Docker vs machine virtuelle : écarts de performance et guide de choix en 5 minutes

En réunion, le boss demande : « On part sur Docker ou sur des machines virtuelles pour le nouveau projet ? » J’ai utilisé les deux, mais expliquer clairement la différence, ce n’est pas évident. De retour au bureau, j’ai fouillé le web : soit c’est trop théorique, soit on se contente de « Docker est plus léger » — mais où est la légèreté ? Quel écart de performance ? Quel cas d’usage pour lequel outil ? Rien de concret.

Trois jours plus tard, j’ai enfin cerné le sujet. Aujourd’hui, je vous l’explique le plus simplement possible : la différence fondamentale (avec une métaphore parlante), l’écart de performance chiffré, et un arbre de décision pour choisir vite.

Différence fondamentale — conteneur vs chambre indépendante

Commençons par la métaphore la plus simple.

Une machine virtuelle, c’est un appartement indépendant dans un immeuble. Chaque logement a sa cuisine, sa salle de bain, son électricité — une unité de vie complète. Vous êtes au 2e, le voisin au 3e, chacun chez soi. Chaque VM exécute un OS complet (Windows, Linux…), avec son noyau, ses pilotes, ses services — le package intégral.

Un conteneur Docker, c’est un conteneur sur un quai. Tous partagent l’infrastructure du port — grues, électricité, routes. Le conteneur ne transporte que l’application et ses dépendances, pas une infrastructure dédiée par boîte. Les conteneurs Docker partagent le noyau de l’hôte et n’embarquent que l’app et son environnement.

La différence paraît mince, mais elle touche tout.

Côté architecture, la VM porte deux couches en plus : Guest OS et hyperviseur. L’hyperviseur simule tout le matériel — CPU, mémoire, disque, carte réseau. Au démarrage, il faut lancer l’OS complet, charger le noyau, initialiser les services — comme redémarrer un PC.

Docker s’appuie directement sur le noyau de l’hôte. Démarrer un conteneur, c’est lancer un processus — instantané. Pas de virtualisation matérielle, pas de couche OS supplémentaire — ultra léger.

Vous vous demandez peut-être : partager le noyau, est-ce sans risque ? Justement, c’est la faiblesse de Docker — isolation moins forte qu’une VM. C’est aussi son atout — rapidité, légèreté, économie de ressources.

Une fois cette différence comprise, comparaisons de perf et cas d’usage s’enchaînent naturellement.

Duel de performance — les chiffres

La théorie ne suffit pas, regardons les données.

Vitesse de démarrage : secondes vs minutes

La semaine dernière, j’ai chronométré une VM configurée (2 cœurs / 4 Go) : du boot à la connexion SSH, près de 4 minutes. Le temps d’un café et quelques posts.

Le même service Redis en Docker ? 3 secondes.

Pas le temps de poser la souris.

Ce n’est pas un hasard. La VM charge un OS complet — init noyau, services, réseau, tout y est. Docker démarre un processus ; le noyau tourne déjà, on enchaîne.

Consommation : Mo vs Go

Encore plus frappant : la consommation. Overhead Docker ? 6-8 Mo de mémoire. Oui, quelques Mo.

Mon conteneur Redis : CPU 0,08 %, mémoire 2,6 Mo. Quasi invisible.

Une VM, même vide ? L’OS seul avale 1-2 Go minimum. MySQL en VM ? 4 Go de base.

Conséquence brutale : sur le même serveur physique, quelques dizaines de VM au maximum, des milliers de conteneurs Docker. En prod, j’ai vu un serveur 32 cœurs / 128 Go avec 800+ conteneurs sans broncher. En VM ? 30, c’est déjà serré.

Perte de performance : proche du natif vs perceptible

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Des benchmarks montrent que Docker est quasi identique au natif, parfois plus rapide (moins d’overhead de virtualisation). Une VM ? Souvent 10-20 % de perte.

Surtout visible sur du CPU intensif. Compilation d’un gros projet chez moi : 25 min en VM, 21 min en conteneur, 20 min sur bare metal. Quasi aucune perte en conteneur.

Tableau récapitulatif :

