Interface d’approbation des agents IA sur téléphone : confiance, contexte et reprise

Repérer le moment exact où une décision est nécessaire

Une interface d’approbation des agents IA ne doit pas interrompre l’utilisateur à chaque étape interne. Elle doit apparaître au moment où une proposition suffisamment précise est sur le point de produire un effet. Avant ce stade, l’agent peut rechercher un élément, lire un contexte autorisé ou préparer un brouillon. Dès qu’il s’apprête à envoyer, modifier, partager ou supprimer, l’écran doit montrer la décision concrète attendue.

Prenons un message préparé sur Android. Une validation donnée au début de la demande « réponds à Camille » serait trop générale : le texte final, le compte d’envoi et même l’identité exacte du contact ne sont pas encore connus. L’approbation utile apparaît lorsque le destinataire et le contenu sont visibles. L’utilisateur peut alors choisir « Envoyer », « Modifier » ou « Refuser » en sachant précisément ce que chaque bouton entraîne.

L’impact de l’action détermine aussi la forme de la décision. Ouvrir une carte ou afficher une note peut demander peu d’intervention. Changer un réglage, transmettre une information personnelle ou supprimer un fichier exige davantage de détails. Une interface cohérente ne traite donc pas toutes les étapes comme équivalentes : elle réserve l’attention aux changements qui comptent réellement.

Les capacités actuellement disponibles de FoneClaw améliorent ce parcours avec des approbations rattachées à la session et des tâches isolées. Une validation concerne ainsi la conversation et l’action qui l’ont déclenchée. Si l’utilisateur refuse, cette tâche reste arrêtée sans débloquer une autre demande. S’il corrige la cible, la proposition peut être reconstruite avant toute nouvelle action.

Séparer suggestion, aperçu et application

Trois états doivent être immédiatement reconnaissables sur un écran mobile. Une suggestion décrit ce que l’agent recommande. Un aperçu montre le changement complet prêt à être appliqué. Un résultat confirme qu’une action a effectivement eu lieu. Sans cette séparation, l’utilisateur peut prendre un brouillon pour un message envoyé ou croire qu’un réglage a été modifié alors que l’agent ne l’a encore que proposé.

Les verbes affichés dans l’interface doivent refléter ces états. « Examiner la proposition » ouvre un aperçu. « Appliquer le changement » déclenche l’action. « Réglage modifié » annonce le résultat. Des boutons génériques comme « Continuer » ou « D’accord » sont trop ambigus lorsqu’un effet externe est possible. Sur téléphone, le libellé devrait idéalement associer le verbe et la cible : « Envoyer à Nadia », « Ajouter au calendrier personnel » ou « Déplacer vers Archives ».

Cette progression peut aussi réduire les validations inutiles. Pour créer un rappel à partir d’un message, l’agent peut d’abord extraire la date et préparer le titre. L’aperçu rassemble ensuite le calendrier choisi, l’heure, le fuseau, la note et l’alerte. Une seule approbation porte alors sur un objet complet et vérifiable, plutôt que sur chaque petite étape de préparation.

Un modèle public récent illustre cette distinction dans un autre contexte. Depuis le 23 juillet 2026, une préversion publique de GitHub permet de suggérer certaines modifications prises en charge dans GitHub Issues afin qu’elles soient examinées avant application. La présentation GitHub des actions proposées dans les issues concerne les opérations GitHub documentées, pas les fonctions d’un téléphone ni celles de FoneClaw. La leçon d’interface reste pertinente : montrer clairement ce qui est proposé, ce qui attend une décision et ce qui a déjà été appliqué.

Adapter la vérification au niveau de confiance

Le niveau de confiance peut aider l’interface à décider où concentrer l’attention. Il ne mesure cependant ni la volonté réelle de l’utilisateur ni la gravité d’une erreur. Une proposition peut sembler très probable tout en visant le mauvais contact. À l’inverse, une faible confiance peut simplement signaler qu’une date est formulée de manière relative. Le score doit donc orienter le parcours, jamais être présenté comme une certitude.

