WSL vs VirtualBox : quand WSL n’est pas l’outil adapté

Tracer la ligne de décision : ce que vous choisissez réellement

Les gens présentent cela comme « WSL vs VirtualBox ». Ce n’est pas le vrai choix. Le choix est :

• Sandbox de confort vs système contrôlable. WSL est une sandbox de confort profondément intégrée à Windows. VirtualBox vous offre une frontière système contrôlable.
• Intégration axée Windows vs comportement axé Linux. WSL optimise la boucle développeur sur Windows. VirtualBox optimise « ça se comporte comme Linux sur du matériel », parce que c’est ce que c’est.
• Destin partagé vs destin explicite. WSL partage davantage son destin avec l’hôte Windows : chemins d’E/S de fichiers, intermédiaires réseau, comportement sous pression mémoire, cadence des mises à jour, interférences d’outils bureautiques d’entreprise. VirtualBox est aussi affecté par l’hôte, mais votre rayon d’impact est plus facile à raisonner.

Si votre charge exige un contrôle du noyau, du réseau bas niveau, des sémantiques de stockage prévisibles, ou la capacité de traiter l’invité comme une machine séparée : par défaut, choisissez une VM. Si votre charge relève surtout d’outils userland et que vous tenez à l’intégration Windows : par défaut, choisissez WSL.

Règle pragmatique : si vous prévoyez d’ouvrir des bugs qui commencent par « Sur Linux ça marche », vous voulez probablement VirtualBox. Si votre plan est « j’ai juste besoin d’un shell, git et d’un compilateur », WSL suffira probablement.

Faits et contexte historique (les éléments qu’on oublie)

• WSL 1 n’était pas une VM. Il traduisait les appels système Linux en appels Windows NT. Cela le rendait astucieux, rapide dans certains cas, et fondamentalement incompatible dans d’autres.
• WSL 2 est passé à un vrai noyau Linux. C’est le grand tournant : WSL 2 exécute un noyau Linux fourni par Microsoft dans une VM légère utilisant des composants Hyper‑V.
• VirtualBox est antérieur à WSL d’une décennie. VirtualBox a commencé chez Innotek, puis Sun, puis Oracle. Il est assez ancien pour avoir résolu des problèmes ennuyeux comme « démarrer un invité avec des périphériques prévisibles ».
• Hyper‑V et VirtualBox ont une histoire commune. Pendant des années ils ont concurrencé les fonctionnalités de virtualisation matérielle. VirtualBox moderne peut fonctionner sur des hôtes avec Hyper‑V activé, mais les interactions de performance et de fonctionnalités peuvent rester… épicées.
• Le modèle de système de fichiers de WSL est intentionnellement scindé. Les fichiers Linux stockés à l’intérieur du disque virtuel de WSL se comportent différemment des fichiers Windows montés sous /mnt/c. Cette différence n’est pas cosmétique ; c’est une limite de performance et de correction.
• Les outils de sécurité en entreprise ont changé la donne. Les agents de protection des endpoints et de DLP inspectent les opérations de fichiers et le trafic réseau. Les chemins d’intégration de WSL peuvent amplifier cette surcharge d’une manière qu’une image disque VM n’amplifie pas.
• VirtualBox est devenu le substrat VM par défaut pour une génération de devs. Des outils comme Vagrant ont popularisé « une VM par projet ». Cette attente s’aligne bien sur VirtualBox et moins bien sur WSL.
• WSL a ajouté le support de systemd plus tard. Les premiers utilisateurs de WSL devaient bricoler le comportement d’init. WSL moderne peut exécuter systemd, mais cela ne transforme pas automatiquement WSL en « serveur ».
• Les attentes réseau ont divergé. VirtualBox propose des modes NIC classiques (NAT, bridgé, host‑only). WSL 2 utilise un réseau virtuel NATé avec Windows comme intermédiaire, ce qui affecte la connectivité entrante et la visibilité des paquets.

Différences d’architecture qui importent vraiment

WSL 2 : une VM légère qui ne veut pas en avoir l’air

WSL 2 exécute un noyau Linux à l’intérieur d’une VM gérée. Microsoft a fait le travail difficile pour que vous n’ayez pas à penser aux réglages BIOS, contrôleurs de disque et séquences de boot. C’est l’attrait. Mais cette approche « gérée » signifie aussi que vous n’avez pas la main sur beaucoup de molettes qui comptent quand vous diagnostiquez des problèmes de performance, réseau ou stockage.

Les différences majeures que vous ressentirez :

