# Mole CLI ou Mole pour Mac

> Choisissez entre le CLI gratuit en terminal et l’app native payante selon le flux de travail, les fichiers de protection partagés sur disque, et les tâches qu’un seul des deux sait faire.

Published: 2026-07-25 | Updated: 2026-08-08

Mole se présente sous deux formes. `mo` est un outil en ligne de commande gratuit et open source, installé avec Homebrew et sous licence GPL-3.0. Mole for Mac est une application native payante, avec cinq onglets et une présence dans la barre de menus. Ce n’est pas un essai et une édition pro. Ce sont des implémentations distinctes, avec des tâches qui se chevauchent et une petite couche partagée sur le disque, de sorte que choisir l’une ne vous empêche pas d’utiliser l’autre. Ce guide vous aide à choisir celle qui correspond à votre façon de travailler, et à comprendre ce qui se passe si vous gardez les deux.

## Ce que les deux partagent

Cinq commandes de la CLI correspondent directement aux cinq onglets de l’app : `mo clean`,
`mo uninstall`, `mo optimize`, `mo analyze` et `mo status` correspondent à Clean,
Software, Optimize, Analyze et Status. Les catégories se reconnaissent d’un côté comme de l’autre :
familles de caches utilisateur, développeur, navigateur et système qui se chevauchent, inventaire d’apps et
découverte de résidus, analyse de disque et indicateurs de santé. Les implémentations et les ensembles exacts
de candidats ne sont pas identiques.

Le scan est gratuit des deux côtés. L’app ne facture que la moitié destructive, et chaque
outil destructif fonctionne deux fois avant qu’une licence soit requise, ce qui vous permet de comparer le scan
de l’app à celui de la CLI sur le même Mac sans rien payer.

Le chevauchement le plus intéressant se trouve sur le disque. Les deux écrivent dans `~/.config/mole/whitelist` et
`~/.config/mole/whitelist_optimize`, et les deux ajoutent des entrées à
`~/Library/Logs/mole/operations.log`. Un cache que vous protégez dans une interface
l’est aussi dans l’autre, et une suppression effectuée dans l’une ou l’autre laisse une trace dans le même fichier. Les deux
programmes ne se connaissent pas à l’exécution, mais ils ne sont pas non plus indépendants.

## Ce que seul le terminal peut faire

Trois grands flux de la CLI n’ont pas d’équivalent dans l’app. Des commandes de support telles que
`mo history`, `mo update`, `mo completion` et `mo remove` relèvent de l’administration du terminal
plutôt que de surfaces d’entretien supplémentaires.

### `mo purge`

Parcourt vos dossiers de projets et propose de retirer les artefacts de build lourds. Sa liste de cibles
est large : `target`, `build`, `dist`, `.next`, `DerivedData`, `__pycache__`,
`coverage`, et une trentaine d’autres, y compris des répertoires de dépendances qu’un gestionnaire de
paquets devrait re-télécharger. Purge supprime définitivement plutôt que d’envoyer vers la
Corbeille, et marque les projets touchés au cours des sept derniers jours comme récents, en les laissant
non sélectionnés. C’est un moyen direct de récupérer des dizaines de gigaoctets sur une machine de développeur,
et aussi la commande qui mérite le plus un `--dry-run` d’abord.

### `mo installer`

Balaye les installateurs DMG, PKG et les archives hors de Downloads, Desktop, des caches Homebrew,
d’iCloud et de Mail, en étiquetant chacun selon sa provenance.

### `mo touchid`

Configure Touch ID pour `sudo`, une tâche de configuration du shell plutôt qu’une
tâche de nettoyage.

