Hébergement mutualisé ou VPS : ce dont votre site a vraiment besoin

L’hébergement mutualisé, le VPS et le serveur cloud ressemblent au tarif à trois paliers de puissance, mais ils diffèrent en trois points : ce qui vous sépare des voisins sur la même machine, où le compte bute, et qui met à jour les logiciels.

Un mercredi matin vers dix heures, le site web ralentit — pas mort, seulement lent : la page s’ouvre en cinq secondes, l’interface d’administration refuse d’enregistrer un contenu, et au bout d’une demi-heure tout redevient normal, comme s’il ne s’était rien passé. Le support de l’hébergeur répond après le déjeuner que le compte a dépassé les limites de son offre, et propose de passer au palier suivant, qui coûte trois fois plus cher et s’appelle « serveur cloud » au tarif.

L’hébergement mutualisé ou VPS, et le serveur cloud, sont empilés au tarif comme trois paliers de puissance d’un même service, alors que ce sont trois solutions techniques distinctes, qui diffèrent en trois points concrets. À ce moment, la plupart des acheteurs ne savent pas ce qu’ils achètent exactement, et ce n’est pas un reproche : vous pouvez vérifier chacun de ces trois points avec les chiffres de votre propre site en main, et aucun ne se lit dans le nom de l’offre.

Hébergement mutualisé ou VPS : trois différences réelles

La première est l’isolation, c’est-à-dire ce qui sépare précisément votre site des sites des autres clients sur la même machine physique. En hébergement mutualisé, c’est un compte dans le système d’exploitation, assorti d’un conteneur de ressources posé au niveau du noyau ; dans le cas d’un VPS, c’est une machine virtuelle distincte avec son propre système d’exploitation ; sur un serveur cloud, c’est la même machine virtuelle, seulement commandée et facturée autrement. La différence pratique entre ces trois variantes tient à quel point la charge d’un voisin peut affecter votre site, et à quelle part de la machine vous avez le droit de modifier lorsque la configuration par défaut ne vous convient pas.

Le deuxième point est la limite, c’est-à-dire où le compte bute et comment cela se manifeste, et c’est là que naissent le plus de malentendus, parce que l’on s’attend à ce qu’une surcharge veuille dire une page lente, alors que dans une partie des cas elle veut dire une page qui ne s’ouvre pas du tout et renvoie un code d’erreur que l’acheteur n’a jamais vu de sa vie. Le troisième point est la responsabilité, c’est-à-dire qui met à jour le système d’exploitation, qui le serveur web, qui PHP et qui le site lui-même, et c’est là que les acheteurs de VPS se trompent le plus souvent, parce que l’accès root n’est pas un cadeau que l’hébergeur joint à une machine plus puissante — c’est le transfert de la liste des devoirs, de lui vers vous, et cela se fait en silence, à la minute même où le mot de passe est envoyé.

Tout le reste, qui occupe des lignes dans un tableau comparatif d’hébergement, est soit identique d’une offre à l’autre, soit n’est pas ce qui casse : les disques NVMe sont aujourd’hui presque partout, mais un « trafic illimité » est une affirmation sur le volume de données transféré, pas sur les ressources, et elle se tient en général juste à côté du tableau où les ressources sont comptées jusqu’au dernier mégaoctet. Quant aux 99,9 %, c’est un chiffre avec une signification juridique précise et une liste d’exceptions en dessous, et la plupart des acheteurs croient qu’il couvre tout autre chose que ce qu’il couvre réellement.

Hébergement mutualisé : un serveur, beaucoup de comptes

L’hébergement mutualisé est un compte utilisateur sur une machine où vivent encore des centaines de comptes identiques, et les hébergeurs français nomment ce même produit de plusieurs façons : OVH l’écrit hébergement mutualisé, IONOS hébergement web — et, dans son assistance, hébergement partagé. Techniquement, dans les trois cas, cela désigne le même accord — le compte vous appartient, pas la machine ; vous gérez le site via cPanel ou un panneau analogue, et tout ce qui se trouve sous ce panneau appartient à quelqu’un d’autre.

Ce qui vous sépare des voisins, c’est un logiciel précis, pas une promesse au tarif, et il vaut la peine de le connaître par son nom. La plupart des hébergeurs cPanel tournent sur CloudLinux, où chaque compte a sa propre copie du système de fichiers : la documentation CloudLinux sur CageFS écrit que les utilisateurs ne peuvent ni voir ni détecter les autres utilisateurs et leurs noms d’utilisateur sur le serveur, ne peuvent pas lire la configuration du serveur web et ne voient qu’une liste de processus tronquée. La deuxième couche est LVE — un conteneur de ressources au niveau du noyau, qui fixe à chaque compte des plafonds de processeur, de mémoire, d’entrée-sortie et de processus, précisément pour que, comme le formule la documentation elle-même, aucun site isolé ne puisse faire tomber tout le serveur web.

