Des données de test sans personnes réelles : pourquoi le pseudonymisé reste personnel et le synthétique ne l'est pas

Copier la production est un traitement, pas un raccourci

Le réflexe se comprend. Les vraies données ont la forme des vraies données : des noms de toutes longueurs, des adresses qui ne tiennent pas dans le formulaire, des commandes à quarante lignes, la cliente dont le nom contient une apostrophe qui a tout cassé en mars dernier. Une restauration de dump de production est le jeu d'essai le plus fidèle qui soit, et il coûte une commande. Le problème est que cette commande est un traitement au sens juridique, et que le règlement a son mot à dire.

Deux des principes de l'article 5 s'y appliquent directement et indépendamment. La limitation des finalités, article 5, paragraphe 1, point b), exige que les données soient collectées pour des finalités déterminées, explicites et légitimes et ne soient pas traitées ultérieurement d'une manière incompatible avec ces finalités. L'adresse a été collectée pour livrer une commande. Reproduire un bug de mise en page n'est pas cette finalité, et savoir si c'est compatible avec elle est une vraie question à laquelle quelqu'un doit apporter une vraie réponse — le règlement donne des critères d'appréciation de la compatibilité, pas un oui ou un non. La minimisation, article 5, paragraphe 1, point c), exige que les données soient adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités. Une copie intégrale de tous les clients, pour tester une page de paiement, est difficile à décrire comme limitée au nécessaire.

Il y a une dimension pratique qui n'a rien à voir avec le droit et tout à voir avec ce qui tourne mal en réalité. Un environnement de test n'a ni les contrôles d'accès de la production, ni sa supervision, ni ses règles de conservation des sauvegardes. Il est sur un portable, dans un conteneur monté par quelqu'un, dans un instantané au fond d'un bucket que personne ne se souvient d'avoir créé. L'envoi de courriels y est souvent encore configuré, ce qui explique qu'un passage en préproduction ait un jour écrit à une liste de clients réels. L'obligation de protéger les données ne s'affaiblit pas parce que la machine s'appelle préproduction, et l'exposition pratique y est plus grande qu'en production. Les deux arguments vont dans le même sens.

Le pseudonymisé reste personnel — c'est là que l'on se trompe

L'article 4, point 5, définit la pseudonymisation comme le traitement de données à caractère personnel de telle façon que celles-ci ne puissent plus être attribuées à une personne concernée précise sans avoir recours à des informations supplémentaires, pour autant que ces informations supplémentaires soient conservées séparément et soumises à des mesures techniques et organisationnelles. Lis-le une fois : les mots décisifs sont sans avoir recours à des informations supplémentaires. Ces informations supplémentaires existent. Elles sont conservées quelque part. Le lien est toujours là ; on l'a rendu plus difficile à suivre, pas supprimé.

Le considérant 26 en tire explicitement la conclusion : les données à caractère personnel ayant fait l'objet d'une pseudonymisation et qui pourraient être attribuées à une personne physique par le recours à des informations supplémentaires doivent être considérées comme des informations concernant une personne physique identifiable. Autrement dit, les données pseudonymisées sont des données à caractère personnel, dans le champ, avec toutes les obligations qui s'y attachent : droit d'accès et d'effacement, obligation de notification de violation, règles de transfert. Les lignes directrices 01/2025 du Comité européen de la protection des données, adoptées le 16 janvier 2025, énoncent la même conclusion dans leur résumé et ajoutent un point à retenir : cela vaut même si les données pseudonymisées et les informations supplémentaires ne sont pas entre les mains de la même personne.

L'anonymisation est une affirmation différente, et bien plus exigeante. Le considérant 26 dit que les principes de la protection des données ne devraient pas s'appliquer aux informations anonymes, c'est-à-dire aux informations qui ne concernent pas une personne physique identifiée ou identifiable, ni aux données rendues anonymes de telle manière que la personne concernée n'est pas ou plus identifiable. Mais le même considérant pose le critère : pour déterminer si une personne est identifiable, il convient de prendre en considération l'ensemble des moyens raisonnablement susceptibles d'être utilisés, compte tenu de facteurs objectifs tels que le coût et le temps nécessaires. Un jeu de données où les noms ont été remplacés mais où subsistent codes postaux, dates de naissance et historiques de commandes échouera souvent à ce critère, parce que la combinaison ré-identifie. Une anonymisation qui résiste à l'examen suppose en général de détruire la structure même que l'environnement de test devait reproduire.

