WebAssembly a quitté le navigateur. Il opère désormais chez Shopify, Cloudflare et dans votre cluster Kubernetes.

WebAssembly a vu le jour en 2017 pour résoudre un problème bien connu des navigateurs : JavaScript était trop lent pour le code nécessitant des performances élevées, et les plugins natifs trop dangereux. La solution ? Un format binaire compact capable d'exécuter du code quasi natif dans un environnement sandboxé — en toute sécurité, de manière portable et rapide. Le pari a été tenu. Éditeurs vidéo, outils de CAO et simulations scientifiques ont investi le web. Figma a multiplié ses performances par trois en migrant son moteur de rendu vers du C++ compilé en WASM.

Puis, l'inattendu s'est produit. Des ingénieurs ont commencé à se demander si un format binaire rapide, sandboxé et indépendant du langage ne pourrait pas être utile ailleurs que dans un navigateur. La réponse fut oui, et l'écosystème qui a émergé est désormais suffisamment mature pour la production.

Le Component Model : la pièce manquante enfin arrivée

La spécification originelle de WebAssembly comportait une limitation fondamentale pour une utilisation côté serveur : deux modules WASM compilés depuis des langages différents ne pouvaient pas s'appeler mutuellement sans un code de gestion mémoire manuel et sujet aux erreurs. Une bibliothèque Rust et un service Go vivaient dans des espaces mémoire séparés, sans système de types partagé. Les architectures polyglottes composables étaient donc hors de portée.

Le WebAssembly Component Model, stabilisé en 2025, résout ce problème grâce à une interface binaire applicative partagée et un langage de description d'interface indépendant du langage appelé WIT (WebAssembly Interface Types). Un fichier WIT déclare les fonctions et types de données qu'un composant exporte ou importe, sans présupposé mémoire lié au langage. La chaîne d'outils — wit-bindgen, wasm-tools, jco — génère automatiquement le code d'intégration. Résultat pratique : un analyseur Rust haute performance, un pipeline ML Python et un frontend TypeScript peuvent composer en tant que composants WASM sans FFI écrite à la main. WASM 3.0 a été ratifié comme standard W3C en septembre 2025, intégrant le garbage collection, la mémoire 64 bits, le SIMD relaxé et la gestion des exceptions, en plus du Component Model.

WASI : la couche d'interface qui rend la portabilité réelle

Faire tourner WASM en dehors du navigateur nécessite un moyen pour le module d'interagir avec le système hôte — lire des fichiers, ouvrir des sockets réseau, écrire sur la sortie standard. Le WebAssembly System Interface (WASI) définit ces API dans un modèle de sécurité basé sur les capacités : un module ne reçoit que les accès qui lui sont explicitement accordés lors de l'instanciation. Rien d'autre n'est accessible.

WASI 0.2, publié en janvier 2024, a verrouillé la base stable de production — entrées/sorties fichier, sockets réseau et intégration avec le Component Model. WASI 0.3, qui ajoute le support natif de l'asynchrone avec des primitives de flux typés et de futures, était en cours de finalisation début 2026. La version 1.0 — la première version "stable pour toujours" — est prévue pour fin 2026 ou début 2027. Cette trajectoire donne aux auteurs de bibliothèques une ABI stable à cibler et aux opérateurs une feuille de route claire sur ce que les garanties de portabilité couvriront à terme.

Où les déploiements en production existent déjà

Le point de preuve le plus concret à grande échelle est Shopify Functions. Depuis 2022, Shopify permet aux développeurs tiers de personnaliser la logique de paiement, de réduction et d'expédition en déployant des modules WASM qui s'exécutent dans un runtime dédié au sein de l'infrastructure de Shopify. Chaque module doit respecter un budget strict de 5 millisecondes ; les latences mesurées se situent généralement entre 0,8 et 2,5 millisecondes. Les développeurs écrivent en Rust, JavaScript (via le compilateur Javy de Shopify, qui intègre un moteur V8 allégé dans un binaire WASM), Zig ou TinyGo. La frontière de sécurité est cruciale : le code marchand non fiable tourne en production à l'échelle de Shopify sans accès aux ressources du système hôte. Aucune fuite du sandbox n'a été constatée. En juin 2026, l'ancien système Scripts que Functions a remplacé a été complètement retiré.

Côté edge computing, Fastly Compute@Edge est un environnement d'exécution purement WASM qui offre des démarrages à froid de l'ordre de la microseconde pour le traitement des requêtes en périphérie de réseau. Cloudflare Workers prend en charge les modules WASM et a ajouté le support des conteneurs en juin 2025 pour les charges de travail hybrides. Le signal le plus marquant de l'industrie est survenu fin 2025, lorsqu'Akamai a acquis Fermyon — la société derrière le framework Spin pour les microservices WASM serverless — et a rendu Fermyon Wasm Functions généralement disponible sur le réseau edge mondial d'Akamai en novembre 2025. Quand le plus grand CDN de la planète acquiert une société spécialisée dans le WASM serverless, le pari sur l'avenir de la technologie est institutionnel, plus seulement expérimental.

