Trouver rapidement les gros fichiers : PowerShell bat toutes les applications ‘cleaner’

Pourquoi PowerShell bat les applications « cleaner » (en production)

Les applications « cleaner » promettent le « un clic ». Les équipes d’exploitation devraient craindre le « un clic ». Pas parce que la commodité est mauvaise, mais parce que les environnements de production exigent des preuves, de la reproductibilité et un plan de retour arrière. PowerShell vous offre ces trois éléments.

Les applications « cleaner » présentent trois problèmes récurrents

• Elles optimisent l’apparence, pas la forensic. Vous obtenez un camembert et un bouton vert. Vous n’obtenez pas une piste d’audit qui satisfait la sécurité, la gestion des changements ou votre futur vous.
• Elles devinent. « Junk » est une catégorie subjective. Votre « junk » peut être un cache métier évitant une reconstruction de 40 minutes en heures ouvrées.
• Elles élargissent votre rayon d’impact. Installer des binaires tiers sur des serveurs pendant une panne est la façon dont de petits incidents deviennent des enquêtes d’une semaine.

PowerShell est ennuyeux — et l’ennui gagne

PowerShell peut scanner, trier, filtrer, exporter et relancer la même logique le mois suivant. Vous pouvez faire relire un script en revue de code. Vous pouvez enregistrer la sortie dans un ticket. Vous pouvez expliquer votre décision en langage clair : « Top 50 fichiers par taille sous D:\Logs ; fichiers supprimés plus anciens que 30 jours ; conservation des 7 derniers jours de logs IIS ; vérification de l’augmentation de l’espace libre de X. »

Bonus : PowerShell ne requiert pas toujours des droits admin pour effectuer un travail utile. Dans des environnements verrouillés, un inventaire en lecture seule suffit souvent pour diagnostiquer le problème et remettre la bonne liste au bon propriétaire.

Une citation à garder au mur : « L’espoir n’est pas une stratégie. » — Gene Kranz

Blague n°1 : Les applications cleaner sont comme des pilules minceur — certaines fonctionnent, la plupart non, et toutes détestent votre foie. Les serveurs n’ont pas de foie, mais ils ont des journaux d’audit.

Quelques faits et un peu d’histoire qui expliquent le bazar actuel

L’explosion de la consommation disque n’est pas née de nulle part. C’est le résultat prévisible de décennies de comportements Windows, d’habitudes logicielles d’entreprise et d’économie du stockage. Voici des faits concrets qu’on trouve dans de vrais environnements :

1. NTFS supporte les flux de données alternatifs depuis les années 1990. La plupart des outils ne les affichent pas. La plupart des auteurs de malwares les adorent. La plupart des applications « cleaner » les ignorent.
2. Le cache de Windows Installer (MSI) est délibéré. Il conserve des copies des données d’installation dans C:\Windows\Installer pour permettre réparations et correctifs ultérieurs. Le supprimer « fonctionne » jusqu’à ce que ça ne fonctionne plus.
3. Le magasin de composants de Windows Update (WinSxS) n’est pas un simple cache. Il fait partie du servicing. La taille sur disque est souvent inférieure à ce qu’Explorer suggère à cause des hardlinks.
4. Pagefile et hibernation échangent disque contre stabilité et vitesse. Beaucoup d’ordinateurs portables sont livrés avec l’hibernation activée ; beaucoup de VM ont des pagefiles dimensionnés pour une pression mémoire pire-cas.
5. Les snapshots VSS peuvent consommer silencieusement énormément d’espace. Les produits de sauvegarde, les « Versions précédentes » et les snapshots coherents pour les applications utilisent le stockage shadow qui grossit jusqu’à sa limite — ou jusqu’à votre espace libre.
6. « Les logs sont bon marché » est devenu un mensonge avec la montée des SSD rapides. Logging à fort débit combiné à des disques OS petits est un mode d’échec classique de Windows Server.
7. Les points de jonction et reparse points peuvent tromper des scans naïfs. Si vous recursez sans soin, vous pouvez boucler vers des redirections style C:\Users\All Users et double-compter.
8. Le journal de changement USN existe pour une raison. Il trace les modifications du système de fichiers pour l’indexation/réplication/sauvegarde. Certaines charges de travail le saturent ; il peut devenir volumineux sur des volumes très actifs.
9. Les PST Outlook n’ont pas disparu. Même avec des plateformes mail modernes, vous trouverez encore des archives PST de plusieurs Go sur des partages — généralement à l’endroit le moins sauvegardé possible.

