WASI et WebAssembly en 2026 : quand Wasm sort enfin du navigateur

# WASI et WebAssembly en 2026 : quand Wasm sort enfin du navigateur

WebAssembly est né en 2017 avec une promesse simple : exécuter du code quasi natif dans le navigateur, à côté de JavaScript. Près de dix ans plus tard, l'histoire la plus intéressante ne se joue plus dans le navigateur. Portée par WASI (WebAssembly System Interface) et le Component Model, la technologie s'installe sur les serveurs, à la périphérie (edge), dans les plugins et jusque dans Kubernetes.

En une phrase : en 2026, Wasm n'est plus « le bytecode du web ». C'est un format de déploiement universel, sandboxé et portable.

TL;DR

• WASI donne enfin à Wasm un accès standardisé et sécurisé au système (fichiers, réseau, horloge) hors du navigateur.
• WASI 0.2 (janvier 2024) est stable ; WASI 0.3 ajoute l'asynchrone natif, le dernier chaînon manquant.
• Le Component Model rend Wasm réellement composable et multi-langage.
• En production aujourd'hui : edge/serverless, plugins, Kubernetes - pas encore le backend généraliste.
• À évaluer dès maintenant pour les plugins et l'edge ; à surveiller pour le reste.

Pourquoi sortir Wasm du navigateur ?

Dans le navigateur, un module Wasm ne peut presque rien faire seul : pas d'accès au système de fichiers, pas de socket réseau, pas d'horloge - tout passe par le JavaScript hôte. C'est précisément ce que WASI vient corriger : définir une interface standard et capability-based entre un module Wasm et le système qui l'exécute.

Les arguments qui ont fait basculer l'industrie :

• Portabilité réelle - un même binaire .wasm tourne sur Linux, macOS, Windows, ARM ou x86 sans recompilation
• Sécurité par défaut - modèle à capacités, deny by default : un module ne voit que les fichiers, variables d'environnement et sockets qu'on lui accorde explicitement
• Démarrage à froid quasi instantané - quelques microsecondes à quelques millisecondes, contre des centaines de millisecondes pour un conteneur
• Empreinte minuscule - des binaires de quelques centaines de Ko, sans OS embarqué
• Multi-langage - Rust, C/C++, Go, C#, Python, JavaScript, Swift… compilent vers la même cible

Concrètement, lancer un binaire WASI ressemble à ceci - et notez le --dir : sans cette autorisation explicite, le module ne voit aucun fichier.

# Compilation Rust vers WASI
cargo build --target wasm32-wasip2 --release

# Exécution sandboxée : on n'accorde QUE l'accès au dossier courant
wasmtime run --dir=. ./target/wasm32-wasip2/release/app.wasm

# Tout le reste (réseau, autres dossiers, env) est refusé par défaut

En 2019, Solomon Hykes, cofondateur de Docker, résumait l'enjeu d'une phrase devenue culte : « Si WASM+WASI avait existé en 2008, nous n'aurions pas eu besoin de créer Docker. » En 2026, cette boutade ressemble de plus en plus à une feuille de route.

WASI : de Preview 1 à 0.3

L'évolution de WASI explique en grande partie la maturité atteinte aujourd'hui.

⚠️ Attention aux numéros de version. « Preview 1 » et « Preview 2 » désignent des jalons historiques, tandis que la numérotation moderne suit le schéma 0.2.x / 0.3. Beaucoup d'outils supportent encore Preview 1 en parallèle de 0.2 ; vérifiez toujours la cible attendue par votre runtime.

Le Component Model : la vraie révolution

C'est sans doute l'apport le plus structurant. Là où un module Wasm classique n'échange que des entiers et des flottants via la mémoire linéaire, un composant expose des interfaces typées de haut niveau (chaînes, records, listes, résultats, ressources) décrites en WIT (WebAssembly Interface Types).

Une interface WIT ressemble à un contrat lisible, indépendant du langage :

package portfolio:greeter@1.0.0;

interface greet {
    record visitor {
        name: string,
        locale: string,
    }

