Le pattern Strangler Fig : guide pragmatique pour les responsables de l’ingénierie

Le pattern Strangler Fig : guide pragmatique pour les responsables de l’ingénierie

Le pattern strangler fig, créé par Martin Fowler, est une approche architecturale permettant de remplacer progressivement les fonctionnalités d’un système existant grâce à une façade ou un proxy qui achemine le trafic vers de nouveaux composants jusqu’à ce que l’ancien système puisse être mis hors service en toute sécurité. Le nom vient du figuier étrangleur, qui pousse autour d’un arbre hôte et finit progressivement par le remplacer jusqu’à sa disparition. En logiciel, le mécanisme est le même : encapsuler, rediriger, remplacer, retirer.

Trois concepts structurent ce pattern : une façade qui intercepte tout le trafic, l’extraction progressive des fonctionnalités vers de nouveaux services et une barrière de mise hors service qui confirme que le système existant n’est plus nécessaire. Utilisez-le lorsque :

• Une réécriture complète comporte un risque de livraison ou commercial inacceptable

• Le système doit continuer à servir le trafic de production pendant toute la migration

• La livraison de fonctionnalités ne peut pas être interrompue pendant des mois, le temps qu’une réécriture soit terminée

• Le Azure Architecture Center et les AWS Prescriptive Guidance le recommandent tous deux pour la migration cloud progressive des applications monolithiques

Ridiculous Engineering applique ce pattern dans le cadre de missions de modernisation où le coût d’une erreur est élevé et la tolérance aux temps d’arrêt faible.

Table des matières

• Pourquoi les équipes choisissent le pattern strangler fig plutôt qu’une réécriture complète

• Comment le pattern strangler fig fonctionne au niveau de l’architecture

• Techniques et composants concrets de mise en œuvre

• Un plan d’action par étapes, de la découverte à la mise hors service

• À quoi ressemble une véritable migration : le service de commandes

• Compromis, pièges et situations où ne pas utiliser ce pattern

• Ridiculous Engineering réalise des migrations strangler fig de bout en bout

• Points clés à retenir

• Sources utiles et lectures complémentaires

• FAQ

Pourquoi les équipes choisissent le pattern strangler fig plutôt qu’une réécriture complète

Les systèmes existants mettent les équipes en difficulté de manière prévisible. La base de code est fragile, la couverture de tests est limitée et les ingénieurs qui comprenaient la conception initiale sont partis. Une réécriture complète semble séduisante jusqu’à l’arrivée de la première estimation : l’entreprise découvre alors qu’elle implique de six à dix-huit mois d’investissement parallèle, sans aucune nouvelle fonctionnalité livrée.

Les problèmes précis qui poussent les équipes vers une modernisation progressive :

• Monolithes fragilesoù une modification dans un module casse des fonctionnalités sans rapport

• Lacunes de connaissances dans des langages anciens (COBOL, PowerBuilder, premiers environnements Java EE), ce qui rend presque impossible toute refactorisation en toute confiance

• Contraintes réglementaires et de disponibilité qui interdisent les fenêtres de maintenance prolongées

• Exigences de livraison continue lorsque les feuilles de route produit ne peuvent pas être interrompues pour une réécriture

• Risques liés aux coûts et aux délais des réécritures de grande ampleur, quidépassent fréquemment les prévisions budgétaires de façon significative

La formulation originale de Martin Fowler résume bien le compromis fondamental :

La réduction des risques est le principal moteur métier. L’approche recommandée par Fowler privilégie des résultats réguliers et visibles plutôt qu’un lancement unique. Pour un directeur technique qui doit défendre un budget de modernisation devant un conseil d’administration, « nous avons livré trois nouvelles fonctionnalités ce trimestre tout en migrant le service de commandes » est une conversation bien plus facile que « nous aurons quelque chose à vous montrer au quatrième trimestre de l’année prochaine ».

Fonctionnement du motif strangler fig au niveau de l’architecture

