Pour auditer tout un parc Windows 10 sans ouvrir PC Health Check poste par poste, la méthode consiste à exécuter le script officiel de Microsoft, HardwareReadiness.ps1, sur chaque machine, à déployer cette exécution par GPO avec un filtre WMI qui cible les Windows 10, à stocker le résultat dans un attribut de l’objet ordinateur de l’Active Directory, puis à produire un rapport avec un second script. La chaîne repose donc sur un Active Directory et des GPO : sans eux, l’architecture décrite ici ne s’applique pas telle quelle. Reste à savoir lire les échecs, car c’est là que se décide le tri entre un réglage dans le BIOS/UEFI et un remplacement de machine.
Pourquoi la vérification manuelle ne tient pas
PC Health Check doit être lancé à la main sur chaque poste. Sur quelques machines, c’est supportable. Sur plusieurs dizaines, centaines ou milliers, cela devient une tournée de bureau en bureau, sans trace centralisée ni moyen de relancer un contrôle après une correction.
L’urgence pèse aussi sur le choix. Le support de Windows 10 a pris fin le 14 octobre 2025 : plus d’assistance technique, plus de mises à jour de sécurité ni de fonctionnalités. Le CERT-FR a constaté que 68 % des postes de travail des organismes utilisant son service ADS tournaient encore sous une version antérieure à Windows 11. Ce chiffre ne concerne que ces organismes, pas l’ensemble des parcs français, mais il donne la mesure du retard. Une étude ControlUp évoque de son côté 40 % du parc professionnel encore sous Windows 10 et 24 % de PC professionnels non compatibles.
La taille du parc tranche donc la question : PC Health Check à la main reste acceptable pour une poignée de postes, le script déployé par GPO devient nécessaire au-delà.
Ce que l’audit contrôle réellement
Le script reprend les critères officiels de Microsoft : processeur 64 bits d’au moins 1 GHz et 2 cœurs, 4 Go de RAM, 64 Go de stockage, UEFI avec Secure Boot, TPM 2.0, carte graphique compatible DirectX 12 avec pilote WDDM 2.0. Il contrôle aussi la version du système. Chaque test produit son propre résultat, ce qui permet de savoir quelle condition précise bloque un poste.
Le processeur mérite une attention particulière. Seuls les Intel de 8e génération (2017) et plus récents, ou les AMD Ryzen 2000 et plus récents, sont officiellement pris en charge. En dessous, le blocage est matériel : aucun réglage ne le lèvera.
Le script officiel HardwareReadiness.ps1
Microsoft fournit ce script prêt à l’emploi. Il s’exécute en administrateur et indique le résultat de chaque test : processeur, RAM, stockage, GPU, Secure Boot, TPM et version du système. La sortie existe en format lisible pour un contrôle ponctuel et en JSON, plus pratique dès qu’on veut l’exploiter par programme. Cette sortie JSON peut aussi servir de base si vous souhaitez ensuite alimenter un autre outil de suivi.
Le test sur un poste isolé reste une bonne première étape : il montre à quoi ressemble un échec avant de multiplier les exécutions.
La chaîne d’audit à l’échelle du parc
L’architecture décrite par IT-Connect enchaîne trois éléments :
- le script s’exécute sur chaque machine, déployé par une GPO dont le filtre WMI ne retient que les postes Windows 10 ;
- le résultat est écrit dans un attribut de l’objet ordinateur de l’Active Directory, ce qui évite de collecter des fichiers sur les postes ;
- un second script interroge l’annuaire et génère le rapport d’audit.
L’intérêt de passer par l’annuaire est de disposer d’un point de lecture unique, rattaché à l’objet que vous gérez déjà. Les détails d’implémentation du second script ne sont pas repris ici : reportez-vous à la documentation de l’auteur pour le code exact, et testez-le sur une unité d’organisation pilote avant de l’étendre. Le filtre WMI évite d’exécuter l’audit sur des machines déjà passées sous Windows 11, mais vérifiez sa requête sur quelques postes avant de généraliser, comme pour toute GPO ciblée.
Deux pièges à traiter avant le déploiement
Le certificat de signature. Le script est signé, mais le certificat Microsoft utilisé est expiré depuis septembre 2022. La conséquence pratique dépend de votre politique d’exécution PowerShell : selon qu’elle exige ou non une signature valide, le script peut être refusé par les postes. Anticipez ce point avant de lancer la GPO, par exemple en validant sur un poste de test que le script s’exécute avec la politique réellement appliquée à votre parc, plutôt que de le découvrir sur des centaines de machines.
Le test Secure Boot. La méthode native du script pose un problème connu. IT-Connect recommande de modifier ce test pour lire l’état de Secure Boot via le Registre Windows. Sans cet ajustement, le résultat peut être faussé et vous classeriez à tort des postes en échec. Comparez sur quelques machines le résultat du script modifié avec l’état réel affiché dans le BIOS/UEFI ou dans les informations système.
Lire le rapport : corriger ou remplacer
Le rapport vaut par la raison associée à chaque échec. On peut classer les postes en trois groupes.
Migrables. Tous les tests passent. Ces machines entrent dans le planning de migration.
À corriger. Le matériel est capable, mais une option est désactivée. Un poste dont le TPM 2.0 est présent mais désactivé dans le BIOS/UEFI échoue au test, et l’installation via l’outil officiel est bloquée tant que l’option n’est pas activée. Même logique pour Secure Boot. Ces postes ne se remplacent pas : une intervention dans le BIOS/UEFI suffit, éventuellement après une mise à jour du firmware selon le modèle. Une fois la correction faite, relancez le script pour vérifier que le résultat a changé.
À remplacer. Le blocage est matériel, typiquement une génération de processeur antérieure aux seuils cités plus haut. Aucun réglage n’y change rien. La RAM ou le stockage insuffisants entrent aussi dans cette catégorie dès lors qu’une extension n’est pas envisageable sur le modèle concerné, ce qui dépend de la machine et se vérifie dans sa documentation.
Ce tri a un effet budgétaire direct : le deuxième groupe se traite en heures de technicien, le troisième en commande de matériel. Mieux vaut chiffrer les deux séparément. Pour les postes qui résistent à toute analyse, un diagnostic plus large s’appuie sur des outils de dépannage et de maintenance Windows adaptés au symptôme observé.
Ce que l’audit ne dit pas
Un poste déclaré compatible l’est au regard des critères matériels et système testés par le script. Cela ne garantit pas que vos logiciels métier, vos pilotes d’imprimantes ou vos périphériques spécifiques fonctionneront sous Windows 11. Ce volet se valide à part, sur un échantillon représentatif de postes, avant de dérouler la migration. En cas de comportement anormal après bascule, un diagnostic d’écran noir sous Windows fait partie des cas courants à anticiper côté support.