Résumé

  • PT Media Cloud Indonesia dispose de preuves publiques d’exploitation plus solides que de nombreux petits hébergeurs: les enregistrements APNIC/IDNIC la relient à AS140449, 103.152.240.0/23 et 2406:38c0::/32, tandis que RIPEstat a observé 103.152.240.0/24, 103.152.241.0/24 et 2406:38c0::/32 annoncés par AS140449 pendant la fenêtre de vérification de juillet 2026.
  • L’entreprise commercialise un large bouquet sous la marque Media Cloud: domaines, hébergement WordPress et Sitejet, VPS Indonésien, SSL, messagerie professionnelle, services web, promotion d’hébergement de jeux et une offre de boucle locale sur mci.net.id qui présente des forfaits de bande passante dédiée de 1 Gbit/s, 2 Gbit/s et 3 Gbit/s.
  • L’inquiétude concernant la résilience est tout aussi concrète. PeeringDB liste un rattachement d’échange à OpenIXP/NiCE et zéro installation pour le réseau; les données de voisinage RIPEstat sont dominées par AS138840, et l’objet de route IPv6 RADB décrit une route client HSP Global enregistrée par procuration. Ce sont des preuves d’interconnexion visibles, pas une preuve de capacité multi-sites indépendante.
  • Les conditions d’utilisation et la politique de remboursement de Media Cloud rendent visible le chemin de défaillance physique: les services peuvent devenir inaccessibles en raison d’un dysfonctionnement d’équipement, d’une maintenance, d’une réparation ou d’un remplacement, d’une interruption de liaison télécom, d’attaques hostiles, de congestion ou d’autres défaillances; le remboursement des services internet est conditionné à plus de sept jours consécutifs d’interruption ou à l’impossibilité de poursuivre le service.
  • Le niveau de preuve est Moyen. L’identité, la surface produit, l’espace d’adressage routé et l’accessibilité actuelle sont bien étayés; les preuves publiques sur l’emplacement des installations, la capacité de réserve, la diversité de transit, la reprise testée et les limites de portabilité des données restent incomplètes.

L’entreprise est visible, mais la dépendance reste physique

PT Media Cloud Indonesia mérite une lecture plus attentive qu’une simple étiquette de « petit hébergeur ». L’entreprise présente deux surfaces publiques liées. L’une est le site orienté connectivité àmci.net.id, qui promeut des solutions de boucle locale et de connectivité FTTH et dirige les utilisateurs vers la boutique de services Cloud. L’autre estmediacloud.id, la surface commerciale destinée aux clients pour les domaines, l’hébergement, les VPS, les certificats SSL, la messagerie et les services web. Ces deux surfaces ne sont pas de simples anecdotes de marque. Elles montrent que l’entreprise demande aux clients de lui confier à la fois leur présence internet de base et des services d’infrastructure structurants.

Cette confiance se heurte à des contraintes très réelles. Un VPS est une machine virtuelle, mais il fonctionne sur du calcul, du stockage, de l’alimentation et du refroidissement physiques. La « bande passante illimitée » est une phrase marketing, mais les paquets traversent toujours des ports, des routeurs, des filtres, de la fibre optique, des contrats de transit et des fabrics d’échange. Une promesse de « support 24/7 » n’est utile que si le client peut joindre l’équipe même lorsque le service affecté, le système de tickets, le DNS ou l’état de facturation est lui-même en panne.

L’offre de boucle locale est encore plus directe: elle dépend de l’accès du dernier kilomètre, d’un point d’interconnexion, d’un chemin d’accès amont, de techniciens d’astreinte et d’une règle commerciale sur ce qui se passe lorsque le circuit reste hors service.

Les preuves publiques commencent au niveau des ressources numériques. L’enregistrement RDAP APNIC/IDNIC pourAS140449liste MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, « Fournisseur de services Internet » et une adresse administrative à Jakarta Sud. APNIC/IDNIC montre également le réseau IPv4103.152.240.0/23et le réseau IPv62406:38c0::/32sous le nom MEDIACLOUD-ID. Ces enregistrements ne prouvent pas l’emplacement de chaque serveur, mais ils sont bien plus solides qu’une page de revendeur anonyme. Ils montrent une entreprise disposant de ressources Internet numériques directement visibles.

L’entreprise héberge également ses sites web publics au sein de cette empreinte. Une vérification DNS pendant cette recherche a résolu mci.net.id et mediacloud.id vers l’adresse 103.152.240.97, à l’intérieur de l’allocation 103.152.240.0/23. C’est un signal modeste mais important: le site web public n’est pas simplement hébergé derrière une passerelle mondiale sans lien apparent avec l’enregistrement réseau. La marque, l’ASN et l’espace d’adressage routé sont suffisamment alignés pour rendre la revendication d’infrastructure vérifiable.

La partie difficile n’est pas de prouver que Media Cloud a une présence publique. La partie difficile est de déterminer le niveau de résilience client que cette présence implique. Les preuves de routage publiques peuvent montrer quels préfixes sont visibles, quels ASN sont adjacents au réseau, si les données d’origine de route sont couvertes et si un répertoire d’échange volontaire liste un port. Elles ne peuvent pas montrer le serveur de rechange dans le rack, le contrat d’installation, le processus de sauvegarde client ou la personne autorisée à remplacer le matériel après minuit. Cet écart est au cœur de l’article.