• Frontière du système de fichiers : ext4‑dans‑un‑vhdx côté Linux vs NTFS Windows monté dans Linux sous /mnt. Caractéristiques de performance différentes ; comportement des watchers différent ; sémantiques de métadonnées différentes sous charge.
• Frontière réseau : WSL 2 est par défaut derrière un NAT, avec Windows faisant routage et redirection de ports. Les connexions entrantes, le multicast et l’attente « il suffit de bind sur 0.0.0.0 » peuvent devenir bizarres.
• Gouvernance des ressources : la VM WSL augmente la mémoire à la demande et ne réduit pas toujours comme vous le pensez sauf si vous la configurez. C’est pratique… jusqu’à ce que ça ne le soit plus.
• Attentes sur le noyau/modules : vous exécutez le noyau de Microsoft. Vous ne pouvez pas charger librement des modules noyau arbitraires comme sur une installation distro normale.

VirtualBox : une VM conventionnelle avec des compromis conventionnels

VirtualBox est « un ordinateur dans une fenêtre ». Vous obtenez du matériel virtuel explicite et un comportement invité plus prévisible. Vous obtenez aussi des coûts, des limitations d’émulation de périphériques et les corvées quotidiennes du cycle de vie des VM : mises à jour, snapshots, dimensionnement des disques et modes réseau.

Mais quand quelque chose casse, VirtualBox casse d’une manière que vous pouvez raisonner : mode NIC mal configuré, I/O disque throttlées, interface host‑only non créée, guest additions manquantes. Ce sont des pannes ennuyeuses. Les pannes ennuyeuses sont survivables.

Une idée paraphrasée à garder sur un post‑it, attribuée à Werner Vogels : « Tout échoue ; construisez des systèmes qui supposent l’échec et récupèrent rapidement. » (idée paraphrasée)

Petite blague, puisque nous allons parler réseau : le NAT, c’est comme les bavardages de bureau — correct pour l’outbound, gênant quand quelqu’un essaie d’engager une vraie conversation.

Quand WSL est l’outil adapté

WSL brille quand votre objectif est d’être productif sur Windows sans maintenir une VM complète. C’est une plateforme pour développeur, pas un mini‑datacenter.

Utilisez WSL quand vous voulez itération rapide et intégration étroite avec Windows

• Outils CLI : git, ssh, curl, runtime de langages, gestionnaires de paquets, systèmes de build.
• Flux de travail textuels : éditeurs, linters, compilateurs, tests unitaires, scripts locaux.
• Conteneurs (souvent) : Docker Desktop utilise WSL 2 comme backend pour les conteneurs Linux ; pour beaucoup de workflows de dev, c’est la voie la plus simple.
• Développement cross‑platform : vous pouvez construire des artefacts ciblant Linux depuis Windows sans double‑boot.
• Services locaux à faible risque : exécuter une base de données de dev ou un cache peut convenir, tant que vous ne les traitez pas comme une baseline de production.

Les fonctionnalités « bonnes et étranges » de WSL

• Accès cohérent à Windows : vous pouvez appeler des exécutables Windows depuis WSL et vice‑versa. Ce n’est pas « à la Linux », mais c’est extrêmement utile.
• Installation sans friction : vous pouvez provisionner une distro en quelques minutes sans ISO ni gestionnaire de VM.
• Moindre charge opérationnelle : pas de cycle de vie d’un OS invité à surveiller de la même manière qu’une VM complète ; moins de composants à patcher manuellement.

WSL est un excellent choix par défaut pour le développement local tant que vous gardez vos fichiers projets à l’intérieur du système de fichiers WSL (et non sur /mnt/c) et que vous acceptez que certaines hypothèses de « vrai Linux » ne tiennent pas.

Quand WSL n’est pas l’outil adapté (et VirtualBox gagne)

Si vous avez besoin d’« une machine », pas d’« un shell », WSL commence à montrer ses coutures. Voici les cas qui changent la décision.

1) Vous avez besoin d’un comportement au niveau noyau, de modules ou d’observabilité bas niveau

Si vous travaillez sur eBPF, développement de modules noyau, flux iptables/nftables personnalisés qui exigent un contrôle total, ou toute chose nécessitant une configuration noyau spécifique : utilisez une vraie VM. Le noyau de WSL est réel, mais ce n’est pas le vôtre. Vous n’obtenez pas une pleine équivalence avec un noyau de distro et vous ne pouvez pas supposer que vous pouvez charger ce que vous voulez.

2) Vous avez besoin d’un réseau entrant prévisible, d’un comportement L2, ou de sémantiques de « vrai hôte »

Le mode bridgé de VirtualBox donne à l’invité une adresse sur votre LAN. C’est toujours virtualisé, mais cela correspond à « c’est une autre machine ». Le modèle NAT de WSL 2 convient pour les connexions sortantes et le développement localhost. Il l’est moins quand vous avez besoin d’accès entrant depuis d’autres appareils, de découverte multicast, de labos multi‑nœuds, ou de captures de paquets qui doivent voir la vérité.

3) Vous devez tester le boot, l’init, ou le cycle de vie complet de l’OS

