Données de test ERP et anonymisation RGPD : guide pratique des 5 méthodes

Le projet ERP entre en recette. Les key users attendent un environnement “comme la vraie vie”, l’intégrateur réclame des données réalistes, et quelqu’un propose la solution la plus rapide : restaurer une sauvegarde de production dans la sandbox. En une nuit, le problème est réglé. Pour le projet, du moins.

Pour l’entreprise, vous venez de dupliquer vos fichiers clients, vos données de paie, vos IBAN fournisseurs et vos échanges commerciaux dans un environnement moins protégé, accessible à des prestataires, parfois hors de l’Union européenne. Ce guide présente les cinq façons de constituer des données de test pour un ERP, leurs forces et leurs pièges, ce qu’il faut anonymiser en priorité, comment préserver la cohérence des données, et une checklist de dix points à valider avant d’ouvrir la recette.

Pourquoi la copie brute de production en recette est un risque RGPD

La tentation est compréhensible : rien ne ressemble mieux à la production que la production. Mais trois principes du RGPD s’y opposent frontalement (texte du règlement sur EUR-Lex).

• Limitation des finalités (article 5.1.b) : des données collectées pour facturer un client ou payer un salarié ne l’ont pas été pour tester un logiciel. Les réutiliser en recette est un détournement de finalité, sauf à documenter une base juridique compatible, ce qui est rarement défendable.
• Minimisation (article 5.1.c) et limitation de la conservation (article 5.1.e) : une recette n’a pas besoin de dix ans d’historique de paie, et la copie reste souvent en place des mois après la fin du projet.
• Sécurité et protection dès la conception (articles 25 et 32) : un environnement de test dispose rarement du même niveau de contrôle d’accès, de journalisation et de chiffrement que la production. La CNIL recommande de développer et tester dans des environnements distincts de la production, avec des données fictives ou anonymisées (CNIL, Tester vos applications).

Dans un ERP, l’exposition est maximale parce que les données sont transverses :

• Données RH et paie : salaires, arrêts maladie, coordonnées bancaires, parfois numéros de sécurité sociale. C’est le périmètre le plus sensible, détaillé dans notre article sur les risques RGPD des modules RH et paie.
• Tiers : clients, fournisseurs, contacts, adresses, emails, conditions commerciales.
• Données bancaires : IBAN, mandats SEPA, relevés rapprochés.
• Accès élargis : en recette, on ouvre des comptes à l’intégrateur, à des consultants, à des équipes offshore et à des key users qui n’ont jamais eu accès à ces données en production.

Le risque se matérialise de deux façons : une fuite depuis l’environnement de test, souvent moins surveillé, ou un contrôle qui découvre que des données personnelles réelles circulent chez un sous-traitant sans cadre contractuel adapté. Dans les deux cas, la question posée sera la même : pourquoi avoir utilisé des données réelles alors que des alternatives existaient ?

Les 5 approches pour constituer des données de test ERP

Il n’existe pas de méthode unique. Le bon choix dépend du périmètre testé (une recette fonctionnelle de la comptabilité n’a pas les mêmes besoins qu’un test de performance) et du niveau de risque acceptable.

1. La copie complète de production

On restaure l’intégralité de la base en sandbox. C’est le réalisme maximal et l’effort minimal, mais c’est aussi le risque maximal. Toutes les données personnelles sont présentes, avec leur historique complet. Cette approche n’est défendable que dans un environnement de préproduction traité comme la production : mêmes contrôles d’accès, même chiffrement, même journalisation, périmètre d’utilisateurs restreint. La CNIL admet le recours à des données réelles en préproduction uniquement lorsque les données fictives ou anonymisées ne suffisent pas, avec un niveau de sécurité équivalent à la production.

2. La copie partielle (sous-ensemble)

On extrait un sous-ensemble cohérent : une filiale, un exercice, un échantillon de clients. Le volume diminue, donc le coût de stockage et le temps de rafraîchissement aussi, et l’exposition est réduite par la minimisation. Mais les données restent réelles : un sous-ensemble non masqué n’est pas moins personnel qu’un ensemble complet. Le piège technique est l’intégrité référentielle : extraire 500 clients sans leurs factures, leurs écritures et leurs articles produit une base inutilisable.

3. Le masquage et l’anonymisation

On part d’une copie de production, puis on remplace les valeurs sensibles (noms, adresses, IBAN, emails) par des valeurs fictives avant de rendre l’environnement accessible. C’est le meilleur compromis réalisme/risque pour la majorité des projets. Attention à la terminologie : une anonymisation au sens du RGPD rend toute ré-identification impossible, de façon irréversible (considérant 26). Un simple masquage de quelques colonnes, qui laisse subsister des recoupements possibles (date de naissance, ville et poste suffisent souvent), relève en pratique de la pseudonymisation. Le point critique : la copie brute transite par un environnement intermédiaire avant masquage, qui doit lui-même être sécurisé et éphémère.

4. La pseudonymisation réversible

