En quelques mois, l’IA générative est passée du statut de curiosité à celui d’outil de tous les jours, et les dirigeants ont remarqué ce qu’elle fait bien. Ils tapent une question en langage courant et obtiennent une réponse fluide en quelques secondes. La demande suivante à l’équipe de BI va de soi : à quoi bon fouiller dans plusieurs tableaux de bord pour comprendre pourquoi la marge a reculé dans l’Ouest, alors qu’il suffirait de poser la question?
Les outils de BI proposent des questions en langage naturel depuis des années, avec des résultats inégaux. Ce qui change, c’est la qualité des modèles de langage qui les alimentent, et les attentes de ceux qui posent les questions. Pour les équipes de BI, il s’agit moins d’une fonction à activer que d’un changement dans ce qu’elles construisent et dans ce dont elles sont responsables.
Les tableaux de bord répondent aux questions que quelqu’un a prévues
Un tableau de bord est un ensemble de réponses à des questions que quelqu’un a prévues il y a des mois : comment les ventes se comparent au plan, où la marge est sous pression, quels clients paient en retard. Il le fait bien, et il doit continuer de le faire. Là où il peine, c’est à la question suivante : pourquoi le chiffre a-t-il bougé, quels produits l’expliquent, comment se compare-t-il à la même période l’an dernier?
Aujourd’hui, ces questions complémentaires partent généralement par courriel vers un analyste, qui reconstitue le contexte, refait les calculs et répond un jour ou deux plus tard. Entre-temps, la réunion est terminée, et la décision a été prise sans la réponse. C’est dans cet écart entre voir un chiffre et le comprendre que les questions en langage naturel ont le plus de valeur.
Prévoir les questions, pas seulement les pages
Avant de choisir un outil, recueillez les questions. Lisez les courriels de suivi envoyés à l’équipe d’analytique, assistez à quelques revues d’affaires et demandez aux dirigeants ce qu’ils ont cherché le mois dernier sans le trouver. Quelques dizaines de vraies questions, formulées avec les mots que les gens emploient réellement, valent mieux que n’importe quelle liste de fonctionnalités.
Regroupez-les par type et vérifiez que le modèle de données permet de répondre à chacune d’elles. Les questions sur un changement exigent des comparaisons dans le temps. Celles qui ventilent un chiffre exigent des hiérarchies propres pour les produits, les régions et les clients. Celles qui portent sur le plan exigent que le plan se trouve dans le même modèle que le réel. La banque de questions devient ensuite un jeu d’essai : chaque question reçoit une réponse attendue, et toute modification du modèle est validée à l’aide de ce jeu. Faites vivre la banque après le lancement : les questions que les gens posent réellement différeront de celles qu’ils avaient prévues, et le registre des vraies questions est le meilleur guide de ce dont le modèle aura besoin ensuite.
Rendre chaque définition univoque
Un tableau de bord masque l’ambiguïté derrière sa mise en page. Le titre de la page, les filtres et l’analyste qui l’a conçu indiquent au lecteur que « revenus » signifie revenus nets après retours et remises. Une question tapée au clavier ne porte aucun contexte de ce genre. Demandez les revenus du dernier trimestre, et le système doit choisir entre les ventes brutes, les commandes reçues, les ventes facturées et les revenus nets. Il ne choisira pas toujours le chiffre que publient les finances.
La solution est une discipline que les bonnes équipes de BI appliquent déjà, rendue explicite pour chaque terme d’affaires :
- Une seule définition certifiée. Une mesure par terme, avec un responsable désigné, et les autres masquées ou renommées pour que personne ne puisse les confondre avec elle.
- Une description en langage clair. Ce que la mesure inclut et exclut, rédigé pour le dirigeant plutôt que pour le développeur.
- Les mots que les gens emploient. Ventes, revenus et chiffre d’affaires associés à la même mesure; les prises de commandes associées aux commandes, et non aux revenus.
- Des valeurs par défaut sensées. La période, la devise et le périmètre présumés lorsqu’une question ne les précise pas.
Lorsqu’un terme demeure vraiment ambigu, un système bien conçu demande une précision plutôt que de deviner.
Montrer d’où vient chaque réponse
Une réponse sans source n’est qu’une opinion. Chaque réponse devrait indiquer la mesure utilisée, les filtres et la période appliqués et la date de la dernière actualisation des données, avec un lien vers le rapport gouverné où l’on peut vérifier le chiffre. Les dirigeants mettent un nouveau système à l’épreuve en posant des questions dont ils connaissent déjà la réponse. Quand la source est visible, un écart s’explique en une minute. Quand elle ne l’est pas, un seul chiffre erroné peut défaire des mois de confiance.
Les réponses doivent aussi tenir compte de la personne qui pose la question. Si un gestionnaire régional ne voit que sa région dans un tableau de bord, une question ne doit pas révéler les autres régions. Les règles d’accès ont leur place dans le modèle de données, où chaque rapport et chaque question en héritent, et non dans des pages individuelles.
Savoir quand ne pas répondre est tout aussi important. Si une question dépasse ce que couvre le modèle, par exemple un mois qui n’est pas encore clôturé ou une mesure qui n’existe pas, la bonne réponse consiste à le dire et à orienter vers la personne qui peut aider. Un système qui reconnaît ses limites gagne la confiance pour les questions auxquelles il sait répondre.
Garder les tableaux de bord pour le suivi
Rien de tout cela ne rend les tableaux de bord obsolètes. Le suivi repose sur la constance : les mêmes mesures, au même endroit, comparées de la même façon chaque semaine, pour que les tendances et les exceptions sautent aux yeux. Une question ne peut pas jouer ce rôle, car personne ne s’informe d’un problème qu’il n’a pas encore remarqué.
Les deux fonctionnent mieux ensemble. Le tableau de bord montre que quelque chose a bougé; la question explique pourquoi. Concevez-les comme un tout : chaque page de tableau de bord devrait prévoir ses questions complémentaires les plus fréquentes, et une question posée encore et encore signale qu’une page manque ou n’est pas claire. Un bon test de la conception consiste à vérifier si un dirigeant peut passer d’un chiffre en rouge dans un tableau de bord à une explication fiable sans écrire de courriel.
Ce qui change pour l’équipe de BI
Le travail se déplace en amont. Il faut moins de pages ponctuelles, puisqu’une question complémentaire n’exige plus un nouveau rapport. Plus d’efforts vont aux définitions, aux descriptions, aux synonymes, aux questions d’essai et à l’examen régulier des questions qui ont échoué. Les compétences qui comptent le plus sont la maîtrise du vocabulaire d’affaires, une modélisation de données rigoureuse et l’habitude de tester les réponses comme les finances vérifient une clôture mensuelle. Ce travail n’a rien de spectaculaire, mais c’est lui qui fait la différence entre une démonstration impressionnante et un outil que la direction utilise chaque semaine.
Commencez petit : un domaine, une équipe de direction, un jeu de données bien gouverné et les questions que cette équipe pose réellement. Prouvez l’exactitude des réponses dans ce périmètre avant de l’élargir. Les équipes qui procèdent ainsi constatent que leurs tableaux de bord s’améliorent aussi, car la clarté qu’exigent les questions en langage naturel profite à tous les rapports.