Orchestration de la remédiation : du scan à la correction priorisée

1. Le fossé entre la détection et la correction

La plupart des organisations savent scanner. Les outils de détection se sont multipliés, les surfaces couvertes se sont étendues, et les rapports de vulnérabilités s'allongent chaque trimestre. Pourtant, les attaquants continuent d'entrer par des failles connues, souvent corrigeables depuis des mois. Le problème ne se situe pas en amont, dans la découverte, mais en aval, dans le traitement.

Le Panorama de la cybermenace 2025 de l'ANSSI, publié le 11 mars 2026, pose un constat sans ambiguïté. Près de 29 % des vulnérabilités exploitées en 2025 l'ont été le jour même de leur divulgation ou avant la publication d'un correctif. Plus préoccupant pour le quotidien des équipes : un scan rapide montrait, fin 2025, que plus de 6 200 actifs français connectés à Internet présentaient encore les principales vulnérabilités exploitées en 2023 et 2024. Vincent Strubel, directeur général de l'agence, qualifie cette absence de correction d'«épée de Damoclès».

Cette persistance ne traduit pas un manque d'outils de détection. Elle révèle une rupture dans la chaîne qui va du signal à l'action. Une vulnérabilité détectée le lundi attend parfois plusieurs semaines avant qu'un ticket soit créé, qu'une équipe le prenne en charge, qu'une fenêtre de maintenance se libère et que la correction soit enfin vérifiée. Chaque transfert manuel entre deux outils ou deux personnes introduit un délai et un risque de perte.

1.1 Le coût de la lenteur

Les chiffres du rapport IBM Cost of a Data Breach 2025 sont éloquents. Le cycle de vie moyen d'une violation atteint 241 jours, dont 83 jours pour la seule phase de confinement. Les violations contenues en moins de 200 jours coûtent en moyenne 3,61 M$, contre 5,49 M$ au-delà, soit un écart de près de 1,9 M$. La vitesse de traitement n'est pas un indicateur de confort opérationnel : c'est une variable financière de premier ordre.

La question n'est donc plus de savoir s'il faut industrialiser la remédiation, mais comment. C'est précisément l'objet de l'orchestration.

2. Qu'est-ce que l'orchestration de la remédiation ?

L'orchestration de la remédiation désigne la coordination automatisée de l'ensemble des actions nécessaires pour passer d'une vulnérabilité identifiée à une vulnérabilité corrigée et vérifiée. Elle ne se limite pas à l'application d'un correctif : elle organise la priorisation, l'attribution des responsabilités, le suivi des délais, la communication entre les équipes et le contrôle final de la correction.

2.1 La distinction avec la gestion des vulnérabilités classique

La distinction avec la gestion des vulnérabilités classique est nette. La gestion des vulnérabilités, au sens du VMDR (Vulnerability Management, Detection and Response), produit une connaissance : quelles failles existent, où, et avec quelle sévérité. L'orchestration prend le relais et produit un résultat : ces failles diminuent, dans un ordre défini et dans des délais maîtrisés. La première remplit un tableau de bord, la seconde le vide.

2.2 Les quatre fonctions d'un cycle orchestré

Un cycle de remédiation orchestré repose sur quatre fonctions enchaînées, sans rupture manuelle entre elles.

Le terme «orchestration» n'est pas un habillage marketing. Il décrit précisément le rôle d'un chef d'orchestre : faire jouer ensemble, au bon moment, des acteurs et des outils qui, livrés à eux-mêmes, produiraient une cacophonie de tableurs, de courriels et de tickets oubliés.

3. Les cinq étapes d'un cycle orchestré

3.1 Étape 1 : prioriser par l'exploitabilité réelle

La priorisation est la première étape, et la plus déterminante. Une orchestration qui traite toutes les vulnérabilités dans l'ordre de leur découverte, ou même de leur score de sévérité brut, gaspille des ressources rares sur des risques théoriques tout en laissant ouvertes des failles activement exploitées.

Pourquoi le CVSS ne suffit plus

Le score CVSS (Common Vulnerability Scoring System) mesure la sévérité intrinsèque d'une vulnérabilité : ce qu'un attaquant pourrait faire s'il l'exploitait. Il ne dit rien de la probabilité que cette exploitation survienne. Or, sur les quelque 48 000 CVE de 2025, environ la moitié ont été estampillées critiques par le CVSS, alors que moins de 300 ont été réellement exploitées en conditions opérationnelles. Prioriser sur le seul CVSS revient à traiter en urgence une multitude de failles qui ne seront jamais utilisées, et à se noyer dans le bruit. Le CVSS souffre d'un second défaut : il est figé à la publication. Une vulnérabilité notée 6,5 aujourd'hui peut devenir le vecteur d'attaque privilégié de demain dès qu'un code d'exploitation circule, sans que son score ne bouge.

