Illustration générée par IA — visuel conceptuel.
Dans un hôtel comme en entreprise, le Wi‑Fi est jugé sur deux critères qui s’opposent parfois : la simplicité d’accès (zéro friction, peu d’appels au support) et une sécurité crédible (au minimum limiter l’écoute radio « d’à côté », et éviter qu’un invité voie les systèmes métiers). Le troisième critère, souvent oublié, est le plus coûteux en exploitation : la résilience (que se passe-t-il quand le portail captif ou le RADIUS tombe ?).
Ce guide compare les principaux modèles de sécurité et d’authentification Wi‑Fi — portail captif, WPA2/WPA3‑Personal, WPA3‑Enterprise / 802.1X, OWE (Enhanced Open) — et propose une méthode pour choisir sans casser l’expérience client tout en préparant un mode dégradé réaliste.
Pour compléter ce dossier avec une approche “terrain” (segmentation, isolation, exploitation), vous pouvez aussi lire : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client et VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?
Clarifier l’objectif : “sécuriser le Wi‑Fi” ne veut pas dire une seule chose
Avant de comparer les options, il faut séparer trois couches qui se confondent souvent dans les discussions :
- Sécurité radio Wi‑Fi (couche L2) : chiffrement/authentification entre le terminal et le point d’accès, sur le médium radio.
- Contrôle d’accès (couche IP/WEB) : qui a le droit d’aller sur Internet, pendant combien de temps, via quel parcours (portail captif, vouchers, etc.).
- Architecture réseau : segmentation (VLAN/SSID), règles firewall, isolation inter-clients, protection des réseaux métiers et techniques.
Un portail captif peut très bien exister sur un réseau Wi‑Fi non chiffré. À l’inverse, un Wi‑Fi chiffré (WPA3 ou OWE) n’implique pas automatiquement un portail captif. Dans un projet sérieux, ces couches se combinent selon le niveau de service attendu.
Les options en clair : ce que chaque modèle protège (et ce qu’il ne protège pas)
Réseau “Open” (sans chiffrement)
Le terminal s’associe au SSID et le trafic radio n’est pas chiffré au niveau Wi‑Fi. C’est simple, mais l’écoute radio opportuniste est facilitée (même si la plupart des usages sont aujourd’hui en HTTPS, cela ne règle pas tous les risques et cela ne donne aucune garantie d’isolation entre clients).
Portail captif (web authentication)
Le portail captif gère l’accès après association au Wi‑Fi : acceptation de CGU, code d’accès, voucher, authentification par email/téléphone selon les choix de l’établissement, etc. Il ne remplace pas à lui seul le chiffrement radio.
Point important : le parcours “portail” dépend de plusieurs services invisibles (DNS, DHCP, redirections HTTP/HTTPS, certificats). En hôtellerie, un incident de portail se traduit très vite par une perception “le Wi‑Fi est en panne”, même si la radio et les AP fonctionnent.
OWE / “Enhanced Open” (Wi‑Fi ouvert mais chiffré)
OWE (Opportunistic Wireless Encryption) vise à apporter un chiffrement automatique sur un réseau sans mot de passe. C’est particulièrement pertinent pour un SSID invités : expérience proche d’un réseau ouvert, mais confidentialité radio améliorée.
Limite à connaître : OWE n’apporte pas d’authentification forte (pas “d’identité” vérifiée du réseau au sens 802.1X). Il faut donc le voir comme une amélioration de confidentialité sur l’air, pas comme un mécanisme d’identité ou de conformité “entreprise”.
WPA2 / WPA3‑Personal (PSK / SAE)
Le Wi‑Fi est chiffré et l’accès se fait via un secret partagé (mot de passe). En WPA3‑Personal, l’échange de clé s’appuie sur SAE (au lieu d’un PSK “classique”), ce qui améliore la robustesse contre certains scénarios d’attaque, mais ne résout pas un problème structurel côté exploitation : un mot de passe partagé se partage (clients qui le transmettent, ancien client qui revient, sous-traitant, etc.).
Dans un hôtel, WPA‑Personal peut rester utile dans des zones “semi‑privées” ou pour certains équipements (selon compatibilités), mais ce n’est généralement pas le meilleur compromis pour un SSID invités “grand public”.
WPA3‑Enterprise / 802.1X (EAP + RADIUS)
Ici, l’enjeu principal n’est pas seulement le chiffrement : c’est l’identité. Le terminal s’authentifie via 802.1X/EAP, et l’infrastructure s’appuie sur un backend AAA (souvent RADIUS). C’est la base d’un Wi‑Fi “entreprise” : politiques par rôle, segmentation dynamique selon le profil, meilleure traçabilité, etc.
En contrepartie, ce choix introduit des dépendances d’exploitation : disponibilité RADIUS, certificats/PKI selon la méthode EAP retenue, synchronisation horaire, supervision, procédure de bascule. Ce n’est pas un défaut : c’est une discipline d’architecture à assumer, documenter et recetter.
Tableau de décision : choisir sans marketing
Le tableau ci-dessous aide à décider rapidement. Il n’existe pas de “meilleure” option universelle : le bon choix dépend de votre parc de terminaux, de votre niveau d’exigence et de votre capacité d’exploitation.
| Option | Confidentialité radio | Identité / politiques | Expérience utilisateur | Dépendances critiques | Quand c’est pertinent |
|---|---|---|---|---|---|
| Open + portail captif | Faible (pas de chiffrement Wi‑Fi) | Faible (contrôle “web” uniquement) | Variable (pop-up/redirect parfois capricieux) | DNS/DHCP/portail/certificats | À éviter quand OWE est possible ; parfois conservé en transition/legacy |
| OWE / Enhanced Open (+/‑ portail) | Bonne (chiffrement “sur l’air” sans mot de passe) | Pas d’identité forte | Très bonne (pas de mot de passe) | Compatibilité terminaux à valider | SSID invités d’hôtel, cafés, espaces publics (objectif : confidentialité sans friction) |
| WPA2/WPA3‑Personal | Bonne (si mot de passe maîtrisé) | Secret partagé (pas de vraie identité par utilisateur) | Bonne si mot de passe simple ; moins bon si rotation fréquente | Gestion du secret (diffusion, rotation, fuite) | Petits sites, zones semi‑privées, certains SSID techniques cloisonnés |
| WPA3‑Enterprise / 802.1X | Très bonne | Forte (politiques par rôle/identité) | Variable (profil, MDM, onboarding) | RADIUS/AAA, méthodes EAP, certificats, supervision | Wi‑Fi staff/back‑office, entreprise, environnements BYOD maîtrisés |
| Combinaisons (souvent la réalité) | Dépend du mix | Dépend du mix | Optimisable | Plusieurs couches à coordonner | Hôtels : invités ≠ staff ≠ IoT ≠ admin (un seul SSID “pour tout” est rarement sain) |
Scénarios recommandés (hôtel & entreprise)
Hôtel : SSID invités (priorité = simplicité + confidentialité minimale)
- Recommandation typique : SSID invités en OWE (Enhanced Open).
- Si CGU / voucher / parcours marketing : ajouter un portail captif (sans renoncer au chiffrement radio).
- Si forte contrainte “legacy” : prévoir une stratégie de transition (à cadrer selon le matériel Wi‑Fi) et accepter qu’une partie des terminaux anciens ne profitent pas du chiffrement OWE.
À ne pas oublier : dans un hôtel, la sécurité “utile” ne s’arrête pas au chiffrement radio. L’isolation entre clients et la séparation stricte d’avec les réseaux métiers sont structurantes. Sur ce point, voir aussi Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?
Hôtel : SSID staff / back‑office (priorité = identité & contrôle)
- Recommandation typique : WPA3‑Enterprise (802.1X), avec politiques par rôle.
- Prévoir redondance RADIUS et tests de bascule.
- Documenter l’onboarding (terminaux d’exploitation, téléphonie Wi‑Fi si utilisée, postes fixes, etc.).
Entreprise : SSID corporate + SSID invités
- Corporate : 802.1X (WPA3‑Enterprise) dès que l’entreprise veut une identité par utilisateur/terminal et des politiques réseau cohérentes.
- Invités : OWE + portail captif (ou portail seul si compatibilité OWE insuffisante), avec isolation stricte et règles firewall minimales.
Pour une approche globale “Wi‑Fi pro” côté conception (couverture/capacité/LAN), voir : Réseau Wi‑Fi professionnel : comment bien le concevoir en entreprise ?
Le vrai sujet : concevoir le mode dégradé (si portail ou RADIUS tombe)
En production, l’incident “qui fait mal” n’est pas le plus spectaculaire : c’est celui qui multiplie les plaintes et mobilise la réception ou le support. Deux pannes reviennent en boucle : portail captif indisponible et RADIUS indisponible. La bonne approche n’est pas d’espérer “zéro panne”, mais de choisir le comportement attendu, puis de le recetter.
Portail captif indisponible : trois comportements possibles (à décider)
- Fail‑open (continuité) : si le portail est down, on laisse sortir vers Internet (avec isolation et filtrage maintenus). Avantage : continuité de service ; inconvénient : perte temporaire du contrôle “portail”.
- Fail‑closed (contrôle) : si le portail est down, on bloque. Avantage : politique stricte ; inconvénient : perception client “Wi‑Fi en panne”.
- Portail minimal de secours : page locale de repli (selon solutions) pour réduire l’impact, tout en gardant une validation minimale.
Le choix dépend du positionnement de l’établissement (loisir vs business), de l’impact sur l’exploitation, et du cadre interne de gouvernance. L’important est de le formaliser : la “bonne” décision est celle que votre équipe sait expliquer et opérer.
RADIUS indisponible (802.1X) : distinguer “nouveaux” et “déjà connectés”
Sur un SSID 802.1X, la question à trancher est souvent la suivante :
- Que fait-on pour un terminal déjà authentifié si le RADIUS devient indisponible ?
- Autorise-t-on de nouveaux terminaux (et si oui, selon quel mécanisme) ?
Selon les contrôleurs/passarelles, il existe des mécanismes de bascule (serveur primaire/secondaire) et, parfois, des mécanismes de cache/survivabilité. Ce n’est pas “automatique” : il faut le configurer, décider des délais, et vérifier le comportement réel en panne (et lors du retour à la normale).
Recommandation projet : éviter de découvrir le comportement 802.1X “en live” le jour d’un incident. Une recette simple (panne RADIUS simulée) permet de valider le scénario retenu et de construire un runbook exploitable.
Recette (tests) : ce qu’il faut valider avant ouverture ou réception
L’objectif d’une recette n’est pas de cocher “WPA3” sur une configuration : c’est de valider un parcours utilisateur et un comportement en panne. Voici une checklist orientée exploitation.
Tests “parcours client” (SSID invités)
- Connexion initiale sur différents terminaux (smartphones récents, laptops, et quelques terminaux “à problème” typiques : consoles, TV, objets connectés selon le site).
- Affichage et stabilité du portail captif (si présent) : redirection, certificat, langues, comportement en HTTPS.
- Reconnexion : que se passe-t-il après veille du terminal, sortie/entrée de chambre, changement d’AP (roaming) ?
- Isolement inter-clients : vérifier qu’un client ne voit pas les autres terminaux invités (et documenter les exceptions nécessaires, par exemple casting si vous l’autorisez).
Tests “RADIUS down” (SSID staff / corporate)
- Arrêt du serveur RADIUS primaire : validation de la bascule vers le secondaire.
- Comportement des clients déjà connectés pendant la panne (stabilité, durée, renouvellement éventuel).
- Comportement des nouveaux clients pendant la panne (bloqués ? autorisés via mécanisme de survivabilité ?).
- Retour à la normale : resynchronisation, stabilité, absence d’effet “yoyo”.
Tests “portail down”
- Simuler une indisponibilité réaliste (service web arrêté, résolution DNS en défaut, certificat expiré si le scénario existe).
- Vérifier le comportement choisi (fail‑open / fail‑closed / repli).
- Vérifier le message utilisateur et la procédure réception/support.
Tests “infrastructure invisible” (DNS/DHCP)
- Un terminal obtient-il une IP dans le bon VLAN ?
- Le DNS répond-il correctement (un incident DNS peut “ressembler” à une panne Internet) ?
- Les règles firewall sont-elles cohérentes avec le portail (si présent) et les services autorisés ?
Pour une démarche plus large “hôtel” (modes dégradés, dépendances, exploitation), la lecture de l’architecture globale est souvent déterminante : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?
Points d’architecture à ne pas rater (sinon WPA3 ne changera rien)
Segmenter : invités ≠ staff ≠ systèmes techniques ≠ administration
Un SSID “Guest” ne doit pas voir le PMS, la GTB/GRMS, les caméras, la téléphonie ou les interfaces d’administration. La segmentation (VLAN) doit être accompagnée de règles de filtrage explicites : “séparer” sans contrôler les flux laisse une partie du risque intacte.
À lire : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?
Ne pas baser toute la sécurité sur un seul mécanisme
- OWE améliore la confidentialité radio, mais ne remplace pas une segmentation et un filtrage cohérents.
- Un portail captif structure l’accès, mais ne chiffre pas “magiquement” l’air.
- 802.1X apporte l’identité, mais impose une ingénierie de résilience (RADIUS, certificats, supervision).
Superviser ce qui casse vraiment l’expérience
Sur un réseau hôtelier, la supervision ne doit pas se limiter à “les AP sont up”. Les incidents visibles côté client sont souvent liés à des services d’infrastructure (DNS/DHCP/AAA) ou à des dépendances applicatives (portail, certificats). C’est un sujet de runbook et de responsabilités, pas uniquement de matériel.
Conclusion : un modèle simple, robuste et crédible (hôtel & entreprise)
Dans la majorité des projets, l’architecture la plus rationnelle ressemble à ceci :
- Invités : OWE (Enhanced Open) + portail captif si nécessaire (CGU/vouchers), avec isolation inter-clients et segmentation stricte.
- Staff / corporate : WPA3‑Enterprise / 802.1X, RADIUS redondé, bascule et mode dégradé testés.
- Exploitation : une recette qui inclut les pannes (RADIUS/portail/DNS/DHCP), et une documentation exploitable par les équipes.
Si vous souhaitez valider ce design sur votre site (hôtel, siège, clinique, resort), Domocasa peut intervenir en audit Wi‑Fi ou en redesign : l’objectif n’est pas d’ajouter des options, mais de rendre le service plus stable, plus lisible et plus maintenable.
