Aller au contenu

VPS ou serveur dédié : où est la limite ?

Cette page est pour vous si votre VPS commence à être juste et que vous vous demandez s’il faut passer au serveur dédié. Elle décrit ce qui est réellement partagé sur un VPS, comment reconnaître une vraie saturation d’un simple problème de réglage, et ce que le dédié apporte — y compris en travail.

La réponse courte : neuf « VPS trop petits » sur dix sont des VPS mal réglés. Le dédié règle un problème de capacité, jamais de code. Mesurez avant de dépenser.

Ce qui est partagé sur un VPS, ce qui ne l’est pas

Section intitulée « Ce qui est partagé sur un VPS, ce qui ne l’est pas »

Un VPS est une machine virtuelle sur un hôte physique partagé avec d’autres clients. L’infrastructure est Proxmox : l’offre VPS Game Ryzen NVMe fonctionne en LXC, l’offre VPS KVM en virtualisation complète KVM.

Ressource Sur un VPS Sur un serveur dédié
vCPU Votre quota est à vous, mais le processeur physique est partagé Tous les cœurs physiques, à vous
RAM Allouée et réservée à votre machine Toute la machine
Disque Un espace NVMe alloué sur la machine hôte Les disques de la machine
IP Une IP dédiée Les IP de la machine
Noyau Celui de l’hôte en LXC ; le vôtre en KVM Le vôtre
Réseau 1 Gb/s annoncé sur les VPS NVMe Selon la configuration commandée
Protection Anti-DDoS CloudFive, permanent Anti-DDoS CloudFive, permanent

Ce qui est à vous est à vous : la RAM allouée ne part pas chez le voisin. Ce qui est partagé, c’est le matériel sous-jacent — surtout la capacité du processeur et les entrées-sorties disque aux heures de forte activité.

Avant de conclure, relevez des chiffres pendant une période de charge réelle — voir Surveiller les ressources.

Ce qui ressemble à une saturation, mais n’en est généralement pas :

  • Un pic de charge pendant une sauvegarde ou une mise à jour. C’est normal : décalez la tâche.
  • Un seul processus à 100 % d’un cœur. C’est un programme mono-thread qui travaille. Ajouter des vCPU n’y changera rien.
  • « La RAM est pleine. » Sous Linux, le système met en cache ce qui reste. Regardez la mémoire disponible et l’usage du swap, pas la mémoire libre.
  • Du lag en jeu alors que le processeur est à 30 %. C’est le tickrate, pas la machine. Voir Latence, ping et tickrate.

Ce qui est une vraie saturation :

  • la charge moyenne reste durablement supérieure au nombre de vCPU, hors pics ;
  • le système swappe en continu et les temps de réponse s’allongent ;
  • l’attente disque est constamment élevée aux heures normales ;
  • le disque est plein et vous supprimez des fichiers chaque semaine pour tenir ;
  • vous êtes déjà sur la plus grande formule et le problème persiste.

Deux offres : Serveur Dédié Ryzen à partir de 125,00 €/mois et Serveur Dédié Intel à partir de 150,00 €/mois. Pour les caractéristiques, reportez-vous aux pages serveur-dedie-ryzen et serveur-dedie-intel, pas à cette page.

Ce que la machine physique change, concrètement :

  • Plus de voisins. La performance ne dépend plus que de vous — surtout sensible sur les charges irrégulières.
  • Toute la capacité d’un coup. Pas de quota à relever : vous arbitrez vous-même entre vos services.
  • La liberté totale sur le système. Noyau, systèmes de fichiers, virtualisation : vous pouvez même découper la machine en machines virtuelles.
  • L’isolation matérielle, parfois exigée par un client ou une contrainte de conformité.

Ce que le dédié ne change pas : un script qui boucle, un plugin mal écrit, une requête SQL sans index. Ces problèmes migrent avec vous, à l’identique.

