Idée principale

Une part des défauts ne vient pas du code mais de ce qui l'a précédé : une spécification incomplète, une décision produit ambiguë, un cas limite jamais envisagé, un flux mal compris. Le constat sert d'ordinaire à disculper — « ce n'est pas un bug, la spec était floue ». Il conduit en réalité ailleurs.

Si le cadre n'est pas assez clair pour livrer correctement, celui qui doit livrer peut le dire et s'arrêter. Refuser n'est pas bloquer : c'est renvoyer la demande vers une clarification — le comportement attendu, les cas limites, les critères d'acceptation, les données, les dépendances, les risques. Demander avant de coder coûte une discussion ; coder dans le flou coûte une fonctionnalité bancale, puis des défauts, du support, du rework et des arbitrages à refaire.

Le fondement est simple : on ne peut pas garantir la qualité de ce qu'on ne comprend pas. Un développeur qui exécute une demande ambiguë tranche les ambiguïtés tout seul, sans le dire, et souvent sans le savoir.

Pourquoi c'est important

Cela transforme une plainte récurrente en droit assorti d'un devoir. Tant que la spécification floue n'est qu'un grief, elle produit des défauts qu'on impute ensuite à celui qui n'a pas posé la question.

Cela précise aussi où se rejoignent responsabilité produit et responsabilité technique : au produit de clarifier son choix, à la technique de ne pas convertir une ambiguïté forte en code fragile.

Nuances et limites

Le droit de refuser se corrompt vite. Utilisé pour obtenir une spécification exhaustive avant tout code, il reconstitue un cycle en V et nie la part d'incertitude que l'équipe est censée absorber.

La ligne n'est pas « tout est écrit » mais « je sais quel comportement je dois rendre vrai » — une frontière qui dépend du contexte partagé de l'équipe, et qu'aucun gabarit ne fixe à sa place.

Questions ouvertes

• Qui arbitre quand le produit estime la demande suffisamment claire et que l'équipe de développement estime le contraire ?