Combien de mémoire peut-on réellement libérer sous Windows

Sur cette page

Réponse courte

On peut réellement libérer moins que ne le promettent les « optimiseurs de mémoire ». Dans cette expérience, la désactivation des composants en arrière-plan a libéré 1,0–1,5 Go de mémoire disponible et réduit le volume d’engagements (commit) de 52 % dans la série 2. Mais les méthodes rapides populaires ne fonctionnent pas : terminer les processus du shell — Windows les redémarre lui-même en environ 20 secondes ; le nettoyage du working set — les pages déchargées restent en RAM comme cache ; les paramètres de registre du gestionnaire de mémoire — aucun bénéfice confirmé. Les désactivations ciblées sur un système déjà optimisé ont donné un honnête +22–30 Mo. La mémoire dans la liste standby est un cache déjà pris en compte dans la mémoire « disponible ».

Statut : les chiffres finaux ont été obtenus dans une machine virtuelle avec 8 Go de RAM sous Windows 11 (26H2, build 26300.9457). Les tendances sont confirmées par la documentation Microsoft et nos expériences contrôlées ; les valeurs absolues sur une autre configuration seront différentes.

Affirmations vérifiables

Nous avons vérifié quatre affirmations :

Terminer les processus en arrière-plan « inutiles » libère de la mémoire.
Le nettoyage du working set ou de la liste standby (mécanique des « optimiseurs de RAM ») libère de la mémoire.
Les paramètres de registre du gestionnaire de mémoire libèrent sensiblement de la mémoire.
La désactivation des composants en arrière-plan libère un grand volume de mémoire.

Périmètre de l’étude

Windows 11 Pro, build 26300.9457 (26H2) ; machine virtuelle, 8 Go de RAM ;
deux états d’une même installation : initial (« avant ») et après application du profil d’optimisation BoosterX — la mesure a été effectuée dans deux séries indépendantes (protocole détaillé et autres métriques — dans « Repos silencieux : l’arrière-plan de Windows avant et après optimisation ») ;
par-dessus l’état « après » — un ensemble de désactivations ciblées de sources en arrière-plan (autologgers de diagnostic ETW, services de notifications, de cliché instantané et d’orchestrateur de mises à jour) ;
métriques : mémoire disponible et occupée, volume d’engagements (commit), nonpaged/paged pool, working set et private bytes par processus, défauts de page (hard faults).

Non inclus : le matériel physique, les systèmes avec un autre volume de RAM, les expériences de désactivation du pagefile et les utilitaires tiers d’« optimisation de mémoire ».

Méthodologie

L’inventaire de la mémoire a été relevé au repos stabilisé : compteurs système (disponible, occupée, commit, pools) et liste des processus avec working set et private bytes.
Expérience contrôlée « terminer les processus du shell » : deux processus d’interface (SearchHost.exe et StartMenuExperienceHost) ont été arrêtés, l’état a été vérifié après 20 et 40 secondes ; le commit a été enregistré avant et après.
L’ensemble de désactivations ciblées a été appliqué à l’état « après », puis une redémarrage et une comparaison avec quatre démarrages de contrôle du même état sans l’ensemble ont été effectués ; les essais de démarrage vérifiaient l’absence de régression de performance.
La couche de mesure (traçage, compteurs, scripts de collecte) occupe elle-même de la mémoire — jusqu’à une centaine et plus de Mo de working set dans certaines mesures ; c’est précisé dans les limites.

Résultats

Combien occupe l’arrière-plan

Relevé de l’inventaire au repos (série 1) :

	Avant	Après	Changement
Working set total, Mo	3 841	1 868	−51 %
Private bytes totaux, Mo	1 524	660	−57 %
Mémoire disponible, Mo	5 490	6 518	+1 028

Série 2 : mémoire occupée 3 017 → 1 538 Mo, disponible 5 174 → 6 653 Mo, volume d’engagements 2 617 → 1 249 Mo. La tendance coïncide dans les deux séries : les composants en arrière-plan retiennent environ la moitié de la mémoire occupée de ce profil.

Structure de la mémoire occupée

Dans l’état « après », la mémoire se répartissait ainsi (working set totaux, série 1) :

shell (explorateur, DWM, recherche dans le menu « Démarrer », nœud de session) — environ 640 Mo ;
services en arrière-plan — environ 640 Mo (57 services dans 39 processus hôtes) ;
composant web de recherche — environ 320 Mo ;
pools du noyau — environ 167 Mo, dont environ 76 Mo occupés par les pools du registre.

Le working set d’un processus n’est pas égal à la mémoire libérable : il inclut les pages partagées (code des bibliothèques système, données communes), qui sont comptées dans chaque processus simultanément. Dans l’état « après » de la série 1, la somme des working set de 75 processus s’élevait à 1 868 Mo, et la somme des private bytes — 660 Mo ; dans les démarrages de contrôle de l’expérience avec désactivations ciblées, le working set total s’élevait à 2 036 Mo. Les plus grands processus d’interface (série 2) :

