Harnais d'agent IA : la moitié cachée qui fait l'agent de code
Le modèle est le moteur. Le harnais, tout ce qu'on construit autour pour qu'il lise, agisse, se corrige et se souvienne, décide jusqu'où va l'agent IA.
- Agents IA
- Harness engineering
- Agents de code
- Pratiques d'ingénierie
En bref. Le harnais d’un agent IA désigne tout ce qui entoure le modèle : la boucle d’exécution, les outils, la mémoire, les garde-fous et les capteurs. Avec un même modèle, la qualité de ce harnais suffit à faire varier fortement les résultats d’un agent de code. Le harness engineering consiste donc à construire ce harnais en pièces séparées, à préférer des capteurs fiables aux consignes répétées, et à l’améliorer en continu, à chaque erreur récurrente.
Sans prérequis technique. Le texte principal se lit de bout en bout sans bagage particulier ; les encadrés « Pour aller plus loin » ajoutent le vocabulaire précis pour qui veut creuser.
Imaginez une voiture de course. Le moteur est une merveille d’ingénierie. Posé seul sur le bitume, pourtant, il ne va nulle part : il lui faut un châssis, des roues, des freins, un volant, un tableau de bord. C’est tout ce qui entoure le moteur qui en fait une voiture.
Une IA qui code fonctionne de la même façon. Le modèle (Claude, GPT…) est le moteur : puissant, mais incapable d’agir seul. Tout ce qu’on construit autour de lui pour qu’il puisse lire des fichiers, lancer des commandes, se corriger et se souvenir porte un nom : le harnais (harness en anglais). Et c’est lui, pas le moteur, qui décide jusqu’où va l’agent.
Pourquoi parle-t-on de harness engineering plutôt que de prompt engineering ?
Parce que, passé un certain niveau, les progrès d’un agent IA ne viennent plus de la formulation des demandes, mais de l’infrastructure construite autour du modèle. Avec exactement le même modèle, deux équipes obtiennent des résultats très différents selon la qualité de leur harnais.
Pendant deux ans, tout le monde a peaufiné ses prompts, c’est-à-dire la façon de formuler les demandes à l’IA. En 2026, le centre de gravité a bougé, et une formule résume le virage : « Moins de prompt engineering, plus de harness engineering. »
Le virage se mesure. Sur Terminal-Bench 2.0, un classement de référence des agents de code, l’équipe de LangChain indique avoir fait passer son propre agent du Top 30 au Top 5 en février 2026, sans toucher au modèle : elle a seulement amélioré ce qu’il y a autour.
Qu’est-ce qu’un harnais d’agent IA ?
Reprenons la voiture. Le harnais, ce sont toutes les pièces qui transforment le moteur en véhicule conduisible :
| Dans la voiture | Pour l’agent IA |
|---|---|
| La transmission qui transmet la puissance | La boucle : le modèle réfléchit, agit, observe le résultat, recommence |
| Les pédales et le volant | Les outils : lire un fichier, lancer une commande, chercher sur le web |
| Les freins, les airbags | Les garde-fous : empêcher une action dangereuse avant qu’elle arrive |
| Le tableau de bord, les voyants | Les capteurs : signaler quand quelque chose ne va pas |
| Le GPS qui garde l’itinéraire | La mémoire : se souvenir du contexte et des consignes |
Pour aller plus loin : l’anatomie technique Les harnais actuels partagent le même squelette : une boucle ReAct (raisonner, appeler un outil, observer) avec un outil
bashquasi universel ; la gestion du contexte (compaction, reset, sous-agents, mémoire externe viaCLAUDE.mdouAGENTS.md) ; des hooks, points d’interception avant et après chaque appel d’outil ; un modèle de permissions (permission model) ; le sandboxing ; le protocole MCP d’extension d’outils ; et l’observabilité. Claude Code, Cursor, Codex, Aider, Cline… convergent tous sur les mêmes briques. La différence se joue sur l’usage, pas sur la nature des pièces.
D’où l’équation devenue canonique : un agent = un modèle + un harnais. Un modèle brut n’est pas un agent ; il le devient quand un harnais lui donne des outils, une mémoire et des garde-fous.
Quelle différence entre le harnais de l’outil et le vôtre ?
Il existe en réalité deux harnais emboîtés : celui que livre le fabricant de l’outil, que vous utilisez sans le construire, et celui que vous ajoutez vous-même pour vos projets, avec vos consignes et vos capteurs. Ce second harnais est votre véritable métier de constructeur.
- Le harnais du fabricant (inner harness) : c’est la voiture telle qu’elle sort de l’usine. Quand vous utilisez Claude Code, Cursor ou un autre outil, vous conduisez une voiture que quelqu’un d’autre a construite. Vous ne la fabriquez pas, mais vous avez intérêt à savoir comment elle marche.
- Votre harnais (outer harness) : ce sont les accessoires et les règles que vous ajoutez pour vos routes à vous. Les itinéraires que vous programmez dans le GPS, les capteurs que vous installez, les consignes que vous donnez.
Pour aller plus loin : la distinction de Böckeler Cette frontière vient de Birgitta Böckeler (Thoughtworks), qui nomme outer harness la partie construite par l’utilisateur. Le reste (system prompt, retrieval, orchestration interne) est déjà intégré à l’outil et reste invisible. Elle prévient : « Construire cet outer harness devient une pratique d’ingénierie continue, pas une configuration ponctuelle. » Les guides et capteurs adaptés à votre cas d’usage forment votre territoire.
Comment un harnais guide-t-il puis vérifie-t-il l’agent ?
Votre harnais agit à deux moments, comme un bon copilote. Avant que l’agent agisse, il le guide avec des consignes, du contexte et les règles du projet, pour qu’il fasse juste du premier coup. Après, il vérifie le travail avec des capteurs, pour que l’agent repère et corrige seul ses erreurs.
- Avant, vous guidez : consignes, contexte, règles du projet.
- Après, vous vérifiez avec des capteurs : des tests, un correcteur de style, une relecture. Pas besoin d’attendre que vous lisiez tout.
Toute l’industrie a pourtant le même point aveugle : on a empilé les guides (fichiers d’instructions, consignes en markdown) et négligé les capteurs. Un harnais sans capteurs ressemble à une voiture sans tableau de bord : elle peut rouler longtemps avec un problème sans que personne ne le voie. Résultat, l’agent répète les mêmes erreurs à l’infini.
Pour aller plus loin : feedforward et feedback En vocabulaire technique, les guides relèvent du feedforward (anticiper) et les capteurs du feedback (observer après coup). Birgitta Böckeler et Chris Ford le résument ainsi : « Dans un monde parfait, on n’aurait besoin que de feedforward, parce que l’agent réussirait du premier coup. Comme ce monde n’existe pas, les capteurs sont vitaux. »
Capteurs fiables ou IA qui juge : lesquels choisir ?
Il en faut des deux familles, car elles se complètent. Les capteurs déterministes (tests, correcteurs de style) donnent une réponse fiable et reproductible ; les capteurs qui confient l’évaluation à une autre IA apportent un jugement plus riche, mais plus lent, plus cher et parfois imprévisible.
- Les capteurs sûrs sont rapides, gratuits et toujours d’accord avec eux-mêmes. Un test qui passe ou échoue, un correcteur de style : la réponse ne varie pas. Comme un radar de recul qui bipe, ils ne se trompent pas sur la distance.
- Les capteurs qui jugent demandent à une autre IA d’évaluer le travail (« ce code est-il clair ? »). Comme l’avis d’un passager : utile, mais subjectif.
La tendance de cette année : remplacer les supplications répétées dans les consignes (« n’oublie pas les tests ! ») par des capteurs sûrs, qui offrent une vraie garantie. L’une des familles ne remplace pas l’autre.
Pour aller plus loin : computational ou inferential Les deux familles s’appellent computational (déterministe, CPU, millisecondes, garanties objectives : ESLint, Semgrep, vérificateurs de types, Dependency Cruiser, mutation testing, couverture de tests) et inferential (non déterministe, GPU, coûteux, sémantique : LLM-as-judge, revue de code par IA). Une expérimentation Thoughtworks montre un agent dont la qualité du code s’améliore au fil du temps, par exemple sa couverture de tests, parce que des capteurs déterministes lui renvoient un signal fiable.
Que savent vérifier les capteurs aujourd’hui ?
On sait fabriquer des capteurs pour certaines questions, pas pour d’autres. La qualité du code se mesure bien, l’architecture commence à se mesurer, mais personne ne sait encore vérifier automatiquement que le code fait fonctionnellement la bonne chose.
| Question | État | En clair |
|---|---|---|
| Le code est-il propre ? | Réglé | On mesure bien : duplication, complexité, style, couverture de tests. |
| L’architecture tient-elle ? | En cours | On commence à savoir (tests de performance, règles de dépendances). |
| Le code fait-il vraiment ce qu’il faut ? | Ouvert | Le grand chantier : des tests verts ne prouvent pas que le comportement est correct. |
C’est la limite la plus importante à retenir, et elle appelle à la prudence face aux tests écrits par l’IA elle-même.
Pour aller plus loin : les trois catégories de Böckeler Birgitta Böckeler range l’outer harness en trois catégories : maintainability, aujourd’hui la plus facile à couvrir avec des capteurs computationnels ; architecture fitness, qui s’appuie sur les fitness functions ; et behaviour, le grand problème encore ouvert. Elle met en garde contre une confiance excessive dans les tests générés par l’IA. Piste prometteuse : les approved fixtures, des scénarios de référence validés par un humain.
Pourquoi toutes les bases de code ne se valent-elles pas ?
Parce que le harnais est le plus utile là où il est le plus dur à installer. Un projet bien rangé (types clairs, modules bien séparés) s’équipe facilement de capteurs. Un vieux projet en désordre, là où on en aurait le plus besoin, est justement le plus difficile à instrumenter.
Pour aller plus loin : affordances et loi d’Ashby Ned Letcher parle d’ambient affordances : les propriétés structurelles qui rendent un code lisible pour un agent (typage fort, frontières nettes). Le cadre théorique est la loi de la variété requise d’Ashby : un régulateur doit avoir autant de variété que le système qu’il gouverne. En pratique, réduire la variété en définissant une topologie d’application bien cadrée rend un harnais complet atteignable. C’est le fondement des futurs harness templates.
Un bon harnais supprime-t-il l’humain ?
Non : il le déplace. Un harnais n’est pas un pilote automatique total ; il dirige l’intervention humaine vers les décisions qui comptent, au lieu de la consacrer à relire chaque ligne produite par l’agent.
Birgitta Böckeler le formule ainsi : « Un bon harnais ne cherche pas forcément à éliminer toute intervention humaine, mais à la diriger là où elle compte le plus. »
Tout repose sur une boucle d’amélioration. Chaque fois qu’un capteur détecte un problème récurrent, on améliore le harnais avec un guide ou un capteur de plus. La fois suivante, l’agent se trompe moins, donc vous le surveillez moins finement. L’humain monte d’un cran : il arrête de relire chaque ligne et s’occupe des vraies décisions.
Pour aller plus loin : l’IA amplificateur (DORA 2025) Le rapport DORA 2025 décrit l’IA comme un amplificateur : elle magnifie les équipes solides et expose les équipes désorganisées. DORA observe une hausse simultanée du débit et de l’instabilité de livraison. Le problème n’est pas la vitesse, mais l’absence d’infrastructure de contrôle. Dans sa synthèse du rapport pour Thoughtworks, Ken Mugrage souligne l’écart entre confiance et usage : 30 % des professionnels ont peu ou pas confiance dans le code produit par l’IA, mais 95 % s’appuient dessus. Même écart côté pratique : selon l’enquête State of Code 2026 de Sonar, reprise par le Culture and Methods Trends Report 2026 d’InfoQ, 96 % des développeurs ne font pas entièrement confiance au code IA, mais 48 % seulement le vérifient toujours avant de le valider.
Un harnais peut-il s’améliorer tout seul ?
Des chercheurs l’ont montré en 2026 : une boucle automatique a fait évoluer un harnais minimal, sans toucher au modèle, jusqu’à dépasser un harnais conçu par des humains, et l’amélioration s’est transférée à d’autres situations. C’est encore de la recherche, mais la leçon vaut dès aujourd’hui.
Même sans cette automatisation, construisez votre harnais en pièces séparées : les consignes d’un côté, les outils de l’autre, la mémoire encore ailleurs, jamais un gros bloc indémêlable. C’est la seule façon de savoir quelle modification a eu quel effet, donc de progresser.
Pour aller plus loin : AHE Le preprint Agentic Harness Engineering (AHE, avril 2026) fait passer un harnais de départ minimal de 69,7 % à 77,0 % sur Terminal-Bench 2, au-delà de Codex-CLI (71,9 %), avec un modèle figé. Le gain se transfère à d’autres modèles.
Quels pièges éviter quand on construit un harnais ?
| Le piège | Pourquoi ça casse |
|---|---|
| Un harnais en un seul bloc | Tout est mélangé : impossible de savoir ce qui marche, donc d’améliorer. |
| Des guides sans capteurs | Plein de consignes, mais l’agent ne sait jamais quand il les a violées. |
| Trop de confiance dans les tests écrits par l’IA | Des tests verts ne garantissent pas le bon comportement. |
| Un harnais construit une fois pour toutes | C’est une pratique continue, pas un fichier de configuration qu’on oublie. |
| Trop d’outils à la fois | Face à des dizaines d’outils visibles, l’agent passe son temps à choisir et se trompe. |
Le plafond de vos agents, c’est votre harnais
L’ingénierie agentique pose un principe : l’humain tient l’architecture, l’IA implémente. Le harnais en est l’étage du dessous, et il fixe le plafond de ce que vous pouvez faire. Le modèle n’est pas hors jeu pour autant : une étude de septembre 2026 montre que l’utilité de chaque pièce du harnais dépend du modèle utilisé et du budget.
Vous pouvez être le meilleur pilote du monde : si la voiture n’a ni freins, ni tableau de bord, ni GPS, vous plafonnez. La nouvelle compétence d’ingénierie ne se limite plus à bien demander à l’IA, ni même à bien la piloter. Elle consiste à construire, et améliorer en continu, la voiture qui transforme un moteur brut en véhicule fiable.
Tout le monde ne fait pas ce pari. En septembre 2026, Martin Fowler relaie l’avis de Robert C. Martin (Uncle Bob) : les agents se sont tant améliorés que le besoin de harnais, sauf les plus souples, pourrait s’effacer. Thoughtworks, de son côté, place le harness engineering au cœur de ses publications et de son Technology Radar. Le débat reste ouvert, mais une chose est sûre : piloter un agent, c’est savoir conduire ; regarder sous le capot, c’est se préparer à construire la voiture.
Sources
- Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com : https://martinfowler.com/articles/harness-engineering.html
- Birgitta Böckeler, Maintainability sensors for coding agents, martinfowler.com : https://martinfowler.com/articles/sensors-for-coding-agents.html
- Birgitta Böckeler et Chris Ford, Harness engineering and agent feedback: Exploring AI coding sensors, Thoughtworks : https://www.thoughtworks.com/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors
- Thoughtworks, Technology Radar Vol. 34 (avril 2026) : https://www.thoughtworks.com/radar
- LangChain, The Anatomy of an Agent Harness : https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
- Ken Mugrage, The future of software development: AI speed, human judgment (synthèse DORA 2025), Thoughtworks : https://www.thoughtworks.com/insights/articles/the-future-of-software-development-AI-speed-human-judgment
- Lin, Liu, Pan et al., Agentic Harness Engineering, arXiv:2604.25850 : https://arxiv.org/abs/2604.25850
- Fan, Zhang, Ma et al., An Empirical Study of Harness Design for Coding Agents, arXiv:2609.20804 (septembre 2026) : https://arxiv.org/abs/2609.20804
Et chez vous ?
Vos équipes utilisent déjà l’IA pour développer. La vraie question n’est plus de savoir si, mais avec quel harnais : quelles consignes, quels capteurs, quels garde-fous, et qui les fait évoluer.
Chez Atecna, nous accompagnons les équipes de développement sur ce terrain précis : diagnostic de maturité, mise en place des guides et des capteurs, industrialisation multi-projets avec notre offre de développement IA, et montée en compétence des équipes.