Résumé

  • Le JavaScript public d’AIRRS ajoute la clé littérale amp;profile=afrinic à l’appel de structure de page de RIPEstat. Dans une chaîne JavaScript, & ne redevient pas automatiquement & : le nom du paramètre est donc amp;profile, et non profile.
  • Le 11 septembre 2026, les requêtes par défaut et celles reproduisant cette clé ont livré la même structure normalisée à sept onglets pour un ASN, un préfixe, un domaine et un pays.
  • Pour les quatre ressources, profile=afrinic — le nom correct — a renvoyé HTTP 500, status: error et zéro onglet. Cela ne démontre aucune erreur dans les données des widgets ; cela révèle une sélection de profil non prouvée.
  • Une réparation vérifiable doit à la fois corriger la requête, rendre le profil nommé opérationnel et publier un reçu indiquant profil demandé, profil retenu, empreinte de structure, statut et règle de repli.

La page qui fonctionne trop bien

Les pannes franches ont un mérite : elles interrompent l’illusion. Une page blanche, une erreur nette ou un graphique absent déclenche une enquête. Un service qui répond avec une solution de repli est plus délicat. Il reste utile, donc personne n’est pressé d’examiner ce qu’il a réellement sélectionné.

AIRRS appartient à cette seconde catégorie. Son nom désigne les statistiques africaines de registre Internet et de routage. La page le décrit comme une collaboration entre AFRINIC et RIPE NCC destinée à présenter, de façon accessible, les données fournies par RIPEstat. Son ambition affichée est exigeante : offrir aux opérateurs, aux régulateurs, aux chercheurs et aux responsables publics des informations à jour sur une ressource Internet ou sur un pays, afin d’éclairer leurs décisions.

L’annonce archivée d’AFRINIC complète ce mandat. Elle cite WHOIS, RIPE RIS, RIPE Atlas et plusieurs jeux de données externes, puis précise qu’AIRRS est alimenté par l’API RIPE Stat. L’interface propose quatre usages immédiatement visibles : consulter un ASN, un préfixe, un nom de domaine ou un rapport de pays.

AIRRS ne fabrique donc pas seul la matière qu’il affiche. Il orchestre une autre plateforme. Cette fonction intermédiaire est importante : avant que les widgets interrogent leurs propres sources, une structure de page décide quels widgets doivent figurer dans quels onglets. Une page peut très bien recevoir une structure valide, se remplir et sembler régionale, sans que le choix régional annoncé ait été appliqué.

Un encodage HTML placé dans une chaîne JavaScript

Le fichier public qui construit les résultats s’intitule lui-même « AFRINIC RIPEstat Template » et porte la mention février 2020. Les en-têtes HTTP de la copie capturée indiquent une dernière modification le 11 mars 2020 à 10 h 00 min 24 s UTC. Lorsqu’une ressource est soumise, ce fichier compose l’adresse de l’API results-page-structure, puis lui ajoute exactement ceci :

&profile=afrinic

Dans un document HTML, & permet d’écrire visuellement une esperluette. Mais ici, les caractères sont à l’intérieur d’une chaîne JavaScript qui devient directement une URL. Il n’existe pas d’étape où un parseur HTML transformerait la suite en séparateur. L’esperluette initiale ouvre bien un nouveau paramètre ; son nom littéral est amp;profile, et sa valeur est afrinic.

Ce détail n’empêche pas nécessairement l’appel de réussir. Une API peut ignorer une clé inconnue et servir sa configuration par défaut. Le code d’AIRRS reçoit alors un objet valide, construit les onglets et précharge les widgets. Le contrôle visuel classique — « la page contient-elle des graphiques ? » — passe sans difficulté.

Pour savoir si le profil intervient réellement, il faut comparer les réponses et non l’apparence. Le test a repris les quatre formes de ressource qu’AIRRS met en avant : l’ASN AS327800, le préfixe 196.192.48.0/20, le domaine afrinic.net et le pays ZA. Trois appels ont été conservés pour chacune : aucun profil, la clé littérale amp;profile=afrinic, puis la clé attendue profile=afrinic.

