Coupures Wi‑Fi aléatoires : le réglage d’itinérance que Windows cache

Ce qu’est réellement l’itinérance (et pourquoi ça ressemble à une coupure)

L’itinérance, c’est le client qui décide : « Je suis actuellement associé à l’AP A ; l’AP B pourrait être mieux ; je vais changer. »
En termes Wi‑Fi, cela signifie une réassociation (et souvent une poignée de main de clé) qui peut prendre de quelques dizaines à plusieurs centaines de millisecondes.
Si c’est propre et rapide, vous le remarquez à peine. Si c’est bordélique, vos applications voient des pertes de paquets, des blocages TCP et le VPN qui renégocie.

Les « coupures aléatoires » sont souvent simplement une mauvaise itinérance. Ça ressemble à une déconnexion parce que vos applications ne tiennent pas compte des
détails Wi‑Fi : elles se préoccupent du fait que la socket a cessé d’échanger des données. VoIP, visioconférence, RDP et VPN sont les premiers à se plaindre.

Voici la partie inconfortable : les décisions d’itinérance sont majoritairement prises côté client. Votre point d’accès peut encourager, pousser ou contraindre (plus loin dans l’article),
mais la pile Wi‑Fi de Windows et le pilote décident en fin de compte quand lâcher le BSSID courant pour en adopter un autre.

Vous pouvez avoir une excellente couverture et malgré tout une mauvaise itinérance. Vous pouvez avoir un signal fort et quand même vous faire expulser.
Un système maillé peut « aider » en vous forçant entre les bandes, tandis que Windows interprète le monde via le RSSI, le SNR, les taux de retry,
les résultats de scan et des heuristiques de pilote.

Le réglage Windows qui compte : Agressivité d’itinérance

Dans de nombreux pilotes d’adaptateurs Wi‑Fi (particulièrement Intel, mais pas uniquement), il existe une propriété avancée souvent appelée
Agressivité d’itinérance. Windows ne l’affiche pas dans un écran convivial « Réseau et Internet ».
Elle est enfouie dans les propriétés du pilote de l’adaptateur, et la formulation exacte varie selon le vendeur.

Ce que ça fait : cela déplace le seuil d’itinérance. Une agressivité plus élevée signifie que le client scanne davantage et migre plus tôt,
souvent vers un signal « meilleur ». Une agressivité plus faible favorise le comportement « plus collant »—rester en place à moins que l’AP actuel devienne clairement mauvais.

L’astuce, c’est que « meilleur signal » n’est pas la même chose que « meilleure expérience ». Un AP proche peut avoir un RSSI fort et être
surchargé, mal configuré ou sur un canal bruyant. Inversement, un AP légèrement plus faible peut fournir un lien bien plus stable avec moins de retries.

Si votre symptôme est des « coupures » périodiques alors que vous ne bougez pas (ou à peine), une itinérance trop agressive est un suspect de choix.
Windows peut décider d’itinérer parce qu’il voit un candidat marginalement meilleur, déclenche une réassociation, et vos applications temps‑réel interprètent cela
comme « Internet a planté ».

Que faire, en général :

• Si vous êtes dans un environnement stable (bureau à domicile, poste fixe, un seul point d’accès à proximité) : réglez l’agressivité d’itinérance plus bas.
• Si vous êtes vraiment mobile (entrepôt, hôpital, campus) et que vous avez des AP d’entreprise conçus pour cela : vous pouvez préférer moyen.
• Ne mettez pas au maximum juste parce que « l’itinérance semble bien ». Ce n’est pas un objectif de performance.

Blague n°1 : L’itinérance Wi‑Fi, c’est comme le bureau partagé—super en théorie, chaotique quand tout le monde change de place en plein meeting.

Pourquoi les « coupures aléatoires » arrivent : les véritables modes de panne

1) Une itinérance trop agressive provoque des micro‑pannes

Si le pilote scanne et itère trop souvent, la qualité de connexion devient une dent de scie. Un peu de perte de paquets devient un recul TCP.
Un petit retard devient « Teams se reconnecte ». L’interface Windows peut afficher une déconnexion, ou elle peut simplement garder le SSID affiché pendant
que vos applications expirent.

2) L’économie d’énergie vous ment

Windows et la gestion d’alimentation du pilote peuvent mettre la carte réseau dans des états basse consommation, réduire la puissance d’émission ou augmenter le sommeil.
Sur batterie, c’est plus agressif. Le résultat peut ressembler à des « coupures aléatoires », surtout avec un faible débit (applications de chat inactives)
puis une demande temps‑réel soudaine (un appel démarre).

3) Le band steering et le « smart connect » font tourner les clients

Les systèmes maillés grand public utilisent souvent le band steering : le même SSID pour 2,4 GHz et 5 GHz (et parfois 6 GHz), avec le système qui tente
de pousser les clients vers des bandes « meilleures ». Ça peut fonctionner—jusqu’à ce que non. Si l’AP est trop insistant (ou bogué), vous obtenez de multiples deauths,
des réassociations ratées et un utilisateur qui pense que son FAI le déteste personnellement.

4) Bugs de pilote et fonctionnalités « avancées »

Des fonctionnalités comme U-APSD, « Throughput Booster », « Preferred Band », « MIMO power save » et l’assistance d’itinérance du fournisseur peuvent interagir mal
avec certains firmware d’AP. La pire catégorie de bug est celle qui ne se reproduit que le mardi à 10:03 pendant un appel.
Mais les logs ne mentent pas ; il faut juste récupérer les bons.

