Comment éviter qu’une migration Strangler ne devienne permanente

Une migration strangler est terminée lorsque le système legacy est mis hors service

Une migration strangler peut livrer avec succès ses capacités de remplacement tout en laissant le programme de modernisation inachevé. Les projets de replatforming à l’origine de ces constats ont régulièrement calé autour de « 80% terminés » : les capacités visibles sont en production et les parties prenantes ont reconnu la livraison, mais le système legacy reste nécessaire. Dans un cas, il traitait encore 15% du trafic de production. Cette dépendance résiduelle est importante, car une migration incrémentale ne capte pleinement sa réduction de risque que lorsque l’ancien système peut être arrêté.

Cette condition de mise hors service change ce que les équipes doivent mesurer. La parité fonctionnelle montre si le nouveau système exécute le travail prévu pour lui, tandis que la mise hors service montre si la production a cessé de dépendre de l’ancien système. Une façade peut encore envoyer un petit ensemble de lectures ou d’écritures vers le legacy après que le remplacement semble terminé, tandis que des traitements batch ou des consommateurs en aval peuvent maintenir des dépendances qui n’apparaissent jamais dans l’interface produit. L’achèvement est donc un état opérationnel avec des conditions précises de trafic, de données et de responsabilité.

Ces conditions changent aussi la manière dont les responsables engineering doivent utiliser le strangler fig pattern. Le remplacement incrémental réduit le risque d’un unique basculement massif, car des capacités individuelles peuvent être déplacées et annulées séparément. Pendant la migration, toutefois, l’organisation exploite une architecture temporaire à deux systèmes ; les deux systèmes ainsi que les mécanismes qui les relient exigent donc une attention engineering. La mise en production des capacités migrées ouvre cette période ; la mise hors service du legacy y met fin.

Le routage est la partie facile du pattern

Cette architecture temporaire commence par un mécanisme de routage établi il y a plus de deux décennies. Martin Fowler a nommé et défini le strangler fig pattern en 2004 dans son bliki : une couche d’interception se place devant le système, les capacités sont déplacées de manière incrémentale, et les requêtes sont envoyées vers l’implémentation appropriée jusqu’à ce que le legacy ne reçoive plus rien. Wikipedia donne la même définition de base, tandis que l’Azure Architecture Center de Microsoft Learn et l’AWS Prescriptive Guidance décrivent des implémentations spécifiques au cloud. Les catalogues de patterns d’architecture, les guides de décision de modernisation et les comparaisons monolithe-versus-microservices situent ce mécanisme parmi des choix de modernisation plus larges.

En pratique, chaque requête client atteint d’abord une façade, généralement un reverse proxy ou une API gateway, qui choisit entre les anciennes et nouvelles implémentations. La façade peut faire ce choix à partir d’un chemin d’URL, d’un en-tête de requête ou d’un feature flag, de sorte que les clients peuvent conserver la même interface pendant qu’une capacité est déplacée. Les recommandations Azure de Microsoft utilisent API Management ou Application Gateway pour cette interception, en envoyant les chemins migrés vers le remplacement et les autres chemins vers le legacy ; Microsoft y gagne lorsque les équipes adoptent des services Azure pour cette conception. AWS, qui bénéficie de la même manière de l’usage de ses services cloud, décrit une implémentation analogue avec Amazon API Gateway ou un Application Load Balancer.

Le point d’interception rend possible une migration capacité par capacité. Une équipe peut envoyer un domaine vers la nouvelle implémentation derrière un feature flag, observer son comportement et rétablir la route legacy si un problème apparaît sans modifier les autres domaines. Le périmètre de rollback peut donc être bien plus petit que l’application. Une exposition progressive en production devient praticable, car le programme ne dépend pas d’une unique date de basculement irréversible.

