Wi‑Fi se déconnecte toutes les 10 minutes : le paramètre avancé du pilote qui le corrige

février 13, 2026 • février 13, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Vous êtes en visioconférence. Tout le monde vous entend jusqu’à—comme un métronome—votre Wi‑Fi se coupe. Dix minutes plus tard, il revient. Dix minutes après, il se recoupe. Vous redémarrez le routeur, jurez après le routeur, vous déplacez de trois pas vers la gauche, et pendant un instant vous croyez avoir réglé le problème.

Puis la déconnexion horlogeuse revient. Si ça sent l’« économie d’énergie » ou le « timer de rekey/reauth », vous êtes déjà sur la bonne piste. La solution n’est généralement pas mystique. C’est un paramètre avancé du pilote (ou deux) plus une preuve que vous avez modifié la bonne chose.

Le réglage avancé qui résout le plus souvent le problème

Si votre Wi‑Fi se coupe sur un rythme—surtout sur des laptops, surtout sur batterie—le correctif le plus efficace est généralement :

Désactiver l’économie d’énergie Wi‑Fi côté client (U‑APSD / SMPS / « Power Save Mode »)

Les fabricants le nomment différemment, mais l’intention est la même : le client négocie un comportement d’endormissement avec le point d’accès (AP). Quand c’est mal implémenté (ou que l’AP n’aime pas la négociation), vous obtenez des blocages périodiques ou des déconnexions qui semblent « aléatoires » à moins de remarquer le timer.

Sur Windows cela se trouve typiquement à deux endroits :

Gestion de l’alimentation de l’adaptateur : « Autoriser l’ordinateur à éteindre ce périphérique pour économiser l’énergie » (Gestionnaire de périphériques → votre adaptateur Wi‑Fi → Propriétés → Gestion de l’alimentation).
Paramètres avancés du pilote (Gestionnaire de périphériques → Propriétés → Avancé) : « Power Save Mode », « MIMO Power Save Mode », « U‑APSD support », « Minimum Power Consumption », « Transmit Power », ou « Prefer maximum performance ».

Ce que vous cherchez à accomplir est sans glamour : garder la radio éveillée, arrêter le comportement de sommeil « utile », et réduire le thrash de roaming/scan. Si votre déconnexion a lieu exactement toutes les 10 minutes, suspectez aussi des timers de rekey/reauth, mais l’économie d’énergie est le gain le plus rapide car elle dépend entièrement du client et vous pouvez la valider sans négocier avec le propriétaire de l’AP.

Une petite blague pour l’air : l’économie d’énergie Wi‑Fi, c’est comme le « mode éco » d’une voiture de sport — super sur une brochure, catastrophique dans la circulation.

Pourquoi « toutes les 10 minutes » arrive dans le monde du Wi‑Fi

Dix minutes n’est pas magique. C’est juste une échelle temporelle très courante où diverses politiques Wi‑Fi et réseau font un tour :

Intervalles de rekey du key group sur les installations WPA2/WPA3 enterprise sont souvent mesurés en minutes. Certains environnements les règlent de façon agressive, et certains pilotes clients gèrent mal la transition.
Réauthentification 802.1X peut être programmée, et si le chemin d’authentification est instable, le « renouvellement » ressemble à une coupure.
Renouvellement de bail DHCP est généralement plus long que 10 minutes, mais des réseaux mal configurés (surtout des VLAN invités) peuvent utiliser des baux courts.
Scans en arrière-plan du pilote et algorithmes de roaming tournent parfois sur des timers périodiques et peuvent provoquer de brèves déconnexions visibles par les applications sensibles.
Tick de gestion d’alimentation qui peut s’aligner sur les politiques OS (économie de batterie, transitions Modern Standby, suspension sélective du NIC).

Faits et historique (parce que les valeurs par défaut ont du bagage)

Voici des points concrets qui expliquent pourquoi votre souci « simple » de Wi‑Fi est en réalité un empilement de décisions prises sur 25 ans :

La gestion d’alimentation 802.11 existe depuis les débuts du Wi‑Fi, mais les implémentations modernes l’ont étendue avec des mécanismes comme WMM Power Save (U‑APSD) pour réduire la latence vocale tout en dormant entre les trames.
WPA2 (2004) a normalisé le rekey périodique comme mesure d’hygiène de sécurité ; « faire tourner les clés » c’est une bonne sécurité, jusqu’à ce qu’un client bogué en fasse un événement de connectivité.
Le band steering est devenu courant avec la généralisation des AP double/tri‑bande ; les clients peuvent être encouragés (ou poussés) vers le 5 GHz/6 GHz, mais certains pilotes interprètent le steering comme de l’instabilité.
Les assistances de roaming 802.11k/v/r existent pour fluidifier le roaming ; des fonctionnalités à moitié implémentées peuvent créer une boucle de tentatives de roaming.
Modern Standby de Windows a changé la sémantique de veille ; c’est plus proche de « toujours allumé, toujours connecté », ce qui met plus de pression sur les états d’alimentation du NIC et la qualité du pilote.
Les pilotes clients sont souvent livrés avec des valeurs par défaut OEM optimisées pour les benchmarks de batterie, pas pour votre combo VPN + visioconférence + AP capricieux.
Le Wi‑Fi en entreprise adore les timers parce qu’il adore la politique. Les timers ne sont pas mauvais ; ils sont juste très littéraux.
Le 6 GHz (Wi‑Fi 6E) ajoute AFC et complexité réglementaire dans certaines régions et rend « je vais tout scanner » plus coûteux pour les clients.

