Pour juger Global Cloud Co., Ltd, il faut suivre les routes

Summary

Les données d’ARIN et de RIPEstat rattachent clairement AS63199 à CDS Global Cloud Co., Ltd et montrent un système autonome largement visible, avec 547 préfixes observés sur la fenêtre du 6 au 20 juillet 2026.
Les 26 rattachements à des points d’échange et les 26 présences en sites déclarés dans PeeringDB étayent l’image d’un opérateur d’interconnexion étendu, mais ne démontrent ni les volumes de trafic, ni les contrats de transit, ni la capacité utilisable par un client donné.
Les offres GPN, PIR, Global DIA et CloudConnect placent la valeur commerciale dans la sélection des chemins vers et depuis la Chine. Leurs chiffres de couverture, leurs engagements et leur positionnement réglementaire restent principalement des affirmations de l’entreprise à vérifier dans le contrat et sur le terrain.

Le cloud disparaît dès que l’on regarde le chemin

L’expression « global cloud » invite à commencer par les machines virtuelles, les capacités de calcul ou le nombre de centres de données. Pour Global Cloud Co., Ltd, le dossier public conduit ailleurs. Les éléments les plus vérifiables ne décrivent pas un inventaire de serveurs: ils décrivent une identité de routage, des préfixes annoncés, des voisinages observés et une distribution de points d’échange et de sites. C’est donc par le chemin réseau qu’il faut évaluer la proposition.

Cette distinction importe particulièrement pour une entreprise qui veut relier des applications internationales à des utilisateurs, bureaux ou partenaires en Chine continentale. Dans ce cas, « être présent dans le cloud » ne dit presque rien sur l’expérience réelle. Le paquet peut emprunter plusieurs opérateurs, traverser des points de congestion, changer de route selon l’heure ou la panne, puis entrer dans un environnement réglementaire et commercial qui n’est pas celui d’une simple liaison domestique. Le service acheté est moins une destination qu’une chaîne de décisions de routage, de responsabilités et d’escalade.

Le site de CDS Global Cloud présente justement l’entreprise comme un fournisseur d’infrastructure pour des organisations internationales. Il associe cette proposition à deux numéros de système autonome, AS63199 et AS38353, à un Global Private Network et à plusieurs produits d’accès optimisé. Mais le paquet de sources ne ferme pas ces affirmations de la même manière. AS63199 dispose d’une identité externe solide et d’une empreinte observable. AS38353 reste, ici, un système autonome compagnon revendiqué par l’entreprise: aucune conclusion indépendante sur son activité ne doit être tirée de ce seul dossier.

Une identité de routage fermement ancrée

Le premier point d’appui vient d’ARIN. Son enregistrement RDAP identifie AS63199 sous le nom CDSC-AS1 et le relie à CDS Global Cloud Co., Ltd. La date d’enregistrement affichée est le 8 septembre 2014; la dernière modification est datée du 9 janvier 2026. L’enregistrement de l’organisation CDSC-1 renvoie lui aussi à CDS Global Cloud Co., Ltd, avec une création au 2 juin 2014 et une dernière modification au 9 janvier 2026.

Un troisième enregistrement ARIN attribue directement à CDSC-1 la plage allant de 148.153.0.0 à 148.153.255.255, sous le nom NET-148-153-0-0-1, depuis le 12 janvier 2016. Cette allocation établit une ressource de numérotation liée à l’organisation. Elle n’indique pas que chaque adresse est annoncée, utilisée, vendue à un client ou disponible dans une région donnée.

RIPEstat confirme une autre dimension: AS63199 était annoncé lors de la collecte. Son aperçu associe la ressource 63199 au détenteur CDSC-AS1 - CDS Global Cloud Co., Ltd et indique une attribution par ARIN. Sur la fenêtre d’observation allant du 6 au 20 juillet 2026, l’API des préfixes annoncés a retourné 547 préfixes. Parmi les exemples figurent 38.123.107.0/24, 148.153.219.0/24, 118.193.20.0/24 et, en IPv6, 2400:5280:804::/48.

Le chiffre de 547 est une photographie, pas une constante patrimoniale. Il peut évoluer avec les annonces BGP, les retraits, les délégations et la visibilité des collecteurs. Il ne se compare pas mécaniquement aux champs info_prefixes4=200 et info_prefixes6=10 du profil PeeringDB: ces valeurs sont déclaratives, peuvent suivre une autre définition et ont leur propre date de mise à jour. Leur écart appelle une explication opérationnelle, non une accusation automatique d’incohérence.

Cette différence de périmètre est précisément ce qui rend l’examen utile. Le nombre produit par RIPEstat correspond à des préfixes vus pendant une fenêtre déterminée, tandis que le profil PeeringDB exprime ce que le réseau a choisi de déclarer dans un annuaire professionnel. L’un renseigne sur l’observation du routage; l’autre sur la présentation de l’opérateur aux partenaires d’interconnexion. Aucun des deux ne constitue un inventaire de clients, de contrats ou de capacités. Les rapprocher permet de formuler des questions, mais pas de fabriquer une réponse qui ne figure dans aucune source.

Un acheteur devrait notamment demander comment Global Cloud Co., Ltd classe les préfixes qu’AS63199 annonce: ressources propres, blocs de clients, annonces temporaires, agrégats ou routes plus spécifiques. Cette ventilation ne se déduit pas du seul total. Elle importe pourtant pour apprécier le rayon d’action du réseau et les conséquences d’un incident. Un grand nombre de routes peut refléter une activité étendue; il peut également augmenter la surface de configuration, le nombre de filtres à maintenir et le besoin d’une discipline rigoureuse dans les registres de routage.

