Les données brutes parlent la langue des systèmes sources - customer_id, transact_date, amt. Le business parle de clients, de périodes, de chiffre d'affaires. Entre ces deux mondes? Un fossé qui génère confusion, erreurs, discussions infinies.
« Qu'est-ce qu'un client résilien? » « Quel statut on utilise? » « Qui a raison sur la définition? » Après trois réunions, vous avez trois réponses. Gartner (2025) rapporte que les données mal alignées causent 35% des erreurs d'interprétation. Un business glossary bien construit réduit de 50% ces allers-retours.
Les meilleures data teams en 2026 construisent des tables intermédiaires qui sont ce pont - alignées avec le vocabulaire métier, réutilisables, testées. C'est l'art de faire parler les données le langage du business.
Le fossé sémantique : cause racine invisible
Un exemple concret. La table brute a « status » avec valeurs « ACTIVE », « INACTIVE », « DORMANT ». Le métier veut « client résilien ». Quel filtre? Lequel des trois? Les discussions se multiplient. Les rapports donnent des chiffres différents selon qui a demandé.
C'est le fossé sémantique. Les données brutes sont agnostiques métier - elles reflètent le système source, pas la logique business. Les tables mal alignées causent chaos et méfiance. L'intermediate layer de dbt est le lieu où on crée ce glossaire opérationnel : « un client résilien » = « status = ACTIVE ET sans interaction depuis < 6 mois ».
Une fois défini, c'est réutilisable partout. Plus de débat. Une source de vérité.
Architecture: staged → intermediate → marts
Les couches de dbt reposent sur cette hiérarchie sémantique.
Staging brute (raw) : transformation minimaliste, renommage des colonnes du système source. Pas de logique métier.
Intermediate business : c'est où on applique la logique métier, où on crée les concepts qui comptent pour le business. Clients résiliants. Commandes de haut CA. Périodes d'activité. C'est ici qu'on joint les tables sources, qu'on calcule les indicateurs composites, qu'on applique les filtres métier complexes.
Marts finaux : prêts pour la BI, construits par composition des intermédiaires.
Avantage : une logique métier complexe n'est définie qu'une fois en intermédiaire, réutilisée par 10 marts finaux. Sans cette couche, chaque mart redéfinit la logique. Chaos garanti.
Conventions de nommage: la base
Une convention claire guide l'univers. Prefixes explicites : is_ pour les booléens (is_active), cnt_ pour les comptages (cnt_orders), amt_ pour les montants (amt_revenue).
Noms explicites et métier : « customer_ltv » au lieu de « cust_val ». Pas d'abréviations cryptiques. Suffixes de calcul : _total pour les agrégations, _flag pour les booléens de segmentation.
Un business glossary documenté centralisé (dans dbt YAML ou un wiki) définit chaque terme métier et sa traduction technique. « Chiffre d'affaires » = « montant des commandes facturées dans la période, toutes catégories, hors remises ». Définition précise, sans ambiguïté.
Quand tout le monde parle le même langage, les erreurs de confusion statistiques disparaissent.
Réutilisable et DRY
Le principe DRY appliqué aux données : une logique métier = une table intermediate. « Commande de haut CA » = « montant total > 10 000 ». Défini une fois, utilisé par 5 marts. Si la règle change, une seule modification.
La couche intermediate réduit de 60% le nombre de tables finals nécessaires car elles partagent des composants. Avantage collatéral : testing centralisé. Tester la logique « client résilien » une fois en intermédiaire plutôt que 5 fois en marts finals. Les tests s'héritent automatiquement.
C'est l'économie d'échelle de la modélisation de données.
Self-service augmenté: quand métiers et intermédiaires s'alignent
Avec des intermédiaires bien nommées et documentées, le self-service devient puissant. Les utilisateurs métier voient des tables avec des noms qu'ils comprennent - « customers_segments », « orders_monthly », « product_categories ». Pas besoin de traducteur data.
Les jointures pré-sensées réduisent les faux pas. Une personne du marketing peut créer un dashboard sans solliciter la data team 10 fois pour clarifier la sémantique. Les erreurs de requête chutent car les données parlent le langage du business.
La documentation des intermédiaires accélère l'autonomisation. C'est le vrai self-service : empowerment par clarté, pas par permissiveness.
Itération et évolution
Le modèle de données n'est jamais statique. Le business évolue, de nouvelles segmentations émergent, des métriques perdent la pertinence. L'intermediate layer permet d'itérer rapidement.
Ajouter une colonne « is_premium_customer » en intermédiaire prend 1 jour et devient immédiatement disponible pour tous les marts dépendants. Sans intermédiaires, c'est 5 jours de coordination entre marts incompatibles.
Les retours des métiers s'implémentent en 2-3 sprints dbt plutôt que 2-3 mois. La couche intermediate est le levier de l'agilité du modèle données.
Le cœur de la stratégie
Les intermédiaires ne sont pas une couche technique gratuite, c'est le cœur de la stratégie sémantique. Quand les données parlent le langage du business, tout devient plus fluide - moins d'erreurs, plus d'autonomie métier, maintenance réduite.
C'est l'art de faire parler les données métier. Et c'est opérationnel.