Une carte réseau peut être tout à fait exacte et pourtant s’avérer inutile. Quand les clients, les points d’accès, les VLAN et les liens s’empilent, l’administrateur finit par chercher une aiguille dans un schéma qui montre tout — sauf ce qui compte vraiment. Avec UniFi Network 10.6, Ubiquiti rapproche la topologie, l’historique, la validation des changements et la détection des écarts : voici comment transformer ces fonctions en méthode de dépannage plutôt qu’en collection de boutons.
Contexte : avoir plus de visibilité ne suffit pas
Quand un utilisateur signale « le Wi-Fi est lent », la tentation est connue : ouvrir la topologie, zoomer, parcourir les clients, vérifier les voyants et espérer détecter le problème d’un coup d’oeil. Cela peut fonctionner sur un petit réseau. Sur un environnement multi-sites, la visibilité devient vite du bruit. Il est toujours bon d’éviter le bruit.
Le vrai problème n’est pas toujours l’absence de données. C’est l’absence de contexte, le contexte est clef : qu’est-ce qui a changé ? depuis quand ? sur quel segment ? est-ce un client isolé, un point d’accès instable ou une configuration différente de celle approuvée ?
La version 10.6 de l’application UniFi Network, annoncée fin août 2026, est intéressante précisément parce qu’elle traite cette chaîne opérationnelle. Topology Spotlight réduit la carte aux clients pertinents. Le time machine d’Unifi ajoute un historique aux ports. SafeOps étend la logique de test puis confirmation à des changements sensibles. Site Manager apporte Drift Inspector et la préparation à la haute disponibilité.
La nouveauté n’est donc pas « une interface plus jolie ». C’est la possibilité de passer de « je vois le réseau » à « je peux expliquer ce qui s’est passé et corriger sans perdre la main ».
Ce que UniFi Network 10.6 change concrètement
Topology Spotlight : réduire la carte aux événements
Topology Spotlight permet de mettre en évidence un groupe de clients et de réduire visuellement les éléments qui ne participent pas à l’analyse. Dans un grand site, cette différence est immédiate : au lieu de parcourir toute la topologie, l’équipe commence par un filtre — un VLAN, un site, un type de client ou un ensemble concerné par l’incident.
Ce n’est pas seulement un gain de confort. Une vue plus ciblée réduit le risque de modifier le mauvais équipement parce que plusieurs chemins se ressemblent à l’écran. Le support peut aussi partager une capture qui raconte quelque chose : les clients concernés, leur point d’accès, leur segment et le lien à vérifier.
Time Machine : remettre l’historique dans le dépannage
Les notes de version 10.6.97 ajoutent Time Machine à la vue Radios pour examiner, sur les dernières 24 heures, des métriques d’usage, des changements de configuration et des événements radio. Port Manager Time Machine s’étend à tous les ports et ajoute un filtre pour les appareils qui se reconnectent fréquemment.
Cette profondeur reste courte, mais elle change la conversation. Au lieu de demander « est-ce encore lent ? », l’équipe peut demander : « qu’est-ce qui s’est passé avant le décrochage ? »
Pour le Wi-Fi, Channel AI peut également exécuter une optimisation nocturne avec une sélection de radios configurable. C’est utile dans un environnement dense, à condition de traiter l’automatisation comme une hypothèse à mesurer, pas comme une promesse magique. Un canal qui paraît meilleur pour l’algorithme n’est pas forcément le meilleur choix pour un réseau qui transporte de la voix, des terminaux mobiles ou des équipements sensibles aux microcoupures.
SafeOps, Drift Inspector et le score de haute disponibilité : corriger sans improviser
SafeOps étend le mécanisme Test & Confirm à des réseaux VPN et de management. L’idée est simple et saine : une modification est appliquée, la connectivité est vérifiée, puis la configuration est confirmée ou rétablie si le test échoue. L’annonce Ubiquiti cite notamment les changements de VLAN de management et la protection par retour à la dernière configuration fonctionnelle.
Site Manager ajoute aussi Drift Inspector dans les Blueprints. L’équipe peut distinguer une exception locale approuvée d’un écart accidentel par rapport au modèle de site. Le High Availability Readiness Score donne, de son côté, une lecture rapide des points uniques de défaillance côté ISP, alimentation et passerelle.
Ces fonctions ne remplacent pas une architecture résiliente. Elles rendent simplement plus difficile le fait de confondre les possibilités de failles entre elles.
Comment l’utiliser dans un cas réel
Scénario : huit sites, une équipe IT et trop de tickets
Imaginons une PME répartie sur huit sites. Chaque implantation possède plusieurs points d’accès, des VLAN utilisateurs et invités, des équipements de téléphonie ou de visioconférence, et une passerelle UniFi. L’équipe IT reçoit régulièrement des tickets de lenteur, mais les incidents sont souvent terminés avant qu’un technicien puisse les observer.
L’objectif n’est pas d’activer toutes les options le même jour. Il est de construire un petit runbook reproductible.
Étape 1 : créer une ligne de base avant la mise à jour
Choisissez un site représentatif et notez :
- la version UniFi OS et la version de l’application Network ;
- les modèles et versions de firmware des passerelles, switches et points d’accès ;
- les SSID, VLAN et usages sensibles ;
- les changements planifiés dans les prochaines 24 heures ;
- les indicateurs qui permettront de dire « le réseau va mieux ».
Faites une sauvegarde et planifiez l’opération dans une fenêtre où quelqu’un peut intervenir localement ou hors bande. Une fonction de rollback n’annule pas le besoin d’un accès de secours.
Étape 2 : utiliser Spotlight pour cadrer le symptôme
À l’ouverture d’un ticket, ne commencez plus par la vue globale. Filtrez d’abord les clients touchés, puis comparez leur point d’accès, leur VLAN et leur chemin vers la passerelle. Si un seul groupe est concerné, laissez les autres équipements hors champ.
Documentez la question initiale : « les clients du SSID invité sur le site B perdent-ils leur session ? » est beaucoup plus exploitable que « le Wi-Fi du site B est bizarre ».
Étape 3 : remonter les 24 dernières heures
Consultez Time Machine sur les radios et les ports associés. Cherchez une modification de canal, une série de reconnexions, un port qui flap, un changement de configuration ou une dégradation apparue juste avant les signalements.
Si le symptôme est intermittent, exportez dans le ticket l’heure approximative et les observations. L’historique n’a de valeur que si l’équipe peut le rapprocher de l’expérience utilisateur, d’un changement ou d’un événement externe.
Étape 4 : automatiser avec mesure, pas avec foi
Activez l’optimisation nocturne Channel AI sur un périmètre pilote et définissez une mesure simple : nombre de reconnexions, plaintes, débit médian ou temps de roaming selon le cas d’usage. Prévenez les équipes qu’un changement de canal peut provoquer une courte interruption.
Les retours associés aux notes de version montrent que certains administrateurs s’interrogent encore sur le comportement du mode automatique, notamment le changement effectif de canal et les environnements avec un seul point d’accès. Ce sont de bons rappels : une option visible dans l’interface doit être vérifiée dans le contexte réel avant d’être déployée partout.
Étape 5 : sécuriser les changements sensibles
Pour une modification de VLAN de management, de VPN ou de politique réseau :
- capturez la configuration de départ et le chemin d’accès de secours ;
- lancez la modification avec Test & Confirm lorsque le matériel et la version le permettent ;
- vérifiez la connectivité des équipements de management, pas seulement celle d’un poste utilisateur ;
- confirmez uniquement après le test ;
- consignez le résultat et l’heure dans le journal de changement.
À l’échelle multi-sites, utilisez ensuite les Blueprints et Drift Inspector pour séparer les exceptions approuvées des écarts non expliqués. Une exception qui n’a pas de propriétaire finit presque toujours par devenir la nouvelle norme.
Étape 6 : transformer le score en test de continuité
Le score High Availability Readiness est un point de départ de discussion. Pour chaque site, demandez : que se passe-t-il si l’ISP tombe ? si l’alimentation du switch principal est coupée ? si la passerelle ne revient pas ?
Ajoutez au score une preuve : date du dernier test, durée de basculement, services réellement vérifiés et personne responsable. Un indicateur de préparation ne remplace pas un exercice.
Limites et points de vigilance
Tout n’est pas disponible de manière uniforme. Ubiquiti précise que Multicast Suppressor et Port Locking arrivent d’abord en Early Access dans sa présentation de Network 10.6 ; les notes de version indiquent en parallèle des prérequis de firmware — UAP 8.8 ou ultérieur pour Multicast Suppressor, firmware de switch 7.6 ou ultérieur pour le verrouillage de port. Vérifiez le canal de diffusion, la version de l’application et les modèles concernés avant d’inscrire une fonction dans un plan de production.
Time Machine apporte un historique utile, mais limité à une fenêtre de 24 heures dans les éléments documentés. Ce n’est pas un système de rétention longue ni une preuve forensique complète. Pour les incidents récurrents, exportez les faits utiles vers votre outil de suivi ou votre supervision.
SafeOps réduit le risque d’une mauvaise configuration dans l’environnement UniFi ; il ne répare pas un câble, un opérateur en amont, un firmware incompatible ou une dépendance externe. Gardez un accès de secours, une sauvegarde et un plan de retour arrière.
Enfin, les notes de version recommandent UniFi OS Server pour les déploiements auto-hébergés afin de bénéficier de l’expérience de plateforme et des intégrations les plus récentes. Cette recommandation mérite une vérification de compatibilité, de sauvegarde et d’exploitation avant toute migration improvisée.
Élargir : moins de dépannage héroïque, plus d’exploitation documentée
Une équipe réseau ne gagne pas seulement du temps quand elle trouve une panne plus vite. Elle gagne de la sérénité quand la panne est résolue en suivant un workflow précis.
Network 10.6 pousse UniFi dans cette direction : filtrer avant d’observer, consulter l’historique avant de modifier, tester avant de confirmer, comparer au modèle avant de déclarer une dérive. La technologie devient un partenaire d’exploitation, pas un substitut au raisonnement.
Cela change aussi la relation avec les utilisateurs. Au lieu de répondre « nous avons redémarré le point d’accès », l’équipe peut expliquer : « les reconnexions ont commencé après telle modification, elles touchent tel groupe, et nous suivons tel indicateur depuis le retour arrière ». La confiance naît rarement d’une interface spectaculaire. Elle naît d’une explication claire et précise qui donne du sens à l’action de l’équipe technique mais aussi au client qui conçoit l’action de l’équipe technique.
Conclusion
Le réseau n’était pas forcément invisible. Il était simplement trop large pour être interprété rapidement et bénéficiait de trop peu d’historique pour raconter ce qui venait de se passer.
UniFi Network 10.6 apporte les briques d’une méthode plus calme : une topologie focalisée, un historique court mais exploitable, des changements réversibles et une lecture des écarts entre sites. Le principal changement n’est pas que la console fasse davantage de choses ; c’est que l’équipe puisse prendre de meilleures décisions avec moins de suppositions.
Travaux pratiques — Sur un seul site, créez un mini-runbook en six lignes : symptôme, filtre Spotlight, historique Time Machine, changement récent, action SafeOps et preuve de retour à la normale. Testez-le sur le prochain incident Wi-Fi et mesurez le temps gagné avant d’activer davantage d’automatisation.
Laisser un commentaire