🧠 Comment écrire une requête SQL : la méthode pas à pas · Modai Lab

Guide pratique · De la question à la requête propre · Lecture : ~15 min
Teste ton niveau sur modai-lab.com/test-sql/

Pourquoi ce guide existe

La plupart des gens ouvrent un éditeur SQL et commencent à taper des SELECT. Résultat : une requête qui tourne peut-être, mais que personne ne comprend, parfois pas même celui qui l'a écrite.

Écrire une bonne requête SQL, ça ne commence pas avec le clavier. Ça commence avec la tête.

Ce guide te donne la méthode complète : par quoi commencer, dans quel ordre réfléchir, et comment valider que le résultat est juste avant de le livrer.

🧪 Calibre ton niveau avant de commencer

Sais-tu déjà dans quel ordre SQL exécute les clauses que tu écris ? Fais le test en 5 minutes.

👉 Faire le test sur modai-lab.com/test-sql/

Résultat en direct · Niveau calibré · Parcours personnalisé

ÉTAPE 0 : Comprendre la question avant de toucher au clavier

C'est l'étape que presque tout le monde saute. Et c'est la source de 80% des requêtes fausses.

Les 4 questions à se poser en premier

1. Quel est concrètement le résultat attendu ?

Pas "les ventes par région". Mais :

Une ligne par région, ou une ligne par région par mois ?
Avec les régions sans ventes (CA = 0) ou seulement celles qui ont vendu ?
Sur quelle période ?
Triées comment ?

Décris le résultat attendu comme si tu expliquais à quelqu'un ce qui devrait apparaître dans le tableau.

Exemple de question floue :

"Donne-moi les ventes par région"

Exemple de question précise :

"Une ligne par région ayant vendu, le CA total des commandes livrées en 2024,

plus une ligne « Non renseignée » pour les clients sans région,

triées du CA le plus élevé au plus bas"

methode-ecrire-requete-sql · 01

2. Quelles tables contiennent les données nécessaires ?

Avant d'écrire une jointure, identifie d'où vient chaque information :

CA total → orders.montant

