YISU CLOUD LTD vend de la capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de maintenance

Résumé

• YISU CLOUD LTD dispose de preuves d'exploitation publiques plus solides qu'une simple coquille corporative: le site de Yisu commercialise des services cloud et d'hébergement, APNIC RDAP liste les AS136970, AS138152 et AS142403 contrôlés par Yisu comme systèmes autonomes actifs à Hong Kong, et RIPEstat montre que les trois ont été annoncés le 12 juillet 2026.
• Ces preuves ne divulguent toujours pas la propriété des baies, les baux d'installations nommées, la topologie électrique, la redondance de refroidissement, la profondeur du personnel de support ou les chemins de migration client testés. Le routage public prouve un espace d'adressage joignable; il ne prouve pas la capacité de calcul utile qui peut survivre à une maintenance ou à une panne.
• Le risque client le plus important est une compression de la capacité hébergée: une panne de baie, de fournisseur amont, de stock matériel, de support, de facturation, de migration ou de contrat fournisseur qui laisse un petit client avec un service IP visible mais un levier limité sur la couche physique sous-jacente.

La vitrine est plus large que la preuve de l'infrastructure

La façade publique de YISU CLOUD LTD est une vitrine cloud, pas une simple étiquette de route. La page d'accueil internationale suryisu.com/intlfait la promotion de l'informatique cloud élastique, des serveurs bare metal, du MySQL géré, des IP anti-DDoS, des serveurs légers, de l'équilibrage de charge et des certificats SSL. La même page indique que l'entreprise offre un accès instantané aux services cloud dans des endroits tels que Tokyo, Francfort, Washington et Los Angeles, tandis que sa carte de localisation nomme également Hong Kong, Singapour, le Japon, la Corée du Sud, l'Allemagne, Bangkok, l'Inde, l'Indonésie, l'Australie et les États-Unis. Il s'agit d'une revendication commerciale large: Yisu vend aux clients l'idée que la capacité peut être commandée via un panneau et utilisée comme une surface d'hébergement mondiale.

La propre pageÀ propos de Yisu Cloudde l'entreprise rend cette revendication plus explicite. Elle indique que Yisu a été fondée en 2017, la qualifie de fournisseur mondial de services cloud, et affirme avoir construit des services de cloud computing pour les entreprises, les développeurs et les organisations gouvernementales. Elle indique également que Yisu a établi des centres de données écologiques économes en énergie et des bureaux d'exploitation à Pékin, Shanghai, Guangzhou, Hangzhou, Hong Kong et d'autres régions de Chine, ainsi qu'en Europe, en Corée du Sud, au Japon, à Singapour et aux États-Unis. La même page revendique plus de 50 000 serveurs cloud, plus de 30 000 utilisateurs cumulés, plus de 2 800 nœuds CDN, 130 To/s de bande passante CDN et une capacité de défense DDoS supérieure à 5 000 Gbps. Ce sont des chiffres importants pour un fournisseur avec une divulgation limitée d'installations indépendantes.

Cet écart est le point de départ de l'article. Les preuves publiques soutiennent que Yisu est un véritable opérateur de services hébergés avec une infrastructure réseau active. Elles ne soutiennent pas le traitement de chaque revendication de localisation ou d'échelle comme une mesure de capacité auditée.

Une page produit peut dire « serveur cloud »; une commande client peut produire une machine virtuelle; une table BGP peut montrer des routes originaires de Yisu; pourtant aucun de ces faits n'identifie la salle de données, le nombre de baies, la conception de l'alimentation électrique, le stock de pièces de rechange, la file d'attente de réparation ou le plan de sortie client. La capacité hébergée semble toujours abstraite au moment de l'achat. En cas de panne, elle devient physique.

Les pages produits de Yisu rendent cette dépendance physique inhabituellement claire. La pageCloud Computing Élastiqueindique que les clients peuvent choisir le CPU, la mémoire, la bande passante et l'IP dédiée, et elle fait la promotion de la protection des données RAID, des instantanés, des réseaux internes personnalisés, des groupes de sécurité et de la défense contre les attaques DDoS. La pageServeur Bare Metalva une couche plus bas: elle vend des serveurs physiques dédiés dans des environnements mono-locataires, avec installation automatique du système d'exploitation, configuration réseau, attachement de disque et contrôles du cycle de vie. La pageServeur Légerest plus simple mais dépend toujours du calcul, du réseau et du stockage groupés de manière fiable. Ce ne sont pas seulement des promesses logicielles. Ils nécessitent des serveurs, des disques, des ports de commutateur, de l'électricité, du refroidissement, un stock IP, du transit et du personnel capable de reconstruire ou de déplacer les clients quand quelque chose se casse.

La lecture équitable n'est ni le rejet ni la crédulité. Le dossier réseau public de Yisu est suffisamment substantiel pour être étudié. Son site Web est suffisamment spécifique pour montrer un catalogue de services. Mais la couche des installations reste suffisamment opaque pour que les clients doivent se demander comment la capacité commercialisée correspond aux baies, aux baux et aux fenêtres de maintenance. Les propres preuves de l'entreprise donnent une forme aux services; les preuves de routage donnent un squelette au réseau; l'absence de preuves sur les installations définit le risque.

