macOS 27 pour les administrateurs Mac : commandes MDM de mise à jour supprimées, TLS plus strict

Si vous gérez des Mac, macOS 27 Golden Gate modifie deux éléments qui n'apparaissent sur l'écran d'aucun utilisateur, mais qui peuvent mettre à terre un processus de correctifs ou un flux d'inscription en une journée. Premièrement, les commandes, requêtes et restrictions MDM de mise à jour logicielle que la plupart des parcs utilisent depuis dix ans ne fonctionnent plus sur les appareils exécutant 27.0. Deuxièmement, chaque connexion du chemin de gestion — MDM, Declarative Device Management, Automated Device Enrollment, installation de profils, installation d'applications et mises à jour logicielles — refuse désormais les serveurs qui ne respectent pas les règles App Transport Security (ATS), alors que les versions précédentes se contentaient de consigner un avertissement.

Aucun de ces deux changements n'est une information nouvelle. Apple les a annoncés avant et pendant la WWDC 2026. Mais maintenant que 27.0 est sorti (le 14 septembre, build 26A428), ils sont actifs sur tout Mac qui effectue la mise à niveau. Ce guide passe en revue ce qui cesse de fonctionner, en s'appuyant sur le schéma et les documents d'assistance d'Apple, comment auditer vos serveurs avant que vos premiers Mac ne rencontrent le problème, et ce qui remplace chaque mécanisme hérité.

Points clés

• La gestion héritée des mises à jour logicielles a disparu sur 27.0. Apple : « La gestion héritée des mises à jour logicielles ne fonctionne plus sur l'ensemble des systèmes d'exploitation 27.0. » Cela couvre les commandes ScheduleOSUpdate, ScheduleOSUpdateScan, AvailableOSUpdates et OSUpdateStatus, le payload com.apple.SoftwareUpdate, ainsi que les restrictions de report.
• Le remplacement est déclaratif. softwareupdate.enforcement.specific impose une version avant une échéance donnée. softwareupdate.settings couvre les reports, les actions automatiques, les Background Security Improvements et l'inscription aux versions bêta. Les status items remplacent les requêtes.
• La cadence recommandée n'a pas d'équivalent sur macOS. Le schéma d'Apple indique que la clé déclarative RecommendedCadence n'est pas disponible sur macOS.
• Les règles TLS sont désormais appliquées sur l'ensemble du chemin de gestion. Cela signifie TLS 1.2 ou ultérieur, des suites de chiffrement à confidentialité persistante (forward secrecy), des certificats RSA ≥ 2048 bits ou ECDSA ≥ 256 bits signés avec SHA-2, ainsi que l'extension extended master secret. Seuls les serveurs SCEP et les serveurs de mise en cache de contenu sont exemptés.
• Vous pouvez auditer avant même que les appareils ne passent à la mise à niveau. Sur les versions précédentes, les mêmes vérifications se contentent de consigner des avertissements. Apple documente le prédicat de journal permettant de les repérer.

Changement 1 : la gestion héritée des mises à jour logicielles ne fonctionne plus

La mise à jour « device management » présentée par Apple à la WWDC 2026 le résume en une phrase : « La gestion héritée des mises à jour logicielles ne fonctionne plus sur l'ensemble des systèmes d'exploitation 27.0. » Elle énumère ensuite ce que cela recouvre : les commandes de mise à jour logicielle, les requêtes de mise à jour logicielle, les réglages de cadence recommandée, et les restrictions de mise à jour logicielle, y compris les reports et les Background Security Improvements.

Le schéma de gestion des appareils publié par Apple — les fichiers YAML du dépôt apple/device-management sur lesquels s'appuient les éditeurs de solutions MDM — indique le statut précis de chaque élément. Pour macOS :

