Benchmark d’agents Android : évaluer un agent téléphonique en 2026
Guide pratique pour construire un benchmark d’agents Android : benchmarks 2026, dimensions de test, métriques de fiabilité, approbations, récupération et matrice FoneClaw.
- Un bon benchmark d’agents Android mesure le résultat vérifié, le bon effet secondaire, la permission utilisée, l’approbation, la reprise et la qualité de trace, pas seulement une suite de gestes plausibles.
- Les benchmarks 2026 comme B-MoCA, MobileWorld, KnowU-Bench et PhoneHarness éclairent des écarts différents : configurations, longs workflows, personnalisation, consentement, surfaces d’action et effets observables.
- Le taux de réussite doit être complété par des métriques de processus : étapes partielles, mauvais effets, interventions humaines, récupération, latence, coût et audit.
- FoneClaw fournit une base actuelle pour définir des scénarios de test Android autour de l’écran visible, des réglages, des messages, des permissions, des approbations, de l’arrêt et de la continuité de tâche.
Ce qu’un benchmark d’agents Android doit mesurer
Un benchmark d’agents Android utile commence par une définition stricte de la réussite : l’agent doit comprendre l’objectif, exécuter l’action correcte, produire l’effet attendu sur le téléphone, respecter l’autorité accordée, montrer les étapes sensibles et récupérer proprement quand le contexte change. Un enchaînement de taps qui semble plausible ne suffit pas. Sur mobile, le résultat compte parce qu’un mauvais destinataire, un mauvais réglage ou une suppression involontaire produit un effet réel.
En construisant FoneClaw, nous avons appris à séparer trois questions. Premièrement, l’agent a-t-il compris l’intention ? Deuxièmement, a-t-il choisi la bonne surface d’action : interface visible, outil structuré, réglage Android ou reprise manuelle ? Troisièmement, l’effet observé correspond-il à ce que l’utilisateur voulait approuver ? Ces trois réponses doivent apparaître dans le score, car un agent peut réussir la navigation tout en échouant sur l’intention, ou comprendre l’intention tout en manquer de permission.
Notre grille d’évaluation vise donc le couple résultat vérifié et processus contrôlé. Elle mesure la réussite, mais aussi la retenue, l’approbation, le coût des reprises, la qualité de trace et la robustesse face aux variations de téléphone. Pour la boucle complète de test, versionnement et retour arrière d’un agent mobile, Agent mobile auto-amélioré : versions, tests et retour arrière approfondit la gouvernance du harnais de test.
Les benchmarks mobiles qui comptent en 2026
Les benchmarks agents IA 2026 ne forment pas un classement unique. Ils testent des angles différents, avec des environnements, tâches et métriques propres. Les comparer comme un seul leaderboard produirait une lecture fragile. Nous les utilisons plutôt comme une carte des écarts à couvrir dans une suite produit.
| Benchmark | Ce qu’il teste | Leçon pour un agent Android |
|---|---|---|
| B-MoCA | Le papier PMLR Benchmarking Mobile Device Control Agents across Diverse Configurations définit 131 tâches Android quotidiennes et randomise des configurations comme les dispositions d’interface et les langues. | Un agent doit généraliser au-delà d’un seul téléphone, d’une seule langue et d’un seul layout. Les tâches simples et complexes doivent être séparées. |
| MobileWorld | L’article ACL MobileWorld contient 201 tâches dans 20 applications, avec 27,8 étapes en moyenne et 62,2 % de tâches multi-apps dans son cadre. Il ajoute des catégories avec interaction utilisateur et MCP. | Les longs workflows multi-apps exposent la perte d’état, les erreurs de reprise et la difficulté à coordonner plusieurs surfaces d’action. |
| KnowU-Bench | Le préprint KnowU-Bench couvre 42 tâches GUI générales, 86 tâches personnalisées et 64 tâches proactives, avec profil utilisateur caché et journaux comportementaux. | La personnalisation se teste avec consentement, clarification et retenue après rejet, pas seulement avec une réponse plus personnelle. |
| PhoneHarness | Le préprint PhoneHarness combine actions GUI, CLI et outils côté hôte, note les effets secondaires observables et enregistre des traces d’exécution auditables. | Un benchmark mobile doit vérifier les effets produits, choisir la bonne surface d’action et garder une trace exploitable. |
Ces travaux indiquent une direction commune : l’évaluation des agents mobiles doit couvrir variation, durée, interaction humaine, permission, effet observable et trace. La découverte fiable des capacités mérite aussi un test dédié ; Agentic Resource Discovery : ai-catalog.json, registres et confiance pour agents mobiles traite ce sujet de confiance autour des ressources et outils.
Six dimensions pour une vraie suite de tests Android
Pour construire un test d’agents GUI Android exploitable, nous faisons varier six dimensions indépendamment. La première est la configuration : modèle de téléphone, version Android, langue, thème, taille d’affichage, permissions initiales et apps installées. Un agent qui réussit seulement sur un appareil propre ne suffit pas pour un usage réel.
La deuxième dimension est l’horizon de tâche. Un test en une étape mesure une capacité locale ; un workflow long mesure la mémoire de tâche, la planification et la reprise. La troisième est le nombre d’applications. Une tâche mono-app peut valider la navigation ; une tâche multi-app expose la coordination entre message, calendrier, réglage, carte ou fichier.
La quatrième dimension est la clarté de l’intention. Certaines consignes sont précises : « active Ne pas déranger pendant trente minutes ». D’autres demandent une clarification : « prépare mon téléphone pour la réunion ». Un bon agent sait poser une question courte quand l’objectif, la cible ou l’effet reste ambigu.
La cinquième dimension est la surface d’action : GUI visible, outil structuré, action système, plugin, commande hôte ou reprise manuelle. La sixième est le type d’effet : lecture seule, action réversible, action externe, action sensible ou opération destructive. Plus l’effet est fort, plus la suite doit tester l’approbation, l’arrêt, la trace et la récupération. La difficulté ne dépend donc pas seulement du nombre d’étapes ; elle dépend du risque, de l’ambiguïté et de l’autorité demandée.
Des métriques au-delà du taux de réussite
Le taux de réussite reste utile, mais il doit avoir un dénominateur clair : nombre de tâches, état initial, politique de retry, temps maximum, accès autorisés et critères de validation. Sans cela, deux scores peuvent mesurer des réalités différentes. PhoneHarness est intéressant ici parce qu’il met l’accent sur les effets secondaires observables et les traces d’exécution plutôt que sur une simple impression de progression.
Nous recommandons une fiche de métriques en six lignes. D’abord, le succès vérifié : l’état final correspond-il à l’objectif ? Ensuite, les checkpoints partiels : l’agent a-t-il trouvé la bonne app, le bon contact, le bon réglage ou le bon écran ? Troisièmement, les mauvais effets : message envoyé au mauvais destinataire, réglage modifié sans accord, donnée exposée ou action doublée.
Quatrièmement, mesurez la récupération : l’agent a-t-il expliqué l’erreur, demandé une permission, repris au bon endroit ou proposé une sortie propre ? Cinquièmement, suivez l’intervention humaine : clarification demandée, approbation, correction, reprise manuelle, annulation. Enfin, consignez latence, coût, consommation et qualité de trace. Un juge LLM peut aider à analyser une trace, mais l’état du téléphone et l’effet observé doivent rester la référence.
Pour structurer les traces liées à l’identité, aux permissions et aux décisions, Identité des agents IA : permissions, approbation par outil et piste d’audit donne le cadre d’audit qui complète ces métriques de fiabilité phone agent.
Tester approbations, permissions, retenue et arrêt
La sécurité doit être scorée comme une capacité fonctionnelle. Un agent qui réussit vite mais demande trop d’autorité, ignore un refus ou continue après un arrêt échoue sur une dimension essentielle. KnowU-Bench est utile sur ce point parce qu’il teste la clarification, le consentement proactif et la retenue après rejet dans un cadre de personnalisation.
Nous testons cinq comportements. Le premier est l’autorité minimale : l’agent demande-t-il uniquement la permission utile à la tâche ? Le deuxième est le bon moment d’approbation : l’utilisateur voit-il la cible et l’effet avant l’action sensible ? Le troisième est la clarification : l’agent pose-t-il une question quand le contexte personnel ou l’action reste incertain ?
Le quatrième comportement est la retenue. Après un refus, l’agent doit respecter la décision et proposer une alternative compatible, comme garder un brouillon ou ouvrir l’app. Le cinquième est l’arrêt. Un ordre d’arrêt doit interrompre la tâche, préserver ce qui est récupérable et laisser une trace compréhensible. Le refus seul ne suffit pas comme mesure de sécurité ; il faut noter la précision de la décision, le contexte et la reprise. Pour le design de l’approbation côté téléphone, Interface d’approbation des agents IA sur téléphone : confiance, contexte et reprise apporte le complément utile.
Comment nous évaluerions les tâches FoneClaw actuelles
La base actuelle de FoneClaw nous donne un socle concret pour définir une matrice d’évaluation produit. Elle apporte l’assistant flottant, l’attachement de l’écran actuel, la continuité de tâche, les approbations, l’arrêt, la récupération de permissions, des améliorations de fiabilité autour de Ne pas déranger, du volume, du mode réunion, des captures, et des actions rapides. La page Télécharger FoneClaw permet de tester cette base utilisateur.
Nous définirions d’abord des tests de lecture seule : lire l’écran visible attaché par l’utilisateur, résumer un état, identifier une app active, vérifier une permission, produire une réponse sans effet externe. Ensuite viennent les tests de contrôle réversible : régler un volume pris en charge, préparer Ne pas déranger pour une durée, ouvrir une app, lancer une capture quand le contexte le permet. Ces tests mesurent l’observation fraîche et le bon changement d’état.
La troisième classe concerne les effets externes : préparer un message, créer une tâche, mettre à jour un mémo, lancer une navigation ou préparer une action de calendrier. Ici, le score doit inclure le contenu proposé, la cible, l’approbation et la vérification. La quatrième classe teste les permissions : retirer une permission, lancer la tâche, vérifier que FoneClaw guide la récupération et reprend proprement.
La cinquième classe teste les interruptions : déplacer l’assistant flottant, passer de Home à l’overlay, changer l’écran courant, arrêter la tâche, puis reprendre. Les capacités actuelles, dont les 100+ outils intégrés, sont présentées sur Fonctionnalités FoneClaw. Ce guide définit une méthode d’évaluation et ne publie pas de score FoneClaw. Pour un scénario utilisateur lié aux permissions et à l’état du téléphone, Bilan de santé Android avec IA : permissions, accès sensibles et applications masquées donne un exemple concret.
Construire un protocole de benchmark reproductible
Un protocole reproductible commence par figer l’environnement : appareil, version Android, langue, taille d’écran, thème, apps, comptes de test, permissions initiales, état réseau, version de l’agent, modèle configuré et politique de retry. Ensuite, chaque tâche doit définir un état initial, une consigne utilisateur, un résultat attendu, les effets interdits, les approbations requises et la méthode de vérification.
- Figer l’environnement et documenter les versions.
- Décrire l’état initial du téléphone et des apps.
- Définir l’objectif, les effets attendus et les effets interdits.
- Faire varier une dimension à la fois : langue, layout, permission, interruption ou app.
- Enregistrer actions, approbations, refus, retries, latence et coût.
- Vérifier l’effet sur le téléphone avec une preuve observable.
- Classer la récupération : réussite, reprise manuelle, arrêt propre, erreur expliquée ou mauvais effet.
La fiche de score doit rester lisible : succès vérifié, checkpoints, mauvais effets, approbation correcte, permission correcte, reprise, intervention humaine, trace et coût. Un premier test réversible peut suffire pour démarrer : ouvrir une app, lire l’écran courant, ajuster un volume pris en charge, puis revenir à l’état initial. Le but n’est pas de produire un chiffre flatteur ; c’est de créer une suite que l’équipe peut rejouer à chaque changement de modèle, d’outil, de permission ou d’interface.