Les litiges sur les primes de bug bounty surviennent lorsqu'un programme refuse, réduit ou retarde une récompense sans rattacher sa décision à une règle que le chercheur aurait pu lire à l'avance. Les déclencheurs les plus fréquents : un correctif lent sans horloge de résolution, un verdict « hors périmètre » prononcé après la publication du correctif, un paiement inférieur à la grille annoncée, et des modifications rétroactives des conditions du programme. La solution n'est pas de payer davantage. C'est de publier l'horloge et la grille en amont, de mesurer le délai de correction par rapport à elles, et de consigner chaque décision (approbation, réduction ou refus) dans un grand livre auditable.

En juin 2026, AMD a transformé un chercheur coopératif en critique public en se trompant sur ces quatre points à la fois. Voici la marche à suivre pour ne pas reproduire l'erreur.

## 124 jours, puis « hors périmètre » : le bras de fer sur la prime AMD

En février 2026, le chercheur Paul LaRosa (alias « MrBruh ») a signalé une faille critique dans l'outil de mise à jour automatique d'AMD. L'utilitaire récupérait sa liste de mises à jour en HTTPS, mais téléchargeait les exécutables eux-mêmes en HTTP en clair, sans véritable vérification de signature. Un attaquant présent sur le même réseau pouvait monter une attaque de l'homme du milieu et pousser du code malveillant sur la machine de la victime.

AMD a mis **124 jours** à publier un correctif. Puis l'entreprise a **refusé la prime de 10 000 $**, qualifiant les attaques de l'homme du milieu contre des « outils optionnels » de hors périmètre. Et ce, alors même qu'AMD avait attribué un CVE (CVE-2026-40677, score CVSS 4.0 de 7,7, ÉLEVÉ) et crédité publiquement LaRosa dans son propre bulletin de sécurité. Le correctif finalement déployé n'ajoutait qu'un contrôle CRC32, c'est-à-dire une somme de contrôle d'intégrité, et non une signature cryptographique. Plusieurs médias ont également rapporté qu'AMD avait révisé les conditions de son programme pour exiger un consentement écrit avant toute divulgation, puis appliqué ce changement au cas de LaRosa après coup.

Le bug n'était pas l'histoire. L'histoire, c'est qu'une horloge lente, doublée d'une décision de paiement opaque et prise après coup, a transformé un chercheur qui avait discrètement signalé une faille réelle en quelqu'un muni d'un mégaphone et d'un grief. Chaque élément de ce dénouement résultait d'un choix de processus, et chacun était évitable.

> Une précision sur ce que cet article n'affirme pas : AMD n'avait aucune obligation légale de payer, et personne ne peut forcer l'inclusion d'un rapport donné dans le périmètre. L'affirmation honnête, plus restreinte, est que le *processus* a échoué. Une horloge silencieuse, un verdict de périmètre non documenté et une décision non consignée : voilà ce qui a transformé une prime refusée en incident de réputation.

## Pourquoi les litiges sur les primes de bug bounty éclatent

Les litiges sur les primes de bug bounty portent rarement sur le seul montant. Ils naissent de l'écart entre ce qu'un programme a annoncé et ce qu'il a réellement fait. Les chercheurs tolèrent un plafond bas ; ils ne tolèrent pas qu'on déplace les poteaux du but. Cinq tueurs de confiance sont à l'origine de la plupart des litiges :

- **Aucune horloge de résolution.** Le correctif traîne pendant des mois parce que rien ne décompte. Le chercheur reste dans le silence et présume la mauvaise foi.
- **« Hors périmètre », décidé après la publication du correctif.** L'éligibilité est tranchée rétroactivement, une fois que l'entreprise a déjà le correctif en main.
- **Un paiement inférieur à la grille annoncée.** Un programme qui promet « 1 000 $+ pour une faille Moyenne » paie 200 $ sans la moindre explication : l'injustice ressentie tient à l'écart, pas au chiffre.
- **Des changements de règles rétroactifs.** Les conditions évoluent en cours de rapport, et les nouvelles s'appliquent rétroactivement à un rapport déposé sous les anciennes.
- **Des décisions opaques, non consignées.** Personne ne peut reconstituer qui a décidé quoi, quand, et au regard de quelle règle.

