Un modèle
ne devient agent
qu'avec un harness.

La plupart des discussions sur les agents IA commencent au mauvais endroit. On compare GPT, Claude, Gemini, puis on cherche lequel est le plus intelligent. C'est intéressant, mais ce n'est pas suffisant. Un agent ne tient pas seulement par la puissance du modèle. Il tient par le système qui entoure ce modèle.

Depuis plusieurs mois, cette idée devient de plus en plus centrale dans l'ingénierie agentique : Agent = Modèle + Harness. Ce n'est pas une formule marketing. C'est une manière beaucoup plus juste de comprendre pourquoi deux agents utilisant le même modèle peuvent avoir des résultats totalement différents.

Un modèle produit du texte. Il répond à une entrée, puis il s'arrête. Il n'a pas, tout seul, de mémoire durable, de boucle d'action, d'accès réel aux fichiers, de capacité de vérification ou de politique de sécurité. Le harness est la couche qui transforme cette génération de texte en comportement agentique.

Pourquoi ce concept change tout

Le benchmark Terminal-Bench 2.0, publié en 2026, illustre bien le déplacement du sujet. Il ne mesure pas seulement une réponse textuelle. Il teste des agents dans des environnements de terminal, avec des tâches longues, des fichiers, des commandes, des tests et des vérifications. Autrement dit, il évalue une capacité d'exécution.

De plus, des travaux récents comme Harness-Bench montrent que la performance d'un agent dépend fortement de la configuration modèle plus harness. Le modèle compte, bien sûr. Mais le système qui organise le contexte, les outils, l'état, les contraintes, les permissions, la traçabilité et la récupération d'erreur compte tout autant.

C'est exactement ce qui change la manière de raisonner. On ne peut plus demander simplement : "quel est le meilleur modèle ?". La vraie question devient : quel est le meilleur système autour du modèle pour cette tâche précise ?

Harness, scaffolding, prompt engineering : trois niveaux différents

Trois notions sont souvent mélangées, alors qu'elles ne parlent pas du même endroit dans la stack.

Le prompt engineering consiste à mieux écrire l'entrée envoyée au modèle. C'est une compétence très utile, mais ce n'est pas une architecture. Un bon prompt peut clarifier le rôle, le format attendu et les contraintes de réponse.

Le scaffolding concerne la préparation de l'agent avant l'exécution : quels outils sont disponibles, quels sous-agents existent, quelles instructions sont compilées, quelle configuration initiale est chargée.

Le harness, lui, concerne ce qui se passe pendant l'exécution. C'est la couche qui pilote la boucle : appel du modèle, choix d'action, exécution d'outil, observation du résultat, mise à jour du contexte, vérification, reprise, arrêt.

Une phrase résume très bien la différence : le prompt système dit au modèle quoi faire, le harness contrôle ce qu'il peut réellement faire.

Les composants concrets d'un bon harness

Un harness de production n'est pas seulement une boucle qui relance un modèle plusieurs fois. C'est un ensemble de composants qui doivent travailler ensemble proprement.

1. La boucle raisonnement, action, observation

La boucle la plus connue vient du pattern ReAct : le modèle raisonne, propose une action, le système exécute cette action, puis le résultat revient sous forme d'observation. Cette observation permet au modèle de continuer avec une meilleure information.

Écrite de manière simple, cette boucle peut tenir en quelques dizaines de lignes. Mais la vraie difficulté n'est pas la boucle minimale. La vraie difficulté, c'est tout ce qui permet à cette boucle de rester fiable quand elle dure vingt, cinquante ou cent étapes.

2. L'exécution des outils

Le harness définit quels outils existent, comment ils sont appelés, comment leurs résultats sont formatés et comment leurs erreurs sont renvoyées au modèle. C'est un point très important. Un outil qui échoue silencieusement produit un agent confiant mais faux.

Dans un agent de code, par exemple, l'outil peut lancer un test. Si le test échoue, le harness doit renvoyer l'erreur de manière lisible. L'agent peut alors corriger. Si l'erreur disparaît dans les logs, l'agent continue sur une hypothèse fausse.

3. La construction dynamique du prompt système

Dans un système sérieux, le prompt système n'est pas toujours un texte figé. Il peut être construit au début de la session avec l'identité de l'agent, le périmètre de la tâche, les règles de sécurité, les limites d'outils, les conventions de sortie et les contraintes du projet.

Tout ce qui ne peut pas être imposé directement par le code doit être exprimé clairement dans cette couche. Mais il ne faut pas lui demander de faire le travail du code. Les règles critiques doivent être contrôlées par le harness.

4. La gestion du contexte et la compaction

