WSLc : une alternative à Docker Desktop pour les entreprises?

Introduction

Installer Docker Desktop pour lancer quelques conteneurs fait souvent partie de la préparation d’un poste de développement. En entreprise, cette installation peut aussi entraîner une demande d’approbation, l’attribution d’une licence et du travail pour les équipes qui gèrent les postes.

Avec WSLc, Microsoft ajoute une nouvelle option : construire et exécuter des conteneurs Linux avec un outil directement intégré à WSL. La question vient assez vite : est-ce qu’on pourrait s’en servir pour remplacer Docker Desktop?

Pour certains usages, oui. Pour remplacer l’environnement complet d’une équipe, il faut regarder davantage que la commande qui démarre un conteneur.

Depuis le 29 septembre 2026, la question devient plus concrète. Microsoft a annoncé la disponibilité générale de WSL containers, avec de nouvelles fonctions, des intégrations aux outils de développement et des contrôles pour les entreprises.

Cet article décrit l’état de WSL containers au 29 septembre 2026. La fonctionnalité est maintenant en disponibilité générale. La prise en charge de Compose reste sur la feuille de route.

WSLc : ce que Microsoft ajoute à WSL

WSL permet d’utiliser un environnement Linux sur Windows. WSL containers ajoute à cette base deux éléments : une interface en ligne de commande, wslc.exe, et une API permettant aux applications Windows de piloter des conteneurs Linux. L’alias intégré container.exe donne aussi accès aux mêmes commandes.

La distinction aide à comprendre ce qui change. WSL fournit l’environnement Linux, WSLc ajoute des fonctions pour construire des images et gérer des conteneurs. Docker Desktop, de son côté, regroupe un moteur, des outils et une expérience de développement plus complète.

Avec WSLc, on dispose donc d’une voie intégrée à WSL pour travailler avec des conteneurs Linux, sans installer Docker Desktop pour les opérations couvertes. Le choix dépend ensuite de ce dont le projet a besoin autour de cette exécution.

À quoi ça sert concrètement?

Le premier usage est de démarrer des services nécessaires au développement. Prenons une API ASP.NET Core qui dépend d’une base de données et d’un service de messagerie. L’intérêt des conteneurs est de pouvoir préparer ces dépendances localement sans installer chaque produit directement sur Windows. WSLc devient un candidat pour cette partie de l’environnement, sous réserve de vérifier les images et les configurations utilisées.

Un deuxième usage consiste à exécuter un traitement dans un environnement Linux reproductible : un outil en ligne de commande, une étape de validation ou une application conteneurisée. Le CLI permet notamment de publier des ports et d’exécuter des commandes dans les conteneurs.

Le troisième usage concerne les applications Windows elles-mêmes. Le paquet NuGet Microsoft.WSL.Containers permet de récupérer une image, de créer un conteneur et d’interagir avec ses processus depuis du code, notamment en C#.

On peut ainsi envisager une application C# qui confie une conversion de fichiers à un outil Linux, puis récupère son résultat, ou une application qui exécute localement une charge d’IA conteneurisée. C’est un scénario d’intégration applicative, avec son propre cycle de gestion des conteneurs, des erreurs et des ressources.

Pourquoi Microsoft fait ce choix

Dans son annonce de disponibilité générale, Microsoft présente Linux sur Windows comme une plateforme d’exécution appelée à prendre davantage de place dans les usages d’IA et de développement cloud-native. L’objectif est aussi d’inscrire ces usages dans les mécanismes de sécurité, de gestion et de gouvernance déjà utilisés pour Windows.

Ma lecture est que Microsoft cherche à rendre Windows plus autonome comme plateforme de développement. Plus les outils et les dépendances d’une application reposent sur Linux, plus il devient utile de pouvoir les exécuter facilement sur un poste Windows.

L’API montre aussi que l’ambition dépasse le poste du développeur. En facilitant la réutilisation de composants Linux dans des applications Windows, Microsoft réduit un obstacle à leur intégration. C’est, à mon avis, un aspect plus durable de cette annonce que la seule comparaison des abonnements.