Mode opératoire pour un diagnostic rapide : trouvez le goulot avant de « nettoyer »

Les alertes disque masquent souvent le vrai problème : un processus qui tourne sans contrôle, une tâche de sauvegarde qui échoue, un spooler bloqué ou une politique de rétention qui n’a jamais existé. Ce playbook décrit ce que vous faites quand vous avez 10 minutes et un canal Slack qui s’échauffe.

Première étape : vérifiez le symptôme et l’étendue

• Quel volume est réellement bas ? Pas « le serveur ». Le volume. C: peut être correct tandis qu’un VHDX monté se noie.
• L’espace libre diminue-t-il en ce moment ? Si oui, vous cherchez un écrivain (logs, dumps, temp). Si non, vous cherchez une accumulation (rétention, sauvegardes, installateurs).
• C’est une machine ou plusieurs ? Plusieurs machines indiquent une politique, un déploiement de correctif ou une montée d’application. Une seule machine indique une charge locale ou une corruption.

Deuxième étape : décidez si vous avez besoin de « qui écrit » ou de « ce qui est volumineux »

• Espace libre qui chute rapidement : examinez les journaux d’événements, les processus en cours et les répertoires qui croissent (logs, temp, spool, dumps).
• Espace libre stable mais bas : inventairez les répertoires et fichiers les plus volumineux ; concentrez-vous sur les données appartenant à des humains et sur les caches applicatifs.

Troisième étape : identifiez les zones « ne pas toucher »

La plupart des incidents empirent lorsque l’on supprime la mauvaise chose. Avant de supprimer quoi que ce soit, marquez ces éléments comme « à manipuler avec précaution » :

• C:\Windows et en particulier C:\Windows\Installer
• C:\Windows\WinSxS
• Fichiers de disques Hyper-V/VMware (.vhdx, .vmdk)
• Chemins de données/logs de bases de données (SQL, Exchange, etc.)
• Dépôts de sauvegarde et stockage des copies shadow

Quatrième étape : choisissez la soupape de secours à moindre risque

Si vous avez besoin d’espace immédiat pour arrêter un outage, les options à moindre risque sont généralement :

• Faire pivoter/compresser les logs (logs applicatifs, logs IIS) avec une rétention connue
• Vider %TEMP% pour le compte de service concerné (avec prudence)
• Supprimer d’anciens dumps si vous avez déjà capturé ce dont vous avez besoin
• Déplacer de grands ensembles de données connus vers un volume plus grand (avec notification des propriétaires)

Tâches pratiques (commandes, signification des sorties et décisions)

Ci‑dessous se trouvent des tâches réelles que vous pouvez exécuter sur des hôtes Windows. Les commandes sont présentées comme si vous étiez sur un shell ; la partie importante est le PowerShell que vous exécutez. Chaque tâche inclut : commande, ce que signifie la sortie et la décision à prendre.

Task 1: Confirm which volumes are actually low

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object -Property DriveLetter | Select DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size | Format-Table -AutoSize"
DriveLetter FileSystemLabel FileSystem SizeRemaining          Size
----------- -------------- ---------- -------------          ----
C           OS             NTFS       8.21 GB         127.87 GB
D           Data           NTFS       412.50 GB       931.51 GB
E           Logs           NTFS       900.12 MB        50.00 GB

Ce que cela signifie : E: est le feu. C: ne l’est pas. Cela évite l’erreur classique : nettoyer le mauvais disque parce que quelqu’un a dit « le serveur est plein ».

Décision : Concentrez les scans sur E:\. Si E: est destiné aux logs, vérifiez la rétention et les écrivains.

Task 2: See if free space is dropping in real time (quick check)

cr0x@server:~$ powershell -NoProfile -Command "$d='E'; 1..5 | ForEach-Object { Get-Volume -DriveLetter $d | Select DriveLetter,SizeRemaining; Start-Sleep -Seconds 3 }"
DriveLetter SizeRemaining
----------- -------------
E           900.12 MB
E           892.44 MB
E           881.03 MB
E           870.77 MB
E           861.65 MB

Ce que cela signifie : Vous perdez activement de l’espace. C’est un écrivain, pas une accumulation historique.

