Pourquoi les agents IA sont lents : diagnostic de latence pour agent mobile

Pourquoi un agent IA paraît plus lent qu’un chatbot

Si vous vous demandez pourquoi les agents IA sont lents, la réponse courte est que l’agent ne fait pas le même travail qu’un chatbot. Un chatbot doit surtout produire une réponse. Un agent mobile doit comprendre la demande, observer l’état du téléphone, choisir un outil, demander les permissions nécessaires, préparer ou exécuter une action, vérifier le résultat et récupérer si quelque chose bloque. Le temps de réponse d’un agent mobile est donc la somme de plusieurs étapes, pas seulement le temps du LLM.

La sensation de lenteur vient aussi du résultat attendu. Quand l’utilisateur pose une question, quelques secondes peuvent sembler acceptables si le texte arrive vite. Quand il demande “prépare une réponse dans cette app” ou “ouvre le bon réglage”, il attend un état réel sur Android. L’agent doit alors éviter de déclarer une action accomplie avant que le téléphone l’ait confirmée.

La bonne mesure sépare deux moments : le premier retour visible, qui montre que l’agent a compris et avance, puis le résultat vérifié, qui confirme que l’action Android a vraiment abouti. Accélérer un agent Android consiste à réduire les attentes inutiles entre ces deux moments, sans supprimer les contrôles qui protègent l’utilisateur.

D’où vient la latence d’un agent IA

La latence des agents IA ne se résume pas à la vitesse du modèle. L’inférence est importante, mais elle n’est qu’une partie du pipeline. Un agent téléphone ajoute l’entrée utilisateur, la transcription éventuelle, le choix du modèle, la sélection d’outil, l’état Android, les permissions, les actions sur l’appareil, les appels réseau, la vérification et parfois la récupération.

Le diagnostic devient plus utile quand on mesure chaque étape séparément. Un agent peut être rapide au premier retour mais lent à terminer, ou lent au départ puis fiable dans l’exécution. Les deux profils ne se corrigent pas de la même manière. Le premier demande souvent une optimisation des actions et vérifications ; le second demande plutôt un modèle plus adapté, une meilleure entrée ou un routage plus simple.

Pour comprendre le pipeline complet d’un agent Android, Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire détaille la chaîne intention, outil, permission, confirmation et résultat. C’est cette chaîne qui transforme une réponse intelligente en action utilisable.

Pourquoi les actions Android ajoutent du délai

Un téléphone réel change entre le moment où l’agent planifie et le moment où il agit. Une notification peut recouvrir un bouton, une application peut revenir sur un écran différent, un compte peut demander une reconnexion, la batterie peut limiter une tâche en arrière-plan ou le réseau peut ralentir. Cette instabilité explique une grande partie du temps de réponse d’un agent mobile.

Un agent fiable doit donc observer l’état avant d’agir. Il doit vérifier quelle app est ouverte, si l’écran correspond à l’intention, si la cible est la bonne et si l’action est toujours disponible. Cette vérification ajoute du temps, mais elle évite l’exécution dans le mauvais état. Sans elle, un agent pourrait envoyer un message au mauvais destinataire ou confirmer une action dans une application inattendue.

La latence vient aussi de l’ambiguïté de cible. “Réponds à ce message” est clair pour l’utilisateur qui regarde l’écran, mais le système doit savoir quel message, dans quelle application, avec quel compte et quel niveau d’effet. Si l’agent ne peut pas établir cette cible, la bonne réponse n’est pas d’aller plus vite : c’est de demander une précision.

Accélérer un agent Android passe donc par de meilleurs états intermédiaires : montrer ce qui a été compris, préparer l’action sans l’exécuter trop tôt, puis vérifier le résultat. Une vérification visible peut sembler moins rapide qu’un clic silencieux, mais elle réduit les reprises coûteuses et protège les actions importantes.

Permissions, approbations et vitesse réelle

Les permissions et approbations sont souvent perçues comme des pauses. En réalité, elles distinguent un agent fiable d’un automate opaque. Android protège les données et actions sensibles par des permissions ; la documentation officielle sur les permissions Android explique que certaines capacités demandent un flux de consentement visible. FoneClaw ne doit pas contourner ces règles : il doit les demander au bon moment.

Il faut séparer deux couches. La permission Android répond à “l’app peut-elle accéder à cette capacité du téléphone ?”. L’approbation d’action répond à “l’utilisateur accepte-t-il cette action précise, avec cette cible et cet effet ?”. Lire un état visible, préparer un brouillon et envoyer un message n’ont pas le même poids. Une expérience rapide doit donc appliquer une politique adaptée au risque au lieu de demander la même validation pour tout.

D’après les informations FoneClaw actuellement disponibles, FoneClaw ajoute la gestion par outil, les remplacements d’approbation, la récupération de permissions et une meilleure gestion des échecs. Ces contrôles peuvent réduire la friction répétitive, parce que l’utilisateur ajuste les comportements par outil au lieu de gérer l’agent comme une autorité uniforme.

