Poser des questions à PostgreSQL en langage naturel

Vos commandes sont dans PostgreSQL et vous devez présenter les ventes du mois dernier par région. Avec Datarelix, décrivez le rapport, examinez le SQL généré et le résultat, puis demandez un graphique. Il vous faut des informations de connexion et des droits de lecture sur les tables ou vues concernées, sans devoir écrire vous-même la première requête.

Définir le rapport

Pour un commerçant, la demande pourrait être :

Affiche le montant des commandes payées par région pour août 2026, en euros. Exclus les commandes annulées. Utilise la date de commande et présente les remboursements séparément s’ils sont disponibles.

Précisez la date qui définit une vente et le traitement des taxes et remboursements. Si ces définitions manquent, demandez à la personne responsable du reporting quels champs utiliser.

Obtenir les accès

Si vous disposez déjà d’une chaîne de connexion PostgreSQL autorisée, utilisez-la pour ajouter la connexion. Sinon, demandez l’hôte, le port, la base, le schéma autorisé, les paramètres TLS et un compte dédié au reporting. La source doit être joignable depuis le service hébergé Datarelix ; la présentation sécurité montre ce que ce service conserve et ce qui parvient au modèle.

Le responsable doit examiner les droits directs, hérités et publics. Le rôle PostgreSQL pg_read_all_data donne un accès de lecture étendu sans contourner les règles de sécurité par ligne ; il ne remplace pas la vérification du droit CONNECT à la base. Un rôle limité au rapport convient mieux si seules quelques tables sont nécessaires. Rôles prédéfinis PostgreSQL

Le guide de connexion PostgreSQL détaille les autorisations, TLS et le dépannage. Commencez par une connexion directe ou un pool de connexions en mode session compatible. Le mode transaction dépend du fournisseur, de la version et de la gestion des requêtes préparées : confirmez sa compatibilité avec le responsable.

Vérifier le tableau avant le graphique

Cette requête calcule le montant des commandes payées, pas le chiffre d’affaires net après remboursements :

SELECT region, SUM(total_eur) AS paid_order_value_eur
FROM reporting.orders
WHERE status = 'paid'
  AND ordered_at >= DATE '2026-08-01'
  AND ordered_at < DATE '2026-09-01'
GROUP BY region
ORDER BY paid_order_value_eur DESC;

Région	Montant des commandes payées, EUR
North	1 200
South	800

Un graphique doit représenter North avec une valeur 1,5 fois supérieure à South. Les deux lignes correspondent aux régions, pas au nombre de commandes. Si les remboursements sont dans une autre table, demandez d’abord leur total séparément.

Comparez avec un total connu et faites examiner les jointures par une personne qui maîtrise SQL si plusieurs tables interviennent. Pour des horodatages, convenez aussi du fuseau horaire du rapport : les limites du mois peuvent différer du réglage de la session de base de données.

À quoi ressemble le SQL généré ?

Sur le schéma d’un commerçant — customers, orders, order_items — la question « Quels étaient nos dix premiers clients par valeur de commandes terminées, avant remboursements, au T2 2026 ? » peut être représentée par le SQL suivant :

Les prix unitaires de cet exemple sont en EUR ; le montant correspond aux commandes terminées avant remboursements.

SELECT
  c.customer_id,
  c.name,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.customer_id
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= DATE '2026-04-01'
  AND o.ordered_at < DATE '2026-07-01'
GROUP BY c.customer_id, c.name
ORDER BY revenue DESC
LIMIT 10;

C’est du PostgreSQL idiomatique : des intervalles de dates semi-ouverts plutôt que BETWEEN, date_trunc('quarter', …) quand il faut une granularité de période, LIMIT/OFFSET pour la pagination, des guillemets droits pour les identifiants qui en ont besoin. Du SQL repris d’un autre dialecte peut contenir TOP 10 ou des identifiants entre accents graves, que PostgreSQL ne reconnaît pas — le mécanisme général est expliqué dans text-to-SQL expliqué.