Décision : Priorisez les répertoires qui croissent en ce moment (logs/temp/spool) et les fichiers avec des timestamps récents.

Task 3: Find the top 50 largest files under a path

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 50 FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                   GB  LastWriteTime
--------                                   --  -------------
E:\Logs\app\trace-2026-02-05.log           9.8 2/5/2026 2:10:12 AM
E:\Dumps\serviceA_2026_02_05_0211.dmp      4.2 2/5/2026 2:11:43 AM
E:\Logs\iis\W3SVC1\u_ex260205.log          1.1 2/5/2026 2:05:01 AM

Ce que cela signifie : Les plus gros coupables sont évidents : un log trace et des dumps qui mangent le disque.

Décision : Arrêtez ou reconfigurez l’écrivain avant de supprimer, sinon vous referez le même nettoyage toutes les 10 minutes.

Task 4: Find the largest directories (fast-ish, no extra modules)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -Directory -Force | ForEach-Object { $size=(Get-ChildItem -LiteralPath $_.FullName -File -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$_.FullName; GB=[math]::Round($size/1GB,2)} } | Sort-Object GB -Descending | Select-Object -First 15 | Format-Table -AutoSize"
Path                 GB
----                 --
E:\Logs              38.44
E:\Dumps             10.21
E:\Temp               1.02

Ce que cela signifie : Confirme les « grosses zones » pour ne pas perdre du temps dans des répertoires insignifiants.

Décision : Approfondissez les 1–2 répertoires principaux ; ignorez le reste jusqu’à ce que vous ayez récupéré assez d’espace.

Task 5: Identify recent growth (largest files written in last 24 hours)

cr0x@server:~$ powershell -NoProfile -Command "$since=(Get-Date).AddHours(-24); Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Where-Object LastWriteTime -ge $since | Sort-Object Length -Descending | Select-Object -First 30 FullName, @{n='MB';e={[math]::Round($_.Length/1MB,1)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                   MB   LastWriteTime
--------                                   --   -------------
E:\Logs\app\trace-2026-02-05.log           10032.0 2/5/2026 2:10:12 AM
E:\Dumps\serviceA_2026_02_05_0211.dmp       4300.4 2/5/2026 2:11:43 AM

Ce que cela signifie : Confirme que ces fichiers sont récents. Si les plus gros fichiers sont anciens, le problème est de la rétention. S’ils sont nouveaux, c’est un incident en cours.

Décision : Escaladez auprès du propriétaire applicatif avec des preuves : chemins exacts et timestamps.

Task 6: Show file types consuming space (group by extension)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Group-Object Extension | ForEach-Object { $sum=($_.Group | Measure-Object Length -Sum).Sum; [pscustomobject]@{Ext=$_.Name; Count=$_.Count; GB=[math]::Round($sum/1GB,2)} } | Sort-Object GB -Descending | Select-Object -First 15 | Format-Table -AutoSize"
Ext   Count GB
---   ----- --
.log   1242 29.10
.dmp     14 10.21
.zip    188  3.44

Ce que cela signifie : Votre espace est principalement consommé par des logs et des dumps. C’est opérationnellement résoluble.

Décision : Mettez en place la rotation/compression pour .log, et configurez la rétention des dumps ou déplacez-les sur un volume plus grand.

Task 7: Find huge files owned by “Users” paths (often human-caused)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\Users' -File -Recurse -ErrorAction SilentlyContinue | Where-Object Length -gt 2GB | Sort-Object Length -Descending | Select FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                                  GB LastWriteTime
--------                                                  -- -------------
C:\Users\jdoe\Downloads\vm-image.vhdx                    22.5 1/12/2026 4:44:02 PM
C:\Users\jdoe\AppData\Local\Temp\installer-cache.bin      3.1 2/4/2026 9:01:15 AM

Ce que cela signifie : Un profil utilisateur héberge quelque chose qui appartient sur un disque de données, pas sur le disque OS.

Décision : Déplacez-le (ne le supprimez pas) s’il est légitime, ou appliquez des politiques de nettoyage de profils s’il s’agit de junk.

