6 jointures SQL à connaître (avec des exemples simples et clairs)

Ce que sont les JOIN SQL et pourquoi on les utilise

Un JOIN SQL vous permet de combiner des lignes de deux (ou plusieurs) tables en un seul résultat en les faisant correspondre sur une colonne liée — généralement un identifiant.

Pourquoi les JOINs sont importants

La plupart des bases de données réelles sont volontairement réparties en tables séparées pour éviter la répétition d’informations. Par exemple, le nom d’un client se trouve dans une table customers, tandis que ses achats se trouvent dans une table orders. Les JOINs servent à reconnecter ces pièces lorsque vous avez besoin de réponses.

C’est pourquoi les JOINs apparaissent partout dans le reporting et l’analyse :

• Construire un rapport de ventes incluant le nom du client, le total de la commande et le statut du paiement
• Trouver les clients qui n’ont encore rien commandé
• Auditer les incohérences, comme des commandes sans paiements
• Créer des récapitulatifs “une ligne par client” à partir de plusieurs lignes reliées

Sans JOINs, vous seriez obligé d’exécuter des requêtes séparées puis de combiner manuellement les résultats — lent, sujet aux erreurs et difficile à reproduire.

Si vous développez des produits sur une base de données relationnelle (dashboards, panneaux d’administration, outils internes, portails clients), les JOINs transforment aussi les « tables brutes » en vues destinées aux utilisateurs. Des plateformes comme Koder.ai (qui génère des apps React + Go + PostgreSQL depuis un chat) s’appuient toujours sur des notions solides de JOIN quand il faut des pages de liste, des rapports ou des écrans de réconciliation précis — la logique base de données ne disparaît pas, même quand le développement s’accélère.

Les 6 types de JOIN que vous utiliserez le plus

Ce guide se concentre sur six JOINs qui couvrent la majorité du travail SQL quotidien :

• INNER JOIN : retourne seulement les lignes qui correspondent dans les deux tables (idéal pour « montrer les relations confirmées »).
• LEFT JOIN : conserve toutes les lignes de la table de gauche, et récupère ce qu’il peut de la table de droite (utile pour « inclure les données liées manquantes »).

Petite note sur la syntaxe

La syntaxe des JOIN est très similaire entre la plupart des bases SQL (PostgreSQL, MySQL, SQL Server, SQLite). Il existe quelques différences — surtout autour du support de FULL OUTER JOIN et certains comportements de coin — mais les concepts et les motifs de base se transposent bien.

Les tables d’exemple que nous utiliserons (customers, orders, payments)

Pour garder les exemples clairs, nous utiliserons trois petites tables qui reflètent une configuration courante : des clients passent des commandes, et les commandes peuvent (ou non) avoir des paiements.

Une petite précision avant de commencer : les tables d’exemple ci‑dessous n’affichent que quelques colonnes, mais certaines requêtes plus loin référencent des champs additionnels (comme order_date, created_at, status ou paid_at) pour montrer des motifs communs. Considérez ces colonnes comme des champs « typiques » que l’on trouve en production.

1) customers

Clé primaire : customer_id

2) orders

Clé primaire : order_id
Clé étrangère : customer_id → customers.customer_id

Remarquez que order_id = 104 référence customer_id = 5, qui n’existe pas dans customers. Cette « correspondance manquante » est utile pour voir comment se comportent LEFT JOIN, RIGHT JOIN et FULL OUTER JOIN.

3) payments

Clé primaire : payment_id
Clé étrangère : order_id → orders.order_id

Deux détails pédagogiques importants :

• order_id = 102 a deux lignes de paiement (paiement fractionné). Quand vous joignez orders à payments, cette commande apparaîtra deux fois — c’est souvent là que les doublons surprennent.
• payment_id = 9004 référence order_id = 999, qui n’existe pas dans . Cela crée un autre cas « non apparié ».

À quoi s’attendre quand on JOINe ces tables

• Lignes appariées : par ex. client 1 ↔ commandes 101/102 ; commande 101 ↔ paiement 9001.
• Lignes non appariées : par ex. client 3 et 4 n’ont pas de commandes ; commande 104 n’a pas de client ; paiement 9004 n’a pas de commande.
• Doublons : joindre orders à payments répétera la commande 102 parce qu’elle a deux paiements.

INNER JOIN : ne conserver que les lignes appariées

Un INNER JOIN retourne seulement les lignes où il y a une correspondance dans les deux tables. Si un client n’a pas de commandes, il n’apparaîtra pas. Si une commande référence un client inexistant (données erronées), cette commande n’apparaîtra pas non plus.

Le modèle de base

