Qu’est-ce que la virtualisation ? Tout ce qu’il faut savoir

Il n’y a pas si longtemps, les salles serveurs obéissaient à une règle simple : une machine, une tâche. L’e-mail tournait sur sa propre machine. Le partage de fichiers avait un serveur dédié. La base de données vivait ailleurs. Chaque système avait son propre cycle de correctifs, sa consommation électrique et ses pannes matérielles, le tout multiplié par une pièce pleine de machines sous-utilisées.

Beaucoup de ces machines étaient dimensionnées pour le pire jour de l’année, puis passaient le reste du temps à attendre. La virtualisation a changé l’équation économique. Au lieu de dédier un serveur à chaque service, les équipes ont commencé à regrouper plusieurs charges de travail sur un plus petit nombre d’hôtes plus puissants. Chaque charge tourne toujours dans son propre environnement, mais l’empreinte physique diminue : moins de serveurs à acheter, câbler, alimenter, refroidir puis mettre au rebut.

Ce guide couvre les éléments qui comptent concrètement : le rôle de l’hyperviseur, la place des types 1 et 2, le fonctionnement de l’allocation des ressources, et les liens entre VM, conteneurs et services cloud. L’objectif est de vous aider à choisir le bon outil et à comprendre les contraintes qui apparaissent une fois passée la première définition.

Image par wirestock sur Freepik.

Comment fonctionne la virtualisation

La virtualisation permet à un hôte physique d’exécuter plusieurs « machines » à la fois — chacune avec son propre OS, ses processus et son système de fichiers. Le composant qui rend cela possible est l’hyperviseur : la couche de contrôle qui répartit CPU, mémoire, stockage et réseau entre les invités et fait respecter les frontières entre eux.

La couche hyperviseur

L’hyperviseur joue le rôle de tour de contrôle. Les invités demandent du temps CPU, des pages de RAM, des I/O disque et de l’accès réseau ; l’hyperviseur ordonnance ces requêtes pour éviter qu’une VM n’affame les autres ou ne prenne le contrôle de l’hôte.

Les CPU modernes intègrent des extensions de virtualisation (Intel VT-x, AMD AMD-V) qui réduisent la surcharge de traduction qui rendait autrefois la virtualisation de bureau poussive. Ces extensions CPU expliquent en grande partie pourquoi la virtualisation sur poste n’a plus des allures de projet expérimental. Avec du matériel récent, faire tourner quelques VM sur un laptop de développeur devient généralement anodin — dans le bon sens.

L’attribution des ressources est ce que vous manipulez le plus souvent :

• CPU : le nombre de cœurs virtuels visibles par l’invité
• Mémoire : la quantité de RAM utilisable avant swap ou blocage
• Stockage : un disque virtuel qui se comporte comme un disque physique du point de vue de l’invité
• Réseau : des NIC virtuelles reliées via des switches virtuels au réseau réel

À l’intérieur de l’invité, tout paraît normal : l’OS démarre, les paquets s’installent, les fichiers s’écrivent, les sockets s’ouvrent. Ce que vous ne voyez pas depuis la VM, c’est l’arbitrage sous-jacent — qui obtient le CPU ensuite, quelles écritures disque sont en file d’attente, et quand l’hôte sature.

Hyperviseurs de type 1 vs type 2

La plupart des hyperviseurs se répartissent en deux catégories, et la différence tient surtout à l’emplacement de l’hyperviseur.

• Type 1 (bare metal) s’exécute directement sur le matériel hôte et est la norme en production car il gaspille moins de capacité dans « la couche du dessous ». ESXi et Hyper‑V en déploiements serveurs entrent dans cette catégorie, et KVM est couramment utilisé comme couche de virtualisation dans les piles Linux.
• Type 2 (hosted) s’exécute comme une application sur votre OS existant. Vous conservez Windows/macOS/Linux comme hôte, puis installez VirtualBox ou VMware Workstation par‑dessus. C’est la façon la plus simple de monter un petit labo sur une machine personnelle, et c’est généralement par là que l’on commence.

Allocation des ressources

Lorsque vous créez une VM, vous faites un pari : « cette charge de travail a besoin d’environ tant de CPU, de mémoire et de disque ». Les hyperviseurs offrent de la flexibilité dans la façon de représenter et réserver ces ressources.

Le provisionnement du stockage illustre bien le compromis :

