Multi-hop ou deux VPN différents : j’ai surtout découvert qui voyait quoi — et pourquoi ma connexion cassait

Je pensais avoir trouvé quelque chose de plus privé que le multi-hop. Deux VPN différents.

L’idée paraissait presque trop logique : si mon trafic traversait le fournisseur A puis le fournisseur B, aucun des deux ne disposerait exactement de la même vue sur ma connexion. Le premier connaîtrait mon adresse IP réelle, le second verrait surtout la sortie du premier. Et puisque j’avais déjà deux applications installées, je me suis dit que le test prendrait trente secondes.

J’ai connecté la première sur mon téléphone Android. Puis la deuxième. La première s’est déconnectée. J’ai recommencé dans l’autre ordre.

Même résultat.

Ce que j’avais imaginé comme deux tunnels emboîtés ressemblait surtout à deux personnes essayant de s’asseoir sur la même chaise.

J’avais confondu « deux VPN installés » avec « deux VPN en chaîne »

Ce n’était pas un bug particulièrement mystérieux.

Android ne laisse normalement fonctionner qu’une connexion VPN à la fois pour un même utilisateur : lorsqu’une nouvelle interface VPN prend la place, l’ancienne est désactivée.

Autrement dit, sur mon téléphone, appuyer sur « Connecter » dans deux applications différentes ne créait pas :

téléphone → VPN A → VPN B → Internet

Cela créait plutôt :

téléphone → VPN A

puis :

téléphone → VPN B

Le deuxième remplaçait le premier.

Ce petit échec aurait pu rester une curiosité technique. Mais les VPN sont devenus beaucoup plus ordinaires en France, et avec cette banalisation arrive assez vite une deuxième question : une fois qu’on utilise déjà un VPN, faut-il vraiment confier toute la route au même fournisseur ?

En juin 2025, après l’entrée en vigueur des nouvelles mesures de vérification d’âge et le retrait temporaire de plusieurs grands sites pour adultes, la demande de VPN mesurée par Top10VPN a atteint un pic de 570 % au-dessus de son niveau habituel. Pour 2026, les travaux français sur la régulation numérique prévoient explicitement d’examiner les risques de contournement des mesures de protection au moyen des VPN.

Je n’essayais donc plus vraiment de répondre à « à quoi sert un VPN ? ».

Ma question était devenue :

si je fais déjà confiance à un VPN pour cacher ma connexion au réseau devant moi, pourquoi devrais-je faire confiance à un seul fournisseur ?

Pour avoir réellement deux fournisseurs, j’ai dû déplacer l’un des VPN

Sur le téléphone, l’expérience était terminée.

Sur mon ordinateur, j’ai construit quelque chose de plus proche de ce que j’avais imaginé.

J’ai configuré un premier fournisseur sur un petit routeur de voyage. Mon ordinateur se connectait donc à Internet à travers ce routeur et son VPN.

Puis j’ai activé un second fournisseur directement sur l’ordinateur. Cette fois, la chaîne existait vraiment.

Mon ordinateur établissait le VPN B à travers la connexion déjà protégée par le VPN A.

Pour le problème précis qui m’obsédait — ne pas confier toute la chaîne à une seule entreprise — c’était nettement plus intéressant. Le premier fournisseur voyait une connexion venant de moi, mais le trafic partait ensuite dans le second tunnel. Le deuxième recevait ma connexion depuis l’adresse de sortie du premier VPN plutôt que directement depuis ma box.

Il y avait enfin une vraie séparation de confiance.

Cela ne faisait pas disparaître les comptes auxquels j’étais connecté, les cookies ou la possibilité d’une analyse de trafic sophistiquée. Mais pour la question beaucoup plus précise « un seul opérateur VPN peut-il relier directement mon adresse d’origine et ma sortie ? », deux fournisseurs réellement imbriqués changeaient bien la réponse.

Puis j’ai fermé mon ordinateur et je suis sorti. Et mon beau schéma s’est désassemblé.

