Sept jours après « Illimité »: Le test de continuité de l'hébergement Web 100 Megs

Résumé

• L'entité exacte est une marque d'hébergement web canadienne utilisant100megswebhosting.com, avec une adresse de contact publique à Edmonton, des traces clients remontant à 2002, un catalogue de services archivé de 2009 à 2010 et une acquisition documentée par Tech Assets en 2011. Les archives disponibles n'établissent pas une société fédérale particulière ni un réseau appartenant à l'entreprise.
• Dès 2010, le nom de la marque avait cessé de décrire le produit: les forfaits mutualisés annonçaient de 10 Go à 250 Go de disque, un forfait annonçait un transfert illimité et les offres dédiées promettaient 2 000 Go. Les limites contraignantes se trouvaient ailleurs: une règle de 4 % des ressources du serveur mutualisé, la compatibilité logicielle, le pouvoir discrétionnaire du support et les conditions d'annulation.
• Le catalogue vendait un flux de travail complet pour petite entreprise via cPanel, PHP, MySQL, e-mail, SSL, tâches planifiées, installateurs d'applications et sauvegardes. Cette commodité concentrait également les coûts de changement, car un site fonctionnel dépendait de bien plus que la copie de ses fichiers publics.
• La vente de 2011 et le récit ultérieur d'un client sur la migration et l'augmentation des frais illustrent l'aspect commercial du risque de continuité. Une acquisition peut préserver le service tout en modifiant le prix, le parcours de support et les incitations autour d'une charge de travail.
• La leçon pratique pour les achats est de tester la propriété, le cycle de vie d'exécution, la politique de ressources, la capacité de restauration, l'emplacement des données et les conditions de sortie avant d'acheter. La capacité est bon marché à renommer; la portabilité répétée est plus difficile à simuler.

Le chiffre le plus important était sept

Le chiffre le plus important dans les documents subsistants de 100 Megs Web Hosting n'est pas 100. C'est sept.

Dans desconditions archivées de 2010, le fournisseur indiquait qu'il ne conservait les archives d'un compte que pendant sept jours après l'annulation. La réactivation durant cet intervalle pouvait entraîner des frais de 50 $, tandis que le client restait responsable de la conservation de ses sauvegardes. Les mêmes conditions précisaient que le fournisseur pouvait être en mesure de restaurer des fichiers automatiquement archivés, mais ne garantissait pas qu'une sauvegarde existerait, serait exacte ou produite régulièrement. Ces clauses définissaient le périmètre réel du service plus clairement que tout quota de disque. Un client pouvait acheter des centaines de gigaoctets et n'avoir qu'une semaine pour découvrir que la copie nécessaire au départ était incomplète.

Ce contraste est la clé pour comprendre 100 Megs Web Hosting Services. L'entrée du répertoire BTWfournit le nom exact de l'entité et la connexion canonique au répertoire. Les pages archivées de l'entreprise raccourcissaient généralement le nom commercial en « 100 Megs Web Hosting » ou « 100Megs Web Hosting ». Le chiffre dans ce nom semblait concret. Il évoquait une époque où une offre d'hébergement pouvait se différencier par une quantité qui paraît aujourd'hui minuscule. Pourtant, en août 2010, le forfait mutualisé le moins cher de l'entreprise annonçait 10 Go de disque — cent fois la quantité suggérée par la marque — et le plus important annonçait 250 Go. Les offres dédiées allaient encore plus loin. L'ancien chiffre était devenu un aide-mémoire, pas une spécification.

Ce n'est pas seulement une histoire amusante sur l'inflation technologique. Une marque figée peut cacher combien d'autres promesses ont changé autour d'elle. Le stockage s'élargit. Les allocations de transfert deviennent « illimitées ». L'installateur d'applications remplace un catalogue logiciel par un autre. Les versions de PHP et des bases de données progressent. Un panneau de contrôle supprime une ancienne fonctionnalité. Un propriétaire de centre de données change. Une société d'hébergement est acquise.

Le client voit toujours le même domaine et une connexion familière, mais le contrat opérationnel sous-jacent peut avoir changé plusieurs fois.

Les preuves sont exceptionnellement révélatrices car le catalogue survivant réunit quatre perspectives souvent séparées: la capacité annoncée, la pile logicielle réelle, la politique d'application du fournisseur et les témoignages de clients. Lues ensemble, elles montrent que l'hébergement était un service de coordination. Il réunissait un nom de domaine, le DNS, des fichiers, des bases de données, des boîtes aux lettres, des certificats, des tâches planifiées, des versions d'applications, des limites de ressources, des files d'attente de support et des règles de facturation.

Le client ne vivait pas ces éléments comme des technologies distinctes. Le client vivait un site web qui continuait à commercer, à publier et à recevoir du courrier, ou pas.

C'est pourquoi sept jours comptent. Cela transforme « sauvegarde incluse » d'une fonctionnalité en une question: incluse pour qui, conservée où, restaurable par qui, et disponible combien de temps après la fin du lien commercial? La même question s'applique à chaque autre élément du lot. « Illimité » n'est pas une réponse de capacité tant que la règle d'utilisation acceptable n'est pas lue. « Migration cPanel » n'est pas une réponse de sortie tant que les extensions non supportées, les bases de données, les enregistrements DNS et le routage du courrier n'ont pas été testés.

« Hébergement canadien » n'est pas une réponse de localisation tant que l'installation physique et le traitement transfrontalier ne sont pas identifiés.

100 Megs est donc précieux non pas parce qu'il était énorme — cela n'a pas été prouvé — ou parce que le nom établit une capacité réseau particulière — ce n'est pas le cas. Il est précieux parce que les archives capturent une petite marque d'hébergement au moment où les allocations brutes devenaient abondantes mais où la continuité opérationnelle restait rare.

Prouver la marque sans inventer une société

La première discipline est l'identité. « 100 megs » est une expression quantitative et pourrait décrire le stockage, le transfert ou la vitesse de ligne. Elle ne peut à elle seule prouver une entreprise, encore moins son envergure. L'identité défendable repose plutôt sur une chaîne d'enregistrements spécifiques à l'entreprise.

L'enregistrement du registre pour100MEGSWEBHOSTING.COMindique une date de création le 16 mars 2001. Un enregistrement de domaine ne prouve pas que le service a commencé ce jour-là, mais il établit une limite inférieure pour l'identité web exacte. Les discussions indépendantes de clients placent ensuite le service en service en 2002. Dans un filPHPBuilder d'octobre 2002, un entité a déclaré héberger sur un compte 100megswebhosting et a décrit un forfait « avancé » à 20 $ par mois avec 1 Go de stockage, 10 Go de transfert mensuel, CGI, PHP, MySQL, un panneau de contrôle, des scripts installables, des statistiques et des journaux d'erreurs. Une autrediscussion Straight Dope d'octobre 2002contient un client disant héberger un site avec 100 Megs Web Hosting et être satisfait du service et du support. Ce sont des déclarations d'utilisateurs, pas des documents d'entreprise audités, mais elles placent indépendamment le domaine exact et le nom du service sur le marché.

Lapage « À propos » archivéede l'entreprise, capturée en juillet 2009, qualifiait 100 Megs Web Hosting d'entreprise canadienne. Elle revendiquait plus de huit ans d'expérience dans le secteur et une clientèle de plusieurs milliers de personnes. La première affirmation est globalement cohérente avec l'enregistrement du domaine en 2001 et les traces clients de 2002. L'affirmation sur le nombre de clients n'est pas vérifiée indépendamment et ne doit pas être utilisée comme mesure de l'ampleur. Lapage de contact archivée, capturée en août 2010, affichait la marque exacte, les adresses de support et de facturation au niveau du domaine, et une adresse postale au 1131, 9363 Simpson Drive à Edmonton, Alberta. Elle utilisait également le pied de page « 100Megs Web Hosting ». Ensemble, ces pages prouvent une marque canadienne tournée vers le public et un contact opérationnel, et non pas simplement une étiquette descriptive de répertoire.

La fin de la période de marque indépendante est plus claire. Tech Assets indique dans sonhistorique d'entrepriseavoir acquis « 100MegsWebHosting » en 2011 et le décrit comme un hébergeur populaire sous cPanel. L'orthographe comprime les espaces, comme le domaine, mais la description cPanel, la chaîne de nom exacte et le calendrier correspondent au service archivé. C'est un pont direct avec l'entreprise. Cela correspond également à la déclaration ultérieure d'un client de 2012 selon laquelle les comptes et sites associés aux « domaines 100megs » avaient été transférés chez Jumpline, la marque d'hébergement d'origine de Tech Assets.

