Qu'est-ce que le harness engineering ? Concevoir la couche autour du LLM à l'ère des agents IA

Le harness engineering est un terme qui s'est répandu en février 2026. Le 5 février 2026, Mitchell Hashimoto (créateur du terminal Ghostty et cofondateur de HashiCorp) l'a employé pour une habitude : chaque fois qu'un agent se trompe, on construit une solution pour qu'il ne refasse jamais cette erreur. Six jours plus tard, OpenAI l'a mis dans le titre d'un compte rendu de son équipe Codex. Anthropic publiait déjà, sous le nom de « harnais », la conception des mécanismes qui entourent les agents de longue durée. Si 2025 a été l'année où l'on disait que le context engineering venait après les prompts, le harness engineering s'occupe de la couche encore plus extérieure.

Cet article expose ce qu'est réellement le harness engineering, en quoi il diffère du prompt engineering et du context engineering, les six composants qui constituent un harnais, des harnais réels publiés par OpenAI et Anthropic, une checklist de conception pratique et une comparaison des outils leaders d'aujourd'hui — les fondations dont vous avez besoin si vous voulez utiliser ou construire des agents IA sérieusement.

1. Qu'est-ce que le harness engineering ?

« Harness » désigne à l'origine l'attelage et le harnachement utilisés sur un cheval — le dispositif qui canalise la puissance de l'animal dans la direction que vous voulez. Le terme en IA fonctionne exactement comme la même métaphore : l'ensemble complet de l'équipement qui met un LLM puissant mais indiscipliné au travail productif.

Concrètement, cela inclut :

• Outils : opérations sur fichiers, recherche web, exécution de code — les moyens par lesquels le LLM peut agir.
• Gestion du contexte : la stratégie pour décider ce qui entre dans le prompt et ce qui est compressé ou écarté.
• Systèmes de mémoire : connaissances persistantes et préférences utilisateur qui survivent d'une session à l'autre.
• Boucle d'agent : le cycle percevoir → raisonner → agir → observer.
• Garde-fous : permissions, sandbox, Hooks, flux d'approbation.
• Format de sortie : markdown, JSON, citations, streaming.

Concevoir tout cela ensemble, c'est ce que nous appelons le harness engineering. Plutôt que d'entraîner ou d'améliorer le LLM lui-même, c'est l'art d'augmenter l'utilité réelle en concevant tout ce qui se trouve autour du LLM. Claude Code, Cursor, Devin, Codex CLI — ils tournent tous sur des modèles à peu près identiques, et pourtant leur comportement et leurs performances divergent fortement à cause de la différence de leur harnais.

Pour savoir où commence et où s'arrête le mot « harnais », Birgitta Böckeler, de Thoughtworks, l'a bien résumé sur martinfowler.com (2 avril 2026) : le harnais, c'est tout ce qu'il y a dans un agent sauf le modèle, autrement dit Agent = Model + Harness. Anthropic emploie le même mot pour son propre service cloud : Claude Managed Agents y est décrit comme un harnais d'agent configurable.

2. Harness engineering vs prompt engineering

Le prompt engineering n'a pas disparu — mais le périmètre est fondamentalement différent.

Si le prompt engineering est l'art de « quoi dire au LLM », le harness engineering est l'art de « quoi donner au LLM et comment l'opérer ». Les deux ne s'opposent pas — ils sont empilés en couches. Le prompt n'est qu'un composant à l'intérieur du harnais.

