Trois agents, un même harnais
Récemment, dans le cadre d’une mission freelance, j’ai donné une formation au codage agentique à une équipe de développement. Situation classique de l’été 2026 : le client n’avait pas encore arrêté son choix sur l’outil que ses développeurs et développeuses allaient utiliser. Claude Code ? OpenCode ? Junie, l’agent de JetBrains ? Le choix était encore ouvert, et je n’allais pas le faire à leur place.
Alors j’ai fait autre chose. J’ai préparé mes démonstrations sur les trois agents à la fois. Trois outils différents, édités par trois acteurs différents, propulsés par des modèles différents. Mais avec une décision structurante : les trois partageaient exactement le même environnement de travail. Le même fichier de mémoire projet, les mêmes procédures documentées, les mêmes connexions aux services externes, les mêmes outils en ligne de commande, quasiment les mêmes permissions. Tout ce qui entoure le modèle, à l’identique.
Et pendant la formation, démo après démo, le même constat s’est imposé : les trois agents produisaient des résultats quasi similaires. Pas identiques au caractère près, évidemment. Mais similaires dans la démarche, dans la qualité, dans le respect des conventions du projet. Prévisibles.
Trois agents, trois modèles, un même harnais : un même comportement.
Si vous avez trouvé ce résultat surprenant, cet article est pour vous. Et si vous êtes en train de vous dire « oui, évidemment », restez quand même : c’est de vos équipes qu’on va parler.
Le débat qui occupe tout le monde
Ouvrez n’importe quel réseau social à dominante tech, n’importe quel agrégateur, n’importe quel Slack de dev. Le débat est partout, en continu : quel est le meilleur agent pour coder ? Claude Code ou Codex ? Codex ou OpenCode ? Et le nouveau venu de la semaine, il est comment ? Chaque sortie de modèle relance la machine, chaque benchmark rebat les cartes, chaque influenceur tech y va de son comparatif.
Je vais le dire sans détour : ce débat est futile. C’est un débat de X/Twitter. Il est divertissant à la minute, il génère de l’engagement, il donne l’impression d’être à la page. Et il n’apprend rien d’utile à personne.
Il y a exactement un moment où la comparaison a du sens : celui où une équipe choisit son outil pour les six ou douze prochains mois. Parce que soyons honnêtes, une équipe ne va pas changer d’agent tous les deux mois, ce serait absolument ridicule. À ce moment-là, oui, testez. Et encore : pas besoin de grille d’évaluation pondérée ni de protocole scientifique. Prenez les leaders du marché, essayez-en un pendant quelques jours, puis l’autre, et gardez celui avec lequel l’équipe a le meilleur feeling. Il n’y a réellement pas de mauvais choix : vous prenez Claude Code ou Codex en juillet 2026, et tout va bien se passer pour vous.
Le reste du temps, ce débat est du bruit. Et pendant que vos développeurs et développeuses scrollent les comparatifs, la vraie compétence, celle qui déterminera leur efficacité avec ces outils, ne se construit pas.
C’est à vous que je m’adresse, lead devs, tech leads, CTO : le temps et le budget que vous consacrez à la question « quel outil » seraient bien mieux investis sur une autre question. Qu’est-ce qui fait qu’un agent fonctionne bien, quel que soit l’outil ? La réponse tient en deux concepts : la boucle agentique, et le harnais. Et ils s’apprennent.
Le socle : un modèle amnésique et une fenêtre limitée
Avant de parler de boucle et de harnais, deux notions de base. Je vais aller vite, mais elles rendent tout le reste limpide.
Premièrement : le modèle est amnésique. Un LLM ne se souvient de rien entre deux appels. La « mémoire » d’une conversation est une illusion fabriquée par l’outil, qui relit l’intégralité du dossier au modèle avant chaque question. Comme un expert brillant mais amnésique, à qui il faudrait rappeler tout le contexte à chaque échange.
Deuxièmement : tout ce que le modèle « voit » tient dans une fenêtre de contexte de taille limitée. Les instructions, l’historique, les fichiers lus, les résultats des commandes : tout entre en concurrence dans cet espace. Ce qui en déborde n’existe plus pour le modèle. C’est une mémoire de travail, pas un disque dur, et c’est la ressource la plus précieuse du développement agentique.
Gardez ces deux idées en tête. Tout ce qui suit en découle.
La boucle agentique : le concept fondamental
Qu’est-ce qui sépare un chatbot d’un agent de code ? Ce n’est pas l’intelligence du modèle. C’est ce qu’on lui permet de faire.
Avec un chatbot, le modèle propose du texte, et c’est vous qui copiez, collez, exécutez, testez, puis revenez lui expliquer ce qui s’est passé. La boucle, c’est vous qui la faites tourner. Avec un agent, cette boucle est automatisée : l’agent rassemble le contexte, le modèle décide d’une action, des outils l’exécutent (lire un fichier, modifier du code, lancer une commande), le résultat revient dans le contexte, et on recommence jusqu’à ce qu’un critère d’arrêt soit atteint. Rassembler, agir, constater, recommencer.
C’est tout. Il n’y a pas de magie, pas de moteur de planification secret. Simon Willison, l’un des observateurs les plus fiables du domaine, définit un agent comme « quelque chose qui exécute des outils en boucle pour atteindre un objectif ». Thorsten Ball, dans un article devenu culte, a démontré qu’un agent fonctionnel tient en moins de 400 lignes de code et trois outils, et l’a résumé d’une formule : « un LLM, une boucle, et assez de tokens ».
L’intelligence est dans le modèle. L’autonomie est dans la boucle.
Et si cette boucle fonctionne si bien sur le code, c’est parce que notre métier offre quelque chose de rare : une vérification objective et gratuite. Le compilateur dit si ça compile, les tests disent si ça marche, le linter dit si c’est propre. À chaque tour de boucle, l’agent peut constater ses propres erreurs et se corriger. Peu de métiers offrent un retour aussi net ; c’est pour ça que le développement logiciel est le terrain idéal des agents.
Comprendre cette boucle n’est pas de la culture générale. C’est ce qui permet de bien s’en servir. Quand vous savez que l’agent tourne en boucle jusqu’à un critère d’arrêt, vous comprenez pourquoi une consigne floue (« améliore le code ») produit des dérives : l’agent ne sait pas quand sortir de la boucle. Une consigne avec un critère de fini explicite (« ce test doit passer », « ce comportement doit être observable ») lui donne sa condition de sortie. Ce n’est pas de la magie noire du prompt, c’est de la logique de boucle.
Le harnais : on ne conduit pas un moteur
Venons-en au concept central de cet article.
Un modèle seul, aussi puissant soit-il, est inutilisable pour travailler. Il raisonne, il décide, il génère, mais il ne sait ni lire vos fichiers, ni exécuter vos tests, ni se souvenir de vos conventions. Le modèle est un moteur. Et on ne conduit pas un moteur : on conduit une voiture. Le châssis, la direction, les freins, le tableau de bord, tout ce qui transforme une force brute en véhicule utilisable, c’est ce qu’on appelle le harnais.
Le mot mérite son clin d’œil étymologique : un harnais, à l’origine, c’est l’équipement du cheval. Les rênes, la selle, le mors. Ce qui canalise un animal puissant et imprévisible pour en faire une force utile et dirigée. On ne choisit pas ce vocabulaire par hasard.
Concrètement, le harnais, c’est tout ce qui, dans un agent, n’est pas le modèle lui-même, pour reprendre la définition de Birgitta Böckeler chez Thoughtworks. Faisons l’inventaire, parce que chaque brique est une connaissance qui vit au-delà de l’outil :
- Le prompt système : la fiche de poste invisible de l’agent, injectée à chaque conversation. C’est lui qui fait qu’un même modèle se comporte en agent de code ici et en chatbot ailleurs.
- Les outils natifs : les mains de l’agent. Lire, écrire, chercher, exécuter des commandes. Le modèle ne « voit » jamais votre machine : il demande au harnais d’exécuter un outil et reçoit le résultat en texte.
- Les permissions : le contrat de confiance. Chaque action risquée passe par une autorisation, et ce niveau de confiance se règle, il n’est pas subi.
- La mémoire projet : un fichier markdown versionné avec le code, lu à chaque session, qui contient les conventions, les commandes, les pièges du projet. Ce qui transforme un agent générique en agent qui connaît votre codebase.
- Les sous-agents : la délégation. Confier une recherche à un agent secondaire qui revient avec une synthèse, en gardant le détail hors de votre précieuse fenêtre de contexte.
- Les hooks : l’automatisation. Formater après chaque édition, lancer les tests avant un commit.
- La compaction : la survie. Quand le contexte approche de sa limite, le harnais résume l’historique pour continuer.
- Les MCP et les CLI : les connexions au monde réel. Un serveur MCP branche l’agent sur vos services externes ; une simple commande documentée fait souvent aussi bien, pour moins cher en contexte.
- Les skills : les savoir-faire. Des procédures écrites une fois, en markdown, chargées seulement quand la tâche s’y prête. Votre façon de faire une revue de code, une release note, un module.
Voilà le harnais. Et voilà exactement ce sur quoi vos équipes devraient monter en compétence : savoir ce qui le compose, comprendre le rôle de chaque brique, et savoir s’en saisir. Le prompt système, les outils, les permissions, la mémoire, les sous-agents : tout cela constitue un socle de connaissances qui vit au-delà de l’outil et du modèle.
Quinze mois pour devenir une discipline
Le concept s’est d’ailleurs institutionnalisé à une vitesse remarquable. Avril 2025 : Thorsten Ball démystifie la boucle. Juin 2025 : Andrej Karpathy popularise le « context engineering ». Décembre 2025 : Philipp Schmid, chez Google DeepMind, prédit que « si 2025 a été le début des agents, 2026 sera l’année des harnais ». Début 2026 : OpenAI, Thoughtworks et Addy Osmani publient chacun leur guide de « harness engineering », et une page « Harnais d’agent » apparaît sur le Wikipédia francophone. En quinze mois, une intuition de bidouilleurs est devenue une discipline d’ingénierie nommée et documentée.
Le harnais pèse plus lourd que vous ne le pensez
Vous trouvez que j’exagère l’importance du harnais par rapport au modèle ? Un chiffre, alors. Le benchmark Agent Security League d’Endor Labs, relayé par l’analyste Tomasz Tunguz, a mesuré la performance d’un même modèle, GPT-5.5, dans deux harnais différents : 61,5 % de justesse fonctionnelle dans l’un, 87,2 % dans l’autre. Plus de 25 points d’écart. Même moteur, deux voitures, deux résultats. La conclusion de Tunguz est limpide : « le harnais fait désormais plus bouger les benchmarks de code que le modèle ».
Addy Osmani le formule autrement dans son guide chez O’Reilly : « un modèle correct avec un excellent harnais bat un excellent modèle avec un mauvais harnais ».
Soyons précis sur ce que ça veut dire, et sur ce que ça ne veut pas dire. On parle ici de modèles qui jouent dans la même cour. Entre un modèle haut de gamme d’OpenAI et un modèle haut de gamme d’Anthropic, la différence à l’instant T existe peut-être, mais elle est largement surestimée. À capacité de modèle équivalente, le poids du harnais domine. C’est exactement ce que montrait ma formation : avec un harnais bien construit, des agents de fournisseurs différents, motorisés par des modèles différents, produisent des résultats remarquablement proches.
Et c’est là que se joue l’argument qui devrait parler à tous les tech leads : la prévisibilité. Un modèle de langage est, par nature, non déterministe. Posez-lui deux fois la même question, vous n’aurez pas deux fois la même réponse. C’est une propriété du moteur, et aucun fournisseur ne la fera disparaître. Ce qui ramène de la prévisibilité dans le système, c’est le harnais : la mémoire projet qui impose les conventions, les permissions qui bornent les actions, les tests qui vérifient chaque tour de boucle, les skills qui standardisent les procédures. Une équipe n’a pas besoin de l’agent le plus performant du mois. Elle a besoin d’un système prévisible, reproductible d’un développeur à l’autre et d’un outil à l’autre. Ça, ça ne s’achète pas avec une licence. Ça se construit.
Une objection revient parfois : « si j’investis dans mon harnais, je m’enferme chez un éditeur ». C’est une non-question. Pour ma formation, le fichier mémoire n’existait qu’une seule fois sur le disque : un lien symbolique le rendait accessible sous le nom attendu par chacun des trois agents. Mêmes skills, mêmes MCP, mêmes CLI. Au pire, migrer un harnais consiste à renommer quelques fichiers. Le harnais n’appartient pas à l’outil : il appartient à votre équipe, versionné dans vos dépôts, à côté de votre code.
Les compétences qui survivront à vos outils
Si je devais résumer les compétences du développeur et de la développeuse de 2026, et probablement de demain, je le ferais en deux mots : le harnais, et le contexte.
Le harnais, on vient d’en faire le tour. Le contexte, c’est l’autre versant, individuel celui-là : savoir nourrir la boucle. Puisque le modèle est amnésique et que sa fenêtre est limitée, la qualité de ce que vous y mettez détermine la qualité de ce qui en sort. Ça veut dire des consignes extrêmement claires, avec un objectif, un périmètre, et surtout un critère d’arrêt explicite : l’agent doit pouvoir identifier à quel moment il peut sortir de la boucle. Ça veut dire des sessions courtes et ciblées, plutôt que des conversations fleuves où l’on revient sans cesse, où l’on corrige, où l’on dérive, et où le contexte finit en ruine. Une tâche, une session. Quand ça dérive, on ne s’acharne pas : on re-cadre et on repart propre. Anthropic a documenté cette discipline sous le nom de context engineering ; c’est une vraie compétence d’ingénierie, et elle est intégralement transférable d’un outil à l’autre.
Autour de ce duo, trois compétences complètent le tableau.
La relecture, d’abord. Le changement de posture est acté, j’en parlais déjà dans Le silence est un choix : nous passons d’auteurs de chaque ligne à architectes et relecteurs. Une grande partie de notre activité consiste désormais à relire du code que nous n’avons pas écrit, à le juger vite et bien, à repérer rapidement ce qui pose problème. Savoir lire du code devient plus précieux que savoir le taper.
L’écriture de skills, ensuite. C’est la compétence montante des lead devs et des CTO. Vos conventions, votre processus de merge request, vos checklists de mise en production : tout savoir-faire répétitif de l’équipe peut être écrit une fois, versionné, et appliqué par l’agent de chacun. Le savoir-faire cesse de vivre dans les têtes et dans les habitudes individuelles ; il devient un actif de l’équipe. Un nouveau développeur récupère les pratiques de la maison le jour de son arrivée. C’est de la capitalisation au sens le plus littéral.
L’outillage des projets, enfin. Tests, linters, CI, environnements reproductibles : tout ce qu’on classait dans les « bonnes pratiques » devient une infrastructure critique pour les agents. Chaque vérification automatisée est une boucle de feedback rapide que l’agent s’applique à lui-même, une erreur qu’il corrige seul au lieu de revenir vers vous. Un projet bien outillé rend l’agent autonome ; un projet mal outillé le rend aveugle. Vos bonnes pratiques d’hier sont le filet de sécurité de vos agents d’aujourd’hui.
Notez ce qui n’est pas dans cette liste : la maîtrise des menus de tel outil, les raccourcis de tel autre, la connaissance encyclopédique des tarifs et des limites de chaque fournisseur. Tout ça se périme en un trimestre. Le reste se transfère.
Un débat qui, lui, mérite votre temps
Puisque j’ai été sévère avec les débats d’outils, je vous dois un contre-exemple : à quoi ressemble un débat qui mérite vraiment l’attention de vos équipes ?
En voici un, et il est brûlant : faut-il encore relire le code généré par les agents ?
Mi-juillet, Salvatore Sanfilippo, le créateur de Redis, qu’on ne peut accuser ni d’amateurisme ni de complaisance, a publié un billet au titre programmatique : « Contrôlez les idées, pas le code ». Son argument est arithmétique : « comment êtes-vous censé relire 5 000 lignes de code par jour ? ». Sa réponse : contrôler le design, les invariants, la QA et les tests, plutôt que les lignes. Peter Steinberger, figure de la scène iOS, va plus loin encore : « ces temps-ci, je ne lis plus beaucoup de code ».
En face, Armin Ronacher, le créateur de Flask, revendique la position inverse : plus de 90 % de son code est écrit par des agents, mais « je considère chaque ligne comme ma responsabilité, jugée comme si je l’avais écrite moi-même ». Et Mitchell Hashimoto, sur le projet Ghostty, ferme désormais sans discussion les pull requests générées par IA que leurs auteurs n’ont visiblement jamais lues.
Entre les deux, Addy Osmani propose la synthèse la plus structurée : la revue ligne à ligne, « c’est terminé, le volume y a mis fin », mais l’effort de relecture doit être proportionnel au coût de l’erreur. Un fichier de configuration se survole ; un module de paiement se relit à plusieurs, humains et agents confondus. Avec une mise en garde qui mérite d’être méditée : faire relire un agent par d’autres agents aux angles morts corrélés produit une « confiance empruntée », pas une vérification.
Les chiffres disent l’ampleur du basculement : d’après l’enquête 2026 de Sonar auprès de plus de 1 100 développeurs, seuls 48 % vérifient systématiquement le code généré avant de le committer, alors que 96 % déclarent ne pas lui faire totalement confiance. Ce grand écart est vertigineux.
Où est-ce que je me situe ? Je vais être honnête : mon avis n’est pas arrêté. Aujourd’hui, dans mon équipe, on relit sérieusement ce que les agents produisent. Mais j’écrivais déjà il y a quelques semaines que je ne croyais pas que ça durerait éternellement, et le débat qui s’installe cet été me conforte dans l’idée que la question est ouverte. Peut-être que demain on ne relira plus l’ensemble du code, et que la vérification se déplacera entièrement vers les tests, les invariants et les specs. Peut-être pas. L’avenir tranchera, et je préfère vous partager une incertitude honnête qu’une conviction de façade.
Mais voyez la différence de nature avec « Codex ou Claude Code » : ce débat-là engage la responsabilité, la qualité, la sécurité, la formation des juniors. Sa réponse structurera nos pratiques pour des années. Voilà le genre de conversation qui mérite un créneau dans vos rituels d’équipe.
Les outils passent, les concepts restent
Prenons enfin un peu de recul historique, parce que cette situation, notre industrie l’a déjà vécue. Plusieurs fois.
Rappelez-vous les guerres de frameworks front-end. jQuery a régné, puis Angular a tout balayé, puis React a balayé Angular, et chaque transition s’est accompagnée des mêmes débats enflammés, des mêmes comparatifs, des mêmes gourous. Pendant ce temps, HTTP n’a pas bougé, ou si peu : quelques verbes ajoutés, des évolutions de protocole, mais les grands concepts (requête, réponse, ressource, cache) sont restés les mêmes. Celles et ceux qui avaient investi dans la compréhension du web lui-même ont traversé toutes les vagues sereinement. Celles et ceux qui n’avaient appris « que » le framework du moment ont tout réappris à chaque fois.
Même chose pour le versionnage : SVN a cédé la place à Git, et quiconque avait compris le concept (des versions, des branches, un historique, des fusions) n’a eu qu’à apprendre une nouvelle syntaxe. Le concept a survécu à l’outil, et il survivra probablement aussi à Git.
Quant aux guerres d’éditeurs, Vim contre Emacs contre les IDE, elles occupent les forums depuis quarante ans sans qu’aucune n’ait jamais fait de personne un meilleur développeur ou une meilleure développeuse. Les débats d’outils sont un genre littéraire, pas une démarche d’ingénierie.
L’écosystème agentique donne déjà tous les signes du même schéma, en accéléré. Les harnais eux-mêmes churnent à une vitesse folle : l’équipe de Manus a reconstruit le sien cinq fois en six mois ; Vercel a supprimé 80 % des outils de son agent et l’a rendu plus efficace. Les produits se réinventent tous les trimestres. Mais sous cette écume, les concepts (une boucle, un contexte, des outils, une vérification) sont les mêmes partout, et ils convergent : tous les agents modernes ont une mémoire projet, tous adoptent MCP, tous convergent vers des formats de skills comparables. C’est précisément ce qui rendait ma démonstration en formation possible.
Un mot de prudence, parce que je vous dois cette honnêteté : tout va très vite, et je ne peux pas vous garantir que la boucle agentique et le harnais seront encore les bons concepts dans cinq ans. Personne ne le peut. Ce que je peux affirmer, c’est qu’investir dans les concepts plutôt que dans les outils est aujourd’hui le pari le plus rationnel disponible. C’est le pari qui a payé à chaque génération technologique précédente, et rien n’indique que celle-ci fasse exception.
Concrètement, pour vos équipes
Alors, qu’est-ce que ça donne, une équipe qui investit au bon endroit ? Quelques pistes, toutes actionnables dès la rentrée.
Orientez les budgets de formation vers les concepts. Une journée sur « la boucle agentique, le harnais et la gestion du contexte » produira plus de valeur durable qu’une semaine sur les fonctionnalités d’un produit qui aura pivoté deux fois avant Noël. Formez sur ce qui se transfère. Et si vos équipes comptent des profils juniors, c’est encore plus vrai : j’ai déjà écrit sur la formation des juniors à l’ère des agents, et tout commence par les concepts.
Traitez votre harnais comme un capital. Les fichiers mémoire se relisent en revue de code, se versionnent, s’améliorent en continu. La bibliothèque de skills d’équipe se construit patiemment : chaque procédure répétée deux fois est candidate. Les permissions se réfléchissent en équipe, pas individuellement. Tout ça vous appartient et suivra vos équipes quel que soit l’outil.
Investissez dans l’outillage de vos projets. Chaque test, chaque règle de lint, chaque vérification en CI est un multiplicateur d’efficacité pour vos agents. La dette d’outillage, déjà coûteuse hier, devient un handicap direct de productivité agentique.
Traitez le choix de l’outil comme une décision réversible. Choisissez un leader, engagez-vous pour six mois ou un an, et cessez d’y penser. Votre harnais étant portable, le coût de changement est faible. L’énergie économisée sur la veille comparative compulsive, réinvestissez-la dans le harnais.
Pour illustrer que ce n’est pas de la théorie : dans l’équipe où je travaille au quotidien, nous utilisons massivement Claude Code. Mais nous faisons aussi tourner OpenCode, avec un modèle d’un autre fournisseur, pour la review automatisée de nos merge requests (celle-là même qui est devenue un jeu d’équipe). Deux agents, deux modèles, un harnais commun, et des comportements conformes à ce qu’on attend des deux côtés. L’outil et le modèle ne sont pas un Rubicon qu’on franchit une fois pour toutes : on joue avec plusieurs, et c’est le harnais qui garantit la cohérence de l’ensemble.
Le bon débat
Revenons une dernière fois dans cette salle de formation. Trois agents, trois modèles, un même harnais, des résultats quasi identiques. Ce jour-là, la démonstration ne portait pas vraiment sur les outils. Elle portait sur ce qui reste quand on enlève les logos : une boucle, du contexte, des briques de harnais, et des développeurs et développeuses qui comprennent ce qu’elles et ils manipulent.
La prochaine fois que le débat « quel est le meilleur agent » s’ouvrira dans votre équipe, sur votre Slack, dans votre veille, essayez de le remplacer par celui-ci : qui, chez nous, sait expliquer notre harnais ? Qui sait pourquoi telle permission est réglée ainsi, ce que contient notre mémoire projet, quels skills standardisent nos pratiques, et comment briefer un agent pour qu’il sache quand s’arrêter ?
Le jour où toute votre équipe sait répondre à ces questions, le choix de l’outil devient ce qu’il aurait toujours dû être : un détail d’intendance.
Les outils passent. Les concepts, eux, ont plutôt tendance à rester. Investissez en conséquence.
Vous accompagnez une équipe qui débute avec ces outils et vous sentez que le sujet mérite mieux qu’un comparatif ? Je propose des accompagnements et des formations sur ces fondamentaux : contact@yoandev.co.
Cet article a été écrit avec l’assistance d’une IA. Dans un harnais soigneusement réglé, évidemment.
Loading comments...