Pourquoi 2/3 des actions de rétro meurent (et comment y remédier)

Le cimetière des bonnes intentions

Imaginez la scène : c'est l'heure de la rétrospective de sprint. L'équipe se réunit, en personne ou dispersée sur des écrans vidéo. Les notes adhésives fusent. Quelqu'un soulève le goulot de déploiement qui plombe la vélocité. Une autre personne mentionne la suite de tests instable. Une troisième suggère des rotations de pair programming pour partager les connaissances.

À la fin de la session, vous avez une belle liste d'actions :

• « Examiner la parallélisation du CI » — assignée à Sarah
• « Documenter le flux d'authentification » — assigné à Mike
• « Mettre en place un calendrier de rotation pour les revues de code » — assigné au lead de l'équipe

Tout le monde acquiesce. La rétro se termine. Les gens se sentent bien. Des progrès ont été faits.

Deux semaines plus tard, même salle, mêmes visages. Nouvelle rétro. Et personne ne mentionne ce qui est arrivé à ces actions. Parce qu'il ne leur est rien arrivé. Elles sont mortes en silence, quelque part entre le backlog Jira et les bonnes intentions de chacun.

Ça vous dit quelque chose ?

Les chiffres qui dérangent

Voici une statistique qui devrait hanter chaque scrum master : un sondage de la communauté PMI a révélé que près des deux tiers des équipes mettent en œuvre moins de 25 % des idées d'amélioration de leur dernière rétrospective. Aucun répondant n'a déclaré en avoir mis en œuvre plus de 75 %.

Relisez ça. Deux tiers des équipes ne parviennent même pas à exécuter le quart de ce à quoi elles se sont engagées.

Ce n'est pas une inefficacité mineure de processus. C'est une crise de crédibilité massive. Chaque action abandonnée est une petite promesse brisée. Empilez-en suffisamment et vous obtenez la « fatigue des rétrospectives » — cette ambiance cynique et désengagée où les gens cessent de soulever des problèmes parce qu'ils ont appris que rien ne change jamais de toute façon.

La cérémonie continue. L'amélioration, non.

Pourquoi les actions de rétrospective meurent-elles ?

Les actions de rétrospective meurent parce que le système est conçu pour l'échec, pas parce que les gens sont paresseux ou s'en fichent. Rien ne force l'équipe à confronter les anciens engagements, les états « en cours » cachent l'abandon, les actions oubliées disparaissent sans décision, et admettre une promesse brisée est suffisamment inconfortable pour que personne n'en parle. Quatre problèmes, un seul cimetière.

Problème 1 : Aucune fonction contraignante

Les actions traditionnelles vivent dans Jira ou un document partagé ou les notes de quelqu'un. Elles rivalisent avec le vrai travail de sprint pour attirer l'attention. Et devinez qui gagne quand le product owner demande des nouvelles de cette échéance de fonctionnalité ? Pas « examiner la parallélisation du CI ».

Il n'y a aucun moment où l'équipe est forcée de confronter le sort des engagements précédents. La rétro se concentre sur ce qui s'est passé ce sprint, pas sur ce que nous avons promis le sprint dernier.

Problème 2 : Le théâtre du progrès

Beaucoup d'outils vous permettent de marquer les actions comme « en cours » ou « complétées à 50 % » ou n'importe quel pourcentage qui vous fait sentir productif. C'est un piège. Une action qui est « en cours » depuis trois sprints n'est pas en cours. Elle est abandonnée avec des étapes supplémentaires.

Le théâtre du progrès permet aux équipes d'éviter le binaire inconfortable : avons-nous fait ça ou non ?

Problème 3 : L'oubli silencieux

Le sort le plus courant d'une action n'est ni l'achèvement ni la clôture explicite. C'est simplement d'être oubliée. Elle glisse au bas de la liste, remplacée par des engagements plus récents et plus brillants. Personne ne dit « nous n'allons pas faire ça ». Elle cesse simplement... d'exister.

C'est la mort par négligence, et c'est bien plus courant que l'échec explicite.

Problème 4 : Éviter la honte

Soyons réalistes : admettre que vous n'avez pas fait quelque chose à quoi vous vous êtes engagé est inconfortable. La nature humaine est d'éviter cette conversation. Alors nous ne mentionnons pas les anciennes actions. Nous nous concentrons sur les nouveaux problèmes. Le cycle continue.

La solution agaçante mais efficace

Quand nous avons construit le système d'actions dans Simyl Flow, nous l'avons conçu pour être intentionnellement inconfortable. Pas cruel — juste honnête. Voici à quoi ça ressemble :

La vérification de responsabilité

La vérification de responsabilité est une fonction contraignante : vous ne pouvez pas commencer une nouvelle rétrospective sans d'abord traiter vos anciens engagements.

