Idée principale

Lue au pied de la lettre, la formule annonce un logiciel sans défaut — ce qu'aucune équipe ne livre, et l'objection tombe aussitôt. L'objectif est ailleurs : zéro défaut connu non décidé.

L'inconnu reste hors de portée. Ce qui est visé est l'acceptation permanente et organisée de défauts que l'on connaît. Quand un signal arrive — un retour du support, une régression repérée sur une application comme My Porsche —, l'équipe tranche : est-ce un défaut ? Si oui, on corrige. Si non, on le sort de la gestion des défauts : amélioration, demande de capacité, incompréhension, sujet intéressant mais hors priorité.

Ce que la règle interdit est le troisième état : « on sait que c'est un défaut, on le garde dans une liste pour plus tard. » Un défaut connu que l'on conserve sans trancher a cessé d'être un défaut logiciel ; c'est un défaut de décision.

Pourquoi c'est important

Cela retourne l'objection la plus courante. On ne promet pas la perfection, on interdit un état intermédiaire — et l'état intermédiaire, lui, est parfaitement atteignable.

Cela déplace aussi la mesure. On ne compte plus les défauts du produit, on compte les défauts connus sans décision. Le premier nombre dépend du système de production ; le second ne dépend que de l'organisation.

Nuances et limites

La règle ne dit rien de la qualité des décisions prises. Une équipe qui requalifie massivement en non-défaut satisfait la lettre en vidant le sens.

Elle ne porte que sur le connu : un produit peu instrumenté, sans support structuré, affiche peu de défauts connus sans en avoir moins.

Questions ouvertes

• Comment repérer une requalification de complaisance, qui ferme la décision sans traiter la douleur ?