Outil CLI
bysiber/cleardisk avatar
bysiber/cleardisk

ClearDisk : analyser l’espace disque avant de supprimer

bysiber/cleardisk offre une implémentation open source exploitable en conditions réelles avec une structure réutilisable.

692 étoiles43 forksSwiftMIT

En bref

De quoi s’agit-il ?
ClearDisk se présente comme un outil de nettoyage qui visualise les fichiers volumineux ; la valeur pratique repose sur la précision de l’analyse et la prudence de la suppression.
À qui s’adresse-t-il ?
cleardisk convient à une équipe qui accepte ses dépendances et ses limites documentées ; il ne convient pas à un déploiement qui exige des garanties absentes du README. Avant adoption, exécutez le chemin propre à ce dépôt, vérifiez les fichiers et commandes cités dans l’article, puis contrôlez le résultat observable et les permissions associées.
Puis-je l’utiliser commercialement ?
Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
Est-il encore maintenu ?
Oui. Les derniers commits datent d’il y a 5 jours.
En quel langage est-il écrit ?
Principalement Swift, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Cartographier les répertoires qui consomment l’espace

ClearDisk analyse 63 emplacements de cache développeur connus. Le README liste Xcode DerivedData, Archives, Simulators et d'autres chemins Xcode, ainsi que Swift PM, CocoaPods, Carthage, Homebrew, npm, Yarn, pnpm, Bun, Deno, pip, UV, Conda, Poetry, Gradle, Maven, Docker, Terraform, Go, Rust, etc. Le scanner d'artefacts de projet recherche les caches par projet dans 23 types de projets, notamment Node.js, Python, Swift, CocoaPods, Xcode, Go, Gradle, Maven, PHP, Ruby, Flutter, CMake, Terraform, .NET, Godot, Unity, Unreal, Haskell, Elixir, Zig et Crystal. Pour un projet Next.js, il peut afficher node_modules, .next et dist séparément.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour cleardisk, le contrôle utile consiste à relier cartographier les répertoires qui consomment l’espace à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Résultats d’analyse et catégories de fichiers

Lorsque vous nettoyez avec ClearDisk, les fichiers sont déplacés vers la corbeille, pas supprimés définitivement. L'application affiche des niveaux de risque : vert pour sûr, jaune pour prudent, rouge pour risqué, et elle avertit si Xcode est en cours d'exécution lorsque vous essayez de nettoyer les caches liés à Xcode. Chaque entrée de cache inclut une description lisible, par exemple "Paquets Swift téléchargés. Re-téléchargés à la prochaine compilation." La vue DerivedData décompose quels projets occupent de l'espace. Le README dit que ces fichiers peuvent être reconstruits ou re-téléchargés, mais ne garantit pas le succès pour chaque type de cache.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour cleardisk, le contrôle utile consiste à relier résultats d’analyse et catégories de fichiers à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Suppression : confirmation et récupération possible

ClearDisk pèse 590 Ko et a zéro dépendance. Il prétend ne pas collecter de données, pas d'analyses et aucun accès réseau. Le README indique que l'application ne se connecte jamais à Internet et que le code source est ouvert pour vérification. Il fonctionne uniquement sur un minuteur de 5 minutes ou lorsque la fenêtre contextuelle de la barre de menus est ouverte, sans processus en arrière-plan. La pile technologique est Swift avec SwiftUI et Swift Package Manager, environ 1 500 lignes de code. Ces chiffres proviennent du README et n'ont pas été mesurés indépendamment.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour cleardisk, le contrôle utile consiste à relier suppression : confirmation et récupération possible à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Permissions macOS et cas des caches

L'installation est documentée de trois manières : Homebrew avec un tap et un cask, un téléchargement DMG depuis la page des releases, et une compilation depuis les sources. La compilation depuis les sources nécessite Xcode Command Line Tools et macOS 14+. La version DMG n'est pas notarisée, donc macOS bloquera le premier lancement. Le README explique deux solutions : utiliser les Réglages Système pour cliquer sur "Ouvrir quand même" ou exécuter xattr -cr sur l'application. La méthode Homebrew gérerait le flag de quarantaine. Le README ne précise pas la taille du DMG ni la date de sortie exacte.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour cleardisk, le contrôle utile consiste à relier permissions macos et cas des caches à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Installation, compilation et état du projet

ClearDisk analyse toutes les cinq minutes une liste fixe de répertoires de cache développeur connus. Il ne fait pas d'analyse complète du disque ni d'indexation de fichiers. Le README montre des exemples comme ~/Library/Developer/Xcode/DerivedData comme sûr, ~/Library/Developer/Xcode/Archives comme prudent, et ~/Library/Containers/com.docker.docker comme risqué. Lorsque la fenêtre contextuelle est ouverte, il peut également analyser à la demande. Les suppressions vont toujours à la corbeille, vous pouvez donc récupérer les fichiers avant de vider la corbeille.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour cleardisk, le contrôle utile consiste à relier installation, compilation et état du projet à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Une méthode de vérification sans risque

ClearDisk est sous licence MIT, copyright 2026 Kadir Can Ozden. La licence accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies, le logiciel étant fourni "tel quel" et sans garantie. Le README ne fournit pas de benchmarks de performance, de nombres d'utilisateurs ou d'audits de sécurité. Il ne décrit pas non plus comment la prévision de stockage calcule la régression linéaire au-delà de l'utilisation de 90 jours d'historique, ni ne précise quelles versions des gestionnaires de paquets pris en charge ont été testées. Ces points ne sont pas établis par le matériel source disponible.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour cleardisk, le contrôle utile consiste à relier une méthode de vérification sans risque à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Conclusion éditoriale

cleardisk convient à une équipe qui accepte ses dépendances et ses limites documentées ; il ne convient pas à un déploiement qui exige des garanties absentes du README. Avant adoption, exécutez le chemin propre à ce dépôt, vérifiez les fichiers et commandes cités dans l’article, puis contrôlez le résultat observable et les permissions associées.

Sources officielles

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Notes de la communauté

Notes de la communauté