Registre et rapport des risques
Le registre des risques est le document où l'équipe de projet consigne chaque risque individuel: son identifiant, sa formulation en cause, événement et conséquence, son propriétaire, la réponse prévue et son statut. Le rapport des risques est un second document que l'équipe construit à partir du registre et des autres sources d'incertitude du projet. Il présente au mandant le risque global du projet, ses sources et une synthèse des risques individuels. Le PMBOK Guide compte les deux parmi les sorties du processus Identifier les risques. Les processus d'analyse, de réponse et de surveillance les complètent jusqu'à la clôture.
Objectif
Le registre dit à l'équipe ce qui peut arriver et qui s'en charge. Le rapport dit au mandant à quel point le projet entier est exposé et ce qui pèse le plus sur cette exposition.
Le PMBOK Guide définit le risque comme un événement ou une condition incertaine qui aurait, s'il se produisait, un effet positif ou négatif sur un ou plusieurs objectifs. Le registre porte donc les menaces et les opportunités dans les mêmes colonnes. L'analyse des opportunités traite en détail la part favorable et inscrit ses résultats dans le registre.
Avec le registre, l'équipe choisit une réponse pour chaque risque et nomme la personne qui la porte. Avec le rapport, le mandant décide de poursuivre le projet, de le réorienter ou de l'interrompre.
L'analyse et gestion des risques décrit le processus qui remplit le registre: identifier, analyser, évaluer, traiter. Elle fixe aussi les échelles de probabilité et d'impact que le registre reprend.
Usage
Quand l'utiliser
- Mandant ou comité de pilotage: le rapport lui donne à chaque séance l'exposition globale et les décisions attendues.
- Fin de phase ou de release: HERMES évalue les risques avant de libérer la phase ou la release suivante.
- Plusieurs propriétaires de risques: chaque ligne nomme qui surveille le déclencheur et qui agit.
- Équipe répartie sur plusieurs sites: un registre partagé tient la liste à jour sans atelier en présentiel.
- Contrôle indépendant attendu: un registre historisé montre quand un risque a été vu et ce qui a été décidé.
- Clôture du projet: le registre clos alimente les leçons apprises du projet suivant.
Quand ne pas l'utiliser
- Événement déjà survenu: c'est un problème, qui entre au journal des problèmes que tient le suivi des items.
- Mandat court à faible enjeu: le registre coûte plus qu'il ne protège. La liste des points en suspens du procès-verbal suffit.
Description
Le registre et le rapport
Le PMBOK Guide définit le registre des risques comme le document où l'équipe consigne les sorties des processus de gestion des risques. Il recense les risques individuels du projet. Ces processus l'alimentent du début à la fin du projet: identifier les risques, les analyser, planifier les réponses, mettre en œuvre les réponses et surveiller les risques. La taille et la complexité du projet décident de son volume. Le plan de gestion des risques fixe son format.
Le rapport des risques présente les sources du risque global du projet et une synthèse des risques individuels. L'équipe le construit pas à pas: chaque processus y ajoute ses résultats. Le risque global est l'effet de l'incertitude sur le projet dans son ensemble. Les risques individuels en font partie. Une estimation de charge fragile ou une technologie que l'équipe découvre peuvent y contribuer sans occuper de ligne au registre.
Additionner les lignes du registre ne rend donc compte que des risques individuels. Le PMBOK Guide définit l'exposition au risque comme une mesure agrégée de l'impact potentiel de tous les risques à un instant donné. Le rapport nomme ce qui pèse sur l'exposition du projet et la compare au seuil du mandant. Le PMBOK Guide appelle appétence au risque le degré d'incertitude qu'une organisation accepte en vue d'un gain. Le seuil de risque la chiffre: un écart toléré de ±5% autour du budget traduit une appétence plus faible qu'un écart de ±10%.
Ce qui entre au registre
Le PMBOK Guide demande à l'équipe de séparer, dès l'identification, les risques des non-risques: les préoccupations et les problèmes. Un problème s'est déjà produit ou se produit encore. Il entre au journal des problèmes. Un risque est un problème qui peut survenir plus tard. Quand un risque se réalise, sa ligne passe au statut «réalisé» et un problème s'ouvre au journal. Une préoccupation exprime une inquiétude sans dire ce qui pourrait arriver. Elle entre au registre une fois réécrite en événement.
Une hypothèse de planification va au journal des hypothèses. L'analyse des hypothèses et des contraintes en tire un risque quand l'hypothèse se révèle fragile: «le fournisseur livre en mars» devient «le fournisseur peut livrer après mars».
Écrire un risque: cause, événement, conséquence
Le PMBOK Guide propose de décrire un risque par sa cause, son événement et sa conséquence. Cette formulation sépare le risque de ses causes et de ses effets. Elle tient en une phrase: en raison de <cause>, <événement incertain> peut survenir, ce qui entraînerait <conséquence sur un objectif>.
La cause est un fait certain d'aujourd'hui: une décision prise, une contrainte, une situation. L'événement est incertain. La conséquence dit quel objectif il touche: délai, coût, périmètre, qualité. Chaque partie sert une décision. Une réponse préventive agit sur la cause. Le déclencheur signale que l'événement approche. La conséquence désigne l'objectif menacé, donc la personne à informer.
| Ligne écrite | Défaut | Ligne réécrite |
|---|---|---|
| «Manque de ressources» | Une cause sans événement ni conséquence | En raison de l'affectation de deux analystes à un second projet, ce second projet peut obtenir la priorité au printemps, ce qui retarderait de six semaines la spécification des contrôles. |
| «Retard de la mise en service» | Une conséquence sans cause ni événement | En raison de trois logiciels communaux différents, l'interface avec l'un d'eux peut échouer au test d'intégration, ce qui retarderait la mise en service dans douze communes. |
| «Le fournisseur a livré le lot 1 en retard» | Un problème: l'événement a eu lieu | Au journal des problèmes. Le registre accueille le risque qu'il révèle: le lot 2 peut subir le même retard. |
| «Les communes ne sont pas prêtes» | Une préoccupation sans événement | En raison de la charge des secrétariats communaux en fin d'année, la formation des utilisateurs peut glisser après la mise en service, ce qui doublerait les appels au support le premier mois. |
Une même cause produit souvent plusieurs événements. Chaque événement reçoit sa ligne, parce que chacun a son déclencheur et sa réponse. La cause commune se lit alors dans la colonne des causes. Le rapport la reprend comme source du risque global.
Les champs d'une ligne
Le PMBOK Guide fixe le contenu du registre à l'identification. Chaque risque reçoit un identifiant unique et une description assez précise pour ne se lire que d'une façon. L'équipe note les réponses envisagées et, s'il est connu, le propriétaire pressenti. L'analyse confirme le propriétaire et la planification des réponses confirme les réponses.
Le PMBOK Guide énumère d'autres champs. Le plan de gestion des risques retient ceux dont le projet a besoin.
| Champ | Contenu | Usage |
|---|---|---|
| Titre court | Quelques mots qui nomment le risque | Le citer en séance et dans le rapport |
| Catégorie | Technique, organisation, réglementation, fournisseurs… | Compter les risques par catégorie dans le rapport |
| Statut | Par exemple ouvert, surveillé, réalisé, clos | Trier les lignes qui demandent une action |
| Causes | Une ou plusieurs | Repérer les causes communes à plusieurs lignes |
| Effets sur les objectifs | Un ou plusieurs: délai, coût, périmètre, qualité | Désigner les personnes à informer |
| Déclencheurs | Les événements ou conditions qui signalent que le risque est sur le point de survenir | Lancer la réponse à temps |
| Référence WBS | Les activités touchées dans la structure de découpage du projet | Relier le risque au planning |
| Informations de temps | Date d'identification, période où le risque peut survenir, date où il cesse d'être pertinent, échéance d'action | Tenir les échéances et clore les lignes échues |
Les résultats des processus suivants s'ajoutent à droite: la probabilité et l'impact estimés, la priorité, la réponse retenue et l'avancement des actions. Les échelles de cotation et la matrice probabilité-impact appartiennent à l'analyse. Le choix de la réponse relève des stratégies de réponse aux risques.
Une ligne sans propriétaire nominatif n'est surveillée par personne: «l'équipe projet» ne guette aucun déclencheur. Un registre qui ne fait que grandir noie les risques ouverts parmi les lignes échues. L'équipe clôt donc toute ligne dont la date de pertinence est passée.
Le rapport des risques
À l'issue de l'identification, le rapport nomme les sources du risque global et indique celles qui pèsent le plus sur l'exposition du projet. Il résume aussi les risques individuels: le nombre de menaces et d'opportunités, leur répartition par catégorie, des indicateurs et leur tendance.
Les processus suivants enrichissent le rapport. L'analyse quantitative y ajoute par exemple la probabilité de tenir la date de mise en service, que calcule la simulation de Monte-Carlo. L'analyse de sensibilité classe les risques selon leur effet sur la date de mise en service ou sur le coût final. La planification des réponses ajoute les réponses au risque global, puis la surveillance leur effet.
Le PMBOK Guide applique au projet entier les familles de réponses des risques individuels. Pour éviter, l'équipe retire du périmètre les éléments les plus risqués. Pour atténuer, elle replanifie ou change la répartition des ressources. Pour accepter, le mandant fixe une réserve pour aléas sur l'ensemble du projet, que dimensionne l'analyse de réserve. Pour exploiter un risque global favorable, l'équipe ajoute au périmètre des éléments à forte valeur. Si aucune réponse ne ramène le projet dans le seuil, l'organisation peut l'interrompre. Le rapport se termine par les décisions qu'il demande au mandant. Chacune renvoie à la ligne du registre ou à la source qui la motive.
Ni le PMBOK Guide ni l'Orange Book du Trésor britannique ne fixent la mise en page du rapport. Le PMBOK Guide renvoie aux exigences de rapport du plan de gestion des risques. L'Orange Book demande à l'organe de direction de préciser la nature, la source, le format et la fréquence des informations qu'il attend. Pour chaque risque principal, il recommande de résumer sa position par rapport à l'appétence, le résultat des actions, les indicateurs d'alerte et la tendance.
Le piège courant est le rapport qui recopie les dix premières lignes du registre. Il ne dit pas si le projet entier sort du seuil ni quelle source l'y pousse. Le second piège est le rapport qui ne compte que les menaces. Il surestime l'exposition.
Tenir les deux documents à jour
Le PMBOK Guide rappelle que l'identification initiale reste incomplète, puisque certains risques n'apparaissent qu'en cours de projet. À intervalle régulier jusqu'à la clôture, l'équipe met le registre à jour: elle ajoute les nouveaux risques, réévalue les existants et ajuste les réponses. En développement agile, le PMBOK Guide donne l'exemple d'une équipe qui revoit les risques au début de chaque sprint. Elle les reprend avec les parties prenantes à la fin de chaque itération.
Le rapport accompagne chaque séance du comité de pilotage et chaque fin de phase. Sa tendance compare la revue du jour à la précédente: risques nouveaux, risques clos, risques réalisés. À la clôture, le registre complet part aux leçons apprises. Les réponses qui ont fonctionné et les risques que personne n'avait vus servent au projet suivant.
Dans HERMES
Dans HERMES 2022, le chef de projet conduit la tâche Gérer les risques. Il identifie les risques, les regroupe, les analyse et les évalue. Il définit pour chacun une stratégie (prévenir, réduire, externaliser, accepter) et des mesures. HERMES ne définit pas de résultat «registre des risques». En approche classique, la planification détaillée de la phase suivante prévoit toutefois d'«actualiser la liste des risques et les mesures» (7.4.5.3). Le chef de projet consigne les risques dans le rapport sur l'état du projet, puis les risques effectifs dans le rapport de phase ou de release. En approche classique, l'évaluation des risques à chaque fin de phase prépare la décision de libérer la phase suivante. En approche agile, elle a lieu à chaque fin de release.
HERMES connaît aussi un rapport sur la qualité et les risques. Le gestionnaire de la qualité et des risques l'établit à la demande du mandant. Il porte un regard indépendant sur le projet. Son contenu: mandat et délimitation, procédure, évaluation globale avec l'état du projet, évaluation de la qualité, évaluation des risques, recommandations. Le rapport des risques du PMBOK Guide est un document du projet, que l'équipe produit elle-même.
| PMBOK Guide | HERMES 2022 | Rédigé par | Lu par |
|---|---|---|---|
| Registre des risques | Aucun résultat dédié. Liste des risques actualisée à la planification de chaque phase. Les risques figurent dans le rapport sur l'état du projet | Chef de projet | Équipe de projet, mandant |
| Rapport des risques | Rubrique «risques» du rapport sur l'état du projet; risques effectifs du rapport de phase ou de release | Chef de projet | Mandant, comité de pilotage |
| Aucun équivalent | Rapport sur la qualité et les risques | Gestionnaire de la qualité et des risques, sur mandat du mandant | Mandant |
Considérations IA
Un modèle de langage réécrit une préoccupation en cause, événement et conséquence. Il repère les lignes qui décrivent un problème ou une cause seule. Il propose une catégorie, détecte les doublons et signale les lignes sans propriétaire nominatif ni déclencheur. Sur un export du registre, il compte les menaces et les opportunités par catégorie et rédige la tendance d'une revue à l'autre. Le PMBOK Guide cite l'IA générative et l'analyse de données parmi les techniques d'identification et d'analyse des risques.
Le modèle ignore les causes réelles du projet. Il produit des risques plausibles et génériques qui gonflent le registre. Une ligne proposée entre au registre quand un propriétaire la reconnaît et en accepte la charge. Le mandant juge l'exposition globale et le seuil. Le registre nomme des personnes, des fournisseurs et des faiblesses contractuelles. Il part vers un service d'IA externe si l'organisation l'autorise. Dans une administration suisse, le droit de la protection des données applicable et le lieu d'hébergement en décident.
Exemples
Un canton romand dématérialise les demandes de permis de construire. Le projet suit HERMES et termine sa phase Conception. Le registre compte 14 risques ouverts. L'extrait en montre cinq, dont deux opportunités. L'extrait omet les colonnes de l'analyse.
| Risque | Cause | Événement | Conséquence | Propriétaire | Réponse | Déclencheur | Statut |
|---|---|---|---|---|---|---|---|
| R-03 Menace · technique | Les communes utilisent trois logiciels de gestion des dossiers | L'interface avec le logiciel C échoue au test d'intégration | Douze communes restent au dossier papier à la mise en service | Architecte de la solution | Maquette d'interface testée avec l'éditeur avant le test d'intégration | L'éditeur ne livre pas sa spécification d'interface au 30 septembre | Ouvert |
| R-05 Menace · réglementation | La loi cantonale sur l'aménagement du territoire est en révision | Le Grand Conseil modifie la liste des pièces du dossier avant la mise en service | Formulaires et contrôles à refaire pour environ CHF 90'000 | Juriste du service de l'urbanisme | Liste des pièces paramétrable | La commission parlementaire adopte le projet de loi | Ouvert |
| R-07 Menace · organisation | Deux des trois analystes travaillent aussi sur la refonte du registre foncier | La refonte du registre foncier obtient la priorité au printemps | La spécification des contrôles prend six semaines de retard | Chef de projet | Escalade au comité de pilotage pour arbitrer la priorité | Le registre foncier avance sa date de mise en service | Ouvert |
| R-08 Opportunité · technique | Le canton voisin exploite un module de vérification des plans sur la même plateforme | Le canton voisin accepte de partager son module | Huit semaines de développement économisées | Chef de projet | Proposer une convention de partage | Réponse du canton voisin à la demande du 15 octobre | Ouvert |
| R-09 Opportunité · organisation | Neuf communes reçoivent déjà les plans en PDF | Ces communes acceptent d'ouvrir le service trois mois avant les autres | Coût du support calculé sur la charge mesurée avant la mise en service générale | Responsable du déploiement | Proposer un déploiement pilote | Accord des neuf secrétariats communaux | Ouvert |
Le rapport présenté au comité de pilotage regroupe ces lignes par source du risque global. Il porte aussi une source qui n'occupe aucune ligne du registre. L'équipe estime la charge de reprise des dossiers en cours à ±30% près. Cette incertitude pèse sur l'exposition au même titre que les risques individuels.
Visualisations
Le registre est un tableau: une ligne par risque, une colonne par champ. Le rapport tient sur une page. Il montre l'exposition par rapport au seuil, la répartition par catégorie et la tendance d'une revue à l'autre. La matrice probabilité-impact place les risques analysés selon leurs deux facteurs. Un schéma relie les lignes du registre aux rubriques du rapport. Un second suit les deux documents au fil des cinq processus de gestion des risques.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Fixer dans le plan de gestion des risques les champs du registre, les catégories, le seuil du mandant et le contenu du rapport. |
| Exécution | Moyen | Un atelier d'identification au démarrage, puis une revue courte du registre à chaque point d'avancement ou à chaque sprint. |
| Documentation | Élevé | Tenir chaque ligne à jour jusqu'à sa clôture et produire le rapport avant chaque séance du comité de pilotage. |
Outils
Un tableur suffit pour un registre de quelques dizaines de lignes: des listes déroulantes pour la catégorie et le statut, un filtre sur les échéances. Un outil de suivi comme Jira ou Azure DevOps gère les risques comme des tickets d'un type dédié. Il historise chaque changement de statut et notifie le propriétaire. Les logiciels de gestion des risques et les modules de gouvernance, risque et conformité (GRC) consolident plusieurs projets et gardent une piste d'audit. L'équipe rédige le rapport dans un traitement de texte ou sur une diapositive. Un outil de tableaux de bord comme Power BI le tire d'un export du registre. Pour une administration suisse, le lieu d'hébergement des données guide le choix dès que le registre nomme des fournisseurs ou des personnes.
Sources
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8e éd., PMI: le risque, le problème, le risque global, l'appétence, le seuil et l'exposition (§2.7.1); l'identification itérative et la séparation des risques et des non-risques (§2.7.2.2); l'exemple agile et l'IA générative (§2.7.3); le contenu du registre et du rapport des risques (Section 4, entrées Risk register et Risk report); les stratégies pour le risque global (Section 5).
- Chancellerie fédérale, HERMES 2022, Manuel de référence Gestion de projet: la tâche Gérer les risques (5.4.3.41); la planification détaillée de la phase suivante (7.4.5.3); les résultats Rapport de phase (4.4.1.29), Rapport sur l'état du projet (4.4.1.36) et Rapport sur la qualité et les risques (4.4.1.42).
- HM Treasury, The Orange Book: Management of Risk, mai 2023, section D «Risk reporting»: les informations que l'organe de direction précise et leur présentation résumée pour chaque risque principal.