Il y a une limite importante. Une recherche dans la base de données fédérale officielleCorporations Canadapour le nom exact n'a donné aucun résultat lors de cette recherche. La base de données elle-même précise qu'elle exclut les sociétés provinciales et territoriales, les sociétés financières et les sociétés étrangères. Un résultat nul ne peut donc pas prouver qu'aucune entité légale n'existait. Cela signifie seulement que les preuves publiques rassemblées ici ne justifient pas de nommer un propriétaire fédéralement constitué en société. De plus, le site archivé n'ajoute pas systématiquement « Inc. » ou un numéro de société. La formulation défendable est que 100 Megs Web Hosting Services était une marque opérationnelle canadienne, joignable publiquement via une adresse à Edmonton, dont le propriétaire légal exact avant la vente de 2011 reste non confirmé dans les sources utilisées ici.

La fenêtre opérationnelle documentée doit être délimitée avec autant de soin. Le domaine a été créé en 2001. Des clients ont discuté de l'utilisation du service en 2002. Des pages de l'entreprise survivent de 2009 et 2010. Tech Assets enregistre une acquisition en 2011. Cela soutient une période d'activité d'au moins 2002 à 2011, avec la preuve du domaine suggérant une préparation ou un lancement dès 2001. Cela ne soutient pas une affirmation concernant un prédécesseur à la fin des années 1990, un jour de fondation précis, un chiffre d'affaires annuel, un effectif ou le nombre de serveurs.

Ces détails attrayants apparaissent dans des listes faibles et des biographies autodéclarées, mais le pont fiable ne les exige pas.

Cette identité plus restreinte est encore suffisante pour étudier l'entreprise. Les marques sont de véritables surfaces commerciales même lorsque leur enveloppe juridique est obscure. Les clients payaient la marque, ouvraient des tickets de support sous la marque, utilisaient ses serveurs de noms et son panneau de contrôle, se fiaient à ses politiques et rencontraient plus tard un successeur. L'erreur analytique serait de transformer cette réalité en une précision d'entreprise fictive.

Une vitrine canadienne sur une surface opérationnelle au Colorado

Le site archivé établissait une distinction claire entre l'endroit où le vendeur se présentait et l'endroit où les machines fonctionnaient. Sa page « À propos » indiquait que le réseau était hébergé dans l'installation Data393 du Denver Tech Center à Englewood, Colorado. Elle vantait une alimentation électrique redondante de secours et de groupe électrogène, des contrôles environnementaux, une détection d'incendie, un accès biométrique et par carte, une vidéosurveillance et des armoires verrouillées.

En matière de connectivité, elle nommait Savvis et Internap, décrivait une connexion Internap à proximité, et listait des pare-feu Fortigate et des commutateurs HP ProCurve. Elle précisait également que les serveurs étaient surveillés 24h/24 et que sa configuration normale utilisait Red Hat Linux.

La plupart de ces détails sont des affirmations de l'entreprise. Ils ne doivent pas être transformés en une conclusion sur la disponibilité ou une certification. Il existe cependant une confirmation indépendante que l'installation nommée et ses capacités physiques générales existaient à l'époque concernée. Uneannonce de Data393 de juillet 2008rapportait une extension de 10 000 pieds carrés sur son site de Denver Tech Center, portant la surface sur dalle surélevée à environ 30 000 pieds carrés. Elle décrivait une alimentation haute densité et un refroidissement, six générateurs de 600 kW en parallèle avec redondance N+1, de la colocation en armoire et en cage, et l'acquisition de Data393 par Managed Data Holdings en décembre 2007. Comme il s'agit d'un communiqué de l'exploitant de l'installation, il corrobore l'installation plutôt que de prouver indépendamment chaque configuration de 100 Megs à l'intérieur.

Les archives fournissent une autre connexion technique. Common Crawl a récupéré les pages de l'entreprise de 2009 et 2010 depuis209.197.254.38. L'enregistrement ARIN RDAP actuel pour cette adressela place dans l'assignation nomméeD393-ENG01-209-197-254-0-25. Le titulaire actuel n'est pas 100 Megs, et un enregistrement actuel ne peut pas reconstruire l'assignation telle qu'elle était en 2010. Le nomD393est cohérent avec le compte Data393 archivé, mais c'est une corroboration de localisation, pas une preuve que 100 Megs possédait le bloc d'adresses.

Aucun système autonome spécifique à l'entreprise ni allocation d'adresse directe n'est établi par cet enregistrement. Cette absence est importante. Les petits fournisseurs d'hébergement louaient fréquemment des armoires, des serveurs, du transit ou des services gérés auprès d'un plus grand centre de données et opérateur réseau. Leur valeur résidait dans le packaging et l'exploitation de la couche client, pas dans la possession de fibre ou l'annonce de routes.

Le site archivé lui-même parlait de son réseau et de ses serveurs dans un langage marketing, mais l'interprétation plus prudente est que 100 Megs contrôlait un service d'hébergement fourni sur une infrastructure et une connectivité fournies par d'autres.

Cette structure de dépendance change la façon dont l'échelle doit être lue. Un fournisseur peut servir de nombreux domaines sans posséder de centre de données. Il peut annoncer plusieurs chemins montants sans détenir son propre numéro de réseau. Il peut offrir un serveur dédié tout en louant le rack, l'alimentation et le transit en dessous. Rien de tout cela ne rend le service irréel. Cela signifie que l'approvisionnement doit séparer la responsabilité opérationnelle de la propriété des actifs. En cas de panne de courant, qui détient le contrat de l'installation? Si une route montante se dégrade, qui peut la modifier?

Si l'équipe de support du revendeur constate un problème, quel fournisseur touche réellement au commutateur ou au serveur? La marque possède la promesse client même lorsqu'une autre entreprise possède le sol opérationnel.

La division Canada-Colorado anticipe également une question moderne du cloud: la juridiction suit les données et les contrats, pas les slogans. « Canadien » indiquait aux acheteurs où le fournisseur s'identifiait. « Emplacements de centres de données à Denver au service du monde », utilisé dans les métadonnées du site, leur disait quelque chose de différent sur le traitement. Les deux pouvaient être vrais. Aucun ne répondait à lui seul à la question de savoir quelle loi régissait un litige, où se trouvaient les sauvegardes, ou quels sous-traitants pouvaient accéder aux informations des clients.

Ces réponses étaient dispersées dans les conditions, la page de confidentialité et la description de l'infrastructure.

Ce que le catalogue vendait réellement en 2010

Lapage d'hébergement mutualisé archivéeprésentait trois forfaits en août 2010. Le forfait Value coûtait 5 $ par mois ou 50 $ par an, avec 10 Go de disque, 50 Go de transfert et un domaine hébergé. Le forfait Pro coûtait 10 $ par mois ou 100 $ par an, avec 100 Go de disque, 250 Go de transfert et cinq domaines. Le forfait Ultra coûtait 20 $ par mois ou 200 $ par an, avec 250 Go de disque, transfert « illimité » et 30 domaines. La page n'établissait pas de devise dans le tableau capturé, donc la description prudente est une tarification en dollars plutôt qu'une hypothèse sur des dollars canadiens ou américains.

La progression révèle la logique de l'hébergement mutualisé de l'époque. Chaque palier achetait plus que de la capacité. Value incluait deux bases de données MySQL et cinq boîtes aux lettres POP; Pro les portait à dix bases de données et 25 boîtes aux lettres; Ultra annonçait les deux comme illimités. Les trois incluaient cPanel, CGI, Perl, PHP, les extensions FrontPage 2000, SSL partagé, un panier d'achat, des statistiques, des tâches planifiées, un filtre anti-spam, un constructeur de site, une sauvegarde en ligne, une sauvegarde quotidienne et Fantastico.

Le SSL personnalisé et l'accès shell n'apparaissaient que comme options sur les forfaits supérieurs. L'accès WebHost Manager était également optionnel sur Pro et Ultra. Le fournisseur proposait de transférer les clients existants vers un nouveau forfait comparable sur demande, une reconnaissance précoce que même une refonte du tableau des forfaits pouvait nécessiter une transition opérationnelle.

