Pour trier les rapports de bug bounty générés par IA, actionnez cinq leviers dans l'ordre : (1) un premier filtrage assisté par IA qui signale automatiquement les fonctions hallucinées et l'absence de preuve de concept avant qu'un humain ne lise le rapport, (2) une limitation de débit dès la réception pour qu'un seul acteur ne puisse pas noyer la file, (3) un score de réputation qui pénalise le slop avéré, (4) un suivi des SLA qui protège le temps rare des relecteurs, et (5) des primes qui rémunèrent l'impact, pas le nombre de soumissions. Les programmes qui se sont éteints en 2026 n'avaient pas un problème de slop. Ils avaient un problème de triage.

Si vous gérez une boîte de réception `security.txt`, un programme de divulgation de vulnérabilités (VDP) ou un bug bounty, vous le sentez déjà. Le volume de soumissions grimpe et le taux de rapports valides s'effondre. Chaque rapport plausible mais bidon coûte encore à un ingénieur senior entre 30 minutes et trois heures pour être réfuté. C'est le problème de l'exploitation sous charge : la question n'est pas « faut-il avoir un VDP » (oui, et nous avons couvert [comment en monter un](/blog/how-to-set-up-vulnerability-disclosure-program)), mais « la file déborde, comment la garder en vie sans épuiser les relecteurs ni perdre les vrais chercheurs ? »

## Les victimes de 2026 : curl, HackerOne et Nextcloud

Au premier semestre 2026, trois des noms les plus crédibles de la divulgation de vulnérabilités ont visiblement plié sous le bruit généré par IA. Ce ne sont pas des programmes marginaux. Ce sont les références en matière de divulgation bien faite, et ils ont tous heurté le même mur : le coût de production d'un faux rapport a chuté à presque zéro tandis que le coût de sa réfutation est resté humain, et élevé.

### Pourquoi curl a débranché la prise

curl a fermé son bug bounty HackerOne à compter du **31 janvier 2026**. Son fondateur, Daniel Stenberg, documentait le déclin depuis des mois. Dans son billet de juillet 2025 « Death by a thousand slops », il rapportait qu'**environ 20 % de toutes les soumissions de 2025 étaient du slop IA** et que **seulement 5 % environ des soumissions de 2025 se révélaient être de véritables vulnérabilités**, une chute brutale par rapport aux années précédentes (source : [daniel.haxx.se](https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/)).

