Nehos Groupe
Définition & Concepts

Strangler Fig Pattern (modernisation legacy progressive)

Version Décideur

L'essentiel

Le Strangler Fig Pattern, c'est moderniser un vieux logiciel d'entreprise en remplaçant ses fonctionnalités une par une, comme une plante grimpante qui pousse autour d'un arbre jusqu'à le remplacer. Au lieu de tout casser et tout refaire d'un coup (catastrophe assurée), on intercale progressivement du code moderne. Pendant 18-36 mois, l'ancien et le nouveau coexistent, puis l'ancien disparaît. Pas d'arrêt de production, risque maîtrisé.

Version Expert

Détails Techniques

Pattern d'architecture logicielle formalisé par Martin Fowler en 2004 (référence : 'StranglerFigApplication') consistant à remplacer progressivement un système existant (legacy) par un système moderne, fonctionnalité par fonctionnalité, sans interruption ni big bang. Métaphore inspirée du figuier étrangleur (Ficus tropical) qui pousse autour d'un arbre hôte jusqu'à le remplacer totalement. Approche opposée au 'big bang remplacement' qui échoue dans 70 % des cas selon l'étude Standish CHAOS Report.

#Définition Strangler Fig Pattern

Pattern d'architecture logicielle formalisé par Martin Fowler en 2004 (référence : 'StranglerFigApplication') consistant à remplacer progressivement un système existant (legacy) par un système moderne, fonctionnalité par fonctionnalité, sans interruption ni big bang. Métaphore inspirée du figuier étrangleur (Ficus tropical) qui pousse autour d'un arbre hôte jusqu'à le remplacer totalement. Pour approfondir, consultez la page service modernisation legacy Nehos.

Traduit en termes opérationnels, Approche opposée au 'big bang remplacement' qui échoue dans 70 % des cas selon l'étude Standish CHAOS Report.

On voit trop de projets échouer par méconnaissance de Strangler Fig Pattern. La théorie compte — mais la mise en pratique encore plus.

#Strangler Fig Pattern expliqué simplement

Le Strangler Fig Pattern, c'est moderniser un vieux logiciel d'entreprise en remplaçant ses fonctionnalités une par une, comme une plante grimpante qui pousse autour d'un arbre jusqu'à le remplacer. Au lieu de tout casser et tout refaire d'un coup (catastrophe assurée), on intercale progressivement du code moderne. Pendant 18-36 mois, l'ancien et le nouveau coexistent, puis l'ancien disparaît. Pas d'arrêt de production, risque maîtrisé.

Situation classique dans les projets que Nehos accompagne. C'est exactement ce type de situation que Nehos rencontre chaque semaine chez ses clients.

#Cas d'usage concrets

ETI mécanique de précision — Modernisation ERP propriétaire 18 ans (Java legacy) vers Next.js + Payload + APIs sur 24 mois. Zéro arrêt de production. Économie maintenance corrective 221 k€/an.

Banque mutualiste — core banking COBOL — Encapsulation progressive du noyau COBOL (5 millions de lignes) avec API gateway + micro-services Kotlin. Décommissionnement par module sur 4 ans avec Méthode Legacy Strangler IA-Assisted Nehos™.

Mutuelle santé Cegid HR legacy — Couches périphériques modernisées (portail self-service Next.js, dashboards) en gardant le cœur paie Cegid. Coexistence permanente, pas de décommissionnement prévu, gain UX et productivité 35 % côté collaborateurs.

#Strangler Fig Pattern chez Nehos Groupe

On connaît les limites autant que les forces de cette technologie. Sur les 3 derniers projets impliquant Strangler Fig Pattern, on a documenté les résultats avec des KPIs précis. Notre service modernisation legacy Nehos couvre ce périmètre de A à Z.

La méthode Nehos est documentée sur Méthode Legacy Strangler IA-Assisted Nehos™. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 24 mois est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : refonte ERP progressive sans big bang.

#Termes associés

Pour aller plus loin, explorez les termes connexes.

Explorez chaque définition pour construire une vision complète du sujet.

#Points clés à retenir

Strangler Fig Pattern, big bang ou refonte complète : quelle différence ? Trois approches, trois profils de risque. Le big bang remplace tout d'un coup à une date pivot : rapide en théorie, catastrophique en pratique selon le Standish CHAOS Report qui mesure 70 % d'échec sur les gros périmètres.

Combien de temps dure une migration Strangler Fig en moyenne ? Cela dépend de la taille du legacy et de sa criticité. Sur un ERP propriétaire d'ETI (200 à 800 collaborateurs, 1 à 5 millions de lignes de code), comptez 18 à 36 mois avec une équipe de 4 à 8 développeurs côté Nehos.

Quel est le coût d'une modernisation Strangler Fig comparé à un big bang ? Sur le papier, le Strangler coûte 15 à 25 % plus cher en budget cumulé qu'un big bang réussi, parce qu'il faut maintenir deux systèmes pendant la transition (couche de routage, double déploiement, double monitoring). Mais le big bang réussit dans environ 30 % des cas selon Standish : si on pondère par la probabilité d'échec et le coût des projets ratés (remboursement, redémarrage, perte de production), le Strangler est statistiquement moins cher de 30 à 50 %.

Applications Concrètes

Contexte : ETI mécanique de précision

