Le split tunneling réduit-il réellement la sécurité d’un VPN ? Le vrai risque commence avec ce qu’on laisse hors du tunnel

Le split tunneling avait parfaitement fonctionné.

C’est justement ce qui m’a posé problème.

Quelques jours plus tôt, chez moi, un service refusait de s’ouvrir tant que mon VPN restait actif. J’avais trouvé la fonction idéale dans l’application : exclure mon navigateur du tunnel.

Un clic.
Le site s’est ouvert.
Le reste de l’ordinateur continuait à utiliser le VPN.
J’avais résolu le problème et complètement oublié le réglage.
Puis je suis arrivé dans un hôtel.

J’ai connecté le portable au Wi-Fi, passé le portail d’accès et activé le VPN. L’icône indiquait « Connecté ». J’ai ouvert mon navigateur et commencé à travailler comme d’habitude.

Par curiosité, j’ai vérifié mon adresse IP.
Ce n’était pas celle du VPN.
C’était celle de la connexion locale.
J’ai essayé avec une autre application : elle utilisait bien la sortie VPN.
Puis j’ai regardé la liste des exclusions.
Mon navigateur était toujours là.

Le split tunneling n’avait rien laissé « fuir ». Il avait obéi exactement à la règle que j’avais créée plusieurs jours auparavant.

J’étais simplement la personne qui avait oublié cette règle.

À ce moment-là, ma question a changé. Je ne voulais plus savoir si le split tunneling était une fonction sûre ou dangereuse.

Je voulais savoir quelque chose de beaucoup plus utile :

qu’est-ce que je perds réellement quand je fais sortir une application du tunnel ?

Hors du tunnel ne veut pas dire « cassé »

La distinction paraît évidente une fois qu’on la formule correctement.

Le split tunneling ne fragilise pas soudainement le chiffrement du trafic qui reste dans le VPN. Il sépare simplement les routes : une partie du trafic continue dans le tunnel, l’autre utilise directement la connexion Internet normale. C’est aussi ainsi que le NIST définit le principe.

Imaginez deux portes de sortie.
La première passe par le VPN.
La seconde donne directement sur Internet.

Le split tunneling ne rend pas la première porte moins solide. Il décide simplement quelles applications ont le droit d’emprunter la seconde.

Si mon navigateur est exclu, son trafic ne profite donc plus de la route VPN : son adresse IP publique n’est plus celle du serveur VPN et les protections réseau appliquées dans le tunnel ne se trouvent plus sur son chemin.

Cela ne signifie pas que chaque page HTTPS devient soudain lisible en clair sur le Wi-Fi de l’hôtel. HTTPS continue de protéger les connexions HTTPS.

Mais pour cette application précise, le VPN n’est plus dans le trajet.
Chez moi, c’était exactement ce que je voulais.
Dans un hôtel, j’avais beaucoup moins envie d’avoir oublié cette porte ouverte.

Le réseau public a rendu mon ancienne exception beaucoup moins anodine

Cette découverte m’a particulièrement marqué à cause d’une actualité récente.

Le 31 juillet 2026, Microsoft Threat Intelligence a détaillé CaptiveCrunch, une campagne observée depuis mai sur des réseaux liés notamment à des hôtels et à d’autres lieux utilisant des portails captifs. Microsoft décrit des manipulations de trafic pouvant conduire certains voyageurs vers du phishing ou vers des instructions destinées à faire installer des logiciels malveillants. L’entreprise recommande de considérer les Wi-Fi d’hôtels, d’aéroports et de conférences comme non fiables.

Un VPN ne transforme évidemment pas un faux portail en site légitime et ne peut pas empêcher quelqu’un d’exécuter volontairement un fichier malveillant.

Mais ce n’était pas ce qui m’intéressait.

J’avais activé le VPN précisément parce que je ne contrôlais pas le réseau sous mon ordinateur.

Puis j’avais laissé mon navigateur contourner ce VPN à cause d’une décision prise plusieurs jours auparavant sur ma fibre domestique.

