Agents IA : maîtriser hallucinations, fuites et coûts

Pourquoi parler de garde-fous dès maintenant

De plus en plus d'entreprises passent de l'automatisation classique à l'agent IA autonome. Une automatisation classique suit un scénario figé : si tel événement survient, alors telle action est exécutée. Un agent, lui, raisonne. Il choisit quoi répondre, quelles données consulter et combien d'outils appeler pour atteindre son objectif.

Cette autonomie fait toute sa valeur. C'est aussi elle qui crée des risques nouveaux.

Un guide technique publié en anglais sous le titre « AI Agent Guardrails: Preventing Hallucinations, Data Leaks & Runaway API Cost » (auteur non précisé) identifie trois défaillances propres aux agents autonomes. Selon ce guide, ces trois risques ne sont pas regroupés par commodité : ils apparaissent dès qu'un système dispose d'une véritable autonomie de décision.

• L'hallucination : l'agent affirme avec aplomb un fait inventé.
• La fuite de données : l'agent fait remonter une information interne réservée, ou expose les données d'un utilisateur à un autre.
• La dérive des coûts d'API : l'agent tourne en boucle, multiplie les appels à des modèles et à des outils payants, et la facture grimpe en quelques heures plutôt qu'en quelques mois.

Chez comm.it, nous accompagnons des TPE et PME dans leurs projets d'IA, d'automatisation des processus métier et de logiciels cœur de métier comme les CRM et les ERP. Ce sont précisément les contextes où un agent manipule des données sensibles : fiches clients, devis, factures, informations RH. Cet article explique comment nous transformons ces trois risques en exigences de conception, et quelle valeur cela apporte concrètement.

Le vrai coût d'un agent mal encadré

Avant de parler technique, il faut mesurer les enjeux pour une petite ou moyenne entreprise.

Une hallucination abîme la confiance plus qu'une panne

Le guide source fait une remarque très juste. Une erreur visible, un message du type « service indisponible », est agaçante mais honnête. Une réponse fausse donnée avec assurance est bien plus grave. Le client, le collaborateur ou le partenaire qui découvre qu'on lui a affirmé quelque chose d'inexact ne fera plus confiance à l'outil. Parfois, il ne fera plus confiance à l'entreprise.

Pour une PME, un assistant qui invente un délai de livraison, une condition tarifaire ou une clause de contrat peut avoir des conséquences commerciales directes.

Une fuite de données est un incident de sécurité

Le guide insiste : une fuite n'est pas un simple défaut de qualité, c'est un incident de sécurité. Si un agent connecté à votre CRM laisse un client voir les informations d'un autre client, vous ne faites pas face à un bug. Vous faites face à un problème de confidentialité, avec ses conséquences réglementaires et réputationnelles.

Une dérive de coûts arrive vite

Les modèles de langage sont facturés à l'usage. Un agent bloqué dans une boucle de raisonnement qui appelle sans cesse un modèle coûteux et des outils externes peut générer une facture inattendue en très peu de temps. Pour une structure dont le budget informatique est maîtrisé au plus juste, ce scénario est inacceptable.

Notre approche : trois lignes de défense et une surveillance unique

L'architecture décrite dans le guide source repose sur une idée que nous appliquons dans nos projets : chaque catégorie de risque appelle des contrôles dédiés, mais la supervision doit être centralisée. Trois pistes parallèles alimentent un même journal d'événements.

Voici comment nous déclinons cette logique pour nos clients.

Ligne de défense n°1 : empêcher l'agent d'inventer

Ancrer chaque réponse dans vos propres données

Le principe s'appelle l'ancrage (ou grounding). L'agent ne doit répondre qu'à partir des documents et des données qu'il a effectivement récupérés : votre base documentaire, votre catalogue, vos procédures internes, les fiches de votre ERP. Il ne doit pas compléter avec ses « connaissances générales » issues de son entraînement.

Le guide pointe l'erreur la plus fréquente : laisser l'agent se rabattre sur ses connaissances générales quand la recherche documentaire ne trouve rien. C'est exactement à ce moment que le risque d'hallucination est le plus élevé.

Concrètement, lorsque comm.it configure un agent :

• les instructions système imposent de citer la source de chaque information ;
• l'agent a l'obligation d'exprimer son incertitude lorsqu'aucun document pertinent n'a été trouvé ;
• une phrase de repli claire est définie, du type « Je ne peux pas répondre à partir des données disponibles », plutôt qu'une réponse plausible mais non vérifiée ;
• pour les usages factuels, nous réglons la température du modèle au plus bas. Le guide recommande une valeur de 0 pour la récupération d'informations factuelles, afin de rendre les réponses plus déterministes.

Encadrer le format des réponses

Deuxième levier : réduire l'espace de réponse possible. Si l'agent doit classer une demande client, il ne doit pas pouvoir inventer une catégorie qui n'existe pas dans votre CRM.

