Cas pratique : basculer de VPN vers ZTNA en PME

Le VPN a longtemps été le réflexe naturel des PME pour connecter des collaborateurs nomades, des prestataires et quelques applications critiques. En 2026, ce modèle montre pourtant ses limites : surface d’attaque trop large, politiques d’accès trop grossières et expérience utilisateur souvent frustrante. Le ZTNA propose une alternative plus fine, plus auditable et plus adaptée à une organisation distribuée.

Dans ce cas pratique, prenons une PME de 180 personnes avec deux sites, un ERP exposé en interne, quelques outils SaaS et une équipe de support externe. Le point de départ est classique : un concentrateur VPN unique, des profils d’accès par sous-réseau et des exceptions qui se sont accumulées au fil des ans. Le résultat est prévisible : trop d’utilisateurs voient trop de choses, et chaque incident se transforme en débat sur les règles réseau.

Pourquoi le VPN devient un point faible

Le VPN n’est pas “mauvais” par nature ; il est surtout devenu trop permissif pour les usages modernes. Une fois connecté, l’utilisateur hérite souvent d’un périmètre trop vaste, alors que la logique Zero Trust impose de vérifier en continu l’identité, le contexte et le niveau de risque. Plus la PME grandit, plus cette approche globale devient difficile à maintenir sans créer de dette opérationnelle.

Le scénario de migration le plus réaliste

Le basculement réussi ne consiste pas à “couper le VPN” du jour au lendemain. En pratique, il faut cartographier les usages, distinguer les applications candidates au ZTNA et conserver temporairement un accès VPN pour certains cas hérités, comme l’administration d’équipements anciens ou des flux industriels spécifiques. L’objectif est de migrer d’abord les parcours les plus fréquents, ceux qui apportent un gain immédiat en sécurité et en simplicité.

Étape 1 : inventorier les flux réels

La première erreur est de raisonner par technologie plutôt que par besoin métier. Il faut donc partir des applications : ERP, intranet, Git, outils RH, consoles d’administration et applications web internes. Pour chacune, on identifie les profils utilisateurs, le niveau de sensibilité et la fréquence d’usage.

Étape 2 : définir des politiques d’accès minimales

Un bon projet ZTNA repose sur des règles simples : qui a le droit d’accéder à quelle ressource, depuis quel type d’équipement, avec quel niveau d’authentification. Ajoutez l’état du terminal si possible : conformité MDM, chiffrement du disque, présence d’un agent EDR et géolocalisation approximative si elle a du sens pour votre contexte.

Étape 3 : publier les applications, pas le réseau

La différence majeure avec le VPN est là. Le ZTNA n’expose pas un segment entier, mais une application ou un service précis, derrière une passerelle qui applique la politique d’accès. Pour l’utilisateur, cela se traduit souvent par une connexion plus rapide, moins de latence perçue et moins de “vous êtes connecté mais rien ne marche”.

À ce stade, les équipes IT gagnent aussi en finesse de diagnostic. Les logs d’accès deviennent plus lisibles, car ils décrivent des interactions applicatives plutôt qu’un simple établissement de tunnel. Cela facilite les audits, l’analyse d’incidents et le travail conjoint entre le réseau, la sécurité et les équipes poste de travail.

Dans un autre registre, les plateformes qui structurent bien leurs parcours d’information rappellent la même logique d’accès ciblé. Sur Le Six, la navigation par intention évite de noyer le visiteur sous trop de choix d’un coup : on va droit au contenu utile, sans détour inutile. Cette sobriété de parcours est finalement très proche de l’esprit ZTNA.

Plan de déploiement sur 90 jours

Une migration pragmatique peut tenir en trois phases. La première concerne le cadrage, la deuxième le pilote, la troisième la généralisation. Ce séquencement permet de limiter les risques de rupture et d’obtenir des retours concrets avant d’élargir le périmètre.

Les indicateurs qui prouvent que la migration fonctionne

Le succès ne se mesure pas seulement au nombre de connexions ZTNA actives. Les bons indicateurs sont plus opérationnels : baisse des tickets liés à l’accès distant, diminution du temps moyen de résolution, réduction du nombre d’applications visibles depuis un poste non conforme, et meilleure traçabilité des accès administratifs.

Il faut aussi surveiller l’acceptation utilisateur. Si le changement améliore la fluidité sans multiplier les authentifications inutiles, l’adoption suit généralement très vite. À l’inverse, une politique trop agressive peut recréer la complexité qu’elle cherchait à éliminer.

Ce qu’il faut retenir pour une PME

Le passage du VPN au ZTNA n’est pas une mode, mais une évolution logique vers un accès plus granulaire, plus sûr et plus compatible avec le télétravail, les prestataires et les applications hybrides. Pour une PME, le bon objectif n’est pas de “faire moderne”, mais de réduire la surface d’attaque tout en simplifiant la vie des équipes. Si vous souhaitez explorer d’autres dossiers techniques de ce type, découvrez tous nos services sur notre page d'accueil.

En pratique, la meilleure migration est celle qui commence petit, prouve sa valeur rapidement, puis remplace progressivement les dépendances historiques. Le VPN peut survivre comme solution de repli pendant un temps, mais il ne devrait plus rester le centre de gravité de l’accès distant.