# Le harnais d'un agent IA : ce qui casse, et pourquoi se faire accompagner

Un agent IA ne se résume pas à son modèle. Le harnais, le logiciel qui l'entoure, décide de ce qu'il voit, de ce qu'il peut faire et de ce qu'il retient, et c'est là que la plupart des problèmes apparaissent : sécurité, droits, tâches qui échouent sans bruit, mises à jour, ressources. Les connaître d'avance évite de les découvrir chez soi.

Guide · Écrit par l’IA, relu par David Solito · Publiée le 7 novembre 2026 · 6 min de lecture

Un agent IA, c’est un modèle de langage et tout ce qui l’entoure : les outils qu’il peut appeler, les accès qu’on lui ouvre, la mémoire qu’il relit, les consignes qu’il reçoit, les tâches qu’il lance seul. Cet ensemble s’appelle le harnais (*harness* en anglais). Hermes et OpenClaw, présentés dans notre [comparatif des agents IA](/fr/memory/comparatif-agents-ia/), sont des harnais ; le modèle, lui, se branche dessus.

Le modèle fait l’essentiel du raisonnement, mais c’est le harnais qui décide de ce que l’agent voit, de ce qu’il a le droit de faire et de ce qu’il retient. Anthropic, qui a étudié des agents travaillant pendant des heures, résume le problème ainsi : chaque nouvelle session commence sans souvenir de la précédente, et sans un harnais bien conçu, l’agent essaie de tout faire d’un coup ou déclare le travail terminé trop tôt [6](#source-6). Quand un agent déçoit ou inquiète, la cause se trouve le plus souvent là.

## Six problèmes que l’on rencontre vraiment

**Des instructions cachées dans ce qu’il lit.** Un agent qui lit vos e-mails ou des pages web peut tomber sur un texte écrit pour le détourner. Simon Willison a décrit la combinaison dangereuse : un agent qui a accès à des données privées, qui lit des contenus venus de l’extérieur et qui peut envoyer des informations au-dehors. Réunies, ces trois capacités permettent à un attaquant de lui faire transmettre vos données [1](#source-1). Le risque n’est pas théorique : l’OWASP, la référence de la sécurité des applications, a publié en décembre 2025 une liste des dix risques propres aux agents, établie avec plus de cent experts  [4](#source-4).

**Des compétences ajoutées qui sont du code.** Les harnais s’enrichissent de modules partagés par leur communauté. Installer l’un d’eux revient à faire tourner du code écrit par quelqu’un d’autre, avec les accès de l’agent. Microsoft recommande de traiter OpenClaw comme une exécution de code non fiable disposant d’identifiants permanents, dans un environnement isolé [2](#source-2). Une analyse publiée sur arXiv, portant sur 470 alertes de sécurité visant ce projet, décrit notamment un module malveillant diffusé par ce canal  [3](#source-3).

**Des droits trop larges.** Un agent partagé par plusieurs personnes voit, par défaut, tout ce que voient ses services connectés. Selon SFEIR, ni Hermes ni OpenClaw ne distinguent les droits des utilisateurs à l’intérieur d’un même agent ; la séparation se fait au niveau du serveur  [7](#source-7).

**Des tâches qui échouent sans bruit.** Une tâche planifiée qui s’arrête ne prévient personne si rien n’est prévu pour le faire. Le résultat attendu n’arrive simplement pas, ou arrive incomplet.

**Des mises à jour qui cassent ce qui marchait.** Les harnais évoluent chaque semaine. Une nouvelle fonction peut modifier une dépendance dont une autre avait besoin.

**Une machine qui a ses limites.** L’agent ne connaît pas la mémoire ou le processeur de son serveur tant qu’on ne les lui a pas écrits. Il peut lancer un travail trop lourd pour elle.

**Le modèle n’est pas le seul responsable** Instructions cachées, modules partagés, droits, tâches silencieuses, mises à jour, ressources : ces six problèmes se règlent dans le harnais et dans son installation, pas en changeant de modèle.

## Ce que nous avons appris sur notre propre installation

Nous faisons tourner Hermes chaque jour pour notre propre travail, et nous en tenons un carnet de bord public sur X [8](#source-8). Plusieurs de ces problèmes, nous les avons vécus.

- **Le serveur figé.** Pour transcrire l’enregistrement d’une réunion de deux heures, l’agent a installé seul un modèle de transcription de 1,5 Go sur une machine de 4 Go de mémoire. Le serveur s’est bloqué et il a fallu le redémarrer à distance. Depuis, aucune tâche lourde ne part sans accord, et la mémoire de l’agent est plafonnée  [8](#source-8).

- **La voix qui a coupé les oreilles.** L’installation de la synthèse vocale a changé une bibliothèque dont la transcription avait besoin : l’agent parlait, mais ne comprenait plus les messages vocaux. Depuis, chaque ajout est suivi d’un essai de ce qui fonctionnait avant  [8](#source-8).

- **La sauvegarde ratée.** Une sauvegarde de nuit avait échoué sans que personne le sache. Nous avons ajouté un rapport du matin, produit par un simple script sans IA : sauvegardes, tâches en échec, alertes ouvertes [8](#source-8). La même semaine, des fichiers de configuration créés avec le compte administrateur sont devenus illisibles pour l’agent ; c’est ce rapport qui l’a fait apparaître.

- **La tâche arrêtée.** Une tâche planifiée a voulu lire ses consignes avec un outil interdit dans ce mode d’exécution, et s’est arrêtée sans rien produire. Nous avons réécrit ses consignes pour qu’elle passe par l’outil autorisé.

- **Le modèle par défaut.** Dans Hermes, une tâche planifiée créée sans modèle précisé tourne sur le modèle principal, souvent le plus cher. Chaque tâche est donc rattachée explicitement au modèle prévu pour elle.

- **Des règles qui se contredisent.** À force d’ajouter des consignes, certaines finissent par s’opposer. Une revue de nuit relit désormais les règles de l’agent ; la première en a trouvé sept incohérences [8](#source-8). Nous avons aussi appris qu’au-delà d’une certaine taille, le fichier de consignes est tronqué : ajouter une règle peut en rendre une autre invisible.

Aucun de ces incidents n’a eu de conséquence pour un client. Tous ont un point commun : ils ne se voient pas dans une démonstration, seulement après quelques semaines d’usage réel.

## Ce qu’apporte un partenaire qui a déjà fait ces erreurs

L’installation d’un harnais se fait en une commande. Le faire tourner de façon fiable pendant des mois demande autre chose.

- **Des garde-fous posés avant, pas après.** Limites de la machine, actions qui demandent un accord, accès ouverts logiciel par logiciel, un agent par rôle quand plusieurs personnes l’utilisent. Anthropic le formule comme un principe : l’agent doit pouvoir travailler seul, mais l’humain garde la main avant les décisions importantes  [5](#source-5).

- **Une surveillance hors de l’agent.** Un agent ne signale pas ses propres pannes de façon fiable. Les sauvegardes, les échecs de tâches et l’état du serveur se surveillent par des scripts simples, indépendants de lui.

- **Des mises à jour testées.** Lire les notes de version, essayer sur une copie, rejouer ce qui fonctionnait.

- **Quelqu’un qui répond.** Quand une tâche n’a pas tourné ou qu’une réponse est fausse, il faut un nom, pas un forum.

## Quand on peut s’en passer

Un partenaire n’est pas indispensable à tout le monde. Une entreprise qui a dans son équipe une personne à l’aise avec un serveur Linux, prête à suivre les mises à jour et à lire la documentation de sécurité, peut installer un harnais elle-même, à condition de commencer petit : un seul usage, en lecture seule, sur une machine isolée. Un usage personnel et peu sensible, comme le tri de ses propres e-mails, se teste aussi sans grand risque.

L’accompagnement devient utile quand l’agent touche des données de clients, quand plusieurs personnes l’utilisent, ou quand personne en interne n’a le temps de le surveiller. C’est ce que nous faisons avec [Lightwire](/fr/assistant-ia-pme/).

Sources consultées le 22 octobre 2026.