Résumé

  • Au 20 juillet 2026 à 00:00:00, RIPEstat indiquait pour AS209045 une visibilité nulle auprès de 323 pairs RIS en IPv4 et de 318 en IPv6, aucun préfixe annoncé dans les deux familles et aucun voisin observé. Cette mesure décrit la vue de collecteurs BGP, pas une panne générale de Genesis Cloud.
  • Les deux entrées opérationnelles à 10 Gbit/s consignées dans PeeringDB pour DE-CIX Francfort et Kristiansand ne contredisent pas les sessions de serveur de routes vues comme inactives ou passives par le looking glass de DE-CIX. La première source décrit une configuration déclarée par l’opérateur; la seconde, un état ponctuel du côté de l’échange.
  • Les contrôles documentés sur les régions, instances, volumes, images, snapshots et groupes de sécurité fournissent des points d’essai utiles, tandis que le chemin DNS de l’API dépendait de Google Cloud et qu’un point de terminaison de stockage objet documenté ne se résolvait pas lors de l’examen. Aucun de ces éléments ne prouve à lui seul une perte de données, une indisponibilité totale ou une capacité de reprise suffisante pour un client donné.

Une contradiction qui disparaît lorsque les preuves sont séparées

Un inventaire public peut sembler raconter deux histoires incompatibles. D’un côté, AS209045 reste entouré d’objets administratifs: un numéro de système autonome enregistré, des blocs d’adresses associés, des objets de route, des autorisations RPKI, une fiche PeeringDB et deux interfaces d’échange marquées comme opérationnelles à 10 Gbit/s. De l’autre, la photographie RIPE RIS datée du 20 juillet 2026 ne voit ni préfixe IPv4, ni préfixe IPv6, ni voisin pour cet ASN. Le looking glass de DE-CIX montre en outre les quatre entrées de serveur de routes examinées dans un état inactif ou passif, avec zéro route.

Ces constats ne portent pas sur le même objet. Un registre répond à la question « quelles ressources et quelles intentions ont été déclarées? ». PeeringDB répond à la question « quelle présence l’opérateur a-t-il décrite auprès de la communauté d’interconnexion? ». Un serveur de routes d’échange renseigne l’état d’une session précise observée depuis cet échange. RIS indique ce qu’un ensemble de collecteurs BGP voit à un instant donné. Le DNS révèle comment certains noms publics se résolvent lors d’une requête.

Enfin, une documentation de service présente des commandes disponibles, sans démontrer qu’un client peut restaurer sa charge dans un délai donné.

L’erreur la plus coûteuse serait de transformer l’une de ces couches en verdict universel. Les ports déclarés dans PeeringDB ne suffisent pas à établir que des routes circulent. L’absence de routes dans RIS ne suffit pas à établir qu’une interface web, une API ou une charge privée est indisponible. Un enregistrement RPKI ne fait pas apparaître un préfixe sur Internet. Une réponse DNS valide pour l’API ne prouve pas la santé des instances ou du stockage. Une réponse négative pour un nom de stockage ne prouve pas la disparition de données. Chaque signal garde sa valeur lorsqu’il reste dans son périmètre.

Pour un acheteur, la conclusion utile n’est donc ni « tout fonctionne » ni « tout est arrêté ». Elle est plus exigeante: les éléments publics montrent une continuité administrative et des surfaces de contrôle documentées, mais la visibilité de routage examinée est nulle et plusieurs dépendances externes sont observables. Il faut convertir cette tension en tests portant sur le compte réel, la région réelle, le type d’instance réel et les copies de données réelles du client.

Tant que ces tests ne sont pas datés et reproductibles, la preuve publique reste de force moyenne pour les registres, le routage, le DNS et les commandes, et faible pour la capacité physique ou la reprise propre à l’acheteur.

Cette méthode évite aussi une confusion temporelle. Une fiche, un objet de route et une session peuvent avoir été créés ou modifiés à des dates différentes. Une mesure RIS possède son heure de requête. Les états du looking glass ont leurs dates de changement. Une documentation décrit une possibilité actuelle sans révéler quand elle a été exercée. L’analyse doit conserver ces horodatages au lieu de fondre des observations éloignées dans une prétendue situation permanente.

Le nom du répertoire n’est ni une société ni un service commercial

L’expression Genesis Cloud Routing, Peering and DNS désigne dans RIPE le rôle technique GCRP3-RIPE. Ce rôle a été créé le 29 avril 2019, modifié pour la dernière fois le 25 juillet 2024 et associé à une adresse à Munich. Un rôle RIPE sert à représenter une fonction de contact dans le registre. Il ne constitue pas, par sa seule existence, une personne morale indépendante, une offre commerciale, un contrat client ou un exploitant de capacité hébergée. Rien dans les éléments examinés ne permet d’affirmer que ce rôle vend lui-même des instances, possède des installations ou exécute tous les contrats associés au nom Genesis Cloud.

AS209045 est un autre objet. RIPE l’enregistre sous le nom GENESIS-CLOUD-AS. Les données RDAP et REST le relient à ORG-GCL19-RIPE, c’est-à-dire Genesis Cloud Limited. Le numéro autonome identifie une entité de routage dans les registres et les échanges BGP; il n’est pas une société, un datacenter, une marque commerciale ou une mesure de santé. Le lien administratif entre l’ASN, l’organisation RIPE et le rôle technique est pertinent, mais il ne rend pas ces éléments interchangeables.

Genesis Cloud Limited est encore une identité distincte. La fiche RIPE d’ORG-GCL19-RIPE indique une société de droit maltais, numéro C 88032, de type LIR. La liste des membres RIPE NCC à Malte la mentionne également. Le statut de registre Internet local signifie qu’une organisation gère des ressources auprès du RIPE NCC. Il ne démontre ni la propriété de serveurs, ni la maîtrise des bâtiments, ni l’exploitation d’une fibre longue distance, ni l’identité exacte de la partie qui signe un contrat avec chaque client.

Genesis Cloud GmbH ne doit pas être confondue avec Genesis Cloud Limited. Une fiche LEI de GLEIF donne à l’entité allemande un statut d’enregistrement « LAPSED », une dernière mise à jour au 26 juin 2026 et un événement de liquidation indiqué comme « IN_PROGRESS », enregistré au 2 septembre 2025. Cette information est juridiquement importante pour l’entité qu’elle nomme. Elle ne prouve pas que Genesis Cloud Limited, Genesis Cloud Norway AS, AS209045 ou tous les services destinés aux clients seraient eux-mêmes en liquidation. Propager ce statut d’une personne morale à toute une constellation technique serait une extrapolation non étayée.

