Votre Mac redemande sans cesse l'autorisation Screen Recording : les vraies solutions

Vous ouvrez Zoom, vous cliquez sur Share Screen, et macOS affiche exactement la même boîte de dialogue que le mois dernier pour vous demander si Zoom a le droit d'enregistrer votre écran. Vous aviez déjà dit oui. Vous ouvrez System Settings, et l'application est bien là : Zoom, dans la liste Screen & System Audio Recording, avec l'interrupteur activé. Rien n'est cassé. Et pourtant on vous a redemandé.

Une semaine plus tard, il se passe autre chose. Votre outil de sauvegarde n'arrive plus à lire votre dossier Mail. Vous vérifiez Full Disk Access et l'application y figure, activée, exactement comme elle le devrait. Mais elle se comporte comme si elle n'avait aucune autorisation. Ce n'est pas le même problème, même si la sensation est identique.

Ces deux situations sont traitées comme une seule et même chose dans la plupart des conseils que vous trouverez, et c'est précisément pour cela qu'une grande partie de ces conseils échoue. Le premier cas est délibéré. Apple a intégré une reconfirmation périodique à l'autorisation de capture d'écran, et aucun réglage ne permet de la désactiver. Le second est un vrai dysfonctionnement, avec une cause précise et identifiable, et cette cause se ramène presque toujours à une seule chose : macOS ne considère plus que l'application présente sur le disque est celle à laquelle vous avez accordé l'autorisation.

Cet article sépare les deux cas, explique le sous-système qui se trouve derrière chacun d'eux et vous donne la bonne solution pour chacun. Il explique aussi pourquoi le conseil le plus répandu sur ce sujet, à savoir modifier les permissions de fichiers avec chmod ou lancer une forme de réparation des permissions, n'a strictement rien à voir avec le système concerné. Tout ce qui est démontré ci-dessous a été testé sur un Mac fonctionnant sous macOS 26.5.2, build 25F84, avec System Integrity Protection activé.

Points clés

• Deux problèmes différents portent le même visage — une redemande programmée pour la capture d'écran est prévue par conception et ne peut pas être désactivée, tandis qu'une autorisation accordée mais non fonctionnelle est un véritable défaut avec une cause réelle.
• TCC lie l'autorisation à l'identité de signature de code d'une application, pas à son chemin — c'est pour cela qu'une autorisation cesse silencieusement de fonctionner après une mise à jour, un déplacement, ou lorsque deux copies de la même application coexistent sur le disque.
• tccutil reset est la seule commande fournie par Apple — il n'existe aucun moyen d'accorder une autorisation depuis le Terminal, et exécuter reset sans identifiant de bundle efface cette autorisation pour toutes les applications du Mac.
• Les bases de données de confidentialité sont illisibles, même pour ls — sur un Mac de test avec SIP activé, lister l'un ou l'autre des répertoires TCC renvoie Operation not permitted, ce qui constitue la preuve la plus claire possible qu'il ne s'agit pas de permissions de fichiers ordinaires.
• Apple ne publie pas la liste des noms de services — des noms comme ScreenCapture et SystemPolicyAllFiles relèvent du savoir communautaire, et tout guide qui les présente comme de la documentation officielle est en train de deviner.

Ce qu'est TCC et ce qu'il n'est pas

Le sous-système qui décide si une application peut enregistrer votre écran, lire votre dossier Mail, utiliser le microphone ou piloter d'autres applications s'appelle TCC. Les initiales signifient Transparency, Consent and Control (transparence, consentement et contrôle). C'est lui qui produit chacune des boîtes de dialogue « L'application souhaite accéder à… » sur lesquelles vous avez cliqué, et c'est lui qui remplit chaque liste de System Settings sous Privacy & Security.

La page man d'Apple pour le seul outil en ligne de commande de ce domaine le décrit en une phrase. Sous NAME, on lit « tccutil – gérer la base de données de confidentialité », et la section DESCRIPTION développe ainsi : « La commande tccutil gère la base de données de confidentialité, qui stocke les décisions prises par l'utilisateur quant à l'accès des applications aux données personnelles. »

Lisez cela attentivement, car la formulation est précise et elle vous donne la forme de tout le système. TCC stocke des décisions. C'est un registre de consentement. Ce n'est pas la description d'un fichier, c'est la description d'une relation entre une application et une catégorie de données protégées.

La base de données de confidentialité n'est pas le système de fichiers

C'est l'idée fausse qui fait perdre le plus de temps, il vaut donc mieux l'évacuer immédiatement.

Les permissions de fichiers Unix traditionnelles sont des attributs stockés sur le fichier lui-même : un propriétaire, un groupe, et des bits de lecture/écriture/exécution, modifiés avec chmod et chown. Elles répondent à la question « quels comptes utilisateurs peuvent toucher à ce fichier ? »

TCC répond à une question complètement différente : « à quelle application l'utilisateur a-t-il consenti à laisser lire cette catégorie de données ? » Le sujet n'est pas le compte utilisateur. C'est l'application. Howard Oakley, de The Eclectic Light Company, a bien formulé la distinction dans son article explicatif de novembre 2025 sur les permissions et la confidentialité, en écrivant que « la protection de la vie privée opère en dehors des attributs de fichiers, au moyen d'un système de règles appliqué à chaque application ».

La conséquence pratique est sans appel. Votre compte utilisateur possède déjà ~/Library/Mail, et les bits POSIX indiquent déjà que vous pouvez le lire. C'est précisément pour cela qu'une commande de terminal exécutée sous votre identité peut le lire alors qu'une application graphique lancée par vous ne le peut pas : les permissions de fichiers n'ont jamais été l'obstacle. TCC l'était.

Aucune quantité de chmod ne corrigera donc un problème TCC. Aucune routine de « réparation des permissions » non plus, un concept qui remonte à l'ère pré-APFS, s'appliquait à la base de données des reçus d'installation, et qu'Apple a retiré de Disk Utility il y a des années. Lancer sudo chmod -R 755 sur tout votre dossier personnel pour faire taire une demande d'enregistrement d'écran ne servira à rien, et peut endommager votre dossier Library. Ne le faites pas.

Les bases de données que vous ne pouvez pas lire, ni même lister

Il existe deux bases de données TCC. Celle propre à l'utilisateur se trouve dans ~/Library/Application Support/com.apple.TCC/ et contient les décisions qui s'appliquent à votre compte. Celle du système se trouve dans /Library/Application Support/com.apple.TCC/ et contient les décisions qui s'appliquent à toute la machine, y compris celles qu'un administrateur ou un profil MDM peut définir.

Voici la démonstration qui tranche le débat. Sur le Mac de test, avec SIP activé, les deux commandes suivantes ont été tentées :

ls ~/Library/Application\ Support/com.apple.TCC/
ls /Library/Application\ Support/com.apple.TCC/

Les deux ont renvoyé Operation not permitted. Pas « permission denied », qui est la forme que prend un échec POSIX, mais la réponse que donne le noyau lorsque System Integrity Protection bloque purement et simplement l'accès. SIP était bien actif : csrutil status a renvoyé System Integrity Protection status: enabled.

Vous ne pouvez pas lister ces répertoires, lire les bases de données qu'ils contiennent, ni les modifier. Si un guide vous dit d'ouvrir TCC.db dans un navigateur SQLite et d'y insérer une ligne, il décrit une machine dont SIP est désactivé, et désactiver SIP pour contourner une demande d'autorisation revient à sacrifier une grande partie de l'architecture défensive de votre Mac pour régler une boîte de dialogue. Cet article ne vous expliquera pas comment faire cela.

Ce que vous pouvez faire, c'est accorder une autorisation via l'interface de System Settings, réinitialiser une décision avec tccutil, ou laisser un profil MDM écrire une décision à votre place. Ce sont les trois portes. Il n'y en a pas de quatrième.

Pourquoi cette conception existe

Si les décisions TCC vivaient dans un fichier ordinaire modifiable, n'importe quelle application ayant un accès en écriture à votre dossier personnel pourrait s'accorder silencieusement l'enregistrement d'écran, l'accès à la caméra et le libre parcours de votre dossier Mail. La protection ne vaudrait rien. Apple a donc placé les décisions derrière SIP, fait de l'interaction utilisateur avec une boîte de dialogue dessinée par le système l'unique voie d'écriture prise en charge, et doté l'outil en ligne de commande d'un seul verbe : reset.

