Mark Anthony Constable for Spiderweb Cloud and vend de la capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• Mark Anthony Constable n'est pas une étiquette vide dans une base de données réseau. Le registre ABN australien pour l'ABN 69 851 855 459 nomme CONSTABLE, MARK ANTHONY comme un individu actif ou travailleur indépendant depuis le 1er septembre 2004, avec des noms commerciaux incluant RentaNet et Spiderweb Cloud.
• La surface commerciale actuelle est réelle mais petite. Spiderweb vend de l'hébergement WordPress et email, un plan « pay-as-you-grow », du design web et du support Linux, tandis que RentaNET propose des serveurs Linux gérés, des plans de type conteneur, la gestion de clusters Proxmox, des options basées sur BinaryLane, des heures de support australiennes et une tarification annuelle.
• APNIC enregistre AS153475 comme SPIDERWEBCLOUD-AS-AP avec la description « Mark Anthony Constable for Spiderweb Cloud and » et « RentaNet offering Email and Web hosting services. » RIPEstat, cependant, a montré AS153475 comme non annoncé le 12 juillet 2026, avec zéro préfixes observés et zéro voisins observés.
• APNIC attache également deux blocs IPv4 portables actifs, 203.25.132.0/24 et 203.25.238.0/24, à Spiderweb Cloud. Les deux étaient visibles globalement dans RIPEstat le 12 juillet 2026, mais les deux étaient annoncés par AS133159 de Mammoth Media plutôt que par AS153475.
• La note de preuve réseau est Moyenne avec un abaissement explicite de l'indépendance. Il y a de bonnes preuves publiques d'une opération d'hébergement actuelle d'un travailleur indépendant australien et d'espace d'adressage routé, mais les preuves publiques ne prouvent pas l'emplacement des baies contrôlé par Spiderweb, la diversité physique du transit, l'autorisation d'origine de route, la reprise multi-site, la restaurabilité des sauvegardes ou la capacité de sortie client.

Un petit hébergeur peut être réel sans posséder toute la chaîne

La lecture la plus solide du registre public n'est pas que Spiderweb est un réseau fantôme. C'est que le service orienté client et l'histoire du contrôle réseau se situent à différents niveaux de la pile. Leregistre ABN pour l'ABN 69 851 855 459nomme CONSTABLE, MARK ANTHONY, montre un statut actif depuis le 1er septembre 2004, donne le type d'entité comme individu ou travailleur indépendant, et liste les noms commerciaux MOTD, Spiderweb Cloud, Digital Mail Service et RentaNet. Le même registre place le principal emplacement commercial dans le Queensland 4218 et indique que le statut GST n'est actuellement pas enregistré.

Ce registre légal correspond aux noms de service sur les sites publics.La page d'accueil de Spiderwebpropose de l'hébergement WordPress, de l'hébergement email, du design web et du support Linux, donne une adresse postale à Broadbeach et affiche le même ABN.La page de services de RentaNETdécrit des serveurs Linux gérés, de l'administration de serveurs, du durcissement de sécurité, des composants de serveur de messagerie, de la gestion de clusters Proxmox et du support. Le service est visiblement suffisamment actuel pour inclure un pied de page 2026 et des liens vers un portail client en direct.

La mise en garde importante est qu'un petit hébergeur actif ne possède pas automatiquement chaque élément physique ou réseau sous le service client. Une boîte aux lettres WordPress, un serveur géré ou un plan conteneur est un ensemble de dépendances. Quelqu'un possède ou loue le calcul. Quelqu'un contrôle l'armoire du centre de données ou le compte cloud. Quelqu'un gère le routage amont, le stockage, les supports de sauvegarde, le DNS, les files d'attente de messagerie, la facturation, l'accès au support et les identifiants d'urgence.

La marque qui répond au téléphone peut être responsable envers le client tout en s'appuyant sur des installations et du transit tiers.

Cette limite est courante dans l'hébergement géré, et elle n'est pas un défaut en soi. En fait, utiliser un fournisseur d'infrastructure australien spécialisé peut être plus résilient que d'essayer de tout gérer seul. Mais la limite doit être visible. Les clients doivent savoir si le service est soutenu par un espace d'adressage portable appartenant à Spiderweb, des adresses attribuées par le fournisseur, une infrastructure BinaryLane, un cache Cloudflare, un autre fournisseur VPS ou un mélange.

Ils doivent également savoir quelle partie peut agir lorsqu'une panne nécessite un changement de route, une restauration de stockage, un remplacement d'hôte, une exportation de données ou un remboursement.

Cet article traite donc Spiderweb et RentaNET comme une opération d'hébergement australienne actuelle mais pas comme un opérateur réseau indépendant prouvé. Cette distinction compte car la première affirmation est bien soutenue par des preuves commerciales et de service, tandis que la seconde n'est pas soutenue par le routage public actuel pour AS153475.

L'offre publique est l'hébergement, la messagerie et le support géré

L'offre de Spiderweb est explicitement orientée client. Lapage principale de Spiderwebindique que l'entreprise fournit un hébergement WordPress et email sécurisé et rentable pour les domaines personnels ou professionnels, ainsi que des services de design web et un support par téléphone, SMS ou email. Elle indique que les sites web des clients sont livrés avec WordPress préinstallé et que les installations WordPress, les plugins et les thèmes sont mis à jour chaque semaine. Elle indique également qu'un support de livraison mondial facultatif peut être fourni via Cloudflare tandis que les serveurs web d'origine sont optimisés avec nginx et PHP-FPM.