L’allocation directe 148.153.0.0 à 148.153.255.255 apporte ici une ancre distincte. ARIN relie ce bloc à CDSC-1, mais l’enregistrement ne décrit ni sa fragmentation opérationnelle ni les services qui l’emploient. Le fait que 148.153.219.0/24 apparaisse parmi les exemples observés par RIPEstat rapproche registre et routage sur une partie de l’espace d’adressage. Il ne permet toujours pas d’attribuer l’usage de chaque sous-réseau, de confirmer sa localisation physique ou de promettre qu’un client recevra une adresse issue de cette plage.

La présence d’un exemple IPv6, 2400:5280:804::/48, mérite également d’être lue avec prudence. Elle montre que l’observation ne se limite pas à IPv4, et le statut de routage indique une visibilité d’AS63199 auprès des pairs RIS IPv6 interrogés. Cela ne suffit pas à conclure à une parité complète des produits entre les deux familles d’adresses. Une diligence technique devrait vérifier séparément la livraison IPv4 et IPv6, les politiques de filtrage, les routes par défaut, la protection contre les annonces erronées et les conditions de bascule. Une offre peut être double pile sur le papier tout en conservant des chemins, des capacités ou des procédures d’incident différents.

Une preuve publique a une portée, pas seulement une source

Le dossier combine trois familles de matériaux qu’il faut garder séparées. Les données RDAP d’ARIN établissent des identités et des allocations administratives. Les réponses de RIPEstat décrivent ce que des collecteurs ont observé dans BGP à un moment ou sur une période donnée. Les fiches PeeringDB déclarent des caractéristiques de réseau, des points d’échange et des sites. Enfin, les pages de CDS Global Cloud exposent une architecture commerciale, des produits, des chiffres de couverture et une position sur la conformité.

La solidité n’est donc pas binaire. L’identité d’AS63199 est fortement étayée parce que le registre, l’aperçu RIPEstat et la fiche PeeringDB convergent autour de CDS Global Cloud Co., Ltd. La portée de l’offre GPN ou le SLA de PIR relèvent d’un autre niveau: ces éléments proviennent de l’entreprise et ne sont accompagnés, dans ce paquet, ni d’un contrat type complet, ni d’une série de mesures indépendantes. Une analyse sérieuse ne doit ni ignorer ces affirmations, ni leur attribuer la même force qu’à un enregistrement de ressource.

Cette hiérarchie permet aussi de résister à deux raccourcis opposés. Le premier consisterait à prendre toute donnée déclarative pour une preuve définitive. Le second serait de rejeter toute page du fournisseur comme inutile. Or la documentation commerciale indique ce que l’entreprise promet de vendre, comment elle découpe son catalogue et quelles responsabilités elle semble vouloir assumer. Elle devient exploitable lorsque chaque promesse est reliée à une pièce à demander: schéma de chemin, bon de commande, annexe de service, mesure de performance, référence de licence, liste de partenaires ou procédure d’escalade.

Pour un comité d’achat, la bonne pratique consiste à créer une matrice où chaque affirmation porte quatre attributs: son auteur, sa date, ce qu’elle démontre exactement et ce qui reste à vérifier. Ainsi, « AS63199 est annoncé » ne devient pas « le circuit client sera disponible »; « 26 rattachements à des échanges sont déclarés » ne devient pas « 26 chemins indépendants sont garantis »; « GPN est entièrement maillé » ne devient pas « chaque site client dispose de deux routes sans domaine de panne commun ». La matrice oblige la décision à rester au niveau de preuve réellement disponible.

Cette discipline est d’autant plus importante que les dates diffèrent. Le profil PeeringDB a été mis à jour le 12 juin 2026, les observations RIPEstat couvrent ou reflètent juillet 2026, et les enregistrements ARIN affichent leurs propres dates de création et de modification. Ces horodatages n’invalident rien, mais ils interdisent de traiter l’ensemble comme un instantané synchronisé. Avant un engagement, les éléments sensibles au temps doivent être revérifiés et rattachés à la configuration proposée, pas seulement à l’identité générale du réseau.

La visibilité est néanmoins large dans l’échantillon RIPEstat. Au moment de la requête du 20 juillet 2026 à 16 h UTC, les 325 pairs RIS observant l’IPv4 et les 320 observant l’IPv6 voyaient AS63199. La série de routage fait remonter une première observation au 2 avril 2015 avec 139.159.48.0/24 et une observation récente avec 154.223.132.0/24. Cela démontre qu’AS63199 n’est pas seulement un identifiant posé sur une page commerciale. Cela ne mesure ni la latence d’un client, ni la stabilité d’un circuit, ni la qualité du support.

Les voisins BGP ne sont pas un carnet de contrats

L’API de voisinage de RIPEstat a retourné 211 systèmes autonomes observés autour d’AS63199. Des entrées à forte puissance dans l’échantillon incluent AS174, AS1299, AS12956 et AS17408. Ces données sont utiles parce qu’elles montrent qu’AS63199 participe à un environnement de routage dense. Elles sont dangereuses lorsqu’on leur fait dire davantage.