La troisième couche est le paramètre PHP open_basedir, et il vaut la peine de savoir ce qu’en dit le manuel PHP lui-même, pas le marketing de l’hébergeur : c’est un filet de sécurité supplémentaire, qui n’est en aucun cas exhaustif et sur lequel on ne peut pas s’appuyer lorsque la sécurité est vraiment nécessaire. Au même endroit, le manuel prévient que la désactivation de fonctions avec disable_functions peut elle aussi être contournée, et que dans un environnement partagé ce n’est pas une mesure de sécurité suffisante. Rien de tout cela n’est un argument contre l’hébergement mutualisé ; c’est un argument pour dire que l’isolation, ici, vient du noyau et du système de fichiers, pas d’une ligne dans un fichier de configuration, et qu’un hébergeur qui répond par le mot « sûr » à une question sur l’isolation n’y a pas répondu.

Ce que l’on ne peut pas choisir en hébergement mutualisé compte autant que ce que l’on peut : le noyau est unique pour tous les comptes, donc vous ne changerez pas sa version ; la liste des versions PHP est fixée par l’hébergeur et elle retarde d’ordinaire d’une ou deux versions sur la plus récente ; le serveur web est celui qui est installé, donc à la question d’un paquet qui n’y figure pas, la réponse sera « non », pas « installez-le ». Un serveur partagé est aussi l’endroit où, en cas d’incident, l’hébergeur doit inspecter les comptes voisins, parce qu’un attaquant qui a pénétré un compte tente la même chose chez les voisins ; que faire lorsque cela s’est produit, nous l’avons décrit dans l’article sur un site WordPress piraté. Aucune de ces limites n’est un défaut : c’est précisément l’accord qui rend ce produit bon marché, et l’acheteur qui le comprend en tire profit.

Que se passe-t-il lorsque le compte bute contre sa limite

Une offre mutualisée a plusieurs limites distinctes, elles sont atteintes indépendamment les unes des autres et se manifestent de façons tout à fait distinctes, donc le symptôme est un outil de diagnostic utile. Les limites CloudLinux par défaut pour un compte sont 100 % d’un cœur processeur, 1 Go de mémoire physique, 1 024 Ko/s d’entrée-sortie, cent processus et vingt entry processes, et c’est précisément ce dernier chiffre qui surprend les acheteurs, parce que vingt a l’air d’un nombre ridiculement petit pour un site qui reçoit dix mille visiteurs par mois.

L’explication, c’est qu’un entry process n’est pas un visiteur : c’est un processus qui entre dans le compte depuis l’extérieur — une nouvelle requête HTTP vers un script PHP, une session SSH ou une tâche cron — tandis que les processus qui naissent déjà à l’intérieur comptent dans une tout autre limite. Lorsque le nombre d’entry processes est atteint, le module Apache n’admet plus la requête suivante et renvoie l’erreur 508 Resource Limit Reached, et CloudLinux le décrit dans sa base de connaissances sans adoucissement : le site qui consomme trop de ressources cesse de fonctionner, mais les autres clients sur le même serveur continuent de tourner normalement. C’est exactement le sens de ce mécanisme — couper un compte pour que la machine ne s’arrête pas.

Les autres limites se manifestent autrement, et le symptôme permet de lire laquelle a été atteinte, avant que quiconque se mette à deviner : le processeur et l’entrée-sortie ne sont pas coupés, mais ralentis, donc la page devient lente et finit par s’ouvrir, tandis que les limites de mémoire et de processus donnent d’ordinaire un 500 ou un 503, c’est-à-dire une page qui ne s’ouvre pas du tout. Sur les serveurs LiteSpeed, les entry processes se comptent autrement que sur Apache, donc on n’a pas le droit d’y traduire ce même chiffre en nombre de visiteurs simultanés, et c’est l’un des moyens les plus fréquents par lesquels un chiffre correct atterrit dans une phrase fausse.

