Autopilot Device Preparation (AP-DP) résout le problème du hash matériel, mais introduit une lacune : l'appareil ignore à quel tenant il appartient pendant l'OOBE. Autopilot Device Association comble précisément ce vide. Cet article s'adresse aux architectes et ingénieurs Intune qui cherchent à comprendre le mécanisme, ses composants techniques et ce qu'il rend possible pour le déploiement Windows.
Pourquoi Device Association était nécessaire
Avec Autopilot v1 (Classic Autopilot), le lien entre un appareil et un tenant reposait sur le hash matériel. Tant que ce hash était importé dans Intune, Windows savait dès l'OOBE à quel tenant il appartenait, et les paramètres OOBE (nommage, région, confidentialité, Wi-Fi, branding) pouvaient s'appliquer avant toute connexion utilisateur.
AP-DP a supprimé cette dépendance au hash — une avancée bienvenue pour des environnements comme GCCH où le hash matériel est interdit. Mais cette suppression a créé un angle mort : sans hash, AP-DP ne dispose d'aucun mécanisme pour identifier le tenant pendant l'OOBE. Il ne s'active qu'après la connexion de l'utilisateur.
Résultat : les OOBE Controls introduits pour AP-DP — nommage de l'appareil, paramètres régionaux, configuration Wi-Fi, branding — sont inopérants pendant l'OOBE faute de contexte tenant. Le framework est en place, mais rien ne peut le déclencher.
Autopilot Device Association est conçu pour fermer cet écart.
Découverte dans Windows Insider Preview Build 27686
La fonctionnalité a été repérée pour la première fois dans Windows Insider Preview Build 27686.1000, sous le nom interne AutoPilotDeviceTagging. Elle s'est manifestée par l'apparition de nouveaux fichiers JavaScript dans le dossier CloudExperienceHost, dont devicelink-page et devicelink-vm.
L'analyse de ces fichiers a rapidement révélé deux éléments clés :
- Une fonction
get_devicelinkinfodansWindows.Management.Service.dllqui collecte le numéro de série SMBIOS, le fabricant et le modèle, puis les encapsule dans un objet JSON. - L'acronyme DAP pour Device Association Page, confirmant le nom officiel de la fonctionnalité.
Microsoft a officiellement présenté la fonctionnalité lors de la session BRK341 à Microsoft Ignite, dans la rubrique "What's New for Windows", section Provision. Elle est apparue sur une diapositive sans commentaire verbal — ce qui indique généralement un code déjà intégré mais pas encore finalisé.
Mécanisme technique : du SMBIOS au UEFI
Le processus Device Association repose sur quatre étapes enchaînées :
La fonction get_devicelinkinfo interroge le SMBIOS pour extraire le numéro de série, le fabricant et le modèle. Ces données sont compilées dans un objet JSON.
L'objet JSON est converti en chaîne de caractères, puis utilisé pour générer un QR code scannable depuis un autre appareil. Une alternative par export manuel est également proposée.
Une fois le QR code scanné ou le fichier importé dans Intune, un marqueur nommé TENANT_DEVICE_LINK est positionné. Ce marqueur utilise le même GUID que l'Autopilot Marker introduit pour la remédiation du hash matériel.
Le DeviceLinkId généré lors de l'association est persisté dans une variable UEFI de l'appareil. Cette persistance garantit que le lien tenant survit à une réinstallation ou à un reset.
Le stockage du DeviceLinkId en UEFI suit exactement la même logique que l'Autopilot_Marker utilisé pour la remédiation du hash matériel. L'identifiant survit aux réinitialisations système, ce qui est indispensable pour un lien tenant durable.
Interface OOBE : deux modes d'association
Lorsque la feature flag 46301882 est activée, une nouvelle page Assign Device Association apparaît pendant l'OOBE. Cette page propose deux méthodes.
Scan de QR code
Un QR code est affiché sur l'écran de l'appareil en cours de configuration. Un technicien scanne ce code depuis un autre appareil (probablement une application Intune ou un portail dédié) pour déclencher l'association au tenant.
Dans l'état actuel des builds Insider, le contenu du QR code est codé en dur avec la valeur test datatest datatest — preuve que cette voie n'est pas encore fonctionnelle en production.
Export manuel des informations appareil
L'option Export Device Information génère un fichier ZIP contenant les journaux MDM. Ce ZIP inclut un fichier CSV (devicelink.csv) avec les données d'association encodées en base64.
Une fois décodées, ces données correspondent exactement à la structure JSON produite par get_devicelinkinfo : numéro de série, fabricant, modèle et DeviceLinkId.
Ce fichier CSV est destiné à être importé dans Intune pour réaliser l'association manuellement — un flux similaire à l'import de hash matériel pour Classic Autopilot, mais sans dépendance au TPM.
Autopilot Device Association n'est pas encore en disponibilité générale (GA). Le flux QR code reste non fonctionnel dans les builds actuelles. Aucune date de GA n'a été communiquée par Microsoft à ce jour.
Ce que Device Association rend possible
L'impact direct porte sur les OOBE Controls d'AP-DP. Avec le lien tenant établi avant la connexion, Windows dispose du contexte nécessaire pour télécharger et appliquer les paramètres OOBE configurés dans Intune :
- Règles de nommage de l'appareil
- Paramètres de confidentialité
- Configuration régionale et langue
- Paramètres Wi-Fi
- Branding organisationnel
Ce sont exactement les paramètres que Classic Autopilot v1 appliquait grâce au hash matériel. AP-DP les rendait inopérants pendant l'OOBE faute de contexte tenant. Device Association restaure cette capacité sans réintroduire la dépendance au hash.
Ce qu'il faut surveiller avant la GA
Plusieurs points restent à clarifier avant que cette fonctionnalité puisse être déployée en production :
- Le flux QR code n'est pas fonctionnel dans les builds actuelles. Le contenu est codé en dur à des fins de test.
- L'import CSV dans Intune : le portail Intune ne dispose pas encore d'une interface dédiée à l'import de fichiers
devicelink.csv. Cette surface d'administration reste à confirmer. - La feature flag
46301882doit être activée côté Windows pour que la page Device Association apparaisse. Le mécanisme de déploiement de cette flag en production n'est pas encore documenté. - La gestion des appareils réinitialisés : le
DeviceLinkIdétant stocké en UEFI, l'impact d'un effacement UEFI ou d'un remplacement de carte mère sur le lien tenant doit être clarifié.
Si votre organisation opère en GCCH et utilise déjà AP-DP, Device Association représente la pièce manquante pour retrouver un niveau de contrôle OOBE équivalent à Classic Autopilot. Suivez la roadmap Microsoft 365 et le Message Center pour la disponibilité GA.
Conclusion et actions à anticiper
Autopilot Device Association rétablit le lien tenant pendant l'OOBE pour AP-DP, sans réintroduire le hash matériel. C'est une évolution structurante pour les organisations qui ont migré vers AP-DP ou qui opèrent dans des environnements où le hash est interdit.
Ce qu'il est possible de préparer dès maintenant :
- Vérifier que vos profils OOBE Controls AP-DP sont configurés dans Intune : ils seront activables dès que Device Association sera GA.
- Documenter le flux d'association pour vos équipes terrain : selon le mode retenu (QR code ou CSV), le processus implique une intervention physique ou une étape d'import.
- Tester le flux d'export CSV dans un environnement Windows Insider pour comprendre la structure des données avant la GA.
- Si votre organisation déploie en GCCH, prioriser le suivi de cette fonctionnalité — elle lève le principal blocage opérationnel d'AP-DP dans ce cloud souverain.
Une fois en GA, le flux Device Association devrait s'intégrer naturellement dans les procédures de déploiement AP-DP existantes, en ajoutant une étape d'association avant la remise de l'appareil à l'utilisateur.