Un voisin observé n’est pas nécessairement un fournisseur payé, un client, un pair direct durable ou un engagement commercial en vigueur. La relation peut être visible à travers les données collectées sans que sa nature contractuelle soit publique. De même, une route vue par de nombreux collecteurs ne révèle pas les préférences locales, les communautés BGP, les filtres, les politiques de retour ou les mécanismes de bascule appliqués au trafic d’une entreprise particulière.

Cette réserve vaut aussi pour les noms d’opérateurs cités par CDS Global Cloud. La page consacrée au transit BGP distingue un service China Blended associé à AS38353 d’une offre Global BGP. Elle affirme des interconnexions avec China Telecom, China Unicom, China Netcom et CERNET pour le premier, puis avec PCCW, NTT, TATA, Zayo, Level 3 et HE pour le second. Ce sont des indications commerciales pertinentes pour préparer une vérification. Le paquet ne contient cependant ni contrats, ni identifiants de sessions, ni mesures permettant de confirmer que chaque relation est active et applicable au circuit proposé.

Pour l’acheteur, la bonne question n’est donc pas « avec combien d’opérateurs êtes-vous connectés ? », mais « quels chemins aller et retour utilisera précisément mon trafic, selon quelle politique, depuis quels sites, et avec quelle solution de repli ? ». Une liste de noms peut ouvrir l’enquête; elle ne la clôt pas.

Le trajet retour peut défaire la promesse du trajet aller

Une architecture d’accès n’est pas jugée sur une seule flèche. BGP permet que le chemin vers une destination et le chemin de retour suivent des opérateurs, des villes et des politiques différents. Pour un service entre la Chine et une application internationale, cette asymétrie peut modifier la latence, la perte de paquets, la capacité de diagnostic et même l’équipe responsable de l’incident. Un fournisseur peut maîtriser une partie du trajet aller sans disposer de la même influence sur le retour.

Les observations de voisinage autour d’AS63199 montrent une surface relationnelle assez riche pour rendre plusieurs chemins plausibles. Elles ne disent toutefois pas quel chemin sera préféré depuis un bureau précis, un réseau mobile, une boucle d’entreprise ou une région cloud. Elles ne révèlent pas non plus les communautés BGP utilisées pour influencer les annonces, les règles de préférence locale, les mécanismes de protection contre les fuites de routes ou les délais de convergence après une coupure. Ces paramètres sont souvent plus décisifs pour l’expérience que le nombre brut de voisins.

Il faut donc demander une démonstration bidirectionnelle. Pour chaque cas d’usage important, le fournisseur devrait montrer des traces depuis le site de départ vers la destination et, lorsque c’est techniquement possible, depuis la destination vers le site. Les mesures doivent être répétées, car une trace unique ne capture ni les changements de politique ni les variations d’heure chargée. Le résultat attendu n’est pas nécessairement un chemin immuable, mais un ensemble de chemins acceptables, leurs conditions d’emploi et les seuils qui déclenchent une intervention.

La même logique vaut pendant une panne. Une bascule qui rétablit la joignabilité en quelques secondes peut encore dégrader fortement le service si elle envoie le trafic sur une route plus longue, saturée ou mal adaptée aux flux interactifs. Inversement, un changement visible dans le chemin n’est pas automatiquement un défaut s’il maintient les objectifs de perte, de latence et de gigue. Le contrat doit donc lier la topologie aux résultats, sans confondre stabilité de route et qualité de service.

Cette approche aide aussi à répartir les responsabilités. Si une boucle locale, un port d’échange, un transport international et une remise cloud relèvent de sociétés différentes, le client ne devrait pas avoir à reconstituer seul le domaine fautif. Le fournisseur principal doit préciser qui observe chaque segment, qui peut ouvrir un ticket auprès du partenaire suivant et quel centre de supervision garde la responsabilité de bout en bout. Une route optimisée perd une grande partie de sa valeur si l’escalade s’arrête à la première frontière contractuelle.

Enfin, le trajet retour doit être intégré aux changements planifiés. Une nouvelle annonce, une modification de filtrage ou le déplacement d’un point de remise peut améliorer une région et en dégrader une autre. Le client a besoin d’un préavis, d’une méthode de comparaison avant et après, et d’un moyen de revenir à la configuration précédente lorsque les seuils convenus ne sont plus respectés. La visibilité publique d’AS63199 rend ce contrôle possible en partie; elle ne remplace pas la coopération opérationnelle nécessaire pour l’exercer.

PeeringDB dessine une surface d’interconnexion

Le profil réseau retourné par PeeringDB apporte une deuxième couche d’observation. Il recense un réseau, identifiant 8581, nommé CDS Global Cloud Co., LTD, pour AS63199. Le profil se classe comme NSP, indique une politique générale Open, ne déclare pas d’exigence de ratio et associe l’ensemble IRR AS-CAPITALONLINEDATA. Il a été mis à jour le 12 juin 2026.

La distribution géographique est plus instructive que l’étiquette. PeeringDB retourne 26 rattachements opérationnels à des points d’échange. L’échantillon comprend IX.br Sao Paulo, DE-CIX Frankfurt, Equinix Singapore, Equinix Hong Kong, HKIX, SGIX, BBIX Singapore, Equinix Dallas, Equinix Miami, JPNAP Tokyo, BBIX Tokyo, FL-IX et IIX-Jakarta. Ce maillage déclaré place AS63199 dans plusieurs marchés d’interconnexion d’Amérique, d’Europe et d’Asie.

