Le benchmark Gemini 4 Argon place Google derrière Claude et GPT-6

Google a publié les résultats du benchmark Gemini 4 Argon, qui placent son modèle derrière Claude et GPT-6 sur des tâches exigeantes de développement Android. La mise à jour du 26 octobre crée une comparaison inconfortable : l’évaluation de Google elle-même situe les systèmes concurrents devant sa dernière version.

Ce constat est important car Android Bench, l’évaluation par Google de l’ingénierie Android assistée par IA, teste bien plus que la capacité à suggérer du code plausible. Son classement actuel évalue des combinaisons modèle-agent sur des travaux de développement conséquents. Un agent est un logiciel qui utilise un modèle pour examiner des projets, modifier des fichiers et exécuter des outils de développement.

Le titre doit toutefois être nuancé. Ces résultats comparent des systèmes configurés, plutôt que des modèles isolés dans des conditions identiques. Ils distinguent également les progrès partiels des solutions entièrement validées. Google a publié des éléments démontrant un écart compétitif, mais ces éléments appuient une conclusion plus restreinte que l’affirmation selon laquelle Gemini perd systématiquement en programmation Android.

Pour les développeurs, la question immédiate concerne la délégation. Quel système mérite une mission difficile, et quelle quantité de travail inachevé un développeur devra-t-il reprendre ? Pour Google, la pression est plus précise : expliquer pourquoi son offre de développement Android devrait mériter cette mission alors que son propre classement favorise ses rivaux.

Le benchmark Gemini 4 Argon révèle un écart net, avec une correction de classement

Les résultats publiés par Google placent Argon derrière les systèmes Claude et GPT concurrents, mais le classement en direct le situe sixième plutôt que cinquième.

Dans sa couverture du 26 octobre, 9to5Google a décrit Argon comme cinquième. Sa couverture de la programmation Android identifie correctement le résultat concurrentiel plus large : l’entrée de Google est derrière les systèmes récents d’Anthropic et d’OpenAI. La position exacte mérite d’être corrigée, car une autre entrée Claude se situe immédiatement au-dessus d’Argon dans le tableau actuel.

Le classement Android Bench de Google place Claude Sonnet 5.5 en première position, avec un taux de réussite de 40 %. GPT 6.1 Sol atteint 29,3 %, tandis que Gemini 4 Argon atteint 21,3 %. Leurs taux de réalisation sont respectivement de 80,9 %, 82,8 % et 81,8 %.

Les configurations diffèrent également. Sonnet s’exécute via Claude Code avec un effort de raisonnement maximal, GPT via Codex avec un effort maximal, et Argon via Antigravity SDK avec un effort élevé. L’effort de raisonnement est le paramètre configuré qui régit la délibération d’un modèle. Ces libellés doivent rester associés à toute comparaison.

Ces détails rendent le résultat utile sans le rendre universel. Une équipe évaluant ces systèmes précis dispose d’un point de départ concret. Un lecteur qui compare les marques sur toutes les tâches de programmation a beaucoup moins de raisons de tirer un verdict global.

La correction du classement ne résout pas le problème de Google. Faire passer Argon de la cinquième à la sixième place modifie sa position ordinale, mais laisse intacte l’observation centrale. Plusieurs systèmes concurrents terminent avec succès davantage de tâches du benchmark.

Les chiffres de réalisation compliquent également une interprétation trop simple. Le score de progrès partiel d’Argon est proche de ceux des concurrents mis en avant, tandis que son résultat sur les tâches entièrement validées reste inférieur. Cette tendance soulève une question différente de celle de savoir si le modèle peut produire une quantité importante de code.

Un développeur peut recevoir une implémentation conséquente sans pour autant obtenir un résultat fiable. Le travail restant peut consister à identifier un défaut subtil, satisfaire une exigence omise ou vérifier un comportement que l’agent a négligé. Le classement seul ne permet pas d’établir quelle explication prédomine dans les échecs d’Argon.

La lecture la plus défendable est donc précise. La configuration Argon testée par Google est derrière les principales alternatives testées pour la résolution complète des tâches. Cela justifie d’examiner ses échecs, plutôt que de considérer chaque sortie comme également faible.

Cela modifie également la conversation concurrentielle. Google n’a pas besoin d’une nouvelle démonstration montrant qu’Argon peut générer une interface Android. Il lui faut des éléments montrant que le système configuré peut terminer des missions exigeantes de manière suffisamment fiable pour justifier la confiance des développeurs.

Google est sous pression pour transformer son expertise Android en travail finalisé

