MCD – Modèle Conceptuel de Données : Le Guide Complet

Le MCD (Modèle Conceptuel de Données) est une représentation schématique qui décrit les informations gérées par une organisation ou un projet, ainsi que les liens logiques entre ces informations, indépendamment de toute contrainte technique. Il constitue la première étape de la modélisation des données.

Le mot important est « conceptuel ». Le MCD ne se préoccupe ni du logiciel retenu, ni du type de serveur, ni de la façon dont les informations seront physiquement enregistrées. Il répond à une question antérieure : de quoi parlons-nous ?

Prenons une entreprise qui vend des abonnements. Son MCD dira qu’elle gère des clients, que chaque client peut souscrire plusieurs contrats, que chaque contrat porte sur une offre puis qu’il génère des paiements successifs. Ces affirmations restent vraies que l’entreprise travaille sous PostgreSQL, sous Salesforce ou sous un tableur.

Le MCD est issu de la méthode Merise, formalisée en France à la fin des années 1970. Cette origine explique la terminologie que vous rencontrerez (entités, associations, cardinalités) et le fait que le sigle soit surtout employé dans le monde francophone. On parle aussi de Schéma Conceptuel de Données, qui en est un synonyme exact.

Retour au Sommaire

Le MCD remplit quatre fonctions dans un projet.

• Il produit une vision partagée. Le schéma donne à des interlocuteurs qui ne parlent pas le même langage un support commun. Une direction marketing et une DSI se comprennent devant un MCD, alors qu’elles se comprennent rarement devant un cahier des charges.
• Il fait apparaître les désaccords tôt. Modéliser oblige à trancher. Un « prospect » est-il un client au statut particulier ou une entité distincte ? La question paraît théorique. Elle détermine votre capacité future à mesurer un taux de transformation.
• Il sert de socle à la conception technique. Le MCD alimente le modèle logique puis le modèle physique. Sans lui, la structure de la base se construit par accumulation de décisions ponctuelles, ce qui produit des systèmes coûteux à faire évoluer.
• Il documente le patrimoine informationnel. Le schéma reste le point d’entrée pour comprendre un système existant, préparer une migration ou intégrer une nouvelle brique.

Nous le constatons projet après projet : le MCD n’est pas un livrable de plus. C’est le document qui transforme des données brutes en informations structurées, exploitables par les équipes métier. Les projets qui font l’économie de cette étape la paient plus tard, au moment de la recette ou de la première évolution fonctionnelle.

Retour au Sommaire

Le Modèle Conceptuel de Données se traduit par Conceptual Data Model (CDM). Le monde anglophone emploie plutôt les termes de Entity-Relationship Diagram (ERD) ou de Entity-Relationship Model, issus des travaux de Peter Chen publiés en 1976.

Les deux traditions décrivent la même réalité avec des conventions graphiques différentes. Merise place les cardinalités de chaque côté de l’association sous la forme (0,n) ou (1,1). Le formalisme de Chen et ses dérivés utilisent souvent la notation dite « pattes de corbeau », plus répandue dans les outils internationaux.

Cette différence de notation a une conséquence pratique. Si vous travaillez avec un intégrateur étranger ou avec un éditeur international, vos schémas Merise ne seront pas lus spontanément. Nous recommandons dans ce cas d’adopter directement le formalisme entité-association anglo-saxon, quitte à perdre en rigueur académique. Un schéma que tout le monde lit vaut mieux qu’un schéma parfait que personne ne comprend.

Retour au Sommaire

Merise distingue plusieurs modèles selon leur niveau d’abstraction. Le MCD n’est que le premier maillon d’une chaîne de traduction qui descend progressivement vers la technique.

La progression du MCD vers le MPD suit une logique d’appauvrissement volontaire. À chaque étape, le modèle gagne en précision technique et perd en lisibilité métier. C’est pourquoi le MCD conserve son utilité une fois la base construite : il reste le seul document qu’un responsable marketing peut lire sans traducteur.

Le MCT occupe une position à part. Il se situe au même niveau conceptuel que le MCD, mais il décrit les traitements plutôt que les données. Les deux se complètent : le MCD dit ce que vous stockez, le MCT dit ce que vous en faites.

