Les agents IA : comment éviter de s'y perdre entre 'harness', 'scaffold' et autres termes

Quand un domaine évolue vite, son langage suit le même rythme. Parfois, les mots se mélangent, changent de sens ou disparaissent aussi vite qu’ils sont apparus. C’est exactement ce qui arrive avec les agents IA aujourd’hui. Les termes se superposent, certains disparaissent après quelques mois d’utilisation, d’autres sont réutilisés dans des contextes différents. Résultat ? Une vraie pagaille pour les nouveaux comme pour les experts qui veulent suivre les dernières innovations.

Cette confusion a poussé les auteurs de cet article à créer un glossaire pour clarifier les termes qui reviennent le plus souvent, sans explication claire. L’objectif n’est pas de faire un dictionnaire complet, mais de se concentrer sur les concepts qui s’emmêlent, se réutilisent ou sont mal compris. Que vous construisiez un agent, que vous le déployiez ou que vous utilisiez des Outils comme Claude Code, Codex ou Hermes Agent, ces termes vous concernent. La dernière partie aborde des concepts spécifiques à l’entraînement des modèles, pour ceux qui travaillent sur ce côté-là.

Attention : ces définitions ne sont pas universellement acceptées. Différents frameworks utilisent les mêmes mots avec des sens différents. L’idée ici n’est pas d’imposer un vocabulaire unique, mais de proposer un modèle mental pratique pour que les discussions soient plus claires.

LE MODÈLE : LE CŒUR DE L'AGENT

Le modèle est le grand modèle de langage (LLM) : il prend du texte en entrée et produit du texte en sortie. Par exemple, Claude, Qwen, GPT, Kimi ou DeepSeek. À lui seul, il n’a ni mémoire entre les appels ni boucle de raisonnement. Il peut exprimer l’intention d’utiliser un outil, mais il a besoin d’un harness pour l’exécuter vraiment. Il répond à une seule question et s’arrête. En l’enveloppant dans un scaffold et un harness, il devient un agent.

LE SCAFFOLD : LA COQUE QUI DONNE SA FORME À L'AGENT

Le scaffold est la couche qui définit le comportement autour du modèle. Cela inclut le prompt système, les descriptions des outils, la façon dont les réponses du modèle sont analysées, et ce qu’il retient entre les étapes (la gestion du contexte). C’est lui qui façonne la manière dont le modèle voit le monde et agit, que ce soit pendant l’entraînement ou lors de l’inférence.

Des produits comme Claude Code, Codex ou Antigravity CLI appellent souvent l’ensemble du système un harness. La documentation de Claude Code le dit clairement : "Claude Code sert de harness agentique autour de Claude." C’est l’usage le plus courant : un harness désigne tout ce qui n’est pas le modèle. La distinction entre scaffold et harness est surtout utile quand il faut les raisonner séparément, par exemple dans un pipeline d’entraînement. On entend aussi parfois le mot scaffold utilisé de manière plus large pour désigner toute l’infrastructure dont dépend le harness : les hooks, la configuration du runtime, voire la structure des dossiers.

Certains produits comme Claude Code ou Codex sont étroitement liés aux modèles de leur fournisseur. D’autres, comme Antigravity CLI ou Hermes Agent, permettent de brancher n’importe quel modèle.

LE HARNESS : LE MOTEUR QUI FAIT TOURNER L'AGENT

Le harness est la couche d’exécution à l’intérieur de l’agent : il appelle le modèle, gère ses appels d’outils et décide quand arrêter. C’est lui qui fait fonctionner l’agent. Le scaffold, défini plus haut, est ce dont le modèle a besoin pour travailler : ses instructions, ses outils, son format de réponse.

L’ingénierie du harness est la discipline qui consiste à bien concevoir cette couche : décider quand l’agent doit s’arrêter, comment gérer les erreurs, et quelles garde-fous l’empêcher de dérailler. Cela s’applique aussi bien à l’entraînement qu’à l’inférence. Un article d’Addy Osmani et un compte-rendu d’OpenAI sur la construction avec Codex couvrent ce sujet du côté de l’inférence.

Lors de l’évaluation, le même schéma apparaît sous la forme d’un eval harness : au lieu de collecter des données d’entraînement, il exécute un ensemble fixe de scénarios sur un modèle à un instant donné et enregistre des métriques au lieu de mettre à jour les poids.

L'AGENT : AU-DELÀ DU MODÈLE

Le terme agent vient de l’apprentissage par renforcement, où un agent est simplement une fonction qui prend une observation et retourne une action. L’environnement prend cette action et renvoie une nouvelle observation, et la boucle recommence. Cette boucle est au cœur du fonctionnement des agents basés sur des LLM.

