Résumé

  • À 09 h 46 CEST le 7 octobre, RIPE NCC indiquait que certaines requêtes à l’application Web de la RIPE Database échouaient avec une erreur 502. À 09 h 47, un correctif était annoncé en surveillance ; l’incident a été déclaré résolu à 10 h 21 le 8 octobre.
  • Les 24 h 34 séparent le statut « surveillance » de l’avis de résolution. Elles ne prouvent ni que les erreurs ont persisté pendant un jour, ni combien de requêtes ont échoué, ni qu’une autre méthode de consultation était disponible.

Une chronologie de statut ne mesure pas la panne

La fiche publique tient en trois temps : un premier signalement, un passage en surveillance une minute plus tard, puis une résolution le lendemain matin. RIPE NCC ne précise que « certaines requêtes ». Aucun point d’accès, aucune opération ni aucune cause ne sont nommés. L’écart d’une minute entre deux messages publics ne prouve pas que le problème a été découvert puis corrigé en une minute.

De 09 h 47 CEST le 7 octobre à 10 h 21 CEST le 8 octobre, il s’écoule 24 h 34. C’est le temps pendant lequel la fiche est passée de « surveillance » à « résolu ». Ce n’est pas une mesure de l’indisponibilité : la page ne donne ni l’heure de la première requête en échec, ni celle de la dernière, ni l’évolution des erreurs après le correctif.

La documentation de la RIPE Database situe le formulaire de requête dans son interface Web, qui comprend aussi Webupdates. La fiche d’incident ne précise pas quelles requêtes ou fonctions étaient concernées ; elle ne permet donc pas d’affirmer que la recherche ou les mises à jour ont échoué en particulier. Les requêtes REST sont décrites séparément. Cette séparation décrit l’architecture, pas la disponibilité de REST ou de la ligne de commande pendant l’incident.

Pour un opérateur, l’enjeu pratique est de savoir quelle voie a renvoyé quel résultat. Une requête navigateur en échec ne prouve pas qu’une fiche d’enregistrement a changé, disparu ou été corrompue. Un avis portant sur certaines requêtes Web ne suffit pas non plus à conclure à une panne de toute la base. La fiche ne signale pas de perte de données ni de compromission, mais elle ne quantifie pas l’impact côté client.

La conclusion défendable reste limitée : RIPE NCC a signalé des erreurs 502 sur certaines requêtes Web, annoncé un correctif en surveillance, puis déclaré l’incident résolu. Le tableau de bord actuel indique que la RIPE Database est opérationnelle ; il décrit l’état présent, pas celui du 7 octobre. L’historique rend visibles les changements de statut, mais pas la fenêtre ni l’ampleur des erreurs réellement observées.

Sources