Des niveaux de récompense bug bounty auxquels les chercheurs font vraiment confiance

Pour définir des niveaux de récompense bug bounty auxquels les chercheurs font confiance, faites quatre choses : rattachez les sévérités à un modèle de notation (CVSS ou un modèle propre à votre contexte), ancrez chaque niveau à des données de référence avec des fourchettes min et max plutôt qu’un chiffre unique, publiez et verrouillez la grille et le périmètre pour qu’ils ne puissent pas changer en silence après une soumission, et réservez le budget cash à l’impact tout en reconnaissant le travail à faible impact dans un circuit distinct. Ce qui détruit la confiance, ce n’est pas de payer trop peu. C’est de revaloriser un travail terminé après qu’un chercheur l’a déjà soumis, corrigé et fait créditer selon les anciens montants.

Cette distinction résume tout le premier semestre 2026. En mai, HackerOne a porté un coup de hache à l’Internet Bug Bounty (IBB), taillant dans les récompenses de tous les niveaux de sévérité, et une bonne partie de la levée de boucliers a visé le moment, pas le montant. Si vous gérez un programme de divulgation des vulnérabilités (VDP) ou un jeune bug bounty et que vous voyez s’accumuler les rapports générés par IA dans votre boîte de réception, vous craignez deux choses à la fois : être enseveli sous le bruit, et fixer des chiffres que vous devrez ensuite réduire en sacrifiant votre réputation auprès de la communauté des chercheurs. Ces deux craintes sont fondées. Une seule des deux se résout en réduisant les primes.

HackerOne a réduit les récompenses bug bounty jusqu’à 89 % sur des travaux que les chercheurs avaient déjà rendus

En mai 2026, HackerOne a abaissé les niveaux de récompense de l’Internet Bug Bounty d’environ 76 % à 89 % sur toute la grille, puis a suspendu le programme le temps d’évaluer d’autres ajustements. L’IBB est le fonds mutualisé qui récompense les vulnérabilités dans les dépendances open source critiques ; il avait distribué plus de 1,5 M$ depuis 2012, avec une répartition 80/20 entre découverte et accompagnement à la remédiation (source : InfoWorld / CSO).

Les chiffres

Ce ne sont pas de simples rognages. Voici la grille des niveaux, avant contre après, au 18 mai 2026 :

Source : The Register, 21 mai 2026. Une vulnérabilité de sévérité moyenne qui valait près de deux mille dollars rapporte désormais moins de trois cents. La justification de HackerOne : l’IBB est « un programme unique et dynamique dont les niveaux de prime s’ajustent automatiquement en fonction des contributions des sponsors actifs ». Sur la cause IA, l’entreprise a déclaré : « La recherche assistée par IA élargit la découverte de vulnérabilités dans tout l’écosystème, en augmentant à la fois la couverture et la vitesse. L’équilibre entre les vulnérabilités trouvées et la capacité de remédiation dans l’open source s’est nettement déplacé. »

Pourquoi c’est une histoire de confiance, pas de budget

Un programme a le droit de manquer d’argent. Un programme a le droit de juger qu’un niveau était surévalué. Ce à quoi les chercheurs ont réagi, c’est l’application du changement à un travail déjà terminé. Comme l’a résumé le chercheur en sécurité Jakub Ciolek : « Le problème de confiance, ici, c’est que le changement a été appliqué de fait bien après que le travail a été rendu, corrigé et publiquement crédité sous une attente différente » (source : The Register).

Un chercheur a touché un paiement de 297 $ face à une attente bien plus élevée. Ciolek lui-même attendait encore d’être payé pour des vulnérabilités Argo CD signalées à l’automne 2025 quand les nouveaux niveaux sont entrés en vigueur. Son diagnostic du moment plus large est la thèse de tout cet article : « La baisse des paiements est un symptôme. L’économie du signalement de vulnérabilités change très vite. » La leçon n’est pas arrêtez de payer. C’est changez les règles vers l’avant, pas vers l’arrière.

La vraie pression : l’IA n’a pas baissé la qualité des bugs, elle a fait exploser le volume des rapports

La lecture honnête de 2026, c’est que la pression du contenu IA bâclé est réelle et documentée, mais que le problème durable, c’est le volume, pas l’IA en soi. Les programmes ne se noient pas parce que l’IA écrit de mauvais bugs. Ils se noient parce que l’IA écrit beaucoup de rapports, et qu’invalider un rapport plausible mais bidon coûte toujours du temps réel à un ingénieur senior.

