- 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
Avis de Hacker News
Dans une entreprise où l’on créait des dashboards avec un outil de BI, les chiffres paraissaient étranges, alors quelqu’un a regardé le générateur de requêtes : impossible de savoir si certaines parties de la requête étaient des jointures internes ou des jointures à gauche.
L’analyste métier qui avait créé ce dashboard ne le savait pas non plus ; en réalité, l’intention était d’utiliser une jointure interne, mais une jointure à gauche était exécutée, et les données affichées étaient supérieures d’un ordre de grandeur à la réalité.
Depuis ce moment, je ne fais plus confiance à ce type de couche d’abstraction posée au-dessus de SQL pour des personnes qui ne connaissent pas SQL.
Trop de gens ont accès aux données, mais ne comprennent ni les données elles-mêmes, ni les relations, ni ce que signifient les résultats qu’ils produisent.
Ces 25 dernières années, des solutions ont été présentées comme la panacée — ingénieurs et scientifiques distribués/intégrés, dashboards en self-service, outils BI/data low-code, et maintenant text-to-SQL/visualisation basés sur des LLM — mais au final, elles n’ont pas résolu le manque de compréhension des données ni le problème de confiance dans les livrables.
Cela dit, SQL n’est pas non plus la solution. Beaucoup de gens connaissent assez SQL pour extraire des données, mais rares sont ceux qui connaissent aussi la structure des données, le schéma et la bonne manière de les utiliser.
En dehors de l’expérience, il n’existe encore aucun outil qui résolve ce problème ; peut-être que les LLM y parviendront un jour, mais honnêtement cela me paraît peu probable.
Les dashboards sont utiles pour consulter rapidement des KPI et creuser, mais au bout du compte, ce qui compte, ce sont les pratiques de gestion des données et la capacité à comprendre correctement les données, les relations et les métriques pour les relier à des insights métier.
L’avenir est prometteur, mais jusqu’ici les outils de nouvelle génération n’ont jamais tenu leurs promesses, donc je ne les crois jamais facilement.
Entre des valeurs par défaut raisonnables et un dispositif qui vous tire une balle dans le pied, ce n’est qu’une question de point de vue.
Dans de grandes entreprises, j’ai vu des cas où un bug subtil ou un choix de conception faisait paraître le chiffre d’affaires plus élevé, et où personne ne voulait y toucher pour se retrouver responsable d’une baisse du chiffre d’affaires.
Par exemple, un bouton de forfait gratuit situé sous la ligne de flottaison sur une résolution moyenne, un mauvais calcul d’état qui empêche l’application d’une remise, ou quelqu’un qui oublie un
false, de sorte qu’une inscription est exigée alors qu’elle n’est techniquement pas nécessaire.Je me demande s’ils ont ressenti quelque chose de similaire, par peur qu’on les tienne pour responsables de la baisse des chiffres.
Dans la mise en œuvre de flux logiques complexes, la partie difficile n’est pas de taper du code dans un IDE, mais de modéliser le problème et de concevoir un algorithme efficace.
Ces outils ciblent les utilisateurs non techniques en promettant qu’il n’est pas nécessaire d’écrire du code, mais ces utilisateurs ne comprennent toujours pas la partie complexe qui consiste à concevoir la solution de façon ingénierie, et finissent perdus ou produisent de mauvais résultats.
Les tentatives de faire grandir des processus métier complexes avec des outils no-code finissent par se heurter à un mur après beaucoup d’essais-erreurs, puis sont transmises à de vrais ingénieurs.
Mais ces ingénieurs doivent alors travailler sans l’assistance évidente dont ils bénéficient quand ils écrivent du code dans un vrai langage de programmation.
Une fois enfermé dans un constructeur de flux visuel, il devient presque impossible d’avoir un dépôt partagé, un vrai contrôle de version, des revues de code, des tests automatisés et du CI/CD.
Les utilisateurs regardent fondamentalement les choses de leur propre point de vue ; il faut donc leur fournir des manières alternatives de voir les données selon leur façon de penser.
Je connais un produit qui traite la présence scolaire sur une base temporelle, parce que les combinaisons d’emplois du temps varient selon l’école, le campus et la date, et qu’il faut de la flexibilité pour les événements sportifs, les remplacements, les activités en classe mixte ou les emplois du temps tournants sur 14 jours.
Cela ne signifie pas pour autant qu’on ne peut pas créer des vues qui composent ces emplois du temps complexes en présence par cours ou en présence matin/après-midi.
L’hypothèse selon laquelle les utilisateurs métier ne peuvent pas apprendre la relation entre leurs questions, le modèle de données et les menus déroulants, ou seraient trop pressés pour le faire, est absurde.
D’après mon expérience, ils essaient au contraire d’apprendre, mais les modélisateurs de données comprennent souvent insuffisamment le domaine et ne parviennent pas à capturer les nuances des questions.
Résultat : au nom de la simplification du self-service, on cache ces nuances, ce qui allonge le temps nécessaire pour obtenir une réponse, ou on les supprime carrément, produisant des réponses inexactes et trompeuses.
Je n’aime pas non plus l’euphémisme non technique. Entre les LLM, les outils de génération de requêtes BI et SQL, il existe largement des positions intermédiaires ; il n’est pas nécessaire de décréter qu’il existe un mur absolu de compétences.
Devenir expert en informatique, en programmation ou en analyse de données, c’est très bien, mais je leur dis, si possible, de placer au centre le domaine qu’ils étudient ou dans lequel ils travaillent, et de développer ces compétences en complément.
La solution au problème où les experts métier ne connaissent pas les données et les experts data ne connaissent pas le domaine, c’est que les deux soient la même personne.
On dirait que l’incompétence organisationnelle atteint maintenant un nouveau niveau.
Il y avait une BD Dilbert qui critiquait les tableurs, et elle s’applique telle quelle aux outils de BI et d’IA.
C’était quelque chose comme : « Le tableur de cette présentation est évidemment rempli d’erreurs et de mauvaises informations. De toute façon, personne ne le regardera à nouveau, sauf s’il renforce une décision que la direction a déjà prise, donc ce n’est pas grave. »
Dans la réalité aussi, les rapports et dashboards cassés sont partout.
Il arrive qu’ils ne soient pas mis à jour pendant des mois, parfois des années, sans que personne ne le sache, tout en étant utilisés dans des processus, des décisions et des workflows.
Parfois les données ne sont pas actualisées, mais elles sont pivotées par date/heure, si bien qu’à chaque exécution les mêmes données sont réarrangées, ce qui masque le fait que tout est gravement cassé.
Souvent aussi, toutes sortes de formules et de « maths » sont complètement fausses et produisent des chiffres imaginaires.
C’est simplement que, à mesure que le monde s’est éloigné des EDW et des systèmes ERP centralisés, les problèmes de données sont devenus exponentiellement plus difficiles, et le niveau d’investissement n’a pas suivi.
Cela fait 24 ans que je fournis des données aux utilisateurs métier, et qu’il s’agisse d’un outil de requêtes, de MS Access, de Power BI ou des cubes de données d’Excel, seule une minorité les utilise réellement.
Ce sont probablement les mêmes personnes qui, il y a 40 ans, auraient récupéré des données depuis des terminaux et des rapports imprimés pour les analyser.
Cela dit, les dirigeants aiment les tableaux de bord d’indicateurs clés, et les nouveaux outils de BI rendent la création et la maintenance de tableaux de bord KPI beaucoup plus faciles.
Leur intitulé de poste peut être quelque chose comme « assistant personnel », mais elles bricolent SharePoint Forms, Access et Excel de façon brillante.
Reconnaître leur ingéniosité et leur donner des outils plus puissants, c’est excellent. Il arrive ensuite qu’elles partent pour un meilleur poste, et c’est très bien aussi.
Les ordinateurs étaient si chers que le « service informatique » était un département à part dans l’entreprise ; par exemple, si la division Ouest avait besoin de ressources de calcul, elle passait contrat avec le service informatique qui disposait d’un mainframe installé sur site.
Notre groupe était une petite équipe interne d’analyse, agile, qui utilisait de nouveaux mini-ordinateurs « bon marché ».
L’avantage, grâce à la structure de financement, était de pouvoir répondre beaucoup plus vite aux besoins des utilisateurs.
Un jour, en traversant une usine, j’ai vu un utilisateur découper des lignes d’un rapport à bandes vertes que nous avions produit, les coller sur une autre feuille puis les photocopier.
Il était en train de trier le rapport selon un autre critère ; quand je lui ai dit « on peut vous faire ça ! », il a répondu « vraiment ? ».
Les personnes qui doivent terminer un travail trouvent toujours un moyen de le faire. L’objectif d’un groupe chargé des systèmes informatiques au service de clients internes est de rendre ce processus aussi efficace que possible.
Quelqu’un d’autre utilisait un PC, une tablette de numérisation et AutoCAD pour relever des points sur des avions et créer des profils radar.
Ce n’était pas vraiment l’usage prévu du CAD, mais une manière inventive de capturer des données à partir des plans de Jane’s Combat Aircraft.
Ils n’arrivent pas à croire que ces données existaient déjà.
L’intégration est une opération métier nécessaire, mais des données faciles à comprendre plaisent énormément aux parties prenantes. C’est un ajout de valeur très simple.
L’interface de BI traditionnelle mentionnée dans l’article est Metabase, et elle fait partie des meilleures interfaces actuelles pour la BI.
Metabase permet de voir le SQL généré par l’interface graphique, et de convertir une question en SQL pur, ce qui est pratique pour passer du self-service à la gouvernance.
Il devient facile de modifier et de valider la logique, et les personnes moins à l’aise techniquement disposent d’un chemin pour monter en compétence.
Mais le fond de l’article reste juste. Même du point de vue de quelqu’un dont le métier est la donnée, les outils de BI donnent rarement à davantage de personnes la compréhension précise des données ou les compétences nécessaires pour les utiliser correctement.
Quand les données sont bien gérées, les outils sont simples et les gens peuvent s’y retrouver, mais le monde est complexe et les données le deviennent aussi.
Le coût de gestion des données est très visible, tandis que les bénéfices le sont beaucoup moins.
J’en suis arrivé à une conclusion similaire sur la « BI en self-service », mais avec une solution un peu différente.
Je pense qu’il vaut mieux monter d’un cran dans la couche d’abstraction : créer des tableaux de bord très personnalisables, mais sans exposer SQL aux utilisateurs métier.
Par exemple, un tableau de bord avec 20 filtres, des dimensions de ventilation et 20 paramètres contrôlant les « hypothèses utilisées ».
La question « je veux voir les performances des annonces Google du mois dernier par tranche d’âge » revient alors à modifier 3 ou 4 menus déroulants prédéfinis.
Les paramètres sont essentiels ici, car seuls les réglages validés sont exposés, sans autoriser de SQL arbitraire.
Bien sûr, ce type de tableau de bord est difficile à construire et demande une vraie expertise en visualisation avec Looker, Tableau, Excel, etc., mais au final 70 % des questions deviennent traitables en self-service.
Pour les 30 % restants, il vaut mieux accepter qu’elles ne le soient pas, et il faut quelqu’un capable de traduire les questions métier en questions de données. C’est un problème humain.
Ainsi, quand le CFO ou quelqu’un d’autre a besoin d’une réponse sur une période donnée, il ouvre ce tableau de bord et ajuste simplement quelques paramètres de base.
Nous utilisons Metabase, celui qui apparaît dans l’image, et dans l’ensemble les utilisateurs non techniques l’utilisent réellement.
Ce qui a aidé à l’adoption, c’est d’organiser des « office hours » pour montrer concrètement des exemples comme « comment récupérer les ventes d’un point de vente ou d’un État donné ».
Cela n’a pas résolu tous les problèmes, requêtes ou exports, mais une bonne partie des demandes qui arrivaient auparavant à l’ingénierie n’arrivent désormais plus jusque-là.
Une autre raison pour laquelle Metabase est bien, c’est qu’on peut l’auto-héberger et utiliser le SSO GSuite.
L’indicateur clé n’est pas « les demandes d’aide ont diminué, donc les utilisateurs sont plus autonomes ».
Car il est très probable que ces utilisateurs produisent et interprètent des indicateurs complètement erronés.
J’ai vu à plusieurs reprises des utilisateurs peu techniques accéder aux données, se dire « ce n’est pas si difficile que ça », puis bâtir une pyramide d’analyses bancales.
Une bonne analyse a toujours besoin de contexte.
Par exemple, pour les revenus récurrents, l’équipe finance remplit à nouveau les dates d’expédition, donc il ne faut pas utiliser la date d’expédition pour calculer le chiffre d’affaires mensuel.
Les prix catalogue sont stockés en USD, mais en pratique le taux de change est ajusté chaque mois selon la table
monthly_discount.En raison d’une convention qui consiste à afficher les stocks invendus de l’année précédente, les éléments dont la date d’achat est null doivent être exclus des rapports de ventes.
Comme les prix sont en devise locale, il ne faut pas additionner les ventes sans faire de jointure avec la table des taux de change.
Je l’ai configuré pour les non-programmeurs de l’entreprise et, honnêtement, ils l’utilisent rarement au-delà de la consultation des tableaux de bord que j’ai créés, mais l’accueil a été bon.
C’est un outil vraiment utile.
Je trouve toujours drôle que des cadres dirigeants, pourtant très bien payés, ne sachent pas exécuter des requêtes SQL de BI.
SQL a justement été conçu à l’origine pour permettre aux managers d’interroger les données plus facilement.
En tant qu’ancien commercial/manager, je n’ai pas beaucoup de sympathie pour ce genre de personnes.
Mais il ne le fait pas lui-même. Parce qu’il connaît les principes économiques de base.
Même s’il peut faire en une demi-journée ce qui prendrait trois jours à quelqu’un d’autre, cette demi-journée est du temps pendant lequel il ne fait pas ce que seul un CEO peut faire.
Un CxO compétent sait aussi que ce qui prend vraiment du temps, c’est de régler parfaitement les détails.
Même si SQL est « haut niveau », obtenir une réponse fiable demande du temps et de la concentration, entre les particularités du traitement des null, les dates, ou les jointures qui ne correspondent pas.
S’il y a quelqu’un dont c’est le métier, il vaut mieux lui confier ça.
Je pense que les tableaux de bord BI peuvent très bien fonctionner pour des requêtes très simples.
Si l’on en est au point de demander à des utilisateurs non techniques d’exécuter des jointures de données, c’est qu’on est déjà allé trop loin, et dans ce cas il vaut mieux simplement utiliser SQL.
Les jointures peuvent sembler élémentaires à certains, mais personnellement je les trouve parfois difficiles à comprendre, et dans une UI de tableau de bord moins expressive que SQL, c’est une combinaison qui prête à confusion.
Au final, c’est un compromis. On peut rendre l’outil plus accessible aux utilisateurs non techniques que SQL, mais il sera inévitablement moins puissant que SQL.
Il reste pourtant beaucoup de valeur dans cet entre-deux. En pratique, une grande partie de la « BI » se résume à : « j’ai deux colonnes de données, tracez-en une par rapport à l’autre ».
L’auteur dit que SQL est le seul outil de BI « self-service », mais honnêtement, je pense que c’est Excel.
Beaucoup d’outils de BI reviennent à recréer Excel avec une interface nouvelle, et donc moins familière.
Je pense que le mème qui consiste à détester Excel vient du fait qu’on a essayé par le passé de faire des choses complexes avec Excel.
Si l’on fait les manipulations de données complexes en SQL, et que « montre-moi ça sous forme de camembert » se fait dans Excel, on peut très bien ne pas avoir réellement besoin d’outils de BI.
Si les sources de données sous-jacentes sont propres, transformées, et que le contrôle d’accès est bien géré, on peut aller étonnamment loin avec VLOOKUP et des tableaux croisés dynamiques.
Dès qu’il y a plus d’une source de données, donner aux utilisateurs non techniques une possibilité de self-service mène toujours à des mélanges de données hors ligne.
Puis vient la question : « l’équipe data, pourquoi vos données ne correspondent-elles pas à mes données ? », avec toujours le présupposé que ce sont les leurs qui sont correctes.
Le problème central, c’est que les outils modernes sont différents des desktops classiques comme les stations de travail Smalltalk ou Emacs.
Ces environnements formaient un environnement totalement intégré, où tout était entre les mains de l’utilisateur, avec des notions de programmation par l’utilisateur final intégrées.
Dans org-mode, on peut produire en un instant de belles slides, écrire et exécuter rapidement des fragments de code, puis obtenir des résultats.
Mais du point de vue des tableaux de bord, les limites sont importantes. On peut tracer rapidement des données, mais le résultat ressemble plutôt à une image statique brute ; et si l’on veut quelque chose de joli avec PGF/TikZ, cela prend trop de temps pour être une option réaliste, tout en restant statique.
Emacs lui-même est le bon outil, mais c’est un outil d’une époque plus ancienne.
Les outils modernes offrent des manipulations plus tape-à-l’œil et plus rapides, mais ils ne permettent qu’un ensemble très limité d’actions, enferment l’utilisateur dans des UI rigides, et ne s’intègrent pas non plus au reste.
R, avec RStudio/quarto, est peut-être ce qui permet de produire le plus vite du contenu présentable, rapidement et salement, mais il est encore très loin de la flexibilité d’Emacs.
Au final, il ne semble pas y avoir de solution sans réécrire toute la stack logicielle moderne en s’appuyant sur le paradigme classique et la puissance du matériel moderne.