Construire un registre des risques du projet

Auteur: AILesson7 min de préparationTesté avec:ChatGPTRévisé: 2026-08-28

Réponse rapide

Transformer des événements incertains en risques attribués et fondés sur des preuves, avec déclencheurs, réponses et dates d'examen. Fournir: Contexte du projet, Incertitudes et preuves connues, Évaluation et gouvernance. Résultat attendu: Un registre des risques priorisé avec justification des scores, mesures de réponse, plans de secours et lacunes.

1

Ajouter votre contexte

Votre texte reste dans ce navigateur. AILesson Prompts ne l’envoie ni à un modèle ni à un serveur.

2

Votre prompt

Les champs non remplis restent visibles sous forme d’espaces réservés, afin que vous puissiez quand même copier et modifier le prompt.

Construisez un registre des risques du projet.

Objectifs, périmètre, phases, dates, parties prenantes et état :
[project]

Hypothèses, incidents, dépendances, estimations, contraintes et signaux d'alerte :
[evidence]

Échelles, appétence au risque, seuils d'escalade, responsables et fréquence des examens :
[method]

Formulez chaque risque comme une relation incertaine cause-événement-conséquence, et non comme un problème déjà présent ou un sujet vague. Distinguez des risques les problèmes actifs, les hypothèses, les dépendances et les opportunités. Pour chaque risque, fournissez un identifiant, un énoncé, les preuves, l'objectif concerné, la probabilité, les dimensions de l'impact, le score et sa justification, la proximité, les indicateurs, la prévention ou l'atténuation, le déclencheur et la réponse du plan de secours, le responsable explicite du risque ou « Non attribué », les responsables des actions, le prochain examen et le risque résiduel. Utilisez uniquement les échelles et les preuves fournies ; n'inventez ni probabilités, ni responsables, ni budget, ni contrôles. Repérez les doublons et les risques corrélés, montrez l'incertitude des scores et signalez les informations manquantes susceptibles de modifier la priorité.
Essayer dans le Playground
Privé par défautL’assemblage du prompt se fait localement dans votre navigateur. Évitez de placer des informations confidentielles dans un service d’IA, sauf si votre organisation l’autorise.

De l'entrée au résultat

Un exemple détaillé

Voyez comment un contexte concret transforme cette recette en résultat utilisable.

Entrée réelle

Contexte du projet
Migrer 18 traitements internes de reporting vers un nouvel entrepôt de données avant le 31 janvier. L'inventaire de la phase 1 est terminé ; la construction commence le 1er novembre. Les rapports Finance doivent rester disponibles et la clôture mensuelle a lieu du 25 au 31 janvier. Le sponsor est le CFO ; la responsable de livraison est Imani ; les équipes de la plateforme de données et Finance participent.
Incertitudes et preuves connues
Trois traitements comportent des transformations non documentées. Les tests de charge de la plateforme n'ont pas commencé. Un connecteur fournisseur est prévu pour le 15 décembre selon une estimation transmise par e-mail, et non un contrat. Un ingénieur part le 20 décembre ; la capacité de remplacement n'est pas confirmée. Le système source a connu deux interruptions de quatre heures au trimestre précédent. Aucune réserve budgétaire n'est indiquée.
Évaluation et gouvernance
Probabilité de 1 Rare à 5 Presque certaine ; impact de 1 Mineur à 5 Critique. Score=L×I. Les scores de 15 ou plus sont escaladés au sponsor. La responsable de livraison anime un examen chaque lundi. Seuls les responsables identifiés et comptables du risque peuvent être attribués ; les autres restent Non attribués.

Exemple de sortie

