Frameworks open source pour agents mobiles : Open-AutoGLM, Mobilerun ou mobile-use

Choisir selon le travail à accomplir

Les meilleurs frameworks open source pour agents mobiles ne forment pas un classement universel. Le bon choix dépend d’abord du téléphone disponible, du modèle que vous comptez utiliser, de votre tolérance à l’infrastructure et de la manière dont vous voulez observer les erreurs. Avant une mise à jour, vérifiez aussi que la sélection de l’appareil, les services auxiliaires et les fichiers de configuration correspondent encore au comportement documenté.

Cette sélection ne revendique pas de taux de réussite mesuré. Elle sert à choisir une voie à évaluer. Un framework fournit l’environnement d’exécution et l’exécuteur ; le modèle fournit le raisonnement ; le téléphone, l’émulateur ou le cloud fournit l’environnement réel où les actions réussissent ou échouent.

Comparer installation, exécution, modèles et licence

Avant de choisir entre Open-AutoGLM, Mobilerun ou le framework mobile-use, séparez quatre couches : l’environnement d’exécution, l’inférence, la connexion au téléphone et l’observabilité. Un agent lancé sur votre machine peut appeler un modèle distant ; un modèle auto-hébergé ne signifie pas que ses poids tournent sur le téléphone.

Open source ne supprime pas les coûts. Les appels de modèle, le serveur d’inférence, les appareils connectés, les téléphones cloud, les outils de trace, les mises à jour Android et la maintenance des scripts restent à prévoir. Vérifiez la licence du dépôt à la révision retenue : elle ne couvre pas automatiquement les modèles, services ou dépendances que vous branchez dessus.

Quand Open-AutoGLM convient le mieux

Open-AutoGLM est un point de départ adapté si votre sujet principal est l’agent visuel de téléphone Android : lire l’écran, décider de la prochaine action et l’exécuter via ADB. Le dépôt documente aussi HDC pour HarmonyOS, mais pour Android le cœur pratique reste la préparation de l’appareil, le débogage USB et l’environnement de contrôle.

Son intérêt tient à la séparation claire entre framework, modèle et appareil. Le projet peut utiliser un modèle hébergé ou une inférence servie par vos soins ; une carte GPU locale n’est donc pas obligatoire pour la voie par API, mais elle peut devenir nécessaire si vous auto-hébergez. Le dépôt décrit également des confirmations pour opérations sensibles et une reprise humaine pour connexion ou captcha.

Choisissez Open-AutoGLM si vous acceptez de gérer l’appareil et les dépendances de test, et si votre équipe veut comprendre le comportement d’un agent de téléphone au niveau de l’écran. Ne l’adoptez pas en supposant une réussite universelle sur toutes les apps : chaque application, permission et état d’écran doit être évalué.

Déploiement local ou hébergement managé avec Mobilerun

Mobilerun, anciennement DroidRun, convient lorsque vous voulez un framework de contrôle mobile pilotable par CLI ou Python, avec arbre d’accessibilité, captures d’écran, sélection du fournisseur de modèle et résultats structurés. Le dépôt est sous licence MIT et documente Android via ADB, débogage USB et service Portal.

La distinction importante est entre Mobilerun Framework et Mobilerun Cloud. Le Framework fait tourner l’agent sur votre machine et se connecte à vos appareils préparés. Le Cloud ajoute une couche managée avec téléphones locaux connectés, téléphones virtuels ou physiques hébergés et parcours API. Les dépendances, les coûts et le contrôle ne sont pas identiques.

La publication du 14 octobre 2026 en UTC, soit le 15 octobre en Chine précise la sélection pour mobilerun run : -d prime sur ANDROID_SERIAL, puis seul l’unique appareil en ligne peut être choisi automatiquement. Plusieurs appareils sans cible explicite provoquent une erreur, au lieu de sélectionner le premier. Inspectez donc la liste connectée avant chaque lancement.

FastAgent ne traite que le premier bloc function_calls d’une réponse ; les suivants sont ignorés. Un appel échoué fait sauter le reste du bloc. Portal peut également réactiver son service d’accessibilité et restaurer son clavier pendant l’exécution : pour révoquer volontairement l’accès, arrêtez l’agent puis contrôlez l’état réel. Ne contournez pas Play Protect.

La publication du 5 octobre sur les fiches d’applications impose app_cards_dir/android/app_cards.json et app_cards_dir/ios/app_cards.json. Le fichier directement placé dans app_cards_dir est ignoré. Migrez les fiches vers le bon dossier et vérifiez les identifiants Android ou iOS. La préparation installe la version Portal prévue pour Mobilerun, met à niveau une ancienne installation et conserve une version plus récente.