Il existe encore une quatrième limite, qui n’a rien à voir avec la charge et qui arrive donc à l’improviste : un inode est un enregistrement du système de fichiers pour un fichier ou un dossier, donc le nombre d’inodes du compte est simplement le nombre de fichiers et de dossiers, boîte mail jamais nettoyée depuis des années comprise. Un barème d’hébergement mutualisé publie ces plafonds noir sur blanc — 400 000 inodes en entrée de gamme, 600 000 au palier suivant, 800 000 au palier supérieur — et, dans la même table, 100 % d’un cœur et 2 048 Mo de mémoire pour les deux premiers, 200 % et 3 072 Mo pour le troisième, plus 10 Mo/s d’entrée-sortie et 150 connexions simultanées pour les trois, tandis que le trafic mensuel y est dit « illimité ». Ce montage est la vraie leçon sur le mot « illimité » au tarif d’un hébergeur : il porte sur le volume de données transféré, et toutes les autres limites sont là, à côté, comptées jusqu’au dernier chiffre.

VPS : votre système d’exploitation sur du matériel partagé

Un VPS (serveur privé virtuel) est une machine virtuelle dont vous possédez le système d’exploitation, l’accès root et la possibilité d’installer ce qu’il faut, et sur le marché français on l’écrit avec le sigle anglais autant qu’on le développe : OVH, par exemple, parle de serveur privé virtuel (VPS). Ce que ce nom ne dit pas, ce sont deux questions techniques qui tranchent quelle part du « serveur à soi » est réellement la vôtre.

La première question est de savoir si la virtualisation est au niveau matériel ou au niveau du système d’exploitation. KVM est un module du noyau Linux qui utilise les extensions de virtualisation du processeur et donne à chaque invité son propre matériel virtualisé — carte réseau, disque, adaptateur vidéo — et surtout son propre noyau, si bien que l’on peut y faire tourner aussi un Windows non modifié. LXC et les conteneurs apparentés sont un autre mécanisme : ils s’appuient sur les espaces de noms Linux, les cgroups et la restriction des privilèges pour créer un environnement aussi proche que possible d’une installation Linux séparée, mais sans noyau distinct. Les conséquences sont simples et pratiques — dans un conteneur, la version du noyau, ses modules et ses vulnérabilités restent partagés avec la machine hôte, donc une partie de ce que vous croyiez acheter est en réalité restée aux voisins.

La deuxième question porte sur le processeur, parce que les mots « son propre serveur » ne veulent pas dire son propre processeur. Les serveurs cloud Hetzner ont deux gammes distinctes : dans les offres à ressources partagées, les ressources de calcul sont réparties entre toutes les instances du même serveur physique, avec une performance de base et la possibilité de la dépasser un temps ; dans les offres à ressources dédiées, un vCPU est un thread d’un cœur physique, et il n’est qu’à vous. DigitalOcean le formule plus clairement encore : dans une offre partagée, le thread peut être partagé avec d’autres, et si les voisins ont une charge élevée, l’instance reçoit des fractions de thread, pas un accès plein, si bien qu’en pratique l’accès plein est possible, mais n’est pas garanti.

Combien de voisins il y a sur une machine, aucun des grands prestataires ne le publie, et le ratio que vous trouverez dans les blogs n’est la mesure publiée de personne, donc cela ne mérite ni d’être cité ni d’être cru. La seule grandeur documentée à laquelle on puisse se référer, c’est si l’offre promet des ressources partagées ou séparées, et cette différence est d’ordinaire écrite tout à fait ouvertement — avec deux noms de produits distincts, deux spécifications distinctes et un écart de prix qui se compte en multiples.

Le serveur cloud est le même VPS, acheté autrement

Un serveur cloud est techniquement une machine virtuelle sur un hyperviseur, c’est-à-dire exactement la même chose qu’un VPS, et la documentation Hetzner s’ouvre sur cette phrase : les serveurs cloud sont des machines virtuelles qui tournent sur des serveurs physiques. Si vous attendez de deux offres deux matériels différents, cette attente n’a pas de fondement.

La différence n’est pas dans le matériel, mais dans la façon d’acheter, et la définition la plus précise en est celle de l’institut américain des normes NIST, que le secteur cite encore : le cloud a cinq traits — le libre-service à la demande, l’accès par le réseau, la mise en commun des ressources entre plusieurs locataires, l’élasticité rapide et la consommation mesurée. En pratique, cela veut dire une API avec laquelle on crée et on détruit la machine par programme, une tarification à l’heure avec un plafond mensuel, et des pièces que l’on peut brancher à part : des snapshots (instantanés), un stockage par blocs séparé, une adresse IP flottante et un répartiteur de charge.

