Hébergement auto-hébergé pour la souveraineté des données : le virage open-source dans le reverse proxy

L’impératif pour l’entreprise : pourquoi les tunnels gérés ne suffisent plus

Exposer des services locaux à Internet pour les tests, webhooks ou accès à distance est une nécessité quotidienne en développement logiciel et gestion d’infrastructure. Depuis des années, des fournisseurs SaaS gérés comme ngrok et Cloudflare Tunnel sont la solution par défaut. Pour les ingénieurs en infrastructure, responsables conformité et équipes de sécurité, cependant, faire passer le trafic interne via un fournisseur SaaS tiers devient de plus en plus difficile à justifier dans un cadre réglementaire strict.

Les entreprises sous GDPR, HIPAA, SOC 2 ou FedRAMP doivent respecter une exigence de souveraineté des données : celles-ci doivent rester soumises aux lois et structures de gouvernance de la juridiction où elles ont été collectées. Lorsqu’on utilise un reverse proxy SaaS géré, vos API internes et payloads webhook transitent par des serveurs contrôlés par un tiers, parfois dans une juridiction légale différente.

Cela a entraîné une évolution vers des outils de tunneling auto-hébergés, de qualité production. Des passerelles open-source comme frp (Fast Reverse Proxy), Zrok (basé sur le réseau zero-trust OpenZiti), et Inlets pour Kubernetes permettent aux équipes d’infrastructure de garder la passerelle en interne — non seulement pour éviter les frais d’abonnement SaaS, mais aussi pour garder le contrôle sur le lieu de terminaison du trafic et qui peut l’inspecter.

Ce document examine l’état actuel de ces trois outils, leur comparaison, et où la conformité est réellement stabilisée versus encore en évolution.

---

1. Panorama de la souveraineté des données et conformité

Le problème des reverse proxies SaaS

Des outils comme ngrok en mode gestion installent un client léger sur votre réseau privé qui établit un tunnel sortant vers les serveurs de l’opérateur. Ce dernier génère une URL publique, et le trafic envoyé à cette URL est routé via l’infrastructure du fournisseur vers votre réseau. C’est pratique, mais cela soulève des enjeux de conformité :

• Résidence des données : Si un développeur en Allemagne teste une API locale via un tunnel géré dont le serveur en bordure est aux États-Unis, ce routage transfrontalier nécessite un mécanisme de transfert légal. Il faut préciser que : un transfert transatlantique n’est pas automatiquement illégal. Le Cadre de confidentialité UE–US (DPF), adopté par la Commission européenne en juillet 2023, offre actuellement une base d’adéquation pour les transferts vers des organisations américaines certifiées, et il a résisté à sa première contestation juridique devant le Tribunal général de l’UE en septembre 2025. Mais l’historique du DPF est celui d’une invalidation répétée — il a remplacé Safe Harbor (abrogé en 2015) et Privacy Shield (abrogé en 2020 par l’arrêt Schrems II) — et un nouveau recours est en cours devant la CJUE, avec une incertitude accrue suite à une décision de la Cour suprême américaine en juin 2026 sur l’indépendance des commissaires FTC, que le Comité européen de protection des données a signalée comme pertinent pour la surveillance du DPF. Pour les équipes conformité, c’est précisément pour cette raison que certaines organisations préfèrent éliminer la question transfrontalière plutôt que de s’appuyer sur un cadre qui a été invalidé deux fois.
• Terminaison TLS en bordure : Par conception, les proxies gérés de niveau 7 (HTTP) terminent TLS en bordure du fournisseur, décryptent le trafic pour le router vers le tunnel, puis le rechiffrent. Même avec un fournisseur de confiance, cela signifie qu’un tiers détient les clés de votre trafic en transit.
• Couplage de disponibilité : S’appuyer sur un fournisseur SaaS de tunnels lie vos workflows d’accès à distance et de tests webhook à leur disponibilité.
• Tarification à l’usage : La tarification SaaS par utilisateur ou par bande passante peut devenir coûteuse à mesure de la croissance de l’usage.

Approche “Apportez votre propre infrastructure” (BYOI)

Pour réduire la dépendance à des mécanismes de transfert tiers, certaines organisations auto-hébergent leur passerelle de tunneling sur leur propre infrastructure — déployant le serveur relais dans une région choisie, sous leur propre régime d’audit et de contrôle d’accès. Les trois outils ci-dessous illustrent différentes approches.