Task 8: Check Recycle Bin size (surprisingly effective on shared hosts)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\$Recycle.Bin' -Force -ErrorAction SilentlyContinue | Select Name,FullName | Format-Table -AutoSize"
Name                                   FullName
----                                   --------
S-1-5-21-2222222222-3333333333-4444444444-1001 C:\$Recycle.Bin\S-1-5-21-2222222222-3333333333-4444444444-1001

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\$Recycle.Bin' -Force -Recurse -ErrorAction SilentlyContinue | Measure-Object Length -Sum | Select @{n='GB';e={[math]::Round($_.Sum/1GB,2)}}"
GB
--
14.72

Ce que cela signifie : Les fichiers supprimés consomment toujours du disque. Sur des hôtes RDS et des serveurs partagés, cela peut être un tueur silencieux.

Décision : Videz les Corbeilles via une politique ou un nettoyage ciblé — après confirmation des attentes en matière de données utilisateur sur l’hôte.

Task 9: Inspect shadow copy storage (VSS) usage

cr0x@server:~$ powershell -NoProfile -Command "vssadmin list shadowstorage"
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (E:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Shadow Copy Storage volume: (E:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Used Shadow Copy Storage space: 18.432 GB (36%)
   Allocated Shadow Copy Storage space: 20.000 GB (40%)
   Maximum Shadow Copy Storage space: 20.000 GB (40%)

Ce que cela signifie : VSS a réservé 20 Go. Sur un volume de logs de 50 Go, c’est agressif.

Décision : Si VSS n’est pas requis pour ce volume, réduisez la taille max ou déplacez-le. Coordonnez-vous d’abord avec les responsables sauvegarde/restauration.

Task 10: Identify Windows Error Reporting dumps and crash artifacts

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\ProgramData\Microsoft\Windows\WER' -Recurse -File -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 20 FullName,@{n='MB';e={[math]::Round($_.Length/1MB,1)}},LastWriteTime | Format-Table -AutoSize"
FullName                                                                 MB  LastWriteTime
--------                                                                 --  -------------
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_serviceA... 950.2 2/5/2026 1:58:03 AM

Ce que cela signifie : Des crashs laissent des traces. Bon pour le debugging, mauvais pour les disques petits.

Décision : Si l’incident est en cours, conservez les artefacts les plus récents et purge les anciens après les avoir capturés pour l’ingénierie.

Task 11: Check IIS logs size and apply retention safely

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\inetpub\logs\LogFiles'; Get-ChildItem -LiteralPath $p -File -Recurse -ErrorAction SilentlyContinue | Measure-Object Length -Sum | Select @{n='GB';e={[math]::Round($_.Sum/1GB,2)}}"
GB
--
33.87

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\inetpub\logs\LogFiles'; $cut=(Get-Date).AddDays(-30); Get-ChildItem -LiteralPath $p -File -Recurse -ErrorAction SilentlyContinue | Where-Object LastWriteTime -lt $cut | Select-Object -First 5 FullName,LastWriteTime | Format-Table -AutoSize"
FullName                                      LastWriteTime
--------                                      -------------
C:\inetpub\logs\LogFiles\W3SVC1\u_ex251201.log 12/1/2025 12:00:00 AM
C:\inetpub\logs\LogFiles\W3SVC1\u_ex251202.log 12/2/2025 12:00:00 AM

Ce que cela signifie : Vous pouvez récupérer de l’espace en supprimant les logs plus anciens que la rétention. L’aperçu montre quels fichiers seraient concernés.

Décision : Si 30 jours est acceptable pour votre organisation, supprimez ces logs plus anciens (ou compressez-les). Prévisualisez toujours d’abord.

Task 12: Export an inventory for audit and escalation

cr0x@server:~$ powershell -NoProfile -Command "$root='E:\'; Get-ChildItem -LiteralPath $root -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object FullName,Length,LastWriteTime | Select-Object -First 500 | Export-Csv -NoTypeInformation -Path 'C:\Temp\top500-files.csv'; Get-Item 'C:\Temp\top500-files.csv' | Select Name,Length"
Name              Length
----              ------
top500-files.csv  189432

Ce que cela signifie : Vous avez maintenant un artefact partageable : une preuve pour tickets, approbations et suivi.

Décision : Joignez le CSV à l’incident. Faites en sorte que la propriété devienne un problème pour quelqu’un d’autre avec des données, pas des impressions.

Task 13: Find files bigger than a threshold (surgical targeting)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Where-Object Length -gt 1GB | Sort-Object Length -Descending | Select FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                   GB  LastWriteTime
--------                                   --  -------------
E:\Logs\app\trace-2026-02-05.log           9.8 2/5/2026 2:10:12 AM
E:\Dumps\serviceA_2026_02_05_0211.dmp      4.2 2/5/2026 2:11:43 AM

Ce que cela signifie : Une courte liste de fichiers « dignes d’une discussion ».

Décision : Pour chaque fichier : conserver, déplacer, compresser ou supprimer — avec un propriétaire et une raison.

Task 14: Find directories with huge counts of small files (performance and backup pain)

cr0x@server:~$ powershell -NoProfile -Command "$p='E:\Logs'; Get-ChildItem -LiteralPath $p -Directory -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $c=(Get-ChildItem -LiteralPath $_.FullName -File -ErrorAction SilentlyContinue).Count; if($c -gt 5000){ [pscustomobject]@{Path=$_.FullName; FileCount=$c} } } | Sort-Object FileCount -Descending | Select-Object -First 10 | Format-Table -AutoSize"
Path                     FileCount
----                     ---------
E:\Logs\app\debug-archive 18234

Ce que cela signifie : Ce n’est pas toujours des « gros fichiers ». Un grand nombre de petits fichiers ralentit les scans, les sauvegardes et l’antivirus.

Décision : Faites pivoter, compressez en archives, ou redessinez la journalisation. Pour les dossiers « archive », envisagez des ZIP mensuels et la suppression des originaux après vérification.

Task 15: Detect reparse points/junctions to avoid double-counting

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\' -Directory -Force -ErrorAction SilentlyContinue | Where-Object { $_.Attributes -match 'ReparsePoint' } | Select FullName,Attributes | Format-Table -AutoSize"
FullName                     Attributes
--------                     ----------
C:\Documents and Settings     Directory, ReparsePoint

Ce que cela signifie : Récuser sans précaution peut boucler ou retraverser des chemins redirigés.

Décision : Excluez ou gérez explicitement les reparse points dans les scans profonds sur les volumes OS.

Task 16: Check whether a network share scan is even sane (latency first)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path '\\fileserver01\deptshare'; (Get-Date); Get-ChildItem '\\fileserver01\deptshare' -ErrorAction Stop | Select-Object -First 5 Name | Format-Table -AutoSize; (Get-Date)"
True
02/05/2026 02:20:01
Name
----
Accounting
Engineering
Legal
Marketing
Projects
02/05/2026 02:20:03

Ce que cela signifie : Le listing de base prend ~2 secondes. C’est acceptable ; si cela prenait 30–60 secondes, un scan récursif serait insupportable.

Décision : Si le partage est lent, scannez hors heures de pointe, scannez d’abord le niveau supérieur, ou exécutez le scan localement sur le serveur de fichiers.

Blague n°2 : Les outils de nettoyage aiment dire « Trouvé 38 Go de junk ». Si c’était vraiment du junk, ça ne traînerait pas sur votre stockage le plus coûteux.

Trois mini-histoires d’entreprise issues des tranchées de l’espace disque

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe a hérité d’une VM Windows Server qui exécutait une API orientée client. L’alerte était simple : « C: en dessous de 5% de libre ». L’ingénieur d’astreinte a fait ce que beaucoup d’entre nous ont fait sous pression : il a ouvert l’Explorateur, a fait un clic droit sur C: et a cliqué sur « Nettoyage de disque ». Cela a libéré un peu d’espace, et l’alerte s’est tue. Pendant une heure.

L’alerte est revenue, plus sévère. Cette fois le service a commencé à faire des timeouts. L’ingénieur a supposé « les logs grossissent » et a supprimé une poignée de fichiers .log dans un dossier applicatif. Le service est reparti — brièvement. Puis il est tombé complètement.

Le vrai coupable n’était pas les logs applicatifs. C’était un nouveau paramètre de diagnostic qui activait un tracing verbeux des requêtes dans C:\Windows\Temp sous un compte de service. Le service écrivait continuellement de gros fichiers trace. Supprimer des fichiers traitait le symptôme, pas la maladie.

Une fois qu’ils ont utilisé PowerShell pour lister « les plus gros fichiers écrits dans la dernière heure », le schéma était évident : des gigaoctets de traces temporaires fraîches. Ils ont désactivé le paramètre, déplacé le chemin de trace vers un volume de données plus grand et ajouté de la rétention.

La mauvaise hypothèse était « c’est un gonflement disque standard ». C’était un incident d’écriture amplifiée en cours. En production, la direction du temps compte : le disque se remplit-il maintenant, ou s’est-il rempli sur des mois ?

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre entreprise avait un serveur de fichiers où les utilisateurs se plaignaient de recherches lentes et d’un affichage de dossiers lent. Quelqu’un a proposé une « optimisation » : dédupliquer le stockage en archivant les anciens répertoires en ZIP et en les déplaçant dans un unique partage \Archive. Moins d’encombrement, moins de fichiers, moins de problèmes — sur le papier.

Ils ont exécuté un script qui zippait tout ce qui était plus vieux que 180 jours. Cela a réduit le nombre de fichiers. Cela a aussi créé un nouveau mode d’échec : des ZIP géants qui changeaient dès qu’un seul fichier était ajouté, provoquant la recopie répétée d’archives multi‑gigaoctets par les sauvegardes. La fenêtre de sauvegarde s’est élargie et a commencé à entrer en collision avec les heures ouvrables.

Pire encore, l’antivirus devait décompressier ces grosses archives, provoquant des pics CPU. Un « nettoyage » est aussi devenu une régression de performance. Les utilisateurs n’ont pas été impressionnés par le concept d’« efficacité compressée » quand l’Explorateur gelait.

La solution n’était pas d’abandonner le nettoyage. C’était de le faire correctement : archiver de façon immuable (mensuellement, ensembles fermés), garder les archives en lecture seule et utiliser des politiques de rétention alignées sur la stratégie de sauvegarde. PowerShell les a aidés à quantifier le changement : nombre de fichiers, taille totale et « fichiers modifiés depuis N jours » pour éviter de faire tourner les archives.

Une optimisation tourne mal quand elle ignore les systèmes en aval : sauvegardes, AV, indexation et restaurations. L’espace disque n’est jamais que de l’espace disque.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Dans un environnement réglementé, un serveur applicatif Windows gérait des imports par lots chaque nuit. L’équipe avait une pratique ennuyeuse : chaque déploiement incluait un rapport d’utilisation disque attaché au ticket de changement. Ce n’était pas glamour. C’était un petit script PowerShell qui exportait les principaux répertoires et types de fichiers en CSV.

Une nuit, l’espace libre a chuté plus vite que d’habitude. L’ingénieur d’astreinte n’a pas deviné. Il a extrait les trois derniers CSV et les a comparés. Un nouveau dossier est apparu sous D:\Data\Import\Staging avec une forte augmentation de fichiers .tmp. Les timestamps correspondaient à un importeur récemment déployé.

Le développeur de garde a d’abord argué que « ça ne peut pas venir de nous » parce que l’importeur nettoie les fichiers temporaires. Le rapport s’en fichait. Il montrait 120 000 fichiers temporaires créés pendant le job et jamais supprimés lorsque le job plantait en cours d’exécution.

Parce que l’équipe avait déjà un rapport routinier, la réponse à l’incident a été chirurgicale : supprimer les temporaires plus vieux que 7 jours, corriger l’importeur pour nettoyer en cas d’échec et plafonner l’espace de staging. Pas de clics frénétiques, pas d’outils mystérieux, pas de suppression accidentelle d’installateurs ou de fichiers système.

C’est pourquoi les pratiques ennuyeuses gagnent. Elles créent des baselines. Les baselines transforment les disputes en corrections.

Erreurs courantes : symptôme → cause racine → correction

1) « Explorer dit que WinSxS est énorme »

Symptôme : Vous voyez un énorme dossier C:\Windows\WinSxS dans l’Explorateur et vous paniquez.

Cause racine : L’Explorateur surestime la taille parce qu’il ne gère pas les hardlinks de servicing comme vous le pensez.

Correction : Ne supprimez pas les fichiers dans WinSxS. Utilisez les méthodes de nettoyage de servicing prises en charge (et coordonnez les fenêtres de patch). Utilisez les scans PowerShell pour trouver la surcharge non système en priorité.

2) « Nous avons supprimé des trucs mais le disque se remplit de nouveau immédiatement »

