Rapport de Pentest : Guide Complet de Rédaction et d'Exploitation

Le rapport de test d'intrusion est le seul livrable qui survit à la mission. Les shells obtenus, les tickets Kerberos forgés et les captures d'écran de bases de données exfiltrées ne valent rien si le document final ne permet pas à l'organisation cliente de comprendre son exposition réelle, de prioriser ses correctifs et de démontrer sa diligence à un régulateur ou à un assureur. Pourtant, la qualité rédactionnelle reste le point faible de nombreuses prestations offensives : findings mal scorés, preuves non reproductibles, recommandations génériques copiées d'un référentiel, executive summary illisible pour un comité de direction. Ce guide détaille la structure d'un rapport professionnel, la méthode de scoring CVSS v3.1 appliquée à des cas concrets, les exigences de reproductibilité, la construction d'une feuille de route de remédiation priorisée, les spécificités des périmètres web, infrastructure et Active Directory, ainsi que les livrables complémentaires attendus dans un contexte réglementaire. Il s'adresse aux RSSI qui reçoivent ces rapports, aux consultants qui les rédigent et aux pentesters qui veulent transformer une campagne technique en levier de transformation de la sécurité.

Structure d'un rapport de pentest professionnel

Un rapport de test d'intrusion n'est pas un journal de bord chronologique. C'est un document à plusieurs niveaux de lecture, conçu pour que chaque partie prenante trouve l'information qui la concerne sans lire le reste. Cette contrainte impose une architecture stable, reproductible d'une mission à l'autre, que le client finit par connaître par cœur — ce qui est précisément l'objectif.

Les sept blocs canoniques

La trame retenue par la majorité des cabinets qualifiés s'articule autour de sept blocs. Le premier est la page de garde et le contrôle documentaire : titre de la mission, client, prestataire, version, date d'émission, niveau de classification, liste des destinataires nommés, historique des révisions. Un rapport de pentest est un document offensif : s'il fuite, il devient un plan d'attaque prêt à l'emploi. La mention « Diffusion restreinte » et un tableau de diffusion nominatif ne sont pas de la bureaucratie, ce sont des mesures de sécurité.

Vient ensuite le résumé exécutif, traité en détail plus bas. Le troisième bloc décrit le périmètre et les conditions d'exécution : adresses IP, noms de domaine, applications, comptes fournis, plages horaires autorisées, exclusions explicites (pas de déni de service, pas de social engineering, pas d'exploitation sur l'environnement de production). Ce bloc est juridiquement le plus important du rapport : il matérialise l'autorisation d'agir et délimite la responsabilité du prestataire.

Le quatrième bloc expose la méthodologie : référentiels appliqués, outillage, approche boîte noire, grise ou blanche, degré de connaissance initial. Le cinquième est la synthèse des vulnérabilités : un tableau unique, dense, qui liste tous les findings avec identifiant, criticité et statut. Le sixième constitue le cœur technique : les fiches de findings détaillées. Le septième regroupe les annexes : sorties d'outils brutes, listes complètes de ports, dumps de hachages anonymisés, scripts de vérification.

Numérotation et traçabilité

Chaque finding doit porter un identifiant stable de la forme PT-2026-042-WEB-03 (mission, périmètre, ordre). Cet identifiant sera repris dans le plan de remédiation du client, dans son outil de ticketing, dans le rapport de retest et parfois dans un dossier d'audit deux ans plus tard. Le renuméroter entre deux versions du rapport est une faute qui casse toute la chaîne de traçabilité. De la même manière, la criticité d'un finding ne doit jamais être revue à la baisse sans justification écrite dans l'historique des révisions.

Executive Summary : communiquer le risque au COMEX

L'executive summary est lu par des personnes qui ne liront rien d'autre. Deux pages maximum, aucun nom d'outil, aucun acronyme non explicité, aucun vecteur CVSS. La question à laquelle il répond n'est pas « quelles vulnérabilités avez-vous trouvées » mais « qu'est-ce qu'un attaquant peut faire à notre entreprise, en combien de temps, et qu'est-ce que cela nous coûterait ».

