Plan de remédiation cyber : ce qui fait dérailler les programmes en exécution
Un plan de remédiation post-audit ressemble rarement à ce qu'on en imagine au démarrage. Sur le papier, c'est une liste d'actions priorisées, validée par le RSSI et la DSI, suivie par un comité hebdomadaire. Dans la réalité, six mois après le kick-off, la moitié des actions a glissé, un tiers a changé de propriétaire, et plus personne ne sait vraiment si l'audit initial est encore représentatif du système d'information.
Cet écart entre le plan théorique et son exécution réelle n'est pas une question de rigueur ou d'outillage. Il tient à des mécaniques organisationnelles que les méthodes publiques (ANSSI, ENISA, NIST) abordent peu, parce qu'elles relèvent du terrain. Cet article revient sur ces mécaniques, sur la méthode de priorisation qui fonctionne quand l'audit remonte 240 findings, et sur la façon dont la remédiation s'articule désormais avec les exigences de DORA et de NIS2 pour les organisations qui mènent les deux chantiers en parallèle.
Ce que dit la doctrine officielle, et ce qu'elle ne dit pas
La référence française en matière de remédiation est le corpus produit par l'ANSSI à partir de 2023, en particulier le volet opérationnel publié sur cyber.gouv.fr. La méthode s'articule autour de quatre temps : définir des objectifs stratégiques peu nombreux, les décliner en objectifs opérationnels, établir les actions techniques, poser une roadmap. Côté américain, qui sert de référence dans la plupart des grandes organisations internationales, le NIST SP 800-61 Rev. 3, publié en avril 2025 et aligné sur le Cybersecurity Framework 2.0, propose une structure équivalente avec une granularité supérieure sur la phase post-incident.
Ces référentiels sont solides. Ils décrivent correctement ce qu'un plan de remédiation doit contenir. Ils décrivent moins bien ce qui le fait dérailler. Pourtant, les données disponibles sont sans ambiguïté. Selon le rapport ENISA NIS Investments 2023, seules 28 % des organisations européennes parviennent à corriger une vulnérabilité critique sur un actif essentiel en moins d'une semaine. Le Verizon DBIR 2025 mesure quant à lui un délai médian de 32 jours pour patcher les vulnérabilités exploitées sur les équipements en périphérie (VPN, firewalls, gateways d'administration), avec seulement 54 % des correctifs effectivement appliqués dans l'année.
Ces écarts ne s'expliquent pas par une méconnaissance des méthodes. La plupart des RSSI savent prioriser. Ce qui les met en difficulté, c'est l'exécution dans la durée, au milieu des contraintes métier, des dépendances applicatives, et des arbitrages permanents entre disponibilité et sécurité.
Le premier blocage : une priorisation qui ne survit pas au premier mois
La quasi-totalité des plans de remédiation démarrent sur une matrice impact/probabilité. C'est utile, mais insuffisant. Une matrice statique ne tient pas la confrontation à la réalité opérationnelle : un correctif jugé prioritaire en semaine 1 peut devenir impossible à appliquer en semaine 8 parce qu'un projet métier critique vient d'être lancé sur le même périmètre. Inversement, une vulnérabilité classée en priorité 3 peut basculer en priorité 1 en quelques heures si elle est ajoutée au catalogue KEV (Known Exploited Vulnerabilities) de la CISA.
La priorisation qui résiste à l'épreuve du terrain combine quatre dimensions, et non deux :
- La criticité technique, mesurée par le score CVSS, mais retraitée par le score EPSS (Exploit Prediction Scoring System), qui estime la probabilité d'exploitation dans les 30 jours. Le CVSS seul produit des hiérarchies trompeuses : une vulnérabilité notée 9.8 mais à EPSS 0.01 % est en pratique moins urgente qu'une vulnérabilité notée 7.5 à EPSS 45 %.
- La présence sur la liste KEV de la CISA, qui agit comme un signal d'exploitation active. Toute vulnérabilité ajoutée à cette liste devrait passer automatiquement en priorité maximale, indépendamment de son score CVSS initial.
- Le contexte métier de l'actif, qui dépend de la cartographie des fonctions essentielles. C'est ici que DORA introduit une rupture pour le secteur financier : les fonctions critiques au sens de l'article 8 du règlement doivent être identifiées et documentées, et le niveau de protection associé doit être proportionné. Une vulnérabilité sur un actif supportant une fonction critique au sens DORA est juridiquement, et non plus seulement opérationnellement, plus urgente.
- L'exploitabilité réelle dans l'environnement, qui dépend de la segmentation, des contrôles compensatoires en place, et de la surface d'attaque. Une CVE critique sur un serveur isolé en zone industrielle sans accès Internet n'a pas le même profil de risque qu'une CVE identique sur un serveur d'authentification exposé.
Cette combinaison ne s'improvise pas. Dans les organisations que nous accompagnons, sa mise en place demande en moyenne deux à trois mois de préparation : industrialisation de l'inventaire, intégration des flux EPSS et KEV, modélisation des dépendances fonctionnelles. Ce travail de socle, peu visible, est ce qui fait la différence entre un plan de remédiation pilotable et un tableur Excel qui dérive.
Le second blocage : la dérive des responsabilités
Un plan de remédiation est presque toujours validé en comité de pilotage avec une matrice RACI précise. Trois mois plus tard, dans la moitié des cas, cette matrice n'est plus à jour. Les responsables désignés ont été réaffectés, des arbitrages ont déplacé des actions d'une équipe à une autre, et certaines actions sont devenues orphelines sans que personne ne le formalise.
Ce phénomène a une cause structurelle. Les actions de remédiation traversent par construction plusieurs frontières organisationnelles : sécurité opérationnelle (SOC, équipes vulnerability management), production (équipes système, réseau, bases de données), études (équipes applicatives), achats (pour les contrats de support), conformité, parfois juridique. Aucune de ces équipes n'a la responsabilité pleine et entière de l'action de bout en bout. Le RSSI pilote, mais ne décide pas seul des fenêtres de maintenance. La DSI exécute, mais arbitre selon ses propres contraintes de capacité.
Trois mécanismes permettent de stabiliser cette gouvernance distribuée. Le premier est la nomination, pour chaque action significative, d'un référent unique de bout en bout, qui n'est pas nécessairement l'exécutant mais qui rend compte de l'avancement. Le deuxième est la mise en place d'un mécanisme d'escalade documenté, déclenché automatiquement quand une action dépasse de plus de quinze jours son échéance prévue, sans attendre la prochaine réunion de pilotage. Le troisième est la traçabilité des arbitrages : chaque fois qu'une action est dépriorisée ou reportée, la décision et son motif sont consignés. Ce dernier point est rarement appliqué, alors qu'il devient critique en cas de contrôle ACPR ou d'inspection au titre de NIS2.
L'articulation avec DORA : ce que change l'entrée en application
Pour les entités financières, le règlement DORA (UE 2022/2554), entré en application le 17 janvier 2025, modifie en profondeur le cadre de la remédiation. Trois exigences ont des conséquences directes sur la conduite des plans.
L'article 6 impose un cadre de gestion des risques liés aux TIC qui inclut explicitement la remédiation comme processus continu, et non plus comme exercice ponctuel post-audit. La traduction opérationnelle est qu'un plan de remédiation isolé ne suffit plus : il doit s'inscrire dans une gouvernance permanente, avec des indicateurs de pilotage, une revue annuelle, et une articulation avec la cartographie des risques.
Les articles 17 à 23 instaurent un régime de notification d'incidents majeurs sous quatre heures pour l'alerte initiale, suivie d'un rapport intermédiaire à 72 heures et d'un rapport final dans le mois. Cette obligation a une conséquence souvent sous-estimée sur la remédiation : les actions correctives qui découlent de la notification doivent être documentées et traçables au niveau requis par l'ACPR, ce qui impose une rigueur formelle que beaucoup de processus internes n'ont pas encore intégrée.
L'article 24 introduit les tests TLPT (Threat-Led Penetration Testing), inspirés du framework TIBER-EU, obligatoires tous les trois ans pour les entités les plus significatives. Les findings issus de ces tests entrent directement dans le pipeline de remédiation, mais avec un niveau de confidentialité et de criticité spécifique qui appelle un circuit distinct du circuit habituel des audits.
Pour une banque ou une compagnie d'assurance, la conséquence pratique est qu'il n'existe plus un seul plan de remédiation, mais trois flux parallèles à orchestrer : la remédiation continue issue de la gestion des vulnérabilités, la remédiation incidentelle issue des notifications DORA, et la remédiation issue des tests TLPT. La capacité à articuler ces trois flux dans une gouvernance unifiée est probablement le point de différenciation le plus net entre les organisations qui ont absorbé DORA et celles qui l'ont juste survolé.
Trois indicateurs qui parlent vraiment du pilotage
Beaucoup de comités de remédiation suivent un nombre d'actions par statut (à faire, en cours, terminé). Ces indicateurs renseignent sur l'activité, pas sur la maîtrise du risque. Trois métriques plus précises permettent de piloter réellement.
Le délai médian de remédiation par classe de criticité (MTTR — Mean Time To Remediate, segmenté par criticité) donne une vision honnête de la capacité d'exécution. Une organisation qui revendique un MTTR de 7 jours sur les vulnérabilités critiques mais qui en pratique tient cet engagement sur 40 % des cas seulement a un problème de pilotage qu'aucun comité hebdomadaire ne révélera tant qu'on ne mesure que le volume.
Le taux de récidive, c'est-à-dire la part des actions clôturées qui rouvrent dans les trois mois (vulnérabilité réapparue, configuration revenue à son état initial, dérive). Un taux supérieur à 15 % indique un problème structurel sur la maîtrise des configurations ou sur l'industrialisation des correctifs.
Le taux de couverture des actifs critiques, c'est-à-dire la part des actifs supportant des fonctions essentielles ou critiques pour lesquels la remédiation est documentée et auditée. Cet indicateur est exigé en pratique par DORA, mais reste sous-utilisé alors qu'il est le seul qui parle directement au COMEX et aux régulateurs.
En synthèse
La remédiation cyber n'échoue presque jamais sur la méthode. Elle échoue sur trois fronts précis : une priorisation qui ne se contextualise pas dans le temps, une gouvernance distribuée qui ne formalise pas ses arbitrages, et un pilotage qui mesure l'activité plutôt que la maîtrise du risque. Pour les entités financières, l'entrée en application de DORA ajoute une exigence de traçabilité et d'articulation entre flux qui rend le sujet structurellement plus complexe qu'il y a deux ans.
Construire un dispositif qui tient la durée n'est pas un projet de quelques mois ; c'est une discipline. Les organisations qui y parviennent ont en commun trois choses : elles industrialisent leur priorisation en combinant CVSS, EPSS et KEV ; elles documentent leurs arbitrages avec autant de rigueur que leurs actions ; et elles pilotent par le risque résiduel, pas par le volume d'actions traitées.
Cet article a été préparé par les consultants cybersécurité d'Avanista. Avanista accompagne depuis plus de 25 ans les acteurs du secteur financier et les grands comptes français dans la conception, le pilotage et l'exécution de leurs programmes de cybersécurité, de la conformité réglementaire à l'administration sécurisée du système d'information.