Quand vous ouvrez une nouvelle rétro, avant de voir le tableau, avant que quiconque ajoute une seule carte, un dialogue apparaît. Il montre chaque action ouverte des rétrospectives précédentes. Pour chacune, vous avez exactement trois choix :

1. Marquer comme terminée — Vous l'avez faite. Célébrez. Passez à autre chose.
2. Reporter — Vous ne l'avez pas faite, mais vous voulez toujours le faire. Elle est transférée à cette rétro avec un compteur.
3. Ne pas faire — Vous décidez consciemment de ne pas faire ça. Vous devez expliquer pourquoi.

Pas de quatrième option. Pas de « en cours ». Pas de « parlons-en plus tard ». Vous devez décider.

type ActionDecision = "done" | "carry_forward" | "wont_do" | null;

C'est tout. Trois états. Des résultats binaires avec une échappatoire qui nécessite une explication.

Le compteur de la honte

Voici où ça devient intéressant. Quand vous reportez une action, nous incrémentons un compteur.

Ce compteur est visible. Quand une action affiche « Reportée 2× » dans ce badge ambre, tout le monde peut le voir. Ce n'est pas une métadonnée cachée. C'est un signal public qui dit « nous avons repoussé cet engagement deux fois maintenant ».

Est-ce un peu inconfortable ? Oui. C'est le but. L'inconfort crée une pression pour soit faire la chose, soit décider consciemment de ne pas la faire. Les deux sont des résultats légitimes. La négligence silencieuse ne l'est pas.

Nous avons vu des équipes où une action atteignant « Reportée 3× » déclenche automatiquement une discussion : « OK, on continue de repousser ça. Voulons-nous vraiment faire ça, ou devrions-nous simplement la clore ? »

Cette conversation est un progrès. Cette conversation n'arrive presque jamais sans le compteur visible.

Ne pas faire est une fonctionnalité, pas un échec

La plupart des outils traitent la clôture d'une action comme son achèvement. Nous séparons explicitement les deux.

Quand vous clôturez quelque chose comme « ne pas faire », vous devez fournir une raison. « Plus pertinent » convient. « Les priorités ont changé » convient. « Nous avons réalisé que c'était une mauvaise idée » convient. Mais vous devez l'articuler.

Ce n'est pas du remplissage bureaucratique de cases. C'est forcer l'équipe à prendre une décision explicite. La clôture consciente est infiniment meilleure que l'abandon inconscient. Une décision de ne pas faire quelque chose est toujours une décision. Une décision crée de l'apprentissage (« nous avons essayé de nous engager sur X mais n'avons pas pu suivre à cause de Y »).

L'oubli ne crée rien.

Terminée ou pas terminée

Nous n'avons délibérément pas implémenté de pourcentage d'achèvement ou d'états de progrès. Une action est soit ouverte, soit terminée. C'est le modèle de données :

export type ActionItemStatus = "open" | "done"; // Simplified - done or not done

C'était un choix de conception conscient qui met certaines personnes mal à l'aise. « Et si j'en suis à la moitié ? » Alors elle est ouverte. « Et si j'ai commencé la recherche ? » Ouverte. « Et si j'ai écrit un brouillon ? » Toujours ouverte.

La seule question qui compte : avez-vous fait la chose à laquelle vous vous êtes engagé ?

Ce cadrage binaire élimine entièrement le théâtre du progrès. Il n'y a pas de terrain d'entente confortable où vous pouvez revendiquer du crédit pour des intentions. Vous l'avez livrée ou vous ne l'avez pas livrée.

Vos actions vous suivent

Nous avons créé un tableau de bord personnel — la page « Mes actions » — qui regroupe tous vos éléments d'action de toutes les équipes dont vous faites partie.

Cela crée une surface de responsabilité personnelle. Vos engagements ne sont pas dispersés entre différents tableaux de rétro et projets Jira d'équipe. Ils sont tous au même endroit, sous vos yeux.

L'effet psychologique est subtil mais réel. Lorsque vos actions ouvertes sont visibles dans votre tableau de bord personnel chaque fois que vous vous connectez, elles sont plus difficiles à oublier. Elles ne sont pas enfouies dans un backlog d'équipe. Elles sont devant vous.

La confiance se mesure, elle ne se présume pas

C'est là que le système devient sérieux. Le taux de complétion des actions alimente directement nos métriques de Dynamique d'équipe — plus précisément, le score de Confiance.

function calculateActionScore(
  completed: number,
  total: number,
  config: TeamDynamicsConfig,
): number {
  if (total === 0) return 50; // No actions = neutral
  const rate = completed / total;

  // Use config threshold
  if (rate >= config.healthyActionItemCompletion) return 100;
  if (rate >= config.healthyActionItemCompletion * 0.7) return 70;
  return Math.max(20, rate * 100);
}

