Pourquoi le strangler fig pattern déraille si souvent — et comment le maintenir en mouvement

Le strangler fig pattern est l'une de ces idées qui paraît aboutie dès qu'on l'entend. On enveloppe l'ancien système, on route les nouvelles fonctionnalités via une façade, on migre une capacité à la fois, et on laisse le monolithe se résorber jusqu'à ce qu'il n'y ait plus rien à éteindre. Sur un schéma, c'est élégant. Dans une vraie organisation, ça déraille plus souvent que ça ne réussit — et quand c'est le cas, la cause est rarement le code.

Nous avons repris suffisamment de migrations à moitié terminées pour voir le même schéma derrière le schéma. La technique est solide. Ce qui casse, c'est tout ce qui l'entoure.

Le premier blocage est organisationnel

Une migration strangler ne progresse que si quelqu'un continue de décider quelle capacité migre ensuite — et continue de financer le déplacement. Cette décision est facile au premier mois, quand la direction est attentive. Au huitième mois, la nouvelle plateforme gère les 30 % visibles — les flux orientés client que tout le monde voulait moderniser — et les 70 % restants sont une logique back-office peu glamour que personne dans la direction ne réclame. La migration n'échoue pas. Elle s'arrête silencieusement, et l'entreprise se retrouve à exploiter deux systèmes indéfiniment — l'issue la plus coûteuse qui soit.

Le deuxième blocage se cache dans les coutures

La façade qui route entre l'ancien et le nouveau n'est pas gratuite. Chaque capacité déplacée ajoute un point de traduction : des données qui doivent rester cohérentes entre deux magasins, une transaction qui franchit maintenant une frontière, un modèle d'identité ou de permission qui doit avoir le même sens des deux côtés. Les équipes sous-estiment cela parce que la façade est invisible sur le schéma d'architecture — c'est la ligne entre deux boîtes. En production, c'est là que vivent les incidents.

Le troisième blocage est la mesure

La plupart des migrations bloquées que nous avons vues n'avaient pas de définition honnête de « terminé » par incrément. « Migrer la capacité commandes » n'est pas une unité de travail ; c'est un vœu. Sans contrat précis pour chaque tranche — ce qui bouge, ce qui reste, comment les deux se réconcilient, et comment on revient en arrière si la tranche se comporte mal — chaque incrément devient une négociation, et les négociations sont lentes.

Comment maintenir la dynamique

Commencez par le prérequis réel du strangler, qui est l'observabilité, pas l'architecture. Avant de déplacer la moindre capacité, vous devez voir exactement ce que fait le monolithe — quels appels, quelles données, quelles dépendances — car on ne peut pas envelopper en toute sécurité ce qu'on ne peut pas mesurer. Les équipes qui sautent cette étape passent la migration à découvrir des couplages cachés de la pire façon : lors des incidents.

Séquencez par risque et réversibilité, pas par visibilité. L'instinct est de migrer d'abord la pièce client visible. La discipline est de migrer la tranche qui vous apprend le plus sur vos coutures tout en étant bon marché à revenir en arrière. Les premiers incréments sont là où vous remboursez votre ignorance ; dépensez-les à apprendre, pas à faire des démos.

Faites de chaque incrément un contrat. Pour chaque tranche : la capacité qui bouge, la propriété des données après le déplacement, la garantie de cohérence à travers la frontière, le chemin de rollback, et la métrique qui dit que ça a fonctionné. Si vous ne pouvez pas écrire ces cinq choses, la tranche n'est pas prête.

Et donnez à quelqu'un un mandat permanent pour continuer à choisir la prochaine tranche. Le strangler fig est une métaphore biologique pour une raison — le figuier tue l'hôte lentement, sur des années, uniquement parce qu'il ne s'arrête jamais de croître. Au moment où il s'arrête, vous n'avez pas une migration. Vous avez deux systèmes et une facture de maintenance.

Rien de tout cela n'est une raison d'éviter le pattern. Pour les grands monolithes porteurs de charge, c'est encore la façon la plus sûre que nous connaissons de moderniser sans basculement big-bang à haut risque. Ce n'est simplement pas un pattern gratuit, et le traiter comme tel est le moyen le plus fiable de se retrouver bloqué à mi-chemin.