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. La discipline qu'il décrit : 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 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. 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.

LangChain a ensuite donné au concept sa forme la plus compacte (mars 2026), puis Birgitta Böckeler (Thoughtworks) en a fait la référence en avril, dans un article publié sur le site de Martin Fowler. La définition qui fait consensus :

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 compacte, popularisée par LangChain, 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 d'Addy Osmani devenue virale (avril 2026) : « A decent model with a great harness beats a great model with a bad harness ». Les data points qui l'étayent commencent à s'accumuler.

Le leaderboard Terminal-Bench 2.0 rend l'effet visible : le même modèle y apparaît plusieurs fois, à des scores séparés de dix points et plus selon le harness qui le soumet. LangChain note même que le harness officiel d'Anthropic, Claude Code, se classe dernier parmi les soumissions Opus 4.6. 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%, un bond de hors du top 30 à la 5^e place à la publication. Vercel a fait la démonstration inverse, par soustraction : en supprimant 80% des outils de son agent text-to-SQL interne (18 outils spécialisés remplacés par un simple accès bash), le taux de succès est passé de 80% à 100%, l'exécution est devenue 3.5× plus rapide et la consommation de tokens a baissé de 37%. 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 largement interchangeables (même si harness et modèle se co-adaptent : un harness réglé pour l'un perd des points avec l'autre), le harness encode le savoir-faire métier, les contraintes de sécurité et la logique de vérification. Il ne se déplace pas avec un changement de fournisseur : c'est 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.

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

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.

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 étant générique, il vaut mieux le rendre concret par opposition entre plusieurs harnesses connus, dont les philosophies divergent.

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.