# Ajouter le nettoyage et l’entretien des outils d’IA à Mole > Pourquoi je tenais aux conversations avec l’IA, ce qui a changé quand les anciennes sessions et worktrees se sont accumulés sur mon Mac, et ce que je veux préserver dans Mole. Published: 2026-09-29 | Updated: 2026-10-03 Pendant ces vacances, j’ai voulu ajouter une fonction utile à Mole : nettoyer les caches d’IA, les anciennes sessions et les worktrees devenus inutiles, et désinstaller les outils essayés il y a longtemps puis délaissés. Pendant mes [tests des résidus de centaines d’apps Mac](https://mole.fit/fr/blog/testing-mac-apps-one-by-one), beaucoup de gens avaient déjà demandé un nettoyage des données d’IA. À l’époque, une bonne partie de ces « déchets » me semblait utile. Les conversations de programmation avec l’IA sont pour moi un bien précieux ; Mole s’occupait donc surtout des véritables caches et des anciennes versions. Mais à force d’utiliser l’IA, mon propre Mac a lui aussi accumulé des fichiers générés, des sessions et des worktrees qui ne servaient plus vraiment. Le besoin devenait clair, alors je m’y suis mis. Un utilisateur m’avait aussi demandé comment nettoyer un `opencode.db` de 62 Go. Cette fois, j’ai installé des apps de bureau et des outils en ligne de commande, ouvert une session et réellement utilisé chacun avant de chercher ce qu’il laissait derrière lui. ## Comment je les ai testés Contrairement à la dernière fois, où les apps étaient seulement installées puis supprimées, je me suis cette fois connecté aux outils que je pouvais utiliser et je les ai essayés dans mes propres projets : poser des questions, lancer des agents, construire un index de code, programmer une tâche. Beaucoup de données n’apparaissent qu’à l’usage, si bien qu’une app installée mais jamais ouverte en cache l’essentiel. Pour chaque outil, une IA comparait le Mac avant et après, mesurait ce qu’il écrivait dans le dossier de départ, `~/Library`, `/usr/local/bin` et la configuration du shell, et le consignait dans un registre. Je regardais ensuite combien de processus et de mémoire il occupait dans la page État de Mole, je le désinstallais avec Mole, puis je fouillais tout le dossier de départ par nom à la recherche de ce que Mole n’avait pas listé. Ce qui manquait entrait dans le code le soir même, suivi d’un nouveau test. Côté bureau, j’ai testé 13 apps : Devin, OpenCode, Trae, Trae CN, TRAE SOLO CN, Kiro, Qoder, QoderWork, Qoder CN, Lingma, CodeBuddy CN, WorkBuddy et Doubao Work. Douze ont réellement servi ; Lingma n’avait aucun quota après la connexion, je n’ai donc mesuré que les fichiers qu’il écrivait. En ligne de commande, j’ai installé et lancé Amp, opencode, Kimi CLI, Kimi Code, Factory Droid, Copilot CLI, Gemini CLI, Qwen Code et iFlow, ce qui, avec Claude Code, Codex, Grok et Cursor Agent qui étaient déjà sur mon Mac, fait 13. En suivant la liste prise en charge par CC Switch, j’ai aussi mesuré ce qu’OpenClaw, Hermes et Pi laissent derrière eux après suppression. Amp s’est distingué par sa finition, avec une vraie personnalité. Qoder CN était probablement le meilleur produit d’IA chinois que j’avais testé ce jour-là, sobre et clair dans l’ensemble. Quelques-uns sont restés inutilisables : je n’ai pas pu me connecter à Gemini CLI avec mon compte Google personnel pendant ce test, et Qwen Code comme iFlow demandent un point d’accès et une clé à fournir soi-même. ## On ne voit ce qu’ils écrivent qu’en s’en servant La mémoire était la partie la plus visible. Ouvertes ensemble, les 13 apps de bureau occupaient environ 23 Go, et CodeBuddy CN à lui seul faisait tourner 41 processus pour 4,49 Go. La plupart sont des apps VS Code ou Electron, où une seule fenêtre cache une chaîne d’helpers ; c’est pourquoi la page État de Mole attribue à chaque app une seule ligne qui additionne tous ses processus enfants. Dans une simple liste de processus, difficile de savoir qui utilise vraiment la mémoire. Les petites modifications apportées au système m’ont davantage surpris. Devin, CodeBuddy, Kiro et Kimi Code ajoutent des lignes de PATH ou d’intégration au shell dans `~/.zshrc`, et au premier lancement, Kiro, Trae et Trae CN placent dans `/usr/local/bin` un lien de commande appartenant à root, qui ne pointe plus vers rien une fois l’app supprimée. WorkBuddy a déposé un `python3.12` dans `~/.local/bin`, de sorte que taper ensuite `python3.12` dans Terminal lance sa copie, et il a aussi installé un Python uv de 127 Mo ; sur le moment, j’ai dit qu’il était plus envahissant que je ne l’imaginais. Le plus curieux fut Kimi CLI : je l’ai lancé une fois, il m’a annoncé qu’il n’était plus maintenu, puis, sans rien demander, il a téléchargé et installé le nouveau Kimi Code, modifié `.zshrc` et renommé l’ancienne commande en `kimi-legacy`. Côté volume, la première utilisation du mode Work de TRAE SOLO télécharge environ 1 Go d’outils qui occupent 3,1 Go une fois décompressés, un ensemble intégré de LibreOffice, FFmpeg et OpenJDK, et six outils de bureau qui n’avaient exécuté qu’une ou deux tâches chacun ont écrit 5,2 Go de données à eux tous. Mon propre `~/.codex`, que j’utilise chaque jour, pèse déjà 24 Go, dont 17 Go de sessions, et sur les 14 Go de l’app de bureau Claude, 12 Go correspondent à la machine virtuelle Linux qu’utilise Cowork. La base de données d’opencode enregistre des événements : une seule question écrit plus de trois fois la taille du message lui-même, et supprimer une session ne réduit pas le fichier, ce qui explique sans doute comment quelqu’un a atteint 62 Go. Les skills étaient un autre piège. Beaucoup d’installateurs de skills écrivent un dossier `skills/` dans le répertoire de chaque agent, que vous ayez cet agent ou non ; c’est ainsi que `~/.qwen`, `~/.iflow` et `~/.factory` existaient sur mon Mac alors que je n’avais jamais utilisé Qwen Code, iFlow ni Droid. La première version de Mole les comptait même comme des outils de 2,4 Mo et a failli traiter mes skills installés comme des restes. ## Certaines choses restent après la désinstallation Après une première série de 14 apps supprimées, une nouvelle recherche trouvait encore plus d’une dizaine de dossiers cachés que Mole n’avait pas listés, comme `~/.kiro`, `~/.qoder`, `~/.qodersec`, `~/.lingma` et `~/.codebuddy`, plus le fichier de jeton de connexion que Kiro garde dans `~/.aws`. Ils ne sont pas sous `~/Library` et leurs noms ne correspondent pas toujours à l’app ; la seule façon de les trouver était de procéder app par app. Certains sont partagés entre produits : Trae CN et TRAE SOLO CN partagent `~/.trae-cn`, Qoder et QoderWork partagent `~/.qoder`, donc désinstaller l’un ne doit pas lister un dossier dont l’autre se sert encore. Les tests de la version internationale de Trae ont aussi montré qu’elle s’attribuait les dossiers de Trae CN, avec les caches cochés par défaut ; après correction, sa liste est passée de 33 lignes à 14. Les processus ont été l’autre surprise. En revérifiant le lendemain matin, `~/.kimi-code` et `~/.factory` étaient revenus après leur suppression, parce que les sessions `kimi` et `droid` laissées ouvertes dans Terminal la veille tournaient toujours : leurs fichiers programmes étaient déjà dans la Corbeille, et les processus continuaient d’écrire des journaux dans ces dossiers. J’ai ensuite trouvé des sessions `gemini`, `qwen`, `iflow` et `amp` encore actives elles aussi. Les outils en ligne de commande n’ont pas de fenêtre, et fermer un onglet de Terminal ne les arrête pas toujours ; mieux vaut donc vérifier qu’un outil ne tourne pas avant de le désinstaller. Ces essais m’ont aussi rappelé la retenue de Claude, Codex et Cursor, les trois que j’utilise souvent. D’autres produits m’ont mis mal à l’aise : des installateurs écrivaient dans le presse-papiers pour suivre le canal d’installation et faire des statistiques, ce qui me semblait aller trop loin. Certaines apps affichaient aussitôt des fenêtres invitant à participer à des promotions pour gagner des tokens. Il fallait parfois prendre sur soi pour les utiliser. Qoder a été une bonne surprise. De la retenue, du goût, pas de comportements déplacés : le produit m’a impressionné. J’aimerais voir davantage de logiciels chinois de ce genre. Bonne continuation. ## Vous pouvez d’abord jeter un œil vous-même Aucune de ces vérifications n’a besoin de Mole ; Terminal suffit, et les commandes ci-dessous ne font que lire, elles ne modifient rien. D’abord, voyez si des outils d’IA ont ajouté des lignes à votre configuration du shell : ```bash grep -nE "codeium|codebuddy|kiro|kimi|lmstudio|\.local/bin" ~/.zshrc ~/.bashrc ~/.zprofile 2>/dev/null ``` Chaque ligne commence par le nom du fichier et le numéro de ligne. Si l’outil concerné a déjà disparu, vous pouvez supprimer la ligne dans un éditeur de texte ; faites d’abord une copie du fichier, puis ouvrez une nouvelle fenêtre de Terminal pour vérifier que tout fonctionne encore. Ensuite, cherchez dans `/usr/local/bin` les commandes qui pointent à l’intérieur d’une app, ainsi que les liens qui ne fonctionnent plus : ```bash ls -l /usr/local/bin | grep "\.app/" find /usr/local/bin -maxdepth 1 -type l ! -exec test -e {} \; -print ``` La première liste les commandes qui pointent à l’intérieur d’une app, la seconde les liens dont la cible a disparu. La plupart sont laissés par des apps supprimées ; ils appartiennent à root, donc leur suppression demande un mot de passe administrateur. Regardez si un agent en ligne de commande déjà supprimé tourne encore : ```bash ps -axo pid,lstart,command | grep -E "kimi|droid|gemini|qwen|iflow|amp|opencode" | grep -v grep ``` Cette recherche porte sur du texte. Vérifiez la commande complète et l’identifiant du processus pour confirmer qu’il s’agit de l’outil d’IA : `amp` peut figurer dans un mot sans rapport. Quittez ensuite dans le Terminal d’origine, ou utilisez `kill` avec cet identifiant si la fenêtre reste introuvable. Enfin, mesurez la place que prennent ces outils : ```bash du -sh ~/.codex ~/.claude ~/.grok ~/.gemini ~/.cursor ~/.local/share/opencode 2>/dev/null ``` Ces dossiers contiennent votre historique de sessions ; avant de supprimer quoi que ce soit, demandez-vous si vous voudrez y revenir, car une conversation d’IA supprimée sans copie conservée ne se récupère pas. ## Comprendre ce que contient un gros dossier Le dossier d’un outil d’IA peut réunir caches recréables, modèles téléchargés, conversations, projets et configuration partagée. Un nom évoquant un cache ne rend pas tous ses fichiers jetables. À la main, examinez d’abord ce qui peut être recréé, puis titres, dates et sauvegardes de votre travail. Pour un worktree, vérifiez les modifications non validées et que ses commits existent sur une branche à conserver. Si `opencode.db` ne rétrécit pas après suppression de sessions, cela ne signifie pas forcément un échec. [SQLite explique](https://sqlite.org/lang_vacuum.html) que les pages des enregistrements supprimés restent généralement disponibles pour réutilisation sans réduire le fichier. Le compactage récupère ces pages vides ; il n’efface pas une nouvelle série de conversations. Choisissez les sessions à retirer avant la maintenance, sans réunir les deux dans une grande action de suppression. ## Ce que fait Mole désormais La page IA est actuellement en Preview et doit encore être testée avant la prochaine version. On y accède par une Lune lointaine sur la page Nettoyer, qui n’apparaît que lorsque des données d’outils d’IA sont trouvées et qui peut être masquée dans les Réglages si vous n’en voulez pas. À l’intérieur, Mole passe les outils en revue un par un et range ce qu’il trouve en trois groupes, selon le regret que pourrait causer leur suppression : les caches et anciennes versions se reconstruisent d’eux-mêmes et sont cochés d’emblée ; les sessions et worktrees ne se recréent pas seuls, c’est donc à vous de les confirmer ; les outils inutilisés depuis longtemps et la maintenance viennent en dernier et ne sont pas cochés non plus.
La page Nettoyage et entretien IA de Mole avec six sessions Codex de plus de 90 jours dépliées sous sessions et worktrees, puis worktrees terminés et sessions de projets supprimés, chaque ligne indiquant ce que c’est, ce que coûte sa suppression et sa taille.
La vraie page Nettoyage et entretien IA. Les données de la capture proviennent d’un dossier d’exemple, pas de mon Mac.
Dans le groupe des sessions, les anciennes sessions Codex au-delà de la durée de conservation peuvent être filtrées à 15, 30, 90 ou 120 jours, et une fois dépliée, chacune affiche son titre et sa date et peut être décochée à part. Mole copie d’abord le fichier de session dans la Corbeille, puis appelle la commande de suppression propre à Codex, afin que l’index de Codex reste cohérent. Pour Claude Code, il ne liste que les sessions dont le dossier de projet a disparu, et un worktree terminé n’apparaît que si git peut prouver qu’il ne contient aucune modification non validée, avec une mention lorsque son travail est déjà fusionné dans la branche principale. Le groupe des outils inutilisés a demandé le plus de temps cette fois. Mole cherche les outils d’IA en ligne de commande aux emplacements fixes qu’utilisent npm, pipx, uv, les installateurs officiels et Homebrew, ne liste que ceux inutilisés depuis 30 jours et qui ne tournent pas, et supprime ensemble le programme, les liens de commande qui pointent vers lui, ainsi que ses réglages, ses sessions et sa connexion. Les données qu’un autre produit utilise encore restent en place : Antigravity range aussi des éléments dans `~/.gemini`, et l’app de bureau d’opencode partage une base de sessions avec sa ligne de commande. Au-delà de quatre outils inutilisés, les trois plus volumineux ont chacun leur ligne et les autres sont regroupés en une seule. Claude Code et Codex ne figurent pas dans la liste, car leurs dossiers servent aussi d’état aux apps de bureau. Les outils en ligne de commande installés dans les dossiers système avec `sudo npm` sont listés eux aussi, et leur suppression demande une seule fois le mot de passe administrateur. Quant au fichier `opencode.db` d’opencode, qui ne cesse de grossir, dès que les sessions supprimées y ont laissé plus d’un dixième d’espace vide et qu’il dépasse 200 Mo, Mole propose de le compacter dans ce groupe : aucune session n’est supprimée, seul l’espace libre revient au disque, et il faut d’abord quitter opencode. Côté désinstallation, les dossiers cachés évoqués plus haut sont désormais listés comme lignes à confirmer, décochées par défaut, et un dossier partagé par plusieurs produits n’est pas listé tant qu’un autre d’entre eux est encore installé. Les liens de commande appartenant à root dans `/usr/local/bin` sont eux aussi listés lors de la désinstallation et passent à la Corbeille via l’assistant administrateur de Mole. Les fichiers ordinaires déplacés dans la Corbeille peuvent être récupérés tant qu’ils y restent. Les programmes installés avec Homebrew passent toujours par sa commande de désinstallation. Les sessions en base de données exigent le fichier exporté et ses instructions de restauration : tout ne se restaure pas en faisant glisser un élément hors de la Corbeille, et la copie de récupération doit encore exister. Ces changements arriveront avec la prochaine version de Mole. ## Ce qui n’est pas encore fait Certaines choses ne sont pas encore faites. Mole ne modifiera pas votre configuration du shell pour retirer les lignes ajoutées par les outils d’IA ; l’idée est plutôt de nommer ces lignes dans les détails de désinstallation. Les worktrees d’outils comme Cursor et Conductor ne sont pas inclus, car je n’ai pas encore de données réelles les concernant sur mon Mac. Au moment de ce test, les anciennes sessions d’opencode et de Devin ne pouvaient pas être nettoyées par ancienneté dans Mole. Je n’ai pas testé MiniMax cette fois, il n’est donc pas encore pris en charge. ## Suite : les anciennes sessions OpenCode et Devin Le 1er octobre, j’ai ajouté au code la prise en charge des anciennes sessions OpenCode et Devin, selon la durée de conservation ou après avoir établi que leurs dossiers de travail ont disparu. Un disque hors ligne ou un dossier illisible ne compte pas comme supprimé. Mole conserve une copie de récupération avant d’utiliser la méthode de suppression de l’outil et d’en vérifier le résultat. OpenCode garde son export JSON ; Devin garde la session choisie et ses enregistrements associés, avec des instructions de restauration. Un outil actif ou un contrôle échoué empêche le nettoyage. Ce travail visait la Preview suivante et n’était pas dans le téléchargement publié à ce moment-là. Je n’ai pas mesuré l’espace récupérable sur la base réelle de l’utilisateur. Avec les tests précédents de plus de 700 apps, je constate que beaucoup de produits ne respectent pas certains principes de base du développement logiciel. Ils ne sont pas toujours aussi professionnels et propres qu’on l’imagine. Cela me donne encore plus envie de garder Mole simple, d’approfondir ses capacités, de ne pas prendre de données inutiles et de ne jamais envoyer les fichiers locaux ou le contenu des conversations. Je n’ajoute même pas de statistiques d’utilisation. J’aimerais continuer avec ce même soin sur la durée. S’il y a sur votre Mac des outils d’IA dont vous aimeriez que Mole s’occupe, ou un type de nettoyage qui vous pèse plus que les autres, dites-le-moi dans le [fil de discussion](https://github.com/tw93/Mole/discussions/1604). Toutes les apps testées jusqu’ici figurent dans la [liste des apps testées](https://mole.fit/tested-apps), et si vous préférez faire le ménage à la main, le [guide de nettoyage des outils de code IA](https://mole.fit/fr/blog/how-to-clean-up-ai-coding-tools-mac) explique comment. Je les ajouterai aux tests, puis aux fonctions quand le nettoyage aura été confirmé comme adapté. Ce travail demandera sans doute un entretien de longue durée. --- Canonical HTML page: https://mole.fit/fr/blog/testing-ai-tools-for-mole Blog index for agents: https://mole.fit/fr/blog/llms.txt Site index for agents: https://mole.fit/llms.txt