Choisir une distribution WSL qui ne vous embêtera pas (Ubuntu vs Debian et autres)

Ce que vous choisissez vraiment quand vous « choisissez une distro »

Sur du métal nu, la sélection d’une distribution peut sembler idéologique. Sur WSL, c’est plutôt comme choisir l’ensemble de valeurs par défaut sous lequel vous voulez vivre pendant que Windows tient le volant en silence.

Vous choisissez :

• Cadence de sortie et rayon d’impact des mises à jour. À quelle fréquence vous devrez gérer des changements d’outillage versus la rapidité à recevoir des correctifs de sécurité et de nouvelles fonctionnalités du compilateur/runtime.
• Friction de l’écosystème des paquets. Si vos outils quotidiens (Python, Node, Go, Rust, OpenJDK, clients PostgreSQL, CLI Azure/AWS) sont des citoyens de première classe ou des exceptions constantes.
• Compatibilité « ça marche sur ma machine » dans la communauté. Si tout le monde dans votre organisation utilise Ubuntu, être la seule personne sur Fedora sous WSL revient à vous imposer votre propre planning d’astreinte.
• Posture de sécurité par défaut. Attentes AppArmor vs SELinux, configuration de sudo, gestion des clés SSH et démarrage des services.
• À quel point il est douloureux de déboguer. Le volume de réponses sur les wikis internes et sur Internet compte. Vous ne marquez pas de points pour l’originalité à 2h du matin.

Une citation fiabilité à tatouer sur votre tableau de sprint

Idée paraphrasée (John Ousterhout) : « La complexité est la cause première de la plupart des problèmes logiciels. »

WSL est déjà une couche superposée. Votre choix de distro doit réduire la complexité, pas ajouter un nouveau trouble de la personnalité.

Faits intéressants et contexte historique (les éléments qui façonnent les défauts d’aujourd’hui)

1. WSL 1 (2016) n’était pas une VM. Il traduisait les appels système Linux en appels Windows NT ; excellent pour certains outils, gênant pour d’autres.
2. WSL 2 (2019) est passé à un vrai noyau Linux dans une VM légère. C’est pourquoi Docker et les vraies fonctionnalités noyau sont devenus sensés.
3. Ubuntu est devenu le choix par défaut de facto tôt. Microsoft a travaillé étroitement avec Canonical ; l’inertie est un puissant outil devops.
4. Le support de systemd dans WSL est arrivé bien plus tard que ce que demandaient les utilisateurs. Pendant des années, les distributions ont dû simuler la gestion des services ou vous deviez lancer les démons manuellement.
5. La séparation des systèmes de fichiers dans WSL est fondamentale. Les fichiers côté Linux (ext4 dans la VM) se comportent différemment des fichiers montés côté Windows sous /mnt/c.
6. La branche « stable » de Debian vise la prévisibilité plutôt que la nouveauté. Cette philosophie colle bien à la reproductibilité en entreprise.
7. Fedora est souvent en avant-poste pour beaucoup de technologies Linux. Elle reçoit fréquemment de nouveaux outils plus tôt — excellent pour l’expérimentation, épicé pour le contrôle des changements.
8. La musl libc d’Alpine est une vraie frontière de compatibilité. Petite et rapide, mais tout n’attend pas musl dans les environnements dev.
9. Kali est conçue pour des flux de travail de tests de sécurité. L’utiliser comme poste de dev quotidien revient à amener une tronçonneuse pour couper du pain : possible, mais ça met tout le monde mal à l’aise.

Réalités WSL qui changent la donne

Avant de comparer Ubuntu vs Debian, comprenez les règles du jeu. WSL n’est pas tant « Linux sur Windows » que « Linux à côté de Windows, partageant quelques organes. » Ces organes partagés sont la source de la plupart des ennuis.

Le problème des deux systèmes de fichiers (et pourquoi il domine les performances)

Dans WSL2, votre système de fichiers racine Linux vit sur un disque virtuel ext4 (un VHDX). Ce chemin est rapide pour les appels système Linux. Les fichiers Windows montés sur /mnt/c sont pratiques, mais franchir cette frontière coûte cher. Beaucoup.

Si vous faites du I/O intensif (git status dans des gros dépôts, installations node_modules, création d’environnements virtuels Python) sur /mnt/c, vous allez accuser votre distribution. Mauvais coupable. Votre goulot d’étranglement est la frontière des systèmes de fichiers.

Le réseau n’est pas « juste le réseau Linux »

WSL2 utilise une pile réseau virtualisée. Ça fonctionne la plupart du temps. Quand ça ne fonctionne pas, le mode de défaillance ressemble à « le DNS Linux est cassé » ou « mon proxy me déteste ». Les correctifs impliquent souvent des réglages côté Windows et un redémarrage de WSL, pas un changement de distro.

