Data warehouse, lakehouse et couche sémantique

Le data warehouse organise des données structurées pour l'analyse, tandis que le lakehouse permet de traiter des données plus variées avec des mécanismes de gestion proches de ceux d'un entrepôt. La couche sémantique donne à ces données un sens métier commun : elle précise ce que mesure un indicateur, comment il se calcule et dans quelles conditions il peut être comparé. Ensemble, ces composants alimentent la BI, ou informatique décisionnelle, ensemble des outils d'analyse et de restitution des données, sans remplacer la responsabilité de la finance sur les définitions.

• Stocker et préparer ne signifie pas définir le métier. Le chiffre d'affaires (CA) est le montant hors taxes des ventes de biens et services reconnu sur la période selon les règles comptables applicables, net des réductions commerciales et des avoirs correspondants. L'entrepôt peut contenir des ventes parfaitement chargées sans préciser si le CA inclut les avoirs, à quelle date il est reconnu ou comment sont traitées les opérations entre sociétés du groupe. Le choix entre entrepôt et lakehouse dépend des sources, des usages et des compétences disponibles ; il ne suffit pas à garantir la cohérence financière.
• Partager une définition exige de formaliser ses conditions. La couche sémantique associe un nom métier à un calcul, une unité, un périmètre, une période et des règles d'accès. Un taux ne se totalise pas comme un montant : il faut généralement recalculer son numérateur et son dénominateur au niveau demandé. Cette logique doit être commune aux restitutions qui prétendent afficher le même indicateur.
• La confiance repose sur une chaîne vérifiable. Chaque résultat doit pouvoir être rapproché de sa source, avec une explication des transformations et des exclusions. Les données disponibles, les données contrôlées et les données officiellement validées peuvent être distinctes. La finance décide des conventions et valide les résultats ; les équipes techniques assurent leur mise en œuvre et leur exploitation.

Sans organisation explicite des données et des calculs, la direction financière passe une partie de son temps à réconcilier des fichiers plutôt qu'à expliquer la performance. Une extraction commerciale suit la date de commande, une autre la date de facture et la comptabilité retient une période de comptabilisation. Les montants peuvent être exacts dans chaque système tout en répondant à des questions différentes.

Des écarts difficiles à interpréter

Si les conventions de reconnaissance du CA ne sont pas explicitées, un tableau commercial et un état financier peuvent afficher des CA différents sans qu'il y ait une erreur de chargement. La difficulté consiste à identifier une différence de convention, de période ou de périmètre avant de corriger les données.

Un référentiel est un ensemble partagé de codes et de descriptions pour identifier les objets métier, par exemple les sociétés, les clients ou les produits. Sans référentiel maîtrisé, un client peut apparaître sous plusieurs noms, une société sous plusieurs codes et une activité dans des regroupements incompatibles. Les comparaisons deviennent fragiles, notamment après une réorganisation.

Des calculs dispersés et peu contrôlables

Une règle d'agrégation précise comment combiner des valeurs pour produire un total ou un regroupement. Additionner des ventes sur des périmètres compatibles est souvent pertinent. En revanche, le taux de marge sur coûts variables — soit (CA − coûts variables) / CA × 100, les coûts variables étant ceux qui varient avec l'activité — se recalcule à partir des montants du regroupement, au lieu d'additionner les taux individuels. Lorsque ces règles sont recopiées dans chaque fichier, les résultats dérivent au fil des corrections locales.

L'infrastructure répond à ces difficultés en séparant la conservation des données, leur préparation et leur interprétation métier. Elle permet aussi de retrouver les corrections effectuées et leurs responsables. Elle ne résout toutefois pas un désaccord sur la définition d'un indicateur : celui-ci doit être arbitré, documenté et approuvé par les fonctions concernées.

1. Collecter les données avec leur contexte. Les extractions conservent l'identifiant d'origine, la date de chargement, la période et la source. Un ETL est un processus qui extrait, transforme puis charge les données ; un ELT les extrait et les charge avant de les transformer dans la plateforme cible. Le choix dépend des contraintes techniques et de contrôle, pas d'une supériorité universelle.

