# Choisir un analyseur de disque au-delà de DaisyDisk
> Comparez les analyseurs treemap et en terminal, et comprenez pourquoi deux scanners corrects affichent des totaux différents sur le même volume.
Published: 2026-07-21 | Updated: 2026-08-08
Un analyseur de disque répond à une question précise : quels dossiers portent le
poids. Le point intéressant est que deux analyseurs corrects pointés sur le même volume
affichent des totaux différents, et aucun des deux n'est cassé. Les clones APFS, les
liens physiques, les fichiers creux, les instantanés locaux et les dossiers que le
scanner n'a pas le droit de lire déplacent chacun le chiffre dans une direction
prévisible. Le choix est donc vraiment un double choix : quelle forme de carte vous
lisez le plus vite, et si vous comprenez ce que le total devant vous compte vraiment.
## La forme de la carte est la vraie différence
Chaque analyseur ici part de l'occupation du disque et fait des choix de comptabilisation
et de dessin différents. DaisyDisk utilise des anneaux sunburst concentriques.
GrandPerspective et Mole utilisent des treemaps, où chaque dossier est un rectangle
proportionnel à sa taille. OmniDiskSweeper affiche une liste triée, du plus grand au
plus petit. ncdu dessine cette liste dans un terminal. macOS lui-même montre une barre
empilée de catégories, sans aucun chemin.
Ce qu'un outil fait après que vous ayez trouvé l'élément compte tout autant. Révéler
dans le Finder laisse la décision entre vos mains et coûte un basculement d'application.
Supprimer sur place place tout le fardeau sur le chemin de récupération : un outil qui
supprime sans passer par la Corbeille ne devrait viser que des données que vous pouvez
reconstruire.
## Les options
### La vue Stockage intégrée, souvent suffisante
Menu Apple, Réglages Système, Général, Stockage. La
[documentation des réglages de stockage](https://support.apple.com/guide/mac-help/change-storage-settings-mchl3d437fbc/mac)
d'Apple décrit ce que vous obtenez : un histogramme de l'espace utilisé et disponible
par catégorie, le détail par volume, et trois recommandations (Stocker dans iCloud,
Optimiser le stockage, Vider la Corbeille automatiquement). Le bouton d'info à côté
d'une catégorie ouvre les fichiers qu'elle contient, et Documents est triable par nom,
type, dernier accès et taille.
C'est un vrai analyseur pour un cas précis : une seule catégorie lourde, surtout des
documents et des médias. Sa limite est Données système, et l'
[article sur le stockage](https://support.apple.com/en-us/102624)
d'Apple indique que macOS gère cette catégorie et que vous ne le pouvez pas. Quand le
poids s'y trouve, la vue intégrée vous a tout dit, et une carte au niveau des chemins
commence à valoir le détour.
### DaisyDisk pour un sunburst soigné
[DaisyDisk](https://daisydiskapp.com/) est l'implémentation de référence de l'analyseur
visuel sur macOS, et il est activement maintenu. La version 4.34.2 est sortie en juillet
2026, après que la 4.34 ait ajouté la prise en compte des clones APFS. Son jeu de
fonctions actuel couvre la carte sunburst, l'aperçu avec la barre d'espace, un
collecteur dans lequel vous glissez des éléments avant de les supprimer en lot, un mode
d'analyse administrateur pour les fichiers qu'un utilisateur normal ne peut pas lire,
l'analyse des disques cloud, la gestion des instantanés, et la détection des liens
physiques et des clones. Il nécessite macOS 10.13 ou plus récent.
La licence est un achat unique couvrant plusieurs Mac personnels, avec une fenêtre de
remboursement ; consultez la
[page de tarifs](https://daisydiskapp.com/support/pricing/)
pour les conditions actuelles. La limite est volontaire : il cartographie et supprime,
mais ne sait pas qu'un dossier appartient à une app que vous avez désinstallée ni qu'un
cache se reconstruit au prochain lancement. L'attribution reste votre travail.
### GrandPerspective pour un treemap open source
[GrandPerspective](https://grandperspectiv.sourceforge.net/) dessine des treemaps
macOS depuis près de deux décennies et continue de sortir, la version 3.7.2 ayant été
publiée en mai 2026 sous la GNU General Public License. Au-delà de la carte, il propose
plusieurs schémas de couleurs (par nom, extension, taille, date de modification), le
filtrage, la prise en charge des liens physiques, l'analyse du stockage cloud, la
compression de scan avec rafraîchissement rapide, l'export en image ou en texte, et
onze localisations. Il nécessite macOS 11 ou plus.
Il est gratuit sur SourceForge et aussi vendu sur l'App Store ; le projet indique que
vous obtenez la même app dans les deux cas, donc la fiche payante est une façon de
soutenir le développeur. L'interface montre son âge à côté d'une app commerciale. Si
cela ne vous gêne pas, c'est là que la plupart des gens peuvent s'arrêter.
### OmniDiskSweeper pour une simple liste triée
The Omni Group propose encore [OmniDiskSweeper](https://www.omnigroup.com/more) en
logiciel gratuit, décrit sur sa propre page comme affichant les fichiers d'un disque du
plus grand au plus petit et vous permettant de les mettre à la corbeille ou de les
ouvrir. Il n'y a aucune carte, et c'est précisément l'attrait : une colonne de tailles
n'a aucune courbe d'apprentissage.
Son statut de maintenance mérite une note honnête. Il figure sur la page des projets
secondaires d'Omni plutôt que dans la ligne de produits principale, et l'index public
des téléchargements liste encore des builds contre d'anciennes versions de macOS. Le
blog d'Omni mentionne un OmniDiskSweeper mis à jour en septembre 2025, et le canal de
builds de test a publié des builds 1.16 ce mois-là, exigeant macOS 14 ou plus. Traitez-le
comme maintenu lentement, et vérifiez que le build que vous obtenez tourne sur votre
version de macOS.
### ncdu pour les terminaux et les disques distants
[ncdu](https://dev.yorhel.nl/ncdu) est un analyseur d'occupation de disque sous licence
MIT avec une interface en mode texte, et le seul outil ici qui fonctionne de façon
identique en SSH. Deux lignes sont actuelles : la réécriture en Zig (2.9.2, octobre
2025) et une version LTS en C (1.22, mars 2025). Il s'installe sur macOS via Homebrew
ou MacPorts. Il prend en charge le scan parallèle, l'export et l'import JSON ainsi
qu'un format binaire compressé, la suppression depuis l'interface, et il distingue la
taille apparente de l'occupation réelle, qui est exactement la distinction de la
section suivante.
Utilisez-le pour la scriptabilité et l'accès distant, pas pour le confort. Supprimer
depuis un navigateur en terminal est impitoyable ; servez-vous-en pour localiser, puis
retirez via le Finder sauf si vous êtes certain.
### L'onglet Analyse de Mole pour une carte dans une boîte à outils plus large
[Mole](https://mole.fit/) dessine un treemap de tout le disque avec un forage en un clic et un fil
d'Ariane ; un clic droit propose Déplacer vers la Corbeille (via la Corbeille système,
donc récupérable) ou Révéler dans le Finder, et les racines de navigation comme `/`,
`/Users` et `/Applications` ne peuvent pas être mises à la corbeille. Les entrées qu'il
ne peut pas dimensionner sont signalées par un badge et une nouvelle tentative au lieu
de disparaître du total, ce qui répond à un mode de défaillance décrit plus bas. Les
limites méritent d'être dites clairement : la licence est un achat unique pour deux Mac
sous macOS 14 ou plus, les résultats sont mis en cache 24 heures donc un total périmé
est possible, et l'app Mac n'a pas d'export JSON, que le CLI open source gratuit
fournit via `mo analyze --json`.
## Sous le capot : pourquoi deux analyseurs ne s'accordent pas sur le même disque
Beaucoup des différences ci-dessous viennent d'un choix de comptabilisation légitime
de l'auteur du scanner, même si un écart inexpliqué peut encore être un bug.
**Clones APFS.** Copier un fichier dans le Finder sur APFS ne duplique pas ses blocs ;
la copie les partage jusqu'à ce qu'un des deux côtés soit modifié. Un analyseur qui
additionne les tailles logiques des fichiers compte les deux copies en entier et
signale plus que ce que le volume contient.
**Liens physiques.** Un inode peut porter plusieurs noms. Un parcours qui compte chaque
nom gonfle le total ; un parcours qui enregistre chaque paire `(device, inode)` peut
distinguer les octets partagés des octets uniques. Les dépôts de paquets et les
arborescences de développement avec du contenu lié peuvent donc paraître bien plus
gros dans un outil que dans un autre.
**Fichiers creux.** La taille apparente d'un fichier peut largement dépasser ses blocs
alloués. Le cas classique est `Docker.raw`, qui affiche une grande taille virtuelle tout
en occupant beaucoup moins. Lire `size` et lire les blocs alloués donne des réponses
différentes.
**Instantanés et espace purifiable.** Les instantanés locaux de Time Machine et les
données purifiables occupent le volume mais n'appartiennent à aucun dossier qu'un
parcours peut visiter. Aucune somme sur l'arbre des dossiers ne les inclura jamais,
donc l'écart entre le total d'un analyseur et le chiffre du Finder est souvent
exactement cela.
**Ce que le scanner ne peut pas lire.** Les dossiers exigeant l'accès complet au disque
ou root ne peuvent pas être interrogés via `stat` par un processus non privilégié. Le
danger n'est pas l'échec, c'est le silence : une sous-arborescence illisible qui
contribue zéro ressemble à une sous-arborescence vide. Les modes d'analyse
administrateur et les badges explicites d'entrées non dimensionnées existent pour
cette raison.
**Liens symboliques.** Les suivre compte les octets de la cible là où ils ne vivent pas
et risque de compter les mêmes données deux fois. Résoudre sans descendre est le défaut
plus sûr, et la différence se voit surtout dans les arborescences de développement.
Puis il y a la méthode de scan. Un parcours en espace utilisateur avec `fts(3)` ou
`getattrlistbulk` garde le parcours dans l'app, ce qui donne à l'auteur un contrôle
direct sur la progression, l'annulation et le comptage des liens physiques. Déléguer à
`du(1)` hérite d'un parcours éprouvé et de ses choix de comptabilisation, mais
intégrer une progression granulaire et des échecs partiels est plus difficile. Une
seule invocation de `du` peut rapporter une arborescence ; un outil n'a pas besoin
d'un sous-processus par dossier. Les outils qui mélangent un parcours interne au
processus avec des replis sur `du` peuvent encore hériter de deux modèles de
comptabilisation, ce qui est une autre raison pour laquelle les totaux peuvent différer.
Ces branches expliquent beaucoup de désaccords honnêtes entre analyseurs. Un outil devrait tout de même indiquer quel modèle de comptabilisation son total utilise.
## Comparaison rapide
| Outil | Forme de carte | Après la découverte de l'élément | Modèle de licence |
| --- | --- | --- | --- |
| Réglages Stockage | Barre par catégorie, sans chemins | Suppression depuis le navigateur de catégories | Inclus avec macOS |
| DaisyDisk | Anneaux sunburst | Collecteur, puis suppression en lot | Achat unique |
| GrandPerspective | Treemap | Révéler ou supprimer, plus export | Open source, GPL |
| OmniDiskSweeper | Liste triée par taille | Corbeille ou ouvrir | Gratuit |
| ncdu | Liste en terminal | Suppression sur place, export JSON | Open source, MIT |
| Mole | Treemap avec forage | Révéler ou Corbeille, racines protégées | Achat unique |
Aucune méthode n'est intrinsèquement fausse. Un outil qui mélange un parcours interne au processus avec un repli sur `du` peut hériter de deux modèles de comptabilisation, donc le résultat a besoin d'une définition explicite.
## Une méthode reproductible pour trouver le poids
Lisez d'abord le conteneur. Comparez ce que `df` rapporte avec la vue de capacité APFS
et le panneau Stockage, pour savoir si vous faites face à une vraie pression physique
ou à un artefact de classification comme les instantanés et l'espace purifiable.
Seulement ensuite lancez un analyseur. N'accordez que l'accès avec lequel vous êtes à
l'aise, et préférez un outil qui marque les régions illisibles au lieu de les compter
silencieusement comme zéro.
Descendez dans la plus grande branche jusqu'à un dossier dont vous pouvez nommer le
propriétaire. Comparez son total à une autre mesure avant d'agir : `du -sh` sur le même
chemin, ou Lire les informations dans le Finder. Quand elles divergent, la raison est
souvent dans la liste ci-dessus, et savoir laquelle vous dit si l'espace est récupérable
du tout.
Supprimez d'abord les données remplaçables et gardez-les dans la Corbeille jusqu'à ce
que l'app concernée fonctionne encore. Pour la version manuelle de ce flux, voir
[comment trouver et supprimer les gros fichiers](https://mole.fit/fr/blog/how-to-find-large-files-on-mac) ;
quand le poids tombe dans une catégorie sans aucun chemin, voir
[ce que sont vraiment les Données système](https://mole.fit/fr/blog/what-is-system-data-on-mac).
---
Canonical HTML page: https://mole.fit/fr/blog/daisydisk-alternative
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