Le noyau est majoritairement géré par Microsoft

Contrairement à une installation Linux traditionnelle, vos mises à jour du noyau sont liées aux mises à jour WSL et Windows, pas aux paquets noyau de votre distro. Cela réduit une dimension de différence entre distributions — mais augmente l’importance de la compatibilité de l’espace utilisateur et des outils.

WSLg et les applications GUI sont un axe séparé

Exécuter des applications GUI Linux (WSLg) fonctionne sur les distributions, mais l’expérience prête à l’emploi varie : paquets, polices, bibliothèques GPU et dépendances de type bureau peuvent être plus lisses sur Ubuntu que sur des distributions minimales.

Blague courte #1 : Choisir une distro pour WSL d’après l’esthétique du fond d’écran, c’est audacieux. C’est comme choisir une base de données parce que le logo est mignon.

Choix rapides (opinionnés) : quoi installer selon les usages courants

Si vous voulez le moins de problèmes : Ubuntu LTS

Choisissez Ubuntu LTS si vous voulez une compatibilité maximale avec les tutoriels, les images d’entreprise, les dépôts tiers et vos coéquipiers. C’est le choix par défaut parce que ça marche, pas parce que c’est cool.

Choisir : Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS (selon ce que votre organisation supporte).

Si vous voulez minimal et prévisible : Debian stable

Choisissez Debian stable si vous voulez moins de « surprises » et que vous n’avez pas besoin des compilateurs les plus récents par défaut. C’est plus lent dans les évolutions, ce qui est un atout quand vous tentez d’aligner dev et CI.

Si vous vivez dans les conteneurs et voulez les outils les plus récents : Fedora (avec prudence)

Fedora est idéale si vous testez des toolchains modernes, des fonctionnalités proches du noyau (même si le noyau WSL est fixe), ou si vous aimez des versions plus récentes des langages. Mais les mises à jour de Fedora ne sont pas timides. Si vous détestez le changement, Fedora vous retrouvera.

Si vous pensez qu’Alpine sera « petit et rapide » : réfléchissez

Le minimalisme d’Alpine est réel, mais les environnements à base de musl peuvent créer des nids de compatibilité dans les workflows de dev. Alpine brille à l’intérieur des conteneurs. Comme distribution WSL principale, c’est souvent une taxe imprévue.

Si vous faites de la formation en sécurité : Kali (pour cet usage uniquement)

Kali n’est pas un « meilleur Linux ». C’est une boîte à outils spécialisée. Utilisez-la comme distribution additionnelle que vous lancez quand nécessaire, pas comme pilote quotidien.

Ubuntu sur WSL : le choix par défaut pour une raison

Ubuntu sur WSL est le chemin de moindre résistance, ce qui en ingénierie de production est un compliment. La plupart des instructions des fournisseurs supposent Ubuntu. Beaucoup de runbooks internes aussi. Et si vous avez besoin d’aide d’un collègue, « je suis sur Ubuntu » réduit la charge cognitive.

Ce qu’Ubuntu fait bien sur WSL

• La cadence LTS convient à la vie en entreprise. Vous pouvez rester stable pendant des années tout en recevant des correctifs de sécurité.
• Disponibilité des toolchains. PPAs, dépôts fournisseurs et paquets tendent à exister et être testés.
• Ergonomie par défaut meilleure. Paquets de base raisonnables, comportement prévisible et beaucoup de « ce tutoriel marche directement ».
• Fort partage d’expérience WSL. Si une solution spécifique à WSL existe, quelqu’un l’a probablement écrite pour Ubuntu en premier.

Ce qu’Ubuntu fait et qui agace certains

• Snap. Sur les machines Linux classiques, Snap est une guerre religieuse. Sur WSL, c’est surtout une question pratique : avez-vous besoin d’apps packagées en snap, et snapd fonctionne-t-il bien sous WSL + systemd ? Parfois oui, parfois friction.
• Plus de « choses » par défaut. Si vous voulez un environnement très léger, Ubuntu peut sembler lourd comparé à une install minimale de Debian.
• Les versions non-LTS sont source de changements fréquents. Si vous prenez une release non-LTS pour des paquets plus récents, attendez-vous à des mises à niveau plus fréquentes et à des régressions occasionnelles.

Quand je recommande Ubuntu sans débat

Équipes. Environnements de dev partagés. Ordinateurs portables d’entreprise. Parité CI avec des runners Ubuntu. Nouveaux arrivants. Personnes qui veulent travailler, pas faire de la curation.

Debian sur WSL : ennuyeuse, légère et généralement correcte

Debian stable est l’ami qui arrive à l’heure, ne parle pas de cryptomonnaie et laisse la cuisine plus propre qu’il ne l’a trouvée. Pour WSL, c’est un argument solide.

