Split tunneling en télétravail : j’ai voulu simplifier ma connexion, puis j’ai compris pourquoi l’exception devait rester plus petite que mon navigateur

Le split tunneling a fonctionné du premier coup. C’était justement le problème.

Je travaillais de chez moi avec l’ordinateur utilisé pour mes missions professionnelles. Le VPN de l’entreprise était connecté, Teams fonctionnait, le portail interne aussi, mais j’avais également un VPN personnel sur la machine pour ma navigation en dehors du travail.

Faire fonctionner les deux en même temps était pénible. Une page refusait de s’ouvrir, Teams hésitait, puis mon navigateur semblait prendre la mauvaise route.

J’ai donc choisi la solution qui paraissait la plus propre: le split tunneling.

J’ai exclu mon navigateur du VPN personnel. Il utiliserait désormais la connexion normale; le reste continuerait à passer par le tunnel.

Actualisation. Le portail s’est ouvert. Teams s’est stabilisé. Parfait.

J’ai continué à travailler pendant presque une heure avant de vérifier mon adresse IP dans ce même navigateur.

Elle n’était pas celle que j’attendais.

À cet instant, je n’avais plus un problème de connexion. J’avais un problème beaucoup plus gênant: je ne savais plus exactement quels contrôles de l’entreprise mon navigateur venait de contourner avec ma règle « simple ».

Le piège était de confondre une application avec un usage

Je n’avais pourtant rien fait de particulièrement exotique.

Le split tunneling sert précisément à envoyer certains flux dans un VPN et à laisser les autres emprunter une route directe. Le NIST le définit ainsi: une partie des communications continue par le tunnel de l’organisation tandis qu’une autre peut communiquer directement avec un réseau extérieur.

Le mécanisme n’est donc pas mauvais en soi.

Microsoft recommande même une forme très ciblée de split tunneling pour certains flux Microsoft 365. Des points de terminaison « Optimize » de services comme Teams, Exchange Online ou SharePoint peuvent être envoyés directement vers Microsoft afin de réduire la latence et la charge du VPN d’entreprise.

C’est précisément ce qui m’avait donné confiance.

Si Teams peut sortir directement, pourquoi ne pas simplement exclure le navigateur qui me posait problème?

Parce que « Teams » et « mon navigateur » ne décrivent pas du tout la même chose.

Une exception préparée par l’entreprise peut viser quelques destinations documentées et laisser tout le reste dans le tunnel. Mon navigateur, lui, pouvait contenir à cinq minutes d’intervalle un article personnel, SharePoint, le CRM d’un client, une console SaaS et un document de travail.

J’avais dessiné une déviation autour d’une autoroute entière parce qu’une seule sortie était encombrée.

Et puisque tout s’était remis à fonctionner immédiatement, je n’avais même pas remarqué le problème.

Une page qui s’ouvre ne dit pas par quel poste de contrôle elle est passée

C’est le détail que j’avais sous-estimé.

Une entreprise ne protège pas forcément le travail à distance avec un unique pare-feu placé au bout du VPN. Certains contrôles peuvent se trouver directement dans les services cloud: authentification multifacteur, conformité du terminal, contrôle d’accès conditionnel ou restrictions sur certaines actions.

C’est aussi ce qui permet à Microsoft de recommander des exceptions précises pour Microsoft 365: les flux concernés peuvent sortir directement tout en restant entourés d’autres mécanismes de sécurité du service.

Mais cela ne signifie pas que je peux transformer cette logique en: « cette application m’ennuie, donc elle contourne le tunnel ».

Le VPN de mon entreprise pouvait aussi faire passer mon trafic par un proxy, un filtrage web, une journalisation ou une passerelle de sécurité. Si je créais moi-même une sortie directe trop large, une partie de ce chemin disparaissait.

Le NIST identifie justement ce compromis: le split tunneling peut améliorer les performances, mais il peut aussi soustraire une partie du trafic du télétravailleur aux protections que l’organisation applique sur son chemin VPN.

En France, la logique est similaire. Cybermalveillance.gouv.fr recommande de privilégier les équipements fournis et maîtrisés par l’organisation et de sécuriser les accès distants avec le VPN de l’entreprise. L’ANSSI insiste également sur la maîtrise des accès, des flux et des équipements utilisés en situation de nomadisme.

En relisant tout cela, mon erreur devenait presque embarrassante de simplicité.

J’avais passé du temps à me demander si ma règle de split tunneling était techniquement correcte.

J’aurais dû commencer par une autre question: qui avait décidé que ce trafic pouvait contourner le tunnel de l’entreprise?

Dans mon cas, la réponse était moi. Et cela suffisait à me faire supprimer la règle.

J’ai voulu la rendre plus précise — et j’ai commencé à fabriquer ma propre politique réseau

Ma première réaction avait pourtant été de corriger le réglage plutôt que de l’abandonner.

Pas tout le navigateur, alors. Uniquement certaines applications. Ou certains domaines. Puis j’ai commencé à réfléchir aux exceptions des exceptions.

Une application professionnelle ne communique pas forcément avec une seule destination. Un navigateur sert à plusieurs contextes. Les services cloud évoluent. Même Microsoft recommande, dans son scénario Microsoft 365, de s’appuyer sur les destinations documentées plutôt que de bricoler une règle approximative autour d’un nom d’application.

À ce moment-là, quelque chose m’a frappé. Je n’étais plus en train de simplifier ma matinée.

J’étais en train de devenir l’administrateur non officiel d’une politique réseau que l’équipe informatique n’avait jamais validée.

