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. Une fois l’attribution comprise, le nettoyage des résidus cesse d’être « qui trouve le plus de déchets » pour devenir « dont les erreurs coûtent le moins cher ».

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 (Delete or uninstall apps).

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 est précise et ne propose presque jamais les données d’une application sœur. Elle rate les dossiers que l’application a nommés d’après elle-même.

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

Mole rassemble l’analyse du disque, l’entretien des applications et le nettoyage avec revue d’abord dans une application Mac native. macOS et les applications propriétaires gèrent toujours les données système.

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.

Les portes de période de calme comptent aussi : une config réécrite la semaine dernière peut appartenir à un outil CLI que la marche de claims ne voit pas. Des mtimes récents doivent supprimer des candidats.

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 » alors que l’application est déjà partie est une association périmé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.

Pour aller plus loin

• Apple : Delete or uninstall apps on 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’état reconstruisible, oui : caches, receipts et préférences par défaut reviennent au premier lancement. Documents, historique de chat et licences, non, c’est pourquoi un outil soigneux ne présélectionne que ce qu’une réinstallation recréerait.