Harness engineering : ce qui entoure le modèle compte autant que le modèle

Depuis deux ans, la plupart des comités de direction posent la même question sur l'IA : quel modèle prendre ? Les signaux de ces dernières semaines suggèrent qu'on regarde au mauvais endroit. Les équipes qui obtiennent des résultats mesurables avec des agents ne se distinguent pas d'abord par leur modèle, mais par ce qu'elles ont construit autour : ce que l'anglais appelle désormais le harness, littéralement le harnais. Voici ce que recouvre le terme, ce que disent les mesures disponibles, deux cas concrets, et une façon raisonnable de s'y mettre dans une PME.

Agent = modèle + harness

La formule vient de Birgitta Böckeler, de Thoughtworks, dans un article publié sur le site de Martin Fowler en avril : le harness désigne tout ce qui, dans un agent, n'est pas le modèle. Le terme lui-même a été popularisé en février par un billet d'OpenAI : une petite équipe y raconte cinq mois passés à construire un produit interne sans écrire une ligne de code à la main, environ un million de lignes et 1 500 pull requests fusionnées, toutes produites par Codex. Le constat de l'auteur, Ryan Lopopolo, est que les débuts ont été lents non parce que l'agent était incapable, mais parce que son environnement était mal spécifié. Face à un échec, la question de l'équipe n'était jamais « essaie encore » mais « quelle capacité manque, et comment la rendre lisible et contrôlable pour l'agent ? ».

Concrètement, le harness regroupe :

• les consignes : prompt système, fichiers de contexte du dépôt (AGENTS.md, CLAUDE.md), compétences réutilisables ;
• les outils : ce que l'agent peut appeler, avec quels droits, et comment ils lui sont décrits ;
• la mémoire : ce qui persiste d'une session à l'autre ;
• l'orchestration : sous-agents, délégation, boucles ;
• la vérification : tests, linters, contrôle de types, revue automatisée, revue humaine ;
• les garde-fous : permissions, isolation, règles qui refusent une action avant qu'elle ne s'exécute.

Böckeler propose une grille simple pour ranger tout cela. Les guides agissent avant l'action et augmentent la probabilité que l'agent fasse juste du premier coup. Les capteurs observent après l'action et permettent à l'agent de se corriger. Chacun peut être déterministe (un test, un linter, rapide et fiable) ou inférentiel (une revue par un autre modèle, plus riche mais plus coûteuse et moins prévisible). Sans guides, l'agent ne sait pas ce qu'on attend de lui. Sans capteurs, il répète les mêmes erreurs sans jamais l'apprendre.

Ce que disent les mesures

Le domaine est jeune, et les chiffres solides sont rares. Ceux qui existent vont pourtant dans le même sens : à modèle constant, le harness fait bouger le résultat de plusieurs points.

À modèle figé, le harness seul fait gagner des points. Une équipe de Fudan et Pékin a publié en avril un travail sur l'évolution automatique des harness d'agents de code : dix itérations sur le harness, sans toucher au modèle, font passer le taux de réussite au premier essai sur Terminal-Bench 2 de 69,7 % à 77,0 %, au-dessus des 71,9 % du harness conçu à la main de Codex CLI. Les auteurs indiquent que le harness obtenu se transpose à d'autres familles de modèles.

Plus de consignes ne veut pas dire mieux. Des chercheurs de l'ETH Zurich ont évalué l'effet des fichiers `AGENTS.md` sur des tâches réelles de développement. Résultat contre-intuitif : ces fichiers n'améliorent pas, en général, le taux de réussite, et augmentent le coût d'inférence de plus de 20 %. Les fichiers écrits par les développeurs font mieux que ceux générés par un modèle, et les consignes sont bien suivies, mais les présentations générales du dépôt n'aident pas. Leur recommandation : n'y mettre que ce qui n'est pas déjà ailleurs (conventions spécifiques, exigences non fonctionnelles), et évaluer avant d'adopter.

