Le cas d'usage le plus convaincant de WebAssembly se trouve en dehors du navigateur

Lorsque WebAssembly a fait ses débuts dans les principaux navigateurs en 2017, le discours était simple : exécuter du code quasi natif dans le navigateur sans JavaScript. Les premiers adoptants ont porté des moteurs de jeux C++, des interpréteurs Python et des bibliothèques de traitement d'images sur le web. Cela fonctionnait, mais les cas d'usage semblaient de niche — la plupart des applications web n'avaient pas besoin de la puissance de calcul du C, et l'écosystème JavaScript était suffisamment riche pour que WASM ne le remplace que rarement dans le développement classique.

L'application la plus convaincante s'est finalement révélée être en dehors du navigateur. Au cours des deux dernières années, WebAssembly s'est imposé comme un runtime crédible pour trois contextes distincts côté serveur — les fonctions serverless, les systèmes de plugins et l'edge computing — où son modèle de sécurité et sa portabilité comptent plus que les performances brutes.

La propriété qui rend WASM différent sur le serveur

La caractéristique clé est le sandboxing par défaut. Un module WASM s'exécute dans un espace mémoire isolé, sans accès au système hôte sauf autorisation explicite via l'interface système WebAssembly (WASI). Il ne peut pas lire de fichiers, ouvrir des connexions réseau ou lancer des processus sans octroi explicite de capacités de la part de l'hôte. Pour les navigateurs, c'était une exigence de sécurité ; pour les environnements serveur, c'est un avantage architectural.

Comparez cela au problème traditionnel des plugins. Lorsque vous souhaitez exécuter du code tiers dans votre application — un plugin, une extension, une fonction définie par l'utilisateur — les options ont historiquement été douloureuses. Soit vous faites implicitement confiance au développeur du plugin et exposez votre processus à d'éventuels bugs ou codes malveillants, soit vous exécutez les plugins dans un sous-processus avec toute la surcharge de la communication inter-processus (IPC), soit vous mettez en place une liste blanche de capacités complexe, spécifique au runtime et difficile à auditer. WASM résout cela avec une primitive unique : les modules s'exécutent dans leur propre sandbox, et vous définissez exactement quelles fonctions hôtes ils peuvent appeler via une interface typée.

Fonctions serverless : l'avantage du démarrage à froid

Cloudflare Workers a été l'un des premiers paris de production sur WASM pour le serverless. Workers exécute JavaScript et WASM dans des isolates V8 sur le réseau edge de Cloudflare, avec l'affirmation centrale que les temps de cold start chutent radicalement car les modules WASM n'ont pas de système d'exploitation à amorcer. Cloudflare rapporte des cold starts médians inférieurs à 5 millisecondes pour les invocations de Workers, contre 100 à 500 ms pour les fonctions Lambda basées sur des conteneurs.

Fastly a adopté une approche similaire avec sa plateforme Compute, qui exécute exclusivement du WASM et se positionne comme le remplacement de VCL (Varnish Configuration Language). Les développeurs écrivent en Rust, Go, JavaScript ou tout autre langage ciblant WASM, compilent en module, et le déploient en tant que service Fastly — pas de conteneurs, pas de capacité provisionnée, pas de gestion de cold start.

Le framework Spin de Fermyon étend cette approche au développement général d'applications. Spin permet de construire des microservices qui compilent en WASM et s'exécutent sans conteneurs ni Kubernetes. Chaque fonction est un module qui démarre en quelques millisecondes, traite une requête, puis se termine. Pas de pool de conteneurs chauds, pas d'infrastructure sidecar par fonction, pas de registre d'images conteneur à maintenir.

Systèmes de plugins : là où le modèle de sécurité paie

Extism est un kit de développement de plugins open source qui utilise WASM pour permettre aux développeurs d'intégrer du code tiers en toute sécurité. Plutôt que d'exiger que les plugins soient écrits dans le langage hôte, Extism permet de les compiler à partir de n'importe quel langage ciblant WASM — Go, Rust, Python, JavaScript. L'hôte définit une petite interface typée ; le plugin ne communique qu'à travers cette interface. Un plugin bogué ou malveillant ne peut pas s'échapper du sandbox.

Grafana Labs a adopté ce modèle pour les plugins backend. Les nouveaux types de plugins Grafana s'exécutent en tant que modules WASM dans le backend de Grafana, isolés les uns des autres et du processus Grafana. Cela élimine une classe d'attaques de la chaîne d'approvisionnement où un plugin compromis obtient un accès complet au processus — une préoccupation réelle dans un écosystème comptant des centaines de contributions tierces.

Envoy Proxy a ajouté le support des extensions WASM pour la même raison : un crash de module WASM ne fait pas tomber le processus proxy ni n'affecte le trafic transitant par d'autres extensions. Pour une infrastructure edge qui doit rester disponible, cette isolation des défaillances compte plus que les performances brutes.

Le Component Model : la pièce manquante désormais disponible

Le développement le plus important récent dans l'écosystème WASM est le Component Model, introduit dans WASI 0.2 début 2024. Auparavant, les modules WASM communiquaient via des buffers mémoire partagée — bas niveau et sujets aux erreurs. Le Component Model introduit des interfaces typées que les modules peuvent implémenter et consommer, permettant la composition sans mémoire partagée.

Concrètement, cela signifie que vous pouvez définir une interface typée et que les plugins l'implémentent quel que soit leur langage source. Un hôte Rust peut appeler un plugin Python ou Go via la même interface typée, le runtime WASM gérant la traduction. Cela résout le plus gros point de friction des systèmes de plugins WASM : l'obligation de liaisons FFI ou d'un runtime partagé.

La Bytecode Alliance — Mozilla, Intel, Fastly, Microsoft et Google — est l'organisation principale qui fait progresser WASM en dehors du navigateur. Leur runtime Wasmtime est l'implémentation de référence pour WASI 0.2 et ce sur quoi la plupart des déploiements en production s'appuient.

Limitations actuelles à connaître

WASM en dehors du navigateur est prêt pour la production pour des charges de travail spécifiques, mais n'est pas universellement mature. Le threading nécessite de la mémoire partagée, ce qui entre en conflit avec le modèle d'isolation utilisé par la plupart des runtimes serverless — la plupart des déploiements sont donc monothreadés, limitant les charges de travail applicables. WASM GC (garbage collection), qui permet aux runtimes de langages gérés de compiler en WASM sans embarquer leur propre GC, n'est disponible que depuis fin 2023 dans les navigateurs majeurs et n'est pas encore largement supporté dans les runtimes serveur. La qualité des toolchains varie considérablement : Rust et Go ont les cibles WASM les plus matures ; Python et JavaScript fonctionnent mais avec plus de complexité opérationnelle.

Pour les développeurs construisant des plateformes qui acceptent du code tiers — passerelles API, outils d'automatisation, produits d'observabilité, marketplaces de développeurs — WASM est désormais une option architecturale sérieuse pour la couche de plugins. Le modèle de sécurité est réel, les performances sont acceptables pour des charges de travail limitées à une requête, et le Component Model rend la composition inter-langages pratique. Les cas d'usage côté serveur sont ceux où les propriétés architecturales qui rendent WASM intéressant se différencient le plus clairement des alternatives.