Données de test pour un logiciel métier : travailler sans copier les données réelles

Un jeu de données de test doit reproduire les cas utiles sans exposer les informations personnelles ou commerciales de l’environnement réel.

Copier la production semble pratique, mais un fichier de test peut circuler vers un outil de développement ou un prestataire. Les données doivent être synthétiques ou transformées selon une procédure contrôlée, avec une vérification du résultat.

Définir les scénarios

Listez les cas à couvrir : dossier incomplet, montant limite, rôle différent, historique long et relation absente. Créez des valeurs qui permettent de distinguer les lignes et les entreprises. Des données trop uniformes cachent les erreurs de tri et d’isolation.

Transformer les champs sensibles

Remplacez les noms, adresses, téléphones, e-mails et identifiants selon une règle qui conserve les relations nécessaires. Un même client fictif doit garder la même référence dans les commandes associées. Les secrets, jetons et fichiers réels doivent être supprimés.

La transformation peut produire des valeurs invalides. Vérifiez les formats, les contraintes et les règles métier après anonymisation. Le logiciel SaaS multi entreprise doit continuer à séparer les espaces dans le jeu de test.

Contrôler l’accès

Limitez qui peut créer, restaurer et exporter les données de test. Marquez clairement l’environnement et désactivez les envois vers de vrais destinataires. Un test d’e-mail doit utiliser une boîte contrôlée.

Réinitialiser

Un script de réinitialisation doit recréer un état connu et supprimer les résultats sensibles. Conservez la version du jeu utilisée dans une recette afin de rendre le défaut reproductible.

Sources : CNIL, anonymisation, OWASP, données de test.

Conserver les relations utiles

Un jeu de test doit permettre de suivre un client fictif depuis la création jusqu’à la facture. Remplacez les identités tout en conservant les liens entre objets. Les références externes doivent rester distinctes afin de détecter les doublons et les erreurs d’import.

Créez plusieurs profils : compte actif, compte archivé, rôle limité, utilisateur de plusieurs espaces et dossier sans responsable. Des valeurs proches permettent de vérifier les tris, les filtres et l’isolation. Un jeu où chaque client possède une seule commande ne révèle pas les erreurs de pagination ou de total.

Protéger les fichiers

Les pièces jointes de test doivent être produites spécialement ou nettoyées avant usage. Vérifiez les métadonnées, les noms, les propriétés du document et le contenu caché. Un fichier présenté comme fictif peut conserver un auteur, une adresse ou un commentaire dans ses propriétés.

Désactivez les envois réels, les webhooks de production et les fournisseurs de paiement. Utilisez des domaines contrôlés et des clés de test. Le stockage des fichiers doit appliquer les mêmes règles de durée et d’accès que le produit.

Réinitialiser sans ambiguïté

Une procédure de remise à zéro doit supprimer les données produites par un test et recréer l’état de départ. Conservez la version du schéma, du jeu et des scripts. Un test qui fonctionne uniquement après plusieurs manipulations manuelles devient difficile à reproduire.

Mesurez la couverture des cas, pas seulement le nombre de lignes. Vérifiez les montants limites, les accents, les dates, les doublons, les droits et les erreurs de réseau. Une donnée synthétique doit pouvoir produire le même chemin d’erreur qu’un cas réel sans exposer une personne.

Vérifier la transformation

Après anonymisation, recherchez les valeurs originales dans les fichiers, les logs, les caches et les index. Testez les exports et les rapports. Une transformation est acceptable seulement si elle protège l’identité tout en conservant les propriétés nécessaires au scénario de test.