Le Wi‑Fi 8, c’est la latence, pas la vitesse : le playbook réseau du bureau du CTO

Vos ingénieurs pensent que le modèle est bête. Il ne l’est pas. C’est votre Wi‑Fi de bureau. Comme rapporté cette semaine, le Wi‑Fi 8 (802.11bn) est la première mise à niveau sans fil depuis des années qui ne court pas après des vitesses tape‑à‑l’œil — il optimise la fiabilité et la latence. C’est exactement ce dont vos workflows lourds en IA ont besoin. Si les flux de jetons saccadent, si la recherche de code paraît molle, ou si les outils de pair‑programming prennent du retard pendant le stand‑up, neuf fois sur dix, le goulot d’étranglement, c’est le temps d’antenne, la contention ou le bufferbloat — pas votre LLM.

Ce qui change réellement avec le Wi‑Fi 8

Le Wi‑Fi 7 (802.11be) a misé sur le multi‑link et l’élargissement des canaux. Le Wi‑Fi 8 (802.11bn, Ultra High Reliability) renforce la performance exploitable sous charge : planification plus serrée, meilleure gestion des interférences, et comportement plus déterministe entre bandes. Les fournisseurs auront des discours marketing différents, mais l’idée est claire : moins de jitter, moins de pics, une latence p95 plus régulière. Cela compte pour des plateaux d’ingénierie modernes où 50–200 ordinateurs portables diffusent simultanément des jetons, collaborent en direct et synchronisent des dépôts.

Deux implications pratiques pour vous :

• Faites évoluer votre KPI de la valeur de crête vers la latence et le jitter p95/p99. Si votre lien atteint 1,8 Gbps dans un test de couloir mais 140 ms de latence p95 pendant un stand‑up, vous perdez.
• Vous pouvez capter 80 % des bénéfices du Wi‑Fi 8 dès aujourd’hui avec un bon design 6 GHz, une gestion de files d’attente adaptée et de la discipline côté clients. Vous n’avez pas à attendre les badges 802.11bn.

Cartographiez votre charge réelle : ce n’est pas la bande passante, c’est la simultanéité

La plupart du trafic dev à l’ère de l’IA n’est pas « gros ». Il est bavard et interactif :

• Diffusion de jetons : 1–3 flux SSE/WS concurrents par ingénieur, quelques kbps mais très sensibles au jitter.
• Appels vidéo avec IDE partagés : 1–2 flux temps réel concurrents par ingénieur, débit variable, sensibles à la perte de paquets.
• Synchronisation en arrière‑plan (Git, registres de paquets, conteneurs) : en rafales, opportuniste ; peut affamer le temps réel sans discipline de file.

L’objectif de conception n’est pas « 3 Gbps à chaque bureau ». C’est « une latence p95 inférieure à 25 ms avec 70 % d’utilisation du temps d’antenne pour plus de 100 flux temps réel concurrents ».

Le cadre de décision d’un CTO : concevez pour la latence maintenant, soyez prêt pour le Wi‑Fi 8 ensuite

1) Spectre et plan de canaux : utilisez le 6 GHz, mais ne soyez pas gourmand

• Adoptez 6 GHz Low‑Power Indoor (LPI) dès maintenant. Aux États‑Unis, le 6 GHz offre jusqu’à 14 canaux 80 MHz non chevauchants. C’est un cadeau — utilisez‑le pour réduire la contention, pas pour courir après des « tests à 320 MHz ».
• Préférez des canaux de 80 MHz en 6 GHz sur des plateaux denses. Des canaux plus larges (160/320) agrandissent les domaines de collision et augmentent en réalité la latence p95 quand l’étage est chargé.
• Maintenez le 5 GHz en 40–80 MHz avec une planification DFS soignée ; réservez le 2,4 GHz aux équipements hérités/IoT uniquement.
• Désactivez les débits hérités. En 2,4 GHz, coupez 1/2/5,5/11 Mbps. En 5 GHz, désactivez 6/9 Mbps et envisagez 12 Mbps minimum. Les clients « collants » torpillent le temps d’antenne.

2) Densité des points d’accès et backhaul : planifiez pour le temps d’antenne, pas pour les barres de signal

