Apprendre une tâche à un agent mobile par démonstration : capture, compétences et sécurité

Montrer une tâche ne revient pas à programmer une macro

Un agent IA peut-il apprendre un parcours à partir d’un enregistrement d’écran ? Une démonstration peut effectivement fournir la matière nécessaire : elle montre l’ordre général, les écrans rencontrés et le résultat recherché. Pour devenir réutilisable, elle doit toutefois être interprétée. L’agent doit distinguer ce qui constitue une règle de ce qui relève simplement de l’exemple, comme le nom d’un contact, la position momentanée d’un bouton ou la valeur saisie ce jour-là.

Le signal récent vient de Claude Cowork. Selon le compte rendu publié par ITmedia le 22 juillet 2026, Record a Skill enregistre une tâche accompagnée d’une explication orale, puis la transforme en compétence réutilisable. Un essai publié par Android Authority décrit également la capture de l’écran pendant que l’utilisateur explique son processus, avec l’objectif de réduire les instructions répétées pour les tâches récurrentes. Cette fonction rend concret un principe plus large : une démonstration commentée peut servir de spécification initiale.

Elle se distingue d’abord d’un prompt, qui décrit le but sans nécessairement montrer le chemin. Elle diffère aussi d’une macro déterministe, laquelle répète une séquence fixe de clics ou de coordonnées. La lecture d’un enregistrement n’est pas davantage une reprise vidéo : le système ne doit pas simplement imiter les gestes visibles. Enfin, cette méthode ne correspond pas à l’entraînement général d’un modèle sur un vaste jeu de données. Elle vise une compétence précise, destinée à être invoquée de nouveau dans un contexte défini.

Le sujet est donc moins « enregistrer mes gestes » que « transmettre une procédure compréhensible ». Pour situer ce signal dans l’évolution des interfaces agentiques, consultez Claude Cowork sur téléphone : pourquoi le mobile devient l’interface de l’agent IA.

De la capture commentée à une compétence réutilisable

Comment passer d’un exemple à une compétence que l’on peut rappeler plus tard ? Le cycle commence par une trace propre. L’utilisateur effectue la tâche dans un état connu tout en expliquant son objectif : « ouvrir cette rubrique », « choisir le prochain créneau disponible » ou « ne poursuivre que si le montant reste sous ce seuil ». La voix apporte le pourquoi que les gestes seuls ne révèlent pas.

L’étape suivante consiste à segmenter la démonstration. Le système identifie le point de départ, les actions, les observations, les décisions et le résultat final. Il sépare ensuite les constantes des paramètres. Le nom de l’application et la destination d’un menu peuvent rester fixes ; le destinataire, la date, le texte d’un message ou la quantité deviennent des valeurs fournies au moment de l’exécution. Une donnée affichée pendant l’exemple ne doit pas être transformée par erreur en règle permanente.

La généralisation exige également de formuler les conditions. Si l’application demande une connexion, si plusieurs comptes sont disponibles ou si une option n’existe pas, la compétence doit savoir s’arrêter, demander une précision ou proposer une reprise manuelle. Les explications prononcées pendant la capture sont particulièrement utiles pour décrire ces bifurcations : « si le bouton est désactivé, revenir sans envoyer » est plus informatif qu’un simple toucher réussi.

Une fois les règles extraites, la compétence peut être empaquetée avec un nom, une finalité, des paramètres d’entrée, des permissions, des conditions préalables, des points de confirmation et un résultat attendu. Elle devient alors invocable par une demande naturelle. Par exemple, « prépare mon message hebdomadaire pour l’équipe » peut appeler le même parcours avec un texte et des destinataires différents.

Cette logique rejoint l’objectif d’Automatiser les tâches Android avec une seule commande vocale : la commande ne contient pas tous les gestes. Elle déclenche un parcours structuré dont les variables sont renseignées au bon moment, tandis que les actions sensibles restent soumises au contrôle prévu.

Pourquoi une simple répétition résiste mal à Android

