Cybersécurité · Architecture réseau

Zero Trust ne supprime pas les VPN dans tous les cas

Publié le 12 février 2026 · 8 min de lecture

Flux de données sécurisés reliant des serveurs dans une architecture Zero Trust

Le discours autour du Zero Trust présente souvent les VPN comme une technologie dépassée. La réalité est plus nuancée : une architecture fondée sur la vérification continue réduit fortement le périmètre de confiance, mais elle ne rend pas les tunnels chiffrés inutiles. Tout dépend des ressources à protéger, des contraintes réseau et du profil des utilisateurs.

Le malentendu autour de la disparition des VPN

Un VPN traditionnel crée généralement un accès au réseau interne après authentification. Une fois le tunnel établi, l’utilisateur peut parfois atteindre de nombreuses ressources, même si son poste, son identité ou son niveau de risque évoluent. C’est cette confiance implicite, souvent associée à une adresse IP ou à une appartenance au réseau, que le Zero Trust cherche à supprimer.

Le modèle « ne jamais faire confiance, toujours vérifier » ne signifie toutefois pas qu’aucun tunnel ne doit exister. Il impose plutôt de ne pas considérer le tunnel comme une preuve suffisante de légitimité. L’identité, l’état du terminal, le contexte de connexion et la sensibilité de l’application doivent être évalués séparément.

Zero Trust et ZTNA : deux périmètres différents

Les solutions de Zero Trust Network Access (ZTNA) donnent accès à une application précise plutôt qu’à un sous-réseau complet. Un proxy ou un connecteur placé près de la ressource applique des règles d’accès, tandis qu’un moteur de politiques exploite les signaux fournis par l’IdP, l’EDR, le MDM et les services d’authentification multifacteur.

Cette approche convient particulièrement aux applications web, aux interfaces SaaS et aux environnements cloud. Elle limite la découverte du réseau et réduit le mouvement latéral d’un attaquant. Elle peut aussi améliorer l’expérience de télétravail en évitant de faire transiter tout le trafic par le datacenter.

Mais ZTNA n’est pas un remplacement universel. Une application ancienne utilisant SMB, des protocoles industriels, des flux UDP spécifiques ou des bases de données accessibles par un client lourd peut mal fonctionner derrière un accès applicatif moderne. Dans ce contexte, un VPN correctement segmenté demeure parfois le moyen le plus fiable de transporter le trafic.

Dans quels cas conserver un VPN ?

Les environnements hérités et les protocoles non web

Les systèmes industriels, les équipements réseau, les consoles d’administration et certains logiciels métiers n’ont pas été conçus pour dialoguer avec un proxy d’identité. Réécrire ces dépendances peut coûter cher et introduire de nouveaux risques. Un tunnel IP chiffré, limité à quelques routes et protégé par une authentification forte, constitue alors une transition pragmatique.

Les interconnexions entre sites et infrastructures

Un VPN site à site reste adapté pour relier deux datacenters, un cloud privé et un réseau local, ou plusieurs agences. Il fournit une connectivité stable entre des équipements qui ne disposent pas toujours d’un navigateur ou d’un agent Zero Trust. La bonne pratique consiste à compléter ce lien par une segmentation stricte, des ACL minimales et une supervision des flux.

Les situations où la connectivité est dégradée

Sur un site isolé, dans un véhicule ou lors d’une intervention technique, l’accès à un fournisseur ZTNA peut dépendre de plusieurs services externes. Un VPN maîtrisé localement peut offrir une voie de secours lorsque le DNS, l’IdP ou une passerelle cloud est indisponible. Cette résilience doit être conçue à l’avance : un compte d’urgence non surveillé ne constitue pas une stratégie de continuité.

À retenir : le VPN ne doit plus être le synonyme d’un accès large au réseau. Il peut devenir un composant de transport contrôlé, soumis aux mêmes exigences d’identité, de segmentation et de journalisation que les autres mécanismes d’accès.

Une transition qui concerne aussi les petites équipes

Les choix d’architecture ne dépendent pas seulement de la taille d’un groupe. Une entreprise distribuée, des consultants itinérants ou des indépendants peuvent devoir protéger des outils très différents : dépôt Git, console cloud, partage de fichiers ou serveur local. Dans cette organisation, le portage salarial à Nice illustre la diversité des contextes professionnels et des accès à sécuriser, entre collaborateurs autonomes et ressources partagées. La priorité reste de cartographier les usages avant de choisir une technologie.

Comment combiner VPN et Zero Trust sans recréer un château fort

La coexistence des deux modèles exige une architecture explicite. Le VPN peut assurer le transport vers une zone donnée, tandis que des contrôles Zero Trust déterminent précisément ce que chaque identité peut y faire. Cette séparation évite de transformer le tunnel en passe-partout.

  • Réduire les routes annoncées : ne publier que les sous-réseaux nécessaires à une fonction précise.
  • Renforcer l’identité : imposer le MFA résistant au phishing et lier l’accès à un appareil conforme.
  • Segmenter les ressources : isoler les environnements de production, de test et d’administration.
  • Surveiller les sessions : analyser les connexions, les volumes inhabituels et les changements de posture.
  • Prévoir une révocation rapide : retirer un certificat, un jeton ou une session sans attendre l’expiration du tunnel.

Dans certains cas, un VPN par application ou par segment peut également réduire la surface d’exposition. Il ne reproduit pas toutes les capacités d’un ZTNA, mais il évite le modèle historique dans lequel une connexion réussie donne accès à un réseau entier.

Le vrai indicateur : la confiance accordée à chaque flux

Évaluer une architecture uniquement par la présence ou l’absence d’un VPN conduit à de mauvaises décisions. La question essentielle est plutôt : quelles preuves sont demandées avant d’autoriser un flux, pendant combien de temps et avec quelle granularité ? Une organisation peut supprimer ses accès distants traditionnels tout en conservant une confiance excessive dans ses comptes cloud ou ses réseaux internes.

À l’inverse, elle peut garder des VPN pour des contraintes techniques tout en appliquant une politique moderne : identité fédérée, privilèges minimaux, appareils vérifiés, segmentation, chiffrement et détection continue. Découvrez d’ailleurs tous nos dossiers technologiques sur la page d’accueil de Galibyte pour suivre les évolutions de la cybersécurité et des infrastructures.

Vers un modèle hybride et progressivement adaptatif

En 2026, le débat le plus utile n’oppose donc pas VPN et Zero Trust. Il consiste à déterminer quelles fonctions doivent être migrées vers le ZTNA, lesquelles nécessitent encore une connectivité réseau et comment surveiller les exceptions. Les VPN disparaîtront probablement de certains usages bureautiques, mais resteront pertinents pour les interconnexions, les systèmes hérités et la continuité opérationnelle.

Le Zero Trust ne supprime pas mécaniquement les tunnels : il les remet à leur juste place. Un VPN n’est plus une frontière de confiance, mais un outil parmi d’autres dans une architecture où chaque accès doit être limité, vérifiable et réversible.

Dernières publications

referencement-fr.com : accès à l’accueil, au contact et aux deux rubriques du site · Quelles actions peuvent infecter un ordinateur ? E-mails, téléchargements et clés USB · Adaptateur.net blog : comprendre les types d’adaptateurs pour choisir le bon modèle · SERP en SEO : ce que la page de résultats change pour votre visibilité

Tous nos articles