6. Découvrir le comportement avant de le modifier
Pourquoi ce chapitre existe
Une demande apparemment précise décrit souvent une intention, pas le comportement complet d'un système. « Ajouter une remise », « corriger le statut », « rendre ce champ obligatoire » : chacune de ces phrases laisse ouvertes des questions sur le périmètre, les exceptions, les données existantes, les consommateurs et la manière dont le résultat sera observé.
Commencer par coder remplace ces inconnues par des hypothèses silencieuses. Le code peut alors être parfaitement cohérent avec une interprétation qui n'est pas celle du produit, des utilisateurs ou du système existant. La découverte n'est donc pas un retard avant le travail ; c'est le travail qui permet de savoir quel changement mérite d'être construit.
Les idées essentielles
- Une demande est une entrée de découverte, non une spécification exécutable.
- Le comportement réel se trouve dans plusieurs sources, parfois contradictoires : usages, données, code, contrats, incidents et décisions passées.
- Les cas limites révèlent la règle ; ils ne sont pas des détails à traiter après le « cas normal ».
- Une bonne découverte rend explicites les inconnues et donne une manière peu coûteuse de les réduire.
Chercher le comportement, pas seulement l'implémentation
Lire le point d'entrée du code est une étape utile, mais le comportement n'habite pas un seul fichier. Une validation peut être effectuée dans le client, répétée dans une API, contournée par un job de reprise et corrigée manuellement par le support. Une règle de priorité peut avoir été modifiée sans que le document métier ait suivi. La question initiale doit être : que se passe-t-il réellement aujourd'hui, pour qui, dans quelles conditions ?
Les sources de connaissance n'ont pas le même statut. Une métrique de production montre un comportement observé, mais pas l'intention. Le code montre un comportement implémenté, mais pas nécessairement celui qui reste souhaitable. Un ticket ancien exprime une décision, mais peut être dépassé. La découverte consiste à confronter ces sources plutôt qu'à élire la première consultée comme vérité absolue.
| Source | Ce qu'elle éclaire | Ce qu'elle ne prouve pas seule |
|---|---|---|
| Parcours utilisateur et support | Les attentes concrètes et leurs conséquences | Les règles invisibles ou les cas non rencontrés |
| Code et tests | Le comportement actuellement programmé | L'intention métier, les usages externes et les données historiques |
| Logs, traces et métriques | Ce qui arrive réellement à une échelle donnée | Les attentes non instrumentées et les parcours qui échouent avant le signal |
| Schémas et données | Les états existants, y compris les anomalies | La signification exacte d'un champ ou son propriétaire |
| Contrats et documentation | Les engagements explicites | Leur fraîcheur et leurs usages effectifs |
| Incidents et décisions passées | Les défaillances connues et leurs compromis | L'ensemble des risques actuels |
Faire émerger les invariants
Un invariant est une propriété qui doit rester vraie malgré les variations du flux. Il ne décrit pas un écran ou une fonction ; il protège une conséquence importante. Par exemple : « un remboursement ne peut jamais excéder le montant effectivement encaissé », « un utilisateur désactivé ne peut pas produire de nouvel effet métier », ou « chaque événement de facturation est traçable jusqu'à son opération source ».
Les invariants ont deux avantages. Ils donnent une cible de conception indépendante de la solution choisie, et ils font apparaître les cas limites. Si une remise est plafonnée par commande, que se passe-t-il lors d'un remboursement partiel, d'une nouvelle devise, d'une modification de panier ou d'une reprise de paiement ? Les réponses peuvent être différentes, mais l'équipe doit pouvoir expliquer pourquoi.
Les inconnues sont des objets de travail
Les équipes expérimentées ne prétendent pas savoir ce qu'elles ignorent. Elles formulent les inconnues de façon exploitable : « Nous ne savons pas si les commandes importées peuvent porter plusieurs devises » est différent de « il faut vérifier les cas limites ». La première phrase permet d'identifier une source de données, un interlocuteur ou une expérimentation.
Toutes les inconnues ne méritent pas la même investigation. Leur priorité dépend de l'impact si l'hypothèse est fausse, de la vraisemblance de l'erreur et du coût d'apprendre. Interroger une personne métier ou examiner cent lignes de logs peut suffire ; lancer un chantier de cartographie complet pour une option interne isolée serait disproportionné.
Écrire « nous supposons que les événements sont reçus dans l'ordre » prépare une conception plus robuste. Si cette hypothèse est essentielle, elle appelle une preuve : documentation du producteur, données de production, test de perturbation ou mécanisme d'idempotence. Si personne ne sait comment elle pourrait être fausse, elle n'est pas encore assez précise.
Croiser les sources sans choisir une vérité par confort
Les sources de connaissance se contredisent fréquemment. Le code peut autoriser une opération que les personnes métier pensent interdite. Une documentation peut décrire une règle remplacée silencieusement. Un dashboard peut indiquer que personne n'utilise un parcours alors que les clients contournent l'instrumentation. Dans ces situations, la découverte ne consiste pas à choisir l'autorité la plus proche de l'équipe. Elle consiste à expliquer la divergence.
Une séquence de travail efficace est la suivante : formuler le comportement supposé ; chercher une source qui le confirme ; chercher activement une source qui pourrait le contredire ; classer le résultat en fait observé, intention confirmée, hypothèse ou anomalie. Cette dernière étape est importante : une anomalie de donnée ne doit pas devenir accidentellement une règle de domaine, mais elle ne doit pas être effacée avant que son impact soit compris.
| Désaccord entre sources | Hypothèse à examiner | Décision possible |
|---|---|---|
| Code et documentation | La règle a-t-elle changé sans mise à jour ? | Corriger la documentation, ou déprécier le comportement réel explicitement |
| Données et produit | Les enregistrements sont-ils historiques ou encore produits ? | Traiter l'historique à part, ou corriger le flux de création |
| Support et métriques | Le contournement échappe-t-il à l'instrumentation ? | Compléter les signaux et modifier le parcours |
| Deux équipes métier | Le même terme couvre-t-il deux politiques ? | Séparer les modèles et leurs contrats |
Préserver les preuves de découverte
Une conversation ou une exploration de logs produit souvent la connaissance la plus coûteuse du changement. La résumer dans la fiche de comportement, une ADR ou un exemple de test protège l'équipe contre la redécouverte lors de la prochaine évolution. Il ne s'agit pas d'archiver chaque échange : il s'agit de conserver la décision, la source de confiance et l'inconnue qui reste ouverte.
Cette trace est également utile lorsque le changement est contesté après livraison. Elle permet de distinguer une hypothèse raisonnable devenue fausse d'un risque connu mais ignoré, puis d'améliorer le mécanisme approprié sans réécrire l'histoire.
Exemple filé — Rendre une « suppression » explicite
Une demande propose de « supprimer un utilisateur ». L'équipe commence par demander ce qui doit disparaître : accès, profil public, données personnelles, factures, événements d'audit, identifiants de connexion, données de recherche et sauvegardes. Elle découvre que le support utilise « supprimer » pour désactiver un compte, tandis que la conformité l'emploie pour une demande d'effacement. Le code actuel mélange les deux dans un statut deleted.
Le modèle de domaine distingue alors trois transitions : désactivation de l'accès, anonymisation de certaines données, et conservation d'un historique obligatoire. La découverte a évité deux défauts opposés : effacer une information qui devait rester traçable, ou promettre une suppression qui ne traitait que l'interface. Les prochaines étapes — cartographier les copies, définir la rétention, tester les droits et planifier la migration — deviennent possibles parce que le comportement a acquis un vocabulaire précis.
Anti-patterns
Prendre le ticket pour la totalité du besoin
Un ticket exprime généralement une décision de priorisation, pas un modèle de domaine complet. Le traiter comme une spécification ferme invite à renvoyer toutes les ambiguïtés à la QA ou au support. Un ticket de qualité contient un résultat attendu, des exemples et des questions ; il ne prétend pas éliminer le dialogue.
Commencer par le schéma de données
Un nouveau champ donne l'impression d'avancer. Mais le schéma fige souvent des concepts encore mal compris : qui le renseigne, à quel moment, peut-il changer, qui le lit, comment traiter l'historique ? Le modèle de données doit traduire une règle explicitée, pas la découvrir par accident.
Confondre le chemin nominal avec la règle
Le scénario le plus courant est souvent le moins informatif. Les règles deviennent visibles dans les transitions : annulation, reprise, doublon, concurrence, expiration, droits insuffisants, import historique. Éviter ces questions ne réduit pas leur importance ; cela les reporte à la production.
Bonnes pratiques
Produire une fiche de comportement, pas une longue spécification
Avant un changement non trivial, quelques éléments suffisent à rendre le raisonnement réutilisable : le résultat attendu, les acteurs touchés, les invariants, les exemples et contre-exemples, les dépendances connues, les inconnues et les critères d'observation après livraison. Cette fiche doit rester assez courte pour être lue pendant une revue.
Utiliser les exemples comme tests de compréhension
Un exemple concret force les termes flous à devenir des valeurs et des états. On peut demander : « un abonnement annulé le dernier jour du mois, avec une facture déjà émise, doit-il être renouvelé ? » Si les personnes concernées répondent différemment, l'équipe a découvert un problème avant de le rendre coûteux.
Checklist — Avant de concevoir
- Quel résultat utilisateur ou opérationnel le changement doit-il rendre possible ?
- Quel comportement actuel est conservé, modifié ou volontairement supprimé ?
- Quels invariants ne doivent pas être violés ?
- Quels cas de transition, d'erreur, de reprise ou de données historiques comptent ?
- Quelles sont les trois hypothèses les plus risquées, et comment les vérifier ?
- Quelle source de connaissance contredirait notre interprétation si elle était fausse ?
À retenir
La découverte ne cherche pas à écrire une prévision exhaustive du futur. Elle transforme une intention vague en comportement discutable, protège les invariants et rend les inconnues visibles. Un changement ainsi préparé réduit le risque avant même que le code ne soit ouvert.