Ubuntu on WSL development on Windows

XDA a soutenu cette année qu’Ubuntu sur Windows est sur le point de devenir plus populaire qu’Ubuntu lui-même, et la raison est ennuyeuse de la meilleure façon. WSL2 a cessé d’être une curiosité et est devenu le moyen par défaut de toucher Linux sur un ordinateur portable professionnel qui doit exécuter Teams, un agent EDR et un VPN d’entreprise. Le chemin de mise à niveau est une seule commande, le noyau est réel et la pile réseau se comporte enfin. Ce qui manque toujours, c’est la boîte à outils : un éditeur qui traite le côté Linux comme une classe de première, un terminal qui ne lutte pas contre tmux, un runtime de conteneur qui respecte le backend WSL2 et une invite qui dit la vérité sur l’état de git. Cet aperçu couvre les meilleures applications pour le développement d’Ubuntu sur WSL sur le bureau, basé sur une utilisation quotidienne sur Windows 11 24H2 et Ubuntu 24.04 LTS dans WSL.

Qu’y a-t-il à chercher dans une application WSL dev

Tous les outils Linux ne sont pas de bons outils WSL. Ceux qui correspondent partagent quatre traits. Premièrement, ils respectent la limite du système de fichiers WSL, de sorte que les travaux d’E/S lourds restent du côté Linux (~/), pas sur /mnt/c/, où les appels entre VM s’enlisent. Deuxièmement, ils s’exécutent soit nativement sur Windows et accèdent à WSL de manière propre, soit ils s’exécutent dans Ubuntu et parlent à Windows via wslg pour les applications GUI et le transfert localhost pour les services. Troisièmement, ils jouent bien avec les contraintes corporatives : pas de pilotes de noyau, pas besoin de désactiver Hyper-V, pas d’hostilité de proxy. Quatrièmement, ils sauvegardent l’état lors des redémarrages de la VM WSL, ce qui se produit plus souvent que la plupart des guides ne l’admettent. Choisissez les outils qui réussissent les quatre et l’environnement cesse de ressembler à une pile de solutions de contournement.

Comparaison rapide

App Best for Runs on Free plan Starting price License
Visual Studio Code + WSL extension The default editor for most WSL work Windows, reaches into WSL Yes, fully Free MIT (with Microsoft telemetry)
Windows Terminal Terminal shell for WSL, PowerShell, and Command Prompt in one window Windows 11 (ships built-in) Yes, fully Free MIT
Docker Desktop Containers with the WSL2 backend Windows (uses WSL2 VM) Yes, personal use $9 per user per month for business Proprietary
JetBrains Toolbox (IntelliJ, PyCharm, WebStorm, GoLand, Rider) Language-aware IDEs that see Linux paths Windows, project inside WSL 30-day trial Around $16.90 per month for IntelliJ Ultimate individual Proprietary
oh-my-posh A prompt that shows git, k8s, and Python context on bash, zsh, and PowerShell Ubuntu (WSL) and Windows Yes, fully Free MIT
tmux Session persistence and split panes inside the WSL shell Ubuntu (WSL) Yes, fully Free ISC
GitHub CLI Everyday GitHub work without leaving the terminal Ubuntu (WSL) and Windows Yes, fully Free MIT
Warp A modern terminal with AI command help Ubuntu (WSL) and Windows Yes, individual free tier $15 per user per month for Warp Teams Proprietary

Les applications

1. Visual Studio Code avec l’extension WSL, le meilleur pour la configuration de montage par défaut WSL

Visual Studio Code pour le développement WSL n’est pas vraiment un éditeur plus un plug-in, c’est un arrangement à deux processus où l’interface utilisateur s’exécute sous Windows et les serveurs de langage, git et le terminal intégré s’exécutent tous à l’intérieur d’Ubuntu. Installez le pack Remote Development, exécutez code . à partir d’un shell WSL et l’extension déposera un petit serveur du côté Linux, créera un lien symbolique du projet et ouvrira une fenêtre qui se comporte comme si toute la chaîne d’outils était native. Les adaptateurs de débogage, les tâches, les ports transférés à localhost et les complétions Copilot traversent tous la limite sans configuration supplémentaire.

Où il manque : l’hôte Windows-side extension et le serveur Linux-side peuvent se désynchroniser lorsque le noyau WSL se met à jour, ce qui nécessite une réinstallation manuelle du serveur. Les très grands monorepos atteignent un plafond de mémoire plus rapidement qu’ils ne le feraient dans un VS Code Linux natif car les deux processus maintiennent une copie de travail.

