Comment évaluer une offre de VPS bon marché

Ce qu’une offre de VPS bon marché ne précise pas

Lisez une offre de VPS bon marché à l’envers, car le prix est le nombre le moins utile de la page. Ce qui détermine la qualité du serveur est la partie que l’annonce ne détaille pas : le taux de surallocation qui se cache derrière le nombre de vCPU, la clause d’utilisation raisonnable qui se cache derrière le mot « illimité », le prix du renouvellement après la première période, et le fait que les sauvegardes et l’adresse IPv4 soient facturées en supplément. Ce guide examine une annonce ligne par ligne, puis vous donne un test d’acceptation à exécuter sur le serveur tant que vous pouvez encore demander un remboursement.

Cela ne signifie pas qu’un prix bas est nécessairement une arnaque. Du matériel plus ancien, une densité d’hébergement plus élevée, un support en libre-service et une redondance moindre de la plateforme permettent de proposer un prix bas. Vous devez savoir quel compromis vous avez accepté avant que vos utilisateurs ne le découvrent à votre place. Tout ce qui suit s’exécute sur Ubuntu 24.04 avec les paquets disponibles en août 2026.

Un vCPU n’est pas un cœur

Un vCPU est un créneau d’ordonnancement, pas un composant physique. Avec KVM (kernel-based virtual machine), chaque vCPU est un thread sur l’hôte. L’ordonnanceur de l’hôte place ce thread sur un cœur physique lorsque son tour arrive. Un hôte peut vendre quatre vCPU pour un seul cœur physique, et chaque guest affiche malgré tout son nombre complet dans nproc. Le nombre indiqué dans l’offre correspond à un plafond de ressources que vous pouvez demander. Il ne précise pas ce qui vous est réservé.

Le ratio de surallocation indique combien de vCPU un hôte vend par cœur physique. Avec un ratio de 1:1, le cœur vous est réservé. Les offres économiques utilisent des ratios plus élevés, qui sont presque toujours publiés nulle part. Considérez donc toute offre qui ne mentionne pas « dedicated core » ou « dedicated vCPU » comme une offre à ressources partagées. Le partage convient à la plupart des usages, car la plupart des serveurs sont inactifs une grande partie du temps. Il devient problématique lorsque votre période de forte charge coïncide avec celle de tous les autres clients.

Vous pouvez mesurer l’effet depuis le guest. Lorsque votre vCPU est prêt à s’exécuter mais que l’hôte attribue le cœur physique à un autre guest, cette attente est comptabilisée comme du steal time : la colonne st dans vmstat et %st dans top. Le steal time montre dans vos propres métriques l’activité d’un voisin bruyant, et c’est la valeur la plus utile de ce guide, car une offre commerciale ne peut pas la falsifier.

Un cœur dédié reste partagé de certaines autres façons. La bande passante mémoire, le last level cache et le chemin de stockage sont communs à tout l’hôte. « Dedicated vCPU » supprime la principale source de variation. Cela ne supprime pas toutes les variations.

Vérifiez également le modèle de CPU avec lscpu. Deux offres peuvent toutes deux indiquer « 4 vCPU », alors que leurs performances en single-thread diffèrent d’un facteur deux, parce que l’un des hôtes utilise une génération de CPU beaucoup plus ancienne. Du matériel ancien à bas prix peut convenir à un build agent, mais il convient mal à une page de paiement.

"Bande passante illimitée" désigne au moins quatre produits différents

Le trafic est décrit de quatre façons, qui ne sont pas interchangeables.

• Un quota mesuré. L’offre indique un volume, par exemple « 2 TB par mois ». Ce qui compte, c’est ce qui se passe ensuite : des frais supplémentaires par TB excédentaire, ou une réduction à un débit très faible jusqu’au début du mois suivant. Vérifiez ce point avant d’en avoir besoin.
• Une offre non mesurée avec une clause d’usage raisonnable. Le trafic n’est pas comptabilisé, et la politique d’usage acceptable fixe la limite avec des mots plutôt qu’avec des chiffres. Recherchez « fair use », « sustained », « excessive » et « abuse » dans ce document.
• Un plafond de débit du port. Un port à 100 Mbit/s vous limite physiquement, quelle que soit la politique de trafic.
• Une combinaison des deux derniers cas : trafic non mesuré sur un port lent. C’est la formule la plus courante des offres bon marché. Elle reste honnête si vous lisez le débit du port.

