Installer Docker sur Mac, même sous Monterey

Docker sur Mac : la réponse courte

Pour installer Docker sur Mac, on passe d'habitude par Docker Desktop. Il faut toutefois un macOS récent. Au 20 octobre 2026, la dernière version, 4.96.0 (19 octobre 2026), s'installe à partir de macOS Sonoma 14. Votre MacBook Intel est resté sous Monterey 12 ou Ventura 13 ? Alors Docker Desktop actuel ne s'installe pas. Ce guide vous donne trois autres voies qui fonctionnent, chacune avec son coût.

Deux informations décident de tout : la puce de votre Mac et sa version de macOS. Ouvrez l'application Terminal et lancez :

uname -m
sw_vers -productVersion

uname -m affiche x86_64 sur un Mac Intel et arm64 sur un Mac Apple silicon. sw_vers -productVersion affiche la version de macOS, par exemple 12.7.6 pour Monterey. Notez ces deux valeurs pour la suite.

Une précision avant de commencer. Les commandes macOS de ce guide se lancent sur votre Mac, et nous ne les avons pas exécutées sur chaque version de macOS. Chaque étape indique donc ce que vous devez voir si tout va bien, et ce que veut dire un échec.

Quelles versions de macOS Docker Desktop prend-il en charge ?

La page d'installation de Docker pour Mac donne une règle courte : « Docker Desktop is supported on the current and two previous major macOS releases. » En clair, Docker Desktop est pris en charge sur la version majeure actuelle de macOS et sur les deux précédentes. La page ne donne aucun numéro de version. Elle demande aussi au moins 4 Go de mémoire vive, sur Apple silicon comme sur Intel. Elle propose toujours un installateur pour les Mac Intel.

Au 20 octobre 2026, Apple indique que la dernière version de macOS est macOS 27. Si on applique la règle à la lettre, elle couvre donc macOS 27, 26 et 15. Le minimum réel d'installation se trouve dans les notes de version de Docker Desktop, et il est plus bas : Sonoma 14 depuis la version 4.49.0. Aucune note publiée entre 4.50.0 et 4.96.0 ne relève ce minimum. Un Mac sous Sonoma installe donc encore la dernière version, mais il sort de la période de support annoncée. Avant d'installer ou de mettre à jour, relisez les notes de version de Docker Desktop. Cherchez une ligne « Minimum OS version » plus récente que celles citées ici.

Quelle version de Docker Desktop pour un ancien macOS ?

Docker a relevé plusieurs fois la version minimale de macOS. Chaque changement apparaît dans les notes de version :

• 4.12.0 (1er septembre 2022) : minimum macOS 10.15 Catalina.
• 4.16.0 (12 janvier 2023) : minimum Big Sur 11.
• 4.25.0 (26 octobre 2023) : minimum Monterey 12.
• 4.42.0 (4 juin 2025) : minimum Ventura 13.3.
• 4.48.0 (9 octobre 2025) : annonce la fin du support de macOS 13 et précise que la version suivante exigera macOS 14.
• 4.49.0 (23 octobre 2025) : minimum Sonoma 14.

Cet historique permet de retrouver la dernière version installable sur chaque ancien macOS. Docker ne publie pas cette liste. Nous l'avons construite à partir des minimums ci-dessus, sans installer chaque version :

• Mojave 10.14 : 4.6.1 (22 mars 2022), car Docker n'a plus publié de version installable sur Mojave à partir d'avril 2022.
• Catalina 10.15 : 4.15.0.
• Big Sur 11 : 4.24.2.
• Monterey 12 : 4.41.2.
• Ventura 13.0 à 13.2 : 4.41.2, car 4.42.0 exige 13.3.
• Ventura 13.3 et plus : 4.48.0.
• Sonoma 14 et plus : aucune limite connue à la version 4.96.0.

Ce minimum vaut pour l'installation et pour la mise à jour. Un Docker Desktop déjà installé sur Monterey ne se mettra donc pas à jour au-delà de 4.41.2.

Attention aussi aux liens de téléchargement : les notes de version n'en donnent que pour certaines versions. Ni 4.41.2 ni 4.48.0 n'ont de lien Docker.dmg dans ces notes. Pour Monterey, la version la plus récente avec un lien est 4.34.3 (9 octobre 2024), en version Intel et Apple silicon.

