PT. INDONESIA SUPER CORRIDOR - centres de données doit prouver que sa capacité de centre de données résiste aux contraintes d’alimentation et de réseau

Résumé

• PT. INDONESIA SUPER CORRIDOR - centres de données a des signaux publics inhabituellement concrets pour ce lot: lesite ISCcommercialise un centre de données Tier IV de 550 baies ISC MPR à Mampang Prapatan, lapage À propos d’ISCindique que l’entreprise a construit une capacité réseau et de centre de données dans Cyber 1, et lapage client de l’Uptime Instituterépertorie des récompenses délivrées pour ISC centres de données DPR, ISC centres de données Cyber-1 Building CBR Level 9 et centres de données ISC MPR.
• L’empreinte de routage est réelle mais étroite.APNIC RDAPnomme AS142379 comme ISC-DC-AS-ID pour PT. INDONESIA SUPER CORRIDOR - centres de données, etRIPEstata montré six annonces IPv4 /24 actuelles avec une visibilité IPv4 RIS complète le 12 juillet 2026, mais aucune visibilité IPv6 actuelle et un seul voisin AS observé.
• La principale lacune de diligence n’est pas de savoir si une activité de centre de données de marque ISC existe. Il s’agit de savoir si les offres de baies, de cloud et de reprise après sinistre annoncées disposent de suffisamment d’alimentations utilitaires divulguées, d’autonomie de générateur, de redondance de refroidissement, de diversité de point de rencontre, de tests de basculement client et de procédures de sortie pour soutenir des charges de production lorsque les conditions d’alimentation, de réseau ou d’installation deviennent inconfortables.

ISC est un cas plus solide qu’un simple espace réservé dans un annuaire

Certains profils d’infrastructure commencent par une entrée de registre mince et ne vont jamais beaucoup plus loin. PT. INDONESIA SUPER CORRIDOR - centres de données est différent. L’entreprise est visible dans l’annuaire BTW, sur ses propres pages de services publics, dans la base de données des récompenses de l’Uptime Institute, dans les enregistrements PeeringDB autour de son échange et de son organisation, et dans les observations de routage en direct. Cela ne rend pas le dossier d’exploitation complet, mais cela change la question. Il ne s’agit pas de rechercher un bâtiment qui pourrait ne pas exister. Il s’agit de tester le niveau de confiance à accorder à une plateforme de centre de données commercialisée dont le dossier public est plus solide sur les installations et les emballages de produits que sur la récupération mesurée des clients.

Lapage d’accueil d’ISCs’ouvre sur une affirmation précise: « 550 baies disponibles dans le centre de données Tier IV ISC MPR (5 MW), Mampang Prapatan Raya, Jakarta, Indonésie. » Elle annonce également 100 Mbps IIX et 10 Mbps IX, une alimentation de 10 A, une allocation IP publique /29 et deux croisements UTP plus deux fibres pour l’offre de baie complète. La même page indique que l’installation est sécurisée, surveillée 24 h/24, protégée par détection de mouvement CCTV et accessible par contrôles par code PIN et carte. Il ne s’agit pas de vagues adjectifs cloud. Ce sont des affirmations sur les baies, l’alimentation, les croisements et l’accès physique.

Lapage À proposajoute le contexte plus ancien de Cyber 1. ISC déclare avoir commencé par construire son propre réseau et centre de données dans Cyber 1, à Jakarta, et décrit la proposition initiale comme un réseau géré fiable et multi-hébergé à l’intérieur d’une installation à haute disponibilité. Elle indique également que l’entreprise maintient des responsabilités PCI DSS lorsqu’elle stocke, traite ou transmet des données de titulaires de carte pour le compte de clients. La même page précise qu’ISC est située au centre de l’environnement d’échange Internet indonésien, revendique une résilience électrique à double source via un tableau de distribution séparé, et positionne ses services autour d’une qualité d’installation Tier III. Là encore, il s’agit d’un récit d’infrastructure physique: emplacement, distribution électrique, portée réseau et obligations de conformité.

L’Uptime Institute donne une forme indépendante à ce récit, sans toutefois constituer un verdict opérationnel complet. Sapage client pour PT Indonesia Super Corridorrépertorie trois sites avec des récompenses délivrées: ISC centres de données DPR à Denpasar, ISC centres de données Cyber-1 Building CBR Level 9 à Jakarta, et centres de données ISC MPR à Jakarta. Laliste des récompenses Uptime par pays pour l’Indonésieplace ISC aux côtés d’autres installations indonésiennes certifiées. Un acheteur doit néanmoins lire attentivement le type et la portée des récompenses, car ladocumentation de certification par niveau de l’Uptimedistingue les certifications de conception, d’installation construite et d’exploitation. Mais la base de données des récompenses soutient l’hypothèse qu’ISC dispose d’installations dignes d’évaluation, pas seulement d’une page de marque.

Cela rend l’avertissement sur le statut opérationnel de l’étude plus utile, et non moins. Lorsque les preuves publiques sont minces, la réponse est souvent « ne vous y fiez pas ». Lorsque les preuves publiques sont concrètes mais inégales, la meilleure réponse est « séparez ce qui existe de ce qui peut être survécu ». Le dossier public d’ISC soutient l’existence d’installations, la commercialisation de services, un rôle de réseau tourné vers les échanges et un routage IPv4 actif.

