Pourquoi les développeurs remplacent ngrok par des tunnels en Rust

Si vous avez déjà travaillé sur le développement de webhooks, testé des API, ou tenté d’accéder à un serveur home lab à distance, vous connaissez la procédure standard : installer ngrok, exécuter une commande, obtenir une URL publique qui redirige vers votre localhost. Pendant des années, c’était le choix par défaut pour la traversée NAT et le tunneling local.

Mais une évolution est en cours, notamment chez les ingénieurs en edge computing, les hobbyistes IoT, et les utilisateurs de home labs. À mesure que les produits SaaS de tunneling commerciaux ajoutent plus de fonctionnalités d’entreprise (et des tarifs adaptés), les développeurs se tournent de plus en plus vers des alternatives open-source, minimalistes — beaucoup écrites en Rust.

Go-based frp (Fast Reverse Proxy) a longtemps été l’option open-source dominante, et reste le projet le plus important dans ce domaine avec une large avance. À ses côtés, un ensemble plus petit d’outils en Rust — rathole, bore, et le service hébergé tunnelto — ont gagné en popularité en échangeant la richesse des fonctionnalités d’frp contre une empreinte plus réduite et, dans le cas de rathole, une meilleure gestion sous charge sur du matériel contraint.

Voici une analyse honnête de ce que ces outils font réellement bien, où le récit “Rust bat Go” tient, et où il est exagéré.

La question du plan gratuit : ce que donne réellement ngrok

Une grande partie du contenu “passer à X” autour de ngrok reprend une affirmation qui n’est plus vraie depuis quelques années : que les utilisateurs du plan gratuit ont un sous-domaine aléatoire qui change à chaque reconnexion du tunnel. C’était vrai dans les premières années de ngrok, mais depuis 2023, ngrok attribue à chaque compte gratuit un domaine dev persistant (comme your-assigned-name.ngrok-free.app) lié au compte — il reste le même à chaque redémarrage, et la documentation officielle confirme que les points d’accès gratuits n’ont pas de timeout de session et peuvent fonctionner indéfiniment en tâche de fond.

Ce que le plan gratuit n’offre pas, c’est la possibilité de choisir votre propre sous-domaine ou d’apporter votre propre domaine — cela est réservé aux plans payants (Hobbyist pour un nom *.ngrok.app personnalisé, Pay-as-you-go pour votre propre domaine). La vraie limite n’est donc pas la rotation des URLs, mais le fait que vous ne pouvez pas faire de branding ou réutiliser un nom spécifique sans payer, et que les endpoints TCP nécessitent une carte de crédit vérifiée même sur le plan gratuit.

Cette distinction est importante, car c’est la vraie raison pour laquelle les développeurs cherchent des alternatives — pas un mythe de sessions de 2 heures ou d’URLs qui changent constamment.

La valeur de Rust à la périphérie

Le garbage collector de Go introduit des pauses non déterministes. Cela se remarque rarement sur une VM cloud, mais sous une charge soutenue de connexions sur du matériel contraint — un routeur OpenWrt, un Raspberry Pi ancien — les pauses GC et la croissance des buffers peuvent faire grimper l’utilisation mémoire au point de déclencher le killer Linux OOM.

Rust assure la sécurité mémoire sans garbage collector, donc il n’y a pas de pauses GC, et l’utilisation mémoire reste généralement stable même sous forte charge. Associé à l’environnement asynchrone tokio, cela permet aux tunnels en Rust de produire des binaires légers, dépendances faibles, avec une latence prévisible.

C’est la théorie. Voici comment cela se traduit pour chaque outil.

1. rathole : l’alternative frp plus légère

Initialement développé par l’utilisateur GitHub rapiz1 et maintenant maintenu par l’organisation rathole-org, rathole affiche 14 000 étoiles GitHub et 800 forks à ce jour, sous licence Apache-2.0.

Ce qu’il élimine

rathole supprime volontairement le tableau de bord web, le load balancer, et le système de plugins d’frp, en se concentrant sur le forwarding TCP/UDP avec une configuration client/serveur en TOML.

La revendication de benchmark, avec contexte

Le README de rathole indique qu’il offre une latence comparable à frp tout en supportant plus de connexions avec moins de mémoire. Les chiffres précis proviennent du fichier docs/benchmark.md : à des QPS de 1 à 3 000, rathole et frp montrent une latence presque identique ; à 4 000 QPS, frp commence à générer des erreurs avec une latence qui grimpe dans les secondes, alors que celle de rathole reste stable. Lors d’un test de charge soutenu de 30 secondes, la consommation mémoire d’frp augmente significativement, tandis que celle de rathole reste stable.

