Quand l’usage précise la règle
Une fonctionnalité réglementaire était déjà en production lorsque l’usage réel a fait apparaître des parcours nécessitant une seconde analyse, plus large.
- Domaine
- Analyse métier
- Contexte
- Projet professionnel anonymisé
Vue d’ensemble
La fonctionnalité avait déjà été analysée, implémentée et utilisée en production. La première version couvrait l’interprétation réglementaire et les scénarios métier validés à ce moment-là.
L’usage client a ensuite fait apparaître des parcours qui n’avaient jamais nécessité de traitement explicite. Certains relevaient de l’ergonomie. D’autres posaient une question plus précise sur l’application de la règle dans une situation particulière.
La première implémentation n’était pas remise en cause. La production nous apportait simplement des informations que nous ne possédions pas lors de l’analyse initiale.
Contexte
Les retours se sont divisés en deux sujets.
Le premier concernait des parcours conformes mais inutilement difficiles pour les utilisateurs. Ils pouvaient être traités comme des améliorations produit sans modifier l’interprétation réglementaire.
Le second concernait des cas exceptionnels. Les analyser séparément aurait été plus rapide, mais n’aurait pas répondu à la question de fond : si plusieurs cas nouveaux apparaissaient, existait-il d’autres situations que le modèle initial laissait également implicites ?
C’est à ce moment-là que le sujet a dû être rouvert plus largement.
Définir le problème
Je ne voulais pas convertir chaque retour client en correctif indépendant. Puisque le modèle réglementaire était de nouveau ouvert, il semblait plus solide de reprendre les règles une à une et de vérifier si l’implémentation les représentait encore de manière cohérente.
La question n’était plus seulement comment prendre en charge ce cas ?, mais que nous apprend ce cas sur la complétude du modèle ?
La première question conduit rapidement vers une solution. La seconde peut montrer que l’exception apparente dépend de plusieurs règles existantes et ne doit pas être traitée seule.
Prendre les décisions
Les optimisations de parcours et la revue réglementaire n’avaient pas le même chemin de validation.
Le but n’était pas de prouver que la première version avait été juste ou fausse. Il s’agissait de décider si les éléments observés en production justifiaient d’expliciter de nouveaux cas dans le modèle.
Valider les décisions
L’analyse des améliorations de parcours est terminée et attend le refinement puis le développement.
La revue réglementaire est encore en cours. Chaque règle concernée est comparée aux nouveaux scénarios, puis l’interprétation devra être discutée avec le client avant de figer les choix techniques.
Cet ordre est volontaire. Commencer le développement trop tôt ferait de la solution technique une partie de l’argument, alors que c’est encore l’interprétation métier qui doit être validée.
État actuel
Les deux sujets sont aujourd’hui à des stades différents. Les optimisations peuvent avancer. La revue plus large n’est pas terminée et l’atelier client n’a pas encore eu lieu.
Cette étude de cas ne peut donc pas présenter honnêtement un résultat final. Elle montre plutôt la stratégie d’analyse : utiliser les cas signalés comme des indices, sans supposer qu’ils définissent à eux seuls toute la portée du problème.
Perspective
Je plaçais auparavant l’analyse réglementaire avant l’implémentation, puis la validation du logiciel en production. Dans la pratique, la frontière est moins nette.
Les spécifications décrivent les situations attendues. La production révèle des combinaisons, des exceptions et des usages difficiles à anticiper intégralement. Cela ne signifie pas automatiquement que la première interprétation était mauvaise. Cela signifie que le modèle peut désormais être confronté à une réalité plus riche.
Dans un produit réglementé, l’analyse continue parfois après la mise en production, simplement parce que le produit rencontre enfin les situations qui donnent un sens concret à la règle.
À retenir
Lorsqu’un nouveau cas réglementaire apparaît en production, il faut se demander non seulement comment le traiter, mais aussi s’il modifie notre compréhension du modèle dans son ensemble.