# Nettoyer Docker sur Mac sans perdre de données > Inspectez images, conteneurs, cache de build et volumes stateful avant de pruner, puis mesurez à part l’allocation du disque sparse. Published: 2026-06-26 | Updated: 2026-08-08 Docker Desktop peut occuper des dizaines de gigaoctets, car les images, les couches inscriptibles des conteneurs, le cache de build et les volumes se trouvent dans un disque virtuel Linux. Ces catégories ne se jettent pas toutes de la même façon. Le cache de build est en général reproductible ; un volume de base de données peut être la seule copie de données importantes. Un nettoyage sûr commence par l’inventaire Docker, pas par la commande de prune la plus large. ## Pourquoi l’espace Docker ne revient pas Docker Desktop sur macOS exécute une machine virtuelle Linux et stocke en principe ses données dans un disque virtuel creux (sparse) nommé `Docker.raw`. Le [guide de stockage Mac](https://docs.docker.com/desktop/troubleshoot-and-support/faqs/macfaqs/#where-does-docker-desktop-store-linux-containers-and-images) de Docker indique **Docker Desktop > Settings > Resources > Advanced** pour son emplacement, la limite de disque et l’espace réellement consommé. Déplacez-le avec ce réglage, pas avec le Finder. Un fichier creux a une taille logique maximale et une allocation physique plus petite, donc `ls -lh` seul peut le faire paraître bien plus gros que la capacité qu’il occupe actuellement. Voyez ce que Docker lui-même estime utiliser : ``` docker system df -v ``` La vue détaillée décompose les images, les conteneurs, les volumes locaux et le cache de build. « Reclaimable » signifie que Docker ne voit aucune référence courante qui exige cet objet ; cela ne prouve pas que vous n’aurez pas besoin demain d’un conteneur arrêté, d’une ancienne image ou d’un volume. Inspectez aussi `docker ps -a` et `docker volume ls` avant tout prune. ## Commencer par un nettoyage ciblé Récupérez toujours l’espace depuis Docker, pas en supprimant le fichier de disque virtuel. Commencez par la catégorie que vous maîtrisez : ``` docker builder prune --filter until=168h docker image prune docker container prune ``` La première commande supprime le cache de build de plus de sept jours ; ajustez l’âge selon votre travail. Les deux suivantes demandent confirmation avant de retirer les images orphelines (dangling) et les conteneurs arrêtés. Relancez `docker system df -v` après chaque étape pour voir quelle action a compté. Le [guide de pruning](https://docs.docker.com/engine/manage-resources/pruning/) de Docker documente `docker system prune` comme commande de commodité plus large. Ajouter `-a` retire toutes les images inutilisées, pas seulement les couches orphelines. Ajouter `--volumes` élargit l’opération aux volumes anonymes inutilisés, qui peuvent contenir des fichiers de base de données ou d’autre état. N’en faites pas de `docker system prune -a --volumes` une commande de nettoyage par défaut. Avant tout prune de volumes, inspectez les noms et la propriété : ``` docker volume ls docker volume inspect ``` Les volumes créés par Compose portent en général des labels de projet et de service. Identifiez le projet propriétaire et exportez ou sauvegardez les données qui ne peuvent pas être reconstruites avant de supprimer le volume. ## Récupérer l’image disque elle-même Après un prune, des blocs libres existent dans le système de fichiers Linux avant que macOS ne les reçoive nécessairement du disque creux. La documentation Docker actuelle indique qu’une image `Docker.raw` rend en général l’espace hôte éligible en quelques secondes ; les anciennes images `Docker.qcow2` s’appuient sur un processus en arrière-plan qui peut prendre plusieurs minutes. Remesurez l’usage réel du disque au lieu de juger le maximum logique du fichier. Une réinitialisation d’usine n’est pas une compaction : elle détruit les conteneurs locaux, les images, les volumes et les réglages. Ne l’utilisez que lorsque cette perte totale est volontaire et que les données de volume importantes ont été exportées. ## Sous le capot : pourquoi le fichier grossit et ne rétrécit pas Docker Desktop exécute une machine virtuelle Linux, et `Docker.raw` est le disque virtuel de cette VM : un fichier creux qui grossit quand l’invité écrit, mais qui ne rend pas automatiquement l’espace à macOS lorsque l’invité supprime. Retirer une image marque des blocs libres dans le système de fichiers de la VM, mais le fichier hôte ne rétrécit que si l’invité émet un TRIM/discard et que Docker Desktop peut utiliser discard et compaction pour restituer les blocs éligibles. Le délai dépend de la version et de l’implémentation de l’image disque. C’est pourquoi un nettoyage logique et un changement de capacité côté hôte doivent être mesurés séparément, et pourquoi supprimer le fichier hôte revient à détruire tout l’environnement Docker.
Un fichier Docker.raw creux grossit au fur et à mesure des écritures de la machine virtuelle invitée et peut restituer des blocs éligibles à macOS par discard et compactage
Supprimer un objet Docker libère d’abord de l’espace dans la VM. Restituer l’allocation physique à macOS est une étape distincte du disque creux.
## Où une carte disque aide Une carte disque comme la vue Analyze de [Mole](https://mole.fit/) peut révéler le disque virtuel et son empreinte physique. C’est le CLI de Docker qui doit décider quels objets internes sont référencés. Les deux vues répondent à des questions différentes : macOS montre où la capacité est allouée, tandis que Docker explique ce que cette allocation contient. ## Un ordre d’opérations sûr Exécutez `docker system df -v`, repérez les anciens projets et les volumes avec état, exportez les données uniques, et prunez une catégorie à la fois. Revérifiez à la fois les totaux internes de Docker et la capacité physique de macOS. N’utilisez les drapeaux de prune larges qu’après avoir examiné leur portée élargie, et ne traitez jamais une réinitialisation d’usine comme raccourci de routine pour récupérer de l’espace. Le gain sûr le plus rapide est en général l’ancien cache de build, pas des volumes inconnus. --- Canonical HTML page: https://mole.fit/fr/blog/how-to-clean-up-docker-mac Blog index for agents: https://mole.fit/fr/blog/llms.txt Site index for agents: https://mole.fit/llms.txt