Ce que Debian fait bien sur WSL

• Mises à niveau prévisibles. Stable reste stable. Vous recevez des correctifs de sécurité, mais le socle ne change pas sous vos pieds.
• Minimalisme sans bizarrerie. Vous pouvez garder votre environnement petit tout en restant compatible avec la plupart des attentes Linux.
• Excellente discipline de packaging. Les normes de packaging de Debian tendent à réduire les comportements « mystères ».

Vrais compromis de Debian

• Defaults plus anciens. Cela peut signifier Python, Node, GCC/Clang, OpenSSL plus anciens. Vous pouvez utiliser les backports ou des installateurs spécifiques aux langages, mais cela demande du travail.
• Certaines scripts fournisseurs supposent Ubuntu. Ils peuvent vérifier lsb_release et refuser de s’exécuter, ou référencer des paquets spécifiques à Ubuntu.

Quand Debian est le meilleur choix

Quand vous tenez à la reproductibilité, quand vous maintenez des outils internes de longue durée, quand vous voulez moins de surprises, et quand vous êtes prêt à installer explicitement des runtimes plus récents.

Autres (Fedora, openSUSE, Alpine, Kali) : quand c’est génial et quand c’est un piège

Fedora : moderne, rapide dans ses évolutions, parfois trop honnête

Fedora est excellente si vous voulez des compilateurs actuels, des runtimes plus récents et une culture distro qui livre rapidement des technologies modernes. Sur WSL, cela peut booster la productivité — jusqu’à ce qu’une mise à jour majeure arrive et que votre outillage décide de rejouer un effondrement de graphe de dépendances.

Fedora sur WSL est un bon choix pour les utilisateurs avancés à l’aise avec l’idée de traiter leur environnement de dev comme du bétail et non comme un animal de compagnie : exporter, détruire, réimporter, poursuivre.

openSUSE (Leap vs Tumbleweed) : l’option sous-estimée

openSUSE est souvent solide, surtout si votre organisation utilise SUSE en production. Leap est la ligne stable ; Tumbleweed est rolling. Sur WSL, les rolling releases peuvent être amusantes jusqu’à ce qu’elles deviennent votre problème.

Alpine : géniale en conteneurs, pas toujours idéale comme poste de travail

La musl libc d’Alpine et son userland centré sur busybox sont excellents pour des images conteneur minimales. Comme distribution WSL pour du dev général, vous rencontrerez des cas limites : binaires précompilés qui supposent glibc, scripts de build qui supposent le comportement des coreutils GNU, et des collègues incapables de reproduire votre environnement sans aussi adopter Alpine.

Kali : boîte à outils spécialisée, pas un mode de vie

Kali est excellente pour son usage prévu. Installez-la comme distro WSL additionnelle pour le travail de sécurité. Gardez votre dev quotidien sur Ubuntu ou Debian.

Blague courte #2 : Utiliser une rolling release sur votre portable de travail est excitant. Tout comme jongler avec des couteaux — mieux en loisir qu’en exigence professionnelle.

Systemd et services : la section « ai-je besoin de ça ? »

Les distributions Linux modernes supposent systemd. Beaucoup de workflows dev supposent des services : démon Docker (si vous utilisez Docker-in-WSL), PostgreSQL, Redis, ssh-agent, tâches de type cron. Historiquement, WSL rendait cela gênant. Aujourd’hui, systemd peut être activé, mais la décision doit rester intentionnelle.

Activez systemd si :

• Vous avez besoin que des services démarrent de façon fiable au lancement de WSL.
• Vous utilisez des unités de service, des timers ou journalctl pour le débogage.
• Vous voulez la parité avec des serveurs Linux où systemd est la norme.

Sauter systemd si :

• Votre distro WSL sert surtout d’outils CLI et de builds.
• Vous exécutez des services dans des conteneurs (intégration Docker Desktop) ou sur des hôtes distants.
• Vous souhaitez réduire la surface d’attaque des tickets « pourquoi mon WSL démarre lentement ? ».

Performance de système de fichiers et stockage : où WSL pose vraiment problème

Je le dis franchement : la plupart des plaintes sur les « performances de distro WSL » sont des erreurs de disposition du stockage.

Règle d’or

Gardez le code que vous compilez et testez à l’intérieur du système de fichiers Linux (quelque part sous votre dossier home WSL), pas sur /mnt/c. Utilisez les montages Windows pour le partage de fichiers, l’édition légère et la commodité — pas pour les opérations intensives.

Pourquoi c’est important (pratique)

• Opérations Git touchent énormément de petits fichiers. Franchir la frontière des systèmes de fichiers ralentit tout.
• Node/npm/pnpm créent et parcourent d’énormes arbres de répertoires.
• Environnements virtuels Python/pip sont intensifs en I/O de petits fichiers.
• Serveurs de langage indexent tout ; ils amplifient la latence de stockage.

