Les 8 erreurs les plus fréquentes

Erreur 1 : Multiplication de lignes par les JOINs

C'est l'erreur la plus fréquente et la plus dangereuse.

-- Prompt : "Total des ventes et nombre de retours par client"
-- SQL généré par l'IA :
SELECT
    c.name,
    SUM(o.amount) AS total_sales,
    COUNT(r.id) AS nb_returns
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
LEFT JOIN returns r ON c.id = r.customer_id
GROUP BY c.name;

**Le problème** : si un client a 5 commandes et 3 retours, le JOIN produit 15 lignes (5 × 3 = produit cartésien partiel). Le total des ventes est multiplié par 3, le nombre de retours par 5.

**La correction** — pré-agréger dans des CTEs séparées :

```sql
WITH sales_by_customer AS (
    SELECT customer_id, SUM(amount) AS total_sales
    FROM orders
    GROUP BY customer_id
),
returns_by_customer AS (
    SELECT customer_id, COUNT(*) AS nb_returns
    FROM returns
    GROUP BY customer_id
)
SELECT
    c.name,
    COALESCE(s.total_sales, 0) AS total_sales,
    COALESCE(r.nb_returns, 0) AS nb_returns
FROM customers c
LEFT JOIN sales_by_customer s ON c.id = s.customer_id
LEFT JOIN returns_by_customer r ON c.id = r.customer_id;
<div class="callout callout-tip">
<p class="callout-title">💡 Bon à savoir</p>
<p><strong>Détecter :</strong> comparez COUNT(*) avant et après le JOIN. Si le nombre de lignes augmente de manière inattendue, il y a une multiplication. <strong>Corriger :</strong> pré-agrégez chaque table dans une CTE séparée avant de joindre. Joignez uniquement des résultats déjà agrégés au niveau de la clé de jointure.</p>
</div>

### Erreur 2 : LEFT JOIN transformé en INNER JOIN

L'IA ajoute souvent un `WHERE` sur la table de droite, ce qui annule le LEFT JOIN.

```sql
-- L'IA génère :
SELECT c.name, o.order_date
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'shipped';  -- élimine les clients sans commande

La correction — déplacer la condition dans le ON :

SELECT c.name, o.order_date
FROM customers c
LEFT JOIN orders o 
    ON c.id = o.customer_id 
    AND o.status = 'shipped';

Pour maîtriser les JOINs dans tous leurs cas, consultez notre guide complet des JOINs SQL.

Erreur 3 : Fenêtre par défaut incorrecte

L'IA utilise fréquemment les window functions sans spécifier la frame :

-- L'IA génère :
SELECT
    date,
    amount,
    AVG(amount) OVER (ORDER BY date) AS moving_avg
FROM sales;

Le problème : sans ROWS BETWEEN, la frame par défaut est RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. Avec RANGE, toutes les lignes ayant la même date sont incluses dans le même groupe — ce n'est pas une moyenne mobile.

La correction :