5) Sécurité et latence des handshakes

L’authentification WPA2-Enterprise (802.1X) peut être rapide si votre environnement est optimisé (PMK caching, OKC, 802.11r où supporté).
Elle peut aussi être un désastre au ralenti si le chemin RADIUS est lent, si les certificats sont mal gérés, ou si le client est forcé de refaire une full reauth trop souvent.

6) Clients « collants » : le problème inverse

Parfois la « coupure » est en réalité le client qui refuse d’itinérer quand il le devrait, s’accrochant à un AP en train de mourir jusqu’à ce que le lien s’effondre.
Ensuite il finit par migrer, tardivement, et votre application parle de déconnexion. Réduire trop l’agressivité peut aggraver cela en environnements très mobiles.
C’est pourquoi vous diagnostiquez d’abord et ajustez ensuite.

7) Renouvellements DHCP et problèmes de couche IP qui se déguisent en Wi‑Fi

Une itinérance peut déclencher un bref changement de connectivité qui expose une configuration DHCP faible, une passerelle instable ou un VPN qui ne tolère pas
les transitions d’interface. Le lien Wi‑Fi peut être sain ; c’est la pile IP qui fait face.

Mode d’urgence pour diagnostiquer vite (premier/deuxième/troisième)

Quand un utilisateur dit « le Wi‑Fi coupe », vous ne commencez pas par réinstaller les pilotes comme si nous étions en 2009. Vous faites du triage comme un SRE :
confirmez le symptôme, restreignez la couche, puis changez une variable à la fois.

Premier : prouvez si c’est une coupure/reconnect au lien Wi‑Fi (itinérance) vs IP/VPN/app

• Générez le rapport WLAN de Windows et consultez les logs de l’Event Viewer. Cherchez Roaming, disconnected, deauth, reason codes.
• Corrélez les horodatages avec les signalements utilisateurs et les logs VPN.
• Si le BSSID change à l’horodatage de la « coupure », vous êtes en itinérance. Si ce n’est pas le cas, suspectez l’économie d’énergie, les retries RF ou la couche supérieure.

Second : vérifiez la qualité du signal et le comportement des retries au moment de la douleur

• Vérifiez le pourcentage de signal RSSI, les débits Tx/Rx et le canal.
• Recherchez une forte utilisation du canal ou des signes évidents d’interférence co‑canal (débits qui s’effondrent, tentatives répétées d’itinérance).

Troisième : isolez le déclencheur avec des changements contrôlés

• Réglez l’agressivité d’itinérance d’un cran en dessous (pas « le plus bas pour toujours », juste un cran). Testez.
• Désactivez la gestion d’alimentation de l’adaptateur pour la fenêtre de test. Testez.
• Si vous êtes sur un maillage avec band steering, testez en séparant temporairement les SSID (2.4 vs 5). Testez.
• En entreprise : testez 802.11r on/off, validez la latence RADIUS et assurez le comportement PMK caching.

Tâches pratiques : commandes, sorties et décisions

Voici les tâches que j’exécute réellement quand un portable Windows « coupe aléatoirement ». Chaque tâche inclut une commande réaliste,
une sortie d’exemple, ce que ça signifie et la décision à prendre. Exécutez-les dans un terminal élevé quand nécessaire.

Task 1: Generate a WLAN report (roams, disconnects, reason codes)

cr0x@server:~$ netsh wlan show wlanreport
WLAN report was written to: C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html

Ce que ça signifie : Windows a créé un rapport HTML avec la chronologie des connexions, les raisons des déconnexions et les infos de l’adaptateur.
Décision : Ouvrez le rapport et recherchez des déconnexions/itinérances répétées aux mêmes intervalles. Si vous voyez « Reason: The network is disconnected by the driver »
ou beaucoup d’événements d’itinérance, vous êtes dans le domaine pilote/itinérance, pas « panne FAI ».

Task 2: Dump interface state (BSSID, channel, rates)

cr0x@server:~$ netsh wlan show interfaces
There is 1 interface on the system:

    Name                   : Wi-Fi
    Description            : Intel(R) Wi-Fi 6 AX201 160MHz
    GUID                   : 2c3a6b2d-1f45-4a8b-9c0a-0f1b1c0d1234
    Physical address       : 34:ab:cd:ef:12:34
    State                  : connected
    SSID                   : CorpNet
    BSSID                  : a0:bb:cc:dd:ee:f0
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA2-Enterprise
    Connection mode        : Profile
    Channel                : 36
    Receive rate (Mbps)    : 866.7
    Transmit rate (Mbps)   : 780.0
    Signal                 : 72%
    Profile                : CorpNet

Ce que ça signifie : Vous avez l’AP courant (BSSID), la bande (canal) et les débits du lien.
Décision : Lors de la prochaine « coupure », exécutez ceci à nouveau. Si le BSSID change, c’est une itinérance. Si les débits s’effondrent avant la coupure,
suspectez l’interférence RF ou l’économie d’énergie. Si le signal est fort mais les performances mauvaises, suspectez la contention ou des bugs de steering.

Task 3: See saved profiles and confirm you’re not connecting to the wrong SSID variant

