Pendant deux ans, tout tournait autour du modèle. Lequel était le plus intelligent, lequel écrivait le code le plus propre, lequel dominait le benchmark ce mois-ci. Cette conversation s'est éteinte en silence. En 2026, les modèles de pointe ont convergé : confiez la même tâche difficile aux modèles leaders, et l'écart entre eux est faible, et il se réduit encore. Si ce n'est donc plus le modèle qui fait la différence, qu'est-ce qui la fait ?
La réponse, c'est tout ce qui se trouve autour du modèle : la boucle qui le maintient au travail, les outils qu'il peut saisir, la mémoire qu'il transporte d'une session à l'autre, les règles qu'il ne peut pas enfreindre. Cette enveloppe a désormais un nom, le harness, et apprendre à bien la construire est devenu la compétence IA la plus précieuse de l'année.
C'est le premier article d'une série en cinq parties sur les agentic harnesses. Nous y définissons ce qu'est réellement un harness, parcourons les quatre parties que partage tout harness, et expliquons pourquoi un simple billet de blog d'un cofondateur de HashiCorp a transformé le "harness engineering" en discipline à part entière. Les articles suivants approfondissent chaque partie tour à tour.
Du distributeur automatique à l'atelier
La plupart des gens utilisent encore l'IA comme un distributeur automatique : on tape une requête, on obtient une réponse, c'est terminé. Cela fonctionne pour une question d'une ligne. Cela s'effondre dès que la tâche s'étale sur plusieurs étapes, plusieurs fichiers ou plusieurs heures, c'est-à-dire sur la plupart du travail réel.
Un harness change la forme de l'interaction. Au lieu d'un unique aller-retour, le modèle s'installe dans un système qui le laisse agir : exécuter une commande, lire le résultat, décider de la suite, recommencer, tout en restant orienté vers un objectif que vous avez défini en amont. Le modèle fournit l'intelligence ; le harness fournit la structure qui transforme l'intelligence en travail abouti.
Une définition limpide, tirée de l'analyse du modèle par LangChain :
Un agent harness, c'est tout morceau de code, de configuration et de logique d'exécution qui n'est pas le modèle lui-même.
Le modèle est le moteur ; le harness est la voiture construite autour, avec ses roues, sa direction et ses freins. Un moteur brillant boulonné à rien ne va nulle part.
Trois couches : Prompt, Context, Harness
Il est utile de voir où se situe le harness par rapport à des notions que vous connaissez déjà.
- Le prompt engineering concerne les mots que vous envoyez dans un seul message : la formulation, les exemples, la forme de la requête.
- Le context engineering concerne ce qui se trouve dans la fenêtre du modèle au moment où il agit : les fichiers, l'historique, les extraits récupérés, les instructions système.
- Le harness engineering concerne tout ce qui est en dehors d'une seule fenêtre de contexte : la manière dont le travail circule à travers de nombreuses fenêtres, dont l'état est transmis, dont on borne les actions possibles.
Chaque couche enveloppe la précédente - une portée de contrôle plus large autour d'une plus étroite :
Le terme "harness engineering" a été forgé par Mitchell Hashimoto, cofondateur de HashiCorp et créateur de Terraform, dans un billet largement partagé en février 2026. Il y décrivait une habitude prise en travaillant avec des agents de code : chaque fois qu'un agent faisait une erreur, il ne se contentait pas de la corriger sur le moment : il intégrait un correctif permanent dans l'environnement de l'agent, pour que cette erreur ne puisse plus jamais se reproduire.
Chaque fois qu'un agent fait une erreur, vous concevez une solution pour qu'il ne la refasse plus jamais.
Ce seul basculement est le cœur de la discipline : traiter l'environnement comme la chose que l'on améliore, plutôt que de se réexpliquer à chaque session. Votre harness devient le registre de chaque leçon apprise, et cela se cumule.
Les quatre parties que possède tout harness
Déshabillez n'importe quel harness et vous retrouvez les mêmes quatre parties. Elles sont nécessaires et, ensemble, suffisantes. Maîtrisez les quatre et vous obtenez un système capable d'accomplir un vrai travail en plusieurs étapes, de façon fiable.
1. La boucle d'agent (Agent Loop)
Le cœur qui bat : une boucle où le modèle raisonne, exécute une action via un outil, observe le résultat et recommence jusqu'à ce que l'objectif soit atteint. C'est la partie "agentique". Sans la boucle, vous avez un chatbot ; avec elle, vous avez quelque chose capable de poursuivre un objectif sur des dizaines d'étapes. Décider quand continuer, quand s'arrêter et comment se remettre d'un faux pas : c'est là que se loge une grande part du savoir-faire d'un harness.
2. L'interface d'outils
Seul, un modèle ne peut produire que du texte. Les outils sont le moyen par lequel ce texte devient action : lire un fichier, lancer des tests, interroger une base de données, naviguer sur le web. Les harnesses les plus puissants ne tendent pas au modèle un menu figé d'outils préfabriqués ; ils lui donnent un accès généraliste à un shell et à un environnement d'exécution de code, afin qu'il assemble à la volée l'outil dont il a besoin. L'origine de ces outils, qu'il s'agisse de serveurs MCP, de commandes CLI ou d'exécution de code en sandbox, est une décision de conception aux conséquences bien réelles en coût et en sécurité.
3. La gestion du contexte
Une fenêtre de contexte est finie, et les tâches longues la font déborder vite. La gestion du contexte est l'ensemble des techniques qui maintiennent malgré tout le modèle au travail de façon cohérente : résumer et compacter l'historique, déporter les sorties d'outils volumineuses vers le système de fichiers, réinitialiser entièrement la fenêtre et transmettre l'état à une nouvelle session via un artefact structuré. C'est ici que se décide la différence entre une démo jouet et un système qui tourne pendant des heures.
4. Les mécanismes de contrôle
Laissé à lui-même, un agent déclarera avec aplomb qu'un travail médiocre est terminé. Les mécanismes de contrôle le maintiennent honnête : des étapes de planification avant d'agir, un agent évaluateur séparé qui note le travail avec scepticisme, des seuils de qualité stricts qui déclenchent une reprise, un historique git qui permet de revenir en arrière, et des garde-fous au niveau des outils qui rendent les actions dangereuses purement impossibles plutôt que simplement déconseillées. Ici, la vérification n'est pas un simple agrément : elle est porteuse.
Pourquoi cela compte au-delà de la démo
Le propre compte rendu d'Anthropic sur les agents de longue durée contient un exemple frappant. Le même objectif, construire un petit jeu jouable doté de fonctions IA, a été confié à un agent unique nu puis à un harness complet. L'agent nu a produit en vingt minutes quelque chose de non fonctionnel. La variante avec harness a pris six heures et a produit une application opérationnelle qui se jouait réellement. Le harness coûtait bien sûr plus cher à faire tourner, mais il a finalement été le seul à livrer un résultat exploitable.
Une seule comparaison suffit à poser l'argument économique. Quand la qualité brute du modèle cesse d'être un fossé défensif, le fossé devient la qualité avec laquelle vous emballez le modèle : les boucles, les outils, la mémoire et les garde-fous qui transforment un modèle capable en une collègue fiable. Cette enveloppe est constructible, appropriable, et propre à la façon de travailler de votre équipe. C'est là que se trouve désormais le levier.
Comment nous voyons les choses chez vensas
Nous ne traitons pas les harnesses comme une curiosité de recherche. Les mêmes réflexes traversent notre quotidien de développement logiciel assisté par l'IA : des garde-fous au niveau des outils qui rendent la mauvaise action impossible, des conventions de projet dans le AGENTS.md qui accompagnent chaque session, des skills réutilisables pour ce que nous faisons de façon répétée, et des boucles de vérification qui contrôlent la qualité au lieu de la présumer. Une bonne partie de ce que nous avons déjà écrit - sur la spec, le verifier et l'environment, sur les agents de code auto-hébergés, sur les git worktrees pour les workflows IA - se révèle être du harness engineering sous un autre nom. Cette série met un cadre autour de tout cela.
Conclusion
Le modèle a cessé d'être la variable intéressante. Ce qui sépare une démo tape-à-l'œil d'un logiciel qui livre vraiment, c'est le système construit autour du modèle : le harness. Il a quatre parties : une boucle qui le maintient au travail, des outils qui le laissent agir, une gestion du contexte qui le garde cohérent, et des contrôles qui le gardent honnête. Maîtrisez ces quatre-là, traitez votre environnement comme ce que vous améliorez durablement, et vous cesserez de vous réexpliquer à l'IA chaque matin pour commencer à vous cumuler.