Idée principale

Personne, devant son écran, ne se demande s'il souffre d'un défaut, d'une capacité absente, d'une capacité mal faite ou d'une capacité qui ne correspond pas à son besoin. Il constate qu'il n'arrive pas à faire ce qu'il venait faire.

La catégorie du ticket est une information de fabrication. Elle décrit l'origine du problème, pas son effet. Un logiciel sans aucun défaut technique peut être douloureux de bout en bout, et la douleur est aussi réelle que celle d'une régression.

Ce qui reste à analyser est donc ailleurs : quelle douleur, pour qui, à quelle fréquence, avec quel impact, est-ce bloquant, est-ce réglementaire, est-ce que cela génère du support, est-ce que cela détruit la confiance.

La conséquence sur le vocabulaire de priorisation est directe : la distinction entre défaut et fonctionnalité est trop pauvre pour porter un arbitrage. La question utile n'est pas de quelle nature relève le sujet, mais quelle douleur est prioritaire au regard de la stratégie, des clients et de la capacité réelle.

Couche apportée par « Le backlog n'est pas un dépotoir : c'est un outil d'action » (2026-06-03).

Pourquoi c'est important

Cela retire à la catégorie le rôle qu'elle prend spontanément. Elle peut aider à mesurer l'état du système de production ; elle ne peut pas décider à la place de l'équipe, puisqu'elle ne porte aucune information sur l'impact.

Nuances et limites

La catégorie garde une valeur diagnostique côté fabrication : une régression signale un système de production qui laisse passer, ce qu'une demande de capacité ne signale pas.

Et la douleur, elle, est déclarative : elle se recueille auprès de gens qui ne la formulent pas toujours, ou qui la formulent dans le vocabulaire de l'outil.

Questions ouvertes

• Comment recueillir la douleur sans la faire passer par le vocabulaire des tickets, qui la reformate en catégories ?