PREUVE / Feuillet de consultation

Rapport de pentest pour un client grand compte : les livrables utiles

Mis à jour le 1er octobre 2026

Partir du lecteur qui accepte la preuve

Un rapport de pentest utile au grand compte doit permettre à son équipe sécurité de comprendre ce qui a été évalué. Demandez au client qui examine le document et quels critères conditionnent son accord. Le nom du prestataire, la période du test, l’environnement et les limites de couverture peuvent compter autant que la liste des constats. Une direction commerciale ne doit pas promettre une validation sur la seule réception d’un fichier PDF.

Faites confirmer le format avant consultation : rapport complet sous confidentialité, synthèse expurgée, lettre de réalisation ou rapport amendé après retest. Ces documents n’apportent pas la même information. Une lettre peut attester qu’une mission a eu lieu sans présenter les résultats détaillés. Une synthèse peut suffire à une première revue, mais le client peut ensuite demander des précisions. Obtenez une réponse écrite plutôt que de choisir un format supposé universellement accepté.

Prévoir un dossier à plusieurs niveaux

Le rapport technique sert aux développeurs. Chaque constat devrait identifier la fonction concernée, les conditions nécessaires, l’impact observé et les éléments de reproduction autorisés. Les preuves doivent être adaptées à la sensibilité des données. La synthèse destinée à l’acheteur expose le périmètre, la méthode, les limites et l’état des corrections sans publier les détails qui faciliteraient une exploitation. Les deux versions doivent rester cohérentes dans leurs dates et dans les statuts des constats.

Le cabinet peut proposer une restitution orale pour expliquer les résultats. Convenez des participants et de la confidentialité de cet échange. Le commercial a besoin d’une formulation compréhensible du risque résiduel ; il n’a pas besoin d’accéder à tous les secrets techniques. Le CTO doit pouvoir poser des questions sur une preuve ambiguë. En cas de désaccord sur la criticité, consignez les arguments et la décision sans effacer l’observation initiale.

Documenter la couverture réelle

Le document doit rattacher ses conclusions à une version de l’application et aux accès fournis. Un test avec un seul rôle ne démontre pas la séparation de tous les privilèges. Une API absente du périmètre doit être mentionnée comme exclusion. Une fonctionnalité indisponible pendant l’audit doit être identifiée. L’acheteur peut alors juger la pertinence du rapport pour son usage plutôt que lire une formule générale de sécurité.

Demandez une matrice de couverture lorsque votre client utilise un référentiel technique. Elle peut rapprocher les exigences retenues, les vérifications effectuées et les limites. Un état « non testé » n’équivaut pas à « conforme ». Un résultat sans constat ne garantit pas l’absence de vulnérabilité. Le rapport décrit une évaluation bornée dans le temps et dans sa méthode. Une évolution majeure ultérieure peut réduire sa représentativité, même si la date du fichier reste récente.

Rendre les corrections lisibles

Prévoyez un registre avec un identifiant stable pour chaque anomalie. Après correction, le cabinet doit pouvoir rattacher sa vérification au constat initial. Distinguez les états : correction prévue, correction déployée, correction revérifiée, réserve maintenue. Une capture de ticket fermé par l’équipe interne ne remplace pas une revérification indépendante lorsqu’elle est demandée par l’acheteur. Le rapport amendé doit indiquer le contexte du retest et les limitations éventuelles.

La preuve commerciale doit conserver les réserves qui concernent l’usage du client. Si une anomalie n’est pas corrigée, indiquez la mesure compensatoire proposée et l’autorité qui accepte le risque côté éditeur. Le client décide de son propre accord ; cette décision ne peut pas être attribuée au cabinet. Évitez les expressions « application certifiée » ou « sécurité garantie » pour qualifier une mission de test qui n’a pas cette portée.

Organiser la diffusion

Avant de transmettre, vérifiez les droits de diffusion prévus au contrat du prestataire. Le rapport peut contenir des données sensibles et des informations sur l’architecture. Définissez les destinataires nommés, le canal de partage, la durée d’accès et la procédure de révocation. Une version expurgée doit conserver les éléments nécessaires à l’évaluation sans montrer des URL privées, des jetons, des données réelles ou des détails d’exploitation non utiles au décideur.

Créez un index du dossier avec le titre de chaque pièce, sa version et sa date. Le commercial utilise cet index pour transmettre la bonne version au bon interlocuteur. Si le client demande une traduction, précisez si elle couvre aussi le rapport de retest. La traçabilité de la diffusion évite qu’une ancienne synthèse circule après correction ou qu’un rapport détaillé arrive dans une messagerie collective sans contrôle des accès.