Migration MDM Apple : guide à l'intention des administrateurs informatiques

Changer de fournisseur MDM lorsque des centaines, voire des milliers d’appareils Apple sont en service constitue l’un des projets les plus complexes sur le plan opérationnel auxquels une équipe informatique doit faire face. La fonctionnalité de migration native d’OS 26 d’Apple change considérablement la donne, mais une migration sans heurts nécessite tout de même une planification minutieuse, une documentation détaillée de la configuration et un processus de validation post-migration rigoureux.

Ce guide couvre tous les aspects, de l’inventaire préalable à la migration jusqu’à la vérification de la conformité après la migration, en accordant une attention particulière aux scénarios qui posent le plus de problèmes à la plupart des équipes : la préservation des données des applications, la synchronisation des clés de récupération FileVault et la gestion des appareils qui ne sont pas éligibles à la nouvelle voie de migration vers OS 26.

Ce qui a changé avec la migration MDM sous OS 26 d’Apple

Avant OS 26, la migration d’appareils Apple supervisés d’une solution MDM à une autre impliquait presque toujours une réinitialisation aux paramètres d’usine, une réinscription et une réinstallation de chaque application gérée. Pour un parc de 500 MacBook, cela représente un projet de plusieurs semaines qui touche chaque utilisateur.

OS 26 d’Apple introduit un processus de migration natif géré via Apple Business (anciennement Apple Business Manager/ASM). Le mécanisme fonctionne ainsi :

1. Un administrateur réaffecte les appareils d’un serveur MDM à un autre directement dans Apple Business.

2. Le serveur MDM d’origine envoie une notification de migration aux appareils inscrits.

3. Les utilisateurs reçoivent une invite leur indiquant un délai configurable pour effectuer la transition.

4. L’appareil se désenregistre automatiquement du serveur MDM source et s’enregistre auprès du serveur MDM de destination, sans effacement des données.

Pour les équipes de gestion des appareils Apple fonctionnant entièrement via Apple Business avec des appareils inscrits via ADE, cela représente une véritable révolution. La principale contrainte : les serveurs MDM source et de destination doivent tous deux prendre en charge l’API de migration vers OS 26, et les appareils doivent fonctionner sous OS 26 ou une version ultérieure.

Appareils et scénarios non pris en charge par la migration vers OS 26 :

• Les appareils fonctionnant sous iOS/iPadOS/macOS antérieurs à la version OS 26 (ceux-ci nécessitent toujours une désinscription et une réinscription manuelle, ou un effacement complet)
• Déploiements d’iPad partagés
• Les appareils inscrits à Apple Business Essentials
• Les appareils non enregistrés dans Apple Business ou Apple School Manager
• Les appareils inscrits par l’utilisateur (BYOD), qui suivent un processus distinct

Si votre parc comprend un pourcentage significatif d’appareils fonctionnant sous une version antérieure à la version 26 du système d’exploitation, prévoyez une migration en parallèle. Ne laissez pas les fonctionnalités phares occulter le fait qu’un environnement mixte en termes de systèmes d’exploitation nécessite une approche mixte. Si vous gérez des appareils BYOD aux côtés du matériel appartenant à l’entreprise, ceux-ci nécessiteront une planification de migration entièrement distincte.

Planification préalable à la migration : ce qu’il faut documenter avant de toucher à quoi que ce soit

La cause la plus fréquente d’une migration MDM difficile n’est pas la migration elle-même, mais une documentation insuffisante sur le fonctionnement réel du MDM source. Avant de lancer quoi que ce soit dans Apple Business ou dans votre MDM de destination, exportez et documentez les éléments suivants :

Profils de configuration

• Exportez tous les profils de configuration du système MDM source, y compris le type de charge utile, la portée et toute exception spécifique à un appareil.
• Signalez les profils qui gèrent les paramètres sensibles en matière de sécurité : FileVault, verrouillage de l’écran, pare-feu, confiance des certificats et filtrage de contenu.
• Notez la distinction entre les profils distribués par le MDM et ceux qui ont été installés manuellement. Les profils installés manuellement ne migrent pas automatiquement et ne peuvent pas être redistribués sans intervention de l’utilisateur.

Inventaire des applications et attribution VPP/Apps and Books

• Extrayez la liste complète des applications gérées, y compris les applications de l’App Store attribuées via « Applications et livres » et toutes les applications personnalisées ou d’entreprise installées via MDM.
• Indiquez quelles applications sont attribuées aux appareils et lesquelles sont attribuées aux utilisateurs.
• Vérifiez que votre jeton « Apps and Books » est associé à votre compte Apple Business et n’est pas codé en dur chez le fournisseur MDM d’origine. Vous devrez révoquer le jeton et l’inviter à nouveau dans le MDM de destination.

