# Supprimer les fichiers restants après désinstallation
> Attribuez les résidus Library par identité de bundle, protégez les données partagées d’un éditeur, et examinez les restes après la Corbeille ou une install disparue.
Published: 2026-07-29 | Updated: 2026-08-08
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](https://mole.fit/fr/blog/how-to-completely-uninstall-apps-on-mac). Pour les
choix de produit, voir [au-delà d’AppCleaner](https://mole.fit/fr/blog/appcleaner-alternative).
**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 :
| Couche | Emplacement typique | Qui doit la retirer |
|---|---|---|
| App bundle | `/Applications`, `~/Applications`, Setapp, etc. | Vous, la Corbeille, ou un gestionnaire de paquets |
| Support utilisateur | `~/Library/…` | Scanner de résidus ou revue manuelle soignée |
| Système / privilégié | `/Library`, helpers, receipts, extensions | **Désinstalleur du fournisseur** d’abord |
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](https://support.apple.com/102610)).
Retirer le bundle de l’application n’est que la couche supérieure. Le résidu de la Library utilisateur et les helpers système sont des décisions distinctes, avec des risques différents.
## Où vivent vraiment les résidus utilisateur
La plupart des résidus tiers se regroupent sous la Library du home :
| Zone | Ce que c’est en général |
|---|---|
| `Application Support/` | Bases de données, packs hors ligne, état de projet |
| `Caches/` | Cache régénérable |
| `Containers/` et `Group Containers/` | Homes sandboxés et groupes partagés |
| `Preferences/` (+ ByHost) | Plists de réglages |
| `Logs/`, DiagnosticReports | Diagnostics |
| `Saved Application State/` | Restauration des fenêtres |
| `HTTPStorages/`, WebKit, cookies | État réseau pour cette identité |
| `LaunchAgents/` | Helpers de connexion utilisateur adossés à un plist |
| `Application Scripts/` | Paquets de scripts sandbox |
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/`. 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.
La correspondance par identité est plus étroite et plus sûre. La correspondance par nom trouve plus de résidus et se trompe plus souvent lorsque deux produits partagent un dossier fournisseur.
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.`
- noms liés à l’équipe tels que `.`
- 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.
L’attribution doit suivre l’identité de bundle jusque dans les chemins possédés, pas les dossiers fournisseur dont d’autres applications ont encore besoin.
## 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/ \
~/Library/Caches/ \
~/Library/Containers/ 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](https://mole.fit/) 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 ` 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](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac))
## 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](https://mole.fit/fr/blog/how-to-disable-startup-programs-on-mac)).
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](https://support.apple.com/102610)
- Connexe : [désinstallation complète](https://mole.fit/fr/blog/how-to-completely-uninstall-apps-on-mac),
[alternatives à AppCleaner](https://mole.fit/fr/blog/appcleaner-alternative),
[ce que les nettoyeurs ne doivent jamais supprimer](https://mole.fit/fr/blog/what-mac-cleaners-should-never-delete)
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.
---
Canonical HTML page: https://mole.fit/fr/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