L'économie était impitoyable à l'échelle humaine. Chaque rapport mobilisait **trois à quatre des sept membres de son équipe sécurité** pendant **30 minutes à environ trois heures** de validation, presque exclusivement du temps bénévole. Le début 2026 a tranché à sa place : sur les **21 premiers jours de 2026, curl a reçu une vingtaine de soumissions et confirmé zéro vulnérabilité**, dont **sept rapports HackerOne dans une seule fenêtre de 16 heures** (source : [daniel.haxx.se](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/) ; [BleepingComputer](https://www.bleepingcomputer.com/news/security/curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/)).

Depuis le 1er février 2026, curl redirige les rapports vers le signalement privé de GitHub et `security@curl.se`, sans récompense monétaire, explicitement, selon les mots de Stenberg, pour « supprimer l'incitation à soumettre de la camelote ». Sur toute sa durée de vie, le programme a payé pour **87 vulnérabilités confirmées et plus de 100 000 dollars depuis 2019**. La prime a fonctionné pendant des années. C'est le slop IA qui l'a brisée.

### La flambée de 76 % chez HackerOne et la mise en pause de l'Internet Bug Bounty

HackerOne a fait deux mouvements distincts. D'abord, son **Internet Bug Bounty (IBB)**, le fonds mutualisé qui rémunère les dépendances open source critiques, a **suspendu les nouvelles soumissions fin mars 2026**, invoquant un déséquilibre entre la découverte assistée par IA et la capacité humaine de remédiation (source : [Privacy Guides](https://www.privacyguides.org/news/2026/04/17/hackerone-pauses-internet-bug-bounty/) ; [InfoWorld](https://www.infoworld.com/article/4154210/internet-bug-bounty-program-hits-pause-on-payouts.html)).

Ensuite, en avril 2026, parallèlement au lancement d'un service de validation payant, HackerOne a dévoilé la statistique macro qui a fait les gros titres : **les soumissions de vulnérabilités ont bondi de 76 % d'une année sur l'autre, atteignant un record en mars 2026**, tandis qu'**environ 25 % des découvertes étaient confirmées exploitables**, un taux resté à peu près stable (source : [communiqué de presse HackerOne](https://www.hackerone.com/press-release/hackerone-introduces-h1-validation-help-enterprises-manage-surge-ai-discovered)). Lisez bien : le nombre absolu de vrais bugs continue de croître, mais le bruit autour aussi, et le bruit croît plus vite. En mai 2026, l'IBB a **réduit fortement les montants des primes pour tous les niveaux de sévérité** (source : [The Register](https://www.theregister.com/security/2026/05/21/hackerone-takes-an-axe-to-its-bug-bounty-rewards/5244458)).

### Le phénomène touche tout l'écosystème

Il serait facile de balayer curl comme un projet open source sous-financé et HackerOne comme les douleurs de croissance d'une seule plateforme. Le schéma est plus large que cela.

| Programme | Ce qui s'est passé | Quand |
|---|---|---|
| **Nextcloud** | Fin des paiements, invoquant une « augmentation massive de rapports de faible qualité » ; réception maintenue ouverte le temps de « trouver comment filtrer correctement les soumissions » | Avril 2026 |
| **Google** | A cessé d'accepter certains rapports générés par IA | Mars 2026 |
| **Cosmos Labs (crypto)** | Le co-PDG rapporte un **bond de 900 % d'une année sur l'autre**, soit 20 à 50 soumissions par jour | 2026 |
| **Bugcrowd** | Les soumissions ont **plus que quadruplé sur une période de trois semaines**, majoritairement des faux positifs ou des découvertes IA de faible qualité | Mars 2026 |
| **Noyau Linux** | Linus Torvalds a qualifié la liste de sécurité de « quasiment ingérable » sous les rapports en double assistés par IA | 2026 |

Sources : [heise](https://www.heise.de/en/news/Due-to-AI-Bug-bounty-programs-without-rewards-now-also-at-Nextcloud-11271443.html) ; [Computing.co.uk](https://www.computing.co.uk/news/2026/security/bug-bounty-platforms-battle-ai-slop) ; [Cointelegraph via TradingView](https://www.tradingview.com/news/cointelegraph:f6afb56fe094b:0-ai-drives-surge-in-bug-bounty-reports-but-slop-is-rising-too/).

La phrase de Nextcloud est la plus parlante. Ils n'ont pas tué la réception. Ils ont gardé le canal ouvert et arrêté de payer *le temps de pouvoir filtrer correctement*. Cet écart — « on veut les rapports mais on n'a pas les moyens de les trier » — est précisément le sujet de cet article.

## Pourquoi le slop IA casse l'économie du bug bounty

Un bug bounty est un mécanisme de signal coûteux. Le postulat d'origine : un humain a investi un effort réel pour trouver un bug, donc il produit un rapport précis et reproductible, et son triage vaut le temps du relecteur. Tout le modèle repose sur le fait que l'effort de soumission est assez cher pour filtrer le bruit à la source.

L'IA fait s'effondrer ce postulat. Elle rend la production d'un rapport plausible presque gratuite, tandis que le coût de sa réfutation reste obstinément humain. Un rapport généré peut citer un CVE d'apparence réelle, décrire une fonction d'apparence réelle et exposer des étapes de reproduction pleines d'assurance — le tout halluciné. Le relecteur doit malgré tout ouvrir le code, suivre l'affirmation et prouver une absence. Prouver qu'un bug est réel est rapide. Prouver qu'un faux convaincant *n'est pas* réel est lent.

Et c'est pire encore. L'IA a tendance à faire remonter de multiples occurrences du *même* problème sous-jacent — le même schéma de cross-site scripting avec vingt charges utiles différentes — et à soumettre chacune comme une découverte distincte. Le volume gonfle sans que la sécurité progresse. Le goulot d'étranglement se déplace entièrement vers la validation, la seule partie du pipeline que l'on ne peut pas automatiser à bas coût par défaut (source : [Pen Test Partners](https://www.pentestpartners.com/security-blog/ai-noise-and-the-effect-its-having-on-vulnerability-disclosure-programs/)).

À garder en tête pour la juste mesure : les VDP et les primes affichaient historiquement **60 à 80 % de soumissions invalides, même avant l'IA** (source : [Yogosha](https://yogosha.com/blog/ai-and-vulnerability-triage-lessons-learned-from-our-automated-assistance-poc/)). La taxe de triage a toujours existé. L'IA n'a pas inventé le problème. Elle a supprimé le frein naturel qui le rendait soutenable.

## La méthode de triage : cinq leviers pour garder un VDP en vie

On ne règle pas ça avec un seul outil. On le règle en inversant l'économie : en renchérissant le coût de soumission du slop et en abaissant le coût de son filtrage. Voici les cinq leviers, par ordre d'effet de levier.

1. **Premier filtrage assisté par IA dès la réception.** Classer automatiquement le slop évident (fonctions hallucinées, CVE fabriqués, absence de preuve de concept, langage générique de modèle) avant qu'un humain n'y passe une heure.
2. **Limitation de débit et contrôles anti-spam.** Un plafond glissant pour qu'un seul acteur ne puisse pas noyer la file en une rafale de 16 heures.
3. **Score de réputation qui pénalise le slop.** Faire en sorte que le slop avéré coûte à celui qui le soumet, pour que les récidivistes s'auto-excluent.
4. **Suivi des SLA qui protège le temps des relecteurs.** Accuser réception et résoudre dans des délais chronométrés, pour que les vrais chercheurs ne passent pas en public par frustration.
5. **Primes à l'impact, pas au volume.** Payer selon la sévérité, mettre les découvertes informatives à zéro et imposer la consolidation, pour qu'un millier de découvertes identiques ne soit payé qu'une fois.

### 1. Premier filtrage assisté par IA dès la réception

Le geste à plus fort effet de levier est de cesser de laisser les soumissions brutes arriver d'abord chez un humain. Une passe de tri par LLM peut repérer les indices que presque tous les rapports de slop partagent : références à des fonctions ou éléments de code qui n'existent pas, CVE présentés comme nouveaux alors qu'ils sont vieux de plusieurs années ou fabriqués, formules de remédiation génériques, et absence de toute preuve de concept précise et exécutable.

Le choix de conception crucial est que cette passe est *assistive*, pas un rejet automatique. Le premier filtre doit recommander, pas décider : haute confiance, à relire, ou à signaler. Un humain tranche toujours sur tout cas limite. Vous ne construisez pas un robot gardien. Vous construisez un Choixpeau qui détourne le slop évident de l'attention de vos ingénieurs seniors.

### 2. Limitation de débit et contrôles anti-spam

curl a encaissé sept rapports en 16 heures. Aucune équipe humaine ne trie ça en temps réel. Un simple plafond glissant — disons cinq rapports par acteur toutes les cinq minutes avant un blocage temporaire — neutralise le schéma de rafale sans toucher aux chercheurs légitimes, qui ne soumettent presque jamais en succession rapide. C'est le levier le moins coûteux à mettre en place et l'un des plus efficaces contre la forme d'attaque spécifique de 2026.

### 3. Score de réputation qui pénalise le slop

Les systèmes de karma sont vieux comme le monde dans l'univers des primes, mais la plupart ne récompensent que le travail valide. L'environnement de 2026 exige l'inverse : le slop avéré et le spam écarté doivent *retirer* des points. Quand la réputation d'un soumetteur baisse, vous pouvez restreindre ses futures soumissions ou les déprioriser automatiquement. L'objectif est de faire en sorte que le slop coûte quelque chose, pour que ceux qui jouent sur le volume cessent d'y trouver leur compte.

### 4. Suivi des SLA qui protège le temps des relecteurs

Voici le lien que l'on oublie : le suivi des SLA ne sert pas seulement à être réactif. Il sert à ne pas perdre les bons chercheurs. Les vrais chercheurs passent en public quand les accusés de réception traînent, que les correctifs sortent en silence ou que la sévérité est discrètement minorée — exactement le mode de défaillance que nous avons couvert dans [quand les chercheurs passent en public](/blog/when-researchers-go-public-botched-disclosure). Sous la charge du slop, les délais d'accusé de réception sont les premiers à déraper, et c'est précisément le moment où vous pouvez le moins vous permettre d'aliéner les vrais rapporteurs noyés dans le bruit. Un chronomètre d'accusé de réception (par exemple 72 heures) plus des objectifs de résolution par niveau de sévérité maintiennent en coordination avec vous les personnes que vous tenez le plus à garder.

<div class="blog-inline-cta">
  <p><strong>Votre boîte VDP est en train de couler ?</strong> Le module CSIRT de Kit livre le premier filtrage IA, la limitation de débit à la réception, le karma de réputation, les chronomètres SLA et les primes à l'impact sous forme de configuration, pas d'un chantier de six mois.</p>
  <p><a href="/users/sign_up">Démarrez votre essai gratuit</a></p>
</div>

### 5. Primes à l'impact, pas au volume

Si votre prime paie par découverte acceptée quelle que soit la sévérité, vous payez les gens pour soumettre du volume — et l'IA s'en charge volontiers. Liez les paiements à une grille des primes par niveau de sévérité où les découvertes informatives paient **0 $** et où seul un impact réel paie un vrai montant. Associez-y une déduplication pour que mille occurrences d'un bug à cause racine unique se résolvent en un seul ticket et un seul paiement. C'est exactement le levier que curl a fini par actionner : supprimer l'incitation monétaire à soumettre de la camelote. Vous n'êtes pas obligé d'aller jusqu'à zéro comme curl, mais vous devez cesser de récompenser la quantité.

## Ne jetez pas les bons chercheurs assistés par IA

L'ennemi, c'est le *volume non validé*, pas l'IA. Cette distinction compte, car la réaction paresseuse — « interdire les rapports assistés par IA » — jetterait vos meilleurs contributeurs.

Le contre-exemple le plus net est Joshua Rogers, dont le travail assisté par IA a fait remonter une cinquantaine de bugs *réels* dans curl, chacun validé par un humain avant soumission. Le même outillage que les marchands de slop, le résultat opposé, parce qu'un humain compétent se tenait entre le modèle et le bouton « envoyer ». Stenberg a été explicite : la recherche responsable assistée par IA est la bienvenue ; c'est le tuyau d'arrosage de production non vérifiée qu'il ne peut pas soutenir.

Le rôle de la méthode est donc précis : filtrer sur les *preuves et la validité*, pas sur le *recours ou non à l'IA*. Un rapport avec une preuve de concept fonctionnelle et une vraie référence de code passe, qu'il ait été rédigé par un humain ou par un modèle. Un rapport avec des fonctions hallucinées et sans PoC échoue pour la même raison, quel qu'en soit l'auteur. Filtrez le signal, pas l'outil.

## Comment Kit met la méthode en pratique

Voici la vérité qui dérange pour toute équipe qui voudrait bâtir cela en interne : les cinq leviers ci-dessus représentent à peu près six mois d'outillage maison. La verticale `Csirt::` de Kit les implémente sous forme de configuration. La correspondance est presque univoque.

| Levier de la méthode | Fonctionnalité CSIRT de Kit | Ce que ça fait |
|---|---|---|
| **Premier triage assisté par IA** | `Csirt::AiScreening` | Le tri par LLM renvoie `pass` / `review` / `flag` selon la confiance, et détecte les signaux explicites de slop : fonctions hallucinées, CVE fabriqués, CVE ancien présenté comme nouveau, remédiation générique, absence de PoC précise, langage de modèle, étapes de reproduction floues, références à du code inexistant |
| **Limitation de débit / anti-spam** | `Csirt::SpamConfig` | Plafond glissant (par défaut 5 rapports par 5 minutes, puis blocage temporaire) avec blocage automatique en cas de récidive |
| **Réputation qui pénalise le slop** | `Csirt::KarmaEvent` | Le slop IA avéré coûte du karma au soumetteur ; le rejet pour spam et le « non applicable » en retirent aussi ; les résolutions valides et les primes en ajoutent, avec des bonus de sévérité |
| **Déduplication** | `Csirt::TriageConfig` | Déduplication activée par défaut, pour que des occurrences répétées d'une même cause racine ne deviennent pas cent tickets |
| **Suivi des SLA** | `Csirt::SlaConfig` | Chronomètre d'accusé de réception (72 h par défaut) plus objectifs de résolution par niveau de sévérité |
| **Primes à l'impact** | `Csirt::BountyMatrixConfig` | Tranches de paiement par niveau de sévérité ; l'informatif paie 0 $, jusqu'au critique |
| **Pilotage sous charge** | `Csirt::OnCallConfig` | Affectation automatique de l'astreinte pour que les accusés de réception ne dérapent pas quand la file s'emballe |
| **Moins de bruit hors périmètre** | `Csirt::ScopeConfig`, `Csirt::SecurityTxtConfig` | Périmètre et politique publics réduisent les soumissions invalides à la source |

Une précision sur le tri par IA : c'est un *triage assistif* — une recommandation assortie d'un score de confiance, pas un rejet automatique. Les humains tranchent toujours chaque `flag` et chaque `review`. Kit ne prétend pas bloquer tout le slop. Il filtre la première passe et redéfinit le prix des incitations pour que les heures de vos relecteurs aillent aux vrais bugs : un rapport façon Joshua Rogers avec un PoC fonctionnel passe sans encombre, tandis qu'un rapport halluciné se fait attraper.

## À retenir : un problème de slop est en réalité un problème de triage

Les programmes qui se sont éteints en 2026 n'ont pas été battus par l'IA. Ils ont été battus par un pipeline de réception conçu pour un monde du signal coûteux qui n'existe plus. Le slop n'est que du volume. La défaillance était structurelle : pas de première passe automatisée, pas de limitation de débit, pas de pénalité de réputation, et une prime qui payait la quantité.

Chacun de ces points est réparable, et chacun relève d'un réglage plutôt que d'un projet de recherche. Si vous montez un programme de zéro, commencez par [le guide de mise en place d'un VDP](/blog/how-to-set-up-vulnerability-disclosure-program). Si vous êtes déjà sous l'eau, le geste consiste à inverser l'économie : automatiser la première passe, freiner les déluges, faire en sorte que le slop coûte quelque chose, protéger le temps de vos relecteurs avec des SLA, et ne jamais payer que pour un impact réel. Gardez dehors les rapports qui ont tué curl, et dedans les rapports façon Joshua Rogers.

C'est exactement ce que le module CSIRT de Kit est conçu pour faire. [Démarrez un essai gratuit](/users/sign_up) et transformez une boîte de réception noyée en une file filtrée, plafonnée et adossée à des SLA.