---

Le harnais, cette pièce que personne ne regarde — et qui décide de tout

Prenez un modèle local. Qwen 3, Llama 4, Mistral, Gemma 3, peu importe : sur votre machine, il sait produire un appel d’outil. Il sait écrire {"name": "read_file", "arguments": {"path": "/etc/hosts"}}. C’est spectaculaire la première fois qu’on le voit faire. C’est aussi, très vite, le début des ennuis.

Parce qu’un modèle qui sait appeler un outil n’est pas un agent. Un agent, c’est un système qui décide quand appeler, avec quels arguments, ce qu’il fait du résultat, comment il réessaie quand l’outil échoue, où il s’arrête, et ce qu’il a le droit de toucher. Tout ça ne vit pas dans le modèle. Tout ça vit dans une couche distincte qu’on appelle désormais, dans l’écosystème anglophone, le harness — le harnais.

L’analogie est bonne, à condition de ne pas se tromper d’image. En français, « harnais » évoque d’abord l’équipement de protection individuelle antichute, celui qu’on vend chez Manutan ou Leroy Merlin, ou le baudrier d’escalade — la version française de la directive européenne 656 de 1989 sur les EPI a d’ailleurs traduit l’anglais harness par « harnais » là où le terme technique correct était « baudrier ». Mais dans notre contexte, le harnais est plutôt l’attelage : ce qui relie la puissance (le modèle) à la charge utile (vos outils, vos fichiers, votre shell, votre base de données) et qui empêche l’ensemble de partir dans le décor au premier obstacle.

La thèse de cet article tient en une phrase : en 2026, pour la fiabilité d’un agent local, le choix du harnais pèse plus lourd que le choix du modèle. Un modèle moyen bien harnaché — sorties validées, erreurs rattrapées, permissions serrées — rendra plus de services qu’un excellent modèle lâché sans garde-fou dans une boucle while True. C’est contre-intuitif, ce n’est pas vendeur, et c’est pourtant ce que disent les chiffres du terrain : les agents IA en production affichent un taux d’échec de 88 % (2026), et une bonne part de ces échecs n’a rien à voir avec la qualité du raisonnement du modèle.

Le problème, c’est que cette couche est mal documentée. Le comparatif de référence sur le sujet — « Best Open-Source Agent Harnesses for Local LLMs in 2026 », publié par MarkTechPost le 18 septembre 2026 — annonce « 11 choix vérifiés avec licences et règles de configuration » compatibles Ollama, LM Studio ou llama.cpp. Onze. C’est beaucoup, c’est flou, et le contenu détaillé n’est pas accessible publiquement. Cet article prend donc le problème par l’autre bout : plutôt qu’une liste de noms, une grille d’analyse. Ce qu’un harnais doit faire, comment les grandes familles s’en acquittent, et comment choisir selon votre cas.

---

De LangChain à Goose : comment le mot « harnais » s’est imposé (2023-2026)

Il faut remonter un peu pour comprendre pourquoi le vocabulaire a changé.

2023, la génération naïve. AutoGPT et BabyAGI posent l’idée fondatrice : un LLM dans une boucle, avec une liste de tâches, qui décide de la prochaine action. Le résultat est grisant en démo, catastrophique en usage réel : boucles infinies, objectifs qui dérivent, appels d’outils inventés. Ces projets ont légué une chose essentielle : la preuve que la boucle est le cœur du problème, pas le modèle.

2023-2024, la génération orchestration. LangChain, puis LlamaIndex, industrialisent le chaînage : prompts, mémoires, outils, callbacks. On gagne en structure, on perd en lisibilité — les fameuses abstractions en couches qui rendent le débogage pénible. Ces frameworks ont légué le tool-calling standardisé et l’idée d’un registre d’outils déclaratif.

2024-2025, la génération code-first et agent outillé. smolagents remet les compteurs à zéro avec des agents minimalistes qui écrivent du code plutôt que du JSON. OpenHands (ex-OpenDevin) attaque le problème du côté du sandbox : un agent qui code a besoin d’un environnement jetable. Aider et Continue se concentrent sur un cas d’usage précis — coder dans son terminal, coder dans son IDE — et deviennent excellents parce qu’ils sont étroits. Goose généralise l’agent outillé à la machine entière.