Pourquoi ne pas mémoriser les coordonnées des boutons et rejouer le geste ? Sur Android, l’écran visible dépend de nombreux états. Une bannière peut déplacer le contenu, un clavier modifier la zone disponible et une mise à jour réorganiser un menu. La taille de l’écran, l’orientation, les réglages d’affichage et la présentation adaptative changent aussi la position des éléments.

L’état du compte produit d’autres variations. Un utilisateur déjà connecté n’obtient pas les mêmes écrans qu’un compte arrivé à expiration. Une première utilisation peut afficher une demande d’autorisation ou une présentation introductive. Le contenu diffère selon la langue, le pays, l’abonnement ou les données disponibles. Une macro fondée sur le troisième bouton de la deuxième ligne risque alors d’effectuer une action sans rapport avec le but initial.

Une compétence plus robuste cherche une intention dans l’interface : identifier le champ du destinataire, vérifier le libellé d’un bouton ou confirmer qu’un écran correspond bien à l’étape attendue. Les informations d’accessibilité peuvent aider à reconnaître les composants, leur rôle et leur texte. Le guide Android consacré aux services d’accessibilité décrit les possibilités offertes par cette couche pour interagir avec l’interface. Son utilisation doit rester alignée sur la finalité déclarée et les permissions accordées.

Même une reconnaissance sémantique ne supprime pas les exceptions. Une boîte de dialogue système peut demander une permission, une application peut ouvrir un navigateur ou un écran de paiement peut exiger une authentification. La compétence doit alors vérifier l’état actuel avant de poursuivre. Elle gagne à disposer de plusieurs stratégies : utiliser l’élément attendu, rechercher une autre voie compatible, demander une action humaine ou arrêter proprement le parcours.

Les travaux sur l’entraînement spécialisé éclairent un autre aspect sans se confondre avec une démonstration personnelle. Notre article PhoneBuddy-4B et entraînement des agents mobiles : pourquoi le Mock-App RL compte sur Android explique comment des environnements contrôlés peuvent améliorer les capacités générales d’un agent. Une compétence issue d’un enregistrement répond à une question plus locale : comment adapter ces capacités à la procédure particulière d’un utilisateur ?

Enregistrer un exemple propre et sans données sensibles

Que faut-il montrer pour transmettre un parcours sans capturer sa vie privée ? Préparez d’abord un environnement de démonstration. Utilisez des données fictives ou un compte de test, désactivez les aperçus de notifications et fermez les applications sans rapport avec la tâche. L’enregistrement doit illustrer la logique, pas recueillir plus d’informations que nécessaire.

Les mots de passe, codes d’authentification, clés de récupération, données de paiement, conversations privées et informations de santé ne doivent jamais apparaître dans la capture. Évitez également les adresses, numéros de téléphone, identifiants internes ou documents personnels lorsqu’ils n’apportent rien à l’apprentissage. Remplacez-les par des valeurs factices dont le rôle reste évident, par exemple « contact de test » ou « adresse exemple ».

Android encadre techniquement la capture d’écran. La documentation MediaProjection d’Android prévoit un consentement de l’utilisateur pour chaque session de projection et détaille la gestion du contenu capturé. Ce consentement ponctuel ne transforme pas l’enregistrement en autorité générale sur le téléphone. Il ouvre une session précise, destinée à un usage visible et maîtrisé.

Pendant la démonstration, expliquez les décisions plutôt que chaque mouvement du doigt. Dites pourquoi vous sélectionnez un élément, ce qui peut varier et quel résultat prouve la réussite. Montrez une exception utile si elle peut être reproduite sans risque : article indisponible, champ obligatoire vide ou destinataire ambigu. Indiquez aussi les moments où l’agent doit demander une confirmation.

La documentation Android sur la confidentialité et la sécurité traite les permissions et l’accès aux données sensibles comme des capacités délimitées. Une compétence doit reprendre ce principe : demander uniquement les accès nécessaires à l’étape concernée, expliquer leur rôle et fonctionner avec une solution de reprise lorsque l’accès n’est pas accordé.

Tester, encadrer et faire évoluer la compétence

