50 000 commandes en production, 12 clients de test créés à la main : c’est l’écart typique entre ce que teste réellement une équipe et ce que rencontre un utilisateur final. Un jeu de données trop pauvre masque des cas limites bien réels — adresse avec caractères accentués, numéro de téléphone international, panier avec cent quatre-vingts articles — que personne n’a pensé à recréer manuellement.
La tentation inverse, copier directement un dump de production sur un environnement de test, expose des données personnelles réelles à des développeurs, des outils tiers ou des environnements moins sécurisés. Ce billet propose une méthode intermédiaire : extraire un échantillon réaliste puis l’anonymiser, sans traiter le RGPD dans sa globalité ni un secteur d’activité particulier.
Le problème : un échantillonnage aléatoire brise les relations
Sélectionner aléatoirement deux cents lignes dans la table des commandes, sans se soucier des tables liées, produit un jeu de données incohérent : des commandes sans client associé, des lignes de commande sans produit référencé. Un extrait réaliste doit préserver les relations entre les tables concernées.
-- Extraction cohérente : d'abord les commandes récentes, puis leurs dépendances
SELECT * FROM wp_posts WHERE post_type = 'shop_order'
ORDER BY post_date DESC LIMIT 200;
-- Puis les clients associés à ces commandes précisément
SELECT DISTINCT customer_id FROM wp_wc_orders
WHERE id IN ( /* identifiants extraits ci-dessus */ );
Anonymiser sans casser le format attendu par le code
Remplacer une adresse email par une chaîne aléatoire fonctionne pour l’anonymisation, mais casse tout code qui valide le format d’un email avant de l’utiliser. La bonne pratique consiste à générer une donnée fictive qui respecte le même format que l’original :
UPDATE wp_users
SET user_email = CONCAT( 'client-', id, '@exemple-test.invalid' ),
display_name = CONCAT( 'Client Test ', id );
UPDATE wp_usermeta
SET meta_value = '0600000000'
WHERE meta_key = 'billing_phone';
Le domaine exemple-test.invalid a l’avantage d’être un domaine réservé par la norme, qui ne peut jamais correspondre à une adresse réelle, ce qui évite tout risque d’envoi accidentel d’email vers une vraie personne pendant les tests.
Variantes selon le champ concerné
- Nom et prénom : remplacer par un générateur de noms fictifs plutôt que par une simple concaténation numérique, pour préserver une certaine diversité réaliste dans les tests d’affichage.
- Adresse postale : conserver un code postal réel (utile pour tester un calcul de livraison par zone) mais remplacer la rue et le nom par une valeur générique.
- Moyen de paiement : ne jamais conserver un numéro de carte, même partiel ; le remplacer systématiquement par une valeur de test fournie par le prestataire de paiement concerné.
Versionner le script plutôt que manipuler à la main
Une anonymisation faite manuellement, une seule fois, se périme dès que le schéma de la base évolue ou qu’un nouveau champ personnel apparaît. Un script SQL versionné dans le dépôt, relancé à chaque nouvel export de dump, garantit que l’anonymisation suit les évolutions du schéma :
#!/usr/bin/env bash
set -e
mysql "$BASE_TEST" < export_production_extrait.sql
mysql "$BASE_TEST" < anonymiser.sql
echo "Jeu de test anonymisé prêt : $BASE_TEST"
Un script d’anonymisation qui échoue silencieusement sur un nouveau champ ajouté au schéma est plus dangereux qu’une absence totale d’anonymisation : mieux vaut qu’il échoue bruyamment que de laisser passer une donnée oubliée.
Vérifier que l’anonymisation a bien fonctionné
- Rechercher dans le dump final toute occurrence d’un nom de domaine d’email réel connu de l’équipe.
- Vérifier qu’aucun numéro de téléphone ne correspond au format d’un numéro réellement attribué.
- Faire relire le script d’anonymisation par une deuxième personne avant de l’utiliser sur un environnement partagé.
En résumé
Un jeu de test réaliste ne s’obtient ni par un échantillonnage aléatoire ignorant les relations entre tables, ni par une copie brute d’un dump de production. Un extrait cohérent, anonymisé par un script versionné qui préserve le format attendu par le code, donne à l’équipe des données proches de la réalité sans exposer la moindre information personnelle véritable.
