macOS 27 bloque l'accès aux données des autres applications : ce qui casse et comment y remédier

Depuis macOS Sonoma, lorsqu'une application tentait de lire les données privées d'une autre application, une invite s'affichait : « App » souhaite accéder aux données d'autres applications. Vous pouviez autoriser ou refuser, et quoi qu'il se passe, vous saviez pourquoi. macOS 27 Golden Gate supprime cette invite. L'accès est désormais refusé par défaut et sans demande. L'application qui voulait ces données obtient simplement un résultat vide ou une erreur « Operation not permitted ». Vous ne le découvrez que lorsqu'une fonctionnalité cesse de fonctionner silencieusement.

Trois changements liés dans la même version pointent dans la même direction : XProtect peut désormais bloquer l'accès aux données couramment volées par les logiciels malveillants, les applications ne peuvent plus lire directement la base de données de confidentialité, et launchd refuse de charger les fichiers de propriétés portant l'attribut de quarantaine. Ce guide explique chacun de ces points en s'appuyant sur le libellé des notes de version d'Apple, montre comment vérifier ce qui est concerné sur votre Mac, et explique comment accorder l'accès de manière délibérée quand vous en avez besoin — et quand vous ne devriez pas.

Points clés à retenir

• Plus d'invite. Dans macOS 27, l'accès aux conteneurs de données d'application et aux conteneurs de groupe d'applications d'un autre développeur est « refusé par défaut » et géré dans les réglages Confidentialité et sécurité. Les notes de version d'Apple classent ce changement sous System Integrity Protection.
• Les outils en ligne de commande posent problème. Apple recense un problème connu : un processus sans bundle ID ne peut pas se voir accorder l'accès aux données d'une application spécifique. La solution de contournement documentée consiste à utiliser Full Disk Access « pour la durée du besoin ».
• XProtect protège désormais les données « couramment ciblées ». Apple ne publie pas la liste, donc attendez-vous à ce que l'accès à certaines données d'application soit refusé, même pour un outil qui les lisait sans problème auparavant.
• Les applications ne peuvent plus lire directement la base de données de confidentialité TCC. Les scripts et outils qui inspectaient TCC.db pour rendre compte des autorisations doivent trouver une autre méthode.
• Les LaunchAgents en quarantaine cessent de se charger. Sur le Mac que nous avons vérifié, 9 des 20 agents présents dans ~/Library/LaunchAgents portaient l'attribut de quarantaine — tous étant des agents de mise à jour écrits par trois navigateurs tiers.

Ce qui a changé : d'une invite à un refus par défaut

Apple resserre cette zone étape par étape :

Version	Accès aux données d'une application d'un autre développeur
macOS 13 Ventura et versions antérieures	Largement ouvert à tout processus s'exécutant sous votre identité
macOS 14 Sonoma	Protégé ; l'utilisateur voit une invite lui demandant d'autoriser l'accès aux « données d'autres applications »
macOS 15 Sequoia	Protection étendue aux conteneurs de groupe d'applications
macOS 27 Golden Gate	Refusé par défaut sans invite ; géré dans les réglages Confidentialité et sécurité

Le libellé de macOS 27, tiré de la section System Integrity Protection des notes de version :

L'accès aux fichiers dans les conteneurs de données d'application et les conteneurs de groupe d'applications d'autres équipes de développement ne déclenche plus d'invite d'autorisation pour l'utilisateur ; ces accès sont refusés par défaut et peuvent être gérés par l'utilisateur dans les réglages Confidentialité et sécurité.

Deux mots de cette phrase déterminent si vous êtes concerné. Équipes de développement : la règle concerne les applications de développeurs différents. Une suite d'applications d'un même développeur peut toujours partager un conteneur de groupe, car elles sont signées par la même équipe. Conteneurs : la règle couvre les dossiers de données en bac à sable que les applications conservent dans votre dossier Library. Elle ne couvre pas votre dossier Documents, votre Bureau ni les fichiers que vous enregistrez vous-même — ceux-ci relèvent de leurs propres autorisations Fichiers et dossiers, qui n'ont pas changé de cette manière.

