WSL2 on kenji.blog

Hyper-V vs WSL2 : Comparaison des technologies de virtualisation sur Windows

Sun, 13 Sep 2026 07:00:00 +0900

1. Introduction : L’évolution de la virtualisation sur Windows

La technologie de virtualisation sur la plateforme Windows a connu une évolution spectaculaire au cours des dernières décennies. Autrefois, les hyperviseurs de type 2 tiers (tels que VMware Workstation ou VirtualBox) étaient la norme, mais depuis que Microsoft a introduit “Hyper-V” avec Windows Server 2008, un hyperviseur de type 1 a également été intégré aux systèmes d’exploitation de bureau tels que Windows 10/11.

Et ces dernières années, ce qui attire le plus l’attention parmi les développeurs est “WSL2 (Windows Subsystem for Linux 2)”. Alors que WSL1 s’appuyait sur la traduction des appels système, WSL2 utilise une “Lightweight Utility VM” (machine virtuelle utilitaire légère) qui applique la technologie d’Hyper-V, réalisant ainsi une compatibilité Linux complète et une amélioration spectaculaire des performances.

Dans cet article, nous comparerons et expliquerons en détail ces deux puissantes technologies de virtualisation — le “Hyper-V” complet et le “WSL2” axé sur l’expérience du développeur — en termes d’architecture, de performances (CPU, mémoire, E/S disque), de configuration réseau, et des meilleurs cas d’utilisation, avec une profondeur technique abyssale.

2. Théorie fondamentale des hyperviseurs et comparaison architecturale

Pour comprendre la technologie de virtualisation, il est essentiel de classer les hyperviseurs (Virtual Machine Monitors : VMM) par type.

2.1. Différences entre les hyperviseurs de type 1 et de type 2

Un hyperviseur est une couche logicielle qui abstrait l’accès au matériel et permet à plusieurs systèmes d’exploitation (OS invités) de s’exécuter simultanément sur une seule machine physique.

Type 1 (Bare Metal) : S’exécute directement sur le matériel. Il n’y a pas de concept d’OS hôte (bien qu’il puisse y avoir un OS de gestion avec des privilèges stricts), l’overhead est extrêmement faible, offrant des performances et une sécurité élevées. Exemples : Hyper-V, VMware ESXi, Xen.
Type 2 (Hébergé) : S’exécute comme une application sur l’OS hôte (Windows, macOS, etc.). Étant donné que tous les accès au matériel passent par l’OS hôte, l’overhead est important. Exemples : VMware Workstation, Oracle VirtualBox.

Le Hyper-V de Windows est un pur hyperviseur de Type 1. Lorsque Hyper-V est activé, l’OS Windows lui-même avec lequel l’utilisateur interagit habituellement s’exécute dans une machine virtuelle spéciale appelée “Partition racine” (Root Partition).

2.2. Détails architecturaux d’Hyper-V

L’architecture d’Hyper-V adopte une conception de micro-noyau et est basée sur des unités logiques d’isolation appelées partitions (Partition).

graph TD
A["Matériel (CPU, RAM, Disque, NIC)"] --> B["Hyperviseur Windows (Ring -1)"]
B --> C["Partition racine (OS Windows)"]
B --> D["Partition enfant 1 (VM Windows)"]
B --> E["Partition enfant 2 (VM Linux)"]
C --> F["VMBus (Bus de machine virtuelle)"]
D --> F
E --> F
C --> G["VID (Pilote d'infrastructure de virtualisation)"]
C --> H["VMWP.exe (Processus de travail)"]

Hyperviseur Windows : S’exécute avec le niveau de privilège le plus élevé du CPU (Ring -1 ou mode VMX Root) et gère uniquement l’allocation de la mémoire et la planification du CPU. Il ne contient pas de pilotes de périphériques.
Partition racine : La partition où s’exécute l’OS Windows hôte. Elle possède tous les pilotes de périphériques et contrôle directement le matériel. Elle fournit également les fonctions de gestion (fournisseur WMI, VMWP.exe, etc.) des partitions enfants.
Partition enfant : La partition où s’exécute l’OS invité. L’accès direct au matériel n’est pas autorisé ; elle envoie des requêtes d’E/S (Synthetic I/O) à la partition racine via un bus de mémoire partagée logique appelé “VMBus”.

2.3. Fonctionnement de WSL2 et Lightweight Utility VM

WSL2 utilise la même technologie de base d’hyperviseur de type 1 que Hyper-V, mais utilise un sous-ensemble de fonctionnalités appelé “Virtual Machine Platform (VMP)”, différent d’une machine virtuelle Hyper-V complète.

