Comment mener une rétrospective efficace et appliquer les leçons apprises aux projets futurs

Lisez la transcription :

Nous testons la retranscription automatique de nos podcasts via un programme logiciel. Veuillez nous excuser pour d'éventuelles fautes, le robot n'est pas parfait à 100%.

Galen Low : Bonjour à toutes et à tous, merci d'être à l'écoute. Je m'appelle Galen Low et je fais partie de The Digital Project Manager. Nous sommes une communauté de professionnels du numérique ayant pour mission de s'entraider pour gagner en compétences, en confiance et renforcer nos liens, afin d’amplifier la valeur de la gestion de projets numériques dans le monde digitalisé. Si vous souhaitez en savoir plus, rendez-vous sur thedigitalprojectmanager.com.

Aujourd’hui, nous parlons des rétrospectives de projet : comment les mener efficacement et comment faire en sorte que les leçons apprises lors de vos séances de rétro se traduisent réellement en améliorations sur les projets à venir.

J’accueille aujourd’hui Payson Hall, fondateur et consultant principal chez Catalysis Group, qui aide les organisations à tirer des enseignements de leurs échecs projet depuis plus de 30 ans.

Payson, ravi de t’avoir avec nous dans l’émission.

Payson Hall : Salut, content de participer et de rencontrer le public.

Galen Low : Oui, et en fait, tu fais bien de le souligner, car aujourd’hui, nous faisons quelque chose d’un peu différent. Nous sommes en direct avec nos membres qui forment le public, et nous allons répondre aux questions en direct via notre communauté Slack. Michael est aussi avec moi au studio, il prendra quelques questions. On va les intégrer dans la conversation, tout peut arriver. On va mettre de l'ambiance !

Parlons-en. Je pense commencer par une question corsée car on en a discuté et tu as animé des rétrospectives de projet en tant que consultant sur toutes sortes de projets depuis des décennies, y compris des projets logiciels et de grandes intégrations de systèmes. Je voulais te demander : quand tu interviens en tant que consultant externe pour révéler tous les petits secrets du projet, les équipes projet te voient-elles comme un allié ou un ennemi ? Ressentent-elles un mentorat ou vivent-elles cela comme un audit ?

Payson Hall : Normalement, c’est plutôt un échange amical. Je tiens vraiment à faire une distinction, car une partie de mon métier consiste aussi à faire des autopsies projet. Si un projet part complètement à la dérive et que l’on soupçonne que certains savaient et n’ont rien dit, là, c’est vraiment plus proche d’une mission d’audit.

En fait, je travaille avec un auditeur d’État en Californie et j’ai audité des projets informatiques à un milliard de dollars. Et là, en général, il s’agit de fournir de la matière pour que les avocats puissent poursuivre l’intégrateur système. Mais dans la plupart des cas, les rétrospectives sont juste des gens qui disent « Hé, on a terminé ce projet. »

Faisons venir quelqu’un pour animer un retour d’expérience, c’est à cela que sert une rétrospective : regarder en arrière pour identifier ce que nous avons appris, ce que nous avons accompli intelligemment sans forcément s’en rendre compte sur le moment, ce que nous aurions pu faire différemment en y réfléchissant. C’est vraiment une session de gestion des risques qui consiste à regarder dans le rétroviseur. Que puis-je améliorer la prochaine fois ? Qu’ai-je fait d’astucieux et que je veux continuer à faire ?

Galen Low : J’aime beaucoup cette distinction, car certains auditeurs n’ont peut-être pas vécu cette différence, et voient chaque rétrospective comme une autopsie, comme s’ils allaient témoigner devant un tribunal, avec un esprit de recherche de coupables au lieu d’un simple retour d’expérience pour progresser.

Payson Hall : L’une des seules grandes règles d’une rétrospective, et il existe de nombreuses façons de les mener, est que, selon moi, le chef de projet ne devrait jamais animer sa propre rétro, car certains des points d’amélioration concernent justement ce qu’il ou elle a fait. Un bon facilitateur permet d’éviter que cela vire au procès ou que l’on cherche à désigner un coupable. On parle de ce qui s’est passé, quand, et des enseignements, pas « Galen, tu as tout raté », ça ne sert à rien. Les gens deviennent sur la défensive, et cela déraille. Il vaut donc mieux faire intervenir quelqu’un d’externe, ou une personne interne mais neutre et digne de confiance, afin d’éviter la chasse au coupable. Il n’est pas question de laisser du sang sur le parquet à la fin…

