WireGuard vs OpenVPN sur VPS : débit, latence et compatibilité comparés (2026)

Tu hésites entre WireGuard et OpenVPN pour ton VPN self-host. Tu as lu partout que "WireGuard est plus rapide" sans trop d'explication sur le pourquoi, ni sur les cas où OpenVPN reste le bon choix. Ce guide compare les deux protocoles honnêtement, sur ce qui compte vraiment pour un VPN self-host sur VPS : débit, latence, coût CPU, modèle de sécurité et compatibilité - avec un verdict par cas d'usage.

Version courte : WireGuard gagne généralement sur la performance brute et la simplicité, mais OpenVPN garde un avantage légitime, parfois décisif, dans deux situations précises.

WireGuard est-il plus rapide qu'OpenVPN sur un VPS ?

Généralement oui. WireGuard tourne dans le kernel Linux, utilise une seule suite cryptographique moderne et ajoute très peu d'overhead par paquet : sur un lien VPS rapide, il délivre donc un débit proche de la ligne brute tout en consommant une fraction du CPU. OpenVPN tourne en démon userland : chaque paquet traverse la frontière kernel/userland pour le chiffrement, ce qui coûte du CPU et du débit - surtout sur du matériel peu puissant. OpenVPN reconnecte aussi plus lentement aux changements de réseau, là où le design stateless de WireGuard reprend quasi instantanément.

Réponse directe

WireGuard vs OpenVPN sur un VPS 1 Gbps - comparaison qualitative :

Verdict : WireGuard pour la performance et la simplicité sur tout VPS moderne. OpenVPN quand tu as besoin du bypass TCP/443 (pare-feux corporate/hôtel) ou de supporter du matériel legacy (routeurs DD-WRT, OpenWRT <21, OS clients très anciens).

Ce comparatif s'appuie sur les caractéristiques publiques et documentées des deux protocoles, et non sur un test privé unique. Notre méthodologie →

Pourquoi WireGuard est généralement plus rapide

L'écart de performance n'est pas du marketing : il découle directement de la conception de chaque protocole.

WireGuard tourne en espace noyau. Il se présente comme un module kernel (wireguard.ko), intégré au kernel Linux mainline depuis la 5.6 (mars 2020). Les paquets sont chiffrés et routés sans quitter le kernel, ce qui évite les coûteux context-switches user/kernel qui dominent le coût d'OpenVPN sur les liens chargés.

WireGuard est petit et figé. Environ 4 000 lignes de C, avec une seule suite crypto moderne (Curve25519, ChaCha20-Poly1305, BLAKE2s). Rien à régler et aucun overhead de négociation - tu obtiens le même chemin rapide à chaque fois.

OpenVPN tourne en userland au-dessus de TLS. C'est un démon qui utilise OpenSSL ; chaque paquet fait un aller-retour kernel → userland → kernel pour le chiffrement. C'est flexible (il sait presque tout faire) mais ça coûte du CPU et du débit, et l'effet est bien plus marqué sur du matériel faible sans accélération AES.

L'overhead protocolaire lui-même reste faible pour les deux. Un header VPN plus le framing UDP/IP grignote quelques pour cent de n'importe quel lien quel que soit le protocole - cette part-là est de l'arithmétique, pas une inefficacité.

Latence et jitter

WireGuard ajoute généralement moins de latence aller-retour qu'OpenVPN, et OpenVPN en TCP est le pire cas : faire passer du TCP dans un tunnel TCP ("TCP-over-TCP") provoque des retransmissions en cascade dès que le lien sous-jacent perd un paquet, ce qui fait grimper latence et jitter. Sur un lien filaire propre c'est tolérable ; sur du Wi-Fi ou de la 4G avec du loss, ça se dégrade nettement.

Pour un usage quotidien - navigation, streaming 4K, visio - l'overhead de WireGuard est imperceptible, et OpenVPN en UDP reste fluide aussi. Le cas à éviter pour un usage sensible à la latence (gaming compétitif, VoIP exigeante) est OpenVPN en TCP, sauf si tu en as spécifiquement besoin pour passer un pare-feu.

Consommation CPU

Parce qu'il tourne dans le kernel, WireGuard consomme nettement moins de CPU par mégabit qu'OpenVPN, qui dépense des cycles à faire transiter chaque paquet entre userland et kernel. Sur un VPS multi-cœurs ça compte rarement pour un tunnel perso. Ça compte énormément sur du matériel ARM faible (ex. un Raspberry Pi sans AES-NI), où OpenVPN peut saturer un cœur bien avant de remplir le lien tandis que WireGuard reste à l'aise - laissant du CPU pour ce que la machine fait par ailleurs (un gestionnaire de mots de passe, un petit cloud, de l'analytics).

Sur du matériel avec accélération AES (la plupart des x86 modernes, Apple Silicon), l'AES-256-GCM d'OpenVPN est accéléré matériellement et l'écart CPU se réduit ; sans accélération, ChaCha20 est le meilleur choix de chiffre côté OpenVPN. Le ChaCha20-Poly1305 de WireGuard est rapide dans les deux cas.