Playbook de diagnostic rapide

L’objectif est de trouver le goulot rapidement : pilote client, RF/environnement, politique AP, ou réseau amont. Ne devinez pas. Collectez des preuves en 10–15 minutes.

Première étape : prouvez que c’est la couche lien Wi‑Fi, pas « l’internet »

Faites un ping continu vers la passerelle par défaut. Si ça échoue, votre lien rompt localement (RF, pilote, AP). Si la passerelle reste solide mais que les cibles externes tombent, suspectez WAN/VPN/DNS.
Surveillez l’état d’association : le client se déconnecte‑t‑il et se reconnecte (nouveau BSSID, nouvelle auth), ou reste‑t‑il associé mais bloqué ?

Seconde étape : cherchez la périodicité et l’événement exact

Sur Windows, générez un rapport WLAN et lisez les codes « Raison de la déconnexion ».
Sur Linux, inspectez les logs journald pour les raisons de deauth/disassoc et les basculements de power‑save.

Troisième étape : changez un réglage client pour supprimer l’économie d’énergie

Désactivez la gestion d’alimentation de l’adaptateur Wi‑Fi dans le Gestionnaire de périphériques et dans l’onglet Avancé du pilote.
Forcer « Performance maximale » (Paramètres d’alimentation Windows avancés pour Wireless Adapter Settings).

Quatrième étape : si c’est toujours périodique, inspectez les timers de rekey/reauth

Vérifiez si l’intervalle de coupure correspond à un timer de sécurité (600 secondes est suspectement « façonné par une politique »).
Confirmez avec les logs AP/controlleur si vous y avez accès — ou au moins testez sur un autre réseau pour isoler.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les actions « fais‑ça, lis‑ça, décide‑ça ». Prêtes à copier/coller, avec sorties réalistes. Servez‑vous en pour transformer « Wi‑Fi instable » en diagnostic.

Tâche 1 (Windows) : Identifier l’adaptateur, la version du pilote et le fournisseur

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter -Physical | Where-Object {$_.Status -eq 'Up'} | Format-Table -Auto Name, InterfaceDescription, LinkSpeed"
Name   InterfaceDescription                      LinkSpeed
Wi-Fi  Intel(R) Wi-Fi 6 AX200 160MHz             780 Mbps

Ce que ça signifie : Confirme quel adaptateur est actif. « Intel AX200 » et ses semblables ont des comportements spécifiques de power‑save et de roaming.

Décision : Concentrez vos réglages sur cet adaptateur ; ne perdez pas de temps sur des adaptateurs virtuels.

Tâche 2 (Windows) : Récupérer les informations détaillées du pilote

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object {$_.FriendlyName -like '*Wi-Fi*'} | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion"
InstanceId  : PCI\VEN_8086&DEV_2723&SUBSYS_00848086&REV_1A\3&11583659&0&10
Data        : 23.60.1.2
Type        : String

Ce que ça signifie : Version du pilote. Certaines coupures périodiques sont des bugs de pilote, pas votre imagination.

Décision : Si vous avez plusieurs versions majeures de retard, mettez à jour. Si vous êtes sur la version la plus récente et que ça empire, revenez à une version OEM connue‑stable.

Tâche 3 (Windows) : Générer et ouvrir le rapport WLAN

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

Ce que ça signifie : Windows a créé un rapport HTML des associations, déconnexions et raisons.

Décision : Ouvrez‑le et cherchez des codes « Raison » qui se répètent, des boucles de reconnexion, et des horodatages tous les ~10 minutes.

Tâche 4 (Windows) : Lister les profils Wi‑Fi et vérifier si une politique vous contraint

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

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

User profiles
-------------
    All User Profile     : CorpWiFi
    All User Profile     : GuestWiFi

Ce que ça signifie : Si des profils de stratégie de groupe existent, vos modifications peuvent être écrasées par l’IT.

Décision : Si un profil d’entreprise est imposé, attendez‑vous à des timers 802.1X et des changements pilotés par le contrôleur ; récoltez des preuves avant de « corriger ».

