Données synthétiques pour les tests et l'assurance qualité : production de masse réaliste sans copie

Demandez à n’importe quelle équipe d’ingénierie d’où provient la masse de données dans l’environnement d’approbation. Dans de nombreuses entreprises, la réponse honnête est : à partir d’une copie de production. Quelqu'un, à un moment donné, a reproduit la base réelle d'un environnement de test, car c'était le moyen le plus rapide de lui donner une apparence réelle. Et cette copie est restée là, utilisée et copiée à nouveau, semestre après semestre.

Cette habitude résout un problème et en crée un plus grave. Cela résout le réalisme, car les données de production sont, par définition, réalistes. Mais cela crée un énorme risque pour la vie privée, car les données personnelles de vrais clients circulent désormais dans des environnements moins protégés, accessibles à davantage de personnes, en plus de copies, avec moins de contrôle. C'est l'un des risques les plus courants et les plus sous-estimés auxquels je suis confronté.

Les données synthétiques résolvent cette équation de manière propre : vous générez une masse qui se comporte comme une production, sans qu’elle ne contienne un seul client réel.

Pourquoi copier la production est un problème

Il vaut la peine de nommer les risques, car ils sont généralement traités comme un coût invisible jusqu’au jour où ils deviennent un incident.

Le risque pour la vie privée est le plus évident. En vertu de la LGPD, les données personnelles dans un environnement d'approbation sont des données personnelles soumises aux mêmes obligations. Chaque développeur ayant accès, chaque sauvegarde de cet environnement, chaque intégration de test qui touche cette base, tout cela est une surface d'exposition. Une fuite lors de l’approbation fait autant mal qu’une fuite pendant la production, avec l’avantage supplémentaire que personne n’y prêtait attention.

Le risque de sécurité vient avec. Les environnements de test ont souvent des contrôles plus souples, des informations d'identification partagées et moins de surveillance. Mettre des données réelles dans ce contexte, c'est garder quelque chose de précieux dans la pièce avec la porte déverrouillée.

Il existe également un risque opérationnel. La copie de production contient ce que la production possède, et la production a rarement le cas extrême que vous devez tester. Vous vous retrouvez avec une base vaste, sensible et pourtant incomplète pour les scénarios les plus importants.

Ce que la masse synthétique apporte

Générer des données de test au lieu de les copier change la donne dans plusieurs dimensions.

Le premier est la sécurité par construction. Si les données ne proviennent jamais d’une personne réelle, aucune donnée personnelle ne peut être divulguée. L'environnement d'approbation cesse d'être un référentiel de risques et devient ce qu'il devrait être, un espace pour exercer le logiciel. C’est l’angle de la vie privée que j’aborde dans données synthétiques et vie privée.

La seconde est le contrôle des scénarios. Avec la masse synthétique, vous générez volontairement ce dont vous avez besoin pour tester : le client avec un nom énorme qui casse la mise en page, la valeur négative, la date invalide, la commande avec mille articles, l'utilisateur sans historique. Ces cas extrêmes sont ceux où vivent les bugs, et la production les distribue rarement sur un plateau.

Le troisième est le volume à la demande. Besoin de dix millions d’enregistrements pour un test de charge ? Générer. Avez-vous besoin d’une base légère pour exécuter rapidement la suite en cours de développement ? Générez plus petit. Vous arrêtez de dépendre de la taille de la production et commencez à définir la taille requise par le test.

Le quatrième est la stabilité. Les données de production changent tout le temps, ce qui rend les tests fragiles et difficiles à reproduire. La masse synthétique générée à partir de règles connues est déterministe lorsque vous le souhaitez, ce qui donne des tests qui échouent pour la bonne raison, et non parce qu'un dé a changé en dessous d'eux.

Le réalisme est l'exigence incontournable

La masse synthétique n’est utile que si elle exerce les mêmes chemins de code que les données réelles exerceraient. Des données synthétiques naïves, que tout le monde appelle "Test Test" avec le même CPF invalide, ne testent presque rien. Il passe par des validations selon lesquelles les données réelles échoueraient et masque les bogues qui n'apparaissent qu'avec variété.

Le réalisme, ici, signifie respecter la structure et les règles du domaine. CPF qui réussit la validation des chiffres. code postal qui existe. Dates cohérentes entre elles, avec inscription avant le premier achat. Des distributions réalistes, avec la bonne combinaison de clients actifs et inactifs, de grosses et petites commandes, de cas courants et rares. Des relations durables, la commande pointant vers le client existant et le produit existant.

Plus votre système dépend de ces règles, plus la foule doit les respecter pour que le test soit valide. Pour l’assurance qualité, le niveau de fidélité requis dépend souvent davantage de la structure et des règles que de la reproduction d’une distribution statistique fine. Vous avez besoin que les données soient valides et variées, et non pour reproduire le comportement agrégé de la base de données avec une précision scientifique.

Comment adopter sans devenir un projet éternel

La tentation est de considérer la génération de données synthétiques comme une grande plateforme. Pour l’assurance qualité, je recommande la voie inverse : commencer petit et prouver rapidement la valeur.

Choisissez un système clair, de préférence un système qui repose actuellement sur la copie de production et qui génère l'essentiel du flux principal. Ressentir le gain dans un cas réel est plus convaincant que n’importe quelle planification à long terme.

Modélisez les règles du domaine avec ceux qui connaissent le métier. La qualité de masse vient d'une bonne capture des contraintes de données, c'est donc dans cette conversation entre l'assurance qualité, le développement et l'entreprise que réside la valeur.

Générateurs de versions sous forme de code. La recette qui produit la pâte fait partie du projet, elle doit être revue, testée et évoluée comme tout autre composant. Cela relie la stratégie de données à la stratégie de test, un sujet que j'aborde dans tests automatisés.

Incluez volontairement les cas extrêmes. Le véritable avantage de la masse synthétique par rapport à la copie de production est de pouvoir générer le scénario difficile. Ne gaspillez pas cela en reproduisant simplement le cas heureux.

Intégrer dans le pipeline. Le volume généré à la demande dans le flux d’intégration continue est ce qui rend les tests reproductibles et peu coûteux à exécuter. Les données de test qui se trouvent dans une base de données statique partagée deviennent obsolètes et perturbatrices.

Le gain que voit le leader

Pour ceux qui décident, l’argument est simple. L'échange d'une copie de production contre une copie de masse synthétique supprime l'un des plus grands risques de confidentialité de l'entreprise, réduit la surface de sécurité des environnements de test et, en même temps, accélère le contrôle qualité, car l'équipe commence à générer le scénario dont elle a besoin au lieu de le rechercher dans une base de données qui ne l'a peut-être même pas.

C'est l'un des rares cas où sécurité et rapidité vont de pair. En général, plus de contrôle se fait au prix d’une plus grande lenteur. Ici, en arrêtant de transporter des données réelles partout, vous devenez à la fois plus sûr et plus agile.

Il s’agit de l’utilisation de données synthétiques offrant le rendement le plus rapide et le risque le plus faible à adopter. La fidélité requise est gérable, le gain en intimité est immédiat et l'impact sur le quotidien de l'équipe apparaît dès les premières semaines.