La gamme de produits annoncée va au-delà d’une simple page VPS

Les pages produits de Media Cloud montrent une entreprise qui veut être un guichet unique pour les clients indonésiens souhaitant construire une présence web. Laboutique Media Cloudindique qu’elle fournit des domaines, de l’hébergement, un constructeur de site, de la messagerie, des certificats SSL et des services VPS. Elle promeut les domaines.id et.com, les services de revendeur et en gros, et une vignette « Best VPS Cloud Hosting » pointant vers le produit VPS. Cela compte car une offre large crée de multiples chemins de dépendance. Un client peut acheter un domaine, un DNS, un certificat SSL, une boîte mail, un constructeur de site et un VPS auprès du même fournisseur et découvrir lors d’un incident que la dépendance technique et la dépendance de compte sont étroitement liées.

Lapage VPSest la revendication la plus claire de capacité hébergée. Elle commercialise « VPS Indonesia », décrit le service comme « VPS indonésien rapide et stable à des prix abordables » et liste des ressources 100% dédiées, du stockage NVMe, une bande passante illimitée et une protection DDoS. Elle indique également que les clients peuvent choisir des systèmes d’exploitation et des applications préconfigurées. C’est exactement le langage qui transforme un petit réseau en dépendance commerciale: les clients n’achètent pas seulement de l’espace d’adressage; ils s’attendent à du calcul, du stockage, des installations logicielles, des contrôles de sécurité et une capacité réseau suffisante pour maintenir les applications accessibles.

Les pages d’hébergement ajoutent une couche supplémentaire.Sitejet Hostingprésente un hébergement groupé avec un constructeur de site et met en avant la protection DDoS, cPanel, Softaculous et les installations en un clic.WordPress Hostingutilise le même langage de fiabilité et de fonctionnalités bien que le tableau des forfaits n’était pas disponible pour la devise détectée au moment de la consultation. Cela est utile car cela révèle les hypothèses de plateforme sous-jacentes à l’expérience client. cPanel, Softaculous, les constructeurs de site et l’hébergement WordPress dépendent tous de panneaux de contrôle, de statuts de licence, de stockage et de pratiques de sauvegarde. Ce sont des systèmes opérationnels, pas de simples noms de produits statiques.

La messagerie étend encore la dépendance.Email Hostingfait la publicité de la messagerie professionnelle avec une garantie de disponibilité de 99,9%, des domaines personnalisés, de la sécurité, une surveillance, un support 24/7 et une assistance pour la configuration, la migration et le dépannage.Professional Emaildécrit 8 Go par boîte aux lettres, un webmail, anti-spam, anti-virus, des signatures DKIM, des sauvegardes automatiques, des fonctions de traçage des courriels et des journaux d’audit. Les enregistrements MX ajoutent de la nuance: mci.net.id utilise la protection de messagerie Microsoft, tandis que mediacloud.id pointe vers les serveurs de messagerie Google aspmx. Ce n’est pas contradictoire; cela montre que certaines parties de l’entreprise reposent sur des plateformes de messagerie externes même lorsque les sites web publics se trouvent dans l’espace d’adressage propre de Media Cloud.

Lapage SSLet les pages de domaines complètent le tableau. Media Cloud vend des couches de confiance au-dessus des serveurs: enregistrement de domaine, transfert, identité.id, certificats, génération de site et identité de boîte aux lettres. Un client qui concentre ces services peut gagner en commodité mais crée aussi un problème de reprise. Si la facturation, la vérification d’identité, le support ou le panneau de contrôle se bloquent, plusieurs fonctions commerciales indépendantes peuvent se bloquer simultanément.

La tarification de la boucle locale rend explicite la question du rack et du routage

La page d’accueil de mci.net.id est inhabituellement utile car elle ne promeut pas seulement des services cloud abstraits. Elle fait de la publicité pour des « solutions de connectivité de boucle locale et FTTH » et décrit une « bande passante dédiée haut débit pour des communications d’entreprise fiables ». La page liste des forfaits de boucle locale à 10 000 000 IDR par mois pour 1 Gbit/s, 20 000 000 IDR par mois pour 2 Gbit/s et 30 000 000 IDR par mois pour 3 Gbit/s, avec des liens « Obtenir un devis ».

Elle indique également que Media Cloud fournit une connectivité dédiée sécurisée et haute performance, une faible latence, une intégration évolutive et un support local 24/7.

Ces affirmations n’équivalent pas à une divulgation publique d’installation. Cependant, elles déplacent l’analyse de l’hébergement web simple à l’infrastructure physique. Un service de boucle locale a besoin d’un chemin d’accès client, d’un point d’interconnexion, d’un chemin de liaison, d’un routeur, d’un modèle de support et d’un processus de réparation. Le chemin de défaillance n’est plus simplement « le VPS est en panne ».

Il peut s’agir d’un problème de fibre du dernier kilomètre, d’un problème de fournisseur amont, d’un problème de routeur d’accès, d’un problème d’interconnexion de centre de données, d’un problème de répartition du support, d’un blocage de facturation ou d’un problème d’équipement côté client que le fournisseur peut ou non contrôler.

