Les points clés à retenir sur l'utilisation des agents d'IA pour sécuriser Chrome

• L'IA a découvert une faille dans Chrome datant d'une dizaine d'années qui avait échappé à plusieurs reprises aux humains.
• Google a déclaré que son processus basé sur l'IA permettait aux développeurs de gagner plusieurs semaines de travail.
• Chrome pourrait avoir besoin de correctifs deux fois par semaine pour assurer la sécurité de milliards d'utilisateurs.

Chrome et son projet open source, Chromium, comptent, par leur ampleur, parmi les projets open source les plus complexes au monde. Avec environ 73 % des parts du marché mondial des navigateurs, Chrome compte environ 3,5 milliards d'utilisateurs.

Je n’ai pas trouvé de référence fiable concernant la population adulte totale, j’ai donc fait le calcul moi-même. D’après les données relatives à la population mondiale totale et au nombre d’enfants sur la planète, on compte un peu moins de 6 milliards d’adultes sur Terre. Le calcul nous montre que Chrome est le principal moyen par lequel plus de la moitié d’entre nous, Terriens, accédons à Internet.

Les enjeux sont donc extrêmement importants pour les développeurs de Chrome. Le simple fait de laisser une faille de sécurité se propager met immédiatement en danger la moitié des adultes actuellement en vie.

Google prend manifestement cette responsabilité très au sérieux.

La semaine dernière, l’équipe de sécurité de Chrome a publié un article de blog expliquant en détail comment elle utilise l’IA pour « améliorer la détection, le tri et la correction des vulnérabilités ».

L’ampleur du défi, la manière dont l’IA apporte son aide, mais aussi la façon dont elle met au jour un nombre impressionnant de nouvelles vulnérabilités constituent une histoire à part entière, qui mérite d’être décortiquée.

Google a qualifié ses versions de « jalons », qui ont lieu environ une fois par mois. Le graphique ci-dessous commence par le jalon 128, publié le 20 août 2024.

Pour chaque jalon jusqu’au M145, Google a corrigé environ 50 bogues. Puis, le M146 a fait un bond à environ 80 bogues. Le M147 a corrigé environ 130 bogues. Le M148 en a corrigé environ 350.

Le graphique montre une courbe de croissance en forme de crosse de hockey. Image : Google

Mois après mois, le nombre de bogues détectés et corrigés a doublé. Puis, pour les versions M149 et M150, Google a corrigé 1 072 bogues, « dépassant ainsi le nombre total de bogues de sécurité corrigés au cours des 23 étapes précédentes réunies ».

La logistique derrière tout cela est ahurissante. Google publiant chaque mois de nouvelles versions majeures, le risque de provoquer des perturbations à l’échelle mondiale est assez élevé. Si, au lieu de corriger un bug, Google venait à introduire un bug grave qui passerait inaperçu jusqu’au déploiement, cela pourrait gâcher la journée de la moitié de l’humanité adulte.

Pour chacun des 40 ou 50 bugs traités lors de la version M128, Google a dû valider le bug, le corriger, effectuer des tests d’assurance qualité sur le correctif pour s’assurer qu’il n’entrait pas en conflit avec les milliards de pages web et les centaines de milliers d’extensions Chrome, publier le correctif, puis inciter les utilisateurs à mettre à jour leur navigateur.

C’est beaucoup à accomplir en à peu près un mois, même avec une armée de développeurs qu’une entreprise comme Google peut mobiliser pour ce travail.

Il est vrai que Google utilisait déjà des outils d’IA pour gérer ces versions antérieures. En 2023, Google a utilisé l’IA pour étendre la couverture du fuzzing de sécurité (il s’agit de tests utilisant de nombreuses entrées aléatoires et inattendues). En 2024, à peu près à l’époque de la version M128, Google a commencé à intégrer des outils d’IA spécialisés pour effectuer des analyses de vulnérabilité. En 2025, l’entreprise a déclaré : « Nous avons collaboré avec DeepMind et Project Zero sur Big Sleep, un agent d’IA dédié à la découverte de vulnérabilités qui a réussi à détecter des bogues dans le moteur JavaScript V8 et la pile graphique. »

Puis, en 2026, Google a passé à la vitesse supérieure avec un « agentic harness » (une structure permettant d’interagir avec les grands modèles de langage, ou LLM) basé sur Gemini, conçu pour détecter les vulnérabilités dans l’ensemble du code source de Chrome.