Ce qui compte comme « données d'une autre application »

Les applications en bac à sable conservent leurs fichiers privés à deux endroits dans votre dossier de départ :

• ~/Library/Containers/ — un dossier par application en bac à sable, nommé d'après son bundle ID, avec les données réelles de l'application sous Data/
• ~/Library/Group Containers/ — des dossiers partagés entre plusieurs applications d'un même développeur, nommés soit group.…, soit précédés de l'identifiant d'équipe du développeur

Lister les noms de dossiers est sans risque et donne une idée de l'ampleur. Sur le Mac que nous avons utilisé, toujours sous Tahoe 26.5.2 :

ls ~/Library/Containers | wc -l                    # 956
ls ~/Library/Group\ Containers | wc -l             # 187
ls ~/Library/Group\ Containers | grep -vc '^group\.'   # 70 named with a team ID

Cela représente 956 conteneurs d'application et 187 conteneurs de groupe, chacun désormais interdit par défaut à toute application d'un développeur différent. Dans la plupart des cas, c'est très bien : une application bien élevée n'a aucune raison de lire la base de données d'une autre. Le problème vient des outils qui la lisent légitimement pour vous.

À quoi ressemble une panne

L'échec ne s'accompagne d'aucune boîte de dialogue ; il se manifeste donc sous forme de symptôme. Les plus courants :

Symptôme	Cause probable
ls: … : Operation not permitted dans Terminal sur un chemin sous ~/Library/Containers/…/Data ou ~/Library/Group Containers/	L'application responsable du shell (Terminal, iTerm, votre IDE) n'a pas accès aux données de cette application
Un outil de sauvegarde, de synchronisation ou d'exportation ignore les données d'une application ou signale « permission denied »	L'outil n'est pas autorisé à lire ce conteneur
Un outil d'importation ne trouve rien à importer depuis une autre application	Refus silencieux ; l'outil d'importation voit un dossier vide ou absent
Un lanceur, un gestionnaire de presse-papiers ou un outil d'automatisation perd une fonctionnalité qui lisait les données d'une autre application	Même refus, se traduisant par des résultats manquants
Un script exécuté par cron ou launchd échoue sur un chemin qu'il lisait hier	Processus en ligne de commande sans bundle ID — voir le problème connu ci-dessous

« Operation not permitted » (EPERM) est l'erreur standard que vous obtenez lorsque les contrôles de confidentialité de macOS bloquent un accès à un fichier. Cela ne signifie pas que le fichier est manquant, et sudo n'y changera rien — la protection de la confidentialité s'applique aussi à root.

Accorder l'accès correctement

Apple place ce réglage dans Réglages Système → Confidentialité et sécurité, et le problème connu ci-dessous concerne spécifiquement le panneau Fichiers et dossiers. C'est là que l'accès aux données d'une autre application est désormais accordé application par application, au lieu de passer par une invite ponctuelle.

Pour les applications classiques

1. Ouvrez Réglages Système → Confidentialité et sécurité → Fichiers et dossiers.
2. Trouvez l'application qui a besoin de cet accès et développez-la.
3. Autorisez les données spécifiques dont elle a besoin, plutôt qu'un accès plus large.

La disposition exacte de ce panneau sous macOS 27 peut différer de celle de Tahoe. Les notes d'Apple décrivent où l'accès est géré, pas un cheminement clic par clic. Le principe reste le même dans tous les cas : accordez l'accès le plus restreint possible pour que la fonctionnalité marche.

Si la documentation d'une application vous indique plutôt d'accorder Full Disk Access, cela fonctionne aussi — Full Disk Access couvre les conteneurs de données d'application. Mais il couvre également tout le reste de votre dossier de départ, y compris les données de Mail, Messages et Safari ; réservez-le donc aux outils dont le travail consiste entièrement à lire votre disque : logiciels de sauvegarde, analyseurs de disque, etc.

