Android 17 : confidentialité et autorisations des assistants IA

Ce qu’Android 17 change pour les assistants IA

Android 17 a atteint sa version stable en juin 2026. Pour les assistants IA, les changements les plus utiles concernent la manière de sélectionner des contacts, de rendre l’accès à la localisation plus visible, d’encadrer le réseau local, de protéger les codes à usage unique, de signaler un appareil placé sous protection renforcée et de gérer certains usages audio en arrière-plan.

Les informations officielles sur la sortie d’Android 17 présentent une plateforme désormais stable, mais son arrivée sur un téléphone dépend toujours du fabricant, du modèle et du calendrier de mise à jour. Certaines règles dépendent aussi de la version d’Android ciblée par l’application ou de la façon dont celle-ci utilise une API.

L’index des changements de comportement d’Android 17 doit servir de référence aux équipes qui testent leurs applications. Pour l’utilisateur, le premier contrôle consiste à examiner les assistants ayant accès aux contacts, à la localisation, aux notifications, au microphone ou aux appareils du réseau local. Chacun de ces accès doit correspondre à une tâche identifiable.

Android 17 n’établit pas un jeu unique d’autorisations pour tous les assistants. Une application de dictée, un assistant domotique et un agent capable d’agir dans plusieurs apps ont des besoins différents. Le bon périmètre commence par la fonction demandée, puis se limite aux données et actions nécessaires à son accomplissement.

Préférer les contacts et fichiers sélectionnés

Le partage d’une donnée choisie est souvent préférable à l’ouverture d’une catégorie entière. Android 17 ajoute un Contact Picker système, présenté dans la documentation officielle des fonctionnalités et API d’Android 17. Ce parcours permet à l’utilisateur de sélectionner les contacts utiles sans accorder systématiquement un accès général à son carnet d’adresses.

Prenons une demande simple : « Prépare un message pour Léa et Marc au sujet du dîner. » L’assistant peut ouvrir le sélecteur de contacts, laisser l’utilisateur choisir les deux bonnes personnes, puis recevoir uniquement les informations nécessaires au workflow. Le destinataire reste visible avant l’envoi, ce qui réduit également le risque de confusion entre deux contacts portant un nom proche.

Ce modèle améliore la lisibilité de la demande d’accès. L’utilisateur sait quelles personnes seront utilisées et dans quel but. Une application qui doit rechercher continuellement des contacts, synchroniser un répertoire professionnel ou fournir une fonction de gestion complète peut avoir un besoin différent. Le sélecteur reste néanmoins la voie naturelle pour une action ponctuelle déclenchée par l’utilisateur.

La même logique s’applique aux fichiers, photos et vidéos. Un assistant qui doit résumer un document peut recevoir le fichier choisi dans le sélecteur. Une analyse d’image peut partir d’une photo explicitement jointe. L’accès reste alors lié au contenu pertinent plutôt qu’à l’ensemble du stockage partagé.

• Vérifiez que le sélecteur affiche la bonne source et le bon compte.
• Choisissez uniquement les contacts ou fichiers nécessaires à l’action.
• Relisez les destinataires, pièces jointes et données extraites avant confirmation.
• Contrôlez la durée d’accès si la tâche doit reprendre plus tard.
• Retirez ou resélectionnez la donnée lorsque le périmètre change.

Une sélection précise organise l’entrée du workflow ; les règles de l’application et du service configuré continuent ensuite de déterminer le traitement. L’assistant doit donc montrer comment le contact ou le fichier sélectionné sera utilisé avant de passer à l’action suivante.

Revoir la localisation et l’accès au réseau local

La localisation et le réseau local répondent à deux besoins différents. La localisation indique où se trouve l’appareil ou aide à rechercher un service proche. L’accès au réseau local permet à une application de découvrir ou de communiquer avec certains équipements présents sur le même réseau. Un assistant domotique peut avoir besoin de l’un, de l’autre ou des deux selon la tâche.

Android 17 améliore la visibilité autour des accès à la position. Les explications d’Android sur les nouveautés de confidentialité liées à la localisation détaillent les outils et changements destinés à rendre ces usages plus compréhensibles. Pour un assistant, chaque accès doit correspondre à une fonction active, comme trouver une station proche ou démarrer un itinéraire.

Le réseau local possède désormais une frontière d’autorisation plus claire. Cette évolution concerne les applications qui recherchent ou contrôlent des appareils à proximité, par exemple un téléviseur, une enceinte, une imprimante ou un équipement domotique. L’autorisation d’utiliser la localisation ne doit pas être interprétée comme un accès automatique à ces appareils, et inversement.

