WSL2 : installation, sauvegarde et maintenance, le guide complet

Je travaille sous WSL2 depuis des années sur ma machine Windows. C’est mon environnement Linux quotidien pour le développement, les tests de modèles d’IA en local avec Ollama et l’administration de mes projets. Le problème, c’est que personne ne t’explique jamais l’essentiel qui ne figure pas dans la documentation officielle : comment sauvegarder proprement ta distribution avant de changer de PC, comment récupérer les dizaines de gigas que le disque virtuel accumule sans prévenir, ou pourquoi certaines commandes systemctl fonctionnent chez toi et pas chez ton collègue.

WSL a bien évolué depuis ses débuts, et cet article rassemble ce que j’aurais aimé savoir dès le premier jour : ce qu’est WSL et pourquoi il a remplacé la machine virtuelle classique dans mon flux de travail, comment l’installer et choisir la bonne version, comment lui allouer plus de RAM pour faire tourner Ollama, et les réflexes de sauvegarde et de maintenance qui évitent les mauvaises surprises.

Qu’est-ce que WSL #

WSL, pour Windows Subsystem for Linux, est une fonctionnalité de Windows qui permet de faire tourner un véritable noyau Linux directement sur ta machine, sans machine virtuelle classique ni double boot. Tu ouvres un terminal, tu tapes wsl, et tu te retrouves avec un vrai Ubuntu (ou Debian, Fedora, Alpine) qui partage le système de fichiers, le réseau et le presse-papiers avec Windows.

Concrètement, ça veut dire que je peux lancer htop, docker, git, ou n’importe quel outil en ligne de commande Linux, tout en gardant VS Code, Chrome et mes outils Windows habituels ouverts à côté. Les deux mondes communiquent : un fichier édité dans l’explorateur Windows est visible instantanément dans mon terminal Linux, et inversement.

Pourquoi c’est intéressant #

Avant WSL, les développeurs Windows avaient deux options peu satisfaisantes : une machine virtuelle complète (VirtualBox, VMware), lourde et lente à démarrer, ou un double boot, pratique mais qui oblige à redémarrer pour changer d’environnement.

WSL2 change la donne sur plusieurs points concrets.

La performance d’abord. Le noyau Linux tourne dans une machine virtuelle légère gérée par Hyper-V, avec un accès quasi natif au CPU et à la mémoire. Compiler un projet ou lancer une suite de tests est nettement plus rapide qu’avec une VM classique.

L’intégration ensuite. Docker Desktop, VS Code (avec l’extension Remote - WSL) et la plupart des outils de développement modernes s’appuient directement sur WSL2. Tu écris ton code dans un environnement Linux natif, avec les bons chemins de fichiers, les bonnes permissions, et sans les problèmes de fins de ligne CRLF/LF qui pourrissent la vie sous Windows pur.

Le côté pratique enfin. Pas besoin de repartitionner un disque, pas de redémarrage pour basculer d’un monde à l’autre. Je ferme mon terminal WSL, je rouvre PowerShell, la vie continue.

Installer et désinstaller WSL #

L’installation tient en une seule commande. Ouvre PowerShell ou l’invite de commandes en administrateur et lance :

wsl --install

Cette commande active les composants Windows nécessaires (plateforme de machine virtuelle, sous-système Linux), installe WSL2 comme version par défaut et télécharge Ubuntu si aucune distribution n’est déjà présente. Un redémarrage de la machine est généralement demandé à la fin.

Pour installer une distribution précise plutôt que la valeur par défaut, liste d’abord celles disponibles :

wsl --list --online

Puis installe celle que tu veux, par exemple Debian :

wsl --install -d Debian

Pour supprimer une distribution devenue inutile, la commande --unregister la désinstalle proprement et supprime son disque virtuel associé :

wsl --unregister Debian

WSL1 vs WSL2 : la vraie différence #

Les deux versions coexistent encore aujourd’hui, avec des cas d’usage différents.

En résumé, WSL1 reste pertinent si tu passes ton temps à manipuler des fichiers stockés sur le disque Windows (/mnt/c/...) et que tu n’as pas besoin de Docker ou de compatibilité noyau complète. WSL2 est le choix par défaut pour tout le reste, en particulier dès que Docker ou des outils bas niveau entrent en jeu. C’est aussi la version installée par défaut depuis plusieurs années sur les Windows récents.

Comment savoir quelle version tourne chez toi #

Ouvre PowerShell et lance la commande suivante :

wsl -l -v

Tu obtiens une liste de tes distributions installées avec leur état et leur version WSL, sous cette forme :

  NAME      STATE           VERSION
