Comparatif ZTNA 2026 : Cloudflare vs Tailscale vs Teleport vs Pangolin

Le paysage de la cybersecurite d'entreprise a connu une mutation profonde ces dernieres annees, et le paradigme Zero Trust s'est impose comme le nouveau standard de reference pour securiser les acces aux ressources informatiques. Face a la multiplication des solutions ZTNA (Zero Trust Network Access) disponibles sur le marche, les responsables IT et RSSI se trouvent confrontes a un dilemme complexe : quelle solution choisir parmi Cloudflare One, Tailscale, Headscale, Pangolin, Teleport et leurs nombreuses alternatives ? Ce comparatif exhaustif analyse en profondeur six solutions majeures selon plus de quinze criteres techniques, economiques et operationnels. Nous examinerons les architectures sous-jacentes, les modeles de deploiement (SaaS versus self-hosted), les capacites de chiffrement, l'integration aux fournisseurs d'identite, la gestion des postures de securite des terminaux, les fonctionnalites d'audit et d'enregistrement de sessions, ainsi que le cout total de possession sur trois ans pour differentes tailles d'organisation. Que vous soyez une startup cherchant une solution simple et gratuite, une PME souhaitant reprendre le controle de ses donnees avec une solution auto-hebergee, ou un grand compte necessitant une conformite stricte aux normes ISO 27001 et SOC 2, ce guide vous fournira toutes les cles pour prendre une decision eclairee et migrer sereinement depuis votre VPN traditionnel vers une architecture Zero Trust moderne.

Pourquoi le VPN traditionnel ne suffit plus : le contexte Zero Trust

Pendant plus de deux decennies, le VPN (Virtual Private Network) a constitue la pierre angulaire de l'acces distant aux ressources d'entreprise. Le modele etait simple : un tunnel chiffre relie le poste de l'utilisateur au reseau interne de l'entreprise, lui accordant de facto un acces large, souvent non segmente, a l'ensemble des ressources du reseau. Ce paradigme, herite de l'ere du perimetre reseau, repose sur une hypothese fondamentale desormais obsolete : une fois authentifie et connecte au VPN, l'utilisateur est considere comme « de confiance » et beneficie d'un acces lateral pratiquement illimite.

Les limites de ce modele sont devenues criantes avec l'evolution des menaces et des usages. Les attaques par mouvement lateral, ou un attaquant compromet un compte VPN puis se deplace librement dans le reseau, representent aujourd'hui l'un des vecteurs d'intrusion les plus devastateurs. L'affaire SolarWinds en 2020, les attaques contre Colonial Pipeline en 2021, et plus recemment les compromissions massives de concentrateurs VPN Ivanti et Fortinet en 2024-2025 ont demontre que le VPN constitue non seulement un point de defaillance unique (SPOF), mais aussi une surface d'attaque considerable. Chaque concentrateur VPN expose sur Internet est une cible potentielle pour les acteurs malveillants qui exploitent des vulnerabilites zero-day dans le firmware de ces appliances.

C'est dans ce contexte que le NIST (National Institute of Standards and Technology) a publie le document fondateur SP 800-207 — Zero Trust Architecture, qui formalise les principes du Zero Trust. Les trois piliers fondamentaux sont :

• Never trust, always verify — Aucune confiance implicite n'est accordee, que l'utilisateur soit a l'interieur ou a l'exterieur du reseau.
• Least privilege access — Chaque utilisateur, appareil et service ne recoit que les permissions strictement necessaires a l'execution de sa tache.
• Assume breach — L'architecture est concue en partant du principe qu'une compromission a deja eu lieu ou est imminente.

Le Zero Trust Network Access (ZTNA) est l'implementation concrete de ces principes pour l'acces distant. Contrairement au VPN qui cree un tunnel reseau, le ZTNA etablit des micro-tunnels applicatifs : l'utilisateur n'accede qu'a l'application specifique autorisee, jamais au reseau sous-jacent. L'authentification est continue et contextuelle, prenant en compte l'identite de l'utilisateur, la posture de securite de son terminal, sa localisation geographique, l'heure de connexion et le comportement observe.

Les avantages du ZTNA par rapport au VPN traditionnel sont multiples. Premierement, la surface d'attaque est drastiquement reduite : il n'y a plus de concentrateur VPN expose sur Internet, car les connexions sont initiees de l'interieur vers l'exterieur (outbound-only). Deuxiemement, la segmentation est native : chaque application est un micro-perimetre independant. Troisiemement, l'experience utilisateur est amelioree : plus besoin de lancer un client VPN, l'acces est transparent et contextuel. Quatriemement, la scalabilite est superieure : l'architecture distribuee elimine les goulets d'etranglement des concentrateurs VPN centralises.

Le marche du ZTNA a explose, passant de 1,5 milliard de dollars en 2022 a une estimation de 7,2 milliards en 2026 selon Gartner. Cette croissance s'accompagne d'une diversification des approches : certains editeurs proposent des solutions SaaS completement gerees, d'autres des plateformes open-source auto-hebergees, et d'autres encore des architectures hybrides. Comprendre ces differences architecturales est essentiel pour faire le bon choix.

Il est egalement important de noter que la transition vers le Zero Trust ne se fait pas du jour au lendemain. La plupart des organisations adoptent une approche progressive, en commencant par les applications les plus critiques et les populations d'utilisateurs les plus a risque (administrateurs systemes, prestataires externes, equipes de developpement accedant aux environnements de production). Le NIST SP 800-207 decrit trois approches de deploiement du Zero Trust : l'approche centree sur l'identite (ou l'identite de l'utilisateur est le point de controle principal), l'approche centree sur le reseau (ou la micro-segmentation reseau est le mecanisme de controle), et l'approche combinee (recommandee) qui integre les deux dimensions. Les solutions analysees dans ce comparatif adressent ces trois approches a des degres divers.

Le contexte reglementaire europeen renforce egalement l'urgence de la migration vers le Zero Trust. La directive NIS2, entree en vigueur en octobre 2024, impose aux entites essentielles et importantes des exigences renforcees en matiere de gestion des risques cyber, incluant explicitement la gestion des acces et l'authentification multi-facteurs. Le Cyber Resilience Act europeen, applicable a partir de 2027, imposera des exigences de securite by design pour tous les produits numeriques. Les organisations qui n'auront pas migre vers des architectures Zero Trust risquent non seulement des sanctions financieres (jusqu'a 10 millions d'euros ou 2% du chiffre d'affaires mondial pour NIS2), mais aussi une exposition accrue aux cyberattaques dans un paysage de menaces en constante evolution.

Taxonomie des solutions ZTNA : SaaS, self-hosted, mesh VPN, tunnels et access planes

Avant de plonger dans l'analyse individuelle de chaque solution, il est indispensable de comprendre les grandes familles architecturales du ZTNA. Cette taxonomie permet de classifier les solutions selon leur modele de deploiement, leur topologie reseau et leur approche de la securite.

SaaS versus self-hosted : le dilemme du controle

La premiere distinction fondamentale concerne le modele de deploiement. Les solutions SaaS (Software as a Service) comme Cloudflare One ou Twingate sont entierement gerees par l'editeur. Le plan de controle (coordination server, politique d'acces, gestion des cles) est heberge dans le cloud de l'editeur. L'avantage est la simplicite de deploiement et de maintenance ; l'inconvenient est la dependance a un tiers pour la gestion des cles de chiffrement et des politiques d'acces. Pour les organisations soumises a des contraintes reglementaires strictes (defense, sante, finance), cette delegation peut etre inacceptable.

Les solutions self-hosted comme Headscale, Pangolin ou Teleport Community Edition permettent a l'organisation de deployer l'integralite de l'infrastructure ZTNA sur ses propres serveurs. Le plan de controle, le plan de donnees et les politiques d'acces sont sous le controle exclusif de l'organisation. L'avantage est la souverainete totale des donnees ; l'inconvenient est la charge operationnelle de maintenance, de mise a jour et de haute disponibilite.

Certaines solutions adoptent une approche hybride : Tailscale, par exemple, utilise un coordination server SaaS pour la decouverte des pairs et l'echange de cles publiques, mais le trafic de donnees transite directement entre les noeuds (peer-to-peer) sans passer par les serveurs de Tailscale. Ce modele offre un compromis interessant entre simplicite et confidentialite.

Mesh VPN versus tunnel versus access plane

La deuxieme distinction concerne la topologie reseau. Un mesh VPN (reseau maille) comme Tailscale ou ZeroTier cree un reseau virtuel ou chaque noeud peut communiquer directement avec n'importe quel autre noeud. La topologie est decentralisee, il n'y a pas de point de passage oblige. Cette approche est ideale pour les architectures distribuees ou les noeuds ont besoin de communiquer entre eux (par exemple, des clusters Kubernetes multi-sites).

Un tunnel applicatif comme Cloudflare Tunnel ou Pangolin cree des tunnels dedies entre une application specifique et le point d'entree ZTNA. L'utilisateur n'accede pas a un reseau, mais a une application precise via un reverse proxy authentifie. Cette approche offre la meilleure segmentation mais peut etre plus complexe a deployer pour un grand nombre d'applications.

Un access plane unifie comme Teleport adopte une approche encore differente : plutot que de creer des tunnels reseau, il agit comme un proxy d'acces protocolaire. Teleport comprend nativement les protocoles SSH, Kubernetes API, bases de donnees (PostgreSQL, MySQL, MongoDB), applications web et bureaux a distance (RDP). Cette comprehension protocolaire permet des fonctionnalites avancees comme l'enregistrement de sessions, l'audit granulaire des commandes executees et le controle d'acces au niveau de la requete.

Les criteres de classification

Pour structurer notre comparaison, nous utiliserons les criteres suivants : le modele de deploiement (SaaS, self-hosted, hybride), la topologie (mesh, tunnel, access plane), le protocole de transport (WireGuard, QUIC, mTLS, SSH), le modele de confiance (zero knowledge, trust-but-verify, full trust), l'integration IdP (OIDC, SAML, LDAP), les capacites d'audit (logs, enregistrement de sessions, SIEM), la gestion des terminaux (device posture, certificats mTLS), le support Kubernetes, le modele de tarification et la maturite de l'ecosysteme.

Cloudflare One : la puissance du reseau mondial au service du Zero Trust

Cloudflare One est la plateforme ZTNA et SASE (Secure Access Service Edge) de Cloudflare, le geant de l'infrastructure Internet. Lancee en 2020 et considerablement enrichie depuis, cette solution s'appuie sur le reseau mondial de Cloudflare, present dans plus de 310 villes a travers le monde, pour offrir une plateforme de securite unifiee combinant ZTNA, passerelle web securisee (SWG), CASB (Cloud Access Security Broker), isolation de navigateur a distance (RBI) et filtrage DNS.

Architecture et fonctionnement

L'architecture de Cloudflare One repose sur trois composants principaux. Cloudflare Access est le module ZTNA a proprement parler : il agit comme un reverse proxy authentifie devant chaque application. L'utilisateur s'authentifie via son fournisseur d'identite (Okta, Azure AD, Google Workspace, etc.), et Cloudflare Access verifie les politiques d'acces avant de relayer la requete vers l'application. Cloudflare Tunnel (anciennement Argo Tunnel) est le mecanisme qui connecte les applications internes au reseau Cloudflare sans ouvrir de port entrant. Un daemon leger (cloudflared) est installe sur le serveur hebergeant l'application et etablit des connexions sortantes vers le reseau Cloudflare. Cloudflare Gateway est la passerelle web securisee qui filtre le trafic sortant des utilisateurs, bloquant les domaines malveillants, le phishing et les malwares.

Le client WARP, installe sur les postes des utilisateurs, cree un tunnel WireGuard vers le point de presence Cloudflare le plus proche. Ce tunnel achemine l'ensemble du trafic de l'utilisateur (ou uniquement le trafic vers les applications protegees, selon la configuration) a travers le reseau Cloudflare, ou les politiques de securite sont appliquees.

Forces de Cloudflare One

Performance reseau inegalee. Avec plus de 310 points de presence mondiaux et une capacite reseau de plus de 280 Tbps, Cloudflare offre une latence extremement faible pour les utilisateurs, ou qu'ils se trouvent. Le trafic est route intelligemment via le backbone prive de Cloudflare, evitant les congestionnements de l'Internet public.

