VS Code Remote WSL : une configuration qui semble native

Ce que « semble natif » signifie réellement

« Natif » n’est pas une ambiance. C’est un ensemble de propriétés mesurables :

• E/S de fichiers rapides où votre éditeur et vos outils ne sont pas pénalisés pour la lecture de nombreux petits fichiers.
• Chemins prévisibles afin que les outils ne soient pas perturbés par les montages de lecteurs Windows ou les bizarreries UNC.
• Comportement Git cohérent (fin de ligne, bits de mode de fichier, sensibilité à la casse) entre outils Windows et Linux.
• Réseau stable où localhost reste localhost, et où les ports se comportent de la même façon chaque matin.
• Extensions s’exécutant au bon endroit — extensions Linux en Linux, extensions UI en Windows.
• Ergonomie du débogage : quand c’est lent ou cassé, vous pouvez prouver la cause en quelques minutes.

Si vous obtenez ces éléments, Remote WSL cesse d’être un « compromis Windows » et devient une station de travail Linux robuste avec un GPU Windows
et un écosystème d’applications attachés. Vous éditez dans VS Code sous Windows, mais vos serveurs de langage, compilateurs, shells et caches de build vivent dans WSL. C’est le principe.

Quelques faits qui expliquent pourquoi WSL fonctionne (et où ça coince)

Quelques points de contexte qui sont réellement utiles quand vous décidez où placer le code, pourquoi un watcher de fichiers échoue,
ou pourquoi une « simple » optimisation devient un cratère :

1. WSL 1 (2016) traduisait les appels système Linux. C’était astucieux, mais avait des limites de compatibilité. WSL 2 est passé à un vrai noyau Linux.
2. WSL 2 exécute Linux dans une VM légère. C’est pourquoi les fonctionnalités du noyau fonctionnent, et pourquoi vous avez désormais un comportement mémoire « type VM ».
3. Les premières versions de WSL 2 utilisaient le NAT avec une IP de VM changeante. Les versions modernes ont amélioré l’intégration, mais il faut savoir de quel côté appartient le port.
4. Le montage du système de fichiers Windows (/mnt/c) est pratique, pas rapide. L’E/S inter-OS a un coût — surtout pour de nombreuses opérations sur de petits fichiers.
5. Ext4 à l’intérieur de WSL est le chemin rapide. Le système de fichiers Linux dans la VM est l’endroit où les builds et les gestionnaires de paquets se comportent correctement.
6. « Remote » de VS Code n’est pas qu’un tour SSH. Il lance un serveur VS Code à l’intérieur de la cible (ici WSL), qui héberge les extensions et les outils de langage.
7. Les limites inotify sont réelles. Les grands monorepos peuvent dépasser les limites des watchers et donner l’impression que « VS Code est cassé » alors qu’il s’agit d’un réglage du noyau.
8. La sensibilité à la casse diffère par défaut. Windows est historiquement insensible à la casse, Linux sensible. Git et les outils peuvent devenir étranges si vous mélangez les hypothèses.
9. WSL s’intègre aux processus Windows. Vous pouvez exécuter code depuis WSL, et appeler des exécutables Windows depuis Linux. C’est à la fois une fonctionnalité et un piège.

Une conclusion opinionnée : si vous tenez à la performance et à la sérénité, gardez votre dépôt dans le système de fichiers Linux de WSL,
pas sous /mnt/c. Vous pouvez toujours l’ouvrir depuis Windows via Remote WSL. Voilà l’astuce.

Comment Remote WSL fonctionne vraiment (pour déboguer calmement)

Le modèle mental

VS Code a deux moitiés dans cette configuration :

• Interface VS Code (Windows) : la fenêtre de l’éditeur, les menus, les raccourcis, le rendu.
• Serveur VS Code (Linux dans WSL) : serveurs de langage, terminaux, opérations Git, débogueurs et la plupart des extensions.

Quand vous « Ouvrez un dossier dans WSL », VS Code installe (ou réutilise) un composant serveur dans votre distribution WSL, puis tunnelise
les opérations de l’éditeur sur un transport local. Si les extensions sont correctement classifiées, elles s’exécutent côté WSL là où se trouve le code.

D’où vient la performance