Processus	Working set, Mo	Private, Mo
`SearchHost.exe` (recherche)	187	80
`explorer.exe` (explorateur)	167	36
`StartMenuExperienceHost`	107	24
`dwm.exe` (DWM)	73	34

Dans l’état « après », la liste standby s’élevait à 711 Mo. Ce n’est pas de la mémoire perdue, mais un cache : le standby est déjà pris en compte dans la mémoire « disponible », et Windows réutilise instantanément ces pages lorsqu’une application réclame de la mémoire.

Expérience : terminer les processus du shell

Après l’arrêt de SearchHost.exe et StartMenuExperienceHost (série 2) :

les deux processus ont redémarré automatiquement en environ 20 secondes avec de nouveaux identifiants ; après 40 secondes, ils fonctionnaient toujours ;
le volume d’engagements n’a pas diminué, mais a augmenté de 12,6 Mo (de 1 386,9 à 1 399,5 Mo) — le redémarrage des processus du shell crée lui-même un nouveau travail ;
la hausse temporaire de la mémoire « disponible » de 93 Mo n’est pas une économie : les processus cibles sont revenus, le commit a augmenté.

Terminer l’explorateur dans une mesure séparée (série 1) n’a pas non plus donné de croissance stable de la mémoire libre : dans cette fenêtre, la mémoire libre a même diminué de 97 Mo avec une hausse du standby de 13 Mo — les pages déchargées restent dans le système comme cache, et le shell et les processus associés continuent de fonctionner.

Conclusion de l’expérience : terminer de force les processus système ne libère pas de mémoire. Windows redémarre automatiquement les composants du shell, et au lieu d’une économie, vous obtenez une charge supplémentaire.

Nettoyage du working set et de la liste standby

La mécanique est documentée par Microsoft. Le déchargement des pages du working set (par exemple, par la fonction EmptyWorkingSet ou SetProcessWorkingSetSize avec une taille « vide » — ce sont précisément celles qu’utilisent les « optimiseurs de RAM ») transfère les pages dans un état transitoire : elles restent mises en cache en RAM jusqu’à ce qu’elles soient à nouveau nécessaires ou réutilisées. L’accès suivant du processus à une telle page est un défaut de page logiciel et un retour dans le working set.

C’est pourquoi le nettoyage du working set change le chiffre « libre » dans les compteurs, mais ne crée pas de mémoire physiquement disponible : les pages ne disparaissent nulle part, et un nouvel accès à celles-ci devient plus coûteux. Le nettoyage de la liste standby est dénué de sens pour la même raison : le standby est déjà de la mémoire disponible pour le système. Dans nos mesures, la pression sur la mémoire était absente dans les deux états (les hard faults restaient bas), c’est pourquoi le déchargement supplémentaire n’améliorait rien.

Notre critère issu de cette expérience : le résultat d’une « libération de mémoire » doit être évalué par le commit, les défauts de page et les latences lors de la réutilisation de la mémoire, et non par une hausse temporaire de la ligne « libre ».

Désactivations ciblées : un gain honnête

Par-dessus l’état « après », nous avons désactivé neuf autologgers de diagnostic ETW et quatre services en arrière-plan (notifications, cliché instantané, orchestrateur de mises à jour) et comparé le résultat avec quatre démarrages de contrôle :

Métrique	Démarrages de contrôle	Avec l’ensemble	Différence
Mémoire libre, Mo	6 664–6 674	6 696	+22…+30
Nonpaged pool, Mo	69,8–71,8	58,7	−11…−13
Working set total, Mo	2 036	1 959	−77
Performance des essais	sans changements	sans changements	—

Seuls les autologgers ont donné −13,2 Mo de nonpaged pool (mesuré séparément). Important : la somme des working set des composants désactivés selon l’inventaire s’élevait à environ 78 Mo, alors que le gain réel de mémoire libre est de +22–30 Mo. La différence apparaît parce qu’une partie de ce qui a été « désactivé » n’était de toute façon pas lancée. C’est là la frontière honnête des désactivations ciblées sans suppression de composants du système ; accessoirement, ce même ensemble a réduit l’activité en arrière-plan au repos de 24 % supplémentaires.

Les paramètres de registre du gestionnaire de mémoire (tailles des pools, du cache système et similaires) n’ont même pas été considérés dans cette expérience comme source de gain : leur lecture et leur utilité pratique sont analysées dans « Memory Manager et cache système » — ils n’ont aucun bénéfice confirmé pour libérer de la RAM.

Ce qui est confirmé

Reproduit (deux séries) : la désactivation des composants en arrière-plan libère 1,0–1,5 Go de mémoire disponible ; le working set total a diminué de 51 % (série 1), la mémoire occupée — de 49 % et le volume d’engagements (commit) — de 52 % (série 2).
Mesuré : le redémarrage automatique des processus du shell arrêtés en l’espace de 20 secondes ; le commit ne diminue pas pour autant (dans notre expérience, il a augmenté de 12,6 Mo).
Mesuré : terminer l’explorateur ne donne pas de croissance stable de la mémoire libre ; les pages déchargées restent en standby.
Documenté : le déchargement des pages du working set les transfère dans un état transitoire, mis en cache en RAM ; la mémoire standby est prise en compte dans la mémoire disponible.
Mesuré : les désactivations ciblées sur un système optimisé donnent +22–30 Mo de mémoire libre à performance inchangée ; la somme des working set de ce qui est désactivé n’est pas égale au gain de mémoire libre.

