ZTNA

01 — DéfinitionQu'est-ce que le ZTNA ?

Le ZTNA (Zero Trust Network Access) est un modèle d'accès distant qui applique concrètement les principes du Zero Trust à la connexion des utilisateurs aux applications de l'entreprise. Au lieu d'ouvrir un tunnel réseau donnant accès à un périmètre entier, le ZTNA accorde des accès applicatifs granulaires après vérification continue de l'identité, de l'appareil et du contexte.

Le terme a été popularisé par Gartner en 2019 à travers son cadre SASE (Secure Access Service Edge). ZTNA s'inscrit dans la continuité du rapport fondateur BeyondCorp publié par Google à partir de 2014, qui documentait comment le géant avait remplacé son VPN d'entreprise par un modèle basé sur l'identité accessible depuis n'importe quel réseau.

Les trois piliers du ZTNA :

• Accès applicatif, pas réseau : l'utilisateur accède à une application précise (SAP, Jira, un partage interne), pas à un sous-réseau entier contenant cette application.
• Vérification continue du contexte : identité vérifiée, appareil conforme (antivirus à jour, chiffrement disque, version OS), localisation cohérente, comportement normal. Une dégradation d'un critère peut réduire les droits en cours de session.
• Invisibilité réseau : les applications protégées ne sont pas exposées à Internet. Un attaquant qui scanne Internet ne trouve pas de passerelle à attaquer — c'est le principe du dark cloud.

Le ZTNA s'intègre naturellement avec l'IAM, l'MFA (idéalement FIDO2), et les outils de conformité des postes (EDR, MDM). Il est souvent déployé dans le cadre plus large d'une plateforme SASE.

Le VPN a été conçu pour étendre un réseau d'entreprise à distance. Le ZTNA part d'un constat différent : le réseau d'entreprise lui-même n'est plus une zone de confiance. Peu importe d'où vient la connexion, l'accès se vérifie à chaque fois.

02 — ContextePourquoi remplacer le VPN ?

Le VPN traditionnel en bref

Le VPN d'entreprise (IPsec ou SSL VPN) établit un tunnel chiffré entre l'appareil de l'utilisateur et une passerelle VPN. Une fois connecté, l'utilisateur se retrouve logiquement « dans » le réseau d'entreprise et peut joindre les ressources internes selon les règles de routage et de pare-feu. Ce modèle a bien fonctionné pendant trente ans dans un contexte où :

• Les applications étaient centralisées dans le datacenter.
• Les utilisateurs étaient majoritairement au bureau.
• Le périmètre de l'entreprise était un concept réseau clair.
• Les menaces venaient surtout de l'extérieur du périmètre.

Les limites devenues critiques

Confiance implicite trop large

Une fois dans le tunnel VPN, l'utilisateur a typiquement accès à un large sous-réseau. Si son poste est compromis (malware, ransomware), l'attaquant peut se déplacer latéralement dans ce périmètre. Les grands incidents ransomware de 2020-2024 ont massivement exploité des connexions VPN compromises comme vecteur initial.

Passerelles exposées à Internet

Une passerelle VPN doit être accessible depuis Internet, ce qui en fait une cible permanente. Les CVE récurrentes sur Fortinet FortiGate, Pulse Secure (Ivanti Connect Secure), Cisco ASA, Citrix NetScaler et SonicWall ont fait des ravages : plusieurs dizaines de milliers d'entreprises compromises par simple exploitation de vulnérabilités 0-day ou 1-day sur leur passerelle VPN entre 2020 et 2024.

Applications désormais distribuées

Les applications sont aujourd'hui dispersées : SaaS (Microsoft 365, Salesforce, ServiceNow), cloud public (AWS, Azure, GCP), cloud privé, datacenter on-premise, edge. Concentrer tout le trafic sur un VPN vers le siège pour ensuite ressortir vers le cloud n'a plus aucun sens — c'est le phénomène du backhauling qui dégrade la performance sans apporter de sécurité.

Mobilité généralisée

Le télétravail permanent post-2020, l'usage massif du mobile et les appareils personnels rendent le modèle « poste au bureau dans le périmètre » caduc. Les utilisateurs se connectent depuis n'importe où, et le concept même de « réseau d'entreprise » s'efface.

Granularité insuffisante

