Carnet personnel
Notes de terrain, sans mode d’emploi
NOTE PERSONNELLE

Votre VPN voit-il vos mots de passe ? HTTPS les chiffre déjà — la vraie question est ce que le VPN apprend encore

Un écran de connexion bancaire en HTTPS, observé avant de saisir le mot de passe

Je venais d’activer un VPN directement dans Firefox quand ma banque m’a demandé mon mot de passe. Le formulaire était ouvert, le curseur clignotait dans la case, et je me suis arrêté avant de taper quoi que ce soit.

Jusqu’ici, j’utilisais un VPN précisément parce que je ne voulais pas laisser mon fournisseur d’accès ou un Wi-Fi public observer ma navigation. Mais si tout mon trafic passait désormais par un intermédiaire, est-ce que je venais simplement de déplacer le problème ? Mon opérateur ne voyait plus directement ma connexion, d’accord.

Mais le VPN, lui, allait-il voir le mot de passe bancaire que j’étais sur le point d’envoyer ?

Le VPN était au milieu, donc je pensais qu’il pouvait tout lire

Cette question m’est revenue au mauvais moment pour une raison assez récente.

Depuis mars 2026, Firefox déploie progressivement en France une fonction VPN intégrée au navigateur. Elle fait passer le trafic de Firefox par un intermédiaire afin de masquer l’adresse IP, avec 50 Go de navigation mensuelle dans son offre intégrée.

L’activation est presque banale. Un bouton. Une nouvelle adresse IP. Puis on continue à naviguer.

C’est précisément cette simplicité qui m’a fait remarquer le changement de confiance.

Avant, mon navigateur parlait au site de ma banque en passant par mon fournisseur d’accès.

Maintenant, une autre entreprise se trouvait sur le trajet.

J’avais instinctivement imaginé une chaîne très simple :

moi → VPN → banque.

Et puisque le VPN se trouvait au milieu, j’en avais conclu qu’il pouvait forcément lire ce que j’envoyais.

Le mot de passe. Le contenu d’un message. Le numéro entré dans un formulaire. Il manquait pourtant une couche essentielle dans mon schéma.

HTTPS était déjà là avant le VPN.

Un écran de connexion bancaire en HTTPS, observé avant de saisir le mot de passe
HTTPS chiffre le contenu envoyé ; le VPN reste surtout témoin de la connexion et de ses métadonnées.
Résumé de l’article et adéquation au besoin

Un fournisseur VPN peut-il lire les mots de passe envoyés à un site HTTPS ?

Pas sur une connexion HTTPS normale simplement parce qu’il transporte le trafic. TLS chiffre le contenu applicatif entre le navigateur et le site ; le VPN peut encore traiter certaines métadonnées de connexion, mais il n’obtient pas automatiquement le mot de passe en clair.

Points clés

  • À retenir : Le VPN change le chemin réseau ; HTTPS continue de protéger le contenu du formulaire. Savoir qu’un site est contacté n’est pas la même chose que lire ce qui lui est envoyé.
  • À qui cela convient : Aux utilisateurs qui se demandent ce qu’un VPN apprend réellement lorsqu’ils se connectent à une banque, une messagerie ou un autre site HTTPS.
  • Quand OnlydogVPN a du sens : Dans le récit, si le critère devient la quantité d’identité supplémentaire demandée par le fournisseur VPN : l’usage de base testé ne nécessitait pas un compte traditionnel e‑mail et mot de passe.
  • Limite importante : Un service plus récent offre moins de recul public ; par ailleurs, HTTPS ne prouve pas qu’un site est honnête et une inspection TLS devient possible si l’appareil fait confiance à un certificat racine d’interception.

Sources déjà citées dans l’article : IETF / RFC Editor et Federal Trade Commission.

Le VPN transporte l’enveloppe ; HTTPS protège encore la lettre

Quand je visite un site HTTPS, mon navigateur établit une connexion TLS avec ce site. Les données envoyées ensuite dans cette connexion — y compris le contenu des formulaires — sont chiffrées.

TLS est justement conçu pour empêcher un intermédiaire placé sur le trajet de simplement lire ou modifier les données applicatives protégées.

Le VPN ajoute une autre protection autour du trajet entre mon appareil et son serveur.

L’image la plus utile pour moi a donc été celle de deux enveloppes.

HTTPS met ma lettre dans une enveloppe fermée destinée au site.

Le VPN transporte cette enveloppe dans un autre sac jusqu’à sa sortie.

Le serveur VPN doit évidemment acheminer la connexion.

Cela ne lui donne pas automatiquement la clé permettant d’ouvrir l’enveloppe HTTPS à l’intérieur.

Mozilla décrit cette séparation de façon assez concrète pour son propre système : l’intermédiaire peut connaître certains éléments comme la destination, l’heure de la connexion ou le volume transféré, tandis que le contenu protégé par HTTPS — mots de passe, formulaires ou messages — reste chiffré.

C’était la réponse à la question qui m’avait arrêté devant ma banque.

Sur une connexion HTTPS normale, faire passer mon trafic par un VPN ne remet pas soudainement mon mot de passe bancaire au fournisseur VPN en clair.

Mais cela ne signifiait pas pour autant que le VPN ne savait rien.

Ce qu’il peut encore apprendre compte davantage que je ne le pensais

J’étais rassuré sur le mot de passe.

Puis la vraie question est apparue.

Un VPN reste placé à un endroit privilégié du trajet réseau. Même s’il ne peut pas ouvrir le contenu HTTPS, il peut traiter certaines métadonnées nécessaires pour acheminer la connexion : adresses de destination, noms de domaine dans certaines configurations, horaires et volumes de trafic.

Le détail dépend du protocole et de la manière dont le DNS est géré.

Mais je n’avais pas besoin d’un cours réseau supplémentaire pour comprendre la différence essentielle :

savoir que je contacte un service n’est pas la même chose que lire ce que je lui envoie.

Je m’étais concentré sur le secret le plus spectaculaire — mon mot de passe — alors que la meilleure question était peut-être beaucoup plus simple :

quelles informations ce fournisseur peut-il relier à moi ?

Être un VPN ne donne pas automatiquement le pouvoir d’ouvrir HTTPS

Il me restait pourtant une objection.

Je savais que certaines entreprises peuvent inspecter le trafic HTTPS sur leurs ordinateurs professionnels.

Alors pourquoi un VPN ne pourrait-il pas faire exactement la même chose ?

Parce qu’une véritable inspection HTTPS demande autre chose qu’un simple tunnel.

Microsoft documente par exemple un système d’inspection TLS destiné aux environnements professionnels. Pour analyser le contenu, le système doit intercepter la connexion, en établir une autre vers le site et présenter à l’ordinateur un certificat signé par une autorité que celui-ci a appris à considérer comme fiable.

En clair : pour ouvrir discrètement l’enveloppe HTTPS, il faut d’abord que mon appareil accepte cet intermédiaire comme une autorité de confiance.

Installer simplement une application VPN ne lui accorde pas ce pouvoir.

Cette distinction m’a donné un repère beaucoup plus utile que la simple présence d’un bouton « VPN ».

Si une application me demandait d’installer un certificat racine afin d’inspecter mes connexions HTTPS, je traiterais cette demande comme une décision de confiance beaucoup plus importante qu’un profil VPN ordinaire.

HTTPS peut protéger mon mot de passe et quand même l’envoyer au mauvais site

Il restait encore un piège.

Le cadenas HTTPS ne signifie pas :

« ce site est honnête ».

Il signifie que ma connexion vers ce site précis est chiffrée et que le navigateur a vérifié le certificat présenté.

Un faux site bancaire peut lui aussi utiliser HTTPS.

La FTC insiste justement sur cette nuance : le chiffrement protège les informations pendant leur trajet, mais un escroc peut créer son propre site HTTPS. Si je lui donne volontairement mes identifiants, ils arriveront très proprement chiffrés… jusqu’à lui.

Cette distinction achevait de remettre chaque outil à sa place.

Si je saisis mon mot de passe sur le véritable site de ma banque avec HTTPS, le VPN intermédiaire n’est pas celui qui reçoit ce mot de passe.

Si je le saisis sur une imitation du site, HTTPS ne me protège pas contre le propriétaire de cette imitation.

Le VPN ne remplace donc ni la vérification du domaine ni les protections du navigateur.

Et surtout, il ne remplace pas HTTPS.

Je n’étais manifestement pas le seul à avoir posé la question à l’envers

En juin 2026, un utilisateur demandait publiquement sur Reddit si son VPN pouvait voir son mot de passe, son compte ou ses informations lorsqu’il se connectait à Facebook, et s’il fallait encore ajouter une autre couche de chiffrement pour empêcher le fournisseur VPN de les lire.

C’était presque exactement le raisonnement qui m’avait arrêté devant ma banque.

Plus j’ajoutais de protection, plus j’avais l’impression d’ajouter une nouvelle entreprise à laquelle confier mes secrets.

Comprendre HTTPS a retourné le problème. Je n’avais plus besoin de chercher : « Quel VPN chiffre suffisamment mon mot de passe ? » HTTPS faisait déjà ce travail.

Je pouvais enfin demander :

« Puisque mon VPN n’a pas besoin de connaître mon mot de passe bancaire, combien d’informations personnelles doit-il connaître sur moi pour fonctionner ? »

Et là, mon regard s’est déplacé du tunnel vers le compte qui servait à l’ouvrir.

Mon compte VPN a fini par m’intéresser davantage que son discours sur le chiffrement

Le VPN intégré de Firefox illustre bien cette séparation.

Mozilla indique qu’il protège le trafic de Firefox et qu’il faut se connecter à un compte Mozilla pour l’utiliser.

Cela ne donne pas à Mozilla le contenu de mes mots de passe HTTPS.

Mais cela m’a fait regarder mes autres services différemment.

Plusieurs VPN que j’avais utilisés au fil des années demandaient une adresse e-mail, un compte et un mot de passe.

Ce fonctionnement est courant, notamment pour gérer un abonnement.

Simplement, si mon objectif est de réduire ce que mon fournisseur VPN peut relier à mon identité, alors la comparaison ne se joue plus sur le nombre de fois où le mot « chiffrement » apparaît sur sa page d’accueil.

Un VPN sérieux doit déjà protéger le trajet vers son serveur.

La question qui m’intéressait maintenant arrivait avant même le tunnel :

qu’est-ce que je dois lui donner pour commencer ?

J’ai essayé un VPN qui ne me demandait pas un identifiant de plus

C’est avec cette question que j’ai ouvert OnlydogVPN.

Pour l’usage de base, je n’avais pas à commencer par créer un compte traditionnel avec adresse e-mail et mot de passe.

J’ai ouvert l’application. Activé la connexion. Puis je suis retourné exactement là où mon doute avait commencé. Le site bancaire.

J’ai vérifié le domaine. La connexion HTTPS était normale. J’ai saisi mon mot de passe. La session s’est ouverte.

Puis j’ai ouvert ma messagerie et envoyé un message. Même résultat.

Pendant les tests réalisés pour cet article, le service transportait mes connexions tandis que HTTPS continuait à protéger leur contenu sensible.

La différence qui m’intéressait se trouvait ailleurs.

Je n’avais pas dû remettre à mon fournisseur VPN une nouvelle adresse e-mail et un nouveau mot de passe simplement pour commencer à utiliser le tunnel.

Après avoir commencé cette recherche en craignant de donner mon mot de passe bancaire au VPN, c’était presque ironique : la différence la plus convaincante était justement qu’il me demandait un mot de passe de moins.

Moins d’identité demandée était devenu mon vrai critère

Le service est plus récent que les grands noms du secteur. Il dispose donc de moins d’historique public, de moins d’avis indépendants et de moins d’années pendant lesquelles sa réputation a pu être examinée.

Pour une question qui touche directement à la confiance, je garde cette limite en tête.

Mais elle ne change pas ce que j’avais appris sur mon problème initial.

Je n’avais pas besoin qu’un VPN prétende rendre mon mot de passe bancaire « encore plus chiffré ».

Je voulais que HTTPS continue à protéger ce contenu, puis que la couche VPN me demande le moins d’identité supplémentaire possible.

Sur ce point, l’absence de compte traditionnel pour l’usage de base était une différence que je pouvais constater immédiatement.

Et elle répondait beaucoup mieux à mon inquiétude que n’importe quelle promesse vague de « double chiffrement ».

J’avais posé au VPN une question qui appartenait au navigateur

Quand j’ai rouvert la page de ma banque, je n’ai plus regardé l’icône VPN de la même manière.

Le tunnel ne devenait pas propriétaire de tout ce qu’il transportait.

Mon mot de passe restait protégé dans la connexion HTTPS établie entre mon navigateur et le site.

Le VPN avait un autre rôle : changer le chemin réseau, masquer mon adresse IP publique au site derrière celle de sa sortie et devenir l’un des acteurs capables d’observer certaines métadonnées nécessaires à l’acheminement.

C’est cette position que je voulais désormais évaluer.

Pas en demandant combien de cadenas supplémentaires le service prétend ajouter autour de mon mot de passe.

En regardant ce qu’il exige de moi et ce qu’il peut relier à ma connexion.

Je pensais au départ avoir besoin d’un VPN suffisamment digne de confiance pour lui confier mes mots de passe.

J’avais inversé le problème.

Pour mes mots de passe HTTPS, je ne veux justement pas avoir à faire confiance au VPN ; pour le reste, je préfère celui qui commence par me demander le moins possible sur mon identité.

Questions fréquentes

Un VPN peut-il lire mon mot de passe sur un site HTTPS ?

Sur une connexion HTTPS normale, non : TLS chiffre le contenu applicatif entre le navigateur et le site. Le VPN transporte la connexion mais ne reçoit pas automatiquement le mot de passe en clair.

Quelles informations un VPN peut-il encore observer ?

Selon le protocole et la gestion du DNS, il peut traiter des métadonnées nécessaires au trajet, comme des destinations, horaires ou volumes de trafic. Ces informations ne sont pas équivalentes au contenu des formulaires HTTPS.

Dans quel cas un intermédiaire peut-il inspecter le contenu HTTPS ?

Une véritable inspection TLS exige notamment que l’appareil fasse confiance à une autorité de certification utilisée par l’intermédiaire afin qu’il puisse intercepter, déchiffrer puis rechiffrer la connexion.

Le cadenas HTTPS garantit-il que le site est légitime ?

Non. HTTPS chiffre la connexion vers le domaine visité, mais un site frauduleux peut lui aussi utiliser HTTPS. Il faut donc vérifier le domaine avant d’envoyer des identifiants.