L'autre terme souvent confondu est le context engineering. Dans un billet du 29 septembre 2025, Anthropic l'a présenté comme le prolongement naturel du prompt engineering. Böckeler décrit la construction du harnais d'un agent de code comme une forme particulière de context engineering. Mis ensemble, ils s'emboîtent : prompt (ce qu'on dit) ⊂ contexte (ce que le modèle voit) ⊂ harnais (ce qu'on lui donne, comment son travail est vérifié et comment on l'arrête). Ce qui est propre au harnais, c'est la partie qui vérifie mécaniquement les résultats et renvoie les échecs à l'agent — les linters et les tests, par exemple.

3. Les 6 composants d'un harnais

1. Tool Use

Les moyens du LLM pour agir sur le monde : lire et écrire des fichiers, exécuter du code, faire des recherches web, appeler des API. Ratez l'interface des outils — noms, arguments, valeurs de retour — et le LLM ne pourra pas les utiliser correctement. Concrètement :

• Noms basés sur des verbes, sans ambiguïté (ex. read_file).
• Arguments obligatoires vs optionnels rendus explicites, avec des valeurs par défaut.
• Messages d'erreur structurés en cas d'échec (dire au modèle quoi faire ensuite).
• Avertissements explicites sur les opérations à effets de bord (destructrices).

2. Gestion du contexte

L'attention du LLM est finie — ce que vous lui montrez détermine ce qu'il dit. Concrètement :

• Filtrage par pertinence : ne tirer que les parties pertinentes pour la tâche, pas des fichiers entiers.
• Compaction : résumer les longues conversations pour les conserver.
• Intégration RAG : récupérer ce qui est nécessaire via la recherche vectorielle.
• Caching : réduire le coût des system prompts répétés grâce à des outils comme le prompt cache d'Anthropic.

À lire aussi : Qu'est-ce que le RAG ?

3. Système de mémoire

Conserver des connaissances d'une session à l'autre. Le CLAUDE.md de Claude Code, les .cursor/rules de Cursor et l'AGENTS.md de Codex sont autant d'exemples de mémoire de projet. Au-delà de cela :

• Mémoire à court terme : historique récent de la conversation.
• Mémoire à long terme : profil utilisateur, décisions passées.
• Connaissances factuelles : bases de connaissances spécifiques au domaine.

4. Boucle d'agent

Le cœur qui fait qu'un « agent IA » fonctionne réellement. La forme de base est le cycle percevoir → raisonner → agir → observer :

1. Recevoir l'objectif de l'utilisateur.
2. Analyser l'état courant (collecter de l'information avec des outils si besoin).
3. Planifier la prochaine action.
4. Agir via un outil.
5. Observer le résultat ; vérifier si l'objectif est atteint.
6. Boucler sinon, terminer si oui.

L'intelligence de votre agent dépend du fait d'y intégrer ou non la replanification, l'autocritique et la décomposition en sous-objectifs.

5. Garde-fous

Les mécanismes qui empêchent les comportements incontrôlés. Comme l'explique Pourquoi l'IA ignore vos règles .md, imposer un comportement par l'environnement est bien plus fiable que de demander gentiment en prose :

• Mode d'approbation : une personne confirme avant l'exécution d'opérations dangereuses (ex. les réglages de permissions de Claude Code, les modes d'approbation de Codex CLI).
• Sandbox : restreindre l'accès au système de fichiers et au réseau.
• Hooks : vérifications arbitraires avant et après les appels d'outils.
• Limitation de débit : minimiser les dégâts en cas de dérive.

6. UX de sortie

Présenter les résultats sous une forme que l'utilisateur peut comprendre et vérifier. Rendu Markdown, citations des sources, blocs de code coloration syntaxique, sortie en streaming, raisonnement visible (thinking), sortie structurée (JSON), et ainsi de suite. Produire la « bonne réponse » ne suffit pas — c'est le travail du harnais de la livrer sous une forme à laquelle l'utilisateur peut se fier et qu'il peut vérifier.

4. Pourquoi le harness engineering, pourquoi maintenant ?

Trois forces alimentent la montée d'intérêt pour le travail sur le harnais.

1. On a montré que le même modèle donne des résultats très différents selon ce qui l'entoure. Dans une expérience publiée par Anthropic le 24 mars 2026, le même modèle Claude Opus a reçu une demande d'une seule phrase : créer un éditeur de jeux rétro en 2D. Un agent seul a terminé en 20 minutes pour 9 $, mais le niveau produit n'était pas jouable. Un harnais découpé en planificateur, générateur et évaluateur a tourné 6 heures pour 200 $, et a livré un jeu où l'on pouvait réellement déplacer son personnage (la physique restait approximative). Le coût était plus de 20 fois supérieur, mais l'écart de qualité aussi. Choisir entre qualité et coût relève désormais autant du harnais que du modèle.

2. Les problèmes que les prompts seuls ne peuvent pas résoudre s'accumulent. « Trop d'outils, le modèle se trompe de choix. » « Le contexte est tellement chargé que le signal important est noyé. » « Sur des tâches longues, l'agent perd le fil à mi-chemin. » Ce ne sont pas des problèmes que vous résolvez avec une formulation plus astucieuse en un seul tour — ce sont des problèmes de design.

