Publié le 12 mars 2026
Dans un entrepôt, un terminal qui perd sa session pendant 3 secondes peut provoquer un scan erroné, une validation de picking ratée ou un blocage de chariot. Le roaming Wi-Fi est la première cause de ces micro-coupures — et rarement la plus visible. Voici notre méthode pour le diagnostiquer et le corriger.
Le roaming, c'est le moment où un terminal mobile (scanner, tablette durcie, chariot avec écran embarqué) change de borne Wi-Fi en se déplaçant. En théorie, c'est transparent. En pratique, dans un entrepôt de 5 000 m² avec des racks métalliques de 10 mètres de haut, c'est souvent là que tout se complique.
Le processus se décompose en trois phases :
L'objectif dans un contexte logistique : que la totalité de ce processus prenne moins de 50 ms. Au-delà, les applications métier (WMS, picking vocal, scan en temps réel) risquent des timeouts applicatifs.
En intervention terrain, on constate que les équipes IT décrivent rarement le problème comme un "souci de roaming". Voici les symptômes remontés les plus fréquents, et ce qu'ils indiquent :
| Symptôme remonté | Cause probable liée au roaming |
|---|---|
| "Les scanners se déconnectent dans l'allée 7" | Zone de recouvrement insuffisant entre deux AP → le terminal reste accroché trop longtemps à une borne faible |
| "Le picking vocal coupe en bout de rack" | Roaming trop lent (>150 ms) → perte de session VoIP/SIP |
| "Ça marche bien le matin, plus l'après-midi" | Interférences co-canal qui augmentent avec l'activité → SNR dégradé, le terminal hésite à roamer |
| "Les chariots perdent la connexion en changeant de zone" | Seuil RSSI de roaming trop bas côté terminal → il reste sur l'AP d'origine jusqu'à perdre le signal |
| "Il faut éteindre/rallumer le terminal pour que ça remarche" | Sticky client : le terminal ne roame plus du tout, accroché à un AP injoignable |
On ne diagnostique pas un problème de roaming depuis un bureau. Il faut aller sur site, avec les bons outils, et reproduire les conditions réelles d'exploitation.
On parcourt l'intégralité de la zone avec Ekahau Pro pour produire des heatmaps de couverture. Ce qu'on cherche spécifiquement :
Avec une capture Wi-Fi (Ekahau ou Wireshark en monitor mode), on trace les handovers des terminaux pendant une tournée réelle. On mesure :
Les logs du contrôleur Wi-Fi (FortiWLC, Aruba Mobility Controller, Ruckus SmartZone…) permettent de confirmer ce qu'on observe côté air :
C'est le paramètre le plus impactant et le moins bien compris. Deux seuils entrent en jeu :
| Seuil | Où il se configure | Valeur recommandée (logistique) |
|---|---|---|
| Min RSSI / Probe Suppression | Côté AP / contrôleur | -70 à -75 dBm |
| Roaming aggressiveness / trigger | Côté terminal (driver Wi-Fi) | -65 à -70 dBm |
On voit souvent des contrôleurs configurés avec un seuil RSSI minimum à -95 dBm (la valeur par défaut sur FortiGate/FortiAP). À ce niveau, le contrôleur ne déconnecte jamais un client, même quand il ne reçoit pratiquement plus rien. Résultat : le terminal reste collé à un AP fantôme au lieu de roamer vers le plus proche.
Notre recommandation : -70 à -75 dBm côté contrôleur, combiné avec un réglage agressif côté terminal.
L'idée est de créer une "pression" des deux côtés : le contrôleur pousse le client à partir (en cessant de lui répondre sous un certain seuil), et le terminal est configuré pour chercher activement une meilleure borne dès que le signal se dégrade.
Ces trois amendements au standard Wi-Fi existent précisément pour améliorer le roaming. Mais leur impact réel dépend énormément du contexte.
Pré-négocie les clés de chiffrement avec la borne cible avant le roaming. Élimine le round-trip RADIUS lors du handover. Impact majeur en WPA2/WPA3-Enterprise. Attention : certains anciens terminaux durcis (Android 7 et en dessous, vieux Zebra/Honeywell) ne supportent pas le 802.11r et refusent de s'associer si c'est activé. Il faut tester la compatibilité avant de l'activer en production.
L'AP envoie au terminal la liste de ses voisins avec leurs canaux. Le terminal peut alors scanner uniquement ces canaux au lieu de balayer toute la bande. Réduit le temps de scanning de 200+ ms à 20-40 ms. Très utile, peu de contre-indications.
Permet au contrôleur de suggérer au terminal de roamer vers une borne précise (via un BTM Request). Utile pour le load balancing et pour éviter les sticky clients. Mais c'est une suggestion : le terminal peut l'ignorer, et certains le font systématiquement.
L'activation combinée de 802.11k + 802.11r est le duo le plus efficace qu'on constate sur le terrain en environnement logistique. Le 802.11v est un bonus appréciable quand les terminaux le supportent correctement, mais il ne remplace jamais une bonne conception radio de base.
Erreur n°1 — Trop de puissance d'émission sur les AP. Intuitivement, on pense qu'"émettre plus fort = mieux couvrir". En réalité, un AP qui émet à pleine puissance couvre une zone trop large. Le terminal le "voit" de loin mais n'a pas la puissance pour lui répondre (asymétrie de liaison). Résultat : il reste accroché à cet AP distant au lieu de roamer vers le plus proche.
Erreur n°2 — Canal bonding en 5 GHz sans analyse préalable. En 80 MHz, on n'a que 5 ou 6 canaux disponibles (moins avec DFS). Dans un entrepôt dense en AP, ça génère du co-canal massif. Mieux vaut souvent rester en 20 ou 40 MHz et avoir des canaux propres.
Erreur n°3 — DARRP / ARM activé sans supervision. Les fonctions d'auto-optimisation radio (DARRP chez Fortinet, ARM chez Aruba) peuvent réattribuer les canaux et les puissances de manière imprévisible. Elles sont conçues pour des bureaux, pas pour des entrepôts où le plan radio a été pensé en fonction de la géométrie des racks.
Erreur n°4 — Ignorer le profil Wi-Fi du terminal. Chaque modèle de terminal durci (Zebra TC52/TC72, Honeywell CT60, Datalogic Memor…) a ses propres comportements de roaming et ses drivers Wi-Fi avec des paramètres spécifiques. Ne pas les configurer, c'est laisser le terminal décider seul quand et comment roamer — souvent mal.
Erreur n°5 — Désactiver les bandes 2,4 GHz "pour simplifier". Certains équipements IoT (capteurs, imprimantes d'étiquettes) ne fonctionnent qu'en 2,4 GHz. Les supprimer crée des problèmes de connectivité qu'on attribue ensuite au roaming alors que c'est simplement de la couverture manquante.
Avant d'appeler un prestataire, vous pouvez déjà vérifier ces points :
N0ctua IT intervient en entrepôt, usine et site logistique partout en France. Audit Ekahau, diagnostic terrain, recommandations concrètes et accompagnement à la mise en œuvre.
Demander un diagnostic