Bulk Infrastructure constitue encore une autre organisation. Ses pages décrivent le campus N01 en Norvège et sa connectivité. DE-CIX documente les surfaces d’échange évoquées dans les sources. Google Cloud apparaît dans la résolution publique de l’adresse de l’API. Cloudflare apparaît dans la délégation publique du domaine genesiscloud.com. Ces relations observables peuvent être essentielles à une cartographie de dépendances, mais elles ne transfèrent pas automatiquement la propriété, la responsabilité contractuelle ou l’état de service d’un acteur à l’autre.

Cette discipline d’identité a une conséquence pratique. Avant toute analyse de continuité, un acheteur devrait inscrire séparément dans son dossier le cocontractant, la marque utilisée dans l’interface, l’ASN observé, la région choisie, le site physique annoncé, les intermédiaires DNS et les échanges Internet pertinents. Une réponse portant sur l’un ne clôt pas une question portant sur l’autre. Le libellé du répertoire permet de retrouver le rôle réseau; il ne remplace pas cette décomposition.

Ressources enregistrées, objets de route et autorisations RPKI

La recherche inverse RIPE relie ORG-GCL19-RIPE à deux plages IPv4, 147.189.192.0 à 147.189.207.255 et 194.61.20.0 à 194.61.23.255, ainsi qu’au bloc IPv6 2a09:7000::/29 et à AS209045. Ces enregistrements établissent une association administrative de ressources numériques. Ils sont utiles pour suivre les références, rechercher les objets correspondants et vérifier les politiques annoncées. Ils ne disent pas que chaque adresse est attribuée à une machine active, que chaque préfixe est visible mondialement ou que du trafic client l’emprunte aujourd’hui.

La recherche d’objets de route renvoie six objets route ou route6 dont l’origine déclarée est AS209045. L’ensemble comprend 147.189.200.0/22, 147.189.207.0/24, 2a09:7000::/29, 2a09:7000::/31, 2a09:7007::/36 et 2a09:7000:1000:200::/56. Le dernier porte la remarque « Test for traffic redirection ». Ce détail mérite d’être conservé comme contexte, mais pas transformé en description d’un mécanisme actif. Un objet IRR exprime une politique ou une autorisation; il ne mesure ni l’annonce actuelle, ni la préférence de chemin, ni la qualité de livraison.

La fiche aut-num ajoute une couche de politique déclarée. Elle énumère notamment des relations d’acceptation avec AS13237, AS50304, AS60259, AS44735, AS200781 et AS212175, ainsi que de nombreuses règles concernant des pairs ou des serveurs de routes. Cette liste peut guider une enquête: elle indique les relations que l’organisation a voulu consigner. Elle ne permet pas d’affirmer que tous ces réseaux transportent actuellement du trafic pour AS209045, qu’un contrat de transit demeure en vigueur ou qu’une session BGP est établie au moment de la lecture.

L’historique RPKI de RIPEstat apporte une troisième forme de continuité administrative. Les dernières lignes disponibles au 18 juillet 2026 comptent deux autorisations de préfixe en IPv4 et trois en IPv6 pour AS209045. Une autorisation d’origine de route aide les réseaux à évaluer si une annonce donnée est conforme à l’intention publiée. En l’absence d’annonce visible, elle reste une autorisation sans route observée. Elle ne garantit ni que le préfixe est émis, ni qu’il atteint les collecteurs, ni qu’un service répond derrière lui.

Ces trois inventaires ne sont donc pas redondants. Les ressources liées à l’organisation répondent à une question d’enregistrement. Les objets IRR décrivent des intentions de routage. Les autorisations RPKI bornent les origines acceptables pour des préfixes. La visibilité RIS mesure une annonce effectivement reçue par des collecteurs. Confondre les niveaux conduirait à compter plusieurs fois une même intention administrative et à la présenter comme autant de preuves indépendantes d’exploitation.

Pour l’acheteur, les registres restent néanmoins précieux. Ils permettent d’établir une référence avant un incident, de détecter un changement ultérieur et de poser des questions précises. Pourquoi un préfixe autorisé n’est-il pas visible? Une annonce a-t-elle été retirée volontairement? Un autre ASN sert-il le trafic? La charge utilise-t-elle seulement des adresses qui ne relèvent pas d’AS209045? Les sources examinées ne répondent pas à ces questions causales. Elles fournissent le vocabulaire et les repères nécessaires pour les poser sans attribuer à tort une activité vivante à un enregistrement statique.

La mesure RIS du 20 juillet 2026 et sa limite exacte

Le constat de routage le plus fort est aussi le plus précisément borné. Pour une heure de requête fixée au 20 juillet 2026 à 00:00:00, le service routing-status de RIPEstat indique une visibilité IPv4 de 0 sur 323 pairs RIS et une visibilité IPv6 de 0 sur 318. Le nombre de préfixes annoncés est nul dans les deux familles, et le nombre de voisins observés est également nul. La requête sur les préfixes annoncés pour la fenêtre allant du 6 au 20 juillet 2026 renvoie un ensemble vide.

Il s’agit d’une observation de collecteurs BGP. Elle signifie que, dans la vue RIS consultée et à l’instant retenu, AS209045 n’apparaissait pas comme origine de préfixes visibles auprès des pairs comptés. La formulation doit rester aussi stricte que la mesure. Elle ne signifie pas « Genesis Cloud est en panne ». Elle ne dit pas si une page web répond, si une API placée derrière un autre ASN fonctionne, si des machines communiquent sur un réseau privé, si des clients ont migré leurs adresses ou si une charge donnée est joignable par un chemin qui ne porte pas AS209045 comme origine.

Cette distinction n’atténue pas la valeur du résultat. Zéro sur plusieurs centaines de pairs dans les deux familles, combiné à zéro préfixe et zéro voisin observé, est un signal fort d’absence de visibilité globale de cet ASN dans RIS à cette date. Pour un acheteur qui avait supposé que sa connectivité publique dépendait d’AS209045, le résultat justifie une vérification immédiate. Il ne justifie pas de raconter une cause que la mesure ne contient pas.

La page BGP.tools consacrée à AS209045 peut servir de second point d’entrée pour examiner la vue de routage. Les chiffres de référence doivent toutefois rester attachés à RIPEstat lorsqu’ils proviennent de cette source. Deux collecteurs peuvent différer par leurs pairs, leur moment d’observation, leurs règles de présentation ou la fraîcheur de leurs données. Additionner leurs instantanés comme s’ils composaient un inventaire unique effacerait les différences qui donnent justement du sens à chaque mesure.

Le bon réflexe consiste à noter cinq éléments avec toute capture: la ressource interrogée, l’heure de requête, la famille d’adresses, le nombre de collecteurs ou de pairs concernés et la réponse brute sur les préfixes. Une nouvelle vérification pourra alors établir si la situation persiste, s’améliore ou change de forme. Sans cette discipline, une absence momentanée risque d’être présentée comme une caractéristique durable, tandis qu’une présence historique risque d’être utilisée pour nier une absence actuelle.