Tâche 5 (Windows) : Surveiller les événements WLAN AutoConfig pour la raison de déconnexion

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-WLAN-AutoConfig/Operational -MaxEvents 5 | Select-Object TimeCreated, Id, Message | Format-List"
TimeCreated : 2/4/2026 9:12:10 AM
Id          : 8003
Message     : WLAN AutoConfig service has disconnected from a wireless network. Reason: The network is disconnected by the driver.

TimeCreated : 2/4/2026 9:12:12 AM
Id          : 8001
Message     : WLAN AutoConfig service has successfully connected to a wireless network.

Ce que ça signifie : « Disconnected by the driver » est un gros indice : économie d’énergie, décision de roaming, ou bug du pilote.

Décision : Priorisez les paramètres avancés du pilote (power save/roaming) avant d’accuser DNS, VPN ou le routeur.

Tâche 6 (Windows) : Vérifier les paramètres de plan d’alimentation sans fil

cr0x@server:~$ powercfg /q | findstr /i "Wireless Adapter Settings"
Subgroup GUID: 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1  (Wireless Adapter Settings)
Power Setting GUID: 12bbebe6-58d6-4636-95bb-3217ef867c1a  (Power Saving Mode)

Ce que ça signifie : Confirme que Windows gère l’alimentation Wi‑Fi via le plan d’alimentation.

Décision : Réglez sur « Performance maximale » sur batterie et sur secteur pendant le diagnostic. Si ça corrige, vous pourrez plus tard détendre « sur batterie ».

Tâche 7 (Linux) : Identifier le périphérique Wi‑Fi, le pilote et le firmware

cr0x@server:~$ sudo lspci -nnk | sed -n '/Network controller/,+4p'
03:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
	Subsystem: Intel Corporation Device [8086:0084]
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Ce que ça signifie : Confirme le pilote du noyau. Intel utilise iwlwifi ; Realtek utilise souvent rtw88/rtl8xxx ; Qualcomm Atheros utilise ath10k/ath11k.

Décision : Appliquez des réglages spécifiques au pilote (iwlwifi power_save, etc.).

Tâche 8 (Linux) : Vérifier l’état actuel du power save

cr0x@server:~$ iw dev wlan0 get power_save
Power save: on

Ce que ça signifie : Le power save est activé au niveau mac80211.

Décision : Désactivez‑le pour tester. Si les coupures cessent, vous avez trouvé la classe de bug.

Tâche 9 (Linux) : Désactiver le power save immédiatement (runtime)

cr0x@server:~$ sudo iw dev wlan0 set power_save off
cr0x@server:~$ iw dev wlan0 get power_save
Power save: off

Ce que ça signifie : Vous avez désactivé le power save pour la session en cours.

Décision : Testez pendant au moins 30 minutes. Si les coupures à 10 minutes disparaissent, rendez la modification persistante (tâches suivantes).

Tâche 10 (Linux + NetworkManager) : Vérifier que NM ne réactive pas le power save Wi‑Fi

cr0x@server:~$ sudo nmcli -f WIFI.POWERSAVE general
WIFI.POWERSAVE: 3 (enabled)

Ce que ça signifie : NetworkManager est configuré pour activer le powersave (valeur 3). Cela peut écraser les modifications manuelles via iw.

Décision : Réglez sur 2 (désactivé) pour les tests de stabilité.

Tâche 11 (Linux + NetworkManager) : Désactiver le power save Wi‑Fi de NM de manière persistante

cr0x@server:~$ sudo bash -lc 'cat >/etc/NetworkManager/conf.d/wifi-powersave-off.conf <<EOF
[connection]
wifi.powersave = 2
EOF
systemctl restart NetworkManager'

Ce que ça signifie : Désactive de façon persistante le powersave Wi‑Fi dans NetworkManager et redémarre ce dernier.

Décision : Retestez les déconnexions périodiques. Si c’est corrigé, conservez la modification. Si l’autonomie est critique, expérimentez ensuite des réglages moins agressifs.

Tâche 12 (Linux) : Vérifier les logs autour de la coupure

cr0x@server:~$ sudo journalctl -u NetworkManager --since "30 min ago" | tail -n 20
Feb 04 09:12:10 laptop NetworkManager[1023]: <info>  [1707047530.1234] device (wlan0): supplicant interface state: completed -> disconnected
Feb 04 09:12:10 laptop NetworkManager[1023]: <warn>  [1707047530.1256] device (wlan0): link timed out.
Feb 04 09:12:12 laptop NetworkManager[1023]: <info>  [1707047532.8899] device (wlan0): supplicant interface state: disconnected -> scanning
Feb 04 09:12:14 laptop NetworkManager[1023]: <info>  [1707047534.2222] device (wlan0): supplicant interface state: scanning -> associating
Feb 04 09:12:16 laptop NetworkManager[1023]: <info>  [1707047536.3333] device (wlan0): supplicant interface state: associating -> completed

