Tester son SaaS avec des données réelles : le cadre juridique

Par David Joseph Atias, avocat au Barreau de Paris · LinkedIn · Octobre 2026

Copier la base de production en recette « pour tester avec du vrai » ? Le réflexe est répandu chez les éditeurs SaaS. Il compte pourtant parmi les plus risqués au regard du RGPD. Utiliser des données réelles en environnement de test n’est pas interdit en soi. Cependant, la CNIL le déconseille et l’encadre strictement. Voici les règles à appliquer, de la donnée fictive à la préproduction sécurisée.

SOMMAIRE

1. Pourquoi les données réelles en environnement de test posent problème
2. Données réelles, environnement de test : le cadre juridique
3. Données réelles en environnement de test : les 7 règles
4. Tableau de synthèse par type de données
5. Les pièges à éviter
6. Pourquoi faire appel à Atias Avocats
7. FAQ — Questions fréquentes

1. Pourquoi les données réelles en environnement de test posent problème

Un SaaS évolue en continu : nouvelles fonctionnalités, migrations, corrections. Chaque évolution doit donc être testée avant sa mise en production. Or les équipes techniques veulent tester sur des cas réalistes. C’est pourquoi la tentation d’utiliser les vraies données est forte.

1.1 Le réflexe de la copie de production

Rien ne ressemble plus aux vraies données que les vraies données. En effet, les volumes, les formats et les anomalies y sont exacts. La copie de la base de production vers la recette devient donc un réflexe. Elle se fait pourtant souvent sans validation du délégué à la protection des données (DPO), ni trace écrite.

1.2 Un angle mort de la sécurité

Les environnements de test sont en général moins protégés que la production. Les accès y sont aussi plus larges : développeurs, prestataires, stagiaires. Les mots de passe et clés d’accès traînent parfois dans le code. De plus, les copies se multiplient sans inventaire. Une fuite y expose pourtant les mêmes personnes qu’en production.

1.3 Un point examiné lors d’une levée de fonds

Les investisseurs auditent désormais la conformité des startups SaaS au RGPD. Ainsi, une base clients dupliquée dans des environnements mal maîtrisés constitue un signal d’alerte. Voir à ce sujet notre article sur la due diligence juridique avant une levée de fonds.

2. Données réelles, environnement de test : le cadre juridique

2.1 Les principes du RGPD

Le règlement (UE) 2016/679, dit RGPD, ne cite pas les environnements de test. En revanche, plusieurs de ses principes s’y appliquent directement :

• Limitation des finalités (art. 5, 1, b) : les données ont été collectées pour fournir le service, pas pour tester. Le test est donc un traitement ultérieur, dont la compatibilité doit être appréciée (art. 6, 4).
• Minimisation (art. 5, 1, c) : seules les données nécessaires au test peuvent être utilisées.
• Limitation de la conservation (art. 5, 1, e) : les copies ne doivent pas survivre au test.
• Protection dès la conception (art. 25) : le texte cite expressément la pseudonymisation.
• Sécurité (art. 32) : les mesures doivent être adaptées au risque, y compris hors production.
• Analyse d’impact (art. 35) : elle s’impose si le traitement présente un risque élevé.

2.2 La position de la CNIL

La CNIL recommande de développer et de tester dans un environnement distinct de la production. C’est le sens de sa fiche « Encadrer les développements informatiques ». Elle range par ailleurs l’usage de données réelles pendant le développement et les tests parmi les pratiques à éviter. Des jeux de données fictives doivent donc être utilisés autant que possible. De même, son guide RGPD du développeur y consacre une fiche, « Tester vos applications ». Si la préproduction exige des données réelles, elle demande alors une sécurité identique à celle de la production.

2.3 Anonymisation ou pseudonymisation : une distinction décisive

Des données réellement anonymes sortent du champ du RGPD (considérant 26). En revanche, des données pseudonymisées restent des données personnelles pour qui détient la clé (art. 4, 5). La Cour de justice l’a confirmé (CJUE, 4 sept. 2025, CEPD c/ CRU, C-413/23 P). Elle admet toutefois qu’un destinataire sans moyen raisonnable de réidentification peut ne pas traiter de données personnelles. Or l’éditeur conserve presque toujours la table de correspondance. Pour lui, la donnée de test pseudonymisée reste donc soumise au RGPD.