La plupart des plaintes « VS Code est lent » dans un flux WSL relèvent vraiment d’une de ces causes :

• Mauvais système de fichiers : dépôt sur un lecteur Windows, outils exécutés en Linux, vous payez la pénalité inter-OS à chaque appel stat.
• Watchers : trop de fichiers, limites inotify trop basses, ou un outil qui retombe en sondage.
• Extensions : une extension Windows seule essayant d’interagir avec des chemins Linux, ou une extension qui insiste pour scanner tout votre home.
• Limites de ressources : mémoire WSL en expansion, thrashing de swap, ou trop peu de CPU alloués.
• Mismatches réseau : service lié à 127.0.0.1 dans le mauvais namespace, hypothèses de redirection de port, ou bizarreries de pare-feu.

Si vous pouvez identifier dans quelle catégorie vous êtes, vous pouvez corriger vite. Sinon, vous testerez des conseils « accélérer VS Code »
au hasard jusqu’à casser votre shell et ressentir une déception profonde.

Une citation à garder sur un post-it, paraphrasée car la formulation exacte s’efface : idée paraphrasée —
« L’espoir n’est pas une stratégie », souvent attribuée à la culture fiabilité/exploitation (liée parfois au général Gordon R. Sullivan).
Le point : mesurez d’abord, puis changez.

La configuration idéale : faites ceci, évitez cela

1) Placez le code dans le système de fichiers Linux

Par défaut : clonez dans votre répertoire home WSL (ou un autre emplacement sur ext4), et ouvrez depuis VS Code via Remote WSL.
Cela évite la voie lente classique : des outils Linux réalisant une forte activité méta sur des répertoires montés depuis Windows.

Modèle recommandé :
/home/<you>/src/<project>

À éviter :
/mnt/c/Users/<you>/src/<project>
sauf si le dépôt est minuscule et que vous ne le touchez qu’occasionnellement.

2) Installez les outils dans WSL, pas dans Windows (pour les projets WSL)

Node, Python, Go, Rust, Java : installez-les à l’intérieur de WSL si le projet y vit. Cela garde les chemins, permissions
et comportements d’exécution cohérents. Utilisez les outils Windows quand le projet est natif Windows (comme les applis .NET desktop).

3) Gardez Git discipliné

Git est l’endroit où le dev cross-plateforme meurt silencieusement. Décidez :

• Où Git sera exécuté ? (Réponse : dans WSL, pour les dépôts WSL.)
• Quelle politique de fins de ligne ? (Réponse : idéalement LF dans les dépôts ; appliquez via .gitattributes.)
• Avez-vous besoin des bits de mode de fichier ? (Probablement oui pour les scripts ; assurez-vous de ne pas perdre les bits exécutable.)

4) Soyez explicite concernant Docker

Vous pouvez exécuter Docker Engine à l’intérieur de WSL, ou utiliser l’intégration Docker Desktop. Les deux peuvent convenir. Le mode d’échec est
de les mélanger sans s’en rendre compte, puis de déboguer « pourquoi mon cache d’images a disparu ? » à 2h du matin.

Choisissez un modèle et tenez-vous-en par machine.

5) Prévoyez les watchers de fichiers et les monorepos

Les gros dépôts nécessitent d’augmenter les limites inotify et de surveiller sélectivement. Sinon, votre éditeur, runner de tests ou bundler
basculera en mode sondage et brûlera du CPU comme si on le payait au cycle.

Blague n°1 : Les watchers de fichiers sont comme les commérages au bureau — acceptables en petite dose, catastrophiques quand tout le monde
s’abonne à tout le monde.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont les vérifications de base que j’exécute quand Remote WSL ne semble pas natif. Chaque tâche inclut une commande, un exemple de sortie réaliste,
ce que cela signifie et la décision à en tirer.

Task 1: Confirm you’re in WSL 2 (not WSL 1)

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

Ce que cela signifie : Votre distro utilise WSL 2. Bien — les fonctionnalités du noyau et la compatibilité sont meilleures.
Décision : Si vous voyez VERSION 1, convertissez-la sauf si vous avez une exigence spécifique à WSL 1.

Task 2: Verify where your repo lives (fast path vs slow path)

cr0x@server:~$ pwd
/home/cr0x/src/payments-api