• Provisionnement épais : réserve immédiatement toute la taille du disque virtuel. Créez un disque de 100 Go, et l’hôte met de côté cet espace tout de suite, que la VM l’utilise ou non. C’est simple et prévisible, mais vous payez le coût de stockage à l’avance — même quand la VM est quasi vide.
• Provisionnement fin : reporte le coût. L’invité voit toujours un disque de 100 Go, mais l’hôte ne consomme de l’espace que lorsque des blocs sont écrits. Cela améliore l’utilisation et rend possible la sur‑allocation, mais crée aussi un mode de panne : si l’hôte manque d’espace réel, des VM peuvent commencer à renvoyer des erreurs difficiles à corriger rapidement.

CPU et mémoire sont souvent gérés avec le même état d’esprit « probabiliste » via la sur‑allocation. Vous pouvez allouer plus de CPU virtuels au total que vous n’en avez physiquement car vous anticipez que les charges ne culmineront pas toutes en même temps. Cela fonctionne bien pour beaucoup de charges mixtes, mais peut créer des contentions si tout s’active simultanément. La sur‑allocation n’est pas « mauvaise » — elle exige simplement de la visibilité sur les points de pression de l’hôte.

Snapshots et migration à chaud

Deux fonctionnalités méritent d’être mises en avant car elles changent les opérations au quotidien, pas seulement les schémas d’architecture.

• Snapshots : un point de retour arrière. Prenez‑en un avant un correctif ou un changement de configuration risqué, et vous pourrez revenir rapidement si la VM ne démarre plus ou si l’application se comporte mal. D’où leur usage courant en test/pré‑prod et lors des fenêtres de maintenance.
• Migration à chaud : permet de déplacer une VM en cours d’exécution vers un autre hôte avec très peu d’interruption. En pratique, c’est ainsi que la maintenance se fait à grande échelle : évacuer un hôte, appliquer des correctifs ou remplacer du matériel, rééquilibrer les charges, tout en gardant les services clients en ligne.

Les formes de virtualisation qui comptent

Il existe des virtualisations spécialisées (réseau, stockage, données), mais la plupart des équipes se heurtent régulièrement à trois catégories.

Virtualisation de serveurs

C’est le modèle de base : un hôte physique exécute de multiples instances serveur, chacune en VM avec son propre OS et ses applications.

Les gains apparaissent vite. Pensez à la « petite flotte » typique d’une entreprise : une appli web légère, une base de données, des tableaux de bord internes, un ordonnanceur, un service de fichiers, du monitoring, peut‑être un broker de messages. Pris séparément, chacun semble mériter un serveur. En réalité, la plupart passent de longues périodes quasi inactifs. La virtualisation transforme ces temps morts en capacité partagée.

Un exemple concret que beaucoup d’organisations constatent :

10 serveurs physiques → 2 hôtes de virtualisation

Après consolidation, il n’y a pas que les coûts qui changent. Le provisioning accélère. La capacité devient un pool plutôt qu’un ensemble d’îlots isolés. Lorsqu’une charge a besoin de plus de ressources, vous réglez les allocations ou vous la déplacez, au lieu de commander du nouveau matériel.

Le revers, c’est le « destin partagé » : lorsqu’un hôte tombe, plusieurs VM disparaissent d’un coup. D’où des architectures de production bâties autour de la redondance, du monitoring et de marges de capacité prudentes.

Virtualisation de postes (VDI)

La VDI exécute des environnements de bureau sous forme de VM dans un data center (ou le cloud). Les utilisateurs se connectent via le réseau ; le calcul et le stockage restent centralisés plutôt que sur le poste.

La VDI s’impose lorsque les organisations veulent :

• des bureaux qui suivent les utilisateurs d’un appareil à l’autre
• des mises à jour, correctifs et politiques centralisés
• un risque réduit de données présentes sur des terminaux perdus ou volés

Une courte comparaison lève une confusion fréquente :

• Bureau à distance : vous vous connectez à une machine existante ailleurs.
• VDI : l’organisation met à disposition des VM de bureau (souvent par utilisateur ou par session) sur une infrastructure d’hôtes partagée.

L’interface peut sembler similaire, mais le modèle opérationnel ne l’est pas. La latence est un enjeu majeur, les besoins GPU font vite grimper les coûts, et gérer un grand parc de bureaux exige une vraie planification de capacité.