Parce que le routage sert la migration, la façade a un rôle délibérément temporaire. Une anti-corruption layer a un objectif différent : elle isole un modèle d’un autre système que l’architecture a vocation à conserver. Une façade strangler devrait disparaître une fois l’ancien système supprimé, sauf si l’organisation décide délibérément de lui donner un rôle permanent. D’ici là, sa place sur le chemin des requêtes signifie qu’elle doit être déployée, patchée, supervisée, supportée et incluse dans les procédures d’astreinte, tandis que les deux stacks applicatives reçoivent le même traitement opérationnel.

Cette charge opérationnelle augmente lorsque la coexistence dure plus longtemps que prévu. L’expérience rapportée dans différents projets de replatforming inclut des anciens et nouveaux systèmes fonctionnant ensemble pendant de longues périodes, tandis qu’une observation qualitative distincte décrit des chevauchements durant « parfois des années ». Cette durée est une observation plutôt que le résultat d’une étude nommée. Chaque mois supplémentaire entraîne le coût de deux stacks, plus les charges de routage, de synchronisation et de réconciliation ; ainsi, la réduction du risque de basculement s’accompagne d’un coût continu d’exploitation en parallèle.

Les premiers succès repoussent les dépendances les plus difficiles dans les 20% finaux

Ce coût d’exploitation en parallèle dépend de l’ordre de migration, car un séquencement initial pertinent crée un problème ultérieur prévisible. Les équipes commencent naturellement par des capacités ayant des interfaces claires et des dépendances limitées, puisque ces segments peuvent valider le routage et le rollback avant que le programme n’atteigne ses problèmes de données les plus difficiles. Ces migrations ont tendance à bien se dérouler. Leur succès peut alors créer davantage de confiance que le patrimoine restant ne le justifie.

Commencer par le module le plus gros ou le plus problématique crée le problème inverse. Les équipes le choisissent souvent parce que sa valeur métier est la plus facile à justifier, alors même que le module peut toucher des tables écrites par cinq autres services, des traitements batch dont personne n’a réellement la responsabilité, et des champs qui ne peuvent pas être renommés sans casser un rapport en aval. Le déplacer en premier oblige l’équipe à affronter des problèmes difficiles d’état partagé, de synchronisation et de réconciliation avant d’avoir établi un processus de migration. Une forte valeur métier, à elle seule, ne crée pas une première frontière utile.

Une meilleure première tranche découle de ce problème de dépendance : elle a peu de dépendances amont et un point d’interception propre. Idéalement, elle est dominée par la lecture, a une surface d’écriture étroite et peut être déplacée derrière la façade sans prendre immédiatement la responsabilité d’un état fortement partagé. Le catalogue de patterns et de décomposition de Chris Richardson soutient une focalisation sur des capacités faiblement couplées avec des frontières définies, y compris une décomposition par capacité métier ou sous-domaine. Une telle tranche peut valider le routage, le chemin de synchronisation ou de double écriture retenu, la réconciliation, l’observation et le rollback dans des conditions de production.

Une fois ces contrôles opérationnels, le programme peut les appliquer à des tranches plus difficiles. Une capacité qui partage largement des données mutables devrait attendre qu’un modèle de responsabilité défini et un processus de rollback testé existent ; un couplage qui ne peut pas être séparé peut placer cette capacité hors de la séquence strangler. Pour un monolithe, la découverte des frontières peut donc devoir intervenir d’abord comme un exercice de décomposition distinct. Une fois que les équipes ont établi des frontières par capacité métier ou sous-domaine, elles peuvent déplacer une tranche de bounded context à la fois pendant que d’autres domaines continuent de pointer vers l’implémentation legacy.

Même un bon séquencement tend à laisser les frontières les plus faibles pour la fin. Le patrimoine restant peut inclure des traitements batch aux effets non documentés, des modules legacy vers lesquels trois équipes écrivent encore directement, et des pipelines de reporting qui continuent de consommer l’ancien schéma. Ces dépendances sont des obligations opérationnelles avec des responsables, ou des lacunes là où un responsable devrait exister. Tant que chacune d’elles n’entre pas dans le périmètre de migration, elle peut survivre à chaque basculement produit réussi.

