Comment j'empêche un binôme IA de réécrire la moitié du dépôt

La première fois que j’ai laissé un agent de code travailler sans cadre strict, il a touché quarante-trois fichiers pour corriger un bug de trois lignes. Le fix était correct. Le diff était inreviewable. J’ai passé plus de temps à vérifier que les quarante autres fichiers n’avaient pas de régression qu’à comprendre le bug initial.

Ce jour-là, j’ai appris que le problème des agents de code n’est pas la qualité du code qu’ils produisent, c’est le périmètre de ce qu’ils décident de toucher. Un agent sans contrainte fera du refactoring opportuniste, « améliorera » du code adjacent, et ajoutera des abstractions que personne n’a demandées. Pas par malice, par optimisation locale d’un objectif trop large.

La règle du diff d’une page

Ma première défense : je ne fais jamais confiance à un diff que je ne peux pas lire en entier sur un écran. Si la PR dépasse ~200 lignes changées, je sais d’expérience que ma capacité de revue tombe en dessous du seuil utile. Je survole au lieu de lire. Et surveiller, c’est ne pas détecter.

En pratique, ça veut dire que je découpe chaque demande en morceaux suffisamment petits pour que le résultat tienne dans une revue de cinq minutes :

« Corrige le bug dans la validation du formulaire », pas « Corrige le bug et refactorise le module de validation ».
« Ajoute le champ email au composant Contact », pas « Ajoute le champ email et harmonise tous les formulaires du site ».
« Écris le test pour parseResponse », pas « Améliore la couverture de test du module API ».

Plus la demande est précise, moins l’agent a de marge pour dériver.

Les trois barrières

Barrière 1 : le fichier allowlist

Quand je travaille avec Claude Code ou un agent similaire, je commence par nommer les fichiers que l’agent a le droit de toucher. Pas « le projet », les fichiers précis. Si je travaille sur un bug dans src/lib/parser.ts, l’agent n’a pas besoin de toucher src/components/Header.astro.

C’est l’équivalent du moindre privilège appliqué à la portée d’édition. Un agent qui ne peut écrire que dans trois fichiers ne peut pas refactoriser quarante-trois fichiers, même s’il pense que ce serait « mieux ».

Barrière 2 : la contrainte de sortie

Je demande toujours un livrable précis : « le diff, rien d’autre », « le fichier de test, pas l’implémentation », « un plan d’abord, le code après validation ». Quand l’agent sait que sa sortie sera évaluée sur un critère étroit, il cesse d’élargir le périmètre.

Les mots qui déclenchent la dérive : « améliore », « nettoie », « modernise », « harmonise ». Chacun est une invitation à toucher du code qui marchait sans qu’on le demande.

Barrière 3 : la revue du diff, pas du chat

Le résumé que l’agent produit (« J’ai corrigé le bug et amélioré la lisibilité de trois fonctions adjacentes ») est toujours plus flatteur que la réalité. Je ne lis jamais le résumé en premier. Je lis le diff. Ligne par ligne. Fichier par fichier.

Si je vois un fichier dans le diff que je n’ai pas mentionné dans ma demande, c’est un signal d’alarme. L’agent a fait du travail non demandé. Parfois c’est pertinent. La plupart du temps, c’est un refactoring cosmétique que je vais devoir maintenir sans l’avoir voulu.

Le workflow en pratique

1. Décrire la tâche en une phrase (verbe + objet + périmètre)
2. Nommer les fichiers autorisés
3. Demander un plan avant le code
4. Valider le plan (ou le restreindre)
5. Recevoir le code
6. Lire le diff intégralement (pas le résumé)
7. Accepter, modifier, ou rejeter

L’étape 3 est celle qui change tout. Quand l’agent propose un plan (« je vais modifier A, B et C pour résoudre X »), vous voyez immédiatement s’il a décidé de toucher B et C sans raison. Vous coupez là, avant que le code soit écrit. C’est mille fois moins cher qu’une revue après coup.

Quand lâcher la bride

Il y a des cas où je veux un large périmètre : un renommage global, une migration de syntaxe, un reformatage. Dans ces cas, la contrainte change, je demande un diff homogène (tous les changements du même type) et je vérifie par échantillonnage, pas ligne par ligne.

Mais c’est l’exception, pas la règle. La règle est : petit périmètre, petits diffs, relecture intégrale. L’agent est un collègue junior ultra-rapide. Vous ne laisseriez pas un junior toucher quarante fichiers sans revue. L’agent ne mérite pas plus de confiance aveugle, il mérite plus de cadre.

Si cela vous a parlé, vous aimerez Écrire des skills que votre agent de code utilisera vraiment et Les petites automatisations qui se cumulent sur un trimestre. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.