Les vétérans de la sécurité tirent la sonnette d'alarme depuis des années. Comme l'ont avancé des voix critiques telles que Katie Moussouris, Jonathan Leitschuh, Robert Graham et Tavis Ormandy dans la presse consacrée à l'industrie du bug bounty, les accords de confidentialité et l'achat du silence érodent le modèle de divulgation ; c'est la transparence qui rend un programme efficace. Le schéma est identique dans chaque litige : la décision n'était rattachée à rien que le chercheur aurait pu lire à l'avance.

### Sans horloge de résolution, le correctif ne fait que dériver

Une vulnérabilité sans échéance de remédiation est une vulnérabilité dont personne n'est propriétaire. La plupart des organisations mettent **60 à 150 jours** à corriger les vulnérabilités critiques, selon une étude sur les SLA de remédiation de Secure.com. Pendant ce temps, les attaquants exploitent les failles critiques en aussi peu que **5 jours** après leur divulgation publique, et environ **60 % des violations de 2024** étaient liées à une vulnérabilité connue et non corrigée. Les 124 jours d'AMD se situaient en plein cœur de la zone de danger, et faute d'horloge publiée, personne n'en était responsable.

### « Hors périmètre », décidé après la publication du correctif

Le périmètre est une promesse que vous faites avant l'arrivée du rapport, pas un verdict que vous rendez une fois le correctif en poche. Lorsqu'un programme accepte un rapport, attribue un CVE, crédite le chercheur, puis déclare le même problème hors périmètre, la décision de périmètre se lit comme une manœuvre d'évitement de paiement : car c'est fonctionnellement ce qu'elle est. Tranchez l'éligibilité au regard d'un document de périmètre publié à l'avance, ou n'invoquez pas le périmètre du tout.

### Un paiement inférieur à la grille annoncée

Un autre litige, largement commenté, concernait un chercheur à qui l'on a proposé **50 000 $** pour un bug critique, alors que le maximum affiché du programme était de **500 000 $**, sans explication détaillée de la réduction et avec un long retard de paiement. Le montant était peut-être défendable. Le silence ne l'était pas. Une réduction sans raison documentée au regard d'une grille publique passera toujours pour une offre au rabais, même quand elle ne l'est pas.

### Des changements de règles rétroactifs

Modifier les conditions de votre programme, c'est très bien. Appliquer les nouvelles conditions à des rapports déposés sous les anciennes, non. Une fois que vous acceptez une soumission, les règles en vigueur au moment du dépôt sont celles qui la régissent. Tout le reste relève de l'appât trompeur, et la communauté des chercheurs le traite comme tel.

## Quelle vitesse est « assez rapide » ? Les SLA de résolution par sévérité

Un SLA de résolution est une échéance publiée, par niveau de sévérité, pour le déploiement d'un correctif, comptée à partir du moment où vous confirmez le rapport. C'est ce qui rend « 124 jours » objectivement indéfendable, plutôt qu'une simple question d'opinion. Les objectifs largement cités dans l'industrie sont serrés :

| Sévérité | Objectif SLA courant | Variante du manuel GitLab |
|---|---|---|
| Critique | 24 à 72 heures | atténuation en 24 h |
| Élevée | 30 jours | 30 jours |
| Moyenne | 60 jours | 90 jours |
| Faible | 90 jours | 180 jours |

Sources : guide des SLA de remédiation de Secure.com ; manuel de gestion des vulnérabilités de GitLab.

Au regard de l'une ou l'autre de ces références, un correctif de 124 jours pour un problème critique de type RCE dépasse l'objectif de plusieurs fois. Les seuils exacts de chaque niveau vous appartiennent. Ce qui compte, c'est de les définir, de les publier du pire au moins grave sur votre page de politique, et de poser une horloge sur chaque rapport confirmé, pour que « en retard » soit un statut que le système fait remonter, et non une plainte que le chercheur doit déposer.

