Générateur de données fictives

Mode d’emploi

1. La page s’ouvre avec dix lignes de CSV déjà créées — la ligne d’en-tête est incluse, le texte peut donc aller directement dans une fixture, un tableur ou un import de base de données.
2. Réglez le nombre de lignes (1–200), choisissez CSV, JSON ou SQL, et cochez les champs utiles. Tout est reconstruit à chaque changement ; changer de format resérialise les mêmes lignes au lieu d’en générer de nouvelles.
3. Choisissez la langue des données — anglais, 简体中文 ou العربية — indépendamment de la langue de l’interface. Les noms, entreprises et couples ville/pays suivent ce choix, tandis que les clés de champs, les dates ISO et la syntaxe SQL restent fixes.
4. Ajoutez une graine quand les mêmes données doivent survivre à une nouvelle exécution : même graine, mêmes lignes, mêmes champs et même langue donnent toujours le même lot. Copiez ou téléchargez quand le résultat convient — rien n’est envoyé, enregistré ni placé dans l’URL.

Règles, limites et problèmes connus

• Chaque valeur est fictive. Les noms, entreprises et villes viennent de petites listes écrites à la main ; toute ressemblance avec des personnes ou organisations réelles est fortuite.
• Les e-mails utilisent les domaines réservés example.com, example.net et example.org (RFC 2606) : ils sont uniques dans un lot mais ne peuvent jamais recevoir de courrier, et un nouveau lot peut répéter une adresse.
• Les numéros de téléphone sont des exemples de format, pas des numéros attribués. Les valeurs nord-américaines se situent dans la plage fictive 555-0100–0199 ; les valeurs chinoises et arabes utilisent des blocs complétés par des zéros. Le motif suit uniquement la langue des données, pas la ville ni le pays de la même ligne. Certains pays n’ont pas de plage réservée, un numéro généré peut donc exister — ne l’appelez pas et n’envoyez pas de SMS.
• Les localisations se limitent à une ville et un pays : pas de rue, de code postal ni de coordonnées. La ville et le pays d’une même ligne viennent toujours du même couple, mais ce n’est pas une adresse livrable.
• Le CSV a toujours une ligne d’en-tête, des fins de ligne LF et aucun BOM. Les anciennes versions d’Excel peuvent mal afficher un CSV non ASCII au double-clic ; importez-le en UTF-8, ou utilisez JSON.
• La syntaxe lisible par machine ne suit jamais la langue de l’interface : les clés de champs (id, name, email…), les dates ISO, les décimales à point et le nom de table SQL fake_data restent identiques dans toutes les langues, la sortie peut donc être importée directement.
• Il n’y a que dix champs fixes. Les noms de champs personnalisés, types, taux de vide, réordonnancement, clés étrangères et contraintes d’unicité ne sont pas pris en charge ; les noms et téléphones peuvent se répéter, seuls les e-mails sont dédupliqués dans un lot.
• L’aléa n’est pas sécurisé : les graines utilisent un hachage non cryptographique avec mulberry32, et les UUID n’ont que la forme v4. Ne les utilisez pas pour des mots de passe, des jetons, des clés ou tout ce qui doit être imprévisible.
• La reproductibilité exige l’ensemble complet des réglages : même graine, même nombre de lignes, mêmes champs et même langue des données. Le format ne participe pas au tirage aléatoire, vous pouvez donc passer librement de CSV à JSON et SQL.
• La limite est de 200 lignes par génération, choisie pour que le résultat tienne dans un panneau de hauteur fixe et se mette à jour instantanément. Les jeux plus grands nécessitent plusieurs lots ou un script.
• Il n’y a ni historique, ni annulation, ni enregistrement. Recharger abandonne tout ; la graine est le seul moyen de revenir. Rien n’est envoyé, stocké dans localStorage ni écrit dans l’URL.