L’API des sites recense également 26 rattachements, répartis entre les États-Unis, l’Allemagne, la Corée, le Brésil, Singapour, Hong Kong, le Japon, la Chine continentale et Taïwan. Parmi les sites nommés figurent Equinix DA1, Equinix SG3, Equinix TY4, Equinix HK2, Digital Realty LAX, DataBank Dallas/Miami, Chief Taipei, KINX Seoul et des sites Capital Online à Pékin.

Cette double présence, échanges et sites, étaye l’idée d’un opérateur orienté interconnexion. Elle ne prouve pas que Global Cloud Co., Ltd possède les bâtiments, les salles ou les baies correspondantes. PeeringDB est un registre industriel largement utilisé, mais ses profils sont entretenus par les réseaux eux-mêmes. Une présence déclarée ne renseigne ni le port effectivement provisionné pour un client, ni son taux d’occupation, ni le trafic actif, ni le stock de pièces, ni le personnel disponible à toute heure.

Il faut aussi éviter de confondre géographie d’interconnexion et géographie de service. Un réseau peut être présent à un échange sans pouvoir livrer le produit demandé dans chaque bâtiment de la ville. Il peut remettre une liaison à un partenaire, changer de domaine opérationnel ou dépendre d’une boucle locale distincte. Pour transformer les 26 plus 26 rattachements en proposition exploitable, l’acheteur doit obtenir la matrice exacte entre site client, point de livraison, port d’échange, transport intermédiaire et destination cloud.

Les échanges et les sites forment une carte d’options

La répartition déclarée dans PeeringDB a néanmoins une valeur stratégique. Elle place des points de présence potentiels à proximité de plusieurs grands marchés: Singapour, Hong Kong, Tokyo et Jakarta en Asie; Francfort en Europe; Dallas, Miami et la côte ouest aux États-Unis; São Paulo au Brésil. Pour une entreprise dont les utilisateurs et applications sont eux-mêmes distribués, cette carte peut réduire le nombre de longues traversées inutiles, à condition que le trafic soit effectivement remis au bon endroit.

Le mot important est « potentiels ». Un rattachement à HKIX ou SGIX signifie qu’une fiche opérationnelle associe le réseau à cet échange. Il ne précise pas si le service proposé au client utilisera ce port, si les sessions pertinentes sont établies, quelle capacité y est engagée, ni si une autre liaison partage le même transport physique. De même, une présence à Equinix SG3, Equinix TY4 ou Equinix HK2 ne garantit pas qu’une commande puisse y être livrée dans le délai, au débit et avec la redondance demandés.

Pour passer de la carte publique à une architecture, le fournisseur devrait produire une matrice de livraison par produit. Chaque ligne associerait un site de départ, une interface client, un service tel que GPN ou PIR, un ou plusieurs points de remise, une destination et une route de secours. Elle indiquerait aussi si le segment est exploité directement, loué ou fourni par un partenaire. Sans cette vue, les listes de sites et d’échanges risquent d’être additionnées alors qu’elles décrivent parfois les mêmes dépendances sous deux angles.

La notion d’indépendance physique doit être traitée séparément de l’indépendance logique. Deux ports dans deux équipements peuvent rejoindre le même chemin de fibre; deux sites peuvent dépendre du même opérateur métropolitain; deux routes BGP peuvent traverser le même câble ou le même point d’atterrissement. Le paquet mentionne des revendications de diversité d’opérateurs, de lignes et de routes pour GPN, mais il ne fournit pas les tracés qui permettraient de vérifier cette séparation pour un client. C’est une question à documenter, non un défaut que l’on peut déduire d’emblée.

La présence de sites Capital Online à Pékin illustre une autre difficulté: un nom de site peut signaler une relation opérationnelle plus proche de l’entreprise, mais le dossier ne permet pas d’en déduire la propriété, la surface occupée ou les ressources disponibles. À l’inverse, une installation exploitée par un tiers peut offrir un service robuste si les contrats, les pièces de rechange et l’accès aux techniciens sont bien organisés. Le critère pertinent n’est pas une opposition simpliste entre « propre » et « partenaire »; c’est la capacité à prouver qui fait quoi, dans quel délai et sous quelle obligation.

Ces questions deviennent concrètes au moment d’un incident. Un port peut rester administrativement actif alors que la qualité du transport en amont se détériore. Un technicien du site peut vérifier une fibre sans être autorisé à modifier une politique de routage. Une équipe réseau peut voir la perte sans contrôler la boucle locale. La matrice de livraison doit donc être accompagnée d’une matrice d’escalade, avec une responsabilité nommée pour chaque frontière. C’est cette organisation, plus que le nombre d’icônes sur une carte, qui transforme une présence internationale en service opérable.

La couverture commerciale doit être réconciliée produit par produit

Les pages de l’entreprise utilisent plusieurs échelles: plus de dix centres de données à service complet, plus de cinquante sites satellites en Chine continentale, une liste de pays et de villes, puis pour Enhanced Internet plus de 50 pays, 89 villes, plus de 400 opérateurs, près de 100 câbles sous-marins dédiés et 94 centres de données. Ces chiffres peuvent tous correspondre à des périmètres différents. Le dossier ne fournit pas le dictionnaire qui permettrait de les additionner ou de les comparer directement.

