Base de données MCD : comment modéliser vos données ?

Quand je démarre un nouveau projet de développement web sur-mesure, la toute première chose que je fais n’est jamais d’écrire du code. Je prends une feuille, un outil de modélisation, et je dessine un MCD. Après plus de 12 ans à concevoir des applications, je peux vous affirmer que la qualité d’une base de données se joue entièrement à cette étape de modélisation conceptuelle. Un MCD bancal, c’est un projet qui accumulera des problèmes de données pendant des années.

Pourtant, je constate que beaucoup de développeurs débutants, voire intermédiaires, sautent cette étape. Ils créent leurs tables SQL directement, ajoutent des colonnes au fil des besoins, et se retrouvent avec une base de données impossible à maintenir. Dans cet article, je vous explique concrètement comment modéliser vos données avec un MCD, de la théorie aux outils pratiques.

Qu’est-ce qu’un MCD en informatique ?

Le MCD, ou Modèle Conceptuel de Données, est un schéma visuel qui représente la structure des données d’un système d’information, indépendamment de toute technologie. Il décrit quelles données existent et comment elles sont liées entre elles, sans se préoccuper de la façon dont elles seront stockées physiquement.

Le MCD est issu de la méthode Merise, une approche de conception des systèmes d’information développée en France à la fin des années 1970. Cette méthode, encore largement enseignée dans les formations informatiques françaises comme le BTS SIO, reste une référence pour structurer des projets de bases de données relationnelles. Merise propose une séparation claire entre les données et les traitements, ce qui permet de modéliser chaque aspect indépendamment.

Concrètement, le MCD répond à une question simple : quelles informations mon application doit-elle gérer, et quelles relations existent entre elles ? Si vous développez un site e-commerce, par exemple, votre MCD va identifier que vous avez des clients, des commandes, des produits, et que ces éléments sont liés entre eux par des règles métier précises.

L’intérêt majeur du MCD est qu’il est compréhensible par tous les acteurs d’un projet, pas uniquement les développeurs. Un chef de projet, un client ou un analyste métier peut lire un MCD et valider que les données ont été correctement identifiées. C’est un outil de communication autant qu’un outil technique.

Les composants fondamentaux du MCD

Pour construire un MCD, vous devez maîtriser quatre éléments de base. Je vous les détaille avec des exemples concrets tirés de mes projets.

Les entités

Une entité représente un objet ou un concept du monde réel que l’on souhaite modéliser. On la dessine sous forme de rectangle. Exemples : Client, Produit, Commande, Facture, Utilisateur. Chaque entité possède un identifiant unique (souvent souligné dans le schéma) qui permet de distinguer chaque occurrence. Pour l’entité Client, ce sera par exemple un numéro client.

Les attributs

Les attributs sont les propriétés qui caractérisent une entité. Pour un Client : nom, prénom, email, téléphone, adresse. Pour un Produit : référence, libellé, prix unitaire, stock. Le choix des attributs doit refléter les besoins métier réels, pas ce que vous imaginez pouvoir servir un jour. J’ai vu trop de bases avec des dizaines de colonnes jamais remplies.

Les associations (ou relations)

Une association traduit un lien sémantique entre deux entités ou plus. On la représente par un ovale ou un losange relié aux entités concernées. Par exemple, l’association « Passer » relie Client et Commande. Une association peut elle-même porter des attributs : l’association « Contenir » entre Commande et Produit portera la quantité commandée.

Les cardinalités

Les cardinalités expriment les règles métier qui contraignent les associations. Elles se notent sous forme de couple (minimum, maximum) de chaque côté de l’association. Les valeurs les plus courantes sont :

• (0,1) : zéro ou une fois
• (1,1) : exactement une fois (obligatoire et unique)
• (0,n) : zéro ou plusieurs fois
• (1,n) : au moins une fois, possiblement plusieurs

Par exemple, un Client peut passer (0,n) commandes (il peut ne pas encore avoir commandé, ou en avoir passé plusieurs), tandis qu’une Commande est passée par (1,1) client (une commande appartient obligatoirement à un seul client). Ces cardinalités sont cruciales : elles déterminent la structure finale de votre base de données.

MCD, MLD, MPD : les trois niveaux de modélisation

La méthode Merise distingue trois niveaux de modélisation des données, chacun apportant un degré de précision supplémentaire. Comprendre cette progression est essentiel pour passer du concept à la réalisation.

Le passage du MCD au MLD suit des règles de transformation bien définies. Chaque entité devient une table. L’identifiant devient la clé primaire. Les associations de type (x,n)-(x,n) génèrent une table de liaison. Les associations de type (x,1)-(x,n) se traduisent par une clé étrangère dans la table côté (x,1). Cette étape est tellement mécanique que certains outils la réalisent automatiquement.

