Gestion des risques projet : matrice, registre et méthode
Gestion des risques projet : identifier les risques, les coter avec une matrice des risques, choisir la réponse et tenir un registre vivant. Exemple inclus.
Par l’équipe RoadmapHero · Mis à jour le · 11 min de lecture
L’essentiel
- La gestion des risques projet consiste à identifier ce qui peut faire dévier un projet, à l’évaluer en probabilité × impact, à choisir une réponse et à suivre chaque risque.
- Une matrice des risques 5 × 5 note la probabilité et l’impact de 1 à 5 ; leur produit, de 1 à 25, classe les risques en zones verte, orange et rouge pour savoir où agir d’abord.
- Il existe quatre réponses à un risque : l’éviter, le réduire, le transférer ou l’accepter ; chacune doit avoir un responsable nommé, un coût assumé et une date de revue.
- Un registre des risques utile est court, revu toutes les une à deux semaines et relié au planning : un risque qui ne déclenche aucune action n’est qu’une inquiétude consignée.
La gestion des risques projet est la démarche qui consiste à repérer à l’avance les événements susceptibles de faire dévier un projet (délai, budget, périmètre, qualité), à les évaluer selon leur probabilité et leur impact, à décider d’une réponse, puis à les suivre jusqu’à ce qu’ils disparaissent. Ses deux outils de base sont la matrice des risques, qui hiérarchise, et le registre des risques, qui trace les décisions. L’essentiel n’est pas le document : c’est que les risques soient revus dans le rituel de pilotage, chaque semaine ou chaque quinzaine.
Beaucoup d’équipes font une analyse des risques au lancement puis ne la rouvrent jamais : le risque identifié en janvier devient le problème découvert en juin, en comité de pilotage. Voici une méthode en quatre étapes, un exemple de registre et les signaux faibles à surveiller.
Qu’est-ce qu’un risque projet ?
Un risque projet est un événement incertain qui, s’il survient, aura un effet sur au moins un objectif du projet. Deux mots comptent : incertain et objectif. Ce qui est déjà arrivé n’est plus un risque, c’est un problème (on parle aussi d’issue) : il ne se gère plus par la prévention mais par un plan d’action. Et un événement qui ne touche aucun objectif ne mérite pas de ligne dans votre registre.
Pour éviter les formulations vagues du type « planning serré » ou « ressources », écrivez chaque risque en trois temps : cause → événement → conséquence.
Mauvais : « Risque fournisseur. »
Bon : « Le fournisseur de l’API de facturation n’a qu’un développeur sur le sujet (cause) ; s’il livre avec plus de deux semaines de retard (événement), la mise en production glisse d’autant et la formation des utilisateurs doit être replanifiée (conséquence). »
Cette phrase plus longue fait gagner du temps ensuite : elle indique qui peut agir, sur quoi, et ce que coûterait l’inaction.
Étape 1 : identifier les risques
L’identification est un travail collectif : le chef de projet voit les risques de planning, l’architecte les risques techniques, l’acheteur les risques fournisseurs, le métier les risques d’adoption. Réunissez-les une heure au cadrage, puis à chaque changement de phase.
Trois techniques fonctionnent bien :
Le pré-mortem. Demandez à l’équipe : « Nous sommes dans six mois, le projet a échoué. Que s’est-il passé ? ». Chacun écrit ses causes en silence pendant cinq minutes, puis on regroupe. Le cadre libère la parole : on ne critique pas le projet, on imagine son échec.
La revue des hypothèses. Relisez le planning et le budget en listant tout ce qu’ils supposent : « la recette durera trois semaines », « l’équipe infra sera disponible en mars ». Chaque hypothèse non vérifiée est un risque potentiel.
La checklist par catégorie. Passez en revue les familles classiques pour ne rien oublier.
Les catégories à balayer :
Technique : intégration, performance, reprise de données, dette existante.
Dépendances et fournisseurs : livraisons externes, autres projets, contrats.
Ressources : experts rares, partages de charge, départs, congés.
Périmètre et exigences : besoins flous, demandes qui s’ajoutent en cours de route.
Organisation et adoption : conduite du changement, disponibilité des métiers.
Réglementaire et sécurité : conformité, données personnelles, audits.
Relisez aussi les bilans des projets précédents : dans une même organisation, les mêmes risques reviennent souvent. Notre guide de la gestion de projet replace l’analyse des risques dans le cycle de vie complet.
Étape 2 : évaluer avec la matrice des risques
La matrice des risques (ou matrice probabilité × impact) croise deux axes : la probabilité que le risque survienne et son impact s’il survient. Le produit des deux notes donne une criticité qui permet de comparer des risques de nature différente, le plus souvent sur une grille 5 × 5.
Le piège est de noter « au feeling ». Définissez une échelle commune, écrite, pour que « impact 4 » veuille dire la même chose pour tout le monde. Voici un exemple d’échelle, à adapter à la taille de votre projet :
Note | Probabilité | Impact délai | Impact budget |
|---|---|---|---|
1 | Rare (moins de 10 %) | Moins d’une semaine | Moins de 1 % |
2 | Peu probable (10 à 30 %) | 1 à 2 semaines | 1 à 3 % |
3 | Possible (30 à 50 %) | 2 à 4 semaines | 3 à 5 % |
4 | Probable (50 à 80 %) | 1 à 2 mois | 5 à 10 % |
5 | Quasi certain (plus de 80 %) | Plus de 2 mois ou jalon client manqué | Plus de 10 % |
Prenez toujours la note d’impact la plus haute parmi les axes (délai, budget, qualité, réputation). Puis placez chaque risque dans la matrice.
Une convention courante pour lire la matrice :
Zone rouge (criticité 15 à 25) : réponse immédiate, responsable nommé, remontée au comité de pilotage.
Zone orange (criticité 5 à 12) : plan de réponse défini, revue à chaque point d’équipe.
Zone verte (criticité 1 à 4) : surveillance simple, pas d’action dédiée.
Pour les projets à fort enjeu financier, la valeur monétaire attendue (probabilité × coût de l’impact) aide à dimensionner une réserve pour aléas. Pour la plupart des projets, une matrice qualitative bien calibrée suffit.
Étape 3 : choisir une réponse aux risques
Chaque risque orange ou rouge appelle une décision. Il n’en existe que quatre, et les nommer clairement évite le flou du « on fait attention ».
Éviter : modifier le plan pour que le risque ne puisse plus survenir. Exemple : renoncer à une technologie que personne ne maîtrise au profit d’une solution éprouvée, ou sortir du périmètre une fonctionnalité qui dépend d’un tiers peu fiable.
Réduire (ou atténuer) : diminuer la probabilité ou l’impact. Exemple : lancer un prototype technique en début de projet, former un deuxième expert, découper une mise en production en deux lots.
Transférer : confier l’impact financier à un tiers. Exemple : pénalités de retard dans le contrat fournisseur, assurance, forfait au lieu de régie. Attention, on transfère le coût, rarement le problème : un fournisseur pénalisé ne vous rend pas vos semaines perdues.
Accepter : décider consciemment de ne rien faire, parce que la réponse coûterait plus cher que le risque. L’acceptation peut être active (on prévoit une réserve de temps ou de budget) ou passive (on traitera si cela arrive).
Pour les risques rouges, ajoutez un plan de contingence et un déclencheur : l’événement observable qui fera passer du plan A au plan B. « Si le fournisseur n’a pas livré l’environnement de test le 15 octobre, nous basculons sur les données simulées et prévenons les métiers. » Le déclencheur transforme une inquiétude en décision datée.
Chiffrez le coût de chaque réponse avant de la choisir. Un plan de réduction qui mobilise deux personnes pendant un mois pour éviter un retard probable d’une semaine est une mauvaise affaire. Accepter un risque est une décision légitime, à condition qu’elle soit explicite et partagée avec le sponsor.
Les réponses « éviter » et « réduire » modifient souvent le planning (prototype, lot supplémentaire, marge avant l’échéance) : intégrez-les dans votre rétroplanning plutôt que dans un document à part.
Étape 4 : suivre avec un registre des risques
Le registre des risques est la liste de référence de tous les risques du projet, avec leur évaluation, leur réponse et leur statut. Pour chaque ligne, les informations utiles sont :
un identifiant et l’intitulé au format cause → événement → conséquence ;
la catégorie, la probabilité, l’impact et la criticité ;
la réponse choisie et les actions associées ;
le responsable (une personne, pas une équipe) ;
le déclencheur et la date de prochaine revue ;
le statut : ouvert, en traitement, clos ou survenu (devenu problème).
Voici un extrait de registre pour un projet fictif de migration d’ERP :
Risque | P × I | Réponse | Responsable et échéance |
|---|---|---|---|
Retard du fournisseur sur l’API de facturation, qui décale la mise en production | 4 × 4 = 16 | Réduire : jalons intermédiaires contractuels et point hebdomadaire | Chef de projet, 30/09 |
Données clients incomplètes à la reprise, recette bloquée | 3 × 4 = 12 | Réduire : reprise à blanc dès le mois 2 | Responsable data, 15/10 |
Indisponibilité des utilisateurs clés pendant la clôture comptable | 4 × 3 = 12 | Éviter : recette déplacée hors période de clôture | Sponsor métier, 01/10 |
Surcoût de licences si le nombre d’utilisateurs dépasse le contrat | 2 × 3 = 6 | Transférer : clause de palier négociée | Achats, 20/10 |
Départ de l’expert paie en cours de projet | 2 × 4 = 8 | Réduire : binôme et documentation des paramétrages | Manager RH SI, 31/10 |
Quelques règles de tenue :
Revoyez le registre toutes les une à deux semaines en équipe, en 15 minutes : nouveaux risques, notes qui bougent, actions en retard, risques à clore.
Présentez le top 5 au comité de pilotage, pas la liste entière, avec les décisions attendues. Notre guide du comité de pilotage projet propose un ordre du jour qui réserve un temps dédié aux risques.
Affichez les risques dans le tableau de bord, à côté du planning et du budget : un tableau de bord de suivi de projet sans ligne « risques » raconte une histoire incomplète.
Fermez les risques qui ne peuvent plus survenir. Un registre qui ne fait que grossir n’est plus lu.
Repérer les signaux faibles avant qu’ils ne deviennent des problèmes
Les risques les plus dangereux sont rarement ceux du registre : ce sont ceux qui s’installent sans bruit. Un signal faible est un indice isolé, facile à rationaliser, qui annonce souvent un risque en train de se matérialiser.
Les plus fréquents :
une tâche qui glisse d’une semaine, puis encore d’une semaine, « sans impact sur le jalon » ;
un jalon intermédiaire manqué et jugé « pas bloquant » ;
un fournisseur ou une équipe partenaire qui répond de plus en plus lentement ;
un statut qui reste vert alors que l’avancement réel stagne depuis trois points (l’effet pastèque : vert dehors, rouge dedans) ;
des ateliers métiers annulés ou des participants qui changent à chaque séance.
Aucun de ces signaux ne justifie, seul, une alerte : c’est leur répétition qui compte. D’où l’intérêt de suivre les glissements dans le temps plutôt que de photographier un statut chaque vendredi. Dans RoadmapHero, par exemple, la santé de chaque élément du plan est semi-automatisée (retard, déplacement, nouveauté) et un retard saisi une fois décale les tâches dépendantes : l’impact sur le jalon se voit tout de suite, au lieu d’être découvert au comité suivant.
Enfin, rendez la remontée des mauvaises nouvelles sans danger : si celui qui annonce un risque passe pour pessimiste, plus personne n’en annoncera. La façon dont vous communiquez avec vos parties prenantes conditionne la qualité de vos alertes.
Les erreurs fréquentes en gestion des risques projet
Un registre de 80 lignes. Personne ne le lit. Gardez les risques critiques en tête et archivez le reste.
Des risques formulés comme des thèmes. « Planning », « budget », « RH » ne permettent aucune action. Revenez au format cause → événement → conséquence.
Pas de responsable, ou un responsable collectif. « L’équipe » ne relance jamais personne. Un nom par risque.
Cacher les risques au sponsor. Un sponsor informé tôt peut arbitrer ; un sponsor surpris perd confiance.
Oublier les risques transverses. Quand plusieurs projets partagent les mêmes experts ou le même fournisseur, le risque se pilote au niveau du portefeuille de projets, pas projet par projet.
Mettre en place la démarche en une semaine
Définissez une échelle de probabilité et d’impact commune, sur une page.
Animez un pré-mortem d’une heure avec l’équipe et les principaux contributeurs.
Rédigez chaque risque au format cause → événement → conséquence, notez-le et placez-le dans la matrice.
Choisissez une réponse et un responsable pour chaque risque orange ou rouge, avec un déclencheur pour les rouges.
Inscrivez la revue du registre dans le point d’équipe récurrent et le top 5 dans l’ordre du jour du comité de pilotage.
Si vous voulez que retards et dépendances remontent d’eux-mêmes dans un plan partagé plutôt que dans des comptes rendus, vous pouvez essayer RoadmapHero sur votre prochain projet.
Questions fréquentes
Quelle est la différence entre un risque et un problème en gestion de projet ?
Un risque est un événement incertain qui pourrait survenir et affecter un objectif du projet ; il se gère par la prévention, en réduisant sa probabilité ou son impact. Un problème est un événement déjà survenu ; il se traite par un plan d’action immédiat et, si besoin, une escalade vers le sponsor. Quand un risque se matérialise, il sort du registre des risques et devient un problème à suivre comme tel.
Comment faire une matrice des risques ?
Définissez d’abord une échelle de 1 à 5 pour la probabilité et pour l’impact, avec des seuils écrits (pourcentages, semaines de retard, part du budget). Notez chaque risque sur les deux axes, multipliez les notes pour obtenir la criticité, puis placez-le dans une grille 5 × 5 colorée en vert, orange et rouge. Les risques en zone rouge reçoivent une réponse et un responsable en priorité.
Que doit contenir un registre des risques ?
Un registre des risques contient, pour chaque risque : un identifiant, un intitulé précis au format cause, événement, conséquence, sa catégorie, sa probabilité, son impact et sa criticité, la réponse choisie avec ses actions, un responsable nommé, un déclencheur, une date de revue et un statut. Un tableur suffit au départ, à condition qu’il soit revu régulièrement et relié au planning.
Quelles sont les 4 stratégies de réponse aux risques ?
Les quatre stratégies de réponse sont éviter, réduire, transférer et accepter. Éviter consiste à modifier le plan pour supprimer le risque. Réduire vise à diminuer sa probabilité ou son impact. Transférer confie la conséquence financière à un tiers, par contrat ou assurance. Accepter est une décision consciente de ne pas agir, éventuellement avec une réserve de temps ou de budget prévue.
À quelle fréquence faut-il revoir les risques d’un projet ?
Une bonne règle consiste à revoir le registre des risques toutes les une à deux semaines en équipe, en une quinzaine de minutes, et à présenter les cinq risques les plus critiques à chaque comité de pilotage. Refaites aussi une identification complète à chaque changement de phase, par exemple entre la conception et la réalisation, car les risques évoluent avec le projet.