Tester les unités systemd, l’ordre de boot, cloud‑init, chiffrement de disque au démarrage, ou des modifications de la ligne de commande du noyau ? Utilisez VirtualBox. WSL s’est amélioré (y compris le support systemd), mais le cycle de vie reste « instance WSL comme environnement géré », pas « un serveur que vous pouvez traiter comme du bétail ».

4) Votre charge est sensible au stockage ou à la correction

WSL est rapide quand vous travaillez sur des fichiers à l’intérieur de son système de fichiers Linux. Il peut être douloureusement lent quand il y a un fort churn de fichiers sur des chemins montés Windows. La voie lente n’est pas un bug ; c’est une frontière. Si votre charge exige de larges checkouts de repo, des arbres node_modules massifs, ou des bases de données qui demandent des sémantiques fsync prévisibles, planifiez autour de cette frontière ou migrez vers une VM.

5) Vous avez besoin de passthrough USB ou d’accès matériel

VirtualBox possède un support USB passthrough mature (avec extension pack) et une histoire assez classique pour attacher des périphériques à un invité. WSL propose quelques options via USB/IP, mais ce n’est pas la même chose. Si vous flashez des appareils, parlez à des dongles, utilisez des adaptateurs série, ou faites du travail embarqué : VirtualBox est généralement la réponse propre.

6) Vous avez besoin d’une forte isolation vis‑à‑vis des outils endpoint d’entreprise

Voici une vérité inconfortable : les outils de sécurité traitent souvent WSL comme « juste un accès de fichiers Windows de plus ». Cela peut signifier un sur‑scannage lorsque vous construisez ou décompactez beaucoup de petits fichiers sur /mnt/c. Une image disque VirtualBox peut être plus isolée car l’hôte voit surtout de gros accès séquentiels en lecture/écriture vers un seul fichier, pas une tempête d’opérations de fichiers.

7) Vous avez besoin d’une reproductibilité stable pour une équipe

WSL est assez reproductible pour beaucoup d’équipes dev, mais il reste lié aux versions Windows, aux versions WSL, et parfois à des comportements d’intégration subtils. Les VMs VirtualBox peuvent être épinglées plus explicitement : ISO connu, version des guest additions, matériel virtuel connu, mode réseau connu. Cela compte quand « ça marche sur ma machine » coûte de l’argent.

Deuxième blague, parce que le stockage mérite toujours une : « Ça marchait jusqu’à ce qu’on mette le repo sur /mnt/c » est la version moderne de « ça marchait sur mon laptop », juste avec plus d’appels système.

Tâches pratiques : commandes, sorties et décisions

Vous ne choisissez pas les outils en vous fiant aux impressions. Vous les choisissez en mesurant le goulot d’étranglement et en vérifiant les hypothèses qui vous trahissent généralement : chemin de système de fichiers, mode réseau, pression mémoire, et frontières hôte/invité. Ci‑dessous des commandes exécutables avec exemples de sorties et ce que vous devez en déduire.

Task 1: Confirm the WSL version and distro state

cr0x@server:~$ wsl.exe --list --verbose
  NAME              STATE           VERSION
* Ubuntu-22.04      Running         2
  Debian            Stopped         2

Ce que ça signifie : Vous êtes sur WSL 2 (VM noyau). Si vous attendiez la sémantique WSL 1 (traduction d’appels système), stoppez : votre chemin de dépannage diffère.

Décision : Si votre problème est lié au noyau/module/pile réseau, traitez WSL comme une VM gérée avec contraintes. N’assumez pas que vous pouvez « simplement ajuster le noyau ».

Task 2: Identify where your project files live (WSL ext4 vs Windows mount)

cr0x@server:~$ pwd
/mnt/c/Users/alex/work/myapp

Ce que ça signifie : Vous construisez sur le système de fichiers Windows via DrvFs. Pour un fort churn de fichiers, c’est la voie lente.

Décision : Si les builds/tests sont lents, déplacez le repo dans le système de fichiers WSL (par ex. /home/alex) avant d’incriminer les compilateurs, Node ou « WSL lent ».

Task 3: Measure filesystem type and mount options inside WSL

cr0x@server:~$ mount | head -n 6
none on / type lxfs (rw,noatime)
none on /mnt/wsl type tmpfs (rw,nosuid,nodev,noexec,relatime)
C:\ on /mnt/c type 9p (rw,noatime,aname=drvfs;path=C:\;uid=1000;gid=1000;metadata;case=off)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=1632048k,mode=755)

Ce que ça signifie : Le lecteur Windows est monté via un mécanisme basé sur 9p. C’est la frontière qui peut écraser les charges de petits fichiers.

Décision : Si votre charge est sensible aux opérations de métadonnées (git status, npm install, yarn, pip, composer), évitez /mnt/c.

Task 4: Quick small-file stress test (diagnose the boundary)

cr0x@server:~$ time bash -lc 'rm -rf /tmp/iotest && mkdir -p /tmp/iotest && for i in $(seq 1 20000); do echo $i > /tmp/iotest/f$i; done'