Le problème n’était donc pas que le split tunneling avait « réduit la sécurité du VPN ».
Le VPN protégeait toujours ce qui passait dedans.
J’avais simplement réduit la quantité de trafic qui y passait.
Et cette différence est devenue mon vrai critère.

Pourtant, supprimer toutes les exceptions n’était pas non plus la bonne conclusion

Ma première réaction a été assez prévisible : remettre tout dans le tunnel et considérer le split tunneling comme une complication dont je pouvais me passer.

Mais ce serait confondre un mauvais souvenir de configuration avec une mauvaise technologie.

Microsoft documente justement une architecture de split tunneling pour Microsoft 365 dans laquelle certains flux empruntent directement Internet tandis que le reste continue de passer par le VPN. Avec des exceptions limitées, intentionnelles et correctement protégées, cette organisation peut parfaitement avoir du sens.

Cela m’a aidé à distinguer deux situations.

Une équipe informatique qui sait exactement quel service sort du tunnel, pourquoi il en sort et comment il est protégé applique une politique réseau.

Moi, j’avais une case cochée six jours plus tôt.
Dans le premier cas, l’exception est maîtrisée.
Dans le second, elle devient facilement un souvenir.

C’est là que le split tunneling commence à me gêner : non pas lorsqu’il existe, mais lorsque je dois accumuler des exceptions simplement pour que mon VPN reste utilisable.

Une exception peut devenir plus grande qu’elle en a l’air

Cloudflare donne un bon exemple de cette difficulté dans sa documentation sur les Split Tunnels. Les règles peuvent inclure ou exclure des domaines et des adresses IP, tandis que le routage et la résolution DNS ne suivent pas toujours exactement la même logique. Une règle trop large peut donc concerner davantage de trafic que ce que son nom laisse imaginer.

Je n’avais pas besoin de transformer cela en cours de réseau.
J’ai gardé l’image de la porte latérale.
Une porte clairement identifiée pour une application précise, aucun problème.

Cinq portes ouvertes pour résoudre cinq petites incompatibilités, dont certaines dépendent d’autres services en arrière-plan, et je commence à ne plus savoir exactement ce que signifie l’icône « VPN connecté ».

Les différences entre systèmes compliquent encore les choses. Proton documente par exemple des possibilités et des limites différentes selon les plateformes, notamment autour des exclusions, du kill switch et de macOS.

Ce n’est pas un défaut propre à un fournisseur. C’est surtout un rappel : « exclure une application » paraît beaucoup plus simple dans une interface que le routage réel qui se déroule derrière.

Et c’est précisément pour cela que je ne voulais plus utiliser le split tunneling comme bouton universel chaque fois qu’un site fonctionnait mal avec mon VPN.

Les utilisateurs se posent la même question lorsqu’ils voient leur vraie IP

Une discussion publiée sur Reddit en août 2026 résume bien la confusion. Un utilisateur s’inquiétait du risque de fuite d’IP avec le split tunneling. La distinction utile apparue dans les réponses était simple : lorsqu’une application a volontairement été exclue, voir son adresse IP réelle n’est pas nécessairement une fuite accidentelle. C’est souvent exactement ce que la règle lui a demandé de faire.

Une autre discussion récente montre pourquoi la fonction reste populaire : banque, streaming, jeux, services locaux… certains utilisateurs préfèrent exclure quelques usages plutôt que désactiver complètement leur VPN.

Je comprenais cette logique.
C’était même exactement la mienne.
Sauf que mon navigateur n’avait pas fondamentalement besoin d’une connexion directe.
Je l’avais exclu parce que mon VPN habituel m’avait placé devant un choix pénible :
garder le navigateur dans le tunnel et supporter les problèmes de connexion ;
ou le sortir du tunnel et espérer me souvenir de cette exception plus tard.

Une troisième possibilité commençait donc à m’intéresser davantage : et si je pouvais simplement laisser le navigateur dans le VPN sans que cela devienne un problème ?