La mesure ne livre pas non plus la raison du retrait éventuel. Une modification planifiée, un changement d’architecture, un déplacement vers un autre ASN, une suspension de sessions ou une difficulté opérationnelle peuvent produire des traces différentes ou parfois semblables. Les éléments disponibles ne tranchent entre aucune cause. Le fait responsable est donc l’absence observée; l’explication reste inconnue.

Enfin, la portée commerciale ne se déduit pas du routage seul. Un client peut acheter une capacité dont la disponibilité dépend de réseaux que les documents publics ne dévoilent pas entièrement. À l’inverse, une application accessible par une adresse d’un autre ASN peut continuer à répondre alors qu’AS209045 disparaît de RIS. La vérification acheteur doit relier la mesure publique aux adresses, noms, régions et services effectivement utilisés, faute de quoi elle compare deux périmètres différents.

L’historique montre un changement, pas sa cause

Les données historiques empêchent de lire le zéro actuel comme une absence éternelle. Entre le 1er novembre et le 3 décembre 2025, RIPEstat a vu 2a09:7000::/31 du 3 novembre à 16:00 au 2 décembre à 00:00. Il a également vu 147.189.200.0/22 du 3 novembre à 16:00 au 2 décembre à 08:00. Ces intervalles établissent que des préfixes attribués à AS209045 ont été visibles dans la période examinée. Ils ne prouvent ni une visibilité continue avant ou après, ni un niveau de trafic, ni une qualité de service.

La requête sur les voisins d’ASN au 1er décembre 2025 signale un voisin à gauche, AS50304. Le 20 juillet 2026, routing-status compte zéro voisin observé. La comparaison soutient l’idée d’un paysage de routage observé qui a changé. Elle ne retrace pas tout l’historique des chemins, ne qualifie pas AS50304 comme prestataire contractuel actuel et ne révèle pas quand ou pourquoi les relations visibles ont cessé de l’être.

Les dates sont ici essentielles. Les deux préfixes historiques cessent d’apparaître au début de décembre 2025 dans la fenêtre demandée. Les sessions DE-CIX présentent d’autres dates de changement. Les autorisations RPKI ont encore des lignes récentes en juillet 2026. Ces calendriers peuvent coexister parce qu’ils décrivent des objets différents. Une autorisation peut rester publiée après le retrait d’une annonce; une fiche d’interconnexion peut rester marquée opérationnelle alors qu’une session de serveur de routes est inactive; un service peut utiliser une adresse provenant d’un autre réseau.

L’historique sert donc à formuler une question plus précise: quelle architecture a remplacé, contourné ou suspendu la visibilité auparavant observée? La réponse ne figure pas dans les sources disponibles. Un acheteur devrait la demander avec ses propres adresses et contrats en main, puis vérifier la réponse par mesure. Présenter une hypothèse comme la cause réduirait la qualité de la décision, car le plan de continuité serait construit autour d’un mécanisme non démontré.

PeeringDB et le looking glass de DE-CIX ne mesurent pas la même chose

PeeringDB présente Genesis Cloud sous AS209045, avec le type d’information « Enterprise » et une portée européenne. La fiche et son interface de données indiquent deux entrées de réseau d’échange à 10 Gbit/s, toutes deux marquées opérationnelles, compatibles avec le serveur de routes et avec BFD. L’une concerne DE-CIX Francfort, l’autre DE-CIX Kristiansand. Ce sont des renseignements structurés et utiles pour comprendre la présence d’interconnexion déclarée.

PeeringDB repose toutefois sur des informations maintenues par les opérateurs participants. Le drapeau « opérationnel » indique l’état déclaré de l’entrée, pas une mesure indépendante de la session, des routes ou des paquets. La capacité de port inscrite ne prouve pas non plus qu’un trafic de 10 Gbit/s circule, que des préfixes sont annoncés, que des GPU sont disponibles ou que le chemin rejoint une charge client. Une interface peut être provisionnée, conservée dans l’inventaire ou utilisée pour certains échanges sans apparaître comme active dans la vue particulière d’un serveur de routes.

Le looking glass de DE-CIX fournit précisément cette vue plus étroite. Lors de l’examen du 20 juillet 2026, les entrées IPv4 et IPv6 de Francfort pour AS209045 étaient inactives après expiration du temporisateur de maintien, avec des changements remontant au 22 octobre 2025. À Kristiansand, les entrées IPv4 et IPv6 étaient inactives ou passives, avec des changements au 24 juin 2026. Les quatre entrées examinées affichaient zéro route.

Ce résultat ne réfute pas la fiche PeeringDB; il affine ce qu’elle ne mesure pas. Une configuration déclarée peut exister tandis qu’une session du serveur de routes est inactive. Inversement, une session inactive auprès du serveur de routes ne prouve pas l’absence de toute session bilatérale, de tout transit ou de tout trafic client. L’échange fournit une surface parmi plusieurs possibles. Pour conclure sur la connectivité d’une charge, il faudrait connaître le chemin de cette charge et observer les autres relations pertinentes.

Les documents publics de DE-CIX et de Genesis Cloud décrivent par ailleurs une conception GlobePEER Remote à 10 Gbit/s, un pont par Kristiansand et Bulk, ainsi qu’un raisonnement consistant à déplacer une partie du trafic IA et calcul intensif du transit vers le peering. Ce récit aide à comprendre l’intention: rapprocher l’interconnexion d’une infrastructure nordique tout en atteignant Francfort. Les bénéfices de charge ou de performance présentés restent cependant des affirmations de partenaires. Ils ne sont pas des mesures vérifiées pour un acheteur particulier et ne garantissent pas l’état actuel des sessions.

La coexistence de ces traces doit modifier la méthode de diligence. Il faut demander non seulement « avez-vous un port DE-CIX? », mais aussi « quelles sessions servent notre trafic, quels préfixes y sont annoncés, quelle route de repli a été testée, à quelle date et avec quel résultat? ». La première question obtient un inventaire. Les suivantes recherchent une capacité opérationnelle démontrée.

Le même principe vaut pour BFD. Sa présence dans une fiche décrit une fonction de détection rapide prévue pour la session. Elle ne prouve pas que la session est établie, que le basculement conduit vers un chemin indépendant ou que l’application tolère la transition. La disponibilité économique d’une interconnexion dépend moins du nombre d’options consignées que de l’indépendance réelle des chemins et de la réussite d’exercices observables.

Sites répertoriés, contrôle physique non démontré

PeeringDB associe également AS209045 à EMC Home of Data MUC I/II, MuCon-X, à Munich, et au campus Bulk Norway Data Center N01, à Øvrebø. Les pages publiques de Bulk décrivent N01 et la connectivité du site. DE-CIX documente de son côté une surface d’échange à Kristiansand. Ces éléments placent l’histoire technique dans un espace européen concret et expliquent le choix de la catégorie Europe et Moyen-Orient consacrée aux services cloud.

