Comment fonctionne un harnais agentique pour l’IA

Le modèle n’est qu’une partie de l’agent

Les développeurs peuvent utiliser Claude Code, Codex ou Cursor tout en concentrant l’essentiel de leur attention sur le LLM qui sous-tend l’expérience. Pourtant, tous trois sont des harnesses agentiques propriétaires construits autour de modèles LLM, et le logiciel qui les entoure est responsable d’une grande partie de ce qui rend leur comportement agentique. Son rôle peut se résumer de façon concise ainsi : « Agent = Modèle + Harness ». Le harness peut rester largement invisible tout en déterminant comment la sortie du modèle se transforme en action.

L’équation distingue deux fonctions qui peuvent autrement sembler n’en former qu’une. Un modèle autonome accepte des entrées telles que du texte, des images, de l’audio ou de la vidéo, et produit du texte en réponse. Un agent ajoute un système environnant qui transforme ces réponses en une activité continue et contrôlée. Concevoir un agent utile exige donc des développeurs qu’ils comprennent à la fois le modèle et le système qui relie sa sortie à l’état, aux outils, à l’exécution et à d’autres appels au modèle.

Un harness transforme les réponses du modèle en travail continu

Ce système environnant est le harness agentique, également appelé agent harness ou agentic AI harness. Il relie un LLM à des outils externes, des sources de données, de la mémoire, des environnements d’exécution et des boucles de rétroaction. Ces connexions déterminent ce qui peut se passer après une réponse : le système peut conserver des informations, invoquer une autre ressource, exécuter un travail et renvoyer les résultats pour une nouvelle interaction avec le modèle. Grâce à ce cycle, un agent peut continuer à travailler sur une tâche après sa première réponse générée.

La mémoire montre comment le harness étend le comportement de base d’un modèle. Un agent peut avoir besoin que des informations persistent entre les interactions, et les fichiers mémoire ainsi que les MCP font partie des mécanismes disponibles à cette fin. MCP, ou Model Context Protocol, fournit un moyen aux systèmes d’agents de connecter les modèles à des ressources et outils externes. La persistance permet aux travaux ultérieurs d’utiliser des informations conservées en dehors d’une seule réponse du modèle, donnant à un agent un état continu tout au long de son travail.

Cet état continu devient utile lorsque l’agent peut aussi agir. Pour l’exécution de code, le harness peut fournir un sandbox, un environnement isolé dans lequel le code s’exécute. Pour un travail nécessitant plusieurs cycles, des boucles peuvent renvoyer les résultats d’exécution au système et déclencher des étapes supplémentaires. La boucle permet à un agent de continuer à travailler jusqu’à ce qu’il résolve la tâche donnée, chaque résultat devenant l’entrée de l’étape suivante.

Ces boucles peuvent aussi avoir besoin d’informations absentes de l’interaction en cours. La recherche web offre au harness un moyen de récupérer des données externes et de les rendre disponibles pour un travail ultérieur. Ensemble, la mémoire, les sandboxes, les boucles et la recherche web distinguent la génération du modèle du fonctionnement de l’agent : le modèle produit des réponses, tandis que le harness crée les conditions d’un travail persistant capable de récupérer des informations et d’utiliser des outils.

Une fois ces conditions réunies, le problème d’ingénierie s’élargit avec elles. Un LLM capable de conserver un état, de récupérer des informations externes, d’exécuter du code et de fonctionner sur plusieurs cycles a besoin de règles définissant quelles ressources il peut atteindre et quand il peut les utiliser. C’est dans le harness que les développeurs peuvent mettre en œuvre ces décisions opérationnelles. Son architecture interne montre l’éventail des décisions en jeu.

À l’intérieur du harness : l’architecture qui coordonne un agent

La première préoccupation architecturale concerne l’endroit où les personnes peuvent voir et contrôler l’activité de l’agent. Une interface peut exposer ce que fait l’agent tout en permettant à une personne d’approuver ou d’interrompre des actions. Le contrôle humain devient important lorsqu’une réponse générée peut déclencher d’autres opérations ayant des effets en dehors de la conversation. L’interface donne au jugement humain une place explicite dans ce processus continu.

