Concept Harness Engineering
Discipline de conception du système (guides, sensors, outils) entourant un agent IA pour fiabiliser et amplifier ses résultats.
Définition : placer le système avant le modèle
Le harness engineering est une discipline émergente qui place la conception du système entourant un agent IA — et non le modèle lui-même — au centre de la performance. Le terme a été forgé par Mitchell Hashimoto (cofondateur de HashiCorp) en février 2026, puis amplifié par OpenAI et codifié par Birgitta Böckeler sur martinfowler.com. Le principe fondateur : chaque erreur d'un agent doit déclencher une amélioration du harnais pour que cette erreur ne se reproduise plus jamais.
Framework : guides et sensors, deux contrôles complémentaires
Le framework de Böckeler distingue deux types de contrôles complémentaires. Les guides (contrôles feedforward) anticipent le comportement de l'agent avant qu'il agisse : fichiers AGENTS.md, conventions de code, scripts de bootstrap, templates de topologie. Les sensors (contrôles feedback) observent après l'action et aident l'agent à s'auto-corriger : suites de tests, linters, vérificateurs de types, revues de code automatisées. La combinaison des deux forme un cybernetic governor qui régule la base de code vers son état souhaité.
Preuve empirique : Terminal-Bench 2.0 de Stanford
La preuve empirique la plus frappante vient de Terminal-Bench 2.0 (Stanford/Laude Institute, mars 2026) : le harness ForgeCode atteint 81,8 % avec Claude Opus 4.6, tandis que Claude Code obtient 58 % avec le même modèle — un écart de 23,8 points attribuable exclusivement au harnais. ForgeCode atteint d'ailleurs des scores identiques avec GPT-5.4 et Claude Opus 4.6, démontrant que le harness neutralise les différences entre modèles.
Harnessability : traçabilité et topologies claires
Le concept de harnessability (Böckeler) mesure la capacité d'une base de code à être harnachée efficacement. Les langages fortement typés, les frontières de modules claires et les frameworks structurés créent des ambient affordances qui rendent le code tractable pour les agents. La loi d'Ashby (variété requise) s'applique : les équipes doivent réduire la variété de ce que l'agent peut produire en définissant des topologies claires et des harness templates pour les patterns récurrents.
Superset du context engineering, résultats en production
Le harness engineering est un superset du context engineering. Böckeler le positionne explicitement : le context engineering fournit les moyens de rendre les guides et sensors disponibles à l'agent, tandis que le harness engineering englobe le cycle complet de conception, maintenance et amélioration continue du système de contrôle. En production, Stripe fusionne plus de 1 300 PRs générées par IA par semaine grâce à son système Blueprints, et OpenAI a construit 1 million de lignes de code avec 3 ingénieurs en 5 mois — des résultats impossibles sans un harnais industriel.
Questions fréquentes
Quelle est la différence entre harness engineering et context engineering ?
Le context engineering fournit les moyens de structurer l'information pour les agents IA. Le harness engineering est un superset qui englobe le cycle complet : guides (feedforward), sensors (feedback), templates de topologie, et amélioration continue du système de contrôle. C'est le passage de la structuration du contexte à la conception d'un système cybernétique complet.
Qu'est-ce qu'un guide et un sensor dans le harness engineering ?
Un guide (contrôle feedforward) oriente l'agent avant qu'il agisse — fichiers AGENTS.md, conventions, scripts de bootstrap. Un sensor (contrôle feedback) observe après l'action et aide l'agent à s'auto-corriger — tests, linters, vérificateurs de types. Les deux sont nécessaires : sans guides l'agent répète ses erreurs, sans sensors il encode des règles sans savoir si elles fonctionnent.
Qu'est-ce que la harnessability d'une base de code ?
La harnessability mesure la capacité d'une base de code à être contrôlée efficacement par un harness. Les bases fortement typées, avec des frontières de modules claires et des frameworks structurés, ont une harnessability élevée. C'est un argument fort pour les stacks AI-Ready : TypeScript, typage strict, conventions explicites.
Le harness engineering rend-il les modèles IA interchangeables ?
Partiellement. Terminal-Bench 2.0 montre que ForgeCode atteint 81,8% avec GPT-5.4 comme avec Claude Opus 4.6. Un bon harness réduit considérablement l'écart entre modèles, mais le choix du modèle reste pertinent pour les cas limites et les tâches à forte exigence de raisonnement.
Articles liés
AWS Bedrock, 6 personnes, 72 jours : rester aux commandes des agents de code
Julien Lépine (CTO AWS France) détaille le redéveloppement d'Amazon Bedrock par 6 personnes en 72 jours — code intégralement généré par IA, sans vibe coding. Un proof-point hyperscaler qui déplace la valeur du code vers le contexte et la responsabilité humaine.
Harness Engineering : le modèle compte moins que le harnais
Même modèle, 58% vs 81,8% de réussite. La variable décisive n'est pas l'IA — c'est le système qui l'entoure. Bienvenue dans l'ère du harness engineering.
Le Guide Complet du Loop Engineering
Cessez de prompter vos agents : concevez les boucles qui les pilotent. Le guide complet du Loop Engineering — définition, généalogie prompt→context→harness→loop, anatomie en 5 blocs, écosystème et limites.
Loopcraft : l'art de combiner les boucles IA
swyx l'appelle loopcraft : l'art d'empiler les boucles plutôt que de s'appuyer sur un agent unique. Les quatre boucles de LangChain, la distinction harnais/loop, la règle monter/descendre et les pièges de l'empilement multi-boucles.
L'ontologie n'est pas louable : le vrai fossé concurrentiel des agents IA
Tony Seale vient de nommer l'évidence : la moitié qui manque aux agents IA n'est pas un framework supplémentaire, c'est l'ontologie de votre domaine. Pour la première fois, le fossé concurrentiel est clairement délimité — et il n'est pas technique.
Que devient DBT quand l'IA écrit le code ?
Benoit Perigaud (DBT Labs) raconte quatre ans d'investissement sur l'IA chez DBT Labs — trois leviers techniques (skills, MCP server, DBT Index), l'épineux problème du token design, les trous du benchmark Analytics Engineering, et l'angle mort que les agents ne savent toujours pas franchir.
Claude Code : l'agent de développement qui change la donne
De l'assistant au agent : une rupture qui redéfinit le développement logiciel Pendant des années, l'IA dans le développement logiciel a joué un rôle bien délimité : celui du copilote. Un outil intelligent, certes, capable de compléter une ligne de code, de suggérer une fonction...
Écrire du code est un anti-pattern : la provocation qui change tout
La provocation qui remet tout en question « Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement. » Cette phrase, prononcée par Didier Girard, a de quoi faire bondir n'importe quel développeur. Elle semble absurde, voire pro...
Context Engineering : le guide complet pour 2026
Le Context Engineering est la discipline qui structure le contexte alimentant les agents IA. Architecture 3-Tier, CDLC, et Compound Engineering : tout comprendre.
Compound Engineering : comment chaque cycle rend le suivant plus facile
Le paradoxe du prompt vide : pourquoi votre IA recommence toujours de zéro Imaginez embaucher un développeur senior chaque matin, lui expliquer l'intégralité de votre projet, vos conventions, votre architecture, vos décisions passées — puis le voir partir à 17h sans laisser la m...
CI/CD ultra-robuste : le filet de sécurité du développement 10x
Le paradoxe du développement augmenté Il y a une tension au cœur de la révolution IA que peu d'équipes techniques prennent le temps d'articuler clairement. D'un côté, les promesses sont réelles : générer du code plus vite, réduire la friction, atteindre un facteur de pro...
AI4IT d'abord : pourquoi l'IA pour le SI précède l'IA pour les métiers
AI4IT d'abord, AI4Business ensuite : pourquoi l'IA pour le build et le run du SI passe avant l'IA pour les métiers dans la fenêtre 2026-2027.
Quand l'agent pousse du code en production à 3h du matin, qui est responsable ?
La sécurité de l'agentic coding se joue dans la revue : signaux d'alarme, vérifiabilité, harnais et identité des agents.
« Coding is solved » : pourquoi votre entreprise n'a pas encore le droit d'y croire
Définition, bascule « coding is solved » et garde-fous : ce que l'agentic coding change vraiment en entreprise.
Ornith-1.0 : quand le modèle apprend son propre harnais
Un même modèle open-source, deux verdicts opposés selon le harnais. Ce qu'Ornith-1.0 et son entraînement self-scaffolding prouvent pour une DSI.
Le modèle C4 à l'ère de l'IA : qui tient la carte du code généré ?
Quand les agents écrivent le code plus vite que les humains ne le lisent, le modèle C4 de Simon Brown change de statut : de documentation d'architecture, il devient l'instrument de contrôle visuel du SDLC, pour comparer l'intention et ce que l'IA a construit.
Pourquoi le sommet du leaderboard ne vous dit pas quel modèle choisir
À défaut du prix, on arbitre sur les benchmarks. Mauvais réflexe : un classement mesure des capacités moyennes sur des tests standardisés, pas la performance sur votre legacy. La précision plafonne, la variance explose, et l'écart au sommet compte moins que le harnais. Que mesurer à la place.
Un modèle par tâche : le guide du routing multi-modèles
Faire tourner toute une usine logicielle sur un seul modèle frontier, c'est payer le tarif du raisonnement pour lire des logs. La mécanique du routage multi-modèles : un modèle par phase, une passerelle unique, l'isolation des sous-agents et la règle qui dit quand le multi-agents mérite son coût.