Un échange public sur Reddit illustrait bien le problème pratique que je rencontrais: lorsqu’un VPN professionnel et un VPN personnel fonctionnent sur la même machine, les routes, le DNS, l’authentification et les applications peuvent commencer à se gêner. La solution évoquée dans cette discussion était beaucoup moins sophistiquée: laisser le VPN professionnel s’occuper du travail et réserver le VPN personnel aux usages personnels.

Ce témoignage ne m’apprenait pas comment configurer mon réseau.

Il m’a surtout fait réaliser que j’étais peut-être en train de résoudre le mauvais problème.

Je n’avais pas forcément besoin de mieux découper les deux VPN sur la même machine. Je pouvais arrêter de les faire cohabiter. J’ai supprimé mes exclusions. Puis j’ai retiré le VPN personnel de l’ordinateur de travail.

Le vrai split était finalement entre mes appareils

J’ai reconnecté uniquement le VPN fourni pour le travail. Le navigateur professionnel a repris la route prévue par l’entreprise. Le portail s’est ouvert.

J’ai téléchargé le document dont j’avais besoin, modifié une ligne dans le tableur partagé et laissé la synchronisation se terminer.

Cette fois, je n’avais plus à me demander si le navigateur suivait une exception, si Teams empruntait une autre route ou si un domaine professionnel venait de sortir du tunnel parce que je l’avais oublié dans une règle.

Il restait pourtant la raison pour laquelle j’avais installé un VPN personnel au départ.

Je ne voulais pas faire passer toute ma vie numérique dans l’environnement professionnel simplement parce que je travaillais depuis chez moi.

J’avais mon téléphone à côté du clavier et mon ordinateur personnel fermé sur le bureau. C’est là que j’ai rouvert la petite application, mais cette fois au bon endroit. Pas sur le PC de travail.

Sur mon appareil personnel.

La différence paraît presque trop simple pour mériter le nom de solution. C’est précisément ce qui m’a plu.

J’ai établi la connexion sur l’ordinateur personnel, puis utilisé le code de vérification prévu par le service pour ajouter mon téléphone sans recréer un compte avec une nouvelle combinaison d’adresse e-mail et de mot de passe.

Le téléphone s’est connecté. L’ordinateur personnel est resté connecté. Et le PC professionnel, lui, n’avait absolument rien à savoir de cette configuration. J’ai repris le test.

Sur la machine de travail, le VPN de l’entreprise était toujours actif. Le portail interne répondait et mes outils professionnels continuaient à suivre leur environnement habituel.

Sur le téléphone et l’ordinateur personnel, la petite application gérait ma connexion privée.

Deux usages. Deux groupes d’appareils.

Plus aucune règle disant que « ce navigateur est personnel, sauf quand il ouvre SharePoint ».

C’était la première configuration de la journée que je pouvais expliquer en une phrase sans ouvrir un panneau de routage.

Ce que j’aimais surtout, c’était de ne plus demander au VPN personnel de décider à la place de l’entreprise

Cette séparation m’a aussi permis de comprendre la limite du petit service sans qu’elle devienne un défaut pour mon usage.

Si mon administrateur voulait déployer sur le poste professionnel une politique précise séparant certaines applications, destinations ou plages IP, je ne demanderais pas à mon VPN personnel de remplacer cet outil.

Cette décision appartient à l’entreprise.

C’est elle qui sait quelles destinations peuvent sortir directement, quels contrôles restent actifs et quelles exceptions sont acceptables. Microsoft peut recommander que certains flux Teams évitent le tunnel central parce qu’il documente les destinations concernées et les protections qui restent autour de ces connexions.

Moi, devant mon ordinateur un mardi matin, je n’ai pas cette visibilité. Et finalement, je n’en ai pas besoin.

La petite application m’a été plus utile en faisant quelque chose de beaucoup plus simple: elle m’a permis de déplacer mon usage personnel vers mes propres appareils, sans transformer la machine professionnelle en terrain de négociation entre deux VPN.

Le service est disponible sur iPhone, Android, Mac et Windows. Dans ce scénario, cette présence sur plusieurs appareils et le partage par code n’étaient pas des fonctions secondaires à cocher sur une fiche technique.

C’était ce qui rendait la séparation facile à conserver après le test. Je n’avais pas seulement trouvé une configuration qui fonctionnait.

J’avais trouvé une configuration que je n’aurais probablement pas envie de « réparer » de nouveau la semaine suivante.

Maintenant, ma règle est beaucoup plus courte

Je ne considère donc plus le split tunneling en télétravail comme un simple choix entre vitesse et sécurité.

Une exception correctement conçue peut être très utile. Microsoft 365 en fournit un bon exemple.

Mais la précision de cette exception compte davantage que le simple fait d’avoir une fonction appelée split tunneling.

Si l’équipe informatique a prévu une route directe pour Teams, je la laisse la gérer.

Si un portail interne doit rester dans le VPN de l’entreprise, je ne crée pas une sortie générale pour mon navigateur simplement parce qu’une autre page ralentit.

Et si je veux mon VPN personnel pendant la journée, mon téléphone et mon ordinateur personnel sont juste à côté.

Au début, mon réglage me semblait intelligent parce qu’il avait immédiatement fait disparaître le problème de connexion.

La configuration finale m’a convaincu pour une raison plus simple: je pouvais regarder chaque écran et savoir immédiatement qui contrôlait sa route.

Le poste professionnel restait du côté de l’entreprise. Mes appareils personnels restaient du mien.

En télétravail, c’est devenu mon critère: une exception approuvée et assez petite pour être comprise vaut mieux qu’un split tunneling personnel tellement pratique qu’on finit par oublier ce qu’il fait passer à côté des contrôles de l’entreprise.