Data Hub Pvt. Ltd. et le rack népalais qui doit battre la distance

Résumé

• Data Hub Pvt. Ltd. semble plus substantiel qu'une simple étiquette d'hébergement, car les enregistrements APNIC, la visibilité RIPEstat, un domaine d'entreprise actif et les propres pages d'installation de l'entreprise indiquent tous un opérateur de cloud et de centre de données basé au Népal avec AS18222, des revendications d'installations à Katmandou et Butwal, des services de colocation, VPS, plateforme, sauvegarde et sécurité.
• L'analyse d'investissement reste conditionnelle. Les archives publiques soutiennent une entreprise d'infrastructure locale, mais ne prouvent pas entièrement le nombre d'armoires, l'utilisation, la capacité électrique, la disponibilité auditée, les clients nommés, les contrats en amont ou l'économie d'un rack népalais face à la profondeur du cloud en Inde et à Singapour.
• La décision du client repose donc sur l'endroit où les frictions sont les moins coûteuses: payer Data Hub pour la sauvegarde de l'alimentation, le refroidissement, la sécurité, les interventions à distance, la facturation locale et la latence nationale, ou accepter une dépendance transfrontalière en échange d'une largeur hyperscale, d'une automatisation et d'une capacité de base moins chère.

Établissement: Data Hub apparaît dans APNIC en tant queORG-DHPL2-AP, un LIR au Népal avec l'adresse Thapathali et le contact d'assistance visible surhttps://wq.apnic.net/query?searchtext=ORG-DHPL2-AP. APNIC répertorie également AS18222 en tant queDATAHUB-AS-APpour Data Hub surhttps://wq.apnic.net/query?searchtext=AS18222, tandis que RIPEstat signale l'ASN comme annoncé avec des préfixes visibles surhttps://stat.ripe.net/data/as-overview/data.json?resource=AS18222ethttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS18222. Le propre site de l'entreprise à l'adressehttps://datahub.com.np/décrit DataHub Népal comme le propre fournisseur de services cloud du Népal et renvoie vers des pages de centre de données, de colocation et de cloud.

Inférence raisonnable: Data Hub ne se contente pas de revendre un serveur virtuel étranger sous une marque népalaise. Son site, ses enregistrements de ressources d'adresses, les traces de serveur de noms DataHub, les étiquettes IPv6 de Yeti Cloud et le site Web de l'entreprise routé par DataHub suggèrent une empreinte opérationnelle nationale avec une véritable périphérie réseau. L'inférence doit rester limitée: les enregistrements de routage publics montrent le contrôle et la visibilité; ils ne révèlent pas la puissance de l'armoire, la surface au sol, la concentration de clients ou la rentabilité.

Il manque encore: un acheteur sérieux demanderait toujours une visite actuelle des installations, une preuve de schéma unifilaire électrique, une politique de carburant pour le générateur, des résultats de tests de redondance de refroidissement, des journaux de contrôle d'accès, des certificats ISO et PCI, une assurance, des données de réponse du support, des contrats en amont, des preuves de participation au NPIX, des références clients, la disponibilité actuelle des armoires et des crédits de service clairs. Sans ces documents, l'économie peut être jugée mais pas garantie.

Le premier calcul est fait par un client, pas par un fournisseur

Imaginez une entreprise de paiement à Katmandou, une plateforme de streaming népalaise ou un fournisseur de logiciels provincial avec une base de données sensible, utilisée quotidiennement et intolérante aux pannes imprécises. L'acheteur a trois hébergements plausibles pour la charge de travail. Il peut louer de la capacité cloud en Inde, où Mumbai, Hyderabad et Delhi ont des écosystèmes plus profonds et des menus de services gérés plus solides. Il peut utiliser Singapour, où la capacité cloud régionale est dense et l'outillage opérationnel est mature. Ou il peut placer un rack, un cloud privé virtuel ou une plateforme gérée au Népal et payer un opérateur local pour transformer l'électricité, le refroidissement, la sécurité, le transit IP et les interventions d'urgence en une promesse de disponibilité.

La comparaison cloud commence par un fait qui semble peu flatteur pour tout fournisseur népalais. La propre documentation des régions d'Amazon répertorie les régions Asie-Pacifique à Hyderabad, Mumbai et Singapour surhttps://docs.aws.amazon.com/general/latest/gr/rande.html. La documentation des emplacements de calcul de Google Cloud répertorie les zones de Mumbai, Delhi et Jurong West, Singapour surhttps://cloud.google.com/compute/docs/regions-zones. La page d'infrastructure mondiale de Microsoft répertorie l'Inde centrale, l'Inde du Sud, l'Inde de l'Ouest et l'Asie du Sud-Est surhttps://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/. La page des régions publiques d'Oracle répertorie les régions Inde Ouest à Mumbai, Inde Sud à Hyderabad et Singapour surhttps://www.oracle.com/cloud/public-cloud-regions/. Ces plateformes offrent un menu qu'aucun fournisseur népalais local ne peut reproduire à l'identique: bases de données gérées, stockage d'objets, contrôles d'identité, files d'attente sans serveur, conception multi-zones, logiciels de marché et cadres d'approvisionnement que les auditeurs multinationaux connaissent déjà.

Mais l'acheteur népalais ne vit pas dans un diagramme cloud mondial. Il vit dans des factures, des files d'attente d'appels, des audits bancaires, des chemins de routeurs, des approbations d'achat et des coupures de courant. La question n'est pas de savoir si Data Hub peut dépasser AWS ou Google; il ne le peut pas. La question est de savoir si une charge de travail hébergée au Népal résout suffisamment de problèmes locaux pour justifier une plateforme plus petite. Pour un client dont les utilisateurs, les régulateurs, les réseaux de succursales et les équipes de support sont principalement au Népal, un rack local peut être une protection contre la distance. Il peut réduire les allers-retours nationaux, placer les ingénieurs à portée de taxi du matériel, faciliter les réponses sur la localisation des données et permettre un paiement en monnaie locale plutôt que par le biais d'achats en devises étrangères. Il peut également transférer les aspects difficiles vers un bilan local: carburant de générateur, batteries UPS, maintenance du refroidissement, sécurité physique, délais d'importation et contrats de bande passante.

