Strangler Fig Pattern : remplacer une application legacy sans l'arrêter

Refondre une application, ce n'est pas choisir entre tout garder et tout jeter

Une application vieillit rarement d'un coup. Elle ralentit sur certains écrans, accumule des correctifs qui se contredisent, et devient de plus en plus coûteuse à faire évoluer sans tout casser au passage. La réaction la plus fréquente à ce stade est binaire : soit on continue à patcher l'existant en espérant tenir encore un an, soit on lance une refonte complète, un projet à part, qui promet de tout régler d'un coup.

Cette deuxième option porte un nom qui devrait alerter avant même de commencer : le mode « big bang ». Rien ne sort en production pendant des mois, le budget est engagé avant que la moindre valeur soit livrée, et l'équipe qui utilise l'ancien système au quotidien continue de composer avec ses défauts pendant toute la durée du chantier. Le jour du basculement concentre alors un risque qui aurait pu être réparti sur plusieurs mois.

Ce choix binaire tient surtout parce qu'il n'existe pas, dans la plupart des organisations, de troisième option nommée entre les deux. On sait décrire « on patche » et on sait décrire « on refait tout », mais on ne sait pas toujours décrire ce que veut dire remplacer un système progressivement, avec une méthode qui garantit qu'il sera un jour entièrement neuf plutôt qu'éternellement à moitié rafistolé. Cette absence de vocabulaire partagé explique en partie pourquoi tant de projets de modernisation démarrent en promettant une refonte complète, avant de se rétracter en cours de route vers un simple ravalement de façade, faute d'alternative claire à proposer aux équipes qui financent le chantier.

Le principe du figuier étrangleur : remplacer sans couper le courant

Le Strangler Fig Pattern consiste à remplacer un système existant morceau par morceau, en faisant cohabiter l'ancien et le nouveau jusqu'à ce que le premier disparaisse entièrement, sans jamais interrompre le service pendant la transition. Le nom vient d'un arbre tropical qui pousse lentement autour d'un autre, en prenant sa place sans jamais l'abattre d'un coup. L'architecte logiciel Martin Fowler a popularisé cette analogie pour décrire une approche de modernisation qu'il documente en détail sur son propre site, référence encore citée aujourd'hui par la plupart des architectures de migration progressive.

Concrètement, la méthode découpe le système existant en tranches fonctionnelles livrables une par une : un module de facturation, un écran de gestion des comptes, un flux d'import de données. Chaque tranche est reconstruite sur une base technique saine, puis mise en production pendant que le reste continue de tourner sur l'ancien système. Une couche d'interfaçage, souvent une passerelle API ou un routeur applicatif, dirige chaque requête vers la bonne version selon ce qui a déjà été remplacé. Une fois toutes les tranches basculées, l'ancien système peut être éteint, sans qu'aucune date limite artificielle n'ait jamais menacé la continuité de service.

La forme concrète de cette couche d'interfaçage varie selon le contexte. Sur une application web, il s'agit souvent d'une passerelle qui intercepte chaque requête et la redirige vers l'ancien ou le nouveau système selon une règle explicite, un identifiant d'utilisateur, un type de donnée, une plage horaire. Sur un système plus interne, un simple drapeau de bascule (feature flag) activé tranche par tranche peut suffire, à condition qu'il soit retiré du code aussitôt la tranche définitivement remplacée, et non laissé en place « au cas où ». Dans les deux cas, le principe reste identique : cette règle de routage doit être explicite et documentée, jamais déduite au cas par cas par qui intervient dessus.

La vraie complexité n'est pas dans les nouvelles briques

Ce que la plupart des équipes sous-estiment dans le Strangler Fig Pattern, ce n'est pas la reconstruction des tranches elles-mêmes, c'est le coût de la couche d'interfaçage qui fait cohabiter les deux systèmes pendant toute la durée de la transition. Cette couche n'est pas un détail technique secondaire à ajouter en fin de projet. C'est une brique logicielle à part entière, avec son propre budget, ses propres tests, et sa propre dette si elle est bâclée. Elle doit gérer les cas où une même donnée existe encore des deux côtés, arbitrer les conflits de synchronisation, et rester fiable plus longtemps que ce que le planning initial prévoit, parce qu'une tranche prend presque toujours plus de temps que prévu à basculer proprement.

« Pour moi, là, les étapes, pour pas qu'on perde trop de temps, c'est en gros : nous, on vient créer une brique, c'est l'équivalent de créer une brique logicielle dans un SI. Si on le transpose, c'est la même manière de fonctionner. »

