Le Component Model de WebAssembly devient le standard de plugins que personne n'a choisi

Pendant dix ans, WebAssembly a été la technologie toujours « à un an » de compter réellement en dehors du navigateur. Cette année est arrivée. Selon l'enquête annuelle 2026 de la CNCF, 38 % des organisations cloud-native exécutent désormais des charges de travail WebAssembly en production, contre seulement 4 % en 2022. La raison n'est pas une application phare unique. C'est que le WebAssembly Component Model a discrètement résolu un problème que les conteneurs, les plugins sous forme de bibliothèques partagées et toutes les approches de sandboxing précédentes n'avaient jamais totalement résolu : exécuter en toute sécurité du code non fiable et multilangage, sans les pièges de la mémoire partagée et sans la surcharge propre aux conteneurs.

Ce que le Component Model corrige réellement

Les modules WebAssembly classiques pouvaient déjà exécuter du code écrit dans n'importe quel langage compilant vers WASM, isolé de l'hôte. Mais faire transiter des données complexes entre modules — chaînes de caractères, structs, variants — exigeait une gestion manuelle de la mémoire à travers la frontière de la mémoire linéaire de WASM, aussi source d'erreurs que cela puisse paraître. Le Component Model remplace cela par un Canonical ABI : une manière standard de décrire et de faire passer des types riches à travers les frontières des composants, sans qu'aucune des deux parties n'ait besoin de connaître le langage d'implémentation de l'autre.

En pratique, cela signifie qu'une application hôte en C# peut exécuter un plugin écrit en Rust, qui appelle un composant écrit en Python, qui transmet des données à un composant écrit en Go — chaque étape étant vérifiée par typage et isolée en mémoire, sans qu'aucun des langages n'ait besoin de partager un runtime ni même de savoir dans quel langage les autres sont écrits. WIT (le WebAssembly Interface Type language) est le schéma qui rend cela possible : on définit une interface une seule fois, et tout composant qui l'implémente devient interchangeable, quel que soit son langage source.

Qui utilise réellement cela en production

Ce n'est pas une curiosité de laboratoire. American Express a construit une plateforme interne de function-as-a-service sur wasmCloud, en utilisant des composants WASM maintenus par la communauté pour prendre en charge des fonctions indépendantes de la topologie à travers son infrastructure. Akamai a racheté Fermyon (l'entreprise derrière le framework WASM Spin) et a déployé Spin sur l'ensemble de son réseau edge — ce qui signifie que des composants WASM, et non des conteneurs, assurent désormais du calcul edge en production chez l'un des plus grands opérateurs de CDN d'internet. SpinKube, la manière native Kubernetes d'exécuter des charges de travail WASM, a rejoint le CNCF Sandbox cette année, formalisant la voie d'entrée pour les équipes déjà sous Kubernetes qui veulent ajouter WASM sans pile d'infrastructure parallèle.

wasmCloud a lui-même atteint le statut d'incubateur CNCF et a livré la version 2.5 avec le support de WASI Preview 3 activé par défaut — une étape importante car Preview 3 introduit les types natifs Future et Stream directement dans la spécification WIT, permettant pour la première fois des E/S asynchrones et non bloquantes à travers les frontières des composants. Auparavant, le code asynchrone traversant une frontière de composant exigeait des motifs de callback peu élégants ; c'est désormais un élément de première classe de la définition d'interface.

Pourquoi les systèmes de plugins sont précisément le cas d'usage gagnant

Extism, un framework conçu spécifiquement pour les systèmes de plugins, illustre pourquoi ce modèle se répand plus vite dans les scénarios d'extensibilité que dans les microservices généraux. Si vous construisez un produit qui doit exécuter du code tiers non fiable — un écosystème de plugins pour un CMS, un pipeline de données avec des étapes de transformation personnalisées, la couche de scripting d'un moteur de jeu — vous avez besoin de trois choses simultanément : du sandboxing pour qu'un plugin défaillant ne puisse pas planter ni compromettre l'hôte, de la flexibilité de langage pour que les auteurs de plugins ne soient pas enfermés dans votre langage hôte, et une performance quasi native pour que le sandbox ne pénalise pas chaque appel. Les conteneurs offrent du sandboxing, mais avec une surcharge au niveau processus mal adaptée aux appels de plugins à grain fin. Les langages de script embarqués (Lua, JavaScript-in-a-box) offrent de la performance, mais enferment les auteurs de plugins dans un seul langage. Les composants WASM sont la première approche à réellement offrir les trois à la fois.

Les réserves honnêtes

Le WASM côté serveur est prêt pour la production pour une classe spécifique de charges de travail — fonctions edge, FaaS et systèmes de plugins — mais ce n'est pas encore un remplacement généraliste des microservices. Les avantages en matière de cold-start par rapport aux conteneurs sont réels, mais plus modestes que ce que le marketing initial laissait entendre, une fois pris en compte le coût d'instanciation des composants à grande échelle. Et l'outillage, bien que nettement meilleur qu'il y a deux ans, présente encore des aspérités : déboguer une chaîne de composants multilangage est plus difficile que déboguer un service monolangage, et les outils d'observabilité conçus pour les charges de travail en conteneurs ne se transposent pas toujours proprement.

Ce qu'il faut vraiment en faire

Si vous construisez un système de plugins ou d'extensions en 2026 et que vous continuez par défaut à recourir à des langages de script embarqués ou à des architectures « un conteneur par plugin », il vaut la peine de prototyper d'abord avec le Component Model — commencez par Extism si vous voulez le chemin le plus rapide vers un hôte de plugins fonctionnel, ou par wasmCloud/Spin si vous êtes déjà dans un contexte Kubernetes ou edge computing. Si vous ne construisez pas de systèmes de plugins, le signal le plus pertinent est le support asynchrone de WASI Preview 3 : c'est l'élément qui débloque WASM pour les charges de travail intensives en E/S qui s'y prêtaient mal auparavant, et il vaut la peine de reconsidérer WASM comme option pour du edge computing que vous aviez précédemment écarté pour des raisons de performance.