Google Android App Functions a construit une cage de sécurité, mais la plupart des agents IA restent à l’extérieur

Google a conçu pour les agents Android un accès contrôlé aux autres applications, mais la plupart des utilisateurs ne peuvent toujours ni voir, ni gérer, ni utiliser réellement cette voie. Google Android App Functions définit désormais comment des assistants approuvés peuvent découvrir et exécuter des actions précises entre applications. Le paradoxe tient au fait que l’architecture de sécurité est arrivée avant l’émergence d’un vaste écosystème d’agents.

Il ne s’agit pas d’une énième fonctionnalité Android inachevée. Google décide quels acteurs peuvent agir au sein des applications, ce qu’ils peuvent découvrir et quelles opérations les développeurs choisissent d’exposer. Ces choix établissent le plan de contrôle des futurs agents capables de créer des notes, retrouver des photos, lancer des médias ou composer des paniers d’achat.

Ils distinguent aussi l’approche de Google des agents qui pilotent les téléphones en interprétant les écrans et en imitant les pressions. Les systèmes pilotés par l’écran peuvent fonctionner sans intégration profonde aux applications, mais restent vulnérables aux changements de mise en page et aux contenus trompeurs. App Functions propose une voie plus propre, même si seuls des agents approuvés et des applications participantes peuvent l’utiliser.

Google a déjà démontré des intégrations limitées, notamment Gemini récupérant des photos via Samsung Gallery. Android 17 étend davantage le cadre. Pourtant, le propriétaire type d’un appareil Android ne trouvera pas un tableau de bord universel d’agents rempli d’assistants tiers et d’actions compatibles.

Cet écart explique la contradiction apparente. La cage n’est pas littéralement vide, mais sa population demeure restreinte, contrôlée et difficile à inspecter pour les utilisateurs ordinaires. Google a sécurisé l’entrée avant d’ouvrir le marché qui l’entoure.

Google Android App Functions a changé la façon dont les agents accèdent aux applications

App Functions remplace le contrôle simulé de l’écran par des opérations déclarées et structurées qu’Android peut identifier et restreindre.

Une fonction d’application est une action distincte qu’une application met à la disposition d’un appelant approuvé. Une application de notes pourrait exposer « créer une note », tandis qu’une application multimédia pourrait proposer « lire une chanson ». L’agent envoie des paramètres structurés au lieu de naviguer dans l’interface visible de l’application.

Le framework App Functions officiel décrit deux parties. Une application fournisseur déclare une action, et un agent de confiance la découvre puis l’exécute. Android assure la médiation de l’échange via AppFunctionManager et des services associés.

Cette architecture est importante parce qu’une interface visuelle a été conçue pour le jugement humain. Une personne remarque qu’un bouton a changé de place, qu’un destinataire semble incorrect ou qu’un total d’achat a été modifié. Un système automatisé peut poursuivre son action après avoir mal interprété l’écran ou suivi des instructions hostiles intégrées au contenu affiché.

Les fonctions structurées limitent l’action disponible. L’agent ne reçoit pas un contrôle illimité simplement parce qu’il peut demander à une application d’effectuer une opération. Le fournisseur définit la fonction, ses entrées et le résultat qu’elle renvoie.

Android suit également l’état d’activation d’une fonction. Une demande d’exécution peut échouer si la fonction n’existe pas, est introuvable ou n’est pas disponible. Cela crée une limite plus claire que d’accorder à un agent un accès général à l’interface de l’application.

Le framework est arrivé dans la plateforme au niveau d’API 36, la version associée à Android 16. La documentation de Google continue de présenter App Functions comme une version bêta ou un aperçu expérimental. Android 17 ajoute l’enregistrement à l’exécution, des fonctions limitées à une activité, des niveaux d’accès mis à jour et des contrôles de découverte plus détaillés.

