Personnes synthétiques pour tests et démos
Les logiciels ont besoin d'enregistrements ressemblant à des personnes avant d'avoir de vrais utilisateurs : formulaires, imports, environnements CRM et captures de démo. La famille People génère des données de personnes fictives et les exporte dans des formats courants afin que les fixtures soient reproductibles et sans données personnelles réelles.
Commencez par le générateur de personnes pour obtenir rapidement noms, adresses et contacts, puis choisissez un export structuré lorsqu'un outil attend un fichier.
Pourquoi les données synthétiques comptent
Réutiliser noms, e-mails ou téléphones de journaux de production dans des tickets, captures ou dépôts publics crée des risques de confidentialité et de conformité. Des enregistrements fictifs permettent d'exercer validation, tri et sérialisation sans copier des personnes vivantes. Ils restent vraisemblables : e-mails distinctifs, adresses plausibles et formes de champs proches de la production. Ils sont toutefois fictifs. Ne les présentez pas comme de vrais clients et ne les employez jamais pour fraude, usurpation ou abus de comptes.
Générateur et exports
- Générateur crée des enregistrements pour les tests interactifs.
- JSON fournit des tableaux pour API, scripts Node et mocks front-end.
- XML vise les intégrations anciennes et fixtures de type SOAP.
- CSV produit des lignes pour tableurs et répétitions d'import.
- YAML convient aux exemples de configuration et GitOps.
Préférez le format parlé par le consommateur ; convertir à la main est source d'erreurs. Les fixtures incluent souvent prénom, nom, e-mail, téléphone et éléments d'adresse. Dans les tests, vérifiez clés, types et chaînes non vides plutôt qu'un nom aléatoire précis. Pour une CI déterministe, utilisez des seeds ou des fichiers golden versionnés ; le navigateur sert surtout à l'exploration QA.
Formats et limites
JSON strict interdit les virgules finales. Les tableurs peuvent modifier encodage, zéros initiaux et formules commençant par = ; ouvrez les CSV comme texte quand nécessaire. XML exige les bons noms, imbrications et échappements. YAML dépend de l'indentation ; JSON est préférable si YAML 1.1 et 1.2 sont ambigus.
Ces données ne vérifient pas une identité, ne constituent ni preuves KYC ni PII de production. Le réalisme varie selon les langues et régions, et le navigateur convient à des lots modestes, pas à des millions de lignes de charge. Nommez clairement les fichiers sample- ou fixture-, ne les mélangez pas silencieusement à des extraits clients et diversifiez les jeux pour une QA inclusive. Ils servent à la qualité logicielle, jamais à des affirmations d'identité réelle.