Le Wi‑Fi public est dangereux même avec HTTPS : attaques réelles, cas pratiques et protection en 2026
Pourquoi le Wi‑Fi public reste risqué malgré HTTPS. Menaces : SSL stripping, attaques par portail captif, points d’accès frauduleux, MITM. Fonctionnement de VPN, HSTS, DNS over HTTPS, WPA3. Conseils pratiques, checklists, cas d’usage et FAQ sur la sécurité des réseaux Wi‑Fi publics en 2026.
Contenu de l'article
- Wi‑fi public : une sécurité apparente, mais une mauvaise idée en réalité
- Comment fonctionne https en 2026 et pourquoi ce n’est pas la panacée
- Menaces réelles sur les réseaux publics : du mitm à la falsification dns
- Ssl stripping et suppression hsts : à quoi ça ressemble en vrai
- Attaques par portails captifs sans magie : même les vigilants se font piéger
- Points d’accès frauduleux et evil twin : saurez-vous repérer la substitution ?
- Vpn en 2026 : atouts, limites et idées reçues
- Bonnes pratiques concrètes : checklist sans excès
- Cas concrets : ça se passe vraiment comme ça
- Tendances 2026 qui bousculent les règles
- Paramétrage pas à pas sur plateformes populaires
- Phishing et ingénierie sociale : pourquoi on clique
- Erreurs qu’on répète sans cesse
- Pour développeurs et admins : que faire aujourd’hui
- Checklist rapide avant connexion à un wi‑fi public
- Que faire si vous pensez être attaqué
- Un minimum de risque avec un maximum de bon sens
- Faq : questions fréquentes sur le wi‑fi public et la sécurité
Wi‑Fi public : une sécurité apparente, mais une mauvaise idée en réalité
On adore internet gratuit dans les cafés, hôtels et aéroports. Qui pourrait résister à la facilité ? On se connecte et on bosse. Mais souvent, cette commodité se paie en sécurité. Le Wi‑Fi public, c’est comme une bouilloire dans une auberge : elle a l’air propre, mais personne ne sait ce qui lui est arrivé hier. Et oui, même quand vous voyez le cadenas HTTPS, ce n’est pas une armure invincible. En 2026, les attaquants sont devenus plus malins, les outils plus accessibles, et les enjeux plus élevés.
Ça fait un peu peur ? Juste un peu. C’est justement pour ça qu’on va tout décortiquer : pourquoi HTTPS ne vous sauve pas de tout, quelles attaques fonctionnent encore vraiment, comment les pirates exploitent les portails captifs et les faux points d’accès, ce que le VPN peut et ne peut pas faire, et surtout comment, sans paranoïa, vous pouvez réduire drastiquement les risques.
On va parler simplement, humainement, avec des exemples concrets, chiffres et cas pratiques. Pour que vous ne fassiez pas que hocher la tête, mais que vous changiez vraiment vos habitudes. Prêt ? C’est parti !
Pourquoi « gratuit » ne veut pas dire sans condition
Le Wi‑Fi public, on le paye avec nos données. Les portails de connexion collectent e‑mail, numéro de téléphone, empreintes d’appareils, et essaient parfois de vous abonner aux notifications push. Les admins réseau voient les métadonnées du trafic : quels domaines vous visitez, quand et en quelle quantité. Et si ce n’est pas un admin, mais un hacker connecté au même réseau ? Là, on parle d’attaques MITM, de falsification DNS, de phishing et de vol de sessions.
Comment les hackers « voient » votre appareil
Le routeur ou un point d’accès falsifié surveille ARP, DHCP, DNS et les handshakes TLS. Sans même déchiffrer HTTPS, on peut deviner beaucoup via les métadonnées : SNI (si non chiffré), adresses IP, tailles de paquets, fréquence des requêtes. Ajoutez à ça le trafic public d’applications et protocoles non sécurisés — et le puzzle s’assemble trop facilement.
Le mythe du « j’ai HTTPS, je suis tranquille »
On adore le cadenas dans la barre d’adresse. Mais HTTPS protège la connexion « navigateur – serveur », pas « point d’accès – conscience du propriétaire ». Si l’attaquant détourne le DNS et vous ramène sur un clone phishing avec un certificat valide (ce qui est possible par compromission de la chaîne, erreurs de configuration ou certificat racine malveillant installé), votre confiance se retourne contre vous. Et si l’attaque se produit avant HTTPS (par exemple via un portail captif), le cadenas ne s’affichera même pas.
Comment fonctionne HTTPS en 2026 et pourquoi ce n’est pas la panacée
En 2026, la plupart des navigateurs utilisent TLS 1.3 par défaut, avec une forte tendance à adopter Encrypted Client Hello (ECH) pour cacher le SNI. C’est une amélioration. Mais pas parfaite. Le diable se cache dans les transitions et exceptions : redirections, premier clic non sécurisé, contenu mixte, HSTS incomplet, applis anciennes, réglages fragiles des routeurs. Sans oublier les problèmes de confiance aux certificats racines et profils MDM sur les appareils.
TLS 1.3, ECH, HTTP/3 et la réalité des cafés
HTTP/3 basé sur QUIC accélère et chiffre le transport, ECH masque le domaine dans la salutation chiffrée côté client. Parfait sur le papier. Mais dans les réseaux de café, QUIC est souvent limité ou filtré, forçant le client à retomber sur HTTP/2 ou même HTTP/1.1. Ce scénario révèle des failles de compatibilité que les attaquants exploitent pour bloquer les nouveaux protocoles ou injecter des réponses dès le premier contact.
HSTS sauve la mise, jusqu’à ce qu’il soit désactivé
HSTS dit au navigateur : « Va toujours en HTTPS ». C’est top si le site est déjà dans la liste préchargée ou si vous y êtes allé avant en HTTPS. Moins bien si c’est votre première visite et que le réseau impose une redirection HTTP. La fenêtre d’attaque est petite, mais bien réelle. Imaginez maintenant un routeur qui coupe activement les en-têtes HSTS (par un proxy intermédiaire) ou rétrograde la connexion. C’est rare, mais ça arrive dans certains réseaux filtrant agressivement.
Problème des certificats de confiance et profils MDM
Parfois, des appareils embarquent des certificats racines en trop : via VPN piratés, profils d’entreprise, antivirus dépassés. Sur un réseau public, un attaquant peut proposer de « mettre à jour le certificat internet » via un portail captif falsifié. Si vous acceptez, le MITM TLS devient un jeu d’enfant. On a vu ça dans des hôtels et des réseaux touristiques de rue.
Menaces réelles sur les réseaux publics : du MITM à la falsification DNS
La liste est longue, mais voici les attaques les plus communes sur le terrain en 2026 : MITM par ARP-spoofing ou proxy, DNS spoofing avec falsification de domaines et blocage DoH, Evil Twin clonant les SSID, portails captifs phishing avec scripts proxy, et capture de sessions sur des applis sans pinning strict.
MITM via ARP-spoofing
Classique : le pirate convainc votre appareil qu’il est la passerelle par défaut. Tout passe par lui. Il voit beaucoup : domaines, IP, tentatives de handshake. S’il peut faire passer un certificat proxy ou forcer le client en HTTP, il inspecte tout en profondeur. Bonne nouvelle : les OS modernes sont mieux protégés, mais les réseaux publics désactivent souvent ces protections pour « compatibilité ».
DNS spoofing et blocage DoH/DoT
Tout le monde adore DNS over HTTPS, mais beaucoup de portails captifs bloquent DoH/DoT avant authentification, puis oublient de les réactiver. Dans ce laps, l’attaquant peut substituer les réponses : vous demandez bank.example et obtenez bank‑secure‑login.example. Ensuite, SSL stripping ou certificat valide mais rare et bogué prend le relais. Sans vigilance ni protection côté appli, ça tourne mal.
Evil Twin et clones prêts en deux minutes
Créer un point d’accès avec le même SSID, la même adresse MAC et un signal plus puissant, c’est affaire de quelques clics et minutes. Ce « jumeau maléfique » intercepte discrètement le trafic, surtout si vous avez activé la connexion automatique. En 2026, c’est devenu plus simple grâce aux appareils compacts bon marché et aux softs qui copient automatiquement les paramètres réseau. Et oui, beaucoup d’appareils se connectent encore sans question au signal le plus fort.
SSL stripping et suppression HSTS : à quoi ça ressemble en vrai
SSL stripping, c’est quand on vous fait descendre du HTTPS vers le HTTP avant que la protection n’intervienne. Comme attirer quelqu’un sur un escalier mal éclairé : un faux pas et vous glissez.
Scénario 1 : redirection avant HTTPS
Vous tapez une adresse sans https. L’attaquant intercepte la requête initiale et répond avec un site HTTP d’apparence légitime. Le bouton « Se connecter » mène au vrai site HTTPS, mais vos données de formulaire sont déjà attrapées. Visuellement, ça clignote vite, l’utilisateur ne remarque rien, et la session est compromise.
Scénario 2 : bugs de compatibilité et HSTS tronqué
Certains sites activent HSTS partiellement : sous-domaines non protégés, durée de vie courte, pas de préchargement. L’attaquant vous provoque à vous connecter sur un sous-domaine sans HSTS, par habitude ou via une pub. Là, ça tourne à la manipulation : cookies, tokens, ingénierie sociale.
Scénario 3 : certificat utilisateur
Via un faux portail captif, on vous propose de « débloquer internet » en installant un « certificat d’accès ». Un clic et voilà, MITM même sur HTTPS. En 2026, c’est moins fréquent, mais toujours vivant dans les zones touristiques et événements de masse. Surtout si la connexion brade des coupons, réductions ou un « Wi‑Fi bonus sans pub ».
Attaques par portails captifs sans magie : même les vigilants se font piéger
Le portail captif est légal. Mais les attaquants l’aiment parce qu’il banalise les redirections. L’utilisateur voit un écran inhabituel ? Normal, c’est un portail. Alors il clique. Et là, tout passe : certificats, « mises à jour de navigateur »…
Pages phishing camouflées en réseau
Logo du café, nom de l’aéroport, palette de couleurs identiques. On croirait le vrai. Ce portail vous demande e‑mail, mot de passe social « pour vous connecter », numéro de carte pour « vérifier 1 euro » ou Apple/Google ID pour « synchronisation ». Vous seriez surpris du nombre de gens qui cèdent. On a observé un taux de conversion de 3 à 7 % lors d’événements publics, c’est énorme.
Attaques push et pièges QR
QR code sur la table, « connectez-vous au Wi‑Fi rapide ». Vous scannez et arrivez sur une page vous demandant d’installer un profil ou de vous abonner aux notifications. Ensuite, les push affluent avec liens phishing : « Votre session a expiré », « Confirmez le paiement ». Ça continue même une heure plus tard chez vous. Pas cool du tout.
Scripts proxy et collecte de tokens
Certains portails insèrent des scripts proxy qui scrutent vos allers-retours tant que le navigateur met en cache les redirections. Ils identifient vos habitudes, collectent identifiants, et accumulent les risques de retargeting. Ce n’est pas toujours criminel — parfois juste une vilaine pratique marketing — mais ça reste pénible.
Points d’accès frauduleux et Evil Twin : saurez-vous repérer la substitution ?
Vous croyez être connecté à « Airport_Free_WiFi ». Mais en fait, c’est « Airport_Free_WiFi » sur le portable d’un hacker à deux mètres, avec un signal plus fort. Internet marche vite, le café est bon — parfait. Jusqu’à ce qu’il soit trop tard.
Signes d’une substitution
Certificats instables, redirections étranges, disparition soudaine de DoH/DoT, alertes « Cette connexion peut être surveillée », portails qui poppent à chaque site nouveau. Plus des demandes inattendues d’installation de profils, changement de proxy, « mise à jour de sécurité ». Deux fois que ça clignote — c’est suspect.
Pourquoi WPA2-Enterprise ne sauve pas toujours
Les réseaux pro avec 802.1X et EAP, c’est un progrès, mais les utilisateurs ignorent souvent la vérification du nom RADIUS. L’Evil Twin glisse un faux RADIUS avec certificat auto-signé et les clients acceptent. En 2026, les mobiles avertissent mieux, mais l’erreur humaine reste ce qu’elle est.
WPA3, SAE et la réalité
WPA3-Personal avec SAE est plus dur à forcer par bruteforce, mais ça n’empêche pas MITM au niveau IP et DNS si le pirate contrôle le point d’accès. Le chiffrement client-AP n’est pas une protection contre le monde entier, surtout si l’attaquant est sur le point d’accès.
VPN en 2026 : atouts, limites et idées reçues
Le VPN est puissant, mais pas une baguette magique. Il chiffre votre trafic entre point d’accès et serveur VPN, cache les requêtes DNS (bien configuré), et bloque beaucoup de scénarios MITM. Mais il ne protège pas contre le phishing, ne répare pas ce que vous avez installé volontairement (certificat malveillant), et peut lâcher sur portails captifs.
Ce que le VPN protège vraiment
Quand le VPN est actif dès la connexion au réseau, tout passe par un tunnel chiffré. L’attaquant ne voit ni domaine, contenu ni requêtes. Un bon VPN utilise son DNS propre via tunnel, bloque le spoofing DNS. Le kill switch coupe la connexion si le tunnel tombe. En 2026, WireGuard, IKEv2/ChaCha20 sont rapides même sur mobiles, et certains FAI ont adopté QUIC pour la stabilité sur réseaux instables.
Où le VPN est impuissant
Page phishing ? Le VPN ne sait pas si le TLS est légitime. Profil malveillant installé ? Le VPN ne détecte rien. Vol de tokens dans une appli sans pinning ? Le VPN ne sauve pas si l’appli accepte MITM via certificat utilisateur. Et parfois, le VPN ne se lance pas avant le portail captif — et là, la porte est grande ouverte.
Split-tunneling et réglages pointus
Beaucoup activent le split-tunneling « pour la vitesse ». Ça plaît aux attaquants : une partie du trafic passe hors tunnel et peut être interceptée. Sur Wi‑Fi public, mieux vaut tunnel complet strict, interdit les réseaux locaux, et kill switch activé. Moins sexy, mais plus sûr pour dormir tranquille.
Bonnes pratiques concrètes : checklist sans excès
Du pragmatisme, pas de théorie. Étapes claires et habitudes efficaces. Commencez par les règles de base, puis techniques fine-tuning et pour les entreprises.
Règles de base pour tous
- Ne saisissez pas mots de passe ni données bancaires sur Wi‑Fi public sauf extrême nécessité. Si besoin, uniquement via VPN et sur des domaines sûrs.
- Désactivez la connexion automatique aux réseaux ouverts. Connectez-vous manuellement et oubliez le réseau après usage.
- Observez les alertes de certificat. Toute « erreur de sécurité » en public est un drapeau rouge. Fermez l’onglet.
- Ne jamais installer de profils, certificats racines, « accélérateurs internet » ou mises à jour de navigateur via portail.
- Utilisez un navigateur dédié en sandbox pour le public, sans sessions ni connexions enregistrées.
Paramètres techniques utiles
- Activez VPN avec démarrage automatique et kill switch. Désactivez le split-tunneling sur réseaux publics.
- Forcer le système à utiliser DoH/DoT dans VPN. Bloquez le DNS local si le fournisseur tente de l’imposer.
- Désactivez l’installation de certificats racines sans PIN ou biométrie. Contrôlez la liste des certificats de confiance trimestriellement.
- Activez le mode HTTPS uniquement dans le navigateur. Ajoutez extension pour isolation des sessions (conteneurs) et gestionnaire de mots de passe avec détection phishing.
- Mettez en place MFA/2FA, idéalement avec clés matérielles ou passkeys. Les OTP par SMS sont un minimum, mieux que rien.
Pour mobiles et ordinateurs portables
- iOS et Android : interdire synchro en arrière-plan des grosses applis sur réseaux ouverts sans VPN.
- Windows et macOS : activez pare-feu, bloquez connexions entrantes sur réseaux publics, désactivez partage fichiers et AirDrop/Nearby Share temporairement.
- Créez un profil Wi‑Fi « Public » : sans connexion automatique, rappel VPN activé, restrictions réseau local.
Pour entreprises et équipes
- Politiques MDM : interdiction de certificats racines utilisateurs, VPN always-on obligatoire, contrôle CA de confiance.
- Utilisez SASE/ZTNA avec vérification posture appareils : accès d’entreprise limité aux appareils à jour et disque chiffré activé.
- Implémentez filtrage DNS via résolveurs sécurisés, blocage des domaines nouvellement enregistrés (DGA, fast-flux).
- Formez vos équipes tous les six mois. Montrez en live une attaque Evil Twin — la prudence monte en flèche.
Cas concrets : ça se passe vraiment comme ça
Quelques histoires sans détours. Apprendre sur les erreurs des autres coûte moins cher que sur les siennes.
Cas 1 : aéroport et « accès rapide sans pub »
Réseau avec portail captif. Un hacker monte un Evil Twin avec même SSID et signal plus fort. Le portail est identique, mais propose un « booster » via installation de profil. 10 % des utilisateurs acceptent. Résultat : MITM même sur sites bancaires, vol de tokens, redirections phishing. Bilan : comptes piratés et mails corporate fuités.
Cas 2 : café et SSL stripping « au premier clic »
L’utilisateur entre une URL sans https, le pirate injecte une couche HTTP au premier contact. Formulaire intercepté, renvoi vers vrai site, l’utilisateur ne remarque rien. Deux heures plus tard, activités suspectes sur le compte. MFA et journaux ont sauvé la mise, mais l’inquiétude reste.
Cas 3 : conférence, QR code et phishing push
Les organisateurs affichent QR codes « connectez-vous au Wi‑Fi ». Certains sont compromis. Le faux portail inscrit les gens à des notifications push. 24 h plus tard, messages « Confirmez votre connexion ». Taux de conversion : 4 %. Ça fait du bruit sur les réseaux sociaux et quelques histoires malheureuses.
Tendances 2026 qui bousculent les règles
Sans contexte, on reste bloqué sur les vieux conseils. En 2026, trois changements majeurs : adoption massive d’ECH, passkeys en lieu et place des mots de passe, intégration de ZTNA dans les appareils d’entreprise. Ça semble bureaucratique, mais c’est un vrai boost de sécurité.
ECH et masque du SNI
Le déploiement rapide d’ECH réduit les fuites de domaines lors du handshake initial. Ça diminue la portée de certaines écoutes passives sur Wi‑Fi public. Cependant, en cas de retour forcé à d’anciens protocoles (comme souvent sur des points d’accès « rétro »), la protection faiblit. N’éteignez pas les protocoles modernes pour compatibilité, sauf si vraiment nécessaire.
Passkeys et WebAuthn
Quand votre compte utilise un appareil et la biométrie à la place du mot de passe, « voler le mot de passe » ne suffit plus. Même en interceptant le trafic, l’attaquant n’obtient pas les secrets pour se connecter. Combinez passkeys avec restrictions géographiques et matérielles : le Wi‑Fi public fait beaucoup moins peur.
ZTNA et SASE en action
Les entreprises abandonnent les tunnels VPN pour des proxies internes avec vérification contextuelle : qui êtes-vous, quel appareil, patchs à jour, disque chiffré, téléphone rooté ou pas. En public, cette approche limite sévèrement l’ingénierie sociale : vol de mot de passe ne suffit plus pour accéder aux services.
Paramétrage pas à pas sur plateformes populaires
Un peu de concret : quoi cliquer aujourd’hui pour dormir tranquille demain. Sans captures d’écran, mais avec des étapes claires.
iOS 18 et iPadOS
- Réglages — Wi‑Fi — Votre réseau — Connexion automatique : désactivée sur réseaux ouverts. Adresse Wi‑Fi privée : activée.
- Réglages — VPN — Ajouter config : choisissez WireGuard ou IKEv2. Activez « Connexion à la demande » et « Couper le trafic sans VPN » (kill switch via profil MDM ou config).
- Réglages — Safari — Avancé — Mode HTTPS uniquement : activé. Désactivez profils tiers, vérifiez certificats de confiance.
Android 15
- Réseau et internet — Wi‑Fi — Paramètres — Connexion auto : désactivée sur ouverts. Adresse MAC aléatoire : activée.
- VPN : installez client avec always-on et blocage trafic sans VPN. Autorisez DNS-over-VPN, bloquez DNS local.
- Chrome — Sécurité — Utiliser DNS sécurisé — activez DoH (via VPN si dispo). Activez mots de passe sécurisés et alertes phishing.
Windows 12
- Réseau & internet — Wi‑Fi — Gérer réseaux connus : supprimez ouverts, désactivez connexion auto.
- Pare-feu : profil Public — blocage connexions entrantes. Désactivez partage fichiers imprimantes.
- VPN : WireGuard/IKEv2, activez « couper connexion si VPN tombe ». Configurez accès réseau public via VPN uniquement.
macOS 15
- Réseau — Wi‑Fi — Avancé : supprimez ouverts, désactivez auto‑connexion aux inconnus.
- Pare-feu — Activé — Bloquer toutes connexions entrantes sur profil public. Désactivez AirDrop sur « Contacts uniquement » ou complètement.
- Configurez VPN avec connexion automatique sur réseau public détecté. Safari — activez « Préférer HTTPS » et protection anti-tracking.
Phishing et ingénierie sociale : pourquoi on clique
La technique se gère par réglages. Les gens, c’est plus compliqué. On clique quand on est pressé, fatigué, attiré par un bonus, ou quand « ça semble logique ». Le Wi‑Fi public est parfait pour accélérer la prise de décision : vous faites la queue, votre café refroidit, les collègues demandent « alors ? ». C’est là qu’on se fait avoir.
Comment se protéger
- Faites une pause de trois secondes. Tout portail inconnu mérite réflexion. Si l’IP ou portail demande mot de passe mail, c’est presque sûr un piège.
- Repérez les signes de phishing : domaines bizarres avec tirets, zones suspectes, avertissements navigateur. En cas de doute, testez via réseau mobile, pas via le même Wi‑Fi.
- Utilisez un gestionnaire de mots de passe : il ne remplira pas un mot de passe sur un domaine différent. Pas de remplissage auto ? Vérifiez l’URL manuellement.
Applications mobiles — le point faible caché
Toutes les applis ne font pas un pinning strict des certificats serveur. Donc en MITM avec certificat utilisateur, elles peuvent faire confiance au pirate. En 2026, beaucoup corrigent ça, mais pas tous. Gardez les services sensibles dans le navigateur avec passkeys et paramètres stricts, pas dans des applis douteuses.
Erreurs qu’on répète sans cesse
Honnêtement ? On fait tous des erreurs. Appelons un chat un chat et cessons ça.
Connexion auto partout
Désactivez globalement. Mieux vaut prendre 10 secondes à choisir un réseau que perdre 10 heures à récupérer un compte.
Ignorer les erreurs de certificat
« Ah, sûrement un bug du café ». Non. Dans 9 cas sur 10, c’est précisément ce à quoi alerte le navigateur. Quittez la page.
Utiliser ses mots de passe pro en open Wi‑Fi
Si ce n’est pas possible, abstenez-vous. Si urgent, uniquement via VPN/ZTNA corporate, MFA, et navigateur sécurisé.
Pour développeurs et admins : que faire aujourd’hui
Les gens utiliseront toujours les Wi‑Fi publics. Notre rôle : faire en sorte que ce soit moins risqué même dans un contexte hostile.
Pour le web
- HSTS strict avec includeSubdomains et preloading. Prévoyez 1 à 2 ans minimum.
- Éliminez contenu mixte. Utilisez Content Security Policy et mode HTTPS obligatoire.
- Activez WebAuthn/passkeys. Réduisez la dépendance aux mots de passe.
- Surveillez sous-domaines et typosquatting. Alertes automatiques sur nouveaux clones de domaine.
Pour applis mobiles
- Certificate pinning avec rotation des clés. Gestion des certificats racines non fiables.
- Bloquez fonctionnement sur appareils rootés/jailbreakés pour fonctions critiques. Intégrez protection MITM dans le SDK.
- Fail-closed : rejetez la connexion si certificat douteux.
Pour réseaux d’entreprise
- Politiques MDM, ZTNA, posture appareil et contrôle des certificats. Bloquez proxys locaux et profils non signés.
- Logs et détection d’anomalies : pics d’erreurs TLS, blocages DoH, réauthentifications massives aux portails, tout est un signal d’alerte.
Checklist rapide avant connexion à un Wi‑Fi public
- Ce réseau est-il vraiment nécessaire ? Vérifiez le nom auprès du personnel.
- La connexion automatique est-elle désactivée ? Parfait.
- Le VPN se lance-t-il automatiquement ? Le kill switch est-il actif ?
- Le navigateur est en mode HTTPS uniquement, gestionnaire de mots de passe actif ?
- Pas d’installation de profils ni de certificats, même si on insiste.
- Évitez paiements et actions administratives si possible.
Que faire si vous pensez être attaqué
Gardez votre calme. Le plan est simple. Quelques étapes rapides pour retrouver la sécurité.
Pas à pas
- Déconnectez-vous immédiatement du Wi‑Fi et passez en réseau mobile.
- Changez les mots de passe des comptes clés, révoquez sessions et tokens.
- Vérifiez les listes de certificats et profils de confiance. Supprimez les suspects.
- Activez alertes de connexions, ajoutez ou renouvelez passkeys, actualisez MFA.
- Consultez les logs : connexions depuis régions suspects, tentatives de récupération. Contactez le support si nécessaire.
Un minimum de risque avec un maximum de bon sens
Le Wi‑Fi public, c’est comme un taxi de nuit : parfois indispensable, mais sans excès. Un peu de vigilance, quelques bons réglages, des habitudes solides — et vous êtes dans le top 10 % des cibles les plus difficiles. Les hackers préfèrent les victimes plus faciles.
Faisons ce pacte : pas de parano, mais pas d’aveuglement non plus. On active VPN à l’avance, on évite les profils douteux, on écoute les alertes, on aime passkeys et ZTNA, et on nettoie nos certificats de confiance tous les six mois. Les détails font la différence. Et promis, le café ne refroidira pas.
FAQ : questions fréquentes sur le Wi‑Fi public et la sécurité
HTTPS suffit-il en 2026 pour être protégé ?
Non. HTTPS est la base, mais n’empêche pas le phishing, ne bloque pas les redirections captives, ne protège pas si vous avez installé un certificat malveillant. C’est un pilier, pas un château fort. Complétez avec VPN, mode HTTPS uniquement, passkeys et une bonne dose de scepticisme.
Le VPN résout-il tous les problèmes du Wi‑Fi public ?
Non. Le VPN chiffre et cache le DNS, mais ne combat pas le phishing ni l’ingénierie sociale. Il ne peut rien si vous avez vous-même fait confiance au pirate via un profil. Utilisez-le comme base, mais pas comme seule protection.
Les portails captifs sont-ils dangereux ?
Autant que votre vigilance est faible. Un portail légal est acceptable, mais normalise la présence d’une « fenêtre étrange ». C’est là que se concentrent le plus les attaques. Ne saisissez jamais vos mots de passe sur d’autres services, ne posez pas de profils ni certificats. Jamais, non jamais.
Faut-il désactiver la connexion automatique aux réseaux ouverts ?
Oui. C’est votre meilleure défense contre Evil Twin. Connectez-vous manuellement, vérifiez le réseau auprès du personnel, supprimez-le après usage. Et activez l’adresse MAC privée.
Que vaut plus que l’autre : DoH/DoT ou VPN ?
Si vous deviez choisir, VPN, car il encapsule DNS et trafic entier. Mais le mieux reste la combinaison : DoH/DoT au sein du VPN. L’essentiel est d’éviter que le système tombe sur un DNS local en Wi‑Fi public.
Des passkeys sont-elles nécessaires si on a déjà de bons mots de passe et 2FA ?
Oui. Les passkeys réduisent quasi à zéro le risque de phishing, car elles lient domaine et appareil. Associées à 2FA, elles rendent les attaques bien plus coûteuses pour les pirates.
Peut-on utiliser sereinement les services bancaires sur Wi‑Fi public ?
C’est possible, mais privilégiez le réseau mobile ou un VPN strict avec mode HTTPS uniquement et gestionnaire de mots de passe. À la moindre alerte de certificat ou redirection douteuse, fuyez et changez de connexion.