Qu’est-ce qu’un VPN d’entreprise ?
Un VPN d’entreprise, Virtual Private Network, est une infrastructure logicielle qui établit des connexions chiffrées entre des terminaux distants et le réseau privé d’une organisation. Il permet à des collaborateurs, des bureaux ou des prestataires d’accéder aux systèmes internes depuis n’importe quelle localisation, sans exposer le trafic aux réseaux publics.
Le mécanisme repose sur un tunnel chiffré : les données sont encapsulées puis transportées jusqu’à une passerelle VPN ou un point de présence, avant d’être acheminées vers la ressource cible. Pour tout observateur extérieur positionné sur le trajet, FAI, opérateur réseau, attaquant sur un point de transit, le contenu du trafic devient illisible et l’origine directe de la connexion est masquée.
Sommaire
- Ce qui distingue un VPN d’entreprise d’un VPN grand public
- Les deux grands types de VPN d’entreprise
- Les familles de protocoles
- Ce qu’un VPN d’entreprise chiffre et ce qu’il ne chiffre pas
- Le split tunneling : tout le trafic dans le VPN ou seulement une partie ?
- Authentification : au-delà du mot de passe ?
- La gestion des adresses IP
- La journalisation et les obligations de conformité
- Haute disponibilité et redondance
- Les limites structurelles du modèle
- Ce que le VPN d’entreprise reste, et ce qu’il n’est plus
Ce qui distingue un VPN d’entreprise d’un VPN grand public
C’est sur ce point que la confusion est la plus fréquente, et la plus coûteuse.
Un VPN grand public est conçu pour un usage individuel : masquer une adresse IP, contourner une restriction géographique, sécuriser une connexion sur un Wi-Fi public. Il distribue des adresses IP partagées entre des milliers d’utilisateurs, sans gestion centralisée, sans contrôle d’accès par rôle, sans traçabilité interne.
Un VPN d’entreprise répond à des impératifs différents. Son objectif n’est pas l’anonymat, c’est la sécurisation de flux entre entités identifiées. Il permet à un administrateur de définir qui accède à quoi, depuis quel appareil, dans quelles conditions, et d’en conserver une trace auditée. Il supporte des dizaines ou des centaines de connexions simultanées. Il s’intègre aux annuaires d’identité (Active Directory, Microsoft Entra ID, Okta) et aux infrastructures hybrides qui mêlent ressources on-premise et cloud. Une part importante des avantages d’un VPN d’entreprise tient à cette capacité de contrôle, de traçabilité et d’administration centralisée.
Les deux grands types de VPN d’entreprise
La notion de VPN d’entreprise recouvre des architectures assez différentes selon le cas d’usage.
Le remote access VPN est le modèle le plus répandu. Un client logiciel installé sur le terminal de l’utilisateur établit une connexion authentifiée vers une passerelle VPN. Ce modèle concerne les salariés en télétravail, les collaborateurs itinérants, les prestataires et consultants externes. Il peut être déployé sur une infrastructure on-premise ou via une infrastructure entièrement hébergée dans le cloud, ce que l’on désigne communément par VPN cloud pour entreprise.
Le site-to-site VPN ne concerne pas des utilisateurs individuels mais des réseaux entiers. Il relie de façon permanente deux sites géographiques distincts, un siège et une filiale, un bureau et un datacenter, un site et une infrastructure cloud. Les deux réseaux communiquent comme s’ils formaient un réseau unique, sans client à installer poste par poste. Le choix entre un déploiement VPN interne ou externalisé engage des arbitrages en termes de maintenance, de coûts et de responsabilité opérationnelle.
Une troisième catégorie mérite d’être mentionnée : les accès SSL/TLS sans client (clientless VPN ou portail SSL), qui permettent d’accéder à certaines applications web internes via un navigateur, sans installation d’agent. Ce mode est plus limité fonctionnellement mais utile pour des accès ponctuels depuis des terminaux non managés.
Les familles de protocoles
Un VPN d’entreprise n’est pas une boîte noire. Le niveau de sécurité, les performances et la compatibilité d’une solution dépendent directement du protocole qu’elle implémente.
IPsec (Internet Protocol Security) est le protocole de référence pour les déploiements site-to-site et de nombreuses implémentations d’accès distant. Il opère au niveau de la couche réseau et s’associe généralement à IKEv2 pour la négociation des clés, ce qui lui confère une bonne stabilité sur les connexions intermittentes.
Les VPN SSL/TLS opèrent au niveau applicatif et traversent plus facilement les pare-feux et les NAT. Ils sont à la base de nombreuses solutions d’accès distant modernes, notamment les portails sans client.
WireGuard® adopte une approche radicalement plus compacte que ses prédécesseurs, environ 4 000 lignes de code contre plus de 70 000 pour OpenVPN, ce qui réduit la surface d’attaque et facilite les audits de sécurité indépendants. On le retrouve dans un nombre croissant de déploiements professionnels, directement ou sous forme dérivée.
OpenVPN reste déployé dans de nombreux environnements existants. Open source, flexible, audité, mais plus consommateur de ressources que WireGuard® et plus complexe à opérer.
L2TP/IPsec, PPTP et SSTP sont des protocoles plus anciens dont l’usage est aujourd’hui fortement déconseillé dans tout déploiement professionnel. PPTP est à écarter sans ambiguïté, il est compromis depuis longtemps. L2TP/IPsec est vieillissant et rarement un choix de référence dans les architectures modernes. SSTP reste propriétaire, avec un écosystème plus étroit.
Ce qu’un VPN d’entreprise chiffre et ce qu’il ne chiffre pas
Un VPN chiffre le trafic entre le terminal de l’utilisateur et la passerelle VPN. Une fois les données sorties du tunnel pour atteindre une application externe, leur protection dépend d’autres mécanismes, principalement TLS. Le VPN ne constitue pas un bouclier sur l’ensemble du trajet.
Pour le trafic interne, la protection couvre le segment entre le terminal et la passerelle VPN, puis selon l’architecture réseau jusqu’à la ressource hébergée sur le réseau de l’organisation. La nature exacte de cette protection au-delà de la passerelle dépend des choix d’implémentation : segmentation, chiffrement applicatif complémentaire, architecture zero trust.
Ce point mérite d’être posé sans ambiguïté : un VPN sécurise un trajet d’accès, pas une ressource. Il ne protège pas automatiquement l’application cible, la base de données, le poste client, ni les droits d’accès excessifs accordés à un compte. Un compte compromis authentifié via le tunnel dispose des mêmes accès que le compte légitime, avec les mêmes risques.
Le split tunneling : tout le trafic dans le VPN ou seulement une partie ?
C’est une question opérationnelle centrale que les définitions génériques occultent systématiquement.
En configuration full tunnel, l’intégralité du trafic réseau du terminal transite par le tunnel VPN, y compris l’accès à des services cloud publics, à des SaaS externes, ou à une simple page web. Cela permet une inspection centralisée du trafic et une meilleure visibilité pour les équipes sécurité, mais génère une charge importante sur les passerelles et dégrade l’expérience utilisateur pour les applications qui n’ont pas besoin de passer par le réseau interne.
En configuration split tunneling, seul le trafic destiné au réseau interne de l’organisation transite par le tunnel. Le reste accède directement à Internet. Les performances sont meilleures, mais cette configuration introduit une surface d’exposition : le trafic externe n’est pas inspecté, et une application compromise sur le terminal peut communiquer librement sans passer par les contrôles de sécurité de l’entreprise.
Le choix entre ces deux modes engage des arbitrages entre performance, exposition au risque, conformité et capacité d’inspection. Dans certains environnements fortement régulés ou très sensibles, le full tunnel est privilégié, parfois combiné à des contrôles de sécurité complémentaires.
Authentification : au-delà du mot de passe
Un déploiement professionnel sérieux ne se limite pas à un identifiant et un mot de passe.
L’authentification multifactorielle (MFA) est incontournable : code TOTP, application d’authentification, clé physique FIDO2. Elle s’appuie sur des protocoles de fédération d’identité comme SAML ou des annuaires accessibles via LDAP, le provisionnement des comptes relevant quant à lui d’une couche séparée, souvent gérée via SCIM.
Dans les environnements plus exigeants, l’authentification repose également sur des certificats numériques, côté utilisateur, côté machine, ou les deux. Un certificat utilisateur lie cryptographiquement une identité à une clé privée stockée sur le terminal. Un certificat machine atteste que l’appareil lui-même est connu et approuvé par l’organisation, indépendamment de l’identité de l’utilisateur qui s’y connecte. Ces mécanismes hybrides, identité + certificat + MFA,constituent le standard dans les environnements à contraintes élevées.
Le contrôle de posture du terminal prolonge cette logique. Avant d’accorder l’accès au tunnel, certaines solutions vérifient que le terminal respecte des conditions définies par la politique de sécurité :
- système d’exploitation à jour
- solution EDR active
- chiffrement du disque activé
- certificat machine présent
Un terminal qui ne satisfait pas ces conditions peut se voir refuser l’accès ou être orienté vers un réseau de remédiation. C’est la frontière entre un VPN d’entreprise basique et un accès conditionnel mature.
La gestion des adresses IP
Dans un VPN d’entreprise, la gestion des adresses IP constitue une question d’architecture à part entière. Les architectures varient selon les besoins :
- certaines solutions attribuent des adresses IP privées dynamiques depuis un pool
- d’autres maintiennent des associations fixes par utilisateur ou par groupe
- d’autres encore attribuent des adresses logiques liées à une politique d’accès, avec des IP dédiées d’entreprise uniquement pour certains usages sortants
Ces choix ont des implications directes sur les règles de pare-feu, les politiques d’accès aux applications métier et la capacité d’audit en cas d’incident.
La journalisation et les obligations de conformité
La journalisation est l’un des points où se joue réellement la maturité d’un déploiement VPN d’entreprise. Une solution professionnelle produit plusieurs catégories de journaux distincts :
- Journaux d’authentification : qui s’est connecté, quand, depuis quelle adresse, avec quel résultat
- Journaux d’allocation d’adresses IP : quelle IP a été attribuée à quel utilisateur à quel moment, essentiel en cas d’incident de sécurité ou d’exigence d’audit
- Journaux d’événements système : tentatives échouées, alertes, anomalies détectées
- Journaux d’accès administrateur : modifications de configuration
- Métadonnées réseau : permettent une corrélation avec d’autres sources (SIEM, EDR) pour la réponse à incident
Dans la pratique, un déploiement professionnel sérieux ne peut pas se passer d’un certain niveau de journalisation, mais cette collecte doit rester justifiée, documentée et proportionnée.
Pour les organisations soumises au RGPD, cela implique notamment :
- l’existence d’une base légale appropriée à leur collecte
- la définition claire de leur finalité
- une politique de conservation proportionnée
- l’identification formelle du fournisseur VPN comme sous-traitant au sens de l’article 28
- des mesures de sécurité et de minimisation adaptées
Une journalisation mal documentée peut constituer un manquement autant qu’une absence de journalisation.
Haute disponibilité et redondance
Un VPN d’entreprise déployé sur une passerelle unique constitue un point de défaillance unique. Si cette passerelle tombe, panne matérielle, saturation, attaque par déni de service, l’ensemble des accès distants est interrompu. Dans un contexte de télétravail généralisé ou d’interconnexion permanente entre sites, cette interruption peut paralyser l’activité.
Les déploiements sérieux intègrent une redondance des passerelles, plusieurs points de présence capables de prendre le relais en cas de défaillance, et des mécanismes de bascule automatique. La capacité à absorber les pics de connexion simultanées sans dégradation est un paramètre de dimensionnement critique, qui pèse directement sur les coûts d’exploitation et, par extension, sur le prix d’un VPN d’entreprise.
Les limites structurelles du modèle
Le VPN d’entreprise est un outil éprouvé, mais ses limites doivent être comprises clairement pour éviter de lui attribuer une protection qu’il ne fournit pas.
La latence s’ajoute mécaniquement au trajet réseau : encapsulation, chiffrement, déchiffrement, saut via la passerelle. Pour des applications à faible tolérance à la latence, cet overhead peut être perceptible, en particulier si la passerelle est géographiquement éloignée de l’utilisateur ou de la ressource.
La surface d’exposition en cas de compromission de compte est la limite la plus sérieuse. Le modèle VPN traditionnel suppose implicitement que tout ce qui franchit la passerelle est légitime. Un attaquant en possession d’identifiants valides, ou d’un certificat volé, accède au réseau avec les mêmes droits que l’utilisateur légitime. C’est cette hypothèse qui est remise en question par les architectures ZTNA, qui vérifient en continu l’identité, l’état du terminal et le contexte de chaque requête d’accès.
La dépendance à un périmètre réseau fixe est le problème de fond. Le VPN d’entreprise a été conçu à une époque où applications et données résidaient dans des datacenters on-premise, derrière un périmètre réseau bien délimité. Avec la migration vers le cloud et la dispersion des ressources chez des fournisseurs tiers, ce périmètre a disparu. Sécuriser l’accès au réseau interne ne suffit plus quand la majorité des applications métier sont hébergées en dehors de ce réseau.
Ce que le VPN d’entreprise reste, et ce qu’il n’est plus
Le VPN d’entreprise n’est pas une technologie dépassée. Pour une organisation qui doit sécuriser l’accès distant de ses collaborateurs à des ressources internes, interconnecter deux sites, ou contrôler les flux entre un réseau local et une infrastructure cloud, il reste une réponse solide, éprouvée et proportionnée.
Ce qu’on ne peut plus lui demander, en revanche, c’est de constituer à lui seul le périmètre de sécurité d’une organisation. Il sécurise un trajet, pas une posture. Il contrôle un accès réseau, pas la légitimité de chaque action réalisée une fois ce réseau atteint. Dans les environnements où la surface d’exposition est large, où les ressources sont dispersées dans le cloud, ou où la compromission d’un compte représente un risque critique, il doit s’inscrire dans une architecture plus large, et non plus en être le pilier unique.