L'autorité n'est pas une propriété des lignes

Il existe en Ouganda un conseil municipal nommé MASAKA TOWN COUNCIL. Il compte 5 731 habitants et se situe dans le Manafwa District, à l'extrême est du pays, tout contre la frontière kényane.

Il existe aussi un lieu appelé Masaka. C'est une ville de 294 166 habitants, dans le sud-ouest, à environ 400 km de là. Les deux n'ont rien à voir l'un avec l'autre, hormis un nom commun.

Les deux lignes proviennent du même fichier : le recensement du Uganda Bureau of Statistics. Les deux sont correctes. Un pipeline qui joint des données géographiques sur la chaîne MASAKA les fusionnera malgré tout, et rien dans l'une ou l'autre source ne s'en plaindra.

Cet article traite des défauts de cette forme — là où chaque nombre pris individuellement, publié par un organisme faisant autorité, est juste, et où le jeu de données construit à partir de ces nombres est malgré tout faux. Nous avons écrit séparément sur les lignes franchement corrompues des statistiques officielles, y compris un défaut de substitution de caractères dans le recensement des États-Unis qui a inventé quatre noms de famille. Le cas présent est plus difficile, parce qu'il n'y a rien à corriger. La source est saine. C'est le présupposé qui est faux.

Le présupposé : un nom identifie un lieu

Ce n'est pas le cas. Dans le recensement ougandais analysé — 2 669 lignes administratives, dont 577 conseils municipaux — cinq noms de conseil municipal sont portés chacun par deux conseils différents :

La paire MAYUGE est la plus instructive, parce que l'un des deux conseils se trouve dans le Mayuge District et l'autre non. Une étape de déduplication qui conserverait « la ligne dont le district correspond à son propre nom » traiterait cette paire correctement par chance, et se tromperait silencieusement sur KINONI — où aucun des deux conseils ne se trouve dans un district de ce nom.

Et MASAKA est pire qu'un doublon, parce que les deux lignes ne sont même pas la même sorte de chose : un conseil municipal de 5 731 personnes situé dans un district, et une ville de 294 166 personnes qui constitue son propre district. Faites la jointure sur le nom, et soit vous perdez 98 % de Masaka, soit vous gagnez 5 731 personnes dans la mauvaise province, selon la ligne que votre GROUP BY conserve par hasard.

Le contrôle qui détecte cela n'est pas du tout un contrôle sur les valeurs. Il s'énonce ainsi : le champ sur lequel vous joignez est-il réellement unique dans la source ? Un seul COUNT() ... GROUP BY name HAVING COUNT() > 1 sur les 577 lignes renvoie cinq, et cinq n'est pas zéro.

Le même échec avec une autre autorité : Wikidata

Nous avons rencontré le problème identique par l'autre bout, en assemblant les poids de population des villes. La méthode consistait à résoudre chaque nom de ville vers une entité Wikidata et à y lire la déclaration de population. Wikidata est une base de connaissances entretenue manuellement, structurée et lisible par machine — à peu près ce qui se rapproche le plus d'une source faisant autorité pour une jointure automatisée.

Les noms qui l'ont fait échouer étaient des mots ordinaires :

Aucun de ces cas n'est une erreur dans Wikidata. Chaque entité cible est correctement décrite. L'erreur est entièrement la nôtre : avoir cru qu'un nom plus un pays suffisaient à identifier une localité.

Le résidu est un fichier de plus de 60 corrections manuelles couvrant 17 locales — bulgare, tchèque, allemand d'Autriche, grec, espagnol, finnois, français de Belgique et du Canada, français, croate, hongrois, italien, norvégien, polonais, roumain, roumain de Moldavie, russe, slovaque. Ce fichier n'est dérivable d'aucune source. Il est le relevé accumulé de chaque endroit où la méthode automatique s'est trompée, et s'il était supprimé, la seule façon de le reconstruire serait de refaire les 60 erreurs.

Le seul garde-fou automatisé qui fonctionne vraiment est bon marché et mérite d'être copié : lorsque la propriété « pays » de l'entité résolue ne correspond pas au pays de la locale, émettez un avertissement. Les occurrences dans le mauvais pays forment le sous-ensemble le plus bruyant des erreurs d'homonymie, et les trouver coûte une seule comparaison.

Un nombre qui apparaît deux fois est une recopie

La version étroite du contrôle d'unicité s'applique aux valeurs, pas seulement aux clés. Wikipédia indique une population de 195 531 pour la ville ougandaise de Mbarara. Dans le fichier de recensement de l'UBOS, 195 531 est la population de Kyengera Town Council, une banlieue de Kampala située à quelque 260 km de là. Le total du Mbarara District lui-même est de 472 629.

