Diagnostiquer et récupérer un agent IA mobile : runbook Android pour échecs, permissions et relance d’outil

Arrêter une tâche d’agent mobile en sécurité

Quand une tâche échoue, le premier réflexe pour diagnostiquer et récupérer un agent IA mobile est de ne pas tout relancer. Un agent de téléphone peut avoir déjà envoyé un message, modifié un réglage, créé un événement, ouvert une page de paiement ou demandé une permission. Répéter toute la demande peut donc produire un doublon ou aggraver l’état.

Dans les cinq premières minutes, faites quatre choses. Stoppez la tâche si l’interface le permet. Notez le dernier résultat visible : écran actuel, message, permission, confirmation, erreur ou action déjà effectuée. Classez la tâche : lecture seule, action réversible ou effet externe. Puis identifiez l’erreur affichée sans la confondre avec la cause racine. Un échec visible au moment d’envoyer un SMS peut venir d’un contact ambigu, d’une permission retirée, d’un réseau absent ou d’un plan d’agent imprécis.

La recherche AgentDebugX formalise une boucle utile pour les agents : Detect, Attribute, Recover, Rerun. En français opérationnel : détecter l’échec, attribuer la cause, réparer la condition, relancer seulement ce qui doit l’être. Nous l’adaptons ici au téléphone Android, où les permissions, l’écran, les validations et les effets externes comptent autant que le raisonnement du modèle.

Capturer un paquet de preuves minimal

Un bon diagnostic commence par des preuves courtes et propres. Capturez l’intention originale, le résultat attendu, l’étape où l’agent s’est arrêté, le dernier état visible et les permissions concernées. Ajoutez le type de réseau, l’application cible, l’écran actif, l’heure approximative et la décision de validation si une carte d’approbation était affichée.

Évitez de partager des secrets. Masquez les numéros de téléphone, adresses, jetons, mots de passe, contenus de messages privés et pièces jointes sensibles. Une capture d’écran peut aider, mais elle ne suffit pas : elle montre l’état final, pas la trajectoire. Pour une cause racine agent, il faut souvent savoir ce que l’agent voulait faire juste avant l’erreur, quel outil a été choisi et quelle condition manquait.

Le paquet minimal tient en six lignes : demande utilisateur, tâche prévue, dernière étape réussie, première étape douteuse, permission ou état Android observé, effet externe déjà produit. Cette structure protège la vie privée tout en donnant assez de contexte pour reconstruire le trajet. Pour relier ces éléments à l’identité, aux permissions et aux journaux d’action d’un agent, notre guide Identité des agents IA : permissions, approbation par outil et piste d’audit prolonge la méthode.

Classer la couche de défaillance

Un échec tâche agent IA se présente souvent comme un seul message, mais il appartient à une couche précise. La classification empêche de réparer au mauvais endroit. Une erreur de permission ne se corrige pas en reformulant le prompt ; une erreur de routage ne se corrige pas en accordant plus d’accès ; une erreur de service externe ne se corrige pas en effaçant les données de l’application.

Android rend la couche permission particulièrement importante. La documentation officielle sur les permissions d’exécution Android rappelle qu’une application doit vérifier les permissions quand elle les utilise, et que l’utilisateur peut refuser, retirer ou refuser durablement une permission. Pour les échecs de routage, notre article Routage des capacités d’un agent IA Android : AutoAttach, Suggest et Fallback explique comment une capacité peut être sélectionnée, proposée ou abandonnée.

Trouver la première étape causale

La boucle AgentDebugX insiste sur un point essentiel : la cause peut précéder l’erreur affichée. Sur téléphone, l’agent peut montrer une erreur d’envoi alors que la première erreur était un destinataire mal choisi trois étapes plus tôt. Pour attribuer correctement, remontez depuis l’échec visible jusqu’à la première décision qui a changé la trajectoire.

Commencez par la dernière étape réussie. Ensuite, vérifiez les préconditions en lecture seule : permission accordée, contact exact, app ouverte, réseau disponible, compte connecté, état de batterie, réglage accessible. Puis inspectez les paramètres envoyés à l’outil : numéro, calendrier, date, texte, lieu, application ou fichier. Si deux causes restent possibles, notez-les avec un niveau de confiance plutôt que de trancher trop vite.

La formulation de la cause doit être observable. Dites permission contacts refusée au moment de chercher le destinataire, pas l’agent a raté. Dites outil calendrier appelé avec une date ambiguë, pas bug calendrier. Cette précision rend la récupération plus courte et les tests futurs plus utiles. Pour transformer cette attribution en évaluation répétable, notre page Benchmark d’agents Android : évaluer un agent téléphonique en 2026 montre comment comparer des tâches avec des résultats observables.

Récupérer sans dupliquer les effets terminés

