L'ARTEMIS de Google met l'automatisation Android en open source : ce que recouvre réellement l'affirmation de 99 % sur AndroidWorld

Le tout dernier commit sur google/artemis n'est pas une fonctionnalité. C'est une mention de crédit — « fix: complete README and relevant file headers per Apache 2.0 requirements », poussé le 12 septembre 2026, trois jours après que Minitap a publié un article intitulé J'attendais mieux de Google. ARTEMIS de Google est le nouvel agent d'automatisation Android open source de l'entreprise : il transforme une instruction en langage courant en appuis, balayages, saisies et vérifications réels sur un appareil Android physique ou un émulateur, capture les journaux et les captures d'écran tout au long du processus, et rapporte un taux d'achèvement des tâches supérieur à 99 % sur le benchmark AndroidWorld de Google Research. Il a été publié en août par l'équipe Pixel Test Engineering Fusion de Google sous licence Apache 2.0, et il vaut vraiment votre après-midi. Il est aussi, depuis la mi-septembre, au centre d'une bataille d'attribution open source qui en dit plus sur la façon dont les agents mobiles sont construits que le chiffre du benchmark. Les deux histoires sont vraies. Une seule d'entre elles explique pourquoi le dernier commit du dépôt était une correction de licence.

Ce qui a réellement été livré

ARTEMIS n'est pas un modèle et pas un wrapper de chatbot. C'est un harnais de contrôle — un système Python 3.12+ qui se situe entre un modèle vision-langage et un combiné réel. Vous lui donnez une tâche en anglais ; il observe l'écran, décide une action, l'exécute via ADB, vérifie ce qui s'est passé et continue. Cinq choses étaient fournies :

• Une CLI et un SDK Python. code>./start.sh/code> initialise ADB, scrcpy, FFmpeg et l’environnement uv ; code>uv run artemis run "…" --profile flash/code> exécute une tâche sans interface ; le code>artemis-client/code> SDK encapsule le même appel pour pytest et la CI, en renvoyant code>succeeded/code>, code>status/code>, code>device_serial/code> et un code>trace_id/code> que vous pourrez suivre plus tard.

• Une console web. code>uv run artemis ui/code> sert une console de test visuelle sur code>localhost:8000/code> où vous observez la boucle étape par étape.

• Un serveur MCP natif. C'est ce qui lui a permis de se répandre. code>uv run artemis mcp --install all/code> expose code>mobile_run_task/code>, code>mobile_manage_task/code>, code>mobile_get_device_state/code>, code>mobile_inspect_trace/code> et code>mobile_diagnose/code> à n'importe quel assistant compatible MCP, avec des chemins d'installation de premier ordre pour Antigravity, Claude Code et Codex, ainsi que la génération de configuration pour Cursor, Windsurf, VS Code et Cline/Roo. Depuis un assistant auquel le serveur est connecté, « compiler l'APK, l'installer, ouvrir les paramètres, activer le mode avion, capturer le résultat » cesse d'être un script pour devenir une phrase.

• Un utilitaire d’accessibilité.La première tâche installe l’Artemis Accessibility Helper, qui lit la disposition de l’écran sans maintenir la connexion UiAutomation — délibérément, afin que les autres outils basés sur UiAutomator présents sur le même appareil ne soient pas supprimés. Il s’exécute sur le téléphone et n’envoie rien à l’extérieur, et se rabat sur UIAutomator2 lorsqu’il ne peut pas s’attacher, le repli étant signalé dans la chronologie des tâches.

• Capture des journaux et des traces.Les piles d'appels de plantage, les captures d'écran d'images clés et un rapport de diagnostic sont collectés automatiquement plutôt que rajoutés par l'appelant — la raison pour laquelle il est utilisable comme suite de tests de non-régression et non comme une simple démo.

Flash et Pro sont deux produits différents qui partagent un même nom.

