VPN sur Steam Deck : faire survivre le profil NetworkManager au passage en mode Jeu

J’avais déjà considéré l’installation comme réussie.

En mode Bureau sur mon Steam Deck, j’avais importé le profil VPN dans NetworkManager, saisi les identifiants, appuyé sur « Connecter » et vérifié mon adresse IP.

Elle avait changé.

Parfait.

J’ai donc posé le clavier Bluetooth, ouvert le menu Steam et choisi « Revenir au mode Jeu ».

Quelques secondes plus tard, j’ai lancé le jeu que je voulais utiliser pendant un déplacement le lendemain.

Pas de VPN.

Je suis retourné dans les réglages réseau. Le Wi-Fi était bien connecté, mais la connexion que je venais de tester semblait avoir disparu.

Retour en mode Bureau.

Le profil était toujours là.

Connexion.

Ça marche.

Retour en mode Jeu.

Plus rien d’utile.

Au bout du troisième aller-retour, j’étais convaincu que SteamOS traitait ses deux interfaces comme deux machines différentes.

L’explication paraissait logique.

Elle m’envoyait pourtant dans la mauvaise direction.

Le profil n’avait pas disparu

Le contexte actuel n’aide pas vraiment à faire confiance à son premier diagnostic. Le 28 août 2026, Valve a publié SteamOS 3.9.0 Preview avec une nouvelle base Arch Linux, une mise à jour importante de Plasma et, pour les nouvelles installations, un changement du backend Wi-Fi vers wpa_supplicant. Valve prévient elle-même qu’une version Preview peut encore produire des comportements inattendus.

J’aurais donc facilement pu mettre mon problème sur le compte d’une mise à jour.

Mais NetworkManager fonctionne justement avec des profils de connexion persistants. Avec son format keyfile, les profils système peuvent être enregistrés dans /etc/NetworkManager/system-connections/. Ils ne disparaissent pas simplement parce qu’on ferme le bureau Plasma.

C’est là que mon raisonnement a changé.

Le profil VPN ressemblait moins à une application laissée ouverte sur le Bureau qu’à une fiche de connexion rangée dans le système. Elle était encore là en mode Jeu.

La vraie question était de savoir si tout ce dont cette fiche avait besoin avait voyagé avec elle.

Un utilisateur de Steam Deck qui cherchait à contrôler une connexion WireGuard depuis le mode Jeu avait d’ailleurs rencontré cette même séparation: ses connexions NetworkManager survivaient bien au passage d’un environnement à l’autre; le problème était surtout de pouvoir les activer proprement sans revenir sur le Bureau.

Je ne cherchais donc plus:

« Pourquoi mon profil disparaît-il ? »

mais:

« Qu’est-ce que ce profil attend encore du mode Bureau pour réussir à se connecter ? »

Le profil avait voyagé. Son mot de passe, moins bien.

La réponse se trouvait dans une option que j’avais presque ignorée pendant l’importation.

NetworkManager ne conserve pas forcément tous les secrets d’une connexion de la même manière. Un mot de passe peut être accessible au système, mais il peut aussi être marqué comme appartenant à un « agent de secrets » de la session utilisateur. Dans ce cas, lorsque la connexion a besoin du mot de passe, elle doit demander à cet agent de le fournir.

En mode Bureau, je ne voyais rien de tout cela.

Je cliquais.

Plasma avait accès à ma session.

Le secret arrivait.

Le tunnel montait.

Puis je passais en mode Jeu en pensant avoir emporté toute la connexion.

En réalité, j’avais emporté la fiche, mais laissé une partie des clés au vestiaire.

Cette distinction explique pourquoi le profil peut rester parfaitement visible dans NetworkManager tout en refusant de fonctionner depuis un autre contexte.

TunnelDeck, le plugin communautaire conçu pour rendre des connexions OpenVPN et WireGuard de NetworkManager accessibles depuis le mode Jeu, documente précisément ce cas. Pour les connexions utilisant un nom d’utilisateur et un mot de passe, son installation demande de choisir « Store password for all users (not encrypted) », notamment parce que TunnelDeck déclenche la connexion en tant que root.

J’ai rouvert mon profil.

C’était bien ça.

Le mot de passe dépendait de ma session utilisateur.

J’ai changé son mode de stockage.

Retour en mode Jeu.

Cette fois, le profil s’est activé.

J’ai lancé le navigateur ajouté à Steam et vérifié mon adresse.

Le VPN était bien là.

Le problème était résolu.

Ou, plus exactement, j’avais résolu le premier problème en découvrant que je venais d’en créer un second.

Faire fonctionner le profil demandait maintenant de choisir où laisser le secret

« Stocker pour tous les utilisateurs » semble assez anodin dans une boîte de dialogue.

En pratique, NetworkManager autorise les profils système à contenir leurs secrets directement dans leurs fichiers de connexion. Ces fichiers sont protégés par des permissions strictes et ne sont pas accessibles à un utilisateur ordinaire, mais le compromis reste différent d’un secret conservé par l’agent de la session Bureau.

Sur un PC fixe, je n’y aurais probablement pas pensé très longtemps.

Sur une console portable que je mets en veille, que je branche sur des docks et que je transporte partout, j’y ai pensé.

