Un pentest applicatif web est un test d’intrusion autorisé qui reproduit les techniques d’un attaquant réel pour identifier et prouver des vulnérabilités exploitables dans vos applications, sites et API. La première action concrète : formaliser le périmètre et obtenir une autorisation écrite avant toute manipulation technique.
Ce que vous obtenez à l’issue d’une mission bien conduite :
- Preuves d’exploitation (PoC) : captures, requêtes reproductibles, démonstration de l’impact réel
- Plan de remédiation priorisé : vulnérabilités classées par criticité (CVSS v3.1), avec recommandations concrètes
- Rapport technique + synthèse non technique pour votre direction (Comex)
- Fichier de suivi (CSV/Excel) pour piloter les corrections en équipe
- Engagement de retest : vérification que les correctifs tiennent
Conseil de pro : Ne commandez pas un pentest sans avoir d’abord listé vos domaines, sous-domaines, comptes de test fournis et plages horaires autorisées. Un cadrage bâclé détruit la valeur du test, quelle que soit la compétence du prestataire.
Points clés
Un pentest applicatif web bien conduit repose sur une autorisation écrite, un périmètre précis, des PoC reproductibles et un retest contractuel : sans ces quatre éléments, le rapport n’a ni valeur probante ni utilité opérationnelle.
| Point | Détails |
|---|---|
| Autorisation écrite obligatoire | Sans convention signée, le test est illégal en France (art. 323-1 du Code pénal). |
| Grey box comme standard | Le grey box offre le meilleur ratio coût/couverture ; réservez le white box aux modules critiques. |
| PoC et retest contractuels | Exigez des preuves d’exploitation reproductibles et un retest inclus dans le forfait. |
| Valeur réglementaire | Le rapport sert de preuve pour RGPD (art. 32), NIS2 et ISO 27001. |
| Fréquence recommandée | Pentest annuel pour périmètres critiques, et après chaque release majeure ou intégration d’API sensible. |
Table des matières
- Qu’est-ce qu’un pentest applicatif web, et en quoi diffère-t-il d’un scan ?
- Pourquoi un pentest applicatif apporte-t-il une valeur concrète à votre entreprise ?
- Quelles failles un pentest web révèle-t-il concrètement ?
- Comment définir un périmètre technique complet pour votre mission ?
- Black box, grey box, white box : quelle méthodologie choisir ?
- Quelles sont les étapes d’un pentest applicatif, du cadrage au retest ?
- Quelles obligations légales encadrent un pentest applicatif en France ?
- Comment choisir un prestataire de pentest applicatif avant de signer ?
- Agence de développement ou pentester indépendant : comment décider ?
- Ce que l’expérience terrain enseigne vraiment sur le pentest applicatif
- Sources
- Questions fréquentes
Qu’est-ce qu’un pentest applicatif web, et en quoi diffère-t-il d’un scan ?
Le terme « pentest applicatif web » désigne un test d’intrusion ciblant la couche applicative : le code, la logique métier, les interfaces utilisateur et les API, par opposition aux tests d’infrastructure réseau qui s’attaquent aux équipements, pare-feux et systèmes d’exploitation.
Trois approches coexistent, souvent confondues :
- Scan automatisé de vulnérabilités : un outil (Nikto, OWASP ZAP, Burp Suite Scanner) parcourt l’application et signale des anomalies connues. Rapide, peu coûteux, mais aveugle à la logique métier et générateur de faux positifs.
- Audit de code (SAST) : analyse statique du code source, sans exécution. Détecte des patterns dangereux mais ne prouve pas l’exploitabilité réelle.
- Pentest manuel applicatif : un testeur humain exploite activement les failles, enchaîne des vulnérabilités, contourne les contrôles et documente chaque étape. C’est la seule approche qui prouve l’impact réel.
On parle de « pentest web » dès que la cible principale est une application accessible via HTTP/HTTPS, qu’elle soit publique ou interne.
Trois modes d’intervention définissent le niveau d’information fourni au testeur :
- Black box : aucune information préalable, simulation d’un attaquant externe. Réaliste pour tester l’exposition, mais couverture limitée.
- Grey box : accès à un compte utilisateur, documentation partielle. Standard du marché pour un bon ratio coût/couverture.
- White box : accès complet (code source, architecture, credentials). Recommandé pour les modules critiques où une couverture maximale est exigée.
Pourquoi un pentest applicatif apporte-t-il une valeur concrète à votre entreprise ?
Un scanner automatisé ne prouvera jamais qu’un attaquant peut extraire la base clients ou contourner votre processus de paiement. Le pentest, lui, le démontre, et c’est précisément ce que demandent vos auditeurs, vos clients grands comptes et les régulateurs.
Bénéfices opérationnels et réglementaires :
- Réduction du risque réel : chaque vulnérabilité exploitée et corrigée ferme une porte avant qu’un attaquant ne la franchisse. L’impact peut aller de la fuite de données personnelles à la compromission totale de l’infrastructure.
- Conformité RGPD (art. 32) : les tests d’intrusion sont reconnus comme le moyen approprié pour satisfaire l’obligation de « tester, analyser et évaluer régulièrement » l’efficacité des mesures de sécurité.
- NIS2 et ISO 27001 : NIS2, DORA et le RGPD renforcent les obligations de tests réguliers pour les entités concernées ; le non-respect expose à des sanctions financières et administratives. L’annexe A.8.8 d’ISO 27001 exige explicitement la gestion des vulnérabilités techniques.
- Valeur pour le management : la synthèse Comex traduit les risques techniques en impacts métier chiffrables, ce qui facilite les arbitrages budgétaires.
Un pentest est une photographie à un instant T. Il ne remplace pas le SAST continu, le bug bounty ou les contrôles en pipeline CI/CD. Un programme de sécurité mature combine les trois.
Quelles failles un pentest web révèle-t-il concrètement ?
L’OWASP Top 10 structure la majorité des tests applicatifs. Voici les familles de vulnérabilités les plus fréquemment exploitées, avec leur impact métier et leur niveau d’urgence.
| Catégorie (OWASP / CWE) | Exemple de test | Impact métier | Urgence |
|---|---|---|---|
| Injection SQL | Paramètre de recherche non filtré | Extraction complète de la base de données | Critique |
| XSS stocké | Champ commentaire injecté dans le DOM | Vol de session, phishing ciblé | Haute |
| IDOR / BOLA | Modification d’un ID dans l’URL pour accéder aux données d’un autre utilisateur | Accès non autorisé aux données personnelles | Critique |
| Défauts d’authentification | Absence de verrouillage après tentatives, tokens faibles | Prise de contrôle de compte | Haute |
| SSRF (A10) | Requête vers une URL interne via un champ de l’application | Accès aux métadonnées cloud, rebond interne | Haute |
| Logique métier | Modification du prix dans la requête de paiement | Fraude, perte financière directe | Critique |
| Composants vulnérables | Bibliothèque JS ou dépendance back-end obsolète | Exploitation de CVE publique | Variable |
| Mauvaise configuration | Headers de sécurité absents, CORS permissif | Exposition de données, attaques cross-origin | Moyenne |
Pour chaque découverte, un pentester documente : la requête brute, la réponse serveur, la capture d’écran, le mapping WSTG et CWE, le score CVSS v3.1, et une recommandation de correction précise.
Conseil de pro : Demandez systématiquement que chaque PoC soit reproductible par votre équipe de développement. Un PoC que vous ne pouvez pas rejouer vous-même est un PoC inutile pour valider la correction.
Comment définir un périmètre technique complet pour votre mission ?
Un périmètre mal défini est la première cause d’un pentest décevant. Trop large, il dilue l’effort ; trop étroit, il laisse des angles morts critiques.
Éléments à inclure dans la convention :
- Tous les domaines et sous-domaines actifs (y compris staging et pré-production si accessibles)
- Endpoints UI et endpoints API (REST, GraphQL, webhooks)
- Back-office d’administration et interfaces internes
- Intégrations tierces : SSO, fournisseurs de paiement, services d’envoi d’e-mails, CDN
- Composants open source et bibliothèques JavaScript exposées côté client
- Hébergement cloud : buckets S3, fonctions serverless, configurations IAM exposées
Checklist pour la convention de pentest :
- Liste exhaustive des domaines et sous-domaines dans le périmètre
- Comptes de test fournis (rôles utilisateur, administrateur, invité)
- Plages horaires autorisées pour les tests actifs
- Contacts d’escalade incident (technique et décisionnel)
- Environnements exclus (production critique sans sauvegarde préalable, bases de données sensibles)
- Techniques interdites (déni de service, destruction de données)
- Procédure de notification en cas de découverte critique en cours de test
Les exclusions méritent autant d’attention que les inclusions. Consignez explicitement ce qui est hors périmètre pour éviter tout litige en cas d’incident.
Black box, grey box, white box : quelle méthodologie choisir ?
Le choix du mode d’intervention conditionne directement la couverture obtenue et le budget nécessaire. Le grey box est le standard du marché pour un bon ratio coût/couverture, le white box est recommandé sur les modules critiques, et le black box pour tester l’exposition externe réaliste.
Les référentiels utilisés par les prestataires sérieux :
- OWASP WSTG v4.2 : guide de test le plus complet pour les applications web, structuré par catégorie de vulnérabilité
- PTES (Penetration Testing Execution Standard) : cadre méthodologique général couvrant toutes les phases
- NIST SP 800-115 : guide technique américain, souvent cité dans les appels d’offres internationaux
- PASSI (ANSSI) : qualification française pour prestataires d’audit de sécurité, obligatoire pour les Opérateurs d’Importance Vitale (OIV) et les Opérateurs de Services Essentiels (OSE)
Les outils automatiques (Burp Suite Pro, OWASP ZAP, Nikto, sqlmap, ffuf) accélèrent la phase de cartographie et de détection des vulnérabilités connues. Mais la logique métier, les enchaînements de failles et les contournements de contrôles d’accès ne se découvrent qu’à la main. Un prestataire qui livre uniquement un export de scanner n’a pas réalisé un pentest.
Les exigences contractuelles sur la méthode doivent préciser : outils autorisés, techniques interdites (fuzzing agressif en production, DoS), limites d’impact acceptables, et obligation de notification immédiate en cas de découverte critique.
Quelles sont les étapes d’un pentest applicatif, du cadrage au retest ?
Un pentest web suit six phases structurées, chacune avec ses livrables propres.
- Cadrage et convention écrite : définition du périmètre, des objectifs, des contraintes légales, signature de l’autorisation. Livrable : convention de pentest signée. Durée : 0,5 à 2 jours.
- Reconnaissance passive : collecte d’informations sans interaction directe (OSINT, DNS, certificats, fuites GitHub). Livrable : cartographie initiale des actifs.
- Reconnaissance active et cartographie : exploration des endpoints, identification des technologies, mapping manuel des fonctionnalités. Livrable : liste d’endpoints et surface d’attaque documentée.
- Exploitation : tests ciblés par famille de vulnérabilité (OWASP WSTG), enchaînement de failles, escalade de privilèges. Livrable : PoC reproductibles pour chaque vulnérabilité confirmée.
- Post-exploitation et rapport : évaluation de l’impact réel, rédaction du rapport technique et de la synthèse Comex, scoring CVSS, plan de remédiation priorisé. Livrable : rapport complet + fichier Excel de suivi.
- Restitution et retest : présentation orale des résultats, questions/réponses avec l’équipe technique, puis vérification des correctifs après remédiation. Livrable : rapport de retest avec statut par vulnérabilité.
- Site vitrine simple (5–10 pages, pas d’authentification) : 2–3 jours
- Application métier avec authentification et rôles : 5–8 jours
- Plateforme e-commerce avec API et paiement : 8–12 jours
- Application critique avec microservices et API multiples : 15 jours et plus
Un rapport utile pour un RSSI contient une synthèse non technique pour le Comex et un fichier exploitable (CSV/Excel) pour le suivi opérationnel des corrections. Exigez les deux dès la signature du contrat.
Quelles obligations légales encadrent un pentest applicatif en France ?
Tester une application sans autorisation écrite préalable constitue une infraction pénale en France, au titre des articles 323-1 et suivants du Code pénal (accès frauduleux à un système de traitement automatisé de données). Cette règle s’applique même si vous êtes propriétaire de l’application et que le testeur agit pour votre compte.
Clauses contractuelles indispensables dans la convention de pentest :
- Autorisation écrite et signée par le responsable légal ou le mandataire habilité, avec périmètre précis
- Responsabilité civile professionnelle du prestataire : vérifiez que la police couvre explicitement les missions de test d’intrusion
- Traitement des données personnelles : le testeur peut accéder à des données réelles ; prévoyez une clause de confidentialité, de minimisation et d’effacement en fin de mission
- Conservation des preuves : durée de rétention des logs et PoC, propriété des preuves après la mission
- Plan d’escalade incident : procédure si une vulnérabilité critique est découverte en cours de test (notification immédiate, suspension des tests si nécessaire)
Le référentiel PASSI de l’ANSSI impose ces exigences aux prestataires qualifiés et constitue la référence contractuelle pour les entreprises soumises à LPM, NIS2 ou souhaitant une valeur probante maximale pour un audit externe.
Conseil de pro : Si le testeur découvre des données personnelles de tiers (clients, salariés) pendant le test, la minimisation s’impose immédiatement : ne pas copier, ne pas conserver, notifier le responsable de traitement. Intégrez cette procédure dans la convention avant le démarrage.
Pour approfondir vos obligations RGPD spécifiques à votre site, le guide RGPD pour PME offre un cadrage pratique adapté aux structures françaises. Vos obligations RGPD en tant qu’entreprise française sont également détaillées dans notre guide dédié.
Comment choisir un prestataire de pentest applicatif avant de signer ?
La qualité d’un pentest dépend presque entièrement du testeur, pas de l’outil. Voici les critères qui distinguent un prestataire sérieux d’un vendeur de rapports de scanner.
Critères de sélection :
- Méthodologie documentée : le prestataire doit pouvoir décrire précisément son approche (OWASP WSTG, PTES) et les outils utilisés avant la mission
- Expérience sectorielle : une application de santé ou de finance a des contraintes de conformité et des risques métier spécifiques
- Références vérifiables : demandez des études de cas ou des contacts clients dans votre secteur
- Assurance RC professionnelle couvrant explicitement les tests d’intrusion
- Qualification PASSI si votre entreprise est OIV, OSE, ou si vous avez besoin d’une valeur probante maximale pour un audit externe
Questions à poser avant de signer :
- Quelle approche recommandez-vous pour notre périmètre (grey/white box) et pourquoi ?
- Chaque vulnérabilité sera-t-elle mappée au WSTG et au CWE, avec PoC reproductible ?
- Le retest est-il inclus dans le forfait, et sous quel délai ?
- Quel est votre SLA en cas de découverte critique pendant le test ?
- Comment gérez-vous les données personnelles auxquelles vous pourriez accéder ?
- Fournissez-vous une synthèse Comex en plus du rapport technique ?
Éléments contractuels à négocier :
- Périmètre précis et liste d’exclusions signée
- Plages horaires et limites d’impact acceptables
- Clause de confidentialité et propriété des preuves
- Engagement de retest avec délai défini
- Plan de remédiation inclus ou en option
Agence de développement ou pentester indépendant : comment décider ?
La question n’est pas « l’un ou l’autre » mais « lequel pour quoi ». Les rôles sont distincts et complémentaires.
Wstart, en tant qu’agence de développement, intervient naturellement sur la sécurité intégrée au cycle de vie : revue de code, correction des vulnérabilités identifiées, mise en place des headers de sécurité, gestion des dépendances, audit technique et accompagnement post-pentest pour les corrections front-end et back-end. La connaissance de la stack propriétaire est un avantage décisif pour corriger vite et bien.
Un pentester indépendant ou un cabinet spécialisé apporte ce que l’agence de développement ne peut pas fournir : l’indépendance du regard. Pour un audit externe, une certification, un appel d’offres grand compte ou une obligation réglementaire (NIS2, ISO 27001), la valeur probante d’un rapport signé par un tiers sans lien avec le développement est irremplaçable.
Le modèle recommandé pour une entreprise de taille intermédiaire : confier la sécurité continue (corrections, mises à jour, revue de code) à votre agence de développement, et mandater un pentester externe une à deux fois par an, ou après chaque évolution majeure de l’application.
Conseil de pro : Formalisez une ligne de responsabilités dans vos contrats : qui est responsable de corriger, qui valide la correction, qui réalise le retest. Sans cette clarté, les vulnérabilités critiques restent ouvertes pendant des semaines après le rapport.
Ce que l’expérience terrain enseigne vraiment sur le pentest applicatif
La fréquence recommandée est simple : un pentest annuel pour tout périmètre critique, systématiquement après une release majeure, et dès qu’une API ou un composant tiers sensible est intégré. Ce n’est pas une règle arbitraire — c’est le rythme auquel les applications changent suffisamment pour invalider les conclusions du test précédent.
La priorité initiale, si vous partez de zéro : authentification et gestion des autorisations d’abord. Les failles IDOR et les défauts d’authentification représentent la majorité des incidents réels, et elles sont systématiquement sous-estimées lors des développements. Viennent ensuite les endpoints API exposés, la logique métier critique (paiement, droits d’accès, workflows sensibles), puis les dépendances tierces.
Les pièges les plus courants, observés régulièrement :
- Cadrage bâclé : périmètre flou, pas de comptes de test fournis, plages horaires non définies
- Absence d’autorisation écrite, qui expose le prestataire et le commanditaire
- Croire qu’un scanner automatisé suffit, alors qu’il ne détecte pas la logique métier
- Ne pas inclure le retest dans le contrat, puis découvrir que les correctifs n’ont pas tenu
Pour un RSSI ou un CTO qui veut structurer la démarche rapidement : commencez par la convention écrite, choisissez le grey box comme mode par défaut, exigez le PoC et le retest, et planifiez la prochaine mission dès la clôture de la première.
Sources
Références méthodologiques et réglementaires pour approfondir et cadrer votre mission :
- Méthodologie pentest web 2026 : OWASP WSTG en pratique – Zeroday Cyber Academy
- Tests d’intrusion (pentest) : guide et obligations 2026
- Comment conduire un pentest web : méthodologie complète 2026
Questions fréquentes
Quelle est la différence entre un pentest et un scan de vulnérabilités ?
Un scan automatisé détecte des anomalies connues sans les exploiter ; un pentest manuel prouve l’exploitabilité réelle et évalue l’impact concret sur votre activité.
Le pentest applicatif web est-il obligatoire pour la conformité RGPD ?
Le RGPD (art. 32) impose de tester régulièrement les mesures de sécurité ; les tests d’intrusion sont reconnus comme le moyen approprié pour satisfaire cette obligation, sans être formellement obligatoires sous ce nom.
Combien de temps dure un pentest applicatif web ?
Faut-il une qualification PASSI pour commander un pentest ?
Non, la qualification PASSI concerne le prestataire, pas le commanditaire. Elle est cependant exigée pour les OIV et OSE, et apporte une valeur probante supérieure pour les audits externes ou les contentieux.
Quand faut-il réaliser un pentest applicatif ?
Avant toute mise en production majeure, après l’intégration d’une API ou d’un composant tiers sensible, et au minimum une fois par an pour les périmètres critiques.