---

2. frp (Fast Reverse Proxy) : La solution robuste en métal

frp (fatedier/frp sur GitHub) est un reverse proxy écrit en Go pour exposer un serveur local derrière un NAT ou un pare-feu. C’est l’un des outils de tunneling auto-hébergés les plus déployés : à la mi-2026, le dépôt compte environ 107 000 étoiles GitHub, est utilisé par plus de 180 projets dépendants publics, et est sous licence Apache-2.0. La version stable actuelle est v0.69.1.

Architecture et souveraineté des données

frp comporte deux composants : frps, le serveur déployé sur votre infrastructure contrôlée, et frpc, le client sur la machine interne. En choisissant où déployer frps, vous contrôlez la juridiction du trafic — par exemple, déployer frps sur un serveur en eu-central-1 maintient cette étape dans les frontières allemandes/européennes.

Une nuance importante pour les lecteurs soucieux de conformité : le chiffrement de transport de frp entre frpc et frps est TLS par défaut depuis la v0.50.0, mais le chiffrement et la compression au niveau payload pour chaque proxy (transport.useEncryption, transport.useCompression) sont désactivés par défaut et doivent être explicitement activés par proxy. L’auto-hébergement de frp vous donne automatiquement un contrôle juridictionnel ; cela ne maximise pas automatiquement le chiffrement sans configuration.

Fonctionnalités pertinentes pour l’usage en entreprise

• Support des protocoles : TCP, UDP, HTTP, HTTPS, et STCP.
• STCP et XTCP pour zéro exposition publique : STCP (Secret TCP) permet d’enregistrer un service avec frps sans ouvrir de port public — un client visiteur autorisé doit présenter une clé pré-partagée pour se connecter. XTCP va plus loin, utilisant la technique NAT hole-punching basée sur STUN pour tenter une connexion peer-to-peer directe, en revenant à STCP si le NAT ne supporte pas.
• Pool de connexions et multiplexage : frps peut maintenir un pool de connexions préétablies pour réduire la latence par requête, et le multiplexage de flux TCP est supporté depuis la v0.10.0.
• Modes de transport KCP et QUIC, un tunnel SSH (ajouté en v0.53.0) permettant aux clients de se connecter via ssh -R sans lancer frpc, et une fonctionnalité alpha VirtualNet (basée sur TUN) pour le routage IP entre pairs.
• Format de configuration : Depuis la v0.52.0, frp utilise TOML, YAML ou JSON ; le format INI legacy est déprécié et ne reçoit plus de nouvelles fonctionnalités.

Il est aussi à noter que les mainteneurs de frp travaillent sur une réécriture en cours, non encore publiée, v2 — un proxy L4/L7 plus proche d’Envoy — décrite dans le README du projet comme nettement plus complexe que prévu, sans date de sortie ferme.

Quand choisir frp

frp convient aux équipes recherchant un relais flexible, protocole-indépendant, entièrement auto-hébergé, et à l’aise avec la gestion de leur propre serveur et configuration TLS. C’est une alternative raisonnable à un VPN traditionnel quand vous avez besoin d’un accès distant ciblé, par service, plutôt qu’une connectivité réseau complète.

---

3. Zrok : Réseau zero-trust basé sur OpenZiti

Zrok est développé par NetFoundry et construit sur OpenZiti, leur overlay réseau zero-trust open-source. Plutôt que de transférer des ports, Zrok établit une couche cryptée basée sur l’identité entre points d’accès — dans le modèle OpenZiti, il n’y a pas de ports d’écoute sur Internet public, et l’accès est accordé par identité cryptographique plutôt que par IP.

Changement majeur de version : v2.0 / zrok2

Zrok a lancé une version majeure v2.0 en mars 2026. Si vous avez suivi des tutoriels plus anciens, la syntaxe de commande a changé :

• Le binaire est maintenant zrok2, pas zrok. Les deux peuvent coexister — v2 utilise son propre répertoire d’environnement (~/.zrok2), son propre préfixe d’environnement (ZROK2_*), et ses propres unités systemd, donc la mise à jour ne perturbe pas une installation v1.
• Le partage réservé a été remplacé 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 gèrent désormais les partages publics et privés, avec un drapeau --share-token sur zrok2 share private pour un token de vanity persistant.
• Une nouvelle commande zrok2 access dynamicProxy a été ajoutée, qui reçoit directement les mises à jour de mappage de noms du contrôleur plutôt que d’analyser l’en-tête Host.

