Combien de fois avez-vous entendu « on repart de zéro, ce sera plus propre » ? De toutes les décisions techniques que je vois passer, c’est celle qu’on regrette le plus souvent. Et quand je pose le calcul honnêtement, il finit presque toujours du même côté.
Repartir de zéro, c’est des mois sans rien livrer, la quasi-certitude de recroiser en production les bugs qu’on croyait fuir, et une bascule qui se joue sur une seule journée. Le découpage progressif, lui, livre en continu et étale le risque sur de petits paris.
Le problème démarre avant même la première ligne de code neuf. Pendant que vous reconstruisez, l’ancien système continue de vivre : il faut le corriger, parfois lui greffer une fonction qu’un client réclame, et tout cela pendant qu’une équipe bâtit le remplaçant. Vous payez deux fois. Côté utilisateur, le produit n’avance plus pendant des mois. J’ai accompagné une PME qui visait six mois de réécriture ; au bout de quatorze, l’ancien tournait toujours en production et le nouveau n’avait pas encaissé une seule commande réelle.
Le calendrier, pourtant, n’est pas ce qui fait le plus mal. Ce qui fait mal, c’est tout ce que l’ancien code sait et que personne ne sait plus. Des centaines de cas limites accumulés au fil des années, rarement documentés, parfois ajoutés un dimanche soir après un incident. La réécriture les redécouvre un par un, en production, déguisés en bugs flambant neufs. Ce code que tout le monde jugeait sale encodait en réalité des leçons payées cher. Arrive ensuite le jour de la bascule, où l’on remplace tout d’un bloc. Un défaut sérieux sur le nouveau système, et vous voilà piégé : revenir en arrière après des mois de divergence des données, c’est rarement jouable. Toute l’application repose alors sur une seule journée.
Le découpage progressif inverse cette logique. Chaque domaine extrait améliore le système immédiatement, sans qu’on patiente des mois avant le premier bénéfice. Le risque, du même coup, se fractionne : vous validez un bout à la fois sous charge réelle, avec un retour arrière possible quand ça dérape, au lieu de jouer le grand saut. Et il y a un effet que les présentations de projet oublient toujours de chiffrer. Chaque extraction vous apprend quelque chose qui servira la suivante ; vous corrigez vos hypothèses en marchant. La réécriture totale, elle, parie tout sur ce que vous croyiez savoir au premier jour, autrement dit au moment précis où vous en saviez le moins.
Cela dit, le progressif n’est pas une religion. Tout reprendre peut l’emporter dans deux cas. Quand la techno est réellement morte : framework abandonné, faille qu’aucun patch ne corrige, dépendance qui refuse de se compiler. Ou quand la base est assez petite pour être refaite sans douleur, mettons quelques milliers de lignes sans logique métier enfouie. Là, orchestrer un découpage coûte plus cher qu’une reprise franche, et je le dis sans hésiter. Pour trancher entre les deux mondes, je regarde toujours trois choses : la taille et la vivacité du produit, le savoir métier enfoui dans le code, le prix d’un gel prolongé pour l’entreprise.
Un cas récent illustre bien où ça se joue. Un éditeur me sollicite, persuadé qu’il lui faut tout reprendre : sa facturation est un nid à bugs, personne n’ose y toucher. On trace les dépendances, on regarde les incidents. Le module de facturation, justement, est appelé par presque tout le reste : le sortir en premier, c’était se condamner à six mois de chirurgie à cœur ouvert. À côté, un service d’export de rapports, peu couplé, qui tombait une fois par semaine. On l’a extrait en trois semaines, mis en production, et l’astreinte du week-end a cessé du jour au lendemain. L’équipe a vu un résultat concret, a repris confiance, et c’est seulement après qu’on a osé s’attaquer à la facturation, par petits morceaux. Le big bang qu’on était venu me vendre n’a jamais eu lieu, et personne ne le regrette.