Deux points importants : le benchmark a été réalisé une seule fois, sur une machine unique (un PC Arch Linux avec un double Xeon E5-2620), en décembre 2021, et comparait une version ancienne de rathole à frp v0.38.0 — une version maintenant environ 30 versions derrière la branche v0.70.x d’frp. Il s’agit aussi d’un test en boucle locale, ce que la documentation de rathole précise reflète une performance limitée par le CPU plutôt que par le réseau réel. La tendance (moins de mémoire sous charge) est plausible, mais il n’existe pas de benchmark indépendant et récent confirmant que ces chiffres restent valides avec la version moderne d’frp.

Fonctionnalités remarquables

• Le protocole Noise : rathole peut utiliser optionnellement le protocole Noise pour le chiffrement du transport, au lieu de gérer des certificats TLS auto-signés. Noise est aussi ce qui sécurise la poignée de main de WireGuard, et il sécurise le transport client-serveur de WhatsApp — la vraie encryption de bout en bout de WhatsApp est un système séparé, le Signal Protocol. La comparaison avec WireGuard est précise ; celle avec WhatsApp est correcte mais plus limitée que “le même chiffrement que WhatsApp pour vos messages”.
• Binaire minimal : le guide de build de rathole permet d’obtenir un binaire x86_64 minimal de 574 KiB, contre environ 10 MiB pour frpc compilé de la même façon.
• Tokens par service obligatoires : chaque service nécessite son propre token, posture par défaut refusant tout sauf explicitement autorisé.
• Configuration à rechargement à chaud : on peut ajouter ou supprimer des services sans redémarrer.

Statut de maintenance

C’est la correction la plus importante : la dernière version taguée de rathole, v0.5.0, date du 1er octobre 2023 — moins de trois ans. C’est précis, mais cela ne veut pas dire abandonné : le dépôt possède une branche de développement active avec des builds automatisés (dernièrement début 2026), et des issues/PR sont encore ouvertes et fusionnées en 2025 et 2026. Il est plus juste de dire que rathole est “stable et peu maintenu sans nouvelles versions stables” que “en évolution active” ou “abandonné”.

2. bore : le tunnel TCP minimal

Créé par Eric Zhang sous licence MIT, bore affiche 11 100 étoiles GitHub et 493 forks, avec sa dernière version (v0.6.0) sortie en juin 2025.

La base du code

L’ensemble du client et du serveur de bore tient en environ 400 lignes en Rust asynchrone sur tokio — suffisamment petit pour être lu d’un seul coup.

Fonctionnement

bore local 8000 --to bore.pub

Expose le port local 8000 à bore.pub:<aléatoire_port> via le serveur public du mainteneur. Pour auto-héberger :

bore server

Un détail de sécurité à connaître

bore supporte une option --secret (ou la variable d’environnement BORE_SECRET) qui oblige les clients à prouver la possession d’un secret partagé via HMAC challenge avant d’accepter le tunnel. C’est une authentification réelle pour qui peut ouvrir un tunnel via votre serveur. Mais selon la documentation, ce secret ne couvre que la poignée de main initiale — le trafic proxifié n’est pas chiffré par défaut. Si vous tunnelisez autre chose qu’un service déjà en TLS (par exemple un serveur dev HTTPS), c’est un point à connaître avant de pointer vers des données sensibles. Cette nuance est absente de la plupart des comparatifs “bore vs ngrok” en ligne.

3. tunnelto : deux projets distincts portant le même nom

C’est la section qui nécessitait le plus de correction. “tunnelto” désigne en réalité deux projets séparés et non liés, et leur confusion (courante dans certains articles) donne une image trompeuse.

tunnelto.dev (agrinman/tunnelto sur GitHub) est le projet open-source, sous licence MIT, écrit en Rust. Sa dernière version date de 2021, et selon ses propres responsables, il n’a pas été mis à jour depuis — il ne possède pas de fonctionnalités de domaine personnalisé, d’authentification d’endpoint, ou d’hébergement statique.

tunnelto.me est un service hébergé, distinct et actif, qui partage le nom. Selon leur site (vérifié en juin 2026), il n’est pas basé sur le code abandonné de tunnelto.dev — leur tableau comparatif indique explicitement que tunnelto.dev n’est plus maintenu depuis 2021. La tarification de tunnelto.me est :

Plan	Prix	Domaine personnalisé	Persistance du tunnel
Gratuit	0 €	1, inclus	Tunnels d’1 heure seulement — à recréer
Hobbyiste	2 €/mois	1	Persistant (survive reboot)
Plus	10 €/mois	3	Persistant
Pro	20 €/mois	5	Persistant