Pour les scripts, tâches cron et outils en ligne de commande

C'est ici qu'Apple recense un problème connu :

Dans le panneau Fichiers et dossiers, un processus sans bundle ID ne peut pas se voir accorder l'accès à des conteneurs de données d'application ou des conteneurs de groupe d'applications spécifiques appartenant à d'autres équipes de développement.

Solution de contournement : évaluez si cet accès est réellement nécessaire. Si c'est le cas, accordez Full Disk Access au processus pour la durée du besoin.

Un « processus sans bundle ID » est n'importe quel exécutable ordinaire : un interpréteur Python, un script shell exécuté par launchd, un binaire installé par Homebrew, un démon lancé par cron. Ce qui compte, c'est la façon dont il est lancé :

• Exécuté depuis Terminal, les décisions de confidentialité sont attribuées à Terminal (ou iTerm, ou votre IDE), qui, lui, possède un bundle ID. Accorder l'accès à cette application couvre généralement les commandes que vous y exécutez.
• Exécuté par launchd ou cron, il n'y a aucune application à laquelle l'attribuer. C'est le processus lui-même qui a besoin de l'autorisation, et selon le problème connu, cela signifie Full Disk Access pour le binaire.

Pour ajouter un binaire en ligne de commande à Full Disk Access, cliquez sur + dans la liste Full Disk Access, appuyez sur ⌘⇧G, collez le chemin (par exemple /opt/homebrew/bin/python3 ou /usr/sbin/cron), puis ajoutez-le. La formule d'Apple — « pour la durée du besoin » — mérite d'être prise au pied de la lettre. Accordez l'accès pour la tâche, puis retirez-le. Un interpréteur disposant de Full Disk Access donne cet accès à chaque script qu'il exécute.

La couche XProtect

Une deuxième note dans la même section ajoute une couche de protection qui ne dépend pas de qui fait la demande :

XProtect peut désormais restreindre l'accès aux données d'application couramment ciblées par des logiciels malveillants. L'accès aux fichiers créés par les applications d'autres équipes de développement peut être refusé par défaut, mais peut être géré par l'utilisateur dans les réglages Confidentialité et sécurité.

Apple ne précise pas quelles données comptent comme « couramment ciblées ». Ce que recherchent les infostealers sur Mac est bien documenté par les chercheurs en sécurité : les profils de navigateur contenant des mots de passe et cookies enregistrés, les données de portefeuille de cryptomonnaies, et les fichiers de session des applications de messagerie. Il est raisonnable de supposer — mais cela reste une supposition — que la liste d'XProtect recoupe largement ces éléments.

L'effet pratique pour vous : un outil qui lit légitimement, par exemple, les données de session ou de profil d'une autre application peut se voir refuser l'accès sous macOS 27, même après avoir accordé ce qui ressemble à la bonne autorisation. Si cela se produit, commencez par vérifier Confidentialité et sécurité à la recherche d'une entrée en attente. S'il n'y en a pas, il vaut la peine de demander au développeur de l'outil s'il a testé sous macOS 27 — la correction devra peut-être venir de son côté.

Les applications ne peuvent plus lire la base de données de confidentialité

La base de données TCC (Transparency, Consent and Control) enregistre les applications que vous avez autorisées à utiliser la caméra, le microphone, l'enregistrement d'écran, les fichiers, etc. La copie par utilisateur se trouve dans ~/Library/Application Support/com.apple.TCC/TCC.db. Pendant des années, les outils disposant de Full Disk Access pouvaient la lire directement pour rendre compte des autorisations.

Les notes de version de macOS 27, dans la section des dépréciations TCC :

Les applications ne peuvent plus accéder directement à la base de données TCC locale.

