Strangler Fig Pattern : moderniser un système legacy sans tout casser

#Origine du pattern : une plante tropicale comme métaphore d'architecture

Le strangler fig pattern tire son nom du figuier étrangleur (Ficus), une plante tropicale dont les racines descendent le long d'un arbre hôte jusqu'au sol. Avec le temps, les racines fusionnent et forment un nouveau tronc. L'arbre hôte finit par mourir, laissant place à une structure autonome et robuste.

Martin Fowler a formalisé cette métaphore en 2004 dans un article fondateur sur martinfowler.com. Il observait que la plupart des systèmes d'entreprise vieillissent mal, deviennent des «legacy» difficiles à modifier, mais qu'une réécriture totale — souvent appelée «big bang» — génère des risques opérationnels considérables : régression fonctionnelle, délais explosés, perte de la connaissance métier encodée dans l'ancien code.

Son insight était simple : remplacer graduellement, module par module, en laissant coexister l'ancien et le nouveau pendant toute la durée de la transition.

Depuis, AWS, Google Cloud, Netflix et des centaines d'équipes engineering ont adopté cette méthode. Elle est aujourd'hui considérée comme le standard industriel pour toute migration legacy de taille significative.

---

#Principe fondamental : coexistence contrôlée

L'idée centrale est de ne jamais avoir un seul instant de basculement total. À la place, vous construisez une couche de routage — un proxy, une API gateway, ou un reverse proxy — qui décide quelle version (ancienne ou nouvelle) traite chaque requête.

Au départ, 100% du trafic part vers le legacy. Au fil des mois, la part du nouveau système augmente. À la fin, 100% du trafic est traité par le nouveau système et l'ancien peut être éteint proprement.

Cette coexistence implique plusieurs principes non négociables :

Pas de modification fonctionnelle pendant la migration. Le nouveau composant doit reproduire exactement le comportement de l'ancien avant d'ajouter des fonctionnalités. Mélanger migration et évolution fonctionnelle est la première cause d'échec.

La couche de routage est critique. Elle doit être stateless, résiliente et facilement configurable (feature flags, pourcentage de trafic, règles métier). En pratique, on utilise Nginx, Kong, AWS API Gateway ou un service mesh comme Istio.

Les données doivent rester cohérentes. L'un des défis majeurs est la synchronisation des données entre l'ancien et le nouveau système pendant la phase de coexistence. On utilise généralement un event bus (Kafka, RabbitMQ) ou un pattern de dual-write pour garantir la cohérence.

---

#Les quatre étapes concrètes

#1. Identify — Cartographier et prioriser

Avant de poser la première ligne de code, cartographiez précisément votre système legacy. L'objectif est d'identifier :

• Les domaines fonctionnels (ou bounded contexts en DDD) : facturation, gestion des commandes, catalogue produit, gestion des utilisateurs…
• Le couplage entre ces domaines : quels modules partagent des données en base ? Quels appels synchrones existent entre eux ?
• La criticité métier : quel est l'impact d'une panne de chaque module ? Quels modules génèrent le plus de valeur ?
• La dette technique : quels modules sont les plus difficiles à tester, les plus fréquemment source de bugs ?

Cette cartographie produit une dependency map qui guide l'ordre de migration. La règle d'or : commencez par un module faiblement couplé, à valeur métier mesurable, mais pas critique au point qu'une erreur soit catastrophique. Typiquement : le module de reporting, le portail client, ou la gestion des référentiels.

#2. Route — Mettre en place la couche de routage

Déployez votre couche de routage devant le legacy avant d'avoir écrit le moindre nouveau composant. Cette étape est souvent sous-estimée.

En pratique : configurez votre reverse proxy pour que 100% du trafic continue vers le legacy. Vérifiez que les temps de réponse et le comportement fonctionnel sont identiques. Vous avez maintenant une infrastructure qui permet de basculer du trafic sans toucher au legacy ni au nouveau système.

Pour les équipes qui démarrent, un simple Nginx ou un AWS Application Load Balancer avec règles de routage basées sur les URL suffisent. Pour des architectures plus sophistiquées, Istio ou Envoy permettent un routage au niveau du service mesh avec canary releases et circuit breakers intégrés.

#3. Strangle — Remplacer module par module

C'est la phase longue, qui dure de quelques mois à plusieurs années selon la taille du système. Pour chaque module sélectionné :

