Un seul modèle trouve, exploite et corrige désormais la faille

La même semaine, un modèle d'IA a prouvé qu'il pouvait enchaîner des exploits fonctionnels sur cinq systèmes d'exploitation différents, et un autre modèle d'IA est arrivé en affirmant qu'il peut trouver, exploiter et corriger les vulnérabilités mieux que tout ce qui l'a précédé. Ce n'est pas une coïncidence. C'est le nouveau plancher.

Mercredi, Google DeepMind a dévoilé Gemini 4 Carbon. Koray Kavukcuoglu, SVP chez Google DeepMind, a posé les chiffres sans détour : Carbon atteint 88,2 % sur SEC-bench Pro pour la découverte de vulnérabilités, 54,8 % sur ExploitGym pour l'exploitation et 71,0 % sur CWE-bench pour le patch. Il prend aussi la tête de l'Artificial Analysis Intelligence Index avec 59, devant Claude Opus 5.5 d'Anthropic à 58 et GPT-6 Astra d'OpenAI à 57. Et selon Google, il est deux fois plus susceptible de générer du code sûr que le modèle qu'il remplace, Gemini 4 Argon.

Prenez une seconde pour laisser ça infuser. Un modèle. Le même modèle. Il trouve la faille, la transforme en arme et la corrige. Trois catégories de benchmarks qui décrivaient autrefois trois métiers complètement différents.

Ce que disent vraiment ces trois chiffres

La plupart des articles sur les benchmarks de sécurité se ressemblent et finissent par se confondre. Ces trois-là, non, parce que chacun correspond à une étape distincte du cycle de vie d'un incident.

SEC-bench Pro mesure la découverte de vulnérabilités dans du logiciel réel. C'est votre scanner, votre pentester, votre équipe de threat research.

ExploitGym mesure l'exploitation. C'est la partie qui a toujours exigé de la patience, de la créativité et un spécialiste qui comprend la disposition mémoire, les mitigations et les particularités de la cible. 54,8 %, ce n'est pas un score parfait, mais c'est un score.

CWE-bench mesure le patch. C'est votre backlog de remédiation, la chose que chaque équipe d'ingénierie jure de traiter au prochain sprint.

Quand un seul modèle est solide sur les trois, la conséquence pratique n'est pas « l'IA est bonne en sécurité maintenant ». La conséquence, c'est que la distance entre la divulgation et la militarisation s'effondre, et que la distance entre la divulgation et le patch n'a aucune raison de faire de même. Les attaquants n'ont plus qu'une compétence : pointer le modèle vers une cible. Les défenseurs héritent de la moitié ingrate : décider quoi corriger, prouver que c'est corrigé, et conserver les preuves.

Le détail d'architecture qui vaut plus que les benchmarks

Enfoui sous les scores de la une, il y a une ligne qui compte davantage pour quiconque fait tourner des agents en production : Carbon répondrait aux tâches ambiguës et sous forte pression en demandant une intervention humaine plutôt qu'en devinant, et il aurait résisté à toutes les tentatives évaluées d'injection de prompt indirecte.

Relisez cette phrase. La résistance à l'injection de prompt est la propriété la plus demandée par toute entreprise qui déploie un agent ne serait-ce qu'à proximité de contenu non fiable, que ce contenu soit une page web, un ticket de support, un fil d'e-mails ou un PDF téléversé par un client. Si un modèle de frontière tient bon face à des tentatives d'injection évaluées, c'est plus important pour votre architecture qu'un point de benchmark.

Le hic, c'est l'accès. Le déploiement de Carbon calque celui d'Argon : d'abord un groupe restreint de cyberdéfenseurs, puis une extension via le Fairwind Program de Google. Google a aussi confirmé participer au processus volontaire de tests pré-lancement du gouvernement américain. GPT-6.1 Terra, publié par OpenAI la même semaine, atteint le seuil Critical de son Preparedness Framework. Autrement dit, les modèles de sécurité les plus capables sont aujourd'hui réservés à un petit cercle, et tous les autres héritent des effets en aval.