Raisonner en scénarios, pas en vulnérabilités

Un COMEX ne sait pas ce qu'est une injection SQL en second ordre. Il comprend parfaitement la phrase suivante : « En quatre heures, depuis Internet et sans aucun compte fourni, nous avons obtenu un accès administrateur à la base de données clients contenant 1,8 million d'enregistrements, dont les coordonnées bancaires de 240 000 abonnés. » Cette formulation est la bonne parce qu'elle nomme le temps, le point de départ, l'actif atteint et la volumétrie.

La bonne pratique consiste à construire trois à cinq chemins d'attaque nommés, chacun chaînant plusieurs findings techniques vers un impact métier. Un chemin typique : exposition d'une interface d'administration → identifiants par défaut → exécution de code → rebond vers le réseau interne → compromission du contrôleur de domaine → accès à l'ensemble des partages de fichiers. Chaque étape renvoie aux identifiants de findings correspondants, ce qui crée le pont entre la lecture direction et la lecture technique.

Le graphique unique

Un seul visuel dans l'executive summary : la répartition des findings par criticité, comparée si possible à la campagne précédente. Toute autre visualisation — matrice de risques, radar de maturité, heatmap par domaine — appartient aux livrables complémentaires. L'objectif est qu'un dirigeant retienne une information chiffrée, pas qu'il admire une infographie.

Enfin, l'executive summary doit contenune appréciation globale assumée : le niveau de sécurité du périmètre est insuffisant, perfectible ou satisfaisant au regard de l'état de l'art. Refuser de trancher est le défaut le plus fréquent des rapports rédigés par des consultants juniors. Le client paie aussi pour un avis d'expert.

Findings techniques : structuration et scoring CVSS v3.1

La fiche de finding est l'unité de travail du rapport. Elle doit être autoportante : un développeur qui reçoit uniquement cette page, extraite du document, doit pouvoir comprendre, reproduire et corriger.

Anatomie d'une fiche