L’histoire de l’adresse publique nécessite également de la prudence. Les enregistrements de ressources numériques APNIC/IDNIC donnent une adresse au Prudential Center à Jakarta Sud. Les pieds de page publics actuels de Media Cloud dirigent les lecteurs vers Epicentrum Walk 3rd Floor Unit A306-307, Jl. HR Rasuna Said, Kuningan, Jakarta Sud. Les deux peuvent être vrais de différentes manières: l’un peut être une adresse de registre, l’autre un bureau actuel ou un emplacement de support, et aucun n’identifie nécessairement l’endroit où les charges de travail ou les routeurs des clients sont réellement hébergés.

La distinction compte car les clients confondent souvent une adresse de contact d’entreprise avec une adresse d’installation. Ils ne le devraient pas.

La page de boucle locale ne nomme pas le centre de données, le bâtiment d’échange, la route de fibre, les fournisseurs de transit amont, la limite de service ou le site de reprise. C’est normal pour une page marketing publique, mais cela signifie que l’acheteur doit poser la question. Si la boucle locale proposée se termine dans le même bâtiment que la charge de travail hébergée, le modèle de défaillance diffère d’une boucle qui atterrit dans un hôtel télécom séparé. Si la boucle est fournie par un partenaire, le chemin de remboursement et d’escalade peut dépendre de la file d’attente de tickets du partenaire.

Si le client a besoin de diversité de routage, il doit savoir si deux circuits partagent des gaines, des entrées de bâtiment, des panneaux de brassage ou une seule passerelle amont.

Ce n’est pas pour dire que l’offre de boucle locale de Media Cloud est faible. C’est pour souligner qu’elle rend la dépendance physique inévitable. La capacité hébergée semble élastique jusqu’à ce que le dernier kilomètre ou le chemin amont échoue. Un client achetant du cloud et de la connectivité locale auprès du même fournisseur devrait se demander si ce regroupement augmente le contrôle ou simplement concentre la défaillance.

AS140449 annonce actuellement un petit ensemble cohérent de préfixes

Les preuves de routage sont plus claires que les preuves du site d’entreprise. L’aperçu RIPEstat AS140449a identifié le détenteur comme « MEDIACLOUD-AS-ID – PT Media Cloud Indonesia » et a montré que l’AS était annoncé pendant la vérification de juillet 2026. Lavue des préfixes annoncés RIPEstatlistait 103.152.240.0/24, 103.152.241.0/24 et 2406:38c0::/32 comme visibles dans la fenêtre du 27/06/2026 au 11/07/2026. Cela signifie que le /23 enregistré est divisé opérationnellement en deux annonces IPv4 /24 visibles, tandis que l’allocation IPv6 est annoncée comme un /32.

Cette configuration est cohérente avec un petit opérateur plutôt qu’un cloud hyperscale. Deux /24 fournissent une présence publique visible, suffisante pour des sites web, de l’hébergement partagé, des adresses VPS, des systèmes de contrôle ou des services locaux, mais pas une empreinte cloud de vente au détail massive. Le /32 IPv6 est beaucoup plus grand en termes d’adresses, mais le volume d’adresses IPv6 ne doit pas être confondu avec la capacité de calcul installée.

La question de la capacité utilisable n’est pas le nombre d’adresses qui existent, mais le nombre de charges de travail qui peuvent être hébergées, déplacées, restaurées et supportées en cas de panne.

L’historique de routagede RIPEstat ajoute de la continuité. Les deux /24 IPv4 apparaissent dans l’historique depuis septembre 2020, tandis que le /32 IPv6 apparaît depuis mars 2021. Sur le dernier intervalle observé, les préfixes IPv4 étaient encore visibles jusqu’au 11/07/2026, et la route IPv6 était également visible jusqu’au 11/07/2026. C’est plus solide qu’un ASN dormant nouvellement créé. Cela suggère une surface de routage publique qui a persisté pendant des années.

Mais l’historique inclut également des périodes de moindre visibilité. Les collecteurs de routes publics peuvent montrer que la visibilité a changé; ils ne peuvent pas expliquer pourquoi. Une baisse peut refléter une politique de routage, une couverture du collecteur, un problème amont, une période de maintenance, un filtrage de route, des effets RPKI ou IRR ailleurs, ou une véritable interruption de service. Il serait irresponsable de convertir l’historique en une affirmation d’interruption spécifique sans preuve d’opérateur ou de client.

Sa valeur est plus étroite: elle montre que la périphérie de route publique est suffisamment observable pour être surveillée et que les clients peuvent se demander ce qui a changé lorsque la visibilité a changé.

L’état BGP actuel est également instructif. Laréponse d’état BGPde RIPEstat a montré de nombreux chemins de collecteurs globaux vers les préfixes de Media Cloud, la plupart des chemins atteignant AS140449 via AS138840. D’autres chemins dans l’échantillon incluaient de grands noms de transit globaux plus en amont, mais la contiguïté immédiate répétée avec AS138840 est la dépendance qui compte. Un client n’a pas besoin de tous les détails du collecteur de routes; il doit savoir si la périphérie de Media Cloud peut survivre à une perte ou une congestion du chemin amont immédiat.

L’histoire amont visible pointe vers HSPnet et OpenIXP/NiCE

