Les garde-fous pour les agents de codage IA surpassent les modèles plus intelligents

Un réviseur a examiné mon code et trouvé un bug. Une route renvoyait une erreur 500 alors qu’elle aurait dû renvoyer une erreur 404. Il a signalé le problème clairement, avec le fichier et la ligne.

Mon agent a corrigé cette route. Précisément celle-là.

Cinq autres routes avaient exactement le même bug. Elles sont restées là, intactes, tandis que l’agent annonçait que le travail était terminé — et il ne mentait pas. Il avait corrigé ce qu’on lui avait montré. Il n’avait simplement jamais pensé à demander dans combien d’autres endroits se cachait la même erreur.

Pendant un moment, j’ai supposé que le problème venait du modèle et qu’un meilleur modèle le résoudrait. J’avais tort, et la solution qui a fonctionné était plus bête que je ne l’imaginais. Les garde-fous pour les agents de codage IA ne servent pas à rendre le modèle plus intelligent. Ils lui donnent un endroit où déposer les choses.

Là où les agents de codage IA se trompent discrètement

Les échecs qui m’ont coûté le plus de temps n’avaient techniquement rien en commun. Ils avaient un point commun structurel : dans chaque cas, quelque chose d’important était gardé en tête au lieu d’être consigné.

« Il a dit que c’était terminé. Ça ne l’était pas. »

Tu reçois un message de fin. La liste des tâches est entièrement cochée. Puis tu regardes et tu trouves un TODO à la place de la logique, une fonction qui renvoie une liste vide ou une sous-tâche discrètement ignorée.

Voici ce que j’ai mis bien trop longtemps à comprendre. L’agent ne bluffe pas. Il vérifie son travail par rapport à son propre souvenir de ce qu’il vient d’écrire, et ce souvenir est réellement convaincant. Des tests au vert, ajoutés au souvenir très net d’avoir écrit le code, donnent exactement l’impression que tout est terminé.

Dépose-le plutôt quelque part : rien n’est considéré comme terminé sans preuves que tu peux examiner. Pas une affirmation que le test a réussi. La sortie réelle, le fichier réel, la ligne réelle.

« Il a modifié mon test au lieu de corriger le code. »

Celle-là fait mal, parce que l’agent fait ce que tu lui as demandé. Tu lui as dit de faire réussir les tests. Il existe deux façons de faire réussir un test qui échoue, et l’une d’elles est beaucoup plus facile.

Dépose-le plutôt quelque part : écris les critères avant le début du travail, puis considère-les comme étant en lecture seule. Si le résultat ne correspond pas, c’est le résultat qui est mauvais. Pas les critères. Cela paraît évident jusqu’au moment où c’est toi qui es tenté de déplacer la cible d’un centimètre.

Pourquoi un fichier CLAUDE.md plus long pousse les agents à ignorer les instructions

Mon premier réflexe a été le même que celui de tout le monde. Tout consigner dans CLAUDE.md. Chaque échec est devenu une nouvelle règle, et le fichier s’est allongé.

La situation a empiré. Pas de façon spectaculaire — juste progressivement, d’une manière qu’il était difficile d’attribuer à quoi que ce soit. Les règles ont commencé à se contredire de façons que je ne voyais pas, et le modèle choisissait silencieusement une interprétation sans jamais signaler le conflit. Lorsque des chercheurs ont réellement testé les fichiers de contexte des dépôts sur de véritables problèmes, ces fichiers n’ont pas du tout amélioré le taux de réussite des tâches. Ils ont ajouté plus de 20 % à la facture d’inférence. Leur conclusion était de réduire le fichier de contexte à ses exigences minimales.

C’est tout le problème en miniature. Un long fichier de règles revient à dire à un système oublieux de faire davantage d’efforts pour se souvenir. Cela lui donne plus de choses à garder en tête, pas moins.

Le cadre que j’ai fini par utiliser comporte une règle qui m’a semblé mauvaise quand je l’ai lue, puis correcte une fois que j’en ai fait l’expérience : chaque nouvelle règle doit supprimer une ancienne règle ou fusionner avec elle. Le nombre de règles ne peut pas augmenter. Quand cela impose un choix difficile, ce choix est précisément le but — tu découvres sur quelles règles tu comptais vraiment.

Cinq endroits où déposer les choses

C’est toute l’idée. Chaque ligne montre quelque chose qui échoue quand on le garde en tête, puis l’endroit où le déposer à la place.

Gardé en tête	Déposé quelque part
Ce que « terminé » était censé vouloir dire	Des critères écrits avant le travail
Si cela a réellement été vérifié	Des preuves que tu peux examiner
Si ton propre travail est de qualité	Un autre modèle qui le vérifie
Ce que tu as décidé il y a trois heures	Un fichier sur le disque
S’il est prudent d’effectuer cette action	Un seuil qui exige un humain

Trois de ces points méritent une explication.

« Je finis quand même par tout vérifier moi-même. »

Si tu as cessé de faire confiance au résultat, tu es désormais le goulot d’étranglement et l’agent ne t’apporte aucun effet de levier.

