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

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

Le bon jeu de test conserve les propriétés nécessaires au diagnostic, sans importer les personnes par facilité. Cette démarche suppose un échange entre le métier, qui décrit le comportement attendu, et les développeurs, qui construisent les essais. Le DPO examine les traitements de données personnelles qui restent nécessaires, plutôt que de valider un export indifférencié.

Distinguer développement, test et préproduction

Copier une base crée un lieu de traitement supplémentaire, de nouveaux accès et souvent de nouvelles copies. Le RGPD impose la minimisation, la protection dès la conception et une sécurité adaptée au risque : Art. 5(1)(c), 25(1)–(2) et 32(1). Le mot « test » ne soustrait pas l’environnement à ces obligations. RGPD, principes et obligations du responsable.

La CNIL recommande de séparer développements et tests de la production et d’employer des données fictives ou anonymisées. Si elles ne suffisent pas, elle envisage une préproduction avec des données réelles, configurée et sécurisée au même niveau que la production, après les tests unitaires, d’intégration et fonctionnels. Guide de sécurité CNIL, fiche 11, pages imprimées 26–27.

Cette possibilité ne constitue pas une autorisation juridique générale. Il reste à examiner la finalité, la base légale, la nécessité, l’information des personnes et les règles particulières applicables aux données. Renommer « préproduction » un serveur de développement ouvert à toute l’équipe ne change ni ses protections ni ses usages.

Le privacy by design consiste ici à prévoir les moyens de diagnostic dès le projet : données générables, sorties contrôlables et accès limitables. Sans ces moyens, chaque anomalie devient une nouvelle demande de copie.

Traduire une anomalie en propriétés à reproduire

Écrivez d’abord une hypothèse testable. « Le dossier de Mme X ne fonctionne pas » décrit une observation ; « le dépôt échoue lorsque le nom du document dépasse la limite prévue » décrit une piste que l’équipe peut explorer sans reprendre le document.

Le volume seul ne garantit pas un essai représentatif. Dix mille lignes identiques peuvent ignorer les relations qui déclenchent le défaut. À l’inverse, trois objets correctement reliés peuvent suffire à reproduire une erreur rencontrée sur une base beaucoup plus grande.

Demandez au développeur ce qui manque lorsqu’il réclame des données réelles : quelle propriété le jeu actuel ne couvre-t-il pas ? Cette réponse peut justifier l’ajout d’un cas fictif, l’observation limitée d’une configuration ou une étude de préproduction. Elle ne conduit pas automatiquement à un export complet.

Exemple : une série d’essais qui remplace le dossier client

Considérons une application fictive de suivi de réparations. Son cahier des charges autorise des noms de pièces jointes jusqu’à 128 caractères, extension comprise, et exige un message explicite au-delà. Dans cet exemple, le nom est composé uniquement de caractères ASCII pour éviter toute ambiguïté de comptage. Ces valeurs décrivent le scénario, pas une limite réglementaire ou un produit existant.

Un agent habilité constate en production un message d’erreur incompréhensible lors d’un dépôt. L’équipe technique souhaite récupérer le dossier complet. Le métier refuse cette première proposition et transmet seulement l’hypothèse de format. Les développeurs créent deux comptes fictifs A et B, un dossier A-01 et des documents sans contenu personnel.

Le protocole préparé comporte cinq observations distinctes :

Les trois premiers essais concernent la limite ; les deux autres vérifient des effets voisins que la correction ne doit pas dégrader. Il ne suffit donc pas de constater qu’un message d’erreur a disparu.

Dans le scénario, T-03 produit le même message indéchiffrable que celui signalé. Le défaut est reproduit sans la pièce originale. Après correction, T-01 et T-02 restent acceptés, T-03 affiche le refus attendu, T-04 ne donne aucun accès et T-05 accepte le nouveau fichier. Le compte rendu conserve ces résultats et la version du logiciel. Aucun essai réel de votre application n’est présenté comme effectué ici.

La demande de copie du dossier est clôturée comme non nécessaire. Pour une prochaine anomalie, l’équipe dispose du jeu et de ses résultats attendus ; elle ne garde pas une archive personnelle « au cas où ». Cette décision applique le principe de minimisation à une difficulté technique déterminée.

Vérifier qu’un jeu annoncé fictif l’est vraiment

Un fichier généré peut contenir un pied de page copié, un auteur dans ses propriétés ou un lien donnant accès à un document réel. Un jeu de base de données peut conserver des commentaires, des miniatures ou des pièces jointes oubliées par le script de transformation.

Examinez les objets liés, pas seulement les colonnes principales. Remplacer les noms sans modifier des dates rares, des adresses précises ou des textes libres peut laisser une identification possible. Si l’organisme dispose encore d’une table de correspondance, il ne peut pas présenter la transformation comme une disparition générale du caractère personnel. La qualification dépend du contexte et des moyens d’identification pertinents ; le guide sur la pseudonymisation et l’anonymisation précise cette analyse.

