WireGuard vs OpenVPN — ce que le changement de protocole a vraiment modifié

En résumé : OpenVPN fonctionne. Il a été audité, déployé et mis à l'épreuve pendant plus de deux décennies. WireGuard remplit le même rôle — tunnel chiffré et authentifié entre deux points — avec une base de code plus réduite, des primitives cryptographiques modernes et de meilleures performances sur les appareils mobiles. Pour la grande majorité des usages grand public et la plupart des usages entreprise, WireGuard est le meilleur choix technique en 2026. OpenVPN l'emporte encore dans quelques cas précis : les réseaux restrictifs où il faut faire passer le trafic TCP pour du HTTPS, les intégrations PKI basées sur des certificats, et les environnements dont l'historique de conformité n'a pas encore certifié WireGuard. Le reste de cet article développe les détails techniques qui justifient ce résumé.

Ce que chaque protocole est réellement

OpenVPN, publié en 2001 par James Yonan, est un protocole VPN basé sur SSL/TLS. Il s'exécute en espace utilisateur sur la plupart des plateformes. Il utilise la bibliothèque OpenSSL ou mbedTLS pour la cryptographie. Son canal de données peut utiliser n'importe quel chiffrement pris en charge par OpenSSL — AES-256-GCM est la valeur par défaut moderne. Son canal de contrôle utilise TLS, ce qui lui permet de s'appuyer sur l'ensemble de l'écosystème de certificats X.509 pour l'authentification. Il prend en charge UDP (la valeur par défaut, moins de surcharge) et TCP (plus lent, mais traversable par les pare-feux restrictifs). Le modèle de configuration est riche et flexible — on peut configurer les routes, le DNS, l'attribution dynamique d'IP, les politiques push, et des dizaines d'autres paramètres.

WireGuard, conçu par Jason Donenfeld et publié en 2016, est une conception beaucoup plus réduite et plus opiniâtre. Les primitives cryptographiques sont fixes — il n'y a ni négociation, ni liste de suites de chiffrement. Le protocole s'exécute dans l'espace noyau sous Linux, macOS et Windows (et dans une implémentation en espace utilisateur sur iOS). Il ne prend en charge que UDP — pas de repli TCP. L'authentification repose uniquement sur des paires de clés publiques/privées statiques — pas d'écosystème de certificats, pas de nom d'utilisateur/mot de passe, pas de PKI. Le modèle de configuration est minimaliste : une liste de pairs, chacun avec une clé publique et une plage d'IP autorisées. La simplicité est l'objectif.

Cette simplification n'est pas une suppression de fonctionnalités par caprice. C'est un arbitrage délibéré — renoncer à la flexibilité de l'espace de configuration complet d'OpenVPN en échange d'une surface d'attaque bien plus réduite, d'une base de code bien plus petite et de performances nettement supérieures. Le livre blanc original de WireGuard l'affirme explicitement : la conception vise à faire une chose parfaitement, pas à être un couteau suisse.

Taille du code et surface d'audit

C'est la différence la plus citée et la plus sous-estimée. L'implémentation de référence de WireGuard compte environ 4 000 lignes de code. La base de code d'OpenVPN dépasse les 100 000 lignes, plus l'intégralité d'OpenSSL — qui représente lui-même environ 500 000 lignes. La surface d'audit — la quantité de code à examiner pour s'assurer de l'absence de vulnérabilités — diffère de deux ordres de grandeur.

C'est important parce que les vulnérabilités de sécurité réelles dans les protocoles VPN ont historiquement été dues à des bugs d'implémentation, non à des défauts de conception protocolaire. La faille Heartbleed de 2014 dans OpenSSL a touché tous les déploiements OpenVPN. Les attaques Lucky Thirteen et les attaques par oracle de rembourrage CBC ont affecté la couche TLS sur laquelle OpenVPN s'appuie. Ce n'étaient pas des bugs du protocole OpenVPN en tant que tel — c'étaient des vulnérabilités dans les couches sous-jacentes. Un protocole dont l'implémentation compte 4 000 lignes offre nettement moins d'endroits où de tels bugs peuvent se cacher.

Cet avantage n'est pas théorique. Les mainteneurs du noyau Linux — notoirement réticents à intégrer du nouveau code — ont accepté WireGuard dans le noyau principal en 2020, en partie parce que la base de code était suffisamment petite pour être relue de bout en bout. Linus Torvalds l'a publiquement qualifié de « œuvre d'art » en comparaison d'autres implémentations VPN. OpenVPN n'a jamais été intégré au noyau car sa complexité le rend impossible.

Primitives cryptographiques