* Ubuntu    Running         2
  Debian    Stopped         1

La colonne VERSION te donne la réponse directement. Si une distribution est en version 1 et que tu veux la basculer en 2, c’est une seule commande :

wsl --set-version Ubuntu 2

La conversion recompresse tout le système de fichiers dans un disque virtuel, ce qui peut prendre plusieurs minutes selon la taille de la distribution.

Systemd, init et réglages avancés #

Historiquement, WSL2 démarrait ses distributions avec un init minimaliste maison, sans systemd. Depuis les versions récentes de WSL, systemd est disponible et peut être activé, ce qui change concrètement ton quotidien : les services (nginx, docker, postgresql…) redémarrent correctement, les commandes systemctl start/enable/status fonctionnent comme sur un vrai serveur Linux, et les timers systemd (remplaçants modernes de cron) sont utilisables.

Sans systemd, certains services doivent être démarrés à la main à chaque ouverture de terminal, et les outils qui s’appuient dessus (Docker en mode natif, par exemple) peuvent mal se comporter ou nécessiter des contournements.

Pour savoir si ta distribution tourne sous systemd, la vérification la plus fiable se fait depuis le terminal Linux :

ps --pid 1 -o comm=

Si la réponse est systemd, c’est actif. Si c’est init ou autre chose, tu es sur l’ancien mécanisme.

Pour activer systemd si ce n’est pas déjà fait, il faut éditer (ou créer) le fichier /etc/wsl.conf à l’intérieur de la distribution :

sudo nano /etc/wsl.conf

Et y ajouter les lignes suivantes :

[boot]
systemd=true

Le changement ne prend effet qu’après un redémarrage complet de WSL, pas juste une fermeture de terminal :

wsl --shutdown

Relance ensuite ta distribution, systemd doit être actif.

Aller plus loin : allouer plus de RAM et de CPU #

/etc/wsl.conf ne règle que le comportement interne de la distribution. Pour ajuster les ressources matérielles (RAM, CPU, swap) allouées à WSL2 dans son ensemble, c’est un autre fichier qui entre en jeu : .wslconfig, à créer côté Windows dans ton dossier utilisateur, à l’emplacement C:\Users\ton_pseudo\.wslconfig.

Par défaut, WSL2 peut s’attribuer jusqu’à 50% de la RAM disponible sur la machine, ce qui devient limitant si tu veux faire tourner des modèles de langage en local avec Ollama ou LM Studio. Un modèle 7B ou 8B quantifié tient dans 8 Go, mais dès que tu montes en taille de modèle ou en contexte, chaque Go de RAM compte.

Crée ou édite le fichier depuis PowerShell :

notepad $env:USERPROFILE\.wslconfig

Et renseigne les limites souhaitées :

[wsl2]
memory=16GB
processors=8
swap=4GB

Adapte les valeurs à la RAM physique de ta machine, en laissant de la marge pour Windows lui-même. Comme pour le changement de systemd, il faut redémarrer WSL pour que la nouvelle configuration soit prise en compte :

wsl --shutdown

Sauvegarder et migrer sa distribution #

C’est le scénario que je redoutais le plus avant de connaître la bonne commande : changer de machine sans tout réinstaller à la main. WSL propose un mécanisme d’export/import directement intégré, sans outil tiers.

Reprends le nom exact de la distribution à sauvegarder avec wsl -l -v (vu plus haut) : c’est celui marqué d’une étoile, généralement Ubuntu. Tu le réutiliseras dans toutes les commandes qui suivent.

Exporter la distribution #

L’export crée une archive .tar contenant l’intégralité du système de fichiers Linux. Prévois de l’espace disque sur la destination (disque externe, NAS, autre partition) :

wsl --export Ubuntu D:\backup\wsl-ubuntu.tar

Selon la taille de tes projets et paquets installés, l’opération peut prendre plusieurs minutes.

Importer sur la nouvelle machine #

Sur le nouveau poste (WSL déjà activé), branche le support contenant l’archive puis importe-la en choisissant où stocker le futur disque virtuel .vhdx :

wsl --import Ubuntu C:\WSL\Ubuntu D:\backup\wsl-ubuntu.tar

Rétablir l’utilisateur par défaut #

Après un import, WSL démarre systématiquement en root, ce qui n’est pas l’utilisateur que tu veux au quotidien. Lance la distribution :

wsl -d Ubuntu

Puis, depuis le terminal Linux, indique l’utilisateur par défaut à utiliser (remplace ton_pseudo par ton identifiant Linux habituel) :

echo -e "[user]\ndefault=ton_pseudo" | sudo tee -a /etc/wsl.conf