Virtualisation applicative et conteneurs

Les conteneurs résolvent un problème différent des VM. Au lieu de virtualiser le matériel pour exécuter des OS invités complets, les conteneurs isolent les applications tout en partageant le noyau de l’hôte. Vous obtenez une séparation au niveau processus/système de fichiers/réseau sans démarrer un autre système d’exploitation.

Docker a rendu ce modèle accessible : empaquetez l’appli et ses dépendances en image, puis exécutez le même artefact en développement, CI et production. Cette répétabilité explique la diffusion rapide des conteneurs — moins de surprises liées à l’environnement, moins de « installez d’abord ces dix prérequis ».

Les conteneurs ont aussi l’ergonomie pour eux :

• Démarrage en quelques secondes plutôt qu’en minutes
• Empreinte souvent en mégaoctets plutôt qu’en gigaoctets
• Faire tourner de nombreux micro‑services en local devient réaliste

VM et conteneurs répondent à des besoins en partie chevauchants mais distincts :

Un schéma de production courant est « des conteneurs sur des VM ». La frontière VM sert à l’isolation d’infrastructure et à la gestion de flotte ; les conteneurs gèrent le déploiement et la mise à l’échelle au niveau applicatif. Notre Introduction to Docker couvre les bases des conteneurs. Notre parcours Containerization and Virtualization with Docker and Kubernetes va plus loin dans les schémas d’orchestration.

VM, conteneurs, cloud : quelles différences ?

On regroupe souvent ces termes car ils coexistent dans la même pile. Il est utile de les distinguer par ce que vous obtenez réellement : un OS isolé (VM), un runtime applicatif isolé (conteneur) ou une plateforme managée qui provisionne les deux (cloud).

Machines virtuelles

Une machine virtuelle embarque un système d’exploitation complet, du matériel virtuel et des applications. Chaque VM a son propre noyau, ce qui offre une isolation forte entre charges sur le même hôte.

Le coût, c’est l’empreinte : des OS complets consomment plus de mémoire, mettent plus de temps à démarrer et génèrent des images plus volumineuses. Cette surcharge est souvent acceptable en production car l’isolation et la compatibilité en valent la peine.

Conteneurs

Les conteneurs partagent le noyau de l’OS hôte tout en isolant le runtime applicatif. Ce noyau partagé est ce qui les rend légers et rapides. Les images sont généralement plus petites et plus faciles à déplacer, ce qui les rend bien adaptés aux workflows de déploiement modernes.

L’isolation des conteneurs est réelle, mais ce n’est pas la même barrière que des « noyaux séparés ». Les conteneurs dépendent toujours du noyau hôte, d’où l’influence du caractère sensible des charges et de la posture de sécurité sur le choix de les exécuter directement sur des hôtes ou à l’intérieur de VM.

Informatique en nuage

Les plateformes cloud s’appuient sur la virtualisation (et souvent sur des conteneurs) et l’enveloppent d’un plan de contrôle managé : API, provisioning, facturation, réseau, et services que vous n’opérez pas vous‑même (bases de données, files d’attente, stockage objet, monitoring).

Quand vous lancez une instance EC2, vous louez en pratique une VM au sein de la flotte d’AWS. D’autres produits — fonctions serverless, services de conteneurs managés — utilisent des mécanismes d’isolation plus légers, mais l’idée reste la même : le cloud expose des ressources à la demande et masque une grande partie du travail d’infrastructure derrière une API.

Un cadre de décision simple :

• Utilisez des VM lorsque la séparation des OS ou la compatibilité guide la conception.
• Utilisez des conteneurs pour des démarrages rapides et un artefact de déploiement reproductible.
• Utilisez des services cloud lorsque l’élasticité et l’opération managée priment sur le contrôle des hôtes sous‑jacents.

En pratique, la version « empilée » est courante : des VM cloud hébergent des clusters Kubernetes, qui orchestrent des conteneurs, qui exécutent les applications. Pour aller plus loin sur l’architecture cloud, consultez notre cours Understanding Cloud Computing et notre cours Understanding Microsoft Azure Architecture and Services pour les services spécifiques à Azure. 

Pourquoi la virtualisation compte

La virtualisation perdure car elle résout des problèmes concrets à travers le développement, les opérations et les métiers de la donnée.

Développement et tests

