D’abord, dater correctement la décision
Le reportage de TechCrunch a été publié le dimanche 4 octobre à 13 h 31, heure de Californie, soit 22 h 31 à Paris. Il a remis l’information en circulation pendant la soirée européenne. Mais le site du programme et un message du compte Google VRP cités par le média situent la pause au 1er octobre. Un article daté du 5 octobre doit donc raconter un changement déjà effectif, pas annoncer une suspension prise dans la nuit.
Cette précision évite une seconde erreur : dire que Google abandonne tous ses programmes de récompenses pour la découverte de failles. Les informations disponibles concernent le Google Open Source Software Vulnerability Reward Program, ou OSS VRP, et plus précisément les signalements de certaines « product vulnerabilities » dans ce cadre. D’autres programmes Google existent. Des comptes rendus du changement de règles indiquent que les dossiers de chaîne d’approvisionnement du programme OSS ne seraient pas touchés, et que certains signalements liés à des dépôts Google Cloud pourraient relever d’un autre canal. Comme la page de règles actuelle de Google n’est pas entièrement lisible dans les sources consultées, ce périmètre doit être vérifié avant chaque soumission directement auprès de Google Bug Hunters.
Google a indiqué qu’il ferait un nouveau point au premier trimestre 2027, selon les messages rapportés par TechCrunch. Une date d’actualisation promise n’est ni une garantie de réouverture à une date précise, ni l’annonce d’une fermeture permanente. Les chercheurs doivent donc suivre les règles en vigueur plutôt que supposer que le programme est revenu à son fonctionnement antérieur.
Comment fonctionne un programme de primes aux vulnérabilités ?
Un bug bounty récompense des chercheurs qui identifient et signalent de façon responsable une faille dans un périmètre défini. L’objectif n’est pas de payer pour chaque anomalie repérée dans du code : le signalement doit permettre aux équipes concernées de comprendre le problème, d’en apprécier l’impact et, si nécessaire, de le corriger. Le programme OSS VRP de Google porte sur des logiciels open source liés à son écosystème et distingue plusieurs types de problèmes et de projets.
Un rapport utile établit au minimum où se trouve la faiblesse, dans quelles conditions elle peut être déclenchée, quel actif est exposé et ce qu’un attaquant pourrait réellement obtenir. Une preuve reproductible peut faire la différence entre une alerte exploitable et une simple hypothèse. Même une erreur de programmation authentique n’est pas automatiquement une vulnérabilité de sécurité : elle peut se trouver dans un chemin de code inaccessible, derrière une protection efficace, ou ne produire aucun impact pertinent dans le modèle de menace du projet.
Le tri de ces dossiers mobilise des ingénieurs et des mainteneurs. Ils doivent lire le rapport, reproduire le comportement, évaluer la gravité, éviter les doublons, parfois coordonner une divulgation et préparer un correctif. Si le nombre d’envois augmente brutalement sans hausse équivalente du nombre de découvertes valables, la file d’attente s’allonge. Les alertes sérieuses risquent alors d’être noyées parmi des dossiers qui consomment du temps sans améliorer la sécurité.
L’IA accélère la production de rapports, pas forcément leur validation
Google avait averti dès mars 2026 que son programme recevait une forte hausse de rapports générés avec l’IA. Son équipe de sécurité décrivait notamment des explications erronées ou « hallucinées » sur la manière de déclencher une faille, ainsi que des erreurs de code à l’impact négligeable. Elle rappelait aussi qu’un outil d’IA peut aider la recherche légitime, mais que sa sortie doit être vérifiée par la personne qui présente le dossier. Ce constat précède donc de plusieurs mois la pause d’octobre.
La cause avancée dans les messages d’octobre est plus nette encore : d’après la formulation de Google rapportée par TechCrunch, la hausse des soumissions automatisées serait « significative » et la grande majorité de ces dossiers ne seraient pas valables. Ce jugement porte sur les rapports reçus par ce programme ; il ne permet pas d’affirmer que toute découverte de vulnérabilité aidée par l’IA est mauvaise ou que la sécurité automatisée ne fonctionne pas.
L’asymétrie économique explique une partie du problème. Un système peut examiner des milliers de fichiers, produire des dizaines d’hypothèses et rédiger automatiquement des rapports à faible coût marginal. Le destinataire, lui, doit décider si chaque cas est réel, inédit, exploitable et dans le périmètre des règles. Un rapport convaincant dans la forme peut même coûter davantage à réfuter s’il invente une chaîne d’exploitation subtile. La technologie augmente alors le volume du bruit plus vite que la capacité de tri.
Google avait déjà durci les exigences au printemps
La note officielle de Google Bug Hunters, publiée le 19 mars puis actualisée en avril, montrait une première réponse : exiger des éléments de preuve plus solides pour certains types de rapports. Selon les projets et les catégories, Google demandait par exemple des étapes exactes de reproduction via OSS-Fuzz ou un correctif fusionné. Pour des projets de priorité plus basse, la société a également restreint certaines récompenses et mentions attribuées aux « product vulnerabilities » et à d’autres problèmes de sécurité.
Ces règles ne reviennent pas à interdire l’usage de l’IA. Elles déplacent le seuil de qualité. Une suggestion de modèle peut ouvrir une piste ; la soumission doit ensuite démontrer que la piste résiste à l’examen du code, au contexte d’exécution et au modèle de menace. On peut y voir une tentative d’adapter les incitations : récompenser une découverte validée plutôt qu’un volume de tickets.
La pause d’octobre suggère que le durcissement du printemps n’a pas suffi à ramener le flux à un niveau gérable pour la catégorie suspendue. C’est une inférence à partir de la succession des mesures, pas une évaluation interne chiffrée publiée par Google. La société n’a pas communiqué, dans les sources citées ici, un tableau complet permettant de comparer mois par mois nombre de soumissions, taux de validité et temps de tri.
Ce que cela change pour les chercheurs en sécurité
Pour un chercheur qui travaille sur un projet open source concerné, la première règle est pratique : ne pas soumettre par automatisme dans l’ancien formulaire OSS VRP. Il faut consulter les règles actuelles de Google Bug Hunters, identifier le canal autorisé et vérifier les limites de périmètre. Une vulnérabilité critique mérite un traitement responsable même si une catégorie de prime est suspendue ; l’absence de récompense dans un programme n’annule pas l’intérêt de signaler le problème au bon mainteneur ou au bon dispositif de divulgation.
Pour ceux qui utilisent l’IA comme assistant, la discipline devient plus importante que jamais : reproduire le comportement, lire le code autour de l’emplacement proposé, vérifier si le chemin est atteignable, documenter l’impact réel et distinguer un cas inédit d’un doublon. Un modèle peut aider à naviguer dans un dépôt ou à formuler des hypothèses, mais il ne doit pas signer à la place du chercheur la validité d’une faille qu’il n’a pas vérifiée. En cas de doute, mieux vaut une enquête supplémentaire qu’un signalement spectaculaire et faux.
Les mainteneurs, eux, peuvent être tentés de fermer leurs canaux de réception pour retrouver de la capacité de travail. Cela a un coût : une barrière trop haute risque d’écarter aussi des chercheurs compétents, notamment ceux qui n’ont pas accès à un environnement complexe de reproduction. Le défi est de filtrer le bruit sans rendre impossible la remontée des vrais problèmes. Des règles claires, des exemples de bonnes preuves et des voies de divulgation toujours accessibles sont donc essentiels.
Une leçon plus large pour les équipes qui déploient des agents de sécurité
Cette affaire dépasse Google. Les agents capables de chercher des vulnérabilités peuvent augmenter la couverture d’un audit, proposer des tests et accélérer certaines corrections. Mais leur efficacité ne se mesure pas au seul nombre d’alertes produites. Pour une équipe de sécurité, les indicateurs réellement utiles sont le taux de signalements confirmés, le temps nécessaire à la vérification, la gravité des problèmes trouvés et la capacité à corriger sans introduire de nouveaux défauts.
Il faut aussi décider où placer l’humain. Un agent peut explorer un dépôt et préparer un dossier ; une personne compétente doit valider les conclusions avant une soumission externe ou une modification sensible. Sur des systèmes critiques, la validation doit être proportionnée aux conséquences possibles. Cette approche n’est pas un rejet de l’automatisation : elle évite de transformer une forte capacité de génération en surcharge pour les destinataires.
Le signal envoyé par la pause est donc ambivalent. L’IA peut faire émerger des failles qui seraient restées cachées. Elle peut aussi industrialiser des soupçons non vérifiés au point d’affaiblir le canal même qui permet de les traiter. La question n’est pas de choisir entre recherche humaine et recherche assistée par IA, mais d’exiger que la seconde produise des éléments reproductibles, hiérarchisés et utiles à la correction.
Ce qu’il reste à vérifier
La prochaine étape est une clarification officielle et accessible du périmètre exact de la pause, des canaux alternatifs et des critères envisagés pour une éventuelle reprise. Le point promis pour le premier trimestre 2027 sera important, mais il ne suffit pas de compter les rapports rejetés. Il faudra savoir si les changements réduisent le temps perdu sans décourager la divulgation de failles sérieuses.
Au 5 octobre, la conclusion la plus juste est la suivante : Google n’a pas arrêté toute recherche de vulnérabilités ni toutes ses primes ; il a suspendu une catégorie de signalements de son programme open source après une montée de rapports automatisés jugés majoritairement invalides. La décision date du 1er octobre. Le reportage du 4 octobre en a amplifié la visibilité, et les prochains textes de Google devront préciser la suite.