Hébergement mutualisé ou VPS : lequel choisir ?

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

L’hébergement mutualisé ou VPS n’est pas une question de vitesse. Avec un hébergement mutualisé, vous louez un compte sur une machine qu’un autre administrateur configure, met à jour et partage entre plusieurs clients. Avec un VPS (virtual private server) non managé, 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. Vous avez accès à root ou non. L’allocation mémoire et les garanties dépendent de l’offre. Et lorsque le serveur ne répond plus à minuit, c’est soit l’hébergeur qui intervient, soit vous. Toutes les fonctionnalités présentées dans 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 pour de nombreux sites. Si votre site a besoin d’un programme qui reste actif même lorsqu’aucun visiteur ne le consulte, vérifiez que votre hébergeur mutualisé prend en charge les services persistants avant de choisir un VPS.

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

Un seul serveur Linux exécute simultanément de nombreux comptes client. Chaque compte comprend un répertoire personnel avec une racine de documents, une base de données et une boîte aux lettres. Un seul serveur web, généralement Apache ou LiteSpeed, sert tous les sites présents sur le serveur. Vous disposez d’un panneau de contrôle, et certains hébergeurs proposent également un shell. Vous n’avez pas accès à root, mais certains fournisseurs autorisent l’installation de logiciels dans votre répertoire personnel, ainsi que l’utilisation de ports autorisés et de services en arrière-plan.

De nombreux hébergeurs mutualisés utilisent CloudLinux, qui place chaque compte dans son propre conteneur léger et limite le temps processeur, la mémoire, les entrées-sorties disque, le nombre de processus et le nombre de processus d’entrée. Chaque limite se manifeste différemment. Le dépassement de la limite processeur ou disque ralentit les réponses de votre site, sans le rendre indisponible. Le dépassement de la limite mémoire ou du nombre de processus se traduit généralement par des erreurs 500 et 503. Avec Apache, la page d’erreur intitulée 508 Resource Limit Reached est due à la limite du nombre de processus d’entrée ; LiteSpeed gère les processus d’entrée différemment. Dans tous les cas, c’est votre compte qui atteint sa propre limite, et non un autre client qui consomme votre part.

Ce compromis est volontaire. Vous renoncez au contrôle et, en contrepartie, l’hébergeur applique les correctifs au kernel et assure la maintenance des logiciels pris en charge. Le renouvellement des certificats et les calendriers de sauvegarde dépendent de l’offre. Pour un grand nombre de sites, ce compromis est intéressant.

Ce qu’un VPS vous fournit réellement

Un VPS est une machine virtuelle qui s’exécute sur un serveur hôte. Avec KVM, votre instance démarre son propre kernel et possède sa propre adresse IP, son propre firewall et son propre système init. Sur un VPS Linux non administré avec un accès root, sudo fonctionne. Sur une installation Debian ou Ubuntu, apt install fonctionne. Un programme lancé avec systemd continue de s’exécuter après votre déconnexion. Avec la configuration appropriée du redémarrage et du démarrage, il redémarre après un crash et revient après un reboot.

C’est aussi pour cette raison que la sécurité de la machine devient votre responsabilité. Personne d’autre ne la surveille. L’éventail des services que l’on peut exécuter sur un VPS est large précisément pour cette raison : cette machine peut faire tout ce qu’un serveur Linux peut faire.

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

root vous donne le contrôle du système d’exploitation. 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, le panneau n’est pas toujours la seule limite : alwaysdata permet d’installer des extensions PHP supplémentaires avec ad_install_pecl.

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

ss -ltnp

Chaque ligne de socket indique un listener TCP. Les détails du processus dépendent de vos permissions. Ainsi, un service qui devrait écouter en TCP mais qui n’a pas démarré apparaît sous la forme d’une ligne manquante. En hébergement mutualisé, l’accès aux informations sur les sockets et l’autorisation d’exécuter vos propres listeners dépendent du fournisseur, même si l’hébergeur contrôle les ports 80 et 443.

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