Ce que cela signifie : Vous êtes sur le système de fichiers Linux. C’est le point idéal pour les performances.
Décision : Si ceci affiche un chemin sous /mnt/c, déplacez le dépôt dans /home et rouvrez dans WSL.

Task 3: Check mount type and options (are you on /mnt/c?)

cr0x@server:~$ mount | grep -E ' /mnt/c | / '
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,metadata,case=off)
none on / type overlay (rw,relatime,lowerdir=/mnt/wslg/distro,upperdir=/mnt/wsl/upper,workdir=/mnt/wsl/work)

Ce que cela signifie : Les lecteurs Windows apparaissent comme drvfs. Ils peuvent convenir pour des éditions occasionnelles, pas pour des builds intensifs.
Décision : Si votre dépôt est sur drvfs et que les builds sont lents, relocalisez-le.

Task 4: Confirm VS Code Server is installed and where

cr0x@server:~$ ls -la ~/.vscode-server/bin | head
total 12
drwxr-xr-x 3 cr0x cr0x 4096 Jan 10 09:14 .
drwxr-xr-x 9 cr0x cr0x 4096 Jan 10 09:14 ..
drwxr-xr-x 6 cr0x cr0x 4096 Jan 10 09:14 1a2b3c4d5e6f7g8h9i0j

Ce que cela signifie : Le serveur existe dans votre home WSL.
Décision : Si ce répertoire est absent et que Remote WSL ne peut pas se connecter, l’installation échoue — inspectez les logs (Task 5).

Task 5: Read Remote WSL logs from the server side

cr0x@server:~$ ls -la ~/.vscode-server/.cli/logs | tail -n 3
drwxr-xr-x 2 cr0x cr0x 4096 Jan 10 09:15 20260110T091500
drwxr-xr-x 2 cr0x cr0x 4096 Jan 10 09:20 20260110T092000
drwxr-xr-x 2 cr0x cr0x 4096 Jan 10 09:25 20260110T092500

cr0x@server:~$ tail -n 30 ~/.vscode-server/.cli/logs/20260110T092500/remoteagent.log
[2026-01-10 09:25:14.101] info  Extension host started
[2026-01-10 09:25:14.223] info  Listening on /run/user/1000/vscode-ipc-2f9a.sock
[2026-01-10 09:25:16.012] warn  File watcher failed to start (ENOSPC)

Ce que cela signifie : L’agent distant est lancé, mais le watcher a échoué avec ENOSPC (limite inotify).
Décision : Augmentez les limites inotify (Task 10) et redémarrez VS Code.

Task 6: Verify Git is the Linux Git (not Windows Git) for WSL repos

cr0x@server:~$ which git
/usr/bin/git

cr0x@server:~$ git --version
git version 2.34.1

Ce que cela signifie : Vous utilisez Git Linux.
Décision : Si which git montre un chemin Windows via l’interop, corrigez l’ordre du PATH ou désactivez l’interop pour ce flux.

Task 7: Detect line ending trouble before it becomes a week-long argument

cr0x@server:~$ git config --show-origin --get core.autocrlf
file:/home/cr0x/.gitconfig  input

Ce que cela signifie : input convertit CRLF en LF lors du commit, mais laisse l’arbre de travail tel quel (généralement LF en Linux).
Décision : Pour les dépôts WSL, préférez input ou false et appliquez via .gitattributes.

Task 8: Check whether you’re accidentally working in a Windows path via UNC

cr0x@server:~$ ls -la /mnt/wsl | head -n 5
total 0
drwxr-xr-x  4 root root  80 Jan 10 08:01 .
drwxr-xr-x 15 root root 340 Jan 10 08:01 ..
drwxr-xr-x  2 root root  40 Jan 10 08:01 instances
drwxr-xr-x  2 root root  40 Jan 10 08:01 services

Ce que cela signifie : Vous regardez les montages d’infrastructure WSL. Ce n’est pas un problème en soi.
Décision : Le piège est de stocker des dépôts dans des emplacements Windows et de les ouvrir via un chemin qui semble « Linux » mais ne l’est pas.
Gardez les dépôts dans /home et vous n’aurez pas de soucis.

Task 9: Check disk usage in WSL (is your virtual disk full?)

