Un test d’intrusion se juge sur son rapport. C’est le seul livrable, et c’est souvent le maillon faible : un export d’outil de scan reformaté, cent quarante pages, aucune priorisation, aucune preuve reproductible.
Voici ce qu’on est en droit d’attendre, ce qui doit vous alerter, et comment évaluer une prestation avant de la commander.
1. Une synthèse lisible par un non-technicien
Deux pages, en tête de document, compréhensibles par un directeur général. Elles répondent à trois questions : qu’est-ce qui a été testé, qu’est-ce qui a été trouvé, qu’est-ce qui doit être corrigé en premier.
Si la synthèse s’ouvre sur « une injection SQL a été identifiée sur le paramètre id de l’endpoint /api/v2/users », ce n’est pas une synthèse. C’est le premier constat technique déplacé en page 2.
Test simple : donnez la synthèse à quelqu’un qui n’est pas de la DSI. S’il ne peut pas dire, après lecture, si la situation est grave et ce qu’il faut décider, elle est à réécrire.
2. Le périmètre — et surtout ce qui n’a pas été testé
Un rapport honnête dit ce qu’il n’a pas couvert : environnements exclus, plages horaires imposées, comptes non fournis, tests d’indisponibilité écartés à la demande du client, applications hors périmètre contractuel.
Cette section protège les deux parties. Sans elle, un périmètre non testé devient, six mois plus tard, un périmètre supposé sûr — et c’est exactement là que se produit l’incident.
Elle doit aussi préciser la boîte : noire (aucune information), grise (comptes utilisateurs fournis), blanche (accès au code et à l’architecture). Un test en boîte noire sur cinq jours ne couvre pas ce que couvre un test en boîte blanche sur la même durée, et facturer les deux au même prix n’a pas de sens.
3. Une priorisation qui tient compte de votre contexte
C’est le point de rupture entre un bon et un mauvais rapport.
Le score CVSS — dans sa version 3.1, ou 4.0 publiée en 2023 par le FIRST — mesure la gravité intrinsèque d’une vulnérabilité. Il ne sait pas si la machine concernée est exposée sur Internet, si elle héberge vos données de paie, ou si elle est isolée dans un segment sans valeur.
Conséquence : une vulnérabilité notée 9,8 sur un serveur de recette isolé passe après une vulnérabilité notée 6,5 sur votre annuaire d’entreprise. Un rapport qui trie uniquement par score vous fait dépenser votre budget de remédiation sur les mauvais sujets.
Deux référentiels complémentaires méritent d’apparaître dans un rapport sérieux :
- Le catalogue KEV de la CISA (Known Exploited Vulnerabilities), qui recense les vulnérabilités effectivement exploitées dans la nature. Une CVE au KEV se corrige avant une CVE mieux notée mais jamais exploitée.
- L’EPSS (Exploit Prediction Scoring System), également porté par le FIRST, qui estime la probabilité d’exploitation à 30 jours.
Attendez donc une priorisation qui croise gravité technique, probabilité d’exploitation et valeur de l’actif — et qui explique le raisonnement.
4. Des preuves reproductibles
Pour chaque constat : la requête envoyée, la réponse obtenue, les conditions d’exploitation, les captures d’écran horodatées. Suffisamment pour que votre équipe reproduise le problème et vérifie le correctif sans rappeler l’auditeur.
Un constat sans preuve reproductible est ingérable : votre équipe ne peut ni le confirmer, ni démontrer qu’il est corrigé. Il restera ouvert dans votre plan d’action pendant deux ans.
5. Des recommandations applicables chez vous
« Appliquer les correctifs de sécurité » n’est pas une recommandation. « Mettre à jour la bibliothèque X en version Y ; à défaut, appliquer le contournement Z sur le reverse proxy en attendant la fenêtre de maintenance » en est une.
La différence tient à la connaissance de votre environnement. C’est aussi pourquoi un test mené sans aucun échange avec vos équipes produit un rapport générique : l’auditeur ne sait pas ce que vous pouvez déployer.
6. Un retest
Un test d’intrusion sans phase de contre-vérification après correction laisse sans réponse la seule question qui compte : est-ce réglé ?
Le retest doit être prévu au contrat, avec un délai (souvent 30 à 90 jours) et un périmètre limité aux constats corrigés. C’est aussi ce document que vous produirez à un client ou à un assureur.
Ce qui doit vous alerter
Un volume anormal de constats de faible gravité — bannières de version, en-têtes HTTP manquants, méthodes HTTP autorisées — noyant deux vulnérabilités sérieuses. Signature d’un scan automatisé peu retravaillé.
Aucun faux positif mentionné. Sur un périmètre réel, un auditeur écarte toujours des résultats d’outil. S’il n’en signale aucun, il ne les a probablement pas vérifiés.
Un rapport livré sans restitution orale. La réunion de restitution est le moment où les priorités se négocient avec vos contraintes réelles. Un PDF envoyé par mail transfère le travail d’interprétation chez vous.
Aucune méthodologie citée. Un prestataire sérieux s’appuie sur un référentiel reconnu — OWASP Testing Guide pour le web, PTES ou l’approche du référentiel PASSI de l’ANSSI pour les prestations d’audit qualifiées.
Ce que le test d’intrusion ne remplace pas
Il donne une photographie à un instant donné, sur un périmètre défini. Il ne remplace ni une gestion continue des vulnérabilités — exigée par la mesure 8.8 d’ISO/IEC 27002:2022 — ni un audit organisationnel.
Un client qui commande un pentest annuel et rien d’autre a une bonne photo et aucun processus.
Sources
- FIRST — CVSS (versions 3.1 et 4.0)
- FIRST — EPSS, Exploit Prediction Scoring System
- CISA — Known Exploited Vulnerabilities Catalog
- OWASP Web Security Testing Guide
- ISO/IEC 27002:2022, mesure 8.8 — gestion des vulnérabilités techniques
Aller plus loin
Nos missions offensives sont décrites sur la page test d’intrusion et ethical hacking. Si l’objectif dépasse un périmètre technique, l’audit 360 couvre aussi l’organisationnel et l’humain. Ces prestations se commandent au forfait, le périmètre étant descriptible à l’avance.