Wi‑Fi 6/6E lent sous Windows 11 ? Corrigez pilote et alimentation

Méthode de diagnostic rapide (trouver le goulot en 10 minutes)

Voici la séquence que j’utilise quand quelqu’un me contacte pour « Wi‑Fi 6 lent » et que je n’ai pas une semaine pour un dépannage au feeling.
Vous allez déterminer si le goulot est (a) RF/choix de bande, (b) pilote/firmware, (c) gestion de l’alimentation, (d) interaction de fonctionnalités du routeur,
ou (e) la connexion Internet elle‑même.

Première étape : prouver que ce n’est pas le WAN

1. Lancez un test de vitesse depuis un appareil filaire sur le même routeur (ou branchez temporairement votre machine Windows 11).
   Si le filaire est aussi lent, cessez de blâmer le Wi‑Fi. Votre goulot est le WAN, le modem, l’ISP, ou le routage en amont.
2. Si le filaire est correct, poursuivez. Vous avez un problème WLAN ou client, pas un problème Internet.

Deuxième étape : vérifiez les détails de la liaison et la bande en 30 secondes

1. Confirmez si vous êtes sur 2,4 GHz, 5 GHz ou 6 GHz, et vos débits de réception/émission.
2. Si vous êtes sur 2,4 GHz : c’est souvent la réponse à « pourquoi c’est lent » dans de nombreuses maisons et un nombre choquant de bureaux.

Troisième étape : vérifiez la version et les capacités du pilote

1. Identifiez la puce Wi‑Fi (Intel/Realtek/Qualcomm/MediaTek) et la version du pilote.
2. Si le pilote est ancien, personnalisé par l’OEM, ou suspectement récent : testez une version connue comme fiable (mettre à jour ou revenir en arrière).

Quatrième étape : supprimez les économies d’énergie et les réglages « intelligents » de l’adaptateur

1. Désactivez « Autoriser l’ordinateur à éteindre ce périphérique pour économiser de l’énergie. »
2. Confirmez que le plan d’alimentation Windows actif ne bride pas discrètement la radio.
3. Diminuez l’agressivité de roaming seulement si vous êtes immobile et subissez des basculements de roaming.

Cinquième étape : isoler les interactions avec les fonctionnalités du routeur

1. Testez WPA2 vs WPA3 (temporairement) si vous suspectez une négociation ou un goulot CPU.
2. Essayez de désactiver les canaux 160 MHz (oui, désactiver une fonctionnalité peut augmenter le débit).
3. Sur 6E, confirmez que le 6 GHz est activé et ne fonctionne pas dans un étrange mode de « compatibilité legacy ».

Sixième étape : mesurez la latence et la perte, pas uniquement le débit

1. Pinguez la passerelle/le routeur et une cible Internet stable. Si la latence vers la passerelle est en dents de scie, vous avez un problème local RF/pilote/alimentation.
2. Si la passerelle est propre mais que la cible Internet oscille, regardez en amont (WAN, bufferbloat, ISP, VPN, proxy d’entreprise).

L’objectif : ne pas « réparer le Wi‑Fi ». Réparez le goulot spécifique que vous pouvez prouver avec une ou deux observations.

À quoi ressemble un « bon » Wi‑Fi 6/6E (et ce qui est un mensonge)

Windows affiche une « vitesse de liaison » qui n’est pas votre débit réel. La vitesse de liaison est le taux PHY négocié selon la modulation actuelle,
la largeur de canal, les flux spatiaux et les conditions du signal. Votre débit réel est inférieur à cause des surcharges (trames MAC, contention,
chiffrement, acquittements, retransmissions), plus ce que font en arrière‑plan le routeur et le client.

Attentes pratiques, à courte portée et spectre propre :

• Wi‑Fi 6 sur 5 GHz (80 MHz, 2×2) : souvent 600–900 Mbps de débit réel dans de bonnes conditions.
• Wi‑Fi 6 sur 5 GHz (160 MHz, 2×2) : peut dépasser 1 Gbps, mais est fragile et plus sensible aux interférences.
• Wi‑Fi 6E sur 6 GHz (80 MHz, 2×2) : tend à être plus propre que le 5 GHz ; le débit est souvent plus constant.
• 2,4 GHz : n’attendez pas de miracles. C’est pour la portée, pas la vitesse.

Le mensonge : « Ma vitesse de liaison indique 2402 Mbps, donc mes téléchargements devraient être 2,4 Gbps. » Non.
Pensez « la moitié à deux tiers lors d’une très bonne journée », et cela avant que votre NAS, VPN ou service cloud ne devienne le goulot.