3. Le métier d'ingénieur lui-même a commencé à changer. L'équipe Codex d'OpenAI a raconté avoir construit un produit interne pendant cinq mois sans une seule ligne de code écrite à la main, jusqu'à environ un million de lignes et environ 1 500 pull requests (11 février 2026). Sa conclusion : le travail principal est passé de l'écriture du code à la conception d'environnements, l'expression de l'intention et la construction de boucles de rétroaction. Claude Code, Codex, Cursor, Devin et les autres grands produits se distinguent tous par la conception de ce qui entoure le modèle.

5. Exemples publiés : trois harnais réels

Le harness engineering reste vite abstrait. Voici trois exemples dont les auteurs ont publié les détails, décrits au niveau de ce qu'ils ont réellement fait.

1. L'équipe Codex d'OpenAI : AGENTS.md comme carte, règles imposées par des linters

• Ils ont limité AGENTS.md à une table des matières d'environ 100 lignes et fait d'un répertoire docs/ du dépôt la source de vérité pour la conception, les plans et les notes de qualité. Un fichier géant chassait la tâche du contexte, devenait vite obsolète et ne pouvait pas être vérifié mécaniquement.
• Pour garder la documentation à jour, des linters et la CI vérifient les liens croisés et la structure, et un agent récurrent cherche les descriptions qui ne correspondent plus au code et ouvre des PR de correction.
• Découpage en couches, sens des dépendances, logs structurés, taille maximale des fichiers, etc. sont imposés par des linters maison et des tests structurels. Les messages d'erreur indiquent comment corriger, pour que l'agent les lise et répare lui-même son travail.

2. Anthropic : concevoir le passage de relais des agents de longue durée

Quand le développement s'étale sur de nombreuses fenêtres de contexte, les agents voulaient tout construire d'un coup ou déclaraient le travail terminé à mi-chemin. Anthropic (26 novembre 2025) a répondu ainsi :

• Seule la première session lance un agent d'initialisation avec son propre prompt. Il prépare une liste de fonctionnalités (feature_list.json), un journal de progression (claude-progress.txt), un init.sh qui démarre le serveur de développement et un premier commit git.
• Chaque session suivante lit le journal de progression et le git log pour se repérer, n'implémente qu'une seule fonctionnalité et se termine par un commit et une mise à jour du journal.
• La liste de fonctionnalités est en JSON plutôt qu'en Markdown, car le modèle avait moins tendance à la réécrire à tort. Le seul champ qu'il peut modifier est celui de réussite/échec (passes).
• Une fonctionnalité n'est marquée comme terminée qu'après avoir été testée de bout en bout par automatisation du navigateur, comme le ferait un utilisateur.

3. Mitchell Hashimoto : ne jamais laisser la même erreur se reproduire

Celui qui a donné le nom travaille à plus petite échelle. Quand l'agent commet une erreur simple, il ajoute une ligne à AGENTS.md ; dans son projet de terminal Ghostty, chaque ligne de ce fichier correspond à un mauvais comportement passé, ce qui les a presque tous éliminés. Quand le texte ne suffit pas, il écrit de vrais scripts — pour prendre des captures d'écran, pour lancer des tests filtrés — et les confie à l'agent.

Le point commun des trois : le poids repose sur des mécanismes qui vérifient et renvoient le travail, plus que sur des demandes rédigées. La checklist ci-dessous aide à décider jusqu'où transformer en mécanisme.

6. Checklist pratique de conception d'un harnais

7. Comparatif des principaux harnais

Chacun de ces harnais tourne sur plus ou moins les mêmes LLM (Claude / GPT / Gemini), et pourtant leurs forces divergent fortement à cause des philosophies de conception du harnais. « Quel harnais ? » compte plus que « quel LLM ? » — c'est le vrai terrain de bataille de l'ère des agents.

8. Anti-patterns

1. Ajouter trop d'outils

