Le réseau de Macrohosting est visible; son assurance service n'est pas encore complète

Résumé

• Le nom Macrohosting relie LACNIC, CABASE et le site web du fournisseur à Nicolas Lagunas Turczyn et à une opération d'hébergement argentine. Les pages publiques examinées n'identifient pas de contrepartie constituée séparée ou de numéro de taxe, donc un acheteur a encore besoin de l'identité contractuelle exacte.
• AS265694 a visiblement annoncé une allocation IPv4 de 1 024 adresses via trois annonces de route se chevauchant le 15 juillet 2026. Les 326 collecteurs IPv4 inclus l'ont vu, et les routes observées étaient valides RPKI; c'est une preuve réseau significative, pas une preuve de disponibilité d'application, de propriété de serveur ou de qualité de sauvegarde.
• Un client peut sélectionner hébergement, VPS, email, domaines et services gérés via un portail de compte en direct. Cependant, un texte de sécurité générique, un texte de témoignage exemple, une base de connaissance publique vide et une route de statut qui mène à la connexion rendent la couche d'assurance publique plus faible que la couche de commande.
• L'enregistrement argentin, les points de contact à Buenos Aires et la présence à AR-IX n'établissent pas la résidence des données. L'approvisionnement devrait lier chaque service à une contrepartie légale, une installation, un réseau d'origine, un emplacement de sauvegarde, un calendrier de support, un objectif de restauration et un recours avant de traiter la marque comme une assurance opérationnelle.

Le nom relie plusieurs enregistrements, mais pas en un contrat complet

L'entrée d'annuaire BTWcommence par une chaîne d'identité inhabituelle: le nom complet d'une personne suivi de la marque Macrohosting entre parenthèses. Cette forme n'est pas simplement une convention d'annuaire.L'enregistrement de LACNIC pour AS265694nomme le déclarant comme Nicolas Lagunas Turczyn(MACROHOSTING), identifie Nicolas Lagunas Turczyn comme contact administratif, technique et abus, et enregistre l'allocation du système autonome le 31 mars 2017.

Il y a des liaisons utiles en dehors du registre de numéros. Lesite web de Macrohostingpublie une adresse de contact à Buenos Aires et un numéro de téléphone se terminant par 3147-0978. Le numéro correspond au numéro central dans l'enregistrement de LACNIC, malgré des différences de format. CABASE, la chambre internet argentine,liste Lagunas Turczyn Nicolas (Macrohosting)parmi ses membres sous hébergement et housing. Ensemble, ces enregistrements soutiennent une conclusion raisonnable que la personne, la marque, le site web et l'enregistrement réseau appartiennent à la même surface opérationnelle.

Les limites sont tout aussi importantes. LACNIC enregistre la responsabilité des ressources internet; il ne certifie pas une société constituée, un propriétaire effectif, une condition financière ou l'autorité de faire chaque promesse commerciale sur le site web. L'avis légal du site donne le nom Macrohosting, l'adresse, le téléphone et l'email de contact, mais la page examinée ne mentionne pas de forme juridique, d'identifiant fiscal ou de numéro d'enregistrement. Le site web donne maintenant une adresse sur Avenida de los Lagos, tandis que l'enregistrement LACNIC donne Avenida Gaona.

Un changement d'adresse, des locaux commerciaux séparés ou un enregistrement plus ancien pourraient expliquer la différence. Les preuves publiques ne choisissent pas entre ces explications.

Cela signifie que la marque est traçable sans être encore complète contractuellement. Un client professionnel devrait demander que le formulaire de commande et la facture indiquent le nom légal, le numéro de taxe, l'adresse de notification et la personne autorisée à engager le fournisseur. Il devrait aussi dire si Nicolas Lagunas Turczyn contracte en tant qu'individu, via une société, ou pour le compte d'une autre entité. Ce n'est pas de la paperasse déconnectée de la fiabilité. La réponse détermine qui doit retourner les données, émettre des crédits, répondre à un avis légal et financer la restauration après un incident grave.

Un catalogue commandable est une preuve de service, pas de chaque promesse

La vitrine de Macrohosting est concise. Elle propose un hébergement partagé avec 20 Go de stockage, cPanel, Imunify360 et SSL inclus, plus deux configurations d'hébergement plus grandes décrites avec des cœurs virtuels, mémoire, stockage, CloudLinux et DirectAdmin. Les boutons de commande mènent à unportail d'administration clientséparé qui expose des catégories pour l'hébergement web, VPS, email d'entreprise, services gérés, domaines, sécurité du site et support. Les clients peuvent choisir entre dollars américains et pesos argentins, créer un compte, passer une commande et entrer dans une zone de support orientée tickets.