Retour au Sommaire

Quatre notions suffisent à construire un Modèle Conceptuel de Données.

Les entités

Une entité représente un objet du monde réel dont vous voulez conserver la trace. Client, Produit, Commande, Contrat, Magasin. Le test de reconnaissance est simple : une entité a une existence propre et vous en gérez plusieurs occurrences distinctes.

Les attributs

Les attributs sont les caractéristiques d’une entité. Pour un client : nom, prénom, date de naissance, adresse électronique, date de création. Chaque entité comporte un identifiant, c’est-à-dire un attribut qui distingue une occurrence de toutes les autres.

Les relations

Une relation, aussi appelée association, décrit un lien entre deux entités ou davantage. Un client « passe » une commande. Un conseiller « traite » une réclamation. La relation se nomme par un verbe, ce qui aide à vérifier qu’elle a du sens.

Les cardinalités

Les cardinalités précisent combien d’occurrences d’une entité peuvent participer à une relation. Elles s’écrivent sous la forme d’un couple minimum-maximum.

• (0,n) : un client peut n’avoir passé aucune commande comme il peut en avoir passé un nombre quelconque.
• (1,1) : une commande appartient à un client et un seul.
• (1,n) : une commande contient au moins une ligne de commande.
• (0,1) : un client dispose au plus d’un compte de fidélité.

Les cardinalités sont la partie la plus discutée d’un MCD et de loin la plus utile. Chaque couple encode une règle de gestion de votre entreprise. Écrire (0,n) plutôt que (1,n) entre Client et Commande revient à décider que vous acceptez des clients sans historique d’achat. C’est un choix métier, pas un choix technique.

Retour au Sommaire

Voici la démarche que nous appliquons pour construire un MCD :

1. Délimiter le périmètre à modéliser. Décidez de ce que le modèle couvre puis surtout de ce qu’il ne couvre pas. Un MCD qui prétend décrire toute l’entreprise ne sera jamais terminé. Modélisez un domaine : la Relation Clients, la gestion des abonnements, le service après-vente.
2. Recenser les informations existantes. Inventoriez les données déjà présentes dans vos systèmes, leurs sources puis leur usage réel. Cette étape s’appuie utilement sur votre plan de collecte si vous en disposez d’un.
3. Identifier les entités.Repérez les objets qui reviennent dans le discours des équipes métier. Un bon indicateur : les substantifs que tout le monde emploie sans les définir. Ce sont presque toujours des entités. Et presque toujours celles sur lesquelles les définitions divergent.
4. Définir les attributs de chaque entité. Listez les caractéristiques utiles de chaque entité. Retenez le critère d’utilité : un attribut que personne n’exploitera alourdit le modèle et devra pourtant être alimenté, contrôlé puis mis à jour.
5. Établir les relations. Reliez les entités par des verbes. Vérifiez chaque lien en le lisant à voix haute dans les deux sens : « un client passe des commandes », « une commande est passée par un client ». Une relation qui ne se lit pas correctement dans un sens est généralement mal posée.
6. Poser les cardinalités. Fixez les minimums et les maximums de chaque côté. C’est l’étape qui demande le plus d’arbitrages métier. Prévoyez d’y consacrer un atelier dédié avec les responsables opérationnels concernés.
7. Valider avec les parties prenantes. Faites relire le modèle par ceux qui manipulent les données au quotidien. Un MCD validé uniquement par la DSI passe à côté de sa fonction. Nous organisons systématiquement une session de lecture collective, entité par entité.
8. Documenter et maintenir le modèle. Accompagnez le schéma d’un dictionnaire qui définit chaque entité et chaque attribut en langage clair. Puis mettez le modèle à jour à chaque évolution structurante. Un MCD qui ne reflète plus la réalité devient trompeur, ce qui est pire que son absence.

Retour au Sommaire

Un exemple vaut mieux qu’une définition. Voici un Modèle Conceptuel de Données simplifié pour un dispositif de Relation Clients, du type de ceux que nous cadrons en amont d’un projet CRM.

Les erreurs de modélisation se répètent d’un projet à l’autre. Voici celles que nous corrigeons le plus souvent.

