La plupart des équipes organisent la même rétrospective, quel que soit le sujet sur lequel elles travaillent réellement. Deux semaines après le début de la recherche, ils se demandent « ce qui a bien fonctionné et ce qui n'a pas fonctionné ». Trois jours après un lancement, même format. En mode itération optimisant la conversion, mêmes questions.
C'est une occasion manquée. Le travail que vous effectuez en découverte est fondamentalement différent du travail que vous effectuez lors d’un lancement. Les risques sont différents, les modes de défaillance sont différents et les questions qui méritent d’être posées sont différentes. Vos rétrospectives devraient refléter cela.
Voici comment adapter votre format de rétrospective à chaque étape du développement du produit afin de réellement faire ressortir les informations qui comptent.
Pourquoi un format ne convient pas à tous
Le travail d'une rétrospective est de vous aider à améliorer le travail que vous faites actuellement. Lors de la découverte, « le travail » s'apprend vite. Lors de la construction, c'est la qualité de l'exécution. Lors du lancement, il s’agit d’une coordination entre les fonctions. Au cours de l’itération, il fait des paris intelligents sur ce qu’il faut conserver, supprimer ou développer.
Lorsque vous utilisez un format rétrospectif générique, vous avez tendance à obtenir des observations génériques. Les équipes discutent par défaut des plaintes liées au processus (les stand-ups sont trop longs, Jira est compliqué) au lieu d'examiner les questions plus profondes spécifiques à leur étape actuelle. En adaptant votre format, vous orientez la conversation vers ce qui nécessite réellement votre attention.
Étape 1 : Découverte – Optimiser pour la vitesse d'apprentissage
Pendant la découverte, votre équipe mène des expériences, discute avec les clients et teste des hypothèses. Le plus grand risque n’est pas que vous construisiez quelque chose lentement ; c'est que vous construisez une chose complètement fausse.
Format rétrospectif : Hypothèse / Test / Apprentissage / Action suivante
Cette structure à quatre colonnes oblige l'équipe à articuler ce qu'elle suppose, comment elle l'a testé, ce qu'elle a réellement appris et ce qu'elle fera ensuite. Cela maintient la conversation fondée sur des preuves plutôt que sur des opinions.
Questions à poser :
- Quelles hypothèses avons-nous validé ou invalidé ce cycle ?
- Où avons-nous consacré du temps à des recherches qui n’ont pas produit de signal clair ?
- Parlons-nous aux bonnes personnes ou sommes-nous coincés dans un segment confortable ?
- À quelle vitesse passons-nous de la question à la réponse ?
À surveiller :
Si votre équipe ne peut pas énoncer clairement ce qu’elle a appris au cours des deux dernières semaines, quelque chose ne va pas. Soit la recherche est floue, soit les expériences sont trop lentes, soit les connaissances se perdent entre les membres de l’équipe. La rétrospective devrait faire ressortir lequel de ces éléments constitue le goulot d’étranglement.
Autre schéma courant : des équipes qui continuent de « valider » sans jamais tuer une idée. Si chaque hypothèse est confirmée, vous posez probablement des questions suggestives ou interprétez des données ambiguës de manière trop généreuse. Un processus de découverte sain invalide régulièrement les hypothèses.
Étape 2 : Construire – Équilibrer vitesse et qualité
Une fois que vous êtes convaincu de ce qu’il faut construire, le travail passe à l’exécution. Désormais, les risques sont liés à une dérive du périmètre, à des exigences peu claires, à des problèmes d'intégration et à la lente accumulation de raccourcis qui créent des problèmes ultérieurement.
Format rétrospectif : Livré / Bloqué / Retravaillé / Collaboration
Ce format se concentre sur la santé de l’exécution. « Livré » célèbre le progrès. Surfaces « bloquées » par des obstacles systémiques. « Rework » suit les endroits où l'équipe a dû refaire le travail (un indicateur avancé des problèmes de processus). La « Collaboration » examine dans quelle mesure différentes fonctions fonctionnent ensemble.
Questions à poser :
- Où les exigences ont-elles changé après le début du développement, et pourquoi ?
- Quelle refonte a eu lieu lors de ce sprint et quelle en est la cause ?
- Y a-t-il eu des décisions que nous avons dû attendre et qui nous ont ralentis ?
- La portée est-elle toujours alignée sur ce que nous avons appris lors de la découverte ?
À surveiller :
La phase de construction est celle où les équipes perdent le plus souvent le lien avec le « pourquoi » derrière ce qu’elles construisent. Les rétrospectives doivent vérifier périodiquement si l'équipe a toujours une vision claire du problème qu'elle résout, et pas seulement des fonctionnalités qu'elle propose.
Faites attention aux modèles de retouche. Si les mêmes types de problèmes continuent de provoquer des retouches (critères d'acceptation peu clairs, cas extrêmes manquants, inadéquations entre la conception et le code), vos actions rétrospectives doivent cibler la cause première plutôt que de simplement noter à nouveau le symptôme.
Étape 3 : lancement – coordonner les fonctions
Le lancement est un défi de coordination. L'ingénierie, les produits, la conception, le marketing, les ventes et le support doivent tous exécuter leurs pièces dans l'ordre. Le plus gros risque n’est pas un bug dans le code ; c'est un écart entre les fonctions où quelque chose passe à travers.
Format rétrospectif : Planifié / Réel / Écart / Prochaine fois
Ce format est volontairement comparatif. Vous exposez le plan, ce qui s'est réellement passé, où se trouvaient les lacunes et ce que vous changeriez pour le prochain lancement. Cela fonctionne bien car les lancements sont suffisamment concrets pour que vous puissiez être précis sur ce qui s’écarte du plan.
Questions à poser :
- Où le plan a-t-il échoué et s’agit-il d’un échec de planification ou d’un échec d’exécution ?
- Quels transferts interfonctionnels se sont déroulés sans problème et lesquels ne se sont pas déroulés sans problème ?
- Les clients ont-ils réagi comme nous l’espérions ? Qu'est-ce qui nous a surpris ?
- Qu’avons-nous appris au cours de la première semaine que nous aurions aimé savoir plus tôt ?
Quand l'exécuter :
N'attendez pas trop longtemps. Organisez une rétrospective rapide dans la semaine suivant le lancement pendant que les détails sont frais. S'il s'agit d'un lancement important, exécutez-en un deuxième au bout de 30 jours une fois que vous disposez de données d'utilisation réelles. Le premier rétro détecte les problèmes de coordination. La seconde capte les signaux d’adéquation produit-marché.
À surveiller :
Les rétrospectives de lancement sont souvent blâmées lorsque les choses tournent mal. Donnez le ton dès le début : l’objectif est d’améliorer le processus de lancement, pas d’identifier qui a laissé tomber la balle. Considérez les lacunes comme des défaillances du système et non comme des défaillances individuelles. "Notre processus n'incluait pas d'étape pour X" est plus utile que "La personne Y a oublié de faire X".
Étape 4 : Itérer – Décider de ce qui mérite plus d'investissement
Après le lancement, vous surveillez les données d’utilisation et décidez où investir davantage. Certaines fonctionnalités prendront leur envol et mériteront d’être agrandies. D’autres seront sous-performants et devront être repensés ou supprimés. Le plus grand risque dans cette phase est l’erreur du coût irrécupérable : continuer à investir dans quelque chose simplement parce que vous l’avez déjà construit.
Format rétrospectif : Travailler / Ne pas travailler / Doubler / Lâcher prise
Ce format impose des décisions explicites de priorisation. « Fonctionne » et « Ne fonctionne pas » sont basés sur des données d'utilisation réelles et des commentaires, et non sur des intuitions. "Double Down" et "Let Go" traduisent les observations en décisions d'allocation de ressources.
Questions à poser :
- Quelles fonctionnalités les clients utilisent-ils réellement et lesquelles ignorent-ils ?
- Où investissons-nous des efforts qui ne produisent pas de résultats proportionnés ?
- Quels signaux nous diraient qu’il est temps d’arrêter d’itérer et de passer à autre chose ?
- Sommes-nous en train d’itérer vers un maximum local, ou y a-t-il une opportunité plus importante qui nous manque ?
À surveiller :
Les équipes résistent souvent à la colonne « Lâcher prise ». Il existe un attachement émotionnel aux fonctionnalités sur lesquelles ils ont travaillé dur. Le facilitateur doit normaliser la temporisation comme un élément sain du développement de produits et non comme un échec. Chaque fonctionnalité que vous conservez entraîne un coût de maintenance continu. Être honnête sur ce qui ne fonctionne pas libère de la capacité pour les choses qui fonctionnent.
Organiser des rétrospectives spécifiques à une étape en pratique
Vous n’avez pas besoin de construire un système élaboré autour de cela. Voici les étapes pratiques :
1. Nommez votre étape actuelle. Au début de chaque rétrospective, indiquez explicitement à quelle étape se trouve l'équipe. Cela semble évident, mais de nombreuses équipes ne le font jamais, et cela recadre toute la conversation.
2. Choisissez le bon format. Utilisez les formats ci-dessus comme points de départ et ajustez-les à votre contexte. Les noms de colonnes spécifiques importent moins que le fait que le format attire l'attention sur les bonnes questions pour votre étape actuelle.
3. Faites une transition délibérément. Lorsque vous passez d'une étape à une autre (par exemple, de la découverte à la construction), exécutez une « transition rétro » qui revient sur l'étape précédente et définit les attentes pour la suivante. C’est le moment naturel de se réaligner sur les objectifs et les indicateurs de réussite.
4. Gardez les éléments d'action adaptés à l'étape. Un élément d'action de découverte doit viser à améliorer la façon dont vous apprenez. Un élément d'action de construction doit viser à améliorer la façon dont vous exécutez. Si vos actions ne correspondent pas à votre étape, le format rétrospectif ne fait pas son travail.
5. Passez en revue toutes les étapes lors des jalons. Après un cycle complet depuis la découverte jusqu'à l'itération, exécutez une méta-rétrospective qui examine le fonctionnement du processus global. C'est là que vous améliorez votre processus de développement de produits lui-même, et pas seulement le travail en une seule étape.
Erreurs courantes à éviter
Utilisation des métriques de construction pendant la découverte. La vitesse et les points d'histoire ne sont pas pertinents lorsque l'objectif est l'apprentissage. Mesurer la découverte en fonction de la vitesse de livraison encourage la construction prématurée.
Sauter la rétrospective de lancement. Les équipes sont souvent épuisées après un lancement et sautent la rétrospective. C’est exactement à ce moment-là que le rétro prend toute sa valeur, car les problèmes de coordination sont nouveaux et spécifiques.
Traiter l'itération comme infinie. Chaque cycle d'itération doit avoir un point de décision clair : développer, maintenir ou cesser. Si vos rétrospectives au cours de l'itération ne produisent jamais de décision de « lâcher prise », vous n'êtes probablement pas honnête quant à ce que les données vous disent.
Ne pas impliquer les bonnes personnes. Les rétros découvertes ont besoin de chercheurs et de concepteurs au premier plan. Les rétros de lancement ont besoin de marketing et de soutien. Invitez les personnes qui effectuent réellement le travail pour cette étape.
Essayez NextRetro gratuitement — Configurez des tableaux de rétrospective spécifiques à une étape en quelques minutes avec des colonnes personnalisables et des modèles intégrés.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