La chose la plus importante à comprendre avant de comparer ARTEMIS à quoi que ce soit, c'est que code>--profile flash/code> et code>--profile pro/code> ne sont pas un réglage de vitesse sur un seul agent. Ce sont deux agents.

• Flash — une boucle réactive d'observation et d'action à environ 3 à 5 secondes par étape, sans plan, sans notes, sans vérification de sécurité avant exécution, sans vérification de point de contrôle, sans rapport final et sans shell ADB. La boucle est illimitée par défaut parce que l'historique est compressé plutôt qu'accumulé.

• Pro — un graphe multi-agents à environ 15–40 secondes par étape, construit à partir d'un Planner qui maintient un plan Markdown vivant avec des éléments explicites code>verify/code> et code>assert/code>, d'un Operator disposant de l'ensemble complet des outils, et d'un Checker en lecture seule qui valide les points de contrôle et effectue une revue de sortie. code>--verification-level/code> accepte code>off/code>, code>final/code> (la valeur par défaut), code>checkpoints/code> ou code>strict/code>.

C'est une différence de latence d'un facteur cinq à dix pour la même description de tâche, et c'est la différence entre un smoke test et une exécution exploratoire de plus de 100 étapes. Selon la propre présentation de Google, Pro est destiné au travail à long horizon et à la surveillance continue code>[Loop:continuous]/code> ; Flash est destiné aux tâches d'interface utilisateur routinières et déterministes. Si vous lisez un avis qui cite des durées d'étapes sans vous dire quel profil les a produites, il ne vous dit rien.

La stratégie de positionnement est la véritable ingénierie.

La plupart des frameworks d’automatisation mobile échouent sur les sélecteurs. ARTEMIS est conçu avec une approche dynamique prioritaire : lorsqu’un index d’éléments d’accessibilité existe, il l’utilise ; lorsqu’il n’existe pas — un Canvas, une surface Compose, une vue Flutter, un jeu — il se rabat sur les coordonnées et la vision. Il n’y a aucune couche XPath à maintenir et aucun ID susceptible de devenir obsolète, ce qui importe, car les applications que vous avez le plus intérêt à tester sont celles qui publient de nouvelles versions chaque semaine.

Le profil Pro ajoute un filet de sécurité : chaque action passe par un contrôle de pré-exécution, d'abord en XML avec un repli par pixels, qui intercepte la popup système sur le point d'avaler votre appui. Les échecs ouvrent un « incident d'exécution » qui reste dans le contexte jusqu'à ce qu'un succès ultérieur le résolve, plutôt que de lancer un agent de réparation distinct. Les longues sessions sont compressées — les anciennes captures d'écran deviennent des résumés visuels, les étapes terminées sont regroupées en époques mémorisables que code>search_history/code> et code>replay_steps/code> peuvent rappeler — ce qui évite qu'un contexte de 100 étapes devienne inabordable.

99,1 % dans le classement, et la mise en garde que les publications de lancement omettent

L’affirmation phare d’ARTEMIS est un taux d’achèvement de plus de 99 % sur AndroidWorld, le benchmark de Google Research composé de 116 tâches réalistes réparties sur une vingtaine d’applications, évalué en Pass@1. Au 11 septembre 2026, le classement AndroidWorld plaçait ARTEMIS à 99,1 %, contre 91,4 % pour mobile-use de Minitap, la performance humaine étant de 80 %. Dans ce tableau, c’est l’état de l’art parmi les résultats rapportés publiquement.