Imaginons la commande « diffuse cette musique sur l’enceinte du salon ». L’assistant doit d’abord vérifier si l’outil prend en charge la découverte de l’équipement. Android peut ensuite demander l’accès approprié au réseau local. Une fois l’appareil identifié, son nom doit être présenté avant la connexion afin d’éviter de choisir l’enceinte d’une autre pièce ou un équipement inconnu.

Si l’utilisateur refuse l’autorisation, le workflow doit afficher ce qui manque et conserver l’intention. Il peut proposer d’ouvrir le réglage concerné, d’utiliser une autre méthode déjà configurée ou d’arrêter la tâche. Le refus ne doit pas déclencher une recherche indirecte avec une portée différente.

Après une mise à jour, testez séparément les fonctions de navigation et celles liées aux appareils locaux. Désactivez temporairement chaque autorisation, relancez une tâche réversible et observez si l’assistant explique correctement le blocage.

Protéger les codes temporaires et notifications sensibles

Un code à usage unique sert à confirmer une authentification ou une opération précise. Android 17 renforce la protection du contenu de notification lié à ces codes. Pour un assistant IA, la conséquence pratique est simple : un OTP ne doit pas être traité comme une notification ordinaire à résumer, classer ou transférer.

Supposons qu’un utilisateur ouvre un service bancaire et reçoive un code temporaire. L’assistant peut expliquer qu’une étape d’authentification attend une intervention, mais le code lui-même doit rester dans le parcours sécurisé prévu par le service. L’utilisateur le consulte et le saisit selon l’interface correspondante.

Cette séparation évite qu’une automatisation de notifications transforme un secret temporaire en donnée conversationnelle. Un résumé quotidien peut mentionner qu’une tentative de connexion a généré une alerte, sans reproduire le code. Une fonction de transfert de messages doit également distinguer ce contenu d’un texte ordinaire.

Lorsqu’un workflow rencontre une notification protégée, l’état attendu est visible : « Une authentification est requise. Ouvrez l’application pour continuer. » L’assistant conserve les informations non sensibles déjà préparées, attend la fin de la validation, puis reprend lorsque le service indique que l’utilisateur est authentifié.

Les protections ne rendent pas toutes les notifications inaccessibles. Elles renforcent le traitement de contenus particulièrement sensibles. Les développeurs doivent vérifier les changements de comportement d’Android 17, tandis que les utilisateurs peuvent contrôler l’accès aux notifications dans les réglages de chaque assistant.

Pour tester la récupération, utilisez un compte de démonstration ou une opération sans conséquence financière. Vérifiez que l’assistant s’arrête devant l’étape d’authentification, qu’il ne copie pas le secret dans son historique et qu’il reprend uniquement après une validation réussie dans l’application concernée.

Réagir au mode de protection avancée

Android 17 expose aux applications l’état du mode de protection avancée, ou Advanced Protection Mode. Ce signal aide une application à adapter son comportement lorsqu’un utilisateur a choisi des politiques de sécurité plus strictes. Les effets précis dépendent de l’appareil, de la fonction et de l’application.

Pour un assistant, ce mode doit apparaître comme un état normal du système. Une action à risque plus élevé peut être limitée, un parcours d’installation peut demander davantage de contrôles ou une opération en arrière-plan peut être indisponible. L’assistant doit présenter cette restriction clairement et proposer une solution compatible avec la protection active.

Par exemple, un workflow peut vouloir ouvrir un fichier reçu, installer une extension ou utiliser un canal de communication particulier. Si la politique de l’appareil bloque l’étape, l’assistant conserve la demande et indique l’action autorisée suivante : consulter le fichier sans l’exécuter, utiliser une fonction déjà approuvée, demander une validation dans les réglages ou abandonner.

Le choix appartient au propriétaire de l’appareil. Un assistant peut guider vers les informations utiles, mais il ne doit pas désactiver lui-même une protection pour terminer une tâche. Les personnes qui souhaitent réduire davantage l’automatisation peuvent suivre Comment désactiver l’IA sur Android : Gemini, permissions, activité et FoneClaw.

Advanced Protection Mode n’est pas nécessairement actif sur tous les téléphones. Lors de l’audit, vérifiez son état, puis exécutez un workflow à faible risque. L’objectif est de confirmer que l’application reconnaît la restriction, explique son effet et revient à un état stable sans élargir silencieusement son périmètre.

Auditer le microphone et l’audio en arrière-plan

Les assistants vocaux et les outils de réunion dépendent du microphone, mais leurs besoins diffèrent. Une commande lancée au premier plan peut utiliser le micro pendant quelques secondes. Une transcription de réunion dure plus longtemps. Une fonction qui poursuit un traitement lorsque l’écran change doit respecter les règles d’arrière-plan et conserver un état visible.

