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 exclusivement focalisée sur la question « quel modèle d’IA est le plus intelligent ? ». Les comparaisons sans fin pour savoir si GPT écrit un code plus propre ou si Claude hallucine moins se sont multipliées, mais sa thèse est que, dans la pratique, les performances réelles d’une IA de codage 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 system prompt qui donne du travail à l’IA, les outils et serveurs externes qu’elle peut utiliser, les politiques de gestion du contexte, les dispositifs de contrôle automatiques qui s’intercalent pendant l’exécution (hooks), les espaces d’exécution sécurisés (sandboxes), les IA auxiliaires (subagents), les boucles de feedback, jusqu’aux mécanismes de reprise quand le travail se bloque. Viv Trivedy a formalisé l’idée en une formule simple : « AI agent = model + harness ». Des équipes comme Anthropic Engineering, HumanLayer ou Simon Willison sont en train d’affiner cette approche. Pour Osmani, ce courant constitue désormais un véritable domaine d’ingénierie.

Les points clés sont les suivants.

• Qu’est-ce qu’un 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 qui lui permettent de mémoriser l’avancement, d’exécuter des outils, d’observer les résultats, de réévaluer la situation et d’empêcher certaines actions interdites. Des produits comme Claude Code, Cursor, Codex, Aider ou Cline sont tous des harness ; même avec le même modèle à l’intérieur, le comportement perçu dépend du harness. Pour reprendre la formule de Simon Willison, un agent IA est « un système qui exécute des outils de manière 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 itérative.

• Le problème vient des réglages, pas du modèle Quand une IA fait n’importe quoi, les ingénieurs ont tendance à accuser le modèle et à conclure qu’il faut « attendre la version suivante ». Le harness engineering rejette cette réaction. En reprenant les mots de HumanLayer, « ce n’est pas un problème de modèle, c’est un problème de réglage (skill issue) ». Il existe des cas où le même modèle Claude Opus 4.6 reste en bas du classement de Terminal Bench 2.0 dans son harness par défaut, Claude Code, puis grimpe parmi les meilleurs une fois placé dans un harness retravaillé à la main. L’équipe de Viv a fait passer le même modèle du top 30 au top 5 en ne changeant que le harness. Autrement dit, le potentiel du modèle est souvent bridé par son harness.

• Le principe du « ratchet » : transformer les erreurs en règles Lorsqu’une IA commet une erreur, il ne faut pas la traiter comme un accident isolé, mais comme un signal durable. L’idée est de resserrer le système cran par cran : ajouter une ligne au document de règles, brancher un mécanisme de blocage automatique, introduire une IA auxiliaire chargée de la revue, afin d’empêcher que la même erreur se reproduise. Par exemple, si l’IA a commenté du code de test, la version suivante du document de règles devra inclure une ligne du type « ne pas commenter les tests ; les supprimer ou les corriger », et l’étape de vérification avant commit devra intégrer un contrôle pour repérer ce motif. Le point essentiel est que chaque ligne d’un bon document de règles doit être reliée à un échec concret du passé. Le harness engineering ne consiste donc pas à prendre tel quel un framework conçu par d’autres, mais relève plutôt d’une discipline qui se cultive à partir de l’historique d’échecs de sa propre codebase.

• Concevoir à rebours à partir du comportement souhaité L’une des méthodes les plus utiles proposées par Viv consiste à raisonner à l’envers : « je veux tel comportement → quels composants du harness le rendent possible ? ». Si l’on ne peut pas expliquer en une phrase à quel comportement sert un composant, mieux vaut le retirer. Concrètement, le système de fichiers et Git servent à conserver et restaurer le travail ; bash et l’exécution de code sont des outils universels pour tout essayer ; le sandbox fournit un espace d’exécution sûr qui protège le système principal en cas de problème ; les fichiers mémoire, la recherche web et les outils 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 ; enfin, la Ralph loop et l’architecture séparant planificateur et évaluateur permettent de mener à bien des tâches longues qui durent plusieurs jours.