Le coup de fouet de curl : tuer le programme, puis le ressusciter

curl est le cas documenté le plus net, et il tranche dans les deux sens. Le mainteneur Daniel Stenberg a fermé le programme à compter de février 2026, expliquant : « Le torrent actuel de soumissions fait peser une lourde charge sur l’équipe sécurité de curl, et ceci est une tentative de réduire le bruit » (source : The Register, 21 janv. 2026). Pendant des années, les soumissions assistées par IA à curl n’avaient découvert pratiquement rien d’authentique durant l’ère du bâclage.

Puis la tendance s’est inversée. En mars 2026, curl est revenu sur HackerOne parce que la qualité des rapports IA s’était améliorée au point que « la quasi-totalité » de ses rapports désormais bons étaient assistés par IA, même si le volume brut avait à peu près doublé d’une année sur l’autre (source : The New Stack). À retenir : l’IA n’est pas durablement l’ennemie de la qualité des rapports. Le changement durable, c’est le volume. Votre structure de récompense doit survivre à une boîte de réception sous haute pression sans pénaliser les chercheurs qui produisent de vrais bugs.

Le geste plus discret de GitHub : des goodies plutôt que du cash pour les bugs à faible impact

Le 15 mai 2026, GitHub a annoncé que les vulnérabilités valides mais à faible impact recevraient une reconnaissance plutôt qu’un paiement : « Les soumissions qui ne démontrent pas d’impact significatif sur la sécurité mais qui débouchent sur un correctif de code ou de documentation seront récompensées par des goodies GitHub plutôt que par une prime. » La justification était explicite : « Nous préférons voir les chercheurs investir leur temps dans une recherche plus poussée et à fort impact, et être rémunérés en conséquence, plutôt que d’optimiser le volume sur des vulnérabilités à faible risque » (source : Blog GitHub).

C’est exactement le même instinct économique que la coupe de l’IBB : réserver le cash à l’impact, atténuer l’incitation au volume. Mais l’accueil a été tout autre, et cette différence change tout.

À quoi ressemble le « bon » exemple : la différence entre GitHub et l’IBB

Le geste constructif et le geste controversé se ressemblent mécaniquement. Tous deux réduisent ce que rapporte le travail à faible impact. La différence tient au moment et au préavis.

GitHub a changé les règles pour l’avenir et publié sa justification avant que quiconque ne soumette sous les nouvelles conditions. Un chercheur qui dépose un rapport aujourd’hui sait qu’une vulnérabilité de niveau « correctif de documentation » rapporte des goodies, pas du cash, et il s’engage en connaissance de cause. La coupe de l’IBB a frappé un travail déjà soumis et crédité selon les anciens montants. Même direction, résultat inverse sur la confiance.

Ce n’est pas une leçon nouvelle. En 2020 déjà, Bountysource avait annoncé qu’il « conserverait » les primes non réclamées via une modification discrète de ses conditions d’utilisation, fait machine arrière après la levée de boucliers, et vu des projets comme elementary OS publier des billets intitulés « Au revoir, Bountysource ». Les changements rétroactifs apportés à un accord de récompense sont l’archétype du geste qui détruit la confiance. La plateforme de bug bounty crypto Immunefi a cristallisé le principe inverse dans un article intitulé « The Bug Bounty Program Is Law » (« le programme de bug bounty fait loi ») : la page de programme publiée est contraignante, et un projet ne peut pas renégocier rétroactivement un rapport déjà soumis sous ses termes.

L’attente au moment de la soumission doit être égale à l’attente au moment du paiement. Tout le reste est négociable. Cela, non.

Le cadre ci-dessous n’a donc pas vraiment à voir avec les chiffres. Il s’agit de rendre vos conditions publiées structurellement incapables de trahir un chercheur après coup.

Comment définir des niveaux de récompense bug bounty qui résistent au contenu IA bâclé

Définissez les niveaux en quatre étapes : ancrez-les à des données, publiez-les et verrouillez-les, rendez chaque paiement auditable, et récompensez l’effort par une reconnaissance plutôt que par une baisse de salaire déguisée. Rien de tout cela n’exige un budget à l’échelle de HackerOne. Cela exige de la discipline, et c’est ce qui distingue un programme auquel les chercheurs font confiance du prochain titre d’avertissement.

Étape 1 : ancrer les niveaux aux données, pas au ressenti

