WebAssembly au-delà du navigateur : comment Wasm devient le runtime universel pour le

Du bac à sable navigateur au runtime universel

WebAssembly est né en 2017 comme cible de compilation pour le navigateur — un moyen d’exécuter du code C, C++ et Rust à une vitesse quasi native dans les applications web. Il a alimenté tout, de l’outil de design Figma au Photoshop web d’Adobe et à l’export web du moteur Unity. Mais dès 2024, les développements les plus conséquents dans WebAssembly n’avaient plus rien à voir avec les navigateurs.

La citation qui a lancé mille conférences vient de Solomon Hykes, cofondateur de Docker, en mars 2019 : « If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. » Sept ans plus tard, la prédiction de Hykes s’est matérialisée plus vite que prévu. En janvier 2024, la Bytecode Alliance a publié WASI Preview 2 (WASI 0.2) avec des interfaces standardisées pour HTTP, les E/S fichiers, les sockets et les horloges — transformant Wasm d’une curiosité navigateur en une véritable plateforme applicative. En septembre 2025, WebAssembly 3.0 est devenu le standard officiel du W3C, ajoutant la collecte des déchets (garbage collection), l’espace d’adressage 64 bits, la gestion des exceptions et les mémoires multiples. Et en décembre 2025, Akamai a acquis Fermyon — la startup derrière le framework Spin — signalant que le plus grand CDN mondial voit Wasm comme l’avenir de l’edge computing.

L’écosystème n’est plus expérimental. La plateforme Compute de Fastly, Cloudflare Workers, wasmCloud de Cosmonic (désormais projet incubé CNCF), et l’implication de Microsoft via la Bytecode Alliance représentent tous des paris entreprise sérieux sur Wasm comme runtime côté serveur. Ce qui rend ce changement significatif n’est pas qu’un autre runtime existe — le monde n’en manque pas — mais que Wasm résout des problèmes spécifiques que les conteneurs gèrent mal : la latence de démarrage à froid, l’isolation multi-tenant et la portabilité multi-plateforme. Ce sont exactement les problèmes qui comptent le plus à l’edge, où le calcul s’effectue sur des milliers de nœuds distribués plutôt que dans des centres de données centralisés.

L’argument technique : pourquoi Wasm bat les conteneurs à l’edge

Les conteneurs ont révolutionné le déploiement en empaquetant les applications avec leurs dépendances dans des images portables. Mais les conteneurs ont une surcharge qui devient prohibitive à l’edge. Une image conteneur minimale fait des dizaines de mégaoctets ; un module Wasm pour une fonctionnalité équivalente fait typiquement de quelques dizaines de kilo-octets à quelques mégaoctets. Les démarrages à froid des conteneurs — lancer une nouvelle instance de zéro — prennent des centaines de millisecondes à des secondes, même avec optimisation. Les démarrages à froid Wasm se mesurent en microsecondes : la plateforme Compute de Fastly initialise les modules Wasm en environ 35 microsecondes — environ 100 fois plus rapide que les solutions serverless concurrentes. Le framework Spin de Fermyon atteint des démarrages à froid autour de 0,5 milliseconde, et leur plateforme Kubernetes délivre plus de 1 500 applications serverless par nœud avec un démarrage sous la milliseconde.

Cet écart de performance compte parce que l’edge computing est fondamentalement une question de latence. Quand un Cloudflare Worker traite une requête sur un nœud edge à Johannesburg ou Jakarta, l’utilisateur attend’une réponse en quelques millisecondes. La plateforme Cloudflare gère désormais plus de 10 millions de requêtes alimentées par Wasm par seconde sur son réseau mondial. Les plateformes serverless basées sur les conteneurs comme AWS Lambda ont progressé sur les démarrages à froid — Lambda SnapStart et la concurrence provisionnée aident — mais elles optimisent autour d’une abstraction fondamentalement plus lourde. Wasm démarre vite parce qu’il est petit, sandboxé dès la naissance et conçu pour une instanciation rapide. Il n’y a pas de noyau à démarrer, pas de système init à exécuter, pas d’espace de noms réseau à configurer.

L’isolation de sécurité est l’autre avantage critique. Chaque module Wasm s’exécute dans un environnement sandboxé sans accès au système hôte sauf si explicitement accordé via des permissions basées sur les capacités. Ce n’est pas de la sécurité ajoutée après coup comme les namespaces et cgroups des conteneurs — c’est intégré dans le modèle d’exécution. Pour les plateformes edge multi-tenant — où le code de milliers de clients différents s’exécute sur la même machine physique — ce modèle d’isolation est fondamentalement plus robuste que les alternatives basées sur les conteneurs. Cloudflare exécute des millions de Workers sur une infrastructure partagée avec ce modèle, et Shopify utilise Wasm pour sandboxer les extensions de logique métier tierces via son API Functions, atteignant des niveaux de densité impossibles avec des conteneurs.