Où mettre quoi

• Placez les dépôts ici : ~/src à l’intérieur de WSL.
• Placez les caches ici : les répertoires de cache Linux par défaut conviennent ; ne les redirigez pas vers Windows.
• Partagez avec Windows via : le chemin \\wsl$ depuis l’Explorateur Windows (fonctionne bien pour l’édition avec des outils Windows).

Tâches pratiques : commandes qui répondent à de vraies questions

Voici les vérifications que j’exécute réellement quand quelqu’un dit « WSL est lent » ou « cette distro est étrange ». Chaque tâche inclut : la commande, ce que signifient les résultats, et quelle décision prendre.

Tâche 1 : Confirmer la version WSL (1 vs 2) et la liste des distributions

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-24.04    Running         2
  Debian          Stopped         2

Sens : VERSION 2 signifie une vraie VM avec noyau Linux. VERSION 1 signifie traduction d’appels système (performances et compatibilité différentes).

Décision : Si vous êtes sur WSL1 et utilisez Docker, des systèmes de fichiers modernes ou attendez des fonctionnalités noyau, migrez vers WSL2. Si votre douleur principale est la performance de /mnt/c, WSL2 aide généralement — mais placez correctement vos fichiers.

Tâche 2 : Vérifier la release de la distro et la fenêtre de support

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04 LTS (Noble Numbat)"
ID=ubuntu

Sens : Vous êtes sur une release spécifique ; LTS implique un support plus long et moins de changements disruptifs.

Décision : Pour la cohérence en entreprise/équipe dev, préférez LTS (Ubuntu) ou stable (Debian). Si vous êtes sur une release en fin de vie, prévoyez une exportation/import pour montée de version plutôt que « juste continuer à patcher ».

Tâche 3 : Vérifier si systemd est activé (et si c’est le bazar)

cr0x@server:~$ ps -p 1 -o comm=
systemd

Sens : PID 1 est systemd. Si ça affiche autre chose (ou une erreur), systemd n’est pas votre init.

Décision : Si vous dépendez de services, activez systemd. Sinon, désactivez-le pour réduire les éléments en mouvement — surtout sur des builds d’entreprise anciens où les mises à jour WSL traînent.

Tâche 4 : Vérifier si vous travaillez sur un stockage monté Windows

cr0x@server:~$ pwd
/mnt/c/Users/cr0x/source/big-repo

Sens : Vous êtes dans le système de fichiers Windows.

Décision : Si c’est un dépôt de build/test, déplacez-le vers ~/src et accédez-y depuis Windows via \\wsl$. Attendez-vous à d’importants gains pour les workflows lourds en node/python/git.

Tâche 5 : Mesurer la douleur de la frontière système de fichiers avec une tempête de fichiers simple

cr0x@server:~$ cd ~ && mkdir -p /tmp/io-test && cd /tmp/io-test
cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do echo x > f.$i; done'
real    0m1.8s
user    0m0.5s
sys     0m1.2s

Sens : C’est sur le système de fichiers Linux (plutôt rapide). Répétez sous /mnt/c et comparez.

Décision : Si le même test est dramatiquement plus lent sur /mnt/c, arrêtez d’accuser Ubuntu vs Debian. Corrigez l’emplacement des fichiers, puis réévaluez.

Tâche 6 : Vérifier l’utilisation du disque dans le monde VHDX WSL

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb       100G   41G   55G  43% /

Sens : Votre système de fichiers Linux a de la marge (ou pas).

Décision : Si vous êtes au-dessus d’environ 85% d’utilisation, attendez-vous à des comportements étranges : échecs d’installation de paquets, builds ratés, dégradation des performances. Nettoyez les caches, supprimez les conteneurs inutiles, ou étendez/déplacez la distro.

Tâche 7 : Identifier rapidement vos plus gros consommateurs d’espace

cr0x@server:~$ sudo du -xhd1 /home/cr0x | sort -h
2.1G    /home/cr0x/.cache
6.8G    /home/cr0x/.local
14G     /home/cr0x/src
23G     /home/cr0x

Sens : -x reste sur un seul système de fichiers ; vous voyez les coûts d’espace réels à l’intérieur de la distro.

Décision : Si les caches sont énormes, supprimez-les (pip/npm). Si les dépôts sont volumineux, envisagez des clones peu profonds pour des gros dépôts fournisseurs ou utilisez sparse checkout.

Tâche 8 : Vérifier la pression mémoire et le comportement de swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.1Gi       0.6Gi       0.2Gi       1.0Gi       1.1Gi
Swap:          2.0Gi       1.4Gi       0.6Gi

Sens : Vous échangez sur disque. Ça peut rendre « WSL est lent » très personnel.

