Zero Trust Network Access (ZTNA) : Pourquoi le VPN traditionnel est-il mort ?

• Le VPN traditionnel étend le réseau interne jusqu’au domicile, ce qui agrandit mécaniquement la surface d’attaque.
• Le ZTNA (Zero Trust Network Access) ne donne pas un Accès réseau global, mais un accès ciblé aux applications.
• Avec le modèle Zero Trust, chaque requête est vérifiée via Authentification forte et signaux de contexte.
• Le ZTNA améliore la Sécurité Réseau en limitant le mouvement latéral après compromission.
• Les performances progressent, car l’accès aux services cloud évite le détour par le siège.
• La migration se fait souvent en parallèle, puis par lots, avant une mise au rebut du concentrateur VPN.

Le télétravail a transformé l’accès distant en artère vitale de l’entreprise, mais il a aussi exposé une réalité longtemps tolérée : le VPN traditionnel a été conçu pour un monde centré sur le bureau et le datacenter. Or, les usages se sont déplacés vers le SaaS, les environnements multi-cloud et des équipes distribuées, tandis que les attaquants industrialisent la Cyberattaque par hameçonnage, vol de sessions et exploitation de failles sur les passerelles exposées. Dans ce décor, le « tunnel vers le réseau » ressemble à une clé universelle confiée à des postes hétérogènes, parfois peu maîtrisés, et connectés depuis des réseaux domestiques imprévisibles.

Face à ce décalage, le ZTNA s’impose comme une refonte du contrat de confiance. L’accès n’est plus une autorisation générale accordée une fois, mais une série de décisions, prises à la demande, selon l’identité, l’état du terminal et le contexte. Cette approche Zero Trust change la géographie du risque : au lieu d’ouvrir un couloir vers l’interne, elle met en place des portes devant chaque application. Ensuite, la question n’est plus « qui est sur le réseau ? », mais « qui accède à quoi, depuis quel appareil, et dans quelles conditions ? »

ZTNA vs VPN traditionnel : l’écart qui tue le modèle “tunnel vers le réseau”

Le débat n’oppose pas deux outils équivalents, car ils n’accordent pas le même type d’autorisation. D’un côté, le VPN traditionnel crée un tunnel chiffré, puis place l’utilisateur « comme au bureau ». De l’autre, le ZTNA autorise un chemin précis vers une application, sans exposer le réseau comme un espace navigable. Ainsi, la différence n’est pas cosmétique : elle redéfinit le Contrôle d’accès et la Protection des données.

Dans une PME fictive, “Atelier Mistral”, 80 salariés utilisent Microsoft 365, un ERP interne et un outil RH. Avec un VPN, une fois authentifié, un poste compromis peut tenter d’atteindre l’ERP, scanner des partages ou viser un contrôleur de domaine. Avec un ZTNA, le même poste peut, au mieux, toucher l’application explicitement autorisée. Le périmètre se déplace : il colle à l’application, pas au plan d’adressage.

Tableau comparatif : accès, visibilité et surface d’attaque

Pour clarifier, la comparaison utile porte sur la portée d’accès, l’observabilité et le risque de mouvement latéral. Ensuite, la performance compte, car la sécurité contournée devient une sécurité théorique. Enfin, le modèle économique influe sur la capacité à passer à l’échelle, surtout quand les équipes alternent bureau et distant.

Critère	VPN traditionnel	ZTNA
Portée d’accès	Accès au réseau interne (souvent large)	Accès spécifique à l’application
Modèle de confiance	Confiance implicite après connexion	Accès conditionnel et vérification à chaque demande
Mouvement latéral	Possible si un poste est compromis	Conçu pour l’empêcher, car le réseau n’est pas “visible”
Journalisation	Souvent centrée IP/session	Logs riches : utilisateur, appareil, application, action
Expérience utilisateur	Client, reconnexions, risques de tunnel mal réglé	Souvent transparent via navigateur/agent léger
Cloud	Trafic “hair-pinning” via le siège fréquent	Accès direct aux services cloud quand c’est pertinent
Exposition aux DDoS	Passerelle VPN publique, cible claire	Moins d’infrastructure directement exposée
Coûts	Appliance + licences + maintenance	SaaS par utilisateur, souvent 5–15 $/mois selon options

Ce tableau ne “condamne” pas tout VPN par principe. Cependant, il montre pourquoi la logique d’Accès réseau étendu devient fragile dès que les applications se dispersent entre cloud et sites. À ce stade, la section suivante doit poser une question simple : que se passe-t-il quand l’attaquant entre, malgré tout ?

Pourquoi le VPN traditionnel devient un accélérateur de compromission

