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 :

1. capturez la configuration de départ et le chemin d’accès de secours ;
2. lancez la modification avec Test & Confirm lorsque le matériel et la version le permettent ;
3. vérifiez la connectivité des équipements de management, pas seulement celle d’un poste utilisateur ;
4. confirmez uniquement après le test ;
5. 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.

Sources consultées

• Ubiquiti — Introducing UniFi Network 10.6
• Ubiquiti Community — UniFi Network Application 10.6.97
• Ubiquiti — What’s New
• Dong Knows Tech — UniFi Network 10.6

Qui aime gérer un changement de réseau à distance sans aucune angoisse ? La gestion d’un réseau sensible et complexe qui se situe à 500 kilomètres oblige à bien réfléchir et à soupeser le pour et le contre. Avec UniFi Network 10.5, Ubiquiti s’attaque enfin à une douleur très concrète : le moment où une équipe modifie un réseau et sait qu’une petite erreur peut se transformer en longue journée.

Contexte : l’origine du vrai problème

Le problème n’est pas seulement la complexité technique. Il vient aussi du fait que beaucoup d’équipes administrent des environnements de plus en plus distribués avec des marges de manœuvre de plus en plus faibles.

Une PME multi‑sites, une école, un commerce avec plusieurs points de vente : tout le monde veut de la visibilité, de la rapidité et moins d’interruptions. Mais dans beaucoup de cas, les changements réseau restent émotionnellement coûteux. Pourquoi ? Parce qu’un VLAN mal appliqué, un mauvais paramètre sur un switch ou une modification poussée trop vite peut couper l’accès précisément à l’outil dont vous avez besoin pour corriger le problème.

On présente souvent le réseau comme une question d’architecture. C’est vrai. Mais c’est aussi une question de sérénité opérationnelle. Et cette dimension est trop souvent sous-estimée.

Ce que Ubiquiti change concrètement

UniFi Network 10.5 introduit plusieurs briques qui vont dans le bon sens, notamment :

• Test & Confirm, qui évite de considérer un changement comme définitif tant que les équipements clés ne confirment pas le bon retour de connectivité ;
• un mécanisme de rollback automatique pour revenir à l’état précédent si la modification casse l’accès ;
• des améliorations de stabilité et de comportement réseau comme Link Debounce et Auto STP Edge ;
• une meilleure visibilité, dans la continuité des évolutions récentes d’UniFi sur la topologie, la chronologie d’activité et la visibilité d’infrastructure.

Ce que cela change est simple à formuler : l’interface ne sert plus seulement à configurer, elle commence à mieux protéger l’administrateur contre certaines erreurs de déploiement.

Utilisation dans la vie réelle

Imaginons un réseau de huit sites avec une petite équipe IT centrale. Chaque site dépend d’un accès distant, d’un ou deux switches, de bornes Wi‑Fi et d’une passerelle. Jusqu’ici, chaque changement un peu sensible — segmentation, politique Wi‑Fi, modification d’uplink, nettoyage d’un port profile — crée la même tension : combien de temps d’interruption en cas d’erreur ?

Avec UniFi 10.5, une méthode plus saine devient possible :

1. identifier les changements réellement risqués et les faire passer en priorité par un scénario Test & Confirm ;
2. documenter quelles confirmations doivent être observées avant de considérer le changement comme validé ;
3. profiter des vues de topologie et de visibilité d’infrastructure pour vérifier les dépendances avant la modification ;
4. prévoir un mini runbook de retour arrière, même si le rollback automatique existe ;
5. utiliser un site pilote ou une plage horaire restreinte pour les premiers déploiements sensibles.

L’intérêt n’est pas de “faire plus de changements”. L’intérêt est de faire les changements importants avec moins de stress, plus de méthode.

Limites et points de vigilance

Attention, un rollback n’est pas une permission de travailler à la légère.

D’abord, il faut comprendre ce que le mécanisme couvre réellement dans votre contexte. Tous les incidents ne se ressemblent pas.