Voie 1 : rester sur la dernière Docker Desktop compatible

C'est la voie la plus simple, mais la plus risquée pour la sécurité. Ouvrez les notes de version et descendez jusqu'à la version choisie (4.34.3 pour Monterey). Téléchargez ensuite le Docker.dmg qui correspond à votre puce : le lien amd64 pour un Mac Intel, le lien arm64 pour Apple silicon. Installez l'application comme d'habitude et lancez-la une fois. Vérifiez ensuite dans le Terminal :

docker version
docker run --rm hello-world

docker version doit afficher une section Client et une section Server. hello-world doit afficher Hello from Docker!. Si la section Server manque, l'application Docker Desktop n'est pas lancée, ou sa machine virtuelle n'a pas fini de démarrer.

Si Docker Desktop tourne déjà sur un Ventura 13.3 ou plus récent, essayez d'abord la mise à jour intégrée à l'application. Elle peut aller jusqu'à 4.48.0, alors que les notes de version n'ont pas de lien direct pour cette version.

Le prix à payer : CVE-2025-9074

La version 4.44.3 (20 août 2025) corrige la faille CVE-2025-9074. D'après Docker, un conteneur malveillant pouvait atteindre le Docker Engine et lancer d'autres conteneurs, sans que le socket Docker soit monté dans ce conteneur. La fiche CVE précise que l'API du moteur était accessible par le sous-réseau Docker configuré, à l'adresse 192.168.65.7:2375 par défaut. Son score CVSS v4.0 est de 9.3, ce qui en fait une faille critique. Docker ajoute que l'isolation renforcée des conteneurs (ECI, Enhanced Container Isolation) ne protège pas contre cette faille.

Or 4.44.3 sort après 4.42.0, qui exige Ventura 13.3. Aucun Mac sous Monterey ne peut donc installer le correctif. Avec une version bloquée sur Monterey, chaque image que vous lancez peut en pratique piloter votre moteur Docker. Si vous choisissez cette voie, lancez seulement des images dont vous connaissez l'origine. Sur Ventura 13.3 et plus, la version 4.48.0 contient le correctif. C'est la version à viser.

Voie 2 : Colima, si votre Mac est sous Ventura

Colima fait tourner Docker dans une petite machine virtuelle basée sur Lima. Il fonctionne sur les Mac Intel comme sur les Mac Apple silicon, et utilise Docker par défaut. Au 20 octobre 2026, la dernière version est v0.10.3, publiée le 4 juin 2026.

Une limite compte ici : la FAQ de Colima dit « Colima requires macOS 13 or newer ». Sur Monterey 12, Colima n'est donc pas pris en charge. La FAQ ajoute qu'une compilation depuis les sources « peut être possible » sur un macOS plus ancien, avec Lima et QEMU comme dépendances. Pour un Mac sous Ventura 13, en revanche, Colima est la bonne voie, puisque Docker Desktop actuel ne s'y installe plus.

Homebrew sur un Mac ancien

Sur macOS, on installe en général Colima avec Homebrew. Le client docker s'installe à part. Le README de Colima indique pour cela brew install docker :

brew install colima docker
colima start
docker run --rm hello-world

D'après le README, le client docker fonctionne sans autre réglage après colima start. hello-world doit afficher Hello from Docker!.

Sur un Mac ancien, c'est Homebrew qui pose problème. En novembre 2024, un mainteneur de Homebrew écrivait que le projet ne peut compiler que sur les trois dernières versions de macOS. Au 20 octobre 2026, la page de la formule colima (version 0.10.3, qui dépend de lima 2.2.1) liste des paquets précompilés, appelés « bottles ». Pour Apple silicon, ils couvrent macOS 27, Tahoe, Sequoia et Sonoma. Pour Intel, seulement Sonoma. Il n'y a aucun bottle pour Ventura ni pour Monterey. Sans bottle, Homebrew doit compiler depuis les sources. Il faut alors les outils en ligne de commande de Xcode, et l'opération prend du temps.

La page des niveaux de support de Homebrew ajoute deux faits. Depuis septembre 2026, les Mac Intel sont au niveau 3 (non pris en charge), et Homebrew ne produit plus de nouveaux bottles pour Intel. Homebrew annonce aussi qu'il ne fonctionnera plus sur Intel en septembre 2027 ou plus tard. C'est une annonce, pas encore un fait.

