« Kill switch : oui. » C'est, la plupart du temps, tout ce qu'un comparatif de VPN vous dira sur cette fonctionnalité. Une case cochée dans un tableau, au même titre que le nombre de serveurs ou la couleur de l'application. Cette page part d'un principe différent : la présence d'un kill switch dans un menu de réglages n'est pas une preuve de protection, c'est une promesse qui reste à vérifier. Un kill switch mal implémenté peut afficher « activé » tout en laissant fuiter votre trafic pendant plusieurs secondes critiques, ou en ignorant complètement l'IPv6. La seule façon de savoir si le vôtre fonctionne réellement est de le tester dans des conditions contrôlées, pas de faire confiance à une case cochée.

Ce qu'un kill switch fait techniquement

Un kill switch VPN est un mécanisme qui coupe l'accès à Internet — ou l'accès d'applications spécifiques à Internet — dès que la connexion au tunnel VPN est perdue de manière inattendue. L'objectif est simple : empêcher que votre trafic continue de circuler en clair, avec votre adresse IP réelle exposée, pendant la fenêtre où le VPN n'est plus actif.

Il existe deux architectures principales. Le kill switch au niveau système bloque l'intégralité du trafic réseau de l'appareil dès qu'il détecte la coupure du tunnel, généralement en manipulant la table de routage ou les règles de pare-feu du système d'exploitation. Le kill switch au niveau application cible uniquement certains programmes désignés (un client torrent, un navigateur), en les empêchant d'émettre du trafic hors tunnel tout en laissant le reste de l'appareil fonctionner normalement. Les implications pratiques de ce choix d'architecture, et les erreurs d'implémentation les plus fréquentes selon le type retenu, sont détaillées sur notre page consacrée au kill switch système contre kill switch application.

Pourquoi « kill switch activé » ne garantit rien

C'est le point que la quasi-totalité des comparatifs VPN passent sous silence. Un kill switch peut être activé dans les réglages et pourtant échouer à protéger votre trafic, pour au moins quatre raisons techniques précises.

Premièrement, la fenêtre de reconnexion : entre le moment où le tunnel tombe et le moment où le kill switch réagit effectivement, il peut s'écouler une fraction de seconde à plusieurs secondes pendant lesquelles du trafic sort déjà en clair. Deuxièmement, le trafic IPv6 : un kill switch conçu uniquement pour surveiller la route IPv4 par défaut peut laisser passer intégralement le trafic IPv6 si le système d'exploitation en dispose, sans que rien ne l'indique à l'utilisateur. Troisièmement, les fuites DNS : la résolution de noms de domaine emprunte parfois un chemin réseau distinct de celui surveillé par le kill switch, ce qui signifie que la liste des sites visités peut continuer à être visible par un tiers même quand le trafic applicatif est bien bloqué. Quatrièmement, le blocage partiel : certaines implémentations n'empêchent que l'ouverture de nouvelles connexions, sans couper les connexions déjà établies au moment de la coupure, qui continuent alors à transmettre des données hors tunnel.

Ces quatre mécanismes sont approfondis, avec leur lien direct aux fuites DNS et IPv6 en particulier, sur la page fuites DNS et IPv6 : pourquoi un kill switch ne suffit pas toujours.

Un exemple concret illustre bien la fenêtre de reconnexion : un ordinateur portable connecté au Wi-Fi domestique bascule automatiquement sur le partage de connexion d'un téléphone lorsque le signal faiblit. Ce changement d'interface réseau force souvent le tunnel VPN à se reconstruire depuis zéro, et selon l'implémentation du client, plusieurs requêtes peuvent partir avant que le nouveau tunnel ne soit pleinement établi et que le kill switch ne reprenne le contrôle. Rien ne s'affiche d'anormal à l'écran pendant ce court intervalle ; c'est précisément ce qui le rend invisible sans test dédié.

Les scénarios qui déclenchent réellement un kill switch

Un kill switch n'est utile que dans la mesure où des coupures de tunnel se produisent effectivement. Cela arrive plus souvent qu'on ne le pense, pour des raisons rarement liées à un « mauvais » VPN : une connexion Internet instable ou un réseau public de mauvaise qualité, un changement de serveur VPN en cours de session, un redémarrage de l'appareil pendant lequel le tunnel n'est pas encore rétabli, un serveur VPN surchargé qui ferme les connexions, un fournisseur d'accès qui tente de détecter et bloquer le trafic VPN par inspection de paquets, ou encore un pare-feu et un antivirus local qui interfèrent avec le protocole utilisé.

Chacun de ces scénarios a des implications différentes sur la durée d'exposition et sur la probabilité de récidive. Le détail technique de chaque cause, avec ce que cela signifie concrètement pour la confidentialité de l'utilisateur, fait l'objet de notre page pourquoi un VPN se déconnecte : causes techniques et implications.

