Serveur dédié vs VPS vs mutualisé : comment choisir

Entre un serveur dédié, un VPS et un hébergement mutualisé, la présentation habituelle tient en une échelle de prix et de puissance. C’est commode et c’est trompeur, parce que les trois formules ne diffèrent pas par la quantité de ressources mais par ce qui sépare votre site de celui du voisin. Cette frontière détermine tout le reste : ce que vous pouvez installer, ce que vous subissez sans le voir, et ce que vous pouvez mesurer.

Trois niveaux d’isolation, pas trois tailles

	Mutualisé	VPS	Dédié
Ce qui est partagé	Le système et ses processus	La machine physique	Rien
Accès administrateur	Non	Oui	Oui
Choix des logiciels et versions	Ce que l’hébergeur propose	Libre	Libre
Voisins visibles dans vos mesures	Non mesurable	Mesurable	Aucun
Redimensionnement	Changement d’offre	À chaud, en minutes	Migration physique

La ligne décisive est la deuxième. Sans accès administrateur, vous ne pouvez ni changer une version de PHP, ni installer un outil de diagnostic, ni appliquer la plupart des mesures décrites dans notre article sur la sécurité d’un serveur. Vous dépendez entièrement des choix de l’hébergeur, y compris sur le calendrier des mises à jour.

Le voisin bruyant, et comment le voir

Sur un VPS, plusieurs machines virtuelles se partagent un processeur physique. Quand l’hébergeur en installe plus que la machine ne peut réellement en servir, votre système attend son tour sans que rien ne l’indique dans les outils habituels : la charge paraît normale, la mémoire est libre, et pourtant tout est lent.

Il existe une mesure qui le révèle, et c’est l’un des rares chiffres vraiment utiles de ce domaine : le temps de vol, ou steal time. Il compte le pourcentage de temps pendant lequel votre machine virtuelle était prête à calculer mais n’a pas obtenu le processeur, parce qu’un voisin l’occupait.

vmstat 1 5          # colonne « st »
top                 # ligne CPU, valeur « st »

Lisez la colonne st. À zéro ou proche de zéro, vous obtenez le processeur quand vous le demandez. Si elle s’installe durablement à plusieurs pour cent, la machine physique est surchargée et aucune optimisation de votre côté n’y changera quoi que ce soit : vous payez une ressource que vous n’avez pas. C’est l’argument à présenter au support, et c’est le seul qui soit incontestable.

Sur un hébergement mutualisé, cette mesure n’est même pas accessible : vous n’avez pas de système à vous. C’est la différence de nature entre les deux formules, bien plus que le prix.

Ce que le dédié apporte réellement

Une machine physique sans hyperviseur supprime deux choses : le partage du processeur, et la couche de virtualisation elle-même. Le gain se concentre sur la performance d’un seul cœur, ce qui compte pour les traitements qui ne se répartissent pas.

C’est décisif pour un serveur de jeu, dont la boucle de simulation s’exécute pour l’essentiel sur un cœur unique, comme nous l’expliquons dans notre guide sur l’optimisation d’un serveur de jeu dédié. Ça l’est beaucoup moins pour un site web classique, où l’attente vient des requêtes en base de données bien avant le processeur.

Le revers est la rigidité. Un VPS se redimensionne en quelques minutes sans changer d’adresse. Une machine physique saturée impose une migration complète, avec la préparation que cela suppose, y compris du côté des noms de domaine comme décrit dans notre article sur la propagation DNS.

Comment un mutualisé lâche, concrètement

Un hébergement mutualisé ne ralentit pas progressivement : il bute sur des plafonds, et chacun produit un symptôme différent. Les reconnaître évite de conclure trop vite qu’il faut changer d’offre.

• Le quota de processeur. Passé un certain temps de calcul, l’hébergeur bride le compte. Le site devient lent aux heures de pointe puis redevient normal, sans qu’aucune modification ait eu lieu.
• Le nombre de traitements simultanés. C’est le plafond le plus fréquent et le plus déroutant : au-delà de quelques requêtes en même temps, les suivantes sont mises en file ou refusées. Le site paraît hors service alors que la charge globale est faible.
• Le nombre de fichiers. Beaucoup d’offres limitent le nombre d’entrées sur le disque et non seulement leur poids. Un site de quelques centaines de mégaoctets peut atteindre ce plafond par ses vignettes d’images, et les envois échouent alors que l’espace annoncé reste libre.
• Les processus longs. Une tâche qui dépasse le temps d’exécution autorisé est interrompue, ce qui casse les imports, les sauvegardes et les migrations au milieu.

