Gemini 4 Argon : des benchmarks de code contrastés

Google a annoncé Gemini 4 Argon le 30 septembre 2026, et ses résultats en programmation me donnent envie de le tester avant de changer de modèle. Argon mène dans la comparaison DeepSWE de Google, mais reste derrière Astra et Opus sur d’autres tests. La limite de sortie passe aussi à un million de tokens, avec un accès initial réservé à un programme de cyberdéfense. [1] [2]

Que montrent les benchmarks de code de Gemini 4 Argon ?

Argon remporte la comparaison DeepSWE, mais le tableau de lancement de Google montre déjà que le modèle en tête change selon la tâche. Je le retiendrais parmi les candidats pour travailler sur un dépôt, sans en faire le remplaçant automatique d’Astra ou d’Opus. Ces trois lignes expliquent pourquoi. [2]

Sur DeepSWE v1.1, Argon atteint 77,9 %, devant Astra à 74,1 % et Opus 5.5 à 74,2 %. C’est un résultat utile pour le développement logiciel. Mais FrontierSWE v2 place Astra à 65,5 % contre 55,0 % pour Argon, tandis que Terminal-bench 4.0 donne 66,4 % à Opus contre 57,4 % à Argon. Les écarts sont de 10,5 et 9,0 points de pourcentage, calculés à partir des scores publiés. [2]

Cette différence compte, car « le meilleur pour coder » serait une conclusion trop générale pour ce tableau. Résoudre un problème limité et terminer une mission longue peuvent demander des capacités différentes à un agent. Ces résultats suggèrent que la tâche doit déterminer quel modèle je teste en premier. C’est la même distinction pratique que dans pourquoi les benchmarks d’IA ne reflètent pas toute la qualité d’un modèle.

Les bons résultats d’Argon dépassent aussi la programmation. Google publie 51,3 % pour Argon en High sur AutomationBench, contre 41,4 % pour Astra en Max et 42,5 % pour Opus 5.5 en Max avec les fallbacks par défaut. Dans l’évaluation de Zapier, une étape refusée est dirigée vers le modèle de secours par défaut du fournisseur. Cela justifie de tester des processus automatisés, mais ce résultat ne fait pas disparaître les faiblesses visibles dans les lignes consacrées au code. [2] [11]

Pourquoi les benchmarks de code ne donnent-ils pas le même classement ?

Les benchmarks évaluent des travaux différents, et Google assemble également des résultats obtenus avec des méthodes distinctes. Le modèle n’est qu’une partie du système évalué : ses instructions, ses outils et son budget de temps peuvent changer le résultat. Le rapport d’évaluation de Google apporte les détails nécessaires pour lire le tableau. [3]

Pour DeepSWE, Google a évalué Argon avec le harness mini-swe, le logiciel qui fournit les outils au modèle et exécute la tâche. Les chiffres concurrents proviennent du classement du benchmark ou des fiches système des fournisseurs. Google publie généralement ses propres résultats avec le niveau de raisonnement le plus élevé. pass@1 mesure le succès en une tentative, sans vote majoritaire entre des réponses produites en parallèle. Cette règle comporte des exceptions et ne vaut donc pas pour chaque ligne. [3]

La qualité des tests DeepSWE mérite aussi de l’attention. Dans son audit du 7 septembre 2026, Epoch AI a trouvé des erreurs dans au moins 23 des 113 tâches, où des solutions valides pouvaient être considérées comme des échecs. Cet audit ne démontre pas que le score d’Argon est faux, mais il me donne une raison de traiter l’écart précis avec prudence, plutôt que de supposer que chaque tâche constituait un test fiable. [10]

FrontierSWE est une exception importante. Le classement public de Proximal affiche la moyenne de cinq essais pour chacune des 34 tâches, avec jusqu’à 20 heures par essai dans son environnement d’agents proximus. Il montre aussi le pire et le meilleur résultat. Ce n’est pas la même mesure qu’un taux de réussite en une tentative. Ces essais longs sont utiles pour savoir si un agent peut continuer à travailler sur une mission exigeante. [4]

Il existe aussi une vérification indépendante des capacités générales. Dans les données du 1er octobre de l’Intelligence Index v4.3.2, Artificial Analysis attribue à Argon en High un score arrondi de 53, comme à Astra en Max. Opus 5.5 en Max avec fallback par défaut obtient 58. Les réglages diffèrent et l’indice combine dix évaluations, principalement sur du texte anglais. Ce n’est pas un pourcentage de tâches de dépôt terminées. C’est une raison supplémentaire de tester Argon tout en gardant les résultats de programmation individuels à l’esprit. [5] [7] [8]

C’est pourquoi je regarde la configuration complète lorsque je compare Claude et Codex sur de grandes fonctionnalités. Si un essai reçoit plus de temps ou d’autres outils, son résultat peut rester utile. Il répond cependant à une autre question qu’un changement du seul modèle.

Gemini 4 Argon a-t-il une fenêtre de contexte d’un million de tokens ?

L’annonce du million de tokens concerne la sortie. Google indique qu’Argon relève la limite de sortie de 64 000 à un million de tokens, ce qui permet des réponses beaucoup plus longues. Cela établit la quantité que le modèle peut produire, sans annoncer une nouvelle fenêtre de contexte d’entrée. [1]

