Un industriel français nous appelle en mai 2025. Leur ERP interne — VB.NET, 3,2 millions de lignes, 47 projets imbriqués, codé entre 2003 et 2014 — vient de planter en production pour la troisième fois en six mois. L'unique développeur qui le maintient encore part à la retraite dans dix-huit mois. Le DSI a déjà reçu trois propositions commerciales pour une « réécriture moderne avec IA » à 1,2 M€, 2,8 M€ et 4,5 M€. Aucune ne le rassure. Notre proposition : pas de réécriture, une méthode en quatre phases qui combine cartographie automatique, filet de tests, strangler fig et IA — pour 680 k€ étalés sur 24 mois, avec valeur livrée tous les trimestres. Voici cette roadmap, ses chiffres réels, et là où l'IA accélère vraiment vs où elle ne sert à rien.
Pourquoi les réécritures « big bang » échouent (et pourquoi l'IA n'y change rien)
L'instinct face à un legacy critique est de tout réécrire. C'est l'erreur la plus coûteuse en transformation digitale. Les chiffres du Standish Group sur 15 ans de projets de réécriture > 1 M€ : 35 % livrent, 19 % livrent en retard et incomplet, 46 % sont abandonnés.
L'IA en 2026 n'a pas changé ce ratio fondamentalement. Elle a juste rendu plus tentantes les promesses de réécriture rapide — sans réduire les vrais risques :
| Risque big bang | Mitigé par l'IA ? |
|---|---|
| Périmètre fonctionnel mal compris | Non |
| Régressions invisibles en prod | Non |
| Coupure de service pendant la bascule | Non |
| Perte de connaissance métier des seniors | Partiellement |
| Coût qui dérive (× 2 à × 5) | Non |
| Décisions archi sans vraie info | Partiellement |
Les deux risques que l'IA atténue (perte de connaissance, manque d'info archi) sont les seuls cas où elle aide réellement — et ils sont dans la phase de cartographie, pas la phase d'écriture du nouveau code.
La méthode que nous appliquons inverse la logique : pas de big bang, une migration progressive et continue. L'IA accélère les phases où elle est forte, les humains gardent le contrôle où elle est faible.
La roadmap en 4 phases : ce qu'on livre, dans quel ordre
Voici la décomposition que nous appliquons systématiquement chez les clients ayant un legacy critique à moderniser. Chiffres réels d'un projet client (ERP industriel VB.NET, 3 M lignes, équipe de 6 devs sur 24 mois).
Phase 1 — CARTOGRAPHIE 2 à 4 semaines
Phase 2 — FILET DE TESTS 4 à 8 semaines
Phase 3 — STRANGLER FIG 3 à 18 mois (par module)
Phase 4 — DÉCOMMISSION 3 à 6 mois| Phase | Durée typique | Coût indicatif | Risque résiduel |
|---|---|---|---|
| 1 — Cartographie | 2–4 semaines | 25–60 k€ | Faible |
| 2 — Filet de tests | 4–8 semaines | 40–120 k€ | Faible |
| 3 — Strangler fig | 3–18 mois | 200–800 k€ | Moyen |
| 4 — Décommission | 3–6 mois | 50–150 k€ | Très faible |
L'enchaînement est non-négociable. Sauter la cartographie pour aller directement au strangler fig, c'est partir refondre un module sans savoir s'il a 12 ou 470 dépendances entrantes. Sauter le filet de tests, c'est faire la migration sans aucun moyen de détecter les régressions.
Phase 1 — Cartographie automatique du legacy
Avant de toucher une ligne, vous devez comprendre ce que vous avez. C'est la phase où l'IA accélère le plus — facteur 5 à 10× selon nos mesures.
L'objectif : transformer 3 M lignes en carte navigable
Vous parsez tout le code source (AST par langage), extrayez les classes, fonctions, appels inter-fichiers, dépendances externes. Vous obtenez un graphe de dépendances brut. Sur ce graphe, vous appliquez du clustering pour identifier les domaines métier naturels :
- Module Facturation : 234 fichiers, fortement couplés ensemble, faiblement liés au reste
- Module Commandes : 189 fichiers
- Module Reporting : 121 fichiers
- Module Authentification : 45 fichiers, très réutilisé partout
Cette cartographie automatique remplace 4 à 6 semaines de rétro-ingénierie manuelle. Sur le client industriel évoqué en intro, on a sorti 47 000 définitions et 189 000 relations en 3 jours d'analyse statique. Sans IA, c'était 3 mois.
Les artéfacts à produire absolument
| Artéfact | Utilité downstream |
|---|---|
| Graphe de dépendances complet | Décision d'ordre de migration |
| Identification des domaines métier | Découpage en modules stranglerables |
| Hot spots de couplage | Modules à laisser pour la fin |
| Fichiers « God class » | Refacto prioritaire |
| Code mort (% du total) | Suppression sans risque |
Sur les 3 M lignes du client industriel, 18 % étaient du code mort jamais appelé en production. Identifié par analyse statique + traces runtime, supprimé en deux semaines, ça a réduit la dette migrable de 540 000 lignes.
Phase 2 — Le filet de tests : votre assurance régression
C'est la phase la plus négligée et la plus critique. Sans tests qui caractérisent le comportement actuel, toute migration est aveugle. Avec, vous avez un détecteur de régression automatique.
Approche : génération de tests de caractérisation
Vous n'écrivez pas des tests « idéaux » — vous écrivez des tests qui figent le comportement actuel, bug compris. C'est l'idée des tests de caractérisation (Michael Feathers, Working Effectively with Legacy Code).
L'IA accélère cette phase de 3 à 5×. Pattern :
- Capture du trafic réel en production (requêtes + réponses) sur 2-4 semaines
- Génération automatique de tests via LLM (Claude Sonnet bon à ça) : pour chaque endpoint, un test qui rejoue la requête et compare la réponse byte-à-byte
- Couverture cible : 60 % du code de production, 95 % des cas d'usage métier critiques
Sur le projet ERP, on est passé de 3 % de coverage initial à 71 % en 6 semaines. Sans IA, on aurait mis 6 mois.
Les seuils à respecter avant de passer à la phase 3
| Indicateur | Seuil minimal |
|---|---|
| Coverage code production | 60 % |
| Cas métier critiques testés | 95 % |
| Tests qui passent à l'identique | 100 % |
| Temps d'exécution suite complète | < 30 min |
Si vous démarrez la phase 3 sans atteindre ces seuils, attendez-vous à des incidents en production. Le filet de tests n'est pas optionnel.
Phase 3 — Strangler fig : la migration progressive
Le pattern strangler fig (Martin Fowler) consiste à faire grandir progressivement le nouveau système autour de l'ancien, en redirigeant peu à peu le trafic. À la fin, l'ancien est étouffé et peut être désactivé.
L'architecture transitionnelle
Vous mettez un routeur devant le legacy. Ce routeur dirige les requêtes vers l'ancien ou le nouveau code selon une règle (par module, par feature flag, par % de trafic). Pour chaque module à moderniser :
- Reécriture du module en stack moderne (Go, TypeScript, Rust selon votre cible)
- Tests de parité : pour 1 000 requêtes réelles, le nouveau code doit donner exactement les mêmes réponses que l'ancien
- Bascule progressive : 5 % → 25 % → 50 % → 100 % du trafic, avec rollback instant si KPI dégradés
- Suppression du code legacy de ce module une fois 100 % bascule réussie
Là où l'IA aide vraiment en phase 3 (et où elle ne sert pas)
| Tâche | Apport IA réel |
|---|---|
| Compréhension code legacy à migrer | × 5–10 |
| Génération de tests de parité | × 3–5 |
| Refacto syntaxique (VB.NET → C#) | × 2–3 |
| Conversion d'idiomes complexes | × 1,5 |
| Décisions d'architecture | × 1 (rien) |
| Définition des contrats d'API | × 1 (rien) |
| Validation métier avec utilisateurs | × 1 (rien) |
Les décisions structurantes restent humaines. L'IA fait le travail répétitif. Sur le projet ERP, l'équipe de 6 devs a livré l'équivalent de 12 ETP en productivité, mais sur les phases d'écriture, pas sur les phases de design.
Anti-pattern : le Big Bang déguisé
Beaucoup d'équipes abordent la phase 3 comme un strangler fig sur le papier, mais en pratique elles refondent tous les modules en parallèle pour aller plus vite. C'est le pire des deux mondes : complexité du strangler + risque du big bang.
Règle stricte : un module à la fois, jusqu'à 100 % bascule, avant de démarrer le suivant. Le rythme parait lent, il est durable.
Phase 4 — Décommissionnement : l'éteindre proprement
La phase la moins glamour, la plus politique. Une fois les modules migrés, il reste à éteindre l'ancien système. C'est le moment où des comportements oubliés ressurgissent (« mais le batch de fin de mois utilise encore le module B ! ») et où il faut refuser les régressions de scope.
Checklist de décommissionnement
| Étape | Critère de validation |
|---|---|
| Trafic legacy = 0 sur 30 jours | Logs serveur |
| Pas de batch/cron qui appelle l'ancien | Audit cron |
| Données critiques migrées et auditées | Tests de cohérence |
| Documentation moderne complète | Onboarding nouveau dev en < 1 sem. |
| Backup légal de l'ancien (3-7 ans) | Conformité réglementaire |
| Décommission infrastructure (VM, DB) | Économies infra mesurables |
Sur le projet ERP, la phase 4 a duré 5 mois — plus long que prévu, parce qu'on a découvert 3 batches mensuels et un connecteur SAP que personne n'avait répertoriés. Tout legacy a ce genre de surprises ; prévoyez 30 % de marge sur la durée de cette phase.
Edge cases : où la roadmap doit s'adapter
Cas 1 : legacy sans tests possibles à générer
Certains systèmes ne peuvent pas être testés en isolation : forte dépendance hardware, base de données partagée non réinitialisable, intégration externe critique. Solution alternative : mode shadow — vous faites tourner les deux systèmes en parallèle sur le trafic réel, vous comparez les outputs, vous loguez les divergences. Plus lent à mettre en place, mais c'est la seule option.
Cas 2 : pas de budget 24 mois, juste 6 mois pour stabiliser
Cas fréquent : direction qui veut « juste arrêter les bugs » sans budgéter une vraie modernisation. Stratégie adaptée : phase 1 (cartographie) + phase 2 partielle (tests de caractérisation sur le top 20 % des bugs) + amélioration ciblée des modules les plus douloureux. Vous gagnez du temps sans démarrer la migration. Coût : 4-6 mois, 150 k€ environ. Vous repartez sur un pied stabilisé pour décider de la suite.
Cas 3 : techno legacy non supportée par l'outillage moderne
VB6, Cobol des années 80, Delphi 5, MUMPS… L'AST n'est pas dispo dans tree-sitter, le LLM n'a pas vu beaucoup de code dessus, les outils de migration n'existent pas. La phase 1 prend 2× plus de temps. Le tooling spécifique se construit. Mais la méthode tient.
| Situation | Adaptation roadmap |
|---|---|
| Stack moderne (Java, .NET, Python) | Méthode standard |
| Stack ancienne mais documentée (VB.NET) | +30 % durée phase 1 |
| Stack obscure (MUMPS, Delphi 5) | +100 % durée phase 1 + 2 |
| Pas de filet de tests possible | Mode shadow obligatoire |
| Budget < 6 mois | Phase 1 + 2 partielle seulement |
Ce qu'il faut retenir
Trois règles, dans cet ordre :
- Pas de réécriture big bang. 46 % d'échec en moyenne. Strangler fig ou rien.
- Cartographie + tests AVANT toute migration. Sans ces deux artéfacts, vous êtes aveugle.
- L'IA accélère les phases répétitives, pas les décisions. Phase 1 et 2 : x5-10. Phase 3 : x1.5-3. Phase 4 : x1.
Pour aller plus loin :
- Working Effectively with Legacy Code (Michael Feathers) — la référence sur les tests de caractérisation
- Article Martin Fowler sur le pattern Strangler Fig
- Standish Group CHAOS Report — données sur les taux d'échec des réécritures
Conclusion
L'industriel évoqué en intro a livré sa modernisation à 24 mois pour 680 k€. La proposition concurrente à 1,2 M€ promettait 12 mois — abandonnée par l'autre prospect au mois 14, perte sèche estimée 800 k€. La modernisation legacy n'est pas un sujet d'IA, c'est un sujet de méthode. L'IA accélère les bonnes phases ; elle ne remplace pas la rigueur d'ingénierie.
