Résumé
- StormWeb Canada Hosting Inc. est visible publiquement comme une société d'hébergement canadienne de longue date, avec une adresse postale à Victoria, des serveurs positionnés à Vancouver, une offre d'enregistrement de domaine auprès de CIRA, des produits d'hébergement partagé, VPS, serveur dédié géré et stockage cloud, ainsi que des canaux de contact pour les ventes, la facturation et le support.
- Les preuves réseau sont plus solides que les preuves d'infrastructure physique. Les enregistrements ARIN contiennent AS14807 pour StormWeb Canada Hosting Inc.; PeeringDB répertorie le réseau sous AS-STORMWEB avec une connexion VANIX opérationnelle de 10G; la liste des entités de VANIX et les données BGP corroborent la présence sur le point d'échange de Vancouver. Aucun de ces enregistrements ne prouve la propriété d'un centre de données, les alimentations électriques redondantes, l'autonomie des générateurs, l'inventaire des serveurs de rechange ou le basculement des clients.
- Les propres pages de produits et de contrats de l'entreprise montrent le modèle de dépendance réel: les services sont hébergés à Vancouver, les plans comportent des garanties de disponibilité, l'hébergement partagé est limité par des contrôles de ressources et d'abus, les clients doivent conserver leurs propres sauvegardes à jour, la maintenance planifiée est exclue des crédits de disponibilité, et les modifications des logiciels, du matériel ou des fournisseurs de services peuvent affecter les sites des clients.
- Les annonces publiques sont importantes car elles décrivent la surface opérationnelle. StormWeb a signalé une fenêtre de maintenance du routeur central de Vancouver en 2025, une panne d'hébergement partagé liée à un instantané de sauvegarde de serveur en octobre 2025, une interruption du service de messagerie liée à une mise à jour logicielle automatique, et plusieurs fenêtres de maintenance matérielle. Ces enregistrements ne prouvent pas un problème de fiabilité chronique, mais ils montrent pourquoi les tâches de sauvegarde, les modifications logicielles, le travail sur les racks et la connectivité en amont sont les chemins de défaillance à tester.
- Le niveau de preuve est Moyen pour l'identité, le catalogue de services et la présence réseau, mais Faible pour la résilience des installations et la reprise multi-sites. Les clients devraient demander des preuves datées concernant les installations, l'alimentation, le transit, la sauvegarde, la restauration, l'escalade du support et la portabilité des données avant de considérer les services hébergés par StormWeb à Vancouver comme une plateforme résiliente pour des opérations sensibles ou critiques en termes de temps.
L'entreprise est visible; l'infrastructure physique ne l'est pas
L'identité publique de StormWeb n'est pas le point faible du dossier. Sapage « À propos »indique que l'entreprise a été fondée en 1998, la décrit comme étant privée et détenue à 100 % par des Canadiens, et déclare qu'elle possède et exploite un réseau indépendant. La même page énumère l'offre principale en termes simples: hébergement web et email, services d'enregistrement de domaine, serveurs privés virtuels, serveurs dédiés et stockage cloud. Elle fournit également les deux ancrages géographiques importants pour une lecture d'infrastructure: le bureau principal se trouve à Victoria, tandis que les serveurs sont situés à Vancouver.
Lapage de contactfournit une adresse postale spécifique au 780 Tolmie Avenue, Building 3, Suite 1032, Victoria, BC, ainsi qu'un numéro de téléphone sans frais et des adresses e-mail distinctes pour la facturation, le support et les ventes. C'est une preuve d'identité utile. Cela montre une entreprise canadienne joignable, et non seulement une marque sur un tableau de prix. L'enregistrement de domaine public pourstormweb.canomme également StormWeb Canada Hosting Inc. comme contact de registraire et de titulaire et renvoie à la même adresse à Victoria. La preuve de domaine n'est pas une preuve d'infrastructure, mais elle renforce la frontière de l'entreprise.
L'infrastructure physique reste beaucoup moins visible. StormWeb indique que « les serveurs sont situés à Vancouver »; il ne publie pas d'adresse de centre de données pour les serveurs clients, de nom de fournisseur de colocation, de durée de bail, de nombre de racks, de topologie de générateur, de description d'onduleur, de conception de refroidissement, de densité de puissance, ou de la quantité de capacité installée, occupée, réservée et disponible à la vente. L'entreprise peut avoir ces détails sous contrat, et peut raisonnablement éviter d'en publier certains.
Le fait est que les lecteurs publics ne peuvent pas convertir l'affirmation de Vancouver en une affirmation de résilience.
Cette distinction est importante car le titre de l'article porte sur la capacité hébergée, pas seulement sur l'identité d'hébergement. Un site web hébergé, une boîte aux lettres, un VPS, un serveur géré ou un compte de stockage cloud dépend d'une chaîne de ressources physiques et opérationnelles: un rack, l'alimentation, le refroidissement, les pièces de serveur, le stockage, les instantanés, les commutateurs, le transit, l'accessibilité du point d'échange, le personnel de support, les contrôles de compte, l'état de facturation et une route pour déplacer les données si le fournisseur ne répond pas aux besoins du client.
StormWeb rend plusieurs parties de cette chaîne visibles, mais les couches physiques les plus sujettes aux pannes restent opaques.
La conclusion sur l'état opérationnel doit donc être prudente plutôt que dédaigneuse. StormWeb a une présence web établie, un catalogue de produits actuel, une identité légale nommée, des canaux de support publics et un système autonome visible. Ce n'est pas une liste fantôme. Pourtant, le dossier public ne permet pas à un acheteur de prouver que le service annoncé peut survivre à une panne de courant prolongée, un incident dans une installation à Vancouver, une panne de commutateur, un effondrement des performances de stockage, une erreur de licence, un instantané de sauvegarde bâclé ou un goulot d'étranglement du personnel.
L'entreprise est suffisamment visible pour être mandatée; les preuves d'infrastructure sont suffisamment minces pour exiger une dégradation.
Vancouver est la véritable géographie derrière la promesse cloud
StormWeb se vend par la localité canadienne. Lapage d'hébergement webindique que ses plans sont hébergés à Vancouver et inclut le stockage, le trafic, les comptes e-mail, les certificats SSL, la migration gratuite, les garanties de disponibilité, la surveillance et le support. Sa section de spécifications techniques nomme des disques SSD/NVMe, une bande passante de 10 Gigabits par seconde, IPv4 et IPv6 partagés, CloudLinux, des processeurs AMD EPYC et un serveur situé à Vancouver. Lapage VPSliste également Vancouver comme emplacement pour les plans de serveur privé virtuel gérés, avec IPv4 et IPv6, stockage NVMe, stockage de sauvegarde à distance et un SLA de disponibilité de 99,99 %. Lapage de serveur dédié gérédonne le même emplacement à Vancouver et un chiffre de bande passante de 2 Gbps pour ses plans listés.
Cette géographie est commercialement significative. Une petite entreprise canadienne qui souhaite une facturation en dollars canadiens, des normes de support locales, des services de domaine canadiens et des données stockées au Canada peut rationnellement préférer un fournisseur hébergé à Vancouver plutôt qu'une plateforme hyperscale dont le placement des données et le contrôle juridique sont plus difficiles à évaluer. Lapage de stockage cloudde StormWeb rend cet appel explicite en décrivant un stockage basé sur Nextcloud sur des serveurs canadiens à Vancouver et en présentant la loi canadienne sur la vie privée comme faisant partie de la proposition de valeur.
Mais la localité n'est pas la même chose que l'indépendance. Un client qui voit « hébergé à Vancouver » doit encore savoir quel site de centre de données à Vancouver, quelle alimentation électrique, quel chemin d'alimentation du bâtiment, quelles entrées de transporteur, quels fournisseurs en amont, quelle plateforme de stockage, quelle cible de sauvegarde et quel roulement du personnel sont impliqués.
Si tous les produits se trouvent derrière le même cœur de Vancouver, alors un événement dans un bâtiment à Vancouver, une coupure de fibre métropolitaine, une erreur de maintenance en amont, une panne de contrôleur de stockage ou une surcharge de support peut affecter des services qui semblent séparés sur le menu de vente.
Vancouver crée également un contexte réseau spécifique. VANIX publie despoints de connexion d'installationsincluant Cologix VAN2 au 1050 West Pender Street, Cologix VAN3, Cologix VAN4 et une installation eStruxture au 555 West Hastings Street. Lapage VAN2de Cologix décrit 1050 West Pender comme une annexe de qualité entreprise connectée au principal hôtel de transporteurs de la ville et indique que l'emplacement donne un accès direct à VANIX. Ces pages soutiennent l'idée que Vancouver a un véritable marché d'interconnexion, pas seulement une étiquette marketing. Elles ne nous disent pas où résident les serveurs de production de StormWeb ni si StormWeb a de l'équipement dans un ou plusieurs de ces bâtiments.
La lecture la plus sûre est que la géographie publique de StormWeb est suffisamment précise pour le positionnement client et insuffisante pour la preuve de résilience. « Vancouver » indique à un acheteur la juridiction et la latence. Cela ne détermine pas si le service peut survivre à la perte d'un rack, d'un commutateur, d'une salle de centre de données, d'une unité de distribution d'alimentation, d'une zone de refroidissement, d'un nœud de stockage, d'un fournisseur de transit ou d'un système de gestion de compte. Les acheteurs devraient demander un plan de site sous confidentialité, mais l'article public ne devrait pas inventer la réponse.
AS14807 fait de StormWeb un opérateur réseau, pas seulement un hébergeur de détail
La preuve opérationnelle tierce la plus solide est l'enregistrement réseau.L'enregistrement AS14807 d'ARINnomme STORMWEB, identifie l'organisation comme StormWeb Canada Hosting Inc., donne une date d'enregistrement en février 2024 et une mise à jour en mai 2026, et liste as14807.net et stormweb.ca dans les commentaires. Cela ne prouve pas combien de serveurs StormWeb exploite, mais cela établit le contrôle d'un système autonome sous le nom de l'entreprise.
Lapage AS14807 de PeeringDBajoute une texture opérationnelle utile. Elle liste l'organisation comme StormWeb, le nom également connu comme StormWeb Canada Hosting Inc., le IRR as-set comme AS-STORMWEB, la portée géographique comme Amérique du Nord, les niveaux de trafic comme non divulgués, le ratio de trafic comme principalement sortant, et un point d'échange public à VANIX. L'entrée VANIX est indiquée comme opérationnelle avec une capacité de 10G et les adresses 206.41.104.51 et 2001:504:39::51.
La propreliste de entités de VANIXcorrobore la même identité de membre, ASN et adresses d'échange IPv4/IPv6. Lapage d'échange VANIXde Hurricane Electric liste également AS14807, StormWeb Canada Hosting Inc., et les mêmes adresses d'échange parmi un grand ensemble de entités de Vancouver. Lapage AS14807 d'IPinfoliste trois blocs IPv4 associés à StormWeb Canada Hosting Inc., tandis que lavue AS14807 d'ipctlrapporte trois préfixes annoncés IPv4, un préfixe IPv6, un statut RPKI-valid et des données de fournisseur en amont qui incluent GTT, Hurricane Electric et Astute Internet.
Pris ensemble, ces enregistrements rendent la présence réseau crédible. StormWeb ne se contente pas de revendre un panneau de contrôle sous licence blanche sans empreinte de routage visible. Il a un ASN public, des objets de route, une adhésion à un point d'échange et une visibilité en amont. Cela améliore l'histoire client car un contrôle de routage direct peut rendre le dépannage, le peering et l'ingénierie du trafic plus pratiques qu'un modèle de pur revendeur.
Mais la propriété d'AS n'est pas une garantie de résilience. Un port d'échange de 10G ne prouve pas le volume de trafic actif, la capacité de réserve lors d'un incident, les commutateurs redondants, l'alimentation double sur chaque routeur, la fibre diverse dans l'installation, ou la capacité de maintenir les serveurs hébergés joignables si le site principal de Vancouver perd l'alimentation ou le refroidissement. PeeringDB marque explicitement les niveaux de trafic de StormWeb comme non divulgués, et les vues BGP publiques ne révèlent pas l'impact client, l'utilisation des ports, l'historique de maintenance ou les tests de basculement.
La présence de fournisseurs en amont nécessite également une lecture attentive. Plusieurs fournisseurs en amont dans les données BGP sont une bonne preuve d'options de routage. Ils ne prouvent pas automatiquement la diversité des chemins physiques. Deux sessions en amont peuvent traverser la même salle de rencontre, le même conduit local, la même baie optique, le même domaine d'alimentation du bâtiment ou le même processus de support.
Les clients achetant un hébergement haute disponibilité devraient demander si les fournisseurs en amont de StormWeb se terminent dans des dispositifs séparés, des armoires séparées, des installations séparées, des entrées de transporteur séparées et des chemins d'alimentation séparés. Sans cette preuve, AS14807 soutient une note réseau Moyenne, pas une note de résilience Forte.
Le catalogue de services montre de vrais produits et une contention cachée
Le catalogue de détail de StormWeb est suffisamment large pour être significatif. Lapage d'hébergement webpropose des plans web et email Starter, Pro et Enterprise, avec les niveaux visibles allant d'un site et 100 Go de stockage SSD/NVMe à des sites illimités, un stockage SSD/NVMe illimité et des comptes e-mail illimités. Elle liste également des certificats SSL gratuits, une aide à la migration, des garanties de disponibilité et une surveillance et un support 24/7. La section technique pointe vers CloudLinux, Apache, MariaDB, plusieurs versions de PHP, SSH/SFTP et d'autres composants d'hébergement ordinaires pour petites entreprises.
Lapage VPSliste des plans de serveur privé virtuel gérés de 25 Go à 500 Go de stockage, 100 Mbps à 1 Gbps de bande passante, un à six vCores, 4 Go à 24 Go de RAM et un stockage de sauvegarde à distance. Lapage de serveur dédié géréliste des plans plus grands avec 1 To à 6 To de stockage, 2 Gbps de bande passante, 8 à 24 vCores dédiés, 32 Go à 96 Go de RAM et un stockage de sauvegarde à distance. Lapage de stockage cloudprésente des options Nextcloud de 1 To, 2 To et 5 To, hébergées à Vancouver avec surveillance et support.
Ce ne sont pas des services exotiques. Ce sont exactement les services que les petites entreprises achètent lorsqu'elles veulent éviter de gérer l'infrastructure elles-mêmes. Cela rend le problème de dépendance plus aigu. L'hébergement pour petites entreprises semble souvent simple parce que le client voit une seule facture et un seul identifiant. Le fournisseur doit toujours rationner le disque, le CPU, la RAM, les E/S, les instantanés, les files d'attente de messagerie, le travail de restauration, les adresses IP, le temps de support et le transit en amont.
Lorsque la page produit utilise des mots tels que « illimité » ou « sans limite », la réalité technique a toujours des limites.
La proprepolitique d'utilisation acceptablede StormWeb confirme que la capacité partagée est activement limitée. Elle indique que le service est conçu pour les petites entreprises indépendamment détenues, pas pour les grandes entreprises ou les entreprises basées à l'international ayant une demande soutenue qui pèse sur le système. Elle décrit également l'hébergement web partagé comme les sites web et e-mails ou services de stockage de nombreux clients hébergés sur le même serveur, avec des contrôles d'abus destinés à empêcher un client de nuire aux autres. La même politique fixe des limites de durée CPU sur l'hébergement partagé et restreint des utilisations telles que le partage de fichiers, les serveurs de jeux et les processus non supervisés.
Ce langage politique est raisonnable. L'hébergement partagé ne peut pas fonctionner sans garde-fous. Cela signifie également que les clients ne devraient pas lire la page de vente comme une promesse de capacité de calcul sans contrainte. StormWeb vend une capacité d'hébergement gérée et limitée pour une classe particulière de clients. Si un site croît inhabituellement vite, est scrapé, envoie des e-mails de manière incorrecte, exécute des scripts lourds ou devient un substitut de stockage, les contrôles du fournisseur peuvent devenir partie intégrante du chemin de disponibilité du client.
L'économie est visible dans l'échelle des prix. Les faibles prix mensuels, la migration groupée, les certificats inclus, le support et les sauvegardes dépendent tous de l'efficacité multi-locataire. L'efficacité multi-locataire dépend de la gestion de la contention. La gestion de la contention dépend d'une surveillance précise, de limitations équitables, de voies de mise à niveau et d'escalade du support. La question clé pour le client n'est pas de savoir si le catalogue de StormWeb est réel.
Elle est de savoir comment l'entreprise sépare l'utilisation normale des petites entreprises de la charge qui force une migration, une suspension, une mise à niveau payante ou une fenêtre de réparation manuelle.
Les garanties de disponibilité définissent des crédits, pas une preuve d'ingénierie
Les pages produits de StormWeb annoncent des garanties de disponibilité: 99,9 % sur les niveaux d'hébergement partagé inférieurs, 99,95 % sur le plan partagé Pro, 99,99 % sur le niveau partagé Enterprise et 99,99 % sur les plans VPS et serveur dédié géré. La page de contrat est plus révélatrice que la page de vente. Lesconditions de servicede StormWeb indiquent que la garantie de disponibilité exacte est listée dans la description du plan, définissent l'indisponibilité réseau comme une perte de paquets de 100 % de StormWeb vers ses fournisseurs de backbone, et mesurent le temps d'arrêt après notification via le système de tickets en ligne, avec un appel téléphonique de repli si le système de tickets est inaccessible.
Cette définition est étroite. Elle peut être appropriée pour une politique de crédit d'hébergement, mais elle n'est pas la même chose que la disponibilité de l'application. Le site d'un client peut être commercialement indisponible parce qu'une base de données est surchargée, qu'une boîte aux lettres est verrouillée, qu'un panneau de contrôle tombe en panne, qu'un instantané de sauvegarde nuit aux performances, qu'une configuration DNS est incorrecte, qu'un renouvellement de certificat échoue, qu'un pool de stockage ralentit, qu'un script consomme du CPU, ou que le propre code du client échoue.
Certains de ces incidents peuvent tomber en dehors d'une définition de perte de paquets réseau.
Les exclusions sont tout aussi importantes. Les conditions excluent la maintenance planifiée, le comportement ou l'équipement du client, les circonstances hors du contrôle raisonnable de StormWeb, l'interruption ou le retard dans les télécommunications ou les services tiers, la propagation DNS, l'enregistrement ou le transfert de domaine, les logiciels ou matériels tiers, et l'incapacité d'obtenir des matières premières, des fournitures, de l'électricité ou de l'équipement. Ces exclusions sont normales dans les contrats d'hébergement.
Elles identifient également la chaîne d'approvisionnement physique derrière la promesse: l'électricité, le transport, les logiciels tiers, le matériel, les matériaux et la maintenance restent tous des dépendances.
La section de limitation de responsabilité est un autre signal économique. Les conditions indiquent que les services sont fournis sans garantie qu'ils seront ininterrompus, sans erreur ou complètement sécurisés, et plafonnent la responsabilité globale à un montant lié à trois mois de service. Ce n'est pas inhabituel pour l'hébergement de petites entreprises. Cela signifie simplement que le modèle de perte du client ne peut pas être externalisé vers le SLA.
Si les revenus, la réputation, les données réglementées ou le processus opérationnel d'un client dépendent du système hébergé, les crédits et les dommages plafonnés ne compenseront pas le client.
Les dispositions de récupération doivent être lues parallèlement à la promesse de disponibilité. Les conditions indiquent que les clients acceptent de maintenir une copie à jour de tout contenu hébergé par StormWeb, nonobstant tout accord de StormWeb pour fournir des services de sauvegarde. Elles décrivent également une demande de restauration gratuite pendant la durée du service, avec des frais après cela. Cela ne signifie pas que StormWeb manque de sauvegardes. Cela signifie que le contrat place la responsabilité ultime de la copie du contenu sur le client.
Une entreprise qui traite les sauvegardes du fournisseur comme sa seule sauvegarde a mal compris la répartition des risques.
La lecture pratique est que StormWeb offre un SLA d'hébergement conventionnel, pas une preuve de résilience de bout en bout. Un acheteur devrait demander comment la disponibilité est surveillée, quels services sont couverts, comment les pannes de stockage et de messagerie sont traitées, comment la maintenance est annoncée, comment les crédits sont demandés, comment les points de restauration sont créés et testés, et à quelle vitesse l'entreprise peut reconstruire un VPS ou une boîte aux lettres sur un matériel différent. La réponse, pas le pourcentage, détermine la disponibilité utilisable.
Les avis de maintenance et d'incident exposent les véritables chemins de défaillance
La page d'annonces de StormWeb est précieuse car elle montre comment le service peut tomber en panne et comment l'entreprise communique. L'index des annoncescomprend des mises à jour de produits, des changements de prix, des avis de maintenance et des messages d'incident. Un avis de maintenance du routeur central de Vancouver en novembre 2025a indiqué que StormWeb mettrait à niveau les routeurs centraux de son point de présence à Vancouver, s'attendant à maintenir des connexions réseau redondantes vers les serveurs pendant la fenêtre, mais notant la possibilité de brefs problèmes de connectivité Internet pour les clients. C'est une déclaration précise du risque réseau: la redondance est prévue, mais un changement de routeur central peut encore être visible par le client.
L'avis de perturbation du service de messagerie IMAP et POP3 d'avril 2024décrit un défaut détecté sur un serveur de messagerie, une restauration après environ 25 minutes, et une mise à jour logicielle automatique incompatible avec la configuration du serveur. Cet incident se situe dans une catégorie différente: pas de transit, pas d'alimentation, mais une compatibilité de changement logiciel. Pour les clients des petites entreprises, les pannes de messagerie peuvent être plus nuisibles qu'un bref problème de site web car la facturation, le support et la récupération de compte dépendent souvent du courrier.
Plusieurs messages plus anciens montrent des travaux matériels planifiés. L'avis de maintenance du serveur da2 d'octobre 2024indiquait que les services web, email et de panneau de contrôle seraient indisponibles pendant une fenêtre de quatre heures pendant laquelle le matériel était mis à niveau, et marquait plus tard la mise à niveau comme terminée. L'avis de maintenance adjacent pour da1suit le même schéma. Ces avis sont utiles car ils localisent le temps d'arrêt au niveau du matériel serveur et des couches de panneau de contrôle, pas seulement à la périphérie du réseau.
La leçon n'est pas que la maintenance est mauvaise. La maintenance est ce qui permet au service de rester sûr. La leçon est que les clients doivent modéliser la maintenance comme une contrainte de capacité. Si un fournisseur doit mettre un serveur partagé hors ligne pour des travaux matériels, la résilience du client dépend de la possibilité de déplacer la charge de travail ailleurs, de la préservation des files d'attente de messagerie, de la tolérabilité de la fenêtre de maintenance et de la possession par le client d'une copie indépendante du site.
Si une mise à niveau de routeur peut créer de brefs problèmes Internet malgré des connexions redondantes, alors les clients haute disponibilité ont besoin soit d'un second chemin, soit d'une tolérance aux événements courts.
Les sauvegardes sont une dépendance, pas un remède
Le langage sur les sauvegardes rassure souvent les acheteurs trop rapidement. Les pages produits de StormWeb listent un stockage de sauvegarde à distance pour les plans VPS et serveur dédié géré, et sa page de stockage cloud vend la capacité Nextcloud comme un produit destiné à l'utilisateur. L'historique des incidents montre pourquoi la conception des sauvegardes nécessite un examen attentif. La panne d'hébergement partagé d'octobre 2025 était liée non pas à une perte de données, mais à un instantané de sauvegarde planifié qui a créé une dégradation inattendue des performances.
C'est un problème d'infrastructure classique: le système de protection peut devenir le système perturbateur lorsque la charge d'instantané, les performances de stockage, les E/S de base de données ou la planification ne correspondent pas à la charge de travail en direct.
Le langage contractuel de StormWeb sur les sauvegardes est clair: le client reste responsable d'une copie à jour. C'est un avertissement sain. Une sauvegarde n'est utile que si elle existe, est suffisamment récente, peut être accessible lorsque le fournisseur est défaillant, et peut être restaurée ailleurs rapidement. Une sauvegarde stockée sur la même plateforme du fournisseur peut aider après une suppression accidentelle; elle peut ne pas aider si l'accès au compte, la facturation, le stockage, le routage ou la file d'attente de support du fournisseur est ce qui a échoué.
L'hébergement partagé soulève un problème particulier. De nombreux clients sur un seul serveur physique ou virtuel peuvent avoir des sauvegardes planifiées dans la même fenêtre. Le fournisseur doit équilibrer la fréquence des sauvegardes, le coût de stockage, l'impact E/S, la granularité de la restauration et le travail opérationnel. Si la sauvegarde crée un ralentissement des performances, les clients le vivent comme un temps d'arrêt. Si les sauvegardes sont trop peu fréquentes, les restaurations perdent trop de données.
Si les restaurations nécessitent l'intervention du personnel de support, un problème généralisé peut créer une file d'attente. Si une sauvegarde est uniquement interne au fournisseur, elle peut ne pas aider un client à migrer sous stress.
Les plans VPS et dédiés déplacent une partie du problème mais ne le suppriment pas. Le stockage de sauvegarde à distance semble plus solide que le stockage local uniquement, mais le tableau des plans publics n'identifie pas le système de sauvegarde, le calendrier de rétention, l'emplacement physique, le modèle de chiffrement, la vitesse de restauration, le chemin réseau, le domaine de défaillance ou si les sauvegardes sont téléchargeables par le client. Un client qui utilise un logiciel de comptabilité, un système de réservation, un stockage de documents juridiques ou un site web de clinique a besoin de plus qu'un chiffre de stockage.
Il a besoin d'un objectif de restauration.
Le stockage cloud a le même piège en sens inverse. Lapage de stockage cloudde StormWeb commercialise Nextcloud, l'hébergement canadien, le chiffrement en transit, le chiffrement au niveau dossier au repos et le support. Cela peut être utile pour les équipes qui ont besoin d'un service de partage de fichiers canadien. Mais le stockage cloud n'est pas la même chose que la reprise après sinistre. Si les utilisateurs suppriment ou écrasent accidentellement des fichiers, si les clés de chiffrement sont mal gérées, si le compte est suspendu, si la plateforme de Vancouver est dégradée, ou si le fournisseur modifie le service, le client a toujours besoin de preuves de rétention, d'exportation et de restauration.
Le test pour les clients de StormWeb est simple et exigeant. Ils devraient demander quand les sauvegardes sont exécutées, où elles sont stockées, combien de temps elles sont conservées, si elles sont isolées du système principal, si elles sont chiffrées, si les clients peuvent les télécharger sans intervention du support, comment les restaurations sont priorisées, et quand la dernière restauration complète a été testée. Sans ces réponses, la sauvegarde est une fonctionnalité, pas une garantie de récupération.
La localisation des données est une proposition de valeur avec des limites
Le positionnement canadien de StormWeb est crédible et commercialement utile. L'entreprise indique qu'elle est détenue à 100 % par des Canadiens, liste un bureau canadien, facture en dollars canadiens et situe les serveurs à Vancouver. Sapolitique de confidentialitéindique qu'elle ne vend pas d'informations personnellement identifiables et décrit l'utilisation des informations pour les transactions, le support et les annonces de service. Sa page de stockage cloud indique que les fichiers sont stockés sur des serveurs sécurisés hébergés à Vancouver. Pour de nombreux clients, ces faits réduisent les frictions.
Le contexte juridique plus large nécessite encore de la prudence. Lesorientations sur le cloud computing pour les petites et moyennes entreprisesdu Commissariat à la protection de la vie privée du Canada présentent le cloud computing comme un problème de confidentialité et de responsabilité, pas simplement un problème d'emplacement de stockage. Lesorientations sur l'externalisationdu CPVP soulignent également le point clé pour les clients du secteur privé: l'externalisation du traitement des données est autorisée en vertu de la LPRPDE, mais les organisations restent responsables des considérations de confidentialité et devraient utiliser des moyens contractuels ou autres pour protéger les informations personnelles.
Les acheteurs du secteur public de la Colombie-Britannique sont confrontés à une analyse supplémentaire. Les orientations provinciales surles divulgations en dehors du Canadaindiquent aux organismes publics d'évaluer les risques lorsque les fournisseurs de cloud ou d'infrastructure peuvent être soumis à des lois qui imposent la divulgation. Le point pertinent pour StormWeb n'est pas qu'il échoue à ce test. C'est que « propriété canadienne » et « hébergé à Vancouver » ne complètent pas le test à eux seuls. Un acheteur a toujours besoin des termes du contrat, de la divulgation des sous-traitants, de la géographie de l'accès au support, de la géographie des sauvegardes, de la gestion des journaux, de la gestion des processus juridiques et des mécanismes d'exportation des données.
Les conditions de StormWeb indiquent que l'accord est régi par le droit de la Colombie-Britannique et le droit canadien applicable. Cela aide à définir le for contractuel. Cela ne prouve pas en soi que chaque outil de support, processeur de paiement, registraire, fournisseur de logiciel, système de surveillance, cible de sauvegarde ou service en amont est canadien. La politique de confidentialité mentionne également des services tiers pour le traitement des paiements et le suivi, ce qui est normal.
Les acheteurs ayant des besoins stricts de localité devraient demander quels tiers traitent les données de compte, de facturation, de support, de surveillance et de sauvegarde.
Il y a une différence pratique entre la résidence des données et la portabilité des données. La résidence des données demande où se trouvent les données. La portabilité des données demande à quelle vitesse le client peut partir. Une petite entreprise canadienne peut choisir StormWeb pour garder son site web, sa messagerie et ses fichiers à Vancouver.
Si elle doit ensuite déménager en raison du prix, des performances, d'une acquisition, du support, de la conformité ou d'un incident, elle doit être en mesure d'exporter le DNS, les boîtes aux lettres, les bases de données, les fichiers du site, les fichiers Nextcloud, les images VPS et les journaux sans une dépendance manuelle d'une semaine.
La note de localité est donc Moyenne. La propriété canadienne, le bureau, l'affirmation d'hébergement à Vancouver, la position d'enregistrement de domaine et le langage axé sur la vie privée de StormWeb sont utiles. La preuve manquante est la carte complète des sous-traitants et de la récupération. Pour les charges de travail sensibles, les clients devraient considérer la localité canadienne comme un avantage de départ, pas le contrôle final.
VANIX améliore la portée, mais ne prouve pas la diversité des routes
La participation de StormWeb à VANIX est l'une des parties les plus solides de son histoire d'infrastructure. Un point d'échange local peut réduire la latence, maintenir le trafic régional local, réduire le coût de transit et améliorer le choix de route. La propre page « À propos » de StormWeb mentionne la participation à VANIX et indique que le peering avec d'autres réseaux canadiens importants aide à réduire la latence en gardant le trafic local local. Les enregistrements publics du point d'échange soutiennent cette affirmation au niveau de l'adhésion.
L'écosystème du point d'échange donne également un contexte utile. La liste des entités de VANIX comprend de grands opérateurs de contenu, de télécommunications, de cloud, d'entreprises et de réseau. La vue d'échange de Hurricane Electric montre StormWeb parmi un ensemble dense de pairs de Vancouver. Lapage d'histoire de VANIXrapporte des jalons de trafic et des mises à niveau de backbone au cours des dernières années, y compris des liens 400G et une croissance du trafic des entités. Ces enregistrements soutiennent la conclusion que StormWeb est attaché à un environnement d'interconnexion local significatif.
Le risque est de trop interpréter les preuves. Une seule connexion d'échange de 10G peut améliorer la portée et l'économie, mais elle ne garantit pas la continuité du service client. Si les routeurs, serveurs et cibles de sauvegarde de StormWeb se trouvent tous derrière un seul site de Vancouver, un seul chemin de commutateur interne ou un seul processus de maintenance, alors l'adhésion à VANIX ne résout qu'une partie du problème.
Si un client a besoin d'un accès garanti à faible latence à un pair particulier, le client a également besoin de savoir si la route reste locale pendant la maintenance, si le fournisseur a un second port d'échange, si les sessions route-server sont redondantes, si BFD est configuré et si le trafic peut passer en transit sans surcharge.
L'histoire du fournisseur en amont nécessite la même discipline. ipctl rapporte GTT, Hurricane Electric et Astute Internet comme fournisseurs en amont pour AS14807. Plusieurs noms en amont sont meilleurs qu'un seul. Pourtant, le BGP public ne révèle pas si ces fournisseurs en amont sont physiquement diversifiés, s'ils se terminent sur différents routeurs, s'ils partagent un chemin optique, si leurs contrats incluent des intervalles de restauration, ou si StormWeb peut absorber la perte de l'un d'eux pendant un pic de trafic d'hébergement partagé.
Les clients devraient demander un dessin de diversité de route et des preuves de test de défaillance plutôt que de se fier à la liste des noms AS.
L'avis de maintenance du routeur central de StormWeb en 2025 est la preuve la plus pratique que le réseau a des pièces mobiles. Il indique que des connexions réseau redondantes devaient rester, mais que de brefs problèmes de connectivité étaient possibles. Ce libellé n'est ni alarmant ni vide. C'est à quoi ressemble une vraie maintenance lorsqu'un petit fournisseur a de la redondance mais doit encore toucher au cœur. Pour un client, la bonne réponse n'est pas d'exiger une maintenance zéro. C'est de décider si l'application peut tolérer un bref problème de connectivité et, si ce n'est pas le cas, de concevoir un second chemin fournisseur.
La note réseau doit donc rester divisée. StormWeb mérite du crédit pour un ASN public, une participation à un point d'échange, des routes visibles et une identité réseau maintenue. Il ne mérite pas une preuve inventée de diversité de route, d'historique de perte de paquets mesurée, d'utilisation des ports, de basculement de la structure d'échange ou de reprise multi-site. Le dossier public soutient des opérations réseau actives et laisse le test de diversité ouvert.
Qui est affecté lorsque le système tombe en panne
La clientèle de StormWeb n'est pas énumérée publiquement, et l'article ne devrait pas inventer de clients nommés. Les pages produits rendent les groupes affectés suffisamment clairs. Les clients d'hébergement web et email partagé comprennent de petites organisations utilisant la plateforme pour des sites web, des boîtes aux lettres, WordPress, des bases de données et des formulaires de contact. Les clients VPS peuvent exécuter des applications plus personnalisées, des panneaux de contrôle, des bases de données et des piles de messagerie.
Les clients de serveurs dédiés gérés peuvent consolider des applications à plus forte ressource sur la capacité gérée par StormWeb. Les clients de stockage cloud peuvent utiliser Nextcloud pour des fichiers partagés entre appareils et membres de l'équipe.
Le mode de défaillance détermine l'impact. Une fenêtre de maintenance matérielle d'un serveur partagé peut rendre les services web, email et de panneau de contrôle indisponibles pour les clients affectés. Un problème de performance d'instantané de sauvegarde peut bloquer l'accès web et email sans détruire les données. Une mise à jour logicielle incompatible peut interrompre les protocoles de messagerie. Un problème de maintenance du routeur central peut affecter la joignabilité Internet même si les serveurs restent alimentés. Une suspension de facturation peut supprimer le service pour une raison non technique.
Un déclencheur de contrôle d'abus peut limiter ou suspendre un site qui a grandi plus vite que prévu.
Chaque groupe affecté a une tolérance différente. Un site de brochure peut survivre à une fenêtre de maintenance planifiée à 1 h 00. Un système de réservation de restaurant, un site de clinique, une boutique e-commerce, une boîte aux lettres juridique ou une page communautaire d'urgence peuvent ne pas le supporter. Un freelance utilisant Nextcloud comme un magasin de commodité peut attendre une réponse du support; un bureau distribué l'utilisant comme système de fichiers principal a besoin de copies hors ligne et de procédures d'exportation.
Un utilisateur VPS peut avoir suffisamment de capacité technique pour se répliquer ailleurs; un utilisateur d'hébergement partagé peut dépendre entièrement du support du fournisseur.
Le langage contractuel en fait un problème de conception client. Les clients sont responsables de maintenir une copie à jour du contenu hébergé. La maintenance planifiée est exclue. La responsabilité du fournisseur est limitée. Les politiques d'abus et de ressources peuvent être appliquées. Le service peut changer à mesure que les logiciels, le matériel et les fournisseurs de services changent. Ces clauses sont commercialement normales, mais elles transfèrent une grande partie de la charge de continuité au client.
C'est là que le support devient infrastructure. StormWeb indique que le personnel de support est disponible 24 heures sur 24 pour les demandes de support, et les pages produits listent à plusieurs reprises la surveillance et le support. La page de contact indique les heures de téléphone pendant les heures de bureau et oriente les problèmes de service existants vers les annonces, l'état du réseau, la base de connaissances et les tickets. Lapage d'état du réseauliste les services web, mail, base de données, FTP, SSH/SFTP et DNS sur l'hébergement web/email, VPS, serveurs dédiés et stockage cloud, et fournit une surface d'état actuel.
C'est utile, mais pas suffisant pour une utilisation à hautes conséquences. Les clients devraient demander comment les tickets urgents sont triés, si l'escalade téléphonique existe pour les pannes, comment fonctionne le personnel après les heures de bureau, si le support a l'autorité de déplacer les charges de travail, comment les demandes de restauration sont mises en file d'attente, et comment les mises à jour d'incident sont distribuées si l'espace client est inaccessible. Dans un contexte de petit fournisseur, le travail de support est une contrainte de capacité aussi réelle que le CPU ou le disque.
Ce qu'un acheteur doit vérifier avant de considérer StormWeb comme résilient
Le premier élément de vérification est l'emplacement de l'installation et le domaine de défaillance. StormWeb indique publiquement Vancouver, mais un acheteur en résilience a besoin de l'opérateur du centre de données, du site, de la limite de la salle ou de la cage, des alimentations électriques, de la conception de l'onduleur, de l'autonomie du générateur, de la redondance du refroidissement, de la suppression d'incendie, de la sécurité physique, et de savoir si les équipements de production, de sauvegarde et de réseau partagent la même installation.
Si le fournisseur ne divulgue pas les détails publiquement, un dossier de preuves confidentiel est raisonnable.
Le deuxième élément est la diversité réseau. AS14807 et VANIX sont de bonnes preuves de départ. L'acheteur devrait demander la liste des fournisseurs en amont, les vitesses de port, la redondance des routeurs, la diversité des installations, les entrées de transporteur, l'utilisation du route-server, la politique de peering privé, la gestion DDoS, et comment le trafic se comporte lorsqu'un fournisseur en amont, un routeur ou une session d'échange échoue. L'expression clé n'est pas « Avez-vous plusieurs fournisseurs? » mais « Montrez les domaines de défaillance séparés. »
Le troisième élément est la capacité et l'inventaire. Les pages de plans publics listent le stockage, le trafic, la bande passante, le CPU et la RAM, mais elles ne révèlent pas la contention. Un acheteur devrait demander combien de clients partagent un hôte, comment le CPU et les E/S sont contrôlés, ce qui se passe lorsqu'un hôte est plein, si du matériel de rechange est disponible, à quelle vitesse un VPS peut être reconstruit, comment les licences sont gérées lors d'un basculement, et si « sans limite » ou « illimité » a des seuils opérationnels au-delà du texte de la politique.
Le quatrième élément est la sauvegarde et la restauration. Un acheteur devrait demander la fréquence des sauvegardes, la rétention, l'emplacement cible, le chiffrement, les vérifications d'intégrité, l'historique des tests de restauration, les droits de téléchargement du client, la priorité de restauration et le coût des restaurations supplémentaires. Si le client a besoin d'une récupération indépendante du fournisseur, il devrait maintenir ses propres sauvegardes en dehors de StormWeb. Si le client a besoin d'une continuité quasi en temps réel, les sauvegardes ordinaires d'hébergement partagé ne suffisent pas.
Le cinquième élément est la maintenance. Les annonces de StormWeb montrent des travaux matériels et de routeur planifiés, ce qui est normal. Les clients devraient demander combien de temps à l'avance la maintenance est annoncée, comment les travaux d'urgence sont gérés, s'il y a des dates d'exclusion, comment la maintenance affecte les crédits SLA, si les charges de travail des clients peuvent être déplacées, et si le fournisseur a un processus de retour arrière testé. Le temps d'arrêt planifié reste du temps d'arrêt pour les utilisateurs du client.
Le sixième élément est la portabilité. Pour l'hébergement web, le client a besoin des fichiers du site, des bases de données, des enregistrements DNS, des boîtes aux lettres, des paramètres de spam et des certificats. Pour le VPS, il a besoin d'images ou de gestion de configuration, pas seulement de sauvegardes de fichiers. Pour le stockage cloud, il a besoin d'exportation en masse, d'historique des versions, de conservation des fichiers supprimés et d'accès propriétaire du compte. Pour les domaines, il a besoin de codes de transfert et de contrôle du compte de registraire.
La localité canadienne est moins utile si la sortie prend trop de temps.
Le septième élément est l'escalade du support. L'acheteur devrait connaître la différence entre le support par ticket, l'aide téléphonique aux heures de bureau, la réponse aux incidents après les heures de bureau, le support de facturation et la restauration d'urgence. Un fournisseur peut avoir un personnel compétent et pourtant créer un goulot d'étranglement lors d'un événement multi-client. Le contrat devrait stipuler qui peut autoriser le travail, comment l'identité est vérifiée et comment le client reçoit les mises à jour lorsque la messagerie elle-même est affectée.
Aucune de ces questions ne suppose la mauvaise foi. Ce sont les éléments de diligence raisonnable ordinaires nécessaires lorsqu'un service hébergé devient une infrastructure opérationnelle. Les preuves publiques de StormWeb sont adéquates pour une liste restreinte d'hébergement normal pour petites entreprises. Elles sont incomplètes pour un acheteur qui souhaite traiter le service comme une plateforme résiliente sans preuve supplémentaire.
Le niveau de preuve doit rester divisé
StormWeb Canada Hosting Inc. dispose de suffisamment de preuves publiques pour éviter le problème de « faible empreinte » qui entoure souvent les petites sociétés d'hébergement. Son site web est actif, son nom d'entreprise et ses coordonnées sont visibles, elle revendique une fondation en 1998 et une propriété canadienne, elle liste des produits hébergés à Vancouver, elle exploite AS14807, elle apparaît dans les données ARIN, PeeringDB, VANIX et BGP, et elle publie des annonces qui incluent des informations de maintenance et d'incident. Cela soutient un niveau de preuve Moyen pour l'identité, le catalogue de services et les opérations réseau.
Le même dossier public laisse les grandes questions de résilience sans réponse. StormWeb ne publie pas d'adresse de centre de données pour les serveurs de production, l'opérateur d'installation pour les charges de travail clients, l'architecture d'alimentation, l'autonomie du générateur, la conception de refroidissement, l'inventaire des racks ou des serveurs, la topologie de stockage, l'isolation des sauvegardes, les statistiques de restauration des clients, l'utilisation des ports d'échange, la diversité physique en amont, la profondeur du personnel de support, ou le plan de reprise multi-site.
Son propre contrat et ses notes d'incident pointent vers les dépendances réelles: maintenance planifiée, services tiers, matériel, logiciel, alimentation, processus de sauvegarde, tickets de support et copies détenues par le client.
La conclusion éditoriale n'est donc pas que StormWeb est dangereux. C'est que StormWeb vend une capacité hébergée ordinaire dont la fiabilité ne peut être déduite de la marque canadienne, des pourcentages de disponibilité ou d'un port d'échange. La capacité devient fiable uniquement lorsque les couches physiques et opérationnelles sont prouvées: racks, alimentation, refroidissement, transit, stock de serveurs, restauration de sauvegarde, contrôles de maintenance et portabilité des données.
Pour de nombreuses petites entreprises, StormWeb peut être un fournisseur d'hébergement canadien raisonnable, en particulier lorsque la localité de Vancouver, la facturation en dollars canadiens, l'enregistrement de domaine, le support géré et la simplicité de l'hébergement partagé sont plus importants que l'ingénierie formelle de haute disponibilité. Pour les clients dont les sites web, boîtes aux lettres, fichiers ou applications sont critiques pour l'entreprise, la posture appropriée est plus stricte.
Utilisez les preuves publiques comme une carte de départ, demandez des preuves privées là où c'est nécessaire, maintenez des sauvegardes indépendantes, testez les restaurations, gardez le DNS et le contrôle de domaine portables, et concevez un second chemin si le temps d'arrêt est coûteux.
Note finale du niveau de preuve: Moyen pour l'identité opérationnelle et la présence réseau; Faible pour la preuve publique de résilience des installations et de récupération client. L'acheteur ne devrait pas confondre le réseau visible de StormWeb avec une plateforme résiliente vérifiée avant que les couches cachées soient documentées et testées.