Lavue des voisins ASNde RIPEstat a enregistré trois ASN adjacents lors de la vérification du 11/07/2026: AS138840 comme voisin gauche dominant, AS7717 comme autre voisin gauche et AS149004 comme voisin droit. APNIC identifieAS138840comme un enregistrement NAP indonésien associé à PT Parsaoran Global Datatrans / HSPnet. APNIC identifieAS7717comme OpenIXP-AS-ID-AP. APNIC identifieAS149004comme Morapido Net au Timor-Leste. Ces étiquettes ne prouvent pas les contrats, mais elles aident à expliquer le voisinage de routage.

PeeringDB ajoute une vue d’interconnexion volontaire. Sarequête API réseau pour AS140449liste « PT Media Cloud Indonesia », alias « Mediacloud », site webhttps://mci.net.id, type d’info « Enterprise », support IPv6, une politique généralement ouverte, un nombre d’IX de 1 et un nombre d’installations de 0. Larequête netixlanassociée liste OpenIXP/NiCE, un port 1 Gbit/s, adresse IPv4 43.252.146.141, adresse IPv6 2001:7fa:f::457 et un état opérationnel. Larequête netfacne renvoie aucune entrée d’installation.

La lecture la plus forte est pratique: Media Cloud a un rattachement d’échange visible à OpenIXP/NiCE et un voisinage de routage public où AS138840 est le chemin principal vu par les collecteurs. La lecture la plus faible serait d’inférer une architecture de résilience complète à partir de ces champs. PeeringDB est maintenu par l’opérateur et volontaire. Un port d’échange de 1 Gbit/s ne prouve pas que tout le trafic client peut transiter par l’échange en cas de problème de transit.

Un nombre d’installations de 0 ne prouve pas que l’entreprise n’a pas de racks; cela signifie simplement que PeeringDB ne liste aucune entrée d’installation pour le réseau. Une contiguïté amont observée ne prouve pas si un lien est du transit, du peering, une sauvegarde ou un chemin de serveur de routes, sauf si elle est étayée par une documentation d’opérateur.

Les objets de route RADB renforcent la même prudence. Une requête RADB pour AS140449 a renvoyé des objets de route pour 103.152.240.0/24 et 103.152.241.0/24 avec origine AS140449 et des descriptions nommant PT Media Cloud Indonesia. L’objet route6 pour 2406:38c0::/32 utilisait l’origine AS140449, mais les remarques décrivaient un objet de route enregistré par procuration pour une route client HSP Global exportée sous l’AS d’origine Media Cloud, maintenu par MAINT-AS138840.

Cette formulation rend la question du contrat fournisseur centrale: si la route IPv6 dépend de HSP pour maintenir l’objet de route ou l’arrangement amont, les clients doivent savoir qui peut réparer l’entité, qui peut modifier les filtres et ce qui se passe lorsque le contrat amont ou le canal de support échoue.

L’assurance de l’origine de route reste incomplète

La validation de l’origine de route n’est pas un test de résilience complet, mais c’est un contrôle significatif. Elle vérifie si une autorisation d’origine de route (ROA) publiée soutient un préfixe et un AS d’origine donnés. Lors des vérifications RIPEstat de juillet 2026,103.152.240.0/24,103.152.241.0/24et2406:38c0::/32ont renvoyé « unknown » sans ROA validant dans la vue vérifiée. RADB a également montré un statut de validation d’origine RPKI de « not_found » pour les objets de route.

Inconnu n’est pas la même chose qu’invalide. Cela signifie que les données de validation d’origine de route vérifiées n’ont trouvé aucune ROA autorisante. Le risque pratique est que les réseaux appliquant des politiques de routage strictes peuvent traiter les routes inconnues différemment des routes valides, ou qu’un détournement de route ou une mauvaise configuration future sera plus difficile à filtrer par une politique automatisée.

Pour les clients, ce n’est pas la seule question de sécurité, mais c’est une bonne question d’approvisionnement: Media Cloud a-t-il l’intention de publier des ROA pour ses préfixes annoncés, et peut-il démontrer que les objets de route et les ROA sont maintenus par la partie ayant la responsabilité opérationnelle?

Le RPKI ne peut pas non plus prouver la qualité du service. Une origine de route valide n’indiquerait pas combien de serveurs sont en ligne, si les sauvegardes fonctionnent, si une boucle locale a une diversité de chemin, ou si un technicien peut remplacer rapidement du matériel. Elle ne ferme qu’une catégorie de risque de routage. Dans ce cas, l’absence de ROA validant rend le plan de contrôle public moins complet que le catalogue de produits. Cet écart est réparable, mais il doit être reconnu.

La leçon plus large pour les clients est que la résilience de la capacité hébergée a de nombreuses couches. Le RPKI protège l’autorisation d’origine. Les objets IRR influencent les filtres. Les voisins BGP influencent l’accessibilité. Les arrangements d’échange et de transit influencent les choix de chemin. L’installation, l’alimentation, les pièces de rechange et le support influencent la réparation. Les sauvegardes et les chemins d’exportation influencent la reprise.

Les preuves publiques de Media Cloud sont les plus solides au milieu de cette chaîne et plus faibles aux extrémités: la visibilité des routes est claire; la portabilité des données et la restauration testée ne sont pas publiques.