Symptôme : Vous libérez 10 Go ; c’est de nouveau plein en 15 minutes.

Cause racine : Un écrivain actif (logging verbeux, génération de dumps en boucle, fichiers temporaires en boucle, file d’attente bloquée).

Correction : Identifiez les écritures récentes (LastWriteTime), puis arrêtez/reconfigurez l’écrivain. Supprimer sans corriger, c’est juste donner votre sommeil à l’entropie.

3) « L’application cleaner a libéré de l’espace, puis les mises à jour ont échoué »

Symptôme : Après le « nettoyage », le patching ou la réparation d’app échoue à cause de ressources d’installation manquantes.

Cause racine : Quelqu’un a supprimé le cache MSI ou des fichiers d’installation système (C:\Windows\Installer).

Correction : Restaurez depuis une sauvegarde si possible ; sinon réinstallez les applications affectées. À l’avenir : traitez les répertoires système comme lecture seule sauf si vous avez une procédure approuvée par l’éditeur.

4) « Le scan d’utilisation disque prend une éternité ou boucle »

Symptôme : Les scans récursifs ne se terminent jamais, montrent des doublons ou font monter le CPU.

Cause racine : Suivre des reparse points/jonctions ; scanner des partages réseau sur des liens lents ; interférence antivirus.

Correction : Détectez les reparse points, scannez depuis le serveur si possible, et commencez par les répertoires de haut niveau avant une récursion profonde.

