Qu'est-ce que la gestion déclarative des appareils ? (2026)

La gestion déclarative des appareils (DDM) est le cadre mis au point par Apple qui permet aux appareils d’appliquer leurs propres configurations en local, sans attendre les instructions du serveur. Présentée lors de la WWDC 2021, elle modifie en profondeur le modèle de communication entre votre serveur MDM et votre parc d’appareils Apple.

Si vous gérez des appareils macOS, iOS ou iPadOS à une échelle significative, le DDM représente le changement architectural le plus important dans la gestion des appareils Apple depuis l’introduction du MDM en 2010. Ce guide explique en quoi consiste cette technologie, comment elle fonctionne sur le plan technique, quelle est sa place par rapport au MDM traditionnel, et ce que vous devez faire avant que le calendrier de dépréciation d’Apple ne vous y oblige.

Pourquoi le MDM traditionnel rencontre des problèmes d’évolutivité

Pour comprendre pourquoi le DDM existe, il faut d’abord comprendre les limites du protocole qu’il remplace. Le MDM traditionnel fonctionne selon un modèle de sondage. Le serveur envoie une commande, l’appareil l’exécute, l’appareil renvoie une réponse, puis le serveur envoie la commande suivante. Chaque vérification d’état, chaque déploiement de configuration, chaque instruction de mise à jour logicielle passe par cette boucle requête-réponse.

Avec 50 appareils, cela fonctionne bien. Avec 5 000 appareils, le serveur doit gérer des milliers de requêtes simultanées. Avec 50 000 appareils, vous gérez une infrastructure uniquement pour gérer votre infrastructure. Ce modèle engendre également des lacunes en matière de conformité : un appareil qui ne parvient pas à joindre le serveur MDM ne met tout simplement pas à jour sa configuration, et le serveur ne se rendra compte de ce décalage qu’au prochain enregistrement réussi.

Il existe également un problème plus subtil. Le MDM traditionnel est « sans état » du point de vue de l’appareil. L’appareil ne « sait » pas quel est son état souhaité. Il se contente d’exécuter les commandes au fur et à mesure qu’elles arrivent. Si un utilisateur modifie un paramètre entre deux enregistrements MDM, l’appareil reste dans un état non conforme jusqu’à ce que le serveur effectue un nouvel interrogatoire et émette une correction.

Pour comprendre le fonctionnement de la gestion des appareils au niveau du protocole, cette architecture d’interrogation constitue la contrainte principale que le DDM est conçu pour éliminer.

Fonctionnement de la gestion déclarative des appareils

Le DDM inverse le modèle de gestion. Au lieu que le serveur indique à l’appareil quoi faire étape par étape, il lui envoie une description complète de l’état souhaité. L’appareil stocke cette description localement et la met en œuvre de manière autonome, même sans connexion active au serveur.

Voici comment cela se traduit concrètement. Avec le MDM traditionnel, l’installation d’un profil de configuration nécessite que le serveur envoie une commande, attende que l’appareil l’accuse réception, confirme l’installation du profil et gère les éventuelles erreurs. Avec le DDM, le serveur envoie une déclaration indiquant « cet appareil doit disposer de cette configuration ». L’appareil se charge alors de mettre en œuvre cet état et de le maintenir au fil du temps.

Si un utilisateur supprime un paramètre géré, l’appareil le rétablit immédiatement, sans attendre le serveur. Si l’appareil reste hors ligne pendant trois jours, il continue d’appliquer l’état déclaré. Lorsqu’il se reconnecte, il rend compte de ce qui s’est passé pendant cette période via le canal d’état.

Les trois piliers : déclarations, canal d’état et extensibilité

L’architecture DDM d’Apple repose sur trois composants. Tout administrateur informatique travaillant avec des appareils Apple doit les comprendre tous les trois.

Déclarations

Les déclarations sont des documents JSON structurés qui décrivent ce que doit être et faire un appareil. Il existe quatre types de déclarations :

• Déclarations de configuration : elles définissent des paramètres spécifiques sur l’appareil, équivalents aux profils de configuration des solutions MDM traditionnelles, mais stockés et appliqués localement. Il s’agit par exemple des politiques de code d’accès, des paramètres Wi-Fi et des configurations VPN.
• Déclarations d’actifs : elles font référence aux ressources externes dont dépendent les déclarations, telles que les identifiants ou les certificats nécessaires à l’activation d’une configuration.
• Déclarations d’activation : elles définissent des prédicats qui déterminent quand une configuration doit s’appliquer. Par exemple : « appliquer FileVault uniquement si l’appareil est inscrit auprès du fournisseur d’identité d’entreprise ». Cette logique conditionnelle s’exécute sur l’appareil, et non sur le serveur.
• Déclarations de gestion : elles gèrent les informations relatives à l’inscription, notamment les propriétés d’inscription de l’appareil et la configuration du service MDM.

