Bug bounty : définition, plateformes, et quand il a
du sens

L'argument fait mouche en réunion de direction : « Des milliers de hackers éthiques testent nos applications en permanence, et on ne paie que s'ils trouvent quelque chose. » Formulé comme ça, le bug bounty ressemble au meilleur rapport qualité-prix de la cybersécurité : une armée de chercheurs, en continu, à la performance. La réalité est plus nuancée — et pour une PME ou une ETI qui n'a jamais fait tester son périmètre, ouvrir un programme trop tôt revient à payer au prix fort, faille par faille, ce qu'un test de dix jours aurait listé d'un coup.

Cet article pose une définition honnête du bug bounty, explique concrètement comment fonctionne un programme (scope, barème de récompenses, triage), passe en revue les vraies plateformes — dont la française YesWeHack —, détaille sa différence de fond avec un pentest, et surtout : à quel moment il a du sens pour vous, et à quel moment c'est prématuré. Sans langue de bois sur ce dernier point.

Bug bounty : la définition sans le marketing

Un bug bounty (littéralement « prime au bug ») est un programme par lequel une organisation invite des chercheurs en sécurité indépendants à trouver des vulnérabilités sur un périmètre défini, et les rémunère au résultat : une prime par faille valide, dont le montant dépend de la criticité. Pas de faille remontée, pas de facture. C'est ce modèle économique qui distingue radicalement le bug bounty de tout le reste : un pentest se paie au jour, un scanner à l'abonnement ; un bug bounty, lui, se paie à la découverte.

Trois ingrédients font un programme. Une foule (la crowd) de chercheurs aux compétences et aux fuseaux horaires variés, qui regardent votre surface sous des angles qu'une seule équipe n'aurait pas. La continuité : le programme reste ouvert, donc chaque déploiement, chaque nouvelle fonctionnalité peut être testée dans la foulée, là où un pentest est une photo à un instant T. Et une plateforme qui sert d'intermédiaire de confiance entre vous et les chercheurs — c'est elle qui héberge le programme, gère les paiements, et souvent trie les rapports. On y revient.

Comment fonctionne un programme de bug bounty

De l'extérieur, on ne voit que la prime. Derrière, il y a un cycle précis, et c'est sa partie invisible — le triage — qui fait ou défait un programme. Voici le chemin que parcourt un rapport, du chercheur jusqu'au virement.

Le scope est le document le plus important du programme. Il liste les domaines, applications et API que vous acceptez de faire tester, ceux que vous excluez explicitement, et les catégories de failles qui vous intéressent (ou pas). Un scope trop étroit décourage les chercheurs ; un scope trop large expose des systèmes que vous n'étiez pas prêt à ouvrir. C'est un arbitrage, et il se révise au fil du temps.

Le barème de récompenses fixe le prix de chaque niveau de criticité. Chez les grands programmes, l'échelle va de quelques centaines d'euros pour une faille mineure à plusieurs dizaines de milliers pour une compromission critique (une RCE, une prise de contrôle de compte généralisée). Point contre-intuitif : le montant dépend de la gravité de la faille, pas de ce que sa correction vous coûte en interne. Un chercheur qui trouve une faille critique en dix minutes touche le tarif critique.

Reste le triage, le nerf de la guerre. Un programme un peu visible reçoit un flux continu de rapports, dont beaucoup de doublons (plusieurs chercheurs trouvent la même chose), de hors-scope, et de faux positifs. Chaque rapport doit être lu, reproduit, qualifié et — s'il est valide — payé dans des délais décents. Sans cette capacité, deux choses arrivent : vous vous noyez, et votre réputation sur la plateforme s'effondre (les chercheurs se parlent, et un programme qui paie mal ou lentement se vide). Beaucoup de plateformes proposent justement un triage managé : leurs analystes filtrent avant que le rapport n'atterrisse chez vous. C'est un service payant, et souvent indispensable.

Les plateformes de bug bounty

On ne lance quasiment jamais un programme « en direct » : on passe par une plateforme de bug bounty, qui apporte la communauté de chercheurs, l'infrastructure de soumission, la gestion des paiements (y compris fiscale, à l'international) et, en option, le triage. Le marché est concentré autour de quelques acteurs.