C'est une couche d'automatisation reconnaissable. La sélection de produit, la devise, l'enregistrement, la commande et l'accès au compte ont été déplacés dans le logiciel. Pour une petite entreprise achetant de l'hébergement web, cela peut supprimer plusieurs échanges manuels avant le début du service. Cela crée aussi un enregistrement du plan sélectionné et un canal pour les demandes ultérieures. Le catalogue est donc une preuve plus forte qu'une page statique disant seulement que des services cloud sont disponibles.

Mais l'automatisation ne règle pas ce qui se passe après le paiement. Les pages publiques examinées ne mentionnent pas de délai de provisionnement, de politique de contention des ressources, de fenêtre de maintenance, de calendrier de sauvegarde, d'objectif de restauration ou d'objectif numérique de réponse au support. Un compte de cœurs virtuels dit comment un plan est conditionné, pas comment le temps CPU est planifié sous charge. Le SSL inclus dit peu sur la gestion des échecs de renouvellement.

Les noms de produits de sécurité identifient des composants mais n'établissent pas la configuration, la surveillance, la responsabilité des correctifs ou la compensation après un incident.

Le portal comporte aussi des raisons de prudence. Sa page d'accueil dit que plus de 35 000 clients font confiance au service et affiche une garantie de disponibilité à 100 %. Autour de ces affirmations se trouvent des descriptions génériques SiteLock, des noms d'exemple et des textes de témoignage lorem ipsum répétés. La zone d'annonces publiques montre le message standard remerciant l'utilisateur d'avoir choisi WHMCS. Ces éléments ressemblent à du contenu de thème fournisseur inachevé plutôt qu'à des preuves spécifiques à l'entreprise.

Ils ne prouvent pas que le service est mauvais; ils signifient que les affirmations concernées ne peuvent pas être utilisées de manière responsable pour prouver qu'il est bon.

Cette distinction compte dans l'approvisionnement logiciel d'entreprise. Un système de facturation et de compte fonctionnel prouve que les transactions peuvent être automatisées. Cela ne prouve pas que les politiques opérationnelles derrière les boutons sont complètes.

Les acheteurs devraient demander une description de service qui convertit chaque fonctionnalité visible en une obligation testable: quand la ressource devient disponible, quelle limite s'applique, comment l'utilisation est mesurée, quels logs peuvent être exportés, quel historique de modification est conservé et comment une action automatisée échouée atteint un opérateur humain.

AS265694 est la preuve opérationnelle la plus forte

L'enregistrement réseau est plus concret que le langage de garantie. LACNIC a directement alloué170.78.136.0/22à Nicolas Lagunas Turczyn(MACROHOSTING) le 28 septembre 2016. Le bloc va de 170.78.136.0 à 170.78.139.255, un total de 1 024 adresses IPv4. La même personne nommée est listée pour la responsabilité administrative, technique et d'abus.

Au 15 juillet 2026,la vue de routage de RIPEstatmontrait AS265694 annonçant activement cet espace d'adresses. Le système était visible pour tous les 326 pairs IPv4 inclus dans la réponse. RIPEstat a compté trois annonces IPv4, aucune annonce IPv6 et deux voisins observés. L'historique d'origine actuel remontait au 1er juillet 2017.

Les trois routes doivent être lues attentivement. L'opérateur a annoncé le 170.78.136.0/22 couvrant et les deux moitiés plus spécifiques, 170.78.136.0/23 et 170.78.138.0/23. Ces routes se chevauchent; elles ne s'additionnent pas pour donner 2 048 adresses distinctes. L'espace alloué et annoncé reste de 1 024 adresses IPv4.L'historique des préfixes de RIPEstatmontrait les trois continûment présents pendant la fenêtre d'observation du 1er au 15 juillet. La validation d'origine de route est revenue valide pour le bloc couvrant et les deux /23 sous une autorisation de route permettant des longueurs jusqu'à /24.

C'est une preuve précieuse. Le réseau n'est pas représenté seulement par un enregistrement dormant. Ses préfixes étaient largement propagés, et un contrôle d'autorisation d'origine était en place. Un client peut surveiller l'ASN et les routes indépendamment de la page marketing du fournisseur. Un rapport d'abus a aussi un chemin de contact nommé dans l'enregistrement faisant autorité.

