Self-Hosting pour la souveraineté des données : le virage open-source dans les reverse proxies et tunnels d'ingress

Introduction : Le dilemme de l’ingress en entreprise

Dans les architectures cloud-native modernes, les développeurs et équipes opérationnelles font face à un défi persistant : comment exposer en toute sécurité des services internes, environnements de staging, dispositifs en périphérie ou clusters Kubernetes locaux à des réseaux externes ou du trafic client ?

Depuis des années, des outils gérés comme ngrok sont devenus la norme. Avec une simple commande CLI, les ingénieurs peuvent contourner le NAT (Network Address Translation), négocier le CGNAT (Carrier-Grade NAT), et établir une URL HTTPS publique directement mappée à un port local.

Cependant, à mesure que les organisations évoluent et que les workloads cloud-native mûrissent, la dépendance à des tunnels d’ingress SaaS tiers introduit des frictions architecturales et réglementaires. Lorsqu’un trafic interne transite par un serveur SaaS géré par un tiers, l’infrastructure de ce fournisseur se trouve directement dans le chemin des données — un vrai sujet pour les architectes sécurité, responsables conformité et ingénieurs infrastructure.

Les cadres de protection des données comme le GDPR, HIPAA, SOC 2 Type II, PCI-DSS, et la directive NIS2 de l’UE influencent la manière dont les organisations doivent gérer les payloads, l’exposition à des tiers, et la réponse aux incidents — même si, comme expliqué ci-dessous, ils ne régulent pas tous la même chose. Il est important d’être précis sur la législation applicable avant d’architecturer.

L’alternative est la souveraineté des données auto-hébergée : prendre le contrôle du plan de contrôle et du plan de données pour éliminer la télémétrie tierce, appliquer une gestion d’accès zero-trust, et respecter ses propres obligations de conformité directement. Ce guide présente quatre options de niveau production qui impulsent ce changement — frp (Fast Reverse Proxy), zrok (basé sur OpenZiti), Inlets, et le nouvel entrant Pangolin — vérifiées contre la documentation et le code source de chaque projet à partir d’août 2026.

1. La poussée réglementaire et architecturale vers la souveraineté des données

Pourquoi les tunnels d’ingress SaaS compliquent la conformité

Les plateformes SaaS de tunneling gèrent des systèmes de reverse proxy multi-locataires. Lorsqu’un agent local crée un tunnel vers une plateforme SaaS :

• Interception et décryptage du trafic : TLS se termine généralement chez le fournisseur SaaS pour permettre des intégrations comme l’inspection des requêtes, la journalisation des webhooks, et les dashboards web, ce qui signifie que l’infrastructure du fournisseur détient brièvement des données décryptées en mémoire.
• Contrôle limité de la télémétrie et des audits : Les organisations ne peuvent souvent pas vérifier où sont stockés les logs de transit ou combien de temps les corps de requêtes/réponses sont conservés sur une infrastructure qu’elles ne gèrent pas.
• Risque de chaîne d’approvisionnement et point unique de défaillance : Les pannes ou incidents de sécurité chez le fournisseur SaaS peuvent impacter la disponibilité et la confidentialité des endpoints internes.

Il est important de noter que ce n’est pas strictement binaire — ngrok, par exemple, propose des options d’entreprise comme un déploiement “Bring Your Own Cloud” (BYOC) et des éditions privées dédiées qui tournent dans l’environnement du client, ciblant précisément ce genre de préoccupations. L’auto-hébergement reste la réponse la plus complète pour les équipes souhaitant garder le contrôle total du plan de contrôle et du plan de données sans payer pour une version entreprise, mais ce n’est pas la seule voie pour réduire l’exposition tierce.

[ Flux traditionnel de tunnel SaaS - Risque de souveraineté ]
Service local  ---3e  Agent de tunnel local  ---3e  [ Cloud SaaS géré ]  ---3e  Utilisateur / Client public
                                                (Terminaison TLS 66;
                                                Exposition du chemin de données)

[ Flux de tunnel auto-hébergé - Souveraineté totale des données ]
Service local  ---3e  Agent de tunnel local  ---3e  [ Passerelle d’entreprise auto-hébergée ]  ---3e  Utilisateur / Client public
                                                (Sous contrôle total de SecOps
                                                & Politique de conformité)

