Ce dossier détaille le quatrième critère de la grille d'évaluation d'un VPN présentée sur ce site : les éléments techniques qui déterminent la sécurité effective d'un service, souvent réduits à la seule mention d'un algorithme de chiffrement sur une page de vente.

Les protocoles courants et leurs différences pratiques

Le protocole est le langage technique par lequel votre appareil et le serveur VPN établissent et maintiennent une connexion chiffrée. OpenVPN, longtemps considéré comme la référence du secteur, reste largement audité et éprouvé, au prix de performances parfois inférieures à des alternatives plus récentes. WireGuard, plus récent, repose sur une base de code volontairement réduite, plus simple à auditer intégralement, et affiche généralement de meilleures performances, en particulier lors des changements de réseau fréquents sur mobile. IKEv2, enfin, se distingue par sa capacité à rétablir rapidement une connexion après une interruption, ce qui en fait un choix pertinent pour un usage mobile où les changements de réseau sont fréquents. Aucun de ces trois protocoles n'est intrinsèquement défaillant lorsqu'il est correctement implémenté ; leurs différences résident surtout dans leurs compromis respectifs entre performance, simplicité d'audit et compatibilité avec les usages mobiles. Un protocole propriétaire, développé en interne par un fournisseur et non publié pour un examen externe, mérite en revanche une prudence particulière : sans code source accessible ni possibilité d'audit indépendant par la communauté de sécurité informatique, l'utilisateur doit se contenter des affirmations du fournisseur lui-même sur sa propre robustesse, une situation qui inverse la charge de la preuve par rapport à un protocole ouvert et largement étudié par des chercheurs extérieurs à l'entreprise qui le déploie.

Le chiffrement AES-256 ne fait pas tout

La mention « chiffrement AES-256 » revient sur la quasi-totalité des pages de vente de VPN, à tel point qu'elle a perdu une grande partie de sa valeur distinctive. Ce standard de chiffrement, effectivement robuste et largement reconnu dans le secteur de la sécurité informatique, ne dit rien à lui seul de la façon dont les clés de chiffrement sont générées, échangées et renouvelées au cours d'une session, ni de la qualité de l'implémentation logicielle qui l'utilise. Un chiffrement théoriquement solide, mal implémenté ou combiné à un échange de clés défaillant, peut être compromis par des failles qui n'ont rien à voir avec la robustesse de l'algorithme lui-même. C'est pourquoi le protocole utilisé et la qualité de son implémentation comptent au moins autant, sinon davantage, que le seul nom de l'algorithme de chiffrement mis en avant en gros caractères sur une page de vente.

Le kill switch, une fonction à tester plutôt qu'à croire sur parole

Le kill switch coupe l'accès à internet dès que la connexion VPN se rompt de façon inattendue, empêchant que du trafic transite en clair sans protection le temps d'une reconnexion. Sa présence dans la liste des fonctionnalités affichées ne garantit pas son bon fonctionnement en conditions réelles : certaines implémentations laissent passer une brève fenêtre de trafic non protégé au moment précis de la coupure, ou ne couvrent que certaines applications plutôt que l'ensemble du trafic système. Le tester soi-même reste simple : couper manuellement la connexion VPN en pleine navigation, puis observer si l'accès à internet est effectivement bloqué ou continue silencieusement en clair sans que l'utilisateur ne s'en aperçoive.

Fuites DNS et IPv6 : les failles les plus fréquentes

Une fuite DNS survient lorsque les requêtes de résolution de noms de domaine continuent de passer par les serveurs DNS de votre fournisseur d'accès habituel plutôt que par ceux du VPN, révélant ainsi les sites que vous consultez malgré une connexion par ailleurs chiffrée. Une fuite IPv6 pose un problème similaire : si le VPN ne gère correctement que le trafic IPv4 et laisse passer le trafic IPv6 en clair sur un réseau qui le prend en charge, votre adresse IPv6 réelle reste visible malgré la protection apparente. Ces deux failles, plus fréquentes qu'on ne l'imagine sur des applications mal conçues, se testent facilement à l'aide d'outils de vérification gratuits disponibles en ligne, à utiliser une fois la connexion VPN établie pour confirmer qu'aucune de ces deux fuites ne se produit dans votre configuration spécifique.

Split tunneling : pratique, mais à utiliser avec discernement

Le tunnelage fractionné (split tunneling) permet de choisir quelles applications passent par le VPN et lesquelles utilisent la connexion directe, une fonctionnalité utile pour préserver de la bande passante ou accéder simultanément à des ressources locales et à des ressources protégées par le VPN. Cette flexibilité a un revers : chaque application exclue du tunnel redevient exposée exactement comme si aucun VPN n'était actif, ce qui peut créer un faux sentiment de protection globale si l'utilisateur oublie quelles applications précises il a choisi d'exclure du tunnel chiffré au moment de la configuration initiale. Revoir périodiquement la liste des applications exclues, en particulier après l'installation d'une nouvelle application sensible sur le même appareil, évite qu'une exclusion pertinente au moment de sa création ne devienne, avec le temps, une exposition oubliée et non intentionnelle.

Comment tester ces éléments vous-même

La plupart de ces vérifications ne demandent aucune compétence technique poussée : des outils de test gratuits, accessibles depuis n'importe quel navigateur, permettent de vérifier en quelques minutes l'absence de fuite DNS ou IPv6 une fois la connexion VPN établie, et de confirmer que l'adresse IP affichée correspond bien à celle du serveur VPN plutôt qu'à votre adresse réelle. Répéter ce test sur plusieurs serveurs différents proposés par un même fournisseur, plutôt qu'une seule fois sur un seul serveur, permet également de vérifier que la protection reste cohérente sur l'ensemble de l'infrastructure plutôt que sur un seul point testé isolément. Il est également utile de répéter ce même test à intervalles réguliers après l'installation initiale plutôt qu'une seule fois : une mise à jour de l'application, un changement de configuration réseau sur votre appareil, ou une modification silencieuse de l'infrastructure du fournisseur peuvent réintroduire une fuite qui n'existait pas lors du premier test, sans qu'aucune notification ne vous en informe spontanément.

Ce qui reste hors de portée d'un protocole, même parfaitement sécurisé

Un protocole irréprochable et une implémentation sans faille protègent le trafic en transit, mais ne remplacent aucun des critères de juridiction et de politique de journaux détaillés dans ce dossier complémentaire : un fournisseur qui chiffre parfaitement votre trafic tout en conservant des journaux détaillés de votre activité offre, dans les faits, une protection largement illusoire. Les critères techniques et les critères de confiance institutionnelle se complètent ; aucun des deux ne suffit isolément à garantir une protection réellement complète. Évaluer un fournisseur uniquement sur ses éléments techniques, aussi solides soient-ils, en ignorant sa juridiction et sa politique réelle de conservation des données, revient à vérifier la solidité d'une serrure sans se demander qui détient un double des clés.