Résumé

  • Cloud 9 commercialise publiquement une large offre de services technologiques à White Plains et Westchester, incluant l'IT géré, les solutions hébergées dans le cloud, le support réseau et serveur, la cybersécurité, la sauvegarde et la reprise après sinistre. Ces pages montrent ce que l'entreprise déclare vendre, mais pas l'infrastructure qu'elle contrôle ni le fonctionnement de ces services.
  • Les enregistrements du registre ARIN fournissent des preuves plus solides. Ils enregistrent AS3700 en tant que CLOUD9 pour Cloud 9 Internet, Inc., identifient des ressources IPv4 et IPv6 détenues de longue date et relient l'enregistrement à l'adresse de White Plains et au contact technique de l'entreprise.
  • RIPEstat ajoute un niveau d'observation récent. Dans la fenêtre d'observation de juillet 2026, il montrait AS3700 comme annoncé et associé à cinq préfixes IPv4 et IPv6 listés.
  • L'empreinte de routage visible ne prouve ni la capacité d'hébergement utilisable, ni la propriété des installations, ni le nombre de centres de données, ni la redondance physique, ni le nombre de clients, ni les résultats de sauvegarde, ni les performances SLA, ni les rôles commerciaux des réseaux voisins observés. Ce sont des questions de due diligence, pas des conclusions.

Réseau visible et pile de services opaque

Les services cloud sont souvent les plus faciles à comprendre au niveau produit et les plus difficiles à vérifier en dessous. Un fournisseur peut décrire la migration, l'accès à distance, la surveillance, la sauvegarde, la reprise et la sécurité dans un langage commercial précis, tout en divulguant peu sur les équipements, installations, contrats réseau et résultats opérationnels qui rendent ces promesses possibles. Cloud 9 est un cas utile car ses dossiers publics révèlent les deux côtés de ce fossé, bien qu'avec des forces de preuve inégales.

D'un côté, les propres pages de Cloud 9. Elles décrivent une entreprise basée à White Plains servant Westchester, avec une offre incluant l'IT géré et co-géré, la migration vers le cloud, les systèmes hébergés, la gestion réseau, le support serveur, les services Microsoft 365, la cybersécurité ainsi que la sauvegarde et la reprise après sinistre. C'est une offre opérationnelle large. Elle dit à un client potentiel quelles charges Cloud 9 est prêt à prendre en charge et quels résultats l'entreprise souhaite associer à son nom.

De l'autre côté, les registres publics de numéros Internet. ARIN identifie Cloud 9 Internet, Inc. comme le registrant d'AS3700 et de certaines ressources d'adresses. RIPEstat montre que le système autonome a été annoncé pendant la période d'observation et liste les préfixes associés. Ces enregistrements ne dépendent pas du libellé d'une page de vente. Ils établissent une identité réseau publique durable et une surface de routage actuellement visible.

L'erreur serait de fusionner ces deux surfaces en une seule affirmation. Un enregistrement de système autonome n'est pas un certificat de capacité. Un préfixe annoncé n'est pas un rapport de disponibilité. Une page de service affirmant que les sauvegardes sont vérifiées n'est pas une preuve publiée de tests de restauration réussis. Un voisin de routage n'est pas automatiquement un fournisseur de transit, un client, un pair ou un partenaire d'installation. Chaque point répond à une question différente, et la qualité d'une évaluation d'infrastructure dépend du fait de garder ces questions séparées.

Le dossier public soutient donc une thèse limitée. Cloud 9 n'est pas seulement un nom accroché à un dépliant cloud générique: AS3700 et ses ressources d'adresses confèrent à l'entreprise une empreinte réseau identifiable avec des racines dans l'ère antérieure de l'Internet commercial. Cloud 9 maintient également une offre actuelle de MSP et de services cloud. Néanmoins, le lien entre les ressources réseau visibles et la capacité vendue via cette offre reste largement non documenté. Le réseau est visible; l'implémentation derrière les affirmations de service ne l'est pas.

Du FAI local au fournisseur de services gérés – selon Cloud 9

Cloud 9 décrit son histoire comme commençant en 1993, lorsqu'il serait devenu le premier fournisseur d'accès Internet de Westchester. Le récit commence par un problème de connectivité locale et évolue vers une croissance en tant que FAI complet pour Westchester et New York. L'entreprise indique s'être ensuite étendue à l'hébergement professionnel, au DSL, à la colocation et aux services WAN gérés. Elle affirme également avoir exploité son propre centre de données lors de grandes pannes précédentes et s'être transformée d'ISP à MSP d'ici 2010.

Cette histoire est pertinente car les données ARIN sont largement compatibles avec une origine Internet précoce. Les enregistrements de ressources IPv4 de Cloud 9 datent de mars 1994, tandis qu'AS3700 porte une date d'enregistrement de juillet 1994. Ces enregistrements ne confirment pas indépendamment chaque jalon du récit de l'entreprise, mais ils montrent que l'identité réseau n'est pas une nouvelle étiquette pour le marketing cloud contemporain. Les ressources de numéros publics relient l'entreprise à l'infrastructure Internet du milieu des années 1990.

La distinction entre cohérence et confirmation est importante. ARIN peut soutenir l'affirmation selon laquelle Cloud 9 Internet, Inc. possédait des ressources Internet enregistrées tôt dans son histoire. Mais ces seuls enregistrements ne permettent pas de déduire que Cloud 9 était le premier FAI de Westchester, combien d'abonnés il desservait, quel équipement il exploitait, quelle était l'étendue de sa couverture géographique, ou comment s'est comporté le centre de données propriétaire allégué. Ce sont des déclarations de la page d'histoire de l'entreprise, sauf si elles sont étayées ailleurs.