Une conception pratique combine trois critères : la confiance du système, la conséquence de l’action et sa réversibilité. Une action peu risquée, facilement annulable et déjà autorisée peut suivre un parcours plus direct. Une opération qui engage un destinataire, un compte, de l’argent ou une suppression définitive conserve une confirmation explicite, même si le modèle affiche une forte confiance.

Plutôt que d’exposer un pourcentage difficile à interpréter, l’interface peut traduire l’incertitude en consigne. « Cible identifiée, vérifiez le contenu » indique que l’essentiel semble clair. « Deux contacts correspondent » appelle un choix. « Date incomplète » demande une précision. « Action sensible prête à confirmer » rappelle que l’attente vient de la conséquence, et non d’une faiblesse particulière du modèle.

Dans la préversion GitHub, les actions prises en charge et jugées très fiables peuvent être appliquées automatiquement selon le fonctionnement configuré, tandis que celles de confiance moyenne ou faible attendent un examen. GitHub précise que ces approbations facilitent le déroulement du travail et ne forment pas une barrière de sécurité côté serveur. Sur Android, la même distinction est indispensable : le niveau de confiance répartit l’effort de lecture, tandis que les permissions du système et les règles d’action déterminent ce qui est réellement autorisé.

Présenter un motif court et une conséquence claire

Une approbation ne devrait jamais obliger l’utilisateur à reconstituer toute la conversation. L’écran doit résumer quatre éléments : la raison de la proposition, sa cible, l’effet prévu et les informations qui ont conduit à cette décision. Le texte peut rester très court si la hiérarchie visuelle place les données importantes avant l’explication.

Pour un événement, l’interface pourrait afficher : « Ajouter un rappel demain à 9 h » ; « Motif : le message de Salomé mentionne une réponse attendue demain matin » ; « Destination : calendrier personnel » ; « Effet : création d’un événement avec une alerte trente minutes avant ». L’utilisateur comprend alors l’origine et la conséquence sans parcourir plusieurs écrans.

Les informations utiles changent selon l’action. Avant un envoi, il faut voir le compte, le destinataire, le texte et les pièces jointes. Pour un réglage, l’état actuel et l’état proposé comptent davantage. Lors d’un déplacement de fichier, le nom, l’emplacement de départ et la destination doivent être lisibles. Une justification standard répétée partout apporte moins de clarté qu’un résumé adapté à l’objet concerné.

Le motif ne constitue pas non plus une preuve absolue. Il explique pourquoi l’agent propose l’action et permet de repérer une mauvaise interprétation. Si la source affichée ne correspond pas à la demande, l’utilisateur peut refuser ou demander une correction avant tout effet. Pour approfondir l’association entre acteur, autorisation et trace de décision, consultez Identité des agents IA : permissions, approbation par outil et piste d’audit.

Rattacher l’approbation à la bonne tâche

Plusieurs demandes peuvent avancer simultanément sur un téléphone. Un itinéraire peut être en préparation pendant qu’un brouillon de message attend une validation et qu’une recherche de calendrier continue. Dans cette situation, une fenêtre d’approbation sans contexte ouvre la porte aux erreurs. Elle doit indiquer la conversation d’origine, la tâche concernée et l’étape exacte qui est suspendue.

FoneClaw distingue les tâches en cours de celles qui attendent l’utilisateur. Les approbations restent liées à leur session et les tâches conservent un contexte isolé. Ainsi, la validation du message préparé pour Marc ne peut pas servir à une modification de calendrier lancée dans une autre conversation. Cette association reste intacte même si l’utilisateur consulte une autre tâche entre-temps.

Une liste de tâches claire peut employer quatre états simples : « En cours », « En attente de votre décision », « Terminé » et « À reprendre ». Chaque élément affiche un titre orienté résultat, l’heure de la demande et la prochaine action attendue. En ouvrant une tâche en attente, l’utilisateur retrouve l’aperçu qui a déclenché l’approbation, pas seulement le dernier message du modèle.