Tarification :

Plates-formes : Windows, macOS, Linux (dans cet article, l’hôte Windows atteignant Ubuntu sur WSL).

Télécharger : Microsoft Store ou site Visual Studio Code.

Conclusion : le choix par défaut pour la plupart des travaux WSL, et celui à installer en premier avant de décider quoi que ce soit d’autre.

2. Windows Terminal, la meilleure base gratuite pour un shell WSL

Windows Terminal est livré avec Windows 11, ouvre un nouvel onglet WSL Ubuntu à partir d’une liste déroulante et affiche le texte sur le GPU, ce qui compte lorsqu’un journalctl -f se défile rapidement. Les profils couvrent les distros WSL, PowerShell 7 et le Command Prompt hérité dans une fenêtre, et chaque profil a son propre répertoire de démarrage, sa police, son schéma de couleurs et ses variables d’environnement. Le fichier settings.json est archivé dans un référentiel dotfiles sans aucun portage, et les volets divisés facilitent le maintien d’une construction dans un volet et d’une queue de journal dans un autre.

Où il manque : l’interface utilisateur des paramètres est encore en retard sur le JSON, et il n’y a pas de sauvegarde de session intégrée et de restauration comme tmux, donc un redémarrage de Windows perd la disposition du volet.

Tarification :

Plates-formes : Windows 10 build 19041 et versions ultérieures, Windows 11 (par défaut).

Télécharger : Microsoft Store ou GitHub.

Conclusion : le terminal à garder épinglé à la barre des tâches ; tous les autres terminaux de cette liste s’exécutent toujours à l’intérieur ou à côté de celui-ci.

3. Docker Desktop, le meilleur pour les conteneurs avec le backend WSL2

Docker Desktop sur Windows utilise WSL2 pour sa VM Linux, ce qui signifie que Docker et le distro Ubuntu partagent le même noyau et le même dockerd. L’activation de l’intégration WSL pour le distro Ubuntu expose les CLI docker et docker compose directement dans le shell Ubuntu, sans aucun shim docker.exe entre les deux, et les montages de volume depuis /home/<user>/... atteignent une vitesse de disque quasi native. Buildx, Kubernetes et la numérisation d’images sont tous dans l’application de barre d’état.

Où il manque : Docker Desktop n’est gratuit que pour les particuliers, l’éducation et les petites entreprises (moins de 250 employés et moins de 10 millions de dollars de chiffre d’affaires annuel). Les plus grandes équipes ont besoin d’un abonnement payant. Il consomme également plusieurs gigaoctets de RAM même en mode inactif car la VM WSL reste chaude.

Tarification :

Plates-formes : Windows 10/11 (backend WSL2), macOS, Linux.

Télécharger : site Docker.

Conclusion : le chemin de la moindre résistance pour les conteneurs sur WSL, à moins que l’équipe ne soit assez grande pour déclencher le niveau payant, auquel cas Podman Desktop ou plain docker à l’intérieur d’Ubuntu vaut le coup d’évaluer.

4. JetBrains Toolbox, le meilleur pour les IDE conscientes du langage qui comprennent WSL

JetBrains Toolbox installe et met à jour IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider et le reste de la gamme JetBrains, et chaque IDE a le support WSL2 intégré. Ouvrez un projet stocké sous \\wsl$\Ubuntu\home\<user>\... et l’IDE exécute son indexation, sa construction et ses exécuteurs de test à l’intérieur d’Ubuntu via un backend sans tête, avec l’interface utilisateur du côté Windows. Cela correspond à la façon dont VS Code fonctionne, de sorte que les observateurs de fichiers restent du côté Linux de la limite et la JVM n’a pas à contester NTFS.

Où il manque : les IDE payants sont le point, et les prix s’accumulent si un projet touche plusieurs langages. L’indexation d’un grand monorepo à travers la limite WSL peut prendre plus de temps à la première ouverture que sur une installation Linux bare-metal.

Tarification :

Plates-formes : Windows, macOS, Linux (Toolbox comme gestionnaire, backends IDE dans WSL Ubuntu).

Télécharger : site JetBrains.

Conclusion : le bon choix quand le langage mérite un IDE plutôt qu’un éditeur, et vaut le coup pour les équipes déjà investies dans la pile JetBrains.

5. oh-my-posh, le meilleur pour une invite qui survit aux changements de shell

