WebAssembly a quitté le navigateur — et devient l'environnement d'exécution universel pour l'edge
WebAssembly a été livré dans les navigateurs en 2017 en tant que cible de compilation pour le code critique en termes de performances — un moyen d'exécuter du C, C++ ou Rust à des vitesses que JavaScript ne peut pas atteindre pour les charges de travail lourdes en calcul. Pendant les premières années, les discussions portaient presque exclusivement sur les cas d'utilisation dans le navigateur : moteurs de jeu, traitement d'images, codecs vidéo. Ce cadre est devenu silencieusement obsolète. En 2026, certains des déploiements les plus actifs de WebAssembly n'ont rien à voir avec les navigateurs.
Cloudflare Workers traite plus de 50 millions de requêtes par seconde sur 300 sites edge, avec Wasm comme cible d'exécution de première classe aux côtés de JavaScript. La plateforme Compute de Fastly — construite entièrement autour de Wasm — traite du trafic de production pour des clients qui nécessitent des démarrages à froid inférieurs à la milliseconde, ce que les conteneurs serverless ne peuvent pas offrir. Des bases de données comme SQLite (via libsqlite-wasm), des outils d'observabilité, et des systèmes de plugins dans les éditeurs et moteurs de jeu déploient Wasm comme environnement d'exécution de plugin sûr et portable. La technologie a trouvé une adéquation produit-marché en dehors du contexte pour lequel elle a été conçue.
Ce qui rend Wasm intéressant en tant qu'environnement d'exécution
Trois propriétés distinguent WebAssembly des alternatives comme les conteneurs, les binaires natifs ou le bytecode JVM.
Portabilité binaire. Un fichier .wasm est un format binaire compact avec un jeu d'instructions bien spécifié. Compilez une fois depuis Rust, C, Go, Swift, Python ou tout langage disposant d'une cible Wasm, et le même binaire s'exécute sur n'importe quel hôte doté d'un runtime conforme — x86, ARM, RISC-V, quel que soit le système d'exploitation. C'est la promesse que la JVM a faite dans les années 1990, mais sans le overhead du ramasse-miettes ni l'obligation d'installer un runtime spécifique à la plateforme.
Vitesse d'exécution quasi-native. Le jeu d'instructions de Wasm est conçu pour être compilé directement en code machine avec un overhead minimal. Les runtimes modernes utilisent une compilation à plusieurs niveaux : un compilateur de base rapide gère la latence de démarrage à froid, un compilateur optimisant basé sur Cranelift ou LLVM prend le relais pour les fonctions chaudes. Les résultats des benchmarks de la Bytecode Alliance montrent que Wasm s'exécute dans une fourchette de 1,5 à 2 fois la vitesse du code natif équivalent pour les charges CPU — bien mieux que les langages interprétés et compétitif avec les environnements JIT.
Sandboxing déterministe. Chaque module Wasm s'exécute dans un bac à sable isolé en mémoire. Il ne peut pas accéder à la mémoire hôte en dehors de sa propre région de mémoire linéaire. Il ne peut pas faire d'appels système directement. Il ne peut pas créer de threads ni ouvrir de descripteurs de fichiers sans autorisation explicite de l'hôte. Ce n'est pas du théâtre sécuritaire — c'est appliqué au niveau instruction par le runtime. Le même modèle d'isolation qui a empêché les exploits de navigateur fait de Wasm un système de plugin convaincant : vous pouvez charger du code tiers non fiable, lui donner exactement les capacités que vous souhaitez, et mettre le reste en bac à sable.
WASI : la pièce manquante pour exécuter Wasm en dehors des navigateurs
Un module Wasm dans le navigateur obtient son interface système depuis JavaScript — l'hôte expose des API pour l'accès DOM, le réseau et le stockage. En dehors du navigateur, il n'y a pas d'hôte JavaScript. C'est le fossé que WASI — l'interface système WebAssembly — a été conçue pour combler.
WASI définit une surface d'API basée sur les capacités pour l'accès au système de fichiers, les horloges, la génération de nombres aléatoires, les sockets réseau et les variables d'environnement. Un binaire Wasm compilé avec WASI peut ouvrir des fichiers, lire des variables d'environnement et écrire sur la sortie standard en utilisant une interface standardisée — et le runtime hôte décide au moment de l'instanciation quelles capacités accorder réellement. Le même binaire s'exécute dans Wasmtime sur un serveur Linux et dans un hôte Wasm côté navigateur sans recompilation ; seules les autorisations accordées diffèrent.
WASI Preview 2, finalisée en 2024 et adoptée largement par les runtimes tout au long de 2025-2026, est l'avancée la plus significative. Elle introduit le modèle de composants — une façon de composer plusieurs modules Wasm avec des interfaces typées en utilisant un nouveau langage de définition d'interface appelé WIT (Wasm Interface Types). Au lieu de passer des pointeurs mémoire bruts entre les modules, les composants exposent des API fortement typées. Un composant qui traite des images peut déclarer qu'il accepte image: png-image et renvoie thumbnail: jpeg-image, et le runtime Wasm peut le lier à n'importe quel autre composant qui parle les mêmes types, quel que soit le langage de compilation de chacun. C'est la pièce qui rend « compiler depuis Rust, appeler depuis Python » effectivement composable plutôt que simplement théoriquement possible.
Runtimes et plateformes
L'écosystème des runtimes a considérablement mûri depuis les premiers jours de l'expérimentation uniquement avec Node.
Wasmtime, maintenu par la Bytecode Alliance — un organisme de normalisation dont les membres incluent Mozilla, Fastly, Intel, Microsoft et Google — est l'implémentation de référence pour WASI. Écrit en Rust, il utilise le générateur de code Cranelift pour une compilation optimisée. Wasmtime est le runtime sous-jacent de Fastly Compute@Edge et est largement utilisé pour intégrer Wasm dans les applications serveur. Le CLI (wasmtime run module.wasm) permet de tester facilement les binaires Wasm localement.
WasmEdge, un projet CNCF en phase sandbox, cible les charges de travail cloud-natives et IA. Il dispose d'un support de première classe pour l'inférence de modèles ONNX via une implémentation native wasi-nn, ce qui en fait le runtime de prédilection pour les cas d'usage IA à l'edge. WasmEdge s'intègre avec containerd et peut être utilisé comme une alternative légère à un runtime de conteneur complet pour les charges de travail Wasm dans les clusters Kubernetes — un modèle de déploiement qui évite le overhead d'un espace utilisateur Linux complet par charge de travail.
Wasmer adopte une approche différente : il privilégie l'intégration native dans les langages, avec des SDK pour Rust, Python, Go, Java, PHP et Ruby qui permettent d'instancier et d'appeler des modules Wasm depuis le code hôte avec un minimum de code passe-partout. Wasmer propose également WASIX — une extension de WASI qui ajoute des primitives de threading, de fork de processus et de pipes compatibles POSIX, permettant à davantage de programmes de type Unix d'être compilés en Wasm sans modification.
Spin, construit par Fermyon, est un framework d'application orienté pour les microservices Wasm. Là où Wasmtime est un runtime que vous intégrez, Spin est une plateforme sur laquelle vous construisez — définissez vos composants dans un manifeste spin.toml, implémentez les gestionnaires en Rust, Go ou Python, et Spin gère le routage HTTP, le stockage clé-valeur, l'accès SQL et la publication/abonnement via des API Wasm natives. Fermyon Cloud exécute les applications Spin directement ; le framework peut également se déployer sur Kubernetes via l'opérateur Spin.
Du côté des plateformes, Cloudflare Workers a été le pionnier du Wasm à l'edge en tant que service de production. Workers utilise des isolates V8 avec support Wasm pour atteindre des temps de démarrage à froid inférieurs à 5 millisecondes à l'échelle mondiale — un chiffre que les fonctions de type Lambda basées sur des conteneurs ne peuvent pas approcher. Fastly Compute@Edge va encore plus loin : chaque instance Compute est un module Wasm, sans aucun runtime JavaScript du tout, permettant une exécution en moins d'une milliseconde de la logique de traitement des requêtes sur les nœuds edge de Fastly.
Cas d'usage réels en 2026
Les systèmes de plugins sont sans doute le cas d'usage non-navigateur le plus réussi de Wasm en termes de déploiement. Extism (par Dylibso) est un système de plugin open source construit sur Wasm : intégrez un petit hôte Extism dans votre application, et tout tiers peut écrire des plugins en Rust, Go, Python ou TypeScript qui s'exécutent dans un environnement Wasm en bac à sable avec des capacités déclarées. Des projets comme l'éditeur Zed, WasmCloud et plusieurs extensions de bases de données utilisent ce modèle. Le modèle d'isolation de Wasm résout le problème de confiance envers l'auteur du plugin qui a tourmenté les systèmes de plugins natifs pendant des décennies.
Les fonctions edge sont le déploiement le plus volumineux. Cloudflare Workers traite des milliards de requêtes quotidiennement en utilisant des modules Wasm écrits par les clients en Rust et C++ aux côtés des workers JavaScript. Les cas d'usage vont de l'authentification des requêtes et du routage A/B à la transformation d'images et à la réécriture HTML à l'edge — une logique qui nécessiterait sinon un aller-retour vers un serveur d'origine.
L'inférence IA à l'edge est un cas d'usage émergent où la portabilité de Wasm et le support wasi-nn de WasmEdge se rencontrent. De petits modèles ONNX — classificateurs d'images, modèles d'embedding, catégorisation de texte — peuvent être compilés en bundles Wasm autonomes et déployés sur des nœuds edge sans gestion de dépendances par nœud. WasmEdge prend en charge l'accélération matérielle via les backends OpenVINO et TensorFlow Lite, maintenant la latence d'inférence compétitive avec les déploiements natifs pour les modèles de moins de 100 millions de paramètres.
Les outils CLI portables construits comme des binaires Wasm se distribuent sous forme de fichiers uniques qui s'exécutent sur n'importe quelle plateforme disposant d'un runtime Wasm — pas de builds spécifiques à une architecture, pas de problèmes de liaison dynamique. Le projet wasi-vfs permet de regrouper un système de fichiers virtuel dans le binaire, permettant à des outils de se comporter comme des exécutables liés statiquement tout en ne compilant qu'une seule fois à partir d'une seule arborescence source.
Là où il reste des aspérités
L'histoire du threading reste incomplète. La proposition threads — mémoire linéaire partagée et atomiques — est implémentée dans les principaux navigateurs et dans Wasmtime, mais l'interaction entre les threads et le modèle de capacités WASI est encore en cours de normalisation. La plupart des déploiements Wasm de production en dehors des navigateurs sont monothreadés, ce qui constitue une véritable contrainte pour les charges CPU qui s'attendent à paralléliser sur plusieurs cœurs.
La maturité des chaînes d'outils varie considérablement selon le langage. Rust bénéficie d'un excellent support Wasm — cargo build --target wasm32-wasi fonctionne pour la plupart des crates, et l'écosystème est bien testé. La sortie Wasm de Go s'est améliorée dans Go 1.21–1.24 mais produit encore des binaires volumineux et dispose d'un support WASI limité en dehors de la cible expérimentale GOOS=wasip1. Python via CPython-wasm ou Pyodide fonctionne, mais le binaire de l'interpréteur seul pèse 20 à 30 Mo. Les langages avec ramasse-miettes ajoutent un overhead d'exécution — le ramasse-miettes lui-même doit être compilé dans le module Wasm, et sans heap géré par l'hôte, les schémas d'utilisation de la mémoire diffèrent des déploiements natifs.
Le débogage reste douloureux. Les informations de débogage DWARF peuvent être intégrées dans les binaires Wasm, et des outils comme wasm-pack et les DevTools des navigateurs prennent en charge les source maps pour Rust et C++. Mais le débogage pas à pas des modules Wasm dans un runtime serveur — définir des points d'arrêt, inspecter les piles d'appels, surveiller la mémoire — n'est pas encore aussi fluide que le débogage de code natif ou de bytecode JVM. L'expérience s'améliore mais accuse un retard de plusieurs années de polissage par rapport aux chaînes d'outils natives.
La surface d'API WASI est encore incomplète pour les applications serveur à usage général. Les entrées/sorties asynchrones (via wasi-io et wasi-http dans WASI Preview 2) sont disponibles mais l'écosystème de bibliothèques les ciblant est mince. Les développeurs qui portent du code serveur existant vers Wasm constatent souvent que leurs dépendances supposent des interfaces POSIX que WASI ne fournit pas ou qu'il enveloppe avec suffisamment de friction pour nécessiter un travail de portage important.
Où Wasm se dirige
La normalisation du modèle de composants est le développement à court terme le plus conséquent. Alors que l'adoption de WASIp2 se répand dans les runtimes — Wasmtime, WasmEdge, Wasmer et les implémentations de moteurs JS dans les navigateurs — la capacité de composer des composants Wasm typés provenant de différents écosystèmes linguistiques sans friction FFI devient une véritable primitive de plateforme. Les outils autour de la génération d'interface WIT mûrissent rapidement dans les projets cargo-component et wit-bindgen de la Bytecode Alliance.
La convergence de eBPF et Wasm est un développement à plus long terme qui mérite l'attention. Les deux technologies offrent une exécution de code en bac à sable dans un environnement hôte — eBPF dans le noyau Linux, Wasm dans les runtimes espace utilisateur. Des projets comme bpf-wasm explorent l'utilisation de Wasm comme alternative plus sûre et plus portable aux programmes eBPF natifs pour l'observabilité et la mise en réseau proches du noyau. Les jeux d'instructions sont différents, mais les objectifs architecturaux — exécution à haute performance, en bac à sable et contrôlée par capacités de code non fiable — sont identiques.
Le navigateur n'a jamais été destiné à être la plus grande surface de déploiement de WebAssembly. Une technologie qui offre un sandboxing déterministe, des performances quasi-natives et une véritable portabilité binaire entre architectures résout des problèmes qui existent partout dans les logiciels système — pas seulement dans le runtime JavaScript. Les runtimes, les normes et les déploiements de production réels sont désormais suffisamment matures pour que « Wasm est un truc de navigateur » soit le même genre d'erreur de catégorie que « Linux est un OS pour serveur web ». Vrai un jour, et maintenant totalement hors de propos.