Deux éléments doivent accompagner ce chiffre. Premièrement, le classement AndroidWorld ne vérifie explicitement pas les soumissions de manière indépendante — chaque chiffre qui y figure, y compris celui d’ARTEMIS, est autodéclaré par l’équipe qui l’a produit, et une analyse de robustesse a montré que les seules variations de tâches peuvent faire varier substantiellement le score d’un agent. Considérez 99,1 % comme une solide affirmation de fournisseur sur un benchmark public et vérifiable, ce qui est une chose réelle et utile, et non comme une mesure auditée, ce qu’elle n’est pas. Deuxièmement, la forme de la comparaison importe : le benchmark est un ensemble de tâches fixe, et le graphique comparatif publié d’ARTEMIS aurait omis mobile-use tout en incluant d’autres entrées. Un benchmark où le résultat antérieur le plus fort est absent du graphique constitue une affirmation plus faible que ne le suggère le pourcentage brut.

Le différend, qui constitue la véritable actualité ce mois-ci

Sur son blog et dans un ticket public sur le dépôt, Minitap — une start-up de tests mobiles dont le projet open source mobile-use fait le même travail pour Android et iOS — a allégué que 228 des 229 fichiers d'ARTEMIS étaient identiques aux siens. Les détails qu'elle a publiés sont d'une précision inhabituelle : du code de connexion d'appareils Android correspondant à son implémentation, la réutilisation mot pour mot d'instructions appartenant à un agent nommé « Hopper », et un exemple WhatsApp qui envoie des messages du Nouvel An à Alice, Bob et Charlie, reproduit avec les mêmes commentaires, les mêmes étapes de nettoyage et le même bug. Elle allègue en outre qu'un fichier portant les noms de trois auteurs de Minitap — Pierre-Louis Favreau, Jean-Pierre Lo et Nicolas Dehandschoewercker — a été remplacé par un force-push en août, avec les noms supprimés et un autre auteur substitué.

La question de la licence n'a rien d'obscur. mobile-use est sous Apache 2.0, et Apache 2.0 autorise précisément ce type de réutilisation — commerciale, dérivée, fermée — à condition de conserver les mentions de copyright et d'indiquer ce que vous avez modifié. Ce qu'elle n'autorise pas, c'est de distribuer le code avec ces mentions supprimées. Depuis que les allégations ont été rendues publiques, le dépôt affiche la ligne « This project includes source code developed by Minitap, Inc. » ainsi que des liens vers minitap-ai/mobile-use, et le commit du 12 septembre qui achève cette attribution est, au moment de la rédaction, la modification la plus récente sur code>main/code>. Minitap n'a publié aucune preuve reliant la suppression de l'attribution à ses propres soumissions au classement restées sans réponse, et Google n'a pas publié de réponse publique détaillée. La lecture honnête : le code partagé est légitime et a toujours été autorisé ; les formalités, quant à elles, ne l'étaient pas pendant un temps, et elles ont désormais été corrigées.

La partie que personne ne chiffre : la facture du modèle

ARTEMIS est livré avec un badge indiquant « Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL », et son fichier de configuration se trouve à code>config/artemis.jsonc/code>, où vous le faites pointer vers le modèle de vision pour lequel vous disposez d'identifiants. Rien dans ce fichier n'est destiné à l'utilisateur tant que vous n'exécutez pas Pro sur un workflow réel et que vous ne constatez pas ce que coûte réellement un agent de longue durée.

Faites le calcul sur les profils. Une exécution Pro de 100 étapes à 15–40 secondes par étape, c'est quelque part entre 25 minutes et un peu plus d'une heure de temps d'horloge, et chacune de ces étapes correspond à au moins un appel à un modèle de vision transportant une capture d'écran. Flash coûte moins cher par étape, mais boucle plus agressivement, et comme son contexte est compressé plutôt que tronqué, il dépassera allègrement la limite de tours que vous pensiez être un plafond. Quel que soit le profil que vous choisissez, c'est le modèle qui est le poste de coût qui évolue avec votre suite de tests, pas la licence ni le matériel.

