Plan de remédiation : structurer la correction après un audit ou
un pentest

On répète qu'un audit ou un pentest "réduit le risque". À la lettre, c'est faux : un pentest ne réduit rien. Il produit un rapport, une liste de findings numérotés du critique au faible. Le risque, lui, ne baisse qu'au moment où quelqu'un corrige, dans le bon ordre, et prouve que la faille est refermée. Entre les deux, il y a ce moment de flottement où le développeur veut attaquer le bug qu'il comprend, le RSSI fixe les vignettes rouges et le chef de projet compte les jours qu'il n'a pas. Ce moment a un remède, et un nom : le plan de remédiation.

Un plan de remédiation, c'est ce qui sépare un rapport rangé dans un dossier partagé d'un risque réellement réduit. Ce n'est pas la liste des failles : c'est la décision, écrite, de quoi corriger, dans quel ordre, par qui et avec quelle preuve que c'est refermé. Autrement dit, la remédiation informatiqueest le maillon qui donne enfin une valeur à tout l'argent dépensé dans l'audit. Encore faut-il que ce plan de remédiation informatiquetienne sous la charge du quotidien, là où la liste brute, elle, reste inerte.

Pourquoi la liste brute de vulnérabilités ne suffit pas

Un rapport classe les findings par gravité, et c'est déjà utile. Mais la gravité affichée, le plus souvent un score CVSS, répond à une seule question : quel dégât si la faille est exploitée. Elle ne dit rien de l'effort de correction, rien de la cause commune à plusieurs entrées, rien de qui doit tenir le clavier. Trier un rapport du plus rouge au plus vert et attaquer dans cet ordre, c'est confondre un inventaire avec un plan.

Le piège est concret. Trois findings notés "critique" peuvent venir d'une seule bibliothèque obsolète : une mise à jour les referme tous les trois d'un coup. À l'inverse, un finding "moyen" isolé, posé sur votre portail client exposé sur Internet, mérite parfois de passer devant un critique enfoui dans un environnement de test que personne ne joint. La liste brute ignore ces deux réalités : elle ne regroupe pas les causes, et elle ne connaît pas votre contexte. C'est le travail du plan de le rétablir.

Il y a aussi une raison d'échelle. Un pentest bien mené remonte quelques dizaines de findings ciblés, mais dès qu'un scanner entre dans la boucle, le volume explose. Ce sujet du bruit et de la priorisation à grande échelle dépasse le seul rapport : il relève de la gestion des vulnérabilités comme processus continu ; le plan de remédiation, lui, se déclenche rapport par rapport.

Ce qu'est vraiment un plan de remédiation

Un plan de remédiation est un document vivant qui prend chaque finding et lui attache quatre choses : une priorité issue du risque réel, un responsable nommé, un délai tenu par un SLA, et un mode de vérification. Rien de plus, rien de moins. Ce n'est ni un tableau de bord sophistiqué, ni un outil à six chiffres : un tableur bien tenu remplit déjà la fonction le premier jour.

La méthode tient en cinq gestes qui s'enchaînent. On priorise sur le risque réel, pas sur le score brut. On regroupe les findings par cause racine. On assigne un responsable et un délai à chaque lot. On suit l'avancement. Et on vérifie, par un retest, que la faille a bien disparu. Le dernier geste reboucle sur le premier : un retest qui échoue rouvre une priorité.

Prioriser : la criticité réelle, pas le CVSS brut

C'est le geste qui décide de tout le reste, et le plus souvent bâclé. Un CVSS élevé attire l'œil, mais il mesure un dégât potentiel dans l'absolu. La criticité réelle, elle, se lit sur votre système à vous. Quatre questions la déterminent, et aucune ne figure dans le score du rapport.

