Votre application vieillit. L'interface est datée, le code est difficile à faire évoluer, les développeurs redoutent chaque mise en production. La question s'impose : faut-il tout reconstruire ou migrer progressivement ?
C'est l'un des arbitrages les plus coûteux en ingénierie logicielle. Une refonte mal calibrée peut immobiliser une entreprise pendant des mois. Une migration trop timide peut prolonger l'agonie d'un système qui ne répond plus aux besoins.
Cet article propose un cadre de décision concret, fondé sur l'expérience terrain, pour choisir la bonne approche selon votre contexte.
La refonte totale : promesse séduisante, risque élevé
Le fantasme de la page blanche
La refonte totale est tentante. On repart de zéro, avec des technologies modernes, une architecture propre, et la promesse de corriger toutes les erreurs du passé. C'est séduisant — et c'est souvent un piège.
Joel Spolsky l'a résumé il y a plus de 20 ans : réécrire un logiciel from scratch est « la pire erreur stratégique qu'une entreprise puisse commettre ». Pourquoi ? Parce que le code existant, aussi laid soit-il, contient des années de corrections de bugs, de cas limites gérés et de logique métier implicite. Repartir de zéro, c'est perdre tout ce savoir accumulé.
Quand la refonte échoue
Les causes d'échec sont récurrentes :
- Le périmètre explose — « tant qu'on refait tout, ajoutons aussi cette fonctionnalité ». Le projet double de taille
- Le legacy survit en parallèle — pendant la refonte, l'ancien système doit continuer à tourner et évoluer. Deux systèmes à maintenir, c'est le double de coûts
- Le budget dérape — une refonte estimée à 6 mois en prend 18. Le ROI initial ne tient plus
- L'équipe s'épuise — développer un produit entier sans rien livrer pendant des mois mine le moral
Quand la refonte se justifie malgré tout
Il existe des cas où la refonte totale est le bon choix :
- La stack est obsolète et non maintenable — PHP 5.6 sans framework, jQuery spaghetti, serveur en fin de vie. Le coût de maintenance dépasse le coût d'une reconstruction
- Le modèle métier a radicalement changé — l'application actuelle ne correspond plus du tout aux processus de l'entreprise
- Le périmètre est petit et bien défini — un outil interne simple, 10-20 écrans, pas de dépendances complexes
La migration progressive : plus lente, mais plus sûre
Le principe du strangler fig
La migration progressive s'inspire du strangler fig pattern : construire le nouveau système autour de l'ancien, module par module, en routant progressivement les utilisateurs vers les parties modernisées.
Chaque itération livre de la valeur. L'ancien système est décommissionné par morceaux. Il n'y a jamais de « big bang » risqué.
Les avantages concrets
- Risque maîtrisé — chaque module migré est testé et validé indépendamment. Un problème n'affecte pas l'ensemble
- Valeur livrée en continu — les utilisateurs bénéficient d'améliorations progressives, pas d'un basculement brutal
- Budget réaliste — chaque phase est estimée et livrée indépendamment. Pas d'effet tunnel
- Apprentissage progressif — l'équipe découvre les subtilités du legacy au fur et à mesure, plutôt que de tout redécouvrir d'un coup
Les limites de la migration progressive
La migration progressive n'est pas gratuite :
- Cohabitation technique — faire coexister ancien et nouveau système demande une couche de routage et des adaptateurs qui ont un coût
- Discipline nécessaire — sans gouvernance, la migration s'enlise. Les modules restants ne sont jamais migrés car « ils fonctionnent »
- Durée totale plus longue — la migration prend plus de temps au total, même si elle livre de la valeur plus tôt
Matrice de décision
L'approche hybride : refonte par domaines
En pratique, la meilleure stratégie est souvent un hybride : identifier les domaines fonctionnels du système, prioriser par impact métier, et reconstruire chaque domaine indépendamment — en commençant par ceux qui génèrent le plus de friction.
Ce n'est ni une refonte big bang, ni une migration timide. C'est une reconstruction pilotée par la valeur métier, avec des livrables concrets à chaque étape.
- Phase 1 — auditer l'existant, cartographier les domaines, identifier les dépendances et les points de douleur
- Phase 2 — reconstruire le domaine prioritaire avec une architecture moderne, tout en maintenant les interfaces avec le legacy
- Phase 3 — itérer domaine par domaine, en décommissionnant progressivement l'ancien système
Les erreurs classiques à éviter
- Reproduire l'existant à l'identique — si vous refaites exactement la même chose avec une stack moderne, vous n'avez rien gagné. Profitez-en pour questionner chaque fonctionnalité
- Sous-estimer la connaissance embarquée — ce bout de code bizarre qui gère un cas limite ? Il a été écrit après un bug en production un vendredi soir. Ne le supprimez pas sans comprendre pourquoi il existe
- Négliger la conduite du changement — une nouvelle application, c'est aussi de nouveaux processus pour les utilisateurs. Prévoyez formation et accompagnement
- Oublier le plan de décommissionnement — sans date de fin pour le legacy, vous maintiendrez deux systèmes indéfiniment
Notre recommandation
Dans la grande majorité des cas, nous recommandons la migration progressive ou l'approche hybride par domaines. Le risque est plus faible, le ROI est plus rapide, et l'entreprise n'est jamais paralysée par un chantier tunnel.
La refonte totale reste pertinente pour les petits systèmes ou quand le modèle métier a radicalement changé. Mais même dans ce cas, nous découpons en phases avec des livrables intermédiaires.
L'étape zéro est toujours la même : un audit technique qui cartographie l'existant et identifie la stratégie optimale. Sans cette étape, tout choix est un pari.