Ensuite, la visibilité n’est utile que si l’équipe sait la lire. Une topologie plus riche, un historique plus détaillé ou des règles plus intelligentes ne remplacent pas la discipline de documentation si souvent traitée par le mépris.

Enfin, dans les environnements multi‑sites, il reste indispensable de distinguer ce qui relève d’une amélioration de confort et ce qui relève d’un vrai filet de sécurité. Les deux sont utiles. Mais les confondre expose à de mauvaises décisions.

Élargir : ce que cela change dans l’organisation

Le sujet est plus profond qu’une version logicielle.

Quand un outil réseau commence à intégrer des mécanismes de confirmation, de retour arrière et de meilleure lisibilité, il pousse les équipes à sortir d’une culture du « je connais mon infra par cœur » pour aller vers une culture de procédures partagées.

Une infrastructure robuste n’est pas seulement une infrastructure qui tient. C’est une infrastructure que plusieurs personnes peuvent comprendre, faire évoluer et dépanner sans dépendre d’un seul cerveau disponible au bon moment.

Conclusion

Le problème de départ n’est pas abstrait : chaque changement réseau à distance porte une part de risque, de stress et parfois d’improvisation. Avec UniFi 10.5, Ubiquiti apporte une réponse très concrète en sécurisant davantage la validation des changements et le retour arrière.

Le vrai bénéfice n’est pas seulement technique. C’est la possibilité de transformer une culture de maintenance nerveuse en une pratique un peu plus calme, plus documentée et plus transmissible. Loin d’être un petit gain, donc.

Travaux pratiques

Choisissez un changement réseau modérément risqué sur un site pilote — par exemple une modification de profil de port ou d’uplink — et testez-le avec un scénario documenté autour de Test & Confirm. Si votre procédure reste floue malgré l’outil, vous avez trouvé le vrai chantier à ouvrir.

Il y a encore trop d’équipes IT qui vivent le déploiement Apple comme une succession de petites urgences. Un Mac à préparer vite. Un iPhone à réinitialiser. Un profil qui ne passe pas. Une app qui manque le jour de l’arrivée d’un collaborateur.

Et si le vrai problème n’était pas le nombre d’appareils… mais l’absence de méthode claire ? Avec Apple Business, le nouveau nom d’Apple Business Manager, Apple pousse une idée simple : la gestion d’un parc Apple ne devrait plus être un chantier artisanal. Elle devrait devenir un système lisible, répétable et beaucoup moins dépendant des héros du service informatique.

Dans cet article, l’idée n’est pas de vendre une promesse magique. L’idée est plus humble que ça : comprendre ce que ce virage change concrètement, où il peut faire gagner du temps, et pourquoi il oblige aussi à revoir le rôle du MDM dans votre organisation.

Contexte : où est le vrai problème ?

Quand on entend : « notre MDM est compliqué », il s’agit rarement du vrai sujet.

Le vrai sujet, ce n’est pas seulement l’enrôlement. Ce n’est pas non plus la console. Le vrai sujet, c’est l’accumulation de petites décisions mal planifiées : qui prépare les machines, qui attribue les apps, qui gère les profils, qui documente les exceptions, qui arbitre quand la pratique demande une dérogation.

Résultat ?

• L’onboarding dépend d’une personne clé.
• La conformité varie d’une équipe à l’autre.
• Les réglages « temporaires » deviennent permanents.
• Le support passe son temps à corriger des écarts au lieu d’améliorer le système.

On se raconte alors une histoire pratique : « il nous faut juste un meilleur outil ». C’est confortable. C’est même séduisant. Mais c’est souvent faux.

La nouveauté la plus intéressante autour d’Apple en ce moment n’est pas seulement une fonctionnalité technique. C’est le message sous-jacent : la gestion Apple devient un sujet de planification opérationnelle, pas seulement de configuration.

Ce qu’Apple change concrètement