Trois ASN Yisu sont visibles, mais ils remplissent des rôles différents

Les ancres dures les plus solides sont les enregistrements APNIC et RIPEstat pour trois ASN contrôlés par Yisu.APNIC RDAP pour AS136970liste « YISUCLOUDLTD-AS-AP - YISU CLOUD LTD » comme un système autonome actif à Hong Kong, enregistré en septembre 2017 et dernière modification en janvier 2021.APNIC RDAP pour AS138152liste « YISUCLOUDLTD-HK - YISU CLOUD LTD » comme actif, enregistré en août 2018 et dernière modification en janvier 2021.APNIC RDAP pour AS142403liste le même nom YISUCLOUDLTD-HK comme actif, enregistré en juin 2021. Les trois enregistrements pointent vers la même famille de déclarants Yisu à Hong Kong.

RIPEstat confirme qu'il ne s'agit pas d'étiquettes dormantes. Ses pages de vue d'ensemble AS montrentAS136970,AS138152etAS142403comme annoncés le 12 juillet 2026. Les appels de statut de routage sont plus utiles car ils donnent une échelle:AS136970avait 17 préfixes IPv4 visibles,AS138152avait 44 préfixes IPv4 visibles, etAS142403avait 70 préfixes IPv4 visibles au moment de la requête RIPEstat. Chacun affichait zéro /48 IPv6 visible dans cette vue. Au total, cela représente 131 équivalents /24 routés, soit 33 536 adresses IPv4 avant toute prise en compte des adresses réservées, filtrées, louées, suspendues ou utilisées en interne.

BGP.tools offre une vue externe complémentaire. Sapage AS136970décrit Yisu comme un réseau de contenu avec 17 préfixes IPv4, des fournisseurs amont via ASLINE et AS142403, et une liste descendante pour AS142403. Sapage AS138152montre 44 préfixes IPv4 et des fournisseurs amont via Zenlayer, Cogent et China Telecom Next Generation Carrier Network. Sapage AS142403montre 70 préfixes IPv4, des fournisseurs amont via NTT America, AS136970 et HK Kwaifong Group Limited, et une liste descendante pour AS136970. Ces pages ne sont pas des certificats d'installation, mais elles montrent que la présence Internet publique de Yisu ne se limite pas à une seule route ou un seul opérateur.

Les trois ASN suggèrent également différents rôles opérationnels. AS136970 ressemble à un réseau Yisu plus ancien avec un plus petit ensemble de préfixes et un lien interne avec AS142403. AS138152 ressemble à un réseau de services diversifié en transit avec Zenlayer, Cogent et China Telecom Backbone et China Telecom Next Generation Carrier Network visibles dans les données BGP.tools ou RIPEstat. AS142403 ressemble au plus grand bord public, transportant de nombreux /24 décrits par Yisu comme Hong Kong et par AFRINIC et connecté à NTT, HK Kwaifong Group et AS136970. Un client n'a pas besoin de mémoriser la carte AS.

Cela importe car les pannes, le filtrage et les délais de réparation peuvent être différents selon l'AS et le chemin amont qui hébergent le service du client.

PeeringDB ajoute une absence notable. Les requêtes pourAS136970,AS138152etAS142403ne renvoient aucune entrée réseau. Cela ne prouve pas que Yisu manque de peering, d'installations ou d'interconnexion privée. De nombreux petits réseaux d'hébergement ne maintiennent pas une page PeeringDB, et certains achètent du transit plutôt que de faire de la publicité pour une présence sur un exchange. Mais l'absence laisse les clients sans liste publique d'installations, de listes d'echange, de politique de trafic ou de notes NOC provenant de PeeringDB. Pour un acheteur de capacité hébergée, cela signifie que l'Internet public peut voir les routes, tandis que l'empreinte physique et d'interconnexion reste principalement derrière la vitrine.

Le mélange d'espace d'adressage pointe vers la location et l'agrégation, pas un simple pool unique

L'espace d'adressage routé de Yisu n'est pas une seule allocation corporative soignée. APNIC montre certaines plages directement sous Yisu. Par exemple,39.109.104.0/24se trouve dans un inetnum APNIC pour YISU CLOUD LTD à Hong Kong, avec des informations de routage APNIC qui montrent également une origine via AS133115.103.100.208.0/24se trouve dans un bloc portable assigné 103.100.208.0/22 pour YISU CLOUD LTD, encore avec une entrée de route APNIC via AS133115. Ces enregistrements sont utiles car ils lient au moins une partie de la surface de service visible à la numérotation APNIC propre de Yisu.

D'autres routes originaires de Yisu ont une histoire plus complexe.43.225.157.0est dans une allocation APNIC décrite comme Better Cloud Limited à Kwai Chung, pas une allocation directe de Yisu.103.142.86.0est décrit comme SHENGYD(HK)LIMITED, avec une entrée de route originaire de AS138152.103.144.244.0est décrit comme PROSPUR INT'L CO., LIMITED, également avec une entrée de route AS138152. Les exemples servis par AFRINIC ajoutent une autre couche:154.92.14.0/24est décrit comme Yisu Cloud Ltd à Hong Kong et originaire de AS142403, tandis que156.227.232.0/24est décrit comme Cloud Innovation Ltd avec le pays RU et une description de route pour Yisu Cloud Ltd via AS138152.