Galen Low : En effet, et c’est très intéressant car nous sommes nombreux à écouter pour comprendre comment organiser notre propre rétrospective. Et bien sûr, on en parlera, il y a des conseils et des astuces que tu vas partager. Mais tu confirmes aussi qu’il vaut mieux que ce soit une autre personne qui apporte ce recul et qui évite justement cette dimension de règlement de comptes. Au final, pas de bains de sang, comme tu dis !

Payson Hall : Il s’agit d’un regard neuf, avec d’autres présupposés. Pense aux projets auxquels tu as participé : tu fais des hypothèses sur les causes des difficultés, qui peuvent être bonnes ou mauvaises. Quelqu’un d’externe, sans ces a priori, pourra voir d’autres choses.

Galen Low : J’adore ! C’est ce côté « prendre du recul » et éviter l’effet tunnel lorsque l’on vit le projet depuis 12 à 18 mois. On ne voit plus la forêt derrière les arbres.

Pour donner des repères aux auditeurs, peux-tu expliquer ce qu’est pour toi une rétrospective de projet et pourquoi c’est important d’en faire une ?

Payson Hall : Excellente question. Une rétrospective, c’est se retourner sur le passé. À la fin d’un projet ou d’une phase critique, on souffle et on analyse les leçons à appliquer sur la suite, ou sur un autre projet. Qu’avons-nous fait de malin, parfois sans s’en rendre compte ? Ou ce que l’on referait différemment, « si c’était à refaire, j’aurais aimé faire ça autrement… » Il s’agit vraiment de prendre du recul, replacer les évènements dans leur contexte. Certaines choses sont vraiment imprévisibles, comme la COVID. Je ne vais pas systématiquement prévoir les pandémies, mais si elle a touché ton projet, il y aura des enseignements à en tirer. Parfois, il s’agit de petits détails pratiques, comme commander 14 ordinateurs au lieu de 12 pour anticiper les pannes au déballage : on évite ainsi de gros retards et cela peut s’avérer une décision très rentable. Oui, acheter deux ordinateurs en trop, mais les rendre si non utilisés, cela peut économiser 3 semaines de retard !

Galen Low : J’adore cet exemple, il montre qu’une rétro sert aussi à capitaliser sur des réussites ou des astuces, pas uniquement sur les échecs. Parfois, on oublie ces petites choses qui ont sauvé la mise, comme la salle de réunion de secours ou une clause qui nous protège. Il faut intégrer ces apprentissages dans le processus pour les prochains projets. Ainsi, la rétro peut se faire aussi en cours de projet, pas uniquement à la fin, lors de moments clés.

Payson Hall : C’est effectivement ce qu’apportent les méthodes agiles : une petite rétro à chaque sprint. Sur des projets plus classiques, je faisais ça à chaque jalon, mais l’agilité a permis de l’ancrer comme nouveau réflexe : faire cela plus souvent, avec des temps réduits à chaque fois. Cela permet à l’équipe de mieux s’approprier la démarche.

Galen Low : Ce changement de culture est intéressant ! Beaucoup d’organisations disent vouloir apprendre, mais refusent d’investir dans ce regard en arrière. Elles pensent « On a déjà compris en avançant ». Mais au final, c’est quoi l’investissement pour une rétro efficace, et est-ce rentable ? Si je devais jouer l’avocat du diable…

Payson Hall : C’est une excellente question. Pour toute démarche d’amélioration, il faut que le coût de la rétro ne dépasse pas sa valeur ajoutée. Je te donne un exemple concret. J’ai récemment animé une rétro avec une équipe d’environ 12 personnes, sur un projet interne de 18 mois, respectant les exigences (un peu de retard, acceptable). Aucun avocat impliqué ! L’équipe a consacré 4 à 6h chacune, préparation, réunion, débrief. Facilitateur : 12h. Chef de projet : 8 à 12h. Au total, deux semaines-personnes pour la rétrospective. Sur 18 mois, soit environ 1000 semaines-personnes, cela fait 0,2%. Il suffit donc de trouver un moyen d’économiser ces deux semaines-personnes pour rentabiliser l’exercice. Et cela se fait souvent naturellement (améliorations de process, best practices, disséminées sur les projets futurs). Je n’ai jamais vu une rétro qui ne produise pas des recommandations qui valent largement cet investissement.

Galen Low : Ok, et sur des petits projets ? Si ton projet dure 4 semaines, deux semaines-personnes c’est énorme… Est-ce qu’on fait l’impasse ? On agrége plusieurs petits projets pour une rétro groupée ?

