Résumé

  • Dans son plan du troisième trimestre 2026, RIPE NCC indique avoir achevé la migration des données RIS/RIPEstat vers des serveurs bare metal loués. Le suivi du traitement et la résorption de dette technique restent toutefois en cours.
  • Le même plan distingue deux autres chantiers : l’étude d’architectures de stockage réduisant la dépendance à HBase, et le remplacement des machines Kafka avec montée de version. Aucun de ces éléments ne prouve l’échec du déplacement de données.
  • Le plan archivé de RIPEstat signale une latence supplémentaire entre le service et ses systèmes dorsaux pendant la migration. L’équipe a étudié notamment les requêtes parallèles et suivi l’effet produit, sans publier de mesure ni faire état d’une panne.
  • Un reçu de migration borné par composant devrait relier périmètre de données, génération technique, bascule, rejeu éventuel, contrôles propres aux fichiers MRT, à RIS Live et à RIPEstat, exceptions connues et durée d’observation.

Le mot juste, mais sans son périmètre

Le plan RIS du troisième trimestre 2026 ne manque pas de nuances. RIPE NCC y écrit que la migration des données RIS/RIPEstat vers du bare metal loué est achevée. La phrase suivante présente comme travaux de suivi l’amélioration de la surveillance du traitement et le nettoyage de dette technique. Puis vient l’étude d’autres architectures de stockage afin de moins dépendre de HBase. L’ensemble est encore marqué « en cours ».

Un autre item concerne Kafka. Les machines doivent être remplacées et le logiciel porté vers une version plus récente. Le chantier, auparavant reporté faute de ressources, est lui aussi en cours. Il ne faut ni effacer ces distinctions, ni en tirer un réquisitoire. Le plan ne dit pas que la migration a échoué, que les données ont été perdues ou que HBase et Kafka sont défaillants.

Il révèle plutôt un problème classique de preuve. Le nom d’un programme rassemble des opérations dont les propriétaires, les risques et les tests d’acceptation ne coïncident pas. Déplacer un corpus n’est pas renouveler son transport. Renouveler le transport n’est pas valider chaque traitement. Une requête qui aboutit ne garantit pas que chaque archive publique est complète, pas plus qu’un fichier présent ne mesure la latence d’une API.

La solution n’est donc pas d’interdire le mot « achevé ». C’est de lui rendre son complément : quelle chose, sur quelle période, selon quel test et au nom de quel responsable a été achevée ?

De la session BGP au résultat exploitable

Le service RIS part de sessions BGP fournies par des réseaux volontaires à des Remote Route Collectors, généralement situés dans des points d’échange. Les collecteurs reçoivent annonces et retraits. Les données sont ensuite stockées et mises à disposition afin que chercheurs et opérateurs puissent étudier le routage.

Ce trajet ne forme pas une boîte noire homogène. Le pair détermine la vue qu’il transmet. Le collecteur enregistre ce qu’il reçoit. Un transport achemine les messages. Des traitements fabriquent des états, des historiques ou des réponses. Le stockage conserve plusieurs générations. Enfin, différentes interfaces les rendent observables.

Chacune de ces étapes peut connaître sa propre migration. C’est pourquoi un contrôle réussi au bout de la chaîne n’est pas toujours capable de localiser ce qui a été validé. Si l’intervalle examiné chevauche la bascule, provenait-il de l’ancien stockage, du nouveau, d’un rejeu ou des deux ? Si un résultat a été recalculé après coup, quelle version du traitement l’a produit ? Si le service répond plus lentement, le fait concerne-t-il l’accès, la donnée sous-jacente ou une classe particulière de requêtes ?

Le plan archivé de RIPEstat donne une réponse partielle et précieuse. La migration a introduit une latence supplémentaire entre RIPEstat et les systèmes dorsaux. L’équipe a cherché des moyens de la masquer, dont les requêtes parallèles, et a suivi avec attention l’effet de la migration. Le chantier d’appui est déclaré achevé au troisième trimestre 2026.

Le texte ne fournit ni percentile, ni seuil de service, ni conclusion selon laquelle une solution aurait été déployée partout. Il établit néanmoins que l’acceptation du déplacement des données et l’expérience du consommateur sont deux objets de preuve distincts.

Trois fenêtres, trois vérifications