C'est pourquoi les preuves publiques de Data Hub sont importantes. L'acheteur ne décide pas si le Népal mérite un drapeau cloud. Il décide si cette entreprise particulière a suffisamment de substance pour justifier la confiance. Une marque qui se contente de louer une capacité VPS étrangère et d'ajouter un discours commercial local ne battrait pas la distance de Mumbai ou Singapour. Un fournisseur avec de véritables installations locales, des ressources d'adresses nationales, un routage visible, une capacité d'intervention à distance et un deuxième site résilient pourrait le faire.

L'empreinte publique de Data Hub pointe vers l'infrastructure, avec des lacunes qu'un acheteur ne devrait pas ignorer

La propre page d'accueil de Data Hub àhttps://datahub.com.np/présente l'entreprise comme "le propre fournisseur de services cloud du Népal" et indique que ses doubles centres de données à Katmandou et Butwal fournissent une infrastructure sécurisée, des performances et un support 24/7. La page n'est pas seulement une brochure déconnectée des preuves réseau. Une recherche DNS au cours de cette recherche a résoludatahub.com.npen45.115.219.68, et les enregistrements de route APNIC pour l'espace45.115.219.0/24environnant apparaissent sous la preuve d'origine de route de Data Hub. Le site public est donc un indice utile: la présence Web de l'entreprise est hébergée sur un espace d'adresses que l'enregistrement de routage public associe à Data Hub, plutôt que sur un simple hébergeur offshore générique.

L'enregistrement APNIC est la preuve la plus solide. Surhttps://wq.apnic.net/query?searchtext=ORG-DHPL2-AP, Data Hub est répertorié comme une organisation APNIC,org-type: LIR, au Népal, avec l'adresse "2nd Floor, Shikhar Biz Center, Thapathali" et l'email de supportsupport@datahub.com.np. Surhttps://wq.apnic.net/query?searchtext=AS18222, AS18222 est enregistré en tant queDATAHUB-AS-AP, décrit comme Data Hub Pvt. Ltd., pays Népal. La requête de mainteneur inverse d'APNIC surhttps://wq.apnic.net/query?searchtext=-i%20mnt-by%20MAINT-DATAHUB-NPmontre plusieurs blocs d'adresses et entrées de route maintenues parMAINT-DATAHUB-NP, y compris l'infrastructure Itahari et des étiquettes de pool client, des blocs clients d'entreprise, des étiquettes IPv6 Yeti Cloud et de nombreux enregistrements de route IPv4 et IPv6.

Ces enregistrements ne sont pas des affirmations marketing; ce sont des artefacts opérationnels. Ils montrent que Data Hub maintient des entrées de ressources d'adresses, a des contacts abuse et techniques validés dans APNIC, et a des routes suffisamment visibles pour que RIPEstat signale AS18222 comme annoncé surhttps://stat.ripe.net/data/as-overview/data.json?resource=AS18222. La vue des préfixes annoncés de RIPEstat surhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS18222a répertorié les préfixes visibles, y compris2400:89e0::/32,45.115.216.0/24,45.115.217.0/24,45.115.218.0/24,45.115.219.0/24,45.117.152.0/23,45.117.153.0/24,103.90.84.0/24,103.250.132.0/24,103.250.133.0/24,202.51.68.0/24,202.51.70.0/23,202.51.76.0/24,202.51.82.0/23et202.51.86.0/24dans la fenêtre de fin juin à début juillet 2026.

La mise en garde est tout aussi importante. Le contrôle des ressources réseau prouve que Data Hub est un véritable entité au routage; il ne prouve pas que chaque service annoncé est fourni à partir d'un espace au sol possédé, que tous les préfixes sont destinés aux clients, ou que les installations ont la capacité impliquée par le langage commercial. L'API de réseau public de PeeringDB àhttps://www.peeringdb.com/api/net?asn=18222répertorie "Data Hub Nepal" en tant qu'AS18222 avec une politique de peering ouverte, mais elle a également montréix_count: 0etfac_count: 0dans l'enregistrement retourné. Cela ne signifie pas que Data Hub est absent de tous les échanges ou installations; PeeringDB est autodéclaré et souvent incomplet. Cela signifie que l'entreprise n'a pas fourni d'empreinte PeeringDB publique qui cartographie indépendamment ses emplacements d'interconnexion. Un acheteur doit considérer APNIC et RIPEstat comme des preuves d'infrastructure routée, et les pages d'installation comme des affirmations nécessitant une diligence raisonnable.

Un rack népalais évalue la résilience avant d'évaluer le calcul

Le mot le plus cher sur le site de Data Hub est peut-être "local", pas "cloud". Un rack népalais doit évaluer la sauvegarde de l'alimentation, le refroidissement, la sécurité et la réponse humaine avant d'évaluer le CPU et le stockage. La page du centre de données de Data Hub àhttps://datahub.com.np/services/data-center/our-data-centers/indique que ses installations incluent la certification ISO 27001:2013 et la conformité PCI DSS, une redondance onduleur et générateur diesel N+N, un transformateur dédié, une redondance de refroidissement N+1, une revendication de niveau de service de 99,95 %, un langage de conception Tier-III, une gestion intégrée du bâtiment, une vidéosurveillance, des alarmes incendie, une détection de fuite d'eau, un contrôle des rongeurs, un réseau neutre vis-à-vis des opérateurs, une surveillance 24x7 et un accès biométrique. Si ces affirmations sont actuelles et étayées, elles expliquent pourquoi une armoire au Népal ne peut pas être tarifée comme un VPS de base dans une région hyperscale étrangère.

L'alimentation est le premier poste. Un opérateur de centre de données local doit convertir l'approvisionnement en électricité du Népal en une charge informatique continue. Cela signifie que le client ne loue pas seulement des unités de rack; il achète la capacité du transformateur, l'autonomie de l'onduleur, le remplacement des batteries, les générateurs diesel, la logistique du carburant, la maintenance des commutateurs et les tests périodiques. Dans un petit marché, ces coûts sont répartis sur moins d'armoires qu'à Mumbai ou Singapour. Si la base de clients de Data Hub est dense et stable, la prime d'alimentation peut être amortie. Si l'utilisation est faible, chaque armoire supporte trop de résilience inutilisée.

