Funnels vs. Tunnels : Repenser ngrok, Tailscale et Cloudflare pour une infrastructure Zero-Trust

Depuis des années, des outils comme ngrok étaient la réponse par défaut à “comment mettre ce serveur local sur Internet.” Une commande, un URL HTTPS public, et c’est tout. Cette commodité est réelle, mais elle comporte un compromis que les équipes plateforme et sécurité ont de moins en moins l’aise d’accepter : un tunnel classique crée un point d’accès public, non authentifié, dès qu’il est en ligne.

L’alternative qui gagne du terrain est le réseautage maillé basé sur l’identité — réseaux overlay privés comme Tailscale, avec des mécanismes de “funnel” étroits et audités pour les rares cas nécessitant un accès public. Ce n’est pas vraiment une histoire de remplacement d’un outil par un autre ; ce sont deux réponses différentes à deux questions différentes. ngrok répond à “comment exposer ceci à n’importe qui sur Internet ?” Tailscale répond à “comment connecter les appareils de mon équipe sans rien exposer ?” Les fonctionnalités de Funnel existent précisément parce que les équipes réelles ont besoin des deux réponses, parfois dans la même journée.

---

1. Comment fonctionne réellement le tunneling traditionnel

Un outil comme ngrok exécute un agent léger sur votre machine qui ouvre une connexion sortante vers le bord cloud de ngrok. Ce bord cloud renvoie une URL publique, et toute requête à cette URL est routée via le tunnel vers votre port local. ngrok http 8080 et vous êtes en ligne en quelques secondes — cette simplicité n’a pas changé.

L’architecture est centrée sur le service : accéder à l’URL constitue le contrôle d’accès. Il n’y a pas de vérification d’identité intégrée au tunnel, sauf si vous en ajoutez une. Cela a quelques conséquences pratiques pour les équipes :

1. Il contourne le pare-feu par conception. C’est le but d’un tunnel — mais cela signifie aussi qu’un tunnel non autorisé est une voie non surveillée dans le réseau.
2. Les URLs aléatoires ne constituent pas une barrière de sécurité. Elles peuvent être devinées par scanner au fil du temps, et si le service sous-jacent n’a pas d’authentification propre, celui qui trouve l’URL y a accès.
3. Il peut devenir discrètement du Shadow IT. Les données transitant par un tunnel dont une équipe de sécurité ignore l’existence compliquent la conformité SOC 2, HIPAA ou GDPR.

Rien de tout cela ne rend ngrok dangereux à utiliser — cela en fait un outil à privilégier pour l’usage externe (démos publiques, webhooks clients) plutôt qu’interne (environnements de staging internes, partage entre collègues).

---

2. La transition Zero-Trust : le réseautage maillé basé sur l’identité

Les outils de réseautage maillé comme Tailscale prennent la configuration opposée par défaut. Au lieu d’une URL publique accessible à tous, chaque appareil s’authentifie (généralement via votre fournisseur SSO) et rejoint un réseau overlay privé — un “tailnet”. Les appareils communiquent via WireGuard, et un appareil non authentifié au tailnet ne peut ni résoudre ni atteindre quoi que ce soit dessus, encore moins voir qu’un service existe.

Une nuance importante : le trafic Tailscale est peer-to-peer lorsque la traversée NAT réussit, mais ce n’est pas toujours un saut direct. Lorsque deux appareils ne peuvent pas établir de chemin direct (courant derrière des NAT restrictifs ou pare-feux d’entreprise), Tailscale utilise sa propre infrastructure de relais — les serveurs DERP — pour transporter le trafic chiffré. La charge utile reste chiffrée de bout en bout dans tous les cas, mais dire que “ça ne touche jamais un serveur central” est une légère exagération sur le comportement réel du réseau.

La proposition de valeur principale reste : l’accès dépend de l’appartenance au tailnet, pas d’une URL devinée, et chaque connexion est liée à une identité authentifiée plutôt qu’à une requête anonyme.

---

3. Funnel Tailscale vs. ngrok : deux architectures, deux philosophies

ngrok est conçu pour le cas où vous souhaitez que l’internet public atteigne votre service — tests de webhooks, démo à quelqu’un sans VPN, ou accepter des connexions entrantes depuis des environnements clients. Son inspecteur de trafic, la rejoue de requêtes, et le moteur de Traffic Policy (son couche de règles programmable pour l’authentification, la réécriture, et la limitation de débit) restent très efficaces pour le débogage du trafic API en direct.

Tailscale part du principe opposé : privé par défaut, c’est fondamentalement un réseau maillé appareil-à-appareil, pas un outil d’entrée publique.

