Au-delà du CLI : Intégrez Zero Trust directement dans votre code d'application

Depuis des années, la réponse par défaut à “comment exposer un service local à Internet” a été une seule commande dans le terminal : pointer un outil de tunneling sur un port et obtenir une URL publique. Ce flux de travail est rapide, mais repose sur un compromis architectural facile à négliger — un tunnel reverse-proxy standard reste une endpoint d’écoute accessible depuis Internet, découvrable par des scanners dès qu’il est en ligne.

Pour un récepteur webhook ou une démo, ce risque est acceptable. Pour un service connecté à une base de données de production, à un panneau d’administration interne ou à un endpoint de modèle propriétaire, c’est une surface d’attaque plus grande que la plupart des équipes ne choisiraient si une alternative plus simple existait.

C’est l’écart que vise l’écosystème OpenZiti — et l’outil de partage construit dessus, zrok —. Plutôt que de considérer “URL publique” comme la seule forme qu’un tunnel peut prendre, OpenZiti permet d’appliquer l’identité Zero Trust et le chiffrement à trois couches : le réseau, l’hôte ou l’application elle-même. Cet article explique comment ce modèle fonctionne, comment les modes de partage public et privé de zrok s’y inscrivent, ce qui a changé dans la version v2.0 récente, et vers où cet écosystème se dirige avec l’agent IA et l’infrastructure MCP en 2026.

Le changement architectural : déplacer la frontière de confiance

OpenZiti est une plateforme de réseau Zero Trust open-source, sous licence Apache 2.0, créée et soutenue par NetFoundry. Son principe est simple : un service réseau ne doit pas être accessible simplement parce qu’un appareil se trouve sur le bon LAN ou possède une connexion VPN ouverte. Dans un réseau OpenZiti, chaque connexion — humaine, microservice ou charge de travail automatisée — doit avoir une identité cryptographique unique (supportée par des certificats x509), et cette identité est vérifiée selon une politique explicite avant qu’une connexion ne soit établie.

Les mécanismes s’appuient sur un réseau overlay privé — une mesh de routeurs en périphérie :

• Routeurs de périphérie forment les points d’entrée et le plan de données chiffré de l’overlay. Les routeurs publics acceptent les connexions entrantes depuis Internet ; les routeurs privés peuvent être entièrement situés dans une zone de confiance.
• Chiffrement de bout en bout est appliqué par défaut. Les SDK OpenZiti utilisent TLS mutuel pour la connexion, couplé à un chiffrement basé sur libsodium du payload — le trafic reste illisible même si un routeur compromis se trouve au milieu.
• Routage intelligent recalcule les chemins à travers la mesh selon les conditions, permettant à l’overlay de contourner un routeur dégradé ou surchargé plutôt que de dépendre d’un seul saut fixe. (Une nuance : certains matériels marketing présentent cela comme “battre BGP”, mais la documentation d’OpenZiti ne fait pas cette affirmation — la sélection de chemin opère au niveau de l’overlay, au-dessus du routage Internet sous-jacent, sans le concurrencer.)

Les trois niveaux de déploiement

La documentation d’OpenZiti précise qu’il ne s’agit pas d’un seul outil avec un seul chemin d’intégration — c’est une plateforme adoptée progressivement, avec trois niveaux clairement identifiés :

1. Accès réseau Zero Trust. Un routeur de périphérie OpenZiti se trouve à la frontière d’une zone de réseau de confiance ; le trafic authentifié entre dans l’overlay et sort dans le réseau privé où résident les services legacy. Aucun changement de code, aucune modification d’application — ce modèle s’adresse aux organisations souhaitant un accès Zero Trust sans toucher à leur infrastructure existante.

2. Accès hôte Zero Trust (Tunnelers). Un tunnelier léger OpenZiti fonctionne sur le même hôte que le service cible — disponible pour Linux, Windows, macOS, iOS et Android. Le tunnelier intercepte et chiffre le trafic de façon transparente ; le service lui-même n’a besoin d’accepter que des connexions localhost. Aucun changement de code requis, mais la frontière de confiance se réduit à l’OS hôte plutôt qu’au réseau entier.

3. Accès application (SDKs). La posture la plus forte, et celle dont cet article parle réellement. Vous intégrez un SDK OpenZiti directement dans votre code client ou serveur. L’application détient l’identité cryptographique et effectue le chiffrement en interne — il n’y a pas de port d’écoute, même en boucle locale. Le service est “sombre” : rien à scanner, rien à sonder, car rien n’écoute.