Nous n'avons pas pu tester brew install colima sur macOS 12, et les sources ci-dessus laissent penser que cela ne marche pas. Si vous essayez, lisez la sortie jusqu'au bout avant de conclure.

Rester sur une version précise de Colima

Pour garder une version précise, prenez le binaire publié sur GitHub. La documentation d'installation de Colima donne la commande de téléchargement. Elle récupère la dernière version pour votre système et votre puce :

curl -LO https://github.com/abiosoft/colima/releases/latest/download/colima-$(uname)-$(uname -m)
curl -LO https://github.com/abiosoft/colima/releases/latest/download/colima-$(uname)-$(uname -m).sha256sum
shasum -a 256 -c colima-$(uname)-$(uname -m).sha256sum
sudo install colima-$(uname)-$(uname -m) /usr/local/bin/colima
colima version

shasum doit répondre OK. Pour rester sur une version précise, ouvrez la release voulue (par exemple v0.10.3) sur la page des releases de Colima. Copiez l'adresse exacte du fichier colima-Darwin-x86_64 ou colima-Darwin-arm64 et utilisez-la à la place de l'adresse en latest/download. Ce binaire seul ne suffit pas. Colima a besoin de Lima, que la formule Homebrew installe comme dépendance. Il vous faut donc aussi une installation de Lima qui fonctionne sur votre Mac.

Voie 3 : le client docker sur le Mac, le moteur sur un VPS Linux

Cette voie fonctionne sur le matériel le plus ancien, parce que le Mac ne fait plus tourner de machine virtuelle. Le Mac garde seulement le client docker. Le moteur Docker tourne sur un serveur Linux, et les deux communiquent par SSH (Secure Shell). Sur le Mac, il faut seulement le client ssh, déjà installé avec macOS, et une connexion par clé au serveur.

Le client docker statique sur le Mac

Docker publie des binaires statiques pour macOS sur download.docker.com/mac/static/stable/. Prenez le dossier x86_64 pour Intel et aarch64 pour Apple silicon. Au 20 octobre 2026, le fichier Intel le plus récent est docker-29.9.1.tgz, daté du 14 octobre 2026. Ce numéro va changer : ouvrez le dossier et prenez le fichier le plus récent. Les étapes suivent la documentation de Docker :

curl -fLO https://download.docker.com/mac/static/stable/x86_64/docker-29.9.1.tgz
tar xzvf docker-29.9.1.tgz
sudo xattr -rc docker
docker/docker --version
sudo mkdir -p /usr/local/bin
sudo cp docker/docker /usr/local/bin/

La documentation de Docker demande d'effacer les attributs étendus avec sudo xattr -rc docker pour que le binaire puisse se lancer. docker/docker --version doit afficher la version du client. Si la commande répond, le binaire fonctionne sur votre macOS.

Voyons maintenant ce que ce paquet ne contient pas. D'après Docker, le binaire macOS contient seulement le client : pas de moteur, pas de buildx, pas de docker compose. Docker estime que ces instructions servent surtout aux tests et recommande plutôt Docker Desktop. Pour Compose, le plus simple est de lancer docker compose sur le serveur lui-même, où le plugin est installé avec le moteur.

Le moteur sur le serveur

Sur le VPS, installez Docker Engine depuis le dépôt officiel. Au 20 octobre 2026, Docker prend en charge Ubuntu 26.10, 26.04, 24.04 et 22.04. Nous ne répétons pas les étapes ici. Suivez l'installation de Docker Engine et du plugin Compose sur un VPS Ubuntu, puis lisez ce qui change quand Docker tourne sur un VPS (mémoire, ports, redémarrage, disque plein).

L'utilisateur SSH doit pouvoir utiliser le socket Docker du serveur. Sur le serveur, ajoutez cet utilisateur au groupe docker, puis reconnectez-vous :

sudo usermod -aG docker $USER

Ce groupe donne des droits équivalents à root sur la machine. Ajoutez-y seulement le compte qui sert à Docker.

Le Mac doit se connecter sans mot de passe. Si ce n'est pas encore le cas, commencez par créer et gérer vos clés SSH. Vérifiez ensuite depuis le Mac, en remplaçant l'utilisateur et l'adresse par les vôtres :