Le service de messagerie est tout aussi concret. Spiderweb publie les paramètres IMAP pourmail.spiderweb.com.au, avec le port 993 sur SSL pour le courrier entrant et le port 465 sur SSL pour le courrier sortant. La même page indique que le service IMAP sécurisé inclut un filtre anti-spam personnalisé et prend en charge SPF, DKIM, DMARC et DNSSEC. Elle indique également que Spiderweb a l'intention de désactiver le service de messagerie POP d'ici fin 2025, ce qui fait de l'IMAP non seulement une préférence de support mais aussi une exigence de migration pour les clients plus anciens.

Lapage de tarificationdonne un modèle économique bas de gamme. Le plan « pay-as-you-grow » commence à 20 AUD par an pour 1 Go de stockage, puis tarifie les sites web WordPress, les boîtes aux lettres IMAP et le stockage supplémentaire par petites incréments. La page donne des exemples de 60 AUD par an pour un site WordPress, une boîte aux lettres et 1 Go de stockage, 90 AUD par an pour un deuxième site web et domaine, et 112 AUD par an pour une configuration plus lourde de 10 Go. Elle indique également que l'enregistrement de domaine est facturé séparément et que le plan inclut une bande passante non mesurée pour le trafic web et de messagerie normal, avec des tendances de trafic abusif pouvant entraîner une suspension.

Cette tarification en dit long à l'acheteur sur le modèle opérationnel. Ce n'est pas une posture cloud hyperscale. C'est un modèle d'hébergement à petit compte, à support lourd, où le client paie pour une présence en ligne gérée, pas pour un accès brut à un grand pool de ressources. Un fournisseur peut bien gérer cela s'il garde un contrôle minutieux des files d'attente de messagerie, des sauvegardes, du filtrage anti-spam, de l'allocation de stockage et du contact de support. Cela peut aussi devenir fragile si trop de fonctions convergent sur un seul serveur ou une seule personne de support.

RentaNET étend la même empreinte à la capacité de serveur géré. Lapage de tarification de RentaNETliste des plans avec 1 à 4 vCPU, 1 à 8 Go de RAM et 10 à 80 Go de NVMe, facturés annuellement de 79 à 419 AUD. Elle indique que chaque plan inclut des fonctions web, messagerie, DNS, CMS et de gestion d'informations personnelles, seule la capacité changeant selon le niveau. La même page fait la publicité de sauvegardes quotidiennes, de restaurations vérifiées, d'un SLA de disponibilité de 99,9%, d'un support australien et d'une revendication de centre de données à Sydney.

Ce sont des promesses clients significatives, mais chacune soulève une question physique. Un plan vCPU dépend d'un hôte. Le NVMe dépend d'un sous-système de disques. Une sauvegarde quotidienne dépend d'une destination, d'une politique de rétention et d'un test de restauration. Un SLA de 99,9% dépend d'exclusions, de mesure et de recours. Une revendication de centre de données à Sydney dépend de l'installation effective du fournisseur et de l'emplacement des copies de sauvegarde.

Les petits prix rendent ces questions plus importantes, pas moins, car il y a moins de marge financière pour une capacité de rechange inutilisée à moins qu'elle ne soit délibérément conçue dans le service.

L'ABN et les noms commerciaux soutiennent la continuité

Le registre officiel des entreprises donne à Spiderweb une histoire plus longue que les seules pages de service actuelles.ABN Lookuprapporte que l'entité active est CONSTABLE, MARK ANTHONY et que l'ABN est actif depuis 2004. Il liste RentaNet depuis le 10 mars 2014, Digital Mail Service depuis le 9 juin 2017, Spiderweb Cloud depuis le 5 juillet 2018 et MOTD depuis le 22 mars 2022 comme noms commerciaux. Il liste également AUwide Communications comme un nom commercial historique depuis le 1er septembre 2004.

Cela importe car le nom d'entité dans le répertoire est maladroit: « Mark Anthony Constable for Spiderweb Cloud and » semble provenir directement d'une description de ressource numérique, pas d'une copie de marque soignée. Le registre officiel des entreprises explique pourquoi la même personne, Spiderweb Cloud et RentaNet apparaissent ensemble dans les documents réseau et de service. Il s'agit d'une structure d'exploitation de travailleur indépendant avec plusieurs noms commerciaux enregistrés, pas d'un groupe d'entreprises conventionnel avec des filiales distinctes divulguées dans le registre public examiné ici.

Le modèle de travailleur indépendant a deux conséquences pour le risque d'infrastructure. Premièrement, la responsabilité envers le client peut être claire de manière simple: les marques de service renvoient toutes à un seul ABN actif. Deuxièmement, la résilience opérationnelle peut dépendre fortement de la disponibilité, des comptes fournisseurs, des connaissances techniques et des relations de support contrôlés par un seul principal ou une très petite équipe. Cela ne signifie pas que le service est faible. Cela signifie que les clients devraient tester la continuité d'accès aussi soigneusement qu'ils testent les spécifications du serveur.

Les pages publiques renforcent ce modèle centré sur le support. Spiderweb publie un numéro de téléphone et indique que les horaires sont de 10h à 18h AEST, sept jours sur sept. Les pages de RentaNET publient le même numéro de téléphone, la même adresse de contact et les mêmes horaires de support. Leformulaire de ticket de support de Spiderwebexpose les départements Ventes, Support et Facturation, avec des options de priorité haute, moyenne et basse. C'est une surface de support en direct, pas simplement un prospectus.

