Harness engineering : la machine autour du modèle

Un agent, c’est un modèle plus un harnais, et le harnais, c’est tout ce qui n’est pas le modèle. Les poids sont figés. La machine qui les entoure, non. Le harnais est l’échafaudage d’exécution qui transforme un modèle brut en agent : la boucle, les outils, la gestion du contexte, les sous-agents, les garde-fous. Concevez bien cette machine et un modèle figé se dépasse lui-même, de façon mesurable.

Si le context engineering écrit la partition, le harness engineering construit l’instrument qui la joue. Cet article parle de l’instrument.

TL;DR Un agent, c’est un modèle plus un harnais. Le harnais, c’est chaque morceau de code, de configuration et de logique d’exécution qui n’est pas le modèle lui-même (LangChain, 2026). METR appelle la même chose un échafaudage et la traite comme une pièce porteuse : un chiffre de capacité sans échafaudage nommé ne veut presque rien dire. LangChain rapporte avoir fait passer un agent de code du Top 30 au Top 5 sur Terminal Bench 2.0 en ne changeant que le harnais, à modèle constant. Et le harness engineering n’est pas seulement ce que fait un laboratoire quand il construit la boucle. La plupart des gens le pratiquent de l’extérieur, en câblant outils, sous-agents et garde-fous autour d’un agent qu’ils n’ont pas écrit. C’est dans le harnais que se gagne la fiabilité, parce que c’est là que les règles de contexte s’exécutent réellement.

Agent = Modèle + Harnais

Commencez par la définition, car toute la discipline en découle. LangChain le dit aussi simplement que possible : « Un harnais, c’est chaque morceau de code, de configuration et de logique d’exécution qui n’est pas le modèle lui-même. » Et le corollaire, la phrase qui mérite d’être retenue : « Si vous n’êtes pas le modèle, vous êtes le harnais » (LangChain, The Anatomy of an Agent Harness, 2026).

Böckeler, sur le site de Fowler, ramène cela à une équation : « Agent = Model + Harness » (Böckeler, 2026). Simon Willison dit la même chose depuis le versant outillage : « Un agent de code est un logiciel qui sert de harnais à un LLM » (Willison, 2026). Trois sources, une même frontière. Le modèle, c’est la partie que vous téléchargez. Le harnais, c’est la partie que vous construisez.

Cela compte parce que les deux moitiés progressent à des horloges différentes. Un nouveau modèle arrive quand un laboratoire en publie un. Le harnais, vous pouvez le changer cet après-midi. Donc si la capacité dépend des deux, votre levier se trouve dans la moitié que vous contrôlez. C’est là le renversement. Le harnais n’est pas la tuyauterie autour de la partie intéressante. À modèle figé, il est la partie intéressante.

Le harnais, c’est l’échafaudage

Le mot est neuf. La chose ne l’est pas. METR, dont le travail d’évaluation est à peu près ce que ce domaine produit de plus rigoureux, parlait déjà d’« échafaudage » (scaffold) en 2024. Même objet, nom plus ancien.

Le cadrage de METR mérite d’être emprunté, parce qu’il est précis sur ce qu’il mesure.

🔬 Un chiffre sans échafaudage ne dit pas grand-chose. La capacité, soutiennent-ils, devrait se lire sur « le meilleur échafaudage disponible », parce que l’échafaudage fixe matériellement le plafond mesuré (METR, Guidelines for capability elicitation, 2024). Un modèle testé à travers un échafaudage faible paraît faible. Les mêmes poids à travers un échafaudage solide paraissent solides. Un chiffre de capacité sans échafaudage nommé ne veut donc presque rien dire.

Les éditeurs ont plutôt retenu « harnais ». Anthropic livre « un harnais d’agent puissant et généraliste » et documente ses « capacités de gestion du contexte, comme la compaction » (Anthropic, 2025). LangChain, Fowler et Willison emploient « harnais » eux aussi. Échafaudage, harnais : lisez-les comme des synonymes. J’utiliserai « harnais » parce que c’est là que le discours des praticiens s’est fixé, mais quand METR dit scaffold, c’est bien de cela qu’il parle.

De quoi un harnais est fait

Décomposez la machine. Six pièces font le travail.

La boucle est le moteur. Raisonner, appeler un outil, observer le résultat, recommencer. Willison en nomme la forme canonique : « un LLM, un prompt système et des outils dans une boucle » (Willison, 2026). Tout le reste s’accroche à ce cycle.

Les outils et l’exécution sont les mains. Lectures de fichiers, commandes shell, appels d’API, un bac à sable pour le code. Le modèle propose une action sous forme de texte. Le harnais est ce qui l’exécute vraiment et renvoie le résultat.

