WSL Manager : piloter WSL2 et des VM Linux natives depuis une interface Flutter

Le problème : des distributions WSL2 gérées à coups d'options wsl.exe

WSL2 se pilote par ligne de commande. Installer une distribution depuis un rootfs, la renommer, la déplacer sur un autre disque, en faire une sauvegarde, compacter un disque virtuel qui a gonflé : chaque opération correspond à une option de wsl.exe, avec ses variantes et ses pièges. Le README résume la promesse en une phrase : installer, copier, renommer, déplacer, sauvegarder et supprimer des distributions sans mémoriser la moindre option de wsl.exe.

Le public visé n'est pas l'administrateur qui vit dans son terminal. C'est plutôt le développeur sous Windows qui utilise deux ou trois distributions, qui veut déplacer une instance vers un disque plus rapide, ou qui doit récupérer un disque virtuel devenu énorme. Le projet s'adresse aussi, depuis peu, à un public plus large : le README décrit la gestion de VM Linux et macOS natives sur Mac, via la Virtualization framework d'Apple, avec la même application. Cette double cible Windows et macOS dans un seul binaire Flutter est le trait le plus inhabituel du projet.

Une application Flutter, deux moteurs sous la même interface

Le dépôt est en Dart, avec Flutter comme boîte à outils. La description du dépôt indique que l'application sert de GUI pour WSL et, sur Mac, pour des VM natives. Le README précise que sur macOS, c'est la Virtualization framework d'Apple qui est utilisée à la place de WSL, et que le build passe par scripts/build_macos.sh, qui embarque un helper signé nommé vmctl.

Autrement dit, l'interface est commune mais le moteur diffère selon la plateforme. Sur Windows, l'application parle à WSL. Sur macOS, elle crée des VM à partir d'une ISO d'installateur, d'une image cloud ou d'un template exporté, et le README ajoute la création de VM invitées macOS depuis une restore image sur Apple Silicon. La gestion des disques suit la même logique : monter un disque physique ou un VHD dans WSL, avec contrôle des partitions et du système de fichiers.

Le README note que chaque VM Linux reçoit une clé de votre ~/.ssh, créée si vous n'en avez pas, et qu'un mot de passe de connexion est lisible depuis la ligne de la VM pour ouvrir une session sur l'écran de la VM elle-même. Ce sont des choix concrets, pas des promesses d'intégration.

Docker, LXC et rootfs : les chemins d'installation alternatifs

Le catalogue intégré couvre les distributions habituelles (Ubuntu, Debian, Alpine, Kali Linux, openSUSE, SLES) et le README indique que toute distribution acceptée par WSL fonctionne. Deux chemins sortent du catalogue. Le premier : utiliser n'importe quelle image Docker comme distribution, sans que Docker soit installé sur la machine. Le second : les conteneurs LXC turnkey, présentés comme expérimentaux.

Le README ajoute la possibilité de pointer l'application vers votre propre dépôt d'images rootfs, ce qui compte si vous produisez des images en interne. Les templates, qui servaient à figer une distribution configurée, sont dépréciés au profit des fichiers .wsl : le README décrit ces derniers comme des paquets portables qui s'installent sur n'importe quelle machine. C'est un changement de format à surveiller si vous aviez automatisé quelque chose autour des templates.

Le serveur MCP et l'assistant : la partie qui mérite le plus de prudence

Le projet expose un serveur MCP (Model Context Protocol) et un assistant intégré à l'application. Le README indique que l'assistant et le serveur MCP reçoivent les mêmes outils que l'interface, et que sur macOS, les commandes peuvent être exécutées dans les VM via SSH provisionné automatiquement par cloud-init.

C'est la fonctionnalité la plus intéressante et la moins documentée dans le matériel fourni. Un serveur MCP qui donne à un agent la capacité d'installer, déplacer ou supprimer des distributions n'est pas un gadget : c'est un accès en écriture à votre environnement de développement. Le README ne détaille ni le mode de transport, ni l'authentification, ni les garde-fous. Impossible, à partir de ces seuls éléments, de savoir comment le serveur est lancé, s'il écoute sur une socket locale ou sur le réseau, ni quelles commandes sont exposées. À vérifier dans le wiki avant de brancher un agent dessus.

Configuration : .wslconfig, systemd et snippets

L'application édite .wslconfig sans passer par un éditeur de texte : mémoire, processeurs, swap, mode réseau, DNS. Elle expose aussi des réglages par distribution : systemd, automount, utilisateur par défaut, commande et chemin de démarrage. Ce sont exactement les clés que l'on modifie habituellement à la main, et les regrouper dans une interface évite les erreurs de syntaxe dans un fichier INI.