Le système de prédicats des déclarations d’activation est l’une des fonctionnalités les plus puissantes et les plus sous-estimées de DDM. Au lieu que ce soit le serveur qui exécute la logique pour décider quels appareils reçoivent quelles configurations, vous transférez cette logique vers l’appareil lui-même. Un appareil inscrit dans le périmètre de votre service financier peut appliquer de manière autonome des paramètres de chiffrement plus stricts qu’un appareil relevant des opérations générales, en fonction de critères évalués localement.

Canal d’état

Le canal d’état est le mécanisme de rapport asynchrone de DDM. Les appareils envoient des rapports d’état au serveur lorsqu’un changement significatif se produit, et non selon une fréquence d’interrogation prédéfinie. Si un appareil applique une déclaration avec succès, il le signale. Si un prédicat d’activation change d’état, il le signale. Si une mise à jour logicielle est installée, il le signale.

Pour les équipes informatiques, cela change votre façon d’envisager la visibilité du parc. Au lieu de récupérer l’état selon un calendrier, vous recevez un flux d’événements de changement. Votre inventaire d’appareils reste à jour en temps quasi réel sans générer de charge serveur proportionnelle à la taille du parc. Un parc de 10 000 appareils génère du trafic d’état lorsque des changements surviennent, et non pas 10 000 vérifications toutes les 15 minutes.

Cela transforme également la surveillance de la conformité. Avec les solutions MDM traditionnelles, vous ne détectez les écarts qu’au moment de la vérification. Grâce au canal d’état de DDM, l’appareil vous signale qu’il a détecté et corrigé un écart, ou qu’il a détecté un écart qu’il ne peut pas corriger lui-même, immédiatement après que celui-ci se soit produit.

Extensibilité

L’extensibilité permet au framework DDM de prendre en charge de nouveaux types de déclarations à mesure qu’Apple les ajoute au fil des versions du système d’exploitation. Plutôt que d’exiger des modifications de protocole chaque fois qu’Apple introduit de nouvelles fonctionnalités de gestion, l’extensibilité fournit un mécanisme standardisé pour ajouter de nouveaux types de configuration et d’état.

C’est un aspect crucial pour la planification à long terme. À mesure qu’Apple continue d’étendre la prise en charge du DDM, votre plateforme MDM peut adopter de nouveaux types de déclarations sans nécessiter de modifications architecturales fondamentales. Pour les équipes informatiques qui évaluent les fournisseurs MDM, une plateforme offrant une prise en charge native du DDM et reposant sur des principes d’extensibilité sera nettement plus facile à maintenir à mesure que les API de gestion d’Apple évoluent.

Gestion déclarative des appareils (DDM) vs MDM traditionnel

Les différences concrètes entre le DDM et le MDM traditionnel ont des répercussions sur les opérations quotidiennes qui comptent pour les équipes informatiques gérant de véritables parcs d’appareils.

Il convient de clarifier la question de la coexistence : le DDM ne remplace pas entièrement le MDM traditionnel, du moins pas encore. Les deux protocoles fonctionnent en parallèle sur les appareils inscrits. Les commandes MDM gèrent toujours certaines actions, les processus d’inscription utilisent toujours les canaux MDM traditionnels, et certaines fonctionnalités n’ont pas encore migré vers le DDM. Apple a indiqué que les commandes héritées relatives aux mises à jour logicielles, aux restrictions et à certaines configurations seront obsolètes à partir d’iOS/macOS 26, faisant ainsi de DDM la voie incontournable pour ces fonctions à l’avenir.

Configuration requise du système d’exploitation pour DDM

La prise en charge de DDM est liée à des versions spécifiques des systèmes d’exploitation Apple. Avant de mettre en place des workflows de gestion basés sur DDM, vérifiez la répartition des systèmes d’exploitation au sein de votre parc :

• iOS 15 / iPadOS 15 / macOS 12 Monterey : introduction de la prise en charge initiale de DDM
• iOS 16 / iPadOS 16 / macOS 13 Ventura : types de déclarations étendus, gestion des mises à jour logicielles via DDM
• iOS 17 / iPadOS 17 / macOS 14 Sonoma : déclarations de configuration supplémentaires, rapports d’état améliorés
• iOS 18 / iPadOS 18 / macOS 15 Sequoia : poursuite de l’extension ; nouvelles commandes MDM héritées marquées comme obsolètes
• iOS/macOS 26 et versions ultérieures : obsolescence significative des commandes MDM héritées ; DDM devient la voie obligatoire pour l’application des mises à jour logicielles et les types de configuration supplémentaires

Si votre parc comprend des appareils fonctionnant sous des versions plus anciennes du système d’exploitation, vous devrez adopter une approche hybride pendant la période de transition. Tout appareil fonctionnant sous une version antérieure à iOS 15 ou macOS 12 ne peut en aucun cas utiliser DDM et nécessitera indéfiniment l’utilisation de commandes MDM héritées ; sinon, vous devrez exclure ces appareils de votre parc matériel pris en charge.

Implications de DDM en matière de sécurité pour la conformité des entreprises

Le modèle d’application autonome de DDM a des implications directes sur le niveau de sécurité qui ne sont pas évidentes d’un point de vue strictement lié à la gestion des appareils.

Avec un MDM traditionnel, l’état de conformité d’un appareil correspond à un instantané pris lors de la dernière vérification. Un appareil qui modifie une configuration de sécurité à 9 h et qui est vérifié à 21 h a été non conforme pendant 12 heures. Dans les environnements réglementés fonctionnant selon des référentiels tels que la norme NIST SP 800-53 ou les benchmarks CIS pour macOS, cet écart constitue un échec de contrôle, même s’il est temporaire.

Le DDM comble cette lacune. Comme l’appareil applique en permanence l’état qu’il a lui-même déclaré, le délai entre la non-conformité et la correction se mesure en secondes, et non en heures. Le canal d’état enregistre l’événement, vous fournissant ainsi une piste d’audit qui montre l’écart et la correction avec des horodatages.

Pour les architectures « zero-trust » qui s’appuient sur les signaux de posture des appareils pour accorder ou refuser l’accès, cela revêt une importance considérable. Un appareil affirmant sa conformité à un moteur de politiques, tel qu’un fournisseur d’identité ou une passerelle SSO, doit fournir des données de posture précises. L’application locale continue de DDM, combinée à des rapports d’état en temps réel, rend les signaux de posture des appareils plus fiables que ne le permettent les vérifications par sondage.

Cela s’inscrit directement dans une stratégie plus large de sécurité des terminaux. Si vous considérez la gestion et la sécurité des appareils comme des disciplines intégrées plutôt que comme des fonctions distinctes, l’architecture de DDM est conçue pour ce modèle intégré.

Application des mises à jour logicielles avec DDM

C’est dans la gestion des mises à jour logicielles que les avantages de DDM sont les plus immédiatement perceptibles pour les équipes informatiques d’entreprise et que le calendrier de dépréciation d’Apple crée le plus d’urgence.

Avec les solutions MDM traditionnelles, l’application d’une version spécifique de macOS implique que le serveur envoie une commande de mise à jour, que l’appareil l’accuse réception, qu’il télécharge et prépare la mise à jour, puis que le serveur effectue un sondage pour confirmer la réussite de l’opération. Si l’appareil est hors ligne pendant la plage horaire prévue, la mise à jour n’a pas lieu. Si un utilisateur reporte la mise à jour, il faut que le serveur envoie une nouvelle commande.

DDM gère les mises à jour logicielles via la déclaration de configuration « Mise à jour logicielle ». Vous déclarez la version minimale acceptable du système d’exploitation. L’appareil évalue son état actuel par rapport à cette déclaration, lance le processus de mise à jour de manière autonome lorsque les conditions sont remplies et communique son état via le canal de statut. Un appareil qui se déconnecte puis se reconnecte reprend là où il s’était arrêté sans que le serveur ait besoin de réémettre de commandes.

Pour les campagnes de mise à jour à l’échelle du parc, cela signifie que vous n’avez pas à gérer une file d’attente de commandes MDM en attente. Vous déclarez votre intention une seule fois, et les appareils se mettent en conformité selon leur propre calendrier, dans les limites des paramètres que vous avez définis.

Le DDM en contexte : fournisseurs d’identité et intégration SSO

L’un des domaines dans lesquels le système de prédicats de DDM apporte une valeur ajoutée significative à l’entreprise est la configuration conditionnelle basée sur le contexte d’identité. La portée traditionnelle du MDM est relativement grossière : vous attribuez des profils à des groupes d’appareils ou à des groupes d’utilisateurs. Les activations DDM peuvent évaluer des conditions plus granulaires.

Exemples concrets pour les environnements d’entreprise :

• Appliquer des exigences plus strictes en matière de code d’accès sur les appareils dont le compte utilisateur dispose d’un accès privilégié, évaluées en fonction des attributs du répertoire
• Imposer des configurations d’authentification par certificat uniquement lorsqu’un certificat spécifique de l’autorité de certification (CA) d’entreprise est présent
• Activer les déclarations de configuration VPN selon que l’appareil est connecté ou non à un segment de réseau spécifique

Ces comportements conditionnels s’exécutent sur l’appareil. Ils ne nécessitent pas que le serveur réévalue les attributions de portée à chaque fois qu’une condition change. L’appareil suit l’évolution de la condition, réévalue le prédicat et ajuste sa configuration de manière autonome.

L’approche d’Iru en matière de gestion déclarative des appareils

La mise en œuvre de la gestion déclarative des appareils (DDM) par Iru est native, et non une adaptation a posteriori. Iru ayant été conçu autour des API de gestion d’Apple, les déclarations DDM constituent un élément central de la manière dont la plateforme fournit les configurations, et non une fonctionnalité supplémentaire superposée à un moteur MDM hérité.

Pour les équipes gérant des milliers de Mac, d’iPhone et d’iPad, cela fait une différence concrète dans plusieurs domaines spécifiques.

Premièrement, l’application des mises à jour logicielles via Iru utilise les déclarations DDM pour les versions de système d’exploitation prises en charge, ce qui signifie que les campagnes de mise à jour ne génèrent pas de charge serveur linéaire à mesure que la taille du parc augmente. À partir de 10 000 appareils, la différence entre une gestion des mises à jour basée sur l’interrogation et une gestion basée sur le DDM est mesurable en termes de coûts d’infrastructure et de temps consacré par l’équipe informatique.

Deuxièmement, le moteur de conformité d’Iru utilise le canal d’état du DDM comme source de données pour l’état de sécurité des appareils. Lorsqu’un appareil signale un changement de configuration via le canal d’état, ce signal alimente les tableaux de bord de conformité en temps quasi réel. Les équipes de sécurité obtiennent ainsi des données précises sur l’état de sécurité sans avoir à attendre les vérifications programmées.

Troisièmement, l’approche d’Iru concernant la période de transition entre le DDM et le MDM traditionnel consiste à faire fonctionner les deux protocoles en parallèle : le DDM là où Apple le prend en charge et les commandes traditionnelles là où elles sont encore nécessaires, sans que les équipes informatiques aient à gérer manuellement cette distinction. Apple déprécie les commandes héritées dans iOS/macOS 26 et versions ultérieures ; grâce à l’architecture native DDM d’Iru, cette transition nécessite des modifications de configuration, et non des changements de plateforme.

Pour les équipes qui envisagent également une migration plus large, il convient d’évaluer attentivement les considérations relatives à la migration MDM d’Apple concernant la prise en charge du DDM lors de l’évaluation de toute plateforme MDM.

Ce que les équipes informatiques doivent faire dès maintenant pour se préparer au DDM

Si vous gérez actuellement un parc d’appareils Apple et que vous n’avez pas encore commencé à intégrer DDM dans votre stratégie de gestion, voici les points sur lesquels vous devez vous concentrer.

Faites l’inventaire de la répartition de vos systèmes d’exploitation. Le DDM nécessite iOS 15 / macOS 12 ou une version ultérieure. Les appareils ne répondant pas à ce critère doivent suivre un parcours de gestion distinct. Dressez un tableau précis du nombre d’appareils dont vous disposez et de leurs versions actuelles de système d’exploitation. Cela a une incidence directe sur votre processus de gestion de l’inventaire matériel.

Identifiez vos cas d’utilisation DDM les plus prioritaires. L’application des mises à jour logicielles et la configuration continue de la sécurité constituent les meilleurs points de départ. Ce sont des domaines dans lesquels le modèle d’application autonome de DDM apporte une valeur immédiate et mesurable.

Évaluez le niveau de maturité de votre plateforme MDM en matière de DDM. Posez des questions précises : la plateforme utilise-t-elle nativement les déclarations DDM pour les mises à jour logicielles ? Le canal d’état alimente-t-il les tableaux de bord de conformité en temps réel ? Comment la plateforme gère-t-elle la période de transition où certains appareils prennent en charge le DDM et d’autres non ? Comment la plateforme se prépare-t-elle à la dépréciation des anciennes commandes Apple dans iOS/macOS 26 ?

Planifiez votre logique de prédicats. Le passage à une logique conditionnelle côté appareil nécessite de repenser la portée de la configuration. Au lieu de se demander « à quel groupe appartient cet appareil », vous concevez des prédicats que l’appareil évalue localement. Faites correspondre votre structure de politiques existante à la logique des déclarations DDM avant de commencer la mise en place.

N’attendez pas que le DDM soit entièrement déployé. Le DDM et les solutions MDM héritées coexistent aujourd’hui. Commencez à utiliser le DDM là où il est disponible et apporte une valeur ajoutée. Attendre que le DDM atteigne une parité totale avec les solutions MDM héritées revient à passer à côté des avantages opérationnels disponibles dès maintenant.

La plateforme native DDM d’Iru est conçue pour accompagner cette transition à l’échelle de l’entreprise. Si vous souhaitez découvrir comment les configurations déclaratives fonctionnent concrètement pour un parc de votre taille, contactez Iru.