En bref
La table de faits est le cœur du modèle dimensionnel : elle enregistre chaque événement métier mesurable et relie les dimensions qui en décrivent le contexte. Son grain — la définition précise de ce qu'une ligne représente — doit être déclaré avant toute conception. Des grains mixtes produisent des agrégations incorrectes ; des mesures mal classifiées (additives, semi-additives ou non additives) génèrent des rapports trompeurs dans tous les outils de BI.
Définition complète
La table de faits (fact table en anglais) est la table centrale d'un modèle dimensionnel. Elle enregistre les événements métier mesurables — une transaction de vente, une connexion utilisateur, une page vue, une ligne de commande — sous forme de lignes, chacune accompagnée de ses mesures numériques : montant, quantité, durée, comptage. Elle est reliée aux tables de dimensions par des clés étrangères qui fournissent le contexte descriptif de chaque événement.
Sur le plan physique, la table de faits est caractérisée par sa forme : elle est longue (des millions à des milliards de lignes selon le volume d'activité) et étroite (un petit nombre de colonnes — les clés étrangères vers les dimensions et les colonnes de mesures). Cette structure contraste avec les tables de dimensions, qui sont courtes et larges. Dans un schéma en étoile, la table de faits occupe le centre du diagramme, entourée des tables de dimensions qui lui sont reliées.
Le concept de table de faits a été formalisé par Ralph Kimball dans sa méthodologie du modèle dimensionnel, qui reste la référence de l'industrie pour la conception des entrepôts de données analytiques. La distinction entre faits et dimensions — entre ce qui est mesuré et ce qui décrit le contexte de la mesure — est la décision de conception la plus fondamentale en Business Intelligence.
Comment l'implémenter
La conception d'une table de faits commence par la déclaration du grain — avant tout le reste. Le grain répond à la question : « Que représente exactement une ligne dans cette table ? » La réponse doit être précise et non ambiguë. « Une ligne par transaction » est un grain clair. « Une ligne par commande » peut être ambigu si une commande contient plusieurs lignes d'articles — dans ce cas, le grain correct est souvent « une ligne par ligne d'article de commande ».
Structure type d'une table de faits transactionnelle
Colonnes de clés étrangères : date_key, client_key, produit_key, canal_key — une par dimension reliée.
Colonnes de mesures : montant_ht, quantite, remise_pct, marge_brute — les faits numériques de l'événement.
Optionnel : clé de dégénérescence — un identifiant source (numéro de commande) qui n'a pas de dimension propre mais est utile pour le débogage.
Chaque mesure doit être classifiée selon son type d'additivité avant d'être intégrée à la table. Une mesure additive — comme un montant de vente — peut être sommée selon toutes les dimensions sans restriction. Une mesure semi-additive — comme un solde de compte — peut être sommée par client mais pas dans le temps. Une mesure non additive — comme un taux de marge en pourcentage — ne doit jamais être sommée directement ; elle se calcule à partir de mesures additives.
Règle de classification des mesures
Additive : montant, quantité, coût — sommable selon toutes les dimensions.
Semi-additive : solde, stock — sommable selon certaines dimensions uniquement.
Non additive : taux, ratio, pourcentage — toujours calculé, jamais sommé.
Exemple concret
Prenons une entreprise française de distribution B2B avec 15 000 commandes par mois. L'équipe data construit une table de faits transactionnelle dont le grain est « une ligne par ligne d'article de commande ». Chaque ligne contient : une clé vers la dimension Date (date de la commande), une clé vers la dimension Client (identifiant du client acheteur), une clé vers la dimension Produit (référence de l'article), une clé vers la dimension Canal (web, commercial terrain, EDI), et quatre mesures : quantité commandée, prix unitaire HT, remise accordée en euros, et marge brute en euros.
Avec ce modèle, l'équipe peut répondre en quelques secondes à des questions comme : « Quel est le chiffre d'affaires HT par région commerciale sur le trimestre T1 2026 ? » ou « Quelle est la marge brute moyenne par famille de produits pour les clients acquis en 2025 ? » ou encore « Quels clients ont acheté le produit A mais pas le produit B au cours des 90 derniers jours ? » Ces requêtes croisent la table de faits avec différentes tables de dimensions selon les besoins analytiques.
En termes de volume, cette table génère environ 45 000 lignes par mois (15 000 commandes × 3 lignes d'articles en moyenne). Sur trois ans, cela représente environ 1,6 million de lignes — parfaitement gérable dans n'importe quel entrepôt de données moderne. La table de faits pèse peu en largeur (8 colonnes) mais croît continuellement en hauteur au fil des transactions enregistrées.
Analyse approfondie
Les quatre types de tables de faits correspondent à quatre patterns analytiques distincts. La table de faits transactionnelle est la plus répandue : chaque ligne représente un événement discret, avec le grain le plus fin possible. Elle est idéale pour les analyses de ventes, les logs d'activité, les événements de support. Son principal avantage est la flexibilité — on peut agréger à n'importe quel niveau de granularité à la requête. Son inconvénient est que les requêtes sur de grandes périodes nécessitent de scanner de nombreuses lignes.
La table de faits à instantanés périodiques capture l'état d'un processus à intervalles réguliers — par exemple, le niveau de stock de chaque produit en fin de journée, ou le solde MRR par client en fin de mois. Elle est adaptée aux analyses de tendances et aux métriques qui n'ont pas d'événement déclencheur clair. Son grain typique est « une ligne par entité suivie par période ». Elle implique des mesures semi-additives que l'on ne peut pas simplement sommer dans le temps.
La table de faits à instantanés cumulatifs suit un processus métier à travers plusieurs étapes successives — le cycle de vie d'une commande, d'un lead ou d'un dossier client. Chaque ligne représente une instance du processus, avec des colonnes de dates pour chaque jalons (date de création, date de validation, date d'expédition, date de livraison). Cette table est mise à jour à chaque franchissement d'étape, ce qui est inhabituel dans un entrepôt de données analytique où les données sont généralement immuables.
La table de faits sans mesures (factless fact table) est la moins intuitive : elle enregistre la survenance d'un événement sans valeur numérique associée. Par exemple, « le client X a visité la page Y le jour Z » est un fait sans mesure naturelle autre que le comptage. Ces tables sont utiles pour analyser des patterns de comportement, des présences ou des absences — comme identifier quels clients n'ont pas effectué d'achat depuis 90 jours, ou quels produits n'ont jamais été commandés dans une région donnée.
La performance des requêtes sur une table de faits dépend fortement des décisions de partitionnement et d'indexation. Dans la plupart des entrepôts de données modernes (BigQuery, Snowflake, Redshift), la table de faits est partitionnée par date — la colonne la plus filtrée dans les requêtes analytiques. Le clustering sur les colonnes de dimension les plus filtrées (client, produit, région) complète le dispositif. Un modèle bien conçu permet des requêtes sub-secondes sur des milliards de lignes, là où un modèle mal structuré rend les mêmes requêtes impossibles à exécuter dans un délai raisonnable.
Erreurs fréquentes dans la conception des tables de faits
- ✗
Mélanger plusieurs grains dans une même table : certaines lignes représentent des transactions individuelles et d'autres des récapitulatifs hebdomadaires. Ce mélange rend toute agrégation incorrecte et difficile à détecter. Les analyses semblent fonctionner mais produisent des doubles comptages ou des sous-totaux faux. La règle est absolue : une table de faits, un grain déclaré, zéro exception. Si deux grains sont nécessaires, deux tables de faits distinctes s'imposent.
- ✗
Stocker des attributs descriptifs dans la table de faits : inclure directement dans la table de faits des colonnes comme le nom du client, la catégorie du produit ou la région de vente est une erreur de modélisation fréquente. Ces attributs appartiennent aux tables de dimensions. Les mettre dans la table de faits gonfle inutilement son volume, complique les mises à jour (si le nom d'un client change, combien de lignes de la table de faits faut-il mettre à jour ?) et casse la logique de la gestion des dimensions à évolution lente.
- ✗
Sommer des mesures non additives : un taux de marge en pourcentage, un score de satisfaction ou un délai moyen ne peuvent pas être sommés directement pour obtenir un agrégat significatif. Sommer des taux de marge par produit pour obtenir un taux de marge global est mathématiquement incorrect — le résultat dépend des volumes relatifs de chaque produit. La bonne pratique est de stocker les mesures additives sous-jacentes (marge brute en euros, chiffre d'affaires en euros) et de calculer le ratio dans la requête ou la couche sémantique.
Comment Fairview exploite les tables de faits
Fairview ingère vos données opérationnelles depuis vos sources de facturation, CRM et ERP, et les structure automatiquement selon les principes du modèle dimensionnel. Les tables de faits construites par Fairview — transactions, événements d'abonnement, interactions commerciales — sont conçues avec un grain déclaré explicitement et des mesures correctement classifiées. Le tableau de bord opérationnel de Fairview repose sur ces tables pour livrer des métriques cohérentes par segment, par cohorte et par canal, sans nécessiter de requêtes SQL manuelles ni de modélisation par votre équipe data.
Lorsque vous connectez vos sources à Fairview, la plateforme construit les tables de faits et de dimensions correspondantes, les partitionne correctement, et expose une couche sémantique qui respecte les règles d'additivité. Vos opérateurs peuvent croiser les métriques par n'importe quelle dimension disponible — date, plan tarifaire, canal d'acquisition, région — avec la certitude que les agrégats produits sont mathématiquement corrects.
En un coup d'œil
- Catégorie
- Business Intelligence
- Termes associés
- 4 termes
- Règle fondamentale
- Un grain par table
- Temps de lecture
- 10 min
Questions fréquentes
Quelle est la différence entre une table de faits et une table de dimensions ?
La table de faits enregistre les événements métier et leurs mesures numériques : montant d'une vente, nombre de clics, quantité commandée. La table de dimensions fournit le contexte descriptif de ces événements : qui est le client, quel est le produit, quelle est la date. La table de faits est longue et étroite ; la table de dimensions est courte et large. Les deux sont reliées par des clés étrangères dans un schéma en étoile.
Qu'est-ce que le grain d'une table de faits et pourquoi est-il important ?
Le grain définit ce qu'une ligne représente exactement — par exemple, une ligne par transaction individuelle. Déclarer le grain avant de concevoir la table est une règle fondamentale. Un grain mixte (certaines lignes sont des transactions, d'autres des récapitulatifs) produit des agrégations incorrectes difficiles à détecter en production. La règle est simple : une table de faits, un grain, zéro exception.
Quels sont les différents types de tables de faits ?
Il existe trois types principaux : transactionnelle (un événement par ligne, le plus courant), à instantanés périodiques (état d'un processus à intervalles réguliers, comme le solde MRR en fin de mois) et à instantanés cumulatifs (suivi d'un processus multi-étapes comme le cycle de vie d'une commande). Les tables sans mesures (factless) enregistrent la survenance d'événements sans valeur numérique associée, utiles pour analyser des patterns de comportement.
Qu'est-ce qu'une mesure additive, semi-additive ou non additive ?
Une mesure additive (montant, quantité) peut être sommée selon toutes les dimensions. Une mesure semi-additive (solde de compte, niveau de stock) peut être sommée par certaines dimensions mais pas dans le temps. Une mesure non additive (taux de marge, ratio) ne peut jamais être sommée directement — elle se calcule toujours à partir de mesures additives sous-jacentes. Confondre ces catégories produit des rapports mathématiquement incorrects.
Découvrez-le dans Fairview
Des données structurées. Des métriques fiables.
Démo en direct de 25 minutes. Fairview structure vos données opérationnelles selon les principes du modèle dimensionnel — sans travail de modélisation de votre part.