Le VPN n’est pas seulement un outil. C’est une philosophie héritée du “château et fossé”, où l’intérieur est réputé plus sûr que l’extérieur. Or, ce postulat a vieilli, car les identifiants fuitent, les postes se contaminent, et les attaquants ciblent le maillon humain. Dès lors, une connexion VPN réussie peut devenir un moment de bascule : l’accès large transforme une fraude d’identifiants en intrusion interne.

Dans les retours d’expérience d’incidents, un scénario revient : un utilisateur valide une fausse page de connexion, puis l’attaquant réutilise les identifiants et s’installe. Ensuite, il explore. Il essaie un partage, puis un serveur, puis un autre. C’est le mouvement latéral, et il devient réaliste parce que le poste est “sur le réseau”. Avec un ZTNA bien configuré, la même tentative se heurte à des autorisations applicatives et à des politiques plus strictes.

Accès excessif : la racine du problème

Le cœur du risque tient dans l’écart entre le besoin et l’autorisation. Un comptable a besoin de l’ERP, pas des segments d’administration réseau. Pourtant, avec un VPN, le chemin vers l’ERP passe souvent par une visibilité réseau plus large. Ainsi, même sans privilèges élevés, un assaillant peut cartographier et tenter des rebonds. Pourquoi laisser cette possibilité, alors que le principe du moindre privilège est acquis depuis des années ?

Dans “Atelier Mistral”, un prestataire externe doit accéder à une application de ticketing interne. Avec un VPN, il reçoit parfois un accès plus large “pour éviter de bloquer”. Ensuite, une seule erreur de périmètre suffit. En revanche, un ZTNA peut limiter l’accès à l’URL ou au service visé, avec des contraintes horaires et un appareil conforme.

Vulnérabilités des passerelles VPN : une cible exposée

Les appliances VPN et leurs concentrateurs ont régulièrement fait l’actualité, car ils sont placés à la frontière et parlent à Internet. Leur complexité, combinée à des délais de patch, a ouvert des fenêtres de tir. Les campagnes d’exploitation de produits très répandus ont montré un point opérationnel : lorsqu’un correctif nécessite une maintenance, beaucoup d’organisations temporisent. Or, pendant ce temps, l’attaquant automatise la recherche de versions vulnérables.

Cette réalité se combine avec la pression métier. Le VPN est “indispensable”, donc il devient difficile à arrêter pour corriger vite. Au contraire, un déploiement ZTNA réduit la dépendance à un point d’entrée unique. Le risque ne disparaît pas, mais la surface exposée change, et la résilience s’améliore.

Performances et contournements : quand l’outil pousse à l’ombre

Le “hair-pinning” est un mot technique, mais ses effets sont concrets : une visioconférence ou un accès à un SaaS peut faire un détour inutile par le siège. Résultat, la latence augmente, et les utilisateurs cherchent des échappatoires. Ensuite, l’informatique fantôme s’installe : partage de fichiers via outils personnels, accès direct non maîtrisé, ou synchronisations hors contrôle. La Sécurité Réseau perd, non par faiblesse cryptographique, mais par friction.

Un insight s’impose : une sécurité qui dégrade trop l’expérience finit souvent par être neutralisée par le terrain. La suite doit donc expliquer comment le ZTNA réduit cette friction tout en renforçant le contrôle.

Cette comparaison en vidéo aide à visualiser la rupture : le VPN “branche” un poste au réseau, tandis que le ZTNA “branche” un utilisateur à une application, sous conditions.

Comment fonctionne le ZTNA : identité, contexte et contrôle d’accès en continu

Le ZTNA n’est pas un simple remplacement de tunnel. C’est un système de décision, qui s’appuie sur un fournisseur d’identité et sur des politiques d’Accès conditionnel. L’accès est accordé à l’application, pas à un segment. Ensuite, la confiance n’est jamais acquise une fois pour toutes : elle est réévaluée. Cette mécanique donne de la matière aux équipes sécurité, car elle produit des signaux exploitables et des logs orientés action.

Authentification forte et signaux de risque : le point d’entrée réel

Une politique moderne commence par l’Authentification forte, souvent via un IdP comme Microsoft Entra ID, Okta ou Google Workspace. Cependant, le MFA n’est qu’un socle. Ensuite, les décisions prennent en compte la conformité du terminal, la posture de sécurité, l’emplacement, ou encore le niveau de risque du compte. Ainsi, un accès depuis un poste géré et chiffré peut être fluide, tandis qu’un accès depuis un appareil inconnu déclenche des étapes supplémentaires.

Dans “Atelier Mistral”, un salarié tente de se connecter à l’ERP depuis un ordinateur personnel non conforme. Le ZTNA peut refuser, ou basculer vers un accès web en lecture seule. À l’inverse, depuis un poste géré, l’accès est accordé sans friction excessive. Le Contrôle d’accès devient adaptatif, ce qui réduit la tentation de contourner.

Accès au niveau applicatif : cloisonner pour protéger les données