Le MLD (Modèle Logique de Données) se présente sous forme de schéma relationnel, avec la notation classique : NomTable(cle_primaire, attribut1, attribut2, #cle_etrangere). C’est à ce stade que l’on vérifie la normalisation des données (formes normales 1NF, 2NF, 3NF) pour éliminer les redondances.

Le MPD ajoute les spécificités du système de gestion de base de données choisi : types de données (VARCHAR, INT, DATETIME pour MySQL), index de performance, contraintes d’intégrité, et paramètres de stockage. C’est à ce niveau que l’on écrit le script SQL de création.

Construire un MCD étape par étape

Voici la méthode que j’applique systématiquement quand je modélise une base de données MCD pour un client. Elle fonctionne aussi bien pour un petit site vitrine que pour une application métier complexe.

Étape 1 : recueillir les besoins

Avant de dessiner quoi que ce soit, je mène un entretien avec le client ou l’équipe métier. L’objectif est d’identifier les données manipulées et les règles de gestion. Je pose des questions concrètes : « Un client peut-il avoir plusieurs adresses de livraison ? », « Un produit peut-il appartenir à plusieurs catégories ? », « Conservez-vous l’historique des prix ? ». Chaque réponse influence directement le MCD.

Étape 2 : identifier les entités

À partir des besoins, je liste tous les substantifs qui reviennent dans les descriptions métier. Client, Commande, Produit, Catégorie, Fournisseur. Je filtre ensuite : un substantif qui n’a pas d’attributs propres n’est probablement pas une entité. Une couleur de produit, par exemple, est un attribut, pas une entité (sauf si vous gérez un catalogue textile complexe).

Étape 3 : définir les attributs

Pour chaque entité, je liste les informations à stocker. Je m’assure que chaque attribut est élémentaire (non décomposable) et dépend directement de l’entité. Une adresse complète en un seul champ, c’est une erreur classique : il faut séparer numéro, rue, code postal, ville. Cela facilite les recherches et les traitements ultérieurs, notamment pour une base de données prospects.

Étape 4 : établir les associations et cardinalités

Je relie les entités entre elles en nommant chaque association avec un verbe : « Passer », « Contenir », « Appartenir ». Puis je détermine les cardinalités en me posant deux questions pour chaque côté : « Au minimum, combien de fois ? » et « Au maximum, combien de fois ? ». C’est l’étape qui demande le plus de rigueur et de validation métier.

Étape 5 : vérifier et itérer

Je relis le MCD en vérifiant trois points : pas de redondance d’information, pas d’association ternaire évitable, et cohérence des cardinalités avec les règles métier. Je présente ensuite le schéma au client pour validation avant de passer au MLD.

Exemple concret de MCD pour une base de données

Prenons un cas réel que j’ai traité récemment : la modélisation d’une base de données pour une librairie en ligne. Le client souhaitait gérer son catalogue, ses clients et ses commandes.

Voici les entités identifiées avec leurs attributs principaux :

• LIVRE (isbn, titre, prix, date_publication, nombre_pages)
• AUTEUR (id_auteur, nom, prenom, biographie)
• CATEGORIE (id_categorie, libelle, description)
• CLIENT (id_client, nom, prenom, email, mot_de_passe)
• COMMANDE (id_commande, date_commande, statut, montant_total)

Les associations et leurs cardinalités :

• AUTEUR Écrire LIVRE : un auteur écrit (1,n) livres ; un livre est écrit par (1,n) auteurs → associationMany-to-Many
• LIVRE Appartenir CATEGORIE : un livre appartient à (1,1) catégorie ; une catégorie contient (0,n) livres
• CLIENT Passer COMMANDE : un client passe (0,n) commandes ; une commande est passée par (1,1) client
• COMMANDE Contenir LIVRE : une commande contient (1,n) livres ; un livre peut figurer dans (0,n) commandes → association Many-to-Many avec attribut « quantité »

Ce MCD, une fois transformé en MLD, génère 7 tables : les 5 entités plus 2 tables de liaison (ECRIRE et CONTENIR) pour les associations Many-to-Many. L’association « Contenir » porte l’attribut quantité, qui se retrouve dans la table de liaison. Ce type de modélisation est identique à ce que vous feriez pour structurer une base de données prospect dans un contexte commercial.

Outils pour créer un diagramme MCD

Au fil des années, j’ai testé de nombreux outils pour dessiner mes MCD. Voici ceux que je recommande selon votre contexte.

Mon choix personnel pour les projets professionnels est Draw.io (désormais diagrams.net) combiné à un export vers MySQL Workbench pour la phase MLD/MPD. Pour l’enseignement et les exercices, Looping reste imbattable : c’est le seul outil gratuit qui gère nativement la notation Merise avec génération automatique du MLD et du script SQL. Si vous travaillez avec des données structurées dans un tableur, sachez qu’il est aussi possible de préparer vos données sur une base de données sur Excel avant de les importer.

Pour ouvrir un fichier MCD, il faut utiliser le logiciel qui l’a créé. Les fichiers .loo s’ouvrent avec Looping, les fichiers .mwb avec MySQL Workbench, et les fichiers .drawio avec Draw.io. Il n’existe pas de format universel de fichier MCD ; chaque outil utilise son propre format de sauvegarde.

MCD vs UML : quelle méthode choisir ?

C’est une question que l’on me pose régulièrement, surtout dans les formations. Le MCD (méthode Merise) et le diagramme de classes UML permettent tous deux de modéliser des données, mais leurs approches diffèrent.

Le MCD Merise sépare strictement les données des traitements. Il utilise la notation entité-association avec des cardinalités explicites (0,1 / 1,n / etc.). C’est une approche orientée données, particulièrement adaptée aux bases de données relationnelles. La méthode est très structurée, avec des règles de transformation claires vers le MLD puis le SQL, ce qui est décrit en détail dans la documentation de référence Merise sur CCM.

L’UML (Unified Modeling Language), développé dans les années 1990, est une approche orientée objet. Le diagramme de classes UML modélise des classes avec leurs attributs, méthodes et relations (héritage, composition, agrégation). Il est plus riche que le MCD car il intègre les comportements (méthodes), mais aussi plus complexe à lire pour un non-développeur.

Mon conseil : utilisez le MCD Merise quand votre objectif principal est de concevoir une base de données relationnelle, notamment dans un contexte français où Merise reste la norme académique et professionnelle. Privilégiez UML si vous travaillez en programmation orientée objet (Java, C#, PHP avec Doctrine) et que la base de données n’est qu’un aspect parmi d’autres de votre modélisation. Dans la pratique, sur mes projets Symfony, je commence souvent par un MCD rapide pour valider la structure des données avec le client, puis je passe directement aux entités Doctrine qui jouent le rôle de diagramme de classes.

Les erreurs fréquentes en modélisation MCD

En 12 ans de développement et de relecture de projets, j’ai identifié des erreurs récurrentes qui sabotent la qualité des bases de données. Voici celles que je rencontre le plus souvent.

Confondre entité et attribut. Une erreur classique consiste à stocker un pays comme un simple attribut texte d’une adresse, alors qu’il devrait être une entité à part avec un code ISO, un libellé et d’autres propriétés. La règle : si un « attribut » possède lui-même des attributs ou s’il est partagé entre plusieurs entités, c’est probablement une entité.

Oublier les cardinalités minimales. Beaucoup de débutants écrivent (1,n) partout sans réfléchir au minimum. Or la différence entre (0,n) et (1,n) est fondamentale : elle détermine si une contrainte NOT NULL sera posée en base. Un produit sans catégorie, est-ce possible dans votre métier ? La réponse change la cardinalité.

Créer des associations ternaires inutiles. Une association qui relie trois entités à la fois est souvent le signe d’une mauvaise décomposition. Dans la majorité des cas, une association ternaire peut être remplacée par une entité intermédiaire et deux associations binaires, ce qui rend le modèle plus lisible et plus facile à implémenter.

Négliger l’identifiant. Chaque entité doit avoir un identifiant unique et stable. Utiliser un nom de personne comme identifiant est une erreur : deux clients peuvent s’appeler Dupont. Préférez un identifiant technique (numéro auto-incrémenté ou UUID), même si un identifiant métier existe (comme un numéro de sécurité sociale).

Sur-modéliser. Un MCD doit refléter les besoins actuels, pas anticiper tous les scénarios possibles. J’ai vu des MCD avec 50 entités pour des applications qui n’en utilisaient que 15. Chaque entité inutile, c’est une table en base, des jointures en plus, et de la complexité de maintenance. Commencez simple, itérez ensuite.

Les types de bases de données et leur rapport au MCD

Le MCD tel que décrit par Merise est conçu pour les bases de données relationnelles, mais il est utile de comprendre les quatre grands types de bases de données pour situer le MCD dans le paysage technologique actuel.

Les bases relationnelles (SQL) constituent le cas d’usage principal du MCD. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server : toutes reposent sur le modèle relationnel théorisé par Edgar F. Codd en 1970. Les données sont stockées dans des tables avec des relations définies par des clés étrangères. Le MCD s’y applique parfaitement.

Les bases documentaires (NoSQL) comme MongoDB stockent des documents JSON sans schéma fixe. Le MCD n’est pas directement applicable, mais la réflexion sur les entités et leurs relations reste pertinente pour structurer vos collections. J’utilise souvent un MCD simplifié même pour mes projets MongoDB.

Les bases clé-valeur comme Redis sont utilisées pour le cache et les données temporaires. Aucun MCD n’est nécessaire ici : la structure est trop simple (une clé associée à une valeur).

Les bases graphe comme Neo4j modélisent des réseaux de nœuds et de relations. Le MCD peut servir de point de départ, mais la notation entité-association ne capture pas la richesse des graphes (relations typées, propriétés de relation, traversées). Pour ces bases, je recommande directement le diagramme de graphe.

Dans la grande majorité des projets web que je développe, la base relationnelle reste le choix par défaut, et le MCD l’outil de conception privilégié. Si vous gérez des données commerciales, la modélisation rigoureuse est d’autant plus importante pour une base de données de prospection efficace, comme le soulignent les recommandations de la CNIL en matière de gestion des données personnelles.