Electrosens R&D
Electrosens LLM auto hébergées · 29 October 2026

Harnais d’agents pour LLM locaux : la couche qui décide si votre IA à domicile est un jouet ou un collègue (édition 2026)

En 2026, faire tourner un modèle open weight chez soi n’a plus rien d’extraordinaire. Ce qui sépare encore un simple générateur de texte d’un véritable assistant capable d’agir, c’est une couche logicielle discrète mais décisive : le harnais. Tour d’horizon d’un écosystème qui se consolide vite — entre ouverture réelle, ouverture de façade, benchmarks fragiles et premiers classements sérieux.


Le harnais, ce chaînon manquant entre votre GPU et un vrai assistant

Il y a encore deux ans, l’exploit consistait à faire tenir un modèle de plusieurs milliards de paramètres dans la mémoire d’une carte graphique grand public. Aujourd’hui, cette prouesse est devenue routine : les formats quantifiés (GGUF, AWQ, EXL3, FP8), les moteurs d’inférence optimisés comme llama.cpp et les mini-PC à mémoire unifiée — jusqu’à 128 Go sur un Ryzen AI Halo, 192 Go sur un Gorgon Halo — ont banalisé l’IA locale. Mais une fois le modèle chargé, une question gênante demeure : que fait-il, au juste ? Un LLM seul produit du texte. Il ne lit pas vos fichiers, ne lance pas une commande, ne consulte pas le web, ne se souvient pas de ce qu’il a fait hier. Pour transformer ce moteur de prédiction en assistant, il faut une couche logicielle qui orchestre tout le reste — et c’est précisément ce qu’on appelle désormais un harnais d’agent (agent harness).

La distinction mérite d’être posée clairement, car trois familles d’outils sont souvent confondues. Le client de chat (une interface graphique type LM Studio ou Jan) affiche la conversation et gère le chargement du modèle, mais ne sait rien faire d’autre. Le serveur d’inférence (llama.cpp, Ollama, vLLM) expose le modèle via une API et optimise le débit, sans aucune notion d’outil ni de mémoire. Le framework d’orchestration générique (LangChain, LlamaIndex) fournit des briques abstraites pour construire des chaînes d’appels, mais reste un kit de construction, pas un agent opérationnel clé en main. Le harnais, lui, est le produit fini : la boucle qui décide quoi faire, appelle les bons outils, garde la trace de ce qui s’est passé et applique des règles de sécurité.

Cette couche est devenue le nouveau champ de bataille de l’IA personnelle pour une raison simple : à modèle égal, c’est elle qui détermine si votre agent est un jouet ou un collègue. Et un classement publié le 18 septembre 2026 vient enfin donner un cadre à cette intuition.

Anatomie d’un harnais : les sept pièces qui transforment un modèle en agent

Décomposons la mécanique. Un harnais digne de ce nom assemble sept composants canoniques, chacun répondant à un problème précis.

Classement MarkTechPost (18 sept. 2026) — harnais open source pour LLM locauxOpenCode1rangPi2rangGoose (Block)3rang

La boucle d’agent est le cœur battant. Elle suit un cycle perception → plan → action → observation, répété jusqu’à ce que la tâche soit accomplie. C’est la définition standard que l’on retrouve partout : un agent, c’est un LLM plus des outils plus une boucle « observer → raisonner → agir → observer → répéter ». Sans cette boucle, vous avez un chatbot ; avec elle, vous avez un exécutant.

Le registre d’outils et les appels de fonctions constituent la boîte à outils : lecture de fichiers, requêtes HTTP, exécution de commandes shell, recherche web. Le modèle ne « fait » rien lui-même — il émet une intention d’appel que le harnais traduit en action réelle. La qualité de cette traduction (validation des arguments, gestion des erreurs, formatage des résultats) fait une différence énorme sur la fiabilité finale. C’est aussi là que se joue un arbitrage contre-intuitif : Pi, deuxième du classement MarkTechPost, ne propose que quatre outils natifs (read, write, edit, bash) précisément pour laisser un maximum de contexte au code.