1. Développer le nouveau composant en isolation, avec ses propres tests unitaires et d'intégration.
2. Synchroniser les données : mettre en place la couche de synchronisation (dual-write ou event sourcing) pour que les deux systèmes voient les mêmes données.
3. Shadow mode : faire tourner le nouveau composant en parallèle de l'ancien, comparer les résultats sans exposer les utilisateurs.
4. Canary release : basculer 1% à 5% du trafic vers le nouveau composant. Monitorer les métriques (latence p99, taux d'erreur, cohérence des données).
5. Rollout progressif : augmenter le pourcentage (10% → 25% → 50% → 100%) en maintenant la capacité de rollback immédiat.

Chaque itération de cette séquence peut durer de 2 à 8 semaines selon la complexité du module.

#4. Retire — Supprimer proprement l'ancien code

C'est l'étape que les équipes repoussent systématiquement — et qui finit par transformer le strangler fig en «strangler fig incomplet». Une fois un module migré à 100%, planifiez formellement la suppression de l'ancien code.

Concrètement : éteignez le module legacy pour ce périmètre, retirez les règles de routage correspondantes, nettoyez les tables de base de données obsolètes, désactivez les synchronisations de données. Documentez la date de retirement dans votre ADR (Architecture Decision Record).

Sans cette étape, vous finissez avec trois systèmes à maintenir au lieu de deux.

---

#Exemple 1 : ERP SAP → architecture microservices

Situation type construite pour illustrer la méthode, pas un projet client réel : aucun résultat chiffré n'y est associé.

Prenons un groupe industriel qui opère sur un SAP ECC 6.0 déployé en 2008, avec de nombreuses personnalisations ABAP et des intégrations point-à-point avec une dizaine d'outils tiers (EDI, WMS, BI, portail fournisseurs).

Le problème. SAP ECC 6.0 entre en fin de support mainstream en 2027. La migration vers S/4HANA en mode «big bang» est lourde en coût et en durée, avec un risque opérationnel que la direction peut juger inacceptable.

L'approche strangler fig. On commence par extraire le portail fournisseurs (gestion des commandes d'achat, des confirmations et de la facturation fournisseurs). Ce module pèse peu dans les transactions SAP mais génère souvent beaucoup de tickets de support et d'insatisfaction externe.

• Phase Identify : cartographie des flux de données entrants et sortants du module, identification des tables SAP concernées, inventaire des interfaces ABAP.
• Phase Route : déploiement d'une API gateway Kong devant SAP, proxying 100% du trafic.
• Phase Strangle : développement d'un microservice Node.js avec PostgreSQL, synchronisation via un connecteur Kafka → SAP BAPI, shadow mode, puis canary progressif jusqu'à 100%.
• Phase Retire : extinction du module ABAP correspondant, mise à jour de la documentation.

Ce que l'on vise. Un premier module migré sans interruption de service, qui sert de preuve pour obtenir la validation du budget des modules suivants sur un horizon pluriannuel. On compare ensuite le coût réel au chiffrage d'un big bang.

---

#Exemple 2 : Monolithe PHP → Next.js headless

Autre situation type, construite pour illustrer la méthode. Une plateforme e-commerce B2B fonctionne sur un monolithe PHP 5.6 — Symfony 2 — avec une forte dette technique, des déploiements longs et une faible couverture de tests.

L'approche strangler fig côté frontend. Plutôt que de réécrire le backend en une fois, l'équipe a choisi d'attaquer par le frontend avec une architecture headless :

1. Déploiement d'un reverse proxy Nginx devant l'ancien monolithe.
2. Migration de la page d'accueil et des pages catalogue en Next.js 14, consommant les API existantes du monolithe (REST legacy).
3. Au fur et à mesure des pages migrées, exposition de nouvelles API REST propres côté backend, abandonnant progressivement le rendu Twig.
4. Au bout de plusieurs mois, l'essentiel du trafic front est traité par Next.js. Le backend PHP n'expose plus que des API JSON.
5. La migration backend (PHP → NestJS + PostgreSQL) a pu démarrer sereinement, le frontend étant déjà découplé.

Ce qui a fonctionné. La séparation en deux phases — frontend d'abord, backend ensuite — a réduit la complexité de chaque étape. Deux équipes peuvent avancer en parallèle : l'une sur le frontend Next.js, l'autre sur la migration progressive des API backend.

Ce qui a failli déraper. La gestion des sessions PHP dans le contexte headless demande souvent du temps supplémentaire imprévu. Leçon : cartographier la gestion des sessions et de l'authentification dès la phase Identify.

---

#Anti-patterns à éviter absolument

Le strangler fig partiel. Migrer 70% du système et laisser 30% en legacy «pour plus tard». Ce 30% finit par représenter 70% de la dette technique résiduelle. Planifiez le retirement dès le début.

Modifier les fonctionnalités pendant la migration. La règle est stricte : le nouveau composant doit répliquer le comportement de l'ancien à l'identique. Ajouter des features pendant la migration est la cause numéro 1 de dérapage calendaire et budgétaire.

Négliger la synchronisation des données. Un dual-write approximatif génère des incohérences de données qui peuvent prendre des semaines à détecter. Investissez dans un mécanisme de synchronisation robuste et monitoré dès la phase 2.

Une couche de routage trop complexe. Des règles de routage enchevêtrées sur des dizaines de critères deviennent ingérables. Maintenez la couche de routage simple, documentée, et testée automatiquement.

Absence de tests de régression. Sans une suite de tests automatisés couvrant le comportement de l'ancien système, vous ne pouvez pas valider que le nouveau composant est équivalent. Construisez vos tests en phase Identify, avant de démarrer le développement.

