WebAssembly a dépassé le navigateur. Voici où il tourne réellement en 2026.

WebAssembly a été introduit en 2017 comme un moyen d'exécuter du code compilé dans les navigateurs à une vitesse quasi-native. En 2026, cette origine n'est presque plus qu'une note de bas de page. L'histoire la plus intéressante, c'est ce qui s'est passé en dehors du navigateur : Wasm s'exécute désormais dans des fonctions serverless, des nœuds edge, des systèmes de plugins et des extensions de bases de données. Le Wasm Component Model et WASI 0.2 ont formalisé tout cela en 2024, et l'écosystème a pleinement rattrapé son retard.

Petit rappel : ce qu'est vraiment Wasm

WebAssembly est un format d'instructions binaires conçu pour fonctionner dans une machine virtuelle sandboxée. Il peut être compilé à partir de C, C++, Rust, Go, Swift, Kotlin et une liste croissante d'autres langages. Trois propriétés le rendent singulier :

Exécution déterministe — le même binaire produit la même sortie sur chaque plateforme, à chaque fois.
Isolation mémoire — un module Wasm n'a pas d'accès direct au système hôte, au système de fichiers ou au réseau, sauf autorisation explicite via une interface.
Portabilité d'architecture — le même binaire .wasm s'exécute sur x86, ARM et RISC-V sans recompilation.

Côté taille, un module Wasm typique est 10 à 100 fois plus petit qu'une image Docker équivalente. Au démarrage, les runtimes Wasm s'initialisent en microsecondes — contre des centaines de millisecondes, voire des secondes pour les conteneurs. Ce ne sont pas des avantages marginaux ; ils changent ce qui est économiquement viable à la périphérie.

WASI 0.2 et le Component Model — pourquoi ils comptent

WASI (WebAssembly System Interface) est l'API standardisée qui permet aux modules Wasm d'interagir avec le monde extérieur — entrées/sorties fichiers, réseau, horloges, aléa. WASI 0.1 était minimal par conception. WASI 0.2, ratifié en janvier 2024, a ajouté les requêtes et réponses HTTP, les sockets, les primitives cryptographiques et, surtout, le Component Model.

Le Component Model définit comment les modules Wasm se composent entre eux. Un composant Rust peut appeler un composant Python via une interface typée définie en WIT (Wasm Interface Types), sans surcoût FFI et avec de fortes garanties de typage à la frontière. Avant cela, les modules Wasm étaient des unités isolées — utiles, mais pas composables. Le Component Model est ce qui fait de Wasm une véritable plateforme, et non une simple cible de compilation.

Le résultat pratique : vous pouvez désormais construire une application Wasm en assemblant des composants développés indépendamment, dans différents langages, liés au niveau de l'interface plutôt qu'au niveau binaire. Pas de mémoire partagée, pas de cauchemars de compatibilité ABI.

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

Trois runtimes se sont imposés comme des choix de production sérieux pour Wasm côté serveur :

Wasmtime (Bytecode Alliance, écrit en Rust) : qualité production, totalement conforme à WASI 0.2, utilisé en production par Fastly et Shopify. L'implémentation de référence pour la spécification Wasm.
Wasmer : prend en charge WASIX — un WASI étendu avec des appels système de type POSIX qui permet à davantage de programmes de type Unix de fonctionner sans modification. Héberge également des images Wasm compatibles Docker via le registre Wasmer.
WasmEdge : un projet CNCF sandbox optimisé pour les charges de travail d'inférence AI. Il exécute GGML et llama.cpp compilés en Wasm, ce qui en fait le runtime de choix pour les déploiements AI en périphérie où Docker est trop lourd.

Au-delà des runtimes, Spin de Fermyon est un framework de microservices construit nativement sur Wasm — essentiellement AWS Lambda mais avec la sémantique d'exécution Wasm, les composants WASI 0.2 et aucun problème de cold start.

Edge Compute : le cas d'usage killer

Si vous voulez comprendre pourquoi les fournisseurs edge ont adopté Wasm avant tout le monde, considérez l'économie : à la périphérie, vous exécutez des milliers de fonctions client sur une infrastructure partagée, et vous avez besoin d'isolation, de démarrage rapide et d'une faible empreinte mémoire simultanément. Les conteneurs résolvent l'isolation mais échouent sur le temps de démarrage et la surcharge par fonction. Les VMs sont pires. Wasm résout les trois.

Cloudflare Workers utilise des isolates V8 avec un support complet de Wasm. Les fonctions démarrent en moins de 1 ms. Plus de 2 millions de développeurs ont déployé du code Workers.
Fastly Compute utilise Wasmtime avec compilation AOT (ahead-of-time). Le temps de cold start est littéralement de 0 ms — le module est déjà compilé en code natif lorsque la requête arrive. Une fonction Rust compilée en Wasm s'exécute à 5–10 % de la vitesse native.
Vercel Edge Functions prend en charge les modules Wasm en tant que citoyens de première classe aux côtés de JavaScript.

Le modèle sandbox est crucial ici : du code non fiable fourni par l'utilisateur s'exécute sur une infrastructure edge partagée sans surcharge de conteneur, car les garanties d'isolation de Wasm sont appliquées au niveau de la VM, pas au niveau du système d'exploitation. Vous n'avez pas besoin d'un espace de noms noyau séparé par locataire.

Systèmes de plugins : étendre sans compromis

