WebAssembly a grandi : WASI 0.2, le Component Model et le WASM côté serveur en production

WebAssembly a commencé comme un moyen d'exécuter du C++ dans les navigateurs plus rapidement qu'en JavaScript. En 2026, c'est devenu la chose la moins intéressante à son sujet. WASI 0.2, le Component Model et un écosystème grandissant de runtimes côté serveur ont transformé WASM en une cible de calcul généraliste crédible — indépendante de tout langage, sandboxée par défaut, et commençant à challenger le déploiement basé sur les conteneurs dans le calcul edge.

Ce que WASI 0.2 a réellement changé

La WebAssembly System Interface (WASI) est la spécification qui permet aux modules WASM d'interagir avec le monde extérieur — systèmes de fichiers, sockets réseau, horloges, génération de nombres aléatoires. Avant WASI, le WASM des navigateurs pouvait effectuer des calculs mais ne pouvait pas accéder au système d'exploitation. WASI est ce qui rend le WebAssembly côté serveur possible.

WASI 0.2, finalisée en février 2024 par la Bytecode Alliance, a introduit deux changements fondamentaux. Premièrement, elle a standardisé le Component Model — qui définit comment les modules WASM exposent des interfaces typées via WIT (WebAssembly Interface Types) et composent entre eux. Deuxièmement, elle a introduit wasi:http, une interface HTTP standard permettant aux programmes WASM de traiter des requêtes web sans shim spécifique à une plateforme.

L'effet concret : un composant WASM écrit en Rust, Go, Python ou C peut désormais exposer une interface typée qu'un autre composant — potentiellement écrit dans un langage complètement différent — peut appeler. De l'interopérabilité entre langages sans la complexité du FFI.

Le Component Model : des modules qui composent

Avant le Component Model, le seul type traversant la frontière des modules dans WebAssembly était les octets bruts (la mémoire linéaire). Appeler un module WASM Rust depuis un module WASM Python nécessitait une sérialisation personnalisée des deux côtés. Le Component Model introduit un système de types plus riche à la frontière des modules — chaînes de caractères, listes, enregistrements, variantes — défini dans des fichiers d'interface WIT.