Ce qu'il ne montre pas, c'est une horloge de restauration. Un formulaire de ticket ne dit pas qui est éveillé à 03h00, qui peut accéder à une console de centre de données, qui peut autoriser un changement de routage BinaryLane ou Mammoth, qui détient l'accès au registre DNS, ou ce qui se passe si le système de facturation est indisponible. La continuité des petits fournisseurs dépend de ces détails. Un acheteur devrait demander des chemins d'escalade nommés, des contrôles de récupération de compte et un processus testé pour substituer un autre technicien ou contact fournisseur si l'opérateur habituel est indisponible.

Ce n'est pas une exigence de structure de grande entreprise. C'est une exigence d'une carte de continuité de petit fournisseur qui correspond à l'ampleur de la promesse. Les preuves publiques de continuité d'activité sont suffisantes pour considérer l'hébergeur comme actif; elles ne sont pas suffisantes pour considérer chaque transfert de support et de fournisseur comme récupérable.

AS153475 est enregistré, mais il ne transporte pas de routes publiques

Le registre réseau est là où commence la dégradation de l'article. Leenregistrement RDAP d'APNIC pour AS153475liste le système autonome comme SPIDERWEBCLOUD-AS-AP, pays AU, enregistré le 4 décembre 2024, avec la description « Mark Anthony Constable for Spiderweb Cloud and » et « RentaNet offering Email and Web hosting services. » Il lie l'ASN à Spiderweb Cloud en tant que registrant, un contact d'abus validé en février 2026, et un contact administrateur Spiderweb Cloud.

L'enregistrement n'est pas la même chose que l'exploitation. Lavue d'ensemble AS de RIPEstat pour AS153475a marqué l'ASN comme non annoncé pour le 12 juillet 2026. Savue de statut de routagea montré zéro préfixes IPv4, zéro préfixes IPv6, zéro voisins observés et aucune première ou dernière observation de route. Savue de préfixes annoncésn'a renvoyé aucun préfixe pour la fenêtre de deux semaines se terminant le 12 juillet 2026.

Cela ne prouve pas que le numéro ne sera jamais utilisé. Un ASN nouvellement enregistré peut rester inactif pendant que des contrats, des objets de route, des filtres, des interconnexions ou des plans d'adressage sont préparés. Un petit hébergeur peut enregistrer un ASN comme une optionnalité future, une étape de migration, ou un moyen de détenir un adressage portable sous sa propre politique plus tard. Mais au moment de cet examen, les collecteurs de routes publics ne montrent pas AS153475 comme l'origine du trafic client.

La distinction est pratique. Si un client croit que Spiderweb exploite son propre bord routé, il peut s'attendre à ce que Spiderweb déplace les routes entre les fournisseurs lors d'une panne de transit. Si les services actuels se trouvent plutôt derrière l'ASN d'un fournisseur ou un espace attribué par le fournisseur, le basculement de route dépend de la conception du fournisseur et des termes du contrat. Le risque du client n'est pas simplement « est-ce que le service a un ASN? » mais « quel ASN est réellement dans le chemin, qui peut le changer, et que se passe-t-il lorsque cette partie est indisponible? »

L'absence de voisins observés est également importante. Si AS153475 avait deux amonts en direct ou plus, un client pourrait commencer à se demander s'ils sont physiquement diversifiés, s'ils ont suffisamment de capacité après basculement et si l'autorisation d'origine de route est à jour. Ici, la question préliminaire est plus fondamentale: quand l'ASN sera-t-il mis en production, quels préfixes va-t-il originer, et quel problème résoudra-t-il par rapport au routage d'origine fournisseur actuel?

Jusqu'à ce que cela soit répondu, AS153475 devrait être traité comme une option de contrôle enregistrée, pas comme une preuve d'un bord opérationnel.

L'espace d'adressage Spiderweb plus ancien est actif, mais originaire du fournisseur

Leregistre d'organisation d'APNIC pour Spiderweb Cloudest le pont entre l'ASN dormant et le routage en direct. Il liste deux réseaux IPv4 actifs sous l'organisation Spiderweb Cloud:203.25.132.0/24et203.25.238.0/24. Les deux sont des blocs IPv4 portables attribués avec des dates d'enregistrement en septembre 2008 et des dates de dernière modification en juillet 2023. Les deux sont liés aux mêmes contacts Spiderweb Cloud.

RIPEstat a observé les deux préfixes comme actifs le 12 juillet 2026, mais l'origine n'était pas AS153475. Lavue d'ensemble du préfixe pour 203.25.132.0/24et lavue d'ensemble du préfixe pour 203.25.238.0/24ont toutes deux identifié AS133159 de Mammoth Media comme l'origine. Lavue de statut de routage pour 203.25.132.0/24et lavue de statut de routage pour 203.25.238.0/24ont montré les deux routes visibles par tous les 326 pairs IPv4 à pleine table échantillonnés, avec des observations de dernière vue le 12 juillet 2026.

C'est une preuve réseau réelle. Cela indique que les actifs d'adresse portables de Spiderweb ne sont pas simplement inutilisés dans un registre. Au moins deux /24 sont globalement visibles. Cela indique également que le bord opérationnel est actuellement un arrangement d'origine fournisseur. Mammoth Media, et non l'AS153475 propre de Spiderweb, est l'origine vue par les collecteurs publics.

