Wanix : un Unix complet qui tourne en WebAssembly dans votre navigateur

Le 23 juillet 2026, le site officiel du projet Wanix affiche sa version 0.4 : un Unix complet, inspiré de Plan 9, qui tourne entièrement en WebAssembly dans un onglet de navigateur. Pas de serveur, pas de conteneur distant à louer : un binaire Wasm et une poignée de balises HTML personnalisées suffisent à faire apparaître un vrai prompt shell.

Concrètement, Wanix permet de lancer un shell Unix authentique (rc, l'interpréteur historique de Plan 9), d'y exécuter des programmes Wasm ou x86, de monter des systèmes de fichiers virtuels, et même de démarrer une machine virtuelle Linux complète, le tout depuis une simple page web statique. Voici comment ça fonctionne, ce qu'on peut vraiment en faire, et pourquoi cette approche mérite l'attention de tout développeur qui s'intéresse au sandboxing côté client.

Wanix, ou l'héritage de Plan 9 réinjecté dans le navigateur

Wanix s'inspire directement de Plan 9, le système d'exploitation de recherche conçu dans les années 90. Son idée fondatrice : tout est fichier, et chaque processus dispose de son propre namespace, c'est-à-dire sa propre vue composable du système de fichiers. Le projet revendique cet héritage sans détour : sa conférence de présentation, longue de 19 minutes et intitulée « The spirit of Plan 9, in Wasm », explique pourquoi un modèle né avant le web tel qu'on le connaît s'avère aujourd'hui pertinent pour construire des outils web local-first.

L'idée est simple à énoncer, plus subtile à mettre en oeuvre : si chaque page web peut composer son propre namespace (quels fichiers, quels binaires, quelles machines virtuelles elle expose), le sandboxing cesse d'être une contrainte imposée par le navigateur pour devenir un outil de composition explicite, contrôlé par le développeur.

Trois balises HTML suffisent à faire tourner un Unix

Wanix se manipule via des web components dédiés. Voici l'exemple minimal fourni par le projet, capable à lui seul de faire apparaître un shell fonctionnel :

<wanix-term>
  <wanix-bind dst="rc.wasm" type="file" src="https://wanix.dev/extras/0.4.0-rc2/rc.wasm"></wanix-bind>
  <wanix-task cmd="rc.wasm" term start></wanix-task>
</wanix-term>

wanix-bind monte le binaire rc.wasm dans le namespace de la page. wanix-task le lance comme commande, réserve un terminal (term) et démarre l'exécution dès que le système est prêt (start). wanix-term affiche un terminal xterm.js relié à cette tâche. Résultat : un prompt rc% authentique s'affiche dans la page, où taper ls révèle bien le fichier rc.wasm qui vient d'être bindé.

Des primitives aux composants complets

Ces trois balises ne sont que la base. Wanix expose toute une famille d'éléments, chacun une brique orthogonale que l'on combine selon le besoin :

• wanix-namespace : conteneur de namespace explicite. En lui donnant un id et des allow-origins, on rend ce namespace importable par d'autres pages.
• wanix-bind : le couteau suisse du montage. Il peut lier des noms entre eux, allouer des devices, récupérer un fichier distant (type="file"), désarchiver un .tar ou .tgz en arborescence (type="archive", empilable en union récursive), ou importer un namespace distant via le protocole 9P par-dessus WebSocket, ou via iframe (type="import").
• wanix-vm : démarre une machine virtuelle complète dans le namespace, grâce à l'émulateur v86. Les démonstrations du projet montrent une image Alpine/Busybox qui démarre jusqu'à un shell Linux fonctionnel, avec export="ttyS0" pour exposer le namespace interne de la VM sous #vm/1/guest.
• wanix-workbench : un éditeur complet basé sur VS Code, utilisable comme explorateur de fichiers, éditeur ou IDE à part entière. Il suffit de lui fournir une tâche avec role="shell" pour obtenir un terminal intégré.

Comment l'essayer en quelques minutes

Wanix s'installe sans rien construire côté serveur. Un simple tag suffit pour charger la bibliothèque depuis le CDN jsDelivr :

<script type="module" src="https://cdn.jsdelivr.net/npm/[email protected]/dist/wanix.min.js"></script>

Le site officiel propose ensuite huit recettes prêtes à copier-coller pour démarrer : lancer un shell, éditer des fichiers, ouvrir un shell dans le Workbench, démarrer une VM, obtenir un poste de dev Linux complet, exporter un namespace, se connecter en shell sur un namespace distant, ou éditer des fichiers distants. Chacune tient en quelques balises HTML, sans étape de build.

Ce que ça change concrètement pour les devs et les PME

Au-delà de la démonstration technique, l'intérêt de Wanix tient à trois usages assez directement exploitables.

• Sandboxing d'exécution sans infrastructure serveur. Faire tourner du code non fiable (soumis par un utilisateur, un exercice pédagogique, une démo produit) directement dans le navigateur du visiteur évite de provisionner et sécuriser des conteneurs côté serveur pour cet usage précis.
• Environnements de démonstration et de formation. Un wanix-workbench embarqué transforme une simple page statique en poste de dev complet avec éditeur, terminal et fichiers, hébergeable sur n'importe quel hébergement statique, sans backend à maintenir.
• Namespaces distants via 9P over WebSocket. La possibilité d'importer un namespace exporté par une autre page ouvre la voie à des scénarios de support ou de debug à distance : un client partage un namespace, un technicien s'y connecte en shell depuis son propre navigateur, sans agent à installer.

Pour une agence comme la nôtre, ce type de brique est particulièrement intéressant pour construire des bacs à sable clients : faire tester une intégration, une configuration ou un script à un prospect sans lui demander d'installer quoi que ce soit, et sans exposer d'infrastructure serveur à du code non maîtrisé.

Notre lecture chez CZSyn

Le sandboxing Wasm côté navigateur n'est pas neuf, mais Wanix pousse l'idée plus loin en réinjectant la composabilité des namespaces façon Plan 9 : au lieu d'un bac à sable monolithique, on obtient des briques qu'on assemble à la carte, fichier par fichier, binaire par binaire. C'est ce qui distingue le projet d'un simple terminal Wasm dans une page.

Nous restons prudents sur la maturité : la version affichée est une 0.4 dont les assets embarqués sont encore taggués rc2 (release candidate), et l'émulation x86 via v86 a un coût en performance qui la réserve pour l'instant à la démonstration ou à la formation plutôt qu'à un environnement de production. Mais l'argument qui nous semble le plus solide pour les équipes françaises reste la confidentialité : puisque tout tourne dans l'onglet, sans serveur distant, aucune donnée ni aucun code ne transite par une infrastructure tierce. Pour un exercice de formation interne ou une démo client sur un sujet sensible, c'est un argument qui compte.

Sources primaires

• Wanix, page officielle du projet, wanix.dev, version 0.4 consultée le 23 juillet 2026.
• Package npm officiel, npmjs.com/package/wanix, version 0.4.0-rc2.