Tokenisation, hachage, chiffrement : que choisir pour pseudonymiser ?

Tokenisation, hachage et chiffrement sont tous rangés sous le mot pseudonymisation, et les mots se mélangent. Seuls certains d'entre eux permettent d'échanger un nom ou un numéro contre une étiquette qu'un lecteur peut encore suivre. Les autres transforment une valeur en un texte illisible, utile pour rapprocher des enregistrements, pas pour un document qu'une personne lit.

Que signifie la pseudonymisation selon le RGPD ?

Le RGPD définit la pseudonymisation à l'article 4, point 5. Il s'agit de traiter une donnée personnelle de façon à ce que personne ne puisse la relier à une personne sans informations supplémentaires. Ces informations supplémentaires doivent être conservées à part et protégées. Un pseudonyme seul ne retire pas son statut légal à la donnée personnelle.

Le Comité européen de la protection des données appelle ce cercle protégé le domaine de pseudonymisation dans ses lignes directrices de 2025. C'est l'ensemble de ceux qui ne doivent pas pouvoir attribuer la donnée par eux-mêmes. La technique choisie décide de la difficulté à entrer dans ce cercle.

Quelles sont les quatre façons de remplacer une valeur dans un document ?

L'ENISA, l'agence de cybersécurité de l'Union européenne, regroupe la pseudonymisation en quelques briques dans son guide de 2019. Quatre d'entre elles reviennent sans cesse dans les outils qui masquent un document.

La plus simple échange une valeur contre une étiquette issue d'un compteur ou d'un générateur aléatoire, comme transformer Claire Exemple en [NAME1]. Rien n'est calculé à partir de son nom. Celui qui fait l'échange tient une table reliant chaque étiquette à sa valeur : c'est le seul chemin de retour.

Une fonction de hachage cryptographique transforme l'e-mail de Claire en une chaîne fixe de lettres et de chiffres, toujours la même pour la même entrée. Personne n'a besoin d'un secret pour la calculer. C'est aussi son problème, comme l'explique la section suivante.

Un hachage à clé, souvent appelé HMAC, ajoute une clé secrète au calcul. Sans cette clé, personne ne peut reproduire la chaîne ni vérifier une hypothèse. L'ENISA qualifie cette technique de robuste, tant que la clé reste secrète.

Le chiffrement verrouille la valeur d'origine avec une clé et peut la restituer grâce au déchiffrement. C'est la seule des quatre techniques conçue pour être inversée volontairement. Comme un tiroir fermé à clé, elle est faite pour être rouverte par qui détient la clé.

Seule la première ligne garde un document lisible. Les trois autres transforment une valeur en bruit, exactement ce dont une base de données a besoin, et exactement ce qu'un document n'a pas besoin.

Pourquoi un simple hachage d'un nom ou d'un e-mail est-il faible ?

Un nom ou une adresse e-mail ne provient pas d'un ensemble illimité de possibilités. Qui veut casser le hachage peut hacher chaque candidat auquel il pense et comparer les résultats. Il n'a même pas besoin de deviner la fonction de hachage elle-même.

Le Comité européen de la protection des données donne cet exemple dans ses lignes directrices de 2025. Supposons qu'un attaquant sache qu'un jeu de données a été pseudonymisé par un simple hachage d'un nom. Il peut hacher chaque nom qu'il détient déjà ailleurs et voir lesquels correspondent.

• Une clé secrète transforme un hachage simple en hachage à clé, bien plus difficile à attaquer sans cette clé.
• Une fonction de hachage de mot de passe conçue pour être lente, comme argon2, ralentit les tentatives. L'ENISA et le BSI allemand recommandent tous deux ce type de fonction, selon les lignes directrices du CEPD.
• Un secret long et aléatoire, pas une date ni un mot court, ne donne rien à deviner à un attaquant.

Que signifie la tokenisation au sens des cartes bancaires ?

Dans la sécurité des paiements, la tokenisation a un sens plus étroit. Le PCI Security Standards Council fixe les règles des paiements par carte. Il définit un jeton comme une valeur de substitution au numéro de carte, et la « dé-tokenisation » comme l'étape qui restitue ce numéro.

Un jeton n'a pas besoin d'être construit en hachant le numéro de carte. Les lignes directrices du Council citent aussi un index, un numéro de séquence ou un nombre aléatoire comme moyens courants d'en générer un. Chaque jeton est mis en correspondance avec l'original dans une table sécurisée appelée coffre de données de carte.

Cela rapproche la tokenisation de paiement de la famille du compteur et de l'étiquette aléatoire, plutôt que du hachage ou du chiffrement. Sa sécurité tient à ce que cette table reste verrouillée, pas à des mathématiques secrètes derrière le jeton.

Quelle technique convient à un document que vous partagez pour la lecture ?

Un document est lu par une personne, donc ses valeurs masquées doivent rester courtes et cohérentes. [NAME1] doit désigner la même personne à chaque apparition, et un lecteur doit encore pouvoir suivre la phrase autour.

C'est pourquoi le mode Token d'ONYRI Sanitize, sur les formules Pro, construit ses étiquettes à partir d'un compteur plutôt que d'un hachage. Chaque valeur devient une courte étiquette comme [NAME1] ou [MAIL1], la même à chaque apparition. Le document reste ainsi lisible. Il n'y a ni clé de chiffrement ni bouton de restauration. La correspondance vit seulement dans votre onglet, alors gardez le fichier d'origine en lieu sûr.

Un hachage ou une chaîne chiffrée casserait cela aussi : le résultat ne ressemble plus à un nom, seulement à une suite de caractères. Une page pleine de texte qui ressemble à du bruit est aussi plus difficile à relire avant de l'envoyer.

Une liste de vérification rapide avant de choisir

• Vous lisez un document en tant que personne ? Utilisez des étiquettes cohérentes issues d'un compteur ou d'un générateur aléatoire, avec une table que vous contrôlez.
• Vous rapprochez des enregistrements entre bases sans les lire ? Un hachage à clé (HMAC) avec une vraie clé secrète est bien plus sûr qu'un hachage simple.
• Vous devez retrouver la valeur d'origine exacte plus tard ? Le chiffrement est la seule des quatre techniques conçue pour être inversée volontairement.
• Ne hachez jamais un nom, une adresse e-mail ou une valeur issue d'une liste courte et devinable sans clé secrète.
• Quel que soit votre choix, le RGPD continue de traiter le résultat comme une donnée pseudonymisée, pas anonymisée, donc vos obligations habituelles restent applicables.