Evidence.dev : la BI as code, et ce qu'Evidence Core change

Evidence est un outil de BI "as code" : on écrit des pages en Markdown, on y glisse des requêtes SQL et des composants de visualisation, et on obtient des dashboards versionnés dans Git. Le sujet est devenu plus intéressant à l'été 2026, parce que le projet a changé de nature : le 26 août 2026, l'équipe a ouvert le code d'un nouveau socle, Evidence Core, qui n'est pas une simple mise à jour de l'ancienne version. Beaucoup d'articles et de tutoriels en ligne décrivent encore l'ancien fonctionnement. Cet article distingue les deux, détaille la connexion à BigQuery (le cas d'usage naturel quand on travaille avec l'export GA4), les limites de l'auto-hébergement, et compare honnêtement avec Looker Studio.

Méthode et réserves. Tout ce qui suit vient de la documentation officielle, du dépôt GitHub et du guide de migration publiés par Evidence. Je n'ai pas installé Evidence Core pour cet article : les extraits de code sont soit repris tels quels de la documentation, soit adaptés et signalés comme non exécutés. Les points que je n'ai pas pu vérifier (tarification de la partie hébergée, mise en cache des requêtes) sont indiqués comme tels.

Evidence en une minute

Le dépôt evidence-dev/evidence est open source sous licence MIT et très actif (des commits quotidiens en octobre 2026, environ 7 000 étoiles sur GitHub). L'idée de départ n'a pas changé : un rapport est un fichier texte. Les requêtes sont écrites en SQL dans la page, les graphiques sont des composants qui pointent vers le résultat d'une requête, et le tout se relit, se compare et se revoit comme du code.

Pour un consultant data ou tracking, l'intérêt est concret : le dashboard livré à un client est un dossier Git, avec un historique de modifications, des revues possibles par pull request, et un déploiement reproductible. Les outils de BI visuels n'offrent pas ce confort, même s'ils offrent d'autres avantages (voir la comparaison plus bas).

Deux Evidence à ne pas confondre

C'est le point le plus important de l'article. Jusqu'en 2026, "Evidence" désignait le paquet npm @evidence-dev/evidence (dernière version que j'ai constatée : 40.1.8, février 2026). Depuis le 26 août 2026, il existe un second socle, Evidence Core, distribué comme un binaire autonome. Le guide de migration officiel (docs.evidence.dev/guides/updating-your-app) liste les différences. Les principales :