OpenVPN est agile en matière de chiffrement — on configure les algorithmes de chiffrement, de MAC et d'échange de clés qu'il utilise, en puisant dans ce qu'OpenSSL prend en charge. Les valeurs par défaut modernes sont AES-256-GCM pour les données, SHA-256 pour le HMAC, et RSA ou ECDSA pour l'authentification par certificat. Cette agilité était un atout historiquement — quand un algorithme s'avérait faible, on pouvait en substituer un autre sans modifier le protocole. C'est aussi une vulnérabilité — la plupart des failles TLS de la dernière décennie ont été liées à la logique de négociation (attaques par déclassement, manipulation de suites de chiffrement, poignées de main de repli) plutôt qu'aux primitives elles-mêmes.

WireGuard fixe ses primitives. Il utilise ChaCha20 pour le chiffrement symétrique, Poly1305 pour l'authentification (combinés en ChaCha20-Poly1305 AEAD), Curve25519 pour l'échange de clés Diffie-Hellman sur courbe elliptique, BLAKE2s pour le hachage, et HKDF pour la dérivation de clés. Aucune de ces primitives ne peut être négociée. Si une vulnérabilité est découverte dans l'une d'elles, la version du protocole elle-même est incrémentée — il n'existe pas de chemin de déclassement in-band exploitable par un attaquant. Le choix des primitives est éclairé par la cryptanalyse moderne : ChaCha20 est plus efficace qu'AES sur les appareils sans accélération matérielle AES (la plupart des anciens téléphones ARM), Curve25519 est la courbe elliptique la plus auditée en usage, et BLAKE2s est plus rapide que SHA-256 tout en étant aussi sûr.

La contrepartie : si l'une des primitives choisies par WireGuard est un jour compromise, chaque déploiement devra se mettre à jour de façon synchrone. Avec l'agilité de chiffrement d'OpenVPN, les serveurs individuels peuvent évoluer à leur propre rythme. Le pari de WireGuard est que les primitives choisies sont suffisamment robustes pour que ce besoin ne se présente pas en pratique avant de nombreuses années. C'est ce qui s'est passé jusqu'ici ; la suite dépend d'évolutions en cryptanalyse que personne ne peut prédire.

Modèle de connexion — sans état vs avec état

OpenVPN maintient une session avec état — il y a une poignée de main à la connexion, la connexion persiste, et la déconnexion est un événement délibéré. Le serveur suit l'état par client, notamment les clés de session négociées, les numéros de séquence courants et l'IP virtuelle assignée. Si le serveur redémarre ou si la connexion est interrompue, la session doit être rétablie avec une poignée de main complète.

WireGuard est conceptuellement sans état du point de vue réseau. Chaque pair est identifié par sa clé publique, non par un identifiant de session. Il n'y a pas de « connexion » au sens traditionnel — les paquets entre pairs s'authentifient soit contre la clé publique connue, soit ils ne s'authentifient pas. La rotation des clés a lieu toutes les deux minutes (ou lorsqu'un seuil d'octets configurable est dépassé), mais elle ne nécessite pas de nouvelle poignée de main du point de vue de l'utilisateur. Si un serveur redémarre, le prochain paquet du client déclenche automatiquement une poignée de main ; l'utilisateur ne ressent aucune interruption au-delà du temps aller-retour d'une seule poignée de main.

Ce modèle sans état explique pourquoi WireGuard gère si bien le changement de réseau. Sur un téléphone passant du Wi-Fi au réseau cellulaire, OpenVPN nécessite généralement une nouvelle poignée de main complète (qui prend souvent 5 à 10 secondes et échoue parfois). WireGuard continue simplement de fonctionner — le nouveau paquet depuis la nouvelle IP s'authentifie correctement, le serveur met à jour sa table de correspondance d'endpoint pour cette clé publique, et le tunnel se poursuit. Du point de vue de l'utilisateur, le changement de réseau est invisible.

Performances — les chiffres qui comptent vraiment

Les benchmarks montrent systématiquement que WireGuard surpasse significativement OpenVPN en débit, latence et utilisation CPU. Les chiffres varient selon le matériel et la configuration, mais le schéma général est constant. Sur un laptop moderne classique en Gigabit Ethernet, WireGuard atteint un débit proche de la ligne (900+ Mbps) ; OpenVPN avec AES-256-GCM et un OpenSSL moderne atteint généralement 200 à 400 Mbps en raison des copies en espace utilisateur et de la surcharge du découpage TLS. Sur les téléphones ARM sans accélération matérielle AES, l'avantage de WireGuard est encore plus important — ChaCha20 est bien plus rapide qu'AES logiciel, et l'implémentation dans le noyau évite les changements de contexte.

