Un registre des risques devient utile à la décision quand les risques prioritaires, leurs responsables et les prochaines réponses sont lisibles. Pour raconter les faits, utilisez une data story pour présentation (en anglais) : méthode et date d’abord, exposition ensuite, puis décision attendue.
Une fois les descriptions des risques vérifiées, vous pouvez utiliser la création de présentations à partir de texte pour préparer les diapositives. Gardez le registre original et les liens vers les preuves à portée de main : produire un support ne vaut pas approbation d’une réponse au risque.
Documenter méthode et date
Indiquez l’échelle, la période et la date des données. Précisez si probabilité et impact sont multipliés ou si une autre règle est utilisée. Une ancienne note ne doit pas être présentée comme un état actuel.
Un impact fort et une probabilité faible ne demandent pas la même décision qu’un événement fréquent mais facile à contenir. N’inventez pas de probabilité précise lorsque les données ne permettent qu’une estimation qualitative.
Rendre les risques prioritaires lisibles
Décrivez chaque risque par sa cause, l’événement possible et son impact. Séparez le niveau inhérent du risque résiduel après réponse. Montrez l’incertitude plutôt que d’inventer des probabilités précises.
Un obstacle technique n’est pas le dommage qu’il peut provoquer. Cette distinction évite de compter deux fois la même conséquence.
Prenons une migration du système de gestion des identités. R-01 est un exemple de planification fictif, et non le bilan d’une migration terminée.
| Champ de R-01 | Entrée pour la migration des identités |
|---|---|
| Objectif et période | Terminer les tests du parcours complet avant le lancement prévu ; évaluer la période jusqu’à la décision de bascule. |
| Cause | La correspondance des rôles entre les anciens et nouveaux systèmes d’identité reste à confirmer. |
| Événement possible | Le nouveau parcours d’authentification et d’autorisation n’est pas prêt pour les tests de bout en bout au moment de décider la bascule. |
| Impact | L’équipe ne peut pas terminer les tests requis ; le lancement pourrait être reporté. La durée d’un éventuel retard n’est pas encore établie. |
| Responsabilité | Le responsable de la migration signale les changements ; le sponsor du projet autorise une modification du lancement. |
| Prévention et preuve | Confirmer les correspondances de rôles et tester des parcours représentatifs d’administrateurs, d’utilisateurs standard et de comptes de service. Conserver la vérification des correspondances et les résultats, y compris les échecs. |
Si l’échéance des tests est déjà dépassée, le jalon manqué est un problème avéré, pas une probabilité future. Reliez le suivi de ce problème à R-01 et conservez l’historique. Évaluez séparément l’incertitude restante, par exemple son effet sur une nouvelle date de lancement, sans noter une seconde fois l’événement déjà survenu.
Vérifier responsables et réponses
Chaque réponse doit avoir un responsable, un état, une échéance et une preuve attendue. « En cours » n’est pas une prochaine étape vérifiable. Sans responsable ou date, le point reste une décision ouverte.
Pour R-01, fixez une alerte précise : si la confirmation des rôles reste bloquée pendant deux cycles hebdomadaires consécutifs de reporting, le responsable de la migration sollicite le sponsor. N’attendez pas le second cycle si la décision de bascule ou une condition de sécurité impose d’agir plus tôt. Les deux cycles constituent une règle de cet exemple de projet, pas un seuil universel.
Le plan de secours consiste à reporter la bascule et à maintenir le service d’identité existant pendant les tests manquants. Indiquez qui peut approuver cette option, si l’ancien service peut rester pris en charge et quelles conditions de sécurité et d’exploitation s’appliquent. Le responsable de la migration la propose ; le sponsor doit approuver explicitement le changement de lancement avant qu’il soit considéré comme autorisé.
Une baisse du risque résiduel exige la confirmation des rôles et les résultats des tests relancés. Clore un ticket ou réussir une seule connexion ne prouve pas que les trois parcours fonctionnent. Tant que les échecs ne sont pas résolus ou acceptés en connaissance de cause par la personne habilitée, montrez l’exposition restante et le prochain point de revue.
L’Orange Book du HM Treasury relie le traitement des risques aux responsabilités d’approbation, au suivi et aux plans de secours. Les actions de R-01 sont un exemple de projet, pas une procédure imposée par ce guide.
La prochaine étape peut être un contrôle technique, une clause à vérifier ou un test.
Ne colorez pas ces points de décision ou d’escalade artificiellement en vert.
Structure courte du support
- Question de décision et date des données
- Méthode et échelle
- Matrice ou liste priorisée
- Risques majeurs, causes et impacts
- Réponses, responsables et risques résiduels
- Décisions et prochaine vérification
Gardez les lignes détaillées du registre et les sources en annexe. La diapositive principale ne conserve que ce qui change une ressource, une escalade ou une hypothèse.
Terminer par la prochaine vérification
Concluez par les décisions et la date du prochain contrôle.
Un score décrit une méthode, pas l’avenir. Séparez faits confirmés, hypothèses et signaux à suivre. La direction peut ainsi arbitrer ressources ou escalade sans attribuer au registre une précision qu’il n’a pas.
