Beaucoup d’organisations disposent d’un registre des risques formellement correct, mais peu ont un pilotage opérationnel fiable au quotidien. En pratique, ce n’est pas le nombre de risques documentés qui compte, mais que les responsables détectent tôt où le risque se construit réellement et que les mesures soient efficaces. C’est précisément là que la gouvernance des risques fondée sur des KPI intervient : elle traduit des risques abstraits en quelques indicateurs mesurés de manière cohérente, comparables entre équipes, systèmes et fournisseurs — et qui se traduisent en décisions sur le budget, les priorités, les dérogations et les escalades.
Le point critique : les KPI (indicateurs clés de performance) mesurent la performance et la mise en œuvre, les KRI (indicateurs clés de risque) mesurent l’exposition au risque. Dans de nombreux rapports, les deux sont mélangés. Cela conduit à des tableaux de bord apparemment « verts », alors que l’entreprise reste en réalité vulnérable (par exemple un bon taux de correctifs global, mais une forte vulnérabilité sur des systèmes exposés à Internet). Cet article montre quels indicateurs se sont avérés pertinents pour les risques informatiques, comment les définir, quelles sources de données sont typiquement nécessaires et comment structurer la gouvernance pour que audits et réalité opérationnelle concordent.
Pourquoi les indicateurs échouent souvent dans la gouvernance des risques
Les schémas d’erreur typiques sont étonnamment constants — indépendamment du secteur ou des outils :
- Trop d’indicateurs : les équipes remontent 30–60 valeurs, mais personne n’en tire de décisions. Conséquence : le reporting devient un exercice obligatoire, non un moyen de pilotage.
- Définitions hétérogènes : « systèmes critiques », « état des correctifs » ou « incident » signifient en exploitation, en sécurité et en audit des choses différentes. Cela rend les tendances inutilisables.
- Absence de lien avec les responsabilités : sans une logique RACI (Responsible, Accountable, Consulted, Informed) claire, il reste flou qui doit agir — et qui porte le risque.
- Métriques sans hygiène des données : si l’inventaire des actifs et les identités ne sont pas exacts, les indicateurs donnent une fausse impression de précision. Les questions d’audit ne peuvent alors pas être répondues.
- Pas de seuils ni de chemins d’escalade : une valeur « rouge » sans décision de suite définie ne produit que des discussions, pas de réduction du risque.
Une logique KPI fiable est moins une question de tableau de bord qu’une question de gouvernance : définitions, sources de données, seuils, catalogue de mesures, procédures d’exception et preuves d’audit doivent être cohérents.
Gouvernance des risques fondée sur des KPI : modèle de base, rôles et logique décisionnelle
Pour les risques informatiques, un modèle en trois niveaux s’est avéré pertinent et est également bien retraçable en audit :
1) Exposition au risque (KRI) : « Quelle est l’ampleur du risque actuellement ? »
Les KRI montrent la surface d’attaque ou de défaillance actuelle, par exemple les vulnérabilités critiques non corrigées dans des systèmes productifs exposés à Internet. Ce sont des indicateurs avancés, car ils augmentent avant les incidents.
2) Efficacité des contrôles (Control KPIs) : « Nos contrôles fonctionnent-ils ? »
Exemples : couverture MFA, tests de RESTauration réussis ou taux de réussite des changements. Ces KPIs montrent si les contrôles de gouvernance sont effectivement appliqués en exploitation.
3) Indicateurs d’impact (Outcome KPIs) : « Quels dommages/interruptions se produisent ? »
Exemples : temps d’arrêt non planifié, incidents de sécurité avec exfiltration de données ou coûts liés à des mesures d’urgence. Ces indicateurs sont importants, mais arrivent souvent trop tard pour permettre une action corrective.
L’attribution des rôles est importante : Accountable est typiquement un propriétaire de service ou propriétaire de système (pour le risque dans le périmètre concerné), Responsible correspond aux fonctions d’exploitation/de sécurité, et Consulted/Informed désignent la conformité, la protection des données, les achats et la direction. Sans cette attribution, les KPIs deviennent des « chiffres de sécurité » qui sont corrects sur le plan technique mais inefficaces sur le plan organisationnel.
Principes de sélection : de quelles métriques les responsables ont-ils réellement besoin
Si vous ne pouvez choisir que peu de métriques, elles doivent satisfaire ces quatre critères :
- Capacité de décision : la valeur doit pouvoir déclencher une action concrète (prioriser, autoriser, arrêter, exclure, escalader).
- Comparabilité : la valeur doit être cohérente dans le temps et entre unités (équipes/services/sites).
- Résistance à la manipulation : la métrique ne doit pas être « présentable en vert » en déplaçant les définitions ou en fermant des tickets sans réduire le risque.
- Preuve d’audit : source des données, méthode de calcul, responsabilité et justificatif doivent être reproductibles.
Concrètement : mieux vaut 10–15 métriques clés avec seuils clairs et logique d’action plutôt qu’un ensemble KPI ingérable. Des métriques détaillées complémentaires peuvent exister au niveau opérationnel, mais elles n’ont pas leur place dans le comité de direction.
Indicateurs clés pour les risques IT (avec définitions, seuils et sources de données typiques)
Ce qui suit est un ensemble de métriques pragmatiques. Vous pouvez l’utiliser comme modèle et l’adapter par entreprise selon la criticité, la régulation et l’architecture (On‑Prem, Cloud, Hybrid).
1) Couverture des actifs : notre visibilité est-elle complète ?
Pourquoi c’est pertinent : Sans inventaire fiable des actifs (terminaux, serveurs, ressources cloud, applications, interfaces), tous les KPIs en aval sont incertains. En audit, c’est souvent le premier point d’attaque.
- KPI : taux de couverture des actifs gérés = (actifs dans l’inventaire/CMDB avec propriétaire + criticité + statut du cycle de vie) / (total des actifs découverts)
- Seuils : objectifs de management par périmètre (p. ex. production/Internet) plus stricts que pour les réseaux de laboratoire
- Sources de données : CMDB, scanners de découverte, inventaire d’actifs cloud, MDM/EDR, inventaire réseau
Note de gouvernance : Définissez « actif » et « propriétaire » de manière univoque. Pour les logiciels métier et les solutions proches des processus, le propriétaire de service (fonctionnel/opérationnel) est généralement plus pertinent qu’un propriétaire d’hôte purement technique.
2) Couverture de criticité : où manque le contexte métier ?
KPI : Proportion d’actifs/services avec une criticité classifiée (p. ex. selon disponibilité, confidentialité, intégrité) et catégorie de données (données personnelles, confidentielles, publiques)
Pourquoi pertinent : Les délais de patch, le niveau de surveillance et les barrières au changement doivent dépendre de la criticité ; sinon cela crée soit une surcharge opérationnelle, soit un pilotage à l’aveugle.
3) Patch‑Compliance en tant que KRI : risque dû aux retards dans les zones critiques
Important : « Patch‑Compliance » n’est pertinente pour l’évaluation du risque que si elle est segmentée (p. ex. exposé à Internet, systèmes privilégiés, OT/production, bases de données stratégiques).
- KRI : Pourcentage de systèmes avec des mises à jour de sécurité en retard dans des classes de criticité définies (p. ex. > 14/30/60 jours au‑delà du SLA)
- KPI complémentaire : Temps médian jusqu’au patch (MTTP : Mean Time To Patch) pour les mises à jour critiques
- Sources de données : Patch‑Management, gestion de configuration, scanners de vulnérabilités, pipelines d’images cloud
Logique de seuil : Définissez pour chaque zone des seuils stricts et une procédure formelle d’exception. « Impossible de patcher actuellement » est une décision impliquant une acceptation du risque — pas un statut.
4) Vulnérabilités : vulnérabilités critiques exposées (risque d’exploitation)
Les comptes de vulnérabilités sans contexte sont inutiles. L’essentiel est la combinaison de la sévérité, de l’exploitabilité et de l’exposition.
- KRI : Nombre/part de « vulnérabilités critiques exploitables » dans des systèmes productifs accessibles depuis l’extérieur
- Optionnel : Part des findings avec un plan de remédiation défini et un propriétaire
- Sources de données : scanners de vulnérabilités, EDR, inventaire WAF/Ingress, scanners de sécurité cloud
Perspective d’audit : Documentez la manière dont « exploitable » est opérationnalisé (p. ex. Known Exploited Vulnerabilities, indices d’exploitation, flags de threat‑intel). Sans définition, cela devient une question d’opinion lors de l’audit.
5) Sécurité des identités et des accès : couverture MFA et accès privilégiés
Beaucoup d’attaques réussies sont pilotées par l’identité. Les indicateurs IAM (Identity and Access Management) doivent donc faire partie de la gouvernance des risques.
- KPI : Couverture MFA pour les comptes privilégiés et les accès à distance (comptes admin, VPN, console cloud, O365/Workspace)
- KRI : Nombre de comptes privilégiés sans propriétaire traçable ou sans ré‑certification régulière
- KPI : Temps jusqu’au deprovisionnement (offboarding) pour les rôles critiques
- Sources de données : IAM/IdP, PAM (Privileged Access Management), système RH, ticketing
Décision de gouvernance : Définissez quels rôles sont « privilégiés » (admins locaux, DB‑admins, Cloud‑owner, admin CI/CD, admin sauvegarde). Cette liste est un artefact d’audit et doit être versionnée.
6) Logging et détection : couverture, qualité, capacité de réaction
« Nous avons un SIEM » n’est pas un indicateur. Ce qui est mesurable, c’est si les sources pertinentes sont connectées et si les alertes conduisent à des décisions.
- KPI : Couverture des sources de logs dans les services critiques (authentification, actions admin, accès aux données, egress réseau)
- KPI: MTTD/MTTA (Mean Time To Detect/Acknowledge) pour les alertes de sécurité d’une gravité définie
- KRI: Part des alertes sans triage dans le SLA ou avec cause récurrente sans mesure
- Datenquellen: SIEM, EDR, IdP‑Logs, Cloud‑Audit‑Logs, Ticketing/IR‑Plattform
Conséquences opérationnelles: Un nombre élevé d’alertes n’est pas automatiquement négatif ; le problème est que les alertes ne soient pas traitées ou qu’aucune résolution durable des causes ne soit mise en œuvre.
7) Backup‑ und Recovery‑Risiko: Testquote, RPO/RTO‑Einhaltung
Le succès des sauvegardes seul ne constitue pas un filet de sécurité. L’essentiel est de savoir si la RESTauration fonctionne en conditions réelles.
- KPI: Part des systèmes critiques avec test de RESTauration régulier (selon plan, avec protocole)
- KPI: Respect des RPO/RTO (Recovery Point/Time Objective) lors des tests et des incidents réels
- KRI: Nombre de tâches de sauvegarde avec erreurs récurrentes ou sans chiffrement/immutabilité vérifiés (Immutable Backup)
- Datenquellen: système de sauvegarde, runbooks de test, protocoles d’urgence, supervision
Audit‑Evidenz: Les protocoles de test de RESTauration constituent une preuve solide. Important : périmètre, état des données, durée, écarts, validation par le responsable.
8) Change‑Risk: Änderungen als Haupttreiber für Ausfälle
Le change management est un levier de risque, pas seulement un processus ITIL. Pour les solutions numériques d’entreprise avec de nombreuses interfaces, cela est particulièrement pertinent.
- KPI: Change‑Failure‑Rate (part des changements avec rollback/incident dans une période définie)
- KPI: Part des changements avec vérification complète des risques (impact, plan de backout, preuve de test, security‑review pour les classes pertinentes)
- KRI: Part des «Emergency Changes» sans évaluation ultérieure ni analyse des causes
- Datenquellen: ITSM, logs de déploiement, supervision, post‑incident‑reviews
Governance‑Praxis: Définissez des classes de changement (standard/normal/emergency) et attachez‑y des exigences minimales et des obligations de preuve. Cela réduit les discussions au cas par cas.
9) Incident‑Response‑Reife: Geschwindigkeit, Qualität, Lerneffekt
Les KPI d’outcome (nombre d’incidents) dépendent fortement de la capacité de détection. La maturité se manifeste par les temps de réaction et l’apprentissage à partir des incidents.
- KPI: MTTR (Mean Time To RESTore) pour des indisponibilités de service définies
- KPI: Part des incidents de sécurité avec analyse complète des causes profondes et suivi des mesures
- KRI: Taux de récurrence des mêmes classes d’incidents (indique un défaut de prévention)
- Datenquellen: ITSM/IR‑Tool, postmortems, gestion des problèmes
10) Drittanbieter‑ und Lieferkettenrisiko: Steuerbarkeit statt Bauchgefühl
Le Third‑Party‑Risk est souvent le domaine où la gouvernance existe formellement, mais n’est pas suivie opérationnellement.
- KRI: Part des pRESTataires critiques sans évaluation de sécurité à jour, sans clauses contractuelles sur la notification d’incident/SLAs ou sans plan de sortie
- KPI: Temps pour clôturer les findings identifiés chez les fournisseurs
- Datenquellen: gestion des fournisseurs, données contractuelles, rapports d’audit, ticketing
Audit‑Perspektive: L’important n’est pas tant un «score» que la traçabilité : classification, exigences minimales, écarts, acceptation du risque, suivi.
Vorlage: KPI‑Steckbrief (Definition, Owner, Grenzwerte, Evidenz)
Pour éviter que des indicateurs ne deviennent sujets à interprétation, chaque indicateur de management doit disposer d’une fiche d’identité. La structure suivante est bien utilisable lors d’audits :
- Nom et objectif (quelle décision cela soutient‑elle ?)
- Périmètre (quels systèmes/services, quelles zones, quelles plages horaires)
- Définition/Formule (incl. filtres de données, exceptions, arrondis)
- Owner (Accountable) et responsables des données (Responsible)
- Seuils (vert/jaune/rouge) et procédure d’escalade
- Catalogue des mesures (quelles actions sont obligatoires en cas de jaune/rouge ?)
- Preuves (quels logs/reports font foi, où sont-ils stockés, combien de temps)
- Cycle de revue (mensuel/trimestriel, plus revue occasionnelle après incident majeur)
KPI-Steckbrief (Kurzvorlage)
KPI-Name:
Ziel/Entscheidung:
Scope (Services/Zonen):
Definition/Formel:
Datenquellen (Systeme, Reports):
Datenqualität/Validierung:
Owner (Accountable):
Bearbeitung (Responsible):
Grenzwerte (G/Y/R):
Eskalation (Gremium, Frist):
Pflichtmaßnahmen bei Gelb:
Pflichtmaßnahmen bei Rot:
Evidence (Ablage, Retention):
Review-Zyklus:
Letzte Anpassung/Version:Des indicateurs aux décisions : seuils, exceptions, acceptation du risque
Les indicateurs deviennent aptes à la gouvernance uniquement lorsque l’on sait quelle décision prendre pour quelle valeur. Cela peut être opérationnalisé avec trois éléments :
Les seuils doivent être liés à la criticité
Un SLA de patch de 30 jours peut être approprié pour des systèmes back‑office internes, mais il est souvent trop long pour des interfaces d’administration exposées sur Internet. Définissez des seuils par classe de criticité, et non une solution universelle.
Les exceptions nécessitent une date d’expiration et une compensation
Si un système n’est pas patchable (legacy, dépendance fournisseur, fenêtres de production), l’exception doit comporter :
- Justification du risque et approbation du Business‑Owner (Accountable)
- Date de fin (p. ex. 60/90 jours) ou plan de migration
- Contrôles compensatoires (p. ex. segmentation réseau, détection supplémentaire, accès uniquement via jump‑host)
- Obligation de preuve (éléments de preuve, qui a autorisé)
L’acceptation du risque est une décision, pas un état
En pratique, les risques disparaissent dans des colonnes « acceptés » sans qu’il soit clair qui assume quel risque résiduel. Mettez en place un format où l’acceptation du risque est documentée explicitement (périmètre, durée, risque résiduel, responsable). Cela réduit les risques « silencieux » qui s’exacerbent ensuite lors d’un incident.
Préparation à l’audit : ce que les auditeurs questionnent typiquement sur la gouvernance des KPI
Que vous vous aligniez sur ISO‑27001, BSI‑Grundschutz, des exigences proches de NIS2 ou des systèmes de contrôle interne : les auditeurs posent souvent les mêmes questions. Une gouvernance des risques KPI‑basée peut être très efficace ici — à condition d’être correctement documentée.
1) Traçabilité de la chaîne de données
D’où provient la valeur, comment est‑elle générée et est‑elle reproductible ? Si vous consolidez des données issues de plusieurs outils, documentez la logique de transformation (même s’il ne s’agit que d’un job de reporting).
2) Exhaustivité et périmètre
Quels systèmes sont inclus, lesquels ne le sont pas — et pourquoi ? Un périmètre défini consciemment est auditable ; un périmètre aléatoire ressemble à une faille de contrôle.
3) Éléments probants pour les mesures
« Nous avons priorisé » ne suffit pas. Les auditeurs veulent voir que des décisions ont été prises en cas de dépassement de seuils (tickets, validations de changement, dérogations, procès‑verbaux d’instances).
4) Vérification régulière de l’efficacité
Les KPI doivent être revus et adaptés en cas de changements d’architecture (migration cloud, nouvelle plateforme IAM, nouveau logiciel métier). Sans protocole de revue, l’ensemble de KPI paraît rapidement obsolète.
Perspective coûts et capacités : les indicateurs comme outil de budget et de priorisation
La gouvernance des risques échoue souvent non pas par manque de volonté, mais par manque de ressources. De bons indicateurs aident à allouer la capacité là où elle a le levier de risque le plus important. Trois modèles pratiques :
- Backlog basé sur les risques : les mesures sont priorisées non pas par intensité, mais par contribution au KRI (p. ex. réduction des « vulnérabilités critiques exploitables dans les Exposed Systems »).
- Contrôles minimaux finançables : pour chaque classe de criticité, définissez des standards minimaux (MFA, logging, tests de sauvegarde). Tout ce qui dépasse est traité comme un projet avec un business case.
- Dette technique transparente : si des systèmes legacy génèrent durablement des exceptions, cela devient une décision de management : modernisation, remplacement ou risque résiduel assumé. Les indicateurs fournissent la justification.
Il est important que les KPI ne soient pas introduits comme un « instrument de sanction ». Sinon, les équipes optimisent pour les chiffres plutôt que pour le risque (par exemple en réduisant le périmètre). La gouvernance doit donc toujours veiller à l’intégrité des données et à une incitation appropriée.
Plan de mise en œuvre en 6 semaines : de zéro à une gouvernance KPI robuste
Si vous avez aujourd’hui un reporting fragmenté, un démarrage léger et réaliste est essentiel. Un plan type :
Semaine 1 : définir le périmètre et les décisions de risque
- Définir les classes de criticité (services/applications, pas seulement les serveurs)
- Nommer l’instance de management (p. ex. Security‑/Risk‑Board) et définir les types de décision
- Sélectionner le Top‑10 des risques qui sont pilotables via des indicateurs
Semaine 2 : sélectionner l’ensemble de KPI et rédiger des fiches
- 10–15 indicateurs (KRIs + Control KPIs + quelques indicateurs de résultat)
- Pour chaque indicateur : fiche, propriétaire, seuils, logique d’action
Semaine 3 : connecter les sources de données et vérifier la qualité des données
- Confronter l’inventaire d’actifs/CMDB avec l’inventaire Discovery/cloud
- Tester les définitions (p. ex. « exposé », « critique », « en retard »)
Semaine 4 : standardiser le reporting et le dépôt des éléments probants
- Format de reporting uniforme (mensuel) incl. tendance et état des mesures
- Emplacement de dépôt pour les éléments probants (procès‑verbaux, dérogations, rapports de test) avec rétention
Semaine 5 : tenir un comité pilote et exercer les chemins d’escalade
- Simuler 2–3 cas réels en se basant sur les seuils
- Tester le processus d’exception et les autorisations
Semaine 6 : Stabiliser et passer en exploitation
- Adapter les définitions, éliminer les risques de ‚gaming‘
- Documenter proprement le RACI, informer les responsables
- Définir le cycle de revue et les déclencheurs de changement pour les ajustements de KPI
Liste de contrôle pour les managers : gouvernance des KPI opérationnelle
- Les KRI et KPI sont-ils clairement séparés (risque vs. performance) ?
- Chaque indicateur a-t-il un Owner (Accountable) avec mandat décisionnel ?
- Les seuils sont-ils couplés à la criticité et à l’exposition ?
- Existe-t-il une procédure formelle d’exception avec date de fin et compensation ?
- La chaîne de données est-elle documentée et auditable (source, calcul, preuves) ?
- Existe-t-il une routine de gouvernance fixe (ordre du jour, compte rendu, suivi des mesures) ?
- Les leçons tirées des incidents sont-elles réintégrées dans les seuils/contrôles ?
Conclusion : Peu d’indicateurs, décisions claires, preuves traçables
La gouvernance des risques basée sur les KPI n’est pas un projet de reporting, mais un mécanisme de pilotage : elle relie la réalité technique (actifs, vulnérabilités, identités, changements) aux décisions de management (priorités, budgets, exceptions, acceptation du risque). Le bénéfice principal apparaît lorsque vous ne « mesurez pas tout », mais définissez peu d’indicateurs stricts, couplés à la criticité et déclenchant des conséquences contraignantes en cas de dépassement de seuil. Ainsi, le risque n’est pas seulement documenté, mais réellement piloté — en exploitation, dans les projets et lors des audits.
La gestion des risques informatiques et la gouvernance informatique sont également importantes pour ce sujet. Cet article remet ces aspects en perspective de manière claire et montre ce qui importe au quotidien.