Zero Trust Network Access (ZTNA) : comment le déployer sans tout reconstruire ?

14 octobre 2026 / Thomas

Par : Thomas

Membre des équipes de Blue, Thomas partage son expérience opérationnelle dans le domaine de la cybersécurité. En tant qu’Analyste SOC, il contribue à des publications dédiées à la détection des menaces, à l’analyse des incidents, à la veille de sécurité et aux bonnes pratiques de protection des environnements sensibles.

« On a un firewall et un VPN, tout fonctionne. » C'est la phrase qu'un RSSI entend le plus quand il parle de ZTNA, et elle est souvent exacte : le VPN fait bien son travail. La vraie question porte sur ce qu'il autorise une fois le tunnel monté. Avec le cloud, le télétravail et les prestataires externes, le réseau de l'entreprise n'a plus de frontière nette, et les solutions VPN, qui donnent un large accès au réseau dès que l'utilisateur est connecté, s'en accommodent mal. Le ZTNA offre une alternative : un accès Zero Trust aux applications, basé sur l'identité et sur l'état du poste.

SOMMAIRE :

Le ZTNA : du modèle Zero Trust à l'accès par application
Comment déployer le ZTNA sans reconstruire son réseau
Différence entre ZTNA et VPN : tableau comparatif
Blue : déployer le ZTNA avec FortiClient, EMS souverain et FortiGate
FAQ : Tout savoir sur le ZTNA

Le ZTNA : du modèle Zero Trust à l'accès par application

Qu'est-ce que le ZTNA ?

Le ZTNA, ou Zero Trust Network Access (accès réseau Zero Trust), est une technologie de sécurité qui fournit aux utilisateurs autorisés un accès sécurisé aux applications dont ils ont besoin, après vérification de leur identité, de l'état de leur appareil et du contexte de connexion. Là où un VPN traditionnel ouvre une route vers le réseau, le ZTNA ouvre l'application et rien d'autre, selon le principe du moindre privilège, au bureau comme à distance.

Le modèle de sécurité Zero Trust n'est pas un produit : il retire la confiance accordée d'office à celui qui se trouve dans le réseau d'entreprise, chaque demande d'accès étant évaluée par session et par ressource. Décrits par le NIST (SP 800-207) puis par l'ANSSI (ANSSI-PA-111, juin 2025), les principes Zero Trust tiennent en trois idées : vérifier explicitement, accorder le moindre privilège, supposer qu'une compromission peut arriver. La technologie ZTNA applique le principe du Zero Trust à l'accès aux applications, et le modèle ZTNA est basé sur l'identité plutôt que sur l'adresse IP. Qu'est-ce que ZTNA, en une phrase ? Un accès par application plutôt qu'un accès par réseau.

Pourquoi le VPN traditionnel ne suffit plus ?

Un VPN (réseau privé virtuel) classique fait confiance dès que le tunnel est monté. L'utilisateur obtient un accès au niveau du réseau : une route, un sous-réseau, parfois l'ensemble du réseau interne. Les VPN ont été conçus pour l'accès à distance, c'est-à-dire brancher un poste sur le réseau de l'entreprise, et ils le font très bien. Le problème tient à ce qu'ils autorisent ensuite.

Prenons un prestataire de maintenance doté d'un compte VPN pour une application de GMAO : il atteint aussi, techniquement, le partage de fichiers et la supervision, simple conséquence d'une route ouverte. Avec du ZTNA, on publie la GMAO et rien d'autre, on exige un poste à jour, et l'accès se coupe si la posture se dégrade.

Pourquoi le ZTNA s'impose-t-il maintenant ? Parce que les menaces visent les identifiants et les postes, et que le concentrateur VPN, exposé sur Internet, est devenu une cible. Un compte volé permet d'explorer les adresses IP voisines et de rebondir de machine en machine : ce sont les mouvements latéraux.

Comment fonctionne le ZTNA ?

Comment le ZTNA décide-t-il d'ouvrir une application ? Le principe du ZTNA tient en cinq étapes.

L'utilisateur passe l'authentification, avec un second facteur adossé à l'annuaire de l'entreprise (SAML, LDAP, Active Directory).
L'état de l'appareil est évalué : système à jour, EDR ou antivirus actif, version de l'agent, poste géré ou non.
Une politique rapproche les utilisateurs et les appareils des règles définies, application par application.
Si tout est conforme, la session est ouverte vers l'application autorisée, et vers elle seule.
La posture reste surveillée : si le poste sort de conformité en cours de session, l'accès est retiré.

Le ZTNA place un point de contrôle entre l'utilisateur et les applications et permet de connecter en toute sécurité chaque session à une seule destination. Les applications privées ne sont plus visibles de l'ensemble du réseau : ni les adresses IP internes, ni les autres ressources.