Ce qui n’est pas confirmé

Les « optimiseurs de RAM » tiers n’ont pas été testés directement : c’est la mécanique (nettoyage du working set) sur laquelle ils reposent qui a été vérifiée.
La désactivation du pagefile n’a pas été mesurée ; on sait seulement que le pagefile est nécessaire pour le crash dump et la limite des engagements de mémoire.
Le transfert des valeurs vers des machines avec un autre volume de RAM, d’autres builds et du matériel physique.
La stabilité de l’économie sur de longues fenêtres : les mesures ont été effectuées au repos stabilisé.

Limites

Machine virtuelle avec 8 Go de RAM : les chiffres absolus sont liés à cette configuration ; un profil avec un plus grand volume de composants en arrière-plan libérera davantage, un système « silencieux » — moins.
La somme des working set par processus surestime l’empreinte unique en raison des pages partagées ; c’est précisément pourquoi nous donnons les private bytes à côté.
La couche de mesure occupait elle-même une mémoire notable (jusqu’à des centaines de Mo de working set dans certaines mesures) — les chiffres d’état incluent la présence de la mesure.
Il n’y avait pas de pression sur la mémoire dans l’expérience (hard faults bas), c’est pourquoi nous n’avons pas vérifié si l’économie réduit le thrashing en conditions de manque de RAM.
Une partie de la libération est liée à la désactivation de composants de protection Microsoft Defender — c’est un compromis avec la sécurité, et non de la mémoire obtenue gratuitement.

L’étude et les outils utilisés appartiennent au développeur de BoosterX, et BoosterX est un optimiseur Windows, c’est pourquoi la mesure de l’effet de l’optimisation relève de son intérêt direct. 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 énumérées. Les résultats négatifs concernant les méthodes populaires de « libération de mémoire » sont publiés au même titre que les positifs.

Conclusion pratique

Ce qui libère réellement de la mémoire, selon cette expérience :

fermer les applications inutilisées — leurs private bytes sont libérés entièrement ;
désactiver les composants en arrière-plan réellement inutiles — l’effet cumulé mesuré est décrit dans « Repos silencieux » ; c’est la seule méthode parmi celles vérifiées qui a donné des gigaoctets, et son prix est la perte des fonctions correspondantes ;
évaluer le résultat par le commit et la mémoire disponible (Gestionnaire des tâches → « Performances » → « Mémoire »), et non par la ligne « libre ».

Ce qui ne fonctionne pas :

terminer de force les processus système : Windows les redémarre en quelques secondes, le commit augmente ;
les « optimiseurs de RAM » et le nettoyage du standby : les pages déchargées restent en RAM comme cache, et leur remise en service coûte des défauts de page logiciels ;
les paramètres de registre du gestionnaire de mémoire.

La mémoire standby n’est pas un problème, mais le travail du cache : la mémoire « disponible » l’inclut déjà. Laissez le pagefile sous la gestion du système : il est nécessaire pour la limite des engagements de mémoire et les vidages de plantage.

Restauration de l’état

Les expériences ont été effectuées dans une machine virtuelle isolée sur des branches d’état de test ; après les mesures, les branches de test ont été réinitialisées, la machine a été remise dans son état initial. L’article ne recommande pas de terminer les processus système ni de désactiver le pagefile, c’est pourquoi aucune action de restauration distincte sur l’ordinateur de l’utilisateur n’est requise.

Sources primaires publiques

Microsoft: Working Set — composition du working set, déchargement des pages, pages transitoires mises en cache en RAM, et fonctions EmptyWorkingSet/SetProcessWorkingSetSize ; vérifié le 2026-09-20.
Microsoft: EmptyWorkingSet — API utilisée par les utilitaires d’« optimisation de mémoire » ; vérifié le 2026-09-20.
Microsoft: About Memory Management — modèle de mémoire virtuelle et pages partagées ; vérifié le 2026-09-20.
Microsoft: Introduction to the page file — commit charge, limite des engagements et rôle du pagefile ; vérifié le 2026-09-20.
Memory Manager et cache système — étude des paramètres de registre du gestionnaire de mémoire.
Repos silencieux : l’arrière-plan de Windows avant et après optimisation — protocole de mesure et autres métriques de cette même expérience.
Comment nous étudions Windows — niveaux de preuve et règles de mesure.

Historique des modifications

2026-09-20 : les chiffres ont été mis en conformité avec les tableaux des séries : « après » de la série 1 — 1 868/660 Mo, l’attribution des pourcentages par métriques et séries a été précisée ; le déni de conflit d’intérêts a été renforcé jusqu’à la formulation complète.
2026-09-20 : première publication — inventaire de la mémoire dans deux séries, expériences négatives avec la terminaison des processus et le nettoyage, gain honnête des désactivations ciblées.