WireGuard vs OpenVPN vs IKEv2 : une vraie comparaison

Ouvrez presque n’importe quelle appli VPN et l’écran qui décide vraiment de son comportement est enfoui dans les réglages : le sélecteur de protocole. WireGuard vs OpenVPN vs IKEv2 n’est pas un choix marketing.

Cela change la vitesse du tunnel, la batterie qu’il vous coûte, la rapidité avec laquelle il récupère quand votre téléphone passe du Wi-Fi au réseau cellulaire, et la quantité de code qui se trouve entre votre trafic et le réseau.

Voici un regard posé, d’ingénieur de terrain, sur les trois protocoles que vous verrez dans les applis VPN pour iPhone et Mac en 2026. Pas d’alarmisme, pas de classements issus d’une page d’affiliation. Juste ce que chacun est réellement, ce qu’il fait bien, ce qu’il fait mal, et lequel tend à être le bon choix par défaut pour un usage mobile moderne.

Pourquoi le choix du protocole compte

Un protocole VPN est l’ensemble de règles que deux ordinateurs utilisent pour établir un tunnel chiffré, puis y faire transiter des paquets. Le protocole décide de la façon dont les clés sont échangées, du chiffrement qui protège les données, de la manière dont la connexion survit à un changement de réseau, et du coût de calcul de chaque paquet.

Cela paraît abstrait jusqu’à ce qu’on en remarque les conséquences. Un handshake plus lourd signifie une première connexion plus lente. Une base de code plus volumineuse signifie une surface plus large pour les failles de sécurité. Un protocole incapable de reprendre d’un réseau à l’autre va couper le tunnel chaque fois que vous quittez le Wi-Fi du café. Un protocole qui s’exécute dans le noyau consommera moins de batterie qu’un protocole qui s’exécute en espace utilisateur.

Ainsi, quand on demande quel VPN est le « plus rapide » ou le « plus sûr », on pose en général une question de protocole sans le savoir. Voici la réponse honnête.

WireGuard

WireGuard est le plus récent des trois et celui qui a le plus changé la façon dont on construit un VPN moderne. Il a été conçu délibérément petit.

L’implémentation de référence compte environ 4 000 lignes de code. OpenVPN, en comparaison, en compte des dizaines de milliers une fois ses dépendances OpenSSL incluses. Le nombre de lignes de code n’est pas une garantie de sécurité, mais c’est une estimation de la surface d’audit. Une petite base de code peut être examinée de bout en bout par une équipe compétente en un temps raisonnable. Une base tentaculaire ne le peut pratiquement pas.

WireGuard choisit aussi ses primitives au lieu de les négocier. Il y a un seul chiffrement (ChaCha20-Poly1305), un seul échange de clés (Curve25519), un seul hachage (BLAKE2s). Pas de menu de suites cryptographiques, pas d’attaques par rétrogradation à craindre. Si le protocole doit un jour changer une primitive, le numéro de version change et les anciens clients cessent de se connecter. C’est inhabituel, et c’est délibéré.

Le handshake est sans état du point de vue du serveur : le serveur n’a pas besoin de mémoriser l’adresse réseau actuelle d’un client pour maintenir son tunnel actif. C’est ce qui rend WireGuard rapide quand vous passez d’un réseau à l’autre. Le téléphone bascule du Wi-Fi à la 4G, envoie un paquet depuis une nouvelle IP, et le tunnel continue de fonctionner. Il n’y a pas d’étape de renégociation.

Il y a une critique honnête de WireGuard qui mérite d’être nommée. Par défaut, un pair conserve la même IP interne d’une session à l’autre, car le serveur identifie les clients par clé publique plutôt que par un bail propre à chaque session. C’est très bien pour un réseau d’entreprise. Pour un produit de confidentialité, le fournisseur doit le gérer délibérément : faire tourner les IP internes, limiter la durée de vie des pairs, s’assurer que les journaux ne transforment pas cette adresse fixe en identifiant durable. Le protocole vous donne les briques de base ; au fournisseur de les utiliser correctement.

WireGuard fonctionne uniquement en UDP. C’est un choix de conception délibéré et c’est aussi son plus gros inconvénient pratique. Sur un réseau qui bloque l’UDP ou n’autorise que le trafic sur le port TCP 443 (certains Wi-Fi d’hôtel, certains réseaux invités d’entreprise, certains environnements de censure), WireGuard ne se connectera tout simplement pas. Il n’y a pas de repli intégré sur TCP.

L’autre point à connaître, c’est que WireGuard fait partie du noyau Linux principal. Cela signifie que, sur les serveurs Linux, le chemin des données va à la vitesse du noyau, sans copie en espace utilisateur. Sous iOS et macOS, l’implémentation s’exécute dans un processus Network Extension géré par le système, ce qui est l’équivalent le plus proche sur une plateforme qui n’autorise pas les extensions de noyau tierces. Il s’agit toujours d’un processus en espace utilisateur dans un bac à sable, mais le framework réseau d’Apple lui transmet les paquets efficacement et la surcharge est faible en pratique.

