Gestion des risques projet : registre, analyse et stratégies de réponse

Tout projet est une suite de décisions prises sans disposer de toute l'information : l'incertitude n'est donc pas un défaut regrettable des projets mal conduits, c'est la matière même du travail. La gestion des risques transforme cette incertitude, qui sinon vous tombe dessus, en quelque chose que vous avez déjà anticipé, chiffré et confié à quelqu'un.

La plupart des organisations s'y prennent mal, et toujours de la même manière, facilement reconnaissable. Un registre est produit lors du démarrage du projet, rempli d'une vingtaine de risques plausibles, présenté une fois, puis plus jamais rouvert jusqu'à ce que l'un d'eux se produise et que quelqu'un fasse remarquer qu'il figurait sur la liste. C'est de la documentation, pas de la gestion. Ce guide traite de la version qui change les décisions : quoi identifier, comment l'analyser avec assez de rigueur pour dimensionner une réserve, quelles réponses existent, et comment garder l'ensemble vivant.

Risque, problème, hypothèse, dépendance

Quatre mots sont employés indifféremment alors qu'ils désignent des choses distinctes, qui appellent chacune une action différente.

La distinction compte, car un registre qui mélange ces catégories produit des revues confuses. Le réflexe le plus précieux est de traiter les hypothèses comme des risques non gérés : chaque hypothèse de planification inscrite dans une charte de projet devrait avoir une action de validation, car une hypothèse non validée est un risque que vous n'avez pas coté.

Pour rédiger les énoncés de risque, une discipline utile est la forme cause-événement-effet. « L'intégration pourrait échouer » ne permet aucune action. « Parce que la file de certification du prestataire de paiement est actuellement de six semaines, il existe un risque que la certification aboutisse après la date de lancement prévue, ce qui retarderait la mise en production et le chiffre d'affaires de deux mois au plus » nomme quelque chose sur quoi agir, fournit un déclencheur à surveiller et énonce un impact que l'on peut chiffrer.

Identifier les risques

C'est à l'identification que se joue la qualité de tout ce qui suit, et un atelier de cinq personnes qui listent ce qui les inquiète trouvera à coup sûr les risques évidents et ratera les plus coûteux. Combinez plusieurs techniques.

• Des listes de contrôle structurées, issues des projets précédents et du registre des leçons apprises de l'organisation. La source de bons risques la moins chère, c'est ce qui a mal tourné la dernière fois.
• L'analyse des hypothèses. Parcourez la charte et le plan, listez chaque hypothèse et demandez-vous ce qui se passe si elle est fausse.
• La décomposition. Parcourez la structure de découpage du projet (WBS) et l'architecture, et demandez-vous à chaque nœud ce qui pourrait mal tourner.
• Des entretiens avec des personnes extérieures à l'équipe. Les équipes d'exploitation, le support, ceux qui faisaient tourner l'ancien système, les ingénieurs du fournisseur. Ils connaissent des modes de défaillance que l'équipe projet n'a jamais vus.
• Le pre-mortem. Demandez à l'équipe d'imaginer qu'un an a passé et que le projet a lourdement échoué, puis de raconter comment. La technique fait émerger à coup sûr des risques que personne n'évoquerait en réunion ordinaire, parce que les soulever paraîtrait déloyal.
• Les catégories. Technique, externe, organisationnel, commercial, réglementaire, humain, données. Les catégories empêchent une équipe technique de produire vingt risques techniques et aucun autre.

Visez la couverture plutôt que le volume. Quarante risques que personne ne revoit valent moins que douze examinés chaque mois.

Le registre

Un registre se justifie quand chaque colonne sert. Les champs suivants constituent le minimum opérationnel.

Trois de ces champs sont régulièrement omis, et ce sont précisément ceux qui rendent le registre opérationnel. Le responsable doit être une personne ayant l'autorité d'agir : un risque confié à « l'équipe projet » n'appartient à personne. Le déclencheur est la condition observable qui indique que le risque est en train de se concrétiser, et le définir à l'avance permet de lancer la réponse à temps plutôt qu'une fois le mal fait. Enfin, le risque résiduel vous oblige à énoncer ce qui subsiste après la réponse, et c'est ce chiffre qui doit piloter la réserve.

Analyse qualitative

L'analyse qualitative hiérarchise rapidement les risques à l'aide de scores relatifs. La probabilité et l'impact sont chacun évalués sur une échelle (cinq niveaux, le plus souvent) puis combinés en un score qui oriente l'attention.

Deux règles garantissent l'honnêteté de l'exercice. Définissez les échelles dans les termes de l'organisation avant de coter : un « impact élevé » doit correspondre à une fourchette de montants, à un nombre de semaines ou à une catégorie nommée d'atteinte à la réputation, pas à une impression. Et cotez l'impact séparément pour chaque objectif lorsqu'ils divergent : un risque qui coûte peu mais retarde le lancement d'un mois n'est pas comparable à un risque qui coûte très cher sans rien retarder.

La matrice est un outil de tri, pas une réponse. Sa faiblesse connue est d'effacer la différence entre une catastrophe peu probable et une nuisance très probable qui se trouvent partager le même score : considérez donc que tout risque à impact très élevé exige une réponse, quoi qu'en dise l'arithmétique.

Analyse quantitative