Microsoft précise également que les améliorations des fondations de WSL doivent bénéficier aux distributions Linux, à WSL containers et aux autres technologies de conteneurs qui s’appuient sur WSL. La démarche laisse donc une place à plusieurs outils.

Ce que la disponibilité générale apporte

Le passage en disponibilité générale s’accompagne de fonctions utiles dans le travail quotidien. L’annonce du 29 septembre met notamment en avant les ajouts suivants :

• Gestion du cycle de vie : wslc container restart permet de redémarrer un conteneur. L’option --stop-timeout, disponible avec wslc create et wslc run, permet de régler le délai d’arrêt, y compris une attente illimitée avec -1.
• Fichiers et stockage : wslc container cp permet de copier des fichiers vers un conteneur ou depuis celui-ci au moyen d’archives tar. L’option --mount est prise en charge à la création et au démarrage. Le chemin de stockage de la session WSLc par défaut devient configurable.
• Réseau : wslc network connect et wslc network disconnect permettent de rattacher un conteneur à un réseau ou de l’en détacher. La création d’un réseau accepte aussi des options propres au pilote réseau.
• Visibilité et diagnostic : wslc system info donne une vue de l’environnement et wslc events diffuse les événements des conteneurs en temps réel.
• Vérifications de santé : les conteneurs peuvent maintenant utiliser des contrôles de santé, ou health checks.

Pour une équipe, ces ajouts touchent autant le démarrage que le dépannage. Exécuter une image est une première étape. Pouvoir comprendre son état, gérer ses fichiers et diagnostiquer son réseau compte tout autant lorsque l’environnement sert tous les jours.

Est-ce que WSLc remplace Docker Desktop?

Docker Desktop inclut notamment Docker Compose, une interface graphique et Kubernetes. Sous Windows, il permet également de basculer entre les conteneurs Linux et Windows. Ces fonctions peuvent faire partie du quotidien d’une équipe, même si elle les associe simplement à « Docker ».

WSLc peut remplacer certains usages locaux. Pour décider s’il couvre ceux d’une équipe, voici les besoins à distinguer :

Besoin de l’équipe	Situation au 29 septembre 2026
Construire une image et démarrer un conteneur Linux	Usage couvert par WSLc.
Consulter les journaux, exécuter une commande et observer les événements	Fonctions disponibles dans le CLI.
Utiliser Aspire pour l’environnement local	L’annonce présente WSL containers comme un moteur d’exécution directement pris en charge par Aspire.
Utiliser les Dev Containers de VS Code	Une intégration avec WSLc est disponible. La configuration du projet reste à valider, notamment si elle dépend de Compose.
Démarrer une solution avec un fichier compose.yaml	La prise en charge native de Compose est encore sur la feuille de route.
Retrouver une interface graphique ou un environnement Kubernetes local	Des outils complémentaires existent, mais ils doivent être évalués séparément.
Utiliser Testcontainers ou les outils de conteneurs de Visual Studio	Leur compatibilité n’est pas établie par cette annonce. Valider les versions et les interfaces nécessaires.
Exécuter des conteneurs Windows	WSLc cible les conteneurs Linux. Ce besoin demande un autre outil.

Les fonctions de base sont décrites dans le guide WSLc. Les intégrations et la feuille de route proviennent de l’annonce de disponibilité générale.

Une syntaxe familière ne prouve pas qu’un outil fournit toutes les interfaces attendues par un autre logiciel. Remplacer docker par wslc dans un script ne suffit donc pas à valider une chaîne de développement. L’alias container.exe ne change pas cette distinction.

Des intégrations concrètes, notamment pour Aspire

Pour les équipes .NET, la prise en charge annoncée dans Aspire est particulièrement intéressante. Une équipe qui décrit déjà ses applications et ses dépendances dans un AppHost dispose maintenant d’une piste concrète pour utiliser WSLc comme moteur local. Le pilote doit porter sur les ressources et les intégrations réellement utilisées par la solution, avec une version d’Aspire qui inclut cette prise en charge.