Une lecture prudente commence donc par demander ce que chaque unité désigne. Un « centre de données » peut être un bâtiment où l’entreprise a une présence, un site partenaire accessible, un lieu de remise commerciale ou une installation dans laquelle elle exploite des équipements. Une « ville couverte » peut signifier livraison sur réseau propre, accès via partenaire ou simple destination joignable. Un « opérateur » peut intervenir dans une seule région, un seul produit ou une capacité de secours. Sans définitions, le total le plus élevé crée une impression d’échelle mais ne dimensionne aucun service.

La réconciliation devrait prendre la forme d’un tableau daté, limité au projet du client. Il n’est pas nécessaire de vérifier les 94 sites revendiqués si l’entreprise n’en utilisera que quatre. En revanche, pour ces quatre sites, il faut connaître l’adresse de remise, la nature de la présence, le fournisseur de la boucle, le port prévu, le débit livré, le chemin de secours et les heures de support. Cette réduction du catalogue à l’architecture réelle est un gain de précision, pas une perte d’ambition.

Elle permet aussi de tester la cohérence entre PeeringDB et les pages commerciales sans exiger qu’elles décrivent exactement la même chose. Les 26 sites de la fiche réseau concernent AS63199 et un profil d’interconnexion. Les implantations commerciales peuvent couvrir d’autres ressources, des partenaires ou le système AS38353 que ce paquet ne vérifie pas indépendamment. Le fournisseur peut expliquer cette différence. Tant qu’il ne le fait pas, l’acheteur doit éviter de transférer automatiquement la preuve obtenue pour AS63199 à tout le catalogue.

Enfin, les chiffres de couverture doivent être datés dans le contrat ou l’annexe technique. Une présence réseau évolue: ports ajoutés ou retirés, capacités modifiées, partenaires remplacés. La page publique fournit un point de départ; la commande doit figer les éléments dont dépend le service et prévoir une notification lorsque l’un d’eux change. Sans cette obligation, une architecture choisie pour sa proximité ou sa diversité peut dériver sans que le client dispose d’un critère clair pour la réévaluer.

La Chine est une question de chemin et de responsabilité

Les pages de CDS Global Cloud décrivent une empreinte commerciale qui couvre la Chine, les États-Unis, Singapour, l’Indonésie, le Vietnam, le Japon, l’Allemagne, Hong Kong, Taïwan, les Pays-Bas et la Corée du Sud. La page d’accueil avance plus de dix centres de données à service complet dans le monde et plus de cinquante sites satellites en Chine continentale. La page des implantations évoque dix centres clés à Pékin, ainsi que Guangzhou, Shanghai, Wuxi et Wuhan, auxquels s’ajouteraient plus de cinquante centres satellites.

Ces chiffres sont utiles comme carte de l’offre revendiquée, pas comme inventaire audité. Une autre page, consacrée à Enhanced Internet, parle de plus de 50 pays, 89 villes, plus de 400 opérateurs, près de 100 câbles sous-marins dédiés et 94 centres de données. Les périmètres ne sont pas explicitement réconciliés. « Site satellite », « centre de données », présence partenaire, destination desservie et infrastructure exploitée ne sont pas forcément des catégories équivalentes.

La promesse centrale réside plutôt dans la façon dont CDS Global Cloud dit assembler ces implantations. La page GPN décrit un Global Private Network de couche 2 entièrement maillé entre la Chine, l’Asie-Pacifique, l’Amérique du Nord et l’Europe. Elle met en avant la diversité des opérateurs, des lignes et des routes, avec des usages tels que dorsale WAN, Ethernet point à point, IEPL, SD-WAN, EVPL/VPL et VPN d’entreprise.

Sur le papier, cette architecture répond à un vrai problème: donner à une entreprise une sous-couche cohérente lorsque l’Internet public entre les bureaux chinois et des applications mondiales est imprévisible. Mais le terme « entièrement maillé » ne révèle pas la topologie réservée à un client. Il faut connaître les nœuds réellement utilisés, les domaines de panne partagés, les fournisseurs locaux, le comportement en cas de coupure et le temps nécessaire pour revenir au chemin nominal. Sans schéma client, tests de bascule et responsabilités nominatives, la diversité reste une propriété annoncée de la plateforme.

Quatre usages, quatre chemins à instruire

La formule générale « accès depuis la Chine » masque des besoins qui ne se ressemblent pas. Un bureau qui consulte une application de gestion hébergée à Singapour, une usine qui synchronise des données avec l’Europe, une équipe de développement qui rejoint plusieurs clouds et un site international qui sert des utilisateurs chinois n’imposent ni les mêmes flux ni les mêmes contraintes. Les regrouper sous un seul indicateur moyen conduirait à acheter une promesse trop large pour être contrôlée.

Dans le premier cas, l’enjeu peut être la régularité d’une application interactive pendant les heures de bureau locales. Le test doit alors porter sur la latence aller-retour, la gigue, la perte et la stabilité des sessions depuis le site réel. Dans le deuxième, la capacité soutenue et le comportement des transferts longs deviennent plus importants. Le troisième cas exige de distinguer les régions et les points d’entrée de chaque fournisseur cloud. Le quatrième inverse le sens principal du trafic et rend particulièrement visible le problème du chemin retour.

GPN, Global DIA, PIR et CloudConnect peuvent participer à ces architectures, mais le dossier ne permet pas de les traiter comme des substituts parfaits. GPN est présenté comme un réseau privé de couche 2 pour relier des implantations. PIR relève du transit IP optimisé. Global DIA vise un accès dynamique aux applications cloud depuis la Chine continentale. CloudConnect ajoute une connexion à des clouds via Equinix Cloud Exchange. Chaque produit déplace la frontière entre réseau privé, Internet, partenaire d’échange et destination cloud.

