Incident, risque ou demande de modification : les différences

Dans tout projet apparaissent trois sortes de « choses à traiter » qu’on confond souvent : ce qui s’est déjà produit, ce qui pourrait se produire et ce que quelqu’un demande. Les traiter de la même façon est une erreur coûteuse : chacune se gère différemment, avec un autre responsable, d’autres délais et d’autres conséquences. Ce guide donne une règle simple pour les distinguer et un exemple de chacune.

Les trois définitions

La règle de décision

Posez-vous trois questions, dans cet ordre :

1. Quelqu’un demande-t-il quelque chose qui n’était pas convenu ? Si oui, c’est une demande de modification, même si la demande arrive déguisée en problème (« le rapport n’a pas la colonne zone » peut être une erreur, si c’était dans le périmètre, ou un changement, si ça n’y était pas).
2. Sinon, est-ce déjà arrivé ? Si oui, c’est un incident.
3. Sinon, cela pourrait-il arriver ? Alors c’est un risque.

La première question est la plus importante, car elle protège le périmètre : un changement traité comme un incident se règle « gratuitement » dans le budget.

Un exemple de chacun

• Incident : « Le chargement des clients a échoué : il manque 300 enregistrements. » C’est déjà arrivé. On l’affecte à quelqu’un, on lui donne une gravité et une priorité, on saisit des heures jusqu’à sa résolution et on le clôture.
• Risque : « Si le client ne livre pas les données articles avant le 15, la migration prendra du retard. » Ce n’est pas encore arrivé. On le note avec probabilité et impact et un plan : demander les données à l’avance, préparer un chargement partiel.
• Demande de modification : « Nous voulons ajouter un rapport de ventes par zone. » Ce n’était pas convenu. On l’enregistre avec son demandeur, on estime l’effort et on décide de l’approuver ou non, et à quel coût.

Comment ils se transforment l’un en l’autre

Les trois catégories ne sont pas des compartiments étanches :

• Un risque qui se réalise devient un incident. Si le client n’a pas livré les données, on ne le surveille plus : on le résout.
• Un incident peut révéler un changement. Si, en enquêtant sur une « anomalie », on s’aperçoit que le système fait ce qui était convenu mais que le client attendait autre chose, ce qui reste est une demande de modification.
• Un incident répété cache souvent un risque qu’on n’avait pas vu : mieux vaut le noter pour qu’il ne se reproduise pas.
• Un changement approuvé peut apporter de nouveaux risques : plus de périmètre, moins de marge.

Erreurs fréquentes

1. Tout mélanger dans une seule liste de « points en suspens ». On perd la distinction entre urgent, important et facultatif.
2. Traiter les changements comme des incidents pour éviter la conversation délicate avec le client. Le périmètre dévore le budget sans que personne ne le voie.
3. Ne pas enregistrer les risques avant qu’ils ne deviennent des incidents, quand il n’y a plus de marge pour les prévenir.
4. Donner à tous les incidents la même gravité. La gravité (quel dommage) et la priorité (quand on le traite) sont des axes différents : un incident peut être grave sans être urgent, ou mineur et urgent.
5. Clore sans consigner la cause, de sorte que l’enseignement se perd.

Comment on fait dans PjMan

PjMan a un registre distinct pour chacun, dans chaque projet, pour qu’ils ne se mélangent pas :

• Incidents : une entité indépendante des tâches, avec statut (issu d’un catalogue de l’organisation que le PM configure ; par défaut Ouvert, En analyse, En résolution, Résolu et Clos), gravité et priorité comme axes séparés, affectés, heures estimées et saisies, dates de détection et de clôture (celle-ci posée automatiquement au passage à un statut final) et lien facultatif avec une phase ou une tâche. Ils ont une liste et un tableau Kanban, et comptent dans les rapports (ouverts, clos, délai moyen de résolution, non affectés). (Incidents)
• Risques : avec probabilité, impact, priorité, statut et plan de mitigation. (Risques)
• Demandes de modification : avec demandeur, effort, coût et délai estimés, et un statut en attente, approuvée ou refusée. (Demandes de modification)

Chacun a son code court (I0003, R0002, S0001), qui sert à le citer dans une conversation ou à le demander à l’assistant. La visibilité diffère aussi : la direction du projet voit les trois, mais un consultant peut voir et créer des incidents liés à son travail et n’a pas accès aux risques ni aux demandes de modification. (Rôles et accès) Rapports rassemble les indicateurs d’incidents de vos projets. (Rapports)

Pour aller plus loin, les guides sur le registre des risques et sur les demandes de modification traitent chaque cas plus en détail.

Créez votre compte ou explorez la démo.

Questions fréquentes

Une erreur du client dans ses propres données est-elle un incident ou un changement ? Si elle bloque le travail prévu, c’est un incident (il faut lever le blocage). Si la correction implique un travail hors périmètre, il y a en plus un changement à trancher.

Où noter quelque chose qui pourrait arriver sans que je sache à quel point c’est probable ? Dans les risques, avec une probabilité moyenne. L’important est de l’écrire et de le revoir.

Puis-je convertir l’un en l’autre ? Dans PjMan, chaque enregistrement est indépendant ; si un risque se réalise, vous enregistrez l’incident et clôturez le risque. L’historique reste dans chaque enregistrement.