Vous cadrez votre premier test d’intrusion payant. Le déclencheur est presque toujours l’un de ces cinq : un questionnaire de sécurité client qui revient sans cesse, un cycle de preuves ISO 27001, SOC 2, DORA ou NIS 2, une demande du conseil, une revue post-incident, ou un prestataire dont la dernière mission a déçu et la décision discrète d’en changer. Quel que soit le déclencheur, le problème côté acheteur reste le même : la plupart des équipes ne savent pas ce qu’un test d’intrusion utile devrait produire.

Le marché est plein de prestataires qui livrent de longs rapports de bruit de scanner à faible gravité, passent à côté du chemin d’attaque qui compromet réellement l’activité, et ne retestent pas ce qu’ils recommandent de corriger. Ce guide parcourt les livrables qu’un test d’intrusion utile devrait produire, comment cadrer honnêtement, et comment distinguer les prestataires qui vous apportent la preuve du risque de ceux qui vous vendent un PDF. Écrit du point de vue de l’équipe qui mène la mission, pas de celle qui la vend.

Un test d’intrusion utile produit trois livrables, pas un seul rapport

La plupart des rapports de test d’intrusion sont écrits pour un seul public : l’ingénieur qui corrigera les constats. La direction de la sécurité, qui doit expliquer le risque, et l’équipe plateforme, qui doit planifier la remédiation, doivent extraire ce dont elles ont besoin d’un document qui n’a pas été rédigé pour elles. C’est à cette étape d’extraction que la valeur de la mission se perd.

Le Rapport technique est le livrable d’ingénierie. Il contient chaque constat, les étapes de reproduction, le périmètre affecté, le score CVSS accompagné du raisonnement sur l’impact métier, et les recommandations de remédiation. Le public est l’ingénieur qui reproduira le problème, écrira le correctif et le déploiera. La question à laquelle il répond : qu’est-ce qui est cassé, précisément, et comment le referme-t-on ?

La Synthèse exécutive des risques est le livrable de direction. Six à dix pages, sans jargon, sans tableau de constats. Le public est le RSSI, le sponsor au conseil, et tout auditeur ou évaluateur client qui lit la mission à distance. La question à laquelle elle répond : quel risque cette mission a-t-elle révélé, et qu’est-ce que l’entreprise doit décider ?

Le Plan d’action est le livrable d’exploitation. Il suit chaque constat critique et élevé à travers les états Ouvert → En cours → Corrigé → Retesté → Clôturé. Le public est l’équipe plateforme ou SRE qui pilote l’ordonnancement de la remédiation. La question à laquelle il répond : quels travaux séquençons-nous ensuite, et qui en est responsable ?

Nous détaillons la production de ces trois livrables sur la page méthodologie. Un seul livrable pour trois publics est l’échec de reporting le plus courant du marché : chaque public a besoin d’un niveau d’abstraction différent et d’une réponse à une question différente.

Le cycle de la mission — ce que chaque étape donne à voir côté acheteur

Une mission utile se déroule en six étapes, et chacune produit quelque chose : un document, une décision, un livrable. Si un prestataire comprime une étape ou la saute, le manque se voit dans le rapport.

1. Cadrage. Avant toute proposition, on devrait vous poser cinq questions : quel actif testons-nous, quel est le déclencheur de la mission, qu’est-ce qui est hors périmètre, quel est le calendrier, et qui lira chaque livrable. Un prestataire qui chiffre sans ces réponses tarife une supposition. Livrable : un document de cadrage que l’acheteur valide.

2. Pré-engagement. Les règles d’engagement (ROE) sont rédigées : autorisation, arbre de contacts, fenêtres de test, contrat d’escalade, règles de traitement des données. Votre service juridique les relit. Le test actif ne commence pas avant que les ROE soient signées des deux côtés. Livrable : des ROE signées.

3. Test actif. Le travail a lieu. Vous devriez recevoir un point quotidien ou un statut écrit pendant la fenêtre de test actif, y compris une note « aucun constat critique observé aujourd’hui » le cas échéant, pour que l’absence de nouvelles ne soit pas ambiguë. Les constats critiques sont escaladés sous quatre heures, hors de la cadence régulière. Livrable : des preuves de travail et des constats préliminaires.

4. Reporting. Les trois livrables — Rapport technique, Synthèse exécutive des risques, Plan d’action — sont rédigés, relus en interne par les pairs, puis présentés avec vous. La restitution est obligatoire, pas optionnelle. Livrable : les trois livrables, plus une restitution documentée.

