Quel protocole VPN choisir en entreprise selon votre architecture réseau ?
Choisir un protocole VPN pour son entreprise n’est pas une question de performance abstraite. C’est une décision d’architecture : quel type de connexion faut-il sécuriser, quelles contraintes réseau s’appliquent, quelles exigences réglementaires entrent en jeu ? La réponse correcte pour un télétravailleur derrière un pare-feu strict n’est pas la même que pour interconnecter deux sites physiques sur du matériel dédié.
La question du protocole vient après une décision préalable : celle de la topologie de votre VPN d’entreprise, un choix que nous détaillons dans notre analyse sur VPN internalisé ou externalisé, selon la taille de votre organisation et le niveau de contrôle souhaité.
En bref — les arbitrages par topologie
- Interconnexion de sites sur matériel dédié : IPsec/IKEv2 dans la quasi-totalité des cas, recommandé par l’ANSSI, supporté nativement par les pare-feux et routeurs professionnels.
- Accès distant, flotte mobile : IKEv2/IPsec, intégration native dans Windows, macOS, iOS, gestion MOBIKE pour la continuité réseau.
- Réseau restrictif, pare-feu bloquant UDP : OpenVPN TCP/443 en solution de repli, passe mieux les filtrages simples, sans garantie face à une inspection avancée.
- WireGuard : transport performant, rarement suffisant seul, nécessite une couche de gestion (Tailscale, Netbird) pour une exploitation à l’échelle en entreprise.
- PPTP : à éliminer sans débat.
- L2TP/IPsec : transition héritée sans avantage moderne, à faire disparaître de l’infrastructure.
Cette page traite exclusivement des protocoles VPN dans un contexte d’infrastructure d’entreprise, accès distant, interconnexion de sites, déploiement MDM et conformité réglementaire. Pour la présentation technique des protocoles et leur fonctionnement, voir notre guide des protocoles VPN.
Deux topologies, deux logiques de choix
Avant d’évaluer un protocole, l’entreprise doit identifier la topologie qu’elle déploie. Ce choix conditionne directement quels protocoles sont pertinents, quels équipements sont concernés et quelles contraintes d’exploitation s’appliquent.
L’accès distant établit une connexion temporaire entre un poste utilisateur et le réseau de l’entreprise. Il s’active à la demande, collaborateurs en télétravail, déplacement professionnel, accès depuis un réseau mobile. Le protocole doit ici gérer des authentifications individuelles, supporter les changements de réseau sans coupure et s’intégrer dans une chaîne MDM ou SSO.
L’interconnexion de sites crée un tunnel permanent entre deux équipements réseau, pare-feux, routeurs, concentrateurs. Il n’y a pas d’utilisateur final à authentifier à la demande : c’est une association de sécurité machine-à-machine, configurée une fois, opérationnelle en continu. Le protocole doit ici privilégier la stabilité, l’interopérabilité entre constructeurs et la compatibilité avec du matériel certifié.
Cette distinction rejoint une réflexion plus large sur l’architecture d’accès, notamment lorsque la question se pose de remplacer un VPN traditionnel par une approche orientée identité et contrôle granulaire. Notre comparatif SDP contre VPN développe ce périmètre.
IPsec : le protocole de référence pour les infrastructures d’entreprise
IPsec est une suite de standards IETF qui opère au niveau de la couche réseau. En contexte d’entreprise, ce qui compte n’est pas la taxonomie interne du protocole mais son comportement opérationnel : il chiffre et authentifie les paquets via ESP (Encapsulating Security Payload), s’appuie sur IKEv2 pour la négociation et le renouvellement des clés, et gère la traversée NAT via l’encapsulation UDP d’ESP, un point que les déploiements en environnement hétérogène rencontrent systématiquement.
L’ANSSI dispose d’un guide officiel dédié à IPsec, DAT-NT-003 v1.1 (août 2015), toujours accessible sur son portail et cité dans des publications plus récentes. Il recommande IPsec comme protocole prioritaire pour les VPN professionnels, aussi bien pour le nomadisme que pour les liaisons entre sites. Cette recommandation repose sur la maturité cryptographique du protocole, son implémentation dans les équipements certifiés et son support dans la quasi-totalité des pare-feux professionnels, Cisco ASA, Fortinet FortiGate, Palo Alto, pfSense, OPNsense.
IPsec est le choix dominant pour les configurations site-to-site pour une raison pratique : il est natif dans l’écosystème des équipements réseau professionnels. L’interopérabilité entre constructeurs différents reste faisable en suivant les standards IKEv2 + ESP, mais elle n’est pas garantie sans vérification préalable des suites cryptographiques supportées de chaque côté. Certains constructeurs introduisent des paramètres propriétaires dans les phases IKE qui peuvent compliquer les configurations hétérogènes, un inventaire précis des capacités de chaque équipement est indispensable avant déploiement.
IKEv2 : le protocole naturel pour les flottes mobiles
IKEv2 (RFC 7296) est le mécanisme d’échange de clés associé à IPsec. Bien que techniquement indissociable d’IPsec pour le chiffrement, il mérite une entrée distincte parce que c’est lui qui détermine le comportement du tunnel côté utilisateur, et c’est sur ce terrain qu’il se distingue pour les déploiements d’accès distant.
Son atout principal en contexte entreprise est la gestion native des changements d’adresse IP via MOBIKE (RFC 4555) : lorsqu’un collaborateur bascule du Wi-Fi d’un hôtel vers le réseau mobile, ou change d’interface réseau, la session IKEv2/IPsec reste active sans coupure ni réauthentification. Pour une flotte de postes mobiles, c’est la différence entre un VPN transparent et un VPN que les utilisateurs contournent parce qu’il déconnecte à chaque changement de réseau.
IKEv2 est intégré nativement dans Windows, macOS et iOS. Sur Android, le profil de plateforme VPN expose bien IKEv2/IPsec. À partir d’Android 11, la bibliothèque IPsec/IKEv2 constitue l’implémentation par défaut du client IKEv2 ; sur les versions plus anciennes, la prise en charge et l’interopérabilité peuvent être plus variables. Il est possible de déployer un accès VPN d’entreprise sur toute une flotte sans installer de client tiers, un argument fort pour les équipes IT avec des politiques strictes sur les applications tierces. IKEv2 s’intègre avec les PKI d’entreprise via certificats X.509 et supporte l’authentification EAP, ce qui permet de le connecter à un annuaire Active Directory ou un serveur RADIUS existant sans reconfiguration majeure.
WireGuard® : transport performant, architecture à compléter
WireGuard® est intégré au noyau Linux depuis la version 5.6 (2020). Sa base de code est nettement plus réduite que celle d’OpenVPN, ce qui diminue la surface d’audit et contribue à ses performances mesurées, latence plus faible, empreinte CPU inférieure à IPsec en mode logiciel. Ces qualités sont réelles et documentées.
Mais en contexte entreprise, WireGuard® natif présente des contraintes structurelles que les comparatifs grand public passent sous silence.
Le problème de la gestion des pairs : WireGuard® repose sur un modèle de clés publiques statiques échangées à l’avance, chaque utilisateur autorisé correspond à une clé configurée dans le serveur. Dans une flotte de dix postes stables, c’est gérable. Dans une organisation avec rotation, départs et plusieurs appareils par personne, la gestion manuelle devient un risque opérationnel. WireGuard® natif n’intègre pas de PKI, pas de gestion d’identité centralisée, pas de révocation automatique. Par ailleurs, tout le trafic passe en UDP, ce qui le rend sujet aux mêmes blocages pare-feu qu’IKEv2 dans les environnements réseau restrictifs.
Des outils comme Tailscale, Netbird ou Headscale résolvent ce problème en ajoutant une couche de contrôle au-dessus de WireGuard®, SSO, ACL, provisionnement automatique. Mais ce ne sont alors plus des déploiements WireGuard® purs : c’est WireGuard® comme couche de transport dans une architecture gérée. La distinction est importante pour les équipes qui évaluent la conformité ou planifient des audits.
Cas d’usage où WireGuard est pertinent en entreprise : organisations avec une équipe IT technique capable de maintenir la configuration des pairs, infrastructures sur Linux à architecture conteneurisée ou distribuée, tunnels inter-instances ou inter-régions dans un environnement homogène. Pour les PME sans ressources techniques internes, la complexité opérationnelle de WireGuard natif est régulièrement sous-estimée.
WireGuard® est une marque déposée de Jason A. Donenfeld
OpenVPN : le recours en environnement contraint
OpenVPN n’est pas le protocole le plus performant, ni le plus simple à déployer. Mais il conserve un avantage décisif dans un cas d’usage précis : les environnements réseau hostiles.
En mode TCP/443, OpenVPN génère un trafic qui ressemble à du HTTPS et passe mieux les filtrages simples, pare-feux d’hôtels, réseaux d’entreprises clientes avec politique UDP restrictive. Ce n’est pas une invisibilité garantie : des équipements DPI avancés peuvent identifier le protocole même sur ce port, c’est précisément pourquoi des techniques d’obfuscation existent en complément. TCP/443 est un repli efficace contre les filtrages basiques, pas une solution universelle contre l’inspection profonde.
Sur les déploiements site-to-site, OpenVPN est moins naturel et moins interopérable que IPsec sur des pare-feux et routeurs professionnels, ces équipements supportent IPsec nativement, pas OpenVPN. Plusieurs configurations d’entreprise l’utilisent néanmoins en point-à-point, notamment sur des environnements Linux homogènes ou des contextes où le parc logiciel est maîtrisé. C’est une option, pas le choix de référence pour cette topologie.
Limites en production : OpenVPN fonctionne en espace utilisateur, ce qui génère une charge processeur visible sur des concentrateurs sous forte sollicitation. Sa configuration correcte demande une maîtrise de TLS et de la gestion de certificats. L’absence d’intégration native dans les systèmes d’exploitation alourdit les déploiements MDM.
VPN SSL : un terme historique à ne pas confondre avec un protocole de tunneling
Les documentations Cisco, Palo Alto ou Fortinet mentionnent régulièrement le « SSL VPN » comme une famille d’accès distant. Le terme renvoie à des solutions qui utilisent TLS comme couche de transport, soit via un client dédié fourni par l’éditeur, soit en mode sans client via navigateur, où l’accès est limité à des applications web désignées plutôt qu’à l’ensemble du réseau.
Ce n’est pas un protocole de tunneling au même sens qu’IPsec, WireGuard® ou OpenVPN. C’est un mode d’accès applicatif. Utile pour un accès nomade léger à quelques ressources métier, il ne remplace pas une architecture VPN réseau complète. OpenVPN s’appuie lui-même sur TLS, mais constitue une couche de tunneling réseau à part entière, il n’est pas un « SSL VPN » au sens Cisco du terme.
PPTP et L2TP/IPsec : protocoles hérités à remplacer
PPTP utilise RC4 avec des clés de 128 bits. Des attaques pratiques contre MS-CHAPv2, l’authentification par défaut de PPTP, sont documentées depuis 2012. Des outils publics permettent de récupérer les identifiants en quelques heures sur du matériel ordinaire. En 2026, maintenir PPTP dans une infrastructure est difficile à défendre dans toute analyse de risques sérieuse.
L2TP/IPsec est dans une position différente : combiné à IPsec avec des paramètres modernes, il n’est pas intrinsèquement cassé. Mais il n’apporte aucun avantage sur IKEv2/IPsec, il ajoute une surcharge protocolaire inutile sans gain de sécurité ou de performance. C’est une couche de transition héritée pour les systèmes qui ne supportent pas IKEv2 ; ce ne sont pas les mêmes reproches que ceux adressés à PPTP, mais la conclusion est la même : la migration est la bonne réponse, pas l’optimisation.
Ce que disent vraiment les référentiels
L’ANSSI privilégie IPsec pour les usages professionnels et sensibles, c’est une recommandation explicite, documentée et sourcée. C’est le seul protocole pour lequel un guide dédié existe dans la doctrine française de sécurité des systèmes d’information.
ISO 27001, en revanche, n’impose pas un protocole précis. C’est une norme de management fondée sur l’analyse de risques : elle demande à l’organisation d’identifier ses menaces, de choisir des mesures adaptées et de les maintenir dans le temps. Ce qui compte pour la conformité ISO 27001 n’est pas le nom du protocole dans la configuration, c’est la cohérence entre le protocole retenu, la gestion des clés, les mécanismes d’authentification, la journalisation, le maintien en condition de sécurité et la revue régulière des risques.
En pratique : un déploiement WireGuard® bien géré, audité et documenté peut satisfaire une revue ISO 27001. Un déploiement IPsec mal configuré, avec des suites cryptographiques obsolètes et sans gestion des certificats, ne le satisfera pas. Le protocole est un élément du dispositif, pas une garantie en soi.
Grille de décision par cas d’usage
| Cas d'usage | Protocole recommandé | Contrainte principale | Référentiel / lecture conformité |
|---|---|---|---|
| Interconnexion de sites, matériel dédié | IPsec / IKEv2 | Interopérabilité entre constructeurs à vérifier | Compatible avec une approche sérieuse, recommandé ANSSI |
| Accès distant, flotte mobile Windows/macOS/iOS | IKEv2 / IPsec | UDP 500/4500 doit être accessible | Compatible avec une approche sérieuse, recommandé ANSSI |
| Accès distant — réseau restrictif, UDP bloqué | OpenVPN TCP/443 | Charge processeur ; DPI avancé peut l'identifier | Compatible avec une approche sérieuse, si certificats correctement gérés |
| Infrastructure distribuée sur Linux / équipe technique | WireGuard + couche de gestion | Gestion des pairs, pas de PKI native | À justifier, dépend de l'implémentation et du niveau de gestion |
| Accès applicatif nomade léger (sans client) | SSL VPN (TLS / sans client) | Accès limité à des applications désignées | À justifier, selon périmètre et implémentation |
| Équipements anciens ne supportant pas IKEv2 | OpenVPN ou L2TP/IPsec (temporaire) | Migration à planifier | À justifier, dette technique documentée |
| PPTP (existant) | Migration immédiate | Chiffrement cassable, attaques documentées | À migrer, difficile à défendre dans toute analyse de risques |
Questions fréquentes
Quel protocole VPN recommande l'ANSSI pour les entreprises ?
L’ANSSI maintient une référence officielle dédiée à IPsec, DAT-NT-003 v1.1 (août 2015), encore citée par des guides ANSSI plus récents et toujours accessible sur le portail officiel. Elle recommande IPsec comme protocole prioritaire pour les VPN professionnels, aussi bien pour le nomadisme que pour les liaisons entre sites. IKEv2 doit être utilisé comme mécanisme d’échange de clés : IKEv1 est déprécié depuis la RFC 9395 (2023).
WireGuard est-il adapté à un déploiement d'entreprise ?
WireGuard® est adapté à certains contextes d’entreprise, avec des prérequis précis. Son modèle de clés publiques statiques et l’absence de gestion d’identité native le rendent difficile à opérer à grande échelle sans surcouche dédiée,Tailscale, Netbird ou Headscale ajoutent la couche de contrôle manquante. Pour une organisation avec une équipe IT technique et une infrastructure distribuée sur Linux, c’est une option sérieuse. Pour une PME sans ressources techniques internes, IKEv2/IPsec reste plus fiable à long terme.
Quelle est la différence entre un VPN d'accès distant et un VPN site à site ?
Le VPN d’accès distant connecte un utilisateur individuel au réseau de l’entreprise à la demande. Le VPN site à site crée un tunnel permanent entre deux équipements réseau, typiquement les pare-feux de deux sites physiques. Ces deux cas d’usage ne requièrent pas les mêmes protocoles ni les mêmes équipements.
IKEv2 peut-il être bloqué par un pare-feu ?
Faut-il encore maintenir L2TP/IPsec dans une infrastructure en 2026 ?
Qu'est-ce qu'un SSL VPN et en quoi diffère-t-il d'un VPN réseau ?
ISO 27001 impose-t-elle un protocole VPN précis ?
Décision d’architecture, pas de performance
En entreprise, on ne choisit pas le protocole « le plus rapide » en théorie. On choisit celui que l’architecture, les équipements, les politiques de filtrage, le modèle d’identité et les exigences de contrôle peuvent supporter durablement.
Pour les liaisons entre sites, l’axe de référence reste IPsec/IKEv2, recommandé par l’ANSSI, natif dans l’écosystème des équipements professionnels, éprouvé en environnement hétérogène. Pour les flottes mobiles, IKEv2/IPsec garde un avantage opérationnel fort grâce à l’intégration native dans les systèmes d’exploitation et la gestion MOBIKE. Pour les réseaux hostiles où UDP est bloqué, OpenVPN TCP/443 reste le repli réaliste. WireGuard, lui, devient convaincant quand il s’insère dans une couche de gestion cohérente, pas quand on le fantasme comme solution auto-suffisante.
Le bon protocole n’est pas celui qui impressionne sur le papier. C’est celui que votre organisation peut déployer correctement, maintenir dans le temps et défendre dans une revue de sécurité.
Pour aller plus loin
Le choix d’un protocole VPN s’inscrit dans une réflexion d’architecture plus large.
Les entreprises qui sécurisent des accès distants ou des environnements SaaS sont souvent amenées à évaluer des modèles alternatifs, notamment les architectures Zero Trust appliquées au VPN d’entreprise, ou le cadre Zero Trust dans sa définition plus large. Pour les organisations qui s’appuient sur des applications en mode hébergé, les bonnes pratiques SaaS en entreprise posent des questions d’accès et de périmètre que le VPN seul ne résout pas toujours. Le modèle SASE tente précisément de répondre à cette convergence entre réseau et sécurité.