Repos au repos : activité de fond de Windows avant et après optimisation
Sur cette page
Réponse courte
Section intitulée « Réponse courte »La désactivation des composants d’arrière-plan de Windows rend effectivement l’inactivité plus silencieuse : dans deux séries de mesures indépendantes, le nombre de processus a chuté de 49–56 %, l’occupation du CPU au repos — de 17–67 %, et le volume d’engagements mémoire (commit) — de 52 % dans la seconde série. Mais sous pleine charge CPU, la bande passante n’a augmenté que de 0,2–0,5 %. L’« inactivité silencieuse » est une réduction confirmée du travail d’arrière-plan et de la concurrence pour les ressources, et non un gain de FPS : l’effet final en jeu n’a pas été mesuré dans cette étude.
Statut : le sens de l’effet est reproduit dans deux séries indépendantes sur une même build de Windows 11 dans une machine virtuelle. Les valeurs diffèrent entre les séries parce que le travail d’arrière-plan de Windows arrive par pics : dans une fenêtre avec analyse de Microsoft Defender, l’écart d’occupation du CPU atteint −67 %, dans une fenêtre déjà silencieuse — −17 %.
Affirmation vérifiable
Section intitulée « Affirmation vérifiable »Nous avons vérifié quatre affirmations :
- La désactivation des composants d’arrière-plan réduit sensiblement l’activité du système au repos.
- Elle réduit sensiblement l’activité dans les premières minutes après le démarrage.
- Elle réduit sensiblement la consommation de mémoire.
- Elle apporte un gain de performance mesurable sous pleine charge CPU.
Périmètre de l’étude
Section intitulée « Périmètre de l’étude »- Windows 11 Pro, build 26300.9457 (26H2) ;
- machine virtuelle : 4 vCPU, 8 Go de RAM, virtualisation VMware ;
- deux états d’une même installation : l’état initial (« avant ») et après application du profil d’optimisation BoosterX (build en vigueur aux dates des mesures) ;
- deux séries de mesures indépendantes : 2026-09-18 et 2026-09-19 ; les états ont été comparés sur des copies de disque indépendantes, afin que les mesures n’influencent pas les unes sur les autres ;
- phases : 5 minutes après le démarrage, 5 minutes de stabilisation, 5 minutes d’inactivité ;
- charges synthétiques courtes : 1, 4 et 8 threads, charge mémoire, charge cadencée et mélanges de priorités.
Les mesures n’incluaient pas de jeux réels, de charge GPU, de matériel physique ni de fenêtres longues (heures et jours).
Méthodologie
Section intitulée « Méthodologie »Le protocole correspond à « Comment nous étudions Windows » :
- chaque phase a été enregistrée par une trace ETW (Windows Performance Recorder, profils légers CPU, disque, fichiers et réseau) et par des compteurs de performance avec un intervalle de 5 secondes (système) et de 15 secondes (par processus) ;
- la phase « après le démarrage » était lancée par un redémarrage contrôlé et activée à un uptime d’environ une minute ;
- dans chaque trace, le nombre d’événements perdus a été vérifié — dans toutes les fenêtres citées, il est égal à zéro ;
- la moyenne a été calculée uniquement sur des intervalles complets de cinq secondes à l’intérieur des limites de la phase (59 intervalles par phase) ;
- dans la série 2, le premier passage « avant » a été exclu en raison de la mise en veille de la machine virtuelle ; la répétition a été utilisée ;
- les essais de charge ont été exécutés deux fois, les médianes sont indiquées ; l’occupation du CPU est normalisée sur quatre vCPU.
« Avant » et « après » sont des états d’une même installation de Windows : « après » est obtenu par application du profil d’optimisation, « avant » est l’état initial. L’ensemble des réglages a été modifié dans son ensemble, c’est pourquoi la contribution isolée d’une désactivation particulière n’a pas été évaluée.
Résultats
Section intitulée « Résultats »Inactivité
Section intitulée « Inactivité »Série 1 (2026-09-18) — inactivité établie sans maintenance active :
| Métrique | Avant | Après | Variation |
|---|---|---|---|
| Occupation du CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Commutations de contexte, /s | 469 | 381 | −19 % |
| Processus (moyenne) | 134,9 | 69,3 | −49 % |
| Threads (moyenne) | 1 444,6 | 738,7 | −49 % |
| CPU total de tous les processus, % | 1,22 | 1,06 | −13 % |
| Mémoire disponible, Mo | 5 490 | 6 518 | +1 028 |
| Lecture disque, Ko/s | 22,6 | 24,4 | +8 % |
| Écriture disque, Ko/s | 311,3 | 262,1 | −16 % |
| Réseau (réception), Ko/s | 132,6 | 2,2 | −98 % |
| Réseau (envoi), Ko/s | 43,2 | 4,7 | −89 % |
Série 2 (2026-09-19) — même fenêtre d’inactivité, mais dans l’état « avant », une analyse d’arrière-plan de Microsoft Defender s’exécutait :
| Métrique | Avant | Après | Variation |
|---|---|---|---|
| Occupation du CPU, % | 33,37 | 11,03 | −67 % |
| Commutations de contexte, /s | 3 737 | 291 | −92 % |
| Processus (moyenne) | 142,3 | 61,9 | −56 % |
| Threads (moyenne) | 1 494,7 | 637,1 | −57 % |
| Mémoire disponible, Mo | 5 174 | 6 653 | +1 479 |
| Mémoire physique occupée, Mo | 3 017 | 1 538 | −49 % |
| Engagements mémoire (commit), Mo | 2 617 | 1 249 | −52 % |
| Nonpaged pool, Mo | 298,2 | 212,9 | −29 % |
| Paged pool, Mo | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Lecture disque, Mo/s | 7,42 | 0,01 | −99,9 % |
| Écriture disque, Mo/s | 4,57 | 0,23 | −95,0 % |
Le réseau au repos de la série 2 était presque inexistant dans les deux états (dizaines d’octets par seconde), c’est pourquoi les lignes réseau ne sont pas indiquées pour elle. La différence entre les séries n’est pas une contradiction, mais une propriété de l’arrière-plan lui-même : lorsque Windows effectue de la maintenance, la désactivation des composants d’arrière-plan fait économiser davantage ; lorsque la fenêtre est déjà silencieuse — moins.
Premières minutes après le démarrage
Section intitulée « Premières minutes après le démarrage »| Métrique | Série 1 (avant → après) | Série 2 (avant → après) |
|---|---|---|
| Occupation du CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Commutations de contexte, /s | 1 114 → 600 | 1 257 → 393 |
| Processus | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Mémoire physique occupée, Mo | — | 2 821 → 1 581 |
| Mémoire disponible, Mo | — | 5 370 → 6 610 |
| Lecture disque, Ko/s | — | 826 → 433 |
| Écriture disque, Ko/s | 634 → 418 | 709 → 298 |
| Réseau (réception), Ko/s | — | 1,15 → ~0 |
Le tiret signifie que dans cette série, la métrique n’a pas été enregistrée pour la phase.
Composition et mémoire
Section intitulée « Composition et mémoire »Instantané de l’inventaire au repos (série 1) :
| Avant | Après | |
|---|---|---|
| Processus | 136 | 70 |
| Threads | 1 679 | 842 |
| Working set total, Mo | 3 841 | 1 868 |
| Private bytes totaux, Mo | 1 524 | 660 |
Principaux consommateurs de mémoire avant optimisation : le processus antivirus MsMpEng.exe (257 Mo), explorer.exe (213 Mo), StartMenuExperienceHost (144 Mo), msedge.exe (133 Mo), SearchHost.exe (122 Mo). Après optimisation, la liste est menée par explorer.exe (170 Mo), msedgewebview2 (119 Mo), SearchHost.exe (115 Mo) et StartMenuExperienceHost (106 Mo).
La mémoire disponible a augmenté de 1,0–1,5 Go, et le volume d’engagements (commit) a diminué de 52 %. Ce qui, parmi cela, peut réellement être « libéré » et pourquoi la somme des working sets des processus n’est pas la même chose que la mémoire libre, est analysé dans « Combien de mémoire peut-on réellement libérer dans Windows ».
Sous pleine charge
Section intitulée « Sous pleine charge »Essais synthétiques courts (série 2, médianes de deux répétitions) :
| Scénario | Variation de la bande passante | Occupation du CPU : avant / après |
|---|---|---|
| Un thread | +5,4 % | 21,9 / 22,6 % |
| Quatre threads (pleine) | +0,19 % | 88,9 / 89,4 % |
| Huit threads (pleine) | +0,50 % | 88,9 / 88,8 % |
| Charge mémoire | +11,2 % | 84,8 / 87,5 % |
| Cadencée (pauses de 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Priorités mixtes | +8,5 % | 21,2 / 22,5 % |
| Priorité d’arrière-plan | +77,1 % | 38,8 / 65,2 % |
Sous pleine charge de quatre threads, le processus utile a reçu environ 89 % de la capacité de quatre vCPU, avant comme après optimisation. Les ~11 % restants dans la machine virtuelle ne peuvent pas être déclarés « bruit Windows » éliminable : l’ordonnancement de l’hyperviseur n’est pas visible depuis la trace invitée. Les threads de travail étaient répartis uniformément (écart du volume de travail entre eux — 0,994–0,997), aucune famine n’a été observée, et la file d’attente CPU au repos après optimisation est pratiquement vide.
Où va l’arrière-plan
Section intitulée « Où va l’arrière-plan »Sources mesurées de l’activité d’arrière-plan dans l’état « avant » :
- l’analyse antivirus — principale source dans la fenêtre de la série 2 : le processus
MsMpEng.exea consommé 212 secondes CPU sur une fenêtre d’inactivité de cinq minutes ; - dans l’état initial, le service de recherche, le service SysMain, la télémétrie, le gestionnaire d’impression et d’autres composants fonctionnaient — le profil d’optimisation met à l’état désactivé environ 50 services d’arrière-plan et 58 tâches planifiées ;
- après le démarrage, l’activité accompagne l’orchestrateur de mises à jour de Windows.
La désactivation des composants d’arrière-plan n’élimine pas complètement l’arrière-plan : dans l’état optimisé, l’évaluation de compatibilité des applications continuait de fonctionner (environ 3,7 ms CPU par seconde dans la fenêtre de maintenance), et l’arrière-plan résiduel total au repos établi s’élevait à 4,8 ms CPU par seconde — environ 0,12 % de la capacité de quatre vCPU (mesuré par trace).
Ce qui est confirmé
Section intitulée « Ce qui est confirmé »- Reproduit (deux séries indépendantes) : nombre de processus −49…−56 %, threads −49…−57 %, mémoire disponible +1,0–1,5 Go.
- Mesuré (série 2) : commit −52 % au repos ; mémoire physique occupée −49 % au repos et −44 % dans la phase après démarrage.
- Mesuré : occupation du CPU au repos −17 % dans une fenêtre silencieuse et −67 % dans une fenêtre avec analyse ; commutations de contexte −19 % et −92 % ; DPC −78 % (fenêtre de la série 2) ; activité après démarrage plus faible dans les deux séries.
- Mesuré : sous pleine charge CPU, gain de bande passante +0,19 % (4 threads) et +0,50 % (8 threads) ; sous charge partielle et mixte — de +5,4 à +11,2 %.
- Mesuré : une charge de classe priorité d’arrière-plan a accéléré de 77,1 % — dans l’état « avant », elle concurrençait le travail d’arrière-plan de Windows lui-même, y compris l’analyse antivirus.
- Observé : les principales sources d’arrière-plan sont l’analyse antivirus, la maintenance et les tâches de compatibilité ; après optimisation, l’arrière-plan résiduel est proche de zéro, mais pas nul.
Ce qui n’est pas confirmé
Section intitulée « Ce qui n’est pas confirmé »- Le gain de FPS, la réduction de l’input lag ou du frametime dans des jeux réels : non mesuré. Les essais CPU synthétiques ne modélisent pas un jeu avec GPU et ne prouvent pas l’effet en jeu.
- La contribution isolée de chaque désactivation particulière : un ensemble de modifications a été appliqué.
- Le transfert des valeurs absolues vers du matériel physique, d’autres builds et d’autres profils d’optimisation.
- La stabilité sur de longues fenêtres : chaque phase dure 5 minutes ; le travail d’arrière-plan de Windows arrive par pics, c’est pourquoi le « jour moyen » n’a pas été mesuré.
- Les mesures ont été effectuées dans une machine virtuelle. La virtualisation apporte sa propre part de DPC/ISR et masque l’ordonnancement de l’hôte ; sur du matériel physique, les valeurs absolues seront différentes. Les proportions et le sens de la comparaison « avant/après » dans des conditions identiques se conservent.
- La métrique ISR est exclue des tableaux : dans une machine virtuelle, le compteur ISR via PDH diverge d’environ 10 % des gestionnaires d’interruptions via ETW et ne converge pas vers une somme exacte.
- La fenêtre « avant » de la série 2 contenait une analyse Defender active, et la charge de l’hôte entre les fenêtres différait (en moyenne 44 % contre 24 %). C’est pourquoi les valeurs sont liées à des fenêtres précises ; le sens est confirmé par deux séries.
- Dans la série 1, une partie de la phase d’inactivité a été interrompue par une pause externe de la machine virtuelle d’environ 26 secondes ; la capture s’est terminée après la reprise, aucun événement perdu.
- Les essais de charge — deux répétitions : il s’agit de statistiques descriptives, la significativité statistique n’a pas été évaluée.
- Une partie du gain au repos est liée à la désactivation de composants de protection de Microsoft Defender. Un système sans protection antivirus est un compromis assumé, et non une optimisation sans coût ; il faut désactiver la protection en comprenant le prix.
- La couche de mesure (trace et compteurs) crée elle-même une petite charge d’arrière-plan ; elle est présente dans les deux états.
L’étude et les outils utilisés appartiennent au développeur de BoosterX, c’est pourquoi le développeur a un intérêt direct aux résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus, et les conclusions peuvent être vérifiées à partir des données ouvertes et des sources publiques citées.
Conclusion pratique
Section intitulée « Conclusion pratique »La réduction du bruit d’arrière-plan est un effet réel, reproduit deux fois : deux fois moins de processus et de threads, deux fois moins d’engagements mémoire, un ordre de grandeur de moins d’activité disque et réseau au repos. C’est utile en soi — pour la réactivité du système, les tâches d’arrière-plan, la température, le bruit des ventilateurs et l’autonomie sur batterie, — et cela ne nécessite aucune promesse de FPS.
Ce qu’il ne faut pas en attendre : un gain de performance sous pleine charge. Si le CPU est déjà chargé par du travail utile à ~89 % de sa capacité, la désactivation de l’activité d’arrière-plan n’ajoutera pas les 11 % restants — dans la machine virtuelle, ils n’appartiennent pas à Windows. Plus le système est occupé au moment de la comparaison, plus l’effet visible est grand : dans une fenêtre de maintenance, la différence est multiple, dans une fenêtre silencieuse — modérée.
Recommandation : évaluez l’arrière-plan avant et après toute modification sur votre ordinateur (Gestionnaire des tâches → « Performances » et « Processus », Moniteur de ressources), plutôt que de vous fier aux pourcentages d’autrui. Si l’objectif est le FPS dans un jeu précis, mesurez-le avant et après la modification.
Restauration de l’état
Section intitulée « Restauration de l’état »Les deux séries ont été exécutées dans des machines virtuelles isolées sur des copies de disque indépendantes ; après les mesures, les machines étaient ramenées à leurs états initiaux. L’article n’exige pas du lecteur qu’il modifie des paramètres, c’est pourquoi aucune action de restauration distincte sur l’ordinateur de l’utilisateur n’est nécessaire.
Sources primaires publiques
Section intitulée « Sources primaires publiques »- Microsoft: Windows Performance Recorder — outil d’enregistrement de traces ETW, utilisé dans la méthodologie ; vérifié le 2026-09-20.
- Microsoft: About Event Tracing — modèle ETW et vérification des événements perdus ; vérifié le 2026-09-20.
- Microsoft: Microsoft Defender Antivirus dans Windows — processus et services Defender, y compris
MsMpEng.exe(« Antimalware Service Executable » dans le Gestionnaire des tâches) ; vérifié le 2026-09-20. - Comment nous étudions Windows — niveaux de preuve et protocole de mesure.
- Service Host et composants d’arrière-plan de Windows 11 — comment Windows répartit les services d’arrière-plan entre les processus.
- Combien de mémoire peut-on réellement libérer dans Windows — analyse détaillée de la mémoire issue de cette même expérience.
- Bureau contre écran de connexion — suite : de quoi est fait le bruit de la session utilisateur.
Historique des modifications
Section intitulée « Historique des modifications »- 2026-09-20 : première publication — deux séries indépendantes de mesures d’inactivité, phases après démarrage, inventaire et essais de charge.
- 2026-09-20 : attribution des résultats par série précisée (commit et mémoire physique occupée — série 2 uniquement ; processus −49…−56 %) ; l’avertissement sur le conflit d’intérêts a été aligné sur la formulation canonique.