oh-my-posh est un seul binaire Go qui rend une invite thématisable pour bash, zsh, fish, PowerShell et nushell, en utilisant une seule configuration JSON ou YAML sur tous. Sur WSL cela paie deux fois : la même invite s’affiche dans une session bash Ubuntu et dans un onglet PowerShell Windows de Windows Terminal, de sorte que les ancres visuelles (branche git, état sale, cluster actuel, virtualenv, temps d’exécution) sont identiques peu importe quel shell détient le travail en cours. Les thèmes sont activement maintenus et les glyphes de polices Nerd se rendaient proprement avec Cascadia Code NF.

Où il manque : le statut git lent sur les très grands référentiels peut ajouter quelques centaines de millisecondes par rendu d’invite, ce qui est correctible en accordant le segment git mais est activé par défaut. La configuration est JSON, pas un script shell, ce qui est une courbe d’apprentissage pour tous ceux qui viennent d’une PS1 fait à la main.

Tarification :

Plates-formes : Ubuntu (WSL), Windows, macOS.

Télécharger : GitHub.

Conclusion : le plus petit changement avec le plus grand rendement de qualité de vie, et vaut la peine d’installer le premier jour d’une nouvelle configuration WSL.

6. tmux, le meilleur pour la persistance des sessions dans WSL

tmux résout les deux problèmes qui brisent le flux dans WSL : perdre une session shell lors du redémarrage de la VM WSL et manquer d’espace horizontal dans une seule fenêtre de terminal. Un serveur tmux en cours d’exécution maintient chaque volet, fenêtre et processus en cours d’exécution vivant lors des reconnexions, et tmux attach reprend exactement où la dernière session s’est terminée. Les volets divisés donnent une construction dans une colonne, une queue de journal dans une autre et un shell scratch dans une troisième, tout cela dans un seul onglet Windows Terminal.

Où il manque : les liaisons de clés par défaut sont notoirement peu conviviales, donc la plupart des utilisateurs les réécrivent, et l’intégration du presse-papiers avec l’hôte Windows nécessite un assistant comme wl-copy ou clip.exe connecté à .tmux.conf.

Tarification :

Plates-formes : Linux (natif dans WSL Ubuntu), macOS.

Télécharger : GitHub ou installer via apt sur Ubuntu.

Conclusion : le choix pour tous ceux qui exécutent des tâches longues, SSH dans des hôtes distants depuis WSL ou veulent que la disposition du volet survive à un redémarrage d’ordinateur portable.

7. GitHub CLI, le meilleur pour le travail GitHub sans quitter le shell

GitHub CLI (gh) transforme la création de demandes d’extraction, l’examen, le checkout et l’inspection des journaux CI en commandes simples qui s’exécutent dans Ubuntu sur WSL. Authentifiez-vous une fois avec gh auth login et le même jeton fonctionne pour cloner les référentiels privés, ouvrir les RP et déclencher les workflows. Parce qu’il s’exécute dans Ubuntu, il joue avec git, jq, fzf et tous les autres CLI de l’écosystème Linux sans traduction de shell.

Où il manque : GitHub-only, donc les équipes sur GitLab ou Bitbucket ont besoin de glab ou bb respectivement. Certaines nouvelles fonctionnalités Web (Copilot chat dans les RP, Vues Projets V2) traînent sur leurs homologues web.

Tarification :

Plates-formes : Ubuntu (WSL), Windows, macOS.

Télécharger : GitHub ou installer via apt à partir du référentiel GitHub CLI sur Ubuntu.

Conclusion : le moyen le plus rapide de fermer la boucle entre une branche locale dans WSL et une RP fusionnée sur GitHub, en particulier dans les flux de libération scriptés.

8. Warp, le meilleur pour un terminal moderne avec IA intégrée

Warp est un terminal basé sur Rust avec rendu GPU, sortie de commande basée sur des blocs et un panneau IA qui suggère, explique et réécrit les commandes shell. Sur WSL, il s’exécute de deux façons : en tant qu’application Linux à l’intérieur d’Ubuntu (rendue via wslg) ou en tant que client Windows natif qui ouvre un profil WSL de la même manière que Windows Terminal. Les blocs de commandes sont individuellement partageables et consultables, et l’IA a accès à l’historique des blocs récents, de sorte que la sortie d’erreur se transforme en question en une seule frappe.

Où il manque : les fonctionnalités IA envoient le contexte du prompt aux serveurs de Warp, ce qui est un bloqueur difficile dans certains environnements réglementés. Les niveaux individuels et d’équipe nécessitent un compte pour débloquer la plupart des fonctionnalités, ce qui est plus de friction que Windows Terminal.

