Coût d'un agent Text to SQL : ce qu'exige vraiment une fonctionnalité « Ask Your Data »

Le coût d'un agent text to SQL pour une fonctionnalité SaaS en production se situe entre quelques semaines d'ingénierie concentrée et un trimestre de travail d'une petite équipe. Cet écart dans le coût d'un agent text to SQL vient presque entièrement de trois facteurs : le degré de désordre de votre schéma, le niveau d'exigence de l'isolation des tenants, et le nombre de questions auxquelles l'agent doit répondre correctement avant que les clients ne le voient. Le modèle est la partie peu coûteuse. C'est la couche sémantique et les garde-fous de sécurité qui absorbent le budget.

Ce que les fondateurs achètent réellement

La fonctionnalité inscrite sur la roadmap est une zone de texte dans le tableau de bord qui dit « posez une question sur vos données ». Un client tape « quels comptes ont churné le trimestre dernier après un paiement échoué », l'agent écrit du SQL, l'exécute, et renvoie un tableau ou un graphique. Chaque démo fournisseur de cette fonctionnalité fonctionne à merveille, parce que chaque démo fournisseur tourne sur cinq tables aux noms du type customers et orders.

Votre base de données a status, status_v2 et une colonne deleted_at qu'une requête sur deux oublie. Elle a un tenant_id sur la plupart des tables et un organisation_id sur les plus anciennes. Elle a trois façons de calculer le chiffre d'affaires, et la finance n'en fait confiance qu'à une seule. Un LLM qui lit ce schéma à froid produira du SQL plausible mais faux, d'une manière que le client ne peut pas détecter à partir du résultat. L'écart entre la démo et votre schéma, c'est tout le projet.

Coût d'un agent text to SQL : où va vraiment l'argent

La couche sémantique est le poste le plus lourd

Une couche sémantique est une description écrite de ce que signifient vos données : quelles tables l'agent peut toucher, comment elles se joignent, comment sont définis « client actif » et « chiffre d'affaires mensuel », et quelles colonnes sont du bruit héritée du passé. Les outils récents dans ce domaine existent précisément pour empêcher les agents de deviner le SQL à partir des noms de colonnes bruts, et l'idée est solide. Le modèle arrête d'inventer des jointures et commence à remplir un modèle que vous contrôlez.

Ce qui coûte cher, c'est que son écriture relève du métier, pas seulement de l'ingénierie. Quelqu'un qui connaît le produit doit s'asseoir et décider, par écrit, ce que signifient les métriques. Si votre équipe n'a jamais tranché sur une définition du churn, c'est cette semaine-là que vous allez le découvrir. Budgétisez-le honnêtement. Sur un produit mature avec une centaine de tables, la couche sémantique seule peut représenter un tiers du coût total, et c'est aussi la partie qui continue de rapporter, car vos analystes humains finissent eux aussi par l'utiliser.

Isolation des tenants et permissions

Un agent text to SQL est un programme qui exécute des requêtes arbitraires écrites par un modèle de langage sur les données de vos clients. Traitez-le comme tel. La connexion à la base de données que l'agent utilise doit être un rôle dédié en lecture seule, jamais l'utilisateur applicatif et jamais rien disposant de droits d'écriture. Dans PostgreSQL, imposez la frontière entre tenants avec des politiques de row-level security indexées sur le tenant, afin qu'une clause WHERE erronée écrite par le modèle renvoie un résultat vide plutôt que les lignes d'un autre client. Fixez un statement_timeout sur ce rôle afin qu'une mauvaise jointure ne reste pas bloquée dix minutes sur votre base primaire.

Il s'agit du même problème de conception que le RAG sensible aux permissions : le contrôle d'accès doit vivre sous le modèle, dans une couche que le modèle ne peut pas contourner en discutant. Si la réponse d'un fournisseur à « comment empêchez-vous les fuites entre tenants » est « le prompt lui dit de filtrer par tenant », passez votre chemin.

Le jeu d'évaluation

Avant que la fonctionnalité ne soit lancée, il vous faut une banque de vraies questions avec des réponses connues et correctes, extraites de tickets support et d'appels commerciaux, exécutées sur une copie des données de production. Cinquante questions, c'est un début maigre. Deux cents, c'est confortable. Chacune coûte le temps de quelqu'un pour écrire le SQL de référence et vérifier le résultat, et c'est ce livrable qui vous dira si la chose fonctionne vraiment. Nous avons déjà écrit sur les raisons pour lesquelles les évaluations ont leur place dans le contrat fournisseur, et cette fonctionnalité en est le cas d'école le plus clair : sans la banque de questions, « ça fonctionne » signifie « ça a fonctionné sur les trois requêtes qu'on a testées en démo ».