Commencez par rattacher les sévérités à un modèle de notation pour que « critique » veuille dire la même chose à chaque fois. CVSS est le choix courant ; un modèle propre à votre contexte fonctionne si vos actifs ne rentrent pas proprement dans CVSS. Ensuite, fixez le prix de chaque niveau à partir de données de distribution réelles, et non d’un chiffre rond deviné au jugé.

Deux ancrages comptent :

• Les références externes, surtout quand vous débutez. Les grilles de récompense publiées par Microsoft vont de 500 à 30 000 $ pour les applications et l’on-premise, et de 1 250 à 19 500 $ pour M365, avec un record de 17 M$ versés en 2024-2025 (source : MSRC). Sur l’ensemble de HackerOne, le paiement annuel moyen par programme actif tourne autour de 42 000 $, et la plateforme a versé 81 M$ au total sur les douze derniers mois, en hausse de 13 % (source : BleepingComputer). Une règle empirique répandue dans le secteur veut que les organisations soient prêtes à payer au-delà de 7 000 $ pour une vulnérabilité critique, sans qu’il existe de standard universel.
• Votre propre historique, dès que vous en avez un. La médiane, la moyenne, le min et le max que vous avez réellement versés par niveau de sévérité et par type de vulnérabilité vous indiquent où se situe la vraie distribution, afin de fixer le prix du niveau suivant à partir de preuves plutôt qu’en taillant uniformément dans toute la grille.

Utilisez des niveaux à fourchette (un min et un max par sévérité), pas un chiffre unique et fragile. Les fourchettes vous permettent de récompenser une critique exceptionnelle en haut de la bande et une critique marginale en bas, sans réécrire la grille. C’est la pratique que recommandent à la fois Intigriti et la Bug Bounty Community of Interest, et c’est précisément ce qui manque aux coupes uniformes comme celle de l’IBB.

Étape 2 : publier et verrouiller vos conditions et votre périmètre

Consignez la grille des primes, les actifs dans le périmètre et hors périmètre, les types de vulnérabilités exclus, vos engagements de SLA et votre clause de sphère de sécurité (Safe Harbor) dans une politique unique et publiée. Versionnez-la ensuite, et considérez la version à laquelle un chercheur a souscrit au moment de la soumission comme contraignante pour ce rapport.

C’est la réponse structurelle à la plainte visant l’IBB. Si les conditions sont publiées et verrouillées au moment de la soumission, aucun mécanisme ne permet de revaloriser en silence un travail terminé. Le chercheur souscrit à un accord connu. Si vous voulez changer l’accord, vous le changez pour les soumissions futures et vous l’annoncez, à la manière de GitHub.

Étape 3 : rendre chaque paiement auditable

Chaque récompense et chaque ajustement doivent être un événement explicite, journalisé et défendable, avec un horodatage et un motif. Un grand livre financier auditable fait deux choses. Il prouve à un chercheur que le montant reçu correspond au niveau qui lui a été promis. Et, dans les rares cas où vous ajustez réellement une récompense, il montre que l’ajustement était une décision délibérée et consignée, et non une réévaluation automatique opaque.

La formule de l’IBB, « les niveaux de prime s’ajustent automatiquement », est précisément ce qu’un grand livre financier empêche. Automatique et invisible, voilà ce qui érode la confiance. Délibéré et journalisé, voilà ce qui la préserve, même quand le chiffre change.

Étape 4 : récompenser l’effort par une reconnaissance, pas par une baisse de salaire déguisée

Les vulnérabilités valides mais à faible impact méritent une reconnaissance. La bonne façon de l’accorder, c’est un circuit de reconnaissance distinct et additif : des points de réputation ou de karma, des goodies, une place au tableau d’honneur. La mauvaise façon, c’est de maquiller une réduction de cash en « reconnaissance » sur un travail qui aurait dû être payé.

La politique « des goodies pour le faible impact » de GitHub est la version propre, parce qu’elle est annoncée à l’avance et coexiste avec le cash pour les bugs à fort impact, sans jamais remplacer un cash promis sur un travail déjà soumis. La reconnaissance complète vos niveaux cash verrouillés. Elle n’est jamais une porte dérobée pour revaloriser.

Faire tout cela dans Kit

La boîte à outils CSIRT de Kit est construite autour de ces quatre habitudes, et c’est tout l’enjeu : la discipline est imposée par l’outil, et non laissée aux bonnes intentions. Soyons clairs : Kit est un jeune produit de gestion de programmes, pas une place de marché dotée du volume de paiements ou du jeu de données de référence de HackerOne. Ce qui fait la différence, c’est la structure qu’il impose, et cette structure constitue l’essentiel de ce sur quoi repose la confiance.