Au-delà des commandes, le terminal vous offre trois choses qu’une fenêtre ne peut pas. Chaque commande
destructive accepte `--dry-run`, qui affiche exactement ce qui serait retiré et ne retire
rien. `mo analyze`, `mo status` et `mo history` acceptent `--json`, et `mo status`
passe de lui-même en JSON lorsque sa sortie est pipée, de sorte qu’un contrôle de santé peut alimenter un
script. Les chemins en lecture seule et à sortie structurée fonctionnent aussi en ssh, sur un Mac sans interface,
ou dans des scripts. Une suppression planifiée exige toujours une politique non interactive explicite ;
l’écran de confirmation interactif ne devient pas sûr simplement parce que cron l’a lancé.

## Ce que seule l’app peut faire

Les apports de l’app se regroupent autour de deux points où le terminal est faible : l’affichage
continu et le contrôle système privilégié.

Côté affichage, Analyze dessine une carte treemap dans laquelle vous pouvez plonger, Status affiche un tableau de bord
bento en direct avec des sparklines et des processus épinglables, et un HUD dans la barre de menus garde le CPU, la mémoire
et le réseau visibles pendant que vous travaillez ailleurs. Uninstall présente un plan de revue
avec chemins, propriétaires et tailles avant tout déplacement, et les suppressions partent vers la Corbeille plutôt
que d’être effacées purement et simplement.

Côté contrôle système, l’app installe un helper root à périmètre étroit via SMJobBless
pour les écritures liées au ventilateur et à la batterie prise en charge. La gestion des éléments de démarrage suit une frontière distincte :
les jobs launchd validés et les éléments Service Management pris en charge peuvent être basculés, tandis que
les éléments d’arrière-plan non reconnus ouvrent les Réglages Système au lieu d’être devinés. L’app
porte aussi des surfaces qui n’ont de sens qu’en tant qu’app résidente : Privacy Check, qui
signale l’usage en direct de la caméra et du micro, Battery Care, qui maintient la charge près de 75 à
80 pour cent sur les Mac pris en charge, Keep Screen On, Clean Screen pour essuyer le clavier, et
un Doctor en lecture seule qui assemble un rapport de diagnostic à coller dans un ticket.

La plus grande surface exclusive à l’app est la mise à jour des autres apps. Elle détecte plusieurs canaux de mise à jour
et dispose de chemins intégrés pour Sparkle, les casks et formules Homebrew, le Mac App Store et
les flux Electron. GitHub Releases et les métadonnées de sites web peuvent identifier des versions supplémentaires ;
lorsque Mole ne peut pas vérifier et remplacer un bundle en toute sécurité, elle ouvre l’app ou la page du fournisseur
plutôt que d’inventer un autre installateur. La licence est un achat unique couvrant deux
Mac, avec mises à jour à vie, un remboursement sous 14 jours, et macOS 14 ou plus récent. Aucun des deux programmes
n’envoie de télémétrie.

## Sous le capot : un même modèle de sécurité pour deux interfaces

L’app n’est pas un wrapper qui lance `mo` en shell. C’est une réimplémentation Swift, et
les deux bases de code partagent des chemins et des décisions de sécurité plutôt que des processus. Analyze s’appuie
sur la taxonomie de chemins de la CLI et sur les leçons de dimensionnement parallèle, mais elle a son propre scanner,
ses timeouts, ses états de résultats partiels, son cache et son comportement de repli. Un total provenant d’une interface
est donc un contre-contrôle utile, pas une promesse de parité octet pour octet.

Le principe inscrit dans le dépôt pour les garder alignées est que la parité CLI
signifie « aussi sûr ou plus sûr », pas une même étendue de suppression. Chaque candidat que l’app présente
est classé avant d’arriver jusqu’à vous : sélectionnable par défaut, review-only et non coché
par défaut, ou bloqué purement et simplement et refusé même si quelque chose le demande. Quand le
comportement de la CLI et cette classification divergent, l’app prend la position la plus étroite.

