Harness Engineering : l’ère où la conception de l’environnement de travail compte plus que le modèle

Il s’agit d’une analyse d’Addy Osmani sur le « harness engineering ». Selon lui, depuis deux ans, l’attention du secteur s’est presque entièrement concentrée sur la question « quel modèle d’IA est le plus intelligent ? ». Les comparaisons se sont succédé sans fin pour savoir si GPT écrivait un code plus propre ou si Claude hallucinait moins, alors que, selon lui, les performances réelles d’une IA de programmation sont davantage déterminées par le harness qui entoure le modèle que par le modèle lui-même. Le terme harness désigne tout ce qui n’est pas le modèle : le prompt système qui permet d’assigner des tâches à l’IA, les outils et serveurs externes qu’elle peut utiliser, les politiques de gestion du contexte, les mécanismes de vérification automatiques qui s’insèrent pendant l’exécution (hooks), les espaces d’exécution sécurisés (sandboxes), les IA auxiliaires (sous-agents), les boucles de feedback, jusqu’aux flux de récupération quand le travail se bloque. Viv Trivedy a formalisé cette idée en une phrase : « AI agent = model + harness », et des acteurs comme l’équipe d’ingénierie d’Anthropic, HumanLayer ou Simon Willison affinent cette approche. Osmani estime que cette dynamique constitue désormais un véritable domaine d’ingénierie.

Voici les points essentiels.

• Qu’est-ce que le harness ? Un modèle seul ne suffit pas à faire une IA capable de terminer un travail. Il faut lui ajouter du code et des réglages pour qu’elle se souvienne de l’avancement, exécute des outils, examine les résultats, réévalue la situation et empêche les actions à éviter. C’est seulement ainsi qu’on obtient une « IA qui travaille ». Des produits comme Claude Code, Cursor, Codex, Aider ou Cline sont tous des harnesses, et même si le modèle qu’ils embarquent est identique, l’expérience concrète dépend du harness. Pour reprendre la formule de Simon Willison, un agent IA est « un système qui exécute des outils de façon répétée pour atteindre un objectif », et la vraie compétence réside dans la manière de concevoir ces outils et cette structure de répétition.

• Le problème vient des réglages, pas du modèle Quand une IA fait n’importe quoi, les ingénieurs ont souvent le réflexe d’accuser le modèle et de conclure qu’il faut « attendre la prochaine version ». Le harness engineering rejette cette réaction. Pour reprendre l’expression de HumanLayer, « ce n’est pas un problème de modèle, c’est un problème de réglage (skill issue) ». On a vu le cas d’un même modèle, Claude Opus 4.6, qui restait dans le bas du classement sur Terminal Bench 2.0 avec le harness par défaut de Claude Code, puis bondissait vers le haut du classement une fois intégré dans un harness retravaillé à la main. L’équipe de Viv a ainsi fait passer un même modèle d’environ la 30e place à la 5e uniquement en changeant le harness. Autrement dit, le harness bride souvent le potentiel réel du modèle.

• Le principe de « ratchet » qui transforme les erreurs en règles Lorsqu’une IA commet une erreur, on ne la traite pas comme un accident isolé mais comme un signal permanent. On resserre alors progressivement le système pour éviter que la même erreur ne se reproduise : on ajoute une ligne au document de règles, un mécanisme de blocage automatique, ou une IA auxiliaire chargée de la revue. Par exemple, si une IA a déjà commenté du code de test, la prochaine version du document de règles inclura une ligne comme « ne pas commenter les tests, les supprimer ou les corriger », et une vérification capable de détecter ce motif sera ajoutée avant le commit. L’idée clé est que chaque ligne d’un bon document de règles doit correspondre à un échec concret du passé. Le harness engineering n’est donc pas l’adoption passive d’un framework conçu par quelqu’un d’autre, mais une forme de discipline qui grandit à partir de l’historique des échecs de son propre codebase.

• Concevoir à rebours depuis le comportement souhaité La méthode la plus utile proposée par Viv consiste à raisonner à l’envers : « je veux tel comportement → quels composants du harness le rendent possible ? ». Si l’on n’est pas capable d’expliquer en une phrase à quoi sert un composant, mieux vaut le retirer. Concrètement, le système de fichiers et Git servent à conserver durablement le travail et à revenir en arrière, Bash et l’exécution de code sont des outils universels pour tenter n’importe quoi, le sandbox est un espace d’exécution sûr qui protège le système principal en cas d’erreur, les fichiers mémoire et les outils de recherche web ou MCP servent à accumuler de nouvelles connaissances, la compression par résumé, la séparation des sorties d’outils et les fonctions de skill étendent les limites de mémoire de l’IA, et la Ralph loop comme la séparation entre planificateur et évaluateur permettent de mener à terme des tâches qui durent plusieurs jours.