Les notifications doivent conserver la même précision. « Une action attend votre accord » est moins utile que « Le message destiné à Marc attend votre validation ». Le détail sensible peut rester masqué sur l’écran verrouillé, mais la tâche doit être identifiable après ouverture. Notre guide Contrôle d’agent IA mobile : quand le téléphone devient le centre de commande montre comment organiser ces états sans transformer chaque attente en interruption urgente.

Adapter l’interface aux actions du téléphone

Une interface mobile ne peut pas utiliser la même carte de confirmation pour toutes les opérations. Un message, un réglage, un fichier et un itinéraire possèdent des conséquences différentes. Le dessin de l’approbation doit donc suivre l’objet manipulé et mettre en avant les données dont dépend la décision.

Pour les communications, montrez l’identité du destinataire, le canal, le compte et le contenu final. Pour les réglages, comparez la valeur actuelle et celle qui sera appliquée. Pour un fichier, indiquez son nom, son emplacement et le caractère récupérable de l’opération. Une navigation doit présenter la destination, le mode de déplacement et l’application qui ouvrira le trajet. Ces détails transforment une approbation abstraite en choix compréhensible.

Chez FoneClaw, un modèle configuré interprète la demande, puis des outils gouvernés réalisent les actions Android prises en charge. Une instruction comme « prépare un message pour annoncer mon arrivée à 18 h et ouvre l’itinéraire vers le rendez-vous » peut produire deux résultats séparés. L’itinéraire peut être affiché dès que la destination est claire. Le message reste en attente jusqu’à ce que le destinataire et le texte aient été examinés.

Une approbation dans l’agent ne remplace jamais une permission Android absente. Si l’accès au calendrier, aux contacts, aux fichiers ou à la localisation manque, la tâche doit signaler la permission nécessaire et expliquer son lien avec l’action. L’utilisateur peut l’accorder, la refuser ou terminer l’étape manuellement. Le guide Sandbox d’agent IA et permissions du téléphone : pourquoi les limites restent essentielles détaille cette séparation entre règles de l’agent et autorisations du système.

Prévoir le refus, la correction et la récupération

Une bonne approbation prévoit plusieurs issues. « Refuser » arrête l’effet proposé. « Modifier » permet de corriger le destinataire, le texte, l’horaire ou l’emplacement. « Revenir » replace l’utilisateur à l’étape précédente. Le refus ne devrait pas être traité comme une erreur : il s’agit d’une décision normale qui doit laisser la tâche dans un état compréhensible.

L’annulation après application exige davantage de précision. Le bouton « Annuler » ne doit apparaître que si le système peut réellement restaurer l’état précédent. Un événement nouvellement créé peut souvent être supprimé. Un réglage peut généralement retrouver sa valeur initiale. Un message déjà envoyé, en revanche, ne redevient pas automatiquement un brouillon. L’interface doit alors proposer une correction réaliste, comme préparer un nouveau message.

Lorsqu’une permission manque, FoneClaw facilite la récupération et la reprise. La tâche peut rester en attente pendant que l’utilisateur ouvre le réglage nécessaire. Après l’autorisation, elle reprend dans son propre contexte. Si l’application se trouve sur un écran inattendu, la récupération depuis l’accueil et la prise en main tactile offrent un chemin clair pour rejoindre l’étape compatible.

Un résultat incertain mérite une vérification avant toute nouvelle tentative. Si l’état d’un envoi, d’un déplacement ou d’une suppression n’est pas confirmé, répéter immédiatement l’action peut créer un doublon ou aggraver l’erreur. La tâche doit d’abord rechercher l’état réel, puis proposer soit une reprise, soit une correction. Le dernier écran annonce ensuite un résultat observable : action terminée, proposition refusée, permission manquante ou intervention tactile nécessaire.

Pour évaluer une interface d’approbation des agents IA, vérifiez cinq points : le changement est-il nommé, la cible est-elle visible, l’état de la tâche est-il clair, le refus laisse-t-il une sortie propre et le résultat peut-il être contrôlé ? Une expérience fiable ne multiplie pas les demandes d’accord. Elle place une décision précise au bon moment et conserve un chemin de retour lorsque le déroulement rencontre un obstacle.