Bug Bounty : Guide Complet pour Débutants (2026)

Qu'est-ce que le bug bounty ?

Qu'est-ce que le bug bounty ? Le bug bounty est la pratique consistant à trouver des vulnérabilités de sécurité dans les systèmes d'une entreprise et à les signaler via un programme de récompense officiel, en échange d'un paiement ou d'une reconnaissance. L'entreprise publie un périmètre de ce que vous êtes autorisé à tester, et paie selon la gravité de chaque bug confirmé.

Voyez cela comme du test d'intrusion légal et rémunéré au résultat. Un pentester traditionnel est engagé pour un tarif fixe afin de tester un ensemble de cibles convenu sur une ou deux semaines. Un chasseur de bugs teste les mêmes types de cibles, mais n'est payé que pour ce qu'il trouve, et peut chasser quand il le souhaite. L'échange, c'est la stabilité contre la liberté : pas de revenu garanti, pas d'horaires fixes, et aucun plafond sur ce qu'une seule excellente découverte peut rapporter.

Les entreprises lancent ces programmes parce que cela revient moins cher que l'alternative. Payer quelques milliers de dollars à un hacker pour une faille coûte bien moins qu'une fuite de données, et cela met des centaines de testeurs sur la cible au lieu d'un seul consultant. Les programmes sont coordonnés selon le modèle de divulgation responsable, où les chercheurs signalent en privé et l'entreprise corrige le problème avant qu'un détail public ne sorte.

Le bug bounty est l'un des moyens les plus courants de passer de l'apprentissage de la sécurité à une rémunération, aux côtés du parcours de carrière en test d'intrusion. Beaucoup de chasseurs font les deux, utilisant les primes pour garder leurs compétences affûtées entre les missions.

Comment fonctionnent les programmes de bug bounty

Chaque programme repose sur les mêmes quelques rouages. Comprenez ces cinq éléments et vous pourrez lire n'importe quelle page de programme en sachant exactement ce que vous avez le droit de faire et ce que cela paie.

Le périmètre (scope)

Le périmètre est la liste des actifs que vous êtes autorisé à tester, généralement des domaines précis, des applications mobiles ou des points de terminaison d'API. Tout ce qui n'est pas listé est hors périmètre, et le tester constitue un accès non autorisé, point final. Le périmètre précise aussi les techniques interdites, le plus souvent le scan automatisé qui martèle la cible, l'ingénierie sociale du personnel et les tests de déni de service. Lisez cette section deux fois avant de toucher à quoi que ce soit.

Gravité et barèmes de primes

La plupart des programmes évaluent les découvertes avec le Common Vulnerability Scoring System (CVSS), en les classant en faible, moyen, élevé ou critique. Chaque niveau correspond à une fourchette de paiement publiée sur la page du programme. Un bug critique d'exécution de code à distance sur une banque peut payer 20 000 dollars, tandis qu'un problème de faible gravité sur un sous-domaine marketing paie 50.

Le tri (triage)

