J'ai vu des dashboards de projet avec 40 indicateurs que personne ne regardait et des reports hebdomadaires de deux pages que le sponsor ouvrait sans lire. Le problème n'est pas le manque de données : c'est l'excès de métriques qui ne pilotent aucune décision. Ce guide liste uniquement les métriques qui, dans mon expérience directe, changent réellement le comportement de qui les lit.
1. Schedule Performance Index (SPI) et Cost Performance Index (CPI). Dérivés de l'Earned Value Management, SPI et CPI restent les indicateurs les plus fiables pour des projets avec budget et schedule définis. SPI en dessous de 1.0 indique un retard, CPI en dessous de 1.0 indique un dépassement de budget. La vraie valeur n'est pas le nombre isolé, mais la tendance : un SPI qui baisse semaine après semaine est un signal d'alarme bien plus utile qu'une donnée négative isolée.
2. Burn rate et runway (pour projets à budget fixe). Combien de budget vous consommez par semaine par rapport à ce qu'il reste. Pour des projets à timeline longue, cet indicateur anticipe un problème de budget avec des semaines d'avance par rapport à un report de coûts consuntifs traditionnel.
3. Lead time et cycle time (pour équipes Kanban/flux continu). Pour les équipes qui travaillent en flux (support, operations, maintenance), velocity et burndown n'ont pas de sens. Lead time (de l'entrée du task à la sortie) et cycle time (du début du travail effectif à la sortie) sont les métriques correctes parce qu'elles reflètent l'expérience réelle du stakeholder qui attend le résultat.
4. Pourcentage de milestones atteintes on-time vs replanned. Il ne suffit pas de regarder si une milestone a été atteinte : ce qui compte c'est combien de fois elle a été replanifiée avant de l'être. Une milestone atteinte après trois replanifications signale un problème d'estimation ou d'exécution que le simple 'atteinte oui/non' cache complètement.
5. Le report que le sponsor lit vraiment. Le format qui fonctionne le mieux dans mon expérience est une page unique structurée ainsi : état général (vert/jaune/rouge) en haut, trois bullets sur ce qui a changé depuis la semaine dernière, les risques qui demandent une décision dans les 7 jours, et rien d'autre. Chaque détail supplémentaire doit être disponible sur demande, pas inclus par défaut — le but du report est de générer des décisions, pas de démontrer combien de travail a été fait.
FAQ. Combien de KPI devrait avoir un dashboard de projet ? Entre 4 et 6 pour le niveau sponsor/board. L'équipe opérationnelle peut en monitorer davantage au niveau de détail, mais la synthèse vers le haut doit rester essentielle. L'EVM (Earned Value Management) est-il encore pertinent en 2026 avec les méthodologies agiles ? Oui, sous forme adaptée : beaucoup d'équipes agiles appliquent l'EVM au niveau release ou programme même si pas au niveau du sprint individuel.
Si votre reporting de projet actuel génère des données mais pas de décisions, réservons une call : je vous aide à redessiner un set de KPI essentiel et un format de report que le sponsor lit vraiment.