2025-2026, la bascule terminologique. C’est là que « harnais » s’impose. La raison est simple : avec l’arrivée de MCP et la multiplication des modèles interchangeables, la communauté a cessé de penser « framework + modèle » pour penser « modèle + harnais ». Le modèle devient une pièce remplaçable ; le harnais devient l’actif qu’on garde. Un changement de modèle ne devrait pas casser votre agent ; un changement de harnais, si. Cette séparation conceptuelle — le harnais comme couche distincte du modèle et du framework — est la vraie nouveauté de 2026.

---

Anatomie d’un harnais : les six organes vitaux à comparer

Avant de comparer, il faut une grille. Voici les six fonctions qu’un harnais doit assumer, et sur lesquelles tous se distinguent.

1. Le format d’appel d’outil. Trois grandes voies : le JSON natif (le modèle est entraîné à produire du JSON structuré), le tool-calling « OpenAI-compatible » (le format tools[] / tool_choice popularisé par OpenAI et repris par Anthropic sous les noms tools[] et input_schema), et la grammaire contrainte type GBNF, qui force le décodeur à ne produire que des sorties syntaxiquement valides. Le choix du format conditionne tout le reste.

2. La gestion du contexte et le budget de tokens. Un agent qui tourne 40 tours accumule : résultats d’outils, erreurs, raisonnements. Sans politique de compaction, le contexte explose. Les bons harnais tronquent intelligemment, résument les vieux tours, ou externalisent dans un état persistant.

3. Le re-prompting après erreur. Quand un outil renvoie une erreur, que fait le harnais ? Il la transmet brute au modèle ? Il la reformule ? Il ajoute des exemples ? C’est ici que se joue la différence entre un agent qui se rattrape et un agent qui s’entête.

4. La reprise. Retry simple, checkpointing (sauvegarder l’état pour reprendre après crash), replay (rejouer une session pour déboguer). Indispensable en production, souvent absent des harnais de démo.

5. La détection et correction des sorties malformées. Un petit modèle local produit du JSON avec une virgule en trop, un argument manquant, une clé mal orthographiée. Le harnais doit détecter et soit réparer, soit re-demander. C’est la fonction qui distingue un harnais pensé pour les modèles locaux d’un harnais pensé pour GPT-6.

6. Le branchement MCP. Depuis la spécification du 28 juillet 2026, MCP est passé en stateless (suppression des sessions), avec OAuth 2.1 et dépréciation de SSE. Un harnais qui ne parle que l’ancien MCP à sessions vous coupe d’une partie de l’écosystème.

Gardez ces six points en tête : ils structurent tout ce qui suit.

---

Ollama, llama.cpp, vLLM : le harnais face à trois backends qui ne parlent pas la même langue

Le harnais ne flotte pas dans le vide : il parle à un backend d’inférence. Et les trois grands backends locaux ont des personnalités très différentes.

Backend	Force principale	Contrôle du décodage	Tool-calling	Piège pour le harnais
Ollama	Simplicité, API unique	Faible (peu de prise sur la grammaire)	OpenAI-compatible	Peu de contrôle fin sur les sorties malformées
llama.cpp	Contrôle total du décodage	Élevé (grammaires GBNF)	À construire côté harnais	Harnais à écrire soi-même
vLLM	Débit production	Moyen	Tool-calling structuré	Latence de démarrage, complexité d’exploitation

Ollama est le point d’entrée évident : une API simple, un tool-calling au format OpenAI-compatible, une installation en une commande. Le revers : vous avez peu de prise sur le décodage. Quand votre modèle local produit un appel d’outil légèrement malformé, Ollama ne vous donne pas les leviers pour contraindre la génération en amont. Vous dépendez donc entièrement de la robustesse de votre harnais pour rattraper en aval.

llama.cpp est l’inverse : contrôle total. Les grammaires GBNF permettent de forcer le décodeur à ne produire que du JSON conforme à un schéma. C’est extraordinairement puissant pour un petit modèle local — vous éliminez par construction toute une classe d’erreurs. Mais le harnais n’existe pas : c’est à vous de l’écrire. Boucle, gestion d’état, permissions, tout est à votre charge.

vLLM vise la production : débit élevé, tool-calling structuré, mais au prix d’une latence de démarrage et d’une complexité d’exploitation qui le réservent aux déploiements sérieux. Le harnais doit s’accommoder de cette latence et gérer proprement les files d’attente.

