Qu’est-ce qu’un harnais d’agent IA ?

Le mot circule dans presque toutes les annonces d’IA agentique depuis le début de l’année, mais il est rarement accompagné d’une définition. Un harnais d’agent, ou harness en anglais, désigne l’infrastructure logicielle qui entoure un modèle de langage et le transforme en agent capable d’agir. Après le MCP et l’Open Knowledge Format, c’est la couche qui restait à nommer, celle qui fait tourner l’agent. On vous explique.

Pourquoi un modèle de langage ne suffit pas à faire un agent

Un modèle de langage est sans état. Livré à lui-même, il produit du texte et rien d’autre. Il n’exécute aucune action, ne conserve rien d’une session à l’autre et ne vérifie pas son propre travail. Le harnais prend en charge tout le reste. La formule qui s’est imposée cette année résume ce partage des rôles : agent = modèle + harnais.

En pratique, le modèle lit son contexte et décide de l’action suivante. Le harnais, lui, l’exécute, en lançant un outil ou du code, puis lui renvoie le résultat sous forme de nouveau contexte. La boucle se répète jusqu’à ce que la tâche soit terminée. Le schéma n’a rien de neuf. Il avait été formalisé par le cadre de recherche ReAct, tandis que la capacité d’un modèle à appeler des outils externes avait été démontrée par Toolformer. Le vocabulaire du harnais est arrivé bien après les mécanismes qu’il désigne.

Cette couche pèse désormais aussi lourd que le modèle dans le basculement vers l’IA agentique. Comme il l’expliquait à VivaTech, Thibault Sottiaux, d’OpenAI, place les deux sur le même plan : « Un très bon modèle, un bon harness, on combine les deux » pour obtenir un bon agent.

Ce que contient concrètement un harnais

Les harnais en production reposent sur les mêmes briques, chacune conçue pour compenser une limite du modèle brut :

Le prompt système : le jeu d’instructions permanent qui fixe le rôle de l’agent, son objectif et ses règles, avant toute saisie de l’utilisateur ou de l’utilisatrice.
Les outils et leur exécution : le modèle choisit l’outil à appeler, le harnais l’exécute et lui renvoie le résultat. La connexion à ces ressources passe souvent par le MCP.
Le bac à sable : un espace isolé où l’agent exécute du code sans toucher au système réel et que l’on peut surveiller ou réinitialiser.
La mémoire et la gestion du contexte : le harnais décide ce qui reste actif et ce qui doit être résumé, une opération appelée « compactage de contexte ».
Les boucles de vérification : lancer des tests, inspecter les résultats, faire relire au modèle sa propre production avant de poursuivre.
Les garde-fous : les autorisations, les politiques et la validation humaine exigée avant une action irréversible, comme la suppression d’un fichier ou un achat.
L’observabilité : les journaux et les traces qui permettent de savoir ce que l’agent a fait et pourquoi, souvent une exigence de conformité dans les secteurs régulés.

Tout cela n’arrive pas forcément d’un bloc. Birgitta Böckeler, de Thoughtworks, distingue le « harnais interne », fourni par l’éditeur avec son outil de codage ou son kit de développement, du « harnais externe » que l’utilisateur assemble par-dessus, à base de fichiers d’instructions, de serveurs MCP ou de compétences personnalisées. Elle sépare aussi les guides, qui orientent l’agent avant qu’il n’agisse, des capteurs, qui observent le résultat et rendent l’auto-correction possible.

Certains éditeurs livrent désormais un harnais préassemblé. Microsoft en propose un dans son Agent Framework, avec le suivi de tâches, le compactage, l’approbation des appels d’outils et l’observabilité activés par défaut, ainsi qu’une série d’options pour désactiver ce dont l’application n’a pas besoin.

Harnais d’agent et harnais d’évaluation, deux choses différentes

Le mot vient du test logiciel, où un harnais de test entoure un composant pour le mettre à l’épreuve. Cet héritage entretient une confusion fréquente avec le harnais d’évaluation, qui sert à mesurer les performances d’un modèle sur un jeu de tâches. La différence tient à la temporalité : le harnais d’agent agit pendant la tâche, le harnais d’évaluation mesure après coup.

Ce que ça change pour les professionnels du digital

Le harnais est devenu une discipline, avec son nom. Après le prompt engineering, qui optimise une interaction, et le context engineering, qui régit l’information vue par le modèle à un instant donné, le harness engineering conçoit l’ensemble de l’environnement autour du modèle et englobe les deux précédents. Le vocabulaire s’est installé au début de 2026 et sa paternité reste disputée.

La conséquence pratique, elle, est directe. Choisir son harnais devient une décision distincte de choisir son modèle. Selon Databricks, un harnais solide autour d’un modèle de milieu de gamme peut faire mieux qu’un harnais faible autour d’un modèle plus puissant. Et la plupart des défaillances constatées en production viennent du harnais plutôt que du modèle, à commencer par un contexte qui se dégrade à mesure que la conversation s’allonge ou des garde-fous absents sur les actions irréversibles. Des travaux publiés par Nvidia fin août vont dans le même sens sur les tâches longues.

La frontière reste mouvante. À mesure que les modèles planifient et corrigent mieux leur propre travail, une partie des tâches assurées aujourd’hui par le harnais devrait remonter dans le modèle lui-même. Databricks l’anticipe sans y voir la fin de la discipline, puisque les environnements d’exécution, l’orchestration des outils et les garde-fous continueront de décider si un modèle tient ou non en production.