Gemini 4 Carbon : accès limité, benchmarks et prix

Gemini 4 Carbon n’est pas accessible au public au 29 octobre 2026 : continuez donc à livrer avec votre modèle actuel. Google DeepMind l’a annoncé le 28 octobre pour les travaux exigeants d’ingénierie et de cybersécurité. Une première place dans un classement justifie de préparer une évaluation, pas de repousser une mise en production. L’annonce de Google prévoit un déploiement à accès restreint.

À quels travaux Gemini 4 Carbon est-il destiné ?

Carbon vise les tâches qui demandent plusieurs tentatives avant d’aboutir : développement au long cours, problèmes d’ingénierie complexes et cyberdéfense. Selon Google, ses équipes internes l’ont vu travailler pendant des jours au débogage et à la correction de bases de code complexes.

Travailler sur la durée, c’est garder le cap sur une tâche malgré la multiplication des étapes. Imaginez un responsable de maintenance qui suit un bug depuis un test en échec jusque dans plusieurs fichiers, essaie une correction, découvre un second problème et reprend son correctif. L’agent est le logiciel qui entoure le modèle et lui permet d’agir, par exemple en lisant des fichiers ou en lançant des tests. La réussite dépend de l’ensemble du dispositif, outils et critères de validation compris.

Pour un fondateur, la question utile est de savoir si ce dispositif peut mener à bien une opération de maintenance récurrente qui mobilise aujourd’hui un ingénieur. Une réponse soignée à une question de code et un correctif que l’équipe accepte sont deux livrables bien différents.

Qui peut accéder à Carbon aujourd’hui ?

Google prévoit d’ouvrir l’accès d’abord à certains acteurs de la cyberdéfense pendant la semaine de l’annonce, puis à d’autres partenaires de confiance via Fairwind. L’accès aux produits sera élargi ensuite, après les retours d’expérience et l’amélioration des garde-fous. Google promet cet élargissement « dès que possible », sans donner de date.

Le Fairwind Program est le programme de Google réservé aux organisations de défense sélectionnées. Il donne la priorité aux gouvernements, aux infrastructures critiques et aux grandes plateformes technologiques essentielles. Son formulaire sert à examiner l’éligibilité : ce n’est pas une inscription donnant immédiatement accès à un modèle public. Le fondateur d’une entreprise de cybersécurité peut candidater si son organisation correspond aux critères ; un développeur d’applications généralistes ne doit pas faire dépendre ses livraisons d’une acceptation.

Les descriptions publiques des technologies du programme mentionnent toujours Argon. Pour les étapes du déploiement, référez-vous à l’annonce de Carbon ; pour les règles du programme, à la page Fairwind. Ni une candidature ni une adhésion existante ne prouvent que votre organisation dispose de Carbon.

Ce qui manque pour le déployer : l’annonce de Google ne fournit aucun identifiant public de modèle Carbon, aucune limite de contexte, aucun niveau d’abonnement dans l’application ni aucune date de disponibilité générale. La longueur des entrées d’un benchmark ne permet pas de déduire une limite d’API. Ne complétez pas ces informations en recopiant la documentation d’Argon.

Ces sources et la méthodologie d’évaluation de Google ont été vérifiées le 29 octobre 2026. Cet article dresse un état des lieux de l’accès à cette date ; aucun test direct de Carbon n’a été réalisé pour sa rédaction.

Quelle place pour Carbon par rapport à Argon ?

Gemini 4 Argon reste le modèle Gemini disponible qui sert de référence. Google a rendu Argon disponible sur Google Cloud le 13 octobre, et sa documentation tarifaire de la Gemini API mentionne un accès payant. Carbon s’appuie sur Argon, mais son annonce ne remplace pas le modèle que votre application peut appeler aujourd’hui.

Cette distinction compte pour un développeur indépendant qui maintient une intégration existante. Continuez à améliorer vos prompts, les permissions des outils et vos critères de validation sur Argon. Conservez les tâches difficiles sur lesquelles il échoue : une future évaluation de Carbon disposera ainsi d’une référence pertinente à dépasser.