[
  {
    "label": "100 Mbit/s",
    "tb_ceiling_30d": 32,
    "hours_per_tb": 22.2
  },
  {
    "label": "200 Mbit/s",
    "tb_ceiling_30d": 65,
    "hours_per_tb": 11.1
  },
  {
    "label": "500 Mbit/s",
    "tb_ceiling_30d": 162,
    "hours_per_tb": 4.4
  },
  {
    "label": "1 Gbit/s",
    "tb_ceiling_30d": 324,
    "hours_per_tb": 2.2
  }
]

Le débit du port constitue un plafond strict, et le calcul est simple. 100 Mbit/s correspondent à 12.5 megabytes par seconde. Sur 30 jours, ce débit à pleine vitesse permet donc de transférer environ 32 TB. Sur la même durée avec un port à 1 Gbit/s, le volume atteint 324 TB. Ici, TB signifie 10^12 bytes, l’unité utilisée pour la facturation par les hébergeurs. Il s’agit d’un calcul, pas d’une mesure. Aucun serveur réel n’utilise son port à plein débit pendant un mois entier.

C’est la deuxième colonne qui différencie les offres. Le transfert d’un seul terabyte prend environ 22.2 heures avec le port à 100 Mbit/s, et 2.2 heures avec le port gigabit. Si votre plan de reprise consiste à « télécharger la sauvegarde et redémarrer », cette durée correspond à votre temps de reprise.

Deux autres détails se cachent dans cette ligne de la fiche technique. « 1 Gbit/s shared » signifie que le port est partagé avec d’autres clients. Le plafond indiqué plus haut correspond donc au meilleur cas, et non à une garantie. Certains hébergeurs facturent également le trafic selon le 95e percentile du débit échantillonné, plutôt que selon le volume total. Cette méthode facture moins cher une charge régulière qu’une charge en pics.

Quelle que soit l’offre, mesurez votre propre usage. vnstat lit les compteurs de l’interface et conserve un historique.

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -d
vnstat -m

Juste après l’installation, vnstat affiche Not enough data available yet., car sa base de données ne contient encore aucun échantillon. Revenez le lendemain : vnstat -m vous donnera un total mensuel à comparer au quota que vous payez.

La promesse du NVMe est-elle réelle, et comment la vérifier ?

lsblk -d -o NAME,ROTA,SIZE,MODEL

ROTA égal à 0 signifie que le guest a été informé que le périphérique n’est pas rotatif. Cette valeur vient de l’hyperviseur. Elle décrit donc ce que l’hôte annonce, et non le support sous-jacent. La colonne MODEL est généralement vide pour un disque virtio comme /dev/vda, et affiche un QEMU HARDDISK générique pour un disque attaché en SCSI. Vous examinez un disque virtuel. Son libellé ne prouve donc rien.

La propriété à vérifier est la latence. La vraie différence se situe entre un NVMe local et un volume attaché au réseau. Un volume réseau peut afficher un débit séquentiel élevé tout en restant lent en pratique. Le débit est mesuré avec de nombreuses requêtes simultanées, tandis qu’une base de données attend une petite écriture à la fois. Mesurez la latence avec une profondeur de file d’attente de 1, puis utilisez une file plus profonde pour mesurer les IOPS (opérations d’entrée/sortie par seconde).

sudo apt install -y fio
fio --name=lat --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=1 --numjobs=1 --runtime=60 --time_based --group_reporting
fio --name=iops --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
rm -f fiotest

Lisez le bloc clat percentiles, et plus précisément la ligne du 99.00e percentile. Il s’agit de la latence d’achèvement observée par le pour cent de requêtes le plus lent. C’est elle que l’utilisateur ressent comme un blocage. À titre indicatif, un NVMe local répond en quelques centaines de microsecondes avec une profondeur de file d’attente de 1, tandis qu’un volume attaché au réseau répond en millisecondes. Comparez vos deux propres mesures au lieu de vous fier à une seule valeur publiée. Exécutez la paire trois fois dans la journée, car un disque partagé avec d’autres tenants ne se comporte pas de la même manière à 03:00 et à 20:00.

fio écrit d’abord le fichier de 1 GB sur le disque. Prévoyez donc suffisamment d’espace et n’oubliez pas que le test consomme le quota d’IOPS prévu par le plan. Si vous voulez seulement une mesure rapide, ioping -c 20 . affiche la latence sur une seule ligne. Un benchmark n’a de valeur que si vous pouvez le reproduire, enregistrez donc les lignes de commande exactes et la sortie avec la date.