L’acheteur devrait donc partir de ses flux plutôt que du catalogue. Pour chaque application, il faut identifier les utilisateurs, les sites, la destination, le sens dominant, les périodes critiques, la sensibilité à la perte et le niveau de reprise acceptable. Le fournisseur peut ensuite proposer un assemblage et montrer quelle partie de la chaîne répond à chaque exigence. Cette méthode évite qu’un bon résultat sur une démonstration à Shanghai soit supposé valable pour un bureau à Guangzhou, une destination à Francfort ou un trafic entrant depuis les États-Unis.

Elle évite également de demander une uniformité irréaliste. Un réseau mondial n’offre pas le même chemin partout; l’objectif raisonnable est une qualité définie et mesurable pour les cas d’usage retenus. Le contrat peut admettre des architectures différentes selon les régions, à condition que leurs différences soient explicites. Ce qui doit rester commun, c’est la méthode de mesure, la responsabilité de l’escalade et la capacité à expliquer un changement de route.

Enfin, cette segmentation facilite une décision progressive. Une entreprise peut commencer par les deux flux les plus critiques, établir une référence, puis étendre le service lorsque les résultats sont reproductibles. La présence publique d’AS63199 et les options d’interconnexion donnent des raisons de mener ce pilote. Elles ne justifient pas de sauter directement à une généralisation mondiale sans preuves au niveau des sites et des applications.

PIR, Global DIA et CloudConnect: trois niveaux de preuve

Premium Internet Routing, abrégé PIR, est présenté comme un transit IP optimisé. La page affirme qu’AS63199 est appairé avec plus de 200 opérateurs mondiaux, dont des opérateurs chinois, et propose aux utilisateurs en Chine un accès à des serveurs hors du pays avec un SLA de 99,9 %. Elle annonce une facturation au mégabit par seconde ou à l’usage et des pointes jusqu’à 10 Gbit/s.

Ces éléments décrivent un produit commercial, non son résultat universel. Le nombre d’opérateurs, le niveau de service et la capacité de pointe proviennent de l’entreprise. Leur sens dépend du point de mesure, des exclusions, de la période de calcul, du niveau de saturation admis et du crédit prévu en cas de non-respect. Un débit de pointe n’est pas une capacité soutenue; un taux de disponibilité ne garantit pas un aller-retour symétrique ni une faible perte de paquets.

Global DIA vise plus directement l’accès aux applications cloud depuis la Chine continentale. CDS Global Cloud le présente comme une sous-couche à routage dynamique réservée aux entreprises et assortie de restrictions. La page montre un exemple SmokePing à Shanghai où un accès DIA ordinaire aurait subi en moyenne 20,97 % de perte de paquets pendant dix jours. Ce cas illustre le problème que le produit veut résoudre. Il ne constitue ni une mesure indépendante, ni une moyenne du marché, ni une preuve de la performance actuelle de Global DIA sur tous les chemins.

CloudConnect ajoute l’accès direct à plusieurs clouds via Equinix Cloud Exchange, avec GPN pour la connectivité mondiale à la demande. L’idée est cohérente: réduire la part d’Internet public et rapprocher le trafic des points d’entrée des fournisseurs cloud. Pourtant, la page ne permet pas de savoir quels sites clients peuvent joindre quelles régions cloud, par quel service d’accès, avec quelles redondances et quelles limites de débit. Le nom d’une bourse cloud décrit un mécanisme possible, pas un circuit livré.

Enhanced Internet rassemble encore davantage de composants: GPN, échanges cloud et vaste couverture revendiquée. La largeur du catalogue peut être un avantage pour un acheteur multi-pays. Elle augmente aussi le besoin de décomposer l’offre. Chaque tronçon doit être classé comme infrastructure propre, présence louée, service d’un partenaire ou simple destination accessible. C’est seulement à ce niveau que l’on peut attribuer la surveillance, l’escalade et les pénalités.

Un SLA ne vaut que par son point de mesure

L’engagement de 99,9 % annoncé pour PIR paraît précis, mais sa portée ne peut être comprise sans méthode de calcul. Sur un mois de trente jours, ce pourcentage correspondrait à une durée théorique d’indisponibilité limitée; cette arithmétique reste toutefois secondaire tant que l’on ne sait pas ce que le fournisseur appelle indisponibilité. Un port hors service, une perte élevée, une route très dégradée et une destination devenue inutilisable peuvent être comptés différemment.

Le premier document à obtenir est donc la définition du point de mesure. Le SLA commence-t-il à l’interface du client, au point de remise de Global Cloud Co., Ltd, à l’entrée d’un partenaire ou dans le cœur d’AS63199 ? Se termine-t-il à une autre interface gérée, à une région cloud ou à la sortie du réseau ? Si la boucle locale ou le dernier segment vers le cloud est exclu, un indicateur de cœur de réseau peut rester conforme alors que l’application est inaccessible.

La période de calcul compte autant. Une moyenne mensuelle peut absorber plusieurs épisodes courts très pénalisants pour une activité transactionnelle. Un objectif de disponibilité ne dit rien, à lui seul, sur la perte, la latence ou la gigue. Le client doit définir des seuils séparés, une fréquence d’échantillonnage et une règle pour les mesures manquantes. Il doit aussi savoir si les maintenances programmées, les événements attribués à des tiers ou certaines restrictions réglementaires sont exclus du calcul.