Une règle opérationnelle : si la latence vers votre passerelle par défaut est en dents de scie alors que le débit est bas, ne touchez pas au DNS, ne touchez pas à Chrome, et ne touchez pas votre ISP.
C’est du Wi‑Fi local (RF, pilote, alimentation, roaming). Réparez le local d’abord.

Faits intéressants et un peu d’histoire (parce que ça aide)

• Wi‑Fi 6 est 802.11ax, et il s’est autant concentré sur l’efficacité en réseaux chargés que sur la vitesse brute.
• Wi‑Fi 6E est essentiellement le Wi‑Fi 6 étendu dans la bande 6 GHz ; le protocole n’est pas « nouveau », c’est le spectre qui l’est.
• OFDMA (Orthogonal Frequency Division Multiple Access) est le grand changement d’ordonnancement qui aide plusieurs clients à partager le medium plus efficacement.
• 1024‑QAM peut augmenter les débits de pointe, mais c’est délicat : il exige une bonne qualité de signal, donc la distance et les murs importent davantage que le marketing.
• Les canaux 160 MHz sont rapides sur le papier mais souvent taxants en stabilité dans les environnements réels en raison de DFS, d’interférences et d’un spectre propre limité.
• Le 6 GHz offre plus d’espace pour des canaux larges et moins d’appareils legacy ; c’est pourquoi le 6E peut sembler « magiquement stable » dans des appartements denses.
• La gestion de l’alimentation de Windows date de l’ère des portables où économiser la batterie était souvent priorisé par défaut au détriment des performances.
• La qualité du pilote compte davantage avec 802.11ax car l’ordonnancement, le roaming et les états d’alimentation sont plus complexes que dans les générations Wi‑Fi précédentes.
• WPA3 améliore la sécurité, mais certaines combinaisons routeur/client ont eu des bizarreries de performances lors des premières phases d’adoption.

Les vrais modes de défaillance : pilote, alimentation, bande, fonctions du routeur

1) Le pilote est « correct » mais inadapté à votre réalité

Windows Update adore livrer des pilotes stables pour une large flotte, pas nécessairement rapides pour votre combinaison spécifique portable+routeur.
Les fournisseurs OEM envoient aussi des pilotes personnalisés adaptés à leurs conceptions d’antenne, contraintes thermiques et profils d’alimentation.
Ensuite vous installez un pilote générique du fabricant de la puce parce qu’un forum l’a dit, et le roaming devient un cirque.

Le schéma que j’observe : une version de pilote fonctionne très bien au bureau mais s’effondre à la maison (ou vice versa). Ce n’est pas surnaturel.
C’est généralement une interaction de fonctionnalités : 160 MHz, WPA3, Target Wake Time, comportement de beamforming, ou steering d’AP.

2) La gestion de l’alimentation sabote silencieusement le débit

« Autoriser l’ordinateur à éteindre ce périphérique pour économiser de l’énergie » est la case évidente. La partie moins évidente : les plans d’alimentation Windows peuvent modifier la façon dont
le système et le pilote entrent dans des états basse consommation. Sur les puces Wi‑Fi modernes, la transition entre états d’alimentation peut ajouter de la latence, réduire les opportunités d’émission,
et provoquer des blocages intermittents qui ressemblent à un « Internet lent ».

Si votre symptôme est bonne vitesse pendant 10 secondes puis chute, ou bégaiements périodiques aléatoires, l’oscillation d’état d’alimentation est un suspect majeur.
Surtout sur batterie. Surtout après des cycles de veille/hibernation.

3) Vous êtes sur la mauvaise bande (ou l’AP vous oriente mal)

Le band steering est génial jusqu’à ce que ça ne le soit plus. Certains routeurs préfèrent vous garder sur 2,4 GHz parce que le signal semble « plus fort » (RSSI),
alors que l’airtime est bruyant et congestionné. L’OS peut aussi préférer un profil réseau enregistré qui mène à une bande sous‑optimale.

4) « Plus de fonctionnalités » peut signifier moins de vitesse

OFDMA, MU‑MIMO, beamforming, 160 MHz, WPA3, fast roaming (802.11r), BSS coloring… ce ne sont pas automatiquement des victoires.
Ce sont des outils. Les outils interagissent. Parfois ils se combattent.

Blague #1 : Le Wi‑Fi, c’est juste de l’Ethernet, sauf que c’est hanté et que vous ne voyez pas les câbles.

5) Le routeur n’est pas aussi puissant que l’autocollant le prétend

