Modélisation et architecture

Le modèle de données est la décision la plus durable d'un projet data : le code se réécrit, un rapport se refait, mais un modèle mal pensé se propage dans tous les rapports qui le…

Guide≈ 8 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : MOD

Pourquoi ce thème#

Le modèle de données est la décision la plus durable d'un projet data : le code se réécrit, un rapport se refait, mais un modèle mal pensé se propage dans tous les rapports qui le consomment et se répare au prix d'une migration. Un bon modèle exprime le métier (on y lit les entités, les grains et les règles), absorbe le changement (nouvelle source, nouvel attribut, historisation) et reste explicable à un nouvel arrivant. Un mauvais modèle se reconnaît à des symptômes quotidiens : chaque nouveau rapport exige un nouveau traitement, les mêmes jointures sont réécrites partout, l'historique manque quand on en a besoin. Ce thème traite de la conduite de la modélisation (décisions, conventions, évolution, migration). Le modèle sémantique d'un rapport (relations, mesures, RLS) est traité côté BI : matrice BI — modèle sémantique.

Ce que mesure le thème#

Axe : du modèle accidentel au modèle conçu, gouverné et évolutif.
Indicateur clé : coût d'un changement type (ajouter un attribut, une source, une dimension) en jours, et part du modèle respectant les conventions.
Unité : jours pour intégrer un attribut ; % d'objets conformes aux conventions ; nombre de ruptures de consommateurs par évolution.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Accidentel	Chaque rapport reçoit les données dont il a besoin, souvent par une table dédiée.	Ajout d'un attribut : plusieurs jours, plusieurs endroits
2	Partagé	Les entités principales (client, produit, date) sont communes à plusieurs rapports.	Dimensions communes sur les 3–5 sujets principaux
3	Conçu	Le modèle suit une méthode (en étoile, par domaine) avec grain explicite et conventions écrites.	≥ 90 % des tables avec grain documenté ; ajout d'attribut < 1 jour
4	Évolutif	Le modèle absorbe l'historisation, les changements de source et de règles sans casser les consommateurs.	Évolution sans rupture ≥ 90 % ; historique reconstituable
5	Adaptatif	Le modèle évolue par petits pas contrôlés, avec migration automatisée et mesure de son coût d'évolution.	Ajout d'une dimension en heures ; dette de modèle suivie

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PD-MOD-1.1	Un schéma physique existe et se consulte (diagramme ou script).	Export du schéma daté.
PD-MOD-1.2	Les tables ont des clés primaires déclarées ou identifiables.	Contrôle des PK : liste des tables sans clé.
PD-MOD-1.3	Les sources sont distinguées des tables d'exposition (zones ou schémas).	Séparation visible dans les noms de schémas.
PD-MOD-1.4	La date et le calendrier sont traités par une table unique.	Table de dates utilisée par les rapports.
PD-MOD-2.1	Les dimensions principales sont partagées entre rapports (pas de copie par rapport).	Même table utilisée par ≥ 2 rapports.
PD-MOD-2.2	Le grain de chaque table de faits est écrit (« une ligne par relevé et par produit »).	Description de table avec phrase de grain.
PD-MOD-2.3	Des conventions de nommage existent (préfixes, casse, abréviations) et sont suivies sur les nouveautés.	Document de conventions ; revue d'un échantillon.
PD-MOD-2.4	Les clés de substitution et les clés métier sont distinguées.	Schéma montrant les deux types de clé.
PD-MOD-3.1	Le modèle suit une méthode explicite (étoile à la Kimball, par domaine…) décrite en une page.	Document d'architecture ; ouvrage de référence cité (ex. The Data Warehouse Toolkit).
PD-MOD-3.2	Les relations de faits à dimensions sont déclarées et leur activité décidée par règle (jointures, rôles).	Matrice de faits × dimensions (bus matrix).
PD-MOD-3.3	L'historisation est décidée par attribut (écrasé, historisé, versionné) et documentée.	Table des attributs avec type d'historisation.
PD-MOD-3.4	Toute décision de modèle importante est consignée (décision, alternatives, raison).	Journal de décisions d'architecture.
PD-MOD-4.1	L'ajout d'une source ou d'un attribut ne casse aucun consommateur (rétrocompatibilité).	Test de non-régression sur les objets exposés.
PD-MOD-4.2	Une couche d'exposition stable isole les rapports des tables internes.	Vues ou schéma d'exposition contractuels (CTR).
PD-MOD-4.3	L'historique des valeurs de référence est reconstituable à une date donnée.	Requête « état au jour J » validée sur un cas.
PD-MOD-4.4	Les migrations de modèle sont scriptées, rejouables et testées sur copie.	Scripts de migration versionnés avec compte rendu de test.
PD-MOD-5.1	Le coût d'évolution du modèle est mesuré (délai d'un changement type).	Série de mesures sur ≥ 6 changements.
PD-MOD-5.2	La dette de modèle (doublons, écarts aux conventions) est inventoriée et réduite.	Inventaire avec tendance trimestrielle.
PD-MOD-5.3	Des revues d'architecture périodiques confrontent le modèle aux usages réels (tables jamais lues, jointures fréquentes).	Compte rendu de revue basé sur des statistiques d'usage.
PD-MOD-5.4	Un changement de moteur ou d'hébergement est possible sans refonte du modèle logique.	Exercice de portage ou analyse documentée.

