Résumé

  • Chez LACNIC, last changed indique quand les informations d’un objet RDAP précis ont été modifiées ; cette date ne prouve pas, à elle seule, un transfert, une bascule BGP ou une remise opérationnelle du réseau.
  • Une réponse publique pour 200.7.85.1 montre un objet réseau modifié en 2024 et deux entités intégrées modifiées en 2026. Les trois dates portent sur trois objets, pas sur un seul événement.

Analyse

Le 26 août 2026, la requête LACNIC portant sur 200.7.85.1 a renvoyé le bloc englobant 200.7.84.0/23, de 200.7.84.0 à 200.7.85.255. Cet objet réseau, marqué ASSIGNED, indique une inscription le 25 janvier 2008 et une dernière modification le 17 septembre 2024.

La même réponse JSON intègre deux autres objets. L’entité titulaire UY-LACN-LACNIC affiche une dernière modification le 7 août 2026. Le contact AIL, auquel la réponse attribue les rôles administratif, technique et abus, a été modifié le 20 janvier 2026. Ces dates ne se contredisent pas. La date de 2024 appartient à l’objet réseau ; celles de 2026 appartiennent aux fiches d’entité.

RFC 9083 impose précisément cette lecture. Une structure events décrit des événements sur une instance d’une classe d’objet. L’action last changed signifie que les informations de cette instance ont été modifiées pour la dernière fois à la date indiquée. La norme distingue l’inscription, la réinscription, le transfert, l’expiration, la suppression et le rétablissement. Employer un verbe à la place d’un autre élargit donc la preuve au-delà des données.

La documentation Whois de LACNIC suit la même logique : pour une ressource, changed date la dernière modification de ses informations ; pour un contact, il date la modification de la fiche de contact. RDAP standardise l’accès HTTP et JSON aux données d’enregistrement. Il améliore leur lisibilité informatique, pas leur portée probante.

Dans un audit d’acquisition ou un incident, une date précise invite pourtant à écrire « le contrôle a changé ». Or la réponse ne dit pas quel champ a été modifié, ne nomme pas l’acteur des événements du bloc et ne signale ni vente, ni clôture contractuelle, ni déplacement d’équipement. Elle établit seulement qu’une information de cet objet réseau a changé.

Le routage relève d’un autre mécanisme. RFC 4271 décrit BGP, ses annonces, ses retraits et la sélection des routes entre systèmes autonomes. Une modification de contact peut ne changer aucune route. Inversement, un changement d’origine, de chemin ou de trafic peut avoir lieu sans événement RDAP simultané. La bonne chronologie sépare donc quatre pistes : registre, documents juridiques, données BGP et bascule effective des services.

La valeur de last changed reste réelle. Elle permet de cadrer une recherche d’archives, de comparer des instantanés et de demander qui disposait d’un accès authentifié. Mais l’absence d’un événement transfer dans cette réponse ne démontre pas l’absence de tout transfert commercial ou opérationnel. Elle signifie seulement que cet objet ne rapporte pas un tel événement.

La règle éditoriale tient en une phrase : nommer d’abord l’objet. « L’objet réseau a été modifié » respecte la preuve. « Le réseau a changé de mains » exige des pièces supplémentaires.

Sources