Retour au blog

Jamf Pro et OS 27 : migrer les mises à jour vers le MDM déclaratif

Article créé le 8 septembre 2026 · Source analysée le 8 septembre 2026 · Source officielle : Jamf · Thème : Jamf Pro, mises à jour Apple et DDM

Jamf Pro 11.31 établit la correspondance entre les mécanismes Apple de mise à jour retirés avec macOS, iOS, iPadOS et tvOS 27 et les fonctions Jamf qui en dépendent. Pour une DSI, le risque n’est plus abstrait : certaines commandes à distance, restrictions et automatisations peuvent cesser de fonctionner ou conserver des données obsolètes si elles ne sont pas remplacées par les flux déclaratifs pris en charge.

1. Ce que Jamf documente précisément

Jamf rappelle qu’Apple a déprécié à la WWDC 2025 les commandes MDM historiques de mise à jour au profit de Declarative Device Management. Dans ses notes Jamf Pro 11.31, l’éditeur indique que ScheduleOSUpdate, le payload macOS com.apple.SoftwareUpdate et les clés de restriction forceDelayedSoftwareUpdates et enforcedSoftwareUpdateDelay sont retirés sur les OS 27.

Dans Jamf Pro, cela concerne notamment les commandes « Download » et « Download and Install », presque toutes les commandes de mises à jour gérées et les réglages de report correspondants. Jamf avertit que les workflows, Smart Groups ou automatisations qui en dépendent peuvent échouer silencieusement ou exposer un état périmé.

2. Les mécanismes qui restent pris en charge

La déclaration softwareupdate.enforcement.specific reste prise en charge : elle alimente la commande « Download and schedule to install » et le composant Software Updates des Blueprints. La déclaration softwareupdate.settings, utilisée par le composant Software Update Settings des Blueprints, reste également disponible.

Jamf classe aussi comme pris en charge le payload de politique reposant sur le binaire softwareupdate sur macOS. Cette coexistence ne signifie pas que tous les chemins ont la même qualité opérationnelle : les équipes doivent identifier le mécanisme réellement appelé par chaque action de l’interface, script ou API.

3. Qu’est-ce que cette annonce change pour une entreprise belge ou française ?

Pour une PME, le point critique est de vérifier que le prestataire MDM ne pilote pas encore les mises à jour uniquement par commandes héritées. Pour une ETI, une grande entreprise ou une administration en Belgique ou en France, le chantier touche aussi les groupes dynamiques, fenêtres de maintenance, tableaux de conformité, procédures de support et preuves de patching.

Un parc mixte OS 26 et OS 27 peut masquer le problème : un même workflow peut réussir sur les appareils restés en OS 26 et échouer sur les nouveaux systèmes. Les équipes sécurité doivent donc mesurer le résultat par version d’OS et par appareil, pas seulement l’envoi de la commande depuis Jamf.

4. Lecture Underside : auditer les dépendances, pas seulement les profils

Notre lecture est que la migration doit partir d’un inventaire des intentions — imposer une version, différer une mise à jour, planifier une installation, prouver la conformité — puis relier chacune au mécanisme Jamf sous-jacent. Supprimer un ancien profil ne suffit pas si un script, une action de masse ou un Smart Group dépend encore de son état.

Ce travail complète notre dossier sur la fin des anciens flux MDM Apple et l’analyse d’Apple Software Lookup pour le patching déclaratif. Apple Business Manager et Automated Device Enrollment posent le cadre de propriété et de supervision ; Jamf doit ensuite appliquer et vérifier la politique de mise à jour.

5. Plan de migration recommandé

Objectif : conserver une chaîne de patching mesurable lorsque les OS 27 retirent les anciens mécanismes MDM, sans attendre les premiers échecs silencieux en production.

Auditer vos mises à jour Jamf et Apple

Source officielle : Jamf Pro 11.31 — OS 27 Software Update Deprecations and Affected Jamf Pro Features.