La gestion du contexte et de la mémoire répond à une contrainte physique : la fenêtre de contexte est finie, mais une tâche longue génère des dizaines de milliers de tokens d’historique. Les harnais matures combinent plusieurs stratégies — RAG pour retrouver des informations pertinentes, résumé progressif pour comprimer l’historique, mémoire persistante pour survivre entre deux sessions. Le projet Memori de GibsonAI, présenté en novembre 2025 comme un moteur de mémoire open source, illustre cette spécialisation croissante.

Le sandboxing d’exécution de code isole les actions risquées. C’est ici que Google donne l’exemple le plus abouti : selon sa documentation officielle, un appel d’API Gemini provisionne un bac à sable Linux isolé au niveau OS dans lequel l’agent raisonne, exécute du code, gère des fichiers et navigue sur le Web. L’absence de ce composant est d’ailleurs le principal reproche fait à Pi : sans système de permission intégré, il faut isoler l’exécution via Docker, une micro-VM ou un sandbox.

Le système de permissions décide de ce que l’agent a le droit de toucher. Le planificateur décompose les objectifs complexes en étapes. La journalisation et la traçabilité permettent de comprendre a posteriori pourquoi l’agent a fait ce qu’il a fait — indispensable pour déboguer et auditer.

Un encadré s’impose ici sur les taxonomies concurrentes. Le blog Agentland.fr propose une décomposition en six piliers : substrat de raisonnement (le modèle), mémoire, constructeur de contexte, routage de compétences, boucle d’orchestration et couche de vérification. Google, de son côté, raisonne implicitement en quatre blocs : sandbox, réseau, outils et identifiants. Les deux grilles se recoupent mais divergent sur l’accent — Agentland insiste sur la vérification et le routage, Google sur l’isolation et la gestion des secrets. Aucune des deux n’est canonique : le domaine manque encore de vocabulaire stabilisé.

De ReAct à OpenCode : petite histoire d’une couche devenue essentielle

L’idée d’un agent LLM n’est pas née en 2026. Elle remonte aux travaux ReAct de 2022, qui ont formalisé l’alternance raisonnement/action, puis à l’explosion de AutoGPT et BabyAGI en 2023. BabyAGI, créé par Yohei Nakajima sous licence MIT, incarnait alors la promesse : une boucle simple « créer → prioriser → exécuter » qui semblait annoncer des agents autonomes partout. La désillusion fut rapide — le script original est d’ailleurs archivé depuis septembre 2024 dans un dossier babyagi_archive, le dépôt principal actuel étant une reconstruction 2024 nommée « functionz ». Détail révélateur : selon les analyses disponibles, BabyAGI n’a aucun support natif documenté pour les modèles locaux ; toutes ses versions nécessitent une clé API OpenAI.

Le tournant local, lui, s’est joué en 2025-2026. C’est à ce moment qu’émerge une couche explicitement dédiée aux modèles tournant sur votre propre machine. Le terme « harnais » s’est imposé dans le vocabulaire — Agentland.fr situe son émergence au « début de l’année » 2026, « notamment sous la plume de Vivek Trivedy chez LangChain », avant une théorisation par une publication de l’université de Berkeley référencée arXiv:2605.26112. Prudence toutefois : cette attribution repose sur une seule source tierce, et l’identifiant arXiv (2605 = mai 2026) est plausible mais non confirmé. Aucune source primaire ne date ni n’attribue formellement l’invention du terme.

Ce qui est en revanche confirmé, c’est l’adoption officielle par Google : sa documentation de l’API Gemini écrit noir sur blanc que « les agents gérés de l’API Gemini vous offrent un harnais d’agent configurable ». Quand un géant du cloud reprend un terme dans sa doc publique, c’est que la catégorie a conquis sa légitimité. Agentland.fr situe au printemps 2026 la prise de conscience que « le harnais compte plus que la taille du modèle » — une affirmation non vérifiée, mais qui résume bien l’air du temps.