Décision : Réduisez les builds parallèles, augmentez les limites mémoire WSL, ou arrêtez d’exécuter des services lourds localement. Le choix de la distro ne résoudra pas la faim mémoire.

Tâche 9 : Confirmer le comportement DNS dans WSL (échec courant en entreprise)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Sens : Les serveurs DNS sont configurés ; s’ils sont incorrects ou manquants, la résolution de noms sera instable.

Décision : Si le DNS pointe vers des serveurs inaccessibles ou une interface VPN captive, corrigez la politique VPN/DNS côté Windows, ou surchargez prudemment la génération de resolv.conf de WSL.

Tâche 10 : Valider l’environnement proxy (parce que les entreprises adorent les proxies)

cr0x@server:~$ env | grep -i proxy
HTTP_PROXY=http://proxy.corp:8080
HTTPS_PROXY=http://proxy.corp:8080
NO_PROXY=localhost,127.0.0.1,.corp

Sens : Votre shell a des variables proxy. Des outils comme apt, curl, npm peuvent ou non les respecter uniformément.

Décision : Si les téléchargements échouent, standardisez la configuration proxy à un seul niveau (shell + config apt + config git) et gardez NO_PROXY correct pour les services internes.

Tâche 11 : Vérifier la santé du gestionnaire de paquets et les contentions de verrou

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 1s (135 kB/s)
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Sens : apt fonctionne et les dépôts sont accessibles.

Décision : Si vous voyez des erreurs de verrou, un job apt en arrière-plan est en cours (ou bloqué). Réparez ça avant de « déboguer WSL ». Si les dépôts sont bloqués, vous avez un problème de proxy/DNS/certificat — pas de distro.

Tâche 12 : Vérifier glibc vs musl (piège de compatibilité Alpine)

cr0x@server:~$ ldd --version
ldd (Ubuntu GLIBC 2.39-0ubuntu8) 2.39
Copyright (C) 2024 Free Software Foundation, Inc.

Sens : Vous êtes sur glibc. Sur Alpine, ce serait musl, et certains binaires ne fonctionneront pas.

Décision : Si votre workflow nécessite des binaires fournisseurs (CLI cloud, agents propriétaires, certains toolchains), préférez des distributions glibc (Ubuntu/Debian/Fedora/openSUSE).

Tâche 13 : Confirmer où est votre git et si les fins de ligne vont vous embêter

cr0x@server:~$ git config --global --get core.autocrlf
input

Sens : Vous êtes configuré pour convertir CRLF uniquement à la validation, réglage courant et sûr quand on mélange Windows et outils Linux.

Décision : Si vous voyez des diffs étranges ou des scripts shell échouant avec /bin/bash^M, corrigez autocrlf et imposer un .gitattributes. Ce n’est pas la faute d’Ubuntu.

Tâche 14 : Vérifier la stratégie Docker (intégration Desktop vs Docker-in-WSL)

cr0x@server:~$ docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT               ERROR
default             Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux *     Docker Desktop                            unix:///home/cr0x/.docker/desktop/docker.sock

Sens : Vous avez des contexts ; desktop-linux suggère l’intégration Docker Desktop.

Décision : Pour la plupart des devs, l’intégration Docker Desktop réduit la gestion du démon. Si vous avez besoin d’un contrôle Linux complet ou êtes sur des machines restreintes, Docker-in-WSL peut marcher — mais prévoyez plus de gestion de services.

Tâche 15 : Exporter une distro avant de « juste mettre à niveau »

cr0x@server:~$ wsl.exe --export Ubuntu-24.04 C:\Users\cr0x\backup\ubuntu24.tar
Export in progress, this may take a few minutes.
The operation completed successfully.

Sens : Vous avez une sauvegarde portable que vous pouvez réimporter.

Décision : Exportezz toujours avant des changements majeurs. C’est la différence entre « oups » et « restauration en 5 minutes ».

Playbook de diagnostic rapide (premier/deuxième/troisième)

Quand WSL semble lent ou cassé, vous avez besoin d’un ordre de triage. Voici celui qui trouve le goulot rapidement, sans transformer votre portable en foire scientifique.

Premier : identifier la classe de problème (I/O, CPU, mémoire, réseau)

• Suspicion I/O : commandes git lentes, installations lentes, indexation lente par les serveurs de langage, nombreux petits fichiers. Vérifiez si vous êtes sous /mnt/c.
• Suspicion CPU : compilations lentes mais le disque semble OK. Vérifiez la charge et les limites CPU.
• Suspicion mémoire : tout est lent par intermittence, bruit du ventilateur, swap. Vérifiez free -h.
• Suspicion réseau : apt/npm/curl échoue, timeouts DNS, erreurs proxy. Vérifiez le DNS et les variables proxy.

