Pseudonymisation (Bêta)

Fonctionnalité Bêta

La pseudonymisation est actuellement en bêta. L'API et le comportement peuvent évoluer dans les prochaines versions.

La pseudonymisation est une technique de protection des données qui remplace les informations personnellement identifiables (PII) par des identifiants artificiels, réduisant ainsi le risque de réidentification directe tout en préservant la structure des données. Dans la plateforme Avatar, la pseudonymisation est disponible en tant qu'étape de post-traitement optionnelle qui complète le processus d'anonymisation.

remarque

La pseudonymisation et l'anonymisation servent des objectifs différents mais complémentaires. L'anonymisation (via la méthode Avatar) protège contre la réidentification par transformation statistique, tandis que la pseudonymisation remplace les identifiants directs par des substituts. Utilisées ensemble, elles offrent une protection renforcée de la vie privée.

Pourquoi pseudonymiser ?

Lorsque vous travaillez avec des jeux de données sensibles, les identifiants directs tels que les noms, adresses e-mail ou numéros de sécurité sociale doivent être traités avec soin. Bien que la méthode d'anonymisation Avatar opère sur des données pseudonymisées (sans identifiants directs), vous pouvez avoir besoin de :

• Conserver les colonnes PII en sortie avec des remplacements réalistes mais fictifs pour les tests ou démonstrations
• Maintenir l'intégrité référentielle entre tables liées — en veillant à ce qu'un identifiant patient dans une table enfant référence toujours correctement son parent
• Se conformer aux politiques de traitement des données qui exigent le remplacement systématique des PII plutôt que leur simple suppression
• Simplifier votre flux de travail en gérant pseudonymisation et anonymisation dans un seul pipeline

Fonctionnement

La pseudonymisation dans la plateforme Avatar est appliquée après la fin du processus d'anonymisation. Le pipeline fonctionne comme suit :

1. Avant l'anonymisation : les colonnes PII sont extraites et mises de côté — elles ne participent pas à la modélisation statistique de la méthode Avatar
2. Anonymisation : la méthode Avatar génère des données synthétiques à partir des variables non-PII
3. Après l'anonymisation : chaque colonne PII est pseudonymisée selon la stratégie configurée, et les valeurs résultantes sont rattachées aux données anonymisées
4. Sortie : le jeu de données final contient des données statistiques anonymisées accompagnées d'identifiants pseudonymisés

Cette séparation garantit que la qualité de l'anonymisation n'est pas affectée par la présence d'identifiants directs.

Stratégies de pseudonymisation

Six classes de stratégie sont disponibles, chacune adaptée à des cas d'usage différents. Toutes les stratégies (sauf HashSha256Strategy et ConstantStrategy) acceptent un paramètre consistent : lorsqu'il vaut True (valeur par défaut), la même valeur source est toujours remplacée par la même valeur de remplacement au sein d'une exécution du pipeline, préservant ainsi l'intégrité référentielle entre les tables.

FakeDataStrategy — Valeurs synthétiques réalistes

Génère des valeurs fictives plausibles correspondant au type de PII. Par exemple, une colonne e-mail produit des adresses e-mail réalistes, une colonne de nom produit des noms réalistes.

• Idéal pour : les tests, démonstrations et scénarios où les données de sortie doivent paraître réalistes
• Nécessite : le type de PII doit être spécifié via pii_type (ex. PiiType.EMAIL, PiiType.FIRST_NAME)
• Exemple : FakeDataStrategy(pii_type=PiiType.EMAIL)

Paramètre high_variability

Le paramètre high_variability contrôle le compromis entre vitesse et unicité des valeurs générées :

• high_variability=False (par défaut) : Avatar échantillonne à partir d'un pool pré-généré de valeurs fictives via l'indexation. Cette approche est nettement plus rapide, mais différentes valeurs source peuvent recevoir la même valeur de remplacement (collision possible).
• high_variability=True : Avatar génère une valeur fictive unique pour chaque ligne ou pour chaque valeur source unique (selon consistent). Cela évite les collisions mais est plus lent.

Utilisez la valeur par défaut (False) dans la plupart des cas. Définissez high_variability=True uniquement lorsque vous devez garantir que deux valeurs source distinctes ne reçoivent jamais le même remplacement fictif.

HashSha256Strategy — Hachage déterministe

Remplace chaque valeur par son empreinte cryptographique SHA-256. La même entrée produit toujours la même sortie.

