Le harness, expliqué simplement
Le terme est partout depuis février 2026, sans qu'il existe vraiment de définition stable. La formule qui s'est imposée tient en quatre mots : Agent = Model + Harness. Tout est dans le « plus ».
Tout sauf le modèle
Le terme harness a été popularisé en février 2026 par Mitchell Hashimoto, créateur de Terraform et de Ghostty. La discipline qu'il décrit : chaque fois qu'un agent commet une erreur, on n'ajuste pas le prompt — on modifie l'environnement pour que cette erreur devienne structurellement impossible. Six jours plus tard, OpenAI publiait une étude de cas où une équipe initialement de trois ingénieurs avait livré 1 million de lignes de code via des agents Codex, en mergeant 1 500 PRs. Conclusion partagée par les deux publications : quand l'IA écrit tout le code, le savoir-faire ne consiste plus à écrire du code, mais à concevoir le système autour de l'agent.
Birgitta Böckeler (Thoughtworks) a ensuite formalisé le vocabulaire dans un article publié sur le site de Martin Fowler en avril 2026, qui sert désormais de référence. La définition canonique qui en est sortie :
Le harness, c'est tout ce qui se trouve dans un agent IA, à l'exception du modèle lui-même.
Cela inclut les outils, la mémoire, la boucle d'orchestration, les permissions, les hooks de sécurité, les mécanismes de feedback, l'observabilité. Tout. La formule complète, attribuée à Hashimoto, est devenue le slogan du domaine :
Cette équation cohabite avec une trinité conceptuelle qui s'est imposée en parallèle, et qu'il faut bien distinguer :
Le prompt engineering n'a pas disparu. Il a été reclassifié : un composant parmi d'autres à l'intérieur du harness.
Le modèle se commoditise, le harness devient le moat
L'argument économique tient en une formule devenue virale dans la communauté : « A decent model with a great harness beats a great model with a bad harness ». Les data points qui l'étayent commencent à s'accumuler.
Sur Terminal Bench 2.0, Claude Opus 4.6 obtient des scores nettement différents selon le harness qui l'emballe : une équipe a fait passer son coding agent du top 30 au top 5 en ne changeant que le harness, à modèle constant. LangChain a publié une mesure plus précise sur DeepAgents : +13.7 points de benchmark en modifiant uniquement le harness (passage de 52.8% à 66.5%). Vercel a documenté qu'en réduisant le nombre d'outils accessibles à l'agent, le taux de succès des tâches augmente — la richesse fonctionnelle n'est pas une variable monotone, le cadrage compte autant que les capacités.
La conséquence stratégique est devenue un cliché du domaine, mais elle reste exacte : les modèles frontière sont interchangeables (les principaux providers se substituent sans réécriture du reste), le harness encode le savoir-faire métier, les contraintes de sécurité, et la logique de vérification. Le harness ne se déplace pas avec un changement de fournisseur — il constitue donc le moat compétitif des organisations qui déploient des agents en production.
De quoi un harness est-il fait
Aucune liste n'est canonique, mais une convergence s'est faite autour de six familles de composants. Tout harness en implémente plusieurs, rarement tous.
feedforward → model → feedback · le harness boucle l'apprentissage
Böckeler propose une distinction transversale utile : computational vs inferential. Les contrôles computationnels sont déterministes et rapides (un linter, un type checker, un test) — fiables, peu coûteux, exécutables à chaque commit. Les contrôles inferentiels sont sémantiques et non déterministes (un LLM qui juge la qualité d'un code) — plus riches en jugement, mais plus lents et plus coûteux. Un harness mature combine les deux selon le coût acceptable à chaque étape du cycle de vie.
Ce que chaque harness illustre
Le terme étant générique, il vaut mieux le rendre concret par opposition entre plusieurs harnesses connus, dont les philosophies divergent.
CLAUDE.md/AGENTS.md chargés au démarrage, skills, sub-agents, plan mode, permissions, observability via le SDK. Tout est fourni, le développeur compose. C'est aussi l'exemple le plus cité dans la littérature sur la harnessability : la qualité d'un harness mesurée par sa capacité à laisser l'agent travailler avec moins de supervision.Ces quatre exemples couvrent les deux axes structurants du débat actuel. Axe 1 : minimalisme (Pi) vs richesse intégrée (Claude Code). Axe 2 : évolution ad-hoc et opérée par l'humain (Claude Code, OpenClaw — l'agent peut modifier son workspace, créer ou patcher ses skills, mais sans boucle formalisée) vs évolution structurée par le harness lui-même (Hermes — self-evaluation explicite tous les 15 tool calls, mécanisme intégré). Tout déploiement réel se positionne quelque part sur ces deux axes, en fonction du compromis acceptable entre contrôle et autonomie.
L'arbitrage se déplace
Le débat « quel modèle choisir » a occupé 2024 et 2025. Il continue, mais il s'est dévalué : à modèle constant, le harness fait la différence entre un agent qui rend service et un agent qui produit du dommage silencieux. Plus le modèle est puissant, plus un mauvais harness lui permet de faire des bêtises avec efficacité.
Pour qui déploie aujourd'hui : avant de comparer les derniers modèles frontière entre eux, il est plus rentable de questionner la qualité du harness dans lequel ils vont tourner. Quelles erreurs reviennent et n'ont pas été cadrées par un guide ? Quels sensors manquent pour les détecter avant production ? Quels outils retirer parce qu'ils élargissent l'espace de décision sans bénéfice mesurable ? C'est cette discipline, devenue assez mature pour avoir un nom, que la littérature appelle désormais harness engineering.
Le harness, c'est tout ce qui n'est pas le modèle dans un agent IA. C'est de moins en moins une couche d'intégration et de plus en plus le terrain où se joue la qualité.