La position de Google dans Android crée des attentes, mais la propriété de la plateforme ne démontre pas à elle seule des performances supérieures dans un benchmark d’ingénierie.

L’entreprise a contribué à définir la plateforme, ses pratiques de développement et l’évaluation elle-même. Cela rend le résultat particulièrement visible. Les lecteurs s’attendent naturellement à ce que ces avantages se traduisent par une assistance solide pour les développeurs Android.

Cependant, cette attente est une inférence sur les avantages de Google, et non une capacité mesurée. Un système de programmation doit appliquer ses connaissances dans un projet existant, respecter les contraintes et se remettre de ses erreurs. La familiarité avec une plateforme ne résout pas automatiquement ces problèmes de coordination.

Google a présenté le lancement initial du benchmark en mars comme un moyen d’identifier les écarts de capacités et d’améliorer le choix des modèles. Ce cadrage compte aujourd’hui. Publier un résultat défavorable est cohérent avec l’objectif déclaré du benchmark, même lorsque cela complique le discours produit de Google.

La publication elle-même ne doit pas être confondue avec un aveu que Gemini manque de valeur. Une évaluation peut révéler des faiblesses tout en restant utile à son créateur. En effet, un benchmark favorisant systématiquement son éditeur susciterait un autre problème de crédibilité.

La pression pratique porte sur l’offre produit qui entoure Argon. Si Google veut que les développeurs délèguent des missions Android difficiles, ses éléments doivent relier les capacités du modèle à des résultats fiables. La commodité d’intégration ne répond pas à elle seule à une comparaison de performances.

Pour un responsable d’ingénierie, cela affecte la charge de justification. Choisir un fournisseur familier peut simplifier les achats ou l’administration, mais ces considérations ne résolvent pas la question de savoir si son système de programmation gère le travail le plus difficile de l’équipe. Le choix technique exige toujours des preuves.

À l’inverse, un rival mieux classé ne mérite pas automatiquement un accès sans restriction à un flux de production. Une équipe doit encore examiner les autorisations du dépôt, les attentes de revue et les types de modifications qu’elle entend déléguer. La domination dans le benchmark ne répond qu’à une partie de cette décision.

L’effet concurrentiel immédiat est d’affaiblir une hypothèse : que le propre modèle de Google devrait être le choix évident pour sa plateforme mobile. Les développeurs Android disposent désormais d’une raison propre à la plateforme pour tester des alternatives.

Cette pression est significative sans nécessiter de prédiction sur les départs de clients. Les éléments disponibles n’établissent ni les changements d’adoption, ni les taux de migration, ni les conséquences commerciales. Ils établissent une comparaison de performances publiée, que les acheteurs peuvent utiliser pour remettre en cause un choix par défaut.

La réponse la plus solide de Google traiterait directement les faiblesses mesurées. Un nouveau résultat accompagné de changements documentés serait plus instructif qu’une affirmation générale sur l’intelligence en programmation. Les développeurs doivent savoir ce qui s’est amélioré, dans quelles conditions et avec quelles limites restantes.

Le défi concurrentiel est donc opérationnel. Google doit montrer que son expertise atteint l’application finalisée, plutôt que de s’arrêter à des explications convaincantes ou à des correctifs substantiels. C’est là que la crédibilité de la plateforme devient une preuve utile pour un développeur qui décide quoi déléguer.

Claude et GPT dominent là où les progrès partiels ne suffisent plus

La distinction concurrentielle porte sur les missions achevées, même lorsque les systèmes produisent des quantités similaires de progrès intermédiaires.

Un score de réalisation peut reconnaître un travail utile sans déclarer une mission réussie. Cette distinction compte chaque fois qu’un développeur reprend une implémentation qui semble presque terminée. Le volume visible de code ne détermine pas la difficulté de réparer ce qui reste.

Prenons l’exemple hypothétique d’une fonctionnalité de création de compte. Un agent peut construire les écrans, connecter la navigation et stocker les données saisies par l’utilisateur. Si l’application gère mal une étape de vérification échouée, la fonctionnalité nécessite toujours une investigation avant sa mise en production.

Le comportement manquant peut ne nécessiter qu’un petit correctif. Le trouver peut néanmoins exiger une lecture attentive, une reproduction et des tests. La réalisation partielle et l’effort humain doivent donc être traités séparément ; aucun ne se traduit mécaniquement par l’autre.

La mise à jour de septembre de Google sur l’évaluation à long horizon explique pourquoi l’entreprise a introduit des missions plus exigeantes et une notation continue. Les tâches à long horizon sont des travaux de développement impliquant des étapes étendues et interdépendantes. Google décrit des travaux tels que la création d’applications, les migrations, les ajouts de fonctionnalités et les conversions multiplateformes.

