Intégration et modernisation de systèmes

Faire fonctionner ensemble des systèmes hétérogènes sans interrompre le service, et réduire la dette technique accumulée.

Enjeu

Le problème tel qu’il se pose.

Les administrations et les grandes organisations exploitent des systèmes construits à des époques différentes, par des fournisseurs différents, avec des formats qui ne communiquent pas. Le remplacement complet est rarement finançable et presque toujours risqué. La modernisation doit donc se faire en service continu.

Résultat recherché

Ce que l’organisation obtient.

Un système d’information dont les composants échangent de façon documentée, dont les dépendances sont connues, et qui peut évoluer par parties sans remise en cause de l’ensemble.

Avant d’engager

Quatre questions préalables.

Une organisation qui ne sait pas répondre à ces questions n’a pas encore de programme : elle a une intention. Les formuler coûte moins cher que de les découvrir en cours de réalisation.

  1. 01Disposez-vous d’une cartographie à jour de vos systèmes et de leurs dépendances réelles, distincte du schéma d’origine ?
  2. 02Vos échanges entre systèmes reposent-ils sur des interfaces documentées, ou sur des accès directs aux bases de données ?
  3. 03Un composant peut-il être remplacé sans arrêter le service qui en dépend ?
  4. 04La propriété du code et des formats vous revient-elle, ou relève-t-elle du fournisseur qui les a produits ?

Notre rôle

Ce que nous prenons en charge.

  • Cartographie des systèmes existants, des flux et des dépendances réelles.
  • Définition d’interfaces documentées et stables entre domaines fonctionnels.
  • Reprise et fiabilisation des données, avec contrôle de qualité mesurable.
  • Migration par lots, chaque lot étant réversible tant qu’il n’est pas confirmé.
  • Décommissionnement maîtrisé des composants remplacés.

Sécurité

Principes appliqués.

  • Segmentation entre domaines fonctionnels et moindre privilège appliqué aux échanges.
  • Authentification et journalisation systématiques des flux inter-systèmes.
  • Chiffrement des échanges et des données au repos.
  • Contrôle de la chaîne d’approvisionnement logicielle des composants intégrés.

Déploiement

Modes possibles.

  • Sur l’infrastructure du client.
  • En environnement hybride, avec maintien des données sensibles sur site.
  • En environnement souverain opéré par le client ou un opérateur national.

Le mode retenu dépend des exigences de souveraineté, de continuité et de classification propres à l’organisation. Il est arrêté avant la conception, pas après.

Répartition de la responsabilité opérationnelle

  1. Cadrage

    Konect 9 / organisation 3

    Les exigences, les critères de sortie et le plan de réversibilité sont posés.

  2. Construction

    Konect 8 / organisation 4

    Les équipes de l’organisation participent à la conception, pas à la recette seule.

  3. Mise en service

    Konect 5 / organisation 7

    L’exploitation est conduite conjointement, procédures écrites à l’appui.

  4. Exploitation accompagnée

    Konect 2 / organisation 10

    L’organisation opère ; Konect intervient sur sollicitation.

  5. Autonomie

    Organisation cliente, seule

    La mission se termine. Le système est exploité sans assistance extérieure.

Schéma de principe. Les proportions expriment un ordre de grandeur relatif entre phases ; elles ne sont ni un engagement contractuel, ni une mesure. Le calendrier réel est arrêté mission par mission.

Transfert de compétences

Fin de mission.

Documentation d’architecture remise au client, formation des équipes d’exploitation et transfert progressif de la responsabilité opérationnelle selon un calendrier contractuel.

Consultations · Préqualifications · Partenariats

Poursuivre l’échange.

Les éléments détaillés — méthodologie, références, capability statement — sont communiqués dans un cadre encadré, à la demande d’une organisation identifiée.