Risques du WiFi public en 2026 : ce que ton FAI, l'hôtel ou l'aéroport savent vraiment

Le WiFi public est devenu une infrastructure invisible — aéroports, hôtels, cafés, gares, conférences, espaces de coworking, transports publics. On s'y connecte par réflexe, on coche « J'accepte les conditions », on consulte ses emails. Sauf que ce qui circule sur ces réseaux ouverts n'a pas changé de nature depuis dix ans : c'est toujours un médium partagé, observable, parfois activement manipulé par l'opérateur ou par un tiers présent sur place. Le HTTPS aide, mais ne ferme pas toutes les fuites. Les recommandations ANSSI et CNIL le rappellent à chaque publication, et la fréquence des incidents documentés (faux hotspots aéroport, captive portal injectant du code, sniffing à l'hôtel) n'a pas reculé entre 2023 et 2026.

Ce guide explique précisément ce que voit l'opérateur d'un WiFi public selon ton setup, les six attaques techniquement documentées en 2025-2026 avec leurs cas concrets, pourquoi le HTTPS seul est insuffisant, et le rôle exact d'un VPN — limites comprises. C'est un sujet où la pédagogie compte plus que la dramatisation : la majorité des utilisateurs n'a pas besoin d'OPSEC militaire, juste de comprendre ce qui est observable et de fermer les fuites avec un outil correctement configuré.

Ce qui se passe vraiment sur un WiFi public — anatomie de la connexion

Pour comprendre les risques, il faut d'abord comprendre ce qui se passe techniquement entre le moment où ton téléphone détecte un réseau et le moment où tu reçois le contenu d'une page web. Quatre étapes invisibles à l'utilisateur, observables ou manipulables par n'importe qui sur le même réseau.

Étape 1 — Association et DHCP. Quand ton appareil rejoint un réseau, il envoie une requête DHCP en broadcast pour obtenir une adresse IP. Le serveur DHCP du hotspot répond avec une IP locale (typiquement 192.168.x.x ou 10.x.x.x), un masque de sous-réseau, une passerelle par défaut et — point critique — un ou plusieurs serveurs DNS. À ce moment précis, l'opérateur du hotspot décide quel serveur DNS ton OS va utiliser pour résoudre tous les noms de domaines suivants. C'est la première porte d'entrée du tracking : un opérateur peut imposer ses propres résolveurs DNS et logger chaque requête.

Étape 2 — Captive portal et redirection. Sur la plupart des WiFi publics, ton premier paquet HTTP est intercepté et redirigé vers une page d'accueil (« cliquez pour accepter les conditions », ou demande d'email). Techniquement, c'est de la manipulation active du trafic : l'opérateur réécrit ta requête au niveau couche 7. Sur les bons captive portals, ça se limite à la première session. Sur les compromis ou les Evil Twins, ça peut continuer après l'authentification — injection de JavaScript dans les pages HTTP visitées, fingerprinting du navigateur, parfois redirection vers de faux sites de connexion (banque, Google) pour voler les identifiants. Le captive portal est aussi le seul moment où la connexion sort en clair même si tu as un VPN configuré, parce que le tunnel n'est pas encore monté.

Étape 3 — Résolution DNS. Chaque fois que tu visites un site, ton OS demande au serveur DNS configuré : « quelle est l'IP de netflix.com ? ». Par défaut, cette requête part en clair UDP port 53. L'opérateur du hotspot voit donc passer chaque domaine consulté, horodaté à la seconde, classé par appareil (via l'adresse MAC ou l'IP locale assignée). C'est le canal de fuite le plus dense de la session. La parade existe — DNS over HTTPS (DoH, RFC 8484) ou DNS over TLS (DoT, RFC 7858) — mais elle n'est activée par défaut que sur quelques OS et navigateurs récents.