Le passage d'ISP à MSP change également ce qu'un lecteur devrait rechercher. L'empreinte publique d'un ISP peut être partiellement lisible via les systèmes autonomes, les allocations d'adresses et les annonces de routes. La valeur d'un MSP est davantage opérationnelle et contractuelle. Elle peut résider dans la configuration des systèmes, la surveillance des environnements clients, la réponse aux incidents, la maintenance logicielle, la coordination des fournisseurs, la protection des sauvegardes et la reprise des services. Une grande partie de cela ne génère pas d'artefact de routage public.

La persistance d'AS3700 peut donc éclairer les origines de Cloud 9 sans mesurer le poids actuel de chaque ligne de service.

L'histoire de Cloud 9 explique néanmoins pourquoi ces couches coexistent. L'entreprise actuelle vend des opérations technologiques externalisées mais porte une identité réseau de son époque ISP. Cet héritage peut être utile. Il peut indiquer une continuité institutionnelle, une histoire technique et une relation directe avec les ressources de numéros Internet. Mais il ne montre pas par lui-même quelle part de l'offre d'hébergement cloud actuelle fonctionne sur des ressources sous le contrôle de Cloud 9, quelle part dépend de tiers, ou comment l'entreprise répartit la responsabilité entre eux.

La surface opérationnelle publique actuelle

Les informations actuelles sur le lieu et le support de Cloud 9 offrent une vue plus concrète qu'une histoire générale. L'entreprise liste le 222 Bloomingdale Road à White Plains, New York, et publie des numéros de support client, dont (914) 696-4000 et (914) 696-4100. Son centre de support indique que le service d'assistance est occupé activement de 8h à 18h et présente le téléphone comme le moyen le plus rapide d'obtenir du support.

Ces détails établissent une surface de contact et de support identifiable. Ils montrent que Cloud 9 invite publiquement les clients à joindre un service d'assistance et associe cette fonction à une fenêtre quotidienne spécifiée. Le numéro de téléphone chevauche également celui du contact technique ARIN pour AS3700, créant un lien étroit mais utile entre l'identité de service public et l'identité réseau enregistrée.

La page de support ne devrait pas être utilisée pour prouver plus qu'elle ne le fait. Une fenêtre de personnel spécifiée ne divulgue ni le nombre ou la qualification des employés, ni les temps de réponse, ni la couverture d'escalade en dehors de cette fenêtre, ni les volumes de tickets, ni les taux de résolution, ni les niveaux de service contractuels. La description du support téléphonique comme le moyen le plus rapide est une instruction de l'entreprise, pas une preuve mesurée comparant les canaux.

L'adresse établit où Cloud 9 déclare être basé; elle ne prouve pas que l'adresse est un bureau propriétaire, un centre de données, ou l'emplacement physique d'une plateforme hébergée.

Néanmoins, la surface de support actuelle est significative. Cloud 9 ne présente pas seulement un enregistrement réseau archivé. L'entreprise publie un catalogue de services actif, un chemin de support, des numéros de téléphone et une adresse à White Plains. Ces éléments montrent une position commerciale actuelle dans le Westchester. Les questions sans réponse concernent le modèle de livraison et les résultats, pas le fait que Cloud 9 se présente toujours comme une entreprise de services technologiques en activité.

Ce que l'offre d'hébergement cloud dit réellement

La page « Cloud-Hosted Solutions » est l'expression la plus claire de l'offre actuelle de Cloud 9. Elle présente le service comme un moyen de réduire la dépendance aux serveurs sur site du client. Cloud 9 déclare que les applications, fichiers et systèmes peuvent être hébergés dans un environnement cloud sécurisé, tandis que la maintenance des serveurs, les mises à jour et les sauvegardes sont prises en charge dans le cadre du service externalisé. La page promet également un accès à distance et une surveillance 24h/7j.

En termes commerciaux pratiques, cette offre combine remplacement d'infrastructure et délégation opérationnelle. Le client est invité à passer de la maintenance d'un serveur local à un service où Cloud 9 coordonne l'hébergement et les travaux techniques récurrents. L'offre ne concerne donc pas seulement la capacité de calcul. Il s'agit aussi de savoir qui surveille l'environnement, qui applique les mises à jour, qui maintient les sauvegardes et qui devient l'interlocuteur en cas de panne ou de problème d'accès.

Cloud 9 utilise un langage plus fort lorsqu'il décrit les contrôles autour de cet environnement. La page fait référence au chiffrement, au contrôle d'accès, aux environnements virtuels isolés, à la vérification des sauvegardes et à plusieurs centres de données sécurisés. Ces déclarations définissent la position de sécurité et de résilience visée du produit. Elles sont importantes en tant que représentations de ce que Cloud 9 commercialise, et elles aident à identifier les preuves dont un client aurait besoin dans un audit sérieux.

Elles ne sont pas une preuve indépendante de l'implémentation. Les sources publiques examinées ici n'identifient pas les installations, n'indiquent pas si Cloud 9 possède ou loue des locaux, ne nomment aucune plateforme d'infrastructure, ne quantifient ni la puissance de calcul ni le stockage disponible, ne publient pas les niveaux d'utilisation, ne divulguent pas les chemins de circuits physiques et n'offrent aucune disponibilité mesurée.

La phrase « plusieurs centres de données sécurisés » ne révèle pas comment ces sites sont séparés, quelles charges de travail sont répliquées, si le basculement est automatique, quelles dépendances sont partagées, ou si chaque client reçoit la même architecture.

