Moderniser le legacy ne se résume pas à choisir entre « tout garder » et « tout réécrire ». La bonne stratégie se décide application par application, en fonction de sa valeur métier, de son état technique et des contraintes de l'entreprise. Pour la plupart des SI, le résultat est un portefeuille mixte : certaines applications sont retirées, d'autres réhébergées telles quelles, d'autres encore remplacées progressivement, fonction par fonction, selon le pattern strangler fig.
La réécriture complète en une fois reste l'option la plus risquée. Martin Fowler, qui a popularisé le pattern strangler fig, rappelle que ces remplacements « big bang » échouent souvent : ils prennent du temps alors que les utilisateurs attendent de nouvelles fonctionnalités, le comportement existant est difficile à spécifier, et sans changement d'organisation le nouveau système finit dans le même état que l'ancien 1.
Cet article présente les options disponibles, détaille le fonctionnement du strangler fig et propose une grille d'arbitrage pour décider, pour chaque application, de l'effort à engager.
Cartographier avant de moderniser le legacy
Toute modernisation commence par un inventaire qualifié. Il ne s'agit pas seulement de lister les applications, mais de documenter pour chacune ce qui conditionnera le choix :
- Valeur métier et criticité : processus soutenus, nombre d'utilisateurs, impact d'une indisponibilité.
- État technique : obsolescence des langages, du middleware et des systèmes, couverture de tests, disponibilité des compétences.
- Dépendances : flux entrants et sortants, bases de données partagées, traitements batch, interfaces avec des partenaires.
- Contraintes : exigences réglementaires, contrats de licence et de support, échéances de fin de vie.
- Accès au code source et capacité à le modifier, condition de plusieurs stratégies.
Cet inventaire révèle presque toujours des applications sans usage réel. Les retirer est la modernisation la moins coûteuse qui soit, et libère du budget pour le reste.
Les stratégies possibles : du retrait au refactoring
Le cadre dit des « 7 R », formalisé notamment dans les guides de migration d'AWS, offre un vocabulaire commun utile au-delà du seul cloud 3 :
- Retirer : arrêter ou archiver les applications sans valeur métier.
- Conserver : laisser l'application en place pour l'instant, par exemple pour des raisons de conformité, de risque ou de dépendances.
- Réhéberger (lift and shift) : déplacer l'application sans la modifier.
- Relocaliser : déplacer en masse des serveurs vers la version cloud de la même plateforme de virtualisation.
- Racheter : remplacer l'application par un produit du marché, souvent en SaaS.
- Changer de plateforme (replatform) : déplacer avec des optimisations ciblées, par exemple vers une base de données gérée, sans changer l'architecture.
- Refactorer ou réarchitecturer : modifier l'architecture pour tirer parti de capacités cloud natives.
Le même guide observe que le refactoring est généralement déconseillé dans les migrations à grande échelle, car c'est l'option la plus complexe ; il suggère de réhéberger, relocaliser ou changer de plateforme d'abord, puis de moderniser ensuite 3. Cette séquence a un mérite : elle sépare le changement d'hébergement du changement d'architecture, deux sources de risque qu'il vaut mieux ne pas cumuler.
Réhéberger déplace la dette technique, refactorer la rembourse : les deux ont leur place, mais pas sur les mêmes applications.
Le pattern strangler fig : remplacer sans interrompre
Pour les applications critiques qu'il faut transformer en profondeur, le pattern strangler fig offre une alternative à la réécriture complète. L'image vient d'un figuier qui germe dans les branches d'un arbre, l'enveloppe progressivement puis le remplace 4. Appliqué au logiciel, il consiste à construire le nouveau système autour de l'ancien et à lui transférer les fonctions une par une, jusqu'à pouvoir éteindre l'existant.
La documentation d'architecture de Microsoft décrit le mécanisme central : une façade, ou proxy, placée entre les clients et les back-ends, qui intercepte les requêtes et les oriente soit vers le système historique, soit vers les nouveaux services 2. La migration suit quatre phases : introduire la façade, transférer progressivement les fonctions, décommissionner le système historique, puis retirer la façade 2. AWS résume le même cycle en trois temps, transformer, coexister, éliminer, et insiste sur la nécessité d'un plan de retour arrière pour chaque service refactoré 4.
Martin Fowler souligne que le pattern ne se limite pas à la technique. Il décrit quatre activités : comprendre les résultats attendus, découper le problème en parties, livrer ces parties avec succès et changer l'organisation pour que l'effort puisse durer 1. Il assume aussi le coût de l'architecture transitoire, ce code temporaire qui permet à l'ancien et au nouveau de coexister : il peut sembler du gaspillage, mais la réduction du risque et la valeur livrée plus tôt le justifient 1.
Le choix de la première fonction à extraire conditionne la suite. Elle doit être assez simple pour roder la façade, le déploiement et la supervision, assez visible pour démontrer de la valeur aux métiers, et faiblement couplée au reste du système pour limiter les effets de bord. Les fonctions en lecture seule, ou les nouveaux besoins qui auraient de toute façon exigé des développements, sont souvent de bons candidats.
Les données, point dur de la coexistence
Le routage des requêtes est rarement le plus difficile. Les données partagées le sont davantage : les deux systèmes doivent pouvoir y accéder simultanément pendant la transition 2. Microsoft recommande une couche anti-corruption pour traduire les échanges entre ancien et nouveau modèle, afin que la nouvelle conception ne soit pas contaminée par la sémantique historique. Lorsque la logique réside dans des procédures stockées impossibles à modifier, la capture des changements de données (CDC), qui lit le journal de transactions, permet d'alimenter les nouveaux services sans toucher à l'application 2.
Quand ne pas l'utiliser
Le strangler fig n'est pas universel. Il est inadapté lorsque les requêtes vers le back-end ne peuvent pas être interceptées, lorsque le code source de l'existant est inaccessible, lorsque le système est petit et simple à remplacer d'un bloc, ou lorsqu'il faut décommissionner l'existant rapidement 2. La façade elle-même doit être conçue pour ne devenir ni un point unique de défaillance ni un goulet de performance 24.
Arbitrer : une grille de décision pour moderniser le legacy
Une fois les options connues, l'arbitrage se fait sur quelques questions simples, posées pour chaque application :
- L'application crée-t-elle encore de la valeur ? Sinon, retrait ou archivage.
- Existe-t-il un produit du marché qui couvre le besoin sans différenciation ? Si oui, rachat.
- Le problème principal est-il l'hébergement (fin de contrat de centre de données, obsolescence matérielle) ? Réhébergement ou relocalisation, en planifiant la suite.
- Des gains rapides existent-ils sans toucher à l'architecture (base gérée, conteneurisation) ? Changement de plateforme.
- L'application est-elle différenciante et freine-t-elle l'évolution du métier ? Refactoring, de préférence progressif avec un strangler fig.
- Le risque ou les dépendances sont-ils trop élevés pour agir maintenant ? Conservation temporaire, avec une date de réexamen.
Deux erreurs reviennent souvent. La première consiste à réhéberger sans prévoir la suite : l'application coûte alors autant qu'avant, ailleurs. La seconde consiste à lancer un refactoring sans faire évoluer l'organisation : Fowler rappelle que sans changement culturel, le nouveau système reproduit les travers de l'ancien 1.
Feuille de route type d'un programme de modernisation
- Mois 1 à 3 : inventaire qualifié, classement des applications par stratégie, identification des retraits rapides.
- Mois 3 à 6 : premières migrations à faible risque (réhébergement, changement de plateforme) pour roder les outils et les équipes.
- En parallèle : choix d'une application différenciante comme pilote du strangler fig, mise en place de la façade et d'un premier service extrait.
- Chaque trimestre : revue des indicateurs (fonctions migrées, trafic routé vers le nouveau système, incidents, coûts) et réallocation du budget.
- En continu : décommissionnement effectif des composants remplacés, sans lequel la modernisation n'est qu'une couche de plus.
Conclusion
Moderniser le legacy est un exercice de portefeuille, pas un projet unique. Retirer ce qui ne sert plus, déplacer ce qui doit l'être, et transformer progressivement ce qui fait la différence : c'est cette combinaison, pilotée par des indicateurs et un décommissionnement réel, qui produit des résultats. DATASWING intervient sur ces programmes en aidant à qualifier le portefeuille et à concevoir l'architecture transitoire.
— Questions fréquentes
Ce qu'on nous demande souvent
Qu'est-ce que le pattern strangler fig ?+
C'est une méthode de modernisation progressive popularisée par Martin Fowler. Une façade intercepte les requêtes et les oriente vers l'ancien système ou vers les nouveaux services. Les fonctions sont migrées une par une, l'ancien et le nouveau coexistent, puis l'existant est décommissionné lorsqu'il n'a plus de dépendances. Elle évite le risque d'une réécriture complète livrée en une seule fois.
Lift and shift ou refactoring : que choisir ?+
Le réhébergement (lift and shift) est rapide et peu risqué, mais il conserve la dette technique. Le refactoring la réduit et ouvre l'accès aux capacités cloud natives, au prix d'un effort et d'un risque plus élevés. Une approche fréquente consiste à réhéberger d'abord pour respecter une échéance d'hébergement, puis à refactorer progressivement les applications réellement différenciantes.
Combien de temps dure une modernisation d'application legacy ?+
Il n'existe pas de durée type : elle dépend de la taille de l'application, de ses dépendances et de la stratégie retenue. Un réhébergement peut se compter en semaines, un remplacement progressif par strangler fig s'étale souvent sur plusieurs trimestres. L'important est de livrer de la valeur à chaque étape et de décommissionner effectivement ce qui a été remplacé.
Comment gérer les données lors d'une migration progressive ?+
Pendant la coexistence, ancien et nouveau système doivent accéder aux mêmes données. On utilise une couche anti-corruption pour traduire les modèles et, si l'existant ne peut pas être modifié, la capture des changements de données (CDC) à partir du journal de transactions. Il faut définir clairement, pour chaque donnée, quel système en est la source de vérité à chaque étape.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
Strangler Fig ↗martinfowler.com · 2024-08
-
[2]
Strangler Fig pattern ↗Microsoft Azure Architecture Center · 2026
-
[3]
About the migration strategies (large migration guide) ↗AWS Prescriptive Guidance · 2026
-
[4]
Strangler fig pattern (decomposing monoliths into microservices) ↗AWS Prescriptive Guidance · 2026