Les données synthétiques échappent à tout ce raisonnement en n'y entrant jamais. Une ligne assemblée à partir d'une liste fixe de prénoms, d'une liste fixe de noms et d'une liste fixe de villes ne concerne pas une personne physique identifiée ou identifiable, parce qu'il n'y a personne derrière et aucune information supplémentaire qui y mènerait. L'article 4, point 1, définit les données à caractère personnel comme toute information se rapportant à une personne physique identifiée ou identifiable ; si rien ne se rapporte à personne, la définition n'est pas remplie, et le règlement n'atteint tout simplement pas le jeu de données. Pas de base légale, pas de test de compatibilité, pas de durée de conservation, aucune demande d'effacement susceptible d'arriver un jour. C'est une différence de nature, et c'est la raison de générer.

Ce que ce générateur produit réellement, mesuré

L'outil puise dans six viviers par pays — France, Royaume-Uni, Allemagne, Espagne, Italie et Portugal — chacun de trente-deux prénoms, trente-deux noms de famille et douze villes. Cela fait 192 prénoms, 192 noms, 72 villes et 6 144 noms complets distincts sur tout l'espace, et une ligne tient debout : une persona de Lisboa reçoit un nom portugais et une partie locale d'adresse qui en dérive, pas un patronyme allemand sur un numéro français. Mesuré sur quatre cents tirages, cent lignes donnent 99,2 noms distincts en moyenne et mille lignes en donnent 922,5. Le premier nom qui se répète apparaît vers la ligne 100, ce qui est la borne des anniversaires sur un espace de 6 144, pas un défaut.

Les adresses e-mail n'entrent jamais en collision, parce qu'elles ne sont pas laissées au hasard. Chaque exécution retient les parties locales déjà distribuées et ajoute un compteur à une répétition : la deuxième Marie Martin reçoit marie.martin2 comme partie locale. Dix mille lignes donnent dix mille adresses distinctes, et deux cent mille en donnent deux cent mille — mesuré sur la fonction qui construit les lignes, puisque le formulaire, lui, s'arrête à mille lignes par exécution. L'index UNIQUE qui rejetait l'import à mi-parcours en laissant une table à moitié remplie n'a plus rien à attraper. Deux limites de cette garantie méritent d'être connues. Le compteur ne vit que le temps d'une exécution, donc deux exports séparés peuvent encore se répéter — garde un jeu de données dans un seul fichier, ou donne à chaque lot son propre préfixe. Et le nombre de noms distincts n'est pas celui des adresses distinctes : une requête qui compte les clients par nom plutôt que par adresse arrivera un peu sous ton nombre de lignes, d'environ huit pour cent à mille lignes.

Chaque adresse se termine par example.com, example.net ou example.org, et rien d'autre. Les trois sont réservés par la RFC 2606 pour servir d'exemples, et les trois publient un enregistrement MX nul — le 0 . de la RFC 7505, un domaine qui déclare dans le DNS n'accepter aucun courrier — si bien qu'un expéditeur s'arrête avant même d'ouvrir une connexion. C'est l'appariement des deux qui compte, et il est plus strict qu'il n'en a l'air. Un domaine qui n'a simplement pas de serveur de messagerie n'est pas sûr : la RFC 5321 fait retomber sur l'enregistrement d'adresse l'expéditeur qui ne trouve pas de MX, donc un domaine à l'allure documentaire avec un A vivant et pas de MX reste une cible de livraison. C'est réservé plus MX nul qui ferme la porte, et c'est la raison de ne pas inventer son propre domaine d'exemple.