La même réserve s'applique à la surveillance. « Surveillance 24h/7j » peut décrire un outil qui vérifie en continu les systèmes, une fonction opérationnelle dotée de personnel, un service d'alerte avec escalade, ou une combinaison de ceux-ci. La page de service ne précise pas quelle interprétation s'applique, comment les alertes sont priorisées, à quelle vitesse les ingénieurs répondent, ou ce qui se passe en dehors de la fenêtre de personnel actif spécifiée pour le service d'assistance. La surveillance est une activité; la fiabilité du service dépend de la qualité de la détection, de la prise de décision et de la résolution.

De même, l'empreinte de routage publique ne clarifie pas ces questions. AS3700 et ses préfixes pourraient soutenir une partie des services de Cloud 9, des fonctions de gestion, de la connectivité client ou des opérations historiques. Les enregistrements disponibles n'associent aucune charge de travail cloud spécifique à un préfixe particulier. Ils ne montrent pas où se trouvent les serveurs, si le trafic hébergé utilise AS3700, ou si un autre fournisseur fournit l'infrastructure pour le service. Traiter le système autonome comme une carte directe de la plateforme hébergée irait au-delà des preuves.

La sauvegarde et la reprise sont des affirmations sur les résultats

La page de Cloud 9 sur la sauvegarde et la reprise après sinistre étend l'offre d'hébergement dans un domaine où les détails d'implémentation sont particulièrement importants. L'entreprise déclare offrir une sauvegarde automatisée, une redondance hors site et dans le cloud, des processus de restauration testés, des objectifs de temps de récupération, une architecture résiliente aux rançongiciels, une surveillance, des alertes et une restauration rapide. Ensemble, ces formulations décrivent un service destiné non seulement à conserver des copies de données, mais à restaurer les opérations commerciales après un incident.

La page publique établit que la sauvegarde et la reprise font partie de l'offre commerciale actuelle de Cloud 9. Elle définit également les dimensions selon lesquelles l'entreprise souhaite que son offre soit mesurée: fonctionnement automatisé, séparation, récupérabilité, vitesse et résilience contre les attaques destructrices. Mais chaque dimension nécessite des preuves au-delà de l'affirmation elle-même.

Un job automatisé peut s'exécuter sans créer de copie utilisable. Une copie hors site peut néanmoins partager un fournisseur, un compte, un plan de contrôle ou une vulnérabilité administrative avec l'environnement principal. Un objectif de récupération peut être un objectif et non un résultat démontré. Un processus testé peut aller d'une restauration de fichier étroite à un exercice applicatif complet. « Rapide » n'a pas de signification analytique sans charge de travail définie, condition de départ et temps écoulé. Le matériel public disponible ne divulgue pas ces détails et ne fournit pas de résultats de tests de restauration client.

La même prudence s'applique à la résilience aux rançongiciels. Le terme indique la menace que l'architecture est censée supporter, mais la page publique ne spécifie aucun paramètre d'immuabilité, de séparation administrative, de conception de rétention, d'isolement de récupération ou de périmètre de test. Il serait donc erroné de transformer une architecture commercialisée en une conclusion selon laquelle Cloud 9 a repoussé une attaque spécifique ou peut restaurer chaque client dans un délai donné.

Les preuves de routage contribuent très peu à cette question de résultat. Un préfixe IPv4 ou IPv6 visible peut montrer qu'un réseau est annoncé. Il ne peut pas montrer qu'une sauvegarde a été effectuée, que les données sont cohérentes, que les identifiants ont survécu à un incident ou qu'une application peut être redémarrée. De même, un bloc d'adresses enregistré n'identifie pas la séparation géographique des copies de sauvegarde. L'existence d'AS3700 ne peut valider un objectif de temps de récupération.

Pour un acheteur, la réponse judicieuse n'est pas de rejeter l'offre, mais de transformer chaque affirmation en une demande de portée. Quels systèmes sont couverts? Qu'est-ce qui constitue une vérification réussie? À quelle fréquence les restaurations sont-elles effectuées? Quelle est la différence entre la restauration de fichier, de serveur et d'application? Quels objectifs sont contractuels et lesquels sont des hypothèses de planification? Quelles dépendances sont partagées entre les environnements primaire et de récupération?

Les pages publiques ne répondent pas à ces questions, de sorte que la conclusion responsable est que le service est offert et que ses résultats restent non confirmés publiquement.

Cette distinction protège également Cloud 9 d'un autre type d'exagération. L'absence de résultats de test publiés ne prouve pas que les tests n'ont pas lieu ou que la reprise est faible. Cela signifie que les résultats ne peuvent être déterminés à partir des preuves publiques examinées ici. L'évaluation correcte n'est ni une approbation ni une condamnation. C'est une ligne claire entre une capacité de reprise commercialisée et une performance de reprise démontrée.

La gestion du réseau, des serveurs et de la sécurité étend la dépendance

Les pages de Cloud 9 sur la gestion réseau et le support serveur décrivent le niveau opérationnel quotidien autour de l'offre cloud. L'entreprise déclare que son service réseau comprend une surveillance continue, la gestion des correctifs et du firmware, l'optimisation, l'intégration réseau cloud et la connectivité pour la reprise après sinistre. La page de support serveur ajoute la surveillance de l'état des serveurs, la maintenance, le durcissement, la migration et l'intégration de la sauvegarde. Une page distincte sur les services de cybersécurité intègre la sécurité dans le même catalogue plus large.

Ces services sont importants car ils élargissent l'offre de Cloud 9 au-delà de l'hébergement loué. L'entreprise propose de participer aux décisions et à la maintenance dans tout l'environnement client. La configuration réseau concerne l'accès aux systèmes hébergés. La maintenance des serveurs concerne les performances et l'exposition. L'intégration de la sauvegarde concerne la récupérabilité des données. Les contrôles de sécurité concernent qui peut atteindre l'environnement et comment les incidents sont contenus. Le produit est une relation opérationnelle, pas un bloc de capacité autonome.

