Risques & opportunités

Ces trois notions sont souvent confondues dans la pratique, mais elles ne se pilotent pas de la même façon. L'**aléa** désigne un événement dont on ne peut pas prévoir la survenue individuelle, mais dont la fréquence statistique est connue ou modélisable : un jour de gel, une panne machine, un retard fournisseur ponctuel. On le traite par provisions moyennes et lissage. L'**incertitude** désigne un domaine où même la loi de probabilité est inconnue : une décision réglementaire à venir, l'adoption d'une technologie émergente, la stabilité géopolitique d'un fournisseur. On ne peut pas la provisionner par calcul statistique. On la traite par scénarios, veille, et options ouvertes. Le **risque**, au sens de la norme ISO 31000 et du PMBOK, est un événement identifié qui, s'il survient, aurait un effet mesurable sur les objectifs du projet. Il combine une cause identifiable, une probabilité d'occurrence, et un impact évaluable. Contrairement à l'aléa, il est nommé ; contrairement à l'incertitude, il est mesurable. Cette distinction guide le mode de traitement : les aléas se provisionnent, les incertitudes se surveillent, les risques se pilotent activement avec un plan de mitigation dédié.

La plupart des plans de mitigation finissent en registres Excel oubliés, consultés une fois par trimestre lors de la revue d'audit. Trois causes principales expliquent ce phénomène, et chacune appelle une discipline précise. **Première cause : les risques sont mal définis.** Un vrai risque nomme un événement particulier et défini, avec une cause identifiable. "On pourrait manquer de ressource" n'est pas un risque, c'est une inquiétude ; "le départ annoncé du chef de lot logiciel en juin peut retarder la livraison du module de six semaines" est un risque. La discipline consiste à reformuler chaque item du registre jusqu'à ce qu'il désigne un événement précis, situé, mesurable. **Deuxième cause : personne n'est nommément propriétaire de la mitigation.** Attribuer un risque au "PMO" ou à "l'équipe projet" garantit qu'aucune action ne sera prise. Chaque risque a besoin d'un pilote unique, nommé, qui rend compte de l'avancement des actions de mitigation à intervalle défini. Le propriétaire n'est pas forcément celui qui subira l'impact ; c'est celui qui a le pouvoir d'agir sur les causes. **Troisième cause : le calendrier du risque n'est pas géré.** Un risque a un cycle de vie temporel : il est mitigable jusqu'à une date-limite, il peut se déclencher dans une fenêtre d'événements précise, il a des triggers d'occurrence liés à d'autres jalons du projet. Traiter un risque sans traiter son calendrier revient à réagir après coup. La discipline consiste à inscrire chaque risque dans le planning au même titre qu'une activité, avec ses dates de revue, sa date-limite de mitigabilité, et ses triggers observables. Cette approche, formalisée notamment par David Hillson dans ses travaux sur la gestion temporelle du risque, considère que la date-limite de mitigabilité est aussi importante que la probabilité et l'impact dans le pilotage d'un risque : au-delà de cette date, l'action préventive n'est plus possible et il ne reste que la gestion de l'occurrence. Un plan de mitigation qui applique ces trois disciplines devient vivant : il est relu régulièrement parce que ses items sont concrets, il est actionné parce que quelqu'un en répond, et il évolue en synchronisation avec le projet parce qu'il a un calendrier propre.

Le dimensionnement d'une provision pour risques (aussi appelée provision pour aléas, contingency reserve, ou budget de contingence) est l'un des arbitrages les plus politiquement sensibles d'un projet. Trop faible, elle expose la direction à devoir demander des rallonges en cours de route ; trop élevée, elle rend le projet peu compétitif à l'instruction ou déclenche des reprises budgétaires. Trois méthodes coexistent, et le choix dépend du degré de maturité de l'analyse de risques. **L'approche forfaitaire** applique un pourcentage global au budget de base. Dans les grands projets industriels et d'ingénierie, une fourchette de 20 à 30 % est fréquemment défendable ; le seuil bas de 5 à 15 % que citent parfois les référentiels génériques correspond en réalité à des secteurs très matures et standardisés (automobile de série par exemple), pas à la moyenne des grands projets. À l'inverse, pour les projets à faible niveau de maturité technologique (TRL bas, typiquement 3 à 4), la provision peut légitimement monter jusqu'à 50 % du budget de base. Sur le papier, le principe voudrait que la provision approche le coût nominal quand l'incertitude équivaut à la totalité du projet, mais aucun financier n'accorde ce niveau en pratique : la barre haute retenue est un compromis entre lucidité technique et acceptabilité budgétaire. Rapide, opaque, faible pouvoir d'arbitrage : cette approche est utile en avant-projet quand aucune analyse détaillée n'a été menée, mais elle ne survit pas à un audit exigeant. **L'approche par sommation pondérée** cumule, pour chaque risque identifié du registre, le produit *probabilité × impact financier*. Cette méthode est défendable auprès d'une direction, traçable en revue, et elle force la discipline d'identification et de chiffrage. Sa limite : elle suppose l'indépendance des risques, ce qui est rarement vrai dans un projet où plusieurs risques peuvent s'enchaîner. **L'approche par simulation** (Monte Carlo typiquement) modélise les corrélations entre risques et produit une distribution de coûts probable. On lit la provision au niveau de confiance souhaité (par exemple P70 ou P85 selon le degré d'exposition acceptable). Coût d'entrée plus élevé, mais elle donne un chiffre défendable pour les projets à fort enjeu ou fortement corrélés. Le vrai piège n'est pas le choix de la méthode : c'est l'absence de méthode explicite. Un budget de contingence dont personne ne peut expliquer le calcul devient indéfendable dès la première revue budgétaire, et perd de sa légitimité au moment où on en aurait le plus besoin.

Ces deux dispositifs sont souvent confondus, ou pire, utilisés comme s'ils étaient interchangeables. Ils protègent en fait deux variables différentes du projet. La **provision pour risques** protège la variable coût. Elle absorbe le surcoût déclenché quand un risque identifié survient : dépassement d'une prestation, remise à niveau d'un lot défaillant, activation d'une prestation de secours. Sans elle, l'occurrence d'un risque déclenche une demande de rallonge budgétaire, avec toutes ses conséquences politiques. Le **buffer de planification** protège la variable durée. Il absorbe le retard déclenché par un aléa, une dépendance qui glisse, ou un risque temporel qui survient. Sans lui, l'occurrence d'un événement retard force le décalage de la date de livraison, avec les mêmes conséquences politiques côté calendrier. Les deux dispositifs se pilotent selon des logiques comparables : dimensionnement (forfaitaire, par sommation, par simulation), consommation suivie (le pourcentage consommé mesure la santé du projet), reconstitution possible en cours de route si le contexte le permet. Mais ils ne se substituent pas l'un à l'autre : un projet qui n'a qu'une provision budgétaire est protégé contre le surcoût d'un risque mais pas contre le retard qu'il génère ; un projet qui n'a qu'un buffer calendaire est protégé contre le décalage mais pas contre le surcoût. Dans un projet, les deux dispositifs se pilotent conjointement, avec des règles de gouvernance qui les articulent : par exemple, une consommation de 50 % du buffer déclenche une revue du portefeuille de risques et une éventuelle mobilisation de la provision pour renforcer une mitigation en cours.