Docker sur Windows : pourquoi vos volumes plombent vos performances (et comment WSL2 change la donne)

# DEBATE-028 : Docker sur Windows — pourquoi vos volumes plombent vos performances et comment WSL2 change la donne **Source :** published/blog/ARTICLE-028-migration-wsl2-docker-performance.md **Speakers :** Mathieu (homme), Vivienne (femme) **Duration :** ~10 minutes **Date :** 2026-03-06 **Note :** Termes anglophones conservés quand ils sont des termes techniques courants (Docker, bind-mount, inotify, hot reload). Ton neutre sans émotion. Les nombres sont écrits en toutes lettres. --- [Vivienne] Mathieu tu utilises Docker sur Windows depuis des années. Mais tu avais un problème avec les volumes. [Mathieu] Oui. Tous mes projets tournaient sur Windows avec Docker Compose. Bases de données et services d'embeddings et outils de monitoring. Tout était containerisé et ça fonctionnait. Sauf les volumes. [Vivienne] Qu'est-ce qui ne fonctionnait pas exactement. [Mathieu] Chaque fois que je montais un répertoire Windows dans un conteneur Linux les performances s'effondraient. On parle d'un facteur dix à vingt fois plus lent sur les opérations de lecture et d'écriture de fichiers. Du coup j'avais pris l'habitude de désactiver les volumes bind-mount et de copier les fichiers manuellement dans les conteneurs. [Vivienne] Pourquoi cette lenteur. [Mathieu] C'est une question d'architecture. Quand Docker tourne via Docker Desktop sur Windows les conteneurs Linux s'exécutent dans une machine virtuelle WSL2. Jusque-là pas de problème. Le problème apparaît quand tu montes un répertoire Windows dans un conteneur Linux. [Vivienne] Parce que les systèmes de fichiers sont différents. [Mathieu] Exactement. Le chemin traverse une frontière entre le système de fichiers NTFS côté Windows et ext4 côté Linux dans WSL2. Cette traduction passe par le protocole neuf P. C'est le protocole Plan neuf qui expose les fichiers Windows via le chemin slash mnt slash c. Chaque opération fichier fait un aller-retour NTFS vers neuf P vers ext4. [Vivienne] Et les benchmarks confirment cette dégradation. [Mathieu] Les chiffres de la communauté sont sans appel. La lecture séquentielle passe d'une milliseconde en natif à quinze à vingt millisecondes en cross-filesystem. L'écriture aléatoire passe de deux millisecondes à vingt-cinq à quarante millisecondes. Et le scan d'un répertoire node_modules passe de deux cents millisecondes à quatre à huit secondes. Soit vingt à quarante fois plus lent. [Vivienne] Et le hot reload. [Mathieu] Complètement cassé. Les événements inotify qui sont utilisés par webpack et Vite et nodemon pour détecter les changements de fichiers en temps réel ne traversent pas la frontière du système de fichiers. Tes outils de développement ne voient plus les modifications. [Vivienne] Docker est au courant de ce problème. [Mathieu] Oui c'est le problème numéro un identifié dans leur documentation officielle sur WSL2. La recommandation est littérale. Stockez le code source dans le système de fichiers Linux et pas dans le système de fichiers Windows. [Vivienne] Et comment tu as découvert la solution. [Mathieu] Un jour en pleine session de travail Claude mon assistant IA me dit pourquoi tu ne mets pas en place WSL2 Ubuntu sur ta machine. Tu pourras connecter tes répertoires aux conteneurs Docker en gardant les performances. Ma réaction a été de demander si c'était possible. [Vivienne] Quelle est la solution concrètement. [Mathieu] Au lieu de garder les projets sur C deux-points antislash Users et de les monter dans Docker tu les stockes directement dans le système de fichiers Linux de WSL2 sous slash home slash user slash projets. Docker accède alors à des fichiers qui vivent dans le même système de fichiers que les conteneurs. Plus aucune traduction entre systèmes de fichiers. [Vivienne] Comment se passe la migration en pratique. [Mathieu] Quatre étapes. D'abord tu installes WSL2 Ubuntu avec la commande wsl tiret tiret install tiret d Ubuntu. Ensuite tu actives systemd dans le fichier de configuration wsl point conf. Puis tu copies les projets depuis Windows vers le système de fichiers Linux avec la commande cp tiret r. Et enfin tu adaptes les fichiers Docker Compose si nécessaire. [Vivienne] Il faut modifier les fichiers Docker Compose. [Mathieu] Généralement non. Si tu utilises des chemins relatifs comme point slash data au lieu de chemins absolus Windows ça fonctionne directement. Les volumes pointent vers des chemins locaux dans le même système de fichiers. [Vivienne] Et pour les services comme Ollama. [Mathieu] Pour mes projets la migration incluait aussi Ollama pour le LLM local et pgvector pour la base vectorielle. Le point clé c'est que tu peux copier les modèles Ollama depuis Windows sans les retélécharger. Les binaires sont identiques. Ensuite tu configures un service systemd avec un port personnalisé. [Vivienne] Parlons des résultats. [Mathieu] J'ai benchmarké mes deux modèles LLM sur les mêmes tâches avant et après migration. Le GPU est identique c'est une RTX trois mille cinquante avec six gigaoctets. Seul l'OS change. [Vivienne] Et la latence initiale. [Mathieu] C'est l'amélioration la plus spectaculaire. Le temps avant le premier jeton sur une instruction courte passe de deux mille deux cent soixante-quinze millisecondes sur Windows à environ cent quatre-vingts millisecondes sur Ubuntu WSL2. Soit douze fois plus rapide. Sur un message de commit de dix-sept jetons on passe de deux mille sept cents millisecondes à deux cent vingt-sept millisecondes. Toujours douze fois plus rapide. [Vivienne] L'hypothèse pour expliquer ce gain. [Mathieu] Le stack TCP loopback de Windows introduit un overhead fixe d'environ deux secondes. Ce surcoût est absent avec le socket Linux natif dans WSL2. C'est un coût fixe qui pénalise toutes les requêtes courtes de manière disproportionnée. [Vivienne] Et le débit soutenu. [Mathieu] Le modèle qwen2 point 5 coder trois milliards de paramètres passe de quarante à cinquante-six jetons par seconde sur Windows à cinquante-sept à soixante-dix-huit jetons par seconde sur Ubuntu WSL2. Soit un gain de vingt-huit à quatre-vingts pourcent. Le modèle qwen3 nothink quatre milliards passe d'environ vingt et un jetons par seconde à environ trente-quatre. Soit plus soixante-deux pourcent. [Vivienne] Et l'impact sur le workflow quotidien. [Mathieu] Le smart commit qui utilise le LLM pour générer les messages de commit passe de deux virgule sept secondes à zéro virgule quatre seconde. C'est quasi-instantané. La revue de code IA passe de cinq virgule sept secondes à deux virgule neuf secondes soit divisé par deux. Le score qualité passe de deux virgule trois secondes à zéro virgule deux seconde. [Vivienne] Aucune régression observée. [Mathieu] Aucune. Le débit soutenu sur les générations longues de six cent quarante jetons reste identique ou supérieur. On gagne partout sans rien perdre. [Vivienne] Il y a des pièges à éviter pendant la migration. [Mathieu] Quatre principaux. Premier piège les binaires installés dans le répertoire local de l'utilisateur comme Claude Code ne sont pas accessibles via sudo à cause du secure path d'Ubuntu. La solution est de créer un lien symbolique dans slash usr slash local slash bin. [Vivienne] Le deuxième piège. [Mathieu] Les adresses IP hardcodées. Si tes scripts utilisaient l'IP gateway WSL2 pour communiquer entre Windows et WSL2 ces adresses ne fonctionnent plus quand le service tourne directement dans WSL2. Il faut remplacer par localhost. [Vivienne] Et l'espace disque. [Mathieu] Le système de fichiers WSL2 vit dans un fichier VHD sur le disque Windows. Il faut surveiller la taille et penser à redimensionner si nécessaire avec la commande wsl tiret tiret manage Ubuntu tiret tiret resize. [Vivienne] Dernier piège. [Mathieu] Les sauvegardes. Les fichiers dans WSL2 ne sont plus visibles directement dans l'explorateur Windows sauf via un chemin réseau spécial. Il faut adapter les stratégies de backup. [Vivienne] Le point le plus ironique de cette histoire. [Mathieu] C'est une IA qui m'a suggéré cette migration. Parfois les solutions les plus impactantes ne sont pas les plus complexes. Elles sont juste celles qu'on n'avait pas encore envisagées. [Vivienne] Le conseil final pour les développeurs sur Windows. [Mathieu] Si vous développez sur Windows avec Docker et que vous n'avez pas encore migré vos projets dans le système de fichiers WSL2 faites-le. C'est une journée de travail pour des mois de gain. Latence divisée par douze sur les opérations courtes. Débit en hausse de trente à quatre-vingts pourcent. Hot reload fonctionnel. Architecture simplifiée.