Ils ne répondent pourtant pas à la question de la propriété. Aucune source examinée ne montre que Genesis Cloud possède les campus, les systèmes électriques, les salles d’interconnexion, les fibres longue distance ou les échanges. Une présence répertoriée peut correspondre à de l’équipement hébergé, à une interconnexion distante, à une capacité louée ou à une autre relation que les pages publiques ne détaillent pas. Le mot « site » ne doit pas devenir « actif détenu » sans document qui l’établisse.

Cette limite compte pour la continuité. Un acheteur ne cherche pas seulement un nom de campus; il cherche à savoir quels domaines de panne sont communs. Deux chemins commerciaux peuvent partager une même entrée physique. Deux services annoncés dans une région peuvent dépendre d’un même bâtiment, d’une même alimentation ou d’un même réseau de transport. À l’inverse, une interconnexion distante peut séparer certaines composantes malgré une présentation commerciale unifiée. Les sources disponibles ne permettent pas de cartographier ces dépendances internes.

Bulk, DE-CIX, la société contractante et le rôle RIPE doivent donc rester des colonnes distinctes dans un registre de risques. Pour chaque dépendance, l’acheteur a besoin d’un responsable, d’un point d’escalade, d’une preuve de redondance et d’un résultat d’exercice. Une brochure de site peut documenter des caractéristiques générales; elle ne remplace pas la démonstration que la charge précise du client bénéficie de ces caractéristiques.

Le classement régional doit lui aussi rester modeste. Les sources juridiques, les installations, les interconnexions, la région documentée et l’API examinée sont centrés sur l’Europe. Cela justifie le classement éditorial choisi. Cela ne signifie pas que chaque client, société affiliée, dépendance logicielle ou route de trafic se trouve exclusivement en Europe ou au Moyen-Orient.

Une documentation de contrôle n’est pas un résultat de reprise

La documentation destinée aux développeurs expose une API de calcul et indique une limite moyenne de dix requêtes par seconde. Ce renseignement est concret: un client peut concevoir son automatisation en tenant compte d’un débit de commandes annoncé. Il ne dit pas que les appels réussiront pendant une perturbation, que les jetons d’accès resteront disponibles, que la capacité demandée existera ou qu’une série de créations atteindra le temps de reprise visé.

La documentation des régions nomme Norway-KRS1, également représentée par NORD-NO-KRS-1. Elle présente le réseau privé, les volumes et les groupes de sécurité comme des ressources régionales. Cette portée est importante pour la conception. Une ressource régionale peut devoir être recréée ailleurs; une copie locale peut partager le même domaine de risque que l’instance qu’elle protège. Mais le mot « régional » ne révèle pas l’emplacement des répliques, leur séparation physique, la disponibilité d’une autre région ou le mécanisme de reprise après sinistre.

Le point de disponibilité renvoie un état booléen par région et type d’instance. Le catalogue des types d’instances énumère des formes CPU et GPU pour Norway-KRS1. Ce sont des signaux utiles pour une tentative de création à un moment donné. Un booléen n’est ni une réservation, ni un stock chiffré, ni un engagement de capacité de remplacement. Il peut répondre favorablement pour une unité sans garantir le nombre d’accélérateurs, la durée ou la proximité dont un client a besoin.

La documentation des instances décrit les opérations du cycle de vie, les scripts de démarrage et le traitement des volumes attachés. Elle avertit aussi des conséquences de la suppression d’une instance avec son disque de démarrage. Ces commandes donnent à l’acheteur une surface de contrôle. Elles ne créent pas une machine équivalente. Un script ne compense pas l’absence d’un type de GPU. Une commande de création ne transporte pas automatiquement l’état. Une suppression correctement exécutée peut même rendre la récupération plus difficile si la politique de copie n’a pas été testée.

Les volumes, images et snapshots possèdent leurs propres paramètres: région, attachement, stockage, classe d’image, compatibilité, clonage et copie instantanée. Les pages actuelles des instances et des snapshots exposent notamment des paramètres replicated_region ou de clonage vers une région. Leur existence montre qu’une surface de portabilité est documentée. Elle ne constitue pas une garantie universelle de copie interrégionale, de compatibilité complète ou de restauration réussie.

Le point décisif est la différence entre capacité syntaxique et résultat opérationnel. Une commande documentée peut être valide tout en échouant pour une permission, un quota, une incompatibilité, un manque de capacité, un délai ou un état de ressource. Un plan de continuité doit donc conserver les identifiants des copies, les régions cibles, les dépendances réseau et les temps mesurés lors d’un exercice. Sans cette preuve, la documentation indique ce qui peut être demandé, pas ce qui sera obtenu.

Les groupes de sécurité illustrent le même écart. La documentation présente des règles de pare-feu et de contrôle du trafic à portée régionale. Elle ne démontre pas une diversité de chemin, une isolation est-ouest suffisante, la récupération d’un segment ou le basculement pendant un incident. Recréer une instance sans recréer correctement ses règles peut produire une machine inaccessible ou trop exposée. L’exercice doit vérifier l’ordre, les dépendances et le résultat, pas seulement l’existence des commandes.

Pour l’économie d’un service d’infrastructure, cette distinction est fondamentale. La valeur d’une option de reprise ne vient pas de son apparition dans un catalogue; elle vient de sa disponibilité lorsque tous les clients concurrents peuvent en avoir besoin, de son coût réel et de sa capacité à restituer l’application dans les limites convenues. Les sources examinées ne fournissent pas cette démonstration pour un acheteur particulier.

Le DNS de l’API révèle une dépendance, pas toute l’architecture

Le domaine genesiscloud.com est enregistré depuis le 5 août 2008. La fiche RDAP de Cloudflare indique une dernière modification au 11 juillet 2026, une expiration au 5 août 2027 et les serveurs de noms ara.ns.cloudflare.com et zeus.ns.cloudflare.com. Ces données établissent le rôle public de Cloudflare pour la délégation observée. Elles ne dévoilent pas l’architecture DNS interne, les zones privées, les mécanismes de secours ou la localisation des charges cloud.

Lors de l’examen, Google Public DNS résolvait api.genesiscloud.com par le nom gws-loadbalancer-prd.genesiscloud.com vers l’adresse 34.76.254.30. RIPEstat associait cette adresse à AS396982, qu’ARIN identifie comme GOOGLE-CLOUD-PLATFORM. La chaîne observée montre donc qu’un point d’entrée public de l’API aboutissait, à cet instant, à une adresse annoncée par Google Cloud.

Ce fait ne doit pas être élargi au-delà de la requête. Il ne prouve pas que toute la plateforme Genesis Cloud est externalisée vers Google Cloud, que les charges GPU y résident, que le plan de données partage le même chemin ou que l’API ne possède aucune solution de repli. Il ne prouve pas non plus que Google Cloud est la partie au contrat du client. Il identifie une dépendance de contrôle visible, suffisamment importante pour être incluse dans les tests.

