Quand l’IA agit sur le téléphone : les agents mobiles, nouvelle surface d’attaque

À jour au 14 novembre 2026. Les fonctions d’IA des téléphones évoluent à chaque version d’Android et d’iOS. Cet article sera mis à jour au fil des annonces.

Sur le poste de travail, les agents d’IA lisent les courriels et les documents, et peuvent agir (voir notre analyse Sécuriser les agents IA en entreprise). Sur le téléphone, une étape de plus est franchie : l’agent regarde l’écran, touche les boutons et remplit les formulaires à la place de l’utilisateur, dans n’importe quelle application. Chaque élément affiché devient une instruction potentielle, et chaque application installée, un voisin capable de l’influencer.

Ce qui change sur le téléphone

Les assistants du système

En mai 2026, Google a présenté Gemini Intelligence, qui fait d’Android un « système d’intelligence » capable d’automatiser des applications pour le compte de l’utilisateur. Google met en avant plusieurs garde-fous :

l’automatisation ne démarre qu’à la demande de l’utilisateur, et seulement dans les applications qu’il a autorisées ;
une confirmation est demandée avant un achat ;
l’utilisateur peut suivre les actions en temps réel, et un indicateur impossible à masquer signale que l’agent travaille ;
de nouvelles protections contre l’injection de requêtes sont en cours d’intégration à Android.

En septembre 2026, Google a précisé le volet entreprise : Gemini enchaîne désormais des tâches entre applications à partir du contexte affiché à l’écran (agenda, courriels, navigateur). Le profil professionnel reste isolé, si bien que les agents personnels n’accèdent pas aux applications et données de l’entreprise, et les administrateurs peuvent configurer, restreindre ou désactiver l’automatisation par l’IA sur toute la flotte.

Chez Apple, les fonctions Apple Intelligence et les services d’IA externes se gèrent désormais, sur les appareils supervisés sous iOS 26.4 ou version ultérieure, par des configurations dédiées de la gestion de flotte. Et le 9 novembre 2026, iOS 27.2.1 a corrigé dans App Intents, le cadre qui permet aux applications d’exposer leurs actions au système, un problème d’autorisation qui pouvait permettre à une application d’accéder à des données sensibles.

Les agents tiers

À côté de ces assistants intégrés, des projets open source permettent de piloter un smartphone depuis un ordinateur : l’agent récupère des captures d’écran par l’interface de débogage d’Android (ADB), les fait analyser par un modèle de vision, puis envoie des touchers et du texte. Leur intérêt est de pouvoir automatiser n’importe quelle application. Leur faiblesse aussi.

Les nouvelles attaques

Ce que l’agent voit n’est pas ce que voit l’utilisateur

En juillet 2026, des chercheurs ont évalué cinq de ces agents open source (AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM et MobA). La Cloud Security Alliance en a publié une synthèse : tous étaient vulnérables à au moins six des sept attaques démontrées, sans privilèges particuliers, avec les seules permissions d’une application ordinaire. Quelques exemples :

un calque presque transparent (2 % d’opacité lors des tests), invisible pour un humain mais lu par le modèle, qui lui donne des instructions ;
des instructions placées dans les coins arrondis de l’écran ou autour de la caméra, des zones que personne ne regarde mais qui figurent sur la capture ;
une fausse interface affichée par-dessus une application légitime pour capter les identifiants que l’agent saisit ;
le remplacement de la capture d’écran dans le bref intervalle (environ 210 millisecondes en moyenne) entre sa prise et sa lecture par l’agent ;
l’écoute du texte saisi par l’agent, mots de passe compris ;
l’injection de commandes sur l’ordinateur qui pilote l’agent : du texte affiché à l’écran, recopié par le modèle, finit exécuté sur le PC ou le serveur.

Les attaques visant la perception ont réussi de façon quasi systématique, quel que soit le modèle utilisé. Les chercheurs y voient un problème d’architecture : l’agent agit sur ce que lui montre une capture d’écran, sans aucun moyen de vérifier qu’elle reflète l’état réel de l’appareil.

Des permissions légitimes, un contexte détourné

Un agent manipulé n’a pas besoin de failles : il utilise les permissions qu’on lui a accordées, dans un contexte que l’attaquant a choisi. C’est le cœur des risques recensés par l’OWASP dans son Top 10 consacré aux applications agentiques : détournement d’objectif, usage abusif des outils, abus d’identité et de privilèges. Sur un téléphone, les « outils » de l’agent sont les applications elles-mêmes : messagerie, paiement, stockage de documents.

L’accessibilité, une porte d’entrée connue

L’ANSSI rappelle que les fonctionnalités d’accessibilité, conçues pour les personnes en situation de handicap, sont régulièrement détournées pour lire le contenu de l’écran et les saisies au clavier. Une application malveillante dotée de ces droits peut observer tout ce que fait l’agent, ou lui présenter une fausse interface. L’ANSSI recommande de ne jamais accorder ces permissions sans raison légitime.

Des écrans qui quittent l’appareil

Pour décider, un agent doit faire analyser l’écran par un modèle. Selon sa conception, ce traitement a lieu sur l’appareil, dans un environnement protégé du fournisseur, ou chez un fournisseur de modèle en ligne. Dans ce dernier cas, chaque capture, avec ce qu’elle montre (messages, documents, codes), quitte le téléphone : une question de confidentialité et de RGPD, au même titre que les données des projets d’IA (voir Sécuriser les données de vos projets IA).

Ce qu’une entreprise peut régler dès maintenant

Inventorier les fonctions d’IA présentes sur la flotte : assistants du système, applications d’assistant tierces, outils d’automatisation.
Décider, fonction par fonction, de ce qui est autorisé, et l’appliquer par la gestion de flotte : politiques Android Enterprise pour l’automatisation par l’IA, configurations Apple pour Apple Intelligence et les services d’IA externes.
Garder les usages professionnels séparés : profil professionnel ou appareils dédiés, pour que les agents personnels n’atteignent pas les données de l’entreprise.
Contrôler les permissions sensibles : applications installées uniquement depuis les magasins officiels, revue des applications qui demandent l’accessibilité ou l’affichage par-dessus les autres.
Désactiver les options pour les développeurs et le débogage sur les terminaux de la flotte, dont dépendent les agents pilotés par ADB.
Exiger une validation humaine pour les actions sensibles : paiement, envoi vers l’extérieur, suppression, changement de droits.
Superviser et tester : remonter les alertes mobiles dans le SIEM, inclure les agents mobiles dans l’analyse de risques et dans les tests d’intrusion, et maintenir les systèmes à jour.

Pour les équipes qui développent ou testent des agents mobiles

Les chercheurs et la Cloud Security Alliance recommandent notamment de :

ne jamais construire une commande système en y insérant du texte lu à l’écran, et passer les arguments sous forme structurée ;
ne pas écrire les captures d’écran dans un fichier temporaire lisible par d’autres applications ;
masquer les zones de l’écran que l’utilisateur ne voit pas, et renforcer le contraste des images pour faire apparaître les textes quasi invisibles ;
utiliser des téléphones de test dédiés, isolés des comptes et des données de production ;
privilégier des projets dotés d’un processus de signalement des vulnérabilités.

Pour sécuriser le reste de la flotte, voir notre analyse Le smartphone, angle mort de la sécurité.

Sources

← Toutes les analyses