Dans la sécurité informatique, trouver une faille n’est que le début. Il faut encore démontrer qu’elle peut être exploitée, distinguer l’alerte sérieuse du faux positif, comprendre sa cause profonde et produire un correctif qui ne casse pas le reste du logiciel. Google veut désormais automatiser toute cette chaîne avec un modèle conçu pour la parcourir vite — et souvent.
Le 21 juillet 2026, Google DeepMind a présenté Gemini 3.5 Flash Cyber, une version spécialisée de son modèle léger Gemini 3.5 Flash. Sa mission : chercher des vulnérabilités dans de vastes bases de code, les valider à l’aide de preuves de concept, puis contribuer à leur correction au sein de l’agent CodeMender.
L’annonce est importante moins parce qu’un nouveau modèle Gemini rejoint le catalogue que par la stratégie qu’elle révèle. Pour auditer des millions de lignes de code, Google ne mise pas seulement sur un modèle géant réalisant une analyse très coûteuse. L’entreprise préfère lancer de nombreuses explorations avec un modèle plus petit et spécialisé, puis agréger leurs résultats. C’est une approche industrielle de la cybersécurité : multiplier les enquêteurs logiciels pour couvrir davantage de chemins d’exécution.
Mais la démonstration contient aussi son propre avertissement. Selon Google, le système a été capable de construire un exploit d’exécution de code à distance contournant des protections courantes. Gemini 3.5 Flash Cyber ne sera donc pas proposé librement au public : son accès initial est réservé à un petit nombre de gouvernements et de partenaires jugés fiables.
Un modèle léger pour explorer beaucoup plus de code
Une vulnérabilité profonde se cache rarement derrière une ligne manifestement dangereuse. Elle peut dépendre d’une combinaison précise d’entrées, de l’ordre de plusieurs opérations ou d’une interaction entre des composants éloignés. À mesure que la taille d’un logiciel augmente, le nombre de chemins possibles explose.
Un grand modèle généraliste peut mener une analyse poussée, mais son coût et sa latence limitent le nombre de tentatives. Gemini 3.5 Flash Cyber adopte une autre logique. Google DeepMind explique avoir affiné Gemini 3.5 Flash pour la découverte, la validation et la correction de failles, puis l’avoir intégré à CodeMender sous la forme de plusieurs sous-agents. Chacun explore une partie du problème avant qu’un rapport unique soit produit.
Sur le benchmark CyberGym, Google autorise ainsi CodeMender à appeler le modèle jusqu’à cinq fois pour constituer une réponse finale. Le résultat ne mesure donc pas une conversation isolée avec Gemini, mais un système agentique : modèle spécialisé, outils de sécurité, environnement d’exécution et orchestration de plusieurs essais.
Cette distinction est essentielle. Un modèle n’ouvre pas magiquement un dépôt de code pour le sécuriser. Il lui faut un cadre capable de compiler le logiciel, d’exécuter des tests, d’observer les plantages, de lancer des outils d’analyse et de recommencer. La performance dépend autant de cette boucle que des poids du modèle.
Pourquoi la vitesse compte autant que le raisonnement
Dans un audit, deux agents peuvent trouver le même nombre de failles tout en ayant une valeur très différente. Si le premier répète dix variantes d’un même problème tandis que le second explore dix zones distinctes du programme, le second couvre mieux le risque réel.
Google illustre ce point avec le moteur JavaScript V8. À nombre d’invocations fixé, Gemini 3.5 Flash Cyber aurait identifié 55 problèmes uniques confirmés, contre 47 pour Gemini 3.5 Flash et 36 pour Claude Opus 4.6. Dix des problèmes trouvés par le modèle spécialisé n’auraient été détectés par aucun des deux autres systèmes testés.
Ces résultats ont été produits par Google et ne constituent pas une évaluation indépendante. Ils montrent néanmoins ce que l’entreprise cherche à optimiser : non pas seulement la qualité d’une réponse, mais la diversité des pistes couvertes pour un budget de calcul donné.
CodeMender veut boucler la chaîne de la faille au correctif
Gemini 3.5 Flash Cyber est le moteur spécialisé ; CodeMender est l’agent qui le met au travail. Présenté pour la première fois en 2025, CodeMender est désormais disponible en préversion dans la Gemini Enterprise Agent Platform avec des modèles Gemini accessibles aux entreprises. La variante équipée de Flash Cyber reste, elle, fortement restreinte.
Le fonctionnement annoncé se décompose en trois étapes.
Chercher au-delà des motifs connus
CodeMender analyse le contexte d’un dépôt et vise plusieurs familles de vulnérabilités : corruption de mémoire, injection, failles web, erreurs cryptographiques ou manipulation non sûre de données. L’objectif n’est pas seulement de repérer une fonction connue pour être risquée, comme le ferait une règle statique, mais de raisonner sur la manière dont des données circulent dans le logiciel.
Google affirme que l’agent peut travailler sur des projets en C, C++, Go, Java, Python, Ruby, Rust et TypeScript. Il peut s’insérer dans une chaîne d’intégration continue ou fonctionner depuis un environnement local de développement.
Prouver qu’une alerte représente un risque réel
Les équipes de sécurité croulent déjà sous les alertes. Ajouter un détecteur très sensible ne sert à rien s’il produit une longue liste de scénarios théoriques impossibles à exploiter.
CodeMender tente donc de générer une preuve de concept et de l’exécuter dans un bac à sable contrôlé. Si le test déclenche effectivement la faille, l’alerte gagne en priorité. Cette étape peut réduire le bruit, mais elle augmente aussi la sensibilité du système : produire un exploit fonctionnel est précisément une capacité utile aussi bien à un défenseur qu’à un attaquant.
Générer un patch sans créer de régression
Une fois la vulnérabilité validée, l’agent propose une modification du code, exécute des tests et présente la différence à un développeur. Google indique utiliser d’autres modèles comme critiques afin de vérifier la correction, sa sécurité et son respect des conventions du projet.
La validation humaine reste explicitement dans la boucle. Le patch n’est pas censé être envoyé automatiquement en production : un développeur doit l’examiner et l’approuver. C’est une précaution indispensable, car un correctif peut fermer une voie d’attaque tout en introduisant une régression fonctionnelle ou une nouvelle faiblesse ailleurs.
La démonstration de deux heures change l’échelle du risque
Le résultat le plus frappant de l’annonce ne vient pas d’un classement public. Google rapporte que son équipe Cloud Vulnerability Research a utilisé Gemini 3.5 Flash Cyber sur ses propres systèmes et qu’en deux heures, le modèle a découvert des vulnérabilités permettant l’exécution de code à distance dans des API publiques, ainsi qu’une corruption de mémoire dans un service de production sensible.
Le système aurait ensuite produit un exploit d’exécution de code à distance fiable à 100 % lors des essais de Google, capable de contourner l’ASLR et la politique W^X. L’ASLR rend aléatoire l’emplacement de certaines zones en mémoire ; W^X empêche en principe une même page mémoire d’être à la fois modifiable et exécutable. Les contourner demande davantage qu’un simple repérage de code suspect.
Il faut lire cette affirmation avec précision. Google ne publie ni le service concerné, ni le code de l’exploit, ni un protocole permettant à un tiers de reproduire le résultat — ce qui est compréhensible pour une faille sensible, mais limite la vérification indépendante. « Fiable à 100 % » décrit les essais internes mentionnés, pas une garantie générale du modèle.
La portée reste néanmoins considérable. Si une machine peut passer en quelques heures de l’audit à un exploit opérationnel, la fenêtre séparant la découverte d’une faille de son utilisation se réduit. Le travail de correction doit alors accélérer au même rythme.
CyberGym mesure une capacité réelle, mais pas toute la sécurité
Google évalue notamment son système sur CyberGym, un benchmark universitaire construit à partir de 1 507 vulnérabilités historiques provenant de 188 projets logiciels. L’agent reçoit une description de faille et une version non corrigée du code, puis doit générer une entrée qui reproduit le problème. Le test réussit si cette preuve de concept déclenche le bug avant le patch, mais plus après.
Ce cadre est plus réaliste qu’un questionnaire de cybersécurité. Il oblige l’agent à naviguer dans de vrais dépôts, compiler des programmes et produire un résultat exécutable. Les travaux liés à CyberGym ont aussi conduit à la découverte de vulnérabilités jusque-là inconnues et de correctifs historiques incomplets.
Pour autant, reproduire une vulnérabilité documentée n’équivaut pas à sécuriser seul un système en production. Le benchmark donne déjà à l’agent une description du problème. Il ne mesure pas entièrement la sélection des actifs les plus critiques, l’analyse d’une architecture d’entreprise, la coordination d’une divulgation responsable ou la qualité du patch sur plusieurs années.
Un article de recherche publié en mai 2026 par des chercheurs de l’ELLIS Institute, de l’Alan Turing Institute et d’universités allemandes rappelle en outre trois fragilités des évaluations d’agents de sécurité : les failles du benchmark lui-même, le vieillissement rapide des scénarios et l’incertitude liée à l’exécution. Un agent offensif suffisamment capable peut parfois exploiter l’environnement de test plutôt que résoudre la tâche prévue.
Les scores de Google constituent donc un signal de capacité, pas un certificat de sûreté. Les tests internes sur Chrome et sur des services récents sont intéressants précisément parce qu’ils réduisent le risque que le modèle ait déjà rencontré les réponses pendant son entraînement. Mais ils restent contrôlés et rapportés par l’entreprise qui développe le produit.
Un outil défensif dont l’accès devient une décision politique
Google réserve Gemini 3.5 Flash Cyber à des gouvernements et partenaires de confiance dans le cadre d’un pilote limité. Ce choix reconnaît le caractère à double usage du modèle : la connaissance qui permet de réparer une faille permet aussi de l’exploiter.
La restriction offre aux défenseurs sélectionnés une avance temporaire. Elle soulève toutefois plusieurs questions. Quels États et quelles entreprises seront admis ? Selon quels critères ? Comment les journaux d’utilisation seront-ils contrôlés ? Que se passera-t-il si des capacités comparables apparaissent dans des modèles ouverts ou sont reproduites par un concurrent ?
Le NIST américain recommande, pour les modèles à double usage, d’évaluer les risques de détournement tout au long du cycle de vie, de définir des seuils de capacité et d’adapter les contrôles d’accès aux scénarios de menace. Dans le cas de Flash Cyber, la restriction d’accès n’est qu’une couche. Elle doit être accompagnée de bacs à sable isolés, de permissions minimales, d’une traçabilité des actions et de procédures de divulgation des vulnérabilités.
Pour une entreprise, le point pratique est tout aussi important : connecter un agent à un dépôt privé lui donne accès à une carte détaillée des faiblesses du logiciel. Google promet, dans sa plateforme, un routage privé, le chiffrement, l’isolation des données et l’absence de conservation du code source. Ces garanties devront être évaluées contractuellement et techniquement, notamment pour les secteurs réglementés.
La cybersécurité entre dans une course de vitesse automatisée
Gemini 3.5 Flash Cyber ne rend pas les ingénieurs sécurité obsolètes. Il déplace leur travail. La recherche exhaustive, la reproduction d’un bug et la préparation d’un premier patch peuvent être accélérées ; la définition du périmètre, l’examen du correctif, l’évaluation de l’impact et la décision de divulguer restent des responsabilités humaines et organisationnelles.
Le changement le plus profond est économique. Jusqu’ici, analyser continuellement chaque modification d’un grand logiciel avec des méthodes avancées coûtait trop cher. Un modèle léger, spécialisé et invoqué en parallèle peut rendre cette surveillance permanente plus réaliste. À terme, chaque commit pourrait être soumis non seulement à des tests fonctionnels, mais à une tentative automatisée de le casser puis de le réparer.
Cette promesse ne donnera un avantage durable aux défenseurs que si la correction va aussi vite que la découverte. Trouver cinquante failles supplémentaires sans disposer des équipes capables de qualifier, déployer et surveiller les patchs ne réduit pas mécaniquement le risque. L’enjeu n’est donc pas seulement de construire une meilleure IA pour chercher des bugs, mais d’organiser toute la chaîne humaine qui transforme une alerte en logiciel réellement plus sûr.
Références
- Google DeepMind, « Introducing Gemini 3.5 Flash Cyber », 21 juillet 2026.
- Google Cloud, « Now in preview: Find and fix software vulnerabilities with CodeMender », 21 juillet 2026.
- UC Berkeley, CyberGym : benchmark d’agents IA sur 1 507 vulnérabilités réelles, consulté le 27 juillet 2026.
- Sahar Abdelnabi et al., « Measuring Security Without Fooling Ourselves: Why Benchmarking Agents Is Hard », mai 2026.
- NIST, « Managing Misuse Risk for Dual-Use Foundation Models », second projet public, mai 2026.
