macOS 27 Golden Gate, iOS 27 et iPadOS 27 sont disponibles depuis aujourd’hui. Avec eux, des mécanismes MDM encore utilisés en production cessent de fonctionner, la téléassistance perd un levier dont elle dépendait depuis des années, et les Mac Intel sortent définitivement du support.
Les annonces grand public se concentrent sur l’interface et l’IA. Pour un DSI, les changements structurants sont ailleurs : gestion du parc, sécurité, authentification et continuité de service. Apple accélère une transformation engagée depuis plusieurs années, le passage d’un modèle piloté par commandes et profils vers une administration déclarative basée sur l’état souhaité du terminal. Sur les OS 27, cette bascule cesse d’être une option.
Voici ce qu’il faut requalifier avant de généraliser le déploiement.
Une précision avant d’entrer dans le détail. Les noms de configurations et de clés cités dans cet article sont ceux définis par Apple : ils sont identiques quel que soit le MDM. Ce qui change d’un éditeur à l’autre, c’est la manière dont l’interface les expose, les regroupe et les renomme en surface. Un réglage introuvable dans une console ne signifie donc pas qu’il n’existe pas côté Apple, mais parfois seulement que l’éditeur ne l’a pas encore exposé.
Note sur les illustrations. Les copies d’écran de ce document proviennent d’une console Jamf Pro. Ce qu’elles documentent, ce sont les clés Apple, leurs versions minimales et leurs mentions de dépréciation ou de retrait : ces informations viennent du schéma d’Apple et valent pour tous les MDM. En revanche, la mise en page, les intitulés en clair et le regroupement des réglages sont propres à Jamf. Sur une autre console, les mêmes clés existent mais ne se présentent pas de la même façon, et certaines peuvent ne pas encore être exposées.
1. Software Update : les mécanismes historiques ne fonctionnent plus
La formulation d’Apple est sans ambiguïté : la gestion historique des mises à jour ne fonctionne plus sur l’ensemble des systèmes 27.0. Il ne s’agit pas d’une dépréciation avec période de grâce.
Commandes de mise à jour MDM, requêtes associées, réglage de cadence recommandée, restrictions de report, Background Security Improvements. Rien de tout cela ne répond plus.
Le schéma est explicite sur le calendrier. Dans le payload Restrictions, forceDelayedSoftwareUpdates, forceDelayedMajorSoftwareUpdates, forceDelayedAppSoftwareUpdates et enforcedSoftwareUpdateDelay portent la mention dépréciée en 26.0, puis retirée en 27.0, avec renvoi explicite vers la configuration déclarative. Si l’un de ces réglages est encore actif chez un client, il est sans effet depuis aujourd’hui sur tout appareil monté en 27.
Payload Restrictions : les clés de report de mises à jour portent la mention « Removed: macOS 27.0 ».
Le modèle cible repose sur deux déclarations distinctes, et la confusion entre les deux est la première source d’erreur de configuration. com.apple.configuration.softwareupdate.settings pilote le comportement des mises à jour, les reports et leur présentation à l’utilisateur, sans jamais en déclencher une. com.apple.configuration.softwareupdate.enforcement.specific impose une version cible et une échéance. La logique passe d’une commande envoyée au terminal suivie d’un résultat, à un état souhaité poussé par le MDM, évalué localement par le terminal, puis remonté sous forme de rapport de statut.
Software Update Settings : les réglages de comportement, dont AllowStandardUserOSUpdates, Notifications et RecommendedCadence.
Software Update Settings : les quatre blocs configurables, Install actions, Beta updates, Deferrals et Background Security Improvements.
Software Updates : la déclaration d’application forcée, avec le choix entre dernière version disponible et version cible datée.
À vérifier avant de s’engager sur un délai auprès d’un client :
● que le MDM prend réellement en charge ces déclarations, les reports et les remontées d’état, et pas seulement leur affichage en console ;
● que la politique de report a été reconstruite côté DDM. Le plafond reste 90 jours, via CombinedPeriodInDays sur iOS, iPadOS et tvOS, et via MajorPeriodInDays, MinorPeriodInDays et SystemPeriodInDays sur macOS, ce dernier couvrant les mises à jour non-OS du type Safari, XProtect ou outils en ligne de commande. Une fenêtre de 30 à 60 jours laisse le temps de qualifier une version majeure avant généralisation.
Attention à ce que recouvre exactement le mot report. Il agit sur la visibilité de la mise à jour, pas sur son installation. Et les Background Security Improvements ne sont pas pris en compte par ces mécanismes, même si reporter la dernière version mineure revient en pratique à reporter le correctif de sécurité, puisqu’ils ne s’appliquent qu’à elle.
Reste un prérequis facile à oublier. Sur Mac Apple silicon, l’application forcée d’une mise à jour s’appuie sur le Bootstrap Token ; en son absence, l’installation silencieuse dégénère en demande d’identifiants auprès de l’utilisateur. Son séquestre et sa disponibilité se vérifient dans le workflow d’enrôlement, avant la campagne, pas pendant.
2. Permissions et téléassistance : la fin de l’octroi silencieux
Le profil PPPC continue de fonctionner sur macOS 27. Ce qui change, c’est que plusieurs de ses clés passent en dépréciation avec macOS 27.0, Accessibility, Camera, Microphone, Speech Recognition et Bluetooth, toutes renvoyées vers la clé Privacy de la configuration déclarative com.apple.configuration.app.settings.
Le point qui concerne directement les équipes de support est ailleurs. Sur macOS 27.0, quand un profil applique le réglage Accessibility, le système affiche désormais une notification non bloquante pour chaque application concernée, et l’utilisateur peut ensuite modifier ce réglage dans les Réglages Système.
Profil PPPC : Accessibility dépréciée en macOS 27.0, avec la notification non bloquante et la reprise de contrôle par l’utilisateur.
La permission est donc toujours accordée sans interaction. Elle n’est simplement plus ni invisible ni définitive.
Pour un outil de téléassistance, de supervision ou de maintenance, la conséquence est concrète : l’autorisation peut disparaître à tout moment, sur décision d’un utilisateur qui vient de recevoir une notification qu’il ne comprend pas. Ce n’est plus un problème de déploiement, c’est un problème d’exploitation dans la durée. Il faut surveiller l’état réel des permissions sur le parc, et pas seulement vérifier qu’elles ont été poussées.
Toutes les permissions ne basculent pas au même rythme, ce qui mérite d’être documenté côté exploitation. Dans le même profil, les clés d’accès aux dossiers de l’utilisateur, aux données et aux bundles d’autres applications, ou l’envoi d’événements système, ne portent aucune mention de dépréciation sur ce cycle. Deux modèles vont cohabiter.
Le remplacement déclaratif s’appelle PermissionDefaults, dans le dictionnaire Privacy. Le nom dit l’intention : des valeurs par défaut, pas des permissions imposées. Subtilité d’exploitation, sur macOS l’application n’est pas désignée par un simple bundle ID mais par un identifiant composé de la forme Bundle-ID {Designated-Requirement}, et les valeurs ne s’appliquent que si la signature de code correspond.
Le même mécanisme arrive côté web. En iOS, iPadOS et macOS 27.0, la configuration Safari accueille à son tour un dictionnaire Privacy avec un PermissionDefaults par site, qui définit les autorisations caméra et micro par motif d’URL, le motif le plus précis l’emportant. Pour un poste de travail encadré, cela devient un vrai levier de politique.
Safari : PermissionDefaults par site, en iOS, iPadOS et macOS 27.0.
macOS 27 retire ce levier aux équipes de support, mais leur en donne un autre. La même configuration accueille un contrôle natif de l’exécution, dans son dictionnaire Allowed. Sur macOS, ce sont AllowedBinaries et DeniedBinaries, qui filtrent les binaires sur leurs propriétés de signature, un binaire ne correspondant que si tous les identifiants correspondent. Les valeurs se génèrent avec codesign -dvvv <chemin_du_binaire>. Sur iOS, tvOS et visionOS, l’équivalent est AllowedApps et DeniedApps, sur les bundle IDs. Le périmètre macOS couvre donc les outils en ligne de commande et pas seulement les applications graphiques, ce qui évite de recourir à un script maison ou à un outil tiers pour ce seul besoin. Les processus critiques du système, eux, continuent de s’exécuter quoi qu’il arrive.
App Settings : le dictionnaire Allowed, avec AllowedBinaries et DeniedBinaries côté macOS.
Un point de vigilance sur AlwaysAllowManagedApps. Elle inclut implicitement les applications gérées dans la liste d’autorisation effective, mais uniquement lorsque AllowedBinaries est présente, et elle ne couvre pas une application simplement déposée dans /Applications par un paquet ou un script. Une politique trop stricte bloquera donc les outils internes, les binaires compilés localement et les applications installées hors catalogue. Audit, qualification, déploiement progressif, puis seulement politique restrictive.
3. L’ère Intel se termine, et pas seulement côté matériel
macOS 26 était la dernière version compatible avec les Mac Intel. macOS 27 est la première réservée aux Mac Apple silicon.
S’y ajoute un second point, qui pèse davantage sur la planification : macOS 27 est aussi la dernière version à proposer Rosetta 2 comme technologie de traduction généraliste. Au-delà, seul un sous-ensemble destiné à certains frameworks de jeu sera conservé. Le parc x86 est donc hors course dès maintenant, tandis que les dépendances x86 du reste du parc ne deviendront bloquantes qu’au palier majeur suivant. Ces deux horizons ne se planifient pas de la même manière.
L’inventaire doit couvrir les applications Intel et Universal, mais aussi les plug-ins, frameworks, agents de sécurité, outils internes et composants auxiliaires. Ce sont rarement les applications connues qui posent problème : personne ne rate une suite métier qui refuse de démarrer. Une dépendance Intel enfouie dans un plug-in, un agent ou un utilitaire appelé une fois par mois traverse le cycle macOS 27 sans se signaler, et casse au palier suivant, à un moment où plus personne ne fait le lien avec la migration.
Un poste peut être parfaitement compatible avec macOS 27 tout en restant incompatible avec une application métier critique.
4. Réseau et identité
TLS et inspection HTTPS. Plusieurs processus système appliquent des exigences réseau renforcées sur les OS 27, notamment pour la gestion du parc, l’enrôlement et l’installation d’applications et de mises à jour. Les services de gestion doivent prendre en charge TLS 1.2 au minimum, avec des suites cryptographiques et des certificats conformes aux nouvelles exigences App Transport Security.
Le point de rupture concerne les infrastructures qui pratiquent l’inspection HTTPS. Lorsqu’un proxy ou une appliance de sécurité intercepte une connexion Apple et présente son propre certificat, l’architecture peut devenir incompatible avec certains services. Avant migration, il faut tester l’enrôlement, les échanges MDM et DDM, les mises à jour, l’installation d’applications et les services Apple associés, puis exclure les flux Apple concernés de l’inspection lorsque c’est nécessaire.
Apple poursuit par ailleurs la bascule des configurations réseau vers le DDM, avec sept nouvelles configurations déclaratives couvrant le VPN par plug-in, IKEv2, IPsec, le VPN permanent, le proxy DNS, les réglages DNS et les relais. Le mouvement est net côté payloads historiques : celui du proxy DNS, par exemple, voit l’ensemble de ses clés marquées dépréciées en iOS 27.0, macOS 27.0 et visionOS 27.0.
Payload DNS Proxy : l’ensemble des clés dépréciées en iOS, macOS et visionOS 27.0.
Platform SSO. Côté authentification, macOS 27 ajoute la possibilité d’exiger Touch ID comme second facteur au déverrouillage FileVault, à l’écran de verrouillage et à la fenêtre de connexion. Une authentification web affiche une vue sécurisée à ces mêmes étapes, ce qui permet à l’IdP de dérouler ses propres parcours multi-étapes et multifacteur. S’y ajoute la connexion par QR code, l’accès caméra étant géré dans un processus système isolé.
macOS 27 autorise également la connectivité réseau pendant le déverrouillage FileVault. Basculer de réseau ou traiter un portail captif à cette étape devient possible, ce qui change beaucoup de choses pour les postes nomades.
Avant d’ouvrir ce chantier, il faut couvrir la création de compte, l’authentification, le changement de mot de passe, le fonctionnement hors ligne, FileVault et la récupération après incident. Un Platform SSO mal qualifié ne produit pas une gêne, il produit des postes sur lesquels personne n’arrive plus à ouvrir de session.
5. Enrôlement et cycle de vie : la sauvegarde ne remplace plus le MDM
Un terminal ne restaure plus les informations de gestion depuis une sauvegarde, profil d’enrôlement et statut de supervision compris. Les appareils présents dans Apple Business Manager ou Apple School Manager s’enrôlent automatiquement via ADE à la place.
Le modèle cible pour les appareils appartenant à l’organisation reste donc Apple Business Manager, puis ADE, activation, MDM et configuration. Sur ce périmètre, l’ADE devient le seul chemin fiable.
Return to Service progresse de son côté : réessai automatique en cas d’échec d’enrôlement, avec un délai croissant pouvant aller jusqu’à cinq minutes, configuration de la langue et de la région, et possibilité d’imposer une mise à jour système pendant la réinitialisation.
Le point critique reste la connectivité après effacement. Wi-Fi, 802.1X, certificats, DNS et proxy doivent être testés dans ce contexte précis, sans quoi le terminal ne revient jamais jusqu’au MDM.
Côté supervision, le Status Channel enrichit les remontées proactives : type d’enrôlement, attente de configuration, statut Return to Service, indication iPad partagé, informations APNs, statut du mode Isolement et, sur iPhone et iPad uniquement, santé matérielle. On passe d’un MDM qui interroge le parc à un parc qui signale ses changements d’état, ce qui réduit le recours à l’interrogation périodique sur les grandes flottes.
Ajout utile au support, les commandes TriggerEnhancedLogCollection et CancelEnhancedLogCollection déclenchent à distance une collecte de logs enrichie, en mode interactif ou non, avec remontée de statut. Sur un incident difficile à reproduire, cela évite plusieurs allers-retours avec l’utilisateur.
6. Apple Intelligence : un sujet de gouvernance, et une spécificité européenne
Les contrôles déclaratifs pour Apple Intelligence ne datent pas d’OS 27. Les configurations com.apple.configuration.intelligence.settings et com.apple.configuration.siri.settings existent depuis iOS 26.4 et macOS 26.4, avec AllowGenmoji, AllowImagePlayground, AllowImageWand, AllowWritingTools, AllowAppleIntelligenceReport, ou côté Siri Enabled, AllowWhileLocked et ForceProfanityFilter.
Ce qu’OS 27 ajoute tient en trois clés, et elles sont bien choisies. AllowVisualIntelligence, qui remplace AllowVisualIntelligenceSummary désormais dépréciée. ForceReduceSensitiveContent, pour contraindre Siri à limiter les contenus sensibles. Et surtout AllowSiriAI, qui désactive spécifiquement les fonctions Siri issues de l’IA, sans toucher au reste de Siri. Les trois sont en iOS 27.0, macOS 27.0 et visionOS 27.0.
L’outillage de gouvernance existait donc déjà. Ce qui arrive avec OS 27, c’est la possibilité de trancher finement, et en particulier de désactiver la couche IA de Siri en gardant l’assistant.
Les App Intents méritent une place dans les audits applicatifs. Une application métier peut exposer certaines actions au système et les rendre accessibles aux mécanismes d’intelligence. Cela ne signifie pas que Siri interroge n’importe quel CRM ou ERP, tout dépend de ce que l’application expose. La question à poser devient : quelles applications métier exposent des App Intents, et quelles données ou actions rendent-elles accessibles ?
Spécificité européenne : Apple a annoncé en juin 2026 le report des fonctions Siri avancées dans l’Union européenne sur iOS 27, iPadOS 27 et watchOS 27, en invoquant ses obligations au titre du DMA, et indique qu’il n’existe à ce jour aucun calendrier de disponibilité. Sont notamment concernées la nouvelle application permettant de revenir sur ses conversations, l’expérience Visual Intelligence étendue, les outils d’écriture intégrés et le mode Siri dans l’app Appareil photo. macOS 27 et visionOS 27 ne sont pas concernés et disposent de ces fonctions dans l’UE.
Une politique d’usage de l’IA doit donc se décliner par plateforme et par région. Concrètement, un même collaborateur disposera de la fonction sur son Mac et pas sur son iPhone, ce qui est difficile à expliquer si personne ne l’a anticipé. À noter que AllowSiriAI porte précisément sur ce périmètre : une organisation qui veut un comportement homogène entre l’UE et le reste de son parc dispose maintenant du levier pour l’imposer.
Les 6 contrôles à lancer avant le déploiement
1. Valider le DDM : prise en charge réelle des déclarations Software Update et des rapports de statut, et politique de report reconstruite côté déclaratif.
2. Requalifier le support : scénarios de téléassistance rejoués de bout en bout sur macOS 27, et surtout supervision dans la durée de l’état réel des permissions, qu’un utilisateur peut désormais retirer depuis les Réglages Système.
3. Contrôler le parc Mac : matériel Intel, dépendances x86 jusque dans les composants auxiliaires, séquestre et disponibilité du Bootstrap Token, agents de sécurité et applications métier critiques.
4. Auditer le réseau : TLS 1.2 minimum, suites cryptographiques et certificats conformes ATS, proxy et périmètre d’inspection HTTPS sur les flux Apple.
5. Tester le retour en service : effacement puis réenrôlement complet d’un terminal mobile, en vérifiant la reconnexion Wi-Fi, 802.1X, certificats, DNS et proxy, puisqu’une sauvegarde ne ramènera plus l’appareil sous gestion.
6. Cartographier l’IA : contrôles Apple Intelligence, App Intents exposés par les applications métier et déclinaison par région.
Conclusion
Vérifier qu’un matériel est compatible avec le nouvel OS ne suffit plus. Sur les OS 27, des mécanismes d’administration disparaissent, et des scénarios d’exploitation entiers changent de comportement sans changer d’apparence, ce qui est nettement plus difficile à détecter.
La qualification doit couvrir toute la chaîne : OS, MDM et DDM, réseau, identité, sécurité, applications et support. C’est long, et c’est précisément pour cette raison que beaucoup de migrations s’arrêtent au contrôle de compatibilité matérielle. Les ruptures apparaissent ensuite, en production, plusieurs semaines après le déploiement.
Chez Netopie, nous accompagnons les DSI sur ces six contrôles : validation de la chaîne DDM avec votre MDM, requalification des scénarios de téléassistance, inventaire du parc et des dépendances x86, analyse des flux Apple face à votre inspection TLS, tests de retour en service et cadrage de la gouvernance Apple Intelligence.