Région → regions.nom via users.region_id (ou l'adresse de livraison ?)

Statut → orders.statut

Période → orders.created_at

methode-ecrire-requete-sql · 02

Si une information est dans deux tables différentes, quelle est la clé qui les relie ?

3. Quelle est la granularité attendue ?

C'est la question la plus souvent oubliée. La granularité = le niveau de détail d'une ligne dans le résultat.

Une ligne par... → commande ? user ? jour ? région ? produit ?

methode-ecrire-requete-sql · 03

La granularité détermine :

Le GROUP BY que tu vas utiliser
Si tu as besoin d'une window function ou d'une agrégation
Si un fan-out de JOIN est possible

4. Y a-t-il des cas limites à gérer ?

Des NULL dans les colonnes clés ?

Des utilisateurs sans commande (LEFT JOIN vs INNER JOIN) ?

Des doublons possibles dans une des tables ?

Des timezones différentes dans les timestamps ?

methode-ecrire-requete-sql · 04 · 4. Y a-t-il des cas limites à gérer ?

ÉTAPE 1 : Identifier les tables et les relations

Avant d'écrire quoi que ce soit, dessine mentalement (ou sur papier) le chemin entre les tables.

Le schéma d'exploration en 3 colonnes

Table source Colonne de jointure Table cible

orders → orders.user_id → users.id

orders → orders.product_id → products.id

users → users.region_id → regions.id

methode-ecrire-requete-sql · 05

Questions à se poser pour chaque jointure :

1. Quelle est la cardinalité ? (1:1, 1:N, N:M)

→ Un user peut avoir N commandes (1:N)

→ Une commande peut avoir N lignes (1:N)

2. Est-ce que chaque ligne de la table de gauche a forcément une correspondance à droite ?

→ OUI → INNER JOIN (risque de perdre des lignes si la correspondance manque)

→ NON → LEFT JOIN (garder les lignes sans correspondance)

3. Est-ce que la jointure peut créer des doublons (fan-out) ?

→ Si oui : agréger avant de joindre

methode-ecrire-requete-sql · 06 · Questions à se poser pour chaque jointure :

Le test de granularité avant d'écrire les JOINs

-- Avant d'écrire la requête complète, vérifier que les clés de jointure

-- ne créent pas de doublons

-- Est-ce que id est unique dans products ?

SELECT id, COUNT(*) FROM products GROUP BY id HAVING COUNT(*) > ;

-- Si résultat vide → une commande matche au plus un produit → pas de fan-out

-- Est-ce qu'un user peut avoir plusieurs lignes dans user_tags ?

SELECT user_id, COUNT(*) FROM user_tags GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT ;

-- Si un COUNT(*) dépasse 1 → joindre user_tags sur user_id multiplie les lignes (fan-out)

methode-ecrire-requete-sql · 07

ÉTAPE 2 : Écrire dans le bon ordre

L'ordre dans lequel tu écris une requête SQL n'est pas l'ordre dans lequel tu penses.

L'ordre de réflexion recommandé

1. FROM (+ JOINs) → Quelles tables ? Quelles relations ?

2. WHERE → Quels filtres sur les données brutes ?

3. GROUP BY → Quelle granularité dans le résultat ?

4. HAVING → Quels filtres sur les agrégats ?

5. SELECT → Quelles colonnes et calculs dans le résultat ?

6. ORDER BY → Dans quel ordre afficher ?

7. LIMIT → Combien de lignes ?

methode-ecrire-requete-sql · 08

Pourquoi cet ordre ?

Parce que c'est l'ordre dans lequel SQL exécute les clauses. Si tu commences par le SELECT, tu réfléchis à l'envers du moteur, et tu crées des bugs que tu ne comprends pas.

Ordre d'exécution SQL (pas l'ordre d'écriture) :

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

methode-ecrire-requete-sql · 09

La méthode de rédaction étape par étape

Commencer par FROM : définir le périmètre

-- Étape 1 : juste les tables et les jointures

FROM orders o

LEFT JOIN users u ON o.user_id = u.id

LEFT JOIN regions r ON u.region_id = r.id

-- Pas encore de SELECT, pas encore de WHERE

methode-ecrire-requete-sql · 10 · Commencer par FROM : définir le périmètre

Ajouter WHERE : filtrer les données brutes

-- Étape 2 : filtres sur colonnes brutes uniquement

FROM orders o

LEFT JOIN users u ON o.user_id = u.id

LEFT JOIN regions r ON u.region_id = r.id

WHERE o.created_at >= '2024-01-01'

AND o.created_at < '2025-01-01'

AND o.statut = 'livré'

-- Attention : si WHERE est sur une colonne de la table de droite d'un LEFT JOIN

-- → ça transforme le LEFT JOIN en INNER JOIN → déplacer dans le ON si nécessaire

methode-ecrire-requete-sql · 11 · Ajouter WHERE : filtrer les données brutes

Ajouter GROUP BY : définir la granularité

-- Étape 3 : définir ce qui constitue "une ligne" dans le résultat

FROM orders o

LEFT JOIN users u ON o.user_id = u.id

LEFT JOIN regions r ON u.region_id = r.id

WHERE o.created_at >= '2024-01-01'

AND o.created_at < '2025-01-01'

AND o.statut = 'livré'

GROUP BY r.nom

-- Une ligne par région

methode-ecrire-requete-sql · 12 · Ajouter GROUP BY : définir la granularité

Ajouter HAVING si nécessaire

-- Étape 4 : filtres sur les agrégats (jamais sur les colonnes brutes)

HAVING SUM(o.montant) >

-- ou COUNT(DISTINCT o.id) > 100

methode-ecrire-requete-sql · 13 · Ajouter HAVING si nécessaire

Écrire le SELECT, maintenant seulement

-- Étape 5 : maintenant qu'on sait ce qu'est une ligne, on peut choisir les colonnes

SELECT

COALESCE(r.nom, 'Non renseignée') AS region,

COUNT(DISTINCT o.id) AS nb_commandes,

COUNT(DISTINCT o.user_id) AS nb_clients,

SUM(o.montant) AS ca_total,

ROUND(AVG(o.montant), ) AS panier_moyen

FROM orders o

LEFT JOIN users u ON o.user_id = u.id

LEFT JOIN regions r ON u.region_id = r.id

WHERE o.created_at >= '2024-01-01'

AND o.created_at < '2025-01-01'

AND o.statut = 'livré'

GROUP BY r.nom

methode-ecrire-requete-sql · 14 · Écrire le SELECT, maintenant seulement

Finir avec ORDER BY et LIMIT

-- Étape 6 : tri et limite

ORDER BY ca_total DESC

LIMIT ;

methode-ecrire-requete-sql · 15 · Finir avec ORDER BY et LIMIT

🧪 Pratique la méthode étape par étape sur Modai Lab

Chaque exercice Modai Lab te force à décomposer la requête avant de l'écrire. Le feedback identifie exactement quelle étape a été brûlée.

👉 Pratiquer sur modai-lab.com

Exercices progressifs · Feedback sur chaque clause · Parcours personnalisé

ÉTAPE 3 : Les vérifications avant de valider

Une requête qui "tourne" n'est pas forcément une requête correcte. Voici les 5 vérifications systématiques.

Vérification 1 : La granularité est-elle correcte ?

-- Avant d'agréger : une commande doit rester une seule ligne après les JOINs

SELECT

COUNT(*) AS lignes_apres_joins,

COUNT(DISTINCT o.id) AS commandes_distinctes

FROM orders o

LEFT JOIN users u ON o.user_id = u.id

LEFT JOIN regions r ON u.region_id = r.id

WHERE o.created_at >= '2024-01-01'

AND o.created_at < '2025-01-01'

AND o.statut = 'livré';

-- Si lignes_apres_joins > commandes_distinctes → fan-out → les SUM seront gonflées

methode-ecrire-requete-sql · 16

Vérification 2 : Les NULL sont-ils gérés ?

-- Identifier les colonnes avec NULL dans le résultat

SELECT *

FROM mon_rapport_par_region

WHERE region IS NULL

OR ca_total IS NULL;

-- Est-ce attendu ou est-ce un problème de jointure ?

methode-ecrire-requete-sql · 17

Vérification 3 : Le LEFT JOIN n'est-il pas devenu un INNER JOIN ?

-- Vérifier combien de lignes de la table principale n'ont pas de correspondance

SELECT COUNT(*) AS total FROM orders;

SELECT COUNT(*) AS apres_left_join

FROM orders o

LEFT JOIN users u ON o.user_id = u.id

WHERE u.region_id IS NOT NULL; -- ← ce filtre élimine les lignes sans correspondance

-- Si total > apres_left_join → des commandes sont perdues

-- → déplacer le filtre dans le ON ou utiliser INNER JOIN intentionnellement

methode-ecrire-requete-sql · 18

Vérification 4 : Le résultat est-il cohérent avec un cas connu ?

-- Prendre un cas simple qu'on peut calculer à la main

-- Ex : vérifier le CA pour une région spécifique

SELECT SUM(montant)

FROM orders o

JOIN users u ON o.user_id = u.id

JOIN regions r ON u.region_id = r.id

WHERE r.nom = 'Île-de-France'

AND o.statut = 'livré'

AND o.created_at >= '2024-01-01'

AND o.created_at < '2025-01-01';

-- Comparer avec la ligne "Île-de-France" dans le rapport

-- Si les deux chiffres ne sont pas identiques → une condition filtre des données inattendues

methode-ecrire-requete-sql · 19

Vérification 5 : Les totaux sont-ils cohérents ?

-- Le total de la requête agrégée doit correspondre au total brut

-- Total brut de référence, avec exactement les mêmes filtres que le rapport

SELECT SUM(montant)

FROM orders

WHERE statut = 'livré'

AND created_at >= '2024-01-01'

AND created_at < '2025-01-01';

-- Total du rapport

SELECT SUM(ca_total) FROM mon_rapport_par_region;

-- Si les deux ne sont pas égaux → chercher où des lignes sont perdues ou comptées deux fois

methode-ecrire-requete-sql · 20

ÉTAPE 4 : Structurer pour la lisibilité

Une requête correcte mais illisible sera réécrite par quelqu'un d'autre dans 6 mois. Autant la rendre maintenable.

Règles de lisibilité

Nommer les alias de façon explicite

-- ❌ Alias cryptiques

SELECT u.n, o.m, COUNT(*)

FROM users u JOIN orders o ON u.i = o.ui;

-- ✅ Alias qui disent ce qu'ils font

SELECT

u.nom AS client,

o.montant AS montant_commande,

COUNT(*) AS nb_lignes

FROM users u

JOIN orders o ON u.id = o.user_id;

methode-ecrire-requete-sql · 21 · Nommer les alias de façon explicite

Documenter l'intention métier

-- Rapport CA par région : commandes livrées 2024

-- Les clients sans région sont regroupés sous 'Non renseignée'

-- Granularité : une ligne par région

SELECT

COALESCE(r.nom, 'Non renseignée') AS region,

SUM(o.montant) AS ca_total

FROM orders o

-- LEFT JOIN : une commande reste comptée même si son client est introuvable

LEFT JOIN users u ON o.user_id = u.id

-- LEFT JOIN : un client sans région reste compté (→ 'Non renseignée')

LEFT JOIN regions r ON u.region_id = r.id

WHERE o.created_at >= '2024-01-01' -- 2024 uniquement

AND o.created_at < '2025-01-01'

AND o.statut = 'livré' -- commandes livrées uniquement

GROUP BY r.nom

ORDER BY ca_total DESC;

methode-ecrire-requete-sql · 22 · Documenter l'intention métier

Décomposer avec des CTEs pour les requêtes complexes

-- ✅ Chaque CTE a une seule responsabilité

WITH

-- 1. Filtrer les commandes du périmètre

commandes_2024 AS (

SELECT id AS order_id, user_id, montant

FROM orders

WHERE created_at >= '2024-01-01'

AND created_at < '2025-01-01'

AND statut = 'livré'

-- 2. Enrichir avec la région du client

commandes_avec_region AS (

SELECT c.order_id, c.montant, COALESCE(r.nom, 'Non renseignée') AS region

FROM commandes_2024 c

LEFT JOIN users u ON c.user_id = u.id

LEFT JOIN regions r ON u.region_id = r.id

)

-- 3. Agréger par région

SELECT

region,

COUNT(*) AS nb_commandes,

SUM(montant) AS ca_total

FROM commandes_avec_region

GROUP BY region

ORDER BY ca_total DESC;

methode-ecrire-requete-sql · 23 · Décomposer avec des CTEs pour les requêtes complexes

La règle des 30 secondes

Une requête est bien écrite si quelqu'un qui ne l'a pas écrite peut comprendre ce qu'elle fait en moins de 30 secondes.

Si ce n'est pas le cas : ajouter des commentaires, décomposer en CTEs, renommer les alias.

ÉTAPE 5 : La checklist complète avant de livrer

AVANT D'ÉCRIRE :

□ Je sais exactement à quoi ressemble le résultat attendu

□ J'ai identifié toutes les tables nécessaires et leurs relations

□ J'ai défini la granularité attendue (une ligne par quoi ?)

□ J'ai identifié les cas limites (NULL, doublons, lignes sans correspondance)

EN ÉCRIVANT :

□ J'ai commencé par FROM et les JOINs, pas par le SELECT

□ Mes filtres sur données brutes sont dans WHERE, pas dans HAVING

□ Mes filtres sur agrégats sont dans HAVING, pas dans WHERE

□ Si LEFT JOIN : les filtres sur la table de droite sont dans le ON

□ Je n'ai pas utilisé SELECT * (colonnes explicites uniquement)

EN VALIDANT :

□ Le nombre de lignes correspond à la granularité attendue

□ COUNT(*) = COUNT(DISTINCT id) (pas de fan-out)

□ Les NULL sont traités intentionnellement

□ Le total du rapport = le total de la table brute

□ J'ai testé sur un sous-ensemble connu pour vérifier un cas concret

EN LIVRANT :

□ Les alias sont explicites et lisibles

□ Les commentaires expliquent l'intention métier, pas la syntaxe

□ Les requêtes complexes sont décomposées en CTEs nommées

□ Quelqu'un d'autre peut lire et modifier cette requête sans moi

methode-ecrire-requete-sql · 28

Récapitulatif : Les 6 étapes en une page

Étape	Ce qu'on fait	Questions clés
0 · Comprendre	Décrire le résultat attendu	Quelle granularité ? Quels cas limites ?
1 · Cartographier	Identifier tables et relations	Quelle clé relie quelles tables ? LEFT ou INNER ? Fan-out ?
2 · Écrire	FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY	Dans cet ordre, pas l'inverse
3 · Vérifier	Granularité, NULL, totaux, cohérence	Le total du rapport = le total brut ?
4 · Structurer	Alias, commentaires, CTEs	La règle des 30 secondes
5 · Livrer	Dérouler la checklist complète	Quelqu'un d'autre peut-il reprendre la requête sans moi ?

Prompt IA pour auditer tes requêtes

Audite cette requête SQL :

[coller la requête]

Vérifie :

1. La granularité est-elle clairement définie ? Y a-t-il un risque de fan-out ?

2. Les filtres sont-ils correctement placés dans WHERE (données brutes) ou HAVING (agrégats) ?

3. Les LEFT JOINs sont-ils transformés en INNER JOIN par un WHERE sur la table de droite ?

4. Y a-t-il des cas NULL non gérés ?

5. Le SELECT liste-t-il explicitement les colonnes (pas SELECT *) ?

6. La requête passerait-elle le test des 30 secondes ? Sinon, comment la restructurer en CTEs ?

Pour chaque problème trouvé : montrer la version corrigée avec une explication d'une phrase.

methode-ecrire-requete-sql · 29

PARTIE BONUS : Les erreurs de débutants les plus fréquentes

Erreur 1 : Filtrer dans HAVING ce qui devrait être dans WHERE

-- ❌ Filtre sur une donnée brute dans HAVING

SELECT user_id, SUM(montant) AS ca

FROM orders

GROUP BY user_id

HAVING statut = 'livré';

-- ERROR: column "orders.statut" must appear in the GROUP BY clause

-- or be used in an aggregate function

-- HAVING travaille sur des groupes : statut n'existe plus à ce stade.

-- Ajouter statut au GROUP BY fait passer la requête mais masque l'intention :

-- c'est un filtre de lignes, sa place est dans WHERE.

-- ✅ Filtre dans WHERE → les lignes sont filtrées avant l'agrégation

SELECT user_id, SUM(montant) AS ca

FROM orders

WHERE statut = 'livré'

GROUP BY user_id;

methode-ecrire-requete-sql · 24

Erreur 2 : SELECT * avec des JOINs

-- ❌ SELECT * avec plusieurs tables → colonnes en double, ambiguïté, données inutiles

SELECT *

FROM orders o

JOIN users u ON o.user_id = u.id;

-- Résultat : colonnes "id" de orders ET de users → laquelle utiliser ?

-- ✅ Nommer explicitement les colonnes nécessaires

SELECT

o.id AS order_id,

o.montant,

o.created_at,

u.nom AS client,

u.email

FROM orders o

JOIN users u ON o.user_id = u.id;

methode-ecrire-requete-sql · 25

Erreur 3 : Oublier que COUNT(*) et COUNT(colonne) ne sont pas équivalents

-- COUNT(*) → compte toutes les lignes, y compris celles avec NULL

-- COUNT(col) → compte uniquement les lignes où col n'est pas NULL

SELECT

COUNT(*) AS total_commandes, -- toutes les lignes

COUNT(promo_code) AS avec_promo, -- uniquement les commandes avec un code promo

COUNT(*) - COUNT(promo_code) AS sans_promo -- commandes sans code promo

FROM orders;

methode-ecrire-requete-sql · 26

Erreur 4 : Joindre sur une colonne non indexée

-- ❌ Jointure sur une colonne libre → scan complet de la table à chaque ligne

SELECT * FROM orders o

JOIN users u ON o.email_client = u.email; -- email non indexé

-- ✅ Toujours joindre sur des clés primaires ou des colonnes indexées

SELECT * FROM orders o

JOIN users u ON o.user_id = u.id; -- id est la clé primaire → index automatique

-- Si la jointure sur email est indispensable : CREATE INDEX idx_users_email ON users(email);

methode-ecrire-requete-sql · 27

🚀 Pratiquer la méthode sur Modai Lab

Cette méthode ne s'ancre pas en la lisant une fois. Elle s'ancre en l'appliquant sur des cas réels, avec du feedback immédiat à chaque étape.

Modai Lab est construit autour de cette approche : chaque exercice te force à réfléchir avant d'écrire, et le feedback indique exactement quelle étape a été brûlée.

👉 modai-lab.com/test-sql/ · Exercices calibrés · Cas business réels · Feedback senior

Pourquoi ce guide existe

🧪 Calibre ton niveau avant de commencer

ÉTAPE 0 : Comprendre la question avant de toucher au clavier

Les 4 questions à se poser en premier

ÉTAPE 1 : Identifier les tables et les relations

Le schéma d'exploration en 3 colonnes

Le test de granularité avant d'écrire les JOINs

ÉTAPE 2 : Écrire dans le bon ordre

L'ordre de réflexion recommandé

La méthode de rédaction étape par étape

🧪 Pratique la méthode étape par étape sur Modai Lab

ÉTAPE 3 : Les vérifications avant de valider

Vérification 1 : La granularité est-elle correcte ?

Vérification 2 : Les NULL sont-ils gérés ?

Vérification 3 : Le LEFT JOIN n'est-il pas devenu un INNER JOIN ?

Vérification 4 : Le résultat est-il cohérent avec un cas connu ?

Vérification 5 : Les totaux sont-ils cohérents ?

ÉTAPE 4 : Structurer pour la lisibilité

Règles de lisibilité

La règle des 30 secondes

ÉTAPE 5 : La checklist complète avant de livrer

Récapitulatif : Les 6 étapes en une page

Prompt IA pour auditer tes requêtes

PARTIE BONUS : Les erreurs de débutants les plus fréquentes

Erreur 1 : Filtrer dans HAVING ce qui devrait être dans WHERE

Erreur 2 : SELECT * avec des JOINs

Erreur 3 : Oublier que COUNT(*) et COUNT(colonne) ne sont pas équivalents

Erreur 4 : Joindre sur une colonne non indexée

🚀 Pratiquer la méthode sur Modai Lab

La théorie c’est bien. La pratique sur des cas concrets, c’est mieux.