Le mécanisme de crédit révèle ensuite la valeur économique de l’engagement. Un remboursement limité à une fraction du prix du port ne compense pas nécessairement l’arrêt d’une application, mais il peut inciter à une meilleure discipline opérationnelle s’il est déclenché automatiquement et fondé sur des mesures partagées. À l’inverse, un crédit qui exige au client de prouver seul l’incident dans un délai très court protège surtout le fournisseur. L’objectif n’est pas d’obtenir une pénalité spectaculaire; c’est d’aligner définition, observation et réaction.

La revendication de pointes jusqu’à 10 Gbit/s nécessite le même traitement. Une pointe autorisée ne décrit ni le débit engagé ni la durée pendant laquelle elle peut être soutenue. Elle ne précise pas davantage si la capacité est disponible sur tous les sites, si elle dépend d’un mécanisme de facturation particulier ou si les partenaires intermédiaires appliquent leurs propres limites. Un test de charge progressif doit vérifier le comportement avant saturation, pendant la pointe et au retour à la normale.

Enfin, le SLA doit prévoir le changement de chemin. Si le service reste joignable par une route de secours qui augmente nettement la latence, la disponibilité binaire peut rester conforme alors que la qualité ne l’est plus. Le contrat devrait donc distinguer indisponibilité, dégradation et bascule, avec des seuils adaptés aux applications critiques. La promesse de routage optimisé devient alors vérifiable: elle n’est plus seulement un nom de produit, mais une série de résultats observables sur un chemin défini.

CloudConnect ne supprime pas les frontières opérationnelles

L’usage d’Equinix Cloud Exchange présenté pour CloudConnect peut raccourcir la partie publique du trajet et offrir une remise plus directe vers plusieurs clouds. Cela ne transforme pas pour autant la chaîne en liaison unique. Il reste un accès depuis le site du client, un transport jusqu’au point d’échange, une interface vers le fournisseur cloud et une configuration à l’intérieur du compte ou du réseau virtuel du client. Chacune de ces étapes peut avoir sa propre commande, sa propre capacité et son propre calendrier.

Une proposition CloudConnect devrait donc nommer les régions cloud réellement accessibles depuis chaque point de remise, plutôt que de promettre « plusieurs clouds » en général. Elle devrait indiquer qui fournit les identifiants ou clés de service, qui configure le routage, comment les préfixes sont filtrés et où se situe la limite de dépannage. Le paquet de sources confirme le positionnement du produit autour d’Equinix Cloud Exchange et de GPN; il ne livre pas cette matrice détaillée.

La redondance doit également être démontrée de bout en bout. Deux connexions logiques vers un cloud peuvent partager le même port physique ou le même transport jusqu’à l’échange. Deux points d’accès distincts peuvent converger vers la même région et le même équipement en amont. La conception devrait expliciter les domaines de panne, puis les essais devraient couper réellement un composant à la fois. Une capture d’écran montrant deux liens actifs ne prouve pas que la bascule fonctionne lorsque le chemin commun disparaît.

Le rôle de GPN dans cet assemblage mérite une description précise. La page le présente comme la connectivité mondiale à la demande qui alimente CloudConnect. Pour le client, il faut savoir si GPN transporte le trafic jusqu’au même site que l’interconnexion cloud, quelles garanties s’appliquent à ce segment et comment son état est corrélé avec celui du port cloud. Sans cette séparation, un incident GPN peut être perçu comme une panne cloud, et chaque équipe peut renvoyer l’enquête vers l’autre.

La sécurité de routage entre aussi dans le périmètre sans que le dossier permette de conclure à un mécanisme particulier. L’acheteur doit demander les règles de filtrage des préfixes, les limites d’annonce, la gestion des routes par défaut et la procédure de modification. Ces contrôles sont essentiels lorsque plusieurs réseaux et comptes cloud se rencontrent. Ils ne doivent pas être supposés à partir de la seule présence d’AS63199 ou de l’ensemble IRR AS-CAPITALONLINEDATA déclaré dans PeeringDB.

CloudConnect peut ainsi être une pièce crédible d’une architecture internationale, mais sa valeur dépend de la clarté des interfaces. Plus le chemin quitte l’Internet public, plus le client doit savoir qui contrôle chaque segment. La connexion directe réduit certains aléas; elle ne dispense ni du dimensionnement, ni de la supervision, ni d’une procédure commune entre Global Cloud Co., Ltd, l’opérateur de l’échange et le fournisseur cloud.

La conformité n’est pas un attribut du paquet BGP

La page Legal Compliance de CDS Global Cloud affirme que l’entreprise détient en Chine continentale des autorisations couvrant la transmission nationale de données par ligne fixe, les services IDC, le CDN, le VPN domestique et les services ISP. Elle situe les services transfrontaliers dans le cadre des textes MIIT No.32 et No.2496 ainsi que des exigences de la convention CDTIA.

Cette présentation compte, car la connectivité transfrontalière ne se réduit pas à l’optimisation technique. Le fournisseur doit pouvoir expliquer quelle entité contracte, quelle licence couvre quelle prestation, où s’effectue la remise, qui transporte les données de part et d’autre de la frontière et quelles restrictions s’appliquent au client. Mais le dossier ne contient pas de copie de licence issue d’un régulateur, d’avis juridique indépendant ni de correspondance entre autorisation et circuit proposé.

