Résumé

  • AS10209 est bien annoncé sur l'internet mondial: il rend visibles 198.182.50.0/23 ainsi que les deux routes plus précises 198.182.50.0/24 et 198.182.51.0/24, soit 512 adresses IPv4 uniques et non 1 024.
  • Le /23 apparaît avec AS4637 immédiatement avant AS10209, tandis que les deux /24 apparaissent avec AS3356; cette disposition peut servir une préférence d'entrée et un repli logique, mais elle ne démontre ni deux chemins physiques ni une capacité suffisante en cas de panne.
  • Le nom « Japan HUB and centres de données » reste une description de registre rattachée à Synopsys, pas la preuve d'une société autonome, d'un bâtiment exploité, de baies commercialisées, d'une puissance électrique, d'un refroidissement, d'une bande passante ou d'une reprise testée.

Un nom d'infrastructure qui dépasse la preuve disponible

« Japan HUB and centres de données » donne immédiatement l'impression d'un lieu. Les mots suggèrent un point de concentration, des interconnexions, une salle équipée et, peut-être, une offre destinée à des clients. Or le dossier public ne permet pas de franchir cette distance entre un libellé administratif et un actif physique. Il établit d'abord l'existence d'un numéro de système autonome japonais, AS10209, dont le nom enregistré est Synopsys-AS-JP-AP. Il relie ensuite ce numéro à Synopsys. Il montre enfin que ce réseau annonce effectivement des adresses. Ces trois constats sont solides. Aucun ne transforme toutefois la description du registre en fiche technique de centre de données.

La distinction est décisive pour un acheteur d'infrastructure. Un enregistrement de ressource internet répond à des questions de délégation, de responsabilité administrative et de contact. Il ne garantit pas que chaque mot de sa description soit une marque commerciale actuelle, le nom juridique d'une entreprise ou la désignation d'un immeuble. Le protocole BGP, de son côté, échange des informations de joignabilité et applique des choix de routage. Il ne renseigne pas, à lui seul, la surface d'une salle, le nombre de baies, la puissance d'un raccordement électrique ou l'état d'un groupe électrogène.

La visibilité d'une route et la disponibilité d'une capacité physique sont deux catégories de preuve différentes.

Le cas d'AS10209 est précisément intéressant parce que la première catégorie est réelle et assez nette, tandis que la seconde demeure presque vide. L'aperçu RIPEstat considère le système autonome comme annoncé. Cloudflare Radar reconnaît également ce petit réseau associé au Japon et à une activité d'entreprise. Cela suffit pour dire que l'objet réseau n'est pas une coquille entièrement inactive. Cela ne suffit pas pour annoncer un « hub » exploitable par des tiers, encore moins pour chiffrer ce qu'il pourrait accueillir.

Le bon point de départ consiste donc à lire le nom comme un indice historique ou opérationnel, puis à demander ce que chaque source prouve séparément. Le registre APNIC prouve l'identité publiée. Les observations de routage prouvent une présence logique à l'instant examiné. Les pages de Synopsys décrivent une entreprise d'ingénierie et ses bureaux. Les documents japonais donnent des critères généraux applicables aux centres de données. Aucun document public ne relie toutes ces pièces en une chaîne démontrant un service de colocation ou une installation indépendante appelée Japan HUB and centres de données.

Cette prudence n'implique pas que le lieu n'existe pas, ni qu'aucune salle technique ne se trouve derrière le réseau. Elle signifie seulement que le public ne dispose pas des éléments nécessaires pour l'affirmer. L'absence d'une fiche de capacité n'est pas une preuve d'absence matérielle. Mais elle interdit de présenter une capacité supposée comme un fait. Dans un marché où les mots « hub » et « centres de données » peuvent être pris pour des promesses de redondance, cette limite est plus instructive que le libellé lui-même.

L'identité mène à Synopsys, pas à un exploitant autonome vérifié

Les liens d'identité convergent vers Synopsys. L'objet APNIC d'AS10209 nomme Synopsys comme titulaire associé et porte le code pays JP. L'objet d'organisation APNIC ORG-SA28-AP indique Synopsys au Futako Tamagawa Rise Office. Du côté d'ARIN, l'adresse 198.182.50.0 appartient à une allocation directe plus large, SYNOPSYS-US03-NET, couvrant 198.182.32.0 à 198.182.63.255 et enregistrée au nom de Synopsys Inc. L'objet d'organisation ARIN fournit également l'identité de Synopsys et ses contacts de réseau. Le rattachement institutionnel du petit bord AS10209 est donc bien étayé.

La frontière juridique et commerciale est pourtant plus étroite que le nom du répertoire ne le laisse croire. La présentation japonaise de la société désigne Nihon Synopsys G.K. et décrit des activités d'automatisation de la conception électronique, de propriété intellectuelle pour semi-conducteurs, de soutien et de conseil. La présentation du groupe parle d'ingénierie allant du silicium aux systèmes, de conception, de simulation et d'analyse. Le rapport annuel 2025 de Synopsys apporte le contexte formel du groupe et de ses risques, sans faire de Japan HUB and centres de données un secteur autonome déclaré.

Ces éléments permettent d'écarter plusieurs raccourcis. On ne peut pas présenter Japan HUB and centres de données comme la raison sociale vérifiée d'une société distincte. On ne peut pas attribuer à Nihon Synopsys G.K. une offre publique de colocation sur la seule foi de l'intitulé APNIC. On ne peut pas dire que Synopsys commercialise des kilowatts, des baies ou des salles via AS10209. On ne peut pas non plus transformer Telstra International ou Lumen, dont les numéros apparaissent dans les chemins BGP, en copropriétaires de l'objet. Une adjacence réseau n'est ni un contrat publié ni un titre de propriété.