Stabilité et roaming mobile

WireGuard est stateless par design : pas de "connexion" à établir, juste des peers connus. Quand un client passe du Wi-Fi à la data mobile et revient, le tunnel reprend quasi instantanément sans renégociation. OpenVPN doit refaire un handshake TLS à chaque changement de réseau, ce qui prend quelques secondes. Pour un téléphone qui switche de réseau toute la journée, le comportement de roaming de WireGuard est un avantage réel et tangible.

Une allée de datacenter : un VPN self-host tourne sur un seul VPS dans une installation de ce type - le choix du protocole détermine surtout l'efficacité avec laquelle ce serveur fait transiter ton trafic.

Analyse sécurité

Le débat sécurité est souvent biaisé par "OpenVPN existe depuis 20 ans donc c'est plus mûr". Regardons les faits :

WireGuard :

• Primitives crypto modernes et figées : Curve25519 (échange de clés), ChaCha20-Poly1305 (AEAD), BLAKE2s (hash), SipHash24 (table de hash).
• ~4 000 lignes de C dans le module kernel - une surface d'attaque petite et auditable.
• Audit formel par Cure53 publié en 2018 - aucune vulnérabilité critique trouvée. Une revue distincte de Trail of Bits (2020) a porté sur l'implémentation macOS.
• Inclus dans le kernel Linux mainline depuis la 5.6 (mars 2020), revu par la communauté netdev.
• Pas de configuration crypto possible par design : impossible de choisir une option faible par erreur.

OpenVPN :

• Primitives configurables : le défaut moderne est AES-256-GCM, mais une config négligente copiée d'un vieux tutoriel pourrait encore sélectionner quelque chose de faible.
• ~70 000 lignes de C plus OpenSSL en grosse dépendance - une surface bien plus large à analyser.
• Audits OSTIF en 2017 et 2018 - quelques bugs trouvés et corrigés, aucun RCE critique.
• Historiquement exposé aux failles d'OpenSSL (Heartbleed en 2014 a touché les déploiements utilisant OpenSSL).

Verdict honnête : les deux sont solides en 2026. WireGuard a un avantage architectural (surface d'attaque réduite, primitives modernes, pas de pièges de config). OpenVPN a un avantage de maturité (deux décennies en production, largement audité, base de déploiement énorme). Pour un self-host, WireGuard est le défaut facile - le rapport simplicité/sécurité est excellent.

Débit par plateforme client

Parmi les plateformes desktop à support WireGuard natif (Linux, macOS, Windows), le débit soutenu est globalement similaire, les kernels récents et le driver natif Windows moderne ayant comblé l'essentiel de l'écart historique. Là où tu verras une vraie différence, c'est sur téléphone : en transfert soutenu à pleine vitesse, les mobiles throttlent pour des raisons thermiques et de batterie et n'égalent pas un desktop. C'est un comportement mobile attendu, sans incidence pour un usage normal (navigation, streaming) - ça n'apparaît que si tu pousses un téléphone avec iperf3 ou un gros backup.

Pour mesurer ton propre setup plutôt que de te fier aux chiffres de qui que ce soit, les commandes de test reproductibles sont en fin d'article.

Quand OpenVPN reste pertinent en 2026

Le marketing WireGuard est tellement dominant qu'on en oublie qu'OpenVPN a encore des cas d'usage solides. Voici les situations où il reste le bon outil.

Cas 1 : bypass firewall corporate / hôtelier

Beaucoup de pare-feu d'entreprise (Fortinet, Palo Alto, Check Point) bloquent l'UDP sortant non-DNS. Tu peux tomber dessus sur le Wi-Fi d'un client, dans certains hôtels, ou sur certains hotspots de transport. WireGuard étant UDP-only, le tunnel échoue silencieusement (le handshake n'aboutit pas). Tu peux encapsuler WireGuard avec wstunnel ou Cloak pour le porter en TCP/443, mais c'est une couche supplémentaire à maintenir.

OpenVPN supporte nativement le mode TCP sur port 443, avec un handshake TLS qui ressemble à du trafic HTTPS ordinaire : il passe donc à travers beaucoup de DPI simples. Pour un usage "VPN de secours quand je suis sur du Wi-Fi corporate non-friendly", garder un profil OpenVPN TCP/443 prêt est pragmatique.

Setup minimal sur le même VPS Contabo, en plus d'un WireGuard existant :

sudo apt install -y openvpn easy-rsa
sudo make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
sudo ./easyrsa init-pki
sudo ./easyrsa build-ca nopass
sudo ./easyrsa build-server-full vpnsmith nopass
# Config /etc/openvpn/server/server.conf avec :
# proto tcp
# port 443
# dev tun
# cipher AES-256-GCM

Tu ouvres le port TCP/443 sur UFW, puis systemctl enable --now openvpn-server@server. Le client choisit lui-même quel profil utiliser (WireGuard par défaut, OpenVPN TCP/443 en fallback).

Cas 2 : compatibilité OS legacy