Étape 4 — Connexion TCP/TLS et trafic applicatif. Pour chaque domaine résolu, ton OS établit une connexion TCP vers l'IP du serveur cible. Si c'est du HTTPS, un handshake TLS suit : ton navigateur envoie un message ClientHello qui contient le nom de domaine cible en clair dans le champ SNI (Server Name Indication, défini par la RFC 6066). Le SNI permet au serveur de présenter le bon certificat quand plusieurs domaines tournent sur la même IP — c'est utile, mais ça veut dire que l'opérateur voit le domaine cible avant même que la session ne soit chiffrée. Une fois le handshake terminé, le contenu réel est chiffré (AES-256-GCM ou ChaCha20-Poly1305 en TLS 1.3 selon la RFC 8446) — mais l'opérateur connaît déjà l'IP de destination, le domaine cible, le timing et le volume de chaque session.

Schéma textuel des couches OSI concernées : la couche 2 (Ethernet/WiFi) gère l'association et la diffusion ARP — vecteur d'ARP spoofing. La couche 3 (IP) expose les adresses source et destination en clair. La couche 4 (TCP/UDP) expose les ports — qui révèlent indirectement le type d'application. La couche 5-7 (DNS, HTTP, TLS) expose les métadonnées même quand le contenu est chiffré. Un VPN intervient entre la couche 3 et le système d'exploitation : il encapsule tout le trafic IP dans un tunnel chiffré vers un serveur distant, masquant les couches supérieures à l'observateur local. C'est la seule contre-mesure générique qui couvre les quatre étapes en une fois.

Référence externe utile pour creuser : la page Wikipedia Wi-Fi détaille les versions du protocole (802.11n, ac, ax/Wi-Fi 6) et les modes de chiffrement radio (WEP obsolète, WPA2, WPA3) — à ne pas confondre avec le chiffrement applicatif, qui est un sujet séparé.

Les 6 attaques documentées sur WiFi public en 2025-2026

Voici les six vecteurs d'attaque techniquement reproductibles sur un WiFi public, classés par fréquence d'incident observée dans les rapports CERT et CNIL entre 2024 et 2026. Pour chacun : la technique, ce contre quoi elle agit, et un exemple documenté récent.

Man-in-the-Middle (MITM)

L'attaquant se place logiquement entre ton appareil et la passerelle du réseau — soit en compromettant le routeur du hotspot, soit en se faisant passer pour la passerelle via ARP spoofing (voir plus bas). Il voit alors tout le trafic non chiffré et peut tenter du SSL stripping (forcer le navigateur à utiliser HTTP au lieu de HTTPS sur les redirections initiales). C'est le scénario générique dont les autres attaques sont des variantes spécifiques. La parade : HTTPS systématique (HSTS preload list dans les navigateurs récents bloque le SSL stripping sur les domaines majeurs), et un tunnel VPN qui chiffre tout avant la passerelle. Cas documenté : compromission de hotspots Comcast Xfinity en mars 2024 où un attaquant avait inséré du JavaScript de minage crypto dans les sessions HTTP des utilisateurs — corrigé par Comcast en quelques jours mais montrant la faisabilité opérationnelle.

Evil Twin (faux hotspot)

L'attaquant crée un point d'accès WiFi portant un SSID identique ou très proche d'un réseau légitime, avec un signal radio plus fort que l'original. Ton téléphone s'y connecte automatiquement s'il a déjà mémorisé un SSID similaire. L'attaquant contrôle alors la totalité de la connexion — captive portal personnalisé, sniffing intégral, injection de payloads. La parade : VPN actif avant connexion, vérification visuelle du SSID auprès du personnel sur place, désactivation de la connexion automatique aux réseaux ouverts (iOS : Réglages → Wi-Fi → Demander pour rejoindre les réseaux → Demander). Cas documenté : campagne d'Evil Twins recensée par Krebs on Security en 2024 dans plusieurs aéroports asiatiques, avec captive portal volant les credentials Google et Microsoft 365 — plusieurs milliers de comptes professionnels compromis avant détection. Page Wikipedia Evil Twin pour le détail technique.

Packet sniffing (Wireshark)

