Comment choisir un VPS en 2026 : la checklist avant de louer

Choisir un VPS en 2026 ne consiste plus à comparer seulement un prix mensuel, une quantité de RAM et un nombre de vCPU. Les offres se sont densifiées, les gammes se sont spécialisées, et les écarts de qualité se jouent souvent sur des critères qui n’apparaissent pas en gros sur la fiche produit : type de virtualisation, niveau réel d’isolation, comportement du stockage sous charge, politique de snapshots, facilité de restauration, garanties de disponibilité, qualité du support et conditions de sortie. Chez plusieurs fournisseurs documentés, les fonctions de sauvegarde, de pare-feu réseau, de console de secours et de restauration existent bel et bien, mais elles obéissent à des règles, des limites et parfois des coûts distincts qu’il faut vérifier avant achat. ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/virtualization_getting_started_guide/index?utm_source=openai))

La bonne méthode consiste donc à transformer l’achat d’un VPS en audit rapide. L’objectif n’est pas de trouver “le moins cher”, mais de louer une machine virtuelle dont le niveau de performance, de contrôle et de réversibilité correspond au risque réel de votre projet. Un site vitrine, un VPN d’entreprise, un SaaS, un serveur de CI, un environnement de préproduction ou une base de données n’ont ni les mêmes besoins ni la même tolérance à l’oversubscription. Cette checklist pas à pas vous aide à lire une offre comme un exploitant, pas comme un simple acheteur.

1. Commencer par le socle : quel type de virtualisation est utilisé ?

Premier filtre : identifier la technologie de virtualisation. Ce point conditionne l’isolation, la compatibilité logicielle, le comportement du noyau et la liberté d’administration. Red Hat documente KVM comme une solution de virtualisation complète capable d’exécuter plusieurs systèmes invités, chaque machine virtuelle disposant de son propre noyau invité. À l’inverse, la documentation OpenVZ décrit l’OS virtualization comme une virtualisation au niveau du noyau : les conteneurs partagent le noyau de l’hôte, même s’ils apparaissent comme des systèmes indépendants. ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/virtualization_getting_started_guide/index?utm_source=openai))

Concrètement, pour un acheteur de VPS, cela change beaucoup de choses :

KVM ou équivalent de virtualisation complète : meilleur choix si vous voulez un noyau indépendant, davantage de compatibilité, des modules spécifiques, un cloisonnement plus proche d’une VM classique et une meilleure prévisibilité pour les usages avancés.
Virtualisation de type conteneur : peut offrir une excellente densité et de très bonnes performances, mais avec davantage de dépendance au noyau de l’hôte et parfois des limitations sur certains usages système. OpenVZ met précisément en avant la densité, l’efficacité et l’utilisation d’un noyau unique partagé. ([docs.openvz.org](https://docs.openvz.org/openvz_users_guide.webhelp/_basics_of_os_virtualization.html?utm_source=openai))

La question à poser au fournisseur est simple : ai-je une vraie VM avec son propre noyau, ou un conteneur virtualisé au niveau OS ? Si la fiche reste vague, c’est déjà un signal. Pour un usage professionnel polyvalent en 2026, KVM reste généralement le point de départ le plus rassurant lorsque vous avez besoin de contrôle système profond.

2. Vérifier le CPU : vCPU partagés, dédiés, et risque d’oversubscription

Le nombre de vCPU indiqué sur une fiche n’explique pas à lui seul le niveau de performance attendu. La vraie question est de savoir si ces ressources sont partagées, garanties ou simplement burstables selon la charge du nœud hôte. Les grands fournisseurs cloud documentent explicitement l’existence d’infrastructures mutualisées par défaut ; par exemple AWS précise que les instances EC2 fonctionnent par défaut sur du matériel en tenancy partagée, tandis que les Dedicated Instances reposent sur un matériel dédié à un seul compte. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html?utm_source=openai))

Pour un VPS classique, cela signifie qu’un “2 vCPU” peut recouvrir plusieurs réalités :

des cœurs virtuels partagés avec d’autres clients ;
des ressources avec priorité standard, sans garantie forte en pic ;
des ressources plus prévisibles sur une gamme “compute” ou “dedicated CPU” ;
une politique de surallocation que le fournisseur ne détaille pas.

Dans la pratique, vous devez demander ou rechercher :

