Qu'est-ce que Postgres ? La base de données derrière de nombreuses apps, expliquée

Postgres (officiellement PostgreSQL) est une base de données relationnelle gratuite et open source : un programme qui stocke les données d'une app dans des tables de lignes et de colonnes, relie ces tables entre elles et répond à des questions à leur sujet dans un langage appelé SQL. Il est réputé pour sa fiabilité, sa rigueur dans la préservation de l'exactitude des données et sa souplesse, qui lui permet de gérer aussi bien une liste d'inscriptions qu'un ensemble de données d'une grande entreprise. De nombreuses apps web, et de nombreux services qui les hébergent, reposent dessus.

Pourquoi c'est important quand on crée avec l'IA

Lorsqu'un créateur d'apps IA ajoute « une base de données » à votre projet, il y a de bonnes chances que ce soit Postgres. Vous n'avez pas besoin d'écrire du SQL pour l'utiliser, mais un peu de compréhension vous aide beaucoup :

Vous pouvez décrire les données dans la forme dont la base a besoin. « Les clients ont plusieurs commandes ; chaque commande a plusieurs articles » se traduit directement en tables.
Vous pouvez demander les bonnes protections. Postgres peut refuser de lui-même les mauvaises données, comme un e-mail en double ou une commande pour un client qui n'existe pas, si l'IA a mis en place les règles.
Vous pouvez relire ce que l'IA a fait. Les noms de tables, les colonnes et les relations sont faciles à vérifier dans un visualiseur de tables, même si vous ne touchez jamais au code.

Une analogie du quotidien : un service d'archives très strict

Imaginez un service d'archives avec une armoire par type d'élément : une pour les clients, une pour les commandes, une pour les produits. Chaque fiche d'un tiroir comporte les mêmes cases imprimées à remplir. Chaque fiche a un numéro unique, et une fiche de commande ne répète pas les coordonnées du client ; elle indique simplement « client n° 214 », en renvoyant au tiroir des clients.

Le préposé est strict. Il ne classera pas une commande qui renvoie vers un client inexistant. Il n'acceptera pas une fiche dont la case date obligatoire est vide. Et si vous lui demandez de transférer de l'argent d'une fiche de compte à une autre, il effectue soit les deux moitiés, soit aucune, jamais une seule.

Ce préposé, c'est Postgres. Les tiroirs sont les tables, les cases imprimées sont les colonnes, chaque fiche est une ligne, et le lien « client n° 214 » est une clé étrangère.

Ce que fait bien Postgres

Fonctionnalité	Ce que cela signifie concrètement
Tables et relations	Les données vivent dans des tables qui pointent les unes vers les autres, si bien que rien n'est recopié à cinq endroits
SQL	Un langage standard pour poser des questions : « toutes les commandes impayées du mois dernier, les plus récentes d'abord »
Transactions (ACID)	Un groupe de modifications s'exécute entièrement ou pas du tout, même si le serveur plante en cours de route
Contraintes	Des règles que la base applique elle-même : champs obligatoires, e-mails uniques, liens valides entre tables
Index	Des raccourcis de recherche pour que les requêtes restent rapides à mesure que les tables grossissent
JSONB	Stocker des données souples de type document dans une colonne lorsqu'une structure fixe ne convient pas
Recherche plein texte	Rechercher des mots dans des champs texte sans service de recherche séparé, pour les cas simples
Extensions	Des modules complémentaires, comme PostGIS pour les cartes et la géolocalisation, ou pgvector pour stocker des embeddings d'IA
Sécurité au niveau des lignes	Des règles à l'intérieur de la base qui déterminent quelles lignes un utilisateur donné peut voir

Postgres est né d'un projet de recherche à l'université de Berkeley, en Californie, dans les années 1980, et il est développé en open source par une communauté mondiale depuis les années 1990. Cette longue histoire explique pourquoi il est souvent le choix par défaut : il est bien documenté, largement pris en charge, et chaque grand fournisseur cloud en propose une version gérée.

Un exemple concret : transformer un tableur en tables

Imaginons que vous dirigiez une petite entreprise de traiteur et que vous suiviez tout dans un seul tableur : chaque ligne est un événement, avec le nom du client, son téléphone et son e-mail, la date, les plats et le prix.

Les problèmes apparaissent vite. Le même client figure sur six lignes avec deux numéros de téléphone différents. Les plats sont saisis dans une seule cellule sous la forme « canapés x40, salade x2 », si bien qu'on ne peut pas totaliser le nombre de canapés préparés ce mois-ci.

Dans Postgres, les mêmes informations deviennent quatre tables :

Table	Colonnes	Remarques
clients	id, nom, telephone, email	L'e-mail doit être unique
evenements	id, client_id, date, lieu, statut	client_id doit correspondre à un client réel
plats	id, nom, prix_unitaire	Une ligne par plat
evenement_plats	evenement_id, plat_id, quantite	Relie les événements aux plats, avec une quantité

Désormais, le numéro de téléphone d'un client ne vit qu'à un seul endroit. « Combien de canapés avons-nous préparés en mars ? » devient une seule requête SQL. Et lorsque vous enregistrez un nouvel événement avec ses plats, une transaction garantit que vous n'obtenez jamais un événement dont la moitié des plats seulement a été enregistrée.