Ce qui est inclus et ce qui est facturé en supplément

• IPv4. Une adresse est normalement incluse. Certaines offres bon marché vous attribuent une adresse partagée derrière un NAT (network address translation), avec quelques ports redirigés. Vous ne pouvez donc pas exécuter votre propre service sur le port 443. Vérifiez avec ip -4 addr show scope global et curl -4 https://icanhazip.com. Deux réponses différentes indiquent que vous êtes derrière un NAT.
• IPv6. Un /64 routé vous fournit des adresses pour les conteneurs et pour tout service que vous souhaitez rendre accessible depuis l’extérieur. Un seul /128 couvre le trafic sortant et presque rien d’autre.
• Sauvegardes. Les sauvegardes automatiques sont généralement proposées en option payante. Les snapshots sont souvent gratuits, mais un snapshot se trouve sur la même infrastructure que le disque copié. Il vous protège donc de vos propres erreurs, pas de la perte de l’hôte. Quelle que soit l’offre, conservez une copie hors du serveur.
• Protection contre les attaques DDoS. De nombreux hébergeurs répondent à une attaque volumétrique (distributed denial of service) en appliquant un null route à votre adresse IP pendant une durée déterminée. Le serveur reste fonctionnel. Il est simplement inaccessible depuis Internet. Demandez le seuil de déclenchement et la durée d’application du null route.
• Niveau de support. Avec une offre unmanaged, vous êtes l’administrateur système, et la responsabilité de l’hébergeur s’arrête à l’hyperviseur et au réseau. C’est la principale différence de coût réelle entre deux offres aux spécifications identiques.
• Licences et panels. Un control panel, un système d’exploitation commercial ou une option de messagerie peuvent coûter chaque mois plus cher que le serveur lui-même.

Quel type de virtualisation achetez-vous ?

systemd-detect-virt

kvm ou qemu désigne une virtualisation complète : vous disposez de votre propre noyau et choisissez les modules à charger. lxc, lxc-libvirt ou openvz désigne un conteneur qui partage le noyau de l’hôte. none désigne un serveur bare metal.

La différence est importante avec un noyau partagé. sudo modprobe wireguard échoue et ip link add dev wg0 type wireguard renvoie RTNETLINK answers: Operation not supported, car un conteneur ne peut pas charger un module de noyau que l’hôte n’a pas chargé. free -h peut indiquer la mémoire de l’hôte au lieu de la vôtre si lxcfs est absent. Votre supervision lit alors des valeurs qui ne correspondent pas à votre serveur. Le swap est souvent partagé avec d’autres conteneurs, et exécuter des machines virtuelles dans votre VPS est totalement impossible. Les offres en conteneur sont moins chères pour une raison précise. Elles restent adaptées à un site statique ou à une petite application.

Quel est le prix du renouvellement ?

Le prix annoncé couvre souvent uniquement la première période d’abonnement. Recherchez la mention « renews at » sur la page de commande, ainsi que la durée de l’abonnement à laquelle s’applique la remise. Une remise valable un an et une remise valable pendant toute la durée du plan correspondent à des offres différentes, même si elles produisent le même montant sur la première facture.

Lisez aussi les conditions de remboursement avec la même attention. Vérifiez la durée de la période de remboursement, son point de départ — à la commande ou à la mise à disposition du service —, la possibilité de rembourser les options telles que les adresses IP supplémentaires, et le remboursement au prorata d’un prépaiement annuel. Ajoutez ensuite un rappel dans votre calendrier une semaine avant la date de renouvellement : le moment le moins coûteux pour partir est avant l’émission de la facture.

Changer de fournisseur plus tard n’est pas gratuit non plus. Transférer quelques centaines de gigaoctets de données, recréer la configuration, attendre l’expiration des valeurs TTL du DNS (domain name system) et, pour un serveur de messagerie, reconstruire la réputation de l’adresse IP peuvent occuper tout un week-end. Tenez compte de ce week-end lorsqu’une économie semble intéressante. Ce que coûte réellement un VPS sur un an est le montant à comparer, et non celui du premier mois.

Le test d’acceptation en trente minutes

