SDP vs VPN : quelles différences et lequel choisir en entreprise ?
Ici, SDP signifie Software-Defined Perimeter, périmètre défini par logiciel.
En bref : un VPN donne un accès au réseau via un tunnel chiffré. Un SDP donne un accès ressource par ressource, selon l’identité, le contexte et souvent l’état du terminal. Le SDP est plus proche d’une logique Zero Trust. Le VPN reste pertinent pour certains accès réseau plus larges ou des environnements legacy.
Sommaire
- SDP vs VPN : la différence en une minute
- SDP, ZTNA, SASE : ce que ces termes veulent dire
- VPN d’entreprise : ce qu’il fait bien, ce qu’il expose encore
- SDP : ce qu’il change vraiment
- Remote access vs site-to-site : ne comparez pas n’importe quoi
- Ce qu’un SDP ne remplace pas automatiquement
- Coexistence : quand garder les deux
- Verdict
- FAQ
SDP vs VPN : la différence en une minute
La question n’est pas « lequel est le plus sécurisé », c’est la mauvaise façon de la poser.
La vraie question : quel type d’accès veut-on sécuriser, avec quel niveau de granularité, pour quels utilisateurs, et avec quelles contraintes d’infrastructure existante ?
Un VPN d’accès distant crée un tunnel chiffré entre le terminal d’un utilisateur et un concentrateur réseau. Une fois le tunnel établi, l’utilisateur accède aux ressources internes comme s’il était sur le réseau local. L’unité d’accès est le réseau.
Un SDP accorde un accès ressource par ressource, après vérification de l’identité, du contexte et souvent de l’état du terminal. L’unité d’accès est l’application ou le service.
Le sujet n’est pas le chiffrement seul. Le sujet est la portée réelle de l’accès.
| VPN classique | SDP / ZTNA | |
|---|---|---|
| Unité d'accès | Réseau | Application |
| Logique dominante | Tunnel chiffré | Identité + contexte |
| Surface exposée | Point d'entrée réseau | Ressources non découvertes avant autorisation |
| Cas fort | Accès général, environnement stable | Accès tiers, ressources sensibles, cloud distribué |
| Adapté au site-to-site | Oui | Non, sauf cas spécifiques |
SDP, ZTNA, SASE : ce que ces termes veulent dire
Ces trois termes ne sont pas interchangeables. Les confondre, c’est perdre la capacité de comparer des solutions.,
Zero Trust est d’abord un ensemble de principes de sécurité, formalisés par le NIST (SP 800-207) : ne jamais présumer la confiance, toujours vérifier, quel que soit l’emplacement de l’utilisateur ou du terminal. C’est une posture, pas un produit.Les approches de déploiement qui permettent de la mettre en œuvre incluent le SDP, la microsegmentation, et le SASE, et pour certaines organisations, un VPN pour entreprise Zero Trust comme point de départ de la transition.
SDP (Software-Defined Perimeter) est l’un de ces modèles historiques. Le concept a été associé aux travaux de la DISA, puis formalisé par la Cloud Security Alliance, qui a publié la spécification SDP v1.0 en 2014.
SDP est le vocabulaire architectural.
ZTNA (Zero Trust Network Access) est le vocabulaire de marché. Le terme ZTNA s’est imposé là où SDP reste surtout un vocabulaire architectural. SDP et ZTNA se recoupent souvent, mais ils ne jouent pas exactement le même rôle : ZTNA peut englober des approches proxy inverse qui ne suivent pas strictement l’architecture SDP au sens CSA.
SASE (Secure Access Service Edge) est un cadre architectural plus large, qui combine réseau (SD-WAN) et sécurité (ZTNA, CASB, SWG, FWaaS) dans une plateforme cloud unifiée. Le ZTNA/SDP est un composant du SASE, pas son équivalent. Évaluer une solution SDP ne nécessite pas d’engager une transformation SASE complète.
Un meilleur discours marketing ne corrige pas une mauvaise architecture d’accès. Savoir ce que ces termes recouvrent réellement aide à évaluer ce qu’on achète.
VPN d’entreprise : ce qu’il fait bien, ce qu’il expose encore
Un VPN d’accès distant d’entreprise n’est pas un produit d’anonymisation. Sa fonction première est d’étendre un accès réseau sécurisé à travers un réseau public, permettre à un terminal distant d’accéder aux ressources internes comme s’il était connecté localement. Le NIST (SP 800-215) décrit le VPN comme une extension de la sécurité périmétrique via un tunnel sécurisé.
Pour des accès réseau généraux, des environnements stables et des postes maîtrisés, le VPN Pro reste une réponse solide. On en parle moins parce qu’il vend moins de rupture, pas parce qu’il a cessé d’être utile.
Ce qu’il expose : dans un VPN d’accès distant classique, l’établissement du tunnel précède souvent la granularité fine des contrôles d’accès. Si une identité est compromise, l’attaquant peut hériter d’une portée réseau plus large que ce que ses fonctions justifient. La maîtrise des accès repose alors davantage sur des contrôles réseau relativement statiques, règles firewall, ACL, que sur une politique d’identité dynamique. Le choix des protocoles VPN pour votre entreprise joue aussi sur cette équation : tous n’offrent pas le même niveau de contrôle d’accès natif.
Les concentrateurs VPN écoutent sur des ports publics détectables. Ce n’est pas une fatalité, c’est une surface à gérer.
SDP : ce qu’il change vraiment
Le changement fondamental du SDP n’est pas le chiffrement, le VPN chiffre aussi. C’est la granularité d’accès et la posture avant connexion.
Le SDP n’est pas un VPN modernisé. C’est un autre modèle de contrôle.
Dans l’architecture SDP historique définie par la Cloud Security Alliance, les ressources ne sont pas exposées à la découverte avant authentification et autorisation. En pratique, l’utilisateur n’obtient pas une visibilité réseau générale : un point de contrôle ou une passerelle n’expose que les applications explicitement autorisées. Le Single Packet Authorization (SPA) fait partie du modèle SDP canonique CSA, mais toutes les offres ZTNA du marché ne s’appuient pas sur ce mécanisme au sens strict.
L’accès est accordé ressource par ressource, session par session, après vérification de l’identité, du contexte et souvent de la posture du terminal. Sans IdP robuste, MFA appliqué et visibilité sur les terminaux, un SDP n’est pas une architecture solide. C’est une promesse de granularité posée sur un socle incomplet.
Ce que ça change concrètement : si une identité est compromise, l’attaquant n’accède qu’à la ressource spécifiquement autorisée pour cette session. Le risque de mouvement latéral est structurellement réduit, pas éliminé, mais réduit.
Ce que ça ne garantit pas : le SDP ne protège pas contre tous les vecteurs d’attaque. Il ne remplace pas un EDR, un SIEM, ni une gestion des identités solide. C’est un contrôle d’accès, pas un programme de sécurité complète.
Remote access vs site-to-site : ne comparez pas n’importe quoi
Elle change pourtant radicalement la conclusion.
VPN remote access : connecte un utilisateur distant à un réseau d’entreprise. C’est le cas d’usage où le SDP/ZTNA est le plus pertinent comme alternative ou complément. La granularité applicative du SDP répond directement au modèle « accès réseau large » du VPN remote access.
VPN site-à-site : connecte deux réseaux entre eux, deux bureaux, un bureau et un datacenter, une infrastructure on-premise et un cloud privé. Dans ce cas, le SDP n’est pas une alternative naturelle. Le VPN site-à-site opère au niveau réseau, pour des flux techniques souvent larges et stables. Le remplacer par du ZTNA applicatif n’a de sens que dans certaines configurations cloud-first spécifiques.
Ce qu’un SDP ne remplace pas automatiquement
L’écosystème IdP/MFA : si la gestion des identités est fragile, déployer un SDP ne règle pas le problème. Il améliore le contrôle d’accès, pas la qualité du socle IAM.
La gestion des postes : le SDP peut vérifier la posture d’un terminal, mais seulement si un MDM ou un EDR expose cet état. Sans inventaire des terminaux, la vérification de posture reste théorique.
Les accès techniques et legacy : certains accès réseau, connexions entre serveurs, accès aux équipements réseau, protocoles industriels, ne se modélisent pas facilement en accès applicatif ZTNA. Le VPN reste souvent la solution opérationnelle pour ces cas.
Les accès site-à-site : comme vu plus haut, le SDP ne remplace pas un VPN site-à-site dans la plupart des architectures actuelles.
La sécurité applicative : le SDP contrôle qui accède à quoi. Il ne contrôle pas ce qui se passe à l’intérieur de l’application une fois l’accès accordé. WAF, DAST, gestion des secrets, ces sujets restent entiers. Pour les environnements qui s’appuient sur des SaaS en entreprise, cette distinction est particulièrement critique : l’accès peut être sécurisé, les données à l’intérieur de l’application, elles, ne le sont que si le fournisseur les protège aussi de son côté.
Un produit ne compense pas un socle IAM faible. Le SDP est un contrôle d’accès réseau évolué, pas un programme de sécurité.
Coexistence : quand garder les deux
La coexistence VPN + SDP est fréquente dans les organisations en transition. Ce n’est pas un compromis par défaut : c’est souvent une réponse architecturale cohérente quand tous les cas d’usage ne se modélisent pas encore en accès applicatif granulaire.
- Des tiers ou prestataires accèdent régulièrement aux ressources internes
- L’infrastructure est distribuée sur plusieurs clouds ou en hybride
- Des applications ou données critiques doivent être isolées des accès généraux
- La surface d’exposition des concentrateurs VPN est identifiée comme un risque actif
Verdict : que choisir entre SDP et VPN ?
Si votre besoin principal est d’ouvrir un accès distant général à des collaborateurs internes, sur une infrastructure stable et majoritairement on-premise, le VPN reste une réponse défendable.
Si votre problème porte sur la granularité des accès, l’exposition des ressources, l’accès des tiers ou la protection d’applications sensibles dans un environnement hybride ou cloud, le SDP/ZTNA apporte une réponse plus adaptée.
Dans beaucoup d’entreprises, le bon choix n’est pas un remplacement brutal. Le bon choix est de réserver le VPN aux accès réseau larges ou legacy, et d’introduire le SDP là où la granularité d’accès devient un enjeu réel.
Questions fréquentes
SDP et ZTNA, c'est la même chose ?
Pas exactement. SDP est le vocabulaire architectural, celui de la Cloud Security Alliance. ZTNA est le vocabulaire de marché, dominant aujourd’hui chez Gartner et dans les appels d’offres. Les deux se recoupent souvent, mais ZTNA est plus large : il peut englober des approches proxy inverse qui ne suivent pas strictement l’architecture SDP au sens CSA.
Mon VPN d'entreprise actuel est-il obsolète ?
Non au sens technique. Un VPN bien configuré, mis à jour et couplé au MFA reste opérationnel. La question n’est pas « est-il obsolète » mais « couvre-t-il mes cas d’usage actuels », notamment si des tiers accèdent à vos ressources, si votre infrastructure est distribuée dans le cloud, ou si vous avez des exigences de granularité que le VPN pro ne peut pas satisfaire sans une complexité firewall excessive.
Peut-on utiliser SDP et VPN simultanément ?
Oui, et c’est fréquent. Le SDP prend en charge les accès à fort enjeu de granularité, le VPN gère les accès réseau plus larges ou les flux site-à-site. Les deux coexistent sans conflit technique dans la plupart des architectures.
Le SDP remplace-t-il le pare-feu ?
Non. Le SDP contrôle l’accès aux applications et ressources selon l’identité et le contexte. Il ne remplace pas le filtrage du trafic réseau qu’assure un pare-feu. Les deux sont complémentaires.
Qu'est-ce que le SPA (Single Packet Authorization) ?
Le SPA est un mécanisme du modèle SDP canonique défini par la Cloud Security Alliance : une passerelle ne répond qu’à une requête authentifiée, ce qui limite fortement l’exposition à la découverte. Ce mécanisme ne s’applique pas à l’ensemble du marché ZTNA, certaines solutions appliquent une logique proche via d’autres architectures de contrôle d’accès, sans SPA au sens strict.
Un SDP suffit-il seul à sécuriser les accès distants ?
Non. Sans IdP robuste, MFA appliqué et visibilité sur les terminaux, un SDP n’est pas opérationnel. La qualité du contrôle d’accès dépend directement de la qualité du socle identité, de la posture terminale et des politiques appliquées. Le SDP est un contrôle d’accès, pas une posture de sécurité autonome.