cr0x@server:~$ netsh wlan show profiles
Profiles on interface Wi-Fi:

Group policy profiles (read only)
---------------------------------
    <None>

User profiles
-------------
    All User Profile     : CorpNet
    All User Profile     : CorpNet-Guest
    All User Profile     : CorpNet_24G

Ce que ça signifie : Plusieurs profils similaires existent.
Décision : Si vous voyez à la fois « CorpNet » et « CorpNet_24G/5G », décidez si vous voulez une sélection explicite de la bande pour les tests.
Si un SSID invité est mémorisé et l’auto‑connexion activée, il peut vous « itérer » vers le mauvais réseau sur le parking.

Task 4: Verify the current driver and version (driver bugs are real)

cr0x@server:~$ pnputil /enum-drivers | findstr /i wifi
Published Name : oem42.inf
Original Name  : Netwtw10.inf
Provider Name  : Intel
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 23.30.0.6
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Ce que ça signifie : Vous pouvez identifier l’INF vendeur et la version.
Décision : Si vous êtes sur un pilote connu pour poser problème pour votre parc, standardisez sur une version testée.
Ne faites pas un « mettre à jour vers la dernière version » aveugle si votre environnement est sensible ; testez d’abord.

Task 5: Inspect power management capabilities and active plan (battery behavior matters)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Ce que ça signifie : Vous êtes sur Balanced, qui tend à activer une économie d’énergie plus agressive.
Décision : Pour le dépannage, basculez temporairement sur Hautes performances ou réglez les paramètres adaptateur sans fil sur Maximum Performance.
Si le problème disparaît sur secteur mais apparaît sur batterie, vous avez une interaction politique d’alimentation/pilote.

Task 6: Check per-adapter power setting (wireless adapter power saving mode)

cr0x@server:~$ powercfg /q 381b4222-f694-41f0-9685-ff5bb260df2e 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 12bbebe6-58d6-4636-95bb-3217ef867c1a | findstr /i "Current AC Power Setting Index"
Current AC Power Setting Index: 0x00000002

Ce que ça signifie : L’index numérique correspond au mode d’économie d’énergie de l’adaptateur sans fil (varie selon la build/pilote), où un nombre plus élevé signifie souvent plus d’économie.
Décision : Si vous recherchez la stabilité, réglez-le sur performance maximale pour AC et DC pendant le diagnostic.
Si cela corrige le problème, vous pourrez ensuite ajuster vers un réglage moins agressif plutôt que de vivre en mode consommation maximale.

Task 7: Pull WLAN AutoConfig events (the truth is in the timestamps)

cr0x@server:~$ wevtutil qe Microsoft-Windows-WLAN-AutoConfig/Operational /c:10 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8001
  Level: Information
  Description:
    WLAN AutoConfig service has successfully connected to a wireless network.

Event[1]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8003
  Level: Warning
  Description:
    WLAN AutoConfig service has disconnected from a wireless network.
    Reason: The network is disconnected by the driver.

Ce que ça signifie : Vous pouvez voir les événements de connexion/déconnexion et les raisons sans deviner.
Décision : « Disconnected by the driver » pointe vers le pilote/firmware/gestion d’alimentation/comportement d’itinérance.
Si vous voyez « Explicit EAP failure », vous êtes dans le domaine 802.1X/RADIUS.

Task 8: Compare IP-layer continuity (is Wi‑Fi dropping, or is IP breaking?)

cr0x@server:~$ ipconfig /all
Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201 160MHz
   Physical Address. . . . . . . . : 34-AB-CD-EF-12-34
   DHCP Enabled. . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . : 10.44.12.87(Preferred)
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . : Monday, 10:12:01 AM
   Lease Expires . . . . . . . . . : Monday, 06:12:01 PM
   Default Gateway . . . . . . . . : 10.44.12.1
   DNS Servers . . . . . . . . . . : 10.44.0.10
                                       10.44.0.11

Ce que ça signifie : Vous confirmez DHCP, temps de bail, passerelle, DNS.
Décision : Si les « coupures » coïncident avec un renouvellement DHCP ou une passerelle qui change, vous pouvez voir un flux IP plutôt qu’une itinérance Wi‑Fi.
Si l’IP reste stable mais que les applications tombent, examinez l’itinérance/l’économie d’énergie/le comportement VPN.

Task 9: Continuous ping to detect micro-outages (measure, don’t vibe-check)

cr0x@server:~$ ping -n 50 10.44.12.1
Pinging 10.44.12.1 with 32 bytes of data:
Reply from 10.44.12.1: bytes=32 time=3ms TTL=64
Reply from 10.44.12.1: bytes=32 time=4ms TTL=64
Request timed out.
Request timed out.
Reply from 10.44.12.1: bytes=32 time=5ms TTL=64