La promesse centrale est l’isolation : l’utilisateur ne “voit” pas le réseau. Il voit une application autorisée. En pratique, cela limite la découverte d’hôtes internes, et donc les tentatives de rebond. De plus, la Protection des données peut être renforcée par des règles : interdiction de téléchargement, restrictions selon la sensibilité, ou inspection des flux selon les offres.

Un exemple simple illustre l’effet. Le service RH utilise une application interne, tandis que la finance exploite une base sensible. Avec un VPN, les deux environnements peuvent se retrouver joignables depuis le même poste distant. Avec un ZTNA, l’accès RH ne donne aucune route implicite vers la finance. Même en cas de vol de session, l’impact est mécaniquement contenu.

Évaluation continue : couper l’accès quand la confiance chute

Le VPN valide souvent au moment de la connexion. Ensuite, la session vit. Le ZTNA, lui, réévalue. Si un terminal perd sa conformité, si un comportement devient anormal, ou si un signal de compromission apparaît, l’accès peut être réduit ou interrompu. Cette logique colle mieux aux attaques actuelles, car elles évoluent au fil des heures. Alors, pourquoi laisser une autorisation inchangée pendant une journée entière ?

À ce stade, la technologie n’a de valeur que si elle s’intègre bien. La section suivante se concentre donc sur le marché, les options concrètes et une trajectoire de migration réaliste.

Une démonstration centrée sur Entra illustre bien l’articulation entre identité, posture du terminal et politiques d’accès, qui constitue l’ossature opérationnelle du ZTNA.

Solutions ZTNA et critères de choix : du SaaS simple à l’architecture SASE

Le marché du ZTNA s’est structuré autour de plateformes cloud, souvent liées à une vision plus large comme le SASE. Pourtant, le bon choix dépend moins du marketing que de l’existant : IdP déjà déployé, parc géré ou non, part de SaaS, applications internes, et exigences de conformité. Autrement dit, la technologie doit s’adapter à la réalité, sinon elle sera rejetée.

Panorama des solutions ZTNA utilisées en entreprise

Plusieurs acteurs dominent les déploiements. Zscaler Private Access vise les environnements globaux et les politiques avancées. Cloudflare Access séduit par son intégration et sa simplicité, surtout si l’organisation utilise déjà des services edge. Microsoft Entra Private Access s’insère naturellement dans l’écosystème Microsoft, ce qui réduit les frottements pour les organisations déjà centrées sur Microsoft 365. Prisma Access et Netskope se positionnent souvent dans des architectures plus complètes, où la sécurité des flux et des données est un sujet majeur.

Pour “Atelier Mistral”, le point clé est l’IdP : l’entreprise a déjà standardisé l’identité sur Entra. Dans ce cas, une solution qui exploite les mêmes politiques d’Accès conditionnel évite la double administration. À l’inverse, une PME très technique peut préférer une approche plus “developer-friendly”, notamment si des applications sont fortement distribuées.

Critères pratiques : ce qui compte au-delà des fiches produit

Le choix se joue souvent sur des détails concrets. D’abord, la capacité à publier des applications internes sans les exposer sur Internet. Ensuite, la richesse de la journalisation et l’intégration SIEM. Par ailleurs, la gestion des appareils compte : MDM, conformité, certificats, posture EDR. Enfin, la couverture des cas d’usage legacy reste un point de vigilance, surtout pour RDP et SSH.

Voici une liste de questions opérationnelles qui évitent les mauvaises surprises :

• Quels types d’applications doivent être protégés : web, client-serveur, RDP, SSH, bases de données ?
• Le fournisseur s’intègre-t-il nativement à l’IdP et à l’Authentification forte déjà en place ?
• Les politiques permettent-elles un Contrôle d’accès fin : par groupe, appareil, localisation, horaire, risque ?
• La solution améliore-t-elle la performance SaaS en évitant le détour par le siège ?
• Les logs sont-ils actionnables pour l’équipe sécurité, notamment en cas de Cyberattaque ?
• La tarification est-elle lisible, et inclut-elle inspection, DLP, ou options nécessaires à la Protection des données ?

Cette grille transforme un débat abstrait en décision d’architecture. Toutefois, la meilleure solution reste celle qui peut être déployée vite, sans casser l’existant. D’où l’intérêt d’une migration par étapes, détaillée dans la section suivante.

Migration VPN vers ZTNA : stratégie par phases, cas concrets et pièges à éviter

Remplacer un VPN ne consiste pas à “couper et basculer” un vendredi soir. Le chemin le plus sûr reste progressif, car il faut cartographier les usages et maintenir la continuité métier. Dans la pratique, trois phases reviennent : déploiement parallèle, migration graduelle, puis retrait du VPN. Chaque phase peut être cadrée par des objectifs mesurables, ce qui rend la transformation pilotable.