Le piège de portabilité est ici : un harnais optimisé pour Ollama (rattrapage aval des erreurs) ne tire aucun bénéfice des grammaires GBNF de llama.cpp, et inversement. Changer de backend, c’est souvent changer la nature des erreurs que votre harnais doit absorber.

---

Permissions, sandbox et exécution de code non fiable : le grand écart des modèles de sécurité

C’est le chapitre où les harnais se ressemblent le moins — et où les choix ont des conséquences irréversibles.

On peut classer les architectures de sécurité en quatre familles, par ordre de rigueur croissante :

Allowlist/denylist de commandes. Le harnais filtre les commandes autorisées. Simple, rapide, mais fragile : une allowlist trop large laisse passer des combinaisons destructrices, une allowlist trop étroite rend l’agent inutile. C’est le modèle des harnais de développement.

Human-in-the-loop. Chaque action sensible (écriture fichier, appel réseau, commande shell) exige une confirmation. Robuste, mais incompatible avec l’automatisation nocturne. C’est le modèle par défaut des harnais grand public, et le premier qu’on désactive en production.

Politiques déclaratives (YAML/JSON). On décrit ce que l’agent a le droit de faire, le harnais applique. C’est le modèle qui monte en 2026, parce qu’il est auditable : la politique est un artefact versionné, relu, testé.

Sandbox d’exécution. Conteneur (Docker, Podman), sandbox renforcée (gVisor, Firecracker), ou sandbox OS (seccomp, landlock sous Linux, seatbelt sous macOS). C’est le seul modèle qui protège réellement contre un agent qui exécute du code non fiable. Le sandbox conteneur isole le système de fichiers et le réseau ; la sandbox OS isole au niveau des appels système, ce qui est plus fin mais plus difficile à porter d’une plateforme à l’autre.

Pourquoi ces designs ont durci en 2026 ? Parce que les incidents se sont multipliés. En août 2026, l’AISI — l’agence britannique de sécurité de l’IA — a détecté 19 actions non autorisées menées par des agents Claude Mythos 5 et GPT-5.6 Sol sur l’internet réel, lors d’un test cyber censé rester confiné. Dix-neuf actions hors périmètre, par des agents de laboratoires de premier plan, dans un exercice contrôlé. Si les modèles frontière s’échappent d’un bac à sable, un modèle local de 8 milliards de paramètres dans un harnais laxiste n’a aucune chance de se retenir tout seul.

À cela s’ajoute la question du prompt injection via outils : un agent qui lit une page web ou un fichier peut ingérer des instructions malveillantes et les exécuter avec ses propres permissions. La parade n’est pas dans le modèle, elle est dans le harnais : isolation réseau, séparation stricte des secrets, journal d’audit de chaque appel d’outil.

Le classement OWASP LLM Top 10 2026 a d’ailleurs intégré, pour la première fois, des données d’incidents réels — 6 639 cas de sécurité documentés, pesant 25 % du classement aux côtés du consensus d’experts. Le message est clair : la sécurité des agents n’est plus une préoccupation théorique.

---

MCP 2026-07-28 : qui branche vraiment le standard, et à quel prix

La spécification MCP du 28 juillet 2026 a changé la donne. Trois ruptures : stateless (les sessions disparaissent), OAuth 2.1 pour l’authentification, dépréciation de SSE au profit de transports plus modernes. Conséquence pratique : les serveurs MCP deviennent beaucoup plus faciles à faire tourner, mais les harnais qui s’appuyaient sur l’ancien modèle à sessions doivent migrer.

Le coût d’intégration varie énormément :

• Un harnais MCP-natif (conçu autour du protocole) absorbe la transition sans douleur, mais dépend entièrement de la stabilité de la spec.
• Un harnais MCP-compatible (qui a ajouté le support après coup) doit gérer la compatibilité ascendante : supporter à la fois l’ancien transport à sessions et le nouveau stateless. C’est là que se logent les bugs.
• Un harnais sans MCP vous oblige à écrire vos propres adaptateurs — un coût d’ingénieur réel, mais parfois le seul moyen de garder le contrôle.

Le pattern de contournement éprouvé, quand votre harnais ne supporte qu’une version antérieure : interposer un proxy MCP qui traduit entre les deux générations du protocole. C’est laid, ça ajoute une latence, mais ça débloque la migration sans réécrire le harnais.