Comprendre le paysage réglementaire

Il est tentant de regrouper GDPR, HIPAA, PCI-DSS, SOC 2, et NIS2 comme “les raisons pour lesquelles vous avez besoin de souveraineté des données,” mais ils ne remplissent pas tous la même fonction, et les confondre complique la construction du bon contrôle pour le bon besoin :

• GDPR concerne directement où les données personnelles circulent et sont stockées — restrictions de transfert transfrontalier et exigences de résidence des données en sont le cœur.
• HIPAA régule les informations de santé protégées (PHI) dans le contexte US — contrôles d’accès, pistes d’audit, et sauvegardes pour PHI en transit et au repos.
• PCI-DSS concerne spécifiquement les données de carte — segmentation réseau, chiffrement en transit, et restriction d’accès (y compris pour tiers).
• SOC 2 Type II est un cadre d’attestation basé sur des critères de confiance (sécurité, disponibilité, confidentialité, etc.) plutôt qu’une loi ; il montre que vos contrôles fonctionnent efficacement dans le temps, y compris ceux liés aux fournisseurs.
• NIS2 (Directive (UE) ²⁰²²⁄₂₅₅₅) est principalement une directive de gestion des risques cyber et de déclaration d’incidents pour les entités essentielles et importantes dans l’UE — elle impose des mesures de gestion des risques, un rapport d’incidents 24h, des exigences de sécurité de la chaîne d’approvisionnement, et une responsabilité au niveau de la direction. Elle ne fonctionne pas en tant que loi sur la résidence des données comme le GDPR, bien que ses dispositions sur la chaîne d’approvisionnement soient directement pertinentes pour le risque d’exposition à des tiers, ce qui la relie à la discussion sur le tunneling.

L’essentiel pratique : réduire le nombre de tiers dans votre chemin de données diminue l’exposition dans tous ces cadres simultanément — mais si vous citez une réglementation spécifique à une équipe conformité, citez celle qui dit réellement ce que vous affirmez.

Définir la souveraineté des données dans les architectures d’edge et de tunneling

Pour atteindre une véritable souveraineté des données en architecture d’accès distant et d’exposition de services, vous avez généralement besoin de trois choses :

1. Isolation du plan de contrôle — politiques d’authentification, intégration du fournisseur d’identité, et configuration de routage entièrement dans votre infrastructure.
2. Isolation du plan de données — le trafic payload ne doit jamais traverser un tiers non-contracté, avec chiffrement de bout en bout du client ou proxy d’ingress directement au backend.
3. Auditabilité et gouvernance zero-trust — événements de connexion, transferts de bytes, décisions d’autorisation alimentent directement votre SIEM et votre pile d’identité.

2. Critères d’évaluation technique pour une alternative auto-hébergée à ngrok

Lors du choix d’une alternative auto-hébergée à ngrok, considérez :

• Flexibilité du protocole et des couches — couche 7 (HTTP/1.1, HTTP/2, gRPC, WebSockets) ainsi que couche 4 (TCP, UDP, protocoles de base de données) ?
• Intégration ZTNA (Zero Trust Network Access) — repose-t-elle sur des ports d’écoute publics exposés, ou peut-elle fonctionner en outbound-only avec authentification basée sur l’identité ?
• Capacités natives Kubernetes — intégration avec Ingress, CRDs, provisioning automatisé ?
• Performance et surcharge de multiplexage — gestion des connexions, keep-alives, latence sous charge concurrente ?
• Modèle de licence et support — open source véritable, source-available, ou commercial, avec SLA de support ?

3. Analyse approfondie des solutions auto-hébergées

3.1 frp (Fast Reverse Proxy)

