La première erreur que j’ai faite avec les agents IA de code, c’était de traiter chaque mauvais résultat comme un problème de prompt. Si l’agent modifiait le mauvais fichier, je pensais que ma consigne n’était 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 stratégie marche une après-midi. Ensuite on comprend que le problème n’est pas la phrase. Le problème est la surface d’execution donnée a l’agent.
Le débat intéressant en 2026 n’est donc plus seulement "Claude Code ou Codex ?" ni "Cursor ou Copilot ?". Le modèle 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 opérateur junior avec un terminal.
Un prompt est une demande de politique. Un harnais est l’application de cette politique.
Pour une vue plus système, j'ai detaille l'architecture complète dans Architecture d'un agent IA en production : harnais, évaluation et observabilité.
Par "harnais", je ne parle pas d’un template de prompt plus élégant. Je parle du système de contrôle autour du modèle : contexte, outils, permissions, workflow, vérification, reprise et mémoire. Le harnais décide 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 développeurs discutent vraiment
Le marketing public reste magique : décris la feature, attends le patch, merge plus vite. La conversation entre développeurs est moins romantique.
Le Developer Survey 2025 de Stack Overflow montre la tension. Les outils IA sont massivement utilisés ou envisages, mais la confiance ne suit pas au même rythme. La frustration principale concerne les réponses "presque correctes". C’est exactement le problème. Un code presque correct coûte cher, parce qu’il ressemble à du progrès jusqu’au moment ou il faut l’intégrer.
C’est aussi pour ca que le debug de code genere par IA apparaît parmi les grandes frustrations. Un mauvais code qui casse tout de suite est pénible. Un code presque correct est pire. Il passe la première lecture, le happy path et des noms cohérents avec le repo. Puis il casse à la frontière : auth, permissions, migrations, retries, fuseaux horaires, cache, teardown, rollback.
La douleur développeur n’est pas "l’IA ne sait pas coder". Elle sait produire du code. La douleur, c’est que la generation est devenue peu chère alors que la vérification reste coûteuse.
Je vois le même schéma dans les discussions sur Claude Code, Codex, Cursor et MCP : contexte qui déborde, qualité qui dégrade, fichiers modifiés sans rapport, sorties d’outils énormes, actions "logiques" mais dangereuses. Même racine : un harnais faible.
Ce qu’un harnais doit contenir
Un harnais d’agent de code, c’est la discipline runtime autour du modèle. Il couvre sept pièces : contexte, outils, permissions, workflow, vérification, reprise et mémoire. Concrètement, il donne une carte du repo, limite les outils, borné les credentials, impose une revue, lancé des checks externes, garde un chemin de rollback et conserve les décisions importantes.
Quand une de ces pièces manque, le prompt doit compenser. C’est le piégé. On écrit des consignes plus longues, mais l’agent garde le même contexte énorme, le même token trop large, le même shell non borné et la même tendance à 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 contrôle.
Un bon harnais transforme la confiance vague en contraintes banales. Il ne rend pas l’agent magiquement plus intelligent. Il rend l’échec plus petit.
Échec 1 : le contexte qui pourrit
Le contexte qui pourrit est l’échec silencieux. Personne ne perd une base de données. Personne n’écrit un postmortem viral. L’agent devient juste moins bon.
On commencé avec une tâche 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 modèle résumé une tentative ratée. La session accumule. A un moment, le signal utile est encore présent, mais il est enterre sous l’historique.
La documentation Claude Code sur la fenêtre 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, règles et compaction se disputent la même mémoire de travail. Donc "plus de contexte" n’est pas automatiquement mieux. Le contexte n’est pas une bibliothèque. C’est un budget d’attention.
MCP rend le problème plus net. MCP est puissant parce qu’il connecte les agents a de vrais outils et données. Mais les schémas d’outils et les résultats 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 nécessaires garde le working set plus propre. Les discussions Hacker News sur les sorties MCP trop lourdes disent la même chose côté terrain : injecter des pages brutes, listes d’issues, logs et snapshots dans le modèle donne souvent moins de focus, pas plus de capacité.
Ma règle de travail est simple : l’agent doit recevoir une carte, pas une décharge.
Pour une vraie tâche, je veux l’objectif, les fichiers probables, le pattern à copier, les commandes de preuve et les contraintes dures. Je ne veux pas précharger 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 mélange trois sujets.
Le contexte n’est pas la mémoire. 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 à la demande, sorties d’outils résumées ou recherchées, règles durables dans le repo et points de redémarrage quand la session dérive.
Échec 2 : l’accès aux outils transforme une suggestion en incident
Le saut entre assistant et agent arrive quand le modèle peut agir.
Une réponse de chat peut être fausse et rester sans conséquence. Une commande terminal avec credentials peut être fausse et coûter très cher. C’est pour ca que les incidents autour des agents de code génèrent autant de débats. La question intéressante n’est pas de savoir si le modèle avait une mauvaise intention. Il n’en avait pas. La question est que le système a accepte l’action.
Les discussions sur Replit, Cursor, Claude Code et les bases de données supprimées exposent le même 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 modèle s’excuse ensuite. La vraie question est opérationnelle :
L’agent pouvait-il s’authentifier ?
Pouvait-il exécuter l’action destructive ?
Pouvait-il contourner un point d’approbation humaine ?
Pouvait-il supprimer ce dont la recovery dépendait ?
Si la réponse est oui, le harnais avait déjà échoue 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 sécurité n’est pas une vibe. C’est séparation d’environnement, credentials scopes, approbations, CI, logs d’audit et discipline de rollback.
La plus grosse erreur est de donner a l’agent votre autorité normale de développeur. Les humains ont du jugement et du contexte social. Les agents ont des patterns, des tool calls et un objectif local. Les traiter comme équivalents est une faiblesse de design.
Un agent de code devrait généralement avoir un accès filesystem limite au repo, aucun secret de production par défaut, de l’observabilité read-only, des commandes destructives bloquées, des credentials staging separes, aucun deploy direct, une sortie en pull request et des logs d’outils.
Oui, cela ralentit certaines tâches. 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.
Échec 3 : l’agent optimise le succès visible
Les agents de code sont très bons pour satisfaire la forme visible d’une tâche. C’est utile jusqu’au moment ou cette forme visible est incomplète.
Demandez un test en échec puis un correctif. L’agent peut adapter le test à son implémentation. 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 vérification externe, parce que la confiance du modèle n’est pas une preuve.
La boucle minimale utile est :
read -> scope -> act -> verify -> record
Read : inspecter les vrais fichiers. Scope : déclarer ce qui change et ce qui ne change pas. Act : modifier uniquement la surface déclarée. Verify : lancer des checks externes. Record : noter ce qui a change, ce qui a échoue et ce qu’il faudra surveiller.
Les pratiques publiées 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, améliorer l’environnement de développement au fil du temps. C’est une logique de harnais. Le prompt n’est qu’une entrée du système.
L’agent ne doit pas définir seul ce que "termine" veut dire.
Termine veut dire : diff scope, tests pertinents, checks executes, fichiers modifiés relus, artefacts attendus, aucun changement sans rapport et rollback évident.
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, vérification et conditions d’arrêt. Ne demandez pas au modèle d’être 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’idée de connecter tous les outils juste parce que c’est puissant.
MCP doit être traite comme l’ajout de nouvelles capacités sur le poste d’un employe. Un serveur MCP GitHub n’est pas seulement "plus de contexte". Il peut exposer issues, PR, données repo et parfois des actions d’ecriture. Un serveur MCP database n’est pas une simple commodité. Il peut exposer des données 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 sûre pour cette tâche ?"
Bonne hygiène MCP : outils à la demande, read-only d’abord, grosses sorties paginées ou résumées, credentials isolés par environnement, pas d’ecriture production par défaut, appels logges, outils inutiles retires.
L’outillage doit aider l’agent à récupérer la bonne tranche de réalité. Il ne doit pas verser toute l’entreprise dans la fenêtre de contexte.
L’opinion forte
Voici l’opinion que je défendrais devant une équipe d’ingénieurs :
La plupart des équipes qui demandent de "meilleurs prompts IA" ont surtout besoin d’un meilleur système 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 frontières de permissions.
Si l’agent livre des bugs plausibles, il faut de la vérification externe.
Si l’agent repete la même erreur la semaine suivante, il faut une mémoire durable.
Le modèle peut s’améliorer et ces choses resteront nécessaires. Les meilleurs modèles réduisent le taux d’erreur. Ils ne suppriment pas le rayon d’explosion. Un senior peut aussi faire une mauvaise modification en production ; la différence est que les équipes matures ne prennent pas "sois prudent" comme politique de déploiement.
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 même modèle et obtenir des résultats totalement différents. L’une discute avec un modèle. L’autre execute une boucle contrôlée.
Checklist pratique
Avant de donner une vraie tâche à un agent IA de code, je veux cette checklist : tâche petite et reviewable, fichiers dans le scope nommes, fichiers hors scope nommes, pattern existant indique, commandes destructives bloquées, secrets de production indisponibles, outils MCP charges seulement si nécessaires, test ou check de preuve, revue humaine avant merge ou deploy, rollback évident, trace utile pour la prochaine session.
Ce dernier point est sous-estimé. Un bon harnais laisse des traces : notes de tâche, décisions, échecs, commandes et raisons des choix bizarres.
Questions fréquentes
Pourquoi un meilleur prompt ne suffit-il pas pour un agent de code ?
Parce qu'un prompt ne limite rien : si l'agent peut exécuter une commande destructive avec des credentials larges, aucune consigne ne l'en empêche réellement. Le contrôle doit vivre dans l'environnement : outils, permissions, sandbox et vérifications.
Qu'est-ce que la dégradation du contexte d'un agent IA ?
La baisse progressive de qualité quand le contexte se remplit de fichiers, de sorties d'outils et d'historique peu utiles. La correction : une mission par session, un contexte ciblé, des sorties d'outils résumées et des règles durables stockées dans le dépôt.
Comment vérifier le travail d'un agent de code ?
Par des contrôles externes à l'agent : tests, typecheck, lint, CI et revue humaine du diff. La confiance du modèle n'est pas une preuve ; l'agent doit déclarer ce qu'il modifie et ce qu'il a vérifié.
L’article que j’aurais voulu lire plus tôt
Si le code compte, arrêtez de traiter l’agent comme un autocomplete plus intelligent. Il ressemble plutôt à un prestataire très motivé, qui travaille a vitesse machine, avec un jugement inégal et des outils que vous avez parfois oublie de connecter.
Donnez-lui un harnais.
Contexte petit. Scope étroit. Outils bornes. Permissions dures. Vérification externe. Mémoire durable. Chemins de reprise. C’est ainsi que l’IA compresse le répétitif sans supprimer le jugement qui rend un logiciel livrable.
Pour la couche sécurité production, lisez Garde-fous pour agents IA de code. Pour la couche outil, lisez Model Context Protocol expliqué. Pour l’architecture des boucles agent, lisez Comment fonctionnent les agents IA. Si vous évaluez mon profil pour une équipe ou un projet, commencez par la section agents IA et automatisation de ma page recrutement ou par mes services freelance.
