À quoi ressemble un bon dispositif BI

Le dashboard est la partie de la business intelligence que l’organisation voit. Le dispositif BI, c’est l’iceberg en dessous : l’entrepôt où la donnée vit réellement, la couche sémantique où les métriques sont définies, le catalogue où les définitions et les propriétaires sont documentés, le calendrier de rafraîchissement qui décide si le chiffre d’hier est bien celui d’hier, et le modèle d’accès qui décide qui a le droit d’écrire le SQL derrière. La plupart des plaintes « le dashboard est faux » sont en réalité des plaintes « le dispositif BI est faux », et aucun retravail du dashboard ne les corrigera.

Cet article porte sur les parties de la business intelligence qui n’apparaissent presque jamais dans une présentation et qui décident presque toujours si les dashboards par-dessus peuvent être de confiance. Il s’associe à l’article sur la stratégie data, qui se situe un niveau au-dessus et cadre les décisions que le dispositif BI est censé servir ; ici, l’angle est sur l’infrastructure ennuyeuse qui rend possibles, en premier lieu, des dashboards qui tiennent.

Un dispositif BI qui marche sépare les systèmes opérationnels (le CRM, l’ERP, la base de l’application où les transactions se passent) du store analytique (l’entrepôt) où les requêtes de reporting et d’analytics tournent réellement. La séparation n’est pas optionnelle dès que l’organisation a plus d’une poignée d’utilisateurs et plus d’une poignée de métriques. Faire tourner de l’analytique contre la base opérationnelle produit deux échecs prévisibles : le système opérationnel ralentit quand le rapport tourne, et le schéma analytique est faux parce que le schéma opérationnel a été conçu pour les écritures, pas pour les lectures.

L’entrepôt est le premier critère de qualité. Que ce soit Snowflake, BigQuery, Postgres-en-entrepôt, DuckDB à petite échelle, ou autre chose, ce qui compte, c’est qu’il y ait un endroit unique où vit la version analytique de la vérité, alimentée par des pipelines d’ingestion que l’équipe comprend et qu’elle peut réparer quand ils cassent.

Au-dessus de l’entrepôt se trouve la couche sémantique : l’endroit où les métriques sont définies une fois et réutilisées partout. « Client actif », « revenu mensuel récurrent », « temps moyen de résolution » existent comme définitions nommées et versionnées dans un artefact unique (un projet dbt, un modèle LookML, un schéma Cube, parfois juste un ensemble de vues d’entrepôt bien disciplinées), et chaque dashboard, rapport ou notebook qui utilise ces métriques référence la même définition. Sans couche sémantique, la même métrique se fait redériver de cinq façons différentes dans cinq dashboards différents, et « client actif » veut dire un chiffre différent selon la page que vous lisez.

Une couche sémantique, c’est de l’infrastructure technique. Un catalogue de métriques, c’est la documentation lisible par les humains qui va avec. Pour chaque métrique sur laquelle l’organisation reporte, le catalogue répond : quelle est la définition (en une phrase), quel est le SQL ou la formule derrière, qui en est propriétaire, quand a-t-elle été modifiée pour la dernière fois, quelle est la cadence de rafraîchissement, et où apparaît-elle (quels dashboards, quels rapports, quelles APIs).

Un catalogue qui marche est court et à jour. Les longs catalogues que personne ne maintient sont pires que pas de catalogue, parce qu’ils créent un faux sens de gouvernance. La discipline, c’est de garder le catalogue plus étroit que ce que l’équipe voudrait (seulement les métriques qui comptent réellement) et d’imposer que toute nouvelle métrique ajoutée à un dashboard doive d’abord apparaître dans le catalogue. Sans cette imposition, le catalogue dérive et les dashboards recommencent silencieusement à définir leurs propres versions privées de « client actif ».

Le catalogue est aussi l’endroit où les utilisateurs métier vont quand ils doutent d’un chiffre. « Que veut dire revenu ici » devrait avoir une réponse en un clic, liée depuis chaque dashboard qui affiche un revenu. Un dispositif BI où cette réponse est « demande à l’équipe data » est un dispositif où l’équipe data est le goulot d’étranglement de la confiance.

Chaque jeu de données dans l’entrepôt a, implicitement ou explicitement, un SLA de rafraîchissement : à quel point la donnée est censée être fraîche quand un utilisateur la lit. Pipeline commercial mis à jour toutes les heures. Attribution marketing mise à jour quotidiennement à 06h00. Chiffres de clôture financière mis à jour dans les trois jours ouvrés après la fin de la période. La version implicite de ces SLAs (« on rafraîchit quand le pipeline tourne ») est ce qui produit des dashboards auxquels l’utilisateur ne fait pas confiance parce qu’il ne peut pas dire s’il lit de la donnée actuelle ou périmée.