Funnel est la réponse de Tailscale à ce besoin occasionnel de franchir cette frontière : une fonctionnalité qui route le trafic internet public vers un nœud spécifique de votre tailnet. Voici quelques points importants si vous envisagez de l’utiliser en production :

• C’est encore une fonctionnalité en bêta. Selon la documentation de Tailscale début 2026, Funnel reste en bêta — utilisable et raisonnablement mature, mais sans SLA de support formel. À signaler à une équipe de sécurité avant de le considérer comme une infrastructure permanente.
• Les ports sont strictement limités. Funnel n’écoute que sur 443, 8443, ou 10000, et uniquement via TLS. Ce n’est pas une configuration souple — c’est une règle imposée. Tailscale provisionne automatiquement le certificat TLS pour votre nom *.ts.net.
• La bande passante est plafonnée, et ce plafond n’est pas publié. Tailscale décrit le trafic Funnel comme soumis à des limites de bande passante non configurables, sans préciser le chiffre.
• Le même port ne peut pas faire Serve et Funnel en même temps. La dernière commande qui touche le port l’emporte — configurez-le en serve pour le seul tailnet ; en funnel pour le public. Il n’y a pas d’état intermédiaire accidentel.
• ngrok n’a pas d’équivalent pour la restriction de port. Il supporte tout trafic TCP/UDP arbitraire sur pratiquement n’importe quel port, ce qui explique pourquoi il (ou des spécialistes du tunneling UDP pour le gaming/VoIP) reste supérieur pour tout ce qui n’est pas HTTPS.

---

4. Partage localhost Zero-Trust : un workflow pratique

Supposons qu’un développeur frontend doit partager localhost:3000 avec un testeur QA et un PM.

L’ancienne méthode : ngrok http 3000, puis coller l’URL dans Slack. Si quelqu’un oublie de fermer le terminal, cette URL — et tout ce qui tourne derrière — reste accessible à quiconque la trouve, tout le week-end si nécessaire. (Pour info, le niveau gratuit de ngrok ne force pas la fermeture des sessions après un temps fixe comme souvent décrit en ligne — plus d’explications sur cette idée reçue dans un instant. Le vrai risque n’est pas le timeout, mais que rien ne ferme la porte pour vous.)

La méthode Zero-Trust, avec la syntaxe CLI actuelle : Tailscale a changé sa syntaxe de commandes Serve/Funnel en version 1.52 — les tutoriels plus anciens utilisant tailscale serve --port 3000 sont en syntaxe pré-1.52 et échoueront ou seront automatiquement traduits avec un message de dépréciation. La syntaxe actuelle ressemble à ceci :

tailscale serve https / http://localhost:3000

