WebAssembly est-il viable en dehors du navigateur ?

Oscar Spencer

En bref, oui.

WebAssembly (Wasm) s’est imposé comme une technologie incontournable qui a révolutionné le développement web. Des premières démonstrations techniques, comme le célèbre jeu Doom s’exécutant entièrement dans le navigateur, aux grandes applications historiques comme Photoshop, qui offrent une expérience complète digne d’un logiciel de bureau sur une simple page web, WebAssembly permet de vivre des expériences totalement inédites dans un programme familier déjà installé sur tous les ordinateurs personnels du monde.

Wasm a été conçu pour être pris en charge par presque tous les langages de programmation, quel que soit le type de processeur de l’ordinateur de l’utilisateur. Il possède également plusieurs propriétés de sécurité avantageuses que le navigateur exploite pour empêcher tout accès non autorisé aux données ou aux ressources système de l’utilisateur. Ces propriétés se révèlent extrêmement utiles en dehors du navigateur, notamment lorsqu’il s’agit d’exécuter du code de manière isolée ou hautement portable.

L’histoire de POSIX sous Unix

Par défaut, WebAssembly n’a accès à aucune ressource du système sur lequel il s’exécute. Il ne fait que manipuler des zéros et des uns, ce qui explique pourquoi Wasm a jusqu’ici été principalement utilisé pour des tâches nécessitant une grande puissance de calcul, comme le décodage de vidéos ou la manipulation d’images, plutôt que pour le développement d’applications complètes. Il est relativement facile de permettre à votre environnement isolé WebAssembly d’accéder à des fonctionnalités externes, telles que l’heure actuelle ou des données stockées dans un fichier, mais les API utilisées varient généralement d’une application à l’autre.

Les systèmes Unix ont connu une situation similaire à celle que rencontre WebAssembly en dehors du navigateur. De nombreuses applications souhaitaient accéder à des ressources système courantes, telles que le réseau et les systèmes de fichiers, mais chaque système d’exploitation procédait de manière légèrement différente. C’est pourquoi POSIX a vu le jour en tant qu’interface standard et portable pour les systèmes d’exploitation : tous les systèmes de type Unix pouvaient l’adopter afin d’uniformiser la manière dont les programmes communiquaient avec le système d’exploitation. Cela permettait également de porter facilement sur un autre système de type Unix les programmes conçus pour fonctionner sur l’un d’entre eux.

Découvrez WASI, l’interface système de WebAssembly

WASI, la WebAssembly System Interface, a vu le jour afin d’offrir aux programmes WebAssembly un moyen standard de communiquer avec un système d’exploitation. WASI s’est largement inspirée d’un projet appelé CloudABI, lui-même inspiré de POSIX. Cette avancée a ouvert tout un monde de possibilités permettant à WebAssembly de briller en dehors du navigateur : les utilisateurs bénéficiaient désormais de toutes les propriétés de sécurité et d’isolation de WebAssembly, associées à des API soigneusement conçues pour accéder aux ressources système courantes sans renoncer totalement à l’isolation. Une technologie similaire vient naturellement à l’esprit : les conteneurs. Toute discussion sur ce sujet se doit de mentionner l’une des publications les plus marquantes et les plus partagées au sujet de WASI, signée Solomon Hykes, cofondateur de Docker :

Voilà une affirmation pour le moins audacieuse. WebAssembly offre un moyen portable de conditionner du code pouvant être exécuté de manière sûre et sécurisée sur n’importe quelle plateforme, à des vitesses proches de celles du code natif, avec un avantage supplémentaire par rapport aux conteneurs : aucun système d’exploitation n’est nécessaire. La plupart des conteneurs créés par les développeurs intègrent une forme de système d’exploitation Linux dans lequel s’exécutent les programmes, ce qui se traduit souvent par des tailles de plusieurs centaines de mégaoctets, voire de plusieurs gigaoctets. Les binaires WebAssembly ne contiennent que du code et leur taille se limite souvent à quelques kilooctets ou à moins de dix mégaoctets. Il peut sembler insensé d’imaginer un monde où, au lieu de déployer des conteneurs partout, les développeurs déploieraient WebAssembly, mais cette réalité est déjà en train de prendre forme, avec plusieurs projets activement développés pour exécuter Wasm sur Kubernetes.

WebAssembly côté serveur en production

Plusieurs entreprises tirent déjà parti de Wasm côté serveur en production. Cloudflare et Fastly disposent toutes deux d’immenses réseaux de calcul en périphérie qui permettent à leurs clients de déployer du code partout dans le monde, au plus près des utilisateurs. Toutes deux ont fait le choix stratégique de WebAssembly afin de bénéficier de petits fichiers binaires ultraportables, de temps de démarrage rapides et d’une gestion robuste de plusieurs locataires. Cosmonic, une jeune entreprise, s’appuie sur une mise en réseau ingénieuse pour permettre aux composants WebAssembly de communiquer entre eux de manière fluide, quel que soit l’endroit où ils s’exécutent, qu’il s’agisse d’un minuscule appareil tenant dans la paume de la main ou d’une machine située à l’autre bout du monde. Une autre jeune entreprise, Fermyon, utilise WebAssembly pour augmenter considérablement la densité des charges de travail sur les serveurs. Il en résulte une réduction drastique des coûts liés aux serveurs et une informatique plus respectueuse de l’environnement.

Croissance en dehors du navigateur

En résumé, bien que WebAssembly ait été initialement développé pour l’exécution de code dans le navigateur, il continue de démontrer tout son potentiel en dehors de celui-ci. Sa conception, qui prend en charge différents langages de programmation et met l’accent sur la sécurité, en fait un excellent choix pour exécuter du code de manière isolée tout en assurant sa portabilité. L’introduction de WASI a permis à WebAssembly de prospérer côté serveur, donnant ainsi aux organisations la possibilité de tirer parti de Wasm pour proposer de meilleurs produits à un coût nettement inférieur. Le potentiel de WebAssembly en dehors du navigateur n’est pas qu’une simple idée : il devient une réalité de plus en plus tangible pour le secteur.

Pour en savoir plus, consultez notre précédent article de blog, « Pourquoi WebAssembly devrait vous intéresser ».

Vous pouvez également regarder ou écouter notre podcast « WebAssembly Unleashed ».

À propos de l’auteur

Oscar Spencer

Autres articles de Oscar Spencer