1. Comprendre le changement avant de le construire
Une demande dit souvent ce qu'il faut obtenir, rarement ce que le système fait déjà. Avant de modifier une règle, cherchez le comportement réel : exemples acceptés ou refusés, données existantes, consommateurs, effets asynchrones, opérations manuelles et contraintes de sécurité.
Les quatre questions utiles
| Question | Ce qu'elle évite |
|---|---|
| Quel résultat doit rester vrai ? | Une correction qui casse une règle voisine |
| Qui dépend de ce comportement ? | Une incompatibilité silencieuse |
| Que se passe-t-il si cela échoue à moitié ? | Une opération impossible à réparer |
| Comment le saurons-nous ? | Une régression découverte trop tard |
Ne demandez pas seulement « où est le code ? ». Demandez aussi où se trouvent la décision métier, les données, le contrat, les utilisateurs et les conséquences externes. Un chemin de code est une preuve parmi d'autres ; il peut avoir vieilli.
Définir un résultat observable
Formulez le changement comme un comportement vérifiable : « un client éligible voit ce prix », « une demande refusée ne crée aucun prélèvement », « un doublon d'événement ne produit qu'un seul effet ». Cette phrase devient la base de la conception, du test et de l'observation.
Une question mérite d'être creusée quand une réponse erronée pourrait créer un dommage difficile à détecter ou à corriger. Le but n'est pas de cartographier tout le système ; c'est de retirer l'incertitude qui compte pour ce changement.
Approfondir : découvrir le comportement, cartographier le système et évaluer l'impact.