Temps de lecture estimé : 12 minutes
- Ce que vous allez apprendre
- Ce qu'est réellement le pattern strangler fig
- Pourquoi « tout réécrire » coûte cher
- Comment ça fonctionne, sans jargon
- Quand ne pas utiliser le pattern strangler fig
- Comment commencer : choisir le premier morceau
- À quoi ressemble une bonne exécution
- La voie du milieu, pragmatique
- FAQ
Ce que vous allez apprendre
Longtemps, la question a été de savoir si vous alliez remplacer le système vieillissant qui fait tourner vos opérations. Puis, elle est devenue : quand? La question la plus difficile, celle qui repousse la décision d'une année à l'autre, est : comment? Comment remplacer la chose que la moitié de votre équipe contourne discrètement, sans arrêter les opérations pendant les travaux?
La réponse qui fait peur est celle que la plupart des gens imaginent : tout arracher, construire un nouveau système, appuyer sur l'interrupteur une fin de semaine, et espérer. C'est la réécriture complète, le « big-bang », et c'est là que les budgets de modernisation vont mourir.
Il existe une voie intermédiaire entre s'accommoder d'un vieux système qui ralentit tout et parier toute l'entreprise sur une seule bascule. On l'appelle le pattern strangler fig, et il vous permet de remplacer un ancien système un morceau réversible à la fois, pendant qu'il continue de fonctionner. Cet article explique ce que c'est, pourquoi cette approche bat la réécriture complète pour la plupart des opérations, comment elle fonctionne réellement, quand ne pas l'utiliser, et comment choisir le premier morceau à remplacer.
Cet article a été révisé par Dominic Barbe, développeur senior chez Done Technologies, qui cumule plus de 10 années d’expérience en développement logiciel et en conception de solutions technologiques sur mesure.
Ce qu’est réellement le pattern strangler fig
Le pattern strangler fig modernise un système existant de façon incrémentale. Selon les capacités du système et la technologie sous-jacente, cela peut impliquer de construire le nouveau système en parallèle de l’ancien, d’utiliser une couche de routage pour diriger les requêtes, et de migrer une capacité à la fois. La stratégie précise varie, mais l’objectif reste le même : remplacer graduellement le système existant tout en minimisant les risques et les perturbations.
Le nom vient de l’arbre étrangleur (strangler fig), et le terme a été inventé par le penseur du logiciel Martin Fowler après avoir observé ces arbres lors d’un voyage dans la forêt tropicale du Queensland. Comme il le décrit, le figuier « commence par de petits ajouts, souvent de nouvelles fonctionnalités, construites par-dessus, mais séparément de l’ancien code », jusqu’à ce que le nouveau système puisse tenir seul et que « son arbre hôte d’origine puisse mourir, laissant le figuier comme un écho de sa forme ». C’est toute l’idée en une image. On n’abat pas le vieil arbre. On fait pousser le nouveau autour de lui jusqu’à ne plus avoir besoin de l’ancien.
La raison d’être de cette approche est simple. L’ancien système continue de fonctionner tout au long du processus. Rien ne s’arrête, parce qu’on n’éteint jamais tout d’un coup. On l’éteint un petit morceau à la fois, seulement après que le morceau de remplacement a prouvé qu’il fonctionne.
Pourquoi « tout réécrire » coûte cher
Une réécriture complète concentre une grande partie du risque opérationnel dans un seul lancement. Une approche de modernisation progressive répartit ce risque sur des étapes plus petites, qui peuvent être testées, ajustées et, au besoin, annulées. Cette différence peut faire toute la différence entre une transition qui se déroule discrètement et une crise opérationnelle de longue durée.
Le système de paie Phénix du Canada en est un exemple frappant. En 2016, le gouvernement fédéral a mis en place un nouveau système pour traiter la paie des employés, tout en centralisant les services de paie et en retirant l’ancienne plateforme. Phénix a été déployé en deux grandes vagues, malgré des préoccupations non résolues concernant les tests, les fonctionnalités et la préparation organisationnelle.
Les problèmes sont apparus presque immédiatement. Des employés fédéraux ont été sous-payés, surpayés, payés en retard ou, dans certains cas, pas payés du tout. Le Bureau du vérificateur général a plus tard conclu que les responsables du projet avaient priorisé le respect de l’échéancier et du budget prévus, au détriment de facteurs critiques comme la fonctionnalité, la sécurité et la préparation.
Les effets se sont fait sentir bien au-delà du lancement initial. Des années plus tard, le gouvernement travaillait encore à stabiliser les opérations de paie, à indemniser les employés touchés et à préparer un autre système pour éventuellement remplacer Phénix.
La leçon n’est pas que les organisations devraient éviter de remplacer des logiciels dépassés. C’est que remplacer un système critique d’un seul coup, tout en changeant simultanément les processus et les équipes qui l’entourent, laisse très peu de place pour apprendre ou se rattraper. La modernisation progressive réduit cette exposition en permettant aux organisations de valider chaque étape avant de passer à la suivante.
Voici comment les deux approches se comparent sur les facteurs qui comptent vraiment pour vous :
| Facteur | Réécriture complète | Strangler fig (incrémental) |
|---|---|---|
| Profil de risque | Une seule bascule, tout ou rien | Plusieurs petites étapes réversibles |
| Continuité des opérations | Arrêt ou gel pendant la bascule | L’ancien système continue de fonctionner |
| Délai avant la première valeur | Attendre que tout soit terminé | Valeur livrée par étapes |
| Retour en arrière en cas de problème | Difficile et coûteux | Revenir à l’ancien système |
| Échéancier global | Plus court, mais seulement si tout se passe bien | Plus long, mais beaucoup plus sûr |
| Meilleur cas d’usage | Systèmes petits et simples | Systèmes volumineux et critiques qui ne peuvent pas s’arrêter |
Rien de tout cela ne signifie qu’une réécriture est toujours le mauvais choix. Cela dit, elle exige une planification rigoureuse, des tests approfondis et une collaboration étroite avec les utilisateurs, pour s’assurer qu’aucune exigence ou processus critique n’est oublié. Elle peut aussi prendre un temps considérable avant que le nouveau système ne livre de la valeur, et les besoins de l’entreprise peuvent évoluer entretemps.
Si vous hésitez encore entre remplacer, reconstruire ou acheter une solution clé en main, c’est une décision distincte qu’il vaut mieux bien prendre d’abord. Nous en avons parlé dans ERP clé en main vs ERP sur mesure pour les fabricants.
Comment ça fonctionne, sans jargon
En pratique, le pattern repose sur trois éléments : une façade qui route les requêtes, de nouveaux composants qui prennent en charge une capacité à la fois, et un plan pour garder les anciennes et nouvelles données synchronisées jusqu’à la bascule finale. L’Azure Architecture Center de Microsoft explique clairement cette mécanique, et elle vaut la peine d’être comprise en termes simples.
La façade : votre chef d’orchestre du trafic
La migration se déroule généralement en quatre étapes :
- Introduire le nouveau système à côté de l’ancien. Quand c’est possible, une façade route les requêtes vers le système existant, rendant la transition transparente pour les utilisateurs. Dans d’autres cas, les utilisateurs peuvent avoir besoin d’accéder directement au nouveau système pour des opérations spécifiques, au fur et à mesure qu’elles deviennent disponibles.
- Migrer une capacité à la fois. Construire un morceau du nouveau système, puis rediriger ce flux de travail ou demander aux utilisateurs de l’exécuter dans le nouveau système. Répéter. À chaque passage, l’ancien système fait moins et le nouveau fait plus.
- Mettre hors service le système existant. Une fois que plus rien ne dépend de l’ancien code, on l’éteint.
- Retirer la façade, si elle a été utilisée. Les clients interagissent désormais directement avec le nouveau système, et la migration est terminée.
Les deux parties difficiles : les appels entre systèmes et les données
Pendant que les deux systèmes fonctionnent, ils doivent communiquer entre eux. Le nouveau code peut avoir besoin de quelque chose que l’ancien système possède encore, et l’ancien code peut avoir besoin de quelque chose que le nouveau système gère désormais. La façon propre de gérer cela est une couche anti-corruption, un traducteur qui permet aux deux systèmes de s’appeler mutuellement sans que le nouveau système hérite des bizarreries et des mauvaises habitudes de l’ancien.
Les données sont l’autre partie difficile. Vous chargez les données existantes dans le nouveau système une fois, généralement avec un processus d’extraction-transformation-chargement, puis vous gardez les deux synchronisés à mesure que les changements arrivent, souvent avec la capture de données de changement. Vous validez que les deux côtés concordent avant de basculer, et vous conservez la possibilité de revenir en arrière jusqu’à ce que les anciennes données soient réellement supprimées.
Surveillez la façade elle-même
Quand une façade est utilisée, elle peut devenir un point de défaillance unique ou un goulot d’étranglement. Comme tout le trafic routé passe par elle, une panne peut affecter tout ce qui se trouve derrière. Elle devrait donc être traitée comme une infrastructure critique dès le premier jour, pas comme une réflexion après coup.
Quand ne pas utiliser le pattern strangler fig
Le strangler fig est le choix par défaut sûr pour les grands systèmes critiques pour l’entreprise, mais c’est le mauvais outil quand le système est petit, quand vous ne pouvez pas intercepter ses requêtes, ou quand vous ne pouvez pas toucher à son code source. Une bonne approche vous indique quand l’utiliser et, tout aussi clairement, quand ne pas le faire.
Évitez le pattern quand :
- Le système est assez petit pour qu’une réécriture propre prenne des semaines, pas des mois. La charge de faire fonctionner deux systèmes en parallèle n’en vaut pas la peine.
- Vous ne pouvez pas intercepter les requêtes du système, ni utiliser une autre stratégie à deux systèmes. Si vous ne pouvez pas router le trafic, vous ne pouvez pas mettre une façade devant.
- Vous ne pouvez pas accéder au code source de l’ancien système, ni le modifier. Vous devez pouvoir rediriger les appels internes, ce qui implique de changer l’ancien système.
- Vous devez éteindre l’ancien système rapidement. Le strangler fig est délibéré et graduel, pas rapide.
Et soyez honnête sur le coût. Pendant un certain temps, vous faites fonctionner deux systèmes en même temps. Cela signifie plus de pièces mobiles, un vrai risque de dérive des données entre l’ancien et le nouveau, et un échéancier global plus long. Cela dit, les réécritures complètes se passent aussi rarement parfaitement et peuvent subir des retards importants quand des problèmes imprévus surviennent.
Le compromis est simple : vous acceptez plus de complexité et plus de temps en échange de beaucoup moins de risque. Pour un système dont votre exploitation dépend chaque jour, c’est généralement le bon compromis. Quand ce n’est pas le cas, et qu’un remplacement net ou un outil clé en main convient vraiment, c’est aussi une option réelle. Nous avons expliqué comment trancher cette question dans choisir le bon logiciel manufacturier.
Comment commencer : choisir le premier morceau
Commencez par une capacité à forte valeur et relativement indépendante. Isolez-la avec une couche de routage ou une autre approche à deux systèmes adaptée, confirmez que la transition et le retour en arrière fonctionnent comme prévu, puis répétez. L’élan d’un projet de modernisation ne vient pas d’un plan parfait. Il vient du fait de terminer quelque chose de réel.
Deux éléments guident le premier choix. D’abord, allez là où le retour est le plus élevé. Le pattern vous permet de séquencer le travail, pour remplacer d’abord les morceaux qui rapportent le plus vite. Ensuite, choisissez un morceau aux frontières nettes, quelque chose que vous pouvez extraire sans tout déstabiliser autour.
Il y a un problème dont personne ne vous avertit, et c’est celui qui arrête la plupart des projets de modernisation des PME avant même qu’ils commencent : plus personne dans l’entreprise ne comprend entièrement l’ancien système. Les personnes qui l’ont construit sont parties. La documentation est un dossier auquel personne ne fait confiance. Le strangler fig est particulièrement brillant ici, parce que vous n’avez pas besoin de rétro-ingénierer tout le système avant de commencer. Vous enveloppez un morceau, vous observez comment il se comporte réellement en production, et vous apprenez le système en le remplaçant, une tranche observée à la fois.
Ce n’est pas de la théorie. TAG, qui maintient en service des unités de récupération de véhicules volés, gérait auparavant le cycle de vie de ces unités et chaque contrat de service sur un ancien ERP local, conçu pour un seul poste de travail, pas pour un réseau mobile de techniciens et de partenaires.
Plutôt que de le remplacer d’un coup, le travail s’est fait fonctionnalité par fonctionnalité vers un système web moderne, en commençant par le morceau qui comptait le plus sur le terrain : une interface tablette qui permet aux techniciens d’installation de saisir et de récupérer l’information de contrat sur place, avec les concessionnaires et revendeurs à venir ensuite. Chaque fonctionnalité a migré selon son propre échéancier, et le personnel a continué à travailler dans l’ancien ERP pour tout ce qui n’avait pas encore basculé. Aucun gel, aucune fin de semaine de bascule, juste un flux de travail remplacé à la fois pendant que l’entreprise continuait de tourner.
Si cela ressemble à votre situation, l’ERP ou le MES coûteux que votre équipe exporte encore vers Excel chaque matin, nous en avons parlé exactement dans vous avez investi 400 000 $ dans un ERP ou un MES… alors pourquoi les équipes vivent-elles encore dans Excel.
À quoi ressemble une bonne exécution
Vous faites bien les choses quand chaque étape est observable, réversible, et livre une vraie valeur par elle-même, pas quand vous avez dessiné l’architecture cible parfaite sur un tableau blanc.
Les signaux sont concrets. Le trafic bascule de l’ancien vers le nouveau selon l’échéancier que vous avez fixé. Lorsqu’un retour en arrière est nécessaire, il se fait rapidement et sans drame. Chaque tranche migrée livre une amélioration opérationnelle réelle que votre équipe peut ressentir, pas juste un schéma plus propre. Et l’empreinte du système existant continue de rétrécir, mois après mois, jusqu’à ce qu’un jour il ne reste plus rien à éteindre. Observable, réversible, durable. Si une étape n’a aucune de ces qualités, elle n’est pas encore prête.
La voie du milieu, pragmatique
Vous n’avez pas à choisir entre vous accommoder du système qui vous ralentit et parier l’entreprise sur une réécriture qui pourrait échouer. Vous pouvez remplacer l’ancien système un morceau réversible à la fois, continuer à fonctionner tout au long, et voir de la valeur bien avant que le dernier morceau ne soit terminé.
La stratégie est simple à décrire mais réellement difficile à exécuter. La partie difficile, c’est de choisir le premier morceau, d’envelopper l’ancien système sans casser ce qui fonctionne déjà, et de garder les deux mondes synchronisés pendant que vous avancez. Si vous voulez un partenaire qui fait ça à côté de votre équipe, et qui reste dans l’équipe plutôt que de disparaître pendant six mois, parlons-en. Pas de pression, pas de big-bang. Juste le prochain morceau, bien fait.
Nous sommes là pour faire de vos projets de logiciels une réalité
Développement de logiciels sur mesure.
FAQ
Le terme a été inventé par Martin Fowler, qui l’a nommé d’après l’arbre étrangleur (strangler fig) qui pousse autour d’un arbre hôte et le remplace graduellement.
Non. C’est une stratégie de migration, pas une technologie spécifique. Elle fonctionne aussi bien pour les monolithes, les logiciels standards et les systèmes sur site que pour les microservices infonuagiques. L’idée centrale, remplacer un système de l’extérieur une capacité à la fois, s’applique partout où vous pouvez router les requêtes.
Plus longtemps qu’une réécriture complète hypothétiquement parfaite, et bien moins longtemps qu’une réécriture ratée. Il n’y a pas de chiffre universel, parce que l’échéancier est calibré selon la complexité et l’enchevêtrement de votre système. Quiconque vous donne une durée fixe sans avoir vu votre système ne fait que deviner.
Le refactoring améliore le code en place sans changer ce qu’il fait. Le strangler fig remplace et améliore le système de l’extérieur, capacité par capacité, jusqu’à ce que l’ancien disparaisse. Le refactoring nettoie la maison où vous vivez; le strangler fig construit une nouvelle maison autour, une qui correspond à votre nouvelle réalité et soutient la croissance future, puis vous y installe une pièce à la fois.