Il ne prouve pas publiquement chaque détail critique pour le client derrière la capacité commercialisée: baies effectivement occupées, puissance réservée, contrats de carburant des générateurs, chemins d’entrée de fibre diversifiés, tests de basculement du refroidissement, gestion historique des incidents, indépendance des sauvegardes, ou la différence entre la capacité cloud vendue par ISC et l’équipement client simplement hébergé dans l’espace ISC.

La carte des actifs compte trois installations nommées, pas une salle de données générique

La navigation propre d’ISC répartit l’histoire du centre de données entre les pages CBR, MPR et reprise après sinistre de Bali. Lapage Centre de données Tier III CBRcommercialise des offres de colocation par U, demi-baie et baie complète avec un chiffre de niveau de service de 99,982 %, une bande passante IIX et IX, une allocation IP, des droits d’accès, une surveillance du trafic, un support « smart hands » et des comptes DCIM. L’offre de baie complète sur cette page annonce 100 Mbps IIX, 10 Mbps IX, une plage IP publique /29, cinq accès utilisateur au centre de données, deux ports de croisement UTP et deux cœurs de fibre. C’est la partie héritée de l’histoire d’ISC, tournée vers Cyber 1.

Lapage Centre de données Tier IV MPRporte le discours de plus haute disponibilité. Elle annonce un chiffre de niveau de service de 99,995 % pour les offres de colocation par U, demi-baie et baie complète, reprend le langage IIX/IX et cache de contenu, et ajoute des offres cloud business et cloud entreprise. Ces offres cloud revendiquent une connectivité 1 Gbps IIX, OIXP et Equinix IX, jusqu’à 4 Go ou 32 Go de mémoire, jusqu’à 80 Go ou 640 Go de stockage, une IP publique, un OS Linux, un port 1 Gbps et jusqu’à 30 Mbps de bande passante internationale. Cet ensemble est important car il transforme ISC d’une société de colocation pure en un fournisseur d’infrastructure hébergée dont les clients peuvent dépendre du calcul, du réseau et du stockage opérés par ISC, et non seulement de leur propre équipement.

Lapage DRC Tier III Balidonne l’angle de la reprise. Elle présente l’installation de Denpasar comme un centre de reprise après sinistre, annonce des concepts de RPO et RTO, décrit des connexions gigabits vers de multiples échanges, une conception de fibre optique interconnectée, une alimentation résiliente provenant de deux sources de tension différentes et une capacité complète de générateur de secours, du FM200 et une détection de fumée au-dessus et en dessous du plancher surélevé, une vidéosurveillance 24 h/24, un accès par carte et empreinte digitale, et une climatisation de précision avec un système redondant. Ce sont des affirmations utiles car elles identifient les chemins de défaillance que l’entreprise sait que les clients interrogeront: panne de l’infrastructure principale, interruption de la fibre, coupure de courant, incendie et refroidissement.

Les annuaires d’installations tiers soutiennent l’existence de plusieurs sites ISC tout en introduisant un bruit de capacité que les acheteurs ne devraient pas ignorer. Lapage entreprise ISC de Baxteldécrit ISC comme exploitant deux centres de données dans une région et indique 6 MW, tandis que sapage ISC Towerdécrit le site MPR comme un centre de données Tier IV dans le sud de Jakarta avec 550 baies et revendique une véritable résilience double chemin 2N onduleur, des générateurs diesel et un support IPv4/IPv6.Datacenters.comrépertorie trois sites en Indonésie pour ISC, et sapage MPRfait état de 6 500 pieds carrés, 1 791 pieds carrés de plancher surélevé et 16,0 MW de puissance. Ces chiffres ne correspondent pas exactement au titre de 5 MW d’ISC ou au signal de marché de type LinkedIn qui décrit jusqu’à 8 MW de charge informatique. L’incohérence n’est pas une preuve de fausse déclaration; les annuaires tiers peuvent être en retard, estimer ou mélanger la puissance du bâtiment avec la charge informatique. C’est cependant exactement la raison pour laquelle les clients devraient demander un calendrier de capacité daté.

La conclusion utile est qu’ISC ne doit pas être réduite à un seul actif. CBR, MPR et Bali DRC apparaissent comme des parties distinctes du récit public. Le risque est que les pages publiques brouillent leurs frontières opérationnelles. Quelles baies sont dans Cyber 1? Quels packages cloud sont fournis depuis MPR? Quelles charges de travail peuvent effectivement basculer vers Bali? Les connexions d’échange annoncées sont-elles disponibles dans chaque salle ou uniquement via le réseau plus large d’ISC?

Si un client achète un service « Tier IV », chaque dépendance du chemin de service est-elle à l’intérieur de ce périmètre Tier IV, ou les portails de gestion, les systèmes de support, les circuits en amont, la facturation et les dépôts de sauvegarde se trouvent-ils dans d’autres salles? Ces questions définissent la résilience utilisable.

La capacité commercialisée a besoin d’un facteur de conversion

Le titre « 550 baies disponibles » est puissant car il donne une échelle tangible. Un acheteur peut imaginer des cages, des armoires, des croisements, des câbles d’alimentation et des déploiements clients. Mais la capacité d’un centre de données ne se limite jamais au nombre de baies. La capacité utile est la quantité d’espace, de puissance, de refroidissement et de raccordement réseau qui peut être vendue sans que la sursouscription se transforme en risque de panne.

