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

#Le piège de la réécriture totale : pourquoi tant de 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.

L'expérience du secteur confirme cette analyse : les projets de réécriture complète de longue durée dépassent très souvent leur budget et leur calendrier, voire sont abandonnés. 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, le scénario type se répète : un éditeur qui tente de réécrire son ERP de gestion commerciale en Go + React se retrouve, après de longs mois, avec une fraction seulement des fonctionnalités de l'ancien système, et finit par opter pour une migration progressive.

---

#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 est à budgéter dès le départ. 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 élevée, la réécriture est plus sûre car les tests servent de spécification. Si la couverture est très faible, 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 s'applique typiquement à un monolithe PHP Symfony 2 chargé de nombreuses années 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 devient disproportionné par rapport au 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.

---

#Exemples de situations : quand le choix fait la différence

Ces trois situations types sont construites pour illustrer les critères de décision. Ce ne sont pas des cas clients et elles ne comportent aucun résultat chiffré.

Situation 1 — Un TMS en PHP de grande taille : migration progressive. Une entreprise de logistique opère un TMS (Transport Management System) en PHP 5.6 avec Zend Framework 1, avec des règles de routage complexes. Une réécriture en Node.js reproduit mal ces règles de routage : le projet s'enlise.

La bonne décision : abandonner la réécriture et passer en mode strangler fig. Le module de tracking (le plus simple) est 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, sans interruption de service.

Situation 2 — Une petite plateforme de paiement en Rails : réécriture. Une startup opère une plateforme de paiement sur Ruby on Rails, bien testée, bien documentée et à trafic faible. Une réécriture en NestJS + TypeScript, avec un basculement planifié sur un week-end, se justifie : petite taille du codebase, couverture de tests élevée et tolérance à une fenêtre d'interruption.

Situation 3 — Un ERP SAP ECC 6.0 : migration progressive. Un groupe industriel doit migrer un SAP ECC 6.0 avant la fin du support mainstream. Une réécriture complète à devis big bang est risquée et coûteuse. Un strangler fig est préférable : extraction du portail fournisseurs en premier, puis des modules de reporting, de gestion des stocks et de facturation, sans 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 une part croissante 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 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 migration progressive d'abord

Notre recommandation se résume à une règle simple.

Dans la plupart 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 quelques 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.

Photos : Nowrin Sanjana, cottonbro studio sur Pexels.