Bi as code avec Evidence.dev
"Les meilleurs tableaux de bord sont construits avec du code", annonce fièrement le site d'Observablehq. Bien que cette déclaration puisse sembler excessive à première vue, elle reflète une nouvelle tendance émergente dans le domaine des outils analytiques : le concept de "BI as code".
Les outils "BI as code" représentent une nouvelle génération d'outils qui permettent de créer des tableaux de bord interactifs ou des rapports sous forme de pages web aussi facilement qu’en écrivant des documents en Markdown. En simplifiant le processus de création de tableaux de bord interactifs, ils offrent également une approche plus accessible pour l'hébergement, générant des pages HTML statiques qui ne nécessitent pas d'infrastructure complexe.
Regardons de près l'outil open-source Evidence.dev, qui incarne cette approche innovante.
Le principe de fonctionnement d’Evidence est le suivant et repose dans les grandes étapes suivantes :
Se connecter aux sources de données et capturer celles-ci dans un extrait stocké localement
Ecrire des pages de rapports en markdown avec des requêtes SQL et des composants d’affichages des données.
Construire les rapports sous forme de pages HTML statiques et de fichiers de données hébergeable sur un site web.
Au delà de pages statiques présentant des données, Evidence ajoute de l’interactivité en permettant de faire des pages paramétrées pour avoir une forme de “Drill down”.
La magie opère grâce au fait d’embarquer dans les pages web générées un moteur DuckDB en sous forme de module WASM. Ce moteur permet de reconstituer les données devant être affichées à partir des fragments stockés sur le serveur.
Une fois démarré le service on obtient cette page d’exemple qui permet de vérifier le bon fonctionnement :
Première page !
Remplaçons le fichier index.md fourni par ces quelques lignes :
---
title: Ventes de produits
---
```sql categories
select
category, sum(sales) as sales_usd,
from needful_things.orders
group by category
```
Cette page détaille des statistiques de ventes de produits par catégories
<BarChart
data={categories}
x=category
y=sales_usd
swapXY=true
/>Le bloc de code sql crée un objet de donnée “categorie” qui va pouvoir être exploité par le BarChart intégré à la page. Vous pouvez mettre plusieurs requêtes dans votre page et les chainer entre elles avec une expression du type FROM ${somedata} dans le SQL.
Pages avec templates
Le principe des pages avec template est de définir une page qui va être générée lors du “build” pour toutes les combinaisons de données possibles correspondant au paramètre.
On commence par définir la page appelante, avec une table présentant toute les catégories dans notre cas. Dans cette table on va définir un attribut “link” qui va donner la destination à suivre en cas de click sur la ligne. Cette page appelante est dans notre cas la page par défaut du dossier “catégories”
<!-- index.md -->
<DataTable
data={categories}
link=category_link
/>
```sql categories
SELECT
category,
COUNT(*) AS "Nombre de ventes",
'/categories/' || category as category_link
FROM needful_things.orders
GROUP BY category
```Pour répondre à la requête on va pouvoir définir une page prenant en compte le paramètre présent dans l’URL appelée. La page doit porter le nom du paramètre entre crochets. Dans cette page, la requête SQL va prendre un clause de filtrage basée sur ce paramètre qu’on récupère dans la variable params.category
<!-- [category].md -->
```sql all_sales_by_cat
SELECT
...
FROM needful_things.orders
WHERE category = '${params.category}'
```Lors du build on va avoir autant de pages que de catégories qui vont être générées. Chaque page d’index se trouvant dans le dossier qui porte le nom de la catégorie.
Construction et Déploiement
Pour construire le site, il suffit de lancer la commande npm build qui va faire appel à Evidence pour extraire les données en se connectant à la source et va créer les pages html nécessaires. Dans l’arborescence on retrouve des fichiers parquet et des fichiers arrow qui seront downloadés lors de l’affichage des pages.
Assez simplement, ce processus peut être intégré dans une chaine de CI/CD qui pourra facilement consommer les commits sur le repository Git pour lancer la construction et deployer le contenu sur un hébergement web.
Conclusion
Cette découverte de Evidence valide le fait qu’une BI complète n’est pas nécessaire dans une immense majorité des cas d’utilisation. Une approche légère et minimaliste comme celle-ci permet de diffuser l’information en offrant un minimum d’interactivité et de modularité.
Dans de prochains articles, nous verrons dans quelle mesure il est possible d’aller beaucoup plus loin dans l’interactivité offerte aux utilisateurs et dans la personnalisation. Aussi nous explorerons d’autres solutions comme observableHq qui offrent des possibilités de customisations très avancées.