La question arrive presque toujours trop tard dans les projets d'application : avec quelles données allez-vous faire tourner le prototype ? Le réflexe naturel consiste à copier un extrait de la base de production, parce que c'est rapide et réaliste. C'est aussi la décision qui expose le plus une PME, et la CNIL est explicite sur le sujet depuis longtemps.

Un prototype est un environnement à part entière

Sur le papier, un prototype est provisoire. Dans la réalité, il vit plusieurs semaines, il est hébergé sur une plateforme choisie en quelques minutes, il est ouvert à un cercle large (dirigeant, testeurs métier, prestataire, parfois un client pilote) et il garde rarement trace de qui a consulté quoi. Les mots de passe y sont plus simples et personne ne surveille ses journaux.

Mettre dans cet environnement le fichier clients complet, les bulletins de paie ou l'historique des dossiers revient donc à créer une copie de vos données les plus sensibles dans l'endroit le moins protégé de votre système d'information. Dans sa fiche « Sécurité des données : les règles essentielles », mise à jour le 19 juin 2026, la CNIL résume la logique de minimisation d'une phrase difficile à contredire : les données que vous ne possédez pas ne peuvent pas être volées. Et le régulateur reste très actif : le 24 août 2026, il a rendu publique une sanction de près de 825 millions d'euros à l'encontre d'Uber au sujet de décisions automatisées.

Ce que dit précisément la CNIL sur les phases de développement et de test

La fiche « Sécurité : encadrer les développements informatiques » range l'usage de données réelles en phase de développement et de test dans la rubrique « ce qu'il ne faut pas faire ». La règle de base tient en deux points : réaliser les développements et les tests dans un environnement informatique distinct de la production, et travailler sur des données fictives ou anonymisées.

Cette règle admet une exception, mais elle est encadrée. Lorsque les tests sur données fictives ou anonymisées ne suffisent pas à s'assurer du bon fonctionnement d'un nouveau service, il devient possible de tester en préproduction avec des données réelles, à deux conditions cumulatives : l'environnement de préproduction doit être configuré et sécurisé au même niveau que la production elle-même, et la fonctionnalité doit avoir déjà passé l'ensemble des tests unitaires, d'intégration et fonctionnels dans les environnements de développement et de test.

Autrement dit, la donnée réelle n'est pas un point de départ commode, c'est un dernier recours qui coûte plus cher que le jeu fictif, puisqu'il oblige à hisser l'environnement de test au niveau de la production.

Quatre niveaux de jeux de données, du plus sûr au plus risqué

  1. Données entièrement fictives. Générées par un script, sans lien avec vos clients. C'est le niveau par défaut d'un prototype et il convient à la grande majorité des écrans, des formulaires et des parcours.
  2. Données synthétiques. Fictives elles aussi, mais calquées sur les distributions réelles : proportion de dossiers incomplets, saisonnalité des commandes, longueur des libellés. Le bon niveau dès que le prototype doit démontrer un comportement de volume.
  3. Données anonymisées. Issues de vos données réelles, mais transformées de manière irréversible. Attention au piège classique : remplacer un nom par un identifiant ne relève pas de l'anonymisation mais de la pseudonymisation. Si le recoupement d'un code postal, d'une date et d'un montant permet de retrouver la personne, le RGPD continue de s'appliquer pleinement.
  4. Données réelles en préproduction. Le dernier recours décrit plus haut, réservé aux cas où le comportement dépend vraiment de la donnée d'origine (reprise d'historique, calculs réglementaires, rapprochement comptable).

Un bon jeu de test ne se juge pas à sa taille

L'erreur symétrique de la copie de production consiste à créer trente lignes trop propres, qui ne cassent rien. Un prototype instruit une décision d'investissement : il doit rencontrer les cas qui font échouer les projets, pas seulement le parcours idéal de la démonstration.

Un jeu de test utile contient donc, volontairement, des irrégularités que vous connaissez : noms composés et particules, accents et apostrophes, adresses étrangères, numéros de téléphone au mauvais format, doublons partiels, champs obligatoires vides, dates incohérentes, montants négatifs, remises exceptionnelles, clients rattachés à deux entités. Quarante enregistrements construits sur cette logique révèlent davantage de défauts qu'un extrait de deux cent mille lignes tiré au hasard.

