Un KPI de sécurité informatique n’a de valeur que s’il aide à décider, corriger plus vite une vulnérabilité, renforcer un contrôle, prioriser un budget ou expliquer un risque au COMEX. Le piège consiste à empiler des métriques techniques sans lien avec la réalité opérationnelle. Un bon tableau de bord SSI sélectionne donc peu d’indicateurs, les mesure régulièrement et les traduit en impact métier.
Ce qu’un KPI de sécurité informatique doit vraiment mesurer
Un KPI, ou indicateur clé de performance, mesure l’efficacité d’une action de sécurité dans le temps. Il ne dit pas seulement combien d’alertes ont été générées, il montre si l’organisation détecte mieux, corrige plus vite, réduit sa surface d’attaque ou améliore sa résilience. C’est cette logique de progression qui distingue un KPI utile d’une simple statistique.
Quiz : KPI Sécurité Informatique
En cybersécurité, il faut aussi distinguer les KPI opérationnels des KPI stratégiques. Les premiers servent aux équipes SOC, infrastructure, cloud ou postes de travail, avec des repères comme la couverture EDR, le taux de patch, les alertes traitées dans les SLA, le MTTD ou le MTTR. Les seconds parlent davantage à la DSI, au RSSI, à la direction générale ou au COMEX, avec des indicateurs comme l’exposition des actifs critiques, le niveau de conformité, le risque résiduel ou l’évolution du coût de remédiation.
Un indicateur doit être actionnable, pas seulement mesurable
Un KPI pertinent répond à une question simple, quelle décision prend-on si la valeur se dégrade ? Si le taux de patch critique baisse, on peut arbitrer des fenêtres de maintenance. Si le nombre d’actifs exposés sur internet augmente, on peut lancer une revue d’architecture. Si le taux de faux positifs explose, on peut ajuster les règles SIEM ou automatiser une partie du tri via SOAR.
À l’inverse, un volume brut d’alertes, isolé de son contexte, peut induire en erreur. Une hausse peut révéler une attaque, mais aussi un nouvel outil mieux configuré. C’est pourquoi les KPI doivent être historisés, comparés à un seuil, reliés à un périmètre et accompagnés d’une lecture qualitative. Sans cela, le tableau de bord rassure plus qu’il n’aide à piloter.
Les 10 KPI à suivre pour piloter la posture de sécurité
La bonne sélection dépend du SI, du secteur et de la maturité cyber, mais certains indicateurs reviennent dans la plupart des tableaux de bord efficaces. Ils couvrent la prévention, la détection, la réponse et la gouvernance. L’objectif n’est pas de tout mesurer, mais de garder les indicateurs qui donnent une vue claire de la posture de sécurité.
| KPI | Ce qu’il mesure | Source possible | Fréquence utile |
|---|---|---|---|
| Couverture EDR ou antivirus | Part des postes et serveurs protégés, avec une cible souvent fixée à 95 % ou plus | EDR, console antivirus, CMDB | Hebdomadaire |
| Taux de patch critique | Part des vulnérabilités critiques corrigées, par exemple sous 30 jours | Scanner de vulnérabilités, ITSM | Hebdomadaire ou mensuelle |
| Actifs exposés sur internet | Serveurs, services, ports ou applications visibles depuis l’extérieur | ASM, scans externes, cartographie SI | Continue ou hebdomadaire |
| Shadow IT détecté | Applications, comptes ou services non maîtrisés par l’IT | CASB, proxy, logs SSO, inventaire cloud | Mensuelle |
| Couverture MFA | Comptes protégés par authentification multifacteur, avec une cible de 95 % sur les comptes sensibles | IAM, AD, SSO | Hebdomadaire |
| MTTD | Temps moyen de détection d’un incident ou d’une compromission | SIEM, EDR, XDR | Mensuelle |
| MTTA | Temps moyen avant prise en compte d’une alerte | SIEM, SOAR, ITSM | Hebdomadaire |
| MTTI | Temps moyen consacré à l’investigation | SOC, ticketing, rapports d’incident | Mensuelle |
| MTTR | Temps moyen de remédiation ou de retour à un état maîtrisé | ITSM, EDR, rapports de crise | Mensuelle |
| Alertes traitées dans les SLA | Part des alertes prises en charge dans les délais, par exemple 24h ou 72h selon la criticité | SIEM, SOC, MSSP | Hebdomadaire |
Ne pas oublier la qualité des alertes
Le taux de faux positifs est un KPI souvent sous-estimé. Un SOC peut recevoir des milliers de signaux, parfois 4500 alertes en moyenne sur une période de suivi, mais toutes ne méritent pas une investigation humaine. Si 30 % des alertes sont jugées non pertinentes, l’équipe perd du temps, la fatigue d’alerte augmente et les vrais signaux faibles risquent d’être noyés.
Ce KPI doit être lu avec prudence. Chercher 0 % de faux positifs peut conduire à désactiver des règles utiles. L’objectif est plutôt de réduire le bruit sans affaiblir la détection, en améliorant la corrélation SIEM, l’enrichissement par l’EDR ou l’automatisation SOAR. C’est un arbitrage de qualité, pas seulement de volume.
Choisir les KPI selon la maturité, le risque et le public cible
Une PME, une ETI industrielle, une entreprise cloud first ou une organisation régulée ne pilotent pas la sécurité avec le même niveau de détail. Le bon réflexe consiste à partir des risques majeurs, interruption de production, fuite de données, ransomware, compromission de comptes à privilèges, non-conformité ou atteinte à la disponibilité d’un service client. Les KPI doivent refléter ces risques, pas seulement la facilité de mesure.
Pour une organisation peu mature : visibilité et contrôles de base
Lorsque l’inventaire est incomplet, les premiers KPI doivent mesurer la visibilité : taux d’actifs inventoriés, couverture EDR, actifs exposés sur internet, comptes sans MFA, vulnérabilités critiques non corrigées. Sans cartographie fiable du SI, les autres indicateurs reposent sur un périmètre instable. Le tableau de bord doit d’abord dire ce qui existe vraiment.
Dans ce cas, mieux vaut suivre 5 à 7 KPI robustes que 30 métriques approximatives. Une couverture EDR à 95 %, un taux de patch critique suivi sous 30 jours ou une MFA déployée sur les comptes sensibles donnent déjà une base de pilotage claire. Le but est de stabiliser la mesure avant d’élargir le suivi.
Pour une organisation mature : vitesse, résilience et risque métier
Une fois les fondamentaux maîtrisés, les KPI doivent mesurer la capacité à réagir : MTTD, MTTA, MTTI, MTTR, taux d’alertes traitées dans les SLA, résultats des exercices de crise, efficacité des playbooks. Certaines équipes visent par exemple une prise en charge initiale sous 3h pour des alertes critiques, mais ce seuil doit rester cohérent avec les moyens disponibles et avec le niveau de service attendu.
La sécurité ressemble alors à un maillage. Chaque point paraît solide isolément, mais c’est l’ensemble qui donne la résistance. Un EDR bien déployé perd de sa valeur si l’inventaire est incomplet. Un SIEM performant devient fragile si les journaux critiques ne remontent pas. Un MFA généralisé laisse une faille si les comptes de service restent hors contrôle. Lire les KPI comme un système de dépendances aide à repérer les ruptures entre outils, processus et responsabilités.
Mesurer correctement : sources, gouvernance et fréquence
Un KPI de sécurité informatique fiable dépend d’abord de la qualité des données. Les sources les plus fréquentes sont la CMDB, l’EDR, les scanners de vulnérabilités, l’Active Directory ou l’IAM, le SIEM, le SOAR, les outils ITSM, les rapports de pentest et les exercices de simulation. La question n’est pas seulement de collecter, mais de faire converger des données cohérentes.
Centraliser sans perdre le contexte
Un tableau de bord SSI doit agréger les données, mais pas les aplatir. Un serveur critique non patché n’a pas le même poids qu’un poste de test isolé. Un compte administrateur sans MFA est plus risqué qu’un compte utilisateur standard. Il faut donc associer les KPI à des attributs de criticité, métier concerné, exposition internet, données sensibles, niveau de privilège, environnement de production ou de test.
La fréquence dépend de l’usage. Les alertes critiques, les actifs exposés et la couverture de protection se suivent de façon rapprochée, parfois quotidiennement. Les tendances de patching, de sensibilisation ou de conformité peuvent être revues chaque mois. Les exercices de réponse à incident doivent, au minimum, être organisés une fois par an pour vérifier que les KPI reflètent une capacité réelle, pas seulement théorique.
Intégrer l’humain dans le tableau de bord
La surface d’attaque humaine mérite ses propres indicateurs : taux de participation aux formations, résultats des simulations de phishing, taux de signalement des emails suspects, délai moyen de remontée d’un incident par les utilisateurs. Un taux de signalement proche de 90 % sur une campagne interne est plus utile qu’un simple score de formation, car il mesure un comportement observable et pas seulement une connaissance déclarative.
Transformer les KPI en décisions business
La direction n’a pas besoin d’un export technique du SIEM. Elle attend une lecture du risque, des arbitrages et une trajectoire. Le rôle du RSSI ou de la DSI consiste à traduire les KPI en langage business : exposition financière, indisponibilité potentielle, impact client, conformité, réputation, capacité de continuité. Le reporting gagne en force quand il relie les chiffres aux décisions.
Un bon reporting distingue trois niveaux. Équipe technique : détails sur les vulnérabilités, faux positifs, SLA, tickets, règles de détection. Management IT et sécurité : tendances, priorités, ressources nécessaires, points de blocage. COMEX : risques majeurs, progrès mesurables, décisions budgétaires, arbitrages de responsabilité. Chaque niveau doit recevoir la bonne profondeur de lecture.
Les KPI doivent surtout montrer une tendance. Une valeur isolée à 83 % ou 97 % peut sembler bonne ou mauvaise selon le périmètre, la criticité et l’évolution. En revanche, une amélioration régulière de la couverture MFA, une baisse du MTTR ou une réduction durable des actifs exposés démontre une progression concrète. C’est l’évolution dans le temps qui donne du sens au chiffre.
Enfin, certains indicateurs doivent être présentés comme des KRI, c’est-à-dire des indicateurs de risque. Par exemple, le nombre de systèmes critiques non corrigés, les comptes à privilèges sans MFA ou les incidents récurrents sur une même application signalent un risque résiduel à arbitrer. C’est cette articulation entre KPI et KRI qui permet de défendre un budget cybersécurité sans tomber dans la peur ou le jargon.
Le meilleur tableau de bord n’est donc pas celui qui contient le plus de métriques, mais celui qui relie clairement la posture de sécurité, les actions de terrain et les décisions de l’entreprise.