Sept champs obligatoires : identifiant, titre factuel (« Injection SQL authentifiée sur le paramètre orderId de /api/v2/orders » et non « Faille critique dans l'API »), score et vecteur CVSS, description technique de la cause racine, preuve de concept reproductible, impact métier explicité, recommandation actionnable avec référence documentaire. On y ajoute utilement la classification CWE et le mapping vers le référentiel utilisé (OWASP Top 10, ATT&CK).

Scorer juste avec CVSS v3.1

Le CVSS n'est pas une note de risque, c'est une mesure de sévérité technique intrinsèque. Il ignore la valeur métier de l'actif, l'existence de compensations organisationnelles et la probabilité réelle d'exploitation. Le confondre avec une priorisation est l'erreur la plus répandue des deux côtés de la table. Le score de base se calcule sur huit métriques : vecteur d'accès (AV), complexité (AC), privilèges requis (PR), interaction utilisateur (UI), portée (S), et les trois impacts confidentialité, intégrité, disponibilité.

Le cas maximal, une exécution de code à distance non authentifiée avec compromission totale du système, se note CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, soit 9,8 — Critique. Chaque lettre se justifie : accès depuis le réseau, exploitation sans condition particulière, aucun privilège préalable, aucune action de la victime, portée limitée au composant vulnérable, et perte complète des trois propriétés. Dès qu'une seule métrique change, le score bascule : passer PR de N à L (un compte utilisateur standard suffit) fait chuter le score à 8,8.

Deux pièges méritent attention. La métrique Scope (S) passe à C uniquement quand l'exploitation affecte des ressources gérées par une autre autorité de sécurité que le composant vulnérable : c'est le cas d'un XSS qui compromet le navigateur de la victime, ou d'une évasion d'hyperviseur. Beaucoup de rapports abusent de S:C pour gonfler leurs scores. À l'inverse, la métrique AC ne passe à H que si l'attaquant doit remporter une condition de course ou collecter des informations préalables non triviales — pas parce que l'exploitation « demande des compétences ».

Preuves et reproductibilité : ce qu'il faut documenter

Une preuve de concept qui ne peut pas être rejouée par l'équipe interne n'est pas une preuve, c'est une affirmation. Le critère de qualité est simple : un administrateur système compétent mais non pentester doit pouvoir reproduire le finding en suivant la fiche, sans poser de question au prestataire.

Le contenu minimal d'une PoC

La requête complète, en texte sélectionnable et non en image : méthode, URI, en-têtes pertinents, corps. La réponse du serveur, tronquée intelligemment — les quinze lignes qui prouvent l'exploitation, pas les huit cents lignes de HTML. La commande exacte si un outil est utilisé, avec tous ses arguments. L'horodatage en UTC et l'adresse IP source de test : ces deux éléments permettent au client de retrouver les traces correspondantes dans ses journaux, et donc de mesurer sa capacité de détection.

Les captures d'écran restent nécessaires pour les vulnérabilités visuelles — un XSS qui s'exécute, un panneau d'administration accessible, une session usurpée. Elles doivent être annotées, recadrées sur l'information utile, et systématiquement expurgées des données réelles. Un rapport qui contient en clair les coordonnées bancaires découvertes pendant le test crée une violation de données dont le prestataire est responsable : caviarder au niveau du pixel, jamais par un simple rectangle noir superposé dans un PDF.

Documenter la détection, pas seulement l'exploitation

Un rapport mature indique, pour chaque étape significative, si l'action a déclenché une alerte. Cette information transforme le test d'intrusion en évaluation de la chaîne de détection et vaut souvent plus, pour un RSSI, que le finding lui-même. Lorsqu'un exercice de type red team est mené, cette dimension devient centrale et doit faire l'objet d'une chronologie dédiée en annexe.

Recommandations de remédiation : priorisation et feuille de route

« Mettre à jour le composant » et « appliquer les bonnes pratiques » ne sont pas des recommandations. Une recommandation utile précise la version cible, le paramètre exact, le fichier de configuration concerné, ou le contrôle applicatif à implémenter, et distingue toujours la mesure de contournement immédiate de la correction de fond.

Trois niveaux de réponse

Pour chaque finding significatif, le rapport propose une mesure d'urgence déployable en moins de 48 heures sans projet (règle de filtrage, désactivation d'une fonctionnalité, rotation de secret), une correction définitive qui traite la cause racine, et une mesure de prévention qui empêche la réapparition de la classe de défaut : revue de code obligatoire, règle SAST, durcissement du modèle de déploiement, formation ciblée.

Priorisation : au-delà du CVSS

La feuille de route ne suit pas l'ordre des scores CVSS. Elle croise la sévérité technique avec quatre facteurs : la criticité métier de l'actif, l'exposition réelle (Internet, interne, nécessitant un accès physique), l'existence d'un exploit public ou d'une exploitation active constatée, et le coût de la correction. Un finding à 6,5 sur un actif exposé et facilement corrigeable passe légitimement devant un 8,1 interne nécessitant un projet de refonte de six mois. Cette arbitration doit être visible dans le rapport sous forme de tableau à trois vagues — immédiat sous 15 jours, court terme sous 90 jours, structurel sur 6 à 12 mois — avec pour chaque ligne un propriétaire pressenti et une charge estimée en jours-homme. C'est cette section que le RSSI présentera pour obtenir son budget.

Rapport de pentest applicatif web vs infrastructure vs Active Directory

Les trois grands périmètres n'appellent ni la même méthodologie, ni la même structure de rapport, ni le même lecteur final.

Applicatif web et API

Le référentiel est le OWASP Web Security Testing Guide, complété par l'ASVS lorsque le client cherche un niveau de vérification formalisé. Le rapport s'organise par classe de vulnérabilité et par point d'entrée, et son destinataire opérationnel est l'équipe de développement : les recommandations doivent donc être formulées en termes de code et de configuration applicative, avec le langage et le framework réellement utilisés. Une matrice de couverture par test WSTG, en annexe, démontre l'exhaustivité de la démarche et évite le débat sur ce qui n'a pas été testé.