Ce changement modifie ce que signifie être en tête. Un système performant sur des corrections localisées démontre quelque chose de précieux, mais différent de la gestion d’une mission d’ingénierie étendue. Maintenir des décisions cohérentes à l’échelle d’un projet crée ses propres possibilités d’échec.

Le revers pour Google est qu’un benchmark conçu pour révéler ces possibilités met désormais en évidence des concurrents devant Argon. Le résultat remet en cause l’attente d’un avantage sur la plateforme d’origine avec un test centré sur une exécution soutenue.

La configuration de Claude en tête fournit le meilleur résultat publié sur la résolution complète parmi les systèmes mis en avant. La configuration de GPT offre un autre point de référence concurrentiel. Leurs positions donnent aux développeurs des alternatives à examiner, plutôt qu’une raison de supposer que leurs résultats ne nécessitent aucune revue.

La comparaison importante porte sur des systèmes auxquels sont confiés des travaux équivalents. Si un assistant gère une migration difficile et qu’un autre écrit des fonctions utilitaires isolées, leur productivité apparente ne peut étayer un classement significatif. Le benchmark aide en définissant un cadre d’évaluation commun.

Il n’élimine pas les différences entre ce cadre et le dépôt d’une entreprise. Les dépendances, l’architecture et les critères d’acceptation d’une équipe peuvent modifier les échecs les plus importants. Un bon résultat général peut coexister avec une mauvaise adéquation à une charge de travail particulière.

C’est pourquoi les comparaisons de programmation Claude vs Gemini nécessitent une limite explicite de la tâche. Une affirmation concernant des missions de benchmark entièrement achevées doit rester liée à ce benchmark. L’étendre aux explications, aux petites modifications ou à chaque projet Android exigerait des preuves supplémentaires.

La même discipline s’applique à l’interprétation de la position de GPT. Un classement sous le leader ne désigne pas un produit inadapté. Il indique un résultat observé différent dans la configuration publiée, laissant aux équipes le soin d’évaluer sa pertinence pour leur propre travail.

Pour Argon, le défi consiste à combler la distance entre une implémentation substantielle et une réalisation acceptée. C’est un objectif plus actionnable que de tenter de gagner un débat indéfini sur le modèle qui comprend le mieux Android.

Des agents et paramètres de raisonnement différents limitent le verdict sur les modèles

Le benchmark Gemini 4 Argon compare des combinaisons déployées, et ne peut donc isoler le modèle sous-jacent comme seule cause de l’écart.

Un agent de programmation contrôle la manière dont un modèle interagit avec un projet. Son logiciel environnant détermine comment les outils sont exposés, quel contexte reste disponible et comment l’exécution se déroule. Des changements dans ces modalités peuvent affecter le résultat reçu par un développeur.

Cela rend les comparaisons entre systèmes commercialement pertinentes. Les développeurs utilisent des produits dotés d’outils, d’autorisations et de comportements d’exécution. Ils rencontrent rarement un modèle fonctionnant indépendamment de l’environnement logiciel qui l’entoure.

Toutefois, la pertinence commerciale et l’explication causale relèvent de questions différentes. Savoir quelle configuration a obtenu de meilleurs résultats n’établit pas pourquoi elle les a obtenus. Le modèle, l’agent, le paramètre de raisonnement et leurs interactions restent autant de facteurs possibles.

Le journal des modifications des benchmarks d’octobre de Google consigne l’ajout d’étiquettes d’effort de raisonnement aux côtés de nouveaux résultats pour Argon, Sonnet 5.5 et GPT 6.1 Sol. Il répertorie également des entrées archivées. La mise à jour modifie donc à la fois les comparaisons disponibles et les informations que les lecteurs reçoivent sur leurs configurations.

Les étiquettes améliorent la transparence, mais elles ne créent pas une mesure standardisée entre les fournisseurs. Un paramètre appelé « élevé » ne peut pas être automatiquement considéré comme équivalent au « maximum » d’un autre fournisseur. Les noms identifient des configurations sans démontrer des conditions de calcul identiques.

Il serait également prématuré de supposer qu’Argon effacerait son retard avec un paramètre différent. Il s’agit d’une possibilité vérifiable, et non d’une explication étayée par le classement actuel. La même prudence s’applique aux affirmations selon lesquelles un autre agent améliorerait nécessairement son résultat.

Une comparaison causale plus solide ferait varier délibérément ces éléments. Garder le modèle fixe tout en changeant l’agent aiderait à examiner le logiciel environnant. Garder l’agent fixe tout en changeant le modèle répondrait à une autre question.