Dans le monde des LLM, le sens du mot s’est élargi. Un agent est un modèle plus tout ce qui l’entoure et qui lui permet d’agir, pas seulement de répondre. Il transforme la génération de texte brute en quelque chose qui peut agir en boucle : recevoir des informations, décider quoi faire, et agir en fonction des résultats.

Prenons l’exemple d’un agent de codage. Le prompt système, les descriptions des outils et le format de sortie que suit le modèle forment le scaffold. La boucle qui appelle le modèle, gère ses appels d’outils et décide quand s’arrêter est le harness. Lors de l’entraînement, le harness exécute aussi plusieurs de ces boucles en parallèle et renvoie les résultats pour mettre à jour le modèle.

Dans la communauté, on résume souvent par Agent = Modèle + Harness. Si vous n’êtes pas le modèle, vous êtes le harness. La subtilité entre harness et scaffold est à l’origine de la plupart des confusions, et c’est ce que les deux sections précédentes visent à clarifier.

Quand on parle de produits comme Claude Code, Codex ou Cursor, on parle d’un harness spécifique construit sur un modèle particulier, conçu et optimisé ensemble. Deux produits utilisant le même modèle sous-jacent peuvent sembler complètement différents parce que leurs harnesses font des choix différents. Et remplacer un modèle par un autre dans le même harness change aussi l’expérience. Le modèle, le harness et le produit sont trois choses différentes.

L'INGÉNIERIE DU CONTEXTE : CE QUE L'AGENT VOIT À CHAQUE ÉTAPE

L’ingénierie du contexte consiste à concevoir ce qui entre dans la fenêtre de contexte de l’agent : ce que le modèle voit à chaque étape, le prompt système, les descriptions des outils, l’historique de la conversation, les connaissances récupérées. Ce n’est pas une décision ponctuelle : au fur et à mesure que le modèle fonctionne, les tours précédents façonnent ce qui entre dans les appels futurs, et le harness gère activement cela tout au long de l’exécution. Cela s’applique aussi bien à l’entraînement qu’à l’inférence, mais les conséquences d’une erreur ne sont pas les mêmes. À l’entraînement, ce que le modèle voit façonne ce qu’il apprend. Une erreur oblige à recommencer l’entraînement. À l’inférence, c’est juste du texte : changer un prompt et redéployer suffit.

La mémoire fait partie de ce tableau. La mémoire à court terme reste dans la fenêtre de contexte pendant une seule exécution : historique de la conversation, résultats des outils, raisonnement précédent. La mémoire à long terme persiste entre les sessions, stockée en externe et récupérée à la demande, puis injectée dans le contexte quand c’est pertinent.

LA POLITIQUE : LE COMPORTEMENT DE L'AGENT

Une politique est le comportement qu’un agent suit : face à une situation donnée, elle définit la probabilité de prendre chaque action possible. Dans les systèmes de LLM, une partie de cette politique est apprise dans les poids du modèle, mais le comportement dépend aussi du scaffold et du harness qui l’entourent. Le même modèle peut se comporter très différemment selon ses prompts, ses outils, sa mémoire et sa boucle d’exécution. Une politique n’est pas un agent. La politique définit le comportement ; l’agent est le système complet qui agit dans un environnement. Enveloppez un point de contrôle dans un scaffold et un harness, déployez-le, et vous obtenez un agent dont le comportement est la politique.

L'UTILISATION D'OUTILS : COMMENT L'AGENT INTERAGIT AVEC LE MONDE

L’utilisation d’outils permet aux agents de sortir d’eux-mêmes : APIs, interpréteurs de code, bases de données, recherche web, systèmes de fichiers. Le modèle exprime l’intention d’utiliser un outil dans un format structuré. Les APIs modernes d’inférence exposent cela comme un objet de première classe : le harness reçoit l’appel directement et le redirige vers la bonne fonction. Le résultat est réinjecté dans le contexte et la boucle continue.

LES COMPÉTENCES : DES PAQUETS DE CONNAISSANCES RÉUTILISABLES

Les compétences sont des paquets de connaissances structurées et réutilisables qui permettent d’accomplir des tâches en plusieurs étapes. Là où un outil est une action (« exécuter cette commande »), une compétence regroupe tout ce qui est nécessaire pour atteindre un objectif (« investiguer ce bug, formuler une hypothèse, écrire une correction »). Elles sont portables entre agents et chargées à la demande. La frontière entre outil, compétence et sous-agent varie selon les frameworks. Le cours HF Context Engineering couvre les compétences en détail.

LES SOUS-AGENTS : DES AGENTS À L'INTÉRIEUR DES AGENTS