L’architecture est conceptuellement simple. Chaque requête client passe par unefaçade strangler, qui est généralement une passerelle API, un proxy inverse ou une couche de routage conçue à cet effet. La façade inspecte chaque requête et la redirige soit vers le système existant, soit vers le nouveau service, selon que les fonctionnalités ont été migrées ou non.

Le flux se présente ainsi : client → façade strangler → monolithe existant (pour les fonctionnalités non migrées) ou nouveau microservice (pour les fonctionnalités migrées). Le système existant et les nouveaux services coexistent pendant la période de migration. Rien ne change côté client.

Principales responsabilités de la façade :

• Routage des requêtes selon le chemin, l’en-tête, le locataire ou l’indicateur de fonctionnalité

• Couche anticorruption (ACL) traduction entre les modèles de données existants et les contrats des nouveaux services, comme le documente l’Azure Architecture Center

• Télémétrie et journalisation de l’utilisation pour mesurer quels points de terminaison existants sont encore actifs

• Routage A/B et canari pour transférer progressivement des pourcentages de trafic vers les nouveaux services

L’article Wikipédia consacré au motif indique qu’il s’applique à plusieurs niveaux de granularité, de l’encapsulation d’une seule méthode à la migration d’une application entière. Cette souplesse le rend pratique : vous n’avez pas à vous engager dans une architecture entièrement composée de microservices dès le premier jour.

Conseil pratique : Instrumentez la façade avant d’extraire la moindre fonctionnalité. Les données de télémétrie d’utilisation de la première semaine vous indiqueront quels points de terminaison sont appelés le plus fréquemment, lesquels ne sont appelés que par un seul client et lesquels n’ont pas été utilisés depuis des mois. Ces données orientent votre liste de priorités d’extraction et mettent souvent au jour du code mort que vous pouvez simplement supprimer.

Techniques et composants concrets de mise en œuvre

La mise en place de la façade est la partie facile. La complexité technique réside dans la logique de routage, la synchronisation des données et le maintien d’un comportement cohérent entre les deux systèmes pendant leur coexistence.

Composants principaux

1. Façade strangler (passerelle API ou proxy inverse) : NGINX, AWS API Gateway, Azure API Management ou un service de routage personnalisé. Il s’agit du point d’entrée unique pour l’ensemble du trafic.

2. Couche anticorruption (ACL) : Une couche de traduction qui convertit les modèles de données et la sémantique du système existant en modèle de domaine du nouveau service. Concevez les ACL avec des règles de traduction explicites et un plan de mise hors service dès le départ.

3. Adaptateurs de service :De minces couches qui permettent au nouveau service d'appeler les API ou bases de données héritées sans importer la logique héritée.

4. Indicateurs de fonctionnalité :Commutateurs d'exécution (LaunchDarkly, Unleash ou un référentiel d'indicateurs développé en interne) qui déterminent quels utilisateurs ou locataires sont orientés vers le nouveau service.

5. Points d'interception :Hooks intégrés au monolithe qui permettent à la façade de capturer les événements ou les modifications de données sans modifier la logique héritée principale.

Techniques de routage

