Gemini 4 Argon est disponible pour tous depuis le 13 octobre 2026, repoussant le plafond de génération de Google de 64 000 tokens à environ 1 million, ce qui permet au modèle de « générer des centaines de milliers de tokens en une seule trajectoire ». Le guide pour développeurs de Google détaille son fonctionnement. Par défaut, une requête classique s'arrête toujours à 65 536 tokens de sortie. Si vous augmentez max_output_tokens sur l'API Interactions avec background: true, le serveur poursuit sa génération par paliers pouvant atteindre 64 000 tokens jusqu'à la limite fixée, soit jusqu'à 1 048 576 tokens moins vos tokens d'entrée. Google prévient toutefois que les invites complexes peuvent prendre plusieurs minutes.
La phrase qui mérite une seconde lecture dans le billet d'annonce ne concerne pas cette limite, mais l'usage qu'en a fait Google. L'entreprise indique avoir utilisé Argon en interne pour des migrations de C/C++ vers Rust allant de « dizaines de milliers de lignes dans des bibliothèques fondamentales comme re2 et libgav1 jusqu'à plus de 800 000 lignes pour le noyau Zircon de Fuchsia », et précise que ces réécritures font « l'objet d'audits rigoureux, manuels comme automatisés, de tests en émulation et de revues approfondies avant leur déploiement en production ». Le laboratoire même qui a entraîné le modèle procède à des revues avant toute mise en production. Une équipe dont les agents peuvent désormais renvoyer des résultats sous un plafond seize fois plus élevé a d'abord besoin d'une stratégie de revue avant d'avoir besoin du modèle.
En résumé
Une limite de génération d'un million de tokens déplace le goulot d'étranglement : le problème n'est plus de générer du code, mais de le valider. Puisqu'une seule exécution peut désormais produire un tel volume, découpez le travail en tâches qu'une personne peut relire d'une seule traite, chacune assortie d'une définition du « terminé » explicite et d'un délai d'expiration propre, exigez des preuves tangibles pour chaque tâche, et évaluez d'abord votre capacité de relecture. Les agents explorent, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les autorisations et valident le résultat.
Ce qui change lorsqu'une seule exécution peut produire autant
La capacité de revue correspond au nombre de livrables d'agents qu'une équipe est capable de lire, d'évaluer et de valider en une journée, et elle dépend des humains, pas du modèle. Un plafond de génération plus élevé ne fait qu'augmenter le volume susceptible d'arriver d'un seul coup.
L'ancien plafond jouait involontairement le rôle de garde-fou sur le périmètre : une réponse ne pouvant dépasser une certaine longueur, le travail était nécessairement fragmenté, ponctué de points d'arrêt naturels. La justification avancée par Google pour cette nouvelle limite va dans le sens inverse : offrir la marge nécessaire pour « résoudre des problèmes complexes d'une seule traite ». Pour un relecteur, « d'une seule traite » signifie un résultat unique, une décision unique et aucun point d'étape où un humain aurait pu dire « mauvaise direction ».
Ce plafond est en outre partagé. La fenêtre de 1 048 576 tokens d'Argon englobe simultanément l'entrée, le raisonnement et la sortie. Ainsi, une exécution qui ingère 300 000 tokens de code ne dispose plus que d'environ 748 000 tokens pour réfléchir et rédiger. Cela reste bien plus que ce qu'un humain peut lire ligne à ligne en une seule séance.
Vient ensuite la question de la qualité. Lors de l'annonce, Bloomberg a rapporté les propos d'employés anonymes de Google affirmant qu'Argon décevait sur certaines tâches de programmation et de front-end par rapport à ses benchmarks, ce que Google a qualifié d'inexact. Le propre tableau de Google montre qu'Argon est à la traîne sur deux de ses quatre bancs d'essai de développement agentique (notre comparatif les passe en revue). Un benchmark n'est qu'une promesse sur un jeu de test. Votre diff, lui, engage directement votre base de code, et ne peut être validé que sur preuves, quel que soit le modèle qui l'a rédigé.
Cadrez la tâche, pas le budget de tokens
L'unité que vous maîtrisez est la tâche, non le nombre de tokens. Laissez le plafond du modèle dicter l'ampleur du travail, et vous obtiendrez le résultat le plus volumineux qu'il puisse produire. Définissez-la vous-même, et vous obtiendrez des résultats qu'un humain peut valider. Les recommandations de Google abondent d'ailleurs dans ce sens : conservez la valeur par défaut de 65 536 tokens pour les tâches courantes, et utilisez le mode arrière-plan à 131 072 ou 262 144 tokens pour les raisonnements complexes et le code, sans viser le maximum.
La description fournie par Google découpe déjà le travail par bibliothèque et par noyau. Faites de même pour un portage : une tâche par module, qu'un relecteur peut examiner d'une traite. Dans Sharkly, cela se traduit par une tâche parente assortie d'une sous-tâche par module, ainsi que de liens « bloque / est bloqué par » lorsqu'un module doit impérativement aboutir en premier. L'objectif, le périmètre et les critères d'acceptation figurent dans la description de la tâche, aussi bien pour l'agent que pour le relecteur :
SH-412 Port the tokenizer module to Rust
Parent: SH-400 Port the parser library to Rust
Blocked by: SH-411 Port the shared buffer types
Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work
Deux paramètres de l'agent viennent renforcer cette approche. Le délai d'expiration par tâche est calibré selon la tâche, et non selon le modèle : supérieur au temps d'exécution raisonnable pour un module, mais inférieur au seuil où vous regretteriez la facture. La simultanéité maximale (tâches attribuées) limite le nombre de modules en cours de traitement, car quarante sous-tâches lancées de concert débouchent sur quarante livrables en attente du même relecteur.
La règle d'arbitrage est simple : confiez l'ensemble du travail à une seule exécution lorsque des vérifications automatisées suffisent à couvrir l'intégralité du résultat, comme pour un renommage mécanique validé par le compilateur et une suite de tests complète. Fractionnez-le dès qu'un humain doit intervenir pour évaluer la moindre partie — ce qui représente l'essentiel du travail lors d'une migration de langage. Les exécutions qui dépassent votre journée de travail exigent les mêmes prérequis : une condition d'arrêt, un état d'attente et un responsable désigné pour prendre le relais au matin.
Rattachez les éléments de preuve à la tâche
Un résultat volumineux dépourvu de preuves n'appelle pas une revue : il oblige un humain à refaire le travail pas à pas, au ralenti.
L'exemple de libgav1 illustre parfaitement ce qu'est une preuve solide. Google indique qu'Argon a réécrit 32 000 lignes de code SIMD au sein d'un portage Rust existant, et que le résultat « s'exécute 2,7 fois plus vite que le portage Rust d'origine, avec une sortie vidéo strictement identique ». C'est précisément cette seconde partie de phrase qui rend ces 32 000 lignes vérifiables : les mêmes entrées ont traversé l'ancien et le nouveau code, produisant des sorties identiques. C'est le principe même des tests différentiels, et cela libère le relecteur pour ce qu'une simple comparaison ne peut appréhender : le code unsafe, le traitement des erreurs et la tenue des gains de performance sur des charges réelles.
Chaque exécution devrait consigner quatre éléments dans la tâche :
| Éléments de preuve sur la tâche | Question du relecteur à laquelle ils répondent |
|---|---|
| Résumé des modifications | Qu'est-ce qui a changé, où et pourquoi ? |
| Résultats des tests, du typage et du build | Le code valide-t-il toujours les contrôles auxquels nous faisons déjà confiance ? |
| Ce qui a été vérifié et comment | Le comportement est-il resté identique, et sur quelles entrées ? |
| Limites connues | Que dois-je vérifier moi-même ? |
C'est exactement la structure définie par le flux de travail de Sharkly : l'agent lance la vérification des types, les tests et le build, puis joint le résumé des modifications, les résultats des vérifications et les limites connues ; un humain valide, demande des corrections ou autorise la fusion et le déploiement. La réponse finale de l'agent est enregistrée sur la tâche et le journal d'exécution se trouve dans l'onglet Exécutions, de sorte que les preuves reviennent directement dans la tâche plutôt que dans un terminal. L'article sur la revue de code avec preuves au niveau de la tâche détaille l'ordre de lecture recommandé, et les modèles de transmission confèrent au rapport un format standardisé.
Réussir les vérifications automatisées ne vaut pas acceptation, pas plus qu'une fusion : dans Sharkly, fusionner une pull request liée ne modifie pas le statut de la tâche. Les contrôles automatiques vérifient ce qu'ils peuvent, et notre article sur les agents de revue de code par IA montre où s'arrêtent leurs capacités. Il appartient à un humain de déterminer si la modification répond bien à ce que demandait la tâche.
Calculez votre capacité de relecture avant de lancer l'exécution
La relecture fonctionne comme une file d'attente : les résultats arrivent, un relecteur les traite, et si le flux entrant dépasse le rythme de traitement, la file s'allonge. Une limite de génération accrue ne modifie que le côté des arrivées. Voici une simulation chiffrée, basée sur des hypothèses théoriques plutôt que sur un projet réel :
| Paramètre d'exemple (hypothétique) | Valeur |
|---|---|
| Modules concernés par la migration | 40 |
| Temps de relecture par module, diff seul | 2 heures |
| Temps de relecture par module, avec preuves différentielles et résumé | 30 minutes |
| Heures qu'un relecteur peut consacrer quotidiennement à une revue approfondie | 3 |
En se basant uniquement sur le diff, la migration requiert 80 heures de relecture, soit environ 27 jours ouvrés. Avec des preuves fournies pour chaque tâche, elle ne demande plus que 20 heures, soit environ sept jours. Qu'il s'agisse d'une exécution géante ou de quarante plus petites, la charge de travail côté relecteur reste rigoureusement identique.
Ce qui change en revanche, c'est la prise de décision. Quarante tâches arrivent à un rythme que vous maîtrisez, et chacune fait l'objet de son propre verdict. Un résultat unique couvrant l'ensemble des quarante modules ne reçoit qu'un seul verdict : un problème sur le module 31 bloque donc les 39 autres. Avec des sous-tâches, un simple commentaire sur le module défaillant permet de relancer une exécution corrective sur cette tâche précise pendant que les autres poursuivent leur cours.
Faites ensuite le calcul des coûts. Une exécution poussée au maximum génère environ 1 million de tokens de sortie, soit près de 10 $ au tarif de 10 $ par million valable jusqu'au 30 novembre, et environ 20 $ à compter du 1er décembre. Pour un projet de niveau Tier 1, le plafond de dépenses fixé par Google est de 10 $ par tranche glissante de 10 minutes : une seule exécution maximale consomme donc l'intégralité du plafond d'une tranche au tarif actuel, et deux fois ce plafond à partir du 1er décembre. Veillez donc à maintenir une simultanéité maximale faible pour tout agent autorisé à exécuter des traitements aussi longs.
Faites vos propres calculs avant la première exécution d'envergure, et non une fois la file d'attente engorgée. Notre article sur le calcul de la capacité de relecture détaille cette même arithmétique à l'échelle d'une équipe, tandis que celui sur la relecture humaine comme goulot d'étranglement présente les statuts et jalons qui permettent de visualiser clairement la file d'attente.
Check-list avant votre première exécution à un million de tokens
- [ ] Le travail est découpé en tâches qu'un relecteur peut achever d'une traite, avec des sous-tâches et des dépendances « bloqué par ».
- [ ] Chaque description de tâche explicite la définition du « terminé » et ce qui est hors périmètre.
- [ ] Le délai d'expiration par tâche est adapté à la tâche (les requêtes longues en arrière-plan prennent plusieurs minutes), et non à la limite de sortie du modèle.
- [ ] Une exécution poussée au maximum respecte le plafond de dépenses de votre niveau d'API (Tier).
- [ ] La simultanéité maximale de l'agent pour les tâches attribuées correspond au volume que les relecteurs peuvent traiter, et non à ce que la machine peut exécuter.
- [ ] Chaque exécution renvoie un résumé des modifications, les résultats des contrôles, ce qui a été vérifié et les limites connues.
- [ ] Tout travail devant préserver le comportement initial intègre un test différentiel par rapport à l'ancien code.
- [ ] Chaque tâche a un relecteur nommément désigné, et l'acceptation découle du changement de statut effectué par cette personne, jamais d'un effet de bord d'une fusion.
Rien de tout cela n'est propre à Argon, que n'importe quelle clé d'API Gemini payante peut désormais interroger. La formule de Google trace la marche à suivre : un volume de sortie massif, suivi d'audits, de tests en émulation et de revues, puis le déploiement en production. Quel que soit le laboratoire à l'origine du prochain bond de capacité de génération, la méthode repose sur la tâche, et non sur le modèle. Sharkly ne choisit pas de modèles : selon la documentation sur les agents, un agent suit le modèle par défaut de son Runtime, modifiable via des arguments personnalisés ou dans la configuration de l'outil. Lorsqu'un modèle plus puissant intègre un Runtime que vous utilisez, cette valeur change, tandis que les tâches, les preuves et le sas de revue restent inchangés. Le contexte, l'avancement, les blocages, les résultats et la relecture humaine restent visibles de la demande initiale jusqu'à la mise en production.
Si vous faites déjà tourner plusieurs agents, Sharkly vous offre un espace centralisé pour gérer leurs tâches et leurs résultats.
