PostgreSQL

Donner à l’équipe un accès PostgreSQL en lecture seule, depuis ChatGPT ou Claude

Vos équipes interrogent la base PostgreSQL en français depuis leur IA, sur les seules tables qui les concernent, sans identifiants de base ni SQL à écrire.

Publié le 28 octobre 2026

En bref

Branchez la base une fois dans Persyst, avec un rôle de lecture : chaque équipe l’interroge en français depuis son assistant, sans identifiants.
Chaque équipe ne voit que ses tables : le schéma transmis à l’assistant ne contient rien d’autre.
Persyst n’exécute que des SELECT bornés à 200 lignes et 60 secondes, et consigne chaque requête.

Combien de nouveaux abonnés cette semaine, et combien de résiliations ?

Du 20 au 26 octobre : 3 180 nouveaux abonnés et 1 940 résiliations, soit +1 240 nets. Les résiliations sont stables par rapport à la semaine précédente ; la hausse vient des inscriptions de mercredi. Requête sur subscriptions, groupée par jour.

Sources consultées

PostgreSQL · table subscriptions · lecture

Exemple d’échange, données fictives.

Le problème : la donnée est là, l’accès ne l’est pas

Les questions du quotidien (combien d’abonnés, quels clients, quelle tendance) ont leur réponse dans la base. Pour l’obtenir, il faut un identifiant, savoir écrire le SQL, ou demander à quelqu’un de l’équipe technique. Donner les identifiants à chacun ouvre toute la base ; installer un serveur MCP sur chaque poste aussi.

Comment Persyst ouvre la base, table par table

Avec le connecteur PostgreSQL de Persyst :

Un administrateur connecte la base une fois, avec un rôle de lecture. Les identifiants restent chiffrés dans Persyst ; l’assistant ne reçoit jamais le mot de passe ni l’hôte.
Il ouvre des tables à chaque équipe : le produit voit subscriptions et payments, la finance voit aussi invoices, personne ne voit users.
Le membre pose sa question dans son assistant. L’assistant consulte le schéma autorisé, écrit un SELECT, et Persyst l’exécute (query_database) dans les limites fixées.

Chaque requête est consignée : qui, quelle table, quand.

Trois questions à essayer

« Quels sont les dix clients qui ont le plus commandé ce trimestre ? »
« Compare le panier moyen de septembre et d’octobre, par canal d’acquisition. »
« Combien de comptes créés le mois dernier n’ont jamais payé ? »

Bien préparer la base

Un rôle dédié à Persyst, avec le seul droit SELECT.
Des tables lisibles : des noms de colonnes explicites aident l’assistant à écrire la bonne requête.
Des vues pour les calculs métier sensibles (chiffre d’affaires, churn) : l’équipe interroge la vue, la définition reste maîtrisée.

Le guide PostgreSQL détaille la connexion, et chaque membre ajoute Persyst à son assistant depuis les premiers pas.

Les limites à connaître

Aucune écriture : ni INSERT, ni UPDATE, ni DELETE, ni instruction multiple.
200 lignes et 60 secondes au plus par requête.
Une table non ouverte n’apparaît ni dans le schéma ni dans les résultats.

Questions

Questions fréquentes

Comment la lecture seule est-elle garantie ?

Persyst n’accepte qu’une instruction SELECT ou WITH … SELECT, sans écriture ni DDL. Connectez en plus un rôle PostgreSQL qui n’a que le droit SELECT sur les tables concernées : la garantie tient alors aussi côté base.

Faut-il savoir écrire du SQL ?

Non. Le membre pose sa question en langage naturel. L’assistant lit le schéma autorisé, écrit la requête, Persyst l’exécute et renvoie le résultat. La requête reste visible pour qui veut la vérifier.

Peut-on exporter une table entière ?

Non. Chaque requête est limitée à 200 lignes : l’usage visé est la question, pas l’extraction. Un export complet passe par vos outils habituels.

Et une base Supabase ?

Une base Supabase est une base PostgreSQL : elle se branche avec ce connecteur, avec les mêmes garanties.