Outils / Actualités / WASI 0.3 apporte l'async natif à WebAssembly
Presse

WASI 0.3 apporte l'async natif à WebAssembly

· VaultTools

La Bytecode Alliance a publié WASI 0.3 en février 2026, apportant l'async/await natif à WebAssembly via le Component Model. La mise à jour rend Wasm viable pour des charges de travail concurrentes complexes sans serveur, renforçant la justification du traitement de fichiers dans le navigateur comme architecture de production.

VaultTools · 20 mars 2026

Des lignes de code sur un écran sombre, symbolisant WebAssembly et l'informatique native au navigateur moderne. Photo de Markus Spiske sur Unsplash

Table des matières


Ce Que WASI 0.3 Apporte

En février 2026, la Bytecode Alliance a publié une préversion de WASI 0.3, disponible en premier dans Wasmtime 37. WASI, le WebAssembly System Interface, définit comment les modules Wasm interagissent avec le monde extérieur : fichiers, horloges, réseau et appels système. La version 0.3 comble la lacune la plus significative qui persistait après WASI 0.2 : l’absence d’exécution asynchrone native.

Avant la version 0.3, les développeurs qui avaient besoin d’un comportement asynchrone à l’intérieur d’un module WebAssembly devaient construire des contournements manuels, en répartissant les machines à états dans des callbacks ou en utilisant des boucles de sondage qui bloquaient les autres exécutions. WASI 0.3 introduit des types stream<T> et future<T> directement au niveau ABI du Component Model, offrant aux modules Wasm des primitives async de première classe qui se composent proprement avec les environnements hôtes.

Pourquoi L’async Est Important Pour Le Traitement Local De Fichiers

La signification pratique pour les outils de traitement de fichiers est directe. Des opérations comme la lecture d’un grand PDF, le traitement parallèle de plusieurs images ou une passe de compression sur un lot de fichiers sont des tâches intrinsèquement concurrentes. Sans async natif, un module Wasm traitant un grand fichier bloque le fil d’exécution principal du navigateur, gelant l’interface jusqu’à la fin de l’opération.

Le modèle async de WASI 0.3 permet à ces opérations de céder le contrôle entre les étapes, maintenant l’interface réactive et permettant un retour de progression pendant les tâches longues. Il facilite également le traitement simultané de plusieurs fichiers dans un seul module Wasm, correspondant à ce que les utilisateurs attendent des applications natives.

Cela importe spécifiquement pour les outils basés sur le navigateur parce que l’alternative, envoyer des fichiers à un serveur pour le traitement, s’est toujours justifiée en partie par le fait que les serveurs gèrent la concurrence plus facilement. WASI 0.3 supprime cet avantage sans que les données n’aient besoin de quitter l’appareil.

Le Component Model Et L’interopérabilité Entre Langages

WASI 0.3 s’appuie sur le WebAssembly Component Model, qui standardise la façon dont les modules Wasm écrits dans différents langages se composent entre eux. Un module Rust et un module Python peuvent partager des types de données et appeler les fonctions de l’autre via une définition d’interface commune, sans le travail d’interface de fonction étrangère manuel que cela nécessitait auparavant.

Pour le traitement de fichiers, cela signifie que des bibliothèques spécialisées peuvent être écrites dans le langage qui dispose du meilleur écosystème pour la tâche, compilées en Wasm et composées en un seul outil sans surcharge d’exécution ni coûts de sérialisation entre frontières. Les propriétés de sandboxing de Wasm s’appliquent à chaque composant de la chaîne : un module traitant un PDF ne peut pas lire la mémoire arbitraire, ne peut pas effectuer d’appels réseau sauf autorisation explicite, et ne peut pas accéder à des fichiers en dehors de ce que l’hôte lui fournit explicitement.

Le modèle de sécurité est imposé par le runtime Wasm, pas par des politiques ou des configurations. Un composant de bibliothèque malveillant ou compromis ne peut pas exfiltrer un fichier qu’il est en train de traiter. C’est une garantie structurelle que le traitement en nuage ne peut pas offrir.

La Route Vers WASI 1.0

La Bytecode Alliance a fixé WASI 1.0, une version stable en production avec des engagements de support à long terme, comme prochain jalon majeur, visant fin 2026 ou début 2027. WASI 1.0 devrait stabiliser les interfaces du Component Model et formaliser les primitives async introduites dans la version 0.3, offrant aux développeurs d’outils une fondation sur laquelle construire sans devoir suivre une spécification en mouvement.

The New Stack a rapporté début 2026 que WebAssembly est sur une trajectoire où il tournera dans des environnements de production si largement que la plupart des utilisateurs le rencontreront sans le savoir. Le navigateur est la cible de déploiement la plus visible, mais WASI permet également aux mêmes modules Wasm de tourner sur des serveurs, des nœuds de périphérie et des applications de bureau, rendant l’investissement dans le traitement de fichiers basé sur Wasm réutilisable dans différents contextes.

Pourquoi Cela Compte Au-delà Des Développeurs

Le modèle de sandboxing de WebAssembly est le fondement technique d’une affirmation précise en matière de confidentialité : les fichiers traités par un outil Wasm restent sur votre appareil non pas parce que l’opérateur de l’outil a accepté de ne pas les collecter, mais parce que l’architecture rend la collecte structurellement impossible. Le module ne reçoit que les données qui lui sont explicitement transmises. Il ne peut pas initier de connexions réseau. Il ne peut pas lire le système de fichiers en dehors du périmètre accordé par l’hôte.

WASI 0.3 rend cette architecture plus capable et plus pratique pour la classe de charges de travail que les outils de fichiers requièrent. Chaque amélioration de l’écosystème Wasm renforce l’argument selon lequel le traitement local dans le navigateur n’est pas un compromis par rapport aux alternatives cloud, mais une architecture supérieure pour le travail sensible à la confidentialité.


Sources