Douze réponses, une frontière très nette

Pour AS327800, l’appel sans profil obtient HTTP 200, status: ok et sept onglets. L’appel avec amp;profile=afrinic obtient lui aussi 200 et sept onglets. Une fois retirés les champs volatils de l’enveloppe, les objets de données normalisés ont exactement la même empreinte SHA-256. L’appel profile=afrinic, en revanche, obtient HTTP 500, status: error, status_code: 500, aucun onglet et un objet de données vide.

Le préfixe 196.192.48.0/20 donne le même triptyque. La requête par défaut réussit. La requête reproduisant le libellé d’AIRRS réussit avec la même structure normalisée. La requête qui porte réellement le nom profile échoue.

Le domaine afrinic.net ne modifie pas le résultat. Le code pays ZA non plus. Au total : quatre succès par défaut, quatre succès pour la clé littérale dont l’empreinte de structure égale celle du défaut correspondant, et quatre erreurs 500 pour le profil correctement nommé.

Les douze enveloppes identifient la version RIPEstat v0.11.15-2026.09.09 et le pipeline 1415073. Chaque fichier conserve en outre son identifiant de requête, son horodatage, son nombre d’onglets, l’empreinte des données normalisées et celle de la réponse intégrale. L’observation est donc datée et reproductible ; elle ne dépend pas d’une impression obtenue devant le navigateur.

Un champ pourrait prêter à confusion. Les réponses en erreur contiennent data_call_status: supported. La documentation de RIPEstat distingue ce champ de status et de status_code. « Supported » classe l’appel comme pris en charge ; il ne transforme ni un code 500 ni status: error en exécution réussie. Le sens doit être lu dans l’enveloppe complète.

La conclusion reste volontairement circonscrite. Pour ces quatre témoins et à cet instant, la clé émise par AIRRS ne modifie pas la structure par défaut, tandis que le profil nommé échoue. Rien ne permet d’en déduire la cause côté serveur. Rien ne prouve que le comportement a commencé en 2020, qu’il est continu, qu’il concernera chaque ressource ou qu’il perdurera après la prochaine version.

Un profil ne garantit pas la vérité ; son absence exige tout de même une étiquette

Sept onglets ne sont pas sept mensonges. La structure par défaut peut proposer des informations précieuses sur le routage, les registres et les mesures. Les widgets RIPEstat peuvent ensuite interroger leurs propres sources. La matrice n’a pas évalué l’exactitude d’une route, d’un objet WHOIS ou d’une mesure Atlas. Elle ne démontre ni corruption, ni indisponibilité de ces données.

Le défaut concerne la provenance de l’assemblage. AIRRS ne dit pas à l’utilisateur : « le profil AFRINIC a été retenu », « le profil par défaut a été retenu » ou « le profil demandé a échoué et voici notre repli ». Le visiteur voit une marque régionale et une page cohérente. Il est donc naturel qu’il attribue la forme de la page à une sélection régionale explicite.

Cette ambiguïté a plusieurs degrés. Si le profil AFRINIC et le profil par défaut sont intentionnellement identiques, l’effet éditorial peut être nul, mais l’absence de preuve demeure. Si le profil régional choisit normalement d’autres widgets, un autre ordre ou d’autres explications, l’effet devient substantiel. Si le service utilise une dernière structure valide en cache, la question se déplace vers la date et la version. L’interface actuelle ne permet pas de distinguer ces scénarios.

Le profil, d’ailleurs, n’est pas un sceau d’exactitude. Il organise un regard ; il ne certifie pas chaque donnée. Exiger la preuve de sa sélection ne revient pas à affirmer qu’une présentation régionale serait intrinsèquement supérieure. C’est simplement demander que le système établisse la correspondance entre ce qu’il prétend demander et ce qu’il a reçu.

