Lorsque WebAssembly (Wasm) est apparu pour la première fois en 2017, sa mission semblait très claire : permettre aux développeurs Web d'exécuter du code haute performance dans un navigateur. Mais aujourd'hui, quelques années plus tard, nous assistons à quelque chose d'inattendu : WebAssembly quitte rapidement son environnement d'origine et conquiert les serveurs, les périphériques edge et même les systèmes embarqués. Que se passe-t-il ?
Un problème que personne ne s'attendait à résoudre.
Imaginez l'architecture typique d'une application cloud moderne. Vous disposez de microservices dans différents langages : Go, Node.js, Python, Rust. Chacun d'entre eux nécessite son propre environnement d'exécution, un ensemble de dépendances et une configuration spécifique. Le déploiement devient une quête et la sécurité un casse-tête permanent.
Imaginez maintenant que vous puissiez compiler n'importe lequel de ces services dans un format unique et universel qui fonctionne partout avec des performances prévisibles et des garanties de sécurité en béton. C'est exactement ce que WebAssembly promet en dehors du navigateur.
WASI : un pont vers le monde réel
Un moment clé dans l'évolution de WebAssembly a été l'apparition de WASI (WebAssembly System Interface), une API standardisée pour l'interaction avec le système d'exploitation. Si Wasm est un processeur, alors WASI est son système d'exploitation.
// Serveur HTTP simple sur Rust, compilé en Wasm
use wasi::http;
#[no_mangle]
pub extern "C" fn handle_request() -> i32 {
let request = http::incoming_request();
let response = http::outgoing_response();
response.set_status_code(200);
response.body().write(b"Hello from WebAssembly!");
0
}WASI résout un problème critique : comment donner aux modules Wasm l'accès au système de fichiers, au réseau et aux autres ressources du système, tout en conservant le modèle de sécurité basé sur les capacités. Le module n'accède qu'à ce qui est explicitement autorisé et rien de plus.
Une performance qui surprend
L'un des principaux avantages de WebAssembly sur le serveur est la vitesse de lancement. Les conteneurs traditionnels peuvent démarrer en quelques secondes, le démarrage à froid des fonctions Lambda se mesure en centaines de millisecondes. Module Wasm ? En microsecondes.
Ce ne sont pas seulement de beaux chiffres. C'est un changement fondamental dans notre façon de penser à l'échelle :
Conteneur Docker :
Temps de démarrage à froid : 1-3 secondes
Volume : 50-500 Mo
Isolation : via l'espace de noms et les cgroups
Module WebAssembly :
Temps de démarrage à froid : <1 ms
Taille : 1-10 Mo
Isolation : intégrée dans le runtime
Fastly rapporte que sa plateforme Compute@Edge basée sur Wasm lance des instances en 35 microsecondes. Cloudflare Workers obtient des résultats similaires. Cela ouvre de nouveaux modèles d'utilisation.
Edge computing : une nouvelle patrie pour Wasm
L'informatique de périphérie est l'endroit où WebAssembly brille vraiment. Imaginez un nœud CDN qui ne se contente pas de fournir du contenu statique, mais qui exécute votre logique métier au plus près de l'utilisateur.
// Cloudflare Worker sur AssemblyScript (compilé en Wasm)
export function handleRequest(request: Request): Response {
const url = new URL(request.url);
// Personnalisation du contenu sur Edge
const country = request.headers.get("CF-IPCountry");
const content = getLocalizedContent(country);
// Test A/B
const variant = Math.random() > 0.5 ? "A" : "B";
return new Response(content, {
headers: {
"X-Variant": variant,
"Cache-Control": "public, max-age=60"
}
});
}Grâce à un démarrage instantané et à une surcharge minimale, Wasm vous permet d'exécuter du code dans des milliers de points de présence à travers le monde sans coûts d'infrastructure insensés.
Plugins et extensibilité.
L'une des applications les plus intéressantes de WebAssembly en dehors du navigateur est le système de plug-ins. L'application doit permettre aux utilisateurs d'étendre les fonctionnalités, mais comment le faire en toute sécurité ?
Les approches traditionnelles nécessitaient soit l'exécution de code non fiable dans des processus séparés (lentement), soit l'utilisation d'interpréteurs intégrés (limités). Wasm offre un juste milieu :
// L'application hôte sur Go télécharge le plugin utilisateur
package main
import (
"github.com/tetratelabs/wazero"
)
func main() {
ctx := context.Background()
runtime := wazero.NewRuntime(ctx)
defer runtime.Close(ctx)
// Chargement du plugin de l'utilisateur
plugin, _ := os.ReadFile("user_plugin.wasm")
mod, _ := runtime.InstantiateModuleFromBinary(ctx, plugin)
// Appel de la fonction avec des restrictions de ressources
result, _ := mod.ExportedFunction("process_data").
Call(ctx, data)
}Cette approche est utilisée par :
Envoy — pour les filtres de trafic personnalisés
Shopify — pour les scripts personnalisés dans les magasins
Figma — pour les plugins (oui, à la fois sur le front et sur le backend)
Des cas réels qui impressionnent
Disney+: utilise Wasm pour le traitement des images et des vidéos côté serveur. Un runtime, de nombreux formats de traitement.
Shopify: exécute des millions de scripts personnalisés par jour sur Wasm, en traitant la logique de paiement pour des milliers de magasins.
Cosmonic: Nous avons construit toute la plateforme sur wasmCloud, où les applications peuvent migrer à la volée entre les clouds et les emplacements périphériques.
SingleStore: avons ajouté Wasm pour exécuter des fonctions personnalisées directement dans la base de données, en toute sécurité et rapidement.
Défis et contraintes.
Tout ce qui brille n'est pas or. Le serveur WebAssembly a ses propres problèmes :
Il n'y a pas encore de consensus sur WASI. La spécification est en développement actif, différents runtime prennent en charge différentes versions. WASI Preview 2 promet la stabilité, mais il n'y a pas encore d'adoption généralisée.
Le débogage est plus difficile. Les outils de débogage du code Wasm sur le serveur ne sont qu'en développement. Il n'y a pas de strace, gdb ou débogueurs habituels prêts à l'emploi.
Écosystème des bibliothèques. De nombreuses bibliothèques populaires ne prennent pas encore en charge la compilation dans Wasm ou nécessitent des correctifs.
La productivité n'est pas toujours meilleure. Pour les tâches gourmandes en CPU, Wasm peut être 10 à 50 % plus lent que le code natif. Un démarrage rapide ne compense pas toujours cela.
Le moment est venu d'expérimenter. Essayez Wasmtime, jouez avec Spin, écrivez votre premier module Wasm côté serveur. L'avenir est déjà là, il est juste inégalement réparti.
Code n'est pas seulement une application, mais votre mentor personnel dans le monde de la programmation. Il explique tout avec des mots simples, aide à consolider les connaissances dans la pratique et donne des récompenses cool pour les succès 🏅
Et nous avons aussi communauté chaleureuse et amicale sur Telegram, où chacun peut poser une question et obtenir une réponse, sans jugement ni théorie inutile. Ensemble, nous résolvons les problèmes, analysons les erreurs et nous nous soutenons mutuellement sur la voie de l'objectif.