Avec un VPN classique, donner à un prestataire externe l'accès à une seule application interne précise est compliqué : on lui donne souvent beaucoup plus que nécessaire, ou on renonce à l'accès. Le ZTNA répond nativement à ce besoin d'accès très ciblé (une seule URL, un seul service).

Charge opérationnelle élevée

Les VPN classiques exigent maintenance, capacity planning, mises à jour de certificats, mises à jour de firmware critiques, gestion des clients sur tous les postes. Le ZTNA en mode cloud-delivered réduit significativement cette charge.

03 — FonctionnementArchitecture typique

Les trois composants clés

1. Le client (agent ou agentless)

Sur l'appareil de l'utilisateur, deux options :

• Agent léger : client installé qui gère l'authentification, la posture de l'appareil, la connexion aux applications. Modèle par défaut pour les postes gérés.
• Sans agent (agentless) : accès via navigateur à des applications web ou via reverse proxy, sans installation. Utile pour les prestataires externes et les BYOD.

2. Le broker / plan de contrôle

Composant central, généralement cloud-delivered :

• Vérifie l'identité via l'IdP (Entra ID, Okta, Google, Ping).
• Récupère la posture de l'appareil (EDR, MDM, antivirus, version OS).
• Applique les politiques d'accès (qui peut accéder à quoi, dans quel contexte).
• Autorise ou refuse chaque demande d'accès en continu.
• Journalise toutes les décisions pour audit et détection.

3. Le connecteur applicatif

Composant déployé à côté des applications protégées (dans le datacenter, dans le cloud privé, à côté des bases de données). Particularité clé : il initie une connexion sortante vers le broker cloud, jamais entrante. Résultat : les applications n'ont aucun port ouvert sur Internet. Cette approche, souvent appelée dark cloud, empêche le scan et la reconnaissance par des attaquants externes.

Flux de connexion typique

