Les trois façons de désinstaller une app Mac, et ce que chacune laisse derrière elle

La glisser dans la Corbeille. Intégré, gratuit, et cela supprime le paquet. Cela ne supprime rien de ce que l’app a écrit en dehors d’elle-même : préférences, caches, conteneurs, état enregistré, agents de lancement, reçus d’installation, et les entrées de Confidentialité et sécurité dans Réglages Système. Pour ces dernières, macOS ne vous donne aucun bouton. tccutil, l’outil qui les efface, retrouve une app via LaunchServices, il a donc besoin du paquet sur le disque. Tant que l’app est dans la Corbeille, cela fonctionne encore ; une fois la Corbeille vidée, il répond « No such bundle identifier » et les autorisations restent à jamais dans la base de données des autorisations. Voilà pourquoi des apps supprimées l’an dernier figurent encore sous Accessibilité.

Le désinstalleur de l’éditeur. Quand il en fournit un - Adobe, Microsoft, la plupart des clients VPN - c’est la bonne réponse, car l’éditeur sait où il a mis les choses. La plupart des apps n’en fournissent aucun.

Un désinstalleur dédié. AppCleaner le fait gratuitement depuis des années et suffit si vous voulez le paquet plus les dossiers évidents de ~/Library ; Pearcleaner en est la version open source. Unroot est construite autour d’une question plus étroite : non pas ce que l’on peut trouver, mais ce que l’on peut prouver, et ce que l’on peut remettre en place. Tout ce qui suit figure dans la version publiée.

Où elle cherche, et pourquoi chaque ligne dit pourquoi

Une analyse lit 58 emplacements - ceux auxquels vous penseriez (Application Support, Preferences, Caches, Containers, Saved Application State) et ceux auxquels vous ne penseriez pas (HTTPStorages, WebKit, Cookies, les arborescences par utilisateur sous /var/folders, les racines des modules audio, les générateurs QuickLook), plus /Library/LaunchDaemons, /Library/PrivilegedHelperTools, /var/db/receipts et /Users/Shared en dehors de votre dossier personnel. Deux sont lus de façon particulière : Application Support un niveau plus bas, car c’est le dossier imbriqué qui doit être proposé et non le dossier de l’éditeur qui emporterait tous les produits voisins, et les plists d’éléments de lancement sur leurs clés Label et ProgramArguments, car les éditeurs nomment le fichier d’après le daemon.

Vient ensuite la correspondance, là où un désinstalleur gagne la confiance ou détruit des données. Un identifiant de paquet exact est certain, tout comme cet identifiant sous forme de suite complète délimitée par des points, un groupe d’apps que l’app a déclaré dans sa propre signature de code, ou un chemin dans un reçu d’installation dont pkgutil peut prouver qu’il a installé ce paquet. Une correspondance sur le nom n’est que possible, et elle est classée comme telle.

Ce qui manque à cette liste, c’est justement l’essentiel. Des règles pour le préfixe de l’éditeur et pour l’équipe de signature ont existé et ont toutes deux été supprimées : à elles deux, elles ont trouvé 45 correspondances sur deux analyses réelles, toutes des données d’une autre app, et jamais un seul vrai reste. Même développeur ne veut pas dire même app. La règle la plus forte s’applique en dernier - un fichier rangé sous l’identifiant d’une autre app installée appartient à cette app - et chaque ligne indique pourquoi elle correspond, ce qui fait la différence entre une liste à laquelle on se fie et une liste qu’on accepte les yeux fermés.

Trois niveaux, et ce qui arrive coché

L’écran de vérification d’Unroot listant toutes les traces trouvées pour une app, regroupées sous Suppression sûre, chaque ligne montrant son chemin et la raison de la correspondance
Chaque ligne porte la raison de sa correspondance, et l’en-tête le décompte de chacun des trois niveaux.

Les résultats sont classés « suppression sûre », « à vérifier » ou « sensible », et ce classement répond à une question : avec quelle prudence traiter cette ligne. Suppression sûre veut dire réversible, dans votre dossier personnel, et appartenant certainement à l’app. À vérifier veut dire trouvé sur le nom seulement, ou partagé avec une app que vous gardez. Sensible désigne les entrées du trousseau, les assistants privilégiés, les extensions système et tout ce qui se trouve hors de votre dossier personnel - le seul niveau capable de produire la panne que tout le monde redoute.