Exécutez ce test sur le nouveau serveur avant toute migration, tant que la période de remboursement est encore ouverte. Sécurisez-le d’abord : les dix premières minutes sur un nouveau VPS couvrent le compte utilisateur, les clés et le firewall. Installez ensuite les outils.

sudo apt update
sudo apt install -y sysbench fio ioping sysstat stress-ng vnstat mtr-tiny curl

Vérification 1 : qu’est-ce qui m’a réellement été fourni ?

systemd-detect-virt
nproc
lscpu | grep -E 'Model name|MHz|Hypervisor'
free -h
lsblk -d -o NAME,ROTA,SIZE,MODEL
ip -4 addr show scope global
curl -4 -s https://icanhazip.com

Vous devez voir le type de virtualisation, un modèle de CPU et une quantité de mémoire à quelques pour cent près de ce que vous avez acheté. free -h qui indique beaucoup plus de RAM que ce que le forfait inclut signifie généralement que vous êtes dans un conteneur sans lxcfs, et non que vous bénéficiez d’un supplément. Une adresse publique fournie par curl qui n’apparaît jamais dans ip -4 addr signifie que l’adresse IPv4 est partagée.

Vérification 2 : quelle est la vitesse d’un thread et quel est le niveau de steal en charge ?

sysbench cpu --cpu-max-prime=20000 --threads=1 run

Relevez la ligne events per second. La vitesse sur un seul thread détermine le temps de rendu d’une page et la durée d’un build. C’est aussi la valeur qui différencie le plus les forfaits bon marché. Chargez maintenant tous les vCPU et observez ce que le scheduler vous attribue réellement.

stress-ng --cpu 0 --timeout 300s &
vmstat 1 30
mpstat -P ALL 1 10

--cpu 0 démarre un worker par CPU en ligne. Surveillez la colonne st dans vmstat et %steal dans mpstat. Des valeurs à un chiffre occasionnelles sur un forfait partagé sont normales. Une valeur de steal à deux chiffres pendant plusieurs minutes signifie que les cœurs physiques sont suralloués. Votre travail attend donc derrière celui d’un autre tenant. Exécutez de nouveau sysbench pendant que la charge est active : un score single-thread qui s’effondre signifie que vos vCPU se disputent les ressources, ce qui indique généralement qu’ils correspondent à des threads frères sur un même cœur plutôt qu’à des cœurs distincts. L’autre possibilité est un score faible avec un steal presque nul : l’hôte applique une limite CPU que vous ne pouvez pas observer directement depuis le guest.

Vérification 3 : comment le disque se comporte-t-il avec une profondeur de file de 1 ?

Exécutez les deux commandes fio de la section NVMe et conservez les deux résultats : la latence au 99e percentile avec une profondeur de file de 1, et les IOPS avec une profondeur de 32. Testez ensuite les écritures, car de nombreux volumes sont beaucoup plus lents dans ce sens.

fio --name=wlat --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --runtime=30 --time_based --group_reporting
rm -f fiotest

Une valeur séquentielle dd est celle que les offres aiment mettre en avant, mais c’est la moins utile que vous puissiez mesurer. Le streaming séquentiel ne correspond pas à l’activité quotidienne d’une base de données ou d’une application web sollicitée. Relevez-la si vous souhaitez comparer les offres. Fondez votre décision sur la latence.

Vérification 4 : à quoi ressemble le réseau depuis l’emplacement de vos utilisateurs ?

Commencez par télécharger un fichier volumineux vers le VPS.

curl -o /dev/null -w 'in: %{speed_download} bytes/s\n' https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

Cela teste un seul chemin vers votre serveur, et rien d’autre. La direction importante est celle qu’empruntent vos utilisateurs. Servez donc un fichier et téléchargez-le depuis une machine située près d’eux.

fallocate -l 100M /var/tmp/100mb.bin
python3 -m http.server 8080 --directory /var/tmp

Ensuite, depuis un laptop ou un serveur proche de votre audience :

curl -o /dev/null -w 'down: %{speed_download} bytes/s\n' http://YOUR_SERVER_IP:8080/100mb.bin
mtr --report --report-cycles 50 YOUR_SERVER_IP

Le port 8080 doit être ouvert dans le firewall pendant ce test. Fermez-le ensuite, supprimez le fichier et arrêtez le serveur Python avec Ctrl+C. Dans la sortie de mtr, lisez la colonne de perte sur la dernière ligne. Une perte sur un routeur intermédiaire, sans perte à destination, est normale : les routeurs traitent les réponses ICMP (internet control message protocol) comptabilisées par mtr avec une faible priorité. Il ne s’agit pas d’une perte sur votre trafic. Une perte sur la dernière ligne est réelle.