La colonne téléphone est le seul endroit où l'outil répond à une question en laissant un champ vide. La France réserve des numéros à la fiction : le plan national de numérotation attribue les racines 01 99 00, 02 61 91, 03 53 01, 04 65 71, 05 36 49 et 06 39 98 aux œuvres audiovisuelles, et 06 39 98 est la seule mobile — une ligne française porte donc +33 6 39 98 suivi de quatre chiffres tirés au sort, et rien d'autre. L'Ofcom met de côté 07700 900000 à 07700 900999 pour les fictions de télévision et de radio, une ligne britannique porte donc +44 7700 900 et trois chiffres. La Bundesnetzagentur a publié deux blocs mobiles pour les productions médiatiques, 0171 3920000 à 3920099 et 0176 04069000 à 04069099, et une ligne allemande vient de l'un des deux. L'Espagne, l'Italie et le Portugal ne publient rien d'équivalent : leurs lignes sortent avec le champ téléphone vide. Les pays sont tirés uniformément, ce qui veut dire qu'environ une ligne sur deux a un blanc à cet endroit — 49,99 % sur deux cent mille lignes — et une note sous le formulaire dit pourquoi, parce qu'une colonne vide sans explication passe pour un outil cassé.

Une règle applicable, et où elle s'arrête

Génère, ne copie pas, et fais en sorte que les données générées aient l'air fausses. Utilise un domaine réservé pour chaque adresse plutôt qu'un mélange, préfixe la partie locale avec quelque chose qu'aucun compte réel ne porterait, et choisis une racine téléphonique que ton pays réserve à la fiction s'il en a une. Ce « s'il en a une » mérite une réponse, car pour la moitié des marchés de ce site la réponse est non. La France, le Royaume-Uni et l'Allemagne publient chacun un bloc ; l'Espagne, l'Italie et le Portugal n'en publient aucun. Ce que ces trois-là ont à la place, c'est de l'espace non attribué pour l'instant, ce qui est une promesse bien plus faible : un régulateur qui n'a pas encore distribué une plage peut la distribuer l'an prochain, et un jeu de test écrit aujourd'hui appellerait alors quelqu'un. Quand une plage réservée existe, sers-t'en ; quand il n'y en a pas, la sortie honnête est l'absence de numéro, et c'est ce que fait désormais cet outil. L'enjeu n'est pas juridique — les données synthétiques sont hors champ quoi qu'elles ressemblent — il est qu'un humain qui jette un œil à un ticket de support ou à une ligne de log puisse voir en une seconde que la ligne n'est pas un client. Une donnée qui a l'air vraie est traitée comme vraie, et c'est ainsi qu'une adresse de test finit sur une liste de diffusion.

Là où la génération s'arrête vraiment, c'est le bug qui ne se reproduit que sur un enregistrement. Parfois le défaut est dans les données de ce client-là et nulle part ailleurs, et aucune ligne synthétique ne le montrera. Ce cas ne se résout pas en faisant semblant, il se résout en resserrant. Extrais l'enregistrement unique et non la table, ne prends que les champs que le bug touche, travaille sur une machine aux mêmes contrôles que la production, journalise l'accès, et supprime tout une fois terminé. C'est un traitement documenté, minimisé et borné dans le temps, avec une finalité que tu peux écrire — chose totalement différente d'un dump nocturne vers une préproduction partagée — et c'est la forme que ton délégué à la protection des données reconnaîtra, parce que c'est celle que le règlement est fait pour accueillir.

Questions fréquentes

Les données pseudonymisées sont-elles encore des données à caractère personnel ?

Oui. L'article 4, point 5, définit la pseudonymisation comme le traitement de données de manière qu'elles ne puissent plus être attribuées à une personne concernée précise sans avoir recours à des informations supplémentaires, et le considérant 26 énonce que les données ayant fait l'objet d'une pseudonymisation et qui pourraient être attribuées à une personne physique par le recours à ces informations supplémentaires doivent être considérées comme des informations concernant une personne physique identifiable. Le Comité européen de la protection des données l'a redit dans ses lignes directrices 01/2025 sur la pseudonymisation, adoptées le 16 janvier 2025, en ajoutant que cela vaut même quand les données pseudonymisées et les informations supplémentaires ne sont pas détenues par la même personne. La pseudonymisation est une garantie encouragée par le règlement, elle peut réduire le risque et soutenir un test de compatibilité, mais elle ne fait pas sortir un jeu de données du champ d'application.