• Visez au plus 30–40 clients actifs par radio d’AP pour les zones sensibles à la latence. Pour un plateau de 120 ingénieurs, cela représente typiquement 4–6 AP en 6 GHz plus un recouvrement en 5 GHz.
• Utilisez un backhaul 2,5 GbE par AP comme base ; 5 GbE pour les déploiements très denses. Ne montez pas des AP tri‑bande Wi‑Fi 7/8 sur du 1 GbE en espérant des miracles.
• Dimensionnez correctement le PoE. Les AP tri‑bande modernes consomment souvent 20–31 W. La norme 802.3at (PoE+) fournit jusqu’à 30 W ; certains modèles exigent 802.3bt. Vérifiez les fiches techniques de vos commutateurs.

3) SSID et sécurité : mettez fin à la prolifération

• Chaque SSID consomme du temps d’antenne à cause des balises — environ 0,5–1 % par SSID et par bande. Limitez‑vous à 2–3 SSID par bande.
• Utilisez WPA3‑Enterprise avec EAP‑TLS et des certificats par appareil pour les ordinateurs portables du personnel. Réservez un SSID distinct, limité en débit, pour les invités.
• Isoler l’IoT. N’autorisez pas les lecteurs de badges et les TV de salles de réunion à partager les politiques de temps d’antenne avec les ordinateurs des ingénieurs. SSID séparé, VLAN séparé, et si possible, AP séparés en 2,4 GHz.

4) Gestion des files et QoS : combattez d’abord le bufferbloat

• Mettez en œuvre du Smart Queue Management (SQM) en bordure WAN avec FQ‑CoDel ou Cake. Rien que cela réduit souvent la latence p95 de 30–70 % pendant les builds et déploiements.
• Mappez correctement DSCP vers WMM : EF (46) vers Voice, AF41/AF31 vers Video, tout le reste en Best Effort. Ne marquez pas tout en EF, sinon vous ferez s’effondrer la file.
• Activez l’airtime fairness sur les AP ; privilégiez les fournisseurs qui exposent la profondeur de file et la télémétrie par catégorie d’accès (AC).

5) Itinérance et puissance : rendez cela banal

• Activez 802.11k/v et 802.11r (fast BSS transition) pour les ordinateurs portables qui le supportent. Votre session de live coding ne devrait pas se figer en passant d’un huddle room à l’autre.
• Ajustez la puissance d’émission à la baisse pour encourager l’itinérance. Des AP surpuissants provoquent des clients collants et des problèmes de nœud caché.

6) Discipline côté clients : fixez la barre pour ordinateurs et téléphones

• Standardisez sur des NIC compatibles 6 GHz (p. ex., Intel AX211/BE200 ou équivalents). D’ici 2026, la plupart des portables premium seront en 6 GHz ; imposez‑le dans vos achats.
• Désactivez les hotspots privés sur les téléphones. Le partage de connexion personnel ruine les plans RF et perturbe l’itinérance.
• Forcez l’usage des codecs matériels dans les apps de visioconférence quand c’est possible. L’encodage logiciel fait grimper la charge CPU et la latence de file.

7) Aménagement des bureaux : les câbles comptent toujours

• Tirez suffisamment de Cat6A pour supporter 2,5/5 GbE et le PoE par emplacement d’AP. Supposez une densité d’un AP pour 800–1 200 sq ft en 6 GHz, davantage dans les bâtiments très vitrés ou anciens.
• Fournissez deux liaisons montantes 10 GbE agrégées par IDF vers le cœur. Une fois le RF stabilisé, vous ne voulez pas que les uplinks des commutateurs deviennent votre nouveau goulot.

Mesure : adoptez des SLO de latence, pas des speed tests

Les speed tests, c’est du théâtre. Adoptez des métriques qui corrèlent avec la satisfaction des développeurs :

• RTT p95 sur le LAN sous charge : visez 15–25 ms. Testez avec flent ou un ping contrôlé tout en saturant le trafic d’arrière‑plan.
• RTT p95 WAN vers vos edges d’inférence IA : fixez un SLO (p. ex., ≤ 60 ms vers votre POP d’inférence le plus proche) et alertez en cas de dérive.
• Jitter p95 pour la visioconférence : en‑dessous de 20 ms paraît « vif ».
• Utilisation du temps d’antenne par radio : tenez 60–70 % sans pics de p95. Si la p95 grimpe au‑delà de 80 ms à 50 % d’occupation, votre gestion de file ou votre plan de canaux est en cause.

