Résumé

  • L'AS398037 est enregistré au nom de NVIDIA Corporation sous le nom NVIDIA-NGC-NSV et annonce quatorze préfixes IPv4 plus un /48 IPv6. Il déclare une politique d'appairage ouverte et détient des ports à 100 Gbps à l'AMS-IX et au LINX LON1. C'est une présence d'interconnexion réelle, pas une formalité administrative.
  • La documentation DGX Cloud de la même entreprise attribue le calcul, le stockage et le réseau physiques aux fournisseurs de cloud partenaires et aux NVIDIA Cloud Partners. Celui qui détient les numéros et celui qui exploite le bâtiment ne sont pas la même partie, là précisément où les charges de travail tournent.

Un registre indifférent au récit produit

Un registre de numéros enregistre qui détient un bloc d'adresses et qui l'annonce. Il ne dit pas à quoi servent ces annonces, et la capitalisation boursière ne le concerne pas. C'est cette étroitesse qui fait sa valeur. Appliquée à une entreprise dont le rôle réseau est d'ordinaire considéré comme une évidence, elle scinde une supposition en deux faits distincts.

Le premier fait est le système autonome lui-même. L'AS398037 appartient à NVIDIA Corporation, identifiant d'organisation NC-1089, sous le nom de titulaire NVIDIA-NGC-NSV. L'enregistrement du système autonome indique une inscription le 14 octobre 2019, une dernière mise à jour le 2 mars 2021, un statut actif et alloué auprès de l'ARIN. La fiche de l'organisation porte d'autres dates — inscrite le 26 septembre 2019, actualisée le 25 novembre 2024 — parce que les deux objets sont tenus séparément.

Une réserve d'attribution doit accompagner ces champs. Le point d'accès RDAP de l'ARIN a renvoyé un type de réponse que cette vérification n'a pas pu afficher ; les données d'enregistrement ci-dessus proviennent donc d'une reproduction tierce du registre ARIN publiée par bgp.tools, et non d'un document lu au registre lui-même. Il s'agit d'une limite de consultation concernant la source, non d'un doute sur les chiffres.

Le nom porté sur la fiche constitue le premier signal discret. NGC est la pile logicielle de cloud GPU de NVIDIA. Le système autonome porte le nom du logiciel, pas celui d'un produit réseau, ni celui d'une région. Une entreprise qui voudrait vendre de la connectivité l'annoncerait dans l'objet que ses pairs consultent avant d'accepter une interconnexion.

Quatorze annonces et un plafond déclaré

L'observation du routage public montre quatorze annonces d'origine IPv4 : 8.44.54.0/24, 24.51.5.0/24, 24.51.6.0/23, 24.51.6.0/24, 24.51.7.0/24, puis neuf /24 consécutifs de 198.100.160.0/24 à 198.100.165.0/24, et de 198.100.171.0/24 à 198.100.173.0/24. En IPv6, une seule origine : 2604:1520:1000::/48.

Ce décompte mérite une note de bas de page plutôt qu'un effet de manche. Quatorze annonces ne font pas quatorze blocs distincts : le 24.51.6.0/23 recouvre deux des /24 listés. Qui veut le total d'adresses doit faire la soustraction lui-même.

L'annuaire d'appairage complète le tableau avec un autre type de chiffre. La fiche PeeringDB de l'AS398037 présente le réseau comme NVIDIA NGC NSV, organisation NVIDIA Corporation, également connu sous le nom Nvidia NGC. Elle déclare un type de réseau Enterprise, une portée géographique Global et une politique d'appairage ouverte, sans exigence de ratio, sans contrat obligatoire et sans condition de présence multiple. Elle affiche 30 préfixes IPv4, 1 préfixe IPv6 et un horodatage de fiche au 22 avril 2026.

