Résumé

  • La page du registre du commerce estonien consacrée au numéro d'immatriculation 14476114 affichait, le 18 octobre 2026, la dénomination Puzl Cloud OÜ et classait GPU Computing OÜ sous la mention « Invalid names ».
  • L'objet d'organisation RIPE qui porte ce même numéro, 14476114, indiquait toujours GPU Computing OU, avec une date de dernière modification au 13 mai 2026.
  • Le système autonome AS57063 annonçait le 18 octobre 2026 les deux mêmes préfixes que deux semaines plus tôt : 213.5.72.0/24 et 2001:67c:f74::/48.

Un seul numéro, deux noms, aucune contradiction

La fiche du registre du commerce estonien relative au numéro 14476114 ne se lit pas comme un portrait d'entreprise. Telle qu'elle a été consultée le 18 octobre 2026, la page du registre du commerce estonien consacrée au numéro 14476114 commence par un nom, Puzl Cloud OÜ, suivi du numéro entre parenthèses, puis porte plus bas une ligne dont la brièveté masque l'importance : sous l'intitulé « Invalid names », le registre inscrit GPU Computing OÜ. Lu simplement, c'est un registre qui indique au lecteur lequel des noms en circulation pour cette personne morale appartient au passé, et lequel il ne tient plus pour valide.

Il s'agit d'une affirmation précise et vérifiable sur un nom. C'est aussi la seule chose que le passage conservé établit. Les champs qu'un extrait complet de registre afficherait d'ordinaire — l'activité de la fiche, le code d'activité déclaré, l'identité des dirigeants — n'étaient pas présents dans le texte retenu et ne sont donc affirmés nulle part ici. Ce qui compte pour le raisonnement est plus étroit et plus difficile à contester : interrogé sur 14476114, le registre répond Puzl Cloud OÜ et signale l'autre nom.

La base de données RIPE répond autrement à la même question. Interrogée sur AS57063 le même jour, elle renvoie quatre objets, dont l'objet d'organisation ORG-GCO2-RIPE. Son attribut org-name indique toujours GPU Computing OU. Son pays est EE, son reg-nr est 14476114, et son adresse correspond à un immeuble de Tallinn, Tartu mnt 83-701. Sa date de dernière modification est le 13 mai 2026, soit environ cinq mois avant la consultation de la page du registre et plus de cinq ans après la création de l'objet, le 9 décembre 2020. La réponse complète se trouve dans l'enregistrement RIPE pour AS57063.

Les deux documents décrivent la même personne morale — le numéro d'immatriculation est identique — et lui donnent des noms courants différents. Aucun des deux n'est manifestement faux. Un objet de registre consigne une attribution, pas l'état civil d'une société en continu ; le registre estonien consigne une personne morale, pas un registre de routage. Ils ont le droit d'être en désaccord, et ce jour-là ils l'étaient.

L'enregistrement de routage n'a jamais été indexé sur le nom

La partie de l'enregistrement qui n'a pas dérivé est celle qui transporte du trafic. L'objet aut-num d'AS57063 porte un as-name égal à PUZL-AS. Il a été créé le 2 novembre 2021 et modifié pour la dernière fois le 8 novembre 2024. L'identité de routage de l'exploitant est donc une chaîne dérivée de « puzl » depuis l'existence de l'objet, dans un enregistrement antérieur de deux ans et demi à la dernière modification de l'objet d'organisation.

L'objet de rôle raconte la même histoire depuis une date plus ancienne. GCO8-RIPE est nommé GPU Computing OU, partage l'adresse du Tartu mnt et porte une adresse de signalement sur le domaine puzl.ee — c'est le domaine, non la raison sociale, qui supporte la couche de contact. Ses dates de création et de dernière modification sont identiques : 9 décembre 2020, une seconde après la création de l'objet d'organisation, ce qui correspond à une session unique d'enregistrement produisant plusieurs objets. L'année 2020 mérite d'être gardée en tête.

Quelle qu'ait été l'histoire sociale depuis, le chemin de contact fondé sur le domaine existait avant l'attribution du numéro d'AS.

Le numéro lui-même n'a changé de main à aucun moment visible. Le 18 octobre 2026, le point d'accès as-overview de RIPEstat renvoyait le titulaire « PUZL-AS GPU Computing OU » et la valeur announced true — une chaîne qui se lit exactement comme l'as-name et l'org-name réunis par un espace, ce qui est l'allure d'un service de synthèse qui concatène deux champs qu'il détient plutôt que de résoudre une raison sociale à jour. Le statut du point d'accès était ok, la réponse n'était pas mise en cache, et la fenêtre d'interrogation correspondait au 18 octobre 2026 à 16h00 UTC : as-overview RIPEstat pour AS57063.

Un lecteur qui s'arrête à cette seule surface apprendrait le numéro d'AS, deux noms à la fois, et aucun désaccord. La contradiction n'apparaît qu'une couche plus bas, dans les deux documents sources qui portent les deux noms.

Deux préfixes, un angle mort explicitement déclaré