WASI et le Component Model : construire la plateforme

Le WebAssembly brut est un moteur de calcul — il peut traiter des données et retourner des résultats. Ce qu’il ne pouvait pas faire, jusqu’à récemment, était interagir avec le monde extérieur de manière standardisée. WASI — la WebAssembly System Interface — change cela en définissant des interfaces portables pour les capacités système : E/S fichiers, sockets réseau, requêtes HTTP, horloges, génération de nombres aléatoires et variables d’environnement. WASI est à Wasm ce que POSIX est à Unix : une couche d’interface standard qui permet au code de s’exécuter sur différentes implémentations.

WASI 0.2, publié en janvier 2024, a introduit le Component Model — sans doute le développement architecturalement le plus significatif de l’écosystème Wasm. Le Component Model permet aux modules Wasm de définir des interfaces typées (utilisant un langage appelé WIT — WebAssembly Interface Type) et de se composer ensemble comme des blocs de construction. Un composant écrit en Rust peut exposer une interface consommée par un composant écrit en Python, le runtime gérant la conversion de données automatiquement. C’est une véritable interopérabilité entre langages — non pas via des hacks FFI ou des couches de sérialisation, mais via un système de types partagé à la frontière des modules.

Les implications pour l’architecture logicielle sont profondes. Au lieu d’applications monolithiques ou de microservices communiquant via HTTP, le Component Model permet ce que certains appellent des « nanoservices » — des composants fonctionnels à granularité fine qui se composent au sein d’un seul processus runtime. Le Spin de Fermyon (désormais partie d’Akamai), wasmCloud et le runtime open-source Wasmtime supportent tous la composition de composants. L’implication de Microsoft via la Bytecode Alliance — qui pilote la spécification WASI et les implémentations de référence — signale que ce n’est pas une expérience marginale.

La feuille de route est claire : WASI 0.3, ciblant début 2026, ajoute le support async natif via des types explicites stream et future, permettant à toute fonction de composant d’être appelée de manière asynchrone. Des previews sont déjà disponibles dans Wasmtime 37+. Ensuite, WASI 1.0 — la version stable sans rupture de compatibilité — est planifiée pour fin 2026 ou début 2027. Quand elle sortira, Wasm aura une interface système mature et standardisée comparable en portée à ce que POSIX a fourni pour Unix.

L’écosystème en 2026 : qui parie sur Wasm

L’écosystème WebAssembly côté serveur a mûri rapidement, et 2025 a marqué un tournant avec une consolidation majeure. Fermyon, fondé par d’anciens ingénieurs de Microsoft Azure, a construit le framework Spin et Fermyon Cloud — une plateforme serverless conçue pour Wasm. Leur pari était que Wasm remplacerait les conteneurs pour une classe significative d’applications : les backends API, les processeurs d’événements et les gestionnaires de webhooks où la vitesse de démarrage et la densité comptent plus que le débit de calcul brut. Fermyon a levé 26 millions de dollars au total (6M en seed plus 20M en Series A) avant d’être acquis par Akamai Technologies en décembre 2025. L’acquisition positionne Akamai — le plus grand CDN mondial — pour concurrencer directement Cloudflare Workers avec de l’edge computing basé sur Wasm, et valide la viabilité commerciale du Wasm côté serveur.

Fastly a reconstruit sa plateforme d’edge computing autour de Wasm, la renommant de Compute@Edge en simplement Fastly Compute. Chaque requête traitée par le CDN de Fastly peut déclencher de la logique basée sur Wasm, et la plateforme supporte Rust, JavaScript, Go et d’autres langages compilés en Wasm. Cloudflare Workers, bien qu’initialement basé sur les isolats V8, a de plus en plus adopté Wasm — particulièrement pour les charges de travail intensives en calcul où les performances JavaScript sont insuffisantes. Shopify utilise Wasm pour son API Functions, exécutant des extensions de logique métier tierces en toute sécurité via un runtime sandboxé qui supporte Rust, AssemblyScript, TinyGo et JavaScript (via Javy, la chaîne d’outils JS-vers-Wasm propre à Shopify). Adobe utilise Wasm via Emscripten pour porter des applications natives C/C++ comme Photoshop et Lightroom dans les navigateurs web.