Il faut aussi résister à une autre confusion: l'allocation ARIN de la maison mère est beaucoup plus large que les routes visibles d'AS10209. Le fait que 198.182.50.0 se trouve dans un ensemble d'adresses attribué à Synopsys Inc. confirme la filiation de la ressource. Il ne signifie pas que toute cette allocation soit utilisée au Japon, qu'elle soit annoncée par AS10209 ou qu'elle corresponde à des serveurs présents dans un même bâtiment. À l'instant observé, la surface publique de ce système autonome se limite au /23 et à ses deux /24 constitutifs.

La qualification la plus exacte est donc celle d'une bordure d'entreprise liée à Synopsys. Cette formulation reconnaît la réalité du réseau sans inventer le produit qui manquerait au dossier. Elle laisse aussi ouvertes des questions opérationnelles: quelle entité signe les contrats de connectivité, quelle équipe gère les routeurs au quotidien, et quel bureau ou site tiers les accueille ? Les enregistrements administratifs ne tranchent pas ces points.

Une multinationale peut répartir la propriété des adresses, les contacts, l'exploitation locale et l'hébergement physique entre plusieurs entités sans que la vue publique en donne le détail.

Pour le lecteur, cette frontière change l'objet de l'enquête. Il ne s'agit pas de mesurer un exploitant de centre de données déjà établi, mais de déterminer ce qui se cache sous une description ambitieuse attachée à un réseau d'entreprise. L'association à Synopsys est de confiance élevée. L'existence d'une activité de colocation autonome est, elle, non démontrée. Confondre les deux produirait une image plus simple, mais faussement précise.

D'Oimachi à Futako Tamagawa, une trace administrative plutôt qu'une carte technique

Le dossier contient deux adresses tokyoïtes. Le texte plus ancien de l'objet aut-num renvoie à 1-28-1 Ooi, dans l'arrondissement de Shinagawa, et conserve une mention d'Oimachi. Les champs concernés ont été modifiés pour la dernière fois en 2020. L'objet d'organisation APNIC, dont une modification date de 2023, pointe au contraire vers le Futako Tamagawa Rise Office, 2-21-1 Tamagawa, dans l'arrondissement de Setagaya. Les pages actuelles de Synopsys placent elles aussi le bureau de Tokyo à Futako Tamagawa et mentionnent séparément Osaka et Yokkaichi.

Cette divergence raconte vraisemblablement une évolution de l'adresse administrative ou un décalage entre plusieurs objets de registre. Elle ne révèle pas deux implantations actives d'AS10209. Rien dans les éléments consultables n'associe un routeur de bord à Oimachi, ni un autre à Futako Tamagawa. Aucun identifiant d'installation, numéro de circuit, document de brassage ou relevé d'interconnexion ne relie le système autonome à l'une de ces adresses. Tracer une ligne de redondance entre les deux quartiers serait donc fabriquer une topologie absente des sources.

La page consacrée au lieu de travail de Synopsys à Tokyo renforce cette limite. Elle présente Futako Tamagawa comme un bureau avec réception, espaces de travail, zones de formation et lieux de pause. Elle mentionne une certification LEED Gold. Cette présentation ne dit pas qu'il n'existe aucune pièce technique sur le site: une page de carrières n'a pas vocation à inventorier chaque équipement. Mais elle ne montre pas non plus une salle informatique, un local opérateurs ou une installation de colocation.

La certification du lieu de travail ne doit pas devenir, par glissement, une certification de disponibilité électrique ou de refroidissement pour AS10209.

Le contexte géographique doit donc rester à plusieurs niveaux. Le Japon est la géographie de registre du système autonome. Tokyo est le contexte administratif historique et actuel. Oimachi et Futako Tamagawa sont des adresses présentes dans les documents, pas des coordonnées vérifiées pour les équipements. Osaka et Yokkaichi sont des bureaux déclarés par Synopsys, pas des sites de secours établis pour ce réseau. L'allocation ARIN au nom d'une société américaine ne géolocalise pas davantage les adresses actives.

Les mêmes règles valent pour les grands opérateurs visibles dans les chemins. Leurs cartes montrent qu'ils ont une présence au Japon et à Tokyo, ainsi qu'une portée internationale. Elles ne montrent pas le point de remise d'AS10209. Elles ne désignent ni l'immeuble, ni le local d'arrivée, ni les fourreaux, ni le parcours métropolitain. Une carte de marché à l'échelle d'un pays ou d'un continent ne peut pas répondre à une question qui se joue à l'entrée d'un bâtiment.

Le niveau de confiance sur la localisation physique demeure donc faible. Il est raisonnable de parler d'un contexte japonais et tokyoïte. Il ne l'est pas d'assigner les routeurs à un centre précis, à un hôtel de télécommunications, à un point d'échange ou à un bureau. Cette case vide est essentielle pour juger la résilience: tant que l'emplacement n'est pas connu, aucune menace de bâtiment, d'accès ou de desserte ne peut être reliée avec précision à l'objet.

Trois annonces, mais seulement 512 adresses IPv4 uniques