Mécanisme hérité	Statut du schéma (macOS)	Remplacement déclaratif
Commande ScheduleOSUpdate	Déprécié en 26.0, supprimé en 27.0	com.apple.configuration.softwareupdate.enforcement.specific
Commande ScheduleOSUpdateScan	Déprécié en 26.0, supprimé en 27.0	Inutile — l'appareil analyse de lui-même et rapporte son statut
Requête AvailableOSUpdates	Déprécié en 26.0, supprimé en 27.0	Status item softwareupdate.pending-version
Requête OSUpdateStatus	Déprécié en 26.0, supprimé en 27.0	Status items softwareupdate.install-state, softwareupdate.failure-reason, softwareupdate.install-reason
Payload de profil com.apple.SoftwareUpdate	Déprécié en 26.0, supprimé en 27.0	com.apple.configuration.softwareupdate.settings
Restrictions forceDelayedSoftwareUpdates, forceDelayedMajorSoftwareUpdates, forceDelayedAppSoftwareUpdates, enforcedSoftwareUpdateDelay	Déprécié en 26.0, supprimé en 27.0	softwareupdate.settings → Deferrals

L'instantané de schéma que nous avons utilisé correspond à la branche release du dépôt au 18 septembre 2026. Si la console de votre éditeur MDM affiche encore les options héritées, elles concernent les appareils sous 26.x et versions antérieures. Sur un Mac exécutant 27.0, elles n'ont plus aucun effet.

Ce que couvrent les réglages déclaratifs

La configuration softwareupdate.settings est l'endroit où la plupart des restrictions héritées ont été déplacées. Voici ses clés de premier niveau, d'après le schéma d'Apple :

Clé	Ce qu'elle contrôle
Notifications	Si l'utilisateur voit les notifications de mise à jour
Deferrals	CombinedPeriodInDays, MajorPeriodInDays, MinorPeriodInDays, SystemPeriodInDays
AutomaticActions	Download, InstallOSUpdates, InstallSecurityUpdate
RapidSecurityResponse	Enable, EnableRollback — intitulée « Background Security Improvements settings » dans le schéma
AllowStandardUserOSUpdates	Si un utilisateur non administrateur peut installer les mises à jour du système
Beta	ProgramEnrollment, OfferPrograms, RequireProgram pour AppleSeed et les bêtas développeurs
RecommendedCadence	Marqué « n/a » pour macOS dans le schéma

Le schéma précise également que les Background Security Improvements « ne sont pas pris en compte par le mécanisme de report Major, Minor ou System ». Un report sur les mises à jour majeures ne retarde donc pas un correctif de sécurité en arrière-plan. Si vous devez les contrôler, utilisez les clés RapidSecurityResponse. Notre guide sur les Background Security Improvements explique en quoi consistent ces mises à jour.

Le vide laissé par la cadence recommandée

Le MDM hérité permettait de définir une « cadence recommandée » qui déterminait quelle mise à jour un utilisateur voyait lorsqu'une mise à jour mineure et une nouvelle version majeure étaient toutes deux disponibles. Apple classe la cadence recommandée parmi les réglages hérités qui cessent de fonctionner, et la clé déclarative RecommendedCadence du schéma actuel indique introduced: n/a pour macOS. Il n'existe donc aujourd'hui aucun remplacement équivalent sur Mac.

En pratique, vous façonnez ce que voient les utilisateurs avec les reports (deferrals), qui masquent une version pendant un nombre défini de jours, et l'application forcée (enforcement), qui impose la version souhaitée avant une échéance. Cela demande plus de travail qu'un simple interrupteur de cadence, et il vaut mieux prévenir votre service d'assistance de ce changement avant que les utilisateurs ne commencent à demander pourquoi une mise à niveau majeure apparaît soudainement.

Imposer une version sur 27.0

La déclaration d'application forcée (enforcement) est celle que vous utiliserez le plus. Elle définit une cible et une échéance :

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.su.macos-27-0-1",
  "Payload": {
    "TargetOSVersion": "27.0.1",
    "TargetLocalDateTime": "2026-10-15T18:00:00",
    "DetailsURL": "https://intranet.example.com/updates"
  }
}

TargetOSVersion et TargetLocalDateTime sont les clés essentielles. Il existe aussi TargetBuildVersion pour cibler un build précis, qui est prioritaire lorsque les deux sont renseignées. La version de l'exemple est purement illustrative — au moment de la rédaction, aucune 27.0.1 n'est encore sortie. Votre éditeur MDM vous proposera généralement un formulaire plutôt que du JSON brut, mais connaître ces clés aide lorsque vous consultez la déclaration dans le statut d'un appareil pour comprendre pourquoi elle ne s'est pas installée.

Une même politique, écrite des deux façons

