Dans le domaine de l’intelligence artificielle, le terme harnais (harness en anglais) désigne la couche logicielle qui entoure un grand modèle de langage pour le transformer en un agent capable d’exécuter réellement des tâches. Une formule résume bien cette idée : Agent = Modèle + Harnais.
Pourquoi est-ce nécessaire
Un modèle de langage brut, comme GPT ou Claude, est un cerveau très performant mais isolé. Il ne peut que générer du texte, ne se souvient de rien d’une session à l’autre et n’agit sur rien. Le harnais joue le rôle de système nerveux et de manuel d’utilisation. Il fournit au modèle des données à consulter, des outils à manipuler et des règles à respecter. C’est ce qui lui permet de passer de la capacité à parler à la capacité à agir.
Ce que contient concrètement un harnais
Un harnais complet comprend généralement plusieurs composants. D’abord une invite système, qui définit le rôle de l’agent, ses objectifs et les règles qu’il doit suivre en permanence. Ensuite des outils et un mécanisme d’exécution : le modèle décide quoi faire, le harnais se charge d’exécuter l’action réelle, comme un appel d’API ou l’exécution de code, puis renvoie le résultat au modèle. Vient également la gestion de la mémoire et du contexte, qui détermine quelles informations conserver et lesquelles résumer. S’y ajoute une boucle de vérification et de rétroaction, qui permet à l’agent de tester son propre travail et de corriger ses erreurs. Enfin, des garde-fous et un environnement isolé encadrent les permissions de l’agent et exigent une confirmation humaine avant les opérations risquées.
Une analogie simple
On peut imaginer le modèle comme un cheval puissant mais qui pourrait s’emballer. Le harnais est l’équipement complet : la selle, le mors et les rênes. Il ne change pas la force du cheval, mais il permet au cavalier de contrôler sa direction et son allure, de le faire tirer un chariot en sécurité vers la destination voulue au lieu de foncer dans le décor.
Les configurations de harnais courantes en 2026
Tous les harnais ne se ressemblent pas. Le choix d’une configuration dépend de l’usage visé, du niveau de contrôle souhaité et du contexte de déploiement. Voici les principales familles que l’on rencontre aujourd’hui, illustrées par des produits ou projets réels.
La première est le harnais en boucle simple, parfois appelé boucle ReAct. Le modèle alterne raisonnement, action et observation, sans planificateur externe ni état persistant sophistiqué. C’est l’approche la plus légère et la plus rapide à mettre en place. Un exemple représentatif est youtu-agent de Tencent Cloud, décrit comme un harnais minimal de tool-calling. Cette configuration convient bien aux tâches courtes et aux prototypes. En revanche, elle dérive facilement sur les tâches longues : sans mécanisme de rappel de l’objectif, l’agent peut s’éloigner du but initial après une dizaine d’actions.
La deuxième famille est le harnais avec planificateur ou superviseur. Un composant séparé établit un plan, surveille son exécution et déclenche une replanification en cas d’échec. C’est la configuration qui gagne en production lorsque la fiabilité prime sur la vitesse. Claude Code d’Anthropic et Deep Agents illustrent bien ce modèle : ils implémentent le motif planification-plus-sandbox de manière suffisamment aboutie pour être recommandés lorsqu’on veut qu’un seul agent termine une tâche de codage de bout en bout de façon fiable.
La troisième famille est le harnais modulaire, où les composants sont interchangeables. OpenCode en est un exemple important : il s’agit d’un backend d’agent de codage qui peut être utilisé comme runtime par d’autres harnais, comme le montre son intégration dans lh-harness aux côtés de Claude Code, Codex CLI et DeepSeek Harness . OpenCode est également à la base de dérivés comme DrizzyAgent, qui étend OpenCode avec une orchestration multi-agents . Cette modularité facilite les tests A/B et l’évolution indépendante de chaque brique.
La quatrième famille est le harnais multi-agents, où plusieurs agents spécialisés collaborent sous la coordination d’un agent manager. MetaGPT en est le représentant historique : il simule une « entreprise logicielle IA » avec des agents qui jouent les rôles de chef de produit, architecte et ingénieur. CrewAI et AgentVerse s’inscrivent dans la même veine. DrizzyAgent, mentionné plus haut, illustre cette approche appliquée au codage avec ses rôles de Coder, Planner, Oracle, Librarian et Atlas . Cette configuration brille lorsque les sous-tâches sont indépendantes et que la spécialisation apporte un gain réel.
La cinquième famille est le harnais de type microkernel ou plan de contrôle. L’idée centrale est de séparer strictement le plan de contrôle (ordonnancement, état, sécurité, mémoire, audit) du plan d’exécution, où les agents sont hébergés dans des sandbox. QM de YCombinator en est un exemple frappant : il fournit une séparation au niveau de l’organisation, où chaque employé, salon Slack et projet dispose de sa propre mémoire, de ses fichiers, de ses identifiants, de ses permissions et de son environnement sandboxé. Cette architecture offre une stabilité de production et un contrôle multi-tenant.
OpenClaw occupe une place particulière dans cette famille. Il ne se présente pas comme un harnais unique mais comme une plateforme d’exécution d’agents qui peut accueillir plusieurs harnais natifs. Sa documentation décrit explicitement un « harnais Codex » qui permet à OpenClaw de déléguer l’exécution à un serveur d’application Codex natif, tout en conservant la maîtrise du plan de contrôle : résolution du fournisseur et du modèle, authentification, budget de contexte, politique d’outils, sandbox et livraison des réponses . OpenClaw propose également un harnais acpx pour les agents compatibles ACP, avec des alias intégrés pour factory-droid, cursor et d’autres . Cette architecture illustre la tendance à traiter le harnais comme un exécuteur interchangeable, branché sur un noyau qui reste stable.
Enfin, une catégorie plus récente mérite d’être mentionnée : le harnais de flux de travail, qui impose une discipline de phases (spécification, conception, implémentation, vérification, intégration) avec un contexte frais à chaque phase et une persistance d’état dans des fichiers explicites. GSD (Get Shit Done) en est l’exemple canonique : il enveloppe une session de codage IA dans un cycle de vie en six étapes, avec un état de projet stocké dans un répertoire versionné qui survit aux réinitialisations de contexte.
Il faut également citer Pi, qui se distingue par une philosophie de « harnais auto-modifiable ». Pi n’est pas seulement un harnais de codage : c’est un environnement que l’agent peut lui-même inspecter et modifier, avec un système de plugins et d’extensions. Son package pi-harness-runtime illustre cette approche en fournissant une configuration runtime complète, avec gestion des clés API, intégrations Telegram, LangChain et PaperClip, et un mécanisme de boucle planificateur-coder-relecteur-fixeur . Dans une interview accordée à InfoQ, les créateurs de Pi décrivent leur outil comme « une preuve de concept d’un logiciel agentique auto-modifiable », et citent DeepSeek Harness comme une inspiration conceptuelle sur cette même voie . Un package communautaire comme @minhduydev/pi-harness pousse la logique plus loin en proposant un harnais portable avec extensions, compétences, modèles de prompts et thèmes, ainsi qu’un contrat de coordination gouverné pour les sous-agents .
Un point important
Le harnais ne consiste pas à corriger ponctuellement un problème en modifiant une invite. Son objectif central est de corriger une erreur commise par l’IA en modifiant son environnement d’exécution, de sorte que cette erreur ne puisse plus se reproduire. C’est pourquoi on considère souvent que la qualité du harnais détermine le degré de maturité d’un modèle dans des scénarios complexes. Une étude arXiv de 2026 va plus loin : le choix du harnais expliquerait une part plus importante de la variance des résultats aux benchmarks d’agents que le choix du modèle lui-même. Autrement dit, à modèle égal, un bon harnais fait une différence mesurable.
