PREUVE / Feuillet de consultation

Après le pentest : prioriser les corrections avant le retest

Mis à jour le 1er octobre 2026

Transformer le rapport en travaux assignés

Après le pentest, chaque constat doit devenir une décision suivie. Créez une tâche avec l’identifiant du rapport, la fonction, le responsable, le traitement retenu et les critères de vérification. Une copie intégrale du détail sensible dans un outil largement partagé n’est pas nécessaire. Conservez les preuves techniques dans un espace restreint et donnez aux développeurs l’accès adapté. Le commercial suit les jalons sans recevoir les éléments permettant l’exploitation.

La première lecture doit clarifier les constats ambigus avec le cabinet. Une mauvaise compréhension de la cause peut produire un correctif qui traite seulement le symptôme. Demandez quelles conditions ont permis l’observation et quels chemins associés doivent être considérés. La restitution peut aider à relier le défaut à la logique métier. Le plan de correction doit rester distinct du résultat déjà démontré.

Prioriser selon le risque du SaaS

La gravité proposée par le cabinet est un point de départ. Examinez l’exposition, les droits nécessaires, les données concernées et l’impact sur les usages du client. Un défaut de séparation entre organisations peut avoir une portée différente d’un problème sur un écran interne très restreint. Les décisions doivent être documentées, surtout lorsqu’un traitement est différé. Ne réduisez pas la priorité à une note isolée sans contexte.

Lorsque plusieurs constats partagent une cause, une correction du composant commun peut être préférable à des modifications locales répétées. Identifiez cependant les effets sur les autres fonctions. Une règle d’autorisation modifiée peut bloquer un parcours légitime ou laisser une API différente inchangée. Votre recette interne doit couvrir le comportement attendu et le refus des opérations non autorisées selon la matrice de droits.

Distinguer correction et compensation

Une correction traite la cause du défaut. Une mesure compensatoire réduit un risque dans certaines conditions, par exemple en désactivant un chemin ou en limitant un accès. Le cabinet et le décideur interne doivent comprendre cette différence. La synthèse client ne doit pas annoncer comme corrigée une anomalie seulement contournée. Décrivez la mesure, ses limites et la décision de risque lorsqu’elle reste temporaire.

Une date cible de correction n’est pas un résultat. Si la vente dépend d’un état vérifié, réservez la capacité nécessaire au développement puis au retest. Le commercial explique le calendrier conditionnel au client. Les responsabilités et échéances doivent être explicites dans le suivi. Lorsque le risque justifie un traitement urgent, coordonnez la décision avec l’exploitation plutôt que de livrer un changement non préparé.

Préparer le passage de vérification

La fiche remise au cabinet indique le constat, la version du correctif, l’environnement et les tests internes réalisés. Les accès doivent être prêts et cohérents avec le scénario initial. Si l’architecture a changé, demandez si un retest ciblé suffit. Une modification large peut exiger une extension d’audit. Le devis et les règles d’engagement déterminent les conditions de cette reprise.

Conservez les différences entre préproduction et production. Un correctif vérifié sur un environnement doit ensuite être suivi lors de son déploiement. Le rapport de retest précise ce qui a réellement été observé. Un compte indisponible ou une fonction désactivée peut empêcher la vérification ; le statut doit rester explicite. Le ticket ne devient pas « confirmé » uniquement parce que le déploiement a été annoncé.

Mettre à jour le dossier de vente

La synthèse amendée rattache les résultats aux identifiants initiaux et conserve les réserves utiles. Le commercial transmet la version approuvée, selon les droits de diffusion. Informez les destinataires si une ancienne pièce est remplacée. Le grand compte examine le risque et son propre critère d’acceptation ; le cabinet ne peut pas garantir sa décision sur la seule base de la clôture interne des tâches.

Après l’audit, utilisez les causes observées pour améliorer vos critères de développement et de recette. Une correction ponctuelle ne démontre pas la sécurité de toutes les futures versions. Repérez les changements qui demandent une nouvelle analyse : droits, intégrations, API ou organisation des données. Le suivi des constats reste un dossier technique vivant, avec des responsables et des preuves datées.