Données de test : arrêtez de copier la production

Votre intégrateur demande une copie de la base clients pour terminer ses tests. Avant de lui fournir un export, exigez les scénarios à reproduire et préparez un jeu qui ne transporte pas toute la vie de l’entreprise.

Je déconseille de traiter cette demande comme une simple opération de sauvegarde. Le coût se déplace vers les accès à surveiller, les copies à retrouver et les données à supprimer. Faites chiffrer la préparation du jeu de test dans la prestation, avec un responsable nommé.

Exigez les cas à tester avant de fournir des données

Demandez au prestataire ce qui manque exactement : des commandes partielles, des caractères accentués, des pièces jointes volumineuses, un historique de changements de statut ? Une réponse limitée à la nécessité d’avoir une base réaliste ne suffit pas. Chaque besoin doit correspondre à un test et à un résultat attendu.

La CNIL recommande des données fictives pour tester les applications. Traduisez ce principe dans votre commande : le prestataire décrit les cas, le métier confirme leur pertinence et l’équipe prépare les données nécessaires. Ne laissez pas le développeur choisir seul ce qui représente le travail des utilisateurs.

Demandez aussi ce que le test cherche à mesurer. Vérifier un calcul exige des valeurs connues. Mesurer un temps de réponse exige un volume et une distribution représentatifs. Une copie complète peut contenir beaucoup de données sans reproduire la condition qui déclenche le défaut.

Pour la validation fonctionnelle, rattachez chaque cas à votre recette métier. Vous pourrez alors refuser un export inutile sans bloquer la vérification attendue.

Construisez un petit jeu cohérent et réutilisable

Commencez avec des dossiers entièrement inventés, dont vous connaissez le résultat. Pour une facturation, prévoyez par exemple une commande livrée, une livraison partielle, un avoir et une annulation. Ce sont des cas de travail à adapter, pas un catalogue universel.

Conservez les relations entre objets : client, commande, lignes et règlement. Un générateur qui remplit chaque table séparément peut produire une base pleine mais inutilisable. Demandez au prestataire de livrer le script de création du jeu avec les résultats attendus. Exécutez-le dans un environnement vide avant de l’accepter.

Ajoutez les cas qui cassent les habitudes : champ vide autorisé, libellé long, doublon attendu, date à la limite d’une période. Pour la charge, multipliez les dossiers fictifs selon les caractéristiques observées dans votre application, sans recopier les identités.

Bon plan : conservez le jeu fictif et son script de remise à zéro avec les tests. Chaque défaut corrigé enrichit ce jeu d’un cas reproductible. Vous payez une préparation réutilisable, au lieu de réclamer un nouvel export à chaque livraison.

Ne confondez pas noms remplacés et base anonyme

Remplacer un nom par un identifiant ne suffit pas. La CNIL distingue anonymisation et pseudonymisation : des données pseudonymisées restent des données personnelles. Évitez donc de qualifier un export d’anonyme sur la seule parole de son script de masquage.

Demandez ce qui reste dans les commentaires, les documents joints, les noms de fichiers et les historiques. Une signature dans un PDF peut rendre inutile le remplacement du nom dans la fiche client. Un poste rare associé à un établissement peut aussi révéler une identité.

Pour chaque famille de champs, faites choisir une règle explicite : supprimer, remplacer par une valeur fictive ou conserver avec justification. Préservez les relations nécessaires aux essais sans conserver inutilement les caractéristiques des personnes. Faites examiner le résultat par une personne compétente en protection des données.

Une base dont l’anonymisation n’est pas démontrée doit rester protégée comme une base contenant des données personnelles.

Coupez les connexions réelles avant le premier démarrage

Une base nettoyée peut encore porter des paramètres de production. Avant de lancer l’application, demandez la liste des services qu’elle contacte : messagerie, SMS, paiement, stockage documentaire, interfaces métier. Contrôlez aussi les tâches planifiées et les traitements en attente.

Mon conseil : bloquez d’abord les sorties réseau, puis ouvrez uniquement les destinations de test nécessaires. Le bouton qui désactive les notifications dans l’application ne couvre pas forcément un traitement indépendant. Vérifiez le résultat avec l’équipe réseau et les responsables applicatifs.

Remplacez les secrets par ceux des environnements de test. Dirigez les messages vers une boîte de capture interne et les appels vers les interfaces de simulation disponibles. Pour chaque connexion autorisée, notez la destination, le compte utilisé et la preuve qu’aucune action réelle ne sera exécutée.

Lancez ensuite un parcours complet et examinez ses traces. Une facture fictive générée correctement ne valide pas le test si elle part chez un client réel. Conservez cette vérification dans la procédure de réinitialisation : elle doit survivre au prochain rafraîchissement de l’environnement.

Faites payer et encadrer toute exception de préproduction

Un défaut peut résister aux données fictives. Commencez par chercher le plus petit cas qui le reproduit. Demandez les champs et les relations indispensables, puis tentez une reproduction avec des valeurs inventées avant d’élargir l’accès.

La fiche de la CNIL sur les développements informatiques envisage des données réelles en préproduction lorsque les tests précédents ne suffisent pas. Elle exige alors une configuration et une sécurité au niveau de la production, après les tests en développement et en test. Ce passage ne constitue pas une autorisation générale de distribuer des copies.

Faites examiner l’exception avec le DPO, la sécurité et le responsable de l’application. Documentez le besoin, les données retenues, les intervenants, le lieu de traitement et l’échéance. Refusez une copie sur un poste de prestataire dont les protections restent inconnues.

Demandez un chiffrage séparé pour la préparation, l’environnement protégé et la suppression. Incluez les exports intermédiaires, les journaux et les sauvegardes dans le périmètre à traiter. Si certaines copies suivent un cycle de purge différé, faites préciser ce cycle et leurs restrictions d’accès. Une suppression de la base active ne clôt pas le dossier.

Fermez une copie oubliée cette semaine

Choisissez une application en cours de maintenance et réunissez son responsable avec le prestataire. Utilisez cette checklist :

• Recensez les copies existantes, leur emplacement et leur responsable.
• Identifiez les données personnelles présentes, y compris dans les fichiers joints.
• Demandez les scénarios qui justifient chaque jeu conservé.
• Préparez un premier jeu fictif avec ses résultats attendus.
• Vérifiez les destinations réseau, les secrets et les traitements automatiques.
• Fixez la suppression des copies inutiles et la preuve attendue.

Inscrivez enfin dans la prochaine commande la livraison du jeu fictif, de son script et de sa procédure de nettoyage. Si le prestataire réclame encore toute la production, demandez-lui de nommer le test impossible à réaliser autrement.