cr0x@server:~$ df -hT / /home
Filesystem     Type   Size  Used Avail Use% Mounted on
overlay        overlay 251G  210G   29G  88% /
overlay        overlay 251G  210G   29G  88% /

Ce que cela signifie : Vous manquez d’espace. Les gestionnaires de paquets et serveurs de langage ne négocient pas avec des disques pleins.
Décision : Nettoyez les caches, prunez les images Docker, ou étendez le disque virtuel WSL avant que des erreurs aléatoires n’apparaissent.

Task 10: Fix “ENOSPC” watcher errors (increase inotify limits)

cr0x@server:~$ cat /proc/sys/fs/inotify/max_user_watches
8192

cr0x@server:~$ sudo sh -c 'printf "fs.inotify.max_user_watches=524288\nfs.inotify.max_user_instances=1024\n" > /etc/sysctl.d/99-inotify.conf'

cr0x@server:~$ sudo sysctl -p /etc/sysctl.d/99-inotify.conf
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 1024

Ce que cela signifie : Vous avez augmenté la capacité des watchers.
Décision : Si votre dépôt est volumineux (monorepo, node_modules, sorties bazel), c’est souvent indispensable. Redémarrez VS Code pour rattacher les watchers.

Task 11: See if a tool is polling the filesystem (CPU burn clue)

cr0x@server:~$ ps aux --sort=-%cpu | head
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cr0x     13240 85.1  3.2 2869136 528400 ?      Sl   09:12   6:18 node /home/cr0x/src/payments-api/node_modules/.bin/webpack --watch
cr0x     11422 22.4  1.1 1462032 182220 ?      Sl   09:14   1:41 /home/cr0x/.vscode-server/node ... extensionHost

Ce que cela signifie : Quelque chose consomme le CPU de façon excessive. Peut être une compilation légitime, ou un mode watch en sondage.
Décision : Si le CPU est saturé au repos, vérifiez les erreurs de watcher (Task 5/10) et la configuration des outils (exclure les répertoires build, utiliser des watchers natifs).

Task 12: Check WSL memory pressure and swap thrash

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi        13Gi       420Mi       256Mi       1.7Gi       1.1Gi
Swap:          8.0Gi       6.5Gi       1.5Gi

Ce que cela signifie : Vous swappez fortement. Les performances se ressentent comme marcher dans du ciment mouillé.
Décision : Réduisez les builds parallèles, fermez les processus runaway, ou ajustez les limites de ressources WSL. Si cela arrive quotidiennement, réglez la cause, pas le symptôme.

Task 13: Identify large directories that poison indexing (usually node_modules or build outputs)

cr0x@server:~$ du -h -d 1 . | sort -h | tail
120M    ./dist
1.4G    ./node_modules
2.1G    .

Ce que cela signifie : L’indexation et la surveillance seront coûteuses si votre éditeur traite ces répertoires comme du code source.
Décision : Ajoutez des exclusions dans les paramètres VS Code et la configuration des outils ; envisagez des options du gestionnaire de paquets qui réduisent le churn.

Task 14: Confirm port binding behavior (is the service reachable?)

cr0x@server:~$ ss -lntp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:3000      0.0.0.0:*       users:(("node",pid=14222,fd=20))
LISTEN 0      4096   0.0.0.0:5432        0.0.0.0:*       users:(("postgres",pid=981,fd=5))

Ce que cela signifie : Votre serveur de dev est lié à la loopback uniquement (127.0.0.1). C’est correct si vous y accédez depuis le même namespace.
Décision : Si Windows ne peut pas y accéder, liez à 0.0.0.0 lorsque c’est sûr pour le dev, ou utilisez les fonctions de redirection de port Remote.

Task 15: Validate DNS and connectivity from inside WSL

cr0x@server:~$ getent hosts github.com | head -n 1
140.82.114.4    github.com

cr0x@server:~$ ping -c 1 github.com
PING github.com (140.82.114.4) 56(84) bytes of data.
64 bytes from 140.82.114.4: icmp_seq=1 ttl=49 time=18.2 ms

--- github.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Ce que cela signifie : DNS et connectivité sortante fonctionnent.
Décision : Si le DNS est instable, concentrez-vous sur la config réseau WSL et les politiques VPN de l’entreprise plutôt que de blâmer VS Code.