Partage public vs privé

Zrok supporte deux modes de partage :

1. Partage public (zrok2 share public <cible>) génère une URL HTTPS publique — utile pour des intégrations tierces comme Stripe ou GitHub webhooks nécessitant un endpoint public classique.
2. Partage privé (zrok2 share private <cible>) génère un token de partage au lieu d’une URL. Un collaborateur ou pipeline CI/CD exécute zrok2 access private <token> pour accéder au service. Aucun enregistrement DNS public ni port ouvert n’est créé, et le trafic circule de bout en bout via la toile OpenZiti entre les deux points — un routeur relayant le trafic pour contourner un NAT strict ne peut pas le déchiffrer, car les clés de chiffrement sont détenues uniquement aux points d’accès.

Zrok supporte aussi un mode de permission “fermé” (--closed, ajouté en v0.4.26 et repris en v2) qui limite un partage aux environnements appartenant au compte qui l’a créé, avec une option --access-grant pour autoriser certains comptes additionnels.

Hébergé vs auto-hébergé, et tarification

Zrok est sous licence Apache-2.0 et peut être auto-hébergé sur Linux, Docker ou Kubernetes, ou utilisé comme service hébergé sur zrok.io (rebaptisé commercialement “zrokNET” sur la page tarifaire de NetFoundry, avec un niveau gratuit offrant 5 GB/jour, 25 environnements, 50 backends de partage, et 50 interfaces privées à l’écriture). L’auto-hébergement supprime totalement les limites d’usage mais nécessite de déployer votre propre contrôleur OpenZiti — un effort opérationnel supérieur à celui d’un serveur frp.

Quand choisir Zrok

Zrok convient aux organisations recherchant un contrôle d’accès zero-trust, basé sur l’identité, et souhaitant que les partages privés ne touchent jamais Internet public. Étant une base de code plus récente et en évolution active, il faut prévoir une migration de v1 à v2 si vous démarrez ou mettez à jour une déploiement existant.

---

4. Inlets : La gamme de produits de tunneling Kubernetes

Inlets a été créé par Alex Ellis, également fondateur d’OpenFaaS. Il cible les équipes devant exposer des services depuis des clusters sans IP publique — Kubernetes bare-metal, clusters Raspberry Pi ou sites en périphérie — en créant un tunnel sortant du cluster privé vers un “nœud de sortie” léger dans une région cloud publique de votre choix.

Correction de licence : Inlets n’est pas un tunnel open-source

Il est important de préciser que le binaire inlets-pro est propriétaire, logiciel commercial fermé. Selon la FAQ du projet, seul inlets-operator et inletsctl — l’outil d’orchestration qui provisionne les VM de nœud de sortie et configure le tunnel — sont sous licence MIT. Le binaire inlets-pro qui transporte réellement le trafic nécessite une clé de licence payante (tiers personnel, commercial ou entreprise) délivrée par OpenFaaS Ltd., sous EULA commercial, et ne fonctionnera pas sans. La version initiale open-source inlets (HTTP-only, sans automatisation TLS) existe toujours dans l’historique du projet mais a été remplacée par inlets-pro et n’est plus activement maintenue.

Cela ne disqualifie pas Inlets pour une discussion sur la souveraineté des données — vous choisissez toujours où se trouve le nœud de sortie, et le trafic peut être chiffré de bout en bout sans que le fournisseur détienne les clés — mais cela signifie qu’Inlets se rapproche du modèle commercial ngrok plutôt que de l’open-source complet de frp ou Zrok. Si “pas de relation fournisseur ni coût de licence” est une exigence absolue, Inlets ne la remplit pas ; si “auto-hébergé avec contrôle sur la région” est la priorité, alors oui.

Souveraineté des données et architecture

En choisissant la région cloud du nœud de sortie, vous contrôlez où le trafic se termine géographiquement. Inlets supporte le tunneling L4 (TCP) et L7 (HTTP) ; avec inlets-pro en mode L4, la terminaison TLS se fait dans votre cluster (par exemple, à un contrôleur d’entrée interne), et le nœud de sortie relaye des octets chiffrés qu’il ne peut pas inspecter.

L’opérateur Inlets

