Comprendre PostgreSQL en 5 concepts pour garder le contrôle
Vous construisez votre produit avec l'IA, et c'est elle qui écrit votre base de données. Des tables apparaissent, des colonnes, des migrations, et vous validez tout sans pouvoir relire une ligne. Le jour où quelque chose casse, vous êtes spectateur de votre propre produit : vous ne savez pas ce qui est stocké, ni où, ni comment.
Cette masterclass vous donne les 5 concepts PostgreSQL qui vous suffisent pour relire le travail de l'IA et reprendre la main vous-même : les tables, les colonnes et leurs types, les clés, les index, les migrations. Pas pour devenir développeur, pour garder le contrôle.
Ce que cet exercice ne peut pas casser
Tout se fait sur une feuille de papier. Vous ne touchez à aucune base, vous ne lancez aucune commande, vous ne risquez aucune donnée. Vous dessinez votre modèle à la main, et c'est cette feuille qui servira de matière pour la suite.
Ce que vous saurez faire à la fin
- Relire un schéma de base produit par l'IA et comprendre ce que chaque table stocke.
- Dessiner votre modèle de données à la main : tables, colonnes, relations.
- Repérer une migration risquée avant de l'appliquer, au lieu de valider à l'aveugle.
- Niveau membre· le prompt prêt à coller qui transforme votre modèle dessiné à la main en schéma de base propre, prêt à relire ou à confier à l'IA.
Le chemin d'un schéma de base lisible : on les relit toujours dans cet ordre.
Cinq concepts, et un modèle dessiné à la main
Une base de données n'est pas un territoire de développeur : c'est la mémoire de votre produit. Cinq concepts suffisent pour la relire et la comprendre. Prenez-les dans l'ordre : chacun répond à une question que vous vous posez déjà sans la formuler.
1Les tables : les grandes choses que votre produit doit mémoriserdoute : « par quoi je commence ? »
Une table, c'est une grande chose dont votre produit garde la trace : des clients, des commandes, des rendez-vous. À la main : posez la question simplement. Que doit mémoriser mon produit pour fonctionner ? Chaque réponse est une table candidate. Si l'IA invente une table dont vous ne voyez pas l'usage, c'est un signal : demandez-lui de justifier au lieu de valider.
2Les colonnes et leurs types : ce que chaque table décritdoute : « c'est quoi tous ces mots techniques ? »
Chaque table a des colonnes, et chaque colonne a un type qui dit la nature de la donnée : du texte (text), un nombre entier (integer), un vrai ou faux (boolean), une date (date), un instant précis (timestamp), un identifiant unique (uuid). Six types couvrent l'essentiel. Exemple : un montant se stocke en integer, en centimes, pour éviter les erreurs d'arrondi. Quand le choix d'un type n'est pas évident, l'explication doit tenir en une ligne, sinon méfiance.
3Les clés : l'identité de chaque ligne, et les liens entre tablesdoute : « comment les tables se parlent ? »
Chaque table a une clé primaire : un identifiant unique par ligne, qui permet de la retrouver sans ambiguïté. Et les tables se relient par clés étrangères : une colonne qui pointe vers une autre table. La traduction en clair tient en une phrase : chaque X appartient à un Y. Chaque commande appartient à un client. Si vous savez dire cette phrase pour chaque lien de votre schéma, vous le comprenez.
4Les index : les colonnes qu'on cherche souventdoute : « pourquoi ça ralentit ? »
Un index, c'est un raccourci de recherche posé sur une colonne qu'on filtrera ou triera souvent. Exemple : on filtre souvent les commandes d'un client, donc on indexe la colonne qui relie la commande au client. Le bon réflexe de relecture : pour chaque index proposé, la raison doit tenir en une ligne. Pas de raison claire, pas d'index.
5Les migrations : les changements appliqués dans l'ordre, sans cassedoute : « et si je casse tout ? »
Une migration, c'est un changement appliqué à la base : créer une table, ajouter une colonne, modifier un type. Elles s'appliquent dans un ordre précis, et certaines sont risquées : supprimer une colonne, changer le type d'une colonne sur une table déjà remplie. C'est ici que se joue le contrôle : avant d'appliquer, repérez les étapes risquées et exigez un avertissement clair devant chacune.
À vous de jouer : votre modèle de données dessiné à la main
Prenez une feuille. Vous allez dessiner la mémoire de votre produit, concept par concept. Cochez à mesure.
Le résultat, en 30 secondes
À partir de votre seule feuille, le prompt produit le schéma complet : les instructions CREATE TABLE commentées, la carte des relations en français, les index justifiés, les migrations dans l'ordre avec les étapes risquées signalées, et une traduction en clair, une phrase par table.
Table commandes : stocke chaque commande passée par un client. Colonnes : id (uuid, clé primaire), client_id (uuid, clé étrangère vers clients), montant (integer, en centimes), statut (text), creee_le (timestamp). Relation : chaque commande appartient à un client. Index : sur client_id, car on filtre souvent les commandes d'un client. En clair : cette table garde la trace de chaque commande, à qui elle appartient, combien elle coûte et quand elle a été passée.
Le prompt prêt à coller
# RÔLE Tu es un architecte de bases de données PostgreSQL, pédagogue et rigoureux. Tu t'adresses à un solo qui construit son produit sans être développeur. Ton exigence : un schéma propre, normalisé, lisible par un humain. Tu ne t'appuies QUE sur ce que je te donne. Ce qui manque, tu me le demandes, tu ne l'inventes jamais. Si une information est ambiguë, tu signales le doute au lieu de trancher seul. # CONTEXTE Je construis un produit digital et je veux le schéma de sa base de données PostgreSQL. Je ne suis pas développeur : je dois pouvoir relire et comprendre ce que tu produis. Ma matière (si j'en ai) :
Le prompt transforme votre modèle dessiné à la main en schéma de base propre et relisible : tables commentées, relations en clair, index justifiés, migrations avec les étapes risquées signalées. Et si vous partez de zéro, il passe en mode interview et vous questionne table par table. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
L'IA vous propose une liste de migrations, dont une qui change le type d'une colonne sur une table déjà remplie de données clients. Que faites-vous ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un autre solo qui laisse l'IA écrire sa base : qu'est-ce qu'une clé étrangère, et pourquoi la phrase « chaque commande appartient à un client » suffit à la comprendre ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Relire un schéma PostgreSQL table par table : ce qui est stocké, sous quel type, relié à quoi.
- Traduire chaque relation en une phrase en clair : chaque X appartient à un Y.
- Repérer les migrations risquées (suppression de colonne, changement de type sur table remplie) avant de les appliquer.
Cinq concepts, et un modèle de données dessiné à la main.