R1 Si les transformations non documentées sont mal comprises, les résultats migrés risquent de ne pas se rapprocher, ce qui entraînerait des rapports Finance erronés. Preuve : trois traitements non documentés. Justification de la probabilité 4 : la lacune connue affecte 3/18 ; impact 5 : exactitude Finance/clôture. Score 20 — escalade. Responsable : Non attribué. Indicateurs : exceptions de correspondance et échecs de rapprochement. Atténuation : documenter la logique et créer des tests source-cible signés avant la fin de la construction ; responsable de l'action Non attribué. Déclencheur du plan de secours : tout échec critique de rapprochement avant la bascule ; conserver le traitement concerné sur le système source et escalader. Le score résiduel ne peut pas être défini tant que les contrôles ne sont pas testés.

R2 Si le connecteur n'est pas livré à la date estimée du 15 décembre, les constructions dépendantes risquent de réduire la durée des tests avant la clôture. L3 en raison de l'estimation non contractuelle ; I4 pour le calendrier et la qualité ; score 12. Responsable Non attribué. Confirmer le statut contractuel et la dernière date d'arrivée viable ; ne définir un connecteur de repli ou une modification du périmètre qu'avec approbation. R3 si la capacité de remplacement n'est pas disponible après le 20 décembre, la résolution des défauts risque de ralentir pendant la bascule. L3/I4=12 ; preuves et plan de ressources incomplets. R4 si la tenue en charge est insuffisante, les rapports risquent de se dégrader pendant la clôture ; aucun score responsable ne peut être attribué tant que la charge attendue et les tests ne sont pas définis.

Problème actif : trois transformations ne sont actuellement pas documentées. Dépendance : connecteur fournisseur. Corrélation : R2/R3/R4 peuvent conjointement réduire la durée des tests. L'examen du lundi doit attribuer les responsables, valider les scores et définir des actions datées.

Pourquoi cela fonctionne

  1. 1

    Les énoncés cause-événement-conséquence distinguent l'incertitude gérable des problèmes actuels et des préoccupations générales.

  2. 2

    Les déclencheurs et les plans de secours précisent ce qui change lorsque la prévention ne suffit plus.

Vérifier le résultat

  • Chaque entrée est-elle réellement incertaine et liée à un objectif du projet ?

  • Les scores sont-ils étayés par les preuves et l'échelle fournies ?

  • La responsabilité du risque, celle des mesures de réponse, les déclencheurs et les dates d'examen sont-ils distincts ?

Utilisez-la en toute confiance

Questions fréquentes

Des réponses pratiques sur le bon moment pour utiliser cette recette, ce qu’il faut fournir et les cas où une vérification humaine reste nécessaire.

Que dois-je préparer avant d'utiliser « Construire un registre des risques du projet » ?

Pour « Construire un registre des risques du projet », préparez le contexte du projet, les incertitudes et preuves connues, ainsi que l'évaluation et la gouvernance. Ne remplacez les espaces réservés que par des informations vérifiables. Si un détail est inconnu, indiquez explicitement cette incertitude au lieu de demander au modèle de le déduire.

Dans quels cas le résultat de « Construire un registre des risques du projet » n'est-il pas prêt à l'emploi ?

Le résultat n'est pas prêt s'il ne produit pas encore, à partir des éléments fournis, le résultat annoncé — un registre des risques priorisé avec justification des scores, mesures de réponse, plans de secours et lacunes — ou s'il repose sur des hypothèses non résolues, des approbations manquantes ou des détails inventés. Utilisez les contrôles comme critères de validation : révisez les données sources ou désignez un réviseur identifié et habilité au lieu de peaufiner un résultat non étayé.

Quels outils d'IA disposent de tests consignés pour « Construire un registre des risques du projet » ?

Le registre de tests publié pour « Construire un registre des risques du projet » mentionne ChatGPT à la date du 2026-08-28. Cela confirme que des essais ont été consignés, sans garantir la compatibilité ni des résultats identiques dans les versions ultérieures du produit. Pour un autre outil ou une autre version, laissez toutes les contraintes visibles et répétez les contrôles du résultat avant utilisation.

Plus de façons d'explorer

Où se situe cette recette

Faites avancer votre travail