La propre page MPR d’ISC aide à illustrer le problème de conversion. Une offre de baie complète comprend une source d’alimentation de 10 A, une allocation IP publique /29, une surveillance du trafic, un service smart hands, deux ports UTP et deux cœurs de fibre. C’est un ensemble pratique pour la colocation d’entreprise, mais cela ne signifie pas que chacune des 550 baies peut consommer 10 A en continu, que toutes les baies ont la même densité de puissance, ou qu’il existe suffisamment de refroidissement et de bande passante en amont pour que chaque baie fonctionne à des charges modernes d’IA ou de stockage dense.

Une baie d’entreprise traditionnelle à densité modeste est très différente d’une baie GPU ou de stockage haute performance. Les pages publiques d’ISC ne publient pas les limites de densité, le PUE, les températures de conception du refroidissement, les plafonds de consommation électrique, les politiques de disjoncteur ou la charge informatique vendable réelle par phase.

La même prudence s’applique aux packages cloud. Les pages MPR et CBR annoncent « Cloud Business » et « Cloud Enterprise » avec des niveaux de service de 99,9 %, des limites de mémoire et de stockage, une IP publique, un système d’exploitation Linux, un langage de port 1 Gbps et jusqu’à 30 Mbps de bande passante internationale. Ces termes semblent plus petits que les offres de baies et peuvent être destinés à des charges de travail professionnelles ordinaires plutôt qu’à du calcul à grande échelle.

Une VM cloud peut être provisionnée à partir d’une installation résiliente, mais la résilience du client dépend du clustering de l’hôte, de la réplication du stockage, de l’emplacement des sauvegardes, de la capacité de migration en direct, de l’exportation des snapshots, de la politique de maintenance et du chemin réseau. Les pages produits publiques montrent l’emballage des services; elles ne montrent pas l’architecture sous les machines virtuelles.

Dans le marché actuel des centres de données, l’alimentation est le facteur de conversion le plus important. Lerapport Énergie et IA de l’AIEprojette une croissance de la consommation électrique des centres de données beaucoup plus rapide que la demande globale d’électricité jusqu’en 2030. La pression est mondiale, mais elle se manifeste localement: chaque bâtiment a besoin d’un raccordement au réseau, d’un appareillage de commutation, d’une capacité onduleur, d’une capacité de refroidissement, d’une logistique de carburant et d’une autorisation d’extension. Le titre de 5 MW MPR d’ISC est significatif dans ce contexte, mais il n’est pas suffisant. Les clients doivent savoir si ce chiffre est la capacité du réseau public, la capacité du bâtiment, la charge informatique, la capacité de conception future ou la capacité vendable actuellement engagée après soustraction des clients existants, des marges de redondance et de la marge de maintenance.

ISC pourrait lever une grande partie de l’ambiguïté par une divulgation ennuyeuse: capacité totale de l’alimentation électrique, charge informatique engagée, charge vendable disponible, densité moyenne et maximale des baies, topologie des onduleurs, autonomie des générateurs, contrats de réapprovisionnement en carburant, conception de la dérivation de maintenance, redondance du refroidissement et hypothèses derrière le chiffre de 99,995 % du MPR. Les pages publiques annoncent une alimentation à double source et des générateurs de secours à plusieurs endroits. C’est un point de départ.

Ce n’est pas la même chose qu’un modèle de capacité prêt pour le client qui montre ce qui se passe lorsqu’une source d’alimentation, un module onduleur, une unité de refroidissement ou un chemin d’approvisionnement en carburant est indisponible.

C’est pourquoi la thèse d’exploitation devrait être améliorée du « faible empreinte publique » uniquement pour l’existence, et non pour la résilience. ISC a une empreinte visible. La dégradation se situe au point où la capacité commercialisée doit devenir une capacité auditée. Si un acheteur place un équipement de colocation ordinaire avec une faible consommation électrique, les preuves publiques peuvent être suffisantes pour justifier une visite du site et une demande de proposition.

Si l’acheteur place des systèmes financiers sensibles à la latence, des charges de travail du secteur public, une infrastructure de reprise après sinistre ou du calcul haute densité, les preuves publiques ne sont pas suffisantes. Ces clients ont besoin d’une lettre de capacité, de documents de topologie, de preuves de basculement et d’un langage contractuel qui lie les niveaux de service à la salle, à la baie et aux chemins réseau exacts qu’ils utiliseront.

Les preuves réseau sont vivantes, mais elles ne sont pas larges

AS142379 est l’ancre de routage pour l’entité de l’annuaire.APNIC RDAP pour AS142379nomme le système autonome « ISC-DC-AS-ID » et donne le contexte du titulaire comme PT. INDONESIA SUPER CORRIDOR - centres de données en Indonésie. Ses données de contact administratif et technique pointent vers une adresse e-mail ISC, tandis que les données de contact abuse utilisent l’adresse hostmaster ISC à un emplacement Cyber Building. C’est une preuve d’identité de registre solide.

L’image des ressources IP montre une frontière de groupe CNI.APNIC RDAP pour 103.91.24.0répertorie le bloc 103.91.24.0 - 103.91.27.255 comme CNI-ID, espace d’adressage portable alloué pour PT Cyber Network Indonesia, un fournisseur de services Internet à Jakarta.APNIC RDAP pour 123.253.248.0répertorie de même 123.253.248.0 - 123.253.251.255 comme CNI-ID. Cela ne fragilise pas le dossier d’exploitation d’ISC, car les enregistrements publics et tiers d’ISC la placent à plusieurs reprises dans un contexte de groupe CNI. Cela signifie que les clients doivent comprendre quelle entité juridique et opérationnelle contrôle l’espace d’adressage, l’installation, l’échange et le contrat client.