• YesWeHack — la plateforme française, basée à Paris, leader européen. C'est le choix naturel pour une organisation soumise au RGPD ou à des exigences de souveraineté : opérations en Europe, communauté large, et des programmes du secteur public et régulé qui préfèrent un acteur européen. Elle propose aussi un « Dojo » de montée en compétences pour les chercheurs. Pour une PME/ETI hexagonale, c'est souvent le point de départ le plus cohérent.
• HackerOne — l'acteur américain historique, avec la plus grande communauté de chercheurs. Idéal pour la visibilité et le volume, un peu moins pour qui tient à des données hébergées en Europe.
• Bugcrowd — l'autre grand américain, réputé pour son triage managé pris en main de bout en bout, utile quand vous n'avez pas d'équipe dédiée en interne.
• Intigriti — plateforme européenne (belge), très présente sur les programmes orientés conformité et données résidentes dans l'UE. Une bonne alternative continentale à YesWeHack.

Il existe aussi des acteurs plus spécialisés — Synack pour les contextes très régulés et gouvernementaux, Immunefi pour le Web3 et les smart contracts, ou l'autre français Yogosha — mais pour la grande majorité des PME et ETI, le choix se joue entre les quatre ci-dessus, et le réflexe souverain penche vers YesWeHack ou Intigriti.

Sur chacune de ces plateformes, un programme se décline en trois modes : public (ouvert à tous, visibilité maximale mais flux de rapports maximal aussi), privé (sur invitation, un panel restreint de chercheurs sélectionnés, moins de bruit et une meilleure qualité moyenne), et la VDP déjà évoquée. On verra que ce choix public/privé est central pour ne pas se faire submerger.

Bug bounty vs pentest : la différence de fond

C'est la comparaison qui revient le plus, et elle est souvent mal posée, comme s'il fallait choisir un camp. Les deux répondent à des questions différentes. Le plus simple est de les regarder selon quatre axes.

La distinction décisive est la garantie de couverture. Un test d'intrusion web vous engage sur un périmètre et une méthode : à la fin, le pentester vous remet un rapport qui dit ce qui a été testé, comment, et ce qui a été trouvé — y compris quand il n'a rien trouvé sur telle zone. Le bug bounty, lui, ne garantit rien de tel : les chercheurs vont où bon leur semble, et une partie de votre périmètre peut ne jamais être regardée parce qu'elle est jugée peu rentable. Le bug bounty excelle en profondeur et en continuité ; le pentest excelle en exhaustivité et en reddition de comptes. Ce ne sont pas les mêmes besoins.

Si vous voulez situer ces deux formats dans l'ensemble du spectre offensif — scan automatisé, EASM, pentest continu, jusqu'à la red team — on l'a cartographié dans red team vs pentest, qui replace chaque exercice selon votre maturité. Et pour la frontière plus fine entre test humain et outil automatique, voyez pentest, scan de vulnérabilité ou EASM.