L’hébergement mutualisé repose sur l’hypothèse que peu de comptes sont actifs au même moment. La mémoire de la machine constitue un pool, et la part de votre compte correspond à une limite plutôt qu’à une réservation. Avec CloudLinux, atteindre la limite de mémoire physique tue des processus, et les visiteurs peuvent recevoir une erreur 500 ou 503.

Sur un VPS, free -m indique la mémoire visible par votre guest. Cela ne prouve pas qu’une quantité de mémoire physique vous est irrévocablement réservée. Un hébergeur peut récupérer de la mémoire du guest au moyen du ballooning. Les garanties de ressources du fournisseur déterminent si cette opération est autorisée pour votre offre.

Le temps processeur est une autre ressource partagée sur les offres de VPS à CPU partagé. Vous pouvez mesurer vous-même le steal time :

vmstat 1 5

La colonne st correspond au 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 guest. Il n’existe pas de pourcentage normal universel ni de seuil prouvant une surallocation. Un steal time durable constitue toutefois une mesure que vous pouvez communiquer dans un ticket au support. vmstat doit pouvoir accéder aux fichiers /proc concernés. Les lectures courantes ne nécessitent pas root, mais un hébergeur mutualisé peut limiter cette visibilité. Le stockage est également une ressource à contrôler. C’est pourquoi le type de disque utilisé par une offre VPS est important, et pourquoi il est préférable de mesurer vous-même un nouveau VPS dès 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 et les versions de PHP prises en charge ; la couverture des certificats et des sauvegardes dépend de l’offre. Lorsque la machine ne répond plus, vous ouvrez un ticket ; le délai et le niveau de réponse dépendent des conditions de support de l’hébergeur. La contrepartie de cette règle concerne les logiciels qui ne sont pas pris en charge : ils doivent être compatibles avec les politiques d’installation et de service de l’hébergeur.

Sur un VPS non géré, le fournisseur est responsable de l’hyperviseur, du réseau et de l’alimentation électrique. Tout ce qui se trouve au-dessus du kernel est sous votre responsabilité. Les mises à jour de sécurité, le firewall, les sauvegardes, le renouvellement des certificats et la supervision relèvent tous de votre travail, et le support ne se connectera pas pour diagnostiquer la configuration de votre serveur web. Prévoyez ces tâches 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 un trafic qui reste dans les limites de ressources du forfait. 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 et confie la maintenance du serveur à des personnes qui s’en occupent à temps plein ; comparez les prix, car il n’est pas moins cher que tous les VPS. Le déplacer sur un VPS n’apporte rien et ajoute une tâche que vous n’aviez pas.

Il existe un deuxième cas, moins souvent mentionné. Si personne dans votre équipe ne veut lire un fichier journal ou exécuter apt upgrade, l’hébergement mutualisé est le choix le plus sûr. Un VPS non corrigé avec un port de base de données ouvert est une situation plus grave qu’un compte mutualisé maintenu à jour par un professionnel. Le contrôle n’est un avantage que si quelqu’un l’utilise.

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

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. Les règles de l’hébergement mutualisé varient : DreamHost interdit les processus persistants sur les offres mutualisées, tandis qu’alwaysdata propose des services personnalisés supervisés sur ses offres payantes.

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 identifiant de processus. 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 de son arrêt. Restart=always dans le fichier d’unité le relance après un crash, et enable le relance après un redémarrage. Écrire des services et des timers systemd est la première compétence VPS qu’il vaut la peine d’apprendre correctement.

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

Le panneau vous fournit une liste. Si votre application nécessite une version de langage absente de cette liste, une bibliothèque à compiler, ffmpeg, un navigateur headless ou une base de données que le panneau ne propose pas (cPanel prend en charge MySQL et, lorsque l’hébergeur l’active, PostgreSQL), consultez les règles d’installation du fournisseur. Installer des logiciels dans votre répertoire personnel ne nécessite pas toujours les privilèges root : DreamHost documente la compilation de zlib et l’installation d’une version personnalisée de Python sur des serveurs mutualisés.

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 lorsque l’application comporte plusieurs composants.

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

