Le backlog n'est pas un dépotoir : c'est un outil d'action

Dans beaucoup d'organisations produit, le backlog est devenu une poubelle propre.

Une idée arrive ? Backlog.

Une demande client ? Backlog.

Un bug pas urgent ? Backlog.

Une piste de discovery ? Backlog.

Une intuition du Product Manager ? Backlog.

Une phrase entendue en rendez-vous commercial ? Backlog.

On y met tout "pour ne pas oublier". Et quelques mois plus tard, on se retrouve avec 300, 500, parfois 1 000 lignes que plus personne ne comprend vraiment.

Ce n'est pas de la transparence.

C'est du bruit.

Un backlog qui contient tout ne clarifie rien. Il donne seulement l'illusion que l'information existe quelque part, alors qu'elle est devenue inutilisable.

Le backlog ne devrait pas être un dépôt d'idées. Il ne devrait pas être une base de demandes clients. Il ne devrait pas être un outil de discovery. Il ne devrait pas être une archive. Il ne devrait pas être le cimetière des bugs qu'on n'a pas voulu traiter.

Un backlog est un outil d'action.

Il sert à organiser une information déjà suffisamment mûre pour que plusieurs personnes puissent travailler ensemble.

La transparence ne consiste pas à tout montrer

L'argument classique pour tout mettre dans le backlog est celui de la transparence.

"Au moins, tout est visible."

En théorie, c'est séduisant. En pratique, c'est souvent faux.

Un backlog de 500 lignes n'est pas transparent. Il est opaque. Personne ne sait vraiment ce qui compte. Personne ne sait ce qui est encore valable. Personne ne sait ce qui est stratégique, ce qui est ancien, ce qui est refusé, ce qui est juste une idée, ce qui vient d'un client important, ce qui a déjà été rediscuté trois fois.

Tout est visible, donc plus rien n'est lisible.

La transparence utile ne consiste pas à tout exposer. Elle consiste à rendre les décisions compréhensibles.

Pourquoi ce sujet est dans la roadmap ?

Pourquoi celui-ci n'y est pas ?

Pourquoi ce bug est traité maintenant ?

Pourquoi cette demande client reste un signal mais ne devient pas un travail ?

Pourquoi ce sujet a été refusé ?

Une idée immature peut rester hors backlog sans être cachée. Elle n'est simplement pas encore prête à devenir un objet collectif.

Il faut distinguer les espaces :

• une mémoire produit ;
• une base de signaux ;
• des notes de réflexion ;
• des décisions ;
• des refus ;
• un backlog.

Tout n'a pas à devenir backlog.

Avant le backlog : l'espace personnel du Product Manager

Avant qu'un sujet entre dans le backlog, il peut exister ailleurs.

Et cet ailleurs n'a pas besoin d'être standardisé.

Un Product Manager peut travailler dans Obsidian. Un autre dans Apple Notes. Un autre dans Trello. Un autre dans un carnet. Un autre dans une base plus structurée. Le nom n'a pas beaucoup d'importance : jardin du PM, sas, parking, notes personnelles, peu importe.

Tant que le travail reste individuel, chacun peut utiliser l'outil qui lui réussit.

C'est même préférable.

L'espace personnel du PM sert à absorber la tempête d'idées. On y collecte, on y relie, on y creuse, on y laisse reposer, on y supprime. Certaines idées vont mûrir. D'autres vont disparaître. Beaucoup ne méritent jamais d'être vues par quelqu'un d'autre.

C'est normal.

Une idée de trois lignes déposée "pour ne pas oublier" n'a pas sa place dans un outil collectif. Elle n'est pas encore prête à mobiliser l'attention d'un développeur, d'un designer, d'un data analyst, d'un sales ou d'un C-level.

Tant qu'une idée reste une pensée individuelle, elle n'a pas besoin d'un outil collectif.

Le backlog commence quand le sujet devient collaboratif

La vraie règle d'entrée est simple :

Le backlog commence quand le sujet cesse d'être une pensée individuelle et devient un travail collectif.

Si le Product Manager continue à creuser seul, ce n'est pas encore du backlog.

Si le sujet demande une étude de faisabilité, il faut parler aux développeurs. Là, le backlog peut devenir utile.

Si le sujet repose sur une hypothèse d'usage ou de valeur, il faut peut-être explorer les données produit avec un data analyst. Là, le backlog peut devenir utile.

Si le sujet demande une conception d'interface, il faut travailler avec le design. Là, le backlog peut devenir utile.

Si le sujet vient du support, il faut peut-être réunir support, produit, data et développement. Là, le backlog peut devenir utile.

Mais entrer dans le backlog ne veut pas dire déposer trois lignes et demander aux autres de se débrouiller.

