Poser une question à sa base de données
La qualité de la réponse dépend bien plus de ce que vous lui désignez que de la façon dont vous formulez la question.
Data Analyst se connecte à PostgreSQL, MySQL et d’autres, traduit une question en langage courant en SQL, l’exécute et trace le résultat en barres, courbes, camembert, aires ou nuage de points. Il garde un historique, permet d’enregistrer les requêtes récurrentes et de les partager avec des personnes nommées.
On essaie, on obtient une réponse fausse, on conclut que ça ne marche pas. Presque toujours le problème est le même — et ce n’est pas le modèle.
Restreignez le schéma avant de demander
L’explorateur de schéma montre vos tables et leurs relations. Servez-vous-en pour orienter la question vers deux ou trois tables plutôt que vers toute la base.
Cela compte plus que n’importe quelle formulation. Un schéma de 90 tables contient quatre choses qu’on pourrait appeler « chiffre d’affaires », et le modèle doit deviner laquelle. Un schéma restreint à orders et order_items n’en contient qu’une. La question plus étroite est moins chère, plus rapide et juste — dans cet ordre d’importance.
Dites ce que vos mots veulent dire
Votre base ne sait pas ce que votre entreprise entend par « client actif ». Dites-le : clients ayant au moins une commande sur les 90 derniers jours. Cette seule précision élimine la catégorie la plus fréquente de mauvaise réponse — non pas une requête cassée, mais une requête correcte répondant à une autre question.
Posez les questions composées d’un seul tenant. « Chiffre d’affaires par région pour le T3, et signale tout ce qui est à plus de 15 % sous le plan » est une opération. Demander le CA, puis les régions, puis les écarts en fait trois, coûte trois fois plus de jetons, et la troisième réponse est souvent moins bonne parce que le contexte a dérivé.
Lisez le SQL, au moins une fois
Data Analyst affiche la requête générée. Lisez-la la première fois que vous demandez quelque chose sur quoi vous allez agir.
Vous vérifiez deux points : la jointure est-elle celle attendue, et la plage de dates signifie-t-elle ce que vous croyez. C’est de là que vient la fausse réponse d’apparence crédible. Un total faux de 8 % parce qu’une jointure a écarté des lignes ressemble exactement à un total juste.
Quand une requête est bonne, enregistrez-la. La requête enregistrée est la version à laquelle vous faites confiance, et la relancer le mois prochain n’emporte pas le risque qu’une question reformulée produise un autre SQL.
Le graphique est un résumé, pas le résultat
Choisissez le type selon la forme de la question : courbe pour l’évolution dans le temps, barres pour comparer des catégories, nuage de points quand vous cherchez une relation. Un camembert à neuf parts ne communique rien et n’est souvent qu’un diagramme en barres qui a renoncé.
Et pour partager un résultat, partagez la requête enregistrée plutôt qu’une capture du graphique. Le graphique est la photo d’un instant ; la requête répond encore à la question le trimestre suivant.
Questions fréquentes
Pourquoi ai-je obtenu un chiffre faux ?
La requête a généralement répondu à une question légèrement différente : une jointure qui a écarté des lignes, ou un terme ambigu comme « actif » que le schéma définit autrement que vous. Lisez le SQL généré une fois et la cause saute aux yeux.
Chaque question coûte-t-elle des jetons ?
Oui, chaque exécution puise dans votre solde IA, d’où l’avantage des questions composées sur les questions en tranches. Les requêtes enregistrées se relancent sans redemander au modèle de les écrire.
Un collègue peut-il voir un résultat sans accès à la base ?
Oui. Le partage se fait par personne avec contrôle des droits : on peut voir la réponse d’une requête enregistrée sans posséder les identifiants de la base.