Ce qui est réellement notable — et c’est vrai —, c’est qu’un domaine personnalisé est inclus dans le plan gratuit, ce que la plupart des concurrents (ngrok, bore) réservent aux plans payants. Mais le tunnel gratuit expire après une heure et doit être recréé, ce qui constitue une limite de session, différente de ngrok mais tout aussi contraignante. Si vous souhaitez un tunnel qui dure toute la nuit ou un reboot, c’est le plan Hobbyiste à 2 €/mois, pas le gratuit. L’authentification du tunnel (Bearer/Basic) est aussi une option payante.

Résumé comparatif

Fonctionnalité	ngrok	frp	rathole	bore	tunnelto.me
Langage	Go	Go	Rust	Rust	Non spécifié
Stars GitHub	— (fermé)	~107k	14 000	11 100	— (service hébergé)
Focus principal	SaaS commercial	Auto-hébergé, riche en fonctionnalités	Auto-hébergé, faible ressource	Auto-hébergé, minimaliste TCP	SaaS hébergé, domaines personnalisés
Domaine personnalisé, plan gratuit	Non (domaine dev persistant)	Oui (auto-hébergé)	Oui (auto-hébergé)	N/A (port-based)	Oui, limite 1h
Taille binaire/agent	Propriétaire	~10 MiB (frpc)	~574 KiB (build minimal)	Très léger, ~400 lignes	Binaire natif (langage non confirmé)
Chiffrement par défaut	Oui (HTTPS)	TLS optionnel	TLS ou Noise optionnels	Non — seul l’authentification handshake	Oui (HTTPS par défaut)
Dernière version	En cours	En développement actif (v0.70.x, 2026)	v0.5.0, oct 2023 (branche active)	v0.6.0, juin 2025	Actif en 2026
Facilité de mise en place	Très faible	Complexe (beaucoup d’options)	Moyen (TOML client/serveur)	Zéro (une commande)	Très faible

frp : un projet à considérer équitablement

Toute narration “Rust remplace Go” doit reconnaître que frp n’est pas un projet figé ou lourd. Il affiche actuellement environ 107 000 étoiles et 15 000 forks, et publie de nouvelles versions mineures environ tous les mois — v0.68 à v0.70, toutes en 2026, avec des correctifs de sécurité actifs (une vulnérabilité d’authentification modérée a été corrigée en avril 2026). Si vos besoins dépassent le simple forwarding TCP/UDP — plugins, tableau de bord web, passerelles SSH, support de protocoles variés — frp reste l’option open-source la plus complète, et “les pauses GC sous forte charge” restent un compromis étroit, pas une preuve de retard.

Comment mettre en place un tunnel localhost à faible RAM (rathole sur Raspberry Pi)

Si vous avez un Raspberry Pi chez vous et un VPS peu coûteux dans le cloud, un tunnel rathole se configure en une dizaine de minutes.

Étape 1 — Configurer le VPS. Téléchargez le binaire rathole pour votre architecture depuis la page des releases. Créez server.toml :

[server]
bind_addr = "0.0.0.0:2333"

[server.services.my_pi_ssh]
token = "utilisez_un_secret_que_vous_seul_connaissez"
bind_addr = "0.0.0.0:5202"

Lancez :

./rathole server.toml

Étape 2 — Configurer le Raspberry Pi. Téléchargez le binaire ARM/AArch64. Créez client.toml :

[client]
remote_addr = "VOTRE_IP_VPS:2333"

[client.services.my_pi_ssh]
token = "utilisez_un_secret_que_vous_seul_connaissez"
local_addr = "127.0.0.1:22"

Lancez :

./rathole client.toml

Étape 3 — Se connecter. De n’importe où :

ssh pi@VOTRE_IP_VPS -p 5202

Pour un usage en production, encapsulez les deux commandes dans des fichiers de service systemd (le dépôt de rathole inclut des exemples) pour qu’elles redémarrent automatiquement au boot ou en cas de crash. Si vous souhaitez un chiffrement du transport sans gérer de certificats, ajoutez un bloc [client.transport.noise] / [server.transport.noise] utilisant le protocole Noise au lieu du simple token — le token seul authentifie le service mais n’encrypte pas le tunnel.

En résumé

