Cybersécurité · Architecture réseau

Avant le VPN, après le ZTNA : ce qui change vraiment

Publié le 12 février 2026 Lecture : 8 minutes Dossier Zero Trust
Flux de données sécurisés reliant des utilisateurs à des ressources cloud

Le ZTNA est souvent présenté comme le successeur naturel du VPN. La comparaison est pratique, mais elle masque l’essentiel : on ne remplace pas simplement un tunnel chiffré par un autre produit. On change le modèle de confiance, la manière de publier les applications et le rôle quotidien des équipes IT.

Le VPN connecte un réseau, le ZTNA autorise une ressource

Dans son fonctionnement classique, un VPN donne à un poste distant une présence logique sur le réseau de l’entreprise. Après authentification, l’utilisateur reçoit une adresse ou rejoint un segment accessible depuis l’extérieur. Cette approche reste efficace pour certains usages techniques, mais elle élargit souvent le périmètre visible : fichiers, consoles d’administration, bases de données ou services internes peuvent devenir atteignables au-delà du strict nécessaire.

Le Zero Trust Network Access inverse cette logique. L’utilisateur ne « rentre » pas dans le réseau ; il obtient, sous conditions, l’accès à une application précise. La passerelle ZTNA évalue l’identité, le contexte de connexion, l’état du terminal et la politique associée. Elle crée ensuite une relation limitée entre cet utilisateur et cette ressource, sans exposer directement l’infrastructure sous-jacente.

Le changement de vocabulaire est révélateur : on ne parle plus d’accès au réseau, mais d’accès à une application, pour une identité donnée, dans un contexte donné.

De la confiance implicite à la vérification continue

Un VPN moderne peut intégrer l’authentification multifacteur, des certificats et des contrôles de posture. Pourtant, son modèle historique conserve une hypothèse : une fois le tunnel établi, la session bénéficie d’un niveau de confiance relativement stable. Or un compte compromis, un terminal infecté ou une session laissée ouverte peuvent transformer cette confiance initiale en point d’appui pour un attaquant.

Le ZTNA introduit une décision plus dynamique. L’autorisation peut dépendre de plusieurs signaux :

La vérification n’est donc pas forcément une reconnexion visible toutes les cinq minutes. Elle peut être silencieuse, pilotée par les politiques d’accès conditionnel, avec une révocation immédiate si le contexte devient anormal.

Une expérience utilisateur moins spectaculaire, mais plus cohérente

Pour l’utilisateur, la disparition du VPN ne signifie pas nécessairement une interface plus complexe. Dans le meilleur scénario, les applications apparaissent dans un portail ou dans l’espace habituel d’authentification unique. L’accès se fait via un navigateur, un agent léger ou un connecteur installé près de la ressource. Le collaborateur n’a plus à se demander quel profil VPN activer avant d’ouvrir un outil métier.

Cette simplicité dépend toutefois d’un travail d’architecture. Les applications anciennes, les protocoles non compatibles avec le web et les flux machine à machine ne se migrent pas tous de la même façon. Il faut parfois conserver un accès réseau traditionnel pour une imprimante industrielle, une console d’administration ou un environnement de production isolé. Le ZTNA n’est pas une obligation de tout transformer en HTTP ; c’est une façon de réduire l’exposition là où cela apporte un gain réel.

Le vrai chantier : l’inventaire et la granularité des politiques

Passer au ZTNA révèle souvent un problème antérieur : l’entreprise ne sait pas précisément qui utilise quelle application, avec quel niveau de privilège et selon quelles dépendances. Un VPN pouvait dissimuler cette dette technique derrière une règle de pare-feu relativement large. Une architecture Zero Trust oblige à décrire les accès avec davantage de précision.

La migration commence donc par une cartographie des ressources, des identités et des flux. Les équipes doivent distinguer les applications publiques, internes, administratives et critiques, puis définir des groupes d’accès compréhensibles. Une politique efficace ne se limite pas à « employés contre non-employés » : elle tient compte du rôle, du projet, du terminal et du niveau de risque.

Cette démarche rejoint d’ailleurs des enjeux plus larges de performance humaine : une sécurité trop intrusive multiplie les interruptions et encourage les contournements. Comme dans tout dispositif de progression, il faut mesurer l’effort demandé, la fatigue cognitive et la capacité des utilisateurs à adopter durablement de nouvelles habitudes. Pour en savoir plus sur les liens entre discipline, gestion du stress et pratiques régulières, les ressources consacrées au sport et au bien-être offrent un angle complémentaire intéressant.

Ce que les administrateurs gagnent — et ce qu’ils doivent accepter

Le bénéfice principal est la réduction de la surface d’attaque. Les applications ne sont plus nécessairement exposées sur Internet, les accès sont plus courts et les règles se rapprochent de l’identité réelle. Les journaux deviennent également plus exploitables : au lieu d’observer une adresse IP connectée au réseau, l’équipe peut corréler une identité, une application, un appareil et une décision de politique.

En contrepartie, l’administration se déplace vers plusieurs plans de contrôle : fournisseur d’identité, gestion des terminaux, moteur de politiques, connecteurs et outils de détection. Une panne d’identité peut désormais affecter de nombreux services. Il faut donc prévoir des procédures de secours, des comptes d’urgence contrôlés, une supervision indépendante et des tests réguliers de restauration.

Les pièges d’une migration trop rapide

Après le VPN : une architecture, pas un simple produit

Le ZTNA ne fait pas disparaître tous les VPN du jour au lendemain. Les connexions intersites, certains environnements industriels et les scénarios d’administration hors bande conserveront probablement des tunnels réseau. En revanche, le VPN cesse d’être la porte d’entrée universelle vers le système d’information.

La trajectoire crédible pour 2026 est hybride : identité fédérée, authentification résistante au phishing, terminaux évalués en continu, segmentation applicative et accès réseau réservé aux cas qui le justifient. Le résultat attendu n’est pas seulement une meilleure sécurité. C’est aussi une architecture plus lisible, plus observable et davantage alignée sur les usages cloud, le travail distribué et les équipes qui changent rapidement de périmètre.

Pour suivre les prochaines évolutions de la cybersécurité, du développement et des infrastructures, découvrez tous nos dossiers sur la page d’accueil de Galibyte.

Dernières publications

Automatisation du stockage : gagner de la place sans créer un goulot d’étranglement · Quel support de stockage pour smartphone ? MicroSD au quotidien, USB pour transférer, cloud pour sauvegarder · Fibre dédiée : le débit garanti ne suffit pas à assurer la continuité · VerifSites : une note sur 5 ne suffit pas pour acheter sans risque

Tous nos articles