7 erreurs de confidentialité des données qui font fuiter discrètement les données de votre entreprise via les agents IA (et comment les éviter)

La plupart des fuites de données via les agents IA ne viennent pas du modèle qui mémorise secrètement votre entreprise. Elles viennent d'erreurs de configuration et d'architecture que vous pouvez nommer et corriger. Les principales : faire tourner un agent sur un compte grand public dont les réglages par défaut s'entraînent sur vos saisies, laisser un agent hériter des permissions trop larges d'une personne, brancher un agent exposé au public sur des systèmes internes, et laisser la « triade fatale » intacte (données privées, contenu non fiable et une voie d'envoi externe) pour qu'une seule injection de prompt puisse lire vos données et les expédier dehors. C'est exactement ce dernier schéma qui a permis à EchoLeak (CVE-2025-32711) d'exposer des données sensibles via Microsoft 365 Copilot à partir d'un e-mail conçu sur mesure, sans le moindre clic de l'utilisateur. Les correctifs n'ont rien d'exotique, et presque tous sont des décisions prises avant le lancement de l'agent, pas une checklist qu'on vous remet après qu'une fuite a eu lieu.

Voici la liste que nous parcourons avant d'installer un agent que nous avons construit dans la stack d'une autre entreprise, rédigée pour qu'un dirigeant non technique puisse repérer les mêmes erreurs dans sa propre configuration ou chez un prestataire. Si vous préférez que nous tenions cette ligne là où elle doit l'être pour vous, voyez comment nous assurons la gouvernance et la maîtrise des risques de l'IA responsable. Tout ce qui suit est à vous, dans un cas comme dans l'autre.

D'abord, une distinction que presque tous les articles sur le sujet brouillent, parce que se tromper là-dessus est l'erreur zéro. Il existe deux façons complètement différentes pour les données de fuir via un agent, et elles ont des correctifs complètement différents :

• Le traitement des données par le fournisseur. Le fournisseur du modèle stocke-t-il ou s'entraîne-t-il sur vos saisies ? C'est un contrat que vous signez et un niveau de compte que vous choisissez. Cela se résout avec des conditions et de la configuration.
• L'exfiltration à l'exécution. L'agent peut-il être trompé, au moment où il s'exécute, pour envoyer vos données là où elles ne devraient pas aller ? Cela se résout avec de l'architecture, pas avec un contrat.

Les chiffres des enquêtes montrent que les acheteurs ressentent cela même quand ils ne savent pas le nommer. Dans l'étude de Cloudera menée auprès de près de 1 500 responsables informatiques seniors dans 14 pays, 96 % prévoient d'étendre l'usage des agents IA au cours de l'année à venir, et pourtant 53 % (plus de la moitié) désignent la confidentialité des données comme leur principal obstacle à l'adoption. Les sept erreurs ci-dessous sont là où cette peur devient une vraie fuite, et là où vit le correctif.

Erreur 1 : faire tourner des agents de production sur des comptes grand public

C'est l'erreur la moins chère à commettre et la plus facile à corriger. Quelqu'un branche un flux de travail sur un compte ChatGPT personnel ou Gemini grand public parce qu'il est déjà là, et voilà que les données de votre entreprise sont régies par des conditions grand public qui n'ont jamais été pensées pour elles.

L'écart entre les offres grand public et entreprise est net. Côté entreprise, le schéma est constant d'un fournisseur à l'autre : aucun entraînement sur vos données par défaut, une fenêtre de rétention courte pour la surveillance des abus, et des options plus solides sur demande. L'API d'OpenAI conserve les données 30 jours pour la surveillance des abus puis les supprime, et ne s'entraîne pas dessus par défaut. Depuis le 14 septembre 2025, Anthropic a ramené la rétention des journaux d'API de 30 jours à 7 jours, et les entrées et sorties de l'API ne servent jamais à l'entraînement. Le Vertex AI de Google (l'offre entreprise) est configurable sans usage pour l'entraînement. Côté grand public, les réglages par défaut s'inversent : ChatGPT grand public stocke les conversations indéfiniment tant que vous ne les supprimez pas, et la rétention de Gemini grand public peut aller jusqu'à 36 mois et servir à améliorer les produits.

