Le glossaire VPN décrit le kill switch comme la fonctionnalité qui "tue" votre connexion Internet si le VPN tombe, pour éviter qu'un site ne découvre votre IP réelle. C'est juste, mais incomplet : il existe deux architectures très différentes derrière ce nom unique, avec des garanties et des angles morts distincts, et surtout, un kill switch affiché comme "activé" dans une interface n'est jamais une preuve suffisante qu'il fonctionne réellement.

Le kill switch au niveau système

Un kill switch système agit au niveau le plus bas de la pile réseau de l'appareil. Concrètement, il modifie la table de routage ou insère des règles de pare-feu qui interdisent tout trafic sortant en dehors de l'interface réseau virtuelle créée par le VPN. Tant que le tunnel est actif, cette règle est invisible : le trafic passe normalement par le VPN, qui est simplement devenu la seule route de sortie autorisée. Dès que le tunnel tombe, cette route disparaît, et comme aucune autre n'est autorisée, plus aucun paquet ne peut sortir de l'appareil, quelle que soit l'application à l'origine de la requête.

L'avantage est une couverture totale : cette approche protège aussi les processus système, les mises à jour automatiques, ou tout logiciel dont l'utilisateur ignorerait qu'il communique en arrière-plan. L'inconvénient est tout aussi net : l'intégralité de la connectivité de l'appareil est suspendue en cas de coupure, y compris pour des usages qui n'ont aucune raison de passer par le VPN.

Le kill switch au niveau application

Le kill switch au niveau application fonctionne différemment : au lieu de couper l'ensemble du trafic, il surveille des processus ou des applications spécifiquement désignés par l'utilisateur, et coupe uniquement leur accès réseau en cas de coupure du tunnel, en laissant le reste de l'appareil fonctionner normalement. Cette approche convient à un usage précis et identifié, par exemple protéger un client de partage de fichiers en pair à pair sans bloquer la navigation générale pendant les mêmes instants. Elle demande en contrepartie une configuration active : une application sensible oubliée dans la liste ne bénéficiera d'aucune protection en cas de coupure.

Pourquoi "activé" ne garantit rien

Un kill switch peut être activé dans les réglages et pourtant échouer à protéger le trafic, pour plusieurs raisons techniques précises. La première est 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. La deuxième concerne 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. La troisième touche aux connexions déjà établies au moment de la coupure : certaines implémentations n'empêchent que l'ouverture de nouvelles connexions, sans couper celles qui étaient déjà en cours, qui continuent alors à transmettre des données hors tunnel.

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

Un kill switch n'est utile que si des coupures de tunnel se produisent, ce qui arrive plus souvent qu'on ne le pense : 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, ou un pare-feu local qui interfère 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.

Protocole de vérification, étape par étape

Vérifier un kill switch demande une méthode, pas une confiance aveugle. Première méthode : forcez l'arrêt du processus du client VPN via le gestionnaire de tâches du système, plutôt que de cliquer sur le bouton de déconnexion normal, qui s'accompagne généralement d'un arrêt propre et contrôlé que le kill switch ne teste jamais. Immédiatement après, essayez de charger une page web : si elle se charge, même partiellement, le kill switch ne protège pas contre ce scénario précis.

Deuxième méthode : désactivez temporairement puis réactivez l'adaptateur réseau (Wi-Fi ou Ethernet) pendant que le VPN est connecté, pour simuler une coupure matérielle plutôt que logicielle. Observez si une fenêtre de quelques secondes permet au trafic de transiter avant que le tunnel ne soit pleinement rétabli.

Troisième méthode, plus précise : identifiez l'adresse IP du serveur VPN auquel vous êtes connecté, puis bloquez-la explicitement via le pare-feu natif de votre système, sans toucher au reste de la connectivité. C'est le test le plus proche d'une panne réelle côté fournisseur.

Pour chacune de ces méthodes, vérifiez systématiquement trois éléments, pas seulement le premier qui vient à l'esprit : l'adresse IP publique a-t-elle été exposée, même brièvement ; les requêtes de résolution DNS ont-elles continué à transiter par le résolveur habituel ; et le trafic IPv6, s'il existe sur votre connexion, est-il resté joignable pendant que l'IPv4 était bloquée.

Comment choisir entre les deux architectures

Si votre objectif est une protection globale sans exception, le niveau système reste la garantie la plus solide, au prix d'une interruption complète de la connectivité en cas de coupure. Si votre usage nécessite une continuité pour certains flux réseau pendant que d'autres doivent impérativement rester protégés, le niveau application est plus adapté, à condition de maintenir la liste des applications surveillées à jour. Certains fournisseurs proposent les deux niveaux simultanément, ce qui offre le meilleur compromis sur le papier, sans dispenser de vérifier que chacun des deux mécanismes fonctionne réellement, indépendamment l'un de l'autre.

Une contrainte supplémentaire sur mobile

Sur ordinateur, les deux architectures sont généralement réalisables avec un niveau de contrôle comparable, parce que le système d'exploitation autorise un accès relativement large à la configuration réseau. Sur smartphone, la situation est plus contrainte : iOS et Android imposent un modèle de sandboxing strict qui limite la capacité d'une application tierce à surveiller ou interrompre le trafic d'une autre application. Un kill switch au niveau application y est donc souvent plus limité dans sa granularité réelle qu'annoncé, tandis qu'un kill switch système, qui peut s'appuyer sur les API de VPN natives du système, se révèle généralement plus fiable sur mobile que son équivalent applicatif.

Faux positifs et faux négatifs à éviter

Deux erreurs de lecture faussent régulièrement ces tests. La première consiste à conclure trop vite qu'un kill switch fonctionne parce qu'une seule page ne s'est pas chargée : certains navigateurs affichent des pages en cache ou des erreurs génériques qui ressemblent à un blocage réussi sans en être la preuve réelle — vérifiez toujours l'adresse IP effective plutôt que la simple impossibilité apparente de naviguer. La seconde consiste à tester une seule fois puis à généraliser : un kill switch peut réagir correctement neuf fois sur dix et échouer sur un cas de figure précis, notamment lors d'un changement rapide et répété de réseau. Répéter chaque méthode à plusieurs reprises réduit ce risque de conclusion prématurée.

Le lien avec les fuites DNS et WebRTC

Un kill switch répond à une question précise : que se passe-t-il quand le tunnel tombe complètement ? Il ne répond pas à une autre question tout aussi importante : est-ce que la totalité du trafic passe bien par le tunnel tant que celui-ci reste actif ? Un VPN peut exceller sur le premier point et être défaillant sur le second, notamment via les fuites DNS et WebRTC, qui se produisent alors même que le kill switch n'a aucune raison de se déclencher. Évaluer un VPN sur un seul de ces deux axes laisse un angle mort dans l'appréciation de sa fiabilité réelle.

Ce qu'il faut retenir

Un kill switch mérite d'être vérifié, pas supposé fonctionnel parce qu'une case est cochée dans les réglages. La distinction entre niveau système et niveau application détermine ce qu'il couvre réellement, et le protocole de test décrit ci-dessus, reproductible en quelques minutes sur n'importe quel appareil, reste la seule façon fiable de savoir si votre configuration actuelle vous protège comme vous le pensez.