C’est ainsi que « 80% terminé » devient un état durable. Les premières tranches étaient gérables, tandis que le travail ultérieur était difficile à estimer, politiquement flou ou jamais attribué. Une fois que la capacité phare fonctionne sur le nouveau système, les parties prenantes métier peuvent raisonnablement considérer l’investissement comme livré. Lorsque les traitements restants, les émetteurs d’écritures et les consommateurs n’ont ni responsables ni lignes budgétaires financées, personne n’a mandat pour les supprimer.

Le cas précédent où 15% du trafic atteignait encore le legacy montre la conséquence. La majeure partie du trafic avait été déplacée, mais la production avait toujours besoin de l’ancienne implémentation ; la façade et les deux stacks applicatives restaient donc des dépendances opérationnelles. L’achèvement mesuré par le volume de trafic en dit donc peu sur la possibilité réelle de mettre l’infrastructure hors service. Un fallback permanent préserve la dépendance à l’ancien système même lorsque les feature flags ont rendu chaque étape antérieure de migration réversible en toute sécurité.

L’exploitation de deux systèmes fait de la responsabilité des données le problème engineering critique

Ces dépendances tardives convergent souvent vers la responsabilité des données, car le routage des requêtes ne peut pas décider quel état stocké fait autorité. Pendant la période de chevauchement, les deux implémentations peuvent participer à un domaine métier ; chaque domaine a donc besoin d’une source de vérité déclarée avant que sa première tranche ne passe en production. Sans cette déclaration, un écart entre les stores devient un débat sur la justesse après qu’une panne s’est produite. La façade peut router les appels, mais elle ne peut pas décider quelle base de données l’emporte lorsque deux versions divergent.

Les doubles écritures offrent un moyen rapide de synchroniser ces bases de données. Une application reçoit une mise à jour et l’écrit à la fois dans les stores legacy et de remplacement, et l’implémentation peut tenir dans un seul sprint. Le mode de défaillance apparaît lorsque la première écriture réussit et que la seconde échoue, laissant un store en avance sans signal intrinsèque permettant d’identifier la valeur faisant autorité. L’expérience de replatforming décrite ici inclut des équipes ayant choisi cette voie d’implémentation courte, puis passé des mois à enquêter sur la dérive qui en a résulté.

La capture de données de changement (CDC), c’est-à-dire la capture et la réplication des changements de base de données au moment où ils se produisent, déplace la synchronisation hors du chemin d’écriture synchrone de l’application. Avec une CDC fondée sur les logs, la migration consomme les changements depuis le write-ahead log de la base de données legacy et les applique de manière asynchrone au nouveau store. La documentation CDC de Confluent indique qu’un pipeline fondé sur les logs correctement réglé maintient généralement le délai de réplication sous une seconde ; Confluent a un intérêt commercial à l’adoption de sa technologie de data streaming. En comparaison, la synchronisation fondée sur du polling rapportée dans ces migrations présentait des délais de plusieurs minutes, bien que ce chiffre ne soit pas rattaché à un producteur nommé séparément.

Parce que la CDC modifie plutôt qu’elle n’élimine la surface de défaillance, l’état doit toujours être vérifié. La réplication peut être retardée ou échouer ailleurs dans la chaîne de traitement, les mappings peuvent être erronés, et la logique en aval peut encore diverger sur la responsabilité. La réconciliation doit donc être un livrable de migration planifié : comparer les états pertinents, identifier la dérive, établir quel système fournit la valeur correcte, et exécuter la vérification avant de déclarer un basculement terminé. Laisser la réconciliation pour la phase de nettoyage retarde la découverte des incohérences qui déterminent si le legacy peut être mis hors service en toute sécurité.

Cette vérification dépend d’une règle de responsabilité précise au niveau du domaine. À chaque jalon de migration, la question pratique est « qu’est-ce qui écrit encore dans l’ancienne source, et qui est responsable de son déplacement », car un émetteur d’écriture inattendu préserve la dépendance au legacy après que le trafic applicatif ordinaire a été déplacé. Les émetteurs d’écriture directs en base de données sont particulièrement faciles à manquer, car ils contournent la façade. En découvrir un tardivement peut invalider un basculement apparemment complet.