Vous voyez pourquoi le microservices migre vers Docker : un ordre de grandeur d’écart sur l’utilisation des ressources.

Isolation et sécurité — plus fort n’est pas toujours mieux

Après les perf, parlons de la faiblesse de Docker.

Niveaux d’isolation

La VM isole au niveau matériel. Chaque VM a son propre noyau — deux machines distinctes. VM A compromise, le pirate ne saute pas vers B ou l’hôte. Isolation « dure ».

Docker ? Isolation au niveau processus. Tous les conteneurs partagent le noyau hôte, séparés par namespace et cgroups Linux. Moins rassurant, non ?

C’est réel. L’évasion de conteneur vise Docker — une faille peut ouvrir l’hôte. L’an dernier, CVE-2024-21626 permettait exactement ça.

Les VM ont aussi des risques, mais bien plus difficiles à exploiter.

Quand une VM est obligatoire ?

Docker n’est pas « insecure » — tout dépend du niveau d’isolation exigé.

Hébergeur cloud : clients isolés strictement → VM. AWS, Alibaba Cloud isolent les locataires en VM. Impossible de faire partager le noyau entre clients A et B.

Finance : conformité stricte (équivalent niveau 3) — un auditeur peut refuser Docker partageant le noyau → VM.

Code non fiable : plateforme de compilation en ligne → VM, pas Docker.

Comment durcir Docker ?

Pour la plupart des cas, c’est suffisant. Microservices internes, code maison — Docker convient. Trois réflexes :

1. Ne pas tourner en root. Conteneur root compromis = gros dégâts. Utilisateur non privilégié.
2. Limiter les Capabilities. Pas de droits système inutiles.
3. Scanner les images. Trivy ou équivalent, mettre à jour les bases.

Notre équipe applique ces trois règles depuis deux ans — aucun incident.

En bref : l’isolation dépend du modèle de menace. Interne → Docker ; multi-tenant exposé → VM.

Cas d’usage — l’arbre de décision

Quand utiliser quoi ? Voici un flux direct.

Quatre cas où Docker passe devant

1. Architecture microservices

Microservices → Docker sans hésiter.

Des dizaines de petits services indépendants. En VM : un service utilisateur = une VM, commandes = une VM, paiement = une VM… les ressources lâchent.

Docker : léger, démarrage instantané, haute densité. E-commerce : user, commandes, paiement — un conteneur chacun, isolation et scale-out faciles.

Sur un projet, 30+ microservices conteneurisés sur 5 serveurs. En VM, le coût serveur aurait triplé.

2. DevOps et CI/CD

Environnements dev / test / prod différents — le cauchemar classique. « Chez moi ça marche » — vous connaissez.

Docker emballe app + dépendances dans une image : même comportement partout.

CI/CD : Jenkins a besoin d’un env propre → conteneur, tests, destruction. 20 secondes. VM ? 5 min de boot + nettoyage manuel.

3. Déploiement rapide et élastique

23 h, pic de trafic, il faut 10 instances de plus.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Docker : quelques secondes, 10 conteneurs up.
VM : 5 min chacune, 10 = 50 min. Les utilisateurs sont partis.

C’est l’atout Docker — elasticité. Kubernetes scale automatiquement ; une VM n’atteint pas cette vitesse.

4. Environnement de dev unifié

Cinq devs : macOS, Windows, Ubuntu. MySQL, Node — versions différentes, « chez toi ça tourne ? »

Une image Docker, docker-compose up pour tous — MySQL, Redis, Nginx, versions figées.

Quatre cas où la VM s’impose

1. Application monolithique traditionnelle

ERP vieux de 10 ans : Java 6 + Oracle sur CentOS 6. Centaines de milliers de lignes, intouchable.

Ne forcez pas Docker. VM stable, priorité absolue. Conteneuriser = coût et risque élevés.

2. Besoin multi-OS

Windows et Linux simultanément — .NET sur Windows Server, Java sur Linux.

Docker = surtout Linux (conteneurs Windows très limités). VM : une Windows, une Linux.

Sur Mac, tester du Windows → VMware ou VirtualBox.

3. Isolation forte