Infrastructure

Ici le rapport doit gérer la volumétrie : plusieurs centaines d'hôtes, des milliers de ports, des findings répétitifs. La règle est l'agrégation : un finding « TLS obsolète » porté par 180 serveurs constitue une seule fiche avec la liste des actifs en annexe, pas 180 fiches. Les référentiels de durcissement (CIS Benchmarks, guides de l'ANSSI) servent de base aux recommandations, et la segmentation réseau mérite systématiquement une section dédiée, cartographie à l'appui, car c'est de là que viennent les chemins de rebond.

Active Directory

Un rapport Active Directory ne se lit pas comme une liste de vulnérabilités mais comme un ensemble de chemins d'attaque. La structure naturelle part du compte initial fourni et remonte vers Domain Admins en décrivant chaque rebond : délégations non contraintes, ACL mal positionnées, comptes de service à mot de passe faible exposés au Kerberoasting, mots de passe dans les attributs de description, gabarits de certificats permissifs. Les graphes issus de l'analyse des relations d'objets sont indispensables mais doivent être retravaillés : une capture brute illisible de 4 000 nœuds n'apporte rien, un graphe de sept nœuds montrant le chemin le plus court vers l'administration du domaine est dévastateur en réunion. Les recommandations s'expriment en termes de modèle de tiering, de comptes protégés, de gestion des mots de passe de service et de réduction de la surface d'administration — rarement en correctifs à appliquer.

Livrables complémentaires : attestation de conformité, matrice de risques

Le rapport technique ne suffit plus. Les exigences contractuelles, assurantielles et réglementaires imposent une famille de documents satellites qu'il faut prévoir dès la proposition commerciale.

L'attestation de test d'intrusion

Document d'une à deux pages, sans détail technique exploitable, destiné à être transmis à des tiers : clients grands comptes, assureurs cyber, auditeurs. Il atteste qu'un test a été réalisé sur un périmètre décrit, à une date donnée, selon une méthodologie nommée, par un prestataire identifié — et, lorsque c'est le cas, qualifié PASSI par l'ANSSI. Il mentionne le nombre de findings par criticité et, après le retest, leur statut de correction. Il ne contient jamais de vecteur d'attaque. C'est ce document, et non le rapport complet, qui doit circuler à l'extérieur.

Matrice de risques et registre de suivi

La matrice de risques traduit les findings en risques au sens de la gestion des risques : événement redouté, source de menace, vraisemblance, gravité, niveau de risque brut, mesures existantes, niveau résiduel. Elle permet l'intégration dans le système de management de la sécurité et alimente directement les obligations d'analyse de risques portées par la directive NIS 2 ou par DORA pour le secteur financier. Le registre de suivi, lui, est un fichier vivant remis en format éditable : une ligne par finding, avec propriétaire, échéance, statut, preuve de correction attendue. C'est l'outil de travail de l'équipe sécurité pendant les six mois qui suivent la mission.

S'y ajoutent, selon les contextes, une présentation de restitution de quinze diapositives pour le comité, un jeu de règles de détection dérivées des techniques employées, et la liste des indicateurs de compromission générés pendant le test afin que le SOC puisse les distinguer d'une attaque réelle.

Exploitation par l'équipe sécurité : plan de remédiation et retests

Un rapport non exploité représente une dépense pure. Or la majorité des organisations traitent les findings critiques puis laissent dériver le reste jusqu'à la campagne suivante, qui redécouvre les mêmes défauts. La responsabilité du RSSI commence à la réception du document.

Industrialiser l'entrée dans le cycle de vie

Première étape, dans les cinq jours : convertir chaque finding en ticket dans l'outil de gestion existant, en conservant l'identifiant du rapport dans le titre, et affecter un propriétaire nommé — jamais une équipe. Deuxième étape : appliquer des délais de correction contractuels par criticité, formalisés dans une politique interne. Un cadencement courant retient 15 jours pour les critiques, 30 pour les élevées, 90 pour les moyennes et le traitement au fil de l'eau pour les faibles, avec une procédure d'acceptation formelle du risque, signée par le propriétaire métier, pour tout dépassement. Cette signature est ce qui transforme une dette technique silencieuse en décision de gestion assumée et documentée.

Cadrer le retest

Le retest n'est pas un nouveau test d'intrusion. Son périmètre se limite aux findings déclarés corrigés par le client, plus la vérification des régressions et des contournements évidents du correctif. Il doit être commandé en même temps que la mission initiale — négocier un retest six mois plus tard coûte plus cher et laisse les correctifs non vérifiés. Le livrable est un addendum qui reprend le tableau de synthèse avec trois statuts : corrigé, partiellement corrigé, non corrigé, chaque statut étant justifié par une preuve de vérification.

La pratique du contournement de correctif mérite une attention particulière : un tiers des corrections observées en retest traitent le symptôme signalé dans la preuve de concept et non la cause racine. Une injection corrigée par une liste noire de mots-clés, une IDOR corrigée sur un seul endpoint, un accès administrateur masqué par une redirection côté client — le pentester doit systématiquement chercher la variante.

Mesurer dans le temps

Trois indicateurs suffisent à piloter l'exploitation du rapport : le délai moyen de correction par criticité, le taux de findings récurrents d'une campagne à l'autre, et la part de findings détectés par la chaîne de supervision pendant le test. Le deuxième est le plus révélateur : un taux de récurrence supérieur à 20 % signale un problème de processus, pas de technique, et doit orienter l'effort vers l'intégration de la sécurité dans le cycle de développement plutôt que vers de nouvelles campagnes offensives. Enfin, la programmation des tests doit suivre le rythme des changements majeurs plutôt qu'un calendrier annuel arbitraire, en s'appuyant sur les méthodologies d'exécution reconnues comme le Penetration Testing Execution Standard pour garantir la comparabilité entre deux campagnes.

Questions fréquentes

Combien de temps faut-il consacrer à la rédaction d'un rapport de pentest ?

La règle empirique retenue par les cabinets matures est de 25 à 30 % de la charge totale de la mission. Une mission de dix jours d'exécution technique implique donc trois jours de rédaction, relecture et restitution. Compresser cette phase est la fausse économie classique : elle dégrade le seul livrable que le client conservera, et génère des allers-retours de clarification qui coûtent plus que le temps économisé.

Faut-il utiliser le CVSS ou un système de criticité propriétaire ?

Les deux, mais sans les confondre. Le CVSS v3.1 apporte la comparabilité, l'auditabilité et un langage commun avec les bases de vulnérabilités publiques. Une criticité contextualisée — recalculée en intégrant la valeur de l'actif et l'exposition réelle — apporte la pertinence opérationnelle. Le rapport affiche les deux colonnes côte à côte et explique la méthode de pondération. Afficher uniquement une note propriétaire non documentée est un signal de faible maturité du prestataire.

Le rapport doit-il être rédigé en français ou en anglais ?

Le corps du rapport, et impérativement l'executive summary, dans la langue de travail du comité de direction destinataire. La terminologie technique reste en anglais lorsqu'il n'existe pas d'équivalent établi, avec une première occurrence explicitée. Pour un groupe international, le schéma le plus efficace est un rapport technique en anglais et un résumé exécutif traduit dans la langue de chaque entité concernée.

Qui doit avoir accès au rapport complet au sein de l'organisation ?

Une liste nominative, courte et tracée : RSSI, direction des systèmes d'information, responsables techniques des actifs concernés, et le cas échéant le délégué à la protection des données. Le document doit être stocké chiffré, avec une durée de conservation définie, et retiré des espaces de partage collaboratif ouverts. Pour toute demande externe — client, assureur, auditeur — c'est l'attestation qui circule, jamais le rapport détaillé.