Nous prenons parti sur ce point. La valeur d’un Modèle Conceptuel de Données ne réside pas dans le schéma. Elle réside dans les conversations qu’il oblige à tenir.

Un atelier de modélisation produit des questions que personne ne pose autrement :

• Qu’appelons-nous exactement un client actif ?
• Un contact commercial chez un distributeur est-il rattaché à l’enseigne ou au point de vente ?
• Que devient un abonné qui résilie puis revient huit mois plus tard ?

Ces questions paraissent secondaires. Elles déterminent pourtant vos indicateurs, vos segmentations puis votre capacité à personnaliser la relation. Nous avons vu des directions marketing et des directions informatiques travailler dix-huit mois sur un projet avant de découvrir qu’elles ne mettaient pas la même chose derrière le mot « client ». Le MCD fait remonter ce désaccord en semaine deux.

C’est la raison pour laquelle nous animons ces ateliers avec les deux populations autour de la table. Nos profils hybrides facilitent l’instauration de ce pont. Le métier apporte les règles de gestion, l’IT apporte les contraintes de faisabilité puis le modèle enregistre l’accord.

Un conseil pratique pour ces sessions : interdisez les noms d’outils. Dès qu’un participant dit « dans Salesforce, on a un champ pour ça », la discussion quitte le terrain conceptuel. Le besoin business précède toujours la technologie. Le MCD est précisément le document qui protège cet ordre.

Retour au Sommaire

La question mérite d’être posée frontalement. Merise a été formalisée il y a près de cinquante ans, pour des bases relationnelles à schéma rigide. Les architectures actuelles fonctionnent différemment. Une Customer Data Platform ingère des flux hétérogènes. Un Data Warehouse moderne s’organise souvent en schéma en étoile, avec des tables de faits et des tables de dimensions qui ne ressemblent guère à un MCD Merise.

Notre réponse est oui. Mais pas pour les raisons d’origine.

Le MCD ne sert plus principalement à préparer la création d’une base de données. Sur ce plan, les plateformes actuelles offrent effectivement beaucoup de souplesse et acceptent des structures évolutives. Sa fonction s’est déplacée vers trois usages.

• Fixer le vocabulaire commun. Une CDP qui agrège douze sources hérite de douze définitions du client. La réconciliation exige de savoir laquelle fait foi. C’est un travail de modélisation conceptuelle, quelle que soit la technologie sous-jacente.
• Piloter la résolution d’identité. Les règles de rapprochement d’une CDP encodent des décisions sur ce qui constitue une même personne. Ces règles se dérivent directement des entités et des cardinalités posées en amont. Les étapes d’unification des données supposent ce socle.
• Préparer les migrations. Le modèle conceptuel est le seul point de comparaison stable entre un système source et un système cible. Une migration de données menée sans lui se transforme en exercice de correspondance champ à champ, avec les pertes que cela suppose.

La souplesse technique a déplacé le problème, elle ne l’a pas supprimé. Les plateformes modernes vous permettent de charger des données que vous n’avez pas comprises. C’est précisément ce qui rend la modélisation plus nécessaire qu’avant : rien ne vous arrête plus au moment du chargement. L’incohérence se découvre à l’usage.

Nous adaptons en revanche le formalisme. Sur un projet CDP, nous produisons un modèle conceptuel allégé, centré sur les entités pivots et les règles d’identité, plutôt qu’un MCD Merise complet avec toutes ses cardinalités. Le niveau de détail suit l’usage, comme pour tout livrable.

Retour au Sommaire

Le RGPD impose de savoir quelles données personnelles vous détenez, à quelle finalité, pendant combien de temps puis sur quelle base légale. Ces obligations reposent sur une cartographie précise du patrimoine informationnel.

Un MCD documenté répond directement à plusieurs de ces exigences :

• Il identifie les entités porteuses de données personnelles.
• Il permet d’associer une finalité et une durée de conservation à chaque catégorie d’information.
• Il rend traçables les liens entre entités, ce qui conditionne le traitement d’une demande d’effacement.
• Il localise les consentements dans le modèle, plutôt que de les laisser éparpillés au fil des outils.