Le refroidissement est le deuxième poste. Le climat de Katmandou est plus doux que celui de nombreux marchés de centres de données chauds, mais une salle de serveurs ne fonctionne pas avec une météo moyenne. Elle fonctionne avec une discipline de température d'entrée, un contrôle de l'humidité, une panne de ventilateur, de la poussière, un confinement de l'air réfrigéré et des fenêtres de maintenance. La revendication de refroidissement N+1 de Data Hub est économiquement significative car elle indique que les clients paient pour une capacité de réserve, pas seulement pour une pièce avec climatisation. Cette capacité de réserve est importante lorsque l'humidité de la mousson, le vieillissement des équipements ou la croissance modifient le profil thermique de la pièce. Cela alourdit également la charge de diligence de l'acheteur: demander l'architecture de refroidissement, les enregistrements de maintenance et l'historique des incidents, pas simplement un badge.

La sécurité est le troisième. Le site de Data Hub mentionne l'accès biométrique, la vidéosurveillance, les alarmes incendie et la sécurité multi-zones. Pour une banque, une plateforme médiatique ou une entreprise de logiciels, le contrôle physique a une valeur économique différente au Népal par rapport à une région éloignée. Si un serveur tombe en panne, un client peut escalader localement et, dans certains cas, envoyer un gestionnaire ou un ingénieur à l'installation. Cela vaut de l'argent lorsque les temps d'arrêt sont réputationnels et que les tickets des fournisseurs internationaux avancent lentement. La même localité crée cependant un risque de concentration. Si trop de clients dépendent de la même installation de Katmandou, le même événement d'alimentation local, perturbation civile, problème d'accès routier ou pénurie de personnel peut affecter de nombreuses charges de travail nationales.

Le point n'est pas que Data Hub soit nécessairement moins cher que le cloud étranger. Il se peut qu'il ne le soit pas. Le point est que l'offre locale tarife un ensemble différent. Elle vend l'évitement de certaines frictions transfrontalières et le transfert des opérations physiques locales à un spécialiste. Les clients ne devraient pas comparer un rack Data Hub uniquement avec une instance EC2; ils devraient le comparer avec le coût total de l'exécution d'une charge de travail sensible au Népal à l'étranger: ingénierie de latence, explications sur les données transfrontalières, achats en devises étrangères, escalade du support, conception de sauvegarde et absence de mains locales lorsque quelque chose de physique ou de procédural tourne mal.

La table de routage indique que l'entreprise s'étend au-delà d'une seule salle à Katmandou

Les étiquettes APNIC les plus intéressantes ne sont pas celles qui ont l'air célèbres. Ce sont les étiquettes ordinaires:INFRA-ITAHARI, un pool d'infrastructure Itahari;CUST-ITAHARI, un pool client Itahari; des blocs clients d'entreprise; des pools d'affectation temporaire aux clients; et des enregistrements IPv6 utilisantYETI-CLOUDetDATAHUB-IM. Ces étiquettes, visibles viahttps://wq.apnic.net/query?searchtext=-i%20mnt-by%20MAINT-DATAHUB-NP, suggèrent un fournisseur qui organise l'espace d'adressage par cas d'usage et région plutôt qu'une coquille passive autour d'une seule allocation.

Cela est important car la thèse du rack népalais ne se limite pas à Katmandou. La propre page de Data Hub indique que le centre de données de Katmandou est en service depuis 2012 et a servi des institutions bancaires et financières, des entreprises clientes, des ONG et des OING. La même page indique que le centre de données de Butwal est en service depuis 2015 et le décrit comme un bâtiment parasismique d'un seul étage conçu pour la zone sismique du Népal. La page cloud publique àhttps://datahub.com.np/services/cloud/public-cloud-services/indique que Butwal sert de site de reprise après sinistre pour la haute disponibilité et la reprise après sinistre. Un acheteur peut ne pas être en mesure de vérifier ces affirmations à partir du seul site Web, mais l'existence d'étiquettes d'adresses régionales telles qu'Itahari rend l'histoire de l'infrastructure publique de l'entreprise plus large qu'une seule salle à Katmandou.

La table de routage révèle également une dépendance. Les données de cohérence de routage de RIPEstat àhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS18222ont montré des importations et exportations observées impliquant AS17501, AS23647 et AS4007, tandis que les enregistrements APNIC identifient AS17501 comme WorldLink Communications, AS23647 comme Communications & Communicate Nepal, et RIPEstat identifie AS4007 comme Subisu Cablenet. Ce n'est pas une preuve des termes contractuels ou des engagements de capacité. C'est la preuve que l'accessibilité publique de Data Hub se situe à l'intérieur de l'écosystème des opérateurs népalais, pas à l'extérieur. Pour un client, la question pratique est de savoir si Data Hub dispose de suffisamment de diversité en amont, de contrôle de routage et de peering national pour maintenir une charge de travail locale lorsque l'utilisateur est local, et pour éviter un chemin fragile de fournisseur unique lorsque le trafic international est inévitable.

Les preuves d'enregistrements DNS inverses vont dans le même sens. Plusieurs zones inverses maintenues par Data Hub répertorient des serveurs de noms tels quens1.datahub.com.np,nilgiri.subisu.net.np,tilicho.subisu.net.np,dns1.vianet.com.npet d'autres noms d'infrastructure réseau népalais. Ceux-ci ne doivent pas être transformés en affirmations commerciales au-delà des enregistrements eux-mêmes. Mais ils montrent un cadre opérationnel national dans lequel le nom de Data Hub, les serveurs de noms liés à Subisu, les serveurs de noms liés à Vianet et les anciens enregistrements de route de passerelle/opérateur coexistent. C'est exactement l'environnement qu'un fournisseur de centre de données local doit naviguer: il a besoin de suffisamment de neutralité pour attirer des clients de différents fournisseurs d'accès, mais suffisamment de dépendance vis-à-vis des opérateurs pour obtenir une connectivité montante et une redondance abordables.

La localité n'est précieuse que si le trafic reste local quand il le faut

