Suivi de projet : indicateurs, burndown, écarts et risques

Suivre un projet, c'est comparer régulièrement ce qui a été réalisé à ce qui était prévu (en délai, en charge, en coût et en qualité), expliquer les écarts et décider des actions qui remettent le projet sur ses rails. Les indicateurs de suivi rendent ces écarts visibles : reste à faire, avancement, glissement des jalons, burndown chart en agile. Ce chapitre montre comment calculer ces indicateurs, les présenter dans un tableau de bord, analyser un écart, traiter une demande de changement et tenir un registre des risques. C'est le cœur de l'indicateur de l'E5 « Un compte rendu clair et concis est réalisé et les écarts sont justifiés ».

Le cycle du suivi

Le suivi est un cycle qu'on répète à chaque point d'avancement, chaque semaine dans un projet prédictif, chaque jour et à chaque fin de sprint en Scrum :

1. Mesurer : relever ce qui a été consommé (le temps passé, les dépenses) et ce qui reste à faire.
2. Comparer : mettre ces chiffres en face du planning et du budget de référence.
3. Analyser : comprendre la cause de chaque écart significatif.
4. Décider : choisir une action corrective, ou accepter l'écart.
5. Communiquer : informer l'équipe et la MOA, par un compte rendu et un tableau de bord (chapitre 11).

Consommé, reste à faire, avancement

Pour chaque tâche, on relève deux chiffres : la charge consommée (le travail déjà passé, en jours-homme) et le reste à faire (RAF), estimé par la personne qui fait la tâche. On en déduit trois indicateurs :

Exemple : une tâche prévue à 20 jh a consommé 15 jh et il reste 10 jh à faire. Réestimé : 15 + 10 = 25 jh. Écart : 25 − 20 = +5 jh, soit +25 %. Avancement : 15 ÷ 25 = 60 %. Le développeur aurait peut-être dit « je suis à 75 % » parce qu'il a passé 15 jours sur les 20 prévus : c'est faux, il n'est qu'à 60 %.

Le point d'avancement du renouvellement du parc

Le soir du jour 24, après les tests sur postes pilotes, Antoine Mercier fait le point par lot du WBS.

Lecture : le projet coûtera 37 jh au lieu de 33,5, soit +3,5 jh (+10,4 %). L'avancement global est de 23 ÷ 37 ≈ 62 %. Côté budget, 3,5 jh × 320 € = 1 120 € de main-d'œuvre en plus, absorbés par la réserve pour aléas de 2 536 € (le budget). Côté délai, les tests pilotes ont révélé qu'un logiciel métier doit être réinstallé à la main sur chaque poste : le déploiement passe de 8 à 9 jh. Avec deux techniciens, la tâche I dure 4,5 jours au lieu de 4 ; comme elle est sur le chemin critique, la fin glisse d'une demi-journée.

Le suivi des délais et des jalons

Pour le délai, on suit d'abord les jalons : date prévue, date réelle ou réestimée, glissement.

Sur le Gantt de suivi, on superpose le planning de référence (en gris) et le planning à jour, et on trace une ligne verticale à la date du jour : toute barre qui devrait être finie à gauche de cette ligne et ne l'est pas signale un retard. Un glissement sur une tâche critique se reporte sur la date de fin ; sur une tâche qui a de la marge, il la consomme (le chemin critique).

Le tableau de bord du projet

Le tableau de bord résume l'état du projet en une page, pour la MOA et le comité de pilotage. On y utilise souvent une météo par axe : vert (conforme), orange (écart sous contrôle), rouge (écart qui menace l'objectif et demande une décision).

Le burndown chart en agile