Task 16: Check SSH agent situation (avoid password prompts every 3 minutes)

cr0x@server:~$ ssh-add -l
The agent has no identities.

Ce que cela signifie : Aucune clé chargée. Vous serez invité à entrer un mot de passe, ou les opérations Git échoueront.
Décision : Chargez les clés dans un agent dans WSL ou utilisez un agent Windows ponté avec précaution. Le choix sûr : garder les clés et l’agent dans WSL pour les dépôts WSL.

Task 17: Confirm file descriptor limits (rare, but real in big tooling)

cr0x@server:~$ ulimit -n
1024

Ce que cela signifie : Une limite FD basse peut casser de gros watchers, outils de build ou runners de tests.
Décision : Si vous voyez « too many open files », augmentez-la via les limites shell et/ou la configuration système (prudemment, et avec l’accord de l’équipe).

Recette de diagnostic rapide

Quand Remote WSL paraît lent ou cassé, ne vous éparpillez pas. Exécutez une boucle serrée qui identifie rapidement la classe de goulot.

Première étape : prouvez où est le dépôt et où tournent les outils

• Dans le terminal WSL à l’intérieur de VS Code : pwd et mount | grep /mnt/c.
• Si votre dépôt est sous /mnt/c, supposez un surcoût du système de fichiers jusqu’à preuve du contraire.
• Confirmez que vous utilisez les toolchains Linux : which git, which node, which python.

Deuxième étape : vérifiez l’état des watchers et la pression d’indexation

• Consultez les logs serveur pour ENOSPC ou les échecs de watcher.
• Vérifiez /proc/sys/fs/inotify/max_user_watches.
• Mesurez la taille du dépôt : du -h -d 1 . | sort -h | tail et décidez quoi exclure.

Troisième étape : vérifiez CPU, mémoire et swap

• ps aux --sort=-%cpu | head pour attraper les watchers et compilateurs runaway.
• free -h pour repérer le thrash de swap.
• Si la mémoire est serrée, réduisez la concurrence, tuez le processus coupable, puis ajustez les ressources WSL en politique — pas en rituel.

Quatrième étape : vérifiez le réseau seulement après les étapes ci-dessus

• ss -lntp pour la vérité sur les bindings de port.
• getent hosts pour la sanity du DNS.
• Ne touchez au pare-feu/VPN qu’après — sinon vous « corrigez » la mauvaise couche et cassez autre chose.

Blague n°2 : Si votre première étape de debug est de réinstaller VS Code, vous ne dépannez pas — vous pratiquez une exorcisme.

Erreurs courantes : symptôme → cause racine → correction

1) « Tout est lent, surtout npm install / git status / indexation TypeScript »

Symptôme : Les commandes touchant de nombreux fichiers rampent ; les ventilateurs tournent ; VS Code est lent.

Cause racine : Le dépôt se trouve sur /mnt/c (drvfs) alors que les outils tournent dans WSL.

Correction : Déplacez le dépôt vers /home/<you>/src, reclonez si nécessaire, rouvrez via Remote WSL.

2) « VS Code ne peut pas surveiller les fichiers ; les changements ne déclenchent pas de rebuild ; les logs montrent ENOSPC »

Symptôme : L’auto-reload s’arrête, les tests ne relancent pas, l’hôte d’extension avertit des watchers.

Cause racine : Les limites inotify sont trop basses pour la taille du dépôt.

Correction : Augmentez fs.inotify.max_user_watches et max_user_instances (Task 10), puis redémarrez.

3) « Git affiche sans cesse des diffs massifs, ou les fichiers changent de fins de ligne »

Symptôme : Chaque commit inclut des changements non liés ; les coéquipiers se disputent sur CRLF.

Cause racine : Configurations Git mixtes entre Windows et WSL ; absence de .gitattributes.

Correction : Standardisez sur LF dans le dépôt avec .gitattributes ; utilisez Git Linux dans WSL ; mettez core.autocrlf=input (ou false) pour les workflows WSL.

4) « Remote WSL se déconnecte ou reste bloqué sur ‘Installing VS Code Server’ »

Symptôme : Boucles de reconnexion ; l’installation du serveur ne se termine jamais.

