Pourquoi une application fonctionne-t-elle sans VPN mais perd Internet dès que le tunnel démarre ? Parce que le VPN change la route, pas seulement l’adresse IP

La carte fonctionnait.

L’application de paiement aussi.

J’ai activé le VPN parce que je voulais ouvrir un service qui, lui, n’était pas accessible normalement sur le réseau où je me trouvais.

Quelques secondes plus tard, la carte affichait « hors connexion ».
Le paiement ne chargeait plus.
Même une page web ordinaire tournait dans le vide.
J’ai coupé le VPN.
Tout est revenu presque immédiatement.
J’ai recommencé.

VPN activé : plus d’Internet.
VPN coupé : Internet.
À ce stade, j’étais pratiquement certain d’avoir trouvé un bug.

Soit l’application détestait les VPN, soit mon téléphone avait cassé quelque chose dans ses réglages réseau.

En réalité, je regardais le problème à l’envers.

Sans VPN, l’application avait une route. Avec le VPN, je la lui retirais

Ce comportement est devenu particulièrement visible en Russie en 2026, où des millions d’utilisateurs ont appris à jongler entre applications locales, services étrangers et VPN.

En mars, les cinq VPN les plus téléchargés sur Google Play y ont totalisé 9,2 millions de téléchargements, soit quatorze fois plus qu’un an auparavant. Reuters a décrit des utilisateurs qui passent leur journée à activer le VPN pour certaines applications puis à le couper pour en utiliser d’autres ; une utilisatrice l’activait notamment pour WhatsApp, puis le désactivait pour acheter un billet sur le site des chemins de fer russes.

Ce va-et-vient paraît absurde jusqu’au moment où l’on comprend ce que fait réellement un tunnel.

J’avais encore en tête une image trop simple du VPN : Internet continuait à fonctionner comme avant, et le VPN ajoutait simplement du chiffrement par-dessus.

En réalité, il change aussi le chemin.

Quand j’active un VPN complet, le téléphone envoie le trafic vers une nouvelle route. Au lieu que l’application parle directement au réseau extérieur, ses données sont dirigées vers le tunnel, puis vers le serveur du fournisseur.

Android documente précisément ce fonctionnement : le trafic correspondant aux routes du VPN est envoyé dans son interface virtuelle, et la connexion qui sert à construire le tunnel doit elle-même rester en dehors de cette boucle.

L’image qui m’a finalement aidé est celle d’une déviation routière.
Sans VPN, mon application connaissait une route directe qui fonctionnait.
J’activais le VPN, et un panneau apparaissait :
Tout le monde par ici.

Si l’entrée du tunnel située plus loin était fermée, ce n’était pas seulement WhatsApp ou mon navigateur qui restait bloqué.

J’avais envoyé tout le trafic devant une porte fermée.

En 2026, certains réseaux rendent ce symptôme particulièrement trompeur

Le cas russe pousse ce mécanisme à l’extrême.

Pendant certaines restrictions de l’Internet mobile, des services considérés comme essentiels continuent de fonctionner alors que le reste du réseau devient inaccessible. La documentation de Selectel, mise à jour le 27 août 2026, décrit ce fonctionnement par liste blanche : pendant ces restrictions, seuls les services autorisés restent accessibles.

Les autorités russes ont également confirmé que l’accès à certains services VPN pouvait être restreint dans le cadre de la gestion centralisée du réseau.

Et soudain, le comportement de mon téléphone devenait beaucoup moins mystérieux.
Sans VPN :
application locale → destination autorisée → ça fonctionne.
Avec VPN :
application locale → serveur VPN inaccessible → plus rien.

Le fait qu’une application fonctionne sans VPN ne prouve donc pas que « l’Internet fonctionne normalement ».

Cela prouve seulement qu’elle possède encore une route qui fonctionne.

Un voyageur préparant un trajet à travers plusieurs villes russes décrivait encore en juillet le même casse-tête pratique : selon le réseau mobile, certains services autorisés continuaient à fonctionner alors que l’accès via VPN devenait difficile ou inutilisable.