C’est la partie qu’on sous-estime. Sur un dédié, vous êtes l’administrateur de la machine entière.

  • Tout l’entretien système est à vous : mises à jour, noyau, surveillance, journaux.
  • La sécurité est à vous : pare-feu, durcissement de SSH, gestion des accès — voir Créer et utiliser une clé SSH et Configurer le pare-feu. Les principes sont les mêmes que sur un VPS, la surface exposée est plus grande.
  • Les sauvegardes sont à organiser vous-même, et à tester. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
  • La répartition des ressources est votre problème. Sur un VPS, les quotas vous protégeaient de vous-même ; sur une machine entière, un service emballé peut emporter tout le reste.
  • Une panne matérielle ne se résout pas en trente secondes. Une pièce défectueuse, cela se remplace.

Posez les chiffres, sans deviner.

Gamme VPS Serveur dédié
Entrée de gamme 5,50 €/mois (VPS Start) 125,00 €/mois (Ryzen)
Haut de gamme 40,00 €/mois (VPS Ultra) 150,00 €/mois (Intel)
Engagement Sans engagement Sans engagement
Montée en charge Changement de formule en quelques minutes Vous arbitrez vous-même
Temps d’administration Celui du système Celui du système et celui de la machine

Trois cas de figure en pratique :

  1. Un seul service, saturé. Le palier VPS supérieur, puis le dédié seulement s’il n’y a plus de palier.
  2. Plusieurs VPS additionnés. Si vous en payez déjà trois ou quatre, comparez le total mensuel au prix d’un dédié. Le regroupement est souvent gagnant — si vous acceptez la charge d’administration qui vient avec.
  3. Vous revendez de l’hébergement. Regardez d’abord l’Offre Hébergeur (à partir de 30,00 €/mois) : elle évite de bâtir une infrastructure.

N’oubliez pas le coût caché : votre temps. Une machine dédiée mal entretenue coûte plus cher qu’un VPS correctement réglé, incidents compris.

On ne « transforme » pas un VPS en dédié : ce sont deux services, et la migration est un déménagement. La règle : le nouveau tourne avant que l’ancien s’arrête.

  1. Faites l’inventaire de ce qui tourne sur l’ancienne machine : services, versions, ports, tâches planifiées, certificats, variables d’environnement. Écrivez-le — ce que vous oubliez ici, vous le découvrirez en production.

  2. Prenez un snapshot du VPS et exportez les données, fichiers et bases. Gardez une copie hors du serveur.

  3. Commandez le dédié et préparez-le : système, comptes, clés SSH, pare-feu. Rien d’exposé avant la fin de cette étape.

  4. Installez les services aux mêmes versions que sur l’ancienne machine. Changer de version et de machine à la fois, c’est doubler les causes de panne.

  5. Transférez les données, puis testez par l’adresse IP, sans toucher au DNS : les services démarrent, les journaux sont propres, vous vous connectez.

  6. Abaissez la durée de vie (TTL) de vos enregistrements DNS à quelques minutes, la veille de la bascule. Voir Modifier la zone DNS.

  7. Resynchronisez les données juste avant la bascule, puis pointez le DNS vers la nouvelle IP.

  8. Laissez l’ancienne machine allumée pendant la propagation : les clients qui ont l’ancienne adresse en cache restent servis. C’est ce qui évite la coupure.

  9. Surveillez 48 heures, puis seulement résiliez l’ancien service.

Les performances n’ont pas bougé après la migration. C’était donc un problème logiciel, pas de capacité. Identifiez le processus fautif avec Surveiller les ressources, puis voyez les guides d’optimisation (Minecraft, FiveM, Rust).

Une partie des visiteurs arrive encore sur l’ancienne machine. C’est la propagation DNS. Gardez les deux en service jusqu’à ce que les journaux de l’ancienne soient vides, et vérifiez qu’aucune IP n’est codée en dur dans une configuration.

Un service refuse de démarrer sur la nouvelle machine. Comparez les versions, puis les droits sur les fichiers : après un transfert, c’est la cause la plus fréquente, et un service qui ne peut pas écrire s’arrête sans explication claire.

Vous hésitez encore. Envoyez vos mesures au support — charge moyenne, mémoire disponible, attente disque, services en place — et demandez un avis avant de commander : ouvrir un ticket. Le support répond 7 j/7.