La Rébellion du Tunneling en Rust : Pourquoi des Outils comme Tunnelto Connaissent un Essor sur GitHub

Il y a une tendance forte dans la communauté des développeurs : une migration progressive des proxies de tunneling SaaS commerciaux vers des outils légers, open-source, écrits en Rust. Tout cela s’explique par la “fatigue du niveau gratuit” — des développeurs lassés des limites de bande passante, des restrictions d’endpoint, et des pages d’avertissement interstitielles quand ils veulent simplement tester un webhook.

Fin décembre 2025, l’outil open-source Tunnelto a connu un véritable moment viral sur GitHub, avec 565 étoiles en une seule journée et la 3e place sur la page des tendances de GitHub. Ce pic n’était pas artificiel — il reflétait une frustration réelle chez les développeurs à la recherche d’une alternative capable, auto-hébergée, gratuite à ngrok. C’est aussi une porte d’entrée vers une évolution plus large vers des outils de développement respectueux de la vie privée et auto-hébergés.

Dans ce guide : pourquoi les développeurs se tournent vers des reverse proxies en Rust, une comparaison vérifiée Tunnelto vs ngrok, d’autres alternatives open-source à ngrok à connaître, et comment fonctionne concrètement l’auto-hébergement d’un tunnel en Rust.

---

Le Problème Central : Le Dilemme du Localhost

Tout développeur web finit par rencontrer ce problème. Vous construisez quelque chose qui doit communiquer avec un service tiers — Stripe pour les paiements, Twilio pour SMS, Slack pour commandes slash. Ces plateformes communiquent via webhooks : des requêtes HTTP envoyées à une URL que vous spécifiez lors d’un événement.

Le problème : Stripe ne peut pas envoyer un webhook à http://localhost:3000. Votre serveur de développement est derrière le NAT et le pare-feu de votre routeur, invisible depuis l’extérieur.

Les Anciennes Solutions

Avant que les outils de tunneling ne deviennent courants, les développeurs contournaient cela avec :

1. Déploiement en staging — commit, push, attendre la CI/CD, puis déclencher le webhook. Une boucle de feedback de cinq secondes devient de cinq minutes.
2. Redirection de ports sur le routeur — techniquement possible, fastidieux, et pas ce que vous souhaitez laisser ouvert sur votre réseau domestique.
3. Simulation d’événements — capturer une charge utile une fois et la rejouer localement, mais cela ne couvre pas tous les cas réels.

La Montée des Tunnels Localhost

Un client de tunneling s’exécute sur votre machine, ouvre une connexion sortante vers un serveur relais public, et vous fournit une URL publique. Quand Stripe atteint cette URL, le relais transfère le trafic via le tunnel vers votre port local.

Pendant des années, ngrok était la référence. Il est presque devenu synonyme de tunneling localhost. Mais en évoluant vers une plateforme plus large de sécurité et d’API, certaines décisions de son niveau gratuit ont poussé une partie de ses utilisateurs à chercher ailleurs.

---

Fatigue du Niveau Gratuit : Que Dit Vraiment ngrok?

C’est ici que beaucoup de contenus “ngrok vs. le reste” deviennent imprécis, il est donc important d’être précis sur ce que limite réellement le niveau gratuit de ngrok, selon la documentation officielle.

Il n’y a pas de limite de session de 2 heures

Cette affirmation circule souvent dans les comparatifs, mais elle ne tient pas face à la documentation tarifaire et aux limites publiées de ngrok. Le plan gratuit est décrit comme gratuit pour toujours et n’est pas limité par la durée de session — vous ne serez pas déconnecté simplement parce que deux heures se sont écoulées. Ce que rencontrent réellement les utilisateurs gratuits, c’est un mélange de :

• 1 Go de bande passante par mois, avec un crédit d’usage unique de 5 $
• Jusqu’à 3 endpoints en ligne simultanément (cette limite ne se réinitialise pas mensuellement)
• Environ 20 000 requêtes HTTP par mois
• Sous-domaines aléatoires et rotatifs à chaque reconnexion — c’est cela qui casse réellement un workflow webhook, car il faut réenregistrer l’URL avec Stripe ou autre à chaque redémarrage.