Cela rend le WASM polyglotte pratique. Un pipeline de traitement de données pourrait utiliser un composant Rust pour l'analyse syntaxique (performance), un composant Python pour l'inférence ML (compatibilité d'écosystème) et un composant JavaScript pour la transformation JSON (bibliothèques existantes), le tout composé en une seule application WASM avec des échanges typés entre eux. Le CLI wasm-tools compose et la toolchain cargo component sont les outils actuels côté développeur. L'écosystème est jeune mais fonctionnel — les principaux runtimes WASM sont alignés sur la spécification.

Runtimes côté serveur : Wasmtime, WasmEdge, Wasmer

Wasmtime (Bytecode Alliance) est le runtime de référence pour la conformité WASI. Écrit en Rust, utilisant Cranelift pour la compilation JIT, il privilégie la conformité à la spécification et l'isolation de sécurité. La plateforme Compute de Fastly fonctionne sur Wasmtime et traite du trafic en production à grande échelle.

WasmEdge (projet CNCF) est optimisé pour les déploiements cloud-native et edge. Il s'intègre à Kubernetes via containerd-wasm-shims, prend en charge l'inférence LLM basée sur GGML dans WASM, et est utilisé dans le proxy Envoy pour l'extensibilité par plugins WASM — un cas d'usage majeur en production.

Wasmer privilégie l'expérience développeur avec le support SDK le plus large : bindings Python, JavaScript, Go, PHP, Ruby. Wasmer opère également Wasmer.io, un registre de paquets WASM analogue à npm mais pour distribuer des modules WASM indépendants de toute plateforme.

Là où WASM l'emporte

Trois modèles de déploiement ont émergé où WASM surpasse réellement les alternatives :

Calcul edge : Cloudflare Workers exécute du JavaScript et du WASM dans plus de 300 points de présence dans le monde. Fastly Compute exécute du WASM directement. L'avantage du démarrage à froid est décisif — un module WASM démarre en microsecondes contre des centaines de millisecondes pour un conteneur. Pour les fonctions edge sensibles à la latence, c'est la différence entre un délai perceptible et aucun délai.

Systèmes de plugins : Les logiciels nécessitant de l'extensibilité sans le risque de sécurité des plugins en code natif ont adopté WASM comme hôte de plugins sandboxé. Le proxy Envoy utilise WASM pour son système d'extensions. Zellij (le multiplexeur de terminal) exécute ses plugins en WASM. Le modèle d'isolation est la propriété clé : un plugin WASM ne peut pas accéder à la mémoire hôte ni aux appels système sans autorisations de capacité explicites, ce qui rend l'exécution de code plugin non fiable sans danger.

Inférence ML côté navigateur : WebLLM exécute des LLM quantifiés — Llama 3, Phi-3, Mistral — dans le navigateur via WASM combiné à WebGPU pour l'accès GPU. Cette combinaison permet d'exécuter des modèles de 3 à 7 milliards de paramètres côté client sans serveur, offrant des capacités hors ligne et éliminant les données envoyées à des API externes.

Là où WASM perd encore

WASM ne remporte pas les charges de travail serveur généralistes. Un serveur HTTP Go ou Node.js exécuté dans un conteneur démarre encore assez rapidement pour la plupart des cas d'usage, dispose d'outils matures et ne nécessite pas la complexité des cibles de compilation WASM et des définitions d'interface WIT. L'écosystème reste jeune — la plupart des bibliothèques n'ont pas été portées vers WASM, et le débogage de WASM compilé est nettement plus difficile que celui du code natif.

L'histoire du réseau est également incomplète. WASI 0.2 dispose de wasi:http mais n'inclut pas encore de wasi:sockets stable pour TCP/UDP arbitraire. Les applications nécessitant un accès brut aux sockets — bases de données, protocoles personnalisés, réseau pair-à-pair — ne sont pas encore bien servies par le WASM côté serveur.

Support des langages en 2026

L'écosystème des langages a considérablement mûri au cours des deux dernières années :

• Rust : Support de premier plan. wasm-pack pour les cibles navigateur, cargo component pour le Component Model. Support complet de WASI 0.2.
• Go : TinyGo pour WASI (Go standard a un support WASM expérimental avec certaines limitations de la bibliothèque standard). TinyGo produit des binaires compacts mais ne prend pas en charge toutes les fonctionnalités de la bibliothèque standard Go.
• Python : CPython se compile en WASM via Emscripten (Pyodide pour l'usage navigateur). Le projet py-wasi cible le WASM serveur plus directement.
• JavaScript/TypeScript : SpiderMonkey compilé en WASM est utilisé par Cloudflare pour exécuter des isolats JS de manière portable. ComponentizeJS convertit du JavaScript en composants WASM.
• C/C++ : Emscripten reste la voie mature. wasi-sdk fournit une toolchain plus minimaliste focalisée sur WASI.
• Swift : Cible WASM expérimentale ajoutée dans Swift 5.9, s'améliorant rapidement au cours de 2025.

La comparaison avec les conteneurs

L'argument de la Bytecode Alliance pour WASM face aux conteneurs est tridimensionnel : des artefacts plus petits (un module WASM fait typiquement quelques kilo-octets, pas des centaines de méga-octets de couches de conteneur), des démarrages à froid plus rapides (microsecondes contre centaines de millisecondes) et un modèle d'isolation plus fort (la sécurité basée sur les capacités de WASM face aux vecteurs d'évasion de conteneurs qui apparaissent régulièrement dans les CVE).

Pour les services longue durée où le démarrage à froid importe peu et où vous avez de l'outillage conteneur existant, les conteneurs sont la bonne réponse. Pour le function-as-a-service, le calcul edge et l'extensibilité par plugins, le modèle de WASM est genuinely convaincant — et de plus en plus, les déploiements en production le prouvent.

La route vers WASI 0.3

WASI 0.3 est en développement actif, avec comme ajouts principaux wasi:sockets pour TCP/UDP, le support des E/S asynchrones et des interfaces supplémentaires pour les ressources système. La spécification du Component Model continue également d'évoluer — le système de types et l'outillage de composition ont encore des aspérités que la Bytecode Alliance est activement en train de lisser.

La trajectoire est claire : WASM n'est plus une curiosité de navigateur ni un projet de recherche. Il est en production chez Cloudflare, Fastly et des dizaines d'entreprises qui l'utilisent pour des systèmes de plugins et des charges de travail edge. Le monopole du runtime JavaScript dans le navigateur s'est terminé en 2017 quand WASM est arrivé. Le monopole des conteneurs dans le calcul serveur est le mur que WASM est désormais en train d'escalader — et WASI 0.2 en est la pioche.