Puis-je copier la base de production en préproduction si je la supprime ensuite ?

Supprimer ensuite ne rend pas la copie licite ; cela limite la durée du traitement, ce qui est une autre question. La copie est un traitement dès qu'elle a lieu, il lui faut une base légale et elle doit passer l'épreuve de la limitation des finalités de l'article 5, paragraphe 1, point b) — le règlement demande si la nouvelle finalité est compatible avec celle de la collecte et donne les critères pour en juger. L'article 5, paragraphe 1, point c), s'applique indépendamment : prendre une table entière quand trois champs suffiraient n'est pas limité au nécessaire. C'est exactement le jugement pour lequel un délégué à la protection des données existe, et la réponse dépend de ton secteur, de ton information sur la vie privée et de ce que tu testes réellement. Demande avant de lancer la restauration, pas après.

Les données synthétiques sont-elles vraiment hors du RGPD ?

Quand elles sont réellement synthétiques, oui — mais le mot travaille. Des données assemblées à partir d'une liste de mots fixe, sans aucun apport d'un enregistrement réel, ne se rapportent pas à une personne physique identifiée ou identifiable : l'article 4, point 1, n'est pas satisfait et le règlement ne s'applique pas. Le considérant 26 dit que les principes de la protection des données ne devraient pas s'appliquer aux informations qui ne concernent pas une personne physique identifiée ou identifiable. La réserve est que tout ce qu'on appelle synthétique n'est pas construit ainsi : un jeu de données produit par un modèle entraîné sur des enregistrements réels est une tout autre affaire, car le modèle a vu les originaux et la sortie peut en conserver assez pour isoler quelqu'un. Si ton générateur lit la production, l'analyse recommence à zéro. S'il lit une liste fixe de cent quatre-vingt-douze prénoms qui n'ont jamais été ceux de personne en particulier, non.

Peut-on vraiment livrer quelque chose aux adresses e-mail générées ?

Non, et la raison mérite d'être reprise dans tes propres jeux de test. Chaque adresse utilise example.com, example.net ou example.org. La RFC 2606 réserve les trois comme noms d'exemple, personne ne peut donc en enregistrer un et se mettre à y recevoir du courrier, et les trois publient un enregistrement MX nul — la forme 0 . définie par la RFC 7505, c'est-à-dire un domaine qui annonce dans le DNS n'accepter aucun courrier. Un expéditeur conforme le lit et s'arrête sans ouvrir de connexion. L'appariement compte : un domaine sans MX du tout n'est pas équivalent, parce que la RFC 5321 fait retomber l'expéditeur sur l'enregistrement d'adresse, donc un domaine plausible qui se résout mais n'a pas de serveur de messagerie reste une cible de livraison. Si tu écris ton propre générateur, prends les noms réservés plutôt que d'en inventer un qui a l'air réservé — et bloque aussi le courrier sortant au niveau de l'environnement, ce que tu devrais faire de toute façon.

Combien de lignes puis-je générer avant que les noms se répètent ?

Les noms commencent à se répéter vers la ligne 100 ; les adresses e-mail, jamais. Les viviers comptent trente-deux prénoms et trente-deux noms pour chacun des six pays, soit 6 144 noms complets distincts, et la borne des anniversaires sur un espace de cette taille place la première collision autour de cent tirages — mesurée à 99,6 sur trois mille exécutions. À cent lignes tu obtiens 99,2 noms distincts en moyenne, à mille lignes 922,5. Les adresses, c'est autre chose : un nom répété se voit ajouter un compteur dans la partie locale, si bien que dix mille lignes donnent dix mille adresses distinctes et qu'un index UNIQUE sur la colonne e-mail n'a rien à rejeter. Une limite à cela : le compteur vaut pour une exécution, et le formulaire génère au plus mille lignes à la fois, donc si tu en veux davantage, relance avec une autre graine et ajoute ton propre préfixe par lot plutôt que de supposer que les deux exports ne peuvent pas se recouper.