Mardi matin, votre responsable produit vous signale que la date de lancement est compromise. À l’heure du déjeuner, le responsable de l’intégration indique que le fournisseur a modifié son API, nécessitant une reprise du travail par l’équipe. En fin de journée, l’équipe d’assurance qualité (QA) demande quels tests abandonner, le calendrier ayant été réduit. L’analyste sécurité ajoute que la compression de la phase de test entraînera probablement la découverte de problèmes après le gel du code (code freeze). En tant que chef de projet, vous devez trancher : maintenir le périmètre, décaler la date ou accepter une baisse de la qualité. Chaque heure d’attente alourdit le coût de la décision finale, car les équipes continuent de travailler sur la base d’hypothèses divergentes.
Avant de préparer une présentation d’état d’avancement, il est crucial d’établir une distinction claire. Un risque est un événement futur incertain susceptible d’affecter les objectifs. Un problème (issue) est une difficulté bien réelle et actuelle. La modification de l’API par le fournisseur constitue un problème une fois qu’elle survient ; auparavant, la possibilité qu’elle se produise relevait du risque. Ce cours vous permet de développer le discernement et les outils nécessaires pour maintenir cette distinction utile et opérationnelle : utilisation d’un registre des risques actif, définition sur une page des objectifs et de l’appétence au risque, formulation claire des risques assortie de leurs déclencheurs, et mise en place d’un suivi léger pour détecter l’incertitude suffisamment tôt pour agir.
Pour commencer, passez en revue la chronologie des événements et identifiez le moment où le projet a basculé de l’incertitude à la réalité.
Lorsque les équipes débattent pour savoir si un risque mérite d’être suivi, elles discutent souvent d’autre chose. Elles débattent en réalité des priorités d’optimisation du projet, des hypothèses retenues et des contraintes immuables. Si ces éléments sont flous, toute discussion sur les risques aboutit à des conseils vagues, du type « gardons un œil dessus ».
Un cadre pratique tient sur une seule page et commence par les objectifs. L’objectif de calendrier pourrait être une livraison avant la fin du trimestre. L’objectif de coût pourrait consister à respecter un budget fournisseur fixe. L’objectif de qualité pourrait viser l’absence de faille de sécurité critique au moment du lancement. À partir de là, vous listez les hypothèses considérées comme vraies pour la planification (par exemple, le maintien de la rétrocompatibilité de l’API du fournisseur) et les contraintes non négociables (comme une échéance réglementaire). Vous définissez ensuite l’appétence au risque, c’est-à-dire la marge de variation que le sponsor tolère avant d’exiger une remontée d’information et une décision. L’appétence ne doit pas être confondue avec l’optimisme ; il s’agit d’une limite fixée pour l’action.
Une erreur fréquente : le mauvais réflexe consiste à définir une appétence unique et globale, comme « nous avons une faible tolérance au risque ». Cela donne une impression de décision ferme. La conséquence est l’apparition de compromis cachés : l’équipe préserve le calendrier en réduisant les tests sans l’aval du sponsor, ou préserve la qualité en repoussant la date de livraison sans en informer l’équipe commerciale.
Choisissez des niveaux d’appétence adaptés au contexte du projet, et non à vos préférences personnelles.