1. L'utilisateur lance l'application (navigateur ou client métier).
2. Le client ZTNA intercepte la connexion et l'oriente vers le broker.
3. Le broker vérifie l'identité (authentification forte + MFA).
4. Le broker évalue la posture de l'appareil (chiffré, patché, EDR actif, conforme).
5. Le broker évalue le contexte (heure, géolocalisation, IP connue, comportement normal).
6. Si toutes les conditions sont remplies, le broker autorise la connexion via le connecteur applicatif à l'application spécifique demandée.
7. Tout au long de la session, les conditions sont revérifiées — une dégradation (EDR désactivé, IP inhabituelle, détection d'anomalie) peut couper la connexion ou imposer une ré-authentification.

Politiques contextuelles

Les politiques ZTNA peuvent être très granulaires :

• L'équipe RH accède à Workday en France pendant les heures ouvrables avec un poste chiffré et EDR actif.
• Les administrateurs accèdent au serveur de production uniquement depuis un poste dédié (PAW) avec authentification FIDO2.
• Les prestataires externes accèdent à une application métier spécifique, sans pouvoir voir les autres ressources.
• Un utilisateur qui se connecte depuis un pays inhabituel voit sa session dégradée (authentification renforcée, accès en lecture seule).

Intégration IdP et MFA

Le ZTNA repose entièrement sur l'identité. L'intégration avec un IdP solide (Entra ID, Okta, Ping Identity, Google Workspace) est indispensable. Les exigences d'authentification adaptatives (MFA conditionnelle, step-up authentication) sont pilotées conjointement par l'IdP et le broker ZTNA.

04 — ModèlesLes deux approches architecturales

Service-initiated ZTNA (modèle broker cloud)

Modèle dominant en 2026. Un broker cloud orchestre les connexions. Les connecteurs déployés près des applications initient des connexions sortantes vers le broker. Les utilisateurs se connectent au broker, qui relaie vers les applications via les connecteurs.

Avantages :

• Aucune exposition des applications sur Internet.
• Déploiement rapide — pas d'infrastructure à monter.
• Scalabilité élastique (cloud-delivered).
• Performance globale avec POP distribués.
• Intégration naturelle avec SASE et SSE.

Inconvénients : dépendance à un fournisseur cloud, bande passante qui transite par le broker, considérations de souveraineté de données.

Acteurs : Zscaler ZPA, Cloudflare Access, Netskope Private Access, Palo Alto Prisma Access, Cato Networks, Cisco Secure Access, Fortinet FortiSASE, Check Point Harmony Connect.

Endpoint-initiated ZTNA (modèle SDP classique)

Modèle plus proche de la spécification SDP (Software-Defined Perimeter) originelle. Le client agent initie les connexions directement vers les applications, après authentification via un contrôleur. Les applications restent invisibles pour les clients non authentifiés via des techniques de « single packet authorization ».

Avantages :

• Performance optimale (connexion directe).
• Contrôle total sur l'infrastructure.
• Adapté aux environnements très sensibles ou souverains.

Inconvénients : déploiement plus complexe, mise à l'échelle manuelle, nécessite une infrastructure de contrôleur à gérer.

Acteurs : Twingate, Tailscale, NetFoundry, Appgate SDP (racheté par One Identity). Ce modèle est aussi souvent adopté dans des environnements plus légers ou auto-hébergés.

Choix du modèle

En 2026, le modèle cloud broker est dominant pour les organisations de taille moyenne et grande. Le modèle SDP reste pertinent pour les environnements qui veulent minimiser les dépendances cloud ou qui ont des exigences de souveraineté très strictes. Certaines plateformes (Cloudflare, Zscaler) supportent les deux approches selon les cas d'usage.

05 — MarchéPaysage des solutions en 2026

Leaders SASE/SSE intégrés

• Zscaler (Zscaler Private Access — ZPA) : pionnier et leader du marché, positionnement SASE complet.
• Palo Alto Networks (Prisma Access) : intégration forte avec le reste de la gamme Palo Alto.
• Netskope (Netskope Private Access) : leader de la sécurité cloud, plateforme SSE complète.
• Cloudflare (Cloudflare Access / Zero Trust) : offre compétitive avec modèle tarifaire accessible, forte intégration développeurs.
• Cato Networks : pure-player SASE, approche convergée réseau + sécurité.
• Fortinet (FortiSASE) : offre SASE intégrée à la gamme Forti complète.
• Check Point (Harmony Connect) : offre SSE dérivée du socle Check Point.
• Akamai (Enterprise Application Access — EAA) : positionnement CDN + sécurité applicative.

Acteurs de l'identité et du réseau

• Microsoft (Entra Private Access) : offre relativement récente (2023), intégrée à l'écosystème Entra ID / Microsoft 365. Attrait fort pour les clients déjà engagés dans M365.
• Cisco (Duo Network Gateway, Cisco Secure Access) : convergence avec l'offre Duo MFA.
• Okta : partenariats avec plusieurs acteurs ZTNA plutôt que solution propre.

Acteurs spécialisés et challengers

• Twingate : offre moderne orientée DevOps, installation simple, tarification accessible.
• Tailscale : positionnement original basé sur WireGuard, très populaire dans les équipes techniques et les PME.
• Banyan Security : acquis par SonicWall en 2023, intégré à l'offre Cloud Secure Edge.
• Appgate SDP : spécialiste historique du SDP, orientation grandes entreprises et secteurs régulés.

Acteurs français et européens

Quelques acteurs nationaux : Thales propose des offres pour le secteur défense et souverain. Orange Cyberdefense, Atos et Capgemini intègrent et opèrent des solutions ZTNA pour des clients français et européens. Des offres plus légères émergent autour de WireGuard et de composants open source pour les environnements souverains.

Critères de choix

• Intégration avec l'écosystème existant (IdP, EDR, MDM).
• Périmètre SASE visé — ZTNA seul ou plateforme complète.
• Couverture géographique des POP (performance pour les utilisateurs mondiaux).
• Souveraineté et conformité (hébergement UE, certifications).
• Modèle tarifaire (par utilisateur, par bande passante, par fonctionnalité).
• Support des protocoles métier spécifiques (SAP, RDP, SSH, bases de données).
• Qualité du reporting et de l'intégration SIEM.

06 — DéploiementDémarche de mise en place

07 — LimitesCe que le ZTNA ne résout pas

La compromission d'identité reste le risque principal

Le ZTNA repose intégralement sur la confiance dans l'identité. Un attaquant qui vole un identifiant valide (via phishing, malware infostealer, pretexting) et contourne le MFA peut se connecter légitimement à la plateforme ZTNA. L'MFA résistant au phishing (FIDO2, passkey) est donc indispensable en complément.

Ne remplace pas la sécurité applicative

Le ZTNA contrôle l'accès, pas ce qui se passe dans l'application. Une vulnérabilité applicative (injection SQL, XSS, escalade de privilèges) reste exploitable par un utilisateur qui a un accès légitime. La sécurité applicative (WAF, tests d'intrusion, revues de code) reste nécessaire.

Dépendance forte au fournisseur

Le ZTNA cloud-delivered crée une dépendance critique au fournisseur — disponibilité, performance, sécurité, conformité. Un incident majeur chez Zscaler, Cloudflare ou Palo Alto a un impact potentiel sur toutes les entreprises clientes. Il faut prévoir des plans de continuité (accès VPN de secours, procédures dégradées).

Coût non négligeable

Les licences ZTNA cloud-delivered se facturent typiquement par utilisateur et par mois (de 4 à 15 € selon les offres et les fonctionnalités), auxquels s'ajoutent parfois des coûts de bande passante et de fonctionnalités avancées. Pour une ETI de 1 000 collaborateurs, le budget annuel peut dépasser 100 000 €. À comparer avec le TCO d'une solution VPN historique (licences + matériel + opérations).

Complexité des politiques

La granularité du ZTNA est une force mais aussi un défi : définir et maintenir des centaines de politiques d'accès différentes demande une gouvernance rigoureuse, sous peine de dérive progressive (accès trop permissifs, règles obsolètes, exceptions non revues).

Cas d'usage techniques spécifiques

Certains scénarios restent complexes : protocoles multicast, applications qui initient des connexions entrantes vers le client, certains protocoles industriels (OT/ICS), interconnexions site-à-site. Le ZTNA est conçu pour l'accès utilisateur aux applications — d'autres solutions (VPN IPsec, SD-WAN, solutions OT dédiées) restent pertinentes pour les autres cas.

Les appareils non gérés restent un angle mort

L'évaluation de la posture fonctionne bien sur les postes gérés avec agent. Sur les BYOD et les postes prestataires non gérés, le contrôle est plus limité : on peut vérifier l'identité mais pas réellement garantir l'état de sécurité de l'appareil. Les accès sans agent (via reverse proxy web) compensent partiellement mais sans couvrir tous les cas d'usage.

08 — FAQQuestions fréquentes

Combien de temps prend une migration VPN vers ZTNA ?

Très variable. Pour une PME de 100 collaborateurs avec 5 à 10 applications à protéger : 2 à 4 mois. Pour une ETI de 1 000 collaborateurs avec des dizaines d'applications hétérogènes : 9 à 18 mois. Pour un grand groupe international : 2 à 4 ans avec des vagues successives. Les principaux facteurs de durée sont la maturité de l'IAM, la diversité des applications et la gouvernance du changement.

Le ZTNA fonctionne-t-il pour les applications non-web ?

Oui. Les solutions modernes supportent RDP, SSH, les bases de données (SQL, Oracle, PostgreSQL), les protocoles métier (SAP GUI, AS/400), VoIP, et même certains protocoles plus exotiques via des connecteurs personnalisables. La complexité augmente pour les applications qui utilisent plusieurs ports ou des connexions bidirectionnelles, mais la plupart des cas sont couverts.

Le ZTNA est-il pertinent pour une PME ?

De plus en plus oui, notamment via des offres comme Cloudflare Zero Trust (gratuit jusqu'à 50 utilisateurs), Tailscale ou Twingate qui ont des tarifs accessibles. Pour une petite structure avec peu d'applications internes, le ZTNA peut même être plus simple qu'un VPN à déployer et à maintenir. Le bénéfice sécurité est proportionnellement important : les PME sont des cibles fréquentes et manquent généralement de ressources pour maintenir un VPN à jour.

Faut-il du ZTNA pour les applications SaaS ?

Le ZTNA classique couvre surtout les applications privées (internes, cloud privé, datacenter). Pour les SaaS (Microsoft 365, Salesforce, Workday), la protection passe plutôt par un CASB (Cloud Access Security Broker) et par l'intégration IAM (conditional access, MFA forte). Les plateformes SASE/SSE combinent ZTNA pour les apps privées et CASB pour les SaaS dans une même console.

Comment ZTNA s'articule avec NIS2 et DORA ?

Le ZTNA répond à plusieurs exigences explicites de NIS2 et DORA : contrôle des accès, authentification forte, segmentation, journalisation, résilience. Il facilite aussi la conformité en fournissant un point de contrôle centralisé et auditable des accès distants. Sans être explicitement nommé dans ces textes, le ZTNA est devenu une brique de référence dans les démarches de mise en conformité des entités soumises.