Derrière l’interface, la couche de prompt et de politique définit les instructions qui régissent le travail de l’agent. Elle peut combiner des instructions système avec des règles métier et des politiques organisationnelles, donnant au harness un endroit où encoder des exigences comportementales. Ces exigences s’appliquent ensuite à l’usage des outils et à l’exécution, là où des décisions générées peuvent avoir des effets au-delà du langage. La couche de politique établit les conditions dans lesquelles le reste du système fonctionne.

Ces conditions dépendent des informations mises à la disposition du modèle ; le gestionnaire de contexte détermine donc ce que le modèle reçoit et à quel moment. Il peut utiliser la compression et d’autres techniques pour organiser les éléments accumulés au cours d’une session, en sélectionnant les informations utiles pour l’étape en cours. Comme le modèle travaille à partir du contexte qui lui est présenté, cette sélection influence sa réponse suivante. La gestion du contexte est donc une partie active de la coordination du travail de l’agent.

Une fois les instructions et le contexte sélectionné disponibles, l’interface du modèle sert d’intermédiaire pour l’accès aux services LLM approuvés. Elle envoie des prompts, du contexte et des paramètres à ces services, puis reçoit leurs réponses. L’interface crée une frontière définie entre le système d’agent et les modèles qu’il peut appeler. Une fois qu’une réponse franchit cette frontière, le harness peut déterminer quelles ressources sont disponibles pour l’opération suivante.

Le registre d’outils définit un ensemble de ces ressources en regroupant les outils et fonctions approuvés que l’agent peut utiliser. L’accès aux outils permet à une décision générée de conduire à une opération externe ; les développeurs doivent donc concevoir explicitement l’ensemble disponible. Le registre fournit cet ensemble défini à l’intérieur du harness. La disponibilité soulève ensuite une question distincte : celle de savoir si l’agent peut effectuer une action particulière.

Cette question relève du système d’autorisations, en particulier lorsqu’une opération disponible est sensible. Les autorisations précisent ce que le modèle peut faire et peuvent imposer des limites plus strictes sur les actions sensibles. Séparer les outils disponibles des actions autorisées permet aux développeurs de gouverner le comportement là où une sortie générée peut produire un effet externe. L’approbation humaine via l’interface peut ajouter un autre contrôle lorsqu’une opération justifie une intervention.

Une fois qu’une action est autorisée, l’environnement d’exécution détermine où elle s’exécute. Le runtime de l’agent entre ici dans l’architecture en fournissant un environnement dans lequel le comportement de l’agent peut se déployer. La coordination et l’exécution sont deux tâches d’ingénierie distinctes, même si elles fonctionnent ensemble pendant une tâche de l’agent. Maintenir cette frontière visible aide aussi à distinguer un harness d’un runtime.

L’exécution peut à son tour nécessiter des informations ou des fonctions extérieures à son environnement immédiat. La couche de connecteurs relie le harness à des sources externes, notamment des référentiels de retrieval-augmented generation (RAG) et des outils activés via MCP. Le RAG récupère des informations pertinentes et les fournit au travail du modèle, tandis que les outils activés par MCP offrent une autre voie vers des ressources externes. Les connecteurs étendent les systèmes qu’un agent peut atteindre tout en maintenant cet accès dans la coordination du harness.

Le travail externe crée également des informations qui peuvent devoir survivre à l’interaction en cours. Le magasin de mémoire et de session préserve la mémoire entre les sessions, permettant à des travaux futurs d’utiliser l’état conservé. Les informations stockées et le contexte du modèle jouent des rôles différents : le magasin peut conserver des éléments d’une session à l’autre, tandis que le gestionnaire de contexte sélectionne ce que le modèle doit recevoir à un moment donné. Cette séparation permet au système de conserver des informations sans injecter automatiquement chaque élément stocké dans chaque appel au modèle.