Pourquoi la complétion des actions correspond-elle à la confiance ? Parce que tenir ses engagements, c'est la confiance. Lorsqu'une équipe respecte systématiquement ses engagements — même ceux internes qui n'affectent que l'équipe — cela renforce la confiance. À l'inverse, un schéma de promesses non tenues (même petites comme les actions de rétro) érode la confiance que l'équipe a en elle-même.

Une équipe qui ne peut pas faire confiance à ses propres engagements aura du mal avec tout le reste.

La métrique n'est pas punitive. Une équipe qui ne crée aucune action obtient un score neutre. Une équipe qui en crée quelques-unes et en complète la plupart est récompensée. Une équipe qui en crée beaucoup et en complète peu est signalée — non pas comme « mauvaise » mais comme un signal que quelque chose ne va pas. Peut-être que les actions sont trop ambitieuses. Peut-être qu'il n'y a pas de temps réservé pour le travail d'amélioration. Peut-être que le problème est systémique.

La métrique crée la conversation. L'équipe décide quoi en faire.

La philosophie

Tout ce que nous avons construit ici découle d'une conviction simple : les décisions explicites valent mieux que la négligence implicite.

• Dire « nous ne ferons pas ceci » vaut mieux qu'oublier tranquillement.
• Dire « nous reportons ceci » vaut mieux que prétendre que nous ne nous sommes pas engagés.
• Dire « nous l'avons fait » (quand vous l'avez vraiment fait) vaut mieux que « nous avons fait des progrès ».

Nous n'essayons pas de faire honte aux équipes. Nous essayons de créer un système où l'honnêteté est plus facile que l'évitement. Où le chemin de moindre résistance mène à la clarté plutôt qu'à l'ambiguïté.

Les outils traditionnels facilitent l'oubli et rendent la confrontation inconfortable. Nous avons inversé cela. Notre système rend l'oubli impossible (la vérification de responsabilité) et la confrontation gérable (trois options claires, chacune légitime).

Le résultat n'est pas un taux de complétion de 100 %. Ce serait irréaliste et indiquerait probablement que les équipes ne s'engagent que sur des actions sûres et faciles. Le résultat, ce sont des équipes qui connaissent le sort de chaque engagement qu'elles ont pris. C'est très différent, et c'est bien plus précieux.

Ce que nous avons observé

Les équipes utilisant le modèle de vérification de responsabilité rapportent quelques changements constants :

Moins d'actions, mais de meilleures

Lorsque vous savez que vous serez confronté à vos engagements, vous en prenez moins. Mais ceux que vous prenez sont plus susceptibles d'être des choses que vous ferez réellement. Le schéma « mettons ceci sur la liste des actions pour que les gens se sentent entendus » meurt rapidement.

Des décisions « ne sera pas fait » plus rapides

Les équipes deviennent meilleures pour reconnaître quand quelque chose ne va pas se produire. Plutôt que de le laisser traîner pendant trois sprints, elles le fermeront en un ou deux. « Nous avons dit que nous ferions ceci, nous ne l'avons pas fait, nous n'allons pas le faire — fermons-le et arrêtons de faire semblant. »

Plus de conversations sur la confiance

Lorsque le score de Dynamique d'équipe reflète le suivi des actions, cela devient une donnée pour la rétro elle-même. « Notre score de confiance a chuté ce sprint. Un facteur : nous n'avons complété que 2 actions sur 7. Que se passe-t-il ? »

Cette méta-conversation sur la capacité de l'équipe à tenir ses engagements est souvent plus précieuse que n'importe quelle action individuelle.

Essayez d'être inconfortable

Si vos actions de rétro continuent de mourir, le problème n'est pas la motivation. C'est la conception du système. Vous avez besoin de :

1. Une fonction de forçage — Quelque chose qui rend la confrontation aux anciens engagements obligatoire, pas optionnelle.
2. Des résultats binaires — Fait ou pas fait. Pas de cachette derrière des pourcentages.
3. Un suivi visible des reports — Un compteur qui rend les reports répétés visibles.
4. Une clôture légitime — Une option « ne sera pas fait » qui nécessite une raison mais est traitée comme valide.
5. Des surfaces de responsabilité personnelle — Vos engagements vous suivent, pas seulement l'équipe.
6. Des métriques qui reflètent la réalité — Le suivi affecte les scores de santé de l'équipe.

Nous avons intégré tout cela dans Simyl Flow parce que nous en avions assez de voir de bonnes idées d'amélioration mourir dans l'espace entre les réunions. La vérification de responsabilité est un peu agaçante. Le compteur de reports est un peu inconfortable. Le statut binaire est un peu rigide.

C'est le but. Le confort, c'est comme ça que les actions meurent.

Sources

1. Bondale, K. (2022). « Why hold retrospectives if ideas don't get implemented? » — PMI « Easy in theory, difficult in practice » blog
2. Wolpers, S. (2024). « Ditch the Unfinished Action Items – How to Make Retrospectives Lead to Real Change »