Qu'est-ce que le split tunneling — comment fonctionne vraiment le routage VPN par application

En bref : un VPN standard fait passer 100 % du trafic de votre appareil par le tunnel chiffré. Le split tunneling rompt cette règle intentionnellement. Vous choisissez quelles applications ou quelles destinations contournent le tunnel et passent directement par votre connexion normale. Le concept est simple — mais l'implémentation pratique diffère sensiblement d'un système d'exploitation à l'autre, et les compromis en matière de confidentialité sont faciles à manquer. Une application de streaming routée hors du tunnel voit toujours votre vraie adresse IP. Une application bancaire routée hors du tunnel communique toujours avec votre banque via votre réseau domestique — ce qui est acceptable, jusqu'à ce que cette même application émette une requête DNS qui fuit par le chemin de contournement et révèle un domaine que vous ne vouliez pas exposer.

Ce que fait vraiment le tunneling VPN (la base)

Avant de comprendre ce qui est « splitté », il faut être clair sur ce que fait le tunnel complet. Un client VPN qui tourne sur votre appareil crée une interface réseau virtuelle — sous Linux elle s'appelle généralement tun0 ou wg0, sous macOS c'est utun, sur iOS et Android le système d'exploitation la gère via une API d'extension par application. La table de routage du système d'exploitation est ensuite modifiée de façon à ce que la route par défaut — la règle qui dit « envoyer les paquets sans autre route correspondante à cette passerelle » — pointe vers cette interface virtuelle plutôt que vers votre interface Wi-Fi physique ou cellulaire.

À partir de là, chaque paquet généré par votre appareil est chiffré par le client VPN, encapsulé dans un nouvel en-tête IP ciblant le serveur VPN, et envoyé par l'interface physique sous forme d'un flux homogène unique. Le serveur VPN déchiffre le paquet, le transmet à sa vraie destination sur l'internet public, reçoit la réponse, la rechiffre et la renvoie. Votre FAI ne voit qu'un flux chiffré vers une seule adresse IP. Les sites de destination voient l'adresse IP du serveur VPN, pas la vôtre.

C'est le comportement par défaut. Le split tunneling intervient dans ce modèle en ajoutant des routes plus spécifiques à la table de routage — des règles qui disent « pour le trafic à destination de cette adresse » ou « pour le trafic généré par cette application, ignorer la route tunnel par défaut et utiliser directement l'interface physique ».

Ce que change le split tunneling

Conceptuellement, le split tunneling introduit une bifurcation dans votre flux réseau. Certains paquets passent par le tunnel chiffré ; d'autres sortent par l'interface brute. La décision est prise par le client VPN selon les règles que vous configurez. Il existe trois grandes catégories de règles de split :

• Par application — « Faire passer tout le trafic de Netflix hors du tunnel ; tunneliser tout le reste. » Implémenté en marquant les paquets avec l'UID ou le PID du processus d'origine, puis en prenant les décisions de routage par tag.
• Par destination — « Faire passer le trafic vers 10.0.0.0/8 hors du tunnel pour pouvoir atteindre mon NAS domestique ; tunneliser tout le reste. » Implémenté uniquement avec des entrées dans la table de routage — la forme la plus simple.
• Par URL ou domaine — « Faire passer le trafic vers *.bank.com hors du tunnel. » C'est fragile car la couche de routage du système d'exploitation ne connaît pas nativement les domaines ; cela nécessite que le client VPN intercepte les DNS et réécrive les réponses, ou maintienne une liste d'autorisation d'IP dynamique qui suit les résolutions DNS. Les éditeurs implémentent cela de façon hétérogène.

Voici la vue architecturale, simplifiée :

Tunnel complet (sans split) :
  [Appli A] -> [Appli B] -> [Appli C]
        \        |        /
         [Interface VPN virtuelle]
                 |
         [Tunnel chiffré]
                 |
         [Serveur VPN] -> internet

Split tunnel (par application, Appli C exclue) :
  [Appli A] -> [Appli B]        [Appli C]
        \        /               \
   [Interface VPN virtuelle]   [Wi-Fi physique]
              |                    |
       [Tunnel chiffré]    [Internet en clair]
              |                    |
        [Serveur VPN]         direct à dest

Le « split » est le point de divergence à l'intérieur de votre système d'exploitation — le choix entre interface virtuelle et interface physique est fait avant que le chiffrement n'ait lieu, donc un paquet qui contourne le tunnel n'a tout simplement jamais été chiffré. Il n'y a pas d'étape de déchiffrement ; il quitte votre appareil tel quel.