L’écosystème s’étend aussi à VS Code. Les notes du CLI Dev Containers 0.88.0 mentionnent l’ajout de WSLc, et l’extension de gestion des conteneurs de VS Code le prend également en charge.

Des projets communautaires complètent cette expérience :

• Lazywslc fournit une interface de gestion dans le terminal.
• WSL Container Desktop propose une application WinUI 3 pour gérer les conteneurs, les registres et un environnement Kubernetes basé sur k3s.
• WSLc remote facilite l’appel de WSLc depuis une distribution WSL.

Ces outils élargissent les possibilités. Leur maintenance et leur support doivent toutefois être évalués séparément de WSL containers. WSL Container Desktop se présente d’ailleurs comme un projet communautaire, et non comme un produit Microsoft.

Compose reste un point à surveiller

Microsoft indique que l’ajout de wslc compose est la demande la plus fréquente et une priorité pour les prochaines itérations. L’objectif annoncé est de réutiliser les fichiers compose.yaml existants sans modification.

Cet objectif ne constitue pas une fonctionnalité disponible dans la version annoncée le 29 septembre. Pour une équipe dont l’environnement repose sur Docker Compose, cette différence peut suffire à reporter une migration. La prise en charge d’Aspire ou de Dev Containers ne permet pas, à elle seule, de conclure que tous les scénarios Compose sont couverts.

Ce que ça change pour les entreprises

Les licences et le coût réel

Selon les conditions publiées par Docker, Docker Desktop est gratuit notamment pour l’usage personnel, l’éducation, les projets open source non commerciaux et les petites entreprises qui comptent moins de 250 employés et moins de 10 millions de dollars américains de revenus annuels. Les deux critères doivent être respectés pour cette dernière catégorie. Un abonnement payant est requis pour les grandes organisations et les entités gouvernementales.

Ces conditions concernent Docker Desktop. Docker distingue explicitement ce produit de ses composants open source, dont Docker Engine. Utiliser des conteneurs ne signifie donc pas automatiquement devoir acheter Docker Desktop.

Si WSLc couvre les besoins d’un poste et permet d’y retirer Docker Desktop, une économie de licence devient envisageable. Elle doit toutefois être comparée au coût du changement : adaptation des scripts, accompagnement des développeurs, résolution des incompatibilités et support interne.

Je ferais le calcul sur une année : licences évitées, moins le coût de migration et le travail supplémentaire récurrent. Une solution qui économise un abonnement tout en ajoutant des heures de dépannage chaque mois peut rapidement perdre son intérêt.

Il faut également examiner séparément les services conservés, les registres d’images et les logiciels contenus dans les images. Changer l’outil local ne règle pas l’ensemble des obligations de licence d’un environnement.

La gestion des postes et des composants Linux

La version en disponibilité générale étend les intégrations de Microsoft Intune et de Microsoft Defender for Endpoint aux usages de WSL containers.

Du côté d’Intune, deux paramètres sont mis en avant :

• Allow WSL containers access : autoriser ou désactiver l’accès à la fonctionnalité.
• WSL containers registry allow list : définir les registres autorisés pour la récupération des images.

Pour une équipe plateforme, cela permet d’encadrer l’accès à WSL containers et les sources d’images. Une liste de registres autorisés ne garantit toutefois pas, à elle seule, que toutes les images de ces registres sont exemptes de vulnérabilités. La sélection, l’analyse et la mise à jour des images restent des responsabilités à organiser.

Microsoft annonce aussi l’extension de son plug-in Defender for Endpoint pour WSL aux conteneurs. Les activités liées aux processus, aux fichiers et au réseau peuvent être remontées et rattachées au poste Windows, ce qui facilite les investigations dans les outils de sécurité existants. Le déploiement et la configuration de cette intégration doivent faire partie de l’évaluation.

