Split tunneling inversé ou classique : je choisissais selon l’application, alors qu’il fallait choisir selon ce qui devait rester l’exception

Firefox affichait l’adresse IP du VPN.
Parfait.
J’ai ouvert Edge pour vérifier l’autre moitié de ma configuration.
Même adresse IP.
Pas parfait du tout.

J’avais pourtant réglé le split tunneling en mode « Include » : Firefox devait entrer dans le tunnel, le reste du PC devait continuer à utiliser ma connexion normale.

C’était précisément pour cela que j’avais choisi le mode inversé.

J’avais besoin de vérifier une page client depuis une connexion extérieure à mon réseau habituel. Une seule application devait prendre le VPN. Teams, OneDrive, mon client Git et les ressources du réseau local n’avaient aucune raison de l’accompagner.

La veille, le montage semblait fonctionner.
Le lendemain matin, tout le PC avait apparemment décidé de suivre Firefox.
À ce moment-là, je pensais encore que la question était :
« Quelle application dois-je mettre dans le split tunneling ? »
Ce n’était déjà plus la bonne question.

Beaucoup de nouveaux utilisateurs commencent justement avec une seule application

Le sujet est devenu beaucoup moins spécialisé qu’il y a quelques années.

Le 4 juin 2025, au moment où plusieurs sites ont suspendu leur accès en France dans le contexte des nouvelles obligations de vérification de l’âge, l’observatoire de Proton a mesuré une hausse de plus de 400 % de l’usage de son VPN par rapport au niveau habituel, avec un pic horaire d’inscriptions dépassant 1 000 %.

Une partie de ces nouveaux utilisateurs n’avait pas besoin de « mettre tout Internet sous VPN ».

Ils voulaient parfois simplement qu’un navigateur, une application ou un service emprunte une autre route sans modifier le comportement de tout le reste.

Et c’est précisément dans ce cas apparemment simple que les mots « split tunneling classique », « inverse », « Include » et « Exclude » commencent à se mélanger.

J’avais moi-même compris le mécanisme.

J’avais simplement choisi mon mode comme si certaines applications étaient naturellement des « applications VPN » et d’autres non.

En réalité, le choix dépend beaucoup plus de la route que l’on veut considérer comme normale.

Classique ou inversé : la différence tient à ce qui se passe par défaut

Le split tunneling classique — souvent appelé mode Exclude — commence avec une règle très simple :

tout passe par le VPN, sauf ce que vous retirez explicitement.
Le mode inversé — Include ou Inverse selon l’application — fait le contraire :
rien ne passe par le VPN, sauf ce que vous ajoutez explicitement.

La documentation actuelle de Proton illustre les deux modèles sur Windows, Linux, Android, Android TV et son extension de navigateur. Sur macOS, son implémentation actuelle se concentre sur l’exclusion d’applications.

Android expose presque exactement la même logique aux développeurs VPN. Son API permet soit d’établir une liste d’applications autorisées à utiliser le VPN, soit une liste d’applications qui doivent le contourner.

Autrement dit, il ne s’agit pas seulement de deux boutons portant des noms différents.

Ce sont deux politiques opposées :
VPN par défaut, avec quelques exceptions.
Ou Internet direct par défaut, avec quelques exceptions.

Cette distinction m’a donné une règle beaucoup plus utile que toutes celles que j’avais essayées jusque-là :

je choisis le mode qui produit la plus petite liste d’exceptions.

Si presque tout mon ordinateur doit utiliser le VPN et que seulement deux applications doivent rester locales, le mode classique est logique.

Si quinze applications doivent continuer normalement et qu’une seule doit prendre le VPN, le mode inversé est plus propre.

La catégorie de l’application compte moins que sa position par rapport à la majorité du trafic.

J’avais commencé par le mauvais sens et construit une liste dont je ne voulais pas

Avant le mode inversé, j’avais essayé le split tunneling classique.
VPN pour tout.
Puis j’avais commencé à exclure.
Teams, parce que je ne voulais pas modifier inutilement la route de mes réunions.
OneDrive, parce que la synchronisation fonctionnait déjà très bien.
Le client Git.
Un outil qui devait atteindre une machine sur le réseau local.

Puis Edge, parce que je voulais un navigateur témoin qui conserve mon adresse habituelle.

La règle fonctionnait, mais quelque chose me gênait.

Chaque fois qu’une nouvelle application apparaissait, je devais décider si elle appartenait à la liste.

Et cette liste décrivait presque tout mon ordinateur simplement pour permettre à Firefox d’utiliser le VPN.

J’avais construit la politique à l’envers.
Je suis donc passé au mode inversé.
Firefox dedans.
Tout le reste dehors.
Cette fois, la configuration tenait en une phrase.

Quand le routage suivait bien ma règle, Firefox présentait l’adresse du VPN tandis qu’Edge conservait celle de ma connexion normale. Mon accès au réseau local restait intact et mes autres applications continuaient leur journée comme si le VPN n’existait pas.

C’était exactement ce que je voulais.

Puis j’ai vu les deux navigateurs afficher la même IP.

Un événement de fin août m’a rappelé qu’un bon mode doit aussi être vérifiable

Ce qui m’arrivait ressemblait beaucoup à un problème publiquement documenté quelques jours auparavant.