Un exemple concret rend la migration plus facile à visualiser. Prenons une politique courante : retenir les mises à niveau majeures pendant 30 jours, tout en laissant activés le téléchargement automatique et les mises à jour de sécurité.

La version héritée est un ensemble de clés de restriction dans un payload com.apple.applicationaccess :

<key>forceDelayedMajorSoftwareUpdates</key>
<true/>
<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>30</integer>

Un Mac sous Tahoe respecte cela. Un Mac sous Golden Gate l'ignore.

La version déclarative exprime la même intention en une seule configuration :

{
  "Type": "com.apple.configuration.softwareupdate.settings",
  "Identifier": "com.example.su.settings",
  "Payload": {
    "Deferrals": { "MajorPeriodInDays": 30 },
    "AutomaticActions": {
      "Download": "AlwaysOn",
      "InstallSecurityUpdate": "AlwaysOn"
    }
  }
}

Trois détails du schéma d'Apple méritent d'être connus avant de rédiger la vôtre :

• Les valeurs de report vont de 1 à 90 jours, la même plage que les anciennes clés de délai.
• Lorsque plusieurs déclarations définissent la même clé, l'appareil les combine selon une règle. Les reports utilisent number-max (le report le plus long l'emporte), les actions automatiques utilisent enum-last, et Notifications utilise boolean-and — si une seule déclaration désactive les notifications, elles sont désactivées. Une déclaration de test oubliée avec un report de 90 jours écrasera silencieusement votre politique de 30 jours ; vérifiez donc ce qui est assigné avant de déboguer quoi que ce soit d'autre.
• Les actions automatiques acceptent Allowed, AlwaysOn ou AlwaysOff, avec Allowed par défaut. Le schéma d'Apple décrit AlwaysOn comme « toujours activé » et AlwaysOff comme « toujours désactivé ». Allowed est le choix à privilégier si vous souhaitez laisser la décision à l'utilisateur.

Relire le résultat

La gestion déclarative rapporte son état via des status items plutôt que des requêtes. L'item softwareupdate.install-state prend l'une de cinq valeurs : none, downloading, prepared, installing ou failed. Associé à softwareupdate.pending-version, qui indique ce que l'appareil compte installer, et à softwareupdate.failure-reason en cas de problème, on retrouve tout ce que fournissait l'ancienne requête OSUpdateStatus. Et l'appareil l'envoie dès que l'état change, plutôt que lorsque vous pensez à le demander.

Le piège du parc mixte

Pendant la prochaine année, votre parc comprendra des Mac sous Tahoe 26.x, qui respectent encore les mécanismes hérités dépréciés, et des Mac sous Golden Gate 27.0, qui les ignorent. Cela crée trois risques :

1. Un report qui ne fonctionne qu'à moitié. Une restriction héritée forceDelayedMajorSoftwareUpdates retient encore les Mac sous Tahoe. Une fois qu'un Mac est passé à 27, seul un réglage déclaratif Deferrals l'affecte. Si vous voulez la même politique des deux côtés, définissez-la aux deux endroits.
2. Des rapports qui deviennent vides. Les tableaux de bord construits sur les réponses OSUpdateStatus et AvailableOSUpdates n'affichent plus rien pour les appareils sous 27.0. Faites basculer vos rapports vers les status items déclaratifs avant que ces appareils n'apparaissent comme « unknown ».
3. Des scripts qui présument que la commande est bien arrivée. Une automatisation qui envoie ScheduleOSUpdate et attend un résultat attendra indéfiniment sur un Mac sous 27.0. Vérifiez vos runbooks et vos scripts d'API auprès de votre MDM à la recherche d'appels de commandes héritées.

L'approche la plus simple consiste à faire basculer dès maintenant tous les Mac vers la gestion déclarative des mises à jour logicielles, y compris ceux encore sous Tahoe, où les déclarations DDM de mise à jour logicielle fonctionnent déjà. Ne conservez les réglages hérités que comme filet de sécurité pour les appareils que vous ne pouvez pas encore basculer. Notre guide sur pourquoi macOS 27 n'apparaît pas dans Mise à jour de logiciels explique comment les reports déterminent si la mise à niveau est proposée en premier lieu.

Changement 2 : un TLS plus strict pour le chemin de gestion