Suite de securite integree. Cloudflare One n'est pas seulement un ZTNA : c'est une plateforme SASE complete. L'integration native entre Access, Gateway, le CASB et l'isolation de navigateur permet de creer des politiques de securite coherentes et multicouches. Par exemple, un utilisateur accedant a une application sensible depuis un appareil non gere peut se voir proposer une session isolee dans le navigateur, ou l'application est accessible mais le copier-coller et le telechargement sont desactives.

Facilite de deploiement. La mise en place d'un tunnel Cloudflare pour exposer une application interne se fait en quelques minutes. Le daemon cloudflared est disponible pour Linux, macOS, Windows et peut etre deploye en tant que conteneur Docker ou pod Kubernetes. La configuration peut etre geree via le dashboard web, l'API REST, Terraform ou le fichier de configuration YAML local.

Tier gratuit genereux. Le plan gratuit de Cloudflare One inclut jusqu'a 50 utilisateurs avec Access et Tunnel, ce qui couvre les besoins de nombreuses petites equipes et startups. C'est un argument majeur pour l'adoption initiale.

Device posture avancee. Cloudflare One peut verifier la posture de securite des terminaux avant d'accorder l'acces : version du systeme d'exploitation, presence d'un antivirus, chiffrement du disque, certificat mTLS client, et integration avec des solutions EDR comme CrowdStrike, SentinelOne ou Carbon Black.

Faiblesses de Cloudflare One

Dependance au SaaS. L'integralite du plan de controle est hebergee chez Cloudflare. Il n'existe aucune option self-hosted. Pour les organisations soumises a des exigences de souverainete des donnees strictes (administration publique francaise, defense, certains secteurs de la sante), cette dependance peut etre un facteur eliminatoire. Le trafic transite par les serveurs Cloudflare, meme si le chiffrement de bout en bout est assure.

Complexite du pricing a l'echelle. Si le tier gratuit est attractif, la tarification au-dela de 50 utilisateurs peut devenir complexe. Le plan Pay-as-you-go est a 7$/utilisateur/mois pour les fonctionnalites de base, mais les fonctionnalites avancees (DLP, CASB, isolation de navigateur) necessitent le plan Enterprise dont le prix n'est pas publie et se negocie au cas par cas. Les organisations de taille intermediaire peuvent se retrouver dans une zone grise tarifaire.

Verrouillage ecosysteme. L'utilisation avancee de Cloudflare One incite a utiliser l'ensemble de l'ecosysteme Cloudflare (DNS, CDN, Workers, R2, etc.). Cette integration est un avantage en termes de simplicite, mais cree une forte dependance a un seul fournisseur. La migration vers une solution concurrente peut etre couteuse et complexe.

Limitation du mesh networking. Cloudflare One est concu pour l'acces client-a-application, pas pour la communication server-a-server ou le mesh networking. Si vous avez besoin que vos serveurs communiquent entre eux via un reseau prive virtuel, Cloudflare One n'est pas l'outil ideal (meme si Cloudflare WARP connector commence a adresser ce cas d'usage).

Tarification de Cloudflare One

Le modele de tarification se decompose comme suit : le plan Free offre jusqu'a 50 utilisateurs avec Access, Tunnel et Gateway basique. Le plan Pay-as-you-go a 7$/utilisateur/mois ajoute la journalisation avancee, les politiques Gateway etendues et le support technique. Le plan Contract a partir de 84$/utilisateur/an (equivalent a 7$/mois avec engagement annuel) offre des remises volume. Le plan Enterprise est sur devis et inclut DLP, CASB, RBI, SLA garanti, support premium et options de localisation des donnees.

Cas d'usage ideaux

Exemples concrets de deploiement

Pour illustrer la puissance de Cloudflare One, prenons l'exemple d'une entreprise de 80 collaborateurs repartis entre Paris, Lyon et le teletravail, disposant d'un intranet Confluence, d'un GitLab auto-heberge, d'un outil de monitoring Grafana et d'un ERP accessible en HTTP. Traditionnellement, un VPN OpenVPN centralise a Paris permettait l'acces a ces quatre applications. Avec Cloudflare One, chaque application recoit son propre tunnel Cloudflare, configure via un fichier YAML ou le dashboard. Les politiques Access definissent que les developpeurs (identifies via le groupe Azure AD « Engineering ») accedent au GitLab et au Grafana, tandis que les comptables (groupe « Finance ») accedent a l'ERP. L'intranet Confluence est accessible a tous les employes authentifies. Le client WARP, deploye via MDM (Intune, Jamf), assure que les politiques Gateway filtrent le trafic web des postes nomades. Le resultat : le concentrateur OpenVPN est decomissionne, la latence est reduite (chaque utilisateur se connecte au PoP Cloudflare le plus proche plutot qu'au serveur VPN parisien), et la granularite des acces est considerablement amelioree.

Un autre scenario ou Cloudflare One excelle est la protection des API internes. De nombreuses entreprises developpent des microservices exposes via des API REST ou gRPC. Cloudflare Tunnel peut exposer ces API en ajoutant une couche d'authentification (JWT verification, mTLS, Access policies) sans modifier le code applicatif. Les API internes deviennent accessibles uniquement aux services et utilisateurs autorises, avec un WAF (Web Application Firewall) et un rate limiting geres par Cloudflare.

Cas d'usage ideaux

Cloudflare One excelle dans les scenarios suivants : les organisations distribuees avec des equipes reparties mondialement qui beneficient du reseau Cloudflare, les entreprises cherchant une solution SASE tout-en-un sans multiplier les outils, les equipes de petite taille (moins de 50 utilisateurs) souhaitant une solution gratuite et professionnelle, et les organisations exposant des applications web internes qui beneficient du reverse proxy authentifie.

Tailscale : le mesh VPN WireGuard simplifie a l'extreme

Tailscale a revolutionne l'acces reseau en rendant WireGuard accessible a tous. Fondee en 2019 par d'anciens ingenieurs de Google, Tailscale propose un mesh VPN base sur le protocole WireGuard qui cree un reseau prive virtuel entre tous vos appareils, avec un deploiement d'une simplicite remarquable. La promesse de Tailscale est claire : « un reseau prive qui fonctionne tout simplement ».

Architecture et fonctionnement

Tailscale utilise une architecture intelligente qui separe le plan de controle du plan de donnees. Le coordination server (heberge par Tailscale en SaaS) gere l'authentification des utilisateurs, la distribution des cles publiques WireGuard, les ACL (Access Control Lists) et la decouverte des pairs. Le plan de donnees, en revanche, est entierement peer-to-peer : le trafic circule directement entre les noeuds, sans transiter par les serveurs de Tailscale. Cette separation est un atout majeur en termes de confidentialite.

Quand deux noeuds Tailscale doivent communiquer, le coordination server les informe mutuellement de leurs adresses IP et cles publiques WireGuard. Les noeuds tentent alors d'etablir une connexion directe. Si les deux noeuds sont derriere des NAT, Tailscale utilise des serveurs DERP (Designated Encrypted Relay for Packets) pour relayer temporairement le trafic le temps que le NAT traversal aboutisse. Dans la majorite des cas, une connexion directe peer-to-peer est etablie en quelques secondes.

Chaque noeud Tailscale recoit une adresse IP stable dans le range 100.x.y.z (CGNAT). Un service MagicDNS integre permet de resoudre les noms des machines directement (machine-name.tailnet-name.ts.net). La configuration des ACL se fait via un fichier JSON ou HuJSON (JSON avec commentaires) qui definit quels utilisateurs ou groupes peuvent acceder a quels noeuds et ports.

Forces de Tailscale

Simplicite d'installation et d'utilisation. L'installation de Tailscale se fait en une commande sur la plupart des systemes d'exploitation. Sur Linux : curl -fsSL https://tailscale.com/install.sh | sh && sudo tailscale up. Sur macOS et Windows, un installateur graphique est disponible. L'authentification se fait via le navigateur avec le fournisseur d'identite de votre choix. En moins de cinq minutes, un reseau prive est operationnel.

Performance WireGuard native. Tailscale utilise WireGuard dans le kernel Linux quand disponible, offrant des performances cryptographiques optimales. Le chiffrement ChaCha20-Poly1305 de WireGuard est extremement efficace, et le protocole est concu pour minimiser la latence. Les connexions peer-to-peer evitent le detour par un serveur central, offrant une latence proche de celle d'une connexion directe.

Subnet routing et exit nodes. Tailscale peut router le trafic vers des sous-reseaux entiers via la fonctionnalite de subnet router. Un noeud Tailscale installe dans un datacenter peut annoncer le reseau 10.0.0.0/8 au reste du tailnet, permettant aux autres noeuds d'acceder aux machines de ce sous-reseau sans installer Tailscale sur chacune d'entre elles. Les exit nodes permettent de router l'ensemble du trafic Internet d'un noeud via un autre noeud Tailscale, fonctionnant comme un VPN classique.

Tailscale SSH. Tailscale SSH est une fonctionnalite qui remplace l'authentification SSH traditionnelle par cles/mots de passe par une authentification basee sur l'identite Tailscale. Plus besoin de gerer des cles SSH : l'acces est controle par les ACL Tailscale, et les sessions peuvent etre enregistrees pour l'audit.

Funnel et Serve. Tailscale Funnel permet d'exposer un service local sur Internet via un nom de domaine *.ts.net avec certificat TLS automatique. Tailscale Serve permet de partager un service local avec les membres du tailnet. Ces fonctionnalites sont utiles pour les demonstrations, le developpement et les webhooks.

Ecosysteme riche. Tailscale propose des integrations avec Kubernetes (operator Tailscale), Docker (sidecar et extension Docker Desktop), Terraform, Pulumi, et des apps pour tous les systemes d'exploitation majeurs incluant iOS, Android, ChromeOS et meme les NAS Synology et QNAP.

Faiblesses de Tailscale

Coordination server SaaS proprietaire. Le principal reproche fait a Tailscale est que le coordination server est proprietaire et heberge par Tailscale. Meme si le trafic de donnees est peer-to-peer et ne passe pas par Tailscale, les metadonnees (qui communique avec qui, quand, depuis quelle IP) sont connues du coordination server. Pour les organisations soucieuses de souverainete des metadonnees, c'est un point de friction. C'est precisement cette limitation qui a donne naissance a Headscale.

ACL limitees pour les grands deploiements. Le systeme d'ACL de Tailscale, base sur un fichier JSON unique, peut devenir complexe a gerer pour les organisations de grande taille avec de nombreux groupes, tags et regles. L'absence de support RBAC (Role-Based Access Control) natif avance oblige a modeliser les roles via des tags et des groupes, ce qui peut manquer de lisibilite.

Pas de reverse proxy authentifie natif. Contrairement a Cloudflare Access, Tailscale ne fournit pas de reverse proxy authentifie devant les applications web. L'acces se fait au niveau reseau (couche 3/4), pas au niveau applicatif (couche 7). Pour ajouter une authentification applicative, il faut combiner Tailscale avec un reverse proxy comme Traefik, Caddy ou Nginx et configurer la verification des headers Tailscale.

Fonctionnalites avancees reservees aux plans payants. L'enregistrement des sessions SSH, les logs d'audit detailles, le provisioning SCIM, la personnalisation des serveurs DERP et les ACL basees sur la posture des appareils necessitent les plans Business ou Enterprise, dont le cout peut etre significatif.

Tarification de Tailscale

Le plan Personal est gratuit pour un seul utilisateur avec jusqu'a 100 appareils. Le plan Personal Plus a 48$/an offre des domaines personnalises et le partage avec des utilisateurs externes. Le plan Starter est gratuit pour jusqu'a 3 utilisateurs et 2 subnet routers. Le plan Premium est a 6$/utilisateur/mois et inclut les ACL basees sur les groupes, les logs d'audit, le provisioning SCIM. Le plan Enterprise est sur devis avec SSO personnalise, SLA garanti et support dedie.

Cas d'usage ideaux

Scenarios d'usage avances avec Tailscale