Presque personne ne teste son harness. L'agence française Marmelab a publié fin septembre un état des lieux du harness engineering fondé sur 246 dépôts open source et 57 publications. Sur les 97 harness assez gros pour être examinés, 60 % n'ont ni test ni évaluation. Seuls 12 dépôts sur 391 contiennent ne serait-ce qu'une règle de refus dans leur configuration Claude Code. L'étude cite aussi un travail sur 481 fichiers CLAUDE.md publics où seule une petite fraction des règles de sécurité écrites est adossée à un contrôle réel. Marmelab précise qu'elle construit elle-même des harness, et que son propre projet figure parmi les finalistes de son classement : à lire comme tel.

La leçon rejoint celle de notre article sur la frontière de confiance des agents : une règle écrite en prose dans un fichier de consignes n'est pas un contrôle. Ce qui compte, c'est ce qu'un script, un hook ou une permission empêche réellement.

Harness² : l'agent règle son propre harness

Début octobre, Google Research a publié en open source, sous licence Apache 2.0, Harness², accompagné d'un article de recherche. L'idée est de pousser la logique jusqu'au bout : plutôt que de régler le harness à la main, laisser l'agent l'améliorer lui-même, sans toucher aux poids du modèle.

Le framework expose huit composants modifiables autour du modèle : prompt système, garde-fous, mémoire, guidage des outils, sous-agents, compétences, scripts et plugins. Pour chaque tâche, une étape baptisée Propose–Probe–Compose propose des modifications du harness, teste leurs effets sur la même tâche, puis compose un harness amélioré à partir des différences de comportement observées. Point important : cela fonctionne sans « bonne réponse » de référence, ce qui correspond à la situation réelle d'une entreprise, où les tâches sont rarement accompagnées de leur corrigé. À un second niveau, le système conserve les harness adoptés et les leçons étayées par des preuves, pour guider les tâches suivantes.

Les chercheurs annoncent qu'une seule étape améliore GLM-5 et Gemini 3.5 Flash sur trois bancs d'essai professionnels (bureautique et web, travail métier, juridique), avec des gains allant jusqu'à 11,5 points sur WorkBuddy-Bench, 4,5 points sur JobBench et 11,8 points de pourcentage sur le taux de réussite partielle du benchmark juridique LAB. Trois réserves : c'est un preprint, les gains sont mesurés sur des benchmarks et non en production, et le dépôt prévient lui-même que les exécutions avec un vrai modèle coûtent des appels d'API.

Pour un CTO, l'intérêt n'est pas d'installer Harness² demain. C'est ce qu'il dit de la direction du marché : le harness devient un objet qu'on versionne, qu'on teste et qu'on optimise, comme du code.

Le cas Claude Code : la revue de code devient un harness

Le second signal est plus directement exploitable. Le 15 octobre, trois membres d'Anthropic ont décrit sur claude.dev, le blog technique des développeurs de l'éditeur, comment l'équipe de Claude Code fait sa revue de code. Le contexte : Claude écrit environ 90 % du code de Claude Code, et dans le monorepo d'Anthropic, les changements fusionnés par jour sont passés d'environ 2 500 en mai à plus de 30 000 en septembre. À ce volume, relire chaque ligne à la main n'est plus tenable.

Leur réponse n'est pas de supprimer la revue, mais de la transformer en une série de couches :

1. Vérifier avant d'ouvrir la PR. L'agent reçoit quelque chose qu'il peut exécuter (tests, build, capture d'écran à comparer à la maquette) et doit montrer le résultat au lieu d'affirmer qu'il a fini. Un sous-agent relit ensuite le diff avec un contexte vierge.
2. Une revue IA sur chaque PR. Plusieurs agents cherchent des bogues en parallèle, puis un autre groupe vote sur chaque constat. Seuls ceux jugés réels par assez d'agents sont publiés ; les remarques de pure forme sont écartées. Chaque constat doit recevoir une réponse.
3. Une revue de sécurité bloquante, puis les contrôles habituels (lint, types, tests, build).
4. Une approbation humaine proportionnée au risque. Un classifieur lit le changement et lui attribue un niveau : aucun humain requis pour la documentation ou une fonctionnalité derrière un flag, un humain pour un changement produit ordinaire, deux pour le code le plus sensible. Un second classifieur peut exiger un humain même quand le niveau ne l'impose pas. Certains chemins (facturation, mise à jour automatique, workflows de CI) exigent toujours une personne, l'approbation d'un agent ne remplace jamais celle d'un humain, et les chemins allégés sont réservés aux auteurs de confiance.
5. File de fusion, feature flags, déploiement progressif et retour arrière rapide pour ce qui passe malgré tout.

