VPN connecté, IP inchangée : trois vérifications avant de demander un remboursement

J’avais pris une capture d’écran avant de cliquer sur « Connecter ».
Adresse IP. Fournisseur d’accès. Ville approximative.

Puis j’ai lancé le VPN, attendu que l’interface devienne verte et repris exactement la même capture.

Même adresse.
J’ai changé de serveur. « Connecté » à nouveau.
Même adresse.

À ce moment-là, je ne me demandais pas si le service perdait 8 % ou 12 % de débit. J’avais une question beaucoup plus primitive : est-ce que ce VPN fait réellement passer mon trafic ailleurs, ou est-ce que j’ai payé pour un bouton vert ?

L’onglet de remboursement n’était pas encore ouvert, mais j’y pensais déjà.
Ce réflexe est devenu assez plausible en France.

Le 4 juin 2025, au moment où Aylo a bloqué l’accès français à plusieurs de ses sites dans le contexte des nouvelles obligations de vérification de l’âge, Proton VPN a mesuré une hausse de plus de 400 % des inscriptions par rapport à son niveau de référence, avec un pic horaire supérieur à 1 000 %.

Et le contexte continue d’évoluer : le 29 juillet 2026, l’Arcom a annoncé intervenir contre 31 nouveaux sites ne respectant pas les règles de vérification de l’âge.

Autrement dit, beaucoup de nouveaux utilisateurs n’installent pas un VPN parce qu’ils veulent comprendre le routage réseau. Ils veulent résoudre quelque chose maintenant. Et quand l’application dit « Connecté » alors que l’adresse affichée ne bouge pas, le remboursement paraît être la conclusion logique.

C’était exactement le piège dans lequel j’étais en train de tomber.

Avant de conclure que le VPN ne changeait pas mon IP, il me restait trois choses très simples à vérifier : quelle adresse je regardais, quelle application j’utilisais pour la regarder et quelle partie de ma connexion passait réellement dans le tunnel.

Est-ce vraiment votre adresse IP publique ?

Ma première erreur était presque embarrassante.

Dans les paramètres Wi-Fi de l’ordinateur, je voyais toujours une adresse en 192.168.x.x. Elle n’avait pas bougé après la connexion au VPN.

Pendant quelques minutes, j’ai pris cela pour une preuve.
Ça n’en était pas une.

Les plages 10.x.x.x, 172.16.x.x à 172.31.x.x et 192.168.x.x sont réservées aux réseaux privés. Cette adresse sert essentiellement à dire au routeur : « cet appareil-ci, dans cette maison, c’est moi ».

Le VPN n’a aucune raison de changer cette petite étiquette collée à l’intérieur du réseau.
Ce qui m’intéressait était l’adresse présentée aux sites Internet.
La vérification utile tient donc en quelques secondes.

VPN coupé, j’ouvre un service qui affiche mon adresse IP publique et je note le résultat.
VPN connecté, je recharge le test.
Si l’adresse publique change, le fait que 192.168.x.x reste identique n’a rien d’anormal.

Dans mon cas, ce premier contrôle a éliminé une fausse alerte… mais pas le problème.
Mon adresse locale n’avait pas changé, ce qui était attendu.
Mon adresse publique, elle, n’avait pas changé non plus.

Là, le badge vert ne suffisait plus.

L’application utilisée pour le test passe-t-elle dans le VPN ?

C’est ce contrôle qui m’a fait arrêter de changer de serveur au hasard.
Un VPN peut être connecté sans prendre en charge toutes les applications de l’appareil.

Android permet explicitement à un service VPN d’inclure certaines applications dans le tunnel ou d’en laisser d’autres utiliser directement le réseau normal. C’est notamment ce qui rend possible le split tunneling.

L’image la plus simple est celle d’une autoroute avec une voie de sortie.

Le tunnel VPN peut parfaitement être ouvert. Mais si votre navigateur a reçu l’instruction de prendre la sortie juste avant, le site utilisé pour vérifier votre IP continuera naturellement à voir la connexion habituelle.

Les deux observations peuvent donc être vraies en même temps :
le VPN fonctionne ;
le navigateur avec lequel vous le testez ne l’utilise pas.

Je suis allé voir les exceptions.
Et mon navigateur était là.

Je l’avais ajouté quelques jours auparavant pour résoudre un problème avec un site qui refusait les connexions VPN, puis j’avais complètement oublié ce réglage.

Je l’ai retiré.
Déconnexion.
Reconnexion.

Cette fois, le vérificateur a affiché une autre IPv4.

C’est à cet instant que mon diagnostic a vraiment changé. Si je m’étais arrêté au mot « Connecté », je n’aurais rien compris. Si je m’étais arrêté à la première adresse inchangée, j’aurais accusé le fournisseur.

Le problème se trouvait entre les deux : le tunnel existait, mais l’application que j’observais avait reçu l’autorisation de l’éviter.

Ce genre de confusion apparaît aussi dans les discussions d’assistance publiques. En 2026, un utilisateur de Norton décrivait par exemple un client affiché comme connecté alors que le VPN ne s’initialisait pas correctement et que la connexion observée restait celle du réseau normal.

L’intérêt de ce témoignage est moins le fournisseur concerné que le réflexe qu’il suggère : un voyant « Connected » est un état de l’application, pas encore une preuve de ce que voit Internet.

À ce stade, j’avais corrigé mon premier vrai problème.

Mais avant de ranger le téléphone, il restait un dernier test. Et c’est celui qui évite de croire que tout est réglé simplement parce qu’une seule adresse a changé.

Avez-vous regardé IPv4 et IPv6 ?

Une connexion moderne peut avoir, pour simplifier, deux portes vers Internet.
IPv4.
IPv6.

Si le VPN prend correctement en charge l’une mais laisse l’autre suivre la connexion habituelle, deux tests peuvent donner des réponses différentes.

Il n’est pas nécessaire de connaître une table de routage pour comprendre le principe. Le VPN construit une route protégée ; le système doit ensuite savoir quel trafic doit emprunter cette route. La documentation de WireGuard illustre ce fonctionnement avec AllowedIPs = 0.0.0.0/0 pour couvrir toutes les destinations IPv4, tandis que le protocole prend également en charge IPv6.

J’ai donc utilisé un test qui séparait clairement les deux.
IPv4 : nouvelle adresse.
IPv6 : encore celle du fournisseur d’accès.

Voilà pourquoi mon premier « ça marche » était encore incomplet.

Le grand fournisseur que j’utilisais permettait de corriger la situation. C’est d’ailleurs l’une des forces des services établis : beaucoup de documentation et suffisamment de réglages pour modifier précisément le comportement du tunnel.

J’ai trouvé le paramètre concerné.
J’ai reconnecté.
Puis j’ai refait le test.

Cette fois, les vérifications publiques ne me ramenaient plus à ma connexion d’origine.

Le VPN n’était donc pas défaillant. Mais j’avais passé près d’une demi-heure à transformer son mot « Connecté » en quelque chose que je pouvais réellement constater.

Et cette demi-heure a changé la question que je posais.
Je ne cherchais plus seulement : « Est-ce que ce VPN peut changer mon IP ? »

Je cherchais : « Combien de décisions dois-je prendre avant de pouvoir vérifier qu’il l’a vraiment fait ? »

J’ai essayé un VPN où le diagnostic devenait presque inutile

J’ai installé OnlydogVPN sur le même appareil.

Avant de le connecter, j’ai rétabli la connexion normale et noté une dernière fois mon adresse publique. Je voulais repartir exactement du même point.

L’approche était plus courte : l’interface part de l’usage que je veux faire de la connexion plutôt que de me demander immédiatement de choisir parmi une succession de serveurs, de protocoles et de paramètres réseau.

J’ai choisi la connexion rapide.
Connecté.
Puis j’ai refait les mêmes contrôles qui venaient de m’occuper pendant une demi-heure.

Premier vérificateur : l’adresse du fournisseur d’accès avait disparu.
Deuxième navigateur : même sortie VPN.
L’application utilisée plus tôt : elle suivait elle aussi la nouvelle route.

Je suis resté quelques secondes devant le résultat parce qu’il n’y avait, justement, rien de particulier à interpréter.

Le statut disait connecté.
Les tests racontaient la même chose.
Je n’avais pas eu besoin de diagnostiquer le VPN pour croire son bouton de connexion.

Pour cette vérification, c’était finalement l’avantage qui comptait le plus. Pas une différence théorique de débit. Pas cinquante emplacements supplémentaires sur une carte. Simplement moins d’endroits où je pouvais accidentellement créer une exception, oublier un réglage puis conclure que le service ne fonctionnait pas.

Le service utilise aussi un transport basé sur HTTP/3. HTTP/3 s’appuie sur QUIC, un protocole conçu notamment pour mieux supporter les changements de chemin réseau. Je n’avais pas installé l’application pour tester cela, mais la suite m’a donné une occasion assez naturelle de le remarquer.

Une fois l’adresse vérifiée, j’ai coupé le Wi-Fi et laissé le téléphone passer sur le réseau mobile.

La connexion a suivi le changement et est revenue sans que j’aie à recommencer toute ma petite procédure de vérification.

C’était un bénéfice plus discret, mais il répondait à une autre irritation très réelle : après avoir enfin obtenu une connexion qui faisait ce que j’attendais, je n’avais pas envie de recommencer à la surveiller dès que le réseau changeait.

Le service plus petit conserve toutefois une limite évidente : il propose moins de régions que les grands fournisseurs. Si j’avais absolument besoin d’une sortie dans un pays précis, je vérifierais d’abord qu’elle existe.

Mais ce n’était pas mon problème ce jour-là.
Je n’avais pas besoin de davantage de destinations.

J’avais besoin que « Connecté » et « mon trafic sort bien ailleurs » cessent d’être deux choses différentes.