J’ai supprimé l’exception avant de changer de VPN

J’ai commencé par remettre le navigateur dans le tunnel.

Puis j’ai ouvert OnlydogVPN^↗.

Le service a une empreinte publique plus petite que les fournisseurs historiques, avec moins de destinations et moins d’années de recul. Mais ce soir-là, je ne cherchais plus le VPN possédant la liste de réglages la plus longue.

Je voulais justement voir si je pouvais en supprimer un.

Sur le Wi-Fi utilisé pour le test, j’ai choisi le mode adapté au réseau public et lancé la connexion.

Puis j’ai rouvert le navigateur.

Le site qui m’avait poussé à bricoler mes routes n’était plus mon seul test. J’ai ouvert ma messagerie, plusieurs pages de travail et un espace cloud, puis lancé le transfert d’un document.

Tout est resté dans la même connexion.
J’ai vérifié l’adresse IP depuis le navigateur.
Cette fois, elle correspondait bien à la sortie du VPN.
Le fichier continuait à avancer.
La messagerie synchronisait.
Les pages chargeaient.
Et surtout, ma liste d’exclusions était vide.

C’était le résultat que je cherchais.
Pas « le split tunneling est dangereux ».
Beaucoup plus simplement :
je n’avais plus besoin du split tunneling pour réparer mon VPN.

Une règle en moins m’a finalement rassuré davantage qu’une fonction en plus

La raison technique m’intéressait surtout après avoir constaté le résultat.

Le service utilise un transport basé sur HTTP/3 et une approche conçue pour mieux supporter les changements de réseau. HTTP/3 s’appuie sur QUIC, un protocole qui prévoit notamment la possibilité pour une connexion de continuer lorsque son chemin réseau change.

En pratique, ce qui comptait pour moi était beaucoup plus simple : je pouvais garder le tunnel complet sans commencer à découper mon ordinateur application par application.

Puis j’ai fermé le portable et quitté le hall.
Le Wi-Fi s’est affaibli.
Le partage de connexion du téléphone a pris le relais peu après.
Une page a hésité, puis le travail a continué.

Je n’en ai pas tiré la conclusion que tous les changements de réseau seraient toujours invisibles. Ce test m’a simplement donné quelque chose de plus convaincant qu’une longue liste d’options : dans la situation qui m’avait justement poussé vers le split tunneling, je pouvais désormais garder mes applications dans le tunnel sans passer mon temps à gérer des exceptions.

Et pour moi, c’était une amélioration de sécurité très concrète.
Moins de portes latérales.
Moins de règles oubliées.

Moins de différence entre ce que l’icône « Connecté » me faisait croire et le chemin réellement emprunté par mon navigateur.

Je ne demande plus si le split tunneling est « sûr »

Je demande ce que je suis en train d’exclure — et surtout pourquoi.

Si une application doit réellement utiliser ma connexion locale, le split tunneling peut être exactement le bon outil. Je garde simplement l’exception aussi petite et intentionnelle que possible.

Mais si je commence à exclure mon navigateur, puis ma visioconférence, puis mon stockage cloud uniquement parce que le tunnel complet devient lent, instable ou pénible, je m’arrête.

À ce stade, le split tunneling n’organise plus vraiment mon trafic.
Il compense les problèmes de la connexion que j’ai choisie.
C’est ce qui a finalement départagé les deux approches pour moi.

Mon ancien fournisseur me donnait un outil puissant pour décider quelles applications pouvaient sortir du tunnel.

Le plus petit service m’a permis, sur ce réseau, de garder le navigateur, les messages et le transfert dans une seule route sans avoir besoin de cette liste.

Je pensais que la question était de savoir combien de sécurité le split tunneling retirait à un VPN.

Dans cette chambre d’hôtel, la réponse était beaucoup plus concrète : le tunnel n’avait rien perdu ; c’était mon navigateur que j’avais oublié dehors.