Plus on ajoute d'outils, plus le LLM risque de choisir le mauvais. La documentation d'Anthropic indique que la précision de Claude dans le choix des outils se dégrade au-delà de 30 à 50 outils disponibles, et propose la recherche d'outils pour ne charger que les outils utiles au besoin. Son guide sur l'écriture d'outils rappelle aussi que plus d'outils ne veut pas dire de meilleurs résultats : plutôt que d'envelopper chaque endpoint d'API, regroupez les fonctions similaires.

2. Tout entasser dans le contexte

« Montrons-lui tout, par sécurité » est contre-productif. Faites passer les choses par un filtre de pertinence et n'incluez que le nécessaire. Le contexte est un dispositif pour faire émerger le signal important — pas un placard de rangement.

3. Implémenter la sécurité avec des prompts seuls

« Merci de ne pas effectuer d'opérations dangereuses » sera ignoré tôt ou tard, selon la situation. La bonne réponse est de rendre cela physiquement impossible au niveau de l'environnement — sandbox, Hooks, limites de permissions.

4. Ne jamais revoir ce qu'on a ajouté

Chaque pièce ajoutée rend le harnais plus lourd, plus lent et plus cher. Après l'expérience citée plus haut, Anthropic a retiré les composants un par un en comparant les résultats, et n'a gardé que ce qui aidait encore (le planificateur et l'évaluateur). Son constat : chaque composant d'un harnais encode une hypothèse sur ce que le modèle ne sait pas faire seul, et ces hypothèses se périment vite à mesure que les modèles progressent. Quand vous changez de modèle, vérifiez un par un si chaque contrôle et chaque découpage ajoutés servent encore.

Synthèse

Le harness engineering est l'art de concevoir la couche « extérieure » au LLM. Le prompt engineering n'est qu'un composant à l'intérieur du harnais. Traiter délibérément les six éléments — définition des outils, gestion du contexte, mémoire, boucle, garde-fous, UX de sortie — peut transformer les performances réelles à partir d'un même LLM sous-jacent.

En 2026, le principal terrain de bataille des agents IA en production a clairement basculé vers le harnais. Construire des « harnais intelligents » — pas seulement écrire des « prompts intelligents » — sera le facteur de différenciation pour la prochaine génération d'ingénieurs.

FAQ

Q1. Donc on n'a plus besoin du prompt engineering ?

Faux. Il reste essentiel — comme un composant à l'intérieur du harnais. Descriptions d'outils, system prompts, messages d'erreur — toutes ces surfaces sont des surfaces de design de prompt. Ce qui est dépassé, c'est la mentalité « je vais régler ça avec un meilleur prompt ».

Q2. Quelle est la première étape pour apprendre le harness engineering ?

Prenez Claude Code ou Cursor et ne vous contentez pas de l'utiliser — modifiez son comportement en ajustant sa configuration. Transformée en étapes, la méthode de Hashimoto donne ceci :

1. Notez chaque échec de l'agent (avec quelle instruction, et ce qui a mal tourné).
2. Pour les échecs simples, ajoutez une ligne à CLAUDE.md / AGENTS.md / .cursor/rules.
3. Les échecs qui se répètent, ou qui feraient des dégâts, bloquez-les mécaniquement avec des Hooks, des linters ou des tests — et écrivez la correction dans le message d'erreur.
4. Redonnez la même tâche à l'agent et vérifiez que l'échec a disparu.

Q3. Les harnais, c'est la même chose que des frameworks comme LangChain ?

Proche, mais pas pareil. Un framework est une boîte à outils d'implémentation ; un harnais est une discipline de conception et un état d'esprit. LangChain, LlamaIndex, le Claude Agent SDK et leurs semblables sont des outils pour construire des harnais.

Q4. Construire son propre harnais ou utiliser un existant ?

Dans la plupart des cas, un harnais existant (Claude Code, Cursor, etc.) plus de la personnalisation suffit. Construire de zéro n'a de sens que pour des exigences entreprise, des domaines de niche ou une optimisation des coûts extrême.

Q5. « Harness engineer » deviendra-t-il un véritable intitulé de poste ?

Il n'existe pas encore d'intitulé de poste établi. Hashimoto lui-même a écrit qu'il ne savait pas si un terme reconnu par le secteur existait. Mais l'équipe Codex d'OpenAI rapporte que le travail principal de l'ingénieur est passé à concevoir des environnements, exprimer l'intention et construire des boucles de rétroaction : le contenu du métier change avant que l'intitulé ne se fixe.