`mo purge` en est l’exemple le plus clair. Le port Mac de ce balayage retire volontairement chaque
répertoire de dépendances téléchargées que la CLI supprime, y compris `node_modules`, `Pods`,
`venv` et `vendor`. Le raisonnement porte sur la récupérabilité : un répertoire `target` compilé
revient d’une compilation locale, alors qu’un arbre de dépendances a besoin du réseau et peut
se résoudre autrement que ce qui avait été installé. L’app n’offre que ce qu’une pure
compilation locale peut reconstruire, et elle les présente comme des lignes review-only plutôt que
présélectionnées. La même asymétrie apparaît ailleurs. L’app conditionne les scans de données d’apps
à l’accès disque complet (Full Disk Access), revalide chaque chemin au moment de la suppression plutôt qu’au
moment du scan, et fait passer les suppressions ordinaires par la Corbeille.

Les deux ne sont donc pas aussi agressifs, et la différence va toujours dans le même
sens. La CLI récupère plus parce qu’elle suppose un utilisateur qui lit la liste. L’app
récupère moins parce qu’elle suppose un utilisateur qui veut que la liste soit déjà sûre.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/two-front-ends.webp" width="1360" height="454" loading="lazy" alt="Deux interfaces, un outil terminal et une application Mac, exécutant séparément les mêmes cinq opérations mais lisant et écrivant le même fichier de liste blanche et le même journal d'opérations sur le disque">
  <figcaption>Les deux programmes ne se parlent jamais pendant l’exécution, mais ils partagent une liste de protection et un journal : un cache protégé dans l’un l’est aussi dans l’autre.</figcaption>
</figure>

## Utiliser les deux

Rien ne casse si vous installez les deux, et les fichiers partagés rendent la combinaison
cohérente. Protégez un cache depuis les Réglages de l’app et `mo clean` le sautera aussi. Ajoutez
un chemin avec `mo clean --whitelist` et l’app le respectera. Les deux laissent leurs suppressions dans
le même journal.

Deux points à connaître. Les programmes ne se coordonnent pas pendant l’exécution : ne lancez
pas un nettoyage des deux côtés en même temps. Et parce que l’app est volontairement plus étroite, voir une
catégorie dans `mo clean` que l’app n’offre jamais est un comportement attendu, pas une fonction
manquante.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/same-or-safer.webp" width="1360" height="454" loading="lazy" alt="L'ensemble des éléments que la CLI supprimera tracé autour de l'ensemble plus petit que l'application Mac supprimera, la différence étant les répertoires de dépendances téléchargés tels que node_modules, Pods, venv et vendor">
  <figcaption>Aussi sûr ou plus sûr, jamais plus large. Les répertoires que seule la CLI balaye sont ceux qui ont besoin du réseau pour revenir.</figcaption>
</figure>

## Choisir

Installez la CLI si vous vivez dans un terminal, voulez prévisualiser avec `--dry-run`, avez besoin de
`--json` pour un script, voulez les balayages d’artefacts de projet et d’installateurs, ou simplement ne
voulez pas dépenser d’argent. Sur une machine de développeur, c’est souvent tout ce qu’il faut, et c’est
gratuit précisément pour pouvoir l’être.

Achetez l’app si vous voulez la carte disque et le tableau de bord en direct, si le contrôle du ventilateur, la gestion
des éléments de démarrage ou les mises à jour d’apps tierces sont la vraie raison de votre venue, ou si vous
l’installez pour quelqu’un qui n’ouvrira jamais le Terminal. Ce dernier cas était la
raison d’origine de l’existence de l’app, une histoire racontée dans
[l’histoire de Mole](https://mole.fit/fr/blog/the-story-of-mole).

Si vous ne savez pas encore, installez d’abord la CLI et lancez `mo clean --dry-run`. Cela ne coûte
rien, ne supprime rien, et lire sa sortie est le moyen le plus rapide de savoir si
votre Mac a un problème digne d’un outil, une question
[à se poser avant d’installer un quelconque cleaner](https://mole.fit/fr/blog/do-you-need-a-mac-cleaner).

---

Canonical HTML page: https://mole.fit/fr/blog/mole-cli-vs-mac-app
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