Dans son annonce officielle, Apple présente Apple Business comme une plateforme réunissant la gestion des appareils, des services de productivité et des outils d’administration dans une même expérience. Le point le plus concret pour les équipes IT, c’est l’arrivée d’un MDM intégré, de Blueprints pour standardiser les configurations, et d’une logique de déploiement zéro contact plus lisible pour les PME et structures en croissance (Apple Business).

Dit autrement : Apple essaie de réduire la distance entre l’intention et l’exécution.

Avant, l’équipe IT devait souvent assembler sa méthode à partir de plusieurs briques : inscription, profils, catalogue d’apps, droits, documentation interne, procédures d’arrivée et de départ. Après, Apple pousse une approche plus unifiée :

• des modèles de configuration reproductibles avec les Blueprints ;
• une meilleure préparation des appareils avant même leur remise aux utilisateurs ;
• une séparation plus claire entre rôles, groupes et usages ;
• une expérience plus cohérente pour les collaborateurs qui doivent installer leurs apps et demander de l’aide.

Ce n’est pas anodin. Parce qu’un parc Apple bien géré, ce n’est pas un parc « moderne ». C’est un parc où l’on supprime les décisions inutiles au quotidien.

En parallèle, le débat sur le declarative device management continue d’alimenter le monde Apple : plusieurs observateurs considèrent désormais que l’ère du « legacy MDM » touche à ses limites, au profit de mécanismes plus natifs, plus prévisibles et moins dépendants d’allers-retours permanents entre serveur et terminaux (9to5Mac).

La vraie question devient donc : est-ce que votre organisation gère encore des exceptions, ou commence-t-elle enfin à gérer des standards ?

Comment l’utiliser dans un cas réel

Prenons un cas simple : une PME de 80 personnes, réparties sur deux sites, avec une dizaine d’arrivées par mois, quelques iPhone d’entreprise et un historique de configuration « au fil de l’eau ».

Avant

• Le support prépare les Mac un par un.
• Les applications ne sont pas les mêmes selon les équipes.
• Les réglages de sécurité sont documentés dans un PDF vieux de 18 mois.
• Le jour d’une arrivée, quelqu’un découvre toujours qu’il manque un accès, un agent ou un certificat.

Après

L’objectif n’est pas de tout refaire. L’objectif est de remettre de l’ordre là où il a de l’effet immédiat.

1. Définir 3 à 4 Blueprints maximum
   • un modèle standard bureau ;
   • un modèle direction ;
   • un modèle terrain/nomade ;
   • éventuellement un modèle prestataire.
2. Lister les apps et réglages vraiment communs
   • sécurité ;
   • navigateur ;
   • outils collaboratifs ;
   • VPN ou accès distants ;
   • configuration d’identité.
3. Nettoyer les exceptions historiques
   • quelles dérogations sont encore légitimes ;
   • lesquelles ne sont que des habitudes non challengées.
4. Documenter le cycle de vie complet
   • arrivée ;
   • changement de rôle ;
   • prêt temporaire ;
   • départ.
5. Repositionner l’outil déjà en place
   • non comme un simple panneau de réglages ;
   • mais comme une couche de gouvernance, d’automatisation et de contrôle là où les besoins dépassent le cadre standard.

C’est là que l’annonce Apple Business devient intéressante, y compris pour les équipes déjà équipées d’un MDM tiers. Pas parce qu’elle remplace mécaniquement ce dernier. Ce serait une lecture trop courte. Mais parce qu’elle oblige à clarifier ce qui doit être natif, simple et standardisé, et ce qui mérite une couche spécialisée.

Limites et points de vigilance

Non, Apple Business ne va pas corriger à lui seul le bricolage que l’on se refuse à regarder dans les yeux.

Quelques points méritent d’être rappelés :

• un outil intégré ne remplace pas une gouvernance claire ;
• un blueprint mal pensé industrialise aussi les erreurs ;
• la promesse de simplicité peut masquer des besoins avancés bien réels.

