Comment se déroule un test d'intrusion web ? Les étapes
d'un pentest

Vous avez validé le budget, signé le devis, et là une petite voix vous souffle : « OK… mais concrètement, il se passe quoi maintenant ? Quelqu'un va casser mon site ? Pendant les heures de bureau ? Et je récupère quoi à la fin ? » Bonne nouvelle : un test d'intrusion n'a rien d'un coup de poker. C'est un processus balisé, méthodique, prévisible, et — promis — beaucoup moins anxiogène qu'une scène de film avec un encapuchonné qui tape « ACCESS GRANTED » en vert sur fond noir.

Dans cet article, on déroule les étapes d'un pentest web dans l'ordre, telles qu'elles se passent réellement. Si vous vous demandez plutôt combien ça coûte, on a écrit l'article frère sur le prix d'un test d'intrusion. Ici, on parle méthodologie et déroulement.

D'abord, une méthodologie (pas de l'improvisation)

Un pentester sérieux ne se réveille pas un matin en lançant des outils au hasard. Il suit une méthodologie reconnue, ce qui garantit une couverture complète et reproductible. Les trois références du métier :

• PTES (Penetration Testing Execution Standard) : le standard qui découpe une mission en 7 phases, du cadrage au rapport. C'est la colonne vertébrale du déroulement décrit ci-dessous.
• OWASP WSTG (Web Security Testing Guide) : le catalogue de tests spécifiques au web — authentification, autorisation, sessions, injections, logique métier. C'est la checklist technique appliquée pendant la phase de découverte.
• OSSTMM : une méthodologie plus large (réseau, humain, physique) maintenue par l'ISECOM, utile quand le périmètre dépasse la seule application web.

Chez own2pwn, nos missions s'appuient sur PTES pour le déroulement et sur l'OWASP WSTG pour la couverture technique. Concrètement, ça donne le parcours suivant.

  [1] CADRAGE          scope + autorisation + regles d'engagement
        |
        v
  [2] RECONNAISSANCE   OSINT, sous-domaines, techno, surface exposee
        |
        v
  [3] CARTOGRAPHIE     crawl, points d'entree, roles, endpoints API
        |
        v
  [4] DECOUVERTE       tests OWASP WSTG : authz, injections, logique...
        |
        v
  [5] EXPLOITATION     on prouve la faille (avec preuve, sans casse)
        |
        v
  [6] POST-EXPLOIT     impact reel : rebond, escalade, donnees accessibles
        |
        v
  [7] RAPPORT          findings + risque + remediation + restitution
        |
        v
  [8] RETEST           on revient verifier que c'est bien corrige

Phase 1 — Cadrage et autorisation

C'est la phase la plus importante, et pourtant celle qu'on oublie de raconter. Le cadrage du pentest (ou pre-engagement dans PTES) définit : quoi on teste (URLs, domaines, API, applis mobiles), comment (blackbox sans accès vs whitebox avec comptes et code), quand (fenêtre de tir, horaires, environnement de prod ou de recette), et ce qu'on ne touche surtout pas (systèmes tiers, attaques de déni de service, données réelles de clients).

Surtout, on signe une autorisation de test. Sans ce document, un test d'intrusion n'est légalement pas distinguable d'une cyberattaque. Cette « lettre d'autorisation » (ou get-out-of-jail-free card) protège le pentester comme le client. Non négociable.

Phase 2 — Reconnaissance

La reconnaissance (ou intelligence gathering), c'est la collecte d'informations sur la cible. On cartographie la surface exposée : sous-domaines oubliés, technologies utilisées, versions de frameworks, fuites sur GitHub, certificats, en-têtes HTTP, endpoints d'API qui traînent. Une partie est passive (OSINT, sans toucher la cible) et une partie active (scans légers).

On le dit rarement aux clients, mais comme le résume bien la philosophie du métier : un pentest, c'est surtout de la recon. La qualité d'une mission se joue énormément ici : un sous-domaine de préprod indexé par erreur, et c'est tout un pan d'attaque qui s'ouvre.

Phase 3 — Cartographie de l'application

Place au mapping. Le pentester parcourt l'application comme un utilisateur, mais avec un proxy d'interception (type Burp Suite) qui enregistre chaque requête et chaque réponse. Objectif : comprendre la logique, lister tous les points d'entrée (formulaires, paramètres, cookies, headers, routes d'API), identifier les différents rôles (visiteur, utilisateur, admin) et repérer les fonctionnalités sensibles. C'est la phase « passive » de l'OWASP : on ne casse encore rien, on dresse la carte du territoire.

Phase 4 — Découverte de vulnérabilités