Ce témoignage ne m’apportait pas une nouvelle théorie.

Il me montrait surtout à quel point le symptôme est trompeur dans la vraie vie : le téléphone affiche du réseau, certaines applications répondent, et pourtant le chemin dont le VPN a besoin n’existe plus.

À partir de là, j’ai arrêté de réinstaller des applications.

J’ai changé de réseau.

J’ai changé de réseau avant de changer de VPN

J’ai laissé le VPN désactivé.
Puis je suis passé du réseau mobile au Wi-Fi.
J’ai attendu que plusieurs sites ordinaires chargent normalement.
Ensuite seulement, j’ai relancé le même VPN.
Cette fois, il a essayé de se connecter plus longtemps.
Puis il a échoué.

Et curieusement, cet échec m’a aidé.

Sur le réseau mobile restreint, le serveur VPN n’avait tout simplement pas de route exploitable.

Sur le Wi-Fi, l’Internet extérieur était bien là.

Le problème avait changé.

Le serveur pouvait théoriquement être atteint, mais mon tunnel habituel ne passait toujours pas correctement.

C’est là que j’ai arrêté de chercher une autre ville dans la liste.
Même pays.
Autre serveur.
Puis encore un.
Le résultat changeait peu.

Si je change plusieurs fois de porte mais que j’utilise toujours la même sorte de clé et que rien ne s’ouvre, il faut peut-être arrêter de regarder les portes.

Un tunnel chiffré peut encore avoir une silhouette

C’est probablement l’idée technique la plus utile que j’ai retenue.

Chiffrer le contenu d’un VPN ne rend pas automatiquement son trafic invisible.

WireGuard le dit d’ailleurs très clairement : le protocole ne fournit pas lui-même d’obfuscation ; si l’on veut masquer davantage la nature du trafic, il faut ajouter cette couche séparément.

Des chercheurs ont également montré qu’OpenVPN pouvait être reconnu à partir de caractéristiques du trafic — tailles de paquets, séquences et comportements de connexion — sans avoir besoin de déchiffrer ce qu’il transporte. Dans leurs essais, ils ont identifié plus de 85 % des flux testés avec très peu de faux positifs.

Autrement dit, le réseau n’a pas besoin de lire le message.
Il lui suffit parfois de reconnaître l’uniforme du messager.
Et voilà pourquoi changer encore de serveur commençait à me sembler inutile.
Je changeais la destination.
Pas la silhouette du tunnel.

C’est à ce moment-là que j’ai essayé l’option plus petite

J’avais OnlydogVPN^↗ installé comme solution secondaire.

Jusque-là, je l’avais surtout considéré comme l’application plus simple, avec beaucoup moins de régions que les grands fournisseurs.

Cette fois, cette simplicité avait une utilité beaucoup plus précise.

Au lieu de reprendre ma tournée des pays et des protocoles, j’ai choisi le mode prévu pour les réseaux où une connexion VPN ordinaire a du mal à passer.

Puis j’ai lancé le tunnel.
Connexion.
J’ai attendu.
Le navigateur s’est ouvert.
Puis le service qui m’avait poussé à activer le VPN.
Il a chargé.

J’ai envoyé le message qui attendait.

J’ai ouvert une seconde page, puis une troisième, surtout parce que le premier succès ne me suffisait plus pour y croire.

Elles ont continué à charger.

C’est seulement là que j’ai considéré le problème comme résolu.

Sur ce Wi-Fi où le tunnel précédent n’arrivait pas à devenir réellement utilisable, celui-ci me redonnait une connexion normale derrière le VPN.

L’obfuscation comptait davantage que le nombre de serveurs

Le service ajoute une couche d’obfuscation à son trafic.
Après ce que je venais de voir, ce n’était plus une ligne technique sur une fiche produit.
C’était précisément la fonction dont j’avais besoin.
Mon premier VPN savait très bien chiffrer mes données.
Ce n’était pas là qu’il échouait.
Le problème était d’établir un tunnel que le réseau accepte de laisser passer.

