Si vous avez déjà tenté de faire tourner un environnement Linux sur votre Mac pour compiler un projet serveur, tester un conteneur Docker ou simplement exécuter un outil uniquement disponible sous Linux, vous connaissez la frustration. Docker Desktop fonctionne, mais il est lourd, lent à démarrer, et son modèle de facturation a changé plusieurs fois ces dernières années. Les machines virtuelles classiques via Parallels ou VMware Fusion font le travail, mais elles mobilisent plusieurs gigaoctets de RAM en permanence et démarrent en une trentaine de secondes. Il y a quelques années encore, les développeurs sur Mac avaient appris à composer avec ces contraintes, comme on s’habitue à une chaussure légèrement trop serrée.
Apple a décidé de changer cela, en silence, avec une approche architecturale que la plupart des utilisateurs n’ont pas remarquée. Le projet s’appelle Containerization. Il est entièrement écrit en Swift, publié en open source sur GitHub, et il repose sur une idée qui va à l’encontre de ce que font Docker et ses concurrents depuis dix ans.
L’origine : WWDC 2025 et une décision architecturale radicale
Lors de la conférence WWDC 2025, Apple a publié en open source un framework Swift baptisé Containerization, accompagné d’un outil en ligne de commande simplement appelé container. L’annonce est passée relativement inaperçue dans le flot des nouveautés, noyée entre les annonces autour d’Apple Intelligence et du nouveau design Liquid Glass. Pourtant, la décision technique au coeur de ce projet mérite attention.
Voici ce que fait Docker, et ce que fait Containerization à la place, expliqué simplement.
Docker, sur Linux, partage le noyau du système hôte entre tous les conteneurs. Chaque conteneur est une sorte de cage isolée, mais ils tournent tous sur le même noyau Linux sous-jacent. C’est ce qui rend Docker à la fois performant et, parfois, moins isolé qu’on ne le croit.
Sur macOS, Docker ne peut pas partager le noyau Darwin avec des conteneurs Linux, puisqu’il s’agit de deux systèmes différents. Docker Desktop contourne cela en faisant tourner une seule grande machine virtuelle Linux en arrière-plan, qui héberge ensuite tous vos conteneurs. Un noyau Linux partagé, dans une VM partagée, pour tous vos projets en même temps.
Apple a choisi le chemin inverse : une machine virtuelle légère et dédiée par conteneur. Chaque fois que vous lancez un conteneur avec l’outil container, une nouvelle VM minuscule démarre en moins d’une seconde, fait tourner votre conteneur, et s’arrête avec lui.
Pourquoi ce choix a du sens sur Apple Silicon
Cette approche est rendue possible, et même performante, grâce à deux éléments propres à l’écosystème Apple.
Le premier est le framework Virtualization, introduit par Apple avec macOS 11 Big Sur et profondément optimisé depuis. Ce framework permet de créer et démarrer des machines virtuelles légères en exploitant directement les capacités de virtualisation matérielles intégrées aux puces Apple Silicon. Le démarrage d’une VM simple prend quelques centaines de millisecondes, pas trente secondes.
Le second est vminitd, le système d’initialisation que l’équipe Apple a écrit entièrement en Swift, spécifiquement pour ces micro-VMs. Quand une VM Containerization démarre, le premier processus qui s’exécute à l’intérieur n’est pas le traditionnel init de Linux, mais ce binaire Swift compilé, ultra-minimal, qui initialise l’environnement, monte les systèmes de fichiers, configure le réseau, et lance votre application en quelques dizaines de millisecondes.
En termes de sécurité, l’isolation obtenue est identique à celle d’une vraie VM. Chaque conteneur est séparé des autres au niveau matériel, pas seulement au niveau logiciel. Apple a également intégré la gestion d’un système de fichiers EXT4 depuis Swift, ce qui permet de créer, formater et peupler des images disque Linux directement depuis le code du framework, sans dépendances externes.
WWDC 2026 : l’arrivée des Container Machines
Si le framework Containerization était la fondation technique, la version 1.0 du projet, présentée lors de WWDC 2026, apporte quelque chose que les développeurs attendaient sans vraiment savoir que c’était possible sur Mac : un environnement Linux persistant.
Apple le résume dans une formule directe : « A container machine is fast and lightweight, like a container, and persistent like a virtual machine. »
Un conteneur classique est éphémère par nature. Quand le processus s’arrête, les modifications apportées à l’intérieur disparaissent. C’est pratique pour des déploiements reproductibles, mais frustrant quand on veut installer des outils, configurer un environnement de développement, et retrouver tout ça intact le lendemain matin.
Une machine virtuelle traditionnelle est persistante, mais lourde et longue à démarrer. Une container machine combine les deux avantages : démarrage en moins d’une seconde, isolation par VM dédiée, et persistance complète entre les sessions.
Ce qui rend ces machines vraiment intéressantes
La première caractéristique notable est l’intégration avec l’environnement macOS. Quand une container machine démarre, elle crée automatiquement un utilisateur Linux dont le nom correspond exactement à votre compte macOS, avec les droits sudo sans mot de passe. Votre dossier personnel macOS est monté à l’intérieur de la machine Linux. Si vous êtes dans le dossier ~/Projets/MonApp sur votre Mac et que vous ouvrez un shell dans la machine, vous vous retrouvez dans ce même dossier, côté Linux.
En pratique, cela signifie que vous pouvez éditer vos fichiers avec Xcode ou VSCode sur macOS, puis compiler et exécuter depuis l’environnement Linux sans copier quoi que ce soit. Le même fichier, vu des deux côtés simultanément.
La deuxième caractéristique est la compatibilité avec les images OCI, le format standard utilisé par Docker et le reste de l’écosystème. Une container machine se crée à partir d’une image Ubuntu, Alpine, Fedora, ou de n’importe quelle image Linux compatible. Elle boot sur le système d’init de cette image, y compris systemd ou openrc, ce qui signifie que vous pouvez démarrer des services en arrière-plan avec systemctl start postgresql comme sur un vrai serveur Linux.
Les commandes concrètes
L’outil container fonctionne en ligne de commande, avec une syntaxe inspirée de Docker mais simplifiée. Voici le minimum pour démarrer :
# Créer une machine persistante à partir d'Ubuntu 24.04
container machine create ubuntu:24.04 --name dev
# Ouvrir un shell interactif dans la machine
container machine run -n dev
# Depuis le Mac, exécuter une commande dans la machine
container machine run -n dev swift build
# Lister les machines et leurs adresses IP
container machine list
Les ressources sont ajustables après création, avec la modification effective au prochain redémarrage de la machine :
container machine set -n dev cpus=4 memory=8G
L’alias m fonctionne partout à la place de machine, ce qui donne container m run ou container m ls pour aller plus vite.
Une subtilité réseau à connaître avant de l’apprendre à la dure : la container machine possède son propre réseau isolé et son propre adresse IP. Si vous faites tourner un serveur web à l’intérieur et que vous voulez y accéder depuis Safari sur votre Mac, ce serveur doit écouter sur l’interface externe de la machine, pas sur localhost. La commande container machine list affiche l’adresse IP de chaque machine active.
La comparaison qui vient à l’esprit : WSL de Microsoft
Les développeurs qui ont travaillé sous Windows ces dernières années connaissent bien WSL (Windows Subsystem for Linux), la fonctionnalité Microsoft qui permet d’exécuter un environnement Linux directement dans Windows, avec partage du système de fichiers et accès aux outils des deux côtés. C’est ce que The Register a appelé directement dans son titre lors de l’annonce, avec la formule « Apple gives Mac devs a WSL-ish thing to call their own. »
La comparaison est juste sur l’expérience utilisateur finale, mais les architectures sont différentes. WSL 2 fait tourner un noyau Linux dans une VM Hyper-V légère. Apple Containerization fait tourner un noyau Linux dans une VM légère via le framework Virtualization, une par machine. Le résultat pratique est similaire, mais le modèle d’isolation d’Apple est plus granulaire : vous pouvez avoir une machine Ubuntu pour votre projet Django, une machine Alpine pour vos outils Rust, et une machine Fedora pour votre projet MediaServer, chacune avec son propre noyau, ses propres processus, son propre réseau.
La configuration du système a migré dans la version 1.0 vers un fichier TOML situé à ~/.config/container/config.toml, remplaçant l’ancien système basé sur les UserDefaults de macOS. Si vous utilisiez une version antérieure, notez que les sous-commandes container system property get et container system property set ont été supprimées.
Ce que cela change pour le développement sur Mac
Pour un développeur qui écrit du code destiné à tourner sur des serveurs Linux, le flux de travail habituel impliquait soit une VM macOS classique à entretenir, soit un déploiement permanent vers un serveur de test distant pour valider que ça tourne réellement sur Linux. Les deux approches créent une friction : la VM est lente à démarrer et à mettre à jour, le serveur distant introduit un cycle déploiement-test-correction qui ralentit l’itération.
Avec une container machine dédiée à chaque projet, vous travaillez dans Xcode ou votre éditeur habituel sur macOS, vous basculez dans un terminal Linux avec container machine run, vous compilez et exécutez dans l’environnement cible exact, et vous revenez sur macOS pour inspecter le résultat dans votre navigateur. Les fichiers sont les mêmes, le projet est le même, la friction disparaît.
La contrainte technique est claire : l’outil container requiert un Mac avec une puce Apple Silicon et macOS 26. Cette dépendance n’est pas accidentelle. Le projet exploite des améliorations récentes du framework Virtualization qui ne sont disponibles que sous macOS 26, et les performances de démarrage sous-seconde reposent sur les capacités de virtualisation matérielle intégrées dans les puces M1, M2, M3 et M4.
Ce que l’architecture annonce
Le projet Containerization n’est pas un outil de niche. Il représente une décision stratégique d’Apple : faire du Mac une plateforme de développement sérieuse pour les applications qui tournent sur Linux en production, sans compromis sur l’expérience utilisateur macOS.
La fondation est open source, écrite en Swift, et maintenue sur GitHub par les ingénieurs Apple. La session WWDC 2026 consacrée aux container machines (session 389, « Discover container machines ») est publiquement disponible sur le portail développeur Apple. Le code source du projet apple/container sur GitHub documente l’architecture dans le détail, y compris le fonctionnement de vminitd et la spécification du hook /etc/machine/create-user.sh pour les organisations qui veulent personnaliser la création des utilisateurs dans leurs images de base.
Si vous faites du développement Swift serveur, du travail avec des outils Linux, ou que vous gérez des Macs où Docker Desktop commence à peser lourd sur les ressources, le moment est venu de regarder ce qu’Apple a construit, sans fanfare, à partir d’une puce et d’une idée architecturale bien précise.
| Titre de la page du support technique | URL officielle | Date de publication |
|---|---|---|
| Discover container machines (WWDC26, session 389) | https://developer.apple.com/videos/play/wwdc2026/389/ | 9 juin 2026 |
| Meet Containerization (WWDC25, session 346) | https://developer.apple.com/videos/play/wwdc2025/346/ | juin 2025 |
| apple/container, version 1.0.0 release notes | https://github.com/apple/container/releases/tag/1.0.0 | juin 2026 |
| Container machine documentation, apple/container | https://github.com/apple/container/blob/main/docs/container-machine.md | juin 2026 |
| Container Machines: A Persistent Linux Environment on Mac (Blake Crosley) | https://blakecrosley.com/blog/container-machines-linux-mac | 11 juin 2026 |
| Apple gives Mac devs a WSL-ish thing to call their own (The Register) | https://www.theregister.com/devops/2026/06/11/apple-gives-mac-devs-a-wsl-ish-thing-to-call-their-own/5254153 | 11 juin 2026 |










