Au-delà des SSNs : anonymiser les identifiants internes de votre organisation
Votre outil RGPD supprime les adresses e-mail. Il supprime les numéros de téléphone. Il supprime les noms. Vous faites passer vos exports de tickets de support. Puis vous partagez le résultat avec votre équipe analytics.
Vos numéros de compte client sont toujours dans chaque ticket. Vos identifiants de commande aussi. Vos identifiants utilisateurs internes aussi.
Ces identifiants semblent inoffensifs seuls. Sans table de correspondance, ils ne désignent pas une personne. Mais votre équipe analytics a cette table. Votre CRM aussi. Votre base de données support aussi. N'importe qui avec un accès peut retrouver la personne en quelques secondes.
C'est un échec de pseudonymisation au sens du RGPD. L'outil n'a pas planté. On ne lui a jamais dit de chercher vos identifiants.
Ce que détectent les outils PII standards
Les outils PII standards couvrent les formats universels. Ils capturent ce que chaque organisation utilise.
Les outils standards détectent :
- Les numéros de sécurité sociale (SSNs US, NINOs UK, formats nationaux EU)
- Les adresses e-mail
- Les numéros de téléphone
- Les numéros de carte bancaire
- Les noms
- Les numéros de passeport et de permis de conduire
Les outils standards ne détectent pas :
- Les identifiants employés au format EMP-XXXXX
- Les numéros de compte client au format ACC-XXXXXXXX-XX
- Les identifiants de commande au format ORD-XXXXXXX
- Les identifiants utilisateurs internes au format UUID ou personnalisé
- Les codes de référence spécifiques aux partenaires
Les outils standards trouvent des motifs universels. Vos identifiants internes ne sont pas universels. Ils nécessitent une configuration personnalisée pour être détectés.
Le risque de ré-identification
Une entreprise exporte des tickets de support pour un contrôle qualité. La suppression PII standard enlève les noms, e-mails et numéros de téléphone. Les numéros de compte au format ACC-XXXXXXXX-XX ne sont pas touchés.
L'export va à l'équipe analytics. Un analyste fait une jointure entre la table de tickets et la base de données clients sur le numéro de compte. La personne est retrouvée immédiatement. Aucune technique particulière n'est nécessaire. C'est une jointure SQL de routine.
L'article 4(5) du RGPD définit la pseudonymisation comme un traitement où les données « ne peuvent plus être attribuées à une personne concernée précise sans recourir à des informations supplémentaires ». Les numéros de compte échouent à ce test. Les informations supplémentaires — votre base de données clients — sont là, dans votre organisation.
L'export « anonymisé » ne l'était pas.
Créer des motifs d'entités personnalisés
La configuration d'entités personnalisées est rapide. Les équipes conformité peuvent le faire sans aide technique.
Étape 1 : Lister vos formats d'identifiants.
Notez chacun. Par exemple : compte ACC-XXXXXXXX-XX, commande ORD-XXXXXXX, employé EMP-XXXXX.
Étape 2 : Décrire le format en langage courant.
« Les numéros de compte commencent par ACC, puis un tiret, puis 8 chiffres, puis un tiret, puis 2 lettres majuscules. »
La génération de motifs assistée par IA retourne : ACC-\d{8}-[A-Z]{2}
Étape 3 : Tester sur des données d'exemple.
Chargez 20 à 30 documents. Vérifiez que toutes les occurrences sont trouvées. Vérifiez qu'aucun faux positif n'apparaît.
Étape 4 : Choisir une méthode.
Pour les identifiants utilisés comme clés de jointure, où l'analyse doit relier des enregistrements :
- Pseudonymiser. Remplacer ACC-00123456-AB par ACC-99876543-XY à chaque fois. La même entrée donne toujours la même sortie. Les jointures fonctionnent encore. La valeur d'origine ne peut être retrouvée sans la clé.
Pour les identifiants inutiles dans l'analyse :
- Supprimer. Remplacer par [REDACTED]. Simple. Définitif.
Étape 5 : Enregistrer comme preset partagé.
Enregistrez l'entité personnalisée — ou un ensemble — dans un preset partagé. La configuration s'applique à tous les usages : uploads en lot, appels API, interface navigateur. Les nouveaux membres de l'équipe obtiennent la configuration complète immédiatement.
Étude de cas : 180 000 tickets de support
Une entreprise a trouvé 180 000 tickets de support dans son entrepôt de données analytics. Les noms et e-mails avaient été supprimés. Les numéros de compte non. Chaque ticket contenait encore une valeur ACC-XXXXXXXX-XX active.
Calendrier de résolution :
- Le responsable conformité définit le motif ACC — 15 minutes
- Le teste sur 30 tickets d'exemple — 20 minutes
- Confirme la précision — 10 minutes
- Traite 180 000 tickets en lot pendant la nuit
- Remplace les tables de l'entrepôt par les versions nettoyées
Temps total pour le responsable conformité : 45 minutes. Sans la détection d'entités personnalisées, la correction aurait nécessité un ticket engineering, une revue de code et un déploiement. Cela prend des semaines, pas des heures.
Pour comprendre comment les identifiants personnalisés créent des risques dans les outils d'IA support, consultez le guide RGPD pour l'IA support.
Où se propagent les identifiants internes
Les identifiants internes apparaissent à plus d'endroits que la plupart des équipes ne l'imaginent.
Documents internes :
- Notes de réunion avec des références à des comptes ou commandes
- Échanges e-mail sur des cas clients
- Présentations avec des données de cas réels
Partagés avec des tiers :
- Rapports aux régulateurs avec des numéros de référence
- Documents d'audit avec des références clients
- Documents fournisseurs contenant des identifiants clients
Recherche et analytics :
- Jeux de données de parcours client
- Exports d'évaluation de la qualité support
- Données d'entraînement pour les modèles ML internes
Chaque contexte nécessite la même configuration d'entités personnalisées pour produire des données réellement anonymes.
Pseudonymisation vs. anonymisation
Le RGPD trace une ligne claire.
La pseudonymisation remplace les identifiants par des substituts. La personne d'origine peut être retrouvée si quelqu'un a la table de correspondance. Ces données restent des données personnelles. Le risque est réduit. Vos obligations RGPD ne disparaissent pas.
L'anonymisation supprime la possibilité de ré-identifier. Les données anonymes ne sont pas des données personnelles. Le RGPD ne s'y applique pas.
Les numéros de compte et de commande sont pseudonymes lorsque des tables de correspondance existent. Les remplacer par des substituts fixes réduit le risque, mais le RGPD reste applicable. Les remplacer par des tokens aléatoires — et supprimer la clé — supprime l'obligation RGPD, mais empêche les jointures analytiques.
Pour le partage avec des tiers sans vos tables de correspondance : la pseudonymisation peut suffire. Pour les analyses internes, une anonymisation complète ou des contrôles d'accès stricts sont nécessaires. Le guide de conformité légale explique comment documenter chaque approche pour votre registre des traitements.
Conclusion
La lacune n'est pas un échec de l'outil. C'est une lacune de configuration. Aucun outil ne peut connaître votre format de numéro de compte si vous ne le lui indiquez pas.
La configuration d'entités personnalisées comble la lacune en quelques heures. Les équipes conformité définissent les formats, les testent sur des données d'exemple, et les appliquent sur tous les modes de traitement. Aucune aide technique n'est nécessaire.
Les 180 000 numéros de compte non supprimés n'étaient pas là parce que l'outil a échoué. Ils étaient là parce qu'on n'a jamais dit à l'outil de les chercher.