La “Lightweight Utility VM” adoptée par WSL2 élimine complètement l’émulation de matériel hérité (comme les BIOS ou cartes mères virtuels) que possèdent les machines virtuelles traditionnelles.

graph TD
A["OS Hôte Windows (Espace utilisateur)"]
B["Système de fichiers NTFS"]
C["Serveur de protocole 9P (Plan 9)"]
D["Lightweight Utility VM (Noyau Linux)"]
E["ext4.vhdx (Disque virtuel)"]
F["Espace utilisateur Linux (Distributions WSL2)"]
A --> C
C -->| Partage de fichiers inter-OS | D
D --> E
D --> F

La plus grande caractéristique de WSL2 est sa rapidité de démarrage et son intégration transparente avec l’OS hôte. Le noyau Linux démarre en moins d’une seconde, et il accède au système de fichiers (NTFS) du côté Windows via le protocole de système de fichiers réseau 9P de Plan 9.

3. Analyse approfondie des performances : Ressources de calcul et E/S

Les performances des machines virtuelles sont représentées par la somme des overheads pour chaque composant : CPU, mémoire et E/S disque.

3.1. CPU et overhead de changement de contexte

Hyper-V et WSL2 utilisent tous deux la virtualisation assistée par le matériel (Intel VT-x / AMD-V). Les instructions CPU s’exécutent généralement à une vitesse native, mais lors de l’exécution d’instructions privilégiées ou d’E/S, une interruption appelée “VM Exit” se produit, entraînant un changement de contexte vers l’hyperviseur.

Cet overhead CPU $T_{overhead}$ peut être exprimé par le modèle mathématique suivant :

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

Où :

$N$ : Nombre d’occurrences de VM Exit par unité de temps
$t_{vm\_exit}$ : Temps de transition de l’invité à l’hyperviseur
$t_{hypercall\_process}$ : Temps de traitement des E/S ou des interruptions via VMBus
$t_{vm\_entry}$ : Temps de retour de l’hyperviseur à l’invité

Comme WSL2 n’a pas d’émulation héritée, $t_{hypercall\_process}$ est optimisé et extrêmement petit. Par conséquent, pour les calculs CPU purs (comme la compilation du noyau ou l’inférence de modèles d’apprentissage automatique), la dégradation des performances est de l’ordre de quelques pourcents par rapport à un environnement bare metal.

3.2. Mécanisme d’allocation de la mémoire

En termes de méthodes de gestion de la mémoire, il existe une nette différence de philosophie de conception entre les deux.

Hyper-V (Dynamic Memory) : La partition racine alloue et récupère dynamiquement la mémoire en fonction des besoins en mémoire de la VM invitée. Cependant, la mémoire allouée en tant que cache de page dans l’OS invité a tendance à ne pas être libérée à moins que le système ne soit sous pression.
WSL2 (Récupération dynamique de mémoire) : WSL2 dispose d’un mécanisme propriétaire qui renvoie (Reclaim) régulièrement la mémoire devenue inutile (y compris le cache) dans la VM Linux à l’hôte Windows. Les premières versions de WSL2 avaient un problème où le cache de page Linux dévorait la mémoire Windows (processus Vmmem gonflé), mais cela a maintenant été amélioré par des patchs du noyau.

3.3. Caractéristiques des E/S disque (VHDX vs ext4.vhdx)

Le goulot d’étranglement le plus fréquent des performances des machines virtuelles est l’E/S disque.

La latence d’E/S $L_{total}$ est calculée comme suit :

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

Pour Hyper-V : Les invités Hyper-V typiques utilisent des disques virtuels au format VHDX. Les requêtes d’E/S émises par le système de fichiers (ext4 ou NTFS) dans l’OS invité traversent le pilote de stockage de périphérique bloc de VMBus (storvsc) et sont traitées comme un accès au fichier VHDX sur le NTFS côté Windows.

Pour WSL2 : Les distributions Linux sur WSL2 s’exécutent sur un système de fichiers ext4 natif construit à l’intérieur d’un fichier dédié ext4.vhdx. Les opérations de fichiers à l’intérieur de Linux (comme dans le répertoire ~) atteignent des performances natives équivalentes à celles de l’Hyper-V ci-dessus. Cependant, lors de l’accès aux fichiers du côté Windows depuis le Linux de WSL2 (comme /mnt/c/), ou vice versa, le processus est très différent. Cet accès inter-OS utilise le 9P (Plan 9 File System Protocol).

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