Ce dernier point mérite attention. Le consentement se rattache à une personne pour une finalité donnée sur un canal donné. Le modéliser correctement demande une entité dédiée, pas une simple case à cocher sur la fiche client. Les modèles qui traitent le consentement comme un attribut booléen se retrouvent en difficulté dès la première demande d’exercice de droits un peu précise.

La gouvernance des données s’appuie sur le même socle. Attribuer la responsabilité d’une donnée suppose de savoir de quelle donnée on parle, donc de disposer d’un modèle et d’un dictionnaire à jour.

Retour au Sommaire

• Le MCD décrit ce que vous gérez, pas comment vous le stockez. Il précède le choix de la technologie et lui survit.
• Quatre briques suffisent : entités, attributs, relations, cardinalités. Les cardinalités portent l’essentiel de vos règles de gestion.
• Séparez la personne de l’entité contractante. C’est l’arbitrage le plus structurant d’un modèle de Relation Clients. C’est aussi celui qui coûte le plus cher à corriger après coup.
• Posez la question du temps sur chaque attribut sensible. Un modèle qui n’historise rien interdit toute analyse d’évolution.
• Écartez les attributs sans cas d’usage. Chaque information modélisée devra être collectée, contrôlée puis justifiée.
• Faites valider le modèle par les équipes métier. Un MCD relu par la seule DSI n’a pas rempli sa fonction.
• La modélisation reste nécessaire avec une CDP. Sa fonction se déplace vers le vocabulaire commun et les règles d’identité.
• Tenez le modèle à jour. Un schéma périmé est plus dangereux qu’un schéma absent.

Retour au Sommaire

Quelle est la différence entre un MCD et un MLD ?

Le MCD décrit les objets métier et leurs liens sans considération technique. Le MLD traduit ce modèle en structures de données exploitables : tables, colonnes, clés primaires, clés étrangères. Le passage de l’un à l’autre suit des règles de transformation systématiques, notamment sur le traitement des relations à cardinalité multiple.

Quel outil utiliser pour créer un MCD ?

Les outils de modélisation les plus courants sont Looping, JMerise, Draw.io, Lucidchart ou dbdiagram. Le choix compte peu. Nous privilégions les outils qui produisent un export lisible et qui permettent une modification rapide en atelier, car un MCD se construit par itérations successives devant les équipes.

Le MCD est-il obligatoire dans un projet CRM ?

Aucune obligation formelle. Dans les faits, tout projet CRM ou RCU produit un modèle de données, explicite ou non. La question n’est pas de savoir si vous en aurez un, mais s’il sera documenté et validé plutôt que subi comme le résultat d’une suite de décisions non tracées.

Combien de temps faut-il pour construire un MCD ?

Sur un périmètre de Relation Clients, comptez deux à quatre ateliers d’une demi-journée avec les parties prenantes, puis quelques jours de formalisation et de dictionnaire. Le facteur déterminant n’est jamais la complexité technique : c’est le temps nécessaire pour aligner les définitions entre les directions concernées.

Qui doit participer à la construction du modèle ?

Les responsables opérationnels qui manipulent les données, un représentant de la DSI ou de l’équipe data, puis le porteur du projet. En présence de données personnelles sensibles, associez également votre référent conformité. Un groupe de six à huit personnes constitue un format de travail efficace.

Faut-il refaire un MCD lors d’un changement d’outil ?

Le modèle conceptuel n’a pas de raison de changer parce que vous changez de logiciel : votre activité reste la même. En revanche, un changement d’outil est le bon moment pour vérifier que le modèle reflète encore la réalité de votre organisation. Nous en profitons systématiquement pour le réviser.

Comment CustUp intervient-il sur la modélisation des données ?

Nous animons les ateliers de modélisation dans le cadre de nos missions de cadrage CRM, RCU et CDP. Nous produisons le modèle conceptuel, le dictionnaire de données associé puis nous accompagnons sa traduction technique avec vos équipes ou votre intégrateur. Sur les contextes B2B, nous appliquons une approche spécifique, détaillée sur notre page dédiée à la modélisation des données clients B2B.