Pourquoi réécrire un logiciel de zéro échoue presque toujours
Face à une dette technique paralysante, réécrire entièrement une application semble être la solution idéale. L'expert Simon Willison explique pourquoi cette approche crée souvent deux problèmes au lieu d'un, et plaide pour des refactorisations ciblées.
Fil « Débat sur la dette technique et les limites de la dégradation du code »
Quand le code d'une application devient trop complexe à maintenir, la tentation est grande de repartir d'une page blanche (greenfield, un projet réécrit de zéro sans contrainte d'historique). Dans un billet récent, l'expert Simon Willison revient sur ce réflexe face à la dette technique (dette technique, l'accumulation de choix de conception raccourcis ou obsolètes). Selon son expérience, vouloir tout brûler pour recommencer fonctionne extrêmement rarement.
L'engrenage vicieux des deux systèmes en production
Le piège de la réécriture suit un schéma classique. Une équipe est affectée au nouveau système, tandis que l'ancien continue de faire tourner le cœur de l'entreprise :
- Les développeurs maintenant l'ancien code font le strict minimum, sachant qu'il sera remplacé, ce qui accélère sa dégradation.
- L'équipe du nouveau projet démarre vite mais réalise qu'elle ne maîtrise ni le périmètre ni les comportements exacts de l'ancien système, souvent mal documenté.
- Sous la pression de livrer après des mois de travail, le nouveau système est lancé avec un sous-ensemble de fonctionnalités.
Au final, l'entreprise se retrouve à devoir maintenir deux systèmes en production : l'ancien code instable et le nouveau système qui contient jusqu'à 80 % de code inactif destiné à un remplacement complet qui risque d'être abandonné si les priorités changent.
Sécuriser l'existant plutôt que tout recommencer
Mon intuition est que dans beaucoup de cas, cela aura de bien meilleures chances de succès que le chant des sirènes d'un remplacement de zéro.
Pour traiter le problème à la racine, Simon Willison s'appuie sur l'approche de Will Larson (Migrations: the sole scalable fix to tech debt). Sa recommandation consiste à consolider le système existant en y ajoutant un maximum de tests automatisés, puis à procéder à des refactorisations (refactoring, la réorganisation du code interne sans modifier son comportement externe) de manière ciblée.
Cette stratégie évite de dupliquer la complexité tout en sécurisant l'existant par une chaîne de validation automatisée :
# Validation de la couverture de tests avant refactorisation ciblée
npm run test:coverage
En consolidant le code actuel au lieu de céder à l'illusion de la page blanche, les équipes s'assurent de livrer de la valeur en continu sans doubler leur charge de maintenance.