frp est un reverse proxy mature, haute performance, écrit en Go, maintenu par fatedier et contributeurs, conçu pour exposer des serveurs locaux derrière NATs et firewalls. C’est l’un des outils de tunneling auto-hébergés les plus déployés dans l’edge computing, la gestion de flotte IoT, et les environnements hybrides d’entreprise, et il est réellement open source sous licence Apache 2.0 — cette partie de la déclaration initiale est vérifiée.

                   +----------------------------------+
                   |       Cloud / VPS auto-hébergé  |
                   |                                  |
   Client  =======3e|   frps (serveur FRP)             |
 (Internet)        |   - Écoute sur ports publics     |
                   |   - Gère TLS / multiplexage      |
                   +----------------------------------+
                                    ^
                                    | Contrôle crypté 66; Tunnel de données multiplexé
                                    |
                   +----------------------------------+
                   |       Réseau d’entreprise privé  |
                   |                                  |
                   |   frpc (client FRP)               |
                   |        |                         |
                   |        v                         |
                   |   Application / API / BD          |
                   +----------------------------------+

Architecture. frp utilise un modèle à double-binaire : frps tourne sur un serveur public et gère le mapping de ports ; frpc tourne dans le réseau privé et initie une connexion outbound vers frps, maintenant une connexion persistante multiplexée.

Options de transport. frp supporte plus de transports que le simple relais TCP — selon la configuration actuelle de frpc/frps, le champ transport.protocol accepte tcp, kcp (protocole UDP à faible latence), quic, websocket, et wss. La prise en charge de QUIC est particulièrement utile pour les liens à haute latence ou perte, multiplexant les flux UDP sans blocage head-of-line.

Types de proxy. frp supporte toujours les modes importants :

• TCP / UDP — exposition directe Layer 4 pour bases de données, SSH, sockets personnalisés.
• HTTP / HTTPS — exposition Layer 7 avec virtual hosting basé sur le domaine et réécriture d’en-têtes/URL.
• STCP (TCP secret) — nécessite une clé partagée pour accéder au service, dissimulant le port.
• XTCP (P2P TCP) — négociation STUN pour une connexion peer-to-peer directe, évitant le relais pour les charges lourdes en bande passante.

Nouveautés. frp dispose d’une fonction alpha VirtualNet, activée via le flag featureGates = { VirtualNet = true }, qui crée une interface TUN et effectue un routage IP entre machines plutôt que du simple forwarding — plus proche d’un mesh léger que d’un reverse proxy classique. Elle nécessite des permissions élevées (root/admin) et est supportée sur Linux et macOS. Le mainteneur a indiqué que frp travaille sur une version 2 basée sur un proxy L4/L7 plus extensible, semblable à Envoy, mais elle n’est pas compatible avec la v1 et est encore en développement — à ne pas utiliser en production pour l’instant.

Exemple de configuration (format TOML actuel) :

# frps.toml (serveur)
bindPort = 7000
vhostHttpsPort = 443

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "STRONG_DASHBOARD_PASSWORD"

transport.tls.force = true

# frpc.toml (client)
serverAddr = "tunnel-gateway.yourcompany.com"
serverPort = 7000

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

transport.protocol = "quic"   # ou "tcp", "kcp", "websocket", "wss"
transport.tls.enable = true

[[proxies]]
name = "internal-api-service"
type = "https"
customDomains = ["api-staging.yourcompany.com"]

Points forts. Runtime léger, mono-binaire ; pas de dépendances externes ; faible empreinte ; routage L4/L7 versatile + P2P via XTCP ; open source Apache 2.0 avec mainteneur actif et cadence de releases en alpha.

Inconvénients. Pas de gestion d’identité/accès intégrée — sécuriser les routes L7 avec OIDC/OAuth2 nécessite un proxy supplémentaire comme Nginx, Traefik, Caddy, ou un proxy OAuth2 devant. La fonction VirtualNet est alpha et non prête pour la production.

3.2 zrok (Zero Trust, basé sur OpenZiti)

zrok est un projet open-source maintenu par NetFoundry, basé sur OpenZiti, le projet de réseau overlay zero-trust de NetFoundry. Zrok et la fabric OpenZiti sont genuinement open source sous licence Apache 2.0 — confirmé directement par la documentation de NetFoundry, pas juste du marketing. NetFoundry vend aussi une suite de gestion sous licence et un support enterprise, mais la fabric elle-même ne coûte rien pour l’auto-hébergement.

                                +---------------------------+
                                |      Fabric OpenZiti       |
                                |   (Contrôleur auto-hébergé |
                                |      & routeurs Ziti)      |
                                +---------------------------+
                                        /           \
                 Contrôle sortant      /             \ Contrôle sortant
                 66 canal de données     /               \ 66 canal de données
                                     v                 v
