Réécrire ou refactoriser ? Décider honnêtement

Toute équipe technique finit par arriver à cette réunion où quelqu'un affirme qu'il irait plus vite en repartant de zéro. Parfois c'est vrai. Généralement non, et la raison est un biais qui mérite d'être nommé.

Vous comparez un système réel, dont vous voyez les défauts en détail, à un système imaginaire dont les défauts n'ont pas encore été découverts. La base existante a une liste de problèmes connus. Le remplacement n'en a aucun — parce qu'il n'existe pas. La comparaison n'est pas honnête, et c'est pourquoi les estimations de réécriture se trompent avec une telle régularité.

Voici une méthode qui résiste à cet instinct.

Ce que contient réellement l'ancien système

Une base de code qui fonctionne n'est pas seulement faite de fonctionnalités. Elle contient aussi chaque correction de bug, chaque cas limite et chaque condition ingrate accumulés pendant que de vrais clients l'utilisaient.

Cette branche étrange qui gère un format de date particulier ? Un client l'a rencontrée en production. Ce rappel avec ce délai bizarre ? Le paiement de quelqu'un a échoué à 2 h du matin. Rien de tout cela n'est documenté, l'essentiel ressemble à des scories, et une réécriture jette tout et le redécouvre un ticket de support mécontent à la fois.

C'est le coût le plus systématiquement sous-estimé. Pas réécrire les fonctionnalités : réécrire les corrections invisibles.

Quatre vraies raisons de réécrire

La réécriture s'impose quand le problème est structurel — quand aucune amélioration progressive ne vous y mènera.

1. Le modèle de données ne correspond plus au produit. Vous aviez prévu un établissement par client et l'entreprise est devenue multi-sites. Chaque table, requête et écran encode l'ancienne hypothèse. C'est la raison légitime la plus fréquente.
2. Vous ne pouvez plus recruter. Le langage ou le framework n'a plus de vivier significatif. C'est un risque d'entreprise, pas une question esthétique.
3. La plateforme est une impasse. Un éditeur l'a abandonnée, la licence a changé, ou elle ne tourne plus sur une infrastructure supportée.
4. L'architecture de sécurité est irréparable. Pas « il y a des vulnérabilités » — celles-là se corrigent. Ici, la conception elle-même suppose quelque chose de dangereux, comme une frontière de confiance unique sans moyen d'introduire du multi-tenant.

Quatre raisons qui semblent vraies et ne le sont pas

1. « C'est moche. » L'esthétique n'est pas un argument économique. Du code laid qui fonctionne et que personne ne touche ne coûte rien.
2. « Le framework est ancien. » Ancien et maintenu, c'est très bien. Ancien et abandonné, c'est la raison 3 ci-dessus — vérifiez dans quel cas vous êtes réellement.
3. « La nouvelle équipe le souhaite. » Compréhensible, et coûteux. Les développeurs préfèrent écrire que lire. C'est une préférence, pas un argument.
4. « C'est lent. » La performance se corrige presque toujours sur place, et à bien moindre coût. Profilez avant de conclure que l'architecture est en cause.

Le test des deux semaines

Le diagnostic le plus utile que nous connaissons, et il ne demande aucune analyse :

Prenez une vraie demande de fonctionnalité, de taille moyenne. Un bon développeur peut-il la livrer en deux semaines sans casser autre chose ?

• Oui → le système est exploitable. Votre problème est une dette ciblée, pas l'architecture. Refactorisez.
• Non, parce qu'il ne trouve pas où les choses se passent → problème de connaissance. Documentation et tests coûtent moins cher qu'une réécriture et règlent davantage.
• Non, parce qu'un changement en casse trois sans rapport → couplage structurel réel. Là, la conversation devient légitime.

La plupart des équipes certaines d'avoir besoin d'une réécriture découvrent qu'elles sont dans le deuxième cas. C'est le problème de la dette sans auteur, et il se soigne en écrivant les choses.

La troisième option que presque personne n'envisage

Le choix n'est pas binaire. Vous pouvez étrangler l'ancien système.

Placez une interface stable devant le code existant, puis remplacez une pièce à la fois derrière elle. Le nouveau travail va dans la nouvelle structure ; l'ancien reste jusqu'à ce qu'on y touche. En quelques mois, l'ancien système rétrécit jusqu'à ce que le reste ne vaille plus la peine d'être déplacé.

C'est plus lent par composant et bien plus sûr globalement, parce que :

• Vous n'avez jamais de période sans produit livrable.
• Chaque tranche se vérifie indépendamment, donc une erreur reste petite.
• Vous pouvez vous arrêter à tout moment et être malgré tout gagnant, ce qu'une réécriture à moitié faite ne peut pas prétendre.
• L'entreprise continue de recevoir des fonctionnalités pendant toute la durée.

Pour la plupart des équipes qui se posent la question, c'est la bonne réponse et elles ne l'ont pas envisagée.

Si vous réécrivez, trois règles

1. Gardez l'ancien système en fonction et faisant autorité jusqu'à ce que chaque tranche soit réellement remplacée. Pas de bascule d'un seul coup.
2. N'ajoutez aucune fonctionnalité pendant la réécriture. Si la cible bouge, vous ne convergerez jamais — c'est ainsi que les réécritures deviennent permanentes.
3. Reprenez les bizarreries délibérément. Passez en revue les conditions étranges et décidez, cas par cas, si chacune est obsolète ou porteuse. Ne les jetez pas en bloc : c'est ainsi qu'on réintroduit trois ans de bugs.

Budgétez avec réalisme. La réécriture d'un système qui a demandé un an n'est pas un projet de trois mois, quel que soit l'enthousiasme dans la salle.

En résumé

Réécrivez quand la structure est mauvaise. Refactorisez quand le code est désordonné. Étranglez quand c'est entre les deux, ce qui est le cas le plus courant.

Et méfiez-vous de la certitude elle-même : la conviction qu'une réécriture ira vite vient de ce qu'on ignore encore ce que fait le système actuel. Cette connaissance arrivera de toute façon ; la seule question est de savoir si elle arrive pendant la planification ou pendant une panne.

Si vous voulez un second avis avant d'engager des mois là-dedans, c'est une conversation fréquente chez nous — et nous en dissuadons souvent nos clients. Découvrez notre approche du développement SaaS, ou envoyez-nous le dépôt.