Les snippets complètent le tableau : des commandes de configuration conservées dans l'application et exécutables sur n'importe quelle instance. Le README mentionne également l'ouverture de Windows Terminal, VS Code ou l'Explorateur directement dans une distribution, la gestion d'un WSL distant sur une autre machine Windows via SSH, et la synchronisation d'une distribution entre deux machines du réseau. Sur ce dernier point, le README ne dit rien du mécanisme de transport ni des conflits possibles entre deux copies divergentes.

Ce qui manque, et ce qui n'est pas encore livré

Le README contient un bloc commenté qui décrit des fonctionnalités présentes dans le code mais absentes des versions publiées : gestion des conteneurs Docker et Podman, clusters Kubernetes, déploiement vers le cloud (Hetzner). Le commentaire explique que ces fonctions ne s'activent que dans les builds de debug, derrière un LicenseManager.unreleasedFeaturesVisible, et qu'une release n'en contient aucune. Le README demande donc explicitement de ne pas les promettre. Si vous cherchez un tableau de bord Kubernetes, ce projet n'est pas l'outil, en tout cas pas dans la version que vous installerez.

Deuxième limite, plus structurelle : la licence. GitHub renvoie NOASSERTION, ce qui signifie que le fichier LICENSE n'a pas été reconnu comme une licence standard. Le README mentionne une version Pro, achat unique via le Microsoft Store sur Windows ou une clé de licence depuis wslmanager.com/buy. Un projet dont certaines fonctions sont derrière une clé de licence et dont le fichier de licence n'est pas identifié automatiquement demande une lecture directe du dépôt avant tout usage en entreprise. Ce n'est pas un avis juridique, seulement un constat sur ce que renvoie l'API du dépôt.

Troisième limite : la maintenance. Le README signale que les builds du site et de GitHub se mettent à jour eux-mêmes, tandis que les installations via le Store sont mises à jour par le Store. Cela veut dire qu'une version installée hors Store peut se remplacer toute seule, ce qui n'est pas toujours compatible avec une politique de gestion de parc.

Alternatives : la ligne de commande et les scripts

L'alternative évidente n'est pas un autre GUI, c'est wsl.exe lui-même, accompagné de scripts. La différence d'approche est nette. Un script d'installation de distribution se versionne, se relit en revue de code et s'exécute de la même façon sur dix machines. WSL Manager déplace ces opérations dans une interface graphique, ce qui les rend accessibles mais difficiles à reproduire à l'identique sur un parc. Le README ne décrit aucun mode ligne de commande pour l'application elle-même, ni format de fichier de configuration permettant de rejouer un ensemble d'opérations.

Sur macOS, l'alternative serait les outils en ligne de commande d'Apple autour de la Virtualization framework, ou un outil de VM plus établi. Le README présente la partie macOS comme beta, ce qui est un avertissement honnête : la création de VM invitées macOS depuis une restore image et le déploiement cloud depuis un Mac sont décrits comme des chemins récents, avec des contraintes notables (une VM déployée puis rapatriée doit encore exister et être arrêtée, car un rootfs nu n'a pas de noyau à démarrer).

Coût de maintenance et cycle de publication

Trois versions en trois jours : v2.0.0 le 6 septembre 2026, v2.0.1 le 7, v2.0.2 le 8. Le dépôt n'est pas archivé et le dernier push date du 9 septembre 2026. Ce rythme indique un projet actif, mais aussi des correctifs rapprochés après une version majeure, ce qui est courant et pas nécessairement un signal négatif. Pour un utilisateur, cela implique de prévoir une procédure de retour arrière si une mise à jour automatique casse quelque chose, puisque l'application se met à jour elle-même hors Store.

La documentation vit dans le wiki du dépôt, pas dans le README. Le README est multilingue (anglais, chinois simplifié et traditionnel, allemand, espagnol, japonais, hongrois, portugais, turc) et l'interface est disponible en neuf langues. La licence reste le point à éclaircir en premier : sans fichier LICENSE reconnu, la réutilisation du code, la redistribution d'un binaire modifié et l'usage en contexte commercial ne peuvent pas être déduits du matériel fourni.

Conclusion éditoriale

À adopter si vous gérez plusieurs distributions WSL2 sur Windows et voulez éviter les options de wsl.exe pour installer, déplacer, sauvegarder ou compacter des instances, ou si vous voulez qu'un agent MCP pilote votre environnement. À éviter si vous cherchez un outil scriptable en ligne de commande : la valeur du projet tient à son interface graphique, et le volet macOS reste marqué beta. Avant de vous engager, vérifiez deux points précis : le fichier LICENSE du dépôt, puisque GitHub renvoie NOASSERTION et que le README mentionne une version Pro vendue sur le Microsoft Store et sur wslmanager.com, et le contenu réel de la release v2.0.2, car le README contient des blocs commentés pour des fonctionnalités non publiées. La page wiki du dépôt reste la seule documentation de référence au-delà de ce README.

Sources officielles

1. bostrot/wsl2-distro-manager on GitHub
2. Issues
3. Project website
4. README
5. Releases