Points clés à retenir (TL;DR)
Synthèse exécutive- Autopilot permet un provisioning zero-touch : un poste neuf est livré directement à l'utilisateur, qui l'allume, se connecte et obtient une machine configurée et conforme sans intervention TI sur site.
- La pièce maîtresse est l'appartenance dynamique Entra basée sur l'attribut
department, qui route automatiquement apps et stratégies par service. - L'enregistrement des hardware hashes se fait idéalement via la synchronisation fabricant (CSP OEM), avec un fallback manuel ou par script pour les postes existants.
- L'Enrollment Status Page (ESP) bloque la session jusqu'à l'installation des apps critiques, garantissant un poste utilisable dès la première ouverture.
- Toute la configuration est scriptable via Microsoft Graph, ce qui la rend reproductible, versionnable et auditable.
Le probleme qu’on resout
La préparation manuelle d’un poste de travail (installation de l’OS, jonction au domaine, déploiement des logiciels, chiffrement, politiques de sécurité) consomme facilement une demi-journée par machine. Pour une PME qui renouvelle quelques dizaines de postes par an, cela représente un coût caché élevé et une qualité inégale : chaque technicien configure à sa façon, les écarts de conformité s’accumulent.
Les méthodes « évidentes » montrent vite leurs limites. Une image maître (WIM/MDT) doit être reconstruite à chaque mise à jour majeure de Windows et impose que la machine transite par l’atelier TI. Une GPO de domaine suppose une infrastructure Active Directory sur site et une jonction réseau préalable, incompatible avec un poste livré directement chez l’utilisateur en télétravail. Aucune de ces approches n’offre un parcours fluide où la TI n’a jamais à toucher physiquement la machine.
Autopilot renverse la logique : le poste sort d’usine en Windows standard, et c’est le cloud (Entra ID + Intune) qui, lors de la première connexion, reconnaît la machine, applique le profil de déploiement et pousse la configuration cible. L’objectif de ce guide est de rendre ce flux complet reproductible dans votre organisation.

Comment ca marche
Le mécanisme repose sur une chaîne d’identité et d’automatisation. Chaque poste possède un hardware hash (empreinte matérielle unique) qui doit être enregistré dans Intune. Quand la machine démarre pour la première fois et atteint l’écran OOBE (Out-Of-Box Experience), Windows interroge le service Autopilot, trouve le hash enregistré et télécharge le profil de déploiement associé.
Le profil définit le mode (ici user-driven, piloté par l’utilisateur), le type de jonction (Microsoft Entra Join pur, sans dépendance à un domaine sur site), le gabarit de nom de machine et les écrans OOBE à masquer. L’utilisateur s’authentifie avec son compte Entra et son MFA ; la machine effectue sa jonction, puis l’ESP prend le relais pour installer les applications et stratégies obligatoires avant de libérer la session.
C’est ici qu’interviennent les groupes dynamiques. Plutôt que d’assigner apps et politiques poste par poste, on crée des groupes Entra dont l’appartenance est calculée par une règle (par exemple l’attribut department de l’utilisateur). Chaque service reçoit ainsi automatiquement son catalogue applicatif. Enfin, les stratégies de conformité (BitLocker, TPM, version minimale de Windows, complexité du mot de passe) vérifient en continu que le poste respecte le socle de sécurité et conditionnent l’accès aux ressources.
Prerequis
- Un locataire Microsoft Entra ID actif avec Intune défini comme autorité MDM.
- Des licences couvrant Intune (Microsoft 365 Business Premium ou un plan EMS/E3/E5).
- Si vous synchronisez des comptes depuis un AD sur site : connecteur de synchronisation opérationnel (l’attribut
departmentdoit remonter dans Entra). - Un compte ou une application avec les portées Graph :
DeviceManagementConfiguration.ReadWrite.All,DeviceManagementServiceConfig.ReadWrite.All,Group.ReadWrite.All,User.Read.All. - Le module PowerShell
Microsoft.Graphinstallé et le script communautaireGet-WindowsAutopilotInfoCommunity. - Droits d’administrateur local sur les postes pilotes pour l’extraction manuelle des hashes.
Procedure
- Nettoyer les données d’annuaire : auditer les utilisateurs sans
departmentet harmoniser les libellés (éviter les doublons dus à des fautes de frappe). C’est le socle de tout le routage dynamique. - Créer les groupes dynamiques par service, plus un méta-groupe « tous les employés avec département » et un petit groupe statique pour le pilote.
- Créer le profil de déploiement Autopilot (mode user-driven, Entra Join) et l’assigner d’abord au groupe pilote.
- Créer l’ESP avec les apps critiques en suivi et un délai d’expiration raisonnable.
- Définir les stratégies de conformité (BitLocker, TPM, version d’OS, mot de passe) et leurs actions graduées en cas de non-conformité.
- Assigner les applications : commun en Required sur le méta-groupe, apps métiers en Available sur chaque groupe de service.
- Enregistrer les hardware hashes : manuellement pour les pilotes, en masse (script ou sync OEM) pour le reste.
- Tester de bout en bout sur les postes pilotes, valider les critères go/no-go, puis étendre au parc.
Le script
Le bloc suivant crée les groupes dynamiques par service et le méta-groupe, puis crée et assigne le profil de déploiement et l’ESP. Toutes les valeurs sont génériques : adaptez les noms de services à votre organisation.
# --- Connexion à Microsoft Graph (portées minimales requises) ---
Connect-MgGraph -Scopes "Group.ReadWrite.All","DeviceManagementConfiguration.ReadWrite.All",`
"DeviceManagementServiceConfig.ReadWrite.All","User.Read.All"
# --- 1) Création des groupes dynamiques par service ---
# Remplacez les libellés 'Dept' par EXACTEMENT ceux de votre attribut department
$services = @(
@{ Nom = "AP-Service-A"; Dept = "Service A" },
@{ Nom = "AP-Service-B"; Dept = "Service B" },
@{ Nom = "AP-Service-C"; Dept = "Service C" }
)
foreach ($s in $services) {
$body = @{
displayName = $s.Nom
description = "Autopilot - service : $($s.Dept)"
mailEnabled = $false
mailNickname = $s.Nom.ToLower().Replace(" ","-")
securityEnabled = $true
groupTypes = @("DynamicMembership")
# Règle : membre actif dont le département correspond
membershipRule = "(user.department -eq `"$($s.Dept)`") and (user.accountEnabled -eq true) and (user.userType -eq `"Member`")"
membershipRuleProcessingState = "On"
} | ConvertTo-Json -Depth 5
try {
$g = Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/groups" `
-Body $body -ContentType "application/json"
Write-Host "OK groupe cree : $($s.Nom) (id $($g.id))"
} catch { Write-Warning "Echec $($s.Nom) : $($_.Exception.Message)" }
}
# --- 2) Méta-groupe : tous les employés avec un département ---
$meta = @{
displayName = "AP-All-Employees"
description = "Autopilot - tous les employes avec departement assigne"
mailEnabled = $false
mailNickname = "ap-all-employees"
securityEnabled = $true
groupTypes = @("DynamicMembership")
membershipRule = "(user.department -ne null) and (user.accountEnabled -eq true) and (user.userType -eq `"Member`")"
membershipRuleProcessingState = "On"
} | ConvertTo-Json -Depth 5
$allGroup = Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/groups" `
-Body $meta -ContentType "application/json"
# --- 3) Groupe pilote STATIQUE (membres ajoutés à la main) ---
$pilot = @{
displayName = "AP-Pilot"
description = "Volontaires pour le pilote Autopilot"
mailEnabled = $false
mailNickname = "ap-pilot"
securityEnabled = $true
} | ConvertTo-Json
$pilotGroup = Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/groups" `
-Body $pilot -ContentType "application/json"
# --- 4) Profil de déploiement Autopilot (user-driven, Entra Join) ---
$profileBody = @{
"@odata.type" = "#microsoft.graph.azureADWindowsAutopilotDeploymentProfile"
displayName = "AP-Deployment-Standard"
description = "Profil standard user-driven, Entra Join pur"
language = "fr-CA"
locale = "fr-CA"
deviceNameTemplate = "PC-%SERIAL%" # gabarit de nom generique
hardwareHashExtractionEnabled = $false
outOfBoxExperienceSettings = @{
deviceUsageType = "singleUser"
userType = "standard"
hidePrivacySettings = $true
hideEULA = $true
hideEscapeLink = $true
skipKeyboardSelectionPage = $false
}
} | ConvertTo-Json -Depth 10
$apProfile = Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeploymentProfiles" `
-Body $profileBody -ContentType "application/json"
# --- 5) Assigner le profil au groupe pilote ---
$assign = @{
target = @{
"@odata.type" = "#microsoft.graph.groupAssignmentTarget"
groupId = $pilotGroup.id
}
} | ConvertTo-Json -Depth 5
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeploymentProfiles/$($apProfile.id)/assignments" `
-Body $assign -ContentType "application/json"
# --- 6) Enrollment Status Page (ESP) ---
$espBody = @{
"@odata.type" = "#microsoft.graph.windows10EnrollmentCompletionPageConfiguration"
displayName = "AP-ESP-Standard"
description = "Enrollment Status Page Autopilot"
priority = 1
showInstallationProgress = $true
blockDeviceSetupRetryByUser = $false
allowDeviceResetOnInstallFailure = $true
allowLogCollectionOnInstallFailure = $true
allowDeviceUseOnInstallFailure = $false
installProgressTimeoutInMinutes = 60
customErrorMessage = "Une erreur est survenue. Contactez votre support TI."
trackInstallProgressForAutopilotOnly = $true
selectedMobileAppIds = @() # a remplir avec les IDs des apps critiques
} | ConvertTo-Json -Depth 10
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations" `
-Body $espBody -ContentType "application/json"
Write-Host "Configuration de base deployee. Validez sur le groupe pilote avant extension."
Extraction du hardware hash sur un poste pilote (PowerShell en administrateur local), puis import dans Intune :
# Sur chaque poste pilote, en admin local
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force
Install-Script -Name Get-WindowsAutopilotInfoCommunity -Force -Confirm:$false
# Extraction locale vers un CSV nomme d'apres la machine
Get-WindowsAutopilotInfoCommunity.ps1 -OutputFile "$env:TEMP\$env:COMPUTERNAME.csv"
# Variante : upload direct dans Intune (contexte requis : droits Intune)
# Get-WindowsAutopilotInfoCommunity.ps1 -Online -Tag "Enrolled-Pilot"
Validation
Après provisioning d’un poste pilote, vérifiez point par point :
- Appartenance dynamique : dans Entra, le compte utilisateur apparaît bien dans le groupe de son service (le recalcul peut prendre quelques minutes).
- Reconnaissance Autopilot : le poste apparaît sous Appareils → Windows → Inscription Windows → Appareils avec le profil
AP-Deployment-Standardet un statut « Assigné ». - Jonction et gestion : le poste est listé comme « Microsoft Entra joined » et, dans Intune, « Corporate / Managed / Compliant ».
- Nom de machine conforme au gabarit défini.
- Chiffrement :
Get-BitLockerVolumeretourne un volume protégé et la clé de récupération est bien escrowée dans Entra. - Applications : les apps en Required sont installées et le portail d’entreprise permet d’ajouter les apps Available.
Critère go/no-go suggéré : au moins 4 postes pilotes sur 5 réussissent intégralement, avec un temps de provisioning moyen inférieur à 60 minutes.

Plan de retour (rollback)
Comme on déploie d’abord sur un groupe pilote restreint, le rayon d’impact reste contenu. Pour revenir en arrière :
- Désassigner le profil et l’ESP du groupe concerné (supprimer l’affectation). Les nouveaux démarrages OOBE ne seront plus pris en charge par Autopilot, mais les postes déjà provisionnés restent fonctionnels.
- Retirer un poste d’Autopilot : supprimer son objet dans Inscription Windows → Appareils, ce qui annule la reconnaissance au prochain OOBE.
- Suspendre les stratégies de conformité en désassignant le groupe, pour éviter de bloquer l’accès pendant une investigation.
- Groupes dynamiques : passer
membershipRuleProcessingStateàPausedfige l’appartenance sans supprimer le groupe ; la suppression du groupe est le dernier recours. - Poste individuel en échec : réinitialiser localement (Paramètres → Récupération → Réinitialiser) ou déclencher un Wipe depuis Intune, puis relancer l’OOBE.
Conservez systématiquement les identifiants (IDs) des objets créés : ils facilitent un retrait ciblé sans affecter le reste.
Depannage
| Symptôme | Cause probable | Solution |
|---|---|---|
| Le poste ne déclenche pas Autopilot à l’OOBE | Hardware hash non enregistré ou profil non assigné | Vérifier la présence du poste dans l’inscription Windows et l’affectation du profil au bon groupe ; attendre le recalcul. |
| Erreur réseau 80180018 pendant l’OOBE | Accès bloqué aux points de terminaison Microsoft | Autoriser les domaines *.microsoft.com et *.msftauth.net et vérifier le Wi-Fi/DHCP du segment utilisé. |
| Expiration de l’ESP (0x800705B4) | Délai trop court pour les installations | Augmenter installProgressTimeoutInMinutes et réduire le nombre d’apps suivies dans l’ESP. |
| App requise bloque l’ESP (0x87D1FDE8) | Application non installable (détection, dépendance) | Corriger la règle de détection de l’app ou la retirer temporairement des apps suivies par l’ESP. |
| L’utilisateur n’hérite pas de ses apps métiers | Attribut department vide ou libellé non conforme |
Corriger l’attribut dans l’annuaire, forcer la synchronisation et vérifier l’appartenance au groupe dynamique. |
Les journaux clés sur le poste se trouvent dans C:\Windows\Panther et dans le dossier de l’extension de gestion Intune (C:\ProgramData\Microsoft\IntuneManagementExtension\Logs).
Securite, changement et bonnes pratiques
Secrets et moindre privilège : n’utilisez jamais un Global Admin pour les opérations courantes. Préférez des rôles ciblés (Administrateur Intune, Administrateur de groupes) ou une application avec uniquement les portées Graph nécessaires. Stockez les secrets dans un coffre et non en clair dans les scripts. Pour l’audit initial, travaillez d’abord en lecture seule avant d’exécuter les opérations d’écriture.
Qualité des données : la fiabilité du routage dynamique dépend entièrement de la propreté de l’attribut department. Mettez en place un contrôle régulier des comptes sans département et un référentiel de libellés normalisés.
Cadrage ITIL : la mise en place d’Autopilot est un changement normal qui doit passer en CAB (comité consultatif sur les changements), avec une fiche de changement décrivant l’impact, le plan de retour et les critères de succès. La phase pilote constitue la validation du risque ; l’extension au parc peut alors être traitée comme une série de changements standards pré-approuvés. Planifiez les extractions de hashes en masse et les Wipes de postes dans une fenêtre de maintenance, et rattachez les incidents de provisioning au processus de gestion des incidents, les défauts récurrents (ex. échec systématique d’une app dans l’ESP) au processus de gestion des problèmes.
Déploiement progressif : commencez par 5 postes, puis un service entier, avant la généralisation. Chaque palier confirme que les apps, la conformité et les temps de provisioning tiennent à l’échelle.
A retenir
Windows Autopilot transforme la préparation des postes d’une tâche manuelle et chronophage en un flux automatisé piloté par le cloud. La clé du succès tient en trois points : des données d’annuaire propres (l’attribut department), une architecture de groupes dynamiques qui fait le routage à votre place, et une configuration scriptée donc reproductible et auditable. En validant d’abord sur un pilote restreint, vous maîtrisez le risque et obtenez des critères go/no-go tangibles avant d’étendre au parc.
Prochaine étape concrète : auditez dès maintenant vos comptes sans département, créez vos trois ou quatre premiers groupes dynamiques, puis lancez un pilote restreint avant d’étendre au parc.