App Mac impossible à désinstaller : sept causes possibles

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 ; ce qui suit suppose que celle-ci a déjà échoué.

Partez du symptôme

• « 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. Vérifiez les installations automatiques, la gestion à distance et les auxiliaires restants.
• 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 peut être refusée.
• rm en root répond « Operation not permitted ». SIP ou une autre protection peut bloquer l'accès.
• 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 d’Apple suggère le mode sans échec.

2. Un agent ou un démon launchd relance un auxiliaire

Un auxiliaire peut redémarrer après avoir été arrêté si son exécutable existe encore. launchd ne recrée pas un bundle supprimé. Si le bundle revient, cherchez un programme de mise à jour ou une réinstallation. L'absence de processus à un instant donné ne permet pas d'exclure un service lancé à la demande.

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 par défaut en root ou sous l'utilisateur configuré, avant toute connexion, 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 <path> 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 peuvent enregistrer des services via SMAppService avec les auxiliaires et leurs définitions dans le bundle plutôt que dans les dossiers Launch habituels. macOS gère leur enregistrement. Vous pouvez consulter les éléments dans Réglages Système > Général > Éléments de connexion et extensions (guide des éléments au démarrage).

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). 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. L'absence de cette section ne suffit pas à exclure une gestion à distance ; vérifiez aussi l'état d'inscription.

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 <id> liste les chemins qu’un paquet a placés, et sudo pkgutil --forget <id> 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"

Cette sortie ne teste que l'écriture dans le bundle, pas les droits nécessaires sur son dossier parent pour le supprimer. Elle n'exclut donc pas un problème de permissions. Vérifiez aussi 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 dépendent de l’utilisateur, du groupe et des droits sur le chemin concerné. Pour supprimer une app, les droits sur son dossier parent comptent aussi : le propriétaire du bundle ne suffit pas à expliquer un refus. sudo ne remplace pas cette vérification et ne contourne pas toutes les protections. TCC gère séparément les autorisations de confidentialité. La Gestion des apps protège la modification et la suppression du 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 peut refuser l'accès même à root. EACCES, affiché comme Permission denied, peut notamment indiquer un manque de droits d'écriture ou de parcours sur le dossier parent. EPERM, affiché comme Operation not permitted, n'identifie pas SIP à lui seul. Vérifiez le chemin et les protections au lieu de déduire du seul message qu'il faut plus de privilèges.

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 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 ». Il concerne les achats effectués ailleurs, pas le simple fait qu'une app reste installée sur un autre Mac. En cas d'installation inattendue, vérifiez-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/<vendor>.

Un auxiliaire privilégié survit. Un logiciel qui a eu besoin de root s’installe dans /Library/PrivilegedHelperTools/<label> avec une /Library/LaunchDaemons/<label>.plist correspondante. Les deux sont possédés par root et hors du bundle, donc mettre l’app à la Corbeille ne touche ni l’un ni l’autre.

ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons \
  /Library/PrivilegedHelperTools 2>/dev/null

Pour le côté données, voir fichiers résiduels après désinstallation.

Faire ce diagnostic dans Mole

La version manuelle de cet article coûte cinq écrans : Moniteur d’activité, trois dossiers launchd, Éléments de connexion et extensions, Confidentialité et sécurité, et Finder. Mole réunit les éléments appartenant à une app sur un seul onglet, et le scan est toujours gratuit, donc il fonctionne comme un diagnostic en lecture seule que vous l’achetiez ou non.

Ouvrez l’onglet Apps de Mole. Il contient trois segments : l’inventaire des apps installées, les mises à jour disponibles, et les éléments au démarrage. Ce dernier est l’inventaire launchd et éléments de connexion que cet article vous a demandé d’assembler à la main, donc la cause d’un « elle revient » est visible avant la suppression plutôt qu’après.