Deuxième : confirmer que le substrat WSL est sain

• Vérifiez que vous êtes en WSL2, pas WSL1.
• Vérifiez l’utilisation du disque (df -h) et les consommateurs d’espace (du).
• Si tout semble « hanté », redémarrez WSL depuis Windows : wsl.exe --shutdown et rouvrez.

Troisième : seulement alors débattez du choix de la distro

Si la douleur de performance provient de la frontière système de fichiers, de la pression mémoire ou de la politique VPN/proxy Windows, passer d’Ubuntu à Debian ne vous sauvera pas. Ça change simplement la forme du même feu.

Changez de distro quand :

• Vous avez besoin de paquets plus anciens/plus stables (Debian stable) pour correspondre à la production.
• Vous avez besoin d’un meilleur support fournisseur et des tutoriels courants (Ubuntu LTS).
• Vous avez besoin d’un userland très récent (Fedora/openSUSE Tumbleweed) et acceptez le churn.

Erreurs fréquentes : symptômes → cause → correction

1) « Git est insupportablement lent dans WSL »

Symptômes : git status prend des secondes ; npm install prend une éternité ; le CPU est majoritairement inactif.

Cause : Le dépôt est sur /mnt/c (montage système de fichiers Windows).

Correction : Déplacez le dépôt vers ~/src à l’intérieur de WSL. Accédez-y depuis Windows via \\wsl$. Retestez.

2) « apt update échoue aléatoirement au boulot »

Symptômes : Timeouts, erreurs TLS, « Temporary failure resolving », uniquement sur VPN ou uniquement hors VPN.

Cause : Comportement proxy/DNS corporate fractionné ; génération automatique de resolv.conf par WSL en conflit avec des adaptateurs VPN.

Correction : Standardisez les variables d’environnement proxy ; vérifiez les serveurs DNS dans WSL ; si nécessaire, désactivez la génération automatique de resolv.conf et gérez-le intentionnellement (avec un runbook interne, pas des approximations).

3) « Le service ne démarre pas / systemctl ne marche pas »

Symptômes : erreurs systemctl, démons qui meurent après fermeture du terminal.

Cause : systemd non activé, ou vous attendez des services en arrière-plan sans système d’init.

Correction : Activez systemd si vous en avez besoin ; sinon lancez les services via Docker Desktop ou des scripts explicites.

4) « Les builds Docker sont lents et bizarres »

Symptômes : Les builds prennent des âges ; la détection de changement de fichiers est floue ; les volumes se comportent de façon étrange.

Cause : Mélange du système de fichiers Windows, du système de fichiers WSL et des contextes Docker ; les montages bind à travers la frontière sont lents.

Correction : Gardez le contexte de build à l’intérieur du système de fichiers WSL ; choisissez une stratégie Docker et appliquez-la (l’intégration Desktop est généralement la plus simple).

5) « Après une mise à jour, Python/Node ont cassé »

Symptômes : Mismatch des toolchains, bibliothèques manquantes, wheels pip qui échouent, drame node-gyp.

Cause : Mises à jour d’une distro non-LTS ou mélange incorrect de paquets système avec des gestionnaires de versions de langages.

Correction : Verrouillez les versions et utilisez un gestionnaire de versions cohérent (pyenv/nvm/asdf), ou restez sur Ubuntu LTS/Debian stable et mettez à niveau volontairement après export.

6) « WSL me mange de l’espace disque »

Symptômes : Le disque Windows se remplit ; WSL rapporte une utilisation modérée ; les chiffres ne correspondent pas.

Cause : Le VHDX grandit et ne se réduit pas toujours automatiquement ; caches et couches de conteneurs s’accumulent.

Correction : Purgez caches et conteneurs ; exportez/importez pour compacter si nécessaire ; évitez de stocker des artefacts géants dans WSL si la politique disque Windows est serrée.

Listes de contrôle / plan pas à pas

Checklist A : Choisir votre distro en 10 minutes

1. Rejoignez-vous une équipe existante ? Utilisez ce qu’ils utilisent sauf raison forte. Généralement Ubuntu LTS.
2. Besoin de compatibilité maximale tutoriels/fournisseurs ? Ubuntu LTS.
3. Besoin de « ne changez pas ma base » stabilité ? Debian stable.
4. Besoin du userland le plus récent et vous acceptez le churn ? Fedora ou openSUSE Tumbleweed.
5. Besoin d’une boîte à outils pour tests de sécurité ? Kali comme distro additionnelle, pas principale.
6. Vous pensez vouloir Alpine ? Mettez Alpine en conteneur. Utilisez Ubuntu/Debian comme distro hôte sauf si vous aimez déboguer les problèmes libc.

Checklist B : Configurer WSL pour qu’il reste rapide

