Table de correspondance et pseudonymisation : les règles du RGPD

Qu'est-ce qu'une table de correspondance ?

Pseudonymiser un document, c'est remplacer ce qui identifie une personne par un substitut : « Élise Garnier » devient [PERSONNE_1], « Garnier Immobilier SAS » devient [ORGANISATION_1]. La table de correspondance garde le lien entre les deux :

C'est elle qui rend la pseudonymisation réversible : grâce à elle, on peut remettre les vrais noms dans la réponse d'une IA, ou retrouver qui se cache derrière une étiquette. C'est aussi le fichier le plus sensible du dossier, puisqu'il réunit tous les noms en un seul endroit. Les exemples ci-dessus sont fictifs.

Pour pseudonymiser un document avant une IA, c'est presque toujours une table qu'on utilise, plutôt qu'une clé de chiffrement. Si la différence entre pseudonymiser et anonymiser n'est pas claire, commencez par anonymisation ou pseudonymisation : la différence selon le RGPD.

Que dit le RGPD sur la table de correspondance ?

Le mot « table » n'y figure pas, mais la définition en dépend entièrement. L'article 4, point 5, définit la pseudonymisation comme le traitement de données personnelles « de telle façon que celles-ci ne puissent plus être attribuées à une personne concernée précise sans avoir recours à des informations supplémentaires, pour autant que ces informations supplémentaires soient conservées séparément et soumises à des mesures techniques et organisationnelles afin de garantir que les données à caractère personnel ne sont pas attribuées à une personne physique identifiée ou identifiable ».

Trois conséquences pratiques :

• Pas de séparation, pas de pseudonymisation. Une copie qui voyage avec sa table, ou une table collée dans la même conversation que la copie, ne remplit pas la condition « conservées séparément ».
• La copie reste une donnée personnelle. Le considérant 26 le dit : des données pseudonymisées qui pourraient être attribuées à une personne grâce à des informations supplémentaires concernent une personne identifiable. Le RGPD continue de s'appliquer, mais le risque est réduit.
• La table relève de la sécurité. L'article 32 cite « la pseudonymisation et le chiffrement des données à caractère personnel » parmi les mesures adaptées au risque, avec les moyens de « rétablir la disponibilité » des données après un incident. Les deux s'appliquent à la table : la protéger, et ne pas la perdre.

L'article 34 donne une raison de plus de chiffrer : en cas de violation de données, l'information de chaque personne concernée n'est pas exigée lorsque des mesures ont rendu les données « incompréhensibles pour toute personne qui n'est pas autorisée à y avoir accès, telles que le chiffrement ». Une table volée en clair, à l'inverse, expose tous les clients du dossier d'un coup.

Que recommande le CEPD ? Le domaine de pseudonymisation

Le Comité européen de la protection des données (CEPD, ou EDPB en anglais) a adopté le 16 janvier 2025 ses lignes directrices 01/2025 sur la pseudonymisation, soumises à consultation publique jusqu'au 14 mars 2025. À la date de cet article, le site du CEPD ne publie que cette version de consultation. Quatre points s'appliquent directement à la table de correspondance.

1. La table est un secret de pseudonymisation, et une donnée personnelle. Le CEPD appelle « secrets de pseudonymisation » les clés et les tables qui font correspondre les pseudonymes aux données personnelles qu'ils remplacent (point 85). Il en tire la conséquence : les tables de correspondance « sont des données personnelles, puisqu'elles permettent l'identification des personnes concernées », et doivent être protégées contre l'accès et l'usage non autorisés (point 93). Les citations du CEPD sont traduites de l'anglais par nos soins. Les originaux que vous gardez font eux aussi partie des informations supplémentaires à tenir séparées (note 21).

2. Le domaine de pseudonymisation. C'est le contexte dans lequel la pseudonymisation doit empêcher de retrouver les personnes : les personnes qui y opèrent, leurs moyens, leurs systèmes (point 35). Le responsable du traitement le définit lui-même, par exemple « un seul destinataire externe » ou l'ensemble des destinataires prévus (point 38). Il doit ensuite garantir que les informations supplémentaires « n'entrent pas » dans ce domaine et que les données pseudonymisées n'en sortent pas sans autorisation (points 40 et 111).

