Windows Autopilot - Quel mode de déploiement choisir avec Intune ?

Ce que fait vraiment cette brique dans Microsoft 365

Je vois Autopilot comme un moteur d’orchestration. Il prend un poste livré avec Windows, s’appuie sur l’installation OEM déjà présente et le transforme en machine prête à l’emploi pour l’entreprise. L’intérêt n’est pas seulement de gagner du temps: on réduit surtout la dépendance aux images personnalisées, aux manipulations manuelles et aux variantes qui rendent un parc difficile à maintenir.

Concrètement, la plateforme sert à appliquer des politiques, enrôler l’appareil dans la gestion MDM, installer des applications et, selon le scénario, ajuster l’édition Windows pour activer des capacités professionnelles plus avancées. Dans une équipe IT, c’est souvent le point de bascule entre un onboarding artisanal et un flux de provisionnement réellement industrialisé. C’est pour cela que le choix du scénario vient avant le reste.

La différence qui compte entre la préparation de périphériques et le mode classique

C’est ici que les projets se trompent le plus souvent. Les deux approches se ressemblent du point de vue de l’utilisateur, mais elles ne couvrent pas les mêmes besoins et elles n’ont pas les mêmes limites. Quand je compare les deux, je regarde d’abord l’identité, le type d’appareil, les modes de déploiement et le volume d’applications à installer pendant l’accueil.

En pratique, je choisis la préparation de périphériques quand je veux un flux plus simple, plus lisible dans les rapports et mieux adapté à des postes Windows 11 homogènes. Je garde le mode classique dès qu’un besoin de coexistence avec Windows 10, de hybrid join, de pré-provisionnement ou de self-deploying entre dans l’équation. Une fois ce choix clarifié, les prérequis deviennent beaucoup plus faciles à sécuriser.

Les prérequis techniques à verrouiller avant le pilote

Avant d’envoyer un premier lot d’ordinateurs, je vérifie toujours cinq choses, dans cet ordre.

• Système Windows 11 seulement pour la variante de préparation, avec 24H2 ou 23H2/22H2 complété par KB5035942.
• Identité Microsoft Entra join uniquement. Si la machine est déjà enregistrée comme appareil Autopilot, le profil classique prend la main.
• Gestion un MDM compatible, typiquement Microsoft Intune, et des licences qui couvrent Entra ID et l’enrôlement automatique. Les familles les plus courantes sont Business Premium, F1/F3, A1/A3/A5, E3/E5, EMS E3/E5, Intune for Education, ou Entra P1/P2 avec Intune.
• Réseau les sorties vers l’activation Windows, Microsoft Entra ID, Intune, Windows Update et Delivery Optimization doivent passer proprement; sinon, le flux continue, mais vous perdez en rapidité et en fiabilité.
• Proxy et sécurité le proxy doit être géré côté infrastructure, pas bricolé via une stratégie Intune si vous voulez éviter les effets de bord.

Je regarde aussi les droits RBAC Intune: configurations des appareils, programmes d’inscription, applications gérées, applications mobiles et organisation. C’est souvent un détail en apparence, mais c’est lui qui bloque la création ou l’affectation des politiques quand l’équipe IT ne dispose que d’un rôle incomplet. Une fois ce socle verrouillé, on peut passer au déroulé opérationnel sans transformer l’OOBE en parcours d’obstacles.

Comment se déroule un déploiement de bout en bout

Le flux reste volontairement proche de ce que l’utilisateur final comprend le mieux: il allume le PC, se connecte au réseau, s’authentifie, puis l’environnement se configure sans qu’on lui demande de devenir technicien. La différence, côté IT, se joue dans la précision de la politique et dans le moment où les ressources sont affectées.

1. Le PC démarre en OOBE, l’écran de configuration initiale de Windows.
2. L’utilisateur s’authentifie avec son compte Microsoft Entra.
3. La politique ciblée sur le groupe d’utilisateurs déclenche le déploiement, et le poste rejoint automatiquement le groupe de sécurité défini dans la politique.
4. Les applications essentielles et les scripts sélectionnés s’installent pendant l’accueil initial. C’est là qu’on voit la limite utile du modèle: mieux vaut rester sélectif, avec un maximum de 25 applications essentielles et 10 scripts.
5. La page de fin confirme que l’accueil est terminé, mais certaines installations assignées au groupe d’appareils peuvent continuer en arrière-plan.
6. Le suivi se fait dans le rapport de déploiement quasi temps réel, avec la possibilité de récupérer les journaux de diagnostic en cas d’échec.