• Le problème du context rot La quantité de texte qu’une IA peut lire en une fois est limitée, et plus on s’approche de cette limite, plus sa capacité de jugement se dégrade visiblement. Le harness est donc aussi un ensemble de mécanismes destinés à bien utiliser cet espace limité. Premièrement, lorsque la limite approche, on compresse intelligemment les contenus anciens au moyen de résumés. Deuxièmement, pour les sorties volumineuses comme un log de 2 000 lignes, on ne conserve que le début et la fin dans le contexte, tandis que le corps est déplacé dans un fichier relu seulement si nécessaire. Troisièmement, au lieu de montrer dès le départ tous les outils et toutes les instructions, on adopte une « divulgation progressive » qui ne les expose qu’au moment où ils sont réellement utiles pour la tâche. Pour les travaux vraiment longs, il arrive même qu’on reparte de zéro dans une nouvelle fenêtre, avec seulement un document de transmission structuré. Anthropic souligne que, pour les tâches longues, la seule compression par résumé ne suffit pas toujours et qu’il faut parfois redémarrer à partir d’un document de handoff structuré. C’est comparable à la manière dont on prépare une documentation claire lorsqu’on transmet un travail à un nouveau collègue.

• Les motifs qui permettent de tenir sur la durée L’un des points faibles des modèles actuels est leur tendance à vouloir terminer trop tôt, à mal découper les gros problèmes et à perdre le fil quand la fenêtre de contexte change. Le harness doit compenser ces faiblesses. La Ralph loop est une technique simple : chaque fois que le modèle essaie de conclure, un hook intercepte ce moment et réinjecte l’objectif initial dans une nouvelle fenêtre de contexte pour poursuivre le travail. Chaque itération redémarre dans un état propre, mais les résultats précédents sont transmis par le système de fichiers. De son côté, Anthropic insiste sur la nécessité de séparer l’« agent de génération » de l’« agent d’évaluation », car une IA qui s’auto-évalue a tendance à être trop indulgente. En complément, le motif du « sprint contract », qui consiste à s’accorder dès le départ sur ce que signifie exactement « terminé », aide efficacement à éviter la dérive progressive du périmètre pendant l’exécution.

• Le rôle des hooks Dire à l’IA de faire quelque chose n’est pas la même chose que configurer le système pour l’y contraindre. Les hooks comblent cet écart : ce sont des mécanismes automatiques qui interviennent à des moments précis, comme avant l’utilisation d’un outil, après 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 dangereuses comme rm -rf ou git push --force, ou encore exiger une approbation humaine avant l’ouverture d’une PR. Le principe est simple : « succès silencieux, échec bruyant ». Si les vérifications passent, l’IA n’entend rien ; si elles échouent, le message d’erreur est réinjecté tel quel dans le flux afin qu’elle se corrige elle-même. C’est une structure peu coûteuse au quotidien, mais très précise au moment où un problème survient.

• Documents de règles et choix des outils : courts et explicites Le fichier AGENTS.md placé à la racine du projet est le fichier de configuration le plus influent, car il entre dans le system prompt à chaque tour. HumanLayer recommande de le maintenir sous les 60 lignes. Plus il s’allonge, plus chaque ligne perd de son poids ; il ne faut donc pas en faire un guide de style général, mais plutôt une checklist de pilote d’avion qui ne conserve que l’essentiel. Même logique pour les outils : comme leur nom, leur description et leur schéma sont injectés dans le prompt à chaque requête, il vaut mieux disposer de 10 outils bien conçus que de 50 outils redondants. HumanLayer souligne aussi l’enjeu de sécurité : puisque la description des outils devient du texte lu par l’IA, connecter un serveur MCP externe non vérifié revient potentiellement à ouvrir un canal d’injection d’instructions écrites à l’avance par quelqu’un d’autre.

Voici les principaux avantages.

