ngrok vs. zrok : L'alternative Zero-Trust, Peer-to-Peer pour le tunneling moderne

Depuis près d’une décennie, lorsqu’un développeur devait exposer instantanément une application locale ou un webhook interne au public, il tapait une seule commande dans son terminal : ngrok http 8080.

Pendant des années, cela suffisait. Mais le paysage DevOps et sécurité moderne a évolué. Avec une attention croissante à la souveraineté des données, la conformité, et la défense du périmètre d’entreprise, router des API internes sensibles, des jeux de données locaux ou des microservices via un proxy cloud tiers centralisé devient une préoccupation de conformité pour les équipes réglementées. Ajoutez à cela les changements de tarification et de quotas de ngrok en février 2026 — qui ont significativement resserré le niveau gratuit — et il n’est pas surprenant que les développeurs cherchent de plus en plus d’alternatives.

Entrez zrok. Basé sur le framework open-source OpenZiti de NetFoundry, zrok est une plateforme de partage peer-to-peer (P2P) et de tunneling Zero-Trust. Il supporte pleinement le workflow traditionnel de “URL publique”, mais inverse aussi le paradigme d’ingress en proposant des tunnels privés, peer-to-peer, qui ne touchent jamais Internet public.

Ce guide décompose les différences architecturales, financières et philosophiques entre ngrok et zrok — et met à jour quelques affirmations qui ne tiennent plus en 2026.

La Divergence Architecturale Principale

Proxy Cloud Traditionnel (ngrok)

Le tunneling traditionnel repose sur un modèle relais client-serveur centralisé. Lorsqu’une session démarre, une connexion sortante persistante est établie avec un nœud relais public. Le fournisseur fournit un domaine accessible publiquement, et tout trafic entrant envoyé à cette URL atteint les serveurs cloud du fournisseur, est inspecté, puis routé vers votre machine.

Cette architecture comporte trois compromis bien connus :

• Souveraineté des données : votre charge utile — une requête d’authentification, une requête brute à une base de données, des données clients propriétaires — transite par un relais tiers.
• Point de défaillance unique : si la région cloud du fournisseur connaît une panne, vos points d’accès externes sont indisponibles, peu importe la disponibilité de votre machine.
• Pénalités de latence : le trafic effectue un voyage multi-sauts vers une passerelle centralisée puis en retour.

Réseau Mesh Overlay Zero-Trust (zrok)

zrok est une application “ziti-native” — elle provisionne un réseau overlay basé sur l’identité en utilisant OpenZiti plutôt qu’un simple tunnel relais. Chaque service, point d’accès, et appareil doit disposer d’une identité vérifiée, cryptographiquement signée, avant qu’une connexion ne soit demandée. Par défaut, zrok élimine les ports entrants sur votre machine locale, utilisant des connexions sortantes pour relier les nœuds.

Partage Public vs. Tunnels Privés Peer-to-Peer

Paradigme Public (Les deux outils)

Les deux outils permettent de créer une URL publique pour partager votre localhost avec Internet. En exécutant zrok share public http://localhost:8080, vous provisionnez une URL publique via le proxy frontdoor de zrok, avec TLS automatique et protections contre les payloads excessifs et injections SQL.

Une correction importante ici : zrok n’est pas immune à la friction souvent reprochée à ngrok. Les comptes zrok gratuits non vérifiés affichent également une page anti-phishing lors de la première visite d’un partage public — le même mécanisme qu’utilise ngrok. Vérifier votre compte zrok avec une carte de crédit (sans frais) la supprime, tout comme la mise à niveau d’un plan ngrok.

Paradigme Privé Peer-to-Peer (Exclusivité zrok)

Pour des microservices d’entreprise sensibles, des bases de données de staging internes ou des données d’entraînement IA classifiées, exposer une URL publique même authentifiée est souvent un risque inacceptable. C’est là que le partage privé de zrok change la donne — il crée un tunnel crypté qui ne touche ni ne s’enregistre sur Internet public.