C'est une conception cohérente et, du point de vue de quelqu'un qui tente de réparer une autorisation cassée à 23 h, une boîte à outils très réduite. La majeure partie de cet article porte sur la manière de bien s'en servir. Pour le contexte plus large sur la façon dont macOS superpose Gatekeeper, la notarisation, SIP et TCC, notre guide complet de la sécurité et de la confidentialité sur macOS Tahoe couvre l'architecture environnante.

Les deux problèmes distincts

Passons maintenant à la séparation dont dépend tout le reste de cet article.

Problème un : la redemande délibérée

Pendant le cycle bêta de macOS 15 Sequoia en 2024, Apple a introduit une reconfirmation périodique pour la capture d'écran et d'audio. Toute application qui capture votre écran se voit demander une reconfirmation selon un calendrier, sans possibilité de refus.

Le comportement initial en bêta était hebdomadaire, et une redemande survenait également après chaque redémarrage. Cela a suscité de vives critiques publiques. MacRumors rapportait en août 2024 que « les fenêtres surgissantes relatives aux autorisations d'enregistrement d'écran apparaissaient chaque semaine tout au long du processus de test bêta, mais Apple a ajusté la fréquence en réponse aux retours des utilisateurs », et que la bêta était passée à une réautorisation mensuelle. 9to5Mac et iDownloadBlog ont rapporté le même changement à partir de la même bêta. La demande à chaque redémarrage a été supprimée en même temps. La boîte de dialogue propose un bouton « Allow For One Month » et une option pour ouvrir System Settings, et MacRumors notait alors qu'« il ne semble pas exister de moyen pour les utilisateurs d'accorder de façon permanente l'accès à l'enregistrement d'écran, mais une fenêtre mensuelle est au moins plus pratique qu'une fenêtre hebdomadaire ».

Passons maintenant à la partie honnête. Je n'ai pas pu vérifier la cadence actuelle dans la génération macOS 26 auprès d'une source faisant autorité. La page d'assistance d'Apple consacrée à ce volet, « Autoriser des apps à utiliser l'enregistrement de l'écran et de l'audio » dans le guide d'utilisation du Mac pour macOS Tahoe 26, décrit comment ouvrir le volet et comment répondre à la boîte de dialogue, et ne dit absolument rien d'une réapprobation périodique. Les sources secondaires qui traitent de macOS 26 se contredisent, certaines décrivant une redemande hebdomadaire et d'autres mensuelle, et aucune ne cite quoi que ce soit.

Voici donc ce que l'on peut affirmer avec certitude et ce que l'on ne peut pas. Confirmé : la redemande périodique a été introduite pendant le cycle Sequoia, s'applique à la capture de l'écran et de l'audio système, propose une autorisation d'un mois et n'offre aucun interrupteur d'arrêt côté utilisateur. Confirmé : la documentation d'assistance actuelle d'Apple pour ce volet n'en fait aucune mention. Non confirmé : l'intervalle exact dans la génération macOS 26. Si votre Mac redemande à peu près une fois par mois, cela correspond à ce qu'Apple a livré dans Sequoia. S'il demande bien plus souvent, lisez le diagnostic de panne ci-dessous, car une redemande fréquente est un problème différent.

Ce qu'il est le plus utile de savoir sur le problème un, c'est qu'il ne s'agit pas d'un défaut et qu'il n'y a rien à réparer. Cliquer sur Allow prend une seconde, et la boîte de dialogue est la reconfirmation : vous n'avez donc rien à réactiver dans System Settings. Tout guide qui vous dit de réinitialiser, réinstaller ou modifier quelque chose en réponse à une demande mensuelle vend un remède à un patient en bonne santé.

Il existe une exception côté développeur. Apple dispose d'un droit d'accès nommé com.apple.developer.persistent-content-capture qui supprime la demande récurrente, et le blog de Michael Tsai a compilé la discussion des développeurs à ce sujet en août 2024. C'est une capacité gérée, destinée aux applications de contrôle à distance et de type VNC : les développeurs doivent en faire la demande auprès d'Apple et se la voir accorder. Vous ne pouvez pas l'activer en tant qu'utilisateur. Elle explique seulement pourquoi un petit nombre d'applications d'accès distant ne vous importunent jamais.

Problème deux : l'autorisation qui ne tient pas

Celui-ci est un véritable défaut. Il se présente comme une application listée dans le volet, activée, qui se comporte comme si elle n'avait aucune autorisation ; une application qui disparaît du volet après une mise à jour ; une autorisation qui fonctionne jusqu'à ce que vous quittiez et relanciez l'application ; deux entrées portant le même nom d'application ; un outil qui n'apparaît jamais dans le volet, même après l'avoir ajouté avec + ; ou une demande à chaque lancement plutôt qu'une fois par mois.

Tout cela a des causes, et la plupart de ces cas partagent une cause unique. C'est l'objet de la prochaine grande section.

Une chose qui n'est pas dans cette liste, bien qu'elle semble y avoir sa place : un Mac qui vous redemande sans cesse le mot de passe de votre trousseau de session. Cela relève du sous-système du trousseau, pas de TCC, et rien dans cet article ne le corrigera. Si c'est votre symptôme, l'article sur la correction de la demande de mot de passe du trousseau de session traite du bon terrain.

Quel problème avez-vous

Symptôme	Quel problème	Que faire
Demande de capture d'écran environ une fois par mois, l'application fonctionne après avoir cliqué sur Allow	Prévu par conception	Cliquez sur Allow. Rien ne va mal.
Demande à chaque lancement	Défaut	Problème d'identité de signature ou de copie en double. Voir ci-dessous.
Activée dans le volet, l'application n'y arrive toujours pas	Défaut	Entrée obsolète liée à une ancienne identité. Réattribution propre.
L'application a disparu du volet après une mise à jour	Défaut	La signature a changé. Réaccordez.
Deux entrées portant le même nom dans le volet	Défaut	Deux copies sur le disque. Trouvez-en une et supprimez-la.
L'outil en ligne de commande fonctionne mais n'apparaît jamais dans le volet	Bug connu de macOS 26.1	Voir la section sur la ligne de commande.
La demande apparaît, vous cliquez sur Allow, rien ne se passe	Défaut	Souvent l'application n'a jamais été entièrement quittée. Réattribution propre.
L'interrupteur est grisé avec une mention de profil	Mac géré	Contactez la personne qui administre l'appareil.
Une autorisation hors capture redemande chaque mois	Défaut	Seule la capture d'écran fait l'objet d'une redemande programmée.

Où se trouve chaque autorisation dans la génération macOS 26

Tous ces volets se trouvent sous la même racine. Ouvrez System Settings, cliquez sur Privacy & Security dans la barre latérale, puis choisissez la catégorie. Les catégories pertinentes pour cet article :

• Screen & System Audio Recording. Renommé dans la génération macOS 26 ; il s'appelait Screen Recording auparavant. La description d'Apple tient en une ligne : « Autorisez des apps à enregistrer votre écran et votre audio, ou seulement votre audio. Les apps listées y ont accès. »
• Full Disk Access. Les données utilisateur protégées à l'échelle du système : Mail, Messages, les données de Safari, les sauvegardes Time Machine et les dossiers de conteneur des autres applications.
• Accessibility. La capacité de contrôler votre Mac : déplacer le pointeur, cliquer, lire le contenu des fenêtres, piloter les interfaces d'autres applications.
• Automation. Le droit, pour une application donnée, d'envoyer des Apple events à une autre application donnée. C'est le seul volet organisé par paires plutôt qu'en liste plate.
• Files and Folders. Accès fin aux dossiers : Desktop, Documents, Downloads, volumes amovibles et réseau. Une application disposant de Full Disk Access n'a besoin d'aucune entrée ici.
• Input Monitoring. Permet à une application de voir les frappes clavier même lorsqu'elle n'est pas au premier plan.
• Camera et Microphone. Exactement ce que leur nom indique. Si c'est précisément votre microphone qui se comporte mal, la chaîne d'autorisations d'entrée a ses propres particularités, traitées dans le guide sur la réparation d'un microphone de Mac qui ne fonctionne plus sous macOS Tahoe 26.5.
• Local Network. Plus récent, et source fréquente de confusion, car une autorisation de réseau local bloquée produit des symptômes qui ne ressemblent en rien à un problème de confidentialité. Une imprimante qui a cessé de répondre en est l'exemple classique, détaillé pas à pas dans la correction AirPrint et confidentialité du réseau local.

Deux faits structurels qui comptent pour la suite. La liste que vous voyez est un rendu de la base de données, et le bug de macOS 26.1 décrit plus bas a prouvé que le rendu peut être faux alors que la base est juste. Et supprimer une entrée avec le bouton - efface la décision plutôt que de refuser l'application : la prochaine fois que l'application demande, vous obtenez donc une nouvelle invite. Cette distinction est le fondement de la séquence de réattribution propre.