L’état persistant et les actions externes créent un besoin supplémentaire de redevabilité. Les systèmes d’audit et d’observabilité conservent des enregistrements pour le monitoring, la revue et la réponse aux incidents. À mesure qu’un agent accède à des outils, à des systèmes externes et à des environnements d’exécution, les ingénieurs peuvent avoir besoin d’examiner ce qu’il a fait après une opération. L’observabilité rend cette activité vérifiable sur une séquence d’appels au modèle et d’actions.

Ensemble, ces composants décrivent des responsabilités coordonnées plutôt qu’une séquence d’exécution obligatoire. Le harness peut fournir des prompts, un contexte sélectionné et des paramètres via l’interface du modèle, puis utiliser les réponses renvoyées dans un travail impliquant des outils approuvés, des connecteurs, de la mémoire et un environnement d’exécution. Les autorisations peuvent limiter les actions, des personnes peuvent approuver ou interrompre l’activité, et des mécanismes d’audit peuvent enregistrer les événements. Des boucles de rétroaction peuvent répéter certaines parties de ce processus jusqu’à l’achèvement de la tâche, le chemin exact étant déterminé par la tâche et la conception du système.

La gestion du contexte fait du harness un enjeu d’ingénierie opérationnelle

Au sein de cette architecture, la gestion du contexte a un effet inhabituellement direct sur chaque appel au modèle. Les informations s’accumulent à mesure qu’un agent progresse au fil d’interactions successives, et des éléments mal organisés peuvent rendre une session confuse, coûteuse et sujette aux erreurs. La compression et d’autres techniques de gestion du contexte déterminent quelles informations accumulées restent suffisamment utiles pour être présentées au modèle. Chaque sélection modifie les informations disponibles au moment où la réponse suivante est générée.

Comme chaque réponse dépend de cette sélection, la curation du contexte devient une décision de qualité. Des éléments non pertinents ou mal gérés peuvent interférer avec des preuves et des instructions utiles, tandis qu’une sélection délibérée contrôle ce que le modèle peut utiliser pour son étape suivante. Dans un agent fonctionnant par boucles, la décision se répète à mesure que de nouvelles informations entrent dans le système. L’ingénierie du contexte façonne par conséquent le jugement continu de l’agent tout au long de la tâche.

Cette décision récurrente a aussi un effet sur le coût. À mesure qu’une session non gérée s’allonge, transmettre les éléments accumulés peut accroître les dépenses en même temps que le bruit. Les développeurs qui choisissent ce que le modèle voit gèrent donc à la fois la qualité de ses informations de travail et le coût de leur fourniture. Le harness leur donne un emplacement architectural pour arbitrer ce compromis tout au long du fonctionnement d’un agent.

Les capacités ont besoin de garde-fous : le harness gouverne aussi l’agent

Les choix opérationnels autour du contexte s’ajoutent à un problème de contrôle plus large créé par les capacités de l’agent. Les outils fournissent des fonctions appelables, les connecteurs atteignent des sources externes, et la mémoire conserve des informations entre les interactions et les sessions. Donner ces ressources à un agent exige aussi des décisions sur les actions autorisées et sur les moments où des personnes doivent pouvoir les inspecter, les approuver ou les arrêter. La même couche environnante qui coordonne les capacités peut faire respecter ces limites.

Les contrôles introduits dans l’architecture répartissent cette responsabilité entre plusieurs mécanismes. La couche de prompt et de politique porte les règles métier et les politiques organisationnelles, tandis que les autorisations déterminent quelles actions le modèle peut effectuer. Les contrôles d’interface permettent aux personnes d’approuver ou d’interrompre l’activité, et les enregistrements d’audit soutiennent le monitoring, la revue et la réponse aux incidents. Exposer un outil puissant crée donc une tâche d’ingénierie connexe : spécifier les contrôles qui régissent son utilisation.

L’ajout d’un autre outil ou d’une autre source externe augmente les opérations que le système peut tenter, ce qui peut aussi créer de nouvelles exigences en matière d’autorisations, de supervision et d’inspection. L’ingénierie du harness représente ces exigences sous la forme d’un logiciel entourant le modèle. La sécurité et le contrôle opérationnel deviennent des décisions architecturales liées aux mêmes mécanismes qui permettent le comportement de l’agent.

