WSL ou VPS pour le développement : lequel choisir ?

Faut-il utiliser WSL ou un VPS pour le développement ?

WSL ou un VPS pour le développement, c’est avant tout une question de disponibilité. WSL (Windows Subsystem for Linux) exécute Ubuntu dans une machine virtuelle qui démarre et s’arrête avec votre session Windows. Un VPS (virtual private server) exécute le même Ubuntu sur une adresse IP publique qui reste disponible lorsque votre ordinateur portable est fermé. La plupart des développeurs finissent par utiliser les deux, le serveur étant la machine qui reste accessible.

Le système d’exploitation n’est pas la différence importante, puisque les deux utilisent Ubuntu. Les différences concernent la disponibilité, l’accessibilité depuis Internet, les garanties offertes par systemd, la vitesse des fichiers, le comportement du réseau et la personne qui gère les sauvegardes. Chaque section ci-dessous présente une différence que vous pouvez observer sur votre propre machine.

Pourquoi WSL s’arrête-t-il lorsque vous fermez l’ordinateur portable ?

WSL 2 exécute un véritable noyau Linux dans une machine virtuelle légère que Windows démarre à la demande. Cette machine virtuelle existe uniquement lorsqu’une distribution est en cours d’exécution, et une distribution ne fonctionne que si quelque chose l’utilise. Vérifiez l’état depuis PowerShell :

wsl --version
wsl --list --running

Fermez tous les terminaux WSL, attendez une minute, puis exécutez de nouveau wsl --list --running. Lorsqu’il indique qu’aucune distribution n’est en cours d’exécution, le shell que vous avez démarré a disparu, ainsi que tout ce qu’il exécutait. wsl --shutdown produit immédiatement le même résultat, ce qui permet de tester le comportement de votre configuration après un redémarrage.

La mise en veille et la veille prolongée arrêtent également la machine virtuelle. Un timer configuré pour sauvegarder une base de données à 03:00 ne se déclenche pas lorsque l’ordinateur est fermé, car le noyau qui devrait l’exécuter ne fonctionne pas. Rien n’enregistre d’erreur. Le job donne donc l’impression de n’avoir jamais été planifié. Ce comportement suffit à pousser certaines personnes à utiliser une deuxième machine : une file de builds, un chatbot, une sauvegarde nocturne ou un récepteur de webhook nécessitent tous un ordinateur qui reste allumé.

systemd fonctionne-t-il dans WSL ?

Oui. La prise en charge est arrivée avec WSL 0.67.6 et elle est désactivée par défaut dans les anciennes installations. Sans cette prise en charge, systemctl status ssh affiche :

System has not been booted with systemd as init system (PID 1). Can't operate.

Lisez d’abord le fichier de configuration, car il peut déjà en contenir un. S’il ne contient aucune section [boot], ajoutez-en une. Sinon, ajoutez l’unique ligne dans la section existante.

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

Exécutez wsl --shutdown dans PowerShell, ouvrez un nouveau shell Ubuntu, puis vérifiez avec systemctl list-units --type=service --state=running. Une liste d’unités indique que systemd est le PID 1. À partir de là, journalctl -b fonctionne.

Le point important concerne ce que enable garantit sur chaque machine. Sur un VPS, sudo systemctl enable --now caddy signifie que le service démarre au boot. Il redémarre donc après un redémarrage ou une mise à niveau du kernel, même si personne n’est connecté. Dans WSL, cela signifie que le service démarre lorsque la distribution démarre, et que la distribution démarre lorsque vous ouvrez un terminal. Le service fonctionne donc uniquement pendant que vous travaillez. C’est l’inverse de la raison d’être des services. Les conteneurs présentent le même problème. C’est pourquoi faire démarrer les services Docker Compose au boot dépend d’un boot que WSL n’effectue que lorsque vous le demandez.

Un webhook peut-il atteindre un serveur exécuté dans WSL ?

Pas sans configuration supplémentaire, en raison de l’architecture réseau. Dans son mode par défaut, WSL 2 place la machine virtuelle derrière une NAT (translation d’adresses réseau), sur son propre adaptateur virtuel. Affichez l’adresse :

ip -4 addr show eth0
ip route show default

Cette adresse est privée. Elle est réattribuée à chaque démarrage de la machine virtuelle et peut donc changer. Windows peut tout de même atteindre localhost:3000, car WSL redirige les connexions localhost vers la distribution. Une autre machine de votre réseau ne le peut pas, sauf si vous ajoutez une règle de proxy depuis une PowerShell exécutée en tant qu’Administrator :

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

