Les bases de données pour débutants : SQL, Postgres et Supabase expliqués

Pourquoi les applications web ont besoin de bases de données

Une application peut afficher un écran, recueillir une information ou exécuter une action. Mais que se passe-t-il lorsqu’elle doit se souvenir de quelque chose ?

Une plateforme de réservation doit mémoriser ses clients, ses services et ses rendez-vous. Une boutique en ligne doit gérer ses produits, ses commandes et ses stocks. Une plateforme SaaS doit savoir quels utilisateurs possèdent un compte, quels projets ils ont créés et de quelles autorisations ils disposent.

C’est à cela que servent les bases de données.

Une base de données est l’endroit où une application stocke de manière structurée et persistante les informations dont elle a besoin. Sans base de données, de nombreuses données pourraient n’exister que temporairement dans le navigateur. Elles risqueraient alors de disparaître à la fermeture de la page. Avec une base de données, l’application peut au contraire enregistrer des informations et les récupérer ultérieurement, depuis différents appareils et pour différents utilisateurs.

Une base de données est la mémoire de l’application

Vous pouvez considérer la base de données comme la mémoire permanente d’une application.

Le frontend affiche les informations. Le backend applique la logique. La base de données stocke les données.

Dans une application de réservation, par exemple :

Frontend → affiche les services et le calendrier Backend → vérifie les disponibilités et les autorisations Base de données → stocke les utilisateurs, les services et les réservations

Il existe plusieurs types de bases de données. Les bases documentaires utilisent des documents flexibles, les bases clé-valeur sont optimisées pour certains types d’accès rapides, tandis que les bases de données relationnelles organisent les données dans des tables reliées entre elles. SQL et Postgres appartiennent principalement à cette dernière catégorie. Supabase, quant à lui, ajoute autour de Postgres un ensemble de services backend conçus pour les applications web.

Bases de données relationnelles : tables, lignes et relations

Une base de données relationnelle organise les informations en tables. Chaque table représente généralement un type d’entité. Dans une plateforme de réservation, vous pourriez avoir :

• profiles → les utilisateurs ;
• services → les services disponibles ;
• bookings → les réservations.

Chaque table contient :

• des colonnes, qui décrivent les propriétés des données ;
• des lignes, qui représentent les différents enregistrements ;
• des clés primaires, qui identifient chaque enregistrement de manière unique ;
• des clés étrangères, qui relient des enregistrements appartenant à différentes tables ;
• des contraintes, qui empêchent l’enregistrement de données non valides.

Par exemple, une réservation peut contenir un profile_id et un service_id. Vous savez ainsi précisément qui a effectué la réservation et quel service a été choisi, sans avoir à copier toutes les informations de l’utilisateur et du service dans chaque réservation.

Pourquoi les relations sont-elles importantes ?

Imaginez qu’un service change de nom. Si son nom était copié dans chaque réservation, il faudrait mettre à jour des centaines, voire des milliers d’enregistrements. Avec une base de données relationnelle, la réservation peut simplement faire référence au service concerné. Les relations entre les données permettent donc de réduire les doublons et les incohérences, tout en conservant un modèle de produit mieux structuré.

Qu’est-ce que le schéma d’une base de données ?

Avant de créer une base de données, il faut décider comment organiser les informations. L’ensemble des tables, colonnes, relations, types de données et contraintes qui définissent cette structure constitue le schéma. Bien concevoir le schéma consiste à représenter dans la base de données le fonctionnement réel du produit.

Avant de créer une nouvelle table, posez-vous les questions suivantes :

1. Que représente chaque enregistrement ?
2. Quelles informations sont obligatoires ?
3. Quelles valeurs doivent être uniques ?
4. Quelles entités doivent être reliées ?
5. Qui peut lire ou modifier ces données ?

L’objectif n’est pas de créer le plus grand nombre possible de tables. Une immense table regroupant des informations très différentes peut devenir difficile à gérer. À l’inverse, placer chaque petite donnée dans une table distincte peut rendre le système inutilement complexe.

Un bon schéma trouve un équilibre entre cohérence des données, simplicité des requêtes et besoins réels du produit.

Qu’est-ce que SQL ?

C’est ici qu’intervient SQL, acronyme de Structured Query Language. SQL est le langage utilisé pour interagir avec de nombreuses bases de données relationnelles.

Il permet notamment de :

• créer des structures ;
• lire des données ;
• ajouter des enregistrements ;
• modifier des informations ;
• supprimer des enregistrements ;
• relier des données provenant de différentes tables.

Les quatre opérations fondamentales sont souvent regroupées sous l’acronyme CRUD :

• Create → créer
• Read → lire
• Update → mettre à jour
• Delete → supprimer

Un exemple simple

Supposons que nous souhaitions récupérer les réservations d’un utilisateur donné. La requête SQL pourrait être :

SELECT id, start_time, status
FROM bookings
WHERE profile_id = 42
ORDER BY start_time;