Ping statistics for 10.44.12.1:
    Packets: Sent = 50, Received = 48, Lost = 2 (4% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 48ms, Average = 6ms

Ce que ça signifie : Vous observez de brèves pointes de perte de paquets—classique d’une itinérance ou d’un comportement de retry RF.
Décision : Si la perte survient en rafales de 1–3 secondes et s’aligne avec les logs d’événements, suspectez l’itinérance.
Si c’est une perte soutenue sans événements d’itinérance, suspectez la congestion RF/l’instabilité de l’AP.

Task 10: Trace route to see if the “drop” is upstream

cr0x@server:~$ tracert -d 8.8.8.8
Tracing route to 8.8.8.8 over a maximum of 30 hops

  1     3 ms     2 ms     3 ms  10.44.12.1
  2     6 ms     5 ms     6 ms  10.44.0.1
  3    12 ms    11 ms    13 ms  192.0.2.10
  4    14 ms    13 ms    14 ms  203.0.113.22
  5    16 ms    15 ms    16 ms  8.8.8.8

Trace complete.

Ce que ça signifie : Chemin de routage de référence. Lors d’une « coupure », cela peut échouer ou changer.
Décision : Si le saut 1 (passerelle) échoue pendant les coupures, c’est local Wi‑Fi/LAN. Si le saut 1 est OK mais que des sauts ultérieurs échouent,
vous traitez un problème WAN/VPN/politique en amont.

Task 11: Check for VPN interface flaps (VPN can amplify roaming pain)

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
-------------------------------------------------------------------------
Enabled        Connected      Dedicated        Ethernet
Enabled        Connected      Dedicated        Wi-Fi
Enabled        Disconnected   Dedicated        MyCorp VPN

Ce que ça signifie : L’état de l’interface VPN est visible et peut osciller lors des transitions Wi‑Fi.
Décision : Si le VPN se reconnecte exactement au moment où le Wi‑Fi itère, examinez les politiques de split tunneling, les paramètres du client VPN,
et si le VPN peut tolérer de courtes interruptions d’interface. Parfois la solution est « accélérer l’itinérance », pas « désactiver l’itinérance ».

Task 12: Validate Wi‑Fi capabilities reported by the driver (802.11r/ax weirdness starts here)

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 1/12/2025
    Version                   : 23.30.0.6
    Radio types supported     : 802.11b 802.11g 802.11n 802.11ac 802.11ax
    FIPS 140-2 mode supported : Yes
    802.11w Management Frame Protection supported : Yes
    Hosted network supported  : No
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

Ce que ça signifie : Le pilote annonce les standards et fonctionnalités de sécurité supportés.
Décision : Si votre réseau utilise 802.11w ou des standards plus récents, confirmez que le client les supporte.
Les incompatibilités peuvent provoquer des boucles de deauth ou des schémas « connexion puis chute ».

Task 13: Disable and re-enable the adapter to clear a stuck state (surgical, not superstitious)

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled
Ok.

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=enabled
Ok.

Ce que ça signifie : Vous réinitialisez l’interface sans redémarrer.
Décision : Si cela « règle le problème pendant un moment », c’est souvent une fuite pilote/firmware ou un état de machine d’itinérance coincé.
Utilisez ceci comme un indice diagnostique—pas comme un mode de vie.

Task 14: Check for “sticky” DNS problems after a roam (apps say Wi‑Fi dropped, DNS says otherwise)

cr0x@server:~$ nslookup internal-service
Server:  10.44.0.10
Address: 10.44.0.10

Name:    internal-service.corp.example
Address: 10.44.20.15

Ce que ça signifie : La résolution DNS fonctionne maintenant.
Décision : Si le Wi‑Fi « coupe » mais que le ping vers la passerelle fonctionne pendant que la résolution DNS échoue, votre problème est la résolution de noms,
l’interception par portail captif ou une politique split‑DNS/VPN—pas l’agressivité d’itinérance.

Les leviers Windows qui contrôlent la stabilité (et ceux à éviter)

Où se trouve l’Agressivité d’itinérance

Généralement : Gestionnaire de périphériques → Cartes réseau → votre adaptateur Wi‑Fi → Propriétés → Onglet Avancé → Agressivité d’itinérance.
Parfois on l’appelle « Roaming Sensitivity », « Roaming Decision » ou « Roam Tendency ».
Si vous ne la voyez pas, votre pilote peut ne pas l’exposer, ou votre OEM l’a peut‑être cachée derrière un package personnalisé.

Mon conseil opérationnel : commencez un cran en dessous de la valeur par défaut. Testez une journée. Si cela améliore la stabilité sans provoquer « je perds le Wi‑Fi quand je vais en salle de réunion », conservez-le.
Si cela provoque un comportement de client collant, remontez d’un cran.

Preferred Band : utile, mais dangereux comme béquille permanente

Réglage du « Preferred Band » sur 5 GHz peut réduire les problèmes d’interférence du 2.4 GHz, qui est essentiellement un parc public où tout le monde crie.
Mais si votre couverture 5 GHz est irrégulière, vous déclencherez plus d’itinérances et de liens marginaux.

Utilisez Preferred Band comme un interrupteur de dépannage. Si forcer le 5 GHz corrige les coupures, cela suggère que votre environnement 2.4 GHz est encombré ou que le band steering de l’AP est cassé.
Ensuite corrigez le réseau. Ne collez pas chaque portable sur le 5 GHz et ne prétendez pas avoir « optimisé ».

Puissance d’émission : ne l’augmentez pas sans réfléchir

Augmenter la puissance d’émission peut rendre votre client « plus fort », mais cela n’améliore pas la capacité de l’AP à vous entendre si la puissance et la sensibilité de l’AP ne correspondent pas.
Vous pouvez créer des liens asymétriques : le client entend l’AP correctement ; l’AP n’entend pas le client de façon fiable. Cela produit des retries, des chutes de débit et l’illusion de « déconnexions aléatoires ».

Gestion d’alimentation : la case qui gâte votre après‑midi

Le classique : « Autoriser l’ordinateur à éteindre ce périphérique pour économiser de l’énergie. » Ce n’est pas toujours la cause directe, mais cela peut amplifier les problèmes de pilote.
Pour le dépannage, désactivez-la. Si la stabilité s’améliore, vous pouvez ensuite décider si l’autonomie importe plus que ne pas couper pendant les appels.

Mode 802.11ax et fonctionnalités « Throughput Booster »

Parfois désactiver 802.11ax (forcer 802.11ac) est un contournement légitime quand un firmware d’AP et un pilote client ne tombent pas d’accord sur OFDMA ou le power‑save.
Ce n’est pas élégant. C’est parfois efficace.

Les bascules « booster » des fournisseurs sont souvent un euphémisme pour « ignorer l’équité et tenter de s’approprier l’airtime ». Dans les réseaux chargés, cela peut aggraver la situation pour tout le monde.
Si vous dépannez la stabilité, désactivez d’abord ces boosters.

Leviers côté AP et réseau qui déclenchent un mauvais comportement Windows

Band steering : quand le « smart » est juste têtu

Le band steering fonctionne en refusant des associations sur une bande, en retardant les réponses ou en déauthentifiant des clients pour « encourager » le passage.
Ce n’est pas de l’itinérance ; c’est de la coercition. Windows peut réagir mal—surtout si l’agressivité d’itinérance est aussi élevée et que le client scanne sans arrêt.

Si vous voyez des déauths répétés, envisagez d’assouplir l’agressivité du steering, de séparer les SSID pour un test ou de désactiver le steering sur un sous‑ensemble d’AP.
En environnement d’entreprise, le band steering est souvent moins prévisible que de concevoir une couverture 5 GHz adéquate.

802.11r (Fast BSS Transition) : excellent si cohérent, terrible si partiellement activé

802.11r peut réduire significativement le temps d’itinérance, ce qui compte pour la voix et les applications temps‑réel.
Le problème, ce sont les déploiements partiels : certains AP le supportent, d’autres non ; certains clients le supportent, d’autres non ; et vous obtenez des échecs intermittents qui paraissent « aléatoires ».

Traitez 802.11r comme un feature flag : déployez‑le correctement et testez les clients, ou gardez‑le éteint.
L’état « à moitié activé » est là où naissent les tickets.

802.11k/v : rapports de voisins et steer côté client

802.11k aide les clients à trouver plus rapidement des candidats d’itinérance. 802.11v peut suggérer aux clients de se déplacer.
Windows et les pilotes varient dans la façon d’utiliser ces indications. Si vos AP sont trop agressifs avec 11v, vous pouvez déclencher des itinérances dont le client n’avait pas besoin.

Canaux DFS : puissants, et parfois piégeux

Les canaux DFS (en 5 GHz) offrent un spectre plus propre, mais ils exigent la détection radar.
Quand un AP détecte un radar (ou pense l’avoir détecté), il doit quitter le canal. Les clients se déconnectent et se reconnectent ailleurs. Les utilisateurs appellent ça « coupures aléatoires ».

Si les coupures surviennent par grappes et affectent plusieurs clients en même temps, investiguez les événements DFS sur l’AP/le contrôleur.
La « solution » peut être de déplacer les SSID critiques hors DFS dans les régions sujettes au radar, pas de changer l’agressivité d’itinérance.

RSSI minimum et désassociation forcée

Certains réseaux appliquent un RSSI minimum en expulsant les clients en dessous d’un seuil.
Bien fait, cela réduit les clients collants. Mal fait, cela crée un effet ping‑pong : le client est expulsé, se reconnecte, est expulsé à nouveau.

Windows avec une agressivité d’itinérance élevée plus un RSSI minimum agressif est une tempête parfaite. Ajustez l’un ou l’autre, pas les deux au « strict maximum ».

Timers de réauthentification WPA2-Enterprise et latence RADIUS

Si vous forcez des réauthentifications fréquentes, vous créerez des « coupures » périodiques qui se corrèlent avec vos timers.
Si le chemin RADIUS est lent ou parfois congestionné, ces réauths échoueront parfois.
Le client paraît coupable ; c’est l’infrastructure d’authentification qui trébuche.

Trois mini-récits d’entreprise depuis les tranchées de l’itinérance

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un nouveau réseau Wi‑Fi 6 sur deux étages. Le pilote s’était bien passé : quelques portables IT, quelques téléphones, du trafic de test poli.
Puis le reste du bureau est revenu. Les appels vidéo ont commencé à couper, et le tableau de bord du helpdesk s’est enflammé comme un sapin de Noël.

L’hypothèse était simple et fausse : « Si le signal est fort partout, l’itinérance sera stable. »
Le plan d’étage avait un RSSI excellent, mais le plan de canaux créait une forte contention co‑canal dans l’open space. Les clients voyaient plusieurs AP « bons » tout le temps.
Les portables Windows avec les réglages d’itinérance par défaut continuaient à trouver des candidats « légèrement meilleurs » et à sauter.

L’équipe a cherché au mauvais niveau pendant deux jours. Ils ont remplacé un pare‑feu périphérique (deux fois), changé un circuit ISP et se sont disputés sur le DNS.
L’indice était dans les logs WLAN AutoConfig : les événements d’itinérance s’alignaient parfaitement sur les coupures d’appel, même si le SSID ne changeait jamais.

La correction n’a pas été héroïque. Ils ont réduit le chevauchement des canaux, ajusté la puissance d’émission des AP pour réduire la taille des cellules, et ont baissé d’un cran l’agressivité d’itinérance sur le modèle de portable le plus affecté.
Les appels ont cessé de couper. Le réseau ne s’est pas « renforcé ». Il est devenu plus calme.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation avait un déploiement maillé flambant neuf dans un bureau rénové—murs en verre, plafonds exposés, tout le catalogue moderne.
Quelqu’un a activé un band steering agressif parce que « 5 GHz est plus rapide » et a mis une enforcement RSSI minimale parce que « les clients collants, c’est mauvais ».
Deux idées raisonnables, combinées en un résultat déraisonnable.

Les portables près de la frontière de couverture s’associaient au 5 GHz, étaient incités, puis expulsés quand le RSSI chutait un instant.
Ils retombaient sur le 2.4 GHz, se faisaient de nouveau steerer, puis recommençaient. Les utilisateurs décrivaient le réseau comme « le Wi‑Fi meurt chaque fois que je me lève ».
Cela semblait ridicule jusqu’à ce que nous le reproduisions en reculant simplement une chaise.

Le retournement a aussi été psychologique : le réseau « paraissait » optimisé sur le papier—plus d’associations 5 GHz, moins de clients « faible RSSI ».
Pendant ce temps, l’expérience humaine était un carrousel de reconnexions. C’était une optimisation ciblant une métrique, pas un niveau de service.

La récupération a été d’assouplir le band steering, d’augmenter le seuil RSSI minimum seulement là où la couverture était réellement dense, et d’arrêter de forcer les clients à prendre des décisions parfaites dans un RF imparfait.
Ils ont aussi standardisé les versions de pilotes Windows parce qu’une gamme de portables avait un bug de boucle d’itinérance qui empirait tout.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société financière avait une politique : quand un problème Wi‑Fi est signalé, le premier intervenant doit collecter les mêmes trois artefacts—rapport WLAN, logs AutoConfig, et un échantillon ping/perte de 10 minutes vers la passerelle.
Aucune exception. Les gens râlaient parce que ça semblait lent. C’était le contraire : cela évitait des chasses aux fantômes qui duraient une semaine.

Un lundi, des traders ont commencé à signaler des « coupures Wi‑Fi aléatoires ». Panique, parce que les salles de marché n’ont pas de patience.
Le premier intervenant a suivi le playbook ennuyeux. Le rapport WLAN montrait des déconnexions simultanées sur plusieurs clients aux mêmes horodatages.
Cela a immédiatement éliminé l’idée de « l’agressivité d’itinérance d’un seul portable ».

Les logs ont pointé des évacuations de canaux DFS sur un groupe d’AP. Une source radar à proximité avait commencé à déclencher la détection.
L’équipe a déplacé le SSID critique hors des canaux DFS pour cette zone et programmé une véritable étude RF.
L’incident s’est clos rapidement parce que les preuves avaient été collectées systématiquement, pas parce que quelqu’un avait une intuition Wi‑Fi mystique.

Blague n°2 : La seule chose plus aléatoire que le Wi‑Fi, c’est l’invitation de calendrier pour la réunion sur pourquoi le Wi‑Fi était aléatoire.

Faits et historique intéressants à utiliser dans des arguments

• L’itinérance Wi‑Fi est conçue pour être pilotée par le client : 802.11 laisse historiquement les décisions d’itinérance à la station (client), pas à l’AP.
• L’itinérance d’entreprise était lente au début : avant les fonctions modernes de transition rapide, l’itinérance WPA2-Enterprise nécessitait souvent une réauth complète, provoquant des coupures audibles en VoIP.
• 802.11r existe parce que la voix l’a exigé : la Fast BSS Transition a été poussée par les applications temps‑réel qui ne tolèrent pas des handshakes de plusieurs secondes.
• 2.4 GHz n’a que trois canaux 20 MHz non chevauchants dans de nombreuses régions : d’où la congestion même quand vos « barres » semblent bonnes.
• DFS n’est pas une « complexité optionnelle », c’est une réglementation : les AP doivent quitter certains canaux si un radar est détecté, et cela peut ressembler à des déconnexions massives.
• Le RSSI est un instrument grossier : de nombreux clients utilisent encore la force du signal comme entrée principale pour l’itinérance, même si l’interférence et l’utilisation de l’airtime comptent davantage.
• Le band steering n’est pas une norme : de nombreuses implémentations sont propriétaires et ajoutent des comportements sur les règles d’association 802.11.
• 802.11k/v sont des « indices », pas des commandes : les clients peuvent les ignorer, et différentes piles pilotes les interprètent différemment.
• Les logs réseau Windows se sont améliorés au fil du temps : les builds modernes rendent les événements WLAN AutoConfig et la génération de rapport WLAN étonnamment utiles—si vous les lisez.

Une idée paraphrasée d’une voix fiabilité à écouter : Paraphrased idea: « L’espoir n’est pas une stratégie ; mesurez et vérifiez. » — attribuée à divers responsables opérations, couramment associée à la pratique d’ingénierie.

Erreurs courantes : symptôme → cause racine → correctif

« Ça coupe toutes les 10–20 minutes, comme sur un métronome. »

Cause racine : timers de réauth/reauth périodiques (WPA2-Enterprise), problèmes de renouvellement DHCP, ou cycle d’économie d’énergie du pilote.

Correctif : corrélez les horodatages dans les logs WLAN AutoConfig et le rapport WLAN. Si des événements EAP s’alignent, ajustez les timers de réauth et validez la santé du RADIUS.
Si DHCP s’aligne, inspectez le comportement des baux et le DHCP du gateway. Sinon, testez avec l’économie d’énergie de l’adaptateur désactivée.

« Ça coupe quand je me déplace entre les pièces. »

Cause racine : latence d’itinérance, 802.11r mal configuré, ou client collant.

Correctif : en entreprise, validez la cohérence de 11r et le PMK caching ; pour un mesh grand public, envisagez de séparer les SSID pour tester.
Si l’itinérance arrive trop tard, augmentez légèrement l’agressivité d’itinérance ; si elle arrive trop souvent, baissez‑la.

« Signal fort, mais Teams se reconnecte. »

Cause racine : contention co‑canal, retries, ou churn lié au band steering ; le RSSI semble correct alors que l’airtime est saturé.

Correctif : comparez les débits du lien dans le temps et recherchez des événements d’itinérance. Réduisez l’agressivité du band steering, ajustez le plan de canaux et évitez les canaux trop larges en zone dense.

« Seulement sur batterie, c’est terrible. »

Cause racine : mode d’économie d’énergie de l’adaptateur et/ou paramètres du plan d’alimentation Windows.

Correctif : mettez Wireless Adapter Settings sur Maximum Performance sur batterie pour un test ; désactivez la case NIC power‑saving dans le Gestionnaire de périphériques ; retestez.

« Ça a commencé après qu’on a activé WPA3 / protection des trames de gestion. »

Cause racine : écarts de compatibilité client/pilote, ou problèmes de configuration en mode mixte.

Correctif : validez netsh wlan show drivers pour les capacités et standardisez les versions de pilotes. Envisagez d’exécuter un SSID test en WPA2 uniquement pour confirmer.

« Ça coupe pour tout le monde en même temps. »

Cause racine : redémarrage/crash d’AP, évacuation de canal DFS, problème de contrôleur, panne LAN/WAN en amont.

Correctif : arrêtez de bidouiller les clients. Récupérez les logs AP/contrôleur pour événements DFS, reboots ou changements de canal. Confirmez la santé de la passerelle et les erreurs de ports de commutation.

« Ça coupe seulement sur un modèle de portable. »

Cause racine : régression de version de pilote, package pilote OEM personnalisé, ou incompatibilité d’une fonctionnalité avancée spécifique.

Correctif : comparez les versions de pilotes via pnputil. Faites un rollback ou standardisez. Désactivez les fonctionnalités avancées comme les throughput boosters pour ce modèle.

« Ça ‘coupe’ mais le Wi‑Fi affiche toujours connecté. »

Cause racine : échecs DNS, interception par portail captif, renégociation du tunnel VPN, ou routage/politique amont.

Correctif : testez un ping vers la passerelle + une résolution DNS pendant l’événement. Si le ping passerelle est OK mais le DNS échoue, corrigez DNS/split‑DNS/VPN/portail captif.

Listes de contrôle / plan pas à pas

Pas à pas : stabiliser un portable Windows qui « coupe aléatoirement »

1. Capturer les preuves d’abord.
   Générez le rapport WLAN et récupérez les 10–50 derniers événements AutoConfig. Notez l’horodatage de la coupure visible par l’utilisateur.
2. Confirmer s’il s’agit d’une itinérance.
   Vérifiez si le BSSID change autour de l’événement. Si oui, l’itinérance est impliquée. Sinon, regardez l’économie d’énergie, les retries et la couche IP.
3. Désactivez les éléments gênants pour une fenêtre de test contrôlée (30–60 minutes).
   Décochez la case de gestion d’alimentation de l’adaptateur ; réglez Wireless Adapter Settings sur Maximum Performance ; désactivez tout « booster ».
4. Ajustez l’Agressivité d’itinérance d’un cran.
   Si les itinérances sont fréquentes sans mouvement, baissez. Si le client s’accroche à un AP faible en marchant, montez légèrement (avec prudence).
5. Testez les hypothèses du band steering.
   Si sur un mesh grand public, séparez temporairement les SSID par bande. Si la stabilité s’améliore, votre steering est le problème, pas Windows.
6. Standardisez les versions de pilotes.
   Choisissez un pilote connu bon pour votre environnement. Mettez à jour/rollback sur le cohort affecté, pas à la pièce.
7. Si 802.1X en entreprise : validez les timers de réauth, la latence RADIUS et les fonctions de roaming rapide (11r/OKC/PMK caching).
8. Après les changements, revérifiez les logs.
   Vous voulez moins d’événements de déconnexion, moins de thrash d’itinérance et des rafales de perte de paquets réduites.

Checklist : signes pour régler l’agressivité d’itinérance (côté client)

• Des itinérances se produisent alors que l’utilisateur est immobile.
• Plusieurs AP visibles avec des forces de signal similaires (déploiement dense, open office).
• Événements de déconnexion/reconnexion montrent des déconnexions initiées par le pilote sans perte RF évidente.
• Le band steering est activé et le client change fréquemment de canaux/bandes.

Checklist : signes pour arrêter de toucher le client et réparer le réseau

• Beaucoup de clients coupent simultanément.
• Les logs AP montrent des évacuations DFS, des reboots ou des changements de canal aux heures des coupures.
• La reachabilité de la passerelle échoue pour le filaire et le sans fil en même temps.
• Des erreurs RADIUS/authentification apparaissent pour plusieurs utilisateurs dans la même fenêtre.

FAQ

1) Où se trouve exactement « Agressivité d’itinérance » sur Windows ?

