Google, créateur d’Android, voit Gemini finir cinquième sur son propre benchmark

Le créateur d’Android termine seulement cinquième sur un test conçu pour évaluer les agents capables de développer des applications Android. La mise à jour d’Android Bench place Claude Fable 5 en tête, tandis que les modèles Gemini de Google peinent à convertir leur avantage industriel en résultats convaincants.

Android Bench place Google derrière ses rivaux

La nouvelle version d’Android Bench évalue désormais 100 tâches Android réalisées par des agents d’intelligence artificielle. Le principe consiste à mesurer la capacité d’un modèle à comprendre une consigne, modifier ou créer du code, utiliser les outils de développement et produire une application fonctionnelle.

Sur cette série, Claude Fable 5 obtient un score de 84,5 %, le meilleur résultat du classement. Plusieurs modèles d’OpenAI et d’Anthropic se positionnent également devant Gemini 3.1 Pro, qui n’arrive qu’en cinquième position.

Le résultat est particulièrement embarrassant pour Google. Android constitue l’un de ses principaux actifs logiciels, et l’entreprise dispose d’un accès direct à sa documentation, à ses outils de développement et à une grande quantité de code lié à l’écosystème mobile. Cette proximité ne suffit pourtant pas à placer son modèle phare au sommet d’un benchmark consacré précisément à cet environnement.

Le classement ne mesure pas seulement la capacité à générer quelques lignes de code. Les tâches évaluent des séquences de travail plus longues, proches de celles qu’exécute un agent de développement : interpréter une demande, naviguer dans un projet, modifier plusieurs fichiers, lancer des tests et corriger les erreurs rencontrées.

Un score qui expose les limites des agents généralistes

La cinquième place de Gemini 3.1 Pro ne signifie pas que le modèle est incapable de programmer pour Android. Elle indique plutôt qu’il rencontre davantage de difficultés que ses concurrents sur l’ensemble du parcours imposé par Android Bench.

Dans ce type d’évaluation, une erreur mineure peut avoir des conséquences importantes. Une interface qui se compile mais ne répond pas correctement, un test qui échoue après une modification ou une dépendance mal configurée peuvent faire perdre une tâche complète. La performance dépend donc autant de la robustesse du raisonnement que de la capacité de l’agent à vérifier son travail et à récupérer après un échec.

Cette distinction est essentielle à mesure que les éditeurs vendent des outils de développement agentique. Un modèle peut être performant sur des exercices isolés de génération de code et se montrer moins fiable lorsqu’il doit maintenir un contexte long, manipuler un dépôt complet ou enchaîner plusieurs actions avec des outils externes.

Huit modèles supplémentaires et une mesure du coût réel

La mise à jour introduit huit nouveaux modèles et élargit l’analyse au-delà du simple taux de réussite. Android Bench publie désormais des métriques de coût et d’efficacité, afin d’évaluer les ressources nécessaires pour obtenir les résultats.

Cette évolution répond à une faiblesse fréquente des benchmarks de programmation : ils indiquent quel modèle réussit le plus de tâches, mais rarement combien de temps et d’argent sont nécessaires pour y parvenir. Or un agent qui multiplie les appels à une API, relance plusieurs fois les tests et produit de longues sorties peut devenir coûteux à déployer, même avec un bon score final.

Le cas de Gemini 3.5 Flash est révélateur. Le modèle affiche le coût d’exécution le plus élevé du classement, à environ 165 dollars et 28 heures pour une série complète de tests. Rapporté mécaniquement aux 100 tâches, cela représente environ 1,65 dollar et 16,8 minutes par tâche, même si les opérations peuvent être parallélisées et que cette moyenne ne décrit pas chaque scénario.

Le positionnement de Gemini 3.5 Flash rappelle qu’un modèle présenté comme plus rapide ou plus léger n’est pas nécessairement plus économique dans un environnement d’agents. Le prix final dépend du nombre de requêtes, de la longueur du contexte, des appels aux outils, des tentatives de correction et du temps passé à exécuter les tests. Une architecture qui déclenche de nombreuses boucles de vérification peut rapidement effacer l’avantage tarifaire théorique d’un modèle.

Une comparaison à lire avec prudence

Les coûts publiés par Android Bench ne constituent pas une facture universelle. Ils varient selon les tarifs d’API retenus, la configuration de l’environnement, les limites de débit et les stratégies d’orchestration utilisées par l’agent. Un même modèle peut afficher une économie différente avec un meilleur système de planification ou une politique de reprise plus efficace.

Le classement reste néanmoins utile, car il rapproche la mesure de la réalité opérationnelle. Dans une entreprise, le modèle le plus intéressant n’est pas forcément celui qui obtient le meilleur score brut, mais celui qui réussit suffisamment de tâches avec un délai et une facture compatibles avec la production.

Un avertissement pour la stratégie logicielle de Google

Google pousse depuis plusieurs mois ses outils vers le développement assisté par des agents capables de planifier et d’exécuter des tâches complexes. Gemini est appelé à intervenir dans la génération de code, le débogage, la création d’interfaces et l’automatisation de workflows. Cette orientation augmente la portée symbolique du résultat : l’entreprise ne se contente pas de perdre un test généraliste, elle recule sur un terrain directement lié à son propre écosystème.

L’écart peut aussi fragiliser le discours commercial autour de Gemini. La puissance d’un modèle ne se résume pas à ses performances sur des tests de connaissances ou de raisonnement. Pour les développeurs Android, la fiabilité sur des projets concrets, la capacité à respecter les conventions de la plateforme et le coût des itérations comptent davantage qu’un score abstrait.

Cela ne condamne pas la stratégie de Google. Les modèles évoluent rapidement, et un benchmark de 100 tâches ne couvre ni toutes les applications Android ni tous les profils de développement. Il ne mesure pas non plus la qualité de l’expérience intégrée aux outils Google, l’accès aux dépôts privés ou la capacité à exploiter des composants propriétaires.

Mais le signal reste difficile à écarter. Si Google veut faire de Gemini un assistant central du développement logiciel, ses modèles devront progresser sur les tâches longues, les corrections autonomes et la maîtrise des coûts, pas seulement sur la génération initiale de code.

Le prochain test sera celui de la fiabilité en production

La prochaine étape sera de vérifier si l’écart observé par Android Bench se retrouve dans des projets plus vastes et persistants : applications comportant plusieurs modules, dépendances externes, tests d’interface et corrections successives. Il faudra également mesurer le taux d’intervention humaine, un indicateur absent d’un simple score de réussite.

Pour Google, l’objectif est concret : faire remonter Gemini 3.1 Pro dans le classement tout en réduisant la facture et le délai d’exécution de ses agents. Tant qu’un modèle maison reste cinquième sur un test Android et qu’un autre modèle Gemini coûte environ 165 dollars pour 28 heures d’évaluation, la promesse d’un développement logiciel automatisé reste davantage un chantier de fiabilité qu’un produit arrivé à maturité.

Source : Ars Technica.