Docker Desktop Installation : Guide Installation 2026

Février dernier. Un client, agence de dev basée à Lyon, huit postes de développeurs, un serveur de test interne. Le mandat était simple sur le papier : standardiser l’environnement de conteneurisation sur toute l’équipe, avec une docker desktop installation homogène qui élimine le fameux « ça marche sur ma machine ». Trois semaines plus tard, le déploiement était terminé, mais pas du tout comme prévu au départ. Ce billet documente ce qui s’est réellement passé — diagnostics compris, y compris ceux qui n’ont mené nulle part.

Le contexte : pourquoi cette PME voulait standardiser Docker Desktop

L’agence tournait avec un mélange de configurations locales depuis des années. Certains développeurs sous WSL2, d’autres en natif macOS, un serveur de test sous Ubuntu 22.04 géré à la main avec des scripts shell datant d’une autre époque. Le responsable technique voulait une base commune : Docker Desktop partout où c’était pertinent, avec une politique de mise à jour centralisée et des images de référence versionnées dans un registre privé.

L’objectif affiché n’était pas seulement technique. C’était aussi une question de temps perdu — les onboardings de nouveaux développeurs prenaient en moyenne deux jours et demi, en grande partie à cause de divergences d’environnement. Sur le papier, la promesse de Docker Desktop (interface unifiée, gestion des ressources, intégration WSL2 pour les postes Windows) semblait répondre exactement à ce problème.

Étape 1 : audit du parc avant toute installation

Avant de toucher à quoi que ce soit, j’ai fait l’inventaire des huit machines. Résultat : cinq PC sous Windows 11 Pro, deux MacBook Pro sur puce M2, et un poste Windows 10 encore en attente de migration — celui-là allait poser problème, on y reviendra. Côté serveur, une VM Ubuntu 22.04 hébergée en interne, sans interface graphique, clairement hors périmètre pour Docker Desktop au sens propre (qui est un outil desktop, pas serveur) mais retenue quand même dans le brief initial du client, qui confondait Docker Engine et Docker Desktop.

Premier point de friction, donc, avant même de commencer : il a fallu clarifier avec le client que le serveur de test tournerait sous Docker Engine + Docker Compose en CLI pur, sans la couche Desktop, réservée aux postes de travail. Ce genre de malentendu revient plus souvent qu’on ne le pense dans les cahiers des charges rédigés par des non-techniciens, et il vaut mieux le lever au tout début plutôt qu’après coup.

Étape 2 : la procédure standard de docker desktop installation sous Windows

Sur les postes Windows 11 Pro, la procédure suivie a été la suivante :

Vérification de la virtualisation activée dans le BIOS (VT-x/AMD-V) — deux postes sur cinq l’avaient désactivée par défaut
Activation de WSL2 via wsl --install en PowerShell administrateur, puis redémarrage
Mise à jour du noyau Linux WSL2 via le paquet officiel Microsoft
Téléchargement de l’installeur Docker Desktop depuis le site officiel (version stable, pas la beta)
Installation avec l’option « Use WSL 2 instead of Hyper-V » cochée
Redémarrage, puis vérification via docker --version et docker run hello-world

Sur quatre des cinq postes Windows 11, cette séquence s’est déroulée sans accroc, en moins de vingt minutes chacune. Le cinquième poste a bloqué net à l’étape WSL2 : erreur « WSL 2 requires an update to its kernel component » qui persistait même après installation manuelle du paquet de mise à jour. Diagnostic : une stratégie de groupe (GPO) héritée d’un ancien déploiement Active Directory bloquait silencieusement l’exécution de certains composants Microsoft Store nécessaires à WSL2. Il a fallu contacter l’admin réseau du client pour lever la restriction — vingt-quatre heures de retard sur ce seul poste.

Le cas du poste Windows 10 : la vraie complication

Le poste sous Windows 10 (version 21H2, non mise à jour depuis un moment) a été le point noir du déploiement. Docker Desktop récent exige Windows 10 version 19044 ou supérieure avec le patch cumulatif à jour, et surtout une édition Pro, Enterprise ou Education — pas Home, faute de support Hyper-V natif complet. Ce poste était en édition Famille.

Deux options se présentaient : mettre à niveau la licence Windows vers Pro, ou faire tourner ce développeur sous une configuration alternative. Le client ne voulait pas payer de licence supplémentaire dans l’immédiat. On a donc opté pour une solution de contournement : installation de Docker via WSL2 en ligne de commande pure (sans la couche graphique Desktop), ce qui fonctionne même sous Windows Home moyennant activation manuelle de WSL2 par le Store. Ce n’est pas Docker Desktop à proprement parler — pas d’interface, pas de Dashboard, pas de gestion visuelle des conteneurs — mais cela couvrait le besoin fonctionnel minimal en attendant l’arbitrage budgétaire du client sur la licence.