La promesse commerciale d'un rack népalais n'est pas la géographie en soi. La géographie n'aide que si le trafic local évite des détours internationaux inutiles. La page de colocation de Data Hub àhttps://datahub.com.np/services/data-center/co-location/décrit le Népal Internet Exchange comme le point d'échange Internet du pays et indique que NPIX maintient le trafic Internet local au Népal pour améliorer l'efficacité et réduire le besoin de bande passante internationale. Le site Web indépendant du NPIX àhttps://www.npix.net.np/encadre l'échange autour de l'"aide aux FAI pour garder le trafic local local" et a signalé le 5 avril 2026 que le trafic local NPIX avait franchi les 100 Gbps, remerciant les membres d'améliorer la qualité du service avec une meilleure latence.

Pour une entreprise médiatique népalaise, cela est important de manière évidente. Si une vidéo, une image, une passerelle de paiement ou une API de connexion est hébergée au Népal et que le FAI de l'utilisateur dispose d'un chemin national efficace vers celui-ci, le client peut économiser sur la latence et peut-être réduire le transit international coûteux. Si le trafic fait une épingle à cheveux à travers l'Inde, Singapour ou un autre chemin étranger avant de revenir à Katmandou, l'hébergement local perd beaucoup de son intérêt. Le client devrait donc tester des chemins réels à partir des principaux réseaux d'accès népalais, et ne pas simplement accepter qu'un serveur ait une adresse népalaise.

L'enregistrement PeeringDB public de Data Hub est un drapeau d'avertissement ici, pas un facteur disqualifiant. PeeringDB àhttps://www.peeringdb.com/api/net?asn=18222répertorie le réseau mais, dans les données retournées, aucun échange ou installation. Le propre site du NPIX confirme le rôle de trafic local de l'échange, et l'API IX publique de PeeringDB àhttps://www.peeringdb.com/api/ix?name__contains=NPIXrépertorie deux entrées Internet Exchange Népal à Katmandou et Lalitpur. Pourtant, l'enregistrement de Data Hub n'a pas montré publiquement d'attachement au NPIX. Cela laisse une lacune. L'acheteur devrait demander un port NPIX actuel, une politique de serveur de routes, une liste de peering bilatéral, des graphiques de trafic et des traceroutes depuis les plus grands FAI népalais.

La différence entre local et quasi-local est nette. Mumbai et Delhi sont régionalement proches par rapport à l'Europe ou à l'Amérique du Nord, et Singapour est un hub mature. Mais le chemin depuis un utilisateur mobile népalais ou un bureau de succursale vers ces régions est toujours un chemin international avec plus de possibilités de politique, de congestion et de transfert d'opérateur qu'un chemin d'échange national propre. Pour les charges de travail interactives, chaque trajet supplémentaire compte: l'authentification, la prise de décision publicitaire, la confirmation de portefeuille mobile, les opérations de sauvegarde CMS éditoriales, les tableaux de bord des centres d'appels et la surveillance en temps réel ressentent tous la latence avant de ressentir l'échelle théorique du cloud. Pour l'analyse en masse et les SaaS distribués mondialement, le calcul change. Data Hub devrait gagner les charges de travail népalaises sensibles à la latence; il ne devrait pas prétendre que chaque charge de travail appartient au Népal.

La localité de conformité est un produit économique même lorsque la loi n'est pas un mur simple

Le cas de l'hébergement local est souvent décrit comme de la souveraineté des données, mais au Népal, la question pratique est plus granulaire. Une banque, une fintech, une entreprise médiatique, un fournisseur hospitalier, un entrepreneur gouvernemental ou une ONG ne se demande pas seulement "existe-t-il une loi exigeant que cet octet reste au Népal?" Il se demande si l'emplacement de stockage, la chaîne de support, la réponse aux incidents, les preuves d'audit et l'histoire du contrôle d'accès peuvent être expliqués à un conseil d'administration, un régulateur, un donateur, un client ou un comité d'approvisionnement. Le site de Data Hub s'appuie sur ce besoin. La page Yeti Cloud àhttps://datahub.com.np/yeti-cloud/indique que les clients peuvent payer en NPR, éviter les problèmes de paiement en devises étrangères et les fluctuations de change, recevoir un support local 24/7 et fonctionner sur des serveurs locaux au Népal. La page cloud publique indique que ses serveurs cloud offrent un contrôle root et administratif, des sauvegardes instantanées, une haute disponibilité, une reprise après sinistre et une infrastructure sécurisée alignée sur la norme ISO 27001:2013.

C'est un produit vendable. La facturation locale en NPR réduit les frictions d'approvisionnement pour les petites entreprises et les acheteurs adjacents au secteur public. Le support local réduit le temps d'escalade. Un emplacement de serveur local peut simplifier une conversation sur la confidentialité ou le risque sectoriel même lorsque le client a encore besoin de contrats appropriés, de consentement, de règles de conservation et de contrôles de sécurité. Pour les clients financiers, la valeur n'est pas qu'un rack local satisfasse comme par magie à toutes les exigences de conformité. C'est que l'infrastructure locale facilite la collecte de preuves: où les systèmes fonctionnent, qui peut y accéder, où se trouvent les sauvegardes, comment les incidents sont traités et quelle juridiction régit le contrat de service.

La faiblesse est que la localité peut devenir un slogan. Une charge de travail hébergée au Népal mais mal sauvegardée, faiblement surveillée ou exposée par une mauvaise sécurité n'est pas plus sûre qu'une charge de travail bien gouvernée à l'étranger. Un rack local avec des contrôles d'accès non documentés, des interventions à distance informelles et des crédits de service peu clairs peut créer un confort national tout en cachant un risque opérationnel. Inversement, une région hyperscale en Inde ou à Singapour peut offrir un meilleur chiffrement, une meilleure identité, une meilleure journalisation, une meilleure reprise après sinistre, une meilleure documentation de conformité et de meilleurs contrôles d'approvisionnement qu'un petit fournisseur népalais. La tâche du client est d'évaluer l'ensemble, pas le drapeau.