• Des niveaux ancrés à des références. Agrégez vos propres récompenses passées (médiane, moyenne, min, max, exemples récents) filtrées par niveau de sévérité et type de vulnérabilité, afin de fixer le prix de chaque niveau à partir de données de distribution réelles et de pouvoir montrer à un chercheur la médiane pour sa catégorie de bug. Les nouveaux programmes s’appuient d’abord sur des références externes, comme les bandes publiées par Microsoft, jusqu’à constituer leur propre historique.
• Des niveaux à fourchette, publiés. Configurez la grille des primes avec un min et un max par sévérité, sur les niveaux informatif, faible, moyenne, élevée, critique et un niveau super critique, puis publiez-la avec le périmètre, le SLA et les conditions de sphère de sécurité (Safe Harbor) sous forme d’une politique versionnée à laquelle les chercheurs souscrivent à la soumission.
• Un grand livre financier auditable. Chaque approbation, ajustement et versement est un événement financier typé et journalisé, filtrable par rapport et par date, pour que le paiement corresponde à la promesse et que tout ajustement soit une décision consignée, non une réévaluation silencieuse.
• Un circuit de karma distinct. La reconnaissance non monétaire coexiste avec les niveaux cash verrouillés, avec des préréglages fixes et transparents, pour qu’une vulnérabilité valide mais à faible impact soit honorée sans que personne ne déguise une coupe de cash en remerciement.

Nous avons creusé le sujet du maintien d’un programme à flot quand la boîte de réception déborde dans le guide de triage VDP, et celui du démarrage de zéro dans comment mettre en place un programme de divulgation des vulnérabilités. Cet article est la couche conception des récompenses qui vient se poser sur les deux.

FAQ

Un programme de bug bounty peut-il changer les récompenses après la soumission ?

Il le peut, mais il ne devrait pas. La levée de boucliers contre l’IBB en mai 2026 a moins été provoquée par l’ampleur de la coupe que par le fait qu’elle s’appliquait à un travail déjà soumis, corrigé et crédité selon les anciens niveaux. Le schéma défendable, illustré par GitHub, consiste à changer les récompenses pour l’avenir uniquement, avec un préavis publié, pour que les chercheurs souscrivent aux nouvelles conditions en connaissance de cause. Considérez votre page de programme publiée comme contraignante pour tout rapport soumis sous ses termes.

Combien faut-il payer pour un bug critique ?

Il n’existe pas de standard universel ; c’est un calcul de risque. Comme repères directionnels : Microsoft paie jusqu’à 30 000 $ pour les vulnérabilités applicatives de premier niveau, le programme HackerOne moyen verse autour de 42 000 $ par an tous niveaux confondus, et une règle empirique répandue voit les organisations payer au-delà de 7 000 $ pour une critique (sources : MSRC ; BleepingComputer). Fixez une fourchette min-max par sévérité, ancrée à ces références et à votre propre historique, et non un chiffre fixe unique.

Comment gérer les rapports bug bounty générés par IA ?

Ne réduisez pas les primes pour les décourager ; cela pénalise les chercheurs qui produisent de vrais bugs. Le problème durable, c’est le volume, pas l’IA. curl a prouvé que la qualité des rapports IA peut passer de sans valeur à « quasiment tous bons » en l’espace d’un an. Gérez le volume par le triage (filtrage, limitation de débit, notation de réputation, protection du SLA) et gérez la conception des récompenses en payant pour l’impact et en reconnaissant le travail à faible impact séparément, pour que l’incitation récompense la qualité plutôt que le nombre de soumissions.

L’essentiel

Quand l’IA inonde votre boîte de réception, l’instinct est de protéger le budget en réduisant ce que vous payez. L’IBB montre où cela mène quand la coupe frappe un travail terminé : un trou de crédibilité qu’aucune somme d’argent ne comble vite. La réponse durable est structurelle. Ancrez vos niveaux à des données réelles, publiez et verrouillez les conditions et le périmètre, journalisez chaque paiement pour que les ajustements soient délibérés et visibles, et récompensez l’effort par une reconnaissance qui accompagne le cash au lieu de le remplacer. Faites cela et votre VDP reste crédible quand le déluge IA arrive, au lieu de devenir le prochain titre d’avertissement.

Si vous concevez une grille de récompense que vous voulez publier dès aujourd’hui sans la regretter dans six mois, démarrez un essai gratuit de Kit et configurez dès le départ un programme référencé, verrouillé et auditable.