Nous imposons pour cela des sorties structurées conformes à un schéma JSON, avec des listes de valeurs fermées (énumérations). Un statut client ne peut être que « prospect », « actif » ou « inactif », par exemple, et rien d'autre. Ce choix a un double bénéfice :

• il limite mécaniquement les hallucinations ;
• il rend la sortie de l'agent directement exploitable par vos logiciels métier, sans retraitement manuel.

Faire intervenir un humain quand c'est nécessaire

Pour les décisions sensibles, nous mettons en place une validation humaine (human-in-the-loop). Le guide évoque un mécanisme simple : si le score de confiance de la réponse passe sous un seuil donné (il cite l'exemple de 0,85), le processus est mis en pause, une alerte est envoyée à un responsable, et l'exécution ne reprend qu'après validation.

Pour une PME, c'est souvent le bon compromis. L'agent traite seul les cas simples et répétitifs, et un collaborateur garde la main sur les cas ambigus.

Ligne de défense n°2 : empêcher l'agent de voir ce qu'il ne doit pas voir

Filtrer avant la recherche, pas après

C'est sans doute le point le plus important, et le plus souvent mal compris.

Beaucoup d'implémentations laissent l'agent interroger l'ensemble des documents, puis filtrent la réponse finale pour masquer ce qui est confidentiel. Le guide source explique pourquoi c'est une vulnérabilité critique : même si le contenu restreint n'est pas cité mot pour mot, il est entré dans le contexte de l'agent et peut influencer son raisonnement. La fuite devient subtile, donc difficile à détecter.

La bonne pratique consiste à appliquer le cloisonnement des accès au moment même de la requête. Chez comm.it, nous procédons ainsi :

1. l'utilisateur est authentifié dès son entrée dans le processus ;
2. son identifiant, son organisation ou son service sont récupérés ;
3. des filtres de métadonnées sont construits dynamiquement à partir de ses droits ;
4. la recherche documentaire (souvent une recherche par similarité dans une base vectorielle) ne porte que sur les documents qu'il a le droit de consulter.

Ainsi, un commercial n'interroge que les dossiers de son portefeuille, un client n'accède qu'à ses propres données, et les documents RH restent invisibles pour le reste de l'équipe.

Appliquer le moindre privilège aux outils

Un agent ne se contente pas de lire des documents. Il appelle des outils : agenda, CRM, ERP, messagerie, API diverses. Chacun de ces outils doit respecter le principe du moindre privilège.

Le guide donne un exemple parlant : un outil qui lit un calendrier ne doit pas disposer d'un droit d'écriture. Nous appliquons cette règle systématiquement :

• pas de clé d'API globale ni d'identifiants administrateur confiés à un agent ;
• des jetons dédiés, limités aux seules opérations nécessaires ;
• pour les outils de consultation, une méthode de requête verrouillée en lecture, afin que l'agent ne puisse pas déclencher dynamiquement une modification ou une suppression.

Cette discipline rejoint notre métier historique de prestataire réseau et sécurité : on ne donne jamais plus d'accès que nécessaire, que ce soit à un collaborateur, à un équipement ou à une IA.

Garder le filtrage de sortie comme filet de sécurité

Un contrôle final de la réponse (recherche de motifs sensibles, vérification par un modèle léger) reste utile. Mais, comme le souligne le guide, si ce filet se déclenche souvent, c'est le signe d'une faille en amont dans le cloisonnement. Le filtrage de sortie ne doit jamais devenir le filtre principal.

Isoler les agents par domaine

Pour les organisations plus complexes, nous pouvons recommander une architecture multi-agents : un agent superviseur délègue à des agents spécialisés, chacun isolé dans son périmètre. L'agent RH n'a aucun accès aux outils de l'agent finance. L'architecture est plus élaborée, mais l'isolation est nettement renforcée.

Ligne de défense n°3 : empêcher la facture de s'envoler

Limiter le nombre d'étapes de raisonnement

Un agent sans limite peut tourner indéfiniment. La première protection consiste à fixer un nombre maximal d'itérations. Au-delà, l'agent s'arrête et signale qu'il a atteint sa limite.

Quel plafond choisir ? Le guide propose une méthode pragmatique : analyser les exécutions réussies en production, déterminer le nombre médian d'étapes, puis fixer le plafond 20 à 30 % au-dessus de cette médiane. Il indique qu'une tâche documentaire standard se contente généralement de 3 à 5 itérations, tandis qu'une recherche complexe mobilisant plusieurs outils peut en demander 10 à 15.

Installer un disjoncteur budgétaire

Deuxième protection : le disjoncteur (circuit breaker). Le coût cumulé des appels est suivi en temps réel pendant la session. Avant chaque réponse ou chaque appel à un outil externe, une condition vérifie que le budget n'est pas dépassé. S'il l'est, l'exécution est interrompue et un administrateur est alerté.

Une nuance est essentielle, et le guide l'énonce clairement : un disjoncteur qui se contente de journaliser le dépassement sans arrêter l'exécution n'offre aucune protection financière. Lors de nos recettes, nous vérifions que l'arrêt est réellement effectif.

Choisir le bon modèle pour chaque tâche

Tous les traitements ne nécessitent pas le modèle le plus puissant, donc le plus cher. Une simple extraction de données ne demande pas les mêmes capacités qu'un raisonnement complexe. Nous mettons en place un routage par niveau de modèle : les modèles avancés sont réservés aux étapes qui le justifient.

Mettre en cache et gérer les erreurs proprement

Deux optimisations complètent le dispositif :

• la mise en cache : si une question identique, avec un contexte identique, a déjà été traitée, la réponse est servie directement sans nouvel appel au modèle ;
• les relances avec délai croissant (exponential backoff) : si un service externe limite le nombre de requêtes, l'agent n'épuise pas son quota d'itérations en réessayant à l'aveugle.

La supervision : voir ce qui se passe, et réagir

Toutes ces protections n'ont de valeur que si l'on sait quand elles se déclenchent. Nous centralisons chaque événement dans un journal unique, stocké dans une base de données relationnelle : limite d'itérations atteinte, citation manquante, tentative d'accès hors périmètre, budget dépassé.

Ce journal sert à trois choses :

• alerter en temps réel l'équipe concernée pour les événements critiques ;
• auditer le comportement de l'agent, ce qui est précieux en cas de question d'un client ou d'un auditeur ;
• ajuster les réglages dans le temps. Si un disjoncteur se déclenche trop souvent sur des demandes légitimes, c'est qu'il est trop strict. Les données réelles permettent de le recalibrer.

Le guide source recommande d'ailleurs de suivre en continu la consommation médiane par type de tâche pour adapter les seuils. Les garde-fous sont des réglages vivants, pas une configuration figée.

Tester comme un attaquant avant de mettre en production

Un garde-fou non testé reste une hypothèse. Avant toute mise en production, nous réalisons des tests adverses dans un environnement de préproduction. Le guide décrit trois scénarios que nous reprenons dans nos recettes.

• Question sans réponse : on interroge l'agent sur une information absente de la base. Il doit renvoyer sa phrase de repli, et en aucun cas des chiffres plausibles inventés.
• Tentative de fuite : un utilisateur d'une organisation A demande explicitement des documents confidentiels de l'organisation B. On vérifie, avant même l'appel au modèle, qu'aucun document de B n'a été récupéré.
• Boucle infinie : on soumet une tâche qui exige plus d'étapes que le plafond autorisé. L'agent doit s'arrêter à la limite, l'événement doit apparaître dans le journal et le coût doit cesser d'augmenter.

Notre liste de contrôle avant déploiement inclut aussi l'audit des identifiants confiés aux outils, le raccordement du journal à un système d'alerte, la limitation du débit des requêtes entrantes pour éviter les abus, et une documentation claire pour que vos équipes sachent ajuster budgets et filtres quand votre organisation évolue.

Ce que cela change pour une TPE ou une PME

Le guide conclut que ces contrôles transforment le comportement non déterministe d'un modèle de langage en un logiciel prévisible et auditable. C'est exactement l'objectif que nous poursuivons avec nos clients.

Concrètement, une approche comme celle de comm.it vous permet :

• de déployer un agent IA connecté à votre CRM, votre ERP ou votre base documentaire sans exposer vos données sensibles ;
• de garder la confiance de vos clients et collaborateurs grâce à des réponses sourcées et à un aveu d'incertitude plutôt qu'une invention ;
• de maîtriser votre budget grâce à des plafonds et à un disjoncteur réellement bloquant ;
• de disposer d'une trace de ce que fait l'agent, pour l'améliorer et en rendre compte ;
• de faire évoluer le dispositif au rythme de votre activité.

Notre force est de réunir des compétences souvent dispersées : intelligence artificielle, automatisation des processus, développement de logiciels métier, mais aussi réseau, messagerie et sécurité. Un agent IA n'est jamais isolé. Il s'insère dans un système d'information, avec ses droits d'accès, ses flux et ses contraintes. C'est en maîtrisant l'ensemble que l'on construit des garde-fous solides.

Par où commencer

Si vous avez déjà un agent IA en test ou en production, trois premières actions sont souvent prioritaires, en cohérence avec les recommandations du guide source :

1. poser un plafond d'itérations et un disjoncteur budgétaire sur l'agent le plus sollicité ;
2. vérifier que le cloisonnement des accès s'applique bien avant la recherche documentaire, et pas seulement sur la réponse finale ;
3. mettre en place un journal centralisé des événements de sécurité pour disposer d'une première base de mesure.

Si vous n'avez pas encore franchi le pas, c'est le meilleur moment pour intégrer ces principes dès la conception plutôt que de les ajouter après un incident.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : AI Agent Guardrails: Preventing Hallucinations, Data Leaks & Runaway API Cost