Données pseudonymisées : séparer la table de correspondance

Une table de correspondance doit rester inaccessible aux personnes qui n’ont besoin que du jeu pseudonymisé. La placer dans un fichier séparé ne suffit pas si les mêmes utilisateurs, comptes techniques ou outils de recherche peuvent ouvrir les deux ensembles. La protection repose sur une séparation effective, des rapprochements autorisés et une gestion des copies.

La bonne question est précise : qui doit pouvoir retrouver quelle identité, pour quelle opération ? À partir de cette réponse, vous pouvez rédiger une spécification d’accès, organiser les demandes de droits et décider du sort de la table à la fin du projet.

Définir les ensembles à séparer

L’Art. 4(5) du RGPD définit la pseudonymisation par le recours nécessaire à des informations supplémentaires pour attribuer les données à une personne précise. Ces informations doivent être conservées séparément et soumises à des mesures techniques et organisationnelles appropriées.

Décrivez trois éléments : le jeu utilisé par les analystes, la correspondance permettant le rapprochement et les données sources contenant les identités. Cette troisième composante compte : retirer l’accès à la table serait insuffisant si chacun peut refaire le rapprochement dans la base d’origine.

Une table peut relier un pseudonyme à un identifiant interne, sans contenir de nom. Elle reste une information supplémentaire sensible si cet identifiant ouvre ensuite le dossier nominatif. Inversement, recopier dans la table l’adresse, le téléphone et toutes les dates de naissance n’est pas nécessaire si un identifiant interne fiable suffit au besoin autorisé.

Notre guide sur la pseudonymisation et l’anonymisation explique la distinction juridique. Ici, l’organisme qui conserve les moyens de rapprochement continue à traiter des données personnelles. Le statut chez un autre destinataire demande une analyse de son contexte et de ses moyens ; le seul mot « pseudonymisé » ne tranche pas cette question pour tous les acteurs.

Spécification remplie : analyser les parcours de formation

Exemple de conception fictif. L’organisme Horizon veut comparer les parcours suivis dans ses formations, sans que les analystes connaissent les participants. Son fichier de travail P-6 contient un code de personne, un type de parcours, un mois d’entrée et un résultat pédagogique. L’analyse ne nécessite ni contact direct avec les participants ni texte libre sur leur situation.

Le registre opérationnel conserve les dossiers nominatifs nécessaires à la gestion des formations. Une table C-6 relie chaque code de P-6 à l’identifiant interne du participant. Le service chargé des droits peut ainsi retrouver les données à corriger. La légalité et la durée du traitement d’analyse doivent être établies par ailleurs : la pseudonymisation ne les remplace pas.

La spécification suivante est une proposition adaptée à ce projet, pas la description d’un logiciel testé.

Les habilitations sont attribuées à des personnes et comptes identifiés, pas à un groupe « projet » donnant tous les droits. Si une même personne cumule deux fonctions, son accès réel aux ensembles doit être reconnu dans l’analyse. Changer de rôle dans un tableau ne fait pas disparaître ce cumul.

Choisir des codes qui ne trahissent pas leur origine

Un code composé du nom, de l’année de naissance ou d’un matricule déjà connu peut permettre un rapprochement immédiat. Précisez ce que le code révèle et les autres fichiers dans lesquels il existe. Un pseudonyme commun à plusieurs projets facilite aussi leurs croisements ; cette liaison doit répondre à un besoin identifié.

Dans P-6, Horizon a besoin de suivre un participant entre plusieurs sessions du même programme. La spécification prévoit donc un code stable dans ce périmètre, sans réemploi automatique dans un projet sans lien. Elle exige également qu’un code ne rattache pas deux personnes différentes et qu’un changement de dossier ne crée pas un nouveau participant artificiel.

La CNIL décrit plusieurs techniques et souligne les risques de collisions ainsi que la sensibilité des informations de correspondance dans sa fiche sur la pseudonymisation en recherche. Le choix technique doit être examiné avec les responsables compétents ; un nom de fonction cryptographique ne démontre pas, à lui seul, la résistance de l’ensemble.

Le contrôle métier est tout aussi important : distinguer deux homonymes, garder le bon rattachement après une fusion de dossiers et empêcher la réattribution d’un ancien code à une autre personne. Ces règles protègent la confidentialité et l’exactitude des résultats.

Fermer les accès indirects

La séparation peut être logique si elle produit une protection effective et adaptée ; le RGPD n’impose pas universellement un serveur physique distinct pour toute table. Les Art. 25(1)/(2) et 32(1)/(2) imposent notamment une protection dès la conception, par défaut et proportionnée aux risques.

Examinez les droits hérités, comptes de service, exports automatiques et outils d’assistance. Une copie nocturne de C-6 déposée dans l’espace des analystes annulerait la restriction de l’interface principale. Un aperçu de recherche montrant les associations aurait le même effet sans téléchargement du fichier.

La gestion des habilitations du moteur de recherche interne doit donc couvrir la table, ses anciennes versions et ses pièces jointes. Vérifiez aussi les tickets de support : un exemple envoyé avec le code et le nom reconstitue une correspondance hors du circuit prévu.

Le chiffrement ajoute une protection, mais il faut connaître les détenteurs des clés et les possibilités d’administration. Le prestataire d’hébergement ou de maintenance n’obtient pas un droit général d’exploiter les correspondances. Lorsque la relation relève de la sous-traitance, les instructions et garanties doivent être encadrées conformément à l’Art. 28(3).

