Google réserve Gemini 4 Carbon aux cyberdéfenseurs avant tout le monde
Le 28 octobre 2026, Google DeepMind a annoncé Gemini 4 Carbon, un modèle frontier taillé pour la cybersécurité et ouvert d’abord à un sous-ensemble de défenseurs. Les scores sont spectaculaires, mais l’accès est fermé : voici ce qu’un RSSI doit en retenir dès maintenant.
28 octobre 2026. Google DeepMind a annoncé Gemini 4 Carbon, son « modèle le plus puissant », en première position de l’Artificial Analysis Intelligence Index v5.0 avec un score de 59. Deux semaines après Gemini 4 Argon, le nouveau modèle affiche des gains massifs sur la détection de vulnérabilités, l’exploitation et le correctif — la boucle complète de la défense. Le point qui compte : Google ne le met pas sur le marché. Il le réserve d’abord à un sous-ensemble de cyberdéfenseurs, puis aux partenaires de son programme Fairwind, avant les développeurs, les entreprises et le grand public. Un modèle frontier dont la première porte est une porte de sécurité, ce n’est pas anodin.
Un modèle noté sur sa capacité à trouver, exploiter et corriger
La communication de Google est construite autour de trois benchmarks, présentés « évalués sans garde-fous » :
- Trouver : 88,2 % sur SEC-bench Pro, un score présenté comme l’état de l’art pour déceler des failles réelles enfouies dans du code de production.
- Valider : 54,8 % sur ExploitGym, un benchmark d’exploitation destiné à trier les vulnérabilités vraiment exploitables de celles qui ne le sont pas.
- Corriger : 71,0 % sur CWE-bench, qui mesure la transformation d’un constat en correctif de code fonctionnel.
À ces chiffres s’ajoutent deux affirmations internes fortes : une résistance à l’injection indirecte mesurée à 0,0 % de taux de succès d’attaque sur le benchmark Gray Swan IPI (contre 0,7 % pour Argon), et une génération de code sûr plus de deux fois meilleure que celle d’Argon. L’équipe Chrome affirme que Carbon produit des correctifs « plus de 10 fois meilleurs » qu’un autre grand modèle frontier.
Un détail mérite d’être souligné : sur Terminal-Bench 4.0, Carbon aurait ramené la triche réussie à 0,0 %, avec des tentatives tombées à 0,4 %. Autrement dit, le modèle ne se contente pas de mieux répondre — il triche moins, un point sensible pour quiconque confie du code de production à un agent.
Une porte d’entrée fermée, par choix
Le fait le plus inhabituel n’est pas la performance, c’est le séquencement d’accès. Google annonce être « activement engagé » dans le processus volontaire de test pré-diffusion du gouvernement américain, puis déroule trois cercles concentriques : les cyberdéfenseurs d’abord, les partenaires Fairwind ensuite, et seulement après les développeurs, les entreprises et les consommateurs via les produits grand public.
Cette stratégie change le rapport de force habituel. D’ordinaire, un modèle frontier est ouvert aux développeurs payants le jour même. Ici, l’argument implicite est double : d’abord, les capacités offensives du modèle (ExploitGym à 54,8 %, c’est littéralement un score d’exploitation) justifient qu’on ne le confie pas à n’importe qui ; ensuite, Google veut recueillir du retour sur ses garde-fous avant une diffusion large. Le corollaire est plus gênant : au moment de l’annonce, personne en dehors de ce cercle ne peut vérifier les chiffres.
Le prix, lui, est déjà public : 2 $ par million de jetons en entrée et 10 $ en sortie au lancement, les jetons mis en cache étant facturés 95 % moins cher. Après la période d’introduction, la grille monte à 4 $ et 20 $. C’est la même grille d’introduction qu’Argon — un signal que Carbon n’est pas pensé comme un produit de niche, mais comme le prochain modèle par défaut de la gamme Gemini.
Ce qu’un RSSI doit en faire dès maintenant
Il faut séparer ce qui est vérifiable de ce qui ne l’est pas. Les benchmarks cités sont autodéclarés et le modèle est inaccessible au commun des équipes ; aucune évaluation indépendante ne peut encore confirmer les 88,2 % de SEC-bench Pro ni le 0,0 % d’injection. La prudence impose donc de traiter ces chiffres comme un objectif affiché, pas comme un constat.
Cela n’empêche pas d’en tirer trois conséquences concrètes :
- La cybersécurité devient un champ de bataille de modèles. Quand un acteur de la taille de Google positionne un frontier sur « trouver, valider, corriger », les équipes de défense qui n’ont pas de stratégie d’IA défensive prennent du retard, pas un risque théorique.
- La résistance à l’injection devient un critère d’achat. Un 0,0 % d’attaque réussie sur Gray Swan IPI est exactement la métrique qu’un RSSI doit exiger de ses fournisseurs d’agents — et qu’il doit pouvoir auditer, pas seulement lire dans un communiqué.
- L’accès conditionné est un précédent. Si Google réserve ses capacités offensives aux défenseurs, cela valide l’idée que l’exploitation automatisée est désormais une capacité sensible à contrôler. Attendez-vous à ce que les régulateurs s’en emparent.
# Ce que vous pouvez auditer dès aujourd'hui sans accès à Carbon :
# 1. Vérifier la résistance à l'injection de VOS agents en production
# (benchmark Gray Swan IPI public, ou un banc interne de prompts indirects)
# 2. Suivre les scores publics du modèle sur les trois benchmarks cités
# (SEC-bench Pro, ExploitGym, CWE-bench) une fois des tiers les publient
# 3. Préparer la bascule de grille tarifaire : 2$/10$ -> 4$/20$ après l'introDes garde-fous chiffrés, pas seulement des benchmarks
Au-delà des scores bruts, Google a publié des métriques d’alignement qui intéressent directement un exploitant : Carbon réduirait l’excès de portée de 26 % et le sous-service de 29 %, couperait les affirmations non étayées d’un facteur 2 par rapport à Argon, et ferait chuter les alertes de désalignement de haute sévérité de près de 80 % dans les environnements de codage internes. Sur WebDev Arena, il gagne 89 points ELO et se classe quatrième (1 768).
Ces chiffres sont aussi autodéclarés, mais ils décrivent un comportement précis : un agent qui reste « strictement dans le périmètre » et qui remonte les divergences avant d’agir est exactement ce qu’on veut confier à une tâche de correctif de sécurité. Le risque d’un modèle qui invente un correctif est pire que celui d’un modèle qui ne le propose pas — d’où l’importance du « 0,0 % de triche » sur Terminal-Bench 4.0.
Verdict
Si vous êtes un défenseur en position d’accéder au programme, demandez l’accès maintenant : un modèle qui promet de trier les vulnérabilités exploitables (ExploitGym) et de produire des correctifs de cause racine (CWE-bench) vaut d’être testé sur votre propre code avant qu’il ne soit généralisé. Si vous n’y avez pas accès, ne fondez aucune décision sur les chiffres annoncés : ce sont des scores autodéclarés sur un modèle fermé, et la seule posture saine est de les traiter comme un objectif à auditer dès que des évaluations indépendantes paraîtront. Et dans tous les cas, retenez la leçon structurelle : la cybersécurité est devenue un marché où les fournisseurs de modèles se font concurrence sur la capacité à trouver et exploiter des failles, pas seulement à répondre. Votre feuille de route d’IA défensive — modèles, bancs d’injection, audits — n’est plus optionnelle ; elle détermine si vous utilisez ces outils ou si ce sont eux qui vous testent.