Le marketing des routeurs met l’accent sur des nombres « AX » agrégés qui supposent plusieurs clients et des canaux larges. Votre débit réel peut être limité par :
CPU (chiffrement/NAT), mauvaise conception radio, firmware bogué, throttling thermique, ou mauvais réglages par défaut (comme forcer 160 MHz dans un quartier encombré).

Tâches pratiques (commandes, sorties, décisions)

Ce sont des tâches réelles que vous pouvez exécuter sur Windows 11 et sur un routeur ou une machine Linux sur votre LAN.
Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision suivante à prendre.
L’objectif est d’arrêter de deviner.

Task 1: Confirm interface status and current rates

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

    Name                   : Wi-Fi
    Description            : Intel(R) Wi-Fi 6E AX210 160MHz
    GUID                   : 8a1d3c1b-2d0d-4d5a-9c6a-9d4c8c8e9c2f
    Physical address       : 3c:52:82:aa:bb:cc
    State                  : connected
    SSID                   : CorpNet
    BSSID                  : 84:16:f9:11:22:33
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA2-Personal
    Cipher                 : CCMP
    Connection mode        : Auto Connect
    Channel                : 37
    Receive rate (Mbps)    : 1201.0
    Transmit rate (Mbps)   : 1201.0
    Signal                 : 88%
    Profile                : CorpNet

Signification : Vous êtes connecté, en 802.11ax, et le Channel 37 suggère fortement le 6 GHz (6E) dans de nombreux domaines réglementaires.
Des débits autour de 1201 Mbps indiquent souvent une largeur de canal de 80 MHz avec 2 flux spatiaux.

Décision : Si vos débits de réception/émission sont faibles (par ex. 144–433 Mbps) alors que vous en attendez davantage, concentrez‑vous d’abord sur la bande/largeur de canal/le signal.
Si les débits sont élevés mais le débit réel est faible, focalisez‑vous sur le pilote/l’alimentation/le CPU du routeur et les interactions de fonctionnalités.

Task 2: Check driver file, version, and supported radio types

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

    Driver                    : Intel(R) Wi-Fi 6E AX210 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 2024-05-10
    Version                   : 23.50.0.6
    INF file                  : oem42.inf
    Type                      : Native Wi-Fi Driver
    Radio types supported     : 802.11a 802.11b 802.11g 802.11n 802.11ac 802.11ax
    FIPS 140-2 mode supported : Yes
    802.11w Management Frame Protection supported : Yes

Signification : Vous avez un pilote Intel moderne, et 802.11ax est pris en charge. Le oem42.inf indique un package installé
(cela peut être OEM ou Windows Update).

Décision : Si la version est ancienne ou si elle a changé récemment et que vos problèmes ont commencé « après des mises à jour », planifiez un test de rollback contrôlé.
Si 802.11ax manque parmi les types radio supportés, vous n’exécutez pas le pilote que vous croyez.

Task 3: Verify IP config and confirm the default gateway

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

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . : Intel(R) Wi-Fi 6E AX210 160MHz
   Physical Address. . . . . . . . : 3C-52-82-AA-BB-CC
   DHCP Enabled. . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . : 10.20.5.114(Preferred)
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . : Tuesday, February 6, 2026 9:12:41 AM
   Default Gateway . . . . . . . . : 10.20.5.1
   DNS Servers . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Signification : Vous avez un bail DHCP cohérent et une passerelle. C’est une validation d’installation, pas une validation de performance.

Décision : Utilisez l’IP de la passerelle pour les tests de latence. Si vous avez plusieurs passerelles ou un adaptateur VPN qui fait des trucs bizarres, isolez‑le ensuite.

Task 4: Ping the gateway to separate Wi‑Fi from WAN

cr0x@server:~$ ping -n 30 10.20.5.1
Pinging 10.20.5.1 with 32 bytes of data:
Reply from 10.20.5.1: bytes=32 time=2ms TTL=64
Reply from 10.20.5.1: bytes=32 time=3ms TTL=64
Reply from 10.20.5.1: bytes=32 time=64ms TTL=64
Reply from 10.20.5.1: bytes=32 time=4ms TTL=64

Ping statistics for 10.20.5.1:
    Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 64ms, Average = 6ms

Signification : Ce pic à 64 ms vers la passerelle est suspect dans un contexte LAN local. Cela signifie souvent des retransmissions, des interférences, des transitions d’état d’alimentation,
ou que l’AP est momentanément occupé. Si vous voyez des pics fréquents ou de la perte ici, ce n’est pas votre ISP.