Apple a publié ces exigences dans son article d'assistance Prepare your network environment for stricter security requirements, daté du 9 juin 2026, et les répète dans les notes de version de macOS 27. Les serveurs situés sur le chemin de gestion doivent respecter les points suivants :

Exigence	Détail
Protocole	TLS 1.2 ou ultérieur ; TLS 1.3 « chaque fois que possible »
Suites de chiffrement	Confidentialité persistante (forward secrecy) — toute suite TLS 1.3, ou suites TLS 1.2 avec ECDHE
Clés de certificat	RSA d'au moins 2048 bits, ECDSA d'au moins 256 bits
Hachage de signature	SHA-2 avec une empreinte d'au moins 256 bits
Extension TLS 1.2	Extended master secret (EMS), RFC 7627

Les flux concernés, selon la liste d'Apple : la gestion des appareils mobiles (MDM), le Declarative Device Management, l'Automated Device Enrollment, l'installation de profils de configuration, l'installation d'applications (y compris la distribution d'applications d'entreprise), et les mises à jour logicielles.

Deux exceptions sont explicitement mentionnées. Les connexions à un serveur SCEP, lors de l'installation d'un profil ou de la résolution d'un asset DDM, ne sont pas concernées. Il en va de même pour les serveurs de mise en cache de contenu, même lorsqu'ils servent des assets liés aux applications ou aux mises à jour logicielles.

Ce qui change sur 27.0, c'est la conséquence. L'article d'Apple : « Les connexions non conformes sont bloquées et les messages de journal apparaissent comme des erreurs plutôt que comme des avertissements. » La vérification elle-même n'a rien de nouveau. Les versions précédentes consignaient déjà ces violations sous forme d'avertissements, ce qui rend justement possible un audit dès maintenant.

Où se cache encore l'ancien TLS

Les services MDM publics sont conformes depuis des années. Le risque réside dans ce que vous hébergez vous-même ou que vous placez dans le chemin :

• Un MDM auto-hébergé derrière un reverse proxy ou un répartiteur de charge ancien, dont la configuration TLS a été définie une fois pour toutes et jamais revue
• La distribution interne d'applications — le serveur hébergeant les manifestes d'applications d'entreprise et les fichiers .ipa ou .pkg
• Les hébergeurs de paquets et d'assets vers lesquels pointent les déclarations d'assets DDM ou les flux d'installation personnalisés
• Les pare-feu et proxys inspectant le TLS, qui re-signent le trafic avec leur propre certificat, lequel doit alors respecter les mêmes exigences de taille de clé et de hachage
• Les anciennes chaînes de certificats — clés RSA 1024 bits ou signatures SHA-1 sur une autorité de certification interne
• Les anciennes piles TLS qui négocient TLS 1.2 mais pas l'extension extended master secret

Comment auditer avant la mise à niveau de vos Mac

Étape 1 : tester chaque serveur avec nscurl

macOS inclut un outil de test ATS. Pointez-le vers chaque serveur de votre chemin de gestion :

nscurl --ats-diagnostics https://mdm.example.com

Il teste la connexion selon une série de configurations ATS et affiche Result : PASS ou Result : FAIL pour chacune. Le premier bloc, Default ATS Secure Connection, est celui qui compte ici. Par mesure de contrôle, nous l'avons exécuté sur un Mac sous Tahoe contre deux serveurs publics. www.apple.com a réussi les 61 vérifications. Un serveur de test public ne proposant que TLS 1.0 n'en a réussi aucune, à commencer par la connexion sécurisée par défaut.

Étape 2 : vérifier l'extended master secret

nscurl ne fait pas apparaître l'EMS séparément, alors que c'est l'exigence que les anciennes piles TLS ont le plus de chances de manquer. OpenSSL 3.x la signale directement. L'openssl système sur macOS est en réalité LibreSSL ; utilisez donc une version installée via Homebrew :

echo | openssl s_client -connect mdm.example.com:443 -tls1_2 -servername mdm.example.com 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Extended master secret"

Sur www.apple.com, cela affiche Protocol: TLSv1.2, un chiffrement ECDHE-RSA-AES256-GCM-SHA384, une clé serveur de 2048 bits et Extended master secret: yes. Vous voulez que chaque serveur du chemin ressemble à cela, ou fasse mieux.

