Rapport de pentest — ce qui le rend professionnel

La mission n'est pas finie quand le dernier exploit fonctionne. Elle est finie quand un directeur peut répéter votre conclusion en conseil, qu'un développeur peut corriger sans vous rappeler, et qu'un auditeur peut retracer chaque preuve. Le rapport est le livrable. Le reste est de la matière première.

Une liste de failles n'est pas un rapport

Un export Nessus, un dump sqlmap ou un dossier de captures ne se livrent pas. Sans remédiation par constat, sans preuve rejouable, sans ordre défendable, vous avez un inventaire. Le client a payé une décision.

Ce que vous saurez faire après cette leçon

• Nommer les six parties d'un rapport et ce que chacune empêche de mal comprendre.
• Écrire pour trois publics sans mélanger leurs langues.
• Remplir le gabarit d'un constat de façon identique d'une faille à l'autre.
• Trancher une priorité P1 à P4 à partir de l'impact métier, pas du seul score CVSS.
• Repérer les formulations qui font peur, qui mentent, ou qui ne se reproduisent pas.

---

1. Le rapport est le produit

Pendant dix modules, vous avez collecté : une fiche cible, des ports, des tickets CVE, une injection SQL, un jeton volé, un chemin BloodHound. Aucun de ces objets n'est lisible par la personne qui signe le chèque de remédiation.

Le rapport fait trois conversions, toujours les mêmes :

Matière brute	Ce que le rapport en fait	Ce que ça arrête
Sortie d'outil	Une preuve datée, recopiable	« On n'a pas compris ce que vous avez lancé. »
Score CVSS	Une priorité métier P1–P4	« Tout est critique, donc rien ne l'est. »
Exploit qui marche	Une action de correction testable	« Merci, on verra ça au prochain sprint. »

Un pentester qui « n'aime pas écrire » livre un travail inachevé. Le client n'achète pas votre Kali. Il achète une phrase qu'il peut défendre devant son conseil d'administration : voici le risque, voici le délai, voici le coût de ne rien faire.

---

2. Trois publics, trois lectures

Le même PDF circule. Il n'est pas lu de la même façon.

La direction lit deux pages. Elle veut la conclusion en tête, le nombre de P1, les trois risques qui menacent le chiffre d'affaires ou la conformité, et ce qu'il faut décider cette semaine. Elle ne veut ni UNION SELECT, ni CWE, ni le nom de sqlmap.

L'équipe technique ouvre les constats. Elle veut la requête exacte, la réponse observée, le fichier à changer, le test qui prouve que c'est fermé. Elle ignore le résumé si les fiches sont floues.

L'audit (interne, client final, assureur, ISO 27001) vérifie que vous êtes restés dans le RoE, que la méthode a un nom, que chaque preuve est datée, que les références existent. Il lit les annexes que personne d'autre n'ouvre.

Écrire le résumé en dernier

Le résumé exécutif se rédige après les constats classés. Sinon vous racontez l'histoire dans l'ordre de découverte — intéressant pour vous, illisible pour un directeur. La conclusion d'abord, le récit ensuite.

La règle de rédaction : une information n'apparaît qu'au niveau qui peut s'en servir. Le hash MD5 de admin@juice-sh.op va dans le constat et en annexe. Dans le résumé, on écrit : le compte d'administration de la boutique est récupérable depuis Internet, sans authentification.

---

3. La structure de référence — six parties, pas sept

Vous gardez exactement cet ordre. La lisibilité vient de la répétition, d'une mission à l'autre, d'un prestataire à l'autre.

3.1. Résumé exécutif — une à deux pages

Il tient debout seul. Un lecteur qui s'arrête à la page 2 doit pouvoir décider.

Contenu obligatoire :

1. Contexte en trois lignes — qui a commandé, quelle cible, quelles dates.
2. Conclusion en tête — posture insuffisante, acceptable avec réserves, ou maîtrisée. Un seul adjectif, justifié par les P1.
3. Comptage — combien de P1, P2, P3, P4.
4. Trois risques métier — phrases sans jargon, chacune liée à un constat numéroté.
5. Décisions de la semaine — rotation de secrets, fermeture d'un endpoint, mise hors ligne d'un admin oublié.

Ce qui n'y figure jamais : une liste d'outils, un tableau CVSS, une capture d'écran, une menace (« un attaquant russe pourrait… »). Vous documentez ce que vous avez fait, pas un scénario de film.

3.2. Périmètre et méthodologie