1. Installez WSL2 et vérifiez avec wsl.exe -l -v.
2. Créez ~/src et clonez vos dépôts là.
3. Accédez aux fichiers depuis Windows via \\wsl$ au lieu de travailler sous /mnt/c.
4. Décidez du systemd : activez uniquement si vous avez besoin de services.
5. Choisissez une approche Docker et standardisez (généralement intégration Docker Desktop).
6. Exportez la distro avant des mises à niveau majeures.

Checklist C : Mettre à niveau sans drama

1. Exporter : wsl.exe --export <Distro> C:\path\backup.tar.
2. Documenter vos paquets indispensables : compilateurs, runtimes, CLI clés.
3. Si votre environnement est fragile, envisagez une reconstruction propre et restaurez seulement dotfiles et clés SSH.
4. Réimportez sous un nouveau nom de distro si vous voulez une voie de retour propre.

Trois mini-récits d’entreprise du terrain

Mini-récit #1 : L’incident causé par une mauvaise hypothèse (édition frontière système de fichiers)

Une équipe produit avait un environnement dev basé sur WSL et un grand monorepo. Les nouveaux développeurs se voyaient dire, à la légère, de « simplement cloner le dépôt dans votre dossier Windows et d’utiliser WSL pour les builds. » Ça semblait raisonnable : les outils Windows peuvent voir les fichiers, les outils Linux peuvent les compiler. La commodité l’emporte, non ?

En un mois, l’équipe a commencé à voir des échecs de tests intermittents et des timeouts « aléatoires ». Le CI était OK. Seuls les portables fondaient. Le principal symptôme était un scan de fichiers lent : le système de build et les serveurs de langage crawlaient, puis les devs tuaient les processus, puis les builds incrémentaux se perdaient sur ce qui avait changé.

Quelqu’un a enfin profilé ça de manière peu glamour : mesurer le temps de création de fichiers et git status à deux endroits. Système de fichiers Linux : assez rapide. /mnt/c : douloureusement plus lent et instable. Les « timeouts aléatoires » n’étaient pas aléatoires. C’était l’outil attendant des opérations de fichier qui franchissaient la frontière Windows/Linux des milliers de fois par minute.

La correction a été ennuyeuse mais immédiate : déplacer le dépôt vers ~/src à l’intérieur de WSL, documenter « ne pas compiler sur /mnt/c », et apprendre aux utilisateurs Windows d’ouvrir le dépôt via \\wsl$. L’incident a pris fin, non pas avec un patch pour l’outil de build, mais avec une hypothèse corrigée sur l’emplacement des fichiers.

Mini-récit #2 : L’optimisation qui s’est retournée contre eux (bravade rolling release)

Un sous-groupe infra voulait du « plus récent partout » sur les machines dev pour réduire la friction avec des toolchains modernes. Ils ont standardisé une distro à évolution rapide pour WSL parce qu’elle livrait des compilateurs et librairies plus récents sans dépôts supplémentaires. Pendant un temps, c’était génial. Builds plus rapides, moins d’installations manuelles, ingénieurs plus heureux.

Puis une vague de mises à jour est arrivée. Une poignée de paquets cœur ont changé de comportement — rien d’extraordinaire, mais assez pour casser quelques scripts internes supposant d’anciens defaults. En parallèle, un CLI fournisseur utilisé par la moitié de la boîte a livré un binaire incompatible avec une version plus récente d’une bibliothèque. Le mode de défaillance était laid : « ça marche sur ma machine » est devenu « ça marchait sur ma machine hier ».

La charge de support a augmenté. Pas parce que la distro était « mauvaise », mais parce que l’organisation n’avait pas la discipline opérationnelle pour des mises à jour fréquentes. Les gens ont épinglé des paquets de façon ad hoc. Certains ont cessé de mettre à jour. La flotte a fini avec trois états : mise à jour, partiellement mise à jour et fossilisée.

La reprise a été de définir deux niveaux : un défaut stable (Ubuntu LTS) et une option « avancée/expérimentale » (rolling). Ils ont aussi ajouté une politique basique : les mises à jour majeures se font intentionnellement, avec une exportation de sauvegarde d’abord. La leçon n’était pas « ne jamais utiliser des distros modernes ». C’était que « moderne par défaut » est un engagement opérationnel, pas une vibe.

Mini-récit #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (discipline export/import)

Une équipe proche des finances avait une distro WSL accumulant des années d’outillage : environnements Python, bases locales pour tests d’intégration, binaires personnalisés, tout. L’ordinateur d’un ingénieur a commencé à mal se comporter après une mise à jour Windows : WSL lançait puis se bloquait. Les redémarrages n’aidaient pas. La peur immédiate était la perte de données et une reconstruction de plusieurs jours.