Les hébergeurs mutualisés acceptent les tâches cron via un formulaire et peuvent imposer leur propre intervalle minimal. Sur CloudLinux, une tâche qui atteint la limite de processeur du compte est ralentie au lieu d’être arrêtée. Une tâche longue peut donc être encore en cours lorsque l’exécution suivante est prévue. Si le compte a déjà atteint sa limite de processus, la tâche ne peut plus démarrer de nouveaux processus. Vous pouvez observer une partie de ce comportement : le paramètre Cron Email de cPanel vous envoie la sortie de chaque tâche par e-mail. Sur les hébergeurs CloudLinux qui proposent cette fonction, la page Resource Usage du panneau indique la limite atteinte par le compte et comptabilise les dépassements. L’accès aux journaux système et l’autorisation d’augmenter les limites restent du ressort de l’hébergeur. Certains fournisseurs affichent toutefois les journaux des tâches avec leurs heures de début et de fin.

Sur un VPS, crontab -e accepte les planifications prises en charge par l’implémentation cron installée. Un timer systemd est toutefois préférable :

systemctl list-timers
journalctl -u cron -n 20

list-timers affiche les prochaines heures de déclenchement et les dernières heures de déclenchement des timers actuellement en mémoire, mais pas le résultat de sortie de leurs services. Le journal cron dépend du service cron installé et de la configuration de la journalisation. Lorsqu’une tâche ne s’exécute pas, consultez l’état et les journaux de son service pour déterminer si elle n’a jamais démarré ou si elle a démarré puis échoué. Cette distinction constitue l’essentiel du débogage d’une tâche planifiée.

Signe 4 : vos voisins vous font perdre du temps de réponse

Le symptôme est caractéristique. La même page, sans aucune modification de votre code, répond rapidement la nuit et lentement à 19 heures. Mesurez cela 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 le premier octet de la réponse, en secondes. Si les 20 valeurs restent proches, cela indique un délai régulier, mais ne permet pas de déterminer si la cause vient du serveur, du code ou de la base de données. Si les valeurs restent stables à 3 heures du matin et varient de plusieurs centaines de millisecondes aux heures de pointe, comparez l’utilisation des ressources du compte, le volume de requêtes et les journaux du serveur avant d’accuser les comptes voisins. Ces mesures incluent l’établissement de la connexion et le traitement par le serveur. Elles ne suffisent donc pas à établir la cause.

Ce que coûte réellement la migration

Voici des exemples de tarifs affichés, vérifiés le 4 novembre 2026. Il ne s’agit ni de moyennes pour toute une catégorie ni des offres les moins chères disponibles. Les exemples d’hébergement mutualisé, de VPS 4 GB et d’offre managée correspondent respectivement aux offres Web Hosting Launch, Stack 4 et Managed VPS Business de DreamHost, avec une facturation annuelle. Le VPS 1 GiB correspond à l’offre Basic Droplet standard de DigitalOcean, facturée au plafond mensuel. Vérifiez le tarif en vigueur avant d’acheter.

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

L’écart affiché va de 2.89 à 6 dollars américains par mois, mais ce n’est pas ce chiffre qui permet de décider. L’offre mutualisée impose de payer une année à l’avance et est renouvelée au tarif de 10.99 dollars par mois. Si vous comparez les tarifs de renouvellement, le résultat change : 10.99 dollars pour l’offre mutualisée contre 6 dollars pour un VPS d’entrée de gamme. Les deux chiffres de DigitalOcean sont identiques, car cet exemple ne bénéficie d’aucune remise de lancement.