Décision : Si les pings vers la passerelle sont en dents de scie, priorisez les changements de pilote/alimentation/bande/canal avant de toucher au DNS ou aux paramètres du modem.

Task 5: Ping a stable internet target to detect upstream issues

cr0x@server:~$ ping -n 30 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=57
Reply from 1.1.1.1: bytes=32 time=19ms TTL=57
Reply from 1.1.1.1: bytes=32 time=85ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 85ms, Average = 23ms

Signification : Un peu de jitter vers Internet est normal. Comparez avec le ping vers la passerelle. Si la passerelle est propre mais que l’Internet est instable,
examinez la congestion WAN, le bufferbloat, le VPN ou le routage ISP.

Décision : Si la passerelle et Internet sont mauvais, réparez d’abord le Wi‑Fi local. Si seul Internet est mauvais, cessez de chasser des fantômes Wi‑Fi.

Task 6: Capture a Wi‑Fi report (Windows built-in)

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

Signification : Windows génère une chronologie des événements de connectivité, des réinitialisations du pilote, du roaming et des erreurs. Ce n’est pas parfait, mais c’est une preuve.

Décision : Si vous voyez des cycles fréquents de déconnexion/reconnexion, des échecs d’authentification ou des réinitialisations de pilote, arrêtez d’optimiser les canaux et réglez d’abord le combo pilote/alimentation.

Task 7: List saved Wi‑Fi profiles and remove stale ones

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     : HomeNet

Signification : Plusieurs profils avec des noms similaires peuvent faire en sorte que Windows fasse du roaming ou de l’auto‑connexion d’une manière non voulue.

Décision : Si vous avez des doublons ou de vieux profils provenant d’anciennes configurations de routeur, supprimez les inutiles et reconnectez‑vous proprement.

cr0x@server:~$ netsh wlan delete profile name="CorpNet-Guest"
Profile "CorpNet-Guest" is deleted from interface "Wi-Fi".

Décision : Après nettoyage, retestez. Si les performances s’améliorent, vous aviez un désordre de politiques/auto‑connexion, pas de la physique RF.

Task 8: Force a reconnect to test band steering outcomes

cr0x@server:~$ netsh wlan disconnect
Disconnection request was completed successfully.

cr0x@server:~$ netsh wlan connect name="CorpNet"
Connection request was completed successfully.

Signification : Vous forcez une ré‑association. Utile après des modifications du routeur ou quand le client est coincé sur une mauvaise bande.

Décision : Relancez immédiatement netsh wlan show interfaces et vérifiez si le canal/la bande et les débits ont changé comme vous le vouliez.

Task 9: Inspect power plan and active scheme

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

Signification : Balanced est acceptable jusqu’à ce que ce ne le soit plus. Les vendeurs ajoutent parfois des ajustements cachés ou livrent des modes « silencieux » dans leurs applications de contrôle
qui modifient le comportement d’alimentation des périphériques en coulisse.

Décision : Si vos problèmes Wi‑Fi apparaissent principalement sur batterie, vous devrez probablement ajuster l’économie d’énergie de l’adaptateur et/ou choisir un plan plus orienté performance pour les tests.

Task 10: Check if the Wi‑Fi adapter is allowed to be powered down

cr0x@server:~$ powercfg /devicequery wake_armed
HID Keyboard Device
HID-compliant mouse

Signification : Cela ne liste pas directement « peut être éteint », mais cela vous aide à comprendre quels périphériques sont autorisés à réveiller le système.
Le débogage de la politique d’alimentation est fastidieux ; on triangule à partir de plusieurs indicateurs.

Décision : Utilisez le Gestionnaire de périphériques pour la case d’alimentation de l’adaptateur Wi‑Fi, puis retestez la stabilité des pings vers la passerelle et le débit.

Task 11: Check advanced TCP settings that affect perceived performance

cr0x@server:~$ netsh int tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : default
ECN Capability                      : disabled
Timestamps                          : disabled

Signification : L’auto‑tuning devrait généralement être normal. S’il est désactivé, les réseaux à large bande passante peuvent paraître inexplicablement lents.

Décision : Si l’auto‑tuning est désactivé, remettez‑le en normal et retestez le débit. En environnement d’entreprise, une politique peut le rétablir.

cr0x@server:~$ netsh int tcp set global autotuninglevel=normal
Ok.

Task 12: Identify which process is actually using the network

cr0x@server:~$ netstat -b -o -n | findstr ":443"
  TCP    10.20.5.114:51542     52.96.34.18:443        ESTABLISHED     10240
 [msedge.exe]
  TCP    10.20.5.114:51556     13.107.42.14:443       ESTABLISHED     14892
 [Teams.exe]

