Accueil / Journal / Conformité, hébergement et impact
Gemini 4 Argon : un million de jetons en sortie, et la question du contrôle
Le 30 septembre, Google a présenté Gemini 4 Argon, capable de produire jusqu'à un million de jetons d'une traite, et pour l'instant réservé à des défenseurs en cybersécurité. Nous avons lu l'annonce. Elle pose une question très concrète aux entreprises : comment contrôler ce qu'aucune équipe ne peut plus relire en entier.

Ce que Google a annoncé le 30 septembre
Le 30 septembre 2026, Google a présenté Gemini 4 Argon, son nouveau modèle de pointe. Selon l'annonce, il vise les travaux longs et complexes : ingénierie logicielle, travail de connaissance en entreprise comme le juridique et la finance, et défense en cybersécurité.
Le modèle n'est pas encore ouvert au public. Google le déploie d'abord auprès d'un groupe de défenseurs en cybersécurité de confiance, dans le cadre de son programme Fairwind. L'éditeur indique participer au processus volontaire du gouvernement américain d'accès aux modèles avant leur sortie, et prévoit d'élargir l'accès progressivement, en commençant par les clients payants de l'API et les abonnés Google AI Ultra. Aucune date n'est donnée.
L'annonce a beaucoup circulé, souvent résumée par un chiffre : un million de jetons en sortie. Nous avons lu le texte de Google en entier. Voici ce qu'il dit, ce que les résumés y ajoutent, et la question que cette annonce pose vraiment aux entreprises : comment contrôler ce qu'une machine produit en volumes qu'aucune équipe ne peut relire.
Ce que dit la source, et ce que les résumés y ajoutent
Plusieurs éléments des publications qui circulent sont confirmés par Google. La limite de sortie passe bien à un million de jetons, contre 64 000 auparavant pour les modèles Gemini. Le modèle est bien réservé, pour l'instant, à des acteurs de la cyberdéfense. Et Google met bien en avant sa résistance à l'injection de consignes et ses capacités en cybersécurité.
D'autres éléments ne viennent pas de la source. L'annonce ne compare pas cette limite à celle des modèles concurrents : l'affirmation selon laquelle la plupart des modèles de pointe plafonneraient autour de 128 000 jetons n'y figure pas. L'idée qu'Argon pourrait écrire « une dizaine de romans » d'une traite est une extrapolation : Google parle d'un raisonnement plus profond, pas de production littéraire en série. Enfin, les résultats de tests présentés comme « inédits » sont ceux de l'éditeur, sur des tests qu'il a choisis.
Ce tri compte. Une décision d'achat ou d'architecture prise sur la foi d'un résumé enthousiaste repose sur des chiffres que personne n'a vérifiés. C'est la même discipline que nous avons appliquée aux annonces d'OpenAI au DevDay et de Claude Sonnet 5.5 : une source citée est une source lue.
Un million de jetons en sortie : ce que cela change vraiment
La plupart des usages d'entreprise produisent des réponses courtes : un résumé, un courriel, une fiche, un classement. Pour eux, une limite de sortie d'un million de jetons ne change rien.
L'intérêt est ailleurs. Google explique que cette marge permet au modèle de raisonner longuement et de générer des centaines de milliers de jetons dans une seule trajectoire, pour résoudre des problèmes difficiles d'un seul tenant. Les exemples donnés sont des travaux d'ingénierie : migrer des bases de code de C et C++ vers Rust, de quelques dizaines de milliers de lignes jusqu'à plus de 800 000 lignes pour un noyau de système, ou optimiser la mémoire des centres de données de Google à partir de leurs données de profilage.
Autrement dit, la limite de sortie compte surtout pour les agents qui travaillent longtemps et produisent beaucoup : réécrire du code, traiter un grand dossier, produire une série de documents. C'est précisément là que la question du contrôle devient centrale. Un agent capable de produire en une passe ce qu'une équipe produirait en plusieurs semaines produit aussi, en une passe, autant d'occasions d'erreur.
Qui peut l'utiliser, et à quel prix
Pour l'instant, presque personne. Gemini 4 Argon est réservé aux défenseurs en cybersécurité du programme Fairwind et aux équipes internes de Google. L'ouverture aux développeurs, aux entreprises et au grand public viendra ensuite, en commençant par les clients payants de l'API et les abonnés Google AI Ultra, sans date annoncée.
Le prix est en revanche connu. Argon sera lancé à un tarif d'introduction de 2 dollars par million de jetons en entrée et 10 dollars en sortie, avec une remise de 95 % sur les jetons d'entrée en cache. Après la période d'introduction, dont la durée n'est pas précisée, le tarif passera à 4 dollars en entrée et 20 dollars en sortie.
Ce dernier point mérite attention. Un outil dont le coût d'exploitation est calculé sur un tarif d'introduction verra ce coût doubler à la fin de la période. Avec une limite de sortie aussi haute, une seule tâche mal cadrée peut aussi consommer beaucoup de jetons. Le suivi par tâche et par agent, que nous détaillons dans notre cadre CADRE, devient indispensable.
Un modèle pensé pour la cyberdéfense
Google a entraîné Argon pour la défense en cybersécurité. Selon l'annonce, il peut trouver, valider et corriger seul des vulnérabilités logicielles critiques. Google cite l'exemple de Wiz, qui l'utilise pour protéger gratuitement des infrastructures publiques critiques, et dont l'essai a mis au jour une vulnérabilité exposant des données personnelles sensibles dans un logiciel utilisé par des hôpitaux, que les modèles précédents n'avaient pas repérée.
Un détail de l'annonce dit beaucoup de la puissance de ces outils : pour les défenseurs de confiance et ses propres équipes, Google publiera Argon sans les garde-fous qui limitent habituellement ses capacités en cybersécurité. Le même outil qui trouve une faille pour la corriger pourrait la trouver pour l'exploiter. C'est pourquoi l'accès est restreint, et pourquoi Google insiste sur une ouverture par étapes.
Pour une entreprise, la conséquence est double. D'un côté, des outils de recherche de vulnérabilités beaucoup plus performants vont arriver, et il faudra les utiliser sur son propre code avant que d'autres ne le fassent. De l'autre, les attaques automatisées vont progresser au même rythme. Sécuriser ses agents et ses applications n'est plus une option, comme nous l'expliquons dans sécuriser un agent IA contre l'injection de consignes.
Les garde-fous annoncés avant l'ouverture
Google décrit quatre chantiers de sécurité à mener avant une diffusion large.
- Empêcher les usages malveillants. Le modèle doit refuser les demandes dangereuses en cybersécurité et dans les domaines chimique, biologique, radiologique et nucléaire, tout en laissant passer la recherche légitime. Google surveille aussi l'activité interne du modèle pour repérer les abus.
- Résister à l'injection de consignes. Google présente Argon comme son modèle le plus résistant aux injections indirectes, ces instructions malveillantes cachées dans un document ou une page que le modèle lit. Il se classe en tête sur le test de Gray Swan consacré à ce type d'attaque.
- Surveiller les écarts de comportement. Un dispositif surveille le raisonnement et les actions du modèle, et arrête l'exécution quand il sort des intentions de l'utilisateur.
- Isoler les environnements de test. Les environnements où le modèle est entraîné et évalué sont isolés et scellés avant les essais à risque.
Ces mesures sont celles de l'éditeur, sur son modèle. Elles ne remplacent pas celles que doit prendre l'entreprise qui l'utilise : limiter les accès de l'agent, valider ce qui engage, conserver des traces. Un modèle très résistant à l'injection reste un modèle qui lit des contenus qu'on ne contrôle pas.
Le vrai sujet : contrôler ce qu'on ne peut plus relire
La question soulevée par cette annonce dépasse Argon. Quand un modèle peut produire en quelques minutes des centaines de milliers de lignes de code ou de texte, la relecture humaine intégrale devient impossible. Faut-il alors confier la relecture à l'IA elle-même ? En partie, oui, mais pas seulement, et pas n'importe comment.
Google donne lui-même la réponse dans son annonce. Ses migrations de code vers Rust, précise-t-il, font l'objet d'audits automatisés et manuels rigoureux, de tests en émulation et de revues avant toute mise en production. Le contrôle ne repose pas sur une relecture ligne à ligne, mais sur un dispositif.
Dans nos projets, ce dispositif tient en cinq principes.
- Des tests avant la production. Ce que l'agent produit doit passer une batterie de tests écrits à l'avance, sur des cas réels. Un résultat qui échoue ne passe pas, quelle que soit sa longueur.
- Des contrôles automatiques indépendants. Vérifier les chiffres contre la source, comparer avec une version de référence, mesurer les écarts. Un second modèle peut y contribuer, mais il ne remplace pas une règle déterministe.
- Un découpage en lots relisables. Plutôt qu'une production géante, des livraisons de taille raisonnable, chacune avec son périmètre et ses tests. Ce qui ne peut pas être relu ne doit pas être livré d'un bloc. Cela vaut pour le code comme pour une série de documents ou de réponses clients.
- Une relecture humaine ciblée. L'humain ne relit pas tout. Il relit ce qui engage l'entreprise, un échantillon tiré au hasard et tout ce que les contrôles ont signalé.
- Une trace de ce qui a été fait. Chaque production garde la version du modèle, les consignes et les contrôles passés, pour pouvoir revenir en arrière.
Ce sont les mêmes conditions que celles qui séparent un prototype d'un outil en production, que nous détaillons dans POC métier : isoler les prérequis de mise en production.
Se préparer dès maintenant : six chantiers concrets
Argon n'est pas disponible, mais les modèles qui produisent beaucoup et longtemps sont déjà là. Voici ce qu'une entreprise qui utilise ou prépare des agents peut faire dès aujourd'hui, sans attendre la prochaine annonce.
1. Repérer les agents qui produisent en volume. Faites l'inventaire des outils qui génèrent de longs contenus : code, rapports, réponses en série, fiches produits. Ce sont eux qui profiteront des nouveaux modèles, et eux qui exposent le plus aux erreurs non vues. Pour chacun, notez qui relit aujourd'hui, et combien de temps cela prend réellement.
2. Fixer des plafonds par tâche. Une limite technique d'un million de jetons ne signifie pas qu'il faut la laisser ouverte. Chaque tâche peut avoir sa limite de sortie, sa durée maximale et son budget. Un agent qui dépasse ces bornes s'arrête et signale, au lieu de continuer à produire et à consommer. Ce réglage protège à la fois la qualité et la facture.
3. Écrire les tests avant de changer de modèle. Le jeu d'essai est ce qui permet de comparer un modèle à un autre sur vos propres cas. Sans lui, chaque nouvelle annonce relance le même débat, tranché à l'intuition. Avec lui, l'évaluation d'Argon, le jour venu, prendra quelques heures.
4. Garder le modèle interchangeable. Un outil construit autour d'un seul fournisseur doit être en partie réécrit pour en changer. Un outil où l'appel au modèle reste isolé derrière une interface simple peut tester un nouveau modèle sans toucher au reste. C'est un choix d'architecture à faire au début du projet, pas au moment où l'on veut migrer.
5. Tester la sécurité de son propre code. Si des modèles de plus en plus capables de trouver des failles arrivent, mieux vaut que vos équipes ou vos prestataires les trouvent en premier. Un audit de vos applications exposées, et en particulier des agents qui lisent des contenus extérieurs, est un bon point de départ.
6. Décider qui répond de quoi. Pour chaque agent, une personne doit être responsable de ce qu'il produit, des contrôles qui l'encadrent et de la décision d'en changer le modèle. Sans responsable désigné, les contrôles s'effritent dès que l'outil fonctionne bien.
Ce que nous en retenons
Gemini 4 Argon n'est pas encore utilisable par les entreprises, et ses résultats restent ceux de Google. Il n'y a donc rien à décider aujourd'hui, sinon une chose : se préparer. Un jeu d'essai sur vos propres cas, un suivi des coûts par tâche et des contrôles automatiques vous permettront d'évaluer Argon le jour de sa sortie, comme n'importe quel autre modèle, sans dépendre des classements.
La question soulevée par l'annonce, elle, est déjà actuelle. Les modèles produisent plus vite qu'on ne peut relire, et l'écart va se creuser. La réponse n'est pas de tout relire, ni de tout confier à l'IA, mais de construire des outils dont la sortie est contrôlée par conception.
Si vous voulez savoir comment encadrer la production de vos agents, ce qui doit être testé, vérifié ou relu par un humain, notre diagnostic IA part de vos processus réels et de vos exigences de contrôle.
Sources
Questions fréquentes
Peut-on utiliser Gemini 4 Argon aujourd'hui ?
Non, sauf à faire partie du programme Fairwind de Google, réservé à des défenseurs en cybersécurité de confiance. Google prévoit d'ouvrir ensuite l'accès aux clients payants de l'API et aux abonnés Google AI Ultra, sans date annoncée.
Un million de jetons en sortie, est-ce utile pour une PME ?
Rarement de façon directe : la plupart des usages produisent des réponses courtes. La limite compte pour les agents qui travaillent longtemps, comme une migration de code ou le traitement d'un grand dossier. C'est aussi là que le coût et le contrôle doivent être les mieux encadrés.
Combien coûtera Gemini 4 Argon ?
Google annonce un tarif d'introduction de 2 dollars par million de jetons en entrée et 10 dollars en sortie, puis 4 et 20 dollars après la période d'introduction, dont la durée n'est pas précisée. Un budget calculé sur le tarif d'introduction doit prévoir ce doublement.
Peut-on confier la relecture d'une production IA à une autre IA ?
En partie. Un second modèle peut signaler des incohérences, mais il ne remplace ni les tests écrits à l'avance, ni les contrôles déterministes, ni une relecture humaine ciblée sur ce qui engage l'entreprise.
Faut-il attendre Argon pour lancer un projet ?
Non. Un projet bien conçu traite le modèle comme un paramètre que l'on peut changer. Si Argon se révèle meilleur sur vos cas le jour de sa sortie, un jeu d'essai et une bascule progressive permettront de l'adopter sans tout reconstruire.