« Interroger les données en une phrase » semble simple, mais la mise en production soulève de nombreux problèmes : définitions métier hétérogènes, schémas complexes, SQL généré erroné, permissions à ne pas dépasser, résultats à expliquer. Le cœur d'une API d'analyse de données par IA n'est pas de faire « écrire du SQL » au modèle, mais de mapper durablement une question en langage naturel vers des données et des rapports fiables.
Cet article propose un plan d'entreprise couvrant architecture, conception du schéma, prompt, validation, permissions, tests de précision et coûts.
Remarque : bases de données, plateformes BI et interfaces de modèles diffèrent ; l'article prend l'exemple courant d'une « base en lecture seule + interface de dialogue compatible OpenAI ». Modèles et prix sont sur la page Tarifs des modèles.
1. Architecture d'ensemble
Découpez la chaîne en étapes observables :
Question en langage naturel
→ détection d'intention (requête / explication / clarification)
→ recherche de schéma (tables, champs, indicateurs, exemples)
→ génération SQL
→ validation statique + injection des permissions
→ exécution en lecture seule (timeout, limite de lignes)
→ validation du résultat
→ configuration du graphique + interprétation textuelle
Principes clés :
- Le modèle ne se connecte pas à la base de production, seulement à une réplique en lecture seule ou à l'entrepôt.
- Les permissions sont injectées côté serveur, jamais confiées au prompt.
- Chaque étape est journalisée : question, tables récupérées, SQL généré, durée, nombre de lignes.
- En cas d'échec, l'utilisateur reçoit une explication compréhensible, pas l'erreur brute de la base.
2. Le schéma compte plus que le modèle
Le modèle ne connaît pas la définition maison d'un « utilisateur actif » ou d'une « commande valide ». Fournissez explicitement cette connaissance.
Tenez une « fiche de schéma » par table :
| Champ | Exemple |
|---|---|
| Nom de table | dwd_order |
| Sens métier | Détail des commandes, une ligne par article commandé |
| Clé / granularité | order_id + sku_id |
| Champs fréquents | date de commande, montant payé, statut, canal |
| Définition de l'indicateur | montant payé = montant réellement réglé, hors remboursements |
| Tables liées | utilisateurs, produits, canaux |
| Interdictions | ne pas utiliser create_time à la place de la date de paiement |
| Question type | montant payé par canal sur 30 jours |
Préparez aussi :
- les synonymes métier : GMV, chiffre d'affaires et volume de transactions pointent vers le même indicateur ;
- un dictionnaire d'indicateurs : définition, numérateur et dénominateur, période, retard de données ;
- quelques exemples « question → SQL » couvrant les requêtes courantes ;
- les chemins de jointure entre tables, pour éviter les suppositions.
La recherche de schéma peut combiner mots-clés et vecteurs pour placer les 5–10 tables et définitions pertinentes dans le contexte. Injecter tout le schéma coûte cher et perturbe le modèle.
3. Comment écrire le prompt
Le prompt doit contraindre, pas encourager l'improvisation. Modèle utilisable :
Tu es un assistant d'analyse de données d'entreprise. À partir du schéma et des définitions fournis, transforme la question en SQL.
Exigences :
1. Génère une seule instruction SELECT ; interdis INSERT/UPDATE/DELETE/DDL.
2. Utilise uniquement les tables et champs fournis, sans inventer de champ.
3. La définition des indicateurs suit le dictionnaire, et les hypothèses sont précisées dans assumptions.
4. Si la période est ambiguë, utilise par défaut les 30 derniers jours et indique l'hypothèse.
5. Si la question est ambiguë, renvoie d'abord clarifying_question, sans deviner.
6. Sortie JSON : {"sql": "", "assumptions": [], "clarifying_question": null}
Quelques détails :
- Demandez au modèle d'expliciter ses hypothèses, pour que le métier puisse vérifier les définitions.
- Imposez « clarifier avant d'interroger » : cela réduit nettement les réponses hors sujet.
- Fournissez des formules dédiées pour « variation annuelle / mensuelle / part », sans laisser le modèle improviser.
- En dialogue multi-tours, conservez indicateurs et période du tour précédent, mais pas le SQL périmé.
4. Validation SQL et garde-fous d'exécution
Générer le SQL n'est que le début. Avant exécution, prévoyez au moins cinq contrôles :
- Analyse syntaxique : parser SQL, refuser plusieurs instructions.
- Type d'instruction : SELECT uniquement, pas d'écriture ni de procédure stockée.
- Liste blanche d'objets : tables et champs qui y figurent.
- Injection de permissions : ajout automatique des filtres tenant, service, région.
- Maîtrise du coût : période, LIMIT, timeout et plafond de données scannées.
Côté exécution, utilisez un compte en lecture seule dédié, connecté à une réplique, avec :
- un timeout de requête, par exemple 30 secondes ;
- un nombre maximal de lignes, par exemple 1000 ;
- un EXPLAIN préalable sur les grosses tables pour estimer le scan ;
- une à deux tentatives maximum, en renvoyant l'erreur de la base au modèle pour correction ;
- un cache des questions identiques, avec périmètre de permission dans la clé.
5. Permissions : le modèle ne remplace pas le système de droits
L'accident le plus courant est « un utilisateur voit des données qu'il ne devrait pas voir ». Réutilisez le modèle de permissions du BI ou de l'entrepôt :
- Niveau jeu de données : quelles tables sont accessibles.
- Niveau ligne : filtrage par tenant, service, région.
- Niveau colonne : masquage ou suppression des téléphones, pièces d'identité, prix de revient.
- Niveau indicateur : permission distincte pour les indicateurs sensibles.
- Niveau session : vider contexte et cache lors d'un changement d'utilisateur.
Le modèle ne produit qu'une intention de requête ; les permissions sont imposées côté serveur, autour du SQL ou dans une vue. Journalisez question d'origine, SQL final, exécutant et nombre de lignes pour l'audit. L'export fait l'objet d'une permission distincte, pour éviter que « pouvoir consulter » signifie « pouvoir tout télécharger ».
6. Des résultats aux graphiques
Un résultat de requête n'est pas un rapport. Demandez au modèle une « configuration de graphique + conclusion textuelle », pas une image :
| Forme de données | Graphique recommandé |
|---|---|
| Série temporelle | Courbe |
| Comparaison de catégories | Barres |
| Répartition | Camembert ou barres empilées |
| Corrélation | Nuage de points |
| Indicateur unique | Carte d'indicateur |
La conclusion doit inclure définition, période, chiffres clés et anomalies. Par exemple : « sur 30 jours, le montant payé baisse de 8 % par rapport au mois précédent, principalement sur le canal Est », avec un lien vers le détail. Évitez « les données se portent bien ».
7. Mesurer la précision
Préparez 100 à 300 questions métier réelles, par niveaux de difficulté :
- requête et agrégation sur une table ;
- jointures multi-tables ;
- variation annuelle, mensuelle, part ;
- questions ambiguës nécessitant clarification ;
- questions sans données ou sans permission.
L'évaluation ne compare pas la ressemblance du SQL, mais l'égalité du résultat exécuté. Enregistrez :
| Indicateur | Description |
|---|---|
| Exactitude d'exécution | Résultat identique à la réponse humaine de référence |
| Taux de clarification | Les questions ambiguës déclenchent-elles la bonne question de retour ? |
| Taux de blocage des accès hors périmètre | Les requêtes interdites sont-elles refusées ? |
| Taux d'explicabilité des échecs | L'erreur est-elle traduite en langage utilisateur ? |
| Latence moyenne | De la question au graphique |
Relancez la régression chaque semaine, et après tout changement de modèle ou de schéma. Au début, conservez un mode « confirmation humaine du SQL », puis ouvrez l'exécution automatique quand la stabilité est établie.
8. Coûts et performances
Le coût vient de trois blocs : récupération du schéma, génération SQL, interprétation du résultat.
- Utilisez la recherche vectorielle pour ne placer que les tables pertinentes.
- Petit modèle pour l'intention et les requêtes simples, modèle fort pour les requêtes complexes.
- Mettez en cache les questions fréquentes et les résultats à périmètre identique.
- N'envoyez à l'interprétation que les données agrégées, pas le détail complet.
- Résumez les longs schémas plutôt que de transmettre tout le DDL à chaque fois.
Formule d'estimation :
Coût par requête =
tokens de contexte du schéma × prix d'entrée
+ tokens de sortie du SQL × prix de sortie
+ tokens d'interprétation × prix
+ coût d'exécution base de données
Les prix exacts sont sur la page Tarifs des modèles ; le coût base de données se calcule séparément, surtout pour les scans de grosses tables.
9. Échecs courants et traitement
| Symptôme | Cause fréquente | Traitement |
|---|---|---|
| Champ inexistant | Schéma non récupéré ou champ inventé | Validation par liste blanche + renvoi de l'erreur pour retenter |
| Définition incohérente | Dictionnaire d'indicateurs incomplet | Compléter le dictionnaire, exiger les hypothèses |
| Jointure qui multiplie les lignes | Mauvaise clé ou granularité | Fournir les chemins de jointure, vérifier le nombre de lignes |
| Période erronée | Fuseau ou valeur par défaut ambiguë | Unifier le fuseau, expliciter la période par défaut |
| Dépassement de permission | Filtrage confié au prompt | Injection forcée côté serveur |
| Réponse hors sujet | Question ambiguë | Clarifier avant d'interroger |
Questions fréquentes
L'IA d'analyse de données remplace-t-elle le BI ?
Non. Elle convient aux questions ponctuelles, à l'extraction rapide et à l'explication de rapports ; les rapports fixes complexes restent du ressort du BI.
Faut-il fournir tout le schéma au modèle ?
Non. La recherche de schéma ne place que les tables et indicateurs pertinents, ce qui réduit coût et erreurs.
Le SQL généré peut-il être exécuté directement ?
Ce n'est pas recommandé. Il doit passer par les quatre contrôles — syntaxe, liste blanche, permissions, coût — et s'exécuter sur une réplique en lecture seule.
Quel niveau de précision peut-on atteindre ?
Cela dépend de la qualité du schéma, de la complexité des questions et du protocole d'évaluation. Établissez une base avec de vraies questions, puis améliorez semaine après semaine ; ne généralisez pas à partir de questions de démonstration.
Comment démarrer dans une petite équipe ?
Choisissez un domaine, par exemple les ventes ou l'exploitation, documentez 10–20 tables et un dictionnaire d'indicateurs, construisez un jeu de 50 questions, puis décidez de l'extension.
Pour aller plus loin
La réussite d'une IA d'analyse de données tient à 80 % au schéma, aux définitions d'indicateurs et aux permissions, pas aux paramètres du modèle. Faites un POC sur un domaine, validez la boucle « question — contrôle — exécution — graphique — explication », puis élargissez. Pour une entrée de modèles et une gestion d'usage unifiées, vous pouvez créer un compte ZSQH AI Gateway ; modèles et prix sont sur la page Tarifs des modèles.
Lectures associées :