L’accès via ce protocole 9P a un important overhead de traitement de sérialisation, et les performances chutent drastiquement (parfois avec un délai plus de 10 fois supérieur) pour les applications lisant et écrivant un grand nombre de petits fichiers (par exemple, npm install ou les opérations Git dans un projet Node.js situé dans un répertoire côté Windows). C’est pourquoi la règle d’or absolue lors de l’utilisation de WSL2 est de toujours placer les fichiers de projet dans le système de fichiers natif de Linux (sous ~/).

4. Structure du réseau : NAT, Default Switch, Bridged

La flexibilité des capacités réseau est l’une des principales différences entre Hyper-V et WSL2.

4.1. Le réseau de WSL2 (Basé sur le NAT)

Par défaut, le réseau de WSL2 est configuré en “NAT (Network Address Translation)” en utilisant la technologie de commutateur virtuel d’Hyper-V. Une adresse IP privée (par exemple : 172.20.x.x) différente de celle de l’hôte Windows est automatiquement attribuée à la VM Linux. Un mécanisme est intégré pour que l’accès à localhost depuis l’hôte Windows soit redirigé vers les services (ports) démarrés dans WSL2, permettant aux développeurs de tester des serveurs web sans se soucier du réseau.

Récemment, un nouveau mode réseau appelé “Mirrored mode” (mode miroir) a été introduit dans les versions preview de WSL2. Cela vise à améliorer le support d’IPv6 et la compatibilité des connexions VPN (configurable via .wslconfig).

4.2. Commutateur virtuel d’Hyper-V (Virtual Switch)

Hyper-V permet la construction de réseaux avancés au niveau de l’entreprise. Via le “Gestionnaire de commutateur virtuel”, il offre principalement trois modes :

Externe (External) : Lie la carte réseau physique de la machine hôte au commutateur virtuel, permettant aux VM invitées de participer directement au réseau physique (connexion par pont). La VM obtient une IP du même sous-réseau que le réseau physique depuis un serveur DHCP.
Interne (Internal) : N’autorise que les communications entre l’OS hôte et les VM, et entre les VM elles-mêmes. Elles ne peuvent pas accéder directement au réseau externe.
Privé (Private) : N’autorise que les communications entre les VM, bloquant même la communication avec l’OS hôte. Utilisé pour créer des environnements de test isolés.

4.3. Construction de réseaux Hyper-V avancés avec PowerShell

Dans les environnements de développement et de test, si vous souhaitez construire un réseau NAT personnalisé pour les VM, PowerShell permet un contrôle détaillé. Voici un exemple de script pour créer un commutateur virtuel interne, y configurer le NAT, et fournir un accès à internet aux VM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Création d'un commutateur virtuel interne
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. Configuration d'une adresse IP pour la carte réseau virtuelle côté hôte (IP servant de passerelle)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. Configuration du réseau NAT
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# Commande de vérification
Get-NetNat

Avec cette configuration, en attribuant manuellement une IP 192.168.100.x et la passerelle 192.168.100.1 à l’invité Hyper-V spécifié, vous pouvez construire votre propre segment NAT capable de communiquer avec l’extérieur via l’hôte.

5. Cas d’utilisation et guide de sélection pratique

Sur la base des différences d’architecture et de performances discutées jusqu’à présent, nous définissons dans quelles situations chacune de ces technologies devrait être adoptée.

5.1. Scénarios où WSL2 doit être sélectionné

WSL2 a été conçu spécifiquement pour “l’amélioration de la productivité des développeurs”. Il est idéal pour les utilisations suivantes :

Développement web et cloud-native : Développement de conteneurs utilisant Docker Desktop (backend WSL2) ou Podman.
Utilisation d’outils exclusifs à Linux : Utilisation quotidienne de bash, grep, awk, sed ou des compilateurs GCC et Clang pour Linux.
Applications GUI (WSLg) : Lorsque vous souhaitez exécuter de manière transparente des applications X11/Wayland de Linux sur le bureau Windows.
Apprentissage automatique et développement d’IA : Apprentissage rapide de TensorFlow ou PyTorch utilisant la fonction de passthrough GPU (NVIDIA CUDA sur WSL).

Attention : Vous pouvez rencontrer des restrictions si vous souhaitez personnaliser finement le noyau ou construire des services complexes qui dépendent fortement de systemd (actuellement, systemd est pris en charge mais désactivé par défaut ou restreint).

5.2. Scénarios où Hyper-V doit être sélectionné

Hyper-V a pour but “la virtualisation de l’infrastructure et une isolation complète”. Il est essentiel pour les utilisations suivantes :