La présence de Google Cloud dans ce chemin explique également pourquoi une API peut rester résoluble alors qu’AS209045 n’apparaît pas dans RIS. L’adresse 34.76.254.30 relève d’un autre ASN. Il n’y a donc aucune contradiction nécessaire entre l’absence d’annonces AS209045 et une réponse DNS pour l’API. Mais la résolution seule ne garantit pas que l’authentification, la création d’instances, la lecture des quotas ou l’accès aux régions fonctionnent.

Cloudflare et Google Cloud doivent rester deux dépendances distinctes. Le premier apparaît dans les serveurs de noms du domaine; le second dans le chemin de l’adresse de l’API examinée. Ni l’un ni l’autre ne devient pour autant Genesis Cloud Limited, Genesis Cloud GmbH, AS209045, Bulk ou DE-CIX. Leur présence rend la surface de continuité plus composite et invite à tester les conséquences d’une défaillance de délégation, de résolution, de terminaison ou de commande.

Un test utile ne s’arrête donc pas à une requête DNS. Il enregistre la chaîne de noms, les réponses A et CNAME, l’ASN de destination, le temps de réponse de l’API et le succès d’une opération sans effet destructif. Il répète l’essai depuis plusieurs réseaux contrôlés par le client. Les sources publiques permettent d’établir une référence; elles ne remplacent pas l’observation depuis les chemins réels de l’acheteur.

Le point de stockage non résolu est un signal d’essai, pas un verdict sur les données

La documentation des régions cite s3.nord-no-krs-1.genesiscloudusercontent.com comme point de terminaison de stockage objet. Lors de l’examen, une requête A auprès de Google Public DNS pour ce nom a renvoyé un statut 3 de type NXDOMAIN. Une requête NS portant sur genesiscloudusercontent.com a également renvoyé un statut 3. La combinaison est notable parce qu’un nom présenté dans une documentation courante ne se résolvait pas depuis le résolveur public interrogé.

Pour un acheteur qui dépend de ce point de terminaison, ce résultat impose un essai direct. Il faut vérifier le nom réellement configuré dans le compte, la documentation applicable à la région, l’éventuelle nécessité d’une résolution privée et la réponse depuis les réseaux autorisés. Si le nom reste négatif dans le contexte prévu, les opérations de copie, de restauration ou de transfert qui l’utilisent peuvent être empêchées, même si d’autres surfaces répondent.

La réponse négative ne démontre toutefois pas une perte de données. Elle ne montre pas le contenu d’un compartiment, l’état des supports, la présence de répliques, la possibilité d’un autre point d’accès ou le sort de tous les services de stockage. Elle ne permet pas non plus d’annoncer une cessation générale de service. Le DNS indique qu’un nom n’a pas été résolu dans une requête donnée; il ne lit pas les objets stockés.

Cette limite ne réduit pas la gravité potentielle pour la reprise. Un stockage intact mais inaccessible par le nom attendu peut rendre une copie inutilisable dans le temps disponible. À l’inverse, un nom différent ou une voie privée peut permettre l’accès sans apparaître dans le test public. Le seul moyen de distinguer ces scénarios est de restaurer un jeu de données témoin selon la procédure du client, puis de mesurer son intégrité et sa durée.

Le contraste avec l’API est instructif. Le nom de l’API se résolvait vers Google Cloud, tandis que le nom documenté du stockage objet ne se résolvait pas dans les requêtes indiquées. Cela montre que « Genesis Cloud est joignable » est une phrase trop large: différentes fonctions peuvent dépendre de noms, d’ASN et de contrôles distincts. La continuité doit être testée service par service.

Images, volumes et snapshots : la portabilité doit être exécutée

Une architecture de reprise repose sur trois questions séparées: peut-on créer une capacité de calcul compatible, peut-on lui rattacher un état cohérent et peut-on rétablir les contrôles réseau nécessaires? La documentation de Genesis Cloud expose des éléments pour chacune, mais aucune source publique ne présente un exercice complet et daté pour un acheteur particulier.

Les images décrivent des classes et des compatibilités. Elles peuvent aider à reconstruire un environnement, mais une image n’est pas nécessairement l’état courant d’une application. Elle peut manquer de données, de secrets, de configurations récentes ou de dépendances externes. La compatibilité déclarée avec un type de machine ne garantit pas que ce type est disponible dans la région cible au moment du besoin.

Les volumes portent l’état persistant attaché aux instances. Leurs paramètres de région et d’attachement indiquent qu’ils ne doivent pas être traités comme des objets sans localisation. Une procédure de reprise doit établir si le volume peut être copié, recréé ou restauré ailleurs, combien de temps cela prend et quel point de récupération est obtenu. La présence d’un champ d’API ne révèle ni le débit de restauration, ni la séparation physique des copies, ni leur complétude.

Les snapshots offrent une autre unité de contrôle. Les paramètres replicated_region et de clonage vers une région documentent une possibilité de portabilité. Ils ne prouvent pas que toutes les classes de snapshot, toutes les images ou tous les volumes peuvent franchir toute frontière régionale. Ils ne garantissent pas non plus que la copie la plus récente a réussi, que ses dépendances suivent ou qu’une capacité de calcul équivalente attend à destination.

Un exercice sérieux commence avant la perturbation. Il crée une charge témoin, écrit des données identifiables, prend une copie, la réplique vers la région cible prévue, crée une instance compatible, rattache l’état et valide l’application. Il enregistre chaque erreur, chaque quota, chaque délai et chaque étape manuelle. Il répète ensuite l’opération avec une copie plus ancienne et une panne simulée d’une dépendance. Ce travail transforme une option documentée en preuve utilisable.

Le disque de démarrage mérite une attention particulière puisque la documentation décrit les conséquences de la terminaison d’une instance avec ce disque. Une automatisation trop agressive peut supprimer la ressource qu’elle cherche à remplacer. Les garde-fous doivent distinguer une instance jetable, un volume persistant et une copie protégée. Ils doivent aussi vérifier que l’ordre des opérations reste valable lorsque l’API répond lentement ou que la création de capacité échoue.

Les scripts de démarrage sont utiles pour réduire la configuration manuelle. Mais ils peuvent dépendre d’un dépôt, d’un service de noms, d’une clé, d’une image ou d’un point de stockage indisponible. Leur succès doit être mesuré depuis la région de repli, avec les mêmes restrictions réseau qu’en situation réelle. Un script qui a fonctionné lors de sa création n’est pas une preuve de portabilité durable.

Enfin, les groupes de sécurité doivent être recréés avec prudence. Une règle régionale peut référencer des plages, des services ou un ordre implicite qui ne se transpose pas automatiquement. La reprise ne se termine pas lorsque la machine démarre; elle se termine lorsque l’application communique seulement avec les parties prévues, que les contrôles restent en place et que les utilisateurs peuvent atteindre le service par un chemin vérifié.