Sélectionnez une app et Mole résout son identifiant de bundle, puis trouve ce que cette identité possède : Application Support, Caches, Preferences, Containers, HTTPStorages, et les agents ou démons de lancement dont la plist référence réellement l’app plutôt que de simplement partager un mot avec son nom. Chaque candidat porte son chemin, sa taille, et la preuve qui l’a rattaché, et tout ce qui est peu fiable arrive décoché.

Confirmer exécute l’ordre que recommande cet article, appliqué plutôt que juste retenu. Mole quitte l’app et les auxiliaires nichés dans son bundle, évince ses auxiliaires d’élément de connexion, décharge tout élément de lancement approuvé via launchctl avant que sa plist ne soit retirée, et revalide chaque chemin au moment de la suppression. Les suppressions vont à la Corbeille, si bien qu’une erreur se répare en la ressortant.

Mole signale ensuite les éléments ignorés et échoués avec leur chemin plutôt qu’un total de succès, donc une ligne refusée parce que la Gestion des apps est refusée, ou parce qu’un chemin est possédé par root et que le garde-fou l’a rejeté, vous dit laquelle des causes ci-dessus vous venez de rencontrer. Un outil qui affiche une coche sur une écriture refusée est exactement pourquoi les gens passent une soirée à s’interroger sur une icône de barre de menus. Tout ce que fait Mole tourne en local, et les opérations sur les fichiers s’ajoutent à ~/Library/Logs/mole/operations.log. Dans un terminal, Mole CLI est gratuit et open source, et mo uninstall accepte --dry-run pour que vous lisiez d’abord la liste des chemins.

Mole ne combat pas les trois causes qu’il ne peut pas gagner : il ne désactivera pas SIP ni ne retirera une app Apple d’origine du volume scellé, il ne peut pas outrepasser un profil de configuration qui réinstalle un logiciel sur un Mac géré, et pour les agents de sécurité, les clients VPN et les produits de virtualisation, il ne remplace pas le désinstalleur de l’éditeur qui connaît l’ordre de démontage. Quand la Gestion des apps est refusée, Mole signale l’échec plutôt que de contourner le problème en élevant ses privilèges.

FAQ

Pourquoi une app revient-elle après que je l’ai supprimée ?

Distinguez un auxiliaire relancé d'une app réinstallée. launchd peut relancer un exécutable présent, pas recréer des fichiers supprimés. Une réinstallation peut venir d'un programme de mise à jour, d'une mise à niveau Homebrew d'un cask encore enregistré, de MDM ou du téléchargement automatique de nouveaux achats sur d'autres appareils. Pour une app Homebrew, utilisez brew uninstall --cask au lieu de déplacer seulement le bundle.

Puis-je supprimer les apps intégrées d’Apple si je désactive SIP ?

Techniquement oui, et c’est un mauvais échange : une dégradation de sécurité pour toute la machine, faite depuis Recovery, contre un bundle qui revient à la prochaine mise à jour de macOS quand le volume système scellé est remplacé. Retirez-la plutôt du Dock et des Éléments de connexion.

Le Finder me demande mon mot de passe pour supprimer une app. Y a-t-il un problème ?

Non. Un installateur .pkg a placé le bundle là en root, donc le déplacer exige une authentification. L’échec qui mérite de vous inquiéter est l’inverse : aucune invite, aucune erreur, rien ne se passe. C’est généralement la Gestion des apps refusée sous Confidentialité et sécurité dans Réglages Système, et sudo ne le corrige pas, parce que la barrière est rattachée au programme qui demande plutôt qu’à l’utilisateur.

Pour aller plus loin

• Comment désinstaller complètement des apps sur Mac pour la séquence normale et les couches de Library qu’elle passe en revue.
• Comment désinstaller un antivirus sur Mac pour les logiciels avec extensions système, où l’ordre de démontage est tout le travail.
• Comment désactiver les programmes au démarrage sur Mac pour le côté launchd et Éléments de connexion une fois que plus rien ne résiste.