Données synthétiques et données anonymisées, cela ressemble à un choix entre deux variantes de la même chose, et le traiter ainsi cause de vrais ennuis. L’une des deux n’a jamais appartenu à personne ; l’autre appartenait à quelqu’un et a été traitée pour l’en retirer. La différence décide qui peut voir les données, combien de temps elles peuvent être conservées, et si elles peuvent être partagées hors de l’organisation tout court.
Cet article expose les quatre approches que les gens utilisent réellement pour les données de test, ce que chacune garantit et ne garantit pas, et pourquoi la combinaison de champs est le détail qui défait discrètement la plupart des tentatives de suppression.
Les quatre approches, côte à côte
La plupart des jeux de données de test sont produits par l’une de quatre méthodes, et elles sont fréquemment décrites par le même mot.
| Approche | Comment elle est produite | Ce qu’elle garantit |
|---|---|---|
| Synthétique | Les valeurs sont générées à partir de règles et d’aléatoire | Rien dans l’ensemble n’a jamais décrit une personne réelle |
| Anonymisée | Des enregistrements réels sont traités pour que les individus ne puissent pas être identifiés | Les données d’origine existaient et la transformation doit être prouvée |
| Pseudonymisée | Les identifiants directs sont remplacés par des codes, avec une correspondance conservée | Les données restent liables à des personnes via la correspondance |
| Masquée | Des caractères sensibles sont remplacés pour l’affichage | La valeur sous-jacente existe généralement encore |
Seule la première part de rien. Les trois autres commencent toutes par des enregistrements réels, ce qui explique que chacune hérite d’une obligation que la première n’a jamais eue.
Pourquoi retirer les noms n’anonymise-t-il pas un jeu de données ?
Parce qu’un nom n’est qu’une manière parmi d’autres de singulariser une personne, et généralement pas la plus fiable. Une table dont la colonne de nom a été supprimée vous dit encore qu’une femme d’une trentaine d’années travaille chez un petit employeur précis dans une petite ville précise, et dans cette population il peut n’exister qu’une seule telle personne. Rien n’a été anonymisé ; l’identifiant a simplement été remplacé par un ensemble d’identifiants qui demandent un peu plus d’effort.
La version statistique du même problème est que tout jeu de données porte des quasi-identifiants — des valeurs qui ne sont pas uniques à elles seules mais le deviennent en combinaison. Date de naissance, code postal, genre et profession forment l’ensemble classique, et l’arithmétique est impitoyable : une combinaison qui paraît large à l’échelle d’un pays entier peut être unique au sein d’une ville, et une base de données de test est généralement un extrait d’un seul marché plutôt qu’un échantillon du monde.
La réidentification n’est donc pas exotique. C’est la conséquence ordinaire de la combinaison de quelques colonnes avec des informations publiquement disponibles, et cela devient plus facile à chaque jeu de données supplémentaire qui devient accessible. C’est pourquoi une prétention honnête à l’anonymisation doit traiter ce qui reste, et pas seulement ce qui a été supprimé.
Qu’est-ce qui compte réellement comme anonyme ?
Une donnée est anonyme lorsque les individus qu’elle contient ne peuvent être identifiés par quiconque, par quelque moyen raisonnablement susceptible d’être utilisé — ce qui est une condition plus forte que la plupart des équipes ne le supposent, car elle inclut les informations détenues ailleurs. En pratique, cela signifie qu’une prétention correcte à l’anonymisation repose sur une évaluation documentée : quels champs ont été supprimés ou généralisés, à quoi ressemble la population résultante, ce qui demeure en combinaison, et pourquoi l’identification n’est pas raisonnablement possible.
Deux conséquences méritent d’être prises au sérieux. Premièrement, l’évaluation est propre à un jeu de données et à un contexte, si bien qu’une approche qui fonctionne pour une publication peut ne pas fonctionner pour la suivante si de nouvelles colonnes sont ajoutées. Deuxièmement, l’évaluation est réellement difficile, car prouver une négation au sujet de l’identification demande bien plus de travail que de démontrer qu’une colonne de chaînes a été supprimée.
Là où la difficulté est élevée, la réponse honnête est généralement de cesser d’appeler les données anonymes. Pseudonymisées, à accès restreint, ou à usage interne sont toutes des descriptions défendables ; anonyme est une prétention qui doit se mériter.
Quelle approche un environnement de test devrait-il utiliser ?
Les données synthétiques, dans la grande majorité des cas, parce qu’elles suppriment l’obligation au lieu de la gérer. Un jeu de données généré à partir de règles et d’une entrée fixe ne contient aucun individu du tout, il n’y a donc aucune horloge de conservation, aucune question de consentement, aucune demande de suppression à satisfaire, et aucune violation à signaler s’il fuite. Il peut être versionné dans un dépôt de test, envoyé par courriel entre équipes et collé dans un ticket sans se demander une seconde à qui appartiennent les informations qu’il contient.
Cela contourne aussi un problème pratique que les données déguisées ne cessent de générer : la correspondance. Des données pseudonymisées ont besoin d’une correspondance conservée quelque part, et cette correspondance est elle-même un jeu de données sensible qu’il faut protéger, faire tourner et auditer. Les équipes consacrent régulièrement plus d’efforts à protéger la correspondance qu’elles n’en auraient consacré à générer les données.
Ce que les enregistrements synthétiques ne font pas, c’est reproduire automatiquement toutes les propriétés des données réelles. Si un test dépend de la distribution — la fréquence d’un cas limite rare, la corrélation entre deux champs, la forme d’une longue traîne — celle-ci doit être modélisée délibérément plutôt qu’héritée. Les exigences de cohérence des champs en sont un exemple : un générateur doit être construit pour maintenir les champs liés en accord, car le hasard seul ne le fera pas.
Comment garder un jeu de données généré reproductible ?
En en faisant une fonction d’une entrée que vous contrôlez plutôt que de l’horloge ou d’une source aléatoire que vous ne pouvez pas rejouer. L’agencement habituel est une graine : une valeur courte, mémorisable par un humain, qui pilote chaque décision du générateur, de sorte que la même graine produise les mêmes enregistrements sur n’importe quelle machine et n’importe quel jour.
La reproductibilité compte pour trois raisons faciles à oublier sous la pression du temps. Un test automatisé peut détenir un échantillon fixe et affirmer dessus, si bien qu’une défaillance est diagnosable plutôt qu’un pile ou face. Un rapport de bug peut nommer l’enregistrement exact qu’il a vu, si bien que n’importe qui peut le reconstruire sur sa propre machine. Et une revue peut reproduire une démonstration à l’identique, ce qui compte lorsqu’un jeu de données est proposé comme preuve qu’aucun enregistrement réel n’est impliqué.
Les enregistrements générés par le générateur d’identités et de données de test fonctionnent ainsi, et les valeurs suivent les conventions de formatage réelles de chaque pays tout en restant entièrement inventées. Ce sont des enregistrements synthétiques destinés aux tests logiciels uniquement ; ils ne décrivent pas une personne réelle, et ils ne peuvent pas servir à en représenter une ni à passer une vérification réelle.
Comment prouver qu’un jeu de données de test ne contient aucun enregistrement réel ?
En étant capable de décrire d’où vient chaque valeur. C’est une question de provenance, et elle se répond au moment de la génération plutôt qu’au moment de l’audit. Un jeu de données produit en exécutant un générateur avec une graine connue, à partir d’un générateur qui ne lit aucune source de production, a une réponse d’une ligne. Un jeu de données produit en transformant un export de production a une réponse qui dépend de l’exactitude de la transformation, et la charge de le prouver ne disparaît jamais tout à fait.
Deux habitudes rendent la provenance durable. Étiquetez les données elles-mêmes — une colonne ou un en-tête marquant les lignes comme synthétiques — afin qu’une copie qui voyage dans un ticket, un tableur ou une capture d’écran annonce encore ce qu’elle est. Et gardez l’étape de génération sous contrôle de version, afin que produire à nouveau le même jeu de données soit une commande plutôt qu’une histoire orale.
Il existe une dernière vérification à appliquer à tout jeu de données qui se prétend sûr : essayez d’y identifier une personne. Si la tentative réussit ne serait-ce qu’une fois, la prétention était exagérée, et la bonne réponse est une prétention plus étroite plutôt qu’une plus bruyante.
Pour les développeurs : graines, distributions et prétentions honnêtes
Concevez le générateur de sorte que chaque décision aléatoire découle de la graine par un chemin unique documenté. Deux générateurs qui acceptent tous deux une graine mais consomment l’aléatoire dans des ordres différents seront en désaccord, et le désaccord ressemblera à un bug du test plutôt qu’à un bug du générateur.
Modélisez la distribution délibérément. Les données réelles ont des quantités inégales de tout, et un tirage uniforme produit un jeu de données trop propre : aucun nom rare, aucun âge inhabituel, aucun champ absent. Si le test a besoin d’une longue traîne, le générateur doit en produire une exprès, et c’est une question de spécification sur les données plutôt qu’une propriété qui émerge.
Gardez la prétention sur les données étroite et vraie. « Synthétique et généré pour les tests » est une prétention vérifiable en lisant l’étape de génération. Cela vaut bien plus pour un auditeur qu’une prétention plus large sur l’anonymat que personne ne peut reproduire. Et portez la contrainte dans les notes de fixtures : les enregistrements produits de cette manière existent pour exercer un logiciel, et non pour usurper l’identité de quiconque ni pour être proposés nulle part comme une identité réelle.
Étapes suivantes
Trouvez dans vos environnements de test un jeu de données dont personne ne peut énoncer l’origine, et remontez-la ; cette réponse est généralement plus intéressante que le jeu de données lui-même. Remplacez-le ensuite par un lot généré et consignez la graine à côté des données, afin que n’importe qui puisse le reconstruire. Si vous pesez les alternatives, l’article sur les règles de confidentialité applicables aux données de test couvre ce que chaque choix vous oblige à faire ensuite.