Une contrainte ne dit pas encore quoi construire

Dans un produit réglementé, les équipes reçoivent souvent des textes, des politiques internes et des avis spécialisés qui n'utilisent pas le langage du logiciel. La réaction naturelle consiste à transformer chaque phrase en exigence fonctionnelle. Le backlog grossit, mais le lien entre la règle, le risque et la preuve devient plus difficile à suivre.

Le cadrage doit créer ce lien avant de détailler la solution. Il ne s'agit pas de demander au produit d'interpréter seul la règle, ni aux juristes de dessiner l'interface. Il s'agit de construire un objet commun qui permette à chaque discipline de voir la décision prise et ce qui la justifie.

Formuler l'obligation comme une situation observable

Une formulation utile décrit qui agit, sur quel objet, à quel moment, avec quelle information et quelle trace doit subsister. Cette structure révèle les ambiguïtés. Elle montre aussi si la réponse attendue relève du produit, d'une procédure humaine, d'un contrôle organisationnel ou d'une combinaison des trois.

Par exemple, « garantir la traçabilité » reste trop général. Il faut préciser les événements concernés, la personne autorisée à les consulter, la durée utile de conservation, la possibilité de contester une action et le comportement du système lorsqu'une information manque.

Cette précision ne remplace pas la validation spécialisée. Elle donne aux spécialistes un objet concret à confirmer ou à corriger.

Construire une chaîne de preuve

Chaque décision sensible devrait pouvoir être reliée à quatre éléments:

1. la source de la contrainte;
2. l'interprétation retenue et son propriétaire;
3. le comportement produit ou organisationnel qui en découle;
4. la preuve permettant de vérifier ce comportement.

Cette chaîne évite deux dérives. La première est la conformité déclarative, où l'équipe affirme répondre à une contrainte sans pouvoir montrer comment. La seconde est la sur-conformité, où elle construit des mécanismes coûteux sans savoir quel risque ils réduisent.

Le registre correspondant doit rester court et vivant. Une base exhaustive mais obsolète n'aide pas l'équipe. Les décisions les plus irréversibles, les hypothèses encore ouvertes et les preuves attendues méritent la priorité.

Distinguer les décisions automatiques des décisions assistées

Les produits sensibles gagnent à rendre explicite le partage entre automatisation et jugement humain. Une règle peut bloquer automatiquement une opération, produire un signal à examiner, proposer une décision contestable ou simplement conserver une trace.

Ces comportements n'ont pas les mêmes effets sur l'utilisateur, l'exploitation et la responsabilité. Ils doivent être choisis, pas hérités par accident de l'implémentation. L'interface doit aussi montrer ce que le système sait, ce qu'il déduit et ce qui reste à décider.

Tester les cas dégradés avant le parcours idéal

Le cadrage classique décrit un parcours nominal puis ajoute les exceptions. Dans un contexte réglementé, les exceptions portent souvent le vrai risque: donnée absente, identité incertaine, délai dépassé, source contradictoire, décision contestée ou service tiers indisponible.

Travailler tôt sur ces cas permet de découvrir les responsabilités qui manquent. Qui peut lever un blocage ? Quelle information doit être visible ? Quel délai reste acceptable ? Quelle trace permet une revue ultérieure ? Les réponses influencent l'architecture autant que l'expérience utilisateur.

Livrer un premier périmètre vérifiable

Le premier incrément ne doit pas chercher à couvrir toute la réglementation. Il doit fermer une chaîne complète sur un périmètre réduit: une situation réelle, une décision, une preuve, un mécanisme de contestation ou de reprise, et une équipe capable de l'opérer.

Ce périmètre fournit une base de discussion beaucoup plus solide qu'une longue spécification. Les spécialistes peuvent examiner un comportement réel. Les équipes techniques voient les coûts de preuve. Les métiers peuvent mesurer l'effet de la règle sur le travail quotidien.

Un bon cadrage ne supprime pas l'incertitude réglementaire. Il la rend localisable. Il montre quelles décisions sont validées, lesquelles dépendent encore d'un avis, quelles preuves seront produites et quelle partie du système devra changer si l'interprétation évolue. Cette capacité d'adaptation documentée vaut souvent plus qu'une promesse de conformité figée.