Le résultat annoncé : de juin à septembre, le nombre de PR fusionnées dans le dépôt de Claude Code a plus que doublé, tandis que la part de PR annulées a baissé de plus de 40 %. Ce sont des chiffres internes, publiés par l'éditeur d'un produit de revue de code qu'il vend par ailleurs, sans volumes absolus : ils indiquent une tendance, pas une garantie.

Le plus instructif, pour une PME, est ailleurs. L'équipe mesure le temps humain (approbations par PR, commentaires, temps d'attente), avec le taux d'annulation et d'incidents comme garde-fou : si ces taux montent, le temps n'a pas été économisé, seulement déplacé. Les incidents passés sont devenus un jeu d'évaluation rejoué chaque jour contre le relecteur automatique. Et l'équipe a dû apprendre à faire converger la revue : une PR a enchaîné plus de cinquante allers-retours entre agent auteur et agent relecteur en une nuit, et environ 59 % de ce que le relecteur signalait à chaque passe concernait du code déjà présent lors de la première. D'où un plafond de trois tours, puis une relecture limitée au nouveau diff.

Boris Cherny, créateur de Claude Code, y estime que donner à l'agent un moyen de vérifier son travail rend le résultat final deux à trois fois meilleur. C'est une estimation personnelle, pas une mesure, mais elle résume bien l'esprit du harness engineering.

Le harness autour du modèle : des guides avant l'action, des capteurs après, des humains là où le risque le justifie, et une mesure qui boucle sur le tout. Synthèse d'après Böckeler (Thoughtworks), OpenAI, Anthropic et Google Research.

Mesurer : le coût par tâche réussie, pas le prix du jeton

Si le harness pèse autant que le modèle, il faut pouvoir le mesurer, sinon on empile des consignes au hasard. Quatre indicateurs suffisent pour commencer :

• Le taux de réussite sur un jeu de tâches maison. Vingt à cinquante tâches réelles, tirées de vos échecs passés, avec un résultat attendu vérifiable. On change une seule chose à la fois (une consigne, un outil, un modèle) et on rejoue. C'est le même jeu de tests que celui recommandé dans notre article sur la réversibilité : il sert aussi bien à comparer deux modèles qu'à juger une modification du harness.
• Le coût par tâche réussie. Le prix du million de jetons ne dit rien : un harness bavard, des fichiers de contexte trop longs ou des boucles de revue sans fin font exploser la facture. L'étude de l'ETH Zurich le montre : plus de 20 % de coût en plus pour un gain nul. Divisez la dépense totale par le nombre de tâches réussies.
• Le temps humain par changement. Approbations, commentaires, temps d'attente, comme chez Anthropic. C'est la ressource rare : OpenAI et Anthropic emploient d'ailleurs la même expression, le temps et l'attention des humains.
• Le taux d'annulation et d'incidents. C'est le garde-fou. S'il monte, vous n'avez rien gagné.

Ajoutez un indicateur de convergence si vous utilisez une revue automatisée : le nombre de tours avant qu'une PR passe. Au-delà de trois, c'est souvent l'approche qu'il faut revoir, pas le code.

Par où commencer dans une PME

Pas besoin d'une équipe de recherche. La plupart des briques existent déjà dans vos outils. L'ordre compte plus que l'exhaustivité.

1. Donner à l'agent de quoi vérifier son travail. Des tests qui tournent vite, un build reproductible, un moyen de lancer l'application en local. C'est le levier le plus rentable, et il profite aussi aux humains.

