WebAssembly côté serveur : le container killer dont tout le monde parle ?

C'est quoi ce WebAssembly qui sort du navigateur ?

Si tu as suivi un peu l'actu tech ces dernières années, tu as forcément croisé le sigle WASM. À l'origine, WebAssembly a été conçu pour faire tourner du code quasi natif (C, C++, Rust...) directement dans ton navigateur, histoire de booster les perfs des applis web gourmandes (jeux, édition vidéo, CAD...). Sauf que des petits malins se sont dit : « Pourquoi limiter un format binaire ultra portable, sandboxé et rapide au seul navigateur ? »

Résultat : depuis quelques années, WebAssembly s'exporte côté serveur grâce à des runtimes comme Wasmtime, WasmEdge ou Wasmer. L'idée est simple : au lieu de packager toute une application dans un container avec son propre OS minimal, ses libs système, son overhead réseau... on compile son code en un module WASM ultra compact qui tourne dans une sandbox sécurisée, sans avoir besoin d'un noyau Linux complet en dessous.

Pourquoi ça fait autant parler dans l'infra cloud

On ne va pas se mentir, Docker et Kubernetes ont posé les fondations du cloud moderne. Mais ils traînent quelques boulets historiques :

• Un container Docker démarre en centaines de millisecondes, parfois plus selon l'image
• Chaque image embarque un mini système d'exploitation, donc du poids et une surface d'attaque plus grande
• L'isolation repose sur les namespaces et cgroups du noyau Linux, efficace mais pas infaillible

WebAssembly côté serveur attaque ces trois points de front :

• Démarrage en microsecondes : un module WASM peut booter en moins d'1 ms, contre 300-500 ms pour un container classique
• Poids plume : quelques centaines de Ko à quelques Mo, contre des dizaines voire centaines de Mo pour une image Docker
• Sandbox par design : le module n'a accès à rien par défaut (pas de filesystem, pas de réseau, pas de syscalls) sauf ce qu'on lui autorise explicitement via WASI

Bref, sur le papier, c'est exactement ce qu'on attend pour du edge computing, du serverless ou des architectures multi-tenant où chaque milliseconde et chaque Mo comptent.

WASI, le chaînon manquant

Le vrai game changer, c'est WASI (WebAssembly System Interface). C'est une sorte de POSIX allégé et sécurisé qui permet à un module WASM d'accéder au système de fichiers, au réseau ou à l'horloge, mais uniquement via des permissions explicites données par l'hôte. Concrètement, ton module ne peut pas aller fouiller partout sur le serveur comme il veut : tu lui donnes accès à un dossier précis, un socket précis, point final.

C'est un modèle de sécurité par capacités (capability-based security), bien plus strict que ce qu'on a l'habitude de voir avec des containers classiques qui, par défaut, ont souvent trop de permissions si on ne durcit pas la config.

Un exemple concret avec Rust

Pour illustrer, voici comment on compile un petit programme Rust en module WASM compatible WASI, puis comment on l'exécute avec Wasmtime.

// main.rs
fn main() {
    println!("Hello depuis WebAssembly côté serveur !");
}

# Compilation vers WASM avec la cible WASI
rustup target add wasm32-wasi
cargo build --release --target wasm32-wasi

# Exécution avec Wasmtime
wasmtime target/wasm32-wasi/release/mon_appli.wasm

Et voilà, ton binaire tourne dans une sandbox, portable sur n'importe quelle machine qui a un runtime WASM installé, que ce soit du x86, de l'ARM, du edge server chez un CDN ou un Raspberry Pi. Pas besoin de recompiler par architecture, pas besoin d'un daemon Docker qui tourne en fond.

Les cas d'usage qui ont vraiment du sens aujourd'hui

Attention, on ne va pas te vendre du rêve : WASM côté serveur n'est pas encore prêt à remplacer Kubernetes pour héberger ta stack e-commerce complète avec base de données et microservices. Par contre, il brille clairement sur certains terrains :

• Edge computing : Fastly, Cloudflare Workers et Fermyon misent à fond dessus pour exécuter du code au plus près de l'utilisateur avec un cold start quasi nul
• Plugins et extensions sécurisées : besoin de faire tourner du code tiers non fiable dans ton infra ? WASM avec sa sandbox stricte est taillé pour ça (Shopify l'utilise pour ses apps)
• Fonctions serverless ultra réactives : là où AWS Lambda peut souffrir de cold starts, WASM propose des temps de réponse quasi instantanés
• Microservices légers et portables : des projets comme SpinKube (basé sur Spin de Fermyon) permettent même de faire tourner du WASM directement dans Kubernetes, en complément des containers classiques

Les limites qu'il faut avoir en tête

Avant de tout migrer en panique, quelques points de vigilance :

• L'écosystème est encore jeune : moins d'outillage, moins de retours d'expérience en prod à grande échelle comparé à Docker
• Le support des langages varie : Rust et C/C++ sont matures, Go et Python progressent mais avec des compromis, notamment sur la taille des binaires ou le support de certaines libs
• Les workloads gourmands en I/O ou nécessitant des syscalls complexes (bases de données, systèmes de fichiers avancés) restent plus à l'aise dans un container traditionnel pour l'instant
• Le multithreading et le GC pour certains langages sont encore en cours de stabilisation dans les specs WASM

Bref, on est clairement dans une phase où WASM côté serveur complète Docker plutôt qu'il ne le remplace. D'ailleurs Docker lui-même a annoncé son support de WASM comme type de runtime alternatif dans son moteur, ce qui montre bien que la tendance est à la coexistence plutôt qu'à la guerre frontale.

Ce qu'on en pense chez YouOnline

Pour nos clients avec des besoins de perf edge, de plugins tiers sécurisés ou de fonctions serverless ultra réactives, on garde clairement un œil sur cette techno. On ne recommande pas encore de tout balancer en prod avec du WASM pur, mais l'intégrer progressivement sur des briques spécifiques (edge functions, sandboxing de scripts clients, micro-fonctions à latence critique) commence à faire vraiment sens en 2024-2025.

Le message à retenir : l'infra cloud de demain ne sera probablement pas « tout Docker » ou « tout WASM », mais un savant mélange des deux, chacun utilisé là où il excelle vraiment. Et ça, c'est plutôt une bonne nouvelle pour tout le monde.