Le VPN fait ce pour quoi il a été inventé : prolonger le réseau de l’entreprise jusqu’à l’utilisateur. Le problème, c’est qu’il s’arrête là. Il n’a pas été conçu pour évaluer en continu l’identité, la posture de l’appareil, la localisation, le risque utilisateur ou le contexte de session. Une fois le tunnel ouvert, la confiance est accordée en bloc et pour la durée de la connexion.
Résultat : les applications d’IA, le SaaS, les applications on-premises, les services non gérés et le trafic Internet se retrouvent protégés de manière inégale. Ce sont précisément ces couches que les attaquants ciblent — les nouvelles expériences d’IA, en particulier, sont rarement gouvernées avec la même rigueur que les applications métier historiques.
Ce que veut dire Zero Trust ici, concrètement
Zero Trust n’est pas une coquille plus dure autour du réseau. Il s’agit de rapprocher l’application de la politique de l’utilisateur, de la session et de la ressource : évaluer chaque demande d’accès à partir des signaux d’identité, d’appareil, d’application, de localisation et de risque ; n‘accorder que le minimum d’accès nécessaire ; et ajuster cet accès dès que la posture ou le risque évolue.
Trois principes structurent désormais le modèle Microsoft : vérifier explicitement, appliquer le moindre privilège, présumer la compromission.
Les briques techniques
L’accès conditionnel ENTRA ID joue le rôle de moteur de politique, en combinant identité, état de l’appareil, localisation, application cible et risque pour prendre les décisions d’accès. Global Secure Access — c’est-à-dire Microsoft Entra Internet Access et Microsoft Entra Private Access — étend ensuite ces contrôles pilotés par l’identité aux applications d’IA, au SaaS, aux ressources on-premises et aux sessions Internet, sans la complexité d’une architecture VPN héritée.
Concrètement : Entra Internet Access apporte la navigation « threat-aware », le filtrage de contenu web et des contrôles SaaS granulaires, là où le VPN ne voyait qu’un simple tunnel pour le moins opaque.
L’intérêt côté direction, pas seulement côté IT
Le bénéfice n’est pas uniquement technique — il change la façon dont les équipes travaillent :
- Risque de compromission réduit, grâce à des réponses automatisées et pilotées par la politique face aux signaux de compromission.
- Opérations plus rapides, en réduisant la complexité du VPN et en évoluant vers un modèle Security Service Edge cloud-native.
- Meilleure expérience utilisateur, avec un accès sécurisé qui évite les frictions du split-tunnel et les connectivités inconstantes.
- Coûts maîtrisés, par une moindre dépendance au matériel on-premises et aux outils de sécurité redondants.
Le gain le plus durable est ailleurs : au lieu d’entretenir un jeu de règles pour les outils d’IA, un autre pour les applications on-premises et un troisième pour le SaaS, les équipes étendent un cadre Zero Trust commun à l’ensemble. Un compte compromis déclenche alors une réponse rapide et pilotée par la politique sur les chemins d’accès cloud comme privés, au lieu de reposer sur un confinement manuel.
Ce qui faut en retenir
- Étendre Zero Trust au-delà du cloud : chaque application, chaque session, chaque ressource.
- Utiliser les détections de risque Entra et la remédiation automatisée pour déclencher des réponses en temps réel.
- Couvrir le trafic Internet, les applications non fédérées et les usages liés à l’IA — sans empiler une couche d’outils supplémentaire.
- Réduire complexité et coûts en retirant les architectures VPN-centriques au profit d’un accès basé sur la politique.
Par où commencer ?
Le point de départ le plus rentable est un audit : quels chemins d’accès dépendent encore du VPN aujourd’hui ? Ensuite, choisir un groupe applicatif à fort impact et y piloter une couverture identity-first, avant de généraliser.
Pour un responsable sécurité, l’enjeu n’est donc pas seulement de moderniser l’accès distant, c’est de faire de l’identité, et non du réseau, le vrai périmètre.
Laurent TERUIN