Le correctif : placez chaque agent de production sur une API d'entreprise ou un compte professionnel, jamais sur un identifiant personnel. La technologie est identique. Les conditions ne le sont pas, et les conditions sont toute la différence entre des données qui restent régies et des données qui deviennent discrètement du matériel d'entraînement.

Erreur 2 : les permissions trop larges héritées par l'agent

La fuite à l'exécution la plus courante n'a rien d'astucieux. On confie à un agent l'accès d'un employé, ou pire, une clé d'administrateur, si bien qu'il peut techniquement voir tout ce que cette personne peut voir. Puis on lui pose une question, ou on le trompe pour qu'il en traite une, qui dépasse de loin son rôle.

Le Cloud Adoption Framework de Microsoft énonce la règle clairement : « Accordez aux agents l'accès uniquement aux sources de données précises requises par leur fonction. Ne fournissez pas un accès large à toutes les données de l'organisation. » Un agent de support n'a pas besoin de votre système de paie. Un agent de planification n'a pas besoin de la base de données clients. Quand un agent agit au nom d'une personne, il doit hériter des permissions de cette personne en transmettant son identité de manière sécurisée, de sorte qu'un agent de support montre à un employé son propre dossier RH uniquement, pas celui de tout le monde.

Le correctif : donnez à chaque agent sa propre identité, cadrée au moindre privilège, et faites-lui hériter des permissions de l'utilisateur qui agit plutôt que de porter en permanence un sur-ensemble. Le test est simple. Si l'agent est trompé demain, le dommage est borné par l'ensemble restreint qu'on lui a accordé, pas par tout ce qu'un seul compte sur-permissionné pourrait atteindre.

Erreur 3 : les agents exposés au public branchés sur des données internes

Un chatbot sur votre site web et un agent qui rédige des rapports internes sont deux mondes de sécurité différents, et la fuite arrive à l'instant où quelqu'un les laisse partager un backend. Un agent public prend des saisies de n'importe qui sur internet. Si ce même agent peut aussi interroger des données internes de l'entreprise, vous avez construit une porte du web public droit vers vos systèmes privés.

Le framework de Microsoft trace ici la ligne la plus stricte : « Les agents exposés au public ne doivent pas accéder aux données internes de l'entreprise. » Gardez le confidentiel et le public séparés par une frontière physique ou logique (leur exemple utilise des groupes de gestion « corp » et « online » distincts). L'idée est que la frontière soit structurelle, pas l'espoir que le prompt tiendra.

Le correctif : posez une vraie frontière entre les agents qui prennent des saisies publiques non fiables et les agents qui touchent à des données confidentielles. Si un seul agent doit réellement faire les deux, c'est la conception la plus risquée que vous puissiez choisir, et elle a besoin des contrôles qui rompent la triade décrits dans les erreurs suivantes, pas seulement d'un prompt système soigné.

Erreur 4 : ignorer la triade fatale

C'est l'erreur qui transforme les trois premières en une véritable exfiltration. Simon Willison, l'expert indépendant qui a inventé le terme « injection de prompt », a nommé la « triade fatale » des agents IA : trois conditions qui, réunies, permettent à une seule instruction injectée de voler vos données.

Quand les trois sont présentes, un attaquant cache une instruction à l'intérieur du contenu non fiable. Le modèle, selon les mots de Willison, « suivra volontiers toute instruction qui parvient au modèle, qu'elle vienne de son opérateur ou d'une autre source ». Il lit vos données privées et les envoie dehors, et rien dans le prompt ne lui a dit de se méfier de l'e-mail.