Les affirmations de certifications publiques de Data Hub rendent cette diligence plus importante. Les pages centre de données et à propos indiquent ISO/IEC 27001:2013, et la page centre de données mentionne la conformité PCI DSS. Celles-ci sont pertinentes pour la gestion de la sécurité et les environnements de données de carte, mais les affirmations publiques doivent être mises en correspondance avec les certificats actuels, les déclarations de portée et les dates d'audit. Un certificat pour une installation, un service ou un système de gestion n'est pas automatiquement une preuve pour chaque produit cloud. La valeur économique de la localité de conformité est réelle; les preuves doivent être spécifiques.

La friction d'importation donne aux opérateurs locaux à la fois une barrière et un problème de coût

Le matériel dans un centre de données népalais a un parcours différent de celui de Singapour ou Mumbai. Les serveurs, baies de stockage, équipements réseau, optiques, batteries, systèmes d'incendie et pièces de refroidissement sont susceptibles d'impliquer des fournisseurs étrangers, un dédouanement, une logistique de garantie, des changes et une incertitude sur les délais. Un opérateur local disposant de pièces de rechange, de relations avec les fournisseurs et de fonds de roulement peut transformer cette friction en un avantage de service. Un acheteur qui possède un seul rack peut ne pas vouloir des pièces de rechange, négocier un support à distance avec un fournisseur à l'étranger ou attendre une expédition transfrontalière pendant un incident. La page de colocation de Data Hub promet des experts techniques sur place et des espaces demi-rack, rack complet et unitaires prêts à l'emploi; cela est précieux précisément parce que l'importation et la gestion du matériel ne sont pas triviales pour les petits clients.

La même friction nuit aux marges de Data Hub. Il doit supporter le risque d'équipement avant que le client ne paie la pleine utilisation. Les batteries d'onduleur vieillissent que les armoires soient pleines ou vides. La maintenance du générateur et les contrats de carburant coûtent de l'argent indépendamment du taux de désabonnement mensuel. Les systèmes de refroidissement nécessitent une maintenance préventive. Le personnel de sécurité et la surveillance des installations sont des coûts fixes. Si un client achète un petit plan VPS, le fournisseur amortit toujours une chaîne de matériel importé et de résilience des installations locales derrière. C'est pourquoi la page cloud publique de Data Hub segmente les offres par petits clients, petites et moyennes entreprises et besoins croissants, et pourquoi Yeti Cloud décrit une facturation à l'utilisation basée sur des "cloudlets" de 128 Mo de mémoire et des unités CPU de 400 MHz. L'architecture tarifaire tente de transformer l'infrastructure fixe en consommation granulaire.

Cela crée une tension stratégique. Le meilleur client économique pour Data Hub n'est pas un site amateur. C'est une institution népalaise qui valorise la latence locale, la facturation locale, le support, la souveraineté, la reprise après sinistre et l'accès sécurisé aux installations au point de payer une prime par rapport au calcul de base étranger. Le deuxième meilleur client est un développeur ou une entreprise de logiciels qui souhaite un PaaS national pour les applications de production où l'expérience utilisateur et la simplicité de paiement comptent. Le client le plus faible est un acheteur uniquement axé sur le prix comparant le vCPU et la RAM de base aux promotions mondiales du cloud. Data Hub peut servir ce client, mais ce n'est pas là qu'un opérateur de centre de données local obtient des rendements durables.

La barrière de friction à l'importation est également temporaire si de plus grands opérateurs entrent avec plus de capitaux. Si la demande de cloud national au Népal augmente, les opérateurs, les banques, les groupes d'infrastructure soutenus par le gouvernement ou les entreprises régionales de centres de données pourraient construire de plus grandes installations et répartir les coûts des équipements importés sur une charge plus importante. L'avantage de Data Hub doit donc être l'historique d'exploitation, la confiance nationale, les preuves réseau, la qualité du support et les couches cloud utilisables, pas simplement le fait d'être le premier.

L'offre groupée se rapproche plus d'un service d'infrastructure que d'une plateforme logicielle

Le site public de Data Hub répertorie une large gamme: centre de données, colocation, cloud public, cloud privé, cloud privé virtuel, PaaS Yeti Cloud, sauvegarde en tant que service, reprise après sinistre, stockage d'objets, DNS, CDN, WAF, pare-feu en tant que service, anti-malware, haute disponibilité, protection contre les rançongiciels, SIOS et GPU en tant que service. L'ampleur est commercialement compréhensible. Dans un marché plus petit, un fournisseur ne peut pas toujours survivre avec des armoires seules. Il doit vendre plus de la pile à chaque compte: héberger le rack, fournir les serveurs virtuels, sécuriser la périphérie, sauvegarder les données, gérer le DNS, offrir une reprise après sinistre et peut-être vendre une couche de plateforme pour les développeurs.

Cette ampleur est aussi un risque. Chaque gamme de produits a une compétence différente. La colocation est la discipline de l'alimentation, du refroidissement, de l'accès et de l'interconnexion. Le cloud public est la planification de capacité, la virtualisation, les performances de stockage, l'isolement réseau et la facturation. Le PaaS est l'expérience développeur, l'outillage de déploiement, l'orchestration de conteneurs, la mise à l'échelle, les journaux, le support d'exécution et les mises à niveau de plateforme. Les services de sécurité nécessitent une connaissance des menaces et une maturité opérationnelle. Le CDN nécessite une empreinte de cache et une ingénierie de trafic. Le GPU nécessite un matériel spécialisé à forte intensité de capital et une densité thermique. Une entreprise peut répertorier de nombreux services plus rapidement qu'elle ne peut tous les exploiter correctement.

Les preuves suggèrent que la revendication principale de Data Hub est la plus forte dans la colocation, le cloud local, l'adressage réseau et le support national. La page de colocation indique que des solutions demi-rack et rack complet dédiées préinstallées et des espaces unitaires sont disponibles, et elle met l'accent sur les experts techniques sur place. La page centre de données donne des caractéristiques d'installation concrètes. La page cloud public donne des affirmations de VPS et de disponibilité. La page Yeti Cloud donne un concept PaaS défini avec des cloudlets, une facturation locale et des options de déploiement. Ceux-ci sont cohérents avec un opérateur de centre de données népalais qui monte dans la pile.

