# 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-09-25
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](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
([guide Apple de désinstallation](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** 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.
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
Le scan de résidus de [Mole](https://mole.fit/fr/mac-app-uninstaller) 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 ` 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](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.
## 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](https://mole.fit/fr/blog/how-to-completely-uninstall-apps-on-mac) 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](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'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.
---
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
