Idée principale

Un défaut réel peut être mineur : un bouton sur lequel il faut cliquer deux fois. À côté, une capacité absente peut empêcher un utilisateur de produire une déclaration fiscale obligatoire.

Le premier est un défaut au sens strict, le second n'en est pas un — et c'est le second qui doit passer devant. L'ordre de traitement suit l'impact, jamais la qualification.

Pourquoi c'est important

C'est le garde-fou d'une politique zéro bug. Lue vite, elle se transforme en « tout défaut avant toute fonctionnalité », et l'équipe se met à corriger des irritants pendant qu'un besoin bloquant reste sans réponse.

Traiter d'abord parce que c'est étiqueté défaut, c'est remplacer l'arbitrage par l'étiquette : exactement l'erreur que la règle voulait corriger, retournée.

Nuances et limites

La réciproque n'est pas vraie. Repousser indéfiniment des défauts mineurs au nom d'une fonctionnalité toujours plus urgente est précisément le mécanisme qui constitue le stock.

Et la comparaison suppose qu'on sache mettre les deux douleurs sur la même échelle, ce qui n'est pas acquis quand l'une est réglementaire et l'autre quotidienne.

Questions ouvertes

• Sur quelle échelle comparer une douleur réglementaire ponctuelle à une douleur d'usage quotidienne ?