Steam Deck après veille : le kill switch fonctionnait — c’était le tunnel qui ne revenait pas

Le kill switch fonctionnait parfaitement. J’ai mis presque vingt minutes à comprendre que c’était précisément mon problème.

J’étais dans une chambre d’hôtel, Steam Deck connecté au Wi-Fi et VPN actif. J’avais joué une quarantaine de minutes, appuyé une fois sur le bouton d’alimentation et posé la console à côté de moi.

Quand je l’ai réveillée un peu plus tard, le Wi-Fi est revenu. Steam, non.

La liste d’amis affichait une erreur de connexion. Le Store ne chargeait plus. Même une page web ordinaire restait bloquée.

J’ai fait ce qui me paraissait logique : Wi-Fi désactivé, Wi-Fi réactivé. Toujours rien.

En regardant le VPN, j’ai enfin vu la différence : le tunnel n’était plus actif, mais le kill switch, lui, l’était toujours.

J’ai immédiatement pensé à une configuration cassée. Un kill switch était censé me protéger lorsque le tunnel disparaissait, pas transformer chaque sortie de veille en panne Internet.

Cette distinction paraît évidente après coup.

Elle ne l’était absolument pas avec un Steam Deck dans les mains et quinze minutes avant de rejoindre quelqu’un en ligne.

La sortie de veille est justement un point sensible de SteamOS

Le timing rendait le diagnostic encore plus trompeur.

Le 28 août 2026, Valve a publié SteamOS 3.9.0 en canal Preview. Parmi les changements réseau, Valve a annoncé le passage par défaut à wpa_supplicant pour les nouvelles installations et l’ajout d’une reconnexion Wi-Fi rapide après une sortie de veille. Les installations existantes continuent pour l’instant d’utiliser iwd sauf changement manuel.

Ce détail m’intéressait moins comme nouveauté SteamOS que comme indice : Valve travaille elle-même sur ce moment très particulier où le Deck se réveille et doit retrouver son réseau proprement.

Et les utilisateurs savent à quel point ce moment peut mal se passer.

À la fin août 2026, un utilisateur de r/SteamDeck décrivait un Deck qui perdait le Wi-Fi à chaque réveil, lui faisait ressaisir son mot de passe et avait même accumulé plusieurs copies du même réseau dans les paramètres. Après plusieurs manipulations, il avait fini par revenir à une version précédente du système pour retrouver un comportement normal.

Cela m’a empêché de mettre immédiatement tout le problème sur le dos du VPN.

« Internet bloqué après veille » pouvait venir du Wi-Fi lui-même. Il fallait donc séparer les deux. J’ai temporairement désactivé le kill switch sans changer de réseau. Le Store s’est chargé immédiatement.

Steam est repassé en ligne. Le Wi-Fi n’était donc pas mort.

C’était presque vexant : le composant que j’accusais venait de me montrer qu’il faisait exactement son travail.

J’avais confondu bloquer une fuite et réparer le tunnel

Un kill switch n’est pas chargé de remettre le VPN debout.

Son rôle est plus ingrat : fermer la porte quand le tunnel disparaît, afin que le trafic ne sorte pas directement par la connexion normale.

La documentation Linux de Proton VPN illustre bien ce comportement. Son kill switch avancé bloque l’accès à Internet tant qu’aucune connexion VPN n’est active ; sous Linux, cette protection peut rester en place même lorsque le tunnel utilisable a disparu.

Et soudain, ce que je voyais n’avait plus rien d’étrange. Le Wi-Fi était revenu. Le tunnel, non. Le kill switch avait donc fermé la porte.

Internet restait bloqué.

Le problème n’était plus « pourquoi le kill switch m’empêche-t-il d’aller sur Internet ? »

C’était « pourquoi le tunnel n’est-il pas revenu avant que j’aie besoin d’Internet ? »

J’ai rouvert mon ancien montage VPN, relancé manuellement le profil et récupéré la connexion.

Donc oui, il existait un contournement.

Seulement, j’avais acheté un Steam Deck pour appuyer sur un bouton et reprendre une partie. Je me retrouvais à réparer une connexion Linux parce que j’avais posé la console vingt minutes.

Mon ancien VPN fonctionnait ; ma routine de réveil, non

Ce montage n’avait rien d’absurde.

Sur Steam Deck, un outil communautaire comme TunnelDeck permet d’utiliser depuis Gaming Mode des connexions OpenVPN ou WireGuard enregistrées dans NetworkManager. Le profil se configure d’abord en Desktop Mode, puis devient accessible dans le menu rapide du Deck.

C’est souple, et pour quelqu’un qui aime contrôler ses profils VPN, c’est même plutôt séduisant.

En temps normal, mon tunnel fonctionnait.

C’était la succession des événements qui me fatiguait :

je jouais ; je mettais le Deck en veille ; SteamOS réveillait le réseau ; le kill switch empêchait correctement le trafic de sortir sans protection ;

le tunnel, lui, ne revenait pas. Je pouvais toujours rouvrir le menu, relancer le profil et continuer. Puis refaire la même chose à la prochaine veille. Après quelques cycles, mon critère avait complètement changé.

