Les agents IA de code n’ont pas besoin d’un meilleur prompt. Ils ont besoin d’un harnais.

La premiere erreur que j’ai faite avec les agents IA de code, c’etait de traiter chaque mauvais resultat comme un probleme de prompt. Si l’agent modifiait le mauvais fichier, je pensais que ma consigne n’etait pas claire. S’il oubliait une contrainte, j’ajoutais un paragraphe. S’il produisait du code plausible mais faux, je demandais un plan detaille. Cette strategie marche une apres-midi. Ensuite on comprend que le probleme n’est pas la phrase. Le probleme est la surface d’execution donnee a l’agent.

Le debat interessant en 2026 n’est donc plus seulement "Claude Code ou Codex ?" ni "Cursor ou Copilot ?". Le modele n’est plus tout le produit. Quand un assistant peut lire un repo, modifier des fichiers, lancer des commandes shell, appeler MCP ou ouvrir une pull request, ce n’est plus de l’autocomplete. C’est un operateur junior avec un terminal.

Un prompt est une demande de politique. Un harnais est l’application de cette politique.

Par "harnais", je ne parle pas d’un template de prompt plus elegant. Je parle du systeme de controle autour du modele : contexte, outils, permissions, workflow, verification, reprise et memoire. Le harnais decide ce que l’agent voit, ce qu’il peut toucher, ce qu’il doit prouver et ce qui se passe quand il se trompe.

Ce que les developpeurs discutent vraiment

Le marketing public reste magique : decris la feature, attends le patch, merge plus vite. La conversation entre developpeurs est moins romantique.

Le Developer Survey 2025 de Stack Overflow montre la tension. Les outils IA sont massivement utilises ou envisages, mais la confiance ne suit pas au meme rythme. La frustration principale concerne les reponses "presque correctes". C’est exactement le probleme. Un code presque correct coute cher, parce qu’il ressemble a du progres jusqu’au moment ou il faut l’integrer.

C’est aussi pour ca que le debug de code genere par IA apparait parmi les grandes frustrations. Un mauvais code qui casse tout de suite est penible. Un code presque correct est pire. Il passe la premiere lecture, le happy path et des noms coherents avec le repo. Puis il casse a la frontiere : auth, permissions, migrations, retries, fuseaux horaires, cache, teardown, rollback.

La douleur developpeur n’est pas "l’IA ne sait pas coder". Elle sait produire du code. La douleur, c’est que la generation est devenue peu chere alors que la verification reste couteuse.

Je vois le meme schema dans les discussions sur Claude Code, Codex, Cursor et MCP : contexte qui deborde, qualite qui degrade, fichiers modifies sans rapport, sorties d’outils enormes, actions "logiques" mais dangereuses. Meme racine : un harnais faible.

Ce qu’un harnais doit contenir

Un harnais d’agent de code, c’est la discipline runtime autour du modele. Il couvre sept pieces : contexte, outils, permissions, workflow, verification, reprise et memoire. Concretement, il donne une carte du repo, limite les outils, borne les credentials, impose une revue, lance des checks externes, garde un chemin de rollback et conserve les decisions importantes.

Quand une de ces pieces manque, le prompt doit compenser. C’est le piege. On ecrit des consignes plus longues, mais l’agent garde le meme contexte enorme, le meme token trop large, le meme shell non borne et la meme tendance a produire un patch qui a l’air termine.

Si l’agent peut faire la mauvaise chose en une commande, le prompt n’est pas la couche de controle.

Un bon harnais transforme la confiance vague en contraintes banales. Il ne rend pas l’agent magiquement plus intelligent. Il rend l’echec plus petit.

Echec 1 : le contexte qui pourrit

Le contexte qui pourrit est l’echec silencieux. Personne ne perd une base de donnees. Personne n’ecrit un postmortem viral. L’agent devient juste moins bon.

On commence avec une tache claire. L’agent lit cinq fichiers. Puis les tests. Puis un log de build. Puis un package file. Puis une issue longue. Puis un serveur MCP retourne un gros payload. Puis on colle une erreur. Puis le modele resume une tentative ratee. La session accumule. A un moment, le signal utile est encore present, mais il est enterre sous l’historique.

La documentation Claude Code sur la fenetre de contexte est utile parce qu’elle rend visible ce qui ne l’est pas : instructions, fichiers lus, sorties d’outils, historique de conversation, skills, regles et compaction se disputent la meme memoire de travail. Donc "plus de contexte" n’est pas automatiquement mieux. Le contexte n’est pas une bibliotheque. C’est un budget d’attention.

MCP rend le probleme plus net. MCP est puissant parce qu’il connecte les agents a de vrais outils et donnees. Mais les schemas d’outils et les resultats peuvent consommer beaucoup d’espace. La documentation Claude sur MCP et tool search existe pour une bonne raison : charger les outils seulement quand ils sont necessaires garde le working set plus propre. Les discussions Hacker News sur les sorties MCP trop lourdes disent la meme chose cote terrain : injecter des pages brutes, listes d’issues, logs et snapshots dans le modele donne souvent moins de focus, pas plus de capacite.