Fantastico faisait ressembler le compte d'hébergement à une boutique d'applications avant que cette expression ne devienne courante. La page archivée listait WordPress, Drupal, Joomla, Mambo, phpBB2, Simple Machines Forum, osCommerce, Zen Cart, CubeCart, des bureaux de support, des outils de projet, des wikis, des programmes de facturation et des sondages. Une petite organisation n'avait pas à se procurer chaque composant séparément. Elle pouvait choisir un script, laisser l'installateur déposer des fichiers et une base de données, connecter le courrier et un domaine, et commencer à publier ou à vendre.

Au-dessus de l'hébergement mutualisé se trouvait unepage de serveur dédié virtuel. Elle proposait un « VDS Power 300 » à 60 $ par mois avec 10 Go de disque, 300 Go de transfert, 256 Mo de mémoire, une allocation processeur de 600 MHz, CentOS, accès root, cPanel et WHM, domaines illimités et Fantastico. La page capturée indiquait que le forfait était épuisé. Ce détail est plus informatif qu'une affirmation générique de disponibilité: le fournisseur avait construit un palier de mise à niveau mais n'offrait pas de capacité dessus à ce moment-là.

Lapage de serveur dédiéproposait trois configurations. Un forfait nommé Cloud était listé à 135 $ par mois avec un disque de 400 Go, 1 Go de mémoire et un processeur Intel 2,2 GHz. Premium était à 199 $ avec deux disques de 500 Go, 2 Go de mémoire et un Core 2 Duo 2,4 GHz. Enterprise était à 349 $ avec deux disques de 500 Go, 2 Go de mémoire et deux Xeon double cœur 2,8 GHz. Tous annonçaient 2 000 Go de transfert, des sauvegardes quotidiennes, des domaines illimités, cPanel et WHM, accès root, Fantastico, pas de frais d'installation et une garantie de 30 jours.

Le nom « Cloud » ne doit pas être interprété comme une preuve d'architecture élastique ou distribuée. Sur la page, c'était simplement la configuration dédiée d'entrée de gamme. Aucune preuve n'y décrit un basculement automatique, une facturation à l'usage, une interface d'application ou une mise à l'échelle horizontale rapide. L'entreprise annonçait également un choix Linux et nommait Savvis, Internap et Level 3 en relation avec le service dédié, mais n'a pas publié de mesures de routage ni de calcul de niveau de service dans le matériel capturé.

L'offre revendeurcomplétait le catalogue. Un revendeur pouvait vendre les trois forfaits mutualisés sous son propre nom à 25 % en dessous du prix de détail, fixer le prix final du client et utiliser WebHost Manager et des serveurs de noms privés. Le revendeur gérait le support de premier niveau; 100 Megs fournissait l'administration système et l'assistance de deuxième niveau. Il n'y avait pas d'obligation d'acheter un gros bloc à l'avance, et le fournisseur disait mettre à jour la facturation du revendeur mensuellement.

Pris ensemble, ce n'étaient pas quatre produits indépendants. C'était un chemin d'escalade. Un client pouvait commencer sur un compte mutualisé à bas coût, ajouter des domaines et des bases de données, devenir revendeur, rechercher un serveur virtuel pour le contrôle, ou passer à une machine dédiée. cPanel et le catalogue d'applications familier réduisaient la distance visible entre les niveaux. Cette continuité était commercialement utile, mais elle maintenait également les connaissances opérationnelles du client liées à une seule famille d'outils et de conventions.

L'économie de l'hébergement se cachait derrière des quotas généreux

Les forfaits mutualisés semblent étonnamment généreux par rapport à leurs prix, en particulier le compte Ultra de 250 Go. Mais le disque n'était qu'un intrant, et rarement le plus contraignant. Une société d'hébergement pouvait allouer bien plus de disque nominal et de transfert que ce que chaque client utiliserait simultanément. Ce qu'elle ne pouvait pas ignorer, c'était la demande de pointe en processeur, la pression mémoire, la contention des bases de données, la réputation du courrier, la main-d'œuvre de support, le stockage de sauvegarde et le risque opérationnel introduit par des scripts vulnérables.

100 Megs rendait cette distinction explicite dans sapolitique d'utilisation acceptable archivée. Un script ou un processus sur la plateforme mutualisée ne pouvait pas utiliser plus de 4 % des ressources système disponibles à un moment donné. La règle s'appliquait même si le client restait dans les limites de disque et de transfert. Le fournisseur se réservait le pouvoir discrétionnaire sur la réponse et avertissait que les services étaient destinés au contenu de sites web plutôt qu'à des archives sans rapport, des logiciels ou des fichiers multimédias volumineux.

Ainsi, « bande passante illimitée » ne signifiait pas une puissance de calcul illimitée ou un usage de stockage sans restriction. Cela signifiait que le fournisseur avait supprimé un compteur du tableau des forfaits tout en conservant des contrôles ailleurs. Le compromis économique était probabiliste: la plupart des sites seraient calmes la plupart du temps; un petit nombre d'applications actives ou inefficaces pouvaient menacer le serveur mutualisé; la direction se réservait la possibilité d'intervenir. L'acheteur qui ne comparait que les gigaoctets manquait la variable la plus susceptible d'interrompre le service.

L'offre revendeur accentuait la même économie. Une remise de gros de 25 % créait de la marge pour les ventes et le support, mais le revendeur acceptait la responsabilité de premier niveau. Chaque paramètre de courrier confus, réinitialisation de mot de passe et échec d'application pouvait consommer cette marge. 100 Megs conservait la couche d'administration système, là où les économies d'échelle étaient les plus fortes. Le revendeur conservait la conversation client, là où les coûts étaient volatils et difficiles à automatiser.

cPanel lui-même a depuis rendu un autre facteur de coût plus visible. Songuide de licence actuelindique que le prix de la licence est basé sur le nombre de comptes sur un serveur, avec des niveaux et un traitement par compte au-delà de seuils spécifiés. Il s'agit d'une politique actuelle, non d'une preuve de la facture de licence de 100 Megs en 2010. Elle montre néanmoins comment un panneau de contrôle qui simplifie les opérations multi-locataires peut devenir une unité de coût en soi. L'économie d'un fournisseur change lorsque la couche de gestion, les extensions de sécurité, le stockage de sauvegarde et le support sont facturés par compte tandis que les clients s'attendent toujours à des frais fixes peu élevés.

Le niveau dédié déplaçait certaines contraintes plutôt que de les éliminer. L'accès root réduisait le contrôle du fournisseur sur les logiciels installés. Il transférait également plus de responsabilité au client. La page annonçait des ajouts gérés et du support, mais elle ne définissait pas quelles mises à jour, réponse aux incidents ou réparations d'applications étaient incluses dans le prix de base. Deux clients payant pour du matériel identique pouvaient générer des coûts de support très différents selon leurs applications et compétences.

La leçon durable est que la capacité bon marché peut coexister avec une continuité coûteuse. Le fournisseur gagne une marge en normalisant les tâches courantes et en contrôlant les usages exceptionnels. Le client gagne de la valeur en évitant l'administration du serveur. Les frictions apparaissent là où chaque partie croit que l'autre possède l'exception: un script actif, une application obsolète, une restauration échouée, une liste noire de courrier, un certificat personnalisé ou une migration qui ne correspond pas à l'outil normal.

Le flux de travail du client était une chaîne, pas un dossier

Un site web de petite entreprise chez 100 Megs pouvait commencer par une action trompeusement simple: pointer un domaine vers le fournisseur et télécharger des fichiers. Le catalogue invitait ensuite le client à ajouter des couches. Créer une base de données MySQL. Installer WordPress, un forum ou un panier d'achat via Fantastico. Ajouter des boîtes aux lettres POP et des règles de redirection. Planifier un script de maintenance. Activer un certificat. Lire les statistiques de trafic. Sauvegarder via le panneau de contrôle. Peut-être héberger plusieurs domaines, puis revendre des comptes à des clients.

Chaque étape était pratique car cPanel la présentait en un seul endroit. Chacune créait également un état qui devait être compris lors d'une panne ou d'un départ. Les fichiers publics n'étaient qu'une partie. Un site dynamique avait besoin du contenu de la base de données et des identifiants. La continuité du courrier dépendait des données des boîtes aux lettres, des alias, des redirections, des filtres et des enregistrements MX. Les tâches planifiées vivaient en dehors de l'arborescence des documents. Les clés de certificat et les procédures de renouvellement avaient leur propre cycle de vie.