Les traces Arize Phoenix ou Langfuse et les trajectoires sauvegardées aident au diagnostic. Les évolutions de compatibilité des arbres d’interface du SDK Cloud et l’absence de nouvelle tentative pour certaines actions de toucher ou de saisie doivent aussi être intégrées à votre maintenance, sans en déduire un succès universel. Pour iOS, traitez Portal comme une configuration spécifique, pas comme une parité automatique avec Android.

Quand Minitap mobile-use est pertinent

Minitap mobile-use vise l’automatisation d’interfaces mobiles en langage naturel, avec fournisseurs LLM configurables et extraction structurée. Il est pertinent si vous voulez décrire une tâche mobile, récupérer un résultat structuré et garder une architecture relativement lisible pour des scénarios contrôlés.

Le README présente Android avec ADB pour appareils physiques ou émulateurs. Le démarrage Docker rapide est indiqué comme Android uniquement. Pour iOS, le point à retenir est précis : la section de configuration manuelle liste les simulateurs iOS sur macOS et indique que les appareils iOS physiques ne sont pas encore pris en charge. Toute formulation marketing plus large doit donc être vérifiée contre l’environnement réel que vous comptez utiliser.

mobile-use est moins adapté aux apps où l’arbre d’accessibilité ne donne pas assez d’information, notamment certains jeux ou interfaces très personnalisées. Vérifiez aussi le fournisseur de modèle, la licence Apache-2.0 du dépôt et le coût d’exécution des tâches répétées avant de l’intégrer dans un parcours produit.

Tester une tâche réversible et inspecter les échecs

Commencez par une tâche sans écriture : ouvrir la calculatrice déjà installée sur un téléphone de test qui vous appartient, puis confirmer son écran. Cette comparaison proposée s’appuie sur les prérequis documentés ; ce n’est pas un essai que nous aurions réalisé. Elle ne doit comporter ni message envoyé ni paiement.

1. Listez les appareils connectés, par exemple avec adb devices pour la voie Android ADB, et identifiez le téléphone voulu.
2. Dans Mobilerun, sélectionnez délibérément cette cible avec -d ou ANDROID_SERIAL. Pour les autres frameworks, suivez leur configuration documentée.
3. Notez le modèle et le fournisseur utilisés, puis vérifiez les services et permissions réellement actifs.
4. Demandez uniquement l’ouverture de l’application choisie, sans saisir ni modifier de données.
5. Conservez les captures, arbres d’accessibilité, journaux et traces disponibles.
6. Arrêtez immédiatement si le mauvais appareil réagit ou si une étape échoue.
7. Vérifiez l’écran final sur le téléphone cible, pas seulement la réponse du modèle.

Après un échec, inspectez ce qui a déjà eu lieu et corrigez la cause avant de relancer : écran inattendu, élément inaccessible, modèle confus, permission manquante ou délai dépassé. L’arrêt des appels suivants dans Mobilerun ne rétablit pas l’état précédent. Il ne fournit ni transaction complète ni garantie qu’une répétition sera sans effet indésirable.

Pour formaliser cette évaluation, le guide Benchmark d’agents Android : évaluer un agent téléphonique en 2026 propose une grille plus complète sans transformer une démonstration en classement artificiel.

Si votre question porte plutôt sur le modèle à brancher derrière le framework, séparez cette décision. Le guide Modèles IA pour agents Android : choisir selon la tâche et l’API traite les modèles, les appels d’outils et les coûts sans les confondre avec l’exécuteur mobile.

Choisir plutôt une voie Android prête à l’emploi

Un framework open source est pertinent si vous voulez développer, instrumenter et maintenir l’agent mobile vous-même. Si votre besoin est d’utiliser un agent Android sans assembler ADB, Portal, WebDriverAgent, appareils cloud, traces et serveurs de modèle, une voie produit peut être plus adaptée.

FoneClaw est notre application Android prête à l’emploi, distincte d’un framework de développement open source. Le modèle configuré comprend et planifie ; les outils activés exécutent les actions prises en charge selon les permissions Android et la politique d’approbation applicable. Cela ne signifie ni contrôle universel des applications ni confirmation systématique à chaque action.

Cette distinction compte : un framework donne de la liberté d’ingénierie ; FoneClaw propose une voie utilisateur pour les tâches Android compatibles. Nous ne présentons pas ici d’intégration native avec les trois frameworks. Pour comprendre les garde-fous autour de l’intention, de la confirmation et du résultat visible, consultez Contrôler un téléphone Android avec un agent IA : intention, confirmation et vérification. La page fonctionnalités FoneClaw présente les capacités disponibles sans les confondre avec une pile open source à maintenir soi-même.