On lance un projet web, on code les premiers écrans, et trois mois plus tard on découvre qu’un utilisateur peut avoir plusieurs adresses de livraison, que les commandes doivent stocker un historique de statuts, et que la table « produit » mélange articles physiques et abonnements. Le schéma SQL bricolé au fil de l’eau ne tient plus. C’est exactement le scénario qu’un MCD diagram posé en amont permet d’éviter.
Contraintes RGPD et privacy by design dans le MCD d’une application web
Depuis 2023, les guides CNIL et RGPD demandent que la protection des données soit intégrée dans la modélisation elle-même, pas uniquement dans le code applicatif. En pratique, cela change la structure du MCD dès les premières entités.
Sur les projets web récents, on retrouve systématiquement des choix de conception liés à la conformité :
- La séparation entre identifiants techniques (clé primaire auto-incrémentée) et données personnelles (email, nom, téléphone), stockées dans des entités distinctes pour faciliter la pseudonymisation.
- Des attributs dédiés au cycle de vie de chaque donnée : date de création, date de purge prévue, indicateur de pseudonymisation. Ces champs figurent directement dans le modèle conceptuel, pas dans un document annexe.
- Des entités spécifiques pour journaliser les accès et les traitements, afin de pouvoir démontrer la conformité en cas de contrôle.
Poser ces contraintes au niveau du MCD diagram évite de devoir restructurer la base six mois après la mise en production, quand un audit RGPD tombe. Intégrer le privacy by design dans le MCD dès le départ réduit aussi le coût de mise en conformité, parce que les migrations de schéma sur une base en production sont toujours plus risquées qu’un ajustement sur un diagramme.
MCD et Domain-Driven Design : aligner le modèle conceptuel sur les bounded contexts
Depuis 2024, la tendance dans les applications web est d’aligner le MCD sur les principes du Domain-Driven Design. Le modèle conceptuel de données n’est plus vu comme un simple schéma entité-association à plat. On le découpe en bounded contexts, chaque contexte regroupant les entités et relations d’un périmètre métier cohérent.
Prenons une application e-commerce. Le bounded context « Catalogue » contient les entités Produit, Catégorie et leurs attributs (nom, description, prix affiché). Le bounded context « Commande » a ses propres entités : Commande, LigneCommande, Statut. Le produit y apparaît sous forme de référence (identifiant + prix au moment de l’achat), pas comme l’entité complète du catalogue.
Pourquoi ce découpage change la qualité du schéma SQL généré
Un MCD monolithique pousse à créer des relations entre toutes les entités. On se retrouve avec des jointures sur six tables pour afficher une page. Découper le MCD par bounded context limite les dépendances et produit un schéma SQL plus lisible, plus performant, et plus facile à faire évoluer.
Les retours varient sur le niveau de granularité idéal, mais le principe reste le même : chaque contexte doit pouvoir évoluer indépendamment. Si on ajoute un système de fidélité, on crée un nouveau bounded context avec ses propres entités (PointsFidelite, RegleGain, HistoriqueUtilisation) sans toucher au MCD du catalogue.
Entités, attributs et relations : les erreurs de modélisation fréquentes sur le web
Sur le terrain, les erreurs de MCD les plus coûteuses ne sont pas des oublis d’entités. Ce sont des choix de cardinalité mal posés et des attributs mal placés.
Cardinalités mal définies entre entités
L’exemple classique : on modélise la relation entre Utilisateur et Adresse en 1-1 parce que « pour l’instant, chaque utilisateur a une seule adresse ». Trois sprints plus tard, le client demande la gestion multi-adresses. Toujours modéliser la cardinalité maximale réaliste, pas celle du MVP. Passer d’une relation 1-1 à 1-N en production implique de créer une table, migrer les données existantes, et adapter toutes les requêtes.
Attributs fourre-tout dans une entité
On voit souvent une entité « Utilisateur » avec un attribut « type » (client, admin, vendeur) et des colonnes conditionnelles (numéro SIRET pour les vendeurs, niveau d’accès pour les admins). Le MCD doit refléter cette réalité par une spécialisation : une entité mère Utilisateur, des entités filles Client, Administrateur, Vendeur. Un attribut qui ne concerne qu’un sous-type ne doit pas figurer dans l’entité parente.
Passer du MCD au schéma SQL : ce que le diagramme ne montre pas
Le MCD diagram représente les données et leurs relations à un niveau conceptuel. Le passage au modèle logique puis au SQL introduit des éléments absents du MCD : index, contraintes d’unicité, types de données précis, tables de jointure pour les relations N-N.
Sur une application web, deux points méritent une attention particulière lors de cette traduction :
- Les tables de jointure générées pour les associations N-N doivent souvent porter des attributs propres. Par exemple, la relation « Utilisateur participe à Projet » génère une table utilisateur_projet, mais cette table a besoin d’un attribut « rôle » et d’une « date d’ajout ». Si ces attributs n’ont pas été anticipés dans le MCD (en tant qu’association porteuse d’attributs), on les découvre trop tard.
- Les contraintes d’unicité composites, fréquentes dans les systèmes web (un seul avis par utilisateur et par produit, une seule inscription par email et par événement), doivent être identifiées dès le MCD sous forme de règles de gestion annotées.
- Les index de performance ne figurent pas dans le modèle conceptuel, mais le MCD aide à anticiper les candidats évidents : toute clé étrangère dans une relation fréquemment interrogée devrait recevoir un index.
Le MCD ne remplace pas le travail de conception physique. Il le prépare. Un diagramme bien construit rend la traduction en SQL quasi mécanique, là où un MCD bâclé produit un schéma qu’on passe des semaines à corriger.
Structurer les données d’une application web sans MCD revient à coder sans spécifications. On avance vite les premières semaines, puis chaque évolution fonctionnelle coûte de plus en plus cher en refontes de base. Le temps passé sur le diagramme en amont se récupère à chaque migration évitée, à chaque requête SQL qui reste lisible six mois après sa rédaction.