Interconnexion multi-cloud. Un cas d'usage de plus en plus frequent est l'interconnexion de ressources reparties sur plusieurs fournisseurs cloud (AWS, GCP, Azure, OVHcloud) et des datacenters on-premise. Tailscale simplifie considerablement cette architecture : en installant Tailscale sur des instances dans chaque cloud et en activant le subnet routing, chaque reseau cloud devient accessible depuis n'importe quel noeud du tailnet. Plus besoin de configurer des VPN IPsec site-to-site entre les clouds, de gerer des peering VPC complexes ou de maintenir des tables de routage manuelles. Un cluster Kubernetes sur GKE peut communiquer directement avec un service sur une instance EC2, le tout chiffre par WireGuard.

Acces aux peripheriques IoT et embarques. Tailscale dispose de clients pour Linux ARM (Raspberry Pi, NVIDIA Jetson), ce qui permet d'integrer des peripheriques IoT et des systemes embarques dans le tailnet. Un technicien peut acceder a distance a un Raspberry Pi installe dans un site industriel, sans ouvrir de port sur le reseau du site, sans VPN concentrateur, et avec une latence minimale grace au peer-to-peer. Cette capacite est particulierement appreciee dans les scenarios de maintenance industrielle, de monitoring environnemental et de gestion de flottes de dispositifs edge.

Partage securise avec des prestataires externes. Tailscale permet de partager des noeuds specifiques avec des utilisateurs externes via la fonctionnalite de sharing. Un prestataire externe peut recevoir l'acces a un serveur de staging specifique sans avoir acces au reste du tailnet, et cet acces peut etre revoque instantanement. C'est une alternative bien plus securisee que l'ouverture d'un port SSH ou la creation d'un compte VPN pour chaque prestataire.

Cas d'usage ideaux

Tailscale est ideal pour les equipes de developpement qui ont besoin d'acceder a des environnements de staging ou de production, les organisations multi-sites souhaitant interconnecter leurs reseaux simplement, les travailleurs a distance accedant a des ressources internes (NAS, serveurs de fichiers, imprimantes), et les scenarii DevOps ou les serveurs doivent communiquer entre eux via un mesh securise.

Headscale : la souverainete totale avec un coordination server open-source

Headscale est une implementation open-source du coordination server de Tailscale, ecrite en Go. Ce projet, lance en 2021 par Juan Font, permet d'utiliser les clients Tailscale officiels (sur toutes les plateformes) avec un serveur de coordination auto-heberge, eliminant ainsi toute dependance au SaaS de Tailscale. Headscale est devenu le projet de reference pour les organisations souhaitant beneficier de l'ecosysteme Tailscale tout en conservant une souverainete totale sur leurs metadonnees.

Architecture et fonctionnement

Headscale remplace le coordination server propriertaire de Tailscale. Il implemente le protocole de coordination Tailscale (basiquement, un serveur HTTP/HTTPS qui gere l'enregistrement des noeuds, la distribution des cles, les ACL et la coordination DERP). Les clients Tailscale officiels sont configures pour pointer vers le serveur Headscale au lieu des serveurs Tailscale.

Le deploiement typique de Headscale consiste en un binaire unique ou un conteneur Docker, une base de donnees SQLite (ou PostgreSQL pour la haute disponibilite), et eventuellement un serveur DERP auto-heberge pour le relayage du trafic quand le NAT traversal echoue. Headscale supporte la gestion multi-utilisateurs via le concept de « namespaces » (renommes « users » dans les versions recentes), et les ACL au format HuJSON compatible avec le format Tailscale.

Depuis la version 0.23, Headscale dispose d'une interface web communautaire (headscale-ui) et d'une API gRPC/REST pour l'automatisation. L'authentification des noeuds se fait soit par cle pre-partagee (pre-auth key), soit par OIDC (OpenID Connect) pour une integration avec les fournisseurs d'identite.

Forces de Headscale

Souverainete totale des donnees. C'est l'argument numero un de Headscale. L'integralite du plan de controle est sous votre controle : les cles, les metadonnees de connexion, les ACL, les logs. Aucune information ne quitte votre infrastructure. Pour les organisations soumises au RGPD, a la directive NIS2, aux exigences SecNumCloud ou aux contraintes de la LPM (Loi de Programmation Militaire), c'est un avantage decisif.

Compatibilite avec l'ecosysteme Tailscale. Headscale utilise les clients Tailscale officiels sur toutes les plateformes (Linux, macOS, Windows, iOS, Android). Cela signifie que vous beneficiez de la qualite et de la stabilite des clients Tailscale (NAT traversal, WireGuard kernel, MagicDNS) sans dependre du SaaS Tailscale.

Cout nul en licences. Headscale est distribue sous licence BSD-3-Clause. Il n'y a aucun cout de licence, quel que soit le nombre d'utilisateurs ou de noeuds. Le seul cout est l'infrastructure d'hebergement (un petit VPS suffit) et le temps d'administration.

Serveurs DERP auto-heberges. Headscale permet de deployer vos propres serveurs DERP, eliminant la dependance aux serveurs de relayage de Tailscale. Vous pouvez placer des serveurs DERP dans vos propres datacenters ou chez vos fournisseurs cloud pour optimiser la latence et garantir que meme le trafic relaye reste sous votre controle.

Integration OIDC. Headscale supporte l'authentification OIDC, permettant l'integration avec Keycloak, Authentik, Dex, Azure AD, Google Workspace et tout fournisseur d'identite compatible OpenID Connect. Cette integration permet une experience utilisateur fluide avec SSO.

Faiblesses de Headscale

Fonctionnalites en retard sur Tailscale. Headscale est un projet communautaire qui reimplemente le protocole Tailscale par reverse engineering. Certaines fonctionnalites arrivent avec du retard ou ne sont pas encore supportees : Tailscale SSH (support partiel), Tailscale Funnel (non supporte), l'enregistrement des sessions (non supporte nativement), et les ACL basees sur la posture des appareils (non supportees).

Pas de support commercial. Headscale n'offre pas de support commercial officiel. En cas de probleme, vous dependez de la communaute GitHub et du serveur Discord. Pour les organisations necessitant un SLA de support, c'est un risque a evaluer.

Administration en ligne de commande. L'administration de Headscale se fait principalement via la ligne de commande (headscale CLI). L'interface web communautaire (headscale-ui) est fonctionnelle mais basique comparee au dashboard Tailscale. La gestion d'un grand nombre de noeuds et d'utilisateurs peut etre fastidieuse.

Haute disponibilite complexe. La mise en place de la haute disponibilite pour Headscale necessite une base de donnees PostgreSQL en cluster, un reverse proxy avec health checks, et une gestion soigneuse de la configuration. Ce n'est pas trivial et demande une expertise DevOps significative.

Deploiement de Headscale

Voici un exemple de deploiement Docker Compose pour Headscale :

# docker-compose.yml pour Headscale
version: "3.8"
services:
  headscale:
    image: headscale/headscale:0.23
    container_name: headscale
    restart: unless-stopped
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "8080:8080"   # API/Web
      - "3478:3478/udp" # STUN
    command: serve

  headscale-ui:
    image: ghcr.io/gurucomputing/headscale-ui:latest
    container_name: headscale-ui
    restart: unless-stopped
    ports:
      - "8443:443"

Et un fichier de configuration minimal :

# /etc/headscale/config.yaml
server_url: https://hs.example.com
listen_addr: 0.0.0.0:8080
private_key_path: /var/lib/headscale/private.key
noise:
  private_key_path: /var/lib/headscale/noise_private.key
ip_prefixes:
  - 100.64.0.0/10
  - fd7a:115c:a1e0::/48
db_type: sqlite3
db_path: /var/lib/headscale/db.sqlite
oidc:
  issuer: https://auth.example.com
  client_id: headscale
  client_secret: your-secret
dns:
  magic_dns: true
  base_domain: ts.example.com
  nameservers:
    - 1.1.1.1

Cas d'usage ideaux

Headscale est ideal pour les organisations soumises a des contraintes reglementaires strictes en matiere de souverainete des donnees, les equipes DevOps et SRE qui ont l'expertise pour gerer une infrastructure auto-hebergee, les laboratoires de recherche et universites qui beneficient du cout nul en licences, et les projets homelab ou les passionnes d'auto-hebergement souhaitant un mesh VPN sans dependance SaaS.

Pangolin : le tunnel self-hosted nouvelle generation avec Traefik et WireGuard

Pangolin est un projet open-source relativement recent qui propose une alternative self-hosted a Cloudflare Tunnel. Le concept est elegant : un serveur central Pangolin combine un reverse proxy Traefik, un tunnel WireGuard et un panneau d'administration web pour exposer des services internes de maniere securisee, sans ouvrir de port entrant sur les serveurs hebergeant les applications. Pangolin se positionne comme la solution ideale pour les administrateurs systemes et les passionnes d'auto-hebergement qui souhaitent les benefices de Cloudflare Tunnel sans la dependance au SaaS.

Architecture et fonctionnement

L'architecture de Pangolin repose sur trois composants. Le serveur Pangolin est le point d'entree public. Il heberge Traefik en tant que reverse proxy, le gestionnaire de tunnels WireGuard, et l'interface d'administration web. Ce serveur est le seul composant qui doit etre accessible depuis Internet. L'agent Pangolin (appele Newt) est un client leger installe sur chaque machine hebergeant des services a exposer. L'agent etablit un tunnel WireGuard sortant vers le serveur Pangolin, a travers lequel le trafic est achemine. Le panneau d'administration est une interface web moderne qui permet de gerer les sites, les tunnels, les certificats TLS (via Let's Encrypt) et les politiques d'acces.

Quand un utilisateur accede a un service expose via Pangolin, le flux est le suivant : la requete arrive sur le serveur Pangolin via HTTPS, Traefik identifie le service cible grace au nom de domaine (virtual host), achemine la requete a travers le tunnel WireGuard correspondant, et l'agent Newt relaye la requete vers le service local. Le certificat TLS est gere automatiquement par Traefik via Let's Encrypt. L'authentification de l'utilisateur peut etre ajoutee via un middleware d'authentification (basicauth, forwardauth avec un serveur OIDC, ou integration avec des solutions comme Authelia ou Authentik).

Forces de Pangolin

Simplicite conceptuelle. Pangolin est remarquablement simple a comprendre et a deployer. Le concept est clair : un serveur public, un agent par site, un tunnel WireGuard entre les deux. Pas de mesh complexe, pas de coordination server, pas de DERP. Cette simplicite se traduit par une surface d'attaque reduite et une maintenance facilitee.

Interface d'administration web moderne. Contrairement a Headscale ou a d'autres solutions self-hosted, Pangolin est livre avec une interface web soignee qui permet de gerer l'ensemble de la configuration : ajout de sites, gestion des agents, monitoring des tunnels, consultation des logs, et configuration des certificats TLS. C'est un avantage significatif pour les equipes qui ne souhaitent pas tout gerer en ligne de commande.

Integration Traefik native. Traefik est l'un des reverse proxies les plus populaires de l'ecosysteme cloud-native. Son integration native dans Pangolin permet de beneficier de tout l'ecosysteme Traefik : middlewares d'authentification, rate limiting, headers de securite, metriques Prometheus, etc.

Certificats TLS automatiques. Pangolin gere automatiquement les certificats TLS via Let's Encrypt (ACME). Pas besoin de gerer manuellement les certificats : chaque service expose recoit automatiquement un certificat valide et renouvele.

Zero port ouvert cote application. Comme Cloudflare Tunnel, Pangolin n'exige aucun port entrant sur les serveurs hebergeant les applications. L'agent Newt initie une connexion WireGuard sortante vers le serveur Pangolin. C'est un avantage majeur en termes de securite, car les serveurs d'application ne sont pas directement exposes sur Internet.

Faiblesses de Pangolin

Projet jeune et communaute reduite. Pangolin est un projet beaucoup plus recent que Tailscale ou Cloudflare One. La communaute est plus petite, la documentation moins fournie, et le nombre de contributeurs est limite. Cela implique un risque de perennite et un support communautaire moins reactif.

Point de defaillance unique. Le serveur Pangolin est un SPOF (Single Point of Failure). Si le serveur tombe, tous les services exposes deviennent inaccessibles. La mise en place d'une haute disponibilite n'est pas nativement supportee et necessite une architecture personnalisee avec un load balancer en amont et une synchronisation de la configuration.

