Le post-mortem projet qui génère du learning
À jour au 2026-08-16
La plupart des post-mortems SAP analytics produisent un diaporama que personne ne rouvre, car ils sont tenus des semaines trop tard, animés par quelqu'un ayant un intérêt dans le résultat, et structurés en chronologie plutôt qu'en causalité. Ce module donne aux consultants le pattern opérationnel d'un post-mortem qui survit à la séance : le tenir trois à quatre semaines après la mise en production pendant que le journal d'hypercare fait encore foi, garder la facilitation blameless pour que les juniors s'expriment, et pousser chaque constat via les cinq pourquoi jusqu'à une cause profonde nommée. Le chiffre qui compte est le taux de suivi réel — une action corrective sans responsable nommé et sans revue de suivi à trois mois ne se produit jamais. Les consultants capables de montrer qu'un post-mortem a débouché sur une mise à jour de checklist et de template ayant survécu au projet suivant détiennent une accréditation différenciante pour les rôles d'excellence en livraison, valorisée 1 200 à 1 600 € par jour pour les indépendants en EMEA.
Ce que vous apprendrez
- Planifier et structurer un post-mortem blameless pour un projet analytics SAP en utilisant les données d'hypercare comme base empirique, et animer l'analyse des cinq pourquoi sur les catégories de défaillances canoniques (interfaces d'intégration, autorisations, qualité de données, exigences)
- Produire les trois artefacts obligatoires du post-mortem — rapport structuré ancré sur les causes profondes, mises à jour spécifiques de checklists, et revue de responsabilisation de suivi à trois mois — plutôt qu'une liste générique de leçons apprises
- Appliquer les techniques de facilitation blameless pour maintenir la sécurité psychologique dans des groupes de séniorité mixte, incluant la reformulation immédiate du langage de blâme et la protection explicite des participants juniors
- Concevoir un mécanisme de propagation de l'apprentissage au niveau practice (digest trimestriel, intégration à l'onboarding, mises à jour de templates) qui transporte l'apprentissage du post-mortem au-delà de l'équipe projet immédiate vers les engagements futurs
Pourquoi la plupart des post-mortems ne produisent rien d'utile
À la fin d'un projet SAP analytics — une migration BW/4HANA, un déploiement Datasphere, une implémentation SAC Planning — l'équipe se réunit pour la rétrospective. Quelqu'un ouvre un diaporama intitulé « Leçons apprises ». Une heure plus tard, l'équipe a convenu que « la communication aurait pu être meilleure », « les exigences n'étaient pas assez claires » et « les tests ont commencé trop tard ». Ces observations sont techniquement vraies pour presque tout projet jamais conduit. Elles ne produisent aucun apprentissage actionnable. Le diaporama est classé dans un dossier SharePoint où il ne sera plus jamais ouvert. Le prochain projet fait les mêmes erreurs.
Ce schéma n'est pas causé par la paresse de l'équipe ou la mauvaise foi. Il est causé par des défaillances structurelles dans la façon dont les post-mortems sont typiquement conduits : ils sont tenus trop tard, animés par quelqu'un ayant un intérêt dans le résultat, structurés autour de la chronologie plutôt que de la causalité, et ils ne distinguent pas les symptômes des causes profondes. Le résultat est une conversation cathartique qui donne l'impression d'un apprentissage mais ne produit rien qui change le prochain projet.
Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · le contrôle de connaissances · les schémas.