Pour un cabinet qui confie une copie à une IA, le domaine comprend au minimum le fournisseur de l'IA et ses systèmes. La règle devient très concrète : rien de ce qui permet de lever les pseudonymes ne doit entrer dans la conversation, le projet, les instructions personnalisées ou les fichiers déposés dans l'outil.

3. Des pseudonymes tirés au hasard. Quand on utilise une table, « il suffit de choisir des pseudonymes générés aléatoirement » (point 107). Un pseudonyme ne doit pas se déduire de la valeur d'origine : pas d'initiales, pas de fragment de nom, pas de hachage simple d'un identifiant prévisible (l'exemple des taxis de New York est détaillé dans notre article sur le risque de ré-identification).

4. Des tables aussi petites que possible. Le CEPD distingue les pseudonymes qui suivent une personne partout, plus risqués, de ceux qui ne valent que pour une relation ou une opération. Il demande de définir les ensembles pseudonymisés de façon cohérente « aussi petits que possible » (points 116 à 121). Pour un cabinet, cela plaide pour une table par dossier plutôt qu'une table unique pour tous les clients : une fuite n'expose qu'une affaire, et deux dossiers ne peuvent pas être reliés par leurs étiquettes.

Que change l'arrêt SRB de la Cour de justice ?

Le 4 septembre 2025, dans l'affaire C-413/23 P, CEPD contre CRU (le Conseil de résolution unique, SRB en anglais), la Cour de justice a jugé une transmission de commentaires pseudonymisés au cabinet Deloitte. L'arrêt interprète le règlement 2018/1725, qui s'applique aux institutions européennes, mais ses définitions sont alignées sur celles du RGPD. La Cour a annulé l'arrêt du Tribunal et lui a renvoyé l'affaire.

Deux enseignements comptent pour la table de correspondance :

• Le point de vue du destinataire compte. Des données pseudonymisées « ne doivent pas être considérées comme constituant, en toute hypothèse et pour toute personne, des données à caractère personnel », car la pseudonymisation peut empêcher des personnes autres que le responsable du traitement d'identifier la personne concernée (point 86). Cela ne vaut que si le destinataire n'a pas accès à la table ni à d'autres moyens raisonnables de réidentifier.
• Pour le cabinet, rien ne change. Celui qui détient la table traite toujours des données personnelles. La Cour juge que, pour l'obligation d'information, le caractère identifiable s'apprécie « au moment de la collecte des données et du point de vue du responsable du traitement » (point 111).

Le CEPD en tire une précision utile dans ses lignes directrices 02/2026 sur l'anonymisation, adoptées le 7 juillet 2026 pour consultation publique : quand une entité traite des données pour le compte d'un responsable, leur caractère personnel s'apprécie du point de vue de ce responsable, et cette entité est un sous-traitant (point 15). En clair, l'arrêt SRB n'est pas une raison de se passer du contrat de sous-traitance avec le fournisseur d'IA : la pseudonymisation réduit le risque, elle ne remplace pas le cadre contractuel. Sur ce contrat, voir ChatGPT et RGPD : peut-on y mettre des données clients ?

Que recommande la CNIL ?

La CNIL a précisé les attentes sur la table de correspondance dans sa fiche sur l'anonymisation et la pseudonymisation (13 janvier 2022). Écrite pour la recherche scientifique, elle s'applique telle quelle à un dossier client :

• La confidentialité des éléments « (table de correspondance, « sel », clé de chiffrement, etc.) » doit être assurée par des mesures techniques et organisationnelles appropriées.
• Ces informations ne doivent pouvoir être consultées « que par des personnes autorisées et dans des conditions préalablement spécifiées ». L'exemple de la CNIL : le responsable d'une recherche y a accès, pas les chargés d'études qui travaillent à ses côtés.
• Une clé de chiffrement doit être « conservée de façon sécurisée et accessible uniquement par les personnes autorisées », avec une méthode de chiffrement « conforme à l'état de l'art ».
• Quand il n'y a plus besoin de revenir à l'identité des personnes, le choix peut être fait de supprimer ces informations, en gardant en tête que les données restantes peuvent encore permettre une identification indirecte.

