Le problème : un fichier Excel qui explose
Imaginez une boutique en ligne. Au début, vous notez vos clients dans un fichier Excel : une ligne par client, une colonne pour le nom, une pour l'email. Ça marche.
Puis arrivent les commandes. Vous ajoutez des colonnes : commande 1, commande 2, commande 3... Au bout de quelques mois, votre fichier a 80 colonnes, des doublons partout, et chercher « combien Marie a dépensé en mars » prend dix minutes. Le fichier est devenu un cauchemar.
C'est exactement le problème qu'une base de données relationnelle résout. Au lieu d'un seul fichier géant, vous découpez les informations en tables reliées entre elles, et vous posez vos questions avec un langage précis : SQL.
Une table, c'est un tableur structuré
Une table ressemble à une feuille de tableur. Chaque colonne a un nom et un type (texte, nombre, date). Chaque ligne (aussi appelée « enregistrement ») représente une entité : un client, une commande, un produit.
Voici une table clients :
id | nom | email | ville
----+----------------+------------------------+-----------
1 | Marie Dupont | marie@exemple.fr | Besançon
2 | Karim Benali | karim@exemple.fr | Dijon
3 | Léa Martin | lea@exemple.fr | LyonLa colonne id est la clé primaire (primary key) : un identifiant unique qui désigne une seule ligne, sans ambiguïté. Deux clients peuvent s'appeler « Marie Dupont », mais ils n'auront jamais le même id.
La clé primaire est presque toujours un nombre auto-incrémenté (1, 2, 3...). C'est l'ancre qui permet de relier les tables entre elles, ce que vous verrez dans la leçon sur les jointures.
Pourquoi SQL existe
SQL signifie Structured Query Language : le langage standard pour parler aux bases de données relationnelles. Inventé dans les années 1970, il est encore partout aujourd'hui : MySQL, PostgreSQL, SQLite, SQL Server parlent tous (presque) le même SQL.
Son intérêt : vous décrivez ce que vous voulez, pas comment l'obtenir. « Donne-moi tous les clients de Dijon triés par nom » se traduit directement :
La table clients a quatre colonnes : id, nom, ville, email. Imaginez la requête SELECT nom FROM clients. Avant de dérouler : que renvoie-t-elle exactement, les lignes entières ou seulement quelque chose de précis ? Et qu'est-ce qui changerait avec SELECT * FROM clients ?
Voir la réponse
SELECT nom FROM clients renvoie une seule colonne, nom, avec une valeur par client (toutes les lignes de la table, mais uniquement la colonne demandée) : c'est une projection, on choisit les colonnes. SELECT * FROM clients renvoie toutes les colonnes (id, nom, ville, email). Point clé : SELECT choisit les colonnes (la largeur du résultat), tandis que la clause WHERE choisit les lignes (la hauteur). Les deux sont indépendants.
SELECT nom, email
FROM clients
WHERE ville = 'Dijon'
ORDER BY nom;Le moteur lit votre intention clause par clause :
SELECT nom, email→ quelles colonnes afficherFROM clients→ dans quelle table chercherWHERE ville = 'Dijon'→ quelles lignes garder (le filtre)ORDER BY nom→ dans quel ordre les trier
Retenez la séparation des rôles : SELECT choisit les colonnes, WHERE choisit les lignes. Vous exprimez l'intention, le moteur fait le travail.
Deux réflexes à corriger dès maintenant, sinon ils vous piègeront plus tard :
SQL ne « boucle » pas. Vous ne parcourez pas les lignes une par une comme dans un langage classique : vous décrivez le résultat voulu, et le moteur choisit tout seul comment l'obtenir.
Sans ORDER BY, l'ordre des lignes n'est jamais garanti. Une table n'est pas une liste rangée : si l'ordre compte, vous devez le demander explicitement. C'est la première surprise de ceux qui viennent du tableur, où les lignes ont une position fixe.
SQL vs NoSQL en une ligne : SQL range les données dans des tables strictes et reliées (idéal pour des données structurées et cohérentes), NoSQL stocke des documents souples sans schéma fixe (idéal pour des données très changeantes ou massives).
Les quatre verbes du quotidien
99 % de votre travail en SQL tourne autour de quatre commandes, qu'on résume par l'acronyme CRUD (Create, Read, Update, Delete) :
Ce cours suit cet ordre naturel : d'abord lire (SELECT), puis filtrer, agréger, relier les tables, et enfin modifier et concevoir des bases sécurisées. Tout au long, vous apprendrez à faire écrire ces requêtes par l'IA, et surtout à vérifier ce qu'elle vous renvoie.
The problem: a spreadsheet that explodes
Imagine an online shop. At first, you list your customers in an Excel file: one row per customer, one column for the name, one for the email. It works.
Then orders arrive. You add columns: order 1, order 2, order 3... After a few months, your file has 80 columns, duplicates everywhere, and finding "how much did Marie spend in March" takes ten minutes. The file has become a nightmare.
This is exactly the problem a relational database solves. Instead of one giant file, you split the information into tables linked together, and you ask your questions with a precise language: SQL.
A table is a structured spreadsheet
A table looks like a spreadsheet. Each column has a name and a type (text, number, date). Each row (also called a "record") represents an entity: a customer, an order, a product.
Here is a clients table:
id | nom | email | ville
----+----------------+------------------------+-----------
1 | Marie Dupont | marie@exemple.fr | Besancon
2 | Karim Benali | karim@exemple.fr | Dijon
3 | Lea Martin | lea@exemple.fr | LyonThe id column is the primary key: a unique identifier pointing to a single row, with no ambiguity. Two customers can be named "Marie Dupont", but they will never share the same id.
The primary key is almost always an auto-incremented number (1, 2, 3...). It is the anchor that links tables together, which you will see in the joins lesson.
Why SQL exists
SQL stands for Structured Query Language: the standard language to talk to relational databases. Invented in the 1970s, it is still everywhere today — MySQL, PostgreSQL, SQLite, SQL Server all speak (almost) the same SQL.
Its strength: you describe what you want, not how to get it. "Give me all customers from Dijon sorted by name" translates directly:
The clients table has four columns: id, nom, ville, email. Consider the query SELECT nom FROM clients. Before scrolling: what does it return exactly — full rows, or only something specific? And what would change with SELECT * FROM clients?
See the answer
SELECT nom FROM clients returns a single column, nom, with one value per customer (all rows from the table, but only the requested column): this is a projection — you choose the columns. SELECT * FROM clients returns all columns (id, nom, ville, email). Key point: SELECT picks the columns (the width of the result), while the WHERE clause picks the rows (the height). The two are independent.
SELECT nom, email
FROM clients
WHERE ville = 'Dijon'
ORDER BY nom;The engine reads your intent clause by clause:
SELECT nom, email→ which columns to showFROM clients→ which table to look inWHERE ville = 'Dijon'→ which rows to keep (the filter)ORDER BY nom→ what order to sort them in
Remember the split of roles: SELECT picks the columns, WHERE picks the rows. You express the intent, the engine does the work.
Two reflexes to fix right now, or they will trip you up later:
SQL does not "loop". You don't walk through the rows one by one like in a regular programming language: you describe the result you want, and the engine decides on its own how to get it.
Without ORDER BY, row order is never guaranteed. A table is not an ordered list: if order matters, you must ask for it explicitly. It's the first surprise for people coming from spreadsheets, where rows have a fixed position.
SQL vs NoSQL in one line: SQL stores data in strict, related tables (ideal for structured, consistent data), NoSQL stores flexible documents with no fixed schema (ideal for highly changing or massive data).
The four everyday verbs
99% of your SQL work revolves around four commands, summarized by the acronym CRUD (Create, Read, Update, Delete):
This course follows that natural order: first read (SELECT), then filter, aggregate, link tables, and finally modify and design secure databases. Throughout, you will learn to have the AI write these queries — and above all to verify what it returns.
À vous d'essayer, la base est déjà remplie. Avant de cliquer sur Exécuter, prédisez : quelles lignes vont sortir, et dans quel ordre ? Lancez ensuite et comparez à votre prédiction.
CREATE TABLE clients (id INTEGER, nom TEXT, ville TEXT);
INSERT INTO clients VALUES (1, 'Alice Durand', 'Dijon');
INSERT INTO clients VALUES (2, 'Marc Petit', 'Dijon');
INSERT INTO clients VALUES (3, 'Léa Martin', 'Lyon');
SELECT nom, ville
FROM clients
WHERE ville = 'Dijon'
ORDER BY nom;🎯 Pratique
S'entraîner (clique pour ouvrir) :
✨ Prompt IA
Demandez à l'IA de concevoir un schéma simple, puis vérifiez qu'il a du sens (clés primaires, types, relations) :
Tu es un développeur back-end expérimenté. Je crée une petite boutique en ligne. Propose un schéma de base de données relationnelle avec les tables clients, commandes et produits. Pour chaque table, donne les colonnes, leur type, et indique la clé primaire et les clés étrangères. Explique en une phrase pourquoi tu sépares les données ainsi.
💬 Ré-explique sans regarder
Sans relire le schéma de l'IA : pourquoi vaut-il mieux trois tables clients, commandes et produits reliées plutôt qu'un seul gros tableau qui répète tout ?
clients, pas recopié sur chaque commande) ; on évite les doublons et les incohérences (un seul endroit à corriger si l'email change) ; les tables se relient par une clé étrangère qui pointe vers la id (clé primaire) de l'autre table. Résultat : un fichier qui ne gonfle pas en colonnes et des questions faciles à poser.Décrivez une table produits pour une boutique. Listez au moins une clé primaire (PRIMARY KEY ou id) et trois colonnes avec leur rôle (nom, prix, stock...).
⚖️ Juge le code de l'IA
Vous demandez à l'IA de créer la table clients. Elle vous propose d'utiliser le nom du client comme clé primaire. Votre rôle de relecteur : l'accepter telle quelle ou la rejeter, et dire pourquoi.
CREATE TABLE clients (
nom VARCHAR(100) PRIMARY KEY,
ville VARCHAR(100)
);id auto-incrémentée (id INT PRIMARY KEY AUTO_INCREMENT), sans aucun sens métier, qui ne changera jamais. Le nom redevient une colonne ordinaire.🧠 Rappel libre
Sans remonter dans la leçon : dans une base relationnelle, qu'est-ce qu'une table, et à quoi sert la clé primaire ?
id auto-incrémentée) identifie chaque ligne de façon unique : deux clients peuvent porter le même nom, jamais le même id. C'est l'ancre qui permet de relier les tables.Vous savez maintenant ce qu'est une table et pourquoi SQL existe. Place à la commande reine : SELECT, pour aller chercher dans vos tables exactement les colonnes et les lignes dont vous avez besoin.
Leçon 2 : Sélectionner des données →