Chacune de ces pièces a des bornes qu’il vaut la peine de connaître avant l’achat, pas un mois après. Un changement d’offre Hetzner ne peut pas réduire la taille du disque, même si l’on n’en utilise qu’une partie ; après un agrandissement du disque, il vous faut agrandir la partition vous-même en mode rescue, et le changement d’offre lui-même figure parmi les exceptions à la garantie de disponibilité. Un snapshot n’est pas une sauvegarde, même si le marché emploie les deux mots comme des synonymes : les snapshots Hetzner n’incluent pas les volumes attachés, et la cohérence n’est pas garantie si le serveur tourne, donc c’est une bonne chose avant une mise à jour et une mauvaise chose comme seule copie des données. L’adresse IPv4 flottante se paie à part, tout comme l’adresse IPv4 principale de l’instance.

Le site d’une entreprise de cinq pages n’utilise d’ordinaire aucune de ces pièces, et c’est la phrase la plus honnête de cette section : si le site ne change jamais de puissance, ne bascule jamais sur une autre machine et n’est jamais branché à une API, alors le serveur cloud et un VPS de même taille sont la même machine avec deux factures différentes. Ce n’est pas un argument contre le cloud, parce que là où l’on se sert de l’élasticité, elle coûte moins cher qu’une réserve tenue en permanence. C’est un argument pour dire que le choix est entre des possibilités dont vous vous servirez vraiment, pas entre des mots qui sonnent moderne.

Qui met à jour quoi

La plus grande différence pratique entre les trois offres n’est pas la vitesse, mais le partage des devoirs, et ce sont les prestataires de cloud eux-mêmes qui l’ont formulé le plus clairement. Le modèle de responsabilité partagée d’AWS coupe le tout en deux : la sécurité du cloud est la responsabilité d’AWS — le matériel, les logiciels, le réseau et les locaux où les services tournent — mais la sécurité dans le cloud est la responsabilité du client. Sur la question des correctifs, c’est même écrit à part et mot pour mot : AWS répond des correctifs et des défauts de l’infrastructure, mais le client répond des correctifs du système d’exploitation de son invité et de ses applications.

En hébergement mutualisé, cette couche appartient à l’hébergeur, et c’est la plus grande valeur de ce produit, à laquelle peu de gens pensent : le noyau, le serveur web et PHP, c’est eux qui les mettent à jour, et vous n’en savez rien tant que quelque chose ne casse pas. Sur un VPS ou un serveur cloud non infogéré, tout cela est passé de votre côté avec le mot de passe root, et Hetzner le dit aussi de l’autre côté dans ses conditions : les logiciels, la configuration et les paramètres système que le client met en place ne sont pas considérés comme une interruption de disponibilité, donc le prestataire n’en répond pas et ils n’entrent dans aucune compensation.

Le site lui-même reste de votre responsabilité dans les trois cas, et c’est le point où il faut lire les offres attentivement, parce que le mot « infogéré » dans le secteur désigne d’ordinaire le système d’exploitation et les logiciels serveur, pas le cœur de WordPress, les extensions et le thème. Dans la maintenance de notre propre hébergement infogéré figurent aussi les mises à jour du système d’exploitation et des logiciels serveur, la configuration de sécurité, les sauvegardes dont la restauration est testée, la supervision et la réaction selon le SLA — et il n’y est pas écrit que nous mettons à jour vos extensions, parce que c’est une autre ligne au tarif et un autre contrat, et nous le disons clairement pour que personne ne découvre cette frontière le jour de l’incident.

Le test pratique avant commande est une seule question, posée directement et en trois parties : qui met à jour le système d’exploitation, qui le serveur web et PHP, et qui le code du site. Si la réponse à l’une des trois est « vous-même », alors c’est un travail qui demande soit une personne avec du temps, soit un contrat avec quelqu’un d’autre, et ni l’un ni l’autre n’est gratuit. Sans réponse, cette question ne disparaît pas — elle revient dix-huit mois plus tard sous la forme d’un système où personne n’a posé le moindre correctif, et ce n’est plus alors une question de choix d’offre.

Ce que veulent dire 99,9 % et ce qu’ils ne couvrent pas

Le pourcentage de disponibilité au tarif a l’air d’une promesse, mais c’est en réalité une formule avec une liste d’exceptions. L’accord de niveau de service des serveurs cloud Hetzner promet 99,9 % par mois pour une instance, et Hetzner lui-même calcule dans son explication ce que ce chiffre veut dire en pratique : sur un mois de trente jours, 43 minutes d’arrêt restent dans les bornes de l’accord, c’est-à-dire que ce n’est pas une violation et qu’aucune compensation n’est prévue.

