La rétrospective est une réunion structurée au cours de laquelle une équipe projet examine collectivement ce qui a fonctionné, ce qui a posé problème et ce qui pourrait être amélioré. Issue des pratiques agiles, notamment du framework Scrum, elle s’applique en réalité à tout type de projet, quelle que soit la méthodologie employée: son principe fondateur est simple et universel, à savoir prendre le temps d’apprendre de l’expérience récente pour ajuster le fonctionnement de l’équipe.
Encore faut-il savoir la conduire. Une rétrospective mal préparée se transforme vite en séance de plaintes sans issue, tandis qu’une session bien structurée produit des améliorations concrètes dès l’itération suivante. Le modèle en cinq phases proposé par Esther Derby et Diana Larsen dans Agile Retrospectives: Making Good Teams Great reste la référence pour structurer cet exercice.
Créer un espace de confiance
La première phase consiste à établir un climat propice à l’échange. Sans sécurité psychologique, les participants retiennent les informations dérangeantes ou se contentent de formules convenues, ce qui rend la session inutile. Le facilitateur peut s’appuyer sur la Prime Directive formulée par Norman Kerth: “Nous comprenons et croyons sincèrement que chacun a fait de son mieux avec les connaissances, les compétences et les ressources disponibles à ce moment-là.” Lire cette déclaration à voix haute en début de session peut sembler formel, mais elle signale clairement que l’objectif est de comprendre, pas de blâmer.
L’activité ESVP offre un bon indicateur de départ: chaque participant indique anonymement s’il se considère comme Explorer (curieux et engagé), Shopper (à l’affût d’au moins une idée utile), Vacationer (présent de corps mais pas d’esprit) ou Prisoner (contraint d’être là). Le résultat, affiché sous forme agrégée, révèle immédiatement le niveau d’engagement réel du groupe et permet au facilitateur d’adapter son approche.
Collecter les données avant d’interpréter
La deuxième phase sépare volontairement la collecte des faits de leur analyse. L’enjeu est d’éviter que les premières interprétations ne filtrent les observations: lorsqu’on demande simultanément “que s’est-il passé?” et “pourquoi?”, l’équipe saute aux conclusions et passe à côté de signaux importants.
Le format Glad, Sad, Mad demande aux participants de répartir leurs observations en trois colonnes: ce qui les a réjouis, attristés ou frustrés. Cette catégorisation émotionnelle, plus fine que le classique “bien/pas bien”, fait émerger des nuances que l’analyse rationnelle seule ne capte pas, notamment la distinction entre un résultat décevant et un processus frustrant.
Pour les équipes plus matures, le Health Check inspiré du modèle Spotify propose une évaluation multicritères de la santé d’équipe sur des dimensions comme l’autonomie, le rythme soutenable ou la qualité technique, ce qui permet de repérer des tendances de fond au fil des rétrospectives successives.
Comprendre les causes profondes
La troisième phase est celle de l’analyse. Il ne suffit pas de constater qu’un livrable a pris du retard: il faut comprendre pourquoi. La technique des 5 Pourquoi (five whys), qui consiste à remonter la chaîne causale en posant successivement la question “pourquoi?” jusqu’à atteindre une cause racine, est particulièrement efficace dans ce contexte.
Une autre approche mérite l’attention: la Celebration Grid développée dans le cadre de Management 3.0 par Jurgen Appelo. Cette matrice croise le type de pratique (standard, expérimentation) avec le résultat obtenu (succès, échec) pour montrer que l’échec d’une expérimentation est plus instructif qu’un succès obtenu par chance. Ce recadrage aide l’équipe à sortir d’une logique punitive où seul le résultat compte.
S’engager sur des actions réalistes
La quatrième phase est souvent celle où les rétrospectives échouent. L’équipe identifie de nombreux problèmes, génère une longue liste d’actions, puis n’en réalise aucune faute de priorisation. La règle d’or est de limiter les engagements à une ou deux actions concrètes par rétrospective, avec pour chacune un responsable nommé, un contenu précis et une échéance. Une action formulée comme “améliorer la communication” ne changera rien; “envoyer un résumé écrit de chaque comité de pilotage dans les 24 heures, responsable: Marie” a une chance d’être appliquée.
Cette discipline exige aussi un suivi: chaque rétrospective devrait commencer par un retour sur les actions décidées lors de la session précédente. Sans ce mécanisme de redevabilité, les engagements perdent leur crédibilité et l’équipe finit par considérer la rétrospective comme un exercice stérile.
Clore et évaluer la session elle-même
La cinquième phase referme la boucle en évaluant la rétrospective elle-même. Le format ROTI (Return On Time Invested, ou retour sur le temps investi) consiste en un vote anonyme de 1 à 5 sur la valeur perçue de la session. Un score en baisse sur plusieurs sessions consécutives est un signal d’alerte: il indique généralement que le format est devenu prévisible ou que les actions décidées ne sont pas suivies.
Ce point soulève une recommandation pratique importante: varier les formats d’une rétrospective à l’autre, non par goût de la nouveauté, mais pour éviter la retro fatigue (lassitude générée par la répétition du même format de session) qui s’installe lorsque l’équipe répète mécaniquement le même exercice. Les ressources d’Atlassian sur les rétrospectives proposent des variantes utiles à intégrer progressivement dans sa pratique.
Qui devrait faciliter?
Un dernier point mérite d’être soulevé: le rôle du facilitateur. Le chef de projet ne devrait pas animer sa propre rétrospective lorsque les sujets abordés concernent directement son management ou ses décisions. La présence d’un facilitateur neutre, qu’il s’agisse d’un Scrum Master (rôle dédié à la facilitation dans le framework Scrum), d’un collègue d’une autre équipe ou d’un coach, permet aux participants de s’exprimer plus librement et garantit que la discussion reste orientée vers l’amélioration plutôt que vers la justification.