Qu'est-ce que la Business Intelligence ?
La Business Intelligence (BI) désigne l'ensemble des processus, technologies et outils qui permettent de collecter, d'integrer, d'analyser et de presenter des informations business pour faciliter la prise de décision. Son objectif fondamental : transformer des données brutes en informations actionnables pour les dirigeants, les managers et les équipes opérationnelles — a la bonne granularite, au bon moment et dans le bon format.
La BI englobe le reporting périodique (tableaux de bord hebdomadaires ou mensuels qui resument la performance), l'analyse ad hoc (requetes ponctuelles sur les données pour répondre a une question métier spécifique), et de plus en plus l'analytique augmentée (suggestions automatiques, détection d'anomalies, alertes et explications basées sur l'IA). Elle se distingue clairement de la Data Science : la BI répond aux questions descriptives ('que s'est-il passe ?') et diagnostiques ('pourquoi ?'), la Data Science répond aux questions prédictives ('que va-t-il se passer ?') et prescriptives ('que devrait-on faire ?').
Les quatre niveaux d'analytique
Le modèle d'analytique de Gartner définit quatre niveaux progressifs. L'analytique Descriptive (que s'est-il passe ?) est le fondement de la BI : tableaux de bord, rapports, agrégations historiques — la majorite des organisations s'arrete ici. L'analytique Diagnostique (pourquoi cela s'est-il passe ?) explore les causes via le drill-down, la segmentation et la comparaison de cohortes. L'analytique Prédictive (que va-t-il se passer ?) utilise des modèles statistiques et ML pour anticiper : churn, demande, defauts. L'analytique Prescriptive (que devrait-on faire ?) recommande des actions optimales : optimisation de prix, allocation de budget, personnalisation.
La BI traditionnelle couvre les deux premiers niveaux. Les plateformes BI modernes (Power BI, Tableau, Looker) integrent progressivement des capacités prédictives via des connecteurs ML, des API OpenAI et des fonctionnalites d'analytique augmentée qui detectent automatiquement les anomalies et les tendances significatives.
Self-service BI et BI augmentée par l'IA
Le self-service BI est l'un des mouvements les plus significatifs des dernières années : donner aux utilisateurs métier la capacité d'interroger les données et de construire leurs propres rapports sans dépendre de l'équipe IT. Power BI, Tableau et Metabase ont ete pionniers dans cette democratisation. La condition pour que le self-service fonctionne : une couche sémantique bien définie qui expose des concepts métier plutot que des tables techniques, et un data catalog qui aide les utilisateurs a trouver et comprendre les données disponibles.
La BI augmentée par l'IA (Augmented Analytics) est la prochaine étape : les outils detectent automatiquement les correlations significatives, expliquent en langage naturel les variations d'un KPI, suggerent des visualisations pertinentes et permettent de requeter les données en langage naturel ('Montre-moi les ventes de ce trimestre par region par rapport a l'année dernière'). Power BI Copilot, Tableau Pulse et Looker Explore Assistant sont des implementations commerciales de cette tendance.
Les systèmes OLTP (Online Transaction Processing) sont optimisés pour l'ecriture fréquente de transactions (votre CRM, ERP, application mobile). Les systèmes OLAP (Online Analytical Processing, concept formalise par Ted Codd en 1993) sont optimisés pour les requetes analytiques complexes sur de grands volumes de données. La BI repose sur des systèmes OLAP (Data Warehouse, Lakehouse) alimentes depuis les systèmes OLTP via des pipelines ETL/ELT. Meler les deux dans le même système est une erreur architecturale classique.
KPI : définition, construction et pieges a éviter
Un KPI (Key Performance Indicator) est une mesure quantifiable qui evalue l'efficacité d'une organisation, d'un processus ou d'un individu par rapport a un objectif defini. La notion clé est dans 'Key' : un KPI doit être un indicateur crucial lie a un objectif stratégique, pas simplement une métrique disponible et facile a calculer.
Les critères SMART pour un bon KPI
Un KPI efficace respecte les cinq critères SMART : Spécifique (mesure une chose précise, pas une notion vague), Mesurable (quantifiable avec des données fiables et disponibles), Atteignable (realiste au regard du contexte et des ressources), Relevant (directement lie aux objectifs stratégiques de l'organisation), et Borne dans le Temps (avec une période de référence claire et une fréquence de mesure définie).
Exemple de KPI SMART : 'Augmenter le taux de rétention client a 90 jours de 65 % a 75 % d'ici Q4 2026 via les nouvelles fonctionnalites d'onboarding.' Contre-exemple : 'Améliorer l'experience client.' — ce n'est ni mesurable, ni spécifique, ni borne dans le temps. La formulation du KPI force la précision sur ce qu'on mesure, comment et jusqu'ou.
KPI de retard vs KPI d'avance
Les KPI de retard (lagging indicators) mesurent des résultats passes qui confirment une tendance deja accomplie : chiffre d'affaires, taux de churn, Net Promoter Score (NPS), EBITDA. Ils sont fiables et faciles a mesurer mais ne permettent pas d'anticiper ni d'agir en amont. Les KPI d'avance (leading indicators) mesurent des signaux prédictifs qui annoncent les résultats futurs : nombre de demos planifiées (precede les signatures), taux d'activation des nouvelles fonctionnalites (anticipe la rétention), time-to-first-value (predit le churn).
Un tableau de bord stratégique équilibre combine les deux : les lagging KPIs montrent ou on en est, les leading KPIs signalent la direction dans laquelle on se dirige et permettent d'agir avant que les résultats finaux soient fixes.
OKR vs KPI : deux logiques complémentaires
Les OKR (Objectives and Key Results), popularises par Google, combinent un objectif qualitatif ambitieux (O) avec 3 a 5 résultats clés mesurables qui definissent le succès (KR). Exemple : O = 'Devenir la référence de confiance pour les équipes data' ; KR1 = 'Atteindre 10 000 decks générés par le catalogue'; KR2 = 'NPS des utilisateurs pro > 50'. Les OKR sont typiquement trimestriels, ambitieux (score cible 0,7/1) et axes sur l'impact.
Les KPIs sont permanents et mesurent la performance continue d'un processus ou d'une activite existante. Les OKRs sont temporaires et mesurent le progres vers un objectif de transformation. En pratique : les OKRs se fixent en debut de trimestre et nourrissent les KPIs opérationnels qui les suivent. Un OKR devient un KPI quand l'objectif est atteint et devient la nouvelle normale a maintenir.
Les vanity metrics donnent l'illusion de succès sans être actionnables. 'Nombre de pages vues', 'Nombre d'inscrits', 'Nombre de followers' sont souvent des vanity metrics si elles ne sont pas correlées aux objectifs business réels. Le test simple : 'Que fera-t-on différemment si ce KPI double ?' Si la réponse est 'rien de different', c'est probablement une vanity metric. Privilégier les métriques actionnables : taux d'activation, revenue par utilisateur actif, taux de rétention a 30/60/90 jours.
Les outils BI du marche
Le marche des outils BI s'est segmente entre solutions enterprise historiques, nouvelles plateformes cloud-native et outils open-source modernes. Le bon outil depend de l'écosystème cloud, des competences de l'équipe et des cas d'usage cibles.
Microsoft Power BI et DAX
Power BI est le leader mondial du marche BI selon le Magic Quadrant Gartner, particulièrement dominant dans les organisations Microsoft (Azure, Office 365, Teams). Son interface de construction de dashboards par drag-and-drop est accessible aux utilisateurs métier ; son moteur analytique Power Pivot (columnar in-memory) offre d'excellentes performances sur des millions de lignes. Power BI Desktop est gratuit ; Power BI Service (collaboration cloud, partage, planification des actualisations) nécessite une licence Pro (10 euros/utilisateur/mois) ou Premium.
DAX (Data Analysis Expressions) est le langage de formules de Power BI pour les calculs avances. Il permet de creer des mesures calculées contextuelles — CALCULATE, SUMX, DATEADD — pour des agrégations complexes comme le cumul glissant 12 mois, la croissance year-over-year ou le panier moyen filtre par segment. DAX a une courbe d'apprentissage prononcée mais est très puissant pour les analyses temporelles et les filtrages contextuels.
Tableau (Salesforce)
Tableau est la référence pour les visualisations analytiques avancées. Son interface de drag-and-drop permet a des non-développeurs de creer des visualisations sophistiquées (scatter plots, treemaps, cartes geographiques interactives, small multiples) sans ecrire de SQL. Rachete par Salesforce en 2019, Tableau s'intègre nativement dans l'écosystème CRM et dans Salesforce Data Cloud.
Tableau se distingue par ses capacités de dataviz et d'exploration visuelle : Table Calculations pour les analyses en séries temporelles, Level of Detail (LOD) Expressions pour les agrégations a granularite variable, et Tableau Pulse pour la détection automatique d'insights. Il est souvent prefere par les équipes analytique et les Data Journalists qui valorisent l'exploration et la communication visuelle des données.
Looker (Google) et LookML
Looker se distingue fundamentalement par son architecture : plutot que de stocker les données, il génère du SQL a la volée et le pousse directement vers le Data Warehouse. LookML, le langage de modélisation de Looker, définit la couche sémantique — les dimensions (colonnes), les mesures (agrégations), les sets de filtres et les explorations — en YAML. Cette définition est centralisée, versionnée dans Git, et toutes les requetes Looker derivent de ce modèle.
Rachete par Google en 2019, Looker s'intègre nativement dans Google Cloud et BigQuery. Looker Studio (ex-Data Studio) est la version gratuite, plus accessible mais sans LookML. Looker est le choix privilégie des organisations data-mature qui veulent une single source of truth pour toutes leurs métriques et qui valorisent la gouvernance et la cohérence des indicateurs.
Metabase, Apache Superset et BI embarquée
Metabase est l'outil BI open-source le plus accessible : sans SQL, les utilisateurs métier construisent des rapports via une interface guidée (filtres, groupements, agrégations en quelques clics). Metabase Cloud est la version SaaS ; la version open-source se self-hoste facilement. Apache Superset est l'alternative open-source plus puissante, adoptée par des organisations comme Airbnb, Lyft et Preset : support SQL complet, visualisations avancées, plugins, API pour l'embarquement.
La BI embarquée (Embedded BI) intègre des tableaux de bord BI directement dans des applications tierces via des iframes ou des SDK. Grafana (open-source, usage historique pour le monitoring infrastructure) est de plus en plus utilise pour la BI opérationnelle embarquée. Redash, Preset (Superset as-a-service) et Lightdash (open-source, dbt-native) sont des alternatives modernes.
Modélisation dimensionnelle : star schema, grain et SCD
La modélisation dimensionnelle est le fondement technique des Data Warehouses analytiques. Formalisée par Ralph Kimball dans 'The Data Warehouse Toolkit' (1996), elle structure les données pour optimiser les requetes OLAP et faciliter la compréhension par les utilisateurs métier non techniques.
Le star schema : table de faits et tables de dimensions
Le star schema place une table de faits au centre, entourée de tables de dimensions. La table de faits contient les événements mesurables (transactions, ventes, clics, appels) avec leurs mesures numeriques (montant, durée, quantité) et des clés etrangeres vers chaque dimension. Les tables de dimensions contiennent les attributs descriptifs qui donnent le contexte : dimension Date (jour, semaine, mois, trimestre, année, jour ferie), dimension Client (nom, segment, region, date d'acquisition), dimension Produit (catégorie, marque, prix catalogue).
Le schema est appele 'etoile' car les dimensions rayonnent autour de la table de faits comme les branches d'une etoile. Les jointures sont simples (une jointure par dimension), ce qui optimise fortement les performances des requetes OLAP — contrairement aux schemas normalisés (3NF) qui nécessitent de multiples jointures. Un utilisateur métier comprend naturellement ce schema : il raisonne 'ventes par produit par mois par region', ce qui se traduit directement en dimensions.
Le grain de la table de faits : le choix fondateur
Le 'grain' est la définition précise de ce que représente une ligne dans la table de faits — c'est la décision la plus importante de toute modélisation dimensionnelle. Un grain mal defini créé des problèmes d'agrégation impossibles a corriger sans refactoring complet. Exemples : 'une ligne = une transaction commerciale' (grain transactionnel), 'une ligne = un snapshot journalier de l'état d'un compte' (grain périodique), 'une ligne = un événement de clic' (grain evenementiel).
Le grain dicte quelles dimensions sont naturellement disponibles et quelles agrégations sont valides. Un grain transactionnel ne peut pas directement compter le 'nombre de clients actifs ce mois' (agrégation dédupliquée) sans une agrégation intermédiaire. Definir le grain avec précision avant de construire les tables de faits évite des mois de dette technique analytique.
Slowly Changing Dimensions (SCD) : gerer l'historique des dimensions
Les dimensions changent dans le temps : un client change de region, un employe change de departement, un produit change de catégorie. Les Slowly Changing Dimensions (SCD) definissent comment gerer ces evolutions. SCD Type 1 : on ecrase l'ancienne valeur par la nouvelle — simple mais on perd l'historique (un rapport sur les ventes 'par region du client' donnera la region actuelle, pas celle au moment de la vente). SCD Type 2 : on ajoute une nouvelle ligne avec les colonnes effective_date et expiry_date (ou is_current boolean) — on conserve l'historique complet au prix de la multiplication des lignes.
Le SCD Type 3 ajoute une colonne 'valeur précédente' (current_region + previous_region) — compromis limité qui ne gere que le dernier changement. Le SCD Type 4 utilise une table d'historique séparée. En pratique, le SCD Type 2 est utilise dans 80 % des cas quand l'historique est important. dbt propose le package dbt_utils et Snapshots pour implementer le SCD Type 2 automatiquement via le delta entre deux executions.
Dimensions conformes et bus architecture Kimball
Les dimensions conformées (conformed dimensions) sont des tables de dimensions partages entre plusieurs tables de faits et datamarts. La dimension Date est l'exemple canonique : la même table de dates est utilisée par les faits de ventes, les faits de production, les faits de support client. Cela permet de combiner les faits de differents domaines en un seul rapport (ventes + tickets support par mois) car ils partagent la même clé de dimension.
La 'bus architecture' de Kimball est une matrice qui liste les datamarts en lignes et les dimensions en colonnes — une coche indiquant quelles dimensions sont conformées entre quels datamarts. C'est l'outil de planification qui garantit l'interoperabilite entre les differentes zones analytiques d'un Data Warehouse.
Ralph Kimball a formalise la modélisation dimensionnelle dans 'The Data Warehouse Toolkit' (1996, 3e édition 2013). Son approche bottom-up (partir des processus métier) s'oppose a celle de Bill Inmon (top-down, modèle entreprise normalise d'abord). Les deux methodologies coexistent : Kimball domine pour les nouveaux projets pragmatiques, Inmon reste présent dans les grandes organisations avec des requirements de cohérence forte.
Kimball, R., Ross, M. - The Data Warehouse Toolkit, 3rd Édition, 2013La couche sémantique : une source unique de vérité pour les métriques
La couche sémantique (semantic layer) est une couche d'abstraction entre les données brutes (Data Warehouse, Lakehouse) et les outils BI. Elle centralise les définitions des métriques business, les logiques de calcul et les droits d'accès, et les expose de façon cohérente a tous les outils de reporting et d'analyse.
Le problème qu'elle resout est fondamental : sans couche sémantique, chaque outil BI ou chaque analyste recalcule ses propres métriques selon sa propre logique. Le taux de conversion dans Power BI diffère de celui dans Tableau parce que les équipes ont des définitions subtitement differentes du denominateur ('sessions avec au moins une page produit' vs 'sessions totales'). Multiplier par 10 le nombre d'outils et d'analystes, et le chaos métrique devient un problème de gouvernance majeur.
dbt Semantic Layer et MetricFlow
dbt Semantic Layer (anciennement dbt Metrics, base sur MetricFlow) permet de definir des métriques directement dans le projet dbt, en YAML. On définit la métrique une fois — son nom, son type (simple, ratio, dérive), sa granularite temporelle, ses dimensions de découpe — et MetricFlow génère le SQL optimal pour chaque outil consommateur. Ces métriques sont versionnées dans Git, documentées via dbt Docs, testées avec les mêmes frameworks que les transformations SQL.
La compatibilité de dbt Semantic Layer s'etend a Tableau, Power BI, Hex, Mode et les outils compatibles JDBC/API. L'avantage clé par rapport a Looker : les métriques restent dans le projet dbt dont la plupart des organisations dépendent deja pour leurs transformations, evitant une couche supplémentaire.
LookML et Cube.js : deux approches de la couche sémantique
LookML (Looker) est la solution la plus mature du marche : un langage YAML qui définit dimensions, mesures, joins et explorations. Tout utilisateur Looker passe par LookML — il est impossible de construire une requete ad hoc sans passer par la couche sémantique, ce qui garantit une cohérence totale. L'inconvenient : LookML est exclusif a Looker et créé une dépendance forte a l'écosystème Google.
Cube.js est la solution open-source de couche sémantique indépendante de l'outil BI. Il expose une API REST/GraphQL/SQL que n'importe quel outil peut consommer — on définit les cubes (entités analytiques), leurs dimensions et mesures en JavaScript ou YAML, et Cube génère le SQL optimise pour chaque source (BigQuery, Snowflake, Postgres, ClickHouse). C'est le choix pour les organisations qui veulent une couche sémantique sans être liées a un outil BI spécifique.
La couche sémantique n'est pas un luxe — c'est l'infrastructure de gouvernance des métriques. Sans elle, la croissance du nombre d'analystes, d'outils et de dashboards créé inévitablement une fragmentation des définitions qui mine la confiance dans les données. Quand le CFO et le CMO présentent des chiffres de croissance differents au board avec des sources toutes deux 'officielles', le problème n'est pas technique — c'est l'absence de couche sémantique.
Data Visualization et data storytelling : construire des dashboards efficaces
La data visualisation ne consiste pas a rendre les données belles — elle consiste a les rendre intelligibles et actionnables. Un bon dashboard guide l'attention de l'utilisateur vers les informations les plus importantes et lui permet de prendre une décision ou de poser une question plus précise. Un mauvais dashboard noie les informations clés dans du bruit visuel.
Choisir le bon type de graphique
Le choix du graphique depend du type de comparaison que vous voulez communiquer. Les comparaisons de valeurs entre catégories : bar chart (horizontal pour les labels longs) ou column chart (vertical pour les séries temporelles courtes). Les evolutions dans le temps : line chart pour les tendances continues, area chart pour montrer le volume. Les proportions : pie chart pour 3 a 4 catégories maximum (au-dela, utiliser un bar chart horizontal trie). Les correlations entre deux variables : scatter plot. Les distributions : histogram ou box plot.
Trois erreurs courantes a éviter : les pie charts avec plus de 5 segments (illisibles), les axes Y qui ne commencent pas a zero (distorsion de l'amplitude des variations), et les graphiques 3D (la profondeur créé une distorsion perceptive). La règle simple : si le graphique nécessite une legende pour être compris, il est probablement trop complexe.
Principes de design d'un tableau de bord efficace
Un tableau de bord efficace respecte la hiérarchie d'information : le KPI le plus important en haut a gauche (le regard occidental commence toujours en haut a gauche), le contexte et les detaills en dessous et a droite. Limiter a 5-7 KPIs par dashboard — au-dela, l'attention se fragmente et aucun KPI n'est vraiment surveille. Chaque KPI doit avoir sa baseline de référence (objectif, période précédente, benchmark) sans laquelle la valeur brute est difficile a interpréter.
Le data storytelling structure les insights en narration : contexte (qu'est-ce qui se passe ?), complication (quel est le problème ou l'écart ?) et résolution (quelle action recommandez-vous ?). Les meilleurs dashboards guident l'utilisateur de l'observation a l'action, pas seulement de la question a la donnée.
La multiplication des dashboards dans une organisation est un symptome de mauvaise gouvernance BI. Quand chaque équipe créé ses propres dashboards avec ses propres définitions, les décideurs ne savent plus quel chiffre croire. Un audit régulier (semestriel) des dashboards actifs — nombre de vues, dernier accès, doublons sémantiques — permet d'identifier et de deprecier les dashboards inutilises et de consolider les définitions fragmentées.
Consolider vos connaissances BI avec la répétition espacée
La BI combine des concepts métier (KPI, métriques, OKR, vanity metrics) et des concepts techniques (star schema, SCD, DAX, LookML, couche sémantique). Ces notions s'entremellent facilement en pratique — la frontiere entre un KPI et une métrique, entre un leading et un lagging indicator, entre un star schema et un snowflake schema sont des questions typiques d'entretien Data Analyst et BI Engineer.
Les flashcards Memia couvrent les concepts fondamentaux de BI et KPI avec des cartes formulées pour tester la compréhension (pas la memorisation mecanique) : formulations comparatives, cas pratiques de choix entre deux approches, et questions ouvertes sur les trade-offs.
Les thèmes les plus recurrents en entretien Data Analyst et BI : différence KPI vs métrique (et comment defendre un choix de KPI), star schema vs snowflake schema (trade-offs), SCD Type 1 vs Type 2 (et quand choisir lequel), lagging vs leading KPIs (avec des exemples concrets), DAX vs SQL vs LookML (quand utilise-t-on lequel ?), et le role de la couche sémantique. Maîtriser ces comparaisons est plus utile que de memoriser des définitions isolées.
Approfondir le cluster Data & IA
Questions fréquentes sur la Business Intelligence et les KPI
Qu'est-ce que la Business Intelligence ?
La Business Intelligence est l'ensemble des processus, technologies et outils qui permettent de collecter, analyser et presenter des informations pour faciliter la prise de décision. Elle répond aux questions descriptives ('que s'est-il passe ?') et diagnostiques ('pourquoi ?'), et se distingue de la Data Science qui répond aux questions prédictives ('que va-t-il se passer ?') et prescriptives ('que devrait-on faire ?').
Quelle est la différence entre un KPI et une métrique ?
Une métrique est toute mesure quantifiable (nombre de visites, durée moyenne de session, chiffre d'affaires). Un KPI est une métrique specifiquement choisie parce qu'elle est cruciale pour mesurer la performance par rapport a un objectif stratégique. Tous les KPIs sont des métriques, mais toutes les métriques ne sont pas des KPIs. Test simple : si doubler cette métrique ne changerait pas les décisions de l'équipe, c'est une métrique, pas un KPI.
Quelle est la différence entre un KPI de retard et un KPI d'avance ?
Les KPIs de retard (lagging indicators) mesurent des résultats passes : chiffre d'affaires, NPS, taux de churn. Ils confirment une tendance deja accomplie. Les KPIs d'avance (leading indicators) mesurent des signaux prédictifs qui annoncent les résultats futurs : nombre de demos planifiées, taux d'activation, time-to-first-value. Un bon tableau de bord combine les deux : les lagging KPIs disent ou on en est, les leading KPIs signalent ou on va.
Quel outil BI choisir : Power BI, Tableau ou Looker ?
Power BI est le choix naturel dans les écosystèmes Microsoft (Azure, Office 365), avec des licences accessibles et un moteur DAX puissant. Tableau est prefere pour l'exploration visuelle avancée et les dataviz sophistiquées, notamment dans les grandes organisations analytique. Looker est optimal pour les organisations data-driven qui veulent une couche sémantique centralisée (LookML) et une intégration Google Cloud/BigQuery.
Qu'est-ce qu'un star schema ?
Un star schema est un modèle de données analytique avec une table de faits centrale (qui contient les mesures quantitatives : ventes, revenus, quantités) entourée de tables de dimensions (qui contiennent les contextes descriptifs : date, produit, client, region). Les jointures sont simples et les performances OLAP excellentes. Il est appele 'etoile' car le schema dessine une etoile avec la table de faits au centre.
Qu'est-ce qu'une Slowly Changing Dimension (SCD) ?
Une SCD gere l'évolution dans le temps d'une dimension (ex: un client change de region). Type 1 : on ecrase l'ancienne valeur (simple, mais perd l'historique — la region actuelle remplace la region au moment de la vente). Type 2 : on ajoute une nouvelle ligne avec les dates de validité effective_date/expiry_date — conserve l'historique complet. Le Type 2 est le plus utilise quand l'analyse historique est importante.
Qu'est-ce que la couche sémantique ?
La couche sémantique est une couche d'abstraction entre les données brutes et les outils BI. Elle centralise les définitions des métriques pour garantir qu'elles sont calculées de la même façon dans tous les outils. Sans elle, le taux de conversion dans Power BI peut differer de celui dans Tableau selon la logique de chaque analyste. dbt Semantic Layer, LookML (Looker) et Cube.js sont les solutions leaders.
Qu'est-ce que DAX dans Power BI ?
DAX (Data Analysis Expressions) est le langage de formules de Power BI pour les calculs avances. Il permet de creer des mesures calculées contextuelles (CALCULATE, SUMX, DATEADD) pour des agrégations complexes : cumul glissant 12 mois, croissance year-over-year, panier moyen filtre par segment. DAX a une courbe d'apprentissage prononcée mais est très puissant pour les analyses temporelles et les filtrages contextuels complexes.
Qu'est-ce que la différence entre OKR et KPI ?
Les KPIs (Key Performance Indicators) mesurent la performance continue d'un processus existant et sont permanents. Les OKRs (Objectives and Key Results) combinent un objectif ambitieux et temporaire avec des résultats clés mesurables pour le trimestre. En pratique : les OKRs se fixent en debut de trimestre et definissent les KPIs a faire progresser. Un OKR devient un KPI quand l'objectif est atteint et devient la nouvelle normale a maintenir.
Qu'est-ce que le self-service BI ?
Le self-service BI donne aux utilisateurs métier la capacité de construire leurs propres rapports et d'interroger les données sans dépendre de l'équipe IT. Il nécessite une couche sémantique bien définie (pour exposer des concepts métier plutot que des tables techniques) et un data catalog (pour aider les utilisateurs a trouver et comprendre les données). Power BI, Tableau et Metabase sont les outils les plus utilises pour le self-service BI.
Article précédent : Data Governance - définition et mise en oeuvre