Une action de rétrospective est une amélioration précise que l'équipe accepte d'essayer après la séance. Une action utile nomme un responsable, décrit le changement, fixe une date de revue et indique la preuve qui montrera si cela a aidé. « Mieux communiquer » est un objectif ; « tester un point blocages à 10 h pendant un sprint » est une action.
Mise à jour du 11 septembre 2026. Ajout de six exemples travaillés, d'un registre d'actions à copier, d'une vérification des résultats et d'un ordre du jour de revue. Les exemples ci-dessous sont illustratifs, ce ne sont pas des résultats clients mesurés.
Pourquoi les actions sont oubliées
Une action peut disparaître parce que personne n'en est responsable, parce qu'il n'y a pas de temps pour la mener, ou parce que l'équipe ne s'accorde jamais sur ce que « terminé » veut dire. Une longue liste entre en concurrence avec le travail de sprint. Un document que personne ne rouvre rend l'engagement invisible.
La solution consiste à rendre l'amélioration assez petite pour être tentée et assez visible pour être revue. Commencez avec une à trois actions : c'est un repère d'animation, pas une limite universelle. Si l'équipe n'a de capacité que pour une seule, n'en gardez qu'une.
Le Guide Scrum indique que la rétrospective de sprint planifie des moyens d'augmenter la qualité et l'efficacité, et que les améliorations les plus utiles devraient être traitées dès que possible. Il n'impose ni règle de trois actions ni outil de suivi particulier.
Comment rédiger une action de rétrospective
Utilisez ce format :
[Responsable] fera [changement précis] d'ici [date]. Nous examinerons [preuve] le [date de revue] et déciderons de garder, d'adapter ou d'arrêter.
Un responsable coordonne le travail et rend compte du résultat. Il n'a pas à tout faire lui-même. Avant d'accepter l'action, vérifiez que cette personne a l'autorité, le temps et le soutien nécessaires.
Rattachez l'action à une observation : ce qui s'est passé, dans quelle situation et pourquoi c'était important. Choisissez ensuite le plus petit changement capable d'y répondre. Évitez d'engager un achat d'outil ou une grande réorganisation quand une courte expérimentation peut tester l'hypothèse sous-jacente.
Six exemples d'actions de rétrospective
| Suggestion vague | Expérimentation vérifiable | Preuve à examiner |
|---|---|---|
| Améliorer les revues de code | Alex coordonne un créneau de revue quotidien de 15 minutes pendant un sprint | Ancienneté des pull requests en attente et interruptions causées par le créneau |
| Signaler les blocages plus tôt | Maria teste un point blocages à 10 h pendant un sprint, avec une personne nommée pour aider sur chaque point bloqué | Quels blocages ont été remontés plus tôt et lesquels ont encore attendu |
| Arrêter la dérive du périmètre | Priya demande au PM de noter chaque ajout en cours de sprint et le travail qu'il repousse | Ajouts avec arbitrage explicite par rapport aux ajouts non planifiés |
| Améliorer les passations d'astreinte | Sam crée une courte check-list de passation d'ici vendredi et la teste sur les deux passations suivantes | Contexte manquant signalé par la personne qui prend le relais |
| Réduire la charge de réunions | Devon suspend une réunion de statut récurrente pendant deux semaines et envoie un compte rendu écrit | Décisions manquées, questions et temps que les participants disent avoir récupéré |
| Rendre les contrôles de release constants | Lee ajoute une étape de vérification du rollback à la prochaine check-list de release | Si la prochaine release a un responsable et une procédure de rollback documentés |
Ce sont des points de départ. Convenez avec votre équipe d'une référence et d'une condition de réussite atteignable. Une évolution sur deux semaines dans une métrique ne prouve pas la causalité : combinez les chiffres avec ce que les gens ont observé.
Modèle d'actions de rétrospective à copier
Copiez ce registre dans un document partagé ou dans votre outil de suivi habituel :
| Problème observé | Expérimentation | Responsable | Échéance | Date de revue | Preuve de réussite | Statut | Décision |
|---|---|---|---|---|---|---|---|
| Les revues attendaient le dernier jour du sprint | Tester un créneau de revue quotidien | Alex | À convenir avant le prochain sprint | Prochaine rétro | Temps d'attente des revues et retours de l'équipe | Prévu | En attente |
| Contexte manquant lors des passations d'astreinte | Tester une check-list de passation en cinq points | Sam | Vendredi | Après deux passations | Éléments de passation manquants | En cours | En attente |
| Ajoutez votre observation | Définissez un petit changement | Nommez une personne | Fixez une date | Fixez une date de revue | Dites comment vous vérifierez | Prévu | En attente |
Les lignes d'exemple utilisent volontairement des dates relatives. Remplacez-les par de vraies dates de calendrier avant de vous engager. Reliez le registre à l'endroit que l'équipe consulte déjà ; entretenir un second backlog invisible annule l'intérêt de l'exercice.
Revoyez les actions précédentes avant de collecter de nouveaux retours
Réservez les cinq premières minutes de la rétro suivante au suivi. C'est une durée indicative : allongez-la quand une expérimentation importante mérite plus de discussion.
- Point du responsable : qu'avons-nous essayé ? Qu'avons-nous renoncé à essayer ?
- Preuve : qu'est-ce qui a changé, et qu'est-ce qui pourrait aussi expliquer ce changement ?
- Décision : garder le changement, l'adapter ou l'arrêter délibérément.
- Étape suivante : si du travail reste à faire, convenez de la capacité, du responsable et d'une nouvelle date de revue.
Utilisez des statuts comme Prévu, En cours, Terminé, Bloqué et Arrêté. Séparez la décision sur le résultat du statut de la tâche : créer une check-list peut être Terminé même si l'expérimentation a montré que la check-list n'aidait pas.
Que faire quand une action est sans cesse reportée
Ne recopiez pas la même phrase en retard dans une nouvelle rétro sans en discuter la raison. Demandez si le travail est trop gros, hors du contrôle du responsable, devenu inutile, ou s'il manque de capacité.
Découpez-le en un test plus petit quand c'est possible. Faites remonter une dépendance à la personne capable de la lever. Arrêtez une action qui n'a plus d'importance et notez pourquoi. Si l'équipe veut toujours le changement, faites-lui de la place au lieu de le traiter comme du travail en plus autour du sprint.
Comment NextRetro s'insère dans le suivi
Menez la collecte, le regroupement, le vote et la discussion sur un tableau de rétrospective gratuit, qui ouvre directement la fenêtre de nom du tableau. Notez l'amélioration retenue et exportez le résultat vers l'outil de travail habituel de l'équipe. Les participants rejoignent la session sans compte, et la page d'accueil permet de créer un tableau en invité.
D'après les tarifs actuels, l'offre gratuite inclut l'historique récent et l'export PDF ou Markdown. L'offre Pro inclut l'historique complet des rétros, les espaces d'équipe et la création du tableau suivant à partir d'une rétro précédente. Choisissez l'option qui rend l'action précédente facile à retrouver ; un registre partagé est un point de départ valable.
Questions fréquentes
Combien d'actions une rétrospective doit-elle produire ?
Commencez par une à trois, selon la capacité. Une seule expérimentation bien portée est un résultat utile. Aucune règle universelle n'impose trois actions, et un nombre plus élevé ne prouve pas que la réunion était meilleure.
Qui est responsable des actions de rétrospective ?
Nommez une personne pour coordonner chaque action. L'équipe peut se partager le travail, mais un responsable nommé rend l'étape suivante et le compte rendu clairs. L'animateur ne devrait pas porter automatiquement chaque amélioration.
Comment mesurer si une action a aidé ?
Décidez de ce que vous observerez avant le début de l'expérimentation. Comparez le résultat à la situation précédente, interrogez les effets secondaires et notez s'il faut garder, adapter ou arrêter le changement. Le simple fait d'avoir terminé la tâche n'établit pas l'amélioration.
Les actions doivent-elles aller dans le backlog de sprint ?
Quand une amélioration demande du travail d'implémentation, discutez-en en planification de sprint et rendez-la visible dans l'outil de l'équipe. Le Guide Scrum autorise l'ajout des améliorations les plus utiles au prochain backlog de sprint ; il n'exige pas que chaque note de rétro devienne un élément de backlog.
Pour lancer la séance, voyez notre guide sans inscription des participants. Si vous évaluez des outils, comparez les limites des offres gratuites et de l'historique avant de décider où vivra le registre des actions.
