Accélérateur VPN : fonctionnement, conditions d’efficacité et limites
Le VPN Accelerator est le nom commercial donné par Proton VPN à un ensemble d’optimisations déployées sur son infrastructure, certaines développées en interne, d’autres basées sur des mécanismes standards de transport réseau. Ce n’est pas une catégorie générique de produit, c’est un bundle propriétaire, intégré aux applications VPN du fournisseur et activé par défaut pour tous les utilisateurs (désactivable selon plateforme, d’après la documentation officielle), conçu pour agir sur la vitesse des VPN dans des conditions réseau spécifiques.
Plusieurs mécanismes distincts sous un seul nom
Le VPN Accelerator regroupe des interventions à plusieurs niveaux de la chaîne de traitement réseau. Les comprendre séparément évite de traiter le chiffre de performance global comme s’il s’appliquait uniformément à toutes les situations.
1. Multi-process OpenVPN : contourner un goulot d’étranglement structurel
La base de code OpenVPN 2 classique est monothread par processus. Sur les CPU modernes, qui disposent de nombreux cœurs — cela signifie qu’un seul cœur peut saturer pendant que les autres restent sous-utilisés. Le résultat concret : un plafond de débit atteint non pas faute de bande passante, mais faute de capacité de traitement sur ce cœur unique.
Proton explique avoir redistribué ce traitement sur plusieurs processus parallèles, ce qui réduit fortement ce goulot pour les sessions OpenVPN à haut débit. L’effet est particulièrement visible sur les connexions rapides où le traitement du chiffrement peut devenir le facteur limitant, c’est l’approche classique pour contourner la limite monothread d’OpenVPN 2 : lancer plusieurs processus/daemons en parallèle.
La firme suisse affirme que le VPN Accelerator améliore les performances quel que soit le protocole utilisé, OpenVPN TCP/UDP, WireGuard, IKEv2, Stealth. Cette annonce globale est cohérente avec la documentation de Proton, mais les composantes qui expliquent ce gain ne sont pas les mêmes selon le protocole. Le volet multi-process concerne spécifiquement OpenVPN : WireGuard® est nativement intégré au kernel Linux et gère déjà le parallélisme différemment. L’impact de cette optimisation est donc structurellement plus marqué sur OpenVPN que sur WireGuard®. À noter : Proton a retiré OpenVPN de son application Android — ce volet concerne principalement les connexions desktop et les configurations manuelles.
2. Segmentation du trajet : extraire plus de débit utile sur les chemins longs
Proton rappelle dans sa page technique que le goodput TCP, le débit effectivement utile, net des retransmissions et des délais de contrôle de congestion, décroît à mesure que la latence et le taux de perte de paquets augmentent. C’est pourquoi les tests de vitesse sélectionnent souvent des serveurs proches. Sur un chemin long, TCP passe une part croissante du temps à gérer la congestion plutôt qu’à transmettre des données. Connecter un appareil à un VPN allonge mécaniquement ce chemin, ce qui peut aggraver le phénomène.
Une des réponses documentées par ce fournisseur est de fractionner ce chemin en segments plus courts, ce qu’ils appellent le « split path ». Leur exemple dans le billet de 2021 : un trajet de 600 ms traité comme deux segments de 300 ms. Sur chaque segment plus court, le goodput TCP peut être significativement plus élevé, et la performance combinée sur l’ensemble du trajet s’en trouve améliorée. Ce mécanisme ne raccourcit pas physiquement Internet ; il exploite la sensibilité de TCP à la longueur des chemins pour en extraire plus de débit utile. Proton ne détaille pas publiquement la mise en œuvre réseau précise de cette segmentation.
Par-dessus cette segmentation, Proton indique utiliser BBR, un mécanisme de contrôle de congestion TCP, pour améliorer le débit utile dans certaines conditions (détails sur le fonctionnement et les limites dans la page dédiée à BBR).
Précision technique : BBR est un mécanisme de contrôle de congestion TCP. Son effet direct concerne les flux transportés en TCP, OpenVPN TCP, WireGuard TCP, Stealth (WireGuard tunnelé sur TLS). Sur les tunnels purement UDP (WireGuard UDP, OpenVPN UDP, IKEv2), les gains proviennent des autres composantes du bundle, segmentation du trajet, optimisations de forwarding, distribution de charge, pas de BBR.
3. Optimisation du forwarding : éliminer les blocages et raccourcir le chemin des paquets
Proton explique également que de petits stalls peuvent entraîner une forte réduction du pacing TCP et donc des performances. Proton identifie une source spécifique de ces stalls dans le code d’OpenVPN et d’IKEv2 : des inefficacités peuvent bloquer le control socket, interrompant momentanément le flux. Pour y remédier, Proton a déchargé les communications interprocessus vers des processus annexes développés en interne, ce qu’ils appellent des « companion processes », afin d’éliminer cette catégorie de blocages.
En parallèle, Proton modifie la pile réseau Linux sur ses serveurs pour contourner le chemin normal de traitement des paquets pour le « trafic connu », réduisant ainsi le nombre de couches traversées avant transmission. L’ensemble repose sur une infrastructure bare-metal, des serveurs VPN physiques non virtualisés, ce qui élimine la couche d’abstraction entre le système d’exploitation et le matériel réseau, dégradante pour le forwarding. C’est vraisemblablement la composante la plus transversale du bundle, elle agit indépendamment du protocole et de la géographie, mais ces affirmations sont celles de Proton : la mise en œuvre interne n’est pas auditable de l’extérieur, et Proton ne fournit pas de mesure isolée pour cette seule optimisation.
Les 400 % : un chiffre réel, dans des conditions précises
Selon Proton, le VPN Accelerator peut améliorer les débits jusqu’à 400 % dans les cas les plus favorables. Le fournisseur précise dans sa documentation que ce gain s’exprime principalement sur les connexions longue distance et les réseaux avec pertes de paquets.
Sur une connexion locale, un utilisateur en France se connectant à un serveur français sur fibre, sans congestion réseau, l’impact sera nettement plus limité. C’est la situation de la majorité des utilisateurs européens en usage quotidien. Les trois mécanismes décrits ci-dessus produisent un effet d’autant plus visible que les conditions de départ sont dégradées : distance élevée, latence forte, instabilité du réseau intermédiaire.
Concrètement, un utilisateur susceptible de constater un effet mesurable est celui qui se connecte régulièrement à des serveurs hors d’Europe, ou qui travaille depuis des réseaux mobiles ou des connexions à faible qualité de service. Pour un usage gaming, les mêmes conditions s’appliquent : un joueur cherchant à améliorer la vitesse d’internet pour les jeux via un VPN ne bénéficiera du VPN Accelerator que si le routage VPN réduit effectivement la congestion sur son chemin réseau.
Ce qu’on ne peut pas vérifier indépendamment
Proton ne publie pas la méthodologie ayant produit le chiffre de 400 %. On ne dispose ni du RTT cible utilisé lors des tests, ni du taux de perte de paquets simulé, ni du protocole de référence, ni des serveurs impliqués. Le chiffre est vraisemblable dans des conditions adverses, les mécanismes décrits sont réels et documentés, mais il n’est pas reproductible de manière indépendante sans ces données.
Les techniques sous-jacentes (contrôle de congestion TCP, multi-process OpenVPN, tuning Linux) sont des pratiques connues et utilisées ailleurs dans l’industrie réseau. Ce que ce VPN gratuit PC a fait est les regrouper, les déployer à l’échelle de son infrastructure et les exposer sous un nom de fonctionnalité. L’affirmation de performance reste celle du fournisseur, pas une mesure tierce.
Le VPN Accelerator n’est ni un argument marketing vide, ni une promesse universelle. C’est un ensemble d’optimisations réelles, utiles surtout quand le réseau est déjà pénalisé par la distance, la congestion ou la perte de paquets. Proton mentionne eux-mêmes que le gain est moins perceptible sur serveur proche avec une connectivité parfaite, mais l’axe marketing reste « jusqu’à 400 % », sans que cette condition soit mise en avant au même niveau.
Comment constater, ou ne pas constater, l’effet
Un test de vitesse sur un serveur proche peut ne rien montrer : il minimise précisément la latence et masque les scénarios où Proton indique que le VPN Accelerator a le plus d’impact, distance, congestion, pertes. Le test le plus propre consiste à comparer dans des conditions strictement identiques : même serveur VPN, mêmes heures, même appareil, même destination, avec l’option activée puis désactivée (quand l’application le permet). La destination doit être réellement distante, et le transfert suffisamment long pour que le débit se stabilise. Sur une connexion locale stable, l’absence de différence mesurable est un résultat normal, pas un dysfonctionnement. Si le Wi-Fi local ou le routeur est le goulot, l’accelérateur VPN ne résout pas ce problème : il agit sur le transport et le traitement côté serveurs Proton, pas sur un réseau domestique en difficulté.
Sources
- VPN Accelerator (page fonctionnalité) : conditions d’activation, liste des protocoles supportés, claim « no real downsides ».
- Billet technique officiel 2021 : segmentation 600 ms → 2 × 300 ms, companion processes, known traffic, multi-process OpenVPN, stalls TCP pacing.
- Support (activation / désactivation) : procédure par plateforme.
- OpenVPN — Commonly Asked Technical Questions : « The OpenVPN 2 codebase operates on a single-thread, using one CPU core. »