Test placebo : les réglages fins du registre réduisent-ils l'activité en arrière-plan

Réponse courte

Non. Les 17 paramètres de registre « fins » que les guides d’optimisation présentent comme un moyen de museler l’activité en arrière-plan n’ont pas réduit le fond total : les opérations de registre et de fichiers sont restées dans les limites de la dispersion naturelle des heures propres. Un effet ponctuel n’est prouvé que pour deux mécanismes : la désactivation de LLMNR a mis à zéro les requêtes réseau correspondantes, et le groupe de télémétrie a arrêté l’interrogation périodique de la configuration DiagTrack (−98–99,8 %). Trois autres paramètres ont été lus, mais n’ont produit aucun effet observable.

Statut : mesuré lors d’une seule passe A/B avec quatre heures de contrôle sur Windows 11 26H2 dans une machine virtuelle. Le verdict « aucun effet » concerne le fond observé au repos ; pour les paramètres à longue période de fonctionnement, la fenêtre de mesure était insuffisante.

Affirmation à vérifier

Une affirmation générale : l’application d’un ensemble connu de 17 paramètres de registre réduit sensiblement l’activité en arrière-plan d’un Windows au repos. Plus 17 affirmations particulières : chaque paramètre modifie-t-il le comportement observé.

Périmètre de l’étude

• Windows 11 Pro, build 26300.9457 (26H2), machine virtuelle, système stabilisé ;
• 17 paramètres de registre parmi les plus souvent recommandés : télémétrie, diagnostic, réseau, compatibilité et recherche ;
• fenêtre avec paramètres : 9,2 minutes après 3 minutes de stabilisation ; fenêtre propre de contrôle de même durée plus quatre heures de contrôle supplémentaires du même lancement ;
• métriques : lancements de processus et de threads, opérations de registre, de fichiers et de réseau via le traçage du noyau ;
• tous les paramètres appliqués simultanément et restaurés immédiatement après la mesure.

Non vérifiés : la charge scénarisée (installation, mises à jour, travail des applications), les paramètres dont la période de fonctionnement dépasse la fenêtre, le matériel physique et d’autres builds.

Méthodologie

A/B strict sur un seul cycle de démarrage : fenêtre avec paramètres appliqués contre fenêtre propre de durée égale, plus quatre heures propres de contrôle pour évaluer la dispersion naturelle. Les événements de traçage du noyau ont été regroupés par processus ; le bruit de surveillance associé a été exclu. Les débits ont été normalisés à la minute ; pour résister aux pics, les médianes des sommes par minute sans la première minute ont été comparées.

Résultats

Fond total : parité

Métrique	Avec paramètres	Fenêtre propre	Heures propres (dispersion)	Verdict
Lancements de processus/min	2549	2601	2601	parité
Opérations de registre/min	14235	14780	14394–18951	dans la dispersion
Opérations de fichiers/min	3098	4472	3251–4472	dans la dispersion

La variabilité naturelle des heures de fond (jusqu’à 28 % pour le registre) dépasse tout effet de l’ensemble. Les deltas bruts « −13 % registre » et « −53 % fichiers » s’expliquent par un pic de la première minute d’observation, et non par les paramètres.

Ce qui a réellement changé

Mécanisme	Résultat	Preuve
Désactivation de LLMNR (résolution de noms multicast)	requêtes LLMNR : 17,8–20,7 en 10 minutes dans toutes les heures propres → 0	probabilité de hasard inférieure à 1e-7 ; la requête mDNS appariée continuait d’arriver
Groupe de télémétrie (AllowTelemetry ×2 + interdiction du téléversement DiagTrack)	activité de l’hôte de télémétrie : 131–1950 opérations de registre/min → 3	l’interrogation périodique de la configuration de télémétrie s’est arrêtée immédiatement

Le groupe de télémétrie a été appliqué avec trois paramètres simultanément, il est donc impossible de séparer la contribution de chacun d’eux dans cette expérience.

Ce qui est réfuté

