Réécriture complète vs migration progressive : comment choisir ?

#Le piège de la réécriture totale : pourquoi 60% des projets big bang échouent

La réécriture complète est la réponse instinctive quand une application legacy devient douloureuse à maintenir. Le raisonnement est séduisant : le code actuel est illisible, la dette technique est trop lourde, les développeurs perdent du temps sur des correctifs au lieu de créer de la valeur. Repartons de zéro avec un stack moderne, des bonnes pratiques, une architecture propre.

Le problème est que ce raisonnement ignore un fait fondamental : le code legacy fonctionne. Il encode des années de décisions métier, de cas limites, de corrections de bugs, de règles de gestion découvertes en production. Cette connaissance est rarement documentée. Elle vit dans le code, dans les tests, dans les procédures de contournement des équipes métier.

Joel Spolsky a formalisé ce constat dès l'an 2000 dans son article désormais classique "Things You Should Never Do, Part I" : le code qui a l'air laid a souvent une raison d'exister. Chaque ligne bizarre est probablement un patch pour un bug découvert en production. Réécrire depuis zéro, c'est jeter cette connaissance et s'exposer à redécouvrir les mêmes bugs.

Les données empiriques confirment cette analyse. Le Standish Group estime que les projets de réécriture complète de plus de 12 mois ont un taux d'échec de 60% à 70% — échec défini comme un dépassement budgétaire de plus de 100%, un dépassement calendaire de plus de 50%, ou un abandon pur et simple. Les causes les plus fréquentes : sous-estimation du périmètre fonctionnel, régression des cas limites, perte de la connaissance métier.

L'exemple le plus célèbre reste Netscape Navigator : la réécriture totale du navigateur a pris 3 ans au lieu de 12 mois prévus, laissant le champ libre à Internet Explorer. Plus récemment, un éditeur SaaS français a tenté de réécrire son ERP de gestion commerciale (PHP 5.6, 280 000 lignes) en Go + React. Après 18 mois et à partir de 307,2 M€, le projet couvrait 40% des fonctionnalités de l'ancien système. L'équipe a finalement opté pour une migration progressive du système existant.

#La migration progressive : le strangler fig en pratique

La migration progressive, formalisée par Martin Fowler sous le nom de strangler fig pattern, prend l'approche inverse. Au lieu de construire un système entièrement nouveau en parallèle, vous remplacez l'ancien système pièce par pièce.

Le principe repose sur trois mécanismes :

Un routeur qui distribue le trafic. Devant l'application legacy, vous placez un reverse proxy (Nginx, Kong, AWS ALB) qui dirige chaque requête soit vers l'ancien système, soit vers le nouveau composant. Au départ, 100% du trafic va vers le legacy. Au fur et à mesure des migrations, le pourcentage bascule.

Des modules indépendants qui coexistent. Chaque module migré fonctionne en autonomie, avec ses propres données, ses propres tests, son propre cycle de déploiement. Les modules non migrés continuent de fonctionner sur l'ancien système sans modification.

Une synchronisation des données maîtrisée. Pendant la phase de coexistence, les données doivent rester cohérentes entre l'ancien et le nouveau système. On utilise généralement un event bus (Kafka, RabbitMQ) ou un mécanisme de dual-write pour maintenir cette cohérence.

Cette approche a un avantage décisif : elle réduit le risque à chaque itération. Si un module migré pose problème, vous pouvez rollback en reroutant le trafic vers l'ancien système en quelques secondes. Vous ne jouez jamais l'avenir de l'entreprise sur un basculement unique.

L'inconvénient principal est la complexité de la coexistence. Maintenir deux systèmes en parallèle a un coût : infrastructure double, synchronisation de données, complexité du routage. Ce coût représente typiquement 20% à 30% du budget total de la migration. C'est le prix de la sécurité.

#La grille de décision : 7 critères objectifs

Plutôt que de choisir par intuition ou par préférence technologique, voici 7 critères factuels pour guider la décision.

1. Taille du codebase. Moins de 30 000 lignes : la réécriture est envisageable. Plus de 100 000 lignes : la migration progressive est quasi systématiquement préférable. Entre 30 000 et 100 000 : les autres critères départagent.

2. Couverture de tests. Si la couverture de tests automatisés est supérieure à 60%, la réécriture est plus sûre car les tests servent de spécification. Si la couverture est inférieure à 20%, la réécriture est très risquée car vous ne saurez pas quoi valider.

3. Documentation fonctionnelle. Les règles métier sont-elles documentées dans un cahier des charges à jour, ou vivent-elles exclusivement dans le code ? Dans le second cas, la migration progressive est plus sûre car elle préserve le code existant pendant la transition.

4. Tolérance à l'interruption. Votre activité peut-elle supporter une période de basculement (quelques heures à quelques jours) ? Si chaque minute d'indisponibilité coûte des milliers d'euros de chiffre d'affaires, la migration progressive est la seule option viable.

5. Budget disponible. La réécriture complète demande un investissement initial plus important car les deux systèmes doivent coexister jusqu'au basculement final. La migration progressive permet de lisser l'investissement sur 12 à 36 mois.

6. Stabilité de l'équipe. La réécriture nécessite une équipe dédiée stable pendant toute la durée du projet (12 à 24 mois). Si vous anticipez du turnover, la migration progressive est plus résiliente car chaque module est un projet autonome.