Vous choisissez une table « gauche », vous joignez une table « droite » et vous les reliez avec une condition dans la clause ON.

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id;

L’idée clé est la ligne ON o.customer_id = c.customer_id : elle indique à SQL comment les lignes se correspondent.

Cas d’usage réel : clients ayant passé des commandes

Si vous voulez la liste uniquement des clients qui ont effectivement passé au moins une commande (et les détails des commandes), INNER JOIN est le choix naturel :

SELECT
  c.name,
  o.order_id,
  o.total_amount
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY o.order_id;

C’est utile pour des actions comme « envoyer un e‑mail de suivi de commande » ou « calculer le chiffre d’affaires par client » (lorsque vous ne vous intéressez qu’aux clients ayant acheté).

Erreur fréquente : condition de jointure manquante ou ambiguë

Si vous écrivez une jointure mais oubliez la condition ON (ou joignez sur les mauvaises colonnes), vous pouvez créer accidentellement un produit cartésien (chaque client combiné à chaque commande) ou obtenir des correspondances fausses de façon subtile.

Mauvais (à ne pas faire) :

SELECT c.name, o.order_id
FROM customers c
JOIN orders o;

Assurez‑vous toujours d’avoir une condition de jointure claire dans ON (ou USING dans les cas où cela s’applique — couvert plus loin).

LEFT JOIN : conserver tout depuis la table de gauche

Un LEFT JOIN retourne toutes les lignes de la table de gauche, et ajoute les données correspondantes de la table de droite lorsqu’il y a une correspondance. S’il n’y a pas de correspondance, les colonnes de la droite deviennent NULL.

Quand l’utiliser

Utilisez LEFT JOIN lorsque vous voulez une liste complète depuis votre table principale, plus les données liées en option.

Exemple : « Montrez‑moi tous les clients, et incluez leurs commandes si elles existent. »

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY c.customer_id;

• Les clients ayant des commandes apparaissent avec les détails de leurs commandes.
• Les clients sans commandes apparaissent toujours, mais o.order_id (et les autres colonnes orders) vaudront NULL.

Trouver les lignes « sans correspondance » (le motif classique)

Une raison très courante d’utiliser LEFT JOIN est de trouver des éléments qui n’ont pas d’enregistrements liés.

Exemple : « Quels clients n’ont jamais passé de commande ? »

SELECT
  c.customer_id,
  c.name
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.order_id IS NULL;

Cette condition WHERE ... IS NULL ne garde que les lignes de la table de gauche pour lesquelles la jointure n’a pas trouvé de correspondance.

Attention : les correspondances multiples multiplient les lignes

Un LEFT JOIN peut « dupliquer » les lignes de la table gauche quand il y a plusieurs lignes correspondantes à droite.

Si un client a 3 commandes, ce client apparaitra 3 fois — une fois par commande. C’est attendu, mais cela surprend souvent quand on veut compter des clients.

Par exemple, ceci compte des commandes (pas des clients) :

SELECT COUNT(*)
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id;

Si votre but est de compter des clients, vous compterez typiquement la clé client (COUNT(DISTINCT c.customer_id)), selon ce que vous mesurez.

RIGHT JOIN : conserver tout depuis la table de droite

Un RIGHT JOIN conserve toutes les lignes de la table de droite, et seulement les lignes correspondantes de la table de gauche. S’il n’y a pas de correspondance, les colonnes de la table de gauche seront NULL. C’est l’image miroir d’un LEFT JOIN.

Exemple simple

Avec nos tables d’exemple, imaginez que vous souhaitiez lister tous les paiements, même s’ils ne peuvent pas être rattachés à une commande (peut‑être que la commande a été supprimée ou que les données de paiement sont désordonnées).

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM orders o
RIGHT JOIN payments p
  ON o.order_id = p.order_id;

Ce que vous obtenez :

• Tous les paiements sont inclus (car payments est à droite).
• Si un paiement n’a pas de commande correspondante, alors o.order_id et o.customer_id seront NULL.

La même requête en LEFT JOIN (souvent préférée)

La plupart du temps, vous pouvez réécrire un RIGHT JOIN comme un LEFT JOIN en inversant l’ordre des tables :

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM payments p
LEFT JOIN orders o
  ON o.order_id = p.order_id;

Cela renvoie le même résultat, mais beaucoup trouvent plus lisible de démarrer par la table « principale » (ici payments) puis d’y joindre les données optionnelles.

Lisibilité : pourquoi beaucoup d’équipes évitent RIGHT JOIN

Beaucoup de guides de style SQL déconseillent RIGHT JOIN car il oblige le lecteur à inverser mentalement le schéma habituel :