Ce mélange est courant dans le marché de l'hébergement low-cost et anti-DDoS. Les fournisseurs combinent souvent leur propre espace d'adressage portable avec de l'espace loué, délégué ou routé client et partenaire. L'implication opérationnelle est simple: le stock IP annoncé n'est pas la même chose qu'une capacité de calcul contrôlée en permanence.

Si un client reçoit une adresse d'un bloc détenu par un autre LIR, le service peut toujours fonctionner parfaitement, mais les conditions contractuelles, le traitement des abus, la géolocalisation, l'autorisation de route, la réputation et les options de transfert peuvent dépendre de parties autres que Yisu. Cela importe quand un client doit déplacer une instance, réclamer une adresse, empêcher le trafic de recherche de changer de région, ou répondre à un examen bancaire ou de conformité.

Les enregistrements RDAP incluent également un autre petit mais important avertissement. L'enregistrement de contact pour les abus de Yisu est marqué avec des remarques indiquant que[email protected]est invalide dans les enregistrements RDAP APNIC pourAS138152etAS142403, avec une date de dernière modification en mars 2026 pour l'enregistrement d'abus. Cela ne signifie pas que Yisu est injoignable via tous les canaux de support; son site liste[email protected] sur la page de contact, et les clients achetant un service utiliseraient le portail client. Cela signifie que l'hygiène du registre public pour le traitement des abus n'est pas aussi solide qu'elle devrait l'être pour un fournisseur d'hébergement dont le service inclut la mitigation DDoS et des ressources IP tournées vers le client.

L'hygiène de l'espace d'adressage n'est pas simplement bureaucratique. Dans un service cloud, la réputation IP peut décider si le courrier du client est livré, si une passerelle de paiement accepte le trafic, si un CDN permet l'accès à l'origine, si un moteur de recherche déplace le site, ou si un rapport d'abus atteint quelqu'un avant qu'une route ne soit filtrée. L'échelle de route visible de Yisu est significative. Le mélange de descriptions directes, de partenaires et servies par AFRINIC signifie que les clients devraient demander ce qu'ils peuvent conserver, déplacer ou remplacer si un contrat fournisseur ou une délégation IP change.

Les promesses produit se transforment rapidement en dépendances physiques

La pageCloud Computing Élastiquede Yisu vend des choix flexibles de CPU, mémoire, bande passante et stockage, et dit que les ressources cloud peuvent être mises à l'échelle horizontalement et verticalement. C'est la commodité commerciale de l'hébergement cloud. La question physique est ce qui se passe quand de nombreux clients veulent la même ressource au même endroit en même temps. La mise à l'échelle horizontale nécessite de la capacité hôte de rechange, des ports de commutateur de rechange, suffisamment de stock IP public ou privé, et des backends de stockage capables d'absorber de nouvelles E/S. La mise à l'échelle verticale nécessite de la capacité hyperviseur ou une migration vers un hôte plus grand. Aucun des deux n'est garanti par un simple sélecteur de produit.

La même page fait des affirmations de fiabilité: jusqu'à 99,95 % de disponibilité de service et pas moins de 99,9999 % de fiabilité des données, protection des données RAID, instantanés, réseaux personnalisés et fonctions de sécurité. Un client devrait lire ces affirmations comme des affirmations de conception de service, pas comme une preuve de région auditée.

RAID peut protéger contre certaines défaillances de disque, mais il ne protège pas contre une baie entière perdant de l'alimentation, une panne du plan de contrôle, une défaillance du contrôleur de stockage, une erreur d'opérateur, un échec de restauration d'instantané, ou un drain réseau qui laisse le client coupé de ses données. Les instantanés ne sont précieux que s'ils sont stockés suffisamment séparément du système défaillant et peuvent être restaurés dans la tolérance du client.

La pageServeur Bare Metalest encore plus exposée aux contraintes physiques. Elle fait la publicité de serveurs dédiés dans des environnements mono-locataires, déploiement rapide, fonctionnement et maintenance 24/7, isolation physique, redondance des données RAID10, technologie réseau multi-liens et isolation réseau. Le bare metal est attrayant car le client évite la surcharge de virtualisation et le risque de voisin bruyant. Il est aussi moins élastique qu'un serveur virtuel quand le stock matériel est serré. Une panne de bare metal peut nécessiter un châssis de rechange, des disques compatibles, des diagnostics manuels, un accès à distance, ou une réinstallation du système d'exploitation. Si Yisu a du matériel de rechange dans la même installation, la récupération peut être rapide. Si elle doit attendre une visite sur site ou une pièce de rechange, la fenêtre de réparation devient le produit.

La pageRDS pour MySQLde Yisu dit que son service de base de données utilise un stockage SSD de niveau entreprise, une haute disponibilité, une séparation lecture/écriture, des sauvegardes flexibles et un déploiement primaire-secondaire sur différents serveurs. Cette architecture peut réduire le risque de serveur unique, mais elle soulève de nouvelles questions de dépendance. Les primaire et secondaire sont-ils dans des baies différentes, des domaines électriques différents ou seulement des hôtes différents? Les sauvegardes sont-elles conservées dans un cluster de stockage différent? Un client peut-il exporter un dump utilisable pendant un incident, ou seulement via un panneau de contrôle fonctionnel? Un basculement préserve-t-il les identifiants d'application et les points de terminaison de connexion? Un service de base de données géré est pratique précisément parce qu'il cache ces mécanismes. L'acheteur a toujours besoin d'un plan de portabilité.