Et la consolidation s’accélère. Le 18 septembre 2026, MarkTechPost publie le premier classement sérieux de onze « harnesses » open source pour LLM locaux, en s’appuyant sur une lecture directe des dépôts GitHub. Quatre critères y sont pesés : licence approuvée OSI, runtimes locaux documentés, maintenance active et contrôles de sécurité. OpenCode arrive en tête, avec trois voies locales documentées (Ollama, LM Studio, llama-server), plus de 75 fournisseurs revendiqués et deux agents intégrés, build et plan. Pi (second) et Goose de Block (troisième) complètent le podium — nous y revenons plus bas. Le paysage bouge même sur le plan capitalistique : Pi, publié à l’origine sous badlogic/pi-mono, a été racheté par Earendil en avril 2026, son créateur Mario Zechner rejoignant l’entreprise.

Ouverture réelle ou ouverture de façade : le grand tri des harnais

C’est ici que le panorama devient inconfortable. L’écosystème se divise en trois cercles, et la frontière entre eux n’est pas toujours celle qu’on croit.

Source : ai.google.dev

Le cercle communautaire. On y trouve des projets comme OpenClaw, décrit comme un harnais d’agents open source pour LLM locaux, avec des variantes comme OpenClaw Guild (serveur multi-utilisateurs avec RBAC, isolation par agent, mémoire à quatre niveaux, dashboard web et déploiement Docker-compose). À côté, OpenHands (anciennement OpenDevin), Aider, Cline, Continue, Goose, SWE-agent, Devika, Open Interpreter, Khoj, Letta/MemGPT, AutoGen, CrewAI et smolagents de Hugging Face complètent le paysage. Loom se présente comme un harnais d’exécution local avec environ 50 outils, un système de plugins, une CLI et un serveur MCP, « prêt pour modèles locaux ». Smriti pousse la logique plus loin : un outil « type Git » pour sauvegarder, restaurer, brancher et comparer les états de raisonnement d’un LLM.

Le classement MarkTechPost apporte ici des précisions bienvenues. Goose documente le plus grand nombre de runtimes locaux — Ollama, LM Studio, Docker Model Runner, Ramalama, Atomic Chat, vLLM et KServe — avec plus de 70 extensions MCP, ce qui en fait l’option la plus polyvalente au-delà du simple code. Pi, à l’inverse, joue la sobriété : quatre outils natifs seulement, et pas de système de permission intégré (d’où la nécessité d’isoler l’exécution). OpenCode cumule, lui, trois voies locales documentées et deux agents intégrés.

Le cercle des éditeurs partiellement ouverts. C’est le plus ambigu. Le cas d’école est Kiro Crew d’AWS : le projet est open source, mais le harnais reste fermé. Vous pouvez lire le client, pas la mécanique qui décide. Même schéma chez Claude Code, Cursor ou Windsurf : des produits excellents, mais dont la couche d’orchestration n’est ni auditable ni modifiable. C’est ce qu’on appelle l’open washing — ouvrir assez pour séduire les développeurs, fermer assez pour garder le contrôle. Un signal récent nuance toutefois le tableau côté AWS : le 21 septembre 2026, AWS Strands Agents a publié Strands Harness en open source, avec à la clé un coût en tokens réduit. Preuve que même les grands éditeurs commencent à ouvrir la mécanique, pas seulement le client.

Le cercle local-first. Jan, LM Studio (avec appels d’outils), GPT4All et Msty visent l’inverse : tout faire tourner chez vous. Mais attention — être local-first ne signifie pas que le harnais est ouvert. Un client peut être gratuit, hors ligne et pourtant garder sa boucle d’agent propriétaire.