<div class="blog-inline-cta">
  <p><strong>Vous voulez que l'horloge tourne toute seule ?</strong> Le module CSIRT de Kit attache un SLA de résolution par niveau de sévérité à chaque rapport et fait remonter automatiquement les statuts dans les temps, à risque ou dépassé, pour qu'un correctif ne puisse jamais dériver en silence.</p>
  <p><a href="/users/sign_up">Démarrez votre essai gratuit</a></p>
</div>

## Combien une prime devrait réellement payer

Une grille des primes est un tableau publié des fourchettes de récompense par niveau de sévérité, ancré à des données de marché réelles, pour que les récompenses soient calculées et non négociées à la baisse. Les références publiques vous donnent les points d'ancrage :

| Niveau | Médianes HackerOne | Fourchettes Bugcrowd |
|---|---|---|
| Critique / P1 | 3 000 $ à 5 000 $ | 3 500 $ à 20 000 $+ |
| Élevée / P2 | 1 000 $ à 2 500 $ | 1 500 $ à 7 500 $ |
| Moyenne / P3 | 500 $ à 1 000 $ | 500 $ à 2 500 $ |
| Faible / P4 | 100 $ à 300 $ | 175 $ à 600 $ |

Sources : bug-bounties.as93.net (médianes HackerOne) ; recommandations de paiement de Bugcrowd.

Ce sont des fourchettes, pas une parole d'évangile. Le Vulnerability Reward Program de Google paie bien plus, les découvertes critiques se situant entre 10 000 $ et 31 337 $, et à l'échelle de la plateforme, HackerOne a versé aux chercheurs environ **81 millions de dollars** sur une période récente de 12 mois. Présentez votre grille sous forme de fourchettes, mentionnez la plateforme que vous avez prise comme référence, et résistez à la tentation de citer une unique « prime moyenne » canonique. Le but de la grille n'est pas d'être généreux. C'est de permettre à un chercheur d'estimer sa récompense avant de cliquer sur « soumettre », et de faire en sorte que votre récompense finale tombe dans une fourchette qu'il a déjà vue.

## Comment refuser un rapport sans perdre le chercheur

Vous refuserez des rapports. Hors périmètre, doublon, informatif, risque accepté : toutes ces classifications sont légitimes. Un refus ne devient un litige que lorsqu'il prend par surprise. Quatre pratiques empêchent un « non » de tourner au conflit public :

1. **Décidez au regard d'une règle publiée à l'avance.** Pointez vers le document de périmètre ou le niveau de la grille sur lequel repose la décision, en le nommant. Si la règle n'existait pas au moment du dépôt du rapport, vous ne pouvez pas l'invoquer.
2. **Montrez les données.** Lorsque vous réduisez une récompense, montrez la fourchette de référence d'où vient le chiffre. Une raison documentée vaut mieux qu'un montant généreux versé en silence.
3. **Préservez la reconnaissance.** Un paiement refusé n'a pas à signifier un crédit effacé. Une place au tableau d'honneur et des points de réputation ne coûtent rien et préservent la bonne volonté, même quand l'argent est contesté.
4. **Proposez un recours.** Un « non » à sens unique se lit comme un verdict tombé d'en haut. Une décision révisable se lit comme équitable, même quand la réponse ne change pas.

Si vous n'avez pas encore mis en place le volet réception de tout cela, commencez par notre guide sur [comment mettre en place un programme de divulgation des vulnérabilités](/blog/how-to-set-up-vulnerability-disclosure-program). Et si votre inquiétude porte sur la relation plutôt que sur l'argent, l'article complémentaire sur [quand les chercheurs rendent l'affaire publique après une divulgation ratée](/blog/when-researchers-go-public-botched-disclosure) traite en profondeur des mécaniques de confiance. Cet article en est la suite « jour 2 » : comment ne pas perdre un chercheur quand l'argent et une échéance sont tous deux en jeu. (Pour le problème de la montée en volume, voir [le contenu IA bâclé qui submerge le triage du bug bounty](/blog/ai-slop-flooding-bug-bounty-triage).)