inlets-operator, opérateur Kubernetes sous licence MIT, surveille les objets Service de type LoadBalancer. Lorsqu’un apparaît, au lieu de provisionner un load balancer cloud coûteux, il lance une VM de nœud de sortie légère sur un fournisseur de votre choix (DigitalOcean, Hetzner, AWS, etc. via API), configure le tunnel, et le relie au pod interne.

La gamme de produits actuelle (2026)

Inlets s’est étendu au-delà de l’outil CLI initial en une petite famille de produits : Inlets Pro (tunnels auto-hébergés, sous licence), Inlets Cloud (offre de tunnel managé avec HTTPS/SSH intégré), et Uplink (couche de contrôle Kubernetes plus récente pour les fournisseurs SaaS qui doivent connecter de nombreux environnements clients à un plan de contrôle partagé, plutôt que l’usage en mode multi-locataire auto-hébergé).

Quand choisir Inlets

Inlets convient aux équipes fortement Kubernetes qui veulent la simplicité opérationnelle d’un déploiement automatisé de nœud de sortie, et sont prêtes à payer une licence commerciale pour cette commodité et support. Les équipes évitant tout coût de licence fournisseur préféreront frp ou Zrok.

---

5. La nouvelle frontière : tunneling zero-trust pour agents IA et serveurs MCP

Le tunneling souverain des données s’étend de plus en plus à une nouvelle catégorie de trafic : agents IA et serveurs MCP (Model Context Protocol) qui accèdent à des outils internes. C’est une évolution réellement nouvelle en 2026, pas encore une pratique établie, mais à considérer.

En mars 2026, NetFoundry a annoncé une extension d’OpenZiti en ce qu’elle appelle un “enclave IA” — des gateways zero-trust spécifiquement pour le trafic agent et LLM :

• openziti/mcp-gateway agrège et expose des outils MCP via l’overlay OpenZiti (ou Zrok) au lieu d’un processus stdio local ou d’un endpoint HTTP en écoute publique. Il nécessite zrok v2.0.x ou supérieur, illustrant la forte intégration entre ces projets.
• Un gateway LLM associé fournit un proxy compatible OpenAI avec routage sémantique entre fournisseurs (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex AI, Ollama, autres endpoints compatibles OpenAI), authentifié avec la même identité OpenZiti utilisée pour l’accès aux outils MCP — objectif : une identité, une piste d’audit, pour les appels modèles et outils.
• ziti-mcp-server, publié à peu près au même moment, est un serveur MCP — il expose environ 200 outils via l’API de gestion OpenZiti à tout client MCP (Claude Desktop, Cursor, etc.), permettant à un agent de gérer identités, services et politiques sur un réseau Ziti via des requêtes en langage naturel, authentifiées comme un opérateur humain.

Pour les lecteurs suivant l’infrastructure IA : c’est la première illustration claire d’un fournisseur de tunneling construisant une infrastructure spécifique pour le trafic agent, plutôt que de réutiliser un tunnel généraliste. C’est encore en développement — ces projets ont été lancés en même temps que Zrok v2.0 et évoluent — mais c’est un signal que les fournisseurs de tunneling zero-trust voient la connectivité agent-outil comme un problème distinct, nécessitant un tooling dédié, pas seulement du “tunneling webhook avec étapes supplémentaires”.

---

6. Matrice comparative

Fonctionnalité / Exigence	frp	Zrok (OpenZiti)	Inlets
Cas d’usage principal	Tunneling TCP/UDP générique, bare-metal	Partage zero-trust, basé sur l’identité, public et privé	Ingress Kubernetes, tunneling cloud-native L4/L7
Licence	Open source complet (Apache-2.0)	Open source complet (Apache-2.0)	Outils d’orchestration (inlets-operator, inletsctl) MIT ; binaire inlets-pro propriétaire et commercial
Modèle de sécurité	Redirection de ports ; secrets STCP/XTCP pré-partagés	Overlay zero-trust ; E2EE entre points sur partages privés	Tunnel WebSocket sortant ; passage L4 avec terminaison TLS interne
Chiffrement par défaut	TLS entre frpc/frps depuis v0.50.0 ; chiffrement payload optionnel par proxy	End-to-end sur partages privés par conception	Dépend du mode de tunnel ; mode L4 conserve TLS interne terminée
Souveraineté des données	Élevée — auto-hébergé, région choisie	Élevée — auto-hébergé ou hébergé, E2EE sur partages privés	Modérée à élevée — région du nœud de sortie choisie, dépend d’un fournisseur commercial
Support Kubernetes natif	Configuration manuelle	Conteneurisable, nécessite setup	Opérateur natif avec provisioning automatique
IP public requis	Oui pour frps	Non pour partages privés	Oui pour le nœud de sortie
Complexité opérationnelle	Modérée	Plus élevée — nécessite contrôleur OpenZiti ou migration v1→v2	Faible à modérée — automatisée via opérateur