La part brutale, et la raison pour laquelle c'est de l'architecture et non un problème d'ingénierie de prompt : « nous ne savons toujours pas comment empêcher cela de façon fiable à 100 %. » Des exploits documentés ont touché Microsoft 365 Copilot, le serveur MCP de GitHub et GitLab Duo. En une seule semaine de janvier 2026, des vulnérabilités d'injection de prompt indirecte ont été divulguées dans quatre outils de productivité IA, toutes selon le même schéma de triade.

Le correctif : rompez une jambe. Refusez la voie d'envoi externe pour que les données volées n'aient nulle part où aller, ou ne laissez jamais un agent qui lit du contenu non fiable détenir aussi un accès aux données privées dans le même contexte. Vous n'avez pas besoin de remporter le combat impossible qui consiste à attraper chaque injection. Vous avez besoin de vous assurer que même une injection réussie n'a aucune sortie.

Erreur 5 : considérer EchoLeak comme le problème de quelqu'un d'autre

Il vaut la peine de nommer un incident réel, car « la triade fatale » sonne abstrait jusqu'à ce qu'on la voie exécutée. EchoLeak (CVE-2025-32711) était une attaque sans clic sur Microsoft 365 Copilot. Un attaquant a envoyé un e-mail conçu sur mesure. Copilot, en faisant son travail normal, a traité cet e-mail (contenu non fiable), avait accès aux données internes de l'utilisateur (données privées), et avait un moyen d'envoyer des informations dehors (communication externe). L'instruction cachée a accompli l'exposition de données sensibles sans aucune interaction de l'utilisateur. Personne n'a cliqué sur quoi que ce soit.

L'erreur ici est de supposer qu'une fuite nécessite un employé négligent. EchoLeak n'en exigeait aucun. La défense qui comptait n'était pas « former le personnel à repérer le hameçonnage », car il n'y avait rien à repérer pour un humain. La défense était architecturale : un agent qui ne peut pas à la fois lire un contenu contrôlé par l'attaquant et exfiltrer ne peut pas être retourné contre vous de cette façon.

Le correctif : partez du principe que le sans-clic est le modèle de menace, pas l'exception. Si votre agent lit quoi que ce soit qu'un tiers peut influencer (e-mails, contenu web, fichiers téléversés, tickets) et qu'il peut aussi envoyer des données dehors, vous avez un trou en forme d'EchoLeak jusqu'à ce que vous fermiez l'une de ces deux capacités ou que vous verrouilliez fermement la voie d'envoi.

Erreur 6 : aucune frontière de résidence ou de rétention des données

Certaines fuites ne sont pas des exfiltrations spectaculaires, ce sont des dérives lentes. Les données finissent stockées dans une région que vous n'avez jamais acceptée, ou restent dans des journaux plus longtemps que votre politique ne l'autorise, simplement parce que personne n'a posé la frontière. Le framework de Microsoft cite cela comme gouvernance de base : identifier l'emplacement de chaque source de données, de l'exécution de l'agent et du stockage des sorties, garder les données dans des régions ou sur site qui correspondent à votre politique de résidence, et les garder chiffrées au repos.

La bonne nouvelle rassurante, que presque aucun article n'énonce clairement, c'est à quel point vous pouvez tout verrouiller. Le schéma d'entreprise chez tous les fournisseurs, c'est : aucun entraînement par défaut, plus une fenêtre de rétention courte, plus des garanties plus solides sur demande. Anthropic propose aux entreprises éligibles un accord de Zéro Rétention de Données (ZDR), au titre duquel les entrées et sorties ne sont pas stockées au-delà de ce qui est nécessaire pour filtrer les abus. OpenAI propose le ZDR via un accord négocié et la résidence des données. Les deux vous laissent choisir où vivent les données. Auto-héberger un modèle ouvert (par exemple avec Ollama) garde les données entièrement locales, avec zéro rétention par des tiers.

Le correctif : décidez et documentez la frontière avant le lancement. Quelle région détient les données, combien de temps vivent les journaux, avez-vous besoin du ZDR, et la récupération sensible doit-elle s'exécuter dans votre propre VPC ou sur site. Le ZDR ne concerne généralement que l'API et est négocié, et il ne couvre pas automatiquement chaque produit à moins que vous ne l'ajoutiez, donc le détail compte.

