Imaginez. Vous avez mis en place une magnifique pipeline de données : vous récupérez des données dans vos différentes sources, vous les avez cleanées, vous y avez appliqué des règles métiers complexes, vous avez mis en place une belle modélisation dimensionnelle, vous avez mis en place des tests de bout en bout qui vous permettent d’être confiant dans la donnée que vous communiquez et vous avez rédigé une documentation complète sur les transformations et également sur les données accessibles aux équipes métier.

Vous êtes fier de vous. Et vous pouvez car c’est déjà un gros achievement d’arriver à cette situation. Et si vous n’avez pas encore cette base solide, je vous conseillerai d’investir votre énergie et vos ressources là-dedans avant d’appliquer ce qui va suivre (mais lisez quand même, ça peut rapidement devenir un de vos projets prioritaires).

Vous êtes donc dans cette situation où vous êtes confiant mais vous êtes confronté à plusieurs problèmes :

• Plusieurs utilisateurs, pour les mêmes indicateurs, obtiennent des chiffres différents. Vous creusez le sujet et vous vous rendez compte qu’ils n’avaient pas la même définition d’active users .Pour l’un, c’était un utilisateur qui avait effectué un achat dans les 7 derniers jours, pour l’autre dans les 3 jours.
• Après plusieurs mois d’utilisation, l’équipe finance se rend compte qu’il y a peut-être un souci avec le chiffre des revenues car il ne colle pas avec les consolidations mensuelles. Vous investiguez et vous mettez le doigt sur une jointure qui est mal faite dans l’outil de visualisation et que certaines commandes sont comptées en double.
• Marc de l’équipe CRM s’est rendu compte qu’il avait accès à toutes les données normalement destinées aux RH …
• Votre équipe est souvent sollicitée pour des analyses ce qui leur fait perdre beaucoup de temps pour faire évoluer et maintenir cette belle pipeline de données (encore félicitations !).

Ce sont tout un tas de problèmes que la mise en place d’un Semantic Layer peut résoudre.

Qu’est-ce qu’un Semantic Layer ?

Un Semantic Layer est une couche (comme son nom l’indique) entre les données qui peuvent être complexes et les équipes métiers qui n’ont pas forcément les compétences techniques pour correctement les exploiter.

Ça va être une réelle interface qui va traduire les termes métiers en requêtes SQL qui peuvent être complexes. Ainsi, les équipes métiers iront directement requêter le Semantic Layer avec leurs mots et le Semantic Layer va leur fournir ce dont ils ont besoin sans que l’utilisateur final ait à écrire la moindre requête SQL.

Source : dbt Semantic Layer

Pour cela, la définition d’un Semantic Layer passe généralement par 2 phases : on définit le modèle logique de nos données avec les termes métier. On définit par exemple à quelles données correspondent les termes de client, commande, produit, panier, etc. et les relations entre ces différents termes : un client passe une commande, un produit est dans le panier d’une commande, … .

Et la deuxième étape consiste à définir et documenter les différentes métriques auxquels les utilisateurs auront accès. Il s’agira également d’indiquer comment elles sont calculées. Par exemple, on va définir que le panier moyen sera calculé en faisant la somme des montants des commandes / le nombre total de panier. Et on va aussi indiquer qu’on applique un filtre en excluant les montants des garanties car nous avons acté au niveau de l’entreprise que cet indicateur ne doit refléter que le panier moyen lié aux produits.

Source : le Semantic Layer Cube

Ainsi, une fois mis en place, le Semantic Layer va nous permettre de toujours avoir le même chiffre de panier moyen dans toute l’entreprise alors qu’avant la moitié des utilisateurs oubliait d’appliquer le filtre sur les garanties. Et comme nous avons défini les différentes entités et relations entre elles, les équipes métiers pourront également très facilement visualiser ce KPI via les différentes dimensions disponibles (par pays du client, par panier qui contiennent un produit spécifique, …) alors que cela aurait demandé des requêtes complexes sans l’existence de ce Semantic Layer.

Cela a donc de nombreux avantages :

• Source unique de vérité : Les KPIs et dimensions ne sont définis qu’une fois et le Semantic Layer va fournir toutes les personnes qui en ont besoin. Il n’y a donc plus d’incohérence dans les chiffres.
• Accessibilité de la donnée : Les utilisateurs métiers qui n’ont pas de compétences techniques peuvent facilement accéder aux chiffres parfois complexes.
• Compréhension de la donnée : Les définitions des différents termes permettent aux utilisateurs de mieux comprendre les données qu’ils manipulent.
• Sécurité : Nous définissons qui a le droit d’accéder à quelles métriques.
• Gain de temps : Les équipes data ne sont plus sollicitées (ou le sont beaucoup moins …) pour répondre aux besoins des équipes métier.