Pas de mesh networking. Pangolin est une solution de tunnel point-a-point, pas un mesh VPN. Les agents ne peuvent pas communiquer directement entre eux : tout le trafic passe par le serveur Pangolin central. Pour les architectures necessitant une communication inter-noeuds, Tailscale ou Headscale sont plus adaptes.

Fonctionnalites ZTNA limitees. Pangolin est avant tout un tunnel reverse proxy, pas une solution ZTNA complete. Il ne propose pas nativement de verification de posture des terminaux, de politiques d'acces contextuelles avancees, d'enregistrement de sessions ou d'integration IdP integree (meme si cela peut etre ajoute via Traefik et un middleware forwardauth).

Deploiement de Pangolin

Voici un exemple de deploiement Docker Compose pour le serveur Pangolin :

# docker-compose.yml pour Pangolin Server
version: "3.8"
services:
  pangolin:
    image: fosrl/pangolin:latest
    container_name: pangolin
    restart: unless-stopped
    ports:
      - "443:443"
      - "80:80"
      - "51820:51820/udp"  # WireGuard
    volumes:
      - ./config:/etc/pangolin
      - ./data:/var/lib/pangolin
      - ./letsencrypt:/letsencrypt
    environment:
      - PANGOLIN_DOMAIN=tunnel.example.com
      - PANGOLIN_EMAIL=admin@example.com

Et pour l'agent Newt cote application :

# docker-compose.yml pour l'agent Newt
version: "3.8"
services:
  newt:
    image: fosrl/newt:latest
    container_name: newt
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    environment:
      - PANGOLIN_ENDPOINT=tunnel.example.com:51820
      - PANGOLIN_TOKEN=votre-token-d-enregistrement
    sysctls:
      - net.ipv4.ip_forward=1

Cas d'usage ideaux

Pangolin versus Cloudflare Tunnel : comparaison directe

Pangolin et Cloudflare Tunnel adressent le meme cas d'usage fondamental (exposer des services internes via un tunnel sortant), mais avec des philosophies radicalement differentes. Cloudflare Tunnel s'appuie sur le reseau mondial de Cloudflare, offrant une performance et une fiabilite inegalees mais au prix d'une dependance totale au SaaS. Pangolin offre la souverainete complete mais necessite de gerer son propre serveur, sa propre haute disponibilite et ses propres certificats TLS (meme si Let's Encrypt automatise largement ce dernier point).

En termes de performance, Cloudflare Tunnel beneficie de l'anycast routing et des 310+ PoP mondiaux, ce qui signifie que l'utilisateur est toujours connecte au point de presence le plus proche. Pangolin route tout le trafic via un serveur unique, ce qui peut introduire de la latence pour les utilisateurs geographiquement eloignes. Pour mitiger ce probleme, il est possible de deployer plusieurs instances Pangolin dans differentes regions et d'utiliser un GeoDNS pour router les utilisateurs vers l'instance la plus proche, mais cette architecture est significativement plus complexe.

En termes de fonctionnalites de securite, Cloudflare Tunnel beneficie de l'ecosysteme Cloudflare (WAF, DDoS protection, bot management) qui est applique automatiquement au trafic traversant le tunnel. Pangolin, utilisant Traefik, peut beneficier des middlewares de securite de Traefik (rate limiting, IP whitelist, headers de securite) mais ne dispose pas de WAF ou de protection DDoS integree. Pour les applications exposees sur Internet public, cette difference peut etre significative.

En revanche, Pangolin brille par sa transparence et sa flexibilite. L'integralite du code est auditable, la configuration est entierement sous votre controle, et l'integration avec l'ecosysteme Traefik (plugins, middlewares personnalises) offre une extensibilite que Cloudflare Tunnel ne permet pas. Pour les organisations qui ont deja une expertise Traefik, Pangolin s'integre naturellement dans l'infrastructure existante.

Cas d'usage ideaux

Pangolin est ideal pour les auto-hebergeurs souhaitant exposer des services depuis un reseau domestique sans ouvrir de port sur leur box, les petites equipes et associations cherchant une alternative self-hosted a Cloudflare Tunnel, les scenarios de developpement ou des services locaux doivent etre accessibles temporairement via Internet, et les architectures ou un nombre limite de services doit etre expose de maniere securisee.

Teleport : le plan d'acces unifie pour l'infrastructure moderne

Teleport, developpe par Gravitational (renomme Teleport), est une solution d'acces a l'infrastructure qui se distingue radicalement des autres solutions de ce comparatif. Plutot qu'un VPN ou un tunnel reseau, Teleport est un access plane unifie qui comprend et intercepte les protocoles d'infrastructure : SSH, Kubernetes API, bases de donnees (PostgreSQL, MySQL, MongoDB, Redis, Cassandra, etc.), applications web, et bureaux a distance Windows (RDP). Cette comprehension protocolaire permet des fonctionnalites uniques comme l'enregistrement complet des sessions, l'audit commande par commande et le controle d'acces granulaire au niveau de la requete.

Architecture et fonctionnement

L'architecture de Teleport repose sur plusieurs composants. Le Teleport Auth Service est le cerveau du systeme : il gere l'authentification des utilisateurs et des machines, emet des certificats x509 et SSH de courte duree (par defaut 12 heures), et applique les politiques RBAC. Le Teleport Proxy Service est le point d'entree unique pour tous les acces : il accepte les connexions des utilisateurs, verifie les certificats, et route les connexions vers les ressources cibles. Le Teleport Node/Agent est installe sur chaque serveur, cluster Kubernetes, ou serveur de base de donnees a proteger.

Le flux d'acces typique est le suivant : l'utilisateur s'authentifie aupres du proxy Teleport via SSO (SAML, OIDC) et MFA (TOTP, WebAuthn/FIDO2). Teleport emet un certificat de courte duree contenant les roles et permissions de l'utilisateur. Ce certificat est utilise pour toutes les connexions subsequentes. Quand l'utilisateur se connecte a un serveur SSH, un cluster Kubernetes ou une base de donnees, Teleport intercepte la connexion, verifie le certificat, applique les politiques RBAC, et enregistre la session.

Forces de Teleport

Enregistrement et audit des sessions. C'est la fonctionnalite signature de Teleport. Chaque session SSH est enregistree dans son integralite (entrees et sorties du terminal), chaque requete Kubernetes est journalisee, chaque requete SQL est capturee. Les sessions enregistrees peuvent etre rejouees dans l'interface web, offrant une visibilite complete sur les actions effectuees par chaque utilisateur. Cette fonctionnalite est cruciale pour la conformite (SOC 2, ISO 27001, PCI DSS, HIPAA) et pour les investigations post-incident.

Certificats de courte duree. Teleport elimine completement la gestion des cles SSH statiques, des mots de passe de base de donnees et des kubeconfig permanents. A la place, il emet des certificats x509 et SSH de courte duree (configurable, par defaut 12 heures) qui contiennent l'identite et les roles de l'utilisateur. A l'expiration du certificat, l'utilisateur doit se re-authentifier. Ce modele elimine le risque de credentials volees et reutilisees.

RBAC granulaire multi-protocole. Le systeme RBAC de Teleport est extremement granulaire. Vous pouvez definir qu'un utilisateur a acces SSH en lecture seule sur les serveurs de production, un acces admin sur les serveurs de staging, un acces en lecture seule a la base de donnees de production et un acces complet a la base de donnees de staging. Les roles peuvent inclure des conditions basees sur les labels, les metadonnees et les attributs du fournisseur d'identite.

Just-in-time access requests. Teleport permet de configurer des workflows d'acces temporaire : un developpeur peut demander un acces eleve pour une duree limitee, la demande est routee vers un approbateur (via Slack, PagerDuty, Jira, ou l'interface web), et l'acces est automatiquement revoque a l'expiration. Ce modele est conforme au principe du moindre privilege et aux exigences des audits de securite.

Support multi-protocole unifie. Teleport est la seule solution de ce comparatif qui gere nativement SSH, Kubernetes, les bases de donnees, les applications web et les bureaux Windows dans une plateforme unifiee. L'utilisateur a un seul point d'entree, une seule authentification et une vue unifiee de toutes les ressources accessibles.

Edition open-source fonctionnelle. Teleport Community Edition est open-source (licence Apache 2.0) et inclut la plupart des fonctionnalites de base : SSH, Kubernetes, bases de donnees, applications web, MFA, RBAC et enregistrement des sessions. Les editions Team et Enterprise ajoutent le SSO, le provisioning SCIM, les access requests avancees, le FedRAMP et les intergations SIEM.

Faiblesses de Teleport

Complexite de deploiement. Teleport est significativement plus complexe a deployer et a operer que Tailscale ou Pangolin. L'architecture multi-composants (Auth, Proxy, Node/Agent) necessite une planification soigneuse, et la haute disponibilite requiert un backend de stockage distribue (etcd, DynamoDB, ou Firestore). La courbe d'apprentissage est raide pour les equipes non familiarisees avec les architectures d'infrastructure modernes.

Pas un VPN/mesh network. Teleport n'est pas un VPN et ne cree pas de reseau virtuel. Il ne permet pas la communication directe entre serveurs via un reseau maille. Son perimetre est l'acces des utilisateurs humains aux ressources d'infrastructure, pas la communication machine-a-machine. Pour les besoins de mesh networking, il faut le combiner avec Tailscale ou WireGuard.

Tarification Enterprise elevee. Si l'edition Community est gratuite, les editions Team et Enterprise sont tarifees par ressource protegee et par utilisateur, et les prix peuvent etre significatifs pour les grandes organisations. Le SSO (SAML/OIDC) est reserve aux editions payantes, ce qui est un frein pour les equipes souhaitant integrer leur fournisseur d'identite existant.