Et puis il y a une question que beaucoup évitent : quand avez-vous revu pour la dernière fois vos standards ?

Pas vos tickets. Pas vos incidents. Vos standards.

C’est souvent là que le désordre commence. On optimise le support, mais on ne revoit jamais le système qu’il est censé supporter.

Élargir : ce que cela change dans l’organisation

Le sujet n’est pas « Apple entre sur le terrain du MDM ». Le sujet, c’est que la toise monte pour tous les acteurs et qu’ainsi tout le monde en profite.

Pour les équipes IT, cela veut dire moins de bricolage ou de zones grises (laissées au hasard)… et plus de valeur dans la clarté opérationnelle.

• Qui décide du standard ?
• Qui valide les exceptions ?
• Où vit la documentation ?
• Quel niveau d’autonomie laisse-t-on aux utilisateurs ?
• Qu’est-ce qui doit être automatisé, et qu’est-ce qui doit rester sous contrôle humain ?

Un bon environnement Apple n’est pas celui qui impressionne en démonstration. C’est celui qui tient quand personne n’a le temps. Quand il y a plusieurs arrivées le même matin. Quand la personne « qui sait » est en congé. Quand un site distant a besoin d’un remplacement en urgence.

Autrement dit : la maturité n’est pas dans la console. Elle est dans la répétabilité.

Conclusion

Le problème de départ était simple : trop d’équipes vivent encore leur gestion Apple comme une suite de manipulations manuelles, de dérogations implicites et de dépendances individuelles.

Avec Apple Business, Apple remet au centre une idée salutaire : un parc Apple doit pouvoir être préparé, configuré et maintenu avec davantage de standards, de lisibilité et de zéro-contact (Apple Business).

La vraie opportunité n’est pas seulement technique. Elle est organisationnelle. Elle oblige à revoir la documentation, la gouvernance des exceptions, la manière dont l’IT construit la confiance au quotidien.

Pas besoin de tout révolutionner ce trimestre. Mais il serait dommage de continuer à appeler « complexité » ce qui relève parfois, tout simplement, d’un manque de cadre.

CTA (à faire)

Cette semaine, choisissez un seul moment du cycle de vie d’un appareil Apple — l’arrivée d’un collaborateur, par exemple — et documentez-le de bout en bout. Ensuite, demandez-vous honnêtement : qu’est-ce qui pourrait devenir standard, reproductible et zéro-contact dès maintenant ?

Sources utiles

• Annonce Apple Business
• Analyse 9to5Mac sur la fin du legacy MDM
• Mosyle News Room

Bien sûr que l’infrastructure compte. Mais ce réflexe cache parfois le vrai sujet : un réseau tombe rarement dans le chaos uniquement parce qu’il manque de puissance. Il tombe surtout dans le chaos quand il manque de visibilité, de routine et de discipline d’exploitation.

Les annonces récentes autour d’UniFi racontent exactement cela. D’un côté, Ubiquiti pousse davantage d’orchestration, de visibilité et de capacités réseau avancées dans UniFi Network 10.5. De l’autre, le Security Advisory Bulletin 064 rappelle brutalement qu’un bon matériel mal maintenu reste un risque très concret.

Contexte : où est le vrai problème ?

Dans beaucoup de PME, d’écoles ou de réseaux multi-sites, l’infrastructure UniFi s’est installée pour de bonnes raisons : simplicité, rapport qualité/prix, cohérence de l’écosystème, administration centralisée. Jusque-là, rien à redire.

Le problème apparaît ensuite. Lentement.

• Les sites ne sont plus exactement au même niveau de mise à jour.
• Les règles réseau ne sont pas documentées et « vivent » dans plusieurs têtes d’administrateurs système.
• L’IPv6 arrive « plus ou moins » selon les accès opérateurs.
• Les incidents WAN se traitent au fil de l’eau.
• Les fenêtres de maintenance ne sont ni planifiées, ni documentées.

