Sans installation, sans risque : l’essor du tunneling natif WebAssembly

La fatigue binaire du milieu des années 2020

Depuis plus d’une décennie, le rituel du “premier jour” du développeur impliquait une danse prévisible et maladroite : télécharger un .zip, extraire un binaire, le déplacer vers /usr/local/bin, et espérer que la politique de sécurité de votre entreprise ne signale pas l’exécutable non vérifié comme une menace. Que ce soit ngrok, cloudflared ou localtunnel, le paradigme était le même — un daemon local devait fonctionner sur votre machine pour ouvrir un trou dans le NAT et relier localhost au monde.

Au milieu des années 2020, cette friction est devenue intenable. Avec la hausse des primes d’assurance cybersécurité et le resserrement des contrôles par les départements IT, la question pour beaucoup d’organisations d’ingénierie est passée de “comment tunnelliser ?” à “pouvons-nous tunnelliser sans rien installer du tout ?”

Entrez dans l’ère des tunnels natifs WebAssembly, en navigateur — non pas un tableau de bord web ajouté à un outil local, mais le tunnel lui-même né, compilé et exécuté à l’intérieur de l’onglet du navigateur.

---

La pile technologique : ce que WASI est (et n’est pas) en 2026

L’article original décrivait une “stabilisation de WASI 0.3 en février 2026” comme le déclencheur de tout cela. La réalité est plus nuancée — et sans doute plus intéressante.

La feuille de route de WASI, précisément

L’Interface Système WebAssembly (WASI) est une spécification en cours de standardisation maintenue par la Bytecode Alliance, en progression via le W3C. Voici où en sont réellement les choses :

• WASI 0.2 (stable, publié en janvier 2024) — C’est la version stable actuelle. Elle a introduit le modèle de composants, wasi-sockets (TCP/UDP), wasi-http, wasi-io et wasi-clocks. C’est cette version qui tourne en production aujourd’hui.
• WASI 0.3 (en développement actif début 2026) — La grande nouveauté est l’I/O asynchrone native via le modèle de composants. Comme l’a noté Matt Butcher de Fermyon, la mise en œuvre complète de WASIp3 dans Wasmtime était prévue pour mi-2025, avec la standardisation W3C à suivre. WASI 1.0 — la version entièrement ratifiée — est prévue pour 2026.
• L’écosystème Go a récemment proposé formellement d’ajouter le support GOOS=wasip3, en soulignant que “le support de la concurrence P3 en fait la première étape WASI à supporter l’utilisation idiomatique des goroutines.”

Donc, la capacité à construire des outils de réseautage sophistiqués en Wasm est réelle et en cours de déploiement — simplement pas via une annonce dramatique en février 2026. C’est le fruit d’années de standardisation progressive et minutieuse.

wasi-sockets : La vraie avancée en réseautage

La proposition wasi-sockets, qui fait maintenant partie de WASI 0.2, est ce qui rend le réseautage en navigateur significatif. La spécification n’est pas une simple adaptation POSIX 1:1. Au contraire :

• Les modules Wasm ne peuvent pas ouvrir de sockets sans une poignée de capacité réseau fournie par l’hôte.
• Les implémentations WASI doivent refuser tout accès réseau par défaut — l’accès doit être accordé au niveau le plus granulaire possible.
• Les API de sockets sont divisées en modules spécifiques aux protocoles (TCP, UDP, recherche DNS), chacun pouvant évoluer indépendamment via la standardisation.

Ce n’est pas qu’une décision technique ; c’est la base d’une posture de sécurité réellement différente comparée à un binaire natif.

---

WebTransport : promesse et réalité actuelle

L’article initial décrivait WebTransport comme le remplacement établi des WebSockets dans les outils de tunneling. La réalité en 2026 est que WebTransport est une norme réelle, en progression — mais pas encore déployée universellement.

Ce qu’est WebTransport : une spécification W3C/IETF (actuellement Internet-Draft en version 15) qui offre une communication bidirectionnelle, à faible latence, client-serveur, via HTTP/3 et QUIC. Elle supporte plusieurs flux, des flux unidirectionnels, la livraison hors-ordre, et des transports à la fois fiables (basés sur les flux) et non fiables (basés sur datagrammes).

Pourquoi c’est important pour le tunneling :
Les WebSockets traditionnels sur TCP souffrent de blocage en tête de ligne — si un seul paquet est perdu, tous les flux de la connexion sont bloqués. QUIC, le transport sous-jacent à WebTransport, élimine cela : seul le flux affecté par la perte de paquet est retardé, pas toute la connexion. Pour le proxy de serveur de développement multiplexé, c’est une amélioration significative.

