Strangler Fig Pattern (modernisation legacy progressive)

Trois approches, trois profils de risque. Le big bang remplace tout d'un coup à une date pivot : rapide en théorie, souvent catastrophique en pratique 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 la valeur 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 une migration de plusieurs années, avec une équipe dédiée dont la taille se décide après l'audit. Sur un core banking COBOL ou un SIRH grand compte, la durée est plus longue encore. Le rythme se règle module par module, avec un premier MVP en production le plus tôt possible 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 la valeur livrée à chaque palier.

Sur le papier, le Strangler coûte 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 un big bang ne réussit pas à tous les coups : si l'on pondère par la probabilité d'échec et le coût d'un projet raté (remboursement, redémarrage, perte de production), le Strangler devient souvent moins cher. Le chiffrage d'un projet réel se fait sur devis, après un audit du legacy ; chez Nehos, un projet logiciel plus large démarre à 30 000 € HT.

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 une partie du code des nouvelles couches (avec relecture humaine systématique), et produire automatiquement les tests de non-régression à partir des logs de production. Le bénéfice attendu : un temps de modernisation réduit et une couverture de tests plus large qu'un projet entièrement manuel, à vérifier projet par projet.

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.