La pageÉquilibreur de Charge Élastiquevend le forwarding de couche 4 et 7, les vérifications de santé, la persistance de session et la conception redondante. L'utilisation la plus forte d'un équilibreur de charge est d'absorber la défaillance individuelle d'un serveur. L'utilisation la plus faible est de placer toutes les instances client derrière un équilibreur de charge qui dépend lui-même d'un site, d'un chemin amont, d'un compte ou d'un plan de contrôle. La page de Yisu indique que l'activation et la désactivation des nœuds de service n'affectent pas le service en cours. C'est plausible pour un cluster bien conçu, mais la page publique n'identifie pas la répartition des installations du cluster ni si les charges de travail des clients peuvent être équilibrées entre les régions.

La pageIP Anti-DDoSest le produit le plus dépendant du réseau de tous. Elle fait la publicité d'une grande capacité de nettoyage DDoS, du masquage de l'IP réelle, du support TCP/UDP/HTTP/HTTPS, de la protection contre les inondations DNS et du support 24/7. La page contient également des mentions de capacité en style « plus de 5000 GB » et « 1000 G+ », qui doivent être lues attentivement car les pages marketing mélangent souvent la capacité totale de la plateforme, les niveaux par produit et les pics de nettoyage dans le meilleur des cas. La défense DDoS n'est pas seulement un nombre de bande passante. Elle dépend de la capacité amont propre, des emplacements de nettoyage, du contrôle des faux positifs, de la vitesse de routage, de la couverture des types d'attaque, et de la possibilité pour le client de se déplacer si l'IP protégée devient bloquée ou saturée.

Hong Kong est l'ancre publique, tandis que la capacité mondiale reste plus difficile à vérifier

Les enregistrements légaux et réseau de Yisu sont fortement ancrés à Hong Kong. APNIC RDAP liste YISU CLOUD LIMITED comme une organisation HK avec une adresse au World Peace Centre, Wo Tong Tsui Street, Kwai Chung, et les enregistrements whois APNIC pour les blocs IP détenus par Yisu répètent la même famille de contacts à Hong Kong. Le site public de Yisu indique également que sa stratégie mondiale inclut Hong Kong, et sa carte de localisation distingue Hong Kong des autres régions listées. L'ancre Hong Kong est crédible.

Ce qui reste moins clair est la part du catalogue de services qui est exploitée par des baies appartenant à Yisu, des cages louées, des serveurs loués, des contrats de revente ou des capacités partenaires dans chaque emplacement annoncé.

Hong Kong est un endroit plausible pour construire ce genre de service. Le portail gouvernemental des centres de données qualifie Hong Kong d'emplacement de centre de données de premier plan en raison de télécommunications robustes, de systèmes de câbles sous-marins externes, d'un marché des télécommunications libéralisé, d'environ 300 fournisseurs de bande passante agréés, d'une grande fiabilité électrique, de la libre circulation de l'information et de la loi sur la confidentialité des données. La pageFacilitation des Centres de Donnéesdu Bureau de la Politique Numérique indique que le gouvernement soutient les centres de données en tant qu'infrastructure de base pour la finance, le commerce, la logistique et le cloud computing, et note qu'un site du cluster d'installations de données de Sandy Ridge a été attribué en mars 2026. La même page indique que Hong Kong bénéficie d'une alimentation électrique fiable, d'infrastructures de télécommunications solides et d'un faible risque de catastrophe naturelle.

L'offre n'est pas sans friction. Une réponse du Conseil législatif de juin 2024 sur lespropriétés disponibles pour une utilisation en centre de donnéesa indiqué que Hong Kong avait environ 970 000 mètres carrés de surface de centre de données à ce moment-là, estimait une demande d'opérateurs à court et moyen terme d'environ 300 000 mètres carrés, et prévoyait que la surface totale atteigne 1,5 million de mètres carrés d'ici 2026. La même réponse discutait de la conversion de bâtiments industriels, de la réhabilitation, de la hauteur sous plafond, de la capacité de charge, de la sécurité incendie, de la sûreté, des eaux usées, du stationnement, des ascenseurs, des toilettes, de l'alimentation électrique et de la génération de secours comme des problèmes pratiques. C'est exactement le monde physique derrière la grille de produits d'un fournisseur cloud.

Pour Yisu, les preuves publiques ne lient pas chaque région annoncée à des installations nommées. Les offres d'achat rapide de la page d'accueil mentionnent Tokyo, Francfort, Washington et Los Angeles, tandis que la page À propos nomme les États-Unis, l'Allemagne, Bangkok, l'Inde, la Corée du Sud, le Japon, Hong Kong, Singapour, l'Indonésie et l'Australie avec des étiquettes activé, en construction et planification. Ce sont des signaux commerciaux utiles, mais ils ne doivent pas être convertis en zones de disponibilité indépendantes sans preuve supplémentaire.

Une étiquette de région peut signifier des baies appartenant à Yisu, des serveurs dédiés loués, de la capacité virtuelle d'un tiers, un point de nettoyage DDoS, ou un emplacement de commande dans l'interface utilisateur.