Le wasmCloud de Cosmonic — une plateforme d’orchestration Wasm-native — est passé au statut d’incubation CNCF en novembre 2024, et Cosmonic a lancé Cosmonic Control en mars 2025 pour la gestion distribuée d’applications de niveau entreprise. Côté Kubernetes, SpinKube est devenu un projet sandbox CNCF, et Azure Kubernetes Service de Microsoft a retiré ses pools de nœuds WASI en preview en mai 2025 en faveur de SpinKube comme voie recommandée pour exécuter des charges Wasm sur Kubernetes.

L’écosystème des conteneurs répond. Docker Desktop supporte désormais les charges Wasm nativement, permettant aux développeurs d’exécuter des modules Wasm aux côtés de conteneurs Linux traditionnels depuis le même fichier docker-compose.yml, utilisant des runtimes comme Spin, WasmEdge et Wasmtime via des shims containerd. Un benchmark 2025 a montré que les applications Wasm atteignent une empreinte mémoire jusqu’à 40% inférieure par rapport aux conteneurs traditionnels. Ce chemin d’intégration suggère que Wasm ne remplacera pas les conteneurs en gros mais les complétera — gérant les charges légères et sensibles à la latence où les conteneurs sont surdimensionnés, tandis que les conteneurs continuent de servir les applications stateful à longue durée. Le cadrage « Wasm vs. conteneurs » cède la place à « Wasm et conteneurs », le runtime étant choisi selon les caractéristiques de la charge plutôt que par idéologie.

Ce que Wasm ne peut pas faire (encore)

Malgré tous ses avantages, WebAssembly hors du navigateur a des limitations réelles qui tempèrent l’enthousiasme. Le support du threading reste incomplet — la proposition Wasm threads est implémentée dans certains runtimes mais pas universellement, limitant les charges parallèles intensives en calcul. Le support des langages à garbage collection s’est significativement amélioré avec WasmGC désormais standardisé dans Wasm 3.0 et livré dans tous les principaux navigateurs. Java, Kotlin, Dart, OCaml et Scala peuvent cibler WasmGC, et Google Sheets a porté son moteur de calcul vers WasmGC en production. Cependant, Go n’a pas encore implémenté le support WasmGC, et l’exécution de frameworks Java enterprise complets en tant que Wasm reste moins mature que les cibles de compilation natives. L’écosystème de bibliothèques et frameworks croît mais reste une fraction de ce qui est disponible pour les conteneurs — un développeur Wasm ne peut pas simplement tirer une image Docker avec PostgreSQL et Redis et avoir un stack complet fonctionnel.

Les outils de débogage et d’observabilité sont en retard par rapport aux conteneurs. Les écosystèmes de conteneurs bénéficient d’une décennie d’investissement dans les outils de logging, tracing, métriques et profilage. L’observabilité Wasm s’améliore — des intégrations OpenTelemetry et des outils spécifiques aux runtimes existent — mais l’expérience n’est pas encore comparable. Pour les équipes ayant construit des pratiques opérationnelles autour de déploiements basés sur les conteneurs, passer à Wasm signifie reconstruire une grande partie de leur outillage opérationnel.

La gestion d’état est un autre défi. Les modules Wasm sont conçus pour être sans état et éphémères — démarrer, traiter, répondre, terminer. Les applications nécessitant des connexions persistantes, des caches en mémoire ou des processus de longue durée ne s’adaptent pas bien au modèle Wasm. La composabilité du Component Model aide en permettant aux composants stateful d’être fournis par le runtime hôte, mais ce pattern nécessite de repenser l’architecture applicative d’une manière à laquelle la plupart des équipes ne sont pas encore préparées. Le support async natif de WASI 0.3, attendu début 2026, devrait atténuer certaines de ces contraintes en permettant aux composants de gérer des E/S concurrentes sans bloquer — mais la statefulness véritable reste un défi de conception plutôt qu’une limitation du runtime.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Solomon Hykes on WASM+WASI — X (formerly Twitter)
• Wasm 3.0 Completed — WebAssembly.org
• Akamai Acquires Fermyon — Akamai Newsroom
• WASI 0.2 Launched — Bytecode Alliance
• The WebAssembly Component Model — Bytecode Alliance
• Fastly Compute Platform — Fastly
• Cloudflare Workers and WebAssembly — Cloudflare
• Fermyon Spin Framework — Fermyon
• SpinKube: Wasm on Kubernetes — SpinKube
• CNCF Welcomes wasmCloud to Incubator — CNCF
• Docker Wasm Workloads — Docker Docs
• WASI Roadmap — WASI.dev