Modèle de données : comment l'utiliser pour mieux cadrer vos user stories

J'ai eu cette conversation des dizaines de fois. Un business analyst présente ses user stories en sprint planning, les développeurs posent des questions sur les données, et la réunion dérive pendant vingt minutes sur des sujets qui auraient dû être clarifiés bien en amont. À la fin, plusieurs user stories sont repoussées parce qu'elles sont trop vagues pour être développées.

Ce n'est pas un problème de rédaction. C'est un problème de cadrage. Et la plupart du temps, la réponse était déjà disponible dans le modèle de données.

Le modèle de données, un outil de cadrage sous-utilisé

Dans la pratique, les business analysts consultent le modèle de données pour comprendre comment les données sont structurées mais rarement pour cadrer leurs user stories. C'est pourtant l'un des usages les plus directs qu'on puisse en faire.

Chaque entité du modèle représente un concept métier que le système manipule. Une user story qui crée, modifie, affiche ou supprime de l'information touche nécessairement une ou plusieurs entités. Identifier lesquelles, c'est déjà poser le périmètre fonctionnel de la story avec précision.

Concrètement, si vous rédigez une user story sur la gestion des commandes et que vous constatez que l'entité LigneDeCommande n'existe pas encore dans le modèle, c'est un signal fort : soit elle est implicite dans Commande (et ça mérite d'être questionné), soit elle est dans le périmètre de votre story et il faudra la créer. Dans les deux cas, vous avez une information critique que vous n'auriez pas vue en restant dans votre outil de ticketing.

Les relations révèlent les règles métier à expliciter

Identifier les entités est une première étape. Mais ce sont les relations entre entités, et plus précisément les cardinalités, qui contiennent les règles de gestion que vos user stories doivent refléter.

Une cardinalité n'est pas un détail technique. C'est une règle métier encodée dans le modèle. Et si votre user story ne la mentionne pas explicitement, vous laissez les développeurs décider à votre place ce qui doit se passer dans les cas limites.

Prenons un exemple simple. Une relation entre Commande et Produit avec une cardinalité indiquant qu'une commande peut contenir plusieurs produits soulève immédiatement des questions pour vos critères d'acceptance : que se passe-t-il si l'utilisateur valide une commande sans avoir ajouté de produit ? Peut-il commander le même produit deux fois dans la même commande ? Quelle est la quantité minimale et maximale par ligne ?

Ces questions ne viennent pas naturellement quand on rédige une user story de façon intuitive. Elles viennent quand on regarde le modèle.

Les cardinalités comme source de critères d'acceptance

Une fois que vous avez compris la nature d'une relation, vous pouvez systématiquement en dériver des critères d'acceptance. C'est mécanique.

Pour une relation un-à-plusieurs (Commande → LigneDeCommande) :

• Que se passe-t-il si on tente de créer une commande sans ligne ?

• Peut-on modifier une ligne après validation de la commande ?

• Que devient la commande si toutes ses lignes sont supprimées ?

Pour une relation plusieurs-à-plusieurs (Produit ↔ Catégorie) :

• Un produit peut-il exister sans catégorie ?

• Y a-t-il un nombre maximum de catégories par produit ?

• Si une catégorie est supprimée, que devient le produit qui lui était rattaché ?

Ces questions ne sont pas exhaustives, mais elles couvrent les cas limites que les développeurs rencontreront inévitablement. Les poser au moment de la rédaction de la user story, c'est éviter de les découvrir en recette, ou pire, en production.

Pour aller plus loin

Si vous souhaitez vous sentir à l'aise avec la lecture des modèles de données pour mieux les exploiter dans votre travail quotidien, j'ai créé une formation gratuite de 2 heures spécialement conçue pour les Business Analysts et Product Owners.

Elle vous donne une méthode concrète pour lire et comprendre un modèle en ERD, Merise ou UML, sans formation technique préalable. Déjà suivie par plus de 1 000 participants, notée 4,5/5.

👉 Accéder gratuitement à la formation "Les Modèles de Données pour Product Owner et Business Analyst"