Dessiner une architecture cible est relativement simple. La difficulté commence lorsqu’il faut y parvenir sans arrêter l’activité, perdre la traçabilité, déstabiliser les utilisateurs ou multiplier les risques techniques. Une architecture de transition répond précisément à ce problème : elle organise les états intermédiaires acceptables entre la baseline et la cible.
1. Le faux choix entre conserver et remplacer
Une transformation est souvent présentée comme une opposition entre deux options : maintenir le legacy ou tout reconstruire. Le cas MediSupply adopte une logique différente. L’architecture applicative cible ne recommande pas le remplacement immédiat de toutes les applications ; elle combine modernisation, encapsulation, création de nouveaux services et décommissionnement contrôlé.
Cette approche reconnaît que certaines composantes historiques peuvent encore porter des fonctions nécessaires pendant que de nouvelles capacités sont introduites autour d’elles.
2. Une architecture de transition est un état maîtrisé, pas un bricolage provisoire
La synthèse TOGAF du cas indique que la Phase E devrait traduire l’architecture cible en lots de transformation, architectures de transition et projets concrets. L’idée est essentielle : la cible finale ne suffit pas. Il faut concevoir les étapes qui permettent de l’atteindre.
Un bon état transitoire doit rester exploitable, sécurisé, observable et réversible. Il doit également avoir une durée et une finalité : un provisoire sans stratégie de sortie devient rapidement un nouveau legacy.
3. Palier 1 — Sécuriser et connaître l’existant
Le premier palier technique du cas prévoit l’inventaire de l’infrastructure, la centralisation des sauvegardes, la supervision des applications critiques, la sécurisation des accès et la documentation des dépendances.
Cette séquence rappelle qu’une organisation ne devrait pas engager une migration complexe à partir d’un environnement qu’elle comprend mal. La connaissance de l’existant réduit l’incertitude avant toute transformation plus profonde.
4. Palier 2 — Moderniser les mécanismes d’intégration
Le deuxième palier introduit progressivement une API Gateway, les premières API, un broker de messages, la centralisation des logs et une gestion centralisée des identités.
L’intérêt architectural est de créer une couche d’interopérabilité entre l’ancien et le nouveau. Le legacy peut continuer à fournir certaines fonctions tandis que de nouveaux services apparaissent derrière des interfaces plus maîtrisées.
5. Palier 3 — Industrialiser les nouvelles capacités
Le troisième palier prévoit le déploiement de nouveaux services, la conteneurisation des composants pertinents, la mise en œuvre de CI/CD, le Data Warehouse et l’automatisation des contrôles.
Le mot important est « pertinents » : une architecture moderne n’exige pas que tous les composants adoptent la même technologie. L’industrialisation doit rester proportionnée aux besoins et aux capacités de l’organisation.
6. Palier 4 — Renforcer la résilience et rationaliser
Le quatrième palier traite la reprise d’activité, la haute disponibilité, le retrait progressif de composants legacy, la suppression de bases et fichiers parallèles devenus inutiles et l’optimisation des coûts.
La rationalisation intervient donc après la construction des capacités de remplacement. Le décommissionnement devient la conséquence d’une transition réussie, non son point de départ.
7. Organiser explicitement la coexistence legacy / modern
La coexistence est souvent inévitable pendant une transformation. Elle doit être rendue visible : quelles fonctions restent assurées par le système historique ? lesquelles sont déjà transférées ? quelles données font autorité ? quels échanges synchronisent les deux mondes ?
Dans le cas MediSupply, la cible prévoit notamment l’interopérabilité entre systèmes existants et nouveaux services et cherche à réduire progressivement la dépendance aux composants legacy. Cette formulation est plus réaliste qu’une rupture instantanée.
8. Le décommissionnement doit être conçu dès la transition
Une architecture de transition échoue si elle sait ajouter mais ne sait jamais retirer. Chaque composant maintenu temporairement devrait donc disposer de critères de sortie : fonction remplacée, données migrées et réconciliées, dépendances supprimées, utilisateurs basculés, mécanismes de retour arrière maîtrisés et archivage traité.
Le cas prévoit explicitement une rationalisation progressive du portefeuille applicatif et le retrait des applications devenues redondantes.
9. Moderniser progressivement ne signifie pas avancer sans contrôle
La matrice de risques du cas identifie notamment la dépendance aux systèmes legacy, le risque de rupture d’activité, la sous-estimation des interfaces, la perte de traçabilité pendant la migration, les compétences insuffisantes et la complexité excessive de l’architecture. Les réponses proposées incluent encapsulation et migration progressive, déploiement par paliers, cartographie préalable, réconciliation et contrôles, formation et architecture proportionnée aux besoins.
La revue de conformité demande en outre que le plan de migration et de retour arrière soit documenté. La transition devient ainsi un exercice de gestion du risque autant qu’un exercice technique.
10. Dix règles pour une transition maîtrisée
- Inventorier avant de migrer.
- Documenter les dépendances.
- Sécuriser l’existant avant d’y connecter le nouveau.
- Créer des interfaces maîtrisées entre legacy et cible.
- Définir la source de référence pour chaque donnée critique.
- Découper la transformation en paliers cohérents.
- Prévoir l’observabilité et la réconciliation pendant la coexistence.
- Documenter migration et retour arrière.
- Définir les critères de décommissionnement.
- Ne jamais laisser le provisoire devenir permanent par défaut.
Conclusion
Moderniser sans tout remplacer n’est ni une concession à l’ancien ni un manque d’ambition. C’est souvent une stratégie plus réaliste de transformation : protéger les fonctions nécessaires, réduire progressivement les dépendances, introduire les nouvelles capacités par étapes et retirer l’existant lorsque les conditions de sortie sont réunies.
Une architecture de transition réussie rend donc la transformation praticable. Elle relie la vision cible aux contraintes du présent et transforme une rupture potentielle en trajectoire gouvernée.
Fondements de l’analyse
MediSupply — paliers et transformation progressive
L’article exploite les paliers de transformation technique, la rationalisation progressive du portefeuille, les analyses d’écarts et la matrice de risques du cas académique. Il ne présente aucun de ces éléments comme un déploiement réel de MediSupply.