Un sous-agent est un agent appelé par un autre agent pour gérer une sous-tâche spécifique. Il a son propre modèle et son propre scaffold, raisonne de manière indépendante et renvoie un résultat. L’agent appelant n’a pas besoin de savoir comment il fonctionne en interne. C’est ce qui sépare un sous-agent d’un outil (un appel de fonction) ou d’une compétence (connaissances packagées) : un sous-agent peut lui-même raisonner, utiliser des outils et appeler d’autres sous-agents.

L'ENTRAÎNEMENT : QUAND L'AGENT APPREND

Les termes précédents s’appliquent aussi bien à l’entraînement qu’au déploiement. Les quatre suivants sont spécifiques à l’entraînement, où l’agent passe par des tâches, reçoit une évaluation et ses poids de modèle sont mis à jour. Chaque système d’entraînement par renforcement pour les LLM est construit autour du même pipeline :

L'ENVIRONNEMENT RL : LE MONDE AVEC LEQUEL L'AGENT INTERAGIT

L’environnement RL est tout ce avec quoi l’agent peut interagir : un objet avec état qui prend une action en entrée, met à jour son état interne et renvoie une observation. Dans le contexte des LLM, les actions sont généralement des appels d’outils. Un système de fichiers est un exemple simple : l’action touch foo.txt met à jour l’état en créant le fichier, et l’observation peut être la liste mise à jour des fichiers. Les définitions varient selon les frameworks.

Les auteurs ont récemment publié un guide dédié à ce sujet. Plutôt que de le résumer ici, consultez The Ultimate Guide to RL Environments pour une analyse complète des types, frameworks et exemples.

LE TRAÎNEUR : LA MACHINE QUI FAIT ÉVOLUER L'AGENT

Le traîneur est ce qui rend l’agent meilleur : il exécute de nombreux épisodes d’agent, évalue les résultats et utilise ces informations pour mettre à jour les poids internes du modèle. TRL’s GRPOTrainer est un exemple concret : une seule classe qui gère la génération des épisodes, l’évaluation des récompenses et la mise à jour des poids.

LE ROLLOUT : UNE EXÉCUTION COMPLÈTE DE L'AGENT

Un rollout est une exécution complète de l’agent, du début à la fin : ce que l’agent a vu, ce qu’il a fait et quelle récompense il a reçue à chaque étape. On l’appelle aussi une trajectoire ou un trace, selon le contexte. Ce sont les données brutes dont les algorithmes d’apprentissage par renforcement se nourrissent.

LA RÉCOMPENSE : LE SCORE QUI DIT SI L'AGENT S'AMÉLIORE

La récompense est la note que l’algorithme d’entraînement utilise pour savoir si le modèle s’améliore. Elle peut être vérifiable (les tests passent/échouent, la réponse correspond), apprise (préférences humaines, LLM comme juge), sparse (une seule note à la fin d’un épisode) ou dense (une note à chaque étape). C’est ce que le traîneur utilise pour mettre à jour les poids du modèle. Pour une analyse détaillée de chaque type, consultez la section Architecture de Récompense dans le guide d’Adithya.

EN SAVOIR PLUS : DES RESSOURCES POUR ALLER PLUS LOIN

Pour approfondir, voici quelques ressources utiles :

• @Vtrivedy10 : The Anatomy of an Agent Harness : une analyse détaillée des composants du harness et de leur utilité.
• Agent Harness Engineering : une vision convergente sur Agent = Modèle + Harness, avec des exemples d’agents de codage.
• Harness Engineering : exploiter Codex dans un monde axé sur les agents : un compte-rendu réel de la construction d’un produit entièrement avec des agents Codex, couvrant le scaffold, les boucles de feedback et la gestion du contexte à l’inférence.
• Tool Schema Rendering Atlas (evalstate) : comment les schémas d’outils deviennent du texte dans les prompts pour chaque modèle, montrant ce que chaque modèle voit vraiment après l’application des templates du fournisseur.
• Blog de Simon Willison : How coding agents work : comment un agent de codage fonctionne comme un harness.
• AI Engineer talks like Harnesses in AI: A Deep Dive : ce qu’est un harness et comment le construire.
• The Ultimate Guide to RL Environments : une comparaison framework par framework et une traduction du vocabulaire.
• Amélioration continue de notre harness d’agent : comment Cursor itère sur son harness en tant que produit.
• lm-evaluation-harness : le eval harness canonique.

DERNIÈRE NOTE : LES TERMES CHANGENT, MAIS LA PRÉCISION RESTE

Le 27 mars 2026, une annonce open source a rappelé que la définition populaire de Agent change chaque année. L’année dernière, le mot Autonomie était au centre des discussions. Cette année, c’est clairement Modèle + Harness qui domine. En résumé : plus un terme est précis et technique, mieux c’est .