Ajoutez au moins un champ
Toutes les données générées sont fictives ; toute ressemblance avec une personne, une adresse ou un compte réel est fortuite. Les cartes sont des numéros de test qui passent la formule de Luhn et ne permettent aucun paiement.
Génère des adresses postales fictives cohérentes : rue, ville, département ou région et un code postal qui appartient bien à la ville, dans l’ordre local. Les codes français ont cinq chiffres, les CEP brésiliens huit, les codes japonais sept et les index russes six. Pratique pour tester des formulaires de commande et la validation d’adresses.
Mode d’emploi
- Partez d’un modèle (Personnes, Noms, Adresses, Comptes, Paiements, Entreprises) ou composez votre propre liste de champs.
- Changez le type de chaque champ dans son menu et le nom de la colonne à côté. Les nombres et les dates ont un min/max ou une plage ; faites glisser la poignée pour réordonner.
- Réglez le nombre de lignes (jusqu’à 10 000), le pays des données et la graine.
- Choisissez JSON, CSV, SQL, XML ou YAML. Passez en Tableau pour vérifier les valeurs ; touchez une cellule pour la copier.
- Copiez ou téléchargez le résultat complet. Nouvelles données (ou R) tire une autre graine.
- La même graine, avec les mêmes champs, pays et nombre de lignes, donne toujours exactement le même résultat : vous pouvez recréer un jeu de données plus tard ou le partager avec un collègue. Les champs et réglages sont gardés dans ce navigateur.
- Chaque ligne est cohérente : l’e-mail et l’identifiant viennent du nom, l’indicatif téléphonique et le code postal correspondent à la ville. Les e-mails utilisent les domaines réservés example.com, example.net et example.org et n’atteignent donc aucune vraie boîte.
- Les téléphones et codes postaux suivent le format de chaque pays : en France, mobiles 06/07 et fixes avec l’indicatif régional (01 pour Paris), codes postaux du bon département (75001 à 75020 pour Paris).
- Les cartes utilisent les préfixes de test acceptés par les environnements de test comme celui de Stripe et passent la formule de Luhn. Les IBAN ont des clés de contrôle valides (et une clé RIB valide pour la France, ainsi que les clés nationales espagnoles et portugaises). Le Japon et la Russie n’utilisent pas l’IBAN : ces lignes reçoivent un IBAN allemand sauf si vous choisissez un pays.
- Les gros volumes sont générés par petits morceaux pour que la page reste fluide. La vue code affiche les 60 premières lignes et le tableau les 100 premières ; Copier et Télécharger incluent toutes les lignes. Le CSV est enregistré avec un BOM pour qu’Excel affiche bien les accents.
- Tout est généré dans votre navigateur. Rien n’est envoyé.
Réalistes mais sans risque
Chaque ligne se tient : l’e-mail et l’identifiant viennent du nom de la ligne, l’indicatif téléphonique et le code postal correspondent à la ville. Les formats suivent chaque pays : codes postaux français à cinq chiffres, CEP brésiliens comme 01310-100, codes japonais comme 100-0001. Les e-mails utilisent les domaines réservés example.com, example.net et example.org (RFC 2606) : un test n’écrira jamais à une vraie personne.
Les numéros de carte commencent par des préfixes de test acceptés par les bacs à sable de paiement et passent la clé de Luhn ; les IBAN ont des chiffres de contrôle valides selon ISO 13616, avec aussi la clé RIB française correcte. Ils passent donc la validation des formulaires sans appartenir à personne.
Reproductibles grâce à une graine
La génération repose sur un générateur aléatoire à graine. Même graine, mêmes champs, même pays et même nombre de lignes donnent toujours le même résultat : notez la graine dans un test, reconstruisez un jeu de données après avoir changé son format, ou envoyez une graine à un collègue au lieu d’un fichier. Nouvelles données ou R tire une nouvelle graine.
Quel format choisir
Le JSON convient aux maquettes d’API et aux prototypes front-end, le CSV s’ouvre dans Excel ou Google Sheets (enregistré avec un BOM UTF-8 pour bien afficher les accents), le SQL fournit des INSERT et un CREATE TABLE facultatif pour MySQL, PostgreSQL, SQLite ou SQL Server, et le XML et le YAML servent aux suites de tests pilotées par configuration. Les gros jeux sont construits par étapes pour que la page reste fluide.
Questions fréquentes
Les données générées sont-elles réelles ?
Non. Noms et rues sont combinés au hasard à partir de listes, les e-mails pointent vers des domaines d’exemple réservés et les numéros de téléphone utilisent des plages fictives quand le pays en prévoit. Toute ressemblance avec une vraie personne est fortuite.
Puis-je payer avec les numéros de carte ?
Non. Ils passent la clé de Luhn et utilisent des préfixes de test : ils fonctionnent en mode test chez les prestataires de paiement, mais ne sont liés à aucun compte et sont refusés pour un vrai paiement.
Comment retrouver les mêmes données ?
Gardez la graine. Avec la même graine, les mêmes champs, le même pays et le même nombre de lignes, le générateur produit exactement le même résultat sur n’importe quel appareil.
Combien de lignes puis-je générer ?
Jusqu’à 10 000 par génération. L’aperçu n’affiche que les premières pour rester rapide, mais Copier et Télécharger incluent toujours toutes les lignes.
Quels pays sont pris en charge ?
États-Unis, Espagne, Brésil, France, Allemagne, Japon, Russie et Corée du Sud, plus une option mixte. Noms, adresses, téléphones et codes postaux suivent le format de chaque pays.
Est-ce adapté à des tests conformes au RGPD ?
Utiliser des données synthétiques plutôt que des copies de la production est une façon courante de garder les données personnelles hors des environnements de test. Tout est généré dans votre navigateur, rien n’est envoyé.