Hébergement mutualisé ou VPS : lequel choisir ?

Hébergement mutualisé ou VPS : réponse courte

La différence entre l’hébergement mutualisé et un VPS ne se résume pas à la vitesse. Avec un hébergement mutualisé, vous louez un compte sur une machine qu’un autre prestataire configure, met à jour et partage entre des centaines de clients. Avec un VPS (virtual private server), vous louez un système d’exploitation complet avec un accès root. Vous installez donc ce que vous voulez, mais vous devez aussi réparer ce que vous cassez.

Trois éléments font réellement la différence. Soit vous avez accès à root, soit vous ne l’avez pas. Soit votre mémoire vous est attribuée, soit vous l’empruntez à un pool de ressources. Et lorsque le serveur ne répond plus à minuit, soit l’hébergeur intervient, soit c’est à vous de le faire. Toutes les différences d’un tableau comparatif découlent de ces trois éléments.

Si votre site se limite à des pages, des images et un formulaire de contact, l’hébergement mutualisé est le bon choix et coûte moins cher. Si votre site nécessite un programme qui reste exécuté lorsqu’aucun visiteur n’est connecté, vous avez besoin d’un VPS.

Ce que l’hébergement mutualisé vous fournit réellement

Un seul serveur Linux exécute simultanément les comptes de nombreux clients. Chaque compte possède un répertoire personnel avec une racine de documents, une base de données et une boîte aux lettres. Un serveur web unique, généralement Apache ou LiteSpeed, sert tous les sites hébergés sur le serveur. Vous utilisez un panneau de contrôle à la place d’un shell. Vous n’avez pas accès à root. Vous ne pouvez donc pas installer de paquet, ouvrir un port ni démarrer un service en arrière-plan.

La plupart des hébergeurs mutualisés utilisent CloudLinux. Celui-ci place chaque compte dans son propre conteneur, avec une limite stricte sur le temps processeur et sur le nombre de processus exécutables simultanément. Dépasser la limite de processus ne ralentit pas votre site. Le serveur renvoie une page d’erreur contenant 508 Resource Limit Is Reached. Cette page indique que votre propre compte a atteint sa limite. Elle ne signifie pas qu’un autre client consomme votre part de ressources.

Ce compromis est volontaire. Vous renoncez au contrôle. En contrepartie, l’hébergeur met à jour le kernel, actualise PHP, renouvelle le certificat et conserve une sauvegarde nocturne. Pour un grand nombre de sites, ce compromis est pertinent.

Ce que vous offre réellement un VPS

Un VPS est une machine virtuelle qui s’exécute sur un serveur hôte. Avec KVM, l’hyperviseur utilisé par la plupart des offres de VPS Linux, votre instance démarre avec son propre kernel et possède sa propre adresse IP, son propre firewall et son propre système init. sudo fonctionne. apt install fonctionne. Un programme que vous démarrez avec systemd continue de fonctionner après votre déconnexion, redémarre s’il plante et revient après un redémarrage.

C’est aussi cet accès root qui fait de la sécurité de la machine votre responsabilité. Personne d’autre ne la surveille. L’éventail des usages d’un VPS est large pour cette raison précise : la machine peut faire tout ce qu’un serveur Linux peut faire.

Différence 1 : l’accès root et ce qu’il permet

root est la différence à l’origine de toutes les autres. Avec cet accès, vous pouvez installer n’importe quel paquet de la distribution, écouter sur n’importe quel port, écrire une unité systemd, lire tous les journaux de la machine et modifier les paramètres du noyau avec sysctl. Sans cet accès, vous devez vous contenter des options proposées par le panneau : un sélecteur de version PHP, un ensemble fixe d’extensions et un formulaire pour les tâches cron.

Sur un VPS, vous pouvez toujours demander à la machine quels services écoutent sur des ports :

ss -ltnp

Chaque ligne correspond à un socket ouvert et indique le processus qui le possède. Un service qui n’a pas démarré apparaît donc par une ligne manquante. En hébergement mutualisé, cette question n’a pas de réponse, car les ports 80 et 443 appartiennent au serveur web de l’hébergeur et rien de ce que vous écrivez ne peut les utiliser.

Différence 2 : mémoire allouée et mémoire empruntée