La frontière opérationnelle est donc le vrai problème. Si Yisu contrôle directement une baie, elle peut diviser les alimentations électriques, remplacer un disque, coordonner la réparation des interconnexions et appliquer les procédures d'accès. Si Yisu revend le serveur d'un fournisseur dans un autre pays, elle dépend de la file d'attente d'accès à distance de ce fournisseur, des pièces de rechange, du statut de facturation, des fenêtres de maintenance et de la politique de routage. Si Yisu fournit un front-end anti-DDoS à un endroit et un hébergement d'origine à un autre, le client dépend des deux.

L'hébergement mondial est précieux précisément parce qu'il offre un choix. Il est risqué quand l'acheteur ne peut pas dire quelle partie contrôle le domaine de la panne.

La diversité de transit existe, mais ce n'est pas la même chose que la diversité de site

Le routage de Yisu n'est pas mono-hébergé dans le sens le plus simple. Lavue des voisins d'AS138152de RIPEstat montre quatre voisins observés le 12 juillet 2026: AS174, AS21859, AS4134 et AS4809. BGP.tools les identifie comme Cogent, Zenlayer, China Telecom Backbone et China Telecom Next Generation Carrier Network dans sa page publique pour AS138152. C'est un mélange significatif pour un fournisseur d'hébergement face à la Chine et à Hong Kong. Cela suggère que Yisu peut atteindre les clients via du transit mondial, du transit orienté hébergement et des chemins liés à China Telecom.

AS142403 a une forme différente. Lavue des voisins d'AS142403de RIPEstat montre AS133115, AS136970 et AS2914 sur le côté gauche, avec AS136970 apparaissant également sur le côté droit. BGP.tools identifie ces fournisseurs amont visibles comme HK Kwaifong Group Limited, le propre AS136970 de Yisu et NTT America. AS136970, à son tour, apparaît dans lavue des voisinsde RIPEstat avec AS142403 et AS18013, que BGP.tools identifie comme Yisu et ASLINE. Le résultat est un réseau où les ASN Yisu sont interdépendants et où le transit extérieur diffère selon l'ASN.

C'est mieux qu'un seul fournisseur amont visible, mais cela ne règle pas la question de la résilience physique. Les voisins BGP peuvent exister dans le même bâtiment, sur le même chemin de salle de rencontre, via le même fournisseur d'interconnexion, ou via des circuits qui partagent un conduit à l'extérieur de l'installation. Ils peuvent aussi être géographiquement diversifiés. Les données BGP publiques distinguent rarement ces cas.

Un client qui voit AS138152 connecté à Zenlayer, Cogent et China Telecom a toujours besoin de savoir si son serveur est attaché à des commutateurs top-of-rack redondants, si ces commutateurs sortent via des routeurs séparés, et si une fenêtre de maintenance sur une installation peut supprimer toute joignabilité pratique.

Le marketing orienté Chine de Yisu rend cela particulièrement important. Les pages d'accueil et À propos mentionnent à plusieurs reprises la bande passante de style CN2 et les chemins de retour rapides vers les utilisateurs domestiques. La visibilité de China Telecom Next Generation Carrier Network sur AS138152 soutient l'idée que le transit orienté Chine est important pour le service. Cela ne prouve pas la performance de bout en bout depuis chaque ville annoncée ou depuis chaque réseau d'accès continental.

Les routes orientées Chine peuvent être précieuses, congestionnées, filtrées, coûteuses ou limitées par contrat selon le circuit et le fournisseur. Un service qui fonctionne bien pour un client à Hong Kong peut se comporter différemment pour une entreprise continentale, un utilisateur d'Asie du Sud-Est ou une origine nord-américaine.

L'absence publique de PeeringDB importe aussi ici. Une page PeeringDB pourrait lister les exchanges, les installations, la politique de trafic et les contacts NOC. Le résultat sans entrée pour les trois ASN de Yisu laisse les preuves de transit public dispersées sur les outils BGP et les enregistrements de registre. Cela ne rend pas le réseau faible en soi. Cela rend la diligence raisonnable du client plus manuelle.

L'acheteur devrait demander quel AS va originer son IP de service, quels fournisseurs amont vont la transporter, si le basculement a été testé, si la protection DDoS change le chemin, et si Yisu peut déplacer la route ou le service vers une région différente sans forcer une reconstruction.

Le support et la facturation font partie de l'infrastructure

Le site Web de Yisu vend du contrôle technique, mais le service dépend aussi des systèmes administratifs. La page d'accueil fait la promotion d'une console, d'un déploiement en un clic, de graphiques de surveillance, de gestion de configuration et d'un support technique 24/7/365. Lapage de contactdonne un email de support et un formulaire Web. Les pages produits orientent les clients vers les liens d'inscription, de connexion, de facturation, d'ajout de fonds et de console. Dans un modèle d'hébergement low-cost, ces systèmes ne sont pas secondaires. Si la facturation, la vérification du compte ou le panneau de contrôle tombe en panne, un client peut ne pas être en mesure de renouveler un serveur, de remplacer une IP, d'ouvrir un ticket, de redimensionner le stockage ou de se rétablir après une suspension.