Ce que ça signifie : Montre la séquence : completed → disconnected → scanning → associating. Si ça se répète sur un timer, suspectez le powersave ou la réauthentification de sécurité.

Décision : Associez cela aux messages de wpa_supplicant (tâche suivante) pour voir si une raison de deauth est présente.

Tâche 13 (Linux) : Inspecter wpa_supplicant pour les raisons de deauth

cr0x@server:~$ sudo journalctl -t wpa_supplicant --since "30 min ago" | tail -n 20
Feb 04 09:12:10 laptop wpa_supplicant[1122]: wlan0: CTRL-EVENT-DISCONNECTED bssid=aa:bb:cc:dd:ee:ff reason=4 locally_generated=1
Feb 04 09:12:12 laptop wpa_supplicant[1122]: wlan0: SME: Trying to authenticate with aa:bb:cc:dd:ee:ff (SSID='CorpWiFi' freq=5180 MHz)
Feb 04 09:12:14 laptop wpa_supplicant[1122]: wlan0: CTRL-EVENT-CONNECTED - Connection to aa:bb:cc:dd:ee:ff completed [id=0 id_str=]

Ce que ça signifie : « locally_generated=1 » pointe souvent vers une décision côté client (roaming, power save, pilote). « reason=4 » est « disassociated due to inactivity » dans de nombreux contextes, classique odeur de mismatch power‑save.

Décision : Continuez d’insister sur le power‑save/ l’agressivité du roaming côté client. Si les raisons indiquent une deauth initiée par l’AP, montez d’un cran vers les réglages AP.

Tâche 14 (Tout OS) : Prouver si la passerelle tombe pendant l’événement

cr0x@server:~$ ping -n 200 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.14 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.06 ms
Request timeout for icmp_seq 63
Request timeout for icmp_seq 64
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=2.44 ms

Ce que ça signifie : Si la passerelle par défaut tombe, ce n’est pas le DNS ni l’ISP. C’est la connectivité Wi‑Fi locale.

Décision : Concentrez‑vous sur les événements d’association RF/pilote/AP, pas sur le routage externe.

Tâche 15 (Tout OS) : Vérifier si vous faites du roaming entre AP ou bandes

cr0x@server:~$ iw dev wlan0 link
Connected to aa:bb:cc:dd:ee:ff (on wlan0)
	SSID: CorpWiFi
	freq: 5180
	signal: -62 dBm
	rx bitrate: 780.0 MBit/s
	tx bitrate: 585.0 MBit/s

Ce que ça signifie : Montre le BSSID et la fréquence. Si après une coupure le BSSID change, vous faites du roaming (peut‑être à cause du band steering ou de seuils de signal trop faibles).

Décision : Réduisez l’agressivité du roaming côté client ou améliorez la disposition des AP / désactivez un steering trop agressif.

Windows : les réglages du pilote qui comptent (et ceux qui n’en valent pas la peine)

Windows offre au moins trois couches d’« économie d’énergie », et elles s’empilent. C’est pour ça que des gens jurent avoir changé un paramètre et que rien ne se passe : ils ont touché la mauvaise couche.

Couche 1 : Gestionnaire de périphériques → Onglet Gestion de l’alimentation

Réglage : « Autoriser l’ordinateur à éteindre ce périphérique pour économiser l’énergie. »

Faire : Décochez pendant le dépannage. Gardez décoché si vous privilégiez la disponibilité sur les gains théoriques de batterie.

Pourquoi ça aide : C’est une solution brute. Empêche Windows de suspendre sélectivement le NIC. La suspension sélective fonctionne jusqu’à ce qu’un combo pilote/firmware rate un réveil ou perde l’état.

Couche 2 : Plan d’alimentation → Wireless Adapter Settings

Réglage : Power Saving Mode : Maximum Performance vs Medium/Low Power Saving.

Faire : Mettez « Performance maximale » sur batterie et branché pendant le diagnostic. Si ça corrige, vous pourrez ensuite décider d’assouplir « sur batterie ».

Couche 3 : Paramètres avancés du pilote (les vrais fauteurs de troubles)

C’est souvent ici que les coupures périodiques sont éliminées. Les noms varient selon les fournisseurs, mais cherchez ces paramètres :

Power Save Mode / Minimum Power Consumption : mettre sur Off / Disabled.
MIMO Power Save Mode (SMPS) : mettre sur No SMPS / Disabled (les noms varient). Un SMPS agressif peut créer des stagnations bizarres ; dans certains environnements ça ressemble à une coupure.
U‑APSD / WMM Power Save : désactivez pour tester. Si le trafic voix/latence est important, vous pourrez le réactiver plus tard si stable.
Roaming Aggressiveness : mettre sur Lowest (ou Medium‑Low). Une agressivité élevée scanne constamment et « vous améliore » jusqu’à une déconnexion.
Preferred Band : verrouillez sur 5 GHz (ou 6 GHz si stable) pour éviter les boucles de band steering. Ou verrouillez temporairement sur 2.4 GHz si vous testez portée/RF.
Transmit Power : mettre sur Highest. Une puissance TX réduite peut causer des liens asymétriques où vous entendez l’AP mais il ne vous entend pas de manière fiable.

