Depuis le 1er octobre, Google n’accepte plus les signalements de failles visant ses produits open source dans le cadre de son programme de primes. Le programme est gelé, une mise à jour est promise pour le premier trimestre 2027, et la raison figure dans un message publié par l’entreprise : une « hausse significative des soumissions automatisées, dont la grande majorité ne sont pas valides ».
On pourrait ranger l’épisode parmi les histoires de « slop » (ces contenus générés en masse par IA, sans valeur). Il frappe pourtant un organe vital du logiciel libre : la chaîne de signalement des failles, celle qui protège tout le reste.
Un programme qui payait pour du signal
L’Open Source Software Vulnerability Rewards Program, ou OSS VRP, fonctionnait comme tout bug bounty (programme de primes aux failles) : un chercheur trouve une vulnérabilité dans un projet open source maintenu par Google, la documente, la signale, et touche une récompense si elle est confirmée. Le modèle repose sur un pari simple. Payer des inconnus coûte moins cher que de laisser une faille entre les mains de quelqu’un qui ne la signalera pas.
Ce pari supposait un équilibre implicite. Rédiger un rapport crédible demandait des heures de travail, donc seuls ceux qui pensaient tenir quelque chose prenaient la peine d’écrire. Le coût d’entrée filtrait le bruit avant même qu’il n’arrive aux équipes.
Cet équilibre a disparu. Les ingénieurs de Google et les mainteneurs des projets concernés ont vu affluer des rapports invalides, et ce type de rapport a un air de famille bien documenté par d’autres projets : des fonctions qui n’existent pas, des chemins de code inventés, des scénarios d’exploitation impossibles, le tout rédigé avec l’aplomb d’un expert.
Quand écrire ne coûte plus rien, c’est lire qui coûte
Un modèle de langage produit en quelques secondes un rapport de vulnérabilité structuré, avec sa sévérité estimée, son extrait de code et sa recommandation de correctif. Rien dans la forme ne distingue un vrai signalement d’un faux. Pour trancher, il faut qu’un humain compétent ouvre le dépôt, remonte le code, tente de reproduire. Plusieurs dizaines de minutes par rapport, parfois des heures.
L’asymétrie est brutale. D’un côté, un coût de production qui tend vers zéro et une prime potentielle qui incite à tenter sa chance à grande échelle. De l’autre, un temps de vérification incompressible, assuré par des équipes dont l’effectif ne suit pas. Le goulot d’étranglement a changé de camp : il se trouve désormais chez celui qui trie.
La prime elle-même aggrave le problème. Elle transforme chaque soumission en ticket de loterie, et un ticket gratuit se joue autant de fois qu’on le peut.
Les bons rapports coincés derrière les faux
Le gel tombe à un moment particulier. Les mêmes familles d’outils qui inondent les boîtes de signalement savent aussi, bien pilotées, repérer des vulnérabilités réelles. L’IA appliquée à l’audit de code progresse, et les programmes de primes auraient dû être les premiers à en profiter.
Ils en pâtissent. Un rapport juste, produit par un chercheur sérieux assisté d’un agent, arrive désormais dans la même file que cent rapports fabriqués à la chaîne. Il attend son tour. Et quand le programme ferme, il n’arrive plus nulle part.
L’effet net va contre l’intuition : au moment où la capacité de découverte augmente, le nombre de failles effectivement corrigées peut baisser. Le maillon lent, la vérification humaine, impose son rythme à toute la chaîne.
Google laisse ouverts les signalements touchant la chaîne d’approvisionnement logicielle et renvoie les participants vers ses autres programmes de primes, ou vers son Patch Rewards Program, qui rémunère les correctifs. La réponse se comprend côté entreprise, mais elle laisse de côté les projets open source eux-mêmes, souvent maintenus par une poignée de bénévoles qui n’ont ni l’équipe ni le budget d’un géant pour absorber le même flot.
Remettre un coût du côté de l’émetteur
Si Google, avec ses moyens, choisit de couper le robinet plutôt que de trier, le reste de l’écosystème a peu de chances de faire mieux. Le précédent existe déjà : fin janvier, Daniel Stenberg, créateur et mainteneur de curl, a fermé le programme de primes du projet, après près de sept ans et 87 failles confirmées, faute de pouvoir écoper les rapports générés par IA. Huit mois plus tard, un acteur de premier plan prend la même décision.
Les mainteneurs et les responsables d’un canal de signalement ont plusieurs pistes devant eux :
- exiger une preuve exécutable (un test qui échoue, un exploit minimal reproductible) avant tout examen humain, pour remettre un coût du côté de l’émetteur ;
- filtrer en amont avec des outils automatisés capables de vérifier que les fonctions et fichiers cités existent réellement dans le dépôt ;
- s’appuyer sur la réputation des chercheurs, au risque de fermer la porte aux nouveaux venus, qui ont toujours apporté leur lot de découvertes ;
- retirer l’incitation financière pour les soumissions anonymes, ce qui revient à abandonner une partie du modèle.
Aucune de ces options n’est gratuite. Chacune réintroduit de la friction, et la friction protégeait le système avant que les modèles génératifs ne l’effacent.
Si vous utilisez un agent IA pour auditer du code tiers, la conséquence est directe : un signalement sans reproduction vérifiée par vos soins n’aide plus personne, il encombre la file où attendent les vrais. La discipline de vérification qu’on attend des mainteneurs s’impose désormais aussi à ceux qui signalent.
Google a fixé son prochain rendez-vous au premier trimestre 2027. D’ici là, on saura si l’entreprise revient avec un filtre automatisé, un programme sur invitation ou des règles de preuve plus strictes. Ce choix servira de modèle, ou de contre-exemple, à tous les projets libres qui reçoivent déjà le même déluge sans pouvoir se permettre de fermer.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