L’aperçu AS de RIPEstata signalé AS142379 comme annoncé le 12 juillet 2026 et a nommé le titulaire comme ISC-DC-AS-ID - PT. INDONESIA SUPER CORRIDOR - centres de données. Lepoint de terminaison des préfixes annoncés de RIPEstata montré six /24 IPv4 actuels: 103.91.24.0/24, 103.91.25.0/24, 103.91.26.0/24, 103.91.27.0/24, 123.253.248.0/24 et 123.253.249.0/24. Lesdonnées de statut de routage de RIPEstatont montré que les 325 pairs IPv4 RIS voyaient l’ensemble de routes au moment de la requête, 1 536 adresses IPv4 annoncées et aucune annonce IPv6 actuelle visible par RIS.

C’est une bonne preuve d’accessibilité, mais ce n’est pas une histoire de diversité complète. Lesdonnées de voisins ASN de RIPEstatont montré un voisin observé: AS38496.APNIC RDAP pour AS38496identifie cet AS comme CNI-AS-ID pour PT Cyber Network Indonesia. Cela ressemble à une relation de transit interne ou de groupe proche plutôt qu’à la preuve qu’AS142379 dispose de plusieurs fournisseurs de transit externes indépendants visibles dans le BGP mondial. Si un client d’installation a besoin de diversité de transport, la question n’est pas « est-ce qu’ISC route des adresses? » La question est « combien de chemins d’entrée physiques, de croisements de transport et de politiques de transit mon service peut-il réellement utiliser? »

La sécurité des routes est un point plus positif. Lavalidation RPKI de RIPEstat pour 103.91.24.0/24et lavalidation RPKI pour 123.253.248.0/24ont toutes deux renvoyé un statut valide pour AS142379 au moment de la requête. La validité RPKI n’empêche pas les pannes et ne prouve pas la diversité des installations, mais c’est un véritable signal d’hygiène de routage. Elle réduit une classe de risque de fausse déclaration d’origine et montre que l’environnement d’adressage CNI/ISC n’est pas une surface de routage totalement négligée.

IPv6 est le signal le plus faible. Baxtel décrit l’ISC Tower comme entièrement IPv4 et prenant en charge IPv6, et ISCX annonce le peering IPv4 et IPv6. Mais la vue actuelle d’AS142379 par RIPEstat n’a montré aucun préfixe IPv6 visible au moment de la requête. Cela peut signifier qu’IPv6 est fourni via d’autres ASN, via des LAN d’échange, via des réseaux clients ou qu’il n’est pas actuellement annoncé par AS142379. Pour les acheteurs, le point pratique est simple: ne supposez pas un service double pile à partir d’un libellé marketing.

Demandez quel ASN annonce l’IPv6 client, si les packages cloud incluent IPv6, si RPKI le couvre, et si les chemins IPv6 bénéficient de la même surveillance et du même support que l’IPv4.

ISCX est stratégiquement utile, mais ne prouve pas tous les chemins clients

L’histoire de l’échange d’ISC est un véritable atout. Lesite ISCXdécrit un « point d’échange Internet de connectivité avec support de centre de données Tier IV en Indonésie » et liste l’accès IXP Manager, l’état du trafic, les mises à jour des filtres d’adresse MAC et IRR, les tableaux de bord de surveillance, le support de serveur de routes, le looking glass, les communautés BGP, le filtrage IRR et RPKI. Lapage ISCX sur PeeringDBrépertorie ISCX Internet Exchange sous PT. Indonesia Super Corridor à Jakarta, avec le site webhttp://iscx.isc.id, des champs de contact technique et un horodatage de mise à jour de juin 2025. Lapage organisation PT. Indonesia Super Corridor sur PeeringDBdonne le contexte d’adresse Cyber 1 et identifie l’organisation derrière les enregistrements liés à l’échange.

Pour un opérateur de centre de données, un échange peut compter autant qu’un transit brut. Il peut réduire la latence domestique, garder le trafic local, attirer les réseaux de contenu et d’accès, et créer une raison commerciale pour que les opérateurs maintiennent une présence dans le bâtiment. Les pages d’ISC mentionnent à plusieurs reprises IIX, OIXP et Equinix IX dans les offres de services. Ses offres cloud revendiquent un accès 1 Gbps à IIX, OIXP et Equinix IX, tandis que les pages de colocation incluent de la bande passante IIX et IX dans les plans de baies.

Ces affirmations correspondent à une installation qui vend non seulement de l’espace et de l’alimentation, mais aussi la proximité avec l’interconnexion indonésienne.

La mise en garde est que la présence d’un échange et la redondance client sont deux choses différentes. Un serveur de routes, un IXP Manager et un looking glass aident les membres à gérer le peering. Ils ne prouvent pas en eux-mêmes qu’un client en colocation dispose de deux entrées de fibre, de deux salles de point de rencontre, de deux contrats de transit, de chemins de bâtiment isolés ou d’un basculement testé d’un opérateur à l’autre. Un échange peut être un point de concentration autant qu’un outil de résilience.

