Chaque modèle repose sur une hypothèse
Comparer VPN, ZTNA et SASE sur une liste de fonctionnalités est peu utile. Ce qui compte, c'est l'hypothèse implicite que chaque modèle fait sur la nature de votre infrastructure et la localisation de vos ressources. Choisir un modèle inadapté à votre hypothèse réelle produit soit une sécurité insuffisante, soit une complexité inutile.
ZTNA est un modèle d'architecture de contrôle d'accès. SASE est un modèle de delivery — une façon de consommer des services de sécurité réseau via le cloud. ZTNA peut être implémenté sans SASE (on-premise ou dans votre propre cloud). Un déploiement SASE inclut généralement ZTNA parmi d'autres composants, mais le ZTNA seul ne fait pas un SASE.
Le problème du mouvement latéral — ce que le VPN laisse ouvert
Dans un modèle VPN traditionnel, l'authentification initiale ouvre un accès réseau large. Selon la configuration du split tunneling et de la segmentation interne, un utilisateur VPN connecté peut atteindre potentiellement l'ensemble des ressources du réseau interne depuis son terminal distant.
C'est le vecteur que les attaquants exploitent systématiquement après compromission de credentials VPN : la latéralisation. L'attaquant se connecte au VPN avec les credentials volés, puis se déplace vers des systèmes à haute valeur (Active Directory, serveurs de backup, bases de données de production) sans nouvelle authentification. Le rapport Verizon DBIR classe ce vecteur parmi les techniques les plus utilisées dans les intrusions documentées.
Comment ZTNA adresse ce problème
ZTNA remplace l'accès réseau par l'accès applicatif granulaire. L'utilisateur n'accède pas au réseau — il accède à des applications spécifiques, après vérification à chaque requête. Cette architecture, formalisée dans le NIST SP 800-207, repose sur deux composants : le Policy Decision Point (PDP) qui évalue les politiques d'accès en continu, et le Policy Enforcement Point (PEP) qui applique les décisions sur le flux réseau.
La granularité de l'accès élimine structurellement la latéralisation : même si les credentials d'un utilisateur sont compromis, l'attaquant n'accède qu'aux applications auxquelles cet utilisateur avait accès, et seulement sous les conditions (posture terminal, contexte, heure) qui étaient valides au moment de la demande.
Les prérequis non négociables de ZTNA
Déployer ZTNA sans avoir ces fondations en place produit une architecture incohérente ou non fonctionnelle :
Un Identity Provider (IdP) centralisé avec MFA — Okta, Entra ID (ex-Azure AD), Ping Identity, ou équivalent. ZTNA évalue l'identité à chaque requête ; sans IdP fiable, il n'y a rien à évaluer. Un système de gestion des terminaux (MDM/UEM) — Microsoft Intune, Jamf, VMware Workspace ONE. ZTNA vérifie la posture du terminal (chiffrement du disque, OS à jour, antivirus actif) — sans agent MDM, cette vérification est impossible ou triviale à contourner. Un inventaire applicatif précis — liste des applications internes, leurs API, leurs dépendances réseau. ZTNA remplace l'accès réseau par des politiques d'accès par application ; sans cet inventaire, vous ne pouvez pas écrire les politiques.
Les organisations qui n'ont pas ces prérequis ne peuvent pas migrer vers ZTNA sans investissement préalable significatif — souvent plus coûteux que le déploiement ZTNA lui-même. Une PME de 30 personnes sans MDM et sans IdP centralisé devrait commencer par ces fondations, pas par ZTNA.
Grille de décision par contexte organisationnel
| Contexte | Approche recommandée | Justification |
|---|---|---|
| PME < 50 personnes, SI centralisé, postes gérés | VPN IPsec/IKEv2 | Meilleur rapport complexité/sécurité. Les prérequis ZTNA (IdP, MDM) représentent un surcoût disproportionné. |
| ETI 100–500 personnes, télétravail partiel, ressources hybrides | VPN + ZTNA en overlay | VPN pour les accès legacy et les ressources on-premise. ZTNA pour les applications critiques (ERP, RH, finance). Migration progressive possible. |
| Organisation entièrement cloud, pas de datacenter central | SASE ou ZTNA natif | Le modèle périmétrique VPN est inadapté — il n'y a pas de périmètre à protéger. SASE offre la cohérence d'une politique unifiée. |
| Secteur réglementé (santé, finance, défense), NIS2 | VPN + microsegmentation + ZTNA | Exigences de cloisonnement réseau documentées. Audit de la chaîne d'accès requise. La combinaison offre la traçabilité nécessaire. |
| BYOD dominant, terminaux non maîtrisés | ZTNA avec vérification de posture | VPN sur terminal non géré n'offre aucune garantie exploitable. ZTNA clientless ou avec agent léger permet de conditionner l'accès à la posture. |
| Multi-sites géographiques, latence inter-sites critique | VPN site-à-site + SD-WAN | Les tunnels IPsec site-à-site réduisent la latence inter-bureaux. SD-WAN optimise le routage multi-liens. SASE peut s'y superposer pour les accès utilisateurs. |
SASE : ce que le marché ne documente pas
SASE (Secure Access Service Edge) est un cadre conceptuel défini par Gartner en 2019. Ce n'est pas un standard technique — il n'y a pas de spécification normative SASE équivalente au NIST SP 800-207 pour ZTNA. Les éditeurs qui se réclament de SASE proposent des niveaux d'intégration extrêmement variables.
Un "SASE complet" peut reposer sur cinq produits acquis en trois ans par un éditeur, avec une console de management unifiée mais des data planes séparés. L'inspection du trafic (SWG), le contrôle d'accès (ZTNA) et le SD-WAN peuvent être des services distincts, chaînés via des redirections de trafic successives. Chaque chaînage ajoute de la latence et une surface d'attaque.
L'inspection du trafic (SWG), le ZTNA et le SD-WAN partagent-ils le même data plane, ou sont-ils chaînés via des proxies distincts ? L'éditeur opère-t-il ses propres points de présence (PoP) ou utilise-t-il des partenaires ? Quelle est la latence P95 pour les utilisateurs dans votre géographie ? Peut-on auditer les journaux d'accès depuis votre propre SIEM, ou les logs sont-ils silo dans la console de l'éditeur ?
Microsegmentation : le complément que le VPN seul ne fournit pas
Qu'on utilise un VPN traditionnel ou ZTNA, la segmentation du réseau interne est un composant de sécurité orthogonal et complémentaire. La microsegmentation divise le réseau interne en zones étanches — un terminal compromis ne peut pas atteindre les systèmes des autres zones sans traverser un pare-feu avec des règles explicites.
Dans une architecture VPN sans microsegmentation, l'accès au réseau interne est souvent équivalent à un accès à l'ensemble du réseau interne. La microsegmentation limite la portée d'une compromission — même si un attaquant obtient un accès VPN valide, il ne peut pas atteindre des systèmes hors de sa zone autorisée.
Les technologies courantes : VLAN classiques (segmentation L2), pare-feu internes avec règles inter-zones (segmentation L3/L4), ou microsegmentation SDN (Software-Defined Networking) avec contrôle dynamique des flux au niveau de chaque workload. La page sur le déploiement couvre les décisions d'infrastructure qui conditionnent l'efficacité de cette segmentation.