La partie la plus mesurable du dossier tient en trois lignes de routage: 198.182.50.0/23, 198.182.50.0/24 et 198.182.51.0/24. RIPEstat les observe toutes comme annoncées par AS10209. Les deux /24 découpent exactement l'espace couvert par le /23. Ils ne s'ajoutent donc pas à lui. Le total unique reste celui du /23, soit 512 adresses IPv4. Compter trois préfixes comme trois blocs indépendants conduirait à doubler artificiellement la taille pour atteindre 1 024, ce que la structure des routes ne permet pas.

Cette arithmétique simple protège contre une erreur plus large: l'adresse routée n'est pas une unité de capacité de centre de données. Une adresse peut ne pas être utilisée, être réservée, servir à une passerelle, être partagée par plusieurs usages ou se trouver derrière un mécanisme qui masque le nombre réel de machines. Les réponses de type « network info » confirment que 198.182.50.1 relève du premier /24 et que 198.182.51.1 relève du second, tous deux avec AS10209 comme origine. Elles ne disent pas à quel hôte ces adresses correspondent, où cet hôte se trouve, ni quelle charge il peut soutenir.

Le statut de routage fournit d'autres bornes utiles. À l'instant de la mesure, trois préfixes IPv4 sont visibles et les pairs IPv4 RIS affichés les voient. Aucun préfixe IPv6 public n'apparaît pour AS10209. La visibilité complète dans cet ensemble de mesure indique une propagation large au moment considéré, pas une disponibilité absolue depuis tous les réseaux de l'internet. Elle ne mesure ni le débit, ni la perte de paquets, ni la latence, ni la disponibilité d'une application située derrière la bordure.

L'historique RIPEstat permet de replacer la surface actuelle dans le temps et montre des périodes de visibilité ainsi que d'anciennes plages associées au système autonome. Cet historique est précieux pour confirmer que le routage peut évoluer. Il ne donne pas les raisons des changements et peut omettre des routes à très faible visibilité. Il serait donc excessif d'en déduire une chronologie des déménagements, des contrats ou des incidents.

Deux signaux indépendants donnent une impression d'échelle modeste. Cloudflare Radar classe AS10209 comme un petit réseau d'entreprise. APNIC Labs estimait 246 utilisateurs au Japon dans son instantané du 2 avril 2026. Ce nombre n'est ni une liste de salariés, ni un décompte d'abonnés, ni un inventaire de postes ou de serveurs. Il dépend d'une méthode d'observation et d'une date. Son intérêt est de corroborer une petite présence mesurée, non de convertir un échantillon en capacité commerciale.

La bonne phrase de capacité logique est donc volontairement limitée: 512 adresses IPv4 uniques sont annoncées par AS10209 au moyen d'un /23 et de deux /24 plus précis; aucun IPv6 public n'est visible dans l'observation retenue. Tout ajout concernant les machines, les clients, les services ou les performances demanderait une autre preuve. Même à l'intérieur du réseau, le nombre d'adresses attribuées ou réellement actives reste inconnu.

Le partage entre AS3356 et AS4637 ressemble à une stratégie d'entrée

La topologie observable devient plus intéressante lorsqu'on distingue les routes par longueur. Pour le préfixe couvrant 198.182.50.0/23, les chemins affichés placent AS4637 immédiatement avant AS10209. Pour 198.182.50.0/24 et 198.182.51.0/24, ils placent AS3356 immédiatement avant AS10209. AS4637 correspond au réseau de Telstra International et AS3356 à celui de Lumen. La comparaison de cohérence de RIPEstat retrouve ces deux voisins dans le routage actuel.

Cette disposition offre une lecture plausible. Sur l'internet, une route plus précise est généralement préférée à une route qui couvre un espace plus vaste. Tant que les deux /24 sont annoncés et reçus, le trafic entrant vers leurs adresses peut donc suivre les chemins associés à AS3356. Le /23 associé à AS4637 peut conserver une joignabilité moins précise. Si les deux /24 disparaissent proprement, le /23 pourrait alors recueillir le trafic destiné aux 512 adresses et jouer le rôle d'un repli.

Le mot « pourrait » porte ici tout le poids de l'analyse. Les observations montrent des chemins, pas l'intention documentée de l'exploitant. Elles ne révèlent pas la politique de sortie d'AS10209, le contenu des contrats, le débit des ports ou le nombre de routeurs. Elles ne montrent pas non plus si les annonces sont conditionnées à la santé des applications. Le dessin logique est compatible avec une ingénierie de trafic réfléchie, mais aucune épreuve publique n'en démontre le comportement en panne.

Plusieurs situations peuvent rompre le scénario idéal. Si les deux /24 restent annoncés alors qu'un pare-feu, une application ou un lien situé en aval ne répond plus, les réseaux distants peuvent continuer à choisir les routes les plus précises et envoyer le trafic vers une impasse. Si un seul /24 disparaît, une moitié de l'espace peut emprunter le /23 tandis que l'autre conserve son chemin habituel. Un contrôle portant sur une seule adresse pourrait alors annoncer que le réseau est accessible tout en manquant une panne partielle.

Si le /23 disparaît mais que les /24 restent présents, la connectivité peut continuer sans disposer du repli apparent.

La capacité du chemin AS4637 sous contrainte est également inconnue. Un itinéraire de secours n'est utile que s'il accepte le volume reporté, si les filtres autorisent les routes attendues, si l'état des pare-feu est compatible et si les services restent accessibles. Aucune donnée publique n'indique le débit engagé, l'utilisation normale ou la marge disponible. Il n'existe pas non plus de résultat montrant le délai de convergence après un retrait.

