Les débits des publicités ne disent rien. Sur macOS, la vitesse réelle d'un tunnel dépend de l'implémentation, du serveur et de quelques réglages — rarement du chiffrement lui-même.
Un VPN ralentit toujours un peu la connexion : le trafic fait un détour par un serveur, et chaque paquet est chiffré puis encapsulé. La question utile est de savoir où se perd le débit, pour agir sur ce qui compte. Cette page fait le tour des facteurs, dans l'ordre de leur impact sur un Mac récent. Elle prolonge la vue d'ensemble sur le VPN pour Mac en se concentrant sur la mesure et l'optimisation.
Sur un Mac Apple Silicon, le processeur intègre les extensions cryptographiques ARMv8 : le chiffrement AES est accéléré par le matériel, et AES-GCM atteint des débits de plusieurs gigabits par seconde sans effort. ChaCha20-Poly1305, utilisé par WireGuard, est également très rapide, y compris en logiciel pur. Sur les Mac Intel récents, l'accélération AES-NI joue le même rôle.
Concrètement, sur une machine des dernières générations, le coût du chiffrement est négligeable devant celui du trajet réseau. Un VPN qui plafonne à 100 Mbit/s alors que la connexion en offre 900 n'est pas limité par la cryptographie — le goulot est ailleurs.
Le raisonnement change sur un Mac ancien : un modèle d'avant 2013 environ, sans AES-NI, chiffre en logiciel pur et peut voir son débit VPN limité par le processeur. Sur ces machines, ChaCha20-Poly1305 — donc WireGuard — est plus rapide qu'AES et sollicite moins le ventilateur. Mais ce cas devient rare, et sur toute la gamme Apple Silicon comme sur les Mac Intel récents, la cryptographie n'est plus un facteur.
C'est le facteur le plus spécifique à macOS. Contrairement à Linux, macOS n'a pas de module noyau pour WireGuard : le tunnel est géré par une extension réseau qui s'exécute en espace utilisateur (une NEPacketTunnelProvider). Chaque paquet fait donc plusieurs allers-retours entre le noyau et le processus de l'extension, ce qui consomme du processeur et limite le débit maximal atteignable — souvent quelques centaines de mégabits par seconde selon le client, là où un WireGuard noyau sur Linux dépasse le gigabit.
Les conséquences pratiques :
Il n'y a pas de réglage utilisateur qui contourne cette limite ; le choix du protocole est le principal levier. Le détail de leur mise en œuvre est abordé dans la page sur l'installation d'un VPN sur macOS.
Le tunnel ajoute ses propres en-têtes à chaque paquet — de 60 à 80 octets selon le protocole. Si la taille maximale de paquet (MTU) du tunnel est trop élevée pour le chemin réseau, les paquets sont fragmentés ou rejetés, ce qui se traduit par des lenteurs, des téléchargements qui calent et des pages qui se figent à moitié chargées. Les bons clients ajustent automatiquement le MTU (valeurs typiques entre 1280 et 1420 octets) et gèrent la découverte de MTU du chemin. Un client qui laisse un MTU inadéquat donne une impression de lenteur sans rapport avec la vitesse du serveur ; certains permettent de le régler manuellement dans les paramètres avancés.
Le serveur choisi pèse plus lourd que tout le reste. Sa distance ajoute une latence incompressible — environ 40 à 60 ms d'aller-retour pour un serveur à 3 000 km — qui pénalise la navigation et tout ce qui est interactif. Sa charge détermine le débit disponible : un serveur saturé aux heures de pointe effondre la vitesse quel que soit le protocole. Sa capacité (liaison réseau du centre de données) fixe un plafond.
La règle : pour un usage quotidien, choisir le serveur le plus proche qui répond au besoin, et réserver les serveurs lointains aux cas où la localisation de sortie est le but recherché.
Sur Wi-Fi, le VPN empile sa surcharge sur un lien déjà variable ; une connexion Ethernet ou Thunderbolt stabilise nettement les mesures et le ressenti. Sur un portable, le tunnel a aussi un coût énergétique : la radio Wi-Fi est maintenue plus active, des messages de maintien de session réveillent l'interface périodiquement, et le client VPN doit s'exclure d'App Nap — le mécanisme qui met en veille les applications inactives — pour garder le tunnel debout. On peut inspecter les verrous d'alimentation posés par les applications avec pmset -g assertions dans le Terminal.
Plusieurs options, utiles dans certains contextes, se paient en performance. Le multi-saut (le trafic traverse deux serveurs VPN au lieu d'un) double la latence et ajoute une passe de chiffrement : à réserver à un besoin réel de cloisonnement. Les serveurs obfusqués, qui enveloppent le tunnel dans une couche supplémentaire pour traverser un filtrage par inspection de paquets, ralentissent aussi et n'ont d'intérêt que sur un réseau qui bloque les protocoles VPN standards. Le blocage de publicités ou de traqueurs intégré au client ajoute un traitement DNS par requête, généralement imperceptible mais non nul. Enfin, un kill switch mal implémenté peut provoquer des micro-coupures lors des changements de réseau. Activer uniquement ce dont on a besoin est la première optimisation.
Si le relais privé iCloud est activé et qu'un VPN tiers prend le relais, macOS désactive automatiquement le relais privé le temps de la connexion VPN — les deux ne s'empilent pas. En revanche, sur un réseau qui bloque le relais privé, Safari peut afficher des avertissements même VPN actif : c'est un comportement du relais, pas du VPN, et il n'affecte pas le tunnel.
Les tests de débit dans le navigateur sont trompeurs : ils frappent un serveur proche via un réseau de diffusion de contenu, et ne reflètent pas la performance du tunnel vers une destination réelle. Méthode plus fiable :
networkQuality (Terminal, macOS 12 et plus) : mesure le débit descendant et montant et la latence sous charge, l'indicateur le plus représentatif de l'expérience réelle.ping et traceroute vers une destination stable, pour isoler la latence ajoutée par le tunnel.Dans tous les cas : tester avant et après activation du VPN, sur le même serveur cible, au même moment de la journée, et répéter à quelques minutes d'intervalle pour lisser les variations.
Réglable : le protocole, le serveur, le MTU, l'exclusion d'App Nap, le passage en Ethernet, l'abandon du multi-saut s'il n'est pas nécessaire. Non réglable : la capacité du parc de serveurs, le bridage volontaire d'un palier gratuit, le plafond imposé par l'architecture Network Extension de macOS.
Sur un Mac récent, la perte de débit d'un VPN vient d'abord du serveur (distance et charge), ensuite de l'implémentation du protocole en espace utilisateur, puis d'un MTU mal réglé — et quasiment jamais du chiffrement. Choisir un serveur proche et dégagé, préférer WireGuard ou IKEv2, vérifier le MTU et mesurer avec networkQuality plutôt qu'avec un test navigateur suffit à obtenir le meilleur d'un service donné. Le reste dépend de la qualité de l'infrastructure de l'éditeur, sujet lié à son modèle économique.