Le directeur financier sort un chiffre, le directeur commercial en sort un autre, et les deux parlent du même indicateur avec les mêmes données dans le même warehouse. Ce n’est pas un problème de données, c’est un problème de définitions, et personne dans votre équipe n’est formellement responsable d’y remédier.
Le vide que personne ne voit
Entre le data engineer qui construit les pipelines et l’analyste qui produit les rapports, la plupart des organisations ont laissé un espace vide. C’est là que se jouent les disputes de chiffres en comité de direction, les heures perdues à réconcilier des métriques qui auraient dû désigner la même chose, et les décisions prises sur des bases que personne ne peut vraiment expliquer.
Le data engineer fait son travail : les données arrivent dans le warehouse, propres, typées, présentes. L’analyste fait le sien : il construit un rapport, tire des conclusions, alerte sur les tendances. Les deux font ce qu’on leur demande. Le problème n’est pas là.
Il est dans ce que personne ne s’est posé comme question : qu’est-ce qu’un client actif, exactement ? Sur quelle période le calcule-t-on ? Est-ce qu’un compte suspendu depuis trente jours en fait partie ? Ces définitions existent, d’une certaine façon. Elles sont dans un fichier Excel partagé, dans un email de 2022, dans la mémoire d’un consultant qui est passé à autre chose. Mais elles ne sont pas dans le système. Ce qui manque, ce n’est pas une personne avec un nouvel intitulé de poste. C’est une couche : celle qui garantit que les données arrivent aux analystes avec des définitions stables, documentées et testées, et non plus avec des conventions implicites.
Ce qui manque souvent entre les deux
La fonction qui fait défaut a des livrables précis. Vous pouvez les vérifier, les tester et les maintenir une fois qu’ils existent. C’est ça qui compte, pas l’étiquette qu’on colle sur la chaise.
Premier livrable : les données brutes du warehouse sont organisées en marts métier. Des couches nommées selon la langue de l’organisation, pas selon les conventions techniques du système source. Pas tbl_cust_ev_log, mais clients_actifs_30j, avec sa définition écrite, ses tests automatisés, sa date de dernière mise à jour. C’est exactement ce qu’on entend par parler le langage du business avec les tables intermédiaires.
Ces marts sont construits avec des outils comme dbt comme couche de transformation. Chaque modèle est versionné dans Git, documenté inline, testé à chaque exécution. Si la définition de « client actif » évolue, le changement est traçable : qui l’a décidé, quand, pourquoi. Si deux équipes utilisent deux définitions incompatibles, le test échoue et le problème remonte avant d’atteindre le rapport du comité de direction.
L’autre livrable structurant, c’est la documentation qui vit dans le code. Pas dans Confluence, pas dans un wiki que personne ne met à jour au-delà du premier trimestre. Dans le dépôt, au même endroit que les transformations. Une doc qui se déploie avec les données. Si vous voulez approfondir ce point précis, on a détaillé pas à pas comment documenter la semantic layer dans un article dédié.
Résultat concret : quand le DAF et le Chief Data Officer consultent le même tableau de bord, ils voient le même nombre de clients actifs. Pas parce qu’ils se sont mis d’accord à l’oral en réunion, mais parce qu’il n’existe qu’une seule définition dans le système, avec ses règles de gestion explicites et ses tests qui garantissent la cohérence à chaque rafraîchissement.
La semantic layer : ce contrat entre vos données et vos équipes
Le terme « semantic layer » mérite qu’on lui donne un contenu précis. Ce n’est pas un concept de conférence data, c’est quelque chose de concret qu’on peut construire, tester et livrer.
Une semantic layer, c’est une couche d’abstraction entre les données brutes de votre warehouse et les personnes qui les consomment. À gauche, des tables avec des noms comme fact_contract_event_v2 ou stg_crm_accounts. À droite, des concepts que votre directeur commercial comprend sans formation : « clients actifs ce mois-ci », « taux de résiliation sur 12 mois glissants », « panier moyen par segment ». Elle fait le lien entre les deux, avec des règles explicites, documentées et testées à chaque rafraîchissement.
Quand c’est bien construit, les effets se voient vite. Chaque équipe part du même référentiel. Un analyste finance et un analyste marketing travaillent sur des périmètres différents sans produire des chiffres contradictoires, parce que le socle est posé dans le code, pas dans les mémoires individuelles. Les nouveaux arrivants montent sur les données en quelques jours au lieu de quelques mois. Les réunions de réconciliation disparaissent.
Quand ça ne l’est pas, chaque équipe reconstruit ses propres définitions dans ses propres outils. L’analyste finance a sa vue dans PowerBI. L’analyste marketing a la sienne dans Tableau. Elles ne se parlent pas. Au bout de dix-huit mois, vous avez trente marts non documentés, des tables nommées temp_final_v3_ok, et une dette que personne n’ose toucher de peur de casser quelque chose. Les décisions se prennent sur des chiffres que les équipes n’arrivent plus à expliquer, ou qu’elles n’osent plus remettre en question. Le coût n’est pas technique. Il est décisionnel.
Un exemple dans la banque et l’assurance
Prenons un cas récurrent dans les organisations financières. Deux équipes calculent un indicateur de risque : le taux de sinistralité, ou le taux de créances douteuses selon le secteur.
L’équipe Risques l’applique sur les contrats actifs à date d’arrêté, avec une exclusion des contrats en phase de litige. L’équipe Finance l’applique sur une période glissante de douze mois, sans exclusion. Les deux méthodologies sont défendables sur le plan actuariel. Aucune n’est documentée dans le système de données. Les deux alimentent des reportings qui remontent en comité de direction.
En réunion de pilotage, les chiffres diffèrent de presque deux points. Chaque directeur défend son périmètre. La réunion dépasse de loin son horaire. Aucune décision n’est prise.
Ce n’est pas anecdotique. Dans les organisations financières que nous accompagnons, ce scénario se reproduit sur les indicateurs de risque, la performance commerciale, les taux de rétention, les volumes de production. Le problème n’est pas que les équipes aient tort. C’est que le système de données n’a jamais tranché.
La réponse tient dans deux marts distincts : sinistralite_risques et sinistralite_finance, avec leurs définitions respectives documentées, leurs filtres explicites, et un modèle de réconciliation qui expose l’écart et sa cause. Quand les deux équipes consultent le tableau de bord, elles voient les deux chiffres, leur différence, et la règle de gestion qui l’explique. La réunion parle de la décision à prendre, pas du chiffre à croire.
C’est ça, une couche sémantique commune. Pas une réunion de gouvernance supplémentaire. Un code qui impose la clarté.
Pourquoi cette fonction manque dans votre organisation
Trois raisons reviennent à chaque fois, dans des secteurs différents.
La compétence est rare. Elle demande de comprendre les besoins métier assez finement pour nommer les choses correctement, c’est-à-dire préférer clients_actifs_30j à dim_user_status, et de maîtriser assez la technique pour produire des modèles dbt robustes, écrire des tests qui tiennent en production, et structurer une couche qui ne devient pas une dette dans six mois. Elle tient une conversation dbt avec les data engineers, puis présente les KPI à un directeur régional, sans que vous fassiez la traduction.
La fonction est souvent diluée dans d’autres rôles. Dans beaucoup d’équipes, c’est l’analyste le plus technique qui assure ce travail en plus du reste, sans méthode, sans outillage cohérent, sans temps alloué. Le résultat : des marts à moitié documentés, des tests qui couvrent trente pour cent des cas, une couche qui ressemble à un chantier permanent. Un data catalog actif rend cette dette visible, mais ne la résorbe pas seul.
Ce n’est pas un besoin permanent au même niveau d’intensité, donc pas forcément un CDI. La valeur se concentre sur deux moments : la construction initiale de la couche sémantique, et les phases de montée en charge quand de nouveaux domaines métier arrivent. Entre les deux, il reste un entretien que les équipes internes peuvent assurer si le travail a été bien fait dès le départ.
Ce que Bomzai met en place
Bomzai intervient sur ces sujets dans la banque, l’assurance, le transport et l’industrie. Ce qu’on met en place n’est pas un audit de plus, ni une recommandation d’architecture qui finit dans un tiroir.
C’est une couche sémantique en production : des marts documentés et nommés selon le vocabulaire métier de votre organisation, des tests automatisés qui valident la cohérence des définitions à chaque rafraîchissement, un catalogue de métriques que votre équipe data peut maintenir sans nous après la livraison.
Nos consultants tiennent les deux conversations en même temps. Ils travaillent avec les data engineers sur les transformations et présentent les définitions de KPI à la direction métier, sans que vous ayez à servir d’interprète entre vos équipes techniques et business. C’est précisément la compétence qui manque, et c’est celle qu’on met en face de votre problème.
Premier livrable en production : six à huit semaines. Pas six mois de feuille de route avant de voir tourner quoi que ce soit.
La vraie question à poser
La question n’est pas « avez-vous quelqu’un avec tel ou tel intitulé de poste ? ». Les organisations mettent des mots différents derrière les mêmes missions, et un data engineer peut très bien porter ce travail. La question utile est ailleurs.
D’abord : disposez-vous d’une couche sémantique ? Des définitions métier posées dans le code, documentées, testées, partagées par toutes les équipes qui consomment la donnée. Ensuite : avez-vous des personnes dont le rôle est explicitement de la maintenir et de la faire évoluer quand les définitions changent et que de nouveaux domaines arrivent ? Ces missions de gouvernance sont en général portées par le data office, quand il existe.
Si vous répondez non aux deux, le problème n’est pas que vos équipes manquent de rigueur. C’est qu’aucune couche ne tranche à leur place. On peut la construire avec vous, et vous la laisser.