TL;DR, Réponse rapide
9 min de lectureLa 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.

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.
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.
| Question | Données pseudonymisées | Données anonymisées |
|---|---|---|
| Réversibles avec des informations supplémentaires | Oui | Non |
| Comptent comme données personnelles | Oui | Non |
| Exigent une base légale de l'Article 6 | Oui | Non |
| Droits d'accès et d'effacement du Chapter III | S'appliquent | Ne s'appliquent pas |
| Notification de violation de l'Article 33 | S'applique | Ne s'applique pas |
| Techniques que WP216 place ici | Hachage, hachage avec salage, hachage par clé, chiffrement à clé secrète, tokenisation | Agré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.

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.
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
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, 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.


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.


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.


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é.
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û.


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.
Articles connexes


Comprendre la formule de la valeur moyenne des commandes étape par étape
La formule de la valeur moyenne des commandes divise le revenu par les commandes, et un simple code de remise peut fausser en silence chaque chiffre publié.


Comment les sites B2B et B2C se comparent sur les benchmarks de durée moyenne de session
Les propres données de Databox situent les benchmarks de durée moyenne de session à 77.61 secondes pour le B2B et 92.33 secondes pour le B2C, par secteur.


Ce que la durée moyenne de session mesure vraiment
En analytics classique, la durée moyenne de session donne zéro temps à la dernière page vue de chaque session et tire la moyenne vers le bas discrètement.