Des outils réellement utiles :

• flent (tests RRUL) pour exposer le bufferbloat dans tous les sens.
• iperf3 pour des vérifications de débit contrôlées, par bande et par AP.
• Heatmaps RF des fournisseurs, plus des surveys Ekahau/NetSpot pour la conception initiale et la validation.
• Télémétrie des AP pour la profondeur de file par AC, les taux de retry et la répartition des clients par bande.

Considérations spécifiques à l’IA souvent oubliées

Les flux de jetons sont petits mais fragiles

Chaque développeur peut maintenir 2–4 flux SSE/WS concurrents. Pris isolément, ils ne font que quelques kilobits, mais leur sensibilité aux micro‑bursts est élevée. Si votre latence p95 augmente de 80–120 ms pendant un pull d’image conteneur, l’utilisateur perçoit que le modèle « réfléchit » ou « devient plus bête ». C’est un problème de mise en file d’attente, pas un problème de modèle.

Le cache en périphérie n’est plus optionnel

Placez vos points de terminaison de modèles/routeurs au plus près — régionalement ou via des accélérateurs on‑prem quand c’est pertinent. Gratter 20–30 ms sur la RTT WAN peut réduire de 10–20 % le temps de réponse perçu du modèle sur des tâches interactives. Pour les copilotes internes et la recherche de code, des proxys locaux plus des keep‑alives HTTP/2 évitent le churn de connexions.

Le trafic d’arrière‑plan doit être bridé

Les registres de conteneurs, les gestionnaires de paquets et les agents d’indexation rempliront toutes les files que vous leur donnez. Limitez le débit d’arrière‑plan par appareil (p. ex., 20–50 Mbps) et appuyez‑vous sur le SQM pour faire passer les flux temps réel en priorité. Votre « AP le plus rapide » ne peut pas compenser un exécuteur CI non bridé qui tire 15 Go d’images pendant la pause déjeuner.

La sécurité sans tuer la latence

• WPA3‑Enterprise (EAP‑TLS) avec des certificats de courte durée et des profils imposés par MDM vous donne une identité par appareil sans jeux de portails captifs. Les portails captifs gaspillent du temps d’antenne et cassent l’itinérance rapide.
• Microsegmentez en L3/L4, pas en grands domaines d’itinérance L2. Gardez les domaines de broadcast petits. Passerelles mDNS/Bonjour pour les rares services qui en ont besoin ; supprimez le reste.
• Privilégiez des ACL à vitesse filaire sur les commutateurs d’accès et les AP. N’envoyez pas en hairpin chaque paquet via un pare‑feu cloud si votre politique ne l’exige pas.

Coûts et calendrier : à quoi vous attendre

• AP : 700–1 200 $ par unité tri‑bande entreprise, plus 150–300 $ pour la pose et le câblage.
• Commutation : les ports d’accès 2,5/5 GbE PoE+ ou PoE++ coûtent 90–150 $ de plus par port que le 1 GbE ; uplinks cœur 10/25 GbE selon besoin.
• Survey et conception : 5–20 k$ ponctuels selon le nombre d’étages et la complexité RF.
• Calendrier Wi‑Fi 8 : premières solutions entreprise en 2026–2027, avec les NIC clients qui suivront. Ne bloquez pas votre déploiement 6 GHz en attendant des logos ; vous ajouterez des fonctions firmware au fil de leur maturité.

Un plan d’exécution 30‑60‑90 jours

Jours 0–30 : établir la base et stopper l’hémorragie

• Instrumentez : ajoutez des tests flent à vos contrôles réseau de bureau ; exportez RTT p95 et jitter vers votre tableau NOC.
• Mettez en place le SQM en bordure WAN avec FQ‑CoDel ou Cake. Si votre pare‑feu ne sait pas le faire, insérez un shaper dédié en ligne.
• Réduisez les SSID à maximum trois par bande. Désactivez les débits hérités. Activez l’airtime fairness et l’itinérance rapide.
• Fixez une barre d’approvisionnement : uniquement des NIC compatibles 6 GHz pour les nouveaux ordinateurs portables.

Jours 31–60 : réarchitecturer pour le 6 GHz