real    0m2.941s
user    0m0.715s
sys     0m2.147s

Ce que ça signifie : C’est votre base de référence à l’intérieur du système de fichiers Linux.

Décision : Exécutez le même test sous /mnt/c. Si c’est nettement plus lent, le problème de « performance WSL » est en réalité lié au chemin.

Task 5: Repeat the stress test on /mnt/c and compare

cr0x@server:~$ time bash -lc 'rm -rf /mnt/c/Temp/iotest && mkdir -p /mnt/c/Temp/iotest && for i in $(seq 1 20000); do echo $i > /mnt/c/Temp/iotest/f$i; done'

real    0m38.772s
user    0m2.105s
sys     0m15.883s

Ce que ça signifie : Vous payez un overhead inter‑frontière par fichier. Multipliez par les gestionnaires de paquets et ça devient moche.

Décision : Déplacez les charges dans l’ext4 de WSL ou utilisez une VM avec un système de fichiers Linux natif pour cette charge. Ne « optimisez » pas vos flags de compilateur pour corriger une frontière de système de fichiers.

Task 6: Check memory pressure and whether WSL is hoarding RAM

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.1Gi       431Mi       152Mi       1.2Gi       1.1Gi
Swap:          2.0Gi       1.4Gi       612Mi

Ce que ça signifie : La VM WSL est sous pression et swappe. Ça ressemble souvent à « tout est lent », y compris I/O et réseau.

Décision : Pour des charges mémoire soutenues, envisagez d’ajuster les limites WSL ou migrez la charge vers une VM avec un dimensionnement RAM explicite. Le swap en dev, c’est le son de votre après‑midi qui se fait voler.

Task 7: Check WSL kernel and feature expectations (systemd, modules)

cr0x@server:~$ uname -a
Linux cr0x 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 19:10:13 UTC 2023 x86_64 GNU/Linux

Ce que ça signifie : Vous exécutez la saveur du noyau WSL. C’est légitime, mais ce n’est pas la même construction exacte que votre distro.

Décision : Si vous exigez une version/configuration noyau spécifique (par ex. pour des fonctionnalités eBPF, comportement LSM, ou disponibilité de modules), ne prenez pas de risque. Utilisez VirtualBox avec un noyau de distro que vous contrôlez.

Task 8: Diagnose inbound reachability (WSL NAT reality check)

cr0x@server:~$ ip addr show eth0 | sed -n '1,8p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:3a:7c:11 brd ff:ff:ff:ff:ff:ff
    inet 172.28.96.15/20 brd 172.28.111.255 scope global eth0
       valid_lft forever preferred_lft forever

Ce que ça signifie : Votre instance WSL est sur un réseau NAT privé (172.28.x.x). Les autres appareils du LAN ne l’atteindront pas directement.

Décision : Si vous avez besoin que d’autres machines se connectent à des services dans Linux sans gymnastique de port‑proxy, préférez VirtualBox en mode bridgé.

Task 9: Check what Windows thinks your VirtualBox VM networking mode is (guest-side clue)

cr0x@server:~$ ip route
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15

Ce que ça signifie : Cette passerelle 10.0.2.2 est le NAT classique de VirtualBox.

Décision : Si vous avez besoin d’accès entrant depuis votre LAN, NAT est le mauvais mode. Passez en bridgé ou host‑only + routage explicite selon vos besoins.

Task 10: Validate bridged networking on a VirtualBox guest

cr0x@server:~$ ip addr show enp0s3 | sed -n '1,8p'
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.77/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
       valid_lft 7200sec preferred_lft 7200sec

Ce que ça signifie : La VM est sur le même LAN que votre hôte. Les autres appareils peuvent l’atteindre et la découverte de services se comporte normalement.

Décision : Pour les labos, les tests multi‑nœuds, ou les services entrants, c’est souvent la configuration la plus propre.

Task 11: Check disk usage and the “WSL vhdx never shrinks” surprise

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc       1007G   96G  861G  11% /

Ce que ça signifie : À l’intérieur de WSL, vous pouvez avoir beaucoup d’espace libre. Sur Windows, le vhdx sous‑jacent peut rester énorme après des suppressions.

Décision : Si votre disque Windows se remplit, vous devez récupérer de l’espace au niveau du disque virtuel (export/import ou compact). Si vous avez besoin d’un comportement de croissance de disque prévisible, une VM avec gestion explicite des disques peut être plus simple à gérer.

Task 12: Confirm whether systemd is actually PID 1 in WSL

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

Ce que ça signifie : systemd s’exécute comme init. S’il s’agit de init ou d’autre chose, vos attentes en matière de gestion de services peuvent être erronées.

Décision : Si votre stack dépend du comportement des unités et timers systemd comme sur un serveur, assurez‑vous que systemd est activé ; sinon utilisez une VM et arrêtez de négocier avec l’init.