Aucune des deux approches ne rendrait chaque comparaison parfaitement contrôlée. Les interfaces des fournisseurs et les capacités prises en charge peuvent différer. Néanmoins, des limites expérimentales explicites aideraient les lecteurs à comprendre ce qu’un résultat isole réellement.

La méthodologie d’évaluation de Google ajoute d’autres limites. Elle décrit un jeu de données privé, des exécutions répétées, des contrôles fonctionnels automatisés et une évaluation visuelle assistée par modèle. Elle avertit également que les totaux de ressources peuvent favoriser les systèmes qui échouent tôt.

Ces divulgations appellent une interprétation prudente plutôt qu’un rejet. Une collection privée de tâches peut réduire l’exposition à des solutions mémorisées, tout en rendant la reproduction externe plus difficile. L’évaluation automatisée peut permettre de passer à l’échelle, tout en laissant aux évaluateurs la responsabilité de déterminer si ses contrôles correspondent au travail visé.

Les intervalles de confiance rapportés se chevauchent également. Cela n’efface pas l’ordre observé, mais limite la confiance dans une hiérarchie de performance figée. Les lecteurs devraient distinguer le résultat affiché d’une affirmation selon laquelle les exécutions futures doivent préserver chaque position.

La conclusion prudente reste substantielle : Argon est en retrait dans cette comparaison publiée. La question non résolue porte sur la part de ce résultat attribuable au modèle, à sa configuration, à son agent ou aux exigences particulières de l’évaluation.

Les équipes Android ont besoin de preuves sur le travail qu’elles devront reprendre

Une décision d’achat utile demande ce qui se passe après que l’agent a soumis ses modifications, plutôt que de s’arrêter à sa position au classement.

Pour une équipe qui maintient une application, la sortie d’un agent devient la responsabilité de quelqu’un d’autre. Les réviseurs doivent comprendre suffisamment les modifications pour les accepter, les corriger ou les rejeter. Cette transmission détermine si des progrès apparents deviennent un travail d’ingénierie exploitable.

Imaginez une migration hypothétique dans une application établie. L’assistant met à jour le code ciblé et signale sa réussite, mais un réviseur découvre des changements de comportement en dehors du périmètre demandé. L’équipe doit alors examiner à la fois la migration et ses effets involontaires.

Cette charge est différente de la rédaction manuelle des modifications initiales. Elle diffère également de la réception d’une implémentation complète et fiable. Un résultat de benchmark peut aider à identifier des candidats, tout en laissant à l’équipe qui reçoit le travail le soin de mesurer la qualité de la transmission.

Les classements de programmation Android sont les plus utiles lorsqu’ils suscitent des questions plus précises. Quelles missions révèlent des échecs ? Le système reconnaît-il lorsqu’il n’a pas terminé ? Le réviseur peut-il retracer pourquoi il a modifié un fichier ou adopté une hypothèse ?

Ces questions comptent parce qu’un résumé assuré peut masquer de l’incertitude. Un développeur a besoin de preuves de ce qui a été vérifié, et pas seulement d’un récit soigné du travail. La qualité de ces preuves influe sur le degré de vérification indépendante qui reste nécessaire.

La comparaison pertinente dépend aussi de la répartition du travail envisagée. Une équipe utilisant l’IA pour des modifications limitées n’a pas les mêmes attentes qu’une équipe déléguant une implémentation étendue. Un résultat décevant dans cette dernière catégorie ne tranche pas la performance dans la première.

Cette distinction laisse à Argon la possibilité de rester utile sans minimiser son retard dans le benchmark. Les équipes peuvent l’évaluer sur le travail qu’elles prévoient réellement de lui confier. Elles devraient éviter de traiter la familiarité ou l’intégration comme un substitut à cette évaluation.

Elle impose une obligation similaire à Claude et GPT. Leurs meilleures positions publiées justifient l’attention, mais les résultats locaux doivent encore étayer une délégation plus large. Une entrée en tête d’un benchmark ne peut pas certifier un dépôt inconnu ou les exigences implicites d’une application.

La continuité des connaissances devient une partie de cette évaluation. Les décisions de projet, les échecs précédents et les contraintes peuvent expliquer pourquoi une modification apparemment raisonnable est inappropriée. Si les réviseurs ne peuvent pas retrouver ce contexte, il devient plus difficile d’évaluer les choix d’un agent.

Les équipes confrontées à ce problème peuvent utiliser une base de connaissances consultable pour organiser les documents techniques et les décisions de développement. Cela facilite l’accès au contexte ; cela ne remplace pas les contrôles exécutables et n’établit pas les performances de programmation.