Les preuves ont encore une limite. Une route visible ne peut pas révéler si un site web, une boîte mail ou un VPS particulier utilise ces adresses. Elle ne mesure pas la perte de paquets, la latence, la capacité de réserve, la disponibilité du serveur ou la réponse aux incidents. La validation RPKI autorise l'origine; elle n'authentifie pas chaque chemin ni ne protège une application de la défaillance.

L'absence d'annonce IPv6 observée est pertinente pour un acheteur qui nécessite IPv6 natif, mais elle devrait être confirmée par rapport au produit commandé plutôt que transformée en affirmation sur chaque réseau privé ou partenaire que le fournisseur pourrait utiliser.

La présence à AR-IX ajoute un indice d'interconnexion local

Macrohosting maintient aussi unprofil réseau PeeringDBpublic. L'enregistrement décrit AS265694 comme un réseau d'entreprise avec une portée Amérique du Sud, du trafic principalement sortant et une politique de peering ouverte. Il a été mis à jour en mars 2026. Son enregistrement d'échange liste un port IPv4 opérationnel à AR-IX CABASE, avec une vitesse annoncée de 10 Gbps et une participation au route-server.

Cette présence d'échange aide à expliquer le rôle local du réseau. Se connecter à AR-IX peut fournir un chemin direct vers d'autres entités plutôt que d'envoyer chaque paquet par le transit amont. Combiné avec l'adhésion à CABASE et les routes actives, c'est un signe convaincant que Macrohosting participe à l'écosystème internet argentin plutôt que de simplement revendre une vitrine étrangère sous un nom local.

Les informations PeeringDB sont des données d'annuaire maintenues par l'opérateur et l'échange, cependant, pas un audit de trafic. Un port d'échange à 10 Gbps ne signifie pas que chaque client reçoit 10 Gbps, que le port n'est pas congestionné aux heures de pointe ou que toutes les destinations l'utilisent. Deux voisins de routage observés n'établissent pas non plus une fibre physiquement diversifiée, des bâtiments séparés ou une alimentation indépendante. La question d'approvisionnement n'est pas simplement de savoir s'il y a plus d'une connexion nommée.

C'est de savoir si le service commandé a des chemins dont les modes de défaillance sont suffisamment indépendants, surveillés et couverts par un accord d'escalade.

Un calendrier réseau utile nommerait le préfixe de service et l'ASN d'origine, le port client ou la limite de shaping, la disponibilité IPv6, les amonts primaire et secondaire, les dépendances d'échange, le traitement DDoS et les preuves utilisées pour mesurer la disponibilité. Il devrait aussi dire qui contacte CABASE, un amont ou une installation lorsque le défaut se trouve en dehors de l'équipement propre de Macrohosting. Les enregistrements de ressources publiques identifient le réseau. Le calendrier identifierait le service que le client achète réellement à partir de celui-ci.

Les preuves réseau argentines ne déterminent pas la localisation des données

Presque chaque indice d'identité publique pointe vers l'Argentine: le pays LACNIC, les contacts à Buenos Aires, l'adhésion à CABASE, la portée sud-américaine dans PeeringDB et la connexion AR-IX. Il serait toujours dangereux d'en déduire que toutes les données clients restent en Argentine.

Les pages publiques examinées ne nomment pas de centre de données, d'opérateur d'installation, de ville pour les serveurs, de site de sauvegarde ou de sous-traitant cloud. Elles ne disent pas si l'hébergement partagé, le VPS, l'email et les services gérés utilisent la même infrastructure. La présence d'échange décrit où les réseaux s'interconnectent; elle ne localise pas un disque. Une adresse IP d'origine locale peut servir une charge de travail dans un endroit tandis que les données de compte, les pièces jointes de tickets, le DNS, la télémétrie de sécurité ou les sauvegardes sont traités ailleurs.

La page de politique de confidentialité maigre aggrave le problème. Elle n'offre aucune explication publique des catégories de données, des sous-traitants, de la conservation, des transferts internationaux ou de la suppression. Pour un individu achetant un site web à faible risque, cela peut être une raison de poser une question courte. Pour une entreprise traitant des données d'employés, de clients ou réglementées, c'est une partie manquante de la spécification de service.

La localité devrait donc être cartographiée par classe de données. Le client a besoin de l'emplacement primaire et de récupération pour les fichiers hébergés, les bases de données, les boîtes mail, les instantanés et les sauvegardes. Il a aussi besoin des emplacements et des règles de conservation pour l'identité du compte, les factures, les messages de support, les logs d'accès, la surveillance et les résultats de malware. Si un service tiers de sécurité, de panneau de contrôle, de DNS ou de paiement reçoit des données, son rôle devrait être indiqué.