Le routage d'origine fournisseur peut être une conception sensée. Il peut réduire la complexité opérationnelle pour un petit hébergeur. Le fournisseur a déjà des amonts, du peering, de la surveillance, des filtres de route, des routeurs et l'accès au centre de données. Un petit client peut se concentrer sur le service géré, la messagerie, le support et les applications client. Mais le routage d'origine fournisseur change le modèle de portabilité et de restauration.

Si un serveur ou service Spiderweb doit quitter l'infrastructure Mammoth Media ou BinaryLane, l'acheteur doit savoir si le /24 portable peut être ré-originé ailleurs, combien de temps prendraient les filtres et les objets de route, s'il existe des autorisations de route valides, et qui est autorisé à demander le changement.

Le résultat actuel de la validation d'origine de route rend cette question plus aiguë. Les vérifications de validation de RIPEstat pour203.25.132.0/24et203.25.238.0/24ont renvoyé un statut inconnu sans ROA de validation. Inconnu n'est pas la même chose qu'invalide. Cela signifie que les preuves publiques de sécurité d'origine de route examinées ici n'ont pas montré d'autorisation de validation actuelle pour l'origine observée. Pour un arrangement d'origine fournisseur, la sécurité de route et la portabilité d'urgence devraient être documentées plutôt que supposées.

La conclusion est étroite mais importante: Spiderweb a des actifs d'adresse routés en direct, mais la table de route publique pointe vers un bord exploité par un fournisseur.

Mammoth Media et BinaryLane deviennent partie du modèle de risque

Mammoth Media n'est pas une étiquette obscure dans cette chaîne. Leregistre RDAP d'APNIC pour AS133159nomme MAMMOTHMEDIA-AS-AP, Mammoth Media Pty Ltd, Brisbane, Queensland. Lavue d'ensemble AS de RIPEstata marqué AS133159 comme annoncé le 12 juillet 2026. Lavue des voisins ASNa montré plusieurs réseaux adjacents observés, incluant de grands fournisseurs de transit et de réseau. Leregistre réseau de PeeringDB pour AS133159liste Mammoth Media, également connu sous le nom de BinaryLane, avec une portée australienne, un support IPv6, une politique de peering ouverte, 13 connexions IX et six installations listées.

Le propre site web de BinaryLane décrit plus directement la couche d'infrastructure commerciale. Lapage d'accueil de BinaryLaneindique qu'elle propose des serveurs cloud NVMe, des sauvegardes automatisées, de l'équilibrage de charge, un pare-feu externe, une facturation horaire et un panneau de gestion ou API. Lapage d'hébergement VPSindique que BinaryLane héberge des serveurs dans quatre centres de données australiens: NextDC S1 à Sydney, NextDC M2 à Melbourne, NextDC P1 à Perth et NextDC B2 à Brisbane. Elle fait également la publicité d'un langage SLA de 99,9% pour l'hébergement VPS, d'une connectivité IPv4 et IPv6, d'un stockage redondant, de sauvegardes quotidiennes automatisées en option et d'un équilibrage de charge en option.

La proprepage de services de RentaNETnomme un partenariat BinaryLane pour la gestion de clusters Proxmox entreprise, avec des centres de données australiens, une facturation horaire, un stockage SSD NVMe et du peering direct. C'est une spécificité utile: si un client RentaNET achète un service géré construit sur l'infrastructure BinaryLane ou Mammoth, les revendications sous-jacentes de centre de données et de réseau peuvent être héritées de ce fournisseur plutôt que livrées depuis des baies appartenant à Spiderweb.

La résilience héritée a des limites. BinaryLane peut avoir une bonne portée de centre de données, des outils de migration en direct et de sauvegarde. Cela ne prouve pas qu'un service particulier de Spiderweb ou RentaNET est déployé sur plusieurs sites, sauvegardé en dehors de son domaine de défaillance principal, protégé par un équilibreur de charge, ou capable de se déplacer entre les préfixes d'origine Mammoth et AS153475. La capacité du fournisseur n'est pas la même que la configuration de l'instance client.

C'est là que l'économie de l'hébergement devient visible. Un petit plan annuel peut être viable car il repose sur une plateforme fournisseur partagée, des images serveur standardisées, une gestion à distance et un support étroitement défini. Il peut être d'un excellent rapport qualité-prix pour un petit site web ou une boîte aux lettres d'entreprise. Il ne faut pas le confondre avec une architecture dédiée à haute disponibilité à moins que le contrat et un test ne montrent que cette architecture existe.

La bonne question d'approvisionnement n'est pas « Mammoth est-il un fournisseur crédible? » Le registre public suggère que c'est un réseau d'hébergement australien visible. La question est « quel service Mammoth ou BinaryLane est réellement utilisé pour ce client, dans quel site, avec quelles options activées, sous quel compte, et avec quel chemin de récupération testé? »

L'emplacement est australien, mais la localité n'est pas une seule adresse

Le registre soutient l'Australie comme zone de service. Le registre ABN est australien, Spiderweb et RentaNET publient des coordonnées australiennes, APNIC marque les ressources comme AU, la géolocalisation RIPEstat place les deux /24 de Spiderweb en Australie, et BinaryLane indique que ses centres de données se trouvent dans des installations australiennes. C'est suffisant pour rejeter un profil vague uniquement mondial.