Le problème des deux fournisseurs est apparu quand j’ai changé de réseau

Dans le café, mon ordinateur passait encore par le petit routeur. VPN A sur le routeur. VPN B sur l’ordinateur. Deux couches.

En quittant le café, j’ai rangé le routeur et connecté l’ordinateur au partage de connexion de mon téléphone.

Le deuxième VPN s’est reconnecté. Tout semblait normal. Sauf que le premier VPN n’existait plus. Il vivait dans le routeur posé au fond de mon sac.

J’étais passé de deux fournisseurs à un seul sans modifier le réglage du VPN affiché sur mon ordinateur.

C’est à cet instant que la différence avec le multi-hop m’a paru beaucoup plus importante que le nombre de cadenas.

Un vrai mode multi-hop ressemble moins à deux applications empilées qu’à un itinéraire à deux étapes dessiné à l’avance. Mullvad, par exemple, fait passer la connexion par un serveur d’entrée puis un serveur de sortie ; l’application organise elle-même les deux étapes. Proton applique une logique comparable avec Secure Core : le trafic traverse d’abord son infrastructure Secure Core avant de rejoindre le serveur de sortie.

La différence devenait enfin facile à retenir.

Deux fournisseurs réellement imbriqués séparent la confiance entre deux entreprises.

Le multi-hop d’un seul fournisseur sépare les points du trajet, mais le même opérateur organise l’ensemble.

Et cette deuxième approche demande beaucoup moins d’entretien.

Je n’ai pas à me souvenir quel tunnel vit dans le routeur, lequel tourne sur l’ordinateur et ce qu’il reste réellement de mon montage lorsque je change de Wi-Fi.

La deuxième étape a quand même un prix : du trajet

Deux serveurs signifient davantage de chemin.

Si l’entrée est à Paris et la sortie à Amsterdam, le détour peut rester raisonnable. Si je commence à envoyer ma connexion d’un continent à l’autre avant de revenir vers le service que j’utilise, j’ai construit moi-même une partie de la latence que je vais ensuite reprocher au VPN.

Mullvad explique d’ailleurs que le multi-hop ralentit généralement la connexion sur de longues distances. Il existe pourtant une exception intéressante : lorsque le chemin direct souffre d’un mauvais peering entre réseaux, ajouter une étape peut parfois contourner la mauvaise route et améliorer le débit.

Une discussion publique d’août 2026 montrait exactement ce paradoxe. Un utilisateur obtenait des débits extrêmement faibles vers certains serveurs ; en faisant passer sa connexion par un autre point grâce au multi-hop, la vitesse redevenait utilisable. La latence, elle, devenait plus irrégulière.

C’est ce qui a changé ma façon de regarder le mot « stabilité ».

Le chemin le plus court n’est pas automatiquement le meilleur. Ajouter une étape n’est pas automatiquement mieux non plus.

La bonne route est celle qui protège réellement ce que j’essaie de protéger sans devenir si fragile que je finis par la désactiver.

Et là, mon propre problème est devenu beaucoup moins spectaculaire.

Je n’avais pas réellement besoin de cacher chaque extrémité à deux sociétés différentes

Je ne protégeais pas une source contre un adversaire capable de surveiller plusieurs réseaux.

Je ne cherchais pas à rendre une corrélation ciblée entre deux extrémités aussi difficile que possible.

Je voulais surtout trois choses beaucoup plus ordinaires : que le Wi-Fi où je me trouvais ne voie pas directement mes destinations, que les sites ne récupèrent pas mon adresse domestique ou mobile, et que cette protection reste utilisable lorsque je passais du Wi-Fi aux données mobiles.

Pour ce problème-là, j’étais en train de transformer un outil de confidentialité en projet réseau.

J’ai donc arrêté le montage à deux fournisseurs et ouvert la petite application.

Pas de deuxième route à assembler. Pas d’entrée et de sortie à maintenir séparément. J’ai utilisé le mode adapté à ma connexion et repris ma navigation.

Puis j’ai fait exactement ce qui avait défait mon montage précédent : j’ai quitté le Wi-Fi.

Le téléphone est repassé sur le réseau mobile. Une page qui chargeait a marqué une courte hésitation. Puis elle a continué. Mes messages sont repartis.

Je n’ai pas eu à reconstruire la route.

C’est là que le transport basé sur HTTP/3 a eu beaucoup plus de valeur pour moi qu’une deuxième case « VPN connecté ». HTTP/3 repose sur QUIC, dont la conception permet à une connexion de migrer vers un nouveau chemin réseau lorsqu’une adresse ou le réseau sous-jacent change.

La version humaine est plus simple : au lieu de raccrocher parce que je suis passé du Wi-Fi à la 5G, la conversation peut continuer sur une autre ligne.

C’était exactement le comportement que je cherchais. Avec deux fournisseurs, je surveillais qui voyait quelle partie de la route.

Avec cette connexion, je regardais simplement si la route tenait encore lorsque le réseau sous mes pieds changeait.

Elle tenait.

Puis j’ai remarqué une chose que mes deux VPN n’avaient jamais réglée

La connexion fonctionnait déjà lorsque j’ai vu le compteur de requêtes bloquées augmenter dans le mode de confidentialité.

J’ai ouvert un site d’actualité. Le nombre a bougé. Une autre page. Encore quelques requêtes bloquées.

C’était un autre problème, mais justement un problème que mes deux tunnels n’avaient pas résolu.

Faire traverser deux serveurs à une requête de suivi ne l’empêche pas d’atteindre son destinataire. Elle prend simplement un chemin plus compliqué.

Le blocage des trackers agit plus tôt : certaines de ces requêtes ne partent tout simplement pas.

Cela ne remplace évidemment pas un multi-hop lorsque le modèle de menace exige réellement plusieurs points de passage. Pour mon usage quotidien, en revanche, empêcher une partie du suivi avant même qu’il sorte de l’appareil me paraissait beaucoup plus concret qu’ajouter encore un nœud à mon dessin.

L’ironie m’a fait sourire.

J’avais passé une heure à essayer d’ajouter une deuxième société entre Internet et moi alors que certaines pages continuaient tranquillement à lancer leurs propres mécanismes de suivi.

Je garderais le multi-hop pour le problème qui exige vraiment un multi-hop

La petite application reste récente. Son historique public est beaucoup plus court que celui de Mullvad ou Proton, et l’App Store français n’affiche toujours pas suffisamment d’évaluations pour proposer une moyenne de notes.

Si mon modèle de menace exigeait réellement une architecture multi-hop documentée, plusieurs juridictions précises ou des années d’infrastructure publique à examiner, je choisirais un service établi qui offre précisément cela.

Et si mon objectif absolu était de répartir la confiance entre deux entreprises différentes, un véritable montage avec deux fournisseurs resterait le plus intéressant — à condition d’accepter de le construire et de vérifier qu’il existe encore après chaque changement de réseau.

Mais ce n’était pas mon problème quotidien.

Deux VPN différents m’avaient donné la meilleure séparation entre fournisseurs, au prix du montage le plus fragile.

Le multi-hop m’offrait deux points de passage beaucoup plus faciles à maintenir, mais toujours organisés par le même fournisseur.

La connexion simple avait fait quelque chose que j’avais presque oublié de tester pendant que je comptais les tunnels : elle était restée protégée lorsque j’avais quitté le Wi-Fi, et ma navigation avait continué sans que je reconstruise quoi que ce soit.

J’avais commencé en pensant que deux VPN devaient forcément être plus privés qu’un.

J’ai terminé avec un critère beaucoup plus utile : si je ne cherche pas à me protéger d’une corrélation ciblée entre deux extrémités du réseau, je préfère une seule route que je garde réellement active à deux couches qui disparaissent dès que je range le routeur.