Disque plein sur Mac malgré l'espace disponible : pourquoi ?
Le Finder affiche 40 Go disponibles, ton build échoue faute de place. Le mécanisme, et comment libérer de l'espace disque sur Mac.
Mis à jour le 2026-08-13
La contradiction
Le Finder affiche 42 Go disponibles. Xcode refuse de compiler. Docker répond no space left on device. df -h donne raison au Finder, du contredit tout le monde. Rien n'est cassé, et personne ne te ment : trois outils différents répondent à trois questions différentes.
En bref : macOS compte comme disponible l'espace qu'il pourrait libérer, sans le libérer. L'essentiel de cet espace est retenu par des instantanés APFS locaux. Tant qu'ils n'ont pas expiré ou que tu ne les as pas supprimés, cet espace appartient à l'instantané, pas à toi, et un programme qui demande un bloc au noyau se voit répondre non.
Vois-le par toi-même
Deux commandes, trente secondes. Lance les deux et compare.
$ df -h /System/Volumes/DataLa réponse du noyau lui-même. C'est le chiffre que reçoit ton compilateur. Regarde Avail, pas Capacity.
$ diskutil apfs list | grep -A2 SnapshotListe les instantanés APFS locaux du volume, s'il y en a.
$ tmutil listlocalsnapshots /La même chose, en plus lisible. Chaque ligne est un moment que Time Machine a conservé en local.
Pourquoi « purgeable » ne veut pas dire libre
Le chiffre « disponible » du Finder signifie en réalité « blocs libres plus blocs purgeables ». Purgeable veut dire que macOS pense pouvoir récupérer cet espace si quelque chose le réclame avec assez d'insistance : données d'instantanés au-delà de leur durée de conservation, fichiers iCloud en cache et quelques autres catégories.
Le problème, c'est que cette récupération n'est ni instantanée ni garantie. Le noyau libère l'espace purgeable sous la pression de la mémoire et du disque, à son propre rythme. Un système de build qui demande 8 Go en une seule allocation ne déclenche pas ce mécanisme en douceur : il échoue, tout simplement. Tu te retrouves donc avec un disque plein et une fenêtre du Finder qui assure que tout va bien.
| Ce que tu lances | Ce qui est compté | Réponse typique |
|---|---|---|
| Finder → À propos de ce Mac | Libre + purgeable | Optimiste |
| df -h | Blocs libres, tels que le noyau les voit | Ce que reçoit ton compilateur |
| du -sh ~/dev | Taille apparente des fichiers, clones comptés deux fois | Très pessimiste |
| tmutil listlocalsnapshots / | Les instantanés qui retiennent la différence | La vraie réponse |
Récupérer l'espace
Dans l'ordre. Arrête-toi à la première étape qui te donne assez de place : inutile d'aller plus loin que nécessaire.
1. Allège les instantanés locaux. C'est celle-ci qui règle le problème, en général.
$ tmutil thinlocalsnapshots / 100000000000 4Demande à macOS de libérer jusqu'à ~100 Go en supprimant des instantanés locaux, au niveau d'urgence 4 (le plus agressif). Seuls les points de restauration locaux sont supprimés : tes sauvegardes Time Machine sur disque externe ou réseau ne sont pas touchées.
2. Si tu préfères les supprimer un par un plutôt qu'en bloc :
$ tmutil deletelocalsnapshots 2026-08-01-120000Supprime un instantané d'après sa date exacte, telle qu'affichée par listlocalsnapshots.
3. Ensuite, les gouffres habituels du développeur, ceux qui ont rempli les instantanés au départ :
$ rm -rf ~/Library/Developer/Xcode/DerivedData/*Fichiers intermédiaires de build d'Xcode. Se reconstruit tout seul. Souvent 10–60 Go.
$ xcrun simctl delete unavailableLes simulateurs iOS des runtimes que tu n'as plus installés.
$ docker system prune -a --volumesImages, conteneurs et volumes Docker. Relis celle-ci deux fois : --volumes supprime le contenu des bases de données.
$ brew cleanup --prune=allAnciens téléchargements et anciennes versions de Homebrew.
Pourquoi du ment aussi, dans l'autre sens
du -sh node_modules peut annoncer 800 Mo alors que le supprimer ne libère presque rien. Sur APFS, pnpm et Bun remplissent node_modules en clonant depuis un magasin partagé plutôt qu'en copiant. Les blocs sont partagés avec le magasin ; les inodes diffèrent, le nombre de liens vaut 1 des deux côtés, et chaque côté annonce la taille complète.
Aucun appel système ne donne cette information à un coût compatible avec le parcours de millions d'entrées de répertoire. C'est pourquoi un outil honnête te donne une fourchette plutôt qu'un chiffre : un plancher qu'il peut garantir, et un plafond qu'il atteindrait si rien n'était partagé.
Alléger les instantanés supprime-t-il mes sauvegardes Time Machine ?
Non. Les instantanés locaux sont des points de restauration temporaires conservés sur le disque interne entre deux sauvegardes. Tes sauvegardes sur un disque externe ou réseau sont distinctes et ne sont pas concernées.
Pourquoi l'espace n'est-il pas revenu tout de suite ?
La suppression des instantanés est asynchrone, et le décompte de l'espace libre du volume peut avoir quelques secondes de retard. Relance `df -h` après un instant. Si rien n'a bougé, un autre instantané retient les mêmes blocs.
Peut-on empêcher macOS de prendre des instantanés locaux ?
Tu peux désactiver complètement Time Machine, ce qui les arrête, mais tu perds aussi tes sauvegardes automatiques : mauvais calcul pour un problème d'espace disque. Alléger les instantanés de temps en temps est la meilleure réponse.
J'ai libéré 30 Go et df affiche toujours la même chose. Pourquoi ?
Presque toujours un instantané pris après la création des fichiers mais avant leur suppression. Allège les instantanés et vérifie à nouveau.
La version automatique
Tout ce qui précède marche, ne coûte rien et continuera de marcher. Loupe fait la même chose sur tous les projets du disque à la fois, et montre ce que chaque suppression coûtera à reconstruire avant que tu l'acceptes.
Guides voisins