La fenêtre de contexte est la mémoire de travail de l'agent. Elle est limitée. Plus la tâche dure, plus elle se remplit : messages, résultats d'outils, erreurs, corrections, fichiers lus, plans successifs.

Le risque est connu : le contexte devient trop long, trop bruyant, et le modèle commence à perdre le fil. On parle souvent de context rot. Le harness doit donc condenser les anciennes étapes, supprimer les résultats obsolètes, externaliser l'état dans des fichiers ou isoler certaines tâches dans des sous-agents qui renvoient uniquement un distillat utile.

5. La mémoire à deux niveaux

Il faut distinguer la mémoire courte et la mémoire longue. La mémoire courte correspond à ce qui reste dans la fenêtre de contexte pendant une exécution. La mémoire longue vit en dehors du modèle : fichiers, journaux de progression, base vectorielle, notes de projet, état sauvegardé.

C'est cette mémoire longue qui permet à un projet de garder une continuité, même quand chaque nouvelle session modèle démarre sans souvenir propre.

6. La vérification et la récupération d'erreur

Un bon harness ne laisse pas seulement l'agent produire. Il vérifie. Il peut lancer des tests, valider un fichier, contrôler un format, détecter une action dangereuse, demander une confirmation humaine ou relancer une étape après une erreur bien identifiée.

C'est ce mécanisme de rétroaction qui fait la différence entre une démonstration impressionnante et un système qui peut réellement livrer.

7. La sécurité et les permissions

Le harness impose les limites que le modèle ne doit jamais franchir : quels fichiers sont accessibles, quelles commandes sont interdites, quelles actions nécessitent une validation humaine, quelles sorties externes sont bloquées.

C'est ici que se joue une grande partie de la sécurité. Un modèle peut être trompé. Il faut donc supposer que cela arrivera et réduire le rayon d'impact.

8. L'observabilité

Sans traces, un agent devient une boîte noire. Le harness doit enregistrer les appels d'outils, les résultats, les erreurs, les validations, les coûts et les décisions importantes. Sans ça, impossible de comprendre pourquoi l'agent a réussi, échoué ou pris une décision risquée.

Lire OpenClaw, CrewAI et les SDK avec cette grille

Cette notion permet aussi de mieux comprendre les outils déjà connus. On arrête de les comparer comme s'ils répondaient tous à la même question.

OpenClaw ressemble à un harness complet déjà packagé pour l'utilisateur final. Il apporte une interface de messagerie, une boucle d'exécution, des permissions, un espace de travail, de la mémoire et une logique de session.

CrewAI aide plutôt à construire un harness orienté workflow multi-agents. Il structure des rôles, des tâches et des processus, mais il reste à intégrer proprement dans une application avec les bons outils, les bons contrôles et les bonnes validations.

Claude Agent SDK ou OpenAI Agents SDK se situent encore plus près de la construction. Ils donnent des briques : boucle agent, outils, sessions, garde-fous, traces, handoffs. Mais c'est au développeur de décider comment ces briques deviennent un système cohérent.

De plus, cette grille confirme une idée très simple : ces outils ne sont pas seulement des "agents". Ce sont des degrés différents de harness déjà construit.

Le lien direct avec la sécurité

Le harness n'est pas seulement une question de performance. C'est aussi la couche où se joue la sécurité réelle de l'agent.

Un modèle peut recevoir un email malveillant, une page web piégée, un message ambigu ou un fichier contenant une instruction cachée. La question n'est donc pas : "est-ce que le modèle peut être manipulé ?". Il faut partir du principe que oui.

La vraie question devient : que peut-il se passer si le modèle se trompe ?

C'est le harness qui répond à cette question. Il limite les permissions, isole l'environnement, bloque certaines commandes, exige une confirmation humaine avant les actions irréversibles et garde une trace de ce qui a été fait.

L'ordre de priorité est donc clair : d'abord contrôler qui peut parler à l'agent, ensuite limiter où il peut agir, puis seulement en dernier compter sur le bon comportement du modèle.

À retenir

Un agent IA n'est jamais uniquement un modèle. C'est un modèle entouré d'un harness. Dans la pratique, ce harness décide souvent si l'agent fonctionne, échoue silencieusement ou devient dangereux.

Avant de juger un outil agentique, il faut donc regarder ce qui entoure le modèle : la boucle d'exécution, les outils, la mémoire, les règles de sécurité, la vérification, la persistance et l'observabilité.

Mon objectif ici est vraiment simple : remettre l'architecture au centre. Le meilleur agent n'est pas seulement celui qui utilise le meilleur modèle. C'est celui dont le harness permet au modèle d'agir dans un cadre clair, vérifiable et maîtrisé.