Votre budget de primes achète du déchet d'IA

Stenberg a retiré l'argent, pas les machines

Daniel Stenberg a fermé la prime aux bogues de curl à cause de ce que l'argent attirait, non de ce qui rédigeait les rapports. Le 31 janvier 2026, il a mis fin à un programme actif depuis avril 2019, qui avait confirmé 87 vraies vulnérabilités et versé plus de 100 000 dollars. La raison en était l'effondrement du taux de réussite. Avant 2024, plus de 15 pour cent des envois se révélaient être de véritables problèmes de sécurité. Au cours de 2025, cette part est tombée sous les 5 pour cent, ce qui, selon ses propres mots, signifiait que même pas un sur vingt était réel. Une équipe bénévole de sept personnes passait des heures à réfuter chacun d'eux, un travail qu'il a décrit comme une usure mentale sérieuse.

Son explication mérite une lecture précise. L'objectif principal de la fermeture, a-t-il écrit, était de supprimer l'incitation à envoyer des rapports médiocres et mal documentés. Il faut remarquer ce que cette phrase ne dit pas. Elle ne nomme aucune technologie et ne propose pas d'en détecter une. Elle désigne un paiement comme ce qui récompensait le mauvais travail, et supprime le paiement. Son critère pour les personnes qui signalent est tout aussi indépendant de l'outil : il ne faut jamais signaler une vulnérabilité si on ne la comprend pas vraiment et si on ne sait pas la reproduire.

Le volume a doublé et le taux de réussite a triplé

Le résultat est allé à l'inverse de la prévision évidente. Cesser de payer n'a pas vidé la file. En avril 2026, après le retour de curl au signalement non rémunéré, les envois arrivaient à un rythme environ deux fois supérieur à celui de 2025, et 15 à 16 pour cent d'entre eux étaient confirmés comme de vraies vulnérabilités. Le nombre de découvertes confirmées a dépassé le niveau de 2024, c'est-à-dire celui d'avant la vague.

Le détail le plus important sonne comme une contradiction. Presque chaque rapport semblait toujours assisté par IA. Ce qui avait changé, c'est que la plupart étaient désormais bons. Le déchet n'était plus un problème, a rapporté Stenberg en avril. L'outil n'a pas quitté la file. Le déchet, lui, est parti.

Lue comme un problème de commande, la prime était un filtre pointé sur la mauvaise cible. Une récompense en argent pour une découverte acceptée se perçoit en fonction du volume d'envois multiplié par la chance, et récompense donc l'envoi rapide et optimiste plutôt que la vérification préalable. Cette pression existait déjà avant les modèles génératifs et restait simplement supportable ; la génération bon marché l'a rendue mortelle. L'ampleur se voit ailleurs aussi. Chez Bugcrowd, le volume des signalements a plus que quadruplé en trois semaines au mois de mars. HackerOne a enregistré jusqu'en mars une hausse de 76 pour cent sur un an des envois, même si sur cette plateforme la part signalant de vraies vulnérabilités est restée stable autour de 25 pour cent, ce qui nuance l'idée que toutes les files se seraient effondrées en même temps.

Personne n'a réellement rien interdit

Le seul recensement qui a pris la peine de compter a trouvé zéro interdiction pure et simple. Une étude exhaustive de 53 programmes de divulgation, couvrant quatre plateformes de coordination, 20 fabricants et 29 projets open source, a été consultée le 28 juillet 2026. Pas un seul n'interdit d'emblée les rapports de bogues écrits par IA. L'affirmation si souvent répétée selon laquelle le secteur les aurait interdits décrit une règle qu'aucun programme de l'échantillon n'a jamais mise par écrit.

La répartition réelle est moins spectaculaire et plus utile. Trente-six programmes, soit 67,9 pour cent, ne disent rien de l'IA dans leurs politiques publiées. Seize, soit 30,2 pour cent, l'encadrent par des conditions. Parmi ces seize, treize exigent une vérification humaine de la découverte, onze exigent une reproduction fonctionnelle, huit refusent les envois purement autonomes tout en continuant d'admettre l'assistance de l'IA, et trois exigent que l'usage de l'IA soit déclaré : Intigriti, Django et FFmpeg. La vérification humaine, et non l'interdiction, est la norme vers laquelle tous convergent.

Le recensement a aussi relevé un défaut qu'il vaut la peine de noter. Trois programmes ont publié leurs règles sur l'IA ailleurs que sur leur page de politique principale. Une condition que la personne qui signale n'a jamais vue et n'a jamais acceptée ne lui est pas opposable, ce qui réduit une règle écrite à une décoration. Les programmes ayant changé de statut n'ont rien interdit non plus : curl a fermé sa prime en janvier 2026, Nextcloud a suspendu les récompenses payées en avril, et l'Internet Bug Bounty a mis les envois en pause.

Apple et GitHub s'en sont pris à la personne