Pour un directeur technique, la décision de migrer doit rester distincte de l’annonce du modèle. Réutiliser un jeu de tests est simple ; présumer que l’API se comportera à l’identique l’est beaucoup moins. Avant d’envisager un remplacement sans adaptation, vérifiez dans la documentation du futur modèle les entrées, les sorties, les outils et les limites de fonctionnement.

Notre présentation de Gemini 4 Argon détaille ses modalités d’accès et ses limites actuelles. Elles restent propres à Argon tant que Google n’a pas documenté celles de Carbon.

Que montrent les benchmarks publiés par Google ?

Dans le comparatif publié par Google, Carbon devance Argon sur toutes les évaluations présentées. Cela ne prouve pas qu’il gagne sur chaque tâche ni face à chaque concurrent. Le tableau ci-dessous reprend la fiche de benchmarks de Google. Il s’agit de résultats publiés, pas de mesures réalisées pour cet article.

Les lignes consacrées à la cybersécurité décrivent différentes étapes de la défense : trouver une faille, déterminer si elle est exploitable, puis la corriger. N’en faites pas la moyenne pour produire un score de sécurité. Pour une équipe qui évalue des travaux de maintenance, un benchmark de correction constitue un point de départ plus pertinent ; un résultat de détection répond à une autre question.

Pourquoi les conditions de test comptent-elles ?

La méthodologie d’évaluation de Google utilise généralement les réglages de raisonnement les plus élevés. Google reprend les résultats d’AA Index et de Terminal-Bench auprès d’Artificial Analysis, ceux de CWE-bench auprès de Collinear AI, et calcule lui-même les autres. La fiche réunit donc plusieurs sources d’évaluation.

Par exemple, le résultat de Google sur SEC-bench Pro repose sur un sous-ensemble de 183 tâches portant sur des moteurs JavaScript. Son évaluation sur ExploitGym utilise Antigravity, l’environnement qui exécute les outils de l’agent, sans connexion Internet et avec les mécanismes d’atténuation désactivés. OSWorld présente un sous-ensemble hors ligne et le meilleur résultat obtenu sur plusieurs exécutions. Ces conditions déterminent ce que l’on peut conclure d’un score.

Un produit qui utilise d’autres outils, permissions ou limites doit faire l’objet de sa propre évaluation. Les résultats des benchmarks ne garantissent pas que les capacités à accès restreint mobilisées pendant un test seront proposées dans le produit que votre entreprise achètera ensuite.

Pourquoi le « #1 » ne dit pas tout

« #1 » désigne la tête d’un classement précis, pas un vainqueur universel. Artificial Analysis place Carbon High en tête de l’Intelligence Index v5.0 avec 59, tout en précisant explicitement qu’aucune API n’est accessible au public. Pouvoir évaluer un modèle performant et pouvoir y accéder en tant que client sont deux choses distinctes.

La fiche de Google comporte elle-même des exceptions : avec 81.5% sur le sous-ensemble hors ligne d’OSWorld, Carbon reste derrière Claude Opus 5.5, le modèle d’Anthropic, à 87.2%. Cela suffit à écarter l’idée qu’il domine tous les usages. Choisissez l’évaluation la plus proche de votre travail avant de choisir un modèle.

Ce tableau ne permet pas non plus de trancher entre Carbon et OpenAI GPT-6.1 Terra. Sa colonne OpenAI porte sur GPT-6 Astra, qui est un autre modèle. Un résultat obtenu par Astra ne permet pas de décider si vous devez remplacer Terra dans votre workflow de développement.

Enfin, le taux de réussite de 0.0% annoncé par Google pour les attaques par injection de prompt concerne les attaques évaluées. L’injection de prompt consiste à dissimuler dans les contenus lus par un agent des instructions visant à le détourner de sa tâche. Conservez des permissions délimitées, une revue des tests et une validation des actions à conséquences importantes, même lorsqu’un modèle affiche un bon résultat.