Ma regle de travail est simple : l’agent doit recevoir une carte, pas une decharge.

Pour une vraie tache, je veux l’objectif, les fichiers probables, le pattern a copier, les commandes de preuve et les contraintes dures. Je ne veux pas precharger tous les documents, tous les outils, toutes les issues et toutes les anciennes conversations "au cas ou". C’est comme ca qu’on obtient un agent qui melange trois sujets.

Le contexte n’est pas la memoire. Le contexte est une pression sur l’attention.

La correction n’est pas un prompt magique. C’est un protocole de contexte : une mission par session, contrats courts, lecture de fichiers a la demande, sorties d’outils resumees ou recherchees, regles durables dans le repo et points de redemarrage quand la session derive.

Echec 2 : l’acces aux outils transforme une suggestion en incident

Le saut entre assistant et agent arrive quand le modele peut agir.

Une reponse de chat peut etre fausse et rester sans consequence. Une commande terminal avec credentials peut etre fausse et couter tres cher. C’est pour ca que les incidents autour des agents de code generent autant de debats. La question interessante n’est pas de savoir si le modele avait une mauvaise intention. Il n’en avait pas. La question est que le systeme a accepte l’action.

Les discussions sur Replit, Cursor, Claude Code et les bases de donnees supprimees exposent le meme fait inconfortable : si un agent peut atteindre la production avec des credentials larges, alors la production est dans son rayon d’explosion. Peu importe que l’instruction dise "staging". Peu importe que le modele s’excuse ensuite. La vraie question est operationnelle :

L’agent pouvait-il s’authentifier ?

Pouvait-il executer l’action destructive ?

Pouvait-il contourner un point d’approbation humaine ?

Pouvait-il supprimer ce dont la recovery dependait ?

Si la reponse est oui, le harnais avait deja echoue avant le premier token.

C’est le point central de mon guide sur les garde-fous pour agents IA de code : utiliser des agents en securite n’est pas une vibe. C’est separation d’environnement, credentials scopes, approbations, CI, logs d’audit et discipline de rollback.

La plus grosse erreur est de donner a l’agent votre autorite normale de developpeur. Les humains ont du jugement et du contexte social. Les agents ont des patterns, des tool calls et un objectif local. Les traiter comme equivalents est une faiblesse de design.

Un agent de code devrait generalement avoir un acces filesystem limite au repo, aucun secret de production par defaut, de l’observabilite read-only, des commandes destructives bloquees, des credentials staging separes, aucun deploy direct, une sortie en pull request et des logs d’outils.

Oui, cela ralentit certaines taches. Tant mieux. Parfois, la friction est le produit.

L’agent le plus rapide n’est pas celui qui peut tout faire. C’est celui qui peut faire la bonne chose sans agrandir le rayon d’explosion.

Echec 3 : l’agent optimise le succes visible

Les agents de code sont tres bons pour satisfaire la forme visible d’une tache. C’est utile jusqu’au moment ou cette forme visible est incomplete.

Demandez un test en echec puis un correctif. L’agent peut adapter le test a son implementation. Demandez de rendre la CI verte. Il peut retirer la branche de code qui revele l’erreur. Demandez de simplifier un flux. Il peut supprimer un edge case parce que l’edge case complique le patch. Ce n’est pas un mensonge au sens humain. C’est une optimisation dans une boucle de feedback faible.

Le harnais a besoin d’une verification externe, parce que la confiance du modele n’est pas une preuve.

La boucle minimale utile est :

read -> scope -> act -> verify -> record

Read : inspecter les vrais fichiers. Scope : declarer ce qui change et ce qui ne change pas. Act : modifier uniquement la surface declaree. Verify : lancer des checks externes. Record : noter ce qui a change, ce qui a echoue et ce qu’il faudra surveiller.

Les pratiques publiees par OpenAI sur l’usage de Codex vont dans ce sens : commencer par le plan pour les gros changements, structurer les demandes comme des issues GitHub, fournir du contexte persistant via AGENTS.md, ameliorer l’environnement de developpement au fil du temps. C’est une logique de harnais. Le prompt n’est qu’une entree du systeme.

L’agent ne doit pas definir seul ce que "termine" veut dire.

Termine veut dire : diff scope, tests pertinents, checks executes, fichiers modifies relus, artefacts attendus, aucun changement sans rapport et rollback evident.

L’IA ne supprime pas la discipline. Elle rend son absence plus visible.

Le template de brief que je veux vraiment

Voici le type de brief que je prefere maintenant. Ce n’est pas poetique, mais ca marche.

Objectif :
Corriger les tokens de reset password expires qui retournent 500 au lieu de 400.