Empreinte operationnelle. Teleport necessite un agent sur chaque serveur, cluster Kubernetes et serveur de base de donnees a proteger. Pour les organisations avec des centaines ou des milliers de serveurs, le deploiement et la mise a jour de ces agents representent une charge operationnelle non negligeable (meme si des mecanismes d'auto-update et des operateurs Kubernetes existent).

Tarification de Teleport

Le plan Community (open-source) est gratuit sans limite d'utilisateurs ni de ressources, mais ne dispose pas du SSO, des access requests avancees et du support commercial. Le plan Team debute a 15$/utilisateur/mois et inclut le SSO OIDC/SAML. Le plan Enterprise est sur devis et ajoute FedRAMP, HSM, les integrations SIEM avancees et le support premium. Teleport Cloud est la version SaaS entierement geree, dont la tarification est basee sur le nombre de ressources protegees.

Cas d'usage ideaux

Exemples concrets avec Teleport

Scenario d'audit PCI DSS. Une entreprise de e-commerce traitant des paiements par carte bancaire doit se conformer a PCI DSS, qui exige la tracabilite complete de tous les acces aux systemes manipulant des donnees de cartes. Avec Teleport, chaque acces SSH aux serveurs de paiement, chaque requete SQL sur la base de donnees contenant les numeros de cartes tokenises, et chaque commande kubectl sur le cluster Kubernetes hebergeant le microservice de paiement est enregistre, horodate et associe a l'identite de l'operateur. Lors de l'audit annuel PCI DSS, l'auditeur peut consulter les enregistrements de sessions, verifier que seuls les personnels autorises ont accede aux systemes en scope, et confirmer que l'authentification multi-facteurs etait active pour chaque session. Sans Teleport, cette tracabilite necessiterait l'agregation de logs provenant de multiples sources (syslog SSH, slow query log MySQL, audit log Kubernetes), un processus fastidieux et sujet aux lacunes.

Scenario de gestion des prestataires. Une ETI fait appel a un prestataire externe pour la maintenance de ses bases de donnees PostgreSQL. Avec Teleport, le prestataire recoit un acces via son fournisseur d'identite (SSO), avec un role limite aux bases de donnees de staging. Quand il a besoin d'intervenir sur la production, il soumet une demande d'acces temporaire via l'interface Teleport. Le DBA interne recoit une notification Slack, approuve la demande pour une duree de 2 heures, et l'acces est automatiquement revoque a l'expiration. Toute la session est enregistree et peut etre rejouee. Ce workflow elimine completement le besoin de partager des mots de passe de base de donnees par email ou messagerie.

Scenario d'incident response. En cas d'incident de securite, l'equipe SOC peut utiliser les enregistrements de sessions Teleport pour retracer exactement les actions effectuees par un compte potentiellement compromis. Les logs structurels permettent de rechercher par utilisateur, par ressource, par commande executee ou par fenetre temporelle. Cette capacite d'investigation forensique est un atout majeur pour reduire le temps moyen de detection (MTTD) et de reponse (MTTR) aux incidents.

Cas d'usage ideaux

Teleport excelle dans les organisations soumises a des exigences de conformite strictes (SOC 2, ISO 27001, PCI DSS, HIPAA) qui necessitent un enregistrement complet des sessions et un audit granulaire, les equipes DevOps et SRE gerant des infrastructures complexes multi-protocoles (SSH + Kubernetes + bases de donnees), les organisations souhaitant eliminer les credentials statiques (cles SSH, mots de passe de base de donnees), et les entreprises necessitant des workflows d'acces temporaire (just-in-time access).

Alternatives a considerer : Twingate, NetBird, ZeroTier, Pritunl et Zscaler ZPA

Au-dela des cinq solutions detaillees ci-dessus, le marche du ZTNA propose d'autres alternatives meritant une mention. Chacune adresse un segment ou un cas d'usage specifique.

Twingate

Twingate est une solution ZTNA SaaS qui se positionne comme un remplacement direct du VPN d'entreprise. Son architecture est similaire a celle de Cloudflare Access : un connecteur est installe dans le reseau de l'entreprise, et les utilisateurs accedent aux ressources via le client Twingate. La particularite de Twingate est sa granularite de controle : les politiques d'acces peuvent etre definies au niveau du FQDN, de l'adresse IP ou du port. Le plan gratuit inclut jusqu'a 5 utilisateurs. Twingate est une excellente option pour les PME qui ne souhaitent pas la complexite d'une solution mesh et veulent remplacer simplement leur VPN. Tarification : gratuit jusqu'a 5 utilisateurs, puis 5$/utilisateur/mois (Starter), 10$/utilisateur/mois (Business).

NetBird

NetBird (anciennement Wiretrustee) est une solution de mesh VPN open-source basee sur WireGuard, concurrente directe de Tailscale/Headscale. Sa particularite est d'offrir a la fois un SaaS et une option self-hosted complete (coordination server + management UI). NetBird propose des fonctionnalites ZTNA plus avancees que Tailscale, notamment des politiques d'acces basees sur la posture des appareils, un DNS prive, des regles de routage et un systeme de groupes. Le plan gratuit inclut jusqu'a 5 pairs. NetBird est une alternative serieuse pour les organisations souhaitant un mesh VPN open-source avec des fonctionnalites ZTNA integrees.

ZeroTier

ZeroTier est un veteran du mesh networking, fonde en 2011. Il cree des reseaux Ethernet virtuels (couche 2) entre les noeuds, contrairement a Tailscale qui opere en couche 3. Cette approche couche 2 permet des cas d'usage specifiques comme le bridging de reseaux locaux ou la decouverte de services par broadcast. ZeroTier propose un plan gratuit jusqu'a 25 noeuds. Le plan self-hosted (ZeroTier Controller) est open-source. ZeroTier est mature et fiable, mais son interface et son experience utilisateur sont moins polies que celles de Tailscale.

Pritunl

Pritunl est un serveur VPN open-source base sur OpenVPN et WireGuard, avec une interface web d'administration. Il se positionne comme une alternative a OpenVPN Access Server. Pritunl n'est pas a proprement parler une solution ZTNA (il fonctionne comme un VPN traditionnel avec authentification centralisee), mais il offre une option self-hosted gratuite pour les organisations qui souhaitent migrer depuis OpenVPN vers une solution mieux geree. L'edition Enterprise ajoute le SSO, le MFA, et la haute disponibilite.

Zscaler ZPA (Zero Trust Private Access)

Zscaler ZPA est la reference Enterprise du ZTNA, faisant partie de la plateforme Zscaler Zero Trust Exchange. C'est une solution SaaS pure, destinee aux grandes entreprises avec des milliers d'utilisateurs. ZPA offre des fonctionnalites avancees comme le CASB inline, la DLP, l'inspection TLS/SSL, et l'integration avec l'ensemble de l'ecosysteme Zscaler (ZIA pour l'acces Internet, ZDX pour le monitoring de l'experience digitale). La tarification est exclusivement sur devis et typiquement reservee aux budgets Enterprise. ZPA est un concurrent direct de Cloudflare One dans le segment des grandes entreprises.

Comparaison rapide des alternatives

Pour resumer ces cinq alternatives en un coup d'oeil : Twingate est le remplacant VPN le plus direct et le plus simple pour les PME, avec une interface d'administration particulierement soignee et un modele de tarification accessible ; NetBird est le concurrent open-source le plus serieux de Tailscale avec des fonctionnalites ZTNA integrees incluant la verification de posture des appareils et un DNS prive, le tout deployable en self-hosted ; ZeroTier est le veteran du mesh networking avec une approche couche 2 unique qui permet des cas d'usage specifiques comme le bridging de reseaux locaux et la decouverte de services par broadcast ; Pritunl est le meilleur choix pour les organisations qui veulent rester sur OpenVPN ou WireGuard classique avec une interface de gestion web intuitive et une option Enterprise pour le SSO ; et Zscaler ZPA est la reference absolue pour les grands comptes avec des milliers d'utilisateurs, des budgets consequents et des exigences de conformite internationales.

Il est important de noter que le marche ZTNA est en consolidation rapide. Plusieurs acquisitions strategiques ont eu lieu en 2024-2025 : Palo Alto Networks a acquis Talon Security pour renforcer ses capacites de navigateur securise, CrowdStrike a enrichi son offre Falcon avec des capacites ZTNA natives, et Microsoft a considerablement renforce Entra Private Access (anciennement Azure AD Application Proxy). Cette consolidation signifie que les solutions ZTNA sont de plus en plus integrees dans des plateformes de securite plus larges. Le choix entre une solution ZTNA independante et specialisee versus une solution integree dans une suite de securite existante (Microsoft, CrowdStrike, Palo Alto) est devenu un facteur de decision supplementaire pour les grandes organisations qui cherchent a rationaliser leur pile de securite.

Grand tableau comparatif des solutions ZTNA

Le tableau suivant synthetise les caracteristiques de chaque solution selon plus de quinze criteres. Il constitue un outil de reference pour une comparaison rapide et structuree.

Matrice de decision par profil d'organisation

Le choix d'une solution ZTNA depend fortement du profil de l'organisation, de sa maturite technique, de ses contraintes reglementaires et de son budget. Cette section propose des recommandations adaptees a six profils types.

Startup (1-20 utilisateurs, budget minimal)

Pour une startup, le budget est roi. La recommandation principale est Cloudflare One Free pour l'acces aux applications web (jusqu'a 50 utilisateurs gratuits) combine avec Tailscale Starter (gratuit pour 3 utilisateurs) pour le mesh networking entre les serveurs. Si l'equipe technique est solide, Headscale peut remplacer Tailscale pour eliminer tout cout. La priorite est la simplicite et la rapidite de deploiement : une startup n'a pas de temps a consacrer a l'administration d'infrastructure de securite.

PME (20-100 utilisateurs, budget modere)

Pour une PME, l'equilibre entre fonctionnalites et cout est essentiel. Tailscale Premium (6$/utilisateur/mois) offre un excellent rapport qualite-prix avec les ACL avancees, les logs d'audit et le provisioning SCIM. Pour l'acces aux applications web, Cloudflare One Pay-as-you-go (7$/utilisateur/mois) est l'option la plus complete. Si la souverainete des donnees est importante, Headscale + Pangolin forment un couple self-hosted efficace a cout de licence nul.

ETI (100-500 utilisateurs, exigences de conformite)

Pour une ETI, les exigences de conformite et d'audit deviennent preponderantes. Teleport Team (15$/utilisateur/mois) est recommande pour l'acces a l'infrastructure (SSH, bases de donnees, Kubernetes) grace a ses capacites d'enregistrement de sessions et d'audit. Pour le ZTNA applicatif, Cloudflare One Contract offre des tarifs negocies et les fonctionnalites SASE. La combinaison Teleport + Tailscale couvre l'ensemble des cas d'usage : acces infrastructure audite + mesh networking.

Grand compte (500+ utilisateurs, multi-sites, conformite stricte)

Pour un grand compte, la scalabilite, la conformite et l'integration avec l'ecosysteme existant sont les criteres dominants. Cloudflare One Enterprise ou Zscaler ZPA pour le ZTNA applicatif et la passerelle web securisee, combines avec Teleport Enterprise pour l'acces infrastructure audite, constituent l'architecture de reference. La tarification est negociee au cas par cas avec des remises volume significatives.

Equipe DevOps / SRE

Pour une equipe DevOps, l'integration avec les outils et les workflows existants est primordiale. Teleport est la recommandation numero un grace a son support natif de SSH, Kubernetes, bases de donnees et ses certificats de courte duree qui eliminent la gestion des credentials. Tailscale complete l'architecture pour le mesh networking entre les clusters et les environnements. L'integration Terraform/Pulumi des deux solutions permet une gestion Infrastructure as Code coherente.

MSP (Managed Service Provider)

Pour un MSP gerant l'infrastructure de multiples clients, la multi-tenancy et la separation stricte des environnements sont essentielles. Cloudflare One avec la gestion multi-compte via Terraform est une option, mais Teleport Enterprise avec ses trusted clusters offre la meilleure separation entre les environnements clients. Headscale deploye par client offre une isolation totale a moindre cout mais au prix d'une charge d'administration plus elevee.

Securite comparee : cryptographie, zero knowledge, audit et supply chain

La securite est le critere ultime d'une solution ZTNA. Cette section analyse en profondeur les mecanismes de securite de chaque solution.

Cryptographie et chiffrement

Toutes les solutions analysees utilisent des mecanismes cryptographiques robustes, mais avec des approches differentes. Tailscale, Headscale et Pangolin s'appuient sur WireGuard, qui utilise le chiffrement ChaCha20-Poly1305 pour le transport, Curve25519 pour l'echange de cles Diffie-Hellman, BLAKE2s pour le hachage et SipHash24 pour les hashtables. WireGuard est audite, formallement verifie et considere comme l'un des protocoles VPN les plus surs.

Cloudflare One utilise WireGuard pour le tunnel WARP et TLS 1.3 pour le proxy Access. Le trafic entre le client WARP et le reseau Cloudflare est chiffre via WireGuard, et le trafic entre Cloudflare et les applications d'origine est chiffre via TLS. Cloudflare genere et gere les certificats TLS pour les domaines personnalises.

Teleport utilise mTLS (mutual TLS) avec des certificats x509 de courte duree pour l'authentification et le chiffrement. Chaque connexion est authentifiee bilateralement : le serveur verifie le certificat du client et le client verifie le certificat du serveur. Ce modele est plus robuste que l'authentification unilaterale classique du TLS web.

Modele de confiance et zero knowledge

