Migrer un système legacy sans interruption de service — la méthode du strangler
Refondre un vieux système informatique pendant qu'il continue de tourner en production : la stratégie du strangler pattern, expliquée pour les dirigeants.
Le piège classique de la modernisation : on lance un grand projet de refonte "big bang", on prévoit 18 mois pour livrer, et au bout de 18 mois, on a deux systèmes — l'ancien (toujours en prod) et le nouveau (jamais utilisé).
Cette approche échoue 7 fois sur 10. La bonne méthode est très différente.
Le strangler pattern, en 30 secondes
L'idée vient de Martin Fowler et porte un nom imagé : la modernisation par étranglement progressif. Au lieu de remplacer le système legacy d'un coup, on construit un nouveau système par paliers, qui prend en charge une fonctionnalité à la fois, jusqu'à ce que l'ancien système n'ait plus rien à faire et puisse être éteint.
À chaque palier :
- On isole une fonctionnalité de l'ancien système
- On la redéveloppe dans le nouveau (en mieux)
- On bascule le trafic du legacy vers le neuf
- L'ancien système continue à servir le reste
Pendant toute la migration, les deux systèmes coexistent. L'utilisateur final ne voit pas la différence — sauf que l'expérience s'améliore palier par palier.
Pourquoi ça marche
Pas d'effet tunnel. À 3 mois, vous avez déjà du livrable en production. À 6 mois, une part significative du système est modernisée. Vous voyez la valeur s'accumuler en continu, pas dans un grand soir incertain.
Risque maîtrisé. Si un palier déraille, vous le corrigez ou vous le suspendez sans bloquer le reste. Le legacy continue de tourner.
Apprentissage progressif. Les premiers paliers (les plus simples) permettent à l'équipe de comprendre les vrais cas d'usage avant d'attaquer les zones complexes.
Possibilité d'arrêter. Si le contexte change (rachat, pivot, budget réduit), vous gardez les paliers déjà livrés. C'est de la valeur acquise, pas un projet abandonné.
Le piège : choisir le bon premier palier
Le premier palier détermine la confiance dans le projet. On le choisit avec deux critères :
- Visible : ses utilisateurs doivent voir le changement (ils deviennent les ambassadeurs du projet)
- Isolé : il ne dépend pas de tout le reste du système (sinon le premier palier devient un mini big-bang)
Mauvais premier palier : "On va commencer par refondre le moteur de calcul de facturation parce que c'est le plus important." C'est souvent la pire idée — c'est le plus risqué, le plus interconnecté, et l'utilisateur ne voit aucune différence.
Bon premier palier : "On va refaire l'écran de saisie des commandes parce que c'est celui qui irrite le plus les commerciaux." C'est isolé, visible, et la victoire est rapide.
Cas réel : modernisation d'un ERP de 2008
Sur un projet où l'ERP était impossible à faire évoluer, la migration strangler a été découpée en 7 paliers étalés sur 14 mois :
| Mois | Palier livré | Effet utilisateur |
|---|---|---|
| 0–2 | Module commandes | Saisie 2× plus rapide |
| 2–4 | Module stocks | Vision temps réel |
| 4–6 | Module facturation | Génération auto des factures |
| 6–8 | Reporting | Tableaux de bord en libre-service |
| 8–10 | Connexion comptable | Plus de double saisie |
| 10–12 | Module RH | Self-service congés |
| 12–14 | Migration des données historiques + extinction legacy | — |
À aucun moment l'activité n'a été interrompue. À 6 mois, 80 % de l'activité quotidienne passait déjà par le nouveau système.
Ce qu'il faut éviter
Geler le legacy pendant la migration. "On ne touche plus à l'ancien système, on attend la fin du nouveau." C'est presque toujours impossible en pratique : le métier continue d'évoluer, les bugs critiques arrivent. Acceptez de continuer à patcher l'ancien système jusqu'à son extinction.
Vouloir tout faire mieux d'un coup. Le strangler garde l'iso-fonctionnel au début. On améliore le code, l'architecture, la performance. On n'ajoute pas 50 nouvelles fonctionnalités en même temps — sinon on cumule les risques migration + nouveautés.
Sous-estimer la coexistence. Pendant 12 à 18 mois, deux systèmes tournent. Il faut prévoir une couche de synchronisation entre les deux (souvent une API ou un bus de messages). Cette couche disparaît à la fin, mais elle est essentielle pendant la migration.
Combien ça coûte
Une modernisation strangler coûte rarement moins qu'un big bang théorique. Mais elle coûte presque toujours moins qu'un big bang réel — parce que les big bangs explosent leur budget.
Comptez :
- Audit + plan de migration : 8 000 à 15 000 €
- Premier palier livrable : 4 à 8 semaines
- Migration complète : 6 à 18 mois selon la complexité
L'avantage budgétaire : les paliers s'absorbent dans le budget IT courant, ils ne nécessitent pas un investissement géant en une fois.
Pour qui c'est pertinent
Le strangler est adapté quand :
- Votre système legacy ralentit le métier mais reste critique
- Vous ne pouvez pas vous permettre une coupure de service
- Le big bang vous fait peur (à raison)
- Vous voulez voir des résultats tangibles avant la fin du projet