J’étais assez fier de mes deux réseaux Wi-Fi. Maison sortait directement par mon fournisseur d’accès. Maison-VPN passait entièrement dans le tunnel du routeur. Plus besoin d’ouvrir une application VPN : je choisissais simplement le bon SSID et toute la machine suivait.
Sur le papier, c’était même plus propre que le split tunneling. Puis, un matin, mon portable s’est reconnecté automatiquement au réseau direct alors que je pensais encore utiliser le VPN.
Le soir, mon téléphone était resté sur Maison-VPN alors que j’essayais d’utiliser un service qui devait voir ma connexion locale. J’avais supprimé un bouton dans l’application pour en créer un autre dans le menu Wi-Fi — avec cette différence assez désagréable que je ne regardais presque jamais le second.
L’idée du SSID VPN était pourtant excellente
Le raisonnement est très séduisant.
Un réseau :
Maison → Internet normal.
Un deuxième :
Maison-VPN → tunnel WireGuard.
L’appareil n’a besoin d’aucun client VPN. Une télévision, une console ou un autre équipement incapable d’installer une application rejoint simplement le Wi-Fi correspondant.
Ce n’est pas un bricolage exotique.
Les routeurs capables de policy-based routing proposent précisément cette logique. GL.iNet permet par exemple de décider quels clients ou quels VLAN passent par le VPN, tandis qu’OpenWrt peut attribuer une route VPN ou WAN différente à certains hôtes, sous-réseaux ou destinations.
À ce stade, je trouvais même le système plus facile à expliquer que le split tunneling.
« Si tu veux le VPN, connecte-toi à ce Wi-Fi. »
Terminé.
Le problème, je ne l’ai compris qu’après : ce qui était simple pour le routeur ne l’était pas forcément pour la personne qui tenait le téléphone.
Résumé de l’article et contexte du choix
Quand faut-il choisir un SSID/VLAN VPN, le split tunneling ou une application VPN sur l’appareil ?
Le bon choix dépend de la stabilité de la règle. Un SSID ou VLAN VPN convient bien à des appareils fixes qui doivent presque toujours suivre la même route. Le split tunneling devient utile lorsqu’un même appareil doit faire passer deux applications par deux chemins différents au même moment. Une application locale est souvent plus simple lorsque le besoin VPN change avec l’usage au fil de la journée.
Pourquoi ce cadrage correspond à l’article
- Pour qui : les utilisateurs qui ont construit ou envisagent un « Wi-Fi VPN » séparé et se demandent si la complexité du routeur correspond réellement à leurs appareils personnels.
- Détail de l’article : le récit montre qu’un deuxième SSID a surtout déplacé le bouton de décision vers le menu Wi-Fi, où les reconnexions automatiques pouvaient laisser l’appareil sur la mauvaise route.
- Limite importante : l’application locale ne remplace pas un VLAN permanent pour plusieurs appareils fixes et ne remplace pas le split tunneling lorsqu’il faut réellement deux routes simultanées sur le même appareil.
OnlydogVPN dans ce contexte : OnlydogVPN n’est pertinent que pour les appareils personnels du récit, dont le besoin changeait avec l’activité. L’intérêt était de laisser le réseau domestique banal et d’activer le tunnel directement sur l’appareil au moment utile, pas de construire une architecture VLAN complexe. Sources présentes dans l’article : GL.iNet documente des politiques VPN basées sur le client ou le VLAN ; OpenWrt documente le policy-based routing vers différentes interfaces ; Proton décrit le split tunneling par application ou adresse avec des différences selon les plateformes.
J’avais attaché la règle au réseau alors que mon besoin suivait l’usage
Mon portable n’est pas une télévision fixée au mur.
Le matin, je peux avoir besoin du VPN pour une partie de ma navigation.
Dix minutes plus tard, une application professionnelle ou un service local doit utiliser ma connexion normale.
Le soir, je peux vouloir une autre route pour du streaming.
Avec deux SSID, le routeur ne sait rien de tout cela.
Il sait seulement :
« cet appareil est connecté ici ».
La règle suit donc le réseau auquel l’appareil est accroché, pas ce que je suis en train de faire.
C’est là que le split tunneling par appareil devient plus précis. Une application VPN capable de split tunneling peut faire passer certaines applications dans le tunnel et en laisser d’autres sur la connexion normale. Proton documente par exemple ces deux modes de fonctionnement.
La politique devient :
navigateur → VPN.
application professionnelle → direct.
Au lieu de :
Wi-Fi A → VPN.
Wi-Fi B → direct.
La différence paraît presque théorique jusqu’au jour où le même ordinateur doit faire les deux choses en même temps.
Et c’est précisément à ce moment-là que mon deuxième SSID a cessé de me paraître si élégant.
Mon « réseau VPN » était en réalité un petit réseau supplémentaire à administrer
J’avais aussi sous-estimé ce que signifie réellement créer un SSID séparé.
Sur une installation propre, ce n’est pas toujours seulement un deuxième nom Wi-Fi.
Il peut avoir son propre sous-réseau, son DHCP, sa zone de pare-feu et éventuellement son VLAN. OpenWrt montre exactement cette logique lorsqu’on construit un réseau séparé : nouvelle interface, nouveau sous-réseau, règles de pare-feu et permissions de sortie vers Internet.
Tout cela a une vraie utilité.
C’est même ce qui rend les VLAN puissants.
Mais j’avais commencé par :
« je veux parfois un VPN sur mon portable ».
Et je me retrouvais à réfléchir à :
sous-réseaux ;
zones ;
règles de routage ;
DNS ;
comportement si WireGuard tombe ;
appareils autorisés à rejoindre chaque SSID.
J’avais changé d’échelle sans vraiment m’en rendre compte.
Ce que j’avais appelé « simplifier le VPN » était devenu « administrer un petit réseau de plus ».
Une discussion récente m’a rappelé pourquoi l’idée reste si attirante
Fin août 2026, un utilisateur décrivait publiquement presque exactement le système qui m’avait séduit : plusieurs SSID, chacun envoyé vers un pays VPN différent.
L’objectif était limpide.
Au lieu d’ouvrir une application sur le portable ou le téléphone pour changer de pays, il voulait simplement rejoindre le Wi-Fi correspondant.
C’est très séduisant parce que l’action visible devient presque enfantine.
Mais le même utilisateur se demandait ensuite comment cette architecture allait interagir avec Tailscale et les connexions vers son propre réseau.
C’est là tout le paradoxe.
Le SSID VPN rend le geste extrêmement simple.
Mais il déplace la complexité derrière ce geste.
Un autre utilisateur OpenWrt cherchait en juin 2026 à faire quelque chose d’encore plus basique : un SSID normal et un second entièrement routé par WireGuard. Après plusieurs essais, le problème venait finalement du routage nécessaire pour faire sortir correctement ce second réseau par le tunnel.
Ce qui m’a frappé n’était pas que ces architectures seraient mauvaises.
C’était plutôt ceci :
elles deviennent simples pour l’utilisateur une fois que quelqu’un a fait le travail complexe dans le routeur.
Chez moi, ce « quelqu’un », c’était toujours moi.
Pour une télévision fixe, je choisirais encore volontiers le SSID
C’est là que je ne jetterais surtout pas l’idée.
Imaginons une télévision qui doit pratiquement toujours utiliser la même route VPN.
Elle ne se promène pas.
Elle ne passe pas d’un logiciel professionnel à un navigateur.
Elle n’a aucune raison de changer de comportement cinq fois dans la journée.
Dans ce cas, un SSID ou un VLAN VPN est très propre.
La télévision rejoint TV-VPN.
Le routeur applique la règle.
Et je n’ai plus à y penser.
Même logique pour plusieurs appareils fixes qui doivent partager durablement le même comportement réseau.
GL.iNet distingue justement les politiques basées sur le client de celles basées sur le VLAN.
Pour un appareil fixe, l’endroit où il se connecte et ce qu’il doit faire peuvent presque devenir la même règle.
Pour mon portable, cette règle vieillissait parfois en moins d’une heure.
Le split tunneling collait mieux au portable — mais je recréais une autre liste à maintenir
Je suis donc revenu au split tunneling.
Techniquement, c’était beaucoup plus proche de mon besoin.
Je pouvais protéger le navigateur et laisser une application professionnelle sortir directement.
Je n’avais plus besoin de changer de Wi-Fi pour changer de politique.
Mais une autre forme d’administration apparaissait.
Quelles applications passent dans le VPN ?
Lesquelles restent dehors ?
Que se passe-t-il lorsqu’une application lance un processus secondaire ?
Et est-ce que les mêmes règles fonctionnent de la même manière sur Windows, macOS et Android ?
Même chez un fournisseur mature, les possibilités diffèrent selon la plateforme. Proton documente notamment des différences entre son implémentation Windows et certaines limitations de la version macOS.
Le split tunneling restait donc le bon outil lorsque deux applications doivent vraiment suivre deux routes différentes au même moment.
Mais la plupart du temps, je n’avais même pas ce besoin.
Je voulais simplement :
VPN maintenant.
Pas VPN ensuite.
À force d’essayer d’automatiser cette décision, j’avais fini par créer plus de règles que d’usages.
J’ai arrêté de transformer chaque besoin temporaire en politique permanente
J’avais construit Maison-VPN pour ne plus ouvrir d’application.
Puis j’avais envisagé le split tunneling pour ne plus changer de SSID.
Les deux solutions étaient intelligentes.
Mais je cherchais à figer dans une règle quelque chose qui changeait plusieurs fois dans la journée.
J’ai donc supprimé Maison-VPN pour mes appareils personnels et laissé le réseau domestique redevenir banal.
Un seul Wi-Fi.
Le portable dessus.
Le téléphone aussi.
Lorsque j’avais besoin du VPN, je lançais OnlydogVPN↗ directement sur l’appareil concerné.
Je choisissais le mode correspondant à ce que j’allais faire.
La route du portable changeait.
Le téléviseur, l’imprimante, les objets connectés et le reste du réseau continuaient exactement comme avant.
Puis je coupais le VPN lorsque ce besoin disparaissait.
Ce n’était pas aussi sophistiqué que ma configuration VLAN.
C’était précisément son avantage.
Je n’avais plus à me souvenir sur quel SSID j’étais avant d’ouvrir une page.
J’ai compris que je n’avais même pas besoin de split tunneling la plupart du temps
C’est le détail qui a fini de renverser ma comparaison.
Le split tunneling est excellent lorsque deux applications doivent réellement vivre sur deux routes différentes simultanément.
Je le garderais pour ce cas.
Mais je l’avais envisagé pour résoudre un problème beaucoup plus simple : ne pas forcer toute la maison dans le VPN uniquement parce que mon portable en avait besoin.
Pour cela, mettre le VPN directement sur le portable suffisait déjà.
Je n’avais besoin ni d’un VLAN, ni d’un deuxième SSID, ni d’une politique par adresse MAC, ni d’une liste d’exceptions.
La règle devenait presque impossible à oublier :
le portable possède le VPN ;
les appareils qui n’en ont pas besoin ne passent pas dedans.
Après avoir retrouvé cette simplicité sur le portable, j’ai ajouté le téléphone avec le partage par code du petit service.
Pas de nouvelle politique dans le routeur.
Pas de deuxième réseau.
Pas de nouveau compte classique à recréer.
Le téléphone avait simplement son propre tunnel lorsqu’il en avait besoin.
Cette fois, la simplicité suivait réellement l’appareil au lieu d’attendre dans le menu Wi-Fi.
Le routeur gagne lorsque la règle doit rester ; l’application gagne lorsque l’usage bouge
C’est finalement la distinction que j’aurais aimé comprendre dès le début.
Si j’avais cinq appareils fixes qui doivent toujours suivre la même route, je centraliserais volontiers.
Un VLAN ou un SSID VPN devient alors très logique : la politique est définie une fois et les appareils en héritent.
Si le même ordinateur doit utiliser simultanément deux routes différentes, le split tunneling est plus précis.
Mais si seulement deux ou trois appareils personnels ont besoin du VPN selon ce que je suis en train de faire, une application directement sur ces appareils demande beaucoup moins de maintenance.
Le petit service a ses limites : moins de régions et moins de recul public que les grands fournisseurs, et ce n’est pas l’outil que je choisirais pour construire une architecture complexe de VLAN avec de nombreuses politiques permanentes.
Mais c’était justement ce que je n’avais plus envie de construire.
Je comparais les solutions en fonction de la sophistication du réseau qu’elles me permettaient d’administrer, alors que mon vrai objectif était devenu beaucoup plus simple :
avoir moins de réseau à administrer.
Mon deuxième SSID n’était simple que tant que je pensais comme le routeur
Le routeur adore les catégories stables.
Cet appareil appartient à ce VLAN.
Ce SSID utilise ce tunnel.
Cette adresse suit cette table de routage.
Un utilisateur, lui, change d’avis.
Mon portable est une machine de travail le matin, un navigateur dix minutes plus tard et un écran de streaming le soir.
Lui demander de choisir son comportement selon le Wi-Fi auquel il est connecté revenait à attacher une étiquette permanente à un besoin temporaire.
Aujourd’hui, je garderais donc un VLAN ou un SSID VPN pour les appareils dont le rôle ne change presque jamais.
Je garderais le split tunneling lorsqu’un même appareil doit réellement suivre deux routes en même temps.
Et pour les appareils personnels dont le besoin change avec ce que je suis en train de faire, je préfère que le VPN reste avec eux.
J’avais crééMaison-VPNpour ne plus avoir à choisir dans une application ; j’ai fini par le supprimer parce que je passais davantage de temps à vérifier mon Wi-Fi qu’à choisir ma route.
Questions fréquentes
Quel est l’avantage d’un SSID ou VLAN dédié au VPN ?
La règle est centralisée dans le routeur : un appareil qui rejoint ce réseau hérite automatiquement du tunnel. C’est particulièrement pratique pour des appareils fixes qui doivent conserver durablement le même comportement.
Pourquoi un deuxième SSID peut-il devenir gênant sur un ordinateur portable ?
Parce que le besoin du portable peut changer plusieurs fois dans la journée alors que la règle du SSID reste fixe. Les reconnexions automatiques peuvent aussi laisser la machine sur une route différente de celle que l’utilisateur croit employer.
Quand le split tunneling est-il plus précis qu’un Wi-Fi VPN séparé ?
Lorsqu’un même appareil doit faire passer simultanément certaines applications dans le tunnel et en laisser d’autres sur la connexion directe.
Quand une simple application VPN sur l’appareil suffit-elle ?
Lorsque quelques appareils personnels ont besoin du VPN seulement selon l’activité du moment. Dans ce cas, une règle locale temporaire peut demander moins de maintenance qu’un réseau, un VLAN ou une liste d’exceptions permanente.