Les comparaisons de latence sont moins spectaculaires mais favorisent systématiquement WireGuard. Un tunnel WireGuard typique ajoute 1 à 3 ms de surcharge par aller-retour sur un réseau rapide ; OpenVPN ajoute 5 à 15 ms selon le chiffrement et la plateforme. Pour les usages interactifs — jeux, appels vidéo, sessions de terminal — la différence est perceptible. Pour les transferts en masse, c'est secondaire par rapport au débit.

Impact sur la batterie mobile

Sur les smartphones, l'écart de performances se traduit par un écart de consommation batterie. Deux effets se cumulent : WireGuard traite la même quantité de trafic réseau avec moins de cycles CPU (car le protocole est plus simple et la cryptographie est plus rapide sur ARM), et WireGuard génère moins de surcharge réseau par octet utile transmis (moins de paquets keep-alive, encadrement plus léger, pas de nouvelles poignées de main périodiques). Des mesures indépendantes ont régulièrement montré que WireGuard consomme environ 20 à 40 % moins de batterie pour des charges de travail équivalentes sur iOS et Android.

Le comportement de mobilité sans nouvelle poignée de main aide également la batterie. Avec OpenVPN, chaque changement de réseau peut provoquer une série de retransmissions de paquets en échec pendant que le client constate que la connexion est morte et initie une reconnexion — ce comportement de réessai maintient la radio active plus longtemps que nécessaire. WireGuard évite cela entièrement.

Comportement lors du changement de réseau en cours de session

C'est l'amélioration la plus visible pour l'utilisateur qu'apporte WireGuard. Imaginez que vous êtes en appel vidéo avec le VPN connecté, et que votre téléphone bascule du Wi-Fi au réseau cellulaire en quittant votre domicile :

• Avec OpenVPN — le réseau cellulaire attribue une nouvelle IP à votre téléphone. Les paquets sortants du client OpenVPN proviennent désormais de cette nouvelle IP, mais l'état du serveur pour votre session attend des paquets depuis l'ancienne IP Wi-Fi. Les paquets sont rejetés. Après quelques secondes de silence, la logique keep-alive d'OpenVPN détecte la panne et déclenche une reconnexion — poignée de main TLS complète, échange de clés, tout le processus. Votre appel coupe ; vous vous reconnectez.
• Avec WireGuard — le même paquet depuis la nouvelle IP arrive au serveur, s'authentifie contre la clé publique connue et est accepté. Le serveur met à jour de façon transparente sa table de correspondance d'endpoint pour cette clé publique vers la nouvelle IP. La réponse suivante est envoyée à la nouvelle IP. L'appel ne coupe pas. L'utilisateur ne remarque rien.

C'est l'avantage d'expérience utilisateur qui a poussé l'industrie des VPN grand public à adopter WireGuard. Les tickets de support à propos du « VPN qui se coupe quand je passe du Wi-Fi au réseau cellulaire » disparaissent tout simplement une fois qu'un éditeur migre d'OpenVPN vers WireGuard.

Là où OpenVPN garde encore l'avantage

OpenVPN n'est pas mort, et il existe des cas précis où il reste le meilleur choix en 2026 :

Mode TCP pour les réseaux restrictifs

WireGuard ne prend en charge que UDP. Certains réseaux — pare-feux d'entreprise, Wi-Fi d'hôtel, FAI restrictifs dans certains pays — bloquent ou limitent fortement le trafic UDP qui ne passe pas par les ports DNS/QUIC standard. Le mode TCP d'OpenVPN (généralement sur le port 443) peut traverser ces réseaux en faisant ressembler le trafic VPN à du HTTPS ordinaire. WireGuard n'a pas de mode TCP natif ; il faut soit ajouter une couche d'obfuscation par-dessus (Cloak, Shadowsocks, AmneziaWG), soit se rabattre sur OpenVPN.

Authentification par certificat avec PKI existante

OpenVPN s'intègre parfaitement à l'infrastructure de certificats X.509. Les organisations qui disposent déjà d'une PKI à d'autres fins (cartes à puce, S/MIME, TLS interne) peuvent l'étendre à l'authentification VPN sans déployer une nouvelle infrastructure. WireGuard utilise des clés statiques, ce qui est plus simple opérationnellement mais ne s'intègre pas aux workflows PKI. Pour les organisations fortement investies dans une PKI, OpenVPN reste l'option naturelle.

Historique d'audit plus long

