Tout logiciel métier vieillit. Un jour, celui qui faisait tourner votre activité devient lent, rigide, difficile à faire évoluer — et le prestataire qui le connaissait n'est plus là. Vient alors la question qui angoisse tout dirigeant : faut-il tout réécrire, ou moderniser petit à petit ? C'est probablement la décision la plus lourde de conséquences de tout le projet.
Le big bang : réécrire tout d'un coup
L'idée est séduisante : abandonner le vieux système, repartir d'une base technique propre et moderne, livrer un nouveau logiciel flambant neuf le jour J. Sur le papier, c'est net. Dans la réalité, c'est l'approche qui échoue le plus souvent.
Le problème tient en une phrase : pendant toute la durée de la réécriture, vous payez deux systèmes et vous ne livrez aucune valeur. Six mois, un an, parfois plus, à reconstruire ce qui existe déjà, sans nouvelle fonctionnalité pour vos utilisateurs. Et le jour de la bascule concentre tous les risques sur une seule date : si le nouveau système a un défaut majeur, c'est toute votre activité qui s'arrête. Beaucoup de projets big bang sont abandonnés à mi-parcours, quand le budget est consommé et que le nouveau système n'est toujours pas prêt.
Il existe un piège supplémentaire, souvent sous-estimé : un vieux logiciel métier contient des années de règles métier accumulées — des cas particuliers, des exceptions, des comportements que plus personne ne documente mais dont dépend votre activité. Une réécriture complète oublie inévitablement une partie de ces règles, et ce sont vos utilisateurs qui les redécouvrent, une par une, en production.
Ce que disent les chiffres
Ce n'est pas qu'une intuition de praticien. Le Standish Group, qui étudie l'issue des projets informatiques depuis 1994 dans ses rapports CHAOS, a compilé sur la période 2011-2015 les résultats de plus de 25 000 projets logiciels. Le facteur le plus déterminant n'est ni la technologie ni la méthode : c'est la taille du projet. Les petits projets réussissent à 61 % et n'échouent que dans 7 % des cas ; les très grands projets ne réussissent qu'à 6 % et échouent dans 43 % des cas.
Le même rapport apporte un éclairage encore plus direct pour notre sujet : les projets développés de zéro avec des méthodes traditionnelles affichent le taux le plus élevé de projets en difficulté (61 %), alors que les projets de modernisation obtiennent l'un des meilleurs taux de succès (53 %). Le rapport prend soin de préciser ce qu'il entend par là : une modernisation en place, qui fait évoluer le logiciel existant — et non une réécriture avec des outils modernes, qu'il classe à part et qui affiche un taux d'échec de 23 %. Autrement dit, découper et moderniser l'existant réussit nettement plus souvent que reconstruire en bloc, et la recommandation centrale du Standish Group est précisément de transformer les grands projets en une succession de petits.
Soyons complets, parce qu'un lecteur qui ouvre le rapport le verra : le meilleur taux de succès du tableau (57 %) revient aux projets qui installent une application du marché sans la modifier. Ce n'est pas un argument contre la modernisation, c'est un rappel que la question se pose un cran plus tôt — faut-il seulement conserver ce logiciel ? Nous y répondons dans Refonte ou remplacement. Mais une fois décidé qu'on le garde, le big bang reste le pari le moins bien noté.
La refonte progressive : moderniser par étapes
L'alternative consiste à moderniser module par module, en commençant par les zones les plus douloureuses ou les plus risquées. L'ancien système et le nouveau cohabitent le temps de la transition. À chaque étape, on livre de la valeur — un irritant corrigé, une brique sécurisée, une fonctionnalité modernisée — et on réduit le risque global, puisqu'on ne bascule jamais tout en même temps.
Cette approche a trois vertus décisives. Vous voyez des résultats vite — les premiers gains arrivent en quelques semaines, pas en un an. Le risque reste maîtrisé — un module qui pose problème n'emporte pas tout le reste. Et l'investissement est pilotable — vous avancez au rythme que votre budget et votre activité permettent, avec la possibilité de faire une pause ou de réorienter à chaque palier.
Comment une refonte progressive fonctionne concrètement
Cette approche a un nom dans le métier : le strangler fig — le figuier étrangleur —, décrit par Martin Fowler en 2004. L'image est celle du figuier qui pousse autour d'un arbre hôte jusqu'à le remplacer entièrement. Appliqué au logiciel : on place une couche d'aiguillage devant l'ancien système, on construit chaque nouveau module à côté, et on redirige les usages vers lui fonction par fonction. L'ancien système fait de moins en moins de choses, jusqu'au jour où il n'en fait plus aucune et peut être éteint — sans qu'il y ait jamais eu de « jour J ».
Le point délicat, et l'essentiel du travail de conception, ce sont les données : pendant la transition, l'ancien et le nouveau doivent lire et écrire des informations cohérentes. Soit une base partagée le temps de la migration, soit une synchronisation dans les deux sens — à décider dès le cadrage, module par module. Et l'ordre des modules compte : on commence par celui qui fait le plus mal ou qui porte le plus de risque, rarement par le plus gros.
Big bang ou progressif : la comparaison point par point
| Critère | Big bang (réécriture complète) | Refonte progressive |
|---|---|---|
| Premier gain visible | Big bang (réécriture complète) : À la bascule finale, après des mois sans rien livrer. | Refonte progressive : Dès le premier module, en quelques semaines. |
| Risque | Big bang (réécriture complète) : Concentré sur une seule date : un défaut majeur arrête toute l'activité. | Refonte progressive : Réparti : un module qui pose problème n'emporte pas le reste. |
| Budget | Big bang (réécriture complète) : Engagé en totalité avant le premier résultat ; dérapages fréquents. | Refonte progressive : Par paliers, chaque lot budgété séparément ; pause possible. |
| Réversibilité | Big bang (réécriture complète) : Quasi nulle une fois la bascule faite. | Refonte progressive : Retour arrière possible à chaque étape. |
| Règles métier existantes | Big bang (réécriture complète) : Une partie est inévitablement oubliée et redécouverte en production. | Refonte progressive : Reprises module par module, en comparant l'ancien et le nouveau. |
| Double fonctionnement | Big bang (réécriture complète) : Deux systèmes à payer pendant toute la reconstruction. | Refonte progressive : Cohabitation organisée et limitée au périmètre en cours de migration. |
| Effort d'architecture | Big bang (réécriture complète) : Faible au départ, lourd à l'arrivée. | Refonte progressive : Réel dès le début : aiguillage et données à concevoir. |
| Quand c'est justifié | Big bang (réécriture complète) : Technologie irrécupérable, périmètre très petit, contrainte externe. | Refonte progressive : La grande majorité des logiciels métiers en production. |
Alors, big bang ou progressif ?
Dans la grande majorité des cas, la refonte progressive est le choix le plus sûr et le plus rentable. Le big bang ne se justifie que dans des situations précises : une technologie totalement obsolète et non maintenable, un périmètre réellement petit et maîtrisé, ou une contrainte externe qui impose une bascule complète (fin de support d'un composant critique, obligation réglementaire). Et même dans ces cas, un bon cadrage permet souvent de découper ce qui semblait indivisible.
La vraie réponse ne se donne pas à l'aveugle : elle se décide après un audit de l'existant — état du code, de l'architecture, criticité métier, contraintes de délai et de budget. C'est ce qui permet de recommander la bonne approche, plutôt que de subir celle qui arrange le prestataire.
Notre conviction
Sur les refontes que nous accompagnons — dans la santé, l'intérim ou l'industrie — le constat rejoint celui du Standish Group : ce qui fait échouer un projet, ce n'est pas la technique, c'est le choix de la trajectoire. Commencer par nommer le bon risque, livrer vite, préserver les règles métier existantes : c'est ce qui transforme une modernisation angoissante en projet maîtrisé. Et si la question se pose un cran plus tôt — faut-il seulement conserver ce logiciel, ou le remplacer ? — c'est l'objet de notre article Refonte ou remplacement.
Questions fréquentes
La refonte progressive coûte-t-elle plus cher ?
Pas nécessairement. Elle demande un effort d'architecture pour faire cohabiter l'ancien et le nouveau, mais elle évite le coût caché le plus lourd d'un big bang : les mois passés à tout reconstruire sans rien livrer, et le risque d'un projet qui dérape ou qu'on abandonne à mi-parcours. Le progressif étale l'investissement et le rend pilotable.
Faut-il refaire l'interface en même temps que la technique ?
Pas forcément, et rarement d'un bloc. Refaire l'interface change ce que l'utilisateur voit et fait : parcours, écrans, ergonomie. Refaire la technique change ce qu'il ne voit pas : architecture, code, dépendances, hébergement. Les deux peuvent être menées séparément, et c'est souvent souhaitable : refaire les écrans sur une base technique fragile, c'est repeindre une maison dont la charpente cède. L'ordre habituel est de sécuriser le socle technique des modules critiques, puis de retravailler les parcours là où ils font perdre du temps aux utilisateurs — module par module, pas en bloc.
Par quel module commencer une refonte progressive ?
Par celui qui fait le plus mal ou qui porte le plus de risque — pas par le plus gros, ni par le plus facile. Un module douloureux livre un gain visible qui crédibilise la démarche ; un module risqué (sécurité, composant plus maintenu) retire une épée de Damoclès. Et un seul à la fois au début : le premier module sert aussi à valider l'architecture de transition, l'aiguillage et la gestion des données, avant d'en paralléliser plusieurs.
Combien de temps dure la cohabitation entre l'ancien et le nouveau système ?
Aussi longtemps que la migration, et c'est voulu : c'est elle qui rend le projet réversible et pilotable. Ce qui doit rester court, c'est la cohabitation sur un même module — quelques semaines entre sa mise en service et l'extinction de l'ancienne version, le temps de vérifier les données et les usages réels. Une cohabitation qui s'éternise sur un module est le signe d'une bascule mal préparée : personne n'ose éteindre l'ancien parce que personne ne sait exactement ce qu'il fait encore.