Comprendre · Agents IA

Le harness : ce qui transforme un LLM en agent

Boucle modèle–outils, permissions, gestion du contexte, hooks et sous-agents : tout ce qui entoure le modèle et fait la qualité d’un agent de code.

Par Saïd Latrach ·3 min de lecture

Modèle, harness, agent

Un LLM seul ne fait qu’une chose : il lit du texte et produit du texte. Il ne lit pas vos fichiers, ne lance pas vos tests et ne se souvient de rien d’une requête à l’autre. Ce qui en fait un agent, c’est le programme qui l’entoure : le harness (le « harnais »).

Le harness envoie au modèle la conversation et la liste des outils disponibles, exécute les outils que le modèle demande, lui renvoie les résultats, et recommence jusqu’à ce que la tâche soit terminée. Claude Code, les agents des IDE ou un agent construit avec un SDK sont tous des harness autour d’un modèle.

Conséquence pratique : à modèle égal, deux agents peuvent donner des résultats très différents. La qualité dépend autant des outils, des consignes et de la gestion du contexte que du modèle lui-même.

La boucle d’outils

Le cœur de tout harness tient en quelques lignes :

messages = [consigne système, demande de l'utilisateur]

boucle :
    réponse = modèle(messages, outils disponibles)
    si réponse ne demande aucun outil :
        afficher la réponse ; fin
    pour chaque appel d'outil demandé :
        si les permissions le refusent : résultat = "refusé"
        sinon : résultat = exécuter(outil, arguments)
        messages += [appel, résultat]
    si le contexte approche sa limite : compacter(messages)

Le modèle ne fait que demander un outil, sous forme de données structurées (nom et arguments JSON). C’est le harness qui l’exécute, et c’est donc lui qui décide de ce qui est permis. Cette séparation est la base de la sécurité d’un agent.

Les briques d’un harness

Brique	Rôle	Exemple
Consigne système	Comportement général de l’agent	Style de réponse, prudence sur les actions irréversibles
Instructions projet	Règles propres au dépôt, chargées à chaque session	`CLAUDE.md`, `AGENTS.md`
Outils	Ce que l’agent peut faire	Lire, éditer, chercher, lancer une commande
Skills	Savoir-faire chargé seulement quand il sert	Procédure de déploiement, conventions SQL
Hooks	Scripts déclenchés sur des événements, de façon certaine	Bloquer un `git push --force`, lancer le linter
Sous-agents	Tâches déléguées dans un contexte séparé	Recherche dans un gros dépôt, relecture de code
Serveurs MCP	Outils externes branchés par un protocole standard	Ticketing, base de données, CRM

Dans un projet, ces briques se retrouvent sous forme de fichiers versionnés :

projet/
├── CLAUDE.md                 # instructions permanentes, chargées à chaque session
├── .claude/
│   ├── settings.json         # permissions, hooks, variables d'environnement
│   ├── skills/
│   │   └── deploiement/SKILL.md   # savoir-faire chargé à la demande
│   └── agents/
│       └── relecteur.md      # sous-agent spécialisé (outils et consigne propres)
└── .mcp.json                 # serveurs MCP : outils externes (ticketing, base, CRM)

Chaque brique a son article : les skills, les hooks, la gestion du contexte, un serveur MCP.

Permissions et bac à sable

Un agent qui peut lancer des commandes peut aussi supprimer des fichiers ou pousser du code. Un bon harness superpose plusieurs protections :

Modes de permission : demander une confirmation avant chaque écriture, autoriser les éditions mais pas les commandes, ou tout autoriser dans un environnement jetable.
Listes d’autorisation et de refus : autoriser npm test sans confirmation, refuser toujours rm -rf ou la lecture d’un fichier .env.
Bac à sable : limiter les dossiers accessibles en écriture et les accès réseau au niveau du système, indépendamment de ce que le modèle décide.
Hooks : une règle écrite en code, exécutée à chaque appel d’outil, qui ne dépend pas de la bonne volonté du modèle.

Une consigne en langage naturel (« ne pousse jamais sur main ») est utile mais peut être oubliée sur une longue session. Une règle critique doit être appliquée par le harness.

Le contexte, ressource principale

Tout ce que l’agent sait d’une tâche tient dans sa fenêtre de contexte : consignes, fichiers lus, sorties de commandes, échanges. Elle est grande mais finie, et la précision baisse quand elle se remplit de bruit. Le harness l’économise de plusieurs façons : charger les skills à la demande, résumer l’historique quand il devient trop long (compaction), confier une recherche volumineuse à un sous-agent qui ne renvoie que sa conclusion.

Le détail de ces techniques est dans l’article Gérer la fenêtre de contexte d’un agent IA.

Ce qui change pour le développeur

Configurer, pas seulement « prompter » : des instructions projet courtes, des skills pour les procédures, des hooks pour les règles non négociables.
Donner des moyens de vérifier : tests, linter, build. Un agent qui peut lancer les tests corrige ses erreurs seul ; sans eux, il ne fait que deviner.
Versionner la configuration : l’équipe partage le même comportement d’agent, et les changements se relisent comme du code.
Mesurer : un changement de consigne ou de modèle se vérifie sur des cas de référence (voir Évaluer un agent IA).