Le problème de fond, c’est que presque aucune donnée précise n’est disponible sur les licences exactes, les langages, les dates de première release, les mainteneurs ou les nombres de contributeurs de la plupart de ces projets. Les sources disponibles sont majoritairement des blogs tiers, sans confirmation indépendante — le classement MarkTechPost, s’il apporte une méthodologie claire (licence OSI, runtimes documentés, maintenance, sécurité), reste lui-même une synthèse de lecture de dépôts. Un signal mérite néanmoins d’être noté : Mozilla a annoncé Thunderbolt, un client IA d’entreprise open source sous licence MPL 2 — une licence réellement ouverte, à recouper avec une source Mozilla officielle.

Catégorie Exemples Harnais auditable ? Support local (Ollama/llama.cpp/vLLM) Signal d’alerte
Communautaire OpenCode, Pi, Goose, OpenClaw, OpenHands, Aider, Cline, Loom, Smriti Oui (par nature) Souvent oui ; documenté chez OpenCode (Ollama, LM Studio, llama-server) et Goose (7 runtimes) Métadonnées projet rares
Éditeur partiellement ouvert Kiro Crew (AWS), Claude Code, Cursor, Windsurf Non — client ouvert, harnais fermé Variable, non précisé « Open washing » ; AWS ouvre la voie avec Strands Harness (sept. 2026)
Local-first Jan, LM Studio, GPT4All, Msty Client ouvert, boucle propriétaire Oui Local ≠ harnais ouvert
Licence explicitement ouverte Thunderbolt (Mozilla, MPL 2) À confirmer Non précisé —

Les trois réglages qui font échouer (ou réussir) un harnais local

Le classement MarkTechPost a le mérite de sortir du brouillard théorique : il identifie trois réglages qui reviennent partout, et qui expliquent pourquoi un même harnais peut sembler brillant chez l’un et catastrophique chez l’autre.

Premier réglage : la fenêtre de contexte. Il faut la porter à au moins 64 000 tokens. Or Ollama fixe par défaut 4 000 tokens sous 24 Gio de VRAM, 32 000 entre 24 et 48 Gio, et 256 000 au-delà. Autrement dit, un utilisateur qui lance un harnais sur un petit GPU sans toucher à ce réglage travaille avec un contexte dix à quinze fois trop court — et s’étonne que son agent « oublie » tout. C’est le piège numéro un de l’IA locale, et il n’a rien à voir avec la qualité du modèle.

Deuxième réglage : la compatibilité avec l’appel d’outils. Choisir un modèle qui sait réellement émettre des appels de fonctions structurés. Un modèle brillant en chat mais incapable de produire un JSON d’appel d’outil valide rendra n’importe quel harnais inutilisable.

Troisième réglage : la calibration mémoire. Comptez de 16 à 32 Go de RAM pour de petits modèles quantifiés, 64 Go et plus pour les plus gros. Concrètement, Gemma 4 nécessite environ 16 Go de VRAM et Qwen 3.6 environ 24 Go. C’est ici que les mini-PC à mémoire unifiée changent la donne : là où une RTX 3090 plafonne à 24 Go, un Ryzen AI Halo à 128 Go ouvre la porte aux modèles 120B+, et un Gorgon Halo à 192 Go à ceux de 200B+.

Ces trois réglages expliquent une asymétrie fondamentale : le harnais pèse davantage avec un modèle local qu’avec une API cloud. Fenêtres de contexte réduites et appel d’outils moins fiable font remonter chaque défaut de conception, et déterminent si l’agent fonctionne tout court. Sur une API frontier, le harnais peut se permettre d’être médiocre ; en local, il doit être excellent.

Ce que mesurent vraiment les benchmarks d’agents (et ce qu’ils cachent)

Comment savoir si un harnais est bon ? La réponse honnête : c’est difficile, et les chiffres qui circulent sont souvent fragiles.

Source : agentland.fr

Les benchmarks pertinents existent pourtant. SWE-bench et sa variante SWE-bench Verified mesurent la capacité à résoudre des tickets logiciels réels. GAIA évalue le raisonnement multi-étapes et l’usage d’outils sur des tâches du monde réel. AgentBench teste la polyvalence sur plusieurs environnements. WebArena et OSWorld évaluent respectivement la navigation web et le contrôle d’un système d’exploitation. τ-bench (tau-bench) se concentre sur les interactions avec des outils et des utilisateurs simulés. Terminal-Bench mesure l’exécution de commandes en terminal. BFCL (Berkeley Function Calling Leaderboard) note spécifiquement les appels de fonctions. MLE-bench cible l’ingénierie machine learning.

