Harness Engineering : le modèle compte moins que le harnais
58% contre 81,8% — avec le même modèle
En mars 2026, le benchmark Terminal-Bench 2.0 de Stanford et du Laude Institute a produit un résultat qui devrait faire réfléchir chaque directeur technique : l'agent ForgeCode, alimenté par Claude Opus 4.6, a atteint un score de 81,8% sur 89 tâches de développement. Le même jour, avec le même modèle Claude Opus 4.6, l'agent Claude Code a obtenu 58%. Un écart de 23,8 points — attribuable exclusivement à la conception du système entourant le modèle.
Ce chiffre n'est pas une anomalie statistique. Il cristallise un basculement que l'industrie du développement logiciel a mis deux ans à nommer. Depuis 2022, l'attention s'est focalisée sur la course aux modèles : plus gros, plus rapides, plus capables. Mais les données empiriques racontent une autre histoire. La variable décisive n'est pas le modèle — c'est tout ce qui l'entoure : les instructions qui cadrent son comportement, les tests qui vérifient ses résultats, les conventions qui réduisent l'espace des erreurs possibles, les boucles de feedback qui lui permettent de s'auto-corriger.
Ce système de contrôle — le harnais de l'agent — porte un nom depuis février 2026 : le harness engineering. Littéralement, l'ingénierie du harnais. Comme le harnais d'un cheval de trait canalise une force brute en travail utile, le harness engineering canalise la puissance d'un LLM en production logicielle fiable. Et ce paradigme est en train de redéfinir ce que signifie être un ingénieur logiciel compétent.
De la genèse au framework : comment le terme s'est imposé en 60 jours
Le 5 février 2026, Mitchell Hashimoto — cofondateur de HashiCorp, créateur de Terraform — publiait un article intitulé "My AI Adoption Journey". Il y décrivait un processus en six étapes pour les équipes adoptant des agents IA, et nommait pour la première fois ce que beaucoup pratiquaient sans vocabulaire commun :
"I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this 'harness engineering.' It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
Six jours plus tard, OpenAI publiait "Harness engineering: leveraging Codex in an agent-first world", amplifiant le terme à l'échelle de l'industrie. Puis le 2 avril 2026, Birgitta Böckeler, Distinguished Engineer chez Thoughtworks, publiait sur martinfowler.com le framework qui est devenu la référence canonique. Martin Fowler introduisait son travail comme "a valuable framing of a key part of AI-enabled software development."
La progression historique est désormais claire : prompt engineering (2022-2024) → Context Engineering (mi-2025) → harness engineering (février 2026). Chaque étape élargit le périmètre de ce que l'humain conçoit autour du modèle. Le prompt engineering, c'était l'e-mail. Le context engineering, c'était l'e-mail avec ses pièces jointes. Le harness engineering, c'est le bureau tout entier — workflow, contraintes, boucles de feedback, outillage et gestion du cycle de vie.
Guides et sensors : l'anatomie du harnais
Le framework de Böckeler structure le harness engineering autour d'un modèle concentrique. Au centre, le modèle. Autour, le builder harness — l'infrastructure intégrée par l'éditeur de l'agent de développement. Et en périphérie, le user harness — ce que les équipes d'ingénierie configurent elles-mêmes. C'est cette dernière couche qui fait la différence entre un agent médiocre et un agent fiable.
Le framework repose sur deux types de contrôles complémentaires :
Les guides (contrôles feedforward) anticipent le comportement de l'agent et l'orientent avant qu'il agisse. Böckeler les décrit comme des mécanismes qui "increase the probability that the agent creates good results in the first attempt." Concrètement : les fichiers AGENTS.md qui documentent les conventions du projet, les scripts de bootstrap, les recettes de transformation de code (comme OpenRewrite), les conventions de nommage explicites.
Les sensors (contrôles feedback) observent après que l'agent a agi et l'aident à s'auto-corriger. Böckeler note qu'ils sont "particularly powerful when they produce signals that are optimised for LLM consumption, e.g. custom linter messages that include instructions for the self-correction." En pratique : les suites de tests, les linters, les vérificateurs de types, les revues de code automatisées par IA.
L'insight critique est que les deux sont nécessaires. Un agent avec uniquement des sensors répète les mêmes erreurs avant de les corriger — coûteux et lent. Un agent avec uniquement des guides encode des règles sans jamais savoir si elles fonctionnent — fragile et aveugle. La combinaison produit ce que Böckeler appelle un cybernetic governor : un système de régulation qui maintient la base de code dans son état souhaité.
Terminal-Bench 2.0 : la preuve empirique que le harnais bat le modèle
Revenons aux chiffres. Le classement Terminal-Bench 2.0, avec ses 89 tâches calibrées, raconte une histoire limpide :
- ForgeCode + GPT-5.4 : 81,8% (±2,0)
- ForgeCode + Claude Opus 4.6 : 81,8% (±1,7)
- Claude Code + Claude Opus 4.6 : 58,0% (±2,9)
ForgeCode — un harness open source, agnostique au modèle, écrit en Rust par Tailcall — atteint des scores identiques avec deux modèles complètement différents. Son équipe a documenté les quatre modifications spécifiques du harness qui ont comblé l'écart entre GPT-5.4 et Opus 4.6 : réorganisation des champs dans les schémas d'outils, aplatissement des structures imbriquées, ajout de rappels explicites de troncature, et imposition d'une compétence de vérification obligatoire. Leur conclusion : "Drop both models into the same harness and Opus looks easier to work with. Adapt the harness to GPT 5.4's actual failure modes and the gap disappears."
LangChain a indépendamment démontré le même principe : leur harness Deep Agents est passé de 52,8% à 66,5% sur Terminal-Bench 2.0 — grimpant d'environ la 30e place au top 5 — en changeant uniquement le harness, sans toucher au modèle GPT-5.2-Codex. Les techniques : boucles d'auto-vérification, middleware de détection de boucles, et une approche "reasoning sandwich" pour l'allocation du budget de tokens.
Le message est sans ambiguïté : optimiser le choix du modèle est nécessaire mais insuffisant. L'investissement qui compte est le système qui entoure le modèle.
En production : Stripe, OpenAI et Anthropic montrent la voie
Les preuves les plus convaincantes ne viennent pas des benchmarks mais des déploiements en production.
Stripe : 1 300 PRs par semaine, zéro code humain
Le système Minions de Stripe fusionne plus de 1 300 pull requests générées par IA chaque semaine, contenant "zero human-written code." L'architecture repose sur des Blueprints — des flux d'orchestration qui alternent entre des nœuds déterministes (tests, linting, compilation) et des nœuds agentiques (raisonnement et génération LLM). Chaque Minion s'exécute dans un devbox isolé : une VM identique à l'environnement de développement humain, préchauffée en 10 secondes, sans accès internet ni accès production. L'insight de Stripe : "Putting LLMs into contained boxes compounds into system-wide reliability upside." Le système a l'autorité de soumission mais pas l'autorité de fusion — chaque PR passe en revue humaine.
OpenAI Codex : 1 million de lignes, 3 ingénieurs
L'expérience la plus radicale vient d'OpenAI. En partant d'un dépôt vide en août 2025, une équipe de 3 ingénieurs (passée à 7) a construit une application interne en bêta de production avec environ 1 million de lignes de code en cinq mois — sans aucune ligne écrite manuellement. Moyenne : 3,5 PRs par ingénieur par jour. Ryan Lopopolo l'a résumé : "We estimate that we built this in about 1/10th the time it would have taken to write the code by hand. Humans steer. Agents execute."
Le harness OpenAI intègre le Chrome DevTools Protocol dans le runtime de l'agent (lui donnant accès aux snapshots DOM, captures d'écran et navigation) et instancie des stacks d'observabilité par worktree. Leur innovation structurelle : le modèle "Table of Contents" pour AGENTS.md — un fichier court d'environ 100 lignes servant de carte, pointant vers un répertoire docs/ comme système de référence. Leur dépôt utilise 88 fichiers AGENTS.md, un par sous-système.
Anthropic : l'architecture à trois agents
Le 24 mars 2026, Anthropic publiait la conception de harness la plus architecturalement détaillée : un système Planner/Generator/Evaluator inspiré des GANs. Le Planner transforme une phrase en spécification produit complète. Le Generator travaille en sprints. L'Evaluator utilise Playwright pour naviguer l'application comme un utilisateur, évaluant chaque sprint avec des seuils stricts. Avant chaque sprint, Generator et Evaluator négocient un sprint contract — un accord sur ce que signifie "terminé" avant qu'une ligne de code soit écrite.
La séparation adresse deux modes de défaillance critiques : la context anxiety (le modèle perd sa cohérence à mesure que la fenêtre de contexte se remplit) et le self-evaluation bias — quand un agent évalue son propre travail, il tend à le valider avec confiance, même quand la qualité est visiblement médiocre pour un observateur humain.
AI slop : quand la vitesse produit de l'entropie
Le harness engineering a aussi sa face sombre. L'explosion de la quantité de code produit crée un nouveau vecteur de risque que l'industrie nomme AI slop — du code généré par IA de faible qualité, verbeux, qui dégrade les bases de code au fil du temps. Le terme a été élu mot de l'année 2025 par Merriam-Webster et l'American Dialect Society.
L'équipe OpenAI l'a vécu directement : "Our team used to spend every Friday (20% of the week) cleaning up 'AI slop.' Unsurprisingly, that didn't scale." Leur réponse : des agents de garbage collection automatisés, tournant sur des schedules, scannant les incohérences et ouvrant des PRs de refactoring ciblé.
Le benchmark SlopCodeBench (janvier 2026, Université du Wisconsin-Madison) a identifié des patterns systémiques : les modèles sont "allergic to libraries" (préférant réimplémenter plutôt qu'importer) et "refuse to ever delete code unless there's no other choice" — générant du bloat massif par accumulation.
David Caudill a connecté ce problème à la cybernétique via la loi d'Ashby (loi de la variété requise) : "The variety that our AI coding assistant is capable of exceeds the variety that any one individual is capable of." La réponse est soit d'augmenter la capacité de revue humaine — ce qui ne passe pas à l'échelle — soit de réduire stratégiquement la variété de ce que le modèle peut produire. C'est précisément ce que fait le harness engineering.
Les leviers stratégiques : construire un harnais qui tient
De l'ensemble des retours d'expérience, quatre leviers se dégagent pour les organisations qui veulent passer du stade expérimental à l'industrialisation.
Évaluer la harnessability de sa base de code
Böckeler introduit le concept de harnessability : "Not every codebase is equally amenable to harnessing." Les langages fortement typés, les frontières de modules claires et les frameworks bien structurés créent ce que son collègue Ned Letcher appelle des ambient affordances — des propriétés structurelles qui rendent les bases de code lisibles et tractables pour les agents. C'est un argument de plus pour les stacks AI-Ready : TypeScript, typage strict, verbosité explicite, trunk-based development.
La réalité difficile pour les équipes legacy : "the harness is most needed where it is hardest to build." Le harnais est le plus nécessaire précisément là où il est le plus difficile à construire.
Définir des topologies pour réduire la variété
Böckeler applique la loi d'Ashby au développement : un contrôleur doit avoir au moins autant de variété que le système qu'il gouverne. Puisqu'un LLM peut produire à peu près n'importe quoi, les équipes doivent réduire la variété en s'engageant sur des topologies définies — services API, processeurs d'événements, dashboards — rendant les harnais complets réalisables. Cela mène aux harness templates : des bundles préconstruits de guides et sensors pour les patterns d'entreprise courants.
Séparer la vérification de la génération
L'architecture Planner/Generator/Evaluator d'Anthropic et les Blueprints de Stripe convergent sur le même principe : l'agent qui produit ne doit pas être l'agent qui évalue. La séparation des rôles élimine le self-evaluation bias et permet des seuils de qualité stricts, automatisés et vérifiables.
Traiter le harnais comme du code
Le principe fondateur de Hashimoto reste le plus actionnable : chaque fois qu'un agent commet une erreur, investir le temps d'ingénierie pour que cette erreur ne se reproduise plus jamais. Les fichiers AGENTS.md, les scripts de vérification, les linters configurés pour les patterns spécifiques de l'équipe — tout cela doit être versionné, maintenu et testé avec la même rigueur que le code de production. Comme Hashimoto le résume : "If you give an agent a way to verify its work, it more often than not fixes its own mistakes and prevents regressions."
La perspective SFEIR : du context engineering au harness engineering
Pour SFEIR, le harness engineering n'est pas une rupture — c'est l'aboutissement logique du Context Engineering que nous pratiquons avec nos clients depuis 2025. Böckeler elle-même positionne le harness engineering comme un superset : "Context engineering provides us with the means to make guides and sensors available to the agent. Engineering a user harness for a coding agent is a specific form of context engineering."
Ce que nous observons chez nos clients confirme les données de Terminal-Bench : les équipes qui obtiennent les meilleurs résultats avec les agents de développement ne sont pas celles qui ont choisi le meilleur modèle. Ce sont celles qui ont investi dans leur infrastructure de contrôle — les conventions documentées, les suites de tests robustes, les pipelines CI/CD qui servent de sensors, les architectures typées qui réduisent la variété. Notre approche Software Factory 10x intègre nativement ces principes : le cycle PLAN → WORK → REVIEW → COMPOUND est un harness en soi, où chaque itération enrichit le système de guides et sensors pour la suivante.
La question stratégique n'est plus "quel modèle utiliser ?" mais "quel harnais construire pour que n'importe quel modèle performant produise des résultats fiables ?"
Conclusion : le harnais est le nouveau différenciateur compétitif
Revenons à notre chiffre de départ : 58% contre 81,8%, même modèle, même benchmark, même jour. Cet écart de 23,8 points n'est pas un détail technique — c'est un avantage compétitif mesurable.
Le harness engineering nous enseigne que l'avantage en 2026 n'est pas l'accès aux modèles frontier — tout le monde y a accès. C'est la discipline d'ingénierie pour construire le système qui rend ces modèles fiables, cohérents et alignés avec l'architecture et les standards spécifiques de chaque organisation.
Comme le note Prithvi Rajasekaran d'Anthropic : "The space of interesting harness combinations doesn't shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination." Le travail intéressant ne disparaît pas — il se déplace. Des ingénieurs qui écrivaient du code, nous passons à des ingénieurs qui conçoivent les systèmes dans lesquels le code s'écrit.
Et c'est précisément ce déplacement qui rend la période passionnante.