Habituellement dans Gestionnaire de périphériques → Cartes réseau → (votre adaptateur Wi‑Fi) → Propriétés → Onglet Avancé.
Si ce n’est pas là, votre pilote/OEM peut ne pas l’exposer. Dans ce cas, le choix de la version du pilote devient encore plus important.

2) Quel réglage choisir : Lowest, Medium, Highest ?

Pour un portable sédentaire sur un réseau stable, un cran en dessous de la valeur par défaut est un bon point de départ.
Lowest peut créer des clients collants si vous vous déplacez. Highest tend à générer du churn d’itinérance dans les déploiements denses.

3) Pourquoi ça coupe même quand le signal est à 80–90 % ?

Parce que la force du signal n’est pas la même chose que la qualité du lien. La congestion, l’interférence, les retries et la charge de l’AP peuvent rendre un lien à fort signal mauvais.
Windows peut itinérer en poursuivant un « meilleur » signal, créant des micro‑pannes en chemin.

4) Est‑ce un problème Windows ou un problème réseau Wi‑Fi ?

Souvent c’est les deux qui interagissent mal. Windows prend les décisions d’itinérance ; le réseau influence les options et parfois pousse les clients.
Si beaucoup de clients coupent ensemble, c’est probablement côté réseau. Si seuls certains modèles coupent, c’est souvent côté pilote/client.