Un forum ou une boutique dépendait du comportement précis des extensions PHP, des permissions de fichiers et des versions de bases de données. Le contrôle du domaine pouvait résider chez l'hébergeur, un revendeur ou le client.

Les traces contemporaines de clients montrent cet ensemble en usage. Le entité de PHPBuilder en 2002 ne vantait pas seulement le disque; il listait PHP, MySQL, le panneau de contrôle, les scripts installables, les statistiques, les journaux d'erreurs et les contrôles d'accès. Le client de Straight Dope évaluait également le service et le support en plus de la capacité. Ces témoignages sont subjectifs, mais ils démontrent ce que les acheteurs considéraient comme le produit.

Unediscussion sur le forum osCommerce d'avril 2006illustre la limite de l'expérience gérée. Un utilisateur a identifié 100 Megs comme hébergeur et a décrit avoir été dirigé vers une installation osCommerce après qu'un problème de renouvellement SSL ait affecté un panier existant. L'utilisateur n'était alors pas sûr de la manière dont les paramètres du compte marchand et de paiement s'assemblaient. Il s'agit du témoignage d'un seul client, sans réponse du fournisseur, donc il ne peut établir une défaillance générale du service. Il montre comment un installateur fourni par l'hébergeur pouvait faciliter le déploiement tout en laissant la configuration critique de l'entreprise au client.

La même complexité apparaissait dans des changements anodins. Un site qui analysait PHP à l'intérieur de fichiers se terminant par.htmlpouvait fonctionner car Apache traitait ces fichiers via un gestionnaire particulier. Changez la façon dont PHP fonctionne et les pages peuvent exposer du code ou cesser de s'exécuter. Un script de maintenance planifié peut être essentiel même si aucun visiteur ne le voit. Une règle de courrier sortant peut briser les confirmations de commande pendant que le site web reste visiblement en ligne. Un domaine peut continuer à résoudre vers une page statique tandis que le système de facturation, le panier ou la boîte aux lettres derrière a échoué.

Cette chaîne explique pourquoi « migration incluse » n'est pas auto-défini. Un transfert peut copier les fichiers du compte et encore omettre un identifiant de bureau d'enregistrement, une zone DNS externe, un paramètre de paiement tiers, un composant FrontPage non supporté ou une archive de courrier locale. Il peut préserver les données mais modifier le timing, les permissions ou le traitement des caractères. Il peut déplacer le site web et laisser l'ancien serveur de courrier accepter des messages. Le client a besoin d'une carte des dépendances, pas seulement d'un répertoire home compressé.

Lapage de support archivéerévèle que 100 Megs disposait d'un système de tickets, d'annonces et d'une base de connaissances divisée en catégories pré-vente, facturation, courrier et configuration. C'est la forme d'une entreprise essayant de transformer une chaîne hétérogène en demandes répétables. Pourtant, les noms de catégories révèlent également les transferts: un problème de facturation et un problème de routage de courrier peuvent avoir le même symptôme pour le client — le service s'est arrêté — mais passer par des files d'attente différentes et nécessiter des autorités différentes.

Pour une PME, la capacité d'hébergement la plus précieuse n'est donc pas la plus grande allocation. C'est un inventaire maintenu de tout ce qui est nécessaire au résultat commercial. Le site, le courrier, le domaine, la base de données, le certificat, le travail planifié et les connexions tierces doivent avoir des propriétaires nommés et des chemins d'exportation. Le catalogue de 100 Megs les rendait tous accessibles. Ses politiques indiquaient clairement que la responsabilité de les préserver ne disparaissait pas.

La pile logicielle portait des dates d'expiration que la marque ne portait pas

Les captures Common Crawl exposent plus que le texte des pages. Leurs en-têtes de réponse HTTP identifient le logiciel présentant le site de l'entreprise lui-même. La réponse de juillet 2009 pour la page « À propos » signalait Apache 1.3.41, PHP 4.4.9, les extensions FrontPage 5.0.2, OpenSSL 0.9.7a et des modules associés. En août 2010, les pages de service capturées signalaient encore Apache 1.3.41 et les mêmes générations FrontPage et OpenSSL, tandis que PHP était passé à 5.2.11.

Ces observations décrivent le serveur qui renvoyait les pages marketing, pas nécessairement chaque machine cliente. Elles ne prouvent pas qu'une application cliente particulière était vulnérable ou que des correctifs étaient absents. Elles prouvent quelque chose de plus fondamental: le service dépendait de composants versionnés qui ne pouvaient pas rester immobiles simplement parce que la marque ne bougeait pas.

Lapolitique de support actuelle de PHPaccorde à chaque branche de version deux ans de support complet suivis de deux ans de support de sécurité critique avant la fin de vie. Lesexigences actuelles de WordPressrecommandent PHP 8.3 ou ultérieur, MariaDB 10.11 ou MySQL 8.0 ou ultérieur, et HTTPS. WordPress prévient que les versions héritées PHP 7.4 et MySQL 5.5.5 peuvent encore fonctionner mais ne sont plus supportées et peuvent exposer un site à des risques de sécurité. Ces références actuelles ne doivent pas être projetées en arrière comme un verdict sur un hébergeur de 2010. Elles montrent la distance qu'un patrimoine client de longue durée doit parcourir.

La migration n'est pas une simple mise à niveau de numéros de version. Les applications écrites pour PHP 4 ou PHP 5 peuvent reposer sur des fonctions supprimées, une gestion d'erreurs laxiste, d'anciennes bibliothèques de bases de données ou des hypothèses sur le comportement des chaînes et des variables. Un thème de forum ou une extension de panier d'achat peut être abandonné même si l'application principale survit.

L'hébergeur a trois choix peu attrayants: conserver un environnement d'exécution ancien, forcer une mise à niveau qui peut casser les sites clients, ou isoler les charges de travail héritées tout en facturant suffisamment pour les exploiter en toute sécurité.

Lapolitique actuelle de fin de vie des logiciels tiers de cPanelrend explicite le côté du fournisseur. Lorsqu'un fournisseur amont cesse les mises à jour, cPanel peut supprimer le logiciel et cesser de le supporter. Lorsqu'un système d'exploitation atteint sa fin de vie, les installations existantes peuvent continuer à fonctionner, mais les nouvelles installations, les mises à niveau et les correctifs spécifiques au système d'exploitation peuvent être bloqués. Dans certains cas, le chemin recommandé est de provisionner un nouveau serveur et de migrer les comptes et la configuration du service.

FrontPage est un pont particulièrement concret du catalogue de 100 Megs aux limites modernes de migration. Les forfaits mutualisés de 2010 annonçaient encore les extensions FrontPage 2000. Ladocumentation actuelle de l'outil de transfert cPanelindique que cPanel ne supporte pas FrontPage et ne restaure pas les fichiers et répertoires spécifiques à FrontPage; elle recommande fortement de désactiver FrontPage avant le transfert. Une fonctionnalité autrefois imprimée dans chaque colonne de forfait est devenue plus tard une donnée que le chemin de migration standard laisserait intentionnellement derrière.

C'est un verrouillage logiciel sans langage de programmation propriétaire. Le client peut posséder le contenu PHP et de la base de données tout en étant verrouillé sur un environnement étroit car la mise à niveau de toutes les dépendances à la fois est risquée. Le fournisseur peut préférer conserver l'ancien environnement car la migration consomme de la main-d'œuvre et crée des appels de support. Les deux parties reportent le changement jusqu'à ce qu'une échéance de sécurité, une acquisition ou un mouvement matériel comprime le calendrier.

L'ancienne marque amplifie l'illusion de stabilité. Si « 100 Megs » répond encore au téléphone, un client peut supposer que le service est le même. En réalité, la continuité nécessite des substitutions répétées: branche PHP pour branche PHP, moteur de base de données pour moteur de base de données, installateur pour installateur, processus de certificat pour processus de certificat et serveur pour serveur. Un bon hébergement cache ces substitutions à l'usage ordinaire. Une bonne gouvernance les enregistre afin que le travail caché ne devienne pas un risque caché.

« Illimité » rencontrait une règle de 4 %