    // Retourne un message, ou une erreur typée
    hello: func(v: visitor) -> result<string, string>;
}

world app {
    export greet;
}

Ce contrat apporte trois choses décisives :

1. L'interopérabilité multi-langage - un composant en Rust peut importer une interface implémentée en Go ou en Python, sans glue manuelle
2. La composition - on assemble plusieurs composants comme des briques Lego, chacun restant sandboxé
3. Des contrats stables - l'interface WIT sert de frontière de version, indépendamment du langage d'implémentation

Des outils comme wit-bindgen (génération de bindings), componentize-py (Python → composant) ou ComponentizeJS / StarlingMonkey (JavaScript → composant) rendent ce modèle utilisable au quotidien.

Les runtimes : un écosystème mûr

Cette diversité - avec plusieurs projets sous l'égide de la CNCF et de la Bytecode Alliance - est un signal fort de maturité : Wasm côté serveur n'est plus une expérience, c'est une infrastructure.

Là où Wasm est déjà en production

Loin du hype, des usages concrets tournent déjà à grande échelle.

Edge / serverless

Fastly Compute exécute du Wasm en production depuis des années ; Fermyon Spin et wasmCloud poussent le modèle « fonction Wasm » plus loin, avec des démarrages à froid en millisecondes.

Plugins extensibles

Le proxy Envoy charge des filtres proxy-wasm ; Extism propose un système de plugins universel embarquable dans presque n'importe quelle application.

Personnalisation marchande

Shopify Functions laisse les développeurs étendre la logique métier via des modules Wasm sandboxés et limités en temps CPU.

Extension applicative

De plus en plus de produits SaaS et de bases de données exposent une couche d'extension Wasm plutôt que d'embarquer un interpréteur maison.

Wasm et Kubernetes : la convergence

L'intégration avec l'écosystème conteneurs s'est nettement clarifiée :

• Docker + Wasm - Docker Desktop sait lancer des charges Wasm via des shims containerd, aux côtés des conteneurs Linux classiques
• runwasi & shims containerd - exécutent des modules Wasm comme des workloads de premier ordre
• SpinKube - déploie des applications Spin directement sur Kubernetes, avec des pods qui démarrent en millisecondes

Le scénario qui se dessine n'est pas « Wasm remplace les conteneurs » mais « Wasm complète les conteneurs » : on garde Kubernetes comme plan de contrôle, et on choisit le runtime - conteneur ou Wasm - selon le besoin : densité, démarrage à froid, sécurité.

WebAssembly 2.0 : le cœur du langage progresse

En parallèle de WASI, la spécification du cœur de Wasm a beaucoup avancé : SIMD, multi-value, reference types, tail calls, exception handling, threads, memory64 et surtout WasmGC.

Ce dernier - le ramasse-miettes intégré - change la donne pour les langages managés : Java, Kotlin, Dart/Flutter ou C# peuvent désormais compiler vers Wasm sans embarquer leur propre GC, avec des binaires bien plus légers.

Faut-il s'y mettre en 2026 ?

Quelques points de vigilance pour un backend classique :

• Écosystème de bibliothèques - tout n'est pas encore portable proprement vers WASI 0.2, surtout côté réseau et bases de données
• Maturité par langage - Rust est en tête ; Go et C# progressent vite ; Python et JS sont utilisables, avec des compromis
• Outillage - encore jeune comparé à l'écosystème conteneurs, mais il se stabilise rapidement

Conclusion

WebAssembly tient enfin sa promesse hors du navigateur. Avec WASI 0.2 stabilisé, l'asynchrone natif en approche dans WASI 0.3, un Component Model qui rend le multi-langage réellement composable et une intégration crédible à Kubernetes, 2026 marque le moment où Wasm cesse d'être une curiosité côté serveur pour devenir une option d'architecture sérieuse.

Il ne remplacera ni Docker ni les conteneurs du jour au lendemain - mais, comme Bun et Biome côté JavaScript, il redéfinit les attentes : portabilité totale, sécurité par défaut et démarrage instantané. Ne pas l'évaluer aujourd'hui, ce serait passer à côté de la prochaine couche d'infrastructure.