C'est l'étape que l'on oublie souvent lorsqu'on demande à une IA de « faire une app à partir de mon tableur ». Le guide pour transformer un tableur en app va plus loin.

Termes clés

Table, ligne, colonne : un type d'élément, une occurrence de cet élément, une information sur cet élément.
Clé primaire : l'identifiant unique de chaque ligne, généralement id.
Clé étrangère : une colonne qui pointe vers une ligne d'une autre table, comme client_id.
Schéma : la conception de l'ensemble de vos tables et colonnes.
Migration : une modification enregistrée et reproductible du schéma, par exemple « ajouter une colonne lieu à evenements ».
Requête : une question ou une instruction écrite en SQL.
Chaîne de connexion : l'adresse et le mot de passe que votre backend utilise pour atteindre la base. C'est un secret : voir variables d'environnement et secrets.
Postgres géré : un service qui fait tourner, sauvegarde et met à jour Postgres pour vous.

Pour les opérations courantes que toute app effectue sur ces tables (créer, lire, mettre à jour, supprimer), voir ce que signifie le CRUD.

Erreurs courantes et idées fausses

Une seule table géante. Recopier la feuille de calcul colonne par colonne conduit aux mêmes problèmes de duplication. Séparez les éléments qui se répètent dans leurs propres tables.
Stocker des listes dans un seul champ texte. « canapés x40, salade x2 » dans une seule colonne ne peut pas être compté ou recherché correctement. Utilisez une table de liaison.
Aucune contrainte. Sans « l'e-mail doit être unique » ou « chaque événement a besoin d'un client », de mauvaises données entrent discrètement et ne se révèlent que des mois plus tard.
Modifier la base à la main en production. Demandez les changements de schéma sous forme de migrations, pour que la modification soit enregistrée et puisse être rejouée.
Laisser le navigateur parler directement à la base. Le frontend doit passer par votre backend, qui vérifie les droits. Le mot de passe de la base n'a jamais sa place dans le code de la page.
« Postgres est réservé aux grandes entreprises. » Il fonctionne tout aussi bien pour une liste d'attente de 50 lignes, et vous n'aurez pas à en changer en grandissant.
Croire qu'une base de données est une sauvegarde. Elle stocke les données ; elle ne vous protège pas automatiquement de leur suppression. Vérifiez les sauvegardes fournies par votre hébergeur.

Que demander à votre créateur d'apps IA

« Enregistre [les éléments] dans une base de données. Tables : … avec ces champs : … Relie chaque [commande] à un [client]. »
« Rends l'e-mail unique pour les clients. Rends ces champs obligatoires. N'autorise pas une commande sans client. »
« Utilise des migrations pour chaque changement de schéma. »
« Ajoute des index pour les recherches que nous faisons le plus souvent : commandes par client et par date. »
« Tous les accès à la base passent par le serveur. Garde la chaîne de connexion dans des variables d'environnement. »

Si vous ne connaissez pas encore la notion même de base de données, commencez par qu'est-ce qu'une base de données, puis revenez ici. Une app full-stack montre où la base se place par rapport au frontend et au backend.

Postgres sur Mythex

Mythex accorde à chaque projet qui en a besoin sa propre base Postgres dédiée. Vous n'avez rien à configurer : demandez-le dans le chat (« enregistre les e-mails de la liste d'attente dans une base de données ») ou utilisez la commande /database, et Mythex la rattache, injecte les détails de connexion dans votre app et peut créer les tables pour vous. Une app publiée met sa base en veille après cinq minutes d'inactivité et la réveille à la requête suivante ; vous êtes facturé pour le temps pendant lequel elle a réellement été active, sur le même solde de crédits que pour la création. Les détails figurent dans la documentation des bases de données, et les modèles de tableaux de bord sont un bon moyen de voir des apps alimentées par des données.

Questions

Postgres et PostgreSQL, est-ce la même chose ?

Oui. PostgreSQL est le nom officiel et Postgres le nom courant ; les deux désignent la même base de données relationnelle open source.

Postgres est-il gratuit ?

Oui. PostgreSQL est open source sous la licence permissive PostgreSQL, vous pouvez donc l'utiliser gratuitement, y compris dans des produits commerciaux. Vous ne payez que les serveurs ou le service géré qui le fait tourner.

Quelle est la différence entre Postgres et MySQL ?

Ce sont deux bases SQL relationnelles gratuites, toutes deux adaptées à la plupart des apps. Postgres est réputé pour sa rigueur sur l'intégrité des données, ses types de données riches comme JSONB et les tableaux, et son large écosystème d'extensions ; MySQL est réputé pour sa simplicité et sa longue présence dans l'hébergement web.

Postgres convient-il à une petite app ?

Oui. Il fonctionne très bien pour une simple liste d'attente d'une seule table, comme pour de grands systèmes de production, donc vous n'aurez pas à changer de base de données à mesure que l'app grandit. Les services gérés permettent de l'exploiter sans administrateur de base de données.