Comment fonctionne réellement notre générateur de personnes — et ce qu'il continue de rater

La plupart des générateurs de faux noms tiennent en une seule fonction : tirer un nom dans une liste, tirer une ville dans une autre liste, coller les deux ensemble. Le nôtre n'est guère plus que cela non plus — mais c'est précisément dans l'écart entre « guère plus » et « une seule fonction » que se logent tous les problèmes intéressants.

Cet article documente toute la machinerie : ce qu'elle prend en compte, comment elle reste reproductible et — la section qui compte le plus — la liste, démonstration à l'appui, de ce qu'elle ne modélise pas. Tout ce qui suit a été mesuré le 18 juillet 2026 sur le code et les fichiers de données livrés, et non sur les documents de conception.

Les douze entrées

Une carte générée est une fonction pure de (locale, seed). Il n'y a pas de base de données à l'exécution. Voici tout ce qui l'alimente.

1. Pays

64 locales, chacune avec ses propres corpus de prénoms, de noms de famille, de rues, de villes, de codes postaux, d'entreprises et de numéros de téléphone. « Locale » désigne ici plutôt un pays qu'une langue : de_DE, de_AT et de_CH sont trois jeux de données distincts, et il en va de même pour fr_CH, de_CH et it_CH — même pays, trois langues, un seul plan de numérotation téléphonique commun.

L'ordre des mots dans l'adresse est propre à chaque locale, car un numéro de rue ne se place jamais deux fois de la même façon :

La version antérieure de ce code codait en dur {s}, {n} — le modèle ukrainien — pour l'ensemble des 64 locales. Chaque adresse américaine se lisait Mill Street, 192.

L'ordre du nom complet est encore une autre affaire. zh_CN, zh_TW, ja_JP et ko_KR placent le nom de famille en premier sans espace (王達仁, et non 達仁 王) ; hu_HU et vi_VN le placent en premier avec une espace (Ferenczi Bódog). Tout le reste suit l'ordre First Last.

63 locales sur 64 disposent de fichiers de rues constitués à la main. ja_JP n'en a délibérément pas : une adresse japonaise s'écrit 丁目-番-号 (îlot–parcelle–bâtiment) et non rue-plus-numéro, et inventer une couche « rue » pour le Japon reviendrait à inventer un système que le pays n'a pas.

2. Sexe

Les prénoms et les noms de famille sont tirés de corpus propres à chaque sexe, mais la raison pour laquelle les corpus diffèrent se répartit en trois cas :

Le troisième groupe est celui qui met en échec les validateurs naïfs. La tradition sikhe attribue Singh surtout aux hommes et Kaur aux femmes ; en bengali, Begum et Khatun sont exclusivement féminins. Ce ne sont pas deux graphies d'un même nom, si bien que les fichiers masculin et féminin ont légitimement des longueurs différentes — en_IN livre 836 noms de famille masculins et 842 féminins, bn_BD 400 et 404. Un validateur qui exige que « les deux fichiers correspondent ligne pour ligne » bloque silencieusement l'ajout, où que ce soit, du nom de famille le plus fréquent de tout un pays.

Le grec relève du deuxième groupe, et ce fut une correction : il était d'abord classé comme invariant, ce qui est faux — -ος → -ου, -ης → -η, et 545 des 648 paires de noms de famille grecs changent effectivement.

Le nom de jeune fille est toujours tiré du corpus féminin, car un nom de jeune fille est le nom de famille de la mère avant son mariage, quel que soit le sexe du titulaire de la carte.

3. Année de naissance → cohorte d'âge

Pour dix locales — de_AT, en_CA, en_GB, en_IE, en_NZ, en_US, es_ES, fr_FR, it_IT, no_NO —, le prénom est tiré d'un corpus construit pour la décennie de naissance de la personne de la carte, et non de la liste de tous les temps du pays. Huit de ces dix couvrent les sept décennies ; la série autrichienne commence en 1984 et l'italienne en 1999, ce qui est un défaut à part entière et fait l'objet d'un article dédié. Les bornes de décennie suivent la convention de l'INSEE : [1941, 1951, 1961, 1971, 1981, 1991, 2001], de sorte que 1950 tombe dans la classe 1941 et que 1951 ouvre la suivante.

L'effet sur les corpus livrés, classés selon les effectifs réels de naissances :

Le norvégien et le français se renouvellent entièrement ; l'américain bouge à peine en tête, ce qui constitue en soi le résultat — les prénoms masculins anglophones se renouvellent plus lentement. Le mécanisme, et les données de registre qui le sous-tendent, font l'objet de Votre prénom est un acte de naissance.

