À mesure que les assistants IA s’installent dans Android Studio et les workflows GitHub, une question devient embarrassante : quel modèle aide réellement, et lequel se contente de produire du code plausible mais fragile ?
Avec Android Bench, Google tente de remettre un peu de science dans un marché saturé de promesses, en évaluant les LLMs sur des tâches Android proches du terrain : issues, pull requests, correctifs qui doivent build, passer les tests et résoudre le problème.
Un benchmark pensé comme un PR en conditions réelles
Android Bench n’est pas une collection de “katas” abstraits. Google explique que le benchmark présente aux modèles des issues et pull requests tirées de projets open source (publics) et leur demande de reproduire le correctif — avec une vérification qui ne s’arrête pas à la forme. Le critère central : est-ce que le patch règle effectivement le bug / la demande ?
Point important : pour cette première version, Google dit vouloir mesurer la performance “pure” du modèle, sans se concentrer sur l’agentique (orchestration d’outils, navigation IDE, etc.). C’est une manière de tester le “cerveau” avant de juger la “boîte à outils”.
Les premiers résultats : 16% à 72% de réussite, un écart qui pique
Les scores publiés montrent un fossé net entre modèles : de 16% à 72% de tâches réussies selon Google. Sur le leaderboard, Google affiche notamment :
- Gemini 3.1 Pro Preview : 72,4%
- Claude Opus 4.6 : 66,6%
- GPT-5.2-Codex : 62,5%
Ce que ça raconte, en creux : “LLM qui code” ne veut pas dire “LLM qui shippe un correctif Android sans casser le projet”. Android, avec Gradle, les API changeantes, les architectures app, Compose/Jetpack et les tests instrumentés, est un sport de contact.
Choosing the best ✨ AI model for your task can feel overwhelming when there’s so many options, which is why the industry looks to LLM benchmarks for guidance.
The problem for Android developers is that these benchmarks aren’t weighted to really evaluate the kinds of tasks that… pic.twitter.com/nz7Uxnc6l2
— Mishaal Rahman (@MishaalRahman) March 5, 2026
Pourquoi c’est plus utile qu’un benchmark “générique” de code ?
Un benchmark Android spécialisé change la nature du débat :
- Le code doit s’insérer dans un codebase, pas dans un snippet isolé.
- Le modèle doit comprendre des conventions Android/Kotlin, des patterns d’archi, des dépendances, parfois des contraintes de compatibilité.
- Le verdict doit être vérifiable : compilation, tests, résolution effective.
C’est précisément ce que Google met en avant : réduire la distance entre “ça a l’air correct” et “ça fonctionne”.
Un signal envoyé aux développeurs… et aux fabricants de modèles
Android Bench est autant un outil de choix pour les devs qu’un message politique à l’écosystème IA : “voici la barre, venez la franchir”. D’autant que Google publie la méthodologie, les données et le framework sur GitHub, ce qui invite à la critique, à la reproduction et — idéalement — à l’amélioration collective.
Mais, il y a aussi des limites à lire entre les lignes : En se concentrant sur la performance “pure”, Android Bench ne mesure pas encore l’expérience réelle d’un dev qui s’appuie sur des outils (IDE, navigation, recherche, exécution, logs, itérations). Un leaderboard n’évalue pas vos contraintes quotidiennes : coût, latence, privacy, contexte projet, ni la capacité à respecter vos conventions d’équipe.
La bonne lecture : Android Bench est un thermomètre — excellent pour comparer une base — mais pas une ordonnance universelle.
Google met ainsi une chose au clair : l’avenir de l’IA pour développeurs ne se jouera pas sur le style du code généré, mais sur sa capacité à survivre à la réalité d’un repo.
