Mesurer l’espace d’une application avant de décider quoi conserver

2. Séparer taille des contenus et occupation du stockage

La somme des tailles des fichiers décrit les contenus comptés selon une méthode. L’occupation du stockage décrit une autre mesure. Conservez le libellé exact au lieu de renommer tout résultat « poids réel ». La documentation Microsoft de Disk Usage distingue notamment DirectorySize et DirectorySizeOnDisk ; cela justifie de garder les colonnes séparées plutôt que de comparer des nombres dont le sens diffère.

La documentation Windows de GetCompressedFileSizeW décrit une mesure tenant compte de la compression ou des fichiers épars lorsqu’ils sont concernés. Elle précise aussi qu’un chemin symbolique peut conduire à mesurer sa cible. Ces repères expliquent pourquoi une longueur de fichier, une occupation et une somme parcourant des liens ne sont pas interchangeables. Ils ne certifient pas le comportement de n’importe quel outil de mesure.

Pour comparer deux relevés, gardez le même périmètre, la même unité et les mêmes règles de parcours. Indiquez si les sous-dossiers sont inclus et comment les liens sont traités. Un résultat partiel doit le rester dans le compte rendu. N’appliquez pas un coefficient inventé pour convertir une taille logique en espace récupérable, et ne déduisez pas une anomalie du seul écart entre deux colonnes.

3. Distinguer dépendance partagée, lien et doublon de contenu

Un fichier peut être nécessaire à plusieurs usages, plusieurs noms peuvent désigner un même stockage, et deux fichiers indépendants peuvent avoir le même contenu. Ces trois situations demandent des preuves différentes. Le même nom, la même extension ou une taille égale ne démontre pas un doublon ; un contenu identique ne démontre pas non plus que l’une des références est devenue inutile.

Microsoft explique, pour le magasin de composants Windows WinSxS, que des fichiers peuvent sembler présents à plusieurs endroits par des liens physiques et que certaines mesures de dossier surestiment alors l’occupation. La documentation Disk Usage prévoit également un choix de comptage des occurrences liées physiquement. Ce cas système illustre une limite de méthode ; il ne prouve pas que les dossiers d’un projet quelconque sont liés de cette façon.

Avant d’attribuer un gain à un retrait envisagé, identifiez l’objet réellement stocké, les références qui le réutilisent et les fonctions qui en dépendent. Une bibliothèque commune ne doit pas être intégralement imputée à chacun des projets pour fabriquer plusieurs gains additionnables. Si le partage ou les liens restent inconnus, gardez le gain récupérable non établi. Aucun fichier système, dépendance partagée ou lien n’est modifié ici.

4. Qualifier la reconstruction avant de classer un artefact

Séparez les contenus que la personne a créés, les paramètres utiles à son travail et les résultats produits par un processus. Une sortie dite reproductible ne l’est pour votre décision que si ses entrées, la version de l’outil, les dépendances et la méthode de reconstruction sont disponibles. Une ancienne copie peut contenir l’unique version d’une pièce ou d’une configuration, même si son dossier ressemble à un résultat généré.

Pour chaque élément envisagé, notez ce qui permettrait de le retrouver, qui en est responsable et ce qui manque encore à cette preuve. Une référence de version ou une empreinte aide à identifier un contenu ; elle ne recrée pas ses octets. Un téléchargement annoncé comme possible peut rester une dépendance au réseau, à un compte ou à une version retirée. Le mot « cache » n’établit donc ni absence de donnée unique ni reconstruction garantie.

Le dossier de sauvegarde DOHM traite déjà la reprise et ses exclusions. Ici, reliez cette preuve de reconstruction au volume mesuré et au besoin actuel : élément unique à préserver, contenu reconstruisible dont les conditions sont établies, ou rôle encore inconnu. La troisième catégorie suspend la décision. Aucun test de restauration, téléchargement, réinstallation ou nettoyage n’est effectué pour cet article.

5. Préserver la version utilisée, le retour et les preuves nécessaires

Avant de proposer une rétention, identifiez la version actuellement utilisée, la version prévue pour revenir en arrière et les éléments nécessaires pour expliquer ou reconstruire ces états. Garder seulement le fichier le plus récent ne répond pas toujours à ces trois besoins. À l’inverse, conserver de nombreuses copies sans connaître leur rôle ne constitue pas une politique de retour.

Écrivez les dépendances de la preuve : manifeste, empreintes, contenu conservé, version et configuration. Si un manifeste renvoie à des fichiers identiques dans une autre version, cette version reste une dépendance de conservation. Retirer son dossier sans matérialiser ou rétablir ces références rendrait la preuve incomplète. Un petit registre peut donc protéger un ensemble volumineux ; sa taille ne mesure pas son importance.

La documentation Microsoft sur WinSxS rappelle que certains composants servent au retour ou à la réparation. Ce repère ne fournit pas de règle de rétention pour vos propres projets. La décision doit avoir un périmètre, un responsable et une justification adaptée. Un nom contenant « ancien », « temporaire » ou « sauvegarde » ne remplace aucune de ces preuves. Ce guide ne fixe aucun nombre universel de versions et ne donne aucune commande de suppression.

6. Budgéter l’opération puis distinguer réduction de contenus et gain libre

Avant une copie ou une production nouvelle, chiffrez le volume supplémentaire attendu au pic de l’opération : nouvelles sorties, copies temporaires et preuves qui devront rester. Définissez séparément une réserve libre pour la continuité de l’environnement. Le budget est acceptable si l’espace libre mesuré couvre ce besoin supplémentaire et la réserve retenue. Une opération qui remplace ensuite une ancienne sortie peut tout de même nécessiter de garder les deux pendant une étape.

Exercice entièrement fictif, en Gio pour toutes les lignes : un environnement dispose de 12 Gio libres. La variante A demanderait 5 Gio de copie et 2 Gio temporaires, avec une réserve choisie de 6 Gio : 5 + 2 + 6 = 13 Gio, au-delà des 12 disponibles ; elle est refusée. La variante B demanderait 3 + 2 + 6 = 11 Gio : elle respecte cette hypothèse et laisse une marge de 1 Gio. La réserve de 6 Gio est inventée pour l’exercice ; ce n’est ni une norme Windows ni une recommandation universelle.

Autre calcul fictif, après une décision de rétention distincte déjà justifiée : 2 Gio de contenus ne seraient plus conservés et 0,25 Gio de preuves nouvelles resteraient nécessaires. La réduction nette de contenus serait 2 − 0,25 = 1,75 Gio. Si l’espace libre global passe pourtant de 12 à 14 Gio, sa variation vaut 2 Gio ; elle ne doit pas être intégralement attribuée à cette décision sans expliquer l’activité des autres processus et la méthode d’occupation. Ces nombres ne décrivent aucune machine réelle et ne prescrivent aucun retrait.

Terminez par une décision explicable : conserver parce que le rôle est actif ou la preuve unique ; différer parce que la dépendance est inconnue ; préparer une rétention autorisée sur un périmètre établi ; ou refuser une nouvelle opération faute de budget. Notez les mesures et leurs limites sans publier identifiants, chemins personnels ou contenu des fichiers. Une empreinte et une liste de tailles restent des preuves documentaires, pas une autorisation de nettoyage.