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.

Les étapes d'un pentest web se suivent dans un ordre précis, et les connaître à l'avance retire l'essentiel de l'inconnu. La question du budget est traitée à part, dans l'article frère sur le prix d'un test d'intrusion. Ici, place à la méthodologie et au 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.

La méthodologie qu'on applique chez own2pwn s'appuie sur PTES pour le déroulement et sur l'OWASP WSTG pour la couverture technique. Concrètement, ça donne le parcours suivant.

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).

C'est une part du métier qu'on sous-estime de l'extérieur : 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. Bien menée, cette phase décide souvent du reste de la mission.

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".

Concrètement, un accès en base de données obtenu par une injection peut ouvrir la porte au serveur applicatif ; un compte utilisateur compromis peut, via un contrôle d'accès défaillant, devenir un compte administrateur ; un jeton de session volé peut donner accès aux données de tous les autres clients. La post-exploitation reste toujours bornée par le mandat : on démontre le chemin sans exfiltrer de vraies données ni pivoter vers des systèmes hors périmètre. L'objectif n'est pas d'aller le plus loin possible, mais de prouver jusqu'où une faille laisse aller, pour que la criticité affichée dans le rapport repose sur un impact démontré et non supposé.

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 les vulnérabilités corrigées par vos équipes, 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

Les huit phases se lisent d'un coup dans le tableau ci-dessous, chacune avec son objectif et le livrable concret qu'elle produit. C'est utile pour situer un devis : un prestataire sérieux vous dit à quelle phase correspond chaque jour facturé, et ce que vous récupérez à chaque étape. Une colonne mérite votre attention, la dernière : si un devis n'aboutit à aucun livrable de retest, il manque une phase, et la plus importante pour prouver que le problème est vraiment réglé.

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 pentest ne s'improvise pas : il suit une méthodologie reconnue (PTES, OWASP WSTG) qui garantit une couverture reproductible d'une année sur l'autre.
• La phase la plus importante est celle qu'on raconte le moins : le cadrage et son autorisation signée. Sans mandat, un test d'intrusion est juridiquement une attaque.
• Une grande partie de la valeur se joue en reconnaissance : un pentest, c'est surtout de la recon avant la moindre attaque.
• Ce qui distingue un vrai test d'un scan reformaté, c'est l'exploitation prouvée et la post-exploitation qui mesure l'impact métier réel, pas une liste de failles supposées.
• Un déroulement complet n'a de valeur que s'il se termine par un retest : une faille corrigée sur le papier ne compte que si on a vérifié qu'elle l'est vraiment.

Rien de magique, donc : de la méthode, de la rigueur et un spécialiste qui pense comme un attaquant. Si vous vous demandez en amont pourquoi et quand lancer une telle mission, on l'a posé dans le pentest en entreprise. Et si vous êtes prêt à franchir le pas, nos offres de pentest web blackbox et pentest web whitebox sont conduites par un consultant certifié OSWE, méthodologie OWASP/PTES, retest inclus. La question du budget, elle, attend dans le prix d'un test d'intrusion.

Questions fréquentes sur le déroulement d'un pentest