Cause racine : Disque plein, problèmes de permissions dans le home, ou installation serveur corrompue.

Correction : Vérifiez df -h, consultez les logs sous ~/.vscode-server/.cli/logs, et supprimez le répertoire de la version serveur problématique pour forcer la réinstallation.

5) « Les ports fonctionnent dans WSL mais pas depuis le navigateur Windows »

Symptôme : Service joignable avec curl localhost dans WSL, mais Windows ne peut pas se connecter.

Cause racine : Service lié à 127.0.0.1 dans le namespace WSL ; hypothèses de redirection de port fausses.

Correction : Liez à 0.0.0.0 quand c’est sûr pour le dev, ou utilisez le forwarding de ports Remote ; vérifiez avec ss -lntp.

6) « Mon build utilise des outils Windows même dans WSL »

Symptôme : Chemins étranges ; variations de performance ; binaires dans des emplacements inattendus.

Cause racine : L’interop Windows dans le PATH fait que des exécutables Windows sont choisis en premier.

Correction : Vérifiez avec which ; réordonnez le PATH ; soyez explicite dans les scripts ; envisagez de limiter l’interop pour les shells de dev.

7) « Les images Docker disparaissent selon l’endroit où j’exécute les commandes »

Symptôme : docker images diffère entre terminaux ; les builds se répètent sans cesse.

Cause racine : Mélange entre l’intégration Docker Desktop et un Docker Engine séparé dans WSL.

Correction : Choisissez un modèle : contexte géré par Desktop ou moteur natif. Standardisez sur un seul par machine et documentez la décision pour l’équipe.

8) « Les renommages sensibles à la casse ne se comportent pas ; les imports échouent en CI mais pas localement »

Symptôme : Ça marche sur votre machine, échoue sur la CI Linux, ou inversement.

Cause racine : Incompatibilité de sensibilité à la casse et Git n’enregistrant pas proprement la sémantique du renommage.

Correction : Faites les renommages soigneusement (nom temporaire puis nom final), assurez-vous que la CI correspond à la production, et n’entreposez pas les dépôts sur des montages insensibles à la casse si vous avez besoin des sémantiques Linux.

Trois mini-récits d’entreprise depuis le terrain

Incident : la mauvaise hypothèse (l’emplacement du dépôt « n’a pas d’importance »)

Une équipe passant des MacBooks à Windows voulait une bascule en un week-end. Ils ont choisi WSL 2, installé VS Code et déclaré victoire
après que l’application démo se soit construite avec succès. L’hypothèse était implicite : « les fichiers sont des fichiers, le stockage est du stockage ».

Dès le lundi après-midi, les développeurs ont signalé que git status mettait une éternité, les tests étaient incohérents, et les services
TypeScript timeoutaient. Les tentatives de corrections rapides ont commencé : réinstaller des extensions, changer de version Node, et basculer des réglages au hasard.
Résultat : échecs différents, même frustration.

La cause racine était ennuyeuse : les dépôts avaient été clonés dans C:\Users\...\src et ouverts via WSL. Chaque outil Linux martelait drvfs avec des dizaines de milliers d’opérations méta.
Sur un petit dépôt, on pourrait ne jamais le remarquer. Sur un monorepo d’entreprise, c’est une taxe à payer à chaque frappe.

La correction a été tout aussi ennuyeuse : déplacer les clones dans /home, rouvrir en Remote WSL, et arrêter d’exécuter Git Windows contre des arbres de travail WSL.
En moins d’un jour, les plaintes ont cessé. Pas de magie. Les outils opéraient enfin sur le système de fichiers pour lequel ils étaient conçus.

Optimisation qui a mal tourné : « Accélérons en partageant node_modules sur Windows »

Un autre groupe a voulu être malin avec le caching. Leurs portables Windows avaient beaucoup de stockage, et ils voulaient éviter des réinstallations répétées dans WSL.
L’idée : garder node_modules côté Windows et le monter ou le symlinker dans les projets WSL. Une installation pour plusieurs projets, moins de téléchargements.

Pendant deux jours, cela semblait gagner. Les installs étaient plus rapides — du moins au premier passage. Puis sont arrivées les étrangetés : les modules natifs échouaient à la compilation,
les binaires avaient de mauvaises attentes ABI, et « marche sur ma machine » devenait « marche jusqu’au reboot ». La surveillance de fichiers s’est même aggravée.