• Le problème du context rot Une IA a une quantité limitée de texte qu’elle peut lire à la fois, et sa qualité de jugement baisse visiblement à mesure qu’elle s’approche de cette limite. Le harness est donc aussi un ensemble de mécanismes destinés à bien utiliser cet espace restreint. Premièrement, quand la limite approche, les anciens contenus sont compressés intelligemment sous forme de résumés. Deuxièmement, de grosses sorties, comme un log de 2 000 lignes, sont tronquées pour ne garder que le début et la fin, tandis que le corps est déplacé dans un fichier à relire seulement si nécessaire. Troisièmement, on n’affiche pas dès le départ tous les outils et toutes les instructions : on adopte une « divulgation progressive », qui ne révèle que ce qui est nécessaire au moment où cela devient utile. Pour les tâches vraiment longues, on peut même repartir de zéro dans une nouvelle fenêtre avec seulement un document de passation. Anthropic souligne que « pour les tâches longues, la compression par résumé ne suffit pas toujours, et il faut parfois repartir avec un document de passation structuré ». C’est comparable, côté humain, au fait de préparer une documentation claire lorsqu’on transmet un travail à un nouveau collègue.

• Les schémas qui permettent de tenir dans la durée Parmi les faiblesses actuelles des modèles, il y a la tendance à vouloir terminer trop tôt, l’incapacité à bien décomposer les gros problèmes, et la perte de continuité lorsqu’on change de fenêtre de contexte. Le harness doit compenser ces limites. La Ralph loop est une technique simple : dès que le modèle tente de conclure, un hook l’intercepte et réinjecte l’objectif initial dans une nouvelle fenêtre de contexte pour relancer le travail. Chaque itération repart d’un état propre, mais les résultats précédents sont transmis via le système de fichiers. De son côté, Anthropic insiste sur la nécessité de séparer l’« IA génératrice » et l’« IA évaluatrice », car une IA qui juge sa propre production a tendance à être trop indulgente. En complément, le pattern du « sprint contract », qui consiste à définir à l’avance ce que signifie exactement « c’est terminé », est efficace pour empêcher le glissement progressif des objectifs pendant l’exécution.

• Le rôle des hooks « Dire à l’IA de faire quelque chose » et « faire en sorte que le système l’y oblige » sont deux choses différentes. Les hooks comblent cet écart. Ce sont des automatismes qui s’insèrent à des moments précis : avant l’utilisation d’un outil, après la modification d’un fichier, juste avant un commit, ou au démarrage d’une session. Ils peuvent, par exemple, lancer automatiquement une vérification syntaxique, un lint ou des tests à chaque modification de code, bloquer des commandes risquées comme rm -rf ou git push --force, ou imposer une validation humaine avant l’ouverture d’une PR. Le principe est : « le succès en silence, l’échec bruyamment ». Si la vérification passe, l’IA n’entend rien ; si elle échoue, le message d’erreur est injecté tel quel dans le flux afin qu’elle puisse se corriger elle-même. C’est une structure qui ne coûte presque rien au quotidien, tout en apportant une aide très précise au moment où un problème survient.

• Documents de règles et choix des outils : courts et nets Le fichier AGENTS.md placé à la racine du projet est le fichier de configuration le plus influent, car il entre dans le prompt système à chaque tour. HumanLayer recommande de le maintenir sous les 60 lignes. Plus il s’allonge, plus le poids de chaque ligne se dilue ; ce ne doit pas être un guide de style général, mais une checklist de pilote avec uniquement l’essentiel. Il en va de même pour les outils : comme leur nom, leur description et leur schéma sont injectés dans le prompt à chaque requête, il vaut mieux 10 outils bien conçus que 50 outils redondants. HumanLayer souligne aussi un point de sécurité : puisque la description d’un outil est elle-même un texte lu par l’IA, connecter un serveur MCP externe non vérifié revient à ouvrir un canal d’injection discrète d’instructions rédigées par quelqu’un d’autre.

Voici les aspects qui peuvent être considérés comme des points forts.