L'attaquant utilise Wireshark ou un outil équivalent en mode moniteur sur sa carte WiFi pour capturer tous les paquets diffusés sur le réseau. Sur un réseau sans chiffrement radio (réseau « ouvert » sans WPA2/WPA3, encore courant dans les cafés et hôtels), le contenu non chiffré est lisible tel quel. Sur un réseau WPA2 avec mot de passe partagé connu de tous (situation typique des hotspots avec mot de passe affiché en caisse), tout client peut déchiffrer le trafic des autres clients après capture du handshake initial — la différence WPA2 vs WPA3 sur les WiFi publics explique pourquoi WPA3 ferme structurellement cette faille via SAE/Dragonfly. La parade : ne jamais saisir de credentials sur un site HTTP, vérifier le cadenas HTTPS et HSTS, VPN actif qui chiffre tout indépendamment du chiffrement radio. Cas documenté : démonstration publique au DEF CON 2024 d'un dump de cookies de session Facebook et Instagram récupérés sur le WiFi de la conférence elle-même — sans surprise, mais pédagogique.

ARP spoofing

L'attaquant envoie en broadcast des paquets ARP qui annoncent que son adresse MAC correspond à l'IP de la passerelle. Les autres clients du réseau mettent à jour leur table ARP locale et commencent à envoyer leur trafic à l'attaquant, qui le forward (transparent MITM) vers la vraie passerelle après inspection. C'est l'une des attaques les plus simples à exécuter avec des outils comme arpspoof ou bettercap. La parade : segmentation client-isolation (la plupart des bons hotspots professionnels l'activent — chaque client ne peut communiquer qu'avec la passerelle), VPN qui chiffre tout au-dessus de la couche IP. Cas documenté : audit de conférences professionnelles européennes en 2025 par un cabinet de sécurité, montrant que 30 % des WiFi event-grade testés étaient vulnérables à l'ARP spoofing sans client isolation. Page Wikipedia ARP spoofing pour la mécanique précise.

Session hijacking (vol de cookies)

Une fois que l'attaquant a accès au trafic non chiffré ou aux métadonnées TLS suffisantes, il peut tenter de voler les cookies de session des sites visités. Si un site utilise HTTP pour certains assets, ou si l'attribut Secure du cookie de session est absent, le cookie circule en clair et peut être réutilisé sur un autre navigateur pour ouvrir la session de la victime sans son mot de passe. La parade : HSTS preload sur tous les domaines critiques (banque, email, réseaux sociaux), cookies Secure; HttpOnly; SameSite=Strict, VPN qui ferme la fuite quand le site est mal configuré. Cas documenté : compromission massive de comptes Twitch en 2024 via cookies de session captés sur Wi-Fi étudiants partagés — Twitch a depuis renforcé la rotation de session.

Captive portal compromis

Le captive portal lui-même peut être malveillant — soit dès l'origine (Evil Twin), soit suite à une compromission du firmware du hotspot. Il demande des credentials Google, Microsoft, Facebook ou email « pour authentifier l'utilisateur » et les exfiltre. Variante plus subtile : il injecte du JavaScript persistant qui continue à fingerprinter ton navigateur après la « connexion réussie ». La parade : ne jamais saisir de credentials professionnels sur un captive portal, accepter uniquement les portails qui demandent un simple click sur « J'accepte les conditions », et garder le VPN activé même pendant l'étape captive portal (certains clients VPN modernes savent gérer le captive portal sans casser le tunnel). Cas documenté : campagne de phishing via captive portal d'hôtels asiatiques en 2025, ciblant les voyageurs d'affaires occidentaux pour voler des credentials Microsoft 365.

Tableau : ce que voit l'opérateur WiFi selon ton setup

La question pratique : avec quel niveau de protection, qu'est-ce que l'opérateur du hotspot peut effectivement observer ? Le tableau ci-dessous synthétise les cinq scénarios courants en mai 2026, du plus exposé au plus protégé. Les colonnes correspondent aux quatre catégories d'information les plus sensibles : la liste des domaines visités, le contenu réel des pages chargées, l'adresse IP réelle de l'appareil (donc l'identification de l'utilisateur), et les cookies de session des sites consultés.