L’hébergement mutualisé est vendu en partant du principe que peu de comptes sont actifs au même moment. La mémoire de la machine forme un pool, et la part attribuée à votre compte est une limite, pas une réservation. Lorsque cette part est épuisée, les processus PHP sont tués et les visiteurs reçoivent une erreur 500 ou 508.

Sur un VPS, la mémoire incluse dans votre offre appartient à votre instance. free -m l’affiche, et aucun processus situé en dehors de votre machine virtuelle ne peut vous la retirer.

Le temps processeur fait honnêtement exception. La plupart des offres VPS partagent les cœurs physiques entre plusieurs clients, et vous pouvez le mesurer vous-même :

vmstat 1 5

La colonne st indique le steal time : la part du temps pendant laquelle votre processeur virtuel était prêt à s’exécuter, alors que le cœur physique était attribué à un autre client. Une valeur stable de quelques pour cent est normale. Une valeur durablement supérieure à 10 % indique que l’hôte est surabonné. Vous pouvez citer cette valeur dans un ticket au support. En hébergement mutualisé, il n’existe pas de mesure équivalente, car les outils qui l’afficheraient nécessitent root. Le stockage se comporte de la même manière. C’est pourquoi le type de disque utilisé par une offre VPS est important et pourquoi il est utile de mesurer vous-même un nouveau VPS durant la première semaine, plutôt que de faire confiance à la page commerciale.

Différence 3 : qui est responsable en cas de panne

Sur un hébergement mutualisé, l’hébergeur gère le système d’exploitation, le serveur web, la version de PHP, les certificats et la sauvegarde nocturne. Lorsque la machine ne répond plus, vous ouvrez un ticket et quelqu’un travaille déjà sur le problème. La contrepartie, c’est que vous ne pouvez pas leur demander d’installer un élément qu’ils ne prennent pas en charge.

Sur un VPS non administré, le fournisseur gère l’hyperviseur, le réseau et l’alimentation électrique. Tout ce qui se trouve au-dessus du kernel relève de votre responsabilité. Les mises à jour de sécurité, le firewall, les sauvegardes, le renouvellement des certificats et la supervision sont à votre charge. Le support ne se connectera pas pour diagnostiquer la configuration de votre serveur web. Prévoyez cette charge dès le premier jour : les dix premières minutes sur un nouveau VPS, puis un firewall que vous comprenez, les mises à jour de sécurité automatiques et des sauvegardes que vous avez restaurées au moins une fois.

Quand l’hébergement mutualisé est le bon choix

Un site vitrine est le cas le plus évident : quelques pages, des images, un formulaire de contact, éventuellement WordPress avec un plugin de cache, et quelques milliers de visites par jour. Aucun job en arrière-plan. Aucun runtime inhabituel. Rien qui doive rester en mémoire entre les requêtes. L’hébergement mutualisé convient très bien à ce type de site, coûte moins cher qu’un VPS et confie la maintenance à des personnes qui s’en occupent à plein temps. Le déplacer vers un VPS n’apporte rien et ajoute une tâche dont vous n’aviez pas besoin.

Il existe un deuxième cas, moins souvent pris en compte. Si personne de votre côté ne veut consulter un fichier de log ou exécuter apt upgrade, l’hébergement mutualisé est le choix le plus sûr. Un VPS non patché avec un port de base de données ouvert est une situation pire qu’un compte mutualisé maintenu à jour par un professionnel. Le contrôle n’est un avantage que si quelqu’un l’exerce.

Signe 1 : vous avez besoin d’un programme qui reste en fonctionnement

Un daemon est un programme qui reste en mémoire et attend du travail : une API, un chatbot, un worker de file d’attente ou un serveur de jeu. Un hébergement mutualisé n’exécute votre code que lorsqu’une requête arrive. Tout programme que vous laissez tourner depuis une session SSH (secure shell) est arrêté, car un processus de longue durée compte dans la limite de processus du compte.

Sur un VPS, le même programme devient une unité systemd :

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status doit afficher Active: active (running) avec un process ID. S’il affiche Active: failed (Result: exit-code), la raison se trouve dans journalctl -u myapp -n 50, qui montre la sortie du programme au moment où il s’est arrêté. Restart=always dans le fichier d’unité le relance après un crash, et enable le relance après un reboot. Écrire des services et des timers systemd est la première compétence VPS qu’il vaut la peine d’apprendre correctement.