Les identifiants directs sont remplacés par des jetons, et la table de correspondance est conservée séparément. Elle permet de retrouver la donnée d’origine, par exemple pour reproduire un incident de production. Mais l’article 4.5 du RGPD est clair : des données pseudonymisées restent des données personnelles. Tout le dispositif RGPD continue de s’appliquer, et la table de correspondance devient un actif sensible à isoler, dans un périmètre sans aucun accès pour l’intégrateur ni les testeurs.

5. Les données synthétiques

On génère des données entièrement fictives à partir de règles : une population de clients, des articles, des commandes, des écritures équilibrées. Le risque RGPD est quasi nul puisqu’aucune personne réelle n’est concernée, et le jeu est reproductible et partageable. Le coût d’entrée est plus élevé : il faut modéliser la diversité réelle (cas limites, taux de TVA multiples, devises, remises exceptionnelles) pour que les tests soient crédibles. Les données synthétiques excellent pour les tests de non-régression et de performance, moins pour la recette métier où les utilisateurs veulent reconnaître “leurs” cas.

Tableau comparatif

Approche	Réalisme	Coût de mise en place	Risque RGPD	Effort de rafraîchissement
Copie complète	Maximal	Faible	Très élevé	Faible
Copie partielle	Élevé	Moyen	Élevé (données réelles)	Moyen
Masquage / anonymisation	Élevé	Moyen à élevé	Faible à moyen, selon la qualité du masquage	Moyen (script à rejouer)
Pseudonymisation réversible	Élevé	Élevé	Moyen (données toujours personnelles)	Moyen à élevé
Données synthétiques	Moyen, selon la modélisation	Élevé	Quasi nul	Faible une fois le générateur construit

En pratique, les projets matures combinent : un jeu synthétique pour les tests techniques et automatisés, une copie masquée pour la recette métier, et une préproduction sécurisée comme la production pour la répétition finale de bascule.

Quoi anonymiser en priorité dans un ERP

Commencez par cartographier où vivent les données personnelles, en vous appuyant sur le registre des traitements. Voici l’ordre de priorité habituel.

• Les tiers (clients, fournisseurs, contacts) : raison sociale des entrepreneurs individuels, noms de contacts, adresses, téléphones. Les personnes morales ne sont pas protégées par le RGPD, mais leurs contacts le sont, et les entrepreneurs individuels sont des personnes physiques.
• RH et paie : identité, rémunération, absences, coordonnées bancaires. À exclure de la recette dès que possible, ou à remplacer par des salariés fictifs.
• IBAN, SIRET, numéros de TVA, numéros de sécurité sociale : à remplacer par des valeurs fictives mais valides en format.
• Emails : un risque souvent sous-estimé. Une recette qui déclenche l’envoi réel de relances ou de factures à de vrais clients est un incident classique. Remplacez les domaines par un domaine inexistant ou une boîte de capture, et désactivez les connecteurs de messagerie sortante.
• Pièces jointes : factures PDF, contrats, bulletins de paie scannés, copies de pièces d’identité. Elles contiennent les données réelles même si la base est masquée.

Le piège des champs texte libres et de la GED

C’est là que les projets échouent le plus souvent. Un masquage soigneux des colonnes “nom” et “IBAN” laisse intacts les champs de commentaires (“rappeler M. Durand au 06…”, “arrêt maladie jusqu’au 15”), les libellés d’écritures comptables, les notes de frais, les motifs de blocage de paiement et les documents rattachés dans la gestion électronique des documents. Ces champs ne suivent aucun format et échappent aux règles de masquage par colonne.

Trois réponses se combinent : vider ou remplacer les champs libres par un texte neutre dans l’environnement de test, ne pas migrer la GED (ou la remplacer par un échantillon de documents fictifs), et scanner les champs restants avec des expressions régulières (emails, téléphones, IBAN) pour détecter ce qui subsiste.

Préserver la cohérence : le masquage qui ne casse pas l’ERP

Un masquage mal conçu produit des données anonymes mais inutilisables. Quatre exigences de cohérence s’imposent.

• Intégrité référentielle : un même client doit recevoir le même nom fictif dans toutes les tables et tous les modules (ventes, comptabilité auxiliaire, CRM, interfaces). Utilisez un masquage déterministe (une fonction qui produit toujours la même valeur de remplacement pour une valeur d’origine), plutôt qu’un tirage aléatoire à chaque table.
• Totaux comptables : on masque les identités, pas les montants. Si vous modifiez des montants, les balances, les rapprochements et les états de TVA deviennent faux, et la recette comptable n’a plus de valeur. La sensibilité des montants est un sujet de confidentialité commerciale, à traiter séparément du RGPD.
• Clés de rapprochement : numéros de pièces, références de commande, numéros de lots et références bancaires utilisés pour le lettrage doivent rester cohérents entre eux.
• Formats valides : un IBAN fictif doit respecter la clé de contrôle, un numéro de TVA le format du pays, un SIRET l’algorithme de Luhn. Sinon, les contrôles de saisie de l’ERP rejettent les données ou, pire, les tests de validation passent à côté de vrais cas.

