Il y a une question que je pose souvent en début de formation sur le management de projet. Je demande aux participants combien de projets ils pilotent ou auxquels ils contribuent en ce moment. Les réponses tournent rarement autour de un ou deux, on est plus sur trois, quatre, cinq projets en parallèle — en plus de l’activité habituelle.
Et pendant ce temps, les résultats ne sont pas à la hauteur.
Le Standish Group suit les résultats de projets informatiques depuis 2014 — plus de 40 000 projets analysés. En 2020, leur constat est le suivant : 31 % des projets atteignent leurs objectifs dans les délais et le budget prévu. 50 % sont en difficulté — résultats partiels, retards importants, surcoûts. Et 19 % sont abandonnés ou échouent complètement. Soit 69 % des projets avec des difficultés significatives.
Ce chiffre évolue d’une année à l’autre, et le périmètre informatique a ses spécificités. Mais dans mes interventions depuis vingt ans, dans des contextes très différents — distribution, administration, laboratoires, BTP, ONG — je retrouve les mêmes mécanismes. Pas parce que les personnes manquent de compétences ou de volonté. Mais parce qu’on part souvent du mauvais endroit.
Un projet est réussi quand il fournit une solution utile, utilisable et utilisée. Pas quand il est livré.
Cette distinction semble évidente. Elle est pourtant massivement ignorée dans la façon dont les projets sont pilotés.
Déployer un nouveau système d’information, réorganiser un service, mettre en place une nouvelle procédure — ce sont des livrables. Des moyens. Le projet n’est pas réussi le jour où la solution est déployée. Il est réussi — ou pas — dans les semaines et les mois qui suivent, quand on peut constater que les objectifs qui avaient justifié le projet sont réellement atteints.
Cette confusion entre la solution technique et le résultat attendu est l’une des causes les plus fréquentes d’échec. Les équipes projet sont missionnées sur le livrable. Elles font leur travail. Mais si personne ne s’est assuré que la solution serait réellement appropriée, utile dans le contexte réel des utilisateurs, et soutenue dans la durée — le projet technique réussit et le projet organisationnel échoue.
C’est exactement ce que décrivait Churchill à sa manière : on ne croit aux statistiques que si on les a soi-même fabriquées. Mais les mécanismes d’échec, eux, sont documentés depuis assez longtemps pour qu’on arrête d’en être surpris.
La réussite d’un projet repose sur quatre dimensions. La plupart des organisations n’en travaillent qu’une ou deux.
Les finalités. Le contexte dans lequel le projet s’inscrit, les enjeux pour l’organisation, les objectifs concrets qu’on cherche à atteindre. Pas le projet lui-même — la raison pour laquelle on l’a lancé. Donner du sens au projet, c’est relier en permanence ce qu’on fait à ce pourquoi on le fait.
Les utilisateurs. Les besoins réels des personnes qui vont vivre avec la solution — pas seulement les spécifications fonctionnelles. Il y a presque toujours un écart entre ce que les commanditaires demandent et ce dont les utilisateurs ont vraiment besoin. Coconstruire avec eux n’est pas une bonne pratique optionnelle — c’est une condition de l’appropriation. Une solution conçue en chambre, sans les utilisateurs, sera utilisée de façon dégradée ou contournée.
Les méthodes et les outils. Le référentiel, le planning, le reporting, la gestion des risques. C’est la dimension que la plupart des organisations travaillent en priorité — parfois en exclusivité. Ce n’est pas là que la réussite se joue, mais c’est là que la plupart des formations se concentrent.
Les acteurs. Le commanditaire, le chef de projet, l’équipe, les contributeurs, les managers des membres de l’équipe, les parties prenantes externes. Ce sont les humains qui font réussir le projet — pas les méthodes. Et pourtant, c’est la dimension la moins investie dans la plupart des organisations.
Le piège est classique : on achète un référentiel, on déploie un outil de gestion de projet, on forme les chefs de projet aux livrables et aux jalons — et on est surpris que ça ne suffise pas.
J’ai eu récemment un client qui s’était rendu compte, après coup, qu’il avait acheté un outil de gestion de projet surdimensionné pour ses besoins réels. Trois post-its et Excel auraient fait l’affaire. L’outil n’était pas le problème. Le problème, c’était la façon dont les acteurs travaillaient ensemble.
Depuis vingt ans, j’entends les mêmes verbatims revenir dans nos formations sur le management de projet. Ils ne sont pas anecdotiques — ils décrivent des difficultés structurelles.
« Je suis sur trois projets en plus de mon activité habituelle. Je ne vois plus le jour. » C’est probablement la situation la plus répandue. Chaque projet a l’impression d’être le seul. Chaque chef de projet pense bénéficier d’une ressource dédiée. La réalité, c’est un contributeur qui arbitre en permanence entre des priorités contradictoires, sans jamais pouvoir s’engager vraiment sur aucune.
« Quand je vois la taille du référentiel projet de notre organisation, j’ai peur qu’on me demande de tout appliquer. » Le référentiel est un moyen. Quand il devient une fin en soi, il génère de l’anxiété et de la résistance. J’ai vu des organisations dont le référentiel prévoit plus de 80 livrables pour des projets qui n’en nécessitent pas le dixième.
« On fait des plannings, mais ils ne sont jamais respectés. » Ce n’est pas un problème de planning — c’est un problème d’engagement, de priorités et de gouvernance. Un planning qu’on ne respecte pas est souvent un planning qu’on n’a pas construit avec les bonnes personnes, ou dans lequel on n’a pas prévu les bons arbitrages.
« Les équipes expérimentées accompagnent les grands projets, mais ne sont pas disponibles pour les petits. » Or c’est souvent en réussissant des petits projets qu’on construit la capacité à réussir les grands. L’expérience ne se transfère pas par osmose — elle se construit dans la pratique accompagnée.
« Dès que le projet est terminé, on passe à autre chose. On fait rarement des retours d’expérience. » C’est la phase de capitalisation — la plus sacrifiée, systématiquement. On la zappe quand le projet s’est bien passé parce qu’on est déjà sur le suivant. On la zappe quand le projet s’est mal passé parce qu’on préfère ne pas y revenir. Résultat : l’expérience s’accumule sans se transformer en compétence.
Voilà ce que vingt ans d’interventions m’ont appris sur les projets.
Les méthodes comptent. Un projet sans repères méthodologiques partagés perd du temps et génère des malentendus. Mais des personnes motivées réussiront avec une méthode imparfaite. L’inverse n’est pas vrai.
La gouvernance compte. Un commanditaire trop présent qui interfère à chaque décision est aussi problématique qu’un commanditaire absent qui ne répond plus aux questions critiques. Définir qui décide quoi, à quel moment et selon quels critères, c’est un travail que la plupart des projets ne font pas sérieusement.
Le dimensionnement compte. Il n’existe pas une méthode projet universelle applicable à tous les contextes. Un projet individuel de trois semaines, un projet d’équipe de six mois, et un méga-projet pluriannuel n’ont pas les mêmes besoins de structure, de reporting ou de coordination. Savoir dimensionner — choisir ce qu’on va faire et ce qu’on ne fera pas — est une compétence en soi, rarement enseignée.
La capitalisation compte. Un projet terminé sans retour d’expérience est une occasion manquée. Pas parce que les processus l’exigent — parce que c’est là que se construit vraiment la capacité à réussir les projets suivants. L’expérience brute ne devient compétence que si elle est analysée, mise en mots et partagée.
Et les acteurs comptent plus que tout le reste. Comprendre qui joue quel rôle dans un projet — commanditaire, chef de projet, contributeur, utilisateur, manager de ressources, expert — et faire en sorte que chacun comprenne ce qu’on attend de lui, c’est la condition de base. Évidente en théorie. Rarement mise en œuvre sérieusement en pratique.
La bonne question n’est pas « comment appliquer une méthode projet ». C’est « qu’est-ce qui empêche réellement les projets de réussir dans mon contexte » ?
Les causes varient selon les organisations. Certaines manquent de repères méthodologiques partagés. D’autres ont trop de méthode et pas assez d’agilité. D’autres ont des acteurs très compétents individuellement qui peinent à travailler ensemble. D’autres encore ont des commanditaires qui ne jouent pas leur rôle.
Un diagnostic honnête de la situation actuelle — ce qui fonctionne déjà, ce qui achoppe, les causes réelles des difficultés — vaut mieux qu’un programme de formation générique sur la gestion de projet. Ce qu’on va mettre en place doit partir du besoin et des acteurs réels, pas du contenu disponible et des méthodes à la mode.
C’est ce que je propose d’explorer dans la formation.
Pour aller plus loin :
Pourquoi les méthodes de gestion de projet ne suffisent-elles pas à faire réussir les projets ? Parce que la réussite d’un projet ne se joue pas uniquement sur les livrables et les jalons — elle se joue sur quatre dimensions complémentaires : les finalités, les utilisateurs, les méthodes et les acteurs. La plupart des organisations ne travaillent que la troisième. Des personnes motivées réussiront avec une méthode imparfaite. L’inverse n’est pas vrai.
Qu’est-ce qu’un projet réussi concrètement ? Un projet qui fournit une solution utile, utilisable et utilisée. Pas un projet livré dans les délais. La solution déployée n’est pas l’objectif — elle est le moyen. Le projet est réussi quand les effets attendus sont réellement atteints dans le quotidien des utilisateurs.
Comment adapter la méthode projet à la taille du projet ? En partant du projet réel plutôt que d’un référentiel standard. Un projet de trois semaines avec deux personnes n’a pas besoin des mêmes outils qu’un méga-projet pluriannuel. Dimensionner — choisir ce qu’on va faire et ce qu’on ne fera pas — est une compétence en soi. Le mieux est l’ennemi du bien.
Pourquoi les retours d’expérience sont-ils si rarement faits ? Parce qu’on passe toujours au projet suivant. Quand le projet s’est bien passé, on n’a pas le temps. Quand il s’est mal passé, on préfère ne pas y revenir. Résultat : l’expérience s’accumule sans se transformer en compétence. La capitalisation est la phase la plus sacrifiée — et l’une de celles qui conditionne le plus la capacité à réussir les projets futurs.
Les actualités, les moments forts et le point de vue des designers pédagogiques d’Eikos sur la formation professionnelle.
Pour ne rien manquer de l’activité d’Eikos Concepts, abonnez-vous à notre newsletter !
Indiquez votre adresse email pour recevoir la ressource dans votre boite de réception