Deux réglages que l’on aime toggler mais qui corrigent rarement des coupures à 10 minutes :

« Mode 802.11n/ac/ax » : ces bascules peuvent aider la compatibilité, mais ce ne sont pas les premiers changements à tenter sauf si l’AP est ancien ou bogué.
Préférences de largeur de canal : impactent le débit et l’interférence ; c’est une optimisation de second ordre, pas une clé contre les coupures périodiques.

Comment valider le correctif (ne vous fiez pas aux impressions)

Après vos modifications, validez avec trois éléments :

Les événements WLAN AutoConfig ne montrent plus de déconnexions initiées par le pilote.
Le ping continu vers la passerelle n’a plus de trou toutes les 600 secondes.
Votre BSSID/fréquence reste stable (sauf si vous vous déplacez physiquement).

Linux : iwlwifi/ath* powersave, NetworkManager et réalité

Linux vous donne l’honnêteté : les logs diront ce qui est arrivé, et ils le feront à 2 h du matin quand vous cherchez le sommeil. Mais Linux vous donne aussi le choix, et certains de ces choix sont « oui, le système réactivera le powersave parce que quelqu’un a jugé cela poli ».

Power save côté client : trois boutons, un résultat

mac80211 powersave via iw (runtime, par interface)
NetworkManager wifi.powersave (politique, persistant)
Paramètres du module pilote (par ex., iwlwifi power_save)

Pour des coupures périodiques, désactivez tout cela pendant les tests. Plus tard, vous pourrez réintroduire l’économie d’énergie prudemment si vous tenez à l’autonomie.

Paramètres du module iwlwifi (Intel)

Les adaptateurs Intel sont courants et généralement bons, mais aussi sophistiqués. Les fonctionnalités d’alimentation peuvent interagir avec des bizarreries d’AP. Une base stable pour le dépannage : powersave off, pas de fonctions expérimentales, et firmware à jour.

cr0x@server:~$ sudo modinfo iwlwifi | grep -E "parm:|firmware"
firmware:       iwlwifi-cc-a0-77.ucode
parm:           power_save:Enable power save (default: true)
parm:           uapsd_disable:Disable U-APSD (default: false)

Ce que ça signifie : Montre les paramètres du module. Si vous voyez uapsd_disable, c’est un indice que vous pouvez tester la désactivation de l’U‑APSD au niveau du pilote.

Décision : N’utilisez les options de module que lorsque NetworkManager et les changements iw ne suffisent pas ou sont systématiquement réactivés.

cr0x@server:~$ sudo bash -lc 'cat >/etc/modprobe.d/iwlwifi-powersave-off.conf <<EOF
options iwlwifi power_save=0 uapsd_disable=1
EOF
update-initramfs -u'
update-initramfs: Generating /boot/initrd.img-6.5.0-18-generic

Ce que ça signifie : Persiste les paramètres iwlwifi après reboot (update-initramfs affiché pour systèmes Debian/Ubuntu).

Décision : Redémarrez et confirmez que les coupures cessent. Si la stabilité s’améliore, vous avez identifié une interaction AP+U‑APSD ou un comportement firmware.

Deuxième petite blague (et dernière) : Si vous aimez courir après un Wi‑Fi intermittent, vous adoreriez aussi la corruption de stockage — les deux gardent des traces, juste pas celles que vous souhaitez.

Routeur/AP : timers et fonctionnalités qui créent des coupures périodiques

Les ajustements côté client résolvent un nombre surprenant de cas. Mais parfois c’est l’AP qui vous renvoie toutes les 10 minutes — poliment, en conformité avec les standards, avec un code raison que personne ne lit.

Causes courantes côté AP des déconnexions périodiques

Intervalle de rekey du Group Key trop court ou gestion boguée côté client des transitions de rekey.
Réauthentification 802.1X avec un chemin RADIUS fragile ou des valeurs de timeout de session incorrectes.
Timeout d’inactivité qui ne prend pas en compte les clients en power‑save (l’AP pense que vous êtes inactif ; vous pensez dormir poliment).
Band steering qui tente sans cesse de vous déplacer entre les bandes, surtout si le même SSID est en 2.4 et 5 GHz avec des seuils agressifs.
Équilibrage de charge / steering client réglé pour des bureaux denses, pas pour un bureau à domicile où « déplacer le client » signifie « le déconnecter ».
Mode de transition WPA3 (mixte WPA2/WPA3) capricieux, surtout avec des pilotes plus anciens.

