Bug bounty ou test d'intrusion (pentest) : lequel faire en premier ?

Vous avez le budget pour un seul effort sérieux de sécurité offensive cette année, et deux camps bruyants pour vous dire quoi acheter. Le premier affirme que le test d'intrusion est le socle professionnel incontournable. Le second jure que le bug bounty est la façon moderne de trouver de vraies vulnérabilités. Les deux ont partiellement raison, les deux se trompent pour beaucoup d'équipes, et l'ordre que vous choisissez compte davantage que le choix lui-même.

Deux modèles, deux mécaniques

Retirez la couche marketing et il reste deux machines totalement différentes. C'est en les confondant que des équipes finissent par payer, au tarif du triage de bounty, des failles qu'un pentester junior aurait relevées dès le premier jour.

Ce qu'est réellement un test d'intrusion

Un pentest est une prestation cadrée et bornée dans le temps. Une petite équipe (souvent un ou deux testeurs) attaque une cible définie pendant une fenêtre définie, en général une à trois semaines, en suivant une méthodologie comme PTES ou le guide OWASP Web Security Testing Guide. Vous obtenez :

• Un périmètre défini : des hôtes précis, des applications, des API, des plages IP, parfois un compte cloud ou un segment de réseau interne.
• Une couverture méthodique : reconnaissance, cartographie, tests d'authentification et de session, contrôles d'autorisation sur chaque rôle, classes d'injection, abus de logique métier, puis exploitation et post-exploitation dans le cadre de règles d'engagement convenues.
• Un rapport avec étapes de reproduction, cotation de sévérité (généralement CVSS, complétée d'un jugement contextuel) et recommandations de remédiation.
• Une fenêtre de contre-test pendant laquelle les correctifs sont vérifiés.

La propriété décisive : la couverture est systématique. Un testeur compétent parcourt toute la surface d'attaque du périmètre, y compris les recoins ingrats que personne n'irait chasser pour de l'argent. Il testera chaque rôle contre chaque endpoint à la recherche de défauts d'autorisation, cette classe de bugs que nous détaillons dans notre guide sur la sécurité des API, parce que la méthodologie l'exige, pas parce que cela rapporte.

Ce qu'est réellement un bug bounty

Un bounty est une offre permanente : un périmètre publié, une grille de récompenses et des règles, hébergés sur une plateforme comme YesWeHack, Intigriti, HackerOne ou Bugcrowd, ou gérés en direct. Des centaines ou des milliers de chercheurs indépendants peuvent examiner vos actifs quand bon leur semble. Vous payez par vulnérabilité acceptée, unique et dans le périmètre.

La propriété décisive : la couverture est économique, pas systématique. Les chercheurs vont là où sont l'argent et les probabilités. Les cibles populaires se font pilonner sur quelques classes bien payées (chaînes de prise de contrôle de compte, SSRF vers les métadonnées cloud, IDOR sur des objets sensibles) pendant que des sous-systèmes entiers restent intouchés des mois durant parce qu'ils semblent peu rentables. Personne ne vous doit de couverture. Personne ne signe de cahier des charges.

Ce que chaque modèle sait vraiment faire

Le pentest gagne quand il vous faut

• De l'assurance et des preuves. Les auditeurs, les grands comptes et les référentiels comme ISO 27001 ou SOC 2 veulent un rapport signé par un cabinet identifié avec une méthodologie. C'est aussi la pièce qui documente vos mesures de sécurité au titre de l'article 32 du RGPD et qui répond aux questionnaires de due diligence de vos clients européens. Un programme de bounty ne coche aucune de ces cases. Si la conformité est votre moteur, commencez par ce que SOC 2 exige réellement.
• Une couverture des surfaces sans gloire. Réseaux internes, clients lourds, ce panneau d'administration derrière le VPN, un Active Directory mal configuré. Les chercheurs n'y ont pas accès et, pour la plupart, ne s'y intéresseraient pas.
• De la profondeur sur la logique métier. Un testeur qui passe trois jours à comprendre votre flux de facturation trouvera le bug du remboursement à quantité négative. Un chercheur de passage, rarement.
• Une facture prévisible. Forfait fixe, dates connues, livrable connu.

Le bounty gagne quand il vous faut

• Une pression continue. Vous déployez tous les jours. Un pentest est une photographie ; votre surface d'attaque est un film. Un bounty signifie que chaque mise en production est potentiellement observée.
• Une diversité de techniques. Mille chercheurs apportent mille outillages, des parcs d'appareils improbables, des bizarreries de navigateurs obscures et des chaînes d'exploitation inédites qu'aucun cabinet ne maintient en interne.
• Un signal réaliste sur votre exposition externe. Les remontées de bounty vous montrent ce que voit un attaquant opportuniste réel, parce que les chercheurs se comportent comme lui, le délit en moins.
• Un coût marginal indexé sur les vrais bugs. Pas de remontée valide, dépense minimale au-delà des frais de plateforme et de votre propre temps de triage.

Où chaque modèle échoue

C'est la partie que les vendeurs passent sous silence.

Modes d'échec du pentest

• Le testeur à checklist. Certains cabinets lancent des scanners automatisés, remettent en forme la sortie et facturent au tarif du conseil. Exigez des exemples de rapports, les noms et certifications des testeurs (OSCP, OSWE, ou un historique de CVE et de recherches publiées ; en France, la qualification PASSI de l'ANSSI est un signal utile), et la part de travail manuel par rapport à l'outillage.
• L'obsolescence de l'instantané. Le rapport est exact pour le commit qui a été testé. Deux sprints plus tard, la moitié décrit une autre application.
• Le théâtre de périmètre. Tester uniquement le site vitrine pendant que l'API du produit reste hors périmètre produit un rapport propre et zéro sécurité.
• La troncature par la fenêtre de temps. Les bugs difficiles demandent plus que la durée de la mission. Une fenêtre de deux semaines peut se refermer exactement au moment où la chaîne intéressante devenait exploitable.

Modes d'échec du bounty

• L'effondrement du rapport signal sur bruit. Un programme mal préparé se fait ensevelir : doublons, remontées hors périmètre, spam de scanners et mendicité de primes (le fameux « votre enregistrement SPF est manquant, payez-moi »). D'expérience, les équipes sous-estiment la charge de triage d'un facteur considérable.
• Payer sa dette connue au prix fort. Si vous lancez un bounty sur une application jamais testée, vous paierez au prix du marché public, remontée par remontée, des bugs qu'un seul pentest aurait énumérés en bloc pour un forfait.
• La confiance des chercheurs est fragile. Réponses lentes, sévérités dégradées et doublons impayés finissent en captures d'écran partagées. Un programme à mauvaise réputation attire des chercheurs faibles et des trouvailles pires encore.
• Une exposition juridique si les règles sont bâclées. Sans safe harbor clair ni périmètre explicite, vous invitez des tests que vous n'avez pas autorisés sur des systèmes que vous ne comptiez pas exposer. Rappel utile : en France, l'accès non autorisé à un système reste un délit pénal, et la Belgique n'a encadré le hacking éthique que sous conditions strictes. Le cadre écrit protège tout le monde, vous compris.

La question de maturité que personne ne pose

La vraie variable de décision n'est pas le budget. C'est la capacité de votre organisation à absorber un flux de signalements externes non vérifiés.

Un programme de bounty est une boîte de réception qui se déclenche à des heures imprévisibles, avec des affirmations de qualité variable, dont certaines critiques, et qui ne ferme jamais. Pour en gérer un, il vous faut au minimum :

• Un responsable nommé pour le triage, avec un vrai contexte d'ingénierie, pas un simple aiguilleur de tickets.
• Une grille de sévérité convenue à l'avance, pour que les discussions de primes ne se transforment pas en débats de politique à chaque remontée.
• Un SLA de remédiation par niveau de sévérité, parce qu'une critique payée mais non corrigée est le pire des mondes, surtout quand son exploitation réelle vous imposerait une notification de violation à la CNIL sous 72 heures.
• Un canal de réception qui fonctionne vraiment, à commencer par un security.txt :

# https://yourdomain.com/.well-known/security.txt
Contact: mailto:security@yourdomain.com
Policy: https://yourdomain.com/security/policy
Preferred-Languages: en, fr
Expires: 2027-06-01T00:00:00.000Z

Si la lecture de cette liste a fait grimacer quelqu'un dans votre équipe, vous n'êtes pas prêts pour un bounty public. C'est normal. La plupart des entreprises ne le sont pas, et le remède est le séquencement, pas l'abstinence.

La mécanique des coûts, honnêtement

Les chiffres varient fortement selon la région, le périmètre et le cabinet (comptez des écarts sensibles entre Paris, Bruxelles, Genève et Tunis), donc prenez ceci comme des ordres de grandeur, pas comme des devis :

• Un pentest applicatif web de qualité se facture généralement au forfait, de quelques milliers à plusieurs dizaines de milliers d'euros pour une à trois semaines d'effort, le coût variant avec la complexité du périmètre, pas avec le nombre de trouvailles.
• Un programme de bounty coûte des frais de plateforme plus des primes. Les récompenses individuelles vont couramment de quelques centaines d'euros pour des failles mineures valides à des montants à cinq chiffres pour des critiques sur les programmes matures. Le coût caché est le temps d'ingénierie : triage, reproduction, arbitrage des doublons et correction sous SLA.

C'est l'arithmétique de l'échec qui compte. Lancez un bounty sur un logiciel non durci et vous convertissez le coût fixe et borné d'un pentest en un flux illimité de primes au bug, assorti d'un risque réputationnel. Ne faites que des pentests annuels sur un produit qui livre vite et vous convertissez une exposition continue en une photographie annuelle. La faiblesse de chaque modèle est la force de l'autre, et c'est précisément tout le sujet.

Le cadre de décision

Déroulez cette liste dans l'ordre et arrêtez-vous à la première réponse.

1. Jamais eu de test offensif professionnel ? Pentest d'abord. Sans exception. Ne payez pas au détail, bug par bug, des trouvailles qu'une couverture systématique livre en gros. Commencez par comment se déroule un vrai pentest de bout en bout.
2. Exigence de conformité ou d'un client dans les deux prochains trimestres (ISO 27001, SOC 2, NIS2, questionnaire fournisseur) ? Pentest d'abord. C'est l'artefact que le processus réclame.
3. Surface critique inaccessible depuis Internet ? Pentest (en version interne ou assumed-breach). Les bounties ne peuvent pas la voir.
4. Pentests annuels qui reviennent presque propres, livraisons hebdomadaires, aucun test continu ? Ajoutez un programme de divulgation coordonnée (VDP) maintenant, un bounty privé payant ensuite.
5. VDP qui tourne sans heurts, triage sous contrôle, critiques corrigées dans le SLA ? Passez à un bounty privé avec 20 à 50 chercheurs invités.
6. Bounty privé stable depuis au moins deux trimestres, taux de doublons en baisse, primes prévisibles ? Envisagez le passage en public.
7. Déjà public ? Conservez malgré tout des pentests annuels ou par version majeure, ciblés sur ce que les bounties ratent structurellement : nouvelles fonctionnalités avant lancement, systèmes internes, configuration cloud et parcours à forte logique métier.

Réussir son premier pentest

Un pentest vaut ce que vaut son cadrage. Exigez :

• Un périmètre sur les joyaux de la couronne, pas sur la plaquette. L'application produit, les API, les flux d'authentification et le compte cloud avant le site vitrine.
• Des identifiants pour chaque rôle. Un test uniquement non authentifié rate les bugs d'autorisation qui dominent les vraies compromissions. Fournissez des comptes de test par niveau de privilège.
• Le grey-box plutôt que le black-box pour les premières missions. Partager la documentation d'architecture, voire le code source, démultiplie ce qu'un testeur sous contrainte de temps peut atteindre. Vous achetez des trouvailles, pas un jeu de rôle réaliste.
• Un contre-test inscrit au contrat. Un rapport sans correctifs vérifiés est un document à charge.
• Des trouvailles routées dans votre chaîne de production, pas dans un cimetière de PDF. Chaque constat doit devenir un ticket, et les classes récurrentes doivent devenir des contrôles automatisés en CI, exactement la boucle que nous décrivons dans construire un pipeline DevSecOps.

Réussir son premier bounty

Démarrez en privé, démarrez étroit, et rédigez le périmètre comme une règle de pare-feu : autorisation explicite, refus par défaut.

## In scope
- app.example.com (production web app)
- api.example.com/v2/* (public API)

## Out of scope
- *.staging.example.com
- Denial of service, rate limit reports
- Findings requiring physical access or social engineering
- Third-party services (report to the vendor)

## Rewards (guideline)
- Critical: $3,000 to $8,000
- High: $1,000 to $3,000
- Medium: $250 to $1,000
- Low: $0 to $250, at our discretion

Puis tenez la ligne opérationnelle :

• Accusez réception vite, idéalement sous deux jours ouvrés. Les chercheurs pardonnent plus volontiers une prime lente qu'un silence.
• Payez au triage, pas à la correction. Faire attendre un chercheur au rythme de votre planification de sprint, c'est ainsi que meurent les programmes.
• Publiez une déclaration de safe harbor pour que la recherche de bonne foi soit explicitement autorisée.
• Suivez le taux de doublons et le délai de triage comme des métriques de premier rang. Des doublons en hausse signifient que vos correctifs n'atterrissent pas ou que votre périmètre est périmé.

La vraie réponse : séquencer, puis mener les deux

« Lequel faire en premier » a une réponse nette pour presque tout le monde : le pentest d'abord, le bounty ensuite, les deux à terme. Le pentest solde le gros de la dette à prix fixe et produit l'artefact que vos clients et vos auditeurs demandent. Le VDP, puis le bounty, maintiennent la pression sur tout ce que vous livrez une fois les testeurs partis. Les programmes de sécurité matures traitent le pentest annuel comme la profondeur et le bounty comme la largeur, et routent les deux vers la même chaîne de remédiation pour que les trouvailles deviennent des tests de non-régression plutôt que des factures récurrentes.

Sauter le séquencement, c'est la voie chère. Les équipes qui commencent par le bounty paient leur backlog au bug, en public. Les équipes qui s'en tiennent au pentest encadrent une belle photographie pendant que le film continue de tourner.

Comment Innovation T peut vous aider

Innovation T pratique la sécurité offensive telle que cet article la décrit : des tests d'intrusion cadrés, avec identifiants, en grey-box, avec contre-test contractuel, puis la mise en place d'un VDP et d'un bounty privé quand votre muscle de triage est prêt. Nous construisons aussi la boucle de remédiation, en câblant les trouvailles dans la CI pour que les classes de bugs corrigées le restent. Consultez nos services de sécurité et d'ingénierie pour la vue d'ensemble.

Si vous faites face à une échéance de conformité, à un questionnaire client ou à un produit qui n'a jamais été attaqué par des professionnels, parlons-en. Nous vous dirons honnêtement quelle prestation il vous faut en premier, et laquelle peut attendre.