Ces changements montrent que Google traite l’action inter-applications des agents comme une préoccupation du système d’exploitation. L’entreprise ne laisse pas chaque développeur d’assistant inventer une couche d’intégration privée. La plateforme fournit des identifiants communs, des métadonnées, la gestion de l’état, des requêtes, des réponses et des vérifications d’autorisation.

La distinction devient plus claire dans un simple scénario de prise de notes. Un agent reçoit l’instruction : « Enregistre l’adresse de l’hôtel dans mes notes de voyage. » Il cherche une fonction compatible, identifie l’application cible, fournit le titre et le contenu, puis reçoit un résultat.

Un agent piloté par l’écran devrait plutôt ouvrir l’application, localiser un bouton, choisir un carnet, sélectionner un champ de texte, saisir le contenu et appuyer sur enregistrer. Chaque transition visuelle ajoute un point où l’ambiguïté ou la manipulation peut s’introduire dans la séquence.

App Functions ne garantit pas qu’un agent a correctement compris la demande initiale. Il ne prouve pas non plus qu’une application a implémenté son action de manière sûre. Il réduit la surface d’attaque en remplaçant un parcours ouvert dans l’interface par une opération explicitement déclarée par les développeurs.

C’est le premier changement important. Android dispose désormais d’un vocabulaire natif pour les agents agissant au sein des applications, plutôt que de simplement parler de ces applications ou d’ouvrir leurs écrans.

Le second changement est moins visible. Android place l’exécution inter-applications derrière des autorisations que les applications ordinaires ne peuvent pas simplement présumer obtenir. Cette décision transforme App Functions, d’une API pratique, en système de contrôle d’accès.

Le modèle d’autorisation place Google et les fabricants d’appareils aux commandes

L’avantage en matière de sécurité vient de la limitation des appelants capables d’agir, mais cette même restriction maintient les agents Android indépendants hors de la porte.

Une application peut exécuter ses propres fonctions sans autorisation spéciale. L’exécution entre packages est différente. AppFunctionManager exige que l’agent appelant détienne une autorisation Android l’autorisant à découvrir ou exécuter des fonctions dans d’autres applications.

Les premiers travaux sur le framework Android attribuaient EXECUTE_APP_FUNCTIONS aux applications préinstallées ou système détenant le rôle d’assistant. Une autorisation de confiance associée était destinée à des composants d’intelligence système étroitement contrôlés. L’historique des autorisations montre à quel point Android a explicitement lié l’exécution des agents à des rôles privilégiés.

Le framework actuel évolue vers des niveaux d’accès plus granulaires. Les développeurs peuvent réserver des fonctions à l’application elle-même, aux appelants système ou aux appelants certifiés par Android. Toutefois, la certification n’équivaut pas à une autorisation d’exécution ordinaire qu’un assistant téléchargé peut recevoir après l’affichage d’une demande.

Cette distinction explique pourquoi la fonctionnalité semble absente sur un téléphone normal. Les utilisateurs ont l’habitude d’approuver l’accès à l’appareil photo, au microphone, aux contacts et à la localisation. Ils ne peuvent pas nécessairement installer un assistant arbitraire et lui accorder une vaste autorité sur App Functions depuis un écran de réglages standard.

Google évite une dangereuse course vers le bas. Si n’importe quelle application pouvait appeler chaque fonction exposée après une vague demande de consentement, les assistants agressifs chercheraient à obtenir des autorisations étendues. Les utilisateurs pourraient les approuver sans comprendre combien d’actions importantes deviennent alors accessibles.

Les agents inter-applications présentent un risque différent des chatbots passifs. Une réponse erronée est gênante. Une action erronée peut envoyer un message à la mauvaise personne, divulguer un document privé, modifier un dossier ou initier une transaction.

L’injection de prompt rend cette distinction plus nette. Un agent peut rencontrer du texte conçu pour supplanter l’intention de l’utilisateur en lisant une page web, un message, un document ou une image. De récentes recherches sur les agents mobiles examinent précisément comment les agents Android pilotés par l’accessibilité peuvent être exposés à des injections indirectes de prompt.