Pourquoi une autorisation accordée cesse de fonctionner

Voici le mécanisme. Si vous comprenez ce seul point, la plupart des comportements déroutants dans ce domaine deviennent prévisibles.

TCC se lie à l'identité de signature de code, pas à un chemin ni à un nom

Lorsque vous accordez une autorisation à une application, macOS n'enregistre pas « le fichier situé à /Applications/Foo.app peut enregistrer l'écran ». Il enregistre une décision liée à l'identité de signature de code de l'application : son identifiant, et l'exigence cryptographique qui décrit qui l'a signée. La note technique TN3127 d'Apple, « Inside Code Signing: Requirements », est la référence sur la façon dont ces exigences sont construites.

La conséquence, c'est ce que personne ne vous dit : si l'identité de signature change, macOS traite l'application comme une application différente à laquelle rien n'a jamais été accordé. L'ancienne entrée reste dans le volet, avec l'air d'être accordée, et décrit une application qui n'existe plus sous la forme que la base de données garde en mémoire. Vous voyez un interrupteur activé. Le système, lui, voit un inconnu.

Vous pouvez inspecter vous-même l'identité d'une application. Sur le Mac de test :

codesign -dv --verbose=2 /System/Applications/Utilities/Terminal.app

La sortie comprend une ligne Identifier, qui est l'identifiant de bundle utilisé par le système (com.apple.Terminal pour Terminal), une chaîne de lignes Authority nommant les certificats qui l'ont signée, et une ligne TeamIdentifier. Pour les applications fournies par Apple, TeamIdentifier indique not set, car Apple signe ses logiciels système via une chaîne d'autorité différente de celle qu'utilisent les développeurs tiers. Pour une application tierce, vous devriez voir un identifiant d'équipe de dix caractères et une chaîne d'autorité incluant un certificat Developer ID.

Cet identifiant d'équipe est l'ancrage stable. Une application signée ad hoc, sans identifiant d'équipe, est identifiée par son seul hachage de code, et un hachage de code change à chaque compilation. Une application signée avec un Developer ID possède une identité d'équipe stable qui survit aux mises à jour. C'est pour cela que certaines applications redemandent après chaque mise à jour et que la plupart ne le font pas.

Passons maintenant aux cas particuliers.

Cas un : l'application a été mise à jour et signée différemment

L'application a publié une nouvelle version. La nouvelle compilation a été signée avec un certificat différent, ou le développeur est passé de la signature ad hoc à un Developer ID, ou l'inverse, ou son certificat a expiré et il a resigné avec un nouveau.

Comment le repérer : le calendrier coïncide exactement avec une mise à jour, et l'application a soit disparu du volet, soit gagné une deuxième entrée.

Solution : supprimez l'entrée obsolète et réaccordez l'autorisation. Il n'y a rien d'autre à faire ; du point de vue de TCC, l'application est réellement une nouvelle application.

Cas deux : deux copies de la même application sur le disque

C'est la cause la plus fréquente du symptôme « activée mais ne fonctionne pas », et la plus facile à manquer.

Vous avez téléchargé une application, vous l'avez lancée une fois depuis ~/Downloads, vous avez accordé l'autorisation, puis vous l'avez ensuite glissée dans /Applications. Ou bien Homebrew Cask en a installé une copie alors que vous en aviez déjà une. Ou encore vous conservez une version stable dans /Applications et une bêta dans ~/Applications. Le volet affiche une ligne avec le nom et l'icône de l'application ; il ne vous dit pas à quelle copie cette ligne correspond. Vous regardez une autorisation accordée à la copie de ~/Downloads alors que vous lancez la copie de /Applications.

Comment le repérer : cherchez toutes les copies présentes sur le disque.

mdfind "kMDItemKind == 'Application'" -name "AppName"

Ou, pour un balayage incluant les copies que Spotlight n'a peut-être pas indexées :

find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null

Si plusieurs chemins remontent, vous tenez votre réponse.

Solution : supprimez les copies dont vous ne voulez pas, gardez-en exactement une, puis effectuez une réattribution propre sur la survivante. Ne sautez pas la suppression : laisser une deuxième copie sur le disque garantit que vous serez de retour ici dans un mois.

Cas trois : l'application a été déplacée après l'attribution

Apparenté au cas deux, mais distinct. Il n'y a qu'une seule copie, mais elle a changé d'emplacement. Certaines applications y survivent proprement et d'autres non, selon la manière dont leur exigence de signature est rédigée et selon qu'un assistant embarqué a ou non son chemin inscrit dans la structure du parent.

Comment le repérer : l'application fonctionnait, vous avez réorganisé votre dossier Applications ou restauré depuis une migration, et elle est tombée en panne.

Solution : réattribution propre au nouvel emplacement. Si elle a été déplacée dans un sous-dossier de /Applications, essayez d'abord de la remettre au premier niveau ; quelques applications dotées d'un mécanisme d'auto-mise à jour se comportent mal dans les sous-dossiers.

Cas quatre : une mise à jour incomplète a invalidé la signature

Une mise à jour a été interrompue, un outil de synchronisation a touché au bundle, un antivirus a mis en quarantaine puis restauré un fichier à l'intérieur, ou une restauration de sauvegarde a reconstruit le bundle de façon imparfaite. La signature ne se valide plus.

Comment le repérer :

codesign --verify --deep --strict --verbose=2 /Applications/AppName.app

Un bundle sain produit un compte rendu court se terminant par une mention indiquant que l'application est valide sur le disque et satisfait à son exigence désignée. Un bundle endommagé nomme le fichier précis qui échoue. Si vous voyez un échec ici, aucune manipulation d'autorisations n'y changera quoi que ce soit, car macOS ne fera pas du tout confiance au bundle.

Solution : réinstallez depuis le téléchargement d'origine du développeur. C'est l'un des rares cas où « réinstallez l'application » est réellement la bonne réponse plutôt qu'un haussement d'épaules. Un mode de défaillance apparenté et plus visible du même dommage sous-jacent est la boîte de dialogue « l'application est endommagée et ne peut pas être ouverte », que nous traitons en détail dans le guide de correction Gatekeeper et quarantaine.

Cas cinq : les auto-actualiseurs à la Sparkle qui remplacent leur propre bundle

De nombreuses applications Mac distribuées en dehors de l'App Store se mettent à jour elles-mêmes à l'aide du framework Sparkle ou d'un équivalent, en téléchargeant une nouvelle version et en remplaçant leur propre bundle en cours d'exécution.

Quand cela fonctionne correctement, le nouveau bundle porte le même identifiant d'équipe et TCC continue de le reconnaître. Quand ce n'est pas le cas — parce que la mise à jour a été signée différemment, parce que l'échange a laissé un bundle partiellement écrit, ou parce que l'application s'est remplacée à un chemin légèrement différent — vous obtenez une redemande ou un échec silencieux la prochaine fois que vous utilisez une fonction protégée.

Comment le repérer : l'application se met à jour toute seule en dehors de l'App Store, et les problèmes d'autorisation se concentrent autour du moment de la mise à jour.

Solution : réattribution propre une fois la mise à jour terminée. Si cela se produit à chaque mise à jour, c'est la configuration de signature du développeur qui pose problème, et cela mérite de lui être signalé, car c'est corrigeable de son côté.

Le diagnostic général

Face à n'importe quel cas « accordée mais ne fonctionne pas », posez trois questions dans cet ordre : combien de copies de cette application existent sur le disque (mdfind), le bundle se vérifie-t-il (codesign --verify), et la panne est-elle survenue immédiatement après une mise à jour ? Ces trois réponses désignent presque à chaque fois l'un des cinq cas ci-dessus.

Les outils du Terminal : ce que tccutil peut et ne peut pas faire

Il existe exactement un outil en ligne de commande pour ce sous-système, et ses capacités sont bien plus étroites que ne le laissent entendre la plupart des guides.

reset est la seule commande

Lancez tccutil sans argument sur macOS 26.5.2 et il affiche sa syntaxe d'utilisation :

tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]

C'est là toute l'interface. La page man d'Apple est explicite : « une seule commande est actuellement prise en charge », et la décrit ainsi :

reset Réinitialise toutes les décisions pour le service spécifié, ce qui amène les applications à redemander lors de leur prochain accès au service. Si un identifiant de bundle est spécifié, le service sera réinitialisé pour ce seul bundle.

Les exemples fournis par Apple dans la page de manuel sont tccutil reset AddressBook et tccutil reset All com.apple.Terminal.