Task 13: Verify you can bind and reach a service from Windows host (WSL localhost integration)

cr0x@server:~$ python3 -m http.server 8080
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...

Ce que ça signifie : Le service écoute. Typiquement Windows peut y accéder via localhost:8080 grâce à l’intégration WSL.

Décision : Si Windows peut y accéder mais pas d’autres appareils du LAN, c’est le NAT WSL par conception. Décidez si vous avez besoin d’une reachabilité LAN ; si oui, envisagez une VM bridgée.

Task 14: Diagnose DNS problems (WSL vs VM behaves differently under VPNs)

cr0x@server:~$ resolvectl status | sed -n '1,18p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 172.28.96.1
       DNS Servers: 172.28.96.1

Ce que ça signifie : Le DNS est médié. Sous certains clients VPN d’entreprise, cela peut casser les attentes de split‑DNS ou causer des échecs intermittents de résolution.

Décision : Si le DNS est instable et que vous avez besoin d’un réseau déterministe pour un labo ou un comportement type CI, une VM avec sa propre NIC en mode bridgé évite souvent ces bizarreries.

Mode d’emploi pour diagnostic rapide

Quand quelqu’un dit « WSL est lent » ou « VirtualBox réseau cassé », vous avez environ cinq minutes pour éviter une journée de superstition. Voici un ordre d’opérations serré qui trouve rapidement le goulot.

Premier : identifiez la frontière que vous franchissez

• Où sont les fichiers ? Si le projet est sous /mnt/c, supposez d’abord une surcharge de frontière système de fichiers.
• Où est le réseau ? Si l’IP de l’invité est dans un espace NAT privé, supposez d’abord des problèmes de reachabilité entrante.
• Où est le CPU ? Si l’hôte est sous charge ou la VM est affamée, supposez planification et pression mémoire.

Second : lancez les trois contrôles « sérum de vérité »

1. Vérification système de fichiers : lancez le test small‑file dans les deux emplacements. Grand delta = problème de frontière, pas « votre appli ».
2. Vérification mémoire : cherchez du swap et peu de mémoire disponible. Swap = tout ment.
3. Vérification réseau : confirmez le type d’adresse IP et la route. NAT vs bridgé vous dit ce qui est possible sans bidouilles.

Troisième : décidez si vous déboguez l’application ou la plateforme

• Si l’échec est causé par des hypothèses noyau/module, visibilité des paquets, réseau entrant, ou sémantiques de stockage : passez à VirtualBox (ou un autre hyperviseur complet).
• Si le problème porte sur l’emplacement des chemins, le réglage des ressources, ou un paramètre d’intégration manquant : corrigez WSL et gardez la boucle dev rapide.

Carte rapide des goulots

• Builds/tests lents : généralement chemin système de fichiers ou surcharge par scanning endpoint.
• Impossible d’atteindre un service depuis une autre machine : NAT WSL ; NAT VirtualBox ; mauvais mode.
• VPN + comportements DNS étranges : DNS médié ; décidez si vous avez besoin d’une NIC réelle.
• Dérive d’horloge/temps : problèmes de synchronisation hôte VM (plus fréquent dans les VMs que WSL).
• « Ça marche sur Linux, pas ici » : inadéquation noyau/module/privilege ; choisissez une VM.

Erreurs courantes : symptômes → cause racine → correction

1) Symptôme : npm/yarn/pip install sont glaciaux dans WSL

Cause racine : Le repo est sur /mnt/c et la charge effectue un grand nombre d’opérations de petits fichiers à travers la frontière Windows↔Linux.

Correction : Déplacez le repo dans /home/<user> à l’intérieur de WSL. Si vous devez conserver les sources sur Windows, envisagez une VM avec dossiers partagés uniquement pour des modifications légères, pas pour des arbres de dépendances.

2) Symptôme : un service bind sur 0.0.0.0 mais d’autres appareils LAN ne peuvent pas y accéder (WSL)

Cause racine : WSL 2 est derrière un NAT. Windows peut souvent y accéder via l’intégration localhost ; votre LAN ne le peut pas.

Correction : Utilisez du proxy/forwarding de ports si acceptable, ou migrez le service dans une VM bridgée (VirtualBox) pour une présence LAN réelle.

3) Symptôme : la capture de paquets ne montre pas le trafic attendu

Cause racine : Le chemin réseau virtuel de WSL et la médiation Windows cachent/transforme ce que vous pensez capturer ; vous capturez peut‑être la mauvaise couche d’interface.

Correction : Utilisez une VM en mode bridgé et capturez sur la NIC invitée, ou capturez sur l’hôte Windows sur la bonne interface. Si vous avez besoin de vérité L2, préférez une VM.

4) Symptôme : l’espace disque Windows disparaît après avoir « supprimé beaucoup de choses » dans WSL