C'est ici qu'une couche de routage cesse d'être une abstraction. Un modèle de vision pilotant une longue session Android est une charge de travail avec deux propriétés délicates : elle est de longue durée et elle ne tolère pas qu'un fournisseur ait un hoquet au milieu de l'étape 74, car le contexte de l'exécution se trouve sur le point de terminaison de ce fournisseur. Pointer ARTEMIS vers une seule URL de base compatible OpenAI et laisser notre basculement déplacer l'exécution vers un autre fournisseur du même modèle, c'est la différence entre un test instable et un après-midi perdu. Qwen3.8-Flash est le candidat intéressant à essayer en premier — un MoE multimodal à 6B actifs avec un contexte de 1M de tokens, répertorié dans notre catalogue à 0,15 $ par million de tokens d'entrée et 0,47 $ par million de tokens de sortie, avec des lectures de cache à 0,018 $ et des écritures de cache à 0,230 $. Ce prix de lecture du cache est celui qui compte ici, car une exécution Pro relit un contexte croissant à chaque étape.

Toutefois, soyez précis sur ce que cela signifie : Qwen3.8-Flash ne figure pas dans la liste des backends testés d’ARTEMIS, qui mentionne Gemini, Claude, GPT-4o et Qwen-VL. C’est un modèle qui pourrait plausiblement convenir au harnais, et le harnais est explicitement conçu pour en accepter un. Personne n’a publié de benchmark de ce couplage, et vous devez considérer toute personne qui prétend qu’il en existe un comme l’ayant inventé.

La feuille de route, et quelle part de celle-ci est porteuse

Quatre éléments figurent sur la feuille de route publiée : une intégration Android Studio avec débogage dans l’éditeur, enregistrement de tests et contrôle des appareils ; la prise en charge d’iOS ; des modèles vision-langage légers embarqués pour un travail à faible latence et privilégiant la confidentialité ; et une interaction vocale duplex en temps réel.

Le premier est celui auquel il faut croire, car c'est l'artefact naturel suivant d'une équipe d'ingénierie des tests Pixel et il ne comporte aucun risque de recherche associé — l'agent pilote déjà un appareil, il a juste besoin d'un panneau dans l'IDE. iOS est une affirmation bien plus ambitieuse qu'il n'y paraît de l'extérieur : toute la stratégie de localisation repose sur le service d'accessibilité d'Android, et iOS n'a pas de surface équivalente avec le même modèle d'autorisations, alors attendez-vous à une réécriture de la couche de perception plutôt qu'à un portage. L'élément VLM embarqué est celui qu'il faut surveiller de près, car c'est le seul élément de la liste qui supprimerait le coût d'API par étape qui domine actuellement une grande suite de tests — et il implique un petit modèle rapide, doté de capacités de vision, capable de maintenir la cohérence d'une tâche d'interface utilisateur, ce qui est une cible bien plus étroite qu'« un petit modèle doué pour l'utilisation d'outils ».

Quoi en faire cette semaine

Clonez-le, exécutez code>./start.sh/code> contre un émulateur, et confiez à Flash une tâche que votre suite Espresso existante couvre. Cela vous dira en moins d'une heure si le localisateur dynamic-first survit aux surfaces Compose de votre application, ce qui est la question qui détermine si le reste a la moindre importance. Ensuite, exécutez la même tâche sur Pro et comparez les deux traces — l'écart entre 3–5 et 15–40 secondes par étape est là où se situe votre budget, et vous ne pouvez pas raisonner sur le coût d'ARTEMIS sans cela.

Pendant que vous lisez le code, lisez les en-têtes. Le commit du 12 septembre qui a ajouté l’attribution Minitap est le plus récent du dépôt, ce qui signifie que les en-têtes de fichier que vous lisez ont quatre jours et que le projet est activement réparé en public. Ce n’est pas une raison pour l’éviter. C’est une raison de vérifier quelle version de l’histoire vous tenez avant de citer un taux de réussite dans une diapositive.

Pointer ARTEMIS vers une seule URL de base compatible OpenAI et laisser notre bascule automatique déplacer l'exécution vers un autre fournisseur du même modèle : c'est la différence entre un test instable et un après-midi perdu.