Harness engineering : Pourquoi le cerveau ne suffit pas ?

On parle beaucoup de ce que les agents IA savent faire (et la liste s’agrandit de jour en jour) et ces démonstrations impressionnent parce qu'elles donnent l'impression qu'un modèle est devenu opérateur. Il ne répond plus seulement, il agit.

Mais cette lecture est incomplète. La vraie question n'est pas seulement de savoir si le modèle raisonne bien. Elle est de savoir dans quel environnement on le laisse raisonner, agir, mémoriser, oublier, recommencer et se tromper. Un agent IA n'est pas un modèle plus quelques outils, c'est un système complet et dans ce système le modèle n'est qu'une partie du sujet.

Le reste porte un nom qui commence à germer dans les discussions, le harness ou harness engineering. C'est l'environnement d'exécution de l'agent, ce qui lui ouvre l'accès aux fichiers, aux outils et aux canaux externes et lui donne un contexte, une mémoire et des procédures sur lesquels s'appuyer. C'est aussi ce qui borne cet accès en gardant une trace de ce qu’il fait, en encadrant les erreurs et en réservant à notre contrôle ce qui doit y rester. Le modèle pense, le harness décide dans quelles conditions cette pensée peut interagir avec le monde.

Le modèle pense, le harness agit

L'image la plus juste vient des personnes qui construisent ces systèmes au quotidien. Le modèle est le cerveau. Le harness lui donne les mains, les doigts et le retour sensoriel avec le monde.

Un cerveau seul ne fait rien. Il raisonne et planifie, mais il ne touche à rien. Pour agir il lui faut des organes qui perçoivent, des membres qui exécutent, un système nerveux qui transmet. Le harness joue exactement ce rôle. Il transforme un modèle qui produit du texte en système qui agit, en lui donnant un shell pour exécuter, des fichiers pour travailler, une mémoire pour durer, des permissions qui bornent ses gestes et des passerelles vers les canaux du dehors. Et il ne se contente pas d'ouvrir ces accès, il définit dans quel ordre l'agent les emprunte, avec quels droits et ce qui se passe lorsque les choses tournent mal

Cette distinction change la façon de comparer les outils. Pendant longtemps la comparaison s'est concentrée sur le cerveau. Quel modèle comprend mieux, lequel code mieux, lequel planifie mieux, lequel tient le plus long contexte. Ces questions comptent mais elles ne suffisent plus. Tant qu'on reste sur le modèle, le débat tourne en rond, Claude contre GPT, un nouveau classement, une nouvelle version, comme s'il s'agissait de trouver le meilleur cerveau dans un bocal. Dès qu'on regarde le harness on voit autre chose, comment chaque système organise le contexte, la mémoire, les outils, les limites et la durée.

La dérive silencieuse des agents qui durent

Le problème n'apparaît pas le premier jour. Au début tout fonctionne. Puis le temps passe et l'agent retient trop de choses, ou pas assez. Les fichiers de mémoire gonflent, les règles se contredisent, les compétences s'accumulent. Une instruction temporaire devient permanente ou un outil activé pour tester reste disponible. Peu à peu l'agent devient moins clair, pas forcément moins capable mais moins net. Il peut réussir une démonstration et devenir pénible à utiliser au bout de quelques semaines, mélanger deux projets, conserver une règle périmée, réutiliser une procédure qui n'est plus adaptée.

Dans ces cas-là le problème ne vient pas forcément du modèle. Il fait exactement ce qu'on lui demande avec ce qu'on lui donne. Le problème se situe en amont, dans l'architecture autour de lui et de l’accumulation de mémoire mal triée qui finissent par contaminer chaque tâche. C'est l’angle mort de beaucoup de discussions sur les agents, on juge le cerveau mais on regarde trop peu le système nerveux. Un harness bien conçu devrait pouvoir anticiper cette dérive en décidant ce que ces mains ont le droit de toucher, ce qu'elles se rappellent et ce qu'elles finissent par oublier.

Une mémoire qui choisit ce qu'elle garde

La mémoire est le premier levier, et son design révèle immédiatement la philosophie du système.

La solution la plus directe consiste à charger les informations importantes dans le system prompt, là où le modèle ne peut pas les ignorer, plutôt que de les enfouir dans un RAG ou une base vectorielle que l'agent reste libre de ne jamais consulter. Deux fichiers suffisent pour l'essentiel, l'un pour ce que l'agent sait de l'utilisateur, l'autre pour ce qu'il sait de son environnement.

Mais ce qui distingue une mémoire utile d'une mémoire encombrante, c'est une contrainte de taille. Une mémoire infinie devient vite un grenier, on y retrouve des choses utiles mais aussi des restes de tâches anciennes, des préférences mal généralisées, des fragments de contexte qui n'ont plus rien à faire dans la conversation en cours. Une mémoire trop pauvre oblige l'utilisateur à tout répéter et l'agent redevient un outil ponctuel. Le bon design est entre les deux, une mémoire contrainte qui oblige à choisir, à compacter, à supprimer, à reformuler, à hiérarchiser. Elle transforme la mémoire en jugement. Un agent mature ne doit pas seulement bien mémoriser, il doit bien oublier.

Au-delà de la contrainte de taille, l'ordre de récupération compte autant que le contenu. Un harness discipliné consulte d'abord ce qui est immédiatement disponible dans le contexte, puis ce qui est à portée et seulement en dernier recours l'historique long par recherche vectorielle. Partir trop vite et trop large sur la recherche externe, c'est exposer chaque tâche à des fragments de contexte qui ne la concernent pas.