• Les zones d’effort deviennent claires Les données de benchmark montrent que le harness est un levier capable d’améliorer fortement le comportement sans changer de modèle. Au lieu d’attendre vaguement « le prochain modèle », on dispose d’un domaine concret sur lequel agir immédiatement.
• Une structure qui capitalise le savoir-faire Grâce à l’approche ratchet, qui transforme les erreurs en règles, chaque leçon apprise devient un actif d’équipe. Même si les personnes changent, le document de règles et les hooks restent en place et protègent les suivants.
• L’émergence de harness prêts à l’emploi (HaaS) Le mouvement que Viv appelle « Harness-as-a-Service » s’installe rapidement. Des produits comme Claude Agent SDK, Codex SDK ou OpenAI Agents SDK intègrent déjà la boucle de travail, les outils, la gestion du contexte, les hooks et les sandboxes, ce qui permet de se concentrer sur sa connaissance métier plutôt que de tout reconstruire depuis zéro.

Il existe aussi des aspects plus lourds.

• Un périmètre large à prendre en charge Instructions, outils, espace d’exécution sécurisé, vérifications automatiques, observation des logs : tout cela doit être assumé directement. Le point central est que le fournisseur de modèle ne s’en charge pas pour vous.
• Le risque de couplage entre modèle et harness Les modèles actuels sont post-entraînés à l’intérieur de harness spécifiques ; lorsqu’on les déplace ailleurs, leurs performances peuvent soudain chuter. Il suffit parfois de modifier un nom d’outil ou le format d’un argument pour déstabiliser le résultat. Un modèle véritablement général ne devrait pas dépendre du nom des outils, mais la co-construction modèle+harness crée une forme de surapprentissage.
• Les risques de sécurité liés aux outils externes Comme les descriptions d’outils des serveurs MCP sont lues directement par l’IA, l’ajout d’un outil non vérifié signifie que, avant même que l’utilisateur n’ait saisi le moindre caractère, un texte externe commence déjà à influencer l’IA.

Voici les points de différenciation de cette approche.

• Prendre ses distances avec un discours centré sur le modèle Plutôt que d’attendre un GPT plus intelligent, cette approche propose des méthodes d’ingénierie pour repousser les limites du 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 change de place Quand les modèles s’améliorent, certains composants du harness deviennent inutiles. Par exemple, Opus 4.6 a quasiment fait disparaître l’empressement que l’on observait souvent avec Claude Sonnet 4.5, du type « le contexte va bientôt se terminer, il faut vite conclure », rendant obsolètes plusieurs dispositifs de réassurance auparavant nécessaires. Mais à mesure que le modèle atteint de nouveaux domaines, de nouvelles faiblesses apparaissent, et de nouveaux harness sont alors nécessaires pour les compenser. La formule d’Anthropic résume bien cela : « chaque composant du 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 dynamique de rétroaction entre la conception des harness et l’apprentissage des modèles. Lorsqu’un motif utile est découvert dans un harness, il se standardise ; la génération suivante de modèles est entraînée en prenant ce motif comme référence ; puis de nouveaux motifs de harness apparaissent au-dessus de ces modèles. D’où la conclusion suivante : le « bon harness » n’est pas forcément celui avec lequel le modèle a été entraîné, mais celui qui a été retravaillé pour correspondre à votre travail.
• Une convergence de l’industrie vers une même forme Claude Code, Cursor, Codex, Aider ou Cline embarquent des modèles différents, mais leurs harness se ressemblent de plus en plus. Le fait que les modèles divergent tandis que les harness convergent apparaît comme un signal sur la direction dans laquelle ce domaine est en train de se stabiliser.

Le texte d’Osmani défend l’idée que la compétitivité des IA de codage 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 que l’on règle une fois pour toutes, mais un système vivant qui évolue en continu à 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 traités, et de nouveaux harness viennent alors combler l’espace laissé libre. Comme le dit Viv dans une formule citée 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, dans ce domaine, tout se joue sur la capacité à commencer vite puis à affiner plus souvent que les autres. En fin de compte, le vrai endroit où les ingénieurs doivent investir leur temps n’est pas de remplacer sans cesse le modèle du moment, mais de retravailler en permanence le harness adapté à leur propre usage afin de relever, cran après cran, le plafond de ce que le modèle peut accomplir.

[kimjoin2]

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

[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

[tangokorea]

Plutôt que de prendre du recul en se demandant lequel est meilleur entre le modèle et le harnais, et si l’on se demandait plutôt quel harnais convient le mieux à quel modèle ?

[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

[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.