Déploiement de bornes & étude Wi-Fi — Hôtel de Courcy & hémicycle

1. Cadrage et contraintes des sites

L’étude portait sur deux ensembles de bâtiments institutionnels : le site du Bon Pasteur (dont la salle de l’hémicycle) et l’Hôtel de Courcy, où se trouve notamment le bureau du président de la Région. Ces lieux accueillent régulièrement des réunions, des événements et des équipes qui ont besoin d’un Wi-Fi stable, homogène et capable d’absorber plusieurs connexions simultanées sans dégradation nette du service.

Les objectifs étaient clairs : contrôler la qualité du signal zone par zone, repérer les trous de couverture, analyser l’occupation des canaux et, si nécessaire, préparer des ajustements de positionnement ou de puissance des points d’accès — toujours en restant aligné avec les règles de sécurité du SI.

Nous avons vérifié qu’aucune réunion ou manifestation officielle n’était prévue sur nos créneaux, afin de ne pas perturber le fonctionnement des lieux et de pouvoir réaliser les mesures dans de bonnes conditions. Cette phase d’organisation est indispensable sur des sites sensibles.

2. Construction du modèle dans Ekahau Pro

Avant tout relevé, il faut construire dans Ekahau Pro un modèle fidèle du bâtiment : composition des murs, matériaux des portes, vitres et cloisons. Le logiciel est exigeant — à juste titre — car chaque type de paroi a un impact différent sur l’atténuation des ondes. Une configuration imprécise fausserait les cartes de couverture et donnerait de fausses certitudes.

Le plan doit être calibré à l’échelle réelle : sans cela, les distances parcourues pendant les mesures ne correspondent pas au modèle, les emplacements des bornes sont mal positionnés et les recommandations d’ajout d’AP peuvent être à côté de la plaque. Cette étape est longue, mais elle conditionne toute la suite du projet.

3. Campagne de mesures sur le terrain

J’ai réalisé les relevés selon une grille méthodique : environ un point de mesure tous les trois pas, en longeant les murs et en traversant chaque pièce pour éviter les trous dans la carte. L’objectif est une cartographie dense exploitée ensuite par le moteur de calcul d’Ekahau.

Pendant la campagne, il faut constamment vérifier sur l’écran que toute la surface du plan visité est couverte par des mesures — les zones grises non visitées apparaissent comme non fiables ou absentes de signal dans le rapport final.

4. Lecture du rapport et arbitrages

À l’issue des relevés, Ekahau génère une cartographie de la couverture. Le code couleur est lisible rapidement : le vert correspond en général à une couverture correcte pour un usage professionnel standard (navigation, messagerie, outils collaboratifs) ; le jaune ou l’orange traduisent une baisse de niveau qui peut se traduire par des débits plus faibles ou une expérience plus fragile ; le gris indique une zone où le signal est insuffisant ou absent — ce qui impose une action (nouvel AP, réglage, ou parfois correction câblage / SSID si la cause n’est pas uniquement radio).

L’analyse ne se limite pas au niveau de signal brut : on s’intéresse aussi à la continuité de la couverture, à la cohérence entre les cellules et aux zones de rupture qui peuvent provoquer des déconnexions ou des difficultés lors des déplacements des utilisateurs. Le rapport d’étude complet comporte de nombreuses pages détaillant fréquences et indicateurs ; sur le terrain, l’objectif est d’en tirer des décisions : puissance, canaux, ajout stratégique de bornes.

L’extrait illustré dans le dossier professionnel montrait une zone grise en bout d’aile, signe d’un trou de couverture ; la solution retenue a été le déploiement d’un point d’accès supplémentaire pour homogénéiser le service.

5. Déploiement des Cisco Meraki MR36

Les emplacements retenus correspondaient aux zones identifiées comme insuffisantes dans Ekahau. Nous avons déployé des bornes Cisco Meraki MR36 aux endroits indiqués, en visant une couverture plus homogène dans les pièces concernées. Chaque borne a été raccordée au réseau en Power over Ethernet (PoE) : le commutateur alimente l’AP via le câble Ethernet, ce qui évite d’ajouter une prise électrique dédiée au plafond et simplifie l’installation.

Côté LAN, nous avons configuré les ports du switch pour transporter les deux VLAN nécessaires au fonctionnement des bornes selon notre modèle. Le DHCP a été mis à jour pour réserver une adresse IP en fonction de l’adresse MAC de chaque équipement. Une entrée RADIUS a également été ajoutée côté NPS (Windows) pour sécuriser l’authentification des bornes sur le réseau, conformément aux exigences internes. Les VLAN concernés ont été autorisés à joindre la plateforme cloud Meraki, ce qui permet l’appairage automatique des nouvelles bornes dans le tableau de bord.

Nous avons choisi d’installer les AP visibles sous plafond plutôt que totalement dissimulés dans un faux plafond fermé, afin de faciliter maintenance, contrôles et remplacement ultérieur — en validant ce compromis avec le contexte du bâtiment.

Les flux vers le cloud Meraki doivent rester explicitement autorisés au pare-feu : à défaut, les points d’accès peuvent paraître inactifs alors que le câblage est correct — situation fréquente lors des intégrations réseau.

6. Enregistrement et vérification Meraki Dashboard

Une fois installées et raccordées, les MR36 se connectent au cloud Meraki dès qu’elles ont accès à Internet. Dans le Meraki Dashboard, je les ai rattachées au réseau correspondant au bâtiment : la configuration Wi-Fi déjà définie par l’équipe (SSID, sécurité, paramètres radio) est alors récupérée automatiquement par les nouvelles bornes.

L’intérêt du modèle cloud, dans notre contexte multi-sites, est triple : gestion centralisée depuis une seule interface, sans session locale sur chaque AP ; supervision de l’état des équipements à distance ; mises à jour logicielles déployables de façon contrôlée sur l’ensemble du parc, ce qui aide à maintenir le niveau de sécurité et de performance sans intervention physique systématique.

Cette phase de vérification a servi à confirmer que les nouvelles bornes étaient bien opérationnelles, intégrées à l’existant et correctement suivies dans les outils d’administration du réseau.

7. Retour utilisateurs une semaine après

Environ une semaine après l’intervention, nous avons pris le temps d’échanger avec des utilisateurs des zones concernées. L’objectif était de croiser les mesures radio avec le ressenti quotidien : coupures encore présentes ou non, lenteurs, difficultés d’association au Wi-Fi, zones où le service reste fragile.

Ces retours complètent les graphiques Ekahau et le dashboard Meraki : ils aident à détecter des problèmes liés à l’charge, à des terminaux particuliers ou à des usages (visio, fichiers lourds) que seuls les usagers remontent spontanément. Les échanges ont globalement confirmé une amélioration perceptible là où la couverture était déficiente avant ajout de bornes.

8. Bilan

Ce chapitre couvre toute la chaîne d’un projet Wi-Fi institutionnel : modélisation sérieuse, campagne de mesures méthodique, lecture de rapport et arbitrages, puis déploiement matériel (MR36, PoE), intégration LAN (VLAN, DHCP, NPS) et validation dans le cloud et auprès des utilisateurs. J’ai mieux compris comment la couche radio s’articule avec la sécurité et l’exploitation d’un grand SI.