Maintenant on attaque pour de vrai. Cette phase combine outillage automatisé (scanners pour dégrossir) et surtout tests manuels guidés par l'OWASP WSTG. C'est le cœur du métier : contrôles d'accès cassés, injections (SQL, NoSQL, commande), failles d'authentification et de session, XSS, SSRF, désérialisation, et — le graal — les failles de logique métier qu'aucun scanner ne trouvera jamais. Pour comprendre pourquoi l'humain reste irremplaçable face à un outil automatique, on a écrit pentest vs scan de vulnérabilité.

Phase 5 — Exploitation

Trouver une faille potentielle, c'est bien. Prouver qu'elle est réellement exploitable, c'est tout l'intérêt du pentest. L'exploitation consiste à transformer une vulnérabilité théorique en démonstration concrète : récupérer une donnée qu'on ne devrait pas voir, contourner une authentification, passer d'un compte utilisateur à un compte admin.

Rassurez-vous : l'exploitation est maîtrisée. Le but est de produire une preuve (capture, requête, jeton), pas de faire tomber votre production ni d'exfiltrer les vraies données de vos clients. Un pentester travaille comme un chirurgien, pas comme un bulldozer.

Phase 6 — Post-exploitation

Une fois un premier accès obtenu, on évalue ce qu'un vrai attaquant pourrait en faire. La post-exploitation mesure l'impact métier réel : jusqu'où peut-on rebondir (mouvement latéral), peut-on escalader ses privilèges, à quelles données sensibles accède-t-on, pourrait-on maintenir un accès dans le temps ? C'est cette phase qui transforme une ligne « XSS détectée » en une phrase qui parle à un dirigeant : « un attaquant pouvait prendre le contrôle de tous les comptes ».

Phase 7 — Rapport et restitution

Le rapport de pentest est le livrable qui justifie toute la mission. Un bon rapport contient deux niveaux de lecture : une synthèse exécutive compréhensible par un dirigeant (niveau de risque global, enjeux métier), et un détail technique pour les développeurs (chaque vulnérabilité, sa criticité, la preuve, et surtout des recommandations de remédiation actionnables).

Vient ensuite la restitution : une réunion où le pentester présente les résultats, répond aux questions et priorise les corrections avec vos équipes. C'est le moment où le rapport prend vie. Un PDF de 80 pages déposé sans explication ne sert personne.

Phase 8 — Retest

Dernière étape, trop souvent zappée par les prestataires low-cost : le retest (ou contre-vérification). Une fois vos équipes ayant corrigé les vulnérabilités, le pentester revient vérifier que les correctifs tiennent vraiment la route — et qu'ils n'ont pas introduit de nouvelle faille au passage. Sans retest, vous n'avez aucune garantie que le problème est résolu.

Le déroulement en un tableau

Ce qu'on attend de vous (le client)

Un pentest se passe d'autant mieux que le client joue le jeu. Voici ce qui fait gagner du temps (donc de la couverture, donc de la valeur) :

• Le périmètre clair : la liste exacte des URLs, domaines et API à tester, et ceux à exclure.
• L'autorisation signée : par quelqu'un qui a le pouvoir de l'accorder (et l'accord de l'hébergeur si la prod est concernée).
• Des comptes de test : en whitebox, plusieurs comptes par rôle (utilisateur, admin) pour tester les contrôles d'accès. C'est ce qui distingue les deux approches — voir pentest whitebox.
• Un contact technique disponible : pour débloquer un accès, valider une fenêtre de tir ou confirmer qu'une alerte vient bien du pentest et pas d'un vrai attaquant.
• Un environnement adapté : idéalement une recette iso-prod, pour tester sans risque pour vos vraies données.

Combien de temps ça prend ?

Pour une application web standard, comptez généralement 5 à 10 jours ouvrés de test, plus quelques jours pour la rédaction du rapport. Le retest intervient ensuite, une fois vos correctifs déployés (souvent quelques semaines plus tard). Le déroulement complet s'étale donc sur quelques semaines, mais la mobilisation de vos équipes reste légère : cadrage au début, restitution à la fin, et un contact joignable entre les deux.

À retenir

Un test d'intrusion web suit un déroulement clair et balisé, conforme aux standards PTES et OWASP WSTG :

1. Cadrage et autorisation avant tout : pas de mandat, pas de test.
2. Reconnaissance et cartographie : comprendre la cible avant d'attaquer (oui, c'est surtout de la recon).
3. Découverte, exploitation, post-exploitation : trouver, prouver, mesurer l'impact réel.
4. Rapport, restitution, retest : documenter, expliquer, puis vérifier que c'est corrigé.

Rien de magique, donc : juste de la méthode, de la rigueur et un spécialiste qui pense comme un attaquant. Si vous êtes prêt à franchir le pas, découvrez nos missions de pentest web blackbox et pentest web whitebox — menées par un consultant certifié OSWE, méthodologie OWASP/PTES, et retest inclus. Et si la question du budget vous trotte dans la tête, l'article sur le prix d'un test d'intrusion vous attend.