La profondeur du support est particulièrement importante car Yisu vend à la fois des produits virtuels et physiques. Les serveurs virtuels peuvent souvent être redémarrés, réinstallés ou redimensionnés via l'automatisation. Le bare metal peut nécessiter un travail manuel. La protection DDoS peut nécessiter une analyse du trafic en direct et un réglage de route. Le MySQL géré peut nécessiter une restauration de sauvegarde, des décisions de basculement et un triage des performances. L'équilibrage de charge peut nécessiter la correction des vérifications de santé ou le remplacement de certificats.

Un fournisseur peut annoncer un support 24/7, mais la vraie métrique est de savoir si le support peut changer quelque chose au niveau de la baie, du routeur ou du compte client pendant un incident en direct.

La note de santé de contact APNIC ne doit pas être surinterprétée, mais elle ne doit pas être ignorée. La remarque de RDAP selon laquelle le contact[email protected]est invalide ne décrit pas nécessairement le support client. Elle montre cependant que le contact public pour les abus attaché aux ressources APNIC de Yisu a un problème de validation. Les fournisseurs d'hébergement vivent avec des rapports d'abus tous les jours: serveurs compromis, pages de phishing, scanners, nœuds de commande DDoS, spam, credential stuffing, proxys ouverts et trafic de bots. Si le courrier d'abus rebondit ou est mal surveillé, les fournisseurs amont et les fournisseurs de réputation peuvent escalader en filtrant ou en null-routant l'espace d'adressage. Cela peut affecter des clients innocents qui partagent un préfixe ou un segment amont.

Le risque de facturation est similaire. Les utilisateurs du cloud pensent souvent que le cloud est élastique, mais de nombreux fournisseurs low-cost fonctionnent sur des soldes prépayés. Si la carte d'un client échoue, un solde s'épuise, un contrôle anti-fraude bloque, ou un compte revendeur est suspendu, le calcul peut disparaître plus vite que dans un contrat d'entreprise. Les liens de connexion et de facturation de Yisu montrent un service conventionnel piloté par panneau. Le site public n'explique pas les périodes de grâce, les fenêtres de conservation des données, les procédures de verrouillage de compte ou les droits d'exportation.

Ces termes décident si un client peut survivre à un problème administratif.

Les fenêtres de support façonnent aussi la migration. Un client peut déplacer un site Web statique rapidement s'il conserve les sauvegardes et le contrôle DNS. Un client utilisant une base de données avec état, un serveur de jeu, une API payante, un endpoint ad-tech ou un site orienté Chine peut avoir besoin de continuité IP, d'instantanés de données, de règles de pare-feu, de certificats et de réputation de route. Les pages de Yisu parlent d'instantanés, de sauvegardes et de migration fluide dans un langage spécifique au produit, mais les pages publiques ne définissent pas de garanties d'exportation entre fournisseurs.

En cas de défaillance contractuelle du fournisseur, la question de support la plus importante n'est pas de savoir si un ticket reçoit une réponse polie. C'est de savoir si le client peut obtenir les données, les adresses et la configuration du service avant que le temps ne s'écoule.

La localité et la souveraineté des données nécessitent un plan côté acheteur

La question de la localité de l'affectation est centrale pour Yisu car son marketing couvre Hong Kong, la Chine continentale, l'Asie-Pacifique, l'Europe et les États-Unis, tandis que ses enregistrements légaux et réseau sont fortement basés à Hong Kong. La localité des données ne concerne pas seulement l'endroit où une entreprise est enregistrée. Elle concerne l'endroit où la charge de travail s'exécute, où les sauvegardes résident, où le personnel de support peut accéder aux données, où le trafic DDoS est nettoyé, quelles lois régissent le transfert, et ce qui se passe quand le client a besoin d'une preuve.

Le portail public des centres de données de Hong Kong met l'accent sur la libre circulation de l'information et l'ordonnance sur la confidentialité des données (personnelles) comme avantages pour les opérateurs de centres de données. Le Commissaire à la vie privée a également publié desorientations sur le cloud computing, avertissant les utilisateurs de données de faire preuve de diligence raisonnable à l'égard des fournisseurs de cloud, de la protection contractuelle, de la sous-traitance, de la sécurité, de l'accès aux données, de la conservation et du transfert transfrontalier. Ces orientations sont écrites pour les clients, pas seulement pour les fournisseurs. Le point clé pour les acheteurs de Yisu est qu'une revendication de service hébergé ne répond pas aux questions de localité par elle-même.

Les pages produits de Yisu ne divulguent pas publiquement un calendrier de traitement des données région par région. Elles ne disent pas si les sauvegardes du MySQL géré restent au même endroit, si les instantanés sont répliqués hors région, si le nettoyage anti-DDoS change le chemin juridictionnel du trafic, si le support peut accéder aux disques des clients depuis l'extérieur de Hong Kong, ou si un client peut contractuellement épingler les données à une région choisie. Certains petits clients peuvent ne pas s'en soucier.

Pour les clients dans la finance, la santé, les services publics, le commerce électronique réglementé, les jeux, l'ad-tech ou les opérations liées à la Chine, ces détails comptent.