Une douzaine de cartes masculines en_US réelles, tirées aux deux extrêmes, donnent ceci :

• nées en 1951 : David, John, Julian, Jessie, Allen, Dan, Willie, Keith, Gary, Dennis, Rodger, Rick
• nées en 2004 : Kevin, Caleb, Andrew, Jajuan, Carson, Jacob, Samson, Baylor, Talon, Benjamin, Daniel, Reece

Notez qu'il s'agit de tirages et non de la tête de la liste — Rodger et Jajuan sortent de la queue. C'est là tout l'intérêt de la pondération : la tête domine sans que la queue disparaisse.

4. Fréquence

Les noms sont pondérés, pas uniformes. Jusqu'au 18 juillet 2026, le poids s'exprimait en répétant une ligne dans le corpus — un poids de 7 signifiait sept lignes identiques —, ce qui plafonnait la résolution à 255 et alourdissait la queue à mesure que les données devenaient plus complètes. Mesuré sur le registre taïwanais : à pleine profondeur (2 707 noms de famille), le top dix tirait 24,9 % là où le chiffre réel est de 52,8 %, soit une erreur de −27,9 pp qui croissait avec chaque nom de famille rare ajouté. L'ancien format punissait la complétude.

Le corpus ne contient plus que des valeurs uniques, les poids résidant dans un fichier .wgt parallèle — des uint32 cumulés, un par enregistrement, résolus par recherche dichotomique. Il n'y a plus de plafond, le cache est plus petit, et le poids peut être un décompte littéral de porteurs.

Douze corpus de noms de famille portent désormais de véritables effectifs de registre plutôt que des rangs calibrés, remesurés le 22 juillet 2026 :

L'étalement est à lui seul tout l'argument en faveur des effectifs réels : le top dix polonais atteint 3,19 % et le vietnamien 69,58 %. Tout générateur qui calibre chaque pays sur la même bande de concentration efface un écart de facteur vingt. La méthodologie pour le contrôler — et les pièges qu'elle recèle — est exposée dans Comment auditer un jeu de données de fréquence des noms.

Les prénoms sont plus en retard : seules huit locales fonctionnent avec de véritables effectifs de naissances (en_US, en_GB, fr_FR, es_ES, sv_SE, no_NO, en_IE, en_NZ). Les noms de famille ukrainiens reposent sur des effectifs de registre, mais pas les prénoms ukrainiens — la locale n'est migrée qu'à moitié, et dire « uk_UA a de vrais poids » sans cette réserve serait faux.

5. Ville ↔ code postal comme une seule paire

La ville et le code postal ne sont pas deux tirages indépendants. Chaque locale livre locality/<locale>.tsv, dont les lignes ont la forme City⇥Region⇥Postcode, plus une quatrième colonne population optionnelle ajoutée le 18 juillet 2026. Une seule ligne est tirée, et la ville et le code postal en sortent ensemble : ils s'accordent donc toujours. La région est conservée pour la pondération et le contrôle, mais n'est pas imprimée sur la carte.

6. Taille des villes

Au 22 juillet 2026, 44 locales sur 64 pondèrent la sélection des villes par la population. La différence se voit sur 400 tirages :

Dans la colonne argentine, chacune des 60 villes est sortie, et Buenos Aires — trois millions d'habitants dans la ville proprement dite — n'est pas tirée plus souvent que Rafaela, qui en compte environ 100 000. Voilà ce que signifie une sélection uniforme, et cela reste invisible sur n'importe quelle carte prise isolément. Le traitement complet se trouve dans Pourquoi les générateurs d'adresses produisent des villes implausibles.

7. Déterminisme — et pourquoi chaque tirage est exactement un tirage

L'URL /<country>/<id> doit renvoyer la même personne pour toujours. C'est une exigence produit, pas une coquetterie technique : un permalien vers une carte ne vaut rien si la carte dérive.

La graine est obtenue en hachant le sel secret de l'installation avec l'id, et le résultat initialise le PRNG. Tout ce qui vient ensuite est tiré de ce seul flux. Le hachage exact, sa troncature et le secret lui-même ne sont délibérément pas publiés ici — ils sont la seule partie de cette conception qui doive rester privée, et la raison en est donnée à la section suivante.

La subtilité ne réside pas dans l'initialisation de la graine. Elle réside dans ce motif :

