En bref
Un data mart est un sous-ensemble de l'entrepôt de données organisé autour d'un domaine métier unique — ventes, finance, marketing, RH. Il expose uniquement les données pertinentes pour ce domaine, dans un modèle dimensionnel adapté aux besoins de reporting de l'équipe propriétaire. Dans les architectures modernes avec dbt, un data mart est typiquement un ensemble de modèles SQL organisés dans un dossier thématique plutôt qu'une base de données physiquement séparée.
Définition complète
Un data mart est un sous-ensemble thématique d'un entrepôt de données, dédié à un domaine fonctionnel ou à une équipe précise de l'organisation. Contrairement à l'entrepôt de données central qui couvre l'ensemble des données de l'entreprise dans un modèle unifié, le data mart ne contient que les données pertinentes pour son domaine — et les expose dans une structure optimisée pour les besoins de reporting spécifiques de l'équipe qui en est responsable.
Le concept de data mart est apparu dans les années 1990 comme réponse à une tension réelle : les entrepôts de données centraux, avec leur modèle de données complet et leurs milliers de tables, étaient trop complexes pour être utilisés directement par les équipes métier. Les analystes commerciaux n'avaient pas besoin d'accéder aux données RH ou aux données de production pour faire leur reporting des ventes — et exposer l'ensemble de l'entrepôt créait de la confusion, des questions de gouvernance, et des performances dégradées.
Un data mart typique couvre un seul domaine : le mart des ventes (sales mart) contient les transactions, les objectifs commerciaux, les données de pipeline et les métriques par représentant et par territoire. Le mart financier (finance mart) contient les revenus, les coûts, les marges et les données budgétaires. Le mart marketing (marketing mart) contient les dépenses par canal, les leads générés, les taux de conversion et les coûts d'acquisition. Chaque mart est modélisé selon les concepts et le vocabulaire du domaine qu'il sert.
Dans les architectures de données modernes, le data mart a évolué d'une base de données physiquement séparée (avec ses propres serveurs, son propre moteur SQL, et ses propres processus d'alimentation) vers un concept principalement logique. Dans un projet dbt sur Snowflake ou BigQuery, un data mart est typiquement un dossier marts/ contenant des modèles SQL finaux, exposés aux outils de BI. La séparation physique a disparu ; la séparation logique et la propriété par domaine restent fondamentales.
Approches de conception : Inmon vs Kimball
Deux philosophies de conception des data marts ont structuré le débat en architecture de données depuis les années 1990.
Inmon (top-down) vs Kimball (bottom-up)
| Dimension | Inmon (top-down) | Kimball (bottom-up) |
|---|---|---|
| Point de départ | Entrepôt central normalisé (3NF) | Data marts thématiques (star schema) |
| Délai initial | Long (12 – 24 mois) | Court (3 – 6 mois par mart) |
| Cohérence globale | Forte (un seul modèle source) | Dépend des dimensions conformes |
| Proximité métier | Modérée | Forte (chaque mart parle le langage du domaine) |
L'approche Kimball est aujourd'hui dominante dans la pratique, notamment via dbt qui encourage un modèle de staging → intermediate → marts qui suit exactement la logique Kimball. Le concept clé de Kimball qui garantit la cohérence entre les data marts est celui des dimensions conformes : une dimension "Client" qui apparaît dans le mart des ventes et dans le mart financier doit avoir la même définition, les mêmes attributs et les mêmes clés dans les deux contextes — sinon les rapports qui croisent les deux domaines produisent des chiffres inconsistants.
Exemple concret
Une entreprise française de logiciels de gestion (SaaS B2B, 8 M€ d'ARR, 45 collaborateurs) a construit trois data marts sur son entrepôt de données Snowflake, alimentés par des pipelines dbt.
Le mart des ventes (marts/sales/) contient six tables finales : les contrats signés par période et par représentant, les opportunités actives avec leur stade et leur date de clôture estimée, les quotas par trimestre et par territoire, les taux d'atteinte, le pipeline pondéré, et la vélocité de vente. Ces tables alimentent directement les dashboards Tableau utilisés par l'équipe commerciale et le directeur des ventes.
Le mart financier (marts/finance/) contient les revenus récurrents par mois (MRR, ARR, churn MRR, expansion MRR), les marges brutes par produit, les dépenses par catégorie et par département, et les projections de trésorerie à 90 jours. Ce mart est la source de vérité pour le reporting mensuel du DAF et du CODIR. Le coût de construction initiale a été de 45 jours-homme d'un ingénieur data senior ; la maintenance mensuelle représente environ 3 jours-homme.
Le mart marketing (marts/marketing/) est plus récent (6 mois). Il consolide les dépenses publicitaires depuis Google Ads, LinkedIn Ads et les réseaux sociaux via Fivetran, les leads générés par source depuis HubSpot, et les taux de conversion par canal. Il calcule le coût par lead qualifié et le CAC payant par canal pour la semaine, le mois et le trimestre. La dimension "Source/Canal" est une dimension conforme partagée avec le mart des ventes — ce qui permet de tracer le parcours complet d'une opportunité depuis la dépense marketing jusqu'à la signature du contrat.
Analyse approfondie
Le data mart résout un problème fondamental de démocratisation des données : rendre l'analyse accessible aux équipes métier sans leur imposer la complexité de l'entrepôt de données complet. Un entrepôt de données mature peut contenir plusieurs centaines de tables, couvrant l'ensemble des processus de l'entreprise. Obliger un analyste commercial à naviguer dans cet espace pour construire un rapport de performance des représentants est une source de friction majeure — et un vecteur d'erreurs. Le data mart réduit l'espace à explorer au seul domaine pertinent, avec un vocabulaire aligné sur celui de l'équipe.
La question de la propriété est centrale dans la conception des data marts. Chaque mart doit avoir un propriétaire clairement identifié — typiquement l'équipe qui en est la principale utilisatrice, avec un référent data qui en assure la maintenance. Sans propriétaire défini, les marts se dégradent : les définitions deviennent obsolètes, les nouvelles dimensions ne sont pas ajoutées, et les utilisateurs contournent le mart pour aller interroger directement les tables sources — ce qui produit des chiffres inconsistants entre les équipes.
La question des dimensions conformes mérite une attention particulière. Dans une organisation avec plusieurs data marts, la tentation est de définir les dimensions indépendamment dans chaque mart pour aller plus vite. C'est une dette technique coûteuse : dès qu'une question croise deux domaines — "quel est le revenu par client acquis via tel canal marketing ?" — les réponses divergent si la dimension "Client" n'est pas définie de manière conforme. Les réunions de CODIR où les équipes ventes et finance arrivent avec des chiffres de revenus différents sont souvent la conséquence directe de dimensions non conformes entre les marts.
La comparaison entre data mart physique et data mart logique est importante pour les décisions d'architecture. Un data mart physique — une base de données séparée avec ses propres tables et ses propres processus d'alimentation — offre l'isolation maximale et des performances prévisibles, mais multiplie les coûts d'infrastructure, les processus de synchronisation, et les risques de dérive entre le mart et l'entrepôt source. Un data mart logique — des modèles SQL dans un projet dbt, exposant des vues ou des tables matérialisées dans le même entrepôt — est plus économique, plus facile à maintenir, et garantit une cohérence native avec le modèle central. Pour les nouvelles architectures cloud, le mart logique est devenu le standard de facto.
Pour les directeurs opérationnels — COOs, DAFs, directeurs commerciaux — le data mart est l'architecture de données qui détermine directement la qualité et la fiabilité des indicateurs disponibles dans leurs outils de pilotage. Un mart des ventes bien conçu, avec des dimensions conformes et un propriétaire actif, produit des chiffres de pipeline et de performance commerciale sur lesquels les décisions peuvent être prises avec confiance. Un mart mal gouverné, avec des définitions obsolètes ou des dimensions non synchronisées, produit des réunions où personne n'est sûr du bon chiffre à utiliser. La question opérationnelle pertinente est moins "avons-nous un data mart ?" que "nos data marts sont-ils maintenus, documentés et cohérents avec nos définitions métier actuelles ?"
Erreurs fréquentes
- ✗
Construire des marts sans dimensions conformes. Chaque data mart créé indépendamment avec sa propre définition des entités partagées — Client, Produit, Période — génère des incohérences dès que des analyses inter-domaines sont nécessaires. La définition des dimensions conformes doit précéder la construction des marts individuels, même si elle retarde légèrement le premier livrable. C'est un investissement en cohérence organisationnelle, pas une charge technique.
- ✗
Créer des marts sans propriétaire défini. Un data mart orphelin — construit pour un besoin initial puis laissé sans propriétaire actif — se dégrade inévitablement. Les nouvelles sources ne sont pas intégrées, les définitions s'écartent des pratiques métier actuelles, et les utilisateurs perdent confiance dans les chiffres. Chaque mart doit avoir un responsable fonctionnel (côté métier) et un responsable technique (côté data) avec des engagements clairs sur la maintenance.
- ✗
Proliférer les marts sans gouvernance. La facilité de création de data marts logiques dans dbt peut conduire à une prolifération incontrôlée : chaque équipe crée ses propres modèles, avec ses propres définitions, sans coordination. On se retrouve alors avec un entrepôt contenant vingt définitions différentes du "chiffre d'affaires" selon le mart consulté. Une politique de gouvernance des marts — catalogue, propriétaires, processus de validation des nouvelles définitions — est nécessaire dès que l'organisation dépasse deux ou trois équipes utilisatrices.
Comment Fairview s'appuie sur vos data marts
Si votre organisation dispose de data marts bien modélisés — un mart des ventes avec les revenus par canal et par représentant, un mart financier avec les marges par produit et les dépenses par département, un mart marketing avec les coûts d'acquisition par canal — Fairview peut s'y connecter directement via des connecteurs SQL standards. Les modèles dimensionnels déjà construits par votre équipe data alimentent les tableaux de bord et les alertes opérationnels de Fairview sans duplication.
Pour les organisations qui ne disposent pas encore de data marts formalisés, Fairview construit ses propres vues analytiques directement depuis vos sources opérationnelles — CRM, comptabilité, ERP — sans dépendre d'une infrastructure analytique préexistante. Cela signifie que Fairview est opérationnel immédiatement, quelle que soit la maturité de votre architecture de données. À mesure que votre équipe data construit des marts formalisés, Fairview peut migrer vers ces sources consolidées pour bénéficier des modèles curatés.
La valeur ajoutée de Fairview par rapport à un data mart seul réside dans la couche d'action : Fairview ne se contente pas d'exposer les indicateurs issus de vos marts, il génère des Next Best Actions — alertes sur les dérives, recommandations contextuelles, détection des anomalies — qui transforment les chiffres en décisions concrètes pour les équipes opérationnelles.
Questions fréquentes
Quelle est la différence entre un data mart et un entrepôt de données ?
Un entrepôt de données est le référentiel analytique central couvrant l'ensemble des données de l'organisation dans un modèle unifié. Un data mart est un sous-ensemble thématique dédié à un domaine fonctionnel précis (ventes, finance, marketing). L'entrepôt est la source de vérité globale ; le data mart est la vue simplifiée et optimisée pour un domaine spécifique. En pratique moderne, les data marts sont souvent des dossiers logiques dans un projet dbt plutôt que des bases de données physiquement séparées.
Quelle est la différence entre l'approche Inmon et l'approche Kimball ?
Bill Inmon préconise une approche descendante : on construit d'abord un entrepôt centralisé normalisé (3NF), puis on dérive des data marts thématiques. Ralph Kimball préconise une approche ascendante : on construit des data marts dimensionnels directement, avec des dimensions conformes qui permettent de les fédérer. L'approche Kimball est plus rapide à déployer et plus proche des besoins métier ; l'approche Inmon produit une architecture plus cohérente à long terme mais avec un délai initial plus long.
Les data marts sont-ils encore utilisés dans les architectures modernes ?
Oui, mais sous une forme principalement logique. Dans les architectures modernes avec dbt, un data mart est typiquement un ensemble de modèles SQL dans un dossier thématique (marts/sales, marts/finance, marts/marketing), exposant des tables agrégées pour les outils de BI. La séparation physique en bases de données distinctes a largement disparu, mais le principe d'organisation thématique et la propriété par domaine restent fondamentaux pour la maintenabilité.
Comment Fairview s'appuie-t-il sur les data marts existants ?
Si votre organisation dispose de data marts bien modélisés, Fairview peut s'y connecter directement via des connecteurs SQL standards pour en extraire les indicateurs opérationnels. Fairview peut également construire ses propres vues analytiques depuis vos sources directes (CRM, comptabilité, ERP) sans dépendre d'un data mart préexistant, ce qui le rend opérationnel immédiatement, même sans infrastructure analytique mature.
Découvrez-le dans Fairview
Des indicateurs opérationnels fiables, depuis vos données existantes.
Démo en direct de 25 minutes. Fairview se connecte à vos data marts ou directement à vos sources opérationnelles.