ssh deploy@203.0.113.10 docker version

Cette commande doit afficher les sections Client et Server du serveur, sans demander de mot de passe. Le message Permission denied (publickey) veut dire que le serveur refuse votre clé. Le guide corriger l'erreur SSH Permission denied (publickey) passe en revue les causes possibles. Un permission denied sur /var/run/docker.sock veut dire que l'utilisateur n'est pas encore dans le groupe docker, ou que votre session SSH a été ouverte avant cet ajout.

Créer le contexte docker

Un contexte Docker est un nom qui pointe vers un moteur Docker. Créez-en un pour le VPS, puis activez-le :

docker context create mon-vps --docker "host=ssh://deploy@203.0.113.10"
docker context use mon-vps
docker version
docker run --rm hello-world

docker version doit maintenant afficher la section Server du VPS, et hello-world doit afficher Hello from Docker!. Pour revenir au contexte local, lancez docker context use default. Pour un seul terminal, export DOCKER_HOST=ssh://deploy@203.0.113.10 donne le même résultat.

Voici comment cela fonctionne. Quand une commande a besoin du moteur, le client lance ssh vers le serveur et y exécute docker system dial-stdio. Une commande purement locale n'ouvre pas de connexion : docker --version, par exemple, affiche seulement la version du client installé sur le Mac. D'après le code source du client, une adresse ssh:// exige Docker 18.09 ou plus récent sur le serveur. Sans autre réglage, chaque commande qui parle au moteur ouvre donc sa propre connexion SSH. Pour réutiliser la même connexion, Docker propose d'ajouter ce bloc dans ~/.ssh/config sur le Mac :

Host 203.0.113.10
  ControlMaster auto
  ControlPath ~/.ssh/control-%C
  ControlPersist yes

Les commandes suivantes répondent alors plus vite, car elles réutilisent la connexion déjà ouverte.

Et la licence ?

Le moteur installé sur le VPS est Docker Engine, qui est gratuit. Docker Desktop est gratuit pour les entreprises de moins de 250 salariés et de moins de 10 millions de dollars de chiffre d'affaires annuel. Tous les détails sont dans Docker est-il gratuit : Engine, Desktop et Hub.

Les surprises du premier jour avec un contexte SSH

Avec un contexte SSH, vous tapez la commande sur le Mac, mais tout se passe sur le serveur. Les trois tests ci-dessous le montrent. Lancez-les vous-même : nous n'avons pas de Mac relié à un serveur dans notre environnement de test.

Pourquoi localhost:8080 ne répond pas sur le Mac

L'option -p publie un port sur l'hôte Docker. Avec un contexte SSH, cet hôte est le serveur, pas le Mac.

docker run -d --name web -p 8080:80 nginx
curl -I http://localhost:8080
curl -I http://203.0.113.10:8080

Le premier curl échoue, car rien n'écoute sur le port 8080 du Mac. Le second peut répondre HTTP/1.1 200 OK, et c'est là le vrai problème. Sans adresse précise, Docker publie le port sur toutes les adresses du serveur (0.0.0.0 et [::]), donc sur Internet. Un pare-feu ufw ne vous protège pas forcément dans ce cas : lisez pourquoi Docker contourne UFW et comment corriger.

Pour corriger, publiez le port sur 127.0.0.1, puis ouvrez un tunnel SSH depuis le Mac.

docker rm -f web
docker run -d --name web -p 127.0.0.1:8080:80 nginx
ssh -N -L 8080:127.0.0.1:8080 deploy@203.0.113.10

Laissez le tunnel ouvert. Dans un autre terminal, curl -I http://localhost:8080 doit maintenant répondre HTTP/1.1 200 OK. Le port n'est plus accessible depuis Internet, car Docker ne l'écoute que sur l'adresse locale du serveur.

Pourquoi mon dossier monté est vide

La documentation de Docker le dit clairement : « Bind mounts are created to the Docker daemon host, not the client ». Un montage de dossier (bind mount) se fait sur le serveur. Vous ne pouvez pas monter un dossier du Mac dans un conteneur distant.

cd ~/projet
docker run --rm -v "$PWD":/app alpine ls -la /app

Le shell du Mac remplace $PWD par un chemin comme /Users/camille/projet. Ce chemin n'existe pas sur le serveur. Avec -v, Docker crée alors un dossier vide à cet endroit, sur le serveur, et ls n'affiche rien. Vérifiez-le :