Les conditions de Media Cloud décrivent le chemin de défaillance

Les pages juridiques de l’entreprise ne sont pas des schémas techniques soignés, mais elles sont opérationnellement révélatrices. Lesconditions d’utilisation de mediacloud.iddéfinissent largement les services pour inclure l’enregistrement de noms de domaine, l’hébergement, les services de création de sites web et les services internet. Les conditions indiquent que l’hébergement stocke et sert le contenu du site web, et que les services internet peuvent inclure la télévision, la messagerie, la connectivité et les services connexes. Elles indiquent également que Media Cloud fera des efforts commercialement raisonnables pour fournir le site et les services vingt-quatre heures sur vingt-quatre, sept jours sur sept.

La même section sur la disponibilité est plus importante que la phrase sur la disponibilité. Elle indique que les services peuvent être inaccessibles ou inopérables pour des raisons incluant des dysfonctionnements d’équipement, une maintenance périodique, des réparations ou des remplacements, des causes indépendantes de la volonté raisonnable, une interruption ou une défaillance des liaisons de télécommunication ou de transmission numérique, des attaques réseau hostiles, une congestion réseau et d’autres défaillances. Elle indique également que Media Cloud n’a aucun contrôle sur la disponibilité continue ou ininterrompue.

Ce libellé n’est pas inhabituel; de nombreux fournisseurs utilisent des clauses de non-responsabilité similaires. Ici, cependant, il donne aux clients une liste concise des catégories exactes de dépendance qu’ils devraient tester.

Lapolitique de remboursementest tout aussi spécifique. Elle indique que les frais d’enregistrement de domaine sont généralement non remboursables une fois enregistrés ou renouvelés; les services d’hébergement et de création de sites web ne sont pas remboursés une fois achetés; et les services internet à large bande ou dédiés peuvent être éligibles à un remboursement si le service est interrompu plus de sept jours multipliés par 24 heures en continu, ou si Media Cloud ne peut pas continuer à fournir le service en raison de difficultés techniques ou d’une interdiction par le chef de quartier local. C’est un seuil opérationnel frappant. Cela suggère que pour la connectivité internet, le déclencheur de remboursement se mesure en jours, pas en minutes ou en heures.

Les clients ne doivent pas confondre l’éligibilité au remboursement avec la résilience opérationnelle. Un remboursement après une semaine d’interruption continue ne restaure pas une application, ne migre pas une boîte aux lettres, ne récupère pas une base de données et ne maintient pas une boutique en ligne en fonctionnement pendant l’interruption. Il ne définit qu’un recours financier.

Un client ayant des charges de travail critiques devrait demander des objectifs de niveau de service, une escalade des incidents, une notification proactive, des fenêtres de maintenance, des obligations d’exportation de données et des objectifs de reprise mesurés qui sont distincts de la politique de remboursement.

C’est pourquoi le titre de l’article pointe vers les racks, le transit et les fenêtres de réparation. Les conditions juridiques de Media Cloud identifient les mêmes catégories: équipement, maintenance, liaisons télécom, congestion et attaque. Les données de routage publiques montrent ensuite où apparaît une dépendance de transit majeure. Le travail de l’acheteur est de transformer ces indices publics en preuves contractuelles et testables.

La localisation des données n’est pas résolue par une marque indonésienne

Le positionnement de Media Cloud est fortement indonésien. La page des domaines met l’accent sur l’identité.id, la page VPS dit « VPS Indonesia », le pied de page donne une adresse de contact à Jakarta Sud, et les enregistrements APNIC/IDNIC placent l’AS et les ressources d’adresse en Indonésie. Pour de nombreux clients, en particulier les petites entreprises, cela peut être le point principal: un fournisseur local, une langue locale, des attentes de paiement locales et un support accessible via des canaux indonésiens.

Mais la souveraineté et la localisation des données exigent plus qu’une étiquette de pays. Un site web hébergé peut se trouver sur les adresses de Media Cloud tandis que la messagerie est traitée via Google ou Microsoft. Un ticket de support peut contenir des informations personnelles. Une sauvegarde peut être stockée dans un système différent du serveur principal. Un enregistrement de domaine peut impliquer des processus de bureau d’enregistrement et de registre. Une réclamation de mitigation DDoS peut reposer sur un filtrage amont ou une plateforme tierce.

Chaque couche peut placer des données, des métadonnées ou des droits d’accès dans un emplacement opérationnel différent.

Lapolitique de confidentialitéde l’entreprise indique qu’elle collecte des informations de contact, des informations de facturation, des identifiants de compte, du contenu créé ou téléchargé par l’utilisateur, des données de journal, des informations sur l’appareil et des cookies ou technologies similaires. Elle indique que les informations personnelles peuvent être partagées avec des fournisseurs de services, des partenaires tiers à des fins de marketing ou de publicité, dans le cadre de transactions commerciales, ou lorsque la loi l’exige. Elle indique également que les informations personnelles peuvent être transférées et traitées dans des pays autres que celui de l’utilisateur, et qu’aucune méthode de transmission internet ou de stockage électronique n’est complètement sécurisée. C’est un langage de confidentialité générique, mais dans un contexte d’hébergement, cela compte: le fournisseur reconnaît la possibilité d’un traitement transfrontalier et par des tiers.