Un dispositif BI qui marche rend le SLA explicite par jeu de données, surveille si le rafraîchissement le respecte réellement, et fait remonter un signal « périmé » sur tout artefact qui lit un jeu de données ayant manqué sa fenêtre. Le signal n’a pas besoin d’être élaboré ; un point coloré, un badge « dernière mise à jour il y a 14 heures, attendue dans les 4 », une alerte automatisée vers l’équipe data. Le point, c’est que l’utilisateur puisse dire si la fraîcheur qu’il attend est la fraîcheur qu’il a obtenue.

La même discipline s’applique aux changements de schéma. Une colonne renommée dans le système source sans préavis ne devrait pas silencieusement changer ce que l’entrepôt calcule ; soit le changement est annoncé et les définitions en aval sont mises à jour ensemble, soit le pipeline échoue bruyamment jusqu’à ce qu’elles le soient.

Un dispositif BI dont les tables, vues et métriques sont nommées de façon cohérente est un dispositif beaucoup plus rapide à intégrer pour de nouveaux analystes et beaucoup plus difficile à mal utiliser. Les conventions sont petites mais elles s’accumulent : tables préfixées par domaine (sales_, support_, finance_), tables de staging clairement distinguées des tables de production, colonnes en snake_case avec unités explicites (revenue_eur plutôt que revenue), colonnes booléennes préfixées par is_ ou has_. Rien de tout cela n’est glamour ; tout cela évite aux analystes de lancer la mauvaise requête sur la mauvaise table parce que les noms se ressemblaient.

L’accès compte autant que le nommage. Un dispositif BI qui marche a des réponses claires à : qui peut lire chaque jeu de données, qui peut changer une définition de métrique dans la couche sémantique, qui peut publier un nouveau dashboard dans un espace partagé, et qui peut éditer un dashboard qui existe déjà. Un accès trop large produit cinq versions contradictoires de la même réponse ; un accès trop strict produit une file d’attente devant l’équipe data. Le bon réglage est entre les deux, et c’est généralement une combinaison d’accès en lecture par rôle sur l’entrepôt, d’accès en écriture sur la couche sémantique restreint à un petit groupe, et d’un workflow de relecture léger pour les nouveaux dashboards avant qu’ils n’apparaissent dans les espaces partagés.

Un dispositif BI qui ne nomme pas de propriétaires à chaque couche est un dispositif où tout devient silencieusement le problème de l’équipe data. L’entrepôt a un propriétaire technique (l’ingénierie data). Chaque domaine à l’intérieur de l’entrepôt a un propriétaire métier (commercial, finance, produit, support) qui est redevable de ce que la donnée veut dire et de sa fiabilité. Chaque métrique du catalogue a un propriétaire nommé qui peut répondre à « ça a augmenté à cause de X » sans escalader. Chaque dashboard a un propriétaire qui est responsable de le retirer quand la décision sous-jacente a bougé.

La propriété est ce qui transforme un dispositif BI d’un empilement d’outils en un système qui fonctionne. Sans elle, chaque changement dans les systèmes sources est un exercice d’incendie, chaque question « le chiffre semble faux » devient une enquête multi-équipes, et chaque retrait d’une métrique obsolète cale parce que personne ne peut être sûr que personne d’autre n’en dépend encore.

La version la moins chère de cela, c’est de tenir une liste de propriété à jour à côté du catalogue de métriques : nom (ou rôle) par jeu de données, par métrique, par dashboard, avec une règle de rotation quand les gens partent. La version chère, c’est ce qui se passe quand personne ne se donne la peine de tenir la version pas chère.

Un bon dispositif BI, ce n’est pas la stack la plus sophistiquée ; c’est celui où les définitions vivent à un seul endroit, où les SLAs de rafraîchissement sont explicites, où le nommage et l’accès sont prévisibles, et où chaque couche a un propriétaire nommé. Les dashboards construits par-dessus ce dispositif peuvent être de confiance parce que l’infrastructure en dessous est de confiance. Les dashboards construits par-dessus un dispositif sans ces critères peuvent être élégants, bien conçus et entièrement corrects en isolation, et produire malgré tout des chiffres dont l’organisation a des raisons de douter.

Le contexte plus large, dont la stratégie qui décide quelles métriques comptent, la conception des dashboards qui les fait remonter, et la couche d’ingénierie qui alimente l’entrepôt, est rassemblé dans le cluster systèmes de données et performance. Et lorsque la question passe de « nous avons un outil de BI mais les chiffres qu’on en sort ne sont pas de confiance » à « il nous faut concevoir l’entrepôt, la couche sémantique, le catalogue et la propriété qui transforment l’outil en un dispositif qui marche », c’est exactement ce sur quoi mon accompagnement analyse de données et aide à la décision est centré.