ssh deploy@203.0.113.10 ls -ld /Users/camille/projet

Le dossier existe maintenant sur le serveur. Pour le supprimer, lancez sur le serveur sudo rmdir /Users/camille/projet /Users/camille /Users. Avec --mount type=bind,src="$PWD",dst=/app, Docker renvoie une erreur au lieu de créer le dossier, ce qui rend l'erreur visible tout de suite. La solution durable consiste à copier les fichiers sur le serveur, ou à utiliser un volume nommé. Le guide bind mount ou volume nommé explique la différence.

Pourquoi docker build est si lent

docker build -t monapp . envoie tout le dossier courant, appelé contexte de build, au constructeur d'images. Avec un contexte SSH, ce constructeur se trouve sur le serveur. Le dossier passe donc par votre connexion Internet. Un dossier node_modules ou .git de plusieurs centaines de mégaoctets ralentit chaque build. Avec BuildKit, la sortie affiche une étape transferring context avec la taille envoyée. Créez un fichier .dockerignore à la racine du projet :

.git
node_modules
*.log

L'image construite reste sur le serveur. docker images liste les images du serveur, pas celles du Mac. Le binaire statique ne contient pas buildx. Lisez donc les premières lignes affichées par docker build avant de conclure sur le constructeur utilisé.

Quelle voie choisir selon votre Mac ?

• Sonoma 14 ou plus récent : Docker Desktop actuel. Relisez les notes de version avant chaque mise à jour.
• Ventura 13.3 ou plus récent : Colima, ou Docker Desktop 4.48.0, qui contient le correctif de CVE-2025-9074.
• Ventura 13.0 à 13.2 : Colima. Docker Desktop s'arrête à 4.41.2, sans le correctif.
• Monterey 12 : la voie 3, avec le client sur le Mac et le moteur sur un VPS. Une ancienne Docker Desktop reste possible, mais sans le correctif.
• Big Sur, Catalina et plus ancien : la voie 3, si le client statique se lance sur votre version.

FAQ

Docker Desktop fonctionne-t-il sur macOS Monterey ?

Oui, mais seulement une ancienne version. Depuis Docker Desktop 4.42.0 (4 juin 2025), le minimum est Ventura 13.3. La dernière version installable sur Monterey 12 est donc 4.41.2. Les notes de version ne donnent pas de lien de téléchargement pour 4.41.2. La version la plus récente avec un lien est 4.34.3. Aucune de ces versions n'a le correctif de CVE-2025-9074, une faille critique corrigée dans 4.44.3.

Colima marche-t-il sur un Mac Intel sous Monterey ?

Pas officiellement. La FAQ de Colima indique que Colima exige macOS 13 ou plus récent. Homebrew ne publie pas de paquet précompilé de Colima pour Monterey. Depuis septembre 2026, les Mac Intel sont au niveau 3 (non pris en charge) chez Homebrew. Sur Monterey, le plus sûr est de garder le client docker sur le Mac et de faire tourner le moteur sur un serveur Linux, par SSH.

Pourquoi localhost ne répond pas alors que mon conteneur tourne ?

Avec un contexte Docker de type ssh://, l'option -p publie le port sur le serveur, pas sur le Mac. Par défaut, le port est ouvert sur toutes les adresses du serveur, donc sur Internet. Publiez-le sur 127.0.0.1 avec -p 127.0.0.1:8080:80, puis ouvrez un tunnel avec ssh -N -L 8080:127.0.0.1:8080 utilisateur@serveur.

Comment revenir au Docker local après avoir utilisé un contexte SSH ?

Lancez docker context use default. docker context ls liste vos contextes et indique celui qui est actif. Si vous avez défini DOCKER_HOST dans le terminal, cette variable passe avant le contexte. Lancez alors unset DOCKER_HOST.

Docker est-il gratuit sur Mac ?

Docker Engine est gratuit. Docker Desktop est gratuit pour les entreprises de moins de 250 salariés et de moins de 10 millions de dollars de chiffre d'affaires annuel. Au-delà, il faut un abonnement Docker Pro, Team ou Business. Colima et le client statique relié à un Docker Engine sur un VPS n'utilisent pas Docker Desktop.