Exécution de VM Windows : Lors de l’exécution de différentes versions de Windows (Windows Server, anciens Windows 10, etc.) comme environnements de test.
Virtualisation imbriquée (Nested Virtualization) : Lorsque vous souhaitez exécuter une machine virtuelle (Hyper-V ou KVM) à l’intérieur d’une autre machine virtuelle. Indispensable pour les environnements de test des ingénieurs d’infrastructure.
Besoins réseau avancés : Lorsqu’il est nécessaire de contrôler strictement la configuration du réseau, comme pour les connexions par pont externes (participation au même LAN), le marquage VLAN ou l’attribution de plusieurs NIC.
Instantanés (Checkpoints) : Fonctionnalité permettant de sauvegarder l’état d’une VM à un moment donné et de revenir en arrière instantanément à tout moment. Extrêmement utile pour les tests destructifs de logiciels ou l’analyse de logiciels malveillants.
Allocation fixe des ressources : Lorsque vous souhaitez fixer strictement le nombre de cœurs CPU et la quantité de mémoire pour minimiser l’impact sur l’OS hôte.

6. Considérations sur le débit d’E/S avec un modèle mathématique (Annexe)

En tant qu’ingénieur système, lorsqu’il s’agit d’identifier les limites des performances d’E/S des deux, il est important de comprendre théoriquement la relation entre le débit $S$ et la taille de bloc $B$.

Le débit de transfert de données $S$ est la quantité de données transférées par unité de temps, modélisée comme suit :

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$ : Taille de bloc (Octets)
$L_{setup}$ : Latence fixe due à la configuration de la requête d’E/S et au changement de contexte
$R_{max}$ : Bande passante maximale du matériel lors de la copie ou du transfert d’appareils

Pour l’accès aux fichiers de WSL2 via le protocole 9P, ce $L_{setup}$ devient très important (en raison des communications via socket et de la sérialisation/désérialisation du protocole). Par conséquent, lorsque la taille de bloc $B$ est petite (lecture et écriture massives de petits fichiers de quelques Ko), l’impact de $L_{setup}$ dans le dénominateur devient dominant, et le débit $S$ chute considérablement. À l’inverse, pour l’accès aux VHDX via le VMBus d’Hyper-V, $L_{setup}$ est optimisé à un niveau proche de l’interruption matérielle, de sorte qu’il peut maintenir des IOPS élevés même pour des petits blocs.

Cette réalité mathématique est le fondement logique de la bonne pratique selon laquelle “il ne faut pas placer les fichiers de projet du côté Windows avec WSL2”.

7. Conclusion : Deux technologies de virtualisation qui coexistent

Ce n’est pas que l’un entre Hyper-V et WSL2 soit meilleur que l’autre, ce sont “deux solutions avec des objectifs différents”.

WSL2 est le “meilleur outil d’intégration” pour briser la coquille de l’OS Windows et apporter l’écosystème Linux de manière transparente et rapide aux utilisateurs de Windows. Il n’est pas exagéré de dire que c’est l’environnement CLI ultime pour les développeurs.
Hyper-V est un “hyperviseur authentique” qui apporte au bureau la forte isolation et les capacités de gestion cultivées dans les centres de données d’entreprise. Il n’y a pas mieux pour la construction de réseaux, les tests du système d’exploitation Windows et la simulation d’environnements d’infrastructure.

Dans les environnements Windows modernes, ces deux technologies ne sont pas en concurrence directe, mais coexistent magnifiquement sur la même plateforme de VM. En les utilisant de manière appropriée en fonction de l’usage, Windows deviendra la station de travail d’ingénierie la plus puissante et la plus flexible au monde.

Le guide ultime de configuration de l'environnement de développement pour WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

WSL2 (Windows Subsystem for Linux 2), qui offre un environnement de développement Linux natif sur Windows, est devenu un outil indispensable dans le développement de logiciels moderne. Cependant, il y a un monde de différence en termes de performances et d’expérience de développement entre l’utiliser dans son état par défaut et le régler de manière appropriée en comprenant son architecture.

Dans cet article, nous expliquerons de manière exhaustive, avec plus de 10 000 caractères, toutes les étapes pour construire l’« environnement de développement ultime » exigé par les ingénieurs professionnels, en commençant par l’explication de l’architecture fondamentale de WSL2, les paramètres pour maximiser les performances, la construction d’un environnement de terminal confortable, l’intégration transparente avec Docker et VS Code, et enfin les paramètres réseau avancés.

1. Architecture de WSL2 et évolution par rapport à WSL1

