Le harnais d'agent : pourquoi tout sauf le modèle compte

État des lieux au mois d’août 2026.

Vous avez construit un chatbot. Vous avez peut-être câblé une boucle ReAct avec quelques outils. Cela fonctionne pour les démos. Puis vous essayez de construire quelque chose de niveau production, et tout s’effondre : le modèle oublie ce qu’il a fait il y a trois étapes, les appels d’outils échouent silencieusement, et les fenêtres de contexte se remplissent de bruit.

Le problème ne vient pas de votre modèle. Il vient de tout ce qui entoure votre modèle.

Le harnais n’est pas le modèle

Le terme de harnais d’agent (agent harness) a été officialisé au début de l’année 2026, mais le concept existait bien avant. Le harnais est l’infrastructure logicielle complète qui enveloppe un LLM : boucle d’orchestration, outils, mémoire, gestion du contexte, persistance de l’état, gestion des erreurs et garde-fous. La documentation de Claude Code le formule simplement : le SDK est « le harnais d’agent qui propulse Claude Code ». L’équipe Codex d’OpenAI utilise le même cadre, en assimilant explicitement les termes « agent » et « harnais » pour désigner l’infrastructure non-modèle qui rend le LLM utile.

La distinction qui induit souvent en erreur est la suivante. L’agent est le comportement émergent : l’entité orientée vers un objectif, utilisant des outils et capable de s’auto-corriger avec laquelle l’utilisateur interagit. Le harnais est la machinerie qui produit ce comportement. Lorsque quelqu’un dit « j’ai construit un agent », il veut dire qu’il a construit un harnais et l’a pointé vers un modèle.

D’où la formule devenue canonique : « Si vous n’êtes pas le modèle, vous êtes le harnais. »

La preuve par les chiffres

L’importance du harnais n’est pas une opinion, elle se mesure. LangChain a modifié uniquement l’infrastructure enveloppant son LLM — même modèle, mêmes poids — et est passé de hors du top 30 à la 5e place sur TerminalBench 2.0. Un projet de recherche indépendant a atteint un taux de réussite de 76,4 % en demandant à un LLM d’optimiser l’infrastructure elle-même, surpassant des systèmes conçus à la main.

Le message est clair : à modèle égal, c’est l’enveloppe qui détermine la performance réelle.

Un processeur sans RAM, sans disque et sans I/O

Beren Millidge a rendu cette idée précise dès 2023 en décrivant les Scaffolded LLMs as Natural Language Computers (les LLM échafaudés comme des ordinateurs en langage naturel). Un LLM brut est un processeur nu. La fenêtre de contexte sert de RAM : rapide, mais limitée et volatile. Les bases de données externes fonctionnent comme un stockage disque : vaste, mais lent. Les intégrations d’outils agissent comme des pilotes de périphériques. Et le harnais est le système d’exploitation.

L’analogie va plus loin : l’architecture classique de Von Neumann — une unité de traitement, une mémoire, des périphériques d’entrée/sortie, coordonnées par un noyau — se retrouve presque à l’identique dans un agent moderne :

• Couche d’interaction : le modèle (CPU/GPU)
• Mémoire & disque : fenêtre de contexte et stockage persistant (bases locales, fichiers de projet)
• Pilotes de périphériques : outils et connecteurs MCP (Model Context Protocol)
• Noyau : la boucle d’orchestration et le gestionnaire d’événements

Nous avons collectivement réinventé l’architecture de Von Neumann, parce que c’est l’abstraction naturelle de tout système informatique — y compris ceux qui raisonnent en langage naturel.

Les trois niveaux d’ingénierie

Trois niveaux concentriques entourent le modèle, et il est crucial de ne pas les confondre :

1. L’ingénierie du prompt élabore les instructions reçues par le modèle.
2. L’ingénierie du contexte gère ce que le modèle voit, et à quel moment.
3. L’ingénierie du harnais englobe les deux précédents, plus toute l’infrastructure applicative : orchestration des outils, persistance de l’état, récupération après erreur, boucles de vérification, application de la sécurité et gestion du cycle de vie.

Le harnais n’est donc pas un simple emballage autour d’un prompt. C’est le système complet qui rend possible le comportement autonome d’un agent.

Les sept décisions qui définissent chaque harnais

Tout harnais se résume à sept choix d’architecture, chacun étant un compromis :

1. Agent unique vs multi-agent : maximiser d’abord un agent unique. Ne diviser qu’en cas de surcharge d’outils (au-delà d’une dizaine).
2. ReAct vs plan-and-execute : ReAct entrelace raisonnement et action (flexible, mais coûteux), tandis qu’une phase de planification séparée accélère l’exécution.
3. Stratégie de gestion de la fenêtre de contexte : compaction, masquage, notes structurées ou délégation.
4. Conception de la boucle de vérification : vérification informatique (tests, linters) ou inférentielle (LLM-juge).
5. Architecture de permission et de sécurité : permissive (rapide mais risquée) ou restrictive (sûre mais lente).
6. Stratégie de ciblage des outils : moins d’outils actifs améliore souvent les performances du modèle (chargement paresseux).
7. Épaisseur du harnais : quelle part de la logique vit dans le code du harnais, plutôt que dans le modèle brut.

Ces sept décisions ne sont pas des détails d’implémentation : ce sont elles qui distinguent un jouet de démonstration d’un système qui tient la charge en production. La suite de cette analyse détaille les douze composants concrets qui matérialisent ces choix.