Une limite d’autorisation ne peut pas rendre le modèle insensible à la manipulation. Elle peut limiter les applications qui agissent comme agents et les fonctions auxquelles ces agents accèdent. Elle fournit aussi aux applications fournisseurs un chemin d’exécution défini, dans lequel elles peuvent valider les arguments et appliquer leurs propres contrôles.

Pourtant, le contrôle centralisé crée un autre problème. Google et les fabricants d’appareils Android deviennent les arbitres de fait des assistants qui bénéficient d’un accès de premier plan. Un agent indépendant peut élaborer un planificateur sophistiqué tout en n’ayant pas l’autorisation d’orchestrer des applications tierces via le framework officiel.

Cette pression affecte trois groupes.

Premièrement, les développeurs d’assistants doivent être admissibles à la voie de confiance d’Android ou s’appuyer sur des techniques moins directes. Ils peuvent créer des liens profonds vers les applications, utiliser des intents existants, opérer via des services d’accessibilité ou simuler des interactions à l’aide d’outils de développement. Aucune de ces méthodes n’offre le même accès standardisé.

Deuxièmement, les développeurs d’applications doivent décider quelles fonctions méritent d’être exposées. Chaque fonction exige de l’implémentation, des tests, une validation des entrées, une gestion du cycle de vie et un travail de compatibilité. Une petite équipe peut hésiter tant qu’un nombre suffisant d’utilisateurs ne possède pas un agent capable d’appeler ces fonctions.

Troisièmement, les utilisateurs doivent faire confiance aux deux parties de la transaction. Ils doivent avoir la certitude que l’assistant a interprété correctement la demande et que l’application fournisseur n’exécutera pas une opération d’une ampleur inattendue.

Cela produit un démarrage à froid classique de plateforme. Les agents ont besoin de fonctions utiles avant d’attirer des utilisateurs. Les développeurs d’applications ont besoin d’agents actifs avant qu’une intégration mérite du temps d’ingénierie. Google peut rompre ce cycle avec Gemini et des partenaires de premier plan, mais les participants indépendants restent dépendants de ses politiques d’accès.

La conception est donc à la fois une cage de sécurité et une porte de distribution. Restreindre l’exécution réduit les abus immédiats, tandis que la certification et les privilèges de plateforme façonnent ceux qui peuvent créer une automatisation Android significative.

La conception axée sur la sécurité de Google se heurte à un problème d’adoption

Le compromis central est simple : un contrôle plus strict rend les agents Android plus sûrs à déployer, tandis qu’un accès plus lent rend le framework moins utile aujourd’hui.

Google a publiquement fait sortir App Functions du domaine des références d’API obscures en février 2026. Son équipe de développeurs Android a qualifié ces capacités de naissantes et présenté la confidentialité ainsi que la sécurité comme des priorités fondamentales de conception.

L’entreprise a également présenté un déploiement concret. Gemini pouvait interpréter une demande, déclencher une App Function dans Samsung Gallery et renvoyer des photos sélectionnées dans l’interface Gemini. Selon l’intégration Samsung, cette expérience a débuté sur la gamme Galaxy S26, avec une extension prévue vers davantage d’appareils Samsung.

Cet exemple prouve que le framework n’est pas une coquille de code vide. Il révèle aussi combien le déploiement reste limité. La démonstration implique l’assistant de Google, un grand fabricant Android, une application galerie propriétaire et certains appareils sélectionnés.

Un vaste écosystème aurait une autre apparence. Les utilisateurs pourraient choisir parmi des agents qualifiés. Des milliers d’applications exposeraient des opérations documentées. Android indiquerait quel agent a appelé quelle fonction, quelles données ont circulé et quelles actions nécessitent une confirmation.