Lorsque la décision exige un chiffre (quelle réserve conserver, faut-il accepter une offre au forfait, une mesure d'atténuation vaut-elle son coût), les techniques quantitatives mettent de l'argent sur la table.

La valeur monétaire attendue (EMV, expected monetary value) est le produit de la probabilité par l'impact, additionné sur l'ensemble des risques. Les menaces comptent comme des coûts positifs, les opportunités comme des coûts négatifs.

ID   Risk                                  P      Impact     EMV
R-07 Certification later than planned     0.40   120,000    48,000
R-11 Migration data quality worse         0.50    90,000    45,000
R-14 Performance target missed            0.15   200,000    30,000
R-02 Lead engineer unavailable            0.20    60,000    12,000
O-03 Reuse of existing auth component     0.60   -40,000   -24,000
                                                            -------
Total expected monetary value                               111,000

Ce total constitue un point de départ défendable pour une réserve pour aléas intégrée à la référence de base des coûts, bien meilleur qu'un pourcentage forfaitaire, puisqu'il se rattache à des risques précis et diminue à mesure qu'ils sont levés. C'est aussi un outil de décision : une mesure d'atténuation qui coûte 20 000 et divise par deux la probabilité de R-11 retire 22 500 de valeur attendue et mérite d'être engagée ; une mesure à 60 000 ne le mérite pas.

L'analyse de sensibilité classe les incertitudes selon leur poids. Faites varier chaque paramètre sur sa plage plausible en maintenant les autres fixes, et représentez l'effet sur le résultat sous forme de barres horizontales triées par taille : c'est le diagramme en tornade. Son intérêt est de montrer que, sur trente paramètres incertains, trois expliquent l'essentiel de la variance, et que c'est là qu'il faut concentrer l'effort d'analyse.

La simulation de Monte Carlo modélise l'ensemble du projet de façon probabiliste. Attribuez à chaque activité une fourchette de durée et à chaque poste de coût une distribution, lancez des milliers de tirages et lisez le résultat en percentiles : 80 % de chances de terminer avant une date donnée, 90 % de chances de rester sous un coût donné. C'est bien plus parlant qu'un plan à valeur unique, et cela met en évidence un effet que la planification déterministe masque : là où plusieurs chemins parallèles convergent, la probabilité que tous soient à l'heure est bien plus faible que la probabilité qu'un seul le soit, si bien que les points de convergence sont systématiquement plus risqués que ne le laisse penser un calcul du chemin critique.

Les réponses

Une fois le risque coté, choisissez une stratégie. Cinq s'appliquent aux menaces, et cinq leur font pendant pour les opportunités.

Toute réponse a deux conséquences. Le risque résiduel est ce qui subsiste ensuite ; il doit être consigné et explicitement accepté par quelqu'un, car une atténuation qui fait passer la probabilité de 40 % à 15 % n'a pas supprimé le risque. Le risque secondaire est celui que la réponse crée : confier du travail à un fournisseur introduit un risque fournisseur ; ajouter un cache pour régler un problème de performance introduit des défauts de données périmées. Les deux ont leur place dans le registre.

Privilégiez les atténuations qui produisent des preuves. Un risque technique portant sur une intégration non éprouvée se traite mieux par un spike limité dans le temps, qui fonctionne ou non, que par un paragraphe de bonnes intentions ; c'est d'ailleurs le même principe qui sous-tend une bonne stratégie d'automatisation des tests, où la couverture automatisée sert d'atténuation permanente contre le risque de régression.

Surveillance et risque en livraison itérative

La surveillance est la partie qui s'étiole. Rendez-la assez peu coûteuse pour qu'elle tienne : une courte revue à chaque fin d'itération ou chaque mois, où chaque risque ouvert est confirmé, recoté si quelque chose a changé, et clos s'il ne peut plus survenir. Surveillez les déclencheurs plutôt que les risques : un déclencheur activé signifie que la réponse commence aujourd'hui. De nouveaux risques arrivent en continu, par les demandes de changement, les nouvelles des fournisseurs et les découvertes techniques ; le registre grossit et maigrit, il n'est pas écrit une fois pour toutes.

La livraison itérative change davantage la forme de la gestion des risques que son fond. Les itérations courtes sont en elles-mêmes une atténuation : elles plafonnent la quantité de travail qui peut reposer sur une hypothèse erronée, et elles produisent des preuves toutes les deux semaines plutôt qu'à la fin. Ordonner le backlog par le risque, en construisant l'intégration incertaine dès la première itération plutôt qu'à la dernière, convertit tôt l'incertitude en connaissance ; c'est pourquoi les éléments structurants pour l'architecture doivent être avancés même lorsque leur valeur métier est faible. Le framework Scrum ne prévoit aucun artefact dédié au risque : les équipes qui en ont besoin tiennent généralement un registre léger à côté du backlog et le revoient lors de l'affinage.

Ce qui ne change pas, c'est le besoin d'une responsabilité explicite et d'une conversation honnête sur ce qui pourrait mal tourner. Une équipe qui traite chaque problème au moment où il survient n'est pas agile : elle est simplement mal préparée, avec une boucle de rétroaction plus courte.

Points clés à retenir

• Séparez risques, problèmes, hypothèses et dépendances : chacun appelle une action différente, et une hypothèse non validée n'est rien d'autre qu'un risque non coté.
• Rédigez les énoncés sous la forme cause-événement-effet, pour que chaque entrée porte un déclencheur à surveiller et un impact chiffrable.
• Un registre fonctionne lorsqu'il comporte un responsable individuel, un déclencheur défini et un risque résiduel énoncé ; sans ces trois éléments, ce n'est que de la documentation.
• La cotation qualitative sert au tri, mais définissez d'abord les échelles en argent et en semaines, et ne laissez jamais la matrice minorer une catastrophe peu probable.
• La valeur monétaire attendue fournit un montant de réserve traçable et indique quelles atténuations valent leur coût ; Monte Carlo révèle le risque aux points de convergence que masque un plan déterministe.
• Toute réponse laisse un risque résiduel et en crée généralement un secondaire ; consignez les deux, et privilégiez les atténuations qui produisent des preuves plutôt que des intentions.