Niveau 🟡 intermédiaire
Durée estimée : 20 min · Prérequis : Installer Ubuntu Server
Une VM, c'est un appartement entièrement indépendant dans un immeuble : ses propres murs
porteurs, sa propre plomberie, son propre compteur Ă©lectrique — complet, mais lourd Ă
construire. Un conteneur, c'est une colocation : chacun a sa chambre et ses affaires
personnelles, mais tout le monde partage la même plomberie et la même structure du bâtiment
(le noyau), ce qui rend chaque « chambre » beaucoup plus légère à installer et à démarrer. LXC
se situe entre les deux : une colocation oĂą chaque chambre ressemble beaucoup plus Ă un vrai
petit appartement.
⚠️ Précision honnête. Contrairement au reste de M4 (largement vécu et testé sur notre
installation), le fonctionnement détaillé d'une VM ou de LXC reste une présentation
générale ici, non appuyée sur une expérience directe — aucun hyperviseur ni LXC n'a jamais
été mis en place sur ce serveur. En revanche, le choix « conteneur natif plutôt que VM » a,
lui, été vécu concrètement lors d'un changement d'architecture (voir l'encadré plus bas) — ce
n'est pas une notion purement théorique de bout en bout.
Une VM (machine virtuelle) simule un ordinateur complet : un hyperviseur (un logiciel
comme VirtualBox, KVM, Proxmox VE, VMware) partage les ressources physiques (CPU, RAM, disque)
d'une machine hĂ´te entre plusieurs machines virtuelles, chacune avec son propre noyau, son
propre système d'exploitation complet, totalement isolé des autres. Avantage : isolation
maximale, une VM peut même faire tourner un système d'exploitation différent de celui de la
machine hôte (Windows sur un hôte Linux, par exemple). Inconvénient : chaque VM porte le poids
complet d'un système d'exploitation entier — démarrage plus lent, consommation de ressources
plus élevée.
Un conteneur (Docker, déjà croisé dans ce wiki depuis M0) ne simule pas un ordinateur
complet : il partage le noyau de la machine hôte, et n'isole que les processus, le système
de fichiers et le réseau d'une application. Un conteneur démarre en une fraction de seconde
(pas de système d'exploitation à démarrer, juste un processus), consomme nettement moins de
ressources qu'une VM, mais son isolation est moins complète : un conteneur ne peut faire tourner
qu'un système compatible avec le noyau de la machine hôte (impossible de faire tourner Windows
dans un conteneur Linux, par exemple).
LXC (Linux Containers) se situe entre les deux : contrairement Ă un conteneur applicatif
(Docker), qui isole en général un seul processus, LXC fait tourner un système Linux complet
(avec son propre systemd, plusieurs processus, comme une petite machine à part entière), tout
en partageant le noyau de l'hôte comme un conteneur classique — plus léger qu'une VM, plus
proche d'un système complet qu'un conteneur Docker.
Tableau comparatif :
| VM | LXC | Conteneur (Docker) | |
|---|---|---|---|
| Isolation | Maximale (noyau propre) | Forte (noyau partagé, système complet) | Modérée (noyau partagé, un processus) |
| Démarrage | Lent (minutes) | Rapide (secondes) | Très rapide (fraction de seconde) |
| Ressources | Élevées | Modérées | Faibles |
| OS différent de l'hôte | Possible | Non (même noyau Linux) | Non (même noyau) |
| Usage typique | Isoler des environnements complets, tester un autre OS | Faire tourner un système complet léger | Isoler une application, une par une |
🧪 Concrètement, sur notre exemple : un vrai changement d'architecture vécu. Le tout
premier essai de ce projet tournait sur un Mac mini, avec Docker installé via OrbStack — un
outil qui fait tourner Docker à l'intérieur d'une VM Linux légère, cachée derrière une
interface qui donne l'impression d'un Docker natif. Le passage au ThinkPad X260 a changé
d'architecture : Docker Engine y tourne nativement sur le noyau, sans VM intermédiaire.
Trois conséquences concrètes de ce changement, pas juste théoriques :
- Accès matériel réel : passer un GPU à un conteneur (
/dev/dri, pour l'accélération
vidéo) fonctionne directement sur du natif — une VM ajoute une couche d'abstraction
matérielle qui aurait rendu ce passage plus complexe, voire impossible selon les cas.- Métriques qui mesurent la vraie machine : la supervision matérielle (vue en M8) lit
directement les capteurs de la machine hôte — avec Docker dans une VM, elle aurait mesuré
la VM, pas le matériel physique réel.- Disparition de
host.docker.internal: ce nom spécial, qui permet à un conteneur de
joindre la machine hôte, est une commodité propre à Docker Desktop/VM. En natif, il faut le
remplacer explicitement parextra_hosts: - "host.docker.internal:host-gateway"dans le
compose.yaml— un détail concret qui casse silencieusement si on migre sans le savoir.
La différence structurelle tient en une image : une VM ajoute une couche complète (hyperviseur +
noyau propre) par instance, un conteneur réutilise le noyau déjà en place et n'isole que ce qui
est nécessaire à l'application.
Cette page reste théorique — aucune commande n'a été testée dans le cadre de cette installation,
faute d'hyperviseur ou de LXC en place ici. Pour aller plus loin par toi-mĂŞme, les commandes de
référence généralement citées sont virsh (KVM/libvirt), l'interface de Proxmox VE pour les VM
et LXC, et docker run/docker compose pour les conteneurs — déjà utilisées ailleurs dans ce
wiki.
Pas de vĂ©rification pratique sur cette page prĂ©cise — la comprĂ©hension se vĂ©rifie en rĂ©pondant Ă
la question : « pourquoi un conteneur démarre-t-il tellement plus vite qu'une VM ? » (réponse :
il n'a pas de système d'exploitation Ă dĂ©marrer, juste un processus dans un environnement dĂ©jĂ
en place).
| SymptĂ´me | Cause probable | Solution |
|---|---|---|
| Croire qu'un conteneur est « une petite VM » | Vocabulaire proche, isolation apparente similaire | Un conteneur ne simule aucun matériel ni noyau — il isole un processus sur un noyau déjà partagé, mécanisme fondamentalement différent |
| Vouloir faire tourner un OS différent (Windows) dans un conteneur Docker sous Linux | Confusion entre isolation de conteneur et virtualisation complète | Impossible par nature — un conteneur partage le noyau de l'hôte, seule une VM permet un OS différent |
| Choisir une VM par réflexe pour isoler une simple application | Habitude ou méconnaissance de l'alternative conteneur | Pour isoler une application (pas un système complet), un conteneur est généralement plus léger et suffisant |
Parce qu'il ne démarre pas de système d'exploitation complet — il partage le noyau déjà en
fonctionnement de la machine hôte, et ne lance qu'un processus isolé.
Non — un conteneur partage le noyau de la machine hôte, il ne peut donc faire tourner qu'un
système compatible avec ce noyau. Seule une VM, avec son propre noyau, le permettrait.
LXC fait tourner un système Linux complet (plusieurs processus, son propre systemd), tout en
partageant le noyau de l'hôte — alors qu'un conteneur Docker isole généralement un seul
processus applicatif.
Sans avoir besoin d'installer quoi que ce soit, dresse une liste de deux usages personnels oĂą tu
choisirais une VM plutôt qu'un conteneur, et deux usages où l'inverse serait plus adapté — en
justifiant chaque choix avec le vocabulaire de cette page.
VM ·
hyperviseur ·
LXC ·
conteneur
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.