Split tunneling inversé — liste d'exclusion vs liste d'autorisation

Les configurations de split tunneling existent en deux variantes qui semblent symétriques mais ont un comportement de défaillance par défaut très différent :

• Mode liste d'exclusion (le défaut courant) — « Tunneliser tout sauf les applications/destinations sur cette liste. » Le défaut est protégé ; seules des exceptions spécifiques fuient. Si vous oubliez d'ajouter une application à la liste, elle reste protégée.
• Mode liste d'autorisation (aussi appelé split tunneling inversé) — « Tunneliser uniquement les applications/destinations sur cette liste ; tout le reste passe en direct. » Le défaut est non protégé ; seules les applications spécifiques sont tunnelisées. Si vous oubliez d'ajouter une application à la liste, elle fuit.

Le mode liste d'autorisation est le bon choix pour « Je veux que seul mon navigateur utilise le VPN, tout le reste peut utiliser ma connexion normale. » Le mode liste d'exclusion est le bon choix pour « Je veux la plupart des choses protégées, mais quelques applications spécifiques ont besoin du réseau réel. » La plupart des consommateurs veulent le mode liste d'exclusion. Les équipes Opérations et DevOps préfèrent parfois le mode liste d'autorisation, car elles cherchent à exposer des services spécifiques via le tunnel sans perturber le reste du système.

Le mode de défaillance du mode liste d'autorisation est sévère : si vous ajoutez une nouvelle application et oubliez de l'ajouter à la liste d'autorisation, le trafic de cette application fuit. Le mode de défaillance du mode liste d'exclusion est plus doux : les applications oubliées restent protégées — vous avez juste des problèmes de compatibilité agaçants quand une application de streaming ou bancaire échoue parce qu'elle voit l'IP du VPN.

Quand utiliser le split tunneling — cinq scénarios concrets

Le split tunneling a de vraies utilisations légitimes. Voici les situations où c'est le bon outil :

1. Services de streaming qui détectent et bloquent les endpoints VPN

Netflix, Disney+, Hulu et la plupart des diffuseurs régionaux maintiennent de longues listes d'IPs de datacenters VPN connus et refusent de diffuser lorsqu'ils en détectent une. Vous pouvez soit désactiver le VPN (perdant toute protection) soit split-tunneliser l'application de streaming pour qu'elle voie votre vraie IP pendant que tout le reste reste protégé.

2. Applications bancaires et financières avec détection de fraude basée sur la localisation

Les banques traitent fréquemment un changement soudain d'IP vers un datacenter VPN comme un signal de fraude — elles déclenchent une authentification renforcée, bloquent des transactions, ou verrouillent brièvement le compte. Exclure l'application de la banque du tunnel préserve votre relation d'IP réelle avec la banque de façon cohérente. C'est une correction d'ergonomie, pas une amélioration de sécurité — la connexion de la banque est déjà chiffrée en TLS, donc le VPN n'apportait de toute façon pas grand-chose en sécurité à cette session spécifique.

3. Ressources du réseau local (NAS, imprimante, maison connectée)

Quand le VPN capture tout le trafic, votre appareil ne peut plus atteindre l'imprimante à 192.168.1.50 car cette IP est inaccessible via le tunnel VPN. Le split tunneling basé sur la destination (en excluant 192.168.0.0/16 et 10.0.0.0/8) rétablit l'accès local sans désactiver le VPN pour l'internet public. De nombreux clients VPN font cela automatiquement par défaut ; d'autres non.

4. Applications sensibles à la latence

Les jeux en ligne compétitifs, les conférences vidéo en direct et les appels vocaux souffrent quand une latence supplémentaire est introduite par le routage via un serveur VPN dans une région distante. Exclure ces applications spécifiques peut récupérer la latence tout en gardant tout le reste chiffré. Le compromis : ces applications sont désormais identifiables par votre FAI et visibles pour les observateurs réseau.

5. VPN professionnel en parallèle d'un VPN personnel

Si votre employeur exige un VPN d'entreprise pour accéder aux ressources internes, et que vous souhaitez que votre trafic personnel passe par un VPN différent (orienté vie privée), le split tunneling sur le VPN d'entreprise — en n'y faisant passer que les plages d'IP d'entreprise — laisse le reste de votre trafic disponible pour le VPN personnel. C'est une configuration avancée, mais c'est un moyen propre de séparer le trafic professionnel du trafic personnel.

Quand NE PAS utiliser le split tunneling — les pièges pour la vie privée

Le split tunneling rend votre comportement réseau plus complexe, et un comportement réseau complexe fuit de façon non évidente. Les modes de défaillance les plus courants :