Étape 3 : laissez les appareils vous le dire

Tester serveur par serveur ne couvre que les serveurs que vous connaissez déjà. L'audit recommandé par Apple couvre le reste en enregistrant à quoi les appareils se connectent réellement :

1. Installez le profil Network Diagnostics Logging d'Apple sur un Mac de test.
2. Exécutez les flux qui vous intéressent : inscription, installation de profil, installation d'application, mise à jour logicielle.
3. Récupérez un sysdiagnose sur ce Mac.
4. Recherchez dans l'archive de journaux avec le prédicat fourni par Apple :

log show --archive system_logs.logarchive --info -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

Sur un Mac sous 26.x, les occurrences trouvées sont des avertissements : ces connexions seront bloquées lorsque ce Mac effectuera la mise à niveau. Sur un Mac sous 27.0, les mêmes occurrences apparaissent comme des erreurs, et ces connexions échouent déjà.

Exécutez ce test sur un Mac sous Tahoe, et vous obtenez la liste de ce qui va casser, avant que quoi que ce soit ne casse réellement.

Une checklist de déploiement

Voici l'ordre dans lequel nous procéderions, pour un parc sur le point de voir ses premières mises à niveau vers 27.0 :

1. Recensez chaque serveur du chemin de gestion : serveur MDM et URL de check-in, configuration Automated Device Enrollment, hébergeurs de manifestes d'applications et de paquets, URL d'assets DDM, ainsi que tout proxy ou pare-feu inspectant ce trafic.
2. Exécutez nscurl --ats-diagnostics contre chacun d'eux et corrigez tout ce qui échoue à la connexion sécurisée par défaut.
3. Vérifiez l'EMS avec OpenSSL 3.x sur chaque serveur qui termine du TLS 1.2.
4. Exécutez l'audit de journaux d'Apple sur un Mac de test sous Tahoe, à travers un cycle complet allant de l'inscription à la mise à jour.
5. Recréez votre politique de mise à jour de façon déclarative : déclarations d'application forcée pour les versions cibles, softwareupdate.settings pour les reports, les actions automatiques et les Background Security Improvements.
6. Faites basculer vos rapports de OSUpdateStatus et AvailableOSUpdates vers les status items déclaratifs.
7. Recherchez dans votre automatisation les noms de commandes héritées : ScheduleOSUpdate, ScheduleOSUpdateScan, AvailableOSUpdates, OSUpdateStatus.
8. Prévenez le service d'assistance que le masquage de mises à jour basé sur la cadence a disparu sur 27.0, et de ce que les utilisateurs verront à la place.
9. Effectuez la mise à niveau d'un groupe pilote, et confirmez que l'inscription, l'installation d'applications et l'application forcée des mises à jour fonctionnent toujours sur du matériel 27.0 réel avant d'élargir le déploiement.

Dépannage des problèmes courants

Un Mac sous 27.0 ignore l'échéance de mise à jour que vous avez définie

Problème : un Mac ayant effectué la mise à niveau vers Golden Gate n'installe pas la mise à jour mineure exigée par votre politique.

Solution : vérifiez quel mécanisme la politique utilise. S'il s'agit d'une commande héritée ScheduleOSUpdate ou d'une restriction MDM, elle ne fonctionne plus sur 27.0. Déployez à la place une déclaration softwareupdate.enforcement.specific, et consultez le statut softwareupdate.failure-reason de l'appareil si l'installation échoue toujours.

Les rapports de mise à jour affichent « unknown » pour les nouveaux Mac

Problème : votre tableau de bord de correctifs n'affiche aucune donnée de mise à jour pour les Mac sous 27.0.

Solution : le tableau de bord lit des réponses de requêtes héritées. Faites-le basculer vers les status items déclaratifs softwareupdate.install-state et softwareupdate.pending-version.

L'inscription fonctionne sur Tahoe et échoue sur Golden Gate

Problème : un nouveau Mac sous 27.0 échoue pendant l'Automated Device Enrollment, alors qu'un Mac sous Tahoe avec la même configuration réussit.

Solution : il s'agit du changement TLS, jusqu'à preuve du contraire. Testez chaque URL du flux d'inscription avec nscurl --ats-diagnostics, et vérifiez les journaux de l'appareil à la recherche d'erreurs ATS provenant de mdmclient, Setup Assistant ou profiles.

