Illustration générée par IA — visuel conceptuel.
Pourquoi la “capacité” Wi‑Fi compte autant que la couverture
Un réseau peut afficher un excellent niveau de signal et pourtant offrir une expérience médiocre dès qu’on ajoute de la simultanéité (beaucoup de clients actifs), de la voix/visioconférence (sensibles aux pertes et à la latence), ou de la mobilité (roaming). En hôtellerie, c’est typiquement ce qui se produit dans un lobby, un restaurant, une salle événementielle… et parfois même à l’étage lorsque l’occupation monte.
L’objectif d’une recette “capacité” n’est pas de produire un seul chiffre de débit. C’est de répondre à une question exploitable : à charge réaliste, le service reste-t-il stable ? Et si non : est-ce un manque de points d’accès, un réglage radio à revoir, ou un goulot d’étranglement côté LAN (uplinks, switching, PoE, pare-feu, accès Internet) ?
Ce qu’on teste réellement (et comment le relier à une décision)
Pour rester simple et actionnable, on peut structurer la recette autour de cinq axes. Chacun doit être mesuré en condition “au repos” puis sous charge.
- Simultanéité / densité : combien de clients actifs dans une zone avant dégradation (et surtout comment la dégradation se manifeste).
- Throughput utile : débit observé “côté application” (souvent en TCP), et comportement quand on injecte de l’UDP (puisque l’UDP révèle rapidement pertes et gigue).
- Latence sous charge : la latence ne se juge pas seulement “réseau vide”. Elle doit rester maîtrisée quand le réseau travaille.
- Pertes / jitter : particulièrement critique pour la voix et la vidéo temps réel.
- Roaming : interruption lors d’un changement de point d’accès, et stabilité pendant un déplacement (data et voix).
Repère voix (utile, mais à interpréter avec prudence)
Pour les applications interactives, l’ITU‑T recommande des limites de délai aller simple (one-way) : 0 à 150 ms est indiqué comme acceptable pour la plupart des usages, et 150 à 400 ms comme acceptable sous réserve de connaître l’impact sur la qualité perçue. (ITU‑T G.114)
En pratique, dans un bâtiment (hôtel/bureaux), on n’a pas toujours un outil simple pour mesurer l’aller simple de bout en bout sur un terminal utilisateur. On suit donc souvent le RTT (ping) vers des cibles LAN puis WAN, et on observe surtout la dérive sous charge (ce qui met en évidence une saturation radio ou un goulot LAN/WAN).
Préparer la recette : ce qu’il faut figer avant de lancer les tests
1) Définir des scénarios d’usage (par zone)
Avant d’ouvrir iperf3, décrivez qui fait quoi et où. En hôtel, il est utile de distinguer (au minimum) :
- Chambres : usage “résidentiel” dispersé, mais répété à l’échelle d’un étage.
- Lobby / restaurant : zones denses, clients + staff + parfois TV/casting.
- Salles de réunion / événementiel : pointes fortes et exigences élevées (visioconférence, partage d’écran, streaming).
- Back-office / staff : outils métier, téléphonie/softphones, stabilité en journée.
Ce cadrage complète naturellement une étude radio Wi‑Fi (site survey) : la couverture “carte de chaleur” ne suffit pas si la charge n’est pas définie.
2) Figer le périmètre technique (pour des tests reproductibles)
- Liste des AP par zone (nom, emplacement, VLAN/SSID servis).
- Chemin LAN (switch d’accès, uplink(s), cœur, pare-feu) pour savoir où un goulot peut apparaître.
- Paramètres Wi‑Fi majeurs : SSID, sécurité, bands activées, canaux/puissances (attention aux mécanismes d’auto-optimisation qui changent la radio pendant la recette).
Si vous êtes en phase de conception, ce travail s’inscrit dans la démarche décrite dans Wi‑Fi hôtelier et Wi‑Fi professionnel : capacité radio et infrastructure filaire doivent être dimensionnées ensemble.
Définir des KPI (sans inventer des “seuils universels”)
Les KPI doivent être liés à une décision. Un KPI utile n’est pas “un beau débit”, c’est un indicateur qui vous permet de décider : ajout d’AP, changement de plan radio, renforcement d’uplink, segmentation, ajustement de QoS, etc.
Plutôt que d’imposer des chiffres identiques à tous les projets, utilisez une matrice simple par zone :
| KPI | Mesure (comment) | Lecture “actionnable” |
|---|---|---|
| Débit utile (TCP) | iperf3 en TCP, itérations répétées | Plafond LAN/uplink si ça sature “trop tôt” malgré une bonne radio |
| Pertes / jitter (UDP) | iperf3 en UDP à débit cible progressif | Dégradation radio (airtime/réessais/interférences) ou queues saturées |
| Latence RTT (idle vs charge) | ping continu vers cible LAN puis WAN pendant un test charge | Buffering/saturation : si le RTT “explose” sous charge, le réseau est fragile |
| Stabilité multi-clients | plusieurs clients simultanés, trafic mixte | Capacité radio insuffisante si la zone s’effondre dès que la densité monte |
| Roaming | ping + flux léger en mouvement + appel réel | Design radio/paramétrage roaming à revoir si coupures répétées |
Outillage minimal (terrain) : simple, mais robuste
iperf3 (débit TCP et tests UDP)
iperf3 est un outil courant pour générer et mesurer du trafic. Il permet notamment :
- le mode UDP (
-u) ; - un débit cible en UDP (
-b) ; - plusieurs flux parallèles en TCP (
-P).
Ces options sont documentées dans des manpages (ex. iperf3(1)) et guides de référence. (manpage iperf3)
Ping continu (latence, dérive sous charge)
Un ping “OK” ne garantit pas une bonne expérience, mais un ping qui se dégrade sous charge est un signal très utile. L’idée est de pinguer plusieurs cibles :
- la passerelle du VLAN (cible LAN très proche),
- un serveur interne (si disponible),
- puis une cible Internet (pour distinguer LAN vs WAN).
Test voix/visioconférence en conditions réelles
Le protocole doit inclure au moins un test applicatif (Teams/Zoom/softphone/VoWiFi selon le site). Le but n’est pas de “mesurer pour mesurer”, mais de valider le ressenti sur un scénario métier (ex. appel en déplacement entre réception et back-office, ou entre deux salles).
Pourquoi il faut parler roaming “côté clients”
Le roaming n’est pas seulement une décision de l’infrastructure : le terminal garde une part importante du contrôle. Sur les appareils Apple, la documentation de déploiement indique notamment la prise en charge de 802.11k/802.11r/802.11v et rappelle que l’absence de mécanismes d’aide (comme le Neighbour Report 802.11k) peut obliger l’appareil à scanner plus largement. (Apple — Wi‑Fi roaming support)
Protocole de tests en 6 étapes (capacité + voix + roaming)
Les étapes ci-dessous forment une “recette” reproductible. Elles peuvent être réalisées sur un hôtel comme sur des bureaux, en adaptant simplement la sélection des zones et le niveau de charge.
Étape A — Baseline “1 client, réseau calme” (par zone)
Objectif : vérifier que la chaîne complète (radio + LAN + cœur + pare-feu) est saine avant de parler densité.
- TCP download / upload (plusieurs itérations).
- UDP à débit progressif (pour observer pertes/jitter).
Exemples iperf3 (à adapter au plan IP) :
# TCP (plusieurs flux)
iperf3 -c <IP_SERVEUR> -t 20 -P 4
# UDP (débit cible)
iperf3 -c <IP_SERVEUR> -u -b 50M -t 20
Étape B — Multi-clients “sur une même zone”
Objectif : identifier le point de bascule lorsque plusieurs clients actifs partagent la même ressource radio.
- Constituer un groupe de clients (PC/smartphones) réellement représentatif.
- Lancer des sessions iperf3 en parallèle.
- En parallèle, faire tourner un ping continu pour voir la latence sous charge.
Lecture : si la latence (RTT) grimpe fortement déjà vers la passerelle LAN, la saturation est proche de l’accès (radio ou uplink d’accès). Si elle grimpe surtout vers Internet, le WAN/pare-feu est suspect.
Étape C — “Zone dense” (plusieurs AP, trafic mixte)
Objectif : simuler un lobby, un restaurant, une salle de réunion : plusieurs AP couvrent la même zone et les clients doivent se répartir “naturellement”.
- Répartir physiquement les clients (pas tous au même endroit).
- Mélanger TCP (usage “data”) et UDP (flux sensibles).
- Observer si un AP devient “hotspot” saturé alors que d’autres sont peu chargés.
Étape D — Test latence “sous charge” (le test qui révèle souvent les uplinks)
Objectif : différencier manque de capacité radio vs goulot LAN/uplink/pare-feu.
- Lancer un ping continu (LAN puis WAN).
- Injecter une charge progressive avec iperf3.
- Comparer la dérive de latence et la stabilité (pics, pertes).
Étape E — Roaming “data” (trajet réaliste)
Objectif : mesurer les interruptions lors d’un passage d’AP à AP sur un trajet réel (couloir → chambre, accueil → bureaux, open space → salle).
- Ping continu (intervalle court) vers une cible LAN.
- Petit flux UDP.
- Déplacement contrôlé (plusieurs passages) pour vérifier la répétabilité.
Étape F — Roaming “voix” (ce que l’utilisateur ressent)
Objectif : valider la continuité d’un appel en déplacement. C’est ici que la recette devient “métier”.
- Appel réel (softphone / VoWiFi / Teams audio) + trajet identique à l’étape E.
- Noter : coupures audio, “robotisation”, déconnexions, nécessité de rappeler.
Interpréter les résultats : diagnostiquer radio vs LAN (et décider)
Symptôme : “bon à 1 client, mauvais en multi-clients”
Hypothèse dominante : saturation radio (airtime, réessais, plan de canaux/puisances, taille de cellule). Décision typique : revoir le design radio (souvent plus d’AP, cellules mieux contenues, planification mieux maîtrisée) plutôt que “changer la box”.
Ce diagnostic s’inscrit dans la logique d’une étude radio Wi‑Fi : capacité et roaming sont des objectifs de conception, pas des “effets secondaires” de la couverture.
Symptôme : “débit plafonné” + “latence qui gonfle sous charge”
Hypothèse dominante : goulot LAN/uplink/pare-feu (ou WAN). Décision typique : audit d’uplinks et de distribution, PoE, cœur réseau, et mise en place de supervision.
En hôtel, cette lecture doit être cohérente avec l’infrastructure globale : architecture réseau IP d’un hôtel (cohabitation Wi‑Fi, VoIP, IPTV, CCTV, GRMS).
Symptôme : “roaming instable” / “appels qui décrochent”
Hypothèse dominante : combinaison de design radio (cellules, recouvrement) + choix de mécanismes d’aide au roaming. La documentation Apple mentionne la prise en charge de 802.11k/802.11r/802.11v sur plusieurs appareils et rappelle l’intérêt des informations de voisinage pour réduire la charge de scan côté client. (Apple — Wi‑Fi roaming support)
Point de vigilance : 802.11r peut améliorer… ou casser des clients
Activer 802.11r n’est pas une “case à cocher” sans recette. Cisco indique que certains clients anciens peuvent ne pas s’associer à un SSID où 802.11r est activé, même en mode mixte, ce qui amène parfois à séparer les SSID ou à utiliser des modes adaptés selon parc clients. (Cisco — 802.11r (compatibilité clients))
Conclusion pratique : dans un hôtel, on teste toujours l’activation (ou non) des mécanismes de roaming avec un panel représentatif de terminaux clients avant généralisation.
Point de vigilance : 802.11v est une “suggestion” au client
802.11v peut aider l’infrastructure à proposer des candidats de roaming, mais Cisco rappelle qu’une requête de transition BSS est une suggestion que le client peut suivre… ou ignorer. (Cisco — 802.11v (BSS Transition))
Voix et “jitter” : comprendre ce qu’on mesure
Dans un rapport, il est utile de distinguer :
- jitter applicatif/voix (souvent RTP) : la RFC 3550 définit le jitter d’inter-arrivée comme une moyenne lissée de la variation d’espacement des paquets. (IETF RFC 3550)
- jitter mesuré par iperf3 en UDP : très utile pour comparer des scénarios, mais ce n’est pas exactement la même chose qu’une métrique de qualité audio “de bout en bout”.
Pour décider, l’approche la plus robuste reste : métriques réseau + test voix réel (en mouvement si nécessaire).
Modèle de rapport de recette (format simple à copier-coller)
Contexte
- Site, zones testées, date/heure, conditions (occupation réelle, événements).
- Inventaire AP/contrôleur (modèles/versions), switches, uplinks, PoE (synthèse).
- SSID/VLAN concernés, options roaming (si pertinentes), politiques particulières.
Hypothèses de charge
- Scénarios par zone : simultanéité visée, profils de trafic (data/vidéo/voix).
- Terminaux utilisés (type + OS) : l’acceptation roaming dépend aussi du client.
Résultats (table de synthèse)
| Zone | SSID | Baseline (1 client) | Sous charge (multi-clients) | Latence (idle vs charge) | Roaming (data/voix) | Conclusion |
|---|---|---|---|---|---|---|
| Lobby | Invités | OK / À préciser | OK / Limite observée | Stable / Dégrade | OK / À corriger | Radio / LAN / mix |
Plan de remédiation (lié aux symptômes)
- Actions radio : ajustements (canaux/puissances), repositionnement, AP additionnels, stratégie de cellules.
- Actions LAN : uplinks, switching, PoE, chemins critiques, segmentation, élimination d’un goulot identifié.
- Actions exploitation : supervision, alertes utiles, re-tests périodiques.
Sur l’aspect exploitation/indicateurs, voir aussi : Supervision réseau : quels équipements et indicateurs faut‑il réellement surveiller ?
Où ce protocole s’insère dans une démarche Domocasa
- Avant : conception et site survey Wi‑Fi (couverture + capacité + interférences + roaming).
- Pendant : recette capacité (ce protocole) + tests roaming voix dans les zones où c’est un usage réel.
- Après : remédiation ciblée (radio, LAN, uplinks, PoE) et re-recette sur les mêmes scénarios, pour prouver l’amélioration.
Besoin d’une recette “capacité” sur site (hôtel ou bureaux) ?
Si vos utilisateurs se plaignent surtout aux heures de pointe, dans les zones denses ou en déplacement, une recette orientée capacité permet généralement d’identifier rapidement si la limite vient de la radio, du LAN/uplink, ou d’une combinaison des deux. Pour cadrer une intervention (site survey, protocole de recette, remédiation et re-tests), vous pouvez aussi vous appuyer sur nos guides Wi‑Fi hôtelier et Wi‑Fi professionnel.
