Contexte et motivations

Le modèle traditionnel des outils de Business Intelligence (BI) regroupe ingestion, transformation, calcul, mise en cache, sémantique, visualisation et gestion d’identité dans une seule application. Depuis 2015, les couches d’infrastructure se sont désagrégées : le calcul est confié aux géants du cloud, l’ingestion à Fivetran, la transformation à dbt. Cette « unbundling » a laissé les outils BI avec uniquement la visualisation et l’interface interactive, ce qui crée une friction lorsqu’un agent conversationnel doit générer un rapport : il doit produire plusieurs fichiers (HTML, CSS, JavaScript, bibliothèques de graphiques, application React ou Streamlit) avant d’obtenir un tableau de bord exploitable.

Pour réduire cette complexité, dbt Labs a publié dbt Charts, un langage structuré en YAML qui décrit un tableau de bord complet dans un seul fichier auditable. Le texte affirme que le langage possède plus de 1 100 options de configuration réparties sur seize types de graphiques, tout en conservant la capacité d’exprimer des mises en page complexes.

Architecture du langage dbt Charts

Le cœur de dbt Charts repose sur trois couches : SQL pour spécifier les données, YAML pour déclarer la forme du rendu, et Jinja pour injecter variables et macros, exactement comme dans dbt. Le YAML encapsule également du Markdown, permettant d’ajouter de la prose descriptive. Un exemple minimal montre un filtre UI, une requête SQL et un graphique :

variables:
  region: "US"
queries:
  revenue: |
    SELECT date, amount FROM sales WHERE region = {{ var('region') }}
charts:
  revenue_chart:
    type: line
    query: revenue
    x: date
    y: amount

Le CLI dct rend le tableau de bord en SVG, HTML, PNG, PDF ou même directement dans le terminal ; les commandes d’exemple sont :

dct render charts/documents.yml --format svg
dct serve

Le système de thématisation repose sur l’héritage : un thème définit des styles globaux, chaque tableau de bord hérite du thème, chaque graphique hérite du tableau de bord, ce qui minimise la duplication et rend la maintenance du style « cheap ».

Intégration avec dbt et workflow CI/CD

Lorsque dbt Charts est placé dans le répertoire charts/ d’un projet dbt, il partage le même dépôt Git que les modèles models/. Ainsi, une modification de modèle et son tableau de bord associé sont soumises dans une même branche et passent par un unique pipeline CI. La validation se fait en deux temps : dbt parse && dct validate charts/ vérifie la syntaxe SQL via le manifeste dbt, et le CLI signale les incohérences visuelles (ex. bande trop étroite, débordement de colonnes). Ces avertissements, comme WARN-BAR-BAND-WIDTH-TOO-NARROW, permettent à un agent conversationnel d’ajuster automatiquement le niveau de granularité ou la largeur du conteneur avant que le tableau de bord ne soit présenté à l’utilisateur.

Le projet prévoit également un support futur du Semantic Layer de dbt, afin que les métriques définies dans le projet puissent être réutilisées sans répéter le SQL, renforçant la cohérence entre transformation et visualisation.

Analyse des impacts et limites

En externalisant les graphiques dans du code, dbt Charts élimine la dépendance à un UI propriétaire, ce qui réduit le nombre de jetons consommés par les agents LLM et accélère le cycle de feedback. La validation stricte minimise les risques d’erreurs de rendu en production, mais elle impose une courbe d’apprentissage pour les analystes non‑techniques qui doivent écrire du YAML et du SQL. De plus, la richesse de plus de 1 100 options de configuration peut entraîner une surcharge cognitive si elle n’est pas correctement documentée.

Le modèle SaaS dbtCharts.com complète l’open‑source en offrant hébergement, contrôle d’accès et éditeur visuel, mais il conserve la dépendance à une plateforme tierce pour le rendu final. Cette dualité entre code libre et service hébergé représente un compromis entre auditabilité et facilité d’utilisation, à évaluer selon les exigences de gouvernance de chaque organisation.