Soyez prudent avec cette comparaison, car les configurations ne sont pas équivalentes. Un VPS doté de 1 vCPU et de 1 GB exécute le serveur web et la base de données sur une petite machine unique. Cela devient vite limité pour WordPress lorsque le trafic réel arrive. L’exemple avec 2 vCPU et 4 GB est renouvelé au tarif de 11.99 dollars par mois, mais les limites d’un compte mutualisé et la capacité d’un VPS ne sont pas directement comparables. Dans ces exemples, le surcoût du VPS au renouvellement par rapport à l’hébergement mutualisé est de un dollar par mois.

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 et la soirée que vous passerez la première fois qu’un problème surviendra. Évaluez ce temps selon votre propre tarif horaire : l’écart se réduit rapidement. Le coût réel d’un VPS compare plus précisément les différentes configurations.

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 et attendez l’expiration de l’ancien TTL avant de basculer. Les caches locaux peuvent mettre plus de temps à se mettre à jour.
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 avec le fichier hosts de votre ordinateur portable. Il associe le domaine à la nouvelle adresse IP uniquement pour votre machine.
5. Obtenez le certificat TLS (transport layer security) sur le nouveau serveur à l’aide d’une validation DNS ou d’un certificat existant valide avant de modifier l’enregistrement A. Conservez le compte d’hébergement 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 confirmer que la valeur réduite est active avant de basculer. --single-transaction crée un instantané cohérent des tables InnoDB sans les verrouiller. Les tables non transactionnelles et les modifications de schéma effectuées en parallèle nécessitent des précautions distinctes. Les commandes passées ultérieurement ne figurent pas dans cet instantané. Sur le nouveau serveur, faites fonctionner les certificats le jour même : Let's Encrypt sur Ubuntu avec nginx ne prend que quelques minutes une fois que l’enregistrement DNS pointe vers le serveur.

Des ressources sans la responsabilité

Si les quatre signes décrivent votre site, mais que sa maintenance ne vous convient pas, l’option intermédiaire est un VPS managé. Le fournisseur prend en charge la maintenance convenue, mais l’accès root et l’étendue de la prise en charge dépendent de l’offre ; le VPS managé de DreamHost n’inclut pas l’accès root. Le tableau ci-dessus indique 31.99 dollars pour son exemple managé de 2 GB, contre 11.99 pour l’exemple non managé de 4 GB. Il ne s’agit donc pas d’une comparaison entre des configurations de même taille. La différence paie l’intervention de quelqu’un lorsque le serveur ne répond plus pendant la nuit.

Le choix entre un VPS managé et un VPS non managé est la prochaine lecture à consulter si cela vous correspond. Si vous exploitez déjà un VPS très sollicité et que le vol de temps reste important aux heures de pointe, l’étape suivante consiste à choisir 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. La mémoire attribuée ne supprime pas la concurrence sur le CPU : avec un VPS à CPU partagé, les instances voisines peuvent encore affecter le temps de réponse, et les garanties de mémoire dépendent du fournisseur. Si vos pages sont lentes à 3am comme à 7pm, vérifiez le code, les requêtes de base de données et les limites de ressources de l’hébergement ; l’heure de la journée ne permet pas d’établir la cause.

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

Parfois, dans les limites fixées par le fournisseur. Certains panels démarrent l’application pour vous via Passenger, puis celle-ci s’exécute lorsqu’une requête arrive. Le fait que l’hébergeur contrôle les ports 80 et 443 n’empêche pas les autres services autorisés d’écouter : alwaysdata autorise les services personnalisés sur les ports 8300 à 8499 en IPv6 sur son Public Cloud. Les règles applicables aux processus persistants varient également selon l’hébergeur. Un bot, un worker de file d’attente ou un serveur websocket nécessite donc une offre qui les prend explicitement en charge, et pas nécessairement un VPS.

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

Pour un VPS non administré, oui. Vous devez savoir gérer 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 chaque mois. Si vous ne souhaitez pas vous en charger, une offre managée confie la maintenance convenue 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 d’un hébergement mutualisé à un VPS ?

Réduire le TTL DNS et conserver les deux comptes actifs aide à éviter une indisponibilité, mais ne garantit pas une migration transparente. Définissez le TTL à 300 secondes la veille et attendez l’expiration de l’ancien TTL. Copiez les fichiers et la base de données, testez le nouveau serveur à l’aide du fichier hosts de votre ordinateur portable, puis modifiez l’enregistrement A. Pendant la propagation, certains visiteurs atteignent l’ancien serveur et d’autres le nouveau. Les caches peuvent également mettre plus de cinq minutes à se mettre à jour. Conservez donc le compte mutualisé pendant une semaine. Suspendez les écritures pour le dernier dump et la restauration de la base de données. Conservez l’ancien site en lecture seule ou redirigez ses requêtes vers le nouveau serveur afin de ne pas perdre les écritures ultérieures.