OpenVPN

OpenVPN est le plus ancien des trois. Il est déployé et corrigé en production depuis 2001, ce qui signifie que presque tous les modes de défaillance imaginables ont déjà été rencontrés, signalés et corrigés sur le réseau de quelqu’un. C’est une vraie valeur.

Il prend en charge l’UDP comme le TCP. L’UDP offre de meilleures performances dans des conditions normales. Le TCP, généralement sur le port 443, permet au tunnel de se faire passer pour du trafic HTTPS ordinaire. Sur les réseaux restrictifs, c’est parfois le seul moyen d’établir une connexion. Si vous vous êtes déjà connecté depuis le Wi-Fi d’une conférence qui bloque tout sauf la navigation web, vous avez probablement apprécié le repli TCP/443.

La cryptographie est fournie par OpenSSL. C’est souple, bien compris, et cela offre aux opérateurs un large menu de chiffrements. C’est aussi une surface d’attaque nettement plus grande que les primitives verrouillées de WireGuard. Heartbleed, en 2014, en est l’exemple type : une faille dans une bibliothèque largement déployée qui a discrètement affecté tous les produits en dépendant, y compris les déploiements OpenVPN utilisant des versions vulnérables d’OpenSSL. Les correctifs arrivent toujours. Le point, c’est que la surface est plus large que ce qu’expose WireGuard.

Le constat sur les performances est honnête : le handshake d’OpenVPN est plus lourd (il effectue une négociation complète de type TLS), et sa surcharge par paquet est plus élevée. Sur une connexion rapide, vous mesurerez la différence. Sur une connexion lente, vous ne la remarquerez peut-être pas. La consommation de batterie sur mobile est également plus élevée, car davantage de travail se fait en espace utilisateur.

La place d’OpenVPN aujourd’hui n’est pas « le plus rapide » ni « le plus léger ». C’est « le plus compatible ». Sur un réseau qui interfère activement avec le trafic VPN, OpenVPN sur TCP/443 passe encore là où WireGuard ne le peut pas. Le prix de cette compatibilité est l’effondrement TCP-sur-TCP : quand la couche TCP externe retransmet parce que la couche TCP interne a déjà retransmis, le débit peut s’effondrer sur un lien instable. C’est la bonne issue de secours, pas le bon tunnel du quotidien.

IKEv2 / IPsec

IKEv2 (Internet Key Exchange version 2) est la moitié « échange de clés » d’un tunnel IPsec. Sur les plateformes Apple, c’est le protocole que le système d’exploitation comprend nativement. Vous pouvez configurer un profil IKEv2 dans les Réglages d’iOS sans installer la moindre appli tierce. C’est un véritable avantage quand vous ne voulez pas de logiciel supplémentaire dans la boucle.

L’atout maître d’IKEv2 sur mobile est MOBIKE — une petite extension qui permet au tunnel de survivre à un changement d’adresse IP sans renégocier. Quand vous passez du Wi-Fi au réseau cellulaire, MOBIKE dit au serveur « c’est toujours moi, simplement sur une nouvelle adresse », et la session continue. Le temps de reconnexion est pratiquement nul pour l’utilisateur.

Sous le capot, le plan de données est IPsec, qui sur les plateformes Apple est implémenté dans le noyau. Cela signifie un bon débit et un faible coût processeur — comparable à WireGuard dans bien des cas, même si la plupart des bancs d’essai indépendants placent toujours WireGuard devant.

Le bémol, c’est la complexité de configuration. IPsec comporte beaucoup de réglages (algorithmes de chiffrement, authentification, confidentialité persistante, durées de vie IKE, intervalles de renouvellement de clé), et la mauvaise combinaison peut laisser un tunnel qui fonctionne mais qui est plus faible qu’il n’y paraît. Le protocole, lui, va bien. Le risque de mauvaise configuration est réel.

IKEv2 est aussi une cible moins intéressante pour l’écosystème open source que WireGuard, ce qui fait que l’innovation côté client a ralenti par rapport à WireGuard. Le protocole lui-même est stable et mature, peu susceptible de vous surprendre dans un sens ou dans l’autre. Le revers de la médaille : vous héritez de ce que le système d’exploitation vous donne, y compris son interface pour le kill switch et les règles à la demande, qui tend à être plus limitée que ce qu’un client dédié peut offrir.

Tableau comparatif

Quelques remarques pour lire ce tableau honnêtement. « La plus rapide » est réel mais limité. Sur une connexion domestique typique, vous n’allez pas remarquer 50 Mbit/s de différence. Les bancs d’essai tiers varient beaucoup selon le matériel, la distance et la façon dont le test est mené, mais l’ordre relatif entre les trois protocoles est constant depuis des années. « Meilleure batterie » est réel et vous le remarquerez sur une connexion de longue durée. « La taille du code » est un argument de surface d’audit, pas un décompte de vulnérabilités.

