Données de test sans données personnelles issues de la production

Objectif

Donner à l'équipe de développement, à la CI et aux environnements de préproduction des données réalistes sans copier de données personnelles hors de la production, de sorte que le raccourci « copier tout simplement la prod » devienne inutile et indisponible.

Prérequis

Un schéma assorti de contraintes, afin que les données générées soient validées par la base de données. Une cartographie des données marquant les colonnes personnelles. Une bibliothèque de génération : la documentation de Faker décrit un paquet Python qui génère de fausses données (noms, adresses, texte, nombres) et une méthode seed() qui rend une exécution reproductible ; cette même documentation prévient que les résultats ne sont pas garantis constants d'une version corrective à l'autre, si bien qu'un projet qui s'appuie sur une graine fige Faker au numéro de version corrective.

Étapes

1. Classer les colonnes : personnelles (à générer), métier (à générer avec des distributions réalistes), référentielles (à copier depuis la production ; les pays, catalogues de produits et tarifs ne portent aucune donnée personnelle).
2. Écrire un générateur par entité avec les mêmes règles de validité que l'application : une adresse e-mail générée passe le validateur, une commande générée référence un client généré. Fixer la graine des générateurs afin qu'un rapport de bug puisse citer une graine.
3. Produire du volume en SQL lorsque c'est possible : INSERT ... SELECT ... FROM generate_series(1, n) construit une grande table en une seule instruction ; la documentation PostgreSQL cite generate_series parmi les fonctions à ensemble de résultats, pour les entiers, les numériques et les horodatages.
4. Reproduire la forme, pas les personnes : échantillonner la production pour obtenir des distributions agrégées (commandes par client, longueurs de noms, taux de valeurs nulles, mélange de paramètres régionaux) et injecter ces agrégats dans les générateurs.
5. Ajouter les cas limites que la production comporte : noms hors ASCII, chaînes très longues, chaînes vides, un client avec dix mille commandes, des horodatages autour des changements d'heure d'été.
6. Conserver un marqueur reconnaissable dans les données générées (adresses sur un domaine réservé, préfixe de nom fixe), afin qu'un jeu de test divulgué soit identifiable et qu'un e-mail ne puisse pas atteindre une personne réelle.
7. Supprimer le raccourci : les identifiants de la base de production ne sont pas accessibles à l'équipe de développement ni à la CI. Si une tâche de copie vers la préproduction existe, elle ne s'exécute qu'après une étape de masquage qui remplace les colonnes personnelles par des valeurs générées avant que la copie ne quitte le réseau de production.

Résultat attendu

Un jeu de données généré, reproductible à partir d'une graine, avec des distributions proches de celles de la production et sans aucune donnée personnelle de production ; la préproduction paraît réaliste et peut être réinitialisée à volonté.

Limites et base de vérification

Les données générées manquent des corrélations auxquelles personne n'a pensé à modéliser (le client qui est aussi un employé). Une copie de production masquée conserve la structure et les quasi-identifiants ; la traiter comme pseudonymisée, pas comme anonymisée. Aucune affirmation n'est faite sur la vitesse de génération ni sur la fidélité des distributions générées par rapport à la production.

Champs joignables et canaux sortants

Un domaine de messagerie réservé protège un seul canal. Les numéros de téléphone, adresses postales et numéros de compte générés sont formellement valides et peuvent être réels, si bien que chaque champ vers lequel un système pourrait envoyer, expédier ou effectuer une vérification provient d'une plage réservée : les domaines relevant de la RFC 2606 et de la RFC 6761 (example.com, .test, .invalid), le bloc fictif du NANP 555-0100 à 555-0199 ou les plages « drame » publiées par les régulateurs nationaux, les réseaux de la RFC 5737 pour les adresses IP, et les numéros de test et clés de bac à sable que documentent les fournisseurs de SMS et de paiement. Indépendamment des données, les environnements hors production simulent chaque canal sortant par configuration : un serveur SMTP de capture, des identifiants de bac à sable du fournisseur, aucune clé d'API de production. Le simulacre constitue la garantie ; les plages réservées limitent les dégâts lorsqu'un simulacre fait défaut.