Comment vérifier vous-même que votre kill switch fonctionne

Vérifier un kill switch ne demande pas de compétences d'administrateur réseau, mais demande une méthode. Dans les grandes lignes : relevez votre adresse IP et votre résolveur DNS une fois connecté au VPN, puis forcez une coupure du tunnel de façon contrôlée (en fermant le processus du client VPN, en désactivant l'interface réseau, ou en bloquant artificiellement l'adresse du serveur VPN via le pare-feu du système), et observez si le trafic s'arrête réellement — navigateur compris — jusqu'au rétablissement de la connexion.

Le protocole complet, avec les quatre méthodes de déclenchement contrôlé et ce qu'il faut observer à chaque étape, est détaillé pas à pas sur la page tester un kill switch VPN : protocole de vérification étape par étape. C'est cette vérification, reproductible par n'importe qui, qui a de la valeur — pas l'affirmation d'un fournisseur.

Qui a vraiment besoin d'un kill switch

Toutes les situations ne justifient pas le même niveau d'exigence. Un utilisateur de logiciels pair-à-pair, un journaliste ou un chercheur manipulant des documents sensibles, un voyageur qui dépend fréquemment de réseaux publics, ou une personne vivant sous un régime qui restreint l'accès à Internet n'ont pas la même tolérance à une fenêtre d'exposition de quelques secondes qu'un utilisateur occasionnel cherchant simplement à éviter le profilage publicitaire. À l'inverse, activer un kill switch au niveau système sans discernement peut aussi créer des frictions inutiles, par exemple en bloquant une application bancaire qui déclenche des vérifications de sécurité supplémentaires lorsqu'elle détecte des changements fréquents d'adresse IP.

Une évaluation par profil de risque, plutôt qu'une recommandation universelle, est proposée sur la page qui a vraiment besoin d'un kill switch VPN ?.

Ce que la promesse marketing ne dit jamais

« Notre VPN est fiable à 100 %, testé et approuvé par notre équipe » est une phrase qu'on retrouve, sous une forme ou une autre, sur la quasi-totalité des sites qui recommandent un service VPN unique. Le problème n'est pas seulement qu'elle soit invérifiable pour le lecteur : c'est qu'elle remplace une méthode par une affirmation d'autorité. Un « test interne » non documenté, sans protocole reproductible, sans préciser sur quelle version du logiciel, quel système d'exploitation ou quel scénario de coupure il a été réalisé, n'a pas plus de valeur qu'une opinion.

Ce qui a une valeur réelle, c'est un protocole de test que vous pouvez reproduire vous-même, sur votre propre configuration, avec vos propres outils. C'est l'objectif de l'ensemble des pages listées ci-dessus : vous donner les moyens de vérifier plutôt que de vous demander de croire.

Une documentation technique crédible se reconnaît à des signes précis : elle indique sur quels systèmes d'exploitation et quelles versions le comportement a été vérifié, elle précise si le trafic IPv6 est couvert ou explicitement désactivé, elle explique ce qui se passe pendant la fenêtre de reconnexion plutôt que de l'ignorer, et elle ne prétend pas à une fiabilité absolue. À l'inverse, une page qui se contente d'un badge « kill switch inclus » sans description du comportement attendu ne vous donne aucune base pour évaluer si la fonctionnalité correspond à votre besoin réel.

Précisons aussi ce que cette page ne couvre pas : elle ne recommande aucun fournisseur en particulier, et elle ne prétend pas qu'un kill switch, aussi bien implémenté soit-il, suffit à garantir un anonymat complet. Il neutralise un risque précis — l'exposition du trafic pendant une coupure du tunnel — rien de plus, rien de moins. Le confondre avec une protection globale serait la même erreur de raisonnement que celle qui consiste à croire une promesse marketing sur parole.

Grille de vérification récapitulative

Avant de considérer qu'un kill switch vous protège réellement, vérifiez dans l'ordre :

  • Vous savez si votre kill switch est de niveau système ou de niveau application, et lequel correspond à votre besoin.
  • Vous avez testé une coupure contrôlée du tunnel et observé si le trafic s'arrête réellement, immédiatement.
  • Vous avez vérifié que la résolution DNS s'arrête également, pas seulement le trafic applicatif.
  • Vous avez vérifié le comportement du trafic IPv6 pendant la coupure, pas seulement l'IPv4.
  • Vous connaissez les scénarios de déconnexion les plus probables dans votre usage réel (réseau, redémarrage, changement de serveur).
  • Vous avez évalué si votre profil d'usage justifie un kill switch systématique ou un usage plus ciblé.

Un kill switch qui n'a jamais été testé dans ces conditions reste, au sens strict, une fonctionnalité non vérifiée — quelle que soit la réputation du fournisseur qui la propose.