{"id":264,"date":"2026-06-09T13:53:22","date_gmt":"2026-06-09T11:53:22","guid":{"rendered":"https:\/\/racheldubois.fr\/?p=264"},"modified":"2026-06-09T13:53:22","modified_gmt":"2026-06-09T11:53:22","slug":"supprimer-son-backlog-provocation-agile-ou-vraie-discipline-produit","status":"publish","type":"post","link":"https:\/\/racheldubois.fr\/index.php\/2026\/06\/09\/supprimer-son-backlog-provocation-agile-ou-vraie-discipline-produit\/","title":{"rendered":"Supprimer son backlog : provocation agile ou vraie discipline Produit ?"},"content":{"rendered":"\n

\u00ab Delete your backlog. \u00bb<\/em><\/p>\n\n\n\n

Supprimez votre backlog.<\/p>\n\n\n\n

C’est vrai que cela sonne comme une provocation gratuite. Un peu posture. Le genre de phrase qu’on lance pour faire r\u00e9agir une salle. Et puis j’ai repens\u00e9 \u00e0 la derni\u00e8re fois que j’avais ouvert le Jira d’une \u00e9quipe que j’accompagnais : des centaines d’items, des tickets de 2022, des epics fant\u00f4mes, des \u00ab \u00e0 creuser \u00bb que plus personne ne pouvait dater. Et l\u00e0, la “provocation gratuite” est devenue tr\u00e9s r\u00e9elle et concr\u00e8te !<\/p>\n\n\n\n

Parce que pour beaucoup d’\u00e9quipes produit, tech ou agiles, l’id\u00e9e para\u00eet presque irresponsable. Le backlog, apr\u00e8s tout, est cens\u00e9 \u00eatre la m\u00e9moire du produit. L’endroit o\u00f9 l’on stocke les demandes, les id\u00e9es, les tickets techniques, les irritants clients, les besoins m\u00e9tier, les opportunit\u00e9s, les bugs, les promesses faites aux stakeholders, les hypoth\u00e8ses \u00e0 creuser plus tard. Sauf qu’\u00e0 force de vouloir tout conserver, beaucoup d’organisations ne construisent pas une m\u00e9moire produit. Elles construisent un cimeti\u00e8re.<\/p>\n\n\n\n

Un cimeti\u00e8re d’id\u00e9es mal formul\u00e9es. De demandes jamais arbitr\u00e9es. De \u00ab on verra plus tard \u00bb. De tickets que personne ne comprend plus. De dettes techniques dont personne ne sait si elles sont encore r\u00e9elles. De fonctionnalit\u00e9s demand\u00e9es par un stakeholder parti depuis trois r\u00e9organisations. De promesses implicites, jamais assum\u00e9es comme telles. De priorit\u00e9s mortes, mais jamais enterr\u00e9es.<\/p>\n\n\n\n

Et ce cimeti\u00e8re a un co\u00fbt.<\/p>\n\n\n\n

Pas seulement un co\u00fbt d’outil. Pas seulement un co\u00fbt de refinement ou de maintenance Jira. Un co\u00fbt cognitif, organisationnel, strat\u00e9gique. Un backlog infini ne ralentit pas seulement l’\u00e9quipe : il r\u00e9v\u00e8le souvent une incapacit\u00e9 plus profonde \u00e0 choisir.<\/p>\n\n\n\n

C’est tout l’enjeu de cet article. Le backlog n’est pas le probl\u00e8me. Il est le sympt\u00f4me.<\/p>\n\n\n\n

D’un outil de pilotage \u00e0 un parking politique<\/h3>\n\n\n\n

\u00c0 l’origine, un backlog est un outil utile, et je ne voudrais surtout pas qu’on me fasse dire le contraire. Il rend visible le travail \u00e0 venir. Il aide \u00e0 prioriser, \u00e0 collaborer, \u00e0 clarifier ce qui compte maintenant et ce qui pourrait compter demain. Dans un syst\u00e8me sain, le backlog soutient la d\u00e9cision. Il aide \u00e0 organiser l’incertitude.<\/p>\n\n\n\n

Je me souviens quand Claude Aubry m’a form\u00e9 au m\u00e9tier de PO en 2007-2008 : ce backlog \u00e9tait une vraie r\u00e9volution salavatrice pour moi qui avait connu jusque l\u00e0 que les sp\u00e9cifications en 10 tommes !! Quel changement ! C’\u00e9tait l\u00e9ger, efficace : on \u00e9crivait sur des fiches bristol pour le bienfait de la contrainte des 3C (Card, Conversation, Confirmation) <\/strong>de Ron Jeffries, et on avait une petite pile de ces fiches pour \u00e9changer et construire avec les ing\u00e9nieurs. Et puis, progressivement un peu partout j’ai vu le backlog devenir autre chose.<\/p>\n\n\n\n

Il devient un parking politique.<\/p>\n\n\n\n

On y met les demandes pour \u00e9viter de dire non. On y ajoute des id\u00e9es pour ne pas les perdre. On y stocke les sujets \u00ab au cas o\u00f9 \u00bb. On y garde des tickets anciens parce qu’on n’ose pas les supprimer. On y laisse mourir des sujets sans jamais acter leur abandon.<\/p>\n\n\n\n

Progressivement, le backlog cesse d’\u00eatre un instrument de pilotage. Il devient une accumulation. Et cette accumulation produit trois effets tr\u00e8s concrets, que je retrouve presque partout.<\/p>\n\n\n\n

Le premier, c’est une charge mentale pour les Product Owners et Product Managers. <\/strong>\u00catre responsable d’un backlog de plusieurs centaines, parfois milliers d’items, c’est porter une dette permanente. M\u00eame quand tout le monde sait pertinemment qu’une grande partie ne sera jamais trait\u00e9e, le simple fait que \u00e7a existe continue \u00e0 peser. J’ai vu des PM avoir un vrai blocage rien qu’\u00e0 l’id\u00e9e d’ouvrir leur outil le lundi matin.<\/p>\n\n\n\n

Le deuxi\u00e8me, c’est la d\u00e9gradation de la qualit\u00e9 des d\u00e9cisions.<\/strong> Plus le backlog est volumineux, plus la priorisation devient artificielle. On compare des choses incomparables : un ticket de 2023, une demande arriv\u00e9e hier, un irritant technique, un engagement politique, une id\u00e9e vague jet\u00e9e en r\u00e9union. La discussion glisse du probl\u00e8me \u00e0 r\u00e9soudre vers la gestion d’un inventaire.<\/p>\n\n\n\n

Le troisi\u00e8me, c’est le brouillage de la strat\u00e9gie. <\/strong>Un backlog plein donne l’illusion que l’organisation sait ce qu’elle doit faire, alors qu’elle a seulement stock\u00e9 ce qu’elle pourrait faire. Ce n’est pas la m\u00eame chose. Pas du tout, m\u00eame.<\/p>\n\n\n\n

Une liste longue n’est pas une strat\u00e9gie. Une collection de demandes n’est pas une vision produit. Un backlog rempli n’est pas une preuve de maturit\u00e9.<\/p>\n\n\n\n

Parfois, c’est m\u00eame l’inverse.<\/p>\n\n\n\n

Le backlog ob\u00e8se ou infini casse le flux<\/h3>\n\n\n\n

On parle beaucoup de flow<\/em> dans les organisations agiles. On optimise le flux de delivery, on mesure les temps de cycle, on traque les goulots d’\u00e9tranglement, on essaie de fluidifier le passage de l’id\u00e9e au produit livr\u00e9.<\/p>\n\n\n\n

Mais que se passe-t-il avant<\/em><\/strong> qu’un sujet arrive dans le sprint backlog ? Avant qu’il soit raffin\u00e9, estim\u00e9, d\u00e9coup\u00e9 en user stories et construit par une \u00e9quipe ?<\/p>\n\n\n\n

Dans beaucoup d’organisations, l’amont est un entonnoir sans v\u00e9ritable discipline. Toutes les demandes entrent. Peu sont r\u00e9ellement qualifi\u00e9es. Encore moins sont reli\u00e9es explicitement \u00e0 une strat\u00e9gie, \u00e0 un probl\u00e8me client, \u00e0 une opportunit\u00e9 business, \u00e0 une m\u00e9trique d’impact ou \u00e0 une hypoth\u00e8se testable.<\/p>\n\n\n\n

Le backlog devient alors un point de rupture du flux.<\/p>\n\n\n\n

On croit que le flow commence quand l’\u00e9quipe prend un item en sprint. En r\u00e9alit\u00e9, le flux de valeur commence bien avant : au moment o\u00f9 l’organisation formule un probl\u00e8me, choisit une direction, d\u00e9cide de ce qui m\u00e9rite attention, et accepte de laisser tomber le reste.<\/p>\n\n\n\n

Si tout entre dans le backlog, rien n’est vraiment choisi. Et si rien n’est vraiment choisi, l’\u00e9quipe peut livrer vite et\/ou beaucoup sans pour autant cr\u00e9er beaucoup de valeur.<\/p>\n\n\n\n

C’est l’une des grandes confusions de l’agilit\u00e9 appliqu\u00e9e m\u00e9caniquement : on optimise le delivery sans jamais nettoyer le syst\u00e8me de d\u00e9cision en amont. On am\u00e9liore la cadence d’ex\u00e9cution tout en conservant une fabrique \u00e0 priorit\u00e9s floues.<\/p>\n\n\n\n

Le backlog devient l’endroit o\u00f9 l’organisation externalise son incapacit\u00e9 \u00e0 d\u00e9cider.<\/p>\n\n\n\n

\u00ab Si c’est important, \u00e7a reviendra \u00bb<\/h3>\n\n\n\n

L’id\u00e9e de supprimer son backlog repose sur une hypoth\u00e8se simple, et franchement assez inconfortable : si une id\u00e9e est vraiment importante, elle refera surface.<\/strong><\/p>\n\n\n\n

Un besoin client critique reviendra. Une dette technique r\u00e9ellement probl\u00e9matique r\u00e9appara\u00eetra : dans les incidents, dans la maintenabilit\u00e9, dans la v\u00e9locit\u00e9 r\u00e9elle, dans la difficult\u00e9 \u00e0 faire \u00e9voluer le produit. Une opportunit\u00e9 strat\u00e9gique s\u00e9rieuse se reformulera d’elle-m\u00eame dans les discussions de roadmap, les objectifs business, les retours march\u00e9.<\/p>\n\n\n\n

Ce qui ne revient jamais \u00e9tait peut-\u00eatre moins important qu’on ne le croyait. C’est brutal. Mais ce n’est pas absurde.<\/p>\n\n\n\n

Je tiens ici a pr\u00e9ciser un deuxi\u00e8me point important parce que prise au pied de la lettre cette logique est dangereuse. Cette logique n’est est vraie qu\u2019\u00e0 une condition : que votre syst\u00e8me soit capable de faire remonter ces signaux.Sans feedback client r\u00e9el, sans observabilit\u00e9 technique, sans proximit\u00e9 avec le march\u00e9, \u201c\u00e7a reviendra\u201d devient une illusion dangereuse.<\/strong><\/p>\n\n\n\n

Sans syt\u00e8me de feedback tout ne \u00ab revient \u00bb pas spontan\u00e9ment. Une dette technique silencieuse peut tr\u00e8s bien ne jamais crier avant le jour o\u00f9 elle vous explose \u00e0 la figure. Certains risques ne se manifestent qu’une fois. L’argument ne dit pas \u00ab ce qui dispara\u00eet ne valait rien \u00bb : il dit qu’une grande partie de ce qu’on conserve survit par inertie, pas par pertinence.<\/p>\n\n\n\n

Et l\u00e0 est le vrai point. Dans les faits, beaucoup d’items survivent dans les backlogs non parce qu’ils sont encore pertinents, mais parce que personne ne veut prendre la responsabilit\u00e9 de les supprimer. Ils existent par prudence. Par peur du conflit. Par respect mal plac\u00e9 pour une conversation pass\u00e9e.<\/p>\n\n\n\n

Supprimer un backlog, ou au moins le purger radicalement ou r\u00e9guli\u00e8rement, force \u00e0 reposer les bonnes questions :<\/p>\n\n\n\n