La distinction a des conséquences pratiques. La fenêtre de contexte limite le contenu avec lequel le modèle peut travailler dans une requête ; le plafond de sortie limite ce qu’il peut générer. Une sortie plus longue pourrait aider lorsqu’une mission exige beaucoup de code ou un rapport détaillé, mais elle ne détermine pas à elle seule quelle part d’un dépôt peut être fournie en entrée.

Le nouveau plafond représente environ 15,6 fois l’ancienne limite de 64 000 tokens. C’est un calcul à partir des chiffres de Google, pas l’affirmation qu’une tâche dure 15,6 fois plus longtemps ou devient d’autant plus fiable. Le plafond indique où la génération doit s’arrêter, pas si tout ce qui précède mérite d’être conservé.

Je m’intéresserais d’abord aux travaux qui s’arrêtaient avant de fournir un résultat complet. Je conserverais la gestion du contexte pour les agents de programmation, car un budget de génération plus élevé ne justifie pas de retirer les instructions et les informations du dépôt qui rendent la tâche compréhensible. L’évaluation viserait toujours une modification que je peux examiner, pas un nombre de tokens.

Qui peut utiliser Gemini 4 Argon au lancement ?

L’accès commence avec des équipes de cyberdéfense de confiance dans le programme Fairwind de Google. Google annonce ensuite une disponibilité plus large, d’abord pour les clients payants de l’API et les abonnés Google AI Ultra, mais sans date pour cette étape. Au 1er octobre 2026, l’accès s’ouvre par étapes ; il n’est pas encore proposé à tous les développeurs. [1]

Google DeepMind décrit Fairwind comme un programme d’accès anticipé pour des organisations approuvées qui travaillent sur la sécurité défensive et la recherche. Les partenaires peuvent inclure des gouvernements et des responsables d’infrastructures critiques, avec des contrôles d’accès et des restrictions d’utilisation. Le programme demande une approbation distincte : un compte payant ordinaire ne suffit pas pour accéder à la première phase d’accès à Argon. [6]

L’accent mis sur la cybersécurité s’appuie sur un benchmark. Le tableau de Google donne 68,0 % à Argon sur CWE-bench v1, comme Astra, et légèrement au-dessus d’Opus 5.5 à 67,0 %. CWE-bench teste l’audit et la correction des vulnérabilités : Argon utilise Antigravity, Astra Codex et Opus Claude Code. Les scores comparent les modèles avec leurs outils d’agent. Ils appuient donc un bon résultat du système Argon testé, plutôt qu’un avantage du modèle isolé. [2] [9]

Pour un développeur qui choisit ses outils maintenant, la restriction d’accès compte autant qu’un score prometteur. Je peux préparer une tâche de comparaison, mais je ne peux pas encore intégrer une annonce à mon travail en production. J’attendrais la voie d’accès documentée et la configuration du modèle avant de modifier une intégration.

Combien coûtera Gemini 4 Argon ?

Google annonce des tarifs de lancement pour l’API de 2 dollars par million de tokens d’entrée et 10 dollars par million de sortie. Ils passent ensuite à 4 et 20 dollars. L’entrée en cache bénéficie d’une réduction de 95 %. Ces tarifs sont annoncés pour la prochaine ouverture plus large ; Google ne précise pas la durée de la période de lancement. [1]

Les tarifs normaux par token seront deux fois plus élevés que les tarifs de lancement. Je prévoirais donc le budget des travaux récurrents avec 4 et 20 dollars. Pour une requête hypothétique de 100 000 tokens d’entrée sans cache et 10 000 de sortie, les tarifs donnent 0,30 dollar au lancement, puis 0,60. Ce sont des calculs de facturation des tokens, pas des coûts par tâche mesurés.

Le plafond de sortie d’un million de tokens rend aussi cette partie de la facture plus visible. Générer un million de tokens de sortie facturés coûterait 10 dollars au tarif de lancement ou 20 ensuite, avant l’entrée. Le modèle n’a pas besoin d’atteindre ce plafond à chaque requête. Je fixerais un budget de génération adapté à la tâche, au lieu de préférer systématiquement la réponse la plus longue autorisée.

C’est la distinction derrière le coût par tâche mesuré plus faible de GPT-6.1 Sol : un prix par token et le coût du travail terminé sont deux mesures différentes. Le prix d’Argon deviendra plus utile lorsqu’une évaluation enregistrera les tokens nécessaires pour produire un résultat accepté.

Que testerais-je lors de l’ouverture plus large ?

Je choisirais une tâche assez longue pour révéler les différences entre les benchmarks de programmation, puis je mesurerais le travail nécessaire pour accepter le résultat. Le score DeepSWE d’Argon justifie ce test. Ses résultats inférieurs sur FrontierSWE et Terminal-bench m’incitent à regarder la poursuite de l’exécution plutôt qu’à le juger sur sa première réponse.

La comparaison partirait du même commit du dépôt, avec les mêmes instructions, outils et critères d’acceptation. J’inclurais une correction limitée et une modification plus importante en plusieurs étapes, je répéterais les essais et je conserverais les échecs dans les résultats. Le temps de revue compterait avec le coût de l’API : un patch bon marché qui demande beaucoup de réparations n’est pas du travail terminé à faible coût.

Je distinguerais aussi la quantité produite de la tâche terminée. Une réponse plus longue aide si elle livre la partie manquante de la mission ; si elle ajoute du code sans rapport, elle crée un travail de revue supplémentaire. Je veux savoir si Argon peut terminer la grande modification avec moins de corrections au tarif normal. C’est la comparaison que je préparerais pendant l’élargissement de l’accès.