Comment savoir si la compétence a réellement appris la procédure ? Le premier essai doit être une simulation sans conséquence : l’agent parcourt les étapes, affiche ses choix et s’arrête avant l’envoi, la publication, la suppression, l’achat ou toute autre action engageante. Cette exécution à blanc permet de vérifier les paramètres et les points d’arrêt sans produire le résultat final.

Testez ensuite plusieurs variantes. Changez une valeur d’entrée, utilisez un autre compte de test, modifiez la langue ou la taille d’affichage et provoquez une permission absente. Ajoutez un état inattendu, comme une session expirée. Le but n’est pas de multiplier les scénarios au hasard, mais de couvrir les différences qui peuvent modifier la décision ou la position des commandes.

Chaque action doit être reliée à une permission ou à une capacité précise. L’ouverture d’une application, la lecture d’un élément visible, l’accès aux contacts et l’envoi d’un message n’ont pas la même portée. Les confirmations doivent correspondre aux conséquences : préparer un brouillon peut être automatique, tandis que son envoi mérite un contrôle explicite. Notre analyse sur la Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action approfondit cette association.

Une compétence exploitable possède également un numéro de version, une date de test et un historique des changements. Lorsqu’une application modifie son interface, la version précédente reste disponible le temps de valider l’adaptation. Les journaux doivent montrer l’invocation, les paramètres utiles, les étapes réalisées, les confirmations et le résultat, sans enregistrer inutilement les données sensibles.

Enfin, définissez la récupération avant le déploiement. Que se passe-t-il si l’application se ferme, si le réseau disparaît ou si l’état final reste incertain ? Le parcours peut retenter une observation sans répéter l’action engageante, revenir à un écran connu ou transmettre la main à l’utilisateur. Pour structurer identité, droits et traces, consultez Identité, permissions et audit des agents IA : la sécurité nécessaire sur téléphone.

La vision de FoneClaw pour les parcours mobiles réutilisables

Comment cette méthode s’intègre-t-elle à la vision produit de FoneClaw ? Nous considérons une compétence mobile comme un contrat opérationnel entre une intention, des paramètres, des actions Android prises en charge et des contrôles. Le modèle configuré fournit la compréhension du langage, le raisonnement et la planification. FoneClaw traduit ce plan en actions compatibles sur le téléphone, avec un état visible et des permissions adaptées au parcours.

FoneClaw se concentre actuellement sur l’exécution contrôlée de parcours Android pris en charge. La création automatique d’une compétence à partir d’un enregistrement n’appartient pas à son périmètre actuel. Le modèle de conception présenté ici reste directement utile : une future chaîne démonstration-compétence doit produire une procédure testable et gouvernée, et non une suite opaque de gestes enregistrés.

Dans un parcours réutilisable, l’utilisateur fournit l’objectif et les variables. Le modèle peut adapter le plan à l’état observé, tandis que FoneClaw montre les résultats de chaque étape. Lorsqu’une permission manque, l’utilisateur peut l’accorder au moment approprié ou choisir une autre voie. Quand le parcours atteint une action importante, FoneClaw sollicite la confirmation prévue. Si l’interface ne correspond plus aux conditions testées, une reprise pratique permet de continuer manuellement.

Cette séparation apporte plus de souplesse qu’une macro sans retirer le contrôle humain. Le raisonnement sert à retrouver la logique de la tâche malgré une variation ; les limites de la compétence empêchent cette adaptation de devenir une autorité générale. L’état visible, les confirmations et les journaux permettent ensuite de comprendre ce qui a été fait.

Pour évaluer un parcours appris par démonstration, posez cinq questions : l’objectif est-il explicite ? Les valeurs propres à l’exemple ont-elles été transformées en paramètres ? Les permissions sont-elles liées aux actions correspondantes ? Les variantes importantes ont-elles été testées ? Une interruption laisse-t-elle un état clair et récupérable ? Si ces cinq réponses sont précises, l’enregistrement a cessé d’être une simple vidéo : il est devenu la base d’une compétence mobile exploitable.