Le niveau de confiance est ainsi moyen à élevé pour le motif observé, mais faible pour son résultat opérationnel en situation dégradée. On peut décrire une multiconnexion logique et un mécanisme de préférence vraisemblable. On ne peut pas vendre ce motif comme une garantie de continuité. Cette nuance est le cœur du dossier: la structure BGP est la meilleure preuve disponible, mais elle s'arrête précisément avant les caractéristiques qui déterminent l'expérience réelle d'un utilisateur lors d'une panne.

Une politique enregistrée en retard et une assurance d'origine non positive

L'objet APNIC plus ancien déclare encore des relations de routage avec AS1 et AS1239. Les observations actuelles mettent plutôt en avant AS3356 et AS4637. La comparaison RIPEstat entre registre et BGP rend ce décalage explicite. Il peut s'agir d'un texte ancien, d'une politique volontairement incomplète ou d'une relation qui ne se manifeste plus dans la vue retenue. Quelle qu'en soit la cause, les lignes publiées dans l'objet de 2020 ne doivent pas servir de carte opérationnelle actuelle.

Ce décalage a une conséquence pratique pour l'évaluation. Une fiche de registre peut rester utile pour identifier un titulaire et retrouver des contacts, tout en étant insuffisante pour décrire les voisins réellement vus sur le réseau. L'acheteur doit traiter la configuration observée et la déclaration administrative comme deux couches différentes, puis demander pourquoi elles divergent. Une mise à jour du texte ou une explication officielle réduirait l'incertitude, mais elle ne démontrerait toujours pas le chemin physique.

Les trois contrôles RPKI examinés ajoutent une autre limite. Pour 198.182.50.0/23, 198.182.50.0/24 et 198.182.51.0/24, RIPEstat renvoie l'état unknown et n'affiche pas de ROA qui autoriserait positivement l'origine AS10209 au moment de la consultation. Cet état ne signifie pas que les routes sont invalides. Il indique qu'aucune autorisation d'origine positive n'a été trouvée par le contrôle retenu. Le résultat peut évoluer si un ROA est publié ou si les caches changent.

La norme sur la vérification d'origine BGP aide à interpréter ce point sans l'exagérer. RPKI peut relier un préfixe à une origine autorisée, mais ne certifie pas le chemin entier, le circuit physique ou le service situé derrière la route. Même un état positif ne prouverait pas qu'une salle dispose de deux alimentations électriques ou que deux fibres entrent par des façades séparées. Inversement, l'état unknown n'empêche pas les routes d'être largement propagées, comme le montre leur visibilité actuelle.

Il faut donc tenir ensemble deux constats. Le plan de contrôle est opérationnel au sens où les annonces existent et atteignent les observateurs. La preuve publique de gouvernance du routage est moins complète: le texte enregistré ne reflète pas les voisins actuels, et l'autorisation d'origine n'est pas positive dans l'instantané. Ces lacunes ne rendent pas AS10209 fictif. Elles créent des questions de diligence sur la tenue des objets, la protection des origines et les procédures de changement.

Une réponse solide de l'exploitant préciserait les relations actuelles, la raison du partage entre l'agrégat et les routes plus précises, les conditions de retrait, et la politique RPKI recherchée. Elle préciserait aussi qui reçoit les alertes et qui peut agir lorsqu'une annonce devient incorrecte. Le public ne possède aucun de ces détails. Le dossier doit par conséquent rester descriptif: il constate les chemins et les états observés, sans attribuer une maturité opérationnelle que les sources ne mesurent pas.

Deux réseaux amont ne font pas deux chemins physiques

Voir deux numéros de système autonome immédiatement en amont est un signal de diversité logique. Ce n'est pas une attestation de diversité physique. Les circuits associés peuvent, en théorie, arriver dans le même bâtiment, traverser la même entrée, emprunter un même fourreau métropolitain, partager un opérateur d'accès local ou dépendre du même domaine électrique. Les chemins BGP ne contiennent pas ces informations. Aucune source publique du dossier ne permet de savoir si l'une de ces dépendances communes existe ou non pour AS10209.

Les cartes de Lumen et de Telstra International ne comblent pas ce vide. La carte de Lumen représente une présence mondiale et avertit que les itinéraires exacts peuvent changer; elle ne distingue pas nécessairement les segments détenus, loués ou utilisés sous droit d'usage. La carte de Telstra montre le Japon, Tokyo, des systèmes internationaux, des points de présence et des symboles de centres de données, tout en indiquant que la disponibilité des services peut évoluer. Ni l'une ni l'autre ne marque une remise AS10209, un bâtiment client ou une paire de circuits précise.

Il serait donc trompeur de superposer la carte du trafic logique aux cartes des opérateurs puis de dessiner deux lignes indépendantes jusqu'à un site supposé. Une présence nationale ne prouve pas l'achat d'un service donné. Une présence dans une ville ne prouve pas le point de remise. Un chemin AS n'établit pas qu'il n'existe aucun intermédiaire commercial. Et deux noms mondiaux ne garantissent pas que la dernière portion locale soit séparée.

La distinction devient critique au moment d'une coupure. Si les deux relations atteignent un même routeur, la panne de ce routeur annule l'avantage logique. Si elles ont un pare-feu en commun, une erreur d'état ou de configuration peut toucher les deux. Si elles empruntent la même entrée d'immeuble, un incident d'accès peut les interrompre ensemble. Si leurs équipements dépendent d'une même alimentation ou d'un même refroidissement, la diversité du transit ne protège pas d'un événement de salle. Ces scénarios sont crédibles en général, mais aucun n'est établi comme le dessin réel d'AS10209.