L'appel au modèle lui-même

Le coût d'inférence est presque négligeable comparé à ce qui précède, et l'architecture qui l'entoure devrait rester simple. Le schéma qui tend à l'emporter est un seul appel, avec la couche sémantique, les définitions de table pertinentes et une poignée d'exemples travaillés dans le contexte, renvoyant du SQL plus une explication d'une ligne. Les chaînes à plusieurs étapes (un planificateur qui choisit les tables, un rédacteur qui rédige le SQL, un correcteur qui répare les erreurs) semblent plus rigoureuses, mais ajoutent en pratique de la latence, du coût, et de nouveaux points de défaillance.

Nous avons observé la même chose dans un système très différent. Notre propre moteur de prospection scrape le site d'un prospect avec un crawler auto-hébergé et un modèle local, puis rédige un e-mail personnalisé par entreprise. Nous avons commencé avec une chaîne qui extrayait des faits à une étape puis rédigeait à une autre. Un seul appel qui faisait les deux, avec un bon contexte, a battu la chaîne en coût comme en qualité de sortie. Le text to SQL se comporte de la même manière : mettez la connaissance dans le contexte, pas dans l'orchestration. Une tentative de nouvelle exécution après une erreur SQL, c'est acceptable. Un pipeline à cinq étapes est généralement le signe que la couche sémantique est absente.

Construire ou acheter

Il existe trois options réalistes.

• La fonctionnalité IA intégrée à votre outil de BI existant. La moins coûteuse et la plus rapide. Adaptée aux tableaux de bord internes ou à un produit mono-tenant. Faible dès que chaque client ne doit voir que ses propres lignes, et que les définitions de métriques sont celles que l'outil déduit lui-même.
• Un fournisseur d'analytics embarqué avec du langage naturel en surcouche. Un compromis raisonnable si votre schéma est propre et que votre modèle de tenancy correspond au leur. Vérifiez où les données sont traitées. Si vos clients sont dans le Golfe ou dans la santé, la résidence des données peut suffire à écarter cette option.
• Le construire sur votre propre stack. Le plus coûteux au départ, et le bon choix lorsque l'isolation des tenants n'est pas négociable, lorsque vos métriques ont des définitions maison, ou lorsque la fonctionnalité fait partie de ce que vous vendez plutôt qu'un simple plus.

Le vrai test est de savoir si la zone « posez une question sur vos données » est un différenciateur produit ou une simple commodité. Si les clients paieraient plus pour l'avoir ou churneraient sans elle, construisez-la. Si c'est une case à cocher pour la plaquette commerciale, achetez et passez à autre chose.

À quoi ressemble une première version sensée

Cadrez étroitement la première version. Une version qui répond correctement à un ensemble restreint de questions vaut mieux qu'une version qui tente tout et se trompe souvent.

1. Choisissez un seul domaine (facturation, usage, ou support) et dix à quinze tables.
2. Écrivez la couche sémantique pour ce domaine uniquement, avec des définitions de métriques validées par celui ou celle qui est propriétaire des chiffres.
3. Créez le rôle en lecture seule, les politiques de row-level security et les délais d'expiration avant même d'écrire le premier prompt.
4. Constituez le jeu d'évaluation à partir de vraies questions clients et exécutez-le à chaque modification.
5. Affichez le SQL généré et le nombre de lignes à côté de chaque réponse, afin que les utilisateurs avancés puissent repérer les erreurs.
6. Lancez-la auprès d'une poignée de comptes bienveillants et lisez chaque requête qu'ils exécutent pendant deux semaines.

Étendez au domaine suivant seulement une fois que le taux de réussite du jeu d'évaluation sur le premier domaine est devenu ennuyeux à force d'être bon.

Questions à poser à qui vous fait un devis

Un devis pour cette fonctionnalité qui revient sous forme d'un seul chiffre, sans aucune question posée en retour, est un devis pour la démo, pas pour le produit. Demandez :

• Comment l'agent se connectera-t-il à la base de données, et avec quels droits ?
• Où vit le filtre de tenant, et que se passe-t-il si le modèle l'omet ?
• Qui écrit les définitions de métriques, et combien de temps cela doit-il prendre selon les estimations ?
• À quoi ressemble le jeu d'évaluation au moment de la livraison, et quel taux de réussite constitue le critère d'acceptation ?
• Quel modèle est utilisé, et quel est le coût par requête à raison de mille questions par jour ?
• Que se passe-t-il quand le schéma change le trimestre prochain ?

Les réponses vous diront si l'équipe a déjà livré cela sur un vrai schéma ou seulement sur un tutoriel. Si vous voulez un second avis sur un devis, ou une estimation cadrée pour votre propre base de données, parlons-en.