Anonymiser ou pseudonymiser les données avant de les envoyer à un LLM
Retirer les noms d'un prompt avant de l'envoyer à un modèle externe est devenu un réflexe. Encore faut-il savoir ce que l'on obtient : une donnée anonyme, qui sort du champ du RGPD, ou une donnée pseudonymisée, qui y reste. La différence change l'analyse de risque, et ce que vous pouvez promettre à votre DPO.
Publié le 22 septembre 2026
Deux notions que le droit distingue
Le RGPD définit la pseudonymisation à son article 4 : un traitement qui fait que les données ne peuvent plus être attribuées à une personne sans recourir à des informations supplémentaires, conservées séparément et protégées. Les données anonymes, elles, sont des informations qui ne permettent plus d'identifier une personne, compte tenu des moyens raisonnablement susceptibles d'être utilisés ; le considérant 26 les place hors du champ du règlement.
Les identifiants sont remplacés par des jetons. La correspondance existe, conservée à part. Réversible par construction, et les données restent personnelles pour celui qui détient la clé.
Toute possibilité raisonnable de réidentification est supprimée, de façon irréversible. Les données sortent du champ du RGPD, mais le résultat est rarement exploitable pour un texte libre.
La CNIL le résume ainsi : les données pseudonymisées conservent un caractère personnel, alors que l'anonymisation rend l'identification impossible en pratique.
Pourquoi un prompt s'anonymise mal
Les autorités européennes de protection des données, dans l'avis 05/2014 du G29 repris par la CNIL, retiennent trois critères pour juger une anonymisation : il ne doit plus être possible d'individualiser une personne, de corréler des informations la concernant entre plusieurs ensembles, ni d'inférer de nouvelles informations sur elle.
Un texte libre échoue souvent aux trois. Retirez le nom d'un courriel et il reste la fonction, le service, la ville, une date, un événement. « La directrice financière du site de Lyon, en arrêt depuis mars » désigne une seule personne dans la plupart des entreprises. Un modèle de langage est précisément doué pour recouper ce type d'indices.
Il y a aussi une contrainte d'usage. Pour qu'une réponse soit utile, il faut souvent réinjecter les vrais noms : un courrier doit être adressé à la bonne personne, un résumé de dossier doit citer les bonnes parties. Une anonymisation irréversible rend cela impossible. Dans la plupart des usages d'IA générative, c'est donc la pseudonymisation qui est praticable, avec ses limites.
Ce qu'a changé la jurisprudence de 2025
Le 4 septembre 2025, dans l'affaire C-413/23 P, CEPD contre CRU, la Cour de justice de l'Union a jugé que des données pseudonymisées ne doivent pas être regardées, dans tous les cas et pour toute personne, comme des données personnelles. Selon les circonstances, la pseudonymisation peut empêcher un destinataire qui ne détient pas la clé d'identifier la personne concernée. L'arrêt porte sur le règlement applicable aux institutions de l'Union, dont les notions sont celles du RGPD.
La même décision rappelle deux limites. Le caractère identifiable s'apprécie au cas par cas, selon les moyens dont dispose chaque acteur. Et les obligations du responsable du traitement, notamment l'information des personnes sur les destinataires, s'apprécient de son point de vue, au moment de la collecte, et restent entières.
Les lignes directrices 01/2025 du CEPD sur la pseudonymisation, soumises à consultation publique en 2025, insistent pour leur part sur ce qu'elle apporte : une mesure qui aide à respecter la minimisation, la protection dès la conception et la sécurité.
Pour vous, responsable du traitement qui détient la table de correspondance, les données pseudonymisées restent personnelles. L'arrêt ouvre une question sur leur statut chez le fournisseur du modèle ; il ne vous dispense ni de l'analyse d'impact, ni de l'encadrement du transfert.
Une chaîne de pseudonymisation avant l'envoi
Une pseudonymisation utile à l'IA générative suit un parcours précis, et la table de correspondance ne quitte jamais votre périmètre.
- DétecterRepérer dans le prompt et dans le contexte documentaire les identifiants directs : noms, adresses électroniques, téléphones, adresses postales, numéros de sécurité sociale, IBAN, numéros de contrat.
- Remplacer de façon cohérenteUne même personne reçoit le même jeton dans toute la requête, pour que le modèle garde le fil du raisonnement.
- Conserver la correspondance localementLa table est stockée dans un coffre, dans votre périmètre, avec des accès restreints.
- Envoyer et restaurerLe modèle travaille sur les jetons ; les vraies valeurs sont réinjectées dans la réponse à son retour, chez vous.
- Journaliser sans le brutLes traces gardent la version pseudonymisée, jamais le prompt d'origine en clair.
Ce que la détection automatique ne voit pas
Aucun détecteur ne garantit une couverture complète. Il rate en particulier :
- Les identifiants indirects : fonction, service, lieu, date, événement rare. Ce sont eux qui permettent la réidentification, et ils ne ressemblent à aucun format connu.
- Les données sensibles en toutes lettres : « suite à son cancer », « délégué syndical ». Aucun nom, mais une donnée de l'article 9 du RGPD.
- Les formats imprévus : fautes de frappe, identifiants internes, noms rares ou étrangers, texte extrait d'un document scanné.
C'est pourquoi la pseudonymisation n'est qu'un étage de la protection. Elle se combine avec une règle d'usage : les données sensibles et les dossiers les plus confidentiels vont vers un modèle exécuté localement, pas vers un fournisseur externe, même après pseudonymisation.
Choisir selon l'usage
| Usage | Technique adaptée | Ce que voit le fournisseur externe |
|---|---|---|
| Rédaction générique, veille, code non sensible | Aucune, pas de donnée personnelle | Le texte tel quel |
| Correspondance client, résumé de dossier courant | Pseudonymisation avec restauration | Des jetons et des identifiants indirects |
| Statistiques, jeux de test, entraînement | Anonymisation, vérifiée sur les trois critères | Des données agrégées ou transformées |
| Santé, RH sensible, contentieux | Modèle local, sans envoi externe | Rien |
Ce tableau est la déclinaison, pour les données personnelles, de la cartographie décrite dans le guide Souveraineté des données et IA générative. Les questions de base légale et d'analyse d'impact sont dans le guide RGPD et IA générative, et l'exposition aux lois étrangères dans le guide Cloud Act et IA.
Questions fréquentes
Des données pseudonymisées sont-elles encore des données personnelles ?
Pour celui qui détient la table de correspondance, oui. Depuis l'arrêt de la Cour de justice du 4 septembre 2025, elles peuvent ne pas l'être pour un destinataire qui n'a aucun moyen raisonnable de réidentifier les personnes, selon les circonstances. Vos obligations de responsable du traitement restent inchangées.
Remplacer les noms suffit-il à anonymiser un texte ?
Non. Un texte libre contient des identifiants indirects (fonction, lieu, date, événement) qui permettent souvent de retrouver la personne. Le résultat est au mieux pseudonymisé, et doit être traité comme une donnée personnelle.
Peut-on envoyer des données de santé pseudonymisées à un modèle externe ?
La pseudonymisation réduit le risque, mais la détection automatique ne repère pas toutes les mentions de santé exprimées en toutes lettres. Pour ces données, un modèle exécuté localement reste la solution la plus sûre, et l'analyse d'impact doit trancher la question explicitement.
Où se situe SmartAGT
En mode hybride, le coffre de confidentialité de SmartAGT, une fois activé, détecte les identifiants directs (courriel, téléphone, IBAN, carte bancaire, adresse IP, NIR, SIREN, SIRET, plaque, et les termes que vous ajoutez) et les pseudonymise de façon réversible avant tout appel à un fournisseur externe. La table de correspondance reste dans votre périmètre, et aucun prompt brut ne rejoint le journal d'audit.
Pour les usages les plus sensibles, le modèle peut être 100 % local, sans aucun flux sortant. Le détail est sur la page Sécurité.