Ce n'est pas suffisant pour localiser les données du client. Lapage de tarification de RentaNETindique « centre de données australien (Sydney) » dans sa section infrastructure. BinaryLane, quant à lui, indique que sa flotte de serveurs s'étend sur Sydney, Melbourne, Perth et Brisbane. Lapolitique de confidentialité de Spiderwebstipule que les données peuvent être détenues sur des serveurs en Australie et dans tout autre territoire que Spiderweb juge approprié de temps à autre, et que les données peuvent être transférées à des parties listées en Australie ou à l'extérieur.

Ces déclarations peuvent être compatibles. Un plan RentaNET spécifique peut être à Sydney. Certains services de messagerie ou web de Spiderweb peuvent utiliser d'autres infrastructures australiennes. Des services externes tels que DNS, CDN, paiement, analytique, billetterie ou sécurité email peuvent traiter des données en dehors de l'Australie. Les sauvegardes peuvent être locales, distantes ou les deux. Les pages publiques ne fournissent pas de carte par service.

Pour la souveraineté des données et la localité, le client a besoin d'un tableau, pas d'un slogan. Il devrait identifier la copie de production, la copie de sauvegarde, la file d'attente de messagerie, le contenu web, la base de données, les journaux, le fournisseur DNS, le compte de registraire, le système de facturation, les données de ticket de support et les données de surveillance. Chaque ligne devrait nommer la région, le fournisseur, le propriétaire du compte, le chemin d'accès, la période de rétention et la méthode de sortie.

Si un plan est annoncé comme Sydney, le tableau devrait dire si les sauvegardes restent également à Sydney ou si elles se déplacent vers une autre région pour la résilience.

La localité interagit également avec la récupération. Une sauvegarde dans le même site peut être rapide à restaurer après une erreur utilisateur, mais faible contre une panne de site. Une sauvegarde dans un autre état peut être meilleure pour la reprise après sinistre, mais peut introduire des questions de juridiction et de contrôle d'accès. Un CDN peut améliorer les performances mais peut cacher les dépendances d'origine jusqu'à ce que l'expiration du cache ou les requêtes dynamiques les exposent. L'acheteur doit comprendre ces compromis avant un incident, pas pendant.

Les preuves publiques soutiennent donc « service hébergé en Australie avec des dépendances fournisseur. » Elles ne soutiennent pas « toutes les données restent dans une installation nommée contrôlée de bout en bout par Spiderweb. »

La messagerie est la dépendance opérationnelle la plus aiguë

Pour de nombreux clients Spiderweb, le chemin de défaillance le plus sensible peut être la messagerie plutôt que l'hébergement web. La page d'accueil de Spiderweb publie les paramètres de messagerie pour IMAP et SMTP, encourage IMAP par rapport à POP, et indique que le filtre anti-spam côté serveur dépend du déplacement des messages par les utilisateurs vers le dossier indésirable plutôt que de leur suppression. Laconnexion webmailest une surface d'accès client en direct. Leportail clientinclut des liens vers le compte, la gestion des services, les tickets de support et les paiements.

L'hébergement de messagerie est impitoyable sur le plan opérationnel. Un site web peut souvent être mis en cache ou restauré à partir d'un instantané. L'email nécessite une réception continue, une gestion de file d'attente, un filtrage anti-spam, des enregistrements d'authentification, TLS, un stockage de boîte aux lettres et une synchronisation appareil-utilisateur. Si le serveur IMAP est indisponible, les clients peuvent perdre l'accès au courrier actuel. Si le chemin SMTP est bloqué ou mal configuré, le courrier sortant peut être rejeté ou classé comme suspect.

Si les enregistrements DNS sont erronés, la délivrabilité peut se dégrader même lorsque le serveur de boîte aux lettres est sain.

Les mises à jour publiques de Spiderweb montrent que l'exploitant comprend certaines de ces dépendances. Lamise à jour de janvier 2026 de Spiderwebindiquait qu'un nouveau serveur avait été déployé le jour de Noël pour améliorer la sécurité et les performances pour les clients d'hébergement. Il décrivait la mise hors service des anciens ports de messagerie non cryptés, publiait les paramètres de messagerie SSL/TLS, et nommait Postscreen, CrowdSec, Rspamd et Spamprobe comme faisant partie de la pile de messagerie et de sécurité. L'article devrait être lu pour les affirmations techniques, pas comme une preuve d'une architecture de résilience complète.

La question opérationnelle est de savoir ce qui se passe lorsque ce système de messagerie tombe en panne. Existe-t-il un MX entrant secondaire qui met en file d'attente le courrier en dehors du serveur principal? Les sauvegardes de boîtes aux lettres sont-elles stockées séparément de l'hôte? Les utilisateurs peuvent-ils exporter tout le courrier au format IMAP standard? Combien de temps faut-il pour restaurer l'hôte si un système de stockage du fournisseur tombe en panne? Les enregistrements DNS et SPF/DKIM/DMARC peuvent-ils être modifiés si le panneau de contrôle normal est indisponible?

Qui peut supprimer un faux blocage si un client est verrouillé par des contrôles de sécurité?

La réponse peut être parfaitement adéquate pour de nombreuses petites entreprises. Un serveur de messagerie simple et bien géré avec des sauvegardes quotidiennes et un support réactif peut être plus précieux qu'une plateforme coûteuse que le client ne peut pas administrer. Mais la messagerie est l'endroit où les promesses de support des petits fournisseurs deviennent les plus visibles. Un client qui perd l'accès à sa messagerie pendant une campagne, un cycle de facturation ou une date limite légale ne vit pas une panne d'hébergement abstraite. Cela ressemble à une interruption d'activité.

C'est pourquoi les fonctionnalités de messagerie annoncées devraient être associées à un test de restauration et à un plan d'exportation.