Même sous Tahoe, Full Disk Access est nécessaire pour la lire. Depuis un shell qui ne l'a pas, sur notre Mac de test :

sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "select service from access limit 1"
# Error: unable to open database ".../com.apple.TCC/TCC.db": authorization denied

Sous macOS 27, cette voie directe est fermée pour les applications en général. Qui le remarque :

• Les administrateurs Mac dont les scripts de conformité ou les extensions d'inventaire interrogeaient TCC.db pour rendre compte des autorisations. La voie prise en charge est le reporting PPPC (privacy preferences policy control) de votre outil de gestion des appareils, pas la base de données.
• Les utilitaires qui affichaient « quelle application a quelle autorisation » en lisant le fichier.
• Les logiciels malveillants, qui lisaient la base de données pour savoir à quoi ils avaient déjà accès. C'est la raison de ce changement.

Sur votre propre Mac, Réglages Système → Confidentialité et sécurité reste l'endroit où consulter et révoquer les autorisations. Chaque catégorie liste les applications qui la détiennent.

L'autre changement silencieux : les LaunchAgents en quarantaine

Ce changement ne concerne pas les données d'application, mais il échoue de la même manière — silencieusement — et il s'est avéré affecter notre Mac de test plus que tout autre point de cet article. Les notes de version, dans la section Launch Daemons and Agents :

launchd ne prend plus en charge le chargement des fichiers de propriétés launchd portant l'attribut étendu de quarantaine.

Un LaunchAgent est un petit fichier .plist dans ~/Library/LaunchAgents qui indique à launchd de démarrer un programme à la connexion ou selon un calendrier : outils de mise à jour, assistants de synchronisation, utilitaires de barre de menus. L'attribut de quarantaine (com.apple.quarantine) est le marqueur que macOS appose aux fichiers arrivant d'Internet — et aux fichiers créés par des applications elles-mêmes soumises aux règles de quarantaine.

Une seule boucle suffit pour vérifier :

for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

Sur notre Mac de test :

Dossier	Fichiers de propriétés	En quarantaine
~/Library/LaunchAgents	20	9
/Library/LaunchAgents	8	0
/Library/LaunchDaemons	27	0

Les neuf fichiers en quarantaine étaient tous des agents de mise à jour — trois chacun — créés par trois navigateurs tiers basés sur Chromium. Le troisième champ de la valeur de quarantaine nomme l'application qui a créé le fichier :

xattr -p com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
# 0081;<timestamp>;<name of the app that wrote it>;<id>

Au moins l'un d'entre eux est chargé et fonctionne actuellement sous Tahoe. À en croire la note d'Apple, sous macOS 27 ces agents ne se chargeront plus, de sorte que les outils de mise à jour en arrière-plan de ces navigateurs s'arrêteraient silencieusement. Nous ne l'avons pas confirmé sur Golden Gate lui-même, et les éditeurs ont peut-être déjà modifié la façon dont leurs agents sont écrits. Mais c'est exactement le genre de panne qui passe inaperçue pendant des mois : rien n'échoue de façon visible, et le navigateur cesse simplement de se mettre à jour.

Corriger un agent en quarantaine

1. Mettez d'abord l'application à jour. Si l'éditeur a corrigé le problème, la nouvelle version réécrira l'agent sans l'attribut.
2. Si vous devez le corriger manuellement, inspectez avant de faire confiance. Vérifiez ce qu'il exécute :

plutil -p ~/Library/LaunchAgents/some.agent.plist          # look at Program / ProgramArguments
codesign -dv --verbose=2 "/path/to/the/program" 2>&1 | grep -E "Authority|TeamIdentifier"

3. Seulement si le programme correspond à ce que vous attendez, retirez l'attribut et rechargez l'agent :

xattr -d com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist 2>/dev/null
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist

Ne retirez pas la quarantaine d'agents que vous ne reconnaissez pas. La persistance via les LaunchAgents est une technique classique des logiciels malveillants, et ce changement vise justement à empêcher qu'un .plist téléchargé s'installe silencieusement. Un agent en quarantaine non reconnu est une raison d'enquêter, pas de le recharger. Notre guide des éléments de connexion et applications en arrière-plan explique comment remonter d'un agent à l'application qui l'a installé.

Un audit de cinq minutes, avant ou après la mise à niveau

Exécutez ces commandes sous Tahoe pour voir ce qui risque de changer, ou sous macOS 27 pour confirmer ce qui a déjà changé :

# 1. How much app data is now guarded by default
ls ~/Library/Containers | wc -l
ls ~/Library/Group\ Containers | wc -l

# 2. Scheduled jobs that may read other apps' data
crontab -l 2>/dev/null
ls ~/Library/LaunchAgents

# 3. Quarantined launch items that will stop loading
for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

# 4. Scripts that read the privacy database directly
grep -rl "TCC.db" ~/bin ~/scripts ~/.local/bin 2>/dev/null

Adaptez les dossiers de l'étape 4 à l'endroit où vous conservez vos scripts. Pour chaque résultat, posez-vous la même question que la solution de contournement d'Apple : cet accès est-il réellement nécessaire ?

Quand ne pas accorder l'accès

Ce changement existe parce que « tout processus s'exécutant sous votre identité peut lire les données de n'importe quelle application » était le principal levier exploité par les infostealers sur Mac. Avant d'accorder l'accès pour retrouver une fonctionnalité, quelques règles aident :

• Privilégiez l'octroi restreint. L'accès par application dans Fichiers et dossiers plutôt que Full Disk Access ; Full Disk Access pour un seul binaire plutôt que pour toute une application de terminal.
• Rendez les octrois en ligne de commande temporaires. La formule même d'Apple est « pour la durée du besoin ». Mettez un rappel sur votre calendrier pour le retirer.
• Méfiez-vous des nouvelles demandes. Une application qui n'avait aucune raison de lire les données d'une autre application le mois dernier et qui demande Full Disk Access ce mois-ci mérite un second regard.
• Ne collez jamais de commandes d'octroi d'autorisation provenant d'une page web à laquelle vous ne faites pas confiance. Les campagnes d'ingénierie sociale qui incitent les utilisateurs à exécuter des commandes Terminal sont exactement la façon dont ces protections sont contournées, comme l'explique notre article sur les avertissements de logiciels malveillants via le collage dans Terminal.

Résolution des problèmes courants

« Operation not permitted » même avec sudo

Problème : sudo ls ~/Library/Containers/…/Data échoue toujours.

Solution : la protection de la confidentialité n'est pas un problème d'autorisations Unix, et root y est également soumis. Accordez l'accès à l'application responsable — Terminal, ou l'application qui a lancé la commande — dans Confidentialité et sécurité.

Une tâche launchd échoue mais la même commande fonctionne dans Terminal

Problème : un script planifié lit correctement les données d'une autre application quand vous l'exécutez à la main, mais échoue à l'heure prévue.

Solution : dans Terminal, l'accès est attribué à Terminal. Sous launchd, il n'y a aucune application à laquelle l'attribuer, et d'après le problème connu d'Apple, un processus sans bundle ID ne peut pas obtenir un accès par application. Accordez Full Disk Access exactement au binaire que la tâche exécute, et retirez-le lorsque la tâche n'en a plus besoin.

Un outil de sauvegarde a ignoré silencieusement certaines données d'application

Problème : la sauvegarde s'est terminée, mais le conteneur d'une application est manquant ou vide dans la sauvegarde.

Solution : accordez à l'application de sauvegarde Full Disk Access — c'est l'un des cas d'usage légitimes — puis relancez-la. Consultez le journal de l'outil à la recherche d'erreurs d'autorisation ; la plupart les signalent même quand la sauvegarde « réussit ».