Payson Hall : Non, ça a été une de mes erreurs de jeunesse. Il ne faut pas inviter à une rétro des personnes qui n’étaient pas sur le projet. Pour rester authentiques, les membres d’équipe doivent se sentir à l’aise pour admettre leurs erreurs face à leurs pairs, pas devant des étrangers. On peut ensuite regrouper les leçons entre chefs de projets, mais jamais pour la rétro primaire. Sur des projets courts, oui, on peut tout à fait faire une rétro informelle d’une à deux heures, préparation minimale pour comprendre le contexte et les attentes du chef de projet.

Galen Low : Oui, c’est dans la démarche agile, une rétro à chaque sprint, puis une plus globale si besoin. Ce qui importe, c’est la flexibilité d’adapter la rétro à la taille et la durée du projet pour en maximiser la valeur.

Payson Hall : Exactement. Parfois, rassembler 8 personnes pendant une heure suffit (8h-personnes), avec un peu de préparation et un mini rapport en une page sur les enseignements, c’est rapide et efficace.

Galen Low : Puis il y a le coût d’opportunité : si une heure permet d’identifier l’astuce qui économise 500 000 dollars, c’est du pur gain !

Certains auditeurs travaillent en agence, avec des clients qui refusent de payer pour une rétro – car c’est de l’amélioration interne – et une direction qui n’aime pas les heures non facturables. As-tu déjà vécu ce genre de refus ? Comment convaincre une direction/clients de la valeur des rétrospectives ?

Payson Hall : Poliment, si mon PDG me disait « nous n’avons rien à apprendre pour progresser », je commence à mettre mon CV à jour… Chez IBM, sur des projets à plusieurs millions, le client ne paie rarement ces heures, c’est bien l’organisation qui le fait, pour gagner en satisfaction et en efficacité. Il suffit de peu d’économies pour rentabiliser l’effort ! Un taux jour à 2000 dollars ne signifie pas qu’une séance interne coûte autant… Et puis, « commencez petit », proposez une rétro sur l’heure du déjeuner : les partenaires vous offrent le petit-déj, vous croyez gagner 2h, eux sont contents de vous avoir fait venir plus tôt ! Bref, c’est rentable, la preuve se fera toute seule. Et surtout, partagez les réussites, racontez aux décisionnaires une rétro qui a permis d’économiser du temps, c’est là que l’effet boule de neige démarre.

Galen Low : Démarrer petit et bâtir une preuve, quitte à demander pardon plutôt que permission, c’est une vraie stratégie !

Souvent, le problème est que les dirigeants n’ont pas la preuve de cette valeur… Mais il y a un vrai potentiel d’évoluer si l’on partage les succès, y compris auprès des responsables qui auraient besoin d’être, parfois, mis face à leurs propres responsabilités — allocation de ressources à la dernière minute, économies mal placées… Bref, il faut faire remonter les apprentissages, d’une manière diplomatique, quitte à adapter la version du rapport destinée à la direction.

Payson Hall : Absolument. Il y a différentes versions de rapports pour différents publics. L’objectif est de rester bienveillant ; la plupart des gens font du mieux qu’ils peuvent avec l’information disponible. S’il s’agit de pointer du doigt ce qu’on n’a pas vu venir, l’idée est de trouver comment obtenir l’info plus tôt la prochaine fois - pour progresser sans chercher de coupable.

Galen Low : Justement, plongeons sur le déroulé d’une retro. Imaginons que tout le monde soit partant, quelle est ta méthode type pour animer une rétrospective ?

Payson Hall : Prenons l’exemple d’un projet d’un an avec une équipe de 10-12 personnes. Première étape : entretien avec le chef de projet – gagner sa confiance, expliquer la démarche, garantir qu’aucune surprise ne sera révélée sans qu’il/elle ait pu lire et réagir aux conclusions. C’est primordial pour éviter la défiance ou la dissimulation, qui sont alors plus néfastes encore. Ensuite, je demande tous les documents utiles : définitions, cahier des charges, comptes-rendus, log des changements, rapports de risques et de statuts. Je veux comprendre l’objectif de départ puis les changements, car tout projet évolue. Un regard extérieur peut aider à relativiser, voir ce qui était prévisible ou non et comment anticiper la prochaine fois.