La gestion du contexte est l’éditeur. Compaction, troncature, résumé : le harnais décide de ce qui reste dans la fenêtre et de ce qui saute à mesure que l’exécution s’allonge. Anthropic présente la compaction comme une capacité de harnais à part entière (Anthropic, 2025). Retenez celle-là. C’est la couture avec le context engineering, et j’y reviens.

Les sous-agents et l’orchestration répartissent le travail. Le harnais longue durée d’Anthropic fait tourner un Planner, un Generator et un Evaluator, chacun avec son propre contexte neuf (Anthropic, Harness design for long-running application development, 2026). Un seul modèle, plusieurs rôles, coordonnés par la machine.

La mémoire et l’état portent ce que la fenêtre ne peut pas porter. Mémoire sur fichiers, brouillons de travail, réinitialisations de contexte qui rechargent depuis le disque. La fenêtre est finie ; la mémoire, c’est la façon dont l’agent se souvient au-delà du point où la fenêtre oublie.

Les garde-fous et les permissions sont les freins. Ce à quoi l’agent a le droit de toucher, quelles commandes exigent une approbation, où passent les frontières d’isolation. Böckeler décrit le harnais en termes d’automatique : des guides qui alimentent le modèle vers l’avant, des capteurs qui font remonter les résultats (Böckeler, 2026). Les garde-fous, c’est là que vous dites non.

Anthropic donne la règle de conception qui relie tout cela : « Chaque composant d’un harnais encode une hypothèse sur ce que le modèle ne sait pas faire seul » (Anthropic, 2026). Lisez votre harnais et vous lisez votre propre liste des limites du modèle.

Même modèle, meilleur harnais, capacité supérieure

Voici l’affirmation, preuve à l’appui. Gardez les poids figés, améliorez la machine, et la capacité mesurée monte.

🔬 Mêmes poids, meilleure machine. LangChain a pris un agent de code, maintenu le modèle constant sur un unique modèle de pointe, changé le seul harnais, et rapporte l’avoir fait passer du Top 30 au Top 5 sur Terminal Bench 2.0 (LangChain, 2026).

Aucun poids nouveau. Un meilleur instrument jouant la même partition.

C’est exactement pour cela que METR insiste pour que la capacité se lise sur le meilleur échafaudage disponible. Le plafond mesuré appartient au couple, modèle et harnais, pas aux poids seuls. Améliorez la moitié que vous contrôlez et le chiffre bouge, sur un modèle qui n’a pas changé. Voilà l’argument pour traiter le harness engineering comme une discipline. Quand le modèle est figé, et pour la plupart des équipes il l’est la plupart du temps, le harnais est le levier qui vous reste en main.

L’essentiel du harness engineering se fait de l’extérieur

Il est facile de lire tout ceci comme le travail de ceux qui construisent des agents à partir de zéro, laboratoires et auteurs de frameworks qui câblent une boucle raisonner-appeler-observer. C’est vrai pour une partie. Mais aujourd’hui, l’essentiel du harness engineering est fait par des gens qui n’ont jamais écrit la boucle.

Vous adoptez un agent livré par quelqu’un d’autre, puis vous concevez le harnais autour. Vous choisissez les outils qu’il peut appeler et les serveurs MCP qu’il peut atteindre. Vous composez des sous-agents et confiez à chacun une part du travail. Vous écrivez les garde-fous : quelles commandes exigent une approbation, quels chemins sont interdits, où passe la frontière d’isolation. Vous lui donnez des fichiers de mémoire et les instructions qu’il recharge à chaque exécution. Rien de tout cela n’est le modèle. Tout cela est le harnais.

C’est pour cette raison que l’article de Böckeler s’intitule « Harness engineering for coding agent users » (Böckeler, 2026), et que Willison écrit sur les agents de code depuis la même place de praticien (Willison, 2026). La discipline n’est pas réservée à celui qui a compilé la boucle. Si vous façonnez ce à quoi un agent peut toucher, ce dont il se souvient et ce qu’on peut l’empêcher de faire, vous faites déjà du harness engineering, que vous ayez construit la boucle ou que vous l’ayez seulement configurée.

Le harnais applique ce que le context engineering décide

Venons-en à la couture, parce que c’est là que les deux disciplines jumelles se rejoignent et que les discussions se croisent sans se rencontrer.

