Résumé
- PT Media Cloud Indonesia dispose de preuves d'exploitation publiques plus solides que de nombreux petits hébergeurs: les enregistrements APNIC/IDNIC le lient à 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 durant la fenêtre de vérification de juillet 2026.
- La société commercialise une offre groupée large 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 affiche des forfaits de bande passante dédiée de 1 Gbit/s, 2 Gbit/s et 3 Gbit/s.
- La réserve sur la résilience est tout aussi concrète. PeeringDB répertorie un rattachement d'échange OpenIXP/NiCE et aucun enregistrement d'installation pour le réseau; les données de voisins RIPEstat sont dominées par AS138840, et l'objet de route IPv6 de RADB décrit une route client HSP Global enregistrée par proxy. Ce sont des preuves d'interconnexion visibles, pas une preuve de capacité multisite indépendante.
- Les propres conditions d'utilisation et la politique de remboursement de Media Cloud rendent le chemin de défaillance physique visible: les services peuvent devenir inaccessibles en raison de dysfonctionnement d'équipement, de maintenance, de réparation ou de remplacement, d'interruption de liaisons télécom, d'attaques hostiles, de congestion ou d'autres pannes; le remboursement des services Internet est conditionné à plus de sept jours continus de coupure ou d'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 concernant l'emplacement des installations, la capacité de réserve, la diversité de transit, la restauration 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 institutionnel orienté connectivité àmci.net.id, qui fait la promotion de solutions de connectivité en boucle locale et FTTH et oriente 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 à ses clients de lui confier à la fois leur présence Internet de base et des services structurants en infrastructure.
Cette confiance se heurte à des contraintes bien réelles. Un VPS est une machine virtuelle, mais il s'exécute sur du calcul, du stockage, de l'énergie et du refroidissement physiques. La « bande passante illimitée » est une expression commerciale, mais les paquets traversent toujours des ports, des routeurs, des filtres, des fibres optiques, des contrats de transit et des tissus d'échange. Une promesse de « support 24h/24 et 7j/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 défaillant.
L'offre de boucle locale est encore plus directe: elle dépend de l'accès du dernier kilomètre, d'un point de raccordement, d'un chemin amont, de techniciens d'astreinte et d'une règle commerciale sur ce qui se passe quand le circuit reste coupé.
Les preuves publiques commencent par la couche des ressources de numéros. L'enregistrement RDAP d'APNIC/IDNIC pourAS140449répertorie MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, « Internet Service Provider » (fournisseur d'accès 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 de numérotation Internet directement visibles.
L'entreprise héberge également ses sites publics à l'intérieur de cette empreinte. Une vérification DNS durant cette recherche a résolu à la fois 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 porte d'entrée 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 vérifiable l'affirmation d'infrastructure.
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 public peuvent indiquer 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 volontaire d'échange répertorie un port. Elles ne peuvent pas montrer le serveur de rechange dans la baie, le contrat d'installation, le processus de sauvegarde des clients ou la personne habilitée à remplacer le matériel après minuit. Cette lacune est le cœur de l'article.
L'offre de produits annoncée va au-delà d'une simple page de VPS
Les pages produit 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 sites, de la messagerie, des certificats SSL et des services VPS. Elle fait la promotion de domaines en.id et.com, de services de revendeur et de gros volumes, et d'une tuile « Meilleur hébergement VPS Cloud » qui pointe vers le produit VPS. C'est important 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 aux lettres, un constructeur de sites et un VPS auprès du même fournisseur, puis découvrir lors d'un incident que la dépendance technique et la dépendance liée au compte sont étroitement liées.
Lapage VPSest l'affirmation de capacité hébergée la plus claire. Elle commercialise « VPS Indonesia », décrit le service comme « VPS Indonesia 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 aussi 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 une dépendance commerciale: les clients n'achètent pas seulement de l'espace d'adressage; ils attendent du calcul, du stockage, une installation logicielle, des contrôles de sécurité et une marge réseau suffisante pour garder les applications joignables.
Les pages d'hébergement ajoutent une couche supplémentaire.Hébergement Sitejetprésente un hébergement groupé avec un constructeur de site et met en avant la protection DDoS, cPanel, Softaculous et des installations en un clic.Hébergement WordPressutilise le même langage de fiabilité et de fonctionnalités même si le tableau des forfaits était indisponible 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 sites et l'hébergement WordPress dépendent tous de panneaux de contrôle, de statuts de licence, de pratiques de stockage et de sauvegarde. Ce sont des systèmes opérationnels, pas de simples noms de produits statiques.
La messagerie étend encore la dépendance.Hébergement Emailannonce une messagerie professionnelle avec une garantie de disponibilité de 99,9 %, des domaines personnalisés, la sécurité, la surveillance, un support 24h/24 et 7j/7 et une assistance à la configuration, la migration et le dépannage.Email Professionneldécrit 8 Go par boîte aux lettres, le webmail, l'anti-spam, l'antivirus, les signatures DKIM, les sauvegardes automatiques, les fonctionnalités de trace-mail et les journaux d'audit. Les enregistrements MX ajoutent une nuance: mci.net.id utilise la protection de messagerie Microsoft, tandis que mediacloud.id pointe vers les échangeurs de messagerie aspmx de Google. Ce n'est pas contradictoire; cela montre que certaines parties de l'entreprise s'appuient sur des plateformes de messagerie externes, même lorsque les sites web publics résident 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 en plus des serveurs: enregistrement de domaines, transfert, identité.id, certificats, production de sites et identité de boîte aux lettres. Un client qui concentre ces services peut y gagner en commodité, mais crée également un problème de récupération. Si la facturation, la vérification d'identité, le support ou le panneau de contrôle bloque, plusieurs fonctions métier indépendantes peuvent bloquer simultanément.
La tarification de la boucle locale rend explicite la question des baies 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 annonce des « Solutions de connectivité en boucle locale et FTTH » et décrit « une bande passante dédiée haut débit pour des communications professionnelles fiables ». La page répertorie des forfaits de boucle locale à 10 000 000 Rp par mois pour 1 Gbit/s, 20 000 000 Rp par mois pour 2 Gbit/s et 30 000 000 Rp 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 performante, une faible latence, une intégration évolutive et un support local 24h/24 et 7j/7.
Ces affirmations ne valent pas divulgation publique d'installation. Elles font cependant passer l'analyse d'un simple hébergement web à une infrastructure physique. Un service de boucle locale nécessite un chemin d'accès au client, un point de raccordement, un chemin de collecte, un routeur, un modèle de support et 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 sur le 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 dispatch 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 des adresses publiques doit également être traitée avec prudence. Les enregistrements de ressources de numéros d'APNIC/IDNIC donnent une adresse au Prudential Center à Jakarta Sud. Les pieds de page publics actuels de Media Cloud orientent les lecteurs vers Epicentrum Walk 3ème étage Unité A306-307, Jl. HR Rasuna Said, Kuningan, Jakarta Sud. Les deux peuvent être vrais de différentes manières: l'une peut être une adresse de registre, l'autre un bureau actuel ou un emplacement de support, et aucune n'identifie nécessairement où sont hébergées les charges de travail ou les routeurs des clients.
La distinction est importante car les clients confondent souvent une adresse de contact d'entreprise avec une adresse d'installation. Ils ne 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 frontière de service ou le site de reprise. C'est normal pour une page commerciale 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 aboutit dans un hôtel de télécommunications distinct. 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 les deux circuits partagent des gaines, des entrées de bâtiment, des panneaux de brassage ou une seule passerelle amont.
Il ne s'agit pas de dire que l'offre de boucle locale de Media Cloud est faible. Il s'agit de 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 défaille. 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 concentre simplement la panne.
AS140449 annonce actuellement un petit ensemble de préfixes cohérent
Les preuves de routage sont plus claires que les preuves du site institutionnel. Lavue d'ensemble d'AS140449 par RIPEstata identifié le détenteur comme « MEDIACLOUD-AS-ID - PT Media Cloud Indonesia » et a montré que l'AS était annoncé durant la vérification de juillet 2026. Lavue des préfixes annoncésde RIPEstat répertoriait 103.152.240.0/24, 103.152.241.0/24 et 2406:38c0::/32 comme visibles sur la fenêtre du 27/06/2026 au 11/07/2026. Cela signifie que le /23 enregistré est opérationnellement divisé en deux annonces IPv4 /24 visibles, tandis que l'allocation IPv6 est annoncée en /32.
Cette configuration est cohérente avec un petit opérateur plutôt qu'un cloud à très grande échelle. 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 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 capacité utile n'est pas le nombre d'adresses existantes, mais le nombre de charges de travail pouvant être hébergées, déplacées, restaurées et supportées lorsque quelque chose tombe en panne.
L'historique de routagede RIPEstat ajoute une 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 ayant persisté pendant des années.
Mais l'historique inclut également des périodes de visibilité plus faible. 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 de collecteur, un problème en 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 de panne spécifique sans preuve de l'opérateur ou du client.
Sa valeur est plus étroite: il montre que la bordure de route publique est suffisamment observable pour être surveillée et que les clients peuvent 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 mondiaux 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 mondiaux plus en amont, mais l'adjacence immédiate répétée à AS138840 est la dépendance qui importe. Un client n'a pas besoin de chaque détail de collecteur de routes; il a besoin de savoir si la périphérie de Media Cloud peut survivre à une perte ou une congestion du chemin amont immédiat.
L'histoire visible en amont 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 l'existence de contrats, mais elles aident à expliquer le voisinage de routage.
PeeringDB ajoute une vue d'interconnexion volontaire. Sarequête API réseau pour AS140449répertorie « PT Media Cloud Indonesia », alias « Mediacloud », site webhttps://mci.net.id, type d'info « Enterprise », prise en charge IPv6, une politique générale ouverte, un compteur IX à 1 et un compteur d'installation à 0. Larequête netixlanassociée répertorie OpenIXP / NiCE, un port à 1 Gbit/s, l'adresse IPv4 43.252.146.141, l'adresse IPv6 2001:7fa:f::457 et un statut opérationnel. Larequête netfacne retourne aucune entrée d'installation.
La lecture la plus solide est pratique: Media Cloud a un rattachement d'échange visible chez OpenIXP/NiCE et un voisinage de routage public où AS138840 est le chemin principal vu par les collecteurs. La lecture plus faible serait d'inférer une architecture de résilience complète à partir de ces champs. PeeringDB est maintenu par les opérateurs et volontaire. Un port d'échange à 1 Gbit/s ne prouve pas que tout le trafic client peut s'écouler via l'échange en cas de problème de transit.
Un compteur d'installation à 0 ne prouve pas que l'entreprise n'a pas de baies; cela signifie simplement que PeeringDB ne répertorie pas d'entrées d'installation pour le réseau. Une adjacence amont observée ne prouve pas si une liaison est du transit, du peering, une sauvegarde ou un chemin de serveur de routes, sauf si cela est étayé par la documentation de l'opérateur.
Les objets de route RADB renforcent la même prudence. Une requête RADB pour AS140449 a retourné des objets de route pour 103.152.240.0/24 et 103.152.241.0/24 avec l'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 proxy pour une route client HSP Global exportée sous l'AS d'origine Media Cloud, maintenue par MAINT-AS138840.
Cette formulation rend centrale la question du contrat fournisseur: si la route IPv6 dépend de la maintenance de l'objet de route par HSP ou de l'arrangement amont, les clients doivent savoir qui peut corriger l'objet, qui peut modifier les filtres et ce qui se passe en cas de défaillance du contrat amont ou du canal de support.
L'assurance d'origine de route reste incomplète
La validation d'origine de route n'est pas un test de résilience complet, mais c'est un contrôle significatif. Il 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 retourné « unknown » (inconnu) sans ROA validante dans la vue vérifiée. RADB a également montré un état de validation d'origine RPKI comme « not_found » (non trouvé) 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 pas trouvé de ROA autorisant. Le risque pratique est que les réseaux appliquant des politiques de routage strictes puissent traiter les routes inconnues différemment des routes valides, ou qu'un futur détournement de route ou une mauvaise configuration soit plus difficile à distinguer 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-elle l'intention de publier des ROA pour ses préfixes annoncés, et peut-elle démontrer que les objets de route et les ROA sont maintenus par la partie ayant la responsabilité opérationnelle?
RPKI ne peut pas non plus prouver la qualité de 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 le matériel rapidement. Cela ne fait que réduire une catégorie de risque de routage. Dans ce cas, l'absence de ROA validantes rend le plan de contrôle public moins complet que le catalogue de produits. Cette lacune est corrigible, mais elle doit être reconnue.
La leçon plus large pour les clients est que la résilience de la capacité hébergée a plusieurs couches. 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 récupération.
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 propres de Media Cloud décrivent le chemin de défaillance
Les pages légales de l'entreprise ne sont pas des schémas techniques peaufinés, mais elles sont révélatrices sur le plan opérationnel. Lesconditions d'utilisation de mediacloud.iddéfinissent les services de manière large 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 des sites web, et que les services Internet peuvent inclure la télévision, la messagerie, la connectivité et les services connexes. Elles précisent également que Media Cloud déploiera des efforts commercialement raisonnables pour fournir le site et les services 24 heures sur 24, 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érants pour des raisons incluant les dysfonctionnements d'équipement, la maintenance périodique, les réparations ou remplacements, les causes échappant à un contrôle raisonnable, l'interruption ou la défaillance des liaisons de télécommunication ou de transmission numérique, les attaques hostiles de réseau, la congestion du réseau et d'autres pannes. Elle indique également que Media Cloud n'a aucun contrôle sur la disponibilité de manière continue ou ininterrompue.
Cette formulation n'est pas inhabituelle; de nombreux fournisseurs utilisent des clauses de non-responsabilité similaires. Ici, cependant, elle donne aux clients une liste concise des catégories de dépendance exactes qu'ils devraient tester.
Lapolitique de remboursementest tout aussi spécifique. Elle indique que les frais d'enregistrement de domaines ne sont généralement pas 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 coupé pendant 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 du quartier local. C'est un seuil opérationnel frappant. Il 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 de coupure 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 vitrine en ligne pendant la panne. Il ne fait que définir un recours commercial.
Un client avec des charges de travail critiques devrait demander des objectifs de niveau de service, une escalation d'incident, une notification proactive, des fenêtres de maintenance, des obligations d'exportation de données et des objectifs de récupération mesurés qui sont distincts de la politique de remboursement.
C'est pourquoi le titre de l'article pointe vers les baies, le transit et les fenêtres de réparation. Les conditions légales 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 de test.
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'adresses en Indonésie. Pour de nombreux clients, en particulier les petites entreprises, cela peut être l'essentiel: un fournisseur local, une langue locale, des attentes de paiement locales et un support pouvant être contacté via les 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 résider sur les adresses de Media Cloud tandis que la messagerie est géré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 registrar et de registre. Une affirmation de mitigation DDoS peut reposer sur un filtrage en amont ou une plateforme tierce.
Chaque couche peut placer les données, les métadonnées ou les 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 sur 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 importe: le fournisseur reconnaît les possibilités de 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 surcette page officielle. La page inclut 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 être accompagné d'une réponse sur l'emplacement: où se trouve l'hôte principal, où se trouvent les sauvegardes, où se trouve l'identité du plan de contrôle, où se trouvent 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 assurance de souveraineté complète.
Capacité installée et 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 à l'intérieur du 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 pur 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 annoncer des ressources dédiées et du stockage NVMe, mais les pages publiques ne divulguent pas combien d'hyperviseurs existent, comment le stockage est répliqué, si les sauvegardes des clients sont hors baie 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 est défaillant.
Un produit de boucle locale peut annoncer 1 Gbit/s, 2 Gbit/s ou 3 Gbit/s, mais les pages publiques ne divulguent pas les itinéraires de fibre, la diversité d'interconnexion, la diversité des opérateurs ou la politique de congestion pendant une panne.
Cette distinction est importante lors d'une défaillance. La capacité installée est ce qu'un fournisseur vend un jour normal. La capacité utilisable est ce qui reste après la 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 la tolérance du client en matière de temps d'arrêt et de perte de données. Les clients achètent les deuxième et troisième catégories, que la facture les nomme ou non.
Le schéma amont visible de Media Cloud rend cette distinction plus urgente. Si la plupart des chemins de collecteurs mondiaux atteignent AS140449 via AS138840, alors le client doit 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 mélange de transit plus large que les collecteurs publics n'exposent pas entièrement. Si la présence OpenIXP/NiCE est à 1 Gbit/s, le client doit demander si elle est utilisée pour du peering sans accord de paiement, pour l'accessibilité du serveur de routes, pour la sauvegarde ou pour le trafic critique des clients.
Si PeeringDB ne répertorie aucun enregistrement d'installation, le client doit 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 d'infrastructure. Un petit fournisseur peut être excellent s'il est honnête sur ses limites, teste la récupération et donne aux clients des chemins 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 assez solides pour dresser les premières questions, mais pas assez 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 répertorie[email protected]sur la boutique et[email protected]sur le site institutionnel, 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, le client a besoin de plus qu'un accusé de réception générique. Il a besoin d'un responsable qualifié, d'un diagnostic, d'un chemin de restauration estimé et d'un moyen de récupérer les données si la restauration manque la date limite du client. Si une boucle locale échoue, le client doit savoir si Media Cloud peut intervenir, si un partenaire contrôle le dernier kilomètre, et si le même circuit transporte le portail de support.
Si la facturation bloque un compte, le client a besoin d'un chemin d'escalade pouvant séparer l'état commercial de l'accès aux données d'urgence.
Les conditions d'utilisation rendent l'état 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 forfait d'hébergement, une boîte aux lettres ou un VPS peut échouer à cause d'une condition administrative aussi bien que d'une condition matérielle.
Les produits de messagerie rendent cela encore plus visible. Les pages de messagerie décrivent l'aide à la migration, le dépannage, le webmail, l'anti-spam, l'antivirus, les signatures DKIM, les sauvegardes automatiques, les fonctionnalités de trace-mail et les journaux d'audit. Si ceux-ci font partie du processus métier d'un client, alors la récupération doit inclure l'exportation des boîtes 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 que « la messagerie est hébergée ».
Le client doit savoir ce qui se passe lorsque le produit de messagerie ou sa dépendance à une plateforme externe est défaillant.
Pour Media Cloud, l'acheteur devrait demander un manuel de procédures de support avant de déplacer des charges de travail critiques. Qui reçoit les appels urgents? Y a-t-il une escalade téléphonique en cas de panne de boucle locale ou de VPS? Le personnel de support est-il habilité à déplacer les 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 d'un VPS, des fichiers d'un site web, du contenu d'une 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, de manière plausible, acheter le domaine, le site web, l'hébergement, le VPS, le certificat SSL, la messagerie professionnelle et la connectivité dédiée de la même famille de marques. Cela peut réduire la gestion des fournisseurs pour une petite entreprise. Cela peut également transformer un incident fournisseur en une panne composée: le renouvellement DNS, l'émission de 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 réfutent 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éparez 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éparez le calcul de la sauvegarde de 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éparez la connectivité de l'hébergement applicatif.
Si la boucle locale tombe en panne, le client peut-il atteindre le service hébergé via un autre fournisseur d'accès? Quatrièmement, séparez 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 focaliser les esprits. Un service coupé pendant plus de sept jours continus est bien au-delà de la tolérance de nombreuses charges de travail commerciales. 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 véritable fournisseur opérationnel 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 bordure de routage. Demandez à Media Cloud quels services utilisent AS140449, quels préfixes sont attribués aux pools VPS ou d'hébergement client, et si des services clients se trouvent derrière d'autres fournisseurs. Demandez si des ROA seront publiées pour 103.152.240.0/24, 103.152.241.0/24 et 2406:38c0::/32, et qui maintient les objets de route IRR.
Demandez si AS138840 est le transit principal, un transit de secours, une adjacence de serveur de routes ou une autre relation, et s'il existe un deuxième chemin de transit indépendant avec une capacité payante suffisante pour acheminer le trafic client en cas de défaillance.
Demandez ensuite le modèle d'installation. Quel(s) centre(s) de données héberge(nt) les produits VPS et d'hébergement? Les baies sont-elles détenues, louées ou revendues? 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 critique des clients, et le port d'échange à 1 Gbit/s dispose-t-il d'une surveillance de congestion?
Si PeeringDB ne répertorie aucune installation, est-ce parce que l'entreprise choisit de ne pas la 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, demandez les tests de récupération. Quand a eu lieu la dernière restauration d'un 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 sur un autre emplacement? Comment les sauvegardes des hébergements 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, demandez les limites du support. Quel est le chemin d'incident majeur pour les services VPS, d'hébergement, de domaine, de messagerie, SSL et de 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? Existe-t-il des temps de réponse et de restauration définis? Quels événements génèrent des notifications aux clients avant le début de la maintenance?
Enfin, demandez comment les déclarations légales et de confidentialité correspondent au placement réel des données. La politique de confidentialité autorise le traitement transfrontalier, et les preuves DNS/MX montrent une dépendance aux 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 conservé à l'intérieur de l'Indonésie par contrat.
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 assez de preuves publiques pour permettre aux clients de l'éviter.
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 se résolvent dans le bloc IPv4 de l'entreprise.
Media Cloud annonce un ensemble spécifique de produits: domaines, hébergement, VPS, SSL, messagerie, services web et connectivité en boucle locale. PeeringDB répertorie le réseau et un rattachement OpenIXP/NiCE.
La dégradation concerne les preuves de résilience. Les preuves publiques ne nomment pas d'installation de production. PeeringDB ne répertorie aucune entrée d'installation. La validation d'origine de route a retourné « inconnu » 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 proxy.
Les propres conditions de Media Cloud indiquent que les services peuvent être interrompus en cas de dysfonctionnement d'équipement, de maintenance, de réparation, de défaillance de liaison télécom, d'attaques hostiles, de congestion et d'autres causes. La politique de remboursement suggère que certains recours pour les services Internet sont formulés autour d'une coupure continue prolongée plutôt que d'un court temps d'arrêt opérationnel.
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 multisite. La voie de diligence appropriée consiste à vérifier le placement 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 des 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.