## Comment Kit opérationnalise les SLA de résolution et l'équité des paiements

La verticale CSIRT de Kit a été conçue comme une réponse presque point par point à l'échec d'AMD : publier l'horloge et la grille, mesurer le délai de correction par rapport à elles, et consigner chaque décision de paiement pour qu'elle soit défendable plutôt que reniable. Voici comment chaque faux pas d'AMD correspond à une fonctionnalité intégrée.

| Échec dans le cas AMD | Comment Kit le gère |
|---|---|
| L'horloge de 124 jours tournait en silence | Des SLA d'objectif de résolution par niveau de sévérité, publiés du pire au moins grave, avec des valeurs par défaut allant de 24 h pour le super critique à 30 j pour le faible |
| Personne ne signalait « ceci est en retard » | Un état de SLA en direct sur chaque rapport : dans les temps, à risque ou dépassé, plus un contrôle « avons-nous résolu dans l'objectif ? » |
| L'accusé de réception dérivait | Un SLA d'accusé de réception distinct (72 h par défaut) alimente le calcul du risque et du dépassement |
| Paiement décidé au cas par cas, puis refusé | Une référence de prime calcule les paiements médian, moyen, minimal et maximal par niveau de sévérité à partir de votre propre historique de récompenses, pour que celles-ci soient ancrées aux données |
| « Hors périmètre » prononcé après coup | Une configuration de périmètre et une grille des primes publiées à l'avance tranchent l'éligibilité en amont, et non rétroactivement |
| Aucune trace auditable de la décision | Les récompenses de primes alimentent un grand livre à intégrité vérifiée et des enregistrements de versement qui valident le solde courant et signalent toute anomalie |
| Reconnaissance conditionnée au paiement | Les événements de karma et un tableau d'honneur préservent le crédit du chercheur même quand un paiement est contesté ou refusé |
| Refus traité comme un « non » à sens unique | Une voie de recours intégrée rend une récompense refusée ou réduite révisable, et non tombée d'en haut |

La thèse est étroite et elle tient : AMD n'a pas perdu le chercheur parce que le bug était difficile. L'entreprise l'a perdu parce qu'aucune horloge ne tournait et que la décision de paiement a été prise dans l'ombre, après coup, au regard d'une règle qui n'existait pas au moment de son signalement. Un SLA de résolution que vous publiez et suivez, plus une grille des primes ancrée à vos propres données de paiement et consignée dans un grand livre, transforment « hors périmètre, aucun paiement » d'une trahison en une décision prévisible et défendable. Payer ou non un rapport donné reste votre décision. Kit rend cette décision rapide, ancrée aux données et auditable.

## À retenir : publiez l'horloge et la grille avant même de dire non

Tout litige sur une prime de bug bounty remonte à la même cause profonde : une décision prise au regard d'une règle que le chercheur n'a jamais pu voir. Publiez vos SLA de résolution par niveau de sévérité. Ancrez votre grille des primes à des données de référence réelles et publiez-la, elle aussi. Posez une horloge sur chaque rapport confirmé, pour que « en retard » soit un état du système et non la plainte d'un chercheur. Consignez chaque approbation, réduction et refus dans un grand livre que vous pouvez auditer. Faites cela, et un refus devient quelque chose que le chercheur attendait, peut vérifier, et autour duquel il continuera à signaler des failles, au lieu de la chose qui vous propulse à la une de Tom's Hardware.

Si vous pilotez un VDP ou un programme de primes rémunérées et que le volet argent-et-horloge vit encore dans des tableurs et de la bonne volonté, c'est précisément la lacune que comble le module CSIRT de Kit. [Démarrez un essai gratuit](/users/sign_up) et fixez vos SLA et votre grille des primes avant que le prochain rapport critique n'arrive.