C'est le contrat relu après coup. Il protège le client (vous n'avez pas touché à ceci) et vous (on ne vous accuse pas d'avoir oublié cela).

Rubrique	Ce qu'on y met
Périmètre inclus	Domaines, IP, applications, comptes fournis.
Périmètre exclu	SaaS tiers, filiales, DoS, phishing si non autorisé.
RoE	Fenêtres, extraction limitée, interdiction de modifier des données.
Méthode	OWASP Testing Guide, PTES, ou le guide interne du client — un nom.
Outils	Liste courte, avec le rôle de chacun. Pas un CV Kali.
Limites	Ce que vous n'avez pas eu le temps ou le droit de tester.

Une limite écrite vaut mieux qu'une faille « oubliée » que le client découvrira six mois plus tard. « Les API authentifiées n'ont pas été testées : aucun compte n'a été fourni » est une phrase professionnelle.

3.3. Vue d'ensemble

Deux objets, pas un roman.

Carte de chaleur — constats croisés par thème et par priorité. Le regard tombe sur les cases sombres.

Thème	P1	P2	P3	P4
Applicatif	2	1	1	0
Identité	0	1	1	0
Réseau	0	0	1	1
Cloud	0	0	0	1

Indicateur de posture — une phrase, pas un score marketing. « Posture insuffisante : deux P1 sont exploitables depuis Internet sans compte. »

Un paragraphe d'attaque relie les constats : de la recherche publique à la session administrateur, puis aux commandes. C'est ici que le chemin vu en module 10 (mouvements latéraux) ou en module 7 (OWASP) devient une histoire métier. Pas dans le résumé.

3.4. Constats détaillés

Un constat par vulnérabilité et par surface. Deux injections SQL sur deux endpoints = deux fiches. La même injection vue par sqlmap et par Burp = une fiche, deux preuves.

Le gabarit est à la section 4. Vous ne l'inventez pas. Vous le remplissez.

3.5. Recommandations priorisées

Les constats disent quoi corriger ici. Ce chapitre dit dans quel ordre on assainit le système.

On regroupe par thème, pas par numéro de fiche :

• identité (mots de passe, MFA, comptes de service) ;
• applicatif (injections, contrôle d'accès, session) ;
• réseau (exposition, cloisonnement) ;
• cloud (rôles, secrets, stockage).

Un correctif structurel — toutes les requêtes SQL passent par des requêtes paramétrées — vaut mieux que six rustines copiées-collées. Le plan à 3, 6 et 12 mois se rédige ici ; l'atelier le met en page.

3.6. Annexes

Journaux, requêtes complètes, captures datées, exports d'outils. Le corps du rapport pointe vers l'annexe. Il ne la recopie pas.

Convention de nommage, dès le premier fichier :

C01-2026-04-18-recherche-union-select.png
C01-2026-04-18-req-search.txt
ANNEXE-A-nmap-10.10.10.0-24.txt

Une capture sans date et sans identifiant de constat ne prouve rien le jour où le client dit « ce n'était plus là ».

---

4. Le gabarit d'un constat — sept champs, toujours

Chaque constat suit exactement la même structure. Un lecteur technique doit pouvoir sauter de la fiche 2 à la fiche 6 sans chercher où est la preuve.

## C-01 — Injection SQL sur /api/recherche

- Sévérité : P1 — justification métier en une phrase
- Contexte : ce que la cible fait, en une phrase
- Preuve : requête, réponse, capture datée
- Impact métier : ce qu'un attaquant obtient concrètement
- Remédiation : action précise, test de clôture, effort
- Références : CWE, OWASP, document client

4.1. Titre court — action + surface

Le titre se lit dans une table des matières et dans un ticket Jira. Il commence par le verbe du défaut, pas par l'outil.

Illisible	Lisible
SQLi sqlmap critique !!!	Injection SQL sur /api/recherche
Problème auth	Absence de contrôle d'accès sur GET /api/commandes/{id}
CVE-2017-0144	Exécution de code à distance via SMBv1 sur SRV-FICHIERS

Pas de point d'exclamation. Pas de « critique » dans le titre : la priorité est un champ séparé.

4.2. Sévérité — P1 à P4, pas le chiffre seul

Le cours utilise quatre priorités de livraison. Le CVSS informe, il ne tranche pas.

Priorité	Délai indicatif	Critère qui compte
P1	24 heures à 7 jours	Compromission démontrée, ou données sensibles exposées sans authentification.
P2	30 à 90 jours	Exploitation réaliste, impact net, prérequis plus lourds (compte, réseau interne).
P3	3 à 6 mois	Durcissement, dette, chaîne d'attaque incomplète.
P4	Backlog	Informatif, version exposée sans exploit, bonne pratique.

Le CVSS 3.1 se calcule quand même. On l'écrit dans la fiche, avec le vecteur. On ajoute pourquoi on s'en écarte si la priorité métier diverge.

Exemple déjà vu au module 7 : une injection SQL non authentifiée qui rend le hash de l'administrateur vaut souvent 7,5 (confidentialité haute, intégrité nulle si vous n'avez fait que lire). C'est High, pas Critical. C'est malgré tout un P1 : le compte qui gouverne la boutique est tombé, depuis Internet, en une requête.

L'inverse existe. Un CVSS 9,8 sur un service isolé, sans donnée, filtré par un saut que vous n'avez pas franchi, peut retomber en P2 si le RoE vous a arrêté avant l'impact. Vous l'écrivez. Vous ne gonflez pas.

4.3. Contexte — une phrase sur la fonction

« /api/recherche alimente le catalogue public de la boutique, sans session. »

Cette phrase évite le dialogue suivant : le développeur croit que vous avez testé l'admin interne, le DSI croit que c'est le site vitrine. Le contexte ancre la surface dans le métier.

4.4. Preuve — rejouable, pas décorative

Une capture d'écran illustre. Elle ne suffit pas. La preuve minimale est la requête qui, recopiée, reproduit le résultat.

Trois formes acceptées, dans cet ordre de préférence :

1. un curl recopiable ;
2. une requête HTTP brute (Burp) ;
3. un pas-à-pas clavier si l'attaque est uniquement graphique.

La réponse observée figure à côté : code HTTP, extrait utile, pas les 200 Ko de JSON. Si le RoE limite l'extraction — --stop=3 au module 7 — vous le rappelez dans la preuve. Cela montre que vous avez choisi de ne pas vider la base.

4.5. Impact métier — ce qui change pour l'entreprise

L'impact n'est pas « perte de confidentialité ». C'est une phrase qu'un juriste ou un DSI peut citer.

Technique	Impact qui se défend
Dump de Users	Lecture des emails clients et du secret d'administration ; usurpation du back-office.
XSS stockée sur un avis	Vol de session d'un administrateur qui modère les avis.
DMARC en p=none	Un tiers envoie des messages qui semblent venir du domaine.
Partage SMB ouvert	Lecture de dossiers RH depuis le poste d'un stagiaire.

Vous restez sur ce que vous avez obtenu, pas sur ce qu'un attaquant « pourrait ensuite ». La chaîne suivante va dans la vue d'ensemble, pas dans chaque fiche.

Loi 25, RGPD, PCI-DSS : on les nomme seulement si les données touchées y sont soumises. Un hash d'administrateur de boutique d'essai n'est pas une « violation PCI ». Des emails de clients réels, si, et le rapport le dit.

4.6. Remédiation — une action, un test, un effort

Sans recommandation, la fiche est une dénonciation. La remédiation a trois qualités :

• Précise — requêtes paramétrées sur le paramètre q, pas « sécuriser l'application ».
• Testable — le curl du constat doit renvoyer une liste vide ou un 400, plus une ligne Users.
• Bornée — effort en jours-personnes, compétence (dev, ops, IdO), dépendance (fenêtre de prod).

Un WAF qui bloque UNION SELECT est une compensation. Il n'est pas la correction. Vous pouvez le recommander en attendant le correctif, vous ne le vendez pas comme la fermeture du P1.

4.7. Références

Type	Exemple	À quoi ça sert
CWE	CWE-89	Le développeur trouve le pattern de correction.
OWASP	A03:2021 Injection	Le RSSI aligne le constat sur son programme.
CVE	seulement s'il y en a une	Le patch vendeur a un identifiant.
Document client	« Politique de mots de passe v3 »	Vous montrez l'écart à leur règle.

Une injection maison n'a souvent pas de CVE. Inventer CVE-2024-XXXX est une faute. CWE + OWASP suffisent.

---

5. Prioriser : le CVSS informe, le métier tranche

Le module 5 l'a déjà dit : le score de base ignore votre client. Le rapport est l'endroit où cette phrase devient une décision.

Ce que vous calculez

• vecteur CVSS 3.1 (AV, AC, PR, UI, S, C, I, A) ;
• score de base ;
• éventuellement le score environnemental si le client a dit que la confidentialité de cette appli valait plus que sa disponibilité.

Ce que vous décidez

• présence sur Internet ou seulement en interne ;
• authentification requise ou non ;
• nature des données (compte admin, PII, secrets cloud) ;
• facilité : une ligne curl ou une chaîne de trois prérequis ;
• existence d'un exploit public (EPSS, catalogue KEV) — utile pour une CVE, inutile pour une SQLi artisanale.

Quatre écarts classiques, à écrire noir sur blanc dans la fiche :

Situation	CVSS typique	Priorité livrée	Pourquoi
SQLi publique, dump comptes	7,5	P1	Admin + emails, sans compte.
RCE théorique, service isolé	9,8	P2	Pas d'accès démontré aux données.
XSS réfléchie sur un outil interne	6,1	P3	Prérequis : compte et victime qui clique.
Bandeau Server: nginx/1.18.0	5,3	P4	Aucun exploit montré.

Ne pas faire peur pour vendre

« Un groupe criminel va vider votre caisse cette nuit » n'est pas un impact. C'est de la publicité. Vous écrivez ce que la preuve montre. Le client décide du budget. Si vous gonflez, le prochain rapport — le vôtre ou celui d'un confrère — ne sera plus cru.

---

6. Ce qui sépare un rapport amateur d'un rapport qui se paie

Quatre critères, repris de l'index de la semaine. Ils servent de grille mentale avant d'envoyer le PDF.

Une remédiation par constat. Chaque fiche se ferme par une action et un test. Les actions transverses vivent au chapitre recommandations, en plus, pas à la place.

Des preuves reproductibles. Un tiers — un développeur, un auditeur, vous dans six mois — rejoue le curl et voit la même classe de résultat. Les secrets réels se masquent (adm***@…, hash tronqué dans le corps, complet en annexe sous NDA).

Une hiérarchisation défendable. Le DSI peut présenter le P1 à la direction sans que vous soyez dans la pièce. Si vous ne savez pas justifier l'écart au CVSS en une phrase, la priorité est mauvaise.

Pas de menace implicite. On documente. On ne vend pas l'angoisse. On ne compare pas le client à « ce qu'on voit d'habitude chez les moins-disants » : vous n'êtes pas son concurrent.

S'y ajoutent trois habitudes de métier :

• Numérotation stable — C-01 ne change plus une fois le brouillon figé. Les tickets du client pointent dessus.
• Une voix — pas « on a trouvé » dans une fiche et « l'équipe offensive estime » dans la suivante.
• Faits au présent de constat, conseils à l'impératif — la requête retourne trois comptes ; paramétrez la requête.

---

7. Les confusions qui coûtent une semaine de réécriture

• Raconter la mission dans l'ordre chronologique. Le client n'a pas à revivre votre mardi soir. Il a à voir le pire d'abord.
• Fusionner deux surfaces dans une fiche. Incorrigible : le ticket ira au mauvais dépôt Git.
• Coller un export d'outil comme constat. sqlmap se trompe. Le module 7 l'a rappelé. La fiche cite l'outil en preuve secondaire, le curl en preuve primaire.
• Mettre le jargon dans le résumé. Vous perdez la direction à la phrase deux ; elle ne lira pas la suite.
• Oublier le RoE dans le PDF. Sans rappel des fenêtres et des interdits, un lecteur externe croit que vous avez tout testé.
• Promouvoir une version logicielle au rang de P2. Une version, sans exploit démontré, est un P4 ou une ligne de la vue d'ensemble.
• Écrire « critique » onze fois. Le mot se vide. P1, P2, P3, P4 suffisent.
• Livrer des données personnelles en clair dans le PDF envoyé par email. Le rapport ne doit pas devenir l'incident. Masquez, chiffrez le dépôt, respectez la clause d'extraction.

---

Ce qu'il faut retenir

Un rapport professionnel a six parties toujours dans le même ordre, et des constats toujours dans le même gabarit. Il parle à la direction, aux techniciens et à l'audit sans mélanger leurs phrases. La priorité se défend par l'impact métier ; le CVSS reste un vecteur dans la fiche, pas un verdict. Chaque constat porte une preuve rejouable et une remédiation testable. Sans cela, vous avez une liste. La leçon suivante prend les notes brutes d'une injection SQL du module 7 et les transforme, champ par champ, en fiche livrable.