2. Organiser les zones de stockage. Une zone conserve les données reçues, une autre les prépare pour l'analyse. Le data warehouse privilégie des structures préparées pour les usages décisionnels. Le lakehouse peut accueillir des données variées et des tables gérées pour l'analyse. Ces architectures peuvent coexister ; leur articulation doit éviter les copies sans responsabilité clairement identifiée.

3. Définir le niveau de détail. Le grain est le niveau de détail représenté par une ligne, par exemple une ligne de facture. Une dimension est un axe d'analyse, comme la société ou le produit. Une clé est un champ ou un ensemble de champs servant à identifier un enregistrement ou à établir une correspondance entre tables. Une jointure relie des tables à partir de clés communes ; une clé de jointure n'est pas nécessairement unique dans chaque table. Si une ligne de vente trouve plusieurs correspondances inattendues dans une table de produits, les montants peuvent être multipliés : cette relation doit être testée.

4. Appliquer les contrôles et les transformations. Les codes sont rapprochés du référentiel, les unités harmonisées et les anomalies isolées. Les totaux sont comparés aux sources avant publication. La traçabilité des données, ou lineage, décrit le parcours d'une donnée depuis sa source jusqu'à sa restitution ; elle inclut les transformations significatives.

5. Publier les définitions métier. Une mesure est une valeur quantitative destinée à l'analyse, issue d'une donnée ou d'un calcul, comme le CA ou un taux de marge ; sa définition précise notamment ses règles d'agrégation. La couche sémantique expose des mesures et leurs règles : formule, filtres, période, devise et droits d'accès. Les outils de restitution utilisent ces définitions lorsque leurs connexions le permettent. Les exceptions sont documentées, et une modification de règle déclenche une vérification des résultats concernés.

Cet exemple est fictif : une entreprise de taille intermédiaire (ETI), catégorie d'entreprise située entre les PME et les grandes entreprises, analyse deux activités sur un mois. Tous les montants sont en euros, sur le même périmètre, sans opération entre les activités. Le budget est la référence chiffrée approuvée pour la période ; le réel correspond ici aux montants réalisés et validés.

La marge sur coûts variables est le CA diminué des coûts qui varient avec l'activité. L'écart budgétaire est calculé comme réel − budget ; son caractère favorable ou défavorable dépend de la nature du montant analysé.

| Activité | CA budget | CA réel | Coûts variables budget | Coûts variables réels | Marge budget | Marge réelle | |---|---:|---:|---:|---:|---:|---:| | Industrie | 580 000 | 600 000 | 348 000 | 360 000 | 232 000 | 240 000 | | Services | 420 000 | 400 000 | 252 000 | 260 000 | 168 000 | 140 000 | | Total | 1 000 000 | 1 000 000 | 600 000 | 620 000 | 400 000 | 380 000 |

Vérifier les opérations

CA réel total = 600 000 + 400 000 = 1 000 000. Coûts variables réels totaux = 360 000 + 260 000 = 620 000. Marge réelle totale = 1 000 000 − 620 000 = 380 000, également égale à 240 000 + 140 000.

Marge budgétée = (580 000 − 348 000) + (420 000 − 252 000) = 232 000 + 168 000 = 400 000. L'écart de marge est donc 380 000 − 400 000 = −20 000, défavorable. L'écart de coûts variables est 620 000 − 600 000 = +20 000, également défavorable.

Le taux de marge sur coûts variables est la marge sur coûts variables divisée par le CA. Au réel : 380 000 / 1 000 000 × 100 = 38 %. Au budget : 400 000 / 1 000 000 × 100 = 40 %. L'écart est de −2 points de pourcentage.

L'entrepôt ou le lakehouse conserve les montants par activité et période. La couche sémantique calcule la marge et recalcule le taux sur les totaux : elle n'additionne pas les taux des activités. Le contrôle financier valide enfin que les coûts retenus correspondent bien à la convention de coûts variables.