La capacité affichée n’est ni une réserve ni un engagement

Le catalogue énumère des formes CPU et GPU dans Norway-KRS1, tandis que le point de disponibilité fournit une valeur booléenne par région et type d’instance. Ces informations permettent de construire une sonde et de savoir si une demande paraît recevable à un instant. Elles ne révèlent pas combien d’unités sont libres, combien sont déjà promises, combien de temps l’état restera favorable ou quelle priorité recevra un client pendant une demande simultanée.

Cette différence est particulièrement importante pour les accélérateurs. Une charge peut exiger un modèle, une mémoire, un nombre de cartes, une topologie entre cartes et un profil de réseau précis. Une autre forme GPU n’est pas nécessairement un substitut économique ou technique. Même une forme nominalement compatible peut imposer une nouvelle image, une adaptation logicielle ou une baisse de performance. Les sources ne fournissent aucune mesure de capacité de remplacement adaptée à un portefeuille client donné.

La disponibilité de secours doit donc être contractualisée ou exercée, idéalement les deux. Un acheteur peut réserver de la capacité, maintenir une empreinte chaude, vérifier périodiquement un lancement ou prévoir une autre plateforme. Les éléments publics ne disent pas laquelle de ces options existe dans un contrat particulier. Ils ne permettent pas non plus d’établir un prix actuel, un crédit de niveau de service ou un remède juridique.

Plusieurs anciennes pages consacrées aux prix, aux conditions, à la confidentialité, au niveau de service, au réseau, au stockage ou à l’assistance n’étaient pas accessibles de manière exploitable lors du dernier passage. Elles sont donc exclues des sources retenues. Il serait imprudent d’en tirer un tarif courant, une promesse de crédit, l’identité actuelle d’un responsable juridique ou une procédure d’assistance. L’économie de la reprise doit être calculée à partir de documents contractuels actuels fournis au client, pas d’une page indisponible.

Le coût pertinent n’est d’ailleurs pas seulement celui de l’instance. Il comprend les copies, la capacité maintenue en attente, le transfert de données, le temps des équipes, la perte éventuelle de performance et la durée d’interruption. Aucun de ces montants n’est établi par les sources publiques examinées. L’analyse peut montrer où demander des preuves; elle ne peut pas produire une estimation crédible sans les paramètres de l’acheteur.

Un protocole de vérification pour l’acheteur

La première étape consiste à fixer le périmètre. L’acheteur doit lister les comptes, projets, régions, types d’instances, volumes, images, snapshots, groupes de sécurité, noms DNS et adresses publiques dont dépend chaque application. Il doit relier chaque élément à un objectif de temps de reprise et à un objectif de point de récupération. Sans cette cartographie, une vérification peut réussir sur une ressource secondaire tout en laissant le service critique sans solution.

La deuxième étape porte sur les quotas et la capacité. Pour chaque type CPU ou GPU réellement utilisé, il faut interroger la disponibilité, vérifier le quota du compte et tenter une création contrôlée dans la région principale puis dans la cible de reprise. Le résultat doit enregistrer l’heure, le type exact, le nombre demandé, le nombre obtenu et le délai. Un booléen favorable sans création n’est qu’un signal; une création unique ne prouve pas la capacité d’un parc entier.

La troisième étape teste l’état. Un jeu de données témoin doit être écrit sur un volume ou dans le stockage utilisé par l’application. Il faut prendre un snapshot, exercer le clonage ou la réplication documentée, puis restaurer dans la région cible. La validation doit porter sur l’intégrité, les permissions, la cohérence de l’application et le temps écoulé. Une copie visible dans une liste mais impossible à rattacher ou trop lente à restaurer ne satisfait pas un objectif de reprise.

La quatrième étape traite les images et le démarrage. L’acheteur doit vérifier que l’image choisie est compatible avec le type de remplacement et que le script de démarrage peut atteindre toutes ses dépendances. Les secrets, licences, dépôts et artefacts nécessaires doivent être disponibles par une voie indépendante du domaine de panne simulé. La réussite doit être évaluée au niveau de l’application, pas au simple état « instance active ».

La cinquième étape reconstruit le réseau. Les groupes de sécurité doivent être exportés sous une forme contrôlée, recréés dans la région cible et comparés règle par règle. Les flux entrants, sortants et est-ouest doivent être testés. L’exercice doit vérifier qu’une règle manquante ne bloque pas la restauration et qu’une règle trop large ne transforme pas la reprise en incident de sécurité.

La sixième étape examine le stockage objet. Il faut résoudre le nom réellement fourni au compte depuis les réseaux d’administration et de travail, puis effectuer une lecture et une écriture non destructives sur un objet témoin. Le nom public documenté qui a renvoyé un statut 3 doit être explicitement comparé au point de terminaison attendu. Si une résolution privée ou un autre nom est requis, cette dépendance doit être documentée et testée hors du chemin principal.

La septième étape vérifie le plan de contrôle. L’acheteur doit enregistrer le CNAME et l’adresse A de l’API, confirmer l’ASN de destination et réaliser une commande de lecture suivie d’une opération contrôlée. Le débit de dix requêtes par seconde annoncé doit être intégré à l’automatisation afin qu’une vague de reconstruction ne se bloque pas sur sa propre cadence. Une stratégie de reprise doit prévoir les erreurs, les délais et la reprise des commandes sans créer de doublons dangereux.

La huitième étape relie le service au routage. Les adresses publiques réellement affectées aux charges doivent être recherchées dans les annonces observées, sans supposer qu’elles appartiennent à AS209045. Si AS209045 est attendu, le résultat RIS nul du 20 juillet devient une référence à comparer aux mesures actuelles. Il faut également examiner les sessions pertinentes, tout en distinguant le serveur de routes DE-CIX des relations bilatérales ou de transit qui pourraient exister.

La neuvième étape teste le basculement de nom et de trafic. Une instance restaurée n’est utile que si les utilisateurs peuvent l’atteindre. L’acheteur doit mesurer les délais de modification, la propagation, les certificats et le comportement des caches. Les informations Cloudflare sur la délégation de genesiscloud.com et la dépendance Google Cloud observée pour l’API montrent pourquoi les couches DNS et adresse doivent être testées séparément du calcul.

La dixième étape examine les recours économiques. Les conditions actuelles remises au client doivent préciser les engagements, exclusions, procédures de notification et éventuels crédits. Comme les pages publiques indisponibles ne fournissent pas de base fiable, aucune hypothèse ne doit être inscrite au budget de risque sans document courant. Un crédit, même confirmé, ne remplace d’ailleurs pas la capacité de restaurer des données ou d’obtenir des GPU.