Le problème traditionnel des plugins : vous voulez permettre aux utilisateurs d'étendre votre plateforme, mais exécuter du code utilisateur arbitraire dans votre processus est un désastre de sécurité. Les options historiques étaient : l'isolation par sous-processus (lent, complexe), un langage de script personnalisé (limité), ou simplement accepter le risque (mauvais). Wasm résout cela.

Extism est un système de plugins open source basé sur Wasm. Vous fournissez un fichier .wasm comme plugin ; l'hôte le charge en toute sécurité dans un environnement isolé avec uniquement les interfaces que vous exposez explicitement. HashiCorp l'utilise pour les plugins Vault, Grafana pour les plugins de sources de données, et plusieurs moteurs de jeu l'utilisent pour les systèmes de modding.
Shopify's Checkout UI Extensions s'exécutent sous forme de modules Wasm. Le code fourni par le marchand s'exécute dans l'infrastructure Shopify sans possibilité d'exfiltrer des données ou d'accéder à des systèmes en dehors de l'interface définie. Cela n'est viable que parce que le sandboxing de Wasm le rend sûr par défaut.
Zed (l'éditeur de code basé sur Rust) utilise Wasm pour les extensions. Pas besoin de runtime Node.js, pas de chaînes de dépendances npm, pas de processus de gestion d'extension. Les extensions s'exécutent isolées dans Wasm avec une interface hôte bien définie.

Le schéma se généralise : toute plateforme qui accepte du code fourni par l'utilisateur peut remplacer le « risque d'exécution de code arbitraire » par « l'exécution Wasm dans une interface définie » et obtenir simultanément sécurité, portabilité et flexibilité linguistique.

Extensions de bases de données

L'extension expérimentale pg_wasm de PostgreSQL permet des fonctions définies par l'utilisateur (UDF) écrites dans n'importe quel langage qui se compile en Wasm. SingleStore prend en charge les UDF Wasm en production. La proposition de valeur est directe : écrivez une UDF critique en Rust, compilez en Wasm, déployez-la sans recompiler le binaire de la base de données et sans installer une toolchain Rust sur le serveur de base de données. Le sandbox Wasm signifie également qu'une UDF buggée ne peut pas corrompre la mémoire de la base de données — elle s'exécute dans son propre espace mémoire linéaire.

Pour les charges de travail analytiques, cela ouvre la porte à des agrégats et transformations personnalisés haute performance qui nécessitaient auparavant des extensions C ou étaient écrits en PL/pgSQL lent.

Inférence AI en Wasm

WasmEdge combiné à llama.cpp compilé en Wasm peut exécuter l'inférence LLM sur n'importe quel hôte WasmEdge. La surcharge par rapport à l'exécution native est d'environ 15 à 25 % — significative, mais acceptable pour de nombreux cas d'usage. La contrepartie est la portabilité : le même binaire Wasm s'exécute sur un serveur cloud x86, un nœud edge ARM ou un appareil IoT RISC-V sans recompilation.

C'est important dans les contextes IoT et edge AI embarqués où l'exécution de Docker est impraticable en raison des contraintes de stockage et de mémoire. Un modèle 7B quantifié en 4 bits fonctionnant via WasmEdge sur un appareil edge est un schéma de déploiement réel en 2026, pas une démo.

Ce que Wasm ne peut toujours pas bien faire

Les limitations de Wasm sont réelles et méritent d'être nommées :

Le multi-threading s'améliore — la proposition de threads et la mémoire partagée sont dans la spécification — mais écrire du Wasm multi-threadé correct reste plus difficile que le threading natif, et le support des runtimes varie.
Les langages avec ramasse-miettes (Go, Python, JavaScript) produisent des binaires Wasm plus volumineux car le runtime GC doit être compilé. Un binaire Go Wasm fait généralement 5 à 15 Mo. Cela diminue à mesure que l'intégration GC mûrit, mais c'est réel aujourd'hui.
Le débogage en production est plus difficile que le code natif. Les source maps aident, mais les traces de pile en Wasm sont encore moins ergonomiques que le débogage natif.
Les toolchains Java et .NET sont encore en maturation. Java a des backends Wasm expérimentaux, et .NET a Blazor pour Wasm dans le navigateur, mais le .NET côté serveur vers Wasm pour des cas d'usage généraux n'est pas encore au niveau production.

Où cela nous mène

L'origine navigateur de Wasm était un accident de l'histoire — un hôte pratique qui fournissait le sandboxing, une couche d'interopérabilité JS et un environnement standardisé. Ce que le navigateur a en réalité construit, c'est une unité d'exécution universelle, portable et sandboxée qui fonctionne aussi dans les serveurs, les nœuds edge, les bases de données et les hôtes de plugins.

Le Component Model donne enfin à Wasm la sémantique de composition pour fonctionner comme une véritable plateforme logicielle — des modules avec des interfaces typées, composables sans mémoire partagée ni complexité FFI. WASI 0.2 lui a donné le modèle d'accès système pour être utile dans des contextes non-navigateur. Les runtimes et les outils ont rattrapé leur retard.

La question n'est plus de savoir si Wasm sera important. Il tourne déjà dans votre CDN, probablement dans vos extensions IDE, et de plus en plus dans votre base de données. La question est de savoir quel cas d'usage le rendra incontournable pour votre stack — et pour la plupart des équipes, ce moment est plus proche qu'elles ne le pensent.