5) « Les sauvegardes sont soudainement énormes après le nettoyage »

Symptôme : Les jobs de sauvegarde commencent à transférer beaucoup plus de données.

Cause racine : L’archivage/la compression ont modifié de nombreux fichiers ou créé des archives monolithiques qui churnent.

Correction : Utilisez des frontières d’archives immuables, évitez de réécrire de grosses archives et alignez la stratégie de sauvegarde avec le nettoyage.

6) « Nous avons supprimé des logs et l’application a cessé de logger »

Symptôme : Après la suppression, l’application ne peut plus écrire de logs ou se comporte étrangement.

Cause racine : L’application avait un handle ouvert ; la suppression a perturbé la rotation ; l’héritage des permissions/ACL a été rompu ; l’application attend que le chemin existe.

Correction : Préférez la troncature/rotation contrôlée, préservez la structure des répertoires, redémarrez les services si nécessaire et définissez des politiques de rétention explicites.

Listes de contrôle / plan étape par étape

Checklist A: « Nous sommes à court d’espace maintenant » (mode incident)

1. Identifier le volume (Task 1). Notez-le dans le ticket.
2. Vérifier si l’espace diminue (Task 2). Si oui, traitez comme un écrivain actif.
3. Obtenir les plus gros fichiers récents (Task 5). Capturez les 30 premiers et leurs timestamps.
4. Trouver les types de fichiers principaux (Task 6). Logs/dumps/temp sont courants.
5. Choisir la soupape de secours à moindre risque : anciens logs, anciens dumps, temp plus vieux qu’une fenêtre.
6. Exporter des preuves (Task 12) avant de supprimer quoi que ce soit de significatif.
7. Corriger l’écrivain : changement de config, rotation, déplacement de chemin, rétention ou correction de bug.
8. Vérifier la récupération : espace libre stable ; services sains ; surveillance calme.

