Paquets macOS : passer au déploiement MDM déclaratif

Article créé le 17 août 2026 · Source analysée le 17 août 2026 · Source officielle : Apple Developer · Thème : macOS, paquets, MDM Apple et déploiement

Apple documente le cycle de vie déclaratif des paquets sur macOS : installation obligatoire ou optionnelle, mise à jour, retrait et remontée d’état. Pour une DSI, le gain n’est pas seulement de remplacer un script : il consiste à transformer chaque .pkg en objet de politique vérifiable sur les Mac supervisés.

1. Ce qu’Apple documente officiellement

La configuration com.apple.configuration.package permet à un service MDM d’installer et de suivre des paquets sur macOS. Elle s’applique uniquement à des appareils supervisés, au niveau système et sur le canal appareil. Le Mac télécharge un manifeste désigné par ManifestURL ; ce manifeste référence un seul paquet et fournit notamment son identifiant, sa version, son URL et son empreinte SHA‑256.

Apple impose un paquet signé dont la signature peut être vérifiée. L’installation peut être Required, donc lancée à l’application de la configuration, ou Optional, donc déclenchée par l’utilisateur depuis une app de gestion. Si le paquet installe une app, celle-ci peut ensuite être gérée séparément avec AppManaged.

2. La mise à jour reste une décision du MDM

Un paquet n’est pas mis à jour automatiquement. Le service de gestion doit modifier la valeur bundle-version du manifeste puis changer le ServerToken de la configuration. Le Mac relit alors le manifeste et installe la nouvelle version si nécessaire.

Cette mécanique rend la promotion explicite : qualification, pilote, généralisation et retour d’état peuvent suivre des groupes distincts. Elle exige en contrepartie une chaîne de publication fiable pour le manifeste, le paquet, son hash et son numéro de version. Un fichier remplacé sans mise à jour cohérente de ces éléments n’est pas une stratégie de patching.

3. Le retrait doit être décidé avant l’installation

Lorsque Remove vaut true dès l’installation, macOS suit les fichiers et dossiers créés ou modifiés par le paquet afin de pouvoir les retirer avec la configuration ou lors du désenrôlement. Les changements ultérieurs, notamment ceux d’un script post-installation ou de l’utilisateur, ne sont pas suivis.

Apple précise qu’activer Remove après l’installation ne recrée pas cet historique. Si l’option reste absente ou vaut false, seule la métadonnée système du paquet est retirée. La réversibilité doit donc être une décision de conception, validée avec l’éditeur et le métier, et non un réglage ajouté au moment d’un incident.

4. Qu’est-ce que cette évolution change pour une entreprise belge ou française ?

Pour une PME, ce modèle réduit la dépendance aux scripts isolés et améliore la visibilité du support. Pour une ETI, une grande entreprise ou une administration en Belgique ou en France, il permet de formaliser une chaîne logicielle commune entre Apple Business Manager, Automated Device Enrollment, Jamf ou un autre MDM, hébergement des paquets et gouvernance sécurité.

Les états déclaratifs distinguent notamment attente, téléchargement, installation, succès et échec avec leurs raisons. Les équipes IT peuvent ainsi mesurer le déploiement sans multiplier les interrogations périodiques. Cela ne remplace ni la qualification applicative ni la gestion des licences : le statut confirme l’état technique du paquet, pas la conformité contractuelle ou fonctionnelle de l’app qu’il contient.

5. Lecture Underside : traiter le paquet comme un artefact de supply chain

Notre lecture est qu’un paquet déclaratif doit être gouverné comme un artefact logiciel : source approuvée, signature vérifiée, hash immuable, propriétaire, version, périmètre, règle de retrait et preuve de déploiement. Le manifeste devient un contrat entre l’hébergement, le MDM et le Mac ; sa disponibilité et son intégrité entrent donc dans les contrôles d’exploitation.

Cette approche complète le cycle de vie déclaratif des apps gérées et la gestion déclarative des mises à jour Apple. Elle est particulièrement utile pour les agents de sécurité, outils réseau, connecteurs métier et composants non distribués par le Mac App Store.

6. Plan de migration recommandé

• Inventorier les paquets, propriétaires, sources, scripts et méthodes de mise à jour existantes.
• Vérifier supervision, support du MDM et portée système sur un groupe pilote.
• Signer chaque paquet et publier un manifeste versionné avec hash SHA‑256.
• Décider avant installation si le retrait des fichiers doit être activé.
• Séparer paquets obligatoires et catalogue optionnel, avec critères de promotion.
• Intégrer les états et raisons d’échec aux tableaux de bord et runbooks de support.

Source officielle : Apple Developer — Installing packages.