Nettoyeurs Mac IA : ce qu'un modèle doit décider, et ce qu'il ne doit pas décider

« 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.

De quel côté se situe Mole

Mole 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 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.

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 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 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 <model>, et hf cache ls avec hf cache rm model/<repo> --dry-run. Pourquoi supprimer des fichiers blob à la main orpheline un modèle est expliqué dans retirer les résidus d’outils d’IA.

Comment ils se comparent

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 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.

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 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 pour les dépôts de gestionnaires de paquets et les node_modules éparpillés.
• Nettoyer après les outils de code IA pour la version pas à pas, chemin par chemin.