Surtout parce que mon ambition de départ était ridiculement simple:

configurer le VPN une fois et jouer.

Je me retrouvais à choisir entre un secret lié à la session Plasma et un secret disponible au niveau système pour qu’un autre processus puisse monter le tunnel depuis le mode Jeu.

Et le plus intéressant, c’est que NetworkManager pouvait parfaitement aller dans l’autre sens: devenir trop persistant.

En avril 2026, un rapport publié sur le tracker SteamOS décrivait un profil WireGuard mal configuré, importé depuis le mode Bureau, qui continuait à être utilisé au point de provoquer de longues attentes au démarrage et sur « Logging in… ». L’utilisateur devait finalement couper le réseau et désactiver manuellement la connexion virtuelle.

À ce stade, j’avais cessé de voir mon problème comme « un VPN qui ne marche pas sur Steam Deck ».

Il marchait.

Le vrai problème était que je devais désormais comprendre qui possédait le profil, qui possédait son secret et sous quel utilisateur la connexion serait lancée.

Pour une machine que j’avais achetée précisément parce qu’elle transforme un PC Linux en console, c’était beaucoup de plomberie pour simplement garder un tunnel actif.

J’ai arrêté d’essayer de perfectionner le profil

J’aurais pu m’arrêter là.

Mon fournisseur habituel avait une longue histoire publique, beaucoup de régions disponibles et suffisamment de documentation pour continuer à ajuster NetworkManager après une mise à jour.

Une fois son secret stocké de la bonne manière, il fonctionnait en mode Jeu.

Mais mon installation reposait maintenant sur plusieurs pièces:

le profil du fournisseur, NetworkManager, la manière dont ses secrets étaient stockés et le plugin qui rendait la connexion manipulable depuis l’interface Steam.

Chaque pièce était raisonnable.

C’était l’ensemble que je n’avais plus envie d’administrer.

Je voulais que le Steam Deck redevienne une console.

C’est à ce moment-là que j’ai essayé OnlydogVPN^↗.

Je n’ai pas importé de fichier .ovpn.

Je n’ai pas recréé de profil NetworkManager.

Je n’ai pas eu à décider si un mot de passe devait appartenir à Plasma ou rester disponible pour root, parce que l’utilisation de base du service ne repose pas sur le traditionnel couple adresse e-mail/mot de passe.

J’ai ouvert l’application, choisi le mode correspondant à mon usage et connecté.

Puis j’ai refait exactement le test qui avait déclenché toute cette histoire.

Retour en mode Jeu.

J’ai ouvert le navigateur ajouté à Steam.

La page s’est chargée.

J’ai vérifié l’adresse IP.

Le tunnel était toujours actif.

J’ai fermé le navigateur, lancé le jeu, attendu sa connexion réseau, puis je suis revenu à l’accueil Steam.

Toujours pas de détour par le Bureau.

Dans ce test, c’était précisément le résultat que j’espérais obtenir depuis le début: fermer Plasma sans transformer cette action en exercice de dépannage.

La différence n’était donc pas qu’un VPN savait « fonctionner sur Linux » et l’autre non.

Les deux avaient fini par fonctionner.

La différence était la quantité d’état système que je devais personnellement comprendre et maintenir pour que cela reste vrai une fois revenu en mode Jeu.

Ce que je vérifierais avant de retourner encore une fois au Bureau

Si un profil fonctionne en mode Bureau mais plus en mode Jeu, je ne commencerais plus par changer de serveur ou de protocole.

Je vérifierais d’abord trois choses.

Le profil est-il bien enregistré comme connexion persistante dans NetworkManager ?

Son mot de passe est-il disponible au système, ou seulement à l’agent de secrets de la session Plasma ?

Et l’outil qui tente de lancer la connexion depuis le mode Jeu agit-il sous le même utilisateur ?

Avec TunnelDeck et un VPN utilisant des identifiants, le point le plus révélateur est précisément l’option de stockage du mot de passe pour tous les utilisateurs.

Cela peut suffire à remettre en service un fournisseur existant sans rien remplacer.

Mais comprendre la panne m’a aussi fait comprendre ce que je voulais éviter.

Je n’avais pas besoin d’un VPN avec davantage de paramètres NetworkManager.

J’avais besoin d’en avoir moins à gérer.

Le petit service a tout de même un compromis réel: il propose moins de régions qu’un grand fournisseur disposant d’un réseau mondial très étendu. Si ma priorité était de sortir précisément dans un pays rare, je regarderais cette différence avant tout.

Ce soir-là, pourtant, je ne cherchais pas une carte du monde.

Je cherchais à appuyer sur « Revenir au mode Jeu » sans me demander quelle partie de ma connexion était restée derrière dans Plasma.

Mon premier VPN y arrivait après que j’avais compris comment NetworkManager séparait le profil de son secret.

Le second m’a permis d’éviter ce problème plutôt que de devenir meilleur pour le réparer.

Et sur Steam Deck, c’est finalement ainsi que j’ai commencé à définir une connexion qui « survit » réellement au passage en mode Jeu: je ferme le Bureau, le tunnel reste utilisable, et je n’ai plus besoin de savoir où NetworkManager a rangé la clé.