L'essentiel
Un harness, c'est tout ce qui entoure le modèle : la boucle, les outils, les permissions, l'isolation, les budgets, la reprise, le journal et la relecture. Claude Code et Codex CLI sont déjà des harness d'agent seul. Un harness multi-agent ajoute la répartition du travail et la vérification croisée, pour un coût en jetons d'environ 15 fois celui d'un chat selon Anthropic. Il ne vaut le coup que sur des tâches chères et découpables.
En novembre 2026, « harness » est le mot qui revient sur X dès qu'on parle de faire travailler plusieurs agents IA ensemble. Le mot est bon, mais il est souvent mal employé : on l'utilise pour désigner un framework, un prompt système, voire le modèle lui-même. Cet article remet les choses à plat. Il dit ce qu'est un harness, liste les briques que les sources primaires citent toutes, explique quand le multi-agent fait perdre de l'argent, puis détaille ce que Maestro, notre orchestrateur Rust, fait déjà et ce qui est encore en atelier.
Un harness, c'est le code autour du modèle
Un harness d'agents IA est le programme qui fait tourner un modèle de langage dans une boucle et qui décide de ce qui est autorisé, exécuté, vérifié et conservé. Le modèle génère du texte et des demandes d'outils. Le harness lit ces demandes, applique les permissions, lance les outils dans un environnement contrôlé, compte ce qui a été dépensé, écrit le journal et décide si le résultat est accepté.
La formule qui circule résume bien l'idée : agent = modèle + harness. Deux équipes qui utilisent le même modèle peuvent obtenir des résultats très différents, parce que l'une borne ses agents et l'autre non. Anthropic emploie d'ailleurs le mot dans ce sens : son article sur les agents de longue durée présente le Claude Agent SDK comme « un harness d'agent généraliste » (26 novembre 2025). Il y décrit un fichier de progression, des commits Git réguliers et une liste de fonctionnalités en JSON, traitée une fonctionnalité à la fois. Aucune de ces pratiques ne dépend du modèle : c'est du harness pur.
Harness d'agent seul ou harness d'orchestration
Il faut distinguer deux étages.
- Le harness d'agent seul entoure un modèle. Claude Code, Codex CLI ou Grok CLI en sont : une boucle, des outils (lecture, écriture, shell), des permissions et souvent un bac à sable. Anthropic a par exemple construit le bac à sable de Claude Code sur bubblewrap sous Linux et seatbelt sous macOS (20 octobre 2025), et annonce 84 % de demandes de permission en moins en interne.
- Le harness d'orchestration multi-agent se place au-dessus. Il prend plusieurs agents, éventuellement de fournisseurs différents, leur distribue des tâches, les isole les uns des autres, fait relire le travail de l'un par un autre et garde la trace de qui a décidé quoi.
Les deux étages se cumulent. Un orchestrateur qui pilote Claude Code hérite de son harness, mais il ne doit pas s'y fier aveuglément : une CLI déclarée « en lecture seule » n'est pas forcément enfermée. C'est précisément ce que nous avons constaté en interne avec Codex, et c'est pourquoi l'orchestrateur doit poser ses propres murs.
Les briques communes d'un harness multi-agent
Anthropic, OpenAI, LangGraph et Cognition ne partagent pas la même architecture, mais leurs recommandations retombent sur la même liste. Voici les neuf briques qui comptent, et le défaut que chacune empêche.
| Brique | Ce qu'elle fait | Ce qu'elle empêche |
|---|---|---|
| Contrat et sorties typées | Chaque tâche est décrite (entrées, agent, format attendu) et la réponse est validée contre un schéma. | Un agent qui répond « à peu près » et casse l'étape suivante. |
| Plafonds vérifiés avant l'appel | Jetons, nombre d'appels, durée : le budget est réservé avant d'appeler le modèle, pas constaté après. | Le dépassement découvert sur la facture. |
| Isolation | Bac à sable, moindre privilège : l'agent ne voit que ce dont il a besoin. | Un agent qui lit ~/.ssh ou écrit hors du projet. |
| Reprise par journal | Chaque tâche finie est enregistrée ; après une panne, on reprend sans repayer ce qui est fait. | Relancer tout un run parce qu'un processus est tombé. |
| Manifeste | Versions, empreintes des entrées, réglages : la photo du run au départ. | Une reprise qui mélange deux configurations sans le dire. |
| Relecteur indépendant | Le travail est relu par un autre agent que son auteur, en lecture seule. | L'auto-relecture, qui valide ses propres erreurs. |
| Journal des décisions | Quel agent, quel secours, quelle règle, à quel moment. | Le « pourquoi c'est Grok qui a répondu ? » sans réponse. |
| Simulation sans appel | Estimer le coût et le déroulé d'un run sans consommer de quota. | Découvrir le coût réel en le payant. |
| GO humain | Toute action à risque (écriture, commande, publication) attend une validation explicite. | L'action irréversible lancée par un agent trop sûr de lui. |
Le dernier point n'est pas une précaution de principe. Le guide d'OpenAI, A practical guide to building agents, demande de prévoir l'intervention humaine dans deux cas : quand l'agent dépasse un seuil d'échecs, et pour les actions sensibles, irréversibles ou à fort enjeu. La reprise est tout aussi standard : la documentation de LangGraph présente ses checkpointers comme la base de la continuité, de l'humain dans la boucle et de la tolérance aux pannes.
Quand le multi-agent ne vaut pas le coup
Le multi-agent est un multiplicateur de coût avant d'être un multiplicateur de qualité. Anthropic l'a mesuré sur son propre système de recherche : un agent consomme environ 4 fois plus de jetons qu'un chat, et un système multi-agent environ 15 fois plus (How we built our multi-agent research system, 13 juin 2025). Le même article chiffre le gain, 90,2 % de mieux qu'Opus 4 seul sur son évaluation interne de recherche, et précise que la quantité de jetons dépensés explique à elle seule 80 % de l'écart de performance sur BrowseComp. Une bonne part de la « magie » multi-agent, c'est donc du calcul en plus.
Anthropic tire lui-même la conclusion : le multi-agent demande des tâches dont la valeur paie la performance supplémentaire. Il cite deux contre-indications nettes. D'abord le code, parce que la plupart des tâches de code se découpent moins en morceaux parallèles que la recherche. Ensuite les domaines où tous les agents doivent partager le même contexte ou dépendent beaucoup les uns des autres.
Les autres sources vont dans le même sens :
- OpenAI recommande en toutes lettres de « maximiser d'abord les capacités d'un agent seul » : un agent avec de bons outils suffit souvent, et chaque agent ajouté apporte complexité et surcoût.
- Anthropic donnait déjà la règle dans Building effective agents : chercher la solution la plus simple, et n'ajouter de la complexité que si nécessaire.
- Cognition (Walden Yan, Don't Build Multi-Agents, 12 juin 2025) pose deux principes : partager le contexte complet, et se rappeler que chaque action porte des décisions implicites. Deux agents qui décident chacun de leur côté produisent des résultats incompatibles.
- La recherche sur le débat entre modèles est sévère : l'étude Stop Overvaluing Multi-Agent Debate compare 5 méthodes de débat sur 9 bancs et 4 modèles. Elles font souvent moins bien que des méthodes simples à agent seul, comme le Chain-of-Thought ou le Self-Consistency, malgré bien plus de calcul. Seule la diversité réelle des modèles améliore les choses.
Notre règle est donc simple. Si un agent seul réussit la tâche avec vos tests, n'ajoutez pas d'agent. Le multi-agent se justifie dans trois cas : la tâche se découpe en morceaux vraiment indépendants, une relecture par un modèle différent attrape des erreurs que l'auteur ne voit pas, ou un agent local peu cher peut traiter le gros du travail avant qu'un agent cloud ne vérifie. Dans tous les autres cas, c'est une facture plus lourde pour un résultat équivalent.
Anthropic note aussi qu'au début, son agent principal lançait jusqu'à 50 sous-agents pour des questions simples, et que des sous-agents mal briefés refaisaient le travail des autres. Ce sont exactement les dérives qu'un harness doit empêcher : plafonds, contrats de tâche précis et journal des décisions.
Ce que Maestro 0.7.1 fait déjà de ce harness
Maestro est notre application Rust native, gratuite, pour Windows et Linux. Elle fait travailler ensemble vos modèles Ollama et vos sessions Claude, Codex ou Grok ouvertes avec vos propres forfaits. Voici les fonctions livrées dans la version 0.7.1 téléchargeable, rapprochées des briques du tableau :
- Contrat de mission : agents admis, chemins modifiables, durée et critère de réussite sont écrits avant que le travail commence.
- GO humain lié à la mission : l'écriture attend votre GO, qui porte sur une mission, un projet et une équipe précis et ne sert qu'une fois. Changer l'équipe ou la mission invalide l'ancien GO.
- Relecture par un second agent : dans l'Orchestre, un agent implémente, un autre relit, un troisième valide s'il est disponible.
- Les tests du projet comme juge : le Pilote enchaîne agent, test, retour d'erreur, dans une limite de tours et de temps. Il ne fait ni commit, ni push, ni publication. La frontière Git arrête la boucle si un fichier change hors du périmètre.
- Pare-feu de prompt : la consigne est examinée avant injection (commandes shell, suppressions, opérations Git, secrets). C'est une défense en profondeur par motifs, qui s'ajoute au contrat et aux tests sans les remplacer.
- Passeport d'agent : chaque session porte son agent, son projet, son rôle, ses permissions et son échéance. Hors contrat ou expiré, l'injection est refusée.
- Reprise durable : l'état est enregistré après chaque tâche. Après un crash, la mission retrouve son GO, ses tâches et ses tests sans rejouer ce qui est déjà vert.
- Ledger d'usage : des observations sans contenu, les jetons Ollama mesurés, et un avertissement explicite tant que les données ne suffisent pas (moins de 30 observations et 2 projets).
- Arène : solo, duo ou trio sur votre propre tâche, de 3 à 9 runs au desktop, classés par qualité, vitesse et quota, avec la recommandation de l'équipe la plus légère qui suffit. C'est la réponse outillée à la question « le multi-agent vaut-il le coup ici ? ».
- Shadow Mode : coût, délai et risque estimés d'après vos journaux locaux, sans lancer de modèle.
- Work Plans : une mission en plusieurs tâches dans un fichier, avec dépendances, budget, permissions, test, empreinte SHA-256 et agents de secours.
- 20 outils MCP sur trois serveurs séparés : 10 de diagnostic en lecture, 5 de préparation, 5 de contrôle. Le GO passe par un serveur distinct et ne s'appelle qu'après votre confirmation explicite.
Ce que la 0.7.1 ne prétend pas faire : enfermer les CLI cloud dans un bac à sable, ni appliquer un plafond de jetons avant chaque appel cloud. Côté mesure, seuls les jetons Ollama sont mesurés ; pour Claude, Codex ou Grok en CLI, Maestro ne prétend pas à un compte exact.
En préparation, pas encore dans la version téléchargeable
Statut : ce qui suit existe sur une branche de développement et a été testé en interne. Ce n'est pas dans Maestro 0.7.1 et aucune date de sortie n'est fixée.
Le prochain étage s'appelle maestro task run. L'idée : chaque appel d'agent devient une tâche décrite, journalisée et rejouable. Ce qui est en préparation :
- Contrat de tâche en JSON : agent, modèle, consignes, messages, plafond de jetons. L'empreinte SHA-256 du contrat sert d'identifiant.
- Journal et reprise par empreinte : une tâche déjà terminée est rendue depuis le journal au lieu d'être rappelée. Une reprise ne repaie pas ce qui est fait.
- Plafonds vérifiés avant chaque appel : une tâche qui ferait dépasser le budget est refusée avant l'appel, pas constatée après.
- CLI cloud enfermées dans bwrap (Linux) : la CLI ne voit pas vos dossiers personnels, et une réponse obtenue en utilisant un outil est rejetée.
- Claude sans aucun outil, avec des jetons mesurés à partir de la sortie JSON au lieu d'être estimés.
- Secours par rôle : si un agent tombe en quota, un autre prend le rôle, et c'est tracé.
- Anti auto-relecture : l'auteur d'une tâche ne peut pas être son propre relecteur, y compris dans la liste des secours.
Le 9 novembre 2026, nous avons fait un vrai essai d'isolement sur cette branche. Dans la bulle bwrap, Codex a répondu sans aucun outil disponible, et ~/.ssh était invisible depuis l'intérieur. C'est un test interne, pas une garantie publique : bwrap est propre à Linux, et nous n'annoncerons cette protection que lorsqu'elle sera dans une version publiée et documentée.
FAQ
Qu'est-ce qu'un harness d'agents IA ?
Un harness d'agents IA est le code qui entoure le modèle : la boucle d'appel, les outils, les permissions, l'isolation, les budgets, la reprise après panne, le journal et la relecture. Le modèle propose ; le harness décide de ce qui est exécuté, vérifié et conservé.
Claude Code et Codex CLI sont-ils des harness ?
Oui. Ce sont des harness d'agent seul : une boucle, des outils, des permissions et un bac à sable autour d'un modèle. Un harness d'orchestration multi-agent se place au-dessus : il distribue le travail entre plusieurs agents, les isole les uns des autres et vérifie leurs résultats.
Le multi-agent coûte-t-il plus cher qu'un agent seul ?
Oui. Anthropic mesure qu'un agent consomme environ 4 fois plus de jetons qu'un chat, et un système multi-agent environ 15 fois plus. Le multi-agent ne se justifie que si la tâche vaut ce surcoût et se découpe en morceaux réellement indépendants.
Quand faut-il rester sur un seul agent ?
Quand la tâche demande un contexte partagé, quand les étapes dépendent les unes des autres, ou quand un agent seul avec de bons outils réussit déjà. C'est le cas de la plupart des tâches de code. OpenAI recommande de maximiser d'abord les capacités d'un agent seul.
Maestro est-il un harness multi-agent ?
Maestro 0.7.1 en possède déjà plusieurs briques : contrat de mission, GO humain lié à la mission, relecture par un second agent, tests du projet comme juge, pare-feu de prompt, reprise durable, ledger d'usage, Arène, Work Plans et 20 outils MCP. Le contrat de tâche avec isolement des CLI cloud et plafonds vérifiés avant chaque appel est en préparation et n'est pas dans la version téléchargeable.
Sources
- Anthropic, How we built our multi-agent research system, 13 juin 2025 (4× et 15× de jetons, 90,2 %, 80 % de la variance).
- Anthropic, Building effective agents, 19 décembre 2024 (chercher la solution la plus simple, n'ajouter de la complexité que si nécessaire).
- Anthropic, Effective harnesses for long-running agents, 26 novembre 2025.
- Anthropic, bac à sable de Claude Code, 20 octobre 2025 (bubblewrap, seatbelt, 84 %).
- OpenAI, A practical guide to building agents (PDF).
- Cognition, Walden Yan, Don't Build Multi-Agents, 12 juin 2025.
- LangChain, LangGraph : persistance et checkpointers.
- Zhang et al., Stop Overvaluing Multi-Agent Debate, arXiv 2502.08788.
- OutilsIA, page Maestro 0.7.1 (fonctions livrées).
Article éditorial OutilsIA.fr, publié le 9 novembre 2026. Les fonctions présentées comme livrées sont celles de Maestro 0.7.1 décrites sur la page Maestro ; les fonctions en préparation ne sont pas dans la version téléchargeable.