Si votre tunnel se coupe en cours de session, c’est probablement une panne réseau, un redémarrage du client, ou le dépassement de la limite de bande passante/demandes, plutôt qu’un timer fixe. Il faut corriger cette idée dans votre esprit si vous avez vu cette “limite de 2 heures” ailleurs — c’est une des inexactitudes les plus répandues dans cet espace.

La page d’avertissement interstitielle est réelle

Pour limiter le phishing et les abus de malware, ngrok injecte une page HTML d’interstitiel (“Visit Site”) devant le trafic du navigateur sur les URLs du niveau gratuit. ngrok fournit un en-tête (ngrok-skip-browser-warning) pour la contourner pour les clients API, mais beaucoup de fournisseurs de webhook ne permettent pas d’injecter des en-têtes personnalisés — ce qui peut réellement casser la livraison automatique des webhooks en niveau gratuit.

Tarification actuelle de ngrok (mi-2026)

ngrok propose quatre niveaux : Free, Hobbyist, Pay-as-you-go, et Enterprise.

• Free — 0 $/mois, crédit d’usage unique de 5 $, 1 Go de bande passante, 3 endpoints, ~20k requêtes/mois
• Hobbyist — 10 $/mois (8 $/mois si annuel), crédit mensuel de 10 $, 5 Go de bande passante, 3 endpoints, ~100k requêtes/mois
• Pay-as-you-go — 20 $/mois de base (inclut 20 $ d’usage), puis facturation à la consommation pour transfert de données, requêtes, et heures d’endpoint
• Enterprise — prix personnalisé, négocié par déploiement

Le cadre “8–29 $/mois” des comparatifs anciens est une approximation valable pour Hobbyist/Pay-as-you-go, mais les noms et la structure ont changé plusieurs fois — il vaut mieux vérifier directement la page de tarification de ngrok, car cela a évolué plusieurs fois cette année.

---

La Rébellion en Rust : Entrée dans Tunnelto

Fin décembre 2025, Tunnelto — un outil de tunneling en Rust créé par le développeur Alex Grinman (GitHub : agrinman/tunnelto) — a atteint la 3e place sur la page des tendances de GitHub, avec 565 étoiles en 24 heures. À l’époque, il tournait autour de 3 665 étoiles ; sa croissance continue, atteignant aujourd’hui entre 6 000 et 7 000 étoiles, avec environ 500 forks.

Un détail important à clarifier, car cela peut embrouiller certains comparatifs : il existe deux produits différents qui portent le nom “tunnelto”.

• tunnelto.dev (agrinman/tunnelto sur GitHub) — le projet open-source, sous licence MIT, dont cette section parle. Sa dernière version client, v0.1.18, est sortie en mai 2021. Le projet n’est pas abandonné — des issues sont traitées occasionnellement et l’instance demo hébergée sur tunnelto.dev tourne toujours sur Fly.io — mais aucune nouvelle fonctionnalité CLI n’a été publiée depuis des années, et le serveur auto-hébergé ne supporte pas les domaines personnalisés ni l’authentification intégrée.
• tunnelto.me — un service de tunneling commercial, actif, qui partage un nom similaire. Il propose sa propre version gratuite (1 domaine personnalisé, 1 Go de bande passante/mois, sessions d’1 heure) et des plans payants à partir d’environ 2 $/mois pour des domaines persistants.

Ce ne sont pas la même base de code, ni la même équipe, ni le même produit — malgré ce que certains articles “alternatives à ngrok” laissent entendre en citant la page de tarification de tunnelto.me comme si elle décrivait le projet open-source tunnelto.dev.

Architecture de Tunnelto (tunnelto.dev)

Tunnelto est entièrement construit sur async-io au-dessus de Tokio, le runtime async standard de Rust. Le système comporte deux parties :

1. Le client — un binaire léger en Rust que vous exécutez localement (tunnelto --port 8000), qui ouvre une connexion TCP sortante vers le serveur Tunnelto.
2. Le serveur — une application Rust sur une machine accessible publiquement, qui termine les requêtes HTTP/HTTPS entrantes et multiplexe le trafic vers la bonne connexion client.

Parce que c’est Rust avec un runtime async, il gère de nombreuses connexions simultanées avec une empreinte mémoire réduite comparée à un équivalent Node.js ou Python.

Pourquoi cette montée ?