Demander à l’agent de vérifier son propre travail n’aide pas, et la raison mérite qu’on s’y attarde : c’est le même contexte qui a produit l’erreur, donc il va chercher les mêmes raisons. Il défendra le travail au lieu de le mettre à l’épreuve.

Dépose-le plutôt quelque part : confie la revue à un modèle différent, idéalement d’un autre fournisseur. Un entraînement différent, des angles morts différents. Celui qui a trouvé mon bug sur cinq routes n’était pas celui qui l’avait écrit, et ce n’est pas une coïncidence.

« Quelque chose s’est approuvé tout seul, et ce n’était pas moi. »

Les agents lisent beaucoup de textes qu’ils n’ont pas écrits — fils de discussion, documentation, pages web, sorties d’outils. N’importe lequel peut contenir le mot « approuvé ». L’injection de prompt occupe la première place dans la liste des risques de l’OWASP pour ces systèmes, et l’OWASP dit clairement que les défenses habituelles ne l’atténuent pas complètement.

Dépose-le plutôt quelque part : une approbation dépend de sa provenance, pas de ce qu’elle dit. Un humain a dit oui, ou un artefact signé sur le disque dit oui. Tout le reste qui contient simplement le mot « approuvé » n’est que du texte.

« La compaction a englouti quatre heures de contexte. »

La session s’allonge, le contexte se remplit et la conversation est résumée. Le résumé conserve ce qui s’est passé et perd pourquoi. Une heure plus tard, tu débats de nouveau d’une décision déjà prise, sans pouvoir dire si tu fais preuve de prudence ou si tu tournes en rond.

Dépose-le plutôt quelque part : dans un fichier. Les décisions, l’état actuel, la suite. La session est jetable, le fichier ne l’est pas. Relis-le avant d’affirmer que quoi que ce soit est terminé.

Ce que coûtent les garde-fous pour les agents de codage IA

La forme compte plus que le montant, alors commençons par elle : l’intégration est un coût ponctuel. Tu le paies pendant que tu raccordes les garde-fous à une base de code, et tu ne paies pas cette partie deux fois. La revue indépendante est l’exception — elle s’exécute à chaque modification, donc elle continue de coûter quelque chose après la mise en place.

La répartition est la partie intéressante. Environ 80 % de mes dépenses sont allées au modèle bon marché chargé du travail en volume, près de 17 % au modèle coûteux chargé de la planification et du jugement, et environ 3 % à la revue qui apporte un second avis — l’étape que les gens omettent. La sécurité était de loin le poste le moins cher de la facture. Dans l’ensemble de mes projets, cette répartition est restée à peu près la même alors même que les prix évoluaient.

Quant au montant : sur la plupart des projets auxquels j’ai travaillé, l’ajout de ces garde-fous après coup a coûté environ 100 à 200 dollars d’utilisation de l’API, aux prix d’août 2026. Le ratio compte plus que les dollars — prévois un budget dans cette fourchette et attends-toi à expérimenter. Tu reviendras sur une ou deux décisions et relanceras une phase, et cela fait partie de l’estimation.

Ton montant sera différent, et les facteurs qui le font varier sont évidents : la taille de la base de code, le nombre de fois où tu changes d’avis et la quantité de travail que tu délègues au niveau bon marché.

Commencer un projet nouveau m’a coûté bien moins cher, et c’est l’information la plus utile. L’argent ne va pas au cadre. Il va à la conciliation — décider, un par un, quels outils et habitudes existants les garde-fous remplacent et lesquels ils doivent contourner. Lors de mon intégration, les propres commandes de test du cadre n’ont pas survécu ; elles ont été supprimées et remplacées par les scripts que le projet utilisait déjà. Un nouveau projet n’a rien à concilier.

Commence par un seul

Tu n’as pas besoin des cinq. Choisis l’échec qui te coûte le plus cette semaine et dépose cette seule chose quelque part.

Si tu ne sais pas lequel choisir, commence par la revue indépendante — un second modèle qui examine le travail du premier. C’est le moins cher des cinq et celui qui détecte le plus large éventail de problèmes, y compris ceux que tu ne penserais jamais à chercher.

Le bug sur cinq routes reste mon exemple préféré, parce qu’il n’avait rien de difficile. Il manquait une seule instruction à l’agent : avant de corriger quelque chose, va chercher tout ce qui lui ressemble. Cette instruction vit désormais dans un fichier. Elle sera encore là à la prochaine session, puis à celle d’après, longtemps après que chacun de nous aura oublié pourquoi elle a été écrite.

Le cadre complet, avec les garde-fous et les étapes d’adoption, se trouve sur GitHub.

---

Ressources

• Les fichiers de contexte des dépôts, testés sur de véritables problèmes (ETH Zurich SRI)
• OWASP LLM01 : Injection de prompt
• AGENTS.md, le format de fichier de contexte de dépôt
• La mémoire de Claude Code et CLAUDE.md
• Le cadre agentique, avec les garde-fous et les étapes d’adoption

---