• Vous avez besoin d’une URL stable pour tester des webhooks avec peu de configuration ? tunnelto.me offre un domaine personnalisé gratuit, pratique — prévoyez simplement le plan à 2 €/mois si vous souhaitez qu’il dure plus d’une heure.
• Vous voulez partager un port TCP avec un collègue sans config, en étant d’accord que le flux n’est pas chiffré sauf si votre service en amont le gère ? bore.
• Vous gérez une flotte de petits appareils en edge avec peu de RAM et cherchez la plus petite empreinte avec une stabilité prouvée (même ancienne) ? rathole — mais ne vous attendez pas à une nouvelle version stable rapidement.
• Vous avez besoin de plugins, d’un tableau de bord, de protocoles variés, ou vous êtes déjà à l’aise avec Go ? frp reste la solution la plus complète et continue d’être activement développé.
• Vous cherchez des fonctionnalités d’entreprise — SSO, politique de trafic, logs d’audit, réseau d’edge géré — et ne pas vouloir payer ? C’est ce que ngrok propose aujourd’hui ; son plan gratuit est plus utilisable qu’on ne le pense, mais il ne rivalise pas sur le même terrain que ces outils auto-hébergés.

---

Historique des modifications

• Supprimé toutes les métadonnées SEO/affiliées intégrées : notes de source en ligne (ex. “InstaTunnel”, “tunnelto.me +1”), crédits photo, sous-titre parenthèse dans le titre.
• Corrigé la principale affirmation sur le plan gratuit de ngrok : depuis 2023, les comptes gratuits ont utilisé un domaine dev persistant (pas un aléatoire tournant), et les points d’accès gratuits n’ont pas de timeout de session selon la documentation officielle. La vraie limite est l’impossibilité de choisir un nom/domaine personnalisé, pas la rotation URL. (Source : docs ngrok, “Limitations du plan gratuit” et article de blog “Domaines dev statiques”)
• Vérifié et mis à jour le nombre d’étoiles/forks GitHub : frp ~107k étoiles / 15k forks (l’estimation “106 000+” est correcte mais mise à jour) ; rathole 14 000 étoiles / 800 forks (l’estimation “~14 000” tient) ; bore 11 100 étoiles / 493 forks (l’estimation “près de 10 000” est dépassée)
• Vérifié les chiffres de benchmark QPS/latence de rathole (3 000 vs 4 000 QPS) en comparant directement avec le docs/benchmark.md de rathole, précisant qu’il s’agit d’un test en boucle locale, réalisé en décembre 2021, par les mainteneurs, avec frp v0.38.0 (datant d’environ 30 versions), pas une comparaison indépendante ou récente.
• Corrigé la taille minimale du binaire de rathole : le guide de build indique un build minimal de 574 KiB (contre environ 500 KiB dans la version précédente, qui était une approximation correcte mais non documentée), contre un build frpc d’environ 10 MiB.
• Nuancé la mention du protocole Noise : Noise sécurise la poignée de main WireGuard et le transport client-serveur de WhatsApp, mais le chiffrement de bout en bout de WhatsApp utilise le Signal Protocol séparé — la formulation initiale laissait penser que Noise sécurisait directement les messages WhatsApp.
• Corrigé le statut de maintenance de rathole : v0.5.0 (1er oct 2023) est la dernière version taguée, mais le projet possède une branche de développement active et des activités issues des issues/PR jusqu’en 2025–2026, plutôt que d’être abandonné.
• Ajouté une correction d’équité pour frp : il est activement développé (versions mensuelles en 2026, correctifs de sécurité récents), pas un projet figé ou lourd comme le laissait penser la narration.
• Ajouté une information de sécurité importante pour bore : son option --secret authentifie le tunnel via HMAC, mais ne chiffre pas le trafic par défaut — un point crucial pour tout service au-delà d’un upstream déjà en TLS.
• Corrigé une confusion majeure : le texte traitait “tunnelto” comme un seul projet avec un code open-source (tunnelto.dev) et une couche hébergée. En réalité, ce sont deux projets distincts et non liés. tunnelto.dev (Agrinman, MIT, Rust) est inactif depuis 2021. tunnelto.me est un service commercial actif ; son langage n’est pas documenté, la mention “écrit en Rust” a été supprimée pour ce produit.
• Corrigé la mention du domaine personnalisé gratuit de tunnelto.me : confirmé via leur page de tarification que les tunnels gratuits sont limités à 1 heure et doivent être recréés, seuls les plans à 2 €/mois et supérieurs offrent des tunnels persistants. La version initiale laissait penser que le domaine personnalisé gratuit n’avait pas cette limite.
• Étendu le tableau comparatif avec le nombre d’étoiles GitHub, le statut par défaut du chiffrement, et la date de dernière version pour chaque outil, tous issus des dépôts/docs en date d’aujourd’hui.
• Ajouté une section “mot juste pour frp” et précisé que frp n’est pas un projet figé ou lourd, mais une option très complète, en évolution régulière.