Le contexte juridique indonésien élève également la barre pour une gestion claire des données. Le règlement gouvernemental n° 71 de 2019 sur les systèmes et transactions électroniques est publié par JDIH Kemkomdigi àcette page officielle. La page comprend des dispositions sur l’enregistrement des opérateurs de systèmes électroniques, la fiabilité, la sécurité, la gestion des risques, les accords de niveau de service et les principes de traitement des données personnelles. La loi n° 27 de 2022 sur la protection des données personnelles est publiée surJDIH Kemkomdigi. Cet article ne prétend pas que Media Cloud tombe dans une catégorie réglementaire spécifique pour chaque produit, mais le cadre national explique pourquoi les clients devraient demander où résident réellement les données, les sauvegardes, les journaux, les tickets et l’accès au support.

Le test pratique est simple. Un VPS indonésien devrait venir avec une réponse sur l’emplacement: où se trouve l’hôte principal, où sont les sauvegardes, où se trouve l’identité du plan de contrôle, où sont les journaux, et quels services tiers gèrent la messagerie, le DNS, le filtrage DDoS, le support ou la facturation? Sans cette matrice, « local » reste un signal marketing utile mais pas une garantie complète de souveraineté.

La capacité installée et la capacité utilisable sont différentes

L’empreinte réseau publique de Media Cloud soutient un récit de capacité installée modeste mais réelle. Elle a un AS enregistré, un /23 IPv4 routé divisé en deux /24, un /32 IPv6, des sites web publics dans le même bloc IPv4, une liste d’échange PeeringDB, une offre de boucle locale et des produits VPS/hébergement/messagerie. C’est plus concret qu’un simple revendeur sans périphérie identifiable. C’est suffisant pour justifier l’intérêt des clients.

La capacité utilisable est la question la plus difficile. Un produit VPS peut promettre des ressources dédiées et un stockage NVMe, mais les pages publiques ne divulguent pas combien d’hyperviseurs existent, comment le stockage est répliqué, si les sauvegardes clients sont hors rack ou hors site, combien de machines de rechange sont stockées, quelle fraction de la capacité est réservée au basculement, ou si le panneau de contrôle peut fonctionner si le réseau de production tombe en panne.

Un produit de boucle locale peut promettre 1 Gbit/s, 2 Gbit/s ou 3 Gbit/s, mais les pages publiques ne divulguent pas les chemins de fibre, la diversité d’interconnexion, la diversité des opérateurs ou la politique de congestion en cas de panne.

Cette distinction compte en cas de défaillance. La capacité installée est ce qu’un fournisseur vend un jour normal. La capacité utilisable est ce qui reste après une défaillance d’un serveur, d’un routeur, d’un chemin de fibre, d’un fournisseur amont, d’un port d’échange, d’une alimentation électrique, d’une file d’attente de support ou d’un compte de facturation. La capacité récupérable est ce qui peut être restauré dans les limites de tolérance de temps d’arrêt et de perte de données du client. Les clients achètent les deuxième et troisième catégories, que la facture les nomme ou non.

Le modèle amont visible de Media Cloud rend cette distinction plus urgente. Si la plupart des chemins de collecteurs globaux atteignent AS140449 via AS138840, alors le client doit se demander si AS138840 est une dépendance amont unique, un chemin de transit principal, un chemin de serveur de routes, ou une partie d’un mix de transit plus large que les collecteurs publics n’exposent pas complètement. Si la présence OpenIXP/NiCE est à 1 Gbit/s, le client doit se demander si elle est utilisée pour le peering sans règlement, l’accessibilité du serveur de routes, la sauvegarde ou le trafic client critique.

Si PeeringDB ne liste aucune installation, le client doit se demander où se trouve l’équipement de production et comment l’accès physique est géré.

Aucune de ces questions n’implique une faute. Ce sont des questions normales de diligence raisonnable en matière d’infrastructure. Un petit fournisseur peut être excellent s’il est honnête sur ses limites, teste la reprise et donne aux clients des voies de sortie réalisables. Un grand fournisseur peut être fragile s’il cache un point de défaillance partagé. Les preuves publiques pour Media Cloud sont suffisamment solides pour formuler les questions initiales, mais pas suffisamment solides pour les clore.

Le support et la facturation font partie de l’infrastructure

Media Cloud vend ses produits via une boutique nécessitant une connexion, des liens de contact et des boutons WhatsApp. Le pied de page listesupport@mediacloud.idsur la boutique etsupport@mci.net.idsur le site d’entreprise, tandis que mci.net.id expose support.mci.net.id à 103.152.240.243. Cela donne aux clients plusieurs points d’entrée de support, mais la question de résilience est de savoir si ces points d’entrée sont suffisamment indépendants pendant un incident.

Le support est une infrastructure car il transforme la détection en réparation. Si un VPS tombe en panne, le client a besoin de plus qu’un accusé de réception générique. Il a besoin d’une personne responsable qualifiée, d’un diagnostic, d’une voie de restauration estimée et d’un moyen de récupérer les données si la restauration dépasse le délai du client. Si une boucle locale tombe en panne, le client doit savoir si Media Cloud peut envoyer un technicien, si un partenaire contrôle le dernier kilomètre, et si le même circuit porte le portail de support.

