Google a annoncé jeudi que ses outils basés sur l'IA ont contribué à corriger 1 072 vulnérabilités de sécurité dans deux versions du navigateur Chrome publiées en juin — Chrome 149 et Chrome 150. Ce chiffre dépasse le total combiné de 1 036 correctifs des 23 versions stables que Google a publiées au cours des deux années précédentes. L'ampleur compte : Chrome est le navigateur le plus utilisé au monde, installé sur environ trois milliards d'appareils, ce qui signifie que les vulnérabilités non corrigées peuvent affecter davantage d'utilisateurs que des failles dans presque tout autre logiciel grand public.

Parmi les découvertes figurait une vulnérabilité d'évasion de sandbox qui dormait dans le code de Chrome depuis plus de 13 ans. Google a précisé que cette faille, si elle n'avait pas été corrigée, aurait pu permettre à un processus de rendu compromis de tromper le navigateur pour qu'il lise des fichiers locaux. Le sandboxing est une frontière de sécurité fondamentale du navigateur, conçue pour confiner le contenu web non fiable afin que, même si un attaquant exploite un bug de rendu, il ne puisse pas atteindre le système d'exploitation ni les données utilisateur — ce qui rend une évasion de cette frontière particulièrement grave.

Les grands modèles de langage ont « fondamentalement changé l'économie de la cybersécurité, transformant la découverte de vulnérabilités en une opération automatisée à l'échelle industrielle », a déclaré Doug Turner, directeur de l'ingénierie de Chrome. Il a souligné que des modèles comme Gemini permettent à l'équipe Chrome de traiter les failles « de manière préventive » et de devancer les attaquants potentiels.

L'entreprise a insisté sur le fait qu'« une augmentation du nombre de bugs trouvés et corrigés n'est pas un signe d'échec ».

Un déploiement de sécurité IA mené sur plusieurs années

Google déploie des grands modèles de langage contre sa propre infrastructure de sécurité depuis plusieurs années. L'effort a commencé par la couverture de fuzzing en 2023, suivi par l'outil Naptime développé avec Project Zero en 2024. En 2025, DeepMind et Project Zero ont introduit l'agent de découverte Big Sleep, qui a identifié des bugs dans le moteur JavaScript V8 de Chrome et dans la pile graphique.

Début 2026, Google a construit un harnais d'agent Gemini pour scanner systématiquement l'ensemble du code de Chrome. Ce système a mis au jour l'évasion de sandbox qui persistait indétectée depuis 2013. Le harnais 2026 intégrait des modèles ouverts interopérables et propriétaires, une base de connaissances constituée à partir de l'historique Git de Chrome et des anciens CVE, ainsi qu'un agent « critique » qui examine les fichiers SECURITY.md rédigés par les développeurs pour identifier où se situent les frontières de confiance.

Triage et correction automatisés des bugs

Google forme également l'IA à valider, catégoriser et réparer les rapports de sécurité entrants. Auparavant, le triage d'un seul rapport nécessitait entre cinq et plus de trente minutes d'attention humaine. Un pipeline hybride combinant règles et modèles d'IA filtre désormais le spam et les doublons, reproduit les bugs sur le système d'exploitation et la version Chrome concernés, ajoute des métadonnées telles que la sévérité et la date d'introduction, et achemine chaque rapport vers un responsable approprié.

Google estime que ce pipeline économise des centaines d'heures de développement chaque mois.

Pour les réparations, un agent de correction propose plusieurs correctifs candidats, tandis qu'un second agent critique sélectionne l'option la plus robuste — itérant à la manière d'une revue de code jusqu'à ce que la modification compile avec succès et respecte les règles de style de Chromium. Le système génère également des tests avant qu'un ingénieur ne donne son approbation finale.

Les modèles fonctionnent sur des machines verrouillées sans accès général à Internet, s'exécutent derrière une couche d'interception réseau en liste blanche, et ne sont pas autorisés à accéder à des fichiers en dehors des répertoires sources désignés.

Réduire le délai de correctif et repenser les primes aux bugs

Google s'attache activement à réduire le « patch gap » — l'intervalle entre le moment où un correctif apparaît dans le code source public et celui où les utilisateurs l'appliquent effectivement. Pendant cette fenêtre, les attaquants peuvent étudier les correctifs et développer des exploits. Pour y remédier, Google teste deux versions de sécurité par semaine et développe des capacités de correctif dynamique permettant de mettre à jour des composants de Chrome sans nécessiter un redémarrage complet du navigateur.

La hausse des découvertes assistées par l'IA a également remodelé le programme de primes aux bugs de Google. Les soumissions externes ont tellement augmenté qu'en mars, l'entreprise avait reçu plus de rapports que sur toute l'année 2025 réunie. Cela a poussé à une refonte du Chrome Vulnerability Reward Program pour orienter les chercheurs vers les catégories de bugs les moins susceptibles d'être trouvées par les propres outils automatisés de Google — un signal que l'automatisation déplace déjà la valeur de la recherche en sécurité humaine vers des domaines que les machines peinent encore à atteindre.

À plus long terme, Google étend son outil de sécurité mémoire MiraclePtr, convertit de nouveaux composants en Rust, et verse 12,5 millions de dollars au projet de sécurité open source Alpha-Omega, une initiative hébergée par la Linux Foundation qui finance des améliorations de sécurité pour les logiciels open source largement utilisés.

À titre de comparaison, le dernier Patch Tuesday de Microsoft a corrigé un record de 570 failles et a mentionné l'IA dans son processus, tandis qu'Apple a indépendamment enregistré 482 correctifs en 2026 — bien qu'aucun des deux concurrents ne semble suivre la même trajectoire que l'approche pilotée par l'IA de Google. Cet écart suggère que les entreprises dotées de profondes capacités de recherche en IA sont de plus en plus capables de mobiliser ces actifs pour la sécurité défensive à un rythme que les concurrents sans modèles internes équivalents pourraient difficilement égaler.