7. Complexité du domaine métier. Plus le domaine métier est complexe (réglementaire, financier, logistique avec des centaines de cas limites), plus la réécriture est risquée. Les cas limites découverts en production sur l'ancien système seront redécouverts un par un sur le nouveau — à vos frais.

#L'approche hybride : le meilleur des deux mondes

Dans la pratique, les projets Nehos empruntent rarement un chemin purement big bang ou purement strangler fig. L'approche la plus efficace est souvent hybride.

La stratégie frontend-first. Réécrivez le frontend en architecture headless (Next.js, Nuxt) en consommant les API de l'ancien backend. Cette réécriture est relativement sûre car le frontend est par nature découplé de la logique métier. Une fois le frontend migré, attaquez le backend en mode strangler fig, module par module. Cette séquence a été appliquée avec succès sur un monolithe PHP Symfony 2 avec 12 ans de dette technique. Le frontend a été migré en 4 mois, le backend en 18 mois.

La stratégie domain-driven. Identifiez les bounded contexts de votre application via un exercice de domain mapping. Les domaines faiblement couplés et bien définis peuvent être réécrits (micro-réécriture ciblée). Les domaines fortement couplés et complexes sont migrés progressivement. Cette approche demande un effort de conception initial (event storming, context mapping) mais produit une architecture cible cohérente.

La stratégie évaluation continue. Démarrez en mode migration progressive sur 2 à 3 modules pilotes. Mesurez le coût réel de la coexistence et de la synchronisation des données. Si ce coût est supérieur à 40% du budget total, réévaluez l'option de réécriture pour les modules restants. Cette approche data-driven est celle que nous recommandons le plus souvent aux ETI qui démarrent leur premier projet de modernisation legacy.

#Cas d'usage réels : quand le choix a fait la différence

Cas 1 — ETI logistique, 140 000 lignes PHP, choix de la migration progressive. Une entreprise de logistique opérait un TMS (Transport Management System) développé en PHP 5.6 avec Zend Framework 1. L'application gérait 2 000 commandes par jour avec des règles de routage complexes (plus de 300 combinaisons de critères). L'équipe a tenté une réécriture en Node.js pendant 8 mois avant de constater que seulement 35% des règles de routage avaient été reproduites correctement. Décision : abandon de la réécriture, passage en mode strangler fig. Le module de tracking (le plus simple) a été migré en premier, suivi du module de facturation, puis des règles de routage — module par module, en validant chaque brique avec les équipes métier. Durée totale : 28 mois. Zéro interruption de service.

Cas 2 — Startup fintech, 18 000 lignes Ruby on Rails, choix de la réécriture. Une startup de 15 personnes opérait une plateforme de paiement sur Ruby on Rails 5.2. L'application était bien testée (couverture 72%), bien documentée et servait un trafic faible (200 requêtes par minute). L'équipe a réécrit l'application en NestJS + TypeScript en 14 semaines, avec un basculement planifié sur un week-end. Le choix de la réécriture était justifié par la petite taille du codebase, la couverture de tests élevée et la tolérance à une fenêtre d'interruption de 48 heures.

Cas 3 — Groupe industriel, ERP SAP ECC 6.0, choix de la migration progressive. Un groupe de 800 collaborateurs devait migrer un SAP ECC 6.0 avant la fin du support mainstream en 2027. La réécriture complète était estimée à 64 M€ et 18 mois. L'équipe a opté pour un strangler fig : extraction du portail fournisseurs en premier (16 semaines), puis des modules de reporting, de gestion des stocks et de facturation sur 36 mois. Coût total : 38,4 M€ — soit 40% de moins que le devis big bang. Zéro interruption de service.

#Le coût caché de la non-décision

Le pire choix n'est ni la réécriture ni la migration progressive — c'est de ne rien faire. Les entreprises qui repoussent la décision de modernisation accumulent une dette technique dont le coût croît exponentiellement.

Chaque mois de report signifie des développeurs qui passent 30% à 50% de leur temps sur de la maintenance corrective au lieu de créer de la valeur. Chaque année qui passe rend le recrutement plus difficile car les candidats compétents refusent de travailler sur des stacks obsolètes. Chaque CVE non patchée augmente le risque de faille de sécurité.

Le diagnostic de 4 à 6 semaines que Nehos propose comme point de départ n'est pas un luxe — c'est l'investissement qui permet de choisir la bonne stratégie avec des données factuelles plutôt que des opinions. Ce diagnostic produit une cartographie du codebase, une évaluation de la dette technique par module, une estimation budgétaire pour chaque option et une recommandation argumentée.

#Recommandation Nehos : la règle des 80/20

Après avoir accompagné plus de 40 projets de modernisation legacy, notre recommandation se résume à une règle simple.

Dans 80% des cas, la migration progressive est le bon choix. Elle réduit le risque, lisse le budget, maintient la continuité de service et permet de valider chaque étape avec les équipes métier.

Dans 20% des cas — petits systèmes bien testés, équipe stable, fenêtre d'interruption acceptable — la réécriture est justifiée. Elle est plus rapide, produit un codebase plus propre et élimine toute dette technique résiduelle.

Le diagnostic initial est la clé. Sans données factuelles sur la taille du codebase, le couplage entre modules, la couverture de tests et la complexité du domaine métier, le choix de la stratégie est un pari. Avec ces données, c'est une décision informée.

Nehos propose un service de modernisation legacy qui commence systématiquement par ce diagnostic. Si vous hésitez entre réécriture et migration progressive, notre guide du strangler fig pattern détaille la méthodologie de migration progressive que nous appliquons le plus fréquemment.