Pentest web : coûts, délais et livrables (ce que vous achetez réellement)

Un pentest web s’achète rarement “à l’heure”. Vous achetez une décision : réduire un risque concret, dans une fenêtre de temps, avec des preuves, des priorités et un plan de correction. Le prix et la durée n’ont de sens que si le périmètre, les hypothèses et les livrables sont clairs.

Cet article explique ce qui fait varier le coût d’un pentest web, combien de temps cela prend en pratique, et ce que vous devez obtenir à la fin pour que l’exercice soit utile côté engineering comme côté direction.

Ce qui fait varier le coût d’un pentest web

Un pentest n’est pas un “scan plus cher”. Les facteurs de coût reflètent surtout la complexité fonctionnelle, la surface d’attaque et le niveau d’accès.

1) Le périmètre réel (et pas le nombre d’URLs)

Le périmètre pertinent est fonctionnel :

• authentification (SSO, MFA, passwordless, magic links)
• gestion de session (cookies, tokens, rotation, révocation)
• parcours critiques (paiement, création de compte, modifications de profil, exports)
• API (REST/GraphQL), BFF, webhooks
• back-office (rôles, permissions, actions sensibles)
• stockage et fichiers (uploads, previews, conversions)

Deux sites “de même taille” peuvent coûter très différemment si l’un est une vitrine et l’autre une application métier avec des rôles et une logique d’autorisation complexe.

2) Le niveau d’accès (black-box, grey-box, white-box)

• black-box : peu d’information, plus de temps en reconnaissance et en contournements
• grey-box : un ou plusieurs comptes, plus efficace, plus proche d’un scénario réel
• white-box : docs et éventuellement accès code, utile pour accélérer sur les flux critiques, mais cela ne remplace pas les tests d’exploitation

En pratique, le meilleur ROI pour beaucoup d’équipes B2B est le grey-box : un accès utilisateur standard et, si possible, un rôle admin limité.

3) Les environnements et contraintes d’exploitation

Quelques éléments qui augmentent la charge :

• WAF / bot protection agressive
• limitations strictes (fenêtres de tests, restrictions IP, pas de brute force)
• données sensibles, anonymisation, logs à auditer
• multi-tenant ou segmentation complexe (espaces, organisations, projets)

Ces contraintes sont normales. Elles doivent simplement être intégrées au cadrage, sinon vous payez des allers-retours.

4) L’objectif : conformité, assurance, ou réduction de risque opérationnel

Un pentest “pour un client” ou “pour une assurance” a souvent des exigences spécifiques sur le rapport, la traçabilité et les preuves. Un pentest orienté réduction de risque cherche, lui, à maximiser la couverture des flux critiques et l’actionnabilité des recommandations.

Avant de comparer des devis, clarifiez l’objectif.

Délais : combien de temps ça prend vraiment

La durée totale se décompose en trois blocs.

1) Cadrage (souvent sous-estimé)

Le cadrage est court si vous préparez bien :

• accès (comptes, VPN si besoin, IPs autorisées)
• périmètre (URLs, apps, API, back-office)
• contraintes (plages horaires, règles d’engagement)
• contacts (qui répond, dans quel délai)

Quand le cadrage est flou, le projet s’étire. Le meilleur indicateur de délai n’est pas la technique, mais la réactivité sur les points de blocage.

2) Phase de test

La phase de test varie selon la complexité. En pratique :

• application simple : quelques jours
• application B2B avec rôles et logique métier : une à deux semaines
• e-commerce + paiement + back-office : souvent plus, surtout si plusieurs prestataires (PSP, anti-fraude, webhooks)

3) Rapport + restitution

Un rapport utile demande du temps. Le minimum acceptable :

• preuves reproductibles
• endpoints/écrans concernés
• impact expliqué
• recommandations concrètes
• priorisation

La restitution (débrief) évite que le rapport reste “dans un dossier”. C’est souvent là que vous récupérez le meilleur ROI.

Pour nos services, l’objectif est un rapport livré rapidement une fois le test lancé, avec une restitution orientée correction.

Livrables : ce que vous devez exiger

Un pentest web n’est pas “réussi” parce qu’il a trouvé des failles. Il est utile si l’équipe peut corriger efficacement.

1) Un rapport exploitable par l’équipe

Le rapport doit contenir :

• une synthèse exécutive (risques majeurs, recommandations globales)
• une section technique par vulnérabilité
• des étapes de reproduction (claires, sans ambiguïté)
• des preuves (captures, requêtes, réponses, logs si nécessaire)
• un niveau de sévérité cohérent et justifié

Si votre équipe ne peut pas reproduire, vous ne pouvez pas corriger. C’est un critère dur.

2) Une priorisation pragmatique

La priorisation doit tenir compte :

• de l’exploitabilité (pré-requis, complexité, bruit)
• de l’impact métier (fraude, fuite, intégrité, disponibilité)
• du contexte (exposition Internet, segmentation, protections)

Les scores “automatiques” (type CVSS) peuvent aider, mais ne remplacent pas une lecture métier. Sur un e-commerce, une faille de logique peut être plus grave qu’une vulnérabilité technique “classique”.

3) Des recommandations actionnables

Vous voulez :

• une correction recommandée (et pourquoi)
• des alternatives si le correctif idéal est coûteux
• des “pièges” à éviter (effets de bord, régressions)
• des tests de non-régression à ajouter

Un bon rapport vous fait gagner du temps, pas l’inverse.

4) Un retest (ou une validation) cadré

Si vous corrigez, vous devez valider. Le retest peut être :

• inclus sur une sélection de failles critiques
• vendu en option

L’important est que ce soit clair dès le départ.

Checklist d’achat : questions à poser avant de signer

Voici une checklist courte qui évite la majorité des mauvaises surprises.

Périmètre et accès

• quels parcours métier seront testés en priorité ?
• quels rôles/comptes sont nécessaires ?
• l’API est-elle incluse (REST/GraphQL, webhooks) ?
• le back-office est-il inclus ?
• y a-t-il des restrictions (WAF, rate limits, plages horaires) ?

Méthode et preuves

• les tests sont-ils manuels, automatisés, ou mixtes ?
• quelles preuves seront fournies (requêtes, captures, etc.) ?
• comment sont gérés les faux positifs ?

Rapport et restitution

• le rapport contient-il des étapes de reproduction ?
• y a-t-il une restitution avec votre équipe ?
• qui reçoit la synthèse exécutive ?
• le format est-il compatible avec vos besoins (audit interne, assurance, client) ?

Validation

• retest inclus ou non ?
• sous quel délai et sur quel périmètre ?

Quels liens avec vos pages “services”

Si vous cherchez une approche structurée, vous pouvez consulter :

• Pentest application web : https://obveron.com/pentest-application-web
• Pentest (général) : https://obveron.com/pentest
• Audit de sécurité web : https://obveron.com/audit-securite
• Réserver un échange : https://obveron.com/book-a-call

Pour des bases officielles et des listes de contrôles, deux ressources utiles :

• OWASP Top 10 (Web) : https://owasp.org/www-project-top-ten/
• ANSSI (guides et recommandations) : https://www.ssi.gouv.fr/guide/

Conclusion

Le coût et les délais d’un pentest web sont une conséquence du périmètre, du niveau d’accès et de la qualité attendue sur les livrables. La bonne question n’est pas “combien ça coûte”, mais “qu’est-ce que l’équipe pourra corriger, et à quelle vitesse, après le test”.

Si vous voulez cadrer rapidement un pentest adapté à votre contexte (B2B, e-commerce, application web, API), vous pouvez réserver un échange de 15 minutes : https://obveron.com/book-a-call