Glossaire

Sous le GDPR, la réversibilité tranche pseudonymisation vs anonymisation

Taras Shynkarenko
Taras Shynkarenko
•Mis à jour : •9 min de lecture
Sous le GDPR, la réversibilité tranche pseudonymisation vs anonymisationSous le GDPR, la réversibilité tranche pseudonymisation vs anonymisation

TL;DR, Réponse rapide

9 min de lecture

La pseudonymisation remplace un identifiant par un jeton que des informations supplémentaires permettent de reconstituer, et l'Article 4(5) du GDPR garde le résultat dans la définition des données personnelles. L'anonymisation supprime l'identifiabilité face à tous les moyens raisonnablement susceptibles d'être utilisés, et le Recital 26 fait alors sortir les données du règlement. Hacher une adresse IP ou un ID utilisateur relève de la pseudonymisation, car la plage des entrées est assez petite pour être repassée entièrement dans la fonction de hachage.

Qu'est-ce qui tranche pseudonymisation vs anonymisation sous le GDPR ?

Le GDPR tranche pseudonymisation vs anonymisation avec une seule question, celle de savoir si quelqu'un peut inverser la substitution : les données pseudonymisées peuvent être attribuées de nouveau à une personne à l'aide d'informations supplémentaires conservées séparément, elles restent donc des données personnelles et chaque obligation du règlement continue de s'appliquer, tandis que les données anonymisées ne peuvent être attribuées à une personne par aucun moyen raisonnablement susceptible d'être utilisé, si bien que le règlement cesse de s'y appliquer. Les informations supplémentaires sont le mécanisme : tant qu'une clé, une table de correspondance, un sel (la valeur aléatoire ajoutée avant le hachage) ou un journal source brut survit quelque part, les données sont pseudonymisées. Avant d'étiqueter un ensemble de données comme anonyme, trouvez chaque copie du matériel qui permettrait de l'inverser et vérifiez qu'elle a disparu.

Comment l'Article 4(5) du GDPR définit-il la pseudonymisation ?

L'Article 4(5) du règlement (UE) 2016/679 définit la pseudonymisation comme "le traitement de données à caractère personnel 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".

Lisez les conditions de cette phrase. La définition suppose que les informations supplémentaires existent toujours, exige leur conservation séparée et ne retire rien du champ du règlement. Le GDPR traite la pseudonymisation comme une garantie, pas comme une sortie : l'Article 25(1) la cite en exemple des mesures qu'un responsable du traitement met en oeuvre pour la protection des données dès la conception, et l'Article 32(1)(a) range "la pseudonymisation et le chiffrement des données à caractère personnel" parmi les mesures de sécurité.

Quel critère le Recital 26 fixe-t-il pour l'anonymisation ?

Le Recital 26 fixe un critère de moyens, pas un critère de technique, et cette phrase tranche la question : "Pour déterminer si une personne physique est identifiable, il convient de prendre en considération l'ensemble des moyens raisonnablement susceptibles d'être utilisés par le responsable du traitement ou par toute autre personne pour identifier la personne physique directement ou indirectement, tels que le ciblage."

La phrase suivante fournit les facteurs : "il convient de prendre en considération l'ensemble des facteurs objectifs, tels que le coût de l'identification et le temps nécessaire à celle-ci, en tenant compte des technologies disponibles au moment du traitement et de l'évolution de celles-ci."

Puis le considérant trace la ligne. "Il n'y a dès lors pas lieu d'appliquer les principes relatifs à la protection des données aux informations anonymes, à savoir les informations ne concernant pas une personne physique identifiée ou identifiable, ni aux données à caractère personnel rendues anonymes de telle manière que la personne concernée ne soit pas ou plus identifiable." Le Recital 26 statue sur les données pseudonymisées dans sa phrase d'ouverture, en disant que les données qui "pourraient être attribuées à une personne physique par le recours à des informations supplémentaires devraient être considérées comme des informations concernant une personne physique identifiable". Le coût, le temps et la technologie bougent tous, donc une déclaration d'anonymisation faite en 2019 exige un nouveau test maintenant.

Racks de serveurs avec des câbles réseau enchevêtrés, représentant les données brutes d'identifiants soumises au hachage.

Pourquoi hacher une adresse IP ou un ID utilisateur relève-t-il de la pseudonymisation ?

Hacher un identifiant tiré d'un ensemble petit et connu relève de la pseudonymisation, car un attaquant peut hacher chaque entrée possible et comparer les résultats à votre table. Le travail a la taille de l'espace des entrées :

candidate inputs to test = 2 ^ (bits in the identifier)

