En bref
Un environnement de test, de recette ou de staging qui contient une copie de la production contient des données personnelles réelles.
Le RGPD s'y applique entièrement : minimisation, sécurité, notification en cas de violation.
La bonne pratique est de préparer des données de test anonymisées ou pseudonymisées, cohérentes entre les tables, sans jamais modifier la base d'origine.
Pour reproduire un bug ou valider une nouvelle version, le plus simple est de copier la base de production.
La copie est réaliste, complète, disponible tout de suite.
Elle contient aussi les vrais noms, e-mails, adresses et historiques des clients.
Voici ce que cela implique au regard du RGPD, et comment préparer des données de test sans exposer personne.
Pourquoi copier la production en test est risqué
Une base de production bénéficie de contrôles stricts : accès restreints, chiffrement, supervision.
Ses copies, beaucoup moins.
- Elles sont moins protégées.
Un serveur de test est souvent configuré vite, avec des règles d’accès plus souples, parce qu’il est jugé « non critique ». - Elles sont accessibles à plus de monde.
Développeurs, testeurs, équipes de recette, prestataires externes : chacun y a accès pour faire son travail. - Elles se multiplient.
Test, recette, staging, pré-production, dumps SQL sur un poste, exports pour une migration : chaque copie agrandit la surface d’exposition. - Elles sont oubliées.
Un dump créé pour corriger un bug reste sur un serveur interne, non chiffré ; le serveur « actif quelques jours » est encore en ligne des mois plus tard.
Le danger ne vient pas toujours d’un attaquant sophistiqué.
Il vient d’une mauvaise configuration, d’un accès oublié ou d’une copie qui n’aurait jamais dû contenir de vraies données.
Ce que montrent les fuites réelles
Données Facebook sur des serveurs Amazon mal configurés
En 2019, plus de 540 millions d’enregistrements concernant des utilisateurs Facebook (commentaires, réactions, noms de comptes) se sont retrouvés en libre accès sur des serveurs Amazon mal configurés.
Ils avaient été stockés par une entreprise tierce, Cultura Colectiva.
Il ne s’agissait pas d’un piratage, mais d’une copie des données détenue par un tiers et stockée sans protection suffisante.
Des milliers de bases Elasticsearch exposées
Entre 2017 et 2021, des milliers de bases Elasticsearch ont été découvertes accessibles publiquement sur Internet.
Parmi elles figuraient des copies secondaires : environnements de test, serveurs de staging, exports techniques ou dumps internes.
Les données exposées pouvaient inclure des adresses e-mail, des informations clients, des journaux techniques, des identifiants internes et des historiques d’activité.
Le point commun : des copies de données réelles, hors de l’environnement principal et moins protégées que lui.
Ce que demande le RGPD pour les données de test
Le RGPD ne fait aucune différence entre production et test.
Dès qu’un système contient des informations permettant d’identifier une personne, directement ou indirectement, il s’applique entièrement.
- La minimisation (article 5).
Les données doivent être adéquates, pertinentes et limitées à ce qui est nécessaire : tester un formulaire ne demande pas le vrai fichier client. Voir notre article sur la minimisation RGPD. - La protection dès la conception (article 25).
Les mesures de protection doivent être prévues dès le développement, pas ajoutées après coup. - La sécurité (article 32).
Des mesures adaptées au risque, y compris sur les copies ; le RGPD cite la pseudonymisation parmi ces mesures. - La notification des violations (articles 33 et 34).
Une exposition du staging se notifie à la CNIL dans les 72 heures, sauf si elle est peu susceptible d’engendrer un risque, et aux personnes concernées en cas de risque élevé. - La responsabilité envers les prestataires.
Vous restez responsable du traitement d’une copie confiée à une ESN ou à un freelance, et le prestataire doit être encadré par un contrat (article 28).
La CNIL consacre un guide RGPD du développeur à l’encadrement des développements, et rappelle que la sécurité des serveurs vaut pour tout le cycle de vie des données.
Les colonnes souvent oubliées dans une base de test
Les colonnes « nom », « prenom » ou « email » sont rarement oubliées.
Les fuites passent par les autres.
- Les champs de texte libre.
Notes, commentaires, descriptions, remarques : « Rappeler Mme Dupont au 06 39 98 12 34 » ou « voir l’e-mail [email protected] ». Il faut analyser leur contenu, pas seulement leur nom. - Les logs et métadonnées.
last_login_ip, user_agent, created_by, modified_by, session_token : adresses IP, e-mails, identifiants, informations sur les terminaux. - Les colonnes techniques mal nommées.
field_7, custom_attr_3, data_blob, extra_info : elles peuvent contenir un IBAN, un numéro de sécurité sociale ou des données sensibles en JSON. Une colonne incompréhensible est souvent une colonne à risque. - Les quasi-identifiants.
Code postal, date de naissance, sexe, profession : banals séparément, ils permettent ensemble d’identifier une personne. Les généraliser (l’année au lieu de la date) ou ne pas les copier s’ils sont inutiles au test. - Les chemins de fichiers et pièces jointes.
/uploads/cv/jean-dupont-cv.pdf ou /documents/contrats/martin_sophie.docx : le nom de la personne est dans le chemin.
Le RGPD vise la personne « identifiable », pas seulement identifiée : ces colonnes entrent donc dans le périmètre.
Comment préparer des données de test conformes
- Cartographier avant de copier.
Analyser toutes les colonnes, noms et valeurs, texte libre compris, pour savoir où se trouvent les données personnelles. - Ne copier que l’utile.
Un sous-ensemble de lignes ou de tables suffit souvent ; les colonnes sans usage pour le test ne partent pas. - Anonymiser ce qui n’a pas besoin d’être suivi.
Une étiquette de type ([PERSONNE], [EMAIL], [IBAN]) remplace la valeur de façon irréversible. - Pseudonymiser de façon cohérente ce qui doit rester relié.
Avec un identifiant constant, Jean Dupont devient PERSON_7b94f21c dans la table clients, les commandes et les tickets : les jointures fonctionnent toujours. - Garder des données réalistes.
Une pseudonymisation réaliste (Jean Dupont devient Auguste Lacroix) garde des valeurs crédibles : les écrans et les traitements se comportent comme avec de vraies données. - Ne jamais modifier la base d’origine.
Le traitement écrit dans une base cible séparée ; la production reste intacte. - Garder une trace.
Un rapport de ce qui a été détecté et traité documente la démarche en cas de contrôle.
Données pseudonymisées et données anonymisées n’ont pas le même statut : les premières restent soumises au RGPD, les secondes non, si plus personne ne peut être identifié (considérant 26).
Avec NymData
NymData se connecte à vos bases PostgreSQL et MySQL, sur vos serveurs, et prépare une copie protégée pour le test, la recette ou le staging :
- Cartographie.
Une analyse de la base ou des fichiers sans rien modifier, avec un rapport des données sensibles trouvées, consultable avant toute action. - Une méthode par colonne.
Anonymisation, pseudonymisation réaliste ou identifiant constant, selon l’usage de chaque donnée. - Cohérence entre tables.
Une même personne reçoit le même identifiant dans toutes les tables et dans les fichiers Word, Excel et CSV du projet. - Base source intacte.
Le résultat est inséré dans une base cible ; un filtre SQL et une limite de lignes permettent de ne copier que l’utile. - Mises à jour planifiées.
Un filtre sur la date de modification (updated_at > '${LAST_JOB_DATE}') permet de ne reprendre que les lignes modifiées depuis le dernier passage, avec un rapport d’audit à chaque exécution.
Pour une volumétrie importante, voir notre retour d’expérience anonymiser une base PostgreSQL de 10 Go, et la page anonymisation de base de données.
Questions fréquentes
Peut-on utiliser des données de production en environnement de test ?
Le RGPD s'applique aux données personnelles quel que soit l'environnement.
Copier la production telle quelle va à l'encontre du principe de minimisation, car un test n'a presque jamais besoin des vraies identités.
La pratique recommandée est d'anonymiser ou de pseudonymiser les données avant de les copier.
Un environnement de staging est-il soumis au RGPD ?
Oui, dès qu'il contient des données qui permettent d'identifier une personne, directement ou indirectement.
Une exposition du staging est une violation de données comme une autre, avec notification à la CNIL dans les 72 heures, sauf si elle est peu susceptible d'engendrer un risque.
Anonymisation ou pseudonymisation pour une base de test ?
L'anonymisation est irréversible : les données sortent du champ du RGPD si plus personne ne peut être identifié.
La pseudonymisation remplace les identités par des identifiants ou des noms fictifs : les données restent soumises au RGPD, mais l'identité n'est plus visible.
En test, la pseudonymisation stable est utile quand il faut garder les liens entre tables.
Quelles colonnes oublie-t-on d'anonymiser dans une base de test ?
Les champs de texte libre, les logs et métadonnées, les colonnes techniques mal nommées, les quasi-identifiants et les chemins de fichiers.
Comment garder des données de test réalistes après anonymisation ?
En conservant la structure, les formats, la volumétrie et les relations entre tables.
Une pseudonymisation réaliste remplace Jean Dupont par Auguste Lacroix : les écrans et les traitements se comportent comme avec de vraies données.