Il se joue, dans la BI, une bascule assez simple à résumer : les outils que l’IA peut lire, modifier et versionner vont prendre de l’avance sur ceux qui restent enfermés dans des interfaces propriétaires.
Evidence.dev est intéressant pour cette raison. Pas seulement parce que c’est un nouvel outil de BI, mais parce qu’il montre à quoi peut ressembler une BI pensée pour un monde où les agents IA produisent une partie du travail.
Evidence.dev, c’est quoi ?
Evidence.dev est un outil de Business Intelligence qui permet de créer des dashboards à partir de fichiers Markdown.
Concrètement, au lieu de construire un dashboard en cliquant dans une interface, on écrit ce que l’on veut afficher : un titre, un graphique, un KPI, une table, un filtre, des onglets, les données à utiliser, les colonnes à mobiliser, les couleurs à appliquer.
Le dashboard devient donc un fichier texte.
Et c’est précisément ce qui change tout : un fichier Markdown peut être lu, compris, modifié, versionné et généré par un agent IA.
Là où Power BI ou Tableau reposent largement sur des interfaces graphiques, Evidence.dev rend le dashboard directement manipulable par du code — et donc par l’IA.
Pourquoi c’est important
Pendant longtemps, la BI a été pensée comme un métier d’interface.
On positionne des graphiques. On règle des filtres. On ajuste des couleurs. On déplace des blocs. On passe du temps à transformer une demande métier en écran exploitable.
Ce modèle a rendu beaucoup de services. Mais il a une limite : il est difficilement lisible par une machine.
Un agent IA peut aider à cadrer un besoin, écrire du SQL, proposer une structure d’analyse ou documenter une logique métier. Mais si le livrable final dépend d’une suite de clics dans une interface fermée, l’agent ne peut pas vraiment produire. Il peut conseiller, mais pas faire.
Evidence.dev inverse cette logique.
Si le dashboard est un fichier Markdown, l’agent peut générer une première version, ajouter une section, corriger une incohérence, documenter un KPI, adapter le dashboard à un nouveau besoin ou proposer une variante à partir d’un brief métier.
Ce n’est pas un détail technique. C’est un changement de productivité.
La BI va-t-elle connaître son moment dbt ?
La data a déjà vécu ce basculement côté modélisation.
Avec dbt, beaucoup d’équipes ont compris qu’elles n’avaient pas besoin d’interfaces lourdes pour transformer leurs données. Elles avaient besoin de fichiers SQL propres, versionnés, testés et documentés.
Le gain n’était pas seulement technique. Il était aussi organisationnel : quand la logique métier est dans du code, elle devient lisible, maintenable, relisible et transmissible.
Evidence.dev applique une logique similaire au dashboarding.
Au lieu de cacher la construction d’un dashboard dans une interface propriétaire, on la décrit dans un fichier texte. Le dashboard devient un artefact de code comme un autre :
- versionnable dans Git ;
- relisible en revue ;
- documentable automatiquement ;
- générable par un agent ;
- maintenable sans dépendre entièrement d’une interface.
La question n’est donc pas “est-ce que le Markdown est plus agréable qu’une interface ?”.
La vraie question est : “est-ce que mon environnement de BI peut être compris et modifié par l’IA ?”
Evidence.dev et Omni : deux faces du “as code” dans la BI
Evidence.dev n’est pas seul dans ce mouvement.
Omni, fondé par d’anciens de Looker, pousse aussi une approche “as code”, mais sur un autre niveau : la couche sémantique. Là où Evidence.dev rend le dashboarding manipulable par le code, Omni travaille plutôt sur la manière de définir, gouverner et interroger les données.
En simplifiant :
- Omni structure la couche sémantique as code ;
- Evidence.dev structure le dashboarding as code.
Les deux approches répondent à un même enjeu : sortir la logique data des interfaces fermées pour la rendre lisible, gouvernable, versionnable et exploitable par des agents.
L’outil idéal combinera probablement les deux : une couche sémantique propre, robuste, gouvernée, et une couche de visualisation tout aussi lisible et maintenable.
C’est probablement dans cette direction que va le marché.
Le dashboard ne disparaît pas, mais il change de statut
Il ne s’agit pas de dire que les dashboards ne servent plus à rien.
Ils restent utiles pour le monitoring opérationnel, le pilotage récurrent, le suivi d’indicateurs partagés ou l’alignement entre équipes.
Mais le dashboard n’est plus forcément le livrable par défaut.
Beaucoup de demandes de dashboards sont en réalité des questions ponctuelles : comprendre une tendance, vérifier une hypothèse, comparer deux segments, explorer un périmètre.
Pour ces usages, un chatbot gouverné, une analyse générée, un rapport automatisé ou une data app peuvent parfois être plus pertinents qu’un nouveau dashboard à maintenir.
Et quand une interface est vraiment nécessaire, la produire en code peut devenir plus rapide que de paramétrer un outil générique.
Est-ce prêt à remplacer Power BI ou Tableau ?
Non — et ce n’est pas vraiment le sujet.
Une entreprise qui possède déjà des centaines de dashboards Power BI ne va pas tout migrer du jour au lendemain vers Evidence.dev. Les outils historiques vont continuer d’exister, parce qu’ils sont installés, connus, intégrés aux organisations.
Evidence.dev reste aussi un outil jeune. Sa maturité doit être évaluée selon les contextes, notamment dans les très grandes organisations.
Mais certains freins sont parfois surestimés.
La performance dépend surtout du data warehouse sous-jacent : BigQuery, Snowflake ou autre. La sécurité et les accès peuvent aussi souvent être traités au niveau du warehouse plutôt que directement dans l’outil de visualisation.
Le vrai sujet est plutôt culturel : passer d’une logique d’interface à une logique de fichiers, de code, de versioning et de collaboration avec des agents.
Ce que cela change pour les équipes data
Les profils data qui se sont construits uniquement autour de la maîtrise d’un outil vont devoir élargir leur socle.
Savoir produire un dashboard Power BI ou Tableau restera utile. Mais il faudra aussi savoir :
- comprendre une logique versionnée ;
- structurer un besoin métier ;
- relire du SQL ;
- documenter proprement ;
- travailler avec un agent IA ;
- contrôler une production générée ;
- penser maintenabilité avant de penser écran.
Le métier ne consiste plus seulement à “faire un dashboard”.
Il consiste à construire un système dans lequel les analyses, les interfaces et la documentation peuvent évoluer rapidement, sans devenir ingérables.
Dans ce modèle, l’IA ne remplace pas l’expertise data. Elle l’amplifie — mais seulement si l’environnement a été conçu pour être lu et modifié par elle.
Conclusion
Evidence.dev est intéressant parce qu’il rend visible une bascule plus large.
La prochaine génération d’outils BI ne sera pas seulement plus jolie ou plus simple à utiliser. Elle sera plus lisible par les humains, mais aussi par les agents IA.
Pendant des années, les interfaces ont caché la complexité. C’était utile. Mais dans un monde où l’IA devient un membre de l’équipe de production, ce qui est caché devient aussi ce qui est difficile à automatiser.
Evidence.dev ne remplacera pas tous les outils de BI demain matin.
Mais le dashboard en Markdown montre une direction : une BI plus versionnable, plus maintenable, plus proche des pratiques software — et beaucoup plus compatible avec l’IA.