ARTEMIS de Google : tester vos parcours Android avant livraison
ARTEMIS de Google : tester vos parcours Android avant livraison
Votre application s’ouvre, les écrans sont propres, le bouton de commande est visible. Mais un client peut-il se connecter, retrouver un produit et renseigner son adresse sans rester bloqué ? Pour une PME qui livre à Paris, une erreur dans cet enchaînement peut suffire à perdre une commande. C’est là qu’ARTEMIS, le projet hébergé sous google/artemis, devient intéressant : il donne des mains Android à un assistant IA pour essayer un parcours, pas seulement commenter une capture.
Le premier usage à envisager est la recette : vérifier une application avant sa livraison ou après une modification. L’enjeu n’est pas de confier votre téléphone professionnel à un agent autonome. Il est d’obtenir un constat exploitable : ce qui était attendu, ce qui s’est réellement affiché et ce qu’une personne doit encore vérifier.
Ce qu’ARTEMIS permet de faire sur Android
Le dépôt officiel google/artemis présente un outil permettant aux assistants et aux suites de tests d’utiliser un téléphone comme un humain. Il peut lire l’interface, toucher un bouton, remplir un champ et passer d’une application à une autre. Il travaille avec un appareil Android dont le débogage USB est activé et autorisé, ou avec un émulateur, c’est-à-dire un appareil simulé.
Le projet documente notamment des connexions à Claude Code, Codex et Antigravity par MCP, un protocole qui relie un assistant à des outils. Cela ne signifie pas qu’une conversation Claude quelconque contrôle spontanément votre mobile : il faut une connexion et des accès configurés. L’assistant propose les actions ; ARTEMIS lui fournit les moyens d’interagir avec l’appareil.
Le terrain diffère donc de Cua Spaces, qui réserve un ordinateur séparé à l’agent. Ici, on cherche à éprouver une interface Android, avec son clavier, ses permissions et ses fenêtres surgissantes. Un parcours réussi dans un navigateur de bureau ne répond pas à cette question mobile.
Un test utile commence par une commande qu’on ne passera pas
Prenons une application de livraison fictive. Avant une nouvelle version, vous voulez vérifier qu’un utilisateur retrouve un produit et prépare une commande. Avec un compte test et des coordonnées fictives, le scénario peut être : se connecter, rechercher le produit, l’ajouter au panier, saisir une adresse de test dans la zone desservie, puis s’arrêter avant toute validation de commande.
Le résultat attendu doit être écrit avant l’essai. Par exemple : le panier conserve le bon produit, l’adresse est acceptée et les frais de livraison apparaissent. Dire simplement « vérifie que l’application fonctionne » laisse l’assistant décider lui-même de ce qui compte. Or votre problème commercial peut être précisément une adresse refusée sans explication.
Imaginons maintenant une observation : après la saisie, le clavier masque le bouton permettant de continuer. Ce n’est pas un résultat obtenu par SAY Digital, mais un exemple de constat à documenter. Une capture au point de blocage, la version de l’application et le modèle du téléphone aident le développeur à reproduire le problème. Si le parcours aboutit, on conserve aussi la preuve du panier et des frais affichés, sans en déduire que le paiement fonctionne.
Ce format évite un compte rendu trop vague. Vous pouvez demander une correction ciblée, puis rejouer le même scénario sur une nouvelle version. La valeur vient de cette comparaison, pas du nombre de gestes que l’agent sait effectuer.
Choisir le niveau de vérification, pas seulement la vitesse
Pour produire cette comparaison, le profil utilisé compte. Le README distingue Flash, une boucle rapide qui observe et agit, de Pro, qui organise un plan et davantage de contrôles. Flash ne fournit pas de vérification aux points de contrôle ni de rapport final intégré. Il ne faut donc pas vendre toute exécution ARTEMIS comme un audit documenté livré automatiquement.
Pro propose un vérificateur, appelé Checker, et une vérification finale configurables ; leur niveau peut aussi être désactivé. Un rapport écrit est optionnel. Pour votre recette, l’équipe doit donc préciser quels contrôles seront actifs et quelles preuves elle remettra. La présence d’un composant nommé « vérificateur » ne prouve pas que votre règle de livraison a été correctement formulée ou testée.
Les applications, les permissions, les blocages et le contexte influencent également la robustesse. Si une demande d’accès aux contacts apparaît pendant notre test de livraison, le compte rendu doit signaler l’interruption et conserver l’écran concerné, pas accorder ce droit pour avancer. L’équipe peut alors déterminer si cette demande vient de l’application ou si le scénario doit être adapté.
Le bouton est accessible ; l’agent a-t-il le droit de le toucher ?
Pro décrit aussi un contrôle technique avant les actions, pour vérifier la cible dans l’interface. Ce mécanisme n’est pas une validation humaine. Reconnaître correctement le bouton « Commander » ne donne pas l’autorisation de passer commande ; la même distinction vaut pour un achat, une publication ou un message envoyé à un client.
Dans notre scénario, l’arrêt avant validation fait donc partie du test. Une personne désignée examine les éléments recueillis et décide de la suite. Un compte de démonstration limite les conséquences ; il ne remplace pas la définition des actions interdites. Si une étape sensible doit réellement être testée, elle mérite un environnement adapté et une autorisation explicite, pas une extension improvisée de la mission.
Préparer les données et le budget avant le téléphone
Les écrans peuvent contenir des noms, des adresses et des messages. Le README indique que le petit service auxiliaire installé sur le téléphone reste local et n’envoie rien ailleurs. Cette précision concerne ce composant, pas toute la chaîne ARTEMIS : selon la configuration, les captures et leur contexte peuvent être transmis à des services IA distants pour interprétation. Il faut examiner ces flux avant d’utiliser des données clients.
Un téléphone dédié, un compte test et des données fictives simplifient ce premier périmètre. Le projet est sous licence Apache 2.0, mais cela ne rend pas l’opération entièrement gratuite : services IA, hébergement éventuel, préparation des scénarios et analyse des échecs entrent dans le coût complet. L’économie à mesurer est le temps d’une recette exploitable, corrections comprises.
Le bon pilote : un parcours Android et une décision de livraison
Le projet annonce plus de 99 % de réussite sur AndroidWorld, un benchmark couvrant plus de vingt applications et cent tâches à plusieurs étapes. C’est un résultat déclaré par le projet, pas une validation terrain réalisée par SAY Digital ni une garantie pour tous les téléphones. iOS figure dans la feuille de route, pas dans le périmètre disponible décrit ici.
Pour décider, choisissez un parcours Android qui compte pour votre activité, son résultat attendu et le responsable du feu vert. Demandez des preuves comparables et une liste des points non vérifiés. Vous pouvez présenter ce parcours à SAY Digital pour cadrer un premier essai : votre équipe saura alors quelle correction demander et sur quelle base autoriser la livraison.