Une demande ciblée plutôt que l’ouverture de la table

Dans l’exemple fictif, le gestionnaire reçoit la demande D-41 de Léa, dont l’identité est vérifiée par le canal habituel approprié. Une session lui est attribuée à tort. Le gestionnaire retrouve son identifiant interne, puis les deux codes historiques associés dans C-6. L’existence de deux codes est expliquée par une migration documentée ; elle n’est pas ignorée au motif que la table courante n’en montre qu’un.

L’instruction transmise à l’équipe d’analyse indique les codes et la correction requise, sans envoyer le nom de Léa si celui-ci n’est pas nécessaire. L’analyste corrige les lignes concernées ; le gestionnaire vérifie que les deux versions encore utilisées sont couvertes. La réponse à Léa décrit la correction effectuée. Cette séquence illustre la procédure ; elle ne rapporte pas un essai réel.

La fiche de rapprochement peut être renseignée ainsi :

• Référence et motif : D-41, rectification d’une session attribuée à tort.
• Périmètre autorisé : recherche du dossier interne concerné et de ses codes P-6 ; aucun export global de C-6.
• Exécutant : gestionnaire des droits habilité ; équipe d’analyse destinataire des seuls codes utiles.
• Résultat : deux codes historiques retrouvés, deux ensembles actifs corrigés, contrôle du rattachement achevé.
• Trace conservée : référence de la demande, date, personnes intervenantes et opération ; pas de nouvelle copie intégrale de la correspondance.

Le niveau de validation dépend du risque : une seconde approbation peut être pertinente pour une extraction exceptionnelle, sans être une exigence légale uniforme pour chaque recherche. En cas de demande informelle d’un analyste souhaitant « comprendre qui se cache derrière ce profil », le gestionnaire ne communique pas l’identité sans motif compatible et autorisation appropriée.

Préserver les droits sans conserver artificiellement les identités

Tant que l’organisme peut identifier la personne à l’aide de ses moyens disponibles, il ne peut pas refuser une demande au seul motif que l’analyste ne connaît que des codes. Organisez le passage entre le point de contact et le détenteur habilité de la correspondance, sans ouvrir les identités à toute l’équipe.

L’Art. 11(1)/(2) n’impose pas de conserver ou d’obtenir des informations supplémentaires uniquement pour identifier une personne lorsque les finalités ne nécessitent pas cette identification. Il prévoit aussi les conséquences d’une impossibilité démontrée d’identifier et le cas où la personne fournit des éléments complémentaires permettant de le faire. L’Art. 12(2)/(6) encadre la facilitation des droits et les vérifications d’identité nécessaires.

Une table momentanément inaccessible n’est donc pas une preuve que l’organisme ne dispose plus de moyens d’identification. Cherchez les correspondances autorisées, documentez une difficulté réelle et respectez les délais de réponse applicables. Évitez de demander une copie complète de pièce d’identité si un élément moins intrusif suffit à lever le doute raisonnable.

Fin du projet : décider de la table et des copies

Fixez une durée ou des critères justifiés pour C-6, distincts de ceux de P-6 et des dossiers de formation. Une sauvegarde, un export d’assistance ou une ancienne version peut encore permettre le rapprochement. Leur sort doit figurer dans la décision de clôture, avec les restrictions et les conditions de restauration éventuelle.

La preuve d’effacement décrit les ensembles retirés et les limites résiduelles. Conserver une copie complète de C-6 « pour prouver sa destruction » créerait précisément la correspondance que l’opération entendait supprimer.

La disparition de C-6 ne démontre pas automatiquement que P-6 est anonyme : un parcours rare, une période ou une information publique peut encore permettre une identification. Le caractère identifiable s’apprécie dans le contexte pertinent. La présentation CNIL des travaux du CEPD de juillet 2026 rappelle cette approche ; les nouvelles lignes directrices sur l’anonymisation sont encore en consultation jusqu’au 30 octobre 2026.

Enfin, si une correspondance est exposée ou altérée, sécurisez les accès et examinez l’incident au titre des Art. 4(12), 33 et 34. Une table ne contenant que des codes internes peut malgré tout permettre une réidentification ; son contenu apparemment technique ne dispense pas d’évaluer les conséquences pour les personnes.

Ce qu’il faut retenir

• Séparez le jeu d’analyse, la correspondance et les données sources dans les accès effectifs.
• Autorisez les rapprochements par motif et périmètre ; évitez les exports globaux de la table.
• Couvrez les migrations, moteurs de recherche, comptes techniques et sauvegardes.
• La destruction de la table et l’anonymat du jeu restant sont deux conclusions distinctes.

FAQ

Une table sans noms doit-elle être protégée ?

Oui si elle permet de relier les codes à des dossiers identifiants. Décrivez la chaîne complète du rapprochement, y compris les identifiants internes et les accès aux données sources.

Faut-il toujours deux personnes pour réidentifier ?

Le RGPD ne fixe pas cette règle générale. Adaptez les validations au risque, à l’étendue de l’opération et aux fonctions. Une extraction complète appelle une justification différente d’une recherche ciblée nécessaire à un droit.

Peut-on utiliser les mêmes codes dans tous les projets ?

Ce choix facilite les rapprochements entre jeux. Ne l’adoptez que si ces liaisons sont nécessaires, licites et encadrées ; la commodité technique ne justifie pas à elle seule un identifiant transversal.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.