Les directives d'Apple rattachent désormais la sanction à la réputation de la personne qui signale, non au signalement. Apple indique sans détour recevoir de nombreux rapports prétendant porter sur de graves problèmes de sécurité ou de confidentialité mais qui sont produits par des modèles de langage et déposés sans la preuve exigée ni validation par une personne. Son remède est une suspension. Si quelqu'un dépose de façon répétée des rapports irrecevables, y compris des rapports irréalisables sur des questions théoriques ou découverts par IA sans validation correcte, Apple peut suspendre le traitement de ses rapports pendant 180 jours. Au-delà de deux périodes de suspension, cette personne peut être définitivement retirée du programme.

La seconde moitié de cette sanction est la plus tranchante. Pendant la suspension, la personne concernée est privée non seulement du paiement mais aussi de la mention dans les avis de sécurité, et pour un chercheur professionnel la reconnaissance publique est la monnaie qui dure. Les conditions de service d'Apple aboutissent au même point par un autre chemin, en prohibant un schéma constant, répété ou à fort volume d'affirmations fausses, tels que des rapports produits avec l'assistance de l'IA et non validés par une relecture humaine. Ce qui compte, c'est cette dernière partie. La clause n'interdit pas l'assistance, elle interdit de livrer le résultat sans le contrôler.

GitHub a emprunté l'autre voie de l'identité, scindant le programme en deux niveaux à compter du 27 juillet 2026. Les primes publiques sont tombées à 250 dollars pour une découverte de faible gravité, 2 000 pour une moyenne, 5 000 pour une élevée et 10 000 pour une critique, contre respectivement 500 à 1 000, 5 000, 20 000 et 30 000 auparavant. Les anciens montants vivent désormais dans un niveau sur invitation qui verse 1 000, 7 500, 20 000 et 30 000 dollars ou plus. L'accès suppose un historique démontré : une découverte critique acceptée, ou deux élevées, ou quatre moyennes, ou sept faibles. Les nouveaux venus du programme public se heurtent à une exigence de signal, avec jusqu'à quatre premiers envois pour faire leurs preuves. L'objectif affiché par Catherine Cassell, ingénieure en sécurité produit, est de réduire le bruit afin que l'équipe puisse se concentrer sur le signal.

Celui que vous freinez est peut-être celui qui compte

Le filtrage par réputation a un coût qu'aucune de ces annonces ne chiffre. Chacun de ces dispositifs récompense un historique existant, ce qui est une façon sensée de classer ceux qui signalent souvent. Mais la personne qui trouve un unique défaut critique dans votre produit sans avoir jamais déposé de rapport nulle part est par définition le profil dépourvu de tout historique, et c'est précisément le signalement que vous voulez le moins freiner. La réponse de GitHub tient en quatre envois pour établir le signal, celle d'Apple en un statut qui peut rester gelé six mois. Les deux se défendent, aucune n'est gratuite, et le coût retombe exactement sur celui qui ne trouve qu'une fois et dont l'unique rapport pourrait être le plus précieux de l'année.

Pour un fabricant européen, la question cesse d'être philosophique le 11 septembre 2026, lorsque les obligations de notification du règlement sur la cyberrésilience commencent à s'appliquer. Le fabricant qui apprend qu'une vulnérabilité de son produit est activement exploitée doit en informer l'ENISA et le CSIRT national compétent dans les 24 heures, fournir une évaluation plus complète sous 72 heures et déposer un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. En France, l'interlocuteur est le CERT-FR, rattaché à l'ANSSI. Le règlement impose en outre une politique de divulgation coordonnée des vulnérabilités, c'est-à-dire une voie ordonnée par laquelle quelqu'un peut vous prévenir avant que les détails ne deviennent publics. À lire le délai attentivement, le problème de la boîte de réception devient un problème de conformité. Le compte à rebours démarre à la connaissance, et une file ensevelie sous des rapports non validés est une machine à retarder précisément cette connaissance.

Trois conséquences en découlent pour quiconque exploite cette réception. Exigez une reproduction fonctionnelle et écrivez-le sur la page que la personne qui signale accepte, car une reproduction est démontrable alors qu'une affirmation sur l'outil qui a rédigé le texte ne l'est pas. Réparez l'incitation avant d'écrire une règle, puisque la file de curl s'est améliorée quand le paiement a disparu, non quand une politique a changé. Et mesurez le taux de découvertes confirmées plutôt que le nombre de rapports, car le volume est justement le chiffre qui a augmenté dans le seul cas où tout s'est amélioré. Rien dans le règlement sur la cyberrésilience ne vous oblige à payer qui que ce soit. Il vous oblige à être joignable et à savoir distinguer un vrai rapport d'un rapport plausible assez vite pour lancer le compte à rebours à temps.

À lire ensuite: Siri AI a eu un prix avant d'avoir une date UE  |  Les services d'Apple ont reculé d'un trimestre à l'autre