Le routage visible d’AS63199 ne ferme donc pas le sujet réglementaire. BGP peut montrer qu’un préfixe est joignable; il ne dit pas qu’un usage, un flux de données ou une structure contractuelle respecte toutes les obligations applicables. De même, une page de conformité ne garantit pas le résultat pour chaque secteur, chaque type de donnée et chaque montage transfrontalier. L’acheteur doit demander les références documentaires, les entités juridiques concernées et l’analyse adaptée à son usage, puis la faire examiner indépendamment lorsque l’enjeu le justifie.

Le coût réel se trouve dans les limites du service

L’économie de l’offre ne peut pas être lue dans un seul tarif au mégabit. Elle dépend du nombre de ports, des boucles d’accès, des frais d’installation, des engagements de volume, des pointes facturées, des changements de route et du niveau de support. La possibilité annoncée par PIR de choisir entre facturation au débit et à l’usage, avec des pointes jusqu’à 10 Gbit/s, peut répondre à des profils très différents. Elle peut aussi déplacer le risque vers les dépassements et les périodes de pointe.

Pour une entreprise distribuée, le prix d’une route imparfaite apparaît ailleurs: temps perdu par les équipes, sessions applicatives interrompues, transferts relancés, recours à un second fournisseur, dépannage local et coordination entre plusieurs fuseaux horaires. Le sujet local-support-labour n’est donc pas périphérique. Les 26 sites déclarés dans PeeringDB ne disent pas qui intervient, dans quelle langue, sous quel délai, avec quel accès physique ou quelle autorité pour modifier une session.

Le contrat devrait distinguer au minimum le réseau supervisé par Global Cloud Co., Ltd, les segments opérés par des tiers et la frontière où change la responsabilité. Il devrait aussi préciser les métriques: disponibilité de port ou de bout en bout, perte, latence, gigue, temps d’accusé de réception et temps de rétablissement. Sans cette décomposition, un SLA agrégé peut rester vert pendant que le parcours réellement important pour le client est dégradé.

Un test d’achat centré sur six preuves

La documentation publique justifie une diligence plus précise qu’une démonstration générique de portail. Six preuves permettraient de convertir la visibilité d’AS63199 en confiance opérationnelle.

Premièrement, une carte de chemin par cas d’usage. Elle doit partir du site client, nommer la boucle locale, les points de remise, les systèmes autonomes attendus à l’aller et au retour, puis aboutir à la région cloud ou au site distant. Une route théorique mondiale ne remplace pas ce tracé.

Deuxièmement, des mesures sur les vrais créneaux. Les tests doivent couvrir les heures chargées en Chine et dans la région de destination, sur plusieurs semaines, avec perte, latence, gigue et changements de chemin. L’exemple SmokePing choisi par le fournisseur peut servir de méthode, pas de résultat transférable.

Troisièmement, la nature des interconnexions. Pour les échanges et sites pertinents, il faut confirmer le port, la capacité engagée, la redondance physique, la politique BGP et le statut actuel. Les entrées PeeringDB et les voisins RIPEstat donnent une liste de vérification; ils ne remplacent pas ces réponses.

Quatrièmement, la séparation des responsabilités. Le fournisseur doit identifier les partenaires, le centre de supervision, l’équipe d’astreinte, le point d’escalade et le pouvoir réel de chaque intervenant. Cette chaîne est particulièrement importante lorsqu’un service traverse plusieurs opérateurs ou juridictions.

Cinquièmement, le dossier réglementaire applicable. Les licences invoquées, l’entité contractante, la portée géographique et les restrictions doivent correspondre au flux prévu. Les références MIIT et CDTIA méritent un examen documentaire, pas une simple reprise de la page marketing.

Sixièmement, les conditions de reprise. Il faut tester la bascule, documenter les dépendances communes, préciser les objectifs de rétablissement et convenir de la preuve qui déclenche un crédit ou une escalade. Ni la présence à un échange ni l’annonce d’un préfixe ne fournit cette garantie.

Un réseau visible, une promesse à contractualiser

Le dossier public soutient une conclusion mesurée. Global Cloud Co., Ltd possède, à travers AS63199, une identité de routage clairement rattachée à CDS Global Cloud Co., Ltd. RIPEstat montre une visibilité étendue et un ensemble important de préfixes observés à la mi-juillet 2026. PeeringDB expose une distribution internationale de points d’échange et de sites qui cadre avec un opérateur tourné vers l’interconnexion. Les pages de l’entreprise articulent cette empreinte autour de GPN, Premium Internet Routing, Global DIA, Enhanced Internet et CloudConnect, avec la Chine comme marché et contrainte structurante.

Ce que le dossier ne montre pas est tout aussi important. Il ne révèle pas le chemin d’un client, la nature contractuelle des voisins BGP, les volumes actifs, la capacité libre, la propriété des installations, le comportement de la bascule, la portée indépendante des licences ou les limites exactes d’un engagement de service. La présence réseau est vérifiable; la qualité achetée reste à démontrer circuit par circuit.

Global Cloud Co., Ltd ne devrait donc pas être évaluée comme une marque de cloud interchangeable. Sa proposition la plus crédible se situe à l’endroit où le routage, l’interconnexion et les contraintes chinoises se rencontrent. C’est aussi là que doit porter la diligence: non sur le nombre le plus spectaculaire affiché par une page, mais sur le chemin promis, l’autorité de ceux qui l’opèrent et les preuves prévues lorsque ce chemin change.

Pour juger Global Cloud Co., Ltd, il faut suivre les routes d’AS63199