Sous-estimer les dépendances de données transversales. Certains modules legacy partagent des tables ou des procédures stockées avec des dizaines d'autres modules. Identifier ces dépendances en amont évite des surprises désagréables en phase Strangle.

---

#Big bang vs strangler fig : critères de décision

Le strangler fig n'est pas universellement supérieur au big bang. Voici une grille de décision factuelle :

Optez pour le strangler fig si :

• Le système est en production avec un trafic actif et une continuité de service requise.
• La complexité fonctionnelle est élevée (nombreux cas limites, logique métier accumulée sur des années).
• L'équipe ne maîtrise pas entièrement le périmètre fonctionnel du legacy.
• Le budget ne permet pas un développement parallèle complet avant le basculement.
• Le risque opérationnel d'une interruption est inacceptable pour le métier.

Le big bang peut être justifié si :

• Le système est petit (moins de 20 000 lignes de code) et entièrement documenté.
• Une interruption planifiée est acceptable (maintenance programmée).
• L'équipe maîtrise à 100% le périmètre fonctionnel et dispose d'une couverture de tests exhaustive.
• Le coût de la coexistence (infrastructure double, synchronisation des données, routage) dépasse le coût du risque.

Dans la pratique, pour les ETI avec des systèmes de production critiques, le strangler fig est le plus souvent le choix par défaut.

---

#Exemple de situation : un ERP d'ETI modernisé sur 3 ans

Feuille de route type, construite pour illustrer la démarche : ce n'est pas un projet client réel et aucun résultat chiffré n'y est associé.

Prenons une ETI du secteur distribution, avec un ERP métier développé en interne il y a de nombreuses années : code Java EE, base Oracle, déployé on-premise.

Phase 0 — Diagnostic. Cartographie complète des modules fonctionnels, analyse de couplage, évaluation de la dette technique par module (métriques SonarQube), qualification des risques métier. Résultat attendu : quelques modules «stranglables» en priorité, des modules à fort couplage nécessitant une approche spécifique, et des modules migrables en bloc en fin de roadmap.

Année 1 — Modules périphériques. Migration du portail client web, du module de reporting BI et de l'API d'intégration EDI. Stack cible : NestJS + React + PostgreSQL sur AWS. Objectif : aucune interruption de service, et des déploiements plus rapides sur les modules migrés.

Année 2 — Cœur commercial. Migration du module de gestion des commandes et de la facturation — les deux modules les plus critiques. Durée plus longue du fait du volume transactionnel et de la complexité de synchronisation des données. Introduction d'un event bus Kafka pour découpler définitivement les deux systèmes.

Année 3 — Clôture et retirement. Migration des modules restants. Extinction progressive de l'ancien ERP, réduction de l'infrastructure on-premise, comparaison du coût total de possession (TCO) avant/après sur une base annualisée.

Ce que cette démarche enseigne. La phase Identify est systématiquement sous-budgétée. Les équipes veulent «démarrer le vrai travail» rapidement. En réalité, une cartographie rigoureuse économise de longs mois de correction en phase Strangle.

---

#Timeline et budget réaliste

Les durées ci-dessous sont des ordres de grandeur, hors coûts d'infrastructure. Le budget dépend du périmètre, du nombre de modules, de la dette technique et des intégrations : il est chiffré sur devis, en 48 h après un premier échange.

Système legacy de taille petite à moyenne (50 000 à 150 000 lignes, 5 à 10 modules)

• Durée : 12 à 18 mois
• Équipe type : 3 à 5 développeurs, 1 architecte, 1 tech lead

Système legacy de taille moyenne à grande (150 000 à 500 000 lignes, 10 à 25 modules)

• Durée : 24 à 42 mois
• Équipe type : 6 à 12 développeurs, 2 architectes, 1 delivery manager

Ces estimations intègrent les phases de synchronisation des données, les tests de régression, le monitoring de la couche de routage et les phases de retirement. Elles excluent les coûts d'infrastructure cloud et les licences.

Un point souvent négligé dans les budgets : le coût de la coexistence des deux systèmes en production. Infrastructure double, maintenances parallèles, synchronisation des données — cette phase pèse de façon significative dans le budget total.

---

#Ressources pour aller plus loin

Le strangler fig pattern s'inscrit dans un ensemble de patterns d'architecture complémentaires : Branch by Abstraction, le pattern Anti-Corruption Layer (indispensable pour préserver la cohérence du nouveau domaine face au legacy), et les event-driven architectures qui simplifient la synchronisation des données en phase de coexistence.

Sur le plan organisationnel, la mise en place d'une roadmap de modernisation legacy sur 3 ans demande un sponsoring C-level explicite et une gouvernance claire entre équipes produit, engineering et métier.

Nehos accompagne les ETI et grands comptes depuis la phase de diagnostic jusqu'au retirement final. Si vous évaluez une migration legacy, notre service de modernisation legacy détaille notre méthodologie.

Photos : Cemrecan Yurtman, Francesco Ungaro sur Pexels.