Les affirmations les plus minces sont celles où l'échelle compte le plus. Le CDN et les services GPU peuvent être utiles, mais sans cartes de trafic publiques, spécifications matérielles ou exemples clients, ils restent des preuves de niveau marketing. Un acheteur doit séparer les "services que Data Hub peut vendre" des "services que Data Hub peut exploiter à la norme du cloud régional". L'approche d'achat correcte est modulaire: utiliser Data Hub pour les charges de travail où la localité népalaise et le support humain comptent, exiger des preuves pour les services gérés de couche supérieure, et garder le cloud étranger disponible pour les fonctions qui nécessitent une profondeur hyperscale ou des bases de données gérées spécialisées.

Butwal change l'histoire de la reprise après sinistre, s'il est conçu plutôt que symbolique

La revendication de l'installation de Butwal est stratégiquement importante. Un fournisseur uniquement basé à Katmandou peut vendre de la latence locale, mais il peine à vendre une reprise après sinistre nationale. La page centre de données de Data Hub indique que le centre de données de Butwal est en service depuis 2015 et est hébergé dans un bâtiment parasismique d'un seul étage conçu pour la zone sismique du Népal. La page cloud publique ajoute que Butwal sert de site de reprise après sinistre. C'est exactement le genre de preuve qu'un client népalais devrait vouloir: assez local pour le confort réglementaire et opérationnel, assez loin de Katmandou pour réduire certains risques corrélés.

Pourtant, la distance seule n'est pas une architecture de reprise après sinistre. La question commerciale est de savoir si Data Hub peut répliquer des charges de travail entre Katmandou et Butwal avec le bon temps de récupération, le point de réplication, la bande passante, la cadence de test, les contrôles d'accès et le processus de retour arrière. Une déclaration sur un site Web ne peut pas répondre à cela. Un client financier devrait demander des exemples de manuels de reprise, les derniers résultats de tests, les options de réplication, la diversité des chemins réseau, le langage des crédits de service et la différence exacte entre sauvegarde, veille, actif-actif et récupération à froid. Une plateforme médiatique devrait demander si Butwal peut prendre le trafic utilisateur en charge, pas seulement conserver des copies. Un fournisseur de logiciels devrait demander comment le DNS, les certificats, les bases de données et les magasins de fichiers se déplacent pendant une panne.

Si la conception de Butwal est réelle et régulièrement testée, elle donne à Data Hub un avantage national significatif. Un client népalais peut éviter de choisir entre aucune reprise locale et une dépendance totale à l'étranger. Il peut conserver les systèmes primaires à Katmandou, répliquer à Butwal et réserver l'Inde ou Singapour pour les sauvegardes tertiaires, l'analyse ou les services mondiaux. Cette posture hybride est plus réaliste qu'un slogan de souveraineté pure. Elle reconnaît le besoin de contrôle local du Népal tout en acceptant qu'une certaine résilience puisse encore nécessiter une capacité transfrontalière.

Si la conception de Butwal est symbolique, le risque est pire que le silence. Les clients peuvent croire qu'ils ont une résilience nationale alors qu'ils ne détiennent en réalité que des sauvegardes faibles ou des étapes de récupération manuelles. La meilleure décision commerciale de Data Hub serait de publier des options de récupération plus claires: des niveaux de réplication intra-Népal, des bandes RTO/RPO testées, des responsabilités clients, des contraintes de bande passante et une portée d'audit indépendante. D'ici là, Butwal est une fonctionnalité prometteuse qui doit être vérifiée compte par compte.

L'ensemble concurrentiel est le cloud étranger, les opérateurs locaux et la propre salle de serveurs du client

La concurrence de Data Hub n'est pas un seul rival. C'est un triangle. Le premier côté est le cloud hyperscale étranger. Les régions de l'Inde et de Singapour offrent des services que Data Hub ne peut égaler en ampleur. Elles sont attrayantes pour les startups nécessitant des bases de données gérées, des outils d'IA, de l'analyse, de la diffusion de contenu mondiale, des services d'identité et un approvisionnement rapide via des canaux établis. Elles réduisent également l'inquiétude de l'acheteur concernant l'infrastructure physique. Le fournisseur, et non le client, gère d'énormes budgets d'alimentation, de refroidissement, de redondance et de sécurité.

Le deuxième côté est l'écosystème des opérateurs et FAI népalais. Les preuves de routage public montrent que Data Hub vit à l'intérieur d'un marché où WorldLink, Subisu, Communications & Communicate Nepal, les traces de serveur de noms liées à Vianet et le contexte NPIX comptent. Les opérateurs peuvent héberger, faire du peering, revendre, construire des installations ou regrouper la connectivité d'entreprise avec une infrastructure gérée. Un opérateur avec un contrôle de dernier kilomètre peut parfois vendre un package d'entreprise plus simple: ligne d'accès, pare-feu, serveur hébergé, sauvegarde et support. La réponse de Data Hub doit être la neutralité et la spécialisation. Sa page de colocation indique explicitement que son écosystème inclut des plateformes cloud, des fintechs, de grands réseaux d'opérateurs et des fournisseurs de services TIC, et décrit un réseau neutre vis-à-vis des opérateurs. L'acheteur devrait tester cette neutralité: peut-il apporter les opérateurs de son choix, se connecter facilement et éviter d'être verrouillé sur un seul fournisseur d'accès?

Le troisième côté est la propre salle de serveurs du client. De nombreuses organisations népalaises ont historiquement fait fonctionner des serveurs dans des bureaux, des succursales ou des salles improvisées parce que les options d'hébergement local étaient limitées, les habitudes d'approvisionnement étaient locales et les applications étaient petites. Le discours économique de Data Hub est de professionnaliser ces dépenses. Au lieu d'acheter un générateur, un rack, un refroidissement, un contrôle d'accès et une rotation de personnel, le client paie un fournisseur dont tout le travail est de maintenir l'environnement en vie. La proposition de valeur est la plus claire là où le client paie déjà des coûts cachés: personnel informatique dormant près d'un bureau pendant les pannes, importations de matériel d'urgence coûteuses, sauvegardes incohérentes, sécurité physique faible et reprise après sinistre sous-testée.