"Modernisation ERP propriétaire 18 ans (Java legacy) vers Next.js + Payload + APIs sur 24 mois. Zéro arrêt de production. Économie maintenance corrective 221 k€/an."

Contexte : Banque mutualiste — core banking COBOL

"Encapsulation progressive du noyau COBOL (5 millions de lignes) avec API gateway + micro-services Kotlin. Décommissionnement par module sur 4 ans avec [Méthode Legacy Strangler IA-Assisted Nehos™](/methodes/legacy-strangler-ia-assisted)."

Contexte : Mutuelle santé Cegid HR legacy

"Couches périphériques modernisées (portail self-service Next.js, dashboards) en gardant le cœur paie Cegid. Coexistence permanente, pas de décommissionnement prévu, gain UX et productivité 35 % côté collaborateurs."

Questions & Réponses

Questions fréquentes sur le Strangler Fig Pattern

Trois approches, trois profils de risque. Le big bang remplace tout d'un coup à une date pivot : rapide en théorie, catastrophique en pratique selon le Standish CHAOS Report qui mesure 70 % d'échec sur les gros périmètres. La refonte complète parallèle développe un nouveau système isolé, puis bascule un jour J : on garde le risque de big bang, plus le coût d'avoir deux équipes pendant des années. Le Strangler Fig intercale du nouveau code à l'intérieur même du système vivant, module par module, avec routage dynamique entre ancien et nouveau. C'est la seule des trois approches qui permet de tester en production, de mesurer le ROI au fur et à mesure, et d'arrêter le projet à tout moment si la valeur n'est pas au rendez-vous.
Cela dépend de la taille du legacy et de sa criticité. Sur un ERP propriétaire d'ETI (200 à 800 collaborateurs, 1 à 5 millions de lignes de code), comptez 18 à 36 mois avec une équipe de 4 à 8 développeurs côté Nehos. Sur un core banking COBOL ou un SIRH grand compte (5 à 20 millions de lignes), on parle de 3 à 5 ans. Le rythme typique est d'un module remplacé tous les 2 à 4 mois, avec un MVP en production dès le 3e mois pour valider la chaîne complète (routage, observabilité, sécurité, déploiement). À noter : la durée brute n'est pas le bon KPI, ce qui compte c'est le ROI cumulé à chaque palier, qui devient positif typiquement entre les mois 6 et 12.
Sur le papier, le Strangler coûte 15 à 25 % plus cher en budget cumulé qu'un big bang réussi, parce qu'il faut maintenir deux systèmes pendant la transition (couche de routage, double déploiement, double monitoring). Mais le big bang réussit dans environ 30 % des cas selon Standish : si on pondère par la probabilité d'échec et le coût des projets ratés (remboursement, redémarrage, perte de production), le Strangler est statistiquement moins cher de 30 à 50 %. Sur un ERP ETI typique, le budget Strangler 24 mois s'établit entre 800 k€ et 1800 k€, contre 600 k€ 1400 k€ pour un big bang qui a 70 % de chances d'échouer. Le calcul est vite fait.
Un Strangler classique repose sur trois activités lentes : lecture manuelle du code legacy par les architectes, réécriture artisanale des règles métier, tests de non-régression rédigés à la main. La Méthode Legacy Strangler IA-Assisted Nehos™ automatise les trois. Nous utilisons des LLM en mode agent pour cartographier le legacy (dépendances, règles métier extraites, dette technique chiffrée), proposer un découpage en modules cohérents, générer 60 à 80 % du code des nouvelles couches (avec relecture humaine systématique), et produire automatiquement les tests de non-régression à partir des logs de production. Résultat mesuré sur nos derniers projets : 35 à 50 % de réduction du time-to-modernize, et une couverture de tests bien supérieure à un projet manuel.
Notre équipe travaille couramment sur COBOL (mainframes z/OS et AIX), Java 6/7/8 (Struts, EJB 2/3, Spring legacy), PHP 5.6 et 7 (Symfony 2, Zend, propriétaire), Visual Basic 6 et VBA, ABAP (SAP R/3 et ECC 6.0), ColdFusion, ainsi que des cas plus rares comme PowerBuilder, Delphi, ou .NET Framework 2.0/3.5. Nous ne réécrivons jamais dans le même langage cible par dogme : le choix de la stack moderne (Next.js + Payload, Kotlin, Node.js, Go, Rust selon le cas) dépend du profil de charge, des compétences disponibles sur le marché, et de la stratégie d'embauche du client à 5 ans. C'est un sujet que nous tranchons toujours en atelier d'architecture, jamais à l'avance.
Soyons honnêtes : le Strangler n'est pas magique. Le risque numéro un, c'est l'enlisement. Si la direction ne tranche pas régulièrement sur les modules à décommissionner, on se retrouve avec un système hybride permanent, deux fois plus coûteux à exploiter que prévu. Le risque numéro deux, c'est la couche de routage elle-même : mal conçue, elle devient un point de contention qui dégrade les performances de tous les modules, anciens comme nouveaux. Le risque numéro trois, sous-estimé, c'est la perte de connaissance métier : si les sachants du legacy partent à la retraite pendant la migration, on perd les règles non documentées. Nehos travaille ces trois risques explicitement en kickoff, avec un comité de pilotage trimestriel qui peut arrêter le projet à tout moment.
Réserver un audit