Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Samedi 26 septembre 2026
RGPD

Données de production en test : décider sans copier

Données de production en test : choisissez un jeu fictif ou anonymisé, documentez une éventuelle préproduction et limitez les copies personnelles.

Un défaut n’apparaît que sur un dossier client particulier. L’équipe propose de copier la base de production dans son environnement de développement. Avant d’autoriser cet export, il faut préciser ce qu’elle cherche à reproduire : une structure de données, un volume, une relation entre objets ou le contenu personnel du dossier.

Distinguer les environnements et le besoin réel

Le RGPD impose la minimisation des données à l’Art. 5(1)(c), la protection dès la conception à l’Art. 25(1) et une sécurité adaptée au risque à l’Art. 32(1). Copier une base crée un nouveau lieu de traitement, de nouveaux accès et souvent de nouvelles durées de conservation. Source : texte officiel du RGPD.

Dans son guide de sécurité, la CNIL recommande des développements et tests dans des environnements distincts de la production, avec des données fictives ou anonymisées. Elle prévoit aussi le cas où celles-ci ne suffisent pas : une préproduction avec des données réelles peut être envisagée, avec un niveau de configuration et de sécurité équivalent à la production, après les tests préalables du service. CNIL, guide de sécurité, fiche 11, pages 26 et 27 imprimées.

Cette recommandation ne constitue pas une autorisation générale de recopier les données. Il reste à examiner la finalité, la base légale, la nécessité, l’information des personnes et, le cas échéant, les règles propres aux données sensibles. Le guide sur le privacy by design replace cette décision dans le projet.

Choisir le jeu selon ce qu’il faut vérifier

Besoin concret Première option à examiner Point de vigilance
Vérifier un formulaire Valeurs entièrement fictives Couvrir les formats difficiles sans utiliser de vraies coordonnées
Reproduire une relation entre dossiers Petit jeu fictif conservant les relations Garder la structure utile, sans copier les personnes
Évaluer la charge Données générées au volume requis Ne pas multiplier un extrait personnel présenté comme anonyme
Comprendre une erreur sur un document Reproduction du défaut sur un document fictif Vérifier les métadonnées et le texte caché
Vérifier une configuration réelle Configuration expurgée des identifiants et secrets Examiner les champs annexes et fichiers liés
Valider un comportement non reproductible autrement Analyse documentée d’une préproduction encadrée Justifier l’insuffisance des alternatives et limiter le périmètre

Le premier livrable utile est une phrase précise : « Nous devons reproduire une pièce jointe dont le nom contient tel caractère », ou « Nous devons vérifier une relation circulaire entre trois objets ». Elle permet souvent de construire un exemple fictif en quelques enregistrements.

Ne pas confondre masquage et anonymisation

Remplacer les noms ne suffit pas nécessairement. Une date rare, une adresse précise, un commentaire ou une combinaison de caractéristiques peuvent permettre de retrouver une personne. Une table de correspondance conservée transforme généralement l’opération en pseudonymisation plutôt qu’en anonymisation.

Le choix doit donc porter sur le risque d’identification dans le contexte de destination, et non sur la seule disparition de deux colonnes. Une donnée pseudonymisée reste susceptible de relever du RGPD. Le guide pseudonymisation et anonymisation explique cette distinction.

Examinez aussi les éléments que l’export principal oublie : pièces jointes, miniatures, commentaires, historiques, champs libres et liens vers des services réels. Un jeu présenté comme fictif peut encore envoyer un message à une vraie adresse si les intégrations restent actives.

Exemple : reproduire un défaut sans importer le client

Exemple hypothétique. Un logiciel rejette un dossier contenant une pièce jointe dont le nom dépasse une certaine longueur. Pour comprendre le défaut, l’équipe n’a pas besoin de l’identité du client ni de la pièce originale. Elle crée un document sans donnée réelle, lui donne un nom de même structure et reproduit les relations applicatives nécessaires.

Si le défaut concerne le contenu d’un document, l’équipe peut rechercher une reproduction minimale : type de fichier, encodage, taille ou mise en page. Elle documente les hypothèses utiles avant de conclure que le contenu original est indispensable.

Cette démarche applique le principe de minimisation au dépannage. Elle réduit aussi le nombre de copies qu’il faudra protéger puis supprimer.

Documenter une préproduction lorsque les alternatives échouent

Lorsqu’un besoin de données réelles persiste, préparez une fiche de décision avant le transfert. Le tableau suivant fournit son contenu, sans imposer un formulaire réglementaire particulier.

Rubrique Décision à documenter
Objectif Comportement précis qui reste impossible à vérifier autrement
Alternatives Jeux fictifs ou anonymisés essayés et limites observées
Périmètre Dossiers, champs et période strictement nécessaires
Licéité Finalité, base légale et conditions particulières applicables
Destinataires Personnes habilitées et éventuels prestataires
Environnement Configuration, cloisonnement, journalisation et sécurité comparables à la production
Flux Messages, paiements et intégrations désactivés ou isolés
Durée Date de fin, déclencheur de suppression et copies concernées
Validation Responsable de décision, avis utiles et conditions préalables

Si une nouvelle finalité est envisagée, analysez son articulation avec la collecte initiale : l’Art. 6(4) encadre, dans son champ d’application, l’examen de compatibilité. Écrire « test » dans le registre ne dispense pas de cet examen.

Un prestataire ne doit pas importer librement les données de son client dans son laboratoire. Ses opérations doivent rester couvertes par les instructions documentées exigées par l’Art. 28(3)(a). Un accès externe ou un hébergement supplémentaire doit également être examiné au regard du contrat et des transferts éventuels. Source : RGPD, chapitre IV.

Fermer le jeu et ses copies à la fin du travail

La fermeture du ticket technique ne supprime pas les fichiers exportés. Vérifiez l’environnement, les postes de travail autorisés, les pièces ajoutées aux tickets et les stockages temporaires. Conservez le compte rendu du diagnostic et les caractéristiques utiles de la reproduction, plutôt que le dossier client complet.

Prévoyez la clôture dès la fiche initiale : un responsable, un déclencheur et une preuve d’exécution. Les règles de conservation des données s’appliquent aussi à ces environnements secondaires.

Si une copie réelle a déjà circulé hors du périmètre autorisé, recherchez ses emplacements et ses destinataires, puis faites qualifier l’incident. Le simple mot « environnement de test » ne diminue pas les conséquences pour les personnes.

Ce qu’il faut retenir

  • Définissez le comportement à reproduire avant de sélectionner les données.
  • Privilégiez un jeu fictif ou correctement anonymisé dans un environnement distinct.
  • Une préproduction utilisant des données réelles exige un besoin démontré et un encadrement complet.
  • La suppression doit couvrir les fichiers de travail et pièces de support, pas seulement la base de test.

FAQ

Peut-on utiliser des données réelles en préproduction ?

La CNIL prévoit cette possibilité lorsque les jeux fictifs ou anonymisés ne suffisent pas, avec des conditions de sécurité et de tests préalables. La licéité, la nécessité et le périmètre du traitement doivent néanmoins être examinés.

Remplacer les noms rend-il la base anonyme ?

Pas nécessairement. D’autres informations ou leur combinaison peuvent permettre l’identification ; la présence d’une table de correspondance doit aussi être prise en compte.

Faut-il copier toute la base pour reproduire un défaut ?

Il faut d’abord rechercher le plus petit ensemble de caractéristiques permettant de le reproduire. Une copie complète doit être justifiée ; elle ne constitue pas un choix par défaut conforme à la minimisation.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →