Pour exécuter des conteneurs Linux sous Windows 11 sans Docker Desktop, utilisez wslc.exe, l’interface en ligne de commande incluse avec Windows Subsystem for Linux (WSL). Depuis PowerShell, mettez WSL à jour, vérifiez que wslc répond, puis lancez un premier conteneur. Microsoft décrit aussi comment construire une image de projet et rendre son application accessible depuis Windows.

Ce que wslc permet sous Windows 11

wslc.exe sert à télécharger des images, construire des images de projet et exécuter des conteneurs Linux. Il est fourni avec WSL : aucun moteur séparé n’est à installer. Une image contient l’application et les éléments dont elle a besoin ; le conteneur est l’instance qui s’exécute.

Préparer WSL et lancer un premier conteneur

Cette démonstration en anglais de Gary Explains passe par PowerShell, un conteneur Ubuntu, Nginx et un test GPU. Elle utilise des options de préversion pour mettre WSL à jour, qui ne sont pas reprises dans cette procédure.
Installez WSL uniquement s’il manque, mettez-le à jour, puis vérifiez wslc avec un conteneur Linux de test.

Si WSL est déjà installé, passez directement à sa mise à jour. La documentation de Microsoft sur les conteneurs WSL détaille la procédure et les commandes ci-dessous.

  1. Installez WSL s’il manque. Dans PowerShell, lancez wsl --install.
  2. Mettez WSL à jour. Exécutez wsl --update dans PowerShell.
  3. Vérifiez que la commande répond. Lancez wslc version.
  4. Testez un premier conteneur. Exécutez wslc run --rm hello-world. Si l’image n’est pas déjà présente sur le PC, elle est téléchargée automatiquement. Le message « Hello » indique que le test a fonctionné.

Construire une image de projet et publier un service

wslc peut construire une image à partir d’un fichier Containerfile, qui décrit les étapes de création. Pour un projet Python avec Django, Microsoft montre comment en créer un à la racine du projet, puis construire l’image depuis ce dossier :

wslc build -t helloworld-django .

Le nom helloworld-django sert ensuite à retrouver l’image. Vérifiez sa création avec wslc image list, puis démarrez un conteneur en publiant le port de l’application :

wslc run -d --rm -p 8000:8000 --name django helloworld-django

Vérifiez l’état du conteneur et ses journaux :

wslc container list
wslc container logs django

Ouvrez ensuite http://localhost:8000/ dans un navigateur Windows pour accéder à l’application. Pour exécuter une commande dans le conteneur, utilisez wslc exec django uname ; le résultat Linux indique que le conteneur utilise le noyau Linux de WSL 2.

Pour un exemple de service plus simple, Microsoft utilise Nginx et relie le port 8080 de Windows au port 80 du conteneur :

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

Dans -p 8080:80, le premier numéro correspond au port accessible depuis Windows et le second au port du conteneur. L’option -d lance le service en arrière-plan.

Gardez les fichiers du projet dans le système de fichiers Linux de WSL lorsque vous utilisez des outils Linux. Microsoft avertit que l’accès aux fichiers peut être nettement plus lent si ces outils travaillent sur des fichiers stockés dans le système de fichiers Windows.

Inspecter et nettoyer les conteneurs

Pour examiner un conteneur ou ses journaux, utilisez wslc container inspect <container-id> et wslc container logs <container-id>. La commande wslc image inspect <image> examine une image.

Quand vous avez terminé, arrêtez le conteneur avec wslc container stop django. Comme l’exemple de lancement utilise --rm, le conteneur est supprimé à l’arrêt. Pour supprimer les conteneurs arrêtés et les images inutilisées, Microsoft documente également wslc container prune et wslc image prune.

Accès GPU et test de llama.cpp rapporté

Dans un article publié le 23 octobre 2026, Abhinav Raj, auteur chez XDA, rapporte avoir exécuté un conteneur avec accès GPU sur un PC équipé d’un Ryzen 5 7600X et d’une NVIDIA RTX 4070 Ti Super avec 16 Go de mémoire vidéo. Le test utilisait le pilote NVIDIA 617.14, l’image nvidia/cuda:12.9.1-base-ubuntu24.04 et l’option --gpus all.

Pour llama.cpp avec Gemma 4 E4B, Abhinav Raj rapporte 124 tokens par seconde lors de chacune des deux exécutions en conteneur. Les deux exécutions natives ont atteint entre 128 et 132 tokens par seconde. Les essais utilisaient la quantification Q4_K_M, le déchargement complet sur le GPU, un contexte de 128K, le même prompt et une réponse de 256 tokens.

Dans le même article, Abhinav Raj décrivait wslc comme limité aux conteneurs Linux et indiquait que Compose manquait lors de son test.