+-----------------------+                    +-----------------------+
|  Hôte (Votre Machine) |                    | Invité (Votre Pair)   |
|                       |                    |                       |
|  [App Locale : 8080]  |                    |  [Proxy Local : 9090] |
|          ^            |                    |          ^            |
|          |            |                    |          |            |
|   (zrok share private)|                    |   (zrok access private|
+----------+------------+                    +----------+------------+
           |                                            |
           v                                            v
     [OpenZiti Identity] <====================> [OpenZiti Identity]
                         Tunnel crypté de bout en bout

Workflow :

1. Héberger la ressource privée — le hôte exécute zrok share private http://localhost:8080. Au lieu d’une URL publique, zrok retourne un jeton d’accès éphémère unique.
2. Envoyer le jeton hors bande — via un chat chiffré ou un gestionnaire de secrets interne, jamais par le canal de partage public.
3. Lier le client — le destinataire exécute zrok access private <jeton>.
4. Accès via boucle locale — zrok lance un proxy local sur la machine du destinataire, par ex. http://localhost:9090.

Puisqu’aucun enregistrement DNS public ni nœud de routage en edge n’est créé, le flux de données reste invisible pour les scanners et bots automatisés.

Comparaison Détail par Fonctionnalité

Dimension	ngrok	zrok
Modèle de licence	Proprietary / commercial, fermé	Open-source (Apache 2.0), même pour la couche OpenZiti
Architecture centrale	Relais cloud HTTP/TCP centralisé	Overlay distribué, basé sur l’identité, Zero-Trust
Auto-hébergement	Non possible — dépend du cloud ngrok	Entièrement supporté — Docker, binaire Linux, “Raspberry Pi à l’échelle d’entreprise”
Partage privé	Non disponible — tous les points d’accès sont publics	Partage privé P2P natif, aucun point d’accès public créé
URL gratuite persistante	Oui, depuis 2023 — chaque compte gratuit a un “domaine dev” statique	Oui, via partages réservés/nommés
Limites du niveau gratuit	1 Go/mois de transfert, 3 points d’accès en ligne, 20 000 requêtes/mois, 5 000 connexions TCP	5 Go/jour de transfert, 25 environnements, 50 backends de partage, 50 frontaux d’accès privé
Interstitiel de première visite (compte gratuit non vérifié)	Oui	Oui
Utilitaires additionnels	Inspection de Webhook, replay de requêtes, OAuth	Partage de fichiers/disques intégré, tunnels HTTP/TCP/UDP, lecteurs WebDAV

Tarification, Bande Passante et Correction sur le Niveau Gratuit de ngrok

Le brouillon initial répète des idées anciennes sur le niveau gratuit de ngrok — que les tunnels “expirent fréquemment” et que les URLs “rotent à chaque initialisation”. Aucun n’est plus vrai, et il est important d’être précis sur ce qui a changé et quand.

Ce qui n’est plus vrai : la documentation de ngrok indique explicitement que le niveau gratuit “n’a PAS de timeout sur les endpoints” — vous pouvez faire fonctionner un endpoint gratuit en tâche de fond indéfiniment. Et depuis que ngrok a déployé des “domaine dev” statiques gratuits (changement introduit en 2023 et renforcé lors de la restructuration tarifaire en 2026), chaque compte gratuit possède un sous-domaine persistant comme your-name.ngrok-free.dev qui ne change pas au redémarrage de l’agent. La douleur classique des URLs de webhook cassées à chaque redémarrage de ngrok est donc éliminée pour le workflow gratuit par défaut.

Ce qui est vrai, et constitue le vrai problème en 2026 : ngrok a considérablement resserré ses quotas en février 2026. Le plan gratuit actuel limite à 1 Go de transfert par mois, 20 000 requêtes HTTP, 5 000 connexions TCP, et 3 points d’accès en ligne simultanés — sans domaines génériques ou personnalisés, ni endpoints TLS sur la version gratuite. Pour un développeur solo testant occasionnellement des webhooks, cela suffit ; pour des flux importants, les équipes se tournent rapidement vers le plan Hobbyist (8–10$/mois) ou Pay-as-you-go (20$/mois + usage).

La Liberté Open-Source avec zrok

Parce que zrok (et la couche OpenZiti qui l’alimente) est sous licence Apache 2.0, les développeurs gardent un contrôle total sur leur chemin d’ingress. La version gratuite gérée par NetFoundry sur zrok.io inclut actuellement :

• 5 Go de transfert quotidien
• Jusqu’à 25 environnements (utilisateur ou service activé sur un appareil)
• 50 backends de partage (éphémères ou réservés)
• 50 frontaux d’accès privé
• La page d’interstitiel de première visite supprimée après vérification par carte (sans frais)

Pour les environnements réglementés — HIPAA, GDPR, SOC 2 Type II — le binaire unique de zrok permet d’exécuter l’ensemble du plan de contrôle sur votre propre VPS ou infrastructure cloud privée, conservant la propriété des chemins de transmission, métriques, et stockages d’identité.

zrok v2.0 : Quoi de Neuf en Mars 2026

zrok a lancé une version majeure v2.0 en mars 2026, et il est utile de le souligner car de nombreux tutoriels existants (y compris certains de la version initiale sur laquelle cet article est basé) font encore référence à la syntaxe v1 :

• Le binaire est désormais zrok2, pas zrok. Les deux peuvent fonctionner côte à côte sur la même machine — v2 utilise son propre répertoire d’environnement (~/.zrok2), son propre préfixe de variables d’environnement (ZROK2_*), et ses propres unités systemd, donc la mise à jour ne perturbe pas une configuration v1 existante.
• La réservation réservée a été remplacée par un modèle de namespace/names. Les anciennes commandes zrok reserve / zrok release / zrok share reserved ont disparu ; zrok2 create share et zrok2 delete share pré-allouent et gèrent désormais les partages publics et privés, et zrok2 modify name -r peut promouvoir un partage éphémère en partage persistant à la volée, sans nécessiter de suppression et recréation.
• Le mode backend VPN a été supprimé. La capacité VPN hôte-à-hôte mentionnée dans la documentation ancienne et dans le brouillon initial a été retirée en v2 en raison de conflits de dépendances avec les bibliothèques TUN sous-jacentes. Si votre flux dépendait de zrok share private --backend-mode vpn, cette option n’est plus disponible — le guide de migration du VPN couvre les alternatives.

Nouveautés 2026 : Infrastructure Zero-Trust pour l’IA

Ce point mérite d’être souligné pour les équipes déjà concernées par le trafic MCP et l’infrastructure orientée agent, car c’est une extension naturelle de la conversation sur le tunneling d’ingress :

• openziti/mcp-gateway agrège plusieurs backends MCP — serveurs stdio locaux et partages zrok distants — en une seule connexion nommée pour un client IA, avec filtrage autoriser/refuser par outil et isolation de session par client (pas d’état partagé entre clients).
• ziti-mcp-server encapsule toute l’API de gestion Ziti — 209 outils couvrant identités, services, routeurs d’edge, politiques, et opérations de fabric — en un serveur MCP, permettant à un agent dans Claude Desktop, Cursor ou autres clients de gérer un réseau OpenZiti de façon conversationnelle, sans passer par la console ou REST brut.
• openziti/llm-gateway est un proxy compatible OpenAI qui effectue un routage sémantique entre OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, et Ollama, avec le trafic de routage et d’inférence transporté via l’overlay Zero-Trust plutôt que sur Internet ouvert.

Tous trois sont open-source et sponsorisés par NetFoundry, et s’appuient sur les primitives de partage privé décrites ci-dessus — un endpoint MCP peut être partagé exactement comme un backend HTTP privé, sans port d’écoute ni URL publique, ce qui renforce l’argument “dark by default” pour le tunneling en général.

Verdict : Quand utiliser lequel ?

Choisissez ngrok si : - Vous construisez un projet hobby rapide et non sensible, et souhaitez une plateforme établie et bien documentée. - Votre workflow est déjà intégré au tableau de bord ngrok, à l’inspection du trafic ou au replay de requêtes. - Votre usage reste dans la limite de 1 Go/mois et 20 000 requêtes/mois, ou vous êtes prêt à payer pour Hobbyist/Pay-as-you-go quand ce n’est plus le cas.

Choisissez zrok si : - La sécurité et la confidentialité sont prioritaires — vous devez partager des API internes ou des métriques sans jamais exposer d’endpoint public. - Vous avez besoin de souveraineté des données — un outil open-source que votre équipe peut auto-héberger dans un VPC privé. - Vous souhaitez un vrai niveau gratuit généreux — 5 Go/jour et aucune expiration forcée. - Vous voulez un partage de fichiers/disques intégré ou expérimentez une infrastructure MCP/agent Zero-Trust en parallèle de vos besoins de tunneling.

En passant de proxies cloud centralisés à des tunnels Zero-Trust vérifiés par identité, zrok offre aux équipes d’ingénierie une approche auto-hébergée, conforme, pour la connectivité d’ingress — avec le risque que, comme tout projet open-source en développement actif, son interface de commande et ses fonctionnalités (voir : suppression du VPN en v2.0) peuvent évoluer.

---

Historique des modifications

Corrections : - Suppression de l’affirmation selon laquelle les tunnels du niveau gratuit ngrok “expirent fréquemment” — la documentation ngrok confirme que le niveau gratuit n’a PAS de timeout sur les endpoints. - Suppression de l’affirmation selon laquelle les URLs gratuites ngrok “rotent à chaque initialisation” — chaque compte ngrok (gratuit inclus) possède depuis 2023 un domaine dev statique persistant ; c’était une vieille croyance, pas un vrai problème actuel. - Remplacement du langage vague sur le niveau gratuit par les limites officielles de ngrok (1 Go/mois, 3 endpoints, 20 000 requêtes, 5 000 connexions TCP), tirées de la documentation tarifaire de ngrok. - Signalement que zrok affiche aussi une page d’interstitiel lors de la première visite pour les comptes non vérifiés — l’article initial laissait entendre que c’était spécifique à ngrok. - Mention que le mode backend VPN de zrok, évoqué dans la liste d’utilitaires, a été supprimé en mars 2026 dans la version 2.0 à cause de conflits de dépendances.

Ajouts : - Une section “zrok v2.0” couvrant le renommage du binaire zrok2, le modèle de namespace/names remplaçant la réservation, et la suppression du VPN — car plusieurs tutoriels font encore référence à la syntaxe v1. - Une nouvelle section sur l’infrastructure Zero-Trust 2026 pour les agents IA : openziti/mcp-gateway, ziti-mcp-server (209 outils API Ziti exposés via MCP), et openziti/llm-gateway. - Confirmation et maintien des chiffres du niveau gratuit pour zrok (5 Go/jour, 25 environnements, 50 backends de partage, 50 frontaux d’accès privé) directement issus de la page tarifaire de zrok — ces chiffres étaient corrects dans le brouillon initial.

Suppression : - La tonalité marketing (“ultime”, “Entrez zrok”) a été atténuée là où elle exagérait. - Artéfacts de mise en forme accidentels issus du brouillon d’origine.

Sources vérifiées : documentation tarifaire ngrok (ngrok.com/docs), article sur domaines statiques gratuits ngrok, page tarifaire de zrok (zrok.io/pricing), blog tech OpenZiti (“Introducing zrok v2.0,” “zrok VPN”), changelog et releases GitHub de zrok, pages projets openziti/mcp-gateway et ziti-mcp-server, guide communautaire Better Stack sur zrok.