Gemini 4 Argon, GPT-6 Astra, Claude Opus 5.5 : trois modèles de pointe, trois vainqueurs différents

L’article de lancement de Gemini 4 Argon publié par Google présente un tableau de benchmarks de 19 lignes. D’après notre analyse, Argon arrive nettement en tête sur 13 d’entre elles et fait jeu égal sur une autre. Les cinq lignes qu’il concède ne doivent rien au hasard : GPT-6 Astra s’impose sur FrontierSWE v2, Terminal-Bench Science et OSWorld-2.0, tandis que Claude Opus 5.5 l’emporte sur Terminal-bench 4.0 et PostTrainBench. Cela représente les deux lignes de Terminal-Bench, une ligne dédiée au codage par agents, la ligne d’ingénierie ML et l’une des deux lignes d’utilisation de l’ordinateur (« computer use ») — soit l’essentiel des cas d’usage sur lesquels une équipe de développement mobilise concrètement ses runs. Et la question n’a plus rien de théorique : depuis le 13 octobre 2026, Argon est disponible pour tous sur l’API payante de Gemini sous l’identifiant gemini-4-argon.

Dès lors, à la question « quel modèle l’emporte ? », la réponse varie selon la ligne examinée — ce qui, pour une équipe exploitant plusieurs agents de codage, est loin d’être un détail. Si chaque Agent de votre organisation tourne sur le même Runtime, l’équipe hérite des faiblesses d’un laboratoire en même temps que de ses victoires, et chaque nouveau lancement relance le débat. Savoir quel agent traite quelle tâche, ce qui est terminé ou ce qui nécessite une revue : rien de tout cela ne devrait dépendre du modèle arrivé en tête d’un classement cette semaine.

TL;DR

Aucun laboratoire de pointe ne domine l’ensemble des benchmarks, pas même sur son propre tableau. Considérez chaque nouvelle sortie comme un élément guidant votre routage, et non comme une raison de tout migrer : conservez plusieurs Runtimes connectés, formalisez la règle de routage par écrit (une configuration par défaut, les critères d’attribution d’une Tâche à un autre Agent, et la désignation du relecteur), puis mettez-la à l’épreuve sur trois Tâches issues de votre propre base de code. Astra s’exécute via Codex, Opus 5.5 via Claude Code, et les modèles Gemini via l’interface Gemini CLI avec une clé payante. Google n’ayant pas précisé si Gemini CLI prenait en charge Argon, effectuez un test préliminaire (smoke test) avec gemini-4-argon avant de lui confier de véritables Tâches.

Ce que révèle le tableau de Google, par type de tâche

Voici les lignes pertinentes pour les agents de codage, regroupées selon les catégories établies par Google :

À elle seule, la catégorie du codage par agents compte quatre lignes pour trois leaders distincts. Le sans-faute d’Argon concerne en réalité le travail intellectuel (« knowledge work »), le contexte long et les benchmarks multimodaux — des domaines qui importent moins pour une équipe dont les Tâches aboutissent à un diff.

Ces chiffres sont toutefois à prendre avec précaution : il s’agit du tableau fourni par Google. Google a lui-même évalué Argon sur plusieurs lignes, les résultats des concurrents sont pour la plupart autodéclarés ou issus de classements publics, et les bancs d’évaluation diffèrent. La méthodologie d’évaluation détaille la provenance de chaque donnée. De plus, les évaluations indépendantes parues depuis le lancement ne s’accordent pas toujours : le benchmark Humanity’s Sixth Sense de Scale AI place Argon en tête à 55,4 % contre 53,6 % pour GPT-6 Astra, Cursor le situe au même niveau qu’Opus 5.5 sur son CursorBench, et Artificial Analysis classe Argon (High) à la huitième place sur 216 variantes répertoriées au 15 octobre.

Le tarif ne permet pas non plus de trancher nettement. Argon est facturé 2 $ par million de tokens en entrée et 10 $ par million en sortie jusqu’au 30 novembre 2026, puis 4 $ et 20 $ à partir du 1er décembre. Ce dernier tarif est rigoureusement identique à celui d’Opus 5.5. De son côté, Astra est affiché à 10 $ et 50 $.

Aucun laboratoire ne domine chaque ligne : aucun ne devrait donc monopoliser votre environnement

Ce constat découle directement des données fournies par les éditeurs, et non de notre propre avis. Si le tableau de Google, conçu par Google pour mettre en avant son propre modèle, concède malgré tout cinq lignes à deux concurrents, c’est bien qu’il n’existe pas de modèle unique parfait pour les agents de codage. Il existe simplement un modèle optimal pour un type de Tâche donné, pour le trimestre en cours et sur un banc de test spécifique.

Cela change la perspective lors de chaque annonce de lancement. Le réflexe tentant consiste à lancer une migration complète : remplacer le Runtime par défaut, réécrire la configuration et bousculer les habitudes de l’équipe. L’option la plus judicieuse consiste plutôt à traiter le nouveau modèle comme un candidat de plus pour les Tâches où il excelle, sans perturber le reste de votre dispositif. Nous avons déjà souligné que le choix du meilleur agent de codage compte moins que votre gestion du travail ; un tableau où trois modèles se partagent les victoires en est la démonstration chiffrée.

Le dilemme se résume ainsi en toute objectivité :

• Conservez un seul Runtime par défaut si la majorité de vos Tâches se ressemblent et qu’une seule personne valide l’ensemble des modifications. Un deuxième Runtime représente une configuration supplémentaire à maintenir, une facture en plus et de nouveaux scénarios de panne à appréhender.
• Exploitez deux ou trois Runtimes si vos Tâches se répartissent entre travail intensif dans le shell, validation d’interfaces et exploration de volumineuses bases de code — car c’est précisément sur ces axes que le tableau se divise.