Comment le mettre en place ?

Il y a de nombreuses façons de le mettre en place. Quand on parle de Semantic Layer, il s’agit d’ailleurs plus d’un concept et pas spécifiquement d’un outil à mettre en place.

Les datamarts

Il est tout à fait possible de mettre cette stratégie en place sans recourir à de nouveaux outils : depuis votre modélisation dimensionnelle, vous pouvez construire des tables spécifiques qui répondent à un besoin métier (un datamart).

Par exemple, une table qui contient tous les KPIs de l’équipe marketing avec les différentes dimensions dont ils ont besoin pour les filtres ou les axes d’analyse. Et fournir une documentation à ces équipes pour définir les différentes colonnes. Les équipes métier pourront donc interagir avec cette table qui est plus facile à manipuler car elle est seule et ils auront accès à tous leurs KPIs. Et vous pouvez gérer les accès des différents datamarts.

Source : panoply.io

Cette méthode est déjà un bon premier pas mais je vois deux gros inconvénients :

• La granularité est fixe : imaginons, nous choisissons la granularité à la journée dans cette table. Les équipes métiers devront faire des agrégations afin d’obtenir leurs chiffres sur le mois, ce qui n’est pas toujours évident.
• La gestion des indicateurs complexes : il sera compliqué de procéder ainsi avec des indicateurs complexes. Par exemple, un taux de conversion peut être compliqué à gérer car on ne peut pas agréger un taux. Pour cela, il faudrait donc également stocker les deux chiffres qui permettent de le calculer ce qui peut rendre fastidieuse cette démarche.

Dans l’outil de BI

En fonction de l’outil de visualisation que vous utilisez, il sera possible de mettre en place cette stratégie directement au sein de l’outil. Par exemple, dans Tableau, il est possible de définir des modèles de données, les publier et les mettre à disposition des utilisateurs qui n’auront accès qu’à ces modèles.

Exemple de LookML, le Semantic Layer de Looker (source : https://tudip.com/blog-post/lookml-for-looker/)

C’est déjà mieux et cela règle les deux soucis précédents mais je vois encore un problème : ce Semantic Layer est propre à l’outil de visualisation que vous utilisez. Et si demain vous changez d’outil, vous devrez refaire tout ce travail. Si jamais vous utilisez plusieurs outils de visualisations, ce travail sera également à faire en double.

Mais si vous n’utilisez qu’un seul outil de visualisation, que vous n’avez pas prévu de le changer et que vous n’autorisez aux utilisateurs finaux d’accéder aux données que via cet outil, alors regarder ce que votre outil propose pour répondre à ce besoin est une bonne solution !

Un Universal Semantic Layer

La dernière solution que je veux vous présenter, et qui est selon moi la plus efficace, est de recourir à un outil dédié à la mise en place d’un Semantic Layer. En plus de définir le modèle de nos données et les métriques, les bons outils dans ce domaine proposent d’autres fonctionnalités :

• Une API qui permet d’interagir avec les éléments définis. Cela permet aux outils les plus populaires de s’intégrer facilement aux outils de visualisations. Dans ces outils, on définit l’adresse de l’API et les credentials et on a directement accès aux différentes métriques et dimensions définies dans le Semantic Layer.
• Un système de caching qui permet une réponse rapide aux requêtes.
• Un système de contrôle d’accès afin de limiter l’accès aux données.

Source : cube.dev

Ce domaine évolue très vite et de nouveaux acteurs sont arrivés sur le marché. De mon point de vue, il y a deux grands acteurs qui ont attiré mon attention, que j’ai eu l’occasion de tester :

• Cube
• dbt Semantic Layer qui permet d’intégrer la définition du Semantic Layer au reste des transformations de données.
• Looker Modeler qui permet d’utiliser LookML dans d’autres outils de visualisation.

Il y a d’autres acteurs que je connais moins et le choix de l’outil dépend énormément de vos besoins. Je vous prépare un récapitulatif de ces différentes solutions. Et la semaine prochaine, je vous propose une démonstration du Semantic Layer de dbt sur LinkedIn afin de comprendre encore mieux ce que ça implique.

J’espère que grâce à cet article, vous voyez un peu mieux ce que signifie le Semantic Layer dont on entend de plus en plus parler. Et à raison car il peut résoudre de nombreux problèmes d’organisation de la donnée. N’hésitez pas à me contacter si vous souhaitez avoir des conseils afin de mettre en place cette stratégie au sein de votre entreprise.