On dit souvent, par commodité, qu’on « anonymise » un fichier avant de le donner à une IA. Le mot est trop fort. La CNIL distingue clairement l’anonymisation et la pseudonymisation. L’avis 05/2014 du G29, toujours cité par l’autorité, le dit aussi : la pseudonymisation n’est pas une méthode d’anonymisation. Voici ce que cela change, concrètement, et pourquoi la table de correspondance de notre anonymiseur ne doit jamais partir vers un modèle.
Ce que dit la CNIL, en quelques phrases
Sur sa page « L’anonymisation de données personnelles », la CNIL décrit l’anonymisation comme un traitement qui vise à rendre impossible, en pratique, toute identification de la personne, par quelque moyen que ce soit, et de manière irréversible. Une fois les données réellement anonymes, le régime de protection des données personnelles ne s’applique plus de la même façon à leur réutilisation. Encore faut-il que l’anonymisation tienne.
La pseudonymisation, elle, est un traitement de données personnelles réalisé de manière à ce que l’on ne puisse plus attribuer les données relatives à une personne physique sans information supplémentaire. En pratique, on remplace des données directement identifiantes (un nom, un prénom) par des données indirectement identifiantes (un alias, un numéro). L’opération est réversible. Les données conservent un caractère personnel. La CNIL rappelle qu’il est souvent possible de retrouver l’identité grâce à des données tierces. La pseudonymisation est une mesure recommandée par le RGPD pour réduire des risques. Elle n’ôte pas le caractère personnel.
L’avis 05/2014 du groupe de travail « article 29 », adopté le 10 avril 2014, va dans le même sens. Il souligne que la pseudonymisation réduit la corrélation d’un ensemble de données avec l’identité d’origine, et qu’elle est une mesure de sécurité utile, mais qu’elle ne produit pas, à elle seule, un ensemble de données anonymes. Le texte officiel est disponible notamment via la version française publiée par la CNIL.
Trois critères pour parler d’anonymat, pas d’un simple remplacement
Les autorités européennes de protection des données, reprises par la CNIL, retiennent trois critères pour évaluer si un jeu peut être considéré comme anonyme :
- l’individualisation : peut-on encore isoler un individu dans le jeu ?
- la corrélation : peut-on relier entre eux des ensembles distincts concernant la même personne ?
- l’inférence : peut-on déduire, de façon quasi certaine, une information nouvelle sur quelqu’un ?
La CNIL donne des exemples parlants. Remplacer seulement un nom par un numéro qui n’appartient qu’à une personne, dans une base de CV, permet encore d’individualiser : on est dans la pseudonymisation, pas dans l’anonymisation. Une base d’adresses, même sans nom, peut cesser d’être anonyme si d’autres bases relient ces adresses à des identités. Un résultat d’enquête trop fin peut permettre d’inférer une information sur une personne que l’on sait avoir répondu.
Si ces trois critères ne sont pas parfaitement tenus, le responsable de traitement qui souhaite parler d’anonymat doit pouvoir montrer, par une évaluation, que le risque d’identification, avec des moyens raisonnablement susceptibles d’être utilisés, est négligeable. Les techniques évoluent. Une veille est nécessaire. Un jeu publié comme « anonyme » qui contient encore des données personnelles peut poser un problème sérieux, y compris au regard d’autres textes, comme l’article L. 312-1-2 du code des relations entre le public et l’administration dans certains contextes de diffusion.
Nous n’allons pas plus loin, ici, dans le conseil juridique. Ces critères suffisent déjà à éviter un abus de langage dans un projet d’IA.
Ce que fait l’anonymiseur, et ce qu’il ne prétend pas
Notre outil remplace des identifiants qu’il a pu détecter, sur son serveur, par règles, dictionnaires et OCR, sans envoyer les documents à une IA tierce pour les analyser. Le mode cohérent pose des jetons stables, [PERSONNE_1], [EMAIL_2]. Le masquage simple ne garde que la catégorie. Dans les deux cas, le résultat est une pseudonymisation, pas une anonymisation au sens de la CNIL.
Le contexte peut encore permettre de reconnaître quelqu’un : une fonction unique, un récit, un recoupement. L’interface le dit, et demande de relire les documents « À vérifier ». Le rapport de conformité aide à prioriser. Il ne délivre pas un certificat d’anonymat. L’outil lui-même, dans ses textes publics, assume ce vocabulaire : les documents produits sont pseudonymisés.
C’est déjà utile. Réduire les noms, les e-mails, les numéros, avant un traitement, diminue ce que l’on expose. Cela ne dispense pas de se demander si le reste du texte identifie encore, ni si l’on a le droit, le fondement, la durée, pour envoyer ce corpus à un prestataire.
La table de correspondance : utile, et dangereuse si elle voyage
L’anonymiseur peut proposer une table de correspondance : un fichier séparé, qui relie chaque jeton à sa valeur d’origine, téléchargeable une seule fois. Ce fichier est précisément l’« information supplémentaire » dont parle la définition de la pseudonymisation. Avec lui, on peut réidentifier. Sans lui, c’est plus difficile, mais pas toujours impossible, on l’a vu, à cause du contexte.
D’où une règle simple, que nous écrivons sans détour : cette table ne doit jamais être transmise à une IA, ni jointe au corpus que l’on confie à un modèle, ni déposée dans le même dossier « pour que le modèle s’y retrouve ». Le modèle n’a pas à « s’y retrouver » jusqu’aux identités. S’il a besoin de suivre une personne dans le texte, le jeton stable du mode cohérent suffit. La table, elle, reste chez vous, à part, avec les mêmes précautions qu’un fichier nominatif, parce que c’en est un.
Elle se télécharge une seule fois. Ce n’est pas un détail d’interface. C’est une façon de réduire les copies. Une fois téléchargée, elle n’a plus à vivre sur le serveur de l’outil — les archives, de toute façon, sont éphémères. À vous ensuite de ne pas la recopier partout. Un coffre, un espace restreint, une destruction quand elle n’est plus nécessaire, valent mieux qu’une pièce jointe « au cas où ».
Si vous n’avez pas besoin de revenir aux identités, ne générez pas la table. L’option existe pour les cas où un retour est réellement nécessaire, par exemple pour corriger un dossier en interne, après analyse. Elle n’est pas un réflexe.
Avant d’envoyer un corpus à un modèle
Nous recommandons une liste courte. Quel est l’usage prévu ? Le corpus a-t-il été réduit à ce qui est utile ? Les identifiants directs ont-ils été remplacés ? Une relecture humaine a-t-elle eu lieu, surtout sur les alertes ? La table de correspondance, si elle existe, est-elle restée à part ? Le contrat du service d’IA, le lieu de traitement, la conservation, ont-ils été regardés ? Si une réponse manque, on n’envoie pas « pour voir ».
L’IA prépare. Elle n’a pas à connaître les personnes au-delà de ce que le projet a décidé de lui montrer. La confusion entre anonymiser et pseudonymiser est précisément ce qui fait partir, parfois, un fichier encore identifiant, avec sa clé de retour dans le même paquet.
Garder les mots justes, et les fichiers séparés
Pseudonymiser n’est pas anonymiser. La CNIL et l’avis 05/2014 du G29 le disent depuis longtemps. Notre anonymiseur s’inscrit dans le premier geste, utile, réversible, à relire. La table de correspondance reste un fichier nominatif. Elle ne voyage pas vers un modèle.
Si vous voulez poser cette discipline dans un projet, nous pouvons l’écrire avec vous, outil et règles compris. La page contact ou un rendez-vous suffisent. On part des documents réels, et des mots justes, plutôt que d’un vocabulaire trop rassurant.