Formalisez la règle de routage par écrit

Une règle de routage qui ne réside que dans la mémoire d’un développeur n’est qu’une habitude, et les habitudes ne résistent pas à une nouvelle embauche ni à l’agitation d’une semaine de lancement. Inscrivez-la là où l’équipe pourra la consulter :

Routing rule v1 (re-test after every frontier launch)

Default
  The Agent on your current default Runtime, until your own
  comparison says otherwise.

Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
  - most of the work happens in a terminal: builds, CI repair, setup  [Terminal-bench 4.0]
  - it is training or evaluation plumbing for a model pipeline        [PostTrainBench]

Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
  - the change has to be verified by driving a desktop or browser UI  [OSWorld-2.0]
  - it is scientific or data work done mostly in a terminal           [Terminal-Bench Science]

Send the Task to the Gemini CLI Agent (gemini-4-argon) when
  - it needs a very large codebase or log read in one pass            [GraphWalks]
  - note: the 1M window is shared by input, thinking and output, and
    Gemini CLI support is unverified. Smoke-test before this line routes work.

Escalate
  If a run fails its acceptance checks twice, reassign the Task to the next
  Agent in this rule. The failed runs stay on the Task as evidence.

Review
  An Agent on a different Runtime from the author reads the diff and the
  evidence. A person accepts the result.

Chaque condition précise le benchmark associé ainsi qu’un profil de Tâche aisément reconnaissable. La directive concernant la revue est la plus essentielle : faire examiner un diff par un modèle différent de celui qui l’a produit offre un second avis économique, tandis que la validation finale reste la prérogative d’un humain.

L’emplacement de cette règle dépend du responsable de l’attribution. Si ce sont les membres de l’équipe qui sélectionnent l’Assignee, elle a sa place dans les conventions écrites de l’Espace (Space). Si le routage est confié à un responsable d’Équipe (Crew leader), elle doit être intégrée dans les instructions du Crew. Dans les deux cas, le résultat est consigné au sein de la même Tâche, ce qui centralise tout l’historique des comparaisons. L’article Quel modèle pour quelle tâche de codage analyse plus en profondeur l’adéquation entre profils de tâches et rôles de modèles.

Évaluez la règle sur votre propre base de code avant de l’adopter

Une ligne de benchmark permet d’inscrire un type de Tâche sur une liste de candidats ; c’est votre propre dépôt qui doit déterminer le choix par défaut. La méthodologie présentée dans comment comparer les agents de codage sur votre propre base de code s’accorde parfaitement avec ce tableau, car celui-ci vous indique déjà les trois types de Tâches à sélectionner :

1. Une Tâche axée sur le terminal, comme la correction d’un job de CI défaillant.
2. Une Tâche dont la modification doit être contrôlée via une interface utilisateur.
3. Une question nécessitant d’intégrer une large portion du dépôt dans le contexte.

Attribuez à chaque Agent la même description de Tâche et les mêmes critères d’acceptation, en activant le mode Create temporary directory pour que chaque run dispose de son propre arbre de travail (worktree). Évaluez ensuite ce qui est concrètement consigné dans la Tâche, plutôt que ce que l’agent prétend : le diff obtenu, les vérifications réalisées et leurs résultats, les questions soulevées et le temps qu’il a fallu à un relecteur humain pour valider le travail.

Argon peut intégrer ce comparatif dès à présent, à condition qu’un prompt de test rapide d’une ligne avec gemini-4-argon s’exécute avec succès dans votre Gemini CLI. Testez ces trois mêmes Tâches sur ce modèle avant d’opérer tout autre changement. Le comparatif Opus 5.5 vs GPT-6 Sol comme Runtime par défaut détaille le volet coût par tâche achevée pour cette même décision.

Où s’exécute chaque modèle, au 15 octobre 2026

Les lignes consacrées à Gemini comportent un piège. Depuis le 18 juin 2026, Gemini CLI ne prend plus en charge les comptes Google AI Pro, Ultra ou les comptes individuels gratuits Code Assist, selon la note de transition de Google. Si les offres Pro et Ultra intègrent bien Argon dans l’application Gemini, un abonnement ne remplace pas une clé d’API, et Argon ne propose aucun palier d’API gratuit.

Sharkly n’impose aucun modèle. La documentation des Agents le formule sans détour : « L’Agent applique le modèle par défaut du Runtime. Il ne garantit ni n’affiche aucun nom de modèle particulier. » Vous paramétrez le modèle via les Custom arguments de l’Agent ou du Runtime, ou directement dans la configuration de l’outil sur le Computer. Ainsi, « l’Agent Codex » mentionné dans la règle de routage désigne un Agent associé à un Runtime Codex configuré pour exploiter Astra.

Les étapes de mise en place sont détaillées dans GPT-6 Astra dans Sharkly, Claude Opus 5.5 dans Sharkly et, pour la configuration de Gemini CLI et le passage à Argon, dans Gemini 4 Argon pour les agents de codage.

Les benchmarks évoluent, votre organisation doit rester stable

Le prochain lancement de modèle redessinera ce tableau. En revanche, tout ce qui structure votre environnement doit rester en place : la règle de routage, les Tâches, les éléments de preuve fournis par chaque run et la personne chargée d’approuver le résultat. Les agents explorent, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les permissions et valident les livrables.

Si vous souhaitez continuer à orchestrer plusieurs agents de codage plutôt que de vous enfermer dans un seul écosystème, c’est exactement pour répondre à ce défi que Sharkly a été conçu.