Développeurs, responsables opérationnels, acheteurs : que faire ?

Les développeurs ont intérêt à garder le modèle qui produit déjà un travail satisfaisant. Si votre application Gemini tourne sur Argon, restez-y pendant que vous préparez le comparatif. Si votre workflow fonctionne déjà bien avec Opus 5.5 ou GPT-6.1 Terra, l’annonce de Carbon ne justifie à elle seule ni un arrêt ni une migration. Notre guide des modèles actuels présente les choix plus largement.

Les responsables opérationnels doivent rendre les tâches longues vérifiables. Le directeur technique d’une entreprise de taille intermédiaire peut retenir une correction de régression récurrente, avec un test en échec connu et un responsable clairement désigné. Un responsable opérationnel expérimenté peut exiger un journal de tâche indiquant les modifications, les vérifications effectuées et les points non résolus. Passer plus de temps à travailler n’est utile que si le résultat est correct et si la personne chargée de le relire peut s’en assurer efficacement.

Les acheteurs doivent prévoir le budget au-delà de la période de lancement. Les tokens sont les unités facturées pour les entrées et les sorties du modèle. Une exécution plus longue peut en consommer davantage, même si le correctif final est court.

Prix de Gemini 4 Carbon : $2 par million de tokens en entrée et $10 par million de tokens en sortie au lancement ; les entrées en cache bénéficient d’une réduction de 95% sur le prix des tokens en entrée ; après la période de lancement, $4 pour 1M de tokens en entrée et $20 pour 1M de tokens en sortie. L’annonce de Google et sa note de bas de page.

L’annonce de Carbon ne précise pas quand s’achèvera la période de lancement. Le changement documenté du tarif Standard d’Argon prend effet le 1er décembre 2026 : c’est une échéance budgétaire pour Argon, pas une date de sortie ni une échéance tarifaire pour Carbon. Pour le comparatif détaillé des offres, consultez la page des tarifs Gemini.

Que préparer dès cette semaine ?

Désignez dès maintenant un responsable pour constituer un jeu de tests réutilisable. Pour un fondateur qui a levé des fonds, le livrable attendu est une décision d’adoption que l’on pourra justifier dès l’ouverture de l’accès. Pour un développeur indépendant, c’est un ensemble de tâches difficiles conservées pour évaluer plus vite le prochain modèle.

1. 1

   Conservez des tâches représentatives

   Rassemblez une correction de régression, une modification touchant plusieurs fichiers, une correction de sécurité autorisée et une demande ambiguë qui devrait entraîner une demande de précision. Incluez des tâches ordinaires autant que des échecs difficiles à résoudre. Retirez les identifiants d’accès et les données clients inutiles des jeux de données de test conservés.

2. 2

   Fixez les critères de validation avant l’exécution

   Consignez la révision de départ, les fichiers autorisés, les outils disponibles, les tests à réussir et les conditions imposant un arrêt. Pour la régression, exigez à la fois la réussite du test reproduisant le bug et l’absence de modifications sans rapport avec la tâche. Une explication plausible ne vaut pas une correction terminée.

3. 3

   Mesurez votre référence avec Argon

   Exécutez ce jeu de tests avec le modèle que vous utilisez actuellement. Conservez le correctif, les résultats des tests, la consommation facturée, les nouvelles tentatives, les interruptions et le travail de revue. Il s’agit de vérifications proposées, pas de résultats mesurés pour cet article. Budgétez les usages récurrents de Gemini au tarif applicable après la période de lancement.

4. 4

   Exigez que Carbon justifie la migration

   Une fois l’accès ouvert sur votre compte et l’interface documentée par Google, reprenez les mêmes tâches avec des outils et des permissions comparables. N’élargissez l’usage que si les résultats validés s’améliorent sans hausse inacceptable du travail de revue, de la latence ou du coût. Sinon, gardez le modèle de référence qui fonctionne.

Pour des conseils pratiques sur l’adoption des modèles au fil de l’ouverture des accès, abonnez-vous à la newsletter.