Les sauvegardes sont annoncées, mais la restauration est la preuve qui compte

Lapage de tarification « pay-as-you-grow » de Spiderwebindique que les serveurs sont sauvegardés toutes les 24 heures et que tous les sites web WordPress ont leur propre système de sauvegarde conservant trois sauvegardes hebdomadaires. La page de tarification de RentaNET indique que les sauvegardes quotidiennes et les restaurations vérifiées sont incluses. Les pages d'accueil et VPS de BinaryLane décrivent des sauvegardes automatisées ou à la demande et la possibilité de restaurer des images de disque complètes ou de monter une sauvegarde et de récupérer des fichiers individuels.

Ce sont toutes des déclarations positives. Elles décrivent également différentes couches. Une sauvegarde de plugin WordPress, un instantané de serveur, une image disque du fournisseur et une copie hors site ne sont pas interchangeables. Ils capturent différentes données à différents moments, restaurent à différentes vitesses et échouent dans différentes conditions. Si toutes les sauvegardes se trouvent dans le même compte fournisseur et que ce compte est verrouillé, suspendu ou compromis, la sauvegarde peut être techniquement intacte mais opérationnellement indisponible.

Le registre public examiné ici ne montre pas la durée de rétention pour les sauvegardes de serveur géré RentaNET, l'emplacement de stockage, le cryptage, le temps de restauration, la fréquence des tests ou les droits d'exportation du client. Il ne dit pas si les boîtes aux lettres, les bases de données, les zones DNS, les clés TLS, les enregistrements de facturation et les tickets de support sont tous inclus. Il ne dit pas si une sauvegarde peut être restaurée vers un autre fournisseur si l'infrastructure Mammoth ou BinaryLane est indisponible.

Ce n'est pas une lacune inhabituelle. La plupart des sites publics des petits hébergeurs ne publient pas de rapports de récupération détaillés. Mais la lacune reste le risque du client. Une affirmation de sauvegarde devient une preuve de résilience seulement lorsque le fournisseur peut montrer une restauration récente, la copie source, l'environnement cible, le temps requis, la fenêtre de perte de données et les étapes que le client doit suivre.

Pour Spiderweb et RentaNET, une bonne preuve de récupération inclurait trois cas. Premièrement, restaurer un site WordPress à partir de la sauvegarde hebdomadaire au niveau du site. Deuxièmement, restaurer une boîte aux lettres à partir de la sauvegarde du serveur de messagerie sans perdre la structure de dossiers. Troisièmement, reconstruire un serveur géré dans une autre région BinaryLane ou un autre fournisseur en utilisant la dernière sauvegarde, les enregistrements DNS et la configuration documentée. Chaque cas devrait inclure le temps de restauration du service et le temps de vérification de l'intégrité des données.

Jusque-là, les sauvegardes quotidiennes doivent être considérées comme une preuve nécessaire mais incomplète.

La capacité installée, annoncée et récupérable sont distinctes

Les pages de service public exposent trois idées de capacité différentes. La capacité installée est ce qui existe sur l'hôte ou la plateforme du fournisseur. La capacité annoncée est ce qui est vendu comme plan ou option. La capacité récupérable est ce qui reste utilisable après une panne ou une migration.

Le modèle d'hébergement PAYG de Spiderweb annonce de très petites unités: des créneaux de stockage, des sites WordPress et des boîtes aux lettres IMAP. Les plans de RentaNET annoncent des tailles de vCPU, RAM et NVMe. BinaryLane annonce des ressources VPS qui peuvent être modifiées à partir d'un panneau de contrôle et facturées à l'heure. Chaque déclaration est utile, mais aucune ne dit au client combien de capacité de rechange existe pendant une panne.

Par exemple, RentaNET indique que les clients peuvent croître d'une unité à la fois sans migration. Cela peut être vrai à l'intérieur de la plateforme fournisseur normale. Si le problème est une panne d'hôte, une panne de site, un problème de compte fournisseur ou une panne de route, la croissance n'est pas le problème. La capacité de remplacement et l'accès aux supports de restauration deviennent le problème. Un plan avec 4 vCPU et 8 Go de RAM n'est récupérable que si un autre hôte avec une capacité compatible, un stockage, des adresses IP et une configuration peut être rendu disponible dans le délai requis par le client.

La même chose s'applique à la « bande passante non mesurée pour le trafic web et de messagerie normal » sur la page de tarification de Spiderweb. C'est une description de facturation, pas une garantie de capacité réseau. Un petit site web peut être non mesuré tout en partageant un port fini, une file d'attente de messagerie, un engagement amont, une politique CDN ou un seuil anti-abus. La page indique également que les tendances de trafic abusif peuvent entraîner une suspension des services. C'est raisonnable, mais les clients devraient comprendre qui décide de ce qui est abusif et à quelle vitesse un faux positif peut être inversé.

Le routage d'origine fournisseur façonne également la capacité. Si les deux /24 de Spiderweb sont originaires de AS133159, la capacité à absorber une panne dépend du routage de Mammoth, de la connectivité du centre de données et de la configuration spécifique du client. La table de route montre l'accessibilité, pas la quantité de bande passante payée, le nombre d'hôtes, la santé du pool de stockage ou le matériel de rechange disponible derrière un service client spécifique.

Le langage sûr est donc: Spiderweb et RentaNET vendent de la capacité de service hébergé et géré; les preuves publiques n'établissent pas quelle part de cette capacité est installée de manière indépendante, maintenable simultanément ou récupérable en dehors de l'environnement du fournisseur.