Les avantages du ZTNA, et ce qu'il ne fait pas

Les avantages du ZTNA se mesurent à ce qui n'arrive plus. La surface d'attaque se limite aux applications publiées, un compte compromis ne donne plus la clé de tout le réseau, la même politique s'applique au bureau et chez l'utilisateur, et chaque accès est journalisé par utilisateur, appareil et application, ce qui aide pour NIS2 ou un audit d'assurance cyber. Le ZTNA peut même faire d'un EDR déjà déployé une condition d'accès. On résume souvent la différence ainsi : le VPN remet un badge d'immeuble, le ZTNA une clé de bureau, après avoir vérifié que la personne est à jour.

Il a aussi ses limites. Le ZTNA ne remplace ni l'annuaire ni le MFA, ne segmente pas les flux entre serveurs, ne corrige pas les vulnérabilités et ne détecte pas une compromission en cours, ce que fait un SOC. Sur un poste non maîtrisé (BYOD), l'assurance reste faible : l'ANSSI recommande de limiter ces accès aux ressources non critiques. Une démarche de sécurité Zero Trust s'ajoute à la sécurité réseau existante, elle ne la remplace pas.

Comment déployer le ZTNA sans reconstruire son réseau

S'appuyer sur l'infrastructure existante plutôt que la remplacer

Une solution ZTNA ne se pose pas sur une page blanche. Dans la plupart des projets, elle s'ajoute au firewall nouvelle génération, au SD-WAN et à l'annuaire déjà en place : on ne reconstruit pas le réseau, on change la logique de contrôle d'accès, service après service. Un client de 150 postes, avec des nomades et un FortiGate déjà en place, peut démarrer ainsi : ce n'est pas réservé aux grands comptes.

Prioriser les cas d'usage à plus fort risque

Une bascule complète du VPN vers le ZTNA est rarement réaliste. Les organisations qui avancent bien démarrent par un cas d'usage à petit périmètre :

les prestataires et intérimaires, dont l'accès se limite à une application, sans impact sur les postes existants ;
les postes nomades, avec connexion VPN automatique hors des bureaux et contrôle de l'état du poste ;
les applications sensibles (RH, finance, production), réservées aux postes conformes.

Le filtrage web de l'agent, qui permet notamment de bloquer les IA génératives publiques non validées, vient ensuite en complément : il ne relève pas du ZTNA proprement dit.

Le bon moment : la fin du tunnel SSL VPN sur FortiOS 7.6.3

Si votre accès distant repose sur des FortiGate, le calendrier se pose presque de lui-même. D'après les notes de version de Fortinet, FortiOS 7.6.3 supprime le mode tunnel du SSL VPN sur tous les modèles : il faut basculer vers l'IPsec VPN (utilisable sur le port TCP 443), et les configurations existantes ne sont pas converties automatiquement. Autant toucher une seule fois à l'accès distant, en ajoutant le contrôle de posture.

ZTNA, SSE, SASE, CASB : démêler les sigles

Le SD-WAN est la partie réseau : il raccorde les sites et choisit le meilleur lien. Le SSE (Security Service Edge) regroupe la sécurité délivrée en service : filtrage web (SWG), contrôle des applications SaaS (CASB), accès applicatif (ZTNA) et pare-feu en service (FWaaS). Le SASE (Secure Access Service Edge, terme introduit par Gartner en 2019) additionne les deux, avec une politique unique. Le ZTNA est un composant essentiel du SASE, mais il peut aussi se déployer seul sur un réseau existant.

Choisir sa solution ZTNA : les questions à poser aux fournisseurs de ZTNA

Les solutions ZTNA se répartissent en deux familles. Le ZTNA basé sur le cloud passe par des points de présence et un plan de contrôle hébergés chez l'éditeur. L'autre garde le point d'application dans votre infrastructure, le plus souvent sur le firewall. Comparez les fonctions plutôt que les sigles : intégration avec votre firewall et votre annuaire, applications couvertes (web, RDP, SSH), prise en compte de l'état du poste, exploitation des règles au quotidien. Posez aussi trois questions de souveraineté : où le trafic est-il inspecté, où sont stockés les journaux d'accès (des données personnelles), et qui exploite le plan de contrôle, sous quel droit ? Pour une organisation soumise à NIS2, qui héberge des données de santé ou travaille pour le secteur public, les réponses peuvent être éliminatoires.

ZTNA, SSE, SASE, CASB : démêler les sigles

Choisir sa solution ZTNA : les questions à poser aux fournisseurs de ZTNA