Où en sont les choses :
Début 2026, la spécification WebTransport de l’IETF est encore un Internet-Draft — pas un RFC finalisé. Les connexions WebSocket sur HTTP/3 (RFC 9220) manquent aussi de support dans les navigateurs en production début 2026. WebTransport a des implémentations fonctionnelles dans Chrome (depuis la v97) et est supporté dans Firefox, mais l’écosystème des bibliothèques serveur et la spécification IETF sont encore en maturation. QUIC et HTTP/3 sont cependant solidement établis — avec plus de 40% du trafic web mondial passant par QUIC/HTTP/3, porté par Google, Cloudflare et les grands CDN.

Le résultat pratique pour les développeurs : les outils de tunneling en navigateur utilisent aujourd’hui plus probablement WebSockets sur HTTP/2 ou HTTP/3 avec WebTransport en option rapide là où supporté, plutôt qu’en standard universel.

---

Pourquoi les développeurs reconsidèrent le binaire local

Le modèle de sécurité “Virtual Cage”

C’est ici que le battage autour de Wasm s’aligne avec la réalité d’ingénierie peer-reviewed.

Contrairement à un binaire natif ou même un conteneur Docker (qui utilise les namespaces du kernel), WebAssembly utilise l’Isolation par Fault (SFI). Le modèle de sécurité de Wasm, tel que documenté par le W3C, garantit :

• Chaque module Wasm s’exécute dans un environnement sandboxé ** séparé du runtime hôte** via des techniques d’isolation par fault.
• La mémoire du module est une seule zone de mémoire linéaire contiguë, initialisée à zéro par défaut et contrôlée par limites à chaque accès.
• Les modules ne peuvent pas sortir du sandbox sans passer par des API explicitement accordées.
• Toutes les fonctions accessibles et leurs types doivent être déclarés au chargement, même avec le lien dynamique.

Firefox de Mozilla utilise cette approche SFI — via un cadre appelé RLBox — pour sandboxer des bibliothèques tierces comme les parsers de polices et XML, réduisant considérablement l’impact des vulnérabilités dans ces composants. Le moteur V8 de Google implémente son propre mécanisme de sandbox heap, protégeant des milliards d’utilisateurs dans tous les navigateurs Chromium, Node.js et Electron.

Pour un binaire de tunneling local fonctionnant avec les permissions de l’utilisateur, une compromission donne à un attaquant un accès direct à votre système de fichiers, clés SSH, et secrets dans ~/.config. Pour un module Wasm, il n’a accès qu’à la mémoire que vous lui avez explicitement accordée. La portée de dégâts est donc structurellement plus limitée.

L’avertissement important : Aucun sandbox n’est absolu. Les bugs JIT-compiler (dans Cranelift, LLVM ou V8) représentent la principale voie d’évasion réaliste. Un article ACM CCS 2025 a identifié 19 bugs de sécurité dans le sandbox heap de V8 via injection contrôlée. Les propriétés de sécurité de Wasm sont réelles et précieuses — mais nécessitent de maintenir les runtimes à jour et de considérer la sécurité de Wasm comme une défense en profondeur, pas une solution miracle.

Le modèle de composants : architecture modulaire, minimaliste et permissionnée

WASI 0.2 a introduit le Modèle de Composants WebAssembly, permettant de construire des applications à partir de petits composants Wasm — chacun avec sa propre mémoire linéaire et un ensemble minimal de capacités. Le modèle utilise des définitions WIT (WebAssembly Interface Type) pour décrire les interfaces entre composants.

Pour un outil de tunneling, cela a de l’importance : le composant réseau, le composant d’authentification et le composant UI peuvent être isolés. Une compromission de la couche réseau n’a pas de chemin structurel vers le stockage des identifiants.

Portabilité instantanée sur tous les appareils

Un module Wasm est indépendant de l’architecture par conception. Le même binaire fonctionne sur x86-64 et ARM64, dans Chrome sur Mac, Edge sur Windows ou un navigateur sur Chromebook. Pour les développeurs sur des machines d’entreprise verrouillées ou des appareils empruntés, une URL suffit — pas besoin de privilèges administratifs ni de gestionnaire de paquets.

---

Le paysage comparatif : Binaire vs. natif en navigateur

