Une seule vue des risques pour le conseil d’administration, pas dix registres distincts
Les conseils d’administration sont censés superviser les risques de l’entreprise, mais l’information qu’ils reçoivent est souvent éclatée entre des registres, des échelles et des cycles de reporting distincts. Une méthodologie commune de gestion des risques d’entreprise (ERM) transforme ces registres des risques distincts en une vue unique qui permet au conseil d’agir.
En bref. Les conseils d’administration n’ont pas besoin d’un rapport sur les risques de plus. Il leur faut une vue unique et partagée, qui applique la même méthodologie de cotation à tous les domaines, montre le risque brut et le risque résiduel, et indique clairement la prochaine décision à prendre.
La supervision des risques par le conseil, sans vue partagée
La directive NIS 2 confie explicitement la responsabilité de la gestion des risques à l’organe de direction. L’article 20 impose aux dirigeants d’approuver les mesures de gestion des risques, d’en superviser la mise en œuvre et de suivre eux-mêmes une formation. Il prévoit aussi qu’ils peuvent être tenus responsables des manquements. L’article 21 précise ce que ces mesures doivent couvrir au minimum. DORA fait de même pour le secteur financier : l’organe de direction reste responsable en dernier ressort du cadre de gestion du risque lié aux TIC. La norme ISO 27001, dans sa clause « Leadership », demande que la direction prenne en main le processus de gestion des risques, et pas seulement qu’elle en soit informée.
Les règles désignent clairement qui doit tenir la barre. Dans la pratique, la direction manque souvent de la vue d’ensemble nécessaire pour le faire. Un comité de direction reçoit un rapport d’audit, un tableau de bord cyber, une synthèse de conformité et un état des risques financiers. Quatre documents, dont aucun ne répond à la question qui est réellement sur la table : où en sommes-nous en tant qu’organisation, et que devons-nous décider maintenant ?
Pourquoi la gestion des risques d’entreprise reste en silos
La cause est rarement la mauvaise volonté. Elle est structurelle. Le risque IT relève du CIO, le risque cyber du CISO, le risque opérationnel et financier du CRO, et le risque lié à la protection des données du DPO. Chaque fonction travaille correctement dans son propre référentiel, mais chacune utilise une échelle, un vocabulaire et un horizon temporel différents.
- CIO Risque IT
- CISO Risque cyber
- CRO Risque opérationnel & financier
- DPO Risque protection des données
Un même langage Méthodologie commune
- Probabilité 1–5
- Impact 1–5
- Risque brut & résiduel
Une seule vue pour le conseil Des risques comparables
- Propriétaires identifiés
- Décisions claires
Résultat : les chiffres ne s’additionnent pas. Un risque cyber « élevé » sur une échelle à trois niveaux et une « classe de risque 4 » issue d’un modèle opérationnel ne peuvent pas être comparés de manière pertinente. Sans échelle commune, le conseil ne peut pas les mettre en balance. La discussion se rabat alors sur le risque signalé avec le plus d’insistance, ou sur celui lié au dernier incident en date.
Quand je mets en place un registre des risques, je commence toujours par la méthodologie, pas par les risques. Sans une échelle unique acceptée par tous, toute consolidation n’est que fausse précision.
À quoi ressemble un registre des risques d’entreprise exploitable
Le modèle qui m’a été le plus utile dans les grandes organisations est volontairement simple. Prenons un environnement organisé en différents domaines.
Le cœur de métier : services de données partagés, services de paiement et services financiers, services à la clientèle, services de support IT d’entreprise et services de support corporate.
Deux domaines transversaux couvrent la sécurité de l’information et la protection des données.
Le dernier domaine couvre les bâtiments et le facility management.
| ID du risque | Description | Catégorie | P | I | Brut | Mesures d’atténuation | P rés. | I rés. | Résiduel | Propriétaire |
|---|---|---|---|---|---|---|---|---|---|---|
| ENT-01 | Des processus clés dépendent de composants hérités vieillissants, maintenus par un groupe de personnes de plus en plus restreint. | Technologie et continuité | 4 | 4 | 16 · Critique | Programme de décommissionnement par phases ; feuille de route d’architecture ; capitalisation des connaissances. | 3 | 3 | 9 · Modéré | [Nom de la personne] |
| SDS-01 | Des erreurs de qualité des données faussent la base de calcul d’un processus clé. | Qualité des données et de l’information | 4 | 5 | 20 · Critique | Règles de validation à la saisie ; rapprochement avec les enregistrements sources. | 2 | 5 | 10 · Élevé | [Nom de la personne] |
Ce tableau reprend les mêmes colonnes pour chaque risque : identifiant du risque, description, catégorie, probabilité (1–5), impact (1–5), score brut, mesures d’atténuation, probabilité résiduelle, impact résiduel, risque résiduel et propriétaire nommément désigné. Quatre éléments font la différence.
Une seule taxonomie. La probabilité est étalonnée sur la fréquence, de « moins d’une fois tous les cinq ans » à « une fois par mois ou plus souvent ». L’impact est coté sur plusieurs dimensions à la fois. Par exemple : l’impact financier, par tranches en euros ; l’impact opérationnel, en termes de prestation de services et de conformité ; et l’impact sur la réputation. C’est la dimension la plus significative qui fixe le score.
Quatre niveaux résument le résultat : Faible (1–4), Modéré (5–9), Élevé (10–14), Critique (15–25).
Le brut face au résiduel, comme preuve. Le brut, c’est l’exposition sans mesures. Le résiduel, c’est ce qui subsiste une fois les mesures en place. L’écart entre les deux est la seule preuve qu’un investissement dans les contrôles a eu le moindre effet.
Une traduction financière. Comme l’échelle d’impact est liée à des seuils en euros, un risque technique peut être discuté dans le langage qu’un comité de direction utilise déjà.
Un propriétaire nommément désigné. Pas un service. Une personne.
Au-dessus se trouve un seul onglet de synthèse : par domaine, le nombre de risques, les scores brut et résiduel les plus hauts, et une cartographie des risques qui positionne chaque identifiant de risque dans la grille probabilité × impact. C’est la vue dont le conseil a besoin. Une seule feuille, tous les domaines, les cas atypiques visibles d’emblée.
La dernière pièce est l’arbre de décision, et il repose délibérément sur le risque résiduel plutôt que sur le risque brut. La réponse à apporter devient explicite :
- Résiduel 1–4 : le comité de direction prend acte du risque, qui passe en surveillance périodique.
- Résiduel 5–9 : le propriétaire assure le suivi, avec une revue semestrielle et un reporting sans décision.
- Résiduel 10–14 : le comité de direction valide le plan d’atténuation, désigne un propriétaire, fixe une échéance et débloque des ressources.
- Résiduel 15–25 : escalade immédiate, avec une décision sur le budget ou un appui externe.
Risque brut et risque résiduel : un exemple
Prenons un risque que toute grande organisation reconnaîtra : des processus clés qui dépendent de composants hérités vieillissants, maintenus par un groupe de personnes de plus en plus restreint. Probabilité 4 — les perturbations surviennent plusieurs fois par an. Impact 4 — une panne touche un processus clé et a des conséquences financières sérieuses. Risque brut de 16, donc Critique.
Les mesures sont bien connues : un programme de décommissionnement par phases, une feuille de route d’architecture et la capitalisation des connaissances, pour que la dépendance envers des individus diminue. La réévaluation donne une probabilité résiduelle de 3 et un impact résiduel de 3, soit un risque résiduel de 9, Modéré. Pour le comité de direction, c’est une décision claire. Pas d’escalade, mais un propriétaire, une échéance et une revue semestrielle.
Le cas où l’impact ne bouge pas est tout aussi instructif. Pour des erreurs de qualité des données qui faussent la base de calcul d’un processus clé, les règles de validation et le rapprochement font baisser la probabilité de 4 à 2. L’impact reste à 5 : les conséquences demeurent tout aussi graves. Le risque brut de 20 devient un risque résiduel de 10 — toujours Élevé, donc toujours du ressort du comité de direction. La différence entre réduire la probabilité et réduire l’impact, c’est précisément la conversation qu’un conseil d’administration devrait avoir.
Pourquoi les registres des risques d’entreprise finissent par ne plus tenir dans un tableur
Je construis d’abord ce type de registre dans Excel, et c’est voulu. Cela impose de la discipline, cela ne coûte rien et cela rend la méthodologie visible pour tous ceux qui y travaillent. Mais dès que le registre doit rester vivant, il cale.
Les versions se multiplient, et il n’est plus évident de savoir laquelle fait foi. Le tableur n’a ni flux de travail ni rappels, si bien que le suivi dépend de l’agenda d’une seule personne. Les mesures ne renvoient ni aux contrôles qu’elles mettent en œuvre, ni aux preuves que ces contrôles fonctionnent. Le registre est une photo à un instant donné : il ne montre ni tendance, ni agrégation dans le temps, ni piste d’audit indiquant qui a modifié quoi, et quand. Les mêmes risques et les mêmes mesures doivent être réutilisés à la main pour NIS 2, CyFun, DORA et le RGPD, un travail qui recommence à chaque changement.
Ce que change une plateforme GRC
C’est ce que nous construisons avec Euraika GRC : la même logique — domaines, taxonomie, risque brut et résiduel, propriétaires, arbre de décision — maintenue vivante. Les risques sont reliés aux contrôles qui les traitent, et aux référentiels dans lesquels ces contrôles figurent, de sorte qu’une même mesure répond à plusieurs obligations. Les propriétaires reçoivent des tâches de suivi plutôt qu’un e-mail. Les preuves sont conservées avec la mesure, pas dans un dossier séparé. Le risque résiduel est recalculé lorsque l’évaluation ou la mesure sous-jacente change. Le reporting au comité de direction est prêt, au lieu d’être assemblé à la main chaque trimestre. Le jugement de cotation, lui, reste là où il a sa place : l’IA assiste, l’humain décide.
Ce que le reporting des risques doit apporter aux CIO, CISO et CRO
CIO : rendre visibles en euros la dette technique et les dépendances en chaîne. Un dossier de systèmes hérités signalé comme risque résiduel Élevé sur la cartographie des risques n’ouvre pas la même conversation que le même dossier enfoui dans une note d’architecture.
CISO : traduire le risque cyber en langage métier et en reporting au niveau du conseil. Non pas parce que le conseil serait incapable de suivre la technique, mais parce qu’il doit prendre ses décisions budgétaires sur la même échelle que celle qu’il applique au risque opérationnel et financier.
CRO : instaurer une méthodologie unique qui permet de comparer les risques d’un domaine à l’autre. C’est la condition préalable à tout ce qui suit.
Vous mettez en place un registre des risques d’entreprise, ou vous cherchez à redonner vie à un tableur existant ? En une heure, nous pouvons vous présenter Euraika GRC ou discuter de la méthodologie qui sous-tend une vue des risques d’entreprise exploitable. Dans les deux cas, vous irez plus loin qu’avec une version de plus du même fichier.
Thomas Baeck est spécialiste de la sécurité, avec une expérience de terrain en architecture de sécurité et comme CISO. Dans des organisations publiques et privées, il construit des registres des risques, des SMSI et des programmes NIS 2 qui remontent jusqu’au comité de direction, et il travaille sur Euraika GRC, la plateforme qui fait passer la conformité d’un effort périodique à une activité continue.