Lecture détaillée par niveau#

🟢 Niveau 1 — Accidentel#

Signes : une table par rapport ; des jointures différentes pour le même concept ; des noms incohérents.
Gain : livraison rapide du premier rapport.
Ne garantit pas : la réutilisation ; la cohérence des chiffres entre rapports.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Partagé#

Signes : des dimensions communes ; le grain est dit à l'oral ou dans des commentaires ; des conventions apparaissent.
Gain : deux rapports sur le même sujet concordent plus souvent.
Ne garantit pas : un modèle compréhensible par un nouvel arrivant.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Conçu#

Signes : bus matrix, grain écrit, historisation décidée attribut par attribut, journal de décisions.
Gain : un attribut s'ajoute sans réfléchir à la structure ; les débats se tranchent par la méthode.
Ne garantit pas : la tenue à l'épreuve d'un changement de source majeur.
Difficulté : 3/5 · Effort : 3/5.

🧪 Exemple

Un datamart de force de vente passe de « une table large de relevés » à une étoile : faits Releve (grain : un produit relevé par visite), dimensions Date, PointDeVente, Produit, Utilisateur. Une bus matrix montre que Produit est partagée avec les ventes. L'ajout d'un attribut « pilier » sur Produit passe de trois jours (modification de 6 rapports) à une demi-journée (une colonne, un test).

🟡 Niveau 4 — Évolutif#

Signes : une couche d'exposition stable ; l'historique se reconstitue ; les migrations se rejouent sur copie.
Gain : le modèle peut changer sans prévenir tout le monde.
Ne garantit pas : la pertinence métier (un bon modèle du mauvais sujet reste inutile).
Difficulté : 4/5 · Effort : 4/5.

-- Dimension à historisation par plage de validité (type 2), requête « état au jour J »
SELECT P.PRD_COD, P.PRD_LIB, P.PRD_PILIER
FROM   [dim].[Produit] AS P WITH (NOLOCK)
WHERE  @JourJ >= P.DATE_DEBUT_VALIDITE
  AND  @JourJ <  ISNULL(P.DATE_FIN_VALIDITE, '9999-12-31');

🔴 Niveau 5 — Adaptatif#

Signes : le coût de changement est une courbe suivie ; la dette de modèle est budgétée ; l'usage guide l'architecture.
Gain : une plateforme qui reste modifiable à 10 fois sa taille initiale.
Ne garantit pas : l'absence de refonte ; un changement de paradigme (streaming, lakehouse) peut rester coûteux.
Difficulté : 5/5 · Effort : 4/5.

Atteinte partielle et notation#

Vérifiez les jalons sur les cinq tables de faits principales et leurs dimensions. Un jalon de modèle se note sur la proportion d'objets conformes : 1 si ≥ 90 %, 0,5 si 50–90 %, 0 en dessous. Les jalons 5.x se notent sur des preuves de mesure, pas sur une intention.

Un « 5 partiel » : le coût de changement est mesuré sur dix évolutions (5.1 à 1), la dette est inventoriée sans trajectoire (5.2 à 0,5), la revue d'usage est annuelle et l'analyse de portabilité n'existe pas (5.3 à 0,5 ; 5.4 à 0).

⚠️ Piège

L'étoile de façade : des noms DIM_/FACT_ posés sur des tables aux grains mélangés. Symptôme : des mesures qui doublent après jointure. Cause : grain non écrit. Remède : la phrase de grain est un prérequis de toute table de faits.

⚠️ Piège

Renommer une colonne consommée : le consommateur casse même si la table est correcte. Livrez d'abord la nouvelle colonne, migrez les consommateurs, retirez l'ancienne (voir CTR niveau 4).

💡 Astuce d'expert

Un identifiant de substitution stable par dimension rend possible un futur chargement différentiel et protège les relations des rapports quand la clé métier change.

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage	Leviers possibles
1 → 2	Isoler un jeu de dimensions communes ; écrire une page de conventions.
2 → 3	Dresser la bus matrix ; écrire la phrase de grain de chaque fait ; tenir un journal de décisions.
3 → 4	Introduire la couche d'exposition ; scripter les migrations ; tests de non-régression (REC).
4 → 5	Mesurer le coût d'évolution ; revoir l'usage réel (tables jamais lues, jointures fréquentes).

Pièges transverses : (1) Faux positif — un modèle « propre » qui ne répond pas aux questions réelles ; relisez-le avec la liste des décisions de VAL. (2) Goodhart — viser « 100 % de tables conformes » encourage à renommer plutôt qu'à concevoir. (3) Sur-ingénierie — normaliser à l'extrême pour un volume modeste.

🤖 IA

Utile pour proposer une étoile depuis un schéma source, générer des scripts de migration ou détecter des écarts de convention. L'IA ignore le grain métier voulu et peut proposer un modèle correct formellement mais sans rapport avec les décisions à éclairer ; la phrase de grain reste humaine.

Voir aussi#

Même matrice : 04 Contrats · 06 DataOps · 12 Métadonnées · 03 Qualité · README
Autres matrices : DL — architecture et conception · DL — dette technique · BI — modèle sémantique · BI — performance et volumétrie
Pratique : méthodes spécifiques data · SQL Server SaaS — vue d'ensemble · comparatif OneLake / SQL Server · GDS et données SQL/BI
Glossaire · Notation

✻ Rédigé par Claude Sonnet 5.5