Lucas est product manager depuis cinq ans dans une scale-up parisienne. Ce matin, il ouvre son backlog Jira Software et s’arrête sur un chiffre : 492 tickets. Il en crée un 493e. L’idée vient d’un entretien utilisateur de la veille, elle mérite d’être capturée. Il ajoute un nouveau ticket dans le backlog. À vingt mètres de là, un développeur cherche dans cette même liste ce qui est censé être prêt à coder pour le prochain sprint. Il abandonne au bout de quelques minutes et demande directement à Lucas ce qu’il doit traiter. Lucas hésite. Il est perdu. Il sent qu’il perd la maîtrise de la roadmap.

Cette scène se joue lors de chaque sprint dans des centaines d’équipes produit. Elle n’est pas anodine : elle dit quelque chose de précis sur la façon dont les organisations gèrent collectivement l’incertitude et les priorités.

L’accumulation comme symptôme organisationnel

La distinction entre Discovery et Delivery est connue des équipes agiles. La Discovery est l’espace de l’exploration, des hypothèses, du chaos créatif nécessaire avant de savoir ce que l’on veut construire. Le Delivery est celui de la rigueur, des spécifications précises, de la construction elle-même. L’erreur la plus répandue dans les équipes produit consiste à mélanger ces deux logiques dans un seul et même outil.

Le résultat est prévisible : un backlog de 500 tickets qui décourage tout le monde, où les tickets prêts à développer cohabitent avec des idées floues formulées dix-huit mois plus tôt. Les développeurs ne savent plus quoi prioriser. Les product managers passent leurs réunions à trier plutôt qu’à décider. Les parties prenantes finissent par douter que leurs demandes soient jamais traitées.

Mais réduire ce problème à un défaut d’organisation serait passer à côté de l’essentiel. Ce que la psychodynamique du travail révèle, c’est que l’accumulation dans un backlog est rarement un accident : c’est un symptôme. Chaque ticket ajouté représente une promesse tacite (« On va faire ça un jour »), un espoir capturé (« Ça va résoudre ce problème »), une reconnaissance accordée à quelqu’un (« Ton idée a été entendue »). Supprimer ce ticket revient alors à trahir une promesse, abandonner un espoir, dire implicitement que l’idée ne mérite pas de suite. C’est émotionnellement coûteux. Alors on accumule, on reporte la décision, on garde « au cas où ».

La charge cognitive invisible du backlog surchargé

L’ergonomie cognitive nous enseigne que la surcharge informationnelle ne ralentit pas seulement le travail : elle en modifie la nature. Face à 492 tickets, le développeur ne cherche plus ce qui est prioritaire. Il cherche à ne pas se tromper. La prudence remplace l’efficacité. La charge cognitive invisible qui pèse sur l’équipe est réelle, même si elle n’apparaît dans aucun tableau de bord.

Pour les développeurs, la désorientation est concrète : ils ne savent plus ce qui est vraiment attendu d’eux à court terme. Pour les product owners, c’est l’épuisement administratif qui prend progressivement la place du travail stratégique. Pour les parties prenantes, c’est la frustration croissante de voir une demande formulée depuis longtemps rester dans une liste sans jamais avancer.

Le backlog comme espace de négociation politique

La sociologie des organisations ajoute une couche supplémentaire à cette analyse. Un backlog n’est pas seulement une liste technique : c’est un espace de négociation où se jouent des rapports de pouvoir réels. Chaque ticket représente la revendication d’un acteur. Le commercial qui veut une fonctionnalité pour conclure un contrat. La responsable marketing qui attend sa roadmap avant un salon. Le dirigeant qui a mentionné « son » projet lors d’un comité.

Dans ce contexte, supprimer un ticket ne revient pas à nettoyer une liste. C’est dire non à quelqu’un d’important dans la hiérarchie, risquer un conflit ouvert, perdre un levier de négociation futur. Le résultat est prévisible : on ne supprime plus rien. Le backlog devient un cimetière diplomatique où cohabitent toutes les demandes, sans qu’aucune ne soit vraiment arbitrée.

La réponse architecturale : Jira Product Discovery et Jira Software

C’est face à ces réalités que la solution proposée par Atlassian prend tout son sens. L’idée centrale est simple dans son énoncé et exigeante dans son application : séparer les outils pour séparer les logiques de travail.

Jira Product Discovery est l’espace des product managers. On y capture des idées, des retours utilisateurs, des problèmes à explorer et des hypothèses à valider. L’interface est visuelle et flexible, délibérément déconnectée du flux de développement. Une idée peut y rester des semaines, être enrichie par des votes ou des insights terrain, puis être archivée sans déclencher la moindre friction technique ou relationnelle. C’est l’espace du « pourquoi » et du « quoi ».

Jira Software est l’espace des développeurs. Une idée n’y entre que lorsqu’elle a franchi un filtre explicite et rigoureux : validée par des preuves de pertinence, priorisée stratégiquement dans le cadre de la vision produit, et rédigée selon une Definition of Ready claire. C’est l’espace du « comment » et du « quand ».

En créant ce sas de décompression entre les deux espaces, les équipes protègent la charge cognitive des développeurs et offrent au travail de discovery un territoire légitime où l’exploration n’est plus une gêne mais une étape à part entière. L’idée n’est plus enfouie sous 492 tickets en attente : elle est dans un espace conçu pour elle.

Ce que la séparation des outils ne résout pas seule

Voilà ce qu’il faut dire clairement : séparer les outils ne résout pas les problèmes d’organisation du travail qui ont conduit à l’accumulation. On peut très bien se retrouver avec 500 idées dans JPD au lieu de 500 tickets dans Jira Software. Si l’organisation ne parvient toujours pas à dire non, si les critères de priorisation restent implicites, si les parties prenantes continuent de ressentir que leurs demandes disparaissent en silence, la séparation technique ne change rien à l’essentiel.

La vraie transformation est culturelle. Elle demande de normaliser l’acte de supprimer : annoncer « nous avons archivé 80 idées ce trimestre » devrait être perçu comme un signe de rigueur stratégique, pas d’échec. Elle demande d’expliciter les critères de priorisation, qu’il s’agisse du cadre RICE, du WSJF ou d’un modèle interne, pour que chaque partie prenante comprenne pourquoi son idée n’a pas franchi le filtre. Et elle demande d’organiser des rituels réguliers de nettoyage, où l’équipe produit décide collectivement et courageusement ce qui mérite de continuer et ce qui peut être libéré.

La philosophie du travail nous rappelle que l’abondance de possibles n’est pas toujours libératrice : elle peut paralyser. Choisir, c’est renoncer. Et c’est précisément là que réside la compétence stratégique d’un product manager : non pas dans sa capacité à capturer toutes les idées, mais dans sa capacité à en libérer avec méthode et clarté.

Votre organisation est-elle capable de faire le deuil des idées non retenues, ou a-t-elle besoin d’accumuler pour ne pas affronter le conflit ? Séparer Discovery et Delivery est une excellente architecture. Elle ne fonctionne pleinement que dans une culture qui accepte de choisir.