La onzième étape impose un calendrier. Chaque preuve doit porter une date d’exécution et une date d’expiration décidée par l’acheteur. Les tests doivent être répétés après une modification de région, d’image, de type d’instance, de réseau, de contrat ou de dépendance DNS. Le changement entre la visibilité de novembre 2025 et celle de juillet 2026 montre pourquoi une démonstration ancienne ne peut pas être traitée comme permanente.

La douzième étape définit le seuil de décision. Si la capacité de remplacement n’est pas démontrée, si la copie interrégionale échoue, si le point de stockage reste non résolu ou si les chemins réseau ne sont pas compris, l’acheteur doit réduire l’exposition. Cela peut signifier maintenir une copie contrôlée ailleurs, limiter les charges sans état, conserver une capacité alternative ou retarder une dépendance accrue. Le choix dépend du contexte du client; les sources publiques ne prescrivent pas une solution unique.

Ce protocole évite deux fausses assurances. La première consiste à croire qu’une liste de fonctions documentées équivaut à une reprise. La seconde consiste à croire qu’un signal de routage défavorable condamne nécessairement toutes les fonctions. En exerçant chaque couche, l’acheteur transforme des traces publiques de force moyenne en preuves propres à son service.

Ce que l’on peut noter avec une confiance moyenne

Les faits de registre ont une base publique identifiable. Le rôle GCRP3-RIPE, AS209045, ORG-GCL19-RIPE, les ressources associées, les objets de route et les politiques déclarées peuvent être vérifiés dans les services RIPE. Le statut LEI de Genesis Cloud GmbH appartient à une source distincte et porte ses propres limites. Ces informations justifient une confiance moyenne dans l’identité des enregistrements, à condition de ne pas les transformer en affirmations sur la propriété physique ou les contrats.

Les mesures de routage ont elles aussi une confiance moyenne lorsqu’elles conservent leur date et leur observateur. Les chiffres RIS du 20 juillet 2026 sont précis. Les préfixes historiques et le voisin observé en 2025 sont précis dans leurs fenêtres. Les états du looking glass DE-CIX sont précis pour les entrées examinées. Aucun de ces relevés ne prétend couvrir chaque chemin privé, pair bilatéral ou charge.

Les réponses DNS sont également des observations publiques de force moyenne. Elles établissent la résolution de l’API vers une adresse Google Cloud et l’échec de résolution du point de stockage indiqué, depuis Google Public DNS au moment de l’examen. Elles ne décrivent pas tout le DNS, les vues privées ou l’état des données. Leur valeur augmente lorsqu’un acheteur les répète depuis ses propres réseaux.

La documentation de l’API offre enfin une preuve moyenne de l’existence de contrôles décrits: régions, disponibilité, instances, volumes, images, snapshots et groupes de sécurité. Elle ne prouve pas l’exécution réussie. Le passage de la documentation au résultat dépend des quotas, de la capacité, des permissions, de la compatibilité, du réseau et de l’état réel du compte.

Cette échelle de confiance n’est pas un jugement général sur une entreprise. Elle qualifie la relation entre une question et les sources disponibles. Une donnée peut être très solide pour montrer qu’un objet de registre existe et très faible pour montrer qu’un client récupérera son service en deux heures. La rigueur consiste à ne pas transférer la confiance d’une question à l’autre.

Ce qui reste faible jusqu’à un essai propre au client

La capacité physique disponible est faiblement établie. Une fiche de site, un catalogue d’instances et un booléen ne révèlent pas le stock mobilisable pendant une perturbation. Ils ne disent pas si une quantité de GPU équivalents peut être attribuée au même client, dans la région voulue et au moment voulu. Seule une réservation vérifiable ou une création périodique à l’échelle pertinente rapproche l’acheteur d’une réponse.

La réplication du stockage est elle aussi faiblement établie. Les paramètres régionaux et les commandes de clonage montrent une surface prévue, pas l’emplacement des copies, leur indépendance ou leur intégrité. La réponse DNS négative du point documenté ajoute une question d’accès, mais ne répond pas au sort des objets. Un test de restauration avec contrôle d’intégrité est nécessaire.

La redondance de topologie reste inconnue. Les présences à Munich et en Norvège, la connectivité Bulk et les surfaces DE-CIX décrivent des lieux et relations. Elles ne révèlent pas si deux chemins partagent une fibre, une alimentation, une salle, un routeur ou une équipe. Compter des logos ou des sites n’est pas compter des domaines de panne indépendants.

L’indépendance de l’API est également faible. Le chemin public observé passe par une adresse Google Cloud, mais les sources ne montrent ni les mécanismes de secours, ni les dépendances d’authentification, ni le comportement en cas de panne du DNS ou de l’API. Une opération de lecture et une création contrôlée doivent être testées lorsque le reste de l’environnement est sous contrainte.

Les remèdes économiques et juridiques ne sont pas établis. Les pages publiques indisponibles ne peuvent soutenir aucun prix actuel, crédit de niveau de service, délai d’assistance ou identité de responsable de traitement. Seul le contrat courant du client peut répondre, et encore faut-il vérifier la procédure d’activation du recours. Une indemnité ne réduit pas automatiquement le temps de reprise.

Enfin, aucune source ne fournit un exercice complet, daté et propre à un acheteur couvrant quota, capacité de remplacement, snapshot, volume, groupe de sécurité, stockage objet, API, routage et interconnexion. C’est la principale lacune. Elle ne peut être comblée par une formulation plus assurée; elle doit l’être par une exécution mesurée.

La décision raisonnable sous incertitude

Les éléments publics racontent une infrastructure dont les traces administratives persistent tandis que la visibilité RIS d’AS209045 est nulle dans la mesure la plus récente examinée. Ils montrent des ports DE-CIX déclarés opérationnels dans PeeringDB et, simultanément, des sessions de serveur de routes inactives ou passives dans le looking glass. Ils montrent une API documentée et résoluble par une adresse Google Cloud, ainsi qu’un point de stockage objet documenté qui ne se résolvait pas auprès du résolveur interrogé.

La conclusion raisonnable n’est pas de choisir le signal le plus rassurant ou le plus alarmant. Elle est de reconnaître que la continuité administrative, la configuration déclarée, l’observation BGP, la résolution DNS et la capacité de reprise sont des objets différents. Les premiers peuvent guider la diligence; aucun ne remplace la dernière.

Un acheteur peut donc retenir une confiance moyenne dans les faits datés de registre, d’API, de DNS et de visibilité de routes. Il doit conserver une confiance faible dans la capacité physique, la réplication, la disponibilité de GPU substituables, l’indépendance des chemins et la reprise exécutée tant qu’il n’a pas ses propres résultats. Cette frontière protège à la fois contre l’exagération d’une panne et contre l’illusion qu’un inventaire public constitue une garantie.