Il ne s’agit pas d’un processus linéaire. Il ne s’agit pas simplement d’examiner le code et de se rendre compte que les entrées n’ont pas été correctement validées. Cela s’apparente davantage à une partie d’échecs, à la différence près que l’IA anticipe des milliers de coups à l’avance. Il ne s’agit pas seulement d’examiner le code. Il s’agit d’envisager des scénarios. Des milliards de scénarios.

Cette démarche ne permet pas nécessairement de détecter des failles dans le code. Il s’agit plutôt de repérer des vulnérabilités, qui reflètent des schémas d’interactions susceptibles d’entraîner une faille de sécurité.

Un exemple en est une vulnérabilité appelée « échappement de sandbox » qui existait dans Chrome depuis 2013. Il s’agit d’un bug qui, s’il était exploité, inciterait le navigateur à lire des fichiers locaux. Cette faille était présente dans le code de Chrome, passant avec succès une suite de tests après l’autre, pendant plus d’une décennie. Gemini l’a découverte début 2026.

Mais voici le problème. Alors que 40 ou 50 vulnérabilités par mois sont relativement gérables pour une équipe de la taille de celle de Google, 1 072 bogues répartis sur deux versions constituent un volume tout simplement écrasant.

Voici les deux principales implications.

Premièrement, si l’IA est capable de détecter autant de vulnérabilités, elle pourrait peut-être aider à gérer, corriger, tester et déployer les correctifs.

Deuxièmement, si l’IA de Google est capable de détecter autant de vulnérabilités, les IA exploitées par des acteurs malveillants le peuvent tout autant. Et qui peut affirmer que les vulnérabilités que Google détecte et corrige sont les mêmes que celles que les pirates trouvent et exploitent ?

Tout cela est très inquiétant.

Le problème, c’est que la réactivité doit être fulgurante. Des milliards de personnes en dépendent.

Mais toutes ces personnes ne comptent pas seulement sur un flux continu de correctifs.

Elles comptent sur le fait que ces correctifs n’aggravent pas la situation.

Pour gérer cela, Google a mis au point un processus de tri en quatre étapes.

À l’étape 1, des agents IA aident à filtrer les faux signalements, les signalements en double et les rapports de bogues qui ne décrivent pas réellement une faille de sécurité de Chrome.

Google appelle cela « filtrer le bruit ».

C’est un peu comme trier ses e-mails pour supprimer les courriers indésirables.

À la deuxième étape, les agents IA reproduisent concrètement les bogues.

Chrome est mis à l’épreuve dans des environnements virtuels correspondant au navigateur et au système d’exploitation spécifiques mentionnés dans le rapport de bogue.  Si le bogue peut être reproduit, l’IA ajoute des détails supplémentaires, tels que des traces de pile, au rapport.

Cette étape prend beaucoup de temps lorsqu’elle est effectuée par des humains. Lorsque je reçois un rapport de bug concernant mon petit produit, cela peut me prendre des heures d’essayer de confirmer que ce que l’utilisateur signale est bien réel. Ce n’est pas du temps consacré à la correction. C’est simplement le temps nécessaire pour déterminer si le bug doit rester sur ma liste de tâches. Si Google parvient à faire en sorte que Gemini s’en charge automatiquement, le gain de temps pour l’équipe de développement pourrait être considérable.

À l’étape 3, les agents IA « enrichissent le rapport avec des métadonnées ».

Combien de séries policières avons-nous tous vues où le détective se voit remettre un rapport de police ou un dossier sur le crime ? Ce dossier contient toutes les informations de fond sur l’affaire avant qu’elle ne soit transmise à un enquêteur.

C’est exactement ce que fait l’étape 3. Les agents IA constituent ce rapport en vue de la transmission.

Ensuite, à l’étape 4, les agents IA identifient le responsable humain compétent et transmettent toutes les informations relatives à l’affaire à cet enquêteur.

Cela permet à l’enquêteur de se concentrer sur l’enquête et de ne pas passer un temps fou sur les détails administratifs nécessaires pour ouvrir le dossier.

Google a déclaré : « Bien qu’il soit difficile de le mesurer avec précision, nous estimons que ce nouveau processus permet d’économiser des centaines d’heures de travail aux développeurs chaque mois. »