OpenVPN est déployé en production depuis plus de deux décennies. Il a été audité à plusieurs reprises par plusieurs cabinets indépendants. L'historique de WireGuard est plus court — huit ans de déploiement en production et un nombre plus limité d'audits formels. Les deux ont un bilan de sécurité exemplaire ; celui d'OpenVPN est simplement plus long. Pour les référentiels de conformité qui exigent un long historique de déploiement (certains contextes FedRAMP, certains contextes FIPS), OpenVPN peut encore être la seule option.

Attribution dynamique d'IP et politiques push plus riches

Le serveur OpenVPN peut attribuer dynamiquement des IP virtuelles, pousser des paramètres DNS, des routes et d'autres configurations aux clients lors de la poignée de main. La configuration de WireGuard est majoritairement statique — les IP autorisées de chaque pair sont configurées à l'avance. Pour les grands déploiements entreprise avec un renouvellement fréquent des endpoints, le modèle dynamique d'OpenVPN est plus simple opérationnellement.

Comparaison propriété par propriété

Pourquoi la plupart des services modernes utilisent WireGuard

Tous les grands VPN grand public — Mullvad, ProtonVPN, NordVPN, IVPN, Surfshark, ExpressVPN, Casper's Cloak — proposent WireGuard, et la plupart en ont fait leur option par défaut. Les raisons sont cohérentes d'un éditeur à l'autre : c'est plus rapide, ça consomme moins de batterie, ça survit aux changements de réseau sans effort, et c'est plus facile à auditer. Le coût du support client baisse car moins de connexions se coupent. Les coûts serveur baissent car chaque serveur peut gérer plus de connexions simultanées (CPU moindre par connexion). L'expérience utilisateur s'améliore de façon mesurable sur mobile.

La transition a également été validée par des adopteurs institutionnels sérieux. Mullvad a publiquement expliqué sa migration complète vers WireGuard et les raisons techniques derrière ce choix. Les services Tailscale et Cloudflare WARP sont construits sur des protocoles dérivés de WireGuard. Linux l'a intégré au noyau. macOS et iOS embarquent un support natif. Il existe un fort consensus dans l'industrie que WireGuard est la bonne base pour les nouveaux déploiements VPN, avec OpenVPN conservé pour les scénarios de compatibilité spécifiques. Pour replacer dans son contexte pourquoi un VPN payant utilisant correctement ces protocoles est important, notre guide VPN gratuit vs payant couvre l'aspect confiance et financement, et notre comparaison ProtonVPN examine les différences d'implémentation entre éditeurs.

Ce que Casper utilise, et pourquoi

Casper's Cloak utilise WireGuard par défaut sur iOS, Android et Mac. Les raisons correspondent directement à la comparaison ci-dessus : la réduction de consommation batterie compte sur les appareils que nos utilisateurs portent réellement ; le changement de réseau sans coupure compte parce que la plupart de nos clients passent d'un réseau à l'autre quotidiennement ; la surface de code réduite s'aligne avec notre modèle de menace (la défense au niveau réseau ne doit pas introduire une surface d'exécution de code supplémentaire) ; et les primitives cryptographiques représentent le meilleur de l'état de l'art moderne.

Nous associons WireGuard à nos propres couches de filtrage et de détection — protection contre les menaces au niveau du résolveur DNS, scoring ML des nouvelles menaces sur les nouveaux domaines, et filtrage des traceurs dans le chemin de réponse. Le tunnel est le transport ; le filtrage actif est ce qui rend la connexion utile au-delà du simple changement d'IP. Pour la référence technique canonique sur WireGuard lui-même, l'article original et la documentation sur wireguard.com/papers restent les meilleures sources primaires.

En conclusion

WireGuard est le bon choix par défaut en 2026 pour les VPN grand public, les déploiements entreprise modernes et la plupart des tunnels cloud-à-cloud. Il est plus rapide, plus économe en batterie, plus facile à auditer et nettement meilleur pour gérer la mobilité réseau mobile. OpenVPN n'est pas déprécié et reste la bonne réponse pour les réseaux restrictifs où le mode TCP est nécessaire, les organisations avec des workflows PKI établis, et les environnements de conformité qui exigent son long historique d'audit.

Pour un utilisateur typique choisissant un VPN grand public : optez pour un éditeur qui propose WireGuard, utilisez-le par défaut, et gardez OpenVPN en repli pour le rare réseau qui ne laisse pas passer le trafic UDP de WireGuard. Les améliorations de performances et de batterie sont réelles, le modèle de sécurité est au moins aussi solide, et l'expérience utilisateur — en particulier sur mobile — est sensiblement meilleure. La transition que l'industrie a déjà opérée est la bonne, et rien n'indique qu'elle s'inversera.