Le côté contre-intuitif, c’est ce qui arrive coché, car ce n’est pas le niveau sûr. Une ligne est cochée quand la correspondance est certaine, pas quand elle est réversible. Confondre les deux rendait le produit malhonnête : la licence d’une app vit dans le trousseau, donc laisser ces lignes décochées signifiait que la suppression par défaut laissait discrètement l’app activée. Une ligne de trousseau sensible est cochée ; une correspondance sur le nom seul ne l’est pas.

Le même écran propose l’autre mode. Réinitialiser garde l’app et supprime tout ce qu’elle a stocké, sauf les reçus d’installation, car un pkgutil qui oublie un paquet encore installé casse son propre système de mise à jour. Les entrées du trousseau restent incluses volontairement : une app remise à neuf est déconnectée.

Rien n’est supprimé

Le rapport de suppression d’Unroot montrant le chemin daté du dossier de quarantaine dans la Corbeille et le manifeste que lit l’annulation
Un seul dossier daté dans la Corbeille, un manifeste à côté, et l’annulation toujours possible.

Les éléments supprimés vont dans un seul dossier daté de votre Corbeille - Unroot - Spectacle - 2026-08-21 11-01-33 - chacun dans son propre emplacement numéroté, si bien que com.vendor.app.plist venant de ~/Library/Preferences ne peut pas écraser en silence celui de /Library/Preferences.

Un dossier plutôt que quatre cents éléments en vrac, c’est en partie une question de lisibilité et en partie de capacité : la commande Remettre du Finder ne restaure que le premier élément d’un lot, et il n’existe aucune API publique pour restaurer par programme, donc une annulation bâtie dessus serait une promesse que le système ne peut pas tenir. À côté des fichiers se trouve unroot-manifest.json, une simple liste de la provenance de chaque élément. C’est ce que lit l’annulation, et il reste lisible même si Unroot a disparu.

Une partie d’une suppression est réellement définitive, et le panneau latéral la compte en rouge. Une entrée du trousseau n’est pas un fichier, elle ne peut donc pas être déplacée dans un dossier ; la supprimer déconnecte l’app et emporte toute licence qu’elle y avait stockée. La feuille de confirmation nomme chacune d’elles au lieu de les compter, car un nombre n’est pas un consentement.

Une annulation qui survit à un plantage

Le manifeste ne peut enregistrer que ce qui a réussi de façon constatée, il ne peut donc être écrit qu’après l’opération - et un plantage entre les deux laisserait des fichiers déplacés sans trace de leur provenance, soit exactement la promesse qu’il est censé tenir. Alors, avant que quoi que ce soit ne bouge, un journal de chaque entrée prévue est écrit dans le même dossier, et une opération terminée le supprime. Un journal sans manifeste est donc la signature d’une suppression interrompue, et le lancement suivant reconstruit le manifeste à partir de lui, en ne gardant que les entrées dont les fichiers sont effectivement dans leurs emplacements.

L’annulation est alors une relecture à l’envers. Si quelque chose occupe désormais le chemin d’origine - vous avez réinstallé l’app - la restauration est déviée vers un voisin numéroté au lieu de l’écraser, car une annulation ne doit jamais rien détruire pour réussir. Les tâches de lancement sont réamorcées plutôt que simplement remises en place, car remettre une plist en laissant le daemon arrêté restaurerait les fichiers sans restaurer discrètement le comportement. Les deux sens passent par une règle qui suppose que tout ce qui précède s’est trompé : /System, les dossiers du trousseau, iCloud Drive et vos dossiers Documents, Bureau, Téléchargements, Images, Films et Musique ne peuvent jamais être une destination, quelle que soit la correspondance.

La seule étape que l’annulation ne remet pas en place est la réinitialisation des autorisations, et l’app le dit sur la ligne plutôt que dans une note de bas de page : les autorisations de confidentialité sont réinitialisées, pas restaurées. Chaque app les redemande la prochaine fois qu’elle en a besoin.

Rien de tout cela n’expire. Chaque suppression qu’Unroot a jamais faite reste sur un seul écran avec l’espace qu’occupe son dossier, si bien qu’une suppression d’il y a deux mois s’annule exactement comme celle d’il y a deux minutes - et savoir si c’est encore possible se décide en regardant le disque, pas d’après un indicateur écrit à l’époque.