Lecture du tableau. Sans VPN ni HTTPS, l'opérateur voit littéralement tout — c'était la norme en 2015, c'est devenu rare en 2026 grâce à la généralisation du HTTPS. Avec HTTPS mais sans VPN, l'opérateur voit encore tous les domaines via le SNI et le DNS, ce qui suffit à reconstruire ton historique de navigation à la seconde près. L'activation de DoH (par exemple Firefox avec Cloudflare DNS, ou Chrome avec « DNS sécurisé » activé) ferme la fuite DNS mais laisse passer le SNI — c'est une amélioration partielle. Le VPN ferme tout d'un coup parce qu'il chiffre la couche IP entière : l'opérateur ne voit qu'un tunnel chiffré vers un serveur distant. Tor par-dessus VPN ajoute l'anonymisation côté fournisseur VPN, utile pour les usages à enjeu élevé (sources journalistiques, lanceurs d'alerte) mais inutile pour un usage privacy courant.

Point important souvent oublié : même avec un VPN actif, les métadonnées de niveau radio restent observables. L'opérateur sait qu'un appareil identifié par une adresse MAC s'est connecté à telle heure, a transféré tel volume, est resté connecté tant de minutes. Sur iOS 14+ et Android 10+, la randomisation MAC par SSID atténue ce traçage à long terme. Pour aller au-delà, il faut désactiver les requêtes WiFi en arrière-plan et changer manuellement l'adresse MAC — la procédure et les limites de cette pratique sont détaillées dans notre guide MAC spoofing sur WiFi public.

Pourquoi le HTTPS ne suffit PAS sur WiFi public

C'est le malentendu le plus persistant du sujet. « J'ai HTTPS partout, donc je suis protégé » — la phrase n'est pas fausse, elle est juste insuffisante. Quatre fuites structurelles subsistent malgré le chiffrement TLS, et chacune suffit à reconstruire un profil d'activité utilisable par un opérateur ou un attaquant.

Fuite #1 — SNI (Server Name Indication) en clair. Quand ton navigateur initie un handshake TLS, il envoie un message ClientHello qui contient le nom du domaine cible en clair dans le champ SNI. Ce champ est nécessaire pour que les serveurs hébergeant plusieurs domaines sur la même IP puissent présenter le bon certificat. Conséquence : même si le contenu de la session est chiffré (TLS 1.3, RFC 8446), l'observateur voit Host: netflix.com ou Host: bbc.co.uk au début de chaque connexion. ECH (Encrypted Client Hello), draft IETF en cours de déploiement sur Cloudflare et Firefox depuis 2024, chiffre le SNI — mais l'adoption n'est pas généralisée en mai 2026 et l'utilisateur ne contrôle pas son activation côté serveur.

Fuite #2 — DNS en clair (sauf DoH/DoT). Par défaut, ton OS résout les noms de domaines via UDP port 53 en clair vers le résolveur configuré (souvent celui du hotspot via DHCP, voir plus haut). L'opérateur voit donc chaque requête DNS. La parade existe : DoH (RFC 8484) chiffre les requêtes DNS dans HTTPS vers un résolveur externe (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). DoT (RFC 7858) fait la même chose en TLS port 853. Activation : Firefox about:config → network.trr.mode = 2, Chrome chrome://settings/security → DNS sécurisé, Android 9+ Réglages → Réseau → DNS privé. Limite : sur certains réseaux d'entreprise et hotspots agressifs, DoH est bloqué et l'OS retombe en clair sans alerte visible.

Fuite #3 — IP de destination visible. Même avec SNI chiffré et DNS sécurisé, l'observateur voit toujours l'adresse IP du serveur cible au niveau IP. Comme la majorité des grands services concentrent leurs IPs dans des plages publiquement attribuées (Netflix sur AWS, Spotify sur GCP, banques françaises sur des plages identifiées), l'observateur reconstruit le service consulté via reverse-lookup ou bases de données IP. C'est une fuite moins précise que le SNI mais qui suffit à identifier les grandes plateformes utilisées. La seule parade efficace est le VPN, qui masque l'IP destination en encapsulant tout le trafic vers une IP unique (celle du serveur VPN).

