VPN vs ZTNA
ZTNA vs VPN : qu'est-ce qui change vraiment dès le premier jour ?
Quatre éléments : la latence, l'expérience de connexion, le mode d'attribution des accès et la part de votre réseau accessible depuis Internet. Oubliez la théorie. Voici ce que l'accès distant Zero Trust change concrètement dès le premier jour après la bascule.
Quatre choses que vos utilisateurs et votre équipe IT ressentent immédiatement
Le changement structurel : passer d'un accès par segment réseau à un accès par application, vérifié en continu.
| Dimension | Avec un VPN | Avec le ZTNA |
|---|---|---|
| Latence | Renvoie le trafic vers un concentrateur unique : les utilisateurs de Singapour routés via Francfort. | L'edge anycast route vers la plus proche de 330+ villes |
| Expérience utilisateur | Connexion unique, accès large toute la session ; reconnexion manuelle après veille ou changement de Wi-Fi. | WARP tourne en arrière-plan, vérifie en continu, sans reconnexion |
| Gestion des accès | Accordé par segment réseau : « les ventes ont le sous-réseau X ». | Par application, par utilisateur, par posture d'appareil : une application, rien d'autre |
| Surface d'attaque | L'IP publique accepte le trafic entrant : apparaît dans les scans Shodan et les avis CVE chaque année. | Tunnel sortant uniquement, aucun port entrant, application invisible sans session |
Pourquoi le modèle par application est le vrai changement
- Un VPN place un utilisateur authentifié sur un segment réseau, pas sur une seule application : si le compte est compromis, l'attaquant obtient une carte, pas seulement un point d'entrée.
- La politique par application rend les revues d'accès possibles : vous cessez de gérer des sous-réseaux et commencez à gérer qui atteint quoi, et vous finissez par trouver les douze personnes ayant accès à un serveur financier que personne ne se souvient d'avoir autorisé.
- Les tunnels par application ne partagent pas de domaine de défaillance : une application en panne ne coupe pas l'accès aux quarante autres, contrairement à un concentrateur VPN unique qui tombe brutalement, d'un coup, pour tout le monde.
Cela s'inscrit dans une architecture SASE et Zero Trust plus large : politique pilotée par l'identité, edge sécurisé et vérification continue fonctionnant comme un seul plan, pas quatre outils rapportés. Les mêmes groupes d'identité qui régissent l'accès aux applications peuvent aussi piloter la politique de prévention des pertes de données, contrôlant non seulement qui atteint une application mais quelles données peuvent en sortir. Associez-la à une protection DDoS continue pour défendre la couche réseau de la même façon. Les équipes soumises à de fortes exigences réglementaires y gagnent un second avantage : des règles par application et un contrôle continu des accès fournissent les preuves de contrôle d'accès attendues lors d'un audit NIS2, à la place d'un simple schéma de réseau.
Pour qui ?
Qui a vraiment besoin du ZTNA, et pour résoudre quel problème ?
Principalement les prestataires, les appareils non gérés (BYOD), les fusions-acquisitions et les anciennes applications non-HTTP. Le ZTNA prend tout son sens là où le VPN est fondamentalement inadapté, pas simplement dès que quelqu'un travaille à distance. Ces quatre cas résument la majorité des migrations que nous accompagnons.
01
Prestataires et intervenants externes
Un prestataire a besoin d'une seule application le temps d'une mission, pas d'un accès à tout un pan de votre réseau tant que personne ne pense à lui couper ses accès. Les autorisations prennent fin avec la mission, et le contrôle des accès devient une simple liste d'applications plutôt qu'une liste de plages réseau.
02
Appareils personnels (BYOD) et non gérés
La posture de l'appareil (son niveau de sécurité constaté) devient une donnée d'entrée de la politique d'accès au lieu d'une hypothèse de confiance : mise à jour du système, chiffrement du disque et enrôlement dans votre outil de gestion de parc (MDM) sont contrôlés à chaque demande d'accès. Un ordinateur personnel peut consulter le wiki interne et rien d'autre, sans installer un logiciel lourd qui verrouille la machine.
03
Fusions et acquisitions
Deux réseaux d'entreprise qui n'ont jamais été prévus pour communiquer ensemble, avec une date limite. Plutôt que de monter une interconnexion routée entre les deux, le ZTNA met à disposition la poignée d'applications utiles de chaque côté, pour une fraction du travail.
04
Applications anciennes ou spécifiques (non-HTTP)
Un vieux module ERP, un système industriel (SCADA), une application financière en TCP propriétaire. Ce sont exactement ces applications qui obligent à garder un VPN sous perfusion alors que tout le reste a déjà migré. C'est pour elles que nous utilisons l'approche hybride détaillée plus bas.
Si vous ne vous reconnaissez dans aucun de ces scénarios, chercher une alternative VPN n'a rien d'urgent : conserver un accès distant sécurisé par VPN reste une option raisonnable et votre migration peut attendre. Le besoin devient sérieux si vous cumulez des accès permanents trop larges, une flotte d'appareils variée et des applications anciennes non-HTTP.
L'architecture
Quelle architecture ZTNA choisir ?
Initié par le service pour le web derrière un NAT, initié par l'endpoint pour le RDP, le SSH et le TCP ancien. Tout le reste en est une variante. Toute architecture Zero Trust se ramène à deux modèles qui couvrent presque tous les déploiements réels, plus l'identité et un cas hybride. Se tromper, c'est ré-architecturer six mois plus tard.
01
Initié par le service (connecteur)
Un connecteur léger derrière votre application ouvre un tunnel sortant uniquement vers l'edge : pas d'IP publique, pas de règle entrante. Le cloudflared de Cloudflare est la référence. Le bon choix par défaut pour les applications web auto-hébergées et les outils internes derrière un NAT.
02
Initié par l'endpoint (client)
Un agent client construit un tunnel WireGuard chiffré depuis l'appareil avant tout trafic applicatif. Cloudflare WARP joue ce rôle, le modèle nécessaire pour le RDP, le SSH et les applications TCP/UDP anciennes jamais conçues pour un navigateur.
03
Intégration de l'identité
Aucun des deux patterns ne remplace votre IdP, ils se placent devant lui. Cloudflare Access se fédère avec Okta, Entra ID ou Google Workspace et ajoute la posture de l'appareil comme second signal. Des groupes IdP propres accélèrent tout ; corrigez d'abord ceux qui sont désordonnés.
04
L'hybride : applications anciennes, non-HTTP
Chaque environnement en a une : un module ERP, une interface SCADA, une application financière en TCP propriétaire. WARP-to-Tunnel gère cela : client endpoint pour le transport, cloudflared côté privé, politique Access par-dessus. Toujours du zero trust, sans repli VPN.
05
Ce qu'il faut exiger d'un fournisseur de solution ZTNA
Que vous compariez plusieurs éditeurs ou que vous gériez le projet en interne, quatre questions permettent de faire la différence entre un simple logiciel et un service réellement exploité : qui rédige et maintient les règles d'accès ? qui traite une tentative de connexion suspecte à deux heures du matin ? comment sont gérées les applications anciennes non-HTTP ? et que devient le VPN pendant la phase de transition ? La plupart des acteurs du marché répondent à la première question et s'arrêtent là.
L'audit de maturité
Qu'auditer avant un déploiement ZTNA ? Les applications et les utilisateurs d'abord.
Quatre éléments : quelles applications chaque groupe utilise, lesquelles parlent HTTP, qui a des accès permanents injustifiés, et votre référentiel de posture. La première cause d'une migration ratée n'est pas la technologie, c'est de démarrer sans savoir ce que l'on a. Avant d'écrire la moindre politique Access, répondez à ceci :
Quelles applications chaque groupe utilise-t-il vraiment ?
Pas ce que l'organigramme suggère, ce à quoi les gens se connectent au quotidien. Les logs VPN le montrent rarement clairement, car la plupart des configurations accordent un accès à l'échelle du sous-réseau indépendamment de l'usage réel.
Quelles applications sont en HTTP, et lesquelles ne le sont pas ?
Cela décide si une application a besoin d'Access (basé navigateur) ou d'un hybride WARP+Tunnel (protocole ancien). Trompez-vous et vous ré-architecturez en pleine migration.
Qui dispose d'accès permanents injustifiés ?
Des prestataires d'un projet terminé en 2023. D'anciens employés dont le compte VPN n'a jamais été révoqué. Cet audit à lui seul justifie généralement toute la migration.
Quel est votre référentiel de posture des appareils ?
Gérés vs BYOD, niveaux de correctifs, MDM même déployé ou non : la politique ZTNA en a besoin comme entrée, pas comme réflexion après coup.
Obtenez ces réponses avant d'écrire la moindre politique : notre équipe mène cet audit applications-et-accès avec vous et vous rend un plan de déploiement priorisé plutôt qu'une page blanche. C'est le moyen le plus rapide de savoir à quoi ressemble une migration réaliste pour votre environnement.
La migration
Comment migrer d'un VPN vers le ZTNA sans casser les accès ?
Par étapes : d'abord par groupes d'utilisateurs, puis par applications, en conservant le VPN en parallèle pendant 60 à 90 jours. Remplacer un VPN est d'abord un projet de conduite du changement, ensuite un projet réseau. Basculer une organisation du VPN au ZTNA en un week-end, c'est noyer le helpdesk dès lundi 9h. Le phasé bat le big-bang, à chaque fois que nous l'avons mené.
Étape 1
Séquencer par groupe, pas par application
Commencez par un groupe à faible risque et forte tolérance : l'IT elle-même, ou une équipe à l'aise avec les nouveaux outils. Pas l'équipe de direction, pas la finance, personne qui escaladera bruyamment si la première semaine est un peu bancale.
Étape 2
Puis par application au sein du groupe
Déplacez d'abord les schémas d'accès les plus simples, wikis internes, tableaux de bord peu sensibles, avant tout ce qui touche aux systèmes de production ou aux données financières.
Étape 3
Faire tourner VPN et ZTNA en parallèle
Ne décommissionnez pas le VPN le jour où le ZTNA passe en production. Les migrations réussies gardent les deux 60 à 90 jours : un repli pour les retardataires et de la marge pour corriger les trous de politique sur le terrain, pas dans une cellule de crise.
Étape 4
Communiquer le changement, pas seulement l'outil
Les utilisateurs remarquent le ZTNA même quand tout fonctionne : plus de « connectez-vous au VPN » chaque matin. Dites-leur pourquoi avant qu'ils ne demandent, et donnez-leur un canal identifié pour tout ce qui casse.
Étape 5
Fixer une date de décommission sur des métriques
Suivez l'adoption, l'enrôlement des appareils et le volume de tickets liés à la migration. Quand les tickets reviennent au niveau de référence et que l'adoption dépasse environ 90 %, c'est votre signal pour retirer le concentrateur, pas une date choisie à l'avance sur un plan de projet.
Un déploiement phasé ne fonctionne que si quelqu'un en est responsable après la mise en production, c'est pourquoi nous exploitons le ZTNA en service managé, pas une configuration de politique ponctuelle.
Le service managé
Comment Brixio opère-t-elle le ZTNA au quotidien ? SOC 24/7, revues d'accès continues.
Nous exploitons le ZTNA en service managé, pas une configuration de politique ponctuelle. Concrètement, cela signifie :
Des politiques construites par client
- Politiques Zero Trust ajustées à l'usage réel des applications et à la structure d'identité
- Pas un modèle générique appliqué à chaque environnement que nous touchons
- Maintenues à mesure que vos applications et groupes évoluent, pas figées une fois
SOC 24/7, follow-the-sun
- Surveillance depuis le Luxembourg, Paris, Dubaï et Singapour
- Une tentative d'accès anormale à 2h du matin est triée en direct dans une autre région
- Aucune alerte n'attend le jour ouvré suivant
Revues d'accès continues
- Autorisations obsolètes, comptes prestataires orphelins et dérive de posture détectés à cadence régulière
- Pas un audit annuel
- Une revue récurrente de qui peut atteindre quoi, pas un nettoyage ponctuel
Identité et posture tenues à jour
- Nouveaux groupes, départs et enrôlements d'appareils gérés remontent dans la politique
- Aucune resynchronisation manuelle quand votre structure IdP change
- Réponse à incident branchée directement sur l'application des politiques et le workflow du SOC
Chaque utilisateur et application se connecte via l'edge Cloudflare One, vérifié par l'identité et la posture de l'appareil à chaque requête, Brixio exploitant et ajustant la politique 24/7 sur Brixio One.
Cela repose sur la posture de sécurité permanente de Brixio
Cloudflare
Authorized Service Delivery Partner (ASDP)
ISO 27001:2022
traitement des données certifié
400+
projets livrés en EMEA & APAC
4 hubs
Luxembourg · Paris · Dubaï · Singapour, follow-the-sun
Cela repose sur la posture permanente de Brixio en tant que Cloudflare ASDP. C'est cette même équipe follow-the-sun qui pilote notre SOC managé sur Cloudflare : une tentative de connexion suspecte y est qualifiée au lieu de finir dans une file d'attente. Parlez à un expert pour dimensionner une migration VPN vers ZTNA sur vos propres applications et votre structure d'identité.