Dans tous les systèmes d'exploitation numérotés 27, Apple a supprimé la gestion des mises à jour logicielles en mode classique. Pas dépréciée : supprimée. Les commandes MDM, les requêtes et les restrictions que votre plateforme utilise depuis dix ans pour pousser les mises à jour iOS et macOS ne fonctionnent plus sur iOS 27, iPadOS 27 et macOS 27. La gestion déclarative (DDM) est désormais le seul moyen d'imposer une mise à jour sur un appareil Apple à jour.
Ce seul changement fait passer le DDM du débat d'architecture à l'échéance calendaire. Ce guide couvre ce qu'est la gestion déclarative, ce qu'elle change concrètement pour l'administrateur comme pour la personne qui tient l'appareil, et ce que le WWDC 2026 a modifié.
L'essentiel en six points
- Le MDM classique est impératif : le serveur envoie des commandes et interroge l'appareil pour connaître son état. Le DDM est déclaratif : le serveur envoie l'état attendu, l'appareil l'applique et signale les changements de lui-même.
- La gestion classique des mises à jour ne fonctionne plus sur aucun OS 27.0. La mise à jour déclarative est la seule voie.
- La déclaration l'emporte. Quand une déclaration et une ancienne commande MDM gèrent le même réglage, c'est la déclaration qui gagne.
- Le travail se déplace sur l'appareil. Les politiques continuent de s'appliquer hors ligne, prennent effet en quelques secondes et se réparent sans resynchronisation.
- L'utilisateur est prévenu, pas pris en embuscade. Les notifications peuvent démarrer 14 jours avant l'échéance, les reports vont de 1 à 90 jours, et le compte à rebours forcé de 60 secondes a disparu.
- C'est additif, et votre MDM doit masquer la couture. Déclaratif là où l'appareil sait le faire, impératif ailleurs, depuis une politique configurée une fois.
Ce qu'est vraiment la gestion déclarative
Le MDM classique est une conversation. Le serveur envoie une commande, l'appareil accuse réception, puis le serveur interroge l'appareil pour vérifier que l'état a bien pris. Chaque réglage est un échange à part. Multipliez par quelques milliers d'appareils et votre MDM passe sa journée à courir après des statuts au lieu de gérer quoi que ce soit.
Le DDM inverse la logique. Le serveur envoie des déclarations : des énoncés sur l'état dans lequel l'appareil doit se trouver. L'appareil les stocke, les applique lui-même, continue de les faire respecter qu'il joigne le serveur ou non, et ne rend compte que lorsque quelque chose change.
La différence est celle qui sépare un manager qui appelle toutes les heures pour savoir si la tâche est faite d'un manager qui confie l'objectif et fait confiance pour être alerté en cas de blocage. Apple a introduit le modèle au WWDC 2021 avec iOS 15. Il en élargit la couverture chaque année depuis, et avec les versions 27 il a commencé à refermer l'ancienne porte derrière lui.
Les briques du DDM
Une déclaration n'est pas un objet monolithique. Apple la découpe en types qui se référencent entre eux, et c'est ce qui rend le modèle composable au lieu de simplement plus rapide.
| Type | Ce qu'il contient | Pourquoi ça compte |
|---|---|---|
| Configurations | Les réglages réels : politique de code, VPN, règle de mise à jour, application à installer | C'est la charge utile. Une configuration, réutilisable dans plusieurs activations |
| Activations | La logique. Un ensemble de configurations plus un prédicat facultatif qui décide quand elles s'appliquent | La politique conditionnelle passe sur l'appareil. Fini de reconstruire des groupes dynamiques côté serveur |
| Assets | Les données réutilisables que les configurations pointent : identifiants, certificats d'identité, profils hébergés | Défini une fois, référencé partout. Renouveler un certificat cesse d'être un push sur toute la flotte |
Sous l'ensemble tourne le canal de statut. L'appareil s'abonne aux valeurs qu'il gère et pousse un rapport dès que l'une d'elles change. Le serveur apprend la dérive au moment où elle se produit, pas au prochain rendez-vous planifié.
Le prédicat d'activation est la partie que la plupart des équipes sous-estiment. Comme les prédicats sont évalués sur l'appareil, à partir des rapports de statut et de propriétés de gestion personnalisées, vous pouvez livrer une politique à un appareil avant que la condition soit vraie et le laisser l'activer plus tard tout seul. Une configuration qui ne s'applique qu'à partir d'une version d'OS donnée, ou uniquement si l'appareil se déclare supervisé, ne demande aucune logique serveur.
Impératif contre déclaratif, côte à côte
Admettons que vous déployiez dix applications gérées sur un appareil.
| MDM impératif | Déclaratif | |
|---|---|---|
| Ce que le serveur envoie | Dix commandes d'installation | Une déclaration qui liste les dix applications |
| Confirmation | Un accusé par commande, puis interrogation | L'appareil remonte son état au fil des changements |
| Un utilisateur supprime l'app numéro sept | Elle reste absente jusqu'à ce que quelqu'un déclenche une resynchronisation | L'appareil la réinstalle tout seul |
| Une mise à jour d'app sort | Une nouvelle commande, en file par appareil | L'appareil la met à jour, sans action serveur |
| Appareil en veille ou hors ligne | Les commandes attendent dans la file | La déclaration s'applique et tient localement |
| Détection de dérive | Au prochain contact, parfois des heures | Poussée immédiate par l'appareil |
| Votre tableau de bord | Une mer de « en attente » | L'état courant |
Une précision, parce que c'est un contresens fréquent : une déclaration est toujours livrée à chaque appareil individuellement. Le gain n'est pas un message pour toute la flotte. Le gain, c'est qu'une seule déclaration remplace un flux de commandes et une boucle d'interrogation, par appareil, pendant toute la vie de la politique.
Ce que ça change pour l'administrateur
Des mises à jour qui aboutissent
Les mises à jour macOS en mode impératif étaient réputées peu fiables. Des commandes qui calaient sans bruit, des appareils qui ignoraient l'échéance, des utilisateurs qui reportaient indéfiniment, et un rapport de conformité auquel on ne croyait qu'à moitié. La mise à jour déclarative donne au Mac une version cible et une date d'application, et c'est le Mac qui pilote. Il télécharge en arrière-plan, s'organise autour de l'utilisateur et remonte sa progression par le canal de statut.
La différence pratique se voit dans le reporting. On arrête de se demander si la commande est passée, on lit un état que l'appareil affirme sur lui-même.
Une conformité démontrable au présent
L'interrogation périodique porte un mensonge en elle. Entre deux relevés, vous ne savez pas ce que fait un appareil. Quelqu'un désactive un réglage, sort du réseau, tombe hors politique, et vous l'apprenez au relevé suivant, peut-être quatre heures plus tard.
Le canal de statut referme cette fenêtre. Pour un audit, passer de « on a vérifié ce matin » à « on sait maintenant » vaut plus que le gain de vitesse. C'est aussi la réponse à la question que posent réellement les auditeurs, qui n'est pas de savoir si vous avez une politique mais si vous pouvez démontrer qu'elle a été appliquée en continu.
Moins d'objets à maintenir
Parce que les assets sont référencés et non recopiés, et que les configurations se réutilisent dans plusieurs activations, le nombre d'objets cesse de croître au même rythme que votre matrice de politiques. Renouveler un certificat d'identité devient une mise à jour d'asset au lieu d'un renvoi de tous les profils qui le contenaient. Retirer une politique devient la suppression d'une activation.
Un déploiement d'apps qui se répare seul
Les déclarations de gestion d'applications ont changé le mode de panne. En MDM impératif, une app qui échouait à l'installation, qu'un utilisateur supprimait, ou qui calait en cours de mise à jour restait cassée jusqu'à ce que quelqu'un s'en aperçoive et déclenche une resynchronisation. Une app gérée en déclaratif porte son état attendu. Si elle manque, l'appareil la réinstalle. Si elle est périmée et que la mise à jour automatique est imposée, l'appareil la met à jour. Sans ticket, sans resynchronisation, sans admin dans la boucle.
Les contrôles qui l'accompagnent sont ceux que les administrateurs réclament nommément : forcer la mise à jour automatique quel que soit le réglage App Store de l'utilisateur, restreindre les téléchargements au Wi-Fi pour qu'une équipe terrain ne brûle pas son forfait sur une mise à jour de 400 Mo, et verrouiller ou masquer une app gérée pour qu'elle ne puisse pas être retirée.
Moins de serveur, moins de diagnostic
La charge serveur baisse, ce qui ressemble à une note d'infrastructure jusqu'au jour où vous passez quelques milliers d'appareils et où votre MDM commence à peiner sous ses propres interrogations. Et quand quelque chose casse, un rapport de statut spontané vous dit ce qui a changé et quand, sans que vous construisiez une requête pour aller le chercher.
Ce que ça change pour la personne qui tient l'appareil
Le DDM se discute presque toujours depuis la console. Mais les personnes qui portent ces appareils ressentent aussi le changement, et c'est ce qu'elles vivent qui décide si votre déploiement restera dans les mémoires comme une amélioration ou comme une nuisance.
Les mises à jour cessent de tendre des embuscades
L'ancien dénouement, c'était un compte à rebours de 60 secondes puis un redémarrage, souvent au milieu de quelque chose d'important. La mise à jour déclarative remplace l'embuscade par une piste d'atterrissage. Les notifications peuvent commencer jusqu'à 14 jours avant l'échéance, et vous en maîtrisez la fréquence et le libellé. Les fenêtres de report vont de 1 à 90 jours, et vous pouvez fixer des durées différentes pour une mise à jour mineure et pour une montée de version majeure.
Le bon résultat est le résultat ennuyeux : le Mac télécharge et installe pendant une plage où personne ne s'en sert, et l'utilisateur ne voit jamais de compte à rebours. Sa machine est simplement à jour. Et quand l'échéance arrive vraiment, elle arrive comme la dernière étape d'une conversation à laquelle l'utilisateur participe depuis deux semaines, pas comme une surprise.
Des apps qui se réparent discrètement
Vu de l'utilisateur, le déploiement auto-réparateur signifie que l'app dont il a besoin est là, dans la version prévue, sans qu'il ait à ouvrir un ticket pour expliquer qu'elle a disparu. Le contrôle Wi-Fi seul compte ici aussi. Personne n'a envie de voir son forfait personnel partir dans la mise à jour d'une app gérée, dans un aéroport.
Moins de flou sur ce que la DSI voit
Ce point est subtil et mérite d'être dit à voix haute à vos utilisateurs. Les déclarations décrivent une intention et sont bornées par ce que la déclaration de gestion autorise. Sur un appareil personnel, la frontière entre géré et privé est définie par le type d'inscription, pas par l'agressivité de l'interrogation serveur. Savoir expliquer cette frontière clairement, c'est la moitié du travail dans un programme BYOD.
Les mises à jour logicielles : le dossier qui se referme tout seul
C'est le domaine au rendement le plus élevé, celui dont Apple a fermé la voie impérative, et le plus facile à démontrer.
Une configuration de mise à jour déclarative prend une version d'OS cible et une date d'application. À partir de là, l'appareil possède la séquence : vérifier la disponibilité, télécharger en arrière-plan, notifier l'utilisateur selon le calendrier que vous avez posé, installer, redémarrer. La progression et les états d'échec reviennent par le canal de statut, donc un appareil coincé est visible comme un état, pas comme une absence de confirmation.
Notre guide sur la gestion des correctifs mobiles creuse le rythme de mise à jour lui-même.
Ce qui change dans iOS 27, iPadOS 27 et macOS 27
Le WWDC 2026 est l'édition où Apple a arrêté d'ajouter au DDM pour commencer à y déplacer des choses. Annoncées le 8 juin 2026 et livrées en septembre 2026, les versions 27 apportent le plus gros transfert de capacités hors des profils classiques à ce jour.
Le réseau a déménagé. Six nouvelles configurations remplacent les anciens payloads réseau : network.vpn-plugin, network.ikev2, network.ipsec, network.always-on, network.dns-proxy, network.dns-settings et network.relay. Si vous maintenez des profils VPN à la main, c'est l'année où ce travail change de forme.
Le filtrage de contenu web a déménagé vers webcontent-filter.plugin. Le cache de contenu sur les Mac supervisés passe à content-cache.settings, en remplacement de l'ancien profil com.apple.AssetCache.managed.
Siri, Apple Intelligence et les réglages clavier sortent du payload de restrictions vers siri.settings, intelligence.settings, external-intelligence.settings et keyboard.settings. Les clés de restriction correspondantes ont été dépréciées dès les versions 26.4, la fenêtre de migration est donc ouverte depuis un moment.
Les profils classiques peuvent maintenant être livrés comme assets. Une clé ProfileAssetReference permet de pointer une déclaration de profil classique ou interactif vers un profil hébergé, ce qui transforme « il nous reste quarante profils non convertis » en étape de transition plutôt qu'en blocage.
De nouveaux éléments de statut sont arrivés : mdm.enrollment-type, mdm.is-awaiting-configuration, mdm.is-return-to-service, device.system.health et security.lockdown-mode. Ce sont des carburants à prédicats. Pouvoir conditionner une configuration au type d'inscription ou au mode isolement, évalué sur l'appareil, supprime une catégorie entière de logique de groupes côté serveur.
Et le titre, à nouveau, parce que c'est celui qui a une date attachée : la gestion classique des mises à jour logicielles ne fonctionne plus dans aucun système d'exploitation 27.0, commandes, requêtes et restrictions associées comprises.
Ce que le DDM ne change pas
L'inscription. Les appareils arrivent toujours par l'inscription automatisée et Apple Business Manager, et le DDM tourne au-dessus de ces fondations. Si votre configuration ABM est en désordre, la gestion déclarative ne la rangera pas.
Votre MDM reste aussi ce qui livre les déclarations, ce n'est donc pas un outil que vous abandonnez. C'est la façon dont votre outil existant parle aux appareils qui change. Et le DDM cohabite avec le MDM impératif au lieu de le remplacer du jour au lendemain. Si les acronymes alentour sont flous, notre guide sur la gestion des terminaux et l'UEM explique comment MDM, EMM et UEM s'articulent.
Ce qu'Appaloosa gère pour vous
L'ordre de migration, le conflit entre une déclaration et un ancien profil, la question de savoir quel appareil sait faire quoi : Appaloosa s'en occupe de façon transparente. Les politiques que vous avez déjà configurées sont livrées en déclaratif sur les appareils compatibles, et les appareils sur des versions plus anciennes continuent de recevoir l'équivalent impératif. Vous ne choisissez pas un modèle appareil par appareil et vous ne maintenez pas deux jeux de politiques.
Deux décisions restent les vôtres, parce qu'elles sont opérationnelles et non techniques. Ciblez une version d'OS précise plutôt que « la dernière », pour que votre parc atterrisse sur un build connu et que le support diagnostique une configuration au lieu de six. Et échelonnez les dates d'application par groupe, pour qu'une cohorte pilote atteigne l'échéance deux semaines avant les autres et trouve l'application métier qui casse avant que 3 000 personnes la trouvent pour vous.
À lire aussi : Gestion Apple : nouveautés iOS 18 et macOS 15
Questions fréquentes
Faut-il réinscrire les appareils pour utiliser le DDM ?
Non. Le DDM passe par l'inscription MDM existante. Si un appareil est inscrit et sur un OS compatible, il peut recevoir des déclarations.
Quelles versions d'OS faut-il ?
Le socle des déclarations est iOS 17, iPadOS 17 et macOS 14. La couverture s'élargit à chaque version suivante, et les versions 27 sont celles où plusieurs domaines deviennent déclaratifs exclusivement.
Le DDM est-il réservé aux appareils supervisés d'entreprise ?
Non, mais le périmètre diffère. Les appareils d'entreprise supervisés bénéficient de la couverture la plus large, y compris l'installation d'applications. Les appareils personnels en inscription utilisateur obtiennent un jeu plus restreint, délibérément limité.
Le sens de l'histoire
Apple a arrêté les sous-entendus. Les nouvelles capacités de gestion arrivent désormais en déclaratif d'abord, les capacités existantes migrent version après version, et avec les systèmes 27 la voie impérative a commencé à disparaître au lieu de simplement passer de mode. Si vous gérez des appareils Apple à une échelle réelle, la question n'est plus de savoir s'il faut adopter le DDM. C'est de savoir si la plateforme que vous payez déjà l'a fait.
Appaloosa prend en charge la gestion déclarative. Le canal de statut est en place, donc les appareils remontent leurs changements d'état en temps réel au lieu d'attendre d'être interrogés, et les configurations déclaratives couvrent les mises à jour logicielles, les applications gérées, Siri et les réglages clavier. La couverture s'étend déclaration par déclaration plutôt que d'un bloc, ce qui est la façon honnête de décrire où en est chaque plateforme aujourd'hui. Appaloosa gère les iPhone et iPad et les Mac via Apple Business Manager et l'inscription automatisée, donc les fondations d'inscription dont dépend le DDM sont déjà en place.