Quand un Hash Est-il une Donnée à Caractère Personnel ? L'Arrêt SRB de la CJUE et l'Identité en Analytics

La question que tout fournisseur d'analytics esquive est simple à poser et difficile à trancher : l'identifiant dans votre base de données est-il une donnée à caractère personnel ? Le 4 septembre 2025, la CJUE a donné la réponse la plus lourde de conséquences depuis des années, en recentrant tout le test sur le contexte plutôt que sur la donnée isolée.

Ce qu'a réellement décidé EDPS contre SRB

L'affaire — EDPS contre SRB, C-413/23 P — est née de la résolution de Banco Popular. Le Conseil de résolution unique a recueilli les commentaires d'actionnaires, remplacé l'identité de chaque auteur par un code alphanumérique, et transmis les commentaires codés à Deloitte en tant qu'évaluateur indépendant. Deloitte ne disposait d'aucune clé pour inverser les codes ni d'aucune autre voie vers les auteurs.

La CJUE a jugé que les données pseudonymisées ne sont pas automatiquement des données à caractère personnel pour toute partie qui les manipule. Le caractère personnel d'un jeu de données s'apprécie par rapport à son détenteur — depuis la position du destinataire spécifique, en tenant compte des moyens techniques, organisationnels et juridiques dont il dispose réellement.

C'est le test de l'identifiabilité relative (ou contextuelle), et c'est la lecture opérante des « moyens raisonnablement susceptibles d'être utilisés » du considérant 26. Une donnée personnelle entre les mains du responsable du traitement peut être non personnelle entre les mains d'un destinataire qui ne peut véritablement réidentifier personne.

La tension avec le CEPD

La cour n'a pas accordé de blanc-seing aux fournisseurs. Les lignes directrices 01/2025 du CEPD sur la pseudonymisation adoptent une ligne délibérément plus stricte : les données pseudonymisées restent des données à caractère personnel tant que quiconque — le responsable ou un tiers — conserve les moyens de réidentifier. Le rapport du CEPD de février 2026 sur l'anonymisation et la pseudonymisation, c'est le comité en train de traiter précisément cet écart entre sa position et celle de la cour.

Pour les développeurs, la lecture pratique est prudente. Ne supposez pas qu'une valeur hachée sort du champ du RGPD au seul motif que votre service ne peut l'inverser. La bonne question est de savoir si la réidentification est raisonnablement probable pour quiconque détient l'information supplémentaire — et si cette information supplémentaire existe encore.

Pourquoi la plupart des hashs d'analytics échouent au test

Hacher un identifiant n'est pas une anonymisation. Un SHA-256 d'une adresse e-mail est déterministe : la même adresse produit toujours le même condensé. Quiconque dispose d'une liste d'e-mails candidats peut les hacher et les rapprocher. Le hash est une clé stable et reliable — pseudonymisation au mieux, et donnée personnelle sous l'une comme l'autre lecture, car les moyens de réidentifier sont trivialement disponibles.

Le même piège vaut pour une IP hachée, un identifiant d'appareil haché, ou tout condensé d'une entrée tirée d'un espace petit et énumérable. Déterminisme plus entrée devinable égale réidentification. La fonction de hachage change les octets, pas la reliabilité.

Ce qui rend un hash véritablement défendable

Deux propriétés font passer un hash de « donnée personnelle pseudonymisée » à « non raisonnablement réidentifiable » : un sel secret qui n'est jamais stocké avec la donnée, et une entrée qui ne peut être devinée de façon exhaustive et ne persiste pas dans le temps. Le modèle d'identité de Monoid repose exactement là-dessus :

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

L'IP et le User-Agent bruts ne vivent dans la mémoire du Worker que le temps de calculer le condensé ; D1 stocke le hash, jamais les entrées. Le SALT_SECRET est conservé côté serveur et jamais écrit à côté de la donnée, de sorte qu'une attaque par rainbow table ou par force brute contre les hashs stockés n'a aucun point d'ancrage. Et parce que la date est une entrée, le condensé du même visiteur tourne chaque minuit UTC. Il n'existe aucune clé stable inter-jours pour effectuer une corrélation.

Passez cette construction par les deux tests. Selon le standard relatif de la CJUE, aucun destinataire des hashs stockés — y compris Monoid interrogeant sa propre D1 — ne détient les moyens raisonnablement susceptibles de réidentifier, car le sel est séparé et l'entrée non énumérable. Selon le standard plus strict du « quiconque » du CEPD, l'information supplémentaire nécessaire (IP brute, plus UA, plus le sel secret de cette date précise) n'est conservée nulle part une fois la requête terminée. Les moyens de réidentifier ne sont pas seulement restreints : ils cessent d'exister.

Comment auditer votre propre stack

L'arrêt fournit une liste de contrôle concrète à appliquer à tout analytics dont vous dépendez :

• L'entrée hachée est-elle énumérable ? Un e-mail, un numéro de téléphone ou une IP brute peuvent être hachés et rapprochés d'une liste de candidats. Si l'espace d'entrée est petit, le hash est réversible en pratique.
• Un sel secret est-il séparé de la donnée stockée ? Un hash sans sel, ou avec un sel dans le même magasin, n'offre aucune barrière réelle à la réidentification.
• L'identifiant persiste-t-il entre les sessions ? Une clé stable qui relie l'activité d'une personne sur des semaines est une donnée personnelle sous toute lecture. Une clé qui tourne quotidiennement ne peut pas accumuler de profil.

La CJUE n'a pas érigé la pseudonymisation en zone refuge, et le CEPD veille à ce que personne ne la lise ainsi. La position durable est celle qui n'a besoin d'aucune interprétation pour l'emporter : un hash salé, à rotation quotidienne, sur une entrée non énumérable n'est raisonnablement réidentifiable par personne, car le matériel nécessaire pour l'inverser n'a jamais été conservé.

Sources

• Arrêt de la CJUE dans l'affaire C-413/23 P, CEPD contre CRU (4 septembre 2025)
• Lignes directrices 01/2025 du CEPD sur la pseudonymisation
• Rapport du CEPD sur l'événement avec les parties prenantes sur l'anonymisation et la pseudonymisation du 12 décembre 2025
• Considérant 26 du RGPD — Non applicable aux données anonymes