Les chemins de défaillance les plus crédibles sont ordinaires

Aucune preuve publique examinée ici n'identifie une panne spécifique, et aucune ne devrait être inférée. Les risques crédibles découlent de la chaîne de dépendance.

Le premier est la panne de la plateforme fournisseur. Si un composant de service BinaryLane ou Mammoth, un domaine d'alimentation du centre de données, un système de stockage ou un bord réseau tombe en panne, la capacité de Spiderweb à restaurer le service dépend du plan sélectionné, de l'emplacement de la sauvegarde, de l'entitlement de support et de l'accès au compte. Un fournisseur avec plusieurs installations ne rend pas automatiquement le déploiement d'un seul serveur d'un client multi-site.

Le deuxième est la panne de contrôle de route. Les deux /24 portables de Spiderweb sont actifs sous AS133159. Si le service client dépend de ces adresses et doit être déplacé, l'exploitant doit coordonner les changements d'origine de route, le filtrage, les objets de route et éventuellement la création de ROA. Parce que RIPEstat a renvoyé une validation d'origine de route inconnue pour l'origine AS133159 observée sur les deux préfixes, l'état de sécurité de la route devrait être nettoyé ou clairement documenté avant un déplacement d'urgence.

Le troisième est la panne du système de messagerie. Les paramètres de messagerie publics, la connexion webmail et la mise à jour de janvier 2026 montrent un service de messagerie avec filtrage anti-spam, ports cryptés et contrôles de sécurité. C'est opérationnellement significatif. Cela crée également une dépendance au stockage de boîte aux lettres, aux enregistrements DNS, à la gestion des files d'attente, aux mots de passe utilisateur, à la gestion des listes noires et à la réponse du support.

Le quatrième est la panne de sauvegarde et de restauration. Une sauvegarde quotidienne qui ne peut pas être restaurée rapidement, restaurée dans un nouvel environnement, ou vérifiée par le client ne répond pas au besoin de récupération. Une sauvegarde WordPress ne protège pas nécessairement la messagerie. Un instantané de serveur ne protège pas nécessairement le DNS externe, la facturation, les enregistrements de support ou le contrôle du registraire.

Le cinquième est la panne de facturation et de compte. Lepanier clientexpose des produits d'hébergement et de support horaire, tandis que le portail gère les services, les tickets et les paiements. Si l'accès à la facturation est verrouillé, une carte de crédit échoue, ou le compte fournisseur est suspendu, le service technique peut devenir dépendant de la récupération administrative. Ce risque est facile à négliger car il semble non technique jusqu'à ce qu'il bloque une restauration.

Le sixième est la saturation du support. Un petit hébergeur peut être très réactif dans des conditions normales et devenir contraint en capacité lorsqu'une migration de serveur, un problème de messagerie, un verrouillage client et un ticket fournisseur se produisent tous ensemble. La capacité de support fait partie de la capacité d'infrastructure. Les clients devraient connaître le chemin d'escalade lorsque les canaux ordinaires sont indisponibles.

Le septième est la panne de migration. Si un client veut partir, il a besoin des fichiers du site web, des bases de données, des boîtes aux lettres, des zones DNS, de l'accès au domaine, des certificats, des notes de configuration et des copies de sauvegarde dans un format utilisable. Un service n'est pas vraiment portable si seul l'exploitant actuel peut interpréter ou accéder à son état.

Aucun de ces chemins ne nécessite un incident dramatique. Ce sont les façons normales dont les petits services hébergés deviennent fragiles.

Ce qui augmenterait la confiance

Spiderweb et RentaNET pourraient améliorer la confiance publique sans révéler de détails sensibles. La première amélioration serait une note de placement de service. Elle devrait indiquer quels produits fonctionnent sur l'espace IP portable de Spiderweb, lesquels sur l'espace attribué par le fournisseur, lesquels utilisent Cloudflare, lesquels utilisent l'infrastructure BinaryLane ou Mammoth, et lesquels sont hébergés ailleurs. Elle devrait également indiquer si la revendication de centre de données à Sydney de RentaNET s'applique à tous les plans ou seulement à certains conteneurs gérés.

La deuxième amélioration serait un plan de route pour AS153475. Si l'ASN est destiné à la production, le fournisseur devrait dire quels préfixes il va originer, quels amonts seront utilisés, s'il y aura plus d'un site ou transporteur, et quel avantage client le changement apporte. Si AS153475 n'est pas encore en service, le site devrait éviter d'impliquer qu'il est le bord actif.

La troisième amélioration serait l'hygiène de sécurité de route. Les deux /24 de Spiderweb devraient avoir une autorisation d'origine de route documentée pour l'origine prévue, que ce soit AS133159 ou AS153475. Les objets de route et les lettres d'autorisation du fournisseur devraient être à jour. Les clients n'ont pas besoin de configurations de routeur privées; ils ont besoin de l'assurance que les changements de route d'urgence ne seront pas bloqués par des documents manquants ou du filtrage.

La quatrième amélioration serait une preuve de restauration. Une brève déclaration publique pourrait identifier la fréquence des sauvegardes, la rétention, la région de stockage, la fréquence des tests de restauration et les temps de restauration attendus par produit. Un rapport plus fort spécifique au client montrerait un test récent pour un site web, une boîte aux lettres et un serveur géré, y compris si la cible de restauration était dans le même fournisseur ou un environnement séparé.

