Pourquoi remplacer son VPN par du Zero Trust Network Access (ZTNA)

Le VPN d’entreprise est une technologie des années 90. Le principe — ouvrir un tunnel chiffré entre l’ordinateur du collaborateur et le réseau de l’entreprise, qui donne ensuite accès à tout — convenait à un monde où le SI vivait derrière les murs du siège. Aujourd’hui, le SI est éclaté entre M365, Google Workspace, des SaaS métier, des serveurs résiduels on-premise et des environnements cloud (Azure, AWS). Continuer à empiler des règles VPN sur ce paysage devient ingérable. Le Zero Trust Network Access (ZTNA) propose un autre contrat.

Le problème du VPN traditionnel

Un VPN d’entreprise fait essentiellement deux choses : il chiffre le trafic entre l’utilisateur et le réseau interne, et il autorise l’utilisateur à accéder à ce réseau interne. Le second point est la faiblesse structurelle. Une fois le VPN ouvert, l’utilisateur peut généralement scanner et tenter d’accéder à toutes les ressources internes — y compris celles dont il n’a pas besoin. Si son poste est compromis, l’attaquant a la même latitude.

S’ajoutent des problèmes pratiques : performances inégales (les utilisateurs nomades coupent le VPN « le temps d’une visioconférence »), maintenance lourde (renouvellement des certificats, mises à jour du concentrateur, gestion des règles pare-feu), faible granularité (souvent pas de différence entre l’accès depuis un Mac à jour et l’accès depuis un Mac jailbreaké).

Ce que change le Zero Trust Network Access

ZTNA renverse le modèle. Au lieu d’ouvrir un tunnel vers le réseau, ZTNA expose chaque application individuellement, et vérifie pour chaque tentative d’accès trois choses : qui (identité, MFA, groupe, rôle), depuis quoi (état de conformité de l’appareil : chiffré, à jour, EDR actif), pour faire quoi (l’app demandée et le risque associé).

Concrètement, l’application interne (un GitLab, un Jira on-premise, un SharePoint, un partage de fichiers) n’est plus exposée à un réseau privé que tout VPNé peut atteindre — elle est masquée derrière un proxy ZTNA qui ne laisse passer que les requêtes validées. L’utilisateur, lui, n’a plus à « se connecter au VPN » : il ouvre l’URL de l’app, est redirigé vers son IdP (Entra ID, Okta), prouve son identité, et l’accès passe ou ne passe pas selon les règles.

Les trois ZTNA qu’on rencontre le plus

Trois solutions reviennent dans 90% des cas chez nos clients :

• Cloudflare Access : excellent rapport simplicité/sécurité, payant à l’utilisateur, intégration native avec Cloudflare Tunnel pour exposer les apps internes sans ouvrir de port. Notre choix par défaut pour les PME jusqu’à 200 collaborateurs.
• Zscaler Private Access (ZPA) : la référence enterprise, écosystème complet (avec ZIA pour le proxy web sortant), idéal pour les organisations multi-sites mondialement réparties. Plus complexe à opérer, plus structuré.
• Tailscale : approche peer-to-peer basée sur WireGuard, très simple à déployer pour des équipes techniques, avec une politique fine via les ACL Tailscale. Notre choix pour les startups et les agences techniques.

L’identité au cœur du modèle

ZTNA n’a de sens qu’avec une identité d’entreprise robuste en façade. Concrètement : un IdP unique (Entra ID, Okta, Google Workspace), du MFA obligatoire avec au moins une méthode forte (passkey FIDO2 ou Authenticator avec verrouillage biométrique du téléphone), et une fédération SSO vers toutes les apps métier via SAML ou OIDC.

C’est aussi le moment d’introduire les passkeys : un facteur d’authentification résistant au phishing, supporté par tous les éditeurs majeurs depuis 2023, qui remplace progressivement le mot de passe + code SMS. Sur les déploiements ZTNA récents, nous activons les passkeys par défaut sur les comptes administrateurs.

La conformité de l’appareil, le second pilier

L’autre apport de ZTNA est de pouvoir conditionner l’accès à l’état de conformité de l’appareil : un Mac chiffré, à jour, avec EDR actif et géré par MDM peut accéder à l’app financière ; un Mac personnel non géré ne peut pas. Cette logique nécessite de coupler le ZTNA au MDM (Kandji, Jamf, Intune) et à l’EDR (Defender, CrowdStrike) pour exposer le « device posture » au moteur de décision ZTNA.

C’est le mariage MDM + EDR + IdP + ZTNA qui donne au modèle Zero Trust son nom : on ne fait confiance à rien par défaut, on vérifie à chaque accès.

Combien de temps ça prend

Pour une PME de 50 collaborateurs, un déploiement ZTNA typique chez nous se fait en 6 à 10 semaines : 2 à 3 semaines de cadrage et de design (inventaire des apps, identification des dépendances réseau, design du modèle d’identité et des règles), 2 à 3 semaines de mise en place technique (Cloudflare Tunnel ou équivalent, intégration IdP, premiers tests), 2 à 4 semaines de migration progressive avec coexistence VPN + ZTNA, puis débranchement final du VPN.

Si vous opérez encore un VPN d’entreprise et que vous sentez le poids opérationnel monter, le formulaire en bas de la home est fait pour démarrer la conversation.