La performance gouvernée ne cherche pas à supprimer les vérifications. Elle cherche à rendre les pauses utiles : demander une permission quand elle manque, demander une confirmation quand l’effet est réel, puis afficher le résultat. Pour le cadre complet des décisions d’outil et traces d’action, Identité des agents IA : permissions, approbation par outil et piste d’audit montre pourquoi ces contrôles sont aussi des instruments de performance.

Self-Harness, traces d’exécution et récupération

La recherche Self-Harness: Autonomous Agentic Harness Optimization étudie un point important pour les agents : la qualité du harness, c’est-à-dire l’environnement qui organise outils, traces et retours d’exécution, peut influencer les performances au-delà du modèle de base. L’idée générale est qu’un agent peut apprendre de trajectoires d’exécution pour améliorer la façon dont il s’outille et se corrige.

Chez FoneClaw, nous lisons Self-Harness comme une recherche externe utile pour penser l’ingénierie des agents, pas comme le nom d’une fonction actuelle de l’application. La leçon produit est claire : les traces d’exécution doivent être assez propres pour expliquer une erreur. Quand l’agent sait quelle étape a échoué, quel outil était concerné, quelle permission manquait, quelle reprise a fonctionné et quel résultat est devenu visible, l’équipe peut réduire les répétitions lentes et renforcer les chemins fiables.

Sur téléphone, la récupération est une composante directe de la latence. Un échec silencieux oblige l’utilisateur à recommencer depuis le début. Un échec clair peut reprendre au bon endroit : permission manquante, application fermée, cible ambiguë, réseau instable, action non prise en charge. Les traces ne servent pas seulement à diagnostiquer ; elles guident les étapes de récupération, les tests de régression, les limites d’outil et le retour arrière quand une amélioration change trop le comportement.

Notre direction produit est gouvernée : workflows réutilisables, skills contrôlées, meilleure récupération, résultats visibles, versioning, tests et rollback lorsque l’exécution change. Le cadre Self-Harness reste distinct de FoneClaw tel qu’il est livré aujourd’hui, mais il confirme une conviction que nous appliquons déjà : un agent mobile progresse quand il apprend de causes d’échec observables, pas quand il modifie son comportement sans contrôle. Pour approfondir cette boucle de manière concrète, Agent mobile auto-amélioré : versions, tests et retour arrière détaille les garde-fous nécessaires.

Mesurer et accélérer un agent Android

Pour accélérer un agent Android, commencez par mesurer autrement qu’avec un seul chronomètre. Notez le temps jusqu’au premier retour, le temps jusqu’au plan, le temps jusqu’à l’outil, le nombre de reprises, le nombre de permissions demandées, le temps d’attente utilisateur et le temps jusqu’au résultat vérifié. Une tâche lente avec zéro erreur peut être préférable à une tâche rapide qui doit être relancée deux fois.

La première amélioration consiste à réduire l’ambiguïté. Une demande comme “résume les trois derniers e-mails non lus de ce compte” est plus rapide à traiter que “regarde mes mails”. La deuxième consiste à choisir un modèle adapté. Un modèle lourd peut être utile pour un plan complexe, mais un modèle plus rapide peut suffire pour une commande fréquente. Pour le routage entre modèles de phone agent, Kimi K3, DeepSeek V4 et GLM-5.2 : choisir le meilleur modèle pour phone agent garde le détail du choix modèle sur sa page dédiée.

La vitesse perçue s’améliore aussi avec un bon retour visuel. Dire rapidement “je vérifie l’application”, “j’attends la permission” ou “le brouillon est prêt” réduit l’impression de blocage. La performance d’un agent mobile n’est pas seulement un nombre ; c’est la capacité à avancer sans cacher ce qui se passe.

Comment FoneClaw raccourcit le chemin gouverné

FoneClaw raccourcit le chemin gouverné en séparant clairement le raisonnement, l’outil, la permission et le résultat. L’utilisateur peut commencer avec le modèle gratuit par défaut ou configurer un modèle compatible avec API Base URL et API Key. Le modèle planifie ; FoneClaw exécute les actions Android prises en charge et garde les étapes sensibles visibles.

La page Fonctionnalités FoneClaw présente plus de 100 outils intégrés pour travailler avec l’état du téléphone, les apps, les communications, les workflows et certains contrôles système. L’objectif n’est pas d’afficher un grand nombre, mais de réduire le détour entre une intention et l’action Android réellement supportée.

Un bon test de performance commence petit : ouvrir une app, lire un état visible, préparer un brouillon sans l’envoyer, ou guider une permission. Mesurez le premier retour, le nombre de reprises et le résultat vérifié. Ensuite seulement, testez une action à effet réel avec approbation. Cette méthode montre où se trouve la latence sans sacrifier la sécurité.

Notre position produit est simple : un agent mobile rapide n’est pas celui qui saute les contrôles, c’est celui qui évite les hésitations inutiles, demande les bonnes permissions au bon moment et récupère proprement quand Android change d’état. C’est ainsi que la latence des agents IA devient mesurable, améliorable et compatible avec la confiance utilisateur.