La compensation elle-même est tout aussi concrète et bien plus petite que ce que l’on attend : elle se calcule à partir des minutes au-dessus du seuil, converties en heures et multipliées par le tarif horaire de l’instance, et elle est versée comme un crédit sur la consommation à venir, pas comme de l’argent. Dans l’exemple de Hetzner, 185 minutes d’arrêt donnent 142 minutes au-dessus du seuil, soit 2,37 heures et un crédit de 0,87 €, ce qui est moins que ce que coûte une heure de travail pour le calculer. Le chiffre d’affaires non recouvré, les commandes perdues et le recul du positionnement dans les moteurs de recherche n’y figurent nulle part, et aucun accord d’hébergement que nous ayons lu ne les couvre.

La liste des exceptions compte autant que le chiffre, parce que c’est elle qui décide à quelle fréquence ce chiffre s’applique vraiment : restent hors accord la maintenance annoncée à l’avance, les logiciels et la configuration du client lui-même, le changement d’offre demandé par le client, les migrations à chaud pour la stabilité de l’hôte, et le réseau au-delà du réseau de base du prestataire. Tout cela est écrit honnêtement et ouvertement, et il s’ensuit une conclusion simple : le pourcentage porte sur la machine, pas sur votre site, donc un site tombé après une mise à jour ratée est entièrement hors de ce contrat.

De plus, 99,9 % n’est pas une constante du secteur, même si on l’emploie souvent comme si elle l’était. L’accord Amazon EC2 promet 99,5 % pour une instance, et 99,99 % seulement si les instances sont déployées dans au moins deux zones de disponibilité, c’est-à-dire deux contrats distincts avec deux chiffres distincts, et la phrase « dans le secteur, c’est 99,9 % » les aplatit en un seul. En hébergement mutualisé, un tel document n’existe d’ordinaire pas du tout — il y a seulement un chiffre sur la page, sans définition, sans méthode de mesure et sans conséquence, et c’est une affirmation, pas un engagement.

Comment mesurer votre site avant de choisir

Le chiffre qui tranche n’est pas le nombre de visiteurs par mois, même si c’est précisément celui que l’acheteur sait par cœur et que le vendeur demande en premier. Ce qui tranche, c’est le nombre de requêtes PHP simultanées au moment où la charge est la plus forte, et c’est une tout autre grandeur, qui corrèle faiblement avec la fréquentation mensuelle.

Deux sites à fréquentation égale peuvent se trouver de part et d’autre de la même limite, et l’écart tient à combien de temps chaque page retient un processus. Un site d’entreprise statique, servi depuis le cache, est pour l’essentiel servi par le serveur web sans PHP, donc il ne consomme presque pas d’entry processes et dix mille visiteurs par mois ne lui font rien. Un site e-commerce où chaque panier, chaque connexion et chaque retour de passerelle de paiement retient un processus PHP deux secondes peut atteindre la même limite dès vingt acheteurs simultanés, et c’est précisément pour cela qu’à la première heure d’une campagne tombent précisément les boutiques qui ont payé la campagne.

Avec ce chiffre, il vaut la peine d’en lire encore trois, et les trois sont accessibles sans l’aide d’un développeur. Le premier est la taille de la base de données et la requête la plus lente qui s’y trouve, parce que c’est d’ordinaire la vraie cause de la lenteur, pas la puissance de la machine. Le deuxième est le nombre de fichiers du compte, parce que les sites avec une grande médiathèque et une vieille boîte mail atteignent la limite d’inodes à l’improviste et sans avertissement. Le troisième est ce que le site fait hors du navigateur — tâches cron, envoi de courrier, intégrations avec le système de comptabilité — parce que ces processus aussi entrent dans le compte depuis l’extérieur et comptent dans la même limite que vous venez de mesurer pour les acheteurs.

Ces quatre chiffres se lisent en un après-midi dans les statistiques du panneau d’hébergement et les journaux du serveur, et c’est le seul endroit où se trouve la charge réelle de votre site, pas une intuition. Le nom de l’offre ne les connaît pas, le vendeur qui ne les a pas vus non plus, et une conversation qui commence par eux se termine d’ordinaire par une réponse moins chère qu’une conversation qui commence par une liste d’offres.

Quand le passage aide et quand il ne résout rien

