Pendant des années, gérer un appareil Apple, c'était un serveur qui donnait des ordres et attendait la réponse. Installe ce profil. Ça a marché ? On revérifie dans une heure. Le Declarative Device Management change ce fonctionnement. L'appareil porte désormais son propre règlement et prévient le serveur quand quelque chose change.
Apple a introduit le DDM à la WWDC 2021, avec iOS 15. Dès iOS 16 en 2022, il couvrait l'essentiel de ce que faisait le MDM classique, et depuis la sortie d'iOS 17 fin 2023, Apple pousse clairement les administrateurs dans cette direction. Si vous gérez des iPhone, des iPad ou des Mac, mieux vaut comprendre ce qui a réellement changé.
Ce qu'est vraiment la gestion déclarative
Le MDM classique est impératif. Le serveur envoie une commande, l'appareil accuse réception, et le serveur interroge l'appareil pour confirmer l'état. Chaque réglage est une conversation. Multipliez par quelques milliers d'appareils et le serveur passe ses journées à courir après les statuts.
Le DDM est déclaratif. Au lieu de commandes, le serveur envoie des déclarations : des énoncés sur l'état dans lequel un appareil doit se trouver. L'appareil les stocke, les applique lui-même, et ne rend compte que lorsque quelque chose change. C'est la différence entre un manager qui appelle toutes les heures pour vérifier une tâche et un manager qui confie l'objectif, puis fait confiance pour signaler un problème.
Les quatre briques du DDM
Une déclaration n'est pas un bloc monolithique. Apple la découpe en types qui se référencent entre eux, ce qui rend le modèle composable.
- Les configurations portent les vrais réglages : une règle de code, un profil Wi-Fi, une politique de mise à jour.
- Les activations sont la logique. Une activation est un prédicat qui décide quand une configuration s'applique, si bien qu'une politique ne s'active que lorsque l'appareil remplit une condition.
- Les ressources (assets) contiennent les données réutilisables auxquelles les configurations renvoient, comme des identifiants ou un certificat, définies une fois et référencées partout.
- Les déclarations de management décrivent l'organisation et ce que le serveur a le droit de faire.
Sous tout cela tourne un canal de statut. L'appareil pousse un rapport dès qu'une valeur qu'il surveille change, si bien que le serveur découvre les écarts au moment où ils se produisent, pas au prochain relevé programmé.
Impératif contre déclaratif, en pratique
Imaginez que vous déployiez un nouveau réseau Wi-Fi sur 3 000 iPad. À l'ancienne, votre MDM met 3 000 commandes en file, attend 3 000 accusés de réception, puis interroge chaque appareil pour confirmer. Certains dorment. D'autres sont hors ligne. La file s'engorge et votre tableau de bord affiche une mer de « en attente ».
Avec le DDM, le serveur envoie une seule déclaration. Chaque iPad l'applique localement, l'impose même hors ligne, et signale le succès à la reconnexion. Le serveur cesse de tout surveiller. C'est tout l'intérêt : déplacer le travail vers l'appareil, et faire moins reposer sur le réseau.
Le canal de statut, ou pourquoi le proactif bat le polling
Le polling a un mensonge intégré. Entre deux relevés, vous ignorez ce que fait un appareil. Un utilisateur peut désactiver un réglage, quitter le Wi-Fi ou sortir de conformité, sans que vous le sachiez avant le relevé suivant, parfois des heures plus tard.
Le canal de statut comble ce trou. L'appareil s'abonne aux valeurs qu'il gère et les signale à l'instant où l'une change. Pour une équipe conformité, ce basculement compte plus que le gain de vitesse. Vous passez de « on a vérifié ce matin » à « on sait maintenant », et c'est exactement ce qu'un auditeur vous demande.
Pourquoi les équipes IT devraient s'y intéresser
La vitesse est le gain évident. Une configuration déclarative s'applique en quelques secondes, sans aller-retour. Mais les bénéfices plus discrets pèsent davantage à grande échelle.
La fiabilité s'améliore, parce que les activations continuent d'imposer les règles sur l'appareil, connexion ou pas. La charge serveur baisse, ce qui n'a rien de spectaculaire jusqu'au jour où vous dépassez quelques milliers de terminaux et où votre MDM cesse de ployer sous son propre polling. Et le dépannage raccourcit, parce qu'un rapport de statut proactif vous dit ce qui a cassé sans requête manuelle.
Ce que le DDM ne change pas
L'enrôlement reste identique. Les appareils arrivent toujours par l'Automated Device Enrollment et Apple Business Manager, et le DDM se pose par-dessus. Il cohabite aussi avec le MDM classique plutôt que de le remplacer du jour au lendemain. Votre MDM reste ce qui distribue les déclarations à la flotte : vous ne lâchez pas l'outil, vous changez sa façon de parler aux appareils. Le BYOD via un profil de gestion simple suit le même chemin.
Si les sigles deviennent flous, notre guide sur l'UEM et la gestion des endpoints remet MDM, EMM et UEM à leur place.
Le DDM n'est pas réservé aux iPhone
C'est sur Mac que la gestion déclarative prouve sa valeur. Les mises à jour logicielles en sont l'exemple le plus clair. L'ancienne méthode impérative pour pousser les mises à jour macOS était réputée capricieuse : commandes qui calaient, appareils qui ignoraient l'échéance, utilisateurs qui reportaient à l'infini. La gestion déclarative des mises à jour donne au Mac une version cible et une date d'application, et le Mac pilote lui-même la mise à jour, avec un compte à rebours visible pour l'utilisateur. Moins de machines bloquées, moins de tickets.
La même logique couvre les réglages de code, de certificat et de compte sur macOS, iOS et iPadOS. Si votre flotte mêle des iPhone sur le terrain et des Mac au bureau, le déclaratif vous donne un seul modèle d'application au lieu de deux séries de bizarreries.
Là où les équipes se trompent
La première erreur est de traiter le DDM comme un remplacement total. Il est additif. Vous ferez cohabiter déclaratif et impératif longtemps, et c'est très bien. Les ennuis commencent quand vous gérez le même réglage des deux façons et que les deux se disputent le contrôle. Choisissez un seul responsable par politique, et notez-le.
La seconde est de bâcler la logique d'activation. Les activations sont utiles justement parce qu'elles sont conditionnelles, mais un prédicat mal écrit peut laisser une configuration inerte ou l'envoyer aux mauvais appareils. Testez les conditions, pas seulement les configurations. Et évitez de déployer une nouvelle politique déclarative à toute la flotte dès le premier jour, aussi propre soit-elle en démo.
Le sens de l'histoire
Apple a été clair sur la trajectoire. Les nouvelles capacités de gestion arrivent désormais en déclaratif d'abord, et la voie impérative devient peu à peu le repli plutôt que le défaut. Si vous gérez des appareils Apple à une échelle sérieuse, le DDM n'est pas une curiosité à observer de loin. C'est le modèle sur lequel se construiront vos prochaines années de gestion Apple.
Appaloosa gère les iPhone et iPad et les Mac via Apple Business Manager et l'Automated Device Enrollment : le socle d'enrôlement sur lequel repose le DDM est déjà en place. Pour voir ce qui tourne sur chaque plateforme, comparez la matrice des fonctionnalités ou démarrez un essai. Et pour le contexte Apple plus large, notre guide Comment fonctionne un MDM Apple couvre l'enrôlement et la supervision.