Strangler Fig Pattern : moderniser un monolithe sans le big bang
Tout le monde a déjà entendu cette phrase dans une réunion : « il faudrait tout réécrire ». Six mois, douze mois, parfois deux ans plus tard, le projet de réécriture intégrale est en retard, le legacy continue d'évoluer en parallèle, et l'équipe se retrouve avec deux systèmes à maintenir au lieu d'un. Le « big bang » est, statistiquement, l'un des moyens les plus fiables de tuer un projet de modernisation.
Le Strangler Fig Pattern propose l'inverse : remplacer le monolithe par petits morceaux, en production, sans interruption de service. Le nom vient de Martin Fowler, qui a baptisé le pattern d'après le figuier étrangleur — cet arbre tropical qui pousse autour de son hôte, l'enveloppe progressivement, et finit par prendre toute la place pendant que l'arbre original disparaît de l'intérieur. La métaphore est précise : le nouveau système grandit autour de l'ancien, fonctionnalité par fonctionnalité, jusqu'à ce que le legacy ne porte plus rien et puisse être retiré.
Pourquoi la réécriture intégrale échoue
Avant de parler de la solution, il faut être honnête sur le problème. Une réécriture « big bang » échoue rarement pour des raisons techniques. Elle échoue parce que :
- Le legacy continue de bouger pendant la réécriture. Le code cible est une cible mobile.
- Personne ne connaît plus toutes les règles métier que le monolithe applique. Une partie de la logique est implicite, encodée dans des bugs devenus features, des correctifs urgents jamais documentés, ou des cas limites que seul le code original gère correctement.
- Le ROI est repoussé jusqu'au jour J du basculement. Aucune valeur livrée pendant 18 mois, puis une mise en production massive avec un risque maximal.
- Le périmètre dérive. Tant qu'à réécrire, autant moderniser le framework, changer la base de données, refondre l'UI… et le projet devient ingérable.
Le Strangler Fig attaque ces quatre problèmes de front.
Comment ça marche concrètement
Le pattern repose sur trois éléments :
1. Un point d'interception (le proxy / façade)
On place un routeur devant le monolithe — typiquement un reverse proxy (Nginx, un API Gateway, un load balancer applicatif), ou un middleware dans l'application elle-même. Toutes les requêtes passent par lui. Au début, il route 100 % du trafic vers le legacy. Rien ne change pour les utilisateurs.
2. L'extraction d'une capacité
On choisit une fonctionnalité bien délimitée — idéalement à fort volume de changement, à faible couplage avec le reste, ou bloquante pour l'évolution du produit. On la réimplémente dans un nouveau service, avec une stack moderne, et on la déploie à côté du monolithe.
3. Le basculement progressif
Le routeur dirige désormais cette fonctionnalité vers le nouveau service. On peut le faire de plusieurs façons :
- Bascule par route :
/api/users/*va au nouveau service, le reste continue vers le legacy. - Canary release : 5 % du trafic vers le nouveau service, on observe, on monte à 25 %, 50 %, 100 %.
- Shadow traffic : le routeur envoie la requête aux deux systèmes, mais ne renvoie que la réponse du legacy. On compare les sorties pour valider la parité avant de basculer pour de vrai.
Une fois la capacité retirée du monolithe, on supprime le code mort. Puis on recommence avec la fonctionnalité suivante.
Les pièges à éviter
Le pattern paraît simple sur le papier. En pratique, trois pièges reviennent systématiquement.
La base de données partagée. Si le nouveau service et le legacy écrivent dans les mêmes tables, vous n'avez pas découpé un service — vous avez créé une nouvelle façade sur le même monolithe. La séparation des données est souvent plus difficile que la séparation du code. Prévoyez une stratégie : change data capture, double écriture, ou extraction par bounded context.
L'absence de critère d'arrêt. Une migration Strangler Fig peut durer des années. Sans un objectif clair (« le module X doit être complètement extrait avant Q3 »), elle s'enlise et vous vous retrouvez avec trois systèmes à maintenir : le legacy, le nouveau, et la couche de coexistence qui n'était censée être que temporaire.
Choisir la mauvaise première brique. La tentation est de commencer par le plus facile. C'est une erreur. Commencez par une capacité qui prouve la valeur du pattern : soit elle débloque une fonctionnalité métier attendue, soit elle élimine une douleur opérationnelle réelle. Sinon, le projet perd son soutien dès le premier trimestre.
Quand l'utiliser — et quand ne pas
Le Strangler Fig est le bon choix quand :
- Le système est en production, génère du revenu, et ne peut pas s'arrêter.
- Le périmètre métier est mal documenté et il faut découvrir les règles au fur et à mesure.
- L'équipe veut livrer de la valeur incrémentale plutôt que parier sur un basculement futur.
Il n'est pas adapté quand le système est petit, peu utilisé, ou quand une réécriture courte (quelques semaines) est réaliste. Dans ce cas, l'overhead du proxy et de la coexistence coûte plus cher que la réécriture directe.
Ce qu'il faut retenir
Moderniser un legacy n'est pas un événement, c'est un processus. Le Strangler Fig vous donne le droit de livrer de la valeur dès la première semaine, de réduire le risque à chaque étape, et de garder un système qui fonctionne en permanence. Le prix à payer : une discipline architecturale rigoureuse sur le routage, les données, et les critères d'arrêt.
La bonne nouvelle, c'est que cette discipline est ce qui distingue les modernisations qui aboutissent de celles qui finissent en deuxième legacy.
Vous avez un monolithe à moderniser et vous hésitez entre réécriture et extraction progressive ? Parlons-en — un audit court suffit souvent à identifier la première brique à extraire et à dérisquer toute la trajectoire.