Un agent IA capable de répondre à des questions sur les chiffres de votre entreprise, en langage naturel : sur le papier, difficile de faire plus séduisant. Mais que se passe-t-il lorsqu'il donne une réponse parfaitement convaincante… et complètement fausse ?
C'est précisément la difficulté rencontrée par Malt.
Dans un épisode du podcast DataGen publié le 28 septembre 2026, Gautier Chenard, Data Analytics Director chez Malt, revient sur la construction de MaltyAI, un agent conversationnel dédié à l'analyse de données.
Après un premier essai peu concluant, l'équipe annonce avoir atteint environ 90 % de bonnes réponses.
Ce qui m'intéresse dans ce retour d'expérience n'est pas tant le chiffre que les décisions techniques et organisationnelles prises pour améliorer les résultats.
Et il y a quelques enseignements à en tirer, y compris lorsqu'on ne dispose pas de l'équipe data de Malt.
Pourquoi un agent IA peut-il se tromper sur vos données ?
Imaginez que vous demandiez à votre agent :
« Quel est notre chiffre d'affaires sur les nouveaux clients ce trimestre ? »
Une question simple en apparence.
Sauf que votre CRM peut contenir plusieurs notions de chiffre d'affaires : commandes signées, montants facturés, opportunités gagnées ou contrats en cours.
Même problème avec les nouveaux clients. Parle-t-on d'une première commande, d'un nouveau compte CRM ou d'un client sans activité depuis deux ans ?
Un modèle de langage peut générer une requête techniquement valide tout en sélectionnant le mauvais indicateur.
Et c'est parfois le plus dangereux : une réponse fausse, mais suffisamment plausible pour ne pas attirer l'attention.
C'est ce qui ressort du premier prototype développé chez Malt. L'agent traduisait les questions en requêtes SQL, les exécutait puis renvoyait les résultats. Les réponses pouvaient être erronées et varier lorsqu'une même question était répétée.
Le problème n'était donc pas uniquement de mieux formuler les demandes.
Comment Malt a amélioré son agent Analytics
Le retour d'expérience présenté par DataGen met en évidence quatre changements.
Limiter les données et les indicateurs accessibles
Plutôt que de laisser l'agent interroger librement les bases de données, Malt l'a connecté à sa couche de métriques existante dans Looker, notamment via MCP (Model Context Protocol).
Une couche sémantique définit et organise les indicateurs métier, leurs règles de calcul et certaines relations entre les données.
L'agent n'a donc plus à décider seul de ce que signifie un indicateur déjà défini.
L'enjeu : réduire le nombre d'interprétations possibles avant même que l'IA ne construise sa réponse.
Pour autant, utiliser une couche sémantique ne garantit pas une réponse juste. Encore faut-il que ses définitions soient fiables, à jour et correctement exploitées.
Apprendre à l'agent à demander des précisions
Un bon analyste ne répond pas toujours immédiatement.
Face à une demande ambiguë, il commence parfois par demander : « Quel périmètre ? Quelle période ? Quelle définition ? »
Malt a cherché à reproduire ce comportement.
C'est une évolution intéressante. On juge souvent un assistant IA sur sa vitesse de réponse. Dans l'analyse de données, sa capacité à reconnaître une ambiguïté peut être tout aussi importante.
Intégrer l'agent aux outils déjà utilisés
Le premier prototype disposait de sa propre interface conversationnelle.
Malt a ensuite rendu l'agent accessible dans Slack et relié ses résultats à Looker.
L'utilisateur peut ainsi poser une question dans son environnement habituel, consulter un graphique, approfondir une analyse et partager les résultats.
Ce changement ne concerne pas directement la justesse des calculs. Il répond à un autre problème : l'adoption.
Un outil techniquement intéressant, mais absent des habitudes de travail, risque de rester peu utilisé.
Observer les réponses et analyser les erreurs
L'évaluation représente une difficulté particulière avec les modèles de langage : deux demandes proches ne produisent pas nécessairement la même réponse.
Chez Malt, les retours des utilisateurs et l'analyse des conversations permettent de repérer les problèmes et de faire évoluer le dispositif.
Le taux de 90 % rapporté dans le podcast constitue un résultat annoncé pour ce cas d'usage. Les éléments publiquement consultables ne suffisent pas à reconstituer entièrement son protocole de mesure.
Il serait donc trompeur d'en déduire qu'un agent construit avec les mêmes outils atteindra automatiquement cette performance.
Ce qu'une PME peut réellement reprendre de Malt
Soyons clairs : une PME n'a pas nécessairement besoin de Looker, de Slack, d'un serveur MCP ou d'un agent développé sur mesure.
En revanche, elle peut reprendre une méthode de conception.
Principe observé chez Malt | Application possible dans une PME |
|---|---|
Définir les indicateurs | Documenter précisément les KPI utilisés dans le reporting |
Réduire le périmètre | Commencer par un processus métier et quelques données fiables |
Clarifier les questions | Faire préciser les périodes, segments et définitions ambiguës |
Intégrer les usages | Utiliser les outils déjà présents lorsque leur architecture le permet |
Analyser les erreurs | Comparer les réponses de l'agent à une référence validée |
Exemple : interroger ses données commerciales
Prenons une entreprise qui suit son activité dans un CRM et un tableau de bord Power BI.
Elle souhaite demander en langage naturel :
« Combien de nouveaux clients avons-nous gagnés ce trimestre, et quels commerciaux ont contribué à ces résultats ? »
Avant de connecter un agent, plusieurs questions méritent d'être tranchées :
Qu'appelle-t-on un nouveau client ?
Quelle date détermine le trimestre : signature, commande ou facturation ?
Comment rattache-t-on un client à un commercial ?
Les données CRM sont-elles suffisamment fiables et à jour ?
L'utilisateur a-t-il le droit de consulter tous les comptes et tous les résultats ?
Ces questions relèvent d'abord de la gouvernance des données, pas du prompt engineering.
Si ces règles sont définies, on peut ensuite tester les réponses de l'agent sur un périmètre limité.
Le rôle de l'IA est d'exploiter les définitions métier, pas de les inventer à chaque question.
Comment tester la fiabilité d'un agent IA sur ses KPI
Je recommande de commencer avec une démarche limitée, plutôt que de brancher immédiatement un agent sur tout le système d'information.
Étape 1, Choisir un usage précis
Par exemple, répondre aux questions récurrentes sur le chiffre d'affaires mensuel, les opportunités gagnées ou les inscriptions à un événement.
Étape 2, Constituer un jeu de questions de référence
Préparer des questions représentatives : cas simples, filtres multiples, périodes incomplètes, formulations ambiguës et demandes qui doivent être refusées.
Étape 3, Définir les réponses attendues
Faire valider les résultats par les personnes qui maîtrisent les données et les règles de calcul.
Étape 4, Tester et qualifier les erreurs
Il ne suffit pas de compter les bonnes réponses. Il faut distinguer une mauvaise valeur, un filtre incorrect, une définition ambiguë, une absence de réponse et une fuite potentielle d'informations.
Étape 5, Mesurer avant d'élargir
Suivre la justesse sur les questions testées, les erreurs critiques, les demandes de clarification et le temps de vérification.
Ne généraliser que lorsque les résultats sont jugés acceptables pour l'usage prévu.
90 % de bonnes réponses : suffisant ou non ?
Cela dépend de la nature des erreurs.
Sur un jeu de 100 questions, 90 réponses justes signifient que 10 n'ont pas satisfait le critère retenu. Mais ces 10 erreurs peuvent être mineures ou modifier complètement une décision.
Une confusion de libellé dans un graphique interne n'a pas les mêmes conséquences qu'un chiffre d'affaires incorrect présenté en comité de direction.
La question n'est donc pas seulement « combien de réponses sont correctes ? », mais aussi « quelles erreurs sommes-nous prêts à tolérer ? »
Et la confidentialité des données ?
La fiabilité ne se limite pas à l'exactitude des calculs.
Un agent relié aux données commerciales, RH ou financières doit respecter les droits d'accès et le cadre de traitement applicable.
L'hébergement en Europe peut faire partie des critères de sélection, sans constituer à lui seul une garantie de confidentialité ou de conformité au RGPD.
Il faut notamment examiner les accès des prestataires, les transferts éventuels, les conditions contractuelles, la conservation des données et la traçabilité des opérations.
Un agent qui calcule parfaitement un indicateur mais le communique à une personne non autorisée n'est pas un système fiable.
Ce que je retiens du cas Malt
Le retour d'expérience de Malt illustre une idée que je défends dans les projets data : avant de rendre les données accessibles par l'IA, encore faut-il savoir ce qu'elles signifient.
Les modèles peuvent faciliter l'accès à l'information. Ils ne remplacent ni une définition cohérente des indicateurs, ni la qualité des données, ni la vérification des résultats.
Et dans certains cas, la bonne solution n'est peut-être même pas un agent IA.
Un tableau de bord bien construit, quelques mesures documentées et un dispositif de questions-réponses classique peuvent suffire.
L'objectif n'est pas de mettre un agent partout. C'est de faciliter l'accès à une information fiable, au bon moment et pour les bonnes personnes.
Et si le véritable enjeu était de savoir conduire un projet IA ?
Le cas Malt illustre une réalité souvent sous-estimée : maîtriser les outils d'IA ne suffit pas à réussir leur intégration dans une activité.
Il faut savoir identifier les bons usages, définir un périmètre, choisir les solutions adaptées, accompagner leur mise en œuvre et, surtout, mesurer les résultats.
C'est toute la différence entre expérimenter l'IA et savoir conduire un projet IA.
Une démarche que l'on retrouve justement dans les compétences de la certification RS7344 « Développer son activité avec l'intelligence artificielle ».
Si vous êtes dirigeant, consultant ou professionnel avec un projet IA à structurer, je propose un parcours individuel de 21 heures pour travailler cette méthode sur votre propre projet et préparer cette certification.
Découvrir la formation RS7344 et vérifier si elle correspond à votre projet
FAQ
Qu'est-ce qu'un agent IA Analytics ?
Un assistant utilisant l'intelligence artificielle pour interpréter des questions en langage naturel et interroger des données structurées afin de produire des réponses, des analyses ou des visualisations.
Pourquoi un agent IA peut-il donner de mauvais chiffres ?
Il peut mal interpréter une question, choisir un indicateur inadapté, appliquer un filtre incorrect ou travailler à partir de données erronées. La qualité des réponses dépend de l'ensemble du dispositif.
Une couche sémantique améliore-t-elle la fiabilité des agents IA ?
Elle peut réduire certaines ambiguïtés en définissant les indicateurs métier et leurs règles de calcul. Elle ne supprime toutefois pas toutes les erreurs possibles.
Comment mesurer la fiabilité d'un agent IA ?
En constituant un ensemble de questions représentatives, en définissant des réponses de référence et en évaluant les réponses produites, y compris la gravité des erreurs et leur évolution dans le temps.
Faut-il une équipe data pour créer un agent Analytics ?
Pas nécessairement pour expérimenter un cas d'usage simple. En revanche, il faut disposer de données compréhensibles, d'indicateurs définis et de personnes capables de vérifier les résultats.