Répétez le test réseau pendant l’heure de pointe de vos utilisateurs. Un seul échantillon pris à 02:00 vous renseigne sur un réseau peu sollicité.

Enregistrez les quatre résultats dans un fichier avec la date, puis répétez les tests dans un mois. Un forfait correct le premier jour mais lent à la sixième semaine indique que l’hôte s’est rempli. Les mesures du premier jour permettent de le savoir au lieu de le supposer.

Quand un VPS bon marché est le bon choix

Un prix bas correspond à des caractéristiques concrètes et implique aussi des compromis réels. Des CPU plus anciens, un ratio d’overselling plus élevé, un stockage réseau plus lent, un support en libre-service et une redondance plus limitée expliquent ce tarif. Adaptez ces compromis à l’usage prévu.

Une offre bon marché convient pour un environnement de développement, un runner CI, un endpoint VPN, un nœud de supervision, une cible de sauvegarde ou un site statique. Ces usages supportent tous une minute de ralentissement. Une offre bon marché est un mauvais choix lorsque la latence constitue le produit : page de paiement, API interactive, serveur de jeu ou base de données dont dépend un autre service. Le test ci-dessus vous indique ce que vous avez acheté, et vous le saurez alors que la réponse ne vous coûte encore rien.

FAQ

Que signifie vCPU dans une offre de VPS bon marché ?

Un vCPU est un processeur virtuel présenté à votre machine invitée. Il correspond à un thread que le scheduler de l’hôte exécute, si possible, sur un cœur physique. Il s’agit d’un droit à demander du temps CPU, et non de matériel réservé, sauf si l’offre mentionne « dedicated core » ou « dedicated vCPU ». Les hébergeurs vendent plus de vCPU qu’ils n’ont de cœurs. Ce ratio est rarement publié, donc mesurez-le. Exécutez stress-ng --cpu 0 --timeout 300s et surveillez la colonne st dans vmstat 1. Une valeur de steal à deux chiffres signifie que vous attendez des cœurs utilisés par d’autres machines invitées.

« Unlimited bandwidth » signifie-t-il vraiment illimité ?

Non. La limite se trouve généralement à deux endroits qui ne figurent pas dans la description de l’offre. La politique d’utilisation acceptable définit une limite de fair use en toutes lettres, et le débit du port fixe un plafond strict en octets. Un port à 100 Mbit/s ne peut pas transférer plus d’environ 32 TB en 30 jours, même à plein débit. Demandez donc le débit du port et cherchez les termes « fair use » et « sustained » dans la politique. Suivez ensuite le volume que vous envoyez réellement avec vnstat -m et comparez-le à la limite incluse.

Comment vérifier que mon VPS utilise réellement du NVMe ?

Vous ne pouvez pas confirmer le support physique depuis une machine invitée, car lsblk indique uniquement ce que l’hyperviseur annonce : ROTA de 0 et une chaîne de modèle vide ou générique. Vous pouvez en revanche mesurer le comportement. Exécutez fio avec --direct=1 à --iodepth=1 et consultez la latence d’achèvement au 99.00e percentile. Un NVMe local répond en quelques centaines de microsecondes. Un volume attaché au réseau répond en millisecondes, même lorsque son débit séquentiel semble impressionnant. Répétez le test plusieurs fois dans la journée, car les performances d’un disque partagé ne sont pas les mêmes à 03:00 et à 20:00.

Que dois-je tester avant la fin de la période de remboursement ?

Quatre éléments, dans cet ordre. La nature réelle de la machine, avec systemd-detect-virt, lscpu et free -h. Les performances single-thread, avec sysbench cpu --cpu-max-prime=20000 --threads=1 run. Le temps de steal sous une charge complète, avec stress-ng --cpu 0 surveillé par vmstat 1. La latence du disque, avec fio et une profondeur de file d’attente de 1. Mesurez ensuite le réseau depuis une machine située près de vos utilisateurs, avec mtr et le téléchargement d’un fichier servi depuis la machine. Trente minutes suffisent pour tout vérifier. Effectuez ces tests avant toute migration afin de conserver la période de remboursement comme moyen de pression.