Cause racine : Le disque virtuel WSL grossit mais ne rétrécit pas automatiquement ; les suppressions dans ext4 ne compactent pas immédiatement le VHDX.

Correction : Récupérez de l’espace en compactant / export‑import de la distro. Si cela se reproduit, définissez des attentes : WSL n’est pas un gestionnaire de stockage thin‑provisioning qu’on peut ignorer.

5) Symptôme : « Hyper‑V est activé donc VirtualBox est lent/bizarre »

Cause racine : VirtualBox peut s’exécuter via les API Hyper‑V selon la configuration de l’hôte. La performance et le timing peuvent changer, et certaines fonctionnalités peuvent être impactées.

Correction : Décidez quel hyperviseur est principal. Si vous devez garder les fonctionnalités Hyper‑V, testez VirtualBox sur vos charges de base. Si vous avez besoin de performances VM maximales, envisagez de ne pas empiler des couches de virtualisation concurrentes.

6) Symptôme : les services système ne démarrent pas de façon fiable dans WSL

Cause racine : systemd non activé ou cycle de vie non équivalent à une machine démarrée ; les services d’arrière‑plan peuvent dépendre du comportement d’init.

Correction : Activez systemd pour la distro si approprié et vérifiez PID 1. Si le cycle de vie des services est central à vos tests, cessez de lutter et utilisez une VM.

7) Symptôme : les watchers de fichiers manquent des changements ou déclenchent des tempêtes

Cause racine : Les sémantiques des watchers cross‑filesystem diffèrent ; le comportement inotify sur des chemins montés Windows n’équivaut pas au comportement natif Linux.

Correction : Gardez les arborescences surveillées à l’intérieur du système de fichiers WSL. Pour de grands monorepos avec beaucoup de watchers, une VM peut être plus prévisible.

8) Symptôme : « Ma base de données est plus lente dans WSL que prévu »

Cause racine : Fichiers de la base placés sur /mnt/c, ou pression mémoire hôte causant du swap, ou antivirus scannant le working set.

Correction : Mettez le répertoire de données dans l’ext4 de WSL, allouez plus de mémoire, excluez les chemins appropriés du scanning selon la politique d’entreprise, ou migrez les charges DB dans une VM.

Trois mini‑histoires d’entreprise depuis le terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne (appelons‑la « Northbridge ») a standardisé le dev local sur des laptops Windows. L’équipe plateforme a validé WSL 2 par défaut et est passée à autre chose. C’était un bon choix pour le code quotidien.

Puis une équipe construisant un agent réseau intensif a commencé à tester un comportement « réaliste » dans WSL. Leur agent écoutait des connexions entrantes depuis d’autres machines du LAN d’entreprise. Les développeurs ont rapporté des connectivités intermittentes : parfois ça marchait depuis l’hôte Windows, parfois pas depuis un deuxième laptop. Ils ont d’abord incriminé des règles de firewall, puis l’agent, puis les switches du labo QA, parce que c’est ce que font les humains sous pression temporelle.

La mauvaise hypothèse : « Binder sur 0.0.0.0 dans WSL équivaut à binder sur une NIC hôte ». Ce n’est pas le cas. WSL 2 vit derrière un NAT, et Windows fait un forwarding localhost astucieux qui rend les choses correctes depuis la même machine. Depuis le LAN, c’est autre chose.

L’« incident » n’était pas une panne ; c’était pire : une période de confiance fausse. Ils ont fusionné un changement qui semblait correct dans les tests WSL mais échouait dans un staging avec de vrais hôtes Linux. Deux jours de debug plus tard, la cause racine était simplement que leur plateforme de test ne correspondait jamais à la topologie de déploiement.

La correction a été ennuyeuse et immédiate : ils ont déplacé les tests d’intégration réseau dans des VMs VirtualBox en mode bridgé. WSL est resté pour le code. L’équipe a arrêté d’essayer de faire de WSL un hôte routable. La productivité a augmenté et le nombre de débats a diminué.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise (« Red Quarry ») gérait un grand monorepo avec une chaîne Node lourde. Quelqu’un a décidé « d’optimiser » en gardant le repo sur le système de fichiers Windows pour que les outils natifs Windows puissent l’indexer et pour simplifier les sauvegardes. Le repo était monté dans WSL sous /mnt/c. Tout le monde a dit que c’était la façon moderne et intégrée.

Au début tout allait bien. Puis le nombre de dépendances a augmenté. Les étapes de build ont commencé à créer et supprimer des centaines de milliers de petits fichiers. Les développeurs ont discrètement lancé des builds pendant la nuit. Ce n’est pas un workflow ; c’est une reddition.

L’optimisation a échoué car elle ciblait le mauvais goulot. L’équipe a optimisé pour « une seule copie de fichiers » et « commodité des outils Windows », mais a payé cela par de l’overhead par fichier et une amplification par les scans de sécurité. Chaque création de fichier devenait une opération cross‑frontière plus une inspection de sécurité. La machine travaillait ; juste pas sur ce que l’on demandait.