Croiser quatre signaux complémentaires

L'EPSS (Exploit Prediction Scoring System), maintenu par le FIRST et déployé en version 4 en 2025, estime la probabilité qu'une CVE soit exploitée dans les trente jours. Un seuil EPSS de 0,1 capture environ 80 % des vulnérabilités qui seront effectivement exploitées, tout en ne représentant que 5 % du volume total. Le catalogue KEV de la CISA apporte, lui, une certitude : si une CVE y figure, elle est exploitée quelque part dans le monde.

En croisant EPSS, KEV et contexte métier, une organisation peut réduire de l'ordre de 80 % le volume de vulnérabilités exigeant une action urgente, tout en couvrant plus de 95 % des failles réellement exploitées. Concrètement, plusieurs milliers de «critiques» se ramènent à une liste opérationnelle de quelques dizaines d'éléments.

3.2 Étape 2 : affecter et contextualiser

Une vulnérabilité priorisée mais non affectée reste une vulnérabilité ouverte. L'étape d'affectation transforme une ligne dans un rapport en une tâche dont quelqu'un est responsable. C'est souvent là que les programmes les plus matures sur la détection échouent : le rapport part par courriel à une liste de diffusion, et personne ne se sent personnellement comptable.

L'orchestration résout ce point par un routage automatique fondé sur la connaissance de l'actif. Si la cartographie associe chaque serveur, chaque application et chaque composant à une équipe propriétaire, alors une vulnérabilité détectée sur cet actif peut générer immédiatement une tâche assignée à la bonne personne. La cartographie des actifs (CAASM) n'est pas un préalable accessoire : c'est le carburant de l'affectation.