5) Dois‑je désactiver 802.11ax (Wi‑Fi 6) pour corriger les coupures ?

Comme test temporaire, oui—parfois cela isole une incompatibilité pilote/AP.
Comme solution permanente, non, sauf si vous avez confirmé que l’environnement ne peut pas supporter ax de manière fiable et que vous avez documenté la raison.

6) Séparer les SSID (2.4 et 5 GHz) aide‑t‑il ?

Cela peut aider. C’est un excellent outil de diagnostic pour prouver un churn lié au band steering.
Pour l’exploitation à long terme, c’est un compromis : plus de contrôle, mais plus de confusion pour les utilisateurs et plus de support.

7) Mon VPN coupe quand le Wi‑Fi itinère. Est‑ce normal ?

C’est courant. Beaucoup de clients VPN traitent de courtes interruptions d’interface comme un « changement de réseau » et renégocient.
La solution peut être une itinérance plus rapide (11r bien faite) ou des paramètres VPN qui tolèrent de brefs clignotements—pas simplement « désactiver l’itinérance ».

8) Quel est le meilleur log à regarder en premier ?

Le rapport WLAN obtenu avec netsh wlan show wlanreport, car il fournit une chronologie que vous pouvez corréler avec la douleur utilisateur.
Associez‑le aux événements WLAN AutoConfig pour les codes de raison.