Finalement, le SRE a exécuté un petit stress test : créer 20k fichiers dans /tmp vs /mnt/c. Le ratio était humiliant. Ils ont déplacé les repos dans le système de fichiers WSL par défaut et ont utilisé des intégrations éditeur pour y accéder. L’indexation a été reconfigurée pour viser les chemins côté Linux quand c’était possible.

Résultat : les temps de build ont fortement chuté sans toucher un seul flag du compilateur. L’« optimisation » nécessaire n’était pas du code plus rapide — c’était moins de traversées de frontières.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une fintech (« Halcyon Ledger ») avait des besoins stricts de reproductibilité. Leurs ingénieurs utilisaient des hôtes Windows, mais leur pipeline de release dépendait du packaging Linux et de comportements proches du noyau. Ils avaient aussi des auditeurs peu réceptifs aux idées sur le choix d’outils.

L’équipe plateforme a pris une décision peu sexy : chaque projet était livré avec une définition VM VirtualBox épinglée, une version de distro connue, et un mode réseau documenté. Les développeurs pouvaient toujours utiliser WSL pour l’édition et des scripts rapides, mais tout ce qui importait — packaging, tests d’intégration, comportement réseau — tournait dans la VM.

Cela semblait être du « travail en plus » jusqu’à ce qu’une mise à jour Windows modifie quelque chose dans le comportement réseau de WSL pour un sous‑ensemble de laptops. Les développeurs ont perdu une demi‑journée à chasser des bizarreries DNS et de redirection de ports. Le pipeline de release n’a pas bronché parce qu’il ne tournait pas sur l’interprétation developer‑de‑WSL de la semaine. Il tournait dans la VM plate et ennuyeuse qui se comportait comme la veille.

L’économie provenait de la prévisibilité, pas de la performance. Les images VM étaient traitées comme des artefacts : versionnées, testées, et parfois remplacées. Personne n’en parlait avec fierté. C’est ainsi qu’on sait que ça marche.

Listes de contrôle / plan pas à pas

Checklist A: Décider WSL ou VirtualBox pour un nouveau projet

1. Avez‑vous besoin de connexions entrantes depuis d’autres machines ? Si oui, préférez VirtualBox en bridgé.
2. Avez‑vous besoin de modules noyau, eBPF, ou réseau bas niveau ? Si oui, préférez VirtualBox.
3. La charge crée beaucoup de petits fichiers ? Si oui, WSL est acceptable seulement si le projet vit dans l’ext4 de WSL.
4. Avez‑vous besoin de périphériques USB ou d’adaptateurs série ? Si oui, préférez le passthrough USB de VirtualBox.
5. La reproductibilité au sein de l’équipe est critique ? Si oui, préférez une VM (VirtualBox) et traitez‑la comme un artefact.
6. Cela concerne surtout des outils CLI et des builds locaux ? Si oui, WSL est généralement la meilleure expérience.

Checklist B: Faire en sorte que WSL se comporte (la configuration « ne pas combattre la physique »)

1. Gardez le code et les arbres de dépendances dans /home, pas dans /mnt/c.
2. Utilisez des éditeurs Windows capables d’ouvrir des chemins WSL sans déplacer les fichiers sur NTFS.
3. Vérifiez systemd si vous en dépendez : checkez PID 1 et l’état des services.
4. Surveillez la mémoire : si vous swappez, ajustez les limites ou changez de plateforme.
5. Soyez explicite sur les attentes réseau : le dev localhost est ok ; la reachabilité LAN n’est pas une fonctionnalité par défaut.

Checklist C: Rendre VirtualBox ennuyeux et fiable

1. Choisissez un mode réseau qui correspond à la réalité :
   • NAT pour le dev sortant uniquement.
   • Bridgé pour « cette VM est un vrai hôte sur le LAN ».
   • Host‑only pour des labos isolés avec routage explicite.
2. Allouez des ressources explicitement : RAM et nombre de CPU. Ne comptez pas sur la croissance dynamique.
3. Utilisez les snapshots avec parcimonie et intention (avant des changements risqués), pas comme mode de vie.
4. Décidez comment vous partagez les fichiers. Les dossiers partagés sont pratiques mais peuvent être plus lents et moins « Linux » qu’un système de fichiers natif.
5. Versionnez votre baseline VM pour les équipes. Si ça compte, épinglez‑la.

Step-by-step: Migrating a project from WSL-on-/mnt/c to WSL ext4

1. Créez un répertoire de travail dans WSL : mkdir -p ~/work.
2. Clonez le repo dans WSL : git clone ... ~/work/myapp.
3. Réinstallez les dépendances dans WSL (ne réutilisez pas aveuglément un cache côté Windows).
4. Mettez à jour la config de l’éditeur pour ouvrir le chemin WSL.
5. Relancez le stress test et votre build. Si le delta n’est pas évident, le goulot n’est pas le système de fichiers.

