Supprimer les fichiers restants après désinstallation

Pointez deux scanners de résidus vers la même application désinstallée et vous obtiendrez deux listes. Ce n’est pas un bug. Chaque outil choisit sa propre règle d’appartenance, sa propre liste d’exclusions et sa propre limite de travail d’administrateur. Ces trois choix décident de tout ce qui s’affiche à l’écran. L'important est de comprendre à quelle app appartiennent les fichiers. Une longue liste de résidus n'est pas utile si elle contient des données dont une autre app a encore besoin.

Ce guide porte sur l’état d’après : l’application est déjà partie, ou vient de tomber dans la Corbeille, et vous voulez examiner le résidu avec le même soin qu’un désinstalleur aurait dû appliquer. Pour la séquence complète tant que l’application tourne encore, voir désinstallation complète. Pour les choix de produit, voir au-delà d’AppCleaner.

En bref : glisser une application vers la Corbeille n’enlève que le bundle ; ses données restent sous ~/Library dans Application Support, Caches, Preferences et Containers. Attribuez les résidus par identifiant de bundle, jamais par taille ni par nom, et examinez chaque candidat avant de supprimer, ou utilisez un désinstalleur qui impose exactement cela.

Ce que « désinstaller » signifie vraiment sur macOS

macOS ne traite pas une application comme un seul objet avec un seul bouton de suppression. Il y a au moins trois couches :

Glisser vers la Corbeille ne garantit que la première couche. La couche du milieu est là où les outils génériques aident. La troisième est celle où ils prétendent souvent et échouent : pilotes, extensions réseau, helpers privilégiés, daemons de licence. Apple recommande encore de préférer l’application Uninstall du fournisseur pour cette raison (guide Apple de désinstallation).

Où vivent vraiment les résidus utilisateur

La plupart des résidus tiers se regroupent sous la Library du home :

Les chemins système sous /Library (LaunchDaemons, PrivilegedHelperTools, receipts sous /private/var/db/receipts) sont un palier de risque plus élevé. Préférez le désinstalleur du fournisseur ; traitez les scanners génériques comme purement consultatifs à ce niveau.

Une application sandboxée paraît souvent soignée : conteneur principal sous ~/Library/Containers/<bundle id>. Elle peut malgré tout utiliser des App Groups, Application Scripts, caches partagés, CloudKit ou éléments du Keychain. Le sandbox restreint l’accès direct aux fichiers ; il ne garantit pas une empreinte à un seul répertoire. Une application hors sandbox peut se disperser dans Application Support, Caches, Preferences, Logs, Saved Application State, WebKit et Cookies. Plus large est la dispersion, plus deux outils ont de raisons de diverger.

L’attribution est toute la compétence

La découverte sûre des résidus s’appuie sur l’identité, pas sur les noms marketing.

Identifiant de bundle versus nom d’affichage

com.example.widget reste stable à travers les renommages et les localisations. Les noms d’affichage, non. Deux produits peuvent partager un dossier d’entreprise (…/Application Support/Google) alors qu’un seul est désinstallé. Faire correspondre « Google » comme chaîne, c’est ainsi que les scanners inventent des faux positifs de plusieurs gigaoctets.

La correspondance par identifiant limite les faux positifs, mais les données partagées restent à vérifier. Elle peut manquer les dossiers qui portent seulement le nom de l'application.

La correspondance par nom trouve ces dossiers, et aussi ce qui partage seulement un mot. Elle trouve davantage, et se trompe plus souvent.

Contrôles pratiques avant toute suppression :

mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null

Si quoi que ce soit avec cet id existe encore, traitez les chemins de support partagés comme vivants.

Helpers et identités embarquées

Les applications modernes embarquent des helpers avec des ids liés : com.example.widget.helper, des noms déclarés dans SMPrivilegedExecutables, des login items sous Contents/Library/LoginItems. Un scanner soigneux recueille ces ids depuis le bundle avant que l’application disparaisse. Une fois le bundle parti, il ne vous reste que ce qui a été enregistré ou ce qui siège encore sur le disque sous des noms exacts.

Group containers

~/Library/Group Containers/ détient à dessein des données de suite partagées :

• group.<bundle id>
• noms liés à l’équipe tels que <TeamID>.<bundle id>
• espaces partagés group.* utilisés par plusieurs applications

Seuls les chemins exacts portés par le propriétaire sont candidats à une association automatique. Les arborescences de groupe partagées doivent rester en revue seule, ou intouchées tant qu’une sœur demeure. C’est la catégorie où les outils qui « trouvent plus » causent de vrais dégâts.

Variantes de nom et builds de canal

Foo Beta peut laisser Foo Beta, FooBeta, et parfois un dossier stable Foo qui appartient au canal release encore installé. Les noms de base dépouillés du canal sont un fort risque de faux positif : gardez-les en revue seule sauf preuve que l’application stable est partie.

