Données de test et RGPD : tester sans copier la production

Copier la base de production pour tester une évolution ou reproduire un bug est un réflexe courant. Au regard du RGPD, il n’a rien d’anodin : la copie multiplie les endroits où se trouvent les données personnelles et les personnes qui y ont accès, et elle survit souvent à la recette. La CNIL recommande de développer et de tester sur des données fictives ou anonymisées. Ce guide explique pourquoi, comment s’y prendre, et ce qu’il faut prévoir quand un prestataire intervient sur l’application.

Il s’adresse aux DSI, aux responsables d’application et aux dirigeants dont l’application traite des données personnelles (clients, salariés, usagers) et qui la font développer ou maintenir, par leur équipe ou par un prestataire de maintenance applicative.

Pourquoi copier la production pour tester pose problème

Une copie de la base de production installée sur un serveur de recette ou sur le poste d’un développeur contient les mêmes données personnelles que l’original, mais rarement les mêmes protections : des accès plus larges, moins de journalisation, des sauvegardes que personne ne suit. Et elle a tendance à rester en place bien après la fin des tests.

Trois principes du RGPD sont en jeu.

• La minimisation. Les données doivent être « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées » (article 5). Tester un écran ne demande pas les vrais noms des clients.
• La protection dès la conception. L’article 25 demande au responsable du traitement de prévoir, dès la conception, des mesures « telles que la pseudonymisation » pour appliquer ces principes de façon effective. Les environnements de test font partie de cette conception.
• La sécurité. L’article 32 impose au responsable du traitement et au sous-traitant un niveau de sécurité adapté au risque. Une base de recette remplie de données réelles hérite de ce risque, sans en avoir les protections.

La CNIL résume le danger dans son guide RGPD pour les équipes de développement : utiliser les données de la base de production pour des tests augmente les risques de sécurité, et peut donner accès aux données à des personnes qui n’ont pas le besoin d’en connaître.

Ce que recommande la CNIL

Le guide de la sécurité des données personnelles de la CNIL consacre une fiche à l’encadrement des développements informatiques. Pour les tests, ses recommandations tiennent en quatre points.

• Développer et tester dans un environnement distinct de celui de la production : d’autres machines, physiques ou virtuelles.
• Travailler sur des données fictives ou anonymisées : « des jeux fictifs doivent être utilisés autant que possible ».
• Si ces données ne suffisent pas, tester en préproduction avec des données réelles, dans un environnement « configuré et sécurisé au même niveau que l’environnement de production lui-même ».
• N’y présenter qu’un service ou une mise à jour qui a déjà réussi ses tests unitaires, d’intégration et fonctionnels dans les environnements de développement et de test.

Le guide RGPD de l’équipe de développement de la CNIL va dans le même sens. Sa fiche « Tester vos applications » écarte les données réelles de production pendant le développement et les tests, et conseille de construire un jeu de données fictives qui ressemble aux données que traitera l’application : s’il est divulgué, les personnes n’en subissent aucune conséquence. À défaut, les environnements de test doivent recevoir les mêmes mesures de sécurité que la production, et une configuration importée de la production doit être anonymisée.

Fictives, anonymisées, pseudonymisées : ne pas confondre

Les trois mots ne désignent pas la même chose, et la différence a une conséquence directe : des données réellement anonymisées ne relèvent plus de la législation sur la protection des données, des données pseudonymisées si.

Définitions d’après l’article 4 du RGPD et la CNIL. La colonne « Usage en test » est notre synthèse de ses recommandations.

Une anonymisation réussie se vérifie. La CNIL retient trois critères.

• L’individualisation. Il ne doit pas être possible d’isoler un individu dans le jeu de données.
• La corrélation. Il ne doit pas être possible de relier entre eux des ensembles de données distincts.
• L’inférence. Il ne doit pas être possible de déduire, de façon quasi certaine, de nouvelles informations sur une personne.

En pratique, effacer les noms et les adresses e-mail ne suffit presque jamais : une date de naissance, une commune et une profession peuvent suffire à retrouver quelqu’un. Les champs de texte libre (commentaires, notes, pièces jointes) sont les plus difficiles à traiter, parce qu’ils contiennent des noms, des numéros et des détails de vie. La CNIL demande aussi une veille : les techniques de réidentification progressent, et une anonymisation jugée suffisante hier peut ne plus l’être.

La pseudonymisation, elle, est définie par l’article 4 du RGPD : les données ne peuvent plus être attribuées à une personne précise sans informations supplémentaires, conservées séparément. Elle reste réversible, et les données gardent leur caractère personnel. C’est une bonne mesure de sécurité, citée par les articles 25 et 32, pas un moyen de sortir du RGPD.

Reproduire un bug de production sans copier la base

