Tu viens de recevoir une invitation : “Lessons Learned - Projet XXX”. Dans ta tête une petite voix te souffle “Ho non, pas encore !”.
Le Project Manager a invité tout le monde, et quand je dis tout le monde, c’est vraiment du directeur principal au gars du service desk.
Personne ne se présente.
Le PM replanifie. Même invitation, nouvelle date. Cette fois il ajoute un rappel. Avec une note polie dans le corps du message : "Votre participation est importante pour l'amélioration continue de nos pratiques.". Il a même mis le lien vers le documents pour que les personnes le remplissent à l’avance.
Heure dite, la réunion commence, hormis le fait que seul une personne sur trois se présente, quand le PM ouvre le dit document : horreur, il est vide. “Pas grave, on va le faire live !”. Silence sur l’appel.
On y est forcément tous passé, la session de lessons learned post déploiement. Tu sais quand on te fait remplir un beau document excel qui liste ce qui aurait pu aller mieux, comment on aurait du faire ceci ou cela. Alors, les premières fois qu’on y est exposé, on le fait consciencieusement, on s’applique, on réflechit.
Une fois…. Deux fois…. Peut être 3 fois…. Mais un jour, tu ouvres les yeux en te demandant à quoi ça peut bien servir … Tu y as mis tes commentaires, souvent les mêmes. Mais rien ne change. On refait encore et encore pareil.
Le lessons learned est l’un des rituels les mieux entretenus du monde corporatif TI. Il a une structure, une cadence, parfois même un facilitateur désigné. Il produit un livrable : un document, souvent un Excel, parfois un Confluence, qui recense avec soin tout ce qui aurait dû être fait autrement.
Ce document va quelque part. Dans un dossier de projet. Sur un SharePoint. Dans les archives de la PMO.
Et il n’en ressort jamais.
Ce n’est pas une exagération. C’est une réalité documentée dans à peu près toutes les organisations TI d’une certaine taille. Les études sur la gestion de projet le confirment depuis des décennies : la majorité des leçons apprises ne sont ni consultées ni intégrées dans les projets suivants. On documente. On archive. On recommence.
Einstein, ou quelqu’un d’assez lucide pour que personne ne veuille signer, a dit que la folie, c’est de faire toujours la même chose en attendant des résultats différents. Dans nos départements TI, on a institutionnalisé cette folie. On lui a donné un nom propre, une case dans le calendrier de projet, et un template standardisé.
Le taux de présence au premier meeting, lui, dit tout ce qu’on a besoin de savoir sur la valeur réelle que l’organisation accorde à l’exercice.
Le diagnostic
Pourquoi est-ce qu’on continue de faire cet exercice si tout le monde sait, au fond, qu’il ne changera rien ?
Parce que chacun des quatre acteurs dans la pièce a une bonne raison de maintenir l’illusion.
Le système
La direction, la PMO, le cadre méthodologique , ne commande pas l’exercice pour apprendre. Il le commande pour prouver qu’il apprend. Ce n’est pas la même chose.
Un audit, une certification, un rapport de gouvernance : tous demandent des preuves de rétrospective. Le Excel existe pour cocher cette case. Que personne ne le relise ensuite n’est pas un bug. C’est une fonctionnalité. Le système se protège de la critique sans se soumettre au changement.
Le PM
Lui, n’a pas choisi cet étau.
Il a une méthodologie à respecter, un livrable à produire, et une équipe qui vote avec ses absences. Alors il replanifie. Il envoie des rappels polis. Il court après les gens pour qu’ils viennent remplir un document que personne ne relira — parce que son rôle, c’est exactement ça. Et parce que personne ne lui a jamais dit officiellement que l’exercice ne sert à rien. Au contraire.
Ce n’est pas de la mauvaise foi. C’est de l’obéissance à un système qui ne lui a jamais donné les moyens de faire autrement.
Le gestionnaire qui anime la séance porte quelque chose qu’il ne nommera jamais à voix haute.
Il sait. Il sait que les commentaires de son équipe vont pointer des problèmes structurels qu’il n’a pas le pouvoir de régler. Des décisions prises en haut. Des contraintes budgétaires imposées. Des délais irréalistes qui viennent d’encore plus haut.
Alors il facilite. Il hoche la tête. Il note tout dans le Excel.
Et il referme le fichier avec le soulagement silencieux de quelqu’un qui vient de traverser une zone de turbulences sans que l’avion tombe.
L’équipe
Elle, a simplement appris.
Les premières fois, elle y met du vrai. Elle nomme les vrais problèmes, propose de vraies solutions, croit sincèrement que quelque chose va changer.
Mais l’organisation a une mémoire courte et une inertie longue.
Alors l’équipe s’adapte. Elle remplit le Excel avec les mêmes commentaires que la dernière fois, dans des mots légèrement différents, avec l’énergie de quelqu’un qui sait déjà que ça ne mènera nulle part.
Ce n’est pas de la mauvaise volonté.
C’est de l’apprentissage organisationnel inversé : l’équipe a appris que ses leçons ne seront pas apprises.
Le miroir
La dernière fois que tu as rempli un lessons learned, est-ce que tu as écrit ce que tu pensais vraiment ? Ou est-ce que tu as écrit ce qui était acceptable d’écrire dans ce contexte, avec ces gens dans la salle, sous ce gestionnaire-là ?
Et si t’as écrit la version acceptable :
Qu’est-ce que t’as fait de la version vraie ?
Ce que tu peux faire dès lundi matin
Le lessons learned tel qu’il existe dans la plupart des organisations est un exercice mort.
Mais le besoin qu’il est censé combler, lui, est bien réel. Une équipe qui ne réfléchit pas à ses patterns répète ses erreurs. Le problème n’est pas le concept. C’est le format, le timing, et l’absence totale de boucle de rétroaction.
Trois choses concrètes à changer. Maintenant.
1. Change le moment
Un lessons learned organisé trois semaines après la mise en prod, quand tout le monde est passé à autre chose, ne capte rien d’utile.
Les vraies observations émergent dans les 48 à 72 heures suivant un événement significatif — une panne, une livraison difficile, une décision qui a coûté cher. Si tu attends la fin de projet, tu récoltes des souvenirs édulcorés et des diplomaties.
Si tu veux du vrai, fais-le pendant que ça brûle encore un peu.
2. Change la question
“Ce qui aurait pu être mieux” est une invitation à la vague.
Remplace-la par des questions qui ont des vraies réponses :
“Quelle décision, si on l’avait prise 48 heures plus tôt, aurait changé le résultat ?”
“Quel signal on a ignoré et qu’on aurait dû prendre au sérieux ?”
Ces questions ont des réponses concrètes. “Ce qui aurait pu être mieux” a des réponses confortables.
Ce n’est pas la même chose.
3. Crée une boucle visible
C’est la plus importante, et la plus négligée.
Si les leçons apprises ne sont jamais réinjectées dans le projet suivant, l’exercice est mort à la naissance. Quelqu’un doit être responsable de relire les points les plus critiques du dernier lessons learned au kick-off du projet suivant.
Une phrase suffit :
“La dernière fois qu’on a fait un déploiement similaire, voici ce qui nous a coûté cher. Est-ce qu’on a prévu quelque chose pour que ça n’arrive pas encore ?”
Trente secondes. Au kick-off. Avant que tout le monde soit déjà dans l’exécution.
Et si tu n’as pas le pouvoir de changer le format officiel ?
Tu peux quand même faire ça en parallèle avec ton équipe. Une rétrospective informelle, 30 minutes, sans Excel, sans template, avec les bonnes questions.
Ce qui compte, ce n’est pas le livrable. C’est la conversation.
Et si tu es dans l’équipe, pas gestionnaire, pas PM, tu as quand même un levier.
La prochaine fois qu’on t’invite à remplir un Excel vide, tu peux poser la question à voix haute :
“Est-ce qu’on a regardé ce qu’on avait écrit la dernière fois avant de commencer celle-ci ?”
Pas pour provoquer.
Pour voir ce qui se passe quand quelqu’un brise le rituel.
Si tu veux arrêter de documenter pour archiver et que tu veux ma méthode concrète, le Protocole Rétro Vivante, pour transformer tes rétrospectives en levier de changement réel, ça se passe en version Premium. On arrête de philosopher. On passe au déploiement.
Quelque part sur un SharePoint de ton organisation, il y a un document Excel qui contient exactement ce qu’il faudrait faire différemment la prochaine fois.
Il attend là depuis le dernier projet.
Le prochain kick-off, c’est lundi.