Checklist B: « Nous manquons d’espace tous les mois » (mode ingénierie)

1. Baseliner l’utilisation disque chaque semaine avec des exports scriptés (top dirs, top types de fichiers).
2. Séparer les volumes de logs des volumes OS quand c’est possible. De petits disques C: et des applis bavardes ne cohabitent pas bien.
3. Définir la rétention par type de log (les logs de sécurité diffèrent des logs de debug).
4. Appliquer des limites : stockage shadow VSS, dossiers de staging, répertoires spool.
5. Rendre les propriétaires visibles : mappez les chemins principaux aux équipes ou applications ; publiez une table de propriété simple.
6. Automatiser le nettoyage seulement après avoir prouvé que c’est sûr avec des prévisualisations et des dry runs.

Checklist C: « Nous devons scanner un énorme partage de fichiers » (mode sanity)

1. Exécutez le scan depuis le serveur de fichiers si possible (réduit le bruit réseau).
2. Commencez par les répertoires de haut niveau ; ne recursez pas partout d’emblée.
3. Mesurez la latence d’un listing basique (Task 16). Si c’est lent, programmez hors heures.
4. Exportez les résultats en CSV et laissez les propriétaires décider de ce qui est supprimable.

FAQ

1) Pourquoi ne pas utiliser un outil GUI comme WinDirStat ou TreeSize ?