Quand un bug bounty a du sens (et quand c'est prématuré)

Voici la partie qu'un vendeur de plateforme ne vous dira pas aussi franchement. Le bug bounty est un excellent outil — au bon moment. Ouvert trop tôt, il devient un gouffre à budget et à temps. La raison est mécanique : sur une application jamais testée, les failles « faciles » (les low-hanging fruits) sont nombreuses et visibles. Vous allez donc recevoir une avalanche de rapports pour des vulnérabilités qu'un pentest de dix jours aurait toutes listées d'un coup, pour un prix fixe — sauf qu'ici vous les payez une par une, au tarif du barème, plus le temps de triage de chacune.

L'ordre raisonnable tient en trois temps. D'abord, un pentest sur vos actifs critiques pour éliminer l'évident et obtenir une base saine — c'est l'étape qui rend tout le reste rentable. Ensuite, la correction et un retest pour vérifier que les failles sont bien fermées. Enfin seulement, l'ouverture d'un programme de bug bounty — idéalement privé au départ, sur invitation d'un panel restreint, pour maîtriser le flux avant d'envisager le public. Ce séquencement transforme le bug bounty en ce qu'il fait de mieux : trouver les failles profondes, celles qu'une mission ponctuelle n'a pas eu le temps d'atteindre, et le faire en continu au fil de vos déploiements.

Un préalable organisationnel, aussi : pour accueillir un programme, il faut une capacité de réponse aux incidents, une politique de safe harbor (l'engagement de ne pas poursuivre un chercheur de bonne foi), et surtout la ressource humaine pour trier. Si vous n'avez ni l'un ni l'autre, commencez par une VDP — gratuite, sans prime — le temps de bâtir le muscle interne.

Combien ça coûte vraiment

« On ne paie que si ça marche » est vrai pour les primes, et trompeur pour le budget total. Un programme de bug bounty a trois postes de coût, et les primes ne sont que le plus visible.

• Les primes. Variables par nature. Un barème sérieux démarre à quelques centaines d'euros pour du mineur et grimpe à plusieurs milliers, voire dizaines de milliers, pour du critique. Sur un périmètre non durci, ce poste explose au démarrage ; sur un périmètre mûr, il se lisse et devient prévisible.
• Les frais de plateforme. Abonnement annuel et, si vous le prenez, le triage managé. C'est un coût fixe, qui existe même les mois où aucune faille n'est remontée. Les plateformes européennes affichent souvent des frais plus contenus que les américaines à périmètre comparable.
• Le coût interne de triage et de correction. Le plus sous-estimé. Chaque rapport mobilise du temps d'ingénieur pour être reproduit, qualifié, corrigé et re-testé. Multipliez par le volume d'un programme public mal cadré, et ce poste dépasse vite les primes elles-mêmes.

À comparer avec un pentest, dont le prix est connu d'avance : un TJM multiplié par un nombre de jours, sans surprise. On a décortiqué ces montants dans combien coûte un test d'intrusion web. Le bug bounty et le pentest ne s'opposent pas sur le prix : ils achètent des choses différentes. Le pentest achète une couverture garantie à coût fixe ; le bug bounty achète de la profondeur continue à coût variable.

Articuler bug bounty, pentest et EASM

Aucun de ces formats ne remplace les autres : ils s'empilent. Avant même de parler de tests, il faut savoir ce qu'on expose — et c'est le rôle de l'EASM (External Attack Surface Management), qui cartographie en continu votre surface d'attaque externe, y compris les sous-domaines et services oubliés. Définir un scope de bug bounty sans cette vision, c'est risquer d'ouvrir un programme sur une partie seulement de ce que vous exposez réellement.

L'articulation qui fonctionne pour une PME ou une ETI ressemble à ceci : un EASM pour la visibilité permanente, un pentest pour durcir en profondeur les actifs critiques et prouver l'exploitable, puis — une fois le périmètre assaini et l'équipe capable de trier — un bug bounty privé pour la continuité et la profondeur au fil des déploiements. Le déroulé concret d'une mission, du cadrage au retest, est détaillé dans comment se déroule un test d'intrusion, et le vocabulaire complet du domaine attend dans le glossaire de la cybersécurité offensive.

À retenir

• Un bug bounty rémunère des chercheurs indépendants au résultat, en continu, via une plateforme : c'est son modèle économique qui le distingue de tout le reste.
• Un programme repose sur trois choses : un scope clair, un barème de primes par criticité, et une vraie capacité de triage — cette dernière est le nerf de la guerre.
• Les plateformes qui comptent : YesWeHack (française, leader européen), HackerOne, Bugcrowd, Intigriti. Réflexe souverain : YesWeHack ou Intigriti.
• Bug bounty vs pentest : continu / foule / au résultat / sans garantie de couverture, contre cadré / expert dédié / à l'effort / exhaustif. Complémentaires, pas concurrents.
• N'ouvrez pas trop tôt. Sans pentest préalable, un bug bounty public vous submerge de rapports sur du low-hanging fruit. L'ordre : pentest, correction, retest, puis bug bounty (privé d'abord).

Vous envisagez un bug bounty ? La meilleure façon de ne pas gaspiller votre budget, c'est d'arriver avec un périmètre déjà durci. Chez own2pwn, on mène les pentests web blackbox (retest inclus) qui éliminent l'évident avant que vous n'ouvriez un programme, et notre plateforme EASM vous donne la vue complète de ce que vous exposez — de quoi définir un scope qui tient la route. Pas sûr du bon ordre pour votre contexte ? Écrivez-nous, on vous dira franchement par où commencer.