Une adresse IPv4 fait 32 bits de large, donc tout l'espace des candidats vaut 2^32 = 4 294 967 296 adresses. Récupérer chaque adresse originale dans une table d'adresses IPv4 hachées en SHA-256 revient à hacher 4 294 967 296 valeurs une fois et à comparer. Les ID utilisateur séquentiels sont pires : une table qui numérote les utilisateurs de 1 à 5 000 000 compte 5 000 000 candidats, 859 fois moins que l'espace IPv4.

Le groupe de travail Article 29 l'a écrit noir sur blanc dans l'avis 05/2014 sur les techniques d'anonymisation (WP216), adopté le 10 avril 2014 : "si un ensemble de données a été pseudonymisé en procédant au hachage du numéro d'identification national, il peut être reconstitué simplement en appliquant la fonction de hachage à toutes les valeurs possibles et en comparant les résultats avec les valeurs figurant dans l'ensemble de données". L'avis énonce la conclusion sans détour : "la pseudonymisation n'est pas une méthode d'anonymisation. Elle réduit simplement la corrélation d'un ensemble de données avec l'identité originale d'une personne concernée et constitue par conséquent une mesure de sécurité utile." WP216 classe le hachage parmi les techniques de pseudonymisation et nomme la croyance qu'un ensemble de données pseudonymisé serait anonymisé comme une erreur courante.

Le salage change l'arithmétique, pas la catégorie. WP216 le formule ainsi : l'utilisation d'une fonction de hachage avec salage "permet de réduire la probabilité de reconstituer la valeur d'entrée. Il reste néanmoins possible, avec des moyens raisonnables, de calculer la valeur originale de l'attribut qui se cache derrière le résultat d'une fonction de hachage avec salage". Demandez à votre fournisseur d'analytique quel choix il fait, et qui détient le sel.

Comment un identifiant haché est inversé
1
Fixer la fonction de hachage. L'attaquant identifie ou devine quelle fonction a produit la table, par exemple SHA-256.
2
Hacher chaque valeur candidate. 2^32 pour une adresse IPv4, ou 5 000 000 pour des ID utilisateur séquentiels.
3
Comparer les résultats à la table. Chaque correspondance révèle l'identifiant d'origine derrière le hachage.
Le WP216 décrit exactement cette attaque par rejeu pour les numéros d'identification hachés et classe le hachage comme de la pseudonymisation, pas de l'anonymisation.

Qu'est-ce qui change quand les données sont pseudonymisées au lieu d'être anonymisées ?

Chaque obligation attachée aux données personnelles s'attache aux données pseudonymisées et se détache des données anonymes.

QuestionDonnées pseudonymiséesDonnées anonymisées
Réversibles avec des informations supplémentairesOuiNon
Comptent comme données personnellesOuiNon
Exigent une base légale de l'Article 6OuiNon
Droits d'accès et d'effacement du Chapter IIIS'appliquentNe s'appliquent pas
Notification de violation de l'Article 33S'appliqueNe s'applique pas
Techniques que WP216 place iciHachage, hachage avec salage, hachage par clé, chiffrement à clé secrète, tokenisationAgrégation, généralisation, ajout de bruit

WP216 juge chaque technique candidate face à trois risques : isoler les enregistrements d'une personne, relier deux enregistrements à la même personne et déduire la valeur d'un attribut à partir d'autres attributs. Une technique qui laisse l'un des trois ouvert n'a pas produit de données anonymes.

Un avocat examine un document juridique imprimé, illustrant l'évaluation au cas par cas que les tribunaux appliquent aux données pseudonymisées.

Des données pseudonymisées peuvent-elles cesser d'être des données personnelles ?

Elles le peuvent, pour un détenteur précis, et la Court of Justice of the European Union l'a dit dans EDPS v SRB, Case C-413/23 P, rendu le 4 septembre 2025. Au point 86, la Cour a jugé que "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 aux fins de l'application du règlement 2018/1725", le règlement qui couvre les institutions de l'UE, dont la définition des données personnelles est, au point 52, "en substance identique" à celle de l'Article 4(1) du GDPR. L'appréciation se fait par détenteur : un destinataire sans accès aux informations supplémentaires occupe une position différente de celle du responsable du traitement qui les a produites. Le critère qui sépare un responsable du traitement d'un sous-traitant désigne à qui revient ce jugement. Ce n'est pas une licence pour réétiqueter vos propres journaux hachés en anonymes tant que la clé se trouve dans votre propre magasin de clés.

Flowsery
Flowsery

Commencez votre essai gratuit de 14 jours

Tableau de bord en temps réel