Fuites DNS par le chemin de contournement

Même quand le trafic TCP d'une application est routé hors du tunnel, ses requêtes DNS peuvent toujours être configurées pour utiliser le résolveur DNS du VPN — ou pire, peuvent retomber sur le résolveur DNS du FAI si le client VPN ne gère pas soigneusement le DNS système. Résultat : une application qui devrait être invisible pour votre FAI devient partiellement visible. Le FAI voit la requête DNS pour banking.example.com même si la connexion TCP ultérieure est passée par un autre chemin. Nous avons une analyse plus approfondie de la façon dont le chiffrement DNS s'intègre dans notre guide DNS-over-HTTPS.

Confusion application/domaine

Le split tunneling par application route selon l'identité du processus, mais les applications modernes font des connexions vers de nombreux domaines. Votre « application de streaming » charge probablement des publicités, de la télémétrie, des APIs de recommandation et des endpoints d'analyse provenant de dizaines de domaines différents — dont certains sont partagés avec des applications que vous souhaitez tunneliser. Exclure l'application entière signifie exclure toutes ces connexions. Le split tunneling basé sur le domaine a le problème inverse : une seule application peut charger le même domaine CDN à la fois pour la vidéo en streaming (que vous souhaitez non protégée) et pour du contenu que vous préféreriez ne pas révéler.

Fuites IPv6

De nombreuses implémentations de split tunnel ont été conçues quand IPv4 était la seule préoccupation de routage. Si votre réseau dispose d'une connectivité IPv6 et que les règles de split tunnel n'incluent pas explicitement les routes IPv6, les paquets qui devraient être tunnelisés peuvent sortir via IPv6 hors du tunnel. C'est l'une des fuites VPN les plus courantes en 2026 et elle est presque toujours causée par une configuration incomplète des règles de split tunnel. Testez-le avec un test de fuite IPv6 après avoir activé le split tunneling.

Interactions avec le kill switch

Un kill switch est conçu pour bloquer tout le trafic si le VPN tombe, afin que rien ne fuite sans protection. Avec le split tunneling activé, la logique du kill switch devient plus complexe — le kill switch doit toujours autoriser les applications split-tunnelisées à communiquer, mais seulement celles-là, et seulement quand le VPN lui-même est aussi hors service. De nombreux clients VPN ont des bugs où le kill switch ne parvient pas à bloquer les applications tunnelisées quand le VPN tombe, ou bloque incorrectement les applications split-tunnelisées qui devraient continuer à fonctionner. Testez la combinaison explicitement.

Comparaison des modes de split tunneling

Comment fonctionne le split tunneling sur chaque système d'exploitation

iOS — limité et indirect