function pick(string $dataset): ?string
{
    $h    = open($dataset);
    $keep = mt_rand(0, PHP_INT_MAX);          // exactly one draw, in BOTH branches
    $v    = ($h !== null && $h['total'] >= 1) ? read_at($h, index_for($h, $keep)) : null;
    mt_srand($keep);                          // stream returns to the same point in BOTH branches
    return $v;
}

Chaque fonction de sélection dépense exactement un mt_rand() puis réinitialise le flux sur $keep. Après l'appel, le RNG se trouve au même point, que le jeu de données ait existé, qu'il ait été absent, ou qu'on soit tombé sur un repli ayant consommé un nombre inconnu de tirages.

Sans cet invariant, ajouter un seul jeu de données décale le flux pour tous les champs qui le suivent. Construisez un nouveau corpus et chaque carte du site change de nom, d'adresse, de téléphone, de mot de passe et de date d'anniversaire. Pire, nous avons rencontré la version réelle du problème : un worker ayant constaté une fois l'absence d'un jeu de données a mis ce résultat négatif en cache et est resté sur le repli Faker jusqu'à la fin de sa vie, si bien que la même URL servait des personnes différentes depuis différents workers PHP-FPM au même instant. Le correctif tenait en deux points — ne jamais mettre en cache une recherche négative, et faire en sorte que les deux branches coûtent un tirage.

La même discipline vaut pour la recherche de cohorte. Une fonction utilitaire « le premier de ces candidats » — essayer le corpus décennal, se rabattre sur le corpus général — parcourt les candidats dans l'ordre mais ne dépense qu'un tirage au total ; un naïf pick($a) ?? pick($b) ?? faker() en dépenserait deux ou trois et ferait que la présence de données de cohorte rebat toute la carte.

8. L'année de création de la carte est encodée dans son id

L'id n'est pas opaque. Certains de ses premiers octets portent de la structure plutôt que de l'entropie — parmi eux la version de l'archive, la plage d'âge demandée au curseur, un drapeau de sexe imposé et l'année de création de la carte. Les décalages exacts sont omis pour la raison donnée au §7 ; ce qui compte pour cet article, c'est que l'année de création soit stockée, pas où elle l'est.

L'année de naissance est calculée comme card_year − age, et non current_year − age. Sans l'année stockée, chaque carte changerait silencieusement de date de naissance à chaque 1er janvier : l'âge est stable puisqu'il vient de la graine, donc l'année de naissance glisserait en avant avec le calendrier. Cet octet a été ajouté le 16 juillet 2026, et les id émis auparavant y portent une valeur aléatoire — d'où le bornage à [1990, current year]. Sans bornage, un octet 0x93 se lisait comme l'année 2147 et produisait une carte née en 2103.

9. Le sel de l'installation

Le générateur est déployé avec un unique sel secret. Sans lui, /<country>/<id> serait une fonction pure du seul id — quiconque exécuterait le même code sur les mêmes corpus rendrait littéralement la même personne pour la même URL. Le sel entre à la fois dans la graine d'identité et dans le hachage du pays aléatoire : il déplace donc la carte entière, et non un seul de ses champs. Substituer un autre sel et refaire le tirage pour le même id montre à quel point l'effet est total :

Pas un champ ne survit au changement : le nom, la rue, la ville, le code postal et la date de naissance sont tous différents. Les sels ci-dessus sont des valeurs de remplissage — la valeur réelle n'est pas publiée, et c'est là tout l'intérêt du mécanisme. Le suffixe |v1 est la sortie de secours : l'incrémenter régénère chaque carte de la base. C'est une ressource à usage unique, ce qui est une raison de plus de ne pas la dépenser en publiant la valeur actuelle.

10. Numéros de téléphone

Les téléphones proviennent d'une table de 963 préfixes mobiles réels répartis sur 65 entrées de locale, émis au format E.164 (+, indicatif pays, numéro national, sans séparateurs). Faker a été abandonné pour ce champ pour deux raisons mesurées : à l'intérieur d'une même locale, son format variait (el_GR produisait aussi bien 698 7681 770 que 6969005371), et plusieurs fournisseurs tiraient au hasard l'indicatif pays lui-même — es_AR émettait 35 indicatifs pays distincts et it_IT 99. Chaque carte italienne portait un numéro de téléphone venu d'un pays choisi au hasard.