C’est vraiment la seule façon de faire face à l’accélération rapide de la cadence des exploits. Mais la dernière chose que l’on souhaite, c’est qu’une IA imagine un correctif qui soit déployé auprès de la moitié des adultes de la planète et qui finisse par échouer.

Néanmoins, face aux milliers de vulnérabilités découvertes à un rythme effréné, Google devait intensifier son processus de correction des bogues. Pour ce faire, l’article de blog décrit un flux de travail multi-agents.

Il y a un agent « correcteur » qui écrit du code, produisant ainsi une série de ce que Google appelle des « correctifs candidats ».

Puis il y a un agent « critique ». Cette IA évalue les correctifs, détermine lequel serait le plus adapté au problème et fournit des informations complémentaires aux développeurs pour leur permettre d’évaluer le correctif.

Les deux agents, le correcteur et le critique, fonctionnent en boucle de manière similaire à un processus traditionnel de révision de code jusqu’à ce qu’ils soient certains que le code est fonctionnel et respecte les conventions de style.

Vient ensuite une petite armée d’agents chargés de rédiger des tests. Ces agents élaborent des tests et les exécutent sur Chrome, sur toutes les plateformes prises en charge par le navigateur.

De cette manière, les problèmes peuvent être détectés et renvoyés au correcteur et au critique avant même qu’un développeur humain n’ait à examiner la correction.

Google affirme que ce processus permet aux développeurs de gagner plusieurs semaines de travail.

Il existe un décalage entre le moment où les pirates découvrent et exploitent des bogues et celui où les correctifs sont publiés. Même lorsque Google sait qu’un bogue circule, il faut généralement plusieurs semaines avant que le correctif n’atteigne la branche stable de Chrome.

Google s’efforce de passer à un rythme de livraison de deux semaines pour les jalons majeurs et à une publication hebdomadaire pour les mises à jour de sécurité. Mais face à l’accélération des attaques, Chrome s’efforce de publier deux mises à jour de sécurité par semaine.

Depuis près d’une décennie, Chrome utilise un mécanisme de téléchargement silencieux en arrière-plan qui stocke les mises à jour sur le disque dur, celles-ci s’exécutant automatiquement dès que l’utilisateur redémarre Chrome.

Et bien sûr, personne ne souhaite installer deux nouvelles versions de Chrome chaque semaine. Nous ne voulons pas non plus redémarrer Chrome. Mais cela pose un problème, car le délai entre le téléchargement d’un correctif et le redémarrage de Chrome par l’utilisateur peut être suffisamment long pour qu’une faille soit exploitée.

Google a déclaré travailler sur des moyens de déployer les mises à jour sans être intrusif. L’entreprise teste actuellement un mécanisme de correctifs dynamiques qui pourrait éliminer la plupart des redémarrages du navigateur. Il travaille également à la sauvegarde locale de l’état du navigateur afin de pouvoir le reprendre facilement. Une autre stratégie consiste à trouver des moments opportuns et non intrusifs pour redémarrer le navigateur.

En tant qu’utilisateur, je n’apprécie vraiment pas qu’un éditeur décide de me traiter comme un enfant et de m’imposer des mises à jour. Mais je n’apprécie pas non plus que des malfaiteurs tentent d’exploiter ma machine. Il semble que Google s’efforce de trouver le juste équilibre, et cela pourrait bien fonctionner.

Google publie de nombreuses informations techniques sur la manière dont il intègre l’IA dans ses processus de défense. Si les détails techniques sont intéressants, ce sont les implications stratégiques qui sont les plus profondes.

L’IA a accéléré le rythme des attaques. Elle peut également accélérer le rythme de la défense. La course aux armements est plus effrénée et plus intense que jamais. Si Google parvient à identifier et à corriger l’équivalent de deux ans de bogues en deux mois, nous pouvons déduire le rythme de l’innovation à partir de ce rapport.

Le code évolue à un rythme plus rapide que jamais. Deux ans en deux mois signifient qu’une année de codage, d’attaques et de défense assistés par l’IA produira le résultat qui nécessitait auparavant 12 ans. Cela représente plus d’une décennie de progrès chaque année.

C’est vertigineux. C’est l’IA qui est à l’origine de cette accélération, et de ce fait, nous dépendons désormais d’elle pour nous défendre à la même vitesse.