La preuve qui réduirait l'incertitude devrait être beaucoup plus précise: identifiants de circuits, bâtiments de remise, salles de rencontre, lettres de diversité, parcours métropolitains, entrées distinctes, routeurs séparés, domaines électriques séparés et résultats d'essais. Un enregistrement sur un point d'échange ou un document d'interconnexion rattaché à AS10209 aiderait également. Rien de tel n'apparaît dans le dossier public.

La formulation défendable reste « logiquement multiconnecté ». Elle reconnaît le motif AS3356/AS4637 sans lui attribuer une architecture de génie civil. Elle évite aussi un faux sentiment de sécurité: le nombre de voisins BGP est un indicateur utile, mais la résilience dépend du plus petit composant commun situé sous ces voisins. Tant que ce composant n'est pas identifié, le degré réel d'indépendance reste inconnu.

Aucune baie, aucun mégawatt et aucun débit public à additionner

La seule quantité opérationnelle propre au sujet est celle des 512 adresses IPv4 uniques routées. Tous les autres champs de capacité attendus pour un centre de données sont absents. Aucun document public ne donne le nombre de baies conçues, installées, alimentées, occupées, réservées ou encore libres. Aucune surface brute ou surface informatique n'est publiée. Aucune densité par baie n'est fournie. Il n'existe pas de valeur de puissance informatique installée, mise en service ou utilisée.

Le volet électrique est tout aussi vide. Le dossier ne nomme ni tension de raccordement, ni puissance disponible, ni sous-station, ni nombre de départs. Il ne décrit pas la topologie des onduleurs, l'autonomie des batteries, la puissance des groupes électrogènes, la réserve de carburant ou les essais en charge. Le refroidissement n'est associé à aucune puissance thermique, aucune enveloppe de fonctionnement, aucune redondance et aucun résultat d'essai intégré.

Du côté des télécommunications, on ne connaît ni la vitesse des ports, ni le débit engagé, ni l'utilisation moyenne ou maximale, ni la marge en panne. Le motif BGP indique des relations de joignabilité, pas leur taille. Une route couvrant 512 adresses peut être transportée sur des liens de capacités très différentes. Le nombre d'adresses ne permet aucune conversion honnête vers des gigabits, des serveurs, des sessions ou des clients.

L'absence se poursuit dans les couches de service. Aucun catalogue public ne décrit une offre sous le nom Japan HUB and centres de données. Aucun client de colocation n'est nommé. Aucun réseau aval, aucune liste de domaines hébergés et aucun inventaire de calcul ou de stockage ne sont établis. L'estimation APNIC Labs de 246 utilisateurs et le classement Cloudflare ne peuvent pas être traités comme des ventes, des employés ou des charges installées. Ils mesurent un signal selon leur propre méthode.

Il faut également séparer plusieurs états que le langage commercial confond souvent. Une adresse peut être allouée sans être annoncée. Une route peut être annoncée sans que le service applicatif réponde. Un équipement peut être installé sans être alimenté. Une baie peut être alimentée mais déjà réservée. Une capacité peut fonctionner en temps normal tout en étant inutilisable après la perte d'un lien, d'une alimentation ou d'un groupe froid. Le dossier ne fournit pas les informations qui permettraient de passer d'un état à l'autre.

Le PUE, parfois employé comme raccourci de performance, n'est pas davantage disponible. Les recommandations du Japan centres de données Council insistent sur un périmètre de mesure, une méthode de calcul et une agrégation définis. Sans compteur propre au site, période et frontière de mesure, aucune valeur ne peut être attribuée. Une mention LEED Gold sur un bureau n'autorise pas une estimation de PUE pour un espace technique non identifié.

La conclusion de capacité doit rester sèche: 512 adresses IPv4 uniques sont publiquement routées. La bande passante, les baies, la surface, la puissance, le refroidissement, le calcul, le stockage, les clients et la marge de reprise sont inconnus. Cette phrase peut sembler moins spectaculaire qu'un tableau de capacités. Elle est pourtant la seule qui respecte la différence entre un réseau visible et un centre de données mesurable.

Le contexte japonais de l'électricité et du refroidissement ne certifie pas ce sujet

Les documents japonais donnent une grille utile pour comprendre ce qu'il faudrait démontrer si Japan HUB and centres de données désignait réellement une installation. Le standard du Japan centres de données Council couvre notamment l'alimentation commerciale, la production de secours, les onduleurs, la climatisation, le risque sismique, le bâtiment et les communications. Un autre document du conseil distingue l'environnement d'un centre de données par le refroidissement dédié, la gestion des allées chaudes et froides et la présence d'onduleurs.

Ce sont des critères d'évaluation, pas des caractéristiques attribuées à AS10209.

Le travail commun du ministère japonais de l'Économie, du Commerce et de l'Industrie et du ministère des Affaires intérieures et des Communications souligne le lien entre développement électrique et développement des télécommunications. Les centres de données demandent une puissance considérable et une connectivité adaptée; leur implantation suppose une coordination de ces deux dimensions. Ce contexte national explique pourquoi un nom et une route ne suffisent pas. Il ne prouve ni réservation sur le réseau électrique, ni accord de raccordement, ni projet de construction pour le sujet étudié.

Le rapport intermédiaire consacré à l'infrastructure numérique décrit aussi une concentration des centres de données autour de Tokyo et d'Osaka, tandis que les atterrissements de câbles se concentrent dans d'autres zones côtières. Il évoque la répartition régionale et la sécurisation d'une électricité décarbonée. Cette séparation rappelle qu'un emplacement tokyoïte ne garantit pas une diversité internationale, et qu'une présence d'opérateur à Tokyo ne garantit pas une alimentation électrique adaptée. Les deux contraintes doivent être prouvées séparément à l'échelle du site.

