Le Harness appliqué au développement logiciel agentique

Dans un article précédent, je vous ai parlé d'ECC, qui se décrit lui-même comme un « agent harness operating system ».

Je vous propose ici d'approfondir la notion de harnais (harness), et d'établir sa définition dans le développement logiciel agentique.

Pourquoi le harness compte plus que le modèle

Avant de détailler l'anatomie du harness, il faut comprendre pourquoi ce concept a pris une telle importance en 2026. La conception du harness qui entoure les modèles d'IA augmente considérablement leur taux de réussite à la tâche. Plus le harness est pertinent et bien construit, plus le modèle va pouvoir délivrer un travail de qualité.

Dans ce paragraphe, je ne vais pas parler de l'apparition des formes de technologie, mais de leur formalisation sous un nom commun. De 2022 à 2024, l'accent a été mis sur la formalisation du prompt engineering, à savoir construire une demande de façon spécifique pour obtenir de meilleurs résultats selon la compréhension du prompt par le modèle LLM. En 2025, c'est le concept de context engineering (introduire un contexte, des règles, et une mémoire centrés sur un projet) qui s'est formalisé sous cette appellation. Début 2026, c'est sous le nom d'agent harness que se formalise le contrôle d'un modèle par un outillage plus avancé. Ça existait déjà avant, mais maintenant, ça a un nom bien défini.

L'analogie connue est que le modèle LLM est comparé au CPU, la puissance brute. La fenêtre de contexte est la RAM, la mémoire limitée. Le harness, lui, est le système d'exploitation, l'ensemble de fichiers qui forme un tout cohérent. Le prompt est, lui, la fenêtre de communication, le moyen pour l'utilisateur de communiquer avec ce système.

Qu'est-ce qu'un Agent Harness ?

Un agent harness, c'est l'ensemble des outils et systèmes qui entourent un modèle d'IA pour lui permettre de travailler efficacement sur du code. Concrètement, c'est exactement ce que sont Claude Code, Codex, Antigravity IDE, Antigravity CLI, OpenCode, Hermes Agent, Cline ou Continue : chacun de ces outils est un harness, avec sa propre façon d'organiser le raisonnement de l'agent, ses outils d'exécution, sa gestion du contexte et ses garde-fous. Ça existait donc avant de prendre la définition d'agent harness, appelé ainsi, pour préciser que c'est un harnais autour d'un agent IA, et se détacher de la notion classique de test harness.

Pour comprendre comment un harness est construit, on peut le découper en cinq couches.

Couche Cognitive

Cette couche, c'est le cerveau de l'agent : le modèle et sa boucle de raisonnement (planifier, agir, observer). C'est ce qui différencie un agent d'un simple chatbot : au lieu de juste répondre à une question, il découpe une tâche en étapes, les exécute une par une, regarde ce qui se passe, puis ajuste son plan si besoin.

Concrètement, tous les outils que vous connaissez fonctionnent sur ce principe : Claude Code, Codex, Antigravity CLI ou Cline planifient une action, l'exécutent via un outil, puis observent le résultat avant de continuer. Certains harnais poussent cette logique plus loin en séparant carrément les rôles : un agent qui planifie le travail, un autre qui l'exécute, et un troisième qui vérifie que le travail est bien fait avant de passer à l'étape suivante, un peu comme un chef de projet, un développeur et un testeur qui se relaient sur la même tâche.

Couche d'Exécution

Si la Couche Cognitive réfléchit, la Couche d'Exécution agit. C'est elle qui regroupe tout ce que l'agent peut réellement faire sur votre machine : lancer une commande dans le terminal, lire et écrire des fichiers, chercher dans votre code, et interagir avec Git. Si l'agent est bien conçu, normalement, cette couche est encadrée par une sandbox, un espace isolé où l'agent peut travailler sans risquer de casser votre environnement réel.

Tous les outils que vous manipulez au quotidien ont leur propre façon de gérer cette couche. Claude Code et Codex tournent directement dans votre terminal avec accès à vos fichiers locaux, tandis qu'Antigravity IDE ou Continue intègrent cette exécution directement dans votre éditeur de code, avec le projet comme cadre d'accès principal. Cette couche donne à l'agent les moyens d'agir, mais pas le droit de tout décider seul, ce contrôle-là appartient à une autre couche.

Couche de Contexte et de Compétences

Cette couche répond à une question simple : qu'est-ce que l'agent sait sur votre projet avant même de commencer à travailler ? Elle regroupe la mémoire du projet, les fichiers de contexte comme AGENTS.md, et les Skills, des fiches de compétences que l'agent va consulter uniquement quand elles sont utiles, ou sur demande de l'utilisateur. Cette approche, appelée progressive disclosure, permet à un agent de disposer de dizaines, voire de centaines de compétences disponibles sans jamais saturer sa fenêtre de contexte. C'est ce système de Skills qui est aujourd'hui repris par la quasi-totalité des outils du marché, ce qui permet d'écrire une compétence une seule fois et de la réutiliser dans plusieurs harnais différents.

Couche d'Orchestration