La cinquième amélioration serait une matrice de support et d'autorité. Elle devrait distinguer le support client, l'administration de serveur, l'escalade fournisseur, les changements de route, les changements DNS, la récupération de domaine, les problèmes de paiement et l'exportation de données. Elle devrait dire qui peut approuver chaque action et quel canal reste disponible si le portail principal est en panne.

La sixième amélioration serait une déclaration de localisation des données et de portabilité. La politique de confidentialité de Spiderweb permet aux données d'être détenues en Australie ou dans d'autres territoires. Les clients devraient recevoir une déclaration plus précise pour leur service: région de production, région de sauvegarde, sous-traitants, format d'exportation, rétention après annulation et procédure de suppression.

Ce sont des demandes proportionnées pour un petit fournisseur. Elles ne nécessitent pas un programme de certification hyperscale. Elles demandent des preuves que le service acheté peut survivre aux défaillances de dépendance les plus probables.

Ce que les clients ne devraient pas inférer

Plusieurs faits publics sont utiles mais faciles à surestimer. Un ABN actif prouve l'identité commerciale, pas la conception technique. Un ASN enregistré prouve l'intention de ressource numérique, pas le routage public. Un /24 routé prouve l'accessibilité, pas la propriété des baies. L'empreinte multi-centre de données d'un fournisseur prouve les options disponibles du fournisseur, pas qu'un service particulier de Spiderweb est déployé sur eux. Une affirmation de sauvegarde quotidienne prouve un processus énoncé, pas une restauration réussie.

L'inverse est également vrai. AS153475 étant non annoncé ne signifie pas que les clients n'ont pas de service. Les sites publics, le portail, le webmail, la tarification et les blocs d'adresses liés à APNIC montrent une surface opérationnelle actuelle. Les petits hébergeurs s'appuient souvent sur des fournisseurs en amont précisément parce que c'est la conception économique sensée. Le problème n'est pas l'existence. Le problème est le contrôle récupérable.

Les signaux officieux de marché et de réseau ne devraient être utilisés que comme signaux. PeeringDB aide à identifier le profil d'interconnexion public de Mammoth Media/BinaryLane, mais il ne certifie pas le déploiement client de Spiderweb. Les collecteurs de routes RIPEstat montrent la visibilité globale des deux /24, mais ils ne montrent pas les chemins de fibre physiques, la capacité des ports, la disposition du stockage, le temps de fonctionnement des générateurs ou le personnel de support. Une page web indiquant « Sydney » est utile, mais elle ne localise pas chaque sauvegarde ou service de contrôle.

Les clients devraient donc poser les questions ennuyeuses. Quelle installation ou région cloud héberge mon service? Quel ASN et quel préfixe le transportent? Qui possède le compte? Que se passe-t-il si ce compte est suspendu? Où sont les sauvegardes? Quand a eu lieu la dernière restauration? Le service peut-il être reconstruit ailleurs? Comment exporter les données de messagerie et de site web? Qui répond lors d'un incident fournisseur?

Ces questions peuvent produire des réponses simples et rassurantes. Si c'est le cas, le service devient plus fiable. Si ce n'est pas le cas, le bas prix cache peut-être une dépendance de récupération que le client devrait tarifer séparément.

La conclusion honnête est une histoire de service géré

Mark Anthony Constable for Spiderweb Cloud and est mieux compris comme une petite opération australienne d'hébergement et de support géré avec de réelles preuves publiques: un ABN actif, des noms commerciaux enregistrés Spiderweb Cloud et RentaNet, des pages d'hébergement WordPress et email actuelles, un portail client, un webmail, une tarification de serveur géré RentaNET, des ressources numériques APNIC et un espace IPv4 portable Spiderweb globalement visible.

La preuve réseau impose également une limite claire. L'ASN nommé Spiderweb, AS153475, n'était pas annoncé dans les vues publiques RIPEstat examinées le 12 juillet 2026. Les deux /24 actifs de Spiderweb étaient annoncés par AS133159 de Mammoth Media. Cela ne rend pas le service faible par défaut, mais cela déplace la question de résilience de « est-ce que Spiderweb a un ASN? » à « comment Spiderweb gère-t-il le routage d'origine fournisseur, l'infrastructure du fournisseur, les sauvegardes, l'autorité de support et la portabilité client? »

Pour une petite entreprise qui a besoin d'un site WordPress géré, d'une boîte aux lettres ou d'un serveur Linux, l'offre publique peut être tout à fait appropriée. Le modèle de support peut être le produit. La valeur peut résider dans le fait que quelqu'un gère les paramètres de messagerie, les mises à jour, le filtrage anti-spam, le travail de restauration et l'administration Linux à des prix qu'un petit client peut se permettre.

Pour un client ayant des besoins de continuité plus forts, la même preuve exige de la prudence. La capacité hébergée ici dépend encore de baies ou d'hôtes cloud contrôlés par un fournisseur, de transit originaire d'un autre ASN, de sauvegardes quotidiennes dont l'étendue de restauration n'est pas publique, de travail de support qui peut être concentré, et de chemins de migration qui doivent être testés avant une panne. Ce n'est pas une condamnation. C'est la surface opérationnelle que l'acheteur devrait mesurer.

La note défendable est donc Moyenne, avec un abaissement de l'indépendance. Les activités et les services sont visibles. L'espace d'adressage est visible. Le réseau du fournisseur est visible. La preuve manquante est le contrôle opérationnel indépendant et la récupération testée.