État d’inscription et de supervision

Pour chaque appareil, indiquez :

• Type d’inscription (ADE/inscription utilisateur/manuelle)
• Statut de supervision
• Version du système d’exploitation
• Numéro de série et statut d’enregistrement Apple Business

C’est également le moment idéal pour recouper votre inventaire des appareils MDM avec vos registres de gestion du parc matériel. Les appareils qui apparaissent dans un système mais pas dans l’autre constituent un problème à résoudre avant la migration, et non après.

Normes de sécurité

Mettez en correspondance vos profils de configuration actuels avec les contrôles de sécurité qu’ils imposent. Si votre organisation adhère aux benchmarks CIS pour macOS ou aux recommandations NIST SP 800-179, documentez quels profils correspondent à quels contrôles. Vous aurez besoin de cette mise en correspondance pour valider votre posture de sécurité dans le système MDM de destination après la migration.

Configuration du système MDM de destination avant le jour de la migration

Le MDM de destination doit être entièrement configuré et testé avant le transfert du moindre appareil de production. Effectuer une migration vers un MDM non préparé revient à créer une période pendant laquelle les appareils sont enregistrés mais ne font l’objet d’aucune gouvernance.

Configuration requise dans le MDM de destination

Certificat Apple Push Notification Service (APNs) : les certificats APNs sont spécifiques à chaque fournisseur. Le certificat APNs de votre MDM source ne peut pas être transféré. Générez un nouveau certificat via le portail Apple Push Certificates à l’aide de l’Apple ID de votre organisation, puis téléchargez-le sur le MDM de destination. Le certificat devant être renouvelé chaque année, notez la date d’expiration et l’Apple ID utilisé.

Intégration ADE (Automated Device Enrollment) : dans Apple Business, attribuez le MDM de destination comme serveur pour les appareils que vous migrez. C’est cette étape qui met en place le flux de migration vers OS 26. Les appareils attribués au nouveau serveur MDM recevront l’invite de migration dès que votre MDM source l’aura lancée.

Configuration de l’inscription PreStage : dans le MDM de destination, configurez votre profil PreStage (ou un profil d’inscription équivalent) avant l’arrivée des appareils. Cela comprend :

• la configuration du volet « Assistant de configuration »
• Les attributions initiales de profils
• Les paramètres d’installation du profil MDM

Jeton « Apps and Books » : révoquez le jeton du MDM source et réinvitez-le sur le MDM de destination. Notez que la révocation du jeton du MDM source supprimera immédiatement la possibilité de pousser de nouvelles attributions d’applications VPP depuis ce système ; veillez donc à coordonner ce moment avec votre fenêtre de migration.

Profils de configuration : recréez tous les profils de configuration requis dans le MDM de destination. Ne vous contentez pas de recréer à l’identique l’architecture des profils de l’ancien MDM. Profitez de la migration pour rationaliser la structure de vos politiques. Les environnements MDM hérités accumulent souvent, au fil des années, des profils qui se chevauchent, se contredisent ou sont redondants. Une migration est l’occasion idéale de faire le ménage.

Exécution de la migration : le processus OS 26 étape par étape

Une fois le MDM de destination configuré et les appareils attribués dans Apple Business, voici la séquence opérationnelle :

1. Lancez la migration depuis le MDM source. Le MDM source envoie une commande MDM aux appareils inscrits pour signaler la migration. Le mécanisme exact varie selon les fournisseurs, mais le résultat est le même : une notification s’affiche sur l’appareil.

2. Les utilisateurs reçoivent une invite de migration. La migration vers OS 26 d’Apple inclut une date limite d’inscription configurable. Vous pouvez définir un délai de grâce (généralement de 24 à 72 heures pour les appareils d’entreprise gérés) à l’issue duquel l’appareil effectue automatiquement la migration. Informez les utilisateurs avant l’apparition de l’invite. Une boîte de dialogue système inattendue demandant de modifier la gestion de l’appareil générera des tickets d’assistance.

3. L’appareil se désinscrit du MDM d’origine. L’appareil supprime le profil de gestion du MDM d’origine ainsi que tous les profils de configuration fournis par ce MDM.

4. L’appareil s’enregistre auprès du MDM de destination. L’appareil contacte les serveurs d’Apple, récupère le profil d’inscription attribué pour le MDM de destination et finalise l’inscription.

5. Le MDM de destination fournit les profils de configuration et les applications. L’appareil reçoit les profils qui lui sont attribués et commence à installer les applications gérées. Les appareils ne sont pas réinitialisés. Les données utilisateur, les applications installées localement et les réglages non liés à la configuration fournie par le MDM sont conservés.

