Le harness, expliqué simplement

Tout sauf le modèle

Le terme harness engineering a été popularisé début février 2026 par Mitchell Hashimoto, créateur de Terraform et de Ghostty. Il décrit une discipline simple. Chaque fois qu'un agent commet une erreur, on ne corrige pas au coup par coup, on outille l'environnement (une règle dans AGENTS.md, un script de vérification) pour que cette erreur ne puisse plus se reproduire. Six jours plus tard, OpenAI publiait une étude de cas. Une équipe de trois ingénieurs au départ (sept ensuite) avait livré en cinq mois un produit d'environ 1 million de lignes via des agents Codex, en mergeant quelque 1 500 PRs, sans écrire une seule ligne à la main. Les deux publications concluent de la même façon. Quand l'IA écrit tout le code, le savoir-faire consiste à concevoir le système autour de l'agent.

LangChain a ensuite donné au concept sa forme la plus compacte (mars 2026). En avril, Birgitta Böckeler (Thoughtworks) l'a repris sur le site de Martin Fowler, en le resserrant sur ce que construit l'utilisateur d'un agent de code. La définition large reste celle qui circule :

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 et l'observabilité. La formule de LangChain est devenue le slogan du domaine.

Elle cohabite avec trois notions qui se sont imposées en parallèle et qu'il vaut mieux distinguer.

Le prompt engineering n'a pas disparu. Il est devenu un composant parmi d'autres du harness.

Le modèle se commoditise, le harness devient le moat

L'argument économique tient dans une phrase d'Addy Osmani, très reprise en avril 2026 : « A decent model with a great harness beats a great model with a bad harness ». Les données qui l'étayent s'accumulent.

Le leaderboard de Terminal-Bench 2.0 rend l'effet visible. Le même modèle y apparaît plusieurs fois, avec jusqu'à dix-huit points d'écart selon le harness qui le soumet. LangChain relève que Claude Code, le harness d'Anthropic, score très en dessous des autres avec Opus 4.6, et le leaderboard le place dernier des neuf soumissions Opus 4.6 (58,0 % contre 62,9 à 76,4 %). La même équipe a chiffré l'effet en reconstruisant le harness de ses DeepAgents à modèle constant (GPT-5.2-Codex) : de 52,8 % à 66,5 %, soit du top 30 au top 5 à la publication. Attention, Terminal-Bench a depuis publié les versions 2.1, 3.0 et 4.0, et un score ne se compare qu'à version égale. Vercel a fait la démonstration inverse, par soustraction. En remplaçant les 17 outils spécialisés de son agent text-to-SQL interne par un accès bash et un outil SQL, le taux de succès est passé de 80 % à 100 % (sur cinq requêtes de test), l'exécution est devenue 3,5× plus rapide et la consommation de tokens a baissé d'environ 37 %. Plus d'outils ne veut pas dire mieux : le cadrage compte autant que les capacités.

La conséquence stratégique est devenue un cliché, mais elle reste exacte. Les modèles frontière sont largement interchangeables (harness et modèle se co-adaptent quand même, et un harness réglé pour l'un perd des points avec l'autre). Le harness, lui, encode le savoir-faire métier, les contraintes de sécurité et la logique de vérification. Il ne part pas avec un changement de fournisseur, et c'est ce qui en fait l'avantage durable d'une organisation qui déploie des agents.

De quoi un harness est-il fait

Aucune liste n'est canonique, mais on retrouve partout six familles de composants. Tout harness en implémente plusieurs, rarement toutes.

agent = model + harness · ce que les sensors attrapent devient un guide

Böckeler propose une distinction utile entre contrôles computationnels et inférentiels. Les premiers sont déterministes et rapides (un linter, un type checker, un test), fiables et assez bon marché pour tourner à chaque commit. Les seconds 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 chers. Un harness mature combine les deux selon le coût acceptable à chaque étape du cycle de vie.

Elle nomme aussi la propriété symétrique côté code, la harnessability. Tous les codebases ne se laissent pas harnacher aussi bien. Typage fort, frontières de modules nettes et frameworks établis donnent aux guides et aux sensors davantage de prise.

Ce que chaque harness illustre

Le terme est générique. Le plus parlant est de comparer quelques harnesses connus aux philosophies différentes.

Ces quatre exemples couvrent les deux axes du débat actuel. Le premier oppose le minimalisme (Pi) à la richesse intégrée (Claude Code). Le second va d'une évolution opérée par l'humain (Claude Code, où l'agent peut modifier ses fichiers et ses skills sans boucle formalisée) à une évolution structurée par le harness lui-même (Hermes, et OpenClaw depuis son Skill Workshop d'octobre 2026, avec des revues en arrière-plan). Tout déploiement réel se place quelque part sur ces deux axes, selon le compromis accepté 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 pèse moins. À 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.