Le modele de confiance determine quelle entite a acces aux donnees en transit et aux metadonnees. Cloudflare One opere un modele « trust-but-verify » : Cloudflare a techniquement acces au trafic dechiffre au niveau du proxy Access (necessaire pour l'inspection et le filtrage). Pour les clients soumis a des exigences de confidentialite strictes, c'est un point d'attention majeur.

Tailscale offre un modele partiellement zero knowledge : le trafic de donnees est peer-to-peer et chiffre de bout en bout sans que les serveurs Tailscale y aient acces. Cependant, le coordination server Tailscale connait les metadonnees : qui se connecte a quoi, quand, depuis quelle IP. Les cles privees WireGuard ne quittent jamais les appareils.

Headscale et Pangolin offrent un modele totalement zero knowledge si deployes correctement : l'organisation controle l'integralite de l'infrastructure et aucune metadonnee ne quitte son perimetre. C'est l'option la plus restrictive en termes de confiance necessaire.

Teleport en mode self-hosted offre egalement un modele zero knowledge complet. En mode Cloud (SaaS), Teleport a acces aux metadonnees mais pas au contenu des sessions (les sessions enregistrees peuvent etre chiffrees avec les cles du client).

Audit et tracabilite

La capacite d'audit varie considerablement entre les solutions. Teleport est le leader inconteste avec son audit unifie multi-protocole : chaque commande SSH, chaque requete Kubernetes, chaque requete SQL est journalisee avec l'identite de l'utilisateur, l'horodatage, le resultat et le contexte. Les sessions completes peuvent etre rejouees. C'est la reference pour les audits SOC 2 et PCI DSS.

Cloudflare One offre des logs detailles via Logpush (envoi vers S3, R2, Datadog, Splunk, etc.) incluant les requetes HTTP, les connexions Gateway, les evenements Access et les alertes de securite. L'integration avec les SIEM est mature.

Tailscale propose des logs d'audit detaillant les connexions, les changements de configuration et les evenements de securite dans les plans Premium et Enterprise. L'enregistrement des sessions SSH est disponible dans les plans Business et Enterprise.

Headscale et Pangolin offrent des logs basiques (connexions, deconnexions, erreurs) mais ne disposent pas de fonctionnalites d'audit avancees natives. L'ajout d'un audit granulaire necessite l'integration avec des outils tiers.

Risque supply chain

Le risque supply chain est un critere souvent neglige mais crucial dans l'evaluation d'une solution ZTNA. Les solutions open-source (Headscale, Pangolin, Teleport Community) offrent la meilleure transparence : le code source est auditable par quiconque, les builds sont reproductibles (ou en voie de l'etre), et les dependances sont publiquement connues. Les solutions proprietaires (Cloudflare One, Tailscale SaaS) sont des boites noires partielles : meme si les clients sont open-source (cloudflared, client Tailscale), le code serveur est proprietaire et non auditable.

La question du supply chain est d'autant plus critique que les solutions ZTNA ont, par nature, un acces privilegie a l'infrastructure de l'organisation. Une compromission du coordination server Tailscale pourrait theoriquement permettre a un attaquant de manipuler les ACL et d'acceder a des ressources non autorisees. Une compromission de l'infrastructure Cloudflare pourrait exposer le trafic en transit. Ces scenarios, bien que hautement improbables compte tenu des investissements securitaires de ces entreprises, illustrent l'importance d'evaluer le risque residuel lie a la dependance a un tiers pour une fonction aussi critique que le controle d'acces.

Pour les organisations les plus sensibles, la recommandation est claire : privilegiez les solutions self-hosted open-source (Headscale, Pangolin, Teleport Community) et mettez en place un processus d'audit regulier du code source et des dependances. Pour les autres organisations, assurez-vous que l'editeur choisi dispose de certifications de securite pertinentes (SOC 2 Type II, ISO 27001), publie un rapport de transparence regulier, et offre des mecanismes de notification en cas d'incident de securite.

Gestion des identites et integration IdP

L'integration avec les fournisseurs d'identite (IdP) est un critere fondamental pour une solution ZTNA, car l'identite de l'utilisateur est le pivot central du modele Zero Trust. Toutes les solutions analysees supportent une forme d'integration IdP, mais avec des niveaux de sophistication tres differents.

Cloudflare One offre l'integration IdP la plus riche : support natif de plus de 15 fournisseurs d'identite (Okta, Azure AD, Google Workspace, OneLogin, PingIdentity, GitHub, etc.), support SAML 2.0 et OIDC, authentification multi-facteurs delechuee au fournisseur d'identite, et possibilite de combiner plusieurs fournisseurs d'identite simultanement (utile pour les organisations avec des prestataires externes utilisant un IdP different).

Tailscale s'appuie sur le fournisseur d'identite pour l'authentification initiale et supporte les principaux fournisseurs via OIDC et SAML. Le provisioning SCIM (System for Cross-domain Identity Management) est disponible dans les plans Premium et Enterprise, permettant la synchronisation automatique des utilisateurs et des groupes depuis l'IdP vers Tailscale.

Headscale supporte OIDC pour l'authentification, ce qui couvre la majorite des fournisseurs d'identite modernes. Cependant, le support SAML et le provisioning SCIM ne sont pas natifs, ce qui peut etre un frein pour les organisations utilisant des IdP anciens ou necessitant une synchronisation automatique des groupes.

Teleport offre un support IdP complet dans les editions payantes (SAML 2.0, OIDC, GitHub SSO) avec un mapping avancee des roles : les attributs et groupes de l'IdP peuvent etre directement mappe aux roles Teleport, permettant une gestion des permissions entierement pilotee par l'annuaire. L'edition Community ne supporte que l'authentification locale et GitHub SSO.

Cout total de possession sur 3 ans : analyse comparative

Le cout d'une solution ZTNA ne se limite pas au prix de la licence. Le cout total de possession (TCO) inclut les licences logicielles, l'infrastructure d'hebergement (pour les solutions self-hosted), le cout des ressources humaines pour le deploiement, l'administration et la maintenance, et les couts indirects (formation, support, temps d'indisponibilite). Nous analysons ici le TCO sur trois ans pour trois scenarios : 50, 200 et 1000 utilisateurs.

Scenario 1 : 50 utilisateurs

Pour 50 utilisateurs sur 3 ans, le TCO varie considerablement :

Cloudflare One Free : Le plan gratuit couvre 50 utilisateurs. TCO = cout d'administration estime a 2 000$ sur 3 ans (configuration initiale, maintenance mineure). TCO total : ~2 000$. C'est l'option la plus economique si le SaaS est acceptable.

Tailscale Premium : 50 utilisateurs x 6$/mois x 36 mois = 10 800$ en licences. Ajoutez 2 000$ d'administration. TCO total : ~12 800$.

Headscale self-hosted : Pas de licence. Un VPS a ~100$/mois = 3 600$ sur 3 ans. Estimation de 8 000$ en administration (deploiement, maintenance, mises a jour, troubleshooting). TCO total : ~11 600$. Le cout d'administration compense largement l'absence de licence.

Pangolin self-hosted : Pas de licence. Un VPS a ~65$/mois = 2 340$ sur 3 ans. Administration estimee a 5 000$ (plus simple a operer que Headscale). TCO total : ~7 340$.

Teleport Team : 50 utilisateurs x 15$/mois x 36 mois = 27 000$ en licences. Administration 5 000$. TCO total : ~32 000$. Le cout est justifie uniquement si les fonctionnalites d'audit et d'enregistrement de sessions sont requises par la conformite.

Scenario 2 : 200 utilisateurs

A 200 utilisateurs, les ecarts se creusent. Cloudflare One passe a environ 55 000$ (7$/utilisateur/mois + administration). Tailscale Premium atteint environ 48 000$. Headscale reste a environ 27 000$ (l'infra necessite un serveur plus costaud et potentiellement un PostgreSQL manage, mais l'absence de licence reste l'avantage decisif). Pangolin est a environ 17 000$ mais commence a montrer ses limites en termes de scalabilite. Teleport Team grimpe a environ 123 000$.

Scenario 3 : 1000 utilisateurs

A 1000 utilisateurs, les solutions Enterprise avec tarification negociee deviennent pertinentes. Cloudflare One Enterprise se negocie typiquement entre 4-5$/utilisateur/mois a ce volume, soit environ 180 000$ sur 3 ans (incluant les fonctionnalites SASE). Tailscale Enterprise se negocie similairement autour de 4-5$/utilisateur/mois, soit environ 170 000$. Headscale reste a environ 68 000$ (infrastructure plus consequente + equipe d'administration dediee). Teleport Enterprise depasse les 540 000$ au tarif standard, mais se negocie significativement a ce volume.

Migration depuis OpenVPN ou WireGuard standalone

La migration depuis un VPN traditionnel vers une solution ZTNA est un projet qui doit etre mene methodiquement. Cette section propose des guides pratiques pour les deux scenarios de migration les plus courants.

Migration depuis OpenVPN vers Tailscale

OpenVPN est encore le VPN le plus deploye en entreprise. La migration vers Tailscale peut se faire progressivement, en faisant coexister les deux solutions pendant la transition.

Phase 1 : Inventaire et planification (1-2 semaines). Identifiez tous les utilisateurs et ressources accedees via OpenVPN. Documentez les regles de pare-feu et les routes. Definissez les ACL Tailscale equivalentes.

Phase 2 : Deploiement parallel (2-4 semaines). Installez Tailscale sur les serveurs cibles en parallele d'OpenVPN. Configurez les subnet routes pour rendre les sous-reseaux existants accessibles via Tailscale. Migrez les utilisateurs pilotes.

# Installation de Tailscale sur un serveur Linux existant
curl -fsSL https://tailscale.com/install.sh | sh

# Activation avec subnet routing pour le reseau interne
sudo tailscale up --advertise-routes=10.0.0.0/24,192.168.1.0/24 \
  --accept-dns=false \
  --hostname=srv-production-01

# Verification de la connectivite
tailscale status
tailscale ping srv-database-01

Phase 3 : Migration des ACL (1-2 semaines). Traduisez les regles OpenVPN en ACL Tailscale. Voici un exemple de correspondance :

// Avant : iptables/OpenVPN route
// iptables -A FORWARD -s 10.8.0.0/24 -d 10.0.0.0/24 -p tcp --dport 5432 -j ACCEPT

// Apres : ACL Tailscale (policy file)
{
  "acls": [
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:database:5432"]
    },
    {
      "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:production:*"]
    }
  ],
  "groups": {
    "group:developers": ["user1@example.com", "user2@example.com"],
    "group:devops": ["admin@example.com"]
  },
  "tagOwners": {
    "tag:database": ["group:devops"],
    "tag:production": ["group:devops"]
  }
}

Phase 4 : Basculement et decommissionnement (1-2 semaines). Migrez les utilisateurs restants. Desactivez OpenVPN. Decomissionnez les serveurs OpenVPN. Documentez la nouvelle architecture.

Migration depuis WireGuard standalone vers Headscale

Si vous utilisez deja WireGuard en mode standalone (configuration manuelle des peers, echange de cles), la migration vers Headscale est naturelle car Headscale utilise WireGuard sous le capot via les clients Tailscale.

# 1. Deployer Headscale
docker run -d \
  --name headscale \
  -v $(pwd)/config:/etc/headscale \
  -v $(pwd)/data:/var/lib/headscale \
  -p 8080:8080 \
  -p 3478:3478/udp \
  headscale/headscale:0.23 serve

# 2. Creer un utilisateur
docker exec headscale headscale users create devteam

# 3. Generer une cle pre-auth
docker exec headscale headscale preauthkeys create \
  --user devteam \
  --reusable \
  --expiration 24h

# 4. Sur chaque machine, remplacer WireGuard standalone par Tailscale+Headscale
sudo systemctl stop wg-quick@wg0
sudo systemctl disable wg-quick@wg0

# Installer le client Tailscale
curl -fsSL https://tailscale.com/install.sh | sh

# Connecter au serveur Headscale
sudo tailscale up \
  --login-server https://hs.example.com \
  --authkey YOUR_PREAUTHKEY \
  --hostname $(hostname)

# 5. Verifier la connectivite avec les autres noeuds
tailscale status
tailscale ping other-machine

Migration des routes : Si votre configuration WireGuard standalone incluait des routes specifiques (AllowedIPs), configurez les subnet routes equivalentes dans Headscale :

# Activer le subnet routing sur un noeud
sudo tailscale up \
  --login-server https://hs.example.com \
  --advertise-routes=10.0.0.0/24,172.16.0.0/16

# Approuver la route cote Headscale
docker exec headscale headscale routes enable -r 1

Migration depuis OpenVPN vers Cloudflare Tunnel (applications web)

Pour les organisations qui utilisent OpenVPN principalement pour acceder a des applications web internes (intranet, outils de ticketing, dashboards), la migration vers Cloudflare Tunnel + Access est souvent la plus rapide et la plus impactante.

# 1. Installer cloudflared sur le serveur hebergeant l'application
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb

# 2. Authentifier cloudflared avec votre compte Cloudflare
cloudflared tunnel login

# 3. Creer un tunnel
cloudflared tunnel create intranet-tunnel

# 4. Configurer le tunnel pour pointer vers l'application locale
cat > ~/.cloudflared/config.yml << 'EOF'
tunnel: intranet-tunnel
credentials-file: /root/.cloudflared/TUNNEL_UUID.json

ingress:
  - hostname: intranet.example.com
    service: http://localhost:8080
  - hostname: gitlab.example.com
    service: http://localhost:3000
  - hostname: grafana.example.com
    service: http://localhost:3001
  - service: http_status:404
EOF

# 5. Configurer le DNS (CNAME vers le tunnel)
cloudflared tunnel route dns intranet-tunnel intranet.example.com
cloudflared tunnel route dns intranet-tunnel gitlab.example.com
cloudflared tunnel route dns intranet-tunnel grafana.example.com

# 6. Demarrer le tunnel en tant que service
sudo cloudflared service install
sudo systemctl start cloudflared

Une fois le tunnel en place, configurez les politiques Access dans le dashboard Cloudflare pour definir quels utilisateurs (groupes Azure AD, emails specifiques, etc.) peuvent acceder a chaque application.

Migration vers Teleport pour l'acces infrastructure

Pour les organisations qui utilisent actuellement des cles SSH statiques, des mots de passe de base de donnees partages et des kubeconfig permanents, la migration vers Teleport represente un changement de paradigme significatif mais extremement benefique.

# 1. Deployer Teleport Auth + Proxy (Docker Compose)
cat > teleport-compose.yml << 'TELEPORT_EOF'
version: "3.8"
services:
  teleport:
    image: public.ecr.aws/gravitational/teleport:16
    container_name: teleport
    restart: unless-stopped
    ports:
      - "443:443"
      - "3025:3025"  # Auth service
      - "3024:3024"  # Tunnel reverse
    volumes:
      - ./teleport-data:/var/lib/teleport
      - ./teleport.yaml:/etc/teleport/teleport.yaml
    entrypoint: teleport start -c /etc/teleport/teleport.yaml
TELEPORT_EOF

# 2. Configuration minimale
cat > teleport.yaml << 'CONFIG_EOF'
version: v3
teleport:
  nodename: teleport-proxy
  data_dir: /var/lib/teleport
  auth_token: votre-token-secret
auth_service:
  enabled: true
  cluster_name: prod.example.com
  authentication:
    type: local
    second_factor: "on"
    webauthn:
      rp_id: prod.example.com
proxy_service:
  enabled: true
  web_listen_addr: 0.0.0.0:443
  public_addr: teleport.example.com:443
  acme:
    enabled: true
    email: admin@example.com
ssh_service:
  enabled: false
CONFIG_EOF

# 3. Demarrer Teleport
docker compose -f teleport-compose.yml up -d

# 4. Creer un utilisateur admin
docker exec teleport tctl users add admin --roles=editor,access --logins=root,ubuntu

# 5. Sur chaque serveur, installer l'agent Teleport
curl -O https://cdn.teleport.dev/teleport-16-linux-amd64-bin.tar.gz
tar -xzf teleport-16-linux-amd64-bin.tar.gz
sudo ./teleport/install

# 6. Joindre le serveur au cluster
sudo teleport configure \
  --roles=node \
  --token=votre-join-token \
  --auth-server=teleport.example.com:443 \
  --output=/etc/teleport.yaml

sudo systemctl enable teleport && sudo systemctl start teleport

La migration des acces SSH est progressive : commencez par les serveurs les moins critiques, validez que l'enregistrement des sessions fonctionne correctement, puis migrez les serveurs de production. Une fois tous les serveurs migres, desactivez l'authentification SSH par cle/mot de passe au profit exclusif des certificats Teleport. Les cles SSH statiques sont revoquees et les fichiers authorized_keys nettoyes.

Bonnes pratiques de migration

Quelle que soit la solution cible, certaines bonnes pratiques s'appliquent universellement lors de la migration depuis un VPN traditionnel.

Inventaire exhaustif des flux. Avant toute migration, cartographiez l'ensemble des flux passant par le VPN : quels utilisateurs accedent a quelles ressources, via quels protocoles, a quelle frequence. Utilisez les logs du concentrateur VPN et des pare-feux pour etablir cette cartographie. Les flux non documentes (souvent les plus anciens) sont ceux qui causeront le plus de problemes lors de la migration.

Coexistence pendant la transition. Maintenez le VPN existant en parallele de la solution ZTNA pendant toute la phase de migration. Definissez des criteres de succes clairs (nombre d'utilisateurs migres, incidents signales, metriques de performance) avant de decommissionner le VPN. Prevoyez un plan de rollback permettant de rebasculer sur le VPN en cas de probleme critique.

Formation des utilisateurs. Le changement d'outil d'acces impacte directement les utilisateurs finaux. Prevoyez des sessions de formation, une documentation utilisateur claire, et un support dedie pendant les premieres semaines. Les solutions comme Tailscale et Cloudflare One, qui offrent une experience utilisateur transparente (pas de client VPN a lancer manuellement), facilitent grandement l'adoption.

Tests de securite post-migration. Apres la migration, effectuez des tests de penetration cibles pour verifier que la nouvelle architecture ZTNA offre bien le niveau de segmentation attendu. Verifiez qu'un utilisateur authentifie ne peut acceder qu'aux ressources autorisees par sa politique, qu'un mouvement lateral est impossible, et que les mecanismes d'authentification (MFA, certificats) fonctionnent correctement dans tous les scenarios (reseau d'entreprise, teletravail, hotspot public).

Tendances 2026-2027 : SASE, politiques pilotees par l'IA et post-quantique

Le marche du ZTNA evolue rapidement. Plusieurs tendances majeures vont faconner le paysage dans les 18 prochains mois.

Convergence SASE (Secure Access Service Edge)

La convergence entre ZTNA, SWG (Secure Web Gateway), CASB, FWaaS (Firewall as a Service) et SD-WAN sous l'ombrelle SASE s'accelere. Gartner prevoit que d'ici fin 2027, plus de 50% des organisations auront adopte une architecture SASE convergee, contre environ 15% en 2024. Cloudflare One et Zscaler sont les mieux positionnes sur cette tendance. Les solutions purement ZTNA comme Tailscale devront soit s'integrer dans des ecosystemes SASE tiers, soit etendre leur perimetre fonctionnel.

Politiques d'acces pilotees par l'IA

L'intelligence artificielle commence a transformer la maniere dont les politiques d'acces sont definies et appliquees. Les tendances incluent la detection d'anomalies comportementales en temps reel (un utilisateur accedant a des ressources inhabituelles a des heures inhabituelles), la recommandation automatique de politiques basees sur les patterns d'acces observes (least privilege automatique), l'evaluation continue du risque contextuel (risque geopolitique, risque de l'appareil, risque comportemental) et la reponse automatisee aux incidents (revocation d'acces automatique en cas de detection d'une compromission).

Cloudflare a commence a integrer des fonctionnalites AI dans sa plateforme avec les recommandations de politiques et la detection d'anomalies. Teleport explore l'utilisation de modeles de langage pour l'analyse des sessions enregistrees et la detection de commandes suspectes. Ces fonctionnalites sont encore emergentes mais deviendront differenciantes d'ici 2027.

Cryptographie post-quantique

L'avenement des ordinateurs quantiques menace les algorithmes cryptographiques actuels (RSA, ECDSA, Curve25519). Le NIST a finalise en 2024 les standards de cryptographie post-quantique (ML-KEM pour l'encapsulation de cles, ML-DSA pour les signatures). Les solutions ZTNA doivent anticiper cette transition.

Cloudflare est en avance sur ce sujet, ayant deploye des echanges de cles post-quantiques hybrides (X25519 + ML-KEM-768) sur l'ensemble de son reseau des 2024. Le trafic du tunnel WARP beneficie deja de cette protection. WireGuard, utilise par Tailscale, Headscale et Pangolin, utilise actuellement Curve25519 qui est vulnerable aux attaques quantiques. Des propositions d'extension post-quantique pour WireGuard existent (Rosenpass, PQ-WireGuard) mais ne sont pas encore mainstream. Teleport, utilisant TLS, beneficiera des mises a jour post-quantiques de TLS au fur et a mesure de leur standardisation.

La question « harvest now, decrypt later » (capturer du trafic chiffre aujourd'hui pour le dechiffrer quand les ordinateurs quantiques seront disponibles) rend cette transition urgente pour les organisations manipulant des donnees sensibles a long terme (secrets d'Etat, propriete intellectuelle, donnees de sante).

Identite decentralisee et verifiable credentials

L'emergence des identites decentralisees (DID) et des verifiable credentials (VC) pourrait transformer l'authentification ZTNA. Plutot que de dependre d'un fournisseur d'identite centralise, les utilisateurs pourraient presenter des attestations verifiables cryptographiquement (diplomes, certifications de securite, habilitations) directement aux solutions ZTNA, sans intermediaire. Cette tendance est encore experimentale mais pourrait devenir significative d'ici 2028-2030.

ZTNA pour les environnements OT et IoT industriel

Un domaine en pleine expansion est l'application du ZTNA aux environnements OT (Operational Technology) et IoT industriel. Traditionnellement, les reseaux industriels (SCADA, automates programmables, capteurs) etaient isoles par un air gap physique ou des pare-feux de segmentation. La convergence IT/OT et la necessite d'acceder a distance aux systemes industriels (pour la maintenance predictive, le monitoring en temps reel, l'optimisation des processus) creent un besoin croissant de ZTNA adapte aux contraintes specifiques de l'OT : latence ultra-faible, support des protocoles industriels proprietaires (Modbus TCP, OPC UA, BACnet, PROFINET), compatibilite avec des equipements anciens ne supportant pas les agents logiciels modernes, et resilience aux deconnexions intermittentes.

Les solutions basees sur le subnet routing (Tailscale, Headscale) sont les mieux adaptees a ce scenario, car elles permettent de rendre un sous-reseau OT accessible sans installer d'agent sur les equipements industriels eux-memes. Un gateway Tailscale ou Headscale est installe dans la DMZ industrielle et annonce le sous-reseau OT au tailnet. L'acces est controle par les ACL, et le trafic est chiffre par WireGuard. Cette approche respecte le principe de defense en profondeur recommande par le modele Purdue tout en eliminant le besoin d'un VPN site-to-site traditionnel. Teleport est egalement pertinent pour les acces aux interfaces d'administration des equipements OT accessibles en SSH ou via des interfaces web, avec l'avantage de l'enregistrement des sessions pour la tracabilite des interventions de maintenance.

Micro-segmentation et service mesh

La convergence entre ZTNA et service mesh (Istio, Linkerd, Cilium) est une tendance emergente. Les service meshes gerent la communication securisee entre microservices au sein d'un cluster Kubernetes, tandis que le ZTNA gere l'acces des utilisateurs aux applications. L'integration des deux permet une architecture Zero Trust de bout en bout, de l'utilisateur jusqu'au microservice individuel. Certains acteurs commencent a proposer des solutions unifiees : Cilium, par exemple, combine un CNI Kubernetes, un service mesh base sur eBPF et des fonctionnalites de securite reseau avancees dans une plateforme unique. L'avenir pourrait voir les solutions ZTNA et les service meshes converger vers des plateformes unifiees de securite reseau Zero Trust.

FAQ : les 10 questions les plus frequentes sur le ZTNA

Le Zero Trust remplace-t-il completement le VPN ?

Oui et non. Le ZTNA remplace le VPN pour l'acces des utilisateurs aux applications et aux ressources. Cependant, certains cas d'usage specifiques peuvent encore necessiter un VPN classique : l'acces a des protocoles non-HTTP/S qui ne sont pas supportes par la solution ZTNA choisie, la connexion de sites distants via des tunnels site-to-site (bien que les mesh VPN comme Tailscale adressent de plus en plus ce besoin), ou la compatibilite avec des equipements legacy qui ne supportent pas les clients ZTNA modernes. La strategie recommandee est de migrer progressivement vers le ZTNA en commencant par les applications web, puis les acces SSH et bases de donnees, et de ne conserver le VPN que pour les cas d'usage residuels.

Quelle solution ZTNA choisir pour moins de 10 utilisateurs ?

Pour une tres petite equipe, trois options se distinguent : Cloudflare One Free (50 utilisateurs gratuits, ideal pour les applications web), Tailscale Starter (gratuit pour 3 utilisateurs, ideal pour le mesh networking), ou Headscale (gratuit et illimite, mais necessite un serveur et de l'administration). Si votre besoin est d'acceder a des applications web internes, Cloudflare One Free est imbattable. Si vous avez besoin d'un reseau prive entre vos machines, Tailscale est le plus simple. Si la souverainete des donnees est critique, Headscale est le choix oblige.

Tailscale ou Headscale : lequel choisir ?

Le choix entre Tailscale et Headscale se resume a un compromis entre simplicite et souverainete. Choisissez Tailscale si vous voulez une solution qui fonctionne immediatement, sans serveur a gerer, avec un support commercial et des fonctionnalites avancees (device posture, session recording, SCIM). Choisissez Headscale si vous avez des exigences de souverainete des donnees, si vous ne voulez pas que vos metadonnees transitent par un tiers, ou si vous avez l'expertise DevOps pour gerer un serveur supplementaire. Un cas intermediaire : commencer avec Tailscale pour le deploiement initial, puis migrer vers Headscale une fois la maturite atteinte.

Cloudflare One est-il sur pour les donnees sensibles ?

Cloudflare One utilise un chiffrement robuste et dispose de certifications SOC 2 Type II, ISO 27001 et FedRAMP (pour le gouvernement americain). Cependant, il faut comprendre que le trafic est dechiffre au niveau du proxy Cloudflare Access, ce qui signifie que Cloudflare a techniquement la capacite de lire le contenu des requetes. Pour la plupart des organisations, les engagements contractuels et les certifications de Cloudflare offrent un niveau de confiance suffisant. Pour les organisations manipulant des donnees classifiees, des secrets d'Etat ou des donnees soumises a des reglementations nationales strictes (defense, renseignement), une solution self-hosted est recommandee. Cloudflare propose des options de localisation des donnees (Data Localization Suite) pour les clients Enterprise qui souhaitent que leurs donnees soient traitees dans une region specifique.

Teleport vaut-il son prix par rapport aux alternatives ?

Teleport est la solution la plus chere de ce comparatif en termes de licence par utilisateur. Son prix se justifie si votre organisation a besoin d'au moins un des elements suivants : l'enregistrement complet des sessions SSH/Kubernetes/base de donnees pour la conformite, l'elimination des credentials statiques via les certificats de courte duree, des workflows d'acces temporaire (just-in-time) avec approbation, ou un audit multi-protocole unifie. Si vous n'avez besoin que d'un acces reseau securise sans ces fonctionnalites d'audit avancees, Tailscale ou Cloudflare One sont des choix plus economiques et plus simples. L'edition Community (gratuite) est cependant une excellente option pour les organisations qui acceptent de gerer leur propre infrastructure et n'ont pas besoin du SSO SAML.

Comment combiner plusieurs solutions ZTNA ?

Il est tout a fait courant et recommande de combiner plusieurs solutions pour couvrir l'ensemble des cas d'usage. L'architecture la plus frequente combine Cloudflare One pour le ZTNA applicatif (acces aux applications web), Tailscale ou Headscale pour le mesh networking (communication inter-serveurs, acces aux ressources non-web), et Teleport pour l'acces infrastructure audite (SSH, Kubernetes, bases de donnees). Chaque solution adresse un segment specifique sans conflit. La cle est de definir clairement le perimetre de chaque solution et d'eviter les chevauchements qui complexifieraient l'architecture.

Le ZTNA est-il compatible avec les environnements on-premise legacy ?

Oui, toutes les solutions analysees supportent les environnements on-premise. Cloudflare Tunnel peut exposer n'importe quelle application accessible localement, y compris les applications legacy sur des serveurs physiques. Tailscale s'installe sur Linux, Windows et macOS, y compris des versions anciennes, et le subnet routing permet de rendre accessibles des machines sur lesquelles Tailscale ne peut pas etre installe. Pangolin fonctionne de la meme maniere via son agent Newt. Teleport supporte les serveurs SSH legacy et peut meme proteger les acces RDP aux serveurs Windows anciens. Le ZTNA n'exige pas une refonte de l'infrastructure existante ; il s'ajoute en surcouche.

Quelle est la latence ajoutee par une solution ZTNA ?

La latence ajoutee depend de l'architecture de la solution et c'est un critere souvent surestime par les decideurs. Les solutions mesh peer-to-peer (Tailscale, Headscale) ajoutent une latence negligeable, generalement inferieure a 1 milliseconde sur le meme reseau local et de 1 a 3 millisecondes entre sites distants, car le trafic circule directement entre les noeuds sans intermediaire. Le chiffrement WireGuard ChaCha20-Poly1305 est extremement performant et ajoute un overhead CPU minimal, meme sur des appareils mobiles ou des Raspberry Pi. Les solutions proxy/tunnel (Cloudflare, Pangolin) ajoutent la latence d'un aller-retour supplementaire vers le serveur proxy. Pour Cloudflare, cette latence est minimisee par la proximite des points de presence et se situe generalement entre 5 et 15 millisecondes, ce qui est imperceptible pour la plupart des applications web. Pour Pangolin, la latence depend de la localisation geographique du serveur central par rapport aux utilisateurs et aux applications. Teleport ajoute la latence du proxy protocolaire, qui est generalement de l'ordre de 2 a 5 millisecondes, un overhead acceptable meme pour des sessions SSH interactives. En comparaison, un VPN OpenVPN classique ajoute typiquement 5 a 20 millisecondes de latence en raison de l'overhead du protocole TLS dans l'espace utilisateur, ce qui signifie que la plupart des solutions ZTNA offrent une performance egale ou superieure au VPN qu'elles remplacent.

Comment gerer la conformite RGPD avec une solution ZTNA SaaS ?

Le RGPD impose que les donnees personnelles des citoyens europeens soient traitees conformement a certaines regles, incluant la minimisation des donnees, le droit a l'effacement et les garanties en cas de transfert hors UE. Pour les solutions SaaS americaines (Cloudflare, Tailscale), verifiez les mecanismes de transfert (Data Privacy Framework, clauses contractuelles types), activez la localisation des donnees si disponible (Cloudflare Data Localization Suite), et documentez les sous-traitants (article 28 RGPD). Pour les solutions self-hosted (Headscale, Pangolin), la conformite RGPD est simplifiee car aucune donnee ne quitte votre infrastructure. Pour Teleport, l'edition self-hosted offre le meme avantage, et l'edition Cloud propose des options de localisation regionale.

Comment mesurer le retour sur investissement d'une migration ZTNA ?

Le ROI d'une migration ZTNA se mesure sur plusieurs axes. Le premier est la reduction du risque cyber : selon une etude Forrester de 2025, les organisations ayant adopte le ZTNA constatent une reduction de 50 a 70% du nombre d'incidents lies a des acces non autorises. Le deuxieme axe est la productivite des equipes IT : l'elimination de la gestion des concentrateurs VPN, des cles SSH statiques et des regles de pare-feu manuelles libere un temps significatif. Pour une equipe IT de 5 personnes, l'estimation est de 15 a 25 heures par mois economisees. Le troisieme axe est la reduction des temps d'onboarding : avec un VPN traditionnel, l'onboarding d'un nouveau collaborateur necessite la creation d'un compte VPN, la distribution de certificats, la configuration du client et souvent un appel au support. Avec un ZTNA base sur l'IdP (Cloudflare, Tailscale, Teleport), l'onboarding est automatique : des que l'utilisateur est provisionne dans l'annuaire (Azure AD, Okta), il a automatiquement acces aux ressources associees a son role. Enfin, le quatrieme axe est la conformite facilitee : les rapports d'audit generes par les solutions ZTNA (notamment Teleport et Cloudflare) reduisent considerablement le temps et le cout de preparation aux audits SOC 2, ISO 27001 et PCI DSS.

Quel avenir pour le ZTNA face a l'informatique quantique ?

L'informatique quantique menace les algorithmes cryptographiques a cle publique utilises par toutes les solutions ZTNA (Curve25519 pour WireGuard, RSA/ECDSA pour TLS). La transition vers la cryptographie post-quantique est en cours mais inegale selon les solutions. Cloudflare est le plus avance, ayant deploye des echanges de cles hybrides (classiques + post-quantiques) sur l'ensemble de son reseau. WireGuard (utilise par Tailscale, Headscale, Pangolin) necessite des extensions post-quantiques qui sont en cours de developpement. L'horizon de menace est estime a 5-15 ans pour les ordinateurs quantiques cryptographiquement pertinents, mais le risque « harvest now, decrypt later » rend la transition urgente pour les donnees a longue duree de vie. Recommandation : privilegiez les solutions qui offrent deja des options post-quantiques ou qui s'engagent sur une feuille de route claire.

Conclusion : quelle solution ZTNA pour quel contexte ?

Ce comparatif approfondi a analyse six solutions ZTNA majeures sous tous les angles : architecture, securite, fonctionnalites, tarification, deploiement et tendances futures. Il n'existe pas de solution universelle ; le choix optimal depend du contexte specifique de chaque organisation. Voici nos recommandations synthetiques.

Choisissez Cloudflare One si vous cherchez une solution SASE tout-en-un avec ZTNA, passerelle web securisee et CASB, si vous avez des equipes distribuees mondialement qui beneficieront du reseau de 310+ PoP, ou si vous etes une petite equipe (moins de 50 utilisateurs) cherchant une solution gratuite et professionnelle. C'est la solution la plus polyvalente et la plus simple a deployer pour l'acces aux applications web.

Choisissez Tailscale si votre besoin principal est le mesh networking (communication inter-serveurs, acces a des ressources reseau), si vous valorisez la simplicite extreme d'installation et la performance WireGuard peer-to-peer, ou si vous etes une equipe DevOps qui a besoin d'un reseau prive virtuel entre des serveurs repartis sur plusieurs sites ou clouds. C'est la reference du mesh VPN moderne.

Choisissez Headscale si la souverainete des donnees est un imperatif non negociable (contraintes reglementaires, politique interne), si vous avez l'expertise DevOps pour gerer un serveur de coordination, ou si vous souhaitez beneficier de l'ecosysteme Tailscale sans la dependance au SaaS. C'est le choix de la liberte et de la souverainete.

Choisissez Pangolin si vous cherchez une alternative self-hosted a Cloudflare Tunnel avec une interface web moderne, si vous etes un auto-hebergeur ou une petite equipe qui veut exposer des services web sans ouvrir de port, ou si vous appreciez la simplicite d'un tunnel point-a-point plutot que la complexite d'un mesh. C'est l'outil ideal pour l'auto-hebergement securise.

Choisissez Teleport si vous avez des exigences de conformite strictes (SOC 2, PCI DSS, HIPAA, ISO 27001) necessitant l'enregistrement des sessions et l'audit granulaire, si vous gerez une infrastructure complexe multi-protocole (SSH + Kubernetes + bases de donnees), ou si vous souhaitez eliminer les credentials statiques avec des certificats de courte duree. C'est la reference pour l'acces infrastructure audite.

Choisissez une combinaison si vos besoins couvrent plusieurs categories. Par exemple, une ETI avec des developpeurs accedant a des serveurs de production, des equipes metier accedant a des applications web internes, et des prestataires externes necessitant un acces controle et audite, beneficiera d'une architecture combinant Cloudflare One pour les applications web (ZTNA applicatif avec reverse proxy authentifie), Tailscale ou Headscale pour le mesh networking entre les serveurs et les environnements cloud (communication machine-to-machine securisee), et Teleport pour l'acces SSH et base de donnees des administrateurs (avec enregistrement des sessions et certificats de courte duree). Cette approche multi-couches garantit que chaque type d'acces est gere par l'outil le plus adapte, sans compromis.

Enfin, n'hesitez pas a combiner les solutions : l'architecture la plus robuste utilise souvent Cloudflare One pour le ZTNA applicatif, Tailscale/Headscale pour le mesh networking, et Teleport pour l'audit infrastructure. Le Zero Trust n'est pas un produit a acheter, c'est une architecture a construire — et les solutions analysees dans ce comparatif sont les briques fondamentales de cette architecture.

Pour aller plus loin, consultez nos guides detailles : le guide complet de Cloudflare Tunnel et Zero Trust Access, Tailscale : le mesh VPN WireGuard pour l'entreprise, Headscale : deployer votre propre serveur de coordination Tailscale, et Teleport : securiser l'acces a votre infrastructure avec le Zero Trust. Pour une perspective plus large sur l'evolution du paysage ZTNA, consultez le document NIST SP 800-207 sur l'architecture Zero Trust, le rapport Gartner sur le marche ZTNA, et l'analyse de l'ENISA sur le Zero Trust en Europe.