Einen Fake JSON-Datensatz erstellen

À quoi servent des données factices ?

Le besoin revient à toutes les étapes du cycle de développement. Pour une démo, on a besoin d'utilisateurs plausibles, pas de Lorem Ipsum tronqué. Pour des tests d'intégration, on veut un jeu de données reproductible mais varié. Pour un environnement de pré-production isolé du RGPD, on remplace les données réelles par des équivalents factices. Pour une maquette UI, il faut peupler des tableaux avec des entrées crédibles. Le générateur de données factices couvre ces cas en produisant des enregistrements JSON conformes à un schéma simple.

Le format du schéma

Le schéma est un objet JSON où chaque clé est le nom du champ produit et la valeur est un type Faker. Par exemple :

{
  "name": "name",
  "email": "email",
  "age": "number 18-65",
  "active": "boolean",
  "registered_on": "date"
}

L'outil génère ensuite N enregistrements respectant ce schéma, dans la locale choisie (français ou anglais). Le résultat est un tableau JSON utilisable directement comme fixture, comme corps d'une requête d'API, ou comme input d'un seeder de base de données.

Types supportés

• name : nom complet (« Marie Dupont »).
• firstName / lastName : prénom et nom séparés.
• email : adresse mail factice (utilise safeEmail de Faker, qui produit des domaines réservés example.com non joignables).
• phone : numéro de téléphone formaté à la locale.
• address : adresse postale complète.
• number : entier aléatoire entre 0 et 1000 par défaut, ou number a-b pour une plage personnalisée.
• boolean : true ou false aléatoire.
• date : date au format ISO 8601 (YYYY-MM-DD).
• uuid : UUID v4.
• text : court paragraphe lorem-ipsumesque (~120 caractères).
• string : trois mots aléatoires.
• url : URL factice (https://example.org/...).

Tout type non reconnu est conservé tel quel dans le résultat. C'est un choix : si vous mettez "role": "admin" dans le schéma, chaque enregistrement aura "role": "admin". Cela permet de mélanger valeurs constantes et champs dynamiques sans changer d'outil.

Choix de la locale

Faker dispose de dizaines de locales. L'outil expose les deux les plus utiles dans un contexte francophone :

• fr_FR : noms français, adresses françaises, numéros de téléphone format français, phrases lorem-ipsum en français approximatif.
• en_US : noms et adresses américains, numéros de téléphone format US.

Pour une cohérence de démonstration côté français, choisissez fr_FR. Pour un test d'internationalisation, mélangez les deux exécutions ou augmentez le nombre de records pour disposer d'une variété d'origines.

Cas d'usage

• Fixtures de tests : générer 50 utilisateurs, les coller dans un fichier YAML d'AliceBundle ou un seeder. Reproductible quand on fixe un seed Faker, varié sinon.
• Maquettes UI : remplir un tableau React/Vue avec des données plausibles. Beaucoup plus parlant qu'un tableau vide ou que foo / bar / baz.
• Charge de test : générer un payload JSON volumineux pour un test de débit (k6, JMeter, Locust).
• Démos commerciales : peupler une instance de démonstration avec des entrées qui ressemblent à des cas réels mais ne risquent pas de fuiter de l'information sensible.
• Anonymisation : remplacer un export de production par un équivalent factice avant de le partager avec un sous-traitant ou de l'utiliser en pré-production.

Limites volontaires

Pour rester simple à utiliser, l'outil ne supporte pas les schémas imbriqués (un champ qui serait lui-même un objet ou un tableau d'objets). Pour de tels besoins, il vaut mieux écrire un script Faker dédié, ou composer plusieurs appels successifs. La limite volontaire évite aussi des combinaisons absurdes ("items": "name" avec une cardinalité aléatoire) qui rendraient l'outil moins prévisible.

Le nombre d'enregistrements est plafonné à 500. Au-delà, on attend d'un environnement de test qu'il génère ses fixtures via du code dédié (Faker en CLI, Foundry, factory_bot, etc.). L'outil web est utile jusqu'à quelques centaines de records ; au-delà, la mémoire et le temps de réponse plafonnent l'expérience.

Reproductibilité et sécurité

Les valeurs sont produites avec un PRNG non déterministe : chaque exécution produit des données différentes. Pour des tests qui doivent être reproductibles (CI), capturez la sortie une fois et committez-la. Pour des données vraiment sensibles (anonymisation de production), gardez à l'esprit que la génération côté serveur public n'est pas le bon canal : préférez un script local qui ne quitte jamais votre poste.

Questions fréquentes

Beispielanfrage

curl -X POST https://cdrn.fr/api/v1/tools/mock-data-generator/execute \
  -H "Content-Type: application/json" \
  -d '{"schema":"{\"name\": \"name\", \"email\": \"email\", \"age\": \"number 18-65\"}","count":5,"locale":"fr_FR"}'

Eingabeschema

Endpunkte

• GET https://cdrn.fr/api/v1/tools - listet alle verfügbaren Tools auf
• GET https://cdrn.fr/api/v1/tools/mock-data-generator - liefert das Schema dieses Tools
• POST https://cdrn.fr/api/v1/tools/mock-data-generator/execute - führt dieses Tool mit einem JSON-Payload aus