Et pendant ce temps, l’équipe croit encore que son risque principal est matériel. C’est confortable, là aussi. Acheter rassure. Documenter, tester et patcher régulièrement rassure beaucoup moins. Pourtant, c’est souvent là que la stabilité se joue.

Ce qu’Ubiquiti change concrètement

Les nouveautés publiées par Ubiquiti mettent en avant une évolution intéressante : UniFi ne cherche plus seulement à être facile à déployer. La plateforme cherche à devenir plus exploitable, avec plus de visibilité et plus de contrôle.

Parmi les points marquants de UniFi Network 10.5, on retrouve notamment :

• une orchestration multi-sites plus lisible ;
• des évolutions autour de l’eBGP ;
• une meilleure prise en compte du double stack IPv6 ;
• une logique plus mature pour piloter un réseau qui n’est plus juste « un seul bâtiment avec un seul accès Internet » (UI What’s New).

Autrement dit : Ubiquiti fournit davantage d’outils pour administrer un réseau réel. Pas un réseau de démo. Un réseau avec des dépendances opérateur, des sites distants, des usages différents et des incidents intermittents.

Mais l’autre signal de la période est au moins aussi important. Dans le Security Advisory Bulletin 064, Ubiquiti détaille plusieurs vulnérabilités affectant des équipements UniFi OS et recommande de monter vers des versions corrigées, notamment 5.1.12 ou ultérieures selon les appareils (Security Advisory Bulletin 064, UniFi OS releases).

Voilà le vrai contraste.

D’un côté, la plateforme devient plus puissante. Un dashboard moderne n’annule pas une version vulnérable. Une belle topologie n’efface pas une routine de mise à jour absente.

Comment l’utiliser dans un cas réel

Prenons un réseau de PME réparti sur trois sites : siège, entrepôt, agence commerciale. Tout fonctionne « globalement bien ». Jusqu’au jour où un incident VPN se combine avec une mise à jour repoussée, une configuration non documentée et un accès opérateur qui se comporte différemment selon les sites.

Avant

• chaque site évolue un peu à sa manière ;
• les versions ne sont pas revues de manière globale dans une routine commune ;
• l’IPv6 n’est pas vraiment suivi ;
• on n’a pas de vue synthétique sur les écarts (il manque une vue qui rassemble les différents sites) ;
• les changements réseau sont mémorisés (dans la tête d’un sysadmin), pas capitalisés (personne ne les inscrits dans une documentation commune).

Après

L’objectif n’est pas de transformer l’équipe en centre d’exploitation réseau d’un grand groupe. L’objectif est plus modeste. Et plus puissant : rendre le réseau prévisible.

1. Faire un inventaire des versions réelles
   • gateways ;
   • contrôleurs ;
   • switchs ;
   • appliances UniFi OS.
2. Traiter la dette de patching avant tout projet annexe
   • vérifier l’exposition aux vulnérabilités signalées par le Bulletin 064 ;
   • définir une cible minimale de version ;
   • planifier la montée par vagues plutôt qu’en réaction.
3. Utiliser la logique multi-sites pour comparer au lieu de supposer
   • versions ;
   • politiques ;
   • comportements WAN ;
   • écarts de configuration.
4. Créer une routine d’observation réseau
   • état WAN ;
   • événements récurrents ;
   • présence et qualité de l’IPv6 ;
   • incidents intermittents.
5. Documenter les changements comme des décisions d’exploitation
   • qui a modifié quoi ;
   • pourquoi ;
   • sur quel périmètre ;
   • avec quel plan de retour arrière.
6. Tester sur un périmètre limité avant généralisation
   • un site pilote ;
   • une fenêtre de maintenance claire ;
   • une validation des services critiques après changement.

Ce que change Ubiquiti ici, ce n’est pas seulement la liste de fonctionnalités. C’est la possibilité de sortir d’une administration « au feeling ».

Limites et points de vigilance

Il faut rester lucide.