Framework, harness et runtime correspondent à des fonctions différentes

Ces responsabilités donnent au harness un périmètre large, mais l’infrastructure adjacente conserve des fonctions distinctes. Un framework agentique sert à écrire et construire un agent, un harness agentique sert à le configurer et à l’exécuter, et un runtime fournit l’environnement dans lequel son comportement se déploie. Les exemples cités rendent cette distinction plus facile à comparer.

Le runtime se reconnecte à l’architecture du harness via l’environnement d’exécution où les actions se produisent. Un harness peut coordonner et gouverner l’exécution tandis que le runtime fournit l’environnement dans lequel le comportement de l’agent se déploie. Maintenir les rôles séparés aide les ingénieurs à situer les décisions de contrôle, d’orchestration et d’exécution dans la couche appropriée.

La frontière du framework complète cette répartition des responsabilités. Les frameworks servent à écrire et construire des agents ; les runtimes hébergent leur comportement ; les harnesses coordonnent l’accès au modèle, le contexte, les outils, les autorisations, les connecteurs, la mémoire, les contrôles humains et l’observabilité tout en configurant et en exécutant les agents. Ces systèmes peuvent faire partie de la même stack, mais leurs rôles d’ingénierie restent distincts. Employer les termes avec précision facilite l’identification de l’endroit où une décision opérationnelle donnée doit être prise.

Pour les développeurs, l’ingénierie des agents va au-delà du modèle

Ces distinctions élargissent les compétences pratiques dont les développeurs ont besoin lorsqu’ils intègrent l’IA agentique dans des applications. Le parcours de formation « Integrating AI for Developers » de Pluralsight est un cours vidéo à la demande couvrant les frameworks courants, les stratégies d’orchestration et les considérations de sécurité. Ses cas d’usage incluent l’automatisation des tâches, les assistants et les agents de workflow, chacun exigeant des développeurs qu’ils réfléchissent à la manière dont le comportement du modèle s’inscrit dans une application plus large. Pluralsight a un intérêt commercial dans cette présentation puisqu’elle vend des formations aux développeurs qui veulent acquérir ces compétences.

Cet exemple de formation relie la distinction architecturale au travail de développement quotidien. Une fois qu’un logiciel peut conserver de la mémoire, atteindre des systèmes externes, exécuter des actions et poursuivre son fonctionnement par boucles, les développeurs doivent décider comment orchestrer ces capacités et où placer leurs limites de sécurité. Ce sont des décisions d’architecture applicative mises en œuvre via le système d’agent environnant, et elles exigent des compétences qui vont au-delà du choix d’un LLM ou de la manière de le prompter.

Réflexions finales

Pour les dirigeants d’entreprise, la distinction essentielle est que choisir un LLM n’est pas la même chose que choisir une architecture d’agent. Le modèle fournit l’intelligence de base, mais le harness détermine comment cette intelligence accède aux données de l’entreprise, aux outils, aux workflows et aux environnements d’exécution. Il fournit aussi les contrôles qui définissent ce qu’un agent peut faire, ce qui nécessite une approbation et comment ses actions peuvent être examinées.

Cela fait du harness un élément important à prendre en compte lors de l’évaluation des plateformes et des investissements en IA agentique. Les dirigeants doivent regarder au-delà des performances du modèle pour examiner l’architecture environnante en matière de gestion du contexte, d’autorisations, de mémoire, d’observabilité et de supervision humaine. Ces capacités influencent le coût d’exploitation, le risque et l’efficacité avec laquelle un agent peut accomplir un travail utile au sein des systèmes existants.

À mesure que les organisations passent des assistants IA à des agents capables d’agir, ces systèmes environnants deviennent plus déterminants. La stratégie d’agent la plus solide prendra en compte les deux côtés de l’équation : ce que le modèle peut générer et la manière dont le harness transforme ces sorties en opérations métier contrôlées et observables.