Inactivité silencieuse : activité en arrière-plan 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 diminué de 49 à 56 %, l’utilisation du CPU au repos de 17 à 67 %, et la charge mémoire (commit) de 52 % dans la deuxième série. En revanche, sous charge CPU maximale, le débit n’a augmenté que de 0,2 à 0,5 %. Une « inactivité silencieuse » correspond à une réduction confirmée de l’activité en arrière-plan et de la concurrence pour les ressources, pas à une hausse des FPS : l’effet final en jeu n’a pas été mesuré dans cette étude.
Statut : la tendance de l’effet a été reproduite dans deux séries indépendantes sur la même build de Windows 11 dans une machine virtuelle. Les valeurs diffèrent d’une série à l’autre, car l’activité en arrière-plan de Windows survient par pics : pendant une fenêtre avec une analyse de Microsoft Defender, l’écart d’utilisation du CPU atteint −67 %, contre −17 % pendant une fenêtre déjà calme.
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é pendant les premières minutes suivant le démarrage.
- Elle réduit sensiblement la consommation de mémoire.
- Elle apporte un gain de performances mesurable sous charge CPU maximale.
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 : é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 indépendantes du disque afin que les mesures n’interfèrent pas entre elles ;
- phases : 5 minutes après le démarrage, 5 minutes de stabilisation, 5 minutes au repos ;
- courtes charges synthétiques : 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 longues périodes d’observation (heures et jours).
Une série distincte sur un PC physique Ryzen 7 7800X3D, comprenant quatre étapes et des mesures en jeu, est publiée dans l’article « BoosterX : activité en arrière-plan de Windows et FPS dans CS2 ». Ses résultats ne sont pas combinés avec ceux de cette série sur machines virtuelles.
Méthodologie
Section intitulée « Méthodologie »Le protocole est conforme à « Comment nous étudions Windows » :
- chaque phase a été enregistrée au moyen d’une trace ETW (Windows Performance Recorder, profils légers pour le CPU, le disque, les fichiers et le réseau) et de compteurs de performances, avec un intervalle de 5 secondes (système) et de 15 secondes (par processus) ;
- la phase « après le démarrage » a été lancée par un redémarrage contrôlé et a commencé à un temps de fonctionnement d’environ une minute ;
- le nombre d’événements perdus a été vérifié dans chaque trace : il est nul dans toutes les fenêtres présentées ;
- les moyennes ont été calculées 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 essai « avant » a été exclu parce que la machine virtuelle s’est mise en veille ; l’essai répété a été utilisé ;
- les tests de charge ont été exécutés deux fois ; les médianes sont présentées ; l’utilisation du CPU est normalisée sur quatre vCPU.
« Avant » et « après » désignent deux états d’une même installation de Windows : l’état « après » a été obtenu en appliquant le profil d’optimisation, tandis que l’état « avant » correspond à l’état initial. Un ensemble de paramètres a été modifié dans son intégralité ; la contribution isolée de chaque désactivation n’a donc pas été évaluée.
Résultats
Section intitulée « Résultats »Inactivité
Section intitulée « Inactivité »Série 1 (2026-09-18) — période d’inactivité stabilisée sans maintenance active :
| Métrique | Avant | Après | Variation |
|---|---|---|---|
| Utilisation du CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Changements 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 |
| Lectures disque, Ko/s | 22,6 | 24,4 | +8 % |
| Écritures 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 période d’inactivité, mais une analyse en arrière-plan de Microsoft Defender était en cours dans l’état « avant » :
| Métrique | Avant | Après | Variation |
|---|---|---|---|
| Utilisation du CPU, % | 33,37 | 11,03 | −67 % |
| Changements 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 utilisée, Mo | 3 017 | 1 538 | −49 % |
| Charge mémoire (commit), Mo | 2 617 | 1 249 | −52 % |
| Pool non paginé, Mo | 298,2 | 212,9 | −29 % |
| Pool paginé, Mo | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Lectures disque, Mo/s | 7,42 | 0,01 | −99,9 % |
| Écritures disque, Mo/s | 4,57 | 0,23 | −95,0 % |
Il n’y avait presque pas de trafic réseau au repos dans la série 2, quel que soit l’état (quelques dizaines d’octets par seconde) ; les lignes relatives au réseau ne sont donc pas présentées pour cette série. L’écart entre les séries n’est pas une contradiction, mais une caractéristique de l’activité en arrière-plan : lorsque Windows effectue des opérations de maintenance, la désactivation des composants d’arrière-plan permet d’économiser davantage ; lorsque la période est déjà calme, le gain est moindre.
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) |
|---|---|---|
| Utilisation du CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Changements de contexte, /s | 1 114 → 600 | 1 257 → 393 |
| Processus | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Mémoire physique utilisée, Mo | — | 2 821 → 1 581 |
| Mémoire disponible, Mo | — | 5 370 → 6 610 |
| Lectures disque, Ko/s | — | 826 → 433 |
| Écritures disque, Ko/s | 634 → 418 | 709 → 298 |
| Réseau (réception), Ko/s | — | 1,15 → ~0 |
Le tiret indique que la métrique n’a pas été relevée pour cette phase dans cette série.
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 l’optimisation : processus antivirus MsMpEng.exe (257 Mo), explorer.exe (213 Mo), StartMenuExperienceHost (144 Mo), msedge.exe (133 Mo), SearchHost.exe (122 Mo). Après l’optimisation, la liste était dominé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, tandis que la charge mémoire (commit) a diminué de 52 %. L’article « Quelle quantité de mémoire peut-on réellement libérer dans Windows ? » explique ce qu’il est réellement possible de « libérer » et pourquoi la somme des working sets des processus ne correspond pas à la mémoire libre.
Sous charge maximale
Section intitulée « Sous charge maximale »Courts tests synthétiques (série 2, médianes de deux répétitions) :
| Scénario | Variation du débit | Utilisation du CPU : avant / après |
|---|---|---|
| Un thread | +5,4 % | 21,9 / 22,6 % |
| Quatre threads (maximum) | +0,19 % | 88,9 / 89,4 % |
| Huit threads (maximum) | +0,50 % | 88,9 / 88,8 % |
| Charge mémoire | +11,2 % | 84,8 / 87,5 % |
| Charge 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 charge maximale sur quatre threads, le processus utile a utilisé environ 89 % de la capacité des quatre vCPU, avant comme après l’optimisation. Les ~11 % restants dans la machine virtuelle ne peuvent pas être qualifiés de « bruit Windows » éliminable : la planification de l’hyperviseur n’est pas visible dans la trace de la machine invitée. Les threads de travail étaient répartis uniformément (écart de volume de travail entre eux : 0,994 à 0,997) ; aucune famine n’a été observée et la file d’attente du CPU au repos était pratiquement vide après l’optimisation.
Origine de l’activité en arrière-plan
Section intitulée « Origine de l’activité en arrière-plan »Sources mesurées de l’activité en arrière-plan dans l’état « avant » :
- l’analyse antivirus était la principale source pendant la fenêtre de la série 2 : le processus
MsMpEng.exea consommé 212 secondes CPU pendant une période d’inactivité de cinq minutes ; - dans l’état initial, le service de recherche, le service SysMain, la télémétrie, le spouleur d’impression et d’autres composants étaient actifs ; le profil d’optimisation désactive environ 50 services d’arrière-plan et 58 tâches planifiées ;
- après le démarrage, l’activité est accompagnée par l’orchestrateur des mises à jour de Windows.
La désactivation des composants d’arrière-plan ne supprime pas complètement cette activité : dans l’état optimisé, l’évaluation de la compatibilité des applications continuait de fonctionner (environ 3,7 ms CPU par seconde pendant la fenêtre de maintenance), et l’activité résiduelle totale en période d’inactivité stabilisée s’élevait à 4,8 ms CPU par seconde, soit environ 0,12 % de la capacité des quatre vCPU (mesurée par traçage).
Éléments confirmés
Section intitulée « Éléments confirmés »- Reproduit (deux séries indépendantes) : nombre de processus −49…−56 %, nombre de threads −49…−57 %, mémoire disponible +1,0 à 1,5 Go.
- Mesuré (série 2) : commit −52 % au repos ; mémoire physique utilisée −49 % au repos et −44 % pendant la phase suivant le démarrage.
- Mesuré : utilisation du CPU au repos −17 % pendant une fenêtre calme et −67 % pendant une fenêtre avec analyse ; changements de contexte −19 % et −92 % ; DPC −78 % (fenêtre de la série 2) ; activité après le démarrage plus faible dans les deux séries.
- Mesuré : sous charge CPU maximale, hausse du débit de +0,19 % (4 thread) et de +0,50 % (8 threads) ; sous charge partielle et mixte, hausse comprise entre +5,4 et +11,2 %.
- Mesuré : une charge de priorité d’arrière-plan a été accélérée de 77,1 % ; dans l’état « avant », elle était en concurrence avec l’activité en arrière-plan de Windows, notamment l’analyse antivirus.
- Observé : les principales sources d’activité en arrière-plan étaient l’analyse antivirus, la maintenance et les tâches de compatibilité ; après l’optimisation, l’activité résiduelle est proche de zéro, mais pas nulle.
Éléments non confirmés
Section intitulée « Éléments non confirmés »- Hausse des FPS, réduction de l’input lag ou du frametime dans des jeux réels : non mesurées. Les tests CPU synthétiques ne simulent pas un jeu avec GPU et ne prouvent pas d’effet en jeu.
- Contribution isolée de chaque désactivation : un ensemble de modifications a été appliqué.
- Transposition des valeurs absolues à du matériel physique, à d’autres builds et à d’autres profils d’optimisation.
- Stabilité sur de longues périodes : chaque phase a duré 5 minutes ; l’activité en arrière-plan de Windows survient par pics, et la « moyenne sur une journée » n’a pas été mesurée.
- Les mesures ont été effectuées dans une machine virtuelle. La virtualisation contribue elle-même aux DPC/ISR et masque la planification de l’hôte ; les valeurs absolues seront différentes sur du matériel physique. Les proportions et la tendance de la comparaison « avant/après » restent valables dans des conditions identiques.
- La métrique ISR a été exclue des tableaux : dans la machine virtuelle, le compteur ISR de PDH diffère d’environ 10 % des gestionnaires d’interruptions mesurés par ETW et ne correspond pas à leur somme exacte.
- La fenêtre « avant » de la série 2 comprenait une analyse Defender active, et la charge de l’hôte différait entre les fenêtres (44 % en moyenne contre 24 %). Les valeurs sont donc propres aux fenêtres concernées ; la tendance a été confirmée dans deux séries.
- Dans la série 1, une pause externe de la machine virtuelle, d’environ 26 secondes, a interrompu une partie de la phase d’inactivité ; la capture a repris après la reprise de la machine, sans perte d’événements.
- Les tests de charge ont été répétés deux fois : il s’agit de statistiques descriptives, et 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 constitue un compromis délibéré, et non une optimisation sans contrepartie ; la protection ne doit être désactivée qu’en connaissance de cause.
- La couche de mesure (traçage et compteurs) génère elle-même une légère activité en arrière-plan, présente dans les deux états.
L’étude et les outils utilisés appartiennent au développeur de BoosterX, qui a donc un intérêt direct dans les résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus ; 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 de fond est un effet réel, reproduit deux fois : deux fois moins de processus et de threads, deux fois moins de charge mémoire, et 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 — sans qu’il soit nécessaire de promettre une hausse des FPS.
Il ne faut pas en attendre un gain de performances sous charge maximale. Si le CPU est déjà occupé par un travail utile à ~89 % de sa capacité, la désactivation de l’activité en arrière-plan ne libérera pas les 11 % restants : dans une machine virtuelle, ils ne sont pas attribuables à Windows. L’effet visible dépend de l’activité du système au moment de la comparaison : il est plusieurs fois plus important pendant une période de maintenance et modéré pendant une période calme.
Recommandation : évaluez l’activité en 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’autres utilisateurs. Si votre objectif est d’augmenter les FPS dans un jeu précis, mesurez-les avant et après la modification.
Restauration de l’état
Section intitulée « Restauration de l’état »Les deux séries ont été réalisées dans des machines virtuelles isolées, sur des copies indépendantes du disque ; après les mesures, les machines ont été rétablies à leur état initial. L’article ne demande pas au lecteur de modifier des paramètres ; aucune action distincte de restauration n’est donc nécessaire sur un ordinateur personnel.
Sources primaires publiques
Section intitulée « Sources primaires publiques »- Microsoft : Windows Performance Recorder — outil d’enregistrement des traces ETW utilisé dans la méthodologie ; vérifié le 2026-09-20.
- Microsoft : À propos du traçage d’événements — modèle ETW et vérification des événements perdus ; vérifié le 2026-09-20.
- Microsoft : Antivirus Microsoft Defender dans Windows — processus et services Defender, notamment
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 — fonctionnement de l’hébergement des services d’arrière-plan de Windows dans les processus.
- Quelle quantité de mémoire peut-on réellement libérer dans Windows ? — analyse détaillée de la mémoire dans cette même expérience.
- Bureau et écran de connexion — suite : composition de l’activité d’une session utilisateur.
Historique des modifications
Section intitulée « Historique des modifications »- 2026-09-20 : première publication — deux séries indépendantes de mesures au repos, phases après le démarrage, inventaire et tests de charge.
- 2026-09-20 : attribution des résultats par série précisée (commit et mémoire physique utilisée : série 2 uniquement ; processus −49…−56 %) ; l’avertissement relatif au conflit d’intérêts a été harmonisé avec la formulation canonique.