Si vous utilisez Claude Code, Codex, ou encore Cursor, vous avez déjà un harnais. Une partie est embarquée dans l'outil, l'autre est celle que vous construisez autour, souvent sans la nommer, et les deux forment un harnais. Cette partie, c'est le fichier CLAUDE.md, les conventions du projet, les serveurs MCP, les hooks qui lancent le linter, etc. Aujourd'hui, on parle de plus en plus de harness engineering.
D'ailleurs, le 13 août 2026, DeepSeek a publié DeepSeek Harness : un outil qui ne contient aucun modèle. Nous sommes le 26 août au moment où j'écris ces lignes, et le dépôt GitHub atteint presque les 200 000 étoiles. Le code source a été publié le jour même. Le principe du projet : tout est plugin, même le modèle.
Je préfère préciser que l'on ne va pas utiliser DeepSeek Harness dans ce guide (je prévois un guide dédié !), mais je l'évoque car il en dit beaucoup sur l'état du marché. Qu'est-ce qui reste stable d'un modèle à l'autre ? Le harnais.
Pourquoi un LLM seul n'est pas un agent ?
Pour résumer, un LLM c'est du texte qui entre et du texte qui sort. Entre deux appels, il n'y a pas de mémoire. Un agent, c'est un LLM qui agit dans une boucle, choisit un outil, a un contexte persistant, et le modèle décide de la suite. D'ailleurs, n'hésitez pas à aller lire notre article sur C'est quoi un agent IA ?.
Un modèle ne demande un outil qu'en produisant du texte, il n'exécute rien. Quelque chose doit lancer la vraie fonction, capturer le résultat, et le renvoyer au modèle : le harnais. C'est tout ce qui se trouve entre le modèle et le monde extérieur.
La formule que vous verrez partout : Agent = Modèle + Harnais.
D'où vient le terme harness engineering ?
Anthropic a publié Effective harnesses for long-running agents en novembre 2025. Un article sur les agents qui travaillent et perdent la mémoire. On commence à parler de harnais d'agent.
Mitchell Hashimoto (créateur de Ghostty) publie My AI Adoption Journey en février 2026. Si vous regardez bien l'étape 5, elle s'intitule Engineer the Harness. Il explique que quand un agent fait une erreur, il faut prendre le temps de construire quelque chose pour qu'il ne puisse jamais la refaire. Comme mettre à jour le fichier AGENTS.md pour corriger l'erreur.
Et quelques jours plus tard, OpenAI publie Harness engineering: leveraging Codex in an agent-first world. Les ingénieurs ne codent pas, ils conçoivent l'environnement dans lequel Codex code. Quand l'agent échoue, ils se posent la question : quelle capacité manque ?
Le 2 avril de la même année, Birgitta Böckeler parle de guides et de sensors dans l'article Harness engineering for coding agent users. On y reviendra plus tard.
Qu'est-ce qu'il y a dans un harnais ?
La question à se poser est : qu'est-ce qui vient avec l'outil ?
Les six composants que nous allons voir ne sont pas propres à Claude Code. Même si Claude Code et Codex ne sont pas la même chose, ils répondent aux mêmes questions avec des mécanismes différents. Ce qui change surtout, c'est ce qu'ils imposent et ce que vous pouvez modifier. Si je reviens sur DeepSeek Harness, cette frontière n'existe pas : la boucle, la sandbox, le modèle, etc. sont des plugins. Mais nous parlerons de DeepSeek Harness dans un article dédié.
La boucle
Récupérer le prompt, appeler le modèle, exécuter les outils demandés, renvoyer les résultats et recommencer. Elle vient avec l'outil.
Les outils
Il s'agit des petites mains de l'agent qui lui permettent de lire, écrire, lancer une commande, faire des requêtes, etc. Les outils viennent en partie de ce que vous utilisez (Claude, Codex, etc.), mais aussi de vous. Par exemple, Claude Code vient avec Read, Edit, Write et Bash, tandis que vous pouvez brancher des MCP.
La gestion du contexte
La fenêtre de contexte est limitée, et à force d'y accumuler des éléments, le raisonnement peut finir par se dégrader. Le harnais peut par exemple décider de résumer l'historique quand il devient trop long. Ce composant vient avec l'outil utilisé, mais aussi avec vous. Claude Code peut par exemple décider de compacter tout seul la conversation, et vous pouvez créer des CLAUDE.md avec vos règles ou encore des skills.
La mémoire
Le modèle n'a aucune mémoire d'une session à l'autre, mais le harnais compense ce problème de deux façons :
-
En relisant l'état de votre application
-
En reprenant une conversation précédente
Aussi, il est important d'avoir des fichiers de progression que l'agent met à jour au fur et à mesure, tout comme des fichiers avec les specs. Je vous incite fortement à aller lire notre article sur Spec Kit. Vos specs, vos décisions, vos fichiers.
Pour ma part, j'ai toujours une partie roadmaps dans mes projets, un peu à la manière de Spec Kit.
La vérification
Un autre composant très important lorsqu'on veut sécuriser et fiabiliser des projets : tests, linter, vérificateur de types, etc. Il faut que l'agent détecte les erreurs avant de livrer une fonctionnalité.
Tout ça vient de vous. Dans mes projets, à la fin de chaque fonctionnalité, mon agent doit obligatoirement implémenter des tests que ce soit avec Django ou Nuxt JS (pytest, vitest, playwright). Il doit aussi passer en revue la qualité du code avec des outils comme ruff et typecheck.
Les garde-fous et la sandbox
Ici, on parle de ce que l'agent ne peut pas faire (ou n'a pas le droit de faire). Par exemple, le type de décision quant à vider une base de données ou rejouer des migrations. À savoir que vous pouvez faire en sorte que l'agent travaille dans un environnement isolé.
Avec un même modèle, vous pouvez avoir plusieurs résultats selon le harnais mis en place, car sur six composants, cinq dépendent de vous. LangChain en apporte la preuve avec sa démonstration : son agent est passé de 52.8% à 66.5% sur Terminal-Bench 2.0 avec le même modèle et un harnais différent.
À noter
Terminal-Bench compte 89 tâches dans un environnement Docker comme compiler un noyau Linux et déboguer. Les tests vérifient l'état final du conteneur.
Quelle est la différence entre un guide et un sensor ?
Dans le processus, les guides agissent avant : nous voulons tous que l'agent fasse mouche du premier coup. Les sensors agissent après : ils détectent que l'agent s'est trompé et lui renvoient l'information pour qu'il corrige et se corrige.
Les sensors peuvent être déterministes, comme un linter (coucou ruff), ou inférentiels comme un autre LLM qui relit le code. Le premier ne se trompe pas sur ce qu'il vérifie, mais vérifie moins de choses, alors que le second vérifiera davantage d'éléments, mais peut halluciner ou ne pas voir une erreur.
À la base, j'avais prévu de voir comment se faire un harnais, et DeepSeek Harness, dans cet article, mais je me rends compte que ça va être assez dense. Alors je vais séparer ça en un article et deux guides.
Aussi, chaque composant du harnais suppose que le modèle ne sait pas faire quelque chose ou qu'il a besoin de quelque chose pour orienter son comportement. Les suppositions expirent, et un guide écrit pour rattraper une faiblesse en 2026 peut devenir obsolète, voire un frein en 2027. Je vous laisse lire la partie Iterating on the Harness de cet article.
