Pourquoi le tunnel complet a réparé ma mauvaise route alors que le split tunneling n’y arrivait pas : mon déploiement utilisait plus d’un chemin

Le git push fonctionnait.

C’est ce qui m’a fait perdre du temps.

Je devais publier un correctif avant que le client commence ses tests du matin. Le code était prêt, le dépôt répondait, ma fibre dépassait largement les 700 Mbit/s.

Puis la construction a voulu récupérer plusieurs couches d’une image depuis un registre distant.

Une première couche est arrivée. La deuxième aussi. La suivante est restée bloquée. Nouvel essai. Même chose.

Le tableau de bord du service s’ouvrait dans le navigateur. L’authentification passait. SSH vers le serveur répondait. Pourtant, certains téléchargements nécessaires au déploiement expiraient ou avançaient à quelques kilo-octets par seconde.

J’ai donc fait ce qui me semblait le plus propre : utiliser le split tunneling uniquement pour l’outil qui posait problème.

Pourquoi envoyer tout l’ordinateur dans un VPN si seul mon registre semblait avoir une mauvaise route ?

Sur le papier, c’était précisément à cela que servait le split tunneling.

Dans mon cas, c’était aussi précisément pour cela qu’il n’a pas suffi.

J’avais une connexion rapide, mais pas une bonne route vers tout

Au début, je continuais à regarder le débit. Speedtest : excellent. Navigation : normale. Streaming : normal. Donc, dans ma tête, Internet allait bien. Sauf qu’Internet n’est pas une seule route.

Le 1er août 2026, Hetzner a par exemple signalé un incident sur son backbone européen ayant provoqué des boucles de routage et des pertes de paquets. Ce n’était pas l’incident que j’étais en train de subir, mais il illustrait parfaitement ce que mes propres tests commençaient à montrer : une destination peut devenir difficile à atteindre alors que presque tout le reste fonctionne normalement.

Mon fournisseur d’accès savait très bien m’emmener vers la plupart des services. Vers certaines adresses nécessaires à mon déploiement, le trajet semblait beaucoup moins bon. Un VPN peut changer ce chemin de manière assez simple. Sans VPN :

mon ordinateur → mon FAI → les réseaux intermédiaires → destination.

Avec VPN :

mon ordinateur → serveur VPN → autre chemin de sortie → destination.

Le service final reste le même.

Ce qui change, c’est la route utilisée pour l’atteindre.

Et à ce moment-là, je pensais encore que détourner seulement l’application problématique serait suffisant.

Le split tunneling ne choisit pas une « meilleure Internet »

C’est là que mon intuition était fausse.

Je pensais au split tunneling comme à une version plus précise du VPN : je sélectionne l’application malade, elle obtient la bonne route, problème terminé.

En réalité, il applique simplement des règles.

Microsoft distingue le force tunnel, où le VPN devient la route par défaut, du split tunnel, où seules certaines routes passent dans le VPN tandis que le reste continue par l’interface physique.

Cloudflare décrit la même logique avec ses modes d’inclusion et d’exclusion : seuls les IP ou domaines concernés sont envoyés dans le tunnel, et le DNS peut encore suivre ses propres règles.

Autrement dit, le split tunneling ne comprend pas mon intention.

Il ne sait pas que « je veux que tout ce qui participe à ce déploiement prenne la meilleure route ».

Il sait seulement :

ce flux-ci passe dans le tunnel ; celui-là, non.

Et mon déploiement n’était justement pas un seul flux. Le client contactait un service. L’authentification en contactait un autre. Les métadonnées venaient d’une destination. Les grosses couches pouvaient être servies ailleurs. Certaines étapes ouvraient le navigateur ou passaient par un processus auxiliaire.

J’avais changé la route d’une partie de mon travail en supposant que cette partie représentait tout le travail.

Mon split tunnel avait réparé le premier morceau, pas le déploiement

J’ai ajouté mon outil de ligne de commande au tunnel. Nouvel essai. L’authentification s’est faite rapidement. Le manifeste de l’image est arrivé. J’ai cru avoir gagné. Puis une grosse couche a commencé à descendre. 12 %. 18 %. Pause. Nouvelle tentative. Cette fois, elle s’est arrêtée encore plus tôt.

J’ai ouvert la liste des exceptions. Je pouvais continuer à bricoler. Ajouter un autre processus. Chercher les domaines du stockage d’objets. Identifier les différentes adresses derrière le registre. Vérifier le DNS. Puis recommencer lorsqu’un domaine ou une IP changeait. C’était intéressant comme exercice réseau.

À vingt minutes d’un déploiement, beaucoup moins.

Une discussion publique de mars 2026 montrait exactement ce type de friction : un utilisateur essayait de faire passer WinSCP et un client SSH dans un split tunnel, tout en continuant à rencontrer des erreurs réseau. D’autres participants décrivaient aussi des comportements inattendus avec certaines applications ou l’accès au réseau local.

Ce qui m’intéressait dans ces témoignages n’était pas de conclure que le split tunneling était mauvais.

C’était de voir à quel point la frontière entre « une application » et « tout ce dont cette application dépend » pouvait devenir floue.

