Un bon modèle de retour d’expérience comporte six champs par leçon : ce qui s’est passé, l’impact, la cause racine, un verdict (garder, changer ou arrêter), un responsable, et le modèle ou la checklist qui change en conséquence. La plupart des modèles s’arrêtent aux trois premiers, et c’est pour cela que la plupart des documents de retour d’expérience ne sont jamais relus. Une leçon ne compte que lorsqu’elle a un responsable qui modifie le modèle à partir duquel démarre le projet suivant. Voici le modèle, la séance qui permet de le remplir et l’étape qui le rend durable.
Gardez l’en-tête court : nom du projet, dates, sponsor, participants à la séance et lien vers le dernier rapport d’avancement. Puis une ligne par leçon :
| Champ | Contenu | Exemple |
|---|---|---|
| Ce qui s’est passé | Une phrase factuelle, sans nom | Les validations client ont pris trois semaines au lieu d’une |
| Impact | Délai, coût, qualité ou relation | Lancement décalé de deux semaines |
| Cause racine | La faille du processus, pas la personne | Aucun délai de validation convenu au lancement |
| Verdict | Garder, changer ou arrêter | Changer |
| Responsable | Une personne nommée | Responsable de la delivery |
| Ce qui change | Le modèle, la checklist ou le processus mis à jour | La checklist de lancement reçoit un point « délais de validation » |
Menez la séance avec trois questions, dans cet ordre : que devons-nous continuer à faire, que devons-nous changer, que devons-nous arrêter. « Garder » compte autant que « changer » : c’est ce qui évite de perdre les bonnes pratiques quand l’équipe change.
Invitez les personnes qui ont fait le travail ainsi que le sponsor, et considérez les autres parties prenantes comme des lecteurs du résultat, pas comme des participants. Six à huit personnes suffisent.
À cause de l’endroit où ils sont rangés et de ceux pour qui ils sont écrits.
Le remède au dernier point ne coûte rien : notez au fil de l’eau. Si vous rédigez déjà un rapport d’avancement hebdomadaire, ajoutez-y une ligne : « ce qui nous a surpris cette semaine ». À la clôture, vous triez ces lignes au lieu de partir d’une page blanche.
Appliquez une règle : une leçon sans responsable et sans modèle modifié n’est qu’une anecdote. Chaque verdict « changer » doit nommer précisément ce qui change, et quelqu’un doit le changer avant une date donnée.
C’est ici que les leçons rejoignent vos modèles de projet. Si les nouveaux projets partent d’un modèle, c’est dans le modèle que les leçons doivent atterrir. Un point oublié au lancement devient une nouvelle tâche du modèle. Un risque qui vous a surpris devient une ligne par défaut de la liste des risques. Le chef de projet suivant hérite de la leçon sans jamais avoir à la lire.
Sur monday.com, cela donne ceci :
Cela ne fonctionne que si les projets partent réellement de modèles partagés. Vlerick Business School illustre bien ce socle : les projets sont organisés en portefeuilles et chaque type de projet a son propre modèle, si bien que les équipes montent leurs nouveaux projets à partir d’un cadre prédéfini mais adapté. C’est cette cohérence qui donne à une leçon un endroit où atterrir.
Honnêtement, pour un projet isolé, un document Word suffit. Utilisez le tableau ci-dessus, tenez la séance, désignez des responsables, et vous serez déjà en avance sur la plupart des équipes.
Un registre devient rentable quand vous menez de nombreux projets en parallèle ou à la chaîne et qu’ils partagent des modèles. Des schémas apparaissent alors : le même retard de validation sur quatre projets n’est pas de la malchance, c’est une lacune du modèle. Vous ne le voyez que si les leçons sont centralisées, par catégorie.
Le piège, c’est la responsabilité. Les modèles dérivent : quelqu’un copie un vieux tableau, une leçon est ajoutée à un modèle et pas à l’autre, et au bout d’un an plus personne ne sait quelle version fait foi. Gouverner les modèles et le registre est une mission permanente, pas une tâche de projet. C’est typiquement le genre de travail qui s’intègre bien dans des Managed Services, où un consultant est responsable dans la durée de la structure de votre environnement monday.com.
Pour chaque leçon : ce qui s’est passé, l’impact, la cause racine, un verdict (garder, changer ou arrêter), un responsable, et le modèle ou la checklist qui change en conséquence. Ajoutez un en-tête avec le nom du projet, les dates, le sponsor et les participants.
Dans les deux semaines suivant la clôture, tant que les souvenirs sont frais, et idéalement avec un journal tenu pendant le projet pour que la séance serve à trier, pas à se souvenir. Sur les projets longs, une courte séance à chaque jalon majeur est utile.
Une rétrospective est en général une séance d’équipe récurrente pendant le travail, courante en Scrum. Le retour d’expérience a généralement lieu à la fin d’un projet ou d’une phase et vise à changer la façon dont le projet suivant est monté. Le modèle convient aux deux.
Donnez à chaque leçon un responsable et une échéance, et exigez que chaque leçon « changer » nomme le modèle, la checklist ou le processus qu’elle met à jour. Revoyez ensuite les leçons ouvertes chaque mois jusqu’à leur clôture.
Commencez par appliquer le modèle ci-dessus à votre projet en cours. Si vous menez de nombreux projets similaires et voulez que vos leçons atterrissent dans les modèles que vos équipes utilisent vraiment, nous pouvons examiner votre configuration ensemble. Réservez un appel découverte gratuit avec Tryve.
Tryve est monday.com Platinum Partner. Chaque mission commence par une phase de cadrage structurée, construite autour de vos processus réels, pas d’un modèle générique. Nos consultants seniors restent impliqués jusqu’à l’adoption, pas seulement jusqu’au démarrage. Réservez un appel découverte gratuit.
Tryve est un partenaire platine de monday.com et aide les entreprises à mettre en place des outils de gestion de projet à la pointe de la technologie !