L'autorité japonaise de l'énergie explique par ailleurs que certaines extensions de bâtiments de centres de données peuvent relever de dispositions permettant plusieurs entrées de service électrique sous des conditions définies. Cette possibilité réglementaire ne signifie pas que Japan HUB and centres de données bénéficie de deux arrivées, ni même qu'un bâtiment correspondant ait présenté une demande. Elle fournit plutôt une liste de questions: combien d'entrées, depuis quelles sous-stations, à travers quels appareillages, et avec quels risques communs en amont ?

Le contexte de résilience du réseau électrique japonais mentionne aussi les menaces liées aux catastrophes naturelles et les efforts de renforcement. Là encore, l'échelle nationale ne donne aucune fréquence de panne ni aucune architecture de secours propre à un site AS10209. Sans adresse technique, évaluation sismique, étude d'inondation, raccordement et résultats d'essais, il est impossible de convertir la politique publique en niveau de disponibilité individuel.

Aucun permis de construire, jalon de chantier, certificat de mise en service, raccordement électrique, évaluation incendie ou inondation, ou essai de groupe électrogène n'est identifié pour cette entité. Il serait abusif de combler cette absence avec des moyennes de marché ou des exigences générales. Les normes indiquent ce qu'un exploitant devrait pouvoir documenter. Elles ne prouvent pas qu'il l'a fait.

Cette partie du dossier abaisse fortement la confiance sur toute affirmation de centre de données. La puissance et le refroidissement ne sont pas des accessoires autour du réseau; ils déterminent si les routeurs, pare-feu et services restent actifs. Or aucune des dépendances physiques n'est rattachée au sujet. Le libellé contient « centres de données », mais la preuve publique ne contient ni le bâtiment ni ses systèmes vitaux.

La reprise logique reste une hypothèse tant qu'elle n'est pas éprouvée

Le motif des routes permet de construire un scénario de reprise raisonnable, mais seulement comme hypothèse à vérifier. En régime normal, les deux /24 liés à AS3356 peuvent attirer le trafic entrant parce qu'ils sont plus précis. Si les deux sont retirés proprement, le /23 lié à AS4637 peut reprendre la destination des mêmes 512 adresses. Cette mécanique est élégante sur le plan logique. Son efficacité dépend pourtant d'une chaîne de conditions qui n'est pas documentée.

Il faut d'abord détecter la bonne panne. Un lien complètement rompu peut entraîner un retrait évident, tandis qu'une panne d'application, de pare-feu ou de stockage peut laisser la session BGP et les annonces intactes. Dans ce second cas, la route continue de paraître saine alors que le service ne l'est plus. Le mécanisme de santé doit donc savoir quand retirer les routes plus précises, qui est autorisé à le faire et comment éviter des oscillations ou un retrait erroné. Le public n'a aucune description de ce fonctionnement.

Il faut ensuite que le chemin de repli soit réellement indépendant et suffisamment dimensionné. Le port associé à AS4637 doit accepter le trafic déplacé. Le routeur, les filtres et le pare-feu doivent posséder un état cohérent. Les applications doivent écouter sur les mêmes adresses et atteindre leurs dépendances. Le DNS, les certificats, les listes d'autorisation, les systèmes d'identité, les licences et la réplication peuvent chacun empêcher une reprise pourtant correcte au niveau BGP. Aucune mesure publique ne relie ces couches.

Les pannes partielles sont particulièrement difficiles. La perte d'un seul /24 peut toucher 256 adresses tandis que le second continue de répondre. La disparition du /23 peut supprimer le filet logique sans couper le chemin principal. Un engorgement peut dégrader le service sans faire tomber une session. Une annonce ancienne peut attirer du trafic vers un équipement isolé. La visibilité globale d'un préfixe ne suffit donc pas à prouver que chaque moitié, chaque fonction et chaque utilisateur est servi.

À ces scénarios réseau s'ajoutent les défaillances physiques: panne du routeur de bord, coupure d'un accès local partagé, rupture d'un brassage, erreur de filtre, saturation par attaque, perte électrique, défaut d'onduleur ou d'appareillage, arrêt du refroidissement, incendie, présence d'eau ou dommage sismique. Le dossier n'établit pas que ces événements se produisent sur le sujet; il montre qu'aucune architecture publique ne permet d'en mesurer la portée ou d'identifier les composants communs.

Aucun calendrier de maintenance, compte rendu d'incident, exercice de bascule, objectif de temps de reprise ou objectif de point de reprise n'est disponible. L'autonomie des groupes, la réserve de pièces et la capacité restante sur un autre site ne sont pas publiées. On ignore même s'il existe un second site capable de restaurer les fonctions. Le statut de reprise est donc non vérifié.

La preuve décisive serait un ensemble de résultats datés: retrait de chaque /24, retrait de l'agrégat, perte de chacun des routeurs, contrôle depuis plusieurs réseaux externes, maintien des applications et mesure de la charge restante. Pour la partie physique, il faudrait tester les alimentations, les groupes, le refroidissement et les procédures d'accès. En l'absence de ces éléments, la disposition BGP doit être présentée comme une possibilité de repli, jamais comme une promesse de continuité.

Les utilisateurs possibles sont internes, mais le rayon d'impact reste inconnu