Quand vous soumettez, un analyste de tri (souvent le personnel de la plateforme, pas l'entreprise) reproduit votre rapport et décide s'il est valide, un doublon ou hors périmètre. C'est le filtre par lequel passe chaque rapport, et un compte rendu clair et reproductible est ce qui vous fait passer rapidement.

Les doublons

Si quelqu'un a signalé le même bug avant vous, le vôtre est marqué comme doublon et ne paie rien. C'est la partie la plus frustrante de la chasse et la raison pour laquelle la rapidité et l'originalité comptent. Les programmes populaires reçoivent les bugs évidents dans les heures qui suivent leur lancement.

La divulgation

Après le déploiement d'un correctif, certains programmes vous autorisent à publier le rapport, ce qui construit votre réputation. D'autres gardent tout privé. Dans tous les cas, divulguer des détails avant que l'entreprise ne l'autorise enfreint les règles et peut vous faire bannir.

Combien gagnent réellement les chasseurs de bugs ?

Combien gagnent les chasseurs de bugs ? Les revenus vont de rien à six chiffres par an, et la plupart des chasseurs se situent près du bas de cette fourchette. Les paiements dépendent entièrement de la gravité de ce que vous trouvez et de la concurrence que vous devancez, si bien que le revenu est réel mais très irrégulier.

Les chiffres au niveau des plateformes sont réellement importants. HackerOne a rapporté que ses programmes ont versé environ 81 millions de dollars de primes sur les douze mois précédant la mi-2025, en hausse d'environ 13 pour cent sur un an, selon son bilan annuel de programme. Le programme de récompense des vulnérabilités de Google a versé près de 12 millions de dollars aux chercheurs rien qu'en 2024. L'argent dans le système n'est pas un mythe.

Le hic, c'est la répartition. Cette cagnotte est distribuée de façon très inégale, un petit groupe de chasseurs d'élite à plein temps en prenant une large part, tandis que la longue traîne des amateurs à temps partiel gagne des montants modestes ou rien un mois donné. Une première année réaliste pour un débutant assidu ressemble à une poignée de découvertes faibles à moyennes, pas à un salaire à plein temps.

Voici le cadrage honnête que je donne à quiconque débute : considérez votre première année comme une éducation rémunérée. Vous êtes récompensé, parfois, pour la pratique même qui vous rend employable en sécurité, que les primes deviennent ou non un jour votre revenu principal. Gardez un emploi ou des études en parallèle. Les chasseurs qui s'épuisent sont ceux qui parient l'argent du loyer sur l'apparition de failles critiques sans doublon à date fixe. Cela n'arrive pas.

Comment débuter en bug bounty : une feuille de route en 6 étapes

Le chemin de zéro à un rapport valide n'est pas compliqué, mais il est facile de sauter des étapes et de perdre des mois. Suivez cet ordre.

1. Apprenez comment fonctionne le web. Requêtes et réponses HTTP, cookies, en-têtes, codes de statut, et comment un navigateur communique avec un serveur. On ne peut pas trouver une faille dans un système qu'on ne comprend pas. Si les termes GET, POST et redirection 302 restent flous, commencez par là.
2. Choisissez une classe de vulnérabilité et apprenez-la à fond. N'essayez pas d'apprendre tous les types de bugs à la fois. Choisissez-en un qui paie bien et accessible aux débutants, comme le contrôle d'accès ou l'IDOR, et comprenez-le de bout en bout avant d'en ajouter un second.
3. Entraînez-vous sur des cibles sûres et volontairement vulnérables. Travaillez cette classe de bug sur des environnements de lab conçus pour être cassés, où il n'y a aucun risque légal ni doublon pour vous voler la découverte. C'est là que se fait le vrai apprentissage.
4. Montez votre boîte à outils. Un proxy d'interception est indispensable. Apprenez Burp Suite assez bien pour intercepter, modifier et rejouer des requêtes, car presque toute la chasse web passe par là.
5. Choisissez un programme accessible avec un large périmètre. Un périmètre plus vaste signifie plus de surface d'attaque et plus de bugs que la foule n'a pas déjà nettoyés. Lisez toute la page du programme, notez ce qui est interdit, et concentrez-vous sur un actif plutôt que de tout scanner.
6. Chassez étroit, rapportez propre. Testez votre unique classe de bug méthodiquement sur ce seul actif. Quand vous trouvez quelque chose, reproduisez-le deux fois, puis documentez-le clairement. Un bug valide bien documenté vaut mieux que cinquante soumissions à moitié testées qui finissent toutes fermées.

En pratique, la plupart des débutants qui réussissent passent bien plus de temps sur les étapes deux et trois qu'ils ne l'imaginent. Les personnes qui signalent un bug valide dès leur premier mois arrivent presque toujours déjà à l'aise avec une vulnérabilité, après des mois de pratique en lab. Il n'y a pas de raccourci pour éviter les répétitions.

Les vulnérabilités qui paient vraiment

Tous les bugs ne se valent pas, et les débutants perdent du temps à courir après des classes rares et difficiles à exploiter alors que les valeurs sûres sont plus accessibles. Voici les types de vulnérabilités qui reviennent le plus dans les primes de débutants, tous rattachés au Top 10 de l'OWASP.

Contrôle d'accès défaillant et IDOR

Le contrôle d'accès est la première catégorie du Top 10 de l'OWASP pour une bonne raison : il est partout et souvent trivial à tester. Une référence directe non sécurisée à un objet (IDOR) se produit quand vous modifiez un identifiant dans une requête, par exemple de /account/1023 à /account/1024, et que le serveur vous remet les données d'un autre sans vérifier si vous devriez les voir. Pas de code d'exploitation, juste une valeur que vous éditez. Notre guide sur le contrôle d'accès défaillant couvre l'approche de test complète.

Cross-Site Scripting (XSS)

Le XSS vous permet d'injecter du JavaScript qui s'exécute dans le navigateur d'un autre utilisateur, ce qui peut voler des sessions ou agir en son nom. C'est l'un des bugs web les plus signalés, car une entrée renvoyée sur une page sans encodage correct est extrêmement courante. Consultez notre tutoriel sur le cross-site scripting pour apprendre à le trouver et le confirmer.

Server-Side Request Forgery (SSRF)

Le SSRF trompe un serveur pour qu'il émette des requêtes en votre nom, atteignant souvent des systèmes internes qu'un utilisateur normal ne pourrait jamais toucher. Sur une infrastructure cloud, il peut exposer des points de terminaison de métadonnées contenant des identifiants, ce qui explique pourquoi il paie souvent en élevé ou critique. Le guide SSRF détaille les cibles internes qui valent la peine d'être atteintes.

Injection SQL

L'injection SQL est plus ancienne et mieux défendue qu'auparavant, mais elle refait surface sur des points de terminaison hérités et paie bien quand c'est le cas, car elle signifie souvent un accès direct à la base de données. Apprenez les schémas dans notre documentation sur l'injection SQL et pratiquez-les avant de chasser en réel.

Failles de logique métier

Ce sont les bugs que les scanners ne trouvent jamais : acheter un article à un prix négatif, sauter une étape de paiement, ou appliquer un coupon mille fois. Ils exigent de comprendre ce que l'application est censée faire, puis de briser cette intention. Ils sont plus difficiles à repérer mais rarement en doublon, ce qui en fait certaines des découvertes les plus rentables pour un chasseur patient.

Méthodologie de bug bounty : de la reconnaissance au rapport

Une méthodologie n'est qu'un processus répétable pour ne pas tester les cibles au hasard. La plupart des chasseurs suivent une version de cette boucle.

Reconnaissance

La reconnaissance consiste à cartographier la surface d'attaque de la cible avant de tester quoi que ce soit. Pour un programme à large périmètre, cela signifie énumérer les sous-domaines, découvrir les points de terminaison et cataloguer chaque entrée que l'application accepte. Plus vous cartographiez de surface, plus un bug a d'endroits où se cacher. Les outils de découverte de répertoires et de contenu aident à faire ressortir des pages que le site ne relie jamais.

Analyse de vulnérabilité

Une fois la carte en main, vous cherchez la classe de bug précise sur laquelle vous vous êtes entraîné. C'est là que vous envoyez des requêtes forgées via votre proxy, observez comment l'application répond, et repérez les petits écarts qui trahissent une faille. La discipline ici, c'est de tester une hypothèse à la fois plutôt que de balancer des payloads à l'aveugle.

Exploitation et impact

Trouver un comportement étrange ne suffit pas. Vous devez prouver un impact réel. Une valeur reflétée est intéressante ; un payload fonctionnel qui vole un cookie de session est un rapport payé. Les équipes de tri récompensent l'impact démontré, alors construisez la preuve de concept la plus propre possible qui montre ce qu'un attaquant pourrait réellement faire.

En testant de vrais programmes, résistez à l'envie d'aller au-delà de ce qui prouve le point. Lire l'enregistrement d'un seul autre utilisateur prouve un IDOR. Vider dix mille enregistrements pour faire peur est la manière de vous faire retirer d'un programme et, selon les données, de franchir une ligne légale. Prouvez l'impact, puis arrêtez.

Meilleures plateformes de bug bounty en 2026

Presque tous les programmes sont hébergés sur une poignée de plateformes qui gèrent le périmètre, les soumissions, le tri et le paiement. Voici par où les débutants commencent réellement, avec une note honnête sur chacune.

Mon conseil direct : commencez sur HackerOne ou Bugcrowd. Ce sont eux qui ont le plus de programmes, l'accueil le plus clair, et le plus grand vivier de cibles à large périmètre où un débutant peut encore trouver ce que la foule a manqué. Viser un critique sur le VRP de Google comme toute première cible est le chemin le plus rapide vers le découragement. Construisez d'abord des victoires sur des programmes accessibles.

Comment rédiger un rapport de bug bounty qui paie

Comment rédiger un bon rapport de bug bounty ? Un bon rapport permet à un analyste de tri de reproduire votre bug en moins de cinq minutes sans vous poser une seule question. Il énonce la vulnérabilité, son impact et les étapes exactes de reproduction en langage clair, appuyé par des preuves. C'est la clarté, pas la longueur, qui vous fait payer.

Les rapports faibles sont la raison la plus courante pour laquelle des bugs valides paient moins qu'ils ne le devraient, ou finissent fermés. Un bon rapport a une forme prévisible :

• Titre. Une ligne nommant le bug et son emplacement, comme « IDOR sur le point de terminaison de facture exposant les données de facturation d'autres utilisateurs ».
• Résumé. Deux ou trois phrases sur la nature de la faille et pourquoi elle compte.
• Étapes de reproduction. Une liste numérotée qu'un inconnu peut suivre exactement, incluant la requête, le paramètre que vous avez modifié, et le résultat attendu par rapport au résultat obtenu.
• Impact. Ce qu'un attaquant obtient en termes concrets, lié à de vraies données ou actions, pas un vague « c'est dangereux ».
• Preuves. Captures d'écran, la requête et la réponse brutes, ou une courte vidéo. Montrez le bug, ne vous contentez pas de le décrire.

Rédigez la section impact pour un non-hacker. La personne qui décide de votre paiement peut être un chef de produit qui doit saisir le risque métier en une lecture. « Un attaquant peut consulter et modifier la carte bancaire enregistrée de n'importe quel client » frappe plus fort qu'un mur de jargon technique. Notre cours Bug Bounty Fundamentals inclut un chapitre complet sur le reporting, avec de vrais exemples de rapports ayant passé le tri sans accroc.

Erreurs fréquentes des débutants

La plupart des gens qui abandonnent tôt la chasse aux bugs font les mêmes erreurs évitables. Évitez-les et vous êtes déjà devant la majorité.

• Tester hors périmètre. Le moyen le plus rapide de se faire bannir et, au pire, d'être signalé aux autorités. Lisez le périmètre, respectez-le exactement.
• Tout apprendre, ne rien maîtriser. Sauter entre dix types de bugs signifie que vous êtes faible partout. La profondeur dans une classe vaut mieux qu'une familiarité superficielle avec toutes.
• Se reposer sur les scanners automatisés. Tout le monde utilise les mêmes outils, donc les bugs qu'ils trouvent sont déjà signalés. Votre avantage, c'est le test manuel et la compréhension, pas un scanner que tous les autres possèdent aussi.
• Sauter les labs d'entraînement. Chasser en réel avant de savoir trouver un bug de manière fiable dans un lab fait perdre des mois sur des programmes où vous ne reconnaîtriez pas une faille sous vos yeux.
• Abandonner après des doublons. Que vos premières découvertes valides soient des doublons est normal, pas un signe que vous êtes mauvais. Cela veut dire que vous cherchez au bon endroit, juste pas encore assez vite. Continuez.

Considérations légales et éthiques

Tout le modèle repose sur le fait de rester dans le périmètre autorisé et de suivre la divulgation responsable. Signalez en privé, n'extrayez jamais plus de données que nécessaire pour prouver l'impact, et ne divulguez jamais de détails publiquement avant que le programme ne l'autorise. Franchissez l'une de ces lignes et un programme de récompense légal devient un délit informatique.

Il existe exactement trois endroits pour pratiquer ces techniques légalement : les programmes de bug bounty dans leur périmètre publié, les missions rémunérées sous contrat signé, et les plateformes de lab isolées conçues pour être attaquées. Les labs de défis HackerDNA relèvent de la troisième catégorie, vous offrant de vraies cibles vulnérables sans aucun risque légal pendant que vous développez les compétences pour les deux premières.