Cette relation crée une concentration au niveau de la gestion, même si l'infrastructure est distribuée. Lorsqu'un fournisseur coordonne les changements réseau, les mises à jour serveur, la migration cloud, la sécurité et la reprise, les clients gagnent un interlocuteur opérationnel unique. Ils peuvent également devenir dépendants de sa documentation, de ses contrôles d'accès, de ses pratiques d'escalade et de sa coordination des fournisseurs. C'est une implication analytique de l'étendue des services, pas une preuve que Cloud 9 a mal géré l'une de ces fonctions.

Les pages publiques ne divulguent pas les outils sous-jacents, le personnel ou la répartition des tâches. Elles ne disent pas si la surveillance est entièrement effectuée par Cloud 9, partagée avec un autre opérateur ou basée sur des plateformes tierces. Elles ne quantifient aucun calendrier de correctifs, ne définissent aucune politique de firmware, ne publient aucun standard de durcissement et ne montrent aucun résultat d'optimisation réseau. Elles ne précisent pas quelles parties de Microsoft 365, de l'infrastructure cloud ou de l'équipement client relèvent d'un accord de service particulier.

Le large catalogue soulève donc une question centrale de due diligence: où commencent et où finissent les responsabilités de Cloud 9? Les catégories marketing peuvent se chevaucher. Une panne réseau peut impliquer du matériel client, une ligne de transporteur, une application hébergée et un pare-feu géré. Un événement de reprise peut nécessiter une coordination entre des fournisseurs de logiciels, d'identité, de sauvegarde et d'infrastructure. Sans une matrice de responsabilité spécifique au service, la liste des capacités ne peut révéler qui est responsable de chaque dépendance.

AS3700 fournit la preuve que Cloud 9 a une identité de routage publique, ce qui peut être pertinent pour la crédibilité de la gestion réseau et l'historique. Cela ne prouve pas que chaque client géré utilise ce réseau, que Cloud 9 contrôle chaque circuit qu'il gère, ou que les routes de l'entreprise offrent une redondance pour la plateforme cloud. La large offre de services et les faits de routage étroits peuvent coexister sans être techniquement coextensifs.

AS3700 est l'ancre publique la plus solide

L'identifiant vérifiable indépendamment le plus solide dans l'empreinte publique de Cloud 9 est AS3700. L'enregistrement RDAP d'ARIN donne au système autonome le nom CLOUD9 et liste Cloud 9 Internet, Inc. comme registrant. L'enregistrement montre les numéros de début et de fin du système autonome comme 3700, une date d'enregistrement du 2 juillet 1994 et une date de dernière modification du 2 mars 2012. Il relie le registrant à l'adresse de White Plains.

Le contact technique intégré est C9-NIC-ARIN, identifié comme Hostmaster. L'enregistrement fournit[email protected]et +1-914-696-4000. Le chevauchement de ce numéro avec les informations de support actuelles de Cloud 9 ne prouve pas la structure de ses opérations réseau, mais relie l'ancienne surface d'enregistrement à la surface de contact publique actuelle de l'entreprise.

Un numéro de système autonome est une preuve précieuse car c'est un identifiant durable utilisé dans le routage interdomaine. Dans ce cas, l'enregistrement prouve que Cloud 9 a une identité réseau nommée et n'utilise pas simplement « Internet » comme partie d'un nom d'entreprise. La vue AS de RIPEstat ajoute qu'AS3700 a été annoncé pendant la période d'observation et identifie le titulaire comme « CLOUD9 - Cloud 9 Internet, Inc. »

Néanmoins, les preuves nécessitent une interprétation disciplinée. L'enregistrement prouve l'allocation et les informations du registrant dans l'entrée ARIN. Le statut d'annonce prouve que le système autonome était visible comme annoncé dans l'observation de RIPEstat. Aucun des deux ne dit combien de trafic AS3700 porte, combien de routeurs originent ses préfixes, où se trouvent ces routeurs, combien de chemins indépendants existent, ou quels services en dépendent. L'ancienneté de l'enregistrement ne mesure pas les investissements actuels.

La date de dernière modification ne doit pas non plus être lue comme la date du dernier changement opérationnel. Elle décrit l'entrée de registre, pas chaque modification d'équipement, de route, de contrat ou de personnel. Une entrée inchangée depuis 2012 peut coexister avec des changements techniques significatifs ou très peu. Le champ dit seulement aux lecteurs quand les données d'enregistrement RDAP ont été modifiées pour la dernière fois selon l'entrée.

AS3700 est donc une ancre solide, pas une carte complète. Il soutient l'affirmation d'une identité réseau publique durable et d'une visibilité de routage actuelle. Il aide à distinguer Cloud 9 d'une marque de service sans surface de système autonome directement enregistrée dans les preuves. Mais il n'offre pas de pont automatique entre l'identité et la portée, ni de certificat public que les solutions hébergées dans le cloud utilisent une architecture spécifique. Sa force probante réside dans sa précision sur un point étroit.

Les ressources d'adresses montrent continuité et sélectivité

Les entrées réseau d'ARIN ajoutent de la substance autour d'AS3700. Elles montrent des allocations IPv4 directes à Cloud 9 Internet, Inc., couvrant 168.100.0.0 à 168.100.5.255 et 168.100.175.0 à 168.100.176.255. Les deux entrées utilisent le nom CLOUD9-NETB, portent des dates d'enregistrement du 7 mars 1994 et montrent des dates de dernière modification du 14 décembre 2021. ARIN enregistre également une allocation IPv6 directe, 2604:8d00::/32, enregistrée le 27 avril 2011 et modifiée pour la dernière fois le 2 mars 2012.

