Votre console MDM affiche vos Mac, mais cela ne prouve pas que vos politiques de mise à jour fonctionnent encore. Avec macOS 27, Apple met fin aux anciennes méthodes de gestion des mises à jour. Il ne s’agit plus de préparer une transition future : il faut vérifier ce qui pilote réellement votre parc, avant comme après la migration.
Mises à jour macOS 27 : ce qui ne fonctionne plus
Dans ses notes entreprise de macOS 27, Apple confirme que la gestion historique des mises à jour ne fonctionne plus sur les systèmes de génération 27.0. Cela comprend les commandes et requêtes de mise à jour, les réglages de cadence recommandée et les restrictions historiques, notamment les reports et les réglages concernant les améliorations de sécurité en arrière-plan.
Apple demande désormais d’utiliser la gestion déclarative des appareils pour configurer et imposer les mises à jour. Ce n’est pas la disparition du MDM : c’est le remplacement de certaines méthodes qu’il utilisait.
La distinction compte. Une inscription MDM valide, des applications correctement distribuées et une console qui répond ne suffisent pas à démontrer que la politique de mise à jour est encore opérationnelle.
Pour une flotte qui mélange macOS 26 et macOS 27, il faut donc identifier les méthodes employées pour chaque groupe. Une procédure qui fonctionne sur les anciens systèmes ne constitue pas une validation pour les nouveaux.
Le déclaratif change la manière de piloter le parc
Définir un état attendu, pas seulement envoyer une commande
Avec une logique impérative, l’équipe IT demande une action à un instant donné, attend le résultat et relance les appareils qui n’ont pas répondu. Avec une logique déclarative, elle définit une politique et un état attendu. L’appareil traite la déclaration et remonte les informations d’état auxquelles le service de gestion s’est abonné.
Pour l’équipe, le travail consiste à préciser :
- la version ou la politique de mise à jour attendue ;
- l’échéance applicable au groupe concerné ;
- les exceptions métier et leur durée ;
- les informations permettant de distinguer conformité, attente et échec.
Le déclaratif ne dispense pas de tester les applications, de prévenir les utilisateurs ou de traiter les appareils hors ligne. Il donne un cadre plus solide à ces décisions. Encore faut-il que le MDM expose les configurations et les rapports utiles.
Vérifier le réseau, pas seulement la console
La documentation de déploiement Apple décrit aussi des exigences réseau renforcées pour certains processus des systèmes 27 : gestion des appareils, inscription automatique, installation de profils et d’applications, mises à jour logicielles.
Le service de gestion doit notamment prendre en charge TLS 1.2 au minimum, avec des suites cryptographiques et des certificats conformes aux exigences App Transport Security. Un simple « notre serveur utilise HTTPS » ne suffit donc pas à convaincre.
Dans la pratique, vérifiez les points de terminaison réellement contactés, la chaîne de certificats et les éventuels intermédiaires réseau. Un proxy ou un service ancien peut être en cause, même si l’appareil reste visible dans la console. Il faut observer un parcours complet sur un appareil pilote, pas seulement ouvrir la page d’administration du MDM.
Exploiter les nouveaux états sans mélanger les plateformes
macOS 27 apporte de nouveaux états déclaratifs, notamment le type d’inscription, l’attente de configuration dans l’Assistant réglages et le statut du mode Isolement sur les appareils supervisés. Les profils historiques peuvent aussi être distribués comme ressources déclaratives, avec une vérification d’intégrité.
Ces capacités aident à mieux comprendre ce qui bloque. Elles ne transforment pas automatiquement chaque console en outil de diagnostic complet : leur exploitation dépend de l’éditeur MDM et de sa mise en œuvre.
Attention également au périmètre. Les informations de santé des composants décrites par Apple concernent l’iPhone et l’iPad, pas le Mac. La nouvelle tentative automatique d’inscription de Return to Service, avec un délai progressif pouvant atteindre cinq minutes, concerne iOS et iPadOS 27. Ce n’est pas une nouveauté macOS.
Passer du constat à une politique vérifiée
1. Cartographier les méthodes encore utilisées
Avant de modifier les politiques, documentez :
- Les versions de macOS réellement présentes et les Mac destinés à passer sous macOS 27.
- Le type d’inscription et la supervision des appareils.
- Les commandes, profils, restrictions et scripts utilisés pour gérer les mises à jour.
- Les politiques déjà déclaratives et les versions de système qu’elles ciblent.
- Les appareils qui ne communiquent plus régulièrement avec le MDM.
- Les exceptions métier, avec un responsable et une date de révision.
L’objectif n’est pas de produire un inventaire décoratif. Il faut repérer les Mac pour lesquels l’organisation croit disposer d’un contrôle qui n’est plus effectif.
2. Demander une preuve à l’éditeur MDM
Que vous utilisiez Mosyle ou une autre solution, ne vous contentez pas d’un badge « compatible macOS 27 ». Demandez où se configure la politique déclarative, quelles versions du système et du service sont requises, et comment son état apparaît dans les rapports.
Faites préciser le comportement d’un Mac hors ligne, d’une installation en échec et d’une échéance dépassée. Vérifiez aussi comment les anciennes politiques cohabitent avec les nouvelles dans une flotte mixte.
La bonne démonstration tient sur un appareil : une déclaration reçue, une échéance comprise et un résultat vérifiable. Une capture d’écran du formulaire de configuration n’est pas une preuve d’application.
3. Construire un pilote représentatif
Un pilote composé uniquement de deux Mac du service informatique ne prouve pas grand-chose. Prenez, par exemple, dix Mac représentatifs : portable souvent hors réseau, poste distant, application métier sensible et usages quotidiens variés.
Testez le passage vers macOS 27 depuis les versions présentes dans votre parc, puis la gestion des mises à jour sur macOS 27. Ce sont deux vérifications distinctes.
Retenez quatre critères de sortie :
- la déclaration est reçue et son état est exploitable ;
- l’utilisateur comprend l’échéance et les actions attendues ;
- l’installation et le redémarrage se déroulent conformément à la politique testée ;
- la console permet de distinguer les appareils conformes, en attente, en échec ou relevant d’une exception documentée.
Si vous gérez aussi des iPhone et des iPad, prévoyez un pilote distinct. Les résultats obtenus sur Mac ne valident pas leurs parcours d’inscription ou de remise en service.
4. Donner une date de fin aux exceptions
« Ce Mac ne doit pas être mis à jour, il y a un vieux logiciel » n’est pas une politique. C’est une dette sans échéance.
Une exception doit identifier le logiciel concerné, le risque accepté, la personne qui valide, la date de révision et le plan de sortie. Elle doit aussi être distinguée d’un échec technique : un Mac autorisé à rester sur une version n’est pas un Mac dont la mise à jour a échoué.
5. Déployer par groupes et documenter le traitement des échecs
Après validation du pilote, étendez progressivement. Suivez la conformité par version attendue, les échecs d’installation, les appareils sans communication récente et les exceptions arrivées à échéance.
Une page de procédure doit suffire à expliquer qui modifie une politique, qui autorise une exception, comment traiter un appareil hors ligne et quand solliciter l’éditeur MDM. Si seul l’administrateur historique sait interpréter le résultat, le chantier n’est pas terminé.
Ce qu’il faut garder sous contrôle
La gestion déclarative ne rend pas une application compatible avec macOS 27. Elle ne remplace ni une sauvegarde vérifiée ni la validation des outils métier. Les notes entreprise signalent notamment que Rosetta, s’il était installé auparavant, n’est pas automatiquement restauré lors de la mise à niveau vers macOS 27. C’est un contrôle supplémentaire à prévoir pour les applications qui en dépendent, même si Rosetta reste disponible comme outil de compatibilité dans cette version.
Pour les fonctionnalités livrées, appuyez-vous sur les notes de version finales. La page WWDC26 conserve un avertissement sur le caractère préliminaire de son contenu : elle éclaire les mécanismes, mais ne doit pas servir seule à certifier une disponibilité en production.
Enfin, distribuer un ancien profil comme ressource déclarative ne modernise pas son contenu par magie. Il faut toujours savoir ce qu’il configure et vérifier que les réglages concernés restent pris en charge.
Conclusion : vérifier le contrôle réel, pas la présence dans la console
Avec macOS 27, la fin des anciennes méthodes de gestion des mises à jour est effective. Une politique historique encore visible dans votre outil ne doit pas être considérée comme une garantie de fonctionnement.
Le bon chantier reste concret : inventorier les méthodes, valider leur équivalent déclaratif, tester sur un groupe représentatif et documenter les exceptions. Pas besoin de refaire toute l’administration. Mais il faut pouvoir prouver ce qui fonctionne.
Vous préparez macOS 27 ou l’avez déjà déployé ? NausicaMedia peut vous accompagner pour vérifier vos politiques de mise à jour, tester leur application et structurer le suivi des exceptions. Commencez par dix Mac : demandez à votre fournisseur MDM de vous montrer la déclaration, l’échéance et le rapport d’état associés.
Sources
- Apple : nouveautés entreprise de macOS 27, notes publiées le 28 septembre 2026. Référence pour les fonctionnalités livrées et la fin des anciennes méthodes de gestion des mises à jour.
- Apple : évolutions de la gestion des appareils présentées à la WWDC26. Détails sur TLS et ATS, les ressources déclaratives, les états remontés et les périmètres par plateforme. Cette page conserve une mention de contenu préliminaire.