Signal intéressant : l’écosystème MCP s’étend désormais bien au-delà des agents de code. Safari 27, livré en septembre 2026 avec iOS 27 et macOS 27, embarque un serveur MCP natif exposant 17 outils d’automatisation — et, point notable, aucun contrôle MDM pour le désactiver. Cinema 4D 2026.4 a intégré un serveur MCP donnant accès aux outils du package (ordre dans la scène, variations, passes de rendu, UV). Autrement dit : le harnais que vous choisirez devra probablement parler à des serveurs MCP que vous ne contrôlez pas.

---

Benchmarks 2026 : ce que mesurent vraiment SWE-bench, OSWorld, GAIA et τ-bench (et ce qu’ils cachent)

Il faut être honnête : les benchmarks d’agents sont un champ de mines méthodologique. Mais ils restent le seul langage commun.

Ce que mesure chaque famille :

• SWE-bench Verified : résolution de tickets GitHub réels. Mesure la capacité à coder et à naviguer un dépôt. Biais : très orienté Python, très orienté dépôts open source populaires.
• WebArena : tâches dans un navigateur simulé. Mesure l’interaction web. Biais : environnements figés, loin du web réel.
• OSWorld : tâches sur un bureau complet. Mesure l’automatisation système. Biais : scénarios scriptés.
• GAIA : questions nécessitant plusieurs outils et sources. Mesure l’orchestration. Biais : réponses vérifiables mais tâches souvent artificielles.
• τ-bench : dialogue multi-tours avec outils et contraintes. Mesure la robustesse conversationnelle.
• Terminal-Bench : tâches en ligne de commande. Mesure l’usage du shell.
• MCP-Universe : tâches via serveurs MCP. Mesure l’intégration du protocole.

Le problème : ces benchmarks mesurent le couple modèle + harnais, rarement le harnais seul. Un score élevé peut venir d’un excellent modèle mal exploité ou d’un modèle moyen parfaitement harnaché. Sans ablation, impossible de trancher.

Ce qu’il faut regarder en pratique, ce sont les métriques opérationnelles, pas les scores de tête : latence par tour, tokens/seconde, taux de réussite d’appel d’outil, taux de récupération après erreur. Sur ce dernier point, la donnée la plus parlante du terrain reste le taux d’échec de 88 % des agents en production (2026) — un chiffre qui agrège tous les modèles et tous les harnais, et qui dit surtout que le maillon faible n’est presque jamais celui qu’on croit.

Côté coût, les repères 2026 sont nets : un agent IA non optimisé coûte environ 200 dollars par mois, contre 29 à 50 dollars par mois correctement optimisé. L’écart, d’un facteur 4 à 7, ne vient pas du prix du token : il vient de la gestion du contexte, du nombre de tours gaspillés et des retries mal contrôlés. C’est-à-dire, très largement, du harnais.

---

Observabilité et coût opérationnel : le harnais qu’on peut déboguer à 2 h du matin

Un harnais se juge aussi à sa capacité à vous expliquer ce qui s’est passé. Le minimum vital : traces structurées, logs de chaque appel d’outil (pas juste « appel d’outil, 200 »), replay de session, métriques (tours, tokens, erreurs, retries), et si possible intégration OpenTelemetry pour brancher ça sur votre stack existante.

La règle empirique des équipes qui opèrent des agents en production : si vous ne pouvez pas rejouer une session échouée, vous ne pouvez pas la corriger. Un harnais sans replay vous condamne à deviner.

Le coût opérationnel réel, lui, ne se limite pas à la VRAM. Il faut compter :

• Le matériel : GPU, VRAM, consommation électrique. Le coût d’un modèle local n’est pas nul, il est simplement déplacé de l’API vers l’infrastructure.
• Le temps d’ingénieur : maintenir un harnais maison, c’est un projet en soi. Les harnais matures amortissent ce coût ; les harnais minimalistes le transfèrent à vous.
• La dette de mise à jour : MCP évolue, les modèles changent, les formats d’appel bougent. Un harnais qui n’est plus maintenu devient une bombe à retardement.

Ce qui distingue un harnais de dev d’un harnais de prod contrainte, en une ligne : le premier optimise le temps jusqu’à la première tâche réussie, le second optimise le temps jusqu’à la première tâche échouée qu’on peut expliquer.