la nature du CPU : partagé ou dédié ;
la fréquence ou la génération de processeur si elle est publiée ;
l’existence d’un fair use ou d’un crédit CPU ;
des benchmarks reproductibles ou au minimum des garanties de gamme.

Pour un site de production, un nœud de base de données, une stack de build ou une application avec pics de charge, un CPU partagé très bon marché peut devenir plus coûteux qu’un VPS un peu plus cher mais stable. Si vous hébergez un service sensible à la latence, la régularité compte plus que le chiffre brut de vCPU.

3. Ne pas se contenter de la mention “NVMe” : lire le stockage correctement

En 2026, la mention “SSD NVMe” ne suffit plus à qualifier une offre. Les documentations d’AWS, Google Cloud et Microsoft rappellent toutes que la performance disque se mesure en IOPS, en débit et selon le type de disque, l’interface et la taille provisionnée ; Microsoft souligne que NVMe peut offrir davantage d’IOPS et de débit, mais que le résultat dépend aussi du type et de la taille de VM ainsi que de la taille de bloc utilisée. Google détaille de son côté des plafonds et méthodes de benchmark, et distingue bien différents types de stockage dont les performances évoluent selon la classe retenue. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/virtual-machines/nvme-overview?utm_source=openai))

Autrement dit, un VPS “NVMe” peut être rapide sur le papier mais décevant en usage réel si :

le stockage est très mutualisé ;
le fournisseur ne donne ni IOPS ni débit ;
la performance chute fortement sous contention ;
les snapshots ou backups dégradent les écritures ;
la capacité minimale annoncée masque une faible endurance ou une QoS limitée.

Checklist stockage avant achat :