+-------------------------------+   +----------------------------------+
|   Appareil client / consommateur |   | Environnement de service privé |
|                                |   |                                  |
| zrok accès (mTLS éphémère)     |===3e| Partage zrok (endpoint obscur) |
| Pas d’attaque réseau entrant   |   | Pas de ports ouverts en entrée |
| Surface                        |   | Micro-segmentation native     |
+-------------------------------+   +----------------------------------+

Le modèle. zrok élimine les ports d’entrée ouverts. Les deux côtés — votre API ou application privée et le client consommateur — établissent des connexions outbound-only, sécurisées par mTLS dans la fabric OpenZiti — l’accès est médié par identité, pas par IP ou port ouvert.

Modes de partage. zrok supporte plusieurs modes backend, pas seulement le proxy HTTP : mode proxy pour une cible spécifique, mode web pour servir un répertoire en site statique, et mode drive pour exposer un répertoire comme lecteur réseau WebDAV, avec une commande zrok copy pour synchronisation unidirectionnelle.

Auto-hébergement, description précise. Un déploiement en production n’est pas simplement “faire tourner deux containers Docker” — les guides actuels expliquent comment déployer un contrôleur et des routeurs OpenZiti, puis le contrôleur zrok, un ou plusieurs frontends, et un pont de métriques, avec PostgreSQL, RabbitMQ, et InfluxDB. C’est un vrai système multi-composants, ce qui correspond à la complexité opérationnelle déjà mentionnée dans la table de licences.

Une nuance de sécurité importante. Par défaut, zrok partage — public et privé — utilise le mode de permission appelé “open” : tout utilisateur de votre instance zrok qui connaît le token de partage peut y accéder. Le flag --closed sur zrok share (avec --access-grant <email>) limite un partage privé à des identités explicitement autorisées. Si vous déployez zrok pour son aspect zero-trust, les partages --closed avec accès explicite sont ceux qui respectent réellement cette philosophie — le mode par défaut étant plus permissif que ce que le “zero trust” laisse penser.

Exemple CLI corrigé. Les commandes initiales étaient proches mais utilisaient un format de token non représentatif et un flag --bind inutile côté client. Version plus précise :

# 1. Pointer le CLI vers votre instance auto-hébergée et s’authentifier
zrok login --api-endpoint https://zrok.yourcompany-internal.net <api-token>

# 2. Partager un service local en privé, limité à des comptes nommés
zrok share private --headless --closed --access-grant teammate@yourcompany.com 127.0.0.1:9090

# La sortie inclut un token de partage, par ex. : wr3hpf2z5fiy

# 3. Sur une machine autorisée, accéder au partage privé
zrok access private wr3hpf2z5fiy

Points forts. Modèle zéro port ouvert avec mTLS natif et micro-segmentation ; licence Apache 2.0 authentique ; modes backend variés (fichiers, WebDAV) ; gestion fine des permissions par partage.

Inconvénients. Complexité opérationnelle plus grande qu’un reverse proxy mono-binaire — déploiement et gestion d’un système distribué (contrôleur, routeurs, frontends, broker, stockage métriques), pas juste un relais. Le mode permission par défaut est plus permissif que le “zero trust” sans configuration explicite.

3.3 Inlets

C’est ici que la correction la plus importante était nécessaire. Inlets Pro n’est pas open source. Le projet original “inlets OSS” (v1/v2) était gratuit et open source, mais son propre dépôt GitHub le décrit comme dépassé et sans mise à jour. Le produit maintenu — inlets Pro, développé par Alex Ellis (fondateur d’OpenFaaS) — est un binaire fermé distribué sous une licence commerciale. Il faut une clé de licence payante ou un abonnement Gumroad pour l’utiliser, et le code source n’est pas publié. Les outils autour, inlets-operator (qui provisionne automatiquement des VMs exit-node pour Kubernetes LoadBalancer) et inletsctl (CLI pour créer des serveurs exit) sont séparés et open source, mais le moteur de tunnel qu’ils orchestrent est un logiciel commercial, pas “dual-licensed open source”.

