Calipia : le blog

Autopilot device preparation : la migration que Microsoft recommande sans vraiment la dater

Il y a des annonces Microsoft qui ressemblent à une invitation polie et qui sont en réalité un avis de déménagement. Celle publiée sur le blog Intune Customer Success appartient clairement à cette catégorie. Le message tient en une phrase : Autopilot device preparation devient la solution recommandée pour les scénarios pilotés par l’utilisateur, et les administrateurs sont invités à préparer le mouvement. Aucune date de fin de vie n’est annoncée pour Windows Autopilot historique, aucune obligation formelle, mais l’orientation produit ne laisse guère de place à l’interprétation.

Pour ceux qui ont passé les six dernières années à affiner leurs profils de déploiement, leurs group tags et leur Enrollment Status Page, la nouvelle a un petit goût amer. Rappelons tout de même que la FAQ officielle affirmait jusqu’ici qu’il n’était pas nécessaire de migrer depuis les profils Windows Autopilot existants vers les stratégies device preparation, les deux solutions ayant vocation à cohabiter un certain temps. Le discours a donc évolué en dix-huit mois, ce qui n’a rien d’anormal pour un service cloud, mais qui mérite d’être noté quand on construit un socle de poste de travail censé tenir cinq ans.

Ce qui change réellement sous le capot

Device preparation n’est pas une fonctionnalité supplémentaire, c’est une réécriture de l’architecture. La différence la plus structurante concerne l’identification du poste. Dans le modèle classique, le device doit être enregistré auprès du service Autopilot via son hardware hash, puis ciblé par des groupes dynamiques s’appuyant sur les attributs Autopilot. Dans le nouveau modèle, l’Enrollment Time Grouping ajoute le poste à un groupe de sécurité au moment de la connexion de l’utilisateur, et l’exigence de hash disparaît. On passe donc d’une logique d’inventaire préalable à une logique d’affectation à l’exécution.

Le second changement concerne la consolidation des objets de configuration. La stratégie device preparation regroupe les paramètres d’enrôlement, l’OOBE, le nommage de machine, les applications requises, les scripts PowerShell et le ciblage à l’enrôlement dans un flux unique, tandis qu’une page de préparation remplace l’Enrollment Status Page avec une progression plus lisible pour l’utilisateur et un statut de déploiement plus détaillé pour l’administrateur. Le reporting devient quasi temps réel, ce qui pour quiconque a déjà attendu la mise à jour d’un rapport Autopilot en pleine campagne de renouvellement constitue un argument sérieux.

Troisième élément, et sans doute le plus intéressant techniquement : la device association. Elle lie un poste Windows 11 physique au tenant avant même le début de l’enrôlement, en s’appuyant sur une attestation matérielle pour créer une relation de confiance entre la machine et l’organisation. Les appareils associés sont automatiquement marqués comme corporate-owned et peuvent recevoir des affectations de stratégie ciblées machine, un nommage et des personnalisations d’OOBE supplémentaires. La fonction arrive dans la vague Intune d’août 2026 et se déploiera prochainement sur Windows 26H1 via la mise à jour KB5124006.

Notons au passage l’ironie de la chose. Microsoft supprime l’enregistrement préalable par hash matériel d’un côté, et réintroduit de l’autre un mécanisme d’association préalable au tenant. La différence est réelle, l’attestation matérielle valant mieux qu’un fichier CSV baladeur, mais on ne peut pas dire que le cycle de vie du poste s’en trouve simplifié. L’association nécessite un TPM 2.0 activé et sain, elle persiste à travers les resets et les réinstallations, et sa suppression impose l’exécution manuelle d’un script local par un administrateur ou un partenaire disposant d’un accès physique à la machine, typiquement lors d’une revente, d’un recyclage ou d’un transfert. Les DSI qui fonctionnent en location financière ou qui renvoient massivement du matériel en fin de contrat ont ici un nouveau point de passage à intégrer dans leur processus de sortie de parc. Oublier l’étape revient à expédier chez le loueur des machines encore mariées à votre tenant, ce qui fera un excellent sujet de conversation avec le service juridique.

Le périmètre réel de la recommandation

C’est là que la lecture attentive s’impose. Microsoft recommande device preparation pour les scénarios éligibles pilotés par l’utilisateur : postes Windows 11 d’entreprise, déploiements user-driven en jointure Microsoft Entra, et Windows 365. En revanche, le pre-provisioning, le self-deploying mode, la jointure hybride Microsoft Entra et l’Autopilot into co-management doivent rester sur l’ancien mécanisme.

Autrement dit, la solution recommandée ne couvre pas les kiosques, les postes partagés en self-deploying, le white glove confié au distributeur, ni les environnements encore adossés à un Active Directory. Pour une entreprise française de taille significative, cela représente rarement une portion négligeable du parc. La conséquence pratique est donc une cohabitation durable de deux socles de provisioning, avec deux modèles de ciblage, deux formes de reporting et deux jeux de procédures pour le support de niveau 1. Ceux qui espéraient une simplification immédiate devront patienter.

Les limites fonctionnelles méritent aussi l’attention des architectes. La comparaison officielle est sans ambiguïté : device preparation livre jusqu’à dix applications essentielles et dix scripts PowerShell, uniquement en ciblage machine pendant l’OOBE, là où Windows Autopilot accepte un nombre quelconque d’applications et distingue ESP device et ESP utilisateur. Pour les organisations qui ont pris l’habitude de tout empiler dans l’ESP, l’exercice de migration sera d’abord un exercice de renoncement. Ce n’est pas nécessairement une mauvaise nouvelle. Un poste qui met quarante minutes à devenir utilisable parce qu’on lui a demandé d’installer la suite complète avant le premier écran n’a jamais été un modèle d’expérience collaborateur.

La méthode de transition proposée

Sur ce point, le billet de Microsoft est plutôt raisonnable. Il recommande de commencer par une population d’appareils éligible plutôt que de viser une migration globale, en créant des groupes de sécurité Entra statiques, en construisant les stratégies device preparation autour de la configuration requise, puis en s’appuyant sur l’Enrollment Time Grouping pour placer les machines dans les bons groupes lors de l’enrôlement. Surtout, il déconseille explicitement de recréer à l’identique chaque configuration Autopilot existante, et invite à repartir des besoins réels de chaque population avant de les projeter dans une stratégie de préparation. Traduction pour les équipes poste de travail : la migration est l’occasion rêvée de solder la dette de configuration accumulée depuis 2019, celle que personne n’ose toucher parce que le collègue qui l’avait paramétrée est parti chez un concurrent.

Pour le parc existant, la mécanique proposée évite le big bang. Il n’est pas nécessaire de forcer le reset des machines déjà enrôlées : il suffit de les pré-associer pour qu’elles empruntent le flux device preparation lors de leur prochain reset naturel ou requis. La pré-association ne réinitialise pas la machine et ne perturbe pas son usage courant. Les profils de déploiement, les profils ESP, les groupes et les enregistrements ne doivent être retirés qu’une fois que le reporting confirme qu’aucune population active ou planifiée n’en dépend encore. Un avertissement mérite d’être surligné dans les runbooks : supprimer trop tôt l’enregistrement Windows Autopilot peut faire disparaître les propriétés Autopilot et casser l’appartenance aux groupes dynamiques qui soutiennent la configuration courante du poste. Le scénario du groupe dynamique qui se vide un vendredi soir est un classique du genre, et il ne s’améliore pas avec l’âge. 

Ce qu’il faut retenir côté DSI

Trois chantiers concrets se dessinent. D’abord un inventaire des scénarios de provisioning par population de postes, avec un verdict clair sur l’éligibilité au nouveau modèle. Ensuite une refonte du modèle de ciblage, puisque les group tags et les groupes dynamiques associés cèdent la place à des groupes statiques alimentés à l’enrôlement, ce qui déplace la question de la gouvernance des groupes Entra vers les équipes poste de travail. Enfin une révision des processus de sortie de parc pour intégrer la levée d’association UEFI, sujet qui concerne autant les achats et la logistique que la technique.

La bonne nouvelle, c’est que rien n’impose de tout faire ce trimestre. La moins bonne, c’est que l’absence de calendrier officiel n’est pas une garantie de longévité, et que l’expérience des dernières années dans l’écosystème Intune invite à ne pas confondre cohabitation et statu quo. Commencer par un pilote régional ou par une population bien identifiée reste le pari le plus sage, ne serait-ce que pour découvrir les surprises avant qu’elles ne découvrent vos utilisateurs…

C’est un sujet que nous aborderons aussi dans le prochain Briefing Calipia qui aura lieu en décembre : bloquez vos agendas et inscrivez-vous !