Signification : Si la plainte est « Le Wi‑Fi est lent » mais qu’un seul processus monopolise l’upload (synchronisation cloud, sauvegarde, téléchargements de jeux),
vous déboguez la mauvaise couche.

Décision : Si une seule application domine le trafic, mettez‑la en pause et retestez. Si tout s’améliore, vous aviez de la contention, pas un problème radio.

Task 13: On the router or a Linux host, verify LAN throughput independent of Wi‑Fi

Si vous avez une machine Linux câblée au routeur (ou un petit serveur), utilisez‑la comme contrôle pour séparer « problème Wi‑Fi » de « problème LAN/WAN ».

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

Ensuite depuis la machine Windows (si vous avez iperf3 installé) ou un autre client. Voici un exemple client depuis Linux à titre d’illustration :

cr0x@server:~$ iperf3 -c 10.20.5.50 -P 4
Connecting to host 10.20.5.50, port 5201
[SUM]   0.00-10.00  sec  1.02 GBytes   876 Mbits/sec  sender
[SUM]   0.00-10.00  sec  1018 MBytes   854 Mbits/sec  receiver

Signification : C’est solide pour un client Wi‑Fi 6 2×2 sur 80 MHz, en supposant un RF correct. Si vos tests Internet sont lents mais que l’iperf LAN est rapide,
votre Wi‑Fi est correct et le chemin WAN ne l’est pas.

Décision : LAN rapide + Internet lent = regardez l’ISP/VPN/DNS/CDN, pas les réglages de l’adaptateur.
Iperf LAN lent = Wi‑Fi local ou CPU du routeur en cause.

Task 14: Inspect Wi‑Fi event logs for driver resets and roaming churn

cr0x@server:~$ wevtutil qe Microsoft-Windows-WLAN-AutoConfig/Operational /c:8 /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: 11004
  Level: Warning
  Description:
    WLAN AutoConfig detected limited connectivity, attempting recovery.

Signification : Des avertissements autour de connectivité limitée, de connexions répétées, ou de timeouts d’authentification pointent vers des problèmes de pilote/alimentation/négociation AP.

Décision : Si vous voyez du churn répété, arrêtez d’optimiser les « canaux » et commencez par stabiliser le pilote et désactiver les coupures d’alimentation de l’adaptateur.

Blague #2 : Le moyen le plus rapide d’améliorer le Wi‑Fi est d’arrêter d’imprimer des PDFs dessus en 4K.

Trois mini‑histoires d’entreprise du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé de nouveaux portables Windows 11 avec des adaptateurs Wi‑Fi 6E. Le script du helpdesk disait : « Si c’est lent, l’ISP est congestionné. »
Ce script fonctionnait l’année précédente. Cette année, il est devenu une responsabilité.

Les plaintes se sont accumulées : appels vidéo qui gèlent, IDE cloud qui se déconnecte, « le VPN est cassé ». Les graphiques WAN semblaient corrects. Le pare‑feu ne surchauffait pas.
Le contrôleur Wi‑Fi montrait un RSSI client correct. Tout le monde continuait à blâmer Internet parce que les tests de vitesse étaient incohérents et émotionnellement convaincants.

La mauvaise hypothèse était simple : une vitesse de liaison élevée signifie que le Wi‑Fi va bien. Sur ces portables, la vitesse de liaison restait élevée alors que le client
subissait des micro‑pics de latence et des orages de retransmissions occasionnels. Windows affichait volontiers 1201 ou 2402 Mbps pendant que le ping vers la passerelle atteignait 200+ ms.

La solution a aussi été simple, une fois l’équipe arrêtée de traiter le Wi‑Fi comme de la magie : bloquer une version de pilote stable pour la puce, désactiver la possibilité pour l’adaptateur d’être éteint,
et désactiver le 160 MHz sur le SSID problématique. Le réseau n’est pas devenu « plus rapide ». Il est devenu cohérent, ce dont le travail a réellement besoin.

La leçon opérationnelle : ne laissez jamais un seul nombre d’interface (« vitesse de liaison ») agir comme votre SLO. Mesurez la latence vers la passerelle et les retransmissions ; ils disent la vérité.

Mini‑histoire 2 : L’optimisation qui a échoué

Une autre organisation a décidé de « moderniser » leur sans‑fil en activant toutes les fonctions brillantes sur l’ensemble du parc : WPA3 uniquement, 160 MHz partout, band steering agressif,
et fast roaming. C’était spectaculaire dans une démo en salle de conférence avec un portable à six pieds de l’AP.