+-------------------------------------------------------------------------+
|                  VPS Cloud public / Passerelle edge                     |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-pro exit-node (reçoit du trafic public)                  |   |
|   | Écoute sur ports 80 / 443                                       |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+
                                    ^
                                    | Contrôle sécurisé 66; Tunnel WebSocket TLS
                                    |
+-------------------------------------------------------------------------+
|                 Cluster Kubernetes privé d’entreprise                     |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-operator (provisionne automatiquement les exit-nodes)   |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|   +-------------------------------+---------------------------------+   |
|   | inlets-pro client (multiplexe le trafic)                        |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|                                   v                                     |
|   +-----------------------------------------------------------------+   |
|   | Ingress-Nginx / Traefik / Envoy (ClusterIP)                     |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

Ce qu’il fait bien. Inlets Pro tunnelise le TCP Layer 4 brut via WebSockets cryptés, ce qui est crucial pour les contrôleurs d’ingress Kubernetes qui doivent voir le TCP brut pour inspecter TLS SNI, gérer le mTLS, ou automatiser cert-manager. L’inlets-operator surveille les objets Service de type LoadBalancer, provisionne une VM sur un cloud supporté, et connecte automatiquement — pratique pour le bare-metal, on-prem, ou Kubernetes edge.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    dev.inlets.operator/provider: "digitalocean"
    dev.inlets.operator/region: "ams3"
    dev.inlets.operator/plan: "s-1vcpu-1gb"
spec:
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https
  selector:
    app.kubernetes.io/name: ingress-nginx

Ce qui est nouveau depuis le brouillon original. L’équipe d’Alex Ellis propose désormais Inlets Uplink, destiné spécifiquement aux équipes SaaS et plateformes qui doivent gérer de nombreux tunnels clients depuis un plan de contrôle Kubernetes — tarifé en forfait mensuel fixe plus une charge par tunnel, en licence commerciale.

Points forts. Conçu pour Kubernetes, avec transparence TCP L4 réelle et intégration cert-manager ; provisioning automatique d’exit-nodes sur grands clouds ; support commercial réel.

Inconvénients. Logiciel commercial sous licence, pas open source à auditer ou forker ; modèle de confiance et coût différent de frp ou zrok. Si l’objectif est “aucune dépendance tierce”, la relation d’Inlets avec OpenFaaS Ltd comme fournisseur de logiciel exit-node doit être considérée, même si le trafic ne quitte jamais votre infrastructure.

3.4 Pangolin — Un nouvel entrant à connaître

Depuis que le paysage du tunneling a évolué, il est pertinent d’ajouter une quatrième option qui n’existait pas sous cette forme lors de la rédaction initiale : Pangolin, une plateforme de reverse proxy tunnel auto-hébergée basée sur WireGuard (via un client utilisateur personnalisé appelé Newt) et Traefik, avec gestion d’identité et d’accès intégrée dès le départ. Elle se positionne comme une alternative auto-hébergeable à Cloudflare Tunnel, et a rapidement gagné en popularité — ses créateurs ont rapporté plus de 12 600 étoiles GitHub et 140 000+ installations en cinq mois. Open source, avec une couche cloud managée optionnelle pour une bascule automatique sans renoncer à la souveraineté.

Son positionnement par rapport à frp, zrok, et Inlets. Pangolin cible précisément le vide décrit dans la section frp — un tunnel auto-hébergé avec authentification SSO centralisée, contrôle d’accès basé sur rôles, TOTP, et règles d’accès par ressource, sans déployer séparément un proxy OAuth2 ou une fabric OpenZiti. Il sacrifie une partie de la pureté zero-port de zrok (le serveur central doit toujours terminer les connexions et être accessible) pour un modèle opérationnel plus simple que la mise en place d’OpenZiti, et offre des fonctionnalités d’identité intégrées que frp ne possède pas nativement.

4. Matrice de comparaison architecturale