• Toutes les nouveautés d’UniFi 10.5 ne sont pas utiles à tous les contextes.
• Les fonctions avancées comme l’eBGP ne servent pas de la même façon à une petite structure et à un réseau plus distribué.
• Une montée de version n’est jamais un acte purement administratif : il faut du test, un calendrier, un minimum de communication.
• La visibilité multi-sites n’a de valeur que si quelqu’un la regarde vraiment et agit sur les écarts observés.

Et surtout : la sécurité ne se délègue pas au matériel.

C’est peut-être la phrase la plus utile de la semaine. Une appliance peut être excellente. Si personne ne suit les versions, les bulletins de sécurité et les dépendances d’exploitation, elle devient juste une excellente appliance vulnérable.

Élargir : ce que cela change dans l’organisation

Un réseau bien tenu, ce n’est pas seulement un réseau qui fonctionne. C’est un réseau que l’on comprend.

Cela change beaucoup de choses pour l’équipe IT :

• on passe d’une culture du dépannage à une culture de la routine ;
• on remplace les interventions héroïques par des fenêtres de maintenance assumées ;
• on transforme les connaissances tacites en documentation utile ;
• on réduit la fragilité créée par les écarts entre sites.

Et là, une question mérite d’être posée franchement : quand avez-vous regardé pour la dernière fois votre réseau UniFi comme un système vivant, et non comme une suite d’équipements ?

Parce que c’est cela, le fond du sujet. L’outil évolue. Les fonctionnalités progressent. Les appliances montent en gamme. Très bien.

Mais la vraie maturité commence le jour où l’on traite les versions, la visibilité, les patchs et la documentation comme des éléments de sécurité à part entière.

Conclusion

Le problème de départ semblait matériel. En réalité, il est souvent méthodologique.

Les nouveautés d’UniFi 10.5 renforcent la visibilité et la capacité d’orchestration des réseaux réels (UI What’s New). Dans le même temps, le Bulletin 064 rappelle qu’un réseau UniFi mal patché reste exposé, même s’il est bien dimensionné (Security Advisory Bulletin 064).

Le gain concret, pour une équipe, n’est donc pas seulement d’avoir plus de puissance. C’est d’avoir plus de méthode : une routine de mise à jour, une lecture multi-sites, une documentation claire et des arbitrages d’exploitation explicites.

Ce n’est pas spectaculaire. C’est mieux que ça. C’est ce qui évite les incidents stupides.

CTA (à faire)

Prendre trente minutes cette semaine pour faire trois choses : lister les versions UniFi OS réellement en production, vérifier votre exposition aux correctifs liés au Bulletin 064, et noter noir sur blanc votre prochaine fenêtre de maintenance réseau.

Rien que ça peut déjà changer le niveau de risque.

Sources utiles

• UI What’s New
• Security Advisory Bulletin 064
• UniFi OS releases

• Rapport SMART  alerte au fur et à mesure du compte, mais notifie seulement si moins de 10 alertes.
• Rapport SMART plus « propres »
• Support pour Daylite 6
• Alerte quand une application précise est supprimée
• Support pour les chainages de sauvegardes dans Carbon Copy Cloner

Changement :

• Carbon Copy Cloner ne vous préviendra plus juste parce que la destination est manquante. Seulement quand il n’a pas pu finir une sauvegarde dans le temps imparti.

Réparations :

• Surveillance de la présence de la capacité du volume est à nouveau possible
• Certains rapports de status SMART n’avait pas de contenu, en dépit d’un status SMART normal.

Pour forcer le client de WM à établir un rapport maintenant :

sudo /Library/MonitoringClient/RunClient -F

Pour forcer le client de WM à vérifier s’il existe des mises à jour :

sudo /Library/MonitoringClient/RunUpdater -F

Pour désactiver la recherche automatique de mise à jour :

/usr/bin/defaults write /Library/MonitoringClient/ClientSettings Update_Enabled -bool false

Ôter le client WM d’un ordinateur :

/Library/MonitoringClient/Utilities/RemoveClient -F