1. Partir d'une décision de gestion. Choisir un usage délimité, comme comparer la marge réalisée au budget par activité. Identifier les utilisateurs, les décisions attendues et les délais de disponibilité nécessaires. Livrable : une fiche d'usage décrivant les résultats attendus et les limites du périmètre.

2. Formaliser les définitions avant les flux. Pour chaque indicateur, préciser formule, unité, période, exclusions, axes d'analyse et responsable de validation. Distinguer une mesure comptable d'une mesure commerciale lorsqu'elles répondent à des besoins différents. Livrable : un dictionnaire métier approuvé par la finance et les fonctions sources.

3. Cartographier les données et leurs propriétaires. Recenser les applications, les extractions disponibles, les référentiels et les contrôles existants. Un propriétaire de données est la personne responsable de leur définition et de leur qualité sur un domaine donné. Livrable : une cartographie reliant sources, responsables, usages et contraintes d'accès.

4. Concevoir le modèle et les échanges. Fixer le grain, les relations entre tables, les règles d'historisation et les frontières entre stockage et calcul métier. L'historisation conserve les états successifs d'une donnée ou d'une règle afin de restituer leur évolution. Livrables : modèle de données, spécification des échanges et règles de traitement des anomalies.

5. Tester sur un périmètre représentatif. Vérifier les totaux, les avoirs, les changements de codes, les périodes incomplètes et les droits d'accès. La recette utilisateur est la validation de la solution par les utilisateurs à partir de cas attendus. Livrables : résultats de tests, écarts expliqués et décision de mise en service.

6. Organiser l'exploitation et l'extension. Définir qui surveille les chargements, qui corrige et qui autorise une republication. Livrables : procédure d'exploitation, registre des incidents et calendrier de révision des définitions. L'extension à la planification budgétaire doit préserver les mêmes axes de comparaison tout en distinguant données réalisées et hypothèses.

Centraliser les définitions, pas tous les traitements

Une formule métier doit avoir une référence identifiée, même si son exécution est répartie entre plusieurs outils. Documenter où elle s'exécute évite de croire qu'un dictionnaire suffit à imposer une logique commune. Si une mesure doit être reproduite dans un autre système, prévoir un test de concordance et un responsable de synchronisation.

Préserver le détail utile et maîtriser les totaux

Conserver le grain nécessaire à l'explication d'un écart, sans exposer tous les détails à tous les utilisateurs. Les mesures additives sont des valeurs que l'on peut additionner sur les axes concernés, comme des ventes sur une période. Les mesures semi-additives ne s'additionnent que sur certains axes : un solde de trésorerie peut être totalisé entre comptes, mais pas entre dates successives. Formaliser ces propriétés protège les restitutions contre les totaux trompeurs.

Séparer disponibilité et validation

Un chargement terminé ne prouve ni l'exhaustivité ni l'approbation des chiffres. Afficher la date de mise à jour, la période couverte et le statut de validation. La clôture est le processus qui arrête et contrôle les comptes d'une période. Une donnée provisoire et une donnée de clôture doivent pouvoir être distinguées, même lorsqu'elles proviennent de la même table.

Tester les règles lors de chaque évolution

Les tests de non-régression vérifient qu'une modification ne dégrade pas des résultats déjà validés. Ils doivent couvrir les formules, les relations entre tables, les accès et les situations limites. Un changement de classement d'une activité peut être aussi sensible qu'une modification de calcul.

Protéger la donnée jusqu'à la restitution

Les droits doivent rester cohérents entre stockage, couche sémantique et outils utilisateurs. Une restriction appliquée dans un tableau ne protège pas nécessairement un export ou une connexion directe. Vérifier les parcours réels, limiter les données sensibles au besoin métier et conserver une trace des changements de droits contribue à rendre le dispositif contrôlable.

Choisir l'architecture avant de préciser les usages

Un lakehouse n'est pas automatiquement plus adapté qu'un entrepôt, et un entrepôt ne suffit pas à tous les traitements. Partir des sources, du niveau de détail, des contrôles et des compétences d'exploitation. Comparer aussi les coûts de fonctionnement et la capacité à maintenir les règles, pas seulement les possibilités techniques.