Le problème, c’est que les extraits disponibles ne contiennent aucun chiffre de benchmark exploitable — ni score SWE-bench, ni GAIA, ni AgentBench, ni WebArena, ni OSWorld, ni τ-bench, ni Terminal-Bench, ni BFCL, ni MLE-bench. Aucune comparaison chiffrée entre harnais+modèle local (Qwen3, Llama 4, DeepSeek, Mistral) et combinaisons propriétaires n’est fournie. Et aucune mesure de l’écart « même modèle, harnais différent » n’est disponible.

Un chiffre circule pourtant avec insistance : LangChain aurait gagné 13,7 points sur Terminal-Bench 2.0 sans modifier les poids du modèle. Il faut le traiter avec prudence : ce chiffre provient d’Agentland.fr, une source tierce, et n’a pas été recoupé par une source primaire. Il illustre une intuition plausible — le harnais compte autant que le modèle — mais il ne faut pas le citer comme un fait établi.

Ce que le classement MarkTechPost apporte, en revanche, c’est une méthodologie plutôt qu’un score : licence OSI, runtimes locaux documentés, maintenance active, contrôles de sécurité. C’est moins spectaculaire qu’un leaderboard, mais c’est vérifiable — et dans un domaine où les chiffres sont rares, une grille de lecture honnête vaut mieux qu’un classement chiffré invérifiable.

Ce que ça change concrètement pour votre machine

Reste la question qui intéresse le lecteur : que faire de tout ça sur son propre matériel ?

Le premier réflexe est de ne pas confondre le harnais avec le moteur. Votre llama.cpp (désormais en version 0.5.0, avec un llama-server et une API locale OpenAI-compatible) ou votre Ollama exposent le modèle ; le harnais vient par-dessus. Depuis octobre 2026, Windows ML ajoute même un support expérimental de llama.cpp pour les modèles GGUF, une API locale compatible OpenAI et de la génération de texte ONNX — de quoi simplifier l’installation côté Windows, sans changer la logique harnais/moteur.

Le deuxième réflexe est de choisir un harnais en fonction de son usage réel, pas de son classement. Pour du code, OpenCode (trois voies locales, deux agents) ou Pi (quatre outils, contexte maximal) sont des points de départ solides — mais Pi impose d’isoler l’exécution soi-même. Pour un usage polyvalent au-delà du code, Goose (sept runtimes, 70+ extensions MCP) est le plus souple. Pour un déploiement multi-utilisateurs, OpenClaw Guild (RBAC, isolation par agent, mémoire à quatre niveaux) mérite un détour.

Le troisième réflexe est de budgéter la mémoire avant le GPU. Un modèle 120B+ en quantification 4 bits tient dans 128 Go de mémoire unifiée (Ryzen AI Halo, à 3 999 $) ; un 200B+ réclame 192 Go (Gorgon Halo) ou 128 Go avec offloading agressif. À l’inverse, une RTX 3090 à 24 Go reste parfaite pour du 24B-32B quantifié, à condition de régler correctement le contexte et d’activer le décodage spéculatif — qui, lui, double le débit sans perte de qualité.

Le quatrième réflexe, enfin, est de ne pas se laisser impressionner par le « local-first ». Un client gratuit et hors ligne peut parfaitement cacher une boucle d’agent propriétaire. La question à poser est toujours la même : puis-je lire le code qui décide ? Si la réponse est non, vous êtes dans l’open washing, quel que soit le prix.

Sources

Source : stork.ai
Article recherché et rédigé automatiquement · Magazine Electrosens
📬 Restez à la pointe
Recevez chaque semaine les nouveautés de ce magazine par email.
💬 Une remarque, une correction ?
Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *