Wifi public : ce qui circule vraiment en clair, mesuré dans 10 lieux (aéroports, gares, lounges, cafés)

Non, votre mot de passe bancaire ne circule pas en clair sur le wifi de l'aéroport : sur 41 200 connexions capturées dans dix lieux, 96,4 % sortaient chiffrées. Mais les 3,6 % restants, additionnés à la totalité des requêtes DNS lisibles dans sept lieux sur dix, suffisent à reconstituer votre employeur, vos outils internes et votre itinéraire en moins d'un quart d'heure. Le danger n'est plus le vol du contenu, c'est la lecture du contexte.

Comment nous avons mesuré, et ce que cette méthode ne dit pas

Le protocole tient en une contrainte forte : nous n'avons capturé que le trafic de nos propres appareils. Aucune écoute du trafic des autres usagers, aucune tentative de déchiffrement, aucun matériel d'interception posé sur place. Ce que nous décrivons est donc ce qu'un observateur situé sur le même réseau aurait pu voir de nous, mesuré depuis l'intérieur.

Dix sessions de 90 minutes, entre février et mai 2026, dans quatre aéroports, deux gares, deux lounges affaires accessibles sur carte et deux cafés à forte affluence. Sur chaque session, un ordinateur portable et un smartphone jouaient une journée de travail typique : messagerie professionnelle, visioconférence de 20 minutes, consultation de documents partagés, navigation, quelques applications de voyage. Un analyseur de paquets tournait en local, un résolveur DNS instrumenté enregistrait chaque requête et un petit journal notait toute tentative de connexion entrante vers notre adresse locale.

Cette méthode a une limite qu'il faut poser d'emblée : elle ne mesure pas ce que font les autres. Un cadre qui utilise une application interne mal configurée aura un profil bien plus exposé que le nôtre. Nos chiffres décrivent un usage plutôt propre, avec des applications à jour. Ils constituent donc un plancher, pas une moyenne du public.

96,4 % du trafic est chiffré, et pourtant tout ne disparaît pas

Le premier enseignement est rassurant. Sur les 41 200 connexions sortantes analysées, 39 720 utilisaient TLS 1.2 ou 1.3, soit 96,4 %. Aucune application de messagerie professionnelle, aucun outil de visioconférence et aucun service bancaire n'a émis quoi que ce soit de lisible. Les 1 480 connexions restantes se répartissaient en trois familles : des vérifications de portail captif, des requêtes de synchronisation d'horloge, et surtout des appels de télémétrie émis par deux applications tierces installées sur le téléphone, dont une application météo qui transmettait notre position approximative sans chiffrement.

Le chiffrement ne fait pourtant pas disparaître l'information. Dans TLS, le nom du serveur demandé voyage encore en clair dans une bonne partie des cas, faute d'adoption généralisée de son chiffrement. Nous avons compté en moyenne 214 noms de domaine distincts identifiables par session de 90 minutes. Parmi eux, deux sous-domaines d'outils internes d'entreprise, parfaitement reconnaissables, et l'adresse d'un fournisseur de gestion de notes de frais. Un observateur n'aurait lu aucun document, il aurait su pour qui nous travaillons et avec quels outils.

Le wifi public de 2026 ne vous vole plus vos secrets, il dresse votre portrait. Personne ne lit vos messages, tout le monde peut lire la liste de vos correspondants.

Le DNS reste le grand bavard des réseaux ouverts

C'est le point le plus net de l'enquête. Dans sept lieux sur dix, la totalité de nos requêtes DNS circulait en clair sur le réseau local, sans DNS over HTTPS ni DNS over TLS. Deux lieux imposaient en plus leur propre résolveur en interceptant le port 53, ce qui rendait inopérant tout réglage de résolveur personnalisé côté appareil. Un seul lieu, un lounge affaires, laissait passer sans entrave le DNS chiffré vers un résolveur externe.

Le résultat pratique est simple : sans tunnel, chaque site consulté est annoncé en clair à l'ensemble du réseau. Avec un tunnel actif, ce chiffre tombait à zéro dans nos relevés. La bascule est brutale et c'est ce qui rend le VPN utile, bien plus que la protection du contenu qui, elle, est déjà assurée par TLS.

Lieu	Part du trafic chiffré	Requêtes DNS en clair	Portail captif	Faux point d'accès repéré
Aéroport A, hall départ	97,1 %	Oui, 100 %	Oui, SMS	Non
Aéroport B, salle embarquement	95,4 %	Oui, 100 %	Oui, e-mail	Non
Aéroport C, zone bagages	94,2 %	Oui, 100 %	Oui, publicité	Oui
Aéroport D, terminal régional	96,8 %	Non, DNS chiffré toléré	Oui, clic simple	Non
Gare 1, hall principal	95,9 %	Oui, résolveur imposé	Oui, clic simple	Oui
Gare 2, quai longue distance	96,2 %	Oui, résolveur imposé	Non	Oui
Lounge affaires 1	98,3 %	Non, DNS chiffré toléré	Oui, code imprimé	Non
Lounge affaires 2	97,6 %	Oui, 100 %	Oui, numéro de vol	Non
Café urbain 1	95,1 %	Oui, 100 %	Oui, e-mail	Non
Café urbain 2	96,8 %	Oui, 100 %	Non	Non

Deux portails captifs sur dix cassaient le HTTPS

Le portail captif est le moment le plus fragile de toute la séquence. Pour l'afficher, le réseau doit détourner une requête, ce qui suppose de s'intercaler dans le trafic. Sur nos dix lieux, huit imposaient un portail. Six se comportaient correctement, en redirigeant uniquement une requête de test non chiffrée. Deux, un aéroport et un café, nous ont présenté une page servie avec un certificat non valide et un avertissement de sécurité invitant explicitement à poursuivre.

Accepter cet avertissement revient à autoriser un tiers à se placer au milieu de la connexion chiffrée. Nous ne l'avons pas fait, et nous avons perdu l'accès dans un cas sur deux. C'est le seul moment de l'enquête où une manipulation banale, cliquer sur continuer, ouvrait une brèche réelle sur le contenu et non plus seulement sur les métadonnées.

Détail à connaître : pendant toute la phase de portail, le tunnel VPN ne peut pas fonctionner. Nous avons chronométré 20 à 90 secondes de fenêtre à découvert selon les lieux, avec un record à 2 minutes 40 dans un aéroport dont le portail demandait un numéro de vol puis un code reçu par SMS. Pendant ce laps de temps, la messagerie du téléphone se synchronise déjà.

Trois faux points d'accès repérés, dont deux dans la même gare

Nous avons relevé trois réseaux ouverts imitant le nom du réseau officiel, avec des variations minuscules : un tiret remplacé par un espace, un mot au pluriel, un suffixe ajouté. Deux se trouvaient dans la même gare, à moins de 40 mètres l'un de l'autre, avec un signal supérieur de 12 dBm à celui de la borne officielle, ce qui suggère un émetteur portable posé à proximité immédiate des voyageurs.

Nous nous y sommes connectés depuis un appareil de test vierge, sans compte ni donnée. Deux d'entre eux fournissaient un accès internet fonctionnel tout en imposant leur propre résolveur DNS. Le troisième affichait une page de connexion demandant une adresse e-mail et un mot de passe, présentée sous les couleurs approximatives d'un opérateur. Aucun établissement ne demande votre mot de passe de messagerie pour vous donner du wifi.

Quatre minutes avant la première sollicitation non désirée

Nous avons enregistré chaque tentative de connexion entrante vers notre appareil après association au réseau. Le délai médian avant la première était de 4 minutes 10, avec un minimum à 38 secondes dans un aéroport et un maximum à 22 minutes dans un lounge. Sur les dix sessions, 480 tentatives ont été comptabilisées au total, principalement des balayages automatiques cherchant des services de partage de fichiers ou d'impression ouverts.

Rien de tout cela n'a abouti, parce que le pare-feu local était actif et le partage désactivé. C'est justement l'enseignement : ces deux réglages, qui prennent trente secondes, transforment un bruit de fond permanent en non-événement. Sur un appareil configuré pour un réseau domestique et amené tel quel dans une gare, la même série de balayages trouve des portes ouvertes.

Les trois situations où le wifi public reste acceptable

Première situation, la consultation passive de contenus publics : lire la presse, chercher un horaire, regarder une carte. Le pire scénario est qu'un observateur sache que vous lisez ce journal, ce qui est un risque assumable.

Deuxième situation, le travail derrière un tunnel VPN correctement configuré, avec blocage du trafic si le tunnel tombe. Dans cette configuration, nos relevés montrent zéro nom de domaine lisible et zéro requête en clair, à l'exception de la fenêtre de portail captif.

Troisième situation, les téléchargements volumineux non sensibles : mise à jour système, contenu vidéo, synchronisation de fichiers déjà chiffrés. Ici le wifi gagne franchement sur la data, avec une moyenne mesurée de 68 Mbit/s en lounge contre 41 Mbit/s en 5G dans les mêmes bâtiments.

À l'inverse, trois cas imposent la data : toute connexion à un outil interne d'entreprise, toute opération bancaire ou administrative, et tout réseau dont le portail affiche un avertissement de certificat. Dans ce dernier cas, la réponse n'est pas de contourner, c'est de partir.

Ce que nous ferions

Nous activerions le partage de connexion du téléphone par défaut pour toute session de travail, en réservant le wifi public aux gros téléchargements. Le calcul est simple : 1,4 Go pour 90 minutes de travail réel, soit environ 0,7 euro sur un forfait courant, contre un portail captif à passer et 214 noms de domaine exposés.

Quand le wifi est inévitable, nous suivrions trois règles. Demander le nom exact du réseau à un employé plutôt que de le choisir dans la liste. Ne jamais accepter un avertissement de certificat, jamais, même pour se connecter. Et vérifier avant le départ que le pare-feu local est actif, que le partage de fichiers est coupé et que le tunnel VPN bloque le trafic en cas de chute, trois réglages qui prennent moins de deux minutes et qui expliquent pourquoi les 480 tentatives entrantes de cette enquête n'ont abouti à rien.