Résumé

  • Le programme RIPEstat du troisième trimestre 2026 désigne l’historique de routage comme la prochaine visualisation importante à reconstruire et relie cette modernisation à la maintenabilité ainsi qu’à l’activation de la politique CSP.
  • L’API publique alimente seule l’interface, mais ses seuils, limites souples, options de premier saut, bornes temporelles et états de visibilité absente peuvent produire des lectures différentes à partir de données valides.
  • Un registre de parité devrait fixer les réponses testées, les paramètres résolus, les écarts intentionnels, les cas limites, les corrections et la condition de retrait de l’ancienne vue.

Le seuil qui déplace le début d’une histoire

Une annonce de préfixe apparaît auprès de neuf pairs RIS, puis de onze. Si une vue conserve le réglage par défaut de dix pairs et si une autre montre également les observations plus faibles, leur trait ne commencera pas au même moment. Aucun paquet n’a besoin d’avoir disparu. Aucun collecteur n’a besoin d’être défaillant. La divergence naît du seuil choisi pour rendre l’histoire lisible.

C’est le risque précis que devrait encadrer la prochaine étape de RIPEstat. Le programme du troisième trimestre 2026 indique que la prochaine visualisation à mettre à jour sera Routing History, jugée précieuse pour les utilisateurs internes et externes. RIPE NCC veut reconstruire les visualisations anciennes sur des technologies récentes, rafraîchir leur apparence, améliorer leur maintien dans la durée et permettre une politique de sécurité des contenus, ou CSP. Le chantier est annoncé « en cours ».

Il faut d’abord reconnaître la force de cet argument. Une interface héritée impose souvent des dépendances, des scripts intégrés et des modes de chargement que les politiques modernes du navigateur supportent mal. La spécification du W3C décrit le CSP comme un mécanisme permettant de contrôler les ressources qu’une page peut charger ou exécuter et d’autres décisions de sécurité. Son mode d’observation permet de relever les violations avant de passer à l’application stricte. Supprimer un obstacle technique à cette défense est une obligation normale d’entretien ; ce n’est pas l’aveu d’une compromission.

La parité ne signifie pas non plus l’identité des pixels. Une nouvelle palette peut mieux servir les personnes daltoniennes. Une navigation au clavier peut modifier l’ordre des éléments. Un écran étroit exige parfois de résumer une légende. Les anciens programmes RIPEstat montrent d’ailleurs une équipe qui a déjà achevé la parité fonctionnelle entre une ancienne et une nouvelle interface, automatisé des tests d’interface, déployé prudemment de nouvelles dépendances et surveillé l’effet d’une migration des traitements RIS. Rien dans les sources étudiées n’autorise à affirmer qu’il n’existe aucun test interne.

La difficulté commence lorsque la sécurité de l’exécution et la continuité du sens sont confondues. Le CSP peut montrer que le nouveau code respecte une politique plus stricte. Il ne montre pas que deux lecteurs, placés devant les mêmes observations, tireront la même conclusion sur le début d’une annonce, sa visibilité ou son origine.

Une réponse API ne dessine pas toute seule

RIPEstat fournit une frontière d’autorité remarquablement claire. La présentation de la Data API la qualifie d’interface publique et d’unique source de données des widgets et de l’interface. La page « Qu’est-ce que RIPEstat ? » distingue l’API, qui fournit les données et répond aux requêtes, de l’interface, qui montre comment les visualiser.

La réponse de l’API peut donc servir d’ancre de comparaison. Elle n’enlève pas le travail d’interprétation. La version 2.3 de l’endpoint Routing History regroupe des périodes d’annonce par origine et par préfixe à partir des collecteurs RIS. Plusieurs paramètres peuvent modifier ce qui arrive à l’écran.

max_rows est une limite souple fixée par défaut à 3 000. Lorsque la limite est atteinte, toutes les routes enregistrées pour une origine déjà retenue sont renvoyées, mais les origines suivantes ne le sont plus. L’ordre et l’avertissement de troncature ne sont donc pas décoratifs. include_first_hop peut remplacer une simple origine par un couple origine-premier saut et multiplier les séries. min_peers, fixé à dix par défaut, écarte les annonces peu visibles ou localisées. normalise_visibility ajoute une proportion calculée à partir des pairs RIS de table complète. Les bornes de début et de fin déterminent enfin la fenêtre observée.

Une valeur mérite un traitement particulier : la visibilité normalisée peut valoir -1 lorsque les informations sur les pairs sont absentes ou peu fiables. Ce n’est pas zéro. Tracer le point sur l’axe suggérerait une absence mesurée ; le supprimer sans signe pourrait suggérer une continuité ; relier les deux côtés pourrait fabriquer une observation. Plusieurs représentations honnêtes sont possibles, mais aucune ne devrait rester implicite.

La portée de l’observation doit voyager avec la courbe. La documentation dit que Routing History repose sur les collecteurs RIS. Celle de Routing Status parle constamment d’état « observé » par RIS et avertit qu’un AS peut avoir d’autres voisins non vus par ces collecteurs. La vue est une preuve publique solide depuis des points définis, non un recensement absolu de l’Internet.

Enfin, la fraîcheur interdit de comparer naïvement deux captures en direct. RIPEstat explique qu’elle dépend de la collecte, de la mise à jour des magasins, des délais de traitement, des incidents et des caches. Deux pages ouvertes à des instants différents peuvent montrer deux états du service plutôt que deux interprétations du même état. Un test de migration doit donc figer une réponse, son heure et son empreinte. Les tests en direct restent nécessaires, mais ils mesurent la santé du service.

La forme minimale du registre

Il ne faut ni une nouvelle commission permanente ni deux interfaces conservées sans fin. Pour chaque cas représentatif, un document versionné peut préciser : les versions de l’ancienne et de la nouvelle interface ; la version de l’endpoint et de sa méthode ; la ressource ; l’intervalle UTC ; le fuseau d’affichage ; les paramètres fournis ; les valeurs par défaut effectivement appliquées ; l’empreinte de la réponse capturée ; les règles de groupe, de tri, de troncature et d’absence.

Les cas de test doivent chercher les endroits où une décision bascule : préfixe à origine unique, ressource multi-origines, réponse assez grande pour solliciter la limite souple, observation de part et d’autre du seuil de pairs, premier saut inclus, visibilité indéterminée, dernière période encore ouverte, lecture au clavier et sur petit écran.

Un écart attendu n’est pas un échec. Le registre peut dire qu’une couleur a changé pour l’accessibilité, qu’une légende a été déplacée ou que l’UTC devient la référence. En nommant la raison, il empêche un futur mainteneur de réintroduire une ancienne faiblesse au nom d’une fausse fidélité.

Il doit aussi donner un responsable, la liste des exceptions non résolues, une date de revue, les liens de correction et la règle de retrait. L’ancienne vue peut disparaître lorsque les écarts qui changent une décision ont été corrigés ou acceptés explicitement, que les usages accessibles fonctionnent et que la lecture de la nouvelle interface est reproductible à partir de la requête conservée.

Ce qui n’est pas établi

Les documents ne prouvent pas que la visualisation actuelle est fausse, que la nouvelle est déjà déployée, que le CSP modifie les données de routage, qu’une vulnérabilité est exploitable ou que RIPE NCC a perdu des observations. Le programme trimestriel n’est pas un rapport de livraison et la documentation publique ne décrit pas tous les contrôles internes.

La proposition est donc préventive. Elle sépare la provenance — API et RIS — du choix de visibilité opéré par une version précise de l’interface. La sécurité peut avancer vite ; la continuité du sens n’a plus besoin d’être une promesse invérifiable.

Sources