Comment savoir que c’est la politique de l’AP sans accès à l’AP

Vous pouvez déduire beaucoup de choses depuis le côté client :

Si les logs montrent une deauth/disassoc initiée par l’AP (locally_generated=0 sur Linux ; « Reason: received deauthentication from AP » sur Windows), suspectez timers/steering AP.
Si le client se reconnecte au même BSSID avec une nouvelle poignée de main toutes les ~10 minutes, suspectez reauth/rekey/timeout d’inactivité.
Si le client se reconnecte à un BSSID ou une bande différente, suspectez steering ou seuils de roaming.

Quand vous avez accès à l’AP, la correction est généralement : augmenter l’intervalle de rekey (dans les limites de la politique), désactiver un steering trop agressif pour ce SSID, et s’assurer que le firmware est à jour. Les équipes sécurité et réseau argumenteront. Elles le font toujours. Votre travail est d’apporter des preuves.

Trois mini-histoires en entreprise issues de la production

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

Le service financier se plaignait que « l’internet meurt toutes les dix minutes » pendant la clôture mensuelle. Cette phrase est un piège : elle invite tout le monde à regarder les graphiques du pare‑feu et la liaison ISP. Nous l’avons fait. Tout semblait en ordre. Pas de perte de paquets sur le WAN, pas de coupures alarmantes, rien d’évident.

Quelqu’un a finalement lancé un ping continu vers la passerelle du bureau depuis un des laptops affectés. Le ping avait une latence propre de 1–2 ms… jusqu’à exactement dix minutes après la dernière déconnexion, quand il est devenu muet pendant 10–15 secondes. Le WAN ne l’a jamais vu parce que le client n’était même pas sur le LAN durant l’événement. L’« internet » était innocent.

La mauvaise hypothèse était subtile : nous avons supposé que des erreurs applicatives signifiaient une panne en amont. Mais les logs (WLAN AutoConfig) disaient « disconnected by the driver ». Ce n’est pas un problème ISP. C’est votre radio, votre pilote, votre état d’alimentation.

Correction : nous avons désactivé l’économie d’énergie de l’adaptateur dans le Gestionnaire de périphériques et réglé le plan d’alimentation sans fil sur Performance maximale. Les coupures ont cessé instantanément. Plus tard nous avons découvert que l’image OEM avait poussé un profil batterie agressif sur tous les laptops, y compris des postes fixes dockés qui ne bougent jamais. Parfois le correctif le moins glamour est le bon.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre nous

Une autre organisation voulait améliorer l’autonomie batterie d’une flotte. Raisonnable. Ils ont activé le power save Wi‑Fi et augmenté l’agressivité du roaming parce que des employés se déplaçaient et se plaignaient de connexions collantes. Aussi raisonnable sur le papier.

Puis les tickets de support ont afflué : « le Wi‑Fi coupe pendant les appels ». Le motif était étrange — surtout visible sur Zoom/Teams, moins sur la navigation web. Symptomatique des micro‑pannes et des événements de réauth : les reprises TCP les cachent ; le média temps réel ne pardonne pas.

Nous avons extrait des logs de quelques machines et trouvé des déconnexions périodiques initiées par le pilote. Pas constantes, pas aléatoires. Périodiques. Le réglage de roaming agressif provoquait des scans fréquents et des tentatives de roaming dans un environnement où le band steering était activé. Le client essayait d’améliorer sa situation et finissait par se re‑keyer et se réassocier à répétition. On optimisait une métrique (vitesse de roaming) au détriment de la métrique humaine importante (stabilité).

Correction : nous avons baissé l’agressivité de roaming à « Low », désactivé l’U‑APSD sur les versions de pilote concernées, et réduit l’agressivité du steering sur le SSID voix. L’autonomie a légèrement diminué. La qualité des appels s’est améliorée drastiquement. La leçon n’était pas « ne jamais optimiser ». C’était « optimiser une variable à la fois, et mesurer le bon résultat ».

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

Un grand campus rapportait des coupures Wi‑Fi intermittentes « à peu près à la même heure chaque heure ». L’instinct initial était d’accuser la congestion RF : trop d’appareils, trop d’AP, trop de tout. L’équipe réseau avait des opinions tranchées. L’équipe desktop en avait de plus fortes.

La pratique ennuyeuse était la suivante : prendre un seul client, capturer une timeline d’événements horodatés, et la corréler avec les logs d’infrastructure. Pas « je pense ». Pas « on dirait ». Une timeline.

Ils ont collecté un rapport WLAN depuis des clients Windows, plus les logs du contrôleur pour les événements de deauth. Les heures de déconnexion s’alignaient avec une poussée périodique de politique de sécurité qui forçait la réauthentification pour un sous‑ensemble d’utilisateurs. Ce n’était pas généralisé parce que la politique ne concernait que certains VLAN et groupes d’identité. Ce détail comptait.