Tout garder, cela veut dire une Corbeille pleine de dossiers de quarantaine. La vider est la réponse normale ; sinon, Historique des suppressions supprime un dossier à la demande, ou tous avec Tout supprimer… après une confirmation qui en indique le nombre. C’est le seul endroit de l’app qui supprime quoi que ce soit, il est donc protégé : trois vérifications par dossier que le chemin est bien l’un des siens, et un nettoyage automatique qui reste désactivé tant que vous ne l’activez pas. Un dossier contenant des fichiers appartenant à root, comme un daemon de lancement supprimé, demande une fois votre mot de passe administrateur.

Les autorisations que personne ne peut effacer à la main

Avant de supprimer quoi que ce soit, Unroot lit la base de données des autorisations - en lecture seule, avec le même Accès complet au disque qu’il lui faut pour voir ~/Library - et montre ce que l’app détenait. Accessibilité, Accès complet au disque, Enregistrement de l’écran, Surveillance de l’entrée, Automatisation et une trentaine de types d’autorisation en tout sont décodés par leur nom. Presque rien d’autre ne vous montre cela, et c’est le meilleur argument qui soit pour expliquer pourquoi l’ordre d’une suppression compte.

La même liste fonctionne pour une app que vous gardez. Faites un clic droit dessus dans l’écran Apps et choisissez Autorisations… : une feuille montre ce à quoi elle a accès - caméra, micro, enregistrement de l’écran, Accès complet au disque et le reste - avec Retirer à côté de chacun. C’est tccutil pour un seul service, il n’y a donc rien à annuler ; l’app redemande simplement la prochaine fois qu’elle en a besoin. Une autorisation accordée à tous les utilisateurs demande votre mot de passe, et une autorisation enregistrée par chemin plutôt que par paquet ne peut être modifiée que dans Réglages Système, ce que la feuille indique.

Car l’ordre compte. La réinitialisation doit s’exécuter tant que le paquet est encore sur le disque, donc le paquet est déplacé en dernier, après l’arrêt des tâches de lancement et la suppression des entrées du trousseau. Le supprimer en premier est l’erreur irréversible, et c’est pourquoi tant d’apps désinstallées hantent encore Réglages Système.

Ensuite, le rapport relit la base de données au lieu de supposer que les outils ont fonctionné. macOS est connu pour refuser certaines réinitialisations de l’Accès complet au disque, il indique donc soit que les autorisations sont vérifiées comme effacées, soit nomme celle qui a survécu et vous dit de l’effacer à la main.

Les apps en cours d’exécution sont traitées avant tout. Chacune est priée de quitter, et si elle refuse, vous avez une décision à prendre plutôt qu’un arrêt forcé silencieux : la forcer à quitter, ou ignorer cette app et ne toucher à aucun de ses fichiers.

Les apps supprimées il y a des années, et ce qu’elles ont laissé tourner

Le balayage des restes d’Unroot listant des caches et journaux orphelins regroupés par identifiant de paquet, seules les lignes sûres étant cochées
Le balayage ne liste que des restes en forme d’identifiant, et ne coche que les caches et journaux que macOS reconstruit à la demande.

L’autre face d’une correspondance étroite, c’est que les restes d’apps déjà disparues n’ont nulle part où apparaître. Ils ont donc leur propre balayage, et il est volontairement prudent. Il ne liste que des éléments en forme d’identifiant - un nom d’au moins trois segments séparés par des points et sans espace - car un dossier nommé d’après une entreprise pourrait appartenir à n’importe quoi, et deviner, c’est ainsi qu’un désinstalleur supprime ce qu’il n’aurait pas dû.

Seuls les caches et les journaux arrivent cochés. Les données et réglages d’app non, et l’écran dit pourquoi : une partie de ce qui est listé est du cache écrit par un framework à l’intérieur d’une app que vous utilisez encore, ce qui est identique vu de l’extérieur. La liste est un point de départ, pas un verdict.

Un fichier restant est inerte. Un agent de lancement restant ne l’est pas, et c’est pourquoi une app supprimée il y a des années peut encore placer un élément en arrière-plan dans Réglages Système, que Réglages Système ne vous permet pas de supprimer. La même idée est donc appliquée à launchd : un écran liste tout ce qui démarre sans qu’on le demande - agents de lancement, daemons et les tâches de connexion que les apps enregistrent via SMAppService - et nomme le propriétaire de chacun. Il s’appelle Lancés à l’ouverture de session.