Data Hub ne gagnera pas tous les triangles. Si la charge de travail est mondiale, très élastique, riche en services gérés ou sensible aux coûts, le cloud étranger peut gagner. Si la charge de travail est un simple ensemble de connectivité, un opérateur peut gagner. Si la charge de travail est minuscule et non critique, un serveur de bureau ou un VPS bon marché peut gagner. Data Hub gagne là où la localité népalaise, les opérations d'installation professionnelles et l'indépendance du réseau ont plus de valeur que la profondeur de la plateforme mondiale.

Les signaux non officiels modestes sont plus utiles que le battage médiatique

Les signaux non officiels peuvent induire en erreur sur les marchés d'infrastructure, mais ils sont toujours utiles lorsqu'ils sont lus modestement. Les métadonnées de la page Facebook de Data Hub àhttps://www.facebook.com/datahubnepaldécrivent la page comme DataHub Népal et indiquent que l'entreprise est un fournisseur de centre de données Internet certifié ISO, de qualité télécom et neutre vis-à-vis des opérateurs; elle expose également une audience visible de plusieurs milliers. Le profil X àhttps://x.com/DataHubNepalmontre le pseudonymeDataHubNepal, un profil créé en novembre 2016 et un très faible volume de publications. Ces signaux ne prouvent pas le chiffre d'affaires. Ils suggèrent une entreprise qui a une identité publique depuis des années, avec plus de gravité sur Facebook et le site d'entreprise que sur X.

La propre page des réalisations de l'entreprise àhttps://datahub.com.np/achievement/indique que Data Hub a remporté un National ICT Award 2024 et encadre le prix autour de la contribution à l'infrastructure informatique et au paysage numérique du Népal. Comme la même page est auto-publiée, elle doit être traitée comme une affirmation de l'entreprise, sauf si elle est mise en correspondance avec une archive gouvernementale ou de prix indépendante. Même ainsi, l'affirmation est commercialement pertinente: l'entreprise veut être comprise comme une infrastructure nationale, pas comme un fournisseur d'hébergement générique.

La conception Web publique elle-même envoie un signal mitigé. Le site expose un catalogue de services large et moderne et un portail cloud en direct àhttps://cloud.datahub.com.np/et un lien d'application àhttps://app.yetiapp.cloud/. Il a également un texte qui exagère parfois, comme la formulation "le seul du Népal" pour Yeti Cloud et le langage "installations à 100 % de disponibilité" sur la page centre de données. Les clients sérieux devraient ignorer les superlatifs et demander des preuves mesurées. Un fournisseur peut être utile et pourtant faire un marketing trop agressif. En fait, la lecture sobre est meilleure pour Data Hub: les preuves réelles se trouvent dans APNIC, RIPEstat, les spécificités des installations et les produits cloud nationaux visibles, pas dans les plus grands adjectifs.

L'enregistrement limité de PeeringDB est un autre signal non officiel. Une entreprise cherchant des clients d'infrastructure neutre vis-à-vis des opérateurs bénéficie souvent de la publication de la présence d'installations et d'échanges. L'enregistrement réseau PeeringDB public de Data Hub existe, mais sans installations visibles ni attachements d'échange. Ce n'est pas fatal au Népal, où les enregistrements peuvent être mal maintenus, mais c'est une opportunité de crédibilité manquée. Si Data Hub veut que les acheteurs croient en sa périphérie neutre vis-à-vis des opérateurs, un profil PeeringDB plus complet, un looking-glass public, une politique de routage, des preuves d'adhésion au NPIX et des détails d'interconnexion d'installations feraient plus qu'une autre fiche produit.

Ce qui changerait le jugement, c'est la preuve d'utilisation

Le jugement actuel est prudemment positif: Data Hub semble être un véritable opérateur d'infrastructure népalais avec des revendications d'installations nationales, un portefeuille cloud actif, des preuves d'organisation enregistrée auprès d'APNIC, le routage AS18222, des préfixes visibles et une thèse de support local. Cela suffit à justifier une attention sérieuse de la part d'un client népalais dont la charge de travail est sensible à la latence, à la conformité ou opérationnellement pénible à héberger à l'étranger.

Cela ne suffit pas à déclarer Data Hub comme un service public de cloud national éprouvé. Les données manquantes sont les affaires. Combien d'armoires sont actives? Quelle quantité d'énergie est contractée et réellement utilisable pour la charge informatique? Quelle est la capacité vendable à Katmandou et Butwal? Quelle part de cette capacité est remplie par des banques, des entreprises, des ONG, des sociétés de logiciels et des charges de travail adjacentes au secteur public? Les revenus proviennent-ils principalement de la colocation, du VPS, du PaaS, de la sauvegarde, de la sécurité ou de projets ponctuels? Les clients renouvellent-ils parce que le service est solide ou parce que la migration est difficile? Data Hub a-t-il des marges saines après l'alimentation, le diesel, le refroidissement, le matériel importé, le personnel de support et le transit en amont?

La concentration de la clientèle pourrait rapidement changer la vision. Si quelques comptes financiers ou liés au gouvernement dominent les revenus, l'entreprise peut être stable mais exposée aux cycles d'approvisionnement et aux chocs de réputation. Si la base est large parmi les entreprises de logiciels, les médias, les PME, les ONG et les entreprises, l'entreprise est plus résiliente mais la complexité du support augmente. Si la plupart des revenus proviennent de l'hébergement VPS à bas prix, l'entreprise peut avoir du mal à financer la résilience des installations. Si la plupart des revenus proviennent de la colocation et du cloud privé géré pour les institutions, l'économie est plus défendable.

La résilience en amont pourrait également changer la vision. RIPEstat voit les importations et exportations avec les ASN des opérateurs népalais, mais les données publiques ne montrent pas la redondance contractuelle ou la capacité. Un seul mélange en amont faible peut saper l'histoire de latence locale. Un mélange solide, avec du peering national, plusieurs sorties internationales et un basculement testé, peut faire de Data Hub une plateforme locale véritablement stratégique. Il en va de même pour l'alimentation: les revendications N+N et N+1 publiées comptent, mais les tests réels de générateur, l'autonomie en carburant, la discipline de maintenance et l'historique des incidents comptent plus.