Tirez-en la conséquence que la plupart des guides passent sous silence : il n'existe aucune commande d'attribution. Vous ne pouvez pas approuver une autorisation depuis le Terminal. reset oublie une décision afin que l'application redemande ; il ne dit pas oui à votre place. Les seules manières de dire oui sont l'interface System Settings et un profil de configuration MDM. Si vous trouvez un guide affirmant qu'une incantation tccutil accorde Full Disk Access, il a tort.

L'avertissement sur l'identifiant de bundle qui compte le plus

C'est le cœur pratique de toute la section Terminal, il mérite donc son propre espace.

# DANGEROUS - resets screen recording for EVERY app on the Mac
tccutil reset ScreenCapture

# Correct - resets it for one app only
tccutil reset ScreenCapture com.example.appname

L'identifiant de bundle est facultatif dans la syntaxe et obligatoire en pratique. Omettez-le et vous venez de dire à macOS d'oublier toutes les décisions d'enregistrement d'écran de la machine. Zoom, Slack, Discord, Teams, votre outil de capture, votre logiciel d'enregistrement, votre client d'assistance à distance : tous vous solliciteront à leur prochaine utilisation. Rien n'est cassé de façon permanente, mais vous vous êtes créé un après-midi de boîtes de dialogue pour tenter de réparer une seule application.

tccutil reset All sans identifiant de bundle est encore pire, puisqu'il oublie toutes les décisions, pour tous les services, pour toutes les applications. Si un guide vous dit d'exécuter cela en première étape, fermez le guide.

Ajoutez toujours l'identifiant de bundle. À chaque fois, sans exception.

L'ordre de validation des arguments, et pourquoi il peut masquer une faute de frappe

Ceci a été testé directement, et le comportement change la manière dont vous devez lire les erreurs. tccutil valide l'identifiant de bundle avant le nom de service. Donnez-lui un service bidon et un identifiant de bundle bidon ensemble :

tccutil reset ZZZNotAService com.example.nonexistent.zzz

et il renvoie :

tccutil: No such bundle identifier "com.example.nonexistent.zzz": The operation couldn't be completed. (OSStatus error -10814.)

Il se plaint du bundle, et non du nom de service manifestement invalide. Donnez-lui un service bidon sans aucun identifiant de bundle :

tccutil reset ZZZNotAService

et il renvoie :

tccutil: Failed to reset ZZZNotAService

Conséquence pratique : une faute de frappe dans l'identifiant de bundle vous donne toujours une erreur claire et précise, ce qui est une bonne chose. Mais une faute de frappe dans le nom de service peut être masquée lorsque l'identifiant de bundle est lui aussi erroné, car l'outil ne va jamais assez loin pour s'en plaindre. Si vous obtenez l'erreur -10814, corrigez d'abord l'identifiant de bundle, puis relancez la commande et voyez si le nom de service était lui aussi faux.

Le corollaire est le suivant : vérifiez l'identifiant de bundle avant de construire la commande.

Comment trouver l'identifiant de bundle d'une application

Deux méthodes fiables. La première a été vérifiée sur le Mac de test, où osascript -e 'id of app "Terminal"' a renvoyé com.apple.Terminal et osascript -e 'id of app "Safari"' a renvoyé com.apple.Safari :

osascript -e 'id of app "AppName"'

Remplacez par le nom de l'application tel qu'il apparaît dans le Finder. C'est la méthode la plus rapide, et c'est celle que les lecteurs de Howard Oakley ont fait remonter dans les commentaires de son panorama de la protection de la vie privée, ce qu'il a reconnu.

La seconde méthode lit directement le bundle, ce qui est utile quand l'application ne se trouve pas à un emplacement standard ou qu'AppleScript n'arrive pas à résoudre le nom :

defaults read /Applications/AppName.app/Contents/Info.plist CFBundleIdentifier

Ou utilisez la vue de signature de code, qui vous montre en même temps l'autorité de signature, et lisez sa ligne Identifier= :

codesign -dv --verbose=2 /Applications/AppName.app

Utilisez celle que vous préférez, mais utilisez-en une. Ne devinez pas l'identifiant à partir du nom de l'application. La nomenclature DNS inversée est une convention, pas une règle, et bien des applications ont des identifiants qui ne ressemblent en rien à ce que vous auriez deviné.

Les noms de services relèvent du savoir communautaire, pas de la documentation Apple

C'est ici que l'honnêteté compte plus que l'exhaustivité.

Apple ne publie pas la liste des noms de services acceptés par tccutil reset. La page man en donne exactement deux à titre d'exemple : AddressBook et All. C'est là l'intégralité de la documentation d'Apple sur le sujet.

Les noms qui circulent viennent de la communauté. Howard Oakley a publié une liste dans son panorama de mars 2025 sur la protection de la vie privée, qui comprend entre autres :

Accessibility, AddressBook, All, AppleEvents, AudioCapture, BluetoothAlways, Calendar, Camera, ContactsFull, ContactsLimited, DeveloperTool, FocusStatus, MediaLibrary, Microphone, Motion, Photos, PostEvent, Reminders, RemoteDesktop, ScreenCapture, SpeechRecognition, SystemPolicyAllFiles, SystemPolicyDesktopFolder, SystemPolicyDocumentsFolder, SystemPolicyDownloadsFolder, SystemPolicyNetworkVolumes, SystemPolicyRemovableVolumes.

Deux d'entre eux correspondent aux volets qui intéressent le plus cet article : ScreenCapture pour Screen & System Audio Recording, et SystemPolicyAllFiles pour Full Disk Access.

Je n'ai délibérément pas testé ces noms par force brute sur le Mac de test. Un tccutil reset qui réussit efface les autorisations réelles de la machine : la seule façon de confirmer qu'un nom fonctionne est donc de détruire ce que vous cherchiez à préserver, et tester ceux qui échouent ne vous apprend rien. La liste ci-dessus relève d'un savoir communautaire bien sourcé qui correspond à ce que les praticiens utilisent sur le terrain. Ce n'est pas de la documentation Apple, et je préfère le dire plutôt que de la présenter comme faisant autorité.

Deux choses en découlent. Si un tccutil reset semble ne rien faire, envisagez que le nom de service soit erroné avant de conclure que le système est cassé. Et préférez la voie System Settings quand vous le pouvez, car le volet, lui, n'a jamais de problème d'orthographe.

Binaires en ligne de commande et outils assistants

C'est le domaine où le modèle « une application, une entrée dans une liste » s'effondre le plus durement, et où un bug bien documenté de macOS 26 a considérablement aggravé les choses pendant un temps.

Un exécutable simple n'a pas d'identifiant de bundle

Un .app est un bundle : un répertoire à structure définie contenant un Info.plist qui déclare, entre autres, un CFBundleIdentifier. Un binaire compilé posé dans /usr/local/bin n'a rien de tout cela. Ce n'est qu'un exécutable Mach-O.

Le modèle de TCC est bâti autour des bundles. Un exécutable simple peut malgré tout recevoir une autorisation, mais il n'a aucun identifiant de bundle sur lequel s'indexer, ce qui explique qu'il puisse ne pas apparaître dans le volet comme le ferait une application, et que tccutil reset Service bundle.id n'ait rien à viser pour lui.

Le bug d'affichage de macOS 26.1, et ce qu'il a appris à tout le monde

Fin 2025, un ensemble de fils de discussion sur les Apple Developer Forums a rapporté la même chose pour différentes autorisations. Cela mérite d'être parcouru, car les ingénieurs d'Apple eux-mêmes ont confirmé le diagnostic et le dénouement vous apprend quelque chose de durable sur la relation entre le volet et la base de données.

Le fil 807898, « Issue: Plain Executables Do Not Appear Under 'Screen & System Audio Recording' on macOS 26.1 (Tahoe) », rapportait qu'un exécutable simple demandant l'enregistrement d'écran recevait bien l'invite habituelle, capturait bien l'écran correctement une fois l'autorisation accordée, mais n'apparaissait jamais dans la liste de System Settings. Résumé de l'auteur : « macOS 26.1 (Tahoe) semble exiger des bundles d'application pour qu'un élément s'affiche dans l'interface de confidentialité Screen Recording. Les exécutables simples : demandent et reçoivent toujours l'autorisation, fonctionnent toujours correctement une fois l'autorisation accordée, mais n'apparaissent pas dans la liste de System Settings. » Le même code empaqueté en bundle .app apparaissait normalement. Quinn « The Eskimo! », ingénieur DTS chez Apple, a répondu en le confirmant : « À mon avis, c'est un bug et je vous encourage à le signaler comme tel. »