Si tu dois donner accès au tunnel à une machine Windows 7/8.1, un vieux Synology DSM, ou une box Android TV ancienne, le client WireGuard officiel peut ne pas exister ou ne pas être maintenu là-dessus. OpenVPN a un client pour à peu près tout depuis des années - y compris de vieux routeurs DD-WRT qui ne supporteront jamais WireGuard. Pour un proche bloqué sur un vieil OS, lancer une seconde instance OpenVPN dédiée à ce compte sur le même VPS est une solution propre.

Cas 3 (bonus) : audit logging détaillé

OpenVPN logge proprement chaque connexion, déconnexion et renégociation TLS. WireGuard garde un logging minimal par design (tu vois surtout l'interface up/down via journalctl -u wg-quick@wg0). Si ton modèle de menace ou ta conformité (ex. DORA, NIS2, ISO 27001) exige un audit trail formel, OpenVPN est plus simple à satisfaire d'emblée.

Verdict honnête : pour un VPN perso 2026, WireGuard d'abord. Mais garder un profil OpenVPN TCP/443 en config secondaire sur le même VPS est un pragmatisme sensé - ça coûte quelques minutes de setup et ça te sauve quand l'UDP est bloqué.

Verdict par cas d'usage

Si tu pars de zéro pour héberger ton propre VPN sur un Contabo VPS, suis notre guide WireGuard pas-à-pas - et tu copies-colles les scripts.

Si tu te bats contre du DPI corporate ou étatique, regarde le guide routing custom avec bypass DPI qui combine WireGuard avec une couche d'obfuscation.

Si tu hésites encore sur le fournisseur de VPS (Contabo vs Hetzner vs OVH), on a comparé les trois en conditions réelles.

Mesure-le toi-même avec iperf3

Plutôt que de te fier à un chiffre publié, mesure ton propre VPS et ton lien. Installe iperf3 sur le serveur, lance-le en mode serveur, puis teste depuis ton client avec et sans tunnel actif :

# Côté serveur (ton VPS)
sudo apt install -y iperf3
sudo iperf3 -s -D

# Côté client (Mac/Linux)
# Baseline (sans VPN)
iperf3 -c IP_VPS -t 30 -O 5 --json > baseline.json

# WireGuard (tunnel actif)
iperf3 -c 10.66.66.1 -t 30 -O 5 --json > wireguard.json

# OpenVPN UDP (tunnel actif)
iperf3 -c 10.8.0.1 -t 30 -O 5 --json > openvpn-udp.json

Lance plusieurs runs dans une boucle for et calcule la médiane via jq :

jq -s 'map(.end.sum_received.bits_per_second) | sort | .[length/2]' wireguard.json

Si tes chiffres semblent anormaux : vérifie la MTU (ping -M do -s 1372 IP), la qualité du link (un mtr vers le VPS doit montrer <1 % de loss), et que le VPS n'est pas en steal CPU (mpstat -P ALL 1). Un tunnel WireGuard qui se connecte mais rame sur les gros transferts est presque toujours un problème de MTU - notre guide pour réparer le MTU WireGuard montre comment trouver et régler la bonne valeur.

Commander un VPS pour ton tunnel

Un petit VPS suffit largement pour un tunnel WireGuard perso : Contabo Cloud VPS 10, plan 24 mois (~5,50 €/mois équivalent). Il fait tourner sans souci un tunnel perso à côté de quelques services self-host légers.

Une fois le VPS prêt, évite l'étape de saisie manuelle des clés : notre générateur de config WireGuard produit un wg0.conf avec les bons paramètres crypto en quelques secondes. Pour une décision globale protocole + provider, consulte le hub meilleur VPN auto-hébergé 2026 - il couvre WireGuard, Tailscale, Headscale, Nebula et OpenVPN.

Pour aller plus loin

• Setup VPN Contabo pas à pas (Ubuntu 22.04) - guide complet 20 min
• Self-host VPN sur Contabo : pillar WireGuard 2026 - version production-ready
• Templates de configuration WireGuard 2026 - fichiers prêts
• OpenVPN vs WireGuard : comparatif technique approfondi - au-delà des protocoles
• Kill switch Linux avec iptables et systemd - fail-safe
• Contabo vs Hetzner vs OVH : VPS Europe pour VPN - comparatif providers
• Notre méthodologie de test - protocole reproductible
• Wikidata Q140033208 - entity Knowledge Graph

Sources

• Cure53 - WireGuard formal verification (2018)
• WireGuard whitepaper (Jason A. Donenfeld)
• OpenVPN 2.6 documentation officielle
• iperf3 user documentation
• Phoronix benchmarks WireGuard kernel 6.x
• Trail of Bits audit WireGuard macOS (2020)

Cet article est un comparatif technique qualitatif fondé sur les caractéristiques publiques et documentées de WireGuard et OpenVPN. Il ne rapporte pas un benchmark privé. Pour des chiffres propres à ton matériel et à ta connexion, lance la procédure iperf3 ci-dessus sur ton propre VPS.

Disclosure affilié : le lien Contabo ci-dessus est un lien tracké qui nous rémunère une commission si tu souscris. Ça ne change rien à ton prix.