La réécriture complète est presque toujours le mauvais choix, et presque toujours le premier réflexe. Quatre tests pour décider, et la méthode intermédiaire.
Un développeur qui découvre le code de quelqu'un d'autre dit à peu près toujours la même chose : c'est illisible, il faut tout refaire. Il a parfois raison. Mais ce jugement est aussi le réflexe le moins coûteux à formuler et le plus coûteux à suivre.
Pourquoi la réécriture séduit.
Reprendre du code existant, c'est comprendre les décisions d'un autre, dont beaucoup paraissent absurdes jusqu'au jour où l'on découvre pourquoi elles ont été prises. Repartir de zéro, c'est ne comprendre que ses propres décisions. C'est plus agréable — et ça n'a rien à voir avec ce qui sert ton entreprise.
Ce que contient un code moche.
Ce que l'on prend pour du désordre est souvent de la connaissance accumulée. La condition bizarre à la ligne 340 corrige un cas limite découvert en production il y a deux ans. Le contournement dans le module de facturation gère un client historique aux conditions particulières. Personne ne s'en souvient, et rien n'est documenté — mais le comportement est correct.
Une réécriture repart d'une compréhension idéalisée du problème et réintroduit tous les cas limites, un par un, en production, sous les yeux de tes clients.
Quatre tests pour décider.
Le test du démarrage : un nouveau développeur peut-il faire tourner le projet en local en une journée ? Si non, le problème est peut-être l'outillage, pas le code — et l'outillage se répare en une semaine.
Le test du changement : combien de temps pour un changement simple et bien délimité ? Si une modification d'un jour en demande cinq à cause des effets de bord, le code te coûte réellement de l'argent. C'est le seul argument financier valable en faveur d'une réécriture.
Le test des tests : existe-t-il des tests automatisés sur les parcours critiques ? Sinon, tu ne peux ni réparer ni réécrire en toute sécurité, car rien ne te dira que le comportement a changé. Écrire ces tests est le premier chantier, quelle que soit la décision.
Le test de la dépendance : le code repose-t-il sur une technologie qui ne reçoit plus de correctifs de sécurité ? C'est le seul cas où la réécriture s'impose sans discussion — la dette devient un risque, plus une gêne.
La voie intermédiaire.
Entre réparer et réécrire, il existe une troisième option qui fonctionne presque toujours mieux que les deux. On isole une fonction du système, on la réécrit proprement derrière une interface stable, on bascule le trafic vers la nouvelle, et l'ancienne meurt d'elle-même. Puis on recommence avec la suivante.
Trois avantages décisifs : la production ne s'arrête jamais, chaque étape apporte une valeur mesurable, et l'on peut s'arrêter quand la valeur cesse de justifier l'effort — ce qui arrive souvent, et c'est une bonne nouvelle. Une réécriture complète, elle, n'a aucune valeur avant d'être terminée à cent pour cent.
Le piège du gel.
Le vrai coût d'une réécriture n'est pas le développement. C'est le trimestre — ou l'année — pendant lequel ton produit cesse d'évoluer. Tes concurrents livrent. Tes clients demandent des fonctions que tu refuses « le temps de la migration ». Tes vendeurs perdent des affaires pour une fonction manquante qui existait dans le plan initial et qui n'est pas encore portée.
Beaucoup de réécritures sont techniquement réussies et commercialement perdantes.●
Ce qu'on ne fait pas.
On ne reprend pas un code existant sans audit préalable — une à deux semaines, facturées, avant tout engagement. Un prestataire qui accepte de s'engager sur un code qu'il n'a pas lu s'engage sur une supposition, et tu paieras l'écart. L'audit peut d'ailleurs conclure que le code est sain et que le problème est ailleurs. C'est arrivé, et c'est un bon résultat.