Le 25 août 2026, un utilisateur de Proton sous Windows 11 a signalé qu’en mode Include, avec seulement certaines applications sélectionnées, le protocole Proton WireGuard UDP envoyait malgré tout l’ensemble du trafic dans le VPN. D’autres tests publiés dans le fil ont reproduit la différence en changeant de protocole. L’équipe Proton a reconnu le problème et indiqué qu’un correctif était intégré à la version bêta 5.1.8 mise à disposition le 31 août.

Pour moi, le problème n’était donc plus de savoir si le mode inversé avait du sens.

Il en avait.

Le problème était qu’une case « Include » cochée dans l’interface ne suffisait pas à prouver que le trafic suivait réellement cette règle.

Je suis revenu à un test beaucoup plus banal.
Une application dedans.
Une application dehors.
Vérification des deux adresses IP.
Accès à une ressource locale.
Déconnexion, reconnexion.
Puis le même contrôle après avoir changé de réseau ou redémarré l’application.

Le mode inversé restait le bon choix pour mon architecture.

Mais il avait désormais un coût que je n’avais pas compté : puisque je dépendais du routage application par application, je devais aussi vérifier que cette frontière restait exactement là où je l’avais placée.

Et c’est en répétant ces contrôles que j’ai fini par regarder quelque chose qui n’était même pas dans les réglages.

Mon test client durait dix minutes ; ma règle de routage était devenue plus durable que le problème

J’ai regardé le deuxième appareil posé sur mon bureau.

Je l’utilisais déjà pour vérifier les versions mobiles des pages clients.

Il n’avait ni Teams, ni ma synchronisation de fichiers, ni mes outils de développement, ni les ressources locales auxquelles mon ordinateur devait rester connecté.

Et je me suis demandé pourquoi j’étais en train de perfectionner une politique de split tunneling sur ma machine principale simplement pour exécuter un test extérieur pendant quelques minutes.

Le problème que j’essayais de séparer dans le logiciel était déjà séparé physiquement sur mon bureau.

J’ai installé OnlydogVPN^↗ sur cet appareil.

Son approche correspondait beaucoup mieux à ce moment précis : partir de ce que j’essayais de faire, plutôt que de me demander d’abord comment répartir toutes les autres applications autour.

J’ai choisi le mode correspondant à mon usage.
Connexion.
Puis j’ai rouvert la page client.
La page a chargé depuis la route VPN.
J’ai effectué le parcours d’inscription.
Le formulaire final s’est affiché.
J’ai pris la capture demandée et je l’ai envoyée au client.

Pendant ce temps, sur mon ordinateur principal, Teams continuait à fonctionner sur ma connexion habituelle.

OneDrive synchronisait.
Mon réseau local n’avait pas changé.
Je n’avais rien oublié dans une liste d’exclusion.

Il n’y avait tout simplement aucune liste à maintenir, parce que je n’avais jamais demandé à ce PC de partager deux routes.

C’était là que la différence devenait intéressante.

Le split tunneling inversé restait la bonne réponse lorsque je devais réellement séparer plusieurs applications sur une seule machine.

Mais pour cette tâche de dix minutes, le petit service m’avait permis de supprimer le problème au lieu de mieux administrer sa complexité.

Une fois le test terminé, j’ai découvert un deuxième détail bien adapté à ce rôle d’appareil secondaire : pour l’usage de base, je n’avais pas eu à créer un nouveau compte traditionnel avec une adresse e-mail et un mot de passe. L’approche par modes d’usage et ce démarrage simplifié apparaissent également dans les tests publiés par l’éditeur.

Ce n’était pas ce qui avait fait charger ma page.
Elle était déjà ouverte.
C’était simplement la friction suivante qui venait de disparaître.

Et une bonne raison de laisser l’application installée pour la prochaine vérification extérieure.

Je ne choisis plus le split tunneling selon le nom de l’application

Il existe toujours des cas où je garderais sans hésiter un client doté d’un split tunneling très configurable.

Si qBittorrent doit être la seule application protégée sur un PC qui sert à vingt autres choses en parallèle, le mode inversé est naturellement adapté.

Si mon ordinateur de voyage doit presque toujours utiliser le VPN mais qu’une application bancaire ou un outil local doit exceptionnellement sortir directement, le mode classique est plus lisible.

Et si je dois gérer en permanence deux routes différentes sur une seule machine, les contrôles précis d’inclusion, d’exclusion et de kill switch deviennent une vraie fonction centrale, pas un détail.

Le plus petit service a aussi une limite facile à comprendre : il propose moins de régions que les grands fournisseurs. Si mon travail exigeait régulièrement une longue liste de pays très précis, je le sentirais rapidement.

Mais ce matin-là, le nombre de régions n’était pas ce qui m’empêchait d’avancer.
Mon erreur était d’avoir demandé :
« Firefox est-il une application qui doit être incluse ou exclue ? »
La réponse dépendait entièrement de tout ce qui se trouvait autour de Firefox.

Quand le VPN est la route normale, j’exclus les rares applications qui doivent rester directes.

Quand la connexion directe est la route normale, j’inclus les rares applications qui ont réellement besoin du VPN.

Et quand la liste d’exceptions devient plus compliquée que la tâche elle-même, je regarde d’abord si je n’essaie pas de fabriquer dans les paramètres une séparation que j’ai déjà sous les yeux.

Ce matin-là, le bon réglage n’était finalement pas « inversé parce que Firefox ».

C’était un seul appareil de test dans le VPN, mon ordinateur de travail en dehors, et aucune règle oubliée à vérifier le lendemain.