Trois points d’entrée sûrs

1. Les désinstalleurs du fournisseur d’abord

Les agents de sécurité, clients VPN, pilotes audio et outils d’endpoint connaissent leurs propres receipts et l’ordre de démontage des extensions. Exécutez-les avant toute promenade dans Library. La suppression de fichiers n’est pas un flux fiable de désactivation pour les extensions système ou réseau ; macOS les enregistre.

2. Revue une fois l’application déjà partie

Quand le .app est parti, cherchez les chemins encore marqués de cet id de bundle ou de variantes de nom exactes. Defaults conservateurs :

• Souvent OK si possession établie : caches, logs, saved state, rapports de plantage
• Examiner avec soin : Application Support, Containers, Preferences (licences, mail hors ligne, bases de projets)
• En général laisser : Group Containers sans possession exacte, Documents hors Library, tout ce dont un autre id a encore besoin

Mesurez les candidats :

du -sh ~/Library/Application\ Support/<Name> \
  ~/Library/Caches/<bundle.id> \
  ~/Library/Containers/<bundle.id> 2>/dev/null

Les erreurs de permission signifient en général que Terminal n’a pas Full Disk Access, pas que le dossier est vide.

3. L’instant où l’application atterrit dans la Corbeille

Beaucoup de gens mettent à la corbeille d’abord et réfléchissent ensuite. Un watcher qui remarque un nouveau .app dans ~/.Trash, lit son identité Info.plist, scanne les fichiers de support liés et ouvre un panneau de revue rattrape le résidu sans chasse au trésor. Contraintes de conception qui séparent l’utile du nuisible :

• Ne jamais supprimer automatiquement le bundle mis à la corbeille (Put Back doit fonctionner)
• Ne jamais s’ouvrir pour les classes protégées / AV / MDM
• Consommer une suppression one-shot lorsque le nettoyeur lui-même a mis l’application à la corbeille pendant la désinstallation, sinon le panneau course le flux de désinstallation
• Conditionner à Full Disk Access ; échouer en silence sans lui plutôt que d’inviter depuis l’arrière-plan

Le scan de résidus de Mole soustrait d’abord les chemins encore revendiqués par une app installée, un identifiant de bundle ou un reçu, et laisse décoché ce qui reste ambigu. Il montre identité et taille et envoie les suppressions récupérables à la Corbeille ; être gros dans Library ne suffit jamais.

Les orphelins ne sont pas « tout ce qui est gros dans Library »

Découvrir les résidus d’applications oubliées exige une soustraction de claims : énumérer les dossiers de support candidats, puis soustraire tout ce qui est encore revendiqué par le logiciel installé (ids de bundle, applications en cours, enregistrement Launch Services, racines fournisseur). Si le scan de claims est partiel (délai dépassé, dossiers illisibles), le résultat sûr est zéro orphelin, pas une liste approximative. Les outils qui trouvent toujours des dizaines d’applications « indésirables » sur un Mac propre optimisent un chiffre de vente.

La date de modification compte aussi : une configuration réécrite la semaine dernière peut appartenir à un outil en ligne de commande que le scanner ne reconnaît pas. Les fichiers récemment modifiés doivent être conservés en cas de doute.

Exemple concret : deux outils, une suite fournisseur

Vous désinstallez le Produit A d’une société qui livre aussi le Produit B, encore installé.

• Outil 1 (axé identifiants) : petite liste, surtout des chemins com.vendor.productA.*.
• Outil 2 (axé noms) : ajoute ~/Library/Application Support/Vendor (4 Go) et un group container que les deux produits utilisent.

L’outil 2 paraît plus exhaustif. Il propose la suppression qui peut casser le Produit B. Le total en bas de l’écran n’est pas un score de qualité. Les catégories au-dessus le sont.

Le receipt orphelin de Homebrew

Si l’application venait de Homebrew Cask, retirer seulement le .app peut laisser un enregistrement Caskroom qui bloque la réinstallation. Après les résidus fichiers :

brew list --cask

Si le token reste, brew uninstall --cask <token> efface l’association (n’acceptez --zap que si vous voulez le nettoyage plus large de brew). « Cask is not installed » signifie que ce cask n’est pas enregistré dans l’installation Homebrew interrogée, pas une raison de rm -rf des chemins Caskroom au hasard.

Ce qu’il faut refuser même quand le nom correspond

• Sœurs encore installées et jumeaux de canal
• Group containers partagés et dossiers parents fournisseur
• Receipts et helpers privilégiés sans désinstalleur validé
• Documents utilisateur hors Library
• Magasins de chat IA et répertoires de modèles qui côtoient des chemins de cache (nettoyage IA)

Erreurs courantes

Maximiser la liste trouvée. Plus de candidats signifie souvent une pire attribution.

Supprimer les Group Containers par défaut. Partagés à dessein.

