Comment nous étudions Windows

Dans la section « Recherches Windows », nous vérifions des affirmations techniques précises. Dans chaque article, nous expliquons ce qui a été vérifié, dans quelles conditions et sur quels systèmes le résultat s’applique.

La présence d’un paramètre, son influence sur le fonctionnement du système et le gain de performance exigent des preuves distinctes.

Ce qui est considéré comme une preuve

Nous utilisons plusieurs types indépendants de preuves :

1. Documentation primaire. Documents officiels Microsoft, spécifications et documentation du fabricant du matériel ou de l’application.
2. Observation statique. Indices d’implémentation dans une version précise du composant. Une telle observation est limitée à la build étudiée et ne prouve pas à elle seule l’exécution du chemin pendant le fonctionnement.
3. Observation dynamique. Événements système, état des composants et traces obtenus dans le scénario décrit.
4. Mesure contrôlée. Comparaison d’une métrique choisie à l’avance lors d’un changement connu et d’un retour d’état vérifié.
5. Reproduction. Répétition du résultat dans un lancement indépendant, sur un autre système ou une autre build.

Les méthodes internes d’automatisation de la collecte et du traitement ne sont pas publiées. Cela ne change pas l’exigence de divulguer la question vérifiée, la configuration, les métriques, le nombre de passages et les limites.

Statuts des matériaux

Statut	Signification
Documenté	Comportement décrit dans une source publique primaire.
Observé	Événement ou état détecté dans l’environnement indiqué.
Mesuré	Différence numérique obtenue selon la méthodologie décrite.
Reproduit	Résultat répété indépendamment.
Non reproduit	Effet déclaré non détecté dans les conditions indiquées.
Données insuffisantes	La méthodologie ou l’échantillon ne permettent pas de conclure.

Le statut concerne une affirmation distincte, et non automatiquement l’article entier. Nous n’utilisons pas de pourcentage de confiance arbitraire et ne qualifions pas un résultat de universellement prouvé sans vérification sur d’autres systèmes.

Comment l’expérience est construite

Avant la mesure, sont fixés :

• une question vérifiée ;
• une variable indépendante ;
• la métrique principale et son unité ;
• Windows build, matériel significatif, pilotes et versions des applications ;
• un seuil pratiquement significatif ;
• la méthode de retour à l’état initial.

Nous comparons l’état initial et l’état modifié, puis vérifions le retour. Lorsque c’est possible, nous alternons l’ordre des passages appariés. Nous contrôlons la montée en température, l’alimentation, les températures et la charge de fond ; si cela est impossible, nous indiquons la limite.

Les intervalles séparés d’une même trace montrent des changements dans le temps, mais ne sont pas considérés comme des répétitions indépendantes. Le résultat d’une machine virtuelle ne peut pas être automatiquement transposé à un ordinateur physique. Pour conclure sur tous les appareils d’une même classe, vérifier un seul appareil ne suffit pas.

Banc physique click-to-photon

Pour les recherches sur les jeux, nous utilisons notre propre banc matériel. Il mesure physiquement la latence complète depuis le signal électrique du bouton de la souris jusqu’au changement de luminosité du pixel à l’écran, sans estimation logicielle de cet intervalle.

Le trajet principal est organisé ainsi :

1. Un fil est soudé à la ligne du bouton gauche de la Logitech G PRO X SUPERLIGHT de première génération. Le front électrique déclenche le timer de l’Arduino Uno.
2. Le même clic passe par le contrôleur de la souris, USB, Windows, le jeu, la file de rendu, le GPU et le moniteur.
3. Un capteur photo fixé sur l’écran arrête le timer lorsque la luminosité de la zone de test franchit un seuil choisi à l’avance.
4. Un résultat contient l’intervalle click-to-photon complet en millisecondes.

Un tel départ inclut intentionnellement le traitement par le contrôleur de la souris et son click debounce, mais n’inclut pas la course mécanique du bouton jusqu’à la fermeture du contact. Nous ne soustrayons pas la latence de la souris de la valeur finale. Dans la méthodologie actuelle de mesures indépendantes de RTINGS pour la G PRO X SUPERLIGHT, il est indiqué 2.5 ms par câble et 3.1 ms via receiver. La faible click latency mesurée fait de cette souris une partie stable appropriée du banc, mais ne transforme pas le résultat en latence pure de Windows ou du jeu.

Un microcontrôleur HID séparé au format Arduino Nano peut envoyer des clics à Windows automatiquement. Cette voie est utilisée lorsqu’il faut supprimer les différences de pression manuelle et répéter le signal d’entrée à un rythme contrôlé. Elle répond à une autre question et n’est pas mélangée avec les séries partant de la ligne physique du bouton de la souris.

Dans CS2, une carte workshop BXLAT est utilisée, où le clic provoque un changement prévisible de la zone de test. Un scénario visuel analogue est appliqué dans Valorant. La position du capteur photo, la résolution, la fréquence du moniteur, la limite FPS, le mode display scaling, presentation mode et le seuil de lumière sont fixés pour toute la série comparée.

Le standard actuel exige au moins 300 clics valides par état. Dans les nouvelles séries, nous conservons la moyenne, l’écart-type, le minimum, le maximum, les percentiles, y compris P90, et la distribution pour construire les graphiques. Les déclenchements erronés, les dépassements du temps d’attente et les valeurs hors de la plage établie à l’avance sont marqués et pris en compte lors de la vérification de la validité de la série.