Ces enregistrements établissent des plages de ressources enregistrées, mais l'observation du routage est plus sélective. Les données des préfixes annoncés de RIPEstat pour AS3700, vérifiées le 21 juillet 2026, listaient cinq préfixes avec des périodes du 7 au 21 juillet: 168.100.0.0/22, 168.100.4.0/24, 168.100.175.0/24, 168.100.176.0/24 et 2604:8d00::/32. Les points de terminaison de vue des préfixes séparés de RIPEstat associent les mêmes préfixes à l'ASN 3700 et au titulaire Cloud 9.

Cette combinaison soutient deux affirmations connexes mais distinctes. ARIN identifie les ressources enregistrées sur Cloud 9. RIPEstat observe des annonces de routes spécifiques attribuées à AS3700 dans une fenêtre temporelle définie. La première est une entrée administrative; la seconde est une vue de l'activité de routage. Ensemble, elles rendent l'empreinte réseau publique plus concrète que chacune ne le pourrait seule.

Ils montrent aussi pourquoi les sommes d'adresses sont un mauvais indicateur de la capacité cloud. Une allocation IPv4 renseigne sur les ressources numériques, pas sur les processeurs, la mémoire, le stockage, la virtualisation, les installations ou la couverture de support. Un /32 IPv6 offre une plage d'adresses extrêmement large, mais la taille de cette plage ne peut être traduite en machines déployées ou en demande client. L'espace d'adressage peut être utilisé de manière clairsemée, alloué à différentes fins, routé de manière agrégée, ou conservé dans le cadre d'une conception réseau durable.

Les enregistrements examinés ici ne rendent pas compte de l'utilisation.

Les annonces listées ne prouvent pas non plus que chaque adresse transporte du trafic de production client. Un préfixe peut supporter de l'infrastructure, des services, des clients ou d'autres fonctions, et les données disponibles ne classifient pas le contenu. De plus, l'observation de cinq préfixes ne révèle aucun volume de trafic. Un petit nombre de préfixes peut porter un trafic important; de nombreux préfixes peuvent en porter peu. Le nombre de préfixes est une description de la granularité du routage, pas une mesure de débit.

Il est également important de ne pas déduire une topologie physique des limites de routes. La présence d'IPv4 et IPv6 indique que Cloud 9 a des ressources visibles dans les deux familles de protocoles dans les données observées. Cela ne dit pas que chaque service hébergé est dual-stack, que le même équipement origine les deux, ou que les chemins sont physiquement diversifiés. Les objets de route ne contiennent pas d'inventaire des installations ni de correspondance avec des produits individuels.

Ce qui peut être dit est néanmoins significatif. Le nom Cloud 9 est associé à des enregistrements de ressources s'étendant sur plus de trois décennies. AS3700 était visible comme annoncé, et RIPEstat listait des préfixes concrets lors de l'examen en juillet 2026. C'est une preuve d'une surface de numéros Internet durable et actuellement observable. Cela renforce le cas que l'héritage ISP de Cloud 9 a une trace publique vivante. Cela reste loin de prouver la capacité derrière l'offre de cloud géré.

Enregistrement, annonce et service sont trois couches différentes

Les rapports d'infrastructure deviennent souvent peu fiables lorsque les preuves administratives, de routage et de produit sont traitées comme interchangeables. Les enregistrements de Cloud 9 permettent de séparer proprement les trois couches.

La couche d'enregistrement répond à qui est nommé dans une entrée de ressource publique. ARIN attribue AS3700 et certaines plages d'adresses à Cloud 9 Internet, Inc. Elle fournit des dates, des handles, des détails de contact et des limites de ressources. C'est une preuve solide de l'identité enregistrée. Ce n'est pas un test en direct du réseau et ne montre pas si chaque adresse enregistrée est actuellement routée.

La couche d'annonce répond à ce que RIPEstat a observé dans le système de routage pendant la période examinée. AS3700 a été affiché comme annoncé, et cinq préfixes ont été listés. C'est une preuve plus forte de la visibilité réseau actuelle que la seule propriété du registre. Mais la visibilité de routage reste une observation à travers l'ensemble de données de RIPEstat. Elle ne révèle pas le chemin physique complet, l'accord contractuel, le niveau de trafic ou le service lié à une route.

La couche de service répond à ce que Cloud 9 présente aux clients. L'entreprise commercialise des systèmes hébergés, la migration, la surveillance, la gestion réseau et serveur, la sécurité, la sauvegarde et la reprise. Ces pages définissent l'offre et ses résultats escomptés. Elles ne confirment pas indépendamment la plateforme ou les résultats.

Relier les couches nécessite des preuves supplémentaires. Pour montrer qu'une application hébergée spécifique fonctionne sur l'infrastructure contrôlée par Cloud 9 et annoncée via AS3700, un lecteur aurait besoin d'une correspondance entre service, infrastructure et route. Pour montrer la résilience, cette correspondance devrait inclure des domaines de défaillance indépendants et des basculements testés. Pour montrer la responsabilité commerciale, elle devrait identifier quelle partie fournit chaque composant et quelles obligations s'appliquent en cas de défaillance. Aucun de ces liens n'apparaît dans le matériel public disponible.

Cela ne rend pas les trois couches déconnectées. La même identité d'entreprise, l'adresse et la surface téléphonique offrent des points de continuité. L'histoire de l'entreprise offre un récit allant d'ISP à MSP. Le catalogue actuel reste axé sur les systèmes connectés. Il est raisonnable de considérer AS3700 comme faisant partie de l'histoire infrastructurelle institutionnelle de Cloud 9 et de sa présence réseau publique actuelle. Il n'est pas raisonnable de le traiter comme une preuve pour chaque affirmation produit.