Le fil 807323, « Background Unix executable not appearing in Screen Recording permissions UI (macOS Tahoe 26.1) », rapportait le même symptôme sous un autre angle. Un exécutable Unix d'arrière-plan appelant CGRequestScreenCaptureAccess() fonctionnait sur 26.0.1 et a cessé d'apparaître dans l'interface sur 26.1. L'auteur notait qu'ajouter manuellement l'exécutable avec le bouton + « accorde l'autorisation en interne, mais l'exécutable n'apparaît toujours pas dans l'interface », si bien que les utilisateurs « ne peuvent ni vérifier ni révoquer les autorisations ». Ce fil n'a reçu aucune réponse d'Apple, seulement la corroboration d'un autre développeur. Le fil 809549 a soulevé le même problème pour Full Disk Access, en rapportant que les binaires en ligne de commande « n'apparaissent pas dans les réglages FDA, même après sélection » ; Quinn l'a redirigé vers le fil consolidé existant et un modérateur l'a verrouillé.

C'est dans ce fil consolidé, le 806187, que se trouve la résolution. La conclusion clé : les autorisations étaient correctement enregistrées depuis le début. La base de données avait raison ; la liste avait tort. Comme l'a formulé un participant, « les applications CLI peuvent disposer de Full Disk Access ou d'autres autorisations, mais vous ne pouvez pas le voir dans la liste ». Une fonctionnalité de « Background Security Improvements » ajoutée en 26.1 avait modifié l'interface des réglages pour n'afficher que les applications empaquetées.

Le contournement provisoire consistait à « faire glisser le binaire depuis le Finder vers la liste Full Disk Access dans la fenêtre System Settings. L'autorisation sera accordée, mais elle n'apparaîtra pas dans la liste. » La recommandation durable est venue de Kevin Elliott, un autre ingénieur DTS : « La meilleure solution consiste à intégrer cet outil dans un bundle d'application. Je ne veux pas dire "faites en sorte que votre outil en ligne de commande se comporte comme une application", je veux dire "prenez votre outil en ligne de commande et placez-le dans un bundle d'application, puis utilisez-le exactement comme vous le faisiez avant". »

Plusieurs participants ont confirmé que le bug d'affichage était corrigé dans la bêta de macOS 26.3, et quelqu'un sur le fil 807898 a rapporté qu'une variante du problème touchant Accessibility, présente en 26.1 et dans la bêta 26.2, était elle aussi résolue en 26.3.

Pourquoi cela vous concerne même si vous avez dépassé 26.1 : le volet est une vue de la base de données, et une vue peut mentir. Si une application ou un outil dispose manifestement d'une autorisation mais n'apparaît pas dans la liste, ne supposez pas que l'autorisation manque. Testez le comportement avant de commencer à réinitialiser des choses.

Pourquoi une application lancée depuis le Terminal hérite des autorisations du Terminal

Cela fait constamment trébucher les développeurs, et une fois la règle connue, le mystère disparaît.

TCC ne se contente pas de demander « quel binaire émet cette requête ? » Il parcourt ce que Howard Oakley décrit comme « une chaîne d'attribution qui remonte la chaîne d'appels jusqu'à une application responsable des réglages de confidentialité à appliquer ». Le système cherche le processus responsable, qui est généralement l'application lancée par l'utilisateur, et non le processus le plus profond de la chaîne.

Ainsi, lorsque vous exécutez un programme depuis le Terminal, c'est typiquement Terminal qui est le processus responsable. La demande de capture d'écran de votre programme devient la demande de capture d'écran de Terminal. Si Terminal détient l'autorisation, votre programme fonctionne ; sinon, l'invite nomme Terminal plutôt que votre programme. C'est exactement ce qu'a observé l'auteur du fil 807898 : lorsqu'il est lancé depuis une autre application telle que VS Code ou Terminal, « c'est l'application parente qui apparaît dans la liste, et non l'exécutable lui-même ».

Trois conséquences au quotidien. Accorder une autorisation à votre émulateur de terminal signifie que chaque outil que vous y exécutez hérite de cette attribution, ce qui est pratique mais constitue aussi une véritable extension de privilèges, à laquelle il vaut mieux réfléchir avant de le faire à la légère. Le même script se comporte différemment selon qu'il est lancé depuis Terminal, depuis un LaunchAgent ou depuis un wrapper applicatif ouvert par double-clic, parce que le processus responsable diffère à chaque fois. Et changer d'émulateur de terminal, c'est repartir de zéro, puisque iTerm2, Ghostty, Warp, Kitty et Terminal.app constituent chacun une identité distincte.

Outils assistants, services XPC et éléments de connexion

Une application Mac moderne, c'est fréquemment plusieurs exécutables : l'application principale, éventuellement un assistant privilégié sous /Library/PrivilegedHelperTools, éventuellement des services XPC embarqués dans le bundle, éventuellement un agent de lancement qui démarre à l'ouverture de session.

Les services XPC embarqués dans un bundle correctement signé opèrent généralement sous l'attribution de l'application parente, car la chaîne se résout jusqu'à l'application. Les assistants et démons de lancement installés séparément, très souvent non : ils s'exécutent en dehors de l'arborescence de processus de l'application, avec leur propre identité, et nécessitent leur propre attribution. C'est pour cela que certaines applications vous demandent d'approuver une autorisation deux fois, une fois pour l'application et une fois pour son assistant, et pour cela qu'un assistant installé en tant que root peut nécessiter une entrée dans la base de données système plutôt que dans votre base par utilisateur.

Si une application ne fonctionne qu'à moitié, avec une interface qui répond mais une fonction d'arrière-plan qui échoue silencieusement, un assistant dépourvu d'autorisation est un suspect sérieux. La documentation d'assistance de l'application elle-même est le chemin le plus rapide pour savoir quel assistant a besoin de quoi, car vous ne pouvez pas le déterminer depuis le volet.

Le cas particulier de l'enregistrement d'écran

Le volet est System Settings → Privacy & Security → Screen & System Audio Recording. Description d'Apple, mot pour mot : « Autorisez des apps à enregistrer votre écran et votre audio, ou seulement votre audio. Les apps listées y ont accès. »

Points spécifiques à cette autorisation :

C'est la seule autorisation soumise à une redemande programmée. Aucune autre catégorie TCC ne redemande selon un minuteur. Si votre autorisation de caméra ou votre Full Disk Access vous sollicite tous les mois, ce n'est pas le comportement prévu et vous avez un défaut.

La basculer exige généralement de redémarrer l'application. Beaucoup d'applications lisent la capacité de capture une seule fois au lancement. Activez l'interrupteur pendant que l'application tourne et elle risque de ne rien remarquer avant d'être relancée. Cela explique à lui seul une bonne part des rapports du type « je l'ai activée et il ne s'est rien passé ».

L'audio système et l'écran sont regroupés mais pas identiques. Le volet couvre les deux. Certaines applications ne demandent que l'audio. Si une application capture bien votre écran mais enregistre le silence, vérifiez si elle a seulement demandé la capture de l'audio système, et contrôlez les réglages de périphérique audio de l'application, car un périphérique audio virtuel manquant est un problème complètement distinct d'un problème TCC. Le guide complet de l'enregistrement d'écran sur Mac détaille le versant audio.

Un cas concret difficile, rapporté honnêtement. Un fil Microsoft Q&A documente Teams pour Mac sous macOS Tahoe 26.4, build 25E246, tournant en boucle sur l'invite d'autorisation de partage d'écran. L'administrateur à l'origine du signalement a vérifié tout ce qu'il est humainement possible de vérifier : un profil PPPC déployé par MDM ciblant com.microsoft.teams2 avec une exigence de code correcte, l'enregistrement TCC de niveau système affichant auth_value=2 pour kTCCServiceScreenCapture, l'enregistrement de niveau utilisateur affichant la même chose, et System Settings montrant Teams activé avec la mention indiquant que le réglage avait été configuré par un profil. Il avait vidé les caches, supprimé l'identifiant hérité com.microsoft.teams, réinstallé via MDM, tué et relancé les processus, et redémarré.

Les réponses proposées relevaient de la remédiation standard : « quittez complètement Teams, supprimez puis rajoutez ou rebasculez l'entrée Teams dans Screen Recording, puis redémarrez Teams et retentez le partage afin que macOS puisse redemander et relier à nouveau l'autorisation », et, à défaut, faire remonter le problème à l'assistance Microsoft avec les journaux du client. Trois semaines plus tard, l'auteur indiquait qu'aucune solution fonctionnelle ne lui avait été fournie et qu'il utilisait l'application web à la place. Il arrive que l'autorisation soit réellement accordée à toutes les couches et que le fautif soit un bug côté application. Savoir quand s'arrêter fait partie du métier.

