WebAssembly s'est échappé du navigateur. En 2026, il devient discrètement le Runtime pour tout

Lorsque WebAssembly a été lancé en 2017, l'argument était simple : un format d'instructions binaires que les navigateurs web pouvaient exécuter à des vitesses quasi-natives, permettant des applications que JavaScript seul ne pouvait pas gérer. Figma a porté son moteur de rendu vers WASM et a rendu un logiciel de conception complexe viable dans le navigateur. AutoCAD Web l'a utilisé pour exécuter du code C++ vieux de plusieurs décennies sans rien réécrire. Le cas d'usage dans le navigateur était réel, et la technologie a tenu ses promesses.

Ce que personne n'avait vraiment prédit, c'est que les utilisations les plus conséquentes de WebAssembly se produiraient entièrement en dehors du navigateur.

Comment WASM s'est échappé du Sandbox

Le développement clé a été WASI — l'interface système WebAssembly, proposée par Bytecode Alliance en 2019 et atteignant une spécification stable 2.0 en 2024. WASI a donné aux modules WebAssembly une interface standardisée pour interagir avec le système hôte : lire des fichiers, établir des connexions réseau, accéder aux variables d'environnement. Cela semble banal, mais a eu une implication profonde : un module WASM compilé avec le support WASI peut s'exécuter partout où un runtime WASI existe — non seulement dans un navigateur, mais sur un serveur, à la périphérie, sur un appareil IoT, dans un moteur de base de données.

Solomon Hykes, le créateur de Docker, a clairement formulé l'importance dans un post qui a été largement cité : "Si WASM+WASI avait existé en 2008, nous n'aurions pas eu besoin de créer Docker. C'est dire à quel point c'est important." La promesse était un binaire portable universel — compilez une fois, exécutez partout, avec un sandbox de sécurité intégré.

Où WASM tourne en 2026

Edge computing et fonctions serverless. Cloudflare Workers supporte WASM depuis 2018, mais en 2026 c'est le runtime principal pour les fonctions de périphérie critiques en performance. Fastly Compute, Fermyon Spin et Wasmer Edge exécutent tous des charges de travail WASM sur des nœuds de périphérie distribués globalement. L'attrait est une combinaison de temps de démarrage (démarrages à froid sous la milliseconde, contre 50–200 ms pour une fonction Node.js), d'isolation de sécurité (chaque module tourne dans son propre sandbox avec des attributions de capacités explicites) et de portabilité (déployer le même binaire chez n'importe quel fournisseur).

Extensibilité des bases de données. SingleStore, DuckDB et plusieurs autres bases de données supportent désormais des fonctions définies par l'utilisateur écrites comme modules WASM, permettant à une logique personnalisée de s'exécuter dans le moteur de requêtes avec accès aux opérations vectorisées et sans la surcharge d'un aller-retour vers un processus externe. Le support WASM UDF de PostgreSQL, stabilisé en 2025, a ouvert cette capacité à la base de données open source la plus déployée au monde.

Systèmes de plugins. Zed (l'éditeur de code), Extism (un framework de plugins utilisé par des dizaines d'applications) et un nombre croissant d'outils pour développeurs utilisent WASM comme runtime de plugins. L'avantage par rapport aux systèmes de plugins natifs traditionnels est l'isolation : un plugin malveillant ne peut pas planter le processus hôte ni accéder à des ressources en dehors de ses attributions de capacités. C'est le modèle que Shopify utilise pour ses extensions d'applications personnalisées et que Figma utilise pour son écosystème de plugins.

CLI portables et outils. Le modèle de composants WASM (standardisé en 2024) a permis la composition : vous pouvez construire un outil CLI comme un ensemble de composants WASM qui importent et exportent des interfaces typées, puis les composer ensemble quelle que soit la langue dans laquelle ils ont été initialement écrits. Un composant Rust peut appeler l'interface d'un composant Python sans qu'aucun ne connaisse la langue d'implémentation de l'autre. Cela permet une nouvelle génération d'outils indépendants de la langue.

Le modèle de composants change la donne

Le modèle de composants WASM mérite une attention particulière car il résout un problème qui a tourmenté les logiciels polyglottes pendant des décennies. Auparavant, si vous vouliez appeler une bibliothèque écrite en Rust depuis Python, vous deviez gérer les FFI, la mémoire partagée, la surcharge de sérialisation ou les appels de sous-processus. Le modèle de composants remplace tout cela par un langage de définition d'interface sûr et indépendant de la langue (WIT — WebAssembly Interface Types) que les compilateurs pour Rust, Python, JavaScript, Go, C et d'autres peuvent cibler.

Le résultat est qu'un développeur peut écrire une bibliothèque de traitement de chaînes haute performance en Rust, l'exposer comme un composant WASM avec une interface WIT typée, et l'appeler depuis Python sans code passe-partout FFI. Le binaire tourne dans un sandbox, l'interface est vérifiée au niveau des types à la frontière, et le même composant fonctionne partout où le runtime WASM existe.

Ce qui manque encore

La croissance de WASM en dehors du navigateur vient avec des limitations réelles. Le support du ramasse-miettes (Garbage Collection) n'a atteint un statut stable qu'en 2024, ce qui le rendait auparavant difficile pour des langages comme Python et Java qui en dépendent. Les threads et la mémoire partagée fonctionnent mais ont des réserves concernant les opérations atomiques qui diffèrent selon la plateforme. L'histoire des outils s'est considérablement améliorée — wasm-pack, cargo-component et componentize-py existent tous — mais l'expérience est encore en retard par rapport au développement natif en termes de débogage, de profilage et de messages d'erreur.

Les performances sont quasi-natives pour les tâches liées au CPU mais pas pour les charges de travail qui dépendent fortement des services du système d'exploitation : les E/S de fichiers via WASI sont plus lentes que les natives, et les attributions de sécurité du modèle de capacités ajoutent une surcharge par rapport aux appels système directs. Pour les chemins critiques en latence, ces écarts comptent.

La trajectoire

La tendance est claire. Wasmtime (maintenu par Bytecode Alliance) s'incruste dans tout, des fournisseurs de cloud aux outils CLI en passant par les bases de données. Le modèle de composants gagne en adoption plus rapidement que toute spécification WASM précédente. Les fournisseurs de navigateurs sont alignés sur les fonctionnalités futures, notamment le ramasse-miettes, le changement de pile pour les coroutines et les améliorations de la gestion des exceptions.

WebAssembly ne remplacera pas les conteneurs ou les binaires natifs pour toutes les charges de travail. Mais pour les cas d'usage spécifiques où la portabilité, l'isolation de sécurité et les temps de démarrage inférieurs à la milliseconde comptent — fonctions de périphérie, applications extensibles, outils portables, plugins en sandbox — il est déjà devenu le choix par défaut. Les cinq prochaines années de son développement le rendront probablement méconnaissable par rapport au format binaire centré sur le navigateur qu'il était au départ.