L’implication métier est une définition plus large de l’utilité. Un assistant gagne la confiance lorsque son travail réduit l’effort total nécessaire pour parvenir à un résultat accepté. Le code généré, les explications convaincantes et les progrès intermédiaires ne comptent que dans la mesure où ils contribuent à atteindre ce résultat.

La comparaison de Google met cette question en relief, car elle distingue des progrès considérables d’une réussite complète. Les développeurs devraient examiner attentivement cette frontière. C’est là qu’une démonstration attrayante devient un engagement d’ingénierie, et que l’équipe qui reçoit le travail assume la responsabilité de ce qui reste.

Surveillez les prochains résultats d’Argon, les changements de configuration et les tests indépendants

Les prochaines preuves significatives montreront si Google peut améliorer la résolution complète des tâches dans des conditions clairement documentées.

Le premier signal sera une autre évaluation d’Argon sur un travail comparable. Un résultat plus solide étayerait l’idée que Google corrige la faiblesse mesurée. Une collection de tâches modifiée exigerait une nouvelle comparaison avant que quiconque puisse affirmer que l’écart initial s’est refermé.

Cette distinction compte, car un classement peut s’améliorer pour plusieurs raisons. Un nouveau modèle peut être plus performant, un agent peut changer ou l’évaluation peut évoluer. Les lecteurs ont besoin d’une documentation suffisante pour distinguer ces évolutions.

Une mise à jour convaincante identifierait la version testée et conserverait un point de référence clair. Sans cette continuité, un score plus élevé pourrait être encourageant tout en restant difficile à interpréter. La question porte sur l’amélioration face à des exigences comparables, plutôt que sur un chiffre plus flatteur à lui seul.

Le deuxième signal serait une modification documentée de la configuration de l’agent ou du raisonnement d’Argon. De meilleurs résultats après un tel changement renforceraient l’argument selon lequel le système environnant a contribué au retard. Des résultats inchangés rendraient cette explication moins convaincante.

Cela clarifierait également la réponse concurrentielle. Google peut améliorer un produit destiné aux développeurs grâce à plusieurs composants, et les utilisateurs bénéficient du résultat combiné. Mais identifier le composant est important pour déterminer si l’amélioration se transfère à un autre environnement de développement.

Le même examen devrait s’appliquer aux concurrents. Une configuration mise à jour de Claude ou GPT pourrait élargir l’écart observé, le réduire ou modifier l’ordre. Une comparaison évolutive exige que les lecteurs suivent les systèmes testés plutôt que de se fier à des impressions au niveau de la marque.

Le troisième signal serait une évaluation indépendante sur des projets Android en dehors de la collection de tâches de Google. Des résultats similaires renforceraient l’idée que l’ordre publié a une pertinence pratique. Des résultats différents aideraient à identifier les charges de travail pour lesquelles le benchmark offre moins d’indications.

Les preuves indépendantes devraient décrire à la fois la mission et les critères d’acceptation. Une démonstration réussie sans limites claires est difficile à comparer à une tâche étendue ayant échoué. Les rapports deviennent plus utiles lorsque les lecteurs peuvent comprendre ce que l’agent devait réellement terminer.

Aucun résultat précis ne devrait être présumé. Les résultats actuels n’établissent pas que Google comblera l’écart, que les concurrents maintiendront leurs positions ou que les développeurs changeront de produits. Ils établissent une comparaison qui mérite d’être suivie avec des preuves mieux contrôlées.

Le benchmark Gemini 4 Argon donne actuellement à Google une question concrète de performance à résoudre. Sa propre évaluation favorise des systèmes concurrents en matière de résolution complète, tout en laissant ouvertes d’importantes questions de configuration et de généralisation.

Avant votre prochaine décision concernant un agent de programmation, identifiez la mission que vous souhaitez déléguer et les preuves nécessaires pour l’accepter. Comparez les candidats sur ce travail, conservez les configurations testées et examinez ce que les réviseurs reçoivent après la soumission. Conservez les tentatives échouées aux côtés des réussites afin qu’une démonstration convaincante ne domine pas le dossier. Distinguez les progrès intermédiaires du travail qui satisfait vos exigences, et consignez les situations où l’intervention humaine modifie le résultat. Ces observations faciliteront l’interprétation des futurs classements de programmation Android. Lorsque Google publiera les prochains résultats d’Argon, demandez-vous si les changements répondent aux échecs qui comptent dans votre dépôt. Le système mis à jour laisse-t-il à votre équipe moins de travail inachevé ?