Si de nombreux clients dépendent du même tissu de commutation, domaine d’alimentation, salle de point de rencontre ou chemin d’agrégation en amont, l’échange devient une partie du domaine de défaillance commun.

PeeringDB crée également une division intéressante. ISCX et l’organisation PT. Indonesia Super Corridor sont visibles, et PeeringDB a une page réseau pour AS136825, un profil Indonesia Super Corridor connexe avec des installations d’interconnexion incluant CNI/ISC DC CBR, CNI DC MPR et CNI DC DPS. Mais une requête directe de l’API PeeringDB pour AS142379 n’a renvoyé aucun profil réseau AS142379 au moment de la vérification. Cette absence n’est pas un problème en soi; de nombreux opérateurs d’installation séparent l’installation, l’échange et les ASN de service.

Cela signifie que les clients doivent demander quel AS, quel tissu d’échange et quel port physique leur service particulier utilise.

La question d’acheteur la plus forte est topologique: « Dessinez le chemin. » Pour une baie complète au MPR, montrez l’alimentation électrique vers l’onduleur vers la baie, le refroidissement vers la baie, le croisement vers la salle de point de rencontre, le transport vers l’amont, le port d’échange vers le serveur de routes, et le réseau de secours vers le DRC le cas échéant. Pour une VM cloud, montrez l’hyperviseur, le stockage, le commutateur haut de baie, l’agrégation, le pare-feu, le transit, le peering, la sauvegarde et le portail de gestion.

Pour un client de reprise après sinistre, montrez le site principal, le chemin de réplication, la mesure RPO/RTO et la cible de restauration. Sans ce dessin, ISCX est un signal attrayant, mais pas une garantie.

La propriété et la frontière opérationnelle nécessitent encore une clarté contractuelle

Les preuves publiques d’ISC chevauchent à plusieurs reprises l’environnement du groupe CNI. Les allocations IP d’APNIC examinées ici sont attribuées à PT Cyber Network Indonesia. AS38496, le seul voisin AS142379 observé dans la vue de RIPEstat, est CNI-AS-ID. Les profils PeeringDB placent PT. Indonesia Super Corridor, ISCX et les noms d’installations de marque CNI dans le même paysage pratique d’interconnexion. Les annuaires d’installations tiers décrivent ISC comme faisant partie du contexte du groupe CNI. Ce schéma n’est pas suspect.

Il est normal que les activités de centre de données, d’échange et de FAI partagent des bâtiments, des sociétés mères, des ressources IP, des équipes d’exploitation et des actifs réseau.

Mais un contexte partagé modifie la diligence. Un client ne doit pas s’arrêter à la marque sur la page web. Il doit identifier l’entité contractante, l’exploitant de l’installation, le détenteur des ressources IP, l’exploitant de l’échange, le prestataire de services à distance, la partie facturante et la partie responsable des communications en cas d’incident. Si une entreprise possède le bâtiment, une autre gère l’échange, une autre détient l’espace d’adressage et une autre signe le bon de commande, le client doit savoir où se situent la responsabilité et l’escalade.

La même question s’applique à l’intérieur de l’installation: un service cloud est-il opéré par ISC sur un équipement appartenant à ISC, par une filiale CNI, par un équipement client dans une baie ISC, ou par un partenaire dont le nom n’est pas visible sur la page produit publique?

La réponse importe pendant les pannes car les défaillances ne respectent pas les frontières marketing. Un client peut avoir un contrat de colocation avec une entité, une attribution IP d’une autre, un croisement via l’équipe d’échange, un ticket de support via un portail client et un chemin de réplication DRC via un troisième service. Si ces fonctions sont opérationnellement intégrées, le client bénéficie d’une équipe de récupération coordonnée unique. Si elles sont administrativement séparées, la récupération peut ralentir pendant que les équipes décident à qui appartient le problème.

Le dossier public ne permet pas à un lecteur extérieur de résoudre cette frontière.

Pour l’approvisionnement, la preuve la plus claire serait un calendrier de services qui associe chaque dépendance à une partie responsable. Il devrait indiquer qui contrôle la salle, qui entretient les onduleurs et les générateurs, qui gère le refroidissement, qui gère les croisements clients, qui possède la plateforme cloud, qui annonce les préfixes clients, qui gère les abus, qui approuve l’accès d’urgence et qui parle aux clients pendant un incident. Ce n’est pas une trivialité juridique.

En cas d’événement électrique, de fuite de route, de défaillance de carte d’accès ou d’activation du DRC, la frontière détermine la rapidité avec laquelle une personne réelle peut prendre une décision.

La page de reprise après sinistre pose les bonnes questions et laisse les réponses difficiles ouvertes

La page DRC de Bali est utile car elle nomme explicitement les concepts de reprise. Elle mentionne le RPO, le RTO, la restauration universelle, la protection des applications métier, la compression, la déduplication, la connectivité multi-échanges, l’alimentation résiliente, la protection incendie, la surveillance et la climatisation de précision redondante. Ce vocabulaire est exactement ce que les acheteurs d’entreprise devraient attendre d’un fournisseur de reprise après sinistre.

La page ne se contente pas de dire « données en sécurité »; elle identifie le temps de récupération, le point de récupération, le réseau, l’alimentation, l’incendie et le refroidissement comme les composants de l’offre.

