Résumé

  • La RIPE Database permet maintenant de consulter et comparer l’historique de certains objets depuis sa page de recherche; à RIPE 93, l’équipe a précisé que la première version ne couvrait qu’un petit nombre de types.
  • L’interface rend un historique existant plus accessible. Elle n’élargit pas à elle seule la période conservée ni les données publiées, et le guide officiel n’a pas encore été aligné.

Une fiche d’objet change. La question, souvent posée au mauvais moment, est simple : qu’y avait-il avant ? La RIPE Database offre désormais une réponse directement sur la page où l’on consulte l’objet courant. Le petit bouton « Version History » ouvre un historique; un sélecteur permet de choisir une date; une comparaison met deux versions côte à côte.

La mise à jour mensuelle de RIPE NCC pour octobre annonce cette fonction. À RIPE 93, l’équipe Database a décrit les commandes de liste, d’affichage et de comparaison dans l’interface Web. La vérification de la fiche AS3333 de RIPE NCC a bien montré le bouton, puis une page « Object History » avec le sélecteur, l’action Compare et des liens XML et JSON. La dernière version affichée datait du 19 mars 2026. La comparaison n’était plus cachée derrière une commande que seuls les habitués connaissent.

L’historique lui-même n’est pas nouveau. Les versions existaient déjà dans la base; la ligne de commande savait les lister et les comparer; RIPEstat utilisait déjà une API d’historique dans son widget. La nouveauté d’octobre est l’accès direct depuis la requête Web. Le présentateur de RIPE 93 indique que seuls quelques types d’objets sont pris en charge au départ. Le bulletin mensuel parle d’objets « sélectionnés », sans publier la liste.

Le guide officiel crée une dissonance plus gênante. La page RIPE Database consacrée aux requêtes historiques affirme encore que les indicateurs d’historique sont réservés à la ligne de commande et indisponibles dans le formulaire Web ou l’API REST. D’autres pages documentent pourtant des points d’accès REST pour lister les versions et en récupérer une précise. Et la page de recherche propose maintenant l’historique. Un lecteur peut réconcilier les trois, mais un manuel ne devrait pas transformer la découverte d’une fonction en fouille archéologique.

Cette trace compte parce que les objets du registre servent au travail. Ingénieurs et opérateurs consultent les informations enregistrées, vérifient une référence, cherchent le moment où un attribut a changé. Une comparaison réduit le coût du contrôle : le champ modifié ressort sans qu’il faille reconstituer deux réponses à la main. C’est un progrès concret. L’information devient plus utile quand elle apparaît à côté de l’objet que l’on vient de chercher.

La version visible ne raconte toutefois pas la décision qui l’a produite. Le modèle public donne un numéro de révision, une date et une opération. La date est celle du traitement par le serveur, générée par la base; elle ne vient pas de l’utilisateur qui a soumis la modification. Le modèle documenté ne nomme ni auteur de la demande ni motif. La comparaison montre un attribut différent. Elle ne dit pas pourquoi il a changé.

La couverture a aussi des bords. Le guide décrit l’historique des objets opérationnels qui existent encore, depuis leur création ou recréation la plus récente. Si un objet a été supprimé puis recréé, l’historique public porte sur ce dernier cycle et indique la date de suppression; il ne reconstitue pas l’ensemble du cycle précédent. Les anciens objets PERSON et ROLE ne sont pas consultables, et les attributs contenant des adresses électroniques sont filtrés. Ce sont des limites précises de continuité et de vie privée, pas des notes à lire après avoir traité l’écran comme un journal complet.

La lacune immédiate est la liste des types couverts. RIPE 93 dit que le périmètre initial est réduit. Quand le bouton apparaît, la fonction est disponible pour ce résultat. Quand il manque, la documentation ne dit pas si le type est exclu, si aucun historique public n’existe ou si une autre condition s’applique. Le bulletin ne nomme pas les types et le guide conserve l’ancien parcours en ligne de commande.

RIPE NCC devrait réunir l’interface, l’API et les règles de preuve sur une seule page. Il faut y publier les types pris en charge et la date de mise en service, relier le bouton au point d’accès correspondant, expliquer l’absence d’un bouton, puis préciser le traitement des dates, des suppressions, des recréations et des données personnelles. La même page doit évoluer quand la liste s’élargit. Un nouveau bouton ne devrait pas obliger les lecteurs à arbitrer entre trois documents pour savoir ce qu’il établit.

L’historique est maintenant plus facile à voir. Le mode d’emploi continue d’envoyer les lecteurs ailleurs.

Sources