Correction : ils ont ajusté le comportement de réauth pour ne pas couper brutalement les sessions actives, et ils ont validé avec un déploiement progressif. Le hardware Wi‑Fi est resté identique. Les clients aussi. La différence était la gestion du changement et la corrélation. Banal, efficace, reproductible.

Erreurs courantes : symptômes → cause racine → correction

Voici les schémas que je vois souvent — surtout quand l’intervalle de coupure est suspectement régulier.

1) Coupures toutes les ~10 minutes uniquement sur batterie

Symptôme : Stable sur secteur, coupures périodiques sur batterie.

Cause racine : Le mode d’alimentation de l’adaptateur sans fil change avec le plan d’alimentation ; selective suspend / U‑APSD / SMPS devient agressif.

Correction : Mettre l’alimentation Wi‑Fi sur Performance maximale sur batterie ; désactiver la gestion d’alimentation NIC ; désactiver Power Save Mode / U‑APSD du pilote pour tester.

2) Coupures toutes les ~10 minutes sur un SSID mais pas un autre

Symptôme : Le Wi‑Fi invité fonctionne ; le Wi‑Fi corporate coupe (ou inversement).

Cause racine : Politique spécifique au SSID : réauth 802.1X, intervalle de rekey du groupe, band steering, ou fonctionnalités du contrôleur.

Correction : Comparez les logs : est‑ce que l’AP vous déauthentifie ? Si oui, ajustez reauth/rekey/steering sur ce SSID ou testez en WPA2-only/WPA3-only.

3) « Internet tombe » mais le ping vers la passerelle reste solide

Symptôme : L’appel Teams tombe, mais vous pouvez toujours pinguer le routeur.

Cause racine : Problème amont : DNS, rekey VPN, timeouts de session firewall, ou coupures WAN — pas une association Wi‑Fi.

Correction : Capturez un ping parallèle vers une IP externe et le timing des requêtes DNS. Inspectez les logs du client VPN ou du routeur WAN.

4) Les coupures corrèlent avec du roaming entre AP

Symptôme : Le BSSID change autour de la coupure ; vous ne bougez peut‑être même pas.

Cause racine : Roaming client trop agressif + steering AP + signal marginal.

Correction : Réduire l’agressivité du roaming ; verrouiller la bande préférée ; améliorer le placement des AP ; désactiver le steering pour ce SSID.

5) Coupures à intervalle fixe sur de nombreux appareils

Symptôme : Plusieurs utilisateurs rapportent des coupures périodiques similaires, souvent synchronisées.

Cause racine : Timer/politique d’infrastructure : reauth, rekey, optimisation RF programmée, bug de contrôleur, ou interférence périodique.

Correction : Corrélez avec les logs contrôleur/AP. Changez un timer à la fois et déployez progressivement.

6) Vous « avez réparé » en changeant les canaux, mais le problème est revenu

Symptôme : Le changement de canal aide temporairement ; la périodicité revient.

Cause racine : Le vrai coupable est la politique/power state du pilote ; le changement de canal a seulement modifié le timing ou forcé une reconnexion temporaire.

Correction : Arrêtez de chasser les canaux en premier. Prouvez les événements de la couche lien ; désactivez l’économie d’énergie côté client ; puis revenez à l’optimisation RF.

Listes de contrôle / plan étape par étape

Étape par étape : le plan « il me faut de la stabilité aujourd’hui »

Mesurer la panne : Lancez un ping vers votre passerelle par défaut pendant 20 minutes et notez si ça tombe à intervalles réguliers.
Récupérer les logs client : Rapport WLAN Windows ou journald/wpa_supplicant Linux pour la raison de déconnexion.
Désactiver l’économie d’énergie côté client :
- Windows : décocher « Autoriser l’ordinateur à éteindre ce périphérique », mettre Wireless Adapter Settings sur Performance maximale, désactiver Power Save Mode/U‑APSD du pilote.
- Linux : iw ... set power_save off, désactiver NetworkManager wifi.powersave.
Réduire le churn de roaming : Mettre l’agressivité de roaming sur Low ; verrouiller la bande préférée si le steering est en cause.
Retester pendant 30–60 minutes : Si le rythme de dix minutes a disparu, conservez le réglage et documentez‑le.
Si ça échoue toujours : Suspectez les timers rekey/reauth et la politique AP ; testez sur un SSID différent ou un hotspot pour isoler client vs réseau.

Checklist : preuves à fournir à l’équipe IT/réseau