Mais le langage de reprise ne devient une preuve que lorsqu’il est lié à des tests. Une page DRC publique ne peut pas dire à une banque, une agence gouvernementale, un opérateur de commerce électronique ou une entreprise SaaS si sa charge de travail redémarrera dans la fenêtre promise. La réponse dépend du mode de réplication, de la cohérence du stockage, des dépendances applicatives, du basculement DNS et de routage, des systèmes d’identité, de l’ordre d’écriture des bases de données, de l’immutabilité des sauvegardes, de la fréquence des tests et de l’accès du personnel client.

« Connexion gigabit vers de multiples échanges » est une affirmation utile, mais ce n’est pas la même chose que la bande passante de réplication mesurée en charge. « Capacité complète de générateur de secours » est encourageant, mais ce n’est pas la même chose que l’autonomie en carburant pendant une urgence régionale.

La page DRC soulève également une question de séparation des installations. Bali est physiquement éloignée de Jakarta, ce qui peut être précieux pour la reprise après sinistre régionale. Mais la distance augmente la latence, modifie la dépendance réseau et peut compliquer la conception de la cohérence des données. Pour certaines charges de travail, Bali peut être excellent comme sauvegarde ou veille chaude. Pour les systèmes transactionnels à faible latence, cela peut nécessiter une réplication asynchrone prudente et l’acceptation de fenêtres de perte de données.

Les clients doivent savoir si l’offre DRC d’ISC est de type sauvegarde-restauration, veilleuse, veille chaude, actif-actif ou simplement de la colocation sur un second site. Chaque modèle a un coût et un comportement de défaillance différents.

Cela importe parce que le « DRC » peut être survendu sur le marché. Une seconde salle avec alimentation et refroidissement ne suffit pas. Un centre de reprise après sinistre doit être exercé. Un client doit demander la date du dernier test, la portée du test, le RPO et le RTO atteints, les hypothèses de défaillance, la propriété du runbook, le plan de dotation en personnel, le processus de notification client et les preuves post-test. Il doit demander si la capacité de restauration est réservée ou au mieux. Il doit demander si les chemins réseau du DRC passent par les mêmes points de concentration de Jakarta qui ont échoué.

Il doit demander ce qui se passe lorsque le sinistre n’est pas une panne de bâtiment mais un incident cyber, un verrouillage de facturation, une défaillance du contrôleur cloud ou une suppression accidentelle.

Le matériel DRC public d’ISC est suffisamment solide pour justifier ces questions, pas assez pour y répondre. L’entreprise commercialise clairement les concepts qui importent. Elle dispose d’une installation nommée à Bali dans la liste des clients de l’Uptime et dans les annuaires de type Datacenters.com/DatacenterMap. Ce qui manque publiquement, c’est la preuve de récupération de niveau client. Ce n’est pas inhabituel dans la colocation, car de nombreux détails figurent dans les propositions et les contrats.

Mais cela signifie que les lecteurs publics ne doivent pas convertir les titres « RPO » et « RTO » en confiance sans demander des preuves mesurées.

Qui est affecté si la plateforme échoue

Les parties affectées sont plus larges que les locataires de baies. Un client de colocation traditionnel peut perdre l’accès à l’équipement hébergé en cas de panne d’alimentation, de refroidissement, de contrôle d’accès ou de smart hands. Un client cloud peut perdre le calcul, le stockage, le service IP public ou l’accès à la gestion en cas de défaillance de l’infrastructure virtuelle opérée par ISC. Un entité à l’échange peut perdre le peering ou la visibilité de la gestion du trafic local en cas de défaillance d’ISCX ou de ses services d’installation de support.

Un client DRC peut découvrir que son plan de reprise existe sur le papier mais ne peut pas être exécuté à la vitesse requise en cas de défaillance de la réplication, du routage, de la dotation en personnel ou de la logistique de carburant. Le même bâtiment peut supporter plusieurs profils de risque différents à la fois.

Les clients les plus sensibles sont ceux qui utilisent ISC pour la localité et la continuité indonésiennes. Les entreprises nationales, les fournisseurs du secteur financier, les systèmes proches du gouvernement, les plateformes médiatiques, les réseaux de contenu et les fournisseurs SaaS régionaux peuvent se soucier de l’accessibilité à Jakarta, de l’accès aux échanges locaux, des canaux de support indonésiens et de la confiance dans la localisation des données. Pour eux, l’installation n’est pas seulement une baie moins chère.

Elle fait partie de la frontière de service que les clients utilisent pour répondre aux attentes de latence, de conformité et de continuité.

Le deuxième groupe affecté est constitué des petits réseaux et fournisseurs de contenu qui pourraient utiliser ISCX ou l’infrastructure hébergée par ISC pour le peering. Si un serveur de routes, un tissu de commutation ou un domaine d’alimentation de l’installation échoue, le trafic local peut être redirigé vers des chemins plus longs ou échouer pour les réseaux sans peering de secours. Si un portail IXP ou un système de surveillance échoue, les membres peuvent perdre la visibilité opérationnelle même si le transfert de paquets continue.

Le matériel ISCX public annonce des tableaux de bord de surveillance et des fonctions de serveur de routes; les clients doivent demander si ces systèmes sont hors bande, redondants et exploités indépendamment du tissu d’échange qu’ils surveillent.