Le Product Manager doit sortir un minimum de ce qu'il a en tête :

• pourquoi on regarde ce sujet ;
• quelle cible est concernée ;
• quelle douleur ou quelle opportunité est visée ;
• quelle valeur est attendue ;
• quelle question doit être tranchée ;
• quels signaux existent déjà ;
• quelle collaboration est nécessaire.

Ce n'est pas une checklist bureaucratique. C'est le minimum pour permettre à d'autres personnes de travailler avec vous.

Une demande du type "fais-moi une analyse de données sur ce sujet" ne suffit pas. Une demande du type "regarde si ça vaut le coup" ne suffit pas non plus.

Le backlog doit permettre une collaboration structurée. Il ne doit pas déléguer une pensée encore floue.

Le backlog ne remplace pas la conversation

Il y a un piège inverse : vouloir tout formaliser.

Créer des templates partout. Ajouter des champs. Imposer des checklists. Transformer chaque ticket en mini-dossier. Écrire pour se couvrir plutôt que pour travailler.

Ce n'est pas mieux.

Le niveau de détail nécessaire dépend de l'équipe, du sujet et du contexte partagé.

Quand un Product Manager travaille depuis trois ans avec le même développeur, il n'a pas toujours besoin d'écrire autant que lorsqu'un développeur vient d'arriver depuis trois mois.

Quand l'équipe se parle tous les jours, certaines choses peuvent rester orales.

Quand l'équipe est nouvelle, distribuée ou sur un sujet risqué, il faut expliciter davantage.

Les notions de Definition of Ready et Definition of Done peuvent aider. Elles donnent des repères. Mais elles doivent rester vivantes. Elles ne doivent pas devenir une bureaucratie qui remplace le jugement.

Un développeur ne doit pas accepter un ticket qu'il ne comprend pas.

S'il manque des éléments pour évaluer la faisabilité, il doit les demander.

S'il manque le contexte métier, il doit le demander.

S'il ne comprend pas la valeur, il doit le dire.

Une user story n'a jamais été faite pour remplacer la conversation. Elle sert à la déclencher.

Le backlog doit être pensé de la même manière.

Il structure la conversation. Il ne la remplace pas.

Un backlog doit être limité

Un backlog illimité est contradictoire avec une roadmap limitée.

Si la roadmap NNL est censée protéger l'entreprise de la dispersion, le backlog ne peut pas absorber tout ce que la roadmap refuse.

Dans une roadmap Now / Next / Later, le Now dépend de la capacité réelle de l'équipe. Le Next doit rester limité. Même le Later, pourtant censé représenter le champ des possibles, ne peut pas contenir cinquante directions différentes. Sinon, il redevient un inventaire.

Le backlog doit prolonger cette contrainte.

Il ne sert à rien d'avoir une roadmap claire et un backlog qui contient tout le reste.

Même logique pour les bugs.

Si l'on applique une politique zéro bug, un défaut réel doit être traité. Si ce n'est pas un défaut, il peut être requalifié. Si le sujet ne vaut pas la peine d'être traité, on l'assume et on le jette.

Mais accumuler des bugs dans le backlog pour plus tard, c'est cacher la poussière sous le tapis.

On croit préserver une information. En réalité, on conserve une décision non prise.

Un backlog limité protège la capacité de l'équipe. Il protège aussi l'énergie mentale. Une liste infinie crée une tension permanente : tout ce qu'on n'a pas fait, tout ce qu'on fera peut-être, tout ce qu'on garde au cas où, tout ce qui attend sans raison claire.

Ce n'est pas neutre.

Un backlog qui grossit fatigue.

Si j'ajoute, qu'est-ce que j'enlève ?

La règle d'hygiène devrait être simple :

Si j'ajoute ça, qu'est-ce que j'enlève ?

Choisir, c'est renoncer.

Ajouter sans retirer revient à nier la capacité réelle de l'équipe. C'est faire comme si le temps, l'attention produit, la disponibilité des développeurs, la capacité design, l'analyse data et la charge support étaient extensibles.

Ils ne le sont pas.

Un sujet peut sortir du backlog pour plusieurs raisons :

• le monde a changé ;
• le métier a changé ;
• la stratégie produit a changé ;
• la connaissance produit a progressé ;
• le sujet n'est plus pertinent ;
• le sujet est trop faible ;
• le sujet est hors roadmap ;
• le sujet n'a jamais mûri.

Il faut pouvoir jeter.

Le backlog ne doit pas protéger les vieilles idées de la suppression. Il doit protéger la capacité de l'équipe à agir sur les bons sujets.

Les vieux tickets pourrissent