L'empreinte opérationnelle à la même date était réduite, stable et identique à celle de la quinzaine précédente. Le point d'accès announced-prefixes renvoyait exactement deux préfixes pour AS57063 : le préfixe IPv4 213.5.72.0/24 et le préfixe IPv6 2001:67c:f74::/48. Tous deux portent une chronologie continue unique du 4 octobre 2026 au 18 octobre 2026, et la valeur latest_time de la réponse est le 18 octobre 2026 à 16h00 UTC. Le détail figure dans la réponse announced-prefixes de RIPEstat.

Deux préfixes constituent une observation réelle et bornée, et la borne est énoncée par le service lui-même. La réponse comprend un message d'information précisant que les résultats excluent les routes de très faible visibilité, à savoir celles vues par moins de dix pairs complets du réseau RIS. Cette phrase fait beaucoup de travail. Elle signifie que le résultat à deux préfixes correspond à ce que voit un point d'observation bien connecté, et non à l'inventaire complet de tout ce qu'un réseau pourrait annoncer par un chemin plus ténu.

Quiconque traite deux préfixes comme l'espace d'adressage total de l'exploitant lit à côté de la réserve inscrite dans le même document.

Le rôle réel de ces préfixes — savoir si 213.5.72.0/24 transporte du trafic client, de l'infrastructure interne ou une bordure de service — n'est pas établi par une annonce. Un préfixe dans la table globale est l'énoncé qu'une origine est joignable, et rien de plus.

La seule question que les documents ne tranchent pas

L'autorisation d'origine est la question suivante, et c'est celle qui a échoué. Le point d'accès de validation RPKI de RIPEstat pour AS57063 n'a renvoyé aucun corps de réponse exploitable le 18 octobre 2026 ; la réponse conservée enregistre un échec de récupération avec un extrait nul et ne porte aucun verdict : réponse de validation RPKI RIPEstat.

La distinction mérite d'être posée, car il est facile de confondre deux choses. Un service de validation qui ne renvoie aucun résultat ne dit rien sur le fait que les préfixes soient signés. Il dit que la réponse n'a pas pu être lue. Traiter un point d'accès illisible comme un préfixe non signé, ou comme un préfixe propre, revient à inventer un fait dans la direction que le lecteur préfère.

L'énoncé honnête est que l'autorisation d'origine pour AS57063 restait non lue au 18 octobre 2026, et que le document qui la trancherait — un résultat de validation nommant les certificats de ressources couvrant 213.5.72.0/24 et 2001:67c:f74::/48 — n'a pas été obtenu.

Un dernier fil reste pendant. L'objet aut-num porte un attribut sponsoring-org pointant vers ORG-SDNS7-RIPE, un objet d'organisation qui n'a pas été consulté pour cet article. Une organisation de parrainage sur une attribution constitue un fait structurel sur la manière dont la ressource a été obtenue, et c'est le genre d'élément qui explique une attribution plus complètement qu'un champ de nom ne le fera jamais. Sa présence est documentée ; son identité ne l'est pas.

Ce que la divergence coûte réellement

La conclusion tentante est qu'il y a eu négligence. Les documents ne la soutiennent pas, et une explication plus terne leur convient mieux. Un objet de registre est modifié quand un exploitant a une raison de le modifier : nouveau mainteneur, adresse changée, demande de ressource. Un changement de raison sociale est une raison de déposer auprès d'un registre du commerce, obligation légale assortie d'une taxe et d'un délai. Rien dans cette obligation ne crée le devoir de toucher un objet de RIR dont le champ de nom n'est lu par personne à ce moment-là.

L'omission sur le champ de nom est l'état par défaut, non une décision.

Ce que cet état par défaut coûte n'est pas supporté par l'exploitant. Il est supporté par tous ceux qui, en aval, traitent un nom comme une clé. Un registre fournisseurs qui recense une société au nom évocateur de GPU et l'y cherchera ne trouvera pas la fiche du registre du commerce, puisque le registre répond à un autre nom. Une contrepartie qui filtre une entité contractante par sa dénomination commerciale ne fera pas correspondre l'objet d'organisation RIPE, car le numéro est là et le nom ne l'est pas. Une cartographie concurrentielle bâtie sur des raisons sociales portera deux entrées, ou aucune.

La correction peu coûteuse est sans éclat et ne dépend d'aucun document non lu. Indexer l'enregistrement sur le numéro d'immatriculation et sur le numéro d'AS, qui ont tous deux survécu au changement de nom, et conserver le nom comme une observation datée plutôt que comme un identifiant : cette entité s'appelait X lors d'une vérification au jour Y. Le numéro est stable, le code est stable, les deux préfixes se sont maintenus au moins sur la quinzaine observée. Le nom est le champ qui bouge, et il devrait être traité comme la colonne la moins faisant autorité de la ligne — y compris dans la fiche du répertoire BTW consacrée à AS GPU Computing OU, qui hérite du nom antérieur au changement exactement comme l'objet de registre le porte.