• Un point d’effort clairement identifié Les données de benchmark montrent que le harness est l’endroit où l’on peut fortement améliorer le comportement sans changer de modèle. Au lieu d’attendre vaguement « le prochain modèle », on dispose d’un domaine concret à optimiser dès maintenant.
• Une structure qui capitalise le savoir-faire Grâce à l’approche ratchet, qui transforme les erreurs en règles, chaque leçon apprise reste dans le patrimoine de l’équipe. Même si les personnes changent, les documents de règles et les hooks continuent de protéger les suivantes.
• L’émergence de harnesses prêts à l’emploi (HaaS) La tendance que Viv appelle « Harness-as-a-Service » s’installe rapidement. Des produits comme le Claude Agent SDK, le Codex SDK ou l’OpenAI Agents SDK regroupent déjà boucle de travail, outils, gestion du contexte, hooks et sandbox, ce qui permet de se concentrer sur sa connaissance métier sans tout construire depuis zéro.

Il y a aussi des aspects plus contraignants.

• Un périmètre large à prendre en charge Il faut soi-même assumer les instructions, les outils, l’espace d’exécution sécurisé, les contrôles automatiques et l’observation des logs. Le point essentiel est que ce n’est pas un domaine que le fournisseur du modèle gère à votre place.
• Le risque de couplage entre modèle et harness Les modèles actuels sont post-entraînés dans des harnesses spécifiques, si bien que les déplacer dans un autre harness peut faire chuter brutalement leurs performances. Il suffit parfois de changer un nom d’outil ou le format d’un argument pour perturber le résultat. En théorie, un modèle vraiment général ne devrait pas dépendre du nom d’un outil, mais la structure d’apprentissage conjointe produit une forme de surapprentissage.
• Les risques de sécurité des outils externes Avec les serveurs MCP, la description des outils est lue telle quelle par l’IA. Dès qu’on branche un outil non vérifié, un texte externe commence donc à influencer l’IA avant même que l’utilisateur n’ait tapé le moindre caractère.

Ce qui distingue cette approche.

• Prendre ses distances avec le discours centré sur le modèle Plutôt que d’attendre un GPT plus intelligent, elle propose une méthode d’ingénierie pour pousser au maximum le modèle dont on dispose déjà. Le diagnostic est que l’écart entre les limites visibles de l’IA aujourd’hui et les capacités réelles du modèle est, dans la plupart des cas, un écart de harness.
• Le harness ne disparaît pas, il se déplace Quand les modèles progressent, certains composants du harness deviennent inutiles. Par exemple, Opus 4.6 a pratiquement supprimé l’empressement qu’on voyait souvent chez Claude Sonnet 4.5, du type « le contexte va bientôt se terminer, il faut conclure vite », ce qui a rendu obsolètes tout un ensemble de garde-fous conçus pour rassurer. Mais dans les nouveaux domaines que les modèles atteignent apparaissent aussi de nouvelles faiblesses, qui exigent à leur tour de nouveaux harnesses. La formule d’Anthropic convient bien ici : « chaque composant d’un harness contient une hypothèse sur ce que le modèle ne sait pas faire seul ».
• La boucle d’apprentissage entre modèle et harness Viv met aussi en avant une autre dynamique : la boucle de rétroaction entre la conception du harness et l’entraînement du modèle. Lorsqu’un motif utile est découvert dans un harness, il est standardisé ; la génération suivante de modèles est ensuite entraînée sur cette base ; puis de nouveaux motifs de harness apparaissent au-dessus de ces nouveaux modèles. D’où cette conclusion : un « bon harness » n’est pas simplement le harness sur lequel le modèle a été entraîné, mais celui que l’on a retravaillé pour l’adapter à son propre travail.
• Le secteur converge vers une forme commune Des IA de programmation comme Claude Code, Cursor, Codex, Aider ou Cline embarquent des modèles différents, mais leurs harnesses se ressemblent de plus en plus. Le fait que les modèles divergent alors que les harnesses convergent est un signal sur la direction dans laquelle ce domaine est en train de se stabiliser.