Cette règle référence une seule adresse. Elle cesse donc de fonctionner dès que l’adresse change. Le mode réseau en miroir est une meilleure option : la distribution utilise les mêmes interfaces et adresses que Windows. En août 2026, il nécessite Windows 11 22H2 ou une version ultérieure. Ajoutez ceci dans %UserProfile%\.wslconfig, puis exécutez wsl --shutdown :

[wsl2]
networkingMode=mirrored

Le mode miroir résout le problème d’accès depuis le réseau local. Il ne vous attribue pas d’adresse publique. Votre routeur effectue de nouveau une NAT, la plupart des connexions résidentielles ne fournissent aucun port entrant que vous contrôlez, et de nombreux FAI ajoutent encore une autre couche de NAT. GitHub ne peut donc pas envoyer un événement en POST à votre portable, et un collègue ne peut pas ouvrir le lien vers votre démonstration. Un service de tunnel permet de contourner ce problème, mais le client du tunnel s’exécute sur le portable. Celui-ci doit donc rester allumé.

Un VPS part du problème inverse. Il possède une adresse IPv4 publique et généralement une adresse IPv6 publique, avec uniquement les ports que vous ouvrez. Pointez un enregistrement A vers celui-ci, autorisez 80 et 443, et il répondra depuis n’importe où. C’est également la condition nécessaire pour obtenir un certificat public, car le challenge HTTP-01 demande à Let's Encrypt de récupérer un fichier via le port 80 sur le nom public. Obtenir un certificat Let's Encrypt avec Certbot et nginx prend cinq minutes sur un serveur et est impossible dans WSL. Pour le développement local, vous pouvez tout de même obtenir un accès HTTPS approuvé par les navigateurs dans WSL en ajoutant votre propre AC au magasin de certificats de confiance d’Ubuntu.

Pourquoi git est-il lent sur /mnt/c ?

Parce que les fichiers ne se trouvent pas sur le système de fichiers Linux. WSL fournit deux espaces de stockage dont les coûts sont très différents. Votre répertoire personnel se trouve sur un système de fichiers ext4 dans un disque virtuel et se comporte comme un disque Linux classique. /mnt/c est le lecteur Windows, exposé via le protocole 9P (protocole de système de fichiers Plan 9) par un composant côté Windows. Chaque ouverture et chaque appel à stat franchissent donc cette frontière.

Un seul fichier ne pose pas de problème. git status sur un dépôt volumineux effectue des milliers d’appels à stat, et chacun d’eux paie ce franchissement. Mesurez plutôt que de faire confiance à un chiffre fourni par quelqu’un, y compris cette page :

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

Exécutez chaque commande deux fois et comparez la deuxième exécution, afin que les deux mesures soient effectuées à chaud. L’analyse antivirus en temps réel de Windows ajoute un coût supplémentaire côté /mnt/c. C’est pourquoi le même dépôt peut sembler plus lent sur un ordinateur portable professionnel que sur un ordinateur personnel.

Dans WSL, la solution consiste à conserver la copie de travail sous ~ et à l’ouvrir avec le mode distant WSL de votre éditeur. Le serveur de l’éditeur s’exécute ainsi dans la distribution au lieu de franchir la frontière. L’Explorateur peut toujours parcourir ces fichiers à l’emplacement \\wsl.localhost\Ubuntu\home\you. Un VPS ne rencontre pas ce problème, car il n’a qu’un seul système de fichiers, Linux. En contrepartie, vous subissez la latence réseau pendant l’édition. Les utilisateurs travaillent donc dans un multiplexeur de terminal ou une session d’éditeur distante. Le partage du CPU est le point à ne pas masquer sur un petit serveur. le temps volé par un voisin bruyant apparaît dans top, dans la colonne st.

Là où WSL s’impose clairement