Trente contre quatorze n'est pas une contradiction, et l'écart importe. La documentation opérateur de PeeringDB définit ces champs de préfixes comme le nombre maximal qu'un pair doit s'attendre à voir annoncé. Trente est un plafond que le réseau publie pour faciliter le paramétrage des sessions par ses pairs. Quatorze est ce qu'un collecteur a réellement observé. Un réseau qui invite ses futurs pairs à ne pas s'attendre à plus de trente préfixes ne décrit pas un backbone.

Ce que dit vraiment une politique ouverte à 100 Gbps

Le détail d'interconnexion est la partie qui résiste à la lecture tranquille d'une simple connectivité d'entreprise. PeeringDB recense des installations aux États-Unis, aux Pays-Bas, au Royaume-Uni, à Singapour et au Japon, et nomme des connexions AMS-IX et LINX LON1 à 100 Gbps chacune.

Un réseau d'entreprise qui touche cinq pays et achète des ports à 100 gigabits sur deux des maillages d'échange les plus denses d'Europe n'achète pas seulement un lien de bureau. Il paie la capacité de remettre du trafic à de nombreux réseaux directement, au lieu de tout faire passer par du transit acheté. Une politique ouverte sans exigence de ratio est celle d'un réseau qui veut rendre l'interconnexion facile — l'exact opposé d'un vendeur de transit qui protège sa marge, et l'exact opposé d'un réseau secret qui cache sa topologie.

Ces ports restent pourtant un actif conditionnel. Un port est une capacité en attente de sessions, et PeeringDB est un annuaire alimenté par ses utilisateurs : une politique déclarée ouverte ne prouve l'existence d'aucune session bilatérale précise. La page consultée n'exposait aucune ligne d'échange nommée dans sa section publique, ce qui est une limite de rendu et non une preuve d'absence.

Le tableau des amonts est plus fragile encore. L'observation suggère sept amonts IPv4 — Arelion, Lumen, Telecom Italia Sparkle, GTT, Cogent, PCCW et Telstra — avec Arelion seul visible en IPv6. La page de méthode de bgp.tools est d'une franchise rare sur ce point : BGP ne code pas les relations d'affaires, les étiquettes d'amont sont déduites des chemins observés à travers certains réseaux de premier rang et certains flux de serveurs de routes, et une relation peut simplement manquer quand un collecteur n'a pas la visibilité.

Les écarts entre collecteurs confirment la prudence. Un instantané Hurricane Electric affiché comme mis à jour le 18 août 2026 recense treize origines IPv4, une origine IPv6 et dix pairs observés, dont AS286 et AS1000 qui n'apparaissent pas dans la table de bgp.tools. Visibilité différente, jour différent, liste différente. Aucune page unique ne dit toute la vérité sur les interlocuteurs de ce réseau.

Les documents du fournisseur déplacent les serveurs

Placez maintenant le relevé de routage à côté du relevé de service : la séparation devient explicite.

Au lancement, le 21 mars 2023, NVIDIA décrivait DGX Cloud comme une location mensuelle de clusters dédiés, hébergés par des fournisseurs de cloud et commençant par OCI. L'hébergement Azure et l'extension à Google Cloud étaient alors présentés comme des projets à venir.

La page produit DGX Cloud actuelle s'ouvre différemment : elle présente le service comme l'environnement interne de NVIDIA pour développer des modèles, valider des architectures et faire tourner des charges de production chez les CSP et les NVIDIA Cloud Partners, tout en conservant des références à des offres via place de marché ou offres privées pour AWS, Google Cloud, Microsoft Azure et OCI. La page ne précise pas si ces sections commerciales restent en vigueur. Les deux lectures de cette page sont des inférences ; seul le texte est un fait.

La documentation du service géré est, elle, sans ambiguïté sur les responsabilités. Run:ai sur DGX Cloud, mise à jour le 27 février 2026, indique que les abonnements utilisent de la capacité GPU fournie par les partenaires CSP de NVIDIA, et que NVIDIA gère les composants du cluster, surveille le calcul, le stockage et le réseau hébergés chez le CSP, administre Kubernetes et coordonne la maintenance avec ce dernier.

