C'est un texte apaisant dans un entonnoir de vente, pas une garantie technique. Lorsqu'un hébergeur imprime « illimité » sur la carte du plan, il ne promet pas un transfert infini à travers la physique et les budgets ; il promet de ne pas mesurer un poste spécifique sur votre facture tout en contrôlant tout le reste qui détermine réellement si votre site reste rapide et accessible. La vérité pratique est simple et un peu irritante : votre plan peut ne pas mesurer le transfert mensuel, mais il vous mesurera absolument d'autres manières dès que votre utilisation semblera inhabituelle, en pics ou coûteuse à servir.
J'ai vu cela se produire suffisamment de fois pour repérer le schéma dès le premier fil de discussion avec le support. Le site démarre fort, les classements grimpent, une campagne frappe, et puis le plan « illimité » développe une personnalité. Les requêtes prennent plus de temps. Les actifs statiques rampent. Les travailleurs prennent du retard. Des erreurs apparaissent par intermittence car l'hôte commence à protéger l'environnement partagé, pas votre succès. Ce n'est pas de la malveillance ; c'est une réalité économique. Les hébergeurs vendent « l'illimité » pour attirer les petits sites dont l'utilisation réelle est minuscule et prévisible. Les cas particuliers — vidéo, téléchargements, API publiques, applications mal mises en cache — deviennent des « abus » dès que les graphiques bougent. Les CGU et les planificateurs de ressources entrent en jeu. Si vous avez acheté « illimité » en espérant une piste de croissance, vous vous sentirez pris de court. Si vous le considérez comme non mesuré sur le papier mais très mesuré en pratique, vous prendrez des décisions d'architecture plus intelligentes et éviterez l'e-mail de suspension qui arrive toujours au moment le moins opportun.
La bande passante, le transfert, le débit et la vitesse du port ne sont pas la même chose
Peu importe combien de fois l'industrie brouille les termes—si nous voulons être honnêtes sur ce que vous pouvez réellement pousser, nous devons séparer le vocabulaire. La bande passante est la taille du tuyau à un moment donné. Le débit est ce que vous réalisez réellement à travers ce tuyau après les frais généraux, la contention et le bridage. Le transfert de données est la quantité totale déplacée sur une certaine période, généralement un mois. La vitesse du port est le plafond rigide sur le flux instantané, généralement exprimé en 10 Mbps, 100 Mbps, 1 Gbps ou plus.
"Non mesuré" est une promesse de facturation concernant le transfert mensuel, et non le taux instantané que vos paquets obtiennent à midi le lundi. "Illimité" est une touche marketing qui implique qu'il n'y a pas de plafond, mais ce que vous avez réellement, c'est un plan qui ne compte pas les gigaoctets pour les dépassements tout en appliquant des limites par tout le reste : parts de CPU, I/O, nombre de processus, concurrence des connexions, et finalement le port que vos paquets doivent traverser. Un port de 1 Gbps peut, en théorie, déplacer une quantité massive en un mois, mais si l'hôte façonne votre port à 100 Mbps après cinq minutes de débit soutenu—ou vous donne simplement une voie "éclatable" qui descend en charge—votre transfert théorique s'évapore en temps d'attente réel et en demandes échouées. Le tuyau que vous pensiez avoir acheté est le tuyau que vous occupez seulement quand vous êtes silencieux.
Quand j'examine un plan, je ne demande pas "La bande passante est-elle illimitée ?" Je pose une question différente et plus laide : "Quel est le pire cas de débit instantané que je suis garanti lorsque mes voisins et moi sommes tous occupés ?" C'est le chiffre qui empêche votre paiement de stagner, vos images de ramper, et vos tâches de fond de construire une piste de réessais que vous paierez plus tard.
Comment l'hébergement mutualisé est conçu pour paraître illimité (jusqu'à ce qu'il ne le soit plus)
L'hébergement mutualisé est un tour de magie basé sur des moyennes. La plupart des sites sont minuscules. La plupart du trafic est éruptif de manière amicale. La plupart des pages sont mises en cache après la première exploration. C'est ainsi que les hébergeurs peuvent sursouscrire le calcul, la mémoire, le stockage I/O et les voies du réseau tout en servant des tableaux de bord joyeux à des milliers de clients. La machinerie derrière cette illusion est un nid de planificateurs de partage équitable et de systèmes de quotas. Les parts de CPU empêchent un seul compte de prendre un cœur entier pendant longtemps. Le façonnage des IOPS empêche les voisins bruyants d'affamer le SAN. Les limites de processus PHP-FPM et Node garantissent que seules quelques requêtes peuvent s'exécuter dynamiquement à la fois. Les plafonds d'inodes limitent silencieusement le nombre de fichiers que vous pouvez conserver sur le disque, étranglant les sites riches en médias avant que le transfert n'apparaisse jamais dans un graphique.
La chose critique à remarquer est qu'aucun de ces systèmes ne touche à la ligne d'élément "bande passante". Cela reste non mesuré, donc l'affirmation reste techniquement honnête. Dès que votre application commence à avoir l'air occupée pendant plus d'un moment, les règles de partage équitable imposent une "utilisation typique" en limitant les parties de votre pile qu'ils contrôlent. Vous verrez des requêtes dynamiques en file d'attente tandis que les ressources statiques se sentent bien. Puis les ressources statiques ralentissent parce que l'origine devient le goulot d'étranglement qu'un CDN ne peut pas entièrement masquer. L'hébergeur ne vous facture toujours pas pour le transfert. Ils vous obligent simplement à en utiliser moins en réduisant la vitesse à laquelle vous pouvez le servir.
Je ne pense pas que les hébergeurs mutualisés soient des méchants pour cela. Le modèle fonctionne pour la grande majorité des sites web, et il a maintenu le web peu coûteux pour les petits éditeurs. Mais l'expression "bande passante illimitée" donne le mauvais modèle mental. Elle vous invite à architecturer comme si vous aviez une voie dédiée, et ce n'est pas le cas. Vous avez la permission de verser de l'eau dans un seau sans payer au litre, mais vous partagez toujours le robinet.
Les petites lignes qui régissent réellement votre utilisation
Si vous voulez la vérité, ne lisez pas le tableau des prix ; lisez la Politique d'Utilisation Acceptable. Vous trouverez des phrases enrobées de sucre comme "sites web typiques" et "utilisation équitable", qui se traduisent par "si vous commencez à ressembler à un nœud de partage de fichiers, un site de streaming, un miroir de médias ou un hub de téléchargement, nous nous réservons le droit de vous limiter, de vous migrer ou de vous suspendre." Vous trouverez des interdictions sur le streaming audio et vidéo à partir de l'origine, la distribution de fichiers à grande échelle, les archives de sauvegarde stockées sur l'espace web, les collections ZIP accessibles au public, et les scripts "gourmands en ressources" qui s'exécutent pendant plus de quelques secondes chacun. Vous trouverez des limites quotidiennes de secondes de CPU, des plafonds de requêtes de base de données et un comptage des connexions qui fait ressembler votre crawler asynchrone préféré à une attaque.
Les limites de processus d'entrée sont particulièrement sournoises. Dans les environnements de type cPanel, un "processus d'entrée" signifie souvent "le nombre de requêtes dynamiques concurrentes autorisées à démarrer." Atteignez ce plafond et le visiteur suivant ne fait pas la queue ; il reçoit des erreurs. Les limites I/O et les chiffres IOPS font de même pour le disque. Les limites d'inodes vous coupent lorsque vous avez "trop de fichiers", ce que les bibliothèques de médias ambitieuses déclenchent avant même de toucher le débit. Aucune de ces choses ne viole la "bande passante illimitée." Elles assurent juste que vous en utilisez très peu lorsque votre site commence à croître.
J'ai perdu le compte des plans qui prétendent être "illimités" tout en réglant discrètement le CPU sur "100% d'un cœur pendant quelques secondes", l'I/O sur "quelques mégaoctets par seconde soutenus", et les processus sur "une poignée à la fois." C'est une ceinture, des bretelles et une corde. Si vous atteignez les trois, vous ne courez pas ; vous vous traînez.
À quoi ressemble "illimité" un lundi chargé
Imaginez un lundi normal après qu'une mention du week-end vous ait apporté une nouvelle attention. Votre HTML est raisonnablement léger, vos images sont correctes, vous vous appuyez sur un CDN pour les actifs statiques, et votre origine gère les éléments dynamiques. Le trafic augmente d'un facteur de cinq. Au début, tout va bien car les caches sont chauds et le CDN absorbe la plupart des requêtes d'images. Puis vos points de terminaison dynamiques prennent du retard. Le plafond de processus de l'hôte maintient uniquement un petit nombre de travailleurs PHP ou Node simultanés actifs. La mise en file d'attente commence, et les temps de réponse s'allongent suffisamment pour rompre les délais entre les services. Le CDN aide toujours, mais les ratés de cache sur le HTML commencent à faire mal. Votre base de données devient plus bavarde, et le planificateur d'I/O soustrait une autre tranche car vous êtes maintenant "intensif en ressources". Vos clients, avec un timing parfait, cliquent sur des images qui n'étaient pas chaudes dans le CDN, tirant des rafales de l'origine qui entrent en collision avec un travail dynamique lent.
Ce qui se passe ensuite dépend de l'hôte. Certains hôtes vous brident progressivement jusqu'à ce que la performance soit si mauvaise que les visiteurs abandonnent et que votre "moyenne" revienne à la normale. D'autres déclenchent des règles automatisées d'abus et déplacent votre compte vers un pool de niveau inférieur ou un VLAN de quarantaine. Quelques-uns lancent encore la classique réponse 509, "Limite de bande passante dépassée," même s'ils ne comptent pas les octets—509 est juste un panneau d'arrêt utile pour gagner du temps pendant qu'ils révisent. Le résultat semble identique : la promesse de "illimité" s'évapore exactement quand vous en avez besoin.
Un site qui sert principalement du HTML mis en cache et des actifs statiques pourrait s'en sortir avec des visiteurs agacés. Un magasin axé sur le panier ou une application axée sur la recherche en prendra un coup. La douleur n'apparaît que rarement comme une métrique nette et unique. C'est une mosaïque de petits ralentissements se combinant en échecs de commande et en abandon croissant.
Avant d'aller plus loin, je veux rendre quelque chose de concret et réutilisable pour que vous puissiez voir le plafond pratique même lorsqu'un plan prétend qu'il n'existe pas.
Je vais plonger dans des chiffres concrets pendant quelques minutes. Ceci est une section Premium axée directement sur les calculs que vous pouvez faire sur un coin de serviette pour traduire la vitesse du port en transfert mensuel puis en pages vues. Si vous avez déjà eu du mal à mapper "1 Gbps illimité" en "Combien de visites puis-je réellement servir ?" c'est ici que cela se précise.
Premium content
Connectez-vous pour continuer
Les tueurs silencieux : limitation du CPU, mise en forme des IOPS et limites de processus
Si vous avez déjà ressenti un ralentissement du site alors que les graphiques semblaient "normaux", vous avez rencontré les tueurs silencieux. La limitation du CPU est la plus visible lorsque vous savez où regarder. Les hôtes partagés allouent une tranche de cœur pour les pics et vous réduisent ensuite sous une charge soutenue. Votre application ne plante pas ; elle traîne. C'est suffisant pour faire chuter les classements de recherche et les taux de conversion sans déclencher d'alarmes qui impliqueraient le support.
La mise en forme des IOPS est plus subtile. Les bases de données vivent et meurent par la latence de stockage. Les applications lourdes en fichiers aussi. Les hôtes utilisent cgroups et QoS de stockage pour empêcher les gros frappeurs d'affamer le réseau. Vous ne voyez pas d'erreur ; vous voyez une attente de disque de vingt millisecondes se transformer en quatre-vingts, ce qui tire les temps de requête dans une nouvelle distribution plus laide. Associez cela à une faible limite de processus d'entrée et vous avez construit un parfait accordéon. Les requêtes prennent plus de temps, donc plus de requêtes sont simultanées, ce qui atteint la limite plus tôt, ce qui laisse tomber de nouveaux visiteurs.
Les limites de processus, enfin, sont la guillotine. De nombreux plans limitent PHP-FPM ou similaire à une poignée d'enfants. Certains ajoutent une limite sur le nombre total de processus simultanés par utilisateur. Les deux permettent à un hôte de sourire et de promettre "bande passante illimitée" tout en s'assurant que vous ne pouvez pas, en pratique, envoyer beaucoup. Si vous avez déjà poursuivi un goulot d'étranglement fantôme au CDN ou dans votre code d'application pour découvrir que l'hôte permet huit travailleurs et s'arrête là, vous avez ressenti le piège.
Je ne mets pas "bande passante illimitée" dans mon registre de risques comme un problème à résoudre. Je réduis ma dépendance à celle-ci. Le modèle qui fonctionne pour la plupart des petits et moyens sites est ennuyeux et efficace. Cachez le HTML en périphérie aussi longtemps que votre contenu le permet. Poussez les images, CSS et JS vers un CDN que vous validez réellement en production avec un taux de réussite élevé, pas seulement un logo. Déchargez les médias lourds vers un stockage d'objets et pointez votre CDN là-bas pour que l'origine ne le voie jamais. Gardez l'origine concentrée sur les lectures et écritures dynamiques qui nécessitent réellement des calculs, et rendez-les aussi sans état et rapides que possible.
Quand vous faites cela, le plan "bande passante illimitée" devient acceptable car vous ne lui demandez pas de supporter la charge qu'il ne peut pas supporter sans drame. Même si l'hôte façonne votre origine, le CDN absorbe la nature aléatoire du trafic. Votre p95 se stabilise, et vous gagnez du temps pour choisir un déménagement lorsque la croissance est réelle au lieu de réagir pendant une panne. Toutes les petites lignes existent toujours, mais vous ne marchez pas dessus. Vous avez construit une petite origine agile au lieu d'un entrepôt.
Je ne mets jamais le streaming vidéo, les téléchargements de fichiers, les miroirs de logiciels publics ou la distribution de sauvegardes sur un plan qui dit "illimité". Je dis cela en tant que personne qui a essayé de les faire passer et a ensuite négocié avec le langage des ToS après coup. Ces charges de travail ne sont pas ce pour quoi l'hébergement partagé est conçu, et l'hôte vous fermera au nom de la protection de tout le monde. Même si vous vous en sortez brièvement, vous êtes à une mention près de pages d'emails en colère et d'une migration à minuit.
Les archives ZIP lourdes d'actifs de produit ou de matériel d'apprentissage déclencheront les mêmes alarmes. Les API publiques qui encouragent le polling client le feront aussi. Et tout ce qui encourage les utilisateurs à récupérer le même fichier multi-megabyte à plusieurs reprises sur de nouvelles connexions atteindra la mise en forme du port plus rapidement que vous ne le pensez. Le fil qui relie ces cas est simple : ce sont des charges de travail à haute sortie, à faible calcul qui attaquent la facture de transit de l'hôte sans consommer le CPU ou l'I/O que leurs planificateurs sont réglés pour mesurer. Ce décalage est exactement pourquoi "bande passante illimitée" existe en tant que formulation. C'est une promesse douce conçue pour être révoquée dès que votre utilisation cesse de ressembler à un petit blog.
Je veux vous donner un guide de traduction avocat-avec-benchmarks que vous pouvez garder. La section suivante est une section Premium où je traduis les clauses les plus courantes utilisées par les hôtes en réalité opérationnelle. Si vous ne lisez rien d'autre, lisez ceci lorsque vous parcourez un plan à 1 h du matin et vous vous demandez si "illimité" portera votre prochain lancement.
Premium content
Connectez-vous pour continuer
Surveiller ce qui compte pour savoir avant l'arrivée de l'email de suspension
Le tableau de bord que votre hôte vous donne ne vous avertira pas de l'échec qui s'annonce. Il rapportera des moyennes et des totaux tandis que la douleur se cache dans la longue traîne. Je surveille différents signaux. Le trafic sortant de l'origine par rapport au trafic sortant du CDN me dit si mon cache fait son travail. Si le trafic sortant de l'origine augmente plus rapidement que les visites, je sais que quelque chose est contourné ou purgé trop agressivement. La concurrence des connexions est le canari pour les plafonds de processus; si les connexions concurrentes approchent d'un plafond plat, je m'attends à des erreurs immédiates pour les nouveaux visiteurs. La bande passante et le temps de requête au 95e centile comptent plus que les moyennes car ils prédisent les moments de la journée où l'hôte vous façonnera et vos utilisateurs échoueront à compléter un parcours.
Le temps de vol du CPU est un test olfactif pour les environnements partagés. Si je vois le vol grimper pendant mes heures creuses, je sais que je suis en concurrence avec des voisins et que mon sursaut atterrira sur un nœud fatigué. Les requêtes lentes valent toujours le temps que vous pensez ne pas avoir; réparer un mauvais index peut faire la différence entre survivre à une mention et passer une journée à s'excuser. Les budgets d'erreurs—le nombre d'erreurs que vous autorisez dans une fenêtre avant de considérer l'expérience utilisateur dégradée—lient tout cela ensemble. Si vos erreurs augmentent avant le trafic, vous avez une friction invisible, et "illimité" ne coussinera rien.
Suivez l'argent et l'histoire cesse d'être mystérieuse. Le transit est coûteux si vous ne pouvez pas négocier un excellent peering et si vos utilisateurs sont éloignés de vos POP. L'hébergement partagé amortit ce coût sur des milliers de comptes dont la plupart n'utilisent presque rien. "Illimité" est un outil d'acquisition de clients. Il réduit la friction et se compare bien sur un tableau où le plan moins cher "inclut" plus. L'hôte suppose que vous serez petit, ou que vous ferez la chose sensée et déplacerez votre trafic lourd vers un CDN et un stockage d'objets dès que vous grandissez, ce qui déplace le trafic sortant vers un fournisseur qui ne fait que du trafic sortant.
Les nuages inversent le modèle. Ils mesurent le trafic sortant car c'est leur centre de profit et parce que leurs réseaux sont coûteux à gérer à l'échelle mondiale. Ils ne promettent pas "illimité" car l'incitation est différente; ils veulent que vous architecturiez de manière réfléchie et que vous payiez pour ce que vous utilisez. Les hôtes partagés veulent que vous apportiez votre petit site et que vous restiez heureux jusqu'à ce que vous ne soyez plus petit, moment auquel ils veulent que vous optimisiez ou que vous mettiez à niveau. Rien de tout cela n'est cynique; c'est ainsi que les factures sont payées. Mais cela explique pourquoi les CGU sont rédigées dans un langage doux et pourquoi les limites techniques sont appliquées avec une touche légère jusqu'à ce qu'elles ne le soient plus.
Points de décision : quand "illimité" est acceptable, quand c’est imprudent, et comment migrer
Je ne rejette pas "illimité" d’emblée. Pour un petit site marketing avec principalement des pages statiques et un blog modeste, cela fonctionne parfaitement si vous placez un CDN devant. Pour une boutique avec peu de trafic et un cache raisonnable, cela peut fonctionner le temps de trouver un ajustement produit-marché. Pour une publication qui connaît des pics imprévisibles, c’est risqué à moins de mettre en cache de manière agressive et de pré-rendre. Pour tout ce qui émet de gros fichiers, c’est le mauvais outil le jour de votre lancement.
Mon arbre de décision est brutal. Si votre temps de réponse dynamique p95 est bas et reste bas sous une légère pression, vous pouvez utiliser un plan partagé plus longtemps que vous ne le pensez. Si votre taux de succès CDN est vraiment élevé et que votre sortie d'origine reste stable lorsque le trafic double, vous êtes suffisamment en sécurité. Si l'une de ces conditions échoue, planifiez le déménagement maintenant. Un petit VPS avec deux vCPU et suffisamment de mémoire pour éviter le swapping est ennuyeux et fiable. Il vous offre une concurrence prévisible, de meilleures performances de stockage et une voie réseau que vous pouvez réellement comprendre. Vous pouvez toujours utiliser la même stratégie de CDN et de stockage d'objets. Lorsque vous dépassez cela, vous le ressentirez d'une manière que vous pourrez mesurer et planifier, et vous passerez à des clusters dédiés ou gérés parce que vous choisissez de le faire, et non parce qu'une clause des CGU vous y a contraint.
Le chemin de migration n’a pas besoin d’être dramatique. Gardez votre origine sans état autant que possible pour que les basculements DNS soient propres. Stockez les sessions dans un backend partagé que vous pouvez pointer à partir des anciennes et nouvelles origines pendant un bref chevauchement. Réchauffez les caches avant de basculer l'interrupteur pour que la nouvelle origine ne subisse pas tout le choc. Le but n’est pas d’être parfait ; c’est d’être prévisible. "Illimité" vous échoue de manière imprévisible. Votre objectif est de cesser d'être surpris.
J'ai promis des scénarios pratiques et vécus parce que c'est ainsi que les limites de ce sujet deviennent évidentes. La section suivante est une section Premium avec trois histoires réelles, chacune commençant par "illimité", chacune rencontrant un mur différent, et les changements exacts qui les ont stabilisées.
Premium content
Connectez-vous pour continuer
Ma position, franchement : c’est non mesuré, pas illimité — traitez-le de cette manière
Je ne suis pas contre "bande passante illimitée" tant que nous sommes d'accord que cela signifie "nous ne comptons pas les octets" et rien de plus. C’est non mesuré, pas infini. Les contrôles qui façonnent votre expérience résident dans les parts de CPU, les limites d’I/O, les plafonds de processus, les plafonds de concurrence, et la mise en forme des ports éphémères lorsque vous êtes occupé. Si vous architectez comme un adulte — CDN en façade, ressources déchargées, travail dynamique minimisé et rapide — vous pouvez vivre heureuse sur un plan qui commercialise "illimité" parce que vous n’avez rarement besoin de le tester. Si vous architectez comme si vous aviez acheté une voie dédiée, vous apprendrez le sens de "l'utilisation équitable" la première fois que quelqu'un se soucie de votre site.
Voici comment je fonctionne. Je traite l’origine comme une petite API qui mérite du respect. Je déplace les octets lourds vers des endroits conçus pour l’égress, et je paie pour cet égress parce que c’est le coût de l’échelle. Je surveille le p95, pas les moyennes. Je garde un œil sur la concurrence et un autre sur la longue traîne des temps de requête. Je lis les ToS comme si c’était un document technique et je traduis chaque euphémisme en un chiffre. J’accepte que l’hébergement partagé soit un environnement sursouscrit avec une proposition de valeur brillante pour les petits sites et un ensemble de limites strictes pour tout ce qui est ambitieux. Quand l’ambition arrive, je déménage parce que je choisis de le faire, pas parce qu'une clause de velours me dit que je dois.
Si vous avez été brûlé par "illimité", ne vous en voulez pas. Le phrasé est censé être rassurant, et ça marche. Construisez la petite origine résiliente. Mettez un CDN en façade. Déchargez les éléments lourds. Connaissez vos chiffres et vos points d’étranglement. Quand le jour viendra où vous aurez besoin d’un VPS ou de quelque chose de plus grand, faites le changement avec un cache chaud et une tête froide. Vous ne regarderez plus jamais "bande passante illimitée" de la même façon, et c’est le but. Ce n’était pas une promesse. C'était une invitation à faire le bon travail.