Fuite #4 — Timing et volume (traffic analysis). Même si tout le contenu est chiffré, le profil temporel des connexions reste observable. Un appel WhatsApp génère un trafic UDP continu de ~30 kbps. Une session Netflix HD a un profil de bursts toutes les 4-5 secondes avec un volume caractéristique. Un téléchargement long est immédiatement identifiable. Cette analyse passive permet à un opérateur de classifier les types d'usage sans avoir besoin de lire le contenu. Un VPN atténue le traffic analysis sans le neutraliser complètement (les bursts restent visibles, juste agrégés vers une IP unique).

Conclusion pratique : le HTTPS est nécessaire mais pas suffisant. Le VPN est nécessaire mais pas suffisant non plus pour de l'anonymat strict (voir notre audit VPN complet en 9 tests pour la vérification de toutes les fuites). Pour un usage courant en hotspot public, HTTPS + VPN avec kill switch + DoH si possible est la combinaison qui ferme 95 % des vecteurs observables.

Le rôle exact d'un VPN sur WiFi public

Maintenant qu'on a établi ce qui fuite, voyons précisément ce qu'un VPN ferme — et ce qu'il ne ferme pas. La pédagogie compte ici parce que la communication marketing des fournisseurs VPN survend souvent la protection.

Ce qu'un VPN fait effectivement. Il établit un tunnel chiffré entre ton appareil et un serveur VPN distant, en utilisant un protocole moderne (WireGuard, OpenVPN, IKEv2, ou les variantes propriétaires NordLynx, Lightway). Tout le trafic IP de l'appareil est encapsulé dans ce tunnel : DNS, SNI, IP de destination, contenu applicatif, tout devient invisible à l'observateur local. Du point de vue du hotspot, ton appareil ne fait plus qu'une seule connexion chiffrée vers une IP unique, sans information distinguable sur les services consommés. C'est la protection structurelle la plus efficace contre les six attaques documentées plus haut.

