Gestion des risques projet IT avecun registre qui sert vraiment

La gestion des risques projet a mauvaise réputation dans les équipes informatiques : un tableau de trente lignes rempli le jour du lancement, présenté une fois en comité, puis rangé. Quand un problème arrive, il n'était pas dans le tableau, ou il y était et personne ne l'a relu. Vous avez sans doute déjà vécu ce scénario.

Je pilote seul des projets courts, sites, intégrations entre outils, outils métier. Je n'ai pas d'équipe PMO pour tenir un registre à ma place, alors j'ai gardé ce qui sert et jeté le reste. J'ai aussi construit mes propres machines de contenu autour d'une idée simple de contrôle du risque : ce qui se vérifie est vérifié par l'outil, et ce qui ne l'a pas été compte comme un échec. Voici comment je transpose ces réflexes au registre des risques d'un projet informatique.

01Pourquoi les risques d'un projet informatique sont sous-estimés

Une étude menée par Bent Flyvbjerg et ses coauteurs sur 5 392 projets informatiques montre que les dépassements de coût ne suivent pas une courbe en cloche. La plupart restent modestes, mais une queue épaisse de projets dérape de façon extrême, et les décideurs sous-estiment nettement cette probabilité. Le mécanisme proposé par les auteurs parle à tous ceux qui ont mené une intégration : les composants techniques dépendent les uns des autres, et un problème sur l'un se propage aux autres.

J'ai vu une version modeste de cette mécanique sur un projet : un mélange de centimètres et de millimètres entre deux outils a déformé tout un rendu. Le défaut était minuscule à la source, et visible partout à l'arrivée. La leçon que j'en garde est concrète : la donnée de référence doit être explicite, et les dépendances entre outils figurent au registre dès le premier jour.

02Identifier les risques sans brainstorming interminable

Je ne commence pas par « quels sont les risques ? », une question trop large qui produit des généralités (« retard », « budget »). Je relis le cadrage et je cherche quatre choses.

1. Les hypothèses : chaque « on suppose que », « normalement », « le fournisseur nous a dit que ». Une hypothèse non vérifiée est un risque déguisé.
2. Les dépendances : entre outils, entre lots, entre fournisseurs. C'est là que la propagation décrite plus haut commence. Je les dessine avant de les écrire, comme dans un planning de projet web construit sur ses dépendances.
3. Les personnes indispensables : celle qui seule connaît l'ancien système, celle qui valide et part en congé au mauvais moment.
4. Les dates qui ne bougent pas : un salon, une obligation légale, une campagne. J'ai appris à les traiter à part lors de mes débuts en production audiovisuelle, où la date de tournage ne se négocie pas.

L'Orange Book du Trésor britannique ajoute deux angles que j'oublie trop souvent : les limites de l'information dont on dispose, et les biais des personnes qui identifient les risques. Il demande aussi de noter les risques dont la source échappe au projet. Un fournisseur qui change son API ne dépend pas de vous, mais son impact sur votre date, si.

Une heure avec l'équipe et un interlocuteur technique suffit en général pour une première liste de dix à quinze lignes. Au-delà, je fusionne.

03Évaluer probabilité et impact sans fausse précision

L'Orange Book pose le principe : un niveau de risque se définit avec des critères communs qui combinent la probabilité et les conséquences. La tentation est ensuite de construire une matrice de cinq sur cinq, avec des scores de 1 à 25. J'ai renoncé à cette précision.

Dans sa vidéo sur le contenu d'un registre des risques, Mike Clayton conseille de rester sur haut, moyen, bas tant qu'on ne maîtrise pas vraiment les probabilités, et d'ajouter la proximité : un risque qui peut arriver demain mérite plus d'attention qu'un risque prévu dans un an. C'est exactement ce que je fais.

Ma grille en trois questions

• Probabilité : est-ce que ça arrive sur un projet sur trois, un sur dix, ou presque jamais ?
• Impact : est-ce que ça décale la date de mise en production, ça coûte un lot de travail, ou ça se règle dans la journée ?
• Proximité : quand saurons-nous si le risque se produit ?

Le score final n'a qu'un rôle : trier. Je le traduis en rouge, orange ou vert, comme le verdict de mes machines de contenu. Le rouge demande une action avant la prochaine revue. L'orange se justifie par écrit : on l'accepte, mais on dit pourquoi. Le vert se relit seulement.

04Un registre des risques court, avec un propriétaire par ligne

Un petit registre rempli avec constance vaut mieux qu'un grand registre mal tenu : c'est le premier conseil de Mike Clayton dans la vidéo citée plus haut, et je l'ai vérifié à mes dépens. Voici les colonnes que je garde.

