DataAnalytics & BI

BI en langage naturel : l'analyste n'est pas en train de disparaître, il change de métier

Les outils de BI conversationnelle promettent à tout collaborateur d'interroger les données sans passer par un analyste. Avant d'y croire, les CDO devraient examiner ce que ces outils produisent réellement, et ce qu'ils ne feront jamais.

Depuis que des plateformes comme Tableau (avec Tableau Pulse), Microsoft (avec Copilot dans Power BI) et ThoughtSpot ont intégré des interfaces en langage naturel à leurs produits, un même récit circule dans les cercles data : l'analyste business traditionnel devient superflu. N'importe quel directeur commercial pourrait désormais taper "Quelles régions ont sous-performé au T2 ?" et obtenir une réponse en trente secondes. Les DSI et CDO s'emparent de l'argument pour justifier des réorganisations. Les cabinets de recrutement notent déjà une pression sur les salaires des profils junior en analytique. Le sujet mérite un examen sérieux, pas un enthousiasme de convention.

Ce que défend le consensus, et ce n'est pas sans fondement

La thèse dominante repose sur un constat réel : la majorité des requêtes analytiques dans une entreprise sont répétitives, peu complexes, et consomment un temps disproportionné des équipes data. Gartner estimait dès 2023 que 60 à 70 % des requêtes adressées aux équipes BI internes portaient sur des questions auxquelles un tableau de bord existant aurait pu répondre, si les utilisateurs avaient su s'en servir. L'interface en langage naturel résout précisément ce problème d'accessibilité.

Les défenseurs du consensus ajoutent que la démocratisation de l'accès aux données réduit les goulots d'étranglement organisationnels. Une équipe commerciale qui attend trois jours un rapport ad hoc perd des décisions. Si ThoughtSpot ou Copilot répondent en quelques secondes, la valeur créée est mesurable. Microsoft communique (en tant qu'éditeur, donc à croiser avec des sources indépendantes) sur des taux d'adoption de Copilot dans Power BI dépassant 40 % parmi les utilisateurs actifs de sa suite M365 dans les grandes entreprises. Ces chiffres, même gonflés, signalent une adoption réelle.

La conclusion logique du consensus : les analystes qui survivront seront ceux qui montent en abstraction, vers la modélisation, la gouvernance, l'interprétation stratégique. Le reste sera automatisé.

Les angles morts que personne ne veut nommer

Le problème avec cette thèse, c'est qu'elle suppose que les questions posées en langage naturel sont les bonnes questions. Ce n'est pas toujours le cas.

Les interfaces NL (natural language) sont très efficaces pour répondre à ce qu'on leur demande. Elles sont aveugles à ce qu'on aurait dû demander. Un directeur régional qui interroge "Quel est mon chiffre d'affaires du trimestre par rapport à l'objectif ?" obtient une réponse précise. Mais si la définition de "chiffre d'affaires" dans le modèle de données exclut les remises accordées hors système CRM, la réponse est techniquement exacte et factuellement trompeuse. L'analyste expérimenté sait que ce cas existe. L'outil ne le sait pas, et l'utilisateur non plus.

C'est le premier angle mort : la qualité de la réponse dépend entièrement de la qualité du modèle sémantique sous-jacent. Or construire et maintenir ce modèle, documenter les ambiguïtés, arbitrer les définitions métier, c'est exactement le travail d'un analyste. ThoughtSpot et ses concurrents ont besoin que quelqu'un ait défini ce que "chiffre d'affaires" signifie dans la couche de données avant que l'interface NL puisse faire quoi que ce soit d'utile.

Le deuxième angle mort concerne les biais de formulation. Des travaux de recherche en HCI (human-computer interaction) publiés notamment dans le journal ACM SIGCHI montrent que les utilisateurs non formés à la statistique ont tendance à poser des questions qui confirment leurs hypothèses préexistantes plutôt qu'à les tester. Un commercial convaincu que son marché sous-performe à cause de la saisonnalité posera des questions qui corroborent cette croyance. Sans un tiers formé à la pensée critique des données pour reformuler ou challenger la question, la BI en langage naturel devient un générateur de biais à grande vitesse.

Troisième point, souvent ignoré : la gouvernance des requêtes. Quand l'analyste était l'intermédiaire, il filtrait naturellement les demandes inappropriées, celles qui portaient sur des données sensibles, celles qui mélangeaient des périmètres incompatibles. Une interface ouverte en langage naturel peut, selon la configuration, exposer des corrélations ou des segments que l'entreprise n'a pas décidé de rendre accessibles. Plusieurs incidents de fuite de données internes ont déjà été documentés dans des environnements où les contrôles d'accès au modèle sémantique n'avaient pas été revus avant le déploiement d'une interface NL.

Enfin, l'hypothèse que les analystes junior sont les plus menacés mérite d'être retournée. Les modèles LLM génèrent des réponses plausibles, pas nécessairement correctes. Quelqu'un doit valider. Ce rôle de vérification exige une maîtrise des données que les utilisateurs métier n'ont pas encore. Les profils junior, s'ils sont bien formés, deviennent les auditeurs de la machine, pas ses victimes.

Ce qu'un CDO averti devrait faire concrètement

La stratégie d'un CDO face à la BI en langage naturel ne doit pas partir de la question "Combien d'analystes peut-on réduire ?" mais de "Qu'est-ce que cet outil fait mieux que nous, et qu'est-ce qu'il ne fait pas du tout ?"

Quelques axes concrets :

  • Investir d'abord dans la couche sémantique avant tout déploiement d'interface NL. Sans un catalogue de données propre, documenté, avec des définitions métier validées, l'interface NL amplifie la confusion existante plutôt qu'elle ne la réduit. dbt Labs, Atlan ou Alation proposent des environnements qui peuvent servir de fondation, avec les limites commerciales que cela implique.
  • Redéfinir le rôle des analystes autour de trois missions qui résistent à l'automatisation : concevoir les modèles sémantiques, auditer les sorties des outils NL, et traduire les questions métier mal formulées en questions analytiques rigoureuses. Ce dernier point est souvent le plus difficile à automatiser, car il exige une compréhension du contexte organisationnel.
  • Tester l'interface NL avec des questions dont les réponses sont déjà connues avant de la mettre entre les mains des équipes métier. C'est une procédure de validation basique que trop d'entreprises sautent, pressées par les cycles de déploiement.
  • Ne pas confondre adoption et valeur. Le taux d'utilisation d'une interface NL dit peu sur la qualité des décisions prises à partir de ses réponses. Construire un indicateur de suivi sur l'exactitude des réponses

Vous avez lu cet article ?

Validez votre lecture pour gagner de l’XP et alimenter votre radar.