Les applications d'entreprise ne s'installent pas sur 27.0

Problème : les applications personnalisées distribuées depuis votre propre serveur ne parviennent pas à s'installer.

Solution : l'hébergeur du manifeste ou du paquet échoue probablement aux exigences TLS. Il s'agit souvent d'un ancien serveur web qui n'a jamais fait partie de l'effort de durcissement du MDM. Les serveurs de mise en cache de contenu étant exemptés, le problème vient du serveur d'origine.

Un pare-feu inspectant le TLS casse le trafic de gestion

Problème : tout fonctionne en dehors du réseau de l'entreprise et échoue une fois dessus.

Solution : l'appareil d'inspection re-signe les connexions avec son propre certificat et ses propres réglages TLS, lesquels doivent désormais respecter les exigences ATS. Mettez à niveau sa configuration, ou excluez vos hôtes de gestion et les points de terminaison MDM d'Apple de l'inspection.

FAQ

Les commandes héritées de mise à jour logicielle fonctionnent-elles encore sur macOS 26 ?

Oui. Le schéma d'Apple les marque comme dépréciées en 26.0 et supprimées en 27.0 ; les Mac sous Tahoe les respectent donc encore. Les Mac sous 27.0, non. Pendant la transition, définissez vos politiques de façon déclarative afin que tous les Mac obtiennent le même résultat.

Qu'est-ce qui remplace le réglage de cadence recommandée ?

Sur macOS, rien directement. Le schéma d'Apple marque la clé déclarative RecommendedCadence comme indisponible sur macOS. Utilisez les reports pour masquer des versions et les déclarations d'application forcée pour exiger la version souhaitée.

Les serveurs de mise en cache de contenu sont-ils concernés par le changement TLS ?

Non. Apple répertorie les serveurs de mise en cache de contenu comme une exception, « même lors de la demande d'assets liés à l'installation d'applications ou aux mises à jour logicielles ». Les serveurs SCEP sont eux aussi exemptés.

Comment savoir lesquels de mes serveurs échoueraient, avant toute mise à niveau de Mac ?

Installez le profil Network Diagnostics Logging d'Apple sur un Mac de test sous Tahoe, exécutez vos flux, récupérez un sysdiagnose et effectuez une recherche avec le prédicat de journal fourni dans l'article d'assistance d'Apple. Sur 26.x, les violations apparaissent comme des avertissements, ce qui vous permet de les voir avant qu'elles ne cassent quoi que ce soit.

Cela change-t-il quelque chose pour les Mac non gérés ?

Le changement de mise à jour logicielle, non. La règle TLS couvre aussi les mises à jour logicielles et l'installation d'applications pour tous les Mac, mais ceux-ci se connectent normalement aux propres serveurs d'Apple, qui la respectent. Vous pouvez vérifier si un Mac est géré avec profiles status -type enrollment. Sur un Mac non géré, les deux lignes affichent « No ».

Conclusion

macOS 27 achève une évolution qu'Apple annonce depuis l'arrivée de la gestion déclarative. Le contrôle des mises à jour est désormais exclusivement déclaratif sur 27.0, et le chemin de gestion applique désormais la même sécurité de transport que n'importe quelle connexion d'application moderne. Aucun de ces deux changements ne touche l'interface utilisateur, si bien qu'un parc peut s'y heurter sans s'en apercevoir — jusqu'à ce qu'une échéance soit manquée ou qu'une inscription échoue.

Les deux peuvent être évités grâce à une préparation que vous pouvez réaliser dès aujourd'hui sur Tahoe. Testez vos serveurs, exécutez l'audit de journaux d'Apple sur un Mac, reconstruisez la politique de mise à jour de façon déclarative, et redirigez vos rapports. Faites cela avant l'arrivée des premiers Mac sous 27.0, et la mise à niveau deviendra une simple formalité.

Lectures complémentaires : Pourquoi macOS 27 n'apparaît pas dans Mise à jour de logiciels · Les Background Security Improvements expliquées · macOS 27 bloque l'accès aux données des autres applications · Guide de mise à jour du premier jour de macOS 27 Golden Gate · Guide de déploiement en entreprise de macOS Tahoe