• Il est gratuit et déjà présent sur la machine. Activez-le, installez Ubuntu et vous pouvez travailler en une minute, sans rien payer ni devoir protéger une surface exposée publiquement.
• Il est jetable, contrairement à un serveur. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar écrit toute la distribution dans un seul fichier, et wsl --import la restaure ou la clone sous un autre nom. Tester une nouvelle version d’Ubuntu revient ici à créer un clone et à pouvoir revenir en arrière, alors que mettre à niveau un VPS de 24.04 vers 26.04 est une opération à sens unique qu’il faut planifier en fonction des services déjà actifs.
• Le calcul sur GPU est direct. Avec un pilote GPU Windows récent, la carte est disponible dans la distribution. Les workloads CUDA et ROCm s’exécutent donc sur du matériel que vous possédez déjà. Louer un GPU de la même catégorie à l’heure coûte réellement de l’argent.
• La boucle d’édition est plus courte. Vos fichiers et votre navigateur sont tous deux locaux. Un serveur de développement sur localhost:5173 s’ouvre donc dans le navigateur auquel vous êtes déjà connecté.

Ce sont de vrais avantages. C’est pourquoi la réponse habituelle consiste à utiliser les deux machines plutôt qu’une seule.

Qui possède les sauvegardes ?

C’est vous, sur les deux machines. Avec WSL, cela surprend souvent. La distribution est un fichier de disque virtuel (ext4.vhdx) situé dans votre profil utilisateur Windows. Aucun fournisseur n’en crée automatiquement un instantané. wsl --unregister Ubuntu le supprime sans possibilité d’annulation, et une réinstallation de Windows l’emporte avec tout le reste. Exportez-la selon une planification que vous respecterez réellement :

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

Sur un VPS, l’instantané du fournisseur vous protège contre la panne de l’hôte. Il ne vous protège pas contre rm -rf dans le mauvais répertoire. Un instantané conservé dans le même compte que le serveur peut disparaître avec lui après le vol d’un identifiant. Envoyez les sauvegardes au niveau des fichiers vers un autre emplacement, puis restaurez-en une avant d’en avoir besoin. Dans les deux cas, la responsabilité vous revient. La différence pratique est qu’un serveur peut envoyer sa propre sauvegarde à 03:00 sans demander à qui que ce soit de laisser un ordinateur portable allumé.

Le pont : SSH de WSL vers le VPS

Une deuxième machine semble contraignante uniquement jusqu’à ce que la connexion soit correctement configurée. Effectuez cette configuration une seule fois dans WSL.

Générez la clé dans la distribution plutôt que du côté Windows, afin que la clé privée reste sur le système de fichiers ext4, avec des permissions Unix acceptées par ssh :

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Les clés Ed25519 sont courtes et rapides, et ssh-copy-id ajoute la clé publique à ~/.ssh/authorized_keys sur le serveur avec les modes corrects. Notions de base sur la gestion des clés SSH explique comment les renouveler et les révoquer par la suite.

Donnez un nom au serveur dans ~/.ssh/config :

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

ssh dev se connecte maintenant. IdentitiesOnly yes empêche le client de proposer toutes les clés qu’il détient, ce qui provoque Too many authentication failures lorsqu’un agent en a plusieurs de chargées. ServerAliveInterval 30 maintient une session sur une connexion domestique pour éviter qu’elle ne se termine sans message.

ForwardAgent yes est la ligne qui simplifie réellement le workflow. Avec votre clé chargée dans l’agent sur l’ordinateur portable, git clone git@github.com:you/app.git fonctionne sur le serveur sans qu’aucune clé privée n’y soit jamais copiée. Testez avec ssh -T git@github.com depuis le VPS ; il doit répondre Hi you! You've successfully authenticated. Ne transférez l’agent que vers des serveurs de confiance, car root sur cette machine peut utiliser le socket de votre agent pendant votre connexion. Sur un serveur partagé avec d’autres personnes, une deploy key par dépôt est plus sûre.

WSL ne maintient pas d’agent actif entre les shells. Chaque nouveau terminal demande donc à nouveau la clé. keychain résout ce problème :

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

Ouvrez un nouveau shell et exécutez ssh-add -l. La commande doit afficher l’empreinte de la clé. Error connecting to agent signifie au contraire que la ligne n’est pas lue. Vérifiez donc que votre shell source bien ~/.bashrc.

Exécutez le travail sur le serveur dans un terminal multiplexer, afin qu’une coupure de connexion ne l’interrompe pas :

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

Le build continue pendant que vous fermez l’ordinateur portable. C’est précisément l’intérêt de la deuxième machine. Le même principe permet de exécuter Claude Code sur un VPS dans tmux et de reprendre la session depuis un autre appareil.