Sauter le désinstalleur du fournisseur pour VPN, AV, audio, virtualisation.

Mesurer sans Full Disk Access, puis conclure « il ne reste rien ».

Vider la Corbeille immédiatement après une suppression massive de résidus. Gardez un jour d’usage normal si quelque chose d’important a pu être mal attribué.

Vérifier

1. Remesurez les chemins retirés.
2. Confirmez qu’aucun login item ni launch agent pour cet id ne reste (éléments de démarrage).
3. Lancez les applications sœurs du même fournisseur.
4. Videz la Corbeille seulement une fois les suppressions acceptées.

Ordre des opérations

1. Cherchez un désinstalleur fournisseur si l’application avait des pilotes, extensions ou helpers.
2. Exportez ou désautorisez tant que l’application tourne encore, si cela compte.
3. Quittez l’application et les helpers visibles.
4. Retirez le bundle (ou confirmez qu’il est déjà dans la Corbeille).
5. Examinez les résidus par identité ; laissez les conteneurs partagés tranquilles.
6. Traitez les receipts cask Homebrew le cas échéant.
7. Gardez les éléments dans la Corbeille pendant un usage normal du Mac, puis videz.

Le premier jour après une désinstallation

Beaucoup de gens vident la Corbeille à la seconde où l’application disparaît. Un rythme plus lent ne coûte rien et garde un chemin de retour :

1. Le premier jour, mettez à la Corbeille le bundle et seulement les caches dont vous avez confirmé qu’ils se régénèrent.
2. Laissez Application Support et Containers en place, et utilisez le Mac normalement pendant une journée.
3. Si les applications sœurs et les autres produits du fournisseur démarrent toujours normalement, vérifiez les données personnelles et leurs sauvegardes avant de supprimer le deuxième lot.
4. Pour les chemins dont vous doutez encore, notez la taille avec du -sh et décidez une semaine plus tard.

La Corbeille occupe le même volume : rien n’est libéré tant que vous ne la videz pas. Ce que vous gagnez à attendre, c’est une fenêtre de récupération. Si le disque est réellement plein, videz d’abord les caches régénérables pour respirer, et gardez les chemins litigieux pour plus tard.

Permissions et visibilité

Sans Full Disk Access, Terminal et la plupart des scanners ne voient pas l’intérieur des Containers ni une partie de la Library. du affiche des erreurs de permission et termine quand même sur un total, et ce total ignore tout ce qu’il n’a pas pu ouvrir. Cela ne se lit pas « il ne reste rien », mais « vous n’avez pas le droit de regarder ».

• Donnez Full Disk Access à Terminal, ou à l’outil qui fait le scan, puis remesurez.
• Comparez les chiffres avant et après. Décider à partir de la passe à moitié aveugle, c’est ainsi qu’un conteneur de plusieurs gigaoctets se retrouve déclaré vide.
• Reprenez Full Disk Access aux outils que vous n’utilisez plus. C’est la permission de lecture la plus large du Mac, et une fois accordée elle survit à la raison de l’octroi.

Comment ce guide se situe par rapport à la désinstallation complète

Désinstallation complète donne l’ordre à suivre tant que l’application est encore installée : désinstalleur du fournisseur d’abord, export ou désautorisation, quitter, retirer le bundle, puis examiner ce qui reste. Ce guide part du principe que le bundle est déjà parti, ce qui supprime les preuves faciles, et consacre sa longueur à la moitié restante : décider quels fichiers appartenaient à l’application et lesquels étaient seulement partagés.

Pour aller plus loin

• Apple : Supprimer ou désinstaller des apps sur Mac
• Connexe : désinstallation complète, alternatives à AppCleaner, ce que les nettoyeurs ne doivent jamais supprimer

Le nettoyage des résidus est de l’entretien d’identité. La compétence n’est pas de maximiser les gigaoctets ; c’est de prouver la possession, de protéger l’état partagé, et de garder les suppressions récupérables.

FAQ

Est-il sûr de supprimer moi-même des fichiers résiduels sous ~/Library ?

Seulement avec attribution : faites correspondre le dossier à l’identifiant de bundle de l’application, pas à sa taille ni à un nom qui se ressemble, et examinez chaque élément avant qu’il parte. Une mauvaise estimation peut emporter les données d’une autre application ou vos propres documents.

Pourquoi les applications laissent-elles des fichiers derrière elles ?

macOS n’a pas de contrat de désinstallation : glisser le bundle vers la Corbeille est tout le mécanisme, et tout ce que l’application a écrit à l’exécution reste là où cela a été écrit.

Une réinstallation recréera-t-elle ce que j’ai supprimé ?

L'installation ou l'app peut recréer des caches et des réglages par défaut. Cela ne restaure pas les documents personnels, les conversations ni l'ancien état d'activation. Une réinstallation ne remplace pas une sauvegarde.