Si la facturation bloque un compte, le client a besoin d’une voie d’escalade qui peut séparer le statut commercial de l’accès d’urgence aux données.

Les conditions d’utilisation rendent le statut du compte et du paiement opérationnellement pertinent. Les prix peuvent changer; le non-paiement peut entraîner une suspension ou une résiliation; les clients sont responsables du maintien de la sécurité du compte; Media Cloud peut suspendre ou résilier l’accès en cas de violation. Ces clauses sont standard, mais elles montrent que le plan de contrôle n’est pas purement technique. Un domaine, un plan d’hébergement, une boîte aux lettres ou un VPS peuvent tomber en panne à cause d’une condition administrative autant que d’une condition matérielle.

Les produits de messagerie rendent cela encore plus visible. Les pages de messagerie décrivent l’assistance à la migration, le dépannage, le webmail, l’anti-spam, l’anti-virus, les signatures DKIM, les sauvegardes automatiques, les fonctions de traçage des courriels et les journaux d’audit. Si ceux-ci font partie du processus commercial d’un client, la reprise doit inclure l’exportation de la boîte aux lettres, la continuité DNS, la continuité DKIM/SPF/DMARC, l’accès aux archives et les preuves de support. Il ne suffit pas de dire « la messagerie est hébergée ».

Le client doit savoir ce qui se passe lorsque le produit de messagerie ou sa dépendance de plateforme externe échoue.

Pour Media Cloud, l’acheteur devrait demander un manuel de procédure de support avant de déplacer des charges de travail critiques. Qui prend les appels urgents? Existe-t-il une escalade téléphonique pour une panne de boucle locale ou de VPS? Les membres du personnel de support sont-ils autorisés à déplacer des charges de travail ou seulement à créer des tickets? Les files d’attente de compte, de facturation et d’abus sont-elles séparées de la réponse aux incidents?

À quelle vitesse l’entreprise peut-elle fournir une exportation complète du disque VPS, des fichiers du site web, du contenu de la boîte aux lettres, de la zone DNS et du code d’autorisation de domaine si le client décide de partir?

Le principal risque client est la concentration

La commodité de Media Cloud est aussi son risque. Un client peut plausiblement acheter le domaine, le site web, l’hébergement, le VPS, le certificat SSL, la messagerie professionnelle et la connectivité dédiée auprès de la même famille de marques. Cela peut réduire la gestion des fournisseurs pour une petite entreprise. Cela peut aussi transformer un incident de fournisseur en une défaillance composée: le renouvellement du DNS, l’émission du certificat, l’hébergement web, l’accessibilité du VPS, l’accès à la messagerie et la connectivité locale peuvent tous nécessiter la même équipe de support ou la même relation de compte.

La version infrastructure de la concentration est similaire. Si la périphérie visible dépend fortement d’AS138840, si la surface d’échange est une seule liste OpenIXP/NiCE, si la production se trouve dans une installation non divulguée, et si le chemin de support est lié au même réseau, alors un seul problème opérationnel peut affecter plusieurs couches. Les preuves publiques ne prouvent pas que tous ces points uniques existent, mais elles ne les infirment pas non plus. Les enregistrements visibles sont suffisants pour exiger une réponse.

Les clients devraient tester la concentration de quatre manières. Premièrement, séparer l’identité et le DNS de l’hébergement. Le domaine peut-il être transféré rapidement? Les enregistrements DNS peuvent-ils être exportés? Les enregistrements de zone sont-ils accessibles pendant une panne d’hébergement? Deuxièmement, séparer le calcul de la sauvegarde du stockage. Le client peut-il récupérer un VPS ou un site web chez un autre fournisseur sans attendre que Media Cloud reconstruise l’hôte d’origine? Troisièmement, séparer la connectivité de l’hébergement d’applications.

Si la boucle locale tombe en panne, le client peut-il joindre le service hébergé via un autre fournisseur d’accès? Quatrièmement, séparer le support de la plateforme affectée. Si le portail de service est en panne, existe-t-il un canal d’escalade indépendant?

Le seuil de remboursement de la boucle locale devrait concentrer les esprits. Un service interrompu pendant plus de sept jours consécutifs est bien au-delà de la tolérance de nombreuses charges de travail professionnelles. Un client qui ne peut pas fonctionner pendant une semaine ne devrait pas compter sur la politique de remboursement comme plan de continuité. Il devrait exiger un basculement, des sauvegardes testées, un accès alternatif et des conditions d’escalade écrites avant d’acheter.

C’est la conclusion la plus pratique du dossier public. Media Cloud ressemble à un fournisseur opérationnel authentique avec un réseau identifiable. Cela vaut la peine d’être évalué. Les mêmes preuves montrent pourquoi l’évaluation doit aller au-delà de la page produit: un client a besoin de preuves de diversité, de restauration et de sortie.

Ce qu’un acheteur sérieux devrait demander ensuite

Un acheteur sérieux devrait commencer par la périphérie de routage. Demander à Media Cloud quels services utilisent AS140449, quels préfixes sont attribués aux pools VPS ou d’hébergement clients, et si des services clients se trouvent derrière d’autres fournisseurs. Demander si des ROA seront publiés pour 103.152.240.0/24, 103.152.241.0/24 et 2406:38c0::/32, et qui maintient les objets de route IRR.