Je passe au crible les rapports de statuts sur la durée du projet : on y lit souvent la montée en puissance de petits soucis, devenus ensuite de gros problèmes. Je bâtis ensuite une première chronologie et liste d’anomalies. Je complète cette vision avec des entretiens pour combler les manques, puis on demande à chaque membre d’équipe de réfléchir à trois types d’événements marquants : heureux/astucieux, incidents/problèmes, anecdotes. On construit ensuite une chronologie murale avec les principaux jalons, puis on enrichit avec les apports de chacun, avant d’identifier les « root cause » des incidents, souvent à travers trois questions : Comment aurait-on pu détecter le problème/opportunité plus tôt ? Pouvait-on en augmenter les chances ou en réduire l’impact ? Souvent, la réponse est non, mais l’exercice est toujours utile. Cela donne la matière du rapport final, qui doit rester succinct et priorisé !

Galen Low : Justement, quand tu as une chronologie avec plein d'évènements, tu privilégies la discussion en profondeur sur chaque point, ou plutôt l’identification/organisation et seulement ensuite une analyse plus ciblée ?

Payson Hall : C’est un arbitrage à faire en direct : laisser assez de temps pour qu’émerge un « aha moment » sans tomber dans une analyse exhaustive et trop chronophage. On priorise et, si besoin, on traite hors séance les cas les plus pointus, pour garder la session dynamique.

Galen Low : C’est là qu’on voit l’intérêt des compétences de facilitation : tous les problèmes du monde ne se résolvent pas dans la rétro, mais on veut pouvoir aborder l’essentiel et ne perdre personne dans la complexité.

Payson Hall : Exactement. Avoir un facilitateur externe ou éloigné du projet aide grandement. En tant qu’ingénieur, la tentation d’entrer dans les détails est forte, il faut rester maître du jeu et se demander à tout moment si on fait progresser le débat.

Galen Low : J’aime bien cette notion de rapport qui reste accessible à tous, pour servir à d’autres équipes/projets. Avoir une vision root cause mais sans tomber dans l’excès d’analyse – on garde plusieurs apprentissages plutôt qu’une seule analyse ultra détaillée, c’est important ! Tu as aussi dit que la rétro, c’est « de la gestion des risques a posteriori », alors que beaucoup associent la gestion des risques uniquement au futur. Tu relis les deux notions ?

Payson Hall : Absolument. L’idée clé est que ce qui compte c’est ce qui a fonctionné ou non, pas « qui » a fonctionné ou non. C’est la mission du facilitateur de s’en assurer. Raconter l’anecdote d’une mauvaise expérience : J’ai voulu assister à une rétro d’équipe (alors que je n’étais pas dans le projet), et le facilitateur a géré cela de façon désastreuse en cherchant des responsables. L’équipe a su ne pas tomber dans ce piège et a refusé de dénoncer l’absent, mais ce n’est pas une discipline généralisable – le facilitateur doit vraiment cadrer vers « qu’avons-nous appris » sans chercher le coupable. On part du principe que chaque personne a fait de son mieux avec ce qu'elle avait à disposition. S’il y a eu une erreur de casting sur les compétences ? C’est souvent plus un problème de staffing du projet, ce qui doit remonter dans la rétro sous l’angle « compétences manquantes » et non « faute de tel ou tel ».

Galen Low : La sécurité psychologique se construit donc en amont, via la relation et le cadrage, et durant la séance, on rappelle régulièrement qu’il ne s’agit pas de pointer du doigt. Concrètement, comment ramènes-tu l’audience sur le bon chemin si la chasse au coupable démarre ?

Payson Hall : Première fois, je recadre gentiment : « ce n’est pas l’objet, on cherche le ‘quoi’ et non le ‘qui’ ». Si cela continue, pause et aparté avec la personne. L’objectif est que le PM et moi puissions discuter entre nous de certains sujets, mais la réunion reste consacrée à l’amélioration collective.

Galen Low : Et sur la question du rapport, comment éviter que le message implicite ne devienne une chasse au sorcier pour la direction qui pourrait lire entre les lignes ?

Payson Hall : S’il y a un problème RH (« pas assez grand pour le manège »), c’est à régler en dehors du rapport. Dans le document, on s’attache à décrire les problèmes process ou staffing général sans désigner de personne. Il vaut toujours mieux des formulations diplomatiques et factuelles : « manque de ressources », « compétences absentes », etc., permettant à l’organisation d’en tirer des leçons sans créer de tensions inutiles.

Galen Low : Ce tact dans la formulation est essentiel. Quand la retro aboutit à un rapport, beaucoup craignent qu’il « prenne la poussière ». Comment s’assurer que ces recommandations aboutissent à des changements concrets ?

