Toutes les métriques et questions P0 dans une couche de contexte unifiée : Qonto s’est donné cet objectif pour fin 2026.

En toile de fond, la mise en œuvre d’une architecture agentique de data analytics. La néobanque relate cette démarche en quatre phases, dont la première fut le text to SQL. Un bot formé sur des instructions spécifiques traduisait le langage naturel, mais ne réalisait pas lui-même les requêtes sur Snowflake. La tâche revenait aux utilisateurs, qui devaient donc comprendre le SQL.

Dans un deuxième temps, Qonto a donné à tous un accès direct au data warehouse via Claude. Celui-ci jugeait si requêtes et données étaient correctes. Mais il le faisait à partir d’un socle inconsistant : incohérences de nommage entre domaines, duplication de logique métier, définitions de métriques variables selon les équipes, etc.

Qonto donne un exemple de question posée par le customer success : « Combien de clients actifs en Allemagne au dernier trimestre ? ». Claude a repéré une colonne is_active au sein d’une table et s’en est servi. Sauf qu’elle ne tenait pas compte d’un paramètre spécifique au customer success : sur un trimestre donné, ne sont considérés comme actifs que les clients qui l’ont été chaque mois. De même, Claude a filtré « Allemagne » en s’appuyant sur le pays de domiciliation du client. Alors que le customer success segmente sur la base du pays de rattachement du portefeuille. On peut y ajouter l’aspect « dernier trimestre », que Claude a pu interpréter comme les 3 derniers mois écoulés et non le dernier trimestre calendaire.

Une couche Omni pour introduire du déterminisme

Qonto a alors basculé sur des agents Claude qui interrogeaient un fichier de contexte en Markdown. Il comprenait des définitions de métriques approuvées, des chemins de jointure validés et des entités documentées. Le SQL était compilé à partir de ces définitions. Les questions qui ne correspondaient à aucune métrique définie renvoyaient une réponse « pas encore modélisé ».

Cette approche ne passait pas à l’échelle. L’agent n’avait pas le contexte nécessaire pour répondre aux questions complexes. Qonto a ainsi entrepris de refactoriser l’architecture de ses modèles de données. Il s’est éloigné des modèles taillés pour la BI au profit de la modélisation dimensionnelle : une ligne représente un paiement, un mois de facturation, etc., le tout articulé autour des événements et de leurs descriptions.

La néobanque a choisi Omni pour sa couche de contexte. Cette dernière lui a permis d’aller vers des résultats déterministes, en décomposant chaque question en une combinaison de métriques et de dimensions prédéfinies. Elle l’oppose à sa première itération (text to SQL) : le LLM sélectionnait des tables, déduisait les relations, choisissait les agrégations et rédigeait le SQL. Quatre étapes probabilistes pour autant d’occasions de commettre des erreurs.

La data literacy avant l’AI literacy

La démarche implique une période de coût bien visible, admet Qonto. Pendant plusieurs mois, les métiers ont vu l’effort d’ingénierie se concentrer sur les modèles existants, sans livraison de nouvelles fonctionnalités. Il a plus globalement fallu déprioriser d’autres projets.

Par ailleurs, avant d’acculturer à l’IA, il a fallu penser data literacy. En effet, l’architecture agentique n’intermédiant plus d’analyste, l’utilisateur métier hérite de la responsabilité d’arbitrage.

Qonto affirme que la couverture est désormais sa principale contrainte. Il vise un taux supérieur à 90 % via sa couche de contexte Omni. Entre requêtes sémantiques gouvernées et exploration libre, il continue d’ajuster le curseur. Cette frontière, prévoit-il, se déplacera à mesure que les capacités des modèles progresseront.

Illustration générée par IA

The post Comment Qonto a basculé du text-to-SQL à l’analyse agentique appeared first on Silicon.fr.