Ce sont des plages mobiles qui sont utilisées plutôt que des lignes fixes : elles sont plus actuelles et ne sont pas rattachées à une ville précise, ce qui évite de revendiquer une précision (indicatif régional s'accordant avec la ville) que rien d'autre dans la carte ne vient étayer.

11. Eircode

Un Eircode irlandais se compose d'une clé de routage de 3 caractères et d'un identifiant de 4 caractères désignant un seul bâtiment. Copier un code directement depuis le fichier de localités donnerait à toutes les cartes d'une même ville un Eircode identique — un défaut que n'importe quel lecteur irlandais repère immédiatement.

La clé de routage est donc conservée telle qu'elle figure dans la ligne de localité (elle est réelle et s'accorde avec la ville) et les quatre caractères finaux sont tirés de l'alphabet Eircode, ACDEFHKNPRTVWXY0123456789 — 25 symboles, à l'exclusion de B, G, I, J, L, M, O, Q, S, U, Z, qu'Eircode omet délibérément pour éviter les confusions entre caractères. Cinq cartes consécutives :

Kildare      R51 X775
Tullamore    R35 5RT8
Drogheda     A92 HNK0
Sligo        F91 XAPK
Listowel     V31 29FX

Ces quatre tirages supplémentaires n'ont lieu que pour en_IE ; toutes les autres locales passent à côté de la branche, si bien que les cartes d'aucune autre locale ne se décalent.

12. Domaine de messagerie

Le domaine de la boîte aux lettres provient d'une archive versionnée, en ajout seul, d'instantanés figés, et le numéro de l'instantané correspond aux deux premiers chiffres hexadécimaux de l'id. Une carte neuve reçoit current ; une carte ancienne lit sa version dans son propre id et obtient pour toujours cet instantané figé. La liste vivante des domaines qui fonctionnent change en permanence ; les permaliens, non.

Ce que le générateur ne fait pas

Chaque point ci-dessous est une limitation réelle et reproductible. Aucun n'est théorique.

Les noms ne varient pas selon la région à l'intérieur d'un pays

La Bavière et Hambourg ne prénomment pas les enfants de la même façon ; la Catalogne et l'Andalousie non plus. Nous modélisons une seule distribution de noms par pays. Une carte de Munich et une carte de Kiel tirent dans le même corpus. Les rues souffrent de la même platitude : il existe un seul fichier de rues par pays, si bien que rien ne distingue une liste de rues bavaroise d'une liste hanséatique.

Les noms de famille ne varient pas selon l'âge

Les données de cohorte n'existent que pour les prénoms. Les noms de famille d'origine migratoire ont une structure par âge très marquée — un corpus allemand de noms de famille de personnes de 20 ans n'est pas celui des personnes de 80 ans — et nous l'aplatissons complètement. Une carte allemande née en 1941 a autant de chances de tirer Öztürk qu'une carte née en 2001.

Le prénom et le nom de famille ne sont pas coordonnés

C'est le défaut le plus visible sur les cartes prises une à une. Les deux champs sont des tirages indépendants dans des corpus indépendants : les couches se croisent donc. Dans de_DE, les prénoms de la couche turque portent 0,69 % du poids des prénoms et les noms de famille de la couche turque 0,87 % du poids des noms de famille. Tirés indépendamment :

Ainsi, environ 1,5 % des cartes allemandes traversent la couche et six sur cent mille seulement produisent une paire turco-allemande cohérente — Mehmet Müller est environ 100 fois plus probable que Mehmet Öztürk. La même chose se produit partout où un corpus contient plus d'une strate onomastique : un prénom arabe atterrit sur un nom de famille ashkénaze en he_IL, Aidan Paun sort de en_IE. La correction consiste à regrouper les corpus en strates et à tirer la paire dans une seule strate ; c'est une dette ouverte, pas un plan que nous aurions exécuté. Voir La couche migratoire manquante.

Les rues ne sont pas liées aux villes

La rue et la ville sont des tirages indépendants à l'intérieur d'une locale. Douze cartes ukrainiennes consécutives produisent вул. Захисників України, 154 à Сімферополь et вул. Гетьмана Павла Скоропадського, 161 à Київ — assez plausible —, mais rien n'empêche qu'une rue qui n'existe que dans une ville soit placée dans une autre, ni qu'un nom qui désigne une place plutôt qu'une rue apparaisse avec un numéro de rue. L'appariement que nous imposons bel et bien, c'est ville↔code postal ; rue↔ville, non.

Les poids des prénoms de 56 locales sont calibrés, pas mesurés

