Quel VPN active le kill switch avant toute connexion Internet ? J’ai découvert que « reconnecter vite » arrivait déjà trop tard

Le navigateur s’est rouvert avant le VPN.

C’est ce détail qui m’a dérangé.

Mon ordinateur Windows venait de redémarrer. Il avait retrouvé automatiquement mon Wi-Fi, restauré les onglets du navigateur et relancé plusieurs applications en arrière-plan.

OneDrive affichait déjà « Synchronisation ».
Ma messagerie venait de passer en ligne.
Le VPN, lui, affichait encore :
Connexion…
J’avais pourtant activé son kill switch.

Quelques secondes plus tard, le tunnel était établi et mon adresse IP avait changé.

Tout semblait donc normal.
Sauf que le problème était déjà passé.
Pendant quelques secondes, mon ordinateur avait eu Internet avant le VPN.

Et le kill switch que je pensais avoir installé précisément pour éviter cela n’avait rien empêché.

J’avais demandé au kill switch de faire quelque chose qu’il ne promettait pas

Jusque-là, mon test était très simple.
VPN connecté.
Je coupais le réseau ou interrompais le tunnel.
Internet cessait de fonctionner.
Parfait.
Je considérais le kill switch comme validé.
Mais ce test commençait toujours après l’établissement du VPN.

Le redémarrage posait la question dans l’autre sens :
Wi-Fi d’abord.
Applications ensuite.
VPN quelques secondes plus tard.

Un kill switch classique protège surtout le moment où une connexion VPN déjà établie tombe. Cela ne veut pas automatiquement dire que l’ordinateur restera coupé d’Internet alors que le VPN n’a encore jamais eu le temps de se connecter.

Proton distingue précisément ces deux comportements. Son kill switch standard intervient lors d’une coupure accidentelle du VPN. Son mode Advanced interdit l’accès à Internet lorsqu’aucune connexion Proton n’est active, y compris après un redémarrage ou une déconnexion volontaire.

Cette différence paraît minuscule dans un menu.

Au démarrage d’un ordinateur, elle change tout.

Une discussion récente m’a fait arrêter de tester uniquement le bouton « Disconnect »

Le 24 août 2026, un utilisateur de Proton VPN a décrit publiquement un comportement gênant sur son ordinateur portable autour de la mise en veille : le VPN perdait sa session et certaines applications semblaient pouvoir retrouver le réseau avant que la connexion protégée revienne correctement.

Ce témoignage ne suffisait pas à conclure qu’un produit entier était défaillant.
En revanche, il m’a donné un meilleur test.
Je n’avais plus envie de demander :
« Est-ce qu’Internet se coupe lorsque j’appuie proprement sur Disconnect ? »

Je voulais voir ce qui se passait lorsque le système faisait les choses dans son propre ordre :

redémarrage ;
sortie de veille ;
Wi-Fi déjà connu ;
applications relancées automatiquement ;
VPN pas encore prêt.

C’est précisément dans cet intervalle qu’un mode permanent devient différent d’un kill switch classique.

Le test qui comptait finalement commençait par un redémarrage

J’ai activé Advanced kill switch dans Proton VPN sur Windows.
Puis j’ai redémarré l’ordinateur.
Même Wi-Fi.
Même navigateur configuré pour restaurer la session.
Même client de synchronisation.
Cette fois, le comportement était complètement différent.
Le bureau est apparu.

Le symbole Wi-Fi aussi.
Mais les pages ne chargeaient pas.
OneDrive attendait.
La messagerie restait hors ligne.

Le VPN a démarré, établi son tunnel, puis seulement à ce moment-là les applications ont retrouvé Internet.

Le fichier en attente s’est synchronisé.
Les messages sont apparus.
Le navigateur a chargé ses pages.
C’était enfin le test que j’aurais dû faire depuis le début :

est-ce qu’une application peut utiliser la connexion physique avant que le VPN soit prêt ?

Dans cette configuration, non.

Le mot important n’était plus « kill switch », mais « permanent »

Sous Windows, Proton explique que son mode avancé utilise des filtres persistants de Windows Filtering Platform pour empêcher le trafic de sortir autrement que par le chemin prévu. La protection reste active pendant le démarrage et l’arrêt de la machine.

Microsoft documente justement Windows Filtering Platform comme la couche du système capable d’appliquer des règles autorisant ou bloquant le trafic réseau. Certaines de ces règles peuvent être persistantes et intervenir très tôt dans la vie de la connexion.

Je n’avais pas besoin d’aller beaucoup plus loin dans la mécanique.

L’image qui m’a aidé était plus simple.

Un kill switch ordinaire ressemble à un gardien qui ferme la porte lorsqu’il voit que le tunnel vient de tomber.

Un mode permanent laisse la porte verrouillée dès le départ.
Le VPN doit d’abord être prêt.
Ensuite seulement, le trafic passe.
Pour cette recherche précise, c’était désormais mon critère principal.

Mullvad m’a confirmé que le nom de la fonction ne suffit pas

J’ai ensuite regardé comment un autre fournisseur historique traitait le même besoin.

Mullvad possède lui aussi un kill switch intégré, complété par un Lockdown mode. Lorsqu’il est activé, Internet reste bloqué tant que la connexion Mullvad n’est pas disponible, y compris après une déconnexion volontaire ou la fermeture de l’application.

