Le harness engineering consiste à concevoir la couche logicielle qui transforme un modèle d'IA, simple générateur de texte, en un agent capable d'agir. En somme, un agent IA est l'association d'un modèle et d'un harness. Le modèle décide de la marche à suivre et le harness l'exécute, en connectant le modèle aux outils, au contexte, aux systèmes externes et aux mécanismes de validation. Dans de nombreux cas pratiques, et en particulier en matière de sécurité, c'est le harness qui détermine la qualité des résultats, bien plus que le choix du modèle.
Qu'est-ce qu'un harness ?
Un harness est la couche d'orchestration autour d'un modèle, ou de plusieurs modèles simultanément. Il s'agit d'une combinaison de code, de logique de flux de travail, de conception de prompts et de validation, au sein de laquelle le modèle n'est qu'un composant parmi d'autres. Le harness héberge la logique qui détermine quel modèle s'exécute et quand, quel contexte chacun perçoit, comment les résultats sont vérifiés et à quel moment faire appel à un modèle plus puissant.
Au plus simple, un harness se résume à une courte boucle de code :
- Appeler le modèle
- Le modèle demande l'utilisation d'un outil
- Le harness exécute l'outil et renvoie le résultat
- Répéter l'opération jusqu'à l'obtention des résultats finaux
À mesure que les harness se complexifient, ils adoptent souvent les schémas suivants :
- Chaînage de prompts : Des étapes séquentielles entrecoupées de vérifications, adaptées aux tâches divisibles dans un ordre fixe.
- Routage : Un classificateur achemine chaque entrée vers un gestionnaire spécialisé, dirigeant les requêtes simples vers un modèle économique et réservant les plus complexes à un modèle plus puissant.
- Parallélisation : Division d'une tâche en parties indépendantes ou exécution répétée d'une même tâche suivie d'une agrégation des votes.
- Orchestrateur-travailleurs : Un modèle central répartit la charge à la volée et délègue les sous-tâches, utile lorsque celles-ci ne peuvent pas être anticipées.
- Évaluateur-optimiseur : Un modèle génère le contenu tandis qu'un autre le critique en boucle jusqu'à ce que le résultat soit validé.
Le harness est également souvent responsable de la compaction, un processus qui condense des historiques de conversation ou des transcriptions de grande taille en résumant les messages plus anciens dans un bloc de texte dense. Gérer correctement 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 brûlant : l'ingénierie du contexte (que nous aborderons une prochaine fois).
Pourquoi vous avez absolument besoin d'un harness
Si vous devez choisir entre plusieurs modèles, vous ne réglez qu'une seule variable. Les modèles de pointe ont convergé au point où l'écart entre les meilleurs sur les benchmarks de codage standard est relativement faible. En revanche, si vous enveloppez ce même modèle dans un harness faible par rapport à un harness robuste, la différence en matière de détection réelle est considérable. Dans de nombreux cas, la conception du harness aura un impact plus important sur la qualité des résultats que le modèle lui-même.
Moins dépendre d'un modèle spécifique vous permet de vous adapter aux évolutions. Les modèles de pointe font l'objet d'un examen minutieux ces derniers temps et perdent la faveur de certains. Lors de l'incident entre Hugging Face et OpenAI en juillet 2026, un modèle de pointe a attaqué une entreprise, mais celle-ci n'a pas pu utiliser de modèle de pointe pour se défendre, car ces derniers bloquent régulièrement les tâches liées à la cybersécurité. Hugging Face a dû utiliser un modèle chinois à poids ouverts pour répondre à l'incident (heureusement, les modèles à poids ouverts affichent de très bonnes performances de nos jours). Rester à la merci des refus des modèles n'est pas une stratégie viable pour l'avenir.
Un modèle performant ne peut pas non plus exécuter la tâche de manière autonome. Si vous demandez ne serait-ce qu'au « meilleur » modèle dans une fenêtre de chat de trouver les vulnérabilités d'un dépôt, vous atteindrez rapidement vos limites. D'une part, la base de code ne tiendra pas dans son contexte, et même pour les parties visibles, il ne pourra pas vraiment relier les idées entre les différents fichiers. De plus, les résultats varieront à chaque fois car ils sont non déterministes. Pour identifier efficacement les vulnérabilités, un harness doit maintenir une boucle d'exécution et vérifier les retours. Dans nos benchmarks des derniers modèles d'IA, nous montrons pourquoi le harness est si crucial pour détecter les failles de code, et comment une vérification d'accessibilité ainsi qu'une phase de validation permettent de séparer une simple accumulation d'hypothèses d'une liste exploitable.
Il y a aussi un argument financier. Les modèles plus volumineux coûtent plus cher par exécution, et les compétences ne progressent pas de manière linéaire avec le prix. Faire tourner plusieurs agents moins onéreux peut surpasser un agent coûteux pour un budget équivalent, dans la mesure où vous pouvez transformer le nombre d'agents en couverture. Un modèle moins cher génère (généralement) davantage de faux positifs ; un harness peut donc gérer ces exécutions multiples et filtrer le bruit, des agents distincts se chargeant de valider les découvertes et d'éliminer les faux éléments.
Et lorsque le travail touche à des éléments sensibles, le harness constitue le seul rempart possible en matière de sécurité. Se contenter de demander à un modèle d'être sécurisé ne suffit pas (nous y reviendrons plus tard).
Quels sont quelques exemples de harnesses d'IA ?
Pratiquement tous les LLM utilisés comme produits reposent sur un harness. Exemple simple : tous les agents de codage qui ont transformé les flux de travail des développeurs ces deux dernières années sont des harnesses enveloppant un modèle de pointe.
Claude Code est l'agent en ligne de commande d'Anthropic. Il lit et écrit du code en s'appuyant sur la même boucle d'appel du modèle, d'exécution et d'utilisation d'outils mentionnée précédemment. La boucle agentique sous-jacente sélectionne les outils, accumule le contexte et gère les sessions longues par le biais de la compaction, tandis que les modes d'autorisation et le sandboxing définissent les limites de sécurité. Le mode agent de Cursor repose sur le même principe au sein d'un éditeur conçu pour l'IA et bâti sur VS Code, où le harness pilote l'édition de plusieurs fichiers directement depuis l'IDE plutôt que depuis le terminal.
Le harness le plus célèbre est sans doute OpenClaw, bien que l'on puisse dire qu'il a évolué au-delà d'un simple harness. Sous le capot, il s'agit d'un service Node.js persistant qui connecte un LLM à votre Mac Mini et à des applications de messagerie. Il fournit la passerelle, les canaux, l'assemblage du contexte, la mémoire persistante, les compétences et la boucle qui lie le tout. OpenClaw sert également en quelque sorte d'avertissement quant aux risques d'une sécurité dégradée lorsque le harness fait preuve de laxisme et que le sandbox est pour ainsi dire inexistant (nous y reviendrons prochainement).
Pour un exemple détaillé et concret, Cloudflare a publié étape par étape son harness de découverte de vulnérabilités, conçu en soumettant des dizaines de ses propres dépôts à des modèles de sécurité. Ces étapes offrent un bon aperçu de tout ce qu'un harness mature permet d'accomplir, en particulier dans un contexte de sécurité. Notre propre harness chez Aikido adopte une approche similaire à haut niveau : repérage des points d'entrée potentiels dans une base de code, classement des flux suspects à explorer, analyse approfondie de chacun d'eux, puis triage des résultats.
Le rôle du harness dans la sécurité et la sûreté de l'IA
En matière de sécurité, le harness a également pour responsabilité partielle de contenir le modèle, en le maintenant dans les limites que vous avez fixées lorsqu'il s'éloigne de sa tâche ou qu'il en est détourné par des éléments de ses données d'entrée. Il établit des frontières souples qui tiennent tant que votre orchestration fonctionne comme vous l'avez conçue.
Des garde-fous tels que la délimitation du périmètre et la journalisation doivent faire partie de la couche d'outils contrôlée par le code. Les LLM étant non déterministes et donc imprévisibles, les tentatives les plus héroïques visant à les maîtriser uniquement par le biais de prompts ne peuvent garantir la sécurité. L'injection de prompt constitue l'un des problèmes majeurs lorsqu'on essaie de contrôler les LLM avec des prompts, car toute entrée contrôlée par un attaquant qui s'immisce dans le contexte peut corrompre le LLM de manière suffisamment convaincante.
Les mesures de sécurité prises en charge par le harness incluent :
- Contrôle du périmètre : Des règles définissant ce qui est autorisé, telles que les domaines, hôtes ou dépôts auxquels un agent a le droit d'accéder, et le refus d'agir en dehors de ceux-ci. Dans un harness, cela se traduit par une liste blanche vérifiant les exécutions de code avant le déclenchement d'un outil, ainsi que par des instructions de périmètre intégrées au prompt.
- Médiation des outils : Le harness détermine quels outils existent, quels arguments sont autorisés et si un appel donné est en droit de s'exécuter. Le modèle peut uniquement formuler une demande d'outil, et c'est le code du harness qui choisit de l'exécuter ou non.
- Gestion du contexte et des entrées : Des contrôles contre l'injection de prompt et les contenus non fiables, comme le nettoyage ou la mise en quarantaine des données externes, la limitation de ce que le modèle lit, et l'exclusion de contenus provenant de l'Internet ouvert qui pourraient influencer ses instructions.
- Validation et vérification : Des contrôles indépendants sur ce que produit le modèle, tels qu'un second agent essayant d'invalider une découverte, une vérification d'accessibilité ou une validation de schéma sur la sortie. Cela permet de filtrer le bruit et les hallucinations.
- Logique d'escalade et de routage : Des règles régissant le moment où une tâche doit être confiée à un modèle plus puissant, celui où l'intervention d'un humain est requise et celui où il faut s'arrêter. Les coupe-circuits (circuit-breakers) et les conditions d'arrêt se trouvent également ici.
- Journalisation et observabilité : L'enregistrement de chaque requête et action afin qu'une exécution puisse être surveillée en direct, mise en pause ou auditée. Ce contrôle vous permet d'intervenir en cas de besoin.
- Gestion des quotas et des ressources au niveau de l'application : La limitation du débit (rate-limiting) et la prise en compte de la charge pour éviter que les agents ne s'acharnent sur une cible ou n'entraînent des coûts excessifs.
Dans certains cas, les agents sont exécutés dans un sandbox, généralement lorsqu'ils interagissent avec des systèmes de production ou qu'ils sont autorisés à exécuter des commandes shell. Le sandbox est le conteneur dans lequel s'exécute l'ensemble du harness et qui assure l'application rigoureuse de la sécurité, incluant l'isolation au niveau de l'OS, les restrictions réseau, les limites de ressources et la séparation d'avec votre infrastructure interne. Ces limites étant garanties par l'environnement, le modèle ne peut pas les franchir, quelles que soient ses actions.
Le saviez-vous ? Vous pouvez également imbriquer des sandboxes au sein du harness. Si le harness fournit au modèle un outil qui exécute des commandes, ces commandes peuvent s'exécuter dans leur propre sandbox distinct, conférant ainsi une isolation rigoureuse à une fonctionnalité risquée sans pour autant assouplir le reste du système.
Sécurité des orchestrateurs d'IA dans le monde réel
Deux cas récents illustrent de différentes manières ce qui se produit lorsque ces frontières cèdent. OpenClaw montre ce qu'il advient lorsqu'une barrière rigide est tout bonnement absente. L'incident impliquant Hugging Face et OpenAI met en lumière les conséquences d'une brèche au sein d'une barrière pourtant existante.
OpenClaw démontre les répercussions lorsque la gestion des couches est laissée à la discrétion de l'utilisateur. La solution intègre des mécanismes d'orchestration, mais traite l'isolation par sandbox comme une option à activer. Par défaut, la session principale s'exécute directement sur la machine hôte, bénéficiant d'un accès total à ses identifiants et fichiers. L'isolation ne s'applique qu'aux sessions pour lesquelles elle a été configurée, et même dans ce cas, certains outils sont explicitement autorisés à s'exécuter sur l'hôte. Ainsi, l'utilisation courante d'OpenClaw repose sur un orchestrateur puissant doté de garde-fous souples, sans barrière rigide sous-jacente — une configuration à l'origine de ses incidents les plus graves. Sans sandbox, le niveau de confinement d'un orchestrateur dépend entièrement de la robustesse de ses contrôles souples, lesquels s'avèrent parfois insuffisants face à un modèle non déterministe.
L'incident entre Hugging Face et OpenAI mentionné précédemment illustre parfaitement (ou presque) la défaillance de la sécurité au sein de l'infrastructure entourant un modèle puissant. OpenAI a révélé qu'au cours de l'évaluation interne d'un benchmark, ses propres modèles s'étaient échappés de la sandbox de test pour accéder aux systèmes de production de Hugging Face et en extraire les réponses.
Cet incident met en évidence les conséquences d'une défaillance simultanée du jugement du modèle et du système qui l'environne. Le modèle d'OpenAI fonctionnait alors avec la désactivation des refus de cybercriminalité, un mécanisme par lequel le modèle ou les agents déclinent une requête en se fondant sur leur entraînement plutôt que sur des règles externes. Si cette approche se justifiait pour les tests menés par OpenAI, elle engendre toutefois d'importants risques de sécurité. Dans ce cas précis, le système environnant — à savoir l'orchestrateur et la sandbox — était entièrement responsable du confinement de ces agents, suppléant ainsi le prompt, mais l'un comme l'autre ont fait défaut.
Même OpenAI, qui s'est efforcé de mettre en place une sandbox sécurisée, a vu son système compromis par l'intermédiaire d'un simple registre de paquets vulnérable et accessible. Il s'agit certes d'un cas extrême, mais les modèles ne cessent de gagner en sophistication, et votre sandbox devra nécessairement intégrer cette réalité.
Sur le plan conceptuel, la réponse doit être architecturale et multicouche. Il convient d'évaluer le risque associé à l'ensemble des éléments accessibles à l'agent. C'est précisément de cette manière que nous avons conçu notre orchestrateur destiné à nos agents de pentest IA. Le système sépare le composant chargé de la planification, du raisonnement et du stockage des données sensibles (le plan de contrôle) d'une sandbox isolée exécutant les outils, pilotant les navigateurs et interagissant avec le réseau (le plan d'exécution), le tout appuyé par des politiques réseau strictes et des solutions logicielles adaptées.
La partie exécution n'a aucun accès aux secrets d'orchestration ni à l'infrastructure interne, partant du principe que l'exécution peut se comporter de manière anormale et que l'orchestrateur ne peut pas tout circonscrire. C'est précisément ici qu'intervient la sandbox. L'application rigoureuse de règles bloque au niveau réseau tout domaine ne figurant pas sur la liste blanche, empêchant l'agent de l'atteindre, quelles que soient ses actions.
Les orchestrateurs d'IA, aujourd'hui et demain
Si le modèle monopolise l'attention, l'orchestrateur accomplit quant à lui un travail considérable. C'est lui qui transforme les capacités brutes en résultats pertinents, tout en gérant de nombreux contrôles de sécurité. Les grandes organisations technologiques concentrent leurs efforts sur les orchestrateurs, tant pour un usage interne qu'en tant que service. Microsoft a récemment publié un framework d'orchestration sous forme de produit. Tant que nous utiliserons des LLM, nous devrons les encadrer au moyen d'orchestrateurs, ce qui signifie que cette discipline n'en est qu'à ses débuts. Cet article ne fait qu'effleurer le sujet, mais vous pouvez approfondir votre apprentissage de l'IA sur cette excellente page dédiée à l'ingénierie des orchestrateurs.
Choisissez judicieusement votre modèle, mais investissez l'essentiel de vos efforts dans l'orchestrateur. C'est pourquoi nous concevons nos propres outils, notamment les fonctionnalités d'analyse de code par IA (AI Code Analysis) et de pentest IA (AI Pentesting) d'Aikido, en donnant la priorité à l'architecture d'orchestration.
FAQ
Qu'est-ce qu'un harness ?
Un orchestrateur constitue la couche d'orchestration entourant un ou plusieurs modèles. Il s'associe au code, à la logique de workflow, à la conception des prompts et à la validation pour transformer un modèle en un agent capable d'agir — en déterminant quel agent s'exécute à quel moment, quel contexte est visible par chacun, quand procéder à une escalade et de quelle manière les résultats sont vérifiés.
Quelle est la différence entre l'orchestrateur et le modèle ?
Le modèle fournit le raisonnement et les capacités linguistiques. L'orchestrateur prend en charge tout le reste : les outils, la mémoire, la boucle d'exécution, la validation et certains contrôles de périmètre. Remplacez le modèle, l'orchestrateur demeure. C'est pourquoi un orchestrateur robuste vous permet de mettre à niveau vos modèles sans avoir à reconstruire l'ensemble de votre système.
L'ingénierie des orchestrateurs constitue-t-elle une véritable discipline ?
Elle est devenue incontournable. À mesure que les performances des modèles de pointe convergent, la couche d'orchestration qui les entoure concentre l'essentiel des différences pratiques en matière de résultats. C'est pourquoi les équipes investissent dans la conception d'orchestrateurs en tant que domaine d'expertise à part entière.
Comment l'ingénierie des orchestrateurs s'applique-t-elle à la sécurité ?
En matière de sécurité, l'orchestrateur remplit deux rôles distincts. Il améliore la qualité des résultats grâce à un ciblage précis et à une validation indépendante menée par des agents parallèles, tout en confinant l'agent par le biais d'un isolement architectural et d'une application des politiques de périmètre au niveau réseau, empêchant ainsi l'agent de s'introduire en production ou d'entraîner une fuite de données.
Que sont les garde-fous pour agents IA ?
Les garde-fous désignent les contraintes qui maintiennent un agent dans son périmètre d'action initial, telles que l'isolation par sandbox, les listes blanches de domaines, les limitations de taux (rate limits) et une séparation stricte entre la couche de planification et la couche d'exécution. Les mécanismes les plus fiables sont implémentés au niveau du code et de l'infrastructure plutôt que sollicités via un prompt, ce qui empêche le modèle de les ignorer ou de contourner les restrictions.