Les fichiers MRT constituent une première fenêtre. Ils sont organisés par collecteur. Les fichiers bview décrivent un état du routage à un instant ; les fichiers d’updates conservent les changements d’un intervalle. La documentation indique actuellement une création toutes les huit heures pour les vues et toutes les cinq minutes pour les mises à jour.

Cette cadence permet de dresser une liste d’attendus par RRC et par intervalle. Mais la présence du nom attendu ne suffit pas : il faut encore relier le fichier à une génération de traitement, vérifier sa taille ou son empreinte, documenter les exclusions et établir si une période manquante a été rejouée. L’article antérieur consacré à un bview produit mais non publié traite d’un incident précis. Ici, aucun fichier manquant n’est allégué ; l’enjeu est la manière de tester une bascule sans confondre génération et livraison.

RIS Live ouvre une deuxième fenêtre, proche du temps réel. Une session fluide à un instant ne démontre pas l’intégrité de l’archive historique. Inversement, des archives complètes ne disent rien, à elles seules, de la fraîcheur d’un flux. RIPEstat en ouvre une troisième : celle d’une requête et de sa dépendance aux systèmes dorsaux. Les sources publiques étudiées ne permettent pas d’affirmer que ces trois fenêtres empruntent le même chemin interne.

Leur séparation protège l’analyse. On peut tester la présence d’intervalles MRT par collecteur, la fraîcheur de RIS Live selon une règle propre au flux, et des distributions de temps de réponse pour des classes de requêtes RIPEstat. Aucun voyant ne devient le représentant abusif des deux autres.

Les archives montrent pourquoi la génération compte

Les anciens plans RIS racontent plusieurs changements utiles. En 2023, RIPE NCC dit avoir remplacé le pipeline qui produit les dumps MRT publics, avec moins de retard et quelques modifications de structure. En 2025, l’organisation dit avoir corrigé une incohérence par laquelle les données d’un pair IPv6 retiré continuaient d’apparaître dans des jeux de données. Le projet visant à documenter publiquement cet artefact et d’autres a été reporté.

Il faut lire le temps verbal avec soin : l’incohérence est donnée comme résolue ; c’est sa documentation qui a été repoussée. Cet exemple ne prouve aucune corruption actuelle. Il démontre seulement qu’une provenance utile comprend aussi le registre des artefacts connus et la version du traitement.

Les plans de 2024 consacrés à une distribution externe par Kafka et à l’ouverture du code de RIS Live ont, eux, été dépriorisés. Ils ne décrivent pas l’architecture présente. Le Kafka public testé autrefois ne doit pas être assimilé sans preuve aux machines en cours de remplacement dans le plan actuel. La meilleure documentation est celle qui dit expressément où une relation s’applique et où elle ne s’applique pas.

La forme minimale d’un reçu

Un reçu de migration borné par composant peut rester bref. Sa première ligne fixe le périmètre : jeux de données, collecteurs, intervalles, produits destinataires et exclusions. Sa deuxième ligne fixe la filiation : génération de collecte, transport applicable, déploiement de traitement et génération de stockage.

La bascule doit être décomposée. Extraction, alimentation initiale, période de chevauchement, passage de la production, gel éventuel des écritures et retrait de l’ancien environnement ne sont pas le même événement. La transcription de RIPE 88 l’illustre dans un contexte historique plus large : elle évoque séparément extraction, construction d’un cluster, consommation de nouvelles données, bascule future et déclassement. Elle ne doit pas servir de plan topologique actuel de RIS.

Vient ensuite l’acceptation : échantillons avant et après la bascule, intervalles MRT attendus, contrôles de fraîcheur propres à RIS Live, classes de requêtes RIPEstat, percentiles de latence, tolérances et durée d’observation. Le reçu dit si le rejeu était inutile, partiel, achevé ou encore attendu. Il consigne les artefacts et nomme les rôles qui acceptent chaque composant.

Rien de tout cela n’exige d’exposer des adresses internes, des identifiants, des secrets ou des journaux bruts. Des plages temporelles, des empreintes, des numéros de génération, des agrégats et des statuts d’exception suffisent.

Un tel reçu ne cherche pas à rouvrir indéfiniment une migration terminée. Il permet au contraire de la fermer proprement. La donnée peut être marquée migrée. Kafka conserve son calendrier. HBase reste une question d’architecture tant qu’aucun choix n’est publié. Le suivi du traitement garde son objectif. RIPEstat conserve sa mesure côté consommateur. Le mot « achevé » cesse alors d’être une promesse diffuse et devient une décision vérifiable.

Sources