Fonctionnalité	Binaire local (2020–2024)	Tunnel natif WebAssembly (2025–2026)
Installation	Manuel (.exe, .deb, .zip)	Zéro (basé sur URL)
Modèle de sécurité	Permissions du système d’exploitation utilisateur	Sandbox SFI, basé sur capacités
Accès mémoire	Système de fichiers complet	Capacités explicitement accordées uniquement
Support architecture	Builds spécifiques à la plateforme	Universel (navigateur moderne)
Mises à jour	Manuelles ou auto-mise à jour	Instantané lors du rafraîchissement de la page
Approbation IT	Souvent bloqué / shadow IT	Fonctionne comme du trafic HTTPS standard
Persistance	Daemon en arrière-plan	Éphémère (dans l’onglet)

---

Les limites : où les binaires natifs ont encore l’avantage

La mort du binaire local est une tendance, pas un fait accompli actuel. Il existe des cas où les outils natifs conservent un avantage certain :

• Tunneling de protocoles au niveau kernel ou bas niveau — tout ce qui nécessite des sockets brutes, eBPF ou accès aux modules kernel n’est pas accessible depuis un sandbox navigateur.
• Transferts de masse à haute performance — bien que la performance de Wasm soit proche du natif pour la plupart des charges, le warm-up JIT et la surcharge du sandbox navigateur comptent dans des scénarios de data-centers à 100Gbps+.
• Agents de fond à long terme — Wasm dans un onglet de navigateur se termine quand l’onglet est fermé. Pour des tunnels d’infrastructure persistants, un processus binaire local ou côté serveur reste le choix pragmatique.
• WASI 0.3 et I/O asynchrone — des fonctionnalités comme le support idiomatique des goroutines et de vrais flux asynchrones, qui rendront le Wasm en navigateur beaucoup plus capable, sont encore en standardisation, pas encore largement déployées.

---

Le côté durable : calcul éphémère

Un avantage peu reconnu du modèle basé sur le navigateur est l’efficacité des ressources. Les daemons de tunneling locaux traditionnels tournent en processus persistent, consommant du CPU même en idle.

Les tunnels natifs WebAssembly en navigateur sont éphémères par conception. Quand vous fermez l’onglet, le processus disparaît — pas de mémoire résiduelle, pas de CPU en arrière-plan, pas de processus obsolète à nettoyer après un redémarrage. Pour des organisations d’ingénierie avec des dizaines de stations de travail de développeurs, la réduction globale du calcul en idle est mesurable.

---

Conclusion : une transition réelle, pas une révolution

L’essor des outils natifs WebAssembly — y compris le tunneling — représente un changement réel et significatif dans la façon dont l’infrastructure pour développeurs est construite. La wasi-sockets de WASI 0.2, le Modèle de Composants, et la spécification WebTransport en maturation offrent des bases d’ingénierie authentiques pour des outils de réseautage natifs en navigateur qui auraient été impossibles il y a trois ans.

Ce qu’il n’est pas encore, c’est un remplacement complet des binaires natifs. WASI 0.3 est encore en développement actif. WebTransport est encore un Internet-Draft. Les échappées du sandbox en navigateur sont un vecteur d’attaque réel, même si difficile. La vérité honnête est celle d’une technologie qui franchit le seuil entre “expérimental” et “prêt pour la production dans la majorité des cas d’usage web” — ce qui est déjà une évolution remarquable.

Pour 99% des développeurs web construisant des APIs, testant des webhooks ou partageant des démos locales, le navigateur devient une plateforme de plus en plus viable — et peut-être même supérieure — pour leurs outils quotidiens.

---

Faits clés en un coup d’œil

• WASI 0.2 (stable depuis janvier 2024) inclut wasi-sockets, wasi-http et le Modèle de Composants — la véritable base pour le réseautage en navigateur.
• WASI 0.3 (en développement, prévu pour 2026) ajoute l’I/O asynchrone native et permet des modèles de programmation concurrents idiomatiques comme les goroutines.
• WebTransport est une spécification W3C/IETF (Internet-Draft, pas encore RFC) proposant des flux multiplexés via QUIC — une vraie amélioration sur WebSockets pour les charges sensibles à la latence, avec un support navigateur en croissance mais pas encore universel.
• Le modèle de sécurité de Wasm (SFI, mémoire linéaire, accès basé sur capacités) est examiné par la communauté académique — réel, mais pas inconditionnel. Les bugs JIT restent la principale voie d’évasion.
• QUIC/HTTP/3 transporte aujourd’hui plus de 40% du trafic web mondial, faisant du transport sous-jacent à WebTransport une réalité mainstream même si le protocole applicatif est encore en maturation.