À retenir
- Un agent sans harness est difficile à déboguer parce qu’on ne peut pas voir, rejouer ou contraindre de façon fiable ce qui s’est produit.
- Le harness est l’endroit où les outils, les permissions, l’évaluation, les logs et les approbations humaines transforment une démo en système.
- La qualité d’un agent dépend autant de l’ingénierie qui l’entoure que du modèle qui effectue le raisonnement.
Regardez la version vidéo!
Si vous entendez parler de « harness engineering » partout depuis quelque temps et que votre première pensée est « ok, ce n’est probablement que du prompt engineering avec un plus beau nom », voilà la première idée fausse à éliminer.
Ce n’est pas le cas, et ce n’est pas « seulement » un nouveau terme.
Et la raison pour laquelle cela compte ne se limite pas au vocabulaire. Ce terme indique où l’IA se dirige réellement. À la fin de cet article, vous devriez pouvoir distinguer le prompt engineering, l’ingénierie du contexte et le harness engineering et, surtout, comprendre pourquoi l’industrie a soudainement commencé à s’y intéresser maintenant.
Ce qui a changé est assez simple. Les agents sont devenus assez bons pour être utiles, mais pas assez fiables pour qu’on leur fasse confiance sans supervision. Voilà toute l’histoire.
Les agents sont devenus assez bons pour être à la fois utiles et dangereux. Ils peuvent maintenant faire plus que générer du texte, ou des tokens. Assez utiles pour que les gens commencent à les laisser écrire du code sérieux, effectuer de vrais appels d’outils et travailler sur de longues tâches. Assez dangereux pour que, si vous les entourez seulement d’une boucle et d’un rêve, ils répètent avec confiance la même erreur idiote encore et encore. Même moi, il m’arrive de laisser Claude Code tourner en boucle beaucoup trop longtemps avant de regarder ce qu’il faisait réellement, parce que je travaillais sur autre chose en parallèle.
C’est vraiment de là que vient le harness engineering. De la douleur. De gens qui ont réalisé qu’une fois le modèle assez compétent, le goulot d’étranglement cesse d’être « peut-il générer du code? » et devient « puis-je le faire agir de façon fiable dans un vrai système? »
La façon la plus claire d’y penser est la suivante. Le prompt engineering définit ce qu’on demande. L’ingénierie du contexte définit ce qu’on envoie au modèle pour qu’il puisse répondre avec confiance. Le harness engineering définit comment l’ensemble fonctionne. Pas seulement les mots du prompt, ni seulement les tokens du contexte, mais l’environnement autour du modèle. Les outils qu’il peut utiliser. Les permissions qu’il possède. L’état qu’il conserve. Les tests qu’il doit réussir. Les logs que vous capturez. Les nouvelles tentatives, points de contrôle, garde-fous, revues et évaluations qui empêchent le système de dériver vers l’absurde. L’ingénierie du contexte s’inscrit dans cet ensemble. Elle compte énormément. Mais elle n’est pas toute l’histoire. Une plus grande fenêtre de contexte ne transforme pas par magie un agent instable en système fiable.
Le modèle est le moteur. Vous ne pouvez pas faire grand-chose sans lui, mais lorsque vous achetez une voiture, il est inclus. Vous travaillez là où vous pouvez apporter de la valeur. Le contexte fait partie du carburant, des changements d’huile et des renseignements du tableau de bord. Ce sont les choses que vous pouvez facilement optimiser et contrôler. Le harness est le reste de la voiture. La direction, les freins, les limites de voie, le calendrier d’entretien, les voyants et le fait que les portes ne devraient pas tomber sur l’autoroute. Si vous vous concentrez uniquement sur le moteur et le carburant, vous pouvez quand même construire une très mauvaise voiture.
Cela a commencé à devenir évident vers décembre 2025. Karpathy a parlé de cette inversion où son workflow est passé de la programmation surtout manuelle avec un peu d’aide d’un agent à une programmation surtout pilotée par un agent avec des modifications manuelles. On pourrait croire que l’histoire est « wow, les modèles ont gagné ». Mais ce n’est pas vraiment ça. L’histoire, c’est que dès que les agents sont devenus assez cohérents pour accomplir beaucoup de choses, tout le monde a aussi découvert à quel point ils étaient fragiles dans de vrais environnements. Ils affirmaient qu’une fonctionnalité était terminée sans exécuter les tests, parfois même sans réellement l’avoir implémentée. Ils perdaient le fil pendant les longues tâches. Ils apportaient des corrections locales qui brisaient les limites architecturales. Ils se coinçaient dans des boucles où ils apportaient indéfiniment d’infimes modifications, ce qui a aussi stimulé beaucoup de recherche sur la compaction. Je serais heureux d’en parler dans un prochain article si cela vous intéresse. Dites-le-moi!
Anthropic a offert l’un des premiers signaux les plus clairs. Son article sur les agents qui travaillent longtemps était essentiellement le plan d’un monde où des agents se relaient d’une session à l’autre, sans mémoire native entre les fenêtres de contexte. Au lieu de prétendre que le modèle se souviendra simplement de tout, l’équipe a externalisé la mémoire dans des artefacts. Une liste structurée de fonctionnalités. Un journal de progression. Des commits Git. Un script d’initialisation. Elle a même séparé les rôles entre un agent d’initialisation et un agent de programmation. C’est déjà une façon de penser en termes de harness. Vous cessez de demander au modèle d’être fiable par magie et commencez à concevoir un système qui rend cette fiabilité plus plausible pour l’agent.
Nous avons commencé à programmer autour des LLMs et des agents plutôt qu’autour des systèmes existants.
Mitchell Hashimoto a ensuite donné un nom à tout cela au début de février 2026. Et honnêtement, je pense que son cadrage explique pourquoi le terme est resté : chaque fois que l’agent commet une erreur, n’espérez pas seulement qu’il fasse mieux la prochaine fois. Concevez l’environnement pour qu’il ne puisse plus commettre cette erreur précise de la même façon. Améliorez AGENTS.md en fonction des mauvais comportements observés. Ajoutez des scripts, des linters, des vérifications et des outils afin que l’agent puisse vérifier et corriger son propre travail. C’est un changement de mentalité très important, parce qu’on cesse de faire reposer la solution sur la prochaine version du modèle et qu’on remet la responsabilité entre les mains du builder. Vous cessez de dire « ce modèle est idiot ». Vous commencez à dire « mon système a permis ce mode d’échec ». Et surtout, nous cessons d’attendre que les fournisseurs améliorent encore leurs modèles et adaptons plutôt nos outils et notre setup. Même les personnes qui ne programment pas peuvent le faire avec de meilleurs fichiers de skills et du prompting en général, en itérant avec les agents pour qu’ils fassent mieux chaque fois. Par exemple, dans chacun de mes fichiers de skills pour Claude Code ou Cowork, j’ai ajouté une dernière étape qui lui demande de réfléchir à l’ensemble de l’échange, de comprendre ce que j’ai aimé ou non, puis d’ajuster sa propre skill afin de faire mieux la prochaine fois. Je lui demande aussi parfois de prendre le temps de trouver une meilleure façon d’accomplir la tâche et, si elle fonctionne, de modifier la skill. Depuis que je fais cela, j’économise des tonnes et des tonnes de tokens et de temps.
OpenAI a ensuite rendu le phénomène impossible à ignorer. Son rapport décrivait la construction d’un produit interne comprenant environ un million de lignes de code et zéro ligne de code source écrite manuellement. Même chose pour le créateur de Claude Code, qui a partagé un tweet affirmant que toutes les anciennes lignes de code de Claude Code avaient été poussées par Claude Code lui-même. Ce qui compte ici ne se limite pas au titre accrocheur. C’est tout ce que ces équipes ont dû construire autour des agents pour rendre cela possible. Une documentation structurée du dépôt comme véritable source de vérité. AGENTS.md comme carte, pas comme mur de texte géant. Une architecture en couches imposée par des linters et des tests. Des boucles de révision d’un agent par un autre avant le merge. Des agents de nettoyage en arrière-plan qui corrigent la dérive. Ce n’est pas simplement écrire des prompts. C’est concevoir une infrastructure. C’est l’ingénierie logicielle qui monte d’un niveau.
Et c’est ici que le lien avec l’ingénierie du contexte devient vraiment utile, parce que je pense que beaucoup de gens confondent actuellement ces deux termes. L’ingénierie du contexte consiste à rendre la tâche plausiblement réalisable par le modèle à un moment donné. Quels renseignements devraient se trouver dans la fenêtre? Que devrait-on récupérer? Que devrait-on résumer? Que devrait-on retirer? C’est du vrai travail et l’agent lui-même peut en automatiser certaines parties. C’est l’une des principales raisons pour lesquelles plusieurs systèmes ont dépassé le simple prompting. Mais un harness décide quand ce contexte est chargé, quels outils sont accessibles, quelles actions sont permises, comment les échecs sont gérés et ce qui doit se produire avant que quoi que ce soit soit déclaré « terminé ».
Votre harness est l’infrastructure que vous construisez autour du modèle.
L’ingénierie du contexte peut donc s’assurer que le modèle voit le bon schéma de base de données. Le harness engineering est la raison pour laquelle il doit quand même exécuter le linter, réussir les tests, respecter les permissions et sauvegarder sa progression afin de ne pas oublier l’objectif trois tours plus tard. L’un définit ce que le modèle voit. L’autre, comment le système se comporte.
Cela explique aussi pourquoi on parle autant de divulgation progressive. Si vous versez tout le cerveau de votre entreprise dans un fichier AGENTS géant, l’agent ne devient pas plus sage. Il devient généralement pire. Plus de bruit, plus de dégradation du contexte, plus d’éléments ignorés sans avertissement. Le meilleur pattern semble être un bref plan au départ, puis des sources de vérité plus détaillées chargées seulement lorsqu’elles sont nécessaires. C’est de l’ingénierie du contexte à l’intérieur d’un harness. Le harness décide ce qu’il faut présenter et quand le faire, au lieu de traiter la fenêtre de contexte comme un dépotoir.
Maintenant, pourquoi tout cela compte-t-il au-delà des personnes qui construisent des agents de programmation toute la journée? Parce que cela commence à ressembler à la nouvelle façon de construire des logiciels. Pas complètement, pas proprement et certainement pas de façon sécuritaire par défaut. Mais la direction devient plus claire. LangChain a montré qu’en changeant seulement le harness, pas le modèle, il pouvait faire passer un agent de programmation de l’extérieur du top 30 au top 5 de Terminal Bench 2.0. Même modèle, meilleur système. Stripe aurait des agents qui produisent plus de mille pull requests fusionnées par semaine, mais dans des environnements isolés, avec des limites CI strictes et des règles d’escalade. Datadog a poussé l’idée plus loin en traitant la télémétrie de production comme une partie du harness lui-même. Si la performance régresse, ce signal est renvoyé dans la boucle. Ce n’est pas du « vibe coding ». C’est générer, valider et corriger, avec de l’observabilité.
Et cela entraîne une conséquence encore plus importante. Le travail du programmeur change. Il ne disparaît pas. Il change. Moins de temps à taper chaque ligne à la main. Plus de temps à concevoir des habitats où les agents peuvent effectuer du travail utile sans tout détruire autour d’eux. Plus de documentation lisible par les machines. Plus d’évaluations. Plus de sandboxes. Plus de limites de permissions. Plus de tests structurels. Plus de logs, de traces et de rejouabilité. Le prompting est la partie la plus facile. La fiabilité est le vrai travail.
La version honnête, par contre, est que rien de tout cela ne signifie que les agents sont réglés par magie. La mémoire échoue encore. La validation laisse encore passer certaines choses. L’utilisation d’outils crée encore des risques de sécurité. La dette de harness est réelle, parce que votre harness devient maintenant son propre produit, avec ses propres bugs et sa propre dérive. Et l’attention humaine devient la véritable ressource rare. Si les agents peuvent générer beaucoup plus d’outputs que les humains peuvent en inspecter attentivement, la rigueur doit être intégrée au système. Vous ne pouvez pas tout réviser manuellement indéfiniment. Il vous faut des vérifications auxquelles vous faites confiance. Des environnements qui échouent de façon sécuritaire. Des traces qui vous expliquent pourquoi quelque chose a mal tourné.
Lorsque les gens demandent où se dirigent les LLMs, je pense donc que la meilleure réponse est celle-ci. Ils se dirigent vers des systèmes. Vers des workflows, des agents, des runtimes et des harnesses, où une plus grande partie de la valeur provient de l’orchestration, des contraintes et des boucles de feedback que d’une capture d’écran d’un prompt sur les réseaux sociaux. Le futur sera probablement moins « un modèle génial fait tout » et davantage « des modèles travaillent dans des environnements bien conçus qui les rendent utilisables ».
Et c’est pourquoi le harness engineering compte. Ce n’est pas un nouveau nom à la mode pour le prompting. C’est ce qui apparaît lorsqu’on cesse de faire des démos d’intelligence et qu’on commence à essayer de la livrer.
Merci d’avoir lu jusqu’au bout!
FAQ
Qu’est-ce que le harness engineering pour les agents IA?
C’est le travail qui consiste à construire les contrôles autour d’un agent : outils, traces, évaluations, permissions, approbations et gestion des échecs.
Pourquoi un agent a-t-il besoin d’un harness?
Un harness vous permet d’inspecter ce que l’agent a fait, de reproduire les échecs, de limiter les actions risquées et de mesurer si les changements ont aidé.
Que se passe-t-il sans harness?
L’agent peut sembler impressionnant dans une démo, mais il devient difficile d’expliquer ou de déboguer ses échecs et de faire confiance au système en production.
Quelle est la différence entre le harness engineering et le prompt engineering?
Le prompt engineering façonne les instructions du modèle. Le harness engineering construit les outils, les évaluations, les traces, les garde-fous et les contrôles autour de l’exécution.
Comment l’ingénierie du contexte s’intègre-t-elle au harness d’un agent?
L’ingénierie du contexte sélectionne l’information mise à la disposition du modèle, tandis que le harness gère le système opérationnel plus large.
Que devrait consigner le harness d’un agent?
Il devrait conserver les traces des décisions du modèle, des appels d’outils, des outputs, des nouvelles tentatives et des échecs afin que les builders puissent comprendre comment le système a laissé l’échec se produire.