Le problème caché était qu’ils avaient optimisé la mauvaise contrainte. Le goulot n’était pas le téléchargement ; c’était le churn du système de fichiers et les sémantiques inter-OS.
L’écosystème Node effectue beaucoup de petites opérations fichier et attend un comportement POSIX. Placer les répertoires les plus sollicités sur drvfs a provoqué des cas limites et une dette de performance permanente.

Ils ont annulé et adopté une règle claire : les dépendances restent avec le projet sur ext4, les caches sont autorisés mais doivent être natifs WSL, et l’équipe n’utilise un miroir de registre réel
que si le réseau est le point douloureux. Leurs builds sont redevenus prévisibles, ce qui est le type de « rapidité » que l’on peut planifier.

Pratique ennuyeuse mais correcte qui a sauvé la mise : standardiser la baseline dev

Une équipe plateforme supportant plusieurs équipes produits avait un autre problème : pas de performance, mais de l’incohérence. Les distros WSL avaient dérivé.
Différentes versions d’Ubuntu, différents paquets système, différentes configs Git. Déboguer était de l’archéologie.

Ils ont fait le travail peu sexy : une checklist baseline et un script bootstrap unique. Il vérifiait WSL 2, assurait que les dépôts vivaient dans /home, réglait les limites inotify,
pinait un petit ensemble de versions d’outils, et affichait des sorties claires quand quelque chose ne correspondait pas. Pas d’UI fancy. Juste des valeurs par défaut disciplinées.

Des semaines plus tard, une mise à jour Windows a déclenché une vague de rapports « Remote WSL déconnecté ». Les équipes suivant la baseline se sont remises en quelques minutes
parce qu’elles avaient des points de contrôle connus : espace disque libre, chemin des logs serveur, et un petit ensemble de fichiers de config à comparer. Les autres équipes ont perdu
une demi-journée chacune à essayer des fixes de forum au hasard.

La pratique n’était pas glamour. Elle n’a récompensé personne d’un trophée performance. Mais elle a réduit le temps moyen pour retrouver la raison, et c’est ce que l’ingénierie orientée production recherche vraiment.

Listes de contrôle / plan étape par étape

Checklist A : Le baseline « sensation native » (à faire une fois par machine)

1. Confirmer WSL 2 : wsl.exe -l -v montre VERSION 2 pour votre distro.
2. Mettre à jour les paquets dans WSL et installer les outils de base (git, build-essentials, toolchains).
3. Créer un répertoire workspace sensé : ~/src et cloner les dépôts là.
4. Ouvrir VS Code via Remote WSL en lançant code . depuis l’intérieur du dépôt en WSL.
5. Augmenter les limites inotify (surtout pour JS/TS, monorepos) : régler les valeurs sysctl et les appliquer.
6. Définir la politique Git : choisir LF et l’appliquer avec .gitattributes ; s’assurer que Git WSL est utilisé pour les dépôts WSL.
7. Choisir le modèle Docker : intégration Desktop ou moteur natif — choisissez une option et documentez-la pour votre futur vous.
8. Exclure les répertoires inutiles dans les paramètres VS Code : outputs de build, dossiers de dépendances, caches d’outils selon le cas.
9. Vérifier SSH : assurez-vous que les clés et l’agent sont disponibles dans WSL pour les opérations Git.

Checklist B : Onboarding d’un nouveau dépôt (par projet)

1. Cloner dans ~/src en WSL.
2. Ouvrir avec code . (depuis WSL) pour que VS Code s’attache correctement.
3. Exécuter la commande bootstrap du projet et surveiller les avertissements de watcher.
4. Vérifier l’exposition des ports avec ss -lntp et décider s’il faut binder sur 127.0.0.1 ou 0.0.0.0.
5. Vérifier l’utilisation disque après l’installation des dépendances (df -h, du) et décider si des règles de nettoyage sont nécessaires.

Checklist C : Quand ça devient soudainement lent (triage en 10 minutes)