Paramètre	Attendu	En réalité
Désactivation de mDNS	arrêt des requêtes mDNS	fréquence inchangée : 35,9 en 10 minutes contre 29,6–35,6 dans les heures propres ; la valeur est lue par le service
Désactivation de NetBIOS over TCP/IP	arrêt des requêtes NetBT	cadence identique : 16,8 contre 16,1–16,7 en 10 minutes
Désactivation de l’auto-DoH	baisse des requêtes DNS	sans changement ; sur ce système, l’auto-DoH n’était de toute façon pas actif

Ce qui n’a pas été vérifié par cette fenêtre

Dix paramètres sont restés sans verdict : quatre diagnostics WDI n’ont pas été lus dans la fenêtre, leurs intervalles de fonctionnement dépassent 9 minutes ou ne se manifestent qu’en charge scénarisée ; les limitations de traçage de la recherche influent sur le canal de recherche lui-même, qui n’était pas inclus dans la capture ; les paramètres de compatibilité et USB n’avaient aucune activité au repos à vérifier.

Fait secondaire important : l’application des paramètres dans les branches de stratégie a elle-même réveillé la mise à jour des stratégies de groupe et le service d’applications — un « coût d’application » ponctuel qui, dans une fenêtre courte, ressemble à une hausse d’activité.

Ce qui est confirmé

• Mesuré : aucune baisse totale des opérations en arrière-plan ; les débits avec paramètres se situent dans la dispersion des heures propres.
• Mesuré : la désactivation de LLMNR arrête complètement les requêtes LLMNR, sans toucher à mDNS ni à NetBIOS.
• Mesuré : le groupe de télémétrie arrête l’interrogation périodique de la configuration DiagTrack (−98–99,8 % d’activité de l’hôte).
• Observé : les paramètres mDNS et NetBIOS sont lus par le service, mais ne produisent aucun effet observable.

Ce qui n’est pas confirmé

• Les effets des paramètres WDI, compatibilité, USB et limitations de recherche : la fenêtre ou les canaux d’observation ne convenaient pas.
• La contribution de chaque paramètre de télémétrie pris séparément.
• Le comportement sur d’autres builds et sur du matériel physique.
• Tout effet sous charge : seul le repos a été mesuré.

Limites

Une seule fenêtre par état, sans randomisation de l’ordre. La variabilité de fond de Windows est grande, c’est pourquoi la conclusion de parité s’appuie sur quatre heures de contrôle et non sur une seule paire de fenêtres. Une partie des journaux du planificateur a cessé d’écrire des événements pendant la fenêtre avec paramètres ; les tâches planifiées déclenchées à ce moment sont visibles par les processus, mais pas par le journal. Les verdicts ponctuels (LLMNR, télémétrie) sont robustes : l’effet est présent dans toutes les heures de contrôle et tombe à zéro dans la fenêtre avec paramètres.

Conclusion pratique

La distinction entre « le paramètre est lu » et « le paramètre contrôle le comportement » est l’essentiel. Sur les 17 réglages vérifiés, seuls deux groupes modifient réellement le comportement observé, et tous deux ont leurs propres points de contrôle dédiés : dans BoosterX, LLMNR est couvert par le réglage « Résolution des noms locaux », la télémétrie par « Télémétrie dans la stratégie de collecte de données » avec les « Enregistreurs automatiques ETW en arrière-plan ». Le reste du fond d’un Windows au repos est créé par Defender, WMI, les vérifications de licence et le Store — les paramètres de registre « fins » de cet ensemble ne les musèlent pas.

Articles liés : l’étude « Repos silencieux » montre ce qui réduit réellement le fond ; « Bureau contre écran de connexion » explique de quoi se compose le bruit résiduel.

Restauration de l’état

Les 17 valeurs ont été restaurées immédiatement après l’arrêt de la mesure ; le retour réussi est consigné par des instantanés. Le système n’a pas été redémarré avant la restauration.

Sources et limites

Les mesures ont été réalisées par BoosterX Research sur la machine virtuelle décrite. L’étude appartient au développeur de BoosterX, le développeur a donc un intérêt direct au résultat ; la méthodologie et les limites sont décrites ci-dessus, les conclusions peuvent être vérifiées à partir de la méthodologie ouverte.

• Microsoft : LLMNR et le paramètre EnableMulticast, vérifié le 2026-09-22.
• Microsoft : Configure Windows diagnostic data, vérifié le 2026-09-22.

Dernière vérification : 2026-09-22.