• « Commencez par la table principale »
• « LEFT JOIN des tables additionnelles »

Quand les relations optionnelles sont systématiquement écrites en LEFT JOIN, les requêtes sont plus faciles à parcourir.

Quand RIGHT JOIN peut rester pratique

Un RIGHT JOIN peut être pratique quand vous éditez une requête existante et que vous réalisez que la table « à conserver » se trouve à droite. Au lieu de réécrire toute la requête (surtout si elle est longue avec plusieurs jointures), changer une jointure en RIGHT JOIN peut être un ajustement rapide et sûr.

FULL OUTER JOIN : conserver toutes les lignes des deux tables

Un FULL OUTER JOIN renvoie toutes les lignes des deux tables.

• Si une ligne match sur la clé de jointure, vous obtenez une ligne combinée unique (comme INNER JOIN).
• Si une ligne existe seulement dans la table de gauche, elle apparaît quand même — avec des NULL pour les colonnes de droite.
• Si une ligne existe seulement dans la table de droite, elle apparaît aussi — avec des NULL pour les colonnes de gauche.

Quand c’est utile

Un cas classique est la réconciliation commandes vs paiements :

• Vous voulez voir les commandes payées (correspondances)
• les commandes impayées (commande existante, paiement manquant)
• les paiements isolés (paiement existant mais pas de commande — erreur de données, remboursement, mauvaise référence, etc.)

Exemple :

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount
FROM orders o
FULL OUTER JOIN payments p
  ON p.order_id = o.order_id;

Support par les bases (qui peuvent l’exécuter directement)

