PREUVE / Feuillet de consultation

Retest de pentest : faire vérifier les corrections et chiffrer la reprise

Mis à jour le 1er octobre 2026

Définir ce que le contre-test prouve

Le retest vérifie des corrections sur des constats identifiés. Son périmètre doit être convenu dès le devis initial si la vente dépend d’une preuve de correction. Une nouvelle version livrée par vos développeurs ne signifie pas que toutes les anomalies ont disparu. Le cabinet doit retrouver les scénarios concernés, vérifier le comportement obtenu et indiquer ce qui reste ouvert. Le résultat concerne les corrections examinées, avec les conditions et limites de ce passage.

Un retest ne constitue pas automatiquement un nouveau pentest de toute l’application. Après une refonte des droits, une nouvelle API ou un changement majeur d’authentification, un examen plus large peut être nécessaire. Faites distinguer la vérification ciblée et l’extension d’audit. Cette distinction évite de présenter au client une attestation de correction comme une évaluation de fonctions qui n’ont jamais été examinées.

Contractualiser la fenêtre de reprise

Demandez combien de passages sont inclus et jusqu’à quelle échéance les correctifs peuvent être remis. Vérifiez la charge réservée et le mécanisme de chiffrage si la correction exige plusieurs itérations. Le cabinet ne peut pas confirmer une disponibilité permanente sans engagement précis. Votre planning doit intégrer le temps de développement, la validation interne, le déploiement sur l’environnement retenu et la production du document amendé.

Définissez un point de contact technique pour préparer les accès. Le compte d’audit initial peut avoir expiré ou ses droits peuvent avoir changé. Le retest doit conserver des rôles comparables lorsque l’objectif est de vérifier le même scénario. Si l’environnement diffère, notez la différence et son effet sur la conclusion. Un contrôle réussi sur une préproduction ne démontre pas, à lui seul, que le correctif a été déployé en production.

Préparer les preuves de correction

Pour chaque constat, votre équipe fournit l’identifiant, la version contenant le correctif, la fonction concernée et les tests internes réalisés. Ne transmettez pas de secrets dans un ticket ou un message commercial. Les explications doivent permettre au cabinet de comprendre le changement sans exposer de données clients. Une correction côté interface seulement peut laisser un problème côté API ; le scénario de vérification doit porter sur le contrôle réellement défaillant.

Les mesures compensatoires méritent un traitement distinct. Désactiver temporairement une fonction peut réduire une exposition sans corriger la cause. Le rapport amendé doit expliquer cette situation plutôt que déclarer simplement l’anomalie résolue. Le décideur côté éditeur et l’acheteur doivent pouvoir comprendre les conséquences sur l’usage prévu. Une date de correction future reste une prévision et ne doit pas figurer comme un résultat acquis.

Lire le document amendé

Conservez la référence du rapport initial. Le retest indique les constats revérifiés, la date, l’environnement et les nouveaux résultats. Les états peuvent différencier correction confirmée, correction partielle, non corrigé et non vérifiable. Faites préciser le sens de chaque état. Le terme « clôturé » peut désigner la fin administrative d’un ticket sans signifier que le défaut a été effectivement corrigé et testé.

Demandez au cabinet de conserver les réserves importantes dans la synthèse transmissible. Si un défaut ne peut pas être reproduit parce qu’une fonction est indisponible, la conclusion doit rester limitée. Un acheteur peut demander un nouveau passage après réactivation. Préparez ce cas dans votre contrat et votre planning plutôt que de promettre que le retest clôturera nécessairement la revue sécurité.

Exemple de correction partielle

Prenons un scénario fictif d’accès à un document d’une autre organisation. L’équipe corrige l’écran principal, mais l’export utilise un mécanisme distinct. Une revérification pertinente examine le chemin initial et les chemins associés convenus. Si l’export reste exposé, la correction ne doit pas être présentée comme complète. Cette illustration ne décrit aucune vulnérabilité réelle et ne fournit pas de procédure d’exploitation d’une cible.

Rattachez ensuite le résultat au dossier de vente : quelle pièce est attendue, par qui et à quelle date ? Le commercial ne diffuse que la version approuvée pour ce partage. Le CTO conserve les détails techniques dans le suivi de correction. Si le client impose l’absence de constats d’une certaine gravité, faites confirmer les critères avant de commander et prévoyez le traitement des anomalies découvertes pendant la mission.