Afin de libérer tout le potentiel de WSL2, il est d’abord important de comprendre sa structure interne. L’approche pour exécuter des binaires Linux sur Windows est fondamentalement différente entre le premier WSL (WSL1) et WSL2.

WSL1 : Couche de traduction des appels système

WSL1 a adopté un mécanisme qui traduisait les appels système Linux en API Windows NT en temps réel. Cela avait l’avantage d’une surcharge de ressources très faible, car aucune machine virtuelle (VM) n’était utilisée. Cependant, il était difficile d’émuler complètement les appels système complexes, tels que les opérations d’E/S du système de fichiers, ce qui entraînait des baisses de performances désespérantes, notamment dans les processus traitant un grand nombre de petits fichiers, comme npm install de Node.js ou les opérations sur les dépôts Git.

WSL2 : VM utilitaire légère et noyau Linux complet

Dans WSL2, l’architecture a été remaniée pour qu’un véritable noyau Linux, construit par Microsoft, s’exécute directement sur une « VM utilitaire légère » qui utilise un sous-ensemble de l’architecture Hyper-V. Cela garantit une compatibilité à 100 % des appels système, et en utilisant un disque virtuel (VHDX) avec un système de fichiers natif Linux ext4, les performances d’E/S des fichiers ont été considérablement améliorées par rapport à WSL1.

Le diagramme Mermaid suivant illustre la différence structurelle entre WSL1 et WSL2.

flowchart TD
subgraph "Environnement du système d'exploitation Windows"
A["Noyau Windows NT"]
A --> F["Système de fichiers NTFS (Lecteur C:)"]
end
subgraph "Architecture WSL2"
B["Hyperviseur Hyper-V"]
B --> C["VM utilitaire légère"]
C --> D["Noyau Linux (Microsoft)"]
D --> E["Espace utilisateur Ubuntu (glibc, bash, etc.)"]
D --> G["Disque virtuel ext4 (.vhdx)"]
end
A -.->|"Partage de fichiers réseau par le protocole Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

La leçon importante à tirer de cette structure est que « l’accès aux fichiers côté Linux (dans le VHDX) est extrêmement rapide, mais l’accès aux fichiers côté Windows (/mnt/c/) est très lent car il passe par le protocole 9P ». Le code source de vos projets doit toujours être placé dans le répertoire personnel côté WSL (~).

2. Analyse mathématique des performances : Pourquoi WSL2 est-il rapide ?

Évaluons quantitativement l’amélioration des performances de WSL2 à l’aide d’un modèle mathématique. L’une des opérations les plus chronophages dans le développement de logiciels est le traitement impliquant des E/S pour un grand nombre de fichiers (ex. : installation de bibliothèques ou compilation).

Le temps d’exécution global $T_{total}$ d’un traitement est exprimé par la somme du temps de calcul par le processeur $T_{compute}$ et du temps consacré aux E/S disque $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

Dans le cas de WSL1, une surcharge se produit lors de la conversion des opérations côté Linux en opérations NTFS, le temps d’E/S est donc modélisé comme suit. Ici, $n$ est le nombre d’opérations sur les fichiers, $t_{ntfs\_syscall}$ est le temps d’exécution de l’appel système côté Windows, et $t_{trans}$ est la surcharge de la couche de traduction.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

D’autre part, dans le cas de WSL2, le noyau émet directement des E/S vers le système de fichiers ext4, de sorte que la surcharge n’est qu’un très léger retard $t_{virt}$ dû à la virtualisation.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

Dans un système de fichiers classique, comme $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$, lorsque $n$ est très grand (des dizaines à des centaines de milliers d’opérations sur les fichiers), la différence de temps d’E/S entre WSL1 et WSL2 augmente de manière exponentielle.

De plus, si le taux de surcharge des calculs du processeur dans un environnement virtualisé est $\rho$, avec la dernière virtualisation assistée par matériel (Intel VT-x / AMD-V), il se situe autour de $\rho \approx 0.01 \sim 0.03$ (1 à 3 %). Par conséquent, même dans des tâches purement de calcul, des performances comparables à un environnement Linux natif de $97\% \sim 99\%$ sont atteintes.

3. Installation et construction des bases

Sur Windows 10/11, l’installation de WSL2 est devenue très simple. Il suffit d’ouvrir PowerShell avec les privilèges d’administrateur et d’exécuter la commande suivante.

1
2
3
4
5
6


# WSL2 et Ubuntu sont installés par défaut
wsl --install

# Pour spécifier une distribution particulière
# Peut être vérifié avec wsl --list --online
wsl --install -d Ubuntu-24.04