Le framework existant fournit plusieurs éléments de cet avenir, mais pas encore toute son expérience publique. Les développeurs peuvent définir des métadonnées, publier des fonctions, observer l’état et traiter les demandes d’exécution. Android 17 introduit aussi un enregistrement plus dynamique et des comportements spécifiques aux activités.

La mise à jour Android 17 de Google inclut une application d’agent de test et des commandes ADB destinées au développement. ADB, ou Android Debug Bridge, est une interface de développeur permettant de contrôler et d’inspecter des appareils. Ces outils aident les programmeurs à valider des fonctions avant que les agents grand public ne les prennent largement en charge.

La prise en charge des tests est nécessaire, mais elle ne vaut pas adoption. Un développeur peut prouver que « créer une note » renvoie la réponse attendue sans savoir combien de véritables assistants l’invoqueront. Une fonction compatible peut rester inactive sur des millions d’appareils.

Le cadre nécessite également des schémas partagés. Deux applications de prise de notes peuvent exposer des actions similaires sous des noms, avec des arguments et des formats de résultats différents. Si chaque fournisseur invente son propre contrat, les agents doivent comprendre une collection grandissante d’interfaces propriétaires.

Des schémas standard permettent aux agents de rechercher par capacité plutôt que de mémoriser chaque application. Le modèle de métadonnées d’Android prend en charge les informations de schéma, mais une interopérabilité réellement utile dépend toujours de définitions cohérentes adoptées par les développeurs.

Le contrôle utilisateur constitue une autre couche non résolue. Une application peut maintenir l’état activé de ses fonctions, et des métadonnées plus récentes peuvent exprimer différents niveaux d’accès. Cependant, les utilisateurs ordinaires ont besoin d’un modèle compréhensible qui réponde à des questions pratiques.

Gemini peut-il créer des notes sans pouvoir les supprimer ? Un autre agent certifié peut-il rechercher des photos sans les partager à l’extérieur ? L’approbation s’applique-t-elle une seule fois, par application, par fonction ou par demande sensible ? Un utilisateur peut-il consulter l’historique des actions après qu’un problème est survenu ?

Google doit équilibrer ces contrôles avec la friction qu’ils génèrent. Confirmer chaque action inoffensive annule la commodité d’un agent. Approuver de larges catégories peut masquer les risques. Un système utile doit permettre aux opérations courantes de se dérouler rapidement tout en s’arrêtant avant les étapes irréversibles ou sensibles.

Ce problème rappelle la conception des autorisations, mais l’intention de l’agent évolue au cours d’une tâche. Une autorisation d’accès à l’appareil photo donne accès à un capteur connu. Un agent peut commencer par lire une liste, déduire plusieurs sous-tâches, consulter plusieurs applications et proposer un achat. La limite déterminante apparaît au milieu du flux de travail.

La politique devient donc plus importante qu’une autorisation unique. Android doit combiner l’identité de l’appelant, le périmètre de la fonction, les règles du fournisseur, les préférences de l’utilisateur, la sensibilité de la transaction et le contexte actuel.

La métaphore de la cage ne saisit qu’une partie de cette conception. Android n’isole pas un processus non fiable dans une boîte. Il coordonne des appelants de confiance via des portes étroitement exposées, chaque application conservant la responsabilité de ce qui se passe derrière sa porte.

Pour les développeurs, le calcul immédiat reste incertain. Prendre en charge Google Android App Functions donne à une application une place dans les futurs flux de travail des agents. Cela implique aussi d’investir dans une interface bêta dont la distribution, la certification et la demande des utilisateurs évoluent encore.

Les agents pilotant l’écran sont plus rapides à lancer et plus difficiles à faire confiance

Le principal adversaire de Google n’est pas une autre plateforme mobile ; c’est le raccourci qui consiste à laisser les agents utiliser les écrans comme des humains.

