Un déploiement SaaS est mis en ligne le vendredi soir. Le samedi matin, les clients ne parviennent plus à se connecter, le volume de demandes au support explose et la page d’état du fournisseur signale une panne partielle. Le sponsor demande pourquoi la gestion des risques n’a pas anticipé ce problème.
Avant de mettre à jour le registre des risques, vous devez répondre à une question plus délicate : existait-il un signal de risque réel sur lequel vous auriez pu agir, ou êtes-vous en train de transformer une analyse a posteriori en recherche de coupables ? Ce module propose une approche structurée — compatible avec les exigences de gouvernance — pour distinguer les signaux prévisibles des véritables imprévus, classifier vos observations et déterminer où l’IA peut apporter son aide sans pour autant lui confier le pouvoir de décision.
Pour commencer, envisagez l’incident sous l’angle d’une chronologie plutôt que d’une conclusion. Identifiez les informations disponibles à l’époque, les personnes qui en avaient connaissance et ce qu’un chef de projet raisonnable aurait pu en faire.
Une erreur courante consiste à qualifier tout résultat défavorable de « prévisible ». Cette approche donne une impression de responsabilité, mais elle incite les équipes à documenter à l’excès des risques peu significatifs tout en négligeant les quelques signaux qui comptent vraiment.
Lors d’une panne, quatre types d’éléments ont tendance à se confondre ; les résultats générés par l’IA les mélangeront également si vous n’imposez pas de règles strictes.
Un risque est un événement futur incertain qui, s’il survient, affecte les objectifs. Exemple : limitations de débit (rate limits) du service d’authentification du fournisseur lors des pics de charge du week-end de lancement.
Un problème (ou incident) est une difficulté actuelle qui s’est déjà produite. Exemple : les utilisateurs reçoivent actuellement des erreurs 500 lors de la connexion.
Une hypothèse est un élément considéré comme vrai à des fins de planification, mais qui pourrait s’avérer faux. Exemple : le fournisseur maintiendra ses niveaux de capacité actuels tout au long du trimestre.
Une dépendance est un livrable ou une condition externe nécessaire à votre projet. Exemple : le fournisseur termine la fenêtre de maintenance prévue avant votre basculement en production.
Question de prédiction : quelle erreur de classification entraîne le plus long délai d’escalade lors d’une panne ?
Entraînez-vous maintenant à appliquer ces catégories, car votre processus de gouvernance repose sur une classification cohérente préalable à la priorisation.
Le mauvais réflexe consiste à tout classer comme un « risque » pour se garder des options ouvertes. Résultat : les véritables problèmes ne sont ni pris en charge ni résolus, et les hypothèses ne sont jamais validées.
Si votre gestion des risques doit résister à un audit, vous ne pouvez pas vous contenter d’une liste informelle dans un fil de discussion. Il vous faut des documents qui témoignent d’une réflexion cohérente et de l’historique des décisions.
Une taxonomie des risques est un ensemble structuré de catégories servant à regrouper les risques, garantissant ainsi la cohérence du reporting entre les différents projets. Elle permet d’éviter les situations où un chef de projet note « risque fournisseur » tandis qu’un autre inscrit « fiabilité des tiers », empêchant toute consolidation des tendances.
Un registre des risques est une liste contrôlée des risques identifiés et des données relatives à leur gestion. La gouvernance exige généralement des champs spécifiques tels que : ID du risque, Énoncé du risque, Cause, Événement, Impact, Probabilité, Score d'impact, Exposition, Responsable du risque, Stratégie de réponse, Actions de réponse, Date cible, Statut, Éléments déclencheurs et Dernière révision. La piste d’audit est établie en indiquant ce qui a été modifié, à quel moment et par qui la modification a été approuvée.
Question de réflexion : quel champ manquant dans le registre rendrait le plus difficile la preuve que vous avez réellement géré le risque, et non simplement consigné son existence ?
Comparez ce qu’une liste informelle ne permet pas de prouver avec ce qu’un registre encadré par une gouvernance permet de démontrer.