Le choix du protocole détermine directement trois choses concrètes pour un usage professionnel nomade : la stabilité de la connexion en cas de changement de réseau, la vitesse réelle, et la capacité à traverser des réseaux qui filtrent le trafic VPN.
IKEv2/IPsec doit son intérêt pour un usage nomade à l'extension MOBIKE, normalisée par l'IETF dans la RFC 4555. MOBIKE permet de changer de réseau - passer du Wi-Fi d'un espace de coworking à la 4G dans les transports, par exemple - sans que le tunnel ne se coupe ni ne se renégocie entièrement. Pour un indépendant qui travaille en déplacement, c'est un critère technique concret, pas un argument marketing.
WireGuard repose sur un modèle cryptographique fixe (Curve25519, ChaCha20-Poly1305) documenté dans le whitepaper présenté à NDSS 2017 par son auteur Jason A. Donenfeld. Sa base de code, environ dix fois plus réduite que celle d'OpenVPN, en fait un protocole plus simple à auditer. Il gère nativement le changement de réseau avec une reprise de connexion quasi instantanée, comparable en pratique à IKEv2/MOBIKE.
OpenVPN reste pertinent dans un cas précis : traverser un réseau qui filtre activement le trafic VPN (certains réseaux d'entreprise restrictifs, certains pays). Configuré en TCP sur le port 443, son trafic devient difficile à distinguer du HTTPS standard. C'est un avantage de contournement, pas de performance : à sécurité égale, il est structurellement plus lent que WireGuard.
PPTP repose sur MS-CHAPv2, dont les faiblesses cryptographiques sont documentées et connues depuis plus d'une décennie - à un point tel que Microsoft, son propre créateur, en déconseille l'usage. Un fournisseur qui ne propose encore que ce protocole ne devrait plus être considéré pour un usage professionnel. L2TP employé seul, sans couche IPsec pour le chiffrement, n'offre lui-même aucune protection : c'est le tunnel L2TP/IPsec combiné qui compte, jamais L2TP isolé.
La Perfect Forward Secrecy (PFS) garantit qu'une clé de session compromise ne permet pas de déchiffrer les sessions passées ou futures - chaque session négocie sa propre clé éphémère, indépendante des précédentes. C'est une propriété du protocole d'échange de clés (le groupe Diffie-Hellman utilisé par IKEv2, en particulier), pas du chiffrement du contenu lui-même.
Le point souvent négligé : la PFS n'est pas toujours activée par défaut dans une configuration IKEv2, et les groupes Diffie-Hellman inférieurs à 2048 bits sont aujourd'hui considérés comme insuffisants. Un tunnel IKEv2 sans PFS correctement configurée offre une sécurité en apparence identique, mais une exposition bien plus large en cas de compromission ultérieure d'une clé.
En 2024, le NIST américain a finalisé deux standards de cryptographie post-quantique : ML-KEM (FIPS 203) pour l'échange de clés et ML-DSA (FIPS 204) pour les signatures. Pour des données professionnelles à durée de vie longue (contrats, correspondances juridiques, propriété intellectuelle), le scénario dit harvest now, decrypt later est une menace documentée : un adversaire capture aujourd'hui du trafic chiffré dans l'idée de le déchiffrer une fois qu'un ordinateur quantique suffisamment puissant existera.
Cela ne signifie pas qu'il faille paniquer sur un usage VPN quotidien, mais qu'une activité manipulant des données sensibles à horizon de plusieurs années gagne à vérifier si son fournisseur documente une feuille de route vers des mécanismes hybrides (classique + post-quantique).
En full tunnel, tout le trafic de l'appareil transite par le VPN - protection maximale, mais charge réseau plus élevée et parfois ralentissement des applications qui n'ont aucune raison de passer par le tunnel. En split tunnel, seul le trafic que vous désignez emprunte le VPN, le reste sortant directement par votre connexion habituelle.
Le point de vigilance : en split tunnel, les requêtes DNS résolues en dehors du tunnel peuvent révéler les domaines que vous consultez à un observateur réseau, même si le contenu applicatif reste chiffré par ailleurs. Si vous choisissez le split tunneling pour préserver de la bande passante, vérifiez que le client VPN permet au minimum de forcer les requêtes DNS dans le tunnel pour le trafic professionnel sensible.
Un kill switch coupe automatiquement l'accès réseau de l'appareil si le tunnel VPN se déconnecte de façon inattendue, empêchant un retour silencieux à une connexion non chiffrée. Pour un usage nomade - changements de réseau fréquents, Wi-Fi publics instables -, cette fonction n'est pas un confort mais une garantie structurelle : sans elle, une coupure de quelques secondes suffit à exposer du trafic non protégé sans que l'utilisateur s'en aperçoive.
| Protocole | Point fort | Limite |
|---|---|---|
| WireGuard | Code réduit et auditable, très bonnes performances | Pas de suite FIPS native (pas d'AES) |
| IKEv2/IPsec | Continuité de connexion (MOBIKE) en mobilité | Configuration Perfect Forward Secrecy parfois désactivée par défaut |
| OpenVPN | Traverse les réseaux filtrants via TCP 443 | Plus lent, base de code nettement plus large |
| PPTP | Aucun, à éviter | Faiblesses cryptographiques documentées |