Base de données anonymisée pour le développement : le RGPD sans y penser

Travailler en local avec une copie brute de la base de production est une habitude confortable — et un risque réel au regard du RGPD. Emails de clients, noms, adresses de livraison, parfois même des données de commande : tout cela se retrouve alors sur des postes de développeurs, potentiellement synchronisé sur des ordinateurs personnels, des dépôts de sauvegarde tiers, voire des messages Slack au moment de partager un export « juste pour debug ».

Ce tutoriel construit un script qui anonymise systématiquement les données personnelles lors de l’export vers un environnement local, sans jamais empêcher le débogage réel : les structures, les volumes et les relations entre tables restent identiques à la production. Il ne couvre pas la synchronisation bidirectionnelle de bases, qui pose des problèmes différents.

Ce qu’il faut anonymiser dans une base WordPress classique

Sur un site avec WooCommerce, les données personnelles ne se limitent pas à la table wp_users :

• wp_users : user_email, display_name, user_login potentiellement nominatif
• wp_usermeta : prénom, nom, adresse de facturation stockés en métadonnées
• wp_postmeta (commandes WooCommerce) : _billing_email, _billing_first_name, _billing_address_1, _shipping_*
• wp_comments : comment_author_email, comment_author_IP

Export puis anonymisation en une étape

La stratégie la plus fiable consiste à importer la base normalement, puis à exécuter immédiatement un script SQL d’anonymisation avant que quiconque n’ouvre la base localement :

wp db import production.sql --allow-root
wp db query "$(cat anonymize.sql)" --allow-root

Le script SQL d’anonymisation

-- Utilisateurs : email et identifiants factices mais uniques
UPDATE wp_users
SET user_email = CONCAT('user', ID, '@exemple.test'),
    user_login = CONCAT('utilisateur', ID),
    display_name = CONCAT('Utilisateur ', ID),
    user_pass = MD5(RAND());

-- Métadonnées de facturation WooCommerce
UPDATE wp_usermeta
SET meta_value = 'Prénom'
WHERE meta_key = 'billing_first_name';

UPDATE wp_usermeta
SET meta_value = 'Nom'
WHERE meta_key = 'billing_last_name';

UPDATE wp_usermeta
SET meta_value = CONCAT('user', user_id, '@exemple.test')
WHERE meta_key = 'billing_email';

-- Commandes : adresses de facturation et livraison
UPDATE wp_postmeta
SET meta_value = CONCAT('commande', post_id, '@exemple.test')
WHERE meta_key IN ('_billing_email');

UPDATE wp_postmeta
SET meta_value = '1 rue Fictive, 75000 Paris'
WHERE meta_key IN ('_billing_address_1', '_shipping_address_1');

-- Commentaires publics
UPDATE wp_comments
SET comment_author = CONCAT('Visiteur', comment_ID),
    comment_author_email = CONCAT('visiteur', comment_ID, '@exemple.test'),
    comment_author_IP = '0.0.0.0';

Le domaine @exemple.test n’est pas anodin : il fait partie des domaines réservés par l’IANA pour la documentation et les tests, garantissant qu’aucun email ne partira réellement vers une boîte existante si un envoi transactionnel se déclenche accidentellement en local.

Garder un compte administrateur exploitable

Anonymiser aveuglément tous les comptes rend aussi illisible le compte administrateur du développeur. Une exclusion ciblée règle ce point :

UPDATE wp_users
SET user_email = CONCAT('user', ID, '@exemple.test')
WHERE user_login NOT IN ('admin_dev');

UPDATE wp_users
SET user_pass = MD5('motdepasse-local')
WHERE user_login = 'admin_dev';

Automatiser dans le script de synchronisation

Ce script d’anonymisation gagne à être intégré directement à la routine db-pull habituelle du projet, pour qu’il s’exécute systématiquement, sans dépendre de la mémoire du développeur :

#!/bin/bash
set -euo pipefail
wp db export - --allow-root --path=/var/www/prod > /tmp/prod.sql
wp db import /tmp/prod.sql --allow-root
wp db query "$(cat scripts/anonymize.sql)" --allow-root
rm /tmp/prod.sql
echo "Base importée et anonymisée."

La règle que j’applique sur tous les projets clients : aucune donnée personnelle réelle ne doit pouvoir techniquement se retrouver sur un poste de développement, même par accident. Ça évite d’avoir à faire confiance à la discipline de chacun.

Limites de cette approche

Ce script couvre les champs les plus courants, mais chaque extension ajoute potentiellement ses propres métadonnées personnelles — un plugin de newsletter, un système de points de fidélité, un formulaire personnalisé stockant des numéros de téléphone. Un audit ponctuel de la structure de la base avec wp db query "SHOW TABLES" puis un examen des postmeta et usermeta spécifiques au projet reste nécessaire avant de considérer le script complet.

En résumé

Anonymiser une base de production avant son usage en local n’est ni compliqué ni coûteux en temps une fois le script écrit — l’essentiel du travail consiste à identifier une bonne fois pour toutes les champs sensibles spécifiques au projet. Ce n’est plus vraiment une option depuis le RGPD, mais une pratique qui devrait faire partie du script de synchronisation dès le premier jour d’un projet, pas ajoutée après coup lors d’un audit de conformité.