Un agent pilotant l’écran peut démarrer avec moins de partenariats. Il lit des pixels ou une arborescence d’accessibilité, décide où interagir, puis génère des appuis, des balayages et des saisies de texte. Si un humain peut accomplir une tâche via l’interface, l’agent peut tenter de suivre le même chemin.

Cette généralité est séduisante. Les développeurs n’ont pas besoin que chaque application ciblée publie une fonction. Les chercheurs peuvent tester des agents sur des logiciels existants, et les startups peuvent démontrer une large couverture avant de négocier des intégrations.

Les propres recherches de Google sur Android ont contribué à établir cette approche. Le jeu de données Android in the Wild contient 715 000 épisodes couvrant 30 000 instructions sur plusieurs versions d’Android et types d’appareils. Il reflète l’ampleur nécessaire pour entraîner ou évaluer des systèmes qui agissent à travers des interfaces variées.

Cependant, un contrôle visuel étendu échange des contrats explicites contre de l’inférence. L’agent doit déterminer ce que signifie chaque écran, si le contenu est fiable et si une interaction a produit le résultat attendu.

Le libellé d’un bouton peut changer après une mise à jour de l’application. Une boîte de dialogue peut recouvrir la cible attendue. Une page malveillante peut placer des instructions là où le modèle les lira. Un parcours de paiement peut ajouter des frais ou modifier un article avant la confirmation finale.

Les humains commettent aussi des erreurs dans ces situations, mais les agents peuvent les répéter plus vite et à plus grande échelle. Ils peuvent fonctionner en arrière-plan, poursuivre leurs actions entre les applications et traiter des informations que l’utilisateur ne consulte jamais directement.

App Functions déplace l’interprétation vers une autre couche. L’agent interprète toujours la demande de l’utilisateur, mais il n’a pas besoin de déduire le fonctionnement de chaque écran. Il sélectionne une opération déclarée et fournit des informations typées.

Cela ressemble à la différence entre utiliser une interface de programmation d’application et automatiser un site web au moyen d’un navigateur. Les API offrent généralement une plus grande stabilité et des entrées plus claires. L’automatisation par navigateur atteint des services sans API, mais elle doit gérer les changements de mise en page, de session et de contenu.

La voie structurée améliore également la responsabilité. Android peut identifier le package appelant, la fonction cible, la demande et le résultat. Les applications fournisseurs peuvent rejeter des arguments non valides ou exiger leur propre confirmation. La politique de la plateforme peut traiter les fonctions sensibles différemment des fonctions ordinaires.

Rien de cela n’élimine le besoin de défenses au niveau du modèle. Un agent compromis peut appeler une fonction autorisée pour de mauvaises raisons. Un fournisseur négligent peut exposer une opération avec une validation insuffisante. Un appelant de confiance peut toujours mal interpréter des instructions ambiguës.

Les opérations structurées peuvent également rendre les actions nuisibles plus fiables. Un agent malveillant qui atteint une fonction « envoyer un paiement » n’a pas besoin de naviguer dans une interface déroutante. La valeur de sécurité dépend de la limitation de l’accès, de la vérification de l’intention et de l’exigence d’une confirmation au bon moment.

C’est pourquoi ouvrir EXECUTE_APP_FUNCTIONS trop largement effacerait une grande partie du bénéfice architectural. Google ne peut pas simplement placer l’autorisation dans une boîte de dialogue standard et considérer le problème comme résolu. La plateforme a besoin de règles de qualification et de comportements observables que les utilisateurs peuvent comprendre.

Dans le même temps, maintenir un accès limité crée une pression en faveur de l’automatisation d’écran. Les assistants indépendants emprunteront la voie qui leur permet de lancer leur produit. Si la porte officielle reste inaccessible, certains développeurs reviendront aux services d’accessibilité, aux outils basés sur ADB ou à l’automatisation d’appareils.

Le résultat est un paradoxe politique. Google veut que les agents utilisent le chemin structuré plus sûr, mais il doit rendre ce chemin suffisamment accessible pour évincer des alternatives plus risquées.