Concrètement, nous demandons :

« Donne-moi l’identifiant, l’horaire et le statut des réservations de l’utilisateur 42, classées par horaire. »

SQL permet également de combiner des informations provenant de différentes tables. Par exemple :

SELECT bookings.start_time, services.name
FROM bookings
JOIN services ON services.id = bookings.service_id;

Cette requête relie les réservations aux services correspondants afin d’obtenir à la fois l’horaire et le nom du service.

SQL est déclaratif

Une caractéristique importante de SQL est qu’il s’agit d’un langage déclaratif. Vous n’avez pas nécessairement besoin d’expliquer à la base de données chaque étape requise pour trouver une information. Vous lui indiquez le résultat que vous souhaitez obtenir, et la base de données détermine comment exécuter la requête.

SQL est par ailleurs une norme largement utilisée, même si les différents systèmes peuvent proposer leurs propres fonctionnalités et extensions. Pour commencer, il n’est pas nécessaire de tout apprendre. Comprendre des concepts tels que SELECT, les filtres, les JOIN, les regroupements, les contraintes et les transactions suffit déjà à acquérir de solides bases.

Qu’est-ce que Postgres ?

Il est important de faire ici une distinction : SQL est le langage. Postgres est la base de données.

Postgres, ou plus précisément PostgreSQL, est un système de gestion de base de données relationnelle open source. C’est le logiciel qui stocke les données, applique les contraintes et interprète les requêtes SQL.

Vous pouvez donc envisager leur relation de la manière suivante :

SQL → le langage avec lequel vous communiquez Postgres → le système qui stocke et gère les données

Postgres prend en charge des fonctionnalités essentielles telles que :

• les clés primaires et les clés étrangères
• les transactions
• les index
• les vues
• les contraintes
• les types de données avancés

Pourquoi les transactions sont-elles importantes ?

Imaginez une boutique en ligne. Lorsqu’un client achète un produit, le système peut devoir :

1. créer la commande ;
2. réduire le stock ;
3. enregistrer le paiement.

Ces opérations sont liées. Si la première réussit mais que la deuxième échoue, une commande pourrait être enregistrée sans que le stock soit mis à jour.

Les transactions permettent de traiter plusieurs opérations comme une seule unité : soit elles sont toutes exécutées correctement, soit la base de données peut rétablir l’état précédent.

Et les index ?

Les index servent à accélérer certaines recherches. Si une application doit régulièrement rechercher les réservations d’un utilisateur à une date donnée, un index peut rendre cette opération beaucoup plus efficace. Mais les index ont un coût : ils occupent de l’espace et nécessitent du travail supplémentaire lorsque les données sont modifiées.

Il n’est donc pas recommandé d’indexer automatiquement chaque colonne. Un index doit répondre à une façon réelle d’interroger les données du produit.

Qu’est-ce que Supabase ?

Si Postgres est la base de données, Supabase est une plateforme backend construite autour de Postgres. Supabase ne remplace pas Postgres.

Il ajoute plutôt un ensemble de services généralement nécessaires à la création d’applications web, notamment :

• l’authentification et la gestion des sessions ;
• le stockage de fichiers ;
• des outils d’administration de la base de données ;
• des fonctions côté serveur ;
• des API connectées aux données ;
• la Row Level Security.

La distinction la plus importante à retenir est donc la suivante :

SQL est le langage. Postgres est la base de données. Supabase est une plateforme backend qui utilise Postgres et ajoute des services permettant de créer des applications.

Cette combinaison est particulièrement utile pour les applications web, car elle permet de gérer les données, les utilisateurs, les fichiers et les autorisations au sein d’une infrastructure intégrée.

Authentification et autorisation : deux notions différentes

Là encore, il est utile de distinguer deux concepts. L’authentification répond à la question :

« Qui est cet utilisateur ? »

L’autorisation répond à la question :

« Qu’a-t-il le droit de faire ? »

Supabase Auth peut gérer l’inscription, la connexion et les sessions. La Row Level Security (RLS) permet quant à elle de déterminer quelles lignes de la base de données un utilisateur donné peut lire ou modifier. Imaginez une plateforme de réservation. Un client devrait pouvoir consulter :

ses propres réservations.

Un administrateur pourrait en revanche consulter :

toutes les réservations.

Tous deux sont des utilisateurs authentifiés, mais ils disposent d’autorisations différentes.

La sécurité ne peut pas dépendre uniquement du frontend

Masquer un bouton dans l’interface n’empêche pas quelqu’un d’exécuter une opération. Un utilisateur pourrait tenter d’envoyer directement une requête au backend.

Les règles d’accès doivent donc être appliquées dans le backend et dans la base de données, et pas uniquement dans l’interface. C’est précisément là que la Row Level Security devient importante : elle permet de définir les règles d’accès directement au niveau de la base de données.

Comment fonctionnent les bases de données dans Coderblock