Enfin, la preuve d'une reprise après sinistre auditée serait décisive. L'installation de Butwal est potentiellement le différenciateur le plus important de Data Hub. S'il s'agit d'un site de reprise après sinistre fonctionnel, testé, avec des produits de réplication clairs et des références clients, Data Hub a une réponse solide au principal dilemme de l'acheteur népalais. S'il s'agit principalement d'une revendication, le fournisseur retombe sur un hébergement local ordinaire avec une empreinte réseau utile mais limitée.

La facture mensuelle doit inclure le cas de défaillance

La façon la plus claire d'évaluer Data Hub est de demander ce qui se passe lors d'une mauvaise semaine. Lors d'une semaine normale, le cloud étranger peut sembler moins cher et plus pratique. Un développeur peut provisionner une base de données à Mumbai, attacher un stockage d'objets, automatiser les sauvegardes et s'appuyer sur un catalogue de services testé par des millions de clients. Un rack local semblera moins élégant. Il peut nécessiter une conversation commerciale, une fenêtre de migration, une coordination de pare-feu, des formalités administratives locales et une relation de support qui semble plus manuelle qu'une console. Cette comparaison est incomplète parce que le client évalue uniquement le calcul en régime permanent, pas le mode de défaillance.

Lors d'une mauvaise semaine, la charge de travail hébergée au Népal a différentes options. Si le matériel tombe en panne, les interventions à distance peuvent remplacer un disque, réinsérer un équipement, vérifier les voyants, tracer un câble de raccordement ou escalader vers un ingénieur local. Si une question d'audit arrive, le client peut produire une adresse népalaise, une facture locale, une chaîne de support locale et, si le contrat le permet, des preuves d'installation. Si les utilisateurs se plaignent des performances, le client peut tester les routes nationales et demander si le trafic quitte le pays inutilement. Si l'approvisionnement bloque un renouvellement en devise étrangère, la facturation locale réduit le choc opérationnel. Si une application de succursale est critique lors d'un incident local, avoir le fournisseur dans le même pays peut raccourcir la boucle d'escalade humaine.

L'option locale a également des risques de mauvaise semaine. Si le carburant du générateur n'est pas géré, une panne de courant devient la panne du client. Si la redondance de refroidissement n'est pas maintenue, une armoire pleine de matériel payé devient du capital sensible à la chaleur. Si la diversité en amont est faible, l'hébergement local peut échouer à la frontière ou à un transfert d'opérateur national. Si les pièces de rechange ne sont pas en stock, la friction d'importation revient au pire moment. Si les contrôles de sécurité sont informels, l'accès local devient une vulnérabilité au lieu d'un avantage. C'est pourquoi l'acheteur devrait évaluer Data Hub à travers une feuille de calcul de défaillance: autonomie d'alimentation, basculement de refroidissement, accès physique, réponse des interventions à distance, basculement en amont, restauration de sauvegarde, récupération Butwal, remplacement de pièces et escalade du support.

Cette feuille de calcul peut justifier une prime. Un rack qui empêche une panne matérielle pour une banque, un diffuseur, un service de paiement, un fournisseur hospitalier ou un entrepreneur de service public peut être moins cher que l'économie de cloud étranger sacrifiée. Elle peut également exposer un surcoût. Si le fournisseur ne peut pas documenter le cas de défaillance, le client paie pour la localité comme une histoire plutôt que comme une capacité opérationnelle. Les preuves publiques de Data Hub sont suffisamment solides pour entamer cette conversation; elles ne sont pas suffisamment solides pour l'ignorer.

La bonne conclusion est un hybride, pas un drapeau

Le client népalais ne devrait pas demander si Data Hub est meilleur que l'Inde ou Singapour dans l'abstrait. Il devrait demander quelle partie de la charge de travail paie pour la localité. La latence face au client à l'intérieur du Népal, les données financières ou personnelles nécessitant une responsabilité locale claire, les charges de travail nécessitant des interventions à distance locales, les systèmes liés aux succursales nationales et les applications où la facturation en NPR et le support local comptent sont des candidats plausibles pour Data Hub. Les grandes analyses, les composants SaaS mondiaux, les charges de travail lourdes en IA, les patrimoines de bases de données gérées et la capacité de pointe peuvent encore appartenir à l'Inde, Singapour ou une autre région hyperscale.

Cette réponse hybride n'est pas un compromis contre Data Hub; c'est la version la plus forte du marché de l'entreprise. Un fournisseur local n'a pas besoin de remplacer le cloud hyperscale pour être économiquement important. Il doit être le point de contrôle du Népal: l'endroit où les systèmes nationaux critiques peuvent fonctionner près des utilisateurs, près des équipes de support et près des régulateurs, avec suffisamment d'indépendance de routage et de discipline d'installation pour battre les coûts cachés de la distance. Le dossier public de Data Hub donne du poids à cette affirmation. APNIC et RIPEstat montrent un réseau annoncé. Le site de l'entreprise montre des produits d'installation, de colocation et de cloud. Le contexte NPIX explique pourquoi les chemins locaux peuvent être importants. Les signaux sociaux et PeeringDB ajoutent de la couleur mais montrent aussi où les preuves sont minces.

Le test d'achat final est pratique. Demander à Data Hub de montrer le rack, la chaîne d'alimentation, la redondance de refroidissement, le processus d'accès, la conception de récupération Butwal, les chemins en amont, les preuves de peering NPIX ou national, la rotation de support, la portée du certificat et le calcul des crédits de service. Ensuite, exécuter des traceroutes et des tests d'application à partir des principaux réseaux d'accès népalais. Si les réponses sont solides, le rack local vaut la peine d'être payé: non pas parce que le Népal est loin de la carte du cloud, mais parce que certaines charges de travail népalaises deviennent moins chères, plus rapides et plus gouvernables lorsque l'infrastructure est proche. Si les réponses sont faibles, l'Inde et Singapour restent la valeur par défaut plus sûre, et Data Hub reste un nom prometteur plutôt qu'une surface opérationnelle éprouvée.