Un pentest, c'est un prestataire externe qui reçoit une autorisation d'attaquer vos systèmes. Le choix de ce prestataire n'est pas anodin : un test mal conduit peut passer à côté de vulnérabilités critiques, produire un rapport inutilisable, ou dans le pire des cas endommager un environnement de production. À l'inverse, un bon prestataire vous remet un rapport qui déclenche des actions concrètes et mesure réellement votre niveau d'exposition.

Voici les critères objectifs pour évaluer un prestataire, les questions à poser avant de signer, et les signaux d'alerte qui doivent vous faire rebrousser chemin.

1. La spécialisation technique : généraliste ou expert du périmètre ?

La cybersécurité offensive est un domaine vaste. Un consultant excellent sur les applications web peut être peu familier des environnements cloud AWS ou des architectures mobile. Avant d'aller plus loin, vérifiez que la spécialisation du prestataire correspond à votre périmètre :

  • Application web ou API REST/GraphQL : le prestataire doit maîtriser les vulnérabilités OWASP Top 10 et OWASP API Security Top 10, la logique métier, le contournement de WAF
  • Infrastructure cloud AWS : escalade de privilèges IAM, SSRF vers les métadonnées EC2, abus inter-services (Lambda, STS, Organizations) (des vecteurs spécifiques à l'environnement AWS qui nécessitent une expertise dédiée)
  • Application mobile : analyse statique et dynamique (Android/iOS), stockage local, trafic intercepté, API backend associée
  • Réseau interne / Active Directory : Kerberoasting, Pass-the-Hash, délégation Kerberos contrainte (un périmètre très différent du web)

Un prestataire qui répond "oui" à tout sans nuance doit être questionné sur ses références concrètes dans chaque domaine.

2. La méthodologie : structurée ou improvisée ?

Un pentest professionnel suit une méthodologie reconnue, pas une série de scans ad hoc. Les références du secteur sont :

  • OWASP Testing Guide : référentiel détaillé pour les tests d'applications web, couvrant chaque catégorie de vulnérabilité avec des techniques de test explicites
  • PTES (Penetration Testing Execution Standard) : cadre global couvrant toutes les phases d'un test d'intrusion, de la reconnaissance au rapport
  • OSSTMM (Open Source Security Testing Methodology Manual) : approche orientée mesure du risque opérationnel

Demandez au prestataire de vous décrire les phases de sa mission. Un professionnel sérieux détaillera sans hésiter : cadrage et périmètre, reconnaissance, cartographie, tests ciblés par famille de vulnérabilités, exploitation contrôlée avec preuves, rapport. Si la réponse est vague ou centrée sur des outils ("on fait un scan Nessus + Burp"), c'est insuffisant.

3. La qualité du rapport : demandez un exemple

Le rapport est le seul livrable tangible d'un pentest. Demandez systématiquement un exemple anonymisé avant de vous engager. Ce que vous devez y trouver :

  • Pour chaque vulnérabilité : localisation précise (URL, paramètre, endpoint), preuve d'exploitation reproductible (requête HTTP brute, payload, capture d'écran annotée), score CVSS avec justification des métriques, impact potentiel expliqué en termes métier, recommandation de correction concrète avec exemple de code si pertinent
  • Une synthèse exécutive : lisible par un dirigeant non technique, résumant le niveau de risque global et les deux ou trois constats prioritaires
  • Un plan de remédiation priorisé : classement des corrections par ordre de priorité (criticité × facilité d'exploitation), idéalement par équipe responsable (dev, infra, cloud)

Un rapport constitué principalement de sorties brutes de scanners automatiques (Nessus, OpenVAS) avec peu d'analyse manuelle vaut peu : les faux positifs ne sont pas filtrés, l'impact réel n'est pas évalué, et les équipes de dev ne savent pas quoi corriger en premier.

4. Le retest : inclus ou facturé en supplément ?

Le retest consiste à revenir sur les vulnérabilités identifiées après que vous avez appliqué vos correctifs, pour vérifier que la correction est effective et que la surface d'attaque a réellement été réduite. Sans retest, le pentest ne vous dit pas si vous avez corrigé le bon problème au bon endroit.

Vérifiez impérativement avant de signer :

  • Le retest est-il inclus dans le tarif ?
  • Porte-t-il sur toutes les vulnérabilités ou uniquement les critiques et hautes ?
  • Sous quelle forme : rapport de vérification ou simple échange ? Dans quel délai après vos corrections ?

5. L'intervenant : qui réalise concrètement les tests ?

Cette question est souvent la plus importante. Dans certains cabinets, le consultant présenté lors du cadrage commercial n'est pas celui qui conduit les tests : la mission est sous-traitée à un tiers ou confiée à un consultant junior une fois le contrat signé.

Posez la question directement : "Qui intervient concrètement sur ma mission ? Le consultant avec qui j'échange aujourd'hui ?" Demandez que la réponse soit inscrite dans la lettre de mission. Un prestataire transparent ne verra aucun inconvénient à cette précision.

L'avantage d'un intervenant unique de bout en bout : il comprend le contexte métier de votre application dès le cadrage, identifie des vulnérabilités de logique métier que seul quelqu'un ayant compris le produit peut trouver, et peut répondre aux questions techniques lors de l'atelier de restitution sans relire le rapport de quelqu'un d'autre.

6. Les certifications : utiles mais pas suffisantes

Les certifications offensives reconnues dans le secteur :

  • OSCP (Offensive Security Certified Professional) : certification pratique de 24h sur un environnement de test réel. Indicateur sérieux de compétence opérationnelle.
  • OSEP, OSED, OSWE : certifications Offensive Security avancées, spécialisées (évasion antivirus, exploit dev, web avancé)
  • CEH (Certified Ethical Hacker) : certification plus théorique, moins représentative de la compétence pratique
  • GPEN, GWAPT (GIAC) : certifications reconnues, surtout en contexte américain

Une certification n'est ni nécessaire ni suffisante. Un consultant sans certification mais avec dix ans d'expérience réelle et des missions vérifiables vaut mieux qu'un certifié récent sans track record. Les certifications sont un signal parmi d'autres, pas un critère éliminatoire en soi.

7. Les références et la transparence

Un prestataire expérimenté peut mentionner des secteurs ou types d'applications testées, même sans nommer les clients (accord de confidentialité oblige). Ce que vous pouvez raisonnablement demander :

  • Des secteurs d'intervention (SaaS, fintech, santé, industrie...)
  • Des types d'applications testées (marketplace, API bancaire, back-office AWS...)
  • Un exemple de rapport anonymisé (voir critère 3)
  • Un ou deux contacts clients qui acceptent d'être sollicités (pas systématique, mais certains prestataires proposent cette option)

La transparence sur les tarifs est aussi un indicateur : un prestataire qui refuse de donner une fourchette de prix avant d'avoir posé la moindre question sur votre périmètre vous fait perdre du temps. Un devis précis nécessite un brief précis, mais une fourchette indicative par type de mission (web, AWS, SaaS) est une pratique normale.

8. La lettre de mission : la pièce la plus importante

Avant tout test, une lettre de mission ou un bon de commande doit être signé par les deux parties. Elle doit contenir :

  • Le périmètre autorisé : liste explicite des domaines, IP, API, environnements. Tout ce qui n'est pas listé est hors scope.
  • Les dates de début et de fin de mission
  • Les techniques autorisées : test non destructif, exploitation contrôlée, social engineering exclu ou inclus
  • Le contact technique côté client, joignable en cas d'incident
  • Les conditions de confidentialité sur les vulnérabilités découvertes

Cette lettre vous protège juridiquement : elle atteste que les tests ont été réalisés dans le cadre d'une autorisation formelle. En son absence, un test d'intrusion peut être qualifié d'accès frauduleux à un système informatique au sens de l'article 323-1 du Code pénal, même avec les meilleures intentions.

Questions à poser avant de signer

Voici une liste de questions concrètes à poser lors du premier échange, avant toute décision :

  1. Qui intervient concrètement sur ma mission ? Le consultant présent dans cet échange, ou un tiers ?
  2. Sous-traitez-vous une partie de la mission ? Si oui, à qui, et quel est leur niveau de qualification ?
  3. Quelle est votre méthodologie ? Quelles phases couvre-t-elle, quels référentiels utilisez-vous ?
  4. Pouvez-vous me montrer un exemple de rapport ? Un rapport anonymisé suffit.
  5. Le retest est-il inclus ? Sur quelles vulnérabilités, dans quel délai, sous quelle forme ?
  6. Avez-vous testé ce type d'application ou d'infrastructure ? SaaS multi-tenant, API GraphQL, environnement AWS avec IAM complexe...
  7. Comment gérez-vous la découverte d'une vulnérabilité critique en cours de mission ? Notification immédiate ? Suspension des tests ?
  8. Votre assurance RC pro couvre-t-elle les missions de pentest ? Et pour quel montant ?

Les signaux d'alerte à ne pas ignorer

Certains comportements doivent vous conduire à chercher un autre prestataire :

  • Un devis envoyé sans poser de question sur le périmètre. Un tarif fixe "pentest web" sans connaître la taille de l'application, le nombre de rôles, la présence d'une API ou d'une infrastructure cloud, c'est un forfait générique qui ne correspond à aucune réalité technique.
  • La promesse de "certifier" ou "valider" la sécurité. Un pentest démontre ce qui est exploitable dans un périmètre donné, à un instant T, avec les techniques connues. Il ne prouve pas l'absence de vulnérabilité. Tout prestataire qui garantit votre sécurité après un test ment.
  • L'absence de lettre de mission. Un prestataire qui commence à tester sans autorisation écrite vous expose à des risques juridiques et opérationnels.
  • Un rapport généré automatiquement. Si le rapport que l'on vous présente ressemble à une sortie de scanner (Nessus, OpenVAS, Burp Scanner) avec peu d'analyse manuelle ajoutée, la valeur du test est très limitée. Les scanners automatiques ne trouvent pas les vulnérabilités de logique métier ni les chaînages de failles.
  • Un changement d'interlocuteur entre le devis et la mission. Si le consultant technique que vous avez rencontré est remplacé au dernier moment par quelqu'un d'autre sans explication, questionnez la sous-traitance.
  • Des délais anormalement courts. Tester sérieusement une application web avec authentification et API prend 3 à 5 jours minimum. Un "pentest complet" en 1 journée est soit un audit superficiel, soit une campagne de scan automatisé rebrandée.

Indépendant vs cabinet : comment choisir

Il n'existe pas de réponse universelle, mais voici les différences pratiques :

Consultant indépendant Cabinet de conseil
Interlocuteur Unique de bout en bout Commercial + consultant(s), parfois différents
Tarif Plus compétitif (pas de frais de structure) Plus élevé (structure, commerciaux, management)
Spécialisation Expertise ciblée sur 1 à 2 domaines Plusieurs profils disponibles en parallèle
Capacité Périmètre adapté à 1 consultant Utile pour les périmètres très larges ou les red teams
Réactivité Souvent plus rapide pour cadrer et démarrer Processus de vente plus long

Pour la majorité des PME, des éditeurs SaaS et des startups, un consultant indépendant expérimenté spécialisé sur votre périmètre est le choix le plus pertinent en termes de rapport qualité/prix. Un cabinet s'impose davantage pour des périmètres très larges nécessitant plusieurs consultants en simultané ou pour des exercices red team multi-vecteurs.

FAQ : choisir son prestataire de pentest

Comment évaluer la compétence technique d'un prestataire de pentest ?

Demandez un exemple de rapport anonymisé. Un bon rapport comporte des preuves d'exploitation reproductibles (requêtes HTTP brutes, captures annotées, payloads), un score CVSS justifié pour chaque vulnérabilité et des recommandations de correction concrètes. Un rapport constitué de sorties de scanners automatiques avec peu d'analyse manuelle est un signal d'alerte.

Faut-il choisir un prestataire certifié OSCP ou CEH ?

Les certifications offensives comme l'OSCP sont un indicateur sérieux de compétence pratique. Le CEH est davantage théorique. Une certification n'est ni nécessaire ni suffisante : un consultant sans certification mais avec dix ans d'expérience réelle et des missions vérifiables vaut mieux qu'un certifié récent sans track record. Priorisez les références et un exemple de rapport.

Le retest est-il inclus dans le prix ?

Pas systématiquement. Certains prestataires facturent le retest séparément (0,5 à 1 jour supplémentaire). Vérifiez ce point avant de signer : sans retest, vous n'avez aucune confirmation que vos corrections ont bien éliminé les vulnérabilités identifiées.

Vaut-il mieux un consultant indépendant ou un cabinet ?

Un consultant indépendant spécialisé offre un interlocuteur unique, un tarif plus compétitif et une expertise ciblée. Un cabinet peut mobiliser plusieurs profils en simultané, utile pour les périmètres larges ou les red teams. Pour la plupart des PME et éditeurs SaaS, un consultant indépendant expérimenté est le choix le plus pertinent.

Comment vérifier qu'il n'y a pas de sous-traitance ?

Demandez que la lettre de mission précise que la mission est réalisée par le consultant présenté lors du cadrage, sans sous-traitance non déclarée. Posez la question directement. Une réponse évasive ou un changement d'interlocuteur entre le devis et le démarrage de la mission doit alerter.

Quels documents demander avant de signer ?

Au minimum : une lettre de mission précisant le périmètre autorisé, les dates et les techniques applicables ; un exemple de rapport anonymisé ; une attestation d'assurance RC pro couvrant les missions de pentest. La lettre de mission est la pièce la plus importante : elle vous protège juridiquement et garantit que le périmètre est compris de la même façon par les deux parties.