• L'exploitabilité. Le rapport prouve-t-il la faille, ou la suppose-t-il depuis une bannière de version ? Un finding démontré par le pentester, capture à l'appui, pèse plus lourd qu'une signature incertaine. Un existe déjà, l'autre est une hypothèse.
• L'exposition. L'actif touché est-il joignable depuis Internet ou enfoui dans un VLAN interne ? Une faille moyenne sur une surface exposée bat une faille critique sur un service que personne n'atteint de l'extérieur.
• La valeur métier de l'actif. Le serveur porte-t-il des données clients, une brique de paiement, un secret d'authentification ? Le même bug n'a pas le même coût selon ce qu'il met en jeu derrière.
• L'effort de correction. Souvent oublié, pourtant décisif. Un correctif d'une heure qui ferme un risque moyen mérite parfois de passer avant un chantier de deux semaines sur un critique isolé. On cherche le meilleur rapport risque écarté sur effort consenti.

En croisant ces facteurs, on obtient une file de priorités bien plus juste que le tri par score décroissant. Une règle simple, codée dans un tableur avant tout outil, suffit à démarrer :

MATRICE DE PRIORISATION : plan de remediation

                    EXPOSE / actif critique     INTERNE / actif secondaire
                  +---------------------------+---------------------------+
  Exploitabilite  |                           |                           |
  PROUVEE (PoC)   |   P0  -> sous 72 h        |   P1  -> sous 2 semaines  |
                  +---------------------------+---------------------------+
  Exploitabilite  |                           |                           |
  SUPPOSEE        |   P1  -> sous 2 semaines  |   P2  -> cycle patch      |
                  +---------------------------+---------------------------+

  Regle : l'exposition ET la preuve montent la priorite.
          Un CVSS 9 "suppose / interne" reste un P2, pas un P0.

Regrouper par causes racines

Une fois la file ordonnée, on résiste à l'envie de traiter les findings un par un dans l'ordre du rapport. Beaucoup partagent une cause racine commune, et corriger la cause referme plusieurs symptômes d'un seul geste. Cinq entrées "injection" sur cinq formulaires différents pointent souvent vers une même absence de validation centralisée : un seul correctif d'architecture, cinq findings clos.

Corriger le symptôme sans remonter à la cause est l'erreur qui fait revenir les mêmes vulnérabilités au pentest suivant. On échappe un paramètre sur la page qui a levé l'alerte, on oublie les douze autres pages qui utilisent le même code non protégé. Le regroupement par cause force la bonne question : pourquoi cette faille existe-t-elle, et où ailleurs le même pattern se cache-t-il ?

Assigner : responsables et SLA par criticité

Un finding sans propriétaire ne sera jamais corrigé. C'est la loi la plus fiable de la remédiation. Chaque lot de correction reçoit donc un responsable nommé, une personne, pas une équipe floue, et un délai contractuel calé sur sa priorité. Le SLA transforme une bonne intention en engagement mesurable, et donne un critère net d'escalade quand la date approche.

Les délais se calent sur les niveaux de priorité définis plus haut. Un exemple de grille de départ, à ajuster selon vos moyens réels de patch :

• P0, sous 72 heures. Exploitable et exposé, l'archétype étant une RCE pré-authentifiée comme wp2shell. On mobilise, au besoin on pose une mesure de contournement immédiate (règle WAF, coupure du service) en attendant le correctif de fond.
• P1, sous deux semaines. Sérieux mais pas en feu : le lot entre dans le prochain sprint avec une date ferme.
• P2, cycle de patch courant. On corrige au rythme normal des mises à jour, sans mobilisation exceptionnelle.

Suivre et vérifier : le retest n'est pas optionnel

Un correctif déployé n'est pas un correctif prouvé. Tant qu'on n'a pas rejoué l'attaque qui avait fonctionné, la faille est présuméefermée, ce qui ne vaut rien dans un rapport d'audit ou face à un régulateur. La vérification, le retest, est la condition de clôture d'un ticket, pas un bonus qu'on s'offre quand il reste du temps.