Changer le groupe d’un client (vous changerez GROUPE_D’UN_CLIENT par le nom de l’un de vos groupes clients) :

/usr/bin/defaults write /Library/MonitoringClient/ClientSettings ClientGroup -string « GROUPE_D’UN_CLIENT »

Changer la durée de temps pour être prévenu de l’exécution de Time Machine (vous changerez 10 par n’importe quel nombre entre 1 et 99) :

defaults write /Library/MonitoringClient/PluginSupport/check_time_machine_settings Days_Until_Warning -int 10

Activer ou désactiver la surveillance de Time Machine (false : pas de surveillance, true : surveillance active) :

defaults write /Library/MonitoringClient/PluginSupport/check_time_machine_settings Warning_Enabled -bool false

Ajuster le seuil de la capacité du volume Root (par défaut : 90%) :

defaults write /Library/MonitoringClient/PluginSupport/check_root_capacity_settings Root_Warn_Level -int 90

Désactiver complètement un plugin :

defaults write /Library/MonitoringClient/ClientSettings PluginsDisabled -array-add « check_[service-to-ignore].plugin »

Trouver le nom du plugin dans /Library/MonitoringClient/Plugins pour désactiver time machine par exemple (c’est une requête qui revient assez souvent) :

defaults write /Library/MonitoringClient/ClientSettings PluginsDisabled -array-add « check_time_machine.plugin »

Dire au plugin Daylite ne pas surveiller un compte utilisateur précis (cette commande vous permettra d’arrêter de surveiller l’utilisateur « admin » pour le plugin Daylite) :

/usr/libexec/PlistBuddy -c « Set :Users_To_Monitor:admin bool false » /Library/MonitoringClient/PluginSupport/check_daylite_client_settings.plist

Activer les notifications de redémarrage :

defaults write /Library/MonitoringClient/PluginSupport/check_reboot_time_settings Warn_On_Reboot -bool true

A propos de l’affichage du panneau de Préférences système :

Toutes les commandes doivent être envoyées en tant que root, et ce faisant les fichiers deviendront illisibles par l’utilisateur logué.

Cela ne causera aucun problème concernant les rapports normaux, mais cela peut avoir un effet cosmétique peu appréciable lorsque vous voudriez voir le plugin dans les Préférences systèmes (pendant les tests de la ligne de commande, bien sûr).

La routine du plugin chaque heure remettra l’agent avec les permissions correctes, et convertira le fichier binaire en xml, ce qu’il préfèrera

Vous pouvez forcer le rapport et donc le rafraîchissement avec la commande :

sudo /Library/MonitoringClient/RunClient -F

Vous ouvrirez à nouveau les Préférences Systèmes pour vérifier les changements.

<code>defaults read /Library/Preferences/SystemConfiguration/com.apple.airport.preferences | grep LastConnected -A 7

Cet article a paru sur Krypted, le 11 novembre 2015.

Pour créer un disque de démarrage d’El Capitan, il faut d’abord nommer le disque ou la clef USB. J’utiliserai mavinstall pour les besoins de cet article. Le format choisi doit être OS X Etendu. L’installeur est appelé Install OS X El Capitan et est par défaut situé dans le dossier /Applications. Au sein de l’application (afficher le contenu du paquet dans le menu contextuel), il y a un nouveau binaire qui s’appelle createinstallmedia (à l’intérieur de Contents/Resources).

Vous utiliserez ce binaire pour créer un disque d’installation (similaire de celui que nous avions utilisé avec InstallESD). Pour se faire, spécifiez le –volume où installer (notez bien que ce volume sera effacé), le chemin de l’installeur OS X El Capitan et nous sélectionnerons –nointeraction afin qu’il aille jusqu’à la conclusion de la création.

/Applications/Install OS X El Capitan.app/Contents/Resources/createinstallmedia –volume /Volumes/mavinstall –applicationpath /Applications/Install OS X El Capitan.app –nointeraction

