# Nettoyeurs Mac IA : ce qu'un modèle doit décider, et ce qu'il ne doit pas décider
> Le classement et l'attribution peuvent être probabilistes, la décision de suppression ne le peut pas. Comment cc-cleaner, DevCleaner, les skills d'agent et Mole tracent chacun cette ligne, et lequel convient à votre disque.
Published: 2026-08-20 | Updated: 2026-08-22
« Nettoyeur Mac IA » recouvre deux produits différents. L’un est une app de nettoyage
avec un modèle quelque part à l’intérieur, vendue sur l’intelligence de ses
recommandations. L’autre est un outil pour récupérer le disque que Claude Code, Cursor,
Ollama et leurs caches se sont discrètement approprié au fil de l’année écoulée. C’est le
second que veut la plupart des gens qui tapent cette expression en 2026. Le premier
mérite pourtant d’être traité en premier, parce que la réponse détermine à quel point
faire confiance à quoi que ce soit dans le second groupe.
## Première partie : ce que le modèle décide réellement
Un nettoyeur qui met en avant l’IA fait une promesse sur une seule étape d’un pipeline
qui en compte au moins quatre :
1. **Énumérer.** Parcourir le disque et le mesurer. Un travail de la forme de `du`, sans
aucun jugement.
2. **Attribuer.** Décider quelle app ou quelle chaîne d’outils possède chaque chemin.
3. **Classer et expliquer.** Décider lesquels des quatre mille candidats méritent, disons
douze, qu’on s’y attarde, et dire en une phrase ce qu’est chacun d’eux.
4. **Décider et supprimer.** Décider ce qui est sûr à retirer, puis le retirer.
Les étapes 2 et 3 sont réellement floues, et un modèle y aide réellement. L’étape 4 est
un problème d’une autre nature, et un modèle en est le mauvais instrument. Presque tous
les débats sur les nettoyeurs IA portent en réalité sur la question de savoir de quelle
étape parle l’éditeur.
### Là où un modèle mérite sa place
L’attribution est le cas difficile, honnêtement. Supposons que vous trouviez
`~/Library/Application Support/Foo Labs` pesant 3 Go sans aucune app nommée Foo Labs sur
le disque. Les indices sont faibles et éparpillés : des fragments d’identifiant de bundle
dans les plists du dossier lui-même, un préfixe correspondant dans
`~/Library/HTTPStorages`, un bundle `.savedState` sous
`~/Library/Saved Application State`, un reçu d’installation dans `/var/db/receipts`.
L’égalité des noms échoue immédiatement, parce que l’éditeur écrit `Foo Labs` à un
endroit et `com.foolabs.editor` à un autre, et un catalogue écrit à la main couvre les
quelques centaines d’apps les plus courantes puis s’arrête net. C’est exactement le cas
de figure où un modèle bat une règle : de nombreux indices faibles, aucun décisif, une
longue traîne que personne ne finira jamais de cataloguer.
Le classement obéit à la même logique : un scan qui renvoie 4 000 chemins et 60 Go pose
un second problème, ce n’est pas un résultat. L’explication est plus facile encore,
puisque transformer `~/Library/Caches/com.apple.nsurlsessiond` en une phrase claire
relève de la traduction. Un outil qui utilise un modèle pour ces trois tâches, et qui le
dit, met en avant une vraie fonctionnalité.
### Pourquoi la dernière barrière doit être déterministe
La décision de suppression exige trois propriétés qu’un modèle ne peut pas fournir.
**Le déterminisme.** Même disque, même version, même réponse, à chaque fois. Une
température à zéro n’achète pas ça, parce que le prompt porte le contenu de votre
machine : installez une app de plus, la liste de fichiers change, et les tokens dont
dépend la décision changent avec elle. Une règle de sécurité qui tient sur votre Mac mais
pas sur celui de votre collègue n’est pas une règle de sécurité.
**L’auditabilité a priori.** Une liste de protection est un ensemble de préfixes de
chemins, lisible en entier en une minute et comparable entre deux versions. Des poids
plus un prompt ne peuvent pas se lire comme une liste de ce qui sera refusé, donc rien ne
vous montre la limite avant que vous ne la franchissiez.
**L’auditabilité a posteriori.** Quand une règle déterministe supprime la mauvaise chose,
vous obtenez un bug reproductible : voici le chemin, voici la ligne qui l’a autorisé,
voici le test qui échoue désormais. Quand un modèle le fait, l’artefact est une
transcription, le correctif est une modification de prompt, et l’effet de cette
modification sur tous les autres cas reste non mesuré.
Les modes de défaillance sont eux aussi asymétriques. Un mauvais classement coûte un
défilement d’écran ; une mauvaise suppression de `~/.claude/projects` coûte chaque
transcription que vous possédez. Le cadre n’est donc pas « IA bonne, IA mauvaise », c’est
une ligne de partage au milieu du pipeline : probabiliste là où se tromper coûte de
l’attention, déterministe là où se tromper coûte des données.
La ligne de partage ne sépare pas les outils intelligents des outils bêtes, elle sépare la moitié du pipeline où se tromper gaspille un défilement d’écran de la moitié où se tromper perd un fichier.
### De quel côté se situe Mole
[Mole](https://mole.fit/) n’embarque aucun modèle et n’exécute aucune inférence. Le fait qu’un chemin
puisse un jour devenir candidat à la suppression est décidé par un tableau fixe de
préfixes relatifs bloqués, compilé dans l’app, contenant des entrées comme
`.ollama/models`, `.lmstudio/models`, `.cache/huggingface`, `.cache/torch`,
`.claude/projects`, `.codex/sessions`, `.grok/sessions` et
`Library/Caches/com.apple.e5rt.e5bundlecache`. La moitié modifiable par l’utilisateur est
un simple fichier texte que vous pouvez lire avec `cat ~/.config/mole/whitelist`. Le
[Mole CLI](https://github.com/tw93/Mole) gratuit est open source sous GPL-3.0 et applique
la même liste, donc le code qui l’impose est public.
Cette dernière entrée est l’argument en miniature. `com.apple.e5rt.e5bundlecache` se
trouve dans `~/Library/Caches` et le mot dans son nom est « cache », donc toute
heuristique de la Terre le classe comme jetable. Il contient des modèles compilés pour le
Neural Engine d’Apple, et le vider pendant qu’une app a des modèles chargés casse les
appels de reconnaissance jusqu’au redémarrage de la machine. Il est protégé parce qu’une
personne a rencontré cet échec et a écrit la ligne.
Le test pratique pour n’importe quel outil se résume donc à une seule question : laquelle
des quatre étapes le modèle exécute-t-il ? Énumération, attribution, classement et
explication sont des réponses crédibles. « Il décide ce qui est sûr à supprimer » est une
réponse qui appelle une autre question, celle de voir la liste, et s’il n’y a pas de
liste, il n’y a rien à examiner.
## Deuxième partie : des outils pour nettoyer après les outils d’IA
C’est ce que la plupart des gens ont réellement en tête. L’empreinte se divise en quatre
types de données soumis à quatre règles différentes, et c’est en les confondant
qu’arrivent les accidents :
- **Caches et logs d’outils.** `~/Library/Caches/claude-cli-nodejs`, les caches Electron
de Cursor, les dossiers de télémétrie et de débogage sous `~/.claude`. Régénérables et
sans intérêt.
- **Transcriptions et état de projet.** `~/.claude/projects`, `~/.codex/sessions`,
`~/.grok/sessions`. Souvent la plus grosse surprise d’un scan, et irremplaçables.
- **Anciennes versions de CLI.** Les CLI d’agents qui se mettent à jour elles-mêmes
laissent les versions précédentes derrière elles. Sur Codex, cela représente environ
300 Mo par version, donc cinq versions empilées atteignent 1,2 Go pour une seule
active.
- **Poids de modèles.** `~/.ollama/models`, `~/.cache/huggingface/hub`, le dossier de
modèles de LM Studio. De très loin les plus volumineux, possédés par l’outil qui les a
téléchargés.
Mesurez avant de choisir un outil :
```
du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h
```
### Mole, pour un balayage passé en revue qui connaît déjà ces chemins
L’outil Clean scanne d’abord et affiche un résultat que vous passez en revue avant que
quoi que ce soit ne bouge. Chaque ligne candidate porte son chemin, son propriétaire et
sa taille exacts, et tout ce dont le scanner n’est pas sûr arrive décoché, si bien que le
clic par défaut est toujours l’action la plus prudente. Les suppressions vont à la
Corbeille plutôt que d’être détruites directement, et chaque opération s’ajoute à
`~/Library/Logs/mole/operations.log`, où `TRASHED` et `DELETED` sont deux mots
différents.
Le scan se termine avant que l’écran de revue n’apparaisse, si bien que vous ne choisissez jamais des éléments dans une liste à moitié construite.
Deux comportements comptent spécifiquement pour les outils d’IA. Les dossiers d’anciennes
versions de CLI d’agents sont proposés, mais la version active ne devient jamais
candidate : la cible du lanceur est résolue et épinglée en premier, si bien que la
version que vous utilisez est exclue par construction plutôt que par une supposition sur
le numéro de version. Et la désinstallation raisonne sur la propriété plutôt que sur la
correspondance de noms, si bien que retirer une app d’un éditeur ne propose pas le
dossier `Application Support` partagé qu’une app sœur encore installée possède.
Pour lancer la tâche : ouvrez Clean, laissez le scan se terminer, déployez les groupes
qui semblent volumineux, décochez ce que vous voulez garder, puis nettoyez et vérifiez
l’espace libéré. Le scan est gratuit et chaque outil payant s’utilise deux fois
gratuitement, si bien que toute la revue est vérifiable avant de décider si les 19 $ en
valent la peine.
### Le Mole CLI, quand vous préférez rester dans le terminal
Un produit gratuit distinct, open source sous GPL-3.0, installé avec
`brew install mole`. Toujours prévisualiser d’abord :
```
mo clean --dry-run
mo purge --dry-run
```
`mo clean` s’occupe des caches et des logs, `mo purge` vise les anciens artefacts de
build de projets, et chaque commande destructive accepte `--dry-run` pour que vous lisiez
d’abord la liste exacte des chemins. Il partage la liste de protection et le journal
d’opérations avec l’app Mac. Une différence à connaître avant d’abandonner ce drapeau :
le nettoyage de cache en CLI supprime les fichiers définitivement, tandis que la
désinstallation et le retrait des résidus vont toujours à la Corbeille.
### cc-cleaner, l’option open source en terminal conçue pour ce problème
[cc-cleaner](https://github.com/elexingyu/cc-cleaner) est sous licence MIT, nécessite
Python 3.10 ou plus récent, et s’installe avec `pipx install cc-cleaner`. Il embarque 22
nettoyeurs, dont Claude Code, npm, uv, cargo, Docker, Playwright, les caches de
navigateur, et un groupe modèles IA/ML couvrant Hugging Face, PyTorch, Whisper et Ollama.
`cc-cleaner status` affiche un tableau des tailles, `cc-cleaner clean` ouvre un sélecteur
interactif, `-n` fait une simulation sans suppression.
Son modèle de risque est explicite : les éléments Safe se nettoient par défaut tandis que
les éléments Moderate et Dangerous exigent `--force`, et son README classe « les
transcriptions de conversation, les dépôts partagés » dans le niveau Moderate. Le code
source dit le reste. Son nettoyeur Ollama supprime la totalité de `~/.ollama/models`
comme un seul dossier, son nettoyeur Hugging Face fait de même avec
`~/.cache/huggingface/hub` et `datasets`, et son nettoyeur Claude propose les
transcriptions `*.jsonl` sous `~/.claude/projects`. La suppression passe par
`shutil.rmtree` et `Path.unlink`, donc rien n’atterrit dans la Corbeille. Sa couche de
sécurité est un ensemble figé de chemins système interdits plus une exigence que chaque
cible se trouve sous votre dossier personnel : une liste déterministe écrite par un
humain, exactement comme il se doit. La différence porte sur l’emplacement de la ligne,
pas sur la rigueur. cc-cleaner range les dépôts de modèles et les transcriptions derrière
un drapeau ; Mole les refuse.
### DevCleaner, pour une app de barre de menus couvrant le même terrain
[DevCleaner](https://devcleaner.app) est un utilitaire de barre de menus pour macOS 14 et
plus, actuellement en version 1.9.0, couvrant 23 écosystèmes, de DerivedData Xcode et
Gradle à npm et Docker, avec des scanners dédiés pour Claude, ChatGPT, Cursor, Ollama et
LM Studio. Les éléments Safe sont supprimés par défaut, les éléments Warning sont « à
votre discrétion », les éléments Danger ne sont jamais présélectionnés, et il tient une
liste noire stricte pour les identifiants et les fichiers de session, plus un
avertissement avant de toucher aux caches d’une app en cours d’exécution. Le nettoyage de
base est gratuit et Pro se vend en achat unique ou en abonnement annuel ; vérifiez les
chiffres actuels sur la page de l’éditeur. Son site ne précise pas si les suppressions
vont à la Corbeille, ce qui vaut la peine d’être demandé avant un premier lancement.
MacPaw propose aussi un CleanMyMac CLI en bêta publique, via un cask Homebrew, visant les
mêmes artefacts. Il est propriétaire, son dépôt est un simple gestionnaire de tickets
plutôt qu’un dépôt de code source, et son comportement change encore explicitement, donc
fiez-vous à ce que montre son étape de confirmation plutôt qu’à toute description
publiée.
### Diriger un agent vers votre propre disque
La dernière voie consiste à se passer des outils de nettoyage et à demander à Claude Code
ou à un agent similaire de nettoyer le disque directement, éventuellement via l’une des
skills de nettoyage publiées. Son avantage est réel, et rien d’autre dans cette liste ne
le possède : un agent peut raisonner sur une organisation que personne n’a cataloguée,
que ce soit un framework sorti le mois dernier, une chaîne d’outils privée, ou un dossier
personnel organisé comme vous seul l’organisez.
L’évaluation doit être tout aussi franche. Les commandes shell sont générées au moment de
l’inférence contre votre vrai système de fichiers, donc ce qui s’exécute n’a jamais été
relu par personne avant de tourner. Il n’y a pas de simulation à moins que vous n’en
exigiez une. La zone d’impact est votre dossier personnel, et un `rm -rf` composé à
partir d’une variable qui s’est révélée vide est un mode de défaillance à la longue
histoire. La première partie s’applique, filet de sécurité retiré : la décision est
probabiliste et branchée directement sur la dernière barrière.
Quatre garde-fous ne coûtent presque rien :
- **Faites-lui piloter un outil doté d’un drapeau de prévisualisation plutôt que de
composer lui-même les suppressions.** Une skill Claude Code publique enveloppe le CLI
`mo` et rend `mo clean --dry-run` obligatoire avant `mo clean`, affiche la sortie
complète de la simulation, et exige une confirmation tapée. L’agent choisit la cible,
un outil déterministe exécute la suppression.
- **Ne préautorisez jamais `rm` dans vos réglages de permissions.** Approuvez chaque
commande de suppression individuellement, et lisez le chemin plutôt que son résumé.
- **Faites de la Corbeille le comportement par défaut.** `trash` via Homebrew, ou un
`mv` vers `~/.Trash`, transforme chaque erreur en erreur récupérable.
- **Bornez le périmètre de travail.** Pointez-le vers un seul dossier, et demandez un
`du -sh` avant et un `df -h` après pour que le gain annoncé soit mesuré plutôt
qu’estimé.
### Les dépôts de modèles appartiennent à l’outil qui les a téléchargés
Aucun nettoyeur généraliste ne devrait être votre instrument ici, pas même ceux cités
plus haut. Ollama et Hugging Face tiennent tous deux des dépôts adressés par contenu où
les modèles partagent des blobs, donc seul l’outil propriétaire sait quel blob est encore
référencé. Utilisez `ollama ls` et `ollama rm `, et `hf cache ls` avec
`hf cache rm model/ --dry-run`. Pourquoi supprimer des fichiers blob à la main
orpheline un modèle est expliqué dans
[retirer les résidus d’outils d’IA](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac).
## Comment ils se comparent
| Outil | Décide de façon déterministe | Prévisualise les chemins | Récupérable | Protège les dépôts de modèles et l’historique de chat | Coût |
|---|---|---|---|---|---|
| Mole for Mac | Liste fixe de préfixes bloqués plus liste blanche utilisateur | Oui, chemin, propriétaire et taille par ligne | Oui, Corbeille par défaut, plus un journal d’opérations | Oui, jamais candidats | 19 $ une fois, deux Mac, mises à jour à vie |
| Mole CLI | La même liste de protection partagée | Oui, `--dry-run` sur chaque commande destructive | Désinstallation vers la Corbeille, nettoyage de cache définitif | Oui, même liste | Gratuit, GPL-3.0 |
| cc-cleaner | Ensemble figé de chemins interdits, borné au dossier personnel | Oui, simulation `-n` et sélecteur interactif | Non, `shutil.rmtree` et `unlink` | Accessible derrière `--force`, pas refusé | Gratuit, MIT |
| DevCleaner | Trois niveaux de risque plus une liste noire d’identifiants | Tailles par scanner, Danger jamais présélectionné | Non documenté, à vérifier avant de lancer | Poids de modèles isolés en classe à part | Base gratuite, Pro achat unique ou annuel |
| CleanMyMac CLI | Non publié, le dépôt est un gestionnaire de tickets | Oui, confirmation avant suppression | Non documenté | Non documenté | Bêta publique, vérifier les conditions de l’éditeur |
| Agent avec accès shell | Rien, décidé au moment de l’inférence | Seulement si vous l’exigez | Seulement si vous forcez la Corbeille | Seulement si vous le précisez dans le prompt | Votre abonnement à l’agent |
| `ollama rm`, `hf cache rm` | Comptage de références à l’intérieur du dépôt | `hf cache rm --dry-run` | Non, mais retéléchargeable | C’est ça, la protection | Gratuit |
## La limite, sans détour
Mole n’est pas une réponse aux malwares, ni une sauvegarde, ni un substitut au
désinstalleur d’un éditeur pour un logiciel qui embarque des pilotes, des composants VPN
ou des extensions système. Il ne supprime ni les poids de modèles ni l’historique de chat
des IA, donc si votre problème de 200 Go est entièrement une bibliothèque de modèles, il
vous en montre la forme dans Analyze et confie la tâche à Ollama ou LM Studio. C’est une
limite délibérée, pas une lacune à combler plus tard.
## En choisir un
**200 Go de sorties de build et une dizaine de chaînes d’outils.** Le volume se trouve
dans les caches, les vieux `node_modules`, DerivedData et Docker, pas dans quoi que ce
soit de spécifique à l’IA. Commencez par un balayage passé en revue ou
`mo clean --dry-run`, puis parcourez
[vider les caches de développement](https://mole.fit/fr/blog/how-to-clear-dev-caches-mac) pour les dépôts
qui exigent leur propre commande de purge. cc-cleaner est une bonne seconde passe si vous
lisez d’abord ses niveaux de risque.
**Une grosse bibliothèque de modèles locale.** Évitez complètement les nettoyeurs
généralistes pour les poids. `ollama ls`, `hf cache ls` et la vue Mes modèles de LM
Studio sont les seuls outils capables de libérer un blob partagé en sécurité. Utilisez
une carte du disque pour trouver le dépôt, et l’outil propriétaire pour le modifier.
**Vous venez de remarquer que Cursor ou Claude Code dévore du disque.** Le cas le plus
simple à traiter : les caches et les logs se régénèrent, les anciennes versions de CLI
sont du pur gaspillage, et les transcriptions sont la seule chose à ne pas toucher.
N’importe quel outil passé en revue ici s’en charge, et la version pas à pas est dans
[nettoyer après les outils de code IA](https://mole.fit/fr/blog/how-to-clean-up-ai-coding-tools-mac).
## FAQ
### Un nettoyeur Mac dopé à l’IA supprime-t-il plus sûrement qu’un nettoyeur normal ?
Pas au vu des preuves disponibles. Un modèle peut battre une règle pour décider quelle
app possède un dossier orphelin et pour classer ce qui mérite attention, parce que ce
sont des problèmes flous avec de nombreux indices faibles. Décider si un chemin est sûr
à supprimer exige du déterminisme et une liste auditable, deux choses qu’un modèle ne
fournit pas. Demandez à un éditeur quelle étape du pipeline son modèle exécute, et
traitez « il décide ce qui est sûr à supprimer » comme une invitation à voir la liste.
### Est-il prudent de laisser Claude Code nettoyer mon Mac ?
C’est l’option la plus flexible et la moins bornée. Les commandes sont générées au moment
de l’inférence et s’exécutent contre votre dossier personnel, sans prévisualisation à
moins que vous n’en demandiez une. Si vous le faites, faites-lui piloter un outil doté
d’un drapeau de simulation plutôt que de composer lui-même `rm -rf`, ne préautorisez
jamais `rm` dans vos réglages de permissions, envoyez les suppressions vers la Corbeille,
et confinez-le à un seul dossier à la fois.
### Un nettoyeur Mac va-t-il supprimer mes modèles Ollama ou mon historique Claude Code ?
Ça dépend entièrement de l’outil, c’est pourquoi c’est la question à poser en premier.
Mole bloque `~/.ollama/models`, `~/.lmstudio/models`, `~/.cache/huggingface`,
`~/.claude/projects`, `~/.codex/sessions` et `~/.grok/sessions` à la barrière de
suppression, quel que soit leur âge, donc ils ne deviennent jamais candidats. cc-cleaner
classe les dossiers de modèles et les transcriptions Claude Code en risque Moderate et
les supprime si vous passez `--force`. Lisez les niveaux de risque d’un outil avant le
premier lancement, pas après.
### Qu’est-ce qui occupe vraiment l’espace après un an d’outils de code IA ?
En général, ce sont les anciennes versions de CLI et les transcriptions plutôt que les
caches auxquels les gens s’attendent. Une CLI d’agent qui se met à jour elle-même peut
laisser plusieurs centaines de mégaoctets par version, et sur Codex, cinq versions
empilées atteignent environ 1,2 Go pour une seule active. Les transcriptions sous
`~/.claude/projects` s’accumulent discrètement et sont l’élément le plus susceptible de
vous surprendre dans un scan, ce qui explique aussi pourquoi elles devraient être
exclues d’un balayage plutôt qu’incluses.
## Pour aller plus loin
- [Nettoyer les modèles Ollama et LM Studio sur Mac](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac)
pour le mécanisme des dépôts de modèles adressés par contenu.
- [Vider les caches de développement sans casser les builds](https://mole.fit/fr/blog/how-to-clear-dev-caches-mac)
pour les dépôts de gestionnaires de paquets et les `node_modules` éparpillés.
- [Nettoyer après les outils de code IA](https://mole.fit/fr/blog/how-to-clean-up-ai-coding-tools-mac) pour
la version pas à pas, chemin par chemin.
---
Canonical HTML page: https://mole.fit/fr/blog/ai-mac-cleaner-tools
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