3. Données réelles en environnement de test : les 7 règles

3.1 Partir de données fictives ou synthétiques

La règle par défaut reste le jeu de données fictives. Par exemple, des générateurs produisent des noms, adresses et historiques crédibles, sans lien avec des personnes réelles. En pratique, ils suffisent pour l’essentiel des tests unitaires et d’intégration. Les données réelles en environnement de test deviennent ainsi l’exception, et non la norme.

3.2 Anonymiser vraiment, pas en apparence

Supprimer les noms ne suffit pas. En effet, une date de naissance, un code postal et un poste permettent parfois de réidentifier une personne. Le groupe de travail des autorités européennes (G29) retient trois critères. Il ne doit plus être possible d’isoler une personne, de relier des données ou d’en déduire des informations (avis 05/2014). Un test de réidentification doit donc être mené et documenté.

3.3 Justifier le recours aux données réelles

Certains tests exigent des données réelles : migration, reprise de données ou analyse d’un incident. Dans ce cas, il faut documenter la nécessité et l’impossibilité de faire autrement. Le traitement de test doit aussi figurer au registre des traitements (art. 30). De plus, sa compatibilité avec la finalité initiale doit être analysée (art. 6, 4).

3.4 Minimiser et masquer

D’abord, on n’importe que l’échantillon et les champs utiles au test. Ensuite, les champs sensibles sont masqués ou remplacés : identité, coordonnées, données bancaires, commentaires libres. La pseudonymisation s’applique alors aux identifiants restants. Enfin, la clé de correspondance est conservée hors de l’environnement de test, avec un accès restreint.

3.5 Sécuriser la recette comme la production

L’environnement qui reçoit des données réelles doit offrir le même niveau de sécurité que la production. Cela implique des accès nominatifs, une authentification forte et une journalisation des consultations. Le chiffrement des sauvegardes s’impose aussi. Par ailleurs, les secrets d’authentification doivent changer lors du passage en production. Pour un exemple d’exigences concrètes, voir les mesures de sécurité exigées par la CNIL pour les données de santé.

3.6 Limiter la durée et purger

Les données copiées ont une durée de vie limitée au test (art. 5, 1, e). Une purge automatique doit donc être programmée dès l’import. Elle doit notamment couvrir les sauvegardes, les journaux et les exports locaux. À défaut, des copies oubliées subsistent pendant des années.

3.7 Encadrer les prestataires et les transferts

Les tests sont souvent confiés à une entreprise de services numériques, à un freelance ou à une équipe à l’étranger. Ce prestataire agit alors comme sous-traitant. Un accord de sous-traitance s’impose donc, comme l’explique notre décryptage de l’article 28 du RGPD. Si l’équipe est hors de l’Union européenne, le transfert doit en outre être encadré (art. 44 et suivants). Voir notre point sur les transferts de données hors UE. Enfin, le contrat de développement doit interdire l’usage de données de production non autorisées.

4. Tableau de synthèse par type de données

5. Les pièges à éviter

5.1 Confondre pseudonymisation et anonymisation

Remplacer un nom par un identifiant ne rend pas la donnée anonyme. En effet, tant que la clé existe, la donnée reste personnelle pour l’éditeur. Le comité européen de la protection des données (CEPD) le rappelle dans ses lignes directrices 01/2025 sur la pseudonymisation. Celle-ci reste néanmoins une mesure de sécurité précieuse, au sens des articles 25 et 32.

5.2 Oublier les données sensibles et de santé

Les données de santé, d’opinion ou biométriques relèvent d’un régime renforcé (art. 9). Leur présence en environnement de test aggrave donc fortement le risque. Par ailleurs, l’hébergement de données de santé par un tiers peut exiger une certification HDS (C. santé publ., art. L. 1111-8). Voir notre article sur le contrat d’hébergement de données de santé.

5.3 Croire que les données synthétiques sont toujours anonymes

Générer des données synthétiques à partir de la production est déjà un traitement de données personnelles. De plus, un modèle de génération mal paramétré peut reproduire des enregistrements réels. Il faut donc tester la proximité entre données générées et données sources. Ce n’est qu’à cette condition qu’elles peuvent être traitées comme anonymes.

