Le disque de votre Mac est plein de snapshots, pas de fichiers. Voici comment le prouver

Vous supprimez 40 Go de vidéos, vous videz la Corbeille, et le chiffre d'espace libre bouge à peine. Ou l'inverse : le Finder annonce joyeusement 300 Go disponibles, et l'installeur de macOS 27 refuse de démarrer faute de place. Les deux sont le même phénomène. Sous APFS, « l'espace libre » est un chiffre négocié, et les parties du disque invisibles depuis le Finder — snapshots, contenu purgeable et volumes voisins partageant le même conteneur — expliquent l'écart. Avec une mise à jour majeure prévue le 14 septembre, mieux vaut savoir lire les vrais chiffres.

Points clés

• df et le Finder mentent par construction. Le chiffre qui compte pour un installeur est l'espace libre du conteneur APFS, que vous lisez avec diskutil info /.
• Le volume système de votre Mac possède un snapshot qu'il ne faut jamais supprimer — le volume système scellé et signé depuis lequel vous avez démarré. Il apparaît dans diskutil mais pas dans tmutil, et cette différence résume tout le diagnostic.
• Les snapshots locaux de Time Machine sont le coupable habituel quand l'espace disparaît. Ils sont supprimés au bout de 24 heures ou quand l'espace vient à manquer, mais ce seuil de « manque » est plus bas que vous ne le souhaiteriez.
• L'espace purgeable est un espace bien réel que macOS libère sous pression — mais une mise à jour majeure ne crée pas forcément le bon type de pression au bon moment.
• Les autres volumes du conteneur comptent aussi. Sur ce Mac, Preboot occupe 9 Go et le volume VM 18 Go de swap, et aucun des deux n'apparaît nulle part dans le Finder.

Quatre chiffres, un seul disque

Commencez par constater l'écart plutôt que de le contester. Sur ce Mac, qui tourne sous macOS 26.5.2 avec un SSD de 1 To :

$ df -h / /System/Volumes/Data
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   395Gi     3%    /
/dev/disk3s5     926Gi   493Gi   395Gi    56%    /System/Volumes/Data

Deux volumes, chacun prétendant faire 926 Gio, chacun annonçant les mêmes 395 Gio disponibles. Aucun des deux n'a tort et aucun ne dit toute la vérité : les volumes APFS partagent un conteneur et s'y développent, si bien que la « taille » est celle du conteneur et l'« espace disponible » est l'espace libre du conteneur, répété pour chaque volume.

Demandez maintenant directement au conteneur :

$ diskutil apfs list disk3 | grep -E "Capacity|Volume Disk|Consumed"
    Size (Capacity Ceiling):      994662584320 B (994.7 GB)
    Capacity In Use By Volumes:   570712170496 B (570.7 GB) (57.4% used)
    Capacity Not Allocated:       423950413824 B (424.0 GB) (42.6% free)
    |   APFS Volume Disk (Role):   disk3s1 (System)
    |   Capacity Consumed:         12568809472 B (12.6 GB)
    |   APFS Volume Disk (Role):   disk3s2 (Preboot)
    |   Capacity Consumed:         8995532800 B (9.0 GB)
    |   APFS Volume Disk (Role):   disk3s3 (Recovery)
    |   Capacity Consumed:         1304084480 B (1.3 GB)
    |   APFS Volume Disk (Role):   disk3s5 (Data)
    |   Capacity Consumed:         529380937728 B (529.4 GB)
        APFS Volume Disk (Role):   disk3s6 (VM)
        Capacity Consumed:         18253713408 B (18.3 GB)

Voilà le décompte honnête. Cinq volumes, et un seul d'entre eux — Data, avec 529 Go — est consultable dans le Finder. Preboot pèse 9 Go. Le volume VM pèse 18 Go. À eux deux, ils occupent plus d'espace que le dossier Documents de la plupart des utilisateurs, et aucune interface de gestion du stockage du Mac ne vous les montrera.