Intervalle exact (par ex. 600 secondes) et horodatages d’au moins trois coupures.
Logs client montrant si la déconnexion était initiée par le pilote ou par l’AP.
BSSID/fréquence avant et après la coupure (preuve de roaming).
Si le ping vers la passerelle tombe (couche lien vs amont).
Version du pilote et version de l’OS.
Si le problème se reproduit sur un autre réseau (un hotspot téléphone fait un bon test).

Checklist : ce qu’il ne faut pas faire

Ne pas réinitialiser le routeur d’usine comme première action. C’est une coupure que vous vous infligez.
Ne changez pas cinq réglages à la fois puis déclarez victoire. Vous ne saurez jamais lequel a compté.
Ne supposez pas que « Wi‑Fi connecté » signifie « Wi‑Fi fonctionnel ». L’état d’association peut sembler sain tandis que le plan de données est misérable.

FAQ

1) Pourquoi ça se coupe exactement toutes les 10 minutes ?

Parce que quelque chose a un timer : transitions power‑save client, scans/decisions de roaming périodiques, rekey du groupe, ou réauth 802.1X. Dix minutes est un intervalle courant de politique.

2) Quel est le seul réglage pilote le plus courant qui corrige les coupures périodiques ?

Désactiver l’économie d’énergie Wi‑Fi agressive (Power Save Mode / U‑APSD / MIMO power save) et forcer la performance maximale. Cela élimine toute une catégorie de cas limites sommeil/réveil.

3) Désactiver l’économie d’énergie va‑t‑il ruiner ma batterie ?

Cela peut réduire l’autonomie, surtout sur les portables. Mais si le choix est « connectivité stable » vs « peut‑être 5–10 % de batterie », choisissez la stabilité d’abord, puis réajustez prudemment.

4) Cela pourrait‑il être un problème DNS à la place ?

Oui, mais le DNS ne chute pas normalement avec une cadence parfaitement de dix minutes. Si votre ping vers la passerelle par défaut tombe, ce n’est pas le DNS. Si le ping passerelle est OK mais que les résolutions échouent, alors investiguez le DNS.

5) Mon Wi‑Fi indique « Connecté, sécurisé » quand il se coupe. Comment ça se fait ?

L’interface n’est pas un packet capture. Vous pouvez rester associé alors que votre plan de données est bloqué à cause de buffering power‑save, bugs du pilote, ou événements de politique amont. Faites confiance aux logs et aux pings plutôt qu’aux icônes.

6) Est‑ce plus fréquent avec certaines puces ?

Les coupures périodiques peuvent arriver avec n’importe quel fournisseur, mais elles sont souvent signalées avec certains composants Intel et Realtek sur laptops quand les profils OEM de batterie et les valeurs U‑APSD/SMPS entrent en collision avec des AP spécifiques.

7) Dois‑je désactiver WPA3 pour corriger ça ?

Seulement en test contrôlé. Le mode de transition WPA3 (mixte WPA2/WPA3) peut être capricieux avec des clients plus anciens. Si désactiver WPA3 stabilise la connexion, la vraie correction est généralement une mise à jour firmware/driver ou passer à WPA2‑only ou WPA3‑only de façon cohérente.

8) Quelle différence entre roaming aggressiveness et band steering ?

L’agressivité de roaming, c’est la décision du client pour partir. Le band steering, c’est l’AP qui pousse ou force les clients vers une bande. Quand les deux sont agressifs, vous obtenez du ping‑pong.

9) Pourquoi la visioconférence souffre plus que la navigation web ?

La navigation tolère de courtes pertes de paquets via des retries et des buffers. L’audio/vidéo en temps réel est sensible au jitter et aux trous ; une reconnexion de 5–15 secondes est immédiatement perceptible.

10) J’ai changé des réglages et ça se coupe toujours. Et maintenant ?

Isolez : testez sur un hotspot téléphone (variable client seulement) et sur un autre laptop sur le même SSID (variable réseau seulement). Si un seul appareil échoue, concentrez‑vous sur pilote/OS. Si plusieurs appareils échouent, ciblez les timers/firmware/politique AP.

Étapes pratiques suivantes

Faites trois choses, dans l’ordre :

Prouvez où vit la coupure avec un ping vers la passerelle et des logs client. Si la passerelle tombe, c’est la couche lien Wi‑Fi, point final.
Désactivez l’économie d’énergie Wi‑Fi de bout en bout (plan d’alimentation OS + gestion d’alimentation du périphérique + paramètres avancés du pilote) et retestez pendant au moins 30 minutes.
Si la périodicité persiste, traitez‑la comme un timer de politique : rekey/reauth/steering. Recueillez horodatages et codes de raison, puis changez une variable réseau à la fois.

Une idée paraphrasée d’un spécialiste de la fiabilité convient ici : paraphrased idea — John Allspaw a maintes fois souligné que l’on apprend la fiabilité en enquêtant sur de vraies pannes, pas en devinant. C’est tout le jeu : mesurer, changer une chose, mesurer à nouveau.