Le retest a une vertu que le développeur qui a patché ne peut pas garantir seul : il rejoue exactement le chemin d'exploitation d'origine et confirme qu'il est mort. Il attrape aussi les corrections partielles, celles qui ferment la porte principale en laissant une fenêtre ouverte à côté. C'est pour cette raison qu'un bon rapport de pentest inclut presque toujours un retest dans sa prestation : sans lui, la boucle n'est jamais réellement bouclée. Ce point pèse d'ailleurs dans le prix d'un test d'intrusion et mérite d'être vérifié au devis.

Les pièges qui font échouer un plan de remédiation

Trois erreurs reviennent sur presque tous les plans qui déraillent, et les connaître suffit souvent à les éviter.

La première, c'est de tout traiter en même temps. Face à quarante findings, l'équipe se disperse, avance de dix pour cent sur chacun, et n'en clôt aucun avant la fin du trimestre. Un plan sert justement à refuser cette dispersion : on finit les P0 avant d'ouvrir les P1, on clôt des lots entiers plutôt que d'entamer tout le front. Un finding corrigé et vérifié vaut mieux que dix findings à moitié traités.

La deuxième, déjà croisée, c'est de corriger le symptôme et pas la cause. On patche la page qui a levé l'alerte, on laisse intact le code partagé qui reproduit le défaut ailleurs. Le pentest suivant remonte les mêmes classes de failles, et la confiance dans le processus s'érode. Le regroupement par cause racine est l'antidote. Quand la cause est diffuse, un test mené avec accès au dépôt aide à en mesurer l'étendue : un pentest avec accès au code source remonte tous les appelants du helper fautif, là où un test externe n'en voit qu'un seul, celui qui répondait sur une URL.

La troisième, la plus silencieuse, c'est l'absence de retest. On marque un ticket "résolu" sur la foi d'un commit, sans jamais rejouer l'attaque. Six mois plus tard, un incident révèle que le correctif n'en était pas un, ou qu'une régression l'a annulé. Sans vérification, le plan raconte une histoire de sécurité qui n'a pas été confrontée au réel.

Faire durer : du plan ponctuel au processus continu

Un plan de remédiation se déclenche à chaque rapport, mais les organisations matures le branchent sur quelque chose de permanent. La priorisation repose sur une donnée que peu maîtrisent vraiment : qu'est-ce qui est réellement exposé, aujourd'hui, sur Internet ? Un actif oublié, une préproduction ouverte par erreur, un sous-domaine hérité d'une acquisition changent la criticité d'un finding du tout au tout. C'est là que l'EASM alimente en continu la couche exposition : il tient à jour la carte de ce qui est joignable, pour que chaque nouveau plan parte d'une réalité fraîche plutôt que d'un inventaire périmé.

Répété à chaque audit, mesuré par quelques métriques simples (délai moyen de remédiation par criticité, âge des findings ouverts, part de retests réussis), le plan ponctuel devient un vrai cycle. C'est exactement ce que décrit notre guide sur la gestion des vulnérabilités de bout en bout : le plan de remédiation en est le geste concret, celui qu'on refait, discipliné, à chaque rapport.

À retenir

• Un plan de remédiation transforme une liste brute de findings en file de correction priorisée, assignée, datée et vérifiée. La liste seule ne réduit aucun risque.
• On priorise sur la criticité réelle (exploitabilité, exposition, valeur métier, effort), pas sur le CVSS brut. Le score ouvre la réflexion, il ne la tranche pas.
• On regroupe par causes racines : corriger la cause referme plusieurs symptômes et empêche les mêmes failles de revenir au pentest suivant.
• Chaque lot a un responsable nommé et un SLA par criticité (par exemple P0 sous 72 h, P1 sous deux semaines). Un finding sans propriétaire ne se corrige pas.
• La clôture passe par un retest. Un correctif non rejoué est présumé, pas prouvé : c'est le geste qui boucle vraiment le cycle.

Vous avez un rapport plein de findings et vous ne savez pas par où commencer ? C'est exactement le moment où l'on intervient : trier ce qui compte, bâtir une file de remédiation tenable, et rejouer les attaques pour prouver que c'est refermé. Parlez-en directement via la page contact, ou voyez d'abord comment se déroule un pentest pour comprendre d'où sort le rapport à remédier.