Capacité	ngrok (SaaS)	frp	zrok (OpenZiti)	Inlets Pro	Pangolin
Souveraineté des données	Limitée par défaut ; édition BYOC / privée disponible en plans entreprise	Contrôle total	Contrôle total	Contrôle total (moteur commercial)	Contrôle total
Licence	Proprietary SaaS	Open source (Apache 2.0)	Open source (Apache 2.0)	Commercial (closed source, clé de licence)	Open source
Support couche réseau	L4 & L7	L4 (TCP/UDP), L7 (HTTP/S), P2P, VirtualNet expérimental	L4 & L7 via fabric zero-trust ; fichiers/WebDAV	TCP L4 & HTTP/WebSockets L7	WireGuard L4 & Traefik L7
Ports firewall entrants	Aucun requis (SaaS)	Nécessite port ouvert sur frps	Aucun requis (par défaut en mode sombre)	Nécessite port ouvert sur exit-node	Aucun requis sur ressources protégées
Intégration Kubernetes	Contrôleur d’ingress personnalisé	Manuel / Helm	Opérateur / SDK	inlets-operator natif	Non natif Kubernetes
Contrôle d’identité / accès	OAuth SaaS / listes IP	Authentification par token ; besoin d’un proxy IdP pour SSO/OIDC	Identités mTLS natives ; modes de permission par partage	Auth par clé de licence ; TLS	SSO intégré, RBAC, TOTP
Empreinte déploiement	Cloud SaaS + agent local	Binôme unique (frps/frpc)	Contrôleur + routeurs + frontends + stack métriques	VM exit-node + client	Serveur central + Traefik + clients Newt

5. Plan de sécurisation pour tunnels d’ingress auto-hébergés

Le déploiement d’une passerelle auto-hébergée transfère toute la gouvernance sécurité à votre SecOps interne. Checklist de production :

+---------------------------------------------------------------------------------------------------+
|                                CHECKLIST DE SÉCURISATION EN PRODUCTION                              |
+---------------------------------------------------------------------------------------------------+
|  [1] TLS 1.3 stricte --3e Terminer ou faire passer TLS 1.3 ; désactiver les chiffrements obsolètes. |
|  [2] Proxy d’identité & OIDC --3e Gérer les endpoints L7 publics via OAuth2-Proxy / Keycloak. |
|  [3] Limitation de débit & DDoS --3e Imposer limites de connexions et contrôles de rafale via eBPF/Nginx. |
|  [4] Intégration de logs d’audit --3e Envoyer les logs JSON directement vers SIEM (Splunk/Datadog). |
|  [5] Segmentation minimaliste --3e Isoler les processus du tunnel avec Docker/AppArmor/SELinux. |
+---------------------------------------------------------------------------------------------------+

1. Appliquer OAuth2/OIDC au niveau de la passerelle. Ne jamais exposer directement des panneaux d’administration ou API de staging non authentifiés. Associer frps ou un exit-node inlets avec OAuth2-Proxy, Authelia, ou Authentik liés à votre IdP d’entreprise. (zrok et Pangolin gèrent l’identité de façon plus native — voir ci-dessus.)
2. Segmenter le rayon d’impact. Exécuter les clients de tunnel dans des réseaux de containers isolés ou avec des utilisateurs Linux non privilégiés ; utiliser NetworkPolicy pour empêcher un pod compromis de scanner les services adjacents.
3. Centraliser la journalisation d’audit. Transférer les logs de cycle de vie des connexions — IP source, paramètres TLS, bytes transférés, identifiants de tokens — vers un stockage immuable ou SIEM. [ Passerelle tunnel ] ---3e [ Agent Syslog / Vector ] ---3e [ SIEM : Splunk / Elastic / Datadog ]

6. Recommandations stratégiques

• Développement local, staging, IoT : frp reste la voie la plus rapide vers un tunnel léger, open-source, zéro coût, pour API internes, sockets SSH ou hardware en périphérie.
• Environnements stricts zero-trust / réglementés où aucun port entrant n’est acceptable : zrok, en configurant délibérément des partages --closed plutôt que le mode permissif par défaut, et en opérant la fabric OpenZiti.
• Ingress cloud-native, on-prem ou hybride Kubernetes : Inlets Pro, en étant conscient que c’est un logiciel commercial, pas une dépendance open source.
• Petites équipes ou auto-hébergeurs souhaitant un accès SSO sans déployer OpenZiti ou Kubernetes : Pangolin est le plus récent et, pour ce cas précis, probablement le plus simple à déployer.