Ces plafonds figurent rarement en page d’accueil de l’offre, et presque toujours dans les conditions techniques. Relevez-les avant de souscrire : ils expliquent la plupart des pannes attribuées à tort à un « manque de puissance », et ils sont le vrai motif de passage au VPS.

Les questions à poser avant de souscrire

1. Les ressources sont-elles garanties ou opportunistes ? Certaines offres annoncent une puissance atteignable par à-coups, pas en continu. La formulation à repérer parle de ressources « partagées » ou « en rafale ».
2. Quel est le stockage ? Un disque à mémoire flash change davantage le ressenti qu’un cœur supplémentaire, sur la plupart des sites.
3. Les instantanés sont-ils inclus ? Sur un VPS, pouvoir figer l’état de la machine avant une mise à jour vaut tous les plans de secours. Ce n’est pas pour autant une sauvegarde, comme nous le rappelons dans notre guide sur les sauvegardes automatiques.
4. Qui applique les correctifs du système ? Sur un VPS et un dédié non infogérés, c’est vous. Beaucoup de serveurs abandonnés le sont parce que personne n’avait compris ce point à la signature.
5. Quelle est la politique en cas de dépassement ? Suspension, facturation supplémentaire ou simple ralentissement : les trois existent et n’ont pas les mêmes conséquences.

Le critère qui tranche, et il n’est pas technique

La réserve mérite d’être posée nettement : un VPS ou un dédié non administré est une charge de travail permanente, pas seulement une dépense.

Correctifs à appliquer, journaux à surveiller, certificats à renouveler, sauvegardes à tester. Un mutualisé bien tenu par un hébergeur sérieux vaut mieux qu’un VPS puissant que personne ne met à jour pendant deux ans. Le second finit compromis, et la puissance n’y aura rien changé.

• Site vitrine ou blog, sans compétence système disponible : mutualisé, sans hésiter.
• Besoin d’une version logicielle précise, d’un outil particulier, ou d’un accès administrateur : VPS. C’est la marche la plus utile de l’échelle.
• Charge régulière et élevée, ou besoin de performance sur un seul cœur : dédié.
• Charge très variable : ni l’un ni l’autre exactement, la question devient celle du dimensionnement élastique, traitée dans notre article sur le choix entre sur site et cloud.

Questions fréquentes sur le choix d'un hébergement

Quelle est la différence entre un VPS et un serveur dédié ?

Un VPS est une machine virtuelle qui partage un processeur physique avec d’autres, un serveur dédié est une machine entière sans hyperviseur. Le dédié apporte surtout de la performance sur un seul cœur, le VPS apporte de la souplesse et se redimensionne en quelques minutes.

Comment savoir si mon VPS est surchargé par ses voisins ?

En lisant le temps de vol, la colonne « st » des commandes vmstat ou top. Elle compte le temps où votre machine était prête à calculer sans obtenir le processeur. Une valeur durablement à plusieurs pour cent signale une machine physique surchargée.

Un hébergement mutualisé est-il suffisant pour un site vitrine ?

Le plus souvent oui, surtout sans compétence système disponible en interne. Un mutualisé tenu à jour par l’hébergeur vaut mieux qu’un VPS puissant dont personne n’applique les correctifs.

Faut-il un VPS ou un dédié pour un serveur de jeu ?

Le dédié est préférable dès que la fréquentation est sérieuse, car la boucle de simulation d’un jeu s’exécute pour l’essentiel sur un seul cœur et supporte mal le partage du processeur avec des voisins.

Qui applique les mises à jour de sécurité sur un VPS ?

Vous, sauf si vous souscrivez une offre infogérée. C’est le point le plus souvent mal compris à la souscription, et la cause principale des serveurs laissés vulnérables pendant des années.