Comportement utilisateur :
Quand le token est expire, retourner HTTP 400 avec le code TOKEN_EXPIRED.

Fichiers dans le scope :
- app/api/password-reset/route.ts
- lib/auth/password-reset.ts
- tests/auth/password-reset.test.ts

Fichiers hors scope :
- schema database
- templates email
- middleware de session

Commandes autorisees :
- npm run test -- password-reset
- npm run typecheck

Approche requise :
- Ajouter ou mettre a jour un test en echec d’abord.
- Reutiliser le pattern AppError existant.
- Ne pas changer la forme publique de la reponse sauf pour le cas token expire.

S’arreter et demander si :
- une migration semble necessaire ;
- le modele de token est incoherent ;
- une commande demande des credentials de production.

Definition de fini :
- test cible vert ;
- typecheck vert ;
- diff sans formatage sans rapport ;
- resume du changement et du risque residuel.

C’est un contrat de harnais compact : contexte, permissions, workflow, verification et conditions d’arret. Ne demandez pas au modele d’etre prudent dans l’abstrait. Rendez la surface d’execution explicite.

Ce que cela change pour MCP

Je suis optimiste sur Model Context Protocol, mais je ne suis pas optimiste sur l’idee de connecter tous les outils juste parce que c’est puissant.

MCP doit etre traite comme l’ajout de nouvelles capacites sur le poste d’un employe. Un serveur MCP GitHub n’est pas seulement "plus de contexte". Il peut exposer issues, PR, donnees repo et parfois des actions d’ecriture. Un serveur MCP database n’est pas une simple commodite. Il peut exposer des donnees clients. Un serveur MCP navigateur n’est pas juste un test visuel. Il peut transporter de l’etat de session.

La question n’est pas "est-ce que l’agent peut l’utiliser ?" La question est : "quelle est la plus petite surface d’outil sure pour cette tache ?"

Bonne hygiene MCP : outils a la demande, read-only d’abord, grosses sorties paginees ou resumees, credentials isoles par environnement, pas d’ecriture production par defaut, appels logges, outils inutiles retires.

L’outillage doit aider l’agent a recuperer la bonne tranche de realite. Il ne doit pas verser toute l’entreprise dans la fenetre de contexte.

L’opinion forte

Voici l’opinion que je defendrais devant une equipe d’ingenieurs :

La plupart des equipes qui demandent de "meilleurs prompts IA" ont surtout besoin d’un meilleur systeme de livraison.

Si l’agent oublie les contraintes, il faut une discipline de contexte.

Si l’agent touche des fichiers sans rapport, il faut des work orders scopes.

Si l’agent peut supprimer la production, il faut des frontieres de permissions.

Si l’agent livre des bugs plausibles, il faut de la verification externe.

Si l’agent repete la meme erreur la semaine suivante, il faut une memoire durable.

Le modele peut s’ameliorer et ces choses resteront necessaires. Les meilleurs modeles reduisent le taux d’erreur. Ils ne suppriment pas le rayon d’explosion. Un senior peut aussi faire une mauvaise modification en production ; la difference est que les equipes matures ne prennent pas "sois prudent" comme politique de deploiement.

Le futur du code avec IA n’est pas le prompt engineering. C’est le harness engineering.

Cela explique pourquoi deux personnes peuvent utiliser le meme modele et obtenir des resultats totalement differents. L’une discute avec un modele. L’autre execute une boucle controlee.

Checklist pratique

Avant de donner une vraie tache a un agent IA de code, je veux cette checklist : tache petite et reviewable, fichiers dans le scope nommes, fichiers hors scope nommes, pattern existant indique, commandes destructives bloquees, secrets de production indisponibles, outils MCP charges seulement si necessaires, test ou check de preuve, revue humaine avant merge ou deploy, rollback evident, trace utile pour la prochaine session.

Ce dernier point est sous-estime. Un bon harnais laisse des traces : notes de tache, decisions, echecs, commandes et raisons des choix bizarres.

L’article que j’aurais voulu lire plus tot

Si le code compte, arretez de traiter l’agent comme un autocomplete plus intelligent. Il ressemble plutot a un prestataire tres motive, qui travaille a vitesse machine, avec un jugement inegal et des outils que vous avez parfois oublie de connecter.

Donnez-lui un harnais.

Contexte petit. Scope etroit. Outils bornes. Permissions dures. Verification externe. Memoire durable. Chemins de reprise. C’est ainsi que l’IA compresse le repetitif sans supprimer le jugement qui rend un logiciel livrable.

Pour la couche securite production, lisez Garde-fous pour agents IA de code. Pour la couche outil, lisez Model Context Protocol explique. Pour l’architecture des boucles agent, lisez Comment fonctionnent les agents IA. Si vous evaluez mon profil pour une equipe produit ou automatisation, commencez par ma page developpeur IA automatisation.