Cloud, SaaS multi-tenant : un client = une VM, noyaux séparés.

Finance, secteur public : audits exigent preuve d’isolation — noyau partagé Docker peut échouer.

4. Environnement OS complet

Drivers embarqués, noyau et matériel spécifiques, dev bas niveau OS.

Docker partage le noyau hôte. La VM simule matériel et noyau complets.

Le mélange, la norme

La plupart des entreprises combinent.

Chez nous :

• Système de trading core (5 ans stable) : VM
• Nouvelle API gateway, microservices : Docker + Kubernetes
• Dev / test : tout Docker
• Tests bureautiques Windows : VMware

Stabilité du cœur, agilité du nouveau.

Arbre de décision rapide

Votre application est-elle nouvelle ?
├─ Oui → Architecture microservices ?
│   ├─ Oui → Docker ✅
│   └─ Non → Déploiements fréquents ?
│       ├─ Oui → Docker ✅
│       └─ Non → Autres critères
└─ Non (hérité) → OS/noyau spécifique requis ?
    ├─ Oui → VM ✅
    └─ Non → Isolation forte ?
        ├─ Oui → VM ✅
        └─ Non → Conteneurisation possible → Docker ✅

Suivez ce flux, la décision tombe en général d’elle-même.

Cas réels — comment les autres choisissent

Quelques scénarios concrets.

Cas 1 : startup 100 % Docker

Ami en SaaS, 15 personnes, budget serré : 3 ECS Alibaba (4 cœurs / 8 Go), une dizaine de services.

En VM : ~15 VM max sur 3 machines. Ils ont pris Docker + Kubernetes : 60+ conteneurs, marge restante.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Onboarding : clone + docker-compose up, env prêt en 5 min. Avant, une VM = une demi-journée de config.

Économie estimée : 10 serveurs en VM → 3 aujourd’hui — des dizaines de milliers d’euros par an.

Pour une startup, c’est concret.

Cas 2 : entreprise traditionnelle, migration progressive

Manufacturing : ERP SAP + Oracle, 15 ans, IBM en VM. Intouchable.

Transformation digitale : nouveau système supply chain. Le directeur IT a séparé : ERP legacy intact, nouveau en microservices Docker.

Aujourd’hui :

• ERP : VM, 5 serveurs, rock solid
• Supply chain : Docker + K8s, 3 serveurs, 70+ conteneurs
• Échange via API gateway

Stabilité du core, agilité du nouveau — « dual-mode IT » typique.

Cas 3 : isolation chez un hébergeur

Petit hébergeur, env isolé par client. Docker tentant (coût bas) — refusé : fuite d’un client ne doit pas toucher les autres. Noyau partagé = risque.

KVM : un client = une VM. Plus cher, mais contrat « serveur virtuel dédié », pas conteneur.

Sécurité avant coût.

Cas 4 : hybride cloud

Jeux en ligne : base de données en datacenter (sécurité données), serveurs de jeu élastiques (pics d’événements).

• Datacenter : MySQL master en VM
• Cloud : services de jeu en Docker + K8s, scale auto
• Événement : 10 → 100 conteneurs en 10 min
• Fin d’événement : retour à 20, économies

Core en VM, périphérie en Docker — le meilleur des deux.

Pas de bon ou mauvais absolu, seulement ce qui convient.

Conclusion

Docker et VM ne s’excluent pas — ce sont des outils complémentaires.

Nouveau projet, itération rapide, env homogène → Docker. Démarrage rapide, faible empreinte, microservices et DevOps. Mes nouveaux projets partent presque tous en Docker.

Legacy, isolation forte, multi-OS → VM. Stabilité et sécurité — utilisez-la quand il faut.

Beaucoup mélangent : core en VM, edge en Docker. Pragmatisme.

Trois actions :

1. Évaluez votre projet : arbre ci-dessus, 5 minutes
2. Testez petit : Docker d’abord sur services non critiques
3. Continuez d’apprendre : Kubernetes, Serverless, edge — l’écosystème évolue vite

Si Docker vous intéresse, prochain article : « Docker pratique : de l’installation au premier conteneur », pas à pas.

Le bon outil, moitié du chemin. Bon choix.