Le paysage des runtimes

Quatre runtimes dominent selon les cas d'usage. Wasmtime, l'implémentation de référence de la Bytecode Alliance, a obtenu le statut de projet principal en avril 2025 et atteint environ 82 % des performances natives sur les benchmarks de calcul. C'est le choix par défaut pour le WASM côté serveur généraliste. Wasmer 6.0, sorti en avril 2025, revendique 95 % des performances natives et a introduit Edge.js, qui exécute des applications Node.js dans un sandbox WASM — un pont intéressant pour les équipes disposant d'une infrastructure Node existante. WAMR (WebAssembly Micro Runtime) cible les systèmes embarqués et IoT, fonctionnant sur du matériel avec seulement 256 kilo-octets de mémoire, avec 80 à 90 % des performances natives grâce à la compilation AOT. WasmEdge est optimisé pour les charges de travail IA et s'intègre à Docker Engine comme shim de conteneur, aux côtés de Wasmtime.

La position de Docker est délibérée : "WASM et conteneurs", pas "WASM contre conteneurs". Docker Engine embarque des shims natifs pour Wasmtime et WasmEdge, de sorte que les modules WASM peuvent être déployés avec les commandes standard docker run depuis un Dockerfile scratch. La chaîne d'outils converge plutôt qu'elle ne rivalise. SpinKube, un projet CNCF basé sur le framework Spin de Fermyon, fait du WASM un type de charge de travail de première classe dans Kubernetes — déployable aux côtés de pods conteneurisés avec les mêmes primitives d'orchestration.

L'argument sécuritaire

Le modèle de sécurité de WASM est "deny by default" au niveau binaire. Un module n'a aucun accès au système hôte, sauf si l'hôte lui accorde explicitement une capacité spécifique au moment de l'instanciation. C'est architecturalement différent des conteneurs, qui partagent le noyau hôte et s'appuient sur l'isolation par namespaces et cgroups pour limiter ce qu'une charge de travail peut atteindre. Dans WASM, le sandbox est appliqué par le runtime, quel que soit le langage de compilation du module.

Pour les plateformes multi-locataires — le modèle Shopify, où des centaines de milliers de marchands déploient du code personnalisé — c'est la fonctionnalité qui rend l'architecture viable. L'alternative consisterait à vérifier chaque morceau de code tiers avant déploiement, ce qui n'est pas envisageable à grande échelle. Le sandbox WASM élimine cette catégorie de risque plutôt que de la gérer.

Le bilan honnête des performances

Le WASM côté serveur tourne à environ 75 à 95 % de la vitesse native sur les charges de calcul intensif — des chiffres crédibles pour la plupart des cas d'usage, avec des bémols. Les opérations impliquant des entiers 128 bits et certaines primitives cryptographiques sont 2 à 7 fois plus lentes que le natif. Les charges liées aux entrées-sorties ne bénéficient d'aucun gain significatif ; l'avantage porte sur le calcul. Les démarrages à froid sont de 1 à 5 millisecondes, contre 50 à 500 millisecondes pour les conteneurs — c'est ce chiffre qui rend le WASM attractif pour le serverless et l'edge, où la latence de démarrage à froid affecte directement l'expérience utilisateur.

Le temps de développement est réellement plus long. Développer en Rust pour WASM nécessite de comprendre la gestion mémoire et un flux de débogage différent de celui auquel la plupart des développeurs web sont habitués. Le Component Model et la chaîne d'outils WASI se sont considérablement améliorés, mais le débogage inter-langages reste plus difficile que le débogage au sein d'une même pile. L'écosystème se situe à peu près là où JavaScript se trouvait au début de Node.js : puissant, productif, mais nécessitant un investissement pour être bien utilisé.

La question "devrais-je utiliser WASM plutôt que des conteneurs ?" trouve une réponse plus claire en 2026 qu'il y a deux ans : utilisez WASM quand la latence de démarrage à froid importe (edge et serverless), quand vous avez besoin d'exécuter du code non fiable dans un sandbox, ou quand vous voulez une composition de composants indépendante du langage. Utilisez des conteneurs quand vous avez besoin d'un environnement Linux complet, d'une large compatibilité de bibliothèques ou d'un accès GPU. Utilisez les deux quand votre charge de travail comporte des couches qui bénéficient de chacun — ce que les outils d'infrastructure sont de plus en plus conçus pour supporter.