Ce travail rejoint celui de la migration de données : les mêmes règles de nettoyage et de validation s’appliquent, comme détaillé dans notre méthodologie de migration de données ERP en 7 étapes. Un jeu de recette bien construit sert souvent aussi de banc d’essai pour les répétitions de migration.

Outils et mécanismes par éditeur

Les fonctionnalités évoluent selon les versions et les licences. Les pistes ci-dessous sont des points de départ à faire confirmer par l’éditeur ou l’intégrateur, pas des garanties.

• SAP : l’écosystème SAP propose des solutions de gestion de données de test (la famille TDMS et des outils de masquage ou d’obfuscation de données, y compris chez des éditeurs tiers). Leur disponibilité dépend de la version (ECC, S/4HANA) et du modèle de déploiement. Vérifiez auprès de SAP ou de votre partenaire ce qui est supporté dans votre contexte, notamment en cloud public où la logique d’environnements est différente.
• Microsoft Dynamics 365 : le modèle d’environnements (production, sandbox) permet de créer des copies de production dans des sandbox. Une copie de production dans une sandbox embarque les données : la mise en place d’une étape de masquage entre la copie et l’ouverture aux utilisateurs reste à votre charge, via des scripts ou des outils tiers.
• Odoo : en édition auto-hébergée, la base PostgreSQL permet d’écrire des scripts SQL ou Python de masquage appliqués après restauration, ce qui donne beaucoup de liberté mais exige de maintenir ces scripts à chaque évolution du modèle de données. Les bases de test doivent aussi neutraliser les serveurs d’envoi d’emails et les tâches planifiées.
• Autres éditeurs (Sage, Cegid, Divalto…) : renseignez-vous sur les procédures de duplication d’environnement et sur la possibilité d’exécuter un script de masquage avant ouverture.

Quel que soit l’éditeur, deux réflexes évitent l’essentiel des incidents : automatiser le masquage dans un script versionné et rejouable, et désactiver tous les connecteurs sortants (email, SMS, EDI, banque, facture électronique) de l’environnement de test. Les principes d’organisation des environnements sont détaillés dans notre guide sur les environnements sandbox, test et staging.

Le processus de rafraîchissement de la sandbox

Un jeu de données de test se dégrade : les cas évoluent, les paramétrages dérivent, les données vieillissent. Il faut donc un processus de rafraîchissement, et non une opération ponctuelle.

• Fréquence : avant chaque cycle de recette majeur, et à l’approche de la répétition générale de bascule. Un rafraîchissement mensuel automatique devient excessif si personne ne l’utilise ; la bonne fréquence suit le calendrier du projet.
• Responsabilités : l’équipe technique exécute le script ; le chef de projet planifie ; le DPO valide la méthode de masquage et en garde la trace ; le propriétaire métier valide que les données restent exploitables.
• Registre RGPD : si l’environnement de test contient des données personnelles (même pseudonymisées), il est un traitement à documenter dans le registre, avec sa finalité, ses destinataires et sa durée.
• Durée de conservation : fixez une date de fin à chaque environnement et à chaque copie. À la clôture du projet, détruisez les sauvegardes de production restaurées et les tables de correspondance. Une copie “temporaire” qui survit des années est la situation la plus courante dans les audits.
• Contrat avec l’intégrateur : si l’intégrateur accède à des données personnelles, même masquées imparfaitement, il agit comme sous-traitant au sens de l’article 28 du RGPD. L’accord de sous-traitance doit couvrir les environnements de test, la localisation des accès (en cas d’équipes hors UE, les règles de transfert s’appliquent) et la restitution ou destruction des données en fin de mission.

Checklist en 10 points avant d’ouvrir un environnement de recette

1. Les données personnelles de l’ERP sont cartographiées (tables, champs libres, GED, interfaces).
2. L’approche retenue (parmi les cinq) est choisie et justifiée par écrit, avec l’avis du DPO.
3. Aucune copie brute de production n’est accessible aux testeurs et prestataires.
4. Le script de masquage est versionné, rejouable et testé sur un échantillon.
5. Les champs texte libres et les pièces jointes sont traités (vidés, remplacés ou exclus).
6. Les contrôles de cohérence sont passés : intégrité référentielle, balances, rapprochements, formats IBAN et TVA.
7. Tous les connecteurs sortants (email, SMS, banque, EDI, facture électronique) sont désactivés.
8. Les accès sont nominatifs, limités au besoin, journalisés, et revus avec l’intégrateur.
9. Le traitement figure dans le registre, et l’accord de sous-traitance couvre les environnements de test.
10. Une date de destruction est fixée pour l’environnement, les sauvegardes et les tables de correspondance.

Cette checklist s’insère naturellement dans la préparation de la recette utilisateur décrite dans notre guide des tests et de la recette ERP (UAT).

Aller plus loin

Une donnée de test mal maîtrisée coûte moins cher à corriger avant l’ouverture de la recette qu’après un incident. Pour structurer la démarche, téléchargez notre checklist de recette ERP ou échangez avec l’équipe DigitsLane sur la construction d’un jeu de données de test adapté à votre projet. Pour le cadre réglementaire général, consultez aussi notre guide sur la conformité RGPD d’un ERP.