La clause de 4 % des ressources est le point où la capacité marketing rencontrait l'ingénierie multi-locataire. Elle stipulait qu'un script ou un processus de compte mutualisé pouvait violer la politique à tout instant même si le client n'avait pas épuisé le disque ou le transfert. Cela peut sembler dur, mais une certaine limite était inévitable. Un seul processus incontrôlé ou une requête de base de données coûteuse peut dégrader des centaines de sites voisins.

Le problème n'était pas l'existence d'une limite. C'était l'écart entre le langage du tableau des forfaits et la règle opérationnelle. « Bande passante illimitée » encourage un acheteur à penser en volume de trafic. La politique d'utilisation acceptable régissait le comportement du CPU, de la mémoire, du réseau et du stockage et laissait le remède à la discrétion de la direction. Un client pouvait rester sous le compteur visible et quand même franchir le compteur invisible.

Un témoignage à la première personne de 2009 sur leTech Blog de TulsaMJraconte que 100 Megs avait arrêté des scripts de maintenance planifiés sans préavis, puis arrêté d'autres scripts et finalement suspendu le compte de l'auteur. L'auteur a déclaré que les sites avaient été réactivés puis déplacés ailleurs. Il n'y a pas de réponse de 100 Megs ni de télémétrie serveur, donc le récit ne peut montrer si chaque intervention était justifiée. Il est utile car il décrit l'incertitude du client: la charge de travail dépendait de scripts dont l'état opérationnel n'était pas évident jusqu'à ce que le fournisseur agisse.

La réponse d'achat correcte n'est pas d'exiger un serveur mutualisé littéralement illimité. C'est de demander une politique de ressources observable et progressive. Quelles mesures sont utilisées — CPU moyen, CPU de pointe, mémoire, nombre de processus, temps de base de données ou entrées/sorties? Sur quel intervalle? Le client les voit-il? Y a-t-il un avertissement avant la suspension? Un pic peut-il être toléré? Un passage à un serveur virtuel est-il proposé? À quelle vitesse les données peuvent-elles être récupérées si le compte est désactivé?

100 Megs invitait les clients ayant des questions sur les ressources à contacter le support à tout moment, et ses niveaux virtuels et dédiés offraient une voie de mise à niveau. Mais le forfait VDS capturé était épuisé. Cela expose un autre problème de continuité: un chemin d'escalade sur une carte de produits n'est pas utile si la capacité n'est pas disponible lorsqu'un client en pleine croissance en a besoin. Un acheteur devrait tester non seulement si le niveau suivant existe, mais comment la migration fonctionne, combien de temps prend le provisionnement et ce qui se passe si ce niveau est contraint.

Le nom de la marque rend la leçon exceptionnellement nette. La quantité annoncée dans un nom ou un forfait est rarement la quantité qui régit la défaillance. Le stockage était abondant. La contention mutualisée, la compatibilité et l'attention du support étaient rares. Les offres modernes « non mesurées » répètent le même modèle chaque fois que des conditions d'utilisation équitable, des limites d'inodes, des limites de workers ou des plafonds de base de données se trouvent en dehors du titre.

Le support faisait partie du plan de contrôle

100 Megs annonçait un support par e-mail 24 heures sur 24, un service d'assistance en ligne, des annonces et une base de connaissances. L'arrangement de revendeur divisait délibérément le support: le revendeur répondait au client en premier, tandis que 100 Megs gérait l'administration système et les problèmes de deuxième niveau. Cette conception n'était pas une décoration administrative. C'était ainsi que l'autorité opérationnelle voyageait.

Considérez un échec de paiement. Le revendeur pourrait inspecter l'application et les paramètres de paiement. 100 Megs pourrait inspecter PHP, le certificat ou un processus bloqué. Data393 pourrait posséder l'intervention physique. Un fournisseur de réseau pourrait posséder un défaut de routage. Le client, cependant, avait une seule panne. La qualité du service dépendait du diagnostic traversant ces frontières sans perdre le contexte.

Les premiers témoignages sur les forums sont favorables: un client qualifiait l'hébergeur de « globalement bon », un autre disait être satisfait du service et du support. Le récit de migration de 2009 est négatif et décrit une intervention silencieuse. Aucun des deux côtés n'établit un temps de réponse moyen ou un taux d'incidents. Ensemble, ils montrent pourquoi les témoignages ne peuvent pas remplacer la conception du support. Un hébergeur peut avoir des utilisateurs satisfaits et quand même créer un risque sérieux pour une charge de travail qui sort des pratiques standard.

Les catégories de la page de support — configuration, courrier, facturation et pré-vente — suggéraient une surface conventionnelle et organisée. Ce qui manque dans les archives publiques est tout aussi important: aucun engagement de niveau de service préservé pour l'accusé de réception ou la restauration des tickets, aucune définition de gravité, aucune procédure d'escalade publiée et aucune délimitation claire du travail géré sur les forfaits dédiés. L'absence de ces sources ne prouve pas que l'entreprise manquait de procédures privées. Cela signifie qu'un acheteur ne pouvait pas les déduire en toute sécurité du tableau des forfaits.

Pour une PME, le support doit être évalué comme un système de contrôle. L'acheteur peut-il ouvrir un ticket lorsque le domaine principal ou la boîte aux lettres est hors service? Existe-t-il un contact hors bande? Le fournisseur conserve-t-il un historique des modifications horodaté? Le personnel de facturation peut-il empêcher une suspension automatique pendant qu'un litige technique est examiné? Un revendeur peut-il escalader directement? Qui peut autoriser la restauration à partir d'une sauvegarde? Quelle preuve est fournie après un incident?

La valeur d'un petit hébergeur réside souvent précisément dans l'aide humaine. Le client peut le choisir parce que quelqu'un peut réparer une erreur de permission ou expliquer un changement DNS. Cet avantage ne devient durable que lorsque le chemin d'aide est documenté et portable. Si toutes les connaissances opérationnelles vivent dans d'anciens tickets, une acquisition ou un départ de personnel peut effacer le contexte même si chaque fichier survit.

L'identité canadienne ne signifiait pas des données canadiennes

La page de contact archivée plaçait la marque à Edmonton. La page « À propos » plaçait l'infrastructure au Colorado. Lapolitique de confidentialité archivéedu site indiquait que le fournisseur collectait et stockait les noms, adresses, numéros de téléphone, informations de carte de crédit, statut du compte, choix de services, journaux, e-mails et autres communications dans le cadre du service. Elle précisait que les informations des clients pouvaient être partagées avec des partenaires sélectionnés, utilisées pour les communications de service et de produit, et divulguées dans des circonstances légales ou de protection spécifiées.

Ces déclarations rendent la géographie opérationnelle. Un client canadien pouvait fournir des données de facturation et de communication à une marque canadienne tandis que le contenu du site web et les journaux de service étaient traités aux États-Unis. Un revendeur pouvait ajouter une autre couche contractuelle. Un site de commerce électronique pouvait introduire des services de paiement et des enregistrements de clients que l'hébergeur ne contrôlait pas entièrement.

Les orientations actuelles duCommissariat à la protection de la vie privée du Canadaindiquent qu'une organisation reste responsable des informations personnelles transférées à un tiers pour traitement. Pour un traitement en dehors du Canada, elle recommande une évaluation des risques, une protection comparable par des moyens contractuels ou autres, des limites d'utilisation et une transparence sur l'accès étranger. Il s'agit d'orientations actuelles et ne doivent pas être traitées comme une conclusion rétrospective selon laquelle 100 Megs se conformait ou ne se conformait pas en 2010.

Ce que le matériel historique permet, c'est une conclusion d'achat. « Canadien » n'était pas une preuve suffisante de résidence des données. Un acheteur devait demander où le site principal, le courrier, les données du panneau de contrôle et les sauvegardes étaient stockés; quelle entreprise exploitait chaque couche; quel processus juridique pouvait y accéder; et si le même emplacement s'appliquait après un basculement ou une restauration.

Les conditions archivées compliquaient encore le tableau en choisissant les lois des États-Unis, malgré l'identité canadienne. La clause ne précisait pas d'État dans le texte capturé. L'interprétation juridique nécessiterait le contrat complet et un avis professionnel, mais le décalage lui-même était un avertissement pour lire au-delà de l'adresse. La nationalité de la marque, l'emplacement du serveur, la loi applicable et la responsabilité en matière de confidentialité sont quatre attributs différents.