Un moyen d'exécution efficace de la couche de contexte et de compétences. Quand une tâche est trop grosse pour un seul agent, la solution qui s'est imposée en 2026 est simple : un agent principal (l'orchestrateur) garde la vue d'ensemble, reste actif en permanence, et délègue de petits bouts de travail à des sous-agents temporaires qui démarrent chacun avec une mémoire vierge. Une fois leur tâche terminée, ces sous-agents ne renvoient pas tout leur travail brut, juste un résumé propre et compact. Cette règle du résumé n'est pas un détail technique, elle est ce qui rend le système utilisable. Un exemple concret et efficace : demander à un agent d'écrire du code, puis à un second agent, complètement isolé du premier, de venir le relire. Cette séparation évite qu'un agent se contente de valider son propre travail sans esprit critique.

Couche de Gouvernance (Évaluations et Guardrails)

Cette dernière couche répond à la question la plus importante : comment être sûr que le travail de l'agent est fiable ? Elle combine deux types de garde-fous : ceux qui guident l'agent avant qu'il n'agisse (comme des Skills ou des règles de contexte spécifiques aux étapes de vérification), et ceux qui vérifient son travail après coup, comme les tests automatisés, les vérifications de qualité de code, ou une demande de validation humaine explicite à certaines étapes.

Description faite, place aux outils concrets en ce début juillet 2026.

Panorama des Agent Harness du moment

Claude Code d'Anthropic est la référence historique, avec un système de Skills désormais lu nativement par la quasi-totalité des agents harness concurrents. Ce qui permet à la fois un apprentissage unique utilisable globalement, avec de micro-ajustements, pour les développeurs, s'ils s'essayent à d'autres agent harness, et une interopérabilité des agents et des skills pour piloter de multiples agent harness. Un normage officieux bienvenu dans ce secteur en évolution très rapide.

Voici une liste des agents harness du moment ayant fait leurs preuves. Je vous invite à les découvrir vous-même, chacun ayant ses spécificités (utilisation via bash, ou via extension IDE, apprentissage, écosystème léger ou complet…) :

• Claude Code — anthropics/claude-code
• Antigravity CLI — Antigravity CLI
• Antigravity IDE — Antigravity IDE
• Cursor — Cursor
• Codex — openai/codex
• Cline — cline/cline
• Hermes Agent — nousresearch/hermes-agent
• Continue — continuedev/continue
• OpenCode — anomalyco/opencode
• Goose — aaif-goose/goose

Pour voir plus loin

Pour compléter cet article, je vais vous parler de deux formes supplémentaires d'outil, s'ajoutant à l'agent harness.

Meta-Harness : gouverner plusieurs agent harnais à la fois

Le meta-harness est une couche qui se place au-dessus de plusieurs agent harness existants pour les rendre interopérables, plutôt que de remplacer l'un d'entre eux. Le point le plus intéressant du meta-harness est que sa couche de décision est elle-même agentique : quand un agent tente une action, comme télécharger un paquet npm, le moteur de politiques évalue dynamiquement le contexte de la session avant d'autoriser ou de refuser, plutôt que d'appliquer une simple liste blanche ou noire statique (bien que cette granularité soit bien sur toujours accordé à l'utilisateur/développeur). C'est ce qui permet des scénarios inédits comme la revue de code croisée entre agent harness, où Claude Code écrit une fonctionnalité tandis que Codex la relit, chacun opérant dans son propre harnais mais partageant le même historique de session.

Il serait apparu via un dépôt attribué à Stanford stanford-iris-lab/meta-harness avant de se concrétiser sous la forme d'omnigent omnigent-ai/omnigent.

Agent Harness Operating System

Un agent harness operating system est une couche logicielle qui ne se contente pas d'outiller un seul agent, mais qui cherche à standardiser, sécuriser et faire persister les compétences, la mémoire et les politiques de gouvernance pour les différents agent harness existants actuellement, exactement comme un système d'exploitation classique standardise l'accès au matériel pour des applications qui, sans lui, seraient incompatibles entre elles. Pour l'instant, à ma connaissance, ECC est l'exemple le plus abouti cette catégorie.

Plutôt que de se focaliser uniquement sur Claude Code, ECC fait fonctionner Claude Code, Codex, OpenCode, Cursor, Anitgravity autour du même socle de Skills, règles, hooks et configurations MCP. Dans sa version 2, le projet embarque 64 agents, 261 skills et 84 commandes prêt à la selection et à l'emplois. Ce proejt intègre aussi un mécanisme de mémoire qui traverse les sessions, ainsi qu'un système de distillation appelé « instincts », qui transforme les patterns de workflow observés en connaissances réutilisables automatiquement dans les tâches futures. Et par rapport au contexte en cour dans une session, la création de skill est aussi directement possible pour être réutilisée par la suite dans ou en dehors du projet. C'est une différence concrète avec un agent harness simple (Vanilla, sans ajout), dont le contexte reste généralement borné à un projet, voire pour certains à une seule session.

ECC embarque aussi AgentShield, une couche de scan proactif contre les injections de prompt et les fuites de données, appliquée uniformément quel que soit l'agent harness sous-jacent utilisé. Un outil de sécurité supplémentaire dont les agent harness ne sont pour le moment pas dotés nativement. Pour plus de détails, vous pouvez lire mon article dédié à ECC.

Conclusion

En espérant avoir été assez concis et complet sur la définition d'un agent harness, on peut retenir l'essentiel : ce n'est pas le modèle seul qui détermine la qualité du travail produit, mais l'ensemble de l'outillage: cognitif, exécutif, contextuel, orchestral et de gouvernance qui l'entoure. C'est cette architecture en couches, désormais formalisée sous un nom commun début 2026, qui explique pourquoi deux développeurs utilisant le même LLM peuvent obtenir des résultats radicalement différents selon le harnais choisi. Les meta-harness et les agent harness operating system comme ECC illustrent la prochaine étape logique de cette évolution : ne plus choisir un seul outil, mais faire cohabiter et gouverner plusieurs harnais autour d'un socle commun de compétences et de règles.

J'aborderai sûrement dans un prochain article les différences fines entre certains agents harness, et ceux spécialisés dans une tâche spécifique, comme l'orchestration multi-agent (sans passer par un meta-harness), les outils dédiés à la mémoire, ceux avec une approche comme Hermes « d'assistant personnel long terme », ou encore les frameworks plus complexes construits autour de la capacité agentique.