De la signature du devis au retest : le déroulement d'une mission pentest

Un pentest n'est pas un scan automatisé suivi d'un rapport PDF généré à la volée. C'est une mission structurée, avec des phases distinctes, des décisions à prendre ensemble, et un accompagnement qui continue bien après la remise du rapport.

Première étape : cadrer le périmètre

Avant de signer quoi que ce soit, un échange de 30 minutes permet de définir ce qui sera testé. Application web, API, infrastructure réseau, application mobile, le périmètre est précis. « Toute la sécurité de l'entreprise » n'est pas un périmètre : c'est une surface impossible à couvrir sérieusement en quelques jours.

Le devis fixe le périmètre exact, la durée, le type de boite (noire, grise ou blanche), les livrables attendus. Une fois signé, la phase de planification démarre.

J-7 : les tests d'accès avant le pentest

Une semaine avant le début du pentest, une vérification est réalisée : s'assurer que les accès définis dans le périmètre fonctionnent réellement. Comptes de test créés ? VPN configuré ? Environnement staging accessible depuis l'extérieur ?

Cette étape paraît anodine. Elle évite pourtant un scénario fréquent : le pentesteur démarre la mission, passe les premières heures à déboguer des problèmes d'accès, et perd une journée entière sur une mission à durée fixe, sans qu'une ligne de test ait été exécutée.

Boite noire, grise ou blanche ?

Le niveau d'information fourni au pentesteur change profondément la nature des tests.

Il n'y a pas de réponse universelle. Le bon choix dépend de ce que vous voulez tester, de la maturité de votre équipe, et du temps disponible. Un article dédié détaille ce choix selon votre contexte.

Le déroulement du pentest : chercher ce qui ne devrait pas exister

Un pentest n'a pas de guide étape par étape. On ne coche pas des cases dans un ordre défini. L'objectif est de trouver quelque chose qui ne devrait pas exister (une faille, une mauvaise configuration, un défaut de logique), sans savoir a priori si c'est là.

Le travail ressemble davantage à une enquête qu'à une procédure : observation du comportement de l'application, formulation d'hypothèses sur ce qui pourrait être mal implémenté, tests ciblés pour les confirmer ou les infirmer. Chaque découverte oriente les suivantes.

Les vulnérabilités les plus critiques sont rarement celles que les outils automatiques remontent. Elles sont dans la logique métier : des comportements que l'application n'était pas censée avoir, mais qui sont là parce que personne n'avait anticipé ce cas précis. Un attaquant, lui, l'imagine.

Tout ce qui est testé est documenté en temps réel : ce qui a été tenté, ce qui a été trouvé, comment.

La rédaction du rapport avec Cybreach Engine

Le rapport est rédigé pendant et après la mission à l'aide de Cybreach Engine, un outil développé en interne. Pour chaque vulnérabilité, la documentation comprend : description technique de la faille, preuve d'exploitation (requête brute, capture d'écran, résultat obtenu), niveau de criticité évalué dans le contexte réel (pas seulement un score CVSS théorique) et recommandation de correction concrète.

Le rapport final est structuré en deux parties : une synthèse exécutive pour les décideurs (ce qui a été trouvé, quel est le risque réel, quelles sont les priorités de correction) et le détail technique complet pour les équipes qui vont corriger.

La restitution : parcourir le rapport ensemble

Le rapport n'arrive pas par email sans explication. Une réunion de restitution est organisée, en visio ou en présentiel, pour parcourir les vulnérabilités les plus critiques, répondre aux questions, et s'assurer que les équipes techniques savent ce qu'elles doivent corriger, dans quel ordre, et pourquoi.

C'est souvent là que les vraies questions émergent : « est-ce que ça s'applique aussi à notre autre environnement ? », « on avait un WAF, pourquoi ça n'a pas bloqué ? ». Ce sont des questions utiles. Y répondre en direct, preuves sous les yeux, est plus efficace que des échanges par email.

3 mois d'accompagnement post-rapport

La remise du rapport n'est pas la fin de la mission. Pendant 3 mois, une disponibilité hebdomadaire est maintenue : un point court, en vidéo ou par message, pour répondre aux questions techniques qui émergent au moment de la correction.

Les développeurs ont des questions précises lors de la correction : « cette approche est-elle suffisante ? », « si je modifie ça, est-ce que ce cas est bien couvert ? ». Pouvoir répondre à ces questions en contexte évite les corrections partielles, exactement le type d'écueil décrit dans notre article sur le cookie de session accepté vide.