Votre app Mac accorde l’accès au micro — puis l’oublie à chaque lancement
GeekBye a demandé l’autorisation du micro, vous l’avez accordée, et ça a marché. Au lancement suivant : disparu. Et l’app n’apparaissait même jamais dans Réglages Système → Microphone. La coupable était une fonction de sécurité de macOS qui exécutait discrètement l’app depuis un chemin qui s’évapore — voici le diagnostic et le correctif en une seule invite.
Voici un bug qui vous fait douter de vos propres yeux. Vous installez GeekBye, il demande l’accès au micro, vous cliquez sur Autoriser, et la transcription fonctionne. Parfait. Vous quittez, vous le rouvrez le lendemain matin — et il demande l’accès au micro à nouveau. Vous allez vérifier dans Réglages Système → Confidentialité et sécurité → Microphone pour corriger ça à la main, et GeekBye n’est même pas dans la liste. Ni refusé. Ni autorisé. Simplement absent, comme s’il n’avait jamais demandé.
Chaque élément pris isolément semblait correct. L’invite était réelle. L’autorisation fonctionnait sur le moment. L’app était correctement signée et notariée, avec les bonnes chaînes d’usage. Et pourtant l’autorisation s’évaporait à chaque lancement. GeekBye v2.0.6 l’a corrigé — et la cause racine est l’une des choses les plus sournoises que macOS fait pour vous protéger.
La fonction qui cachait l’app à elle-même
La coupable est l’App Translocation de macOS, une fonction de sécurité de Gatekeeper. Quand vous téléchargez une app et la lancez directement depuis le DMG ou depuis votre dossier ~/Downloads — partout où elle est encore « en quarantaine » — macOS ne l’exécute pas vraiment depuis l’endroit où vous la voyez. Il la copie de manière transparente vers un chemin aléatoire en lecture seule, enfoui sous /private/var/folders/.../AppTranslocation/…, et exécute cette copie. C’est une bonne défense : elle empêche un téléchargement malveillant de trafiquer les fichiers à côté de lui.
Mais voici la collision. Le système d’autorisations de macOS (TCC — ce qui garde la trace de qui peut utiliser votre micro, caméra, écran) identifie une app par son chemin et son identité de code. Quand l’app est transloquée, ce chemin est aléatoire et temporaire. Donc quand vous accordez l’accès au micro, macOS enregistre consciencieusement l’autorisation — contre un chemin qui n’existera plus au lancement suivant. Vous rouvrez l’app, macOS la transloque vers un chemin aléatoire différent, voit une app dont il n’a aucune trace, et redemande. Et comme ce chemin fantôme n’est jamais un emplacement stable, l’app ne gagne jamais de ligne permanente dans Réglages Système → Microphone.
L’app accordait l’autorisation à un fantôme.
C’est aussi pourquoi seuls certains tombaient dessus. Si votre copie de GeekBye vivait déjà dans /Applications — parce que vous l’y avez glissée, ou parce qu’elle y est arrivée via la mise à jour automatique — il n’y a pas de quarantaine, pas de translocation, un chemin stable, et tout persiste à la perfection. Le bug était invisible pour nous et pour quiconque avait dépassé sa première installation, ce qui est exactement le genre de bug qui survit le plus longtemps.
Le correctif : donner à l’app un vrai chez-soi
Puisque tout le problème est un chemin instable, le correctif consiste à amener l’app sur un chemin stable. La v2.0.6 détecte quand GeekBye s’exécute transloqué (ou simplement en dehors de /Applications) et propose un « Déplacer vers Applications » en un clic — en utilisant l’appel de relocalisation de macOS qui copie le bundle dans /Applications et le relance depuis là. À partir de ce moment, l’app a une identité fixe : l’autorisation du micro tient, l’enregistrement d’écran tient, et GeekBye apparaît enfin dans Réglages Système là où on s’y attend.
L’invite est courtoise à ce sujet. Elle propose Déplacer vers Applications, Pas maintenant et Ne plus demander — et elle retient le dernier choix, pour que l’app n’embête jamais quelqu’un qui a une raison délibérée de l’exécuter depuis ailleurs. La décision de savoir s’il faut même afficher l’invite est isolée dans de petites fonctions pures (cette build est-elle transloquée ? est-elle en dehors de /Applications ? l’utilisateur l’a-t-il supprimée ?) pour que la logique soit testée unitairement sans avoir à lancer une vraie build notariée sur un vrai volume en quarantaine.
La même version a aussi simplifié l’expérience d’autorisation elle-même. GeekBye affichait autrefois une fenêtre d’autorisation personnalisée, faite maison — quelques centaines de lignes d’interface tentant de reproduire quelque chose que le système d’exploitation fait déjà bien. La v2.0.6 l’a supprimée et s’est appuyée sur l’invite d’autorisation native de macOS, soutenue par une bannière discrète et non bloquante qui n’apparaît que lorsqu’une autorisation requise manque réellement. Moins de code, et un comportement que les utilisateurs reconnaissent déjà parce que toutes les autres apps Mac fonctionnent pareil.
Ce dont je suis le plus fier : on l’a prouvé avant d’y croire
Il aurait été facile de deviner la translocation et de livrer un correctif. Au lieu de ça, la version a livré d’abord un diagnostic de démarrage : au lancement, GeekBye rapporte désormais son propre chemin d’exécutable et s’il est transloqué, s’il est à l’intérieur de /Applications, et l’état actuel des autorisations micro et écran. Cette télémétrie a transformé une théorie plausible en une théorie confirmée — les données de production ont montré que les sessions touchées s’exécutaient bien depuis des chemins transloqués en dehors de /Applications, exactement comme prévu.
Cet ordre compte. « L’invite apparaît mais l’autorisation ne tient pas » a plusieurs explications possibles — un problème de signature, une chaîne d’usage manquante, un souci d’entitlement, une bizarrerie de la base de données TCC. Nous avons écarté les causes au niveau de l’API (le chemin de la requête était démontrablement correct), puis laissé les données du monde réel pointer vers la couche identité/chemin plutôt que de livrer un correctif plein d’espoir en croisant les doigts pour que les tickets de support s’arrêtent.
Trois choses que ce bug enseigne
- Une autorisation qui s’affiche mais ne persiste pas est un problème d’identité, pas d’API. Si le code de la requête est correct et que l’autorisation s’évapore quand même, arrêtez de réécrire la requête. Demandez-vous à quel chemin et à quelle identité de code le système d’exploitation lie l’autorisation — et si cette identité est stable d’un lancement à l’autre.
- Livrez le diagnostic avec (ou avant) le correctif. Quelques champs — d’où je m’exécute, quel est mon état d’autorisation — ont transformé une supposition éclairée en une cause racine vérifiée et nous ont dit exactement quels utilisateurs étaient touchés. Instrumentez la frontière que vous suspectez avant de la corriger.
- Les bugs qui se cachent des développeurs sont ceux qui tournent dans le « mauvais » environnement. Le nôtre vivait dans
/Applicationssur chaque machine de dev, donc le bug était structurellement invisible pour nous tout en frappant les nouveaux utilisateurs. Quand un rapport ne se reproduit pas, la première question est qu’est-ce qui est différent dans l’endroit où ça tourne, pas l’utilisateur se trompe-t-il.
GeekBye v2.0.6 a livré l’invite de relocalisation et le diagnostic ensemble. Pour l’arc de fiabilité plus large dans lequel ça s’inscrit, voyez ce que coûte vraiment une version 2 (v2.0.0) et pourquoi l’enregistrement d’écran capture le mauvais moniteur (v2.0.10) — un autre bug qui ne surgissait que dans un environnement précis. Pour la version des petits détails d’à côté, logiciel serein : le correctif du scintillement et la puce du mode de réponse (v2.0.3 + v2.0.5).
