- Les « self-serve dashboards » ne fonctionnent pas vraiment en pratique, car ils finissent par faire perdre beaucoup de temps aux ingénieurs ou aux data scientists, qui doivent écrire les requêtes et préparer les tableaux de bord pour les utilisateurs métier.
Pourquoi le « self-serve BI » ne fonctionne pas
- SQL est le seul véritable outil de « self-serve BI ». Mais la plupart des fournisseurs de « self-serve BI » essaient de déguiser SQL en autre chose.
- Écrire une requête SQL n’est pas le seul obstacle pour les parties prenantes métier qui veulent interroger les données. Elles ne comprennent pas la signification des données, leur provenance, la manière dont elles sont calculées, ni comment interpréter et valider les résultats.
Tentative 1 : l’approche classique « menus déroulants et cases à cocher »
- Cette interface n’est qu’une tentative de faire du « SQL à la souris ». Elle n’apporte rien de mieux que SQL, et est au contraire plus lente, moins fiable, plus limitée, et impossible à généraliser à d’autres outils.
- Une personne comme un CFO n’utilisera pas cette interface pour interroger les données, car elle n’a pas le contexte nécessaire pour les comprendre ni la certitude que les résultats sont fiables.
Tentative 2 : l’approche text-to-SQL
- Les LLM sont presque trop efficaces pour traduire le langage naturel en SQL. Ils essaieront de générer une requête même si la question n’est pas bien formulée.
- Un profil technique remarquera qu’il y a un problème dans la question et demandera plus de contexte. Il expliquera quels types de données sont disponibles et collaborera avec l’équipe métier pour formuler une question précise et utile.
- Les LLM peuvent devenir une vraie solution pour le « self-serve BI », mais pas sous leur forme actuelle. Ils ont besoin de plus de contexte et doivent mieux savoir exprimer l’incertitude et demander davantage d’informations.
Ce qui fonctionne réellement
- Le problème du « self-serve BI », ce n’est pas SQL, mais le contexte et le sens des données. La solution consiste, quelle que soit l’interface, à apprendre aux gens à comprendre les données qu’ils interrogent.
- Demander aux équipes techniques de documenter toute leur connaissance crée une surcharge importante et devient vite obsolète.
- La vraie solution au « self-serve BI » n’est pas de rendre la BI « self-serve » pour les non-techniciens, mais de permettre aux profils techniques d’aider plus efficacement les parties prenantes métier avec de meilleurs outils.
Suggestions pour de meilleurs outils
- Mettre les LLM à disposition des profils techniques, et non des parties prenantes métier.
- Leur permettre de manipuler librement les données avec les outils qu’ils préfèrent, comme Python ou R.
- Leur permettre de partager facilement leur travail. Les notebooks et les applications internes de données sont difficiles à partager, car ils impliquent de gérer des conteneurs, des dépendances et de l’infrastructure.
1 commentaires
Commentaire sur Hacker News
Problèmes des outils de BI : en utilisant des outils de BI, certains ont constaté que des jointures de requêtes étaient mal configurées, ce qui affichait des données erronées. Cela a fait perdre confiance dans la couche d’abstraction destinée à ceux qui ne maîtrisent pas bien SQL.
Utilité du Text-to-SQL : cela reste utile pour les développeurs, mais pour les non-développeurs, il existe un risque de générer des requêtes incorrectes faute de bien comprendre la structure de la base de données.
Incompétence organisationnelle : des rapports contenant des erreurs et de mauvaises informations issues d’outils de BI et d’IA sont réellement utilisés, un problème déjà critiqué de façon similaire dans la BD Dilbert.
Capacité d’apprentissage des utilisateurs métier : supposer que les utilisateurs métier ne peuvent pas comprendre la relation entre le modèle de données et les menus déroulants est une erreur. Le problème vient souvent du fait que le modélisateur de données comprend mal le domaine.
Expérience dans la mise à disposition des données : après 24 ans d’expérience à fournir des données, le constat est que seule une minorité d’utilisateurs se sert réellement des outils, tandis que les dirigeants préfèrent les tableaux de bord KPI.
Atouts de Metabase : Metabase offre une bonne interface parmi les outils de BI, et permet de convertir en SQL pur le SQL généré par l’interface graphique, ce qui le rend accessible même aux personnes moins techniques.
Limites de la BI en libre-service : il faut reconnaître les limites de la BI en libre-service, et la solution consiste à créer des tableaux de bord sur mesure qui n’exposent pas SQL aux utilisateurs métier.
Retour d’expérience avec Metabase : en utilisant Metabase et en formant les utilisateurs non techniques via des "office hours", de nombreuses demandes n’ont finalement pas eu besoin d’être transmises à l’équipe d’ingénierie.
L’ironie autour de l’usage de SQL : il est ironique que des cadres supérieurs ne puissent pas exécuter des requêtes SQL. SQL a été conçu à l’origine pour permettre aux managers d’interroger facilement les données.
Difficulté de l’ETL : pour les utilisateurs non techniques, manipuler des données dans l’ETL est encore plus difficile qu’en BI. En développant AWS Glue, certains ont compris qu’il fallait des outils permettant aux utilisateurs techniques de déboguer les problèmes.