Dans les applications web standard de Coderblock, chaque projet dispose d’un environnement Supabase dédié comprenant Postgres, Auth, Storage, Deno Edge Functions et Row Level Security. Une structure de base pour les profils et un système initial de gestion des rôles sont également déjà disponibles.

La différence, c’est que vous n’avez pas nécessairement besoin de commencer par configurer manuellement la base de données. Vous pouvez décrire ce que vous souhaitez créer dans le chat.

Par exemple :

« Ajoute des services avec une durée, un prix et un statut actif. »

Puis :

« Crée des réservations associées aux utilisateurs authentifiés. »

Et enfin :

« Empêche les clients de voir les réservations des autres clients et crée une vue d’administration permettant de toutes les gérer. »

L’agent peut concevoir le schéma, appliquer les migrations, connecter le frontend React au backend et configurer les politiques RLS nécessaires. Dans la section Backend de l’éditeur, vous pouvez ensuite consulter les tables, les utilisateurs authentifiés, le stockage et les fonctions.

L’aperçu en direct se met à jour à mesure que vous continuez à modifier l’application dans la conversation.

Le meilleur prompt n’est pas « crée une base de données »

Lorsque vous utilisez un générateur d’applications par IA, il ne suffit pas de demander :

« Crée une base de données pour une application de réservation. »

Il est bien plus utile de décrire le modèle du produit. Précisez :

• quelles sont les principales entités ;
• quelles informations elles doivent contenir ;
• comment elles sont reliées ;
• quels champs sont obligatoires ;
• quels utilisateurs peuvent accéder aux données ;
• quelles actions ils peuvent effectuer.

L’IA dispose ainsi des informations nécessaires pour transformer la description du produit en une structure de données cohérente.

Bonnes pratiques pour débuter avec les bases de données

Il n’est pas nécessaire d’être ingénieur en bases de données pour éviter les erreurs les plus courantes.

Utilisez des identifiants stables

Chaque table importante doit posséder une clé primaire. Évitez d’utiliser des données comme les noms ou les adresses e-mail en tant qu’identifiants permanents : elles peuvent changer.

Placez les règles au plus près des données

La validation dans le frontend est utile pour l’expérience utilisateur, mais elle ne doit pas constituer l’unique protection. Utilisez :

• des champs obligatoires ;
• des contraintes d’unicité ;
• des clés étrangères ;
• des types de données adaptés ;
• des politiques d’accès.

La base de données peut ainsi protéger l’intégrité des données, quelle que soit l’origine de la requête.

Respectez le principe du moindre privilège

Chaque utilisateur ne doit disposer que des autorisations nécessaires à l’accomplissement de ses tâches. Testez donc l’application avec différents rôles :

• visiteur anonyme ;
• utilisateur authentifié ;
• administrateur.

Vérifiez toujours ce que chaque rôle peut lire, créer, modifier ou supprimer.

Gérez le schéma à l’aide de migrations

Les bases de données évoluent en même temps que les produits. Lorsque vous ajoutez une fonctionnalité, vous pouvez avoir besoin de créer une table, d’ajouter une colonne ou de modifier une relation. L’utilisation de migrations contrôlées permet de suivre ces changements et réduit le risque de perdre des données existantes. Avant de supprimer une colonne ou de modifier une structure, vérifiez toujours qu’elle n’est plus utilisée.

Modélisez le produit, pas l’écran

C’est probablement la règle la plus importante. Une table doit représenter un concept réel du produit, et non simplement un écran de l’interface. Le design d’un tableau de bord peut changer complètement. Un client, une réservation ou une commande continueront en revanche à représenter les mêmes entités. Réfléchir d’abord au modèle de données facilite également l’évolution future du frontend.

SQL, Postgres et Supabase : ce qu’il faut vraiment retenir

Si vous débutez, inutile de mémoriser des dizaines de termes.

Retenez simplement cette relation :

SQL → le langage utilisé pour interroger et modifier les données Postgres → la base de données relationnelle qui stocke les données et exécute les requêtes Supabase → la plateforme backend qui utilise Postgres et ajoute l’authentification, le stockage, les API, les fonctions et les outils nécessaires à la création d’applications web

Dans Coderblock, ces concepts sont intégrés au processus de création de l’application. Vous pouvez décrire en langage naturel ce que votre application doit mémoriser, comment les données doivent être reliées et qui peut y accéder. L’agent peut prendre en charge l’implémentation full stack, tandis que vous contrôlez et affinez le résultat dans le chat.

Comprendre le fonctionnement des bases de données vous permet donc de faire quelque chose d’encore plus important : mieux décrire ce que vous souhaitez créer. Vous n’avez pas nécessairement besoin d’écrire du SQL. Mais savoir ce que sont les tables, les relations, les rôles, les contraintes et les autorisations vous aide à transformer une idée en une application qui ne se contente pas d’afficher des données, mais sait réellement les stocker, les relier et les protéger.