C’est la situation où la tentation est la plus forte : un utilisateur signale une anomalie, elle ne se produit qu’avec ses données, et la copie de la base semble le plus court chemin. Il existe presque toujours une autre voie.

• Décrire le cas, pas la personne. Ce qui déclenche l’anomalie est une propriété des données : un champ vide, un caractère spécial, une date limite, un volume, une combinaison d’options. On la note dans le ticket, sans y copier la fiche de l’utilisateur.
• Reconstruire le cas avec des données fictives. Le jeu de test reçoit un enregistrement qui présente la même propriété. Il rejoint ensuite les tests automatisés : l’anomalie ne pourra pas revenir sans être vue.
• Extraire le minimum, anonymisé à la source. Si une partie des données réelles est indispensable, on n’extrait que les tables et les champs utiles, et on les anonymise avant qu’ils quittent l’environnement de production.
• Diagnostiquer sur place, sous contrôle. Quand rien d’autre ne marche, l’analyse se fait en production ou dans une préproduction sécurisée comme elle, par une personne habilitée, avec un accès tracé et limité dans le temps, plutôt qu’en faisant sortir les données.
• Nettoyer les journaux. Les journaux d’erreurs et les traces envoyées aux outils de suivi contiennent souvent des données personnelles : ils se masquent eux aussi.

Ces pratiques ne sont pas une contrainte de plus : un cas reproduit avec des données fictives se rejoue à volonté, se partage sans précaution et se teste automatiquement. C’est aussi ce qui rend les tests fiables dans la durée.

Quand un prestataire développe ou maintient l’application

Consulter des données fait partie des traitements définis par l’article 4 du RGPD. Dès qu’il accède à des données personnelles pour le compte de son client, un prestataire qui développe ou maintient l’application agit donc comme sous-traitant. Le contrat qui l’encadre doit contenir les mentions prévues par l’article 28, et le prestataire ne peut lui-même faire appel à un autre sous-traitant « sans l’autorisation écrite préalable, spécifique ou générale, du responsable du traitement ».

Pour les données de test, cinq points méritent une ligne dans le contrat ou dans son annexe.

• L’accès aux données de production : interdit par défaut, ou réservé à des personnes nommées, pour des opérations décrites.
• Les données de test : qui fournit le jeu, qui le construit, et selon quelle méthode d’anonymisation.
• Les environnements : où ils sont hébergés, qui y accède, et comment une éventuelle préproduction est sécurisée.
• La traçabilité : des accès nominatifs, journalisés, retirés au départ de chaque intervenant.
• La fin de la recette : la destruction des copies, sauvegardes comprises, et la preuve qu’elle a eu lieu.

Un point de plus si l’équipe du prestataire travaille hors de l’Espace économique européen : selon les recommandations 01/2020 du Comité européen de la protection des données, l’accès à distance depuis un pays tiers à des données situées dans l’EEE est un transfert, à encadrer par les outils du chapitre V du RGPD. Une équipe qui ne voit que des données fictives ou réellement anonymisées ne reçoit, elle, aucune donnée personnelle. Le cas d’une équipe de maintenance située loin ou hors de l’Union est détaillé dans notre comparatif maintenance applicative offshore ou nearshore.

Notre guide du contrat de maintenance applicative détaille les autres clauses à vérifier, et celui pour externaliser sa maintenance applicative ce que l’entreprise garde toujours chez elle.

Chez iones, c’est la règle : aucun développeur ne dispose d’un accès direct aux bases de données de production, et les équipes travaillent sur des environnements de développement et de staging isolés, avec des données anonymisées ou de test (voir la sécurité de vos données).

La check-list avant chaque recette

• Le jeu de test est fictif ou anonymisé, et la méthode est écrite.
• Aucun identifiant direct ne subsiste : nom, adresse e-mail, téléphone, adresse postale, numéro de client ou de contrat.
• Les champs de texte libre et les pièces jointes ont été vidés ou remplacés.
• Les journaux et les outils de suivi d’erreurs ne reçoivent pas de données réelles.
• Si des données réelles sont indispensables, l’environnement est sécurisé comme la production et la décision est documentée.
• Les accès sont nominatifs et tracés.
• La date de destruction des copies est fixée, sauvegardes comprises.

Questions fréquentes

Données de test : un livrable comme un autre

Ne pas copier la production n’est pas une contrainte de plus : c’est ce qui permet de tester souvent, de partager un cas sans précaution et de confier une application à une équipe externe sans exposer ses utilisateurs. La règle tient en une phrase : des données fictives par défaut, des données anonymisées quand le réalisme compte, des données réelles seulement dans un environnement protégé comme la production.

L’équipe nearshore d’iones assure la maintenance applicative et les tests d’applications existantes, sans accès direct aux bases de production. Vous pouvez aussi nous écrire pour un premier échange.