Les sources associent AS10209 à Synopsys et décrivent un petit réseau d'entreprise. Le groupe le plus vraisemblablement exposé comprend donc des personnes ou des systèmes utilisant une bordure japonaise de Synopsys: salariés, prestataires, accès à distance, réseaux de bureau ou services internes automatisés. Les activités d'ingénierie de semi-conducteurs peuvent dépendre de transferts de fichiers, d'accès à des outils, de licences et de collaboration. Le dossier ne relie toutefois aucune application précise aux préfixes concernés.

Cette réserve empêche d'annoncer un nombre d'utilisateurs touchés. L'estimation de 246 utilisateurs observée par APNIC Labs le 2 avril 2026 est un signal de mesure, non la population contractuelle ou salariale du réseau. Cloudflare fournit une autre indication d'échelle, mais pas une liste de personnes. On ne sait pas combien d'adresses sont actives, combien de sessions passent par la bordure, ni si certaines fonctions utilisent d'autres numéros de système autonome.

Il n'existe aucune base pour parler d'abonnés internet grand public, de locataires de colocation, de clients de domaines hébergés ou de réseaux en aval. Aucun client gouvernemental, hyperscale ou infonuagique particulier n'est identifié. Il serait également excessif de rattacher tous les salariés de Nihon Synopsys ou tous les services japonais du groupe à AS10209. Les bureaux d'Osaka et de Yokkaichi figurent dans la présence de l'entreprise, mais aucune source ne dit qu'ils dépendent de ces routes.

La mention « Global » dans le cadrage éditorial s'explique par la propagation mondiale des routes et par l'activité internationale de la maison mère. Elle ne signifie pas qu'AS10209 possède plusieurs implantations mondiales. Le pays de registre est le Japon, l'histoire administrative est tokyoïte, et le point physique actuel reste inconnu. Une panne pourrait être limitée à une bordure de bureau japonaise; elle pourrait avoir une portée plus large si des systèmes internationaux en dépendent. Sans carte des applications, les deux scénarios restent ouverts.

Pour apprécier le rayon d'impact, il faudrait relier chaque préfixe à des fonctions, des propriétaires et des solutions de remplacement. Il faudrait savoir quelles adresses servent à l'accès, aux licences, au DNS, aux outils d'ingénierie ou à d'autres services, et quels utilisateurs passent par elles. Il faudrait aussi savoir quelles dépendances sont locales, lesquelles sont hébergées ailleurs et comment les données sont répliquées. Aucun de ces renseignements n'est public.

L'incertitude sur les utilisateurs n'affaiblit pas la preuve du réseau. Elle montre simplement que la joignabilité BGP ne révèle pas le service. Un même préfixe peut soutenir des usages très différents, et une petite population mesurée peut dépendre de fonctions essentielles. À l'inverse, un nombre d'adresses visible ne permet pas d'inférer un grand marché. Le jugement doit donc porter sur la qualité de la preuve, pas sur l'ampleur suggérée par le nom.

Ce qu'un acheteur devrait exiger avant de compter une capacité

Avant de compter une seule baie ou un seul kilowatt sous le nom Japan HUB and centres de données, un acheteur devrait d'abord faire préciser l'identité de l'objet. Le terme désigne-t-il encore une installation, un ancien libellé interne ou simplement la description historique d'AS10209 ? Quelle entité juridique exploite le numéro aujourd'hui ? Quelle entité contracte avec les réseaux observés ? Une réponse claire permettrait de séparer le rôle de Synopsys Inc., celui de Nihon Synopsys G.K. et celui d'éventuels hébergeurs tiers.

La seconde série de questions concerne le lieu. Il faudrait nommer le bâtiment ou les bâtiments actuels, fournir des identifiants d'installation et expliquer le passage d'Oimachi à Futako Tamagawa dans les dossiers. Si les équipements se trouvent dans un centre tiers, le nom de ce site et la salle concernée devraient être indiqués au niveau de précision compatible avec la diligence. Si les routeurs sont dans un bureau, il faudrait distinguer la salle technique d'une véritable offre de centre de données.

La connectivité demanderait ensuite des preuves de remise. Les deux relations observées sont-elles directes ? Quels sont les identifiants et les débits des circuits ? Les accès utilisent-ils des entrées, des fourreaux, des équipements et des domaines électriques distincts ? Existe-t-il un opérateur local commun sous les marques visibles ? Quel chemin porte le trafic sortant ? Le partage /23 et /24 correspond-il bien à une stratégie de repli, et selon quelles conditions les annonces sont-elles retirées ?

La capacité normale et la capacité en panne doivent être publiées séparément. Pour le réseau, cela signifie vitesse des ports, engagement, utilisation, pointe et marge après la perte d'un chemin. Pour l'installation, cela signifie puissance conçue, installée, mise en service, utilisée et encore disponible; baies conçues, installées, alimentées, occupées, réservées et libres; refroidissement disponible dans l'enveloppe de densité; et capacité de restauration sur un autre site. Une valeur commerciale sans état précis serait peu utile.

La résilience électrique demanderait les raccordements, sous-stations, appareillages, onduleurs, batteries, groupes, carburant et essais. La résilience thermique demanderait la topologie des équipements, leur redondance et un essai de perte. Les risques d'incendie, d'inondation et de séisme devraient être liés au bâtiment réel. Les documents de permis, de mise en service et d'essais intégrés apporteraient une preuve plus forte qu'une norme générale ou qu'une certification de bureau.