Deuxième réflexe utile : le jeu de données se versionne avec le projet, comme le code, et se rejoue à l'identique après chaque modification.

Les décisions à prendre pendant le prototype, pas après

  • Les profils et les droits d'accès doivent être intégrés dès les phases de développement. Un prototype où tout le monde voit tout produit un modèle de données qui ne sait pas cloisonner.
  • Les zones de texte libre et de commentaires sont à éviter : elles collectent des informations non nécessaires et souvent sensibles, et elles sont ensuite impossibles à trier.
  • Les formats de saisie doivent minimiser la collecte. Si vous n'avez besoin que de l'année de naissance, le formulaire ne doit pas permettre de saisir le jour et le mois.
  • Les secrets (clés d'interface, jetons, mots de passe techniques) ne doivent jamais partir dans le dépôt de code, et doivent être changés au passage en production.
  • La durée de vie du prototype se fixe au départ : date d'extinction, suppression des comptes de test, suppression des jeux de données et des exports générés pendant les démonstrations.

Le coût réel de la bonne pratique

Un générateur de données fictives passe souvent pour un luxe de projet mature. C'est l'inverse : le script se construit une fois, se réexécute en quelques secondes, permet de remettre le prototype à zéro avant chaque démonstration et évite de dépendre d'un export de production que quelqu'un doit préparer puis nettoyer.

La copie de production engendre au contraire un coût récurrent invisible : une opération manuelle à chaque rafraîchissement, une dépendance à une personne et un risque juridique porté par le dirigeant. Sur nos projets de prototypage rapide, la génération du jeu de données fait partie de la première semaine, au même titre que le modèle de données.

Cinq erreurs fréquentes

  • Considérer que le prototype est trop court pour mériter des précautions, alors qu'il survit souvent six mois.
  • Confondre anonymisation et pseudonymisation, et croire le sujet réglé parce que les noms ont été remplacés.
  • Héberger le prototype chez un outil choisi dans l'urgence, sans savoir où les données sont stockées.
  • Bâtir un jeu de test trop propre, qui valide une démonstration mais ne prépare aucune décision.
  • Oublier de supprimer le prototype, ses comptes et ses exports une fois l'application en service.

Questions fréquentes

Peut-on utiliser des données clients réelles dans un prototype ?

La CNIL recommande de ne pas utiliser de données personnelles réelles pour les phases de développement et de test, et de recourir à des jeux fictifs autant que possible. Lorsque les données fictives ne suffisent pas, il reste possible de tester en préproduction avec des données réelles, à condition que cet environnement soit sécurisé au même niveau que la production et que les tests unitaires, d'intégration et fonctionnels aient déjà été passés.

Quelle différence entre données anonymisées et pseudonymisées ?

Une donnée anonymisée ne permet plus de réidentifier la personne, y compris par recoupement, et sort du champ du RGPD. Une donnée pseudonymisée remplace un identifiant direct par un code, mais la réidentification reste possible : elle demeure une donnée personnelle soumise au RGPD.

Combien d'enregistrements faut-il dans un jeu de test ?

Il n'existe pas de nombre idéal. Quelques dizaines d'enregistrements bien choisis, couvrant les cas limites de votre métier, sont plus utiles qu'un extrait massif de production. On ajoute un volume synthétique plus important uniquement lorsque le prototype doit démontrer une performance ou un comportement de masse.

Que faire des données du prototype une fois le projet lancé ?

Elles se suppriment, avec les comptes de test, les exports produits pendant les démonstrations et les sauvegardes de l'environnement. Cette étape se planifie dès le lancement du prototype, sinon elle est oubliée. Les secrets techniques utilisés pendant la phase de test doivent également être renouvelés.

Parlons de votre projet

Vous préparez un prototype ou une application métier et vous vous demandez quelles données y faire circuler, ou comment construire un jeu de test représentatif ? Nous cadrons ce point dès le premier atelier, avant la première ligne de code. Parlons de votre projet.