5.4 Tester ou entraîner une IA avec des données de production (AI Act)

Réutiliser les données clients pour entraîner ou tester une fonctionnalité d’IA constitue une nouvelle finalité. Elle exige ainsi une analyse de compatibilité et souvent une base légale distincte. Côté AI Act, le règlement (UE) 2024/1689 impose une gouvernance des jeux d’entraînement, de validation et de test (art. 10). Pour les systèmes à haut risque de l’annexe III, cette obligation s’appliquera à compter du 2 décembre 2027. Ce report résulte du règlement (UE) 2026/1744. Par ailleurs, l’AI Act exclut les tests menés avant la mise sur le marché (art. 2, 8). Les essais en conditions réelles font exception (art. 60). Le RGPD continue toutefois de s’appliquer à ces tests. Voir notre guide des obligations de l’AI Act pour les entreprises.

6. Pourquoi faire appel à Atias Avocats

Encadrer les données réelles en environnement de test exige de parler deux langues. D’une part, celle du RGPD et de la doctrine de la CNIL. D’autre part, celle des équipes techniques : recette, préproduction, intégration continue. Notre cabinet fait ainsi le lien entre les deux, avec des règles directement applicables par les développeurs. S’y ajoutent désormais les contrats de développement et l’AI Act.

Nous conduisons notamment les missions suivantes :

• audit des environnements non productifs et des copies de données ;
• rédaction d’une politique de données de test, utilisable par les équipes ;
• analyse de nécessité, mise à jour du registre et analyse d’impact ;
• clauses de données de test dans les contrats de développement et les accords de sous-traitance ;
• encadrement des équipes de développement situées hors de l’Union européenne ;
• gouvernance des données d’entraînement et de test des fonctionnalités d’IA.

Découvrez nos services en contrats informatiques. Vous souhaitez sécuriser vos environnements de test ? Contactez le cabinet.

Conclusion

Les données réelles en environnement de test ne sont pas interdites, mais elles doivent rester l’exception. En pratique, la donnée fictive ou anonymisée couvre l’essentiel des besoins. Lorsque la donnée réelle est indispensable, elle doit être justifiée, minimisée, sécurisée et purgée. En revanche, la copie intégrale de production reste à proscrire. Une politique de données de test simple suffit souvent à transformer un risque en argument de confiance.

FAQ — Questions fréquentes

Peut-on utiliser des données de production pour tester un logiciel ?

La CNIL le déconseille et recommande des données fictives. Si des données réelles sont indispensables, il faut documenter cette nécessité et minimiser les données. L’environnement doit alors être sécurisé comme la production, puis purgé après le test.

Les données pseudonymisées sont-elles soumises au RGPD ?

Oui, pour qui détient la clé de correspondance (RGPD, art. 4, 5). La Cour de justice admet qu’un destinataire sans moyen raisonnable de réidentification peut ne pas être concerné. Mais l’éditeur qui conserve la clé reste soumis au RGPD.

Les données synthétiques sont-elles des données personnelles ?

Leur génération à partir de données réelles est un traitement de données personnelles. En revanche, le résultat peut sortir du RGPD s’il ne permet aucune réidentification. Il faut donc tester ce risque avant de les traiter comme anonymes.

Quelles mesures de sécurité pour un environnement de recette ?

Avec des données réelles, la recette doit être sécurisée comme la production. Cela implique des accès nominatifs, une authentification forte, une journalisation et des sauvegardes chiffrées. Les secrets doivent aussi être changés lors du passage en production.

Faut-il une analyse d’impact pour tester avec des données réelles ?

Elle s’impose si le traitement présente un risque élevé (RGPD, art. 35). C’est souvent le cas avec des données sensibles, des volumes importants ou de l’IA. À défaut, la nécessité du test doit au moins être documentée.

Contact : david@atiasavocats.com | LinkedIn: David Joseph Atias | https://www.atiasavocats.com | 42 rue de la Clef, 75005 Paris

Atias Avocats — Contrats IT & SaaS, RGPD, Sécurité des données, AI Act