On sous-estime le vieillissement des tickets.

Une idée créée aujourd'hui puis relue six mois plus tard n'est pas nécessairement une bonne mémoire. Elle est souvent périmée.

Le produit a changé. Les clients ont changé. Le marché a changé. Les priorités ont changé. L'équipe a appris. La technique a évolué. L'IA a peut-être rendu possible ce qui ne l'était pas, ou rendu inutile ce qui semblait important.

Reprendre un vieux ticket peut être pire que repartir de zéro.

Le danger vient aussi de l'aversion à la perte. Comme le ticket existe, on veut le préserver. Comme quelqu'un a écrit quelque chose, on hésite à jeter. Comme une demande a été capturée, on veut lui donner une chance.

Mais un ticket n'est pas un actif parce qu'il existe.

Un vieux ticket n'est pas forcément une mémoire. C'est souvent une hypothèse moisie.

Si le sujet redevient intéressant, on peut le rouvrir proprement. Mais il faut le réévaluer dans le contexte actuel, pas reprendre mécaniquement une ancienne formulation.

Un seul backlog pour casser les silos

Je ne crois pas aux backlogs séparés par nature de travail.

Un backlog produit.

Un backlog technique.

Un backlog bugs.

Un backlog support.

Un backlog discovery.

Dans une même équipe, cette fragmentation casse la priorisation.

Bien sûr, si plusieurs équipes travaillent sur des périmètres différents, elles peuvent avoir plusieurs backlogs ou plusieurs vues. Mais dans un espace de priorisation donné, il faut un backlog unique.

Pourquoi ?

Parce qu'on ne priorise pas des catégories. On priorise des douleurs, des risques et de la valeur.

Un sujet issu du support peut nécessiter du support, un data analyst et un développeur.

Un sujet produit peut nécessiter produit et design, sans enjeu technique majeur.

Un sujet d'export peut ne pas nécessiter de design, mais demander une forte connaissance métier et une validation technique sur des traitements de données.

Le bon raisonnement n'est pas : "dans quel backlog va ce sujet ?"

Le bon raisonnement est : "quel problème adresse-t-on, et de quelles personnes avons-nous besoin ?"

C'est aussi pour cela que la distinction bug / feature est souvent trop pauvre. Le client ressent une douleur. Il ne se demande pas si elle appartient au backlog bug, au backlog produit ou au backlog technique.

La question est : quelle douleur est prioritaire au regard de la stratégie, des clients et de la capacité réelle ?

Une demande client n'est pas un item de backlog

Capturer une demande client est important.

Mais une demande client n'est pas un item de backlog.

C'est un signal.

Les clients sont souvent très bons pour expliquer leurs problèmes. Ils savent décrire une douleur, une contrainte, un contexte, une frustration, une obligation métier.

Ils sont beaucoup moins fiables pour proposer la bonne solution.

Il faut donc prendre la demande comme un matériau d'apprentissage, pas comme une consigne d'exécution.

Une demande client peut alimenter le backlog. Mais ce n'est pas automatique.

Elle peut rester dans une base de signaux.

Elle peut être reliée à d'autres demandes.

Elle peut ressortir plus tard.

Elle peut ne jamais ressortir.

Elle peut ne pas correspondre à la stratégie produit.

Elle peut ne pas rentrer dans la roadmap.

Elle peut concerner un cas trop isolé.

Elle peut être intéressante, mais pas assez importante.

Le backlog ne doit pas absorber toutes les demandes clients sous prétexte de ne pas les perdre.

Une demande client est un matériau d'apprentissage, pas une consigne d'exécution.

Tracer certains refus sans recréer un backlog caché

Faut-il tracer les refus ?

Parfois, oui.

Mais tracer un refus ne veut pas dire garder un sujet à faire.

Certains refus méritent une trace parce qu'ils créent une connaissance historique. On refuse aujourd'hui pour une raison donnée : coût, stratégie, faisabilité, manque de compétence, faible demande, mauvais timing.

Un an plus tard, la décision peut changer.

Le métier peut avoir évolué.

La position produit peut avoir changé.

L'IA peut rendre faisable ce qui était trop coûteux.

L'équipe peut avoir recruté un data analyst.

La faisabilité technique peut avoir évolué.

Dans ces cas-là, il est utile de comprendre pourquoi le sujet avait été refusé.

Mais tous les refus ne méritent pas une trace. Beaucoup d'idées faibles peuvent simplement disparaître.

Si le refus est structurant, récurrent ou transverse, il peut même devenir un PDR. On documente alors la décision, son contexte, ses alternatives et les conditions qui pourraient la faire évoluer.

La trace du refus doit servir la mémoire. Elle ne doit pas recréer un backlog caché.