2. Réduire les consignes au strict nécessaire. Un fichier de contexte court, qui ne répète pas le README et ne contient que ce que l'agent ne peut pas deviner : conventions maison, pièges connus, commandes de vérification. Chaque règle doit répondre à un échec observé, pas à une crainte.

3. Transformer les règles importantes en contrôles. Ce qui compte vraiment devient un linter, un hook ou une permission refusée, exécutés en local et dans la CI. Limitez aussi les outils visibles par l'agent : moins d'outils, c'est moins de contexte et moins d'erreurs de choix. Pour les accès, la passerelle MCP et l'isolation des agents font partie du harness au même titre que les tests.

4. Ajouter une revue IA sur un dépôt pilote. Sur un seul dépôt, pendant quelques semaines, avec un fichier de consignes de revue tenu par les responsables du code. Comptez ce que les développeurs font des remarques : corrigées, jugées fausses, ignorées. C'est votre mesure du bruit.

5. Écrire des niveaux de risque. Décidez quels chemins exigent toujours un humain (authentification, facturation, CI, déploiement), puis ce qui peut passer avec une seule relecture. Commencez strict, assouplissez avec des preuves. Ne laissez jamais l'approbation d'un bot remplacer celle d'un humain.

6. Mesurer et entretenir. Le jeu de tâches maison, les quatre indicateurs, et un rendez-vous régulier pour retirer les règles devenues inutiles. Un harness encode des hypothèses sur ce que le modèle ne sait pas faire seul : quand le modèle progresse, certaines deviennent du poids mort.

Checklist

• [ ] L'agent peut lancer les tests, le build et l'application, et doit en montrer le résultat
• [ ] Fichier de contexte court, sans redite du README, chaque règle liée à un échec observé
• [ ] Règles critiques traduites en linters, hooks ou permissions, actives en local et en CI
• [ ] Outils visibles par l'agent limités au nécessaire, accès via une passerelle, exécution isolée
• [ ] Revue IA en pilote sur un dépôt, avec un suivi du bruit des remarques
• [ ] Niveaux de risque écrits, chemins sensibles toujours soumis à un humain
• [ ] Jeu de vingt à cinquante tâches maison, rejoué à chaque changement de harness ou de modèle
• [ ] Coût par tâche réussie, temps humain par changement et taux d'annulation suivis
• [ ] Plafond de tours de revue automatique
• [ ] Revue trimestrielle du harness : chaque règle a une raison d'être, les autres sont retirées

Conclusion

Le choix du modèle reste important, mais il devient la partie la plus facile à changer. Ce qui distingue une équipe qui tire parti des agents d'une équipe qui s'y épuise, c'est le système autour : des guides courts, des contrôles qui s'exécutent vraiment, une revue proportionnée au risque, et une mesure qui dit si chaque ajout sert à quelque chose. Bonne nouvelle pour une PME : c'est de l'ingénierie logicielle classique, appliquée à un nouveau type de contributeur.

C'est le type de chantier sur lequel j'accompagne des CTO et dirigeants de PME : audit du harness existant, constitution d'un jeu de tâches maison, mise en place d'une revue IA et de niveaux de risque, choix des indicateurs. Si vos agents produisent plus de code que votre équipe ne peut en relire, c'est probablement le bon moment pour en parler.

Sources

1. Birgitta Böckeler (Thoughtworks), Harness engineering for coding agent users, martinfowler.com, 2 avril 2026
2. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 février 2026
3. Google Research, Harness² (dépôt GitHub), licence Apache 2.0, consulté le 18 octobre 2026
4. Xu et al. (Google Cloud AI Research), Harness²: Recursive Agent Harnessing for an Open World, arXiv 2610.14224, octobre 2026
5. Osmani, Westlee Lunt et Wang (Anthropic), How the Claude Code team does code review, claude.dev, 15 octobre 2026
6. Lin et al., Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses, arXiv 2604.25850, avril 2026
7. Gloaguen et al. (ETH Zurich, LogicStar.ai), Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?, arXiv 2602.11988, février 2026
8. François Zaninotto (Marmelab), The State Of AI Harness Engineering 2026, 24 septembre 2026