Travailler sur du legacy avec un agent

Comprendre avant de modifier

Le code legacy, c’est du code qu’on ne peut pas changer en confiance — le plus souvent parce qu’il n’a pas de tests, peu de documentation, et une structure qui s’est sédimentée au fil des ans. Pour un agent, c’est le terrain le plus hostile : il lui manque presque tous les leviers qui lui permettraient de vérifier son travail.

La règle d’or tient en une phrase : on comprend avant de toucher. Avant la moindre modification, on fait cartographier le code par l’agent — quelles entrées, quelles sorties, quels effets de bord, quelles dépendances. Lire et résumer coûte quelques tokens ; modifier à l’aveugle coûte une régression en production.

Point clé : Un agent sur du legacy démarre avec peu de leviers (pas de tests, types faibles, architecture enchevêtrée). Ton premier travail n’est pas de coder : c’est de reconstruire un filet avant de déléguer quoi que ce soit.

Le filet : les tests de caractérisation

Un test de caractérisation ne vérifie pas ce que le code devrait faire — il capture ce qu’il fait réellement, aujourd’hui, bugs compris. On exécute le code, on observe la sortie, et on la fige dans un test. Le but n’est pas de juger le comportement : c’est de le verrouiller pour détecter le moindre changement pendant un refacto.

C’est l’oracle qui transforme un terrain miné en terrain sûr. Une fois les tests de caractérisation au vert, on peut lancer l’agent en boucle fermée : il modifie, relance les tests, voit le rouge, corrige. Sans ce filet, l’agent dérive en silence — le code compile, mais le comportement a changé sans que personne ne s’en aperçoive.

Attention — ne jamais confondre. Un test de spec dit « le prix TTC doit être de 120 ». Un test de caractérisation dit « aujourd’hui, cette fonction renvoie 119,99 — on le fige ». Si ce 119,99 est un bug, le test le révèle au moment où on le corrige : c’est exactement ce qu’on veut.

Casser les dépendances : les points de couture

Souvent, la méthode qu’on veut sécuriser est intestable telle quelle : elle appelle directement une base de données, l’horloge système, ou un service réseau. La solution n’est pas de réécrire la logique, mais d’introduire un point de couture (un « seam ») — un endroit où l’on peut substituer la dépendance sans changer le comportement.

Concrètement : on extrait la dépendance derrière une interface ou un paramètre, ce qui permet de l’injecter en test. C’est une opération mécanique et minimale — on la confie volontiers à l’agent, à condition de lui interdire de toucher à la logique métier au passage.

Point clé : Un point de couture, c’est un port hexagonal qui s’ignorait. Extraire l’accès base derrière une interface rend la méthode testable et amorce une architecture plus propre — sans big bang.

Le piège du rewrite

Devant un module confus, l’agent (comme le dev) est tenté de tout réécrire à neuf. C’est presque toujours un piège. Le code legacy encode des années de corrections : des cas limites, des contournements, des bugs devenus des fonctionnalités. Réécrire de zéro, c’est jeter ce savoir métier implicite et le redécouvrir un incident de prod à la fois.

La voie pragmatique est l’incrément vérifié : petits pas, chacun couvert par un test, chacun relu. On ajoute le neuf à côté de l’ancien (sprout), on bascule progressivement, on supprime le mort quand plus rien ne l’appelle. La simplicité gagne ici contre l’envie de table rase.

Attention — branche dédiée et revue. L’agent travaille sur une branche, jamais sur main. Chaque incrément est relu par un humain. Sur du legacy, la confiance se construit test après test — pas par un grand saut.

Construire les leviers avant de déléguer

L’autonomie d’un agent dépend des leviers en place. Sur du legacy, ils sont presque tous faibles au départ. La stratégie : monter ces leviers par incréments vérifiés, et n’élargir l’autonomie de l’agent qu’à mesure qu’ils se renforcent. On ne passe pas en AFK sur une base sans filet.

Point clé : Progression « in-loop → out-of-loop → AFK » : sur du legacy, on reste in-loop tant que le filet n’existe pas. L’autonomie se mérite, levier après levier.