5. Planification des actions. Chaque constat critique et élevé reçoit un responsable de remédiation, une date cible et une approche de vérification convenue avec votre équipe plateforme ou SRE. C’est une séance de travail, pas un courriel de passation. Livrable : un Plan d’action séquencé et assigné.

6. Clôture. Chaque constat critique et élevé est retesté après remédiation. Le Plan d’action fait passer chaque constat de Ouvert → En cours → Corrigé → Retesté → Clôturé. Un constat n’est pas certifié clos par le prestataire tant qu’il n’a pas été retesté. Livrable : une note de clôture qui liste l’état final de chaque constat.

Un cadrage comprimé ou une planification des actions sautée est le défaut de qualité le plus courant du marché — et le plus simple à détecter avant de signer le cahier des charges. Demandez le document de cadrage, le modèle de ROE et le modèle de Plan d’action avant que la proposition n’arrive. Un prestataire incapable de partager les trois vous vend un PDF.

Les étapes de reproduction ne sont pas optionnelles

Pour chaque constat, le rapport devrait contenir cinq éléments : les préconditions (état du système, rôle utilisateur ou contexte d’authentification requis), la requête ou la charge exacte utilisée pour déclencher le problème, la réponse attendue, la réponse observée, et l’hypothèse de remédiation. C’est le contrat de reproductibilité.

La raison n’a rien d’académique. Six mois après la clôture de la mission, un tiers — un auditeur, un régulateur au titre de DORA ou NIS 2, l’équipe de revue sécurité d’un client potentiel — lira le rapport sans le testeur d’origine. Si le constat ne peut pas être reproduit à partir du seul rapport, il ne peut pas être défendu.

Faites ce test sur n’importe quel rapport de test d’intrusion antérieur auquel vous avez accès : ouvrez les trois premiers constats critiques ou élevés, confiez-les à un ingénieur compétent de votre équipe, et demandez s’il peut reproduire le problème sans contacter le cabinet. Si la réponse est non pour l’un des trois, le rapport a un défaut de reproductibilité. Un constat sans étapes de reproduction est une opinion. Un constat avec étapes de reproduction est une preuve.

CVSS plus impact métier — pourquoi l’inflation de gravité est un défaut de qualité

CVSS v3.1 est la référence technique. Il note l’exploitabilité (vecteur d’attaque, complexité, privilèges requis, interaction utilisateur), la portée (le problème franchit-il une frontière de sécurité) et l’impact (confidentialité, intégrité, disponibilité). La sortie est un nombre entre 0,0 et 10,0, projeté sur des paliers nommés : faible, moyen, élevé, critique.

CVSS seul ne suffit pas. Un constat CVSS 7,5 sur une instance de test isolée n’est pas le même risque qu’un constat CVSS 7,5 sur le système de paiement en production. Même nombre, priorité différente. Un rapport utile applique une lecture par l’impact métier — criticité de l’actif, rayon d’impact, exploitabilité dans l’environnement réel de l’acheteur — et laisse cette lecture déplacer la priorité par rapport à ce que le seul palier CVSS suggérerait.

L’inflation de gravité est une tactique commerciale, pas un signal de sécurité. Les prestataires qui notent chaque injection SQL en critique sans tenir compte du contexte indiquent que la notation sert à justifier la facture, pas à prioriser la remédiation. Le même schéma apparaît chez les prestataires qui refusent de noter quoi que ce soit en faible — « si nous l’avons trouvé, c’est que ça compte » — ce qui gonfle la valeur apparente du rapport tout en cassant la capacité de votre équipe d’ingénierie à trier.

Le barème de notation que nous utilisons est publié. CVSS comme plancher technique, l’impact métier comme lecture de priorisation, le résultat documenté par constat pour que le raisonnement survive à une lecture isolée du rapport. Si chaque constat d’un rapport est critique ou élevé, la priorisation est cassée — et le rapport vous livre de l’alarme, pas des travaux hiérarchisés.

Ce qui se passe quand nous trouvons quelque chose qui ne peut pas attendre le rapport

Les constats critiques — chemins d’exploitation actifs vers la production, identifiants exposés, exécution de code à distance en direct, données sensibles exposées — sont signalés sous quatre heures après leur découverte, hors de la cadence régulière de reporting. Un appel téléphonique, un message chiffré au contact d’incident nommé dans les ROE, une confirmation écrite dans le même délai. Le travail se poursuit en parallèle de la réponse côté acheteur.

