Résumé

  • Dans la capture du 8 septembre, de 14 h à 15 h UTC, total_queries vaut 3 192 583 pour WHOIS, alors que les sept catégories affichées totalisent 3 183 463. Dans le même fichier, les chiffres RDAP s’additionnent exactement.
  • Les 1 690 heures archivées comportant du trafic WHOIS présentent toutes un écart. Le total général est supérieur dans 1 011 fichiers et inférieur dans 679 : une simple catégorie « autre » manquante ne peut donc pas réconcilier les deux sens.
  • Une présentation publiée pour APNIC 62 indique que prop-167 reste « en cours de mise en œuvre » en raison de problèmes d’exactitude. Elle ne nomme pas cet écart. APNIC devrait joindre à chaque heure une équation de rapprochement et un historique des corrections, sans exposer les requêtes brutes.

Un fichier statistique peut être parfaitement téléchargeable, correctement signé par une somme de contrôle et pourtant laisser son lecteur face à deux dénominateurs. C’est le cas de la capture horaire disponible au moment de cette enquête. Pour l’intervalle du 8 septembre 2026 entre 14 h et 15 h UTC, la rubrique WHOIS annonce 3 192 583 requêtes. Les valeurs attribuées à inetnum, route, aut-num, domain, organisation, as-set et inet6num s’additionnent à 3 183 463.

Il manque 9 120 unités entre les deux représentations, soit 0,2857 % du total déclaré. Le contrôle le plus convaincant se trouve juste à côté. La rubrique RDAP du même document affiche cinq types dont la somme, 588 346, est rigoureusement égale à total_queries. La somme MD5 fournie par APNIC correspond au fichier téléchargé. Le transport n’a donc pas altéré les octets ; la différence appartient au contenu publié.

Pris isolément, un écart inférieur à trois dixièmes de point pourrait passer pour une note technique. L’archive montre qu’il s’agit d’une propriété du jeu de données.

Un test sur toute la période, pas un exemple choisi

Les répertoires mensuels commencent le 30 juin, date que la page de prop-167 associe à « Implementation Complete ». Le contrôle a parcouru les 1 691 fichiers horaires disponibles jusqu’à celui se terminant le 8 septembre à 14 h UTC. Le nombre de fichiers correspond exactement au nombre d’intervalles attendus. Les noms se suivent sans trou ; chaque flux gzip est lisible ; chaque document est un JSON valide ; les bornes horaires internes correspondent au nom du fichier. Aucun contenu décompressé n’est dupliqué.

Pour chaque service, le calcul est volontairement élémentaire : somme de toutes les valeurs de query_type_distribution, puis soustraction de cette somme à total_queries. Le même rapprochement est effectué sur chaque ligne ASN affichée, entre query_count et la somme de query_count_by_type.

RDAP constitue un groupe témoin remarquable. Les 1 691 totaux horaires sont égaux à leurs distributions. Aucune des lignes ASN affichées ne présente d’écart interne. Le format sait donc produire une identité arithmétique.

WHOIS ne l’obtient qu’une fois. L’heure du 27 août entre 9 h et 10 h UTC déclare zéro requête, zéro ASN, une distribution vide et aucune ligne. C’est la seule égalité. Les 1 690 fichiers contenant une activité WHOIS comportent tous un écart au niveau du service et au moins une ligne ASN non rapprochée. Au total, 347 490 lignes affichées ont un query_count différent de la somme de leurs types.

La toute première heure, le 30 juin de 3 h à 4 h UTC, donne déjà deux nombres : 4 774 145 requêtes selon le total et 4 801 599 selon les catégories, soit 27 454 de plus du côté des types. Dans la dernière heure archivée du contrôle, le 8 septembre de 13 h à 14 h, la relation s’inverse : 2 989 539 au total, 2 987 334 par types, donc 2 205 de moins.

Ce changement de signe est la donnée décisive. Dans 1 011 fichiers, le total est supérieur à la distribution. On pourrait imaginer des commandes acceptées mais non classées, puis ajouter une catégorie résiduelle. Dans 679 fichiers, les catégories dépassent au contraire le total. Le 14 juillet entre 5 h et 6 h UTC, elles atteignent 3 652 538 face à un total de 3 288 941 : 363 597 de plus, soit 11,0551 %. Une catégorie oubliée ne peut pas être négative. Le 20 août entre 3 h et 4 h, l’écart maximal dans l’autre sens est de 80 961, soit 2,3823 %.

Il serait tout aussi trompeur d’additionner les écarts de signes opposés et de baptiser le résultat « requêtes erronées ». Leur compensation ne mesure rien de défini. Le constat solide porte sur le rapprochement : deux champs qui semblent décrire un total et sa ventilation ne partagent pas, publiquement, une équation stable.

Des compteurs différents peuvent être légitimes

La lecture la plus charitable est aussi la plus plausible. total_queries peut compter les connexions ou commandes acceptées à la frontière du service. La distribution par type peut être alimentée plus tard, après analyse de la syntaxe, enrichissement par ASN ou résolution d’un objet. Des événements tardifs, des reprises internes, des commandes malformées, des requêtes multi-objets ou des fenêtres de clôture différentes peuvent produire deux compteurs honnêtes.