La récupération sûre commence par l’inventaire des effets. Qu’est-ce qui a déjà été lu, préparé, modifié, envoyé, créé, supprimé ou partagé ? Les actions en lecture seule peuvent souvent être relancées. Les réglages réversibles demandent une vérification d’état. Les effets externes, comme un SMS envoyé, un mail transmis ou un événement créé, exigent une relance ciblée afin de ne pas dupliquer.

Réparez la précondition manquante avant de relancer. Cela peut être une permission, une application remise au premier plan, un écran correctement positionné, une connexion réseau, un compte reconnecté ou une cible clarifiée. Si la permission a été refusée durablement ou réinitialisée automatiquement par Android, ouvrez le réglage correspondant et accordez seulement l’accès nécessaire à la tâche.

Ensuite, relancez le plus petit suffixe sûr. Ne demandez pas à l’agent de recommencer depuis le début si seules les deux dernières étapes ont échoué. Demandez plutôt : reprendre à partir du brouillon affiché, vérifier l’événement déjà créé, renvoyer uniquement si aucun message n’est parti, ou ouvrir la page de permission puis reprendre l’action. Cette discipline évite les doublons et garde le téléphone dans un état compréhensible.

Après relance, arrêtez dès que le résultat final est vérifié. Un agent mobile efficace n’a pas besoin de continuer à explorer quand la tâche est terminée. Le résultat vérifié devient la clôture de l’incident.

Utiliser les contrôles FoneClaw pour diagnostiquer et récupérer

Chez FoneClaw, nous avons construit les contrôles de récupération autour d’un principe simple : l’utilisateur doit pouvoir revenir à la tâche, voir l’état, comprendre l’étape bloquée et reprendre avec une action précise. FoneClaw expose les résultats d’outil, les validations, l’arrêt, la relance, la récupération des permissions et le contexte d’écran choisi par l’utilisateur lorsque la tâche en a besoin.

Si une tâche échoue depuis une autre application, commencez par revenir au même contexte. Le panneau flottant permet d’utiliser FoneClaw près de l’écran courant. L’attachement de l’écran actuel reste une action volontaire : l’utilisateur choisit quand fournir ce contexte, puis l’agent peut raisonner sur ce qui est visible. Pour comprendre ce mécanisme sans le mélanger au dépannage général, consultez Assistant IA flottant Android : comprendre et agir depuis l’écran actuel.

Nos outils Android couvrent des familles d’actions prises en charge, avec plus de 100 outils intégrés sur la route principale actuelle. Pour diagnostiquer, ne regardez pas seulement la réponse du modèle : regardez l’outil choisi, son résultat, la permission demandée, la validation attendue et l’état final. Une action de volume, de calendrier, de message ou de localisation n’a pas la même stratégie de relance.

Quand une permission manque, FoneClaw guide vers la récupération adaptée et reprend la tâche avec l’état visible. Quand une validation est en attente, l’utilisateur garde la décision. Quand une étape doit être relancée, la relance s’appuie sur la condition réparée. Les capacités actuelles sont décrites sur la page fonctionnalités FoneClaw, et la page téléchargement FoneClaw garde les informations d’installation à jour.

Créer un rapport utile pour le support ou un bug

Escaladez quand l’échec se répète avec les mêmes étapes, quand la cause reste ambiguë après vérification, quand l’agent produit un résultat incohérent ou quand une action externe a besoin d’un audit. Un bon rapport n’a pas besoin de contenir toute votre vie numérique.

Utilisez ce modèle : objectif de la tâche, appareil et version Android, application cible, étapes visibles, permission ou validation affichée, dernier résultat réussi, première étape suspecte, résultat attendu, résultat obtenu, heure approximative, réseau utilisé et capture expurgée si utile. Retirez mots de passe, jetons, contacts privés, contenus de messages et pièces jointes personnelles, sauf accord explicite et nécessité réelle.

Ajoutez la relance déjà tentée : permission réparée, écran replacé, réseau testé, tâche arrêtée, étape relancée. Ce détail évite au support de recommencer le diagnostic depuis zéro et accélère l’identification de la cause racine.

Prévenir la récurrence avec des tests d’acceptation

Après la récupération, transformez l’incident en test. Notez la tâche, la condition qui a échoué et le plus petit scénario qui reproduit le problème. Testez ensuite les combinaisons importantes : permission accordée, permission refusée, permission retirée, réseau coupé, application en arrière-plan, écran incorrect, cible ambiguë et validation ignorée.

Les bonnes pratiques Android sur les permissions recommandent de tester les flux avec permissions accordées et retirées, et de ne demander que les accès nécessaires. Pour un agent mobile, ajoutez deux tests : interruption au milieu de la tâche et vérification finale du résultat. Le succès n’est pas seulement une réponse correcte ; c’est une action visible, vérifiée, arrêtable et récupérable.

Conservez les preuves qui servent à la régression : intention, couche d’échec, cause attribuée, réparation, suffixe relancé et résultat final. Un seul rerun réussi ne prouve pas une correction permanente. Une petite matrice d’acceptation vous dira si l’agent résiste aux changements d’état du téléphone.