Votre application a cinq ans. Elle fonctionne, mais la moindre nouvelle fonctionnalité prend trois fois plus de temps qu'avant. Les développeurs qui l'ont construite sont partis. La stack est obsolète. Et un jour, quelqu'un dans l'équipe lâche la phrase fatidique : "Il faudrait tout réécrire."
C'est un moment charnière. La décision qui suit va conditionner des mois de travail, un budget conséquent et la continuité de votre activité. Réécrire de zéro promet un nouveau départ, mais les risques sont réels. Moderniser par étapes semble plus prudent, mais est-ce toujours suffisant ?
Autant le dire d'entrée : dans la majorité des cas qu'on rencontre, la refonte totale est une erreur. Mais pas toujours. Cet article vous donne les critères pour savoir dans quelle catégorie vous tombez.
La tentation de la refonte totale 🔥
Pourquoi on en arrive là
La refonte totale naît d'une frustration accumulée. Le code est devenu un plat de spaghetti. Une correction introduit deux nouveaux bugs. Les développeurs passent plus de temps à contourner l'existant qu'à construire quoi que ce soit d'utile. La dette technique s'est empilée au fil des années, et un jour, le système craque.
Les signes avant-coureurs sont souvent les mêmes :
- Les temps de développement ont triplé en deux ans
- Plus personne ne comprend certaines parties du code
- Les incidents de production sont de plus en plus fréquents
- Le recrutement est difficile parce que la stack fait fuir les candidats
- Les demandes métier simples deviennent des chantiers de plusieurs semaines
Les promesses séduisantes
"On repart sur de bonnes bases." "On choisit une stack moderne." "En six mois, c'est réglé." Ces phrases reviennent dans toutes les réunions de lancement d'une refonte. Et elles sont sincères. Le problème, c'est qu'elles sous-estiment systématiquement la complexité de l'existant.
Une application en production depuis cinq ans, c'est des centaines de règles métier. Certaines sont documentées. Beaucoup sont enfouies dans le code, fruit de correctifs successifs pour gérer des cas particuliers que personne ne se rappelle. Réécrire, c'est redécouvrir chacune de ces règles, une par une.
Le "second system effect"
Frederick Brooks l'a décrit dans The Mythical Man-Month : la deuxième version d'un système tend à être sur-conçue. L'équipe, libérée des contraintes de l'ancien code, veut tout améliorer en même temps. On ajoute des abstractions, on anticipe des besoins futurs, on construit une "architecture parfaite". Le projet enfle. Six mois deviennent douze, puis dix-huit.
Pendant ce temps, l'ancienne application continue de tourner. Elle reçoit des correctifs urgents qui creusent l'écart avec la nouvelle version. Quand la refonte est enfin prête, elle ne couvre que 70 % des fonctionnalités existantes. L'équipe métier découvre des régressions. La migration traîne. Le budget initial a doublé.
Ce scénario n'est pas un cas extrême. C'est le scénario le plus fréquent des refontes totales.
Quand la refonte est vraiment justifiée
Malgré ces risques, il existe des situations où réécrire est la seule option raisonnable :
- La stack est morte : le langage ou le framework n'est plus maintenu, les failles de sécurité ne sont plus corrigées, impossible de recruter
- L'architecture est incompatible avec les nouveaux besoins (passer d'un monolithe rigide à une application distribuée, par exemple)
- Le volume de dette technique dépasse la valeur du code : il coûte plus cher de maintenir l'existant que de reconstruire
- Le périmètre fonctionnel a changé radicalement : l'application d'aujourd'hui n'a plus grand-chose à voir avec ce qui a été construit à l'origine
La modernisation progressive : ce que ça veut dire concrètement 🔧
Le principe
Moderniser progressivement, c'est remplacer les pièces du moteur sans arrêter la voiture. L'application continue de fonctionner en production pendant que vous améliorez son architecture, sa qualité de code et ses performances, module par module.
L'idée : on améliore un bout, on vérifie que rien n'a cassé, on passe au suivant. Pas de big bang. Pas de date de migration qu'on repousse trois fois avant de la supprimer du calendrier.
Les approches
Le Strangler Fig Pattern. Inspiré du figuier étrangleur qui pousse autour d'un arbre existant jusqu'à le remplacer. Vous construisez les nouvelles fonctionnalités dans un nouveau système, et vous redirigez progressivement le trafic de l'ancien vers le nouveau. L'ancien système rétrécit jusqu'à disparaître.
Le refactoring incrémental. Vous restez dans la même base de code, mais vous restructurez le code existant par petits lots. Extraction de classes, découpage de fonctions trop longues, introduction de tests unitaires pour sécuriser les changements. Un commit à la fois, sans casser ce qui tourne.
La migration par modules. Vous identifiez les modules les plus problématiques et vous les remplacez un par un. Le module de facturation est ingérable ? Vous le réécrivez isolément, vous le connectez au reste via une API, et vous passez au suivant.
Les prérequis
La modernisation progressive ne fonctionne que si certaines conditions sont réunies :
- Des tests : sans filet de sécurité, la moindre modification est un pari. Commencez par ajouter des tests sur les parties critiques avant de toucher au code.
- Un minimum de documentation : les règles métier clés doivent être identifiées. Pas besoin d'un document de 200 pages, mais les flux principaux doivent être compris.
- Une CI/CD fonctionnelle : pouvoir déployer régulièrement et en confiance. Sans ça, vous allez accumuler du travail "en attente de mise en prod" et perdre le rythme.
- L'adhésion de l'équipe : la modernisation progressive demande de la discipline. Il faut accepter de consacrer une part de chaque sprint à l'amélioration de l'existant, pas seulement aux nouvelles fonctionnalités.
Quand la modernisation progressive est le bon choix
- L'application fonctionne et génère de la valeur, même si elle est pénible à maintenir
- Le budget ne permet pas d'arrêter le développement de fonctionnalités pendant 12 mois
- Les règles métier sont complexes et mal documentées (les redécouvrir prendrait trop de temps)
- L'équipe actuelle maîtrise la stack existante
- La tolérance au risque est faible (secteur réglementé, application critique)
Les 7 critères pour trancher 📊
On utilise ce tableau en interne quand on audite une application. Pour chaque ligne, regardez de quel côté votre situation penche.
| # | Critère | Penche vers la refonte | Penche vers la modernisation |
|---|---|---|---|
| 1 | État du code | Illisible, non structuré, aucune convention | Structuré mais vieillissant, conventions respectées |
| 2 | Couverture de tests | Aucun test, impossible d'en ajouter | Tests existants ou ajoutables facilement |
| 3 | Documentation métier | Règles métier bien connues de l'équipe | Règles enfouies dans le code, personne ne sait tout |
| 4 | Compétences sur la stack | Impossible de recruter, stack abandonnée | Développeurs disponibles, stack encore maintenue |
| 5 | Tolérance au risque | Peut se permettre une interruption de service | Application critique, zéro tolérance aux pannes |
| 6 | Budget et timeline | Budget disponible pour 12-18 mois de refonte | Budget contraint, besoin de résultats rapides |
| 7 | Complexité métier | Périmètre fonctionnel simple et bien compris | Domaine métier complexe, beaucoup de cas particuliers |
Comment lire ce tableau. Si la majorité de vos réponses tombent dans la colonne de gauche, la refonte est envisageable. Si elles tombent à droite, la modernisation progressive est le choix le plus sûr. En pratique, vous aurez des réponses des deux côtés, et c'est normal. Ce qui compte, c'est d'identifier les critères bloquants.
Le critère 3 (documentation métier) est souvent le plus sous-estimé. Si les règles métier ne sont connues que du code existant, une refonte revient à les redécouvrir à l'aveugle. C'est le scénario le plus dangereux.
Besoin d'y voir clair sur votre code ?
Quatre scénarios concrets 🎯
Scénario 1 : la startup post-MVP offshore
On voit ça régulièrement. Une startup fait développer son MVP par une équipe offshore pour valider son marché. Le produit trouve ses premiers clients. Bonne nouvelle. Sauf que le code n'a pas été pensé pour durer : pas de tests, pas de documentation, architecture monolithique fragile.
Dans ce cas, le périmètre fonctionnel est encore limité (c'est un MVP), donc le coût d'une réécriture reste raisonnable. On garde ce qui fonctionne (base de données, certains composants), on réécrit le reste avec une architecture propre, et on pose des tests dès le départ. Comptez 2 à 4 mois.
Scénario 2 : la PME avec un ERP vieillissant
Une PME industrielle utilise un ERP développé sur mesure il y a huit ans en PHP 5. Commandes, facturation, stocks, planification de production. Trois personnes l'utilisent au quotidien. Le développeur qui l'a construit est parti depuis longtemps.
L'application est lente, l'interface est datée, mais les règles métier sont correctement implémentées. Et c'est là le point important : ces règles métier, personne ne saurait les réécrire de mémoire. Lancer une refonte de 12 mois avec deux systèmes en parallèle, c'est chercher les ennuis.
Mieux vaut migrer de PHP 5 vers PHP 8 par étapes, refaire l'interface module par module, ajouter des tests automatisés au passage. En 12-18 mois, l'application est transformée sans avoir jamais mis la production en danger.
Scénario 3 : l'administration avec le développeur parti
Celui-là, c'est le plus stressant pour le client. Une collectivité territoriale, une application de gestion des demandes citoyennes, un développeur unique parti sans laisser de documentation. L'application tourne. Personne ne sait comment. Le moindre bug déclenche une crise.
Ici, la question "refonte ou modernisation" est prématurée. Avant tout, il faut comprendre ce qu'on a sous le capot. Audit technique, documentation des flux critiques, mise en place de tests sur les parcours principaux. Ça prend 2-3 mois. Après seulement, on peut décider quels modules moderniser et lesquels réécrire.
Scénario 4 : l'application critique en production
Plateforme SaaS B2B, 500 clients actifs, SLA engagés, 99,9 % de disponibilité attendue. L'architecture monolithique atteint ses limites de performance et l'équipe de 8 développeurs se marche dessus sur la même base de code.
Impossible d'arrêter la production. Impossible de dire aux clients "revenez dans six mois." C'est le cas d'usage classique du Strangler Fig : on identifie les modules à fort trafic (API publique, moteur de recherche, tableau de bord), on les reconstruit dans des services indépendants, et on redirige le trafic progressivement. L'ancien monolithe rétrécit sprint après sprint. C'est long (18-24 mois pour une migration complète), mais c'est le seul chemin qui ne met pas le business en danger.
L'approche hybride : le meilleur des deux mondes 🧩
En pratique, la réponse est rarement 100 % refonte ou 100 % modernisation. Les projets les plus réussis combinent les deux approches selon les modules.
La stratégie en trois temps
D'abord, stabiliser. Avant toute chose, sécurisez l'existant. Ajoutez des tests sur les parcours critiques, mettez en place du monitoring, documentez les règles métier essentielles. Cette phase dure 1 à 3 mois et réduit les incidents immédiatement. C'est aussi la phase qui rassure tout le monde : la direction voit que les choses bougent, l'équipe technique reprend confiance.
Ensuite, moderniser. Une fois l'application stabilisée, on attaque les modules les plus problématiques. Refactoring, mise à jour des dépendances, amélioration des performances. Sprint après sprint, la base de code rajeunit.
Enfin, remplacer ce qui doit l'être. Certains modules sont irrécupérables. Pour ceux-là, et seulement ceux-là, une réécriture ciblée se justifie. Mais à ce stade, vous avez des tests, vous avez de la documentation, vous savez exactement ce que le module fait. La réécriture se passe dans un cadre maîtrisé. Rien à voir avec un "on jette tout et on recommence."
L'audit technique comme point de départ
On le répète à chaque prospect qui nous appelle avec l'envie de "tout réécrire" : commencez par un audit. Un audit technique donne une photographie factuelle de l'état du code. Qualité, dette technique, couverture de tests, risques de sécurité, dépendances obsolètes. Ça prend quelques jours, et ça évite des mois de travail dans la mauvaise direction.
C'est à partir de ce diagnostic qu'on construit un plan d'action. Pas avant.
Par où commencer 🚀
Étape 1 : l'audit technique
Un audit sérieux produit un livrable concret :
- Cartographie de l'application : modules, dépendances, flux de données
- Évaluation de la dette technique : scoring par module, identification des points critiques
- Analyse de sécurité : vulnérabilités connues, dépendances obsolètes
- Recommandations priorisées : ce qu'il faut traiter en premier, ce qui peut attendre
Ce n'est pas un document théorique qui finit dans un tiroir. C'est une feuille de route.
Étape 2 : le plan d'action priorisé
À partir de l'audit, on définit ce qu'on traite en premier, avec quelle approche (refactoring, réécriture, migration), pour quel budget et quel calendrier. Le genre de document qu'un DSI peut poser sur la table de son comité de direction avec une réponse claire à : "Combien ça coûte, et qu'est-ce qu'on obtient quand ?"
Étape 3 : les premières victoires rapides
Mises à jour de sécurité, correction des bugs les plus visibles, amélioration des temps de chargement. Des interventions à faible risque qui produisent des résultats en quelques semaines, pas en quelques mois. C'est ce qui maintient la confiance de toute l'organisation pendant que le gros du travail avance en coulisses.
Soyons honnêtes : la plupart des projets de refonte totale qu'on nous présente n'en ont pas besoin. La frustration pousse à vouloir tout jeter, mais le vrai problème est rarement le code en entier. C'est souvent deux ou trois modules qui pourrissent la vie de tout le monde, pendant que le reste fait son travail correctement.
La pire décision, c'est de ne pas décider. De laisser l'application se dégrader en croisant les doigts pour que ça tienne.
Si votre application montre des signes de fatigue, commencez par regarder ce que vous avez vraiment. Un audit technique, quelques jours de travail, et vous saurez exactement où vous en êtes et par quoi commencer. Parlons-en.