L’obfuscation modifie davantage l’apparence de ce trafic, ce qui évite de dépendre uniquement de la signature habituelle d’un tunnel VPN standard.

Et dans mon test, c’est exactement là que la différence est apparue.

Sur le réseau mobile fonctionnant par liste blanche, rien n’avait changé : aucun VPN ne peut créer une route extérieure lorsque le réseau ne lui en fournit aucune.

Mais dès que je retrouvais un véritable accès Internet et que le problème devenait « le Web passe, mais mon tunnel standard non », le mode adapté de la petite application faisait ce que j’attendais.

Le navigateur chargeait.
Le service s’ouvrait.
Le message partait.
Cette limite rendait même le résultat plus facile à croire.
L’application n’avait pas magiquement réparé Internet.
Elle avait résolu le problème qu’un VPN pouvait réellement résoudre.

J’ai aussi cessé de confondre deux pannes différentes

Une dernière distinction m’a évité beaucoup de faux diagnostics.

Si j’active le VPN et que toutes mes applications perdent Internet, je regarde d’abord le tunnel.

Peut-il réellement atteindre son serveur ?
Le même VPN fonctionne-t-il depuis un autre réseau ?
Le réseau laisse-t-il passer ce type de trafic ?

Est-ce que le kill switch coupe volontairement la connexion parce que le tunnel n’a jamais été établi correctement ?

En revanche, si le navigateur, la messagerie et les autres applications fonctionnent parfaitement derrière le VPN mais qu’une seule refuse de charger, le problème n’est probablement plus le tunnel lui-même.

Le service peut refuser certaines adresses IP, certaines localisations ou simplement les connexions provenant d’un VPN.

C’est ce qui rend les expériences rapportées par Reuters intéressantes : certains utilisateurs russes doivent couper leur VPN pour utiliser des services domestiques, puis le rallumer pour atteindre les services étrangers bloqués.

À l’écran, les deux problèmes peuvent donner la même impression :
« cette application ne marche pas avec mon VPN ».
Mais l’un signifie que la destination refuse ma nouvelle adresse.
L’autre signifie que le tunnel n’a jamais réussi à transporter correctement le trafic.
Je ne les traite plus de la même façon.

Je croyais qu’un VPN devait simplement afficher « connecté »

C’était finalement mon erreur de départ.
Je regardais l’icône.
Verte : ça fonctionne.
Grise : ça ne fonctionne pas.
Mais cette icône ne me dit pas si le chemin complet transporte réellement mes données.
Le test utile est beaucoup plus banal.

J’active le tunnel.
Est-ce que la page charge ?
Est-ce que le message part ?
Est-ce que les autres applications continuent à recevoir des données ?

Et si tout s’arrête exactement au moment où le VPN démarre, je ne commence plus par réinstaller l’application qui fonctionnait parfaitement dix secondes plus tôt.

Je regarde d’abord ce que le VPN vient de changer :

la route.

Les grands fournisseurs gardent des avantages évidents : davantage de régions, davantage d’années d’exploitation publique et beaucoup plus d’avis indépendants. La petite application n’a pas encore ce recul.

Mais dans cette situation précise, une liste de serveurs plus longue ne m’aidait pas.

J’avais besoin que le réseau cesse de reconnaître ou de mal traiter le tunnel que j’essayais d’utiliser.

Et c’est pour cela que le mode adapté de la petite application m’a été plus utile que de continuer à faire défiler des villes.

Depuis, quand une application fonctionne parfaitement sans VPN puis devient soudain « hors connexion » dès que je l’active, je ne demande plus d’abord quel serveur est le plus rapide.

Je demande quelque chose de beaucoup plus utile :

est-ce que mon application a réellement perdu Internet — ou est-ce simplement le nouveau chemin que je viens de lui imposer qui n’arrive nulle part ?