WebAssembly au-delà du navigateur : le futur du backend ?
WASM côté serveur avec WASI, edge computing et pourquoi Docker pourrait être challengé.
WebAssembly sort du navigateur
WebAssembly (WASM) a été créé pour exécuter du code natif dans le navigateur. Mais WASI (WebAssembly System Interface) l'a libéré du browser. Solomon Hykes, co-fondateur de Docker, a déclaré : "Si WASM+WASI avait existé en 2008, nous n'aurions pas eu besoin de créer Docker." WASM côté serveur est une réalité en 2026.
Pourquoi WASM côté serveur
Les conteneurs Docker démarrent en secondes, WASM démarre en millisecondes. Un module WASM fait quelques MB contre des centaines de MB pour une image Docker. Et WASM offre un sandboxing natif plus sécurisé que les conteneurs.
- Cold start <1ms vs >100ms pour un container — critique pour le serverless/edge
- Taille : module WASM ~1-5MB vs image Docker ~50-500MB
- Sécurité : sandboxing par défaut, capabilities-based security (pas d'accès filesystem/réseau implicite)
- Portabilité : compile once, run anywhere — plus portable que les containers
- Polyglottisme : Rust, Go, C/C++, AssemblyScript, Python compilent vers WASM
Edge Computing avec WASM
L'edge computing exécute du code au plus près de l'utilisateur (CDN nodes). CloudFlare Workers, Fastly Compute, Vercel Edge Functions utilisent WASM/V8 isolates. La latence passe de ~200ms (serveur centralisé) à <50ms (edge node le plus proche).
- CloudFlare Workers : JavaScript + WASM, 200+ datacenters, cold start <5ms
- Fastly Compute : WASM natif, Rust/Go/JS, cold start <1ms
- Spin (Fermyon) : framework open source pour apps WASM serverless
- wasmCloud : orchestrateur de microservices WASM distribués
Rust + WASM : le combo parfait
Rust est le langage le plus adapté à WASM côté serveur. Pas de garbage collector (donc pas de pause GC), binaires compacts, performance native et safety garantie par le compilateur. La majorité des runtimes WASM (Wasmtime, Wasmer) sont écrits en Rust.