L’état mutable partagé rend la règle de responsabilité encore plus importante, car les anciens et nouveaux logiciels peuvent mettre à jour les mêmes enregistrements simultanément. Sans frontière claire, ces mises à jour peuvent entrer en concurrence sous charge de production et créer des résultats qu’un job de comparaison périodique doit réparer de façon répétée. La réconciliation passe alors d’un contrôle de migration à une charge récurrente de gestion d’incident. Une coexistence stable exige donc une responsabilité d’écriture exclusive ou, à défaut, explicitement définie.

Tant que la coexistence continue, sa charge de travail continue aussi. Les équipes doivent maintenir ensemble l’ancienne stack, la nouvelle stack, la façade, les mécanismes de CDC ou de double écriture, les jobs de réconciliation, la supervision, l’alerting et la couverture d’astreinte, tandis que l’infrastructure et les licences des systèmes parallèles restent au budget. L’architecture temporaire de migration constitue par conséquent une dette technique qui doit être suivie en parallèle du code legacy en cours de suppression. Son coût ne prend fin que lorsque ses composants deviennent inutiles.

Pourtant, la responsabilité peut s’affaiblir alors même que ce travail exige encore une attention soutenue. L’expérience de replatforming à l’origine de ces observations indique que la réconciliation ne reçoit souvent des ressources que jusqu’au « premier trimestre », une observation opérationnelle sans étude quantitative nommée. La réconciliation est nécessaire jusqu’à ce que la transition des données soit démontrablement complète ; la fin de l’affectation de l’équipe de migration initiale est donc un substitut dangereux à une condition d’achèvement engineering. Un processus de réconciliation sans responsable pérenne peut continuer à produire des résultats sans que personne ne soit chargé d’agir dessus.

Un résultat propre doit aussi couvrir une activité métier significative. Zéro dérive lors d’une journée calme en dit peu sur le traitement mensuel, les jobs planifiés, les exécutions de reporting ou d’autres travaux peu fréquents. Avant la mise hors service finale, la réconciliation devrait rester propre sur un cycle métier complet afin que ces chemins aient l’occasion de s’exécuter. La responsabilité des données, la synchronisation et la réconciliation deviennent ainsi des contrôles sur toute la période pendant laquelle deux systèmes de production coexistent.

Financez les jalons de mise hors service et les 20% finaux

Parce que les dépendances non résolues maintiennent ce modèle opérationnel en vie, le financement doit couvrir leur suppression. Un programme organisé autour de la parité fonctionnelle peut financer les capacités de remplacement et épuiser son mandat alors que d’anciens émetteurs d’écriture et consommateurs subsistent. Des jalons de décision liés à la mise hors service intègrent ces dépendances dans le programme financé. Avant que le financement de la tranche suivante ne soit débloqué, le jalon devrait identifier chaque émetteur d’écriture legacy restant, lui attribuer un responsable et établir comment il sera déplacé.

La phase finale mérite un budget explicite, car les plans fonctionnels initiaux ont tendance à masquer son travail. Les jobs sans responsable doivent être investigués, les écritures directes redirigées, les rapports en aval modifiés, la dérive des données éliminée, et l’infrastructure décommissionnée une fois ces dépendances disparues. Appeler cela les 20% finaux est un pattern de programme observé plutôt qu’un ratio universellement mesuré ; la part exacte peut donc varier selon le patrimoine. L’exigence de management reste la même : le travail de mise hors service a besoin d’une ligne budgétaire avant que la livraison visible ne crée une pression pour déclarer le succès.

Le risque programme rend cette exigence pertinente au-delà des migrations strangler. McKinsey Digital a indiqué en 2012 que les grands projets IT dépassaient en moyenne leur budget de 45% et leur calendrier de 7%. Ces chiffres concernent les grands projets IT en général plutôt que les programmes strangler en particulier. Ils plaident pour budgéter le travail qui se poursuit après l’arrivée en production de nouvelles fonctionnalités, au lieu de supposer que le périmètre fonctionnel et le calendrier initiaux absorberont chaque dépendance tardive.