Plusieurs explications plausibles, non exclusives, pour le pic de décembre 2025 :

1. Friction accumulée avec les contraintes du niveau gratuit de ngrok (limites de bande passante, d’endpoint, pages d’avertissement) qui atteint un point critique pour certains développeurs.
2. Une préférence pour la propriété — pouvoir lire, forker, auto-héberger le code plutôt que dépendre d’un service cloud tiers.
3. L’effet halo de Rust — Rust a été en tête du sondage Stack Overflow “langage le plus admiré” plusieurs années consécutives, et le rapport State of Developer Ecosystem 2025 de JetBrains estime à environ 2,27 millions le nombre de développeurs ayant utilisé Rust dans les 12 derniers mois. Les outils en Rust ont tendance à bénéficier d’un crédit de crédibilité basé sur leur rapidité et leur sécurité.

Prenez cette viralité avec un peu de recul — la majorité des raisons évoquées pour cette montée viennent d’un seul article de blog du jour où la tendance a explosé, pas d’une étude ou d’un sondage.

---

Tunnelto vs ngrok : Une Comparaison

1. Tarification et limites

• ngrok : Niveau gratuit comme décrit plus haut (1 Go de bande passante, 3 endpoints, URLs aléatoires, page d’avertissement). Hobbyist à partir de 10 $/mois (8 $/mois si annuel) ; Pay-as-you-go à partir de 20 $/mois + usage.
• tunnelto.dev (open source) : Le logiciel lui-même est gratuit, sous licence MIT — vous pouvez l’auto-héberger sur n’importe quel VPS, pour un coût équivalent à celui du VPS (un droplet à 5 $/mois suffit). Il n’y a pas de facturation intégrée ni de niveau payant pour le projet open-source, mais pas de support de domaine personnalisé ni d’authentification sans ajouter votre propre reverse proxy.
• (Si vous cherchez un tunnel commercial hébergé, maintenu, avec domaines personnalisés sur le niveau gratuit, c’est tunnelto.me — produit différent, à partir de 0 $, avec plans payants à partir d’environ 2 $/mois pour des domaines persistants. Ne pas confondre les deux lors de la comparaison des coûts.)

2. Expérience développeur

• ngrok : CLI mature, intégration avec de nombreux frameworks, tableau de bord avec inspection du trafic HTTP en temps réel.
• tunnelto.dev : Une seule commande (tunnelto --port 3000) pour obtenir rapidement une URL publique. C’est volontairement minimal — vous sacrifiez l’outil d’inspection du trafic de ngrok pour la simplicité et l’absence d’interstitiel forcé.

3. Hébergement et contrôle

• ngrok : Code fermé, dépendant entièrement de leur cloud. Si leur infrastructure a des problèmes, votre tunnel aussi.
• tunnelto.dev : Licence MIT. Vous pouvez lire le code, le forker, et lancer votre propre serveur — le projet documente le déploiement du binaire serveur (compilé pour la cible musl) via Docker, avec configuration par variables d’environnement. Vous gérez la disponibilité et l’infrastructure.

4. Domaines personnalisés

• ngrok : Domaines personnalisés/stables nécessitent un plan payant.
• tunnelto.dev (auto-hébergé) : Vous pouvez pointer votre propre domaine vers votre serveur, mais vous êtes responsable du TLS — généralement via Nginx ou Caddy. Ce n’est pas automatique comme chez certains concurrents.

---

Explorer l’Écosystème : Autres Alternatives Open Source à ngrok

Tunnelto n’est pas la seule option. Voici où en est le reste du marché, vérifié par rapport à chaque repo.

1. rustunnel

Outil de tunneling en Rust sous licence AGPL (joaoh82/rustunnel) — auto-hébergeable ou service payant à la demande. Sa particularité : un serveur MCP pour agents IA, support UDP, tunnels P2P, groupes avec vérification de santé — vraiment différencié des outils plus anciens, qui datent d’avant la vague actuelle d’outillage pour agents.

2. bore

Créé par Eric Zhang (ekzhang/bore), bore est un tunnel TCP minimaliste sous licence MIT — environ 400 lignes en Rust asynchrone. Il a environ 11 100 étoiles. Il fait une seule chose : transférer un port TCP local vers un serveur distant. Pas de parsing HTTP, pas de TLS, pas de tableau de bord.