Le modèle en couches évite également une erreur négative courante. Si un fait ne peut être établi sur une couche, cela ne signifie pas que le contraire est vrai. L'absence de détails publics sur les installations ne prouve pas que Cloud 9 ne possède pas d'installations. L'absence de résultats de performance ne prouve pas une mauvaise performance. L'absence de parties contractantes divulguées ne prouve pas qu'il n'y en a pas. Cela signifie que ces questions restent non résolues dans les preuves publiques. La précision implique la retenue dans les deux directions.

Deux voisins observés, aucun rôle commercial divulgué

Les données asn-neighbours de RIPEstat pour AS3700, vérifiées le 20 juillet 2026, listent AS17378 et AS46405. Des entrées séparées de vue AS de RIPEstat identifient le titulaire d'AS17378 comme TierPoint, LLC et le titulaire d'AS46405 comme DANY-NY/NJ HIDTA. C'est une observation étroite de voisinage de routage dans l'ensemble de données.

Le mot « voisin » peut inviter une histoire commerciale que les données ne contiennent pas. Il est tentant d'étiqueter un réseau plus grand ou reconnaissable comme fournisseur en amont, client, pair, revendeur, site d'hébergement ou chemin de sauvegarde. Aucune de ces étiquettes ne découle automatiquement de la liste de voisins. Le résultat de RIPEstat n'indique pas qui paie qui, qui fournit le transit, où l'interconnexion a lieu, pourquoi le voisinage existe ou si la relation est durable.

Cette limitation est importante car les pages de services de Cloud 9 font des affirmations sur la surveillance, l'intégration cloud, la redondance et les systèmes hébergés. Un ASN voisin observé pourrait sembler expliquer l'une de ces fonctions, mais une telle conclusion serait spéculative. Les données de voisinage n'attribuent ni AS17378 ni AS46405 à l'offre d'hébergement cloud, à l'architecture de sauvegarde ou à la connectivité de reprise après sinistre de Cloud 9. Elles ne prouvent aucun rôle fournisseur/client ni mécanique contractuelle commerciale.

Les deux observations ajoutent néanmoins du contexte. Elles montrent que RIPEstat n'a pas présenté AS3700 isolé lors de l'examen. Elles identifient les titulaires enregistrés aux autres extrémités des voisinages de routage observés. Pour un processus de due diligence technique, ces noms pourraient devenir des points de départ pour des questions sur la connectivité et la responsabilité. Ce ne sont pas des réponses.

Une description soigneuse est donc simple: RIPEstat a observé AS17378 et AS46405 comme voisins d'AS3700 dans son ensemble de données du 20 juillet, et ses points de terminaison de vue en nomment les titulaires. Tout ce qui va au-delà nécessite une autre classe de preuves, telles que des divulgations de politiques de routage, des contrats, des lettres d'autorisation, des enregistrements d'installations ou une confirmation technique directe. Rien de tout cela n'est présent ici.

Ce qu'AS3700 ne prouve pas

La présence d'un système autonome enregistré et annoncé est un fait positif, mais il est facile de charger ce fait de significations qu'il ne peut porter. AS3700 ne prouve pas que Cloud 9 possède un centre de données. Il n'établit pas combien d'installations sont impliquées dans le service d'hébergement actuel, où elles se trouvent, si Cloud 9 y possède de l'équipement, ou si l'entreprise achète de la capacité auprès d'un autre opérateur.

Il ne prouve aucune capacité cloud utilisable. Les annonces de routes ne fournissent aucune information sur le nombre de processeurs, la mémoire, le stockage, la densité de virtualisation, les réserves disponibles ou l'allocation client. Elles ne montrent pas si un service peut supporter une augmentation soudaine de charge de travail. Elles n'identifient pas l'hyperviseur ou la pile cloud exacte. Elles ne rapportent pas si la capacité est dédiée, partagée ou revendue.

AS3700 ne prouve pas non plus la redondance. Plusieurs préfixes ne sont pas la même chose que plusieurs chemins indépendants. La visibilité IPv4 et IPv6 n'est pas une preuve d'installations séparées. Deux voisins observés n'établissent pas de basculement, car leurs rôles commerciaux, chemins physiques et dépendances partagées sont inconnus. Même si le trafic peut suivre plus d'un chemin de plan de contrôle, les données publiques ne montrent pas si l'électricité, la fibre, l'équipement, les logiciels, le personnel ou les installations partagent un point de défaillance commun.

Les enregistrements ne prouvent aucune qualité de service. Il n'y a pas de pourcentage de disponibilité mesuré, d'historique d'incidents, de distribution de latence, d'enregistrement de perte de paquets, de performance de réponse du support ou de résultat d'application de SLA dans les preuves publiques examinées ici. Les horaires de service d'assistance spécifiés établissent une fenêtre de support publiée, pas la qualité des cas traités à l'intérieur. L'affirmation de surveillance 24h/7j n'établit pas de temps de réponse ou de qualité de résolution.

Ils ne prouvent aucun résultat de sauvegarde. Une allocation d'adresse ne peut révéler si les tâches de sauvegarde réussissent, si les copies sont immuables, si la restauration est testée régulièrement, ou si les objectifs de récupération déclarés d'un client ont été atteints. Une route qui reste visible pendant un incident ne montrerait pas qu'une application ou ses données étaient utilisables.

Ils ne prouvent aucune envergure. Les enregistrements ne fournissent aucune information sur le nombre de clients, le chiffre d'affaires, le nombre d'employés, le volume de trafic, le nombre de points de terminaison gérés, les charges de travail hébergées ou le stockage géré. Un long historique opérationnel peut démontrer la persistance de l'identité sans quantifier l'activité actuelle. Le catalogue de services peut démontrer la largeur de l'offre sans montrer l'adoption.

