Refactoriser 10 000 lignes de legacy sans tout casser

Un module de 10 000 lignes sans tests, que personne n'ose toucher : tout projet finit par en hériter. La tentation est grande de lâcher un agent IA dessus et de revenir le lendemain avec « tout est propre ». Mauvaise idée. Le refactoring de legacy avec l'IA fonctionne — mais à une condition que les démonstrations passent sous silence : l'IA accélère un processus discipliné, elle ne le remplace pas. Voici la méthode qui rend l'échelle atteignable sans tout casser.

Pourquoi « 10 000 lignes d'un bloc » est un piège

Commençons par tuer le fantasme. On ne refactore jamais dix mille lignes d'un seul coup, et surtout pas en confiant l'opération à une IA en autonomie. Trois raisons, toutes mesurées.

D'abord, l'IA ne voit pas tout votre dépôt. Même avec des fenêtres de contexte qui atteignent aujourd'hui le million de jetons, la recherche montre un effet « perdu au milieu » : un modèle exploite bien l'information située au début et à la fin de son contexte, mais rate celle du centre, avec une chute de performance de l'ordre de 20 à 30 %. Une grande fenêtre ne garantit pas un raisonnement fiable sur l'ensemble.

Ensuite, elle invente. Une étude présentée à USENIX Security 2025, portant sur plus de deux millions d'échantillons de code, mesure que près de 20 % des paquets recommandés par des modèles n'existent pas — un cas tombant à environ 5 % pour les modèles commerciaux, mais grimpant à plus de 20 % pour les modèles ouverts. Pire : ces noms hallucinés sont reproductibles, donc exploitables par un attaquant qui enregistre le paquet fantôme. C'est le « slopsquatting ».

Enfin, un gros diff est invérifiable. Si l'IA réécrit trois mille lignes d'un coup, vous ne pouvez pas relire honnêtement le résultat. Et un changement qu'on ne peut pas vérifier n'est pas un refactoring : c'est un pari.

Le vrai filet de sécurité : les tests

La discipline qui rend le refactoring sûr est antérieure aux IA. Michael Feathers la formule sans détour : pour lui, le code legacy, c'est simplement du code sans tests. Pas du code vieux ou mal écrit — du code qu'on ne peut pas modifier sans risque parce que rien ne protège son comportement.

La parade s'appelle le test de caractérisation : avant de toucher quoi que ce soit, on écrit des tests qui capturent le comportement actuel du code — pas le comportement souhaité, mais celui qui tourne en production aujourd'hui, bugs compris. Ces tests deviennent votre filet : tant qu'ils restent verts, vous savez que vous n'avez rien cassé d'observable.

La boucle qui refactore sans casser

Une fois le comportement gelé par des tests, le refactoring assisté suit une boucle simple, répétée sur de petits lots (Fig. 1).

Le cœur, c'est le périmètre étroit : une classe, une fonction, un module — jamais le dépôt entier. On demande à l'IA une transformation précise (« extrais cette logique dans une fonction pure, en préservant le comportement »), on relit le diff comme on relirait la pull request d'un junior, on lance les tests, on committe un petit changement réversible, puis on itère. Fowler le résume : chaque transformation fait peu, mais leur cumul produit la grande restructuration — et comme chaque pas est petit, il a peu de chances de mal tourner, et le système reste fonctionnel à tout moment.

C'est ainsi que les « 10 000 lignes » deviennent atteignables : non pas en une passe héroïque, mais en cent petits lots testés, relus et commités. Lent ? Non : l'IA accélère chacune de ces étapes. Mais le rythme reste cadencé par les tests, pas par la confiance aveugle.

Où l'IA aide, où elle est dangereuse

La ligne de partage est nette (Fig. 2). Encadrée, l'IA est précieuse : générer les tests manquants, expliquer un code obscur, proposer un renommage ou une extraction, repérer la duplication et les API dépréciées, rédiger un diff étroit que vous validez. En autonomie aveugle, elle devient un risque : refactor massif non testé, hallucination de dépendances, perte d'information sur les gros contextes, et — le plus sournois — la suppression silencieuse d'un contrôle. En réécrivant un bloc, un agent peut retirer une validation d'entrée ou une vérification d'autorisation sans le signaler. C'est précisément ce que pointe l'OWASP sur le traitement des sorties de modèles.

Quel outil pour quel usage

Trois familles d'agents conviennent au refactoring, avec deux modèles de coût (Fig. 3).

Cline est open-source (licence Apache 2.0) et fonctionne sur le principe « apportez votre clé API » : il n'embarque aucun modèle, vous branchez celui que vous voulez — Claude, GPT, Gemini, ou même un modèle local via Ollama. Vous ne payez que les jetons consommés. Ses modes Plan et Act, et surtout ses checkpoints réversibles, en font un outil adapté au refactoring incrémental : chaque édition est un diff que vous approuvez. Cursor est un éditeur de code complet avec mode agent et indexation du codebase, gratuit en version limitée, payant à partir de 20 $/mois. GitHub Copilot s'intègre étroitement à l'écosystème GitHub, propose un mode agent sur tous ses plans dont une offre Pro à 10 $/mois, et est passé à une facturation à l'usage en juin 2026.

Quel que soit l'outil, le principe ne change pas : vous approuvez chaque changement et vous lancez les tests. L'agent propose, vous disposez.

Testez vous-même : le protocole

1. Choisissez une seule fonction redoutée de votre legacy.
2. Demandez à un agent de générer ses tests de caractérisation, puis relisez-les et faites-les passer au vert.
3. Demandez une transformation précise (une extraction, un renommage), « en préservant le comportement ».
4. Relisez le diff intégralement, relancez les tests, et committez si tout est vert.
5. Recommencez sur la fonction suivante — et mesurez votre rythme après vérification.

En une matinée, vous saurez où l'agent vous fait vraiment gagner du temps — et où votre jugement de développeur reste irremplaçable.