Une grande réécriture avec une seule ligne de financement et un seul basculement présente un profil de risque différent. Sa dépense peut sembler plus simple parce que l’organisation budgète un seul remplacement et une seule date de transition. Ses échecs, toutefois, peuvent apparaître tardivement lorsque l’essentiel du programme doit fonctionner ensemble. Une approche strangler répartit ces décisions sur des tranches incrémentales et permet un rollback par tranche, tandis que son business case doit absorber le coût de l’exploitation en parallèle ; le choix dépend en partie de la capacité à cadrer le patrimoine de manière suffisamment fiable pour un remplacement ciblé.

Pour un programme strangler, ce modèle de financement a besoin d’un jalon d’achèvement opérationnel et testable. Il devrait exiger :

• Zéro trafic de production vers le système legacy, avec 100% des lectures et écritures routées vers le système de remplacement.
• Un responsable nommé du nouveau système pour chaque domaine auparavant détenu par le legacy.
• Zéro dérive de réconciliation sur un cycle métier complet.
• Chaque consommateur en aval des données ou API legacy redirigé vers le nouveau système ou formellement déprécié.

Ces conditions révèlent des dépendances que la parité fonctionnelle peut manquer. Un remplacement peut implémenter chaque fonction visible par l’utilisateur alors qu’un processus de reporting lit encore l’ancien schéma, ou alors qu’une équipe écrit directement dans une base de données legacy. Couper le legacy dans l’une ou l’autre de ces conditions casserait un consommateur restant. Le maintenir en fonctionnement évite cette rupture immédiate tout en préservant le coût et la dépendance que le programme de modernisation vise à supprimer.

Le même jalon donne au business case un test d’achèvement concret. La part de trafic établit si l’ancien chemin d’exécution reste actif, la responsabilité établit si la responsabilité a été transférée avec la capacité, la réconciliation établit si l’état a survécu à la transition, et la migration en aval établit si les consommateurs cachés ont été déplacés. Une fois ces conditions remplies, les ingénieurs peuvent planifier la mise hors service comme un changement exécutable plutôt que prédire que plus personne ne dépend du système.

L’infrastructure de migration temporaire a besoin de son propre plan de sortie

Mettre le legacy hors service révèle alors une dernière dépendance créée par la migration elle-même : la façade. Les projets de replatforming ont vu des façades temporaires survivre aux applications legacy qu’elles avaient été introduites pour aider à supprimer, parce qu’un service présent sur chaque requête de migration acquiert progressivement des responsabilités de production. Logging, alertes, runbooks d’astreinte et responsabilité de maintenance s’accumulent autour d’elle. Ces responsabilités peuvent faire de sa conservation l’option par défaut même après la disparition de sa fonction initiale de routage.

Une façade observée avait été cadrée pour un « trimestre unique » et routait pourtant encore du trafic « deux ans plus tard » parce que sa suppression n’avait pas de responsable. À ce stade, poursuivre son exploitation pouvait sembler plus sûr que modifier un composant portant du trafic de production, même si son objectif initial de migration avait expiré. L’infrastructure temporaire a donc besoin, dès le départ, de son propre responsable de mise hors service et de son propre jalon. Sans cette responsabilité, l’accumulation des obligations de support peut transformer un autre composant de migration en travail de plateforme permanent.

Après l’arrêt du legacy, l’équipe a deux issues cohérentes. Elle peut supprimer la façade parce que la décision de routage ancien/nouveau n’existe plus, éliminant la couche spécifique à la migration et sa charge de maintenance. Ou bien l’organisation peut décider que la façade apporte désormais une valeur d’intégration durable et la conserver délibérément. Une façade conservée devrait recevoir un nouveau nom, un responsable explicite et un SLA afin que son statut de production reflète son rôle permanent.

Certains systèmes ne devraient pas être étranglés