Le fournisseur publie-t-il des IOPS ou un débit garantis ?
S’agit-il d’un disque local éphémère, d’un bloc réseau, ou d’un stockage persistant ? Google rappelle par exemple que le Local SSD est un stockage temporaire. ([docs.cloud.google.com](https://docs.cloud.google.com/compute/docs/disks?hl=en&utm_source=openai))
Les snapshots sont-ils possibles sans arrêter la VM, et avec quelles précautions de cohérence ?
Le fournisseur recommande-t-il l’arrêt pour garantir la cohérence ? Hetzner le recommande explicitement lors de la création de backups ou snapshots. ([docs.hetzner.com](https://docs.hetzner.com/cloud/servers/backups-snapshots/faq/?utm_source=openai))

Si la charge est orientée base de données, logs, indexation ou CI, le couple IOPS + constance sous charge est plus important que la simple présence du mot NVMe.

4. Snapshots : très utiles, mais à ne jamais confondre avec une vraie stratégie de sauvegarde

Presque tous les acheteurs surestiment les snapshots. Les documentations officielles sont pourtant claires : un snapshot est une image disque à un instant donné, pratique pour revenir en arrière, cloner ou migrer, mais ce n’est pas nécessairement une sauvegarde complète répondant à un objectif de reprise métier. DigitalOcean définit les snapshots comme des images disque à la demande ; Hetzner explique que backups et snapshots sont des copies du disque serveur, avec des comportements distincts ; et sa documentation sur Storage Box précise même qu’un snapshot n’est pas un full backup. ([docs.digitalocean.com](https://docs.digitalocean.com/products/snapshots/details/?utm_source=openai))

Exemples concrets vérifiés :

DigitalOcean : les snapshots sont conservés jusqu’à suppression manuelle ; les backups automatiques suivent une politique de rétention distincte. Les sauvegardes peuvent être quotidiennes, hebdomadaires ou à intervalles de 4, 6 ou 12 heures selon l’option activée. ([docs.digitalocean.com](https://docs.digitalocean.com/products/backups/?utm_source=openai))
Hetzner Cloud : les backups sont quotidiens avec sept emplacements ; les snapshots restent disponibles même si le serveur d’origine est supprimé. ([docs.hetzner.com](https://docs.hetzner.com/cloud/servers/backups-snapshots/faq/?utm_source=openai))
OVHcloud : la documentation VPS détaille l’usage des snapshots et la FAQ précise qu’un snapshot de VPS peut être téléchargé. ([docs.ovhcloud.com](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/using-snapshots-on-a-vps?utm_source=openai))

La bonne question n’est donc pas “y a-t-il des snapshots ?”, mais :

Quelle est la fréquence possible ?
Quelle est la rétention ?
Les données sont-elles exportables ?
La restauration remplace-t-elle tout le disque ?
Les volumes additionnels sont-ils inclus ? Hetzner précise que backups et snapshots n’incluent pas les volumes attachés. ([docs.hetzner.com](https://docs.hetzner.com/cloud/servers/backups-snapshots/faq/?utm_source=openai))

Pour un usage pro, il faut au minimum une stratégie en trois couches : snapshot technique, sauvegarde automatisée, et export hors fournisseur.

5. Sécurité minimale attendue : pare-feu, isolation réseau, accès de secours

Un VPS sérieux doit vous permettre de réduire la surface d’exposition dès la mise en service. DigitalOcean documente un pare-feu réseau stateful sans coût additionnel pour les Droplets, bloquant tout trafic non explicitement autorisé. AWS rappelle de son côté qu’un security group agit comme un pare-feu virtuel autour d’une instance EC2. OVHcloud mentionne dans sa FAQ VPS l’existence d’un Edge Network Firewall intégré à son infrastructure Anti-DDoS pour certains services, tout en précisant que les Local Zone VPS n’incluent pas certaines fonctions de sécurité comme l’Anti-DDoS. ([docs.digitalocean.com](https://docs.digitalocean.com/products/networking/firewalls/?utm_source=openai))

Avant de louer, vérifiez :

pare-feu réseau natif ou seulement firewall logiciel dans l’OS ;
protection DDoS incluse ou optionnelle ;
console hors bande ou VNC/KVM web ;
mode rescue pour réparer un système cassé ;
journalisation et API pour automatiser les règles.

Le mode rescue est particulièrement important. OVHcloud le présente comme un système temporaire permettant notamment de réinitialiser un mot de passe, diagnostiquer le réseau, réparer l’OS, corriger un pare-feu mal configuré ou tester les performances disque. Hetzner fournit aussi un rescue mode avec mot de passe root affiché dans la console et une procédure de réinitialisation du mot de passe root. ([docs.ovhcloud.com](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/rescue?utm_source=openai))

Un VPS sans console de secours ni rescue simple à activer augmente fortement votre temps d’indisponibilité en cas d’erreur d’administration.

6. Accès root, liberté d’administration et limites cachées

Dans l’univers VPS, “accès root” doit être vérifié, pas supposé. Il faut confirmer que vous pouvez administrer l’OS, modifier la configuration réseau et système, réinitialiser l’accès, monter un volume de récupération et piloter la machine via console si SSH tombe. Les documentations OVHcloud et Hetzner sur le rescue mode montrent justement que ce niveau de contrôle existe sur leurs offres concernées. ([docs.ovhcloud.com](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/rescue?utm_source=openai))

Points à contrôler avant achat :

accès root réel ou compte administrateur limité ;
images personnalisées autorisées ou non ;
possibilité de changer le noyau selon la techno de virtualisation ;
console web disponible si SSH ne répond plus ;
reverse DNS configurable ; Hetzner expose un réglage Cloud Server rDNS dans sa documentation, et DigitalOcean rappelle ce qu’est un enregistrement PTR/rDNS. ([docs.hetzner.com](https://docs.hetzner.com/cloud/servers/?utm_source=openai))

Pour l’envoi d’e-mails transactionnels, l’hébergement d’un VPN, la supervision ou certains usages B2B, le rDNS et la liberté réseau ne sont pas des détails. Leur absence peut bloquer un projet pourtant “fonctionnel” sur le plan technique.

7. Localisation des données : latence, conformité et souveraineté

La localisation n’est pas qu’un sujet juridique ; c’est aussi un paramètre de performance. Plus l’infrastructure est proche des utilisateurs ou des autres briques de votre SI, plus la latence peut baisser. OVHcloud met en avant cet effet pour ses Local Zone VPS, conçus pour rapprocher les applications des utilisateurs et réduire les temps d’accès. ([docs.ovhcloud.com](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/vps-faq?utm_source=openai))

Sur le plan conformité, la Commission européenne rappelle que la protection du RGPD continue de s’appliquer aux données personnelles, y compris en cas de transfert vers un pays tiers, avec des mécanismes d’encadrement spécifiques. Cela signifie qu’un choix de région ou de pays d’hébergement doit être aligné avec vos obligations contractuelles et réglementaires, surtout si vous traitez des données personnelles européennes. ([commission.europa.eu](https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/what-rules-apply-if-my-organisation-transfers-data-outside-eu_en?utm_source=openai))

Checklist localisation :

où est hébergée la VM ?
où sont stockés snapshots et backups ?
la région est-elle fixe ou susceptible d’évoluer ?
les données sortent-elles de la juridiction visée en cas de sauvegarde, réplication ou support ?

En clair : si votre trafic est français ou européen et que votre contrat impose une certaine résidence des données, la localisation doit être documentée noir sur blanc avant signature.

8. Sauvegardes : fréquence, rétention, cohérence et restauration testable

Une offre VPS acceptable en production doit détailler son modèle de sauvegarde. DigitalOcean documente des backups systèmes automatisés avec différents intervalles et une rétention variable selon le type de plan ; Hetzner décrit des sauvegardes quotidiennes avec sept emplacements ; OVHcloud documente les snapshots VPS et l’accès à un stockage de sauvegarde dans certains cas selon sa FAQ. ([docs.digitalocean.com](https://docs.digitalocean.com/products/backups/?utm_source=openai))

Mais le vrai critère n’est pas seulement la présence d’une sauvegarde : c’est la restaurabilité. Avant achat, vous devez savoir :

combien de points de restauration existent ;
si la sauvegarde couvre uniquement le disque système ou aussi les volumes annexes ;
si la restauration peut être faite sur une nouvelle instance ;
si vous pouvez exporter vos données hors plateforme ;
si le fournisseur recommande d’éteindre la VM pour une cohérence applicative correcte.

Sans test de restauration, une sauvegarde n’est qu’une promesse. Une bonne pratique consiste à exiger qu’au moins un restore complet puisse être réalisé sur une instance de test avant la mise en production.

9. Support et SLA : lire au-delà du slogan commercial

Le support fait partie du produit. DigitalOcean affiche pour ses CPU Droplets un SLA d’uptime de 99,99% par instance, mis à jour le 3 juin 2025, tandis que sa grille de support indique un plan inclus avec réponse inférieure à 24 heures, puis des plans payants avec objectifs plus courts. Hetzner documente un SLA de 99,9% mensuel pour chaque Cloud Server. OVHcloud précise dans sa FAQ qu’un VPS inclut un SLA de 99,9%. ([digitalocean.com](https://www.digitalocean.com/sla/cpu-droplets?utm_source=openai))

Attention toutefois : un SLA d’uptime n’est pas une promesse de dépannage applicatif. Il définit surtout une disponibilité contractuelle et, en cas d’écart, un mécanisme de crédit. Pour bien comparer deux offres, il faut distinguer :

SLA d’infrastructure : disponibilité mensuelle garantie ;
canaux de support : ticket, email, chat, téléphone, Slack dédié ;
temps de première réponse ;
niveau d’accompagnement : purement infrastructure ou assistance plus avancée.

Un VPS low-cost sans support réactif peut être correct pour un labo, mais dangereux pour un service business. Si votre activité perd de l’argent à chaque heure d’arrêt, le coût du support doit entrer dans la comparaison.

10. Réversibilité : pouvez-vous partir sans douleur ?

La réversibilité est souvent oubliée lors de l’achat alors qu’elle devient cruciale au premier incident, au premier changement de prix ou à la première limite technique. Un bon VPS doit permettre de récupérer les données, exporter les sauvegardes ou au moins reconstruire l’environnement rapidement ailleurs. OVHcloud indique qu’un snapshot de VPS peut être téléchargé selon sa FAQ, tandis que DigitalOcean explique comment utiliser snapshots et backups pour restaurer ou recréer des Droplets, et comment migrer de région via snapshot. ([docs.ovhcloud.com](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/vps-faq?utm_source=openai))

Questions à poser :

puis-je télécharger un snapshot ou une image ?
puis-je cloner la VM vers une autre région ou un autre compte ?
les backups survivent-ils à la suppression du serveur ? Chez Hetzner, les backups sont liés au serveur alors que les snapshots persistent ; chez DigitalOcean, les snapshots restent jusqu’à suppression. ([docs.hetzner.com](https://docs.hetzner.com/cloud/servers/backups-snapshots/faq/?utm_source=openai))

Une offre peu chère mais fermée sur ses outils de backup et d’image peut créer un vrai verrouillage.

11. Les pièges fréquents des offres low-cost

Les offres très bon marché ne sont pas forcément mauvaises, mais elles exigent une lecture plus rigoureuse. Les pièges les plus fréquents sont les suivants :

CPU trop mutualisé : fiche séduisante, performances irrégulières.
stockage “NVMe” sans métriques : aucune donnée sur IOPS, débit, contention ou constance.
snapshots vendus comme sauvegarde : pratique pour rollback, insuffisant pour PRA.
pas de rescue ni console : une erreur SSH ou firewall vous coupe totalement de la machine.
support minimal : réponse lente, utile seulement pour la facturation.
région unique : pas de proximité utilisateur ni de plan de bascule simple.
options importantes payantes : backups, IP additionnelle, firewall avancé, support prioritaire.
fiches floues : absence de techno de virtualisation, de SLA précis, ou de politique de rétention.

Le point commun de ces pièges est toujours le même : la brochure montre le prix d’entrée, pas le coût opérationnel du risque.

12. Mini-méthode pour comparer deux fiches techniques

Pour départager deux VPS, appliquez une grille simple sur 10 critères, notés de 0 à 2.

Virtualisation : 0 si floue, 1 si acceptable, 2 si KVM ou équivalent clairement documenté.
CPU : 0 si aucune précision, 1 si partagé assumé, 2 si gamme plus prévisible ou dédiée.
Stockage : 0 si “SSD/NVMe” sans données, 1 si type clair, 2 si IOPS/débit/règles explicités.
Snapshots : 0 absents, 1 présents, 2 avec restauration et conservation claires.
Sauvegardes : 0 absentes, 1 optionnelles, 2 avec fréquence et rétention documentées.
Sécurité réseau : 0 basique, 1 firewall logiciel seulement, 2 firewall réseau natif et accès rescue.
Accès admin : 0 limité, 1 root standard, 2 root plus console plus rDNS.
Localisation : 0 floue, 1 région annoncée, 2 région plus implications de sauvegarde claires.
Support : 0 lent ou flou, 1 correct, 2 délais et canaux documentés.
Réversibilité : 0 verrouillée, 1 migration partielle, 2 export ou clone bien documenté.

Ensuite, ne comparez pas seulement le total. Regardez surtout les zéros. Une note faible sur la sauvegarde, le rescue ou la réversibilité pèse souvent plus lourd qu’un petit écart de prix mensuel.

13. Checklist finale, facile à scanner

Checklist VPS 2026 avant location

Virtualisation

Le fournisseur indique clairement KVM, Xen, VMware ou conteneur ?

Ai-je besoin d’un noyau indépendant ?
CPU

Les vCPU sont-ils partagés ou dédiés ?

Y a-t-il un risque de burst limité ou de forte mutualisation ?
Stockage

Le type de disque est-il précisé ?

Le fournisseur publie-t-il IOPS, débit ou au moins des garanties de gamme ?
Snapshots

Sont-ils inclus ?

Peuvent-ils être restaurés rapidement ?

Restent-ils disponibles après suppression du VPS ?
Sauvegardes

Quelle fréquence ?

Quelle rétention ?

Les volumes annexes sont-ils couverts ?
Sécurité

Pare-feu réseau natif ?

Protection DDoS ?

Console de secours et rescue mode ?
Administration

Accès root complet ?

rDNS configurable ?

Réinitialisation de mot de passe possible ?
Localisation

Où est la VM ?

Où sont les backups ?

La région est-elle adaptée à la latence et à la conformité ?
Support

Quel SLA d’uptime ?

Quels délais de réponse ?

Quel canal en incident critique ?
Réversibilité

Puis-je exporter ou télécharger mes images ?

Puis-je reconstruire ailleurs sans dépendance forte au fournisseur ?
Prix réel

Le tarif inclut-il vraiment backups, snapshots, firewall et support utile ?

Si vous pouvez répondre clairement à chacune de ces lignes, vous êtes en train de choisir un VPS exploitable. Si plusieurs réponses restent floues, vous n’achetez pas une infrastructure : vous achetez une inconnue. Et en hébergement, les inconnues finissent presque toujours par coûter plus cher que l’écart de prix initial.