Tarification :

Plates-formes : macOS, Linux (natif), Windows (natif) et dans WSL Ubuntu.

Télécharger : site Warp.

Conclusion : le choix pour les développeurs qui veulent de l’aide IA sans alt-tab sur une fenêtre de chat, à condition que la politique de flux de données soit acceptable.

Comment choisir le bon

Si un ordinateur portable Windows est neuf et que l’objectif est un environnement de développement WSL complet au déjeuner, installez Windows Terminal, puis VS Code avec l’extension WSL, puis Docker Desktop, dans cet ordre. Cela couvre l’édition, le shelling et les conteneurs.

Si le travail est Python, Go ou JVM lourd : ajoutez PyCharm Pro, GoLand ou IntelliJ Ultimate de JetBrains Toolbox. La refactorisation et l’expérience du débogueur battent toujours VS Code pour ces piles.

Si le budget est zéro : ignorez Docker Desktop et JetBrains et installez docker.io à l’intérieur d’Ubuntu avec le mode rootless, plus IntelliJ IDEA Community pour le travail JVM ou PyCharm Community pour Python. Associez-le à oh-my-posh, tmux et GitHub CLI, tout gratuit.

Si le flux de travail vit dans des sessions SSH longues ou des compilations en arrière-plan : tmux n’est pas optionnel. Configurez-le avant de faire quoi que ce soit d’autre, car l’ajustement des sessions ultérieurement signifie perdre la session actuelle.

Si l’IA dans le terminal est la priorité et que la politique d’entreprise le permet : Warp, à la fois du côté Windows et à l’intérieur d’Ubuntu.

Si l’environnement est verrouillé et ne peut pas installer quoi que ce soit avec un pilote de noyau Windows : tout ce qui est dans cette liste fonctionne toujours, car aucun d’eux n’installe de pilotes de noyau. Docker Desktop et Warp sont les seuls avec un niveau payant qui vaut le coup.

FAQ

Quelle est la meilleure application gratuite pour le développement d’Ubuntu sur WSL ? Windows Terminal, Visual Studio Code avec l’extension WSL, oh-my-posh, tmux et GitHub CLI sont tous gratuits et couvrent le shell, l’éditeur, l’invite, la persistance des sessions et le travail GitHub. Docker Desktop est gratuit pour l’utilisation personnelle et les petites entreprises et couvre les conteneurs.

Docker Desktop vaut-il toujours la peine de payer sur WSL ? Pour les équipes au-dessus des seuils gratuits, oui, car l’intégration du backend WSL2, Kubernetes et les environnements de développement économisent du temps de configuration réel. Pour les développeurs en solo ou les équipes qui exécutent déjà docker.io dans Ubuntu avec un script qui démarre le démon au lancement de WSL, la réponse est non.

Ai-je besoin d’IDE JetBrains si j’ai déjà VS Code ? Non pour la plupart des travaux. VS Code avec l’extension WSL couvre Node, Python, Go et Rust suffisamment bien pour qu’une licence JetBrains payante ne vaille la peine que lorsque la base de code est suffisamment grande pour que l’indexation, la refactorisation et le débogage spécifiques au langage se payent. Les piles JVM et .NET sont les victoires les plus claires.

Puis-je utiliser ces outils sans WSL2, sur Windows simple ? Windows Terminal, Docker Desktop, VS Code, JetBrains, oh-my-posh, GitHub CLI et Warp s’exécutent tous sur Windows sans WSL. tmux ne le fait pas, et ses remplaçants natifs Windows les plus proches (ConEmu, ZellijW) ne sont pas équivalents. Si l’objectif est un flux de travail shell Linux, WSL2 est toujours le chemin le plus court.

Quelles applications pour le développement d’Ubuntu sur WSL sont open source ? Windows Terminal, Visual Studio Code (l’éditeur de base, pas les builds de marque Microsoft), oh-my-posh, tmux et GitHub CLI sont open source. Docker Desktop, les IDE JetBrains et Warp sont propriétaires, avec des niveaux gratuits.

Comment empêcher WSL de se sentir lent ? Conservez les fichiers de projet à l’intérieur du système de fichiers Linux (~/) plutôt que sur /mnt/c/, limitez la mémoire WSL dans .wslconfig afin que la VM ne se permute pas avec l’hôte, et désactivez l’analyse en temps réel de Windows Defender pour le fichier VHDX WSL. Ensemble, ces trois modifications éliminent la plupart de la lenteur que les gens blâment sur WSL lui-même.