Quelqu'un qui lisait un long PDF de tableaux a pris la valeur sur la mauvaise ligne. C'est l'erreur la plus ordinaire qui se puisse imaginer, et probablement la plus largement propagée de tout cet article, parce qu'un chiffre de population de Wikipédia est recopié bien plus souvent qu'un PDF de recensement n'est ouvert. La règle est la suivante : un chiffre ne devrait apparaître qu'à un seul endroit. Si le nombre de la ville A est identique octet pour octet au nombre de la ville B dans le document source, l'un des deux est une recopie, pas une coïncidence.

Quand la source ne veut rien vous dire

Un autre mode de défaillance est celui d'une source qui a des airs d'autorité et qui, tout simplement, n'est pas contrôlable.

forebears.io en est l'exemple canonique. C'est un agrégateur propriétaire : il ne publie aucune méthodologie par pays, aucun registre de sources et aucune date de collecte. ridni.org et stats.ridni.org sont le même genre de source : un nombre apparaît, et rien derrière lui n'apparaît.

Nous voulons être précis sur ce que nous pouvons et ne pouvons pas affirmer ici. Nous pouvons dire que les données sont invérifiables : il n'y a aucune méthodologie à lire et aucun moyen de reconstituer un chiffre. Nous ne pouvons pas soutenir, et nous n'avons vu aucune preuve à l'appui, l'assertion plus forte selon laquelle le site servirait délibérément des chiffres faussés aux clients automatisés ; cela a été avancé dans des notes de travail dont nous avons hérité, et rien de ce que nous pouvons reproduire ne l'étaye. Une méthode non publiée n'est pas la preuve d'une méthode malhonnête.

La position défendable est plus étroite et reste suffisante : un chiffre que vous ne pouvez pas retracer jusqu'à un registre ni reconstituer est au mieux un indice sur l'ordre, jamais un poids, et toute ligne qui repose sur un tel chiffre devrait être étiquetée dans le jeu de données, afin qu'un lecteur futur sache de quelles lignes il s'agit.

La partie où il s'agit de nous

Il serait confortable de s'arrêter là, sur une liste d'erreurs commises par d'autres. Le défaut le plus coûteux de ce type dans le projet était le nôtre, et il a survécu précisément parce qu'il ressemblait à une confirmation.

Les poids des noms de famille ukrainiens (uk_UA) ont produit à une époque une part du top 10 de 5,45 % à l'intérieur du corpus. Nous avions consigné un chiffre de 5,45 % comme part réelle du top 10 au niveau de la population ukrainienne. Les deux coïncidaient exactement, et la coïncidence a été lue comme une validation.

C'était l'inverse. La relation

top-10 share in corpus  ×  coverage  =  top-10 share in population

est une identité, pas une hypothèse. Si les deux parts sont égales, l'identité dit que la couverture est de 100 % — que le corpus contient tous les noms de famille du pays. Le corpus en contenait 2 207. L'Ukraine en compte environ 707 685. Une couverture de 100 % était impossible : l'un des deux nombres devait donc être faux.

Les deux l'étaient. Le chiffre du corpus était gonflé par une queue plate : 1 900 des 2 207 entrées (86 %) se trouvaient au poids minimal de 2 et portaient ensemble 71 % de la masse totale. Et les « vrais » 5,45 % étaient eux-mêmes faux — recalculés à partir des décomptes de Yu. Pradid, les noms de famille du top 10 d'Ukraine couvrent 821 657 porteurs sur environ 45 millions, soit 1,83 % ; Мельник fait 0,24 %, et non les ~1 % que nous avions retenus.

« Après » est l'état au 18 juillet 2026, immédiatement après le correctif. Le corpus a été reconstruit depuis : au 22 juillet 2026, il contient 2 376 noms de famille fondés sur les effectifs de tête du registre, une part du top 10 de 9,4 % et, rapportée au chiffre de population de 1,83 %, une couverture implicite d'environ 19 % — ce qui est la forme que devrait avoir un corpus mince tiré d'un répertoire très plat.

Un accord parfait entre deux nombres obtenus indépendamment est un fait qui demande une explication, pas un résultat qui appelle une célébration. Celui-ci était un double échec déguisé en confirmation.