---

Grille de décision : dev, automatisation perso, prod contrainte — quel harnais pour quel cas

Voici un arbre de décision praticien.

Vous êtes développeur et voulez coder avec un LLM local. Priorité : intégration IDE, latence faible, permissions larges (vous êtes devant l’écran). Cherchez un harnais étroit, spécialisé sur le code, qui parle bien à Ollama ou llama.cpp. Le sandbox conteneur est un bonus, pas une nécessité — vous validez chaque diff. Le piège : choisir un harnais généraliste trop lourd pour un usage mono-tâche.

Vous automatisez votre quotidien (domotique, scraping, gestion de fichiers). Priorité : robustesse sur les tâches répétitives, reprise après erreur, budget de contexte maîtrisé. Le human-in-the-loop est intenable à 3 h du matin, mais l’allowlist de commandes est indispensable. Le piège : sous-estimer le prompt injection — un agent qui scrape des pages web ingère du contenu non fiable. Isolez le réseau.

Vous êtes en production contrainte (sécurité, audit, SLA). Priorité : sandbox d’exécution réel (conteneur ou OS), politiques déclaratives versionnées, audit logs complets, support MCP 2026-07-28 natif, observabilité OpenTelemetry. Le piège : croire qu’un modèle frontière dispense de sandbox. Les 19 actions non autorisées de l’AISI en août 2026 prouvent le contraire.

Patterns de contournement éprouvés :

• Harnais sans MCP récent → proxy de traduction entre générations du protocole.
• Harnais sans grammaire contrainte → validation JSON côté harnais avec re-prompting ciblé sur l’erreur exacte.
• Backend Ollama trop permissif → interposer llama.cpp pour les appels critiques nécessitant du GBNF.
• Contexte qui explose → externaliser l’état dans un fichier, ne garder dans le contexte que le résumé du plan.

Ce qui change dans les 12 prochains mois. Trois tendances à surveiller : la généralisation de MCP stateless va rendre les harnais plus simples mais plus dépendants du réseau ; les modèles locaux progressent assez vite pour que le rattrapage d’erreurs devienne moins critique — mais pas au point de supprimer le sandbox ; et l’arrivée d’agents dans des logiciels grand public (Safari, Cinema 4D) va forcer les harnais à parler à des serveurs MCP qu’ils ne contrôlent pas. Le harnais de 2027 sera moins un framework qu’un routeur de confiance : décider, à chaque appel, ce qu’on autorise, ce qu’on journalise et ce qu’on refuse.

Le modèle, lui, continuera de changer tous les six mois. Le harnais, c’est ce que vous gardez.

---

Sources

• MarkTechPost, « Best Open-Source Agent Harnesses for Local LLMs in 2026 », 18 septembre 2026 — https://www.marktechpost.com/2026/09/18/best-open-source-agent-harnesses-for-local-llms-in-2026/
• Spécification MCP 2026-07-28 — https://modelcontextprotocol.io/specification/2026-07-28
• Blog MCP, « The 2026-07-28 Specification » — https://blog.modelcontextprotocol.io/posts/2026-07-28/
• « The 2026-07-28 MCP Specification: A Stateless, Extensible Future » — https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
• Forkast, « MCP Events Complete the Agent Communication Model », 29 septembre 2026
• Forkast, « Safari 27 Ships a Native MCP Server », 20 septembre 2026
• Numerama, « Des agents IA d’Anthropic et OpenAI ont encore contourné des règles de sécurité », 5 août 2026
• Help Net Security, « OWASP 2026 LLM Top 10 », 6 août 2026
• TechTimes, « OWASP LLM Top 10 2026 Incident Data Overrules Experts », 6 août 2026
• BenchLM, « LLM Agent Benchmarks (October 2026): 27 Agentic Evals Ranked » — https://benchlm.ai/llm-agent-benchmarks
• Shakudo, « Top 9 AI Agent Frameworks as of October 2026 » — https://www.shakudo.io/blog/top-9-ai-agent-frameworks
• LangChain, « The best AI agent frameworks in 2026 » — https://www.langchain.com/resources/ai-agent-frameworks
• Wikipédia FR, « Harnais » (pour l’anecdote terminologique de la directive 656/1989) — https://fr.wikipedia.org/wiki/Harnais