WebAssembly devient discrètement le runtime par défaut du edge computing

Cloudflare et Fastly se disputent les mêmes clients, exploitent des plateformes incompatibles entre elles et s'accordent rarement publiquement sur quoi que ce soit. Pourtant, les deux sont arrivés à la même conclusion pour leurs produits de calcul en périphérie (edge) : WebAssembly, et non les conteneurs, est le runtime qui rend réellement possible une exécution distribuée mondialement et à faible latence. Cette convergence n'est ni une coïncidence ni un effet de mode : c'est un problème de physique que les conteneurs ne peuvent pas résoudre à l'échelle à laquelle opèrent les réseaux edge.

Le problème du démarrage à froid que les conteneurs n'ont jamais résolu

Un conteneur a besoin d'un noyau de système d'exploitation, d'une couche de système de fichiers et d'une décision de l'ordonnanceur avant que votre code n'exécute la moindre instruction. Même les runtimes de conteneurs optimisés affichent des temps de démarrage de plusieurs dizaines de millisecondes. C'est acceptable pour un datacenter qui reçoit un trafic stable vers une poignée de régions. Ce ne l'est pas pour un réseau edge qui veut démarrer votre fonction à froid, dans n'importe lequel de ses plus de 330 points de présence — celui le plus proche de la requête — à chaque invocation, car maintenir des conteneurs actifs sur chaque site edge pour chaque client n'est pas viable économiquement.

WebAssembly contourne entièrement le problème. Un module Wasm est un format de bytecode compact et isolé (sandboxé) qui ne dépend d'aucun noyau : il démarre dans le même processus que l'hôte du runtime. Fastly Compute, construit sur Wasmtime, instancie les modules en quelques microsecondes plutôt qu'en millisecondes. Cloudflare Workers exécute Wasm au sein de la même architecture d'isolats V8 déjà utilisée pour JavaScript, de sorte qu'un module Wasm et une fonction JS bénéficient de la même garantie de démarrage rapide. C'est un facteur 1 000 sur la classe de latence de démarrage, et en périphérie, la latence de démarrage n'est pas une optimisation : c'est toute la proposition de valeur.

Le Component Model a rendu le code edge polyglotte réellement praticable

Jusqu'à récemment, la plus grande faiblesse pratique de Wasm était l'interopérabilité. Un module Wasm compilé en Rust et un module compilé en Go ne pouvaient pas facilement s'appeler mutuellement ni partager des types de données complexes : on était contraint de tout sérialiser manuellement à travers une frontière de tableau d'octets, ce qui annulait une bonne partie de l'attrait pour les équipes ayant des bases de code multilingues.

Le WebAssembly Component Model résout ce problème directement. Il définit un système de types d'interface standard (WIT) qui permet à des modules compilés depuis différents langages source d'exposer des interfaces typées les uns aux autres, composables comme l'étaient autrefois les bibliothèques partagées avant que les images de conteneurs ne rendent ce type de composition malaisé. Les propres données de l'enquête développeurs de Cloudflare montrent concrètement cette évolution : les composants WASM représentaient 12 % des déploiements Workers en 2023, un chiffre passé à 34 % lors du dernier relevé. Ce n'est pas du bruit d'adopteurs précoces — c'est un runtime en train de devenir une infrastructure par défaut.

Ce qui se compile réellement vers Wasm aujourd'hui

Rust reste la cible la plus mature — l'absence de ramasse-miettes et la petite taille des binaires produits en font une correspondance quasi idéale avec les contraintes de l'edge. Go dispose d'un support utilisable mais plus lourd via TinyGo. C et C++ compilent via Emscripten, avec des décennies de code existant capable de cibler Wasm moyennant des modifications modestes. Python et JavaScript s'exécutent via des interpréteurs compilés en Wasm, ce qui fonctionne mais sacrifie une partie de l'avantage de démarrage à froid puisque l'on embarque un interpréteur en plus de son code. Si votre logique edge est réellement sensible à la performance — routage des requêtes, vérifications d'authentification, réécriture d'en-têtes, transformations d'images — Rust vers Wasm est actuellement la combinaison la plus solide entre maturité de l'écosystème et caractéristiques du runtime.

Là où cela reste insuffisant

Le modèle de sandboxing de Wasm implique que l'accès direct au système de fichiers et aux sockets bruts passe par WASI (la WebAssembly System Interface), encore en cours de stabilisation — attendez-vous à des changements de surface d'API à mesure que les fonctionnalités de WASI Preview 2 gagnent en maturité et en adoption. Le débogage reste en retrait par rapport aux conteneurs : les traces de pile et les outils de profilage pour Wasm exécuté au sein d'un hôte edge s'améliorent, mais ne sont pas encore aussi matures qu'une décennie d'outillage pour conteneurs. Et pour les charges de travail nécessitant un état persistant sur la durée, un accès GPU intensif ou une intégration système profonde, Wasm en périphérie n'est pas le bon outil — ce travail reste du ressort d'un conteneur traditionnel ou d'une VM plus proche de vos données.

Que faire concrètement

Si vous construisez quoi que ce soit s'exécutant au moment de la requête sur Cloudflare Workers, Fastly Compute ou Vercel Edge Functions, considérez Wasm comme la cible par défaut, pas comme une expérimentation. Pour les nouveaux services natifs edge, prototypez en Rust avant de vous tourner vers une approche exclusivement JS/TS si la latence compte — l'écart de temps de démarrage s'accumule sur des millions d'invocations. Si votre équipe déploie déjà plusieurs langages, commencez dès maintenant à suivre l'outillage WIT du Component Model ; c'est l'élément qui vous permettra de cesser d'écrire une glue de sérialisation manuelle et fragile entre modules edge. Et si votre charge de travail a réellement besoin de connexions persistantes, d'un état en mémoire volumineux ou de calcul GPU, ne la forcez pas dans Wasm simplement parce que c'est à la mode — c'est exactement le type de charge de travail que le modèle de runtime edge n'a jamais eu vocation à résoudre.