Le piège apparenté est la vérification circulaire. Si vos poids ont été calibrés à partir du registre X, alors les contrôler contre le registre X — ou contre un article publié qui a tiré ses chiffres du registre X — mesure votre arithmétique, pas le monde. Nous avons repéré cela deux fois dans la même journée : une estimation hongroise portant sur un nom de famille ethnonymique, qui semblait confirmer nos 8,20 % mais puisait dans le même registre, et un contrôle espagnol où la part du top 10 multipliée par la couverture reproduisait la part de population de façon presque tautologique. Notre auto-contrôle taïwanais concorde à 0,03 point de pourcentage près, et nous l'étiquetons dans le texte comme un contrôle de cohérence interne plutôt que comme une vérification, parce que c'est exactement ce qu'il est. L'antidote consiste à saisir la liste de comparaison à la main à partir d'une source sans rapport, et nos contrôleurs de listes de tête font précisément cela.

Ce qu'il faut réellement faire

1. Testez l'unicité de la clé de jointure avant de joindre. Pas les valeurs — la clé. Cinq noms dupliqués parmi 577 conseils municipaux ougandais ne sont qu'à un GROUP BY de distance.
2. Testez si deux lignes qui partagent un nom sont le même type d'objet. MASAKA TOWN COUNCIL et MASAKA CITY diffèrent d'un facteur 51 parce que l'un est un conseil municipal et l'autre une ville de niveau district.
3. Testez qu'une valeur n'apparaît qu'une seule fois. Des chiffres identiques sur deux entités signalent une recopie.
4. Avertissez lorsqu'une entité résolue sort du pays attendu. C'est le garde-fou le moins coûteux qui soit contre les homonymes, et il a permis de repérer Nokia et León.
5. Gardez le registre des corrections manuelles sous gestion de versions et traitez-le comme une donnée primaire. Soixante corrections qu'aucune source ne peut régénérer valent plus, à l'octet, que tout le reste du pipeline.
6. Méfiez-vous de l'accord. Là où deux nombres coïncident exactement, cherchez à savoir s'ils sont indépendants. Lorsqu'ils ne le sont pas, la coïncidence ne signifie rien.
7. Étiquetez les lignes qui reposent sur des sources invérifiables, afin qu'un mainteneur futur puisse les retrouver sans reconstituer la provenance.

L'autorité est une propriété des institutions. L'exactitude est une propriété des lignes. Le Uganda Bureau of Statistics fait autorité, et son fichier contient deux lieux différents appelés Masaka, parce que l'Ouganda contient deux lieux différents appelés Masaka. Le défaut n'a jamais été dans le recensement. Il était dans la jointure.

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

Tous les chiffres ont été recalculés le 18 juillet 2026 à partir des fichiers primaires et intermédiaires listés ci-dessous. Là où nos anciennes notes de travail divergeaient des fichiers, ce sont les fichiers qui l'emportent, et la divergence est indiquée dans le texte.

Sources :

• Ouganda — UBOS, National Population and Housing Census 2014, profils régionaux par zone, analysés en une hiérarchie administrative (2 669 lignes aux niveaux district / county / sub-county ; 577 conseils municipaux). MASAKA TOWN COUNCIL 5 731 dans le Manafwa District, Bubulo West County ; MASAKA CITY 294 166 ; les deux lignes MAYUGE TOWN COUNCIL à 12 481 (Bugiri) et 20 197 (Mayuge). <ubos.org/&gt;
• Wikipédia, article sur Mbarara, population 195 531 — correspondant à Kyengera Town Council dans le même fichier UBOS. Total du Mbarara District 472 629.
• Wikidata — utilisé pour résoudre les noms de villes vers des déclarations de population ; erreurs d'homonymie corrigées dans un registre manuel de correctifs de plus de 60 entrées réparties sur 17 locales.
• Ukraine — corpus de 2 207 noms de famille (tel qu'il se présentait alors) face à environ 707 685 noms de famille dans le pays ; part du top 10 dans la population recalculée à partir des décomptes de Yu. Pradid à 821 657 porteurs, soit 1,83 %.
• forebears.io — agrégateur propriétaire, aucune méthodologie publiée par pays, aucun registre de sources, aucune date de collecte ; les chiffres ne peuvent être retracés jusqu'à un registre ni reconstitués.

Sur l'affirmation concernant forebears.io. Des notes de travail dont nous avons hérité affirmaient que le site renvoie délibérément des données faussées aux clients automatisés. Nous n'avons pu ni le reproduire ni l'étayer autrement, ce n'est donc pas affirmé dans cet article ; ce qui est affirmé, c'est que les données sont non traçables, ce qui est vérifiable et suffisant.

Sur l'identité de couverture. top-10 share in corpus × coverage = top-10 share in population est une identité algébrique dès lors que les définitions sont cohérentes. Elle est utile parce qu'elle punit la coïncidence, et dangereuse parce qu'elle est trivialement satisfaite quand les deux membres proviennent du même registre. Voir Comment auditer un jeu de données de fréquence des noms et Ce que nous avons mal compris sur les données de noms.