Le texte d’Osmani avance donc que la compétitivité d’une IA de programmation dépend davantage de la conception du harness qui entoure le modèle que du choix du modèle lui-même, et que le harness n’est pas un simple fichier de configuration qu’on règle une fois pour toutes, mais un système vivant mis à jour en permanence à partir de l’historique des échecs. L’amélioration des modèles ne fait pas disparaître le harness : elle déplace simplement le niveau des problèmes à traiter, et de nouveaux harnesses viennent alors combler cet espace. Comme le dit Viv dans la citation reprise par Osmani, « construire un bon agent est un art de l’itération, et sans première version il n’y a pas d’itération ». Autrement dit, ce domaine est avant tout une course entre ceux qui commencent vite et raffinent plus souvent. En fin de compte, l’endroit où les ingénieurs doivent investir leur temps n’est pas de remplacer sans cesse le modèle à la mode, mais de retravailler continuellement le harness adapté à leur activité pour relever progressivement le plafond de ce que le modèle peut accomplir.

[kimjoin2]

J’ai l’impression qu’on voit surtout proliférer des termes marketing.

[jimmy2056]

Plus le modèle est performant, plus la charge de conception des harnais diminue.

[akapwhd]

Même en appliquant ce genre de choses, j’ai l’impression que ça n’aide pas beaucoup au moment de coder en pratique… C’est sans doute parce que le développement ici a un niveau de difficulté où il s’agit surtout de lancer un agent avec un plan Codex, haha

[dongho42]

Mais quand on met dans le prompt « fais A, ne fais pas B », cette approche semble valable si le modèle le comprend vraiment bien ; mais si, selon l’état du serveur IA, le prompt n’est suivi que de manière probabiliste, est-ce que cette approche reste vraiment efficace ?

[dongho42]

Autrefois, même quand j’écrivais clairement dans le prompt « fais A », il ne le respectait toujours pas avec une certaine probabilité, donc j’ai tout essayé : le mettre en gras en mrkdwn, l’écrire deux fois, l’écrire en anglais, le formuler en chiasme, l’écrire en XML… mais il finissait quand même par ignorer le prompt avec une certaine probabilité...

[kurthong]

Moi aussi, j’ai mis un peu de tout dans le même sac, dans le même esprit que ce que disait Osmani,
et comme ce sujet est arrivé pendant que je développais une appli, j’ai un peu précipité les choses,
mais je me dis qu’au lieu de se contenter d’en parler, Osmani aurait peut-être mieux fait d’intégrer ce qu’il racontait dans Google Anti-Gravity.
C’est pareil pour Kapasi : maintenant, au lieu de vraiment construire quelque chose, ils balancent juste un texte vite fait et s’arrêtent là… bof, quoi !

https://github.com/hang-in/tunaFlow

[blackfabric]

Résumé en 3 points

• Le système (le harnais) détermine davantage le succès ou l’échec que le modèle : les performances de l’IA dépendent moins du modèle lui-même, comme GPT ou Claude, que de la conception de l’environnement de travail qui l’entoure — prompts, outils, sandbox, boucles de feedback, etc. — appelé « harnais ».
• Le principe du « ratchet » : il faut éviter de considérer les erreurs de l’IA comme de simples accidents et les répercuter immédiatement dans la documentation des règles (AGENTS.md, par exemple) ou dans des hooks, afin que le système devienne plus robuste avec le temps.
• Le problème vient souvent de la configuration (skill), pas du modèle : si l’IA travaille mal, c’est souvent moins à cause d’un manque d’intelligence du modèle que d’une mauvaise conception du harnais, et une approche d’ingénierie consistant à concevoir, à rebours du résultat souhaité, les composants nécessaires et les contraintes est indispensable.

[yungoun]

Mais Harness, jusqu’à la semaine dernière, était vendu à fond, et depuis cette semaine c’est beaucoup plus calme… Peut-être à cause des ratés d’Anthropic et parce que Codex 5.5 est excellent, j’imagine…

[click]

Des trucs comme le SDD ont déjà perdu leur hype, donc j’imagine que c’est maintenant l’ère du harnais. Ce qui est assez étonnant avec le harnais, c’est que même si ce concept n’était manifestement pas dans les données d’entraînement, le modèle l’a compris très vite. C’est peut-être parce qu’il réutilise simplement le sens existant du mot ; je ne l’avais même pas mentionné qu’il disait déjà des choses comme « mettre à jour le harnais ».

[kurthong]

C’est une analyse d’un article de développeur senior qui rend très crédibles des propos assez creux à mes yeux (désolé, personnellement je n’aime pas Google). Cela dit, je pense bien sûr que l’approche consistant à essayer de comprendre le phénomène est une bonne tentative.