Un livrable que tout le monde produit et que personne n’utilise
Vous cherchez pourquoi le projet précédent a dérapé de trois mois. Le chef de projet a quitté l’équipe, le sponsor a changé de poste, et le registre des leçons apprises dort dans un répertoire partagé que personne n’a ouvert depuis la clôture. Ce scénario est banal, et il illustre un paradoxe tenace de la gestion de projet.
Le registre des leçons apprises est l’un des livrables les plus universels. Le PMBOK en fait un processus formel depuis sa sixième édition, PRINCE2 l’intègre dans ses rapports de fin de projet, HERMES le prévoit dans ses documents de clôture. Pourtant, des études menées par le PMI sur des projets dans plus de quarante pays aboutissent au même constat: les leçons apprises sont systématiquement documentées et presque jamais redistribuées aux projets suivants.
Le PMI désigne ce phénomène sous le terme de “project amnesia”: à la clôture d’un projet, les membres de l’équipe retournent à leurs postes fonctionnels et les connaissances acquises se dispersent. Le registre existe quelque part sur un serveur, mais le chef de projet suivant ne le consultera probablement pas. Les mêmes erreurs se reproduisent d’un projet à l’autre, parfois au sein de la même organisation.
Le problème du bilan de clôture
La pratique dominante consiste à capturer les leçons apprises à la fin du projet, lors d’un post-mortem (la réunion de bilan réalisée après la clôture du projet) ou d’un atelier dédié. Cette approche pose plusieurs problèmes fondamentaux.
Le plus évident est un biais de mémoire. À la fin d’un projet de douze mois, les participants se souviennent des événements récents et des crises majeures, mais oublient les difficultés quotidiennes de la phase d’exécution. Les leçons les plus utiles, celles qui concernent les processus, les interfaces entre équipes ou les décisions de conception prises trop tard, sont diluées par le temps.
Un autre biais, rarement discuté, est le biais de survie. Les projets qui arrivent à la clôture sont ceux qui ont réussi, au moins partiellement. Les projets arrêtés en cours de route font rarement l’objet d’un retour d’expérience structuré, alors que ce sont précisément ceux dont les leçons seraient les plus précieuses.
Il y a enfin un problème de format. Un document de synthèse de vingt pages produit en fin de projet ne correspond pas à la manière dont les chefs de projet cherchent de l’information. Lorsqu’un praticien rencontre un problème spécifique, il a besoin d’une réponse ciblée, pas d’un rapport exhaustif qu’il faudrait parcourir intégralement pour trouver le paragraphe pertinent.
Capturer en continu plutôt qu’en bloc
L’alternative au post-mortem est la capture continue. Le PMBOK 6e édition a formalisé cette idée en créant le processus “Manage Project Knowledge”, qui distingue deux formes de connaissances: la connaissance explicite, qui peut être écrite et transmise dans un document, et la connaissance tacite, qui réside dans l’expérience des individus et se transmet par l’interaction directe.
En pratique, la capture continue signifie intégrer un moment de retour d’expérience dans les rituels existants du projet. Un bilan de cinq minutes à la fin de chaque comité de pilotage, une question systématique dans les réunions d’équipe hebdomadaires (“qu’est-ce qui a bien fonctionné cette semaine, et qu’est-ce qu’on ferait différemment?”), un champ dédié dans le compte rendu de chaque revue de phase. Ces micro-captures produisent des leçons plus précises et plus exploitables qu’un atelier de clôture, parce qu’elles sont formulées quand le contexte est encore frais.
Rendre les leçons trouvables
La capture n’est que la moitié du problème. L’autre moitié, souvent négligée, est la redistribution. Un registre centralisé dans un fichier Excel ou un wiki ne sera consulté que si quelqu’un sait qu’il existe et prend le temps d’y chercher l’information pertinente. La NASA elle-même, malgré un système dédié de capitalisation (le Lessons Learned Information System), a dû repenser plusieurs fois ses mécanismes de partage pour que les ingénieurs consultent réellement les retours d’expérience des missions précédentes. Si une agence spatiale peine à faire circuler ses leçons apprises, il est raisonnable d’admettre que le problème n’est pas propre aux organisations moins matures.
Plusieurs approches améliorent la redistribution sans exiger un changement culturel radical. Indexer les leçons par type de projet, par phase et par thématique plutôt que par projet d’origine permet à un chef de projet qui démarre une phase d’appel d’offres de trouver les leçons pertinentes sans parcourir les registres complets de dix projets différents. Intégrer les leçons directement dans les modèles de documents est encore plus efficace: si le modèle de plan de gestion des risques de l’organisation inclut un encart rappelant les trois principaux risques identifiés dans les projets similaires, la leçon arrive au praticien sans qu’il ait à la chercher.
Dans tous les cas, le format court est déterminant. Une leçon apprise efficace tient en trois éléments: la situation rencontrée, l’action prise ou omise et la recommandation pour les projets futurs. Ce format permet une lecture rapide et une recherche par mots-clés, ce qui le rend compatible avec la réalité du travail quotidien.
La connaissance tacite ne se documente pas
Le PMBOK a raison de distinguer connaissance explicite et connaissance tacite, mais les organisations tirent rarement les conséquences de cette distinction. Une partie significative de ce qui fait le succès ou l’échec d’un projet réside dans les relations entre parties prenantes, dans la capacité d’un chef de projet à percevoir quand un fournisseur est en difficulté, dans les négociations informelles qui précèdent les décisions formelles. Ces connaissances ne se capturent pas dans un registre.
Les mécanismes qui fonctionnent pour transmettre la connaissance tacite sont le mentorat, le binômage entre un chef de projet expérimenté et un nouveau, la participation d’anciens membres d’équipe aux revues de lancement des projets suivants. Ces pratiques demandent du temps et une volonté organisationnelle de les soutenir, mais elles transmettent précisément ce que les documents ne peuvent pas contenir.