Redémarre WSL pour que le changement soit pris en compte :

wsl --shutdown

Au prochain lancement, tu retrouves ton environnement tel qu’il était, avec le bon utilisateur.

Maintenance : compacter le disque virtuel #

Le disque virtuel .vhdx qui stocke ta distribution grossit au fil du temps, mais ne rétrécit jamais tout seul, même après avoir supprimé des fichiers ou désinstallé des paquets volumineux. Après plusieurs mois d’usage intensif, il n’est pas rare de récupérer 10 à 30 Go d’espace disque Windows en le compactant manuellement.

Prérequis #

Ouvre PowerShell en tant qu’administrateur (clic droit sur l’icône, “Exécuter en tant qu’administrateur”).

Étape 1 : arrêter WSL #

Avant tout compactage, il faut couper WSL pour éviter toute corruption du disque virtuel pendant l’opération :

wsl --shutdown

Étape 2 : compacter le disque virtuel #

Le compactage passe par diskpart, l’outil de gestion de disques intégré à Windows. Adapte le chemin à l’emplacement réel de ton fichier ext4.vhdx (visible avec wsl --import si tu l’as choisi toi-même, ou dans %LOCALAPPDATA%\Packages\ pour une distribution installée depuis le Store) :

Write-Output 'select vdisk file="C:\WSL2Folder\ext4.vhdx"' 'compact vdisk' | diskpart

Patiente jusqu’au retour du curseur, l’opération peut prendre quelques minutes selon la taille du disque.

Le système graphique : WSLg #

Depuis les versions récentes de Windows 10 et 11, WSL embarque WSLg, un support natif des applications graphiques Linux. Concrètement, ça veut dire que tu peux lancer une application graphique Linux directement depuis ton terminal WSL, et la fenêtre s’affiche sur le bureau Windows comme une application native, avec le son et l’accélération GPU.

WSLg nécessite une version relativement récente du composant WSL (à ne pas confondre avec la version de distribution vue plus haut). Vérifie la tienne avec wsl --version et mets à jour si besoin via le Microsoft Store ou wsl --update : c’est la première chose à contrôler si une application graphique refuse de s’afficher.

L’intérêt saute aux yeux avec quelques exemples concrets. Nautilus, le gestionnaire de fichiers de GNOME, permet de naviguer visuellement dans l’arborescence Linux plutôt qu’en ligne de commande :

sudo apt install nautilus
nautilus

Stacer, pour surveiller et nettoyer le système (processus, démarrage, paquets) avec une interface plutôt qu’à coups de ps et systemctl :

sudo apt install stacer
stacer

Ça fonctionne aussi avec des applications qui n’ont rien de spécifique à l’administration système, comme Chrome ou Obsidian installés dans la distribution Linux plutôt que côté Windows, pratique pour un environnement de test isolé ou une prise de notes synchronisée avec le reste de tes projets Linux.

Toutes ces fenêtres s’ouvrent directement sur ton bureau Windows, sans configuration de serveur X ni outil tiers comme VcXsrv qu’il fallait installer et paramétrer manuellement il y a encore quelques années.

Limites de WSL #

WSL2 n’est pas un remplacement universel d’un vrai serveur Linux. Quelques limites à garder en tête avant de tout miser dessus.

Le réseau reste virtualisé, ce qui complique parfois l’exposition de services WSL vers le réseau local sans configuration additionnelle (port forwarding, netsh).

Les performances sur les fichiers stockés côté Windows (/mnt/c/...) restent inférieures à celles d’un accès natif Linux, donc mieux vaut garder ses projets dans le système de fichiers Linux (~/projets) plutôt que dans /mnt/c/Users/....

Pour des besoins de production ou de haute disponibilité, WSL reste un outil de développement, pas un hyperviseur de serveur.

Pour du développement quotidien, de la formation, ou des tests d’outils en local, ces limites ne pèsent pas lourd face au confort gagné.

Conclusion #

WSL2 a changé ma façon de travailler sur Windows : un vrai Linux, installé en une commande, avec Docker, systemd et même des applications graphiques qui fonctionnent comme sur un serveur classique. Les réflexes à garder sous la main sont simples : vérifier si systemd est actif dès qu’un service se comporte bizarrement, ajuster .wslconfig si tu montes en charge avec Ollama ou un autre outil gourmand en RAM, exporter sa distribution avant de changer de machine, et compacter le disque virtuel tous les quelques mois pour ne pas se retrouver à court d’espace.

Sources et références #

• Documentation officielle WSL
• Comparaison WSL1 et WSL2
• WSLg sur GitHub