Seules huit locales tirent les poids de leurs prénoms de registres de naissances. Les 56 autres ont été ajustées vers une bande supposée de « 20–35 % de part du top 10 partout » — une norme qui n'existe pas. Mesuré face aux six locales qui disposaient d'effectifs réels lorsque la comparaison a été menée en juillet 2026 : la concentration réelle du top 10 s'étale de 9,88 à 33,32 % (un rapport de 3,4), nos corpus calibrés de 20,68 à 24,84 % (un rapport de 1,20), et la corrélation des rangs de Spearman entre nos chiffres et les vrais est de 0,056. Ce n'est pas un signal comprimé ; c'est l'absence complète de signal pays. Les erreurs individuelles atteignent 13 pp — la part réelle du top 10 féminin aux États-Unis est de 9,88 %, notre corpus annonce 23,01 %. La calibration a également aplati l'écart réel de concentration entre hommes et femmes, de 7,41 pp à 1,81 pp. Calculs complets dans L'effondrement de la diversité des prénoms.

20 locales n'ont pas de poids de villes

44 des 64 fichiers de localités comportent une colonne de population. Les 20 restants tirent les villes uniformément. Une partie relève de travaux en attente ; une autre est délibérée. Là où l'institut statistique d'un pays ne publie que des chiffres régionaux, ou là où les nombres disponibles mélangent des unités incompatibles — la kommune norvégienne face au tettsted, le gouvernorat saoudien face à la ville —, nous avons laissé la locale en tirage uniforme plutôt que d'assembler une colonne à partir de deux choses de nature différente. Une ville tirée uniformément est une approximation documentée ; une colonne dont deux tiers des lignes relèvent d'une unité et un tiers d'une autre est un défaut que personne, nous compris, ne verrait jamais.

Les cohortes couvrent 10 locales sur 64

Cinquante-quatre locales tirent un prénom sans aucune référence à l'année de naissance de la carte. Dans celles-là, une carte née en 1945 et une carte née en 2005 tirent dans la même liste.

Faker reste le plancher

Là où un jeu de données manque, le champ se rabat sur la bibliothèque Faker — abandonnée depuis 2020, émettant des avertissements de dépréciation sur PHP 8.5, et à l'origine des défauts de numéro de téléphone et de format d'adresse décrits plus haut. Elle n'est délibérément jamais atteinte lorsque les corpus sont construits, mais elle reste le plancher sous chaque champ.

Pourquoi tout cela compte pour qui utilise le site

Deux de ces propriétés sont celles qu'un utilisateur ressent vraiment.

Le permalien fonctionne pour toujours. L'URL d'une carte est une promesse : le nom, l'adresse, le téléphone et la date de naissance qui y figurent seront identiques dans cinq ans. C'est pour cela que l'année de naissance est figée dans l'id, que le domaine de messagerie provient d'une archive versionnée et que chaque fonction de sélection est disciplinée jusqu'à exactement un tirage. Qu'un seul de ces trois éléments manque, et l'URL devient silencieusement une autre personne — et silencieusement est le mot qui compte, car rien, sur une carte, n'a jamais l'air cassé. Ce n'est simplement plus la carte qui avait été mise en signet.

Le réalisme est une propriété de la distribution, pas de la carte prise une à une. Chaque carte brésilienne tirée uniformément porte une ville réelle avec un code postal correct. Leur ensemble décrit un Brésil où São Paulo a la même taille que Palmas. Aucune inspection de cartes individuelles, si poussée soit-elle, ne le révèle : c'est pourquoi les limitations ci-dessus sont énoncées comme des mesures et non comme des impressions — celles que nous avons attrapées, nous les avons attrapées en comptant, et plusieurs d'entre elles portaient sur des choses que nous avions supposées correctes.

Données arrêtées au 2026-07-18

Chaque décompte, chaque part et chaque exemple de cet article ont été mesurés à cette date directement sur le code en fonctionnement et les fichiers de données livrés : 64 répertoires de locales contenant 261 fichiers de poids et 20 fichiers de cohortes, 64 tables de localités et 63 tables de rues. Les décomptes de tirages de villes et de préfixes ont été remesurés le 22 juillet 2026.

Les exemples de cartes ont été produits en exécutant la fonction d'identité en production sur les corpus livrés, par le même chemin d'initialisation de la graine que celui du site en ligne. Les tableaux de tête de corpus ont été calculés en décodant les fichiers de poids cumulés et en triant par poids ; ce sont les propres chiffres des corpus, qui, pour les douze locales listées, sont les propres effectifs des registres.

Les sources de registre derrière les corpus pondérés sont documentées locale par locale dans les articles compagnons : Les 10 noms de famille les plus fréquents par pays, Courbes de concentration des noms de famille et Données ouvertes sur les registres de noms de famille.