L’expression « données de test et RGPD » arrive généralement accompagnée d’une prise de conscience inconfortable : la base de données de préproduction que tout le monde interroge librement contient de vrais noms, de vraies adresses et de vrais numéros d’identification, et personne n’a jamais décidé que ce devait être autorisé. C’était simplement pratique.
Cet article couvre ce qui constitue une donnée personnelle dans un enregistrement de test, pourquoi les environnements de développement sont le mauvais endroit pour des copies de production, la différence entre déguiser des données et les supprimer, et à quoi ressemble un remplacement viable.
Qu’est-ce qui compte comme donnée personnelle ici ?
Plus de choses qu’on ne le pense, et la liste est comportementale plutôt que technique. Un nom, un numéro d’identification, une date de naissance, une adresse de domicile, un numéro de téléphone et une adresse électronique en sont les membres évidents. Des éléments moins évidents les rejoignent : une photographie, un identifiant d’appareil, une trace de localisation, un pseudonyme de compte, et toute note dans un système d’assistance qui décrit incidemment quelqu’un.
- Membres évidents : un nom, un numéro d’identification, une date de naissance, une adresse de domicile, un numéro de téléphone et une adresse électronique
- Éléments moins évidents : une photographie, un identifiant d’appareil, une trace de localisation, un pseudonyme de compte
- Également personnels : toute note dans un système d’assistance qui décrit incidemment quelqu’un
Le concept est défini par référence à la personne plutôt qu’au champ. Une donnée est personnelle lorsqu’elle se rapporte à un individu identifiable, directement ou indirectement, ce qui signifie qu’un champ n’a pas besoin de contenir un nom pour être personnel. Un enregistrement comportant une date de naissance, un code postal et un intitulé de poste peut être personnel si ces trois éléments réunis désignent une personne dans la population que couvrent les données.
C’est cette définition qui fait de l’environnement de test une véritable question plutôt qu’une formalité. Si la base de préproduction détient l’un de ces éléments, la préproduction traite des données personnelles, et tout argument sur la conservation, l’accès et la sécurité s’applique désormais à un système conçu sans eux.
Pourquoi les systèmes de test ne devraient-ils pas détenir de données de production ?
Parce que les contrôles qui protègent la production sont précisément ceux qui manquent aux environnements inférieurs. La production dispose généralement d’un accès restreint, d’un stockage chiffré, d’une journalisation d’audit et d’un processus de changement. La préproduction n’en a typiquement aucun des quatre, parce qu’elle existe pour être pratique. Y copier un jeu de données constitue donc une dégradation de la protection appliquée aux enregistrements les plus sensibles que détient l’organisation.
Trois conséquences s’ensuivent, et chacune est coûteuse à sa manière. L’accès se multiplie : chaque prestataire, chaque compte de test automatisé et chaque ordinateur portable qui restaure un vidage détient désormais des données personnelles. La conservation devient accidentelle : la copie est rafraîchie, oubliée, sauvegardée et laissée dans un espace de stockage que personne ne possède. Et la portée d’un incident grandit : lorsqu’une fuite ordinaire se produit quelque part, la question n’est plus quels systèmes ont été exposés mais combien de copies existent.
L’angle réglementaire est plus étroit que l’angle ingénierie mais pointe dans la même direction. Les données personnelles doivent être collectées à des fins déterminées et ne pas être utilisées pour des fins incompatibles, si bien que réutiliser discrètement des enregistrements de production pour tester une migration constitue une nouvelle finalité que personne n’a acceptée. Rien de tout cela n’est propre à un cadre juridique unique ; le même raisonnement apparaît dans la plupart des régimes de protection de la vie privée, ce qui explique que les conseils pratiques convergent.
Quelle est la différence entre anonymisation et pseudonymisation ?
Ces deux notions sont constamment traitées comme des synonymes et elles ne le sont pas. Des données pseudonymisées ont vu leurs identifiants directs remplacés par un code, la correspondance étant conservée quelque part. L’enregistrement ne peut pas être attribué sans cette information supplémentaire, mais le lien existe toujours et peut être suivi si la correspondance fuite. Des données anonymisées ont été traitées de sorte que l’individu ne puisse plus être identifié par quiconque, y compris l’organisation qui les détient, et la transformation ne peut pas être inversée.
Cette distinction décide si les données sont encore des données personnelles. Les enregistrements pseudonymisés restent personnels pour la plupart des usages, car une clé existe. Les enregistrements anonymisés, faits correctement, ne le sont pas — mais prouver une anonymisation correcte est réellement difficile, et c’est cette difficulté qui rend si peu avantageux le recours aux données de production pour les tests.
Il existe un second piège au-delà des identifiants directs. Retirer les noms d’une table ne l’anonymise pas, car des combinaisons des champs restants identifient des personnes. Un intitulé de poste rare dans une petite ville suffit souvent à lui seul. Selon un critère juridique, la bonne question n’est pas de savoir si un nom est présent mais si quelqu’un pourrait raisonnablement identifier l’individu à partir de ce qui reste, en utilisant des informations qu’il détient ou pourrait obtenir.
Le masquage et la suppression résolvent-ils le problème ?
Le masquage remplace des caractères sensibles par un motif fixe, et il est excellent pour l’affichage : un agent de support voit les quatre derniers chiffres d’un numéro tandis que le reste est caché. Ce n’est pas de l’anonymisation, car la valeur d’origine est généralement encore stockée, et une couche de masquage devant un enregistrement réel ne fait rien contre l’enregistrement réel.
La suppression de champs individuels a la même faiblesse sous un autre costume. Retirez le nom et l’enregistrement comporte encore une adresse, une date de naissance et un numéro de téléphone. Remplacez aussi l’adresse et les champs restants peuvent encore singulariser une personne dans la population. Chaque suppression réduit le risque sans le clore, et il est rarement un point clair où quelqu’un peut prouver que le risque a atteint zéro.
Il existe aussi un problème de documentation. En pratique, les équipes ne peuvent pas démontrer quels enregistrements ont été anonymisés correctement et lesquels sont simplement déguisés, car la transformation a eu lieu de manière ad hoc et n’a laissé aucune trace. Un jeu de données dont personne ne peut reconstituer la provenance ne peut pas être défendu plus tard.
Qu’est-ce qui devrait remplacer les copies de production ?
Des enregistrements qui n’ont jamais appartenu à personne. C’est l’argument en faveur de la génération de données plutôt que de leur collecte, et c’est pourquoi les enregistrements synthétiques résolvent d’un coup la question de la confidentialité et celle de la qualité. Il n’y a rien à protéger, rien à conserver, rien à divulguer, et aucune limitation de finalité à discuter, car les données n’ont jamais appartenu à une personne.
Les enregistrements générés se comportent aussi mieux dans les tests. Les valeurs produites par le générateur d’identités et de données de test sont cohérentes en interne — l’adresse, le code postal et l’indicatif téléphonique appartiennent au même pays, et les formats d’identifiant suivent les conventions de ce pays — ce qui signifie qu’un jeu de données de test n’a pas besoin d’être réparé à la main. Ce sont des enregistrements synthétiques pour les tests logiciels uniquement, et ils ne sont pas utilisables pour usurper l’identité d’une personne réelle ni pour satisfaire un contrôle réel d’identité, d’âge ou d’éligibilité.
La réserve honnête est que les données synthétiques ne reproduisent pas automatiquement toutes les corrélations du monde réel. Si un test dépend réellement de la forme statistique de données réelles, cette forme doit être modélisée délibérément, et la comparaison des approches synthétiques expose ce qu’implique la modélisation et où elle atteint ses limites.
Comment garder les données personnelles hors des journaux et des captures d’écran ?
La fuite vient rarement de la base de données. C’est le journal de requêtes qui a capturé un enregistrement complet, le rapport d’erreur qui a intégré le corps de la requête, la capture d’écran jointe à un ticket de bug, le tableur exporté pour analyse et laissé dans un lecteur partagé, et le vidage local que quelqu’un a pris pour reproduire un défaut dans l’avion.
Trois contrôles en réduisent l’essentiel. Premièrement, gardez les enregistrements réels hors des environnements où les journaux sont verbeux, ce qui est un argument direct pour utiliser des données synthétiques en préproduction. Deuxièmement, traitez une capture d’écran ou un export comme contenant tout ce que l’écran contenait, et exigez que les preuves de test proviennent d’environnements ne détenant aucun enregistrement réel. Troisièmement, rendez la conservation explicite : une copie qui existe pour une finalité devrait avoir une date de fin, et une copie sans date de fin n’est pas une copie, c’est une seconde base de production.
La revue des accès a sa place ici aussi. Savoir qui peut atteindre le jeu de données n’est utile que si la réponse a été vérifiée récemment, et le moment où une copie est largement partagée est celui où cette revue cesse d’avoir un sens.
Pour les développeurs : isolation, provenance et preuve
Séparez les environnements plutôt que de filtrer un flux de données dans l’autre. Un environnement de développement devrait être peuplé par une étape de génération, jamais par une restauration depuis la production, et la connexion du développement vers la production ne devrait pas exister du tout — et pas seulement être inutilisée.
Étiquetez la provenance des données dans le jeu de données lui-même. Un marqueur qui indique que ces lignes sont synthétiques et destinées aux tests uniquement survit à l’export, à la capture d’écran et au ticket d’assistance, et il dit à un futur lecteur tout ce qu’il a besoin de savoir sur ce qu’il regarde. C’est la sauvegarde la moins coûteuse disponible et celle que l’on saute le plus souvent.
Enfin, préparez la réponse à la question qu’un auditeur posera : comment savez-vous que ce jeu de données ne contient aucun enregistrement réel ? Une étape de génération qui s’exécute à partir d’une graine et ne lit jamais de source de production est une réponse démontrable. Un pipeline qui a transformé un export de production ne l’est pas, peu importe à quel point la transformation paraît minutieuse en revue. Une absence vérifiable vaut mieux qu’un déguisement prouvable, à tous les coups.
Étapes suivantes
Découvrez si votre base de données de préproduction a été restaurée à partir d’un vidage de production, et si c’est le cas, plaidez pour son remplacement par des lignes générées avant la prochaine revue trimestrielle des accès. Parcourez ensuite un rapport de bug du mois dernier et comptez en combien d’endroits les coordonnées d’une personne réelle y ont voyagé — journaux, pièces jointes, captures d’écran — car ce compte est ce contre quoi l’alternative est en concurrence. Quand vous passerez à l’action, générez le premier lot dans le générateur d’identités et étiquetez chaque ligne comme synthétique avant de l’importer.