Le cas particulier de Full Disk Access

Full Disk Access est l'autorisation la plus large du système. C'est celle dont ont besoin les outils de sauvegarde, les utilitaires de migration, les logiciels de sécurité et les émulateurs de terminal utilisés pour l'administration.

Ce n'est pas la même chose que les entrées Files and Folders. Files and Folders accorde un dossier précis. Full Disk Access accorde l'accès aux données protégées de toute la machine : Mail, Messages, les données de navigation de Safari, les sauvegardes Time Machine et les répertoires de conteneur des autres applications. Une application disposant de Full Disk Access n'a besoin de rien dans Files and Folders.

Elle exige presque toujours un redémarrage de l'application. Plus que toute autre autorisation, Full Disk Access tend à être évaluée au démarrage du processus. Accordez-la, puis quittez et relancez l'application. Beaucoup d'applications affichent une boîte de dialogue vous demandant précisément cela ; croyez-les.

Elle ne peut pas être demandée par une invite. Une application ne peut pas afficher une boîte de dialogue qui accorderait Full Disk Access en cas d'approbation ; elle peut seulement vous renvoyer vers le volet. C'est pour cela que les applications qui en ont besoin affichent des instructions plutôt qu'une boîte de dialogue système, et pour cela que « j'ai cliqué sur Allow et ça ne marche toujours pas » est un rapport fréquent : il n'y avait aucun Allow à cliquer.

Pour un émulateur de terminal, l'attribution est large. Donner Full Disk Access à Terminal ou à iTerm2 signifie que chaque commande que vous y exécutez dispose de cette portée, via la chaîne d'attribution décrite plus haut. C'est souvent exactement ce que veut un administrateur. Comprenez simplement ce que vous faites.

Les outils en ligne de commande ont été touchés par le bug d'affichage de 26.1 décrit plus haut, le correctif étant arrivé dans la bêta 26.3. Si vous êtes en 26.1 ou 26.2 et qu'un outil CLI refuse d'apparaître dans la liste après l'y avoir ajouté, c'est le bug connu et il est fort possible que l'outil dispose malgré tout de l'autorisation. Testez le comportement plutôt que de faire confiance à la liste.

Le cas particulier d'Accessibility et d'Automation

Ces deux volets sont regroupés parce qu'ils produisent une confusion de même nature.

Accessibility accorde à une application la capacité de contrôler votre Mac. Les gestionnaires de fenêtres, les expanseurs de texte, les gestionnaires de presse-papiers, les remappeurs de clavier, les outils d'automatisation et les logiciels d'assistance à distance en ont tous besoin, et macOS la traite comme l'autorisation puissante qu'elle est.

Son comportement distinctif : beaucoup d'applications nécessitent de quitter complètement puis de relancer, et certaines exigent que l'interrupteur soit désactivé puis réactivé, pour que le changement soit pris en compte. Si une application dépendante d'Accessibility cesse de fonctionner après une mise à jour, examinez d'abord les cas d'identité de signature de code vus plus haut. Accessibility faisait aussi partie des volets touchés par le bug d'affichage de macOS 26.1, un message du fil 807898 indiquant que la variante Accessibility « a maintenant été corrigée dans la bêta 26.3 ».

Automation est structurellement différent de tous les autres volets. Ce n'est pas une liste d'applications mais une liste de paires : « l'application A souhaite contrôler l'application B », chaque paire constituant une décision distincte. Si votre script contrôle trois applications, vous avez trois décisions et trois entrées.

Deux choses en découlent. Une autorisation Automation cassée signifie souvent qu'une paire parmi plusieurs manque, et le volet est le seul endroit où vous pouvez voir laquelle. Et réinitialiser Automation avec tccutil reset AppleEvents com.example.controller efface d'un coup toutes les paires de ce contrôleur : vous réapprouverez donc chaque cible la prochaine fois que votre script y touchera. C'est souvent la sortie la plus rapide d'un état Automation bloqué, mais préparez-vous à la série d'invites.

Un piège qui mérite d'être nommé : lancez un AppleScript depuis le Terminal et l'attribution enregistrée sera « Terminal contrôlant l'application cible », et non « votre script la contrôlant ». Déplacez le script vers un autre émulateur de terminal, ou empaquetez-le dans une application, et vous devrez l'approuver à nouveau. C'est la chaîne d'attribution fonctionnant comme prévu, ce qui ne la rend pas moins surprenante la première fois.

La séquence de réattribution propre

Lorsque vous avez identifié un véritable défaut, voici la séquence. Suivez-la dans l'ordre. Chaque étape existe pour une raison, et en sauter une est la façon dont les gens concluent que tout l'exercice ne fonctionne pas.

1. Quittez complètement l'application.

Pas seulement fermer sa fenêtre. Quittez-la avec Cmd-Q, puis vérifiez qu'il ne reste rien :

pgrep -fl "AppName"

S'il reste des processus, ils retiennent l'ancien état d'autorisation et tout ce que vous ferez ensuite sera évalué au regard d'une décision obsolète encore en mémoire.

Pourquoi : un processus en cours d'exécution met en cache son état d'autorisation. Réinitialiser la base de données sous un processus vivant produit un comportement incohérent qui vous enverra à la poursuite d'un fantôme.

2. Vérifiez qu'il existe exactement une copie de l'application sur le disque.

mdfind "kMDItemKind == 'Application'" -name "AppName"

Supprimez toute copie que vous n'utilisez pas.

Pourquoi : si deux copies existent, vous risquez de réaccorder l'autorisation à la mauvaise et de vous retrouver exactement au point de départ. C'est l'étape que les gens sautent, et la raison pour laquelle la séquence échoue chez eux.

3. Confirmez l'identifiant de bundle.

osascript -e 'id of app "AppName"'

Pourquoi : un identifiant erroné vous donne au mieux l'erreur -10814, et au pire vous incite à retirer complètement l'identifiant de la commande reset, ce qui est la voie destructrice.

4. Supprimez l'entrée de l'application dans le volet.

Ouvrez System Settings → Privacy & Security → le volet concerné, sélectionnez l'application, cliquez sur -. Si une authentification administrateur vous est demandée, fournissez-la.

Pourquoi : cela supprime la décision obsolète via l'interface prise en charge. Ce n'est pas la même chose que de désactiver l'interrupteur, ce qui enregistre un refus plutôt que de supprimer la décision. Un refus signifie que l'application ne sera plus autorisée à vous solliciter.

5. Réinitialisez le service pour cet identifiant de bundle.

tccutil reset ScreenCapture com.example.appname

Remplacez par le nom de service et l'identifiant corrects. SystemPolicyAllFiles pour Full Disk Access, Accessibility pour Accessibility, AppleEvents pour Automation.

Pourquoi : le volet et la base de données peuvent diverger, comme le bug de 26.1 l'a démontré de manière concluante. Faire à la fois la suppression dans l'interface et la réinitialisation vous couvre quelle que soit celle que le système consulte réellement. L'identifiant de bundle n'est pas facultatif ici.

6. Relancez l'application.

Pourquoi : un processus neuf, sans décision en cache et sans résidu de l'exécution précédente.

7. Déclenchez l'action qui nécessite l'autorisation.

Lancez un partage d'écran. Ouvrez le dossier. Envoyez l'Apple event. Ne retournez pas dans System Settings pour préactiver l'interrupteur.

Pourquoi : l'invite est le mécanisme qui lie l'identité de signature actuelle à la décision. Cette liaison est tout l'objet de l'exercice. Préactiver un interrupteur dans le volet écrit parfois une décision qui n'est pas correctement liée, ce qui explique les rapports d'un interrupteur activé et d'une application qui ne fonctionne pas.

8. Approuvez à l'invite.

Cliquez sur Allow, ou sur Open System Settings et activez-la là si l'application relève d'une des catégories qui ne peuvent pas solliciter directement, comme Full Disk Access.

9. Quittez et relancez l'application une fois de plus.

Pourquoi : beaucoup d'applications ne lisent leur jeu de capacités qu'au lancement. Cette étape convertit « accordée » en « réellement utilisable » et élimine le faux négatif le plus courant de toute la procédure.

Si l'application échoue encore après l'étape neuf, le problème n'est pas l'autorisation. Passez à la section suivante.

Quand rien ne fonctionne

Testez avec un compte utilisateur neuf