Conclusion

L’éloignement des tunnels SaaS gérés est réel, mais la justification doit être aussi rigoureuse que l’architecture elle-même. Tous les cadres réglementaires ne disent pas ce qu’on suppose souvent, et toutes les “alternatives open source” ne le sont pas entièrement — Inlets Pro étant l’exemple le plus clair. frp, zrok, et Pangolin sont réellement open source et mettent le contrôle total dans vos mains ; Inlets Pro met le chemin des données sous votre contrôle tout en restant un produit payant et fermé. Savoir faire la différence, c’est la clé pour une argumentation conformité précise versus une qui s’effondre lors d’un audit sécurité.

---

Sources

• fatedier/frp — GitHub, README, releases
• Documentation officielle frp (gofrp.org)
• Vue d’ensemble de zrok — Documentation NetFoundry
• zrok — Page de licence open source, Documentation NetFoundry
• Guide de déploiement self-hosting zrok (Linux) — Documentation NetFoundry
• Modes de permission zrok — openziti/zrok GitHub
• OpenZiti — Réseau Zero Trust, sécurisé par identité
• inlets PRO — GitHub et conditions de licence
• Site officiel inlets.dev
• Tarification Inlets Uplink — OpenFaaS Gumroad
• Pangolin — GitHub
• Page de lancement Y Combinator — Pangolin
• Directive NIS2 — Commission européenne
• ngrok BYOC / édition privée — AWS Marketplace

---

Changelog

Revue éditoriale — 28 août 2026

1. Suppression de la ligne de meta description en haut du brouillon (pas partie du corps de l’article).
2. frp : confirmation de la licence Apache 2.0 directement via le dépôt fatedier/frp (la source officielle — à ne pas confondre avec des forks non liés). ajout des protocoles de transport supportés (quic, kcp, websocket, wss) en plus du tcp simple, non mentionné dans le brouillon original. ajout de la fonction alpha VirtualNet en TUN et d’une note sur la version frp v2 en cours de développement, toutes deux issues de la documentation et des notes de version du projet.
3. zrok : confirmation de la licence Apache 2.0 pour zrok et la fabric OpenZiti, directement via la documentation NetFoundry. remplacement de la description vague “Docker Compose ou charts Kubernetes” par la liste réelle des composants (contrôleur, frontends, pont métriques, PostgreSQL, RabbitMQ, InfluxDB). correction de l’exemple CLI (format du token, ajout des flags --closed/--access-grant) et mention d’un point de sécurité que l’article original n’avait pas : les partages zrok sont par défaut en mode “open” accessible à tout utilisateur de l’instance, pas en mode “zero trust” par défaut.
4. Inlets : correction majeure. La version initiale décrivait Inlets Pro comme open source, ce qui est faux. Inlets Pro est une solution commerciale fermée, nécessitant une clé de licence payante. Seuls l’ancien projet OSS “inlets” et ses outils d’orchestration (inlets-operator, inletsctl) sont open source. mise à jour de la matrice et du texte pour refléter cela, ajout du produit Inlets Uplink avec tarification.
5. Cadre réglementaire : clarification. La version initiale laissait penser que GDPR, HIPAA, SOC 2, PCI-DSS, NIS2 régulent tous la résidence des données. Ajout d’explications précises pour chaque cadre, notamment que NIS2 est principalement une directive de gestion des risques cyber et déclaration d’incidents, pas une loi sur la résidence.
6. ngrok : ajout d’une note factuelle que ngrok propose des options BYOC et édition privée à l’échelle entreprise, ce qui nuance la vision d’un SaaS sans contrôle.
7. Ajout section 3.4 (Pangolin) : plateforme open source, auto-hébergée, basée sur WireGuard + Traefik, avec gestion d’identité intégrée, qui n’était pas dans le brouillon initial. Son positionnement par rapport à frp, zrok, Inlets.
8. Mise à jour de la matrice de comparaison (Section 4) et des recommandations stratégiques (Section 6), avec tableau Markdown.
9. Ajout d’une section Sources avec liens vers documentation et ressources principales.