L'ingénierie du « harness » consiste à développer l'infrastructure, y compris le code, qui transforme un modèle d'IA, à l'origine un simple générateur de texte, en un agent capable d'agir. En résumé, un agent IA est constitué d'un modèle et d'un « harness ». Le modèle décide de la prochaine action à entreprendre, et le « harness » la met en œuvre, en reliant le modèle aux outils, au contexte, aux systèmes externes et aux mécanismes de validation. Dans de nombreux cas concrets, et en particulier dans le domaine de la sécurité, c’est le « harness » qui détermine davantage la qualité du résultat que le choix du modèle.
Qu'est-ce qu'un harnais ?
Un « harness » est la couche d’orchestration qui entoure un modèle, voire plusieurs modèles à la fois. Il s’agit d’un ensemble cohérent de code, de logique de workflow, de conception de prompts et de validation, au sein duquel le modèle s’intègre comme l’un des composants parmi d’autres. Le « harness » contient la logique qui détermine quel modèle s’exécute à quel moment, quel contexte est présenté à chacun d’entre eux, comment les résultats sont vérifiés et quand il convient de passer à un modèle plus puissant.
Dans sa forme la plus simple, un « harness » est une courte boucle de code :
- Appeler le modèle
- Le modèle demande un outil
- Harness exécute l'outil et renvoie le résultat
- Répétez l'opération jusqu'à l'obtention des résultats définitifs
À mesure que les faisceaux de câbles gagnent en complexité, ils intègrent souvent certains des schémas suivants :
- Enchaînement d'instructions : étapes séquentielles entrecoupées de vérifications, pour une tâche qui se décompose selon un ordre fixe.
- Routage : un classificateur achemine chaque entrée vers un gestionnaire spécialisé, et envoie les requêtes simples vers un modèle moins coûteux, tout en réservant les requêtes complexes à un modèle plus performant.
- Parallélisation: soit en divisant une tâche en parties indépendantes, soit en exécutant plusieurs fois la même tâche puis en regroupant les résultats.
- Orchestrator-workers : un modèle centralisé divise la tâche à la volée et la délègue, pour les travaux dont on ne peut pas prédire les sous-tâches à l'avance.
- Évaluateur-optimiseur : un modèle génère des résultats tandis qu'un autre les évalue, dans une boucle qui se répète jusqu'à ce que le résultat soit validé.
Le « harness » est également souvent à l’origine du « compactage », processus qui consiste à condenser de longs historiques de conversation ou des transcriptions en résumant les messages les plus anciens en un bloc de texte dense. La gestion correcte de la fenêtre de contexte d’un LLM a également un impact majeur sur la qualité et la sécurité des résultats, ce qui a donné naissance à un nouveau sujet d’actualité : l’ingénierie du contexte (que nous aborderons une autre fois).
Pourquoi a-t-on besoin d'un harnais ?
Si vous hésitez entre plusieurs modèles, vous ne modifiez en réalité qu’une seule variable. Les modèles Frontier ont atteint un tel niveau de convergence que l’écart entre les meilleurs d’entre eux, sur les benchmarks de codage standard, est relativement faible. Cependant, si vous intégrez ce même modèle dans un « harness » faible plutôt que dans un « harness » fort, la différence dans les résultats obtenus est considérable. Dans de nombreux cas, la conception du « harness » aura davantage d’impact sur la qualité des résultats que le modèle lui-même.
En réduisant la dépendance vis-à-vis d’un modèle spécifique, vous pouvez vous adapter à l’évolution des temps. Les modèles « frontier » font l’objet d’une surveillance accrue ces derniers temps et perdent en popularité auprès de certains. Lors de l’incident Hugging Face-OpenAI de juillet 2026, un modèle « frontier » a attaqué une entreprise, mais celle-ci n’a pas pu utiliser un modèle « frontier » pour se défendre, car ces modèles bloquent régulièrement les tâches liées à la cybersécurité. Hugging Face a dû recourir à un modèle chinois à poids ouverts pour sa réponse à l’incident (les modèles à poids ouverts affichent heureusementde très bonnes performances ces derniers temps). Être à la merci du refus des modèles n’est pas une stratégie viable à long terme.
Même un modèle performant ne peut pas exécuter cette tâche de manière autonome. Si vous demandez au « meilleur » modèle qui soit, dans une fenêtre de chat, de détecter les vulnérabilités d’un dépôt, vous vous heurterez très rapidement à des limites. D’une part, la base de code ne tiendra pas dans son contexte, et même pour les parties qu’il parvient à voir, il ne peut pas vraiment établir de liens entre les différents fichiers. Et bien sûr, les résultats varieront à chaque fois, car ils sont non déterministes. Pour détecter efficacement les vulnérabilités, un harnais doit exécuter une boucle en continu et vérifier les résultats renvoyés. Dans nos tests de performance des derniers modèles d’IA, nous montrons pourquoi le harnais est si important pour détecter les vulnérabilités dans le code, et en quoi une vérification de l’accessibilité et une étape de validation permettent de distinguer une liste de « peut-être » d’une liste sur laquelle vous pouvez agir.
Il y a également un aspect financier à prendre en compte. Les modèles plus volumineux coûtent plus cher par exécution, et leurs performances ne sont pas proportionnelles à leur prix. Utiliser plusieurs agents moins coûteux peut s'avérer plus efficace qu'un seul agent onéreux pour un budget identique, car le nombre d'agents permet d'étendre la couverture. Un modèle moins coûteux génère (généralement) davantage de faux positifs ; un système de gestion peut donc coordonner les différentes exécutions et filtrer le bruit, tandis que des agents distincts valident les résultats et éliminent les données inutiles.
Et lorsque le travail touche à des sujets sensibles, le harnais est le seul endroit où la sécurité peut trouver sa place. Se contenter d’inviter un modèle à se protéger ne suffit pas (nous y reviendrons plus tard).
Quels sont les exemples d'utilisation de l'IA ?
Pratiquement tous les modèles LLM utilisés comme produit s'inscrivent dans un cadre d'application. Un exemple simple : tous les agents de programmation qui ont pris le relais des flux de travail des développeurs ces deux dernières années sont des cadres d'application construits autour d'un modèle de pointe.
Claude Code est l'agent terminal d'Anthropic. Il lit et écrit du code en suivant la même boucle « appel-modèle-exécution-outil » décrite ci-dessus. La boucle d'agent sous-jacente choisit les outils, accumule le contexte et gère les longues sessions grâce à la compaction, les modes d'autorisation et le sandboxing définissant les limites de sécurité. Le mode agent de Cursor repose sur le même principe au sein d'un éditeur axé sur l'IA et basé sur VS Code, où le harnais pilote l'édition de plusieurs fichiers depuis l'IDE plutôt que depuis le terminal.
Le « harnais » le plus célèbre est sans doute OpenClaw, même si l’on peut considérer qu’il a désormais dépassé le simple cadre d’un « harnais ». En réalité, il s’agit d’un service Node.js fonctionnant en continu qui relie un LLM à votre Mac Mini et à vos applications de messagerie. Il fournit la passerelle, les canaux, l’assemblage du contexte, la mémoire persistante, les compétences et la boucle qui les relie entre eux. OpenClaw constitue également un exemple édifiant de la faiblesse de la sécurité lorsque le harnais est mal conçu et que le bac à sable est pratiquement inexistant (nous y reviendrons dans un instant).
Pour un exemple concret et détaillé, Cloudflare a publié étape par étape son cadre de découverte de vulnérabilités, développé en appliquant des modèles de sécurité à des dizaines de ses propres dépôts. Ces étapes donnent une bonne idée de tout ce que fait un cadre abouti, en particulier dans un contexte de sécurité. Notre propre cadre, disponible à l’adresse Aikido , présente des similitudes à un niveau général : il explore une base de code à la recherche de points d’entrée potentiels, classe les flux suspects à examiner, les analyse en profondeur, puis trie les résultats obtenus.
Le rôle du « harnais » dans la sûreté et la sécurité de l'IA
En matière de sécurité, le harnais contribue également, dans une certaine mesure, à contenir le modèle, en le maintenant dans les limites que vous avez définies lorsqu’il s’écarte de sa tâche ou qu’il en est détourné par un élément de ses données d’entrée. Il maintient ces limites souples, qui restent valables tant que votre orchestration se comporte conformément à la manière dont vous l’avez conçue.
Des mécanismes de protection, tels que la limitation de portée et la journalisation, doivent faire partie de la couche d’outils contrôlée par le code. Les grands modèles de langage (LLM) étant non déterministes et donc imprévisibles, même les tentatives les plus ambitieuses visant à les contrôler uniquement à l’aide de prompts ne peuvent garantir la sécurité. L’injection de prompts constitue l’un des principaux problèmes liés à la tentative de contrôle des LLM par ce biais, car toute entrée contrôlée par un attaquant qui parvient à s’introduire dans le contexte peut corrompre le LLM si elle est suffisamment convaincante.
Les contrôles de sécurité couverts par le harnais comprennent :
- Contrôle de la portée : règles définissant les limites d'accès, telles que les domaines, les hôtes ou les dépôts auxquels un agent est autorisé à accéder, et interdisant toute action en dehors de ce cadre. Dans un harnais, cela se présente sous la forme d'une liste blanche qui vérifie l'exécution du code avant le lancement d'un outil, ainsi que d'instructions de portée dans l'invite de commande.
- Médiation des outils : le harnais détermine quels outils existent, quels arguments sont autorisés et si un appel donné peut être exécuté. Le modèle peut uniquement demander un outil ; c'est le code du harnais qui décide de l'exécuter ou non.
- Contexte et traitement des données d'entrée : mesures de protection contre l'injection de commandes et les contenus non fiables, telles que le filtrage ou la mise en quarantaine des données externes, la limitation des informations lues par le modèle et l'interdiction de lui fournir du contenu provenant d'Internet ouvert dont il pourrait tirer des instructions.
- Validation et vérification : contrôles indépendants des résultats produits par le modèle, par exemple un deuxième agent cherchant à réfuter une conclusion, un contrôle d'accessibilité ou une validation du schéma sur les résultats. Cela permet de détecter le bruit et les « hallucinations ».
- Logique d'escalade et de routage : règles déterminant quand confier une tâche à un modèle plus performant, quand faire appel à un intervenant humain et quand mettre fin au traitement. Les mécanismes de protection et les conditions d'arrêt sont également définis ici.
- Journalisation et observabilité : enregistrement de chaque requête et de chaque action afin de pouvoir suivre une exécution en temps réel, la mettre en pause ou l'auditer. Ce contrôle vous permet d'intervenir si nécessaire.
- Gestion des débits et des ressources au niveau de l'application : limitation des débits et prise en compte de la charge afin d'éviter que les agents ne saturent une cible ou ne génèrent des coûts excessifs.
Dans certains cas, les agents se trouvent dans un bac à sable, généralement lorsqu’ils interagissent avec des systèmes en production ou sont autorisés à exécuter des commandes shell. Le bac à sable est le conteneur dans lequel s’exécute l’ensemble du harnais et qui assure l’application stricte des mesures de sécurité, notamment l’isolation du système d’exploitation, les restrictions réseau, les limites de ressources et la séparation par rapport à votre infrastructure interne. Ces limites étant imposées par l’environnement, le modèle ne peut pas les franchir, quelles que soient ses actions.
Anecdote : il est également possible d'imbriquer des « sandboxes » au sein du harnais. Si le harnais fournit au modèle un outil permettant d'exécuter des commandes, celles-ci peuvent être exécutées dans leur propre « sandbox » distincte. Ainsi, une fonctionnalité à risque se voit attribuer une limite stricte sans pour autant compromettre le reste du système.
L'IA au service de la sécurité dans le monde réel
Deux cas récents illustrent ce qui se passe lorsque ces limites ne sont plus respectées, de différentes manières. OpenClaw montre ce qui se passe lorsque la limite stricte fait tout simplement défaut. L'incident impliquant Hugging Face et OpenAI montre ce qui se passe lorsqu'elle est bien en place mais qu'elle est franchie.
OpenClaw illustre comment cela se traduit lorsque le choix des couches est laissé à l’utilisateur. Il est livré avec les contrôles de harnais, mais considère le bac à sable comme une option à activer ; par défaut, la session principale s’exécute directement sur la machine hôte avec un accès complet à ses identifiants et à ses fichiers. Le bac à sable ne couvre que les sessions pour lesquelles il est configuré, et même dans ce cas, certains outils sont marqués pour s’exécuter de toute façon sur l’hôte. Ainsi, OpenClaw est généralement utilisé avec un harnais performant doté de garde-fous souples, mais sans limite stricte en arrière-plan, ce qui est précisément la configuration à l’origine de ses incidents les plus graves. Un harnais sans bac à sable n’offre un niveau de confinement que dans la mesure où ses contrôles souples tiennent bon, et face à un modèle non déterministe, ceux-ci ne tiennent pas toujours.
L'incident impliquant Hugging Face et OpenAI que j'ai évoqué plus tôt est un excellent (ou pas si excellent que ça) exemple de défaillance de la sécurité de l'infrastructure entourant un modèle puissant. OpenAI a révélé que, lors d'une exécution interne d'un test de performance, ses propres modèles avaient échappé au bac à sable de test et avaient accédé aux systèmes de production de Hugging Face pour récupérer les réponses du test.
Cet incident montre ce qui se passe lorsque le jugement du modèle lui-même et le système qui l’entoure sont tous deux compromis simultanément. Le modèle d’OpenAI fonctionnait avec les « cyber-refus » désactivés : c’est-à-dire que le modèle ou les agents refusaient d’exécuter une action demandée, en se basant sur leur apprentissage plutôt que sur des règles externes. Cela s’explique par les tests qu’OpenAI cherchait à mener, mais cela engendre également de graves risques de sécurité. Dans cet incident, c’était au système environnant, et non à une consigne, qu’incombait l’entière responsabilité de contenir ces agents — à savoir le « harness » et le « sandbox » —, et ces deux éléments ont échoué.
Même OpenAI, qui a tenté de mettre en place un environnement de test sécurisé, a été compromis par un seul système de registre de paquets vulnérable et accessible. Il s'agit bien sûr d'un exemple extrême, mais les modèles ne cesseront de gagner en intelligence, et vous devrez en tenir compte dans votre environnement de test.
La solution technique doit être architecturale et à plusieurs niveaux. Il faut évaluer les risques liés à tout ce à quoi l'agent a accès. C'est ainsi que nous avons conçu notre infrastructure pour nos agents « pentest IA ». Le système sépare la partie qui planifie, raisonne et stocke les données sensibles (le plan de contrôle) d'un environnement isolé (sandbox) qui exécute des outils, pilote les navigateurs et interagit avec le réseau (le plan d'exécution), grâce à des politiques réseau rigoureuses et à des logiciels adaptés.
Le volet « exécution » n’a pas accès aux secrets d’orchestration ni à l’infrastructure interne, car on part du principe que l’exécution peut présenter des comportements indésirables et que le cadre de test ne peut pas tout contenir. C’est là qu’intervient le bac à sable. La politique de sécurité stricte bloque tout domaine ne figurant pas sur la liste blanche au niveau du réseau, de sorte que l’agent ne puisse pas y accéder, quelles que soient ses actions.
Les applications de l'IA, aujourd'hui et demain
Le modèle attire l'attention, mais c'est le « harness » qui fait le gros du travail. C'est lui qui transforme les capacités en résultats optimaux, tout en gérant de nombreux contrôles de sécurité. Les grandes entreprises technologiques se concentrent sur les « harnesses », tant pour un usage interne qu'en tant que service. Microsoft a récemment lancé un framework de « harness » sous forme de produit. Tant que nous disposerons de modèles de langage grand format (LLM), nous continuerons à les encadrer à l'aide de « harnesses » ; cette discipline n'en est donc qu'à ses débuts. Nous n'avons fait qu'effleurer le sujet dans cet article, mais vous pouvez également approfondir vos connaissances en IA sur cette superbe page consacrée à l'ingénierie des harnais.
Choisissez bien votre modèle, mais concentrez ensuite tous vos efforts sur le harnais. C’est pourquoi nous fabriquons nos propres outils, notamment ceux de Aikidoanalyse de code par IA et pentest IA, en les concevant d’abord comme des harnais.
FAQ
Qu'est-ce qu'un harnais ?
Un « harness » est la couche d'orchestration qui encadre un ou plusieurs modèles. Il s'agit à la fois du code, de la logique de workflow, de la conception des invites et de la validation qui transforment un modèle en un agent capable d'agir : il détermine quel agent s'exécute à quel moment, quel contexte chacun d'entre eux perçoit, quand il faut faire appel à un niveau supérieur, et comment le résultat est vérifié.
Quelle est la différence entre le harnais et le modèle ?
Le modèle fournit le raisonnement et le langage. Le harnais fournit tout le reste : les outils, la mémoire, la boucle, la validation et certains contrôles de portée. Si vous changez de modèle, le harnais reste inchangé. C'est pourquoi un harnais robuste vous permet de mettre à niveau vos modèles sans avoir à reconstruire votre système.
La conception de harnais est-elle une véritable discipline ?
C'est désormais le cas. À mesure que les modèles de pointe se rapprochent en termes de capacités, c'est l'orchestration qui les entoure qui fait désormais la majeure partie de la différence concrète en termes de résultats ; c'est pourquoi les équipes investissent dans la conception de « harnesses » en tant que domaine de travail à part entière.
En quoi l'ingénierie des harnais s'applique-t-elle à la sécurité ?
En matière de sécurité, le « harness » remplit deux fonctions. D’une part, il améliore la qualité des résultats grâce à une délimitation précise du périmètre d’analyse et à une validation indépendante effectuée par des agents parallèles ; d’autre part, il restreint l’action de l’agent grâce à une isolation architecturale et à l’application des limites de périmètre au niveau du réseau, de sorte qu’un agent ne puisse pas s’introduire dans l’environnement de production ni divulguer de données.
Qu'est-ce que les garde-fous des agents IA ?
Les garde-fous sont les contraintes qui maintiennent un agent dans le périmètre prévu : il s'agit notamment du sandboxing, des domaines autorisés, des limites de débit et d'une séparation stricte entre la couche de planification et la couche d'exécution. Les garde-fous fiables sont mis en œuvre au niveau du code et de l'infrastructure plutôt que d'être demandés via une invite ; ainsi, le modèle ne peut ni les ignorer ni être amené à les contourner.