Enfin, l'acheteur devrait demander des résultats de reprise centrés sur les applications. La bascule de chaque route a-t-elle été observée depuis plusieurs réseaux ? Les pare-feu et les sessions restent-ils cohérents ? Les dépendances d'identité, de licence, de DNS, de stockage et de réplication continuent-elles de fonctionner ? Quel est le temps mesuré, quelle donnée peut être perdue et quelle charge reste supportable ? Sans ces réponses, le mot « redondance » décrit seulement des composants présents, pas un service restauré.

Ces demandes ne supposent pas que l'objet soit défaillant. Elles traduisent la distance entre ce qui est visible et ce qui serait nécessaire pour acheter une capacité. Le réseau public donne un point de départ utile. Il ne remplace ni un inventaire, ni une visite, ni une attestation de diversité, ni des essais. Tant que ces preuves ne sont pas disponibles, le compteur commercial doit rester à zéro, même si le compteur d'adresses routées affiche 512.

Verdict: réseau visible, installation et capacité toujours non démontrées

Le dossier atteint un niveau de confiance moyen pour le réseau. AS10209 est annoncé, son association à Synopsys est solide, ses trois routes IPv4 sont observables et le motif des voisins immédiats est précis: AS4637 pour l'agrégat /23, AS3356 pour les deux /24. Plusieurs vues indépendantes confirment une petite présence logique. Cette partie peut être décrite sans spéculation excessive.

Le niveau de confiance tombe à très faible pour l'installation et la capacité de centre de données. Aucun bâtiment actuel n'est nommé comme site d'AS10209. Aucun local de rencontre, brassage, port d'échange, rack de routeur ou chemin métropolitain n'est identifié. Aucune baie, surface, puissance, alimentation, autonomie, capacité de refroidissement, bande passante, clientèle ou marge de secours n'est publiée. Les pages de bureau ne comblent pas le vide, pas plus que les cartes générales des grands réseaux.

La frontière d'entreprise doit rester nette. Japan HUB and centres de données est l'identité existante du répertoire attachée au libellé d'AS10209 et aux dossiers Synopsys. Ce n'est pas un exploitant autonome vérifié. Rien ne montre que Synopsys vende de la colocation, de la puissance ou des baies sous ce nom. Rien ne montre non plus que les bureaux indiqués contiennent les routeurs ou une salle commercialisable.

La phrase de capacité demeure inchangée: 512 adresses IPv4 uniques sont routées; toutes les quantités de bande passante, de baies, de puissance, de refroidissement, de calcul, de stockage, de clients et de marge sous défaillance restent inconnues. Les trois annonces ne doivent pas être additionnées, et la grande allocation de la maison mère ne doit pas être substituée à la surface réellement annoncée.

Enfin, deux réseaux amont observés ne prouvent pas deux parcours physiques. Le partage agrégat/routes plus précises fournit un mécanisme logique crédible, mais aucune épreuve publique ne montre qu'il retire les bonnes routes, préserve les applications ou dispose de la capacité nécessaire lors d'une panne. Le terme exact est multiconnexion logique, avec diversité physique et reprise opérationnelle non vérifiées.

La leçon dépasse AS10209. Les registres de l'internet peuvent conserver des descriptions très évocatrices alors que leur fonction première est de documenter des ressources. Une annonce BGP peut être entièrement réelle sans que le bâtiment supposé par son nom soit public. Pour évaluer une infrastructure, il faut refuser de laisser un mot remplir les colonnes absentes. Ici, le réseau existe. Le centre de données comptable, lui, reste à prouver.

Sources

  1. APNIC RDAP, AS10209
  2. APNIC Whois, AS10209
  3. APNIC RDAP, organisation ORG-SA28-AP
  4. ARIN RDAP, réseau contenant 198.182.50.0
  5. ARIN RDAP, organisation SYNOPS
  6. RIPEstat, aperçu d'AS10209
  7. RIPEstat, préfixes annoncés par AS10209
  8. RIPEstat, état du routage d'AS10209
  9. RIPEstat, cohérence du routage d'AS10209
  10. RIPEstat, état BGP de 198.182.50.0/23
  11. RIPEstat, état BGP de 198.182.50.0/24
  12. RIPEstat, état BGP de 198.182.51.0/24
  13. RIPEstat, informations réseau pour 198.182.50.1
  14. RIPEstat, informations réseau pour 198.182.51.1
  15. RIPEstat, historique du routage d'AS10209
  16. RIPEstat, contrôle RPKI de 198.182.50.0/23
  17. RIPEstat, contrôle RPKI de 198.182.50.0/24
  18. RIPEstat, contrôle RPKI de 198.182.51.0/24
  19. Cloudflare Radar, aperçu d'AS10209
  20. Cloudflare Radar, routage d'AS10209
  21. APNIC Labs, estimation de population au Japon
  22. Synopsys, bureaux dans le monde
  23. Nihon Synopsys G.K., présentation de la société
  24. Synopsys, lieu de travail à Tokyo
  25. Synopsys, présentation du groupe
  26. Synopsys, rapport annuel 2025
  27. Lumen, carte mondiale du réseau
  28. Telstra International, carte du réseau et de l'infrastructure
  29. Japan centres de données Council, standard des installations
  30. Japan centres de données Council, bénéfices et contraintes des installations
  31. Japan centres de données Council, guide PUE
  32. METI et MIC, publication du rapport Watt-Bit 1.0
  33. METI et MIC, synthèse du rapport intermédiaire 2.0
  34. Agence japonaise de l'énergie, entrées électriques multiples
  35. Agence japonaise de l'énergie, résilience du réseau électrique
  36. RFC 4271, Border Gateway Protocol 4
  37. RFC 6811, vérification de l'origine des préfixes BGP