Passer à une offre plus grande est la bonne réponse bien plus rarement qu’on ne la propose, et le premier cas où cela n’aide pas est aussi le plus fréquent. Si le site est lent parce qu’une requête lit toute la table des produits à chaque ouverture de page, une machine plus puissante l’exécutera plus vite, le problème restera, et vous aurez acheté du temps, pas une solution. Il en va de même des quarante extensions, des images brutes servies à leur taille réelle et d’un thème qui reconstruit le menu depuis zéro à chaque requête.

Le passage est la bonne réponse lorsque la limite est atteinte avec un code correct : si le site est mis en cache, les requêtes sont en ordre et le compte bute encore contre le nombre d’entry processes, alors c’est une limite d’offre, pas un défaut dans le code, et il n’y a plus rien à optimiser. De même, le passage est la seule réponse lorsqu’il faut quelque chose que l’on ne peut pas installer sur un compte mutualisé — une autre version de PHP, un worker de file d’attente, Redis, un cron à la minute — ou lorsqu’une exigence sectorielle, un marché public ou une demande du client fixe le pays où les données se trouvent physiquement.

Il existe aussi un troisième cas, dont les vendeurs parlent rarement, parce qu’il réduit la facture : parfois le bon mouvement est vers le bas. Un site qu’on a déplacé sur un VPS il y a trois ans pour une campagne publicitaire et qui reçoit depuis deux cents visiteurs par jour paie une machine dont il ne se sert pas, et il la paie deux fois — en argent sur la facture et en temps humain, parce que le système d’exploitation du VPS doit être mis à jour par quelqu’un même lorsque personne n’y entre.

Avant tout déménagement, il vaut la peine de régler encore une question qui n’a rien à voir avec la puissance : au nom de qui le domaine est enregistré, et au nom de qui l’est le compte d’hébergement. Nous en avons écrit à part dans l’article sur les erreurs à éviter lors de la création d’un site web, et c’est l’une de ces questions qui, le jour de la migration, ne se réparent plus vite, parce que la réponse dépend d’une personne avec laquelle vous n’avez peut-être plus de conversation.

Ce que vous achetez lorsque l’offre s’appelle infogérée

L’écart de prix entre une machine non infogérée et une machine infogérée est grand, et ce n’est pas une majoration sur la même marchandise, donc il est honnête de poser les deux chiffres côte à côte. Au tarif Hetzner entré en vigueur le 15 juin 2026, le serveur cloud CX23 avec deux vCPU, quatre gigaoctets de mémoire et 40 Go de disque coûte 5,49 € par mois hors taxes, et l’adresse IPv4 principale s’y ajoute pour 0,50 € par mois. Notre hébergement infogéré commence à 45 €/mois, et l’écart entre ces deux chiffres est précisément le sujet de cette section.

L’écart, c’est du travail, et on peut le compter pièce par pièce : mises à jour du système d’exploitation et des logiciels serveur, configuration de sécurité, supervision avec Zabbix vingt-quatre heures sur vingt-quatre et réaction selon le SLA, sauvegardes chaque jour avec 30 jours de conservation et une restauration régulièrement testée, et pour une infrastructure particulièrement critique — jusqu’à 365 jours et dans deux pays distincts de l’Union européenne. La préparation de l’environnement et le transfert prennent 3 à 10 jours, nous menons la migration en parallèle et basculons le DNS dans une fenêtre planifiée, et ensuite vous avez un interlocuteur responsable, pas un ticket de support dans un autre fuseau horaire.

Il faut dire honnêtement l’autre face, parce que sans elle cette section serait un tarif entouré d’un article. Si votre site est statique, la fréquentation faible et que personne ne demande jamais une version de PHP que l’hébergeur n’a pas, alors l’hébergement mutualisé à quelques euros par mois est la bonne réponse, et un environnement infogéré serait le prix d’une tranquillité d’esprit que vous avez déjà. Nous le disons aussi à ceux qui appellent avec cette question, parce que vendre un environnement dont on ne se sert pas est une affaire à court terme — un an plus tard, cela revient comme la question de ce pour quoi l’on a vraiment payé, et il n’y a pas de bonne réponse.

Si vous n’êtes pas sûr de quel côté de cette frontière se trouve votre site, on peut lire ces quatre chiffres ensemble : écrivez-nous, et nous vous dirons ce que montrent les statistiques de votre compte actuel et quelle limite vous est la plus proche — y compris si la réponse est qu’il n’y a aucune raison de déménager et qu’il vaut mieux investir l’argent dans la vitesse du site.