Créez un nouveau compte administrateur dans System Settings → Users & Groups, connectez-vous dessus, installez ou lancez l'application, et accordez-y l'autorisation.

Ce seul test découpe proprement l'espace du problème :

• Ça fonctionne dans le nouveau compte : le défaut se situe dans l'état de votre compte utilisateur, très probablement la base TCC par utilisateur, une préférence obsolète ou un élément d'ouverture de session qui interfère. L'application et le système vont bien.
• Ça échoue aussi dans le nouveau compte : le défaut est à l'échelle du système ou dans l'application elle-même. Votre compte n'est pas en cause, et une bonne partie des conseils du type « supprimez vos préférences » que vous vous apprêtiez à essayer vous auraient gâché la soirée.

Cela prend cinq minutes et vaut plus qu'une heure de suppositions.

Quand une réinstallation complète est vraiment la réponse

Réinstaller est la réponse réflexe à tout, et elle est généralement mauvaise. Elle est réellement pertinente dans trois situations :

1. codesign --verify signale que le bundle est endommagé. La signature ne se valide pas ; rien en aval ne peut être réparé. Réinstallez depuis le téléchargement d'origine du développeur, pas depuis une sauvegarde, car la sauvegarde peut être la source du dommage.
2. L'application a été installée depuis une source qui l'a modifiée. Les installateurs reconditionnés, les outils qui patchent des bundles d'application et certains mécanismes de déploiement en entreprise laissent un bundle dont la signature ne correspond plus à celle du développeur. Récupérez une copie propre auprès du développeur.
3. La documentation d'assistance de l'application le préconise pour le symptôme précis que vous rencontrez. Certaines applications ont des problèmes connus d'état d'autorisation, avec des procédures de réinstallation documentées, y compris des étapes pour effacer leurs propres répertoires d'état.

En dehors de ces trois cas, une réinstallation reproduit généralement le bundle que vous aviez déjà, et si l'identité de signature est inchangée, la situation des autorisations le sera tout autant.

Redémarrez, mais pour la bonne raison

Un redémarrage efface l'état des processus, recharge les démons de lancement et réinitialise les caches en mémoire. Il corrige réellement une classe d'états d'autorisation bloqués, en particulier ceux impliquant des assistants d'arrière-plan qui ne se rechargent pas proprement. Il ne corrige pas une incohérence de signature de code, une copie en double sur le disque, un bundle endommagé ni un bug applicatif. Redémarrez une fois, tôt, puis revenez au diagnostic.

Ce qu'il ne faut pas faire

Pour être explicite, car ces conseils apparaissent constamment dans les résultats de recherche : ne désactivez pas SIP, ce qui supprime des protections sur tout le système pour contourner une boîte de dialogue. Ne modifiez pas et ne supprimez pas TCC.db, ce que vous ne pouvez pas faire avec SIP activé et ne devriez pas vouloir faire avec SIP désactivé. Ne faites pas de chmod -R sur votre dossier personnel, ce qui ne touche pas à ce sous-système et peut casser votre dossier Library. Et n'exécutez pas tccutil reset All sans identifiant de bundle, sauf si vous voulez passer le reste de la journée à cliquer sur Allow.

Les Mac gérés

Si votre Mac est administré par un employeur ou un établissement scolaire, les règles changent, et il vaut la peine de savoir si c'est votre cas avant de passer une heure à vous battre contre un interrupteur que vous n'alliez de toute façon jamais gagner.

Comment savoir si votre Mac est géré

Trois vérifications. Premièrement, regardez System Settings → General → Device Management. Si un profil est installé, il y figure. Deuxièmement, cherchez la mention dans le volet de confidentialité lui-même : une entrée gérée affiche un texte indiquant que le réglage a été configuré par un profil, et son interrupteur est généralement grisé. Troisièmement, depuis le Terminal :

profiles status -type enrollment

Sur le Mac de test non géré, cela a renvoyé :

Enrolled via DEP: No
MDM enrollment: No

Un Mac géré signale ici une inscription à la place.

Ce qu'un profil peut et ne peut pas faire

Le MDM accorde des autorisations via une charge utile Privacy Preferences Policy Control, généralement appelée profil PPPC. Elle écrit directement des décisions dans la base TCC du système, ce qui explique qu'un Mac géré puisse disposer d'autorisations apparues sans que personne n'ait cliqué sur quoi que ce soit.

Il y a des limites, et la capture d'écran en fait partie. Kandji, un éditeur MDM dont l'analyse des évolutions de PPPC est largement citée parmi les administrateurs Mac, décrit le mécanisme : pour la capture d'écran et la surveillance des entrées, « l'informatique peut utiliser le MDM pour préautoriser certaines applications à être approuvées même par des utilisateurs standard, afin d'activer la capture d'écran ou la surveillance des entrées ». Cela utilise une valeur d'autorisation qui délègue l'approbation à l'utilisateur plutôt que de l'accorder silencieusement. Un profil peut donc refuser purement et simplement la capture d'écran et peut permettre à un utilisateur standard de l'approuver, mais le comportement documenté est qu'il ne l'accorde pas silencieusement comme il peut le faire pour Full Disk Access ou Accessibility.

Tenez cette nuance avec précaution, car le cas Microsoft Q&A évoqué plus haut impliquait un administrateur signalant un enregistrement TCC de niveau système pour kTCCServiceScreenCapture avec un motif d'autorisation indiquant une politique MDM. Ces deux récits ne s'accordent pas parfaitement, et je les rapporte tous les deux plutôt que de choisir le plus commode.

Si vous utilisez un Mac géré

N'essayez pas de contourner un interrupteur grisé. Vous n'y parviendrez pas, et sur de nombreux déploiements la tentative est journalisée. Un tccutil reset sur une entrée gérée par profil échouera ou sera réappliqué au prochain enregistrement auprès du serveur de gestion. Contactez la personne qui administre votre parc ; le correctif est une modification de profil de son côté et prend une minute.

Si vous administrez un Mac géré

Faites correspondre l'exigence de code de la charge utile PPPC à ce que codesign rapporte réellement pour la version déployée de l'application. Le cas Teams évoqué plus haut est instructif précisément parce que l'administrateur l'avait vérifié et s'est quand même heurté à un mur : un profil correct est nécessaire mais pas toujours suffisant. Lorsqu'une application change d'identifiant de bundle d'une version à l'autre, comme l'a fait Teams, retirez l'identifiant hérité du profil plutôt que de laisser les deux en place.

Résolution des problèmes courants

L'application est listée et activée mais ne peut toujours pas enregistrer

Problem: Le volet montre l'application activée. L'application se comporte comme si elle n'avait aucune autorisation.

Solution: L'entrée est liée à une identité de signature qui ne correspond plus à l'application présente sur le disque. Exécutez d'abord mdfind "kMDItemKind == 'Application'" -name "AppName" pour vérifier la présence d'une deuxième copie, la cause la plus fréquente, et supprimez les exemplaires en trop. Puis déroulez toute la séquence de réattribution propre, en incluant à la fois la suppression dans le volet et le tccutil reset avec l'identifiant de bundle. Ne vous contentez pas de désactiver puis réactiver l'interrupteur ; cela enregistre un refus suivi d'une approbation non liée, ce qui est précisément la façon dont vous en êtes arrivé là.

L'application a disparu de la liste après une mise à jour

Problem: Une application qui figurait dans le volet hier n'y est plus aujourd'hui, et la seule chose qui a changé, c'est une mise à jour.

Solution: La nouvelle compilation a été signée différemment, macOS voit donc une nouvelle application sans historique. Il n'y a rien à réparer : lancez l'application, déclenchez l'action protégée, approuvez la nouvelle invite. Si l'application utilise Full Disk Access, qui ne peut pas solliciter, ajoutez-la avec le bouton +. Si cela se reproduit à chaque mise à jour, la configuration de signature du développeur est instable et mérite de lui être signalée.

Chaque lancement produit une invite, pas une fois par mois

Problem: La boîte de dialogue de capture d'écran apparaît chaque fois que vous ouvrez l'application, plutôt qu'au rythme attendu.

Solution: C'est un défaut, pas la redemande prévue par conception. Les causes probables sont une application signée ad hoc dont le hachage de code change à chaque compilation, un auto-actualiseur qui remplace son bundle de façon répétée, ou un chemin de lancement qui diffère à chaque fois. Exécutez codesign -dv --verbose=2 sur l'application et regardez la ligne TeamIdentifier. Si elle indique not set sur une application tierce, cette application n'est pas signée avec un Developer ID et une autorisation stable est hors d'atteinte tant que le développeur n'aura pas corrigé sa signature.

