Les assistants IA veulent les droits de l'OS
Mise à jour : Apple reconnaît que Full Disk Access est trop large pour les agents
Apple vient de confirmer l'argument central de cet article.
Le 2 octobre, l'entreprise a publié une courte note pour les développeurs intitulée "Updates to Full Disk Access in macOS".
Quatre paragraphes.
Et une concession assez importante.
Apple explique que Full Disk Access a surtout été créé pour permettre aux apps de sauvegarde de fonctionner. Cette permission contourne une grande partie des contrôles habituels et ouvre l'accès aux données du Mac. Selon Apple, certains développeurs l'utilisent désormais d'une manière qui peut exposer fichiers, mails, messages et historique de navigation sans que l'utilisateur comprenne vraiment ce qu'il a autorisé.
Puis Apple nomme ce qui change l'échelle du risque :
Les agents.
À mesure que les logiciels gagnent en capacités et en autonomie, le risque augmente fortement, dit Apple. L'entreprise prévoit donc de modifier macOS pour que ce niveau d'accès ne puisse être accordé qu'à travers une action utilisateur "très explicite".
Très bien.
Mais c'est une direction, pas encore une architecture de sécurité.
Apple n'a annoncé ni la version de macOS concernée, ni la date du changement. On ne sait pas si l'accès deviendra plus granulaire, combien de temps une autorisation restera valide, ce que l'utilisateur pourra révoquer ou si les agents disposeront d'une nouvelle API pensée autour de tâches précises.
La vraie question n'est donc pas de savoir si le bouton sera plus difficile à cliquer.
C'est de savoir si Full Disk Access doit encore être la permission utilisée.
Une alerte plus effrayante ne suffit pas
Un consentement explicite vaut mieux qu'un consentement accidentel.
Mais cela ne résout pas le problème des agents.
Full Disk Access est une permission globale et permanente à l'échelle de l'app. Une fois accordée, elle peut survivre à la raison précise que l'utilisateur avait en tête. L'agent peut ensuite recevoir de nouveaux prompts, ouvrir de nouveaux outils, rencontrer du contenu hostile ou interpréter une instruction ambiguë d'une manière que personne n'avait anticipée au moment de cocher la case.
Le consentement donné à l'installation n'est pas un consentement à chaque décision future de l'agent.
Apple possède déjà un meilleur modèle ailleurs dans macOS. Pour les apps sandboxées, son système d'accès aux fichiers permet à l'utilisateur de choisir un fichier ou un dossier précis, puis d'accorder un accès en lecture seule ou en lecture-écriture à cette ressource.
C'est beaucoup plus proche de ce dont les agents ont besoin.
Pas :
"Faites confiance à cette app avec tout l'ordinateur."
Mais :
"Autorisez cet agent à lire ce dossier pour cette tâche, jusqu'à la fin de cette tâche."
La différence paraît petite.
C'est tout le produit.
Le plugin Messages devient le test évident
Le plugin Apple Messages décrit plus bas rend la tension très concrète.
OpenAI affirme qu'il fonctionne localement et demande par défaut une validation avant l'envoi. TechCrunch rapporte que sa configuration exige Full Disk Access. Rien de tout cela ne signifie qu'OpenAI a abusé de cette permission.
Cela signifie que le système d'exploitation a donné une clé très large à une fonctionnalité ciblée.
Reuters relie l'annonce d'Apple aux critiques visant l'accès de Muse, chez Meta, à des messages privés ; Meta conteste cette présentation. Pas besoin de trancher ce désaccord pour voir le problème de plateforme.
Si un assistant utile a besoin de l'une des permissions les plus larges du Mac pour rechercher dans Messages, le modèle de permissions porte plus de risque que la fonctionnalité ne l'exige réellement.
La note d'Apple soulève aussi un point moins discuté : les données d'une conversation appartiennent à plus d'une personne. Donner à un assistant accès à ses messages peut exposer les mots, les identités et le contexte de gens qui n'ont jamais vu la fenêtre de permission.
Le consentement de l'utilisateur compte.
Ce n'est pas la seule vie privée en jeu.
À quoi devraient ressembler les permissions des agents
Un modèle de permissions conçu pour les agents devrait être presque ennuyeux de précision.
- Ciblé par ressource : une conversation, un dossier, un calendrier ou un compte, pas tout le disque.
- Ciblé par action : lire et rechercher ne doivent pas automatiquement permettre d'écrire, d'envoyer, de supprimer ou de modifier des réglages.
- Demandé au bon moment : l'accès apparaît quand la tâche en a besoin, pas pendant l'installation alors que l'usage futur reste abstrait.
- Limité dans le temps : l'autorisation expire avec la tâche, la session ou une durée clairement annoncée.
- Attribuable : l'utilisateur voit quel agent, quel outil et quelle instruction ont provoqué l'accès.
- Traçable : un journal montre ce qui a été lu ou modifié, et pourquoi.
- Révocable : l'accès se retire facilement, sans désinstaller le produit ni fouiller plusieurs panneaux de réglages.
Et ces règles doivent s'appliquer à Apple comme aux acteurs tiers.
Ce dernier point compte parce que sécurité et concurrence sont désormais liées. Apple peut avoir entièrement raison de vouloir renforcer les contrôles autour des agents, tout en bénéficiant d'un système où ses concurrents dépendent des permissions qu'elle définit.
La réponse n'est pas de donner un accès universel à tout le monde.
C'est d'exposer un ensemble commun de capacités étroitement délimitées et bien journalisées, utilisées dans les mêmes conditions par Apple et les assistants concurrents.
La bataille européenne sur l'interopérabilité, analysée dans la version originale ci-dessous, devient plus claire sous cet angle. "Ouvrir la plateforme" ne devrait pas signifier distribuer un passe-partout à chaque assistant. Cela devrait signifier exposer les actions utiles du système à travers des permissions conçues pour la tâche réelle.
La vraie leçon
Full Disk Access est une permission de compatibilité très large, pensée pour des logiciels comme les outils de sauvegarde.
Ce n'est pas un modèle natif de capacités pour agents autonomes.
L'annonce d'Apple est bienvenue parce qu'elle reconnaît que l'autonomie change le niveau de risque. Une validation plus délibérée peut empêcher certains utilisateurs d'accorder cette permission dangereuse trop facilement.
Mais un clic plus difficile n'est qu'une transition.
Le système d'exploitation doit devenir l'intermédiaire entre l'intention de l'utilisateur et la prochaine action de l'agent.
L'agent devrait demander le fichier.
Pas l'ordinateur.
En bref
La guerre des assistants IA devient une guerre de système d'exploitation.
Pas un jour.
Maintenant.
Le 16 juillet, la Commission européenne a adopté des mesures juridiquement contraignantes sous le Digital Markets Act pour dire à Google comment ouvrir certaines parties d'Android et de Google Search à ses concurrents. Une partie concerne l'interopérabilité d'Android pour les assistants IA. L'autre concerne l'accès aux données de ranking, de requêtes, de clics et de vues issues de Google Search.
Cela ressemble à de la paperasse bruxelloise.
C'est en réalité une carte produit.
La Commission rappelle qu'Android est utilisé par plus de 60 % des utilisateurs mobiles dans l'UE. Elle dit que les services IA tiers ont besoin d'accéder à des fonctionnalités Android comme les commandes vocales, les actions dans et entre les apps, la traduction en direct, la transcription, les suggestions de réponse et des informations contextuelles comme un lieu récemment visité.
En clair :
Si Gemini peut vivre profondément dans Android, les concurrents ne doivent pas rester coincés éternellement au niveau d'une simple app.
C'est ça, l'histoire.
Les assistants IA ne sont pas seulement des chatbots avec une meilleure voix. Pour être utiles, ils ont besoin de privilèges système : wake words, notifications, intents d'apps, fichiers locaux, contexte d'écran, état du navigateur, calendriers, messages, cartes, paiements et capacité d'agir dans le téléphone sans donner l'impression d'être une page web enfermée dans un rectangle.
Le modèle compte.
L'OS décide ce que le modèle peut toucher.
Et dès que l'assistant peut toucher les choses, le propriétaire de la plateforme possède un pouvoir immense.
Futur très normal. Le réglage de l'assistant par défaut devient maintenant de la politique industrielle.
Mise à jour : Messages est le test des privilèges système
Un mois plus tard, OpenAI rend l'argument beaucoup moins abstrait.
Le 20 août, OpenAI a lancé un plugin Apple Messages pour l'app desktop ChatGPT sur macOS. Le plugin peut lire et rechercher des conversations Messages sur un Mac, préparer des réponses et envoyer des messages via l'app Messages d'Apple. Il fonctionne dans ChatGPT Work et Codex, et OpenAI dit qu'il est disponible sur tous les plans dans l'app desktop macOS.
Cela ressemble à une petite fonctionnalité.
Ce n'en est pas une.
Les messages ne sont pas une source de données comme une autre.
C'est le graphe social de l'utilisateur, ses plans, ses rappels, son contexte émotionnel, ses obligations, ses petits mensonges, ses vieux reçus, ses demi-décisions, ses blagues récurrentes, sa logistique et toute la mémoire du type "attends, qu'est-ce que je leur avais promis ?"
Un assistant qui peut rechercher dans les messages ne répond pas seulement à partir de documents.
Un assistant qui peut envoyer des messages n'écrit pas seulement du texte.
Il touche l'une des surfaces d'action les plus intimes de l'ordinateur.
C'est exactement ce que j'entendais par privilèges système.
Le modèle de permissions devient le produit
Le guide du plugin d'OpenAI est prudent sur la frontière.
Le plugin Apple Messages fonctionne seulement dans Codex et ChatGPT Work, pas dans les conversations ChatGPT ordinaires. Pour cette version, il ne fonctionne que dans le build Apple Silicon de l'app desktop macOS, et il n'est pas disponible sur le web, mobile, Codex CLI ou l'extension IDE. L'utilisateur doit accorder les permissions macOS demandées avant que ChatGPT puisse lire Messages. Par défaut, ChatGPT demande de relire le message et les destinataires avant l'envoi.
Très bien.
Mais regardez tout ce qui se cache comme design produit dans ce paragraphe.
Quelle surface peut utiliser le plugin ?
Quelle architecture de machine ?
Quelles permissions macOS ?
Quel mode de chat ?
Quelles validations avant envoi ?
Un administrateur workspace peut-il le désactiver ?
Que se passe-t-il quand l'approbation persistante est activée ?
Le guide d'OpenAI prévient que l'approbation persistante retire à l'utilisateur sa dernière chance de relire avant que ChatGPT envoie un message en son nom. Il note aussi un problème connu : les tâches qui désactivent les demandes d'approbation peuvent empêcher Messages d'afficher la confirmation nécessaire à l'envoi.
C'est ça, l'histoire.
Pas "l'IA peut envoyer des textos".
"L'utilité de l'assistant dépend d'un modèle d'approbation assez fragile pour que la documentation doive expliquer où il casse."
Ce n'est pas une critique. C'est la forme réelle des produits agentiques.
Dès que l'assistant peut agir dans un logiciel personnel, le produit n'est plus seulement le modèle ou la boîte de prompt. C'est la frontière de permission, le chemin de révocation, le contrôle admin, la règle local-versus-cloud et le dernier checkpoint humain avant que le message parte de votre machine.
TechCrunch rapporte qu'OpenAI affirme que le plugin ne crée pas d'index complet des messages, tourne localement sur l'appareil et stocke le contenu des messages localement sauf si l'utilisateur choisit le stockage cloud de la conversation. Le même article note aussi que la configuration demande Full Disk Access.
Le compromis tient en une phrase :
Pour rendre un assistant utile, on lui donne une permission terriblement utile.
Apple a toujours la version la plus facile
Le plus drôle, c'est que c'est aussi une histoire Apple.
OpenAI peut s'intégrer à Messages sur Mac en passant par les permissions et les chemins d'automatisation exposés par macOS. C'est important. Cela donne à ChatGPT une route vers une surface de communication native d'Apple sans devenir Siri.
Mais ce n'est toujours pas la même chose que posséder l'OS.
Cela ne fonctionne pas sur iPhone, là où la plupart des gens vivent réellement dans Messages. Cela ne devient pas l'assistant par défaut. Cela ne peut pas redessiner le modèle de permissions du système. Cela ne peut pas décider comment chaque app expose ses intents. Cela ne peut pas se tenir tranquillement à côté de chaque notification sauf si la plateforme l'autorise.
Le plugin prouve donc les deux côtés de la guerre des assistants.
Les assistants concurrents peuvent parfois atteindre des surfaces profondes grâce à des plugins, des permissions et de l'automatisation desktop.
Les propriétaires de plateformes décident encore où se trouvent les surfaces les plus profondes, à quel point elles sont stables et si elles existent sur les appareils qui comptent vraiment.
C'est pour cela que la guerre des assistants finit toujours par devenir une guerre d'OS.
La qualité du modèle vous donne le brouillon.
L'accès au système d'exploitation décide si vous pouvez l'envoyer.
Ce que l'Europe force vraiment
La Commission ne dit pas "ouvrez Android, mais dans l'esprit".
Elle précise des catégories d'accès.
Pour Android, Google doit donner aux services IA tiers une interopérabilité effective avec des fonctionnalités clés. La FAQ de la Commission parle de onze fonctionnalités, dont les commandes vocales, les actions dans et entre les apps, la traduction en direct, la transcription et les suggestions contextuelles.
Ce ne sont pas des détails décoratifs.
C'est la différence entre :
"Ouvre cette app et demande au chatbot."
Et :
"Assistant, réponds à ce message, réserve le trajet, traduis l'appel, résume ce que je regarde et fais l'étape suivante dans l'app déjà ouverte."
C'est cette deuxième version que les gens veulent vraiment.
La partie Search compte aussi. La Commission dit que Google doit donner aux services de recherche éligibles, y compris les chatbots IA, accès à certaines données de ranking, de requêtes, de clics et de vues. L'idée est de permettre aux concurrents d'améliorer leurs propres produits de recherche et de recherche IA sans devoir recréer l'avantage comportemental de Google depuis zéro.
C'est énorme.
Les données de recherche ne sont pas seulement un ancien actif d'internet.
Ce sont des signaux d'entraînement, de ranking, d'intention, de fraîcheur et de distribution produit. Dans un monde d'assistants IA, la recherche ressemble moins à une page de liens et plus à un substrat de tâches. L'assistant doit savoir ce que les gens demandent, ce qu'ils cliquent, ce qu'ils ignorent et quelles réponses les aident réellement.
Pas étonnant que Google soit mécontent.
Dans sa réponse, Google affirme que ces décisions menacent la vie privée, la sécurité et la qualité produit. L'entreprise dit que le partage forcé de données et l'interopérabilité peuvent exposer les utilisateurs à de nouveaux risques et affaiblir les garde-fous.
Une partie de cet argument est intéressée.
Une partie est aussi vraie.
Ouvrir un accès agentique au téléphone, ce n'est pas comme ouvrir une API météo.
C'est plutôt décider qui reçoit les clés du bâtiment.
L'assistant n'est plus une app
C'est le changement mental.
La plupart des entreprises IA parlent encore comme si l'assistant était une destination.
Ouvrez ChatGPT.
Ouvrez Claude.
Ouvrez Gemini.
Posez la question.
C'est utile, mais ce n'est pas la fin du jeu.
La fin du jeu, c'est l'assistant comme couche au-dessus de la vie numérique de l'utilisateur.
Cela veut dire que l'assistant doit agir là où l'utilisateur se trouve déjà. Il doit comprendre le message à l'écran, la page dans le navigateur, le rendez-vous dans le calendrier, l'itinéraire dans Maps, la photo qui vient d'être prise, l'app active, le fichier en cours d'édition et la notification arrivée il y a trente secondes.
Une app peut demander des permissions.
Un système d'exploitation peut orchestrer le contexte.
C'est pour ça que Google et Apple ont un avantage.
Gemini peut devenir une partie d'Android. Siri peut devenir une partie d'iOS. Microsoft peut pousser Copilot dans Windows. Google peut relier Gemini à Search, Chrome, Android, Gmail, Docs, Maps et YouTube. Apple peut relier Siri au contexte local de l'appareil, aux contrôles de confidentialité, aux capteurs et aux intents d'apps.
Un assistant concurrent peut être plus intelligent et quand même sembler moins bon s'il n'atteint pas la bonne surface au bon moment.
C'est la vérité produit inconfortable.
La qualité du modèle vous fait entrer dans la conversation.
L'accès à l'OS vous permet de faire le travail.
Apple est l'histoire en arrière-plan
La décision contre Google arrive à un moment gênant parce qu'Apple dit quelque chose de similaire depuis l'autre côté.
Apple affirme que certaines nouvelles fonctionnalités Siri IA ne seront pas lancées immédiatement dans l'UE à cause des inquiétudes liées au DMA. L'entreprise soutient que les exigences d'interopérabilité pourraient l'obliger à compromettre la vie privée et la sécurité.
Là aussi, il y a de la stratégie dans la réponse.
Apple ne veut pas que les régulateurs lui disent comment exposer des capacités profondes d'iOS.
Mais la tension est réelle.
Un assistant capable de lire votre écran, d'agir dans les apps, de comprendre le contexte personnel et de passer d'un service à l'autre est puissant parce qu'il est intime. Le même accès qui le rend utile devient dangereux si le mauvais acteur l'obtient, si les permissions sont floues, si les logs sont faibles ou si le modèle suit la mauvaise instruction.
C'est exactement pour ça que l'histoire GPT-Red compte, mais depuis un autre angle.
Cet article parlait de tester les agents avant qu'internet ne les attaque.
Celui-ci demande où ces agents ont le droit de vivre.
Plus l'assistant descend profondément dans l'OS, plus le modèle de sécurité devient le produit.
L'Europe dit en substance :
"Vous ne pouvez pas réserver éternellement les hooks utiles à votre propre assistant."
Google et Apple disent en substance :
"Si vous nous forcez à ouvrir ces hooks, il faudra accepter les conséquences sécurité."
Les deux camps ont un point.
Énervant, mais vrai.
Ce n'est pas seulement Google Search
Il est tentant de traiter la partie données Search comme une vieille bataille antitrust avec un peu d'IA par-dessus.
Ce serait rater le déplacement.
Les données de recherche deviennent du carburant pour assistants.
Si un assistant IA doit répondre aux questions, recommander des actions, comparer des produits, résumer l'actualité, orienter les utilisateurs vers des services et peut-être accomplir directement des tâches, alors la recherche n'est plus seulement une page de résultats.
La recherche devient l'un des sens de l'assistant.
L'avantage de Google n'est pas seulement d'avoir un moteur de recherche. C'est d'avoir des décennies de comportements de requêtes, de feedback de ranking, de signaux de fraîcheur, de connaissance du spam, d'intention locale, de patterns d'achat et l'habitude de milliards d'utilisateurs qui demandent d'abord à Google.
Les concurrents de la recherche IA veulent ce signal.
Les régulateurs voient ce signal comme un fossé.
Google voit ce signal comme son produit, son obligation de confidentialité et son avantage concurrentiel.
Les trois peuvent être vrais.
Le problème, c'est que "partager les données de recherche" paraît simple jusqu'à ce qu'on demande :
- Quelles données ?
- Avec quelle fraîcheur ?
- À quelle granularité ?
- Avec quelle anonymisation ?
- Pour quels concurrents ?
- Sous quelles règles de sécurité ?
- Les données peuvent-elles servir à entraîner des modèles ?
- Google peut-il protéger les utilisateurs contre la réidentification ?
- Les concurrents peuvent-ils construire quelque chose d'utile si les données sont trop agrégées ?
Ce n'est pas une jolie histoire d'open data.
C'est le début désordonné de la régulation de l'infrastructure de recherche IA.
Très reposant.
Le propriétaire de la plateforme a l'agent le plus facile
La façon la plus simple de comprendre le conflit est celle-ci :
Le meilleur assistant IA est probablement celui qui est le plus proche du vrai contexte de l'utilisateur.
Cela crée un problème de propriétaire de plateforme.
Si Google contrôle Android, Google peut rendre Gemini natif. Si Apple contrôle iOS, Apple peut rendre Siri natif. Si Microsoft contrôle Windows, Microsoft peut rendre Copilot natif. Tous les autres doivent demander la permission.
Cette permission peut être technique.
Elle peut être commerciale.
Elle peut être enterrée dans des APIs.
Elle peut être façonnée par les règles de confidentialité, la revue d'app store, les limites d'exécution en arrière-plan, les choix de navigateur par défaut, les politiques de notifications, l'accès aux fichiers, les APIs de modèles locaux, l'invocation vocale et mille petites décisions qui ne ressemblent jamais à de la "concurrence IA" jusqu'au moment où l'assistant ne peut pas faire la chose.
C'est là que la régulation devient du design produit.
Le DMA n'entraîne pas un modèle.
Il décide quel modèle peut se tenir près du système nerveux numérique de l'utilisateur.
C'est pour ça que cette histoire compte plus qu'une bataille de plateforme classique.
Si les agents deviennent l'interface, les défauts de plateforme deviennent les défauts d'agents.
Et les défauts d'agents vont valoir très cher.
Ce que les builders devraient en retenir
Si vous construisez un assistant, ne pensez pas seulement en capacité de modèle.
Pensez en surfaces atteignables.
Votre assistant peut-il être invoqué au bon moment ?
Peut-il voir le bon contexte ?
Peut-il agir dans la bonne app ?
Peut-il expliquer quelle permission il demande ?
Peut-il fonctionner sans demander tout le téléphone ?
Peut-il lire un fil sans indexer une vie ?
Peut-il envoyer un message sans faire de "toujours autoriser" le chemin paresseux ?
L'utilisateur peut-il révoquer l'accès proprement ?
Un administrateur peut-il désactiver la surface risquée sans casser le reste du workflow ?
Une autre app peut-elle faire confiance à son action ?
Un régulateur peut-il comprendre le contrôle ?
Ces questions font maintenant partie du produit.
Si vous possédez une plateforme, la leçon est plus dure :
Vos APIs d'assistant IA ne sont pas seulement des fonctionnalités développeur.
Elles sont à la fois politique de concurrence, architecture de sécurité et stratégie de distribution.
C'est une combinaison horrible.
C'est aussi le vrai travail.
La prochaine guerre des assistants ne sera pas gagnée seulement par le modèle qui répond le mieux dans un chat vide.
Elle sera gagnée par le système qui peut se tenir le plus près possible de la vraie vie de l'utilisateur, sans la casser.
L'Europe vient de rappeler à Google que "le plus près" n'est pas censé vouloir dire "seulement nous".
Le reste de l'industrie devrait regarder.
L'assistant IA devient l'invité le plus important du système d'exploitation.
Et apparemment, les invités ont maintenant besoin d'une architecture réglementaire.