---

7. Bonnes pratiques pour une stratégie de tunneling auto-hébergée

1. Ne pas supposer que l’auto-hébergement est automatiquement chiffré. Comme pour frp, TLS transport peut être activé par défaut, mais le chiffrement payload individuel ne l’est pas nécessairement. Vérifiez les paramètres par défaut de chaque outil.
2. Terminez TLS en interne si possible. Utiliser le mode L4/TCP en passant par un contrôleur d’entrée interne, et terminer TLS à cet endroit, évite que votre relais ne détienne du trafic déchiffré.
3. Placez les relais dans la région requise par votre conformité, et documentez pourquoi — cela est crucial en cas de contrôle ou d’audit.
4. Auditez régulièrement l’accès. Pour frp, vérifiez allowPorts. Pour Zrok, vérifiez les grants et tokens, et changez-les périodiquement.
5. Surveillez le trafic du tunnel comme tout autre point d’entrée. Intégrez les logs à votre SIEM, utilisez Prometheus ou OpenTelemetry. L’auto-hébergement supprime un fournisseur, mais le tunnel reste une porte d’accès à votre réseau privé.

---

Conclusion

Les tunnels SaaS gérés offrent une commodité, mais avec des compromis de conformité — surtout pour les organisations sous régimes stricts. La légalité des transferts transfrontaliers dépend des mécanismes comme le DPF, et le fait d’auto-héberger ne garantit pas un trafic plus chiffré par défaut. Il faut vérifier la configuration.

Ce que permettent frp, Zrok et Inlets, c’est de choisir précisément où le tunnel se termine, et dans le cas de Zrok, d’éviter tout endpoint public pour le partage interne. Parmi eux, frp et Zrok sont véritablement open source sans coût de licence ; Inlets privilégie une automatisation Kubernetes avec support commercial. Le choix dépend de la priorité : flexibilité protocolaire (frp), contrôle zero-trust (Zrok), ou automatisation Kubernetes supportée (Inlets).

---

Changelog

Corrections : - Clarification sur la légalité des transferts transfrontaliers sous GDPR/Schrems II, contexte actualisé avec le DPF (adopté juillet 2023, validé septembre 2025, appel en cours, surveillance accrue depuis juin 2026). - Précision sur la licence d’Inlets : seul inlets-operator et inletsctl sont MIT, le binaire inlets-pro est propriétaire et nécessite une licence payante. - Mise à jour de la syntaxe et des concepts de Zrok : version 2.0 en mars 2026, changement de nom du binaire, suppression du modèle de partage réservé. - Clarification que TLS de transport de frp est par défaut depuis v0.50.0, mais chiffrement payload et compression sont optionnels. - Langage neutre, suppression de termes promotionnels.

Ajouts : - Faits actuels sur frp : ~107k étoiles, Apache-2.0, version v0.69.1 (juin 2026), migration format de config, fonctionnalités SSH, VirtualNet, et le projet v2 en développement. - Nouveaux éléments sur la frontière zéro-trust IA : openziti/mcp-gateway, passerelle LLM compatible OpenAI, ziti-mcp-server avec API de gestion, annoncés par NetFoundry en mars 2026. - Détails produits Inlets : Inlets Cloud, Uplink, et path auto-hébergé. - Mode “fermé” (--closed, --access-grant) pour Zrok. - Ligne de licence dans la matrice pour distinguer open source et commercial.

Sources vérifiées : github.com/fatedier/frp, github.com/openziti/zrok, blog.openziti.io, netfoundry.io/docs, zrok.io/pricing, inlets.dev, github.com/inlets/inlets-pro, github.com/inlets/inlets-operator, prnewswire.com, github.com/openziti/mcp-gateway, blog.openziti.io, analyses juridiques sur le DPF.