Remarque concernant la conservation des applications : les applications gérées attribuées via « Applications et livres » sont conservées lors de la migration vers OS 26 si le MDM de destination est configuré pour revendiquer la gestion de ces applications. Si le MDM de destination ne revendique pas ces applications, celles-ci peuvent passer du statut « géré » à « non géré », ce qui a des implications sur les données des applications gérées et le comportement de l’effacement sélectif. Vérifiez la configuration de la revendication de gestion des applications de votre MDM de destination avant la migration.

Continuité de FileVault et de la configuration de sécurité

Les clés de récupération FileVault sont stockées par le MDM source. Lorsqu’un Mac migre vers le MDM de destination, le MDM source perd sa connexion de gestion et la clé de récupération qui y est stockée devient orpheline.

Pour assurer la continuité de la clé de récupération FileVault :

• Après la migration, le MDM de destination doit émettre une commande de rotation de la clé de récupération FileVault. Cela génère une nouvelle clé de récupération qui est conservée en dépôt auprès du MDM de destination.
• Jusqu’à ce que cette rotation ait lieu, la clé précédente stockée dans le MDM source reste valide pour la récupération, mais elle n’est plus gérée.
• Donnez la priorité aux Mac sur lesquels FileVault est activé dans votre liste de contrôle de validation de la migration. Vérifiez que la nouvelle clé de récupération est conservée en dépôt dans le MDM de destination pour chaque appareil.

Pour les autres configurations de sécurité, vérifiez les éléments suivants dans le MDM de destination après la migration :

• Application de la politique de verrouillage d’écran et de mot de passe
• État du pare-feu
• État de la protection de l’intégrité du système (SIP) sur les Mac Intel
• Configuration de Gatekeeper
• Profils de confiance des certificats

Si votre organisation suit un cadre de conformité, c’est le moment idéal pour effectuer un contrôle de conformité sur chaque appareil. Considérer la gestion des appareils et la sécurité comme une discipline intégrée, plutôt que comme des axes de travail distincts, permet une validation post-migration plus systématique.

Stratégies de migration pour les appareils fonctionnant sous une version antérieure à OS 26

Pour les appareils fonctionnant sous iOS/iPadOS ou macOS antérieurs à la version 26, trois options s’offrent à vous :

Option 1 : effectuez la mise à jour vers la version 26 du système d’exploitation, puis procédez à la migration. Si l’appareil prend en charge la version 26 du système d’exploitation, déployez la mise à jour depuis le MDM source avant de lancer la migration. Il s’agit de la solution la plus simple pour le matériel éligible.

Option 2 : désinscrire l’appareil du MDM source, puis le réinscrire dans le MDM de destination. Pour les appareils inscrits via ADE, vous pouvez les désinscrire du MDM source ; l’appareil se réinscrira alors auprès du MDM de destination en fonction de son affectation Apple Business. Cette procédure ne nécessite pas d’effacement complet, mais l’utilisateur devra suivre les étapes de l’Assistant de configuration si vous ne les avez pas configurées pour qu’elles soient ignorées.

Option 3 : réinitialisation aux paramètres d’usine et réinscription. Pour les appareils ne faisant pas partie d’Apple Business ou ceux présentant des configurations locales complexes devant être effacées, un effacement complet suivi d’une réinscription constitue l’option la plus propre. C’est l’option qui nécessite le plus de coordination avec les utilisateurs finaux.

Répertoriez dès le début de la planification la répartition des versions du système d’exploitation au sein de votre parc. Si 30 % de vos Mac fonctionnent sous macOS Sequoia et ne sont pas éligibles à la version 26, cela représente un volet opérationnel important à planifier séparément.

Planification de la réversion et procédures d’urgence

La plupart des guides de migration omettent cette section. Ne faites pas cette erreur.

Avant de lancer toute migration en production, définissez votre seuil de retour en arrière : à quel moment allez-vous suspendre ou annuler la migration ? Les déclencheurs courants sont notamment :

• Plus de X % des appareils migrés ne parvenant pas à recevoir les profils de configuration dans un délai de Y heures
• La perte d’applications gérées dépassant un seuil défini
• Signalement de lacunes dans les clés de récupération FileVault supérieures à un pourcentage défini
• Échec de l’installation des outils de sécurité (EDR, protection des terminaux) sur les appareils migrés

Dans le cadre du processus de migration vers OS 26, la réversion consiste à réaffecter les appareils au serveur MDM source dans Apple Business et à déclencher une migration inverse. Cela est techniquement possible, mais nécessite que le serveur MDM source soit toujours actif et dispose d’une licence valide. Ne résiliez pas votre contrat MDM d’origine avant d’avoir confirmé la réussite de la migration et effectué la validation post-migration pour l’ensemble du parc.

Pour les grands parcs, un déploiement par phases est la pratique courante : migrez un groupe pilote de 10 à 20 appareils provenant d’une équipe non critique, validez minutieusement, puis procédez par lots. Chaque lot doit faire l’objet d’un point de contrôle de validation avant le début du lot suivant.

Validation post-migration et vérification de la conformité

La validation post-migration est un aspect dans lequel de nombreuses équipes investissent trop peu. Un appareil qui semble inscrit dans le MDM de destination n’est pas nécessairement conforme. Vérifiez chacun des points suivants pour vos appareils migrés :

• Profils de configuration fournis et appliqués (interrogez l’appareil pour connaître les profils installés)
• Applications gérées installées et en état « géré »
• Clé de récupération FileVault déposée auprès du système MDM de destination
• Outils de sécurité (agent EDR, protection des terminaux) installés et générant des rapports
• Appareil conforme à toutes les politiques requises
• Profils de certificats installés et valides

Intégrez ces éléments dans une liste de contrôle de validation formelle et appliquez-la à chaque lot de migration avant de marquer ce lot comme terminé. Si votre MDM de destination dispose d’un tableau de bord de conformité ou d’une vue de reporting, utilisez-le. Les appareils qui apparaissent comme enregistrés mais non conformes nécessitent un suivi immédiat.

L’approche d’Iru en matière de migration MDM Apple

La migration est souvent l’occasion pour les équipes de repenser l’ensemble de leur architecture de politiques, et pas seulement leur fournisseur MDM. Iru s’articule autour d’un concept appelé « Assignment Maps » (cartes d’affectation), qui vous permet de définir une hiérarchie structurée de politiques mettant en correspondance les attributs des appareils et des utilisateurs avec des ensembles de configuration. Lors de la migration depuis un MDM hérité, cela s’avère particulièrement utile car cela impose une conception réfléchie des politiques plutôt qu’une reproduction à l’identique de tout ce qui s’est accumulé dans l’ancien système au fil des années.

En ce qui concerne plus particulièrement la distribution des applications, le déploiement automatique d’Iru est configuré pour fournir les applications gérées avant même que la commande « DeviceConfigured » ne soit terminée. Cela signifie que les appareils qui suivent le processus de migration vers OS 26 reçoivent leurs applications dans le cadre de la séquence d’inscription initiale, plutôt que via un processus en arrière-plan que les utilisateurs pourraient percevoir comme une interruption.

Iru se connecte directement à Apple Business pour l’intégration de l’ADE et la gestion des APNs, ce qui simplifie le processus de migration. Il vous suffit d’affecter les appareils au serveur MDM d’Iru dans Apple Business, de configurer vos profils d’inscription et vos cartes d’affectation, et la migration se déroule selon le processus standard d’Apple.

Pour la validation de la posture de sécurité après la migration, la bibliothèque de conformité d’Iru comprend des éléments prédéfinis qui correspondent aux benchmarks CIS pour macOS et aux contrôles NIST courants. Après la migration, vous pouvez générer un rapport de conformité sur l’ensemble de votre parc et identifier immédiatement les appareils nécessitant une correction, plutôt que de créer ce mappage à partir de zéro.

Pour les équipes migrant depuis des plateformes héritées complexes, l’interface d’Iru est conçue en fonction du fonctionnement réel des frameworks de gestion d’Apple, ce qui réduit le temps d’apprentissage pour les administrateurs qui ont passé des années à contourner les abstractions d’un autre outil.

Tirer le meilleur parti de votre migration vers l’MDM d’Apple

Une migration vers le MDM d’Apple est, par définition, source de perturbations. Les équipes qui en sortent le mieux loties la considèrent comme une refonte délibérée de leur architecture de gestion, et non comme un simple changement de fournisseur. Cela implique de rationaliser la structure de vos profils, de valider vos niveaux de sécurité de référence par rapport à un cadre concret et de vérifier que chaque appareil est réellement conforme avant de déclarer le projet terminé.

La fonctionnalité de migration native d’OS 26 supprime l’obligation de réinitialisation d’usine pour les appareils éligibles, ce qui élimine la principale perturbation pour les utilisateurs. Cependant, le travail de planification, la documentation préalable à la migration et la validation post-migration restent essentiels, quelle que soit la voie de migration choisie.

Si votre équipe envisage de passer à Iru ou prévoit une migration depuis un autre fournisseur MDM Apple, demandez une démonstration pour découvrir comment les « Assignment Maps » et l’architecture native Apple d’Iru peuvent simplifier à la fois la migration et la gestion continue qui s’ensuit.