Docker remplace l’hyperviseur tiers de Docker Desktop par son propre VMM
Le 12 août 2026, Docker ouvre la bêta publique de Docker VMM, une couche de virtualisation maison qui remplace Apple Virtualization et Hyper-V sous Docker Desktop. Les gains promis touchent le démarrage, les E/S fichiers et la mémoire, mais ils font aussi de Docker l’unique responsable de la pile.
12 août 2026. Docker ouvre la bêta publique de Docker VMM, une couche de virtualisation écrite maison qui remplace, sous Docker Desktop, l’hyperviseur tiers que l’outil utilisait depuis ses débuts. Disponible dès la version 4.86 sur macOS et Windows, elle promet un démarrage plus rapide, des E/S fichiers accélérées et une gestion de la mémoire qui rend la RAM inutilisée à l’hôte. La disponibilité générale vise fin octobre 2026, avec le support Linux au même moment.
L’enjeu tient en une phrase : pour la première fois, Docker possède la pile complète sous ses conteneurs — du moteur jusqu’à la machine virtuelle qui l’héberge. C’est un virage stratégique autant qu’une promesse de performance, et il mérite qu’on regarde ce qui change vraiment.
Ce qu’est le VMM, et pourquoi on ne le voit jamais
Sous Docker Desktop, un conteneur Linux ne tourne jamais directement sur un Mac ou un Windows : il s’exécute dans une petite machine virtuelle Linux invisible, gérée par un virtual machine monitor (VMM). Ce VMM fabrique la VM, branche le réseau local, partage les fichiers et traduit les appels matériels. La plupart des développeurs n’y pensent jamais — jusqu’au jour où il est lent, instable, ou qu’il retient de la mémoire qu’il aurait dû rendre.
Jusqu’ici, Docker Desktop déléguait ce rôle à un tiers. Sur macOS, c’était le framework Virtualization d’Apple (après des années de HyperKit, le VMM maison historique). Sur Windows, c’était WSL2 ou Hyper-V. Docker VMM change la donne : c’est un hyperviseur conçu par Docker, pour des charges de conteneurs, sans la couche d’un fournisseur intermédiaire.
La différence n’est pas cosmétique. Un VMM générique doit convenir à des VM de toutes natures. Un VMM écrit pour un seul usage — faire tourner le moteur Linux de Docker — peut élaguer tout ce qui ne sert pas : les périphériques inutiles, les chemins de boot génériques, les indirections de partage de fichiers. C’est exactement l’argument de Docker : « nous possédons la pile complète, nous pouvons régler chaque partie du moteur pour les charges de conteneurs ».
Les quatre gains annoncés
La page de la bêta liste quatre effets concrets, et ils ciblent précisément les points de friction quotidiens :
- Démarrage plus rapide, du premier lancement aux changements de projet en passant par la reprise après redémarrage ;
- Meilleures E/S fichiers, avec un partage hôte-conteneur nettement accéléré — la boucle edit-compile-test y gagne à chaque build ;
- Gestion de mémoire plus intelligente, qui restitue la RAM à l’hôte quand les conteneurs sont inactifs ;
- Stabilité Windows améliorée, avec pour la première fois un VMM construit et maintenu par Docker pour les utilisateurs Windows.
Le dernier point mérite une précision technique : sur Windows, Docker VMM reste une VM isolée, mais Docker la positionne comme le meilleur des deux mondes — l’isolation d’Hyper-V avec la vitesse de WSL2. L’isolation reste totale, ce qui écarte le scénario « conteneur exécuté en processus hôte » et ses implications de sécurité.
Un détail de configuration qui compte : VirtioFS devient obligatoire
Ce qui est moins visible dans l’annonce, c’est une contrainte de configuration. Docker VMM ne prend en charge qu’un seul mécanisme de partage de fichiers : VirtioFS. Les utilisateurs qui utilisaient encore gRPC-FUSE (ou l’ancien partage osxfs) basculeront donc de force sur VirtioFS en activant la bêta.
C’est un choix cohérent : VirtioFS est aujourd’hui l’implémentation la plus rapide, avec des gains revendiqués allant jusqu’à 98 % sur certaines opérations de système de fichiers. Mais pour les équipes dont certains workflows dépendaient de comportements spécifiques de l’ancien partage — notamment sur les gros dépôts ou les montages imbriqués — le passage à Docker VMM n’est pas qu’une coche à activer. C’est une migration de partage de fichiers déguisée.
Comment l’activer, et comment vérifier
L’activation est volontairement simple, sans liste d’attente ni feature flag à réclamer. Il faut Docker Desktop 4.86 ou plus récent, puis :
- sur macOS, les utilisateurs qui avaient déjà sélectionné « Docker VMM » dans les réglages sont mis à jour automatiquement vers le nouveau moteur à la montée en 4.86 ;
- sur Windows, l’option apparaît dans Settings → General, sous la forme d’un sélecteur « Docker VMM » à activer manuellement.
Une fois la bête activée, deux commandes permettent de confirmer l’état du moteur et la version embarquée :
# Version de Docker Desktop et du moteur
docker version
# Informations détaillées : OS hôte, kernel de la VM, version du moteur
docker infoLe champ Server → Operating System de docker version indique la distribution Linux embarquée dans la VM, et docker info confirme le noyau qui tourne sous le nouveau VMM. En cas de doute sur le mécanisme de partage actif, c’est dans Settings → General → Choose file sharing implementation que Docker Desktop affiche VirtioFS comme seule option compatible avec Docker VMM.
Le pari stratégique : un moteur pour tout le reste
La bêta ne s’arrête pas à la performance. Docker le dit explicitement : le moteur de Docker VMM est le même que celui qui propulse Docker Sandboxes (SBX), l’environnement isolé pour les agents de codage. Chaque amélioration du moteur profite donc aux deux produits en même temps.
Et la feuille de route va plus loin. Docker vise à terme un runtime unifié qui couvre l’ordinateur portable, le cloud et l’on-premise, où conteneurs, applications Compose et agents seraient des citoyens de première classe sur une même fondation. Docker VMM est présenté comme la première étape de ce chemin — ce qui explique pourquoi Docker investit dans un hyperviseur alors même que la tendance du marché pousse vers des runtimes plus légers.
Le timing est tout sauf anodin. Docker Desktop est devenu le produit commercial central de l’éditeur, celui qui finance le reste. En reprenant la main sur le VMM, Docker supprime une dépendance technique envers Apple et Microsoft — deux acteurs dont les priorités en matière de virtualisation ne s’alignent pas forcément sur les siennes. C’est aussi une manière de verrouiller l’expérience : les réglages de gouvernance et de contrôle administratif annoncés pour l’entreprise se brancheront directement sur ce moteur.
Le revers : un point de défaillance unique
Il faut le dire franchement. Remplacer un hyperviseur éprouvé par un VMM en bêta n’est pas un geste neutre. Apple Virtualization et Hyper-V ont des années de durcissement derrière eux ; Docker VMM démarre. Si le nouveau moteur présente un bug — fuite mémoire, corruption de partage, plantage de VM — l’utilisateur n’a plus de solution de repli : il n’y a pas d’autre VMM à sélectionner derrière.
La fenêtre de risque est courte, mais réelle : la bêta court jusqu’à l’automne, et la disponibilité générale vise fin octobre 2026, soit à peine dix semaines après l’ouverture. Pour un outil installé sur des millions de postes de développement, c’est un rythme soutenu. La recommandation raisonnable est de traiter la bêta comme ce qu’elle est : un terrain d’essai à activer sur des machines non critiques d’abord, pas sur le poste de la personne qui doit livrer en production.
Verdict
Docker VMM est un bon pari stratégique et une vraie promesse de confort pour les développeurs. La logique est saine : un hyperviseur taillé pour un seul usage bat presque toujours un hyperviseur générique, et posséder la pile permet à Docker d’itérer sans dépendre du calendrier d’Apple ou de Microsoft.
La recommandation est conditionnelle mais tranchée : si vous êtes sur macOS ou Windows, passez en 4.86 et activez la bêta sur une machine de développement secondaire — les gains de démarrage et d’E/S sont réels, et le retour d’expérience aidera la GA d’octobre. Si votre partage de fichiers repose sur gRPC-FUSE ou sur des montages exotiques, testez VirtioFS avant de basculer, car c’est le seul mécanisme compatible. Et si votre poste est critique, attendez la GA : dix semaines de bêta, ce n’est pas une garantie de stabilité. Docker n’a plus d’excuse pour un VMM médiocre — il a désormais la main, et c’est exactement pour ça que la bêta mérite d’être observée de près.