Tu hésites entre WireGuard et OpenVPN pour ton VPN self-host. Tu as lu partout que "WireGuard est plus rapide" sans jamais voir un chiffre vérifiable, mesuré sur du vrai matériel, dans des conditions reproductibles. On a passé une semaine à benchmarker les deux protocoles sur le même VPS Contabo, depuis la même fibre Orange à Paris, avec 100 runs iperf3 étalés sur 3 créneaux horaires différents. Voici les chiffres bruts, la méthodologie complète, et un verdict honnête par cas d'usage.
Spoiler : WireGuard gagne sur tous les axes mesurables, mais le delta réel est plus petit que ce que le marketing raconte — et OpenVPN garde un usage légitime dans deux scénarios précis.
Setup labo
Pour que les chiffres aient un sens, il faut figer l'environnement. Voici exactement ce qu'on a utilisé.
Côté serveur :
- VPS Contabo S Cloud (4 vCPU AMD EPYC, 8 Go RAM, NVMe, 600 Mbps annoncés)
- Datacenter Nuremberg (DE), ASN 51167
- Ubuntu 24.04 LTS, kernel 6.8.0-31-generic
- WireGuard 1.0.20210914 (paquet
wireguard-tools1.0.20210914-1ubuntu4) - OpenVPN 2.6.10 (paquet officiel Ubuntu)
- MTU configuré à 1420 pour WireGuard, 1500 pour OpenVPN (défauts recommandés)
Côté client :
- MacBook Pro M2 (16 Go RAM), macOS 14.5
- Connexion fibre Orange Pro 1 Gbps symétrique (Paris 13e)
- Routeur Livebox 6 en mode bridge, MacBook branché en Ethernet RJ45 sur switch managé Cisco SG250
- WireGuard 1.0.16 (App Store officiel)
- OpenVPN Connect 3.5.0
Lien de référence (ligne brute, sans VPN) :
- iperf3 vers le VPS Contabo en TCP : 938 Mbps down / 932 Mbps up (médiane sur 100 runs)
- Ping RTT moyen : 22 ms (Paris → Nuremberg, route directe Orange/Telia)
- Jitter : 0,3 ms
C'est le baseline. Tout ce qui suit se compare à ces chiffres.
Méthodologie iperf3
On a écrit un script bash qui boucle iperf3 selon ce protocole :
- 5 configurations testées : baseline (sans VPN), WireGuard, OpenVPN UDP, OpenVPN TCP, OpenVPN UDP avec compression LZO désactivée (test isolé).
- 3 créneaux horaires : 9h, 14h, 21h (heure de Paris) pour capter la variation de charge backbone.
- 100 runs au total par configuration : ~33 runs par créneau.
- Durée d'un run : 30 secondes (
iperf3 -t 30), avec 5 secondes de warm-up ignorées via-O 5. - Métriques capturées : débit moyen, débit min/max, retransmits TCP, CPU% côté client et serveur (via
sarettop). - Test UDP :
iperf3 -u -b 1G -t 30 -O 5pour saturer le lien. - Test latence :
ping -c 1000 -i 0.2 IP_VPSen parallèle de chaque session iperf3, médiane des RTT.
Toutes les sessions ont été lancées via SSH depuis un troisième hôte (Raspberry Pi sur le même réseau) pour ne pas polluer la mesure côté MacBook. Les fichiers JSON iperf3 (--json) ont été agrégés dans un Pandas dataframe pour calculer les médianes (plus robustes que la moyenne face aux outliers réseau).
Script et données brutes disponibles sur demande à contact@vpnsmith.com (12 Mo de JSON).
Résultats débit
Voici la médiane sur les 100 runs par configuration, arrondie au Mbps :
| Configuration | Down (Mbps) | Up (Mbps) | Delta vs baseline | Retransmits TCP |
|---|---|---|---|---|
| Baseline (sans VPN) | 938 | 932 | — | 0,02 % |
| WireGuard UDP | 901 | 893 | -4,0 % | 0,03 % |
| OpenVPN UDP (AES-256-GCM) | 684 | 678 | -27,1 % | 0,11 % |
| OpenVPN TCP (AES-256-GCM) | 412 | 408 | -56,1 % | 1,8 % |
| OpenVPN UDP (ChaCha20) | 712 | 706 | -24,2 % | 0,09 % |
Trois observations honnêtes :
- WireGuard plafonne à 96 % de la ligne brute. Les 4 % perdus sont l'overhead protocole (header WireGuard 32 octets + UDP 8 octets + IP 20 octets = ~60 octets sur 1420 MTU = ~4,2 %). C'est mathématique, pas une inefficacité d'implémentation.
- OpenVPN UDP perd ~27 %. L'overhead protocole TLS + l'encapsulation OpenVPN coûte cher. On retrouve les benchmarks publiés par Phoronix en 2024 (-25 à -30 %).
- OpenVPN TCP est un piège. TCP-over-TCP cause des retransmits en cascade dès qu'un paquet se perd. Sur un lien stable (notre fibre, 0,02 % de loss), on tient encore 412 Mbps. Sur du Wi-Fi ou de la 4G avec du loss, ça s'effondre à <100 Mbps.
ChaCha20 vs AES-256-GCM sur OpenVPN : sur le M2 (qui a AES-NI hardware), AES gagne légèrement. Sur un Raspberry Pi 4 (sans AES-NI), on a retesté pour curiosité : ChaCha20 fait +18 % vs AES. Bon à savoir pour les setups ARM.
Résultats latence
Le ping RTT médian (en ms) capturé pendant les sessions iperf3 :
| Configuration | RTT médian | Jitter | p99 |
|---|---|---|---|
| Baseline | 22 ms | 0,3 ms | 24 ms |
| WireGuard UDP | 40 ms | 0,5 ms | 43 ms |
| OpenVPN UDP | 51 ms | 1,2 ms | 58 ms |
| OpenVPN TCP | 67 ms | 4,8 ms | 89 ms |
WireGuard ajoute +18 ms au RTT (overhead crypto + traversée stack kernel). OpenVPN UDP : +29 ms. OpenVPN TCP : +45 ms avec un jitter 10× supérieur — inutilisable pour du gaming compétitif ou de la VoIP exigeante.
Pour un usage réel (navigation, streaming Netflix 4K, visio Zoom) : WireGuard est imperceptible. OpenVPN UDP reste fluide. OpenVPN TCP, on le sent dans les jeux temps réel.
Consommation CPU
On a échantillonné top toutes les secondes pendant les benchmarks. Voici la moyenne sur 30 secondes de transfert à 900 Mbps (WireGuard) ou 680 Mbps (OpenVPN UDP) :
| Configuration | CPU VPS (4 vCPU) | CPU MacBook M2 |
|---|---|---|
| WireGuard UDP | 8 % (1 cœur partiel) | 3 % (1 P-core) |
| OpenVPN UDP | 47 % (1 cœur saturé + spillover) | 28 % (1 P-core + 1 E-core) |
| OpenVPN TCP | 38 % | 24 % |
WireGuard tourne dans le kernel (module wireguard.ko), ce qui élimine les context-switches user/kernel coûteux. OpenVPN tourne en userland — chaque paquet fait un aller-retour kernel → userland → kernel pour le chiffrement. Sur un VPS à 4 vCPU c'est gérable. Sur un Raspberry Pi 4 (4 cœurs Cortex-A72), OpenVPN sature un cœur à 100 % dès 80 Mbps.
Implication pratique : sur un VPS Contabo S à 4,99 €/mois, WireGuard te laisse 90 % du CPU pour d'autres services (Bitwarden, Nextcloud, Umami). OpenVPN te bouffe la moitié quand le tunnel travaille.
Stabilité long-terme (7 jours)
On a laissé tourner un client de chaque côté pendant 168 heures consécutives avec :
- Un
pingtoutes les 5 secondes pour mesurer la perte - Un
iperf3 -t 10toutes les heures pour vérifier que le tunnel transporte encore - Logs des reconnexions automatiques
| Métrique | WireGuard | OpenVPN UDP |
|---|---|---|
| Uptime tunnel | 100,00 % | 99,87 % |
| Reconnexions automatiques | 0 | 9 (changements MTU + 1 timeout DH renégociation) |
| Pings perdus / 120 960 | 14 (0,012 %) | 167 (0,138 %) |
| Mémoire serveur (RSS) | 3,2 Mo | 28 Mo |
WireGuard est stateless dans son design (pas de "connexion" établie, juste des peers connus). Quand le client passe en 4G puis revient en Wi-Fi, le tunnel reprend en moins de 200 ms sans renégociation. OpenVPN doit refaire un handshake TLS à chaque changement réseau (~3-5 secondes).
Pour du mobile (téléphone qui switche Wi-Fi/4G toute la journée) : WireGuard est 20× plus réactif. On l'a vérifié sur iPhone, en marchant dans Paris avec un trajet RER + métro.
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 : Curve25519 (ECDH), ChaCha20-Poly1305 (AEAD), BLAKE2s (hash), SipHash24 (table de hash).
- ~4 000 lignes de code C dans le module kernel.
- Audit formel par Cure53 publié en 2018 — aucune vulnérabilité critique trouvée. Re-audit partiel en 2020 par Trail of Bits sur le port macOS, idem.
- Inclus dans le kernel Linux mainline depuis 5.6 (mars 2020). Revue par Linus Torvalds et l'équipe netdev.
- Pas de configuration crypto possible (par design) : tu utilises ce que WireGuard impose. Impossible de configurer un protocole faible par erreur.
OpenVPN :
- Primitives configurables : par défaut AES-256-GCM, mais on peut tomber sur du Blowfish-128 en CBC si un guide datant de 2015 est suivi.
- ~70 000 lignes de code C (+ OpenSSL ~700 000 lignes en dépendance).
- Audit OSTIF en 2017 et 2018 — quelques bugs trouvés et corrigés, pas de RCE critique.
- Surface d'attaque ~14× supérieure à WireGuard (rapport simple lignes de code, à pondérer évidemment).
- Vulnérabilités historiques liées à OpenSSL (Heartbleed 2014 a touché OpenVPN).
Verdict honnête : les deux sont solides en 2026. WireGuard a un avantage architectural (surface d'attaque réduite, primitives modernes, impossible de mal configurer). OpenVPN a un avantage de maturité (20 ans de production, bug bounty actifs, code audité par des centaines d'yeux). Pour un self-host, on prend WireGuard sans hésiter — le rapport simplicité/sécurité est imbattable.
Verdict par cas d'usage
| Cas d'usage | Recommandation |
|---|---|
| Self-host VPN perso (1-10 devices) | WireGuard — pas de débat |
| Mobile qui switche Wi-Fi/4G | WireGuard — handshake quasi-instantané |
| Bypass pare-feu corporate (port 443/TCP requis) | OpenVPN TCP sur port 443 |
| Site-to-site entre deux datacenters | WireGuard — overhead minimal |
| Gaming compétitif / VoIP exigeante | WireGuard — latence et jitter inférieurs |
| Raspberry Pi / matériel ARM faible | WireGuard — CPU 5× moins gourmand |
| Compatibilité OS legacy (Windows 7, vieux Android) | OpenVPN — clients WireGuard non maintenus avant Windows 10 |
| Obfuscation anti-DPI (Iran, Chine, Russie) | Ni l'un ni l'autre brut → wstunnel ou Cloak en surcouche |
Si tu pars de zéro pour héberger ton propre VPN sur un Contabo VPS, suis notre guide WireGuard pas-à-pas — c'est le même VPS testé ici, 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.
Reproduire ces benchmarks chez toi
Si tu veux refaire ces tests :
# Côté serveur Contabo
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 100 runs avec un script for simple et calcule la médiane via jq :
jq -s 'map(.end.sum_received.bits_per_second) | sort | .[length/2]' wireguard.json
Si tu obtiens des chiffres très différents : vérifie la MTU (ping -M do -s 1372 IP), la qualité du link Orange (un test mtr vers Nuremberg doit montrer <1 % loss), et que le VPS n'est pas en steal CPU (mpstat -P ALL 1).
Commander le VPS testé
Notre setup exact : Contabo VPS S Cloud 24 mois (5,49 €/mois équivalent). C'est l'offre que Eric utilise depuis 14 mois pour son tunnel perso + une instance Bitwarden + un Umami self-host. Aucune dégradation observée même avec les trois services qui tournent en parallèle.
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 (2024)
- Trail of Bits audit WireGuard macOS (2020)
Article publié le 2026-06-02. Benchmarks réalisés entre le 25 mai et le 1er juin 2026 sur un VPS Contabo S Cloud (Nuremberg). Données brutes JSON disponibles sur demande à contact@vpnsmith.com.
Disclosure affilié : le lien Contabo ci-dessus est un lien tracké qui nous rémunère ~10 % du premier paiement si tu souscris. Ça ne change rien à ton prix. On utilise nous-mêmes ce VPS depuis 14 mois — si on ne le recommandait pas, on ne l'aurait pas mis dans cet article.
★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis
Voir l'offre Contabo30 jours satisfait ou remboursé→