À savoir si vous l’évaluez : le flag optionnel --secret ajoute une authentification HMAC pour contrôler qui peut ouvrir un tunnel, mais selon la doc, cela ne couvre que la poignée de main — le trafic tunnelé n’est pas chiffré par défaut. Si vous transférez quelque chose sans TLS, le trafic est visible en transit. Cette nuance est souvent oubliée dans les comparatifs “bore vs ngrok”.

3. rathole

Positionné comme une alternative performante à frp (rathole-org/rathole sur GitHub), rathole supporte TCP et UDP, cible les environnements embarqués (binaire d’environ 500 Ko), et supporte le rechargement à chaud de la config.

4. frp (Fast Reverse Proxy)

Écrit en Go, pas en Rust, mais le poids lourd du secteur — fatedier/frp a environ 108 000 étoiles et 15 000 forks, bien plus que tous les autres outils Rust réunis. Supporte HTTP, HTTPS, TCP, UDP, WebSockets, configuré via TOML, et reste le choix par défaut pour des déploiements complexes en production.

5. Cloudflare Tunnel (cloudflared)

Pas open-source de bout en bout (le serveur est Cloudflare), mais le client cloudflared est open-source, et le service est gratuit avec tout compte Cloudflare. En 2026, il utilise QUIC (HTTP/3) par défaut, intégré dans la plateforme “Cloudflare One” Zero Trust — vous pouvez mettre une politique d’accès (SSO, OTP, fournisseurs tiers) devant un tunnel, gratuitement, jusqu’à 50 utilisateurs, sans écrire votre propre code d’authentification. Nécessite DNS géré par Cloudflare pour les tunnels avec domaines personnalisés, mais les tunnels rapides (cloudflared tunnel --url) fonctionnent sans domaine, comme ngrok en niveau gratuit.

---

Pourquoi Rust Correspond à Ce Job

Ce n’est pas un hasard si beaucoup d’outils de tunneling actuels (Tunnelto, bore, rathole, rustunnel) sont écrits en Rust :

1. Haute concurrence, faible mémoire — un serveur de tunnel peut maintenir des milliers de connexions inactives. Rust gère cela avec un empreinte mémoire bien plus petite qu’un runtime gérant le même volume en garbage collection.
2. Latence prévisible — pas de pauses GC, pas de micro-stutters imprévisibles, important pour le temps réel (WebSockets).
3. Sécurité mémoire — les proxies face au réseau sont souvent la cible de bugs de corruption mémoire en C/C++. Rust élimine ces classes de bugs à la compilation.
4. Binaries statiques multiplateformes — Rust compile proprement, vous obtenez un seul binaire sans dépendances runtime.

---

Auto-Hébergement d’un Tunnel Localhost en Rust : Ce Que Ça Implique

Si vous souhaitez gérer votre propre serveur de tunnel plutôt que de dépendre d’un service tiers, voici une vue réaliste — en utilisant la documentation officielle de Tunnelto comme exemple, et non une version idéalisée.

Prérequis

• Un VPS avec IP publique (DigitalOcean, Linode, AWS EC2, etc.)
• Un domaine pointé vers ce VPS, si vous voulez un domaine personnalisé
• Confort avec SSH, Docker, et configuration de reverse proxy

Étape 1 : Installer le toolchain Rust (si compilation depuis la source)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env

Étape 2 : Lancer le serveur

Le serveur Tunnelto est documenté comme déployé via Docker, compilé pour la cible musl, configuré par variables d’environnement — pas une seule option CLI pour un domaine personnalisé. Clonez le repo et compilez ou récupérez l’image publiée :

git clone https://github.com/agrinman/tunnelto.git
cd tunnelto/tunnelto_server
cargo build --release

Prévoyez de le faire tourner derrière Nginx ou Caddy pour TLS — le serveur auto-hébergé ne gère pas HTTPS automatique ni le routage par domaine comme l’instance demo tunnelto.dev.

Étape 3 : Connectez-vous avec le client

cargo install tunnelto
tunnelto --port 3000

Par défaut, cela pointe vers le service tunnelto.dev hébergé. Pour utiliser votre propre serveur, configurez le client avec l’adresse de votre serveur — vérifiez l’aide CLI (tunnelto --help) pour le bon flag, car cela peut varier avec les versions.