Demander si AS138840 est le transit principal, un transit de secours, une contiguïté de serveur de routes ou une autre relation, et s’il existe un deuxième chemin de transit indépendant avec une capacité payée suffisante pour transporter le trafic client en cas de défaillance.

Ensuite, demander le modèle d’installation. Quel(s) centre(s) de données hébergent les produits VPS et d’hébergement? Les racks sont-ils possédés, loués ou sous-loués? Y a-t-il des alimentations électriques séparées, des routeurs séparés, des pare-feu séparés et des entrées de fibre séparées? OpenIXP/NiCE est-il utilisé pour le trafic client critique, et le port d’échange de 1 Gbit/s a-t-il une surveillance de la congestion?

Si PeeringDB ne liste aucune installation, est-ce parce que l’entreprise choisit de ne pas divulguer, parce que le réseau est fourni via un partenaire, ou parce que les charges de travail des clients ne sont pas placées dans une installation d’interconnexion publique?

Troisièmement, demander des tests de reprise. Quand a eu lieu la dernière restauration de disque VPS? Combien de temps a-t-elle pris? A-t-elle été restaurée sur le même hôte, sur un autre hôte dans la même installation, ou dans un emplacement différent? Comment les sauvegardes d’hébergement WordPress et Sitejet sont-elles stockées? Un client peut-il tester une exportation sans annuler le service? La messagerie est-elle sauvegardée de manière à ce que le client puisse la récupérer? Les clés DKIM, les zones DNS, les certificats et les archives de boîtes aux lettres sont-ils inclus dans un package de sortie?

Quatrièmement, demander les limites du support. Quel est le chemin d’incident majeur pour les services VPS, hébergement, domaine, messagerie, SSL et boucle locale? Quelle méthode de contact reste disponible si mci.net.id ou mediacloud.id est inaccessible? Le support WhatsApp crée-t-il un ticket formel? Y a-t-il des temps de réponse et de restauration définis? Quels événements génèrent des notifications clients avant le début de la maintenance?

Enfin, demander comment les déclarations juridiques et de confidentialité correspondent au placement réel des données. La politique de confidentialité permet le traitement transfrontalier, et les preuves DNS/MX montrent une dépendance à des plateformes mondiales pour certaines parties de l’entreprise. Le client devrait demander où les données personnelles, les journaux, les sauvegardes, les tickets et les enregistrements de facturation sont traités, et si un produit peut être contractuellement conservé en Indonésie.

Ces questions ne sont pas hostiles. Elles sont la manière dont un acheteur transforme le réseau public visible de Media Cloud en une dépendance testée. L’entreprise a suffisamment de preuves publiques pour justifier la conversation. Elle n’a pas encore suffisamment de preuves publiques pour permettre aux clients de la sauter.

Le niveau de preuve

PT Media Cloud Indonesia obtient un niveau de preuve publique Moyen. Le niveau n’est pas un score de qualité pour l’entreprise; c’est un score pour ce que les preuves publiques peuvent soutenir. Du côté positif, l’identité et la surface d’exploitation sont inhabituellement concrètes pour un fournisseur d’hébergement régional. APNIC/IDNIC lie l’entreprise à AS140449, 103.152.240.0/23 et 2406:38c0::/32. RIPEstat a vu trois préfixes actifs annoncés en juillet 2026. Les sites web publics résolvent dans le bloc IPv4 de l’entreprise.

Media Cloud fait la publicité d’un ensemble spécifique de produits: domaines, hébergement, VPS, SSL, messagerie, services web et connectivité de boucle locale. PeeringDB liste le réseau et un rattachement OpenIXP/NiCE.

Les préoccupations de déclassement concernent les preuves de résilience. Les preuves publiques ne nomment pas d’installation de production. PeeringDB ne liste aucune entrée d’installation. La validation de l’origine de route a renvoyé « unknown » pour les préfixes vérifiés. Les chemins BGP visibles sont fortement associés à AS138840, et l’objet de route IPv6 décrit une route client HSP Global enregistrée par procuration.

Les propres conditions de Media Cloud indiquent que les services peuvent être interrompus par un dysfonctionnement d’équipement, une maintenance, une réparation, une défaillance de liaison télécom, des attaques hostiles, une congestion et d’autres causes. La politique de remboursement suggère que certains recours pour les services internet sont cadrés autour d’une interruption prolongée continue plutôt que d’un temps d’arrêt opérationnel court.

Cette combinaison soutient une conclusion claire: Media Cloud est un véritable fournisseur indonésien de services hébergés et de connectivité avec un réseau visible, mais les clients ne devraient pas traiter le réseau visible comme une preuve de résilience cloud multi-sites. La voie de diligence raisonnable appropriée est de vérifier l’emplacement des installations, la diversité de transit, les contrôles d’origine de route, les tests de sauvegarde et de restauration, l’escalade du support, les règles de continuité de facturation et les droits d’exportation de données.

Si ces vérifications sont satisfaisantes, les preuves publiques donnent aux clients quelque chose de solide à surveiller. Si ces vérifications sont absentes, la commodité d’un fournisseur local groupé peut devenir une dépendance concentrée.