Confondre stockage central et vérité unique

Une table centrale peut contenir plusieurs dates, périmètres ou conventions légitimes. Pour éviter les désaccords, nommer distinctement les mesures et préciser leurs conditions d'emploi. La vérité partagée repose sur des définitions approuvées, pas sur l'emplacement physique des données.

Recréer les calculs dans chaque restitution

Les formules locales finissent par diverger. Réutiliser les mesures communes lorsque l'outil le permet ; sinon, encadrer les exceptions et comparer les résultats. Une couche sémantique propre à un outil ne s'impose pas automatiquement aux autres outils connectés au même stockage.

Multiplier les montants par une jointure incorrecte

Relier des ventes à un référentiel contenant plusieurs lignes valides pour le même code peut créer des doublons. Vérifier l'unicité attendue des clés et les périodes de validité. Comparer les volumes de lignes et les sommes avant et après chaque relation sensible.

Réécrire silencieusement l'histoire

Rattacher toutes les périodes à l'organisation actuelle peut être utile, mais cela ne restitue plus nécessairement la vision publiée à l'époque. Distinguer la vision historique et la vision recalculée avec le périmètre actuel. Conserver la règle appliquée et informer l'utilisateur de la vue sélectionnée.

Corriger les sources sans conserver de trace

Une correction manuelle invisible rend le rapprochement impossible. Prévoir un registre indiquant la valeur d'origine, la correction, son motif et sa validation. Lorsque la correction doit revenir dans l'application source, organiser cet échange explicitement plutôt que laisser une divergence durable entre systèmes.

Un KPI, ou indicateur clé de performance, est une mesure retenue pour suivre un objectif et guider une décision. Ici, les KPI portent sur la fiabilité de la chaîne de données et son aptitude à servir le pilotage. Le périmètre, la période et le responsable de chaque mesure doivent être précisés ; un indicateur technique isolé ne garantit pas la qualité financière.

• Taux de complétude = nombre de champs obligatoires renseignés / nombre de champs obligatoires attendus × 100. Définir quels champs sont obligatoires selon le type de donnée ; une absence légitime ne doit pas devenir une anomalie artificielle.
• Taux de conformité = nombre d'enregistrements satisfaisant toutes les règles retenues / nombre d'enregistrements contrôlés × 100. Publier la liste des règles et distinguer les anomalies bloquantes des alertes.
• Écart de rapprochement = montant publié − montant source, à convention et périmètre identiques. Pour une mesure financière, expliquer chaque différence plutôt que la masquer dans un total net.
• Délai de disponibilité = date et heure de mise à disposition validée − date et heure de disponibilité de la source. Cette durée mesure le traitement et la validation, pas le retard propre à la source.
• Taux de couverture des définitions = nombre d'indicateurs publiés disposant d'une définition approuvée / nombre d'indicateurs publiés × 100. Une définition complète inclut formule, unité, périmètre et propriétaire.
• Taux de traçabilité = nombre d'indicateurs prioritaires reliés à leurs sources et transformations / nombre d'indicateurs prioritaires × 100. La traçabilité doit permettre une investigation réelle, pas seulement afficher un schéma.

Si un dénominateur est nul, indiquer « non applicable » plutôt que produire un taux trompeur. Les livrables associés sont le dictionnaire métier, le modèle de données, la cartographie des flux, les résultats de rapprochement, le registre des anomalies et les preuves de validation. Ils doivent être datés, accessibles aux responsables concernés et mis à jour lors des changements.

Un EPM, ou système de gestion de la performance d'entreprise, outille notamment la planification, les analyses financières et, selon les solutions, la consolidation comptable, qui consiste à présenter les comptes d'un groupe comme ceux d'une seule entité économique, notamment après harmonisation et élimination des opérations internes au périmètre consolidé. Il complète l'infrastructure de données : il peut recevoir des données réalisées, gérer des hypothèses et produire des résultats de gestion, mais ne remplace pas nécessairement l'entrepôt ou le lakehouse.