Reconnexions sur un téléphone, en pratique

La dimension où ces protocoles diffèrent le plus sur un téléphone est ce qui se passe quand votre réseau change. Sortir d’un bureau, monter dans un train, basculer d’un Wi-Fi à portail captif vers la 4G parce que la page du portail ne s’est jamais chargée : un VPN mobile passe une part réelle de sa vie à gérer ces transitions.

WireGuard les gère de façon quasi invisible. Comme le serveur est sans état vis-à-vis de l’adresse d’un client, le téléphone envoie simplement un paquet depuis sa nouvelle IP et le tunnel continue. IKEv2 avec MOBIKE se comporte de manière similaire par conception : la même association de sécurité migre vers la nouvelle adresse. Le temps de reconnexion des deux est pratiquement nul.

OpenVPN gère les changements de réseau le moins bien des trois. Le comportement par défaut consiste à détecter que le lien a changé, à démonter le tunnel et à le reconstruire de zéro — un handshake complet de type TLS. C’est perceptible sur un téléphone, en général une seconde ou deux, et parfois plus si la première tentative échoue. Les clients OpenVPN modernes masquent cela avec une logique de reconnexion, mais le protocole sous-jacent est le plus lent à récupérer.

Avis honnête

Pour un VPN mobile moderne, WireGuard est le bon choix par défaut. La cryptographie est moderne et non négociable, la base de code est assez petite pour être réellement examinée, le handshake est rapide, le coût en batterie est faible, et les reconnexions entre réseaux sont nettes. Ce n’est pas un effet de mode. C’est ce vers quoi toutes les équipes VPN mobiles sérieuses ont convergé au cours des cinq dernières années.

OpenVPN garde un véritable cas d’usage : le repli TCP/443 sur les réseaux restrictifs. Si votre travail vous place parfois sur un réseau qui bloque tout sauf le trafic web, avoir un client OpenVPN sous la main est vraiment utile. Pour un usage grand public au quotidien sur un téléphone, c’est le mauvais choix par défaut.

IKEv2 est un choix tout à fait raisonnable si vous voulez un profil VPN sans installer d’appli. La configuration native d’iOS est solide et les reconnexions sont nettes. Le compromis, c’est que vous perdez les fonctionnalités qu’un vrai client vous offre — des journaux de connexion lisibles, une interface de kill switch claire, un sélecteur de serveur, une bascule rapide. Les profils natifs sont parfaits pour une config d’entreprise toujours active et un peu décevants pour un usage personnel.

Un protocole ne résout pas le reste de la question de la confidentialité. Le fournisseur doit toujours être honnête sur ce que signifie vraiment une politique sans journaux, l’appli doit toujours gérer les clés correctement, et un VPN ne peut empêcher votre système d’exploitation ou votre navigateur de divulguer des informations vous concernant à des tiers. Le protocole est une partie de la réponse, pas toute la réponse.

En résumé

Si vous choisissez un protocole VPN en 2026 et que votre priorité est un tunnel iPhone fonctionnel qui se connecte vite, ménage la batterie et survit au trajet en train du Wi-Fi à la 4G — choisissez WireGuard. Si vous devez régulièrement vous connecter depuis des réseaux qui vous mettent des bâtons dans les roues, gardez OpenVPN en secours. Si vous voulez un profil natif sans appli installée, IKEv2 est la bonne réponse.

Snap VPN est exclusivement WireGuard. Nous avons fait ce choix parce qu’une fois les protocoles réellement comparés sur les dimensions qui comptent sur un téléphone (vitesse, batterie, reconnexion, auditabilité), il n’y a aucun argument honnête pour proposer les autres par défaut. Ajouter des protocoles supplémentaires signifierait plus de code dans le tunnel, plus de menus de chiffrement, plus de configuration à rater, et un choix par défaut plus lent pour des utilisateurs qui n’auraient de toute façon jamais touché au sélecteur de protocole. Nous préférons bien faire une seule chose.

WireGuard vs OpenVPN n’est pas vraiment le débat intéressant sur un iPhone moderne. WireGuard a remporté cette comparaison sur le plan technique il y a quelques années. La question intéressante est de savoir si le reste du produit autour du protocole est construit avec la même retenue : identité anonyme, aucun journal de trafic, un kill switch qui fonctionne réellement, une base de code cliente réduite.

Si vous voulez voir WireGuard se comporter comme il le devrait sous iOS, Snap est dès maintenant sur l’App Store, et macOS arrive ensuite. Pas d’inscription par e-mail. Aucun journal de trafic. Aucun identifiant lié à une personne réelle. Anonyme par conception, sur le protocole qui a gagné sa place par défaut.