Contact et aide
Des tests reproductibles commencent par un environnement de test proprement documenté. Sur les systèmes Windows, la simple mention « Windows 11 » dans un rapport de bug ne suffit généralement pas. La version du build, le mode du firmware, les fonctions de sécurité, le pilote graphique et le matériel peuvent influencer l’apparition d’un bug et sa reproductibilité sur un second appareil. Ce guide montre comment relever les principales données techniques d’un appareil de test Windows avec les seuls outils intégrés – sans logiciel de diagnostic supplémentaire.
Quelles informations doivent figurer dans la documentation d’un appareil de test Windows ?
Pour de nombreux scénarios de QA et de support, six groupes d’informations sont particulièrement pertinents : système d’exploitation et build, processeur et mémoire vive, mode du firmware, statut du TPM, statut du Secure Boot, ainsi que les données graphiques et de pilote. Selon l’application, s’y ajoutent la résolution d’écran, la capacité de stockage disponible, la langue, le fuseau horaire et les composants d’exécution installés.
L’objectif n’est pas de collecter le plus de données possible. Le but est une empreinte système petite et cohérente, relevée de la même manière sur chaque appareil de test. Cela permet de repérer beaucoup plus rapidement les différences entre un environnement fonctionnel et un environnement défaillant.
1. Relever la version et le build de Windows avec winver
Appuyez sur touche Windows + R, saisissez winver et validez. La fenêtre affiche la version de Windows installée et le build du système d’exploitation. Les deux valeurs doivent être reprises dans un rapport de bug.
L’édition seule est trop imprécise. Deux appareils peuvent tous deux utiliser Windows 11 mais avoir des builds ou des niveaux de correctifs différents. Un comportement apparaissant après une mise à jour ne peut donc être étudié utilement que si le build est documenté.
Notez néanmoins toujours aussi l’édition. Le fait qu’un appareil de test fonctionne sous Windows 11 Home, Windows 11 Pro ou Windows 11 Enterprise détermine si des fonctions comme BitLocker, les stratégies de groupe ou Hyper-V sont même disponibles – et influence donc aussi le comportement lors des tests.
2. Relever les données système centrales avec msinfo32
Ouvrez la commande msinfo32 via touche Windows + R. Les informations système regroupent de nombreuses données utiles pour les tests et l’analyse des erreurs. Sont particulièrement pertinents :
- Nom et version du système d’exploitation
- Fabricant et modèle du système
- Type de système
- Processeur
- Mémoire physique installée
- Version et date du BIOS
- Mode du BIOS
- Statut du « démarrage sécurisé » (Secure Boot)
Pour des processus de QA reproductibles, il est recommandé de consigner ces champs dans un modèle fixe. Cela évite des rapports de bug où un testeur documente la version du BIOS et un autre uniquement l’édition de Windows.
3. Vérifier l’UEFI et le Secure Boot
Dans msinfo32, le champ relatif au mode du BIOS indique si l’appareil a démarré en mode UEFI ou dans un ancien mode Legacy. Le champ relatif au démarrage sécurisé indique si le Secure Boot est actif. Microsoft cite la capacité UEFI et Secure Boot comme faisant partie de la configuration requise pour Windows 11.
Pour la recherche d’erreurs, cette information est utile même lorsque l’application testée n’utilise pas directement le Secure Boot. Des différences dans la configuration du firmware et l’état de sécurité peuvent expliquer pourquoi le comportement d’installation, de pilote ou de périphérique diffère entre deux machines par ailleurs équipées de façon similaire.
Ne modifiez pas les paramètres du firmware pour un simple test sans en comprendre les conséquences. Si une modification est nécessaire, documentez l’état avant et après l’ajustement et suivez les instructions du fabricant de l’appareil ou de la carte mère.
4. Contrôler la version du TPM avec tpm.msc
Appuyez sur touche Windows + R, saisissez tpm.msc et ouvrez la gestion du TPM. Si le module de plateforme sécurisée (Trusted Platform Module) est disponible et opérationnel, vous y trouverez les informations du fabricant et la version de la spécification. Pour Windows 11, le TPM 2.0 est une exigence minimale.
Si Windows n’affiche aucun TPM compatible, cela ne signifie pas nécessairement que le matériel est absent. Microsoft indique que le TPM peut être désactivé dans le firmware UEFI sur certains appareils. Selon la plateforme, il peut apparaître sous des noms tels qu’Intel PTT ou AMD fTPM.
Pour la documentation des tests, trois valeurs suffisent en général : TPM présent : oui/non, version de la spécification et statut. Les clés sensibles ou les données d’identité n’ont pas leur place dans un rapport de bug ordinaire.
5. Documenter DirectX et le pilote graphique avec dxdiag
Ouvrez la commande dxdiag via touche Windows + R. L’outil de diagnostic DirectX affiche, en plus des données système, des informations sur l’unité graphique et le pilote. L’onglet Affichage montre notamment le nom du GPU, la version du pilote, la date du pilote, la prise en charge de DirectX et le mode d’affichage.
Ces informations sont particulièrement importantes en cas de défauts d’affichage, de plantages liés à l’accélération matérielle, de problèmes avec plusieurs écrans ou de différences entre machines de test virtuelles et physiques. Microsoft indique, pour Windows 11, une unité graphique compatible DirectX 12 avec un pilote WDDM 2.0 comme exigence minimale.
6. Relever le CPU, la RAM et le type de système de façon uniforme
Vous trouvez également le processeur, la RAM installée et le type de système dans msinfo32 ou sous Paramètres → Système → Informations système. Pour le CPU, relevez si possible la désignation exacte du modèle plutôt que simplement « Intel » ou « AMD ». Pour la mémoire vive, la capacité installée suffit tant qu’aucun problème de mémoire n’est étudié.
Pour les tests de performance ou de charge, il convient de noter en plus si d’autres processus gourmands en ressources s’exécutent en parallèle. Un résultat de test sans contexte sur l’utilisation du matériel peut facilement être mal interprété.
7. Vérifier l’espace de stockage libre
Un appareil peut satisfaire aux exigences formelles de Windows tout en ayant trop peu d’espace libre pour une mise à jour, des données de test temporaires ou une application plus volumineuse. En cas d’échec d’installation ou de mise à jour, documentez donc non seulement la taille du disque, mais aussi l’espace libre disponible avant le test.
Selon Microsoft, Windows 11 nécessite un support de stockage d’au moins 64 Go. Pour des tests d’application reproductibles, c’est toutefois l’espace libre réellement disponible qui constitue l’indicateur le plus pertinent.
Empreinte système recommandée pour les rapports de bug
Un modèle compact peut par exemple se présenter ainsi :
OS : Windows 11 [Édition]
Version/Build : [winver]
Modèle de l’appareil : [msinfo32]
CPU : [modèle exact]
RAM : [Go]
Mode BIOS : UEFI/Legacy
Secure Boot : Activé/Désactivé/Non pris en charge
TPM : présent, version [x.x]
GPU : [modèle]
Pilote graphique : [version + date]
DirectX/WDDM : [dxdiag]
Affichage : [résolution / mise à l’échelle]
Espace libre : [Go]
Date/heure du test : [date/heure]Lors d’une comparaison entre deux machines, le même modèle doit être utilisé pour les deux systèmes. Les différences deviennent ainsi immédiatement visibles, sans que les développeurs aient à parcourir plusieurs captures d’écran.
Quelles données ne doivent pas figurer dans des rapports de bug publics ?
Le diagnostic système peut contenir des informations qui ne sont pas nécessaires à l’analyse technique. Ne publiez donc aucun numéro de série, clé de produit, donnée de compte, identifiant d’appareil, donnée réseau privée ou autre information personnelle ou confidentielle. Vérifiez les rapports de diagnostic exportés avant de les partager.
Dans les entreprises, des règles internes supplémentaires s’appliquent aux journaux et aux données de télémétrie. Une bonne empreinte système ne contient que les données contribuant à la reproduction du bug.
Pourquoi cette documentation améliore la reproductibilité
Un bug qui n’apparaît que sur un seul appareil de test n’est pas automatiquement aléatoire. L’environnement diffère souvent sur un détail : un autre build Windows, un autre pilote graphique, une configuration de firmware différente, moins d’espace libre ou un matériel différent. Lorsque ces différences sont relevées de façon structurée, un « ça marche chez moi » peut se transformer en hypothèse vérifiable.
Cette méthode est particulièrement précieuse pour les tests de régression. Enregistrez l’empreinte système avec chaque exécution de test. Si le résultat change après une mise à jour de Windows, du firmware ou d’un pilote, il devient possible de retracer quelle variable d’environnement a changé entre les exécutions.
Conclusion
Une documentation de test Windows fiable ne nécessite pas d’outils tiers volumineux. Avec winver, msinfo32, tpm.msc et dxdiag, les principales caractéristiques système peuvent être relevées de façon cohérente. Ce qui compte n’est pas la quantité de données mais un modèle reproductible, utilisé de façon identique sur tous les appareils de test.