Erreur 7 : traiter la confidentialité comme une checklist qu'on délègue

La dernière erreur est structurelle. La plupart des recommandations, y compris l'excellent framework de Microsoft, supposent que vous construirez et gouvernerez l'agent vous-même, et vous remettent donc une pile de 3 000 mots d'identités Entra, d'étiquettes Purview et de groupes de gestion. C'est la bonne réponse pour une grande équipe informatique. Pour la plupart des entreprises, c'est une checklist que personne n'a le temps ou la compétence spécialisée d'appliquer pleinement, alors elle est livrée à moitié, et les manques sont exactement là où les données fuient.

L'erreur est de traiter les contrôles comme de la documentation plutôt que comme une architecture dont quelqu'un est responsable de bout en bout. Une checklist qui liste « isoler les données confidentielles » et « restreindre les intégrations externes aux serveurs MCP de confiance » ne vaut que ce que vaut la personne qui la câble, qui valide chaque communication externe, et qui met en place le plan d'incident pour désactiver vite un agent quand quelque chose tourne mal.

Le correctif : assurez-vous qu'une partie est réellement responsable de la frontière, pas seulement du document. Soit vous construisez la capacité interne pour mettre en œuvre et maintenir toute la pile, soit vous avez un opérateur qui élimine ces modes de défaillance par conception et les exploite, avec une frontière publiée que vous pouvez désigner. Le mauvais entre-deux, c'est une liste de contrôles et personne de responsable de leur tenue.

Comment s'alignent les sept erreurs et leurs correctifs

Voici les sept réunies au même endroit, triées selon que le correctif est un contrat que vous signez ou une architecture que vous construisez. Ce partage est le moyen le plus rapide de savoir quelle équipe est responsable de chacune.

Remarquez que seules deux des sept se résolvent par un contrat. Les cinq autres relèvent de l'architecture et de la responsabilité, qui est la partie qu'un PDF de bonnes pratiques ne peut pas faire à votre place. C'est aussi la raison honnête pour laquelle les sources faisant autorité laissent un manque : elles vous disent quoi construire, pas qui le construira correctement à l'intérieur de vos systèmes précis.

Ce qui, en réalité, ne sort jamais, quand la frontière est bien construite

Il est facile de lire sept erreurs et de conclure que les agents IA sont un champ de mines pour la confidentialité. Ils ne le sont pas, quand la ligne est tracée délibérément. Sur des conditions d'entreprise, vos saisies ne sont pas des données d'entraînement, et la rétention se compte en jours, pas pour toujours (7 pour l'API d'Anthropic, 30 pour OpenAI, supprimées ensuite). Avec le ZDR, elles ne sont pas stockées au-delà du filtrage des abus. Avec la résidence des données fixée, elles restent dans votre région. Avec une récupération en VPC ou sur site, les données sensibles ne sortent jamais de votre périmètre. Avec le masquage à la frontière, les champs qui ne devraient jamais voyager sont retirés avant tout envoi. Avec un cadrage au moindre privilège qui hérite des permissions de l'utilisateur, l'agent ne peut jamais atteindre que ce que la personne qui agit pouvait déjà atteindre.

C'est une frontière précise et défendable, et pouvoir l'énoncer clairement est tout l'enjeu. Le danger n'a jamais été le modèle absorbant discrètement votre entreprise. Ce sont les sept erreurs de configuration et d'architecture ci-dessus, dont chacune est évitable avant que le premier agent ne soit mis en service.

C'est le travail que nous accomplissons à l'intérieur des stacks d'autres entreprises : choisir les conditions, cadrer les identités, isoler le public du confidentiel, rompre la triade, et être responsable de la frontière pour qu'elle tienne. Si vous voulez que ces erreurs soient éliminées de vos agents par conception avant qu'ils ne touchent quoi que ce soit de réel, réservez une consultation gratuite ci-dessous et nous cartographierons votre frontière ensemble.