Automatiser des tâches Android en plusieurs étapes avec confirmation

Définir une tâche Android fiable en plusieurs étapes

Automatiser des tâches en plusieurs étapes Android commence par une intention claire, mais l’intention seule ne suffit pas. Une demande comme « prépare mon téléphone pour la réunion » contient un résultat attendu, plusieurs dépendances et au moins un réglage sensible. Le rôle de FoneClaw est de transformer cette phrase en workflow Android lisible : comprendre le but, inspecter l’état actuel, proposer les changements, demander la validation utile, exécuter les actions prises en charge, puis vérifier l’état final.

Nous utilisons un modèle simple : intention, inspection, proposition, confirmation, exécution, vérification, récupération. L’intention décrit le résultat. L’inspection regarde ce qui existe déjà sur le téléphone : heure, calendrier, volume, mode sonore, état de Ne pas déranger, permissions disponibles ou app ouverte. La proposition rend le plan visible avant tout changement. La confirmation valide une action précise. L’exécution applique le changement pris en charge. La vérification contrôle que le téléphone affiche bien le nouvel état. La récupération explique quoi faire quand une permission, une interface ou un réglage manque.

Cette chaîne évite de traiter une commande vocale comme une action atomique. Un seul ordre peut impliquer plusieurs étapes, et chaque étape peut dépendre de l’état précédent. Activer un réglage déjà actif, modifier une politique de notifications, créer un rappel ou envoyer un message n’ont pas le même niveau d’impact. Le workflow fiable garde ces différences visibles.

Pour replacer cette boucle dans le contrôle du téléphone au sens large, notre guide Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire explique comment nous pensons l’action Android gouvernée, la progression et le retour d’état.

Préparer une réunion avec Ne pas déranger en mode Priorité

La réunion est un bon cas pratique parce qu’elle combine une intention simple et un réglage qui mérite une validation. La demande peut être : « prépare mon téléphone pour ma réunion de 14 h : laisse passer les contacts prioritaires et les alarmes, puis remets le mode normal après ». FoneClaw commence par comprendre le résultat : réduire les interruptions pendant la réunion sans bloquer les alertes importantes.

La première étape consiste à inspecter l’état actuel. Le téléphone est-il déjà en mode silencieux ? Ne pas déranger est-il désactivé, actif, ou configuré autrement ? Les contacts prioritaires existent-ils ? Les alarmes peuvent-elles passer ? La réunion a-t-elle une heure de fin claire dans le calendrier ou faut-il demander une durée ? Cette inspection protège le workflow contre les changements inutiles et les hypothèses fragiles.

Ensuite, FoneClaw affiche une proposition concrète. Elle doit nommer le réglage, le nouvel état et la condition de fin : « passer Ne pas déranger en mode Priorité pour la réunion, laisser passer les alarmes et les contacts autorisés, puis vérifier l’état après activation ». Le point important est la visibilité : l’utilisateur voit le changement prévu avant l’exécution.

Après confirmation, FoneClaw applique l’action Android prise en charge et vérifie le résultat. Le retour attendu n’est pas seulement « terminé » ; il doit indiquer que Ne pas déranger est bien en mode Priorité, ou expliquer quelle étape demande une intervention. Selon le fabricant, la version Android, les droits accordés et la politique existante, certains chemins passent par un panneau système ou un réglage à confirmer à l’écran. Le workflow reste utile quand il montre l’endroit où reprendre.

La restauration compte autant que l’activation. Pour une réunion avec heure de fin connue, le workflow peut préparer une vérification ou un rappel de retour au mode normal. Pour une réunion sans fin certaine, la meilleure sortie est souvent : « active le mode Priorité maintenant et rappelle-moi de vérifier à 15 h ». Nous construisons FoneClaw pour que ce type de routine garde une trace claire : ce qui a été proposé, ce qui a été appliqué, et ce qui reste à vérifier.

Concevoir des étapes réutilisables avec points de contrôle

Un bon workflow Android commence par l’inventaire des prérequis. Pour une réunion, les prérequis peuvent être le calendrier, l’heure de début, l’heure de fin, les contacts prioritaires, le niveau de volume, l’état de Ne pas déranger et les permissions nécessaires. Pour un trajet, ce seront la destination, l’app de navigation, le réseau, la localisation et le moment de départ. Pour un coucher, ce seront le volume, les alarmes, le mode sombre, la luminosité et les notifications.

L’ordre des étapes doit suivre les dépendances. Avant de changer un réglage, inspectez son état. Avant de créer un rappel, vérifiez l’heure. Avant de préparer un message, identifiez le destinataire. Avant de lancer une navigation, vérifiez la destination. Cette logique rend les workflows plus robustes, car chaque étape dispose du contexte dont elle a besoin.

Ajoutez aussi des embranchements. Si la réunion se termine dans le calendrier, le workflow peut proposer une restauration à l’heure prévue. Si aucune fin n’est connue, il peut demander une durée ou créer un rappel. Si Ne pas déranger est déjà actif dans un autre mode, il peut proposer de conserver l’état actuel ou de passer en Priorité. Si une permission manque, il peut ouvrir le réglage utile puis reprendre la tâche.

Les relances doivent repartir de l’état actuel, pas de l’hypothèse initiale. Si un réglage a déjà changé, si l’utilisateur a modifié l’écran ou si une étape a réussi partiellement, FoneClaw doit relire le contexte avant de continuer. C’est ce qui rend une automatisation Android par IA plus sûre qu’une macro aveugle.

Choisir les actions qui demandent confirmation