Les concurrents et les projets open source peuvent exploiter cette lacune en proposant des agents qui semblent plus capables dans les applications existantes. Leurs démonstrations peuvent couvrir davantage de tâches parce qu’ils n’attendent pas l’intégration des fournisseurs. Le système de Google peut paraître contraint précisément parce qu’il impose des limites.

Les consommateurs n’évalueront pas ces architectures à travers la documentation des API. Ils remarqueront si un agent peut accomplir une demande. Si un rival pilotant l’écran gère dix applications alors que la voie structurée de Gemini n’en prend en charge que deux, la capacité peut l’emporter sur une sécurité abstraite dans la décision d’achat.

Les développeurs font face à la même tension lorsqu’ils conçoivent des flux de travail IA. Une automatisation fiable dépend d’entrées prévisibles, d’actions contrôlées et de points de vérification visibles. Le contrôle général de l’interface offre une portée étendue, tandis que les fonctions structurées offrent des garanties plus claires.

Google doit combler cet écart de capacités sans transformer les agents Android en télécommandes sans restriction. App Functions fournit le mécanisme, mais l’adoption et la politique d’accès déterminent si les développeurs l’utiliseront réellement.

Le véritable test consiste à savoir si la cage devient une place de marché

La prochaine phase dépendra de la participation des applications, de l’accès des agents et d’un contrôle visible pour les utilisateurs, plutôt que de nouvelles classes de framework.

Le premier signal à surveiller est le nombre et la diversité des applications de production exposant des App Functions. Samsung Gallery est une démonstration utile, car la récupération de photos implique des données personnelles et une tâche utilisateur identifiable. Cela n’établit pas une prise en charge étendue dans la communication, la productivité, la finance, les achats, les voyages et les médias.

Les principales applications doivent exposer davantage que des actions de démonstration promotionnelles. Des flux de travail répétés et pratiques montreront si le framework fait réellement économiser aux utilisateurs un effort significatif. Créer une note, localiser une photo précise, lancer une playlist et ajouter des articles à un panier constituent les premiers tests.

L’adoption renforce l’approche de Google si plusieurs développeurs d’applications indépendants annoncent des intégrations fonctionnelles. Elle l’affaiblit si la prise en charge reste concentrée parmi les logiciels de Google, les applications des fabricants d’appareils et certains partenaires de lancement sélectionnés.

Le deuxième signal est l’accès pour les agents non-Google. Les métadonnées plus récentes d’Android font référence à des appelants certifiés par Android, ce qui suggère une voie plus large qu’un seul assistant propriétaire. La question décisive est de savoir ce que requiert la certification et si des agents tiers qualifiés peuvent concourir dans des conditions raisonnables.

Un programme crédible a besoin de critères publiés, d’obligations de sécurité, de procédures de révocation et d’un examen prévisible. Les développeurs doivent savoir comment un agent obtient l’accès et quel comportement lui fait perdre cet accès.

Sans ces précisions, le système d’autorisations risque de devenir un avantage de distribution privé pour Gemini. Google peut soutenir qu’un accès strict protège les utilisateurs, tandis que ses rivaux peuvent affirmer que les mêmes règles protègent la position de Google en tant qu’agent par défaut d’Android.

La preuve de l’existence de plusieurs agents certifiés renforcerait l’interprétation privilégiant la sécurité. Une exclusivité persistante du premier parti renforcerait l’interprétation de contrôle de l’accès. La légitimité du framework dépend de sa capacité à distinguer les exigences de confiance de l’accès préférentiel.

Le troisième signal est une expérience de contrôle et d’audit destinée aux utilisateurs. Le déploiement plus large de Gemini Intelligence par Google promet une automatisation proactive sur les téléphones et d’autres appareils. Davantage d’actions en arrière-plan rendent la visibilité de plus en plus importante.