Le troisième groupe affecté est constitué des clients qui achètent du cloud plutôt que de l’espace. Les acheteurs cloud ont souvent moins de visibilité sur l’emplacement de leurs charges de travail. Ils peuvent voir un plan de VM, de la mémoire, du stockage, une IP publique et un package de bande passante, mais pas le cluster hôte, la réplication du stockage, la politique de maintenance de l’hyperviseur, le calendrier de sauvegarde ou le chemin d’escalade du support.

Si les services cloud d’ISC sont construits sur un pool de ressources compact, le risque pratique est la contention de voisin bruyant, la maintenance de l’hôte, la défaillance du stockage, une bande passante internationale limitée ou un support lent pendant un incident d’installation. Les plans publics sont utiles pour la tarification et la portée; ils ne suffisent pas pour une architecture de production.

Le quatrième groupe affecté est constitué des revendeurs ou des fournisseurs de services gérés qui pourraient placer des systèmes clients à l’intérieur d’ISC sans exposer ISC comme dépendance. Lorsqu’un service en marque blanche ou hébergé par un revendeur échoue, l’utilisateur final ne voit souvent que le fournisseur immédiat. La défaillance sous-jacente du centre de données peut être invisible jusqu’à ce que la récupération s’arrête. Pour ces chaînes, les preuves opérationnelles d’ISC importent même si le client final ne signe jamais directement avec ISC.

Les chemins de défaillance à tester sont ordinaires et sans pitié

Le premier chemin de défaillance est l’alimentation électrique. Les pages d’ISC mentionnent l’alimentation à double source, des tableaux de distribution séparés, une alimentation résiliente provenant de deux sources de tension et des générateurs. Ce sont les bons composants.

Les clients doivent néanmoins vérifier le schéma unifilaire, si les deux sources sont des alimentations électriques indépendantes ou des chemins de distribution internes, si la capacité des générateurs supporte la charge informatique complète et le refroidissement ensemble, combien de temps le carburant dure à la charge engagée, si le réapprovisionnement est contracté pendant un événement à l’échelle de la ville, et si la maintenance peut être effectuée sans déplacer les charges client dans un état de redondance réduite.

Le deuxième chemin de défaillance est le refroidissement. La page DRC d’ISC mentionne une climatisation de précision avec un système redondant et ses pages de maintenance font référence à des travaux sur le système de refroidissement. C’est un bon début. Le risque est que les contraintes de refroidissement et d’alimentation interagissent. Une baie peut être vendue avec 10 A, mais un équipement dense peut créer des points chauds, et la redondance du refroidissement doit supporter la charge réelle, pas la charge moyenne.

Les clients doivent demander des détails sur le confinement allée froide/allée chaude, les plages de température et d’humidité, la redondance des unités de refroidissement, la conception du refroidisseur ou DX, l’historique de maintenance et les alarmes visibles via DCIM.

Le troisième chemin de défaillance est l’interruption du point de rencontre des opérateurs. Le matériel public d’ISC commercialise les croisements, la bande passante IIX/IX, ISCX, les serveurs de routes, OIXP, Equinix IX et le langage multi-échanges. La vue BGP pour AS142379 montre encore un voisin observé, AS38496, et aucune route IPv6 actuelle depuis cet AS. Cela ne contredit pas l’histoire de l’échange, mais cela signifie que les preuves publiques au niveau AS ne montrent pas une large diversité de transit.

Les clients doivent exiger une liste d’opérateurs, une déclaration de diversité de chemin, une conception de la salle de point de rencontre, un SLA de croisement et la preuve que le basculement a été testé depuis la baie ou le réseau virtuel du client.

Le quatrième chemin de défaillance est l’incendie, l’inondation ou l’interruption d’accès à l’installation. La page Bali mentionne le FM200 et des capteurs de fumée au-dessus et en dessous du plancher surélevé, la vidéosurveillance et l’accès par carte/empreinte digitale aux baies. La page d’accueil mentionne la sécurité humaine et des détecteurs de mouvement.

Ce sont des contrôles physiques, mais les clients doivent se renseigner sur les infiltrations d’eau, les risques de toiture et de drainage, la charge au sol, la séparation des zones incendie, l’accès d’urgence, l’accès client pendant les incidents et si les contraintes d’assurance ou de gestion du bâtiment pourraient retarder les réparations. Un centre de données peut avoir de bons contrôles et être néanmoins exposé à des dépendances ordinaires du bâtiment.

Le cinquième chemin de défaillance est la construction ou l’inadéquation de capacité. Le dossier public porte plusieurs chiffres de capacité: le titre de 5 MW MPR d’ISC, le marqueur de 6 MW de Baxtel, le chiffre de 16,0 MW de Datacenters.com pour MPR, et d’autres références de marché allant jusqu’à 8 MW de charge informatique. L’existence de chiffres différents n’est pas alarmante en soi, mais c’est un avertissement contre l’achat à partir d’un chiffre de diapositive.

Les clients doivent demander quel chiffre est actuel, s’il s’agit de la capacité du réseau public, brute, critique, informatique ou planifiée, et si leur contrat réserve la capacité ou leur donne simplement accès à la capacité tant qu’elle est disponible.

Le sixième chemin de défaillance est administratif. Les comptes DCIM, les portails clients, les services d’assistance, les systèmes de facturation et les autorisations d’accès font partie de l’infrastructure. Si un portail est hors service, un client peut ne pas être en mesure de surveiller le trafic, d’ouvrir un ticket, de provisionner de la capacité cloud, d’ajuster les filtres réseau ou de vérifier qu’un événement de maintenance est planifié. ISCX annonce IXP Manager et des tableaux de bord de surveillance. ISC annonce des comptes DCIM client.