Signe 2 : vous avez besoin d’un runtime que le panneau ne propose pas

Le panneau vous fournit une liste. Si votre application a besoin d’une version de langage absente de cette liste, d’une bibliothèque à compiler, de ffmpeg, d’un navigateur headless ou d’une base de données autre que MySQL, l’hébergement mutualisé n’a aucun emplacement où les installer. L’installation de logiciels nécessite root. Or le compte ne dispose ni de compilateur ni d’en-têtes de développement. La compilation échoue donc avant de produire quoi que ce soit.

Sur un VPS, vous l’installez avec apt install, ou vous l’exécutez dans un conteneur pour garder l’hôte propre. Docker Compose sur un VPS est généralement la solution dès que l’application comporte plusieurs composants interdépendants.

Signe 3 : votre tâche cron doit s’exécuter à l’heure

Les hébergeurs mutualisés acceptent les tâches cron via un formulaire et imposent un intervalle minimal, généralement de cinq ou quinze minutes. Une tâche qui dépasse la limite de processeur du compte est arrêtée en cours d’exécution. Elle échoue silencieusement, car rien n’écrit dans un journal auquel vous avez le droit d’accéder.

Sur un VPS, crontab -e accepte toute planification que vous indiquez. Un timer systemd est encore préférable :

systemctl list-timers
journalctl -u cron -n 20

list-timers affiche la prochaine exécution et le dernier résultat de chaque timer. Le journal cron affiche chaque commande au moment de son exécution. Lorsqu’une tâche ne s’exécute pas, vous pouvez déterminer si elle n’a jamais démarré ou si elle a démarré puis échoué. Cette distinction constitue l’essentiel du dépannage d’une tâche planifiée.

Signe 4 : vos voisins augmentent votre temps de réponse

Le symptôme est précis. La même page, sans aucune modification de votre code, répond rapidement la nuit et lentement à 19 heures. Mesurez le temps de réponse depuis votre propre machine avant d’accuser qui que ce soit :

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer correspond au délai avant réception du premier octet de la réponse, en secondes. Si les 20 valeurs restent proches, le serveur n’est pas en cause et la correction concerne votre code ou vos requêtes SQL. Si elles restent stables à 3 h du matin, mais varient de plusieurs centaines de millisecondes aux heures de pointe, vous partagez une machine très sollicitée avec des comptes auxquels vous n’avez pas accès. C’est le seul facteur que vous ne pouvez pas corriger avec un meilleur code, car la cause se trouve de l’autre côté de la limite entre les comptes.

Ce que la migration coûte réellement

Voici les prix généralement affichés en août 2026 pour la plus petite offre de chaque catégorie. Considérez-les comme des ordres de grandeur, pas comme un devis, et vérifiez le prix actuel avant d’acheter.

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

L’écart affiché va de 3 à 5 dollars américains par mois, mais ce n’est pas ce chiffre qui permet de décider. L’hébergement mutualisé affiche un tarif de première période qui exige généralement de payer un à trois ans à l’avance, puis le renouvellement passe à environ 12 dollars. Comparez les tarifs de renouvellement entre eux et la perspective change : 12 dollars pour le compte mutualisé, contre 6 dollars pour un VPS d’entrée de gamme.

Soyez prudent avec cette comparaison, car les dimensions ne sont pas équivalentes. Un VPS avec 1 vCPU et 1 GB exécute le serveur web et la base de données sur une petite machine unique. C’est limité pour WordPress dès que le trafic réel augmente. La comparaison réellement équivalente avec une offre mutualisée renouvelée est la formule avec 2 vCPU et 4 GB, à environ 15 dollars. Le surcoût réel est donc de quelques dollars par mois, pas un multiple du prix.

Le coût le plus important n’apparaît jamais sur la facture. Un VPS ajoute une heure de configuration, quelques minutes chaque mois pour les mises à jour, ainsi que la soirée que vous passerez à intervenir la première fois qu’un problème surviendra. Évaluez ce temps selon votre propre tarif horaire et l’écart se réduit rapidement. Ce qu’un VPS coûte en pratique détaille davantage les différentes tailles.

Déplacer un site d’un hébergement mutualisé sans perdre de trafic