Une telle architecture n’est pas un défaut en soi. Le défaut public est l’absence de traduction entre les étapes. Le README explique que chaque bloc possède une plage horaire, un total de requêtes, un nombre d’ASN, une distribution par type et une liste de statistiques par ASN. Il ne définit ni frontière de comptage, ni catégorie non classée, ni règle de duplication, ni traitement des événements tardifs, ni délai de clôture. Il ne précise pas non plus qu’un type peut éventuellement être incrémenté plusieurs fois pour une seule requête.

Cette lacune interdit de décider lequel des deux nombres serait « le vrai ». Peut-être le total mesure-t-il fidèlement l’entrée du service et les types, fidèlement une activité de traitement. Dans ce cas, les deux chiffres sont justes à leur niveau et trompeurs lorsqu’ils sont placés comme un tout et sa décomposition sans nommer ces niveaux.

La somme de contrôle ne tranche pas davantage. Elle garantit que le lecteur possède le fichier produit par APNIC, non que les champs partagent une unité ou une population. Intégrité du fichier et cohérence métrique sont deux contrôles distincts.

Les listes ASN demandent une précision supplémentaire. Les heures observées peuvent déclarer plusieurs milliers d’ASN, tandis que le tableau asns contient au maximum mille lignes. Ce choix ressemble à un classement tronqué, probablement utile pour limiter la taille des fichiers. Mais le README ne le dit pas. La somme des lignes visibles ne doit donc pas être confondue avec la population entière, même lorsque chaque ligne aura été réconciliée.

Deux états publics pour la même mise en œuvre

La page officielle de prop-167 affiche encore Implemented et inscrit au 30 juin 2026 la mention « Implementation Complete ». En parallèle, APNIC a mis en ligne une présentation destinée à la séance Policy SIG d’APNIC 62, programmée le 10 septembre. La diapositive consacrée à prop-167 indique « Status: In Implementation », rappelle une première publication le 30 juin, puis mentionne « Some issues with data accuracy – Currently being resolved ». L’achèvement attendu est fixé à la fin du troisième trimestre.

La chronologie impose deux réserves. La présentation a été capturée avant l’heure prévue de la séance ; il faut donc la décrire comme un document publié, non comme une déclaration déjà prononcée. Et le document ne relie pas ses « problèmes d’exactitude » aux différences arithmétiques relevées ici. Il ne faut pas inventer ce diagnostic à la place d’APNIC.

Les deux surfaces donnent néanmoins une distinction utile. Le statut de juin peut attester qu’un service a été ouvert au public. La mise à jour de septembre peut reconnaître que l’assurance sur les données n’est pas terminée. Disponibilité et exactitude ne sont pas la même étape. Une politique de transparence ne s’achève pas nécessairement au premier fichier visible.

Pourquoi le dénominateur change l’usage

Le flux public représente un progrès réel. Il offre des volumes, des types, des ASN d’origine et des nombres d’adresses sources distinctes sans divulguer ces adresses ni les objets consultés. Il permet d’étudier les tendances et les concentrations avec une granularité horaire. Le caractère ouvert et archivé rend aussi les erreurs potentielles observables, ce qui est une qualité institutionnelle.

Mais chaque analyse choisit implicitement l’un des deux dénominateurs. Une part d’ASN divisée par total_queries n’est pas la même que la part divisée par la somme des types. Une série construite à partir du total peut évoluer différemment de celle reconstruite par addition. Si les types comptent plusieurs classes pour une commande, leur somme surestime volontairement les requêtes uniques. Si le total inclut des commandes non classées, la distribution sous-représente volontairement une partie de la charge. Sans définition, un graphique exact peut répondre à une question que son auteur n’a jamais formulée.

L’enjeu n’est pas de conclure à une panne WHOIS. Les fichiers ne prouvent ni perte ni duplication, ni réponse incorrecte, ni usage hostile. Une ligne non rapprochée ne rend pas l’ASN fautif. L’heure à zéro ne suffit pas à établir une interruption. La seule affirmation nécessaire est plus sobre : la preuve publique ne permet pas de recomposer les métriques.

Une petite comptabilité pour chaque heure

Le remède peut rester agrégé. APNIC pourrait joindre à chaque fichier une équation comprenant les requêtes acceptées à la frontière externe, celles analysées et classées, puis les comptes exclus pour commande malformée, type non pris en charge, délai dépassé ou autre raison générale. Si une requête alimente plusieurs classes, la multiplicité doit devenir une règle explicite. Si les compteurs ferment à des heures différentes, chaque échéance doit être indiquée.

Le document devrait aussi nommer la transformation : identifiant d’exécution, version de l’ingestion et du classificateur, résultat du contrôle arithmétique, heure d’achèvement. Les échecs d’enrichissement ASN peuvent rester des nombres agrégés. Le tableau limité à mille lignes doit être présenté comme un classement avec sa règle de sélection.

Enfin, toute réparation doit laisser une trace. Un fichier peut porter l’état provisoire, validé, corrigé ou retiré. Son empreinte doit être publiée. Une version de remplacement doit citer l’empreinte antérieure, l’heure de correction, la famille de motif et les champs touchés, tout en gardant l’ancienne version accessible.

Ce registre de rapprochement ne demande aucun nom d’utilisateur, aucune adresse IP et aucune requête brute. Il demande seulement comment deux totaux produits par la même institution peuvent être utilisés ensemble. APNIC a déjà construit la partie la plus coûteuse : la publication régulière et l’archive. L’équation et la chaîne de correction en feraient une preuve durable.

Sources