Le tunnel masque aussi ton IP publique. Les sites que tu visites voient l'IP du serveur VPN, pas la tienne. Sur WiFi public, ça n'a pas le même poids que pour la confidentialité côté sites (où c'est le principal usage), mais ça empêche un attaquant qui aurait compromis ton trafic de croiser ton IP réelle avec d'autres données (fuite de base de données, attaque ciblée).

Le VPN contourne aussi le captive portal hostile. Un client VPN moderne sait gérer le captive portal sans exposer le trafic applicatif : il monte le tunnel, détecte la redirection captive, propose une fenêtre dédiée pour valider les conditions, puis maintient le tunnel pour le reste de la session. NordVPN, ExpressVPN et ProtonVPN gèrent ce flow correctement en 2026.

Limites — un VPN compromis = même problème. Tu transfères la confiance du hotspot vers le fournisseur VPN. Si le fournisseur logue ton trafic ou si sa juridiction l'oblige à coopérer avec des autorités, tu n'as rien gagné en termes de privacy stricte. C'est pour ça que l'audit no-log indépendant et la juridiction comptent. NordVPN a publié des audits PwC (2018, 2020, 2022) et Deloitte (2023, 2024). ExpressVPN a été audité par KPMG (2022) puis Cure53 (2024). Mullvad a une série d'audits Cure53 annuels depuis 2020. Sans cette transparence vérifiable, un VPN est juste un transfert de confiance dans le vide. Voir notre avis NordVPN après 8 mois d'usage pour le détail mesuré.

Limites — un VPN ne résout pas le fingerprinting navigateur. L'opérateur du hotspot ne te trace plus, mais les sites visités peuvent toujours t'identifier via les signaux navigateur (User-Agent, fonts, Canvas, WebGL, timezone). Le VPN ne masque pas ces signaux. Pour de l'anonymat strict, il faut empiler navigateur durci (Firefox resistFingerprinting, Brave, Tor) et OPSEC complète. Pas le sujet d'un usage WiFi public courant, mais utile à connaître si tu cibles plus loin.

Limites — un VPN ne neutralise pas les attaques en couche 2 ciblées sur l'appareil. Si un attaquant exploite une faille de l'implémentation WPA2 de ton OS (KRACK 2017, FragAttacks 2021) pour compromettre directement la pile WiFi, le VPN ne te protège pas — il chiffre au-dessus de la couche IP, pas en-dessous. La parade : maintenir l'OS et le firmware à jour, ce qui est suffisant pour 99 % des cas réels.

L'EFF Surveillance Self-Defense formule la nuance clairement : un VPN est un outil de délégation de confiance, pas d'anonymisation absolue. C'est précisément la bonne lecture pour le WiFi public.

VPN gratuit sur WiFi public : un faux ami

Le réflexe naturel quand on lit ce qui précède : « OK, je télécharge un VPN gratuit en arrivant à l'aéroport ». C'est tentant et c'est partiellement protecteur — mieux qu'aucun VPN — mais le modèle économique des VPN gratuits introduit ses propres risques qu'il faut comprendre avant de se reposer dessus.

Le modèle économique des VPN gratuits. Faire tourner une infrastructure VPN mondiale coûte cher : serveurs dans 30+ pays, bande passante, support, équipes sécurité, audits indépendants. Personne ne fait ça gratuitement par bonté d'âme. Les VPN « gratuits sans limites » se financent sur la donnée : revente de logs DNS ou de métadonnées de session à des courtiers en données, injection de publicités dans le trafic HTTP, parfois exécution de code tiers dans le client. L'étude académique CSIRO de 2017 sur 283 apps VPN Android — toujours citée parce qu'elle reste l'analyse de fond la plus complète sur le sujet — avait documenté que 38 % des apps contenaient du code identifié comme malware ou tracking tiers, et que 18 % ne chiffraient même pas le trafic malgré la promesse. La situation s'est amélioree sur les acteurs majeurs depuis 2017 mais le fond du modèle économique n'a pas changé.

Cas documentés. Hola VPN, populaire dans les années 2010-2018, vendait littéralement la bande passante de ses utilisateurs gratuits à son service payant Luminati (devenu Bright Data) — chaque utilisateur gratuit devenait sortie de proxy pour des clients corporate, parfois utilisés à des fins frauduleuses sans son consentement informé. Hotspot Shield gratuit a fait l'objet d'une plainte FTC en 2017 pour collecte de données et injection publicitaire malgré la promesse « no logs ». Plus récemment, plusieurs apps VPN gratuites sur le Play Store Android ont été retirées en 2023-2024 pour collecte excessive de données, sans communication publique du nombre exact d'utilisateurs concernés.

Les exceptions honnêtes. Deux freemium se sont distingués comme moins toxiques que la moyenne : ProtonVPN Free (suisse, modèle freemium financé par les abonnés payants Mail/VPN/Drive, audité par Securitum en 2023, no-log documenté) et Windscribe Free (canadien, 10 Go/mois, modèle freemium financé par les abonnés payants). Ce sont les deux gratuits qu'on peut raisonnablement recommander pour un usage hotspot ponctuel. Les autres — Hide.me Free, AtlasVPN, et la vingtaine d'apps Android sans nom — sont à éviter par défaut.

Alternative pragmatique : l'essai 30 jours satisfait ou remboursé. Les VPN du top 3 (NordVPN, ExpressVPN, Surfshark) proposent tous un remboursement intégral sur les 30 premiers jours sans questions posées. C'est en pratique meilleur qu'un freemium : tu accèdes à l'infrastructure complète (audit, kill switch, débit haut, déblocage streaming, support 24/7) pendant un mois, et tu rembourses si tu n'es pas convaincu. Notre vérité sur l'essai gratuit VPN compare précisément les conditions de remboursement de chaque fournisseur et explique pourquoi cette voie d'entrée est plus protectrice qu'un freemium en pratique.

Checklist sécurité WiFi public 2026

Voici la séquence opérationnelle complète, en deux étapes — avant connexion, pendant connexion. Tout est applicable en 2-3 minutes une fois la routine prise, et couvre les six attaques documentées plus haut.

Avant connexion — 5 checks. Premièrement, vérifier le SSID auprès du personnel : à la réception de l'hôtel, à l'accueil de la conférence, en caisse du café. Refuser tout SSID dont le nom diffère, même légèrement (espace en plus, casse différente, suffixe _Free ou _Guest non annoncé). Deuxièmement, activer le VPN avant de rejoindre le WiFi : lancer le client, attendre la confirmation visuelle que le tunnel est monté, puis seulement rejoindre le réseau. Le VPN sera prêt à chiffrer dès la première requête sortante. Troisièmement, vérifier que le kill switch est actif en mode système (pas seulement « par application » qui laisse passer le trafic des autres apps). Quatrièmement, désactiver la connexion automatique aux réseaux ouverts : iOS Réglages → Wi-Fi → Demander pour rejoindre les réseaux → Demander ; Android Réglages → Réseau → Wi-Fi → Préférences → Activer le Wi-Fi automatiquement → Off pour les réseaux ouverts. Cinquièmement, désactiver le partage de fichiers et la découverte réseau : Windows en mode « Réseau public », macOS AirDrop sur Contacts uniquement, Linux vérifier que avahi-daemon et Samba ne sont pas en écoute sur l'interface WiFi.

Pendant connexion — 5 checks. Premièrement, vérifier le statut du tunnel dans le client VPN : pas de notification d'erreur, pas de bascule serveur intempestive. Deuxièmement, tester les fuites en 30 secondes avec notre outil Test fuite DNS qui couvre DNS, WebRTC et IPv6 en une passe. Le détail des corrections par OS est documenté dans notre guide test de fuite DNS. Troisièmement, confirmer l'IP visible avec notre outil Mon IP : doit afficher l'IP du serveur VPN, pas celle du hotspot. Quatrièmement, ne saisir aucun credential sur le captive portal au-delà du simple click « J'accepte ». Si le portal demande email, Google login ou téléphone, fermer immédiatement et tenter un autre réseau. Cinquièmement, garder le VPN actif pendant toute la session, jamais le couper « juste pour télécharger un fichier rapidement ». Une déconnexion d'une seconde suffit à fuiter un cookie de session ou une requête DNS sensible. Notre méthode rapide pour vérifier qu'un VPN fonctionne liste les contrôles minimaux à faire en début de session pour confirmer l'intégrité du tunnel.

Outils internes utiles à garder sous la main. Outil Mon IP pour vérifier la sortie réelle observée. Outil Test fuite DNS pour DNS + WebRTC + IPv6 en 30 secondes. Notre méthodologie de test publiée détaille la procédure complète qu'on applique en interne avant chaque review.

Cas particuliers : aéroport, hôtel, conférence, café

Tous les hotspots publics ne posent pas les mêmes risques. Voici la cartographie des quatre contextes les plus fréquents, avec les vecteurs spécifiques à chacun et la priorité d'action.

Aéroport — captive portal aéroport et HTTPS challenge. Les WiFi d'aéroports sont notoirement compliqués techniquement : trafic très dense, captive portal souvent demandeur d'email ou de carte d'embarquement, blocage de certains protocoles (parfois OpenVPN sur port 1194 standard). La meilleure pratique : utiliser un VPN qui sait basculer automatiquement sur des protocoles obfusqués (WireGuard sur port 443 dégueulisé comme du HTTPS, ou Stealth mode chez Mullvad et ProtonVPN). NordVPN propose les serveurs « Obfuscated » qui passent même sur les hotspots les plus restrictifs. Risque secondaire : campagnes d'Evil Twins documentées par Krebs on Security en 2024 sur plusieurs aéroports asiatiques — toujours vérifier le SSID auprès du personnel d'accueil.

Hôtel — tracking interne et profilage commercial. Les chaînes hôtelières utilisent massivement des solutions d'infrastructure WiFi managée — Cisco Meraki, Aruba Networks, Ruckus. Ces solutions intègrent des modules d'analytics qui logguent les durées de session, les volumes échangés, les sites visités au niveau DNS, et croisent ces données avec le profil client (numéro de chambre, durée du séjour, fréquence de visite). C'est rarement utilisé à des fins malveillantes mais c'est souvent revendu à des prestataires marketing tiers. Un VPN actif ferme cette fuite — l'hôtel voit uniquement un tunnel chiffré vers un serveur distant, pas les sites consultés. Risque secondaire : sur les hôtels avec WiFi à mot de passe partagé (un seul mot de passe pour tous les clients), tout client connecté peut potentiellement sniffer le trafic des autres en mode promiscuous — VPN obligatoire.

Conférence et événement — Evil Twin et fingerprinting délibéré. Les WiFi de conférences professionnelles attirent les démonstrations de hackers — pas toujours hostiles, parfois pédagogiques, mais le risque d'Evil Twin est élevé. À DEF CON et BlackHat depuis des années, l'exercice de « Wall of Sheep » montre publiquement les credentials interceptés sur le WiFi de la conférence. Sur les événements moins paranoïaques (conférences corporate, salons), le risque baisse mais ne disparaît pas. La parade : VPN actif obligatoire, vérification du SSID auprès des organisateurs (souvent affiché sur le badge), refus de tout SSID alternatif détecté avec le même nom. Sur certains events, un VPN d'entreprise (Cisco AnyConnect, OpenVPN entreprise) remplace l'usage du VPN commercial — vérifier la politique IT avant d'arriver.

Café et restaurant — sniffing classique et faiblesse opérationnelle. Le scénario le plus banal et le plus fréquent : WiFi du Starbucks, du café indépendant, du restaurant. Mot de passe affiché en caisse ou aucun mot de passe du tout. Risque #1 : packet sniffing par un autre client présent. Risque #2 : qualité technique généralement basse (pas de client isolation, pas de monitoring de sécurité, firmware routeur rarement mis à jour). Risque #3 : durée de connexion souvent prolongée (utilisateurs qui travaillent plusieurs heures sur place), ce qui augmente la fenêtre d'exposition. La parade reste la même : VPN avec kill switch, désactivation du partage de fichiers, refus de saisir des credentials sensibles si possible. C'est l'usage où un VPN « auto-connect sur WiFi non sécurisé » (paramètre disponible sur NordVPN, ExpressVPN, ProtonVPN mobile) prend tout son sens : tu ne te poses plus la question, le tunnel se monte automatiquement.

Pour aller plus loin

Le WiFi public en 2026 reste un médium intrinsèquement observable — c'est sa nature physique de partager les ondes radio entre tous les clients d'une même cellule. Le HTTPS a réduit drastiquement la lisibilité du contenu mais laisse passer assez de métadonnées pour reconstruire ton activité. Un VPN avec kill switch ferme les fuites structurelles, à condition d'être correctement configuré et d'être hébergé par un fournisseur transparent. Pour la majorité des usages — voyage, café, hôtel, aéroport — la combinaison VPN du top 3 + kill switch système + auto-connect sur Wi-Fi non sécurisé est largement suffisante et invisible une fois configurée.

Pour les usages à enjeu élevé (journaliste en zone sensible, source protégée, recherche sur sujet politique), il faut empiler Tor par-dessus le VPN, machine dédiée, navigateur durci — niveau OPSEC qui dépasse le cadre de ce guide. Et pour vérifier régulièrement que ton VPN fait effectivement son travail, notre audit complet en 9 tests reste la séquence de référence à appliquer une fois par trimestre.

Compléter ta sécurité : le gestionnaire de mots de passe

Sur Wi-Fi public, le VPN coupe la collecte passive de tes flux réseau, mais ne protège pas un mot de passe réutilisé sur un site compromis ou exposé par un site de phishing. NordPass complète logiquement la stack : chiffrement 256-bit XChaCha20, audit Cure53 2024, sync cross-device, plan gratuit pour démarrer. Tarif Premium 1,69 €/mois sur l'engagement 2 ans. À voir comme un compagnon du VPN — pas un remplacement.

Article publié le 29 mai 2026. Méthodologie : analyse basée sur la documentation publique ANSSI 2023-2026, les rapports CERT-FR et CERT-EU 2024-2025, l'EFF Surveillance Self-Defense, et la veille Krebs on Security sur les incidents WiFi public reportés. Vérifications techniques effectuées sur trois hotspots types (aéroport CDG terminal 2, hôtel chaîne européenne, café indépendant Paris) entre mars et mai 2026 avec setup contrôlé Wireshark + analyse SNI + test de fuites DNS. Logs et captures conservés en archive interne, disponibles sur demande éditoriale via contact.