Je suis en mission, je reçois un schéma de base de données — par où commencer ?

Il y a quelques années, je travaillais sur un projet de digitalisation dans le secteur de la distribution. À peine arrivé, l'architecte m'a partagé un fichier avec un message lapidaire : "Le MLD est dans le dossier projet, c'est utile pour ta prise en main." Je me retrouve face à une trentaine de boîtes reliées par des traits, avec des chiffres dans tous les sens.

Je n'allais évidemment pas répondre que je ne comprenais pas. Mais je ne savais pas vraiment par où commencer non plus.

Depuis, j'ai vu passer des centaines de modèles de données dans des contextes très différents: retail, banque, santé, industrie. Et j'ai développé une méthode simple pour m'y retrouver rapidement, quelle que soit la notation utilisée. C'est ce que je propose de partager ici.

Les entités : commencer par le vocabulaire du domaine

La première chose à faire quand on reçoit un modèle de données, c'est d'ignorer les traits. Complètement. Dans un premier temps, concentrez-vous uniquement sur les boîtes, ce qu'on appelle les entités.

Ces entités portent des noms : Client, Commande, Produit, Contrat, Facture, Collaborateur. Ce sont les concepts centraux du domaine métier. Et c'est précisément là que réside votre première valeur ajoutée en tant que business analyst : vous savez si ces noms correspondent à la réalité de l'organisation.

Il n'est pas rare de voir un modèle où l'entité s'appelle Account alors que tout le monde dans l'entreprise parle de Client. Ou une entité Order alors que le métier distingue très clairement les Devis, les Commandes et les Livraisons. Ces écarts ne sont pas anodins, ils révèlent souvent des approximations dans le recueil des besoins, voire des ambiguïtés qui auront des conséquences lors des développements.

La liste des entités vous donne aussi quelque chose de précieux : le périmètre fonctionnel du projet. Si vous voyez une entité Facture dans le modèle d'un projet qui était censé ne couvrir que la gestion des commandes, c'est une information qui mérite d'être questionnée. Soit le périmètre a glissé, soit le modèle couvre plus large que prévu.

Prenez donc le temps de faire l'inventaire des entités, de vérifier que vous les reconnaissez, et de repérer celles qui vous semblent manquer ou surprenantes. C'est la base.

Les relations : décoder la notation sans la connaître

Une fois les entités identifiées, on peut s'intéresser aux relations. Et c'est là que beaucoup de business analysts bloquent, parce que les notations varient d'un modèle à l'autre.

C'est vrai. Il n'y a pas de standard universel. J'ai vu des modèles en Merise, des ERD avec la notation Crow's Foot, des diagrammes UML et même des variantes maison où la personne qui a rédigé le modèle avait ses propres conventions. Essayer d'identifier la notation avant de lire le modèle est souvent une perte de temps.

La technique que j'utilise est différente : je cherche une relation que je connais bien, et je m'en sers comme étalon pour comprendre comment les cardinalités sont notées dans ce modèle précis.

Prenons un exemple. Dans presque tous les projets qui impliquent des données géographiques, on retrouve une relation entre Client et Pays. Et cette relation, on la connaît par cœur : un client est rattaché à un seul pays, et un pays peut contenir plusieurs clients. C'est une cardinalité classique de type "un à plusieurs".

Je retrouve cette relation dans le modèle, j'observe comment les symboles sont placés de chaque côté du trait, et j'ai immédiatement la clé de lecture pour tout le reste du schéma. Si du côté Client il y a une patte de corneille et du côté Pays un simple tiret, je sais que la patte de corneille signifie "plusieurs". Si c'est Merise et que je vois 1,n du côté Client et 1,1 du côté Pays, je sais que le n représente la multiplicité.

Pas besoin d'avoir mémorisé toutes les notations. Une relation connue suffit à calibrer votre lecture.

Quelles questions poser et lesquelles éviter ?

Une fois que vous avez identifié les entités et compris le sens des cardinalités, vous avez suffisamment de contexte pour engager une conversation utile avec l'équipe technique.

La tentation est de poser des questions techniques : "C'est quoi ce champ ?", "Pourquoi cette table a une clé composée ?". Ces questions ne sont pas les vôtres. Elles n'apportent pas grand-chose à votre compréhension fonctionnelle et elles font perdre du temps à tout le monde.

Les bonnes questions partent des entités et des relations pour interroger les règles métier qu'elles encodent :

• "Cette entité Commande couvre-t-elle les commandes en cours et les commandes livrées, ou seulement l'une des deux ?"

• "Un client peut-il exister dans le système sans avoir passé de commande ?"

• "Si je vois qu'un Produit peut apparaître dans plusieurs Commandes, est-ce que ça veut dire que les quantités commandées sont gérées dans une table intermédiaire ?"

• "Il y a une entité Adresse séparée du Client. Est-ce qu'un client peut avoir plusieurs adresses ?"

Ce type de question fait deux choses en même temps. Il vous permet de valider votre compréhension du modèle. Et il force l'équipe à formuler explicitement des règles qui étaient jusqu'alors implicites, ce qui est souvent très utile pour tout le monde.

Ce qu'il ne faut pas faire

Ne pas chercher à tout comprendre en une fois. Un modèle peut contenir des dizaines, voire des centaines d'entités. Votre objectif n'est pas de mémoriser le schéma, c'est de comprendre les entités et les relations qui concernent votre périmètre de travail.

Ne pas confondre le modèle conceptuel et le modèle physique. Le modèle qu'on vous partage en début de mission est souvent un modèle physique ou logique, rempli de clés techniques, de tables intermédiaires, de contraintes d'intégrité. Il est plus difficile à lire qu'un modèle conceptuel, qui lui se concentre uniquement sur le sens métier. Si vous n'avez accès qu'au modèle physique, gardez en tête que certains éléments que vous voyez sont des choix d'implémentation technique, pas des réalités fonctionnelles.

Ne pas rester bloqué seul. Un modèle de données est un artefact de communication. Il est fait pour être discuté. Trente minutes avec l'architecte ou le développeur référent, en posant les bonnes questions, vous feront gagner des jours de compréhension.

Pour aller plus loin

Si cette situation vous parle et que vous souhaitez structurer votre lecture des modèles de données, j'ai créé une formation gratuite de 2 heures à destination des Business Analysts et Product Owners.

Elle couvre les trois grandes notations que vous rencontrerez en mission, ERD, Merise et UML, et vous donne une méthode concrète pour lire et comprendre un modèle sans formation technique préalable. Déjà suivie par plus de 1 000 participants, elle est notée 4,5/5 pour sa clarté et son utilité pratique.

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

Clément Fiocre — Data Rosetta Stone