Deux entrées portant le même nom d'application

Problem: Le volet affiche deux fois la même application, parfois avec des icônes identiques.

Solution: Deux copies existent sur le disque, avec des identités de signature différentes ou des chemins différents. Trouvez-les toutes avec find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null. Gardez-en une, supprimez les autres, retirez les deux entrées du volet, puis réaccordez l'autorisation à la survivante. Si vous conservez délibérément un canal bêta aux côtés d'une version stable, attendez-vous à deux entrées et acceptez-les.

Un outil en ligne de commande n'apparaît pas dans la liste

Problem: Vous ajoutez un binaire avec le bouton + et il n'apparaît pas.

Solution: Sur macOS 26.1 et 26.2, il s'agit du bug d'affichage confirmé décrit plus haut, reconnu par les ingénieurs DTS d'Apple et signalé comme corrigé dans la bêta 26.3. L'autorisation est très probablement enregistrée même si la liste ne l'affiche pas : testez donc le comportement réel avant de pousser le diagnostic plus loin. Sur toute version, les exécutables simples n'ont pas d'identifiant de bundle et n'ont jamais été des citoyens de première classe dans cette interface. La réponse durable, selon les mots de Kevin Elliott dans le fil 806187, consiste à placer l'outil dans un bundle d'application et à continuer de l'utiliser exactement comme avant.

L'invite nomme la mauvaise application

Problem: Vous lancez un script et la boîte de dialogue d'autorisation nomme Terminal, ou VS Code, ou Script Editor, plutôt que votre script.

Solution: C'est la chaîne d'attribution fonctionnant correctement. Le processus responsable est l'application que vous avez lancée, et l'autorisation s'y rattache. Soit vous accordez l'autorisation à cette application hôte en acceptant que tout ce que vous y exécutez hérite de cette attribution, soit vous empaquetez votre outil dans son propre bundle d'application afin qu'il devienne le processus responsable. Sachez que changer d'émulateur de terminal implique d'accorder à nouveau l'autorisation, car chacun constitue une identité distincte.

L'interrupteur est grisé

Problem: Vous ne pouvez pas modifier l'interrupteur, et une mention relative à un profil peut apparaître.

Solution: La décision est fixée par un profil de configuration. Confirmez-le avec profiles status -type enrollment et vérifiez System Settings → General → Device Management. Sur un Mac géré, contactez votre administrateur ; le changement doit se faire dans le profil. Sur un Mac personnel affichant un profil inattendu, examinez ce qui y est installé, car un profil que vous n'avez pas sciemment installé mérite un examen attentif.

L'autorisation fonctionne, puis cesse après une mise en veille ou une longue session

Problem: Le partage d'écran fonctionne en début de journée et échoue après que le Mac a été en veille.

Solution: Vérifiez d'abord si ce que vous constatez n'est pas la boîte de dialogue de reconfirmation périodique apparue derrière une autre fenêtre, car une invite que vous n'avez jamais vue ressemble exactement à un échec silencieux. Ramenez toutes les fenêtres au premier plan et regardez. S'il n'y a pas d'invite, quittez complètement l'application, vérifiez avec pgrep -fl "AppName", et relancez-la, car un processus assistant qui n'a pas réussi à se recharger après le réveil est le coupable habituel. Redémarrez le Mac une fois si le problème persiste. Si cela se reproduit quotidiennement, l'application a un bug de gestion du réveil et cela mérite un signalement à son développeur.

FAQ

Puis-je désactiver l'invite périodique d'enregistrement d'écran ?

Non. Apple ne fournit aucun réglage côté utilisateur pour la désactiver, et il n'existe aucune commande prise en charge qui la supprime. Le seul mécanisme qui l'élimine est le droit d'accès com.apple.developer.persistent-content-capture, une capacité gérée que les développeurs doivent demander à Apple, destinée aux applications de contrôle à distance. Ce n'est pas quelque chose qu'un utilisateur peut activer.

À quelle fréquence macOS redemande-t-il l'autorisation d'enregistrement d'écran ?

Apple n'a jamais documenté l'intervalle. Le comportement a débuté pendant le cycle Sequoia sur une base hebdomadaire, et Apple l'a fait passer à une base mensuelle au cours de cette bêta après les critiques, comme l'ont rapporté MacRumors et 9to5Mac en août 2024. La page d'assistance actuelle d'Apple ne mentionne pas du tout la redemande, et je n'ai pas pu vérifier la cadence de macOS 26 auprès d'une source faisant autorité.

Réinitialiser les autorisations va-t-il supprimer mes données ?

Non. tccutil reset supprime des décisions de consentement enregistrées, rien d'autre. Aucun fichier, réglage ni donnée d'application n'est touché. Le coût, c'est le dérangement : chaque application concernée redemandera l'autorisation la prochaine fois qu'elle en aura besoin. Ce coût est proportionnel à l'ampleur de votre réinitialisation, ce qui est exactement pourquoi vous devriez toujours inclure un identifiant de bundle.

Pourquoi mon application fonctionne-t-elle dans le Terminal mais pas toute seule ?

Parce que TCC attribue la requête au processus responsable, qui, pour un programme lancé depuis le Terminal, est généralement Terminal lui-même. Votre programme emprunte l'autorisation de Terminal. Seul, il n'a aucune autorisation et, s'il s'agit d'un exécutable simple plutôt que d'un bundle d'application, il risque même de ne pas apparaître dans le volet pour pouvoir en recevoir une.

Est-il dangereux d'accorder Full Disk Access ?

C'est l'autorisation la plus large que propose macOS, couvrant Mail, Messages, les données de Safari, les sauvegardes Time Machine et les conteneurs des autres applications. Ne l'accordez qu'à des logiciels auxquels vous confieriez tout cela, et notez que l'accorder à un émulateur de terminal étend cette portée à chaque commande que vous y exécutez.

Dois-je redémarrer mon Mac après avoir modifié une autorisation ?

En général non. Quitter et relancer l'application concernée suffit presque toujours, et c'est une étape obligatoire car beaucoup d'applications ne lisent leurs capacités qu'au lancement. Un redémarrage complet aide dans le cas plus restreint d'un assistant d'arrière-plan ou d'un démon de lancement qui ne se recharge pas proprement. Redémarrez une fois, puis revenez au diagnostic.

Conclusion

L'essentiel de la frustration dans ce domaine vient du fait de traiter une seule étiquette, « les permissions », comme une seule chose. Il y en a au moins trois : les permissions de fichiers POSIX, régies par chmod et qui n'ont rien à voir avec tout cela ; les décisions de confidentialité TCC, liées à l'identité de signature de code d'une application et stockées dans des bases de données que vous ne pouvez pas lire ; et, sur les Mac gérés, la politique écrite par profil qui prime sur ce que vous pouvez modifier localement.

Une fois ces éléments séparés, l'arbre de décision est court. Une invite de capture d'écran qui arrive selon un calendrier est délibérée, elle n'a aucun interrupteur d'arrêt, et la bonne réponse est de cliquer sur Allow et de reprendre votre journée. Tout le reste est un défaut, et les défauts ont des causes : une deuxième copie de l'application sur le disque, une signature qui a changé lors d'une mise à jour, un bundle qui ne se vérifie plus, un assistant qui a besoin de sa propre autorisation, ou une chaîne d'attribution qui pointe vers votre émulateur de terminal plutôt que vers votre script.

L'outillage est véritablement mince. tccutil n'a qu'un verbe, Apple ne publie pas les noms de services qu'il accepte, et le volet est une vue de la base de données dont on a démontré qu'elle pouvait se tromper, comme l'a montré le bug d'affichage de macOS 26.1 lorsque les ingénieurs d'Apple eux-mêmes ont confirmé que les autorisations étaient correctement enregistrées alors que la liste refusait de les afficher. Composez avec cela : vérifiez l'identifiant de bundle avant de construire une commande, ajoutez-le systématiquement à reset, suivez la séquence de réattribution propre dans l'ordre, et testez avec un compte utilisateur neuf quand vous êtes bloqué. Et sachez quand vous arrêter. Lorsque vous avez vérifié l'attribution, vérifié la signature, éliminé les doublons et testé dans un compte vierge, comme l'a fait l'auteur du signalement Teams sous macOS Tahoe 26.4, le problème qui reste n'est pas le vôtre à résoudre. Signalez-le et utilisez un contournement en attendant.

Lecture complémentaire : Microphone du Mac qui ne fonctionne pas sous macOS Tahoe 26.5 · Sécurité et confidentialité sur macOS Tahoe : le guide complet