Il reste du travail de gestion. La documentation entreprise de WSL rappelle notamment que la mise à jour des distributions et de leurs paquets ne se confond pas avec celle de Windows. Pour les conteneurs, il faut également prévoir le renouvellement des images utilisées. L’intégration au système ne dispense donc pas de définir qui entretient les composants Linux.

Ce que je vérifierais avant de changer d’outil

Je commencerais par un projet représentatif et quelques postes. Le pilote devrait couvrir le démarrage complet de la solution, les tests, le débogage et l’accès aux registres privés derrière le VPN ou le proxy de l’organisation. J’y inclurais aussi la persistance des données, les montages de fichiers et les besoins en espace disque.

Pour une solution .NET, je vérifierais séparément l’exécution de l’AppHost Aspire, les tests d’intégration et les fonctions de l’IDE utilisées par l’équipe. La réussite d’un de ces scénarios ne valide pas automatiquement les autres.

L’objectif serait de répondre à une question concrète : est-ce qu’un développeur peut réaliser son travail habituel avec un effort de configuration et de support acceptable? Une fois ce point établi, on peut comparer les coûts et décider d’élargir l’usage.

Des améliorations de performance et de réseau

Microsoft annonce des accès aux fichiers Windows depuis les environnements Linux pouvant être jusqu’à deux fois plus rapides avec WSLc. Ce chiffre porte sur ces accès aux fichiers. Il ne signifie pas que l’application, la compilation ou les tests deviennent deux fois plus rapides.

L’annonce présente également le mode réseau consomme, activé pour les usages de conteneurs, comme une amélioration de la compatibilité réseau dans les environnements de développement et d’entreprise.

Ces évolutions touchent des irritants bien réels. Je mesurerais néanmoins leur effet sur le projet retenu pour le pilote, avec les emplacements de fichiers, le VPN, le proxy et les règles réseau réellement utilisés. Microsoft indique poursuivre ses travaux sur les performances entre Windows et Linux ainsi que sur les fondations réseau de WSL.

Un premier exemple avec WSLc

Sur un poste d’essai où WSL est déjà installé, mettez-le à jour vers la version courante. La procédure officielle utilise maintenant la commande de mise à jour habituelle. Depuis PowerShell :

wsl --update
wsl --version
wslc version

Pour aller au-delà de l’installation, démarrons un serveur Nginx :

wslc run -d --rm -p 8080:80 --name exemple-web nginx

Le serveur tourne en arrière-plan, accessible sur le port 8080. L’option --rm supprime le conteneur à son arrêt.

Ouvrez http://localhost:8080, puis consultez les conteneurs et les journaux :

wslc container list
wslc container logs exemple-web

La nouvelle commande suivante permet aussi de consulter l’état général de l’environnement :

wslc system info

Enfin, pour arrêter le serveur et supprimer le conteneur :

wslc container stop exemple-web

Exemple adapté du guide officiel WSLc et de l’annonce de disponibilité générale.

Conclusion

La disponibilité générale de WSL containers en fait une option plus concrète pour les équipes qui utilisent des conteneurs Linux sur Windows. Les nouvelles fonctions de gestion, la prise en charge annoncée dans Aspire et VS Code, ainsi que les intégrations avec Intune et Defender for Endpoint renforcent son intérêt en entreprise.

Pour ma part, je commencerais par les projets dont les dépendances et les scripts sont faciles à reproduire, ou par une solution Aspire représentative. Si WSLc couvre ces usages sans compliquer le travail des développeurs, son adoption devient intéressante. Pour une équipe qui dépend fortement de Docker Compose ou d’autres intégrations propres à son environnement actuel, certains obstacles demeurent.

L’API mérite elle aussi d’être suivie. La possibilité d’intégrer des traitements Linux dans une application Windows ouvre des usages qui vont bien au-delà de la préparation d’un poste de développement.

Le bon critère de décision reste la valeur apportée au quotidien : moins de configuration, un environnement fiable et un coût total raisonnable. Les économies de licence peuvent motiver un essai, l’expérience obtenue doit justifier l’adoption.