Une application a perdu une fonctionnalité après la mise à niveau, sans erreur

Problème : une fonctionnalité d'importation, de synchronisation ou de recherche ne renvoie rien.

Solution : cherchez dans Confidentialité et sécurité une entrée que vous pouvez autoriser, et consultez les notes de version de l'éditeur pour la compatibilité avec macOS 27. Si les données recherchées sont du type que protège XProtect, la correction devra peut-être venir du développeur.

Un outil de mise à jour en arrière-plan a cessé de se mettre à jour

Problème : la mise à jour automatique d'une application s'est arrêtée silencieusement depuis la mise à niveau.

Solution : vérifiez si son LaunchAgent porte l'attribut de quarantaine à l'aide de la boucle ci-dessus. Mettez d'abord l'application à jour manuellement ; c'est la correction qui a le plus de chances de tenir.

FAQ

macOS 27 a-t-il supprimé l'invite « accéder aux données d'autres applications » ?

Oui. Les notes de version d'Apple indiquent que cet accès « ne déclenche plus d'invite d'autorisation pour l'utilisateur » et est « refusé par défaut ». Vous le gérez dans les réglages Confidentialité et sécurité au lieu de répondre à une invite au moment où cela se produit.

Cela affecte-t-il les applications d'un même développeur ?

Non. La règle s'applique aux « autres équipes de développement ». Les applications signées par la même équipe de développement peuvent toujours partager des données via leurs conteneurs de groupe, ce qui permet aux suites d'applications apparentées de continuer à fonctionner.

Full Disk Access suffit-il toujours ?

D'après la solution de contournement d'Apple pour le problème connu en ligne de commande, oui — Full Disk Access donne accès aux conteneurs de données d'application. Les nouvelles restrictions d'XProtect sur les données couramment ciblées constituent la partie qu'Apple décrit comme distincte, et celles-ci peuvent tout de même s'appliquer à certaines données.

Pourquoi mon script ne peut-il plus lire TCC.db ?

Les notes de macOS 27 d'Apple indiquent que les applications ne peuvent plus accéder directement à la base de données TCC locale. Utilisez Réglages Système pour consulter les autorisations, et le reporting de votre outil de gestion des appareils si vous êtes administrateur.

Est-il sûr de retirer l'attribut de quarantaine d'un LaunchAgent ?

Seulement lorsque vous avez confirmé ce qu'il exécute, et que le programme est bien signé par le développeur attendu. Retirer la quarantaine est exactement ce que les logiciels malveillants espèrent que vous fassiez, et c'est précisément pour cette raison que macOS 27 a cessé de charger les agents en quarantaine.

Conclusion

Le fil conducteur de ces changements de macOS 27 est cohérent : les données appartenant à une application ne sont plus disponibles pour une autre simplement parce que les deux s'exécutent sous votre compte, et un fichier téléchargé depuis Internet ne se transforme plus en processus en arrière-plan simplement parce qu'il a atterri dans le bon dossier. Pour la plupart des gens, c'est un gain net, puisqu'il s'agit précisément de l'accès dont dépendaient les infostealers sur Mac.

Le coût, ce sont des pannes qui ne seront jamais annoncées. Les scripts, outils de sauvegarde, outils d'importation et même les outils de mise à jour des navigateurs peuvent cesser de fonctionner silencieusement. Effectuez l'audit de cinq minutes, accordez l'accès de façon restreinte et temporaire là où un outil en a vraiment besoin, et lorsque quelque chose devient silencieux après la mise à niveau, vérifiez d'abord Confidentialité et sécurité.

Lectures connexes : macOS 27 ignore « Ouvrir avec Rosetta » : corriger les plug-ins Intel manquants · L'enregistrement d'écran et Full Disk Access redemandent sans cesse · « App is damaged » et l'attribut de quarantaine · Guide de mise à jour du jour de lancement de macOS 27 Golden Gate