Vos accès distants reposent encore sur un VPN traditionnel ?

Faites évaluer votre parcours vers le Zero Trust avec un expert réseau et cybersécurité.

Discutez avec nos experts

Différence entre ZTNA et VPN : tableau comparatif

Sujet	VPN IPsec / SSL classique	ZTNA
Ce qu'on ouvre	Un accès réseau : une route, un sous-réseau	Un accès par application : ce nom, ce port
Confiance	Implicite dès que le tunnel est monté	Réévaluée à chaque session, en continu
Posture du poste	Optionnelle, souvent contrôlée à la connexion seulement	Condition d'accès permanente : système à jour, EDR actif, version de l'agent
Mouvements latéraux	Possibles : l'utilisateur est « dans » le réseau	Fortement contraints : pas de route, une application à la fois
Exposition	Adresses IP et services internes atteignables	Applications privées invisibles hors périmètre autorisé

Remplacer le VPN du jour au lendemain ?

Rarement. Le VPN et le ZTNA cohabitent le temps de la transition : le VPN reste sur les usages historiques, le ZTNA prend les nouveaux. Le facteur de réussite n'est pas l'éditeur mais la clarté des règles écrites en amont : qui accède à quoi, depuis où, avec quel appareil. Sans annuaire tenu à jour, sans MFA et sans gestion des vulnérabilités, un ZTNA ne produit pas de Zero Trust. D'où la recommandation de l'ANSSI d'avancer cas d'usage par cas d'usage, avec un pilote : une politique trop stricte dès le premier jour est le principal risque côté utilisateurs.

Blue : déployer le ZTNA avec FortiClient, EMS souverain et FortiGate

Trois composants, trois rôles

L'offre ZTNA de Blue repose sur la technologie Fortinet.

FortiClient : l'agent installé sur le poste (Windows, macOS et Linux, distributions à valider avec l'avant-vente). Il porte le VPN IPsec et le ZTNA, remonte l'état du poste et reçoit un certificat client émis par l'EMS.
FortiClient EMS : la console, qui distribue les configurations, calcule les étiquettes de posture et les synchronise vers le firewall. Chez Blue, elle est hébergée dans notre cloud souverain, dans nos datacenters de Châteaubourg et de Nantes.
FortiGate : le point d'application, au datacenter. Il authentifie l'utilisateur (SAML, LDAP, Active Directory, MFA), interroge l'EMS sur la posture, puis ouvre ou non l'accès.

Aucune licence ZTNA supplémentaire n'est nécessaire sur le FortiGate : tout FortiGate sous FortiOS 7.0 ou supérieur peut servir de passerelle ZTNA, seules les licences FortiClient comptent.

Ce que Blue opère, ce qui reste chez vous

Blue vend un service, pas une licence seule : installation de la machine virtuelle EMS, maintien en condition opérationnelle et de sécurité, supervision, support avec un interlocuteur unique en français, documentation des paramétrages préconisés. Vous configurez et exploitez les règles ZTNA de votre parc (accès distant, conditions d'accès des utilisateurs et des postes, filtrage web), avec l'aide de nos équipes au démarrage : vos règles d'accès sont votre politique de sécurité. Facturation au nombre de devices, service Blue inclus, par paliers, sans facturation à la bande passante.

Filtrage web et shadow IA : encadrer l'usage de l'IA

Dans l'offre Blue, la même politique s'applique au bureau et à distance, et le VPN se monte automatiquement dès que le poste sort du réseau de l'entreprise. Le filtrage web de l'agent est inclus et s'applique où que soit le poste, sans détour par le datacenter. C'est la réponse à l'angle mort du télétravail, et un levier contre le shadow IA : les IA génératives publiques non validées peuvent être bloquées, et les usages ramenés vers une offre cadrée comme Gorill·IA, dont les données restent dans le périmètre de Blue. Pour héberger vos propres modèles : IA souveraine et guide LLM en cadre HDS.

Compatible avec vos offres Blue, avec une limite à connaître

L'offre ZTNA est compatible avec les offres firewall et SD-WAN de Blue ainsi qu'avec Gorill·IA : un client dont nous opérons déjà le firewall dispose du point d'application, un client SD-WAN a déjà son architecture multi-sites. La console qui décide des accès est hébergée et exploitée par Blue en France, sous droit français, hors Cloud Act.

Une limite à connaître : l'accès distant dépend du FortiGate et du lien du datacenter. La réponse est architecturale (haute disponibilité, deux liens, deux sites) et se chiffre dès la proposition. Pour le réseau, voir le comparatif SD-WAN vs MPLS et notre réseau privé MPLS/VPN ; nos services de sécurité sont présentés sur la page cybersécurité.