Sur une reprise récente chez un client industriel, le moteur de calcul était propre et couvert de tests, pendant que la couche d’export tournait sur du code que personne n’avait rouvert depuis des années. Une seule application, deux verdicts opposés. C’est ça, un projet hérité : un patchwork. Le réflexe « ce projet est pourri, on réécrit » se trompe presque toujours de niveau. Le tri se fait module par module, et pour ça je trace au tableau, dès le premier atelier, une grille à deux axes.
Reprendre un projet, ce n’est pas le réécrire en entier. Je classe chaque module sur deux axes, son état et son poids réel : le sain, on le garde ; le dégradé qui compte, on le refactore ; l’irrécupérable critique, on le remplace un module à la fois.
Deux axes pour trancher
Le premier axe, c’est l’état du code. Sain : fonctionnel, lisible, on le fait évoluer sans transpirer. Dégradé : ça marche, mais chaque modification est une corvée. Irrécupérable : illisible, instable, on n’ose plus y toucher de peur de tout casser.
Le second, c’est le poids réel. Un module critique vit au centre de ce qui rapporte et se modifie sans arrêt ; un module périphérique reste stable, en bordure, ouvert une fois par an.
Pris isolément, l’état ne décide de rien. Un code affreux qu’on ne rouvre jamais ne coûte rien. Ce qui dicte l’action, c’est le croisement.
Ce que dit chaque croisement
Sain, qu’il soit critique ou non : on garde. Le réécrire parce qu’on n’en est pas l’auteur, c’est de l’argent jeté par la fenêtre. J’ai vu des équipes brûler des semaines à « se réapproprier » du code parfaitement sain, juste gênées de ne pas l’avoir écrit.
Dégradé et critique : on refactore, sous filet de tests, sans changer le comportement. C’est le meilleur retour sur investissement de toute la reprise. Une partie importante, rouverte chaque semaine mais pénible à faire évoluer, et soudain tout ce qui vient ensuite avance plus vite.
Dégradé mais périphérique : on laisse vivre. Le réparer reviendrait à dépenser de l’énergie pour zéro bénéfice. Ça pique les yeux, on s’en accommode.
Irrécupérable et critique : on remplace. Indispensable, plus sauvable, mais un module à la fois, jamais l’application entière. Viser le tout-d’un-coup, c’est le piège de la réécriture totale, et il a englouti plus de projets que n’importe quel bug.
Alors voici le conseil concret : la prochaine fois qu’on vous dit « il faut tout reprendre », ouvrez le dépôt et faites classer chaque module par l’équipe elle-même, dans une colonne par verdict. Vous verrez la liste « on garde » être de loin la plus longue. C’est elle qui finance le reste.