Teknik - L’arrivée de l’IA dans le Bug Bounty - Parce que... c'est l'épisode 0x353!

• 13 et 14 novembre 2026 - Worldwide - DEATHCon
• 16 au 19 novembre - Rennes, France - European Cyber Week 2026
• 25 et 26 février 2027 - Québec, Canada - SéQCure 2027
• 9 au 11 mars 2027 - Lilles, France - Forum INCYBER - Europe 2027
• I.A. Café - Enquête au cœur de la recherche sur l’intelligence artificielle
• 16 novembre 2026 - Paris, France - CNIL - Convaincre ou manipuler ? L'éthique du numérique à l'épreuve des urnes
• Boostsecurity - Dazio
• 13 au 16 octobre 2026 - Montréal, Canada - MTL Connecte
• 5 novembre 2026 - Montréal, Canada - CISO Open Mic Montréal 2026

Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.

Le bug bounty et son fonctionnement

Adrien Jeanneau, responsable de l’équipe triage chez YesWeHack depuis presque cinq ans, présente dans cet épisode technique du Polysecure le fonctionnement du bug bounty et l’impact de l’intelligence artificielle sur cet écosystème. Le principe du bug bounty consiste à cadrer la recherche et la remontée de vulnérabilités au travers d’un programme établi par un client qui passe par YesWeHack comme intermédiaire. Ce programme se décompose en plusieurs éléments, dont les règles classiques précisant ce qui est autorisé ou non, la définition du scope qui peut couvrir des applications mobiles, web, des binaires, du code open source, voire des agents IA ou des serveurs type MCP, ainsi que des règles qualifiantes et non qualifiantes. Puisque le modèle repose sur la rémunération des chercheurs à l’impact, une vulnérabilité de sévérité faible rapporte moins qu’une vulnérabilité critique.

L’arrivée de l’IA chez les chercheurs

L’équipe triage analyse les rapports de vulnérabilité qui arrivent sur les programmes afin de confirmer leur sévérité et le respect des règles de chaque programme. Depuis environ un an, l’IA a bouleversé ce flux de travail. Les chercheurs, souvent en avance sur ces sujets, ont rapidement intégré l’IA dans leur processus d’analyse, d’abord surtout sur du code source puisque les modèles étaient moins habiles pour naviguer sur des applications web. Cette évolution a provoqué une montée en puissance du nombre de rapports arrivant dans les mains de l’équipe triage. Le problème principal est que les chercheurs ne vérifient pas ce que l’IA rédige. Si on demande à un modèle de trouver une vulnérabilité, elle en trouvera potentiellement une, mais sans vérification humaine, celle-ci peut être inexploitable ou totalement hallucinée.

Les mesures mises en place par la plateforme

Pour faire face à cette vague, YesWeHack a déployé plusieurs dispositifs. D’abord, des rappels répétés des règles aux chercheurs, leur rappelant que seules des vulnérabilités qualifiantes donnent droit à une récompense. Ensuite, une règle limitant le nombre de soumissions simultanées pour les nouveaux chercheurs. Un chercheur qui soumet d’un coup quinze ou vingt rapports sur un programme open source, ce qui est historiquement difficile à réaliser, est très probablement en train d’envoyer des rapports invalides. Une fois les rapports validés ou rejetés, un nouveau ratio se débloque et augmente progressivement à mesure que le chercheur soumet des rapports valides.

Plus récemment, la plateforme a mis en place un système de crédits. Un chercheur débutant reçoit dix crédits, et chaque soumission coûte entre un crédit et beaucoup plus selon les types de programmes. Si le rapport est accepté, les crédits engagés sont remboursés et le chercheur en gagne de nouveaux, ce qui lui permet de soumettre davantage de rapports. À l’inverse, si le r