Les standards radio — fondations de la sécurité des communications

Avant WireGuard et OpenVPN, les ingénieurs radio avaient développé des standards de communication sécurisée remarquablement sophistiqués. APCO P25, développé à partir de 1989 pour les services d'urgence nord-américains, définit un protocole complet avec chiffrement AES, authentification mutuelle des terminaux, gestion des clés de chiffrement Over The Air (OTAR), et interopérabilité entre équipements de fabricants différents. DMR (Digital Mobile Radio), standard ETSI adopté en Europe, offre des fonctionnalités similaires avec une architecture différente orientée vers les usages commerciaux.

Ces standards posaient une exigence que les protocoles VPN modernes ont mis du temps à reproduire : l'interopérabilité entre équipements de fabricants différents avec des garanties de sécurité vérifiables. Un terminal P25 certifié Motorola communique de façon sécurisée avec un terminal P25 certifié Kenwood — les clés de chiffrement et les protocoles d'authentification sont standardisés, pas propriétaires.

WireGuard — le protocole moderne de référence

WireGuard représente dans l'écosystème VPN ce que P25 représentait dans la radio professionnelle : un standard épuré, avec un ensemble d'algorithmes cryptographiques fixé, une surface d'attaque minimale, et une auditabilité maximale. Le code source tient en environ 4 000 lignes — contre 70 000 pour OpenVPN. Cette compacité n'est pas une limitation : c'est une propriété de sécurité. Un code que des auditeurs humains peuvent relire intégralement est un code dont les propriétés de sécurité sont vérifiables.

La pile cryptographique de WireGuard est fixée : Curve25519 pour l'échange de clés, ChaCha20-Poly1305 pour le chiffrement authentifié, BLAKE2s pour le hachage. Pas de négociation, pas de choix de suites, pas de possibilité de downgrade vers des algorithmes faibles. Cela correspond exactement à l'approche des systèmes radio professionnels de qualité — des algorithmes de chiffrement fixés dans le standard, pas négociables à l'exécution.

La limitation WireGuard en contexte professionnel

WireGuard identifie les pairs par clé publique et maintient une table d'association pairs/IP dans le kernel Linux. Cette table est visible via les outils système standards. Pour un usage enterprise avec des équipes distantes et des politiques de confidentialité strictes, cette exposition des IPs des pairs actifs est une contrainte à gérer. Les implémentations sérieuses ajoutent une couche de rotation de clés et d'isolation réseau au-dessus du WireGuard standard.

OpenVPN — flexibilité et maturité

OpenVPN délègue la cryptographie à OpenSSL, donnant accès à l'ensemble des suites TLS disponibles. Cette flexibilité est à double tranchant : elle permet des configurations très robustes, mais aussi des déploiements faibles si l'administrateur ne fait pas attention. Une configuration OpenVPN sécurisée en 2026 doit explicitement imposer TLS 1.3 minimum, AES-256-GCM, et désactiver les suites dépréciées que les versions anciennes d'OpenSSL pourraient autrement négocier.

L'avantage opérationnel d'OpenVPN en contexte enterprise : il peut tourner sur TCP port 443, indiscernable du trafic HTTPS pour un pare-feu stateless. Dans des environnements où les connexions UDP sont filtrées ou surveillées — hôtels d'affaires, réseaux d'entreprises clients, certains pays — OpenVPN sur TCP est souvent le seul protocole qui passe.

IPsec/IKEv2 — le standard enterprise natif

IPsec est intégré nativement dans Windows, macOS, iOS et Android — aucun client tiers requis. Cette intégration native est un avantage de déploiement significatif pour les organisations qui gèrent des flottes d'appareils hétérogènes. IKEv2, la version actuelle du protocole d'échange de clés, supporte MOBIKE — une extension qui maintient les sessions VPN à travers les changements d'adresse IP réseau. Pratique pour les équipes mobiles qui basculent entre Wi-Fi et 4G.

La complexité de la spécification IPsec est sa principale faiblesse. L'étendue des options configurables laisse de la place aux erreurs d'implémentation et aux configurations sous-optimales. Plusieurs CVE historiques ont touché des implémentations spécifiques. La robustesse d'une installation IPsec dépend autant de la qualité de l'implémentation utilisée que du standard lui-même.

Protocole Algorithmes Client requis Filtrabilité Usage recommandé
WireGuard Fixés (Curve25519, ChaCha20) Oui (léger) UDP — filtrable Standard — performances optimales
OpenVPN Négociés (OpenSSL) Oui (lourd) TCP/443 — indiscernable HTTPS Environnements avec filtrage UDP
IKEv2/IPsec Négociés (AES-256-GCM) Natif OS UDP 500/4500 — filtrable Flottes mobiles — BYOD
APCO P25 Fixés (AES-256) Terminal certifié Radio — portée limitée Communications terrain — services d'urgence

Le choix du protocole en pratique

En entreprise, la décision n'est pas binaire. Les VPN commerciaux modernes supportent généralement WireGuard, OpenVPN et IKEv2 simultanément et basculent automatiquement selon le contexte réseau. La priorité va à WireGuard pour les performances, avec fallback automatique sur OpenVPN TCP si les ports UDP sont bloqués. C'est une approche similaire à ce que les systèmes radio multi-standards (P25/DMR/analogique) faisaient pour maintenir la couverture — choisir le meilleur protocole disponible dans chaque contexte, avec dégradation gracieuse.

Pour les critères de sélection d'un VPN d'entreprise, le support multi-protocoles est un signal positif — il indique que l'éditeur a investi dans une implémentation robuste plutôt que dans un protocole propriétaire non audité.