# Quand une app Mac refuse de se désinstaller : sept causes, un symptôme chacune
> Elle est en cours d'utilisation, elle revient après suppression, rien ne se passe du tout, ou elle est grisée. Chaque symptôme pointe vers exactement une cause, d'un auxiliaire en cours d'exécution à launchd, SIP, la Gestion des apps et MDM.
Published: 2026-08-18 | Updated: 2026-08-22
Une désinstallation ratée sur macOS n’est pas un seul problème. Le Finder peut refuser de
déplacer le bundle. Le déplacement peut réussir et l’app peut être de retour à la
connexion suivante. Le bundle peut disparaître tandis que l’auxiliaire qui vous embêtait
continue de tourner. Chaque cas est un mécanisme différent avec un correctif différent,
donc partez de ce que votre Mac a fait exactement. Pour la séquence ordinaire, voir
[désinstallation complète](https://mole.fit/fr/blog/how-to-completely-uninstall-apps-on-mac) ; ce qui suit
suppose que celle-ci a déjà échoué.
## Partez du symptôme
Le libellé du refus est un diagnostic en soi. Deux de ces six cas ne produisent aucune boîte de dialogue, ce qui explique qu’on les lise comme un outil cassé.
- **« L’élément n’a pas pu être déplacé dans la Corbeille car il est ouvert. »**
Quelque chose tourne, souvent pas l’app que vous avez quittée.
- **Elle a été supprimée, et elle est revenue.** Une tâche launchd, un profil, ou un
gestionnaire de paquets l’a remise en place.
- **Le Finder demande un mot de passe administrateur.** Un `.pkg` a laissé le bundle
possédé par root. Normal.
- **Rien ne se passe. Aucune boîte de dialogue, aucune erreur.** La permission Gestion
des apps est refusée.
- **`rm` en root répond « Operation not permitted ».** Protection de l’intégrité du
système.
- **Grisé, ou réapparaît sur un Mac professionnel.** Un profil de configuration ou un
MDM le possède.
## 1. L’app, ou l’un de ses auxiliaires, tourne encore
Le Finder refuse de déplacer un bundle dont des fichiers sont ouverts, et quitter le
processus que vous voyez n’arrête pas tout ce que l’app a démarré. Le Moniteur
d’activité liste chaque processus, pas seulement ceux avec une fenêtre. Recherchez le nom
de l’éditeur et lisez l’ensemble des résultats : une app appelée Foo embarque couramment
`Foo Helper`, un `FooUpdater`, et un bundle d’élément de connexion avec un nom
d’affichage sans rapport. La fenêtre **menu Pomme > Forcer à quitter** ne remplace pas
cette vérification, car elle ne liste que les applications ayant une présence à l’écran.
```
pgrep -fl -i foo
lsof +D /Applications/Foo.app 2>/dev/null | awk '{print $1, $2}' | sort -u
```
`pgrep -fl` fait correspondre la ligne de commande complète, donc il attrape un
auxiliaire dont le chemin de l’exécutable porte le nom de l’éditeur même quand son nom de
processus ne le fait pas. `lsof +D` signale chaque processus qui garde un fichier ouvert
à l’intérieur du bundle.
Forcer le parent à quitter n’arrête pas un auxiliaire de façon fiable. Un auxiliaire est
son propre processus avec son propre PID, donc tuer le parent l’orpheline, sauf si le
parent le démonte lui-même en quittant. Et si launchd gère l’auxiliaire, tuer l’un ou
l’autre ne fait que dire à launchd de le relancer. C’est le sujet de la section suivante.
Un aperçu Quick Look ou l’indexation Spotlight peuvent aussi garder des fichiers du
bundle ouverts, et un redémarrage efface les deux. Si le message revient, le
[guide de retrait d’apps](https://support.apple.com/guide/mac-help/mh35835/mac) d’Apple
suggère le mode sans échec.
## 2. Un agent ou un démon launchd la ramène
C’est le cas « je l’ai supprimée et elle est revenue », le plus souvent mal
diagnostiqué : les gens vérifient le Moniteur d’activité, ne voient rien, et concluent
que l’app ne tournait pas. Le lancement à la demande signifie que ce n’est pas une
preuve.
launchd supervise les tâches en arrière-plan. Une tâche est une property list dotée d’un
`Label`, d’un programme, et de conditions pour son exécution. `RunAtLoad` la lance quand
la tâche se charge, `KeepAlive` la relance quand elle se termine. Une tâche sans ni l’un
ni l’autre revient quand même : `MachServices`, `Sockets`, `WatchPaths`,
`QueueDirectories` et `StartInterval` font tous démarrer le processus par launchd dès que
quelque chose le demande, donc un auxiliaire qui s’éteint après dix secondes d’inactivité
et redémarre sur son service Mach paraît absent à chaque vérification.
Les définitions vivent à trois endroits. `~/Library/LaunchAgents` n’est qu’à vous, à
l’intérieur de votre session de connexion ; `/Library/LaunchAgents` s’exécute pour chaque
utilisateur à la connexion ; et `/Library/LaunchDaemons` s’exécute pour tout le système
en root avant que quiconque ne se connecte, ce qui explique pourquoi un démon survit à
une désinstallation manuelle alors qu’un agent souvent non. `/System/Library/Launch*`
appartient à Apple et est protégé.
```
launchctl list | grep -i foo
launchctl print-disabled gui/$(id -u) | grep -i foo
grep -l -i foo ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist \
/Library/LaunchDaemons/*.plist 2>/dev/null
```
Dans `launchctl list`, une étiquette avec un PID tourne actuellement, et une avec un
tiret est chargée et attend un déclencheur ; `print-disabled` lit la base de données
persistante des états désactivés, un fait distinct de l’existence d’une plist. Lisez le
candidat avec `plutil -p ` et vérifiez que `Program` ou `ProgramArguments` pointe
vers l’app que vous retirez : les éditeurs ne nomment pas toujours le fichier d’après
l’étiquette qu’il contient.
### L’ordre compte
Arrêtez et désactivez d’abord la tâche, puis retirez la plist, puis retirez l’app.
```
launchctl bootout gui/$(id -u)/com.vendor.foo.helper
sudo launchctl bootout system/com.vendor.foo.daemon
launchctl disable gui/$(id -u)/com.vendor.foo.helper
```
Supprimez la plist pendant que la tâche est chargée, et launchd garde un service dont la
définition n’existe plus sur le disque ; il s’exécute jusqu’au prochain redémarrage et
peut laisser une entrée résiduelle dans la base de données des états désactivés. Retirer
l’app en premier est pire : la tâche redémarre en visant un exécutable manquant et échoue
en boucle, d’où viennent les cas « elle a disparu mais apparaît toujours dans Éléments de
connexion ».
Sur macOS 13 et plus récent, les apps s’enregistrent via
[`SMAppService`](https://developer.apple.com/documentation/servicemanagement/smappservice)
et ces enregistrements vivent à l’intérieur du bundle de l’app, donc il se peut qu’il n’y
ait aucune plist à trouver. Ceux-ci relèvent de la gestion des tâches en arrière-plan,
contrôlée dans **Réglages Système > Général > Éléments de connexion et extensions**
([guide des éléments au démarrage](https://mole.fit/fr/blog/how-to-disable-startup-programs-on-mac)).
## 3. C’est une app système protégée par SIP
La protection de l’intégrité du système est une politique au niveau du noyau, pas un
simple bit de permission. Apple la décrit comme utilisant des permissions noyau pour
limiter l’inscriptibilité des fichiers système critiques, appliquée « à chaque processus
s’exécutant sur le système, que ce processus tourne en bac à sable ou avec des
privilèges administratifs »
([Sécurité des plateformes Apple](https://support.apple.com/guide/security/system-integrity-protection-secb7ea06b49/web)).
Depuis Big Sur, le contenu système réside aussi sur un volume distinct, scellé
cryptographiquement. `csrutil status` affiche si la protection est activée, et Apple est
explicite : « vous ne pouvez pas retirer les apps requises par votre Mac », un ensemble
qui inclut Mail, Musique, Livres, Notes, Podcasts, Plans, Actualités et Bourse.
Désactiver SIP pour supprimer un seul bundle est un mauvais échange. Cela suppose de
démarrer en mode Recovery et de changer une politique de sécurité valable pour toute la
machine ; sur les Mac Intel, Apple note que la désactiver retire la protection de toutes
les partitions du support de stockage physique, et sur Apple Silicon, le Mac quitte la
Sécurité complète. Le gain ne dure pas non plus : le volume système est intégralement
remplacé à la prochaine mise à jour de macOS, et aucun espace utilisable n’est récupéré.
Mieux : glissez l’icône hors du Dock, retirez-la de
**Réglages Système > Général > Éléments de connexion et extensions**, et si elle continue
d’ouvrir vos fichiers, changez le gestionnaire avec
**Lire les informations > Ouvrir avec > Modifier tout**.
## 4. Elle a été installée par MDM ou un profil de configuration
Sur un Mac géré, une app peut être repoussée selon le calendrier du serveur de gestion,
et un profil peut être marqué comme non retirable. Les symptômes sont un retrait qui
s’annule lui-même quelques heures plus tard, un contrôle grisé, ou une recherche launchd
qui ne trouve rien parce que la réinstallation est pilotée à distance. Vérifiez
**Réglages Système > Général > Gestion des appareils** ; si cette section est absente, le
Mac n’est pas géré et ce n’est pas votre cause.
```
profiles status -type enrollment
sudo profiles list
```
La première rapporte l’inscription via l’inscription automatisée des appareils et si
elle est approuvée par l’utilisateur ; la seconde liste les profils installés et exige
les droits root. Demandez ensuite au service informatique. Les recommandations d’Apple
sont de demander à quiconque a fourni un profil que vous ne pouvez pas retirer, et Apple
avertit que retirer un profil supprime tout ce que ce profil configurait, donc un profil
qui porte votre compte mail l’emporte avec lui.
## 5. La propriété, et la permission qui échoue en silence
**Le Finder demande un mot de passe administrateur.** Normal. Un installateur `.pkg`
s’exécute en root et laisse le bundle possédé par root, donc le déplacer exige une
authentification. Confirmez avec `ls -ld /Applications/Foo.app`. Les reçus valent la
peine d’être connus tant qu’on y est : `pkgutil --files ` liste les chemins qu’un
paquet a placés, et `sudo pkgutil --forget ` retire le reçu de
`/private/var/db/receipts` sans supprimer un seul fichier.
**Rien ne se passe du tout.** Aucune invite, aucune erreur, l’app est toujours dans
`/Applications`, et l’outil que vous avez utilisé signale un échec vague ou se rabat sur
autre chose. Sur macOS 14 et plus récent, c’est généralement la Gestion des apps,
qu’Apple décrit comme « Autoriser les apps à mettre à jour ou supprimer d’autres apps sur
votre Mac ». Le signe révélateur, c’est que le chemin est inscriptible au sens POSIX et
que l’écriture échoue quand même :
```
test -w /Applications/Foo.app && echo "posix says yes"
```
Si cela s’affiche et que le retrait ne se produit toujours pas, les permissions ne sont
pas votre problème. Rendez-vous dans
**Réglages Système > Confidentialité et sécurité > Gestion des apps**, activez l’app qui
fait le retrait, puis relancez-la, car de nombreuses apps ne consultent la permission
qu’au démarrage.
## Sous le capot : trois refus qui se ressemblent
Les permissions POSIX sont la première barrière : le bundle est possédé par root, vous
ne l’êtes pas, et `sudo` résout le problème, parce que la vérification ne porte que sur
l’identité de l’utilisateur. TCC, la couche de confidentialité derrière Réglages
Système, décide une fois POSIX franchi. La Gestion des apps est une barrière TCC pour une
seule opération, modifier ou supprimer le bundle d’une autre app. Être administrateur ne
la satisfait pas, et `sudo` non plus, parce qu’elle est rattachée au programme demandeur
plutôt qu’à l’utilisateur, ce qui explique pourquoi son refus peut surgir comme une
erreur générique sans invite.
SIP est en dessous des deux et refuse root d’emblée. Un refus POSIX pose `EACCES` et
affiche `Permission denied` ; un refus SIP pose `EPERM` et affiche
`Operation not permitted`. Le premier signifie réessayez avec de l’autorité, le second
signifie qu’il n’y a aucune autorité avec laquelle réessayer.
## 6. Une extension système ou un filtre réseau est encore actif
Les logiciels de sécurité, les clients VPN et les produits de virtualisation installent
des extensions système. Le bundle de l’app enregistre l’extension ; il n’est pas
l’extension. Supprimez le conteneur pendant que l’extension est active, et
l’enregistrement se retrouve sans propriétaire, ce qui explique comment un Mac continue
de filtrer le trafic via un logiciel que vous croyez avoir retiré.
```
systemextensionsctl list
```
La sortie montre l’identifiant d’équipe, l’identifiant de bundle, et un état tel que
`[activated enabled]`. La désactivation relève de l’app qui la contient et exige souvent
un redémarrage, donc lancez d’abord le désinstalleur de l’éditeur.
[Désinstaller un antivirus sur Mac](https://mole.fit/fr/blog/how-to-uninstall-antivirus-mac) couvre l’ordre
de démontage pour cette catégorie.
## 7. Elle vient de l’App Store, ou de Homebrew
**Apps de l’App Store.** Supprimer le bundle ne retire pas l’achat. Le cas qui piège les
gens est le réglage qu’Apple formule ainsi : « Télécharger automatiquement les apps que
vous avez achetées sur l’App Store sur d’autres Mac et appareils » : si un second Mac sur
le même compte l’a encore, ce réglage peut la ramener. Désactivez-le dans
**App Store > Réglages**.
**Casks Homebrew.** Si vous avez installé avec `brew install --cask foo`, mettre l’app à
la Corbeille laisse Homebrew croire qu’elle est installée. `brew list --cask` montre
toujours le token, et le prochain `brew upgrade` peut réinstaller l’app que vous venez de
supprimer, une vraie cause du « elle est revenue » sans aucune tâche launchd impliquée.
Lancez plutôt `brew uninstall --cask foo`. La page de manuel de Homebrew décrit `--zap`
comme retirant « tous les fichiers associés à un cask » et avertit qu’il « peut retirer
des fichiers partagés entre applications », donc n’y recourez que délibérément.
## Après une suppression réussie : ce qui reste
**Éléments de connexion et extensions la liste encore.** Soit une entrée « Ouvrir à la
connexion » pointant vers un chemin manquant, soit un enregistrement de gestion des
tâches en arrière-plan pour un service dont le programme a disparu. Retirez-la avec le
bouton moins dans **Réglages Système > Général > Éléments de connexion et extensions** ;
macOS efface souvent ces entrées lui-même après un redémarrage.
**Une icône de barre de menus apparaît au démarrage.** Quelque chose charge encore un
binaire : généralement un agent de lancement que vous n’avez jamais retiré, ou un
auxiliaire que l’installateur a copié dans `~/Library/Application Support/`.
**Un auxiliaire privilégié survit.** Un logiciel qui a eu besoin de root s’installe dans
`/Library/PrivilegedHelperTools/