• Idéal pour : le remplacement cohérent de clés entre jeux de données et entre exécutions
• Comportement : déterministe — des entrées identiques produisent toujours des sorties identiques
• Remarque : les valeurs hachées ne sont pas lisibles par un humain. Évitez cette stratégie pour les colonnes à faible entropie (ex. codes courts ou entiers) car elles sont vulnérables aux attaques par dictionnaire en force brute
• Exemple : HashSha256Strategy()

Uuid4Strategy — Identifiants uniques aléatoires

Remplace chaque valeur par un UUID généré aléatoirement (version 4).

• Idéal pour : les clés primaires et identifiants où l'unicité importe plus que la lisibilité
• Exemple : Uuid4Strategy()

ConstantStrategy — Remplacement fixe

Remplace chaque valeur de la colonne par la même chaîne fixe, quelle que soit la valeur d'origine.

• Idéal pour : supprimer ou masquer entièrement une colonne
• Exemple : ConstantStrategy(value="REDACTED")

IntegerStrategy — Identifiants entiers pseudonymes

Associe chaque valeur source unique à un entier pseudonyme unique. L'association est aléatoire, de sorte que l'ordre de tri d'origine n'est pas conservé.

• Idéal pour : les identifiants numériques (ex. identifiants clients, numéros de compte) lorsque le code en aval attend un type entier
• Exemple : IntegerStrategy()

SpecificIdStrategy — Identifiants structurés par motif

Génère des identifiants structurés à partir d'un motif défini par l'utilisateur, combinant des caractères littéraux et des espaces réservés.

Espace réservé	Description
#	Chiffre aléatoire (0–9)
?	Lettre aléatoire (casse contrôlée par letter_case)
^	Caractère alphanumérique aléatoire
{{col}}	Valeur d'une autre colonne pour la même ligne

Le paramètre letter_case (une valeur de SpecificIdLetterCase) contrôle la casse des lettres : UPPER, LOWER, ou BOTH (valeur par défaut).

• Idéal pour : les identifiants spécifiques à un domaine avec un format requis (ex. codes employés, numéros de référence)
• Exemple : SpecificIdStrategy(pattern="EMP-####"), SpecificIdStrategy(pattern="{{dept}}-???##", letter_case=SpecificIdLetterCase.UPPER)

Types de PII pris en charge

La plateforme reconnaît les types suivants d'informations personnellement identifiables. Ces types guident la stratégie FakeDataStrategy pour générer des valeurs de remplacement appropriées :

Type de PII	Description	Exemple original	Exemple pseudonymisé (FakeDataStrategy)
Email	Adresses e-mail	jane.doe@corp.com	sarah.miller@example.net
First Name	Prénoms	Jane	Sarah
Last Name	Noms de famille	Doe	Miller
Full Name	Noms complets	Jane Doe	Sarah Miller
Phone	Numéros de téléphone	+33 6 12 34 56 78	+33 6 98 76 54 32
SSN	Numéros de sécurité sociale	1 85 12 75 108 042	2 91 03 69 205 118
Address	Adresses physiques	12 Rue de Rivoli	45 Avenue des Champs
Free Text	Champs de texte libre	Note patient...	Lorem ipsum...

astuce

Le type de PII doit uniquement être spécifié avec FakeDataStrategy. Toutes les autres stratégies fonctionnent indépendamment du type de PII.

Intégrité référentielle multi-tables

Lorsque vous travaillez avec des jeux de données multi-tables (ex. une table patients liée à une table visites), la pseudonymisation maintient automatiquement l'intégrité référentielle :

• Une clé primaire pseudonymisée dans la table parent est appliquée de manière cohérente aux clés étrangères correspondantes dans les tables enfants
• Cela garantit que les relations entre tables restent valides après pseudonymisation
• Les clés étrangères des tables enfants héritent automatiquement de la correspondance de pseudonymisation du parent — aucune configuration supplémentaire n'est nécessaire

Par exemple, si patient_id dans la table patients est pseudonymisé avec Uuid4Strategy, la même correspondance est appliquée à patient_id dans la table visites, préservant la relation parent-enfant.

Premiers pas

La pseudonymisation est configurée colonne par colonne lors de la mise en place de vos paramètres d'avatarisation. Vous transmettez un objet stratégie pour chaque colonne à pseudonymiser — aucune configuration n'est nécessaire pour les colonnes de clé étrangère, qui héritent automatiquement de la correspondance de leur parent.

Pour la documentation technique, les exemples de code et les tutoriels pas à pas, consultez la documentation du client Python :

• Guide utilisateur — Comment pseudonymiser des colonnes PII
• Tutoriel — Présentation de la pseudonymisation