Le seul chiffre qui intéresse un installeur :

$ diskutil info / | grep "Container Free Space"
   Container Free Space:      423.9 GB (423947014144 Bytes)

Utilisez celui-là. S'il diffère de celui du Finder de plusieurs dizaines de gigaoctets, tout ce qui suit explique où est passée la différence.

Le snapshot qu'il ne faut jamais supprimer

Lancez la commande évidente, et le résultat a de quoi inquiéter :

$ diskutil apfs listSnapshots /
Snapshot for disk3s1s1 (1 found)
|
+-- B8B12570-09B5-402F-99BB-F383487AD69D
    Name:        com.apple.os.update-5B92CE4BA1034457A0921532291F4A4AD939CBE...
    XID:         17495484
    Purgeable:   No
    NOTE:        This snapshot limits the minimum size of APFS Container disk3

Un snapshot, marqué comme non purgeable, décrit explicitement comme limitant la taille minimale du conteneur. La tentation est grande d'en conclure que c'est lui qui dévore votre disque.

Ce n'est pas le cas. C'est le système d'exploitation que vous utilisez actuellement.

Depuis macOS 11, le volume système est scellé et vérifié cryptographiquement, et le Mac ne démarre pas le volume — il démarre un snapshot de celui-ci. diskutil apfs list le dit explicitement :

|   APFS Volume Disk (Role):   disk3s1 (System)
|   Snapshot:                  B8B12570-09B5-402F-99BB-F383487AD69D
|   Snapshot Disk:             disk3s1s1
|   Snapshot Mount Point:      /
|   Snapshot Sealed:           Yes

Snapshot Sealed: Yes, monté sur /. Le préfixe com.apple.os.update- est la convention de nommage du snapshot créé lors de l'application d'une mise à jour du système. Le supprimer n'est pas une opération de nettoyage ; c'est supprimer le système en cours d'exécution. macOS refusera généralement de le faire, mais « généralement » n'est pas le mot que vous avez envie de voir entre vous et un Mac qui ne démarre plus.

Le signe qui le distingue d'un snapshot que vous pouvez supprimer :

$ tmutil listlocalsnapshots /
Snapshots for disk /:

$ tmutil listlocalsnapshots /System/Volumes/Data
Snapshots for disk /System/Volumes/Data:

Les deux sont vides. tmutil ne signale que les snapshots de Time Machine — ceux créés pour les sauvegardes, ceux qu'il est sans risque d'alléger. diskutil signale, lui, tous les snapshots APFS, y compris le snapshot système scellé. Si diskutil affiche un snapshot que tmutil ne montre pas, ce n'est pas à vous de le supprimer.

Règle simple : agissez sur ce que tmutil vous montre. Lisez diskutil pour comprendre, pas pour décider.

Les snapshots qui dévorent réellement votre disque

Time Machine crée des snapshots locaux sur le Mac lui-même, pas seulement sur le disque de sauvegarde, et ce sont eux qui répondent le plus souvent à la question « où sont passés ces 80 Go ? ».

Le mécanisme est simple, la conséquence ne l'est pas. Un snapshot conserve l'état du volume à un instant donné. Modifiez un fichier ensuite, et les blocs d'origine doivent être conservés en plus des nouveaux. Supprimez une vidéo de 20 Go qui existait au moment du snapshot, et l'espace ne revient pas — le snapshot y fait toujours référence. Les fichiers créés et supprimés entre deux snapshots font exception : ceux-là ont réellement disparu et sont irrécupérables.

Le ménage effectué par Apple obéit à deux logiques, l'âge et la pression : les snapshots de plus de 24 heures sont supprimés, et les plus anciens sont purgés quand l'espace libre devient critique. Entre ces deux règles, un Mac avec Time Machine actif et une journée chargée en mouvements de fichiers peut retenir des dizaines de gigaoctets qu'il ne libérera que lorsque l'horloge ou le seuil de pression le décidera.