Le mécanisme d’“enrollment time grouping” est central ici: la machine est ajoutée au bon groupe dès l’inscription, ce qui accélère la livraison des politiques. C’est aussi ce qui explique pourquoi le flux est souvent plus stable que des affectations plus tardives et plus dispersées. Une fois cette mécanique comprise, les erreurs courantes deviennent beaucoup plus faciles à repérer.

Les erreurs qui font perdre du temps aux équipes IT

Dans les pilotes que j’ai vus échouer, le problème n’était presque jamais la technologie elle-même. C’était plutôt un mauvais cadrage du scénario ou des hypothèses trop optimistes sur ce que le flux pouvait faire immédiatement.

• Vouloir mélanger les deux mondes un poste déjà enregistré comme Autopilot peut faire passer le profil classique avant la préparation de périphériques.
• Attendre du mode récent ce qu’il ne sait pas faire il ne remplace pas le pré-provisionnement, le self-deploying ni les scénarios sur appareils existants.
• Mettre trop d’applications dans l’OOBE plus le panier de départ grossit, plus l’utilisateur attend et plus vous augmentez les risques de timeout.
• Mal traiter le réseau quand l’activation, Entra, Intune ou Windows Update ne passent pas bien, le déploiement continue parfois, mais le confort utilisateur s’effondre.
• Interpréter la page de fin comme une fin absolue elle signale la fin de l’accueil, pas la fin de toutes les installations arrière-plan.
• Tester sur un seul modèle de PC un déploiement propre sur un portable de démonstration peut se dégrader sur un autre BIOS, un autre Wi-Fi ou un autre constructeur.

Je traite ces points comme des garde-fous simples, pas comme des contraintes théoriques. C’est souvent en les corrigeant que le support baisse, bien plus qu’en ajoutant une couche de documentation. Et une fois les pièges évités, on peut passer à ce qui fait vraiment la différence à l’échelle.

Ce que je recommande pour standardiser un parc Windows

Mon approche est assez directe: je choisis la préparation de périphériques quand l’objectif est de livrer des PC neufs, homogènes, sous Windows 11, avec une identité cloud-native et un catalogue applicatif limité au strict nécessaire au premier démarrage. C’est un bon choix pour une PME ou une équipe IT qui veut réduire la variabilité sans monter une usine à gaz.

• Garder le démarrage léger je limite volontairement les applications “essentielles” à ce qui est indispensable pour travailler dès le premier jour.
• Décaler le reste après l’ouverture de session les applications moins critiques et les politiques secondaires passent ensuite, une fois que l’utilisateur est au bureau.
• Piloter avec un groupe dédié j’utilise un petit groupe de test, puis un groupe de production clairement séparé.
• Surveiller les rapports le tableau de bord quasi temps réel permet de voir rapidement si un lot entier décroche sur un même point.
• Conserver le mode classique quand il apporte une vraie valeur hybrid join, pré-provisionnement, self-deploying, anciens postes ou besoins de reprise restent de bons motifs de l’utiliser.
• Penser au contexte Microsoft 365 global pour certains cas comme Windows 365 Frontline en mode partagé, le mode automatique peut être plus pertinent qu’un déploiement standard.

Si je devais résumer ma règle de décision en une phrase, je dirais que la meilleure voie est celle qui simplifie le plus le poste cible sans vous fermer les portes dont vous aurez encore besoin dans six mois. C’est exactement ce tri qui évite les déploiements séduisants sur le papier, mais pénibles à opérer au quotidien.

Le bon réflexe pour éviter un mauvais choix de scénario

Au fond, la vraie question n’est pas “quelle fonctionnalité est la plus moderne”, mais “quel parcours d’inscription colle le mieux à mon identité, à mes licences et à mon réseau”. Quand ces trois paramètres sont clairs, le reste devient étonnamment rationnel: cloud-native et standardisé d’un côté, scénarios plus riches et plus hérités de l’autre.

Dans une équipe que je conseille, je commence toujours par le poste final attendu, pas par la marque du produit. Ce réflexe évite de surdimensionner le projet, de bloquer des utilisateurs au mauvais moment et de confondre un démarrage propre avec un vrai déploiement maîtrisé.