Suivi des objectifs

Suivi sans cookies

Que doit faire une équipe analytique face à cela ?

Cessez de collecter l'identifiant au lieu de le hacher, car un identifiant haché garde attachée à l'enregistrement chaque obligation du GDPR. Flowsery est construit ainsi : sans cookie, hébergé dans l'UE et GDPR by design, exposé sur la page analytique respectueuse de la vie privée et dans les notes GDPR de Flowsery. Des pages liées traitent de la question de savoir si une adresse IP est une donnée personnelle, du masquage des champs sensibles en session replay, de l'analytique qui fonctionne sans cookies et de l'analytique conforme au GDPR sans bandeau de consentement.

Cette page décrit ce que disent les instruments, avis et arrêts cités, et ne constitue pas un conseil juridique.

Questions fréquentes

Les données pseudonymisées restent-elles des données personnelles sous le GDPR ?

Oui. L'Article 4(5) définit la pseudonymisation comme un traitement qui coupe l'attribution à une personne concernée "sans avoir recours à des informations supplémentaires", ce qui signifie qu'avec elles l'attribution est possible. Le Recital 26 énonce que les données qui pourraient être attribuées à une personne par le recours à des informations supplémentaires devraient être considérées comme des informations concernant une personne physique identifiable.

Le GDPR s'applique-t-il aux données anonymisées ?

Non. Le Recital 26 énonce qu'il n'y a pas lieu d'appliquer les principes relatifs à la protection des données aux informations anonymes, "à savoir les informations ne concernant pas une personne physique identifiée ou identifiable, ni aux données à caractère personnel rendues anonymes de telle manière que la personne concernée ne soit pas ou plus identifiable". Le même considérant ajoute que le règlement ne s'applique pas au traitement de telles informations, y compris à des fins statistiques ou de recherche.

Hacher une adresse IP suffit-il à l'anonymiser ?

Non. Une adresse IPv4 compte 2^32 = 4 294 967 296 valeurs possibles, donc quiconque détient la table hachée peut toutes les hacher et faire correspondre la sortie. WP216 décrit exactement cette attaque par rejeu pour des numéros d'identification hachés et classe le hachage comme technique de pseudonymisation. Le salage élève le travail par ensemble de données sans changer le classement.

Qu'est-ce que le critère des "moyens raisonnablement susceptibles d'être utilisés" ?

C'est le critère d'identifiabilité du Recital 26 : "il convient de prendre en considération l'ensemble des moyens raisonnablement susceptibles d'être utilisés par le responsable du traitement ou par toute autre personne pour identifier la personne physique directement ou indirectement, tels que le ciblage". Le considérant nomme ensuite les facteurs objectifs à peser : le coût de l'identification, le temps nécessaire et les technologies disponibles. Le critère couvre les moyens à la portée de n'importe qui, pas seulement des vôtres.

La pseudonymisation réduit-elle les obligations du GDPR ?

Elle change la façon dont un responsable du traitement satisfait ses obligations sans les supprimer. Le Recital 28 dit que la pseudonymisation des données "peut réduire les risques pour les personnes concernées et aider les responsables du traitement et les sous-traitants à remplir leurs obligations en matière de protection des données", et l'Article 32(1)(a) la compte comme mesure de sécurité. Aucune des deux dispositions ne retire une seule obligation de l'enregistrement.

Qui décide qu'un ensemble de données compte comme anonymisé ?

Le responsable du traitement conduit l'appréciation et doit pouvoir la défendre, car le Recital 26 bâtit le critère autour du coût, du temps et des technologies disponibles au lieu d'une liste de techniques approuvées. WP216 fournit les trois questions auxquelles répondre : isolement, corrélation, inférence. Un oui à l'une d'elles signifie que l'ensemble de données est pseudonymisé, pas anonymisé.

Le chiffrement relève-t-il de la pseudonymisation ou de l'anonymisation ?

Le chiffrement relève de la pseudonymisation tant que quelqu'un détient la clé, car le texte chiffré peut être inversé avec des informations supplémentaires tout comme une table hachée. Le WP216 range le chiffrement à clé secrète aux côtés du hachage et de la tokenisation parmi les techniques de pseudonymisation, pas d'anonymisation. L'Article 32(1)(a) regroupe pseudonymisation et chiffrement comme mesures de sécurité pour les données personnelles, ce qui n'a de sens que si les données chiffrées comptent encore comme données personnelles.

Quelles techniques le WP216 classe-t-il comme anonymisation ?