Sur une station de travail, d’accord. Sur un serveur pendant un incident, PowerShell gagne car il est natif, scriptable, relisible et facile à exécuter à distance. De plus : vous pouvez exporter des preuves.

2) Est-ce que les scans PowerShell sont sûrs sur des serveurs de production ?

Les scans en lecture seule sont généralement sûrs, mais ils peuvent être gourmands en I/O sur des volumes très sollicités. Commencez ciblé (répertoires de haut niveau, écritures récentes) et évitez de scanner des partages réseau entiers en heures de pointe.

3) Quelle est la façon la plus rapide de trouver « ce qui a changé » ?

Filtrez par LastWriteTime (Task 5) et triez par taille. Cela vous dit ce qui a récemment grandi et suffit généralement à identifier l’écrivain.

4) Puis-je supprimer des fichiers directement depuis PowerShell ?

Oui, mais faites-le seulement après une prévisualisation et un export. Supprimer, c’est facile ; l’expliquer ensuite est la partie difficile. Utilisez des règles de rétention (plus vieux que X jours) et conservez un enregistrement.

5) Pourquoi mon scan manque-t-il certains fichiers ?

Permissions et répertoires verrouillés sont courants. Utilisez -ErrorAction SilentlyContinue pour l’inventaire, mais si vous avez besoin d’exhaustivité, exécutez avec les droits appropriés et journalisez les erreurs.

6) Pourquoi la « taille du dossier » diffère-t-elle entre les outils ?

Hardlinks, reparse points et différences d’outils dans ce qu’ils comptent. Certains outils comparent taille allouée vs taille logique. Pour décider, concentrez-vous sur « gros fichiers par chemin » et « ce qui croît ».

7) Comment gérer VSS qui prend de la place sur un volume ?

Confirmez d’abord qu’il est censé exister sur ce volume (Task 9). S’il ne l’est pas, réduisez la taille maximale ou déplacez le stockage shadow — après coordination avec les exigences sauvegarde/restaure.

8) Comment scanner un partage réseau sans se faire détester ?

Exécutez le scan sur le serveur de fichiers, limitez la profondeur de récursion initiale et planifiez les scans profonds hors heures. Exportez les résultats et laissez les propriétaires décider de ce qui est supprimable.

9) Quel est le plus grand « ne faites pas ça » pour le nettoyage disque sur Windows ?

Ne supprimez pas n’importe quoi sous C:\Windows (surtout Installer et WinSxS) parce qu’un blog dit que c’est « sûr ». Utilisez des outils de servicing supportés et nettoyez plutôt les données applicatives.

10) Comment rendre cela reproductible pour mon équipe ?

Transformez les Tasks 1, 3/4, 5, 6 et 12 en un petit script qui écrit des CSV dans un emplacement connu et joignez-le aux runbooks d’incident. La reproductibilité est l’objectif principal.

Conclusion : prochaines étapes qui ne vous hanteront pas

Les applications « cleaner » racontent une histoire : l’utilisation disque est un mystère et seul leur bouton magique peut le résoudre. La production est l’opposé. L’utilisation disque se connaît. Ce ne sont que des fichiers, des timestamps et des propriétaires. PowerShell transforme « on manque d’espace » en une liste exploitable.

Faites ceci ensuite

1. Choisissez un hôte qui se remplit régulièrement et exécutez les Tasks 1, 4, 6 et 12. Sauvegardez le CSV.
2. Identifiez les 3 principaux coupables (répertoires ou types de fichiers) et assignez des propriétaires.
3. Implémentez une politique de rétention (logs, dumps, temp) avec un workflow de prévisualisation.
4. Relancez les mêmes commandes la semaine suivante et comparez. Si le même coupable revient, vous n’avez pas corrigé l’écrivain — seulement les preuves.
5. Écrivez-le dans votre runbook : « Quand disque bas : exécuter ces commandes, exporter ce CSV, contacter ces propriétaires. » Rendez-le volontairement ennuyeux.

Si vous voulez un système qui reste propre, arrêtez d’acheter du « clean ». Commencez à acheter du « mesuré ». PowerShell est la règle de mesure que vous avez déjà.