Pour les publics cités par AIRRS, cette correspondance n’est pas un luxe technique. Un chercheur peut capturer une page dans une méthode. Un régulateur peut comparer deux pays. Un opérateur peut reprendre un graphique dans une note de capacité. Un responsable public peut y voir une synthèse adaptée à la région. Plus la page paraît achevée, moins chacun est susceptible de demander quel profil l’a produite.

Six années ne racontent pas, à elles seules, une histoire

La date du client AIRRS et celle du serveur RIPEstat sont éloignées. Le premier fichier porte une dernière modification de mars 2020 ; les réponses testées proviennent d’une version de septembre 2026. Cette différence suffit pour justifier un contrôle de compatibilité. Elle ne suffit pas pour désigner un responsable ni reconstruire une chronologie.

Les sources ne disent pas si profile=afrinic a jadis fonctionné, si le profil a changé de nom, si le fragment & vient d’un copier-coller depuis un modèle HTML, ou si une modification côté API a exposé un ancien problème. Elles ne montrent aucun engagement de compatibilité qui aurait été violé. Elles ne permettent même pas d’établir que la date de dernière modification résume toutes les opérations de déploiement du client.

Il faut donc résister à deux récits faciles. Le premier accuserait un client oublié. Le second accuserait une API qui aurait cassé un contrat. Aucun n’est établi. AFRINIC maîtrise la requête et la présentation publiques d’AIRRS. RIPE NCC maîtrise la résolution du profil et l’enveloppe RIPEstat. Une réparation complète peut demander une action de chaque côté, sans que l’observation actuelle répartisse la faute.

La bonne unité d’analyse n’est pas l’organisation, mais l’interface entre elles. Cette interface doit avoir un test permanent. Le chargement de la page d’accueil ne suffit pas. Un test valable envoie un ASN, un préfixe, un domaine et un pays avec le nom de profil voulu ; il vérifie le profil effectivement choisi, l’ordre des onglets, l’empreinte de structure et les champs de statut.

Le reçu qui manque à la page de résultats

Une refonte n’est pas nécessaire pour lever l’ambiguïté. AIRRS pourrait joindre à chaque résultat — ou à une page publique de diagnostic — un reçu de sélection compact.

Ce reçu commencerait par la forme de ressource et sa valeur canonique. Il reproduirait le nom exact du paramètre envoyé et la valeur de profil demandée. Surtout, il afficherait le profil déclaré comme effectivement retenu par RIPEstat. Si le défaut est utilisé, le mot default devrait apparaître ; une valeur absente ne devrait pas être interprétée comme une sélection AFRINIC.

Le même objet pourrait contenir la version ou l’empreinte normalisée de la structure, les identifiants ordonnés des onglets et widgets, la version de RIPEstat, l’identifiant de requête, l’horodatage ainsi que status, status_code et data_call_status. Il n’est pas utile d’y placer l’historique des recherches de l’utilisateur, son adresse ou une topologie privée.

La règle de repli doit être aussi explicite que le profil. En cas d’indisponibilité du profil nommé, AIRRS peut bloquer la page, afficher la structure par défaut avec un avertissement, ou servir la dernière structure régionale connue en indiquant son âge. Ces choix présentent des compromis différents entre continuité, fraîcheur et provenance. L’erreur n’est pas de choisir l’un d’eux ; elle est de laisser le lecteur ignorer lequel s’applique.

Enfin, le reçu devrait référencer le dernier test réussi pour les quatre formes annoncées. Un code HTTP 200 ne suffit pas : une empreinte de structure et la liste des onglets sont nécessaires pour détecter un changement silencieux. Corriger amp;profile prouve uniquement que le client pose la bonne question. Obtenir 200 avec profile=afrinic prouve que le profil répond. Vérifier l’empreinte prouve que la réponse est bien celle attendue. Ce sont trois contrôles différents.

Cette proposition vient de l’analyse ; AFRINIC et RIPE NCC ne l’ont pas annoncée comme exigence. Sa vertu est sa modestie. Elle transforme une supposition de marque en fait vérifiable, sans prétendre auditer l’ensemble des données que les widgets présenteront ensuite.

Sources