FULL OUTER JOIN est supporté dans PostgreSQL, SQL Server et Oracle`.

Il n’est pas disponible dans MySQL et SQLite (vous aurez besoin d’un contournement).

Alternative portable : UNION d’un LEFT JOIN et d’un RIGHT JOIN

Si votre base ne supporte pas FULL OUTER JOIN, vous pouvez le simuler en combinant :

1. toutes les lignes de orders (avec les paiements correspondants quand disponible), et
2. toutes les lignes de payments qui n’ont pas correspondu à une commande.

Un motif courant :

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
LEFT JOIN payments p
  ON p.order_id = o.order_id

UNION

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
RIGHT JOIN payments p
  ON p.order_id = o.order_id;

Astuce : quand vous voyez des NULL d’un côté, c’est le signal que la ligne manquait dans l’autre table — exactement ce qu’on recherche pour les audits et la réconciliation.

CROSS JOIN : créer toutes les combinaisons (à utiliser avec prudence)

Un CROSS JOIN renvoie toutes les paires possibles de lignes de deux tables. Si la table A a 3 lignes et la table B 4 lignes, le résultat aura 3 × 4 = 12 lignes. On appelle cela un produit cartésien.

Ça fait peur — et ça peut être dangereux — mais c’est utile lorsque vous souhaitez générer des combinaisons.

Un petit exemple sûr : tailles × couleurs (création de SKUs)

Imaginez que vous maintenez des options produit dans des tables séparées :

• sizes : S, M, L
• colors : Red, Blue

Un CROSS JOIN peut générer toutes les variantes possibles (utile pour créer des SKUs, préconstruire un catalogue ou tester) :

SELECT
  s.size,
  c.color
FROM sizes AS s
CROSS JOIN colors AS c;

Résultat (3 × 2 = 6 lignes) :

• S / Red
• S / Blue
• M / Red
• M / Blue
• L / Red
• L / Blue

Avertissement : la taille des résultats augmente vite

Parce que les nombres de lignes se multiplient, CROSS JOIN peut exploser très rapidement :

• 10 000 clients × 50 produits = 500 000 lignes
• 100 000 × 100 000 = 10 000 000 000 lignes

Cela peut ralentir les requêtes, saturer la mémoire et produire une sortie inutilisable. Si vous avez besoin de combinaisons, gardez les tables d’entrée petites et envisagez d’ajouter des limites ou des filtres maîtrisés.

SELF JOIN : joindre une table à elle‑même

Une SELF JOIN est exactement ce que son nom indique : vous joignez une table à elle‑même. C’est utile lorsqu’une ligne dans une table est liée à une autre ligne de la même table — le plus souvent pour des relations parent/enfant comme employés et leurs managers.

Pourquoi les alias sont nécessaires (et comment ils aident)

Comme vous utilisez la même table deux fois, vous devez attribuer à chaque « copie » un alias différent. Les alias rendent la requête lisible et indiquent à SQL de quel côté vous parlez.

Un schéma courant est :

• e pour l’employé
• m pour le manager

Exemple pratique : employés et leurs managers

Imaginez une table employees comme ceci :

• id
• name
• manager_id (pointe vers l’id d’un autre employé)

Pour lister chaque employé avec le nom de son manager :

SELECT
  e.id,
  e.name AS employee_name,
  m.name AS manager_name
FROM employees e
LEFT JOIN employees m
  ON e.manager_id = m.id;

Gérer les employés de premier niveau (manager_id NULL)

Remarquez que la requête utilise LEFT JOIN, pas INNER JOIN. Cela a de l’importance car certains employés n’ont peut‑être pas de manager (par ex. le CEO). Dans ces cas, manager_id est souvent NULL, et un LEFT JOIN conserve la ligne employé tout en affichant manager_name comme NULL.

Si vous utilisiez un INNER JOIN, ces employés de premier niveau disparaîtraient du résultat car il n’y a pas de ligne manager correspondante.

Conditions de jointure : ON vs USING (et pourquoi ça compte)

Un JOIN ne sait pas « magiquement » comment deux tables sont liées — vous devez le lui indiquer. Cette relation se définit dans la condition de jointure, et elle appartient juste à côté du JOIN parce qu’elle explique comment les tables s’apparentent, pas comment vous voulez filtrer le résultat final.

ON : le plus flexible (et le plus courant)

Utilisez ON lorsque vous voulez un contrôle total sur la logique de correspondance — noms de colonnes différents, conditions multiples ou règles supplémentaires.

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.created_at
FROM customers AS c
INNER JOIN orders AS o
  ON o.customer_id = c.customer_id;

ON est aussi l’endroit où vous pouvez définir des correspondances plus complexes (par ex. en appariant sur deux colonnes) sans transformer votre requête en devinette.

USING : plus court, mais seulement pour des colonnes du même nom

Certaines bases (comme PostgreSQL et MySQL) supportent USING. C’est un raccourci pratique quand les deux tables ont une colonne du même nom et que vous voulez joindre sur cette colonne.

SELECT
  customer_id,
  name,
  order_id
FROM customers
JOIN orders
USING (customer_id);

Un avantage : USING retourne typiquement une seule colonne customer_id dans la sortie (au lieu de deux copies).

Évitez les noms de colonnes ambigus : qualifiez toujours dans les jointures

Une fois les tables jointes, les noms de colonnes se chevauchent souvent (id, created_at, status). Si vous écrivez SELECT id, la base peut renvoyer une erreur de « colonne ambiguë » — ou pire, vous pourriez lire le mauvais id.

Préférez les préfixes de table (ou les alias) pour la clarté :

SELECT c.customer_id, o.order_id
FROM customers AS c
JOIN orders AS o
  ON o.customer_id = c.customer_id;

Évitez SELECT * dans les requêtes jointes

SELECT * devient vite brouillon avec les jointures : vous récupérez des colonnes inutiles, risquez des duplications de noms et rendez plus difficile la compréhension du résultat attendu.

Sélectionnez plutôt les colonnes exactes dont vous avez besoin. Le résultat est plus propre, plus facile à maintenir et souvent plus efficace — surtout quand les tables sont larges.

Filtrer des données jointes : WHERE vs ON

Quand vous joignez des tables, WHERE et ON filtrent tous deux, mais à des moments différents.

• ON décide quelles lignes correspondent lors de la jointure.
• WHERE filtre le résultat final après que la jointure a été réalisée.

Cette différence de moment est la raison pour laquelle on voit souvent des gens transformer accidentellement un LEFT JOIN en INNER JOIN.

Comment WHERE peut casser un LEFT JOIN

Supposons que vous vouliez tous les clients, même ceux n’ayant pas de commandes récentes payées.

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.status = 'PAID'
  AND o.order_date >= DATE '2025-01-01';

Problème : pour les clients sans commande correspondante, o.status et o.order_date sont NULL. La clause WHERE rejette ces lignes, donc les clients non appariés disparaissent — votre LEFT JOIN se comporte comme un INNER JOIN.

Déplacer les conditions liées à la jointure dans ON pour garder les lignes non appariées

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
 AND o.status = 'PAID'
 AND o.order_date >= DATE '2025-01-01';

Désormais, les clients sans commandes qualifiantes apparaissent toujours (avec des colonnes order = NULL), ce qui est généralement l’objectif d’un LEFT JOIN.

Checklist rapide : quoi mettre dans ON vs WHERE ?

• Mettez les conditions dans ON quand elles décrivent quelles lignes de la table de droite peuvent correspondre (filtres de statut/date/type sur la table jointe).

Éviter les doublons et les surprises en cas de relations plusieurs-à-plusieurs

Les jointures n’ajoutent pas seulement des colonnes — elles peuvent aussi multiplier les lignes. C’est généralement un comportement attendu, mais cela surprend souvent lorsque les totaux doublent (ou pire).

Pourquoi les lignes se multiplient

Une jointure renvoie une ligne de sortie pour chaque paire de lignes correspondantes.

• Un‑à-plusieurs : un client peut avoir plusieurs commandes. En joignant customers à orders, chaque client peut apparaître plusieurs fois — une fois par commande.
• Plusieurs‑à‑plusieurs (le vrai piège) : si vous joignez orders à et que chaque commande peut avoir plusieurs paiements, vous pouvez obtenir plusieurs lignes par commande. Si vous joignez en plus une autre table « many » (comme ), vous pouvez créer un effet de multiplication : par commande.

Agréger avant de joindre

Si votre objectif est « une ligne par client » ou « une ligne par commande », pré‑résumez d’abord le côté « many », puis joignez.

-- Une ligne par commande à partir des paiements
WITH payment_totals  (
  
    order_id,
    (amount)  total_paid,
    ()    payment_count
   payments
    order_id
)

  o.order_id,
  o.customer_id,
  (pt.total_paid, )  total_paid,
  (pt.payment_count, )  payment_count
 orders o
  payment_totals pt
   pt.order_id  o.order_id;

Cela garde la « forme » de la jointure prévisible : une ligne commande reste une ligne commande.

DISTINCT en dernier recours

SELECT DISTINCT peut donner l’apparence de résoudre les doublons, mais il peut masquer le vrai problème :

• Il peut supprimer silencieusement des lignes légitimes.
• Il peut cacher une condition de jointure incorrecte (par ex. l’absence d’une partie d’une clé composite).
• Il peut fausser les totaux (surtout les sommes et les comptes).

Utilisez‑le seulement si vous êtes certain que les doublons sont totalement accidentels et que vous comprenez pourquoi ils sont apparus.

Vérification rapide : validez les comptages

Avant de faire confiance aux résultats, comparez les comptes de lignes :

• Comptez les lignes dans votre table principale (ex. commandes).
• Comptez les lignes après la jointure.
• Si le nombre augmente de façon inattendue, inspectez quelles clés provoquent des correspondances multiples et décidez si vous devez agréger ou changer le chemin de jointure.

Bases de performance et fiche mémo JOIN

Les JOINs sont souvent accusés de « requêtes lentes », mais la vraie cause est généralement la quantité de données que vous demandez à la base de combiner et la facilité avec laquelle elle peut trouver les lignes correspondantes.

Indexation (conceptuelle) et pourquoi ça aide les JOINs

Pensez à un index comme à une table des matières d’un livre. Sans index, la base peut devoir scanner beaucoup de lignes pour trouver les correspondances de votre condition de JOIN. Avec un index sur la clé de jointure (par exemple customers.customer_id et orders.customer_id), la base peut accéder directement aux lignes concernées bien plus vite.

Vous n’avez pas besoin de connaître les détails internes pour bien l’utiliser : si une colonne est fréquemment utilisée pour apparier des lignes (ON a.id = b.a_id), elle est un bon candidat pour avoir un index.

Joindre sur des clés stables (pas des noms ou des e‑mails)

Dans la mesure du possible, joignez sur des identifiants stables et uniques :

• Bon : customers.customer_id = orders.customer_id
• Risqué : customers.email = orders.email ou customers.name = orders.name

Les noms changent et peuvent se répéter. Les e‑mails peuvent changer, être manquants ou différer par la casse/format. Les IDs sont conçus pour une correspondance cohérente et sont souvent indexés.

Réduisez le travail dès le départ

Deux habitudes rendent les JOINs nettement plus rapides :

1. Sélectionnez moins de colonnes. Évitez SELECT * quand vous joignez plusieurs tables — les colonnes superflues augmentent l’usage mémoire et réseau.
2. Limitez les lignes avant ou pendant la JOIN. Filtrez le plus tôt possible.

Exemple : limitez d’abord les commandes, puis joignez :

SELECT c.customer_id, c.name, o.order_id, o.created_at
FROM customers c
JOIN (
  SELECT order_id, customer_id, created_at
  FROM orders
  WHERE created_at >= DATE '2025-01-01'
) o
  ON o.customer_id = c.customer_id;

Si vous itérez sur ces requêtes dans le cadre d’un développement d’application (par ex. pour une page de reporting sur PostgreSQL), des outils comme Koder.ai peuvent accélérer le scaffolding — schéma, endpoints, UI — tout en vous laissant le contrôle de la logique de JOIN qui garantit la justesse.

Fiche mémo rapide JOIN