La fenêtre de vulnérabilité est devenue un problème de planification

Voici le basculement qui devrait changer votre façon de planifier le prochain trimestre. Pendant vingt ans, les équipes de sécurité ont optimisé le délai moyen de correction en supposant un attaquant qui traîne. Un chercheur signale, un éditeur écrit un correctif, un attaquant s'y met finalement un jour ou l'autre. Cette marge était tout le postulat de l'industrie de la gestion des vulnérabilités.

Ce postulat a disparu. Dans le même cycle, on a vu la Frontier Red Team d'Anthropic publier des chaînes d'exploitation pour Chrome, Safari, Android, Windows et un chemin zero-click dans le noyau Linux, et on a vu un modèle de production optimisé exactement pour ce workflow s'ouvrir aux défenseurs. La fenêtre entre un correctif public et un exploit fonctionnel se mesure désormais en heures les mauvais jours. Si votre SLA de patch s'exprime encore en jours et en scores de gravité, vous réglez un bouton sur une machine qui a déjà tourné la page.

Traduction pratique : la priorisation doit être pilotée par l'exploitabilité et l'atteignabilité, pas par le CVSS seul. Un 9.8 sur un service que personne ne peut atteindre perd contre un 6.4 sur la chose que chaque client touche.

Ce que les clients aratech devraient faire ce trimestre

Cinq mouvements, par ordre de levier :

1. Recalibrez votre SLA de patch sur l'exploitabilité, pas sur la gravité. Associez chaque constat à un contrôle d'atteignabilité. Rétrogradez ce qui n'est pas exposé, et escaladez ce qui se trouve sur le chemin du périmètre.

2. Inventoriez tout ce que l'IA a écrit. Avec des modèles deux fois plus susceptibles de générer du code sûr, la courbe de qualité s'améliore, mais celle du volume de code est pire. On ne sécurise pas ce qu'on n'a jamais compté.

3. Traitez l'injection de prompt comme un contrôle testable, pas comme une note de bas de page dans le design. Construisez une suite adversariale pour chaque agent qui touche du contenu non fiable, et exécutez-la à chaque montée de version de modèle.

4. Benchmarkez vos propres défenses contre un modèle de frontière. Lancez votre scanner, votre SAST et vos outils de dépendances sur une cible dont vous connaissez déjà toutes les réponses. Si un modèle trouve plus que votre stack, vous savez lequel acheter ensuite.

5. Conservez la piste de preuves. Les régulateurs et les assureurs ne demandent plus si vous aviez une politique. Ils demandent ce que vous avez fait, quand, et sur quels fondements. Une remédiation automatisée n'est défendable que si elle est aussi journalisée automatiquement.

La partie inconfortable

Chacun de ces chiffres est auto-déclaré. Google a testé son propre modèle sur des benchmarks qu'il a lui-même choisis. Gemini 4 Carbon est peut-être réellement le modèle de sécurité le plus solide du marché, ou peut-être seulement le plus solide sur les tests précis qu'un éditeur a décidé de publier. Les deux peuvent être vrais.

Ce n'est pas une raison de l'ignorer. C'est une raison d'instrumenter votre propre réalité. Les organisations qui traverseront 2027 intactes ne sont pas celles qui choisissent tôt le bon fournisseur de modèle. Ce sont celles qui savent répondre, un mardi ordinaire et sans préavis, à la question suivante : lesquels de leurs systèmes étaient exploitables hier, et lesquels sont corrigés aujourd'hui.

La vitesse des modèles a changé ce qui est possible. La vitesse de la gouvernance, elle, reste à votre charge.

Chez aratech, on construit la moitié ennuyeuse : le contexte, l'inventaire, la piste d'audit, la boucle qui continue de tourner après la compilation du code source. Parce que dans un monde où un seul modèle trouve, exploite et corrige, le seul avantage durable qui reste, c'est de savoir précisément où vous en êtes.