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 :
SELECT nom, email
FROM clients
WHERE ville = 'Dijon'
ORDER BY nom;Pas de boucle, pas de tri manuel. Vous exprimez l'intention, le moteur fait le travail.
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:
SELECT nom, email
FROM clients
WHERE ville = 'Dijon'
ORDER BY nom;No loop, no manual sorting. You express the intent, the engine does the work.
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 :
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;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.
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...).
Vous demandez à l'IA de supprimer le client n°3. Elle vous renvoie cette requête. Votre rôle de relecteur : l'accepter telle quelle ou la rejeter, et dire pourquoi.
DELETE FROM clients;DELETE FROM clients; n'a pas de WHERE : elle ne supprime pas le client n°3, elle vide TOUTE la table clients. C'est l'accident SQL classique. La requête correcte cible une seule ligne par sa clé primaire : DELETE FROM clients WHERE id = 3;. Réflexe pro : avant tout DELETE ou UPDATE, vérifier qu'un WHERE précis est présent, et le tester d'abord avec un SELECT.Sans remonter dans la leçon : en 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.You now know what a table is and why SQL exists. Time for the star command: SELECT, to pull from your tables exactly the columns and rows you need.
Lesson 2: Selecting data →