Android 17 modifie certains comportements liés à l’audio en arrière-plan. Les équipes doivent consulter l’index officiel des changements, tester leur cible Android et vérifier le fonctionnement sur les appareils concernés. Pour l’utilisateur, le critère principal reste observable : quand la capture commence-t-elle, pourquoi continue-t-elle et comment l’arrêter ?

Avant l’enregistrement : l’application doit annoncer l’objectif, demander l’autorisation nécessaire et laisser choisir le contexte. Une commande courte, une note vocale et une réunion ne justifient pas la même durée ni le même traitement.

Pendant l’enregistrement : l’indicateur de microphone et l’état de l’application doivent rester compréhensibles. L’utilisateur doit pouvoir interrompre la capture. Si le système place l’application en arrière-plan ou retire une permission, le workflow doit refléter ce changement.

Après l’enregistrement : l’application confirme l’arrêt, présente le fichier ou la transcription disponible et propose les actions pertinentes. Une pièce jointe audio ne doit pas rester active comme source implicite d’une nouvelle tâche sans choix clair de l’utilisateur.

Testez aussi une interruption : recevez un appel, verrouillez l’écran, retirez l’autorisation du microphone ou arrêtez l’application. Au retour, l’assistant doit indiquer si l’enregistrement a été sauvegardé, interrompu ou abandonné. Cette reprise évite les fichiers incomplets présentés comme des résultats terminés.

Réaliser un audit des autorisations

Un audit efficace commence par les tâches, pas par la liste brute des permissions. Inventoriez ce que l’assistant doit accomplir, associez chaque tâche à la donnée minimale nécessaire, puis testez le refus, la révocation et le résultat final.

Les permissions peuvent être refusées, révoquées automatiquement ou modifiées par une politique de sécurité. Un test réussi aujourd’hui ne remplace donc pas la vérification au moment de la prochaine action. L’assistant doit consulter l’état actuel avant d’utiliser une capacité.

Pour approfondir la différence entre l’environnement contrôlé de l’agent et les droits du système, consultez Sandbox d’agent IA et permissions du téléphone : pourquoi les limites restent essentielles. Le guide Vérifier la santé du téléphone Android avec IA : batterie, permissions et notifications complète cet audit avec les effets de la batterie, des réglages et des notifications.

Terminez par une revue des exceptions. Un fabricant peut déployer Android 17 à un rythme différent, une application peut cibler une autre version du SDK et une politique professionnelle peut imposer des restrictions supplémentaires. Notez ces variations par workflow plutôt que d’élargir toutes les autorisations pour obtenir un comportement uniforme.

Tester un workflow FoneClaw sous Android 17

Chez FoneClaw, nous construisons les actions Android autour d’outils explicites, d’autorisations vérifiables et d’une progression visible. Pour tester Android 17 sans commencer par une tâche sensible, choisissez un workflow simple : préparer un message à deux contacts sélectionnés, puis enregistrer un rappel de suivi.

Demandez d’abord à FoneClaw de préparer le message. Lorsque le choix des destinataires est nécessaire, sélectionnez les contacts pertinents dans le parcours proposé par Android. FoneClaw utilise ce contexte pour préparer le texte et affiche les noms ainsi que le contenu avant toute étape conséquente.

Refusez ensuite l’accès demandé pour une fonction secondaire ou retirez temporairement une permission. Le workflow doit indiquer ce qui manque, conserver le brouillon et proposer une reprise. Après votre décision, FoneClaw reprend depuis l’état confirmé plutôt que de reconstruire silencieusement la tâche avec une portée plus large.

Validez le message uniquement après relecture du destinataire et du contenu. Demandez ensuite la création du rappel. Une fois l’action effectuée, contrôlez que l’élément apparaît avec la bonne date et le bon texte. La progression persistante, détaillée dans Android Halo : statut des agents IA dans la barre d’état Android, aide à suivre les tâches qui changent d’application ou attendent une autorisation.

Ce test couvre les cinq points essentiels d’Android 17 : contexte choisi, portée minimale, refus visible, confirmation et résultat vérifié. Il peut ensuite être adapté à la localisation, à un fichier sélectionné, à une commande vocale ou à un appareil du réseau local, selon les capacités disponibles sur le téléphone.

Les fonctionnalités FoneClaw présentent les actions actuellement prises en charge et leurs usages. La page Télécharger FoneClaw permet de choisir la distribution Android disponible, puis d’exécuter cet audit sur une tâche réversible. Le comportement concret dépend de la version Android, des permissions accordées, de l’état des applications, des services régionaux et du périmètre du workflow.