Step-by-step: Migrating “needs real host networking” from WSL to VirtualBox

1. Créez une VM avec la distro que vous déployez (correspondre à la version majeure).
2. Réglez le réseau sur Bridged Adapter.
3. Installez votre stack et liez les services à la NIC invitée.
4. Validez la reachabilité depuis un autre appareil du LAN.
5. Documentez les paramètres VM (mode NIC, attentes de ports, règles de firewall) dans le repo pour que la prochaine personne n’ait pas à redécouvrir cela par la souffrance.

FAQ

1) WSL 2 est‑il « une vraie VM » ?

Il utilise un vrai noyau Linux dans un environnement de type VM. Mais il est géré et intégré de façons qui le font se comporter différemment d’une VM que vous administrez bout‑en‑bout.

2) Si WSL 2 utilise un vrai noyau, pourquoi dit‑on encore que ce n’est pas du vrai Linux ?

Parce que « vrai Linux » implique généralement le contrôle du noyau, des modules, du cycle de boot, et des comportements prévisibles des périphériques/réseau. WSL est un userland Linux réel sur un noyau géré avec des contraintes d’intégration.

3) Quelle est la plus grosse erreur de performance WSL ?

Mettre votre projet (et surtout les répertoires de dépendances) sur /mnt/c puis exécuter des outils Linux qui créent ou statent des milliers de fichiers.

4) Quand VirtualBox est‑il une mauvaise idée ?

Quand vous avez besoin d’une boucle d’intégration Windows serrée et que vous n’avez pas besoin des sémantiques de machine complète. Aussi quand la configuration hôte de votre organisation rend VirtualBox lent à cause de couches de virtualisation concurrentes — testez sur votre matériel avant de standardiser.

5) WSL peut‑il remplacer VirtualBox pour des labos Kubernetes ?

Parfois. Les clusters single‑node de dev peuvent bien fonctionner. Si vous avez besoin du réalisme réseau multi‑nœuds, d’ingress depuis d’autres machines, ou de comportements CNI qui supposent des nœuds routables, un labo VM est généralement moins surprenant.

6) Pourquoi l’accès localhost marche de Windows vers WSL, mais pas le LAN ?

Parce que Windows et WSL coopèrent pour rediriger certains ports vers localhost. Ce n’est pas la même chose que l’invité WSL ayant une adresse routable sur le LAN.

7) Ai‑je besoin de systemd dans WSL ?

Si vos outils attendent des unités systemd, timers, journal ou dépendances de services, oui. Si vous faites juste des shells et des processus uniques, non. Si vous testez le cycle de boot d’un serveur, utilisez de toute façon une VM.

8) Qu’en est‑il des périphériques USB et des ports série ?

VirtualBox a une histoire simple pour le passthrough USB (avec les composants adéquats). WSL peut gérer certains scénarios d’appareils, mais si l’accès matériel est central, une VM est généralement la voie de moindre regret.

9) Puis‑je faire en sorte que WSL se comporte comme un réseau bridgé ?

Vous pouvez l’approcher avec du forwarding de ports et une configuration réseau côté Windows, mais ce n’est pas le modèle par défaut. Si le bridgé est une exigence, choisissez une VM où le bridgé est un réglage de première classe.

10) Les équipes doivent‑elles standardiser sur un seul outil ?

Standardisez sur les résultats. Pour le codage, WSL est souvent la meilleure expérience sur Windows. Pour les tests d’intégration et la reproductibilité, une baseline VM épinglée est généralement le choix le plus calme.

Prochaines étapes à faire aujourd’hui

• Auditez où vivent vos repos. S’ils sont sur /mnt/c et que vous vous plaignez des performances, déplacez un repo dans /home et re‑mesurez.
• Décidez de votre exigence réseau. Si d’autres machines doivent se connecter en entrant, arrêtez de faire comme si le NAT suffisait. Utilisez VirtualBox en bridgé pour cette charge.
• Exécutez les stress tests et conservez les résultats. Avoir un chiffre de référence transforme les débats en ingénierie.
• Séparez « shell de dev » et « environnement d’intégration ». WSL pour l’itération quotidienne ; VirtualBox pour le réalisme et la reproductibilité quand c’est important.
• Rédigez les règles de frontière. Un guide interne de deux pages vaut vingt threads Slack et un onboarding basé sur le folklore.

Choisissez WSL quand vous voulez la rapidité d’installation et une excellente boucle développeur Windows. Choisissez VirtualBox quand vous avez besoin d’une machine que vous pouvez raisonner — réseau, stockage, comportement noyau, et tout le reste. Utilisez les deux quand vous êtes sérieux : WSL pour le confort, une VM pour la vérité.