Les acheteurs doivent traiter ces systèmes comme des dépendances opérationnelles et demander comment ils sont sauvegardés, surveillés et supportés.

Ce qui changerait la note

ISC peut améliorer la note de risque publique sans publier de données clients sensibles. Une courte page réseau aiderait: les ASN utilisés pour les services d’installation, de cloud et d’échange; les préfixes IPv4 et IPv6 actuels; les fournisseurs de transit/amont; les tissus d’échange; la politique du serveur de routes; le statut RPKI; les liens looking glass; les enregistrements PeeringDB; les contacts abuse et NOC; et les canaux de notification de maintenance. L’entreprise dispose déjà de suffisamment de matériel public pour soutenir une telle page. La consolider réduirait l’ambiguïté.

Une page de capacité des installations aiderait davantage. Elle devrait distinguer CBR, MPR et Bali DRC; lister le niveau de conception et la portée des récompenses; indiquer la puissance brute, la charge informatique engagée et la charge vendable disponible; expliquer les bandes de densité des baies; identifier les hypothèses d’alimentation électrique et de générateur; divulguer la redondance du refroidissement; et expliquer si les services cloud fonctionnent dans un ou plusieurs sites. Elle n’a pas besoin d’exposer les clients individuels. Elle doit rendre la capacité commercialisée testable.

Une page de preuves de reprise serait encore plus précieuse. Elle pourrait décrire les modèles de reprise après sinistre disponibles, publier des exemples de catégories RPO/RTO, expliquer la fréquence des tests de restauration, lister les options de sauvegarde et de réplication, indiquer si la capacité DRC est réservée ou au mieux, et fournir un canal de statut ou d’historique des incidents. Les clients n’ont pas besoin de perfection. Ils ont besoin de savoir si l’entreprise a pratiqué la défaillance contre laquelle elle vend une protection.

Pour la confiance réseau, AS142379 devrait montrer une diversité publique plus large s’il est destiné à servir directement des clients de production. Plusieurs fournisseurs de transit visibles, un profil réseau PeeringDB AS142379, une connectivité IPv6 utilisable actuelle par les clients, une couverture RPKI propre sur tous les préfixes visibles et un looking glass public augmenteraient tous la confiance. Si AS142379 est simplement un ASN interne ou spécifique à l’installation tandis que la diversité client repose sous AS136825, AS38496 ou d’autres ASN CNI/ISC, ISC devrait le dire clairement.

L’ambiguïté force les clients à deviner quelles preuves de route publiques s’appliquent à leur service.

Pour la confiance dans l’approvisionnement, ISC devrait aligner les revendications de capacité du marché. Un acheteur voyant 5 MW, 6 MW, 8 MW et 16 MW à différents endroits publics ne peut pas savoir quel chiffre contrôle. La réponse peut être simple: puissance du site, charge informatique, expansion planifiée, capacité du bâtiment ou erreur d’annuaire. Mais le décalage public crée des frictions. Dans l’achat de centres de données, une déclaration de capacité propre n’est pas cosmétique; elle détermine si un client peut réserver de l’espace et de l’énergie pour trois à cinq ans.

Note d’exploitation

PT. INDONESIA SUPER CORRIDOR - centres de données obtient une note de preuve réseau et opérationnelle moyenne avec une forte composante d’existence d’installations. La partie forte est méritée: ISC a des pages d’installation officielles, des actifs CBR/MPR/Bali nommés, des enregistrements de récompenses délivrées par l’Uptime Institute, des offres publiques de baies et de cloud, une surface d’échange ISCX, une identité AS APNIC, une visibilité IPv4 actuelle RIPEstat et une RPKI valide sur les préfixes visibles échantillonnés. C’est bien mieux qu’une coquille dormante ou une marque d’hébergement non vérifiée.

La dégradation est également méritée. Les preuves publiques ne prouvent pas encore une capacité utilisable à l’échelle annoncée. Elles ne réconcilient pas les chiffres de puissance concurrents. Elles ne montrent pas d’IPv6 actuelle pour AS142379. Elles montrent un seul voisin BGP observé pour cet AS. Elles ne publient pas de listes d’opérateurs, de schémas unifilaires électriques, d’autonomie en carburant, de preuves de test de refroidissement, de résultats de restauration client, d’historique de statut, de communications d’incident, d’architecture cloud ou de règles de basculement spécifiques au site.

L’entreprise commercialise les bons ingrédients, mais les clients doivent encore vérifier la recette.

La conclusion pratique n’est pas d’éviter ISC. C’est d’acheter prudemment. Pour une colocation modeste, une présence adjacente à un échange, la localité indonésienne ou une conversation de reprise Jakarta/Bali, ISC mérite de figurer sur la liste de diligence.

Pour les charges de production qui dépendent d’une alimentation ininterrompue, de chemins d’opérateurs diversifiés et d’une reprise éprouvée, les acheteurs doivent exiger des visites de site, des documents d’ingénierie, des tests de route en direct, des exercices de basculement et un langage contractuel qui associe le service commercialisé à une installation et un chemin de dépendance spécifiques. Dans les centres de données, la différence entre « baies disponibles » et « capacité survivable » est là où réside le vrai risque.