Générez des données personnelles d'exemple pour vos tests.
Les résultats sont fournis à titre informatif. Vérifiez-les auprès d'autres sources.
Les données de test les plus dangereuses sont les données bien rangées
Des enregistrements générés permettent de remplir une base, de charger un point d'entrée ou de construire un écran avant qu'aucun utilisateur réel n'existe — sans copier des données de production sur un portable. Mais un générateur qui ne produit que des noms ASCII propres et des codes postaux bien formés laissera volontiers partir en production un champ qui casse sur O'Brien.
Comment ça marche
- Produit en masse des noms, courriels, adresses, numéros de téléphone, dates et identifiants d'apparence réaliste.
- Exporte en JSON ou CSV, pour injecter la sortie directement dans une base ou un fichier de fixtures.
- Génère des volumes assez grands pour révéler des problèmes de pagination, d'index et de rendu que dix lignes ne montreront jamais.
utiliser des données générées quand il faut du volume — des milliers de lignes pour tester pagination et plans de requête de la sûreté — aucune donnée personnelle réelle sur une machine de dev de la répétabilité — la même graine donne le même jeu à chaque exécution réaliste ≠ bien rangé : les vraies données ont des apostrophes, des accents et des champs vides
Exemple chiffré
Alimenter une table d'utilisateurs avant que le produit n'en ait.
- générer 5 000 lignes plutôt que 10 — pagination et requêtes lentes n'apparaissent qu'en volume
- inclure des noms qui cassent le code naïf : O'Brien, Łukasz, José, 名字
- inclure un courriel avec un tag plus et un à la limite de 254 caractères
- laisser certains champs facultatifs réellement vides au lieu de remplir chaque colonne
- fixer la graine pour qu'un test en échec se reproduise à l'identique
Un jeu de données qui exerce les cas gênants sur votre machine au lieu de les découvrir chez un client. La seule apostrophe attrape du SQL non échappé, un export CSV cassé et un affichage déformé en une seule ligne.
Lire le résultat
- N'alimentez jamais avec une copie de la production. Au-delà de l'exposition juridique au RGPD, de vrais enregistrements fuient sur des portables, dans des sauvegardes et via des partages d'écran, et rien ne permet ensuite de les rappeler.
- Données générées n'est pas synonyme de données anonymisées. Si vous dérivez des lignes de vraies par brassage ou masquage, la ré-identification reste souvent possible ; des enregistrements synthétiques créés à partir de rien ne portent pas ce risque.
- Fixez la graine quand des tests dépendent de la sortie. Un aléa non ensemencé produit des suites qui échouent une fois par semaine et passent au réessai, ce qui apprend aux gens à ignorer les échecs.
- Restez sur des domaines manifestement fictifs — example.com est réservé exactement à cela — pour qu'une tâche mal configurée ne puisse pas écrire à une vraie adresse.
Questions fréquentes
- Combien de lignes générer ?
- Assez pour casser quelque chose. Dix lignes prouvent qu'un écran s'affiche ; quelques milliers révèlent les index manquants, les requêtes non bornées et la pagination qui s'effondre à la dernière page. Visez l'ordre de grandeur de la production si vous le pouvez.
- Puis-je m'en servir pour des tests de charge ?
- Oui, et c'est l'un des meilleurs usages — mais variez les valeurs. Dix mille requêtes identiques mesurent votre cache, pas votre système ; des enregistrements distincts empruntent les chemins qu'une charge réelle prend vraiment.