La raison du délai de quatre heures est opérationnelle. Un constat critique qui dort, non lu, dans un rapport préliminaire pendant trois semaines est un risque que l’acheteur paie. La découverte ne rend pas le problème plus sûr ; elle rend le silence plus risqué.

Posez la question à chaque prestataire : « Quel est votre délai d’engagement sur les constats critiques ? Est-il inscrit dans le cahier des charges ? » Si la réponse est vague, ou si l’engagement n’apparaît que dans la documentation commerciale et pas dans le contrat, le prestataire se réserve le droit d’enterrer les mauvaises nouvelles. Cet engagement a sa place dans le cahier des charges.

Les constats chaînés comptent plus que de longues listes de « moyens »

Un rapport piloté par scanner signale des constats isolés. Une divulgation d’information ici, un en-tête CORS mal configuré là, une dépendance obsolète plus loin. Chacun noté faible ou moyen sur CVSS, chacun noyé dans un long tableau. L’acheteur lit le tableau, conclut que le rapport est surtout du bruit, et la mission s’arrête là.

Un rapport utile fait autre chose : il vous montre comment les constats isolés se chaînent pour compromettre un actif métier réel, écrit sous forme de récit en paragraphes avec des étapes de reproduction pour chaque maillon de la chaîne.

Prenons une chaîne plausible. Une divulgation d’information dans le portail support fait fuiter le nom d’hôte de l’environnement de préproduction interne. Cette préproduction a une authentification faible contre laquelle la production a été corrigée il y a quatre mois, mais jamais la préproduction. Elle partage les secrets de production via ses variables d’environnement — une commodité héritée que personne n’a retirée. Depuis la préproduction, la réplique en lecture de la base de données de production est joignable sur le réseau interne. Quatre constats, chacun individuellement CVSS moyen ou inférieur ; ensemble, un chemin à impact métier critique qui exfiltre des données client sans toucher à l’application de production.

Les scanners ne font pas cela. Ils signalent les quatre constats individuellement et laissent l’acheteur relier les points. Relier les points est le travail de l’analyste : la part du test d’intrusion qui ne peut pas être automatisée, la part que l’acheteur paie réellement. Le même travail d’analyse vaut pour les missions web et API et les évaluations de sécurité cloud, où les chemins traversent souvent plusieurs services.

Une longue liste de « moyens » sans récit est un export de scanner. Une courte liste de chemins d’attaque avec étapes de reproduction est un test d’intrusion.

Pas de clôture sans nouveau test

Le Plan d’action fait passer chaque constat critique et élevé par cinq états : Ouvert → En cours → Corrigé → Retesté → Clôturé. Le prestataire ne certifie pas la clôture de sa propre autorité ; il la certifie après avoir retesté la remédiation dans le même environnement et selon les mêmes étapes de reproduction que celles qui ont produit le constat d’origine.

La raison en est que la remédiation est la part de la mission la plus sujette à l’échec silencieux. Un correctif qui compile et passe la suite de tests existante n’est pas nécessairement un correctif qui referme le chemin d’attaque. Sous la pression des échéances, les équipes d’ingénierie clôturent régulièrement un constat avec une atténuation partielle — une règle WAF qui bloque la charge précise du rapport, une validation d’entrée ponctuelle qui ne se généralise pas. Le nouveau test est la seule vérification que l’acheteur a bien obtenu le résultat de sécurité qu’il a payé.

Un prestataire qui émet un rapport final sans cycle de nouveau test, ou qui certifie la clôture sur la foi d’une capture d’écran du nouveau code fournie par l’acheteur, vous livre une mise en scène de conformité plutôt que de la sécurité. Demandez avant de signer : « Quel est votre processus de nouveau test ? Est-il inclus dans la mission, ou s’agit-il d’une ligne distincte que je dois autoriser après coup ? » La réponse détermine si la mission se clôt sur des résultats vérifiés ou sur un PDF.

Hors périmètre par conception — ce qu’un test d’intrusion n’est pas

Un test d’intrusion utile a des exclusions explicites, définies par écrit avant tout test actif. Ces contraintes existent parce que l’alternative — « testez tout, comme vous voulez » — fait peser une exposition juridique sur les deux parties, casse la discipline de périmètre et ne donne à l’acheteur aucun moyen d’évaluer le résultat.