Ce Mac n'a aucune destination Time Machine configurée :

$ tmutil destinationinfo
tmutil: No destinations configured.

— ce qui explique que sa liste de snapshots soit vide, et que son volume Data affiche No snapshots for disk3s5. Si Time Machine est configuré sur le vôtre (et il devrait l'être — voir le guide de stratégie de sauvegarde actuel), attendez-vous à en trouver plusieurs.

Les visualiser dans Utilitaire de disque

Si vous préférez éviter le Terminal : ouvrez Utilitaire de disque, puis Présentation → Afficher tous les appareils, sélectionnez le volume Data, et activez Présentation → Afficher les snapshots APFS. Vous obtenez une liste avec les tailles et un menu contextuel pour supprimer les snapshots un par un. Le conseil de Howard Oakley mérite d'être répété — conservez le plus récent, car les supprimer tous peut forcer Time Machine à repartir sur un cycle de sauvegarde complet la prochaine fois.

Les alléger délibérément

La méthode officiellement prise en charge pour récupérer l'espace des snapshots est thinlocalsnapshots, qui prend un point de montage, un nombre d'octets à essayer de libérer, et un niveau d'urgence de 1 à 4 :

# Ask macOS to free roughly 20 GB from Data volume snapshots, highest urgency
sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4

Le niveau d'urgence 4 est le plus agressif et supprimera tous les snapshots sauf le plus récent si nécessaire. C'est exactement ce que macOS s'impose lui-même sous pression d'espace ; le lancer manuellement revient simplement à anticiper.

Pour supprimer un snapshot précis plutôt que d'alléger par volume :

# List them first
tmutil listlocalsnapshots /System/Volumes/Data

# Delete one by its date stamp
sudo tmutil deletelocalsnapshots 2026-09-10-140233

Et l'équivalent de plus bas niveau, qui fonctionne sur n'importe quel snapshot APFS par UUID, XID ou nom :

diskutil apfs deleteSnapshot disk3s5 -uuid <snapshot-UUID>

Utilisez tmutil dès que possible. diskutil apfs deleteSnapshot pointera sans sourciller vers le mauvais volume, et le mauvais volume ici, c'est celui depuis lequel vous avez démarré.

Ce que « purgeable » signifie réellement

macOS signale une partie de l'espace comme purgeable : du contenu qu'il est prêt à supprimer automatiquement quand le disque se remplit. Cela inclut les snapshots ayant dépassé leur fenêtre de rétention, les fichiers iCloud mis en cache qui existent déjà dans le cloud, les originaux Photos déjà téléversés, les médias téléchargés et divers caches.

L'espace purgeable est réellement récupérable — mais la récupération est réactive. macOS le libère quand quelque chose réclame de l'espace, et cette demande doit se présenter sous une forme que macOS sait reconnaître. Un gros cp la déclenchera ; un installeur qui vérifie l'espace libre en amont et refuse avant même d'écrire quoi que ce soit, peut-être pas.

C'est exactement le scénario d'échec du jour de la mise à jour : des centaines de gigaoctets purgeables, un installeur qui refuse de démarrer, et aucun moyen évident de convaincre le système d'agir. La méthode simple et sûre pour forcer les choses consiste à créer une véritable pression :

# Write a large file to force macOS to reclaim purgeable space, then delete it
mkfile -n 30g ~/Desktop/ballast
rm ~/Desktop/ballast

mkfile -n crée un fichier sparse, donc l'écriture elle-même est rapide ; c'est l'allocation qui déclenche la récupération. Supprimez-le dès que le chiffre d'espace libre bouge.

Les volumes dont personne ne parle

Deux des cinq volumes du conteneur méritent qu'on s'y attarde, car ils grossissent et personne n'y pense.

Preboot — 9,0 Go sur ce Mac. Il contient les ressources de démarrage de chaque installation de système que le conteneur a connue, y compris les environnements de récupération et le matériel cryptographique propre à chaque volume. Il grossit à chaque mise à jour majeure et n'est pas nettoyé automatiquement. Ce n'est pas non plus quelque chose à nettoyer à la main : supprimer le mauvais élément y produit un Mac qui ne démarre plus. Considérez-le comme le coût fixe des mises à jour que vous avez effectuées.

VM — 18,3 Go sur ce Mac. C'est le swap. Vous pouvez voir exactement ce qu'il contient :

$ ls -lh /System/Volumes/VM/
-rw-------  1 root  wheel   1.0G ... swapfile0
-rw-------  1 root  wheel   1.0G ... swapfile1
-rw-------  1 root  wheel   1.0G ... swapfile10
...

$ sysctl vm.swapusage
vm.swapusage: total = 17408.00M  used = 16258.81M  free = 1149.19M  (encrypted)

Dix-sept fichiers de swap d'un gigaoctet chacun, dont 16 Go utilisés. macOS agrandit le swap à la demande et ne le réduit pas volontiers ; un redémarrage est le moyen fiable de le récupérer. Si vous manquez de place avant une mise à jour, redémarrer le Mac n'a rien d'une superstition — cela restitue réellement plusieurs gigaoctets sur une machine allumée depuis des semaines.

De combien d'espace macOS 27 a-t-il besoin ?

Les minimums annoncés par Apple pour les mises à jour majeures se situent historiquement entre 25 et 45 Go selon la version de départ, et l'installeur complet à lui seul pèse environ 17 Go — celui de Tahoe fait 17 953 734 Kio d'après le catalogue des installeurs, et Golden Gate devrait être dans la même catégorie.

Le chiffre pratique est plus élevé que celui annoncé. Prévoyez 60 Go d'espace libre dans le conteneur avant de lancer une mise à jour majeure, pour trois raisons : le téléchargement de l'installeur, l'espace de travail dont l'installation a besoin, et le snapshot que macOS prend de votre système avant la mise à jour, lequel ne peut pas être allégé pendant le processus.

Vérifiez-le, ne l'estimez pas :

diskutil info / | grep "Container Free Space"

L'autre chiffre optimiste : iCloud et Photos

Deux fonctionnalités signalent délibérément l'espace d'une manière qui flatte le disque.

« Optimiser le stockage Mac » d'iCloud Drive évince le contenu des fichiers que vous n'avez pas utilisés récemment, ne laissant qu'un fantôme qui se retélécharge à la demande. Le Finder affiche le fichier à sa taille complète ; le disque, lui, n'en garde presque rien. C'est un excellent comportement, jusqu'à ce qu'un installeur demande combien d'espace est disponible, car le contenu évincé est compté comme purgeable et non comme libre.

« Optimiser le stockage Mac » de Photos fait la même chose pour les originaux, en ne gardant localement que des versions allégées. Une photothèque de 200 Go peut n'occuper que 30 Go sur le disque, et peut se retélécharger en masse silencieusement si vous ouvrez la mauvaise vue au mauvais moment.

Aucune des deux n'est un problème à corriger. Elles expliquent en revanche pourquoi un Mac peut passer de « largement assez de place » à « disque plein » sans que vous ayez rien fait, et pourquoi un chiffre d'espace libre relevé la semaine dernière ne vaut plus rien aujourd'hui. Mesurez juste avant la mise à jour, pas la veille au soir.

Un audit d'espace pré-mise à jour en cinq commandes

Exécutez-les dans l'ordre et vous saurez exactement où vous en êtes en moins d'une minute :

# 1. The number that matters
diskutil info / | grep "Container Free Space"

# 2. Every volume in the container, with what it is consuming
diskutil apfs list $(diskutil info / | awk '/Part of Whole/ {print $4}') | grep -E "Capacity|Volume Disk"

# 3. Snapshots that are actually yours to remove
tmutil listlocalsnapshots /System/Volumes/Data

# 4. Swap, which a restart returns
sysctl vm.swapusage

# 5. The largest directories in your home folder
du -sh ~/* 2>/dev/null | sort -rh | head -10

Si l'étape 1 dépasse 60 Go, arrêtez-vous là — vous êtes prêt. Sinon, les étapes 2 à 5 vous indiquent laquelle des quatre sources attaquer, à peu près dans l'ordre qui rend le plus d'espace pour le moins de risque.

Récupérer de l'espace, par ordre de sécurité

1. Redémarrer. Libère le swap, vide les caches, supprime certains snapshots. Coûte deux minutes et restitue souvent 10 à 20 Go.
2. Alléger les snapshots Time Machine. sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4. Sans risque, pris en charge officiellement, réversible au sens où la prochaine sauvegarde recrée ce qui compte.
3. Vider la Corbeille, y compris dans Photos et Mail, où les éléments supprimés restent 30 jours dans la corbeille propre à l'application.
4. Forcer la récupération de l'espace purgeable avec l'astuce du fichier lest décrite plus haut si les chiffres restent en désaccord.
5. Caches de développement, le cas échéant. Sur ce Mac, /System/Library/AssetsV2 totalise 25 Go — dont 16 Go de runtimes du simulateur iOS. Les derived data, le device support et les archives d'Xcode ajoutent couramment 50 Go ou plus sur une machine de développeur en usage actif. Le panneau Réglages → Components d'Xcode lui-même supprime proprement les runtimes de simulateur.
6. Les gros fichiers qui sont réellement les vôtres. Les outils d'analyse de stockage les trouvent plus vite qu'en parcourant les dossiers. Et si le disque est plein sans raison apparente, les logs cachés à la racine du système sont l'autre piste à explorer.
7. Décharger vers un stockage externe. La réponse lente mais juste quand le disque est tout simplement trop petit.

Ce qu'il ne faut pas faire

• Ne supprimez pas le snapshot com.apple.os.update- du volume système. C'est le système d'exploitation en cours d'exécution.
• N'exécutez jamais rm -rf sous /System/Volumes/. Preboot, VM et Recovery sont indispensables au fonctionnement du système.
• Ne désactivez pas les snapshots locaux de Time Machine pour « gagner de la place ». Vous perdez la possibilité de revenir en arrière après une mauvaise mise à jour — exactement le filet de sécurité que vous voulez pendant la semaine de mise à jour.
• N'installez pas d'application de nettoyage pour faire tout cela. Chaque opération ci-dessus est une commande native. Un outil tiers avec l'accès complet au disque qui promet de libérer de l'espace en supprimant des fichiers système est un risque pire que le disque plein lui-même.
• Ne supprimez jamais les fichiers de swap à la main. macOS les recrée, et en supprimer un qui est en cours d'utilisation provoque un plantage.

Résolution des problèmes courants

tmutil thinlocalsnapshots indique un succès mais rien n'est libéré

Les snapshots supprimés référençaient des blocs également référencés par d'autres snapshots. Supprimer l'un de plusieurs snapshots qui se chevauchent ne libère rien ; supprimer le dernier libère tout d'un coup. Relancez avec le niveau d'urgence 4, ou supprimez les snapshots restants un par un.

Utilitaire de disque n'affiche aucun snapshot mais de l'espace manque toujours

Ce ne sont donc pas les snapshots. Vérifiez la répartition des volumes du conteneur — Preboot et VM réservent souvent des surprises — et vérifiez l'espace purgeable. Un Mac avec une grande photothèque iCloud contient aussi des originaux optimisés dont le décompte peut sembler bizarre.

L'installeur dit qu'il manque d'espace mais diskutil en indique largement assez

Vérifiez que vous lisez bien le conteneur et non un volume, et que vous regardez le disque interne plutôt qu'un disque externe. Si les deux s'accordent à dire qu'il y a de la place, l'échec cache généralement autre chose derrière une erreur d'espace — un kext tiers qui échoue à son autorisation est le cas le plus courant. Le guide de mise à jour du jour J explique comment vérifier les kexts.

L'espace continue à disparaître pendant la nuit

Time Machine s'est exécuté. C'est le système qui fait son travail. Si le volume de changements est réellement déraisonnable, regardez ce qui écrit — un client de synchronisation qui réécrit de gros fichiers, une image disque de VM, ou une base de données — plutôt que Time Machine lui-même.

Le Mac ne démarre plus après la suppression d'un snapshot

Démarrez sur Recovery et utilisez la Restauration système Time Machine pour revenir à un snapshot antérieur s'il en reste un ; sinon, réinstallez macOS par-dessus, ce qui préserve le volume Data. C'est exactement le scénario que la règle « ne jamais supprimer le snapshot scellé » vise à éviter.

FAQ

Les snapshots APFS sont-ils une sauvegarde ?

Non. Un snapshot réside sur le même disque que les données qu'il référence. Si le SSD tombe en panne, les snapshots tombent avec lui. Ils protègent contre les erreurs et les mauvaises mises à jour, pas contre une panne matérielle. Une véritable sauvegarde réside ailleurs — voir le guide de stratégie de sauvegarde.

Faut-il supprimer les snapshots avant de passer à macOS 27 ?

Allégez-les plutôt que de tous les supprimer, et conservez le plus récent. La mise à jour elle-même créera un nouveau snapshot de votre système d'avant mise à jour, celui-là même dont vous auriez besoin si quelque chose tournait mal.

Pourquoi le Finder affiche-t-il un chiffre d'espace libre différent ?

Le Finder indique l'espace disponible du volume en incluant le contenu purgeable, ce qui donne un chiffre optimiste. diskutil info / indique l'espace libre réel du conteneur. Fiez-vous au second dès qu'un installeur entre en jeu.

Puis-je empêcher macOS de prendre des snapshots locaux ?

Vous pouvez désactiver Time Machine entièrement, ce qui les arrête, mais c'est un mauvais compromis. La rétention de 24 heures associée à l'allègement automatique basé sur la pression fait que les snapshots s'autolimitent sur un Mac en bonne santé.

9 Go pour Preboot, est-ce normal ?

C'est plutôt élevé, mais pas alarmant pour un Mac qui a connu plusieurs mises à jour majeures. Il grossit à chaque installation de système hébergée par le conteneur. Il n'existe aucune méthode officielle pour l'élaguer, et aucune raison d'essayer.

Redémarrer libère-t-il vraiment de l'espace ?

Oui, de façon mesurable. Le swap y contribue le plus — 18 Go sur ce Mac — avec les caches et les snapshots expirés. C'est la première chose à essayer, et la seule qui ne coûte rien.

Conclusion

Le chiffre d'espace libre du Finder est un résumé écrit pour rassurer ; celui du conteneur est celui qui décide si la mise à jour de lundi démarre. L'écart entre les deux, ce sont des snapshots que vous pouvez alléger, du contenu purgeable que macOS libérera sous pression, et deux volumes invisibles qui ne sont, au fond, que le coût de faire tourner un Mac moderne.

Si vous ne devez retenir qu'une seule commande de tout cet article, que ce soit diskutil info / | grep "Container Free Space". Tout le reste de cet article sert à expliquer pourquoi ce chiffre diffère de celui que vous attendiez — mais c'est lui qui a raison.

Lectures associées : Guide de mise à jour du jour J pour macOS 27 Golden Gate · Pourquoi macOS 27 n'apparaît pas dans Réglages Système · Les logs cachés à la racine qui remplissent votre disque · Dépannage de Time Machine