Modélisation dimensionnelle :
les 5 erreurs classiques à éviter

La modélisation dimensionnelle est le socle de tout Data Warehouse performant. Bien faite, elle offre des requêtes rapides, une lecture intuitive des données et une évolutivité à long terme. Mal faite, elle devient un cauchemar de maintenance, de performances dégradées et de chiffres incohérents d'un rapport à l'autre.

Après des dizaines de projets Data Warehouse au Maroc — finance, hôtellerie, logistique, télécoms — voici les cinq erreurs que nous rencontrons systématiquement, et comment les éviter.

Erreur n°1 : Négliger la table de dates (Dim_Date)

C'est l'erreur la plus fréquente et la plus coûteuse. Beaucoup de projets utilisent directement des champs date dans les tables de faits, sans Dim_Date dédiée. Résultat : impossible de filtrer par semaine fiscale, par période Ramadan, par saison touristique ou par exercice comptable marocain.

La Dim_Date doit contenir au minimum : Jour, Semaine, Mois, Trimestre, Année, Jour de la semaine, Indicateur Jour Férié (calendrier marocain), Période fiscale. Elle doit couvrir l'intégralité de la plage historique plus 2 à 3 ans dans le futur.

-- Exemple SQL Server : génération automatique Dim_Date
WITH CTE_Dates AS (
    SELECT CAST('2015-01-01' AS DATE) AS DateVal
    UNION ALL
    SELECT DATEADD(DAY, 1, DateVal)
    FROM CTE_Dates
    WHERE DateVal < '2030-12-31'
)
SELECT
    CONVERT(INT, FORMAT(DateVal,'yyyyMMdd')) AS ID_Date,
    DateVal,
    DAY(DateVal) AS Jour,
    MONTH(DateVal) AS Mois,
    YEAR(DateVal) AS Annee,
    DATEPART(QUARTER, DateVal) AS Trimestre,
    DATENAME(WEEKDAY, DateVal) AS Jour_Semaine
FROM CTE_Dates
OPTION (MAXRECURSION 10000);

Erreur n°2 : Créer des tables de faits trop larges

On voit souvent des tables de faits qui contiennent 80 à 120 colonnes : des métriques, des attributs descriptifs, des codes libellés, des champs calculés redondants. C'est le signe d'une confusion entre table de faits (métriques numériques + clés étrangères) et table de dimensions (attributs descriptifs).

Règle d'or : une table de faits ne doit contenir que des mesures quantifiables (montants, quantités, durées, comptages) et des clés étrangères vers les dimensions. Tout attribut descriptif (libellé produit, statut client, région) appartient à une dimension.

Une table de faits bien structurée pour la finance ressemble à :

Fait_Transactions (
    ID_Date       INT FK,
    ID_Compte     INT FK,
    ID_Tiers      INT FK,
    ID_Devise     INT FK,
    Montant_Debit  DECIMAL(18,2),
    Montant_Credit DECIMAL(18,2),
    Solde_Courant  DECIMAL(18,2)
)

Erreur n°3 : Ignorer les Slowly Changing Dimensions (SCD)

Un client change de région. Un produit change de catégorie. Un commercial change d'équipe. Si votre dimension n'est pas conçue pour gérer ces changements, vous perdrez l'historique ou vous contaminerez les données passées avec des valeurs actuelles.

Il existe trois approches principales :

SCD Type 1 — Écrasement : On met à jour directement la valeur. Adapté quand l'historique ne compte pas (correction d'une faute de frappe, mise à jour d'un code postal).

SCD Type 2 — Historisation : On ajoute une nouvelle ligne avec des colonnes Date_Debut, Date_Fin et Indicateur_Actif. Permet de savoir quelle était la situation à n'importe quelle date. C'est la méthode recommandée pour les attributs à fort impact analytique (région client, catégorie produit).

SCD Type 3 — Colonne précédente : On ajoute une colonne "valeur précédente". Simple mais limité à un seul changement historique.

Erreur n°4 : Choisir des clés métier comme clés de substitution

Utiliser le numéro de compte, le code client ou la référence produit comme clé primaire dans les dimensions est tentant — c'est lisible et intuitif. Mais c'est une erreur d'architecture.

Les clés métier changent (fusion de systèmes, migration ERP, changement de codification). Les clés de substitution (surrogate keys) — des entiers auto-incrémentés sans signification métier — restent stables pour toujours et accélèrent les jointures.

La clé métier reste présente dans la dimension en tant qu'attribut interrogeable, mais ne sert jamais de clé d'intégration avec les tables de faits.

Erreur n°5 : Négliger la granularité de la table de faits

La granularité définit ce que représente une ligne dans la table de faits. C'est la décision la plus structurante du modèle, et elle doit être documentée explicitement dès le début du projet.

Une granularité imprécise provoque des doubles comptages ou des agrégations impossibles. Par exemple, une table de faits ventes à la granularité "commande" (une ligne par commande) ne peut pas répondre à "quelle est la marge par ligne de produit" sans restructuration. Il aurait fallu descendre à la granularité "ligne de commande".

Règle : choisissez toujours la granularité la plus fine disponible. Il est facile d'agréger des données fines vers le haut (GROUP BY mois). Il est impossible de désagréger des données déjà consolidées.

Conclusion

Ces cinq erreurs ne sont pas des détails techniques — ce sont des choix d'architecture qui conditionnent la fiabilité de tous vos rapports pour les années à venir. Un Data Warehouse bien modélisé dès le départ coûte moins cher à maintenir, répond plus vite aux requêtes et s'adapte à l'évolution du business sans refonte complète.

Vous concevez un Data Warehouse ou souhaitez auditer votre modèle existant ? L'équipe ANAILYNIS intervient sur toute la chaîne — modélisation dimensionnelle, ETL Oracle ODI, reporting Power BI. Contactez-nous.