Les utilisateurs doivent voir quelles fonctions existent, quels agents peuvent les appeler et quelles autorisations restent actives. Ils ont également besoin d’un historique qui explique ce qu’un agent a demandé et ce que chaque application a renvoyé.

Une interface de contrôle utile devrait distinguer la commodité à faible risque de l’autorité aux conséquences importantes. Lire une chanson ne mérite pas la même friction qu’envoyer un message ou soumettre une commande. La plateforme devrait communiquer cette différence avant qu’une erreur ne survienne.

La conception des confirmations sera la partie la plus difficile. Trop d’invites conditionnent les utilisateurs à tout approuver. Trop peu d’invites les laissent surpris par des actions qu’ils n’avaient pas l’intention d’effectuer. Les approbations contextuelles doivent rester claires sans transformer chaque flux de travail en une succession d’interruptions.

Google devrait également expliquer où le traitement a lieu. Certaines fonctions peuvent s’exécuter sur l’état local de l’application, tandis que le raisonnement de l’assistant peut impliquer des services cloud. Les utilisateurs doivent comprendre à quel moment leurs données quittent l’appareil et quelle partie les reçoit.

Les contrôles d’état du framework pourraient prendre en charge une révocation d’urgence. Si un agent se comporte de manière inattendue, les utilisateurs devraient pouvoir désactiver son autorité inter-applications sans devoir chercher dans chaque application. Les applications fournisseurs devraient également pouvoir suspendre rapidement les fonctions sensibles.

Les développeurs rechercheront aussi des outils opérationnels. Ils ont besoin de journaux pour les appels échoués, la validation des schémas, les tests de compatibilité, le signalement des abus et un comportement clair selon les versions d’Android. Un framework ne devient un écosystème que lorsque les équipes peuvent le prendre en charge en production.

Le déploiement progressif de Google est défendable. Libérer une agentivité inter-applications sans restriction avant que les contrôles existent inviterait des échecs prévisibles. L’entreprise a plutôt mis en place des vérifications d’autorisation, des contrats fournisseurs, des outils de test et des API de plateforme en expansion avant d’activer l’accès universel.

Le point de vue sceptique est tout aussi défendable. Un framework sécurisé comptant peu de fonctions appelables n’apporte pas beaucoup de valeur aux consommateurs. Une voie étroitement contrôlée peut également pousser les développeurs indépendants vers l’automatisation d’écran même que le framework était conçu pour remplacer.

Les Google Android App Functions représentent donc une transition importante, mais incomplète. Android dispose désormais d’un mécanisme natif permettant aux agents de découvrir et d’exécuter des opérations encadrées. La plateforme n’a pas encore démontré que ce mécanisme peut soutenir un marché des agents ouvert, concurrentiel et largement adopté.

Au cours des prochains mois, surveillez les intégrations en production au-delà des partenaires de lancement, la publication de règles d’accès pour les agents externes et l’apparition d’un historique clair des autorisations pour les utilisateurs. Ensemble, ces signaux indiqueront si Google a construit une infrastructure partagée ou une voie protégée pour Gemini.

Pour les propriétaires d’appareils Android, la question pratique n’est pas de savoir si un agent IA peut toucher un écran. Des systèmes expérimentaux ont déjà montré que c’est possible. La question est de savoir si Android peut permettre aux agents d’agir dans les applications personnelles sans demander aux utilisateurs de renoncer à un contrôle réel.

Pour les développeurs, la décision arrive plus tôt. Ils doivent identifier des opérations sûres et utiles qui méritent une exposition structurée, et définir à quel moment une confirmation doit intervenir. Attendre évite du travail à court terme, mais peut rendre une application invisible lorsque les utilisateurs commenceront à déléguer des tâches au lieu d’ouvrir des interfaces.

Google a construit l’entrée et installé la serrure. Il doit maintenant prouver que les agents de confiance, les développeurs indépendants et les utilisateurs ordinaires peuvent tous recevoir les bonnes clés.