Enfin, les données de routage ne prouvent aucune mécanique contractuelle. TierPoint, LLC et DANY-NY/NJ HIDTA sont des noms associés par RIPEstat à des ASN voisins observés. Les données n'identifient aucun d'eux comme fournisseur, client, pair, hôte d'installation ou partenaire commercial de Cloud 9. Il serait également erroné de conclure qu'ils n'ont pas un tel rôle. Le rôle n'est simplement pas établi.

Ces exclusions n'affaiblissent pas la conclusion valide. Elles la définissent. Cloud 9 a une identité réseau enregistrée durable, des ressources annoncées visibles et une offre de services actuelle. Les affirmations plus ambitieuses – capacité, résilience, performance et topologie commerciale – nécessitent des preuves conçues pour répondre à ces questions. AS3700 est précieux car il prouve moins, mais plus solidement, qu'une lecture large ne le suggérerait.

L'économie réside dans la carte des dépendances non divulguées

L'offre de Cloud 9 est conceptuellement attrayante sur le plan économique car elle invite les clients à échanger les charges directes de propriété et de maintenance contre un service géré. La page cloud encadre explicitement l'offre comme un moyen de s'éloigner des serveurs locaux et d'externaliser la maintenance, les mises à jour et les sauvegardes. Les pages réseau, serveur et reprise étendent cette délégation à davantage de la pile opérationnelle.

La question économique n'est pas seulement le prix de l'hébergement. Il s'agit de savoir quels risques et tâches passent à Cloud 9, lesquels restent chez le client, et lesquels sont transmis à des fournisseurs d'infrastructure ou de logiciels non nommés. Si Cloud 9 fournit expertise et coordination tout en achetant la capacité sous-jacente ailleurs, sa valeur pourrait résider davantage dans l'intégration et le support que dans la possession d'installations. S'il contrôle davantage de la pile, le profil de capital et d'exploitation pourrait être différent. Le matériel public ne tranche pas entre ces possibilités.

Cette ambiguïté affecte l'analyse de résilience. Un client peut vivre un service contractuel tout en dépendant de plusieurs systèmes techniques. Cloud 9 peut être l'interface responsable même si une autre partie exploite un composant. Inversement, un client peut conserver la responsabilité des applications, des identifiants, de la connectivité locale ou de l'équipement tout en achetant des fonctions gérées sélectionnées. Les étiquettes larges sur les pages de services ne révèlent pas ces limites.

Le même problème concerne les coûts de changement. Passer d'un serveur local peut réduire la maintenance locale, comme le suggère l'offre de Cloud 9, mais cela peut aussi rendre plus importants la documentation, l'export de données, la propriété de configuration et les procédures de reprise. Ce n'est pas une affirmation sur les contrats de Cloud 9. C'est l'implication de due diligence de toute offre combinant hébergement et gestion. Les preuves publiques ne divulguent pas les conditions de portabilité, les procédures de retour de données ou le support de sortie.

AS3700 ajoute à cette image un actif potentiellement utile: une surface de ressources réseau durable et directement identifiable. Une telle surface peut donner aux clients techniques quelque chose de concret à surveiller et à discuter. Mais son importance économique dépend de la façon dont elle est utilisée. Si le service hébergé repose matériellement sur AS3700 et les préfixes enregistrés de Cloud 9, l'identité réseau pourrait faire partie de l'architecture de livraison. Si le service est principalement fourni via d'autres plateformes, AS3700 pourrait jouer un rôle différent ou plus étroit.

Les sources publiques ne cartographient pas cette dépendance.

L'économie réelle réside donc cachée dans une carte de responsabilités et de dépendances que les pages publiques ne fournissent pas. Qui possède ou loue la puissance de calcul? Qui contrôle les changements de routage? Qui détient les identifiants administratifs? Qui effectue les tests de reprise? Qui supporte les coûts de capacité supplémentaire? Qui doit remédier aux objectifs manqués? Ces questions déterminent la substance d'un service cloud géré plus que l'existence d'un ASN.

Les matériels publics de Cloud 9 suffisent à identifier l'offre et à démontrer une longue continuité réseau historique. Ils ne suffisent pas à modéliser l'économie unitaire, le risque de concentration ou les marges de service. Aucune donnée sur les revenus, les clients, la capacité, l'utilisation ou les coûts des fournisseurs n'est disponible. Toute conclusion financière serait donc spéculative.

Une échelle de preuve pratique pour clients et partenaires contractuels

Le dossier public peut néanmoins soutenir une séquence rigoureuse de due diligence. La première étape consiste à préserver ce qui est déjà connu. Cloud 9 Internet, Inc. est le registrant ARIN désigné d'AS3700. CLOUD9 est le nom ASN enregistré. ARIN enregistre des allocations IPv4 et IPv6 directes spécifiques. RIPEstat a montré AS3700 comme annoncé et a listé cinq préfixes dans la fenêtre d'observation de juillet 2026. Cloud 9 publie une adresse à White Plains, des numéros de support et un large catalogue de services gérés.

La deuxième étape consiste à demander à Cloud 9 de cartographier le service commercialisé sur l'infrastructure visible et invisible. Quelles parties de la solution hébergée dans le cloud utilisent des ressources contrôlées par Cloud 9? Les charges de travail des clients sont-elles adressées à partir des préfixes listés? Quelles installations ou plateformes fournissent la puissance de calcul et le stockage? Quels éléments sont possédés, loués ou fournis via un autre service? Les réponses relieraient le langage produit à l'architecture, sans supposer qu'AS3700 supporte l'ensemble du service.