Seuls ceux dont le programme est manquant peuvent être sélectionnés en masse, et cette retenue est voulue. Une tâche comme com.docker.vmnetd partage un préfixe d’éditeur avec une app que vous avez encore ; la classer comme liée plutôt qu’orpheline sert précisément à garder un élément actif hors d’une liste intitulée « Suppression sûre ». Une tâche qui a encore un programme à exécuter n’est jamais orpheline, aussi abandonné que paraisse son nom.

Ce qu’une tâche active obtient à la place, c’est Désactiver. Cela arrête la tâche maintenant et l’empêche de démarrer après un redémarrage, rien n’est déplacé, et Activer la rétablit. Une tâche qu’une app a enregistrée depuis son propre paquet ne peut être basculée que dans Réglages Système, et la ligne y renvoie.

Ce qu’elle ne fait volontairement pas

Elle a besoin de l’Accès complet au disque, activé à la main, car macOS n’offre à une app aucun moyen de le demander ; sans lui, une analyse s’exécute quand même mais ne couvre que les emplacements hors de votre dossier personnel, et le dit au lieu de laisser une liste courte passer pour une liste propre. Supprimer quoi que ce soit hors de votre dossier personnel demande une fois votre mot de passe administrateur.

Certaines tâches, elle les refuse d’emblée - les logiciels d’Apple, elle-même, et les extensions système, qui ont une section intitulée « Unroot ne peut pas supprimer ceci » avec l’endroit exact où le faire vous-même.

Elle ne s’installe pas dans votre barre des menus, et par défaut rien ne guette le moment où vous glissez une app dans la Corbeille - Unroot analyse quand vous l’ouvrez et ne fait rien le reste du temps. Activez Repérer les apps glissées à la Corbeille dans Réglages -> Général et cela change : une app qui arrive dans la Corbeille déclenche une notification avec Nettoyer, et le nettoyage s’exécute tant que le paquet est encore là pour que tccutil le trouve. Pour être présente à ce moment-là, Unroot s’ouvre alors à la connexion et continue de tourner sans fenêtre. Elle a besoin de l’Accès complet au disque pour voir la Corbeille.

L’autre élément résident est une extension du Finder, et elle reste désactivée tant que vous ne l’activez pas dans Réglages Système -> Extensions -> Finder. Ensuite, un clic droit sur une app propose de la désinstaller. L’endroit où cela apparaît mérite d’être connu, car macOS n’est pas cohérent sur ce point : dans ~/Applications, c’est un élément de premier niveau qui nomme l’app, et partout ailleurs - /Applications compris, là où vivent la plupart des apps - il se trouve dans le sous-menu Services, sous le plus sobre « Uninstall with Unroot », non traduit. Il ne supprime rien par lui-même. Il transmet votre sélection à l’app, comme Désinstaller une app… dans la barre du haut, et le même écran de vérification s’ouvre.

Ce n’est pas non plus un nettoyeur de disque, même si elle montre ce que vous coûtent vos apps. L’écran Apps s’ouvre sur une carte de stockage - le poids de vos apps, réparti selon leur dernière ouverture - avec les filtres Inutilisées et Grosses à côté, et Installeurs liste les images disque et paquets laissés dans Téléchargements, en cochant ceux dont l’app est déjà installée. Elle ne va pas plus loin que les apps et leurs installateurs, et ne s’approche jamais du compte d’un autre utilisateur.

Et il n’existe pas de version Mac App Store, car lire ~/Library, réinitialiser les autorisations et déplacer des fichiers appartenant à root sont tous impossibles depuis un bac à sable.

Ce qu’elle coûte, et quoi regarder d’autre

Unroot nécessite macOS 14 ou ultérieur, fonctionne sur Apple Silicon et Intel, et occupe environ 10 Mo. C’est un achat unique de 13,99 $ avec un essai gratuit de 30 jours sans carte ni e-mail, et la licence est permanente. La fiche complète se trouve sur la page d’Unroot.

Si vous cherchez de l’espace disque au-delà des apps et de leurs installateurs, Sweep est la voisine - elle range le dossier Téléchargements selon des règles que vous écrivez et y trouve les doublons et les téléchargements bloqués, détaillé fonction par fonction dans trier automatiquement ses fichiers sur un Mac. Un panorama du reste se trouve dans les apps utilitaires pour Mac.