À l'ère de l'IA, le backlog n'est plus l'endroit où l'on pense

Le point le plus important aujourd'hui est peut-être celui-ci : le backlog n'est plus le bon endroit pour penser le produit.

Les outils comme Jira, Notion ou leurs équivalents restent souvent des outils de cartes. Des traitements de texte améliorés. Des espaces où l'on organise des items, des statuts, des champs, des commentaires.

Ils peuvent être utiles pour coordonner l'action.

Mais ils sont très faibles pour construire une réflexion produit.

Les agents IA intégrés à ces outils améliorent parfois un texte, reformulent un ticket, proposent un résumé. C'est utile à la marge. Mais ce n'est pas un système de pensée.

Le vrai actif est en amont.

Un contexte produit riche peut contenir :

• des sources ;
• des interviews transcrites ;
• des notes atomiques ;
• des notes thématiques ;
• des glossaires ;
• des décisions ;
• des PDR ;
• des normes ;
• des données produit ;
• des requêtes SQL ;
• des analyses ;
• des signaux clients ;
• des liens entre features existantes et features absentes.

Avec l'IA, ce contexte devient interrogeable.

On peut demander les angles morts.

Comparer des options.

Relier des entretiens.

Identifier des récurrences.

Générer une requête SQL pour vérifier un comportement dans la data.

Transformer une interview en thématiques.

Relier une douleur client à des features existantes ou absentes.

Construire un ticket seulement à la fin.

Dans cette logique, Jira ou Notion deviennent des chaînes de sortie. On y pousse une information quand elle est prête à être travaillée collectivement.

Le ticket n'est plus l'endroit où l'on pense.

C'est l'endroit où l'on pousse le résultat d'une pensée déjà structurée.

Le backlog discovery est un mauvais contenant

Le "backlog discovery" devient alors un mauvais concept.

La discovery manipule des signaux riches. Elle demande de comparer, relier, analyser, croiser, reformuler, synthétiser.

Une interview client ne devrait pas finir directement comme une carte.

Elle peut être transcrite. Découpée en thèmes. Reliée aux douleurs. Reliée aux enjeux client. Reliée aux enjeux produit. Reliée aux features existantes. Reliée aux features absentes. Croisée avec d'autres interviews. Vérifiée dans les données produit.

Un backlog ne sait pas bien faire cela.

Une liste de cartes est trop pauvre pour porter ce travail.

La discovery a besoin d'un cerveau.

Le backlog n'est qu'un outil d'action.

Certains résultats de discovery peuvent évidemment finir dans le backlog. Mais seulement lorsqu'ils deviennent assez mûrs pour une collaboration structurée.

Le backlog ne doit pas être l'endroit où la discovery se pense.

Le backlog est jetable

Il faut enfin accepter une idée désagréable : le backlog est jetable.

Un item de backlog sert jusqu'à la livraison.

Après, il perd une grande partie de sa valeur.

Les tickets se désynchronisent. Les specs se désynchronisent. Les arbitrages changent pendant la réalisation. Le comportement final en production diffère souvent de ce qui avait été écrit au départ.

La seule réalité durable est ce qui est livré.

Le code source.

Le comportement produit.

La documentation maintenue depuis cette réalité.

Cela ne veut pas dire que le backlog ne sert à rien. Il sert à coordonner. Il sert à faire travailler plusieurs personnes ensemble. Il sert à passer d'une intention à une action.

Mais il ne faut pas le traiter comme une archive sacrée.

Il faut y passer le minimum de temps utile.

Assez pour collaborer.

Assez pour agir.

Pas assez pour produire une documentation qui pourrira.

Le backlog n'est pas une source de vérité. C'est un support temporaire de coordination.

Conclusion

Un bon backlog ne contient pas tout ce que l'entreprise pourrait faire.

Il contient ce sur quoi elle est prête à travailler ensemble.

Ce qui est immature reste hors backlog.

Ce qui est signal reste signal.

Ce qui est refusé peut parfois être tracé, mais ailleurs.

Ce qui relève de la discovery se travaille dans un système de contexte.

Ce qui est bug réel doit être traité, pas stocké.

Ce qui entre dans le backlog doit pouvoir avancer vers l'action.

À l'ère de l'IA, cette distinction devient encore plus importante. Le Product Manager peut construire un contexte beaucoup plus riche en amont : sources, interviews, notes, glossaires, décisions, analyses, données, sparring partner IA.

Le backlog reste utile.

Mais il doit rester à sa place.

Ce n'est pas le cerveau du produit.

Ce n'est pas la mémoire complète de l'entreprise.

Ce n'est pas un dépôt d'idées.

C'est un outil d'action.