Idée principale

Une grande partie des défauts d'une file ne sera jamais corrigée. Ce n'est pas une découverte : l'équipe le sait, le support le sait, le Product Manager le sait.

Le ticket reste pourtant ouvert. Le fermer revient à écrire « on ne fera pas », et à porter cette phrase devant le client qui l'a signalée, devant le support qui la relaie, devant la direction qui l'a vue passer. Personne ne veut être celui-là.

Laisser ouvert ne coûte à personne en particulier. C'est ce qui rend l'inaction stable : le statu quo n'a pas d'auteur.

Pourquoi c'est important

Cela explique la persistance d'un stock que tout le monde juge inutile. Le problème n'est pas informationnel — l'information est partagée — il est d'attribution.

Un dispositif qui force la décision n'apporte donc aucune connaissance nouvelle. Il désigne un signataire. C'est là que se joue son efficacité, et aussi sa difficulté politique.

Nuances et limites

Dans une organisation où refuser est peu risqué, le stock ne grossit pas par ce mécanisme — il peut grossir par simple absence de relecture, ce qui appelle une autre réponse.

Questions ouvertes

• Qui doit porter le refus : le Product Manager, le support qui a remonté le signal, ou l'équipe qui aurait corrigé ?