Côté avocats, le guide du CNB sur l'IA (avril 2026) recommande de pseudonymiser ou d'anonymiser « systématiquement » avant tout usage d'une IA générative et d'être « attentif au risque d'identification indirecte par croisement de données ». Dans sa grille d'évaluation des outils d'IA, il retient aussi le chiffrement des données des clients au repos « avec un algorithme de chiffrement suffisant, tel que l'AES-256 », la clé étant détenue et gérée par le cabinet (p. 26).

Quelles règles pratiques pour un cabinet ?

Voici huit règles qui traduisent ces textes pour un cabinet, un office ou une direction juridique qui confie des copies pseudonymisées à une IA.

Si votre ordinateur est sauvegardé en entier (Time Machine, sauvegarde du service informatique), la table y est copiée avec le reste, et effacer un dossier ne supprime pas ces copies anciennes : c'est la rotation des sauvegardes qui fixe leur durée de vie. D'où l'intérêt d'une table chiffrée.

Que se passe-t-il quand on détruit la table ?

Trois effets, dont un seul est souvent attendu.

1. La réinjection devient impossible. Plus rien ne permet de remplacer [PERSONNE_1] par le vrai nom dans une réponse de l'IA.
2. La copie ne devient pas anonyme pour autant. La CNIL le rappelle : une fois les informations supprimées, « les données restantes peuvent cependant toujours permettre une identification indirecte des personnes et demeurent alors soumises au respect du RGPD ». Un numéro de RG, une date d'audience ou un montant au centime désignent encore l'affaire. Et tant que le cabinet garde les originaux, il peut toujours relier la copie aux personnes : pour lui, elle reste une donnée personnelle.
3. Les copies déjà envoyées ne reviennent pas. Détruire la table ne retire rien chez le fournisseur de l'IA : la conversation, les fichiers déposés et leur durée de conservation dépendent de ses conditions et de vos réglages. La table protège la copie, elle ne la rappelle pas.

À l'inverse, perdre la table par accident (disque en panne, poste remplacé sans transfert) produit le même effet que la détruire : les exports déjà faits ne peuvent plus être réinjectés. Décidez donc en amont, par écrit, combien de temps la table doit vivre, et prévoyez sa sauvegarde ou acceptez sa perte. Pour la méthode complète, de la copie à la réponse, voir pseudonymiser un document pour l'IA, puis remettre les vrais noms.

Comment AnonymFiles gère la table de correspondance

AnonymFiles applique ces règles par conception. Ce qui suit est décrit dans sa documentation technique et sur la page sécurité :

• Une table par dossier, sur le poste. Chaque dossier préparé a son espace privé dans le dossier utilisateur (sur Mac, sous ~/Library/Application Support, avec des droits réservés à votre compte ; sur Windows, sous %APPDATA%). Une même personne garde la même étiquette dans toutes les pièces du dossier, et les étiquettes se renomment.
• Chiffrée. Les correspondances sont chiffrées au repos en AES-256-GCM, avec une clé de 256 bits créée sur l'ordinateur et protégée par le trousseau du système.
• Jamais dans l'export. L'export contient les copies relues et un index des pièces, jamais la table. Rien ne part vers l'éditeur : pas de compte, pas de cloud, pas de télémétrie.
• Réinjection sur le poste. La réponse de l'IA revient avec ses étiquettes, et l'application remet les vrais noms sur l'ordinateur, en texte, en Word ou en PDF.
• Effacement avec le dossier. Retirer un dossier de la bibliothèque supprime, après confirmation, son espace privé : copies, correspondances, index de recherche et règles. Les originaux ne sont jamais touchés. La réinjection des exports de ce dossier devient alors impossible.

Comme l'application ne transmet ni document ni table à son éditeur, aucun contrat de sous-traitance n'est nécessaire pour l'étape de pseudonymisation elle-même ; celui qui vous lie au fournisseur de l'IA reste nécessaire. Deux limites honnêtes : la protection de la table dépend aussi de celle de votre session (mot de passe, verrouillage de l'écran), et l'application ne gère pas à votre place les sauvegardes de votre ordinateur. Le fonctionnement pas à pas est décrit dans comment fonctionne AnonymFiles ; pour les cabinets, voir aussi la page logiciel de pseudonymisation pour avocats et les tarifs.