Les exclusions standard sont concrètes. Pas de test de déni de service ou volumétrique contre la production. Pas de charges destructrices : pas de suppression de données, pas de chiffrement, aucune action qui modifie l’état de façon irréversible pour l’acheteur. Pas d’ingénierie sociale du personnel hors d’un périmètre écrit et convenu à l’avance (et jamais contre du personnel non informé au niveau de la direction). Pas de test de systèmes que l’acheteur ne possède pas — SaaS tiers, API partenaires, infrastructure exploitée par un hébergeur — même lorsque ces systèmes sont joignables depuis l’environnement concerné.

Le document de règles d’engagement consigne chaque exclusion, ainsi que les fenêtres de test, l’arbre d’autorisation, le contact d’incident, les règles de traitement des données et le contrat d’escalade. Il est signé par les deux parties avant tout test actif. Le sauter ne rend pas la mission plus rapide ; cela donne une mission sans aucune base juridique.

Un prestataire qui promet de « tout tester » sans ROE signées propose de prendre en charge votre responsabilité juridique et la sienne, sur une poignée de main. Ne signez pas cette mission. Les exclusions des ROE sont ce qui rend le reste du travail défendable.

Cinq questions à trancher avant d’émettre l’appel d’offres ou le cahier des charges

Traitez ceci comme la liste de cadrage côté acheteur. Si vous ne pouvez pas répondre aux cinq, vous n’êtes pas prêt à émettre l’appel d’offres — et tout prestataire qui chiffre malgré tout tarife une supposition.

1. Quel actif cherchez-vous réellement à tester ? Une seule application ou un portefeuille de services ? Testez-vous la surface d’attaque externe, le déplacement latéral interne, ou les deux ? Testez-vous la production, une préproduction équivalente à la production, ou une instance de test fraîchement provisionnée ? L’actif détermine le périmètre et le coût ; des réponses vagues ici signifient des réponses vagues partout ailleurs.

2. Quel est le déclencheur de la mission ? Questionnaire de sécurité client, audit, revue post-incident, lancement d’une nouvelle fonctionnalité, cycle de preuves ISO 27001, SOC 2, DORA ou NIS 2. Le déclencheur détermine qui lit le rapport, quels livrables sont nécessaires, et ce que la mission devra défendre six mois plus tard. Déclencheurs différents, périmètres différents.

3. Qu’est-ce qui est hors périmètre, et est-ce documenté ? Modification de la base de données de production. Déni de service. Ingénierie sociale hors d’une fenêtre convenue à l’avance. SaaS tiers que vous ne possédez pas. Si les exclusions ne vivent que dans la tête d’une seule personne de votre côté, elles n’existent pas en tant que contrat.

4. Quel est le calendrier ? Un calendrier comprimé produit un rapport piloté par scanner. Une mission honnête représente cinq à quinze jours ouvrés de test actif pour une application web type et son API ; les périmètres multi-services, d’infrastructure cloud ou de red team prennent plus de temps. Si le prestataire accepte un test d’intrusion de deux jours, ce que vous obtiendrez, c’est deux jours de scans.

5. Qui lira chaque livrable ? L’équipe d’ingénierie lit le Rapport technique. Le RSSI et le sponsor au conseil lisent la Synthèse exécutive des risques. L’équipe plateforme ou SRE pilote le Plan d’action. Si vous ne pouvez pas nommer la personne qui recevra chaque livrable, vous cadrez un PDF, pas une mission.

Si vous souhaitez de l’aide pour trancher ces cinq questions, demandez un échange de cadrage. La conversation est plus courte que le document ci-dessus.

En conclusion

Trois livrables, cinq questions de cadrage, un contrat de nouveau test. Voilà la forme d’une mission utile.

Chez HackingByte, nous menons les missions sous direction senior, avec des preuves de niveau reproduction, des récits de chemins d’attaque plutôt que des exports de scanner, et un cycle de nouveau test qui referme la boucle sur chaque constat critique et élevé. La page méthodologie détaille notre façon de travailler, du cadrage à la clôture. Si vous cadrez votre premier test d’intrusion payant ou remplacez un prestataire dont la dernière mission a déçu, le formulaire de contact est le chemin le plus court vers une conversation.

Pas de marketing par la peur, pas de statistiques anxiogènes, aucune certification que nous ne détenons pas. Juste le travail, fait sérieusement.