Les recherches sur ce banc sont menées depuis plusieurs années, et le format de stockage a changé pendant cette période. Dans le tableau public des mesures historiques, il y a des séries de 300 clics et des séries plus anciennes de 100. Pour une partie des anciens tests, seuls AVG, STDDEV, MIN et MAX sont conservés ; les P90 ou graphiques manquants ne sont pas reconstruits à partir des agrégats et sont explicitement marqués comme indisponibles. Les nouvelles séries seront publiées avec des statistiques étendues.

Ce qui est publié dans le résultat

L’article contient :

• une réponse courte ;
• une affirmation vérifiable ;
• le domaine de recherche ;
• la méthodologie et le nombre de traces indépendantes ;
• les valeurs des métriques et la dispersion ;
• les conclusions confirmées et non confirmées ;
• les métriques exclues ou contaminées ;
• les limites ;
• une recommandation pratique sans garantie d’un résultat identique ;
• la confirmation du retour à l’état initial ;
• les sources publiques primaires et la date de vérification.

Si le résultat n’a pas confirmé une recommandation populaire ou une fonction de BoosterX, il peut tout de même être publié. La présence d’un réglage dans le produit n’est pas une preuve de son efficacité.

Comment vérifier soi-même

Une partie significative des observations dynamiques de nos recherches est reproduite avec des outils publics : Sysinternals ProcMon pour les traces système et WinDbg avec les symboles publics Microsoft. Le chemin de vérification de base se présente ainsi.

1. Lecture du paramètre — ProcMon. Ouvrez Options → Configure Symbols et indiquez le serveur public de symboles Microsoft, afin que les piles affichent les noms des modules et des fonctions. Ajoutez ensuite un filtre Path contains — par exemple SystemResponsiveness de HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. D’après les événements de lecture, on voit si la valeur est lue, quand et par quel processus.
2. Qui lit — pile d’appel. Un double-clic sur l’événement ouvre ses propriétés ; dans l’onglet Stack, la chaîne des modules est affichée — c’est précisément le « lecteur » du paramètre. Par exemple, une chaîne de user32.dll vers win32kfull.sys signifie que le sous-système Win32k est responsable de la valeur.
3. Comportement au runtime — WinDbg. Avec les symboles publics Microsoft, on peut placer un point d’arrêt sur une fonction de la pile et observer comment la valeur lue est appliquée.
4. Tests synthétiques. Modifiez la valeur et mesurez le comportement observé. Par exemple, les intervalles d’entrée de la souris sont mesurés par des testeurs publics de fréquence d’interrogation.

Frontière honnête. L’analyse statique des binaires et les traces complètes ne sont pas publiées dans les articles. Le chemin ci-dessus reproduit la partie dynamique de nos observations, mais ne remplace pas l’analyse statique — ses conclusions concernent la build étudiée.

Limites de la mesure de la latence

La latence logicielle, la profondeur de file, la période du moteur audio, le temps de planification du thread et la latence physique complète décrivent des grandeurs différentes. Par exemple, la file XAudio2 ne détermine pas tout l’intervalle entre l’action de l’utilisateur et le son sortant du haut-parleur. Pour le mesurer, un équipement externe est nécessaire.

De même, le temps CPU d’un processus séparé n’est pas égal à l’influence globale sur les FPS, le frametime, la consommation d’énergie ou la réactivité du système. De telles conclusions sont vérifiées par des métriques distinctes.

Protection des données

Les ETL, PML, journaux d’événements, dumps mémoire et exports du registre d’origine ne sont pas publiés par défaut. Les traces système peuvent contenir des noms d’utilisateurs, des chemins, des lignes de commande, des adresses réseau et d’autres données sensibles. Microsoft le signale spécifiquement dans les conditions Sysinternals.

Seuls des tableaux sélectionnés manuellement et anonymisés sont publiés sur le site. Nous supprimons les identifiants uniques des appareils et des installations, les chemins utilisateur, les données de comptes, les identifiants réseau, les données de connexion et les informations sur les processus non liés à la recherche.

Correction des conclusions

Windows, les pilotes et les applications changent. Chaque article reçoit une date de dernière vérification et un domaine d’applicabilité. Si une nouvelle mesure contredit une ancienne conclusion, l’article est mis à jour avec l’explication de la cause. L’ancien résultat n’est pas automatiquement transposé à une nouvelle build.

Indépendance et marques

Les recherches sont publiées par l’équipe BoosterX et peuvent concerner des fonctions du produit. Ce conflit d’intérêts possible est pris en compte par le fait que la méthodologie, les valeurs mesurées, les limites et les résultats négatifs sont séparés de la recommandation produit.

BoosterX Wiki est une publication indépendante et n’est pas liée, autorisée, sponsorisée ou approuvée par Microsoft Corporation. Les noms Microsoft et Windows sont utilisés uniquement pour décrire précisément l’objet de la recherche. Plus de détails : Microsoft Trademark and Brand Guidelines.

Historique des modifications

• 2026-08-24: méthodologie publiée.
• 2026-09-20: ajout de la section « Comment vérifier soi-même » ; lien vers la source des données de la souris corrigé.

Dernière vérification de la méthodologie : 2026-09-20.