## 💡 [Feature Discussion] Gouvernance multi-acteurs – Direction, Risk Manager, Risk Owner

[oliboub]

Contexte

Deming est un excellent outil, très bien conçu du point de vue du RSSI. Après avoir vécu des comités de pilotages avec gestionnaire de risques, je souhaite soumettre quelques observations et suggestions d'amélioration, sans prétention : je ne suis pas expert du domaine et je peux me tromper sur certains points.

En particulier, il peut y avoir plusieurs niveaux de responsabilité :

Niveau	Acteur	Rôle attendu
Top Management	Direction Générale	Définit l'appétence au risque, valide les budgets et les objectifs de sécurité
Coordination	RSSI	Chef d'orchestre : s'assure que les risques sont couverts, que les contrôles sont réalisables et que les actions sont bien réalisées
Gestion des risques	Risk Manager (indépendant du RSSI)	Identifie, évalue et documente les risques — sans être juge et partie . rapporte à la direction générale
Propriétaire du risque	Chef de métier / DSI	"Possède" le risque sur son périmètre, valide l'acceptation ou le traitement
Opérationnel	Équipes IT	Implémente et maintient les contrôles

Note : ce modèle multi-acteurs concerne surtout les organisations de taille importante, où un Risk Manager indépendant du RSSI est envisageable. Dans les petites structures, le RSSI cumule naturellement ces rôles.

---

🧩 Suggestions d'amélioration

1. Modèle de données : lier explicitement Risques → Contrôles → Mesures

Aujourd'hui, il semble manquer un lien explicite entre les risques et les contrôles. La logique hiérarchique naturelle serait :

Domaine → Risque → Contrôle → Mesure

• Un risque appartient à un domaine
• Un contrôle est rattaché à un risque (et à un domaine)
• Une mesure est attachée à un contrôle

Suggestion concrète : à la création d'un contrôle, ajouter un champ "Risque associé".

2. Navigation et dashboard : suivre la logique hiérarchique

Le menu et le tableau de bord gagneraient à refléter cette hiérarchie :
Domaines > Risques > Contrôles > Mesures

Dans le dashboard, ajouter :

• Liste des risques sans contrôle associé
• Liste des contrôles sans mesure associée

Cela permettrait d'identifier rapidement les lacunes de couverture.

3. API Risques

Il semble manquer une API sur les risques . Une API /risks permettrait l'intégration avec des outils tiers et les remontées vers la Direction.

4. Rôles utilisateurs : élargir au-delà du périmètre RSSI

Les 4 rôles actuels (Admin, User, Auditee, Auditor) ne couvrent pas les besoins multi-acteurs. Voici une proposition :

Groupe	Accès suggéré
Direction	Dashboard, niveau de risque global, matrice des risques, mesures
Risk Manager	Scoring, domaines, attributs, matrice des risques, risques
Risk Owner	Ses risques, ses contrôles, les mesures associées, matrice de ses risques
Control Actor	Mesures et contrôles qui lui sont assignés

Le groupe actuel ne permet que l'association aux contrôles — il manque la notion de "propriétaire de risque" par domaine.

5. Lien Domaines ↔ Groupes / Responsables

Un lien entre un domaine et un groupe d'utilisateurs permettrait de matérialiser les responsables de risques par domaine, ce qui est cohérent avec une organisation décentralisée de la gestion des risques.

---

✅ En résumé

Ces suggestions visent à élargir l'outil au-delà du périmètre RSSI, pour permettre à la Direction, aux Risk Owners et à un Risk Manager indépendant d'utiliser Deming dans leur périmètre.

Ce n'est qu'un point de vue . Aucun jugement ni analyse de valeur. Je me dis juste que ça pourrait aider à l'adhésion à l'outil.

[dbarzin]

Bonjour @oliboub,

Tout d'abord, désolé pour la réponse tardive, et merci pour cette analyse très structurée. Ce type de retour, basé sur une expérience concrète des comités de pilotage, est précieux pour faire évoluer Deming.

Voici mes réponses point par point :

1. Lien Risques → Contrôles → Mesures

Le lien existe déjà dans le modèle de données : il y a une table control_risk, et la chaîne complète est donc Risque → Mesures → Contrôles. Un risque peut ainsi être relié aux contrôles qui le couvrent au travers des mesures associées.

2. Philosophie de l'outil

Il est important de préciser que Deming est un outil orienté sur le contrôle régulier du SMSI : ce n'est pas un outil d'analyse de risques. Les risques y sont mis en avant pour donner du contexte aux contrôles et prioriser les actions, mais l'analyse de risques elle-même (identification, évaluation détaillée) a vocation à être menée dans un outil dédié.

3. API Risques

Bien vu : cette API est effectivement manquante. Elle sera ajoutée prochainement.

4. Rôles utilisateurs

Concernant le rôle "Direction", je ne pense pas que la direction générale se connectera directement à l'outil — elle consomme plutôt des rapports et des tableaux de bord présentés en comité. Un rôle dédié ne me semble donc pas nécessaire. Les autres propositions (Risk Manager, Risk Owner, Control Actor) sont en cours d'analyse.

5. Lien Domaines ↔ Groupes / Responsables

Ce point est effectivement très pertinent : matérialiser les responsables de risques par domaine s'inscrit bien dans une organisation décentralisée. C'est dans la feuille de route.

Encore merci pour ce retour détaillé, n'hésite pas à poursuivre la discussion sur l'un ou l'autre de ces points.

[oliboub]

Bonjour Didier,

Merci. Je prends en compte tes réponses, et j'essaye d'intégrer.

1. Si on a bien le lien RIsques --> Contrôles --> mesures, c'est bien. Je comprends que tu ne mettes pas les risques en avant si tu estimes que ça doit être intégrédans un autre outil, peut-être plus orienté entreprises pour les risques globaux.

On peut avoir deux approches:
1.1) Soit c'est deming qui devient l'outil d'entreprise , plus large que l'IT, et à ce moment il faudrait ajouter plus d'informations dans risques comme par exemple celui qui a identifié le risque et aussi les documents attachés

1.2) Soit ça ne gère que les risques IT ( comme préconisé) et il faudrait ajouter un champs risque ID pour faire le lien entre les 2 outils.
Et peut-être prévoir la possibilité d'importer et d'exporter les données par l'API. pour éviter les pertes ou modifications d'informations (point 3)

Pour les 2 cas, ce qui serait peut-être utile, c'est la possibilité de modifier l'ordre des icônes, avoir risque en premier. (Par exemple par un drag an drop des icônes pour laisser à l'utilisateur le choix de son ordre) et pourquoi pas pouvoir cacher certaines icônes en fonction du profil.?

D'autre part, dans la documentation:

• quand on on clique sur documentation, dans ?, il faudrait ouvrir une nouvelle fenêtre plutôt que d'écraser celle de deming.
• et Ajouter "Risque" dans définitions de l'introduction.

A Suivre.

[dbarzin]

Un retour sur ce point :

• L'API pour les risques est disponible.
• le lien ? ouvre une nouvelle fenêtre
• "Risque" a été ajouté dans définitions de l'introduction

[oliboub]

Merci, ça fonctionne.