Ce point mérite d’être dit clairement : la solution retenue sur ce poste n’était pas la solution idéale. C’était un compromis dicté par une contrainte budgétaire du client, pas par un choix technique. Je le signale parce que ce genre d’arbitrage revient régulièrement en contexte PME, et prétendre que chaque déploiement se termine par une installation parfaite et homogène serait mentir.

Étape 3 : la docker desktop installation sur macOS Apple Silicon

Les deux MacBook Pro M2 ont été nettement plus simples à traiter. Téléchargement du binaire ARM64 depuis le site officiel Docker (attention à ne pas prendre par erreur la version Intel, qui s’installe mais tourne ensuite en émulation Rosetta 2 avec une perte de performance notable sur les builds d’images lourdes), glisser-déposer dans Applications, lancement, acceptation des permissions système demandées par macOS (accès réseau, extension système à autoriser manuellement dans Réglages Système → Confidentialité et sécurité).

Seul point d’attention réel : sur un des deux Mac, Docker Desktop refusait de démarrer après l’installation, bloqué sur l’écran de chargement avec la baleine qui charge indéfiniment. Le journal système (accessible via le menu Docker → Troubleshoot → Get support bundle) a révélé un conflit avec une ancienne installation de Docker Toolbox jamais complètement désinstallée, qui laissait des fichiers de configuration réseau orphelins dans ~/.docker. Suppression manuelle du dossier, réinstallation propre, résolu en une dizaine de minutes une fois la cause identifiée — mais il a fallu près d’une heure de recherche avant de la trouver, entre les faux pistes (pare-feu, VPN d’entreprise, permissions macOS).

Étape 4 : configuration du serveur de test sous Ubuntu

Pour la VM Ubuntu 22.04, comme mentionné plus haut, pas de Docker Desktop mais Docker Engine en ligne de commande, installé via le dépôt APT officiel :

Ajout de la clé GPG officielle Docker et du dépôt dans les sources APT
apt update && apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin
Ajout de l’utilisateur de déploiement au groupe docker pour éviter le sudo systématique
Configuration du démon Docker pour limiter la taille des logs de conteneurs (fichier /etc/docker/daemon.json), sans quoi les logs peuvent saturer le disque sur un serveur de test qui tourne en continu

Cette partie s’est déroulée sans incident majeur, en dehors d’un premier oubli — la limitation des logs — qui a été corrigée après coup une fois qu’on a remarqué que l’espace disque de la VM chutait plus vite que prévu sur les premiers jours de test.

Bilan du déploiement et ce qu’on en retient

Sur les huit postes de développeurs, sept tournent aujourd’hui sous une docker desktop installation standard et à jour. Le huitième, sous Windows 10 Famille, reste sur la solution de contournement WSL2 en ligne de commande, en attendant que le client tranche sur la licence. Ce n’est pas la fin d’histoire idéale qu’on aimerait raconter, mais c’est la réalité du terrain : dans un contexte PME, les contraintes budgétaires et les parcs hétérogènes viennent régulièrement complexifier ce qui, sur le papier, ressemble à une simple installation de vingt minutes.

Le temps d’onboarding moyen d’un nouveau développeur, mesuré six semaines après le déploiement, est passé de deux jours et demi à environ une demi-journée — l’objectif initial du client a donc été globalement atteint, malgré les frictions rencontrées en cours de route. Le point de vigilance principal à retenir pour toute PME qui envisage une démarche similaire : faire l’audit du parc matériel et logiciel avant de fixer un calendrier de déploiement, pas après. La GPO bloquante et l’édition Windows Home auraient pu être identifiées en amont avec un simple inventaire, ce qui aurait évité deux jours de retard cumulés sur le projet.

Points de vigilance pour une installation en environnement professionnel

Quelques éléments à vérifier systématiquement avant de lancer une campagne de docker desktop installation à l’échelle d’une équipe :

Vérifier l’édition Windows de chaque poste (Home ne supporte pas Docker Desktop complet) avant toute planification. Contrôler l’état des stratégies de groupe sur les parcs gérés par Active Directory, qui peuvent bloquer silencieusement WSL2 ou le Microsoft Store. Sur macOS, s’assurer qu’aucune trace d’une ancienne installation Docker Toolbox ou Docker Machine ne traîne dans le dossier utilisateur avant d’installer la version actuelle. Et sur les serveurs, ne pas confondre Docker Desktop (outil de poste de travail) avec Docker Engine (démon serveur) — une confusion qui, dans ce cas précis, aurait pu faire perdre une journée entière si elle n’avait pas été clarifiée dès le brief initial.

J’en parle plus en détail dans un article sur commandes curl pour du débogage réseau.

Sur un terrain proche, je détaille aussi comment forcer une installation Windows 11 sur du matériel non certifié.

Pour approfondir, consultez la documentation de Docker Desktop ainsi que la documentation de Microsoft sur WSL2.