Comment lire un MCD sans être développeur

En réunion de cadrage, l'architecte projette un schéma à l'écran. Quelqu'un dit "c'est le MCD du projet, ça vous donne le périmètre fonctionnel". Tout le monde hoche la tête. Vous regardez le schéma : des rectangles arrondis, des ovales, des traits avec des chiffres dans tous les sens.

Vous n'êtes pas développeur. Personne ne vous a appris à lire ça. Et vous n'allez pas le demander maintenant.

C'est une situation que beaucoup de business analysts et product owners vivent sans le dire. Ce guide est fait pour y remédier.

C'est quoi un MCD, exactement ?

MCD signifie Modèle Conceptuel des Données. C'est un outil issu de la méthode Merise, très répandue dans les projets IT français.

Ce qu'il faut comprendre avant tout : un MCD n'est pas un schéma technique. C'est une représentation des concepts métier et de leurs relations, construite indépendamment de tout choix d'implémentation. Il dit quoi, quelles entités existent dans le domaine, quelles règles les lient, sans dire comment ces données seront stockées en base.

C'est la différence avec le MLD (Modèle Logique des Données) et le MPD (Modèle Physique des Données), qui eux traduisent ces concepts en tables, colonnes et contraintes techniques. Le MCD, c'est le niveau le plus proche du métier. C'est précisément pour ça qu'un business analyst devrait savoir le lire, et idéalement le produire.

Étape 1 : repérer les entités

La première chose à faire quand vous ouvrez un MCD, c'est d'ignorer tout sauf les boîtes. En Merise, les entités sont représentées par des rectangles aux coins arrondis. Ce sont elles qui portent les noms.

Ces noms sont votre point d'entrée : Client, Commande, Produit, Contrat, Collaborateur. Ce sont les concepts centraux du domaine métier. Votre premier travail est de les lire et de vérifier que vous les reconnaissez.

Posez-vous deux questions simples. Est-ce que je retrouve ces termes dans les échanges avec le métier ? Et est-ce qu'il manque des concepts que j'aurais attendus ici ?

Si une entité porte un nom flou ou technique, notez-le. Si une entité que vous attendiez est absente, c'est peut-être un oubli, peut-être un choix, dans les deux cas, c'est une information à creuser. La liste des entités vous donne le périmètre fonctionnel du projet. C'est déjà beaucoup.

Étape 2 : lire les attributs

À l'intérieur de chaque entité, vous trouverez une liste d'attributs. Ce sont les informations que le système connaît sur ce concept : le nom d'un client, la date d'une commande, le prix d'un produit.

Deux choses à retenir ici.

D'abord, ne vous perdez pas dans les identifiants. En Merise, chaque entité possède un identifiant, généralement souligné ou indiqué en tête de liste. C'est un choix de modélisation, pas une information métier. Passez-le, concentrez-vous sur les autres attributs.

Ensuite, vérifiez la cohérence des attributs avec ce que vous connaissez du métier. Si l'entité Client contient un attribut chiffreAffaires, demandez-vous si c'est une donnée que le système doit enregistrer ou une donnée calculée à partir d'autres informations. Ce type d'observation révèle souvent des approximations dans la modélisation qui auront des conséquences plus tard.

Étape 3 : décoder les relations et les cardinalités

C'est l'étape où la plupart des lecteurs non techniques s'arrêtent. Les cardinalités semblent cryptiques, et les notations varient d'un modèle à l'autre.

La technique que j'utilise est simple : je cherche dans le modèle une relation que je connais déjà bien, et je m'en sers pour calibrer la lecture de toutes les autres.

En Merise, les cardinalités s'écrivent sous la forme minimum,maximum de chaque côté de la relation. Les valeurs courantes sont 0, 1 et n.

Prenons une relation classique : Client et Pays. Je sais que dans la quasi-totalité des projets, un client est rattaché à un seul pays, et qu'un pays peut contenir plusieurs clients. Je retrouve cette relation dans le modèle et j'observe les cardinalités :

• Du côté Client : 1,1 un client appartient à exactement un pays.

• Du côté Pays : 1,n un pays contient un ou plusieurs clients.

J'ai maintenant ma clé de lecture. Le n signifie "plusieurs". Le 1,1 signifie "exactement un". Le 0,1 signifierait "zéro ou un", autrement dit, facultatif. Et le 0,n signifierait "zéro ou plusieurs", facultatif et multiple.

Avec cette grille, je peux lire n'importe quelle relation du modèle et la reformuler en langage naturel. Ce n'est pas de la technique, c'est de la lecture.

Les erreurs fréquentes

Confondre le MCD et le MLD. Le modèle qu'on vous partage n'est pas toujours un MCD. Si vous voyez des noms de tables au format COMMANDE_LIGNE ou des colonnes du type id_client_fk, vous avez probablement un MLD ou un MPD entre les mains — un modèle plus technique, plus difficile à lire. Savoir faire la distinction vous permet de savoir à quel niveau vous vous situez.

Chercher les clés étrangères. Dans un MCD, elles n'existent pas explicitement — c'est précisément l'intérêt du niveau conceptuel. Si vous cherchez des id qui font le lien entre les tables, vous lisez probablement un modèle physique.

Vouloir tout comprendre en une fois. Un MCD peut représenter des dizaines 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. Commencez par identifier les cinq ou six entités les plus connectées. Le reste s'éclaire ensuite naturellement.

Ne pas questionner ce que vous lisez. Un MCD n'est pas une vérité absolue. C'est un modèle, construit à un moment donné, par des personnes qui avaient une certaine compréhension du métier. Il peut contenir des erreurs, des approximations, des choix discutables. Le lire activement — en vérifiant que ce qu'il dit correspond à la réalité du terrain — fait partie du travail du business analyst.

Pour aller plus loin

Si vous souhaitez aller plus loin sur la lecture des modèles de données, MCD, ERD ou UML, 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 sans formation technique préalable. Déjà suivie par plus de 1 000 participants, 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