AS209045 mérite une surveillance renouvelée parce que sa vue de routage a changé entre la fin de 2025 et juillet 2026. Le point de stockage mérite une nouvelle résolution et un essai d’objet. Les contrôles régionaux méritent une restauration complète. Les relations juridiques méritent d’être attribuées à la bonne entité. Ce sont des actions précises, proportionnées aux preuves.

La meilleure décision ne dépendra finalement pas d’une interprétation abstraite des dix gigabits inscrits dans PeeringDB. Elle dépendra de la capacité du client à lancer la bonne machine, récupérer le bon état, reconstruire le bon réseau et rejoindre le service par un chemin mesuré lorsque la voie principale n’est plus disponible. Les sources publiques indiquent où regarder. Seul l’exercice du client peut montrer si la continuité promise existe pour lui.

Sources

  1. RIPE REST, rôle GCRP3-RIPE - https://rest.db.ripe.net/ripe/role/GCRP3-RIPE.json
  2. RIPE RDAP, AS209045 - https://rdap.db.ripe.net/autnum/209045
  3. RIPE REST, organisation ORG-GCL19-RIPE - https://rest.db.ripe.net/ripe/organisation/ORG-GCL19-RIPE.json
  4. RIPE NCC, registres Internet locaux à Malte - https://www.ripe.net/membership/member-support/list-of-members/mt/
  5. GLEIF, LEI 894500D5RP23ET9F9O40 - https://api.gleif.org/api/v1/lei-records/894500D5RP23ET9F9O40
  6. RIPE REST, ressources liées à ORG-GCL19-RIPE - https://rest.db.ripe.net/search.json?query-string=ORG-GCL19-RIPE&type-filter=inetnum&type-filter=inet6num&type-filter=aut-num&inverse-attribute=org&flags=no-referenced&flags=no-filtering
  7. RIPE REST, objets route et route6 pour AS209045 - https://rest.db.ripe.net/search.json?query-string=AS209045&type-filter=route&type-filter=route6&inverse-attribute=origin&flags=no-referenced&flags=no-filtering
  8. RIPE REST, politique aut-num AS209045 - https://rest.db.ripe.net/ripe/aut-num/AS209045.json
  9. PeeringDB, page publique AS209045 - https://www.peeringdb.com/asn/209045
  10. PeeringDB API, AS209045 profondeur 2 - https://www.peeringdb.com/api/net?asn=209045&depth=2
  11. RIPEstat, état de routage AS209045 - https://stat.ripe.net/data/routing-status/data.json?resource=AS209045
  12. RIPEstat, préfixes actuellement annoncés par AS209045 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS209045
  13. RIPEstat, préfixes annoncés par AS209045 de novembre à décembre 2025 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS209045&starttime=2025-11-01T00:00:00&endtime=2025-12-03T00:00:00
  14. RIPEstat, voisins d’AS209045 au 1er décembre 2025 - https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS209045&query_time=2025-12-01T00:00:00&lod=1
  15. RIPEstat, historique RPKI IPv4 d’AS209045 - https://stat.ripe.net/data/rpki-history/data.json?resource=AS209045&family=4&resolution=d
  16. RIPEstat, historique RPKI IPv6 d’AS209045 - https://stat.ripe.net/data/rpki-history/data.json?resource=AS209045&family=6&resolution=d
  17. BGP.tools, AS209045 - https://bgp.tools/as/209045
  18. API looking glass DE-CIX, voisins IPv4 de Francfort - https://lg.de-cix.net/api/v1/routeservers/rs1_fra_ipv4/neighbors
  19. API looking glass DE-CIX, voisins IPv6 de Francfort - https://lg.de-cix.net/api/v1/routeservers/rs1_fra_ipv6/neighbors
  20. API looking glass DE-CIX, voisins IPv4 de Kristiansand - https://lg.de-cix.net/api/v1/routeservers/rs1_krs_ipv4/neighbors
  21. API looking glass DE-CIX, voisins IPv6 de Kristiansand - https://lg.de-cix.net/api/v1/routeservers/rs1_krs_ipv6/neighbors
  22. DE-CIX, actualité sur le peering de Genesis Cloud - https://www.de-cix.net/en/about-de-cix/news/genesis-cloud-enhances-ai-and-hpc-capabilities-with-de-cix-peering
  23. DE-CIX, étude de cas PDF sur Genesis Cloud - https://www.de-cix.net/_Resources/Persistent/7/0/6/4/70646d11ea3d9beea4d676de422368b2bf1ab4e9/AI%20and%20HPC%20in%20the%20Nordics_Genesis%20Cloud%20benefits%20from%20peering%20in%20Frankfurt.pdf
  24. DE-CIX, site de Kristiansand - https://www.de-cix.net/en/locations/kristiansand
  25. Bulk Infrastructure, campus de datacenter N01 - https://bulkinfrastructure.com/data-centers/locations/n01/p3
  26. Bulk Infrastructure, connectivité des datacenters - https://bulkinfrastructure.com/data-centers/connectivity
  27. Genesis Cloud Developers, Compute API - https://developers.genesiscloud.com/compute-api/
  28. Genesis Cloud Developers, régions - https://developers.genesiscloud.com/compute-api/regions/
  29. Genesis Cloud Developers, disponibilité - https://developers.genesiscloud.com/compute-api/availability/
  30. Genesis Cloud Developers, types d’instances - https://developers.genesiscloud.com/compute-api/instance-types/
  31. Genesis Cloud Developers, instances - https://developers.genesiscloud.com/compute-api/instances/
  32. Genesis Cloud Developers, volumes - https://developers.genesiscloud.com/compute-api/volumes/
  33. Genesis Cloud Developers, images - https://developers.genesiscloud.com/compute-api/images/
  34. Genesis Cloud Developers, snapshots - https://developers.genesiscloud.com/compute-api/snapshots/
  35. Genesis Cloud Developers, groupes de sécurité - https://developers.genesiscloud.com/compute-api/security-groups/
  36. Cloudflare RDAP, genesiscloud.com - https://rdap.cloudflare.com/rdap/v1/domain/genesiscloud.com
  37. Google Public DNS, CNAME de api.genesiscloud.com - https://dns.google/resolve?name=api.genesiscloud.com&type=CNAME
  38. Google Public DNS, adresse A de api.genesiscloud.com - https://dns.google/resolve?name=api.genesiscloud.com&type=A
  39. RIPEstat network-info, 34.76.254.30 - https://stat.ripe.net/data/network-info/data.json?resource=34.76.254.30
  40. ARIN RDAP, AS396982 - https://rdap.arin.net/registry/autnum/396982
  41. Google Public DNS, adresse A de s3.nord-no-krs-1.genesiscloudusercontent.com - https://dns.google/resolve?name=s3.nord-no-krs-1.genesiscloudusercontent.com&type=A
  42. Google Public DNS, enregistrement NS de genesiscloudusercontent.com - https://dns.google/resolve?name=genesiscloudusercontent.com&type=NS