Un wifi invité qui ne donne accès qu'à Internet

Trois exigences qui semblent s'opposer

Un accès wifi d'établissement doit satisfaire trois attentes qui, à première vue, tirent dans des directions différentes :

• Simple pour le visiteur. Personne n'ira demander un mot de passe à l'accueil, ni installer quoi que ce soit. La connexion doit se faire en deux gestes.
• Cloisonné pour l'exploitant. Le téléphone d'un client de passage n'a aucune raison de pouvoir parler à la caisse, aux caméras ou au poste de gestion.
• Traçable pour la loi. Fournir un accès à Internet au public s'accompagne d'obligations de conservation des données techniques de connexion.

Le réflexe courant consiste à traiter la première et à repousser les deux autres. C'est précisément l'inverse qu'il faut faire : les contraintes de cloisonnement et de traçabilité structurent l'installation, et la simplicité d'usage se construit par-dessus.

Séparer les usages : le principe des VLAN

Un réseau d'entreprise « à plat » place tous les appareils dans le même espace : les postes de travail, l'imprimante, le système d'encaissement, les caméras, le stockage partagé — et, si on y branche un wifi ouvert, les téléphones de tous les visiteurs. Dans cette configuration, un appareil compromis dans le lot peut en atteindre d'autres.

La segmentation en VLAN (réseaux locaux virtuels) répond à ce problème sans tirer un seul câble supplémentaire. Le même équipement porte plusieurs réseaux logiques, étanches entre eux : l'exploitation d'un côté, les invités de l'autre. Chacun a son propre adressage, et l'équipement n'autorise à circuler de l'un à l'autre que ce qui a été explicitement décidé.

Pour un accès invité, la règle est simple à énoncer : le réseau invité ne mène qu'à Internet. Il ne voit pas les ressources internes, et il ne les verra pas davantage si un appareil qui s'y connecte se révèle infecté. On y ajoute l'isolation entre clients : deux appareils connectés au même réseau invité ne se voient pas non plus l'un l'autre — ce qui protège les visiteurs entre eux, pas seulement l'établissement.

L'intérêt secondaire est budgétaire : il n'y a rien à racheter. La segmentation se configure sur l'infrastructure existante, et le jour où un nouvel usage arrive — un écran d'affichage, un boîtier de réservation, un objet connecté quelconque — il prend sa place dans le segment qui lui correspond au lieu d'atterrir au milieu des données de gestion.

Le portail captif : là où le consentement se joue

Le visiteur qui rejoint le réseau tombe sur une page aux couleurs de l'établissement, hébergée et maintenue par nos soins, qui dialogue avec les bornes pour autoriser la session. C'est cette page qui porte tout ce qui doit être dit avant la connexion.

Deux choix y sont structurants :

• Les conditions d'utilisation sont affichées, pas cachées derrière un lien. Le visiteur a sous les yeux l'objet du service, ce qui est interdit, ce qui est conservé et pendant combien de temps.
• La case n'est pas pré-cochée, et le bouton reste inactif tant qu'elle ne l'est pas. Le consentement est un geste délibéré. Une case déjà cochée à l'arrivée ne vaut pas consentement, et une acceptation implicite ne se démontre pas.

Ce détail d'interface est aussi ce qui rend l'installation défendable : il n'y a pas d'un côté la technique et de l'autre la conformité. Ici, c'est le même écran.

Journaliser ce qu'il faut, et rien de plus

Fournir un accès public implique de conserver des données techniques de connexion et de pouvoir les transmettre sur réquisition. C'est une obligation légale, pas une option — et c'est aussi la contrepartie qui protège l'exploitant : sans journal, c'est l'abonné qui répond de ce qui est parti de sa ligne.

Le principe directeur est celui de la minimisation : on conserve ce qui identifie une session, pas ce que la personne en a fait.

La durée de conservation est bornée à un an, et elle est annoncée au visiteur avant qu'il accepte — pas enfouie dans une politique que personne ne lira. Une durée qu'on ne s'engage pas à tenir n'a aucune valeur : elle doit s'appliquer réellement, ce qui suppose une purge et non un fichier qui grossit indéfiniment.

Le journal est lui-même une donnée à protéger

C'est l'étape qu'on oublie le plus souvent. Un fichier qui contient des adresses IP, des adresses MAC et des horaires de présence est un traitement de données personnelles. Le constituer pour se conformer à une obligation, puis le laisser accessible, revient à créer le problème qu'on voulait éviter.

Le répertoire qui les héberge est donc fermé en accès direct depuis le web : une requête vers le journal se heurte à un refus du serveur, pas à un téléchargement. C'est une ligne de configuration ; son absence transformerait une mise en conformité en fuite de données.

Ce que ça change, concrètement

• Pour l'exploitant : le wifi devient un service offert aux clients, pas une porte ouverte sur les outils qui font tourner l'établissement.
• Pour le visiteur : il sait ce qui est conservé avant de se connecter, et il n'est pas exposé aux autres appareils connectés au même réseau.
• En cas de réquisition : l'information demandée existe, elle est datée, et elle se retrouve — sans avoir à fouiller ni à improviser.

Ce que nous en retenons

Sur ce type d'installation, trois principes reviennent à chaque fois :

• Le cloisonnement d'abord, le confort ensuite. Un accès invité conçu autour de la contrainte reste simple à utiliser ; l'inverse oblige à tout reprendre.
• La conformité se joue dans l'interface, pas dans un document annexe. Ce que le visiteur lit et coche fait partie de l'installation technique.
• Protéger ce qu'on est obligé de collecter. Une obligation légale mal appliquée crée un risque au lieu de le couvrir.

Un wifi public bien posé ne se remarque pas : le client se connecte en deux gestes et n'y pense plus. Tout le travail est dans ce qu'il ne voit pas.