Anonymisation vs pseudonymisation : ce qui compte vraiment pour le RGPD

La pseudonymisation est définie par l'article 4(5) du RGPD : le traitement des données de telle façon qu'elles ne puissent plus être attribuées à une personne sans information supplémentaire. Remplacer un nom par un identifiant, hacher un e-mail, masquer un numéro de téléphone : tout cela est de la pseudonymisation. Les données restent des données à caractère personnel, et le RGPD continue de s'appliquer - y compris à vos environnements de dev et de test.

L'anonymisation, elle, est décrite par le considérant 26 : des données rendues anonymes de telle manière que la personne concernée n'est pas ou plus identifiable, en tenant compte de tous les moyens raisonnablement susceptibles d'être utilisés. Des données réellement anonymes sortent du champ du RGPD.

La pseudonymisation n'est pas un échec pour autant : c'est une mesure de minimisation et de sécurité explicitement reconnue par les articles 25 (protection des données dès la conception) et 32 (sécurité du traitement). Pour des copies de production en environnement de test, elle réduit déjà drastiquement le risque en cas de fuite.

Le Comité européen de la protection des données (EDPB, anciennement G29) évalue la robustesse d'une anonymisation avec trois critères d'attaque, au niveau du jeu de données entier :

1. Individualisation (singling out). Peut-on isoler l'enregistrement d'une personne ? Remplacer le nom ne suffit pas : la combinaison code postal + date de naissance + genre est unique pour une large partie de la population. Ces colonnes anodines sont des quasi-identifiants.
2. Corrélation (linkability). Peut-on relier deux enregistrements concernant la même personne, dans le même jeu de données ou en le croisant avec un autre ?
3. Inférence. Peut-on déduire, avec une probabilité significative, la valeur d'un attribut sensible à partir des autres ?

Un outil qui transforme les valeurs colonne par colonne - quel qu'il soit - ne neutralise aucun de ces critères à lui seul : il faut des garanties calculées sur l'ensemble du jeu de données.

Irréversibilité du hachage. La stratégie de hash utilise HMAC-SHA256 avec une clé éphémère générée à chaque exécution et détruite à la fin du run. Sans la clé, le mapping n'est pas reconstructible, même par attaque par dictionnaire sur des valeurs à faible cardinalité.

Quasi-identifiants et k-anonymat. La détection PII repère les quasi-identifiants (code postal, date de naissance, genre, profession…). Vous fixez un seuil k : un jeu de données est k-anonyme quand chaque combinaison de quasi-identifiants est partagée par au moins k lignes. À chaque run, Anonyx calcule les classes d'équivalence et applique votre politique : signaler les classes sous le seuil, les généraliser (tranches d'âge, codes postaux tronqués, plages de dates - sans supprimer de lignes), les supprimer, ou faire échouer le run en mode strict.

Un arbitrage assumé. Anonyx préserve l'intégrité référentielle : une même valeur source reçoit la même valeur anonymisée partout où elle apparaît, pour que vos jointures et vos clés étrangères survivent. Ce mapping cohérent maintient, par construction, une forme de corrélation interne au jeu de données - c'est le prix de données de test exploitables, et c'est documenté plutôt que caché.

La qualification anonymisation / pseudonymisation ne se décrète pas dans une plaquette marketing : elle s'évalue jeu de données par jeu de données, règles par règles. C'est pourquoi chaque exécution Anonyx produit un rapport de risque de ré-identification : seuil k visé et atteint, quasi-identifiants traités, lignes généralisées ou supprimées, stratégie appliquée colonne par colonne.

Ce rapport est l'élément de preuve que vous présentez à votre DPO ou à votre responsable de traitement pour trancher. Si le k-anonymat est satisfait, vous documentez la neutralisation du critère d'individualisation retenu par l'EDPB. S'il ne l'est pas, vous savez exactement quelles colonnes ajuster - ou vous assumez une pseudonymisation robuste, qui reste une mesure reconnue par les articles 25 et 32.

Le détail des stratégies et des contrôles est décrit sur la page fonctionnalités.