• Élaborez un plan RF prédictif pour le 6 GHz avec des canaux de 80 MHz. Validez par un survey ciblé.
• Mettez à niveau la commutation si nécessaire vers du 2,5 GbE PoE+ et assurez au moins deux liaisons 10 GbE vers le cœur par IDF.
• Séparez l’IoT sur 2,4 GHz avec un SSID/VLAN distinct. Imposer l’onboarding des appareils par certificats.
• Pilotez un seul plateau d’ingénierie : ciblez une RTT LAN p95 ≤ 25 ms aux heures de stand‑up. Itérez le plan de canaux en conséquence.

Jours 61–90 : durcir et définir des SLO

• Déployez le 6 GHz sur les étages restants. Tenez un playbook vivant des placements d’AP et niveaux de puissance éprouvés.
• Publiez des SLO de latence pour le réseau de bureau : p. ex., RTT LAN p95 sous charge ≤ 25 ms ; WAN vers l’edge IA le plus proche ≤ 60 ms ; jitter de visioconférence p95 ≤ 20 ms.
• Automatisez des tests continus (RRUL horaire, marche d’itinérance quotidienne) et alertez en cas de violation des SLO.
• Pré‑allouez un budget pour des mises à jour firmware 802.11bn ou des remplacements d’AP en 2027. Choisissez des fournisseurs avec une feuille de route Wi‑Fi 8 crédible.

Arbitrages à reconnaître

• Des canaux plus larges ne sont pas toujours meilleurs. 160/320 MHz est superbe en démo fournisseur, puis s’effondre à 15 h. En bureau réel, 80 MHz gagne souvent sur la p95.
• Plus d’AP n’est pas toujours mieux. Des déploiements trop denses sans discipline de puissance/canaux causent des interférences co‑canal et une latence plus mauvaise.
• La QoS peut nuire si elle est mal appliquée. Un marquage EF excessif affame le Best Effort et force des retransmissions TCP qui dégradent fortement la réactivité perçue.
• Sécurité vs itinérance. EAP‑TLS et 802.11r fonctionnent bien ensemble sur des stacks modernes ; les portails captifs et les danses NAC par SSID, rarement.

Pourquoi c’est crucial pour votre feuille de route IA

Quand votre équipe dit « le modèle local est pire que l’API », mesurez le RF. Si la latence p95 dans vos bureaux passe de 20 ms à 120 ms chaque fois que quelqu’un lance un pull de conteneur, vos agents paraîtront « plus bêtes », votre recherche de code paraîtra « plus faible », et vos sessions de pair‑programming glisseront du temps réel au gênant. La promesse du Wi‑Fi 8, c’est une latence stable et déterministe ; votre rôle est de créer les conditions pour que ces gains se matérialisent.

Choisissez des partenaires qui savent exécuter

Ce n’est pas une mise à niveau « on installe et on oublie ». C’est une discipline de conception. Travaillez avec des ingénieurs réseau à l’aise avec la planification 6 GHz, le SQM et des SLO temps réel — pas juste le débit de crête. Demandez aux fournisseurs la p95 sous charge, pas des tests de vitesse de couloir. Et ne lancez pas un nouveau pilote IA tant que vos étages ne tiennent pas ≤ 25 ms de RTT LAN p95 aux heures de pointe. Vos modèles paraîtront soudainement bien plus intelligents.

Points clés à retenir

• Le Wi‑Fi 8 déplace l’accent de la vitesse de crête vers une latence prévisible — exactement ce qu’exigent les workflows lourds en IA.
• Vous pouvez obtenir l’essentiel des bénéfices dès maintenant avec un design 6 GHz solide, du SQM et des standards côté clients.
• Concevez selon des SLO de latence et de jitter p95, pas pour des Gbps de prestige.
• Utilisez 80 MHz en 6 GHz, limitez les SSID à trois par bande et maintenez moins d’~40 clients actifs par radio.
• Mettez en place du SQM (FQ‑CoDel/Cake), un mappage DSCP→WMM correct et l’itinérance rapide (802.11k/v/r).
• Budgétez pour du backhaul 2,5/5 GbE, des uplinks 10 GbE et une densité d’AP réaliste (1 pour 800–1 200 sq ft).
• Mettez en œuvre un plan sur 90 jours : établir la base et le SQM, piloter le 6 GHz, puis publier des SLO de latence et passer à l’échelle.