Le coût de création puis de suppression de ces composants temporaires fixe une limite à l’utilité du pattern. L’étranglement exige un point d’interception par lequel le trafic de migration peut être réparti. Des clients desktop fortement couplés, des traitements batch qui lisent directement les bases de données, et des systèmes sans frontière d’API ni bus de messages peuvent ne pas disposer de ce point de contrôle. Pour ces systèmes, créer une séparation architecturale peut devoir devenir un projet préalable distinct avant qu’un routage incrémental soit viable.

Un état mutable partagé indivisible peut créer un blocage tout aussi fort. Si les anciennes et nouvelles implémentations ne peuvent pas recevoir une responsabilité d’écriture propre, une façade laisse le problème central d’état non résolu ; la séparation des bases de données et le travail sur les frontières de domaine peuvent alors devenir l’effort substantiel de modernisation. Les équipes devraient d’abord établir des frontières par capacité métier ou sous-domaine, puis déterminer si les tranches qui en résultent permettent une séquence strangler. Certains modules fortement couplés peuvent rester inadaptés même après que d’autres parties du patrimoine ont été déplacées avec succès.

Les petits patrimoines font face à une contrainte différente, car l’exploitation en parallèle a un coût minimum réel. L’expérience de replatforming ici inclut des équipes ayant consacré un effort engineering significatif à construire une façade autour d’une application qu’une petite équipe aurait pu réécrire directement. Lorsqu’un patrimoine peut être spécifié complètement et remplacé dans un effort ciblé, exploiter deux systèmes ensemble avec synchronisation et réconciliation peut coûter plus cher que la réduction du risque de basculement apportée par l’approche incrémentale. La pertinence dépend donc de l’architecture et de l’économie du patrimoine considéré.

Cette décision de pertinence dépend de la capacité du remplacement incrémental à créer une responsabilité séparable et un chemin crédible vers la mise hors service. Un patrimoine sans frontière d’interception utile peut d’abord nécessiter une séparation architecturale ; un état mutable qui ne peut pas être divisé peut exiger un travail sur le domaine ou la base de données ; et un patrimoine où le coût de la double exploitation dépasse celui d’une réécriture ciblée peut favoriser un remplacement direct. Le strangler fig pattern gagne son avantage en matière de risque là où chaque tranche migrée rapproche l’organisation de manière mesurable de l’arrêt de l’ancien système.

En résumé

Le strangler fig pattern doit être évalué à l’aune de ce qu’il supprime, et pas seulement de ce qu’il livre. Déplacer les capacités de manière incrémentale peut réduire le risque de basculement, mais l’entreprise continue d’assumer le coût et l’exposition du legacy tant que l’ancien trafic, les dépendances de données, les consommateurs ou l’infrastructure de migration restent en production.

Pour les dirigeants, cela fait de la mise hors service un objectif de programme plutôt qu’une tâche de nettoyage post-lancement. Le financement, la responsabilité et la gouvernance doivent s’étendre jusqu’au point où le legacy peut être arrêté en toute sécurité. Les jalons de mise hors service donnent aux dirigeants un moyen pratique de tester les progrès en demandant si le trafic a été déplacé, si les données se réconcilient, si les consommateurs en aval ont migré, et si chaque dépendance restante a un responsable.

Cela crée aussi une base plus claire pour décider s’il faut utiliser ce pattern tout court. Là où les capacités peuvent être séparées et la responsabilité transférée de manière incrémentale, l’étranglement peut échanger un grand risque de basculement contre une série de changements plus petits et réversibles. Là où l’état partagé ne peut pas être divisé ou où l’exploitation en parallèle est disproportionnellement coûteuse, un remplacement ciblé peut être le meilleur investissement.

La distinction stratégique est simple : la mise en production d’un système de remplacement crée une nouvelle capacité ; l’extinction d’un système legacy capture le résultat complet de la modernisation. Une migration strangler n’est complète que lorsque l’organisation n’a plus besoin du système qu’elle avait entrepris de remplacer.