9) Le Bluetooth peut‑il provoquer des coupures Wi‑Fi ?

Parfois, surtout en 2.4 GHz à cause des problèmes de coexistence. Si forcer le 5 GHz ou le 6 GHz fait disparaître le problème,
vous avez un indice fort. Ensuite corrigez l’usage des canaux/bandes plutôt que de blâmer « Windows ».

10) Si je baisse l’agressivité d’itinérance, puis‑je casser quelque chose ?

Vous pouvez créer un comportement de client collant : rester sur un AP plus faible plus longtemps que l’idéal, surtout en déplacement.
C’est pourquoi vous changez d’un cran à la fois et validez avec les logs et des mesures de perte.

Prochaines étapes qui fonctionnent réellement

Si vous voulez le chemin le plus court vers moins de « coupures » Wi‑Fi, faites ceci dans l’ordre :

1. Générez le rapport WLAN et récupérez les événements WLAN AutoConfig. Confirmez si vous êtes en itinérance, déconnecté ou si c’est un problème IP/DNS.
2. Exécutez netsh wlan show interfaces avant et après une coupure. Suivez les changements de BSSID et les déplacements de canal/débit.
3. Désactivez temporairement l’économie d’énergie de l’adaptateur et mettez Wireless Adapter Settings sur Maximum Performance. Si la stabilité revient, vous avez trouvé un levier.
4. Réglez l’Agressivité d’itinérance un cran en dessous si vous voyez du thrash d’itinérance alors que l’utilisateur est immobile.
5. Si vous êtes sur un mesh avec « smart connect », testez en séparant les SSID. Si cela améliore, ajustez le steering—ne continuez pas à punir le client.
6. Standardisez et testez les versions de pilotes Wi‑Fi sur votre parc. L’aléatoire a souvent un numéro de version.

L’itinérance n’est pas mauvaise. Les réglages cachés ne sont pas automatiquement magiques non plus.
Mais quand Windows prend discrètement des décisions d’itinérance à votre place, soit vous instrumentez et ajustez—soit vous continuez d’avoir des « coupures » Wi‑Fi qui ne sont pas du tout aléatoires.