Un projet ne dérape pas sans prévenir. Les signaux sont toujours visibles, encore faut-il les regarder. En vingt ans à concevoir et livrer des projets complexes, je n’ai jamais vu un échec qui n’ait pas été annoncé des mois à l’avance par des signes que tout le monde avait sous les yeux et que personne n’avait envie de nommer.
Le problème n’est pas le manque d’indicateurs. Les comités de pilotage en débordent. Le problème, c’est le choix des indicateurs : la plupart des projets suivent le planning, le budget et le nombre de tickets fermés, et pensent être sous contrôle. En réalité, ils ignorent l’essentiel : le niveau réel de l’équipe, la qualité de ce qui est livré, et la valeur créée. Résultat classique : un projet « dans les clous » pendant dix mois, et un échec à la livraison.
Le confort des indicateurs rassurants
Le planning, le budget et le volume de tickets ont un point commun : ils mesurent de l’activité, pas du résultat. Une équipe peut fermer cent tickets par semaine en produisant un logiciel que personne n’utilisera. Un budget peut être respecté au centime sur un périmètre qui a discrètement fondu de moitié. Un planning peut être tenu grâce à des raccourcis techniques qui exploseront en production trois mois après la fête de fin de projet.
Ces indicateurs sont populaires parce qu’ils sont confortables. Ils sont faciles à produire, ils rassurent la direction et ils ne mettent personne en cause. Les vrais indicateurs de santé d’un projet ne sont pas confortables : ils exposent les failles, et ils désignent des décisions.
Cinq KPI de projet informatique qui dérangent
Voici ceux que nous installons sur les projets que nous pilotons, et ce que chacun révèle.
- Le taux de retravail : la part du travail livré qu’il faut refaire. Il montre des décisions mal prises en amont, un cadrage flou, des exigences comprises de travers. Le rapport DORA 2024, référence sur la performance des équipes de livraison logicielle, a d’ailleurs ajouté le taux de retravail à ses indicateurs historiques, défini comme la part des déploiements non planifiés faits pour corriger des bugs vus par les utilisateurs.
- Le turnover projet : combien de personnes ont quitté l’équipe depuis le début. Un projet qui perd un tiers de son équipe en un an ne sera pas livré comme prévu, quoi que dise le planning. Ce signal est presque toujours ignoré parce qu’il met en cause l’organisation, pas les individus.
- Le time-to-value : le délai entre le début du travail sur une fonctionnalité et le moment où un utilisateur en tire un bénéfice réel. S’il se compte en trimestres, le projet fabrique du stock, pas de la valeur. Et un stock logiciel se déprécie vite.
- La séniorité réelle de l’équipe : pas les années de CV, la capacité à décider et à reconnaître les signaux faibles. À mon avis, c’est l’indicateur qui explique la plupart des dérives. Une équipe qui apprend le contexte pendant six mois prend ses décisions structurantes au moment où elle les comprend le moins. Nous avons chiffré ce coût dans consultant senior ou junior.
- Les bugs en production : leur nombre, mais surtout leur nature. Des bugs de compréhension métier signalent un cadrage défaillant ; des bugs de régression signalent l’absence de filet de tests. Quand ils apparaissent, le problème est déjà ancien.
Comment les mesurer sans usine à gaz
L’objection classique est que ces indicateurs sont difficiles à produire. Ce n’est pas vrai, à condition d’accepter des mesures simples et honnêtes plutôt que des tableaux de bord parfaits.
Le taux de retravail se lit dans l’outil de suivi : il suffit d’étiqueter les tickets qui reprennent un travail déjà livré. Le turnover projet est une liste de noms et de dates. Le time-to-value demande de noter deux dates par fonctionnalité, le début et la première utilisation réelle. La séniorité réelle se juge en revue : qui pose les questions, qui repère les risques, qui tranche. Les bugs en production se classent en trois catégories à la main, une fois par mois, en une heure.
L’important n’est pas la précision, c’est la tendance et la régularité. Un indicateur approximatif regardé chaque mois vaut infiniment plus qu’un indicateur exact produit une fois par an.
Le courage de regarder
La vraie difficulté n’est pas technique. Un indicateur qui dérange désigne une décision à prendre : remplacer un profil, revoir un périmètre, arrêter une fonctionnalité, dire au sponsor que le planning est fictif. C’est pour éviter ces décisions que les projets s’entourent d’indicateurs rassurants.
Un bon pilotage consiste à voir ce que les autres ne regardent pas, puis à en parler avant que cela ne coûte. Il faut pour cela un pilote qui ne dépende pas du confort du sponsor, et une relation où l’on peut annoncer une mauvaise nouvelle sans que le messager soit sanctionné. Ce sont des conditions humaines, pas méthodologiques.
Un projet ne se pilote pas avec des indicateurs rassurants. Il se pilote avec ceux qui dérangent, parce que ce sont les seuls qui permettent d’agir tôt.
Cédric Gérard, Directeur Associé
Ce que nous mettons en place chez Voxalia
Notre pôle Pilotage de projet installe ces cinq indicateurs dès le cadrage, avec une revue mensuelle où ils sont lus avec le client, sans filtre. Nous y ajoutons une règle que nous nous imposons à nous-mêmes : nos propres consultants sont soumis aux mêmes mesures. Si le turnover projet ou le retravail se dégrade sur une équipe que nous avons constituée, c’est notre responsabilité, et nous la prenons avant que le client n’ait à la réclamer.
Cette transparence sur la santé réelle des projets est le pendant de la transparence sur nos marges. Dans les deux cas, l’idée est la même : montrer les chiffres qui comptent, y compris quand ils ne nous arrangent pas, parce que c’est la seule manière d’agir à temps.
Questions fréquentes
Quels sont les KPI d’un projet informatique ?
Les classiques mesurent l’activité : respect du planning, consommation du budget, tickets fermés. Les KPI utiles mesurent la santé : taux de retravail, turnover projet, time-to-value, séniorité réelle de l’équipe et nature des bugs en production. Les premiers rassurent, les seconds permettent d’agir.
Qu’est-ce que le taux de retravail ?
La part du travail livré qu’il faut refaire. Le rapport DORA 2024 le définit comme la part des déploiements non planifiés effectués pour corriger des bugs vus par les utilisateurs. Il se mesure en étiquetant les tickets qui reprennent un travail déjà livré.
Comment mesurer le time-to-value ?
En notant deux dates par fonctionnalité : le début du travail et la première utilisation réelle par un utilisateur. La tendance mensuelle compte plus que la précision ; un délai qui se compte en trimestres signale un projet qui fabrique du stock.
Sources
- DORA, Accelerate State of DevOps Report 2024 (introduction du taux de retravail parmi les indicateurs de performance).
- Voxalia, publication LinkedIn « Un projet ne dérape pas sans prévenir ».