La troisième étape consiste à définir les domaines de défaillance. Cloud 9 déclare utiliser plusieurs centres de données sécurisés et offrir une redondance hors site et cloud. Un audit significatif identifierait les sites ou régions de plateforme pertinents, les dépendances électriques et réseau, la méthode de réplication, les dépendances du plan de contrôle et les circonstances déclenchant un basculement. La question clé n'est pas le nombre de sites en tant que chiffre marketing, mais si les composants nécessaires au service client peuvent tomber en panne indépendamment.

La quatrième étape consiste à convertir les affirmations de surveillance et de support en définitions opérationnelles. Qu'est-ce qui est surveillé en continu? Quelles alertes reçoivent un examen humain? Comment les horaires de service d'assistance publiés se rapportent-ils aux événements en dehors de cette fenêtre? Quels objectifs de réponse et de résolution s'appliquent? Quels canaux sont contractuellement convenus? Les performances historiques, si partagées, devraient être liées à la même portée de service et non présentées comme une moyenne d'entreprise indifférenciée.

La cinquième étape consiste à examiner la reprise en tant que workflow démontré. Cloud 9 commercialise la sauvegarde automatisée, la vérification, la restauration testée et les objectifs de temps de récupération. Un client devrait identifier les systèmes protégés, la fréquence de sauvegarde, la rétention, la séparation administrative, l'étendue des tests de restauration, les données de test, les exceptions et les résultats de restauration mesurés. L'objectif est de déterminer si le résultat promis a été exécuté dans des conditions pertinentes pour les applications de ce client.

La sixième étape consiste à rendre la responsabilité explicite. La gestion réseau, le support serveur, la cybersécurité, l'hébergement et la reprise se chevauchent. Un plan de service devrait distinguer les tâches de Cloud 9 des tâches client et des tâches tierces. Il devrait identifier qui approuve les changements, qui détient les identifiants, qui communique les incidents et qui coordonne un fournisseur. C'est là que le confort de service large devient une pratique opérationnelle exécutoire.

La septième étape consiste à clarifier la connectivité sans surinterpréter le graphe de routage. RIPEstat a observé AS17378 et AS46405 comme voisins d'AS3700, mais leurs rôles ne sont pas établis. Cloud 9 pourrait expliquer directement les accords de transit, de peering, d'accès et de basculement pertinents, y compris les relations soutenant le service acheté. Une confirmation documentaire ou technique aurait plus de poids qu'une étiquette dérivée basée sur le voisinage.

La huitième étape consiste à tester la sortie et la portabilité. Un service géré peut être fiable et néanmoins créer une dépendance opérationnelle. Les clients devraient comprendre l'export de données, le transfert de configuration, le transfert d'identifiants, le support pendant la migration et le traitement des sauvegardes à la résiliation. Aucune de ces conditions ne peut être déduite d'AS3700 ou des pages de services publiques.

Cette échelle ne présuppose aucune faiblesse. Elle transforme l'ambiguïté publique en questions répondables. Les ressources enregistrées de Cloud 9 rendent la couche d'identité inhabituellement claire. Ses pages actuelles rendent l'offre assez claire pour identifier les affirmations opérationnelles pertinentes. Les prochaines preuves devraient se concentrer sur les liens entre elles: architecture, responsabilité, tests, performance et recours contractuels.

La visibilité n'est pas la capacité, mais elle n'est pas rien

AS3700 rend Cloud 9 visible d'une manière que de nombreuses descriptions de service ne le sont pas. Il donne à l'entreprise un identifiant stable, un titulaire enregistré et un ensemble de ressources d'adresses associées. RIPEstat ajoute la preuve que le système autonome et cinq préfixes listés étaient présents dans les données de routage observées en juillet 2026. Ce sont de véritables faits d'infrastructure.

Les propres pages de Cloud 9 établissent un autre fait réel: l'entreprise se présente actuellement comme un fournisseur d'IT géré, d'hébergement cloud, de support réseau et serveur, de sécurité, de sauvegarde et de reprise à White Plains et Westchester. Son histoire décrit une transition d'un FAI local fondé en 1993 à un fournisseur de services gérés d'ici 2010. Les premières données ARIN donnent à cette histoire d'origine un contexte réseau tangible, même si elles ne confirment pas indépendamment chaque affirmation historique.

La conclusion disciplinée est plus étroite que la promesse marketing et plus forte que le scepticisme fondé sur le silence. Cloud 9 a une surface de routage et de ressources publique durable. Il offre des services dont la valeur dépend de la capacité, de la surveillance, de la redondance, de la reprise et du support. Les preuves disponibles ne quantifient pas ces capacités et ne montrent ni leur architecture, ni leurs performances, ni leur chaîne d'approvisionnement.

Cette lacune est l'endroit où la due diligence devrait se concentrer. La possession d'installations, la capacité d'hébergement utilisable, la diversité physique, le nombre de clients, les résultats SLA, les tests de sauvegarde et les rôles commerciaux des partenaires contractuels ne peuvent pas être lus à partir d'un ASN. Ils nécessitent des documents spécifiques au service, des cartographies techniques, des résultats mesurés et des définitions contractuelles. Jusqu'à ce qu'ils soient disponibles, ils restent des questions ouvertes.

La chose la plus utile qu'AS3700 fait n'est pas de prouver l'ensemble de l'offre cloud de Cloud 9. Il crée un point de départ solide. Il donne un réseau nommé, enregistré sur l'entreprise, avec des ressources détenues de longue date et une visibilité publique actuelle. De là, la tâche consiste à demander quelle part du service géré repose sur ce réseau, ce qui repose ailleurs, et qui est responsable si une couche tombe en panne.

Sources