Phase 1 : déploiement parallèle pour sécuriser vite sans rupture

La première étape consiste à garder le VPN en place, tout en ouvrant le ZTNA sur des applications web simples. Cela inclut souvent des portails internes, des outils RH, ou des consoles d’administration qui s’y prêtent. Ainsi, les utilisateurs voient un bénéfice immédiat : moins de connexions manuelles, moins de perte de session, et un accès plus direct aux services.

Chez “Atelier Mistral”, l’équipe IT commence par le portail RH et un wiki interne. Ensuite, elle impose une règle : accès uniquement depuis appareils gérés, avec Authentification forte. Résultat, le périmètre exposé du VPN se réduit déjà, car une partie des usages disparaît du tunnel. Cette étape crée aussi de la confiance côté métiers, car les irritants diminuent.

Phase 2 : migration progressive, application par application

La seconde phase vise les applications plus critiques, comme l’ERP, puis les outils d’exploitation. Il faut alors définir des connecteurs, des politiques, et des groupes d’accès. De plus, la segmentation logique doit être revue : le ZTNA force à expliciter qui a besoin de quoi. Cette clarification peut sembler lourde, mais elle évite les droits historiques accumulés.

Les cas legacy demandent plus d’attention. RDP et SSH restent possibles, mais ils requièrent souvent des composants dédiés et des règles strictes. Pour un serveur de production, l’accès peut être limité à un bastion, avec enregistrement de session. Ainsi, la Sécurité Réseau gagne en traçabilité, tandis que les opérations restent faisables.

Phase 3 : retraite du VPN et maintien d’un plan de secours

Une fois que la majorité des applications est accessible via ZTNA, le concentrateur VPN devient moins indispensable. C’est le moment de planifier sa mise hors service, car le risque d’exposition diminue. Néanmoins, un accès d’urgence peut être conservé, par exemple pour des scénarios de reprise après sinistre. Dans ce cas, il doit être verrouillé : comptes dédiés, MFA strict, fenêtres d’accès, et surveillance renforcée.

Les bénéfices se lisent aussi en finance. Les coûts matériels et la maintenance baissent, tandis que la capacité s’ajuste plus facilement. Surtout, la réduction de surface d’attaque devient tangible : moins de points d’entrée exposés et moins d’Accès réseau implicite. L’insight final est clair : la migration réussit quand elle traite autant l’organisation que la technique.

On en dit quoi ?

Le constat est net : le VPN traditionnel n’est pas “mort” parce qu’il chiffre mal, mais parce qu’il distribue trop d’Accès réseau dans un monde qui ne fonctionne plus en périmètre fixe. À l’inverse, le ZTNA colle aux usages actuels, car il mise sur le Contrôle d’accès applicatif, l’Accès conditionnel et une Authentification forte qui s’adapte au contexte.

Dans une période où chaque fuite d’identifiants peut devenir une Cyberattaque majeure, la réduction du mouvement latéral et l’amélioration de la visibilité ne relèvent plus du confort. Elles deviennent un choix d’architecture, donc un choix de survie opérationnelle.

Le ZTNA peut-il remplacer complètement un VPN traditionnel ?

Dans la plupart des organisations, oui, car le ZTNA couvre bien les applications SaaS, web internes et beaucoup d’applications modernes. En revanche, certains usages legacy nécessitant un accès “réseau brut” peuvent justifier un maintien temporaire du VPN, le temps de moderniser ou de mettre en place des accès ZTNA adaptés (RDP/SSH via composants dédiés).

Le ZTNA est-il forcément plus cher que le VPN ?

Pas forcément. Le ZTNA est souvent facturé par utilisateur et par mois, ce qui paraît plus visible. Toutefois, le coût total d’un VPN inclut appliance, licences, maintenance, exploitation, et surtout le coût du risque lié à un accès réseau étendu. Une comparaison réaliste doit intégrer ces éléments, ainsi que les gains de productivité liés à une meilleure performance cloud.

Quel rôle jouent l’accès conditionnel et l’authentification forte dans un projet ZTNA ?

Ils constituent le socle. L’authentification forte valide mieux l’identité, tandis que l’accès conditionnel ajuste la décision selon des signaux (conformité du terminal, localisation, risque de session, comportement). Ensemble, ils permettent un contrôle d’accès fin, évolutif et plus robuste face au vol d’identifiants.

Combien de temps faut-il pour migrer vers ZTNA sans interrompre les utilisateurs ?

Un premier périmètre (applications web) peut souvent être opérationnel en quelques semaines, si l’identité et les groupes sont déjà structurés. Ensuite, le remplacement complet du VPN se fait généralement par étapes sur plusieurs mois, car il faut traiter les applications plus anciennes, ajuster les politiques, et accompagner les équipes. L’approche parallèle limite fortement les interruptions.