Le mélange d'espace d'adressage complique la géolocalisation. Certains blocs originaires de Yisu sont de l'espace APNIC décrit comme Hong Kong. Certains sont des plages servies par AFRINIC avec des descriptions Hong Kong, russes ou autres dans les données whois. Certains sont décrits sous d'autres sociétés hongkongaises mais originés par Yisu. Les fournisseurs de géolocalisation IP peuvent mapper ces adresses différemment.

Un client peut acheter un service « Hong Kong » et constater que les outils anti-fraude, les plateformes publicitaires ou les processeurs de paiement lisent l'IP comme une autre juridiction jusqu'à ce que les bases de données soient mises à jour. Ce n'est pas nécessairement la faute de Yisu, mais c'est un problème opérationnel prévisible quand les fournisseurs d'hébergement utilisent des pools IP mixtes.

La souveraineté des données recoupe également la sortie du client. Un client qui a besoin de prouver la localité ne devrait pas se fier à un menu déroulant de localisation de produit. Il devrait conserver des sauvegardes indépendantes, documenter où son service est commandé, enregistrer les plages IP et ASN assignés, demander des déclarations écrites sur l'emplacement des sauvegardes et l'accès au support, et tester la restauration chez un autre fournisseur. Les preuves réseau et produit de Yisu en font un candidat crédible pour certains cas d'usage hébergés.

Elles ne suppriment pas le devoir du client de vérifier où se trouvent réellement les données, les journaux et les copies de sauvegarde.

Les chemins de défaillance qui exposeraient la couche physique cachée

Le premier chemin de défaillance est la panne de baie ou d'hôte. Pour un serveur cloud Yisu, le client peut voir un redémarrage, des performances réduites, des erreurs d'E/S disque ou une instance qui ne démarre pas. Pour le bare metal, la même panne peut être plus lente car un serveur physique peut nécessiter le remplacement de composants ou une migration complète. Si Yisu dispose de capacité hôte de rechange et d'automatisation fiable, le client peut être déplacé. Si l'emplacement affecté est limité en approvisionnement, le client attend la réparation ou accepte une région différente.

Les pages produits publiques ne révèlent pas la politique de capacité de rechange.

Le deuxième chemin de défaillance est la panne de fournisseur amont ou de route. AS138152 a plusieurs voisins visibles, mais tous les préfixes clients ne bénéficient pas nécessairement également. La combinaison de chemins d'AS142403 est différente, et AS136970 dépend en partie d'AS142403. Une fuite de route, une action de filtrage, une panne d'interconnexion, un différend contractuel ou un changement de mitigation DDoS pourrait affecter un ASN ou un groupe de préfixes tout en laissant un autre sain. Les clients devraient donc surveiller leur préfixe et AS réellement assigné, pas seulement le domaine principal du fournisseur.

Un serveur peut fonctionner tandis que la route vers lui est malade.

Le troisième chemin de défaillance est l'épuisement du stock matériel. Yisu vend de l'élasticité low-cost et du bare metal. Si un emplacement est en rupture de stock, les clients peuvent encore voir une page d'achat, mais le provisionnement peut ralentir, le matériel de substitution peut différer, ou la réparation peut dépendre de la livraison de pièces. La pageBMSfait la publicité d'un provisionnement automatique, d'une installation du système d'exploitation et d'un attachement de disque après l'achat. C'est utile quand le stock existe. C'est fragile quand le stock est épuisé ou quand un niveau spécifique de CPU, mémoire, SSD ou bande passante n'est plus disponible dans l'installation demandée.

Le quatrième chemin de défaillance est la surcharge du support. Le trafic anti-DDoS, les plaintes pour abus, le filtrage amont et les problèmes de panneau de contrôle peuvent produire de nombreux tickets à la fois. La pageIP Anti-DDoSde Yisu indique que le service peut masquer l'IP d'origine, supporter plusieurs protocoles et fournir des stratégies personnalisées. Pendant une vraie attaque, le client a besoin d'un réglage rapide: contrôle des faux positifs, changements de domaine protégé, verrouillage de l'origine, modifications de route et nettoyage post-attaque. Si le support est mince, la capacité de nettoyage promise peut ne pas se traduire par une récupération utilisable pour chaque client.

Le cinquième chemin de défaillance est la facturation ou le verrouillage du compte. Un client d'hébergement prépayé peut perdre l'accès en raison du solde, d'un examen des risques, du traitement des abus, d'une défaillance du canal de paiement ou du statut de revendeur. Ce type de panne n'est pas visible dans BGP. Il peut néanmoins être fatal si le client ne peut pas renouveler, exporter, prendre des instantanés ou ouvrir des tickets. Les pages publiques de Yisu ne décrivent pas les périodes de grâce de résiliation ou les conditions de conservation des données.

Les clients devraient supposer qu'ils ont besoin de sauvegardes hors plateforme et du contrôle DNS.

Le sixième chemin de défaillance est l'échec de migration. Les pages de Yisu mentionnent les instantanés, les sauvegardes, la migration fluide et la configuration flexible. Ceux-ci ne sont précieux que si un client les a testés. Un service hébergé qui fonctionne depuis des années peut accumuler des dépendances locales: règles de pare-feu, réseaux privés, IPs sur liste blanche, endpoints de base de données, certificats SSL, portes d'entrée anti-DDoS et surveillance liée à des contrôles spécifiques à Yisu. Une panne de fournisseur devient bien pire quand le client découvre que sa propre architecture ne peut pas bouger.

