Tabserve vs ngrok : Tunnels localhost uniquement dans le navigateur via WASM

Les équipes de développement modernes sont de plus en plus dispersées, mais les équipes de sécurité d’entreprise renforcent la sécurité des réseaux d’entreprise comme jamais. Si vous travaillez dans un environnement IT strict, vous connaissez la difficulté : les agents Endpoint Detection and Response (EDR) bloquent les binaires exécutables non signés, et les configurations de pare-feu interrompent les connexions SSH sortantes. Dans ces environnements zero-trust, les outils de développement traditionnels échouent.

Lorsque vous devez partager une application web locale avec un intervenant distant, tester un webhook d’un service externe, ou déboguer une API depuis un Chromebook d’entreprise verrouillé, télécharger un démon de tunneling n’est tout simplement pas une option. Entrez le “tunnel uniquement dans le navigateur” — et plus précisément, l’outil qui a popularisé ce pattern : Tabserve.

En s’appuyant sur WebSockets et Web Workers du navigateur, cette catégorie d’outil exécute le processus de tunneling nativement dans le sandbox du navigateur. Parce qu’il fonctionne entièrement dans un onglet standard via un port HTTPS standard, il contourne de nombreuses restrictions réseau qui bloquent les outils en CLI. Ce document explique comment fonctionne cette architecture, corrige une idée reçue courante à son sujet, et propose une comparaison honnête et actuelle avec ngrok — y compris un problème en direct avec le domaine de Tabserve qui modifie les conseils pratiques ici.

1. Le dilemme du réseau d’entreprise

Historiquement, exposer un serveur de développement local (http://localhost:3000) nécessitait un reverse proxy : un agent léger sur votre machine qui ouvre un tunnel sortant sécurisé et persistant vers un serveur public. Des outils comme ngrok, Localtonet, ou le démon cloudflared de Cloudflare remplissent cette fonction, mais ils partagent une exigence : l’installation d’un binaire ou l’utilisation d’un CLI. Dans des environnements IT stricts, cela crée une friction :

• L’exécution de binaires est bloquée. Les politiques de liste blanche d’applications empêchent l’exécution d’un exécutable non signé.
• Pas de privilèges administrateur. Installer un service système ou modifier PATH nécessite des droits administrateur que les développeurs sur VDI ou matériel verrouillé n’ont pas.
• Filtrage des protocoles. Les pare-feu d’entreprise filtrent souvent le port 22, et changer SSH vers un port non standard (2222 étant la convention typique, pas une alternative universelle fixe) n’aide pas toujours avec l’inspection approfondie des paquets.

Si vous ne pouvez pas exécuter un binaire et que vous ne pouvez pas compter sur SSH, vous restez bloqué sur localhost — mais l’IT doit presque toujours autoriser un navigateur et HTTPS sortant sur le port 443. C’est là que le tunnel dans le navigateur exploite cette faille.

2. Anatomie d’un reverse proxy uniquement dans le navigateur

Un reverse proxy dans le navigateur déplace la logique de routage d’un daemon système vers l’onglet du navigateur lui-même. Au lieu de télécharger quoi que ce soit, vous ouvrez une page web.

Le flux, sans logiciel installé :

1. Le point d’entrée public. Le service de tunneling exécute un serveur d’entrée public — dans le cas de Tabserve, un seul Cloudflare Worker. Lorsqu’un utilisateur distant accède à votre URL de tunnel, le Worker intercepte la requête.
2. La connexion WebSocket. L’onglet du navigateur maintient une connexion WebSocket persistante avec ce Worker. Pour un pare-feu d’entreprise, cela ressemble à n’importe quelle autre application web en direct — un client de chat, un tableau de bord, un document collaboratif.
3. Le marshalling des requêtes. Le Worker sérialise la requête HTTP entrante (méthode, en-têtes, corps) et la pousse via WebSocket vers l’onglet.
4. L’exécution locale. Un Web Worker dans cet onglet désérialise la charge utile et envoie la requête à votre serveur local (par exemple, http://127.0.0.1:8080) en utilisant la fonction native fetch() du navigateur.
5. Le proxy de la réponse. La réponse du serveur local est sérialisée et renvoyée via WebSocket au Worker Cloudflare, qui la retourne à l’utilisateur distant.

L’ensemble de cette boucle se déroule dans le sandbox du navigateur : pas de CLI, pas de permissions élevées, pas d’installation.

3. Ce qui se cache derrière : Cloudflare Workers + Web Workers (pas WASM)

Voici une correction importante : il est facile de trouver des versions de cette histoire — y compris des brouillons antérieurs — qui décrivent Tabserve comme un projet WebAssembly (WASM). Ce n’est pas le cas. Les dépôts de Tabserve le précisent clairement : “Tabserve est une application web qui utilise des Web Workers dans le navigateur comme reverse proxy.” La composante Worker est un Cloudflare Worker écrit en JavaScript/TypeScript ordinaire, et le proxy local se fait via Web Workers exécutant du JS standard dans l’onglet du navigateur — pas via des modules WebAssembly compilés.

Cette distinction est importante pour deux raisons :

• WASM et Web Workers résolvent des problèmes différents. Un Web Worker déplace le travail du thread principal pour que l’UI ne freeze pas pendant la gestion des requêtes — c’est exactement ce dont Tabserve a besoin, et c’est ce qu’il utilise. WebAssembly permet d’exécuter du code compilé à vitesse proche du natif dans le navigateur ; des usages en production existent (l’ABI Proxy-Wasm utilisé par Envoy et autres proxies d’edge est un exemple légitime, séparé), mais ce n’est pas ce qui alimente cet outil.
• Les Durable Objects sont la couche d’état réelle. La partie Cloudflare Worker utilise Durable Objects avec l’API WebSocket Hibernation pour maintenir chaque tunnel connecté à moindre coût — l’objet “dort” entre les messages, ce qui permet de ne facturer que le trafic actif. Notamment, les Durable Objects nécessitaient le plan Workers Payant à 5$/mois lors de la première version de Tabserve (un issue GitHub 2023 montre un déploiement échouer pour cette raison). Cloudflare a déplacé les Durable Objects vers le plan gratuit des Workers en avril 2025, avec des limites d’utilisation gratuites — donc l’auto-hébergement du Worker Tabserve n’exige plus forcément un compte payant, mais une utilisation intensive peut dépasser ces limites.

La documentation de Tabserve indique aussi clairement ses contraintes réelles à connaître avant de s’y fier :

• HTTP(S) uniquement. Pas de TCP ou UDP — c’est une limite stricte du routage via l’API fetch() du navigateur, pas une fonctionnalité manquante.
• Capacité maximale. Environ 100–500 requêtes par seconde.
• Une réponse de 5 Mo peut bloquer. Les réponses volumineuses bloquent la boucle d’événements du Worker/Web Worker et ralentissent tout le trafic jusqu’à ce que ça se vide.
• L’onglet doit rester ouvert et actif. Certains navigateurs tentent de suspendre les Web Workers inactifs ; le projet indique que Chrome et Firefox de bureau tiennent le coup plusieurs jours, mais cela n’a pas été testé exhaustivement sur tous les navigateurs et OS.

4. Une complication en direct : tabserve.dev ne pointe plus vers Tabserve

C’est le genre de vérification d’état actuel qui doit être faite, et cela modifie le conseil pratique de ce document. À l’heure où j’écris, tabserve.dev — le domaine officiel du projet — ne héberge plus Tabserve. Il redirige vers une page de jeu en ligne indonésienne ou de vente de T-shirts, sans trace de l’outil original. La organisation GitHub (emadda/tabserve, le tracker d’incidents, et emadda/worker-tabserve-reverse-proxy, la source du Worker) est toujours active et mentionne tabserve.dev comme site canonique dans le README, mais le domaine lui-même a été abandonné et repris par une partie non liée.

Concrètement, cela signifie :

• Ne tapez pas tabserve.dev dans un navigateur en vous attendant à l’outil. Ce n’est pas malveillant, d’après ce qu’on peut voir, juste squatté — mais ce n’est pas Tabserve.
• La seule méthode actuelle pour l’utiliser est l’auto-hébergement. Les deux dépôts sont open source (le Worker sous emadda/worker-tabserve-reverse-proxy, l’interface web sous emadda/tabserve). Vous déployez le Worker dans votre compte Cloudflare et domaine via wrangler, configurez une route Workers (*.votre-domaine.com/*), collez votre AUTH_TOKEN dans la configuration de l’UI web, et seulement là vous obtenez l’expérience “visiter une page, obtenir une URL HTTPS” promise par le concept.
• Cela adoucit quelque peu le discours “sans CLI”. L’utilisateur final accédant à votre URL de tunnel et vous, en train de faire du tunneling au quotidien, ne touchent jamais un CLI. Mais la mise en place — déployer un Worker, configurer DNS, définir un token d’authentification — reste une opération unique avec wrangler et le tableau de bord Cloudflare, généralement effectuée par la personne qui le met en place pour une équipe, pas une expérience totalement sans CLI.

Il faut garder cela en tête comme une leçon générale : le plus grand avantage d’un tunnel dans le sandbox du navigateur (pas de binaire à installer qui devienne obsolète) s’accompagne d’une fragilité différente (un domaine unique qui peut expirer, être squatté ou disparaître, mettant fin au “produit” même si le code est correct).

5. Tabserve vs ngrok : Comparaison honnête

Capacité	ngrok	Tabserve (auto-hébergé)
Environnement d’exécution	Binaire/daemon système	Onglet navigateur (Web Workers) + votre propre Cloudflare Worker
Configuration	Télécharger CLI, ngrok config add-authtoken, lancer	Une seule fois : déployer Worker sur votre compte Cloudflare, configurer la route DNS, coller le token dans l’UI web
Utilisation quotidienne	Exécuter une commande CLI par tunnel	Ouvrir la page web auto-hébergée, pas de CLI
Privilèges admin	Non requis pour usage basique ; peut être nécessaire pour l’installation	Jamais requis sur la machine du développeur
Pare-feu	Sortant vers l’edge de ngrok ; généralement OK sur 443, mais binaire/processus reconnaissable et parfois bloqué	Semble du trafic WSS ordinaire sur 443 depuis un onglet du navigateur
Protocoles	HTTP, HTTPS, TCP, TLS (pas UDP natif)	HTTP/HTTPS uniquement — limité par l’API fetch() du navigateur
Débit	Limité par votre plan de bande passante, pas le protocole	~100–500 RPS selon la documentation de Tabserve ; réponses volumineuses (5 Mo+) peuvent bloquer l’événement
Stabilité du domaine/URL	La version gratuite obtient un domaine *.ngrok-free.app persistant (ne tourne plus en rotation au redémarrage depuis la mise à jour de janvier 2026) ; domaines personnalisés à partir du plan Hobbyist	Sous-domaine configuré sur votre propre domaine — entièrement sous votre contrôle, mais c’est votre zone Cloudflare à gérer
Tarification (2026)	Gratuit (3 endpoints, 1 Go/mo, 20 000 requêtes HTTP/mo) ; Hobbyist ~$8–10/mo ; Pay-as-you-go à partir de 20$/mo	Gratuit en auto-hébergement avec le plan gratuit Cloudflare Workers (Durable Objects inclus depuis avril 2025) ; limites d’utilisation à l’échelle
Public cible	Postes de travail non restreints, CI/CD, besoins en production	Ordinateurs portables d’entreprise verrouillés, partage rapide ponctuel, équipes prêtes à auto-héberger

Quand utiliser ngrok

ngrok reste la meilleure option pour les environnements non restreints et tout ce qui dépasse HTTP simple : tunnels TCP bruts (exposant une base de données locale directement), certificats TLS personnalisés, ou endpoints longue durée qui doivent survivre à un redémarrage sans re-déploiement. Un proxy uniquement dans le navigateur ne peut pas tunneliser du TCP brut, car l’API fetch() du navigateur n’a pas accès aux sockets.

Quand un tunnel dans le navigateur a encore du sens

Si votre équipe possède (ou est prête à déployer) son propre domaine hébergé par Cloudflare, l’auto-hébergement de Tabserve offre un tunnel HTTPS sans rien à installer côté développeur — vraiment utile pour un Chromebook, une session VDI qui se réinitialise chaque nuit, ou une machine de contractant que vous ne contrôlez pas. Prévoyez simplement la configuration initiale, et n’attendez pas une version hébergée publique et toujours disponible à tabserve.dev — cette porte est actuellement fermée.

6. L’avenir du partage localhost sans CLI

La tendance vers le partage localhost sans CLI n’est pas seulement une solution de contournement pour l’IT stricte ; elle s’inscrit dans un mouvement plus large vers un développement effectué directement dans un onglet du navigateur. GitHub Codespaces reste un exemple majeur de cette évolution pour des environnements de développement complets. Une correction importante à apporter à une version antérieure : Gitpod, souvent cité aux côtés de Codespaces, n’est plus le même produit qu’avant. La version payante de Gitpod Classic a été abandonnée le 15 octobre 2025, et la société a été rebaptisée Ona, positionnée comme “centre de contrôle pour projets logiciels et agents de développement logiciel” plutôt qu’un IDE cloud simple — les utilisateurs existants ont été dirigés vers le plan gratuit d’Ona ou vers des offres d’entreprise plutôt qu’un produit Gitpod Classic continu.

Cela ne remet pas en cause la tendance sous-jacente — les environnements de développement cloud accessibles entièrement via un navigateur sont toujours très présents — mais cela signifie que Gitpod en tant que tel n’est plus un exemple parfait en 2026.

Les tests de webhooks restent l’un des cas d’usage les plus clairs pour tout tunnel éphémère dans le navigateur : attraper un webhook Stripe ou GitHub, vérifier votre gestionnaire, fermer l’onglet, c’est tout — le cycle de vie de l’onglet sert aussi de barrière de sécurité automatique.

Les environnements VDI (Citrix Workspaces et similaires, courants dans la banque, la santé, la défense) sont aussi très adaptés : machines qui se réinitialisent quotidiennement, effaçant tout outil CLI installé, tout ce qui nécessite une installation locale sans persistance a un avantage évident.

---

Changelog

• Suppression et correction de la mention WASM. La version initiale présentait Tabserve comme une architecture “tunnel Cloudflare Worker WASM”. Les dépôts de Tabserve décrivent l’utilisation de Web Workers dans le navigateur, pas de WebAssembly ; la section 3 a été réécrite en conséquence, et WASM/Proxy-Wasm n’est mentionné qu’en tant que pattern séparé, réel mais non utilisé par cet outil.
• Ajout du mécanisme d’état réel du Cloudflare Worker (Durable Objects + API WebSocket Hibernation) et correction de son historique de coûts : les Durable Objects nécessitaient le plan payant à 5$/mois en 2023, mais ont été intégrés au plan gratuit en avril 2025 (avec limites d’usage gratuites).
• Ajout des limitations documentées de Tabserve (HTTP-only, ~100–500 RPS, blocage de réponses de 5 Mo, onglet doit rester actif) — absentes de la version initiale, mais directement pertinentes.
• Correction majeure : tabserve.dev est actuellement squatté. Le domaine ne héberge plus Tabserve — il redirige vers une page de jeu ou de vente. Ce changement modifie le conseil : l’outil n’est utilisable qu’en auto-hébergement à partir du code source. Ajout d’une section dédiée et modification de toutes les références à “visiter le site” pour refléter cette réalité.
• Atténuation du discours “sans CLI” pour distinguer la configuration (qui implique wrangler et le tableau de bord Cloudflare, une opération unique) de l’utilisation quotidienne (qui reste réellement sans CLI).
• Correction de la mention du port SSH alternatif. La version initiale citait “port 223” ; la convention réelle est 2222 (223 ne correspond pas à un port SSH largement utilisé).
• Réécriture du tableau comparatif avec les prix et fonctionnalités actuels de ngrok en 2026 (gratuit : 3 endpoints/1 Go/mois/20 000 requêtes ; Hobbyist ~8–10$/mois ; Pay-as-you-go à partir de 20$/mois), supportant HTTP/HTTPS/TCP/TLS mais pas UDP natif, avec la mise à jour de ngrok en janvier 2026 pour un domaine de développement persistant non rotatif.
• Correction de la référence à Gitpod dans la conclusion : le plan payant de Gitpod Classic a été abandonné en octobre 2025, et la société a été rebaptisée Ona ; la version initiale citait Gitpod comme un exemple actuel, ce qui n’est plus exact.
• Sources vérifiées : github.com/emadda/tabserve, github.com/emadda/worker-tabserve-reverse-proxy (README, wrangler.toml, Issue #1, Discussion #3), fetch en direct de tabserve.dev, changelog Cloudflare (avril 2025), comparatif 2026 ngrok, et github.com/gitpod-io/gitpod / annonce de rebranding Ona.