Des fonctions propres au pilotage financier

Un EPM peut proposer des modèles par axes d'analyse, des formulaires de saisie, des calculs, des contrôles et un workflow, circuit organisé de tâches et de validations. Il peut gérer des versions, états identifiés d'un jeu de données, comme le budget approuvé et une prévision révisée. Ces capacités permettent de distinguer les chiffres reçus des sources, les ajustements de gestion et les hypothèses saisies.

Le contrat d'échange avec l'infrastructure doit préciser le grain, les périodes, les devises, les codes et les statuts. Il faut aussi décider où chaque règle est exécutée. Une marge calculée dans l'EPM et affichée dans la BI doit suivre une convention compatible, ou porter un nom qui rend leur différence explicite. La complémentarité entre BI et EPM repose sur cette répartition des responsabilités.

Des solutions à examiner selon le besoin

OneStream, CCH Tagetik et Oracle EPM proposent des fonctions de gestion financière couvrant notamment la consolidation et la planification, selon les produits et modules retenus. Anaplan, Pigment, Board, SAP Analytics Cloud et Workday Adaptive Planning sont également pertinents à examiner pour des besoins de planification et d'analyse.

Le choix doit vérifier les échanges avec les sources, les contrôles de chargement, la gestion des versions, les droits et la restitution des calculs. La présence d'un connecteur ne prouve pas que les définitions métier sont partagées. Les possibilités exactes de réutilisation d'une couche sémantique, d'export et de traçabilité doivent être testées dans le contexte envisagé, sans supposer une compatibilité automatique.

Débutant : des chiffres utiles, mais dépendants des personnes

Les données sont extraites dans des fichiers, les rapprochements sont manuels et les formules vivent dans les restitutions. Quelques collaborateurs connaissent les règles, sans documentation complète. Le signe distinctif n'est pas l'usage d'un tableur : c'est l'impossibilité de reproduire sereinement un résultat lorsque son auteur est absent.

La priorité consiste à définir les indicateurs essentiels, identifier leurs sources et stabiliser les contrôles. Un dictionnaire métier limité mais approuvé, des fichiers datés et un rapprochement systématique peuvent constituer une première étape solide. Déployer une plateforme plus large sans ces bases risque seulement de déplacer les incohérences.

Intermédiaire : une chaîne organisée, encore partiellement fragmentée

Un entrepôt ou un lakehouse alimente plusieurs usages. Les référentiels principaux sont maîtrisés, les chargements sont surveillés et certains calculs sont partagés. Les anomalies ont des responsables, mais des règles locales subsistent dans les tableaux ou les applications financières.

Le signe distinctif est la capacité à rapprocher les résultats et à expliquer les écarts, même si l'investigation reste parfois manuelle. La priorité devient la formalisation des règles d'agrégation, la traçabilité des transformations et les tests de concordance entre outils. Les changements d'organisation doivent être traités sans perdre la possibilité de reproduire les vues historiques.

Avancé : des définitions gouvernées et des résultats reproductibles

La gouvernance des données est l'organisation des responsabilités, des règles et des décisions qui encadrent leur usage. À ce niveau, elle relie les propriétaires métier et les équipes techniques. Les définitions sont approuvées, les changements contrôlés et les accès cohérents sur toute la chaîne.

Le signe distinctif est la capacité à reproduire un résultat publié, à retrouver sa source et à mesurer l'impact d'une modification avant sa diffusion. La maturité reste proportionnée aux risques : un domaine sensible peut exiger des contrôles renforcés sans imposer la même complexité à tous les usages.