• Un identifiant, jamais réutilisé, même quand la ligne est fermée.
• Le risque, écrit sous la forme « si [cause], alors [conséquence] sur [objectif] ».
• La probabilité, l'impact et la proximité : haut, moyen, bas, et une date.
• Le statut, rouge, orange ou vert.
• La réponse : éviter, réduire, partager ou accepter, avec l'action précise.
• Le propriétaire, une personne nommée et pas une équipe.
• Le signal d'alerte, ce qui nous dira que le risque approche.
• La date de prochaine revue.

La colonne réponse reprend les options de l'Orange Book : éviter l'activité qui crée le risque, réduire sa probabilité ou ses conséquences, le partager par contrat, ou l'accepter par une décision éclairée. Le même texte demande que chaque réponse précise les actions, les responsables, les indicateurs d'alerte précoce et les échéances. C'est la colonne « signal d'alerte » qui manque le plus souvent dans les registres que je relis.

Pour les propriétaires, je suis la règle de la vidéo : le chef de projet ne porte pas toutes les lignes. Un responsable de lot prend les risques importants, un spécialiste les risques techniques plus étroits. Sinon personne d'autre ne regarde.

05Faire vivre le registre jusqu'à la mise en production

Un registre vit par sa revue, pas par sa création. L'Orange Book le dit à sa manière : les étapes sont présentées l'une après l'autre, mais en pratique elles sont itératives. Ma routine tient en dix minutes par semaine.

1. Relire les lignes rouges et orange, et elles seules en détail.
2. Pour chacune, vérifier si le signal d'alerte s'est allumé.
3. Ajouter les risques nés pendant la semaine. Un risque identifié entre au registre, même s'il paraît mineur.
4. Fermer ce qui ne peut plus arriver, avec la date et la raison.
5. Remonter au comité de pilotage ce que l'équipe ne peut pas décider seule, sous forme de décision à prendre.

Deux réflexes viennent directement de ma façon de construire des outils. D'abord, une vérification qui n'a pas eu lieu est un rouge, pas un vert : si personne n'a testé la reprise des données, le risque « reprise incomplète » n'est pas maîtrisé, il est inconnu. Ensuite, je vérifie comme un utilisateur final. Sur un projet, un site semblait normal à l'équipe connectée et restait cassé pour les visiteurs à cause d'un cache. Depuis, la recette avant la mise en production se fait aussi en navigation privée.

Le découpage aide également. Le Scrum Guide rappelle qu'une approche itérative sert à contrôler le risque et que des sprints courts limitent le coût d'une erreur à une période plus courte. Livrer une première intégration partielle au bout de deux semaines révèle plus de risques qu'un mois de réunions.

Quand un risque porte sur un calcul, je préfère le tester qu'en débattre. Chez Moonworkers, un oracle écrit à partir des textes officiels a rejoué des centaines de cas de cotisations et trouvé quatre erreurs d'un penny dues à une règle d'arrondi. Aucune grille de probabilité ne les aurait trouvées.

06Ce que le registre ne fera pas pour vous

Le registre ne remplace pas une décision. Une ligne rouge depuis trois semaines sans action est un signal sur la gouvernance du projet, pas sur le risque lui-même.

Il ne capte pas bien les dérapages extrêmes décrits par l'étude de Flyvbjerg : ceux-là naissent souvent d'une chaîne de petites dépendances que personne n'avait reliées. Le registre aide à les voir plus tôt s'il porte les dépendances, il ne les rend pas prévisibles.

Il a aussi un coût. Sur un projet de trois semaines avec deux personnes, je me contente d'une liste de cinq lignes dans le document de cadrage. Je ne ferais pas un registre de trente colonnes pour un site vitrine. Et j'ai déjà raté des risques évidents parce que la liste existait et que je m'y fiais trop : une spécification d'intégration qui bougeait à chaque réunion n'était pas notée comme un risque, alors que c'en était un. Depuis, je la versionne, comme je l'explique dans la spécification d'intégration entre un ERP et un site marchand.

07Par où commencer cette semaine

Prenez votre document de cadrage et soulignez chaque hypothèse. Transformez les cinq plus fragiles en lignes « si…, alors… », donnez à chacune un propriétaire nommé, un signal d'alerte et une date de revue. Bloquez dix minutes par semaine dans l'agenda de l'équipe pour les relire. Ce petit registre vous dira plus de choses qu'un grand tableau remis au comité.

Si vous lancez un projet informatique et voulez un regard extérieur sur ses risques avant de vous engager, je fais ce type de cadrage dans mes missions de direction de projet. On peut en parler.