Cela lie l’application locale à l’adresse de votre propre tailnet (quelque chose comme https://dev-laptop.tailnet-name.ts.net) — visible uniquement pour les appareils authentifiés dans ce tailnet. Le trafic est chiffré WireGuard de bout en bout, et Tailscale peut transmettre des en-têtes d’identité pour que l’application réceptrice sache qui se connecte, sans que vous ayez besoin de construire une couche d’authentification pour le partage interne.

Si un client externe sans Tailscale a vraiment besoin d’accéder, vous pouvez élever le même port au public :

tailscale funnel 443 on

Il devient alors accessible depuis Internet sur un endpoint HTTPS géré par Tailscale — délibérément, sur un port fixe, avec une trace du fait que quelqu’un l’a activé.

---

5. Cloudflare Tunnel : l’autre alternative Funnel

Cloudflare Tunnel (fait partie de la plateforme Cloudflare One / Cloudflare Zero Trust, qui inclut aussi Access, un Secure Web Gateway, DLP, Isolation de Navigateur à Distance, CASB, et sécurité email sous une seule console) adopte une troisième approche : au lieu d’un mesh peer, il route via le edge global de Cloudflare. Le daemon cloudflared s’exécute sur votre machine ou serveur et ouvre une connexion sortante vers le centre de données Cloudflare le plus proche — pas de ports entrants, jamais. Mettez Cloudflare Access devant le tunnel et les visiteurs doivent s’authentifier via SSO avant d’atteindre votre origine.

Voici quelques changements récents à connaître si vous utilisez cloudflared aujourd’hui : Cloudflare a retiré la commande proxy-dns dans les versions de février 2026 pour corriger une vulnérabilité dans une bibliothèque DNS sous-jacente — si vous l’utilisiez comme résolveur DNS-over-HTTPS (souvent avec Pi-hole), cette utilisation doit changer ; la fonctionnalité principale de tunneling n’a pas été affectée. Par ailleurs, Cloudflare prévoit une mise à jour API en octobre 2026 qui supprimera les identifiants de route CIDR et le champ connections dans les réponses API Tunnel/Mesh, en faveur de valeurs route_id simples — pertinent si vous gérez les routes de tunnel via Terraform ou API plutôt que via le tableau de bord.

En pratique, la répartition est la suivante : Cloudflare Tunnel est souvent préféré pour publier des applications internes à une force de travail distribuée déjà derrière Cloudflare Access ; Tailscale est plus adapté pour la connectivité entre développeurs et homelab où le vrai peer-to-peer à faible latence de WireGuard est plus important qu’un edge centralisé.

---

6. Construire une infrastructure d’équipe sécurisée : ce qui a changé en 2026

Si vous planifiez cette migration, voici quelques faits importants à prendre en compte, car ils ont évolué cette année :

SCIM n’est plus une fonctionnalité réservée aux entreprises. La refonte tarifaire de Tailscale en avril 2026 (“tarification v4”) a intégré la gestion automatique des utilisateurs via SCIM, les politiques de posture des appareils, et les webhooks dans tous les plans payants en self-service — auparavant, SCIM nécessitait un contrat Enterprise. Les plans actuels sont : Personal (gratuit, jusqu’à 6 utilisateurs), Standard (8$/utilisateur/mois), Premium (18$/utilisateur/mois, ajoute SSO/SAML, logs de flux réseau, et Funnel), et Enterprise sur mesure. Si votre dernier devis pour cette migration supposait un tarif Enterprise juste pour faire fonctionner SCIM, il vaut la peine de vérifier.

Les logs d’audit de configuration sont maintenant inclus dans tous les plans payants, pas seulement le plus haut de gamme — utile pour construire la traçabilité “qui a activé Funnel et quand” que veulent vraiment les équipes plateforme.

Voici la démarche de déploiement :

• Déployer le client mesh sur les stations de travail, runners CI/CD, et serveurs de staging, intégrés à votre IdP via SSO et SCIM pour une gestion automatique.
• Activer MagicDNS pour que les utilisateurs se connectent par nom plutôt qu’IP, et écrire des ACL pour que l’accès soit limité par équipe — frontend peut accéder à staging, seul la plateforme peut SSH en prod.
• Diriger le trafic de tunneling par défaut vers Serve, et mettre Funnel derrière un attribut de nœud explicite dans votre politique ACL pour que l’exposition publique nécessite une action délibérée et enregistrée plutôt qu’une simple exécution d’un binaire par un développeur.
• Envoyer les logs de flux et d’audit vers votre SIEM pour que la visibilité qu’offre ngrok (un processus non surveillé sur un laptop) devienne la norme plutôt que l’exception.

---

7. Quand ngrok reste l’outil adapté

Ce n’est pas vraiment une comparaison à somme nulle, et il est utile d’être juste sur les cas où ngrok reste clairement supérieur :

1. Connectivité inter-organisationnelle. Si votre SaaS doit atteindre le réseau d’un client, vous ne pouvez pas lui demander de rejoindre votre tailnet. Le tunneling centré sur le service est fait pour cela.
2. Inspection approfondie du trafic. La rejoue de requêtes et l’inspecteur de ngrok restent en avance sur ce que proposent les outils maillés pour le débogage du trafic webhook ou API en direct.
3. Protocole non-HTTPS, non-TCP. Funnel est HTTPS uniquement sur trois ports fixes. Si vous avez besoin de UDP public — un serveur de jeu, VoIP, certains protocoles IoT — ngrok (ou une alternative spécialisée UDP) est l’outil, pas Funnel.

Et pour finir : la déclaration selon laquelle “le niveau gratuit de ngrok expire après 2 heures” qui circule largement en ligne n’est pas exacte selon la documentation actuelle de ngrok — le niveau gratuit n’a pas de timeout de session ; les endpoints restent actifs tant que le processus tourne, même en service en arrière-plan. Ce que le niveau gratuit impose, c’est une limite de 1 Go/mois de transfert, 3 endpoints en ligne, une page d’avertissement interstitielle lors du trafic navigateur (pouvant être contournée avec un en-tête ngrok-skip-browser-warning pour l’API ou l’usage programmatique), et pas de domaines personnalisés. Ce sont de vraies limitations — le timeout de 2 heures n’en fait pas partie.

---

8. Un regard réaliste : Zero-Trust n’est pas invulnérable

Il est tentant d’écrire cette comparaison comme “tunnels publics mauvais, mesh privé bon” et s’arrêter là. Il faut résister un peu à cette idée. En mai 2026, les bulletins de sécurité de Tailscale ont révélé une vulnérabilité de déni de service (TS-2026-008) affectant à la fois Serve et Funnel : une requête HTTP malformée avec un chemin ne commençant pas par / pouvait faire entrer la logique de correspondance des requêtes dans une boucle infinie, saturant un cœur CPU à 100% indéfiniment. Elle était livrée sans timeout pour interrompre la boucle. Tailscale l’a corrigée en faisant que la logique de correspondance du chemin se termine correctement.

Rien de tout cela ne remet en cause l’argument architectural basé sur l’accès par identité — une vulnérabilité DoS dans la couche d’entrée est un mode de défaillance différent de “n’importe qui trouve cette URL et entre”. La transparence de Tailscale dans sa divulgation est exactement ce qu’on attend d’une infrastructure de confiance pour le trafic interne. Mais cela rappelle que “Zero-Trust” désigne un modèle d’accès, pas une invulnérabilité aux bugs. Quel que soit le layer d’entrée choisi, il doit être patché, surveillé, et faire l’objet d’un plan d’action en cas de défaillance.

---

Conclusion

La transition des tunnels vers les funnels reflète surtout une évolution dans la signification de “pratique” pour une équipe : passer de “le moyen le plus rapide de rendre quelque chose public” à “le moyen le plus rapide d’envoyer quelque chose aux bonnes personnes, avec un historique.” ngrok reste la meilleure option pour l’exposition publique — connectivité client, tests de webhooks, démo à quelqu’un sans VPN. Tailscale (ou Cloudflare Tunnel, selon que votre priorité est le mesh peer-to-peer ou un edge centralisé) est la meilleure valeur par défaut pour tout ce qui est réellement interne.

Le mouvement pratique n’est pas d’interdire un outil au profit de l’autre — c’est de faire du privé par défaut la norme, et de considérer l’exposition publique comme une exception délibérée et enregistrée plutôt qu’une habitude.

---

Changelog

Changements structurels : - Suppression des métadonnées SEO, des phrases en gras répétées, et de la liste de références pseudo-citations du brouillon original ; réécriture en prose simple. - Ajout d’une nouvelle section (§8) sur la divulgation de vulnérabilité DoS de Tailscale en mai 2026, pour équilibrer — le brouillon initial n’abordait pas que les outils Zero-Trust ont aussi leur histoire de vulnérabilités.

Corrections par rapport aux sources principales : - Démenti de la fausse affirmation “ngrok free tier times out after 2 hours” — confirmé par la documentation actuelle de ngrok que le niveau gratuit n’a pas de timeout de session ; les limites réelles sont 1 Go/mois, 3 endpoints, et la page d’avertissement dans le navigateur. - Mise à jour de la structure des plans ngrok — les plans actuels sont Free / Hobbyist (8-10$/mois) / Pay-as-you-go (20$/mois + usage) / Enterprise, remplaçant l’ancien nom et prix “Personal/Pro/Enterprise”. - Correction de la syntaxe CLI de Tailscale — le brouillon utilisait la syntaxe pré-1.52 (tailscale serve --port 3000, tailscale funnel 3000) ; remplacée par la syntaxe actuelle (tailscale serve https / http://localhost:3000, tailscale funnel 443 on). - Correction de la gestion SCIM / logs d’audit — SCIM, posture des appareils, webhooks, et logs d’audit de configuration sont passés de l’option Enterprise à tous les plans payants dans la mise à jour “pricing v4” d’avril 2026 ; aussi mise à jour des noms/prix des plans (Personal gratuit/6 utilisateurs, Standard 8$, Premium 18$, Enterprise personnalisé). - Indication que Funnel de Tailscale reste une fonctionnalité en bêta début 2026 — l’original laissait entendre une version plus stable/GA. - Ajout de la nuance sur les relais DERP — le trafic Tailscale n’est pas toujours strictement peer-to-peer ; il peut passer par les serveurs relay quand la traversée NAT directe échoue, tout en restant chiffré de bout en bout. - Ajout des changements de Cloudflare Tunnel en 2026 — suppression de la commande proxy-dns (février 2026) et la mise à jour API d’octobre 2026, absentes du brouillon initial. - Confirmation de la précision : restrictions de ports de Funnel (443/8443/10000, TLS-only), limite de bande passante non publiée, comportement “dernier commandé gagne” quand Serve et Funnel ciblent le même port.

Sources vérifiées : documentation ngrok (limites, page tarifaire), documentation Tailscale (Funnel, Serve, référence CLI, bulletins de sécurité, annonce tarifaire v4), documentation Cloudflare One / Cloudflare Tunnel et changelog.