Cela reste pertinent car l'hébergement « local » est souvent vendu comme une confiance. Le support local et la facturation locale peuvent être véritablement précieux. Ils n'impliquent pas automatiquement une infrastructure locale ou une juridiction unique. Le bon test suit chaque catégorie de données à travers la collecte, le traitement, la sauvegarde, l'accès au support, la divulgation et la suppression. Les propres pages de 100 Megs contenaient suffisamment d'informations pour révéler la division, mais un client devait assembler les pages.

L'acquisition de 2011 a transformé la continuité en migration

L'acquisition de 2011 par Tech Assets est le changement commercial crucial. L'historique de l'acheteur met l'accent sur des acquisitions répétées d'hébergement et une capacité de migration. Il avait lancé Jumpline en 1997, transféré sa clientèle vers une plateforme virtualisée en 2002 et acquis une série d'hébergeurs spécialisés et cPanel avant d'acheter 100MegsWebHosting. Cela rend l'achat lisible comme une transaction de portefeuille: la clientèle, la facturation récurrente et les charges de travail cPanel pouvaient être déplacées vers un système d'exploitation plus vaste.

L'acquisition peut améliorer la continuité. Un propriétaire plus grand peut offrir une infrastructure plus récente, un meilleur pouvoir d'achat, un support plus large et une sécurité plus disciplinée. Elle peut également modifier le contrat commercial tout en laissant le service technique en ligne. Les clients peuvent faire face à un nouveau portail, un cycle de renouvellement, une équipe de support, une correspondance de forfaits ou un prix.

La migration peut être réussie au sens étroit — les fichiers et les domaines fonctionnent toujours — tout en étant perturbatrice au sens large où le service ne correspond plus à la raison pour laquelle le client l'a acheté.

Un avis de juillet 2012 sur lapage Jumpline de WHTopdonne un témoignage client spécifique. L'auteur de l'avis a déclaré qu'une société qu'il appelait « domaines 100megs » avait été vendue à Jumpline, que les domaines et sites hébergés avaient été transférés, que l'hébergement annuel était passé de 60 $ à plus de 130 $, et que le coût de renouvellement du domaine avait augmenté. L'auteur a déclaré avoir ensuite transféré les domaines vers un autre bureau d'enregistrement et l'hébergement ailleurs. Il s'agit d'une seule plainte non vérifiée déposée sur un site d'avis. Elle n'établit pas une tarification universelle, la date exacte de la migration ni une rupture contractuelle. Elle corrobore au niveau du client qu'une charge de travail de 100 Megs a atteint Jumpline après l'acquisition documentée, et elle montre les dimensions selon lesquelles le client a jugé la continuité.

La chaîne d'entreprise a ensuite de nouveau bougé. Lapage client actuelle de Jumplineindique que Jumpline fait partie de la famille HostPapa et fournit un chemin de connexion pour les clients existants. Elle précise que les fichiers et le contenu du site web restent accessibles, qu'il n'y a pas de changements immédiats de service ou de prix, et que les ajustements futurs seront communiqués. Cette page ne prouve pas qu'un compte spécifique de 100 Megs reste actif en 2026. Elle établit la surface de successeur actuelle pour Jumpline et illustre comment une marque d'hébergement peut persister comme porte d'accès client après des changements de propriété.

L'avis de 2012 est particulièrement révélateur lorsqu'on le met en regard du catalogue de 2010. Le prix annuel du forfait Value était de 50 $ et celui du Pro de 100 $. Le passage signalé par un client de 60 $ à plus de 130 $ ne serait pas simplement une inflation de la capacité disque; ce serait une refonte de l'ensemble du lot. Peut-être que le successeur incluait des fonctionnalités dont le client n'avait pas besoin. Peut-être que sa structure de coûts était différente. Les preuves publiques ne peuvent pas arbitrer la raison. Ce qui importe, c'est que le coût de changement a donné au successeur la marge pour modifier l'offre.

Un client devait séparer les domaines, l'hébergement et l'état de l'application avant que la concurrence par les prix ne redevienne effective.

Les clauses d'acquisition méritent la même attention que les clauses de sauvegarde. Les conditions de 2010 permettaient à 100 Megs de céder le contrat tout en restreignant la capacité du client à le faire. Cette asymétrie est courante dans les contrats de service, mais elle signifie que le fournisseur peut changer la contrepartie sans que le client change la charge de travail. Un plan de continuité doit donc anticiper un changement d'entreprise aussi bien qu'une panne matérielle.

La question appropriée n'est pas « Cet hébergeur sera-t-il un jour acquis? » C'est « Que pouvons-nous déplacer indépendamment s'il l'est? » L'enregistrement du domaine, l'autorité DNS, les sauvegardes hors fournisseur, la documentation de l'application et les enregistrements de facturation créent un pouvoir de négociation. Sans eux, même une migration techniquement compétente peut laisser le client commercialement captif.

La sortie était un inventaire de données, pas un bouton de téléchargement

Les conditions historiques donnaient aux clients une capacité de sauvegarde via le panneau de contrôle tout en désavouant la régularité et l'exactitude des sauvegardes du fournisseur. Cet arrangement n'était rationnel que si les clients exportaient et testaient réellement leurs propres copies. Une sauvegarde laissée sur le même compte d'hébergement n'était pas une copie de sortie. Une archive complète que seul l'hébergeur pouvait restaurer n'était pas encore une procédure de récupération.

Ladocumentation actuelle de sauvegarde cPanelrend la distinction précise. Un utilisateur peut générer et télécharger une sauvegarde complète du compte, y compris vers un stockage FTP distant ou de copie sécurisée. Mais une sauvegarde complète ne peut pas être automatiquement restaurée depuis l'interface cPanel ordinaire; la restauration automatique nécessite WHM et donc généralement le fournisseur d'hébergement. La documentation prévient également que la création d'une sauvegarde peut échouer lorsqu'un compte est proche de son quota car le processus a besoin d'espace de travail, et que les sauvegardes automatiques de compte n'existent que si le fournisseur les active.

Cela crée un piège pratique. Le client qui a le plus urgemment besoin de partir peut être proche du quota, suspendu ou dans la fenêtre d'annulation de sept jours. Le fournisseur peut contrôler l'outil de restauration. Le bon moment pour tester l'exportation est avant le conflit ou la panne.

L'outil de transfert actuel de cPanel peut copier des comptes, des packages et des configurations lorsque l'opérateur dispose de privilèges suffisants. Il peut mettre à jour le DNS et le routage du courrier et effectuer un transfert en direct destiné à réduire les temps d'arrêt.

Pourtant, sa documentation liste des limites: les modèles DNS personnalisés ne sont pas transférés, les paramètres à deux facteurs doivent être reconfigurés, les conflits de noms de bases de données peuvent déclencher un renommage, les arrangements de courrier à distance nécessitent une attention particulière et les fichiers spécifiques à FrontPage ne sont pas restaurés. Même un transfert au sein de la même famille de panneaux de contrôle nécessite donc une étape de réconciliation.

Le récit TulsaMJ fournit un exemple historique de cette réconciliation. Après avoir quitté 100 Megs en 2009, l'auteur a documenté que PHP fonctionnait comme un module Apache chez 100 Megs mais comme CGI chez la destination. La syntaxe du gestionnaire.htaccessa dû changer, et la découverte de la différence a pris du temps et du support. Les fichiers avaient été déplacés; leur contexte d'exécution, non.

Un inventaire de sortie complet de 100 Megs aurait contenu au moins les éléments suivants:

1. Le compte du bureau d'enregistrement, le contact du titulaire, le statut du verrouillage de transfert et l'identifiant d'autorisation pour chaque domaine.
2. Chaque zone DNS et l'emplacement des serveurs de noms faisant autorité, y compris les enregistrements de courrier, de vérification et de service non générés par cPanel.
3. Les fichiers du site web, les fichiers de configuration cachés, les permissions, les liens symboliques et les tâches planifiées.
4. Chaque base de données, utilisateur, privilège et paramètre de caractères, plus une vérification de cohérence au niveau de l'application.
5. Les boîtes aux lettres, messages, alias, redirections, filtres, listes de diffusion, paramètres anti-spam et les appareils ou archives locales qui dépendaient du comportement POP.
6. Les clés privées de certificat, la chaîne de certificat, la méthode de renouvellement et la preuve que la destination pouvait servir HTTPS avant le changement de DNS.
7. Les versions d'applications, extensions, thèmes, clés de licence, historique de l'installateur et exigences d'exécution.
8. Les statistiques de trafic, les journaux d'accès et les journaux d'erreurs nécessaires au dépannage ou aux obligations de conservation.
9. Les relevés de facturation, les tickets de support, les versions des politiques et une preuve d'annulation.
10. Une fenêtre de retour en arrière dans laquelle l'ancien service restait disponible pendant que le nouveau site, le courrier et les tâches étaient testés.