Le document d'exigences est plus net encore. Les NVIDIA Requirements for AI Clouds, version 2.4, datées du 1er septembre 2026, définissent un NVIDIA Cloud Partner comme le fournisseur de cloud chargé de livrer et d'exploiter les capacités de calcul, de réseau, de stockage et de service géré applicables. Le document traite aussi les clusters DGX Cloud en environnement partenaire, le réseau CorpIT de NVIDIA et le stockage objet sur site de NVIDIA comme des ensembles séparés, joints par des exigences d'interconnexion privée — une architecture d'opérateurs liés mais distincts.

La répartition des responsabilités varie même selon l'offre. Le guide d'administration de cluster Slurm pour DGX Cloud, mis à jour le 17 janvier 2026, précise que NVIDIA provisionne et configure le cluster, tandis que la gestion et l'exploitation du cluster incombent au client, NVIDIA administrant le compte CSP, les ressources d'infrastructure et les contrôles de sécurité qui séparent le calcul, le réseau et le stockage entre locataires.

Les pièces ne sont pas le réseau

Dernière pièce du puzzle : le portefeuille réseau, celui que l'on confond le plus souvent avec la réponse. Spectrum-X associe des commutateurs Ethernet et des SuperNIC à un routage adaptatif qui écarte les gros flux des points de congestion, plus un contrôle de congestion fondé sur la télémétrie ; Spectrum-XGS étend la plateforme entre centres de données distribués. Chacune de ces capacités est une propriété d'un équipement et d'un logiciel que le client installe et exploite. Vendre les commutateurs, les cartes et la logique de contrôle de congestion n'équivaut pas à posséder le maillage sur lequel ils tournent.

Remettez les couches dans l'ordre et le tableau devient cohérent. NVIDIA détient les numéros, l'identité de routage et une présence d'interconnexion mondiale bien réelle. Elle administre un plan logiciel — Kubernetes, séparation des locataires, document d'exigences partenaires — qui pénètre dans des installations qu'elle ne possède pas. Ses partenaires livrent et exploitent le calcul, le stockage et le réseau physiques. Ses clients, dans au moins une configuration documentée, exploitent eux-mêmes le cluster.

Voilà pourquoi la formule habituelle trompe. Un fournisseur dont le silicium transporte le trafic est-ouest de l'IA est une entreprise d'infrastructure au sens commercial fort, mais le système autonome n'est pas un joyau prouvant l'exploitation d'un backbone. C'est un réseau modeste, à l'appairage ouvert, portant un nom de marque : la couche d'adressage d'une entreprise dont le levier réel est la conception et le plan logiciel, pas les baies.

Ce que le dossier tranche et ce qu'il laisse ouvert

Quatre limites méritent d'être posées. Le document d'enregistrement de l'ARIN n'était pas lisible dans cette vérification, les champs du système autonome reposent donc sur une reproduction tierce. La page DGX Cloud ne permet pas d'établir si les textes conservés pour AWS, Google Cloud, Azure et OCI décrivent des offres actives ou des éléments hérités. La déclaration d'appairage ouvert de PeeringDB ne prouve aucune session bilatérale. Les identités des amonts sont déduites de chemins de routage, pas lues dans des contrats.

La part d'hébergement de chaque partenaire et l'éligibilité commerciale actuelle n'ont pas été vérifiées ici.

Aucune de ces lacunes ne touche la conclusion centrale, qui ne demande que deux documents lus en entier : une reproduction de registre qui nomme NVIDIA titulaire de l'AS398037, et la documentation de service de NVIDIA elle-même, qui nomme des partenaires exploitants du calcul, du stockage et du réseau. Les adresses et les baies ont des propriétaires différents parce que ce sont deux choses différentes.