Claude Code et les sous-agents ramènent la réécriture d'un projet legacy de trois mois à une semaine

L'écart entre trois mois et une semaine dans cette histoire ne s'explique pas par des modèles qui écriraient soudain un code parfait, mais par le fait que l'auteur a cessé d'utiliser l'IA comme un autocomplétion intelligent pour en faire une véritable chaîne d'ingénierie. À partir de deux projets Go de même ampleur, il montre que lorsque le legacy est démêlé à la main et à l'intuition, la vitesse se heurte au chaos. Quand le modèle dispose de rôles, de procédures, de relectures et d'un circuit de tests, la réécriture d'un monolithe va plusieurs fois plus vite.

Il y a un an, le point de départ était la dette technique d'après-MVP, que beaucoup connaissent bien. Le projet comptait un seul main.go d'environ deux mille lignes, où la logique métier, la configuration, les handlers HTTP, l'accès à la base de données et d'autres éléments annexes étaient entassés au même endroit.

Une telle structure peut survivre à un lancement précoce du produit, mais supporte mal la croissance : chaque modification entraîne des effets de bord, le code se découpe difficilement en zones de responsabilité, et les tests deviennent une source de douleur supplémentaire plutôt qu'un appui. L'auteur se souvient qu'il avait alors fait évoluer le système vers une architecture correcte morceau par morceau, avec des tests maison et une vérification manuelle permanente.

Il a réalisé la première refactorisation dans Cursor et y a consacré environ trois mois. Le processus était prudent, presque chirurgical : extraire un bloc, vérifier que le comportement n'a pas été cassé, puis passer au suivant.

Un projet récent de même ampleur a donné un résultat très différent. L'auteur a pris Claude Code avec le modèle Opus, branché trois sous-agents relecteurs et construit autour d'eux une trentaine de skills, des scénarios reproductibles pour les opérations courantes. La réécriture a pris une semaine, et une part notable de ce temps n'a pas été consacrée au transfert du code lui-même, mais à une couche BDD par-dessus l'implémentation. Selon son estimation, sans les scénarios godog, la tâche aurait pu tenir en environ trois jours.

L'essentiel de l'article n'est pas qu'un outil précis se soit révélé plus fort qu'un autre, mais que l'auteur a changé sa manière de travailler. Il oppose sa pratique aux conseils populaires du genre « donnez un bon prompt au réseau de neurones et attendez le résultat ». Dans un vrai legacy, cela ne suffit pas : le modèle a besoin non seulement de contexte, mais aussi d'un environnement maîtrisé.

Les sous-agents offrent un regard parallèle sur les changements et attrapent les erreurs avant qu'elles n'atteignent la branche principale. Les skills suppriment la routine, standardisent les étapes et réduisent le nombre de décisions à reprendre à zéro. Le BDD ajoute un contrat de comportement externe, pour que la réécriture ne se transforme pas en remplacement silencieux de la logique métier par une belle structure neuve.

C'est pourquoi l'auteur voit comme résultat majeur non pas simplement l'accélération, mais l'apparition d'une chaîne d'outils opérationnelle, level85. Il s'agit en somme d'un ensemble d'accords entre l'humain, le modèle et les agents auxiliaires : comment décomposer une tâche, comment vérifier les résultats intermédiaires, comment limiter la liberté de génération et où brancher les tests. Cette approche fait de l'IA non pas un bouton magique, mais un participant discipliné au développement.

L'auteur ne cherche pas à vendre une recette universelle. Au contraire, il souligne que même dans la configuration finale, des pièges subsistent : trop de contexte, une mauvaise décomposition, des vérifications faibles ou un moment mal choisi pour automatiser peuvent facilement annuler le gain. La conclusion principale est pratique : l'accélération dans le développement assisté par IA ne vient pas d'un seul modèle, mais du système d'exploitation qui l'entoure.

Si une équipe continue de traiter l'IA comme une fenêtre de chat pour des conseils ponctuels, le code monolithique sera toujours réécrit lentement et dans la nervosité. Mais si le modèle devient une partie du processus, avec des rôles, des relectures, des scénarios et des méthodes fixes, même un legacy lourd peut être démonté plusieurs fois plus vite sans renoncer à la discipline d'ingénierie. C'est sans doute la principale leçon de l'article.