Traiter la couche d'interfaçage comme une simple tuyauterie temporaire, à jeter une fois la migration finie, revient à sous-investir exactement l'endroit du système qui porte le plus de risque pendant toute la durée du chantier. C'est elle qui absorbe les deux versions en parallèle. Si elle casse, les deux systèmes tombent ensemble.

Ce qui rend une coexistence temporaire tenable

Trois éléments déterminent si une migration progressive tient sa promesse ou s'enlise. Le découpage d'abord : chaque tranche doit correspondre à un flux métier complet et testable seule, pas à une couche technique arbitraire qui ne veut rien dire pour l'équipe qui l'utilise au quotidien. La couche d'interfaçage ensuite, qui doit être conçue, budgétée et maintenue comme n'importe quelle autre brique du système, avec un responsable nommé qui ne change pas d'une tranche à l'autre. Le rythme de suppression enfin : chaque portion de l'ancien système remplacée doit être retirée au fil de l'eau, pas accumulée pour un grand nettoyage final qui, en pratique, n'arrive presque jamais. Un ancien module laissé en place « parce que ça marche encore » finit presque toujours par redevenir la référence par défaut de quelqu'un dans l'équipe, ce qui prolonge indéfiniment la cohabitation que la méthode est censée limiter dans le temps.

Donner à la couche d'interfaçage son propre budget

Dans la plupart des plannings de refonte progressive, le budget se répartit entre les tranches à reconstruire, comme si la couche d'interfaçage se construisait toute seule en marge. En pratique, elle absorbe une part significative de l'effort total, parce qu'elle doit rester compatible avec une version de l'ancien système qui, elle, continue parfois d'évoluer pendant la transition, au gré de correctifs urgents que personne n'a le luxe de geler le temps du chantier. Un budget explicite pour cette couche, révisé à chaque tranche plutôt que fixé une fois pour toutes au départ, évite la dérive la plus fréquente de cette méthode : la voir grossir silencieusement jusqu'à coûter, à elle seule, plus cher que l'ensemble des tranches qu'elle relie.

Fixer par avance le critère qui déclenche la bascule

Sans critère explicite, une tranche reste indéfiniment « presque prête », et l'ancien système continue de tourner en parallèle bien après que le nouveau aurait pu prendre le relais. Le critère de bascule se fixe avant de commencer à coder la tranche, pas une fois qu'elle est livrée : un volume de tests passés, une période d'observation en production sans incident, ou un nombre d'utilisateurs migrés sans régression signalée. Cette discipline rejoint un principe plus large sur la reprise d'un système existant, qui consiste à stabiliser avant d'étendre plutôt que de céder à l'urgence apparente de tout moderniser en même temps.

Quand ce pattern n'est pas le bon choix

Le Strangler Fig Pattern n'est pas une réponse universelle, et le présenter comme telle serait aussi trompeur que de vanter le big bang. Une application isolée, sans utilisateur actif à ménager pendant la transition, ni dépendance critique avec d'autres outils, se remplace souvent plus vite et moins cher d'un bloc : construire une couche d'interfaçage pour un système que personne ne risque d'interrompre ajoute une complexité que rien ne vient justifier. Le pattern gagne sa place quand la continuité de service compte réellement, pas par principe.

Le signal le plus fiable pour trancher n'est pas la taille du code ni son ancienneté, c'est le nombre de systèmes tiers qui dépendent de lui sans que vous en ayez la liste exhaustive. Une application qui alimente une facturation, un CRM et un tableau de bord métier ne se remplace jamais proprement d'un bloc, parce que chaque intégration cassée silencieusement se découvre des semaines plus tard, au pire moment. À l'inverse, un outil interne utilisé par deux personnes, sans intégration externe, mérite rarement l'effort de conception d'une couche d'interfaçage : le temps passé à la construire dépasserait largement celui d'une réécriture complète suivie d'un week-end de bascule.

La même vigilance s'applique quand le système hérité n'a plus personne capable d'expliquer pourquoi il se comporte ainsi : avant de découper quoi que ce soit en tranches, mieux vaut d'abord reconstituer la logique d'un legacy sans historique documenté, faute de quoi chaque tranche reproduit fidèlement des règles que personne n'a vérifiées depuis des années. Pour une modernisation centrée spécifiquement sur un ERP, la question se pose différemment : notre article sur la migration ERP sans big bang détaille les trois principes qui s'appliquent à ce cas précis.

Avant de lancer votre prochaine refonte, listez les flux métier de votre application actuelle et identifiez lequel peut être remplacé en premier sans dépendre des autres. C'est cette tranche-là, pas la plus visible ni la plus urgente, qui doit ouvrir le chantier.