• Routage fondé sur le chemin :Acheminer /orders/v2/* vers le nouveau service, /orders/* vers l'ancien.

• Routage fondé sur l'en-tête ou le locataire :Acheminer certains locataires ou clients d'API vers le nouveau service pour tester celui-ci auprès des premiers utilisateurs.

• Routage piloté par des indicateurs de fonctionnalité :Déplacer progressivement un pourcentage du trafic (1 %, 10 %, 50 %, 100 %) à l'aide d'un référentiel d'indicateurs.

• Déploiements canari :Acheminer une petite partie du trafic de production vers le nouveau service et comparer les taux d'erreur et la latence avant d'élargir le déploiement.

Migration et synchronisation des données

C'est au niveau des données que la plupart des migrations de type « strangler » ralentissent. Les options, classées approximativement par ordre de complexité :

• Double écriture :L'application écrit simultanément dans la base de données héritée et dans le nouveau magasin de données. Cette méthode est simple à mettre en œuvre, mais les échecs d'écriture nécessitent une logique de rapprochement rigoureuse.

• Capture des modifications de données (CDC) :Des outils comme Debezium diffusent en quasi-temps réel les modifications ligne par ligne de la base de données héritée vers le nouveau service. Privilégiez la CDC pour les systèmes à forte charge d'écriture lorsque la latence liée à la double écriture est inacceptable.

• Event sourcing :Rejouer les événements métier pour reconstruire l'état dans le nouveau service. Cette approche est puissante, mais elle exige que le système hérité émette des événements propres.

• Rétroremplissage en masse :Migration ponctuelle des données historiques, généralement exécutée avant la mise en production, puis rapprochée des écarts de la CDC.

Conseil de pro : Pour les parcours de lecture non critiques, la cohérence éventuelle est généralement acceptable. Réservez la complexité de la double écriture synchrone aux transactions financières, aux stocks et à toute donnée pour laquelle une lecture obsolète aurait une véritable conséquence métier.

Liste de contrôle des tests et de la supervision

• Tests de bout en bout qui exercent les chemins de code hérités et nouveaux via la façade

• Tests de contrat entre la façade et chaque service en aval

• Tableaux de bord canari suivant le taux d'erreur, la latence p95 et la parité des indicateurs métier

• Alertes en cas de dérive comportementale : si le nouveau service renvoie des résultats différents de l'ancien pour une même entrée, vous devez le savoir avant les utilisateurs

Plan d'action par phases, de la découverte à la mise hors service

Phase	Activités clés	Rôles	Critère de réussite
1. Découverte	Inventorier les points de terminaison, cartographier les dépendances, instrumenter la télémétrie	Architecte, ingénieur data	Cartographie des dépendances terminée ; les 10 principaux points de terminaison par volume d’appels sont identifiés
2. Identifier les points de jonction	Définir les limites des services, identifier les points de traduction de l’ACL	Architecte, responsable produit	Contextes délimités documentés ; schéma de l’ACL rédigé
3. Construire la façade et l’ACL	Déployer la couche de routage, implémenter l’ACL, valider la parité	Architecte, ingénieur fiabilité	100 % du trafic passe par la façade sans régression
4. Extraire la première fonctionnalité	Migrer un point de terminaison à faible risque et forte valeur vers le nouveau service	Équipe d’ingénierie, assurance qualité	Le nouveau service gère le point de terminaison cible ; le taux d’erreur correspond à la référence de l’ancien système
5. Acheminer et surveiller	Déplacer progressivement le trafic à l’aide de fonctionnalités activables et d’un déploiement canari	Ingénieur fiabilité, responsable de la migration	Latence p95 dans une fourchette de 10 % par rapport à l’ancien système ; aucune alerte d’incohérence des données
6. Itérer et passer à l’échelle	Répéter l’extraction pour les fonctionnalités restantes par ordre de priorité	Équipe entière	Chaque fonctionnalité extraite réussit les tests de contrat et le contrôle canari
Décommissionner l’ancien système	Confirmer l’absence d’appels entrants, transférer la propriété des données, archiver	Architecte, ingénieur data, ingénieur fiabilité	Aucun trafic vers l’ancien système pendant 30 jours consécutifs ; parité des données confirmée ; plan de retour arrière documenté

Le contrôle de décommissionnement mérite d’être souligné. Un module ancien n’est pas prêt à être retiré tant que trois conditions ne sont pas remplies : aucun appel entrant pendant une période définie (30 jours constituent un minimum raisonnable), le transfert confirmé de la propriété des données vers le nouveau service, et les données historiques archivées ou migrées avec un chemin de lecture vérifié. Négliger l’une de ces conditions crée le pire résultat possible : un système « décommissionné » qui continue discrètement à servir du trafic.

Pour les attentes en matière de calendrier, un périmètre réduit s’étend généralement sur quelques mois, un périmètre moyen comme un domaine complet prend moins d’un an, et un grand périmètre impliquant la décomposition complète du monolithe constitue un programme pluriannuel de longue durée, comme Fowler le reconnaît explicitement dans ses recommandations.

À quoi ressemble une véritable migration : le service de commandes

Un point de départ courant pour les migrations par étranglement est le service de commandes d’un monolithe de vente au détail ou SaaS. Voici la séquence de migration :

• Étape 1 — Extraire le modèle de lecture : Créer un nouveau microservice de requêtes de commandes qui lit une copie répliquée de la table des commandes de l’ancien système. Acheminer toutes les requêtes GET /orders/* via la façade vers le nouveau service. L’ancien système gère toutes les écritures.

• Étape 2 — Ajouter le routage par façade pour les points de terminaison de commandes : Déployer la façade de la passerelle API. Confirmer que 100 % du trafic de commandes passe par celle-ci sans régression de latence.

• Étape 3 — Implémenter l’ACL : Le modèle de commande existant contient probablement des champs dénormalisés, des codes d’état sous forme d’entiers et des identifiants client qui correspondent à un schéma différent. L’ACL effectue la traduction avant même que le nouveau service ne les voie.

• Étape 4 — Migrer les flux d’écriture avec la CDC : Déployez Debezium (ou un équivalent) pour diffuser les écritures de commandes de la base de données existante vers le journal d’événements du nouveau service. Validez la parité des données entre les deux stockages.

• Étape 5 — Valider et effectuer un déploiement canari : Acheminez 5 % du trafic d’écriture vers le nouveau service. Surveillez les écarts dans le nombre de commandes, les échecs de transition d’état et les échecs de notification en aval.

• Étape 6 — Effectuer la bascule et mettre hors service : Acheminez 100 % du trafic vers le nouveau service. Surveillez pendant 30 jours. Mettez les tables de commandes existantes hors service après avoir confirmé l’absence totale de lectures directes.

Architecture pendant la coexistence : client → façade de passerelle API → monolithe existant (écritures, au départ) et nouveau microservice de commandes (lectures, puis écritures). Les deux services partagent un flux de réplication CDC pendant la transition. Les diagrammes téléchargeables de l’Azure Architecture Center illustrent clairement ce routage progressif.

Phase de migration	Gère dans le système existant	Gère dans le nouveau service	Contrôle de validation
Extraction des lectures	Toutes les écritures, toutes les lectures	Lectures des commandes (GET)	Parité des données dans les résultats de lecture
Migration des écritures (canari)	95 % des écritures	5 % des écritures	Taux d’erreur, parité du nombre de commandes
Bascule complète	Rien	Tout le trafic des commandes	Confirmation de l’absence de trafic pendant 30 jours
Mise hors service	Archivé	Tout le trafic des commandes	Propriété des données transférée

Conseil pratique : Exécutez la checklist de migration d’entreprise pour tous les points de terminaison destinés aux clients qui affectent le référencement naturel ou les URL publiques. Une migration de type strangler qui modifie la structure des URL sans redirections appropriées peut nuire au trafic organique aussi gravement qu’une réécriture mal exécutée.

Compromis, pièges et situations où ne pas utiliser ce modèle

Le modèle strangler fig n’est pas toujours le bon choix. Utilisé sans précaution, il crée sa propre catégorie de problèmes.

Risques et mesures d’atténuation :

• Complexité du routage : La façade devient une dépendance essentielle sur le chemin critique. Réduisez ce risque à l’aide de disjoncteurs, de contrôles d’état et d’une solution de repli testée vers le système existant pour chaque route.

• Difficultés liées à la cohérence des données : Les écritures doubles et la capture des modifications (CDC) créent toutes deux des fenêtres d’incohérence. Les équipes sous-estiment souvent l’effort d’ingénierie nécessaire pour maintenir la synchronisation des bases de données.

• La façade comme goulot d’étranglement : Une passerelle API mal dimensionnée ajoute de la latence à chaque requête. Testez les performances de la façade sous une charge de production avant d’acheminer du trafic réel.

• Coûts d’une coexistence prolongée : Exécuter deux systèmes en parallèle double la charge opérationnelle. Prévoyez explicitement ce coût ; certains modules existants ne justifieront peut-être jamais une migration complète et devront être isolés derrière la façade indéfiniment.

• Couplage caché : Les systèmes existants comportent souvent des effets secondaires non documentés (déclencheurs d’audit, tâches par lots, intégrations en aval) qui n’apparaissent qu’après l’extraction. Une phase de découverte approfondie permet d’en détecter la plupart.

Liste de contrôle pour une décision rapide — utilisez le modèle du figuier étrangleur lorsque :

1. Le système doit rester opérationnel pendant toute la migration (sans fenêtres de maintenance)

2. Une réécriture d’un seul bloc prendrait plus de six mois et bloquerait la livraison de fonctionnalités

3. Vous pouvez définir des limites de service ou des points de séparation clairs dans le code existant

4. L’équipe a la capacité d’exploiter deux systèmes en parallèle

5. La complexité de la migration des données est maîtrisable avec la CDC ou la double écriture

Ne l’utilisez pas lorsque :

1. Le système existant ne présente aucun point de séparation identifiable (une véritable « grosse boule de boue » sans limites de domaine)

2. L’équipe ne dispose pas de la capacité SRE nécessaire pour surveiller deux systèmes simultanément

3. Le périmètre de la migration est si réduit (un seul microservice doté d’API propres) qu’un remplacement direct présente moins de risques

4. Les contraintes réglementaires interdisent d’exécuter l’ancien et le nouveau système en parallèle

Pour les équipes confrontées aux défis d’intégration de systèmes existants plus largement, ce modèle constitue un outil parmi d’autres dans une boîte à outils de modernisation plus vaste, et non une solution universelle.

Ridiculous Engineering mène des migrations selon le modèle du figuier étrangleur de bout en bout

La plupart des équipes souhaitent se moderniser progressivement. Moins nombreuses sont celles qui disposent de l’expérience en architecture, de l’expertise en ingénierie des données et de la capacité SRE nécessaires pour y parvenir sans que la migration ne s’éternise pendant des années ou que la façade ne devienne discrètement le nouveau système existant.

Ridiculous Engineering’s pratique de développement logiciel sur mesure pratique des démarches de migration progressive selon le modèle de l’arbre étrangleur, de l’analyse initiale à la mise hors service : cartographie des dépendances, conception de façades et de listes de contrôle d’accès (ACL), mise en place de pipelines CDC, gestion du déploiement canary et assistance à long terme une fois les nouveaux services opérationnels. Nous appliquons des critères mesurables à chaque phase afin que vous sachiez exactement quand une fonctionnalité est prête à basculer et quand le module historique peut être retiré en toute sécurité. Si vous devez faire évoluer un monolithe sans interrompre votre activité, planifiez une mission d’analyse avec notre équipe.

Points clés à retenir

Le modèle du figuier étrangleur est le bon choix lorsqu’une réécriture d’un seul bloc est trop risquée, que le système doit rester opérationnel et que vous pouvez définir des points de séparation clairs dans le code existant.

Point	Détails
Instrumenter avant d’extraire	Déployez d’abord la façade et ajoutez la télémétrie ; les données d’utilisation déterminent les priorités d’extraction.
Les ACL empêchent la contamination par l’existant	Concevez des couches anticorruption avec des règles de traduction explicites et un plan de mise hors service dès le premier jour.
La synchronisation des données est la partie la plus difficile	La réplication fondée sur la CDC gère les systèmes à forte charge d’écriture ; la double écriture convient aux flux plus simples, mais nécessite une logique de rapprochement.
La mise hors service comporte un critère impératif	Aucun trafic vers l’ancien système pendant 30 jours consécutifs, ainsi qu’une parité des données confirmée, avant de retirer un module.
Ridiculous Engineering	Mène des missions de bout en bout selon le modèle du figuier étrangleur, avec des critères mesurables à chaque phase, la conception des ACL et la mise en place de pipelines CDC.

Sources utiles et lectures complémentaires

• Martin Fowler — StranglerFigApplication : origine du modèle, métaphore et logique fondamentale de réduction des risques. Commencez par cette ressource.

• Azure Architecture Center — modèle Strangler Fig : diagrammes de routage par phases, recommandations sur les ACL et réserves de mise en œuvre de l’équipe d’architecture cloud de Microsoft.

• AWS Prescriptive Guidance — Strangler Fig : cas d’utilisation du routage et des ACL, avec des notes de mise en œuvre cloud native ; couvre les approches de double écriture et de CDC.

• Wikipédia — modèle Strangler Fig : référence concise couvrant les options de granularité et la journalisation de l’utilisation comme outil de migration.

• Ridiculous Engineering — Intégration des systèmes existants : modèles pratiques pour une modernisation non perturbatrice de la part de l’équipe Ridiculous Engineering.

• Ridiculous Engineering — Coûts de modernisation de COBOL : enseignements budgétaires et calendaires tirés de projets de modernisation de langages existants.

FAQ

Qu’est-ce que le modèle Strangler Fig en architecture logicielle ?

Le modèle Strangler Fig est une approche visant à remplacer progressivement un système existant en acheminant le trafic via une façade vers de nouveaux services, une fonctionnalité à la fois, jusqu’à pouvoir mettre le système existant hors service. Martin Fowler a forgé ce terme en s’inspirant de la biologie du figuier étrangleur.

En quoi le modèle Strangler Fig diffère-t-il d’une réécriture en une seule fois ?

Une réécriture en une seule fois remplace l’intégralité du système d’un coup, bloque la livraison de fonctionnalités et concentre tous les risques sur un lancement unique. L’approche Strangler Fig migre une fonctionnalité à la fois, fournit continuellement de la valeur et permet un retour en arrière à toute étape.

Qu’est-ce qu’une couche anticorruption et pourquoi est-elle importante ?

Une couche anticorruption (ACL) est un composant de traduction qui convertit les modèles de données et la sémantique du système existant en modèle de domaine du nouveau service, empêchant les décisions de conception héritées de se propager dans le nouveau système. Sans elle, les nouveaux services ont tendance à reproduire les mêmes problèmes structurels que le système qu’ils remplacent.

Combien de temps dure généralement une migration Strangler Fig ?

Le calendrier dépend du périmètre : une petite migration dure généralement quelques mois, un domaine complet comme un service de commandes prend moins d’un an, et la décomposition complète d’un monolithe constitue un programme de longue haleine s’étalant sur plusieurs années.

Quand ne faut-il pas utiliser le modèle Strangler Fig ?

Évitez-le lorsque le système existant ne présente aucune frontière identifiable, lorsque l’équipe ne dispose pas des capacités SRE nécessaires pour exploiter deux systèmes en parallèle, ou lorsque le périmètre de la migration est suffisamment réduit pour qu’un remplacement direct comporte moins de risques que la création et la maintenance d’une façade.

Recommandé

• Programmation par intuition : faisons-nous fausse route ? | Ridiculous Engineering

• Comment l’IA transforme la culture de l’ingénierie et l’évolution des carrières | Ridiculous Engineering

• Le secteur technologique se tourne vers les compétences analytiques pour renforcer ses effectifs | Ridiculous Engineering

• Libérer la créativité grâce à la théorie des contraintes | Ridiculous Engineering