Les SDKs sont disponibles pour sept langages : Go, C, Python, Node.js, Java/Kotlin, Swift, et C#/.NET (confirmé directement via openziti/ziti et les dépôts SDK par langage). Il existe aussi un SDK JavaScript pour le navigateur (dans le cadre du projet “browZer”) pour servir des applications web Zero Trust sans nécessiter d’installation client — un aspect que le cadre CLI-first de la plupart des outils de tunneling ne couvre pas vraiment.

La majorité des équipes commencent avec des tunnelers pour des services existants — déploiement en quelques minutes sans modification de code — puis évoluent vers des SDK intégrés à l’application pour des travaux neufs, à haute sécurité ou en environnement vert, où l’effort d’intégration supplémentaire réduit significativement la surface d’attaque.

zrok : La couche de partage construite sur OpenZiti

Mettre en place manuellement des identités et des routeurs de périphérie représente un vrai travail d’infrastructure, une friction que la plupart des développeurs ne veulent pas subir juste pour partager un serveur local avec un collègue. zrok existe pour supprimer cette friction — c’est un outil de partage peer-to-peer open-source, “ziti-native”, qui provisionne un overlay basé sur l’identité plutôt qu’un relais cloud simple, tout en offrant l’expérience d’obtenir une URL publique en une seule commande.

Comparatif des fonctionnalités

Fonctionnalité	Proxy cloud traditionnel (ex. ngrok)	zrok (toile OpenZiti)
Architecture principale	Relais HTTP/TCP centralisé	Overlay distribué, basé sur l’identité, Zero Trust
Licence	Proprietary, fermé	Open-source (Apache 2.0), auto-hébergable
Ports entrants	Expose un endpoint via un écouteur public	Connexions sortantes uniquement ; pas de port entrant sur votre machine
Partage de ressources	Principalement endpoints HTTP	HTTP/TCP/UDP, partage de fichiers/disques intégré, WebDAV
Niveau gratuit (service géré)	Variable selon le fournisseur	5 Go/jour de transfert, jusqu’à 25 environnements, 50 backends de partage, 50 frontaux d’accès privé
Friction à la première visite	Interstitiel anti-phishing sur comptes gratuits non vérifiés	Idem — zrok affiche un interstitiel équivalent, supprimable en vérifiant avec une carte sans frais

Ce dernier point mérite d’être souligné : zrok n’est pas exempt de la friction que certains associent uniquement à ngrok. Les deux outils affichent une page d’avertissement lors de la première visite pour se protéger contre le phishing sur des URLs éphémères en gratuit.

URL publiques vs partage privé peer-to-peer

zrok supporte le flux de travail familiarisé avec l’URL publique — zrok share public http://localhost:3000 vous donne une URL HTTPS comme https://your-share.share.zrok.io, utile pour tester un webhook Stripe ou GitHub, ou présenter une interface à un client non technique.

La différence réside dans le partage privé, qui ne crée jamais d’URL publique ni d’enregistrement DNS :

