Gemini 4 Carbon peut exploiter des failles, Google le réserve à quelques spécialistes

Un modèle capable de repérer une faille n’est déjà plus une simple aide au développeur. Avec Gemini 4 Carbon, Google revendique aussi la capacité de produire des étapes d’exploitation — et réserve d’abord cette puissance à un cercle limité de spécialistes de la cybersécurité.

Google positionne Carbon sur le terrain offensif

Présenté le 28 octobre 2026, Gemini 4 Carbon est décrit par Google comme son modèle le plus avancé pour la cybersécurité et les tâches longues de programmation. Sa particularité ne tient pas seulement à la détection de vulnérabilités : le modèle a été évalué sur l’ensemble de la chaîne, de l’identification d’une faiblesse jusqu’à sa correction, en passant par son exploitation.

Les résultats communiqués par l’entreprise sont élevés. Carbon atteint 88,2 % sur SEC-bench Pro pour trouver des vulnérabilités, 54,8 % sur ExploitGym pour les exploiter et 71 % sur CWE-bench pour les corriger. Google affirme également que le modèle génère du code sécurisé avec un taux de réussite plus de deux fois supérieur à celui de Gemini 4 Argon lors de tests internes.

Cette combinaison est stratégique. Un modèle qui signale une faille peut accélérer un audit ou aider un développeur à sécuriser une application. Un modèle qui sait aussi construire une méthode d’exploitation se rapproche davantage des outils utilisés lors d’opérations offensives — avec les risques que cela implique si l’accès n’est pas contrôlé.

Une progression de l’analyse vers l’action

La détection et la correction de failles sont déjà des usages recherchés de l’IA dans les équipes de sécurité. L’exploitation ajoute une dimension plus sensible : elle permet de vérifier si une vulnérabilité est réellement exploitable, dans quelles conditions et avec quelles conséquences.

Sur le papier, cette capacité peut servir à réduire les faux positifs et à hiérarchiser les urgences. Une faille théorique mais impossible à exploiter ne présente pas le même risque qu’une vulnérabilité permettant d’obtenir un accès ou d’exécuter du code. Pour les défenseurs, simuler ces scénarios peut donc améliorer la qualité des audits.

Mais cette logique fonctionne dans les deux sens. La même automatisation peut réduire le temps nécessaire à la préparation d’une attaque, notamment lorsque la recherche porte sur de grandes quantités de code. L’enjeu ne réside plus seulement dans la précision du modèle, mais dans son accès aux environnements, aux outils et aux données nécessaires pour passer d’une analyse à une action.

L’accès commence avec Fairwind, pas avec le grand public

Google ne déploie pas Carbon comme un modèle généraliste immédiatement accessible. La première phase passe par Fairwind, un programme destiné à un groupe de défenseurs de la cybersécurité. Cette distribution au compte-gouttes constitue le principal garde-fou annoncé autour du modèle.

Le choix est cohérent avec le profil de Carbon. Les spécialistes sélectionnés peuvent tester ses performances dans des contextes encadrés, mesurer ses erreurs et identifier les comportements susceptibles de faciliter une utilisation malveillante. Pour Google, cette phase permet aussi d’observer les limites du modèle avant une éventuelle extension de sa disponibilité.

Le dispositif pose toutefois une question centrale : quels critères déterminent l’accès et comment les utilisateurs sont-ils contrôlés ? La sélection d’experts ne suffit pas à elle seule à garantir un usage défensif. Il faut également surveiller les requêtes, limiter les actions exécutables, protéger les informations sensibles et pouvoir révoquer rapidement les accès.

La distinction entre analyse et exploitation sera particulièrement importante. Autoriser un modèle à expliquer pourquoi un morceau de code est vulnérable n’offre pas le même niveau de risque que lui permettre de générer automatiquement une chaîne d’attaque testable contre une cible réelle. Les mécanismes de filtrage devront donc être plus fins qu’un simple blocage de mots-clés.

Des scores impressionnants, mais difficiles à traduire en risque réel

Les résultats publiés donnent une indication claire sur l’ambition de Google, mais ils ne suffisent pas à mesurer la performance de Carbon dans une infrastructure réelle. Les benchmarks évaluent des scénarios définis à l’avance, avec des tâches et des critères de réussite déterminés. Ils permettent de comparer des modèles, sans reproduire toute la complexité d’un environnement de production.

Le score de 54,8 % sur ExploitGym est particulièrement révélateur : Carbon est présenté comme performant pour exploiter des vulnérabilités, mais il échoue encore dans près de la moitié des cas évalués. Cette limite peut réduire le risque d’automatisation totalement fiable. Elle peut aussi obliger un opérateur à contrôler chaque étape, ce qui conserve une place importante à l’expertise humaine.

Le taux de 88,2 % sur SEC-bench Pro doit lui aussi être interprété avec prudence. La capacité à détecter une faiblesse dépend de la qualité du code fourni au modèle, de la visibilité sur son contexte et de la nature des vulnérabilités recherchées. Dans une application complexe, les dépendances, les configurations et les interactions entre services peuvent modifier fortement le résultat.

Quant au chiffre de 71 % sur CWE-bench, il suggère que la correction automatisée progresse, sans garantir qu’un correctif soit complet ou qu’il n’introduise pas une nouvelle faille. Une modification qui fait disparaître un test vulnérable peut aussi dégrader les performances, casser une fonctionnalité ou déplacer le problème ailleurs dans l’application.

Un prix conçu pour les usages intensifs

Google annonce un tarif de lancement de 2 dollars par million de tokens en entrée et 10 dollars par million de tokens en sortie. Le coût de sortie est donc cinq fois supérieur à celui de l’entrée, un écart qui reflète probablement la complexité des réponses produites par un modèle destiné aux tâches longues de programmation et d’analyse.

À première vue, ces tarifs peuvent sembler accessibles aux grandes équipes de sécurité, aux éditeurs de logiciels et aux plateformes d’audit automatisé. Le calcul change lorsque les requêtes portent sur de vastes bases de code, génèrent de nombreuses hypothèses ou nécessitent plusieurs itérations pour tester et corriger une vulnérabilité. La facture dépendra moins du prix unitaire que du volume d’analyses et du degré d’autonomie accordé au modèle.

Cette structure tarifaire pourrait aussi favoriser les usages hybrides : Carbon pour les dossiers complexes et les investigations à forte valeur, des modèles moins coûteux pour le tri initial, la documentation ou les corrections simples. Le modèle ne devient pas nécessairement l’outil unique d’un centre de sécurité, mais plutôt une brique spécialisée dans les étapes les plus exigeantes.

Le prochain test sera celui de la gouvernance

Avec Gemini 4 Carbon, Google ne vend pas uniquement un modèle plus performant en programmation. L’entreprise met sur le marché une capacité d’analyse capable de franchir la frontière entre repérage, validation et exploitation d’une faille. La restriction initiale via Fairwind montre que Google considère cette puissance comme suffisamment sensible pour justifier un déploiement progressif.

Le prochain jalon concret sera l’évaluation des retours du programme : taux de détection confirmé, qualité des correctifs, nombre de faux positifs, échecs d’exploitation et incidents liés à l’usage du modèle. Ces indicateurs permettront de vérifier si les scores annoncés se traduisent par des gains mesurables pour les équipes défensives — sans fournir aux attaquants un raccourci équivalent.