Mais l’équipe avait une habitude peu glamour : avant des changements majeurs, ils exportaient leurs distros WSL vers un emplacement standard. Pas quotidiennement, pas parfaitement, mais assez souvent pour que ça compte. L’ingénieur avait une exportation de la semaine précédente.

Le plan de reprise a été simple : wsl.exe --shutdown, désinstaller l’enregistrement de la distro cassée, et réimporter depuis le tarball sous un nouveau nom. Ils étaient opérationnels rapidement, et pouvaient comparer l’ancien et le nouvel environnement sans panique.

Cette pratique ennuyeuse n’a pas seulement sauvé du temps ; elle a sauvé la qualité de décision. Sans elle, les gens font souvent des modifications désespérées et créent un désordre plus grand. Avec un rollback connu, l’équipe a pu corriger la cause racine calmement.

FAQ

1) Dois-je choisir Ubuntu ou Debian pour WSL si je suis débutant sur Linux ?

Ubuntu LTS. Vous aurez plus de « ça fonctionne », plus de tutoriels qui correspondent à votre système et moins de surprises de packaging.

2) Debian est-elle « plus stable » qu’Ubuntu LTS ?

En termes de rythme de changement des paquets de base, Debian stable tend à être plus conservatrice. Ubuntu LTS est aussi stable, mais avec des defaults différents et parfois des stacks plus récents via backports/HWE. Pour la plupart des utilisateurs WSL, les deux sont suffisamment stables ; choisissez selon la compatibilité de l’écosystème.

3) Le choix de la distro résout-il les lenteurs sur WSL ?

Parfois, mais rarement. Le levier de performance le plus important est de placer votre charge de travail sur le système de fichiers Linux, pas sur /mnt/c. Ensuite : pression mémoire, limites CPU et stratégie Docker.

4) Dois-je activer systemd dans WSL ?

Activez-le si vous avez besoin que des services se comportent comme sur des serveurs Linux : systemctl, timers, journald. Si vous avez juste besoin de shells et compilateurs, évitez-le et gardez l’environnement plus simple.

5) Puis-je exécuter Docker dans WSL sans Docker Desktop ?

Oui, mais vous gérerez un démon et son stockage, plus le cycle de vie des services. La plupart des développeurs devraient utiliser l’intégration Docker Desktop sauf si la politique l’empêche.

6) Et openSUSE ou Fedora si mes serveurs de production les utilisent ?

C’est une raison légitime d’appariement du userland en production. Soyez honnête sur la cadence de mises à jour : Fedora évolue plus vite ; openSUSE propose des options stables et rolling.

7) Alpine est-elle une bonne distro WSL pour le travail dev ?

Alpine est excellente pour des conteneurs. Pour du dev général sur WSL, les problèmes de compatibilité musl et le comportement userland différent peuvent coûter du temps. Utilisez-la si vous avez spécifiquement besoin de parité Alpine.

8) Comment garder plusieurs distros WSL sans chaos ?

Nommez-les selon l’usage (ex. Ubuntu-Work, Debian-CI-Parity, Kali-Lab). Gardez votre « défaut » ennuyeux. Exportezz avant les mises à jour. Ne partagez pas les mêmes dépôts entre distros via /mnt/c si les performances comptent.

9) Puis-je accéder à mes fichiers WSL depuis Windows en toute sécurité ?

Oui — utilisez \\wsl$ depuis Windows. Évitez de toucher directement au VHDX sous-jacent ou au système de fichiers de la distro via des chemins Windows non prévus pour cela.

10) Si j’ai déjà fait le mauvais choix, c’est douloureux de changer ?

Pas trop si vous traitez la distro comme remplaçable. Exportezz si nécessaire, réinstallez une nouvelle distro et reprovisionnez via des scripts. La douleur vient des environnements snowflake ; corrigez ça une fois et le futur vous ne s’enverra plus de mails en colère.

Conclusion : étapes pratiques suivantes

Si vous voulez une distribution WSL qui ne vous embêtera pas, misez sur la prévisibilité et une réalité partagée, pas sur le goût personnel.

1. Choix par défaut : installez Ubuntu LTS sauf raison spécifique de ne pas le faire.
2. Choix stabilité : utilisez Debian stable si vous voulez peu de churn et des defaults propres.
3. Choix performance : gardez les dépôts dans le système de fichiers Linux ; arrêtez de builder sur /mnt/c.
4. Hygiène opérationnelle : exportez votre distro avant les mises à niveau, et conservez un script de reconstruction pour l’outillage de base.
5. Triage comme un SRE : vérifiez la localisation des fichiers, la pression mémoire et le réseau/proxy avant d’accuser la distro.

Choisissez l’option ennuyeuse, configurez-la correctement, et passez votre temps à livrer plutôt qu’à découvrir de nouvelles et passionnantes manières pour un gestionnaire de paquets de vous décevoir.