Après l’installation et un redémarrage, il vous sera demandé de configurer un nom d’utilisateur et un mot de passe UNIX lors du premier lancement. Cet utilisateur est indépendant de l’utilisateur Windows et n’est valide qu’au sein de WSL.

Si vous utilisez déjà WSL1, vous pouvez le convertir en WSL2 avec les commandes suivantes.

1
2
3
4
5


# Convertir une distribution existante en WSL2
wsl --set-version Ubuntu 2

# Définir WSL2 comme version par défaut pour les distributions ajoutées à l'avenir
wsl --set-default-version 2

4. Les secrets du contrôle des ressources : .wslconfig et wsl.conf

L’un des plus grands pièges de WSL2 est la « consommation illimitée de mémoire (gonflement du processus Vmmem) ». Comme WSL2 utilise le cache de page du noyau Linux, chaque opération d’E/S consomme de la mémoire de l’hôte (Windows) de manière infinie. Pour éviter cela, il est impératif de limiter les ressources via des fichiers de configuration.

Les fichiers de configuration de WSL2 sont divisés en deux : .wslconfig qui affecte l’ensemble de Windows et wsl.conf qui affecte l’intérieur de chaque distribution.

4.1. .wslconfig (Côté Windows)

Créez un fichier dans le répertoire de profil utilisateur de Windows (C:\Users\<Nom_d_utilisateur>\.wslconfig) pour contrôler l’allocation des ressources à la VM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<Nom_d_utilisateur>\.wslconfig
[wsl2]
# Quantité maximale de mémoire allouée à la VM. Il est recommandé d'utiliser environ 50 % à 75 % de la mémoire totale de l'hôte
memory=16GB

# Nombre de cœurs de processeur à utiliser (tous les cœurs sont utilisés si omis)
processors=8

# Taille du fichier d'échange (swap)
swap=8GB

# Emplacement du fichier d'échange (si vous souhaitez économiser de l'espace sur le lecteur C)
# swapfile=D:\\wsl\\swap.vhdx

# Activer le transfert localhost (pour accéder à WSL depuis Windows via localhost)
localhostForwarding=true

# Libérer automatiquement la mémoire (Windows 11 uniquement)
# Libère dynamiquement le cache de page et empêche le gonflement de Vmmem
autoMemoryReclaim=dropcache

[experimental]
# Fonctionnalités réseau avancées disponibles dans Windows 11 22H2 et versions ultérieures
# Cela permet la prise en charge d'IPv6 et le partage de la même adresse IP entre WSL et Windows
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Côté Linux)