Enfin la mémoire ne devrait pas être un fichier figé mais une interface. On commence avec deux fichiers markdown qui couvrent la majorité des cas et le jour où les besoins grandissent, on change l'implémentation sans toucher à l'agent. C'est une décision d'architecte, pas une simple fonctionnalité.

Les compétences, télécharger ou apprendre

Au-delà de la mémoire déclarative, ce qu'on sait, il y a la mémoire procédurale, ce qu'on sait faire. C'est là que les choix d'architecture divergent le plus.

Quand un agent répète une tâche, il peut finir par apprendre une manière de faire. Pas seulement retenir une information mais formaliser une procédure. Comment déployer dans cet environnement, comment vérifier tel type de configuration, comment préparer tel livrable. Deux philosophies s'opposent. La première consiste à empiler des capacités prêtes à l'emploi, un modèle d'app store où on cherche une compétence et où on l'installe, déjà faite par d'autres. Rapide, séduisant, parfois très efficace, mais chaque ajout augmente la surface à surveiller et chaque capacité importée embarque ses hypothèses, ses droits, ses angles morts.

La seconde consiste à construire les compétences à partir de l'usage réel. L'agent observe les tâches qui reviennent, et lorsqu'il détecte qu'un même type de tâche se répète et qu'il a appris à le résoudre, il entre dans une phase réflexive. Il analyse sa performance, extrait les motifs réutilisables et écrit lui-même une compétence qui encode la manière dont il a résolu le problème. La différence est décisive. Une mémoire indique que l'utilisateur utilise Tailscale, une compétence indique comment configurer Tailscale dans cet environnement précis. La première est une information, la seconde une procédure réutilisable. Une compétence de marketplace fait des hypothèses sur son contexte de destination, une compétence construite à partir de l'usage réel l'a vécu, elle est calibrée d'emblée.

Cette approche est plus lente mais plus saine. Elle évite de transformer l'agent en catalogue vivant et l'oriente vers une forme d'apprentissage opérationnel, plus proche d'un compagnonnage que d'un app store. Reste le risque de l'accumulation. Une compétence qui n'est jamais revue devient une dette, une procédure utile aujourd'hui peut devenir dangereuse demain. La réponse est un curateur automatique, révision régulière des compétences, déplacement entre états actif et archivé, rapport d'usage. L'apprentissage sans hygiène finit toujours en désordre. Un agent utile dans le temps n'est pas celui qui accumule le plus, c'est celui qui sait transformer l'expérience en procédures propres puis nettoyer ces procédures lorsqu'elles ne servent plus.

Le prix des mains

L'image du cerveau et des mains a une conséquence qu'on oublie souvent. Plus on donne de mains à l'agent, plus il faut construire de limites autour de lui.

Un agent qui répond dans une interface de chat reste relativement contenu. Un agent qui lit des fichiers touche déjà à un environnement sensible. Un agent qui écrit dans un dépôt peut casser quelque chose. Un agent qui appelle des APIs peut modifier des données. Un agent qui discute sur Slack, Telegram ou Teams entre dans une surface sociale. Un agent qui accède au réseau, aux secrets, à l'infrastructure ou aux outils métier devient un véritable acteur opérationnel.

À ce niveau-là le harness n'est plus une couche de confort, c'est une couche de sécurité. Les permissions, les validations, les journaux, les secrets, les environnements isolés, les droits temporaires, les limites par canal, les seuils d'approbation humaine, tout cela devient central. Chaque canal devient une frontière de confiance, et plus le cerveau fait bouger ses mains loin, plus le système nerveux qui les contrôle doit être solide. On ne peut pas demander à un agent d'agir loin sans construire précisément ce qui l'empêche d'aller trop loin. Un agent mal configuré peut faire des dégâts comme n'importe quel système disposant d'un accès étendu, indépendamment du modèle qu'il utilise.

L'autonomie tenue

On parle trop souvent d'autonomie comme s'il s'agissait d'une valeur en soi. Un agent autonome impressionne parce qu'il donne l'impression que l'humain peut disparaître de la boucle. Mais qui agit seul, se trompe seul également.

La bonne question n'est donc pas jusqu'où peut-on rendre l'agent autonome, mais jusqu'où peut-on lui faire confiance sans perdre la maîtrise. C’est la différence entre autonomie brute et autonomie tenue. Tenue, parce que la mémoire l'empêche de dériver, les permissions bornent ses gestes, les journaux gardent trace de ce qu'il fait et parce que le système sait distinguer ce qui est normal de ce qui doit attendre une validation humaine.

C'est cela, le harness engineering. Ni un meilleur prompt, ni un meilleur modèle, ni dix outils de plus, mais l'environnement dans lequel un cerveau peut faire bouger ses mains sans devenir flou, lourd, risqué ou impossible à maintenir.

Tenir trente jours

Les agents IA vont continuer à progresser. Les modèles comprendront mieux et corrigeront plus finement leurs propres erreurs. Mais dans les usages professionnels, la différence ne se fera pas uniquement sur le cerveau, elle se fera sur ce qui l'entoure, sur la manière dont le harness tient ensemble la mémoire, les accès et la sécurité quand l'usage s'étire dans le temps.

La vraie frontière n'est pas l'agent qui réussit une démo, c'est l'agent qui reste fiable au bout de trente jours d'usage réel. Et cette frontière-là ne relève pas seulement de l'IA, elle relève de l'architecture.