Du ticket à la décision utilisateur
Un ticket peut demander un point d’entrée API, un validateur ou une nouvelle propriété. Mais le logiciel n’existe pas pour satisfaire le ticket : il existe pour permettre une action ou éviter une erreur.
Quand on comprend cette décision utilisateur, les choix techniques deviennent souvent plus simples. Le contrat d’API, les messages d’erreur et les cas limites cessent d’être des détails séparés : ils font partie d’une même expérience.
Les validations racontent le produit
Dans les systèmes métier, une validation est rarement seulement une condition booléenne. Elle exprime une règle, une intention et parfois une contrainte réglementaire. Une bonne validation dit au client ce qui doit changer et reste cohérente dans toutes les couches.
Penser produit pousse donc à traiter les codes d’erreur, les statuts HTTP et les scénarios limites comme une interface publique, pas comme une conséquence interne de l’implémentation.
Les tests comme documentation du résultat
Un test utile ne prouve pas uniquement qu’une méthode retourne une valeur. Il capture le comportement que le produit promet. Cette nuance est importante quand le code change mais que l’intention doit rester stable.
Je préfère donc des tests nommés autour du scénario et du résultat observable. Ils servent à la fois de filet de sécurité et de documentation exécutable.