Tracez la ligne par objet. Le context engineering travaille le contenu : quels tokens méritent une place dans la fenêtre, à choisir à neuf à chaque étape. C’est du jugement, du goût, une décision. Le harness engineering travaille la machine : le runtime qui fait entrer et sortir ces tokens. C’est du code. La gestion du contexte est leur point de contact. La compaction est une décision sur ce qui compte, exécutée par une capacité du harnais. Le context engineering décide ; le harnais applique.

Je dois être honnête : le domaine ne s’accorde pas sur la façon dont ces deux disciplines s’emboîtent. LangChain met le harnais au-dessus : « les harnais sont aujourd’hui essentiellement des mécanismes de livraison pour un bon context engineering », donc le harnais contient le travail de contexte. Böckeler inverse : « un harnais est une forme particulière de context engineering », donc le context engineering contient le harnais. Anthropic garde les deux vocabulaires séparés et ne les emboîte pas du tout. Trois sources respectées, trois récits d’emboîtement.

Je ne vais donc pas faire comme si la hiérarchie était tranchée. Je trace une ligne fonctionnelle et je dis que je la trace : contenu contre machine, décision contre application. C’est une frontière de travail, pas une loi. Elle a la seule propriété dont j’ai besoin : elle vous dit quelle discipline possède quelle panne. Si les mauvais tokens ont été retenus, c’est un problème de contexte. Si les bons tokens ont été retenus et que la machine les a jetés quand même, c’est un problème de harnais. Pour le versant contenu de la couture, dans ses propres mots, allez voir le jumeau : le context engineering, le versant contenu.

Pourquoi la sobriété doit vivre ici

C’est ici que ça paie, et là que la thèse de fond mord. Une fenêtre sobre, ce n’est pas quelque chose qu’on espère. C’est quelque chose que la machine impose.

Demandez-vous à qui l’on demande de garder la fenêtre sobre. Si la réponse est « au modèle, en surveillant lui-même son contexte », c’est déjà perdu, car le modèle ne peut pas voir ce qu’on ne lui montre pas et n’a aucune raison de dépenser moins de tokens. Les bonnes intentions ne compactent pas une transcription. Une capacité, si. La compaction est une capacité du harnais (Anthropic, 2025). La troncature est une capacité du harnais. Les réinitialisations de contexte qui rechargent la mémoire depuis le disque sont une capacité du harnais. La sobriété est une propriété qu’on inscrit dans le runtime, pas une discipline qu’on demande aux poids d’exercer.

Voilà pourquoi l’argument de la sobriété se joue ici et pas dans le modèle. Vous ne comptez pas sur le modèle pour garder sa propre fenêtre propre. Vous imposez une fenêtre sobre dans la machine, comme vous imposez tout ce à quoi vous tenez vraiment : avec du code qui s’exécute que le modèle coopère ou non. Le harnais est la couche d’application. Si ce n’est pas dans le harnais, c’est un vœu.

On lâche les mains

Cet article a tracé le versant machine de la ligne. Son jumeau trace le versant contenu : quels tokens méritent leur place, et pourquoi la curation est une discipline de décision avec le goût humain au centre. À lire ensuite : le context engineering, le versant contenu.

Sous les deux se trouve le mécanisme. Si « la fenêtre », « la compaction » et « les tokens » portent beaucoup de poids et que vous voulez la mécanique, voyez ce qu’est une fenêtre de contexte. Le coût, la position et la dégradation découlent tous d’une seule ligne : le modèle relit toute la fenêtre à chaque étape.

Et les capacités de harnais nommées ici méritent chacune son propre article. Comment compiler des spécifications en scripts d’exécution que le harnais lance. Comment des linters sur mesure deviennent des garde-fous que la boucle ne peut pas contourner. Comment permissions et isolation s’appliquent à la frontière. Voilà la machine, en détail. Ceci était la machine, en esquisse.

Retenez cette seule ligne. Le modèle est figé ; le harnais ne l’est pas. Tout ce que vous pouvez encore changer à ce que votre agent fait de façon fiable, vous le changez dans la machine autour du modèle.

Sources

• LangChain (Trivedy, V.), The Anatomy of an Agent Harness, 2026. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
• Böckeler, B. (Thoughtworks / martinfowler.com), Harness engineering for coding agent users, 2026. https://martinfowler.com/articles/harness-engineering.html
• Willison, S., How coding agents work, 2026. https://simonwillison.net/guides/agentic-engineering-patterns/how-coding-agents-work/
• METR, Guidelines for capability elicitation, 2024. https://metr.org/blog/2024-03-15-guidelines-for-capability-elicitation/
• Anthropic (Young, J.), Effective harnesses for long-running agents, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic (Rajasekaran, P.), Harness design for long-running application development, 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps