Surviving the SaaS Pivot: Why AGPL Open-Source Tunnels Win

Developers exposing local environments to the internet face a persistent threat : providers de dépréciation des niveaux gratuits, restriction de la bande passante, et verrouillage des fonctionnalités derrière des paywalls d’entreprise. La traduction d’adresses réseau (NAT) et la NAT de niveau opérateur (CGNAT), désormais standard dans la plupart des fournisseurs d’accès à Internet grand public et mobiles, signifient que la plupart des développeurs ne disposent plus d’une adresse IPv4 routable publiquement, rendant les tunnels en reverse-proxy une couche obligatoire dans la pile de développement moderne. La création d’un récepteur webhook, d’une interface d’agent IA, ou d’un serveur de jeu multijoueur local implique presque toujours de faire appel à un démon de tunneling pour franchir le pare-feu local et exposer un point de terminaison public.

Pendant des années, l’industrie a privilégié des plateformes SaaS propriétaires pour résoudre ce problème de routage. À mesure que l’écosystème mûrit et que les exigences de profit contraignent ces plateformes à resserrer leurs conditions, la communauté open-source migre vers une “assurance pivot fournisseur” — des outils licenciés strictement sous la GNU Affero General Public License (AGPL) qui permettent aux développeurs d’héberger eux-mêmes la même infrastructure si le fournisseur commercial change ses conditions ou disparaît.

Pourquoi les niveaux gratuits diminuent

Le recul par rapport aux tunnels freemium généreux est motivé par des changements réels et mesurables dans les deux options par défaut les plus populaires.

ngrok, longtemps l’outil de référence pour l’exposition locale, propose désormais un plan gratuit réellement plafonné : un crédit d’utilisation unique de 5 $, jusqu’à 3 points de terminaison en ligne, 1 Go de transfert de données, et 20 000 requêtes HTTP/S par mois. Une fois ce crédit ou ces limites atteints, les points de terminaison cessent d’accepter du trafic jusqu’au reset mensuel suivant. Au-delà du gratuit, le niveau Hobbyist d’ngrok coûte 10 $/mois (8 $/mois facturés annuellement) pour 3 points de terminaison et 5 Go de bande passante, et le paiement à l’utilisation commence à 20 $/mois plus 0,10 $/Go et 1 $ pour 100 000 requêtes supplémentaires, avec un nombre illimité de points de terminaison et une option de domaine personnalisé.

Cloudflare Tunnel est souvent présenté comme une alternative sans coût, et pour l’entrée HTTPS, c’est en grande partie le cas — mais il hérite de restrictions réelles issues des conditions du CDN de Cloudflare qui peuvent surprendre. Deux points importants, plus précis que ce qui est souvent dit :

• La restriction vidéo/grand fichier. Elle est souvent (et maintenant obsolète) citée comme “Section 2.8” des conditions de Cloudflare — mais cette section a été retirée en mai 2023, lorsque Cloudflare a déplacé la restriction basée sur le contenu de son accord général d’abonnement en une section spécifique aux services CDN dans ses Conditions d’utilisation spécifiques. La restriction ne s’applique qu’au CDN de Cloudflare — c’est-à-dire qu’elle concerne les routes hostname publics d’un Tunnel Cloudflare (qui font proxy via le edge de Cloudflare), mais pas aux routes du réseau privé du Tunnel accessibles via WARP. Elle est également plus limitée qu’une interdiction totale de streaming : les vidéos et autres gros fichiers sont acceptés aujourd’hui sur le CDN tant qu’ils sont servis depuis un service hébergé par Cloudflare comme Stream, Images ou R2 — la restriction concerne la livraison de fichiers volumineux hébergés en dehors de Cloudflare via le CDN. Un serveur Plex ou Jellyfin auto-hébergé exposé via un hostname Tunnel public est concerné ; le même serveur accessible uniquement via WARP privé ne l’est pas.
• La limite de 100MB pour le corps de la requête. Les plans gratuits et Pro plafonnent la taille maximale du corps de requête HTTP (POST) proxyfée via le CDN à 100MB — au-delà, Cloudflare renvoie une erreur 413 “Request Entity Too Large” plutôt que de supprimer silencieusement les données. Les plans Business portent cette limite à 200MB et Enterprise à 500MB. C’est une limite réelle à prendre en compte pour les uploads de gros fichiers ou outils de synchronisation, mais il s’agit d’une limite de taille de corps sur le trafic proxy via le CDN, et non d’une suppression de chunks spécifique au Tunnel.

Fonctionnement de l’assurance pivot fournisseur

L’enfermement dans un fournisseur de tunnels se produit lorsqu’un développeur construit des pipelines CI, de test webhook ou d’automatisation autour d’une API propriétaire ou d’un relais en source fermée. Si l’entreprise hébergeant ce relais modifie ses tarifs ou ferme, le développeur doit réécrire toute son architecture réseau. L’assurance pivot fournisseur garantit qu’un développeur peut déployer une infrastructure identique sur son propre matériel, utilisant le même logiciel.

Cette garantie est codifiée par la GNU Affero General Public License v3.0 (AGPLv3). Contrairement aux licences permissives comme MIT ou Apache 2.0, l’AGPL ferme la “faille SaaS” dans la GPL classique : toute entité qui modifie le logiciel et l’exécute comme service réseau doit rendre cette version modifiée disponible aux utilisateurs y accédant via le réseau — pas seulement à ceux recevant un binaire compilé. Pour un relais reverse-proxy, cela signifie que le serveur principal ne peut pas être discrètement forké et rendu propriétaire par un opérateur commercial. Si un service de tunneling sous licence AGPL se dégrade ou modifie ses tarifs, un développeur peut provisionner un VPS à faible coût, déployer le même code de relais, et continuer à fonctionner sans changer sa configuration client locale.

Évaluation du paysage moderne du tunneling

Outil	Licence serveur	Langage principal	Protocoles supportés	Cas d’usage idéal	Profil de coût
ngrok	Proprietary	Go	HTTP, TCP, TLS	Tests webhook legacy	Gratuit (3 endpoints/1GB/20K req) → 10–20+ $/mo
rustunnel	AGPL v3.0	Rust	HTTP, TCP, UDP, P2P	Reverse-proxy auto-hébergé sous AGPL	0 $ auto-hébergé / 3+ $/mo PAYG
frp	Apache 2.0	Go	HTTP, HTTPS, TCP, UDP	Homelabs intensifs	Coût VPS (~4 $/mo)
Cloudflare Tunnel	Cloud propriétaire	Go (cloudflared)	HTTP, HTTPS via CDN ; TCP/UDP via WARP	Webhooks stateless, HTTPS gratuit	Gratuit (domaine requis)
rathole	MIT	Rust	TCP, UDP (pas de routage HTTP)	Port forwarding sur VPS peu puissant	Coût VPS (~4 $/mo)
bore	MIT	Rust	TCP uniquement	Port forwarding minimaliste	Relais public gratuit ou VPS à ~4 $/mo
Tailscale Funnel	Cloud propriétaire	Go	HTTPS/TCP (ports 443, 8443, 10000)	Partager un service hors du tailnet	Gratuit (plan personnel)

Quelques corrections importantes par rapport à la façon dont ce tableau est souvent présenté ailleurs : rathole ne gère pas le routage HTTP-aware — c’est un simple port-forwarder TCP/UDP sans couche HTTP basée sur sous-domaine ou chemin, contrairement à frp ou ngrok. Et Tailscale Funnel n’est pas un mesh L3 général — le réseau Tailscale sous-jacent est un mesh privé WireGuard ; Funnel est la fonctionnalité précise qui sort un seul service de ce mesh privé vers Internet via HTTPS ou TCP brut sur quelques ports fixes.

L’écosystème alimenté par Rust

Les performances et la sécurité mémoire sont cruciales pour les relais en edge gérant des millions de connexions multiplexées WebSocket et TCP, et la communauté open-source s’est de plus en plus tournée de Go et Node.js vers Rust pour cette couche. rathole privilégie le débit brut et une empreinte minimale en échange de la conscience HTTP — son binaire peut faire environ 500KB en version allégée, avec une version complète plus volumineuse. Il authentifie et chiffre avec le Noise Protocol Framework, en utilisant par défaut le pattern Noise_NK (authentifié côté serveur), nécessitant la génération d’une paire de clés avec rathole --genkey et la configuration du client avec la clé publique du serveur. bore va encore plus loin vers la minimalisme : un seul binaire Rust, TCP-only, avec un relais communautaire gratuit à bore.pub. Son flag --secret authentifie la poignée de main du tunnel, mais ne chiffre pas le trafic tunnelé par défaut — TLS doit être géré par l’application derrière ou ajouté à une autre couche.

Dans ce domaine fortement Rust, rustunnel est un nouvel entrant plus complet qui cible directement l’usage d’ngrok. Sous licence AGPL, il expose des services locaux HTTP, TCP, UDP (plus tunnels P2P natifs avec authentification partagée), via un edge géré ou un relais auto-hébergé, et compte actuellement environ 600–650 étoiles sur GitHub avec une activité régulière jusqu’en 2026.

• Architecture & chiffrement : le trafic client-serveur passe par des connexions WebSocket chiffrées TLS, avec provisioning automatique Let’s Encrypt pour les points de terminaison publics.
• Haute disponibilité : plusieurs backends peuvent être derrière un sous-domaine ou port TCP personnalisé, équilibrés avec des sondes de santé configurables, pour retirer automatiquement un backend défectueux.
• Observabilité : un tableau de bord terminal en plein écran affiche le statut des sessions en direct, la latence par région, et les compteurs de requêtes par seconde, avec sortie JSON exploitable. La documentation mentionne aussi des métriques Prometheus et du logging d’audit — utiles pour la télémétrie au niveau connexion et tunnel (qui s’est connecté, quand, combien de données) plutôt que pour inspecter le contenu réel du payload tunnelé, ce qui est cohérent avec la position de rustunnel sur la confidentialité.
• Intégration d’agent IA : il fournit un serveur MCP natif avec des guides d’installation en un clic pour Cursor, Claude Code, Claude Desktop, et Windsurf, distribué en binaire natif plutôt qu’en package npm.
• Tarification : auto-hébergement gratuit (tunnels illimités, source AGPL), un niveau hébergé gratuit (jusqu’à 3 tunnels, pas de sous-domaines personnalisés), et un niveau payant à l’usage à partir de 3 $/mois + 0,10 $/Go supplémentaire — pas de compteur horaire séparé, donc les tunnels inactifs n’entraînent pas de coûts au-delà du minimum fixe. La zone gérée couvre actuellement Helsinki, Hillsboro (Oregon), et Singapour.

Si un niveau cloud géré comme celui-ci change ses conditions ou ferme, la même logique que pour l’AGPL s’applique : le même code serveur est disponible pour auto-hébergement gratuitement.

Identifier et éviter l’abandonware

Éviter l’enfermement fournisseur ne sert à rien si l’alternative open-source n’est pas maintenue. Le nombre d’étoiles peut être trompeur, car il reflète la popularité historique plutôt que l’activité actuelle.

frp (Fast Reverse Proxy) est l’exemple le plus clair d’une infrastructure auto-hébergée durable et active : sous licence Apache-2.0, écrit en Go, avec plus de 106 000 étoiles GitHub et une activité continue, offrant du forwarding TCP, UDP, HTTP, et HTTPS avec routage par sous-domaine vhost et sans intermédiaire tiers.

localtunnel, en revanche, est une mise en garde : le dépôt localtunnel/localtunnel a environ 22 000 étoiles, mais l’activité de commits et d’étoiles est plate — pratiquement aucune nouvelle contribution ou étoile semaine après semaine jusqu’en 2026. Un tel projet silencieux comporte un vrai risque : dépendances non patchées, dérives TLS/protocoles, et un serveur relay public non maintenu qui pourrait disparaître sans préavis. C’est une solution acceptable pour une démo rapide, mais une mauvaise base pour quelque chose sur quoi vous comptez vous appuyer à long terme.

Déployer un relais open-source

Passer d’un tunnel SaaS propriétaire à un relais AGPL auto-hébergé implique quelques étapes, et c’est toujours la même démarche, que vous choisissiez rustunnel, frp, ou rathole :

1. Provisionner un hôte. Un petit VPS Linux avec une IP publique suffit — budget environ 4–6 $/mois ; le DigitalOcean Basic Droplet le moins cher commence actuellement à 4 $/mois.
2. Configurer DNS. Pour les outils de routage HTTP (rustunnel, frp), créer un enregistrement A générique (ex. *.tunnel.votredomaine.com) pointant vers l’IP publique du VPS, pour que le relais puisse attribuer dynamiquement des sous-domaines. Les outils TCP-only comme rathole et bore n’ont pas besoin de cela — ils se lient directement aux ports.
3. Déployer le relais. La plupart de ces projets proposent des images Docker ou des fichiers systemd, donc un docker-compose up ou une installation via gestionnaire de paquets suffit pour faire fonctionner rapidement le serveur.
4. Se connecter depuis votre machine locale. Le client établit une connexion persistante et chiffrée vers le VPS, faisant le pont entre localhost:8080 et un point de terminaison public sur votre domaine.

L’auto-hébergement élimine les plafonds de bande passante arbitraires, évite totalement le CGNAT ISP, et — parce que le code du relais est le même dans tous les cas — si un fournisseur commercial modifie ses tarifs ou ferme, cela ne nécessite pas de réécriture. Avec une infrastructure sous licence AGPL, c’est le développeur, pas le fournisseur, qui contrôle en fin de compte les règles de routage.