La virtualisation rend peu coûteuse la création d’environnements contrôlés. Besoin de tester un pipeline sur deux versions d’OS ? Créez deux VM, exécutez les mêmes étapes, comparez les comportements. Envie de tenter une mise à niveau risquée ? Prenez un snapshot, procédez, revenez en arrière si besoin.

Elle supprime aussi des frictions pour les vérifications multiplateformes. Un développeur sur macOS peut valider le comportement sous Windows sans faire tourner plusieurs machines physiques.

Pour les travaux data, la reproductibilité est le fil rouge. Les résultats dépendent souvent d’un mélange précis de paquets, bibliothèques système et configuration. Les environnements virtualisés aident à garder ces dépendances stables et portables.

Coûts et efficacité

La mutualisation des ressources est l’avantage de base : vous cessez de payer pour dix machines inactives et utilisez le même matériel de façon plus régulière.

Les économies se voient dans des postes concrets : moins de serveurs à acheter, moins d’espace en baie, des besoins de refroidissement réduits, moins de contrats de maintenance, et un tas de matériel de remplacement plus réduit. La consolidation n’élimine pas le travail opérationnel, elle en change la nature.

Flexibilité et montée en charge

Le provisioning devient une tâche logicielle. Au lieu de commander du matériel, attendre la livraison, le monter et imager un OS, les équipes clonent un template, définissent les allocations et déploient.

La mise à l’échelle est aussi moins rigide. Si la demande augmente, vous ajoutez des VM ou redimensionnez l’existant. Si elle baisse, vous récupérez de la capacité au lieu de laisser un serveur physique sous‑utilisé des mois durant.

La reprise après sinistre ne devient pas automatique, mais la virtualisation élargit la boîte à outils. Quand le « serveur » est une image de VM managée plus des données, les stratégies de réplication et de restauration sont plus faciles à standardiser qu’à l’époque du « une appli par machine ».

Défis fréquents et comment les gérer

La virtualisation supprime une catégorie de soucis et en introduit une autre. La plupart des problèmes ne sont pas mystérieux : limites de ressources, contention ou hygiène opérationnelle.

Problèmes de performance

La plainte la plus fréquente est la contention : plusieurs VM se disputent le même temps CPU, la même bande passante mémoire ou les mêmes I/O de stockage. Tout semble aller jusqu’à ce que plusieurs charges culminent en même temps ; la latence grimpe et le débit chute.

Ce qui aide en pratique :

• Surveillez les métriques de l’hôte, pas seulement celles de l’invité (CPU ready time, pression mémoire, latence disque/I&O en attente).
• Révisez régulièrement les dimensionnements. Les deux extrêmes font mal : sur‑allouer gaspille la capacité ; sous‑allouer provoque du swap et de l’« agitation ».
• Considérez une utilisation soutenue élevée comme un signal de capacité et planifiez en conséquence, plutôt que de courir après les symptômes VM par VM.

Une minorité de charges ont encore leur place sur du bare metal : sensibilité extrême à la latence, couplage fort à du matériel spécialisé, ou contraintes temps réel où même un léger jitter d’ordonnancement est inacceptable.

Considérations de sécurité

L’isolation des VM est solide, mais pas un champ de force. Les hôtes sont partagés, les hyperviseurs sont des infrastructures critiques et des vulnérabilités — rares mais réelles — existent.

Une posture sécurité pragmatique ressemble à :

• Appliquer rapidement les correctifs aux hyperviseurs et aux hôtes
• Segmenter les réseaux pour que « même hôte » ne signifie pas « même zone de confiance »
• Séparer les charges hautement sensibles quand le profil de risque l’exige

Les conteneurs ajoutent un autre choix : les exécuter directement sur des hôtes ou à l’intérieur de VM dépend de vos besoins d’isolation et de votre modèle opérationnel.

Prolifération de VM

La virtualisation facilite la création, donc les environnements grossissent vite. Sans garde‑fous, vous vous retrouvez avec des VM orphelines, des propriétaires inconnus et des machines qui existent « au cas où ».

Un modèle de prévention efficace :

• Exiger des tags de propriétaire et de finalité
• Attribuer des dates d’expiration pour les VM de dev/test
• Revoir l’utilisation régulièrement (et supprimer ce qui est réellement inactif)
• Automatiser le nettoyage en environnements non‑prod

