Résumé

  • Le 17 septembre 2026, RIPE NCC a publié quatre états pour les API externes de son environnement de test RPKI : enquête à 14 h 22 CEST, problème identifié à 14 h 43, surveillance à 14 h 45 et résolution à 14 h 59.
  • Le composant concerné est le pilote RPKI. La documentation permanente décrit un service de test au mieux, séparé de la production par le système, le jeu de données, le dépôt, le Trust Anchor et l’adresse de base de l’API.
  • L’avis d’incident ne précise ni les opérations du pilote touchées, ni la référence du correctif, ni le contrôle d’isolement propre à l’incident, ni le sort des requêtes, ni le responsable et le critère de sortie de la surveillance. Une attestation de reprise limitée pourrait réunir ces éléments sans révéler de secrets.

Analyse

Quatorze minutes séparent le passage en surveillance de la clôture. C’est la partie la plus intéressante de la chronologie, précisément parce que la page n’explique pas ce qui a été observé pendant ce laps de temps. Elle affirme qu’un correctif a été appliqué, puis que l’incident est résolu. Entre les deux, le lecteur ne voit ni test de santé, ni seuil, ni série de requêtes, ni propriétaire du contrôle.

La chronologie complète commence à 14 h 22 et s’achève à 14 h 59. Les vingt et une premières minutes mènent de l’enquête à l’identification ; deux minutes conduisent ensuite à la surveillance. Ces nombres décrivent les publications de la page d’état. Ils ne fixent pas l’heure réelle de début de la panne, la première détection technique, l’instant exact du déploiement ou la durée totale de validation.

Le périmètre général, lui, est explicite. Le titre vise les « external APIs » de l’environnement de test RPKI et la composante est classée « Pilot (RPKI) » parmi les services non critiques. RIPE NCC prévient que cet environnement est fourni au mieux et reçoit en premier des fonctions bêta susceptibles de différer du système de production.

La documentation va plus loin que le simple mot pilote. La plate-forme hébergée de test est un miroir exécuté sur un système séparé. Les ROA créées dans cet environnement ne modifient pas le jeu de données de production ; elles sont publiées dans un autre dépôt sous un Trust Anchor distinct. La documentation de l’API sépare également localcert.ripe.net pour le pilote de my.ripe.net pour la production.

Ces éléments empêchent une conclusion abusive : l’incident public n’est pas la preuve d’une panne de la RPKI de production. Ils ne disent rien non plus d’une clé de signature, d’une validation de routes, d’une perte de données ou d’un effet BGP. La séparation documentée est un contrepoids important à toute lecture alarmiste.

Mais une architecture permanente ne remplace pas un constat fait pour l’incident. L’avis ne dit pas si l’équipe a vérifié cette frontière pendant l’événement. Il n’indique pas davantage les familles de points d’accès ou les types d’opérations indisponibles. Une lecture, une simulation et une demande de modification ne posent pas la même question de reprise.

Le sort des requêtes est le maillon absent pour l’utilisateur. Une erreur nette à l’entrée, une mise en file d’attente, une acceptation suivie d’un retard et une opération à l’état incertain peuvent toutes accompagner la formule « les API ne fonctionnent pas ». Elles exigent pourtant des actions opposées après le rétablissement. Les sources ne démontrent pas qu’un de ces scénarios s’est produit ; elles montrent que la page publique ne les départage pas.

Une preuve de reprise proportionnée devrait donc joindre sept choses : l’identifiant de l’incident, le périmètre d’opérations du pilote, les horodatages et leur fuseau, une référence de changement ou de correctif, la confirmation d’isolement propre à l’événement, un résultat agrégé de file d’attente ou de réconciliation, et la règle qui clôt la surveillance. Une date de revue ou de correction complète l’ensemble.

La confidentialité n’est pas un obstacle. Aucune clé d’API, aucun contenu de ROA, aucun nom de compte et aucun journal interne n’est nécessaire. Un opérateur peut publier des classes de résultats — refusé avant traitement, accepté puis vérifié, aucune file persistante — et conserver le détail sensible derrière la procédure d’assistance.

Cette petite discipline donnerait aussi à « résolu » une portée plus précise. Le terme décrirait l’état du service ; la réconciliation décrirait l’état des actions des usagers. Confondre les deux charge un seul badge d’une promesse qu’il ne peut pas tenir. Les distinguer protège à la fois l’utilisateur qui doit décider et RIPE NCC contre des inférences sans fondement.

Sources