1. La veille, réduisez le TTL (time to live) DNS (domain name system) du domaine à 300 secondes. Le changement prendra effet en quelques minutes au lieu de plusieurs heures.
2. Préparez le nouveau serveur et faites fonctionner le site sur son adresse IP avant de modifier le DNS.
3. Copiez les fichiers, puis exportez la base de données et restaurez-la sur le nouveau serveur.
4. Testez le site avec le fichier hosts de votre ordinateur portable. Ce fichier dirige le domaine vers la nouvelle adresse IP uniquement pour votre machine.
5. Émettez le certificat TLS (transport layer security) sur le nouveau serveur, modifiez l’enregistrement A et laissez le compte mutualisé actif pendant une semaine.

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig affiche le TTL dans la deuxième colonne de sa réponse. Vous pouvez ainsi vérifier que la valeur réduite est active avant de modifier quoi que ce soit. --single-transaction crée un snapshot cohérent sans verrouiller les tables. C’est important si l’ancien site continue à traiter des commandes pendant l’intervention. Sur le nouveau serveur, faites fonctionner les certificats le jour même : Let's Encrypt sur Ubuntu avec nginx ne demande que quelques minutes une fois que l’enregistrement DNS pointe vers le serveur.

Des ressources sans les responsabilités

Si les quatre signes décrivent votre site, mais que la maintenance ne vous convient pas, le VPS géré constitue l’option intermédiaire. Vous conservez la mémoire allouée et les droits root, tandis que le fournisseur prend en charge les mises à jour, la supervision et, généralement, un panneau d’administration. Le graphique ci-dessus estime son coût à environ 30 dollars, contre 15 pour un VPS non géré de même capacité. La différence finance l’intervention d’un tiers lorsque le serveur ne répond plus pendant la nuit.

Le choix entre un VPS géré et un VPS non géré est la prochaine lecture recommandée si cette situation vous concerne. Si vous exploitez déjà un VPS très sollicité et que le steal time reste élevé aux heures de pointe, l’étape suivante est un serveur dédié sans aucun voisin.

FAQ

Un VPS est-il plus rapide qu’un hébergement mutualisé ?

Pas automatiquement. Un serveur mutualisé peu chargé peut être plus rapide qu’un VPS avec 1 vCPU pour une seule page WordPress. L’intérêt d’un VPS est la régularité : la mémoire incluse dans votre offre vous est réservée, donc le temps de réponse dépend de votre code et non du compte le plus chargé de la machine. Si vos pages sont lentes à 3am comme à 7pm, la cause vient de votre code ou de vos requêtes SQL, et déplacer le même code sur un VPS ne fait que déplacer le problème.

Puis-je exécuter une application Node.js ou Python sur un hébergement mutualisé ?

Parfois, mais uniquement dans des limites strictes. Certains panels démarrent une application pour vous avec Passenger, qui l’exécute lorsqu’une requête arrive. Vous ne pouvez pas utiliser votre propre port d’écoute, car le serveur web de l’hébergeur utilise 80 et 443. Vous ne pouvez pas conserver un worker en mémoire entre les requêtes, car la limite de processus du compte arrête tout processus de longue durée. Un bot, un worker de file d’attente ou un serveur WebSocket nécessite un VPS.

Dois-je connaître Linux pour administrer un VPS ?

Pour un VPS non managé, oui. Vous devez savoir utiliser les clés SSH, un firewall, les mises à jour et les sauvegardes, et prendre l’habitude de consulter les journaux. Prévoyez une heure pour la configuration initiale, puis quelques minutes par mois. Si vous ne souhaitez pas effectuer ces tâches, une offre managée conserve les ressources qui vous sont attribuées et confie la maintenance au fournisseur. C’est le compromis décrit dans hébergement VPS managé ou non managé.

Mon site sera-t-il indisponible pendant le passage de l’hébergement mutualisé à un VPS ?

Non, si vous réduisez d’abord le TTL DNS et laissez les deux comptes fonctionner. Définissez le TTL à 300 secondes un jour à l’avance, copiez les fichiers et la base de données, testez le nouveau serveur avec le fichier hosts de votre ordinateur portable, puis modifiez l’enregistrement A. Pendant quelques minutes, certains visiteurs accéderont à l’ancien serveur et d’autres au nouveau. Laissez donc le compte mutualisé actif pendant une semaine. Activez le mode lecture seule pendant le dernier dump de la base de données, ou acceptez de perdre les données écrites pendant cette période.