Notez aussi qu’il faudra devenir ou invoquer sudo pour réaliser cette action.

Une fois lancé, vous verrez que la commande efface le disque, copie le matériel d’installation (InstallESX, etc.) et rends le disque capable de démarrer, comme suit :

Erasing Disk : 0%… 10%… 20%… 100%…
Copying installer files to disk…
Copy complete.
Making disk bootable…
Copying boot files…
Copy complete.

Alors vous pourrez sélectionner le volume nouvellement créé depuis le panneau Disque de démarrage des Préférences Systèmes ou redémarrer en appuyant sur la touche option de votre clavier pour sélectionner le nouveau volume.

Notez que si vous faites cela sur un système avec un disque SSD cela sera beaucoup plus rapide. Cela a pris 17 minutes la dernière fois que je l’ai réalisé.

Cet article a paru sur Krypted, le 11 octobre 2015.

FileCloud chez NausicaMedia, c’est votre box sécurisée dans un cloud privé ! Offrez-vous la meilleure offre sur le marché. Une box survitaminée !

• Hébergé dans un cloud privé sécurisé en France
• Échange de fichiers sécurisé pour les entreprises
• Chiffrement 256-bit AES pour l’hébergement et pour la transmission
• Synchronisation entre tous les appareils, ordinateurs (PC, Mac, Linux) et iPhone, iPad
• Sauvegarde de dossiers depuis les postes utilisateurs
• Intégration avec les applications Microsoft Office
• Prévention en temps réel
• Aperçu des documents
• Intégration du répertoire utilisateur
• Versions et verrouillage des fichiers
• Antivirus
• WebDAV
• Multilangue
• Partage évolué (public, privé et temporaire).
• Contrôles du téléchargement de fichiers
• Validation en deux étapes
• Comptes clients illimités et gratuits…

Notre nouveau site affiche clairement et simplement ce que nous faisons à présent : Apple, Daylite, Cloud. Il est une évolution du précédent.

— Apple, parce que sans Apple, nous n’existerions pas comme il est dit sur la page d’accueil de notre site. Nous installons, configurons, surveillons (monitoring), déployons et gérons vos ordinateurs, iPhone, iPad, serveurs Apple. C’est ce que nous faisons depuis presque 15 ans, depuis la sortie de la première version d’OS X.

— Daylite, parce que Daylite c’est Calendrier et Contacts les applications d’Apple pour les professionnels ! Une intégration aussi poussée que les logiciels Apple avec les fonctions de travail collaboratif, de délégation, et de suivi pour les petites entreprises. Il est aussi possible de compléter et d’interfacer Daylite avec d’autres logiciels professionnels et c’est ce que NausicaMedia vous propose sous forme de solutions logicielles : Billings Pro pour la facturation ; DocMoto pour la gestion électronique de documents ; MoneyWorks pour l’analyse financière ; FileCloud pour l’échange de fichiers et de dossiers.

— Cloud, parce que c’est la dernière offre de NausicaMedia. Mais peut-être la plus importante ! Nous créons pour vous le Cloud sécurisé et 100 % français. Hébergement de vos Mac mini dans l’un des datacenters de Claranet en plein cœur de Paris, le Cloud de NausicaMedia vous offre :

• hébergement et co-hébergement
• luxueuse bande passante
• sécurité et sauvegarde de vos données
• installation et mise à disposition de vos logiciels professionnels (Daylite, MoneyWorks, BillingsPro…)
• espace de stockage et logiciel de partage de fichiers et de dossiers avec vos contacts et avec vos collaborateurs (FileCloud)

Avec cette offre d’hébergement de Mac mini, NausicaMedia vous propose d’allier le meilleur de ses savoir-faire, ses solutions Apple et ses solutions Daylite, en une seule offre novatrice.

Nous espérons que vous prendrez du plaisir sur ce nouveau site qui ne fait qu’évoluer, mais une évolution peut se révéler majeure, nul besoin de révolution pour cela.