Une affectation efficace ne se limite pas à un identifiant de CVE. L'équipe qui reçoit la tâche a besoin de comprendre, en quelques secondes, pourquoi elle est urgente et comment la traiter. Une affectation complète inclut l'actif précis concerné et son propriétaire métier, la raison de la priorité (exploitation confirmée, exposition externe, criticité de l'actif), la marche à suivre recommandée et le délai attendu. L'apport de l'intelligence artificielle change ici la donne : une orchestration moderne génère une recommandation de remédiation contextualisée, adaptée à la version exacte du composant et à son environnement.

3.3 Étape 3 : le ticketing comme colonne vertébrale

Le suivi est le cœur opérationnel de l'orchestration. Sans un système de tickets fiable, l'affectation se dissout dans les boîtes de réception et la priorisation perd tout son sens. Le ticket est l'unité de travail qui relie une vulnérabilité à sa résolution, et son cycle de vie matérialise l'avancement du programme.

Un suivi de remédiation digne de ce nom assure plusieurs propriétés simultanément. Chaque vulnérabilité priorisée génère un ticket unique, horodaté, doté d'un responsable et d'une échéance. L'état d'avancement est visible sans avoir à le demander. Les dépassements de délai déclenchent des relances et, si besoin, une escalade hiérarchique automatique. L'historique complet reste consultable, ce qui constitue la matière première de tout audit de conformité.

La bonne architecture n'oppose pas le ticketing intégré et les outils existants : elle les relie. Une vulnérabilité priorisée doit pouvoir générer un ticket dans l'outil natif de la plateforme de sécurité pour les équipes cyber, tout en se synchronisant avec l'outil de gestion de service déjà en place pour les équipes IT. L'objectif n'est pas de remplacer ce qui fonctionne, mais d'éliminer les ressaisies entre les silos.

3.4 Étape 4 : automatiser sans perdre le contrôle

L'automatisation est le levier qui permet de tenir le rythme face au volume. Mais elle se conçoit par paliers, et non comme un interrupteur unique entre «tout manuel» et «tout automatique». La maturité d'un programme se mesure à sa capacité à automatiser ce qui peut l'être sans risque, tout en gardant une main humaine là où la prudence l'impose.

Le cas des environnements industriels mérite une attention particulière. Sur un système de production OT, l'application d'un correctif peut interrompre une chaîne ou désynchroniser un automate. L'orchestration n'y supprime pas la décision humaine : elle la prépare en fournissant le contexte, la fenêtre de maintenance recommandée et la mesure de contournement applicable en attendant. Vouloir tout automatiser sur ces périmètres serait une faute d'ingénierie.

Les chiffres confirment le bénéfice d'une automatisation bien dosée. Le rapport IBM 2025 établit que les organisations recourant largement à l'IA et à l'automatisation dans leurs opérations de sécurité réduisent le coût moyen d'une violation de près de 1,9 M$ et raccourcissent le cycle de vie de l'incident de 80 jours par rapport à celles qui ne les utilisent pas.

3.5 Étape 5 : vérifier et clôturer

Un ticket fermé n'est pas une vulnérabilité corrigée. C'est l'erreur la plus fréquente et la plus dangereuse des programmes de remédiation : considérer qu'une tâche marquée «résolue» par une équipe signifie que la faille a disparu. Un correctif peut avoir été partiellement appliqué, annulé par un retour arrière, contourné par une réinstallation ou neutralisé par une configuration restée vulnérable.

La vérification consiste à re-scanner l'actif concerné après l'intervention et à confirmer, sur preuve technique, que la vulnérabilité n'est plus présente. Ce n'est qu'à cette condition que le ticket peut être clôturé.

4. SLA et indicateurs de pilotage

Un programme de remédiation qui ne se mesure pas ne se pilote pas. L'orchestration produit un flux d'événements horodatés qui rend enfin possible un pilotage chiffré, là où le suivi manuel ne livrait que des impressions. Deux familles d'objets structurent ce pilotage : les engagements de délai et les indicateurs de performance.

4.1 Définir des délais de correction par niveau de risque

Les engagements de délai, ou SLA de remédiation, fixent le temps maximal accordé pour corriger une vulnérabilité selon sa criticité. Ils doivent rester réalistes pour être tenus, et différenciés pour être pertinents.

Ces valeurs sont des repères, à calibrer selon le secteur, la maturité et les contraintes d'exploitation. Le principe importe plus que le chiffre : un délai différencié, écrit et opposable est infiniment supérieur à l'absence d'engagement.

4.2 Les indicateurs qui comptent

Quelques indicateurs suffisent à piloter un programme, à condition de les suivre dans la durée et avec une définition stable.

• MTTR par criticité : le temps moyen de remédiation, mesuré séparément pour chaque niveau de risque. Un MTTR global agrège des réalités trop différentes pour être utile.
• Taux de respect des SLA : la proportion de vulnérabilités corrigées dans le délai cible. C'est l'indicateur de tenue des engagements.
• Dette de vulnérabilités et son ancienneté : le volume de failles ouvertes et, surtout, depuis combien de temps. Une dette vieillissante est le symptôme d'un goulet d'étranglement.
• Présence de vulnérabilités exploitées dans le parc : le nombre de CVE du catalogue KEV encore présentes. Cet indicateur devrait tendre vers zéro en permanence.
• Taux de correctifs vérifiés : la part de tickets clôturés sur re-scan plutôt que sur déclaration. Il mesure la fiabilité réelle du programme.

5. Conformité : NIS2, DORA et la traçabilité

L'orchestration de la remédiation n'est pas qu'une affaire d'efficacité opérationnelle. Elle répond directement à des obligations réglementaires qui se durcissent en Europe et en France. Un processus tracé, mesurable et assorti de délais est précisément ce que les régulateurs attendent désormais.

5.1 Ce que NIS2 exige réellement

La directive NIS2 n'impose aucun outil précis. Son article 21 exige en revanche des mesures de gestion des risques proportionnées, qui incluent explicitement le traitement des vulnérabilités, la continuité d'activité et la sécurité de la chaîne d'approvisionnement. Un programme de remédiation orchestré, capable de prouver qui a corrigé quoi, quand et avec quel résultat, répond frontalement à ces exigences. La traçabilité n'est plus un confort : elle devient une obligation de démonstration.

5.2 DORA et le secteur financier

Pour les entités financières, le règlement DORA, applicable depuis janvier 2025, impose une gestion structurée des risques liés aux technologies de l'information, incluant l'identification et le traitement des vulnérabilités ainsi que des tests réguliers de résilience. Là encore, l'orchestration apporte la preuve documentée que les vulnérabilités sont traitées dans des délais maîtrisés, ce qui constitue un attendu central des contrôles.

Au-delà des textes, l'ANSSI souligne un point essentiel : appliquer les correctifs sans délai sur les équipements exposés figure en tête des mesures de base décrites dans NIS2 et le Cyber Resilience Act. L'orchestration de la remédiation est, à ce titre, l'instrument concret d'une conformité qui se prouve par les actes.

6. Les pièges qui font échouer un programme d'orchestration

Mettre en place une orchestration de la remédiation se heurte à des écueils récurrents. Les connaître à l'avance évite de reproduire des erreurs coûteuses, observées dans de nombreuses organisations qui croyaient avoir résolu leur problème de correction en achetant simplement un outil de plus.

6.1 Confondre l'outil et le processus

L'erreur la plus fréquente consiste à penser qu'une plateforme suffit. Un outil sans règles de priorisation documentées, sans SLA opposables et sans responsables désignés ne produit qu'un tableau de bord supplémentaire. L'orchestration est d'abord un processus, que l'outil sert à industrialiser. Inverser cet ordre, c'est automatiser le désordre plutôt que de le résoudre. Avant de paramétrer quoi que ce soit, l'organisation doit avoir tranché qui décide, qui corrige et selon quels délais.

6.2 Sous-estimer la cartographie d'actifs

Toute la chaîne d'affectation repose sur la connaissance des actifs et de leurs propriétaires. Une cartographie incomplète ou périmée fait dérailler l'orchestration dès la deuxième étape : les tickets partent vers les mauvaises équipes, ou ne partent nulle part. Le Shadow IT aggrave le phénomène, puisque les actifs inconnus échappent par définition à toute affectation. On ne corrige pas ce qu'on ne sait pas posséder.

6.3 Mesurer ce qui est facile plutôt que ce qui compte

Beaucoup de programmes se contentent de compter les vulnérabilités fermées, indicateur flatteur mais trompeur. Fermer mille tickets de faible sévérité pendant que trois vulnérabilités exploitées restent ouvertes donne une statistique rassurante et une posture désastreuse. Le nombre de CVE du catalogue KEV encore présentes dans le parc est, à cet égard, bien plus révélateur que le volume brut de tickets clôturés.

6.4 Clôturer sans vérifier

Une équipe surchargée a une tendance naturelle à marquer une tâche comme résolue dès qu'elle a lancé l'action de correction, sans attendre la confirmation. Multiplié par des centaines de tickets, ce raccourci crée une dette invisible : des vulnérabilités réputées corrigées mais toujours actives. Seule une vérification systématique par re-scan, intégrée au flux d'orchestration, prévient cette dérive.

6.5 Automatiser trop vite sur les périmètres sensibles

Certains programmes étendent l'automatisation de la correction à des actifs critiques avant d'avoir éprouvé les règles sur des périmètres tolérants. Une application automatique de correctif qui interrompt une chaîne de production ou un service client génère une défiance durable envers tout le programme. La confiance se construit par paliers : on automatise d'abord là où l'erreur est sans conséquence, puis on élargit à mesure que les règles font leurs preuves.

7. Feuille de route de mise en place

Mettre en place une orchestration de la remédiation ne se fait pas d'un bloc. Une démarche progressive, qui sécurise chaque étape avant d'élargir, donne de meilleurs résultats qu'un déploiement massif et précipité.

7.1 Orchestrer la remédiation avec Beareye

Le cadre méthodologique décrit jusqu'ici suppose, pour être tenu, une plateforme qui relie effectivement la détection, la priorisation, le suivi et la vérification. C'est l'objet de Beareye, la plateforme souveraine éditée par BEAROPS, qui intègre nativement les briques de l'orchestration sans imposer un nouveau silo.

Beareye couvre la surface d'attaque externe comme interne grâce à ses modules EASM, CAASM et VMDR, détecte le Shadow IT et inscrit la gestion des vulnérabilités dans le cadre CTEM d'exposition continue. Chaque faille priorisée devient une tâche traçable, dotée d'un responsable, d'une échéance et d'un historique consultable. Les vulnérabilités sont hiérarchisées selon leur degré d'exploitabilité réelle, et des remédiations personnalisées par intelligence artificielle sont fournies : l'équipe reçoit non seulement la liste des actions à mener, mais aussi le «comment», adapté à son environnement.

L'orchestration n'a de valeur que si elle s'insère dans l'existant. Beareye s'y connecte par ses API et ses connecteurs natifs, qui permettent d'intégrer la plateforme au reste du système d'information. Cette articulation, entièrement opérée depuis une plateforme hébergée en France, répond à la double exigence des décideurs français : industrialiser la remédiation et conserver la maîtrise souveraine de leurs données de sécurité.