Le transfert de domaine est un chemin de contrôle séparé de la migration d'hébergement. Lapolitique de transfert actuelle de l'ICANNexige qu'un bureau d'enregistrement fournisse le code AuthInfo du domaine et supprime un verrou de transfert dans un délai de cinq jours calendaires lorsque le libre-service n'est pas disponible, sous réserve des conditions de la politique. Elle précise également qu'un bureau d'enregistrement ne peut pas retenir ces étapes uniquement en raison d'un litige de paiement. Cette protection n'est utile que si l'entreprise sait quel bureau d'enregistrement détient le domaine, maintient le contact du titulaire à jour et commence avant l'expiration ou la crise.

Le courrier nécessite une prudence particulière. Un site web peut être comparé visuellement à une adresse temporaire; le courrier électronique est un état distribué. Les messages peuvent arriver sur l'ancien serveur pendant que les caches DNS expirent. Les utilisateurs POP peuvent avoir des historiques locaux uniques. Les redirections et les filtres peuvent ne pas se reproduire exactement. La migration nécessite une période d'observation parallèle, un temps de vie DNS bas défini à l'avance, des messages de test provenant de réseaux externes, et la confirmation que l'ancienne file d'attente est vide.

Les boutiques et forums basés sur des bases de données nécessitent une cohérence applicative. Copier les fichiers à midi et une base de données à une heure peut produire un site dont les téléchargements, les commandes et les enregistrements ne concordent pas. Le client a besoin d'une fenêtre de maintenance ou d'une méthode de réplication, d'un gel final des écritures, de sommes de contrôle ou de comptages d'enregistrements, et d'un test transactionnel à la destination. La confusion du client osCommerce en 2006 rappelle qu'un panier techniquement installé n'est pas un flux de travail commercial validé.

Les conditions d'annulation convertissent ces étapes techniques en délais. L'accord archivé permettait à l'une ou l'autre partie de résilier sur préavis, imposait des frais d'annulation anticipée dans certaines circonstances, et limitait la fenêtre d'archivage après l'annulation. Il plafonnait également la responsabilité déclarée à 500 $ et excluait certaines catégories de pertes de données, de profit et d'utilisation. Ces clauses historiques ne sont pas présentées comme les conditions du successeur actuel. Elles montrent pourquoi un client ne pouvait pas faire du plafond de responsabilité de l'hébergeur son plan de récupération.

Le test de sortie le plus solide est une restauration effectuée par une personne autre que celle qui a construit le site, utilisant une copie stockée en dehors du fournisseur. Si cette personne peut récupérer le site web, la base de données, le flux de courrier, le DNS et le certificat dans les délais requis, la portabilité est réelle. Si l'exercice s'arrête à « nous avons téléchargé un fichier tar », le client a un artefact, pas une continuité.

Les affirmations de sécurité nécessitaient des preuves opérationnelles

La page « À propos » archivée utilisait le vocabulaire sécuritaire de son époque: accès physique contrôlé, surveillance, pare-feu, alimentation redondante, contrôles environnementaux et surveillance continue. L'annonce Data393 soutient indépendamment plusieurs capacités au niveau de l'installation. La page de confidentialité indiquait que des garanties physiques, électroniques et de gestion étaient en place. Ce sont des entrées pertinentes, mais elles ne révèlent pas la latence des correctifs, la révision des accès, la gestion des vulnérabilités, l'isolation des sauvegardes ou la réponse aux incidents.

Les en-têtes de réponse exposés démontrent pourquoi la gouvernance des versions appartient à l'évaluation de la sécurité. Ils donnaient aux étrangers les générations exactes d'Apache, PHP, OpenSSL et FrontPage pour le site marketing. Les chaînes de version seules ne prouvent pas l'exploitabilité; les logiciels peuvent être rétroportés ou configurés de manière défensive. Elles donnent à un acheteur une raison de demander la politique de cycle de vie et les contrôles compensatoires.

La politique d'utilisation acceptable plaçait une responsabilité sécuritaire importante sur les clients. Elle interdisait les relais de courrier ouverts, les accès non autorisés, les logiciels malveillants, les activités perturbatrices et plusieurs formes d'abus. Elle précisait que le fournisseur pouvait supprimer des informations ou fermer un site lorsqu'il avait connaissance d'une activité nuisible. De tels pouvoirs peuvent protéger les voisins sur un serveur mutualisé, mais ils rendent également les procédures de notification, de conservation des preuves et d'appel importantes pour une entreprise légitime prise dans un faux positif.

Aucune source publique fiable utilisée ici n'établit une certification de sécurité spécifique à l'entreprise, une disponibilité mesurée indépendamment, un historique de violation ou un taux d'incidents pour 100 Megs. C'est un vide de preuves, pas une preuve qu'aucun incident n'est survenu. Les archives ne peuvent pas non plus montrer à quelle fréquence les sauvegardes ont été restaurées avec succès ou à quelle vitesse le support a traité les rapports d'abus.

Un acheteur dans cette position devrait demander des preuves opérationnelles plutôt que des adjectifs: versions d'exécution supportées; fenêtres de correctifs et de changements d'urgence; séparation entre les comptes clients; contrôles d'accès privilégié; surveillance des logiciels malveillants et du courrier sortant; chiffrement et immutabilité des sauvegardes; résultats de tests de restauration; obligations de notification; et les entreprises d'installation, de réseau et de support qui peuvent accéder aux données.

Si le fournisseur s'appuie sur une certification de centre de données, l'acheteur devrait demander quel service et quels contrôles elle couvre. Un bâtiment certifié ne certifie pas l'application PHP d'un client.

Pour le commerce électronique, le partage des responsabilités doit être particulièrement clair. L'hébergeur peut fournir HTTPS et un installateur d'applications. Il ne valide pas pour autant le panier d'achat, l'intégration des paiements, les mots de passe administrateur ou les choix de conservation des données. Le client devrait minimiser les données de paiement, utiliser une conception de paiement adaptée à ses obligations de conformité, maintenir les applications supportées et vérifier le parcours complet de paiement et de remboursement après chaque changement significatif.

Sécurité et portabilité se renforcent mutuellement. Un fournisseur peut avoir besoin de supprimer un composant obsolète pour la sécurité. Un client qui peut tester et se déplacer a la marge pour mettre à niveau. Un client piégé sur un environnement d'exécution ancien fait pression sur le fournisseur pour qu'il conserve le risque. Le meilleur investissement dans la continuité est souvent le même que le meilleur investissement dans la sécurité: des dépendances documentées, des logiciels à jour, une configuration reproductible et une récupération testée.

Un test d'approvisionnement construit à partir des archives de 100 Megs

L'acheteur moderne qui choisit entre un hébergement mutualisé, un hébergement d'applications géré, un serveur virtuel, une machine dédiée ou une plateforme cloud plus vaste ne devrait pas demander quelle catégorie est intrinsèquement la meilleure. Chacune déplace le travail et le contrôle. L'hébergement mutualisé standardise les opérations à faible coût mais contraint les ressources et les versions. L'hébergement d'applications géré peut réduire le travail de correction mais réduit les extensions supportées. Un serveur virtuel augmente le contrôle et l'administration.

Le matériel dédié isole la capacité mais ne fournit pas automatiquement la résilience. Une plateforme cloud large offre de nombreux blocs de construction tout en faisant de l'architecture et de la gestion des coûts la responsabilité du client.

100 Megs lui-même vendait plusieurs de ces échelons, ce qui rend ses archives un test d'approvisionnement utile. Un acheteur peut prendre chaque affirmation attrayante du catalogue de 2010 et demander le fait opérationnel en dessous.

Identité et contrepartie.Quelle entreprise légale exacte signe le contrat et facture le client? Quelle marque publique fournit le support? Le contrat peut-il être cédé? La marque 100 Megs est bien prouvée, mais son enveloppe légale pré-acquisition ne l'est pas. Cette distinction devrait être résolue avant que de l'argent ou des données réglementées ne soient déplacés.