1. Le dépôt est-il sous /mnt/c ? Si oui, arrêtez et déplacez-le.
2. Les logs montrent-ils ENOSPC ? Si oui, augmentez les limites inotify.
3. Le CPU est-il saturé au repos ? Identifiez le processus et vérifiez s’il est en sondage ou effectue du travail légitime.
4. Le swap est-il fortement utilisé ? Réduisez la concurrence et tuez les processus runaway ; puis ajustez les ressources.
5. Only then: vérifiez le réseau et les contraintes VPN.

FAQ

1) Dois-je stocker mes dépôts dans Windows et juste utiliser les outils WSL ?

Non pour tout ce qui est non trivial. C’est la cause n°1 des rapports « WSL est lent ». Placez les dépôts dans le système de fichiers Linux de WSL et ouvrez-les via Remote WSL.

2) WSL 2 est-il toujours meilleur que WSL 1 pour VS Code Remote ?

Pour les stacks modernes, oui. Le vrai noyau de WSL 2 améliore la compatibilité et le comportement des outils. WSL 1 peut convenir pour certains patterns I/O, mais c’est l’exception aujourd’hui.

3) Pourquoi VS Code installe-t-il quelque chose à l’intérieur de WSL ?

Parce que Remote WSL exécute un serveur VS Code dans l’environnement Linux. Ce serveur héberge les extensions et les outils de langage proches de votre code et toolchain.

4) Mon extension fonctionne sous Windows mais pas dans WSL. Est-ce un bug ?

Parfois c’est simplement que l’extension s’exécute du mauvais côté. Certaines extensions doivent tourner là où sont le système de fichiers et les outils. Préférez les extensions qui supportent l’exécution distante proprement.

5) Comment empêcher les watchers de fichiers de faire fondre mon CPU ?

D’abord, augmentez les limites inotify si vous obtenez ENOSPC. Ensuite, excluez les outputs de build et les dossiers de dépendances de la surveillance/indexation. Enfin, vérifiez si un outil est en sondage.

6) Quelle est la meilleure approche pour les clés SSH : agent Windows ou agent WSL ?

Pour les dépôts WSL, gardez les clés et un agent dans WSL. Cela réduit les bizarreries transfrontalières. Si la politique d’entreprise exige des clés gérées par Windows, pontifiez délibérément et testez.

7) Pourquoi Windows ne peut-il pas atteindre mon service WSL sur localhost ?

Généralement parce que le service est lié à 127.0.0.1 dans WSL, ou que le forwarding de port n’est pas configuré comme vous le pensez. Vérifiez avec ss -lntp et liez de façon appropriée.

8) Puis-je utiliser Docker dans WSL sans Docker Desktop ?

Oui, vous pouvez exécuter Docker Engine dans WSL. L’important est la cohérence : ne mélangez pas cela avec les contexts Docker Desktop à moins d’aimer poursuivre des caches fantômes.

9) Pourquoi Git se comporte différemment entre Windows et WSL ?

Les différences incluent les fins de ligne, les bits de mode de fichier et les hypothèses de sensibilité à la casse. Choisissez un seul environnement Git pour un dépôt (Git WSL pour les dépôts WSL) et appliquez la politique via .gitattributes.

10) Quelle est la meilleure amélioration unique pour la « sensation native » ?

Déplacez le dépôt dans le système de fichiers Linux de WSL. Tout le reste est un réglage autour de cette décision fondamentale.

Conclusion : étapes pratiques suivantes

Si vous voulez que Remote WSL semble natif, arrêtez de le traiter comme une nouveauté et commencez à le traiter comme une station de travail avec une topologie.
Placez le code là où les outils Linux sont rapides. Exécutez les outils là où les sémantiques du système de fichiers correspondent. Réglez les limites des watchers sérieusement. Et quand quelque chose casse, mesurez d’abord.

Étapes suivantes à faire aujourd’hui :

• Créez ~/src dans WSL et reclonez un dépôt de taille moyenne là-bas.
• Ouvrez-le avec code . depuis WSL et vérifiez which git et pwd.
• Augmentez préventivement les limites inotify si vous avez un gros dépôt ou une toolchain JS.
• Exécutez la recette de diagnostic rapide une fois quand tout va bien afin de savoir à quoi ressemble le normal.

Le bénéfice n’est pas seulement la vitesse. C’est la prévisibilité. Et la prévisibilité vous permet d’expédier sans transformer votre portable en second emploi.