Le PMI a mesuré en 2026 que 31 % des projets complexes n’atteignent pas l’ensemble des bénéfices attendus, contre 12 % dans son étude de 2024. La complexité augmente, l’incertitude aussi, et l’écart se creuse entre les organisations qui anticipent et celles qui subissent. Le management des risques est précisément la discipline qui sépare les deux.
Attention à ne pas confondre deux notions proches. Un risque est un événement incertain, qui ne s’est pas encore produit. Un problème est un événement survenu, qu’il faut désormais traiter. Le management des risques travaille sur le premier, avant que le second n’apparaisse.
Dans cet article, nous vous expliquons :
- ce que recouvre exactement la discipline, menaces et opportunités comprises
- ce qu’en disent les trois référentiels de référence, PMBOK 7, ISO 31000 et PRINCE2 7
- comment construire un plan de management des risques et un registre exploitables
- les 10 stratégies de réponse du PMI et la façon de chiffrer un risque
- comment la démarche s’adapte aux projets agiles et aux nouveaux risques de 2026
Le management des risques ne traite pas que des mauvaises nouvelles
C’est le contresens le plus répandu sur le sujet. Dans les référentiels professionnels, un risque est un événement incertain qui, s’il survient, a un effet sur au moins un objectif du projet. Cet effet peut être défavorable, on parle alors de menace, mais il peut aussi être favorable, et l’on parle d’opportunité.
Prenons un exemple concret. Un fournisseur vous annonce qu’il pourrait livrer un composant avec trois semaines d’avance. C’est un événement incertain qui affecte votre calendrier, donc un risque au sens strict. Une équipe qui ne gère que les menaces le laissera passer. Une équipe qui gère réellement ses risques préparera le scénario permettant d’absorber cette avance et de la convertir en marge sur le chemin critique.
Cette symétrie a des conséquences pratiques. Elle change la composition de votre registre, elle change les stratégies de réponse que vous mobilisez, et elle change surtout la façon dont les équipes perçoivent l’exercice. Un atelier d’identification des risques présenté uniquement comme un inventaire de catastrophes se remplit mal, parce que personne n’a envie d’être le porteur de mauvaises nouvelles. Le même atelier ouvert aux opportunités mobilise nettement mieux.
Le management des risques recouvre donc l’ensemble du cycle : cadrer la démarche, identifier ce qui peut arriver, évaluer la gravité, décider quoi faire, agir et surveiller. Voyons comment les référentiels structurent ce cycle.
Ce que disent PMBOK 7, ISO 31000 et PRINCE2 7
Trois cadres coexistent et se complètent plutôt qu’ils ne se concurrencent. Les connaître évite de réinventer une méthode maison qui ne passera aucun audit.
Le PMBOK 7 a fait disparaître le chapitre risques
La 6e édition du PMBOK Guide décrivait sept processus dans son chapitre 11 : planifier le management des risques, identifier, analyser qualitativement, analyser quantitativement, planifier les réponses, mettre en œuvre les réponses, surveiller. Beaucoup de chefs de projet ont appris la discipline sous cette forme.
La 7e édition, publiée en 2021, a supprimé cette structure. Le PMI est passé d’une logique de processus à une logique de principes et de domaines de performance. Le risque s’y retrouve à deux endroits : dans le principe « optimiser les réponses aux risques », l’un des douze principes, et dans le domaine de performance « incertitude », l’un des huit domaines. Concrètement, le PMI ne vous impose plus une séquence, il vous demande d’obtenir un résultat et vous laisse adapter la méthode au contexte.
Ce changement déroute, mais les sept processus restent une excellente trame opérationnelle. Rien ne vous interdit de les conserver comme colonne vertébrale, c’est même ce que font la plupart des PMO.
ISO 31000:2018, le cadre organisationnel
Là où le PMI raisonne projet, la norme ISO 31000:2018 raisonne organisation. Elle pose huit principes, parmi lesquels la création de valeur, l’intégration aux processus existants, la personnalisation, l’inclusion des parties prenantes et la prise en compte des facteurs humains et culturels.
Son processus se déroule en six temps : communication et consultation, définition du périmètre et des critères, appréciation du risque, traitement, surveillance et revue, enregistrement et reporting.
Un point mérite d’être clarifié, car la confusion est fréquente. ISO 31000 donne les principes, le cadre et le processus. C’est la norme ISO/IEC 31010 qui recense les techniques d’appréciation à proprement parler, dont l’AMDEC fait partie. Vous avez besoin des deux.
PRINCE2 7 et la différence entre appétence et tolérance
Sorti en 2023, PRINCE2 7 traite le risque comme l’un de ses thèmes. Il apporte surtout une distinction très utile que les deux autres référentiels détaillent moins.
L’appétence au risque exprime le niveau de risque global qu’une organisation accepte de prendre pour atteindre ses objectifs. C’est une orientation stratégique, définie au niveau de la direction. La tolérance au risque, elle, fixe des seuils de variation acceptables autour d’un objectif précis, en coût, en délai, en périmètre ou en qualité. Dépasser une tolérance déclenche une escalade.
La différence est loin d’être théorique. Une entreprise peut avoir une forte appétence au risque sur l’innovation produit et une tolérance très serrée sur les délais réglementaires. Sans ces deux niveaux, votre chef de projet ne sait pas ce qu’il peut arbitrer seul.
Les deux documents qui structurent la démarche
La théorie ne sert à rien sans les livrables qui la portent. Il en faut deux, et ils ne servent pas à la même chose.
Le plan de management des risques
Ce document ne contient aucun risque. Il décrit comment vous allez les gérer, et se rédige au moment du cadrage, en même temps que votre charte de projet. On y trouve généralement :
- la méthodologie retenue et son niveau de formalisme
- les rôles et responsabilités, dont l’identité du responsable de la démarche
- le budget et le calendrier consacrés au management des risques
- les catégories de risques utilisées pour structurer l’identification
- les échelles de probabilité et d’impact, et la matrice qui les croise
- les tolérances des parties prenantes et les seuils d’escalade
- les formats de reporting et la fréquence des revues
Sauter cette étape est l’erreur classique. Une équipe qui n’a pas défini ses échelles avant de commencer passera ses ateliers à débattre de ce que signifie « impact élevé » au lieu d’identifier des risques.
Le registre des risques
Le registre est le document vivant du projet. Chaque ligne correspond à un risque et comporte au minimum un identifiant, une description, une catégorie, la probabilité, l’impact, le score obtenu, un propriétaire nommé, la stratégie de réponse retenue, les actions associées et le statut.
Deux colonnes sont trop souvent oubliées. La date probable de survenance, d’abord, qui permet de trier le registre par échéance plutôt que par score et d’éviter de traiter en priorité un risque qui ne se matérialisera que dans huit mois. Le risque résiduel, ensuite, c’est-à-dire ce qui subsiste une fois la réponse appliquée. Un risque atténué n’est pas un risque disparu.
Ajoutons une notion que peu d’équipes suivent : le risque secondaire, créé par la réponse elle-même. Transférer un risque technique à un prestataire réduit votre exposition technique mais crée une dépendance contractuelle. Cette dépendance doit entrer au registre.
Le score de criticité se calcule en multipliant la probabilité par l’impact, sur des échelles de trois ou cinq niveaux. Le croisement des deux axes donne la matrice des risques, généralement en cinq par cinq, qui visualise les priorités. Nous détaillons la mécanique complète de l’évaluation dans notre article sur l’analyse des risques projet.
Pour alimenter le registre, plusieurs techniques se combinent : le brainstorming en atelier, la technique Delphi qui interroge des experts de façon anonyme et itérative pour éviter l’effet de dominance, l’analyse des hypothèses du projet, les checklists issues des projets passés, l’analyse des causes racines et l’analyse SWOT. Aucune ne suffit seule, et c’est leur croisement qui fait la qualité du registre.
Les 10 stratégies de réponse du PMI
Une fois les risques priorisés, il faut décider. Le PMI distingue cinq stratégies pour les menaces et cinq pour les opportunités, l’escalade étant commune aux deux familles.
Pour les menaces, éviter consiste à modifier le projet pour supprimer la cause, par exemple en retirant du périmètre la fonctionnalité à l’origine du danger. Transférer déplace la responsabilité vers un tiers, par une assurance, une garantie ou un contrat à prix forfaitaire, sans faire disparaître le risque pour autant. Atténuer réduit la probabilité ou l’impact, par un prototype, une redondance ou une formation. Accepter revient à ne rien faire de particulier, de façon passive si l’on se contente de surveiller, ou active si l’on constitue une réserve.
Pour les opportunités, la symétrie est parfaite. Exploiter cherche à rendre l’événement favorable certain, en affectant par exemple vos meilleures ressources à la tâche concernée. Partager associe un partenaire mieux armé pour capter le bénéfice, souvent via une coentreprise. Améliorer augmente la probabilité ou l’ampleur du gain. Accepter laisse l’opportunité se présenter sans effort particulier.
Reste l’escalade, qui s’applique aux deux familles. Elle intervient quand le risque dépasse le périmètre d’autorité du chef de projet et relève du programme ou de la direction. Un risque escaladé sort du registre projet, mais il doit être tracé dans le registre du niveau supérieur, sans quoi il disparaît purement et simplement.
Chiffrer le risque : valeur monétaire attendue, Monte-Carlo et réserves
L’analyse qualitative suffit pour prioriser. Elle ne suffit pas pour négocier un budget. Passer au quantitatif devient nécessaire dès que l’enjeu financier justifie l’effort.
La valeur monétaire attendue
La valeur monétaire attendue, ou EMV pour expected monetary value, se calcule en multipliant la probabilité d’un risque par son impact financier. Un risque évalué à 30 % de probabilité, avec un impact chiffré à 200 000 euros, représente une valeur monétaire attendue de 60 000 euros.
L’intérêt vient de l’agrégation. En additionnant les valeurs monétaires attendues de l’ensemble des risques identifiés, vous obtenez un montant défendable devant un comité, plutôt qu’un pourcentage arbitraire ajouté au budget du projet. Notez que les opportunités entrent dans le calcul avec un signe positif, ce qui réduit d’autant l’exposition nette.
Monte-Carlo et diagramme tornade
La simulation de Monte-Carlo teste des milliers de combinaisons d’aléas pour produire une distribution des coûts ou des dates de fin possibles. Elle répond à une question que l’estimation classique ne sait pas traiter : quelle est la probabilité de livrer avant telle date, et quelle réserve faut-il pour atteindre un niveau de confiance de 80 % ?
L’analyse de sensibilité poursuit un autre objectif. Représentée sous forme de diagramme tornade, elle classe les variables selon leur influence sur le résultat final. Vous découvrez ainsi que le délai d’approvisionnement pèse trois fois plus lourd que la productivité de l’équipe, et vous concentrez vos efforts là où ils comptent.
Réserve pour aléas et réserve de gestion
La distinction est souvent mal comprise, et elle a pourtant des conséquences directes sur votre autonomie.
La réserve pour aléas couvre les risques identifiés, ceux que l’on appelle les inconnues connues. Elle est intégrée à la référence de base du budget et le chef de projet peut la mobiliser seul, dans les limites fixées.
La réserve de gestion couvre ce qui n’a pas été identifié, les inconnues inconnues. Elle se situe en dehors de la référence de base et sa mobilisation exige l’accord du sponsor ou de la direction.
Méfiez-vous des pourcentages tout faits qui circulent sur le sujet. Le PMI ne fixe aucun taux universel, et un pourcentage forfaitaire appliqué sans analyse n’a aucune valeur en comité. La bonne pratique consiste à dimensionner la réserve pour aléas à partir de la valeur monétaire attendue ou d’une simulation, puis à l’ajuster au contexte du projet.
Qui décide quoi : propriétaire du risque, tolérances et escalade
Un registre sans responsable nommé ne produit aucune action. C’est le constat le plus fréquent lors des audits de projet, et il est facile à corriger.
Chaque risque doit avoir un propriétaire, une personne physique identifiée, pas une direction ni une équipe. Ce propriétaire surveille les signaux avant-coureurs, déclenche la réponse prévue et rend compte de l’évolution du risque. Il n’est pas nécessairement le chef de projet, et il vaut souvent mieux qu’il ne le soit pas : le risque fournisseur revient naturellement à l’acheteur, le risque réglementaire au juriste.
L’escalade vers le comité de pilotage se déclenche dans quatre situations : le score du risque dépasse le seuil de criticité défini dans le plan, une tolérance de coût, de délai, de périmètre ou de qualité est menacée, la décision sort du périmètre d’autorité du chef de projet, ou le traitement exige de puiser dans la réserve de gestion.
Ces règles doivent être écrites avant le premier incident. Une escalade improvisée en cellule de crise arrive systématiquement trop tard. Le registre gagne d’ailleurs à être revu à chaque jalon plutôt qu’au fil de l’eau, ce qui donne un rythme de revue et évite qu’il ne devienne un document mort après le cadrage.
Le management des risques en contexte agile
Une objection revient souvent : les cadres agiles ne prévoient pas de registre des risques, donc ils ne gèrent pas les risques. C’est inexact, ils les gèrent autrement.
Scrum n’impose effectivement aucun artefact dédié. Le traitement du risque y est structurel plutôt que documentaire : des itérations courtes limitent l’exposition, la revue de sprint confronte le produit à la réalité toutes les deux semaines, et l’affinage continu du backlog permet de réagir sans passer par un comité. Livrer un incrément fonctionnel toutes les deux semaines réduit mécaniquement le risque de découvrir une erreur de conception au bout de dix-huit mois.
Deux pratiques méritent d’être connues. Le backlog ajusté au risque consiste à prioriser non seulement sur la valeur métier mais aussi sur l’incertitude, en remontant plus tôt les éléments à forte dépendance ou à fort inconnu technique. Le spike est une tâche de recherche encadrée dans le temps, dont le livrable n’est pas une fonctionnalité mais une décision éclairée : valider une technologie, mesurer une performance, lever une ambiguïté fonctionnelle.
À l’échelle, SAFe formalise davantage. Lors du PI Planning, l’atelier ROAM classe les risques identifiés en quatre catégories : résolus, attribués à un responsable, acceptés en l’état, ou atténués par une action. L’exercice se fait collectivement et devant tout le train, ce qui règle en une session ce qu’un registre classique mettrait des semaines à arbitrer. Si vous outillez ces pratiques, notre sélection d’outils de gestion de projet agile couvre les solutions du marché.
Les risques qui montent en 2026
Les catégories de risques évoluent, et un registre construit sur les modèles d’il y a cinq ans passe à côté d’une part croissante de l’exposition réelle.
Le baromètre Allianz des risques 2026, qui interroge plus de 3 300 experts dans 97 pays, place les incidents cyber au premier rang mondial pour la cinquième année consécutive, cités par 42 % des répondants. L’interruption d’activité et les ruptures de chaîne d’approvisionnement arrivent en troisième position avec 29 %. Un chiffre du même rapport mérite d’être médité : seuls 3 % des répondants jugent leur chaîne d’approvisionnement très résiliente.
L’intelligence artificielle ajoute une dimension réglementaire nouvelle. Le règlement européen sur l’IA, entré en vigueur le 1er août 2024, s’applique par étapes : interdiction de certaines pratiques et obligation de formation depuis le 2 février 2025, règles de gouvernance et modèles à usage général depuis le 2 août 2025, application générale depuis le 2 août 2026. Un paquet de simplification dit Digital Omnibus, entré en vigueur le 27 juillet 2026, a toutefois reporté les obligations les plus lourdes concernant les systèmes à haut risque, désormais applicables au 2 décembre 2027 pour ceux de l’annexe III et au 2 août 2028 pour ceux intégrés à des produits réglementés. Si votre projet embarque de l’IA, cette qualification conditionne votre charge de conformité et doit figurer au registre dès le cadrage.
Côté méthode, le cadre de gestion des risques liés à l’IA publié par le NIST le 26 janvier 2023 s’est imposé comme la référence opérationnelle. Il s’articule autour de quatre fonctions : gouverner, cartographier, mesurer et gérer. Il n’a rien d’obligatoire en Europe, mais il fournit une grille de lecture solide pour structurer l’analyse d’un projet incluant des modèles d’apprentissage.
En bref : construire une démarche qui tient
Le management des risques échoue rarement par manque de méthode. Il échoue parce que le registre est rempli une fois au cadrage puis oublié, parce qu’aucun propriétaire n’est nommé, ou parce que les seuils d’escalade n’ont jamais été écrits.
Trois points à retenir pour éviter ces écueils :
- Traitez les opportunités autant que les menaces, avec les cinq stratégies dédiées de chaque famille
- Nommez un propriétaire par risque et définissez vos seuils d’escalade avant le premier incident
- Chiffrez votre réserve pour aléas à partir de la valeur monétaire attendue, jamais d’un pourcentage forfaitaire
Si vous démarrez, le plus simple reste de caler une revue des risques sur vos points de suivi de projet existants, plutôt que d’ajouter une réunion supplémentaire que personne ne tiendra. Nos modèles de gestion de projet comprennent d’ailleurs les tableaux nécessaires pour démarrer votre registre sans repartir d’une feuille blanche.
