Fuite de données avec l'IA : par où vos applications fuient
· Écrit et tenu à jour par Nonimo
Une fuite de données avec l’IA, dans une entreprise qui a branché ses propres applications sur l’API d’un LLM, n’a presque jamais l’allure d’une attaque. Les données sortent pendant le fonctionnement normal : dans le prompt, dans les journaux, dans les documents qu’un moteur de recherche interne ajoute à la requête, dans les arguments d’un appel d’outil, puis chez le fournisseur qui les conserve.
Nonimo Gateway s’installe sur vos propres serveurs. Voir les offres et nous écrire.
La parade tient en quatre gestes : minimiser ce qui part, pseudonymiser avant l’appel, garder la clé de correspondance chez vous, restaurer les vraies valeurs dans la réponse. Ce guide passe en revue les cinq sorties, puis les quatre gestes, avec un exemple concret.
Fuite de données ChatGPT : deux problèmes distincts
On range sous « fuite de données ChatGPT » deux situations qui ne se traitent pas de la même façon. La première est le collaborateur qui colle un dossier dans l’application grand public. Elle relève de la charte et de la formation, et notre guide sur ChatGPT et la confidentialité des données explique ce que l’outil conserve.
La seconde est moins visible : vos propres applications, ou celles qu’un prestataire a développées pour vous, appellent l’API d’OpenAI avec des données clients. Personne ne colle rien, tout est automatique, et c’est précisément pour cela que personne ne regarde. C’est le sujet de cette page.
Les cinq sorties d’une application qui appelle un LLM
| Sortie | Ce qui part | Où cela reste |
|---|---|---|
| Le prompt | le texte envoyé au modèle, avec les noms, numéros et faits du dossier | chez le fournisseur, selon ses conditions |
| Les journaux | la requête et la réponse complètes, gardées pour le débogage | chez vous, chez votre prestataire, dans l’outil d’observabilité |
| Le RAG | les extraits de documents que la recherche interne ajoute au prompt | chez le fournisseur, avec le prompt |
| Les appels d’outils | les arguments que le modèle remplit pour appeler une fonction | chez le fournisseur et dans le système appelé |
| La conservation | tout ce qui précède, pendant la durée fixée par le contrat | chez le fournisseur et ses sous-traitants |
Le prompt. C’est la sortie évidente, et pourtant la moins surveillée. Un modèle de courrier qui insère automatiquement « nom, prénom, date de naissance, NIR » envoie ces quatre champs à chaque appel, qu’ils servent ou non à la tâche.
Les journaux. L’ANSSI recommande de journaliser les requêtes des utilisateurs, en prenant garde à leur protection quand elles contiennent des données sensibles (R29 de ses recommandations pour un système d’IA générative). Dans les faits, beaucoup d’outils de suivi gardent le texte intégral, parfois sur un service hébergé hors de l’Union. Notre guide sur l’AI gateway détaille ce piège.
Le RAG. Un système qui va chercher des documents pour enrichir la réponse envoie au modèle des extraits que l’utilisateur n’a pas choisis. Si la recherche interne ne respecte pas les droits d’accès, le dossier d’un autre client peut partir avec la question. L’ANSSI demande de traiter ce « besoin d’en connaître » dès la conception (R8).
Les appels d’outils. Quand le modèle appelle une fonction, par exemple pour créer un rendez-vous, il remplit des arguments : nom, téléphone, motif. Ces données transitent par le fournisseur. Certains garde-fous ne les inspectent pas : la documentation de Bedrock Guardrails indique que, dans les usages avec appel de fonctions, le filtre n’évalue ni les arguments, ni les résultats, ni les définitions des outils.
La conservation. Ce qui est parti est conservé selon les conditions du fournisseur et de votre contrat. Vous ne la pilotez qu’en partie, et c’est pourquoi le plus sûr est de ne pas envoyer la donnée en clair.
Un exemple : la lettre de liaison d’une clinique
La clinique Saint-Aubin, à Rennes, a fait développer un assistant qui rédige les lettres au médecin traitant après une consultation. L’application assemble un prompt avec le nom du patient, sa date de naissance, son NIR, le motif et le compte rendu. Pour gagner en cohérence, elle ajoute deux anciens comptes rendus trouvés par recherche interne. Puis le modèle appelle un outil pour proposer un rendez-vous de contrôle, avec le téléphone du patient en argument.
Une seule lettre fait donc sortir : l’identité complète et le NIR, un diagnostic, deux comptes rendus dont l’un concerne un homonyme, et un numéro de téléphone. Le tout est copié dans l’outil de suivi du prestataire. Aucun pirate n’est intervenu.
Avec les quatre gestes ci-dessous, le même appel envoie « PATIENT_1 », « NIR_1 », le motif et le compte rendu du seul patient concerné, et l’assistant rend une lettre où le vrai nom réapparaît chez la clinique. Pour les champs à retirer d’un compte rendu, voyez notre guide sur le compte rendu médical avec l’IA, et pour le NIR en particulier, notre guide pour masquer un numéro de sécurité sociale.
Comment stopper une fuite de données avec l’IA : quatre gestes
- Minimiser. L’article 5 du RGPD limite les données à ce qui est nécessaire à la finalité. Un courrier n’a pas besoin du NIR pour être bien rédigé : retirez du modèle de prompt tout champ que la tâche n’utilise pas, et limitez le RAG aux documents de la personne concernée.
- Pseudonymiser avant l’appel. Remplacez noms, numéros et coordonnées par des étiquettes avant que la requête ne quitte votre réseau, y compris dans les extraits RAG et les arguments d’outils. Les articles 25 et 32 du RGPD citent expressément la pseudonymisation parmi les mesures attendues.
- Garder la clé chez vous. La table qui relie « PATIENT_1 » au vrai nom ne doit jamais partir avec la requête. C’est ce qui fait la différence entre une pseudonymisation et un simple déplacement du problème. Les données restent personnelles au sens de l’article 4, point 5, du RGPD : le contrat avec le fournisseur reste nécessaire.
- Restaurer dans la réponse. Sans ce dernier geste, l’utilisateur reçoit une lettre adressée à « PATIENT_1 », et il finit par désactiver la protection. Tous les outils ne le font pas : Portkey, par exemple, indique dans sa documentation sur le caviardage que celui-ci est irréversible par conception. En streaming, la restauration doit en plus gérer des étiquettes coupées entre deux morceaux de texte.
Pour comparer les outils qui font tout ou partie de ce travail, voyez notre panorama des logiciels de masquage, notre comparaison avec Presidio et notre comparaison avec Portkey. Et si vous vous demandez s’il faudrait plutôt héberger votre propre modèle, notre guide LLM local ou proxy de confidentialité pose les critères.
Si les données sont déjà parties
Un envoi non prévu de données personnelles à un tiers peut constituer une violation de données au sens de l’article 4, point 12, du RGPD. L’article 33 impose de la documenter dans tous les cas, et de la notifier à la CNIL dans les meilleurs délais, si possible dans les 72 heures, sauf si elle n’est pas susceptible d’engendrer un risque pour les personnes. Notre guide sur la violation de données et la CNIL déroule les questions dans l’ordre.
Nonimo Gateway, les quatre gestes chez vous
Nonimo Gateway est un proxy privé qui s’installe sur vos propres serveurs. Compatible avec l’API d’OpenAI, il se branche en changeant base_url. Il remplace les données personnelles avant l’envoi, dont le NIR et les autres documents et numéros nationaux de chaque pays servi, garde la correspondance chez vous et remet les vraies valeurs dans la réponse. Vous gardez votre propre clé OpenAI, et un plugin est disponible pour LiteLLM.
Les offres et les prix sont sur la page de Nonimo Gateway.
Une fuite de données avec l’IA se prépare dans le code, rarement dans un incident spectaculaire. Faites l’inventaire des cinq sorties de vos applications, puis appliquez les quatre gestes en commençant par celle qui transporte le plus de noms. Voyez les offres de Nonimo Gateway et écrivez-nous.
Sources
Sources vérifiées le 20 octobre 2026.
- CNIL, RGPD, chapitre 1, article 4 : la pseudonymisation (point 5) et la violation de données à caractère personnel (point 12).
- CNIL, RGPD, chapitre 2, article 5 : la minimisation des données (paragraphe 1, point c).
- CNIL, RGPD, chapitre 4 : la pseudonymisation dans la protection des données dès la conception (article 25) et parmi les mesures de sécurité (article 32), la documentation et la notification des violations (article 33).
- ANSSI, Recommandations de sécurité pour un système d’IA générative, version 1.0 du 29 avril 2024 : le besoin d’en connaître dès la conception (R8) et la journalisation des requêtes en protégeant les données sensibles (R29).
- AWS, Bedrock Guardrails, filtres d’informations sensibles : les arguments, résultats et définitions d’outils non évalués dans les usages avec appel de fonctions.
- Portkey, PII redaction : un caviardage irréversible par conception, avec des étiquettes numérotées.
Cette page est fournie à titre d’information. Les caractéristiques des produits d’autres éditeurs ont été vérifiées sur leurs pages officielles le 20 octobre 2026 et peuvent évoluer.
Nonimo masque, sur votre propre ordinateur, les noms de clients et les identifiants avant que votre texte n’arrive à ChatGPT. Sans compte, et l’application fait ce travail sans que les données de vos clients quittent votre machine.
Questions fréquentes
Qu'est-ce qu'une fuite de données avec l'IA ?
C'est la sortie de données personnelles ou confidentielles vers un service d'IA qui n'aurait pas dû les recevoir, ou vers un endroit où elles n'auraient pas dû être conservées. Dans une application qui appelle l'API d'un LLM, elle se produit le plus souvent pendant le fonctionnement normal, sans piratage.
Par où les données sortent-elles d'une application qui appelle ChatGPT ?
Par cinq canaux principaux : le prompt lui-même, les journaux de l'application ou du gateway, les documents récupérés par un système RAG, les arguments des appels d'outils, et la conservation chez le fournisseur du modèle. Chacun se traite séparément.
Une fuite de données ChatGPT suppose-t-elle un piratage ?
Non, le plus souvent. Quand vos applications appellent l'API d'un LLM, les données sortent parce que le code les met dans la requête, dans les journaux ou dans les arguments d'un outil. C'est le fonctionnement prévu, et c'est pour cela que personne ne le remarque.
Comment empêcher une fuite de données vers un LLM ?
En quatre gestes : n'envoyer que ce qui est nécessaire, remplacer les données personnelles avant l'appel, garder la table de correspondance chez vous, puis remettre les vraies valeurs dans la réponse. Le fournisseur ne voit alors que des étiquettes.
Des données pseudonymisées envoyées à une IA sont-elles encore des données personnelles ?
Oui. Selon l'article 4, point 5, du RGPD, des données pseudonymisées restent rattachables à une personne grâce à des informations conservées à part, ce qui en fait des données personnelles. La pseudonymisation réduit le risque, elle ne fait pas sortir le traitement du RGPD.
Que faire si des données clients sont déjà parties vers un LLM ?
Les consigner d'abord, puis évaluer le risque. L'article 33 du RGPD impose de documenter toute violation, notifiée ou non, et de la notifier à la CNIL si possible dans les 72 heures, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes.