ITSkillsCenter
Business Digital

Microsoft Intune : Windows Autopilot et politiques de conformité

13 min de lecture

Microsoft Intune est le service qui pilote les postes Windows et les terminaux mobiles d’une organisation. Il agit sur deux plans : la gestion des appareils (MDM) et la gestion des applications (MAM). Ce tutoriel met en place le déploiement zéro-touche des PC Windows neufs avec Windows Autopilot, puis la politique de conformité qui interagit avec l’accès conditionnel pour bloquer les appareils non sécurisés.

Article principal : Microsoft 365 pour PME — architecture et gouvernance.

Prérequis

  • Une licence par utilisateur incluant Microsoft Intune et Microsoft Entra ID P1. Les deux sont inclus dans Microsoft 365 Business Premium.
  • Un compte avec le rôle Administrateur Intune ou Administrateur global.
  • Un fournisseur OEM partenaire Autopilot (Dell, HP, Lenovo, ASUS, Acer, Surface, etc.) ou un poste existant dont on récupère manuellement le hardware hash.
  • Un domaine Microsoft Entra ID configuré (cf. Adoption Microsoft 365 — embarquer une équipe en 8 semaines).
  • Niveau attendu : administrateur Microsoft 365 confirmé, à l’aise avec PowerShell.
  • Temps : 3 heures pour la mise en place initiale, 5 minutes par poste enrôlé ensuite.

Étape 1 — Comprendre les scénarios de déploiement

Windows Autopilot se décline en plusieurs scénarios qu’on choisit en fonction du contexte. Le scénario User-Driven est le plus courant : le collaborateur reçoit le PC neuf, le déballe, se connecte au Wi-Fi, saisit son identifiant et son mot de passe Microsoft Entra, et l’OS finalise lui-même la configuration en imposant les politiques Intune. Le scénario Self-Deploying ne demande aucune saisie utilisateur et convient aux bornes ou aux postes en libre-service. Le scénario Pre-Provisioned (anciennement White Glove) permet à un technicien d’amener le PC en état presque-prêt avant de le remettre au collaborateur, qui termine la configuration en quelques minutes. Le scénario Existing Devices applique Autopilot à un parc existant pour le ré-enrôler avec les politiques modernes.

Pour une PME, le scénario par défaut est User-Driven. On y revient pour les choix particuliers : une borne d’accueil partagée bascule en Self-Deploying, un poste de direction prêt à l’usage immédiat passe par Pre-Provisioned. La décision se prend par profil de poste, pas par utilisateur.

Étape 2 — Configurer la jointure automatique Microsoft Entra et Intune

Avant de déployer le moindre poste, on configure l’enrôlement automatique. Dans le centre Intune (endpoint.microsoft.com) on ouvre Devices → Windows → Windows enrollment → Automatic Enrollment. On active MDM user scope à All (ou à un groupe de sécurité si on déploie en pilote). Cette configuration relie l’authentification Microsoft Entra ID à l’inscription automatique du poste dans Intune au premier démarrage.

Ce paramétrage nécessite Microsoft Entra ID P1 par utilisateur enrôlé (inclus dans Microsoft 365 Business Premium). Sans P1, l’inscription doit être lancée manuellement par le collaborateur dans Paramètres Windows → Comptes → Accéder à votre lieu de travail ou à votre établissement scolaire, ce qui annule l’intérêt zéro-touche du déploiement.

Étape 3 — Importer les appareils dans Autopilot

Chaque appareil Autopilot est identifié par un hardware hash unique calculé par le firmware. La voie la plus efficace consiste à demander à l’OEM (Dell, HP, Lenovo, etc.) d’enregistrer directement les hashes des PC commandés dans le locataire Microsoft 365 — le partenaire reçoit l’identifiant locataire, et les PC apparaissent dans Autopilot avant même leur expédition. C’est le mode standard pour un parc neuf.

Pour des PC déjà en stock ou achetés au détail, on récupère le hash localement avec un script PowerShell.

# Capture du hardware hash sur un poste Windows existant
# À exécuter en administrateur sur le poste à enrôler
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile C:\autopilot.csv -Append

Le script écrit dans le fichier CSV un hash unique par appareil au format attendu par Autopilot. On peut concaténer plusieurs postes dans le même fichier en lançant la commande sur chacun avec le paramètre -Append. Le CSV s’importe ensuite dans le centre Intune via Devices → Windows → Windows enrollment → Devices → Import. L’import déclenche en arrière-plan une synchronisation qui peut prendre 15 minutes ; on rafraîchit la liste régulièrement jusqu’à voir les appareils apparaître avec le statut Not assigned.

Étape 4 — Créer un profil de déploiement Autopilot

Le profil Autopilot définit l’expérience que vivra l’utilisateur lors du premier démarrage. Dans le centre Intune, Devices → Windows → Windows enrollment → Deployment profiles → Create profile, on choisit Windows PC puis on configure les options clés : type de déploiement (User-Driven), type de jointure (Microsoft Entra joined), masquage de l’écran d’accord de licence Microsoft, masquage de l’écran de confidentialité, masquage du Cortana, langage et fuseau horaire imposés.

Le profil est ensuite assigné à un groupe d’appareils Microsoft Entra. La pratique recommandée consiste à créer un groupe dynamique Autopilot - Tous les appareils avec une règle d’appartenance qui inclut tous les appareils dont l’attribut device.devicePhysicalIDs contient [ZTDId] (l’identifiant Autopilot). Tout nouvel appareil importé rejoint automatiquement ce groupe et reçoit le profil sans intervention manuelle.

Étape 5 — Préparer les politiques de configuration des postes

Une fois Autopilot opérationnel, on prépare les politiques que les postes recevront à l’enrôlement. Trois familles structurent un déploiement de base. Premier : la politique de conformité (l’objet de l’étape suivante). Deuxième : les politiques de configuration qui imposent le chiffrement BitLocker, le pare-feu Windows Defender, la mise à jour Windows Update, le bandeau d’accueil personnalisé. Troisième : les applications déployées automatiquement — Microsoft 365 Apps for Enterprise, le navigateur Edge avec ses politiques d’organisation, l’antivirus Microsoft Defender en mode bloquant.

Pour les politiques de configuration, on utilise les Settings catalog — la nouvelle interface unifiée qui remplace progressivement les anciens modèles administratifs. Dans Devices → Configuration → Create → New policy → Platform = Windows 10 and later → Profile type = Settings catalog, on construit une stratégie en sélectionnant les paramètres : BitLocker → Enable encryption, Windows Update → Active hours, Defender → Real-time protection. La granularité est importante : on prépare une politique courte par thème plutôt qu’une politique géante difficile à diagnostiquer.

Étape 6 — Créer la politique de conformité

La politique de conformité énonce les conditions qu’un appareil doit remplir pour être considéré comme « conforme ». Cette information remonte à Microsoft Entra ID où l’accès conditionnel l’utilise pour autoriser ou bloquer les ressources. Sans cet aller-retour Intune-Entra, un appareil non chiffré pourrait accéder à SharePoint comme un appareil maîtrisé.

# Création d'une politique de conformité Windows minimale via Microsoft Graph
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"
$body = @{
  "@odata.type" = "#microsoft.graph.windows10CompliancePolicy"
  displayName = "Conformite-Windows-Standard"
  passwordRequired = $true
  passwordMinimumLength = 8
  passwordRequiredType = "alphanumeric"
  bitLockerEnabled = $true
  secureBootEnabled = $true
  codeIntegrityEnabled = $true
  storageRequireEncryption = $true
  defenderEnabled = $true
  rtpEnabled = $true
  antivirusRequired = $true
  antiSpywareRequired = $true
  osMinimumVersion = "10.0.19045"
} | ConvertTo-Json
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies" -Body $body -ContentType "application/json"

La politique impose un mot de passe alphanumérique de 8 caractères minimum, l’activation de BitLocker, le démarrage sécurisé, l’intégrité du code, le chiffrement du stockage, l’activation de Microsoft Defender en temps réel, et la version minimale de Windows à 10 22H2 (build 19045). L’appel retourne l’Id de la politique créée. On l’assigne ensuite à un groupe d’utilisateurs dans le centre Intune (la commande directe d’assignation via Graph est possible mais l’interface est plus claire pour cette opération).

Au-delà de la création, on calibre la politique sur deux dimensions importantes côté tenant. D’abord, dans Endpoint security → Device compliance → Compliance policy settings, on bascule l’option Mark devices with no compliance policy assigned as sur Not compliant. La valeur par défaut est Compliant, ce qui crée une faille où les appareils sans politique passent les contrôles d’accès conditionnel — Microsoft documente explicitement ce changement comme prérequis quand on couple Intune et accès conditionnel. Ensuite, on règle la Compliance status validity period sur 30 jours (valeur par défaut, configurable de 1 à 120 jours) ; un appareil qui n’a pas confirmé sa conformité depuis cette durée bascule automatiquement en non-conforme.

Étape 7 — Connecter la conformité à l’accès conditionnel

L’intégration finale consiste à exiger un appareil conforme dans une politique d’accès conditionnel. Dans le centre Entra → Conditional Access → Nouvelle politique, on cible un groupe d’utilisateurs (par exemple les administrateurs ou la direction au démarrage), Toutes les applications cloud, et dans Grant on coche Require device to be marked as compliant.

À partir de cette activation, un utilisateur ciblé qui tente d’accéder à Outlook ou SharePoint depuis un PC non enrôlé dans Intune reçoit un message d’erreur explicite : « Votre appareil n’est pas conforme aux politiques de votre organisation ». L’erreur n’est pas un blocage opaque : le portail d’entreprise (Company Portal) installé sur le PC propose le chemin de remédiation — chiffrer la partition, mettre à jour Windows, activer Defender. Cette boucle remédiation-vérification est le cœur de l’expérience moderne de gestion d’appareils.

L’intégration complète de cet accès conditionnel basé sur la conformité s’inscrit dans le tutoriel Accès conditionnel Microsoft Entra ID — quatre politiques de référence, qui pose les politiques de socle (MFA, blocage authentification héritée, géographie). On peut empiler la conformité comme cinquième politique, ciblée d’abord sur les rôles à privilèges, puis élargie progressivement à toute l’organisation au rythme des déploiements Autopilot.

Étape 8 — Tester un poste de bout en bout

Le test de validation se fait sur un PC neuf ou réinitialisé en usine. On allume le PC, on choisit la langue et le clavier, on connecte le Wi-Fi. À la place de l’écran de création de compte local Windows, l’OS détecte que l’appareil appartient à un locataire Autopilot et bascule sur l’écran de connexion Microsoft Entra de l’organisation. L’utilisateur saisit son identifiant et son mot de passe, déclenche la MFA, et l’écran d’accueil personnalisé s’affiche pendant que les politiques s’appliquent en arrière-plan.

Pour vérifier l’aboutissement de l’enrôlement, on consulte côté Intune Devices → Windows → Tous les appareils → [appareil de test]. Les onglets Compliance et Configuration doivent afficher Succeeded pour les politiques assignées. Le statut de chiffrement BitLocker se voit dans Endpoint security → Disk encryption. Si une politique reste en Pending plus d’une heure, on examine le rapport d’erreur ; les causes les plus fréquentes sont une dépendance non installée (ex. : politique BitLocker sans TPM activé dans le BIOS), un conflit entre deux politiques ciblant le même paramètre, ou un retard de propagation côté Microsoft.

Étape 9 — Industrialiser le ré-enrôlement (Autopilot Reset)

Une fois le déploiement maîtrisé, Autopilot Reset devient l’outil de routine pour le service informatique. Il efface tout ce qui appartient à l’utilisateur (comptes, fichiers locaux, applications installées hors politique) en gardant l’inscription Intune et la jointure Entra ID. Le poste se retrouve en quelques minutes dans l’état initial Autopilot, prêt à être remis à un autre collaborateur.

Le déclenchement se fait en local depuis l’écran de connexion Windows (combinaison Ctrl + Win + R) ou à distance via le centre Intune (Devices → [appareil] → Autopilot Reset). Le mode local convient au technicien sur place ; le mode distant est l’arme du support pour récupérer un poste compromis sans passer par la station physiquement. Cette capacité de remise à zéro pilotée à distance change radicalement la relation au support : là où l’on planifiait une visite ou un envoi par transporteur, on lance une action depuis un onglet de navigateur et le poste est utilisable une heure plus tard.

Erreurs fréquentes

Erreur Cause Solution
L’appareil n’apparaît jamais dans Autopilot Hash importé pour un autre locataire ou erreur dans le CSV Vérifier le format CSV, relancer Get-WindowsAutopilotInfo
Premier démarrage demande un compte Microsoft personnel Profil Autopilot non assigné à temps Réinitialiser le PC, attendre la synchronisation côté Intune, redémarrer
Les politiques restent en Pending Conflit entre stratégies ou prérequis matériel manquant Activer TPM 2.0 dans le BIOS, vérifier les conflits dans Reports
BitLocker ne se chiffre pas automatiquement TPM non détecté ou mode BIOS legacy au lieu d’UEFI Basculer en UEFI, activer Secure Boot, relancer la politique
Appareils sans politique passent l’accès conditionnel Paramètre tenant Mark devices… resté à Compliant Basculer le paramètre sur Not compliant
Retire ne supprime pas les données utilisateur Confusion entre Retire (entreprise) et Wipe (complet) Utiliser Wipe pour effacer entièrement, Retire pour ne retirer que les données pro

FAQ

Faut-il une licence Intune en plus de Microsoft 365 Business Premium ?

Non. Microsoft 365 Business Premium inclut Microsoft Intune (variante Intune Plan 1) pour chaque utilisateur. Pour les fonctionnalités avancées (Endpoint Privilege Management, Microsoft Tunnel, Analyses avancées), il faut une licence Intune Suite ou des add-ons spécifiques.

Peut-on enrôler un Mac avec Intune ?

Oui. Intune supporte macOS via Apple Business Manager (équivalent Apple à Autopilot) avec inscription automatique au premier démarrage. La logique de politiques de conformité est identique ; les paramètres applicables diffèrent (FileVault au lieu de BitLocker, Gatekeeper, mises à jour macOS).

Comment gérer les téléphones personnels (BYOD) ?

Sur les appareils personnels, on n’inscrit pas l’appareil entier en MDM (intrusion vie privée, refus utilisateur courant). On utilise les politiques de protection d’application (MAM) : code PIN spécifique pour ouvrir Outlook mobile, blocage du copier-coller vers une application non gérée, effacement sélectif des données pro à la fin du contrat. Aucune visibilité sur les photos, contacts personnels ou applications privées.

Que se passe-t-il quand un appareil reste hors ligne longtemps ?

Tant que la Compliance status validity period n’est pas dépassée (30 jours par défaut), l’appareil reste vu comme conforme et l’utilisateur peut accéder aux ressources. Au-delà, l’appareil bascule en non-conforme jusqu’à sa prochaine connexion à Intune. Cette mécanique évite à la fois les utilisateurs en déplacement bloqués sans raison et les appareils volés qui restent hors ligne plusieurs semaines avec des sessions encore valides.

Peut-on faire Autopilot sans avoir acheté les PC chez un partenaire OEM ?

Oui, via la procédure manuelle de capture du hardware hash décrite à l’étape 3. C’est un peu plus laborieux : il faut allumer chaque PC une première fois, exécuter le script PowerShell, importer le CSV. Pour un parc renouvelé chez un partenaire OEM, on demande l’enregistrement automatique côté constructeur et les PC arrivent prêts à enrôler — c’est le mode optimal au-delà de 10 postes par commande.

Tutoriels associés

Ressources officielles

Sponsoriser ce contenu

Cet emplacement est à vous

Position premium en fin d'article — c'est l'instant où les lecteurs sont le plus engagés. Réservez cet espace pour votre marque, votre formation ou votre offre.

Recevoir nos tarifs
Publicité