Deux philosophies de conception
WireGuard et OpenVPN ne sont pas deux implémentations du même concept : ils incarnent deux époques du chiffrement de tunnel.
OpenVPN est né en 2001 : environ 100 000 lignes de C en espace utilisateur, négociation TLS complète, certificats X.509, bibliothèques OpenSSL, plugins d'authentification (LDAP, TOTP, PKCS#11), transport UDP ou TCP. C'est un couteau suisse : il sait tout faire, au prix d'une surface de code que personne — pas même ses mainteneurs — ne lit en entier.
WireGuard, publié en 2015 par Jason Donenfeld et intégré au noyau Linux en 2020, tient en environ 4 000 lignes. Choix cryptographique figé et moderne : Curve25519 pour l'échange de clés, ChaCha20-Poly1305 pour le transport, BLAKE2s pour le hachage, et un routage par clés publiques (« cryptokey routing ») qui rend la configuration lisible d'un coup d'œil. Le code court n'est pas une garantie absolue — mais il rend l'audit réaliste : trois audits formels indépendants (2020, 2021, 2022) ont couvert l'intégralité du cœur du protocole, exercice à cette échelle impossible sur OpenVPN.
Règle empirique du logiciel de sécurité : la confiance croît quand la surface d'audit diminue. Sur ce critère, WireGuard gagne sans discuter — c'est sa raison d'exister.
Performance : l'écart mesuré
Nous avons mesuré les deux protocoles en interne en août 2026 sur un VPS-3 Horizon (4 vCPU EPYC, 1 Gbps illimitée), entre nos points de présence de Rotterdam et Zurich, avec iperf3 en dix flux parallèles. Conditions propres, MTU 1420, noyau 6.8 :
| Protocole | Débit agrégé | CPU émetteur | CPU récepteur | Reconnexion |
|---|---|---|---|---|
| WireGuard (UDP) | 938 Mbps | 23 % | 19 % | < 100 ms |
| OpenVPN 2.6 (UDP, AES-256-GCM) | 612 Mbps | 64 % | 58 % | 1,2–3 s |
| OpenVPN 2.6 (TCP, AES-256-GCM) | 428 Mbps | 71 % | 66 % | 1,5–3,5 s |
Méthodologie : mesures internes août 2026, iperf3 ×10, fenêtres TCP par défaut. Vos résultats varieront avec la latence, le MTU et la charge CPU.
Deux enseignements. D'abord, l'écart est structurel, pas accidentel : WireGuard vit dans le noyau, sans copie mémoire entre contextes ; OpenVPN traverse les couches utilisateur à chaque paquet. Ensuite, AES-GCM accéléré par AES-NI reste honnête — 612 Mbps suffisent à la plupart des usages — mais il consomme près de trois fois plus de CPU pour les deux tiers du débit. Sur batterie, la différence devient autonomie : +30 à 40 % en faveur de WireGuard dans notre test de routage continu sur quatre heures.
Enfin, un détail d'architecture qui change tout en mobilité : WireGuard est sans état de connexion. Il n'existe pas de « session » à rétablir — chaque paquet authentifié suffit. Changement d'IP côté client, bascule 4G/Wi-Fi, réveil de machine : le tunnel reprend instantanément, sans négociation. OpenVPN, bâti sur TLS, doit renégocier à chaque rupture ; ce sont ces secondes de reconnexion qu'on subit sur smartphone.
Résistance au DPI : le point faible de WireGuard
Voici ce que les benchmarks ne montrent pas : WireGuard est trivial à identifier. Son premier message contient des champs d'identification stables en clair, sa signature UDP est stable et atypique, et il n'existe tout simplement pas en transport TCP : soit l'UDP passe, soit rien ne passe. Depuis 2021, des réseaux étatiques et des pare-feux d'opérateurs bloquent WireGuard par signature — souvent en quelques heures.
OpenVPN présente un profil différent. En UDP, il est reconnaissable mais plus banal. En TCP sur le port 443, il imite du HTTPS — imparfaitement (empreinte TLS, certificat auto-signé repérable), mais suffisamment pour traverser la plupart des pare-feux « sortie web uniquement » : hôtels, avions, intranets d'entreprise. Surtout, l'écosystème d'obfuscation d'OpenVPN est mature : obfs4 déforme le flux pour le faire passer pour du trafic non-VPN, stunnel l'enveloppe dans du TLS réel. WireGuard n'a rien de natif équivalent ; les solutions existent (couche intermédiaire, port UDP inhabituel, encapsulation), mais elles ajoutent une machine — et un point de défaillance — dans la chaîne.
Quand OpenVPN gagne encore — et c'est mérité
Trois situations où nous installons encore OpenVPN, volontiers :
- Sortie réseau restreinte. Si vos clients traversent des proxys qui n'autorisent que TCP 443, OpenVPN en TCP reste le seul tunnel fiable sans couche supplémentaire.
- Matériel ancien ou embarqué. Routeurs antérieurs au noyau 5.6, vieilles boxes, systèmes sans accès noyau : WireGuard y est impossible ou douloureux ; OpenVPN y tourne depuis vingt ans.
- Intégration d'entreprise. Authentification par certificats internes, MFA via plugins, annuaire LDAP, conformité aux politiques PKI : OpenVPN s'y branche. WireGuard, par design, n'en fera jamais la promesse — c'est une vertu autant qu'une limite.
Ajoutez l'obfuscation éprouvée (obfs4) et la gestion de la rotation de clés par PKI, et OpenVPN conserve un territoire légitime. Le décréter obsolète serait aussi faux que le déclarer universel.
Notons enfin que les deux protocoles cohabitent parfaitement sur la même machine : rien n'empêche de faire tourner wg-quick@wg0 et une instance OpenVPN côte à côte, chacun sur son port et sa gamme d'adresses. C'est d'ailleurs l'architecture de nos propres bastions d'administration internes — WireGuard pour le trafic courant, OpenVPN en TCP 443 en filet de sécurité.
L'arbre de décision
Quatre questions, dans l'ordre, tranchent dans 95 % des cas :
Réseau libre, performance d'abord ?
WireGuard. Clients officiels partout (Linux, Windows, macOS, iOS, Android), débit proche du port, quatre lignes de configuration.
Réseau hostile ou censuré ?
OpenVPN en TCP 443 + obfs4, ou double tunnel WireGuard encapsulé dans OpenVPN. Testez depuis le réseau réel avant de figer l'architecture.
Matériel ancien ou routeur ?
OpenVPN, sauf noyau 5.6+ avec WireGuard backporté. Ne vous battez pas contre le firmware.
PKI d'entreprise, MFA, conformité ?
OpenVPN avec certificats. S'il s'agit d'un besoin personnel, passez à WireGuard dès que possible.
WireGuard sur un VPS VPSPLEX : la configuration complète
Un VPS-1 Coast (6,99 $/mois) suffit à héberger un tunnel WireGuard personnel à 1 Gbps illimitée — bande passante non comptée, UDP libre. La mise en route complète sur Debian ou Ubuntu :
# 1. Installation
apt update && apt install -y wireguard
cd /etc/wireguard && umask 077
# 2. Paires de clés (serveur + client)
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee client.key | wg pubkey > client.pub
# 3. Configuration du serveur — collez les clés générées
cat > wg0.conf <<'EOF'
[Interface]
Address = 10.7.0.1/24
ListenPort = 51820
PrivateKey = COLLEZ_ICI_SERVER_KEY
[Peer]
PublicKey = COLLEZ_ICI_CLIENT_PUB
AllowedIPs = 10.7.0.2/32
EOF
# 4. Forwarding + démarrage
sysctl -w net.ipv4.ip_forward=1
systemctl enable --now wg-quick@wg0
Le bloc miroir côté client tient en huit lignes — Endpoint désigne l'IP de votre VPS, PersistentKeepalive maintient le trou NAT ouvert. Sur le téléphone, évitez le transfert de fichier : affichez la configuration en QR et scannez-la depuis l'application WireGuard.
# Configuration client (wg0.conf du laptop ou du téléphone)
[Interface]
PrivateKey = COLLEZ_ICI_CLIENT_KEY
Address = 10.7.0.2/32
DNS = 1.1.1.1
[Peer]
PublicKey = COLLEZ_ICI_SERVER_PUB
Endpoint = IP_DE_VOTRE_VPS:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
# Côté serveur : wg show doit afficher un handshake récent
Astuce mobile : qrencode -t ansiutf8 < client.conf affiche le QR directement dans votre terminal.
Côté pare-feu, ouvrez le port UDP 51820 (ou un autre port — WireGuard s'y adapte) et activez le masquerade : deux règles nftables et le tour est joué. Une précision d'usage, parce que nous vous la devons : un tunnel VPN sur votre VPS est un usage parfaitement légitime — navigation sécurisée depuis des réseaux hostiles, accès à vos services, géo-redondance. Il ne rend ni licite ni invisible quoi que ce soit d'illégal : notre politique d'abus reste intégrale (pas de phishing, de spam ni de malware), et un VPN ne remplace jamais une hygiène opérationnelle.