À ce moment-là, ma question a changé.

Je ne cherchais plus :

quel processus manque encore dans ma liste ?

Je cherchais :

que se passe-t-il si je retire complètement la mauvaise route de cette session ?

J’ai arrêté de découper le déploiement en morceaux

J’avais gardé OnlydogVPN sur l’ordinateur comme solution de secours pour les réseaux qui me posaient problème.

Je l’ai ouvert.

Cette fois, je n’ai créé aucune règle de split tunneling.

J’ai choisi le mode adapté à une connexion problématique et laissé l’ensemble de la session passer par le tunnel.

Navigateur. Terminal. Registre. Tout du même côté. J’ai reconnecté. Puis j’ai repris exactement là où j’avais échoué. Authentification. Immédiate. Récupération du manifeste. Puis la grosse couche. 8 %. 21 %. 37 %. J’ai attendu le ralentissement que j’avais déjà vu plusieurs fois. Il n’est pas venu. 64 %. 83 %. 100 %.

La couche suivante est partie. Puis la suivante. L’image complète était enfin locale. J’ai lancé le déploiement. Le serveur a récupéré la nouvelle version. Le contrôle de santé est passé au vert. J’ai actualisé le tableau de bord une dernière fois.

Le correctif était en ligne.

C’était tout ce que j’essayais d’obtenir depuis le début. Pas une règle de routage élégante. Pas une liste d’exceptions parfaite. Un déploiement terminé.

Le tunnel complet n’avait pas réparé mon FAI : il avait cessé d’utiliser son mauvais chemin

C’est seulement après avoir terminé que la différence m’a paru évidente. Le VPN n’avait pas corrigé les tables de routage de mon fournisseur d’accès. Il avait simplement évité que mon trafic vers ces destinations continue à emprunter ce chemin. Mon FAI n’avait plus qu’à m’emmener correctement jusqu’à l’entrée du VPN.

À partir de là, le trafic repartait par un autre réseau. J’ai commencé à voir le problème comme un service de livraison. Le split tunneling revient à confier certains colis précis à un autre transporteur. Cela marche très bien si l’on sait exactement lesquels doivent changer de trajet.

Mon déploiement, lui, ressemblait plutôt à une commande répartie entre plusieurs colis, plusieurs entrepôts et plusieurs bons de livraison.

J’en avais redirigé quelques-uns. Les autres continuaient à passer par le centre de tri qui posait problème. Le tunnel complet avait déplacé toute la commande.

Et soudain, je n’avais plus besoin de savoir quel sous-domaine, quel processus ou quelle adresse IP contenait la couche qui allait se bloquer.

Ce qui m’a fait garder cette configuration, c’est qu’elle supprimait une décision

Le service utilise un transport basé sur HTTP/3 et une interface organisée autour de situations plutôt qu’autour d’une longue combinaison de protocoles, serveurs et règles. Les tests publiés par le service utilisent justement cette approche lorsqu’un problème vient du chemin réseau lui-même.

Mais ce matin-là, ce n’était pas le nom du transport qui m’avait convaincu. C’était la disparition d’une question. Avec mon split tunnel, je demandais : ce processus passe-t-il dans le VPN ? et celui-ci ? et ce domaine ? et cette nouvelle adresse ? Avec le tunnel complet, je demandais simplement :

est-ce que mon déploiement fonctionne par cette route ?

Oui.

Je pouvais m’arrêter là.

Il reste des cas où je choisirais le split tunneling sans hésiter. Si une imprimante locale, une banque ou une application d’entreprise doit rester hors VPN, sa précision devient utile.

Mais dans un workflow éclaté entre navigateur, authentification, registre et services de stockage, cette précision peut aussi devenir une charge : il faut connaître à l’avance toutes les pièces du puzzle.

Le petit service a aussi moins de localisations et moins d’historique public que les fournisseurs les plus établis.

Pour ce problème précis, ce n’était pas ce qui comptait. Je connaissais déjà la mauvaise route. Ce que je ne connaissais pas, c’était tout ce qui continuait encore à l’emprunter.

Pourquoi le tunnel complet peut-il réussir là où le split tunneling échoue ?

Parce qu’ils ne changent pas la route avec la même portée.

Le split tunneling fonctionne très bien lorsque tout le trafic problématique correspond aux règles que l’on a définies.

Mais lorsqu’une même tâche dépend de plusieurs domaines, plusieurs IP, plusieurs processus ou plusieurs étapes d’authentification, il suffit qu’un seul morceau reste sur la route directe pour que l’ensemble paraisse encore cassé.

Le tunnel complet ne demande pas d’identifier ces morceaux un par un. Il remplace la route par défaut de toute la session. Dans mon cas, c’est ce qui a fait la différence. Le split tunneling avait correctement détourné ce que je lui avais demandé de détourner.

Le problème était simplement que mon déploiement avait plus de chemins que je ne le pensais.

Je croyais devoir trouver la bonne exception ; il fallait surtout arrêter d’envoyer une partie de la même version par la route qui avait déjà perdu les premières couches.