Définition
Un hyperviseur est une plateforme de virtualisation permettant à plusieurs systèmes d’exploitation de fonctionner en parallèle sur une seule machine physique.
Deux types, deux logiques d’usage
Les hyperviseurs de Type 1, dits natifs ou bare-metal, s’exécutent directement sur le matériel hôte pour gérer les systèmes invités — KVM, Microsoft Hyper-V, VMware vSphere en sont les représentants. QubesOS, un système d’exploitation orienté sécurité, s’appuie précisément sur l’hyperviseur bare-metal Xen pour cloisonner chaque application dans sa propre machine virtuelle.
Les hyperviseurs de Type 2, dits hébergés, s’exécutent comme une couche logicielle au-dessus d’un système d’exploitation hôte, qui ordonnance à son tour les ressources des machines virtuelles — QEMU, CrosVM, VirtualBox en relèvent.
Le choix entre les deux ne tient pas qu’à l’architecture : il répond avant tout à l’usage visé. Un hyperviseur hébergé convient à un usage quotidien ou à des tests sur poste personnel ; un hyperviseur bare-metal s’impose sur un serveur dédié, en production, ou dès que la performance devient un critère décisif.
| Fonctionnalité | Type 2 (hébergé) | Type 1 (bare-metal) |
|---|---|---|
| Migration à chaud | Non | Oui |
| Haute disponibilité | Non | Oui |
| Clustering | Non | Oui |
| Passthrough matériel (GPU, réseau) | Émulé, partiel | Complet |
| Performances et latence | Moyennes | Quasi-natives |
| Sécurité et isolation | Dépend de l’OS hôte | Très forte |
| Cas d’usage principal | Tests, développement, labo local | Production, datacenters, cloud |
Une nuance sur le passthrough GPU
Sur un Type 2, on bénéficie souvent d’une accélération 3D matérielle — mais c’est le système hôte qui partage la carte graphique via des pilotes émulés. Sur un Type 1, le PCIe passthrough est réel : la carte graphique est littéralement détachée du serveur physique et confiée exclusivement à la VM, une configuration très employée pour le cloud gaming ou l’entraînement de modèles d’IA.
La ligne « sécurité et isolation » mérite qu’on s’y arrête : sur un Type 2, si l’OS hôte est compromis, l’ensemble des machines virtuelles qu’il héberge le devient également — la surface d’attaque de l’hôte s’ajoute directement à celle de chaque VM. Un hyperviseur Type 1, en s’exécutant directement sur le matériel sans OS hôte intermédiaire, réduit d’autant cette surface partagée.
gVisor, un sandbox entre le conteneur et la VM
gVisor est un noyau d’application open-source développé en Go par Google, implémentant l’API Linux pour isoler des conteneurs comme le ferait un noyau indépendant. Son cas d’usage naturel se situe précisément là où l’exécution de code non sûr est inévitable — traitement de fichiers uploadés par des utilisateurs anonymes, SaaS manipulant des données sensibles — sans vouloir pour autant assumer le coût opérationnel d’une machine virtuelle complète.
Le coût de l'isolation
gVisor reste coûteux en surcoût d’exécution. Les systèmes générant de nombreux appels système, opérations réseau ou entrées-sorties disque voient leurs performances chuter significativement, comparativement à un conteneur classique ou même à une VM complète — l’isolation renforcée n’est jamais gratuite.
gVisor illustre ainsi un compromis récurrent en sécurité des systèmes : plus l’isolation entre le code non fiable et le noyau hôte est stricte, plus le coût en performance tend à croître. Le choix entre conteneur classique, gVisor, ou machine virtuelle complète se pose donc moins en termes de « quelle est la solution la plus sûre » que de « quel niveau de risque le gain de performance justifie-t-il d’accepter ».