Payson Hall : Ne jamais faire de rapport fleuve. Il faut prioriser deux ou trois recommandations majeures à faire remonter à la direction. Le gros du reste, ce sont des axes d’amélioration portés tacitement par chaque participant sur son prochain projet – c’est le principal vecteur, l’apprentissage organique. Les bases de données de leçons globales et contextuelles ? Jamais vu fonctionner. Le vrai changement vient des éléments répétés dans les recommandations qui finissent par percoler et provoquer un déclic. Un war room par projet, par exemple, revient souvent, et à force, la direction finit par l'entendre…

Galen Low : Oui, il y a apprentissage formel (recommandations prioritaires pour la direction) ET apprentissage informel, via l’expérience vécue et partagée. Cela essaime, même de façon invisible…

Payson Hall : Exactement. Et c’est ce qui nourrit la gestion des risques lors de la préparation des futurs projets : ce qu’on a vécu et discuté sera dans tous les esprits lors du repérage des nouveaux risques. On gagne vraiment en maturité collective.

Galen Low : C’est une vraie dynamique de transmission orale, une histoire à raconter, qui nourrit la base de connaissances collective.

Je rebondis : certains évoquent la notion de « prespective », sorte de pré-mortem. Quelle est ta vision de l’articulation entre gestion du risque et rétro, notamment en mode agile où l’on fait des rétros itératives ? Tu sépares la rétro et la gestion du risque ou mélanges-tu tout ?

Payson Hall : Pour moi, les deux sont liés, surtout en mode agile. À chaque rétro, on identifie ce qu’il faudrait améliorer, qui devient une action pour le sprint suivant, c’est une gestion du risque itérative, intégrée, et saine.

Galen Low : Exactement, cela permet de nourrir la réflexion « future » tout en capitalisant sur l’expérience immédiate. Autre question fréquente : parfois, les causes des problèmes sont externes à l’équipe (ressources réaffectées à d’autres priorités). Comment faire remonter ça ?

Payson Hall : Il faut décrire le constat de façon neutre : « Le projet a rencontré des soucis de ressources du fait de réaffectations à des urgences externes. » Puis la recommandation : « Penser à étoffer l’équipe ou obtenir des engagements sur les ressources, avec signalement anticipé d’un éventuel retrait pour pouvoir anticiper et réorganiser. » On ne blâme personne, mais on met en lumière les impacts et des pistes d’amélioration pour l’avenir.

Galen Low : Merci ! Dernière question : sur quoi se concentrer lors d’une rétro, alors que le temps est compté et qu’il y a tant de sujets potentiels ?

Payson Hall : C’est variable, mais l’essentiel est d’avoir une définition claire et partagée avec les parties prenantes. Puis de vérifier un vrai process de gestion du changement : toute demande supplémentaire doit être formalisée et accompagnée de moyens. Beaucoup de problèmes viennent non pas d’une mauvaise estimation, mais d’une dérive de périmètre non portée à l’attention de tous.

Galen Low : Oui, tout est lié. Il s’agit vraiment de comprendre les besoins et points de vue les plus porteurs de valeur pour la discussion.

Je pense qu’on arrive au terme de l’émission. Payson, merci d’avoir partagé ton expérience ! Comment peut-on en savoir plus sur Catalysis Group ?

Payson Hall : Rendez-vous sur catalysisgroup.com, rubrique « resources » – il y a notamment des articles sur la gestion du risque qui donneront de la matière concrète pour vos rétrospectives.

Galen Low : Je recommande vivement, Payson est un excellent journaliste et narrateur, ses articles sont à la fois utiles et réjouissants à lire ! Pour tous ceux qui pensent que les rétrospectives ou la gestion du risque sont ennuyeuses, vous changerez d’avis en lisant ses ressources.

Pour nos auditeurs, j’espère que vous avez retenu de nombreuses idées aujourd’hui – on publiera d’autres questions dans la communauté pour en débattre avec vous.

Payson Hall : Si vous souhaitez me contacter par e-mail pour toute question, n’hésitez pas !

Galen Low : Voilà, chers auditeurs ! Comme toujours, si vous souhaitez rejoindre une communauté de plus d’un millier de champions de la gestion de projet, rendez-vous sur thedigitalprojectmanager.com/membership. Et si l’émission vous a plu, abonnez-vous et suivez-nous sur thedigitalprojectmanager.com.

À la prochaine, et merci de votre écoute.