Une limite honnête : la doc indique que la version auto-hébergée ne supporte pas bien plusieurs instances sans coordination supplémentaire, car elle dépend d’un état centralisé. Suffisant pour une utilisation personnelle ou petite équipe, mais pas une alternative clé en main à ngrok sans développement supplémentaire.

---

La Tendance Plus Large : Maîtriser l’Expérience Développeur

Le phénomène derrière la montée de Tunnelto dépasse un seul repo. Pendant des années, la tendance était de tout externaliser à un SaaS spécialisé. Cela reste pertinent pour des bases de données gérées ou des CDN globaux — mais pour un utilitaire simple comme le tunneling localhost, de plus en plus de développeurs pensent qu’il n’est pas nécessaire de payer un abonnement récurrent.

Auto-héberger un tunnel personnalisé avec domaine propre sur un VPS à 5 $/mois — partagé dans une équipe — rend l’offre à 20+ $/mois par utilisateur beaucoup moins attractive, surtout si vous n’avez pas besoin des fonctionnalités avancées comme inspection du trafic, SSO d’entreprise ou SLA garantis.

Conclusion

La “Rébellion du Tunneling en Rust” est une correction de trajectoire, pas un remplacement total des solutions commerciales. Le niveau gratuit de ngrok est plus restrictif qu’avant — limites de bande passante, d’endpoint, pages d’avertissement — mais la fausse idée du “limite de 2 heures” n’est pas conforme à la documentation actuelle, et il faut la corriger quand on la voit.

Des outils comme Tunnelto, bore, rathole, et rustunnel offrent des alternatives gratuites, auto-hébergeables, souvent plus rapides pour ceux qui n’ont pas besoin des fonctionnalités d’entreprise de ngrok. Faites attention à la confusion entre tunnelto.dev et tunnelto.me lors de la comparaison des prix — ce sont des produits distincts, et beaucoup de comparatifs se trompent.

Que vous choisissiez une offre gratuite hébergée ou que vous déployiez votre propre tunnel Rust, le choix s’élargit et devient moins cher qu’il y a deux ans.

---

Changelog

• Supprimé la fausse affirmation “limite de session de 2 heures” du niveau gratuit ngrok, remplacée par ses vraies limites : 1 Go/mois, 3 endpoints, ~20k requêtes, sous-domaines rotatifs, page d’avertissement.
• Mis à jour la structure tarifaire de ngrok : Gratuit (0 $), Hobbyist (10 $/mois), Pay-as-you-go (20 $/mois + usage), Entreprise (sur devis).
• Correction majeure : clarification que tunnelto.dev (projet open-source agrinman/tunnelto) et tunnelto.me (service commercial) sont deux produits séparés, avec des modèles de tarification et fonctionnalités différents.
• Statistiques actualisées : tunnelto (stars passés de 3 665 à environ 6 000–7 000), dernière version client (v0.1.18, mai 2021), serveur auto-hébergé sans support natif pour domaines ou TLS automatiques.
• Correction du guide d’auto-hébergement : suppression d’une commande non vérifiée (tunnelto set-host) et remplacement par la méthode officielle via Docker/env variables, avec la note que le multi-serveur n’est pas supporté nativement.
• Ajouté statistiques vérifiées pour l’écosystème : bore (~11 100 étoiles, supporte HMAC, pas de chiffrement par défaut), frp (~108 000 étoiles, supporte HTTP/HTTPS/TCP/UDP), rathole (support TCP/UDP, focus sur appareils embarqués), rustunnel (licence AGPL, MCP pour IA).
• Suppression d’une affirmation non vérifiée sur rustunnel dans une étude 2026, aucune source indépendante n’étant trouvée.
• Mise à jour de la section Cloudflare Tunnel : transport QUIC/HTTP3, plateforme “Cloudflare One” Zero Trust, politiques d’accès gratuites jusqu’à 50 utilisateurs.
• Vérifié le chiffre d’adoption Rust (~2,27 millions de développeurs en 12 mois) selon le rapport JetBrains 2025, remplaçant la donnée non sourcée.
• Suppression des citations et références numérotées pour une meilleure lisibilité, la source étant intégrée dans le texte.