Contrôle du domaine.Le client est-il le titulaire, avec des identifiants indépendants et des contacts de récupération? Le domaine peut-il être transféré sans un compte d'hébergement actif? Un site dont le domaine et l'hébergement tombent en panne ensemble a transformé deux dépendances en une seule.

Emplacement et fournisseurs.Où sont traitées les données principales, le courrier, les journaux et les sauvegardes? Qui possède l'installation et le réseau? Quels emplacements sont utilisés pendant la récupération? 100 Megs était canadien et hébergé au Colorado; aucun des deux faits n'annulait l'autre.

Capacité et application.Qu'exclut « illimité »? Quelles limites de CPU, mémoire, processus, nombre de fichiers, base de données et courrier s'appliquent? Comment sont-elles mesurées et présentées? La règle des 4 % importait plus que le titre de transfert du forfait Ultra.

Cycle de vie.Quelles versions de PHP, base de données, système d'exploitation et panneau de contrôle sont proposées, quand prennent-elles leur retraite, et qui paie pour la remédiation? Un client peut-il préparer la version suivante? La présence de PHP, MySQL et FrontPage dans une liste de fonctionnalités n'était que le début de l'obligation.

Limite applicative.« Géré » couvre-t-il le système d'exploitation, le panneau de contrôle, l'application open source, les extensions, le réglage des performances et la récupération, ou seulement certains d'entre eux? Quels changements nécessitent un engagement payant? La page dédiée de 100 Megs annonçait un support et des ajouts gérés sans assez de détails préservés pour évaluer la limite.

Conception du support.Quels sont les objectifs d'accusé de réception et de restauration par gravité? Existe-t-il une voie hors bande? Qui possède le premier et le deuxième niveau? Les historiques de tickets sont-ils exportables? La page revendeur divulguait utilement son arrangement à deux niveaux; un acheteur aurait encore besoin des délais d'escalade.

Sauvegarde et restauration.La copie est-elle hors du compte de production et du domaine de panne? Combien de temps est-elle conservée? Le client peut-il restaurer sans privilège du fournisseur? Les bases de données sont-elles capturées de manière cohérente? L'archive de sept jours post-annulation et la non-garantie rendent ce test non négociable.

Migration.Quels composants sont transférés automatiquement et lesquels nécessitent un travail manuel? L'acheteur peut-il effectuer une répétition en direct? Le DNS, le courrier, les tâches planifiées, les certificats, les paramètres à deux facteurs et les anciennes extensions sont-ils inclus? La propre documentation de cPanel montre pourquoi « cPanel vers cPanel » n'est pas synonyme de complet.

Tarification dans le temps.Quels sont les prix de première durée, de renouvellement et de migration? Quels éléments sont optionnels aujourd'hui mais requis en pratique — SSL personnalisé, sauvegardes, sécurité, adresses dédiées ou support? Comment les comptes acquis sont-ils mappés vers les nouveaux forfaits? La plainte Jumpline de 2012 n'est pas un tarif, mais elle identifie le risque.

Sortie et suppression.Combien de préavis est nécessaire, quand l'accès cesse-t-il, quels frais s'appliquent, et quand les copies principales et de sauvegarde sont-elles supprimées? Le client peut-il récupérer les journaux et les tickets après l'annulation? Les conditions historiques rendaient l'accès limité dans le temps et la responsabilité du fournisseur limitée.

Ce test clarifie également la concurrence. Un rival offrant moins de disque mais une télémétrie de ressources transparente, des environnements d'exécution supportés et une restauration éprouvée peut être moins cher en termes commerciaux. Un rival avec des frais d'introduction bas mais un renouvellement coûteux, un constructeur de site propriétaire et un domaine contrôlé par l'hébergeur peut être plus coûteux. Un serveur virtuel peut réduire une forme de contrainte tout en augmentant le coût de la sécurité et de l'administration.

La comparaison devrait valoriser le temps du personnel, les migrations attendues et l'exposition aux pannes en plus de la facture.

Pour une PME, le coût de changement est souvent asymétrique. L'adhésion prend des minutes car l'hébergeur automatise la configuration. Le départ prend des jours car le client doit redécouvrir des années d'état accumulé. L'approvisionnement devrait inverser cette asymétrie avant de signer: exporter un compte échantillon, inspecter l'archive, le restaurer ailleurs, transférer un domaine de test, reproduire les règles de courrier et enregistrer combien de temps le support met à répondre. Un fournisseur confiant dans la continuité devrait être en mesure d'expliquer l'exercice.

Le même test s'applique après une acquisition. Revalidez le contrat, les contacts de support, les emplacements des données, la feuille de route des environnements d'exécution, l'accès aux sauvegardes, le prix de renouvellement et la procédure d'annulation. Ne supposez pas qu'une page d'accueil fonctionnelle prouve que chaque dépendance a survécu. Le récit de 100 Megs à Jumpline suggère que le transfert technique et la satisfaction commerciale peuvent diverger.

Ce qui reste connaissable — et ce qui doit être surveillé

L'histoire exacte de l'entreprise a des ancres solides et de véritables lacunes. Ancrées: le domaine a été enregistré en 2001; des utilisateurs ont décrit le service en 2002; la marque a publié un contact canadien détaillé et un catalogue hébergé au Colorado en 2009-2010; le service offrait des niveaux mutualisés, revendeur, virtuels et dédiés autour de cPanel; Tech Assets déclare avoir acquis la marque en 2011; un client ultérieur a décrit un transfert vers Jumpline; et Jumpline présente maintenant HostPapa comme sa surface parente.

Non prouvés: l'identité légale complète avant l'acquisition, le nombre de clients revendiqué par l'entreprise, le chiffre d'affaires, l'effectif, le nombre et l'utilisation des serveurs, la propriété des ressources réseau, la disponibilité mesurée, la fréquence des suspensions, les taux de restauration réussie et si un compte client original de 100 Megs reste actif aujourd'hui. Ce ne sont pas des omissions décoratives. Elles définissent la force avec laquelle l'histoire peut être utilisée.

L'enregistrement actuel du domaine doit être surveillé comme un signal de continuité, pas confondu avec une entreprise en activité. Un domaine enregistré peut pointer vers un successeur, un service inactif ou une page d'attente. Les questions significatives sont de savoir si les anciens clients ont toujours une voie authentifiée vers les données du compte, quelles conditions les régissent maintenant, quelles versions d'exécution restent, et si le successeur peut produire une exportation complète.

La chaîne de successeur mérite également une surveillance. La page actuelle de Jumpline promet un accès continu et une communication préalable des changements majeurs. Les acheteurs avec des comptes hérités devraient conserver des copies de ces avis, comparer les conditions des forfaits et de renouvellement, tester les sauvegardes avant les changements de plateforme et vérifier que l'enregistrement du domaine n'est pas silencieusement regroupé avec l'hébergement. Le moment avant une migration planifiée est le moment le moins coûteux pour trouver un composant non supporté.

Pour les historiens de l'hébergement, des documents primaires supplémentaires pourraient combler les lacunes juridiques et opérationnelles: les enregistrements de noms commerciaux et d'entreprises de l'Alberta, les contrats pré-acquisition complets, les enregistrements de routage archivés, les factures clients, les avis d'acquisition et les communications de support. Jusqu'à ce que ces documents apparaissent, ils ne devraient pas être remplacés par des estimations d'agrégateurs ou des hypothèses dérivées du mot « Megs ».

La leçon plus profonde de la marque ne dépend pas de la comblement de ces lacunes. En 2010, 100 mégaoctets ne décrivaient même plus le plus petit forfait annoncé. La promesse a survécu parce qu'elle était devenue un nom. Ce que les clients achetaient réellement, c'était l'alignement continu de nombreuses pièces mobiles: un logiciel qui fonctionnait encore, un domaine qui résolvait encore, un courrier qui arrivait encore, une base de données qui correspondait encore aux fichiers, un support qui pouvait atteindre la bonne couche, et une sauvegarde qui pouvait devenir un service fonctionnel ailleurs.

La capacité croît presque automatiquement. La continuité non. Elle doit être conçue dans la propriété, les contrats, l'architecture et la répétition. La clause d'archivage de sept jours l'a rendue visible en 2010, et l'acquisition l'a rendue à nouveau visible en 2011. Une marque d'hébergement peut porter un vieux numéro pendant des décennies. Ses clients devraient porter quelque chose de plus utile: la capacité testée de partir.