Le guide de migration liste aussi ce qui n'a pas d'équivalent dans Core : les requêtes sources/*.sql, les composants Svelte personnalisés, les box plots, les diagrammes de Venn, les liens de drill-through sur les cartes, l'axe y secondaire (à reconstruire avec {% combo_chart %}) et les barres horizontales empilées à 100 %. Une commande evidence migrate (avec option --dry-run, CLI en version 0.9.0 ou plus) aide à convertir un projet existant.

Conséquence pratique : avant de suivre un tutoriel, regardez la date et la syntaxe. Des composants écrits <LineChart ... /> ou des pages [client].md relèvent de l'ancien socle. Les deux restent open source, mais ne sont pas interchangeables.

Installer et démarrer un projet avec Evidence Core

La documentation officielle propose un script d'installation qui télécharge le binaire. Comme pour tout script lancé via curl | sh, relisez-le avant de l'exécuter, surtout sur une machine qui détient des accès clients.

curl -fsSL https://evidence.studio/install.sh | sh

evidence init mon-dashboard --warehouse bigquery
cd mon-dashboard
evidence dev        # serveur de dev sur le port 3000

Les autres commandes utiles, d'après la documentation du CLI : evidence validate (valide la syntaxe du projet), evidence query, evidence tables, evidence describe et evidence schema (explorer l'entrepôt depuis le terminal), evidence connectors, evidence models, evidence lineage, evidence docs, ainsi que evidence serve pour la production. Les commandes launch, link et unlink relient le projet à Evidence Studio et à GitHub, la partie hébergée dont il est question plus bas.

À quoi ressemble une page

Une page est un fichier Markdown. Les requêtes sont déclarées dans la page, dans un bloc de code nommé : le nom du bloc devient le nom du jeu de données que les composants référencent. Les composants s'écrivent avec la syntaxe Markdoc. Voici deux exemples tirés de la documentation (jeu de données de démonstration demo.daily_orders) :

{% line_chart
   data="demo.daily_orders"
   x="date"
   y="sum(total_sales)"
   series="category"
   date_grain="month"
   title="Sales Over Time" /%}

{% big_value
   data="demo.daily_orders"
   value="sum(total_sales)"
   fmt="usd1m"
   date_range={ date="date" range="last 12 months" }
   comparison={ compare_vs="prior year" } /%}

Attention à un piège que j'ai rencontré en lisant la documentation : l'attribut comparison_title, qu'on devine facilement, n'existe pas. Le big_value utilise title et les options comparison.display_type, comparison.text et comparison.hide_pct. D'où l'intérêt de evidence validate : la syntaxe étant vérifiable statiquement, ce genre d'erreur se détecte avant publication.

Filtres interactifs

Pour laisser le lecteur filtrer, on déclare un composant de saisie, puis on le relie à un graphique ou à une table :

{% dropdown id="category_filter"
   data="demo.daily_orders"
   value_column="category" /%}

{% line_chart data="demo.daily_orders"
   x="date" y="sum(total_sales)"
   filters=["category_filter"] /%}

La valeur choisie peut aussi être injectée dans le SQL avec {{category_filter}}. La documentation décrit plusieurs propriétés sur ce filtre (.filter, .selected, .literal, .label, .fmt) : lisez la page dédiée pour choisir la bonne selon que vous filtrez une colonne ou construisez une clause SQL. Je n'ai pas trouvé la notation ${inputs.x} de l'ancien socle dans la documentation Core.

Connecter BigQuery (et l'export GA4)

C'est le cas d'usage qui parle le plus aux équipes analytics : l'export GA4 est déjà dans BigQuery, il manque une couche de restitution versionnée. Evidence Core se connecte à BigQuery en connexion directe (requêtes live, pas de copie préalable des données). La documentation du connecteur BigQuery décrit les points suivants :

• Authentification : la seule méthode documentée est une clé JSON de compte de service, soit en chemin de fichier (keyfile, relatif au connection.yaml), soit en contenu inline (keyfile_json), l'un ou l'autre mais pas les deux. Je n'ai trouvé ni authentification par ADC (Application Default Credentials), ni OAuth utilisateur dans la documentation.

• Champs : type: bigquery, project (et non project_id), datasets (liste obligatoire des jeux de données accessibles), dataset (jeu de données par défaut, facultatif), location (US, EU, etc.).

• Rôles IAM recommandés : roles/bigquery.jobUser et roles/bigquery.dataViewer, de préférence attribué au niveau du jeu de données. La documentation déconseille les rôles plus larges (bigquery.user, admin, connectionUser).

• Rôles applicatifs (roles) : pour de la sécurité par ligne, le connecteur peut emprunter l'identité de comptes de service distincts (chaque rôle a un nom et un serviceAccountEmail). Cela suppose que le compte principal ait iam.serviceAccountTokenCreator et que des politiques d'accès aux lignes (row access policies) existent côté BigQuery.

Un fichier de connexion ressemble donc à ceci. Exemple adapté de la documentation, non exécuté : la forme exacte (liste YAML pour datasets, emplacement du fichier) est à confirmer avec le projet généré par evidence init.

type: bigquery
project: mon-projet-gcp
datasets:
  - analytics_123456789
dataset: analytics_123456789
location: EU
keyfile: ./sa-key.json   # ne jamais commiter ce fichier

Ce que ça implique concrètement

• Une clé de compte de service est un secret durable. Mettez-la hors du dépôt Git (.gitignore, variable d'environnement ou gestionnaire de secrets avec keyfile_json) et donnez au compte un accès en lecture seule limité aux jeux de données utiles. Sur certaines organisations Google Cloud, la création de clés de compte de service est interdite par une contrainte de politique d'organisation (iam.disableServiceAccountKeyCreation) : c'est de la connaissance générale GCP, pas une information issue de la documentation Evidence, mais à vérifier avant de promettre une mise en place chez un client.

• Les requêtes sont live. Chaque ouverture de dashboard peut déclencher des requêtes facturées au volume de données lues. Je n'ai pas vérifié si Evidence met en cache les résultats. Sur l'export GA4, filtrez toujours les tables par date (_TABLE_SUFFIX) et, dès que les volumes grossissent, construisez une table agrégée (par exemple avec dbt) plutôt que d'interroger les tables d'événements brutes à chaque affichage.

• Le SQL est du BigQuery natif. Dans Core, plus de DuckDB : les fonctions sont celles de BigQuery (UNNEST, PARSE_DATE, etc.), ce qui est plutôt une bonne nouvelle pour l'export GA4, dont tout l'écosystème de requêtes est écrit pour BigQuery.

Exemple de requête de sessions par jour sur l'export GA4 (SQL BigQuery standard, non exécuté dans Evidence ; remplacez le nom de la propriété et les dates) :

SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  COUNT(DISTINCT CONCAT(
    user_pseudo_id, '-',
    CAST((SELECT value.int_value
          FROM UNNEST(event_params)
          WHERE key = 'ga_session_id') AS STRING)
  )) AS sessions
FROM `mon-projet-gcp.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930'
GROUP BY date
ORDER BY date

Auto-hébergement : ce qui marche, ce qui manque

Evidence Core se déploie sur votre infrastructure avec la commande evidence serve ou l'image Docker officielle evidencedev/serve:latest (le projet est copié dans l'image avec COPY --chown=evidence:evidence . /project). Deux contraintes à connaître :

• Connecteur direct obligatoire : un projet auto-hébergé doit utiliser un connecteur direct (comme BigQuery) ; les fonctions qui reposent sur l'entrepôt de données d'Evidence Studio ne sont pas disponibles.

• Protection d'accès minimale : evidence serve exige une authentification basique (variables EVIDENCE_BASIC_USER et EVIDENCE_BASIC_PASSWORD) et refuse de démarrer sur un hôte non local sans elle. La variable EVIDENCE_AUTH_DISABLED=true permet de la désactiver pour un réseau privé de confiance. Pour un dashboard client, prévoyez donc un reverse proxy avec votre propre authentification (SSO, VPN) devant le service.

Selon la documentation, ces fonctions ne sont pas disponibles en auto-hébergement : l'authentification des utilisateurs au-delà du basique, la sécurité par ligne, les agents, l'éditeur web, la collaboration en temps réel, l'Evidence Warehouse, les modèles SQL, l'analytique embarquée et le serveur MCP de Studio. Les fonctions de Studio (environnement de développement hébergé, diffusion par e-mail, contrôle d'accès par page, agent d'analyse, serveur MCP hébergé) relèvent de l'offre hébergée. Je n'ai pas trouvé sa grille tarifaire dans les sources lues : vérifiez-la sur le site d'Evidence avant de bâtir un projet client dessus.

Evidence face à Looker Studio

Looker Studio reste l'outil par défaut des équipes analytics autour de GA4 et de Google Ads. La comparaison n'a de sens que sur des critères précis :

Je n'ai trouvé aucune preuve que Looker Studio prenne en charge Git. La notion de contrôle de version par Git appartient plutôt à Looker (LookML), un produit distinct : c'est une connaissance générale, pas un point que j'ai retrouvé dans les sources consultées pour cet article.

Quand choisir Evidence, quand l'éviter

Cas où Evidence a du sens

• L'équipe sait écrire du SQL et utilise déjà Git : le dashboard devient un livrable comme un autre, relu et déployé par la même chaîne.

• Les dashboards doivent être reproductibles et auditables : par exemple un rapport mensuel dont la méthode de calcul doit rester traçable.

• Vous voulez des métriques définies une seule fois (YAML) et réutilisées dans plusieurs pages.

• Vous travaillez avec des agents de code : une syntaxe textuelle validable par une commande est plus fiable à produire et à vérifier qu'une configuration cliquée.

Cas où Looker Studio (ou autre) reste plus adapté

• Le destinataire final est un client non technique qui veut explorer et ajuster lui-même.

• Le besoin se résume à des données GA4 et Google Ads avec des connecteurs natifs, sans infrastructure à maintenir.

• Vous avez besoin de composants que Core ne propose pas (voir la liste du guide de migration) ou de plusieurs entrepôts dans un même rapport.

• L'organisation interdit les clés de compte de service et n'accepte que l'authentification par identité.

Mon avis de praticien tracking

Pour un projet tracking, Evidence est une bonne façon de livrer un rapport de recette ou de qualité de données reproductible : taux d'événements reçus par page, part de sessions sans source, écart entre transactions du site et du back-office. Ce sont des vues stables, écrites une fois, relues en revue. Pour du reporting marketing exploratoire destiné à des équipes métier, Looker Studio garde l'avantage de l'accessibilité. Les deux ne s'excluent pas : l'export GA4 dans BigQuery alimente indifféremment l'un ou l'autre, et une table agrégée construite avec dbt sert les deux.

Une dernière remarque de prudence : Evidence Core a quelques semaines d'existence au moment où j'écris. Comptez avec des évolutions rapides de la syntaxe et de la documentation, et épinglez la version du CLI dans vos projets clients.

Sources

• Dépôt GitHub evidence-dev/evidence (licence MIT, activité)

• Guide de migration vers Evidence Core (différences avec l'ancien socle, fonctions sans équivalent)

• Documentation du connecteur BigQuery (authentification, champs, rôles IAM)

• Article du blog Evidence du 26 août 2026 présentant Evidence Core (installation, commandes, auto-hébergement, fonctions réservées à Studio)

• Documentation de Google Looker Studio, section historique des versions et publication des rapports

Le détail des commandes, des composants et des options de connexion est susceptible d'évoluer : vérifiez la documentation en vigueur avant de lancer un projet.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.