À la fin de chaque projet, la plupart des méthodologies prescrivent le même exercice: réunir l’équipe, identifier ce qui a fonctionné et ce qui n’a pas fonctionné, consigner le tout dans un registre des leçons apprises (lessons learned). Ce document est censé servir de mémoire organisationnelle pour les projets futurs, éviter la répétition des mêmes erreurs et capitaliser sur les bonnes pratiques.
Dans les faits, ce registre est rarement consulté. Les mêmes erreurs se reproduisent d’un projet à l’autre, les mêmes risques surprennent des équipes différentes et les bonnes pratiques restent confinées dans la mémoire de ceux qui les ont développées. Le problème ne vient pas d’un manque de volonté, mais d’un processus qui échoue à plusieurs niveaux.
Pourquoi les leçons apprises restent lettre morte
Un exercice relégué en fin de parcours
Le registre des leçons apprises est presque toujours traité comme une activité de clôture. L’équipe se réunit une dernière fois, souvent sous pression pour libérer les ressources vers le projet suivant, et produit un document en quelques heures. Ce timing pose un problème fondamental: à ce stade, les détails sont flous, les participants sont déjà mentalement engagés ailleurs et la motivation pour un travail rétrospectif rigoureux est au plus bas.
Le résultat est un document superficiel, rempli d’observations génériques du type “améliorer la communication” ou “mieux définir le périmètre” sans préciser les circonstances, les causes profondes ni les actions correctives concrètes. Ce phénomène est l’un des principaux obstacles à l’efficacité du processus: des leçons trop vagues pour être exploitables par une autre équipe.
La réticence à documenter les échecs
Un registre de leçons apprises utile doit inclure les échecs, les erreurs de jugement et les décisions qui se sont révélées inadéquates. Or, dans beaucoup d’organisations, cette transparence se heurte à la culture interne. Les membres de l’équipe hésitent à mettre par écrit ce qui pourrait être perçu comme une critique de leurs collègues ou de leur hiérarchie, et les chefs de projet préfèrent parfois ne pas officialiser des défaillances qui pourraient compromettre leur évaluation.
Cette autocensure vide le registre de sa substance. Les leçons réellement instructives, celles qui portent sur des erreurs significatives et leurs conséquences, sont édulcorées ou omises au profit d’observations consensuelles qui n’apportent rien.
L’absence de mécanisme de réutilisation
Même quand le registre est correctement rempli, il manque souvent un processus pour injecter ces connaissances dans les projets suivants. Le document est archivé dans un répertoire partagé, mais aucune étape de la planification du prochain projet ne prévoit sa consultation. Le chef de projet qui démarre une nouvelle initiative n’a ni le temps ni le réflexe de parcourir les leçons apprises de projets antérieurs, surtout s’il n’y a pas participé.
Le PMBOK (Project Management Body of Knowledge), dans sa sixième édition, a tenté de répondre à ce problème en formalisant le processus “Manage Project Knowledge”, qui distingue explicitement les connaissances tacites (l’expérience individuelle des praticiens) des connaissances explicites (les documents formels). L’enjeu n’est pas seulement d’écrire un registre, mais de créer les conditions pour que l’information circule d’un projet à l’autre.
Construire un processus de retour d’expérience qui fonctionne
Collecter en continu plutôt qu’en fin de projet
La première correction consiste à abandonner le modèle du registre unique rédigé à la clôture. Un processus de retour d’expérience efficace collecte les leçons au fil du projet, quand les événements sont encore frais et que l’équipe est en mesure de fournir des détails précis.
Concrètement, cela peut prendre la forme d’un point de cinq minutes à la fin de chaque revue de jalon, ou d’une question systématique lors des réunions de suivi: “qu’avons-nous appris cette semaine que nous devrions documenter?” L’objectif n’est pas de produire un document exhaustif à chaque itération, mais d’accumuler progressivement des observations contextualisées qui formeront, à la clôture, un registre riche et exploitable.
Structurer les leçons pour qu’elles soient exploitables
Une leçon apprise utile n’est pas une observation générale. Elle doit suivre une structure minimale: le contexte dans lequel l’événement s’est produit, ce qui s’est passé, pourquoi cela s’est passé et ce que l’équipe recommande pour la prochaine fois. Sans cette structure, le registre devient une liste de platitudes que personne ne peut traduire en action.
Le framework Diátaxis, conçu pour la documentation technique, propose une distinction utile entre quatre types de contenu: tutoriels, guides pratiques, référence et explication. Appliquée aux leçons apprises, cette grille rappelle qu’un registre efficace doit contenir à la fois des faits (que s’est-il passé) et des recommandations opérationnelles (que faire différemment), pas uniquement l’un ou l’autre.
Créer un pont entre les projets
Le registre ne sert à rien s’il n’est pas consulté. L’étape la plus souvent négligée est la création d’un mécanisme formel qui oblige à exploiter les leçons antérieures. Plusieurs approches ont fait leurs preuves: intégrer la revue des leçons apprises pertinentes dans la checklist de lancement de tout nouveau projet, organiser un atelier de transfert quand un projet similaire démarre ou encore désigner un “gardien des connaissances” au sein du PMO (Project Management Office, le bureau de gestion de projets) chargé de faire le lien entre les registres existants et les équipes en planification.
Atlassian souligne que cette circulation des connaissances ne repose pas uniquement sur des documents: les échanges directs entre praticiens, la rotation des équipes et le mentorat jouent un rôle complémentaire essentiel. Le registre des leçons apprises est un support, pas un substitut à la conversation.