VM, micro-VM ou conteneur : quel niveau d'isolation choisir pour vos workloads ?

Une question d'infrastructure qui est aussi une question de sécurité

Quand une équipe IT arbitre entre machine virtuelle et conteneur, la discussion tourne presque toujours autour de la performance, du coût ou de la rapidité de déploiement. C'est incomplet. Le choix du modèle d'isolation détermine aussi ce qui se passe si une application est compromise : l'attaquant reste-t-il cantonné à ce service, ou peut-il rebondir vers d'autres charges de travail sur la même machine physique ? Cette question devient centrale à mesure que les exigences de cloisonnement se renforcent, notamment sous l'effet de NIS2 et des clauses de sécurité imposées dans la chaîne d'approvisionnement.

Il existe aujourd'hui quatre familles de solutions, avec des niveaux d'isolation très différents : la machine virtuelle classique, la micro-VM, le conteneur système et le conteneur applicatif. Elles ne sont pas interchangeables.

Les quatre modèles, en clair

1. La machine virtuelle classique

Une VM (via un hyperviseur type KVM, VMware ou Hyper-V) émule un serveur complet : son propre noyau, son propre matériel virtuel, isolé du reste par l'hyperviseur. C'est le niveau d'isolation le plus fort et le plus mature, éprouvé depuis plus de vingt ans en production. Le prix à payer : un système d'exploitation entier à démarrer, patcher et surveiller par workload, avec un temps de démarrage de l'ordre de la minute et une empreinte mémoire significative.

2. La micro-VM

Les micro-VM (Firecracker, développé par AWS et utilisé notamment pour Lambda, ou Kata Containers) reprennent le principe de la VM classique — un noyau isolé par un hyperviseur — mais avec un matériel virtuel radicalement simplifié et un temps de démarrage ramené à quelques dizaines de millisecondes. L'objectif : conserver l'isolation matérielle d'une vraie VM tout en approchant la légèreté et la densité d'un conteneur. Kata Containers va plus loin en s'intégrant directement à l'écosystème Kubernetes : chaque pod tourne dans sa propre micro-VM, avec l'API et les habitudes opérationnelles des conteneurs classiques.

3. Le conteneur système

Moins connu, ce modèle (LXC, LXD) fait tourner un système Linux complet dans un espace de noms isolé, mais sans hyperviseur ni noyau dédié : tous les conteneurs système d'une machine partagent le même noyau hôte. Il se situe entre la VM et le conteneur applicatif — plus proche de l'usage « petit serveur virtuel » que de l'usage « une application, un conteneur ».

4. Le conteneur applicatif

Le modèle Docker / OCI, aujourd'hui standard pour empaqueter et déployer une application. Isolation par espaces de noms (namespaces) et groupes de contrôle (cgroups) du noyau Linux, avec un noyau partagé entre tous les conteneurs de la machine. C'est le plus léger, le plus rapide à démarrer, et celui qui permet la plus forte densité — mais aussi celui dont l'isolation est la plus faible en cas de faille noyau ou de mauvaise configuration.

Surface d'attaque : ce que change le noyau partagé

Un noyau partagé signifie qu'une vulnérabilité noyau exploitée depuis un conteneur peut, dans le pire cas, affecter l'ensemble des workloads de la machine hôte — un scénario documenté à plusieurs reprises via des failles d'évasion de conteneur (« container escape »). Ce n'est pas une fatalité : des mécanismes comme seccomp, AppArmor, SELinux ou l'exécution rootless réduisent nettement ce risque au quotidien. Mais ils atténuent la surface d'attaque, ils ne changent pas la nature du modèle : le noyau reste un point de défaillance commun.

La VM et la micro-VM suppriment ce point commun : même en cas de compromission complète d'un workload, l'attaquant se heurte à la frontière de l'hyperviseur pour atteindre un autre workload. C'est pour cette raison que les environnements multi-tenant les plus sensibles — hébergement mutualisé, fonctions serverless exécutant du code tiers, environnements de test exécutant du code non maîtrisé — s'appuient très majoritairement sur des VM ou des micro-VM plutôt que sur de simples conteneurs.

Quel modèle pour quel usage

• Isolation maximale requise (multi-tenant avec du code non maîtrisé, données très sensibles, obligation contractuelle de cloisonnement fort) : VM classique ou micro-VM. Les micro-VM apportent l'essentiel du bénéfice de sécurité de la VM avec une densité et un temps de démarrage proches du conteneur — un compromis particulièrement pertinent pour du serverless ou du CI/CD exécutant du code externe.
• Applications internes standards, environnement de confiance maîtrisé : conteneur applicatif (Docker/OCI), généralement orchestré via Kubernetes. C'est le choix par défaut de la majorité des architectures modernes, à condition d'appliquer les bonnes pratiques de durcissement (exécution non-root, images minimales, mise à jour régulière du noyau hôte).
• Migration d'un existant type « petit serveur virtuel » sans réécriture applicative : conteneur système (LXC/LXD), qui conserve les habitudes d'administration d'un serveur classique tout en gagnant en densité par rapport à une VM complète.

Le pont avec le choix d'infrastructure souveraine

Ce choix d'isolation ne se fait pas dans l'abstrait : il conditionne aussi le choix d'hébergeur. Un acteur du cloud souverain européen ne propose pas nécessairement les mêmes briques de micro-VM que les hyperscalers américains — Firecracker reste, par exemple, principalement associé à l'écosystème AWS. Avant d'arbitrer un modèle d'isolation, il est donc utile de vérifier ce que votre hébergeur cible sait réellement opérer en production, plutôt que de concevoir une architecture autour d'une brique indisponible chez lui.

Ce qu'il faut retenir

Le choix entre VM, micro-VM et conteneur n'est pas qu'une affaire de performance : c'est un arbitrage entre isolation et densité. La VM et la micro-VM isolent au niveau du noyau et conviennent aux workloads les plus sensibles ou multi-tenant ; le conteneur système et le conteneur applicatif partagent le noyau hôte et offrent en échange légèreté et vitesse, à condition d'appliquer un durcissement sérieux. Une équipe IT ou un RSSI qui arbitre son infrastructure gagne à partir du niveau de risque réel de chaque workload plutôt que d'une préférence technologique unique — et à vérifier que l'hébergeur visé, souverain ou non, sait effectivement opérer le modèle retenu.