Un rapport de pentest n’est pas un livrable, c’est une matière première. Celui dont il est question ici comptait 105 lignes ; au bout d’un trimestre, neuf avaient été traitées. Aucune difficulté technique n’était en cause. Voici les sept étapes qui ont inversé le ratio, dans l’ordre où elles doivent être appliquées.
Pourquoi un bon rapport ne produit rien
Le scénario est d’une régularité déprimante. L’audit est sérieux, le rapport est clair, la restitution se passe bien. Trois mois plus tard, on rouvre le document et presque rien n’a bougé.
Trois causes, toujours les mêmes. La longueur : une liste de cent lignes n’a pas de premier élément évident, donc elle n’est jamais commencée. L’ordre trompeur : le rapport classe par gravité technique, ce qui n’est pas l’ordre dans lequel il faut agir. Et l’absence de propriétaire : le rapport est adressé à une direction, les corrections relèvent de développeurs et d’administrateurs qui n’étaient pas dans la salle.
Aucune de ces causes n’est technique, et c’est pour cela qu’ajouter un outil ne les résout pas.
Étape 1 — Re-hiérarchiser sur votre exposition, pas sur le CVSS
La note CVSS mesure la dangerosité intrinsèque d’une faille. Elle est calculée sans rien savoir de votre architecture, et c’est normal : l’auditeur ne peut pas la remplir à votre place.
Reprenez donc chaque ligne et ajoutez deux colonnes. D’où cette ressource est-elle accessible ? Depuis Internet, depuis le réseau interne, depuis un poste d’administration seulement. Et que se passe-t-il concrètement si elle tombe ? Perte de données clients, arrêt de production, page vitrine défigurée.
Une faille notée 9,8 sur un service joignable uniquement depuis un réseau d’administration porte un risque réel inférieur à une faille notée 6,1 sur le formulaire public de demande de devis. Cette relecture prend une demi-journée pour une centaine de lignes, et elle change presque toujours la composition des dix premières.
Étape 2 — Regrouper par cause commune plutôt que par ligne
C’est l’étape qui produit le plus d’effet, et celle que personne ne fait spontanément parce que le rapport est structuré ligne par ligne.
Sur nos 105 lignes, il n’y avait que 19 causes distinctes. Onze lignes venaient d’une même bibliothèque obsolète. Sept venaient d’une absence d’en-têtes de sécurité sur un groupe de pages servi par la même configuration. Six venaient du même défaut de contrôle d’accès reproduit dans plusieurs contrôleurs.
Le passage de 105 tâches à 19 chantiers change tout, pour une raison psychologique autant que pratique : dix-neuf, c’est une liste qu’une équipe accepte de regarder. Et corriger une cause ferme plusieurs lignes d’un coup, ce qui produit un sentiment de progression que la correction ligne à ligne ne donne jamais.
Retour de terrain
Le regroupement a un effet secondaire que nous n’avions pas anticipé la première fois : il révèle des problèmes de pratique que le rapport ne nomme pas. Quand six lignes viennent du même défaut de contrôle d’accès reproduit dans six contrôleurs, le vrai sujet n’est pas les six contrôleurs, c’est qu’il n’existe pas d’endroit unique où ce contrôle est écrit. Corriger les six laisse le septième arriver au prochain développement. C’est la différence entre traiter un rapport et améliorer une base de code, et elle ne coûte pas plus cher — elle demande simplement d’avoir posé la question.
Étape 3 — Nommer un responsable par lot, pas un pilote global
Un pilote global existe presque toujours après un audit. Il tient le tableau de suivi, relance, fait le point. Il n’a jamais les mains dans le code.
Chaque lot doit porter un nom propre : la personne qui fera la modification, pas son responsable hiérarchique. C’est une différence qui paraît formelle et qui décide de l’issue. Un lot attribué à « l’équipe applicative » n’avance pas ; le même lot attribué à une personne identifiée avance, ou fait remonter explicitement qu’elle n’a pas le temps — ce qui est une information exploitable.
Prévoyez aussi le cas des lots sans propriétaire évident : un composant que plus personne ne maintient, un service hérité d’un prestataire parti. Ce sont ceux-là qui restent ouverts un an, et il vaut mieux les identifier au premier jour comme un problème d’organisation plutôt que de les laisser pourrir en bas d’un tableau.
Un rapport qui dort dans un tiroir ?
Nous reprenons votre dernier rapport de pentest, le regroupons par cause, le re-hiérarchisons sur votre exposition réelle et vous remettons un plan de remédiation daté et attribué.
Lance-toi — plan de remédiationÉtape 4 — Fixer trois délais par gravité, et les écrire
Trois délais suffisent, et leur valeur exacte importe moins que le fait qu’ils soient tenables. Nous utilisons : critique sous 15 jours, élevé sous 60 jours, moyen sous 6 mois.
La tentation est d’afficher des délais ambitieux — critique sous 48 heures, élevé sous 15 jours. C’est une erreur mécanique : un délai intenable est manqué dès le premier cas, et un délai manqué une fois cesse d’être un délai pour tout le monde. Il vaut infiniment mieux tenir un engagement modeste que rater un engagement exigeant.
Écrivez également la procédure de dépassement : qui est informé, et qui peut accorder un report. Sans elle, le dépassement se règle par le silence, et le tableau de suivi devient une fiction consultée par personne.
Étape 5 — Distinguer correction et atténuation
Corriger supprime la cause : mettre à jour le composant, réécrire la requête, ajouter le contrôle manquant. Atténuer rend l’exploitation impraticable sans toucher à la cause : restreindre l’accès réseau, ajouter une règle de filtrage devant l’application, désactiver la fonctionnalité concernée.
Les deux sont légitimes, et l’atténuation est souvent la bonne réponse immédiate quand la correction demande trois semaines de développement. Mais elles n’ont pas la même durée de vie : une atténuation tient tant que personne ne modifie la configuration qui la porte.
D’où la règle, sans exception : toute atténuation est inscrite au registre avec une date de correction réelle. Une atténuation sans date devient permanente par oubli, et dix-huit mois plus tard personne ne sait plus pourquoi cette règle de filtrage existe — ce qui garantit qu’elle sera supprimée lors du prochain ménage.
Étape 6 — Faire retester le périmètre qui compte
Retester l’intégralité d’un rapport de cent lignes coûte presque le prix de l’audit initial, pour un bénéfice nul sur les observations mineures.
Le périmètre utile couvre quatre catégories : les vulnérabilités critiques et élevées, celles dont la correction a demandé une modification de code, celles où vous avez retenu une atténuation plutôt qu’une correction, et celles dont la correction a été faite par une personne extérieure à l’équipe habituelle.
Sur nos accompagnements, environ un correctif sur sept ne passe pas le retest. La raison est presque toujours la même, et elle est instructive : le développeur a corrigé le point d’entrée exact décrit dans le rapport, sans traiter les deux autres appels qui présentaient le même défaut. C’est précisément ce que l’étape 2 cherche à éviter, et c’est pourquoi les deux étapes se répondent.
Étape 7 — Mesurer deux chiffres et accepter le reste par écrit
Deux indicateurs suffisent. Le délai médian entre la publication du rapport et la correction effective, par niveau de gravité — c’est le seul chiffre qui décrit votre capacité réelle à traiter un audit. Et le taux d’échec au retest, qui mesure la qualité des corrections plutôt que leur quantité.
Puis vient la partie que la plupart des organisations évitent : accepter formellement le reste. Une longue traîne d’observations mineures dont la correction coûte plus cher que le risque qu’elles portent doit être acceptée par écrit, avec un nom, une date et une échéance de réexamen.
Cette formalisation change la nature de la situation. Un risque accepté et documenté est une posture défendable devant un assureur, un client grand compte ou un auditeur de conformité. Un risque ignoré parce que la liste était trop longue ne l’est pas, et la différence entre les deux tient à une page de tableau.
Notre dossier s’est terminé à 88 lignes corrigées et 17 acceptées par écrit avec une date de réexamen à douze mois. Ce n’est pas cent sur cent, et c’est précisément l’objectif : viser cent produit neuf.
Retour de terrain
Un mot sur le retest, parce que c’est la ligne que les PME coupent en premier quand le budget serre. Un audit sans retest ne prouve rien : il vous dit ce qui n’allait pas à une date donnée, pas ce qui va aujourd’hui. Si l’arbitrage budgétaire est réellement contraint, il vaut mieux réduire le périmètre de l’audit initial et conserver le retest, plutôt que d’auditer largement et de ne jamais vérifier. Un périmètre restreint entièrement traité et vérifié vaut mieux qu’un périmètre large dont on ignore l’état réel — et c’est aussi, accessoirement, ce que regarde un auditeur de conformité.
Où cela s’inscrit dans un cadre de conformité
Pour les organisations soumises à NIS2, ce processus n’est pas une bonne pratique optionnelle : la capacité à traiter les vulnérabilités identifiées et à documenter les décisions est explicitement attendue. Le registre des acceptations formelles produit à l’étape 7 est exactement le document demandé lors d’une revue.
Ces questions rejoignent celles que se posent les équipes de développement sur la gestion de leurs dépendances, documentées côté écosystème open source, et les enjeux d’outillage traités côté automatisation en entreprise. Le point de départ côté périmètre reste notre page audit de périmètre NIS2, et notre grille de tarification d’un pentest pour PME détaille ce qu’il faut prévoir en amont, retest compris.
Questions fréquentes
Par quoi commencer quand un rapport de pentest contient plus de 100 vulnérabilités ?
Par une re-hiérarchisation faite chez vous, et surtout pas par le haut de la liste. Un rapport classe par gravité technique, c’est-à-dire par la note CVSS, qui mesure la dangerosité intrinsèque d’une faille sans rien savoir de votre exposition réelle. Une faille notée 9,8 sur un service accessible uniquement depuis un réseau d’administration interne représente un risque bien inférieur à une faille notée 6,1 sur votre formulaire public de demande de devis. Reprenez donc chaque ligne du rapport et ajoutez deux colonnes que l’auditeur ne pouvait pas remplir : d’où cette ressource est-elle accessible, et que se passe-t-il concrètement si elle tombe. Cette relecture prend une demi-journée pour une centaine de lignes et change presque toujours l’ordre des dix premières.
Faut-il tout corriger, et en combien de temps ?
Non, et vouloir tout corriger est la principale cause d’immobilisme après un audit. Un rapport contient trois populations : quelques vulnérabilités qui exigent une action rapide, un ensemble intermédiaire à traiter dans le trimestre, et une longue traîne d’observations mineures dont la correction coûte plus cher que le risque qu’elles portent. La décision utile consiste à accepter explicitement ce dernier lot, par écrit, avec une date de réexamen. Un risque accepté et documenté est une posture défendable ; un risque ignoré parce que la liste était trop longue ne l’est pas, et c’est exactement la différence que regarde un assureur ou un auditeur de conformité.
Quelle est la différence entre corriger et atténuer une vulnérabilité ?
Corriger supprime la cause, par exemple en mettant à jour un composant ou en réécrivant une requête. Atténuer rend l’exploitation impraticable sans toucher à la cause, par exemple en restreignant l’accès réseau au service concerné ou en ajoutant une règle de filtrage devant l’application. Les deux sont légitimes, mais elles n’ont pas la même durée de vie : une atténuation tient tant que personne ne modifie la configuration qui la porte, ce qui arrive plus souvent qu’on ne le croit. La règle que nous appliquons est simple : une atténuation est toujours accompagnée d’une date de correction réelle et d’une ligne dans le registre, sans quoi elle devient permanente par oubli et personne ne se souvient pourquoi la règle de filtrage existe.
Le retest est-il indispensable et sur quel périmètre ?
Il est indispensable, mais pas sur l’ensemble du rapport. Faire retester cent lignes coûte presque le prix de l’audit initial et n’apporte rien sur les observations mineures. Le périmètre utile couvre les vulnérabilités critiques et élevées, celles dont la correction a demandé une modification de code, et celles pour lesquelles vous avez retenu une atténuation plutôt qu’une correction — ces dernières étant les plus susceptibles d’avoir été mal comprises. Sur nos accompagnements, environ un correctif sur sept ne passe pas le retest, presque toujours pour la même raison : le développeur a corrigé le point d’entrée exact décrit dans le rapport et pas les deux autres appels qui présentaient le même défaut.
Combien de lignes de votre dernier rapport sont réellement fermées ?
Si vous ne pouvez pas répondre en une minute, le rapport n’est pas encore un plan. Nous le transformons en lots datés et attribués, avec le périmètre de retest défini.
Lance-toi