Renforcez la sécurité de la machine avant d’y installer quoi que ce soit. Les dix premières minutes sur un nouveau VPS présente, dans l’ordre qui évite de vous bloquer l’accès, la création d’un utilisateur non-root, le SSH avec clés uniquement, un pare-feu et les mises à jour de sécurité automatiques.

Quelle machine pour quelle tâche ?

Utilisez WSL lorsque le travail se fait sur votre écran. Édition, exécution de la suite de tests, serveur de développement sur localhost, notebooks, expériences GPU : tout ce que vous démarrez puis surveillez.

Utilisez le VPS lorsque le travail doit être accessible ou doit continuer après votre session. URL de staging qu’un client peut ouvrir, endpoint de webhook, tâche cron basée sur une horloge réelle, bot, petite base de données utilisée par un autre service, import lancé le vendredi après-midi.

Si vous ne savez pas encore à quoi servira la deuxième machine, les usages réels d’un VPS est une liste plus utile qu’une comparaison de spécifications, et ce qu’est un VPS explique la virtualisation sous-jacente. Si vos outils fonctionnent uniquement sous Windows, il s’agit d’une autre décision, et Linux comparé à Windows Server est la page correspondante.

Une habitude évite que deux machines deviennent deux machines partiellement configurées : le code est stocké dans git, et les deux machines sont des clientes du dépôt. Aucun élément important ne doit exister sur une seule d’entre elles.

FAQ

Puis-je héberger un site web avec un vrai domaine depuis WSL ?

Pas de manière fiable. WSL 2 se trouve derrière le NAT de votre machine, votre routeur applique ensuite un autre NAT, et la plupart des connexions domestiques ne fournissent aucun port entrant à transférer. Un service de tunnel peut exposer un port local, mais le client du tunnel s’exécute sur l’ordinateur portable : le site devient indisponible dès que l’ordinateur se met en veille. Les certificats compliquent encore la situation, car le challenge HTTP-01 exige que Let’s Encrypt récupère un fichier via le port 80 sur le nom public. Un VPS avec une adresse IP publique et un enregistrement A remplit ces deux conditions sans contournement.

systemctl enable fonctionne-t-il dans WSL ?

Il fonctionne une fois que systemd est activé, ce qui signifie systemd=true sous [boot] dans /etc/wsl.conf, puis wsl --shutdown. Sans cela, systemctl répond System has not been booted with systemd as init system (PID 1). Can't operate. Même lorsque systemd fonctionne, enable démarre le service lorsque la distribution démarre, et la distribution démarre lorsque vous ouvrez un shell. Sur un serveur, la même commande signifie que le service redémarre après un reboot sans qu’aucun utilisateur ne soit connecté.

Pourquoi l’adresse IP de mon WSL change-t-elle constamment ?

Dans le mode NAT par défaut, la machine virtuelle reçoit une nouvelle adresse privée depuis l’adaptateur virtuel WSL à chaque démarrage. Toute règle netsh interface portproxy ou adresse codée en dur cesse de fonctionner après wsl --shutdown. Vérifiez l’adresse actuelle avec ip -4 addr show eth0. Le mode réseau miroir de Windows 11 supprime cette adresse distincte en attribuant à la distribution les mêmes interfaces que Windows : définissez networkingMode=mirrored sous [wsl2] dans %UserProfile%\.wslconfig.

/mnt/c est-il vraiment plus lent, ou est-ce un mythe ?

Il est plus lent, et une minute de test suffit à le démontrer sur votre propre machine. Les fichiers sous ~ résident sur un disque virtuel ext4. Les fichiers sous /mnt/c sont fournis via le protocole 9P par un composant côté Windows ; chaque appel stat traverse donc la frontière, et git status sur une arborescence volumineuse en génère des milliers. Copiez le dépôt dans ~, exécutez time git status deux fois dans chaque emplacement, puis comparez les exécutions à chaud. Conservez vos copies de travail sous ~ et utilisez le mode distant WSL de votre éditeur.

Ai-je encore besoin de WSL une fois que je dispose d’un VPS ?

La plupart des utilisateurs conservent les deux. WSL est gratuit et démarre instantanément. Il reste donc l’environnement où vous modifiez et testez le code ; les tâches GPU y sont également exécutées. Le serveur est la machine qui reste active : il héberge le nom public et exécute les tâches qui doivent continuer après la fermeture de l’ordinateur portable. Conservez le code dans git et considérez les deux environnements comme des clients du dépôt. Vous pouvez ainsi déplacer le travail de l’un à l’autre sans coût.