Le WP216 place l'agrégation, la généralisation et l'ajout de bruit du côté de l'anonymisation, séparées du hachage, du hachage salé, du hachage à clé, du chiffrement à clé secrète et de la tokenisation, qu'il range en pseudonymisation. Une technique ne mérite l'étiquette anonymisation que lorsqu'elle ferme les trois risques testés par le WP216 : l'individualisation des données d'une personne, le lien entre deux enregistrements pour la même personne, et l'inférence d'un attribut à partir d'autres attributs. Si l'un de ces trois risques reste ouvert, le jeu de données demeure pseudonymisé.

Une entreprise qui reçoit des données hachées d'une autre entreprise peut-elle les traiter comme anonymes ?

Seulement si cette entreprise n'a aucun accès aux informations supplémentaires nécessaires pour les inverser. La Cour de justice de l'Union européenne a jugé dans EDPS v SRB que les données pseudonymisées ne sont pas des données personnelles "in all cases and for every person", ce qui fait que l'évaluation se fait par destinataire plutôt que par jeu de données. Un destinataire sans accès à la clé ou à la table de correspondance ne se trouve pas dans la même position que le responsable qui a généré les données et les détient encore.

Pourquoi une évaluation d'anonymisation ne peut-elle pas rester valable indéfiniment ?

Le Recital 26 lie l'identifiabilité aux coûts, au temps et à la technologie disponible, trois facteurs qui évoluent avec la puissance de calcul et l'amélioration des techniques. Un jeu de données dont la réidentification prenait trop de temps en 2019 peut devenir identifiable dès qu'un matériel plus rapide ou de nouvelles méthodes réduisent ce coût. Le statut d'anonymisation doit être retesté face à la technologie actuelle plutôt que considéré comme acquis pour toujours.

Cet article vous a-t-il été utile ?

Dites-nous ce que vous en pensez !

Nous voir plus souvent sur Google

Un clic définit Flowsery comme source préférée. Nos articles remontent alors dans vos À la une, en mode IA et dans les aperçus IA.

Avant de partir...

Flowsery

Flowsery

Des analyses orientées revenus pour votre site web

Suivez chaque visiteur, source et conversion en temps réel. Simple, puissant et sans cookies.

Tableau de bord en temps réel

Suivi des objectifs

Suivi sans cookies

Termes connexes du glossaire

Sous le GDPR et le CCPA, une adresse IP est une donnée personnelle ?Sous le GDPR et le CCPA, une adresse IP est une donnée personnelle ?
Glossaire

Sous le GDPR et le CCPA, une adresse IP est une donnée personnelle ?

Sous le GDPR, une adresse IP est une donnée personnelle dès que l'exploitant dispose des moyens légaux d'identifier le visiteur, a jugé le CJEU dans Breyer.

•9 min de lecture
Comprendre le CPRA, la loi californienne sur les droits à la vie privéeComprendre le CPRA, la loi californienne sur les droits à la vie privée
Glossaire

Comprendre le CPRA, la loi californienne sur les droits à la vie privée

Le CPRA a modifié le CCPA en 2023 en ajoutant des règles sur les informations personnelles sensibles, un droit de rectification et une agence dédiée, la CPPA.

•8 min de lecture
Le test qui tranche responsable du traitement vs sous-traitantLe test qui tranche responsable du traitement vs sous-traitant
Glossaire

Le test qui tranche responsable du traitement vs sous-traitant

Le test du GDPR pour responsable du traitement vs sous-traitant: qui détermine les finalités et les moyens. Ce que chaque rôle signe, doit et notifie.

•10 min de lecture
Google recense sept causes distinctes de not set dans GA4Google recense sept causes distinctes de not set dans GA4
Glossaire

Google recense sept causes distinctes de not set dans GA4

Google donne à not set dans GA4 une cause par dimension, d'un session_start absent à un content_group vide. Voici chaque cause et le correctif associé.

•9 min de lecture
Ce que le server-side tracking corrige, et ce qu'il laisse intactCe que le server-side tracking corrige, et ce qu'il laisse intact
Glossaire

Ce que le server-side tracking corrige, et ce qu'il laisse intact

Ce que le server-side tracking déplace sur votre serveur, les plafonds de cookies Safari qu'il évite, la déduplication des événements et le consentement dû.

•9 min de lecture
Ce que ces chiffres disent du taux de rebond moyen par secteurCe que ces chiffres disent du taux de rebond moyen par secteur
Glossaire

Ce que ces chiffres disent du taux de rebond moyen par secteur

Neuf secteurs suivis affichent un taux de rebond moyen par secteur documenté allant de 35.76% à 48.38%, selon les données Databox datées de septembre 2024.

•7 min de lecture

Articles connexes