Le burndown chart (graphique d'avancement descendant) montre le travail restant dans le sprint, jour après jour. L'axe horizontal porte les jours du sprint, l'axe vertical le travail restant (en points ou en heures). Une ligne idéale relie le total du premier jour à zéro le dernier jour ; la courbe réelle montre ce qui reste vraiment.

Lire un burndown :

• courbe réelle au-dessus de la ligne idéale : l'équipe est en retard sur son rythme ; si l'écart persiste, l'Objectif de Sprint est menacé ;
• courbe en dessous : l'équipe est en avance, elle pourra peut-être prendre un élément de plus ;
• courbe plate pendant plusieurs jours : rien n'est terminé, soit parce que les éléments sont trop gros, soit parce que l'équipe est bloquée ;
• courbe qui remonte : du travail a été ajouté en cours de sprint, ce qui doit rester exceptionnel.

Le burndown de Prêt'Matos est en escalier, parce que les points ne descendent que lorsqu'une story est entièrement terminée. C'est honnête, mais peu lisible en début de sprint. Beaucoup d'équipes tracent plutôt le burndown des heures restantes sur les tâches du Sprint Backlog, plus régulier. Au Daily Scrum du jour 6, la courbe plate depuis le jour 4 aurait dû alerter : l'équipe avait deux stories en cours en même temps et n'en terminait aucune.

Deux variantes complètent le burndown :

• le burnup chart trace le travail terminé, qui monte, et le travail total prévu, en haut : si le périmètre augmente, la ligne du haut monte aussi, ce que le burndown cache ;
• le burndown de release suit les points restants de tout le backlog, sprint après sprint, pour prévoir une date de fin ; il s'appuie sur la vélocité.

Les autres indicateurs utiles en agile : la vélocité par sprint, le nombre d'anomalies ouvertes, le taux de stories terminées par rapport aux stories engagées, et en Kanban le délai de livraison (mesurer le flux).

Analyser un écart et réagir

Un écart n'est ni une faute ni une fatalité : c'est une information. Pour chaque écart significatif, cherche sa cause avant de choisir l'action.

Les actions possibles se rangent en quelques familles : replanifier (changer l'ordre, utiliser les marges), renforcer (ajouter une ressource, avec les limites vues au chapitre 1), réduire le périmètre (avec l'accord de la MOA), utiliser la réserve et, si rien ne suffit, escalader : présenter le problème et les options chiffrées au comité de pilotage, qui décide.

Traiter une demande de changement

Une demande de changement modifie ce qui a été validé : le périmètre, la date, le budget, une exigence. En approche prédictive, elle suit un circuit :

1. Enregistrer la demande : qui la fait, quoi, pourquoi, pour quand.
2. Analyser l'impact sur le triangle : combien de jours-homme, quel décalage, quel coût, quels risques.
3. Décider : la MOA, ou le comité de pilotage si l'impact dépasse ce qu'elle peut engager, accepte, refuse ou reporte.
4. Mettre à jour le cahier des charges, le planning et le budget si le changement est accepté (on parle d'avenant quand le contrat est modifié).
5. Communiquer la décision à l'équipe et aux parties prenantes.

En Scrum, le circuit est plus léger : la demande devient un élément du Product Backlog, que le Product Owner ordonne comme les autres ; elle n'entre pas dans le sprint en cours si elle remet en cause l'Objectif de Sprint. Dans les deux cas, la règle est la même : aucun changement sans décision de celui qui porte le besoin. Le cours ITIL décrit la même logique pour les changements en production (gestion des changements).

Le registre des risques

Un risque projet est un événement incertain qui, s'il se produit, a un effet sur les objectifs du projet : retard, surcoût, baisse de qualité. Un risque n'est pas un problème : le problème est déjà là, le risque peut encore être évité. On les recense dans un registre des risques, dès le cadrage, et on le revoit à chaque point d'avancement.

Pour chaque risque, on note sa probabilité et son impact sur une échelle de 1 (faible) à 4 (très fort), et on calcule sa criticité = probabilité × impact, qui sert à les classer.

Quatre réponses sont possibles face à un risque, comme en sécurité informatique (traitement du risque) :

• éviter : supprimer la cause, en changeant de solution ou de périmètre (ne pas migrer pendant la clôture comptable) ;
• réduire : diminuer la probabilité ou l'impact (tester tôt, prévoir un plan B) ;
• transférer : confier la conséquence à un tiers (pénalités contractuelles, assurance, prestataire) ;
• accepter : ne rien faire de plus, en connaissance de cause, pour les risques faibles, et prévoir la réserve.

Exercices

Exercice 1 sur 4 Avancement et reste à faire Réussi À revoir

Trois tâches d'un projet de développement en sont là :

Tâche	Prévu (jh)	Consommé	Reste à faire
Écrans de saisie	10	8	4
Reprise des données	6	6	0
Tests	8	2	5

1. Calcule, pour chaque tâche et pour l'ensemble, la charge réestimée, l'écart et l'avancement.
2. La développeuse des écrans dit qu'elle est « à 80 % ». Qu'en penses-tu ?

Voir la réponseMasquer la réponse de l'exercice 1

1. Écrans : réestimé 8 + 4 = 12 jh, écart +2 jh, avancement 8 ÷ 12 ≈ 67 %. Reprise : réestimé 6 jh, écart 0, avancement 100 %. Tests : réestimé 2 + 5 = 7 jh, écart −1 jh, avancement 2 ÷ 7 ≈ 29 %. Ensemble : prévu 24 jh, consommé 16, reste 9, réestimé 25 jh, écart +1 jh (+4,2 %), avancement 16 ÷ 25 = 64 %.
2. Elle a consommé 8 jh sur 10 prévus, d'où son « 80 % », mais il lui reste 4 jh : son avancement réel est d'environ 67 %. Le pourcentage du budget consommé n'est pas un avancement.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Lire un burndown Réussi À revoir

Le burndown d'un sprint de 10 jours part de 30 points. Voici le travail restant, jour par jour (valeurs du jour 0 au jour 10) : 30, 30, 27, 27, 27, 27, 27, 22, 14, 9, 6.

1. Où devrait se trouver la ligne idéale au jour 5 ?
2. Que s'est-il passé entre le jour 2 et le jour 6 ? Qu'aurait dû faire l'équipe ?
3. Quelle est la vélocité du sprint ?

Voir la réponseMasquer la réponse de l'exercice 2

1. La ligne idéale descend de 3 points par jour (30 ÷ 10) : au jour 5, elle est à 15 points. La courbe réelle est à 27.
2. La courbe est plate pendant quatre jours : aucun élément n'a été terminé. L'équipe a probablement trop de stories en cours, ou des stories trop grosses, ou elle est bloquée. Au Daily Scrum, elle aurait dû le voir et réagir : finir une story avant d'en commencer une autre, découper, faire lever le blocage, et prévenir le Product Owner que l'Objectif de Sprint était menacé.
3. 30 − 6 = 24 points (les 6 points restants ne comptent pas, puisqu'ils ne sont pas terminés).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Le registre des risques d'une migration Réussi À revoir

Une PME migre sa messagerie vers un service en ligne. Pour chaque risque, calcule la criticité (probabilité × impact, échelles de 1 à 4), classe les risques et propose une réponse pour les deux premiers.

Risque	Probabilité	Impact
Des courriels perdus pendant la bascule	2	4
Les utilisateurs ne retrouvent pas leurs dossiers	3	2
Le prestataire de migration est indisponible le jour J	1	3
Le changement d'enregistrements DNS met du temps à se propager	3	3

Voir la réponseMasquer la réponse de l'exercice 3

Criticités : propagation DNS 3 × 3 = 9 ; courriels perdus 2 × 4 = 8 ; dossiers 3 × 2 = 6 ; prestataire 1 × 3 = 3. Classement : DNS, courriels perdus, dossiers, prestataire.

• Propagation DNS (réduire) : abaisser la durée de vie des enregistrements (TTL) quelques jours avant, basculer un vendredi soir, garder l'ancien serveur actif pendant la transition.
• Courriels perdus (réduire) : migration en deux passes (une copie la veille, une synchronisation finale), sauvegarde des boîtes avant la bascule, vérification par échantillon après.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Une demande de changement Réussi À revoir

En plein déploiement du parc, la directrice demande d'ajouter l'installation de deux imprimantes multifonctions neuves, achetées à part. Antoine estime le travail à 1,5 jh, sur le chemin critique.

1. Ce travail fait-il partie du projet ? Que dit le cahier des charges ?
2. Décris le circuit que doit suivre la demande et les chiffres qu'Antoine doit fournir.

Voir la réponseMasquer la réponse de l'exercice 4

1. Non : le périmètre du cahier des charges exclut explicitement les imprimantes (le cahier des charges). C'est une demande de changement.
2. Antoine enregistre la demande, puis en chiffre l'impact : 1,5 jh × 320 € = 480 € de main-d'œuvre, et environ un jour de décalage de la fin du projet si elle est faite pendant le déploiement (avec deux techniciens, 1,5 jh durent 0,75 jour, arrondi à un jour). Il propose une alternative : l'installer après la tâche J, ou la confier comme demande séparée au support. La directrice, qui porte le besoin et le budget, décide ; Antoine met à jour le planning et le budget, et la décision figure dans le compte rendu.

Tu avais trouvé ?

Oui, j'avais bonPas encore