Schéma VPN - Comment bien lire et comprendre son fonctionnement ?

Comment lire un schéma VPN sans se perdre

Je commence toujours par repérer quatre éléments: le poste utilisateur, la passerelle VPN, le tunnel chiffré et la ressource finale. Les flèches sont utiles, mais elles ne racontent pas toute l’histoire: il faut aussi voir où le trafic entre, où il est chiffré, où il est déchiffré et à quel moment il ressort vers Internet ou vers le réseau interne.

• Client VPN: l’application ou le composant système installé sur l’ordinateur, le smartphone ou le routeur.
• Passerelle VPN: le point d’entrée ou de sortie du tunnel, souvent un firewall, un concentrateur ou un appliance dédié.
• Tunnel: la partie logique du trajet où les paquets sont encapsulés et chiffrés.
• Destination: un site web, un serveur d’entreprise, un ERP, un dépôt de fichiers ou une application métier.
• Politique de routage: la règle qui dit quels flux passent dans le tunnel et lesquels sortent directement.

Quand un schéma ne montre qu’un simple trait entre deux boîtes, il est souvent trop vague pour être vraiment exploitable. Un bon dessin précise au minimum les extrémités du tunnel et le périmètre protégé, ce qui évite les mauvaises interprétations dès la phase de design. C’est justement ce périmètre qu’il faut détailler ensuite.

Les composants qu’un schéma VPN doit faire apparaître

Un schéma utile n’est pas seulement esthétique. Il doit m’aider à comprendre comment la session démarre, où l’identité est vérifiée et quels équipements participent réellement à la sécurité. En 2026, les déploiements sérieux s’appuient encore sur quelques briques très classiques, même si leur mise en œuvre a beaucoup évolué.

• L’authentification avec mot de passe, certificat, MFA ou annuaire d’entreprise. Sans elle, le tunnel n’est qu’un tuyau fermé, pas un accès contrôlé.
• Le protocole VPN, par exemple IPsec, SSL/TLS ou WireGuard. Il définit la manière dont les paquets sont encapsulés, chiffrés et vérifiés.
• Les clés et certificats, qui prouvent l’identité des deux extrémités et servent au chiffrement.
• Le routage, qui décide si tout le trafic passe par le VPN ou seulement certains sous-réseaux.
• Le DNS, souvent oublié, alors qu’il influence la résolution des noms et peut révéler des fuites si la politique est mal définie.

Le point que beaucoup sous-estiment, surtout en PME, c’est le routage. Une passerelle bien sécurisée ne suffit pas si les flux internes, les exceptions de sécurité ou les règles DNS sont incohérents. C’est là que le schéma devient un outil de validation, pas seulement de présentation. Une fois ces blocs repérés, on peut suivre le trajet d’un paquet.

Le trajet d’un paquet de données de bout en bout

1. L’application génère une requête, par exemple l’ouverture d’un fichier sur un serveur distant.
2. Le client VPN encapsule le paquet d’origine dans un autre paquet destiné à la passerelle.
3. Le contenu est chiffré avant de quitter le poste utilisateur.
4. Le trafic traverse Internet en n’exposant que les extrémités du tunnel, pas le contenu interne.
5. La passerelle VPN déchiffre le flux, vérifie l’identité et remet les données vers la ressource cible.
6. La réponse revient par le même principe, en sens inverse, jusqu’au poste utilisateur.

Deux précisions comptent beaucoup. D’abord, le chiffrement protège surtout la portion entre l’appareil et la passerelle VPN. Ensuite, une fois sorti du tunnel, le trafic suit les règles classiques du réseau de destination, donc il peut encore dépendre du HTTPS, de la politique de journalisation et de la sécurité du serveur final. Une fois le flux compris, il devient plus simple de comparer les architectures.

Les schémas les plus courants dans les réseaux d’entreprise

Dans les documents d’architecture, on rencontre surtout trois variantes. Elles répondent à des besoins différents et il ne faut pas les confondre, sinon on finit avec un schéma séduisant mais inadapté. Pour une PME française, la distinction entre télétravail, interconnexion de sites et accès applicatif ciblé change vite la manière de concevoir le réseau.

Le schéma le plus lisible dépend donc du besoin réel. Une liaison entre un siège à Paris et une agence à Lyon se dessine différemment d’un simple accès nomade vers un ERP. C’est aussi pour cela qu’un dessin générique est souvent insuffisant: il faut choisir le modèle qui reflète l’usage métier. Reste alors à voir ce que ces dessins ne disent pas toujours.

Ce que le schéma ne montre pas toujours

• Le split tunneling: une partie des flux passe par le VPN, une autre sort directement vers Internet. C’est pratique, mais cela mérite une vraie décision de sécurité.
• Le DNS: si les requêtes ne suivent pas la même route que le trafic applicatif, on peut créer des fuites ou des comportements incohérents.
• La visibilité du fournisseur: un VPN ne supprime pas la confiance accordée à la passerelle ou au prestataire. Il déplace le point de confiance.
• La performance: latence, bande passante et charge de la passerelle influencent le ressenti, même si le schéma reste impeccable.
• La journalisation: certains environnements gardent des logs détaillés; d’autres en conservent beaucoup moins. Cela a des conséquences opérationnelles et parfois juridiques.

Le point le plus mal compris, à mon sens, c’est l’idée qu’un VPN protège tout de la même manière. En réalité, il sécurise surtout un trajet et un périmètre définis. Si ce périmètre est flou, le schéma rassure plus qu’il n’éclaire. C’est là que les erreurs de lecture deviennent fréquentes.

Les erreurs de lecture que je vois le plus souvent

Quand j’analyse un schéma VPN, je retrouve souvent les mêmes raccourcis. Ils ne sont pas forcément graves à première vue, mais ils finissent par créer des incidents, des attentes irréalistes ou des choix techniques bancals.

• Confondre tunnel et anonymat: le VPN chiffre le trafic, mais il ne rend pas l’utilisateur invisible.
• Oublier le chemin retour: un schéma ne vaut rien s’il ne montre que la requête sortante.
• Ne pas distinguer client et passerelle: les responsabilités techniques ne sont pas les mêmes.
• Ignorer les flux DNS: ils peuvent contourner la logique attendue et créer une fuite d’informations.
• Mélanger accès distant et site-à-site: ces deux modèles n’ont ni les mêmes contraintes ni le même niveau de granularité.
• Négliger la redondance: sans passerelle de secours, le schéma peut être beau et pourtant fragile.

En pratique, je conseille de relire chaque schéma avec une seule question en tête: “si cette passerelle tombe, que se passe-t-il exactement ?”. Cette question force à vérifier la haute disponibilité, le basculement et les points de défaillance cachés. Une fois ce filtre appliqué, le dernier tri devient plus simple.

Ce qu’un bon schéma VPN doit faire comprendre en une minute

Un schéma vraiment utile doit répondre immédiatement à trois questions: qui se connecte, vers quoi, et par quel chemin. S’il faut dix minutes pour comprendre ces trois points, le dessin n’est pas encore assez bon.

• La frontière de confiance: où commence et où s’arrête le tunnel.
• La politique de routage: quels flux passent par le VPN et lesquels restent en accès direct.
• La dépendance opérationnelle: ce qu’il faut surveiller, sauvegarder ou redonder pour garder le service disponible.

Quand ces éléments sont lisibles, le schéma sert vraiment à concevoir, expliquer et sécuriser un accès réseau. C’est cette clarté qui fait la différence entre un dessin décoratif et un outil d’architecture exploitable au quotidien.