Avec la version 8.8.13, Ubiquiti ne se contente pas d’aligner quelques correctifs pour ses bornes WiFi. L’éditeur rapproche les générations U6 et U7 dans une même branche logicielle, ajoute un lien mesh MLO sur les U7, permet à une borne maillée de changer d’uplink et introduit une nouvelle suppression du multicast.
Le mouvement est plus intéressant que le numéro de version. UniFi commence à traiter les U6 et U7 comme une même plateforme logicielle, tout en réservant les fonctions radio propres au WiFi 7 aux modèles capables de les exécuter. Pour les entreprises qui exploitent déjà un parc mélangé, cette convergence peut simplifier les évolutions et accélérer l’arrivée de fonctions communes.
La prudence reste nécessaire : 8.8.13 est une Release Candidate publiée le 28 octobre 2026, pas une version Official recommandée pour un déploiement généralisé. Certaines bornes — U7-LR, U6-LR et U6-Lite — ne sont pas encore prises en charge par cette branche. Voici donc les nouveautés à comprendre aujourd’hui, avant de décider lesquelles méritent un pilote.
Ce qu’il faut retenir
- Les bornes U6 rejoignent la même branche fonctionnelle que les U7 pour les nouveautés, améliorations et correctifs applicables à leur matériel.
- Les bornes U7 compatibles peuvent établir un lien mesh en utilisant simultanément les bandes 5 et 6 GHz grâce au MLO en mode STR.
- Mesh Uplink Roaming permet à une borne reliée sans fil de basculer vers un meilleur parent lorsque les conditions changent.
- Multicast Suppression ajoute deux niveaux de filtrage destinés à réduire la consommation de temps d’antenne par le multicast et le broadcast.
- Les serveurs RADIUS peuvent désormais être déclarés par leur nom DNS complet, ou FQDN, plutôt que seulement par une adresse IP.
- La version réduit aussi les pics de latence liés au scan des bornes voisines et corrige la perte de priorité des flux voix et vidéo sur les bornes WiFi 7.
- 8.8.13 reste une Release Candidate. Ubiquiti indique que la prise en charge des U7-LR, U6-LR et U6-Lite arrivera dans de futures versions.
U6 et U7 avancent désormais sur la même branche logicielle
C’est la nouveauté la plus structurante. Dans la note de version 8.8.13, Ubiquiti annonce que les U6 rejoignent la même trajectoire logicielle que les U7. Les deux générations doivent donc recevoir le même firmware et les mêmes fonctions lorsque le matériel le permet.
Cette formulation ne signifie pas qu’une U6 devient une borne WiFi 7. Elle ne gagne ni radio 6 GHz si elle n’en possède pas, ni MLO par mise à jour. La convergence concerne le socle logiciel : gestion du mesh, authentification, multicast, roaming, fiabilité du démarrage et correctifs réseau.
Pour un parc d’entreprise, le bénéfice potentiel est concret. Les sites équipés progressivement mélangent souvent U6 et U7 pendant plusieurs années. Une branche commune peut limiter les différences de comportement et éviter de maintenir deux calendriers de firmware. Elle peut aussi rendre plus cohérente la qualification d’un correctif qui concerne les deux générations.
Il faut toutefois vérifier la matrice modèle par modèle. La première Release Candidate n’inclut pas encore les U7-LR, U6-LR et U6-Lite. Et lorsqu’Ubiquiti parle de parité fonctionnelle, l’éditeur ajoute bien que les capacités dépendantes du matériel restent propres à chaque borne. Le firmware unifié simplifie la trajectoire ; il ne rend pas le parc homogène par magie.
Le mesh MLO utilise simultanément le 5 et le 6 GHz
Le MLO, pour Multi-Link Operation, est généralement présenté côté client. Un ordinateur ou un téléphone WiFi 7 peut maintenir plusieurs liens avec une même borne et choisir le meilleur pour transmettre. Nous avons détaillé ce fonctionnement dans notre présentation du WiFi 7 et dans l’analyse de l’UniFi E7 en entreprise.
8.8.13 applique cette logique au lien entre deux bornes U7. Ubiquiti annonce un mesh sur les bandes 5 et 6 GHz en MLO STR. STR signifie que les deux liens peuvent émettre ou recevoir simultanément. Le backhaul sans fil ne dépend donc plus d’une seule bande à un instant donné.
L’intérêt n’est pas seulement le débit maximal. Deux liens peuvent offrir davantage de marge lorsque l’une des bandes devient chargée ou subit une perturbation. Pour un site où le câble est provisoirement impossible — bâtiment classé, espace événementiel, chantier ou extension temporaire — le mesh peut devenir plus résilient.
Le 6 GHz a cependant une portée plus courte et traverse moins bien les obstacles que le 5 GHz. Un lien MLO performant demande donc une implantation radio sérieuse. Il ne corrigera pas une borne placée derrière plusieurs murs ou trop loin de son parent. La documentation UniFi sur le mesh maintient d’ailleurs une préférence claire pour une liaison Ethernet, recommande un signal d’au moins -60 dBm entre bornes et conseille de limiter le nombre de sauts sans fil.
Autre distinction importante : le mesh MLO entre bornes ne rend pas automatiquement les clients MLO. Le poste doit toujours être compatible, et l’activation du MLO sur un SSID impose le WPA3. Le nouveau backhaul et le MLO client sont deux usages séparés d’une même technologie.
Mesh Uplink Roaming choisit un meilleur parent
Une borne mesh était jusqu’ici fortement dépendante du parent choisi pour son uplink sans fil. 8.8.13 ajoute Mesh Uplink Roaming : la borne peut passer vers un meilleur uplink lorsque la topologie ou les conditions radio évoluent.
Cette fonction est utile dans un environnement temporaire ou changeant. Une borne parent peut redémarrer, être déplacée, devenir chargée ou subir davantage d’interférences. La borne enfant dispose alors d’un mécanisme pour rejoindre un chemin plus favorable au lieu de rester attachée à un lien dégradé.
Il ne faut pas confondre cette fonction avec le roaming des utilisateurs entre bornes. Ici, c’est l’uplink de la borne elle-même qui change de parent. Un bon basculement doit préserver les VLAN, le multicast et les flux des clients situés derrière la borne maillée. La même version corrige justement plusieurs problèmes de synchronisation du mesh, de trafic VLAN et de multicast derrière les bornes sans fil.
Le gain attendu est donc la continuité du backhaul, pas la disparition des contraintes du mesh. Chaque saut consomme du temps d’antenne et partage la capacité radio avec les clients. Pour un bureau permanent, une salle de réunion très utilisée ou de la voix sur WiFi, le câble reste la référence dès qu’il est réalisable.
Multicast Suppression veut protéger le temps d’antenne
Le multicast sert à la découverte et à la diffusion de services : AirPlay, Chromecast, Sonos, imprimantes, certains équipements audiovisuels et de nombreux objets connectés en dépendent. Sur un réseau filaire, ce trafic peut sembler léger. Sur le WiFi, il occupe du temps d’antenne et peut être transmis à des débits robustes mais faibles, ce qui pénalise tous les clients.
8.8.13 ajoute Multicast Suppression dans les réglages de capacité. La capture fournie par Ubiquiti présente deux modes :
- Conservative, destiné à empêcher les tempêtes de multicast et de broadcast ;
- Aggressive, qui bloque tout sauf DHCP et ARP, à moins d’autoriser explicitement un appareil.
Cette nouveauté complète les réglages déjà décrits dans la documentation des SSID UniFi, notamment Multicast Enhancement et Multicast and Broadcast Control. Elle ne doit pas être activée à l’aveugle : un filtrage agressif peut casser la découverte de téléviseurs, d’écrans de salle, d’enceintes ou de capteurs.
L’approche la plus sûre consiste à commencer sur un SSID sans dépendance audiovisuelle, observer le temps d’antenne et les flux, puis tester les services de découverte réels. Si un équipement doit rester joignable, son autorisation doit être documentée. L’objectif est de supprimer le bruit inutile, pas de gagner quelques points de capacité au prix d’un service devenu invisible.
RADIUS par FQDN : un petit changement utile aux architectures d’entreprise
8.8.13 permet de renseigner un serveur RADIUS par son nom de domaine complet, ou FQDN. Jusqu’ici, une adresse IP fixe était souvent nécessaire dans la configuration de la borne.
Pour une entreprise, un nom tel que radius.exemple.fr sépare la configuration WiFi de l’adresse réellement utilisée par le serveur. Une migration, un changement d’hébergement ou un basculement peut alors être préparé dans le DNS sans modifier chaque profil d’authentification. C’est particulièrement utile lorsque le RADIUS est exploité par une équipe centrale ou un prestataire distinct de l’équipe réseau.
Cette souplesse ajoute aussi une dépendance. Les bornes doivent résoudre le nom au bon moment, via des serveurs DNS disponibles depuis leur réseau de management. Le TTL, les adresses IPv4 ou IPv6 retournées, les certificats et le comportement pendant une panne DNS doivent être vérifiés. Un FQDN facilite l’évolution d’un service ; il ne constitue pas à lui seul une haute disponibilité.
Des améliorations moins visibles pour la latence, la voix et le roaming
La liste de correctifs montre aussi les priorités du firmware commun. Ubiquiti annonce avoir amélioré le scan en arrière-plan des bornes voisines pour réduire les pics de latence côté client. Ce scan est nécessaire à la connaissance de l’environnement radio, mais il ne doit pas provoquer de rupture perceptible pendant un appel ou une visioconférence.
La version corrige également la perte de priorité WiFi des flux voix et vidéo sur les bornes WiFi 7. Ce point est important : une hausse de débit brut ne compense pas une file de priorité mal conservée. Dans un bureau, la qualité d’un appel Teams, Meet ou Webex dépend davantage de la latence, de la gigue et des pertes que du résultat d’un test de débit.
Fast Roaming reçoit plusieurs correctifs : activation qui ne devenait effective qu’après un redémarrage, pertes de connectivité IPv6, broadcast et multicast, et problèmes de trafic après connexion. Ces changements prolongent le travail déjà observé dans UniFi AP 8.7.11, mais 8.8.13 les place désormais dans une branche appelée à servir les U6 comme les U7.
Enfin, Ubiquiti corrige deux fuites de VLAN : l’une vers le réseau de management pendant des changements de configuration, l’autre sur des ports Auto-Link avec Network Override. Même si l’article est centré sur les fonctions nouvelles, ces correctifs doivent peser dans la qualification de la version. Une segmentation ne se valide pas uniquement parce que les VLAN apparaissent correctement dans l’interface.
Ce que cette version change dans la trajectoire UniFi
La vraie nouveauté de 8.8.13 est la combinaison de trois mouvements.
Le premier est la convergence : U6 et U7 doivent avancer sur le même socle logiciel. Le deuxième est l’usage du WiFi 7 dans l’infrastructure elle-même : le MLO ne sert plus seulement au client, il relie aussi deux bornes. Le troisième est l’optimisation du temps d’antenne : roaming d’uplink, scan des voisins et suppression du multicast cherchent tous à rendre le réseau plus prévisible lorsque l’environnement devient dense ou changeant.
Cette trajectoire est cohérente pour les parcs mixtes. Elle peut prolonger l’intérêt des U6 pour les fonctions qui ne demandent pas de radio WiFi 7, tout en réservant le MLO mesh et le 6 GHz aux U7 compatibles. Elle évite aussi de résumer une migration vers U7 à une promesse de débit : les fonctions d’exploitation, de résilience et de maîtrise du trafic comptent tout autant.
Faut-il installer 8.8.13 maintenant ?
Pas sur l’ensemble d’un parc. La version est proposée sur le canal Release Candidate et Ubiquiti demande de changer explicitement le canal de firmware pour l’installer. Elle est pertinente sur quelques bornes de laboratoire ou sur un site pilote non critique, à condition de disposer d’un retour vers le canal Official.
Le pilote doit être choisi en fonction de la fonction à observer : deux U7 pour le mesh MLO, plusieurs parents possibles pour Mesh Uplink Roaming, un SSID contenant de vrais services de découverte pour Multicast Suppression, ou un RADIUS de test résolu par DNS. Il faut ensuite vérifier les usages — DHCP, DNS, authentification, VLAN, IPv6, appels, visioconférence et découverte audiovisuelle — plutôt que le seul état « connecté » dans UniFi.
Notre avis est donc favorable à l’évolution, mais prudent sur le calendrier. 8.8.13 donne une bonne lecture de la prochaine génération logicielle UniFi ; elle ne constitue pas encore une consigne de mise à jour générale. Le signal le plus important est la branche commune U6/U7. Les fonctions mesh MLO, roaming d’uplink et suppression multicast donnent ensuite des raisons concrètes de préparer des scénarios de test ciblés.
Questions fréquentes
Les bornes U6 gagnent-elles le WiFi 7 avec le firmware 8.8.13 ?
Non. Elles rejoignent la même branche logicielle que les U7 et reçoivent les fonctions applicables à leur matériel. Le 6 GHz, le MLO et les autres capacités radio restent dépendants du modèle.
Le mesh MLO remplace-t-il une liaison Ethernet ?
Non. Il peut améliorer la capacité et la résilience d’un lien sans fil compatible, mais le mesh partage le temps d’antenne et reste sensible au signal, aux obstacles et aux interférences. Ubiquiti continue de recommander une liaison filaire lorsque c’est possible.
Multicast Suppression peut-il bloquer AirPlay ou Chromecast ?
Oui, surtout en mode Aggressive si les appareils nécessaires ne sont pas autorisés. La fonction doit être testée avec les équipements et les protocoles de découverte réellement utilisés sur le site.
Toutes les bornes U6 et U7 peuvent-elles installer 8.8.13 ?
Non. La note de version indique que la prise en charge des U7-LR, U6-LR et U6-Lite sera ajoutée dans de futures versions. La compatibilité doit être vérifiée avant tout pilote.
Faire évoluer un réseau UniFi avec BoucheCousue
BoucheCousue peut inventorier votre parc U6/U7, analyser la couverture et le temps d’antenne, puis construire un pilote autour du mesh, du multicast, du roaming et de l’authentification RADIUS. Parlons de votre réseau WiFi.
Article préparé le 29 octobre 2026 à partir des informations officielles disponibles. La version 8.8.13 était alors publiée sur le canal Release Candidate ; son contenu et sa compatibilité peuvent encore évoluer avant une version Official.