Ce n'est qu'alors qu'un fournisseur argentin et un réseau argentin peuvent devenir une position de résidence basée sur des preuves.

Le support existe comme canal; la responsabilité a besoin de termes de service

Macrohosting expose plusieurs façons d'entamer une conversation. Le site principal a un formulaire de contact et un numéro de téléphone. Le portail a un formulaire de contact public, une inscription et une connexion, plus des entrées de menu pour les tickets, les annonces, une base de connaissance et l'état du réseau. Ces éléments montrent que le support client fait partie du service prévu, pas une réflexion totalement absente.

Ce qu'ils ne montrent pas, c'est l'engagement de travail derrière l'interface. La base de connaissance n'a retourné aucun article public lors de l'examen. La route d'état du réseau a mené à une connexion client plutôt qu'à un historique de composants public. Les pages examinées n'ont pas divulgué les heures de support, les niveaux de gravité, les objectifs d'accusé de réception, les objectifs de restauration, les contacts d'escalade ou les recours en cas de panne. Un bouton de ticket peut organiser les demandes, mais il ne peut pas à lui seul garantir que le bon ingénieur répondra avant l'expiration de la fenêtre de récupération du client.

C'est là qu'un fournisseur plus petit peut soit créer soit perdre de la valeur par rapport à une alternative hyperscale. Un opérateur local peut offrir une langue directe, un contexte local et un accès à quelqu'un qui comprend à la fois le serveur et le réseau. Ces avantages sont opérationnels seulement lorsque les personnes, les heures et l'autorité sont réelles. Le client devrait savoir qui surveille la plateforme en dehors des heures de bureau, qui peut changer une route, qui peut restaurer une sauvegarde, qui peut approuver un accès d'urgence et qui communique lorsqu'une dépendance échoue.

La responsabilité de la sauvegarde mérite sa propre ligne. Aucun document public examiné n'établit que chaque plan inclut des sauvegardes, à quelle fréquence les copies sont faites, combien de temps elles sont conservées ou si la restauration est testée. La capacité de stockage dans un plan n'est pas une promesse de récupération. Un acheteur devrait supposer que la responsabilité reste non résolue jusqu'à ce qu'une commande indique le point de récupération, le temps de récupération, l'emplacement de la copie, l'arrangement de chiffrement, la période de conservation et la cadence des tests de restauration.

Convertir l'empreinte publique en un pack d'assurance

Macrohosting a plus de substance opérationnelle que sa vitrine clairsemée ne le suggère initialement. La personne et la marque réapparaissent dans les enregistrements de ressources faisant autorité. Le bloc IPv4 est directement alloué. Le système autonome a une origine de route de longue durée, visible mondialement, une autorisation d'origine valide, deux voisins observés et une entrée AR-IX opérationnelle. Ce sont des faits utiles et inspectables indépendamment.

La prochaine étape n'est pas d'exiger un site web plus grand. C'est de rendre l'enregistrement commercial aussi précis que l'enregistrement réseau. Avant de placer une charge de travail de production, un acheteur devrait obtenir un document qui nomme la contrepartie légale et lie le plan sélectionné à son installation, sa plage d'adresses, son ASN d'origine, son modèle d'amont et ses limites de ressources client. Il devrait définir la maintenance, la surveillance, la gravité des incidents, la couverture de support, l'escalade, la restauration, les crédits et l'assistance à la résiliation.

Un deuxième calendrier devrait cartographier les données et la récupération. Il devrait localiser les données primaires, les sauvegardes, les enregistrements de compte, les tickets et la télémétrie de sécurité; identifier les sous-traitants; fixer les règles de conservation et de suppression; et enregistrer un chemin d'exportation et de restauration testé. Un troisième devrait allouer le travail humain: qui corrige le système d'exploitation, renouvelle les certificats, surveille l'épuisement des ressources, répond aux alertes de malware, change les routes et contacte les fournisseurs externes.

Ce pack ne remplacerait pas la valeur des preuves réseau publiques de Macrohosting. Il permettrait aux preuves de faire leur travail propre. AS265694 prouve un rôle opérationnel visible sur Internet. Le catalogue prouve que les services peuvent être commandés. Les surfaces de contact prouvent que les demandes peuvent être soumises. L'assurance opérationnelle commence lorsque ces faits sont joints à des réponses exécutoires et spécifiques au produit sur l'identité, le contrôle, la localité, la récupération et la réponse humaine.