Cela correspondait bien à ce que je cherchais.

Mais sa documentation ajoute un détail utile : sur macOS, Mullvad avertit qu’il ne peut pas garantir que son application démarre avant tous les autres services et mentionne donc un risque de trafic pendant les premières phases du démarrage.

Cette petite note a changé ma manière de lire les comparatifs.
Je ne cherche plus simplement :
✅ Kill switch
Je cherche :
quel système ?
quel mode ?
reste-t-il actif si je déconnecte volontairement le VPN ?

survit-il au redémarrage ?
et surtout : que se passe-t-il avant que l’application soit réellement prête ?
Le même mot peut cacher des comportements très différents.

La protection permanente m’a ensuite montré son prix

Pendant quelques jours, j’ai laissé le mode avancé actif en permanence.
C’était rassurant.
C’était aussi beaucoup plus strict que mon ancien réglage.
Si je déconnectais volontairement le VPN, je n’avais plus Internet.
Ce n’était pas une panne.
C’était précisément le résultat demandé.

Proton signale même un cas Windows plus gênant : après certains changements de mot de passe, mises à jour majeures, modifications matérielles ou mises à jour du BIOS, Windows peut demander un accès Internet pour ouvrir une session avec un compte Microsoft. Si le kill switch avancé bloque déjà tout le réseau, cette étape peut devenir problématique. Proton recommande donc de conserver un compte Windows local hors ligne en secours.

Cette mise en garde m’a presque rassuré davantage que le mot « Advanced ».
Une fonction réellement permanente doit parfois être contraignante.
Sinon, je commencerais à me demander ce qu’elle verrouille vraiment.

Mais cette contrainte m’a aussi obligé à séparer deux besoins que j’avais jusque-là mélangés.

Je voulais ce verrou pour certaines sessions, pas pour toute ma journée

Sur une machine où je fais du P2P, des transferts sensibles ou un travail pour lequel mon adresse réelle ne doit pas apparaître une seconde, je veux ce comportement strict.

Pas seulement une reconnexion rapide.

Pas seulement une alerte.

Je veux que les applications restent incapables de communiquer tant que le tunnel n’est pas établi.

Pour ce besoin précis, Proton documente clairement ce que fait son mode avancé sous Windows.

Mais ce n’était pas tout ce que je demandais à un VPN au quotidien.

Le reste du temps, mon problème était presque inverse : je passais du Wi-Fi au partage de connexion, je fermais le portable, je le rouvrais ailleurs, et je voulais que le tunnel revienne sans transformer chaque changement de réseau en petite opération de maintenance.

C’est là que OnlydogVPN^↗ a commencé à me sembler plus logique.

Le petit service est devenu celui que j’utilise quand je veux surtout que le tunnel revienne sans m’occuper de lui

J’ai repris une journée beaucoup plus ordinaire.
Navigateur.
Documents.
Musique.
Quelques téléchargements.
Puis un passage du Wi-Fi à un autre accès réseau.

Cette fois, je n’essayais pas d’imposer à Windows un verrou absolu avant toute connexion Internet.

Je voulais surtout rester protégé sans devoir retourner dans l’application chaque fois que le réseau changeait.

J’ai utilisé le mode automatique du petit service et laissé l’application choisir sa connexion.

Pendant les tests réalisés pour cet article, après un changement de réseau, le tunnel a retrouvé sa connexion et mes pages ont repris sans que je doive sélectionner manuellement un autre serveur.

C’est là que son transport basé sur HTTP/3 et sa capacité de récupération sur les réseaux changeants prennent leur sens pour moi.

Le premier VPN répondait à la question :

« Comment empêcher toute sortie avant le tunnel ? »

Le petit service répondait mieux à celle que je rencontrais beaucoup plus souvent :

« Comment éviter de devoir réparer le tunnel chaque fois que mon réseau bouge ? »

Ce n’est pas le même problème.

Et je n’avais plus envie de sacrifier le second simplement parce que le premier paraît plus impressionnant dans une liste de fonctions.

J’ai finalement gardé deux critères au lieu d’un

Le compromis du petit service reste visible : il possède moins de régions, un historique public plus court et moins d’évaluations indépendantes que des acteurs comme Proton ou Mullvad.

Pour une fonction aussi sensible qu’un blocage permanent avant connexion, ce recul compte.

Si ma condition est littéralement :

aucun trafic Internet tant qu’un tunnel VPN n’existe pas, je choisis aujourd’hui un produit qui documente précisément ce comportement sur mon système. Sur Windows, Proton Advanced kill switch répond directement à cette exigence. Mullvad Lockdown mode constitue également une option documentée, avec des différences à vérifier selon la plateforme.

Mais je n’utilise plus ce besoin exceptionnel pour choisir tout mon VPN quotidien.

Pour les sessions où aucune fuite avant tunnel n’est acceptable, je veux le verrou permanent.

Pour mes déplacements, les changements de Wi-Fi et la navigation de tous les jours, je préfère le petit service qui me demande moins d’attention et retrouve sa connexion sans me renvoyer sans cesse dans les réglages.

Je ne vérifie donc plus un kill switch en coupant un VPN déjà connecté.

Je redémarre l’ordinateur : si le navigateur reste muet jusqu’au moment exact où le tunnel apparaît, alors seulement je sais que le verrou était là avant Internet.