• [ ] Quelle décision chaque indicateur doit-il éclairer, et quels utilisateurs ont réellement besoin du détail sous-jacent ?
• [ ] La finance et les fonctions opérationnelles ont-elles approuvé la même définition, ou nommé explicitement leurs mesures différentes ?
• [ ] Pour chaque mesure, la formule, l'unité, la devise, la période, les exclusions et les axes d'analyse sont-ils documentés ?
• [ ] Le grain de chaque table est-il connu, et les relations entre tables sont-elles testées pour éviter de multiplier les lignes et les montants ?
• [ ] Les règles d'agrégation distinguent-elles les montants, les soldes et les ratios, y compris lorsque l'utilisateur change le niveau d'analyse ?
• [ ] Les sociétés, clients, produits et autres référentiels ont-ils un responsable, des codes stables et des règles de mise à jour ?
• [ ] Peut-on distinguer l'organisation historique de l'organisation actuelle lorsque les regroupements ont changé ?
• [ ] Les totaux publiés sont-ils rapprochés des sources sur des conventions identiques, avec une explication des différences ?
• [ ] La date de mise à jour, la couverture de la période et le statut de validation sont-ils visibles dans les restitutions ?
• [ ] Les anomalies sont-elles isolées, affectées à un responsable et corrigées avec une trace de leur traitement et de leur validation ?
• [ ] Où s'exécute chaque règle métier, et comment vérifie-t-on sa concordance lorsqu'elle existe dans plusieurs outils ?
• [ ] Les droits restent-ils cohérents lors d'un export, d'une connexion directe ou d'un échange avec une application financière ?
• [ ] Peut-on retrouver les sources et transformations d'un chiffre, puis reproduire un résultat déjà publié avec ses conventions d'origine ?
• [ ] Les changements de formule, de référentiel et de droits font-ils l'objet de tests et d'une approbation avant leur mise en service ?
• [ ] Les responsabilités d'exploitation, les procédures en cas d'échec et les conditions de republication sont-elles connues ?

Une réponse négative n'impose pas forcément de suspendre tout usage. Elle doit conduire à identifier un risque, une mesure de maîtrise et un responsable. Avant la mise en service, traiter en priorité les écarts susceptibles de modifier une décision financière ou d'exposer des données sensibles.

À retenir : l'entrepôt et le lakehouse organisent les données ; la couche sémantique formalise leur lecture métier. La fiabilité vient de définitions approuvées, de contrôles de rapprochement et d'une traçabilité exploitable, pas du seul choix d'une architecture.

Faut-il choisir entre data warehouse et lakehouse ?

Pas nécessairement. Ils peuvent répondre à des besoins différents et coexister. La décision dépend des formats de sources, des usages analytiques, des contrôles attendus et des compétences disponibles. Une architecture plus simple et bien exploitée peut être préférable à un assemblage dont les responsabilités restent floues.

Une couche sémantique est-elle seulement un dictionnaire ?

Non. Le dictionnaire explique les termes ; la couche sémantique organise aussi des relations, des mesures et leurs conditions de calcul pour les rendre utilisables par les outils. Sa portée dépend de son implémentation : elle peut être liée à une restitution ou partagée entre plusieurs usages. Il faut vérifier quels outils appliquent réellement ses règles.

Qui doit être responsable des définitions ?

La fonction métier concernée doit approuver le sens de l'indicateur. La finance porte les conventions financières, tandis que les équipes techniques assurent leur mise en œuvre et leur exploitation. Les désaccords sur les périmètres ou les dates nécessitent un arbitrage explicite, pas une correction discrète dans un traitement.

Peut-on additionner tous les indicateurs ?

Non. Les ventes peuvent généralement être additionnées sur des périmètres compatibles ; les soldes ne s'additionnent pas entre dates successives. Un taux de marge doit être recalculé à partir de la marge et du CA du regroupement demandé. La règle de totalisation fait donc partie de la définition de l'indicateur.

Cette infrastructure suffit-elle pour utiliser l'IA ?

L'intelligence artificielle (IA) désigne des techniques informatiques capables notamment d'apprendre des régularités dans des données ou de générer du contenu. Des données organisées et des définitions explicites constituent une base utile, mais ne garantissent ni la justesse d'une prévision ni celle d'une réponse générée. Il faut contrôler les accès, évaluer les résultats et maintenir une validation humaine adaptée aux décisions financières.