Je ne cherchais plus un VPN avec un meilleur kill switch.

Je cherchais un VPN capable de se remettre en route avec la même obstination que son kill switch mettait à bloquer Internet.

J’ai arrêté de tester le débit et commencé à tester le bouton de veille

C’est à ce moment-là que j’ai ouvert OnlydogVPN. Je n’ai pas lancé de benchmark. Je n’ai pas cherché le pays qui me donnerait théoriquement quelques millisecondes de moins. Le problème était désormais beaucoup plus concret.

Je me suis connecté sur le même Wi-Fi d’hôtel. L’application a choisi automatiquement sa route, sans me renvoyer vers une liste de profils ou de serveurs. J’ai ensuite ouvert Steam, vérifié que le statut Cloud était revenu et lancé le jeu.

Puis j’ai appuyé sur le bouton d’alimentation. Écran noir. Dix minutes plus tard, j’ai réveillé le Deck. Le Wi-Fi est revenu.

J’ai attendu.

C’était normalement le moment où Steam passait hors ligne et où ma petite séance de dépannage commençait.

Cette fois, la liste d’amis s’est reconnectée. Le statut Cloud s’est actualisé. J’ai rouvert le jeu. Le menu en ligne était disponible.

Je n’avais pas quitté Gaming Mode. Je n’avais pas coupé le kill switch pour récupérer Internet. Je n’avais pas rouvert un profil VPN à la main.

Surtout, je n’avais plus à choisir entre garder la protection et rester hors ligne ou désactiver la protection pour recommencer à jouer immédiatement.

C’était exactement ce que j’attendais d’un VPN sur une console portable : que la veille reste une pause, pas le début d’un diagnostic réseau.

HTTP/3 expliquait enfin quelque chose que je pouvais voir

Le service utilise un transport basé sur HTTP/3, donc sur QUIC, ainsi qu’une logique de récupération pensée pour les réseaux faibles ou changeants.

Le nom du protocole m’importait assez peu avant ce problème. Après, il devenait plus facile à comprendre.

Une connexion classique peut ressembler à un trajet qui doit être reconstruit lorsque la route sous elle change. QUIC est conçu pour être moins attaché à un chemin réseau unique : il dispose notamment de mécanismes permettant à une connexion de continuer lorsqu’une adresse ou un chemin change, par exemple après une modification liée au réseau ou au NAT.

Cela ne signifie pas que QUIC, à lui seul, « répare la veille du Steam Deck ».

Mais associé à une application conçue pour récupérer lorsque le réseau disparaît puis revient, il correspond beaucoup mieux au problème que j’avais sous les yeux.

Je n’avais pas besoin d’en savoir davantage pour juger le résultat. Veille. Réveil. Tunnel revenu.

Steam en ligne. Je pouvais recommencer à jouer.

Le deuxième réveil comptait plus que le premier

Un réveil réussi ne m’aurait pas suffi. J’ai donc reposé le Deck. Connexion active. Veille.

Réveil. Steam est revenu derrière le tunnel. J’ai recommencé une troisième fois. Même résultat sur ces trois cycles.

Cette répétition a fini de changer ma manière de voir le kill switch.

Je continue à vouloir qu’un VPN bloque réellement le trafic lorsque sa protection disparaît. Sur ce point, rien n’avait changé.

Mais sur un Steam Deck, un kill switch rigoureux associé à un tunnel qui demande une intervention après chaque veille produit une expérience absurde : plus la protection fonctionne bien, plus le défaut de récupération devient pénible.

Le bon comportement ne pouvait donc plus se résumer à :

« si le VPN tombe, Internet est bloqué ».

Il fallait aussi :

« quand le Deck revient, le VPN revient avec lui ».

C’était la différence entre une fonction de sécurité que je pouvais laisser activée en permanence et une fonction que j’allais finir, par agacement, par désactiver.

Je garderais encore l’ancien montage pour ce qu’il fait mieux

Le petit service n’a pas tous les avantages d’un fournisseur historique.

Il propose moins de régions, son histoire publique est plus courte et il existe moins d’avis indépendants à consulter.

Si mon objectif était de choisir une destination inhabituelle, de conserver plusieurs profils WireGuard précis ou de construire une configuration Linux très personnalisée, NetworkManager et un fournisseur plus établi garderaient un intérêt évident.

TunnelDeck montre justement tout ce qu’on peut faire lorsque l’on veut traiter le Steam Deck comme le PC Linux qu’il est réellement.

Simplement, ce n’était plus le problème que j’essayais de résoudre. Je ne voulais pas davantage de contrôle après la sortie de veille. Je voulais avoir moins souvent besoin de ce contrôle. Au début, je pensais que mon kill switch était responsable du blocage d’Internet.

À la fin, je lui reprochais presque l’inverse : il faisait suffisamment bien son travail pour révéler que le tunnel, lui, n’avait pas suivi le réveil du Deck.

Le Wi-Fi pouvait revenir. Le kill switch pouvait rester actif.

Mais pour que le Steam Deck reste réellement une console que je pose et reprends quelques minutes plus tard, le tunnel devait être revenu avant que j’aie une raison d’ouvrir autre chose que mon jeu.