iOS n'expose pas une vraie API de split tunneling aux applications VPN tierces. Le framework NetworkExtension permet de configurer un VPN soit à l'échelle du système (tout le trafic) soit par application (uniquement les applications explicitement enregistrées par un profil MDM). Le vrai routage split par application nécessite NEAppProxyProvider d'Apple avec un profil de configuration distribué par MDM — ce qui implique un scénario d'appareil géré. Les applications VPN grand public sur iOS qui annoncent le « split tunneling » implémentent généralement des exclusions basées sur la destination (par exemple, en excluant des plages d'IP spécifiques du tunnel) ou utilisent l'API de règles à la demande pour activer conditionnellement le VPN selon le SSID Wi-Fi ou la correspondance de domaine. Le split tunneling par application pour les utilisateurs iOS grand public n'est pas vraiment disponible.

Android — support natif

L'API VpnService d'Android supporte le routage par application nativement. Le client VPN peut appeler addAllowedApplication() ou addDisallowedApplication() pour spécifier quelles applications passent par le tunnel. Le système d'exploitation gère le routage par application de façon transparente — le client VPN n'a pas besoin de faire du marquage au niveau des paquets. Android supporte également le paramètre système « VPN permanent » avec une option « Bloquer les connexions sans VPN », qui combine le comportement kill switch avec la configuration par application : les applications tunnelisées passent par le tunnel, les applications non tunnelisées passent en direct, et si le VPN tombe, les applications tunnelisées sont bloquées.

macOS — l'implémentation varie

macOS supporte le split tunneling via plusieurs mécanismes : le framework NetworkExtension (similaire à iOS, avec plus de flexibilité), les filtres de paquets configurés via des règles pf, ou la manipulation de la table de routage par des clients VPN s'exécutant avec des privilèges élevés. Le split tunneling par application sur macOS est fonctionnel mais nécessite que le client VPN interroge le noyau pour obtenir les associations socket-vers-processus. Le split basé sur la destination est simple et fiable.

Windows — la plateforme la plus courante pour le split tunneling

Les clients VPN Windows utilisent le split tunneling depuis plus d'une décennie. La plateforme de filtrage Windows (WFP) fournit l'inspection des paquets au niveau noyau et l'API de décision de routage dans laquelle les clients VPN s'accrochent. Le split tunneling par application sur Windows est bien supporté et largement déployé. La plupart des déploiements VPN d'entreprise utilisent le split tunneling Windows pour s'assurer que le trafic d'entreprise passe par le tunnel d'entreprise tandis que le trafic internet général passe en direct — en partie pour les performances, en partie pour réduire la charge sur les concentrateurs VPN d'entreprise.

Erreurs courantes lors de la configuration du split tunneling

Observer comment les gens configurent mal le split tunneling révèle quelques schémas récurrents. Si vous le configurez, vérifiez-vous par rapport à cette liste :

• Ne pas tester les fuites DNS après l'activation. Effectuez un test de fuite (dnsleaktest.com ou similaire) après chaque changement de configuration. Si vous voyez le résolveur DNS de votre FAI listé pour une application qui devrait être tunnelisée, le contournement laisse fuiter le DNS.
• Oublier que les navigateurs sont particuliers. Un navigateur qui exécute une application web de streaming route à la fois la vidéo en streaming et vos autres onglets via le même processus. Exclure le navigateur exclut toute votre navigation. Utilisez un profil de navigateur séparé ou une application différente pour le cas du streaming.
• Ne pas gérer IPv6. Désactivez complètement IPv6 si votre client VPN ne le gère pas explicitement. Le taux de fuite dû à des règles de split tunnel IPv6 oubliées est élevé.
• Utiliser des règles basées sur le domaine pour des décisions critiques en matière de sécurité. Le split tunneling basé sur le domaine convient pour des ajustements d'ergonomie. Il n'est pas suffisamment fiable pour imposer « cette application sensible doit toujours passer par le VPN » — pour cela, utilisez des règles basées sur l'application avec l'application explicitement tunnelisée, idéalement en mode liste d'autorisation.
• Ne pas réviser les règles trimestriellement. Les applications s'ajoutent et se retirent ; les nouvelles applications d'un même éditeur n'héritent de rien des anciennes. Auditez périodiquement votre ensemble de règles de split tunnel.

Le verdict honnête sur le split tunneling

Le split tunneling est vraiment utile pour des problèmes spécifiques — les applications de streaming qui détectent les VPN, les applications bancaires qui signalent les connexions VPN, l'accès au réseau local — et il a une longue histoire de déploiement légitime en environnement d'entreprise. Pour les consommateurs, la formulation honnête est que c'est avant tout un outil d'ergonomie et ensuite un outil de confidentialité. Chaque règle de split tunnel affaiblit le modèle de protection d'une façon spécifique, et le compromis sécuritaire ne vaut le coup que lorsque la protection n'aurait de toute façon pas aidé ce trafic (par exemple, une session bancaire déjà chiffrée en TLS et allant vers une seule destination bien connue).

Si votre modèle de menace est « Je veux un VPN sur des réseaux Wi-Fi publics hostiles pour que l'opérateur du réseau local ne puisse pas observer mon trafic », un tunnel complet est la bonne réponse. N'activez pas le split tunneling simplement parce que le client VPN le propose — chaque exclusion est une brèche. Si votre modèle de menace est « Je veux la plupart du trafic protégé mais des applications spécifiques ont besoin du réseau réel », le split tunneling est le bon outil, mais configurez-le soigneusement, testez les fuites DNS et IPv6 ensuite, et révisez les règles périodiquement. La référence technique de la documentation de démarrage rapide WireGuard montre comment les décisions de routage sous-jacentes fonctionnent au niveau du protocole.

Casper's Cloak utilise par défaut une architecture à tunnel complet car le modèle de menace contre lequel nous protégeons — réseaux hostiles, surveillance par les FAI, pistage publicitaire — bénéficie du modèle plus simple « tunneliser tout ». Nous couplons cela avec un filtrage des traceurs au niveau DNS et une détection des menaces par IA pour les destinations malveillantes connues, de sorte que le tunnel complet fait aussi un filtrage actif — pas seulement du routage. Pour les cas particuliers du streaming et de la banque, la bonne décision est généralement de se déconnecter brièvement plutôt que de maintenir un ensemble permanent d'exclusions de split tunnel que vous finirez par oublier.