Toutes les étapes d’un workflow Android n’ont pas le même niveau de risque. Lire un état, ouvrir une app ou afficher un réglage sert souvent à préparer la décision. Modifier un mode système, envoyer un message, partager une localisation, supprimer un élément ou lancer une action extérieure engage davantage l’utilisateur. La confirmation doit donc suivre l’impact réel de l’étape.

Pour Ne pas déranger en réunion, la confirmation doit nommer le réglage exact : « passer Ne pas déranger en mode Priorité maintenant ». Cette formulation est plus utile qu’un accord vague comme « continuer ». Elle indique ce qui change, quand, et dans quel but. Si le workflow prévoit aussi un rappel de restauration, cette étape doit être visible elle aussi.

Dans FoneClaw, nous concevons les approbations comme des décisions liées à une action précise. Une validation pour inspecter l’état du téléphone ne valide pas automatiquement un changement de réglage. Une validation pour préparer un message ne vaut pas envoi. Une validation pour passer en mode Priorité ne vaut pas autorisation future pour d’autres modes ou d’autres réunions. Ce découpage rend le workflow compréhensible au moment où l’utilisateur est pressé.

La confirmation gagne à afficher trois éléments : la cible, l’effet et la reprise. La cible peut être un réglage, une app, un contact ou un rappel. L’effet décrit le changement. La reprise explique quoi faire si l’utilisateur refuse, corrige ou interrompt. Pour les actions très réversibles, une confirmation légère peut suffire. Pour les communications et les réglages sensibles, la relecture explicite reste la bonne norme.

Pour préparer l’usage vocal sans perdre cette étape de décision, Commande vocale Android : configuration, scénarios sûrs et workflows FoneClaw détaille comment formuler des demandes qui gardent la cible, la contrainte et la validation visibles.

Vérifier le résultat et récupérer une exécution partielle

Une tâche en plusieurs étapes est terminée seulement quand l’état final correspond au résultat demandé. Après un changement de Ne pas déranger, vérifiez le mode actif. Après un rappel, vérifiez l’heure et le texte. Après une ouverture d’app, vérifiez que le bon écran est affiché. Après une note, vérifiez le contenu créé. Cette vérification transforme l’automatisation en workflow fiable.

L’exécution partielle arrive souvent sur téléphone. Une permission peut manquer, un panneau système peut demander une action manuelle, un constructeur peut nommer différemment un réglage, le réseau peut changer, une app peut être fermée, ou l’utilisateur peut interrompre la tâche. Le bon comportement consiste à dire ce qui a réussi, ce qui reste à faire et quelle reprise est disponible.

Dans notre modèle, la récupération commence par la frontière qui a bloqué. Si la permission manque, FoneClaw guide vers l’accès utile. Si le réglage existe mais demande un choix constructeur, il affiche l’écran pertinent. Si une étape a été appliquée mais que la vérification échoue, il propose de relire l’état ou de revenir au réglage précédent quand le chemin est pris en charge. Si l’objectif est devenu ambigu, il demande une précision.

La restauration fait partie de la reprise. Pour une routine de réunion, l’utilisateur peut vouloir revenir au mode sonore normal, rétablir l’ancien niveau de volume ou vérifier que les notifications prioritaires se comportent comme prévu. Une automatisation qui active un état temporaire doit aider à en sortir proprement.

Ce principe distingue FoneClaw d’un simple enchaînement de raccourcis. Nous gardons la progression, les approbations, l’interruption et la reprise dans le même fil de tâche lorsque le parcours est pris en charge. Pour comparer cette approche à des moteurs de règles plus techniques, notre guide Meilleures alternatives à Tasker sur Android : choisir selon la tâche explique quand une règle fixe suffit et quand un agent Android guidé par l’état devient plus pratique.

Modèles de workflows Android réutilisables

Une fois le modèle compris, vous pouvez créer des routines courtes. Le modèle réunion : inspecter calendrier et état sonore, proposer Ne pas déranger en mode Priorité, confirmer le changement, vérifier l’état, puis préparer une restauration ou un rappel. Le modèle trajet : vérifier destination, réseau et localisation, ouvrir la navigation, préparer un message de retard sans l’envoyer, puis vérifier que l’itinéraire est affiché.

Le modèle coucher fonctionne autrement : vérifier les alarmes, réduire le volume, ajuster la luminosité ou ouvrir les réglages utiles, puis confirmer les changements qui modifient réellement le téléphone. Le modèle concentration : ouvrir une app de travail, limiter les interruptions, créer un rappel de pause, puis restaurer les notifications à la fin. Chaque modèle doit rester borné : un objectif, quelques étapes, un état final vérifiable.

• Réunion : inspecter le calendrier, proposer le mode Priorité, confirmer, appliquer, vérifier, restaurer.
• Trajet : vérifier destination et réseau, ouvrir la navigation, préparer un message, confirmer la suite.
• Coucher : vérifier alarmes, régler volume ou luminosité, confirmer les changements utiles.
• Concentration : réduire les interruptions, créer un rappel de pause, vérifier le retour au mode normal.

Le meilleur premier test est réversible. Choisissez une réunion fictive ou un créneau court. Demandez : « prépare mon téléphone pour une réunion de quinze minutes, propose le passage de Ne pas déranger en mode Priorité et montre-moi avant d’appliquer ». Vérifiez la proposition, confirmez seulement si elle correspond à votre intention, puis contrôlez l’état final. Ensuite, demandez le retour au mode précédent ou créez un rappel de restauration.

Cette boucle résume la direction que nous construisons dans FoneClaw : moins de manipulations répétitives, plus d’état visible, des confirmations précises et une récupération pratique. Automatiser un workflow Android ne consiste pas à disparaître derrière l’écran ; cela consiste à rendre les étapes utiles plus rapides tout en gardant la décision au bon endroit.