Un agent analytique a lu « dernier trimestre » comme « les trois derniers mois », filtré sur le pays de domiciliation au lieu du pays de rattachement du portefeuille, et pris une colonne is_active au pied de la lettre. La question qu’il devait traiter était pourtant banale : combien de clients actifs en Allemagne au dernier trimestre ? Le customer success de Qonto la pose tous les jours, avec une définition précise dans la tête. L’agent, lui, n’avait aucune raison de la connaître.
Trois interprétations plausibles, trois réponses fausses, et pas une seule erreur de syntaxe SQL. Voilà le problème de l’analyse agentique résumé en une requête.
Qonto raconte son parcours en quatre phases. La première, le text to SQL : un bot traduit la question en requête, mais ne l’exécute pas. C’est l’utilisateur qui la lance, donc l’utilisateur qui doit comprendre le SQL. Le gain pour le commercial qui voulait juste un chiffre est à peu près nul. Deuxième phase, l’accès direct au warehouse via Claude. Le modèle juge si la requête et les données sont correctes. Il juge depuis un socle qui ne tient pas debout : noms de colonnes incohérents d’un domaine à l’autre, logique métier dupliquée, définitions de métriques qui changent selon l’équipe. On demande à une machine de trancher des ambiguïtés que l’entreprise n’a jamais tranchées elle-même.
Le Markdown, puis la plomberie
Troisième phase, des agents Claude qui interrogent un fichier de contexte en Markdown. Dedans : les définitions de métriques approuvées, les chemins de jointure validés, les entités documentées. Le SQL est compilé à partir de ces définitions, et une question qui ne correspond à rien renvoie « pas encore modélisé ». Élégant, mais ça ne passe pas à l’échelle. L’agent n’a toujours pas le contexte pour les questions complexes.
Quatrième phase, la moins sexy et la plus déterminante. Qonto refactorise ses modèles de données. Il abandonne les modèles taillés pour la BI et passe à la modélisation dimensionnelle, une ligne par paiement ou par mois de facturation, articulée autour des événements et de leurs descriptions. Puis il adopte Omni comme couche de contexte, pour obtenir des résultats déterministes : chaque question est décomposée en une combinaison de métriques et de dimensions prédéfinies.
La comparaison avec la première itération fait mal. En text to SQL, le modèle sélectionnait les tables, déduisait les relations, choisissait les agrégations et rédigeait la requête. Quatre étapes probabilistes, quatre occasions de se planter. La couche de contexte en supprime trois. Je vous parlais il y a quelques jours de cette couche de contexte qui reste le chaînon manquant de l’IA d’entreprise : Qonto en donne la démonstration par l’échec, phase après phase.
La facture que personne ne met dans le deck
Qonto assume un détail que les études de cas oublient systématiquement. Pendant plusieurs mois, les métiers ont vu l’effort d’ingénierie partir sur des modèles existants, sans une seule nouvelle fonctionnalité livrée. Il a fallu déprioriser d’autres projets. Voilà le prix réel d’un agent analytique qui dit la vérité, et il se paie avant d’encaisser quoi que ce soit.
Autre point que la néobanque soulève sans le maquiller : puisqu’il n’y a plus d’analyste au milieu, l’utilisateur métier hérite de la responsabilité d’arbitrage. Avant d’acculturer à l’IA, il a fallu penser data literacy. En pratique, ton agent ne supprime pas l’analyste, il déplace sa charge de travail sur quelqu’un qui n’a rien demandé.
Reste la couverture, devenue la contrainte principale. Qonto vise plus de 90 % via Omni, et ajuste en permanence le curseur entre requêtes sémantiques gouvernées et exploration libre. Cette frontière bougera avec les capacités des modèles, ce qui est une façon polie de dire qu’elle bougera aussi avec leurs hallucinations.
Pendant ce temps, la moyenne du marché
Un rapport publié par la branche custom content de MIT Technology Review (pas sa rédaction, c’est écrit noir sur blanc dans le document) met des chiffres sur le même problème. Dans les organisations interrogées, 48 % des insights produits par des agents analytiques débouchent sur des actions qui améliorent le business. C’est mieux que les 37 % que les répondants attribuent à l’an dernier, un chiffre déclaratif sur un passé récent, donc à manier avec des pincettes. Ça veut surtout dire que plus de la moitié des insights ne servent à rien.
Un petit groupe de « insight leaders » dépasse les 70 %. La différence ne vient pas du modèle : elle vient du contexte. 55 % des dirigeants interrogés citent le manque de contexte métier comme première cause d’insights médiocres, 45 % des données fragmentées ou inaccessibles. Et 45 % des entreprises ajoutent une couche sémantique à leur architecture, pendant que 60 % planchent sur la gouvernance des données et de l’IA.
Le chiffre le plus révélateur n’est pourtant pas là. Dans 52 % des organisations, les agents produisent trop d’insights pour être correctement évalués, donc pour être suivis d’effet. Moins d’un quart (24 %) arrivent à tous les évaluer, la majorité traitant les cas un par un, avec des humains à plein temps sur la tâche. Générer coûte cher, évaluer coûte plus cher, et personne n’a budgété la deuxième ligne.
La conclusion tient dans un constat qui ne fera bander aucun comité de direction : la partie décisive de ces projets ne ressemble pas à de l’IA. Elle ressemble à de la documentation. Renommer des colonnes, valider des jointures, arbitrer qu’un « client actif » ne signifie pas la même chose pour deux équipes du même étage. Aucune démo ne fait rêver avec ça, et c’est exactement pour cette raison que la moitié des agents analytiques du marché produisent des insights que personne n’utilise.
Sources :
Comments are closed