1. L’hôte exécute zrok share private http://localhost:8080 et reçoit un jeton d’accès éphémère et unique — pas une URL.
2. Ce jeton est envoyé hors bande, via un canal de confiance (chat chiffré, gestionnaire de secrets).
3. Le destinataire exécute zrok access private <jeton> sur sa machine.
4. zrok lance un proxy local (http://localhost:9090) qui tunnelise vers le service de l’hôte via l’overlay vérifié par identité.

Puisqu’aucun frontend public ni enregistrement DNS n’est créé pour un partage privé, il n’y a rien à trouver pour un scanner ou un bot — la connexion n’existe qu’entre deux endpoints authentifiés.

zrok propose aussi un SDK basé sur l’SDK Go d’OpenZiti, pour que les équipes intègrent le partage directement dans leurs outils plutôt que d’utiliser la CLI :

// charger un environnement zrok activé
root, err := environment.LoadRoot()

// demander un partage privé pour une ressource locale
shr, err := sdk.CreateShare(root, &sdk.ShareRequest{
    BackendMode: sdk.TcpTunnelBackendMode,
    ShareMode:   sdk.PrivateShareMode,
})

// accepter les connexions pour cette ressource
listener, err := sdk.NewListener(shr.Token, root)

zrok v2.0 : Quoi de neuf ?

zrok a lancé une version majeure v2.0 en 2026, et comme beaucoup de tutoriels et scripts existants font encore référence à la syntaxe v1, il est utile d’être précis sur ce qui change :

• Le binaire s’appelle désormais zrok2, pas zrok. Ce choix a été fait pour permettre à v1 et v2 de fonctionner côte à côte sans interférence, plutôt que de forcer une migration. v2 utilise son propre répertoire d’environnement (~/.zrok2 au lieu de ~/.zrok), son propre préfixe de variables d’environnement (ZROK2_* au lieu de ZROK_* — ex. ZROK2_API_ENDPOINT, ZROK2_ADMIN_TOKEN), et des paquets Linux et unités systemd séparés (zrok2, zrok2-agent, config à /etc/zrok2). Vous pouvez activer un environnement v2 neuf avec zrok2 enable sans toucher à votre setup v1.
• Les commandes de réservation ont été remplacées par un modèle de namespace/names. Les anciennes commandes zrok reserve / zrok release / zrok share reserved ont disparu. À la place, zrok2 create share et zrok2 delete share gèrent les partages publics et privés, et zrok2 modify name -r peut promouvoir un partage éphémère en partage persistant à la volée — fini de supprimer un partage pour rendre son nom permanent.
• Le mode VPN a été retiré. Les versions antérieures de zrok (et certains tutoriels, y compris la version brouillon de cet article) mentionnaient une option --backend-mode vpn pour le partage VPN hôte-à-hôte. Cette capacité a été supprimée dans v2 en raison de conflits de dépendances avec la bibliothèque TUN. Si vous utilisiez cette fonctionnalité, elle n’est plus disponible dans v2.

Installation et démarrage

Sous macOS et Linux, la formule Homebrew pour la version v2 est :

brew install zrok2

(La formule v1 zrok existe toujours séparément et fonctionne si besoin.) Sur Windows, la méthode la plus fiable est de télécharger directement la dernière version depuis la page des releases GitHub de zrok — nous n’avons pas pu vérifier un dépôt Scoop officiel maintenu pour le binaire v2 au moment de la rédaction, donc nous ne le recommandons pas comme méthode d’installation confirmée.

Une fois installé :

zrok2 invite      # s'inscrire au service gratuit zrok.io (pas de token d'invitation séparé)
zrok2 enable       # lier votre appareil à votre environnement zrok
zrok2 share public localhost:3000

Pour les équipes nécessitant une souveraineté totale des données — environnements régulés, conformité HIPAA, GDPR ou SOC 2 — zrok est entièrement auto-hébergeable. La stack Docker Compose auto-hébergée ne se limite pas à un seul conteneur : elle inclut ziti-controller et ziti-router pour le plan de contrôle/données OpenZiti, postgresql pour la base de données zrok, rabbitmq pour les mises à jour de mappage frontend, zrok2-controller et zrok2-frontend pour l’API zrok et le proxy de partage public, ainsi que des services optionnels comme caddy (terminaison TLS) et influxdb pour la métrique. C’est une infrastructure plus complexe qu’un simple binaire, à connaître si vous envisagez un déploiement auto-hébergé.

Applications concrètes

Automatisation Webhook sans règles de pare-feu entrantes

En utilisant le SDK Node.js d’OpenZiti, des équipes ont construit des workflows GitHub Actions où une pipeline CI/CD peut déclencher en toute sécurité un script de build ou de déploiement sur un serveur interne — sans que l’équipe réseau ouvre un port entrant ni gère des règles NAT.

Partage peer-to-peer de fichiers et disques

Parce que zrok résout le problème du “qui a l’adresse” de la même façon que celui du partage de service, c’est idéal pour le partage ad hoc de fichiers et le montage de dossiers partagés en WebDAV directement via l’overlay, sans mettre en place un serveur dédié.

Infrastructure Zero Trust pour agents IA et MCP

C’est la partie de l’écosystème qui évolue le plus rapidement, et où beaucoup d’anciens articles (y compris des brouillons antérieurs de ce blog) sont déjà dépassés. Mi-2026, NetFoundry a sponsorisé un petit cluster de projets open-source sous licence Apache 2.0 — il est utile d’être précis sur leur rôle, car leurs périmètres se chevauchent :

openziti/llm-gateway est un proxy API compatible OpenAI. Sa documentation décrit un routage natif vers OpenAI, Anthropic, et tout backend compatible OpenAI — Ollama, vLLM, llama-server, SGLang, etc. (Une correction : certains articles antérieurs mentionnaient un routage natif vers AWS Bedrock et Google Vertex AI. Le dépôt officiel indique support natif pour OpenAI et Anthropic, ainsi que tout backend compatible — pas d’intégrations first-party Bedrock, Vertex ou Azure OpenAI.) Il effectue un routage sémantique en cascade : heuristiques de mots-clés, puis similarité d’embedding, puis un classificateur LLM en fallback — pour choisir automatiquement un modèle si l’utilisateur n’en spécifie pas, avec équilibrage de charge pondéré et vérifications de santé sur une pool de serveurs d’inférence. C’est un seul binaire Go, sans base de données ni queue de messages, pouvant s’exposer via zrok pour atteindre un endpoint derrière NAT ou dans un réseau isolé.

openziti/mcp-gateway offre aux assistants IA un accès Zero Trust aux serveurs MCP. Il se compose de trois parties : mcp-tools connecte un client MCP à un partage zrok ou un tunnel Agora ; mcp-gateway agrège plusieurs backends de serveurs d’outils en une seule connexion nommée (ex. fs:read_file, github:create_issue) ; et mcp-bridge expose un seul serveur MCP local sur le réseau. Les backends peuvent être des processus stdio locaux ou des serveurs MCP HTTP(S)/SSE distants. Les partages peuvent être persistants, et le transport supporte stdio et HTTP Streamable.

ziti-mcp-server est un autre projet, distinct, qui expose l’API de gestion OpenZiti — environ 200 outils pour gérer identités, services, routeurs, politiques. Il permet à un agent dans Claude Desktop, Cursor, ou autre, de provisionner et gérer les routeurs et politiques via conversation, sans dépendre d’autres MCP.

openziti/agora est une nouvelle couche Zero Trust pour la communication agent-à-agent, compatible A2A, avec la couche d’identité, découverte et politique d’OpenZiti. mcp-gateway peut l’utiliser comme transport alternatif, permettant à un gateway de servir des outils via tunnels Agora et de s’y enregistrer dans un catalogue.

Ce qui relie ces quatre projets, c’est la même philosophie : un endpoint MCP ou un gateway inference peut être partagé comme un backend HTTP privé — authentifié, chiffré, sans écoute publique.

En résumé

L’utilisation d’une seule commande pour obtenir une URL publique ne disparaîtra pas, et reste souvent la solution la plus pratique pour le développement quotidien. Mais “praticité” et “exposé à Internet” ne doivent pas forcément faire bon ménage. La modélisation en couches d’OpenZiti — accès réseau sans code, tunneling hôte sans code, SDK intégré pour la sécurité maximale — permet à une équipe de choisir le compromis qu’elle souhaite, service par service, plutôt que d’appliquer une seule règle par défaut. zrok facilite l’accès aux deux premiers niveaux en quelques minutes ; les SDK sont là pour les services où “sombre par défaut” vaut l’effort supplémentaire.

---

Changelog

Corrections : - Remplacement de la phrase vague “une version majeure de zrok v2 a introduit le binaire zrok2” par les changements précis et sourcés de la v2.0 : renommage du binaire/environnement/env-var (~/.zrok2, ZROK2_*), le modèle de namespace/names remplaçant la réservation, et la suppression du mode VPN en raison de conflits de dépendances TUN. - Correction de la liste des fournisseurs de openziti/llm-gateway : la mention de support natif pour Bedrock, Vertex AI a été retirée, support natif pour OpenAI et Anthropic uniquement. - Correction et expansion de la description de mcp-gateway : séparation claire avec ziti-mcp-server, description de ses composants (mcp-tools, mcp-gateway, mcp-bridge) et de leur rôle. - Reformulation de la phrase sur le routage BGP : description plus précise, évitant de surinterpréter le niveau de couche. - Remplacement de l’instruction Windows scoop install zrok par une note indiquant l’absence de dépôt Scoop officiel vérifié.

Ajouts : - Noms précis des trois niveaux de déploiement d’OpenZiti, issus de la documentation officielle. - Section sur openziti/agora, nouvelle et non mentionnée dans la version précédente. - Support pour partages persistants et HTTP Streamable dans mcp-gateway. - Exemple de code source du pattern de partage privé avec le SDK Go. - Détail précis de la liste des services Docker Compose auto-hébergés. - Confirmation des chiffres clés : 7 langages SDK, chiffrement libsodium/mTLS, limites du niveau gratuit.

Suppression : - Suppression des phrases répétitives et du jargon excessif, pour une rédaction plus claire.

Sources vérifiées : - openziti/ziti, openziti/zrok, blogs OpenZiti, documentation NetFoundry, pages de tarification, SDKs par langage, dépôts openziti/llm-gateway, openziti/mcp-gateway, openziti/agora, et ancien article de référence.