Sur la page consacrée au principe général du kill switch VPN, on distingue rapidement deux architectures : le niveau système et le niveau application. Cette distinction est souvent réduite à une ligne dans un tableau comparatif, alors qu'elle correspond à deux mécanismes techniques réellement différents, avec des garanties, des limites et des cas d'usage distincts. Comprendre cette différence permet de choisir la bonne configuration plutôt que de subir celle qui est activée par défaut.
Un kill switch système agit au niveau le plus bas possible 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 route n'est autorisée, plus aucun paquet ne peut sortir de l'appareil, quelle que soit l'application à l'origine de la requête.
Cette approche a un avantage évident : elle ne dépend pas de la liste des applications installées, elle protège tout, y compris les processus système eux-mêmes, les mises à jour automatiques, les notifications, ou tout logiciel dont l'utilisateur ignorerait qu'il communique en arrière-plan. C'est la garantie la plus large possible.
Elle a aussi un coût : l'intégralité de la connectivité de l'appareil est suspendue, y compris pour des usages qui n'ont aucune raison de passer par le VPN. Une visioconférence professionnle utilisant un outil interne à l'entreprise, une synchronisation cloud légitime, ou simplement la consultation d'un site qui ne pose aucun problème de confidentialité particulier seront interrompues de la même manière qu'un client torrent. Pour un usage occasionnel, cette rigueur n'est pas un problème. Pour un usage professionnel quotidien avec de multiples flux réseau simultanés, elle peut devenir une source de friction récurrente.
Le kill switch au niveau application fonctionne différemment : au lieu de couper l'ensemble du trafic de l'appareil, il surveille des processus ou des applications spécifiquement désignés par l'utilisateur, et coupe uniquement leur accès réseau — ou les ferme entièrement — en cas de coupure du tunnel. Le reste de l'appareil continue de fonctionner sans interruption.
Cette approche convient particulièrement à un usage précis et identifié : protéger un client de partage de fichiers en pair à pair pour qu'il ne divulgue jamais l'adresse IP réelle de l'utilisateur, sans pour autant bloquer la navigation générale ou les outils professionnels pendant les mêmes instants. Elle demande en contrepartie une configuration active : l'utilisateur doit lui-même désigner quelles applications sont concernées, ce qui suppose une compréhension correcte de son propre modèle de risque. Une application sensible oubliée dans la liste ne bénéficiera d'aucune protection en cas de coupure.
Techniquement, cette variante repose généralement sur une surveillance au niveau du processus (identification du programme émetteur du trafic) combinée à des règles de pare-feu ciblées, plutôt que sur une modification globale de la table de routage. Cela la rend plus légère à l'usage, mais aussi plus dépendante de la qualité d'implémentation du logiciel VPN : une erreur dans la détection du processus, un contournement via une bibliothèque réseau non surveillée, ou un simple bug peuvent laisser passer du trafic que l'utilisateur croyait protégé.
Quelle que soit l'architecture retenue, plusieurs erreurs reviennent régulièrement chez les fournisseurs qui n'ont pas soigné cette fonctionnalité. La première est un délai de réaction trop long : le mécanisme de détection de la coupure n'est vérifié qu'à intervalles réguliers plutôt qu'en continu, ce qui crée une fenêtre d'exposition même quand le kill switch finit par se déclencher correctement. La seconde est l'absence de prise en compte de l'IPv6 : un kill switch système conçu avant la généralisation de l'IPv6, ou mal mis à jour, peut ne bloquer que la route IPv4 par défaut et laisser passer intégralement un trafic IPv6 natif.
La troisième erreur concerne le comportement au démarrage de l'appareil : si le kill switch ne s'active qu'une fois l'application VPN lancée manuellement, tout trafic émis entre le démarrage du système et le lancement de l'application échappe totalement à la protection, alors même que l'utilisateur pense être protégé dès l'allumage. La quatrième, plus subtile, concerne les connexions déjà établies au moment de la coupure : certaines implémentations n'empêchent que l'ouverture de nouvelles connexions sans interrompre celles qui étaient déjà en cours, ce qui peut laisser un flux de données continuer à transiter hors tunnel pendant un temps non négligeable.
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 tous deux 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é, et repose davantage sur les API réseau exposées par le système que sur un contrôle direct. Un kill switch système, en revanche, peut généralement s'appuyer sur les API de VPN natives du système d'exploitation, ce qui le rend souvent plus fiable sur mobile que son équivalent applicatif. Cette asymétrie mérite d'être gardée en tête si votre usage principal se fait sur téléphone plutôt que sur ordinateur.
Le choix ne devrait pas se limiter à celle proposée par défaut. Si votre objectif est une protection globale sans exception, sans avoir à réfléchir à la liste des applications concernées, 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 et de comprendre que cette liste constitue, de fait, le périmètre exact de votre protection.
Certains fournisseurs proposent les deux niveaux simultanément, avec une protection système comme filet de sécurité et une granularité applicative en complément. Cette combinaison offre le meilleur compromis sur le papier, mais elle ne dispense pas de vérifier que chacun des deux mécanismes fonctionne réellement, indépendamment l'un de l'autre. La méthode pour effectuer cette vérification, avec des scénarios de coupure contrôlée reproductibles, est détaillée sur notre page tester un kill switch VPN : protocole de vérification étape par étape.
Comprendre la différence entre ces deux architectures transforme la question posée à un fournisseur de VPN. Plutôt que de demander « avez-vous un kill switch ? », la question pertinente devient : « votre kill switch agit-il au niveau système, au niveau application, ou propose-t-il les deux ? Quel est le délai de détection d'une coupure ? Le trafic IPv6 est-il couvert ? Que se passe-t-il pour les connexions déjà établies au moment de la coupure ? » Ce sont ces réponses, documentées et vérifiables, qui distinguent une fonctionnalité de sécurité réellement pensée d'un argument commercial ajouté après coup.