Modifiez /etc/wsl.conf à l’intérieur de WSL pour contrôler le comportement spécifique de la distribution.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (Modifié à l'intérieur de WSL)
[network]
# Désactiver la génération automatique de /etc/resolv.conf au démarrage de WSL
# Utile si vous souhaitez configurer un DNS personnalisé (ex. : 8.8.8.8)
generateResolvConf=false

# Définir un nom d'hôte personnalisé
hostname=WSL-DevNode

[automount]
# Paramètres lors du montage de lecteurs Windows
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Changer le point de montage du lecteur C de /mnt/c à /c (pour raccourcir le chemin)
root=/

[boot]
# Activer systemd (WSL 0.67.6 et versions ultérieures)
# Cela permet à snap et à divers démons (tels que Docker) de fonctionner nativement
systemd=true

[user]
# Utilisateur connecté par défaut
default=kenji

Pour appliquer ces paramètres, vous devez exécuter wsl --shutdown dans PowerShell pour arrêter complètement la VM WSL avant de redémarrer.

5. L’environnement de terminal ultime : Zsh + Powerlevel10k

Rester avec le bash par défaut n’augmentera pas votre productivité. En combinant Zsh, qui se vante de puissantes capacités de complétion et de visibilité, avec le thème ultra-rapide « Powerlevel10k », nous allons construire l’invite de commande (prompt) la plus puissante.

5.1. Installation et configuration de Windows Terminal

Installez « Windows Terminal » à partir du Microsoft Store. Ouvrez la configuration JSON (settings.json), définissez le profil par défaut sur WSL (Ubuntu) et changez la police pour une Nerd Font orientée développement (par ex., HackGen Console NF ou MesloLGS NF).

5.2. Installation de Zsh et Oh My Zsh

Exécutez les commandes suivantes dans le terminal WSL.

1
2
3
4
5
6


# Mise à jour des paquets et installation de Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Exécuter le script d'installation de Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Introduction de Powerlevel10k et des plugins

Nous allons introduire des plugins pour améliorer encore Zsh (coloration syntaxique et auto-complétion) ainsi que le thème Powerlevel10k.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Modifiez ~/.zshrc pour activer le thème et les plugins.

1
2
3
4
5


# Changements dans ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Ajouter au tableau des plugins
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Enregistrez et exécutez source ~/.zshrc, l’assistant de configuration de Powerlevel10k (p10k configure) se lancera. Suivez les instructions à l’écran pour personnaliser l’invite selon vos préférences (style de l’invite, présence d’icônes, informations à afficher, etc.). Le nom de la branche Git et son statut, la version de Node.js, le temps d’exécution des commandes, etc. seront affichés en temps réel, ce qui améliorera considérablement l’efficacité du développement.

6. Intégration transparente de VS Code Remote - WSL

Pour le développement dans WSL2, l’extension « Remote - WSL » est le mécanisme qui permet d’accéder de manière transparente aux fichiers dans WSL depuis l’IDE (Visual Studio Code) installé côté Windows.

Explication de l’architecture

Le diagramme de séquence suivant montre comment VS Code communique avec WSL2.

sequenceDiagram
autonumber
participant U as "Développeur"
participant V as "Interface utilisateur de VS Code (Windows)"
participant S as "Serveur VS Code (WSL2)"
participant F as "Système de fichiers ext4 (WSL2)"
U->>V: "Tapez `code .` dans le terminal WSL"
V->>S: "Établir une connexion RPC via Vsock"
Note over V,S: Communication via les sockets Hyper-V sans utiliser TCP/IP
S->>F: "Lire les fichiers sources / Exécuter le Linter"
F-->>S: "Retourner les données et l'analyse"
S-->>V: "Diffuser les résultats du serveur de langage vers l'UI"
V-->>U: "Afficher la coloration syntaxique et les erreurs"

Le VS Code côté Windows fonctionne comme un simple « client léger (UI) », et tous les traitements lourds tels que le Language Server, le débogueur et l’exécution du terminal sont gérés par le « VS Code Server » côté WSL. Cela vous permet de garder votre environnement propre uniquement du côté WSL, sans avoir à installer Node.js ou Python du côté Windows.

Paramètres essentiels de VS Code

Installez “WSL” (ms-vscode-remote.remote-wsl) depuis les « Extensions » de VS Code. Ensuite, allez simplement dans le répertoire de votre projet dans le terminal WSL et exécutez code ., VS Code se lancera côté Windows avec ce répertoire ouvert.

Point important (problème des codes de fin de ligne) : Les codes de fin de ligne diffèrent entre Windows et Linux (Windows utilise CRLF, Linux utilise LF). Lors d’un développement sur WSL, assurez-vous d’unifier le paramètre core.autocrlf de Git et les paramètres de fichier par défaut de VS Code à LF. Si vous négligez cela, vous rencontrerez des erreurs mystérieuses lors de l’exécution de scripts shell ou de conteneurs Docker.

1
2


# Configuration du code de fin de ligne de Git côté WSL
git config --global core.autocrlf input

Ajoutez également ce qui suit dans le fichier settings.json de VS Code (Paramètres distants).

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Optimisation de Docker Desktop et de l’intégration WSL2

Pour utiliser Docker dans un environnement WSL2, il existe principalement deux approches.

Installer Docker Desktop pour Windows et activer la fonctionnalité d’intégration WSL2
Installer nativement le moteur Docker directement à l’intérieur de WSL2 (ex. : Ubuntu)

Approche 1 : Docker Desktop (Recommandé)

Dans la plupart des cas, cela est recommandé car la gestion via l’interface graphique et l’accès transparent aux conteneurs entre Windows/WSL sont faciles. Vérifiez les points suivants depuis les paramètres de Docker Desktop (Settings).

Cochez General -> Use the WSL 2 based engine.
Cochez Resources -> WSL Integration -> Enable integration with my default WSL distro et activez la distribution à utiliser (Ubuntu) avec le bouton à bascule.

Cela vous permet d’exécuter la commande docker directement depuis le terminal WSL2, et la communication avec le démon Docker s’effectue via des machines virtuelles légères dédiées (docker-desktop et docker-desktop-data) gérées par Docker Desktop.

Approche 2 : Installation directe du moteur Docker natif

Si vous avez des contraintes de réseau d’entreprise (comme éviter la monétisation de Docker Desktop) ou si vous souhaitez réduire au maximum la surcharge de performances, installez Docker en tant que pur serveur Ubuntu après avoir activé systemd dans /etc/wsl.conf.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Extrait des instructions officielles d'installation de Docker sur WSL2 Ubuntu avec systemd activé
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Ajout du dépôt
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Ajouter l'utilisateur actuel au groupe docker (pour exécuter sans sudo)
sudo usermod -aG docker $USER

Après le redémarrage, systemctl start docker fonctionnera exactement comme dans un environnement Linux natif et offrira des performances élevées.

8. Intégration des clés SSH : Authentification transparente entre Windows et WSL

Lors de la réalisation de clones SSH Git ou de la connexion SSH à des serveurs distants, gérer des clés SSH séparées côté Windows et côté WSL est très fastidieux. Pour allier sécurité et commodité, nous allons configurer un pont pour transférer l’agent SSH en cours d’exécution côté Windows (ou un gestionnaire de mots de passe comme 1Password) vers le côté WSL.

Ici, nous expliquerons l’approche la plus sécurisée et moderne consistant à utiliser la fonctionnalité d’agent SSH de 1Password ou l’OpenSSH Authentication Agent de Windows, et à la transférer vers un socket de domaine UNIX de WSL2 en utilisant npiperelay et socat.

Transfert de socket ssh-agent

Habituellement, l’agent SSH, qui est fourni en tant que Named Pipe (tube nommé) sous Windows, doit être converti en un fichier socket côté WSL. Il est facile d’utiliser des fonctionnalités fournies par wsl-ssh-agent ou 1Password.

Depuis l’écran des paramètres de 1Password, activez « Developer » -> « Use the SSH agent » (Utiliser l’agent SSH). Ensuite, ajoutez la configuration suivante dans le fichier ~/.zshrc ou ~/.bashrc côté WSL pour lier automatiquement le socket lors de la connexion.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Ajout dans ~/.zshrc (exemple lors de l'utilisation de 1Password SSH Agent)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Transférer avec socat et npiperelay si le socket n'existe pas ou si le processus n'est pas lié au démarrage de WSL
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Démarrer socat en arrière-plan et connecter le Named Pipe côté Windows au socket UNIX côté WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

L’installation de npiperelay.exe et l’ajout à la variable d’environnement PATH côté Windows sont nécessaires au préalable.

Une fois cette configuration terminée, lors de l’exécution de ssh-add -l depuis le terminal WSL, la liste des clés publiques des clés SSH enregistrées dans 1Password ou côté Windows s’affichera. Cela vous permet de passer l’authentification en toute sécurité sans avoir à copier les fichiers de clé privée dans WSL.

9. Maintenance : Optimisation (compression) d’un VHDX gonflé

L’un des plus grands inconvénients de WSL2 est sa spécification selon laquelle « la taille du fichier du disque virtuel côté Windows (.vhdx) ne rétrécit pas automatiquement, même si vous supprimez des images Docker ou des fichiers ». Si vous continuez à développer pendant une longue période, le fichier ext4.vhdx va gonfler jusqu’à des dizaines ou des centaines de gigaoctets.

Pour libérer de l’espace disque, vous devez optimiser (Compacter) régulièrement le VHDX depuis le côté Windows.

Tout d’abord, arrêtez complètement WSL.
1

wsl --shutdown
Ouvrez PowerShell avec des privilèges d’administrateur et exécutez la commande diskpart suivante, ou la commande Optimize-VHD du module Hyper-V (cette dernière n’est disponible que si Hyper-V est activé).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Si le module Hyper-V est disponible
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# Si vous utilisez diskpart
diskpart
# Entrez interactivement dans l'invite suivante
DISKPART> select vdisk file="C:\Users\<Nom_d_utilisateur>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

En effectuant cette opération régulièrement, vous pouvez récupérer la capacité du lecteur C inutilement consommée.

10. Conclusion

WSL2 a complètement dépassé le cadre d’être un simple « Linux bonus fonctionnant sur Windows » et a évolué vers une puissante plateforme de développement qui n’est pas inférieure, et peut-être même supérieure, à macOS et aux machines Linux natives.

En appliquant tous les paramètres expliqués cette fois-ci (optimisation des ressources avec .wslconfig, amélioration du terminal avec Zsh + Powerlevel10k, accès transparent avec VS Code Remote, intégration SSH et maintenance VHDX), un « environnement de développement ultime » rapide, sécurisé et sans stress est achevé.

La configuration de l’environnement demande un peu d’effort, mais une fois les paramètres fixés, il ne fait aucun doute que votre future productivité en ingénierie s’améliorera considérablement. N’hésitez pas à explorer des personnalisations supplémentaires sur la base de ce guide, en fonction de vos propres projets et préférences.