Remarquez aussi ce qui est décidé ici : status = 'completed', le brut plutôt que le net des remboursements, un trimestre calendaire plutôt que les 90 derniers jours. Ce sont des interprétations. Voir la requête, c’est ce qui vous permet de les contrôler — tout l’intérêt de vérifier une réponse générée par IA.

Les points PostgreSQL à examiner côté analyste

Point	Effet possible sur la réponse	Contrôle utile
Choix du schéma	Plusieurs schémas peuvent contenir le même nom de table	Confirmer les schémas autorisés et les noms qualifiés des sources
Vues et vues matérialisées	Une vue peut porter une définition approuvée ; une vue matérialisée a son propre historique d’actualisation	Identifier son responsable et sa dernière actualisation
Sécurité au niveau ligne	Le rôle connecté peut voir moins de lignes que celui d’un rapport existant	Comparer identités et politiques avant d’interpréter un résultat vide
Noms entre guillemets	Les identifiants à casse mixte nécessitent leur forme exacte	Comparer les noms générés à ceux découverts
Bornes de dates	Le sens d’un horodatage dépend de son type et du fuseau	Examiner des lignes proches de minuit et de la fin de mois
Granularité de jointure	Une commande peut correspondre à plusieurs articles ou paiements	Comparer identifiants distincts et lignes jointes avant de sommer les totaux de commandes

Une connexion peut inclure plusieurs schémas autorisés. Les requêtes entre schémas nécessitent toujours les droits correspondants et doivent rester dans ce périmètre. Deux schémas autorisés ne nécessitent pas à eux seuls deux connexions distinctes.

Examiner les droits sans modifier les objets de production

Dans son client SQL habituel, l’analyste ou le responsable de la base peut contrôler le droit de lecture sur une table connue :

SELECT has_table_privilege(current_user, 'reporting.orders', 'SELECT')
       AS can_read_orders;

Ce contrôle porte sur un droit précis, pas sur l’ensemble des accès effectifs. Examinez séparément rôles hérités, droits publics, politiques et fonctions. Pour rendre lisibles les futures tables de reporting, l’administrateur configure les droits par défaut du rôle qui crée ces tables ; modifier ceux d’un autre rôle ne les couvre pas. La référence PostgreSQL contient ces étapes.

Distinguer problème de connexion et problème de résultat

Un échec de connexion appelle un contrôle du point d’accès, des identifiants, du réseau et de TLS. Une liste de schémas vide appelle un contrôle de la base, des schémas autorisés et des droits de découverte. Un résultat vide appelle un contrôle des filtres, des données disponibles et des politiques de lignes. Reformuler la question métier ne répare pas un droit manquant.

Le comportement des requêtes préparées dépend du pooler et de sa configuration. Utilisez le point d’accès conseillé par le fournisseur pour ce client ; une connexion directe ou de session adaptée peut aider au diagnostic. PgBouncer documente les requêtes préparées au niveau protocole avec la configuration correspondante ; PREPARE SQL suit d’autres contraintes. Compatibilité PgBouncer

Pour un rapport lent, réduisez la période et examinez les jointures. L’analyste peut consulter le plan dans un outil autorisé et discuter index ou vues de reporting avec le responsable. Deux lignes de sortie peuvent nécessiter la lecture d’une grande table. Le parcours Datarelix en lecture seule ne crée pas d’index, ne migre pas et n’administre pas la base.

Conserver un rapport utile

Quand le tableau correspond à la définition attendue, demandez un graphique en barres et ajoutez-le à un tableau de bord. Celui-ci reste privé à votre compte et utilise une seule connexion. Son actualisation manuelle relance la requête enregistrée. Avec les dates fixes ci-dessus, il continuera à afficher août ; un rapport mensuel évolutif demande une règle de dates relative.

Si aucune table n’apparaît, vérifiez la base, le schéma et le rôle avant de reformuler. Si une requête est lente, réduisez la période ou demandez une vue de reporting : un petit résultat peut nécessiter beaucoup de calcul.

Suivez le démarrage rapide, puis l’exemple de rapport de ventes hebdomadaire pour préparer des graphiques réutilisables.