Les audits révèlent souvent une part étonnamment élevée de VM faisant peu de travail pendant longtemps. Le correctif est rarement complexe ; c’est surtout de la discipline et de la gestion du cycle de vie.

La virtualisation au quotidien

La virtualisation est présente dans des usages quotidiens de nombreuses équipes, même si elles ne la nomment pas ainsi.

Développement et data science

CI/CD exécute fréquemment des jobs sur des VM ou des conteneurs éphémères afin que chaque run démarre dans un environnement propre. Cela évite la dérive de dépendances et facilite la reproduction des échecs.

L’isolation évite aussi les collisions entre projets. Un workflow peut nécessiter d’anciennes bibliothèques CUDA ; un autre des versions plus récentes. Des environnements séparés empêchent ces besoins de tourner au bras de fer des dépendances.

Les notebooks hébergés constituent un autre cas d’usage de la virtualisation. Lorsque vous lancez Jupyter sur des plateformes comme Colab, le notebook s’exécute dans une infrastructure gérée par un tiers. Comprendre ce contexte rend moins mystérieux les limites de ressources, les redémarrages et le comportement du système de fichiers.

Entreprise et cloud

Les fournisseurs cloud opèrent la virtualisation à très grande échelle. Leur modèle économique dépend d’un « empaquetage » efficace de charges clientes diverses sur des flottes partagées tout en maintenant des frontières d’isolation strictes.

Les entreprises appliquent la même logique pour la consolidation et la compatibilité legacy. Virtualiser une application plus ancienne permet de la faire tourner sur du matériel moderne bien après la fin de vie de son serveur d’origine.

Pour des architectures hybrides, des services comme AWS Outposts existent car certaines organisations veulent des modèles proches du cloud tout en exécutant une partie des charges au plus près de leurs sites.

Apprentissage et expérimentation

La virtualisation reste l’un des environnements les plus sûrs pour apprendre. Vous pouvez lancer une VM Linux, expérimenter librement, tout casser, revenir à un snapshot, ou la supprimer sans toucher à votre système principal.

Elle est aussi utile pour simuler, sur une seule machine, des systèmes multi‑services : un front web, une couche applicative et une base de données qui communiquent via des réseaux virtuels — suffisamment réaliste pour apprendre les concepts sans facture cloud.

Vers où va la virtualisation

Plusieurs tendances façonnent l’usage de la virtualisation pour les prochaines années.

Edge computing : davantage de charges près des lieux de production des données. Des VM et conteneurs légers aident à standardiser le déploiement sur des sites distribués, mais gérer des flottes en périphérie introduit sa propre complexité.

Gestion plus intelligente des ressources : les plateformes automatisent de plus en plus le bon dimensionnement, rééquilibrent plus agressivement et détectent plus vite le gaspillage — surtout là où l’ajustement manuel ne passe pas à l’échelle.

Enfin, les piles hybrides deviennent la norme. Kubernetes domine l’orchestration de conteneurs dans de nombreux environnements, et « conteneurs dans des VM » reste un schéma de production courant : isolation VM au niveau infra, flexibilité des conteneurs au niveau applicatif. Notre Introduction to Kubernetes couvre les fondamentaux.

Conclusion

La virtualisation rend l’infrastructure moderne praticable à grande échelle : elle découpe un hôte physique en environnements isolés que l’on peut créer, redimensionner, déplacer et retirer sans toucher au rack. 

Pour nous, professionnels de la donnée, ce n’est pas de l’arrière‑plan anecdotique. On la retrouve dans les environnements reproductibles, les conflits de dépendances entre projets et les petits « pourquoi ce notebook a‑t‑il redémarré ? » qui s’éclairent quand on se souvient qu’il y a un runtime managé en dessous.

La meilleure façon d’ancrer les concepts est de monter un mini‑labo. Installez un hyperviseur de type 2, créez une VM Linux, prenez un snapshot, cassez quelque chose volontairement, puis revenez en arrière. Exécutez ensuite une charge similaire dans un conteneur et comparez : temps de démarrage, empreinte de ressources, et ce que « isolation » signifie réellement dans chaque cas.

Nous avons d’excellentes ressources pour continuer :

• Containerization and Virtualization Concepts (mise en pratique des bases)
• Introduction to Docker (les conteneurs en pratique)
• Containerization and Virtualization with Docker and Kubernetes (parcours, des fondamentaux → à l’orchestration)