Agents IA et données confidentielles : pourquoi une simple consigne ne suffit pas
Agents IA et données confidentielles : pourquoi une simple consigne ne suffit pas
Prenons un exemple fictif. Une responsable commerciale demande à son agent IA de rechercher des informations publiques pour préparer un rendez-vous. L’agent a aussi accès au dossier client. Pour affiner sa recherche, il inclut dans une requête web le nom du client et un élément confidentiel de la négociation. Aucun email n’a été envoyé. Aucun document n’a été partagé. Pourtant, cette information vient de sortir de l’entreprise.
Autoriser un agent à consulter Internet ne signifie pas l’autoriser à transmettre un dossier. Une consigne de confidentialité aide le modèle à respecter cette distinction. Elle ne remplace pas des restrictions appliquées par les outils et l’environnement sur les données accessibles, les transmissions et les validations requises.
Une recherche web peut déjà être une transmission
Quand une équipe parle d’un assistant « en lecture seule », elle pense souvent aux fichiers que celui-ci ne peut pas modifier. Mais rechercher sur Internet implique d’envoyer une demande à un service extérieur. Si la requête contient une information interne, cette information est transmise au service, même si l’agent n’ouvre ensuite que des pages publiques.
La question utile n’est donc pas seulement « peut-il envoyer des emails ? ». C’est « quelles données ses outils peuvent-ils faire sortir, et vers qui ? ». Une recherche, un connecteur ou un service d’analyse peuvent transporter du contexte sans joindre le moindre fichier. Le contrôle doit porter sur ces échanges, pas uniquement sur les boutons d’envoi visibles.
Cette différence entre réponse et action est le point de départ de notre guide des agents IA en entreprise : dès qu’un assistant utilise des outils, sa mission doit être traduite en permissions vérifiables.
Pourquoi « ne divulgue jamais les données » reste utile, mais insuffisant
Il faut donner des règles claires à l’agent : quels dossiers consulter, quelles informations exclure et quand demander une validation. Sans ces indications, une recherche trop précise peut lui sembler une bonne manière de rendre service. Le problème n’est pas que les consignes seraient inutiles ; c’est de leur attribuer le rôle d’un verrou.
La documentation de Claude Code l’explicite pour les fichiers CLAUDE.md et sa mémoire automatique : ils apportent du contexte, pas une configuration imposée. C’est une distinction documentée pour ce produit, qui illustre une question à poser à tout fournisseur : si le modèle propose une action contraire à la règle, quel composant l’empêche réellement ?
Une page consultée peut aussi contenir une instruction qui tente de détourner l’assistant. On parle d’injection de prompt lorsque ce contenu cherche à modifier son comportement au lieu de rester une information à analyser. Mais une fuite ne suppose pas forcément un attaquant : OpenAI décrit également le risque qu’un agent partage involontairement davantage de données que prévu avec un outil connecté.
Notre article sur le triangle de risque des assistants IA examine la combinaison de données privées, de contenus extérieurs et de moyens de transmission. Ici, le point décisif est plus discret : le moyen de transmission peut être la recherche elle-même.
Quatre protections à demander avant d’ouvrir les dossiers clients
1. Un accès limité à la mission
Pour comparer des offres publiques, l’agent n’a pas besoin de lire tout le portefeuille commercial. Si une synthèse exige des éléments internes, son accès doit être limité aux documents nécessaires. Une responsable qui suit vingt clients peut légitimement lire leurs dossiers ; son agent chargé du rendez-vous de demain n’a pas pour autant besoin des vingt.
2. Un contrôle des données transmises et des destinations
Autoriser uniquement certains domaines réduit les destinations possibles. Cela ne détermine pas quelles données peuvent leur être envoyées. Un moteur de recherche approuvé reste un service extérieur : son autorisation ne doit pas permettre de lui transmettre librement les détails d’un contrat.
Demandez donc ce qui est contrôlé avant la sortie : destination, contenu autorisé et contexte de la mission. Si l’environnement ne peut pas imposer la limite nécessaire, il faut réduire les données disponibles ou séparer la recherche publique du traitement confidentiel.
3. Une validation qui montre ce qui va sortir
Pour une action sensible, « autoriser l’outil » est trop vague. Le valideur doit comprendre quelle information sera transmise, à quel destinataire et pour quelle raison. La validation doit intervenir avant la transmission, pas après l’obtention du résultat. Si ces éléments ne sont pas visibles, l’équipe ne peut pas donner un accord éclairé.
4. Des traces utiles sans recréer le dossier dans les journaux
Il faut pouvoir retrouver l’outil appelé, la destination, la décision d’autorisation et les refus. Cela ne justifie pas de recopier tous les contenus confidentiels dans les journaux techniques. Leur accès et leur conservation doivent eux aussi être définis. Le responsable métier doit enfin savoir qui peut suspendre l’agent en cas d’écart.
Une IA locale règle-t-elle le problème ?
Faire tourner le modèle sur un équipement maîtrisé peut éviter d’envoyer son contexte à un fournisseur de modèle distant. Cela ne ferme pas les outils connectés : un agent local qui interroge un service web lui transmet toujours sa requête. Hébergement du modèle et contrôle des sorties sont deux décisions distinctes.
Notre guide LM Studio et IA locale explique ce que l’exécution locale change. Pour protéger un dossier, il faut aussi examiner les connecteurs, les services annexes et les traces, sans supposer que le mot « local » couvre toute la chaîne.
Regard croisé : pourquoi nous privilégions la piste Hermes Agent pour un cadre maîtrisé
Si la confidentialité dépend de l’environnement d’exécution, le choix ne peut pas se limiter au modèle qui rédige la meilleure synthèse. Chez Say Digital, Hermes Agent est une piste que nous privilégions pour construire un agent métier dont l’entreprise peut organiser l’exploitation. Ce framework open source permet de choisir où fonctionne l’agent et quel fournisseur de modèle il utilise. Notre guide Hermes Agent en entreprise explique cette séparation entre modèle, outils et responsabilité humaine.
L’intérêt n’est pas de remplacer une consigne Claude par une consigne Hermes. Claude Code est orienté vers le travail de développement ; Hermes peut servir de couche d’exécution pour des missions métier reliées à plusieurs outils. Leurs usages se recoupent, mais ce n’est pas un classement de sécurité. Pour une entreprise, l’avantage recherché est de pouvoir faire des choix explicites :
- Hébergement et modèle : choisir l’environnement de l’agent, puis décider séparément si le modèle sera distant ou local, selon les contraintes du dossier.
- Contexte et procédures durables : conserver les consignes utiles et réutiliser des « skills », des procédures que l’équipe peut relire, tester et faire évoluer. Cette mémoire reste elle-même un contenu sensible à gouverner.
- Droits et preuves : cadrer les comptes connectés, les opérations autorisées, les validations et les traces nécessaires. Ces contrôles doivent être appliqués par les outils et l’environnement ; une procédure mémorisée ne les impose pas.
Ces possibilités d’hébergement, de choix du modèle et de capitalisation sont décrites dans le dépôt officiel de Hermes Agent. Elles donnent une base adaptable, pas une protection automatique : un agent auto-hébergé peut encore transmettre du contexte à un modèle distant ou à une recherche web. Les journaux doivent permettre de comprendre les actions sans recopier inutilement les dossiers.
Pour passer de ce choix d’architecture à une délégation réelle, notre analyse du droit d’agir des agents, dont Hermes Agent précise pourquoi chaque connexion reste soumise aux permissions du service. Le bon premier pilote n’est donc pas « Hermes avec tous les dossiers » : c’est une mission bornée, des accès limités et une transmission interdite que l’équipe doit voir effectivement bloquée.
La preuve à demander : un refus qui fonctionne
Avant de connecter des dossiers réels, faites tester le parcours sur des données fictives. L’équipe doit pouvoir constater qu’un document hors mission reste inaccessible, qu’une information non autorisée ne part pas dans une requête et qu’une transmission sensible attend la bonne validation. Demandez aussi ce qui se passe lorsque le contrôle ne peut pas statuer : une incertitude ne doit pas devenir une autorisation implicite.
Un essai réussi ne certifie pas le système pour toujours. Ajouter un outil, changer un fournisseur ou élargir les droits peut rouvrir une sortie. La documentation de Claude Code distingue les permissions des mécanismes d’isolation réseau ; OpenAI rappelle que les protections réduisent le risque sans l’éliminer entièrement.
Dans le Say Digital Framework, le prototype doit donc prouver les refus attendus avant le déploiement contrôlé. Les règles et les tests accompagnent ensuite les changements, puis l’équipe mesure le temps gagné et les validations nécessaires. Une démonstration qui produit une belle synthèse sans montrer ce qu’elle empêche ne suffit pas à autoriser l’accès aux dossiers clients.
Vous voulez donner accès à vos données sans ouvrir toutes les sorties ? Partons d’une mission précise et des informations qu’elle exige. Échangeons avec Say Digital pour cadrer les accès, les transmissions et les preuves à demander avant le déploiement de votre agent.
Sources et ressources
Documentation consultée le 24 octobre 2026. Les recommandations ci-dessus sont un cadre de décision, pas une certification de sécurité.