Ce qui renforcerait la revendication opérationnelle de Yisu

Le moyen le plus rapide d'améliorer le niveau de confiance public serait une divulgation des installations à un niveau non sensible. Yisu n'a pas besoin de publier les numéros de cage. Elle pourrait identifier quelles régions sont exploitées par Yisu, lesquelles sont exploitées par des partenaires, et lesquelles sont de la capacité de revente ou virtuelle.

Elle pourrait divulguer si les services à Hong Kong se trouvent dans une ou plusieurs installations, si ces installations ont des domaines électriques séparés, si le transit orienté Chine est physiquement diversifié, et si les réplicas et sauvegardes du MySQL géré peuvent traverser les installations. Cela transformerait une carte marketing en une carte opérationnelle.

La divulgation du transit aiderait aussi. Les preuves BGP de Yisu montrent déjà plusieurs chemins amont, mais les clients ont besoin de savoir comment ces chemins correspondent aux produits. Un serveur cloud sur AS142403 peut avoir une combinaison de fournisseurs amont différente de celle d'un serveur sur AS138152. Une IP protégée DDoS peut router via un réseau de nettoyage avant d'atteindre l'origine. Un produit bare metal peut être lié à une installation différente d'un serveur léger.

Une page orientée client qui indique quel AS et quel combinaison de transit s'appliquent par emplacement réduirait l'incertitude sans exposer de détails opérationnels sensibles.

La divulgation de la gouvernance IP serait précieuse car l'ensemble de routes visible de Yisu inclut des blocs Yisu directs, des blocs APNIC décrits comme partenaires et des plages décrites par AFRINIC. Les clients devraient savoir si les IP assignées sont portables au sein de Yisu, si des IP de remplacement peuvent être émises rapidement, si la correction de géolocalisation est prise en charge, si les notifications d'abus sont traitées via une boîte aux lettres validée, et si les problèmes de réputation IP déclenchent une suspension ou une remédiation.

Pour de nombreux petits clients d'hébergement, la continuité IP est aussi importante que la continuité CPU.

Les preuves de récupération importeraient le plus. Les résumés d'incidents publics, les historiques de maintenance, les objectifs de restauration, les conditions de conservation des sauvegardes, les fenêtres de remplacement du bare metal et les procédures d'exportation sont plus utiles qu'un pourcentage de fiabilité générique. Un fournisseur peut offrir honnêtement 99,95 % de disponibilité de service et laisser quand même un client incapable de récupérer une base de données assez rapidement.

Ce dont les clients ont besoin n'est pas seulement un calcul de disponibilité; ils ont besoin de la preuve que le basculement et la restauration ont été répétés.

Enfin, Yisu pourrait rendre la localité plus facile à vérifier. Une déclaration région par région pour le calcul, le stockage, les instantanés, l'accès au support et le trafic anti-DDoS aiderait les clients réglementés à décider si Yisu correspond à leur modèle de risque. Hong Kong est une base crédible et attrayante pour l'hébergement. La capacité mondiale est utile. Mais les clients qui se soucient de la souveraineté des données ont besoin d'un langage contractuel et de contrôles techniques, pas seulement d'une étiquette de région dans un flux d'achat.

En résumé

YISU CLOUD LTD est un véritable sujet d'infrastructure publique. Son site Web vend un large catalogue de cloud et d'hébergement, les enregistrements APNIC lient plusieurs ASN actifs à l'entreprise, RIPEstat voit 131 /24 IPv4 visibles sur trois ASN Yisu le 12 juillet 2026, et BGP.tools montre une diversité amont non triviale. Ce n'est pas un fournisseur fantôme.

Les preuves d'exploitation sont encore incomplètes. Les sources publiques ne prouvent pas le nombre d'installations, la propriété des baies, la conception électrique, la redondance de refroidissement, la profondeur du stock matériel, le personnel de support, la distribution de la capacité de nettoyage DDoS, le comportement de restauration de la base de données gérée, ou les limites de migration interrégionales derrière le catalogue de services de Yisu.

La conclusion la plus solide est donc mesurée: Yisu dispose d'une infrastructure de services hébergés visible et d'un dossier réseau ancré à Hong Kong, mais les clients devraient traiter sa capacité commercialisée comme dépendante de sites physiques et de chemins tiers qui ne sont que partiellement visibles.

Pour les petits sites Web, les environnements de test et les charges de travail sensibles aux coûts, cela peut être acceptable si le client conserve des sauvegardes et surveille le préfixe assigné. Pour les charges de travail avec état, réglementées ou critiques pour le chiffre d'affaires, l'acheteur devrait poser des questions plus difficiles avant de compter sur Yisu comme plateforme principale: quelle installation, quel ASN, quels fournisseurs amont, quel emplacement de sauvegarde, quel chemin d'escalade du support, quelle méthode de sortie et quelle fenêtre de réparation. La capacité cloud est vendue comme un choix de panneau de contrôle.

Chez YISU CLOUD LTD, comme chez tous les fournisseurs d'hébergement, le service repose en fin de compte sur des baies, du transit et des personnes capables de réparer les choses quand le panneau de contrôle ne suffit plus.