SELECT
    date,
    amount,
    AVG(amount) OVER (
        ORDER BY date
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS moving_avg_7d
FROM sales;

Pour comprendre les subtilités des fonctions fenêtre, voir notre guide des fonctions fenêtre SQL.

Erreur 4 : NULL ignorés dans les calculs

L'IA oublie souvent de traiter les NULL :

-- L'IA génère : taux de complétion d'un formulaire
SELECT
    100.0 * COUNT(CASE WHEN step = 'complete' THEN 1 END) / COUNT(*) AS completion_rate
FROM form_events;

Le problème : si step peut être NULL, ces lignes ne sont ni comptées dans le numérateur ni correctement gérées. Il faut aussi se demander si COUNT(*) est le bon dénominateur (tous les événements ? ou les utilisateurs uniques ?).

La correction :

SELECT
    ROUND(
        100.0 * COUNT(DISTINCT CASE WHEN step = 'complete' THEN user_id END)
        / NULLIF(COUNT(DISTINCT user_id), 0),
        1
    ) AS completion_rate
FROM form_events;

Erreur 5 : Mauvais dialecte SQL

L'IA génère parfois du SQL pour le mauvais dialecte :

-- Syntaxe PostgreSQL, mais vous êtes sur MySQL
SELECT DATE_TRUNC('month', order_date) AS month FROM orders;

-- En MySQL, il faut :
SELECT DATE_FORMAT(order_date, '%Y-%m-01') AS month FROM orders;

Ou encore :

-- L'IA utilise ILIKE (PostgreSQL) au lieu de LIKE avec LOWER (MySQL)
SELECT * FROM products WHERE name ILIKE '%widget%';

-- En MySQL :
SELECT * FROM products WHERE LOWER(name) LIKE '%widget%';

Erreur 6 : Agrégation sans les bonnes colonnes dans GROUP BY

-- L'IA génère :
SELECT
    department,
    employee_name,
    MAX(salary) AS max_salary
FROM employees
GROUP BY department;

Le problème : employee_name n'est pas dans le GROUP BY. PostgreSQL et SQL Server rejettent cette requête. MySQL en mode non-strict retourne une valeur arbitraire pour employee_name — qui n'est pas forcément l'employé avec le salaire max.

La correction — utiliser une window function :

WITH ranked AS (
    SELECT *, RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS rn
    FROM employees
)
SELECT department, employee_name, salary
FROM ranked WHERE rn = 1;

Pour approfondir les GROUP BY et HAVING, consultez notre guide GROUP BY et HAVING.

Erreur 7 : Performances catastrophiques

L'IA écrit du SQL qui fonctionne sur 1000 lignes mais explose sur 10 millions :

-- L'IA génère : sous-requête corrélée sur chaque ligne
SELECT
    e.name,
    e.salary,
    (SELECT AVG(salary) FROM employees e2
     WHERE e2.department_id = e.department_id) AS dept_avg
FROM employees e;

La correction — une seule passe avec une window function :

SELECT
    name,
    salary,
    AVG(salary) OVER (PARTITION BY department_id) AS dept_avg
FROM employees;

Pour plus de techniques d'optimisation, voir 10 techniques d'optimisation SQL.

Erreur 8 : Logique métier incorrecte

L'IA ne connaît pas votre business. Elle peut :

• Compter les annulations comme des ventes
• Inclure les employés inactifs dans les statistiques
• Confondre la date de création et la date de livraison
• Utiliser le prix catalogue au lieu du prix réel

-- L'IA génère : CA basé sur le prix catalogue
SELECT SUM(p.catalog_price * oi.quantity) AS revenue
FROM order_items oi
JOIN products p ON oi.product_id = p.id;

-- Mais le vrai CA est basé sur le prix effectivement payé
SELECT SUM(oi.unit_price * oi.quantity) AS revenue
FROM order_items oi
WHERE order_status = 'delivered';

Erreurs par profil d'utilisateur et cas concrets

Erreurs des débutants (< 1 an d'expérience)

Les débutants font souvent confiance aveuglément à l'IA et ne détectent pas les erreurs subtiles.

Exemple : Clara, analyste marketing junior

Clara demande : "Taux de conversion par canal d'acquisition"

-- L'IA génère (erreur subtile) :
SELECT 
    channel,
    COUNT(CASE WHEN status = 'converted' THEN 1 END) * 100.0 / COUNT(*) as conversion_rate
FROM users
GROUP BY channel;

Le problème : COUNT(*) inclut tous les utilisateurs, même ceux qui viennent juste de s'inscrire et n'ont pas encore eu le temps de convertir. Le taux est artificiellement bas.

La correction métier :

SELECT 
    channel,
    COUNT(CASE WHEN status = 'converted' THEN 1 END) * 100.0 / 
    COUNT(CASE WHEN created_at <= CURRENT_DATE - INTERVAL '7 days' THEN 1 END) as conversion_rate,
    COUNT(*) as total_users,
    COUNT(CASE WHEN status = 'converted' THEN 1 END) as converted_users
FROM users
WHERE created_at <= CURRENT_DATE - INTERVAL '7 days'
GROUP BY channel
ORDER BY conversion_rate DESC;

Erreurs des intermédiaires (2-4 ans)

Les utilisateurs intermédiaires détectent les erreurs évidentes mais ratent les subtilités métier.

Exemple : Marc, analyste financier

Marc demande : "Évolution du chiffre d'affaires mensuel avec croissance YoY"

-- L'IA génère (logique incomplète) :
WITH monthly_revenue AS (
    SELECT 
        DATE_TRUNC('month', order_date) as month,
        SUM(amount) as revenue
    FROM orders 
    WHERE status = 'paid'
    GROUP BY 1
)
SELECT 
    month,
    revenue,
    LAG(revenue, 12) OVER (ORDER BY month) as revenue_previous_year,
    ROUND((revenue - LAG(revenue, 12) OVER (ORDER BY month)) * 100.0 / 
    LAG(revenue, 12) OVER (ORDER BY month), 2) as yoy_growth_pct
FROM monthly_revenue;

Le problème : la requête ne gère pas les remboursements, les annulations tardives, ni les ajustements comptables. En finance, le CA doit être net.

La correction comptable :

WITH transactions AS (
    SELECT DATE_TRUNC('month', order_date) as month, amount
    FROM orders 
    WHERE status IN ('paid', 'delivered')
    UNION ALL
    SELECT DATE_TRUNC('month', refund_date) as month, -refund_amount
    FROM refunds 
    WHERE status = 'processed'
),
monthly_revenue AS (
    SELECT month, SUM(amount) as net_revenue
    FROM transactions
    GROUP BY month
)
SELECT 
    month,
    net_revenue,
    LAG(net_revenue, 12) OVER (ORDER BY month) as revenue_previous_year,
    ROUND((net_revenue - LAG(net_revenue, 12) OVER (ORDER BY month)) * 100.0 / 
         NULLIF(LAG(net_revenue, 12) OVER (ORDER BY month), 0), 2) as yoy_growth_pct
FROM monthly_revenue
ORDER BY month DESC;

Erreurs spécifiques à l'e-commerce

Exemple : Léa, e-commerce manager

"Taux de retour par catégorie de produit"

-- L'IA génère (erreur de périmètre) :
SELECT 
    p.category,
    COUNT(r.id) * 100.0 / COUNT(o.id) as return_rate
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
LEFT JOIN returns r ON oi.id = r.order_item_id
GROUP BY p.category;

Le problème : compte les commandes récentes qui n'ont pas encore eu le temps d'être retournées.

La correction :

WITH eligible_orders AS (
    -- Seulement les commandes livrées depuis plus de 7 jours
    SELECT oi.id as order_item_id, p.category
    FROM orders o
    JOIN order_items oi ON o.id = oi.order_id
    JOIN products p ON oi.product_id = p.id
    WHERE o.status = 'delivered' 
      AND o.delivery_date <= CURRENT_DATE - INTERVAL '7 days'
      AND o.delivery_date >= CURRENT_DATE - INTERVAL '6 months'
)
SELECT 
    e.category,
    COUNT(e.order_item_id) as total_eligible_items,
    COUNT(r.id) as returned_items,
    ROUND(COUNT(r.id) * 100.0 / NULLIF(COUNT(e.order_item_id), 0), 2) as return_rate_pct
FROM eligible_orders e
LEFT JOIN returns r ON e.order_item_id = r.order_item_id 
    AND r.status = 'approved'
GROUP BY e.category
HAVING COUNT(e.order_item_id) >= 100
ORDER BY return_rate_pct DESC;

Cas réels par type de base de données

PostgreSQL : pièges fréquents

Problème avec les fuseaux horaires :

-- L'IA génère (ignore le fuseau horaire) :
SELECT DATE_TRUNC('day', created_at) FROM orders;

-- Correction (prise en compte du fuseau métier) :
SELECT DATE_TRUNC('day', created_at AT TIME ZONE 'UTC' 
       AT TIME ZONE 'Europe/Paris') FROM orders;

BigQuery : erreurs typiques

Problème avec les ARRAY et les partitions :

-- L'IA génère (syntaxe incorrecte) :
SELECT user_id, tags[0] FROM users;

-- Correction BigQuery :
SELECT user_id, tags[OFFSET(0)] FROM users;

MySQL : pièges courants

Problème avec le GROUP BY strict :

-- MySQL 5.7+ en mode strict rejette :
SELECT department, name, COUNT(*) FROM employees GROUP BY department;

-- Correction :
SELECT department, ANY_VALUE(name), COUNT(*) FROM employees 
GROUP BY department;

Checklist de revue complète

Pour tous les profils

• Exécution : la requête s'exécute-t-elle sans erreur ?
• Résultat : le nombre de lignes est-il plausible ?
• NULL : y a-t-il des NULL inattendus ou ignorés ?

Vérification des JOINs (priorité absolue)

• Comptabilisez les lignes avant et après chaque JOIN
• Si LEFT JOIN : des lignes de la table de gauche ont-elles disparu ?
• Les conditions de filtrage de la table de droite sont-elles dans ON ?

Vérification des agrégations

• COUNT vs COUNT DISTINCT : le bon est-il utilisé ?
• GROUP BY contient toutes les colonnes non-agrégées
• Les NULL sont traités dans les calculs de pourcentages
• Pas de division par zéro possible (NULLIF)

Vérification business

• Les bons statuts sont filtrés (actif/inactif, validé/brouillon)
• Les bonnes dates sont utilisées (création/modification/livraison)
• Recoupement avec une source alternative (Excel, dashboard)

Tableau récapitulatif : erreurs vs solutions

-- Exemple : test que le CA mensuel n'a pas changé de > 20%
SELECT 
    month,
    net_revenue,
    LAG(net_revenue) OVER (ORDER BY month) as prev_month,
    CASE 
        WHEN ABS(net_revenue - LAG(net_revenue) OVER (ORDER BY month)) / 
             LAG(net_revenue) OVER (ORDER BY month) > 0.2 THEN 'ALERTE'
        ELSE 'OK'
    END as status
FROM monthly_revenue
ORDER BY month DESC LIMIT 3;

-- Faux : mélange des cohortes d'âges différents
SELECT 
    registration_month,
    DATE_TRUNC('month', login_date) as activity_month,
    COUNT(DISTINCT user_id) as active_users
FROM users u
LEFT JOIN logins l ON u.id = l.user_id
GROUP BY 1, 2;

-- Correct : fenêtre d'observation identique pour tous les cohorts
WITH cohorts AS (
    SELECT 
        user_id,
        DATE_TRUNC('month', registration_date) as cohort_month
    FROM users
    WHERE registration_date >= '2024-01-01' - INTERVAL '12 months'
),
activity_month_number AS (
    SELECT 
        c.cohort_month,
        c.user_id,
        (DATE_TRUNC('month', l.login_date)::date - c.cohort_month::date) / 30 as months_since_signup
    FROM cohorts c
    LEFT JOIN logins l ON c.user_id = l.user_id
        AND l.login_date >= c.cohort_month
)
SELECT 
    cohort_month,
    months_since_signup,
    COUNT(DISTINCT user_id) as retained_users
FROM activity_month_number
WHERE months_since_signup >= 0 AND months_since_signup <= 11
GROUP BY 1, 2;

-- Faux : compte aussi les abandons
SELECT 
    step,
    COUNT(DISTINCT user_id) as users
FROM funnel_events
GROUP BY step
ORDER BY step;

-- Correct : progression à travers le tunnel
WITH step_completion AS (
    SELECT 
        user_id,
        MAX(CASE WHEN step = 'step_1' THEN timestamp END) as step_1_time,
        MAX(CASE WHEN step = 'step_2' THEN timestamp END) as step_2_time,
        MAX(CASE WHEN step = 'step_3' THEN timestamp END) as step_3_time
    FROM funnel_events
    GROUP BY user_id
)
SELECT 
    'Step 1' as step,
    COUNT(DISTINCT CASE WHEN step_1_time IS NOT NULL THEN user_id END) as users
FROM step_completion
UNION ALL
SELECT 
    'Step 2',
    COUNT(DISTINCT CASE WHEN step_2_time IS NOT NULL AND step_1_time IS NOT NULL THEN user_id END)
FROM step_completion
UNION ALL
SELECT 
    'Step 3',
    COUNT(DISTINCT CASE WHEN step_3_time IS NOT NULL 
        AND step_2_time IS NOT NULL AND step_1_time IS NOT NULL THEN user_id END)
FROM step_completion;

SELECT COUNT(*) as row_count FROM table1;  -- avant
SELECT COUNT(*) FROM table1 LEFT JOIN table2 ...;  -- après

-- ❌ Mauvais
LEFT JOIN users u ON orders.user_id = u.id
WHERE u.status = 'active'

-- ✅ Bon
LEFT JOIN users u ON orders.user_id = u.id AND u.status = 'active'