Votre base PostgreSQL suffoque sur un VPS à 20 €. Le commercial propose un bare metal « pour avoir tout le CPU ». Facture ×3, livraison 48 h, migration manuelle — et après benchmark, le goulot était un index manquant, pas le hyperviseur.
Bare metal : serveur physique loué, OS direct sur le hardware (ou IPMI pour reinstall). VM cloud : slice virtualisée avec API, snapshot, redimensionnement en clics. La performance justifie la rigidité bare metal quand vous saturez mesurée des ressources VM et que l'isolation voisins est en cause — pas quand le tuning applicatif manque.
Comparatif exploitation
| Critère | VM cloud | Bare metal |
|---|---|---|
| Provisioning | Secondes–minutes | Heures–jours |
| IOPS / latence disque | Variable (voisins) | NVMe dédié typique |
| CPU sustained | Crédits burst possibles | Cœurs fixes |
| Snapshots / restore | Natif API | IPMI, imaging, plus lent |
| Scale up | Redimension instance | Changement machine |
| Coût petit projet | Bas | Souvent plancher élevé |
| Isolation | Hyperviseur | Physique |
Acheter du bare metal pour compenser une requête SQL non indexée reporte le vrai travail sur la facture matériel.
Quand rester en VM (cas majoritaire web)
Sites WordPress, API modérées, SaaS early-stage. VPS ou instance cloud + monitoring suffisent jusqu'à preuve contraire par métriques.
Besoin d'élasticité. Scale horizontal VM + load balancer vs rack fixe.
Environnements jetables. Staging, CI runners — VM à l'heure.
Budget ops limité. Snapshots, rebuild API, pas de datacenter à appeler.
Hetzner Cloud, OVH Public Cloud, Scaleway Instances : profils NVMe local réduisent l'écart avec entry bare metal pour beaucoup de charges.
Quand bare metal se défend
I/O bound prouvé. iowait élevé, queue depth disque saturée sur VM premium déjà testée.
CPU 100 % sustained. Transcodage, rendu, simulations — pas burst 5 minutes.
Licences par socket. Parfois économie sur Oracle/SQL Server (vérifier contrat).
Compliance isolation stricte. Client exige pas de multi-tenant hyperviseur — rare mais documenté.
Acteurs comme Leaseweb, OVH Bare Metal, Online.net documentent profils — comparez annuaire.
Méthode de décision en 4 mesures
- 7 jours metrics : CPU steal, iowait, disk latency p99, RAM swap
- Tune app + DB sur VM actuelle ou tier supérieur
- Benchmark A/B VM premium vs bare metal entry (même région)
- Calculez TCO 36 mois incluant migration et ops
Le sommet : la rigidité est le prix caché du métal nu
Décider et avancer sans angle mort
- Profilez charge réelle 7–30 jours.
- Optimisez avant changement de classe hardware.
- Testez tier VM supérieur vs bare metal entry.
- Documentez procédure rebuild bare metal (RTO).
Voir S3 ou disque bloc pour couche stockage. Comparateur pour fiches dédiées.
Questions fréquentes
Le bare metal est-il toujours plus rapide qu'une VM ?
Souvent en I/O et CPU sustained. VM NVMe bien dimensionnée peut suffire — mesurez.
Qu'est-ce que je perds en bare metal ?
Provisioning lent, snapshots moins flexibles, scale = migration, parfois pas de facturation horaire.
Pour quels workloads bare metal se justifie ?
Bases forte écriture, transcodage, analytics — pas WordPress moyen non optimisé.
La VM suffit-elle pour la conformité ?
Oui si isolation documentée. Bare metal n'ajoute pas RGPD automatiquement.
Avant de signer un dédié, une question : avez-vous saturé la plus grosse VM de votre hébergeur avec une app déjà tunée ? Si non, le bare metal attend.