Puis la réalité est arrivée. Dans les open spaces, le 160 MHz entrait en conflit avec le bruit RF et les événements DFS. Les clients changeaient de canal, renégociaient, et parfois atterrissaient sur un spectre saturé.
Un sous‑ensemble de clients Windows 11 avec une révision de pilote particulière affichait des effondrements intermittents du débit—bon pendant des minutes, mauvais pendant 30 secondes, puis de nouveau.
C’était parfait : difficile à reproduire à la demande et facile à mal diagnostiquer.

L’« optimisation » visait à augmenter le débit de pointe. Au lieu de cela, elle a augmenté la variabilité. Et la variabilité casse la voix, le VDI et tout ce qui est interactif.
Les gens ne se plaignent pas d’avoir 700 Mbps au lieu de 900 Mbps. Ils se plaignent quand leur appel coupe.

Le plan de rollback a été incrémental : revenir à 80 MHz sur la plupart des SSID, garder WPA3 en mode « transition » plutôt qu’exiger uniquement WPA3 pendant un moment, et traiter le band steering
comme quelque chose à régler par environnement. Le débit de pointe a baissé. Les tickets ont chuté davantage.

La leçon : le meilleur Wi‑Fi est un Wi‑Fi ennuyeux. Optimisez pour la stabilité et l’équité d’airtime, pas pour une capture d’écran à mettre dans une présentation.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise réglementée avait l’habitude, que d’autres équipes se moquaient, de maintenir une petite matrice de versions de pilotes « connues‑bonnes » par puce et modèle de portable.
Ils testaient aussi les mises à jour de fonctionnalités Windows avec ces pilotes dans un anneau pilote avant le déploiement large.

Lorsqu’une mise à jour Windows 11 est arrivée et que les performances Wi‑Fi se sont dégradées pour une famille d’adaptateurs spécifique, ils n’ont pas paniqué.
Ils avaient déjà des baselines : distributions de ping vers la passerelle, plages de débit iperf, et comportement de roaming sous charge.
Ce n’était pas subjectif. C’était une régression mesurable.

Ils ont maintenu le pilote constant, reproduit le problème, puis testé deux versions alternatives du pilote : une plus récente, une plus ancienne.
La version plus ancienne a restauré la stabilité. La plus récente a amélioré le débit mais a réintroduit du churn de roaming sur certains modèles d’AP.
Ils ont donc choisi l’option ennuyeuse : la stabilité d’abord, puis un engagement fournisseur plus long pour le cas complexe.

Pendant que d’autres organisations passaient des semaines à « éteindre et rallumer », celle‑ci a déployé un rollback contrôlé via la gestion des endpoints et est passée à autre chose. Personne n’a été promu pour ça. C’est comme ça qu’on sait que c’était correct.

Une idée paraphrasée souvent attribuée à la pensée fiabilité d’ingénierie (pas mot pour mot) : la disponibilité vient du contrôle du changement et de la compréhension des modes de défaillance, pas des exploits héroïques.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “Link speed is huge but downloads are slow”

• Cause racine : Débit limité par les retransmissions, les interférences, ou le CPU/NAT/chiffrement du routeur ; la vitesse de liaison n’est que le PHY.
• Correction : Pinguez la passerelle pour jitter/perte ; testez iperf LAN ; essayez 80 MHz au lieu de 160 MHz ; mettez à jour/revenez en arrière le pilote ; confirmez que vous êtes en 5/6 GHz.

2) Symptom: “Fast for 30 seconds, then drops, then recovers”

• Cause racine : Transitions d’état d’alimentation, bizarreries Target Wake Time, ou bugs de pilote après la veille.
• Correction : Désactivez la case d’arrêt d’alimentation de l’adaptateur ; testez sur secteur ; réglez Wireless Adapter Settings sur Maximum Performance ; envisagez un rollback de pilote.

3) Symptom: “Only slow on battery”

• Cause racine : Politiques d’alimentation agressives pour l’adaptateur WLAN.
• Correction : Réglez l’économie d’énergie de l’adaptateur Wi‑Fi sur Maximum Performance sur batterie ; conservez Balanced mais ajustez ce réglage si vous tenez à la stabilité des conférences.

4) Symptom: “Slow only in one location (same laptop)”

• Cause racine : Congestion RF, événements DFS du canal, ou band steering qui vous place en 2,4 GHz.
• Correction : Vérifiez le canal et la bande ; passez au SSID 5/6 GHz ; évitez de forcer 160 MHz dans des environnements encombrés.

5) Symptom: “Wi‑Fi 6E is slower than Wi‑Fi 6”

• Cause racine : Atténuation du signal 6 GHz à travers les murs, SNR effectif plus bas, ou placement d’AP non adapté au 6 GHz.
• Correction : Utilisez le 6 GHz près de l’AP ; sinon privilégiez un 5 GHz fort ; envisagez d’ajouter des AP plutôt que d’attendre que le 6 GHz traverse les murs.

6) Symptom: “VPN feels broken on Wi‑Fi but fine on Ethernet”

• Cause racine : Jitter/perte Wi‑Fi qui déclenche des retransmissions VPN ; MTU/fragmentation peut amplifier la douleur.
• Correction : Stabilisez d’abord le ping vers la passerelle ; puis vérifiez MTU et les réglages du client VPN si nécessaire. Ne commencez pas par le VPN.

7) Symptom: “After a Windows update, Wi‑Fi throughput tanked”

• Cause racine : Pilote remplacé par Windows Update ou nouveaux paramètres d’alimentation par défaut.
• Correction : Identifiez les changements de version du pilote ; testez un rollback ; puis verrouillez un pilote connu‑bon via la gestion des endpoints.

8) Symptom: “Speed is fine, but latency spikes during uploads”

• Cause racine : Bufferbloat sur le routeur/liaison WAN ; saturation en upstream ; QoS mal configuré.
• Correction : Limitez les uploads, activez SQM/Smart Queue Management si disponible, ou configurez correctement le QoS. Le Wi‑Fi peut être innocent ici.

Listes de contrôle / plan pas à pas

Plan A : Corriger le combo pilote + alimentation (la victoire habituelle)

1. Enregistrer une baseline : exécutez netsh wlan show interfaces et enregistrez canal, type radio, débits, signal.
   Lancez un test de ping de 30 s vers la passerelle et notez la latence max/moy.
2. Vérifier la version du pilote : exécutez netsh wlan show drivers. Si la version a changé récemment, planifiez un test de rollback.
3. Mettre à jour ou revenir intentionnellement :
   • Privilégiez les pilotes pris en charge par l’OEM d’abord pour les portables (ils règlent souvent l’alimentation/antennes).
   • Si l’OEM est obsolète et défaillant, testez les pilotes du fabricant de la puce, mais traitez‑les comme un changement avec possibilité de rollback.
4. Désactiver les coupures d’alimentation de l’adaptateur : dans Gestionnaire de périphériques → Network adapters → votre adaptateur Wi‑Fi → Power Management :
   décochez « Allow the computer to turn off this device to save power. »
5. Définir la politique d’alimentation de l’adaptateur sans fil : Options d’alimentation → Paramètres avancés → Wireless Adapter Settings :
   réglez « On battery » et « Plugged in » sur Maximum Performance (au moins pour les tests ; conservez‑les si ça règle votre quotidien).
6. Retester : ping de la passerelle à nouveau ; puis un iperf LAN si possible ; puis un test Internet.
7. Décider : si la stabilité de la latence s’est améliorée de façon significative, gardez ces réglages et arrêtez de bricoler.

Plan B : Sanité de bande et canal (quand le PHY est en cause)

1. Confirmez que vous êtes en 5 GHz ou 6 GHz. Si vous êtes en 2,4 GHz, réglez le steering ou séparez les SSID temporairement pour prouver le point.
2. Évitez le 160 MHz jusqu’à preuve du contraire. Utilisez 80 MHz pour la stabilité dans les environnements bruyants.
3. Sur 6E, placez l’AP où le 6 GHz peut réellement atteindre votre bureau. S’il ne peut pas, utilisez le 5 GHz et passez à autre chose.
4. Retestez : si les débits et le ping vers la passerelle s’améliorent, vous aviez un problème de planification RF/canal, pas un problème Windows.

Plan C : Interactions de fonctionnalités du routeur (quand « nouveau » rime avec « bizarre »)

1. Passez temporairement WPA3‑only en mode transition WPA2/WPA3 (ou WPA2) pour tester les bizarreries de négociation/perf.
2. Désactivez les fonctions de roaming avancé (802.11r) si vous voyez du churn d’auth/roaming répété sur des clients Windows.
3. Mettez à jour le firmware du routeur. Si le firmware est déjà à jour, considérez que « à jour » peut être « actuellement bogué ». Testez une version antérieure si possible.
4. Gardez les changements isolés : une modification, un test, une décision. Ne créez pas un ragoût mystère.

FAQ

1) Pourquoi ma vitesse de liaison Wi‑Fi 6/6E est élevée mais la vitesse réelle est faible ?

La vitesse de liaison est le taux PHY négocié. Le débit réel est inférieur à cause des surcharges, de la contention, des retransmissions, et parfois des limites CPU du routeur.
Utilisez le ping vers la passerelle et iperf LAN pour localiser où la perte/jitter est introduite.

2) Dois‑je toujours activer les canaux 160 MHz ?

Non. Utilisez le 160 MHz quand vous avez un spectre propre et de courtes distances. Sinon, il augmente souvent la variabilité (événements DFS, interférences)
et peut réduire le débit réel ou la stabilité.

3) Le 6 GHz est‑il toujours plus rapide que le 5 GHz ?

Pas toujours. Le 6 GHz est généralement plus propre, mais il s’atténue davantage à travers les murs. Si votre signal 6 GHz n’est pas fort, le 5 GHz peut le surpasser en pratique.

4) Dois‑je vouloir le pilote Wi‑Fi le plus récent ?

Vous voulez le meilleur pilote pour votre combinaison adaptateur + portable + routeur. Le « plus récent » est parfois la bonne solution, parfois une régression.
Si les performances se sont dégradées après une mise à jour, un test de rollback contrôlé est une démarche d’ingénierie sensée.

5) Quel réglage de Windows 11 cause le plus souvent des saccades Wi‑Fi ?

La gestion de l’alimentation. En particulier : permettre à Windows d’éteindre l’adaptateur et l’économie d’énergie sans fil agressive sur batterie.
Désactivez la case d’arrêt d’alimentation et réglez l’adaptateur sans fil sur Maximum Performance pour tester.

6) Mon Wi‑Fi est lent seulement après la veille. Pourquoi ?

Certains pilotes ne reprennent pas correctement, ou les transitions d’état d’alimentation restent coincées en modes sous‑optimaux.
Une mise à jour/rollback du pilote plus la désactivation des coupures d’alimentation de l’adaptateur résolvent généralement le problème.

7) Désactiver IPv6 accélérera‑t‑il le Wi‑Fi ?

En général non, et cela crée souvent de nouveaux problèmes. Si vous suspectez DNS ou problèmes de chemin, testez d’abord avec le ping vers la passerelle et iperf LAN.
Ne cassez pas IPv6 parce que l’Internet vous l’a conseillé.

8) Comment savoir si le routeur est le goulot ?

Si iperf LAN entre votre client Wi‑Fi et un serveur filaire est lent, le goulot est local (Wi‑Fi ou routeur).
Si iperf LAN est rapide mais Internet lent, le chemin WAN du routeur, l’ISP, le VPN ou la congestion en amont sont plus probables.

9) Pourquoi les performances changent‑elles selon le routeur du bureau vs la maison ?

Différents plans de canal, différents ensembles de fonctionnalités (WPA3/802.11r/OFDMA tuning), et différents profils d’interférence.
Les pilotes peuvent se comporter différemment selon l’implémentation de l’AP et le comportement du band steering.

10) Dois‑je séparer les SSID (2.4/5/6 GHz séparés) ?

Pour le dépannage, oui—c’est l’un des moyens les plus rapides de prouver que le band steering est en cause.
À long terme, un seul SSID peut convenir si votre routeur gère bien le steering. Beaucoup ne le font pas.

Conclusion : prochaines étapes qui font vraiment bouger les choses

Si vous ne retenez qu’une chose : arrêtez de vénérer le chiffre de la vitesse de liaison. Mesurez la latence vers la passerelle, confirmez votre bande, et traitez les changements de pilote comme de vrais changements
avec possibilité de rollback. Windows 11 n’est pas spécialement mauvais pour le Wi‑Fi 6/6E ; il cache juste très bien les deux boutons qui comptent le plus : le comportement du pilote et la politique d’alimentation.

Prochaines étapes pratiques :

1. Exécutez netsh wlan show interfaces et confirmez la bande/le canal et les débits.
2. Pinguez votre passerelle par défaut pendant 30–60 secondes. Des pics ou de la perte signifient un problème Wi‑Fi local.
3. Vérifiez la version du pilote avec netsh wlan show drivers. Si les problèmes ont commencé après une mise à jour, testez un rollback.
4. Désactivez l’arrêt d’alimentation de l’adaptateur et réglez l’économie d’énergie de l’adaptateur sans fil sur Maximum Performance (au moins pour tester).
5. Si vous forcez le 160 MHz, essayez 80 MHz pendant une journée et voyez si la stabilité s’améliore.

Le Wi‑Fi est un medium partagé avec beaucoup de pièces mobiles. L’astuce est d’être méthodique, pas mystique.