Un risque est quelque chose qui pourrait se produire et qui nuirait au projet si cela arrivait. La gestion des risques consiste à identifier ces menaces au plus tôt et à décider quoi en faire avant qu'elles ne posent problème. L'idée simple : les problèmes sont beaucoup plus faciles à gérer quand vous y avez réfléchi à l'avance.
Un outil simple et largement utilisé pour suivre les menaces et les éléments du projet :
R — RISKS → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS → things we're taking as true (validate them)
I — ISSUES → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
For each risk, score:
LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
AVOID → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT → live with it, but have a fallback ready
Un projet dépend d'une API tierce qui est nouvelle et non éprouvée. Risque : elle peut ne pas fonctionner correctement. Probabilité moyenne, impact élevé. Atténuation : explorez-la tôt, construisez une abstraction pour pouvoir changer de fournisseur, et ayez un plan de secours. Maintenant, une inconnue est un risque géré avec un plan.
Traiter la gestion des risques comme une liste de contrôle de lancement unique. Les risques évoluent — examinez régulièrement le journal RAID et ajoutez-en de nouveaux à mesure qu'ils émergent.
Les risques non gérés deviennent des crises, généralement au pire moment possible, près d'une date limite.
Le coût de la gestion d'un risque tôt est minuscule comparé à la lutte contre lui après qu'il se soit produit.
Nommer les risques à haute voix renforce également la confiance — les parties prenantes préfèrent « voici ce qui pourrait mal tourner et notre plan » à un silence confiant suivi d'une mauvaise surprise.