Distinguez aussi le jeu créé de l’environnement qui le traite. Les comptes des développeurs, leurs adresses professionnelles et certains journaux restent des données personnelles, même lorsque les dossiers d’essai sont fictifs. Les règles d’habilitation et de conservation continuent de leur être appliquées.

Enfin, vérifiez les sorties. Un scénario fictif peut déclencher un vrai courriel si une ancienne adresse subsiste, ou appeler un service de paiement avec des identifiants de production. Utilisez des destinations contrôlées, isolez les intégrations et retirez les secrets inutiles. Un bouton « mode test » ne démontre pas à lui seul ce cloisonnement.

Quand les données réelles semblent indispensables

Une réponse documentée peut aboutir à un refus, à une réduction du périmètre ou à une préproduction encadrée. Elle doit permettre à la personne qui décide de comprendre pourquoi les alternatives sont insuffisantes, et non seulement que l’équipe préfère travailler sur la base réelle.

La fiche suivante peut servir de point d’arrêt avant l’export :

• Besoin résiduel : comportement exact non vérifiable avec les jeux préparés et résultats déjà obtenus.
• Données : dossiers, champs, objets liés et période nécessaires ; justification des éléments exclus ou conservés.
• Licéité : finalité, base légale, articulation avec la collecte initiale et conditions propres aux données sensibles, le cas échéant.
• Accès et flux : personnes habilitées, prestataires, pays, sorties actives et copies autorisées.
• Clôture : événement mettant fin au besoin, responsable de suppression et vérification des emplacements.

Une nouvelle finalité appelle l’analyse pertinente : l’Art. 6(4) prévoit, dans son champ, l’examen des liens entre finalités, du contexte, des données, des conséquences et des garanties. La base contractuelle initiale ne couvre pas toute expérimentation ultérieure. Les données de l’Art. 9(1) nécessitent aussi une condition applicable de l’Art. 9(2) ; un intérêt technique ne la remplace pas. RGPD, Art. 6(1), 6(4) et 9.

Le responsable du traitement doit faire établir cette analyse et prendre la décision ; le DPO conseille lorsqu’il est désigné. L’équipe technique confirme les conditions réellement disponibles. Si les droits ne peuvent pas être limités ou si la purge reste indéfinie, l’autorisation ne devrait pas présenter ces conditions comme déjà remplies.

Le prestataire, pour sa part, ne peut pas importer librement les données de son client dans son laboratoire. L’Art. 28(3)(a) impose des instructions documentées ; un nouvel intervenant et un accès hors EEE appellent leurs vérifications propres. L’Art. 35(1) impose une analyse d’impact lorsque le traitement envisagé est susceptible d’engendrer un risque élevé. RGPD, Art. 28 et 35.

Prévoir la fermeture avant la première copie

Les règles de conservation des données concernent aussi les environnements secondaires. La fin de l’abonnement ou du contrat de développement n’est pas automatiquement la bonne échéance pour chaque extrait. Reliez la durée au besoin documenté et organisez le retrait des copies dès qu’il prend fin.

Le contrôle doit couvrir la base de préproduction, les exports autorisés, les pièces de tickets et les stockages temporaires. Si une sauvegarde contient ces données, son traitement et une éventuelle restauration doivent être intégrés au dispositif. Supprimer l’environnement visible ne prouve pas la disparition de ses copies.

Conservez le résultat utile : hypothèse, version, périmètre des essais, décision et constat de clôture. Un compte rendu peut montrer qu’une opération a été vérifiée sans conserver le dossier personnel qui a servi à l’exécuter.

Si un extrait réel circule déjà hors du périmètre autorisé, arrêtez sa diffusion et recherchez les destinataires. Qualifiez les faits, documentez toute violation de données et évaluez les suites selon les Art. 33 et 34. Le nom du serveur ne diminue pas le risque pour les personnes. RGPD, sécurité et violations.

Ce qu’il faut retenir

• Décrivez la propriété à vérifier avant de sélectionner des données.
• Un jeu réduit doit couvrir les relations et les résultats attendus, pas seulement un volume.
• Une préproduction réelle exige une analyse juridique et des conditions techniques effectivement réunies.
• Prévoyez les sorties, les copies et leur fermeture dès la décision initiale.

FAQ

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

La CNIL envisage cette possibilité lorsque les essais fictifs ou anonymisés sont insuffisants, avec les conditions exposées dans son guide. La nécessité, la licéité et le périmètre restent à justifier dans votre situation.

Remplacer les noms rend-il la base anonyme ?

Pas nécessairement : d’autres informations, leurs combinaisons ou une correspondance conservée peuvent permettre l’identification. Une transformation doit être évaluée dans son contexte, y compris avec les fichiers liés.

Faut-il conserver l’extrait pour reproduire une future anomalie ?

Une utilité éventuelle ne justifie pas une conservation indéfinie. Préférez conserver les caractéristiques et le jeu fictif reproductible. Si un besoin personnel demeure, documentez son périmètre et sa durée.

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.