SQL pour data analyst : compétences essentielles 2026

SQL reste en 2026 la compétence technique la plus demandée pour les postes de data analyst. Toutes les offres d'emploi la mentionnent, tous les entretiens la testent, et aucun outil no-code ne l'a remplacée pour les analyses complexes. Mais quelles sont exactement les compétences SQL qu'un data analyst doit maîtriser en 2026 ?

Découvrez les niveaux de compétence attendus, de la base aux techniques avancées, et ce qui a changé avec l'arrivée de l'IA.

Le socle indispensable

Requêtes de base : SELECT, WHERE, ORDER BY

Un data analyst passe une grande partie de son temps à explorer des données. Les requêtes de base doivent être instinctives :

SELECT
    client_id,
    nom,
    date_inscription,
    pays
FROM clients
WHERE pays IN ('France', 'Belgique', 'Suisse')
    AND date_inscription >= '2025-01-01'
    AND email IS NOT NULL
ORDER BY date_inscription DESC
LIMIT 100;

**Ce qu'on attend d'un data analyst** :
- Filtres complexes avec AND/OR, IN, BETWEEN, LIKE, IS NULL
- Manipulation des dates (extraction mois/année, intervalles)
- Tri multi-colonnes
- LIMIT/OFFSET pour l'exploration

### JOINs : le quotidien du data analyst

En entreprise, les données sont rarement dans une seule table. Un data analyst fait des JOINs dans **chaque requête** ou presque.

```sql
-- Analyse typique : CA par catégorie de produit par mois
SELECT
    p.categorie,
    DATE_TRUNC('month', c.date_commande) AS mois,
    SUM(lc.quantite * lc.prix_unitaire) AS chiffre_affaires,
    COUNT(DISTINCT c.id) AS nb_commandes
FROM commandes c
INNER JOIN lignes_commande lc ON c.id = lc.commande_id
INNER JOIN produits p ON lc.produit_id = p.id
WHERE c.statut = 'livré'
GROUP BY p.categorie, DATE_TRUNC('month', c.date_commande)
ORDER BY mois DESC, chiffre_affaires DESC;
**Compétences attendues** :
- INNER JOIN et LEFT JOIN maîtrisés parfaitement
- JOINs sur 3-5 tables simultanément
- Anti-join (LEFT JOIN + WHERE IS NULL) pour trouver les données manquantes
- Self-join pour les comparaisons intra-table

Pour approfondir, consultez notre [guide complet des JOINs SQL](/joins-sql-inner-left-right-full-exercices).

### GROUP BY et agrégation

L'agrégation est le pain quotidien du data analyst : transformer des millions de lignes en insights exploitables.

```sql
-- Reporting hebdomadaire des inscriptions
SELECT
    DATE_TRUNC('week', date_inscription) AS semaine,
    COUNT(*) AS nb_inscriptions,
    COUNT(CASE WHEN source = 'organic' THEN 1 END) AS inscriptions_organic,
    COUNT(CASE WHEN source = 'paid' THEN 1 END) AS inscriptions_paid,
    ROUND(
        100.0 * COUNT(CASE WHEN a_achete THEN 1 END) / NULLIF(COUNT(*), 0), 1
    ) AS taux_conversion_pct
FROM utilisateurs
GROUP BY DATE_TRUNC('week', date_inscription)
ORDER BY semaine DESC;

Voir notre guide GROUP BY et HAVING.

Les compétences intermédiaires

CTE : structurer ses analyses

En 2026, écrire des sous-requêtes imbriquées sur 5 niveaux n'est plus acceptable. Les CTE sont devenues le standard pour structurer les requêtes complexes.

WITH utilisateurs_actifs AS (
    SELECT DISTINCT utilisateur_id
    FROM evenements
    WHERE date_evenement >= CURRENT_DATE - INTERVAL '30 days'
),
revenus_par_utilisateur AS (
    SELECT
        utilisateur_id,
        SUM(montant) AS revenu_total
    FROM achats
    WHERE utilisateur_id IN (SELECT utilisateur_id FROM utilisateurs_actifs)
    GROUP BY utilisateur_id
)
SELECT
    CASE
        WHEN revenu_total >= 500 THEN 'Gros acheteur'
        WHEN revenu_total >= 100 THEN 'Acheteur moyen'
        ELSE 'Petit acheteur'
    END AS segment,
    COUNT(*) AS nb_utilisateurs,
    ROUND(AVG(revenu_total), 2) AS panier_moyen
FROM revenus_par_utilisateur
GROUP BY 1
ORDER BY panier_moyen DESC;

Voir notre article sur les CTE en SQL.

CASE WHEN : la logique métier en SQL

Un data analyst passe beaucoup de temps à catégoriser, segmenter et pivoter les données. CASE WHEN est l'outil central pour cela.

Voir CASE WHEN en SQL.

Sous-requêtes et EXISTS

Savoir quand utiliser une sous-requête corrélée, un EXISTS ou un JOIN est une compétence intermédiaire clé.

Voir notre article sur les sous-requêtes SQL.

Les compétences avancées (le differentiator)

Window Functions

Les fonctions fenêtre sont ce qui distingue un bon data analyst d'un excellent data analyst en 2026. Elles permettent des analyses impossibles (ou très complexes) avec GROUP BY seul.

Classement et top-N

-- Top 3 produits par catégorie
WITH classement AS (
    SELECT
        categorie,
        produit,
        ca_mensuel,
        RANK() OVER (PARTITION BY categorie ORDER BY ca_mensuel DESC) AS rang
    FROM stats_produits
    WHERE mois = '2026-03-01'
)
SELECT * FROM classement WHERE rang <= 3;

Comparaison temporelle

-- Variation mois sur mois
SELECT
    mois,
    revenu,
    LAG(revenu) OVER (ORDER BY mois) AS revenu_m_1,
    ROUND(100.0 * (revenu - LAG(revenu) OVER (ORDER BY mois))
        / NULLIF(LAG(revenu) OVER (ORDER BY mois), 0), 1) AS variation_pct
FROM revenus_mensuels;

Cumuls et moyennes mobiles

-- Moyenne mobile 7 jours
SELECT
    jour,
    nb_inscriptions,
    ROUND(AVG(nb_inscriptions) OVER (
        ORDER BY jour ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ), 1) AS moyenne_mobile_7j
FROM stats_quotidiennes;

Voir notre guide complet des fonctions fenêtre et RANK, DENSE_RANK et ROW_NUMBER.

Analyse de cohortes

L'analyse de cohortes est une compétence data analyst très valorisée. Elle combine CTE, window functions et agrégation :

WITH cohortes AS (
    SELECT
        utilisateur_id,
        DATE_TRUNC('month', MIN(date_achat)) AS mois_cohorte
    FROM achats
    GROUP BY utilisateur_id
),
activite AS (
    SELECT
        c.mois_cohorte,
        DATE_TRUNC('month', a.date_achat) AS mois_activite,
        COUNT(DISTINCT a.utilisateur_id) AS utilisateurs_actifs
    FROM cohortes c
    INNER JOIN achats a ON c.utilisateur_id = a.utilisateur_id
    GROUP BY c.mois_cohorte, DATE_TRUNC('month', a.date_achat)
)
SELECT
    mois_cohorte,
    mois_activite,
    utilisateurs_actifs,
    ROUND(
        100.0 * utilisateurs_actifs /
        FIRST_VALUE(utilisateurs_actifs) OVER (PARTITION BY mois_cohorte ORDER BY mois_activite),
        1
    ) AS taux_retention
FROM activite
ORDER BY mois_cohorte, mois_activite;

Pour un exercice guidé, voir Exercice SQL : calculer un taux de rétention.

Analyse de funnel

WITH etapes AS (
    SELECT
        session_id,
        MAX(CASE WHEN evenement = 'page_vue' THEN 1 ELSE 0 END) AS a_vu_page,
        MAX(CASE WHEN evenement = 'ajout_panier' THEN 1 ELSE 0 END) AS a_ajoute,
        MAX(CASE WHEN evenement = 'paiement' THEN 1 ELSE 0 END) AS a_paye
    FROM evenements
    GROUP BY session_id
)
SELECT
    COUNT(*) AS sessions_totales,
    SUM(a_vu_page) AS page_vue,
    SUM(a_ajoute) AS ajout_panier,
    SUM(a_paye) AS paiement,
    ROUND(100.0 * SUM(a_ajoute) / NULLIF(SUM(a_vu_page), 0), 1) AS taux_ajout_pct,
    ROUND(100.0 * SUM(a_paye) / NULLIF(SUM(a_ajoute), 0), 1) AS taux_paiement_pct
FROM etapes;

Pour un exercice complet, voir Exercice SQL : tunnel de conversion e-commerce.

Optimisation

Un data analyst qui écrit des requêtes performantes est beaucoup plus efficace. Les bases à connaître :

• Utiliser EXPLAIN pour comprendre le plan d'exécution
• Savoir quand un index est nécessaire
• Éviter SELECT *
• Comprendre l'impact des JOINs sur le volume de données

Voir nos 10 techniques d'optimisation SQL.

SQL et IA en 2026

Ce qui a changé

L'IA (ChatGPT, GitHub Copilot, les assistants SQL intégrés aux outils BI) peut générer du SQL à partir de langage naturel. Beaucoup de data analysts l'utilisent quotidiennement.

Ce que ça change pour les compétences SQL

Ce qui reste indispensable :

• Comprendre ce que fait une requête (pour vérifier le SQL généré par l'IA)
• Optimiser les requêtes (l'IA génère rarement du SQL optimisé)
• Debugger les erreurs (l'IA fait des erreurs subtiles)
• Comprendre les jointures et l'impact sur les données

Ce qui est moins critique :

• Mémoriser la syntaxe exacte de chaque fonction
• Connaître les différences de syntaxe entre les dialectes

En résumé : l'IA n'élimine pas le besoin de maîtriser SQL. Elle change les compétences les plus valorisées — de la syntaxe vers la compréhension et la vérification.

Pour en savoir plus, consultez nos articles sur l'entretien SQL avec IA et comment reviewer du SQL généré par IA.

Erreurs fréquentes à éviter

Basées sur l'analyse de plus de 1000 tests techniques, voici les erreurs les plus coûteuses en entretien :

Erreur #1 : Confusion entre WHERE et HAVING

-- ❌ Incorrect : filtrer l'agrégation avec WHERE
SELECT categorie, COUNT(*)
FROM produits
WHERE COUNT(*) > 10  -- Erreur !
GROUP BY categorie;

-- ✅ Correct : utiliser HAVING après GROUP BY
SELECT categorie, COUNT(*)
FROM produits
GROUP BY categorie
HAVING COUNT(*) > 10;

Erreur #2 : JOINs qui dupliquent les données

-- ❌ Problématique : relation 1-to-many non gérée
SELECT 
    u.nom,
    SUM(c.montant) as total_commandes  -- Fausse si un utilisateur a plusieurs adresses
FROM utilisateurs u
JOIN adresses a ON u.id = a.utilisateur_id
JOIN commandes c ON u.id = c.utilisateur_id
GROUP BY u.nom;

-- ✅ Solution : agréger avant de joindre
WITH total_par_utilisateur AS (
    SELECT utilisateur_id, SUM(montant) as total_commandes
    FROM commandes
    GROUP BY utilisateur_id
)
SELECT u.nom, t.total_commandes
FROM utilisateurs u
JOIN total_par_utilisateur t ON u.id = t.utilisateur_id;

Erreur #3 : Division par zéro non gérée

-- ❌ Plante si le dénominateur est 0
SELECT 
    produit,
    100.0 * ventes_cette_annee / ventes_annee_derniere as croissance_pct
FROM stats_produits;

-- ✅ Protection avec NULLIF
SELECT 
    produit,
    ROUND(100.0 * ventes_cette_annee / NULLIF(ventes_annee_derniere, 0), 1) as croissance_pct
FROM stats_produits;

Erreur #4 : Window functions mal comprises

L'erreur la plus fréquente avec les window functions concerne la différence entre RANK() et ROW_NUMBER() :

-- ❌ Problème : ROW_NUMBER() avec des égalités
SELECT 
    vendeur,
    ca_mensuel,
    ROW_NUMBER() OVER (ORDER BY ca_mensuel DESC) as position
FROM ventes_janvier;
-- Si deux vendeurs ont le même CA, l'ordre est arbitraire

-- ✅ Solution : RANK() pour gérer les égalités
SELECT 
    vendeur,
    ca_mensuel,
    RANK() OVER (ORDER BY ca_mensuel DESC) as position
FROM ventes_janvier;
-- Deux vendeurs à égalité auront la même position

Erreur #5 : Agrégations sur des JOINs 1-to-many

Cette erreur est particulièrement sournoise car elle produit des résultats "plausibles" mais faux :

-- ❌ Piège : commandes dupliquées par les lignes de commande
SELECT 
    EXTRACT(MONTH FROM c.date_commande) as mois,
    COUNT(*) as nb_commandes,  -- FAUX : compte les lignes, pas les commandes
    SUM(c.montant_total) as ca  -- FAUX : somme les montants dupliqués
FROM commandes c
JOIN lignes_commande lc ON c.id = lc.commande_id;

-- ✅ Solution : COUNT DISTINCT ou agréger séparément
SELECT 
    EXTRACT(MONTH FROM c.date_commande) as mois,
    COUNT(DISTINCT c.id) as nb_commandes,
    SUM(DISTINCT c.montant_total) as ca
FROM commandes c
JOIN lignes_commande lc ON c.id = lc.commande_id
GROUP BY EXTRACT(MONTH FROM c.date_commande);

Spécificités par secteur d'activité

Les attentes en SQL varient significativement selon le secteur :

E-commerce et Marketplace

Compétences prioritaires :

• Analyses de cohortes (rétention client)
• Tunnels de conversion (panier → paiement)
• Segmentation RFM (Récence, Fréquence, Montant)
• Window functions pour les classements produits

Exemple type d'analyse :

-- Analyse RFM simplifiée
WITH rfm AS (
    SELECT 
        client_id,
        DATEDIFF(CURRENT_DATE, MAX(date_commande)) as recence,
        COUNT(*) as frequence,
        AVG(montant) as montant_moyen
    FROM commandes
    WHERE date_commande >= '2025-01-01'
    GROUP BY client_id
)
SELECT 
    CASE 
        WHEN recence <= 30 AND frequence >= 5 AND montant_moyen >= 100 THEN 'VIP'
        WHEN recence <= 90 AND frequence >= 2 THEN 'Actif'
        ELSE 'À réactiver'
    END as segment,
    COUNT(*) as nb_clients
FROM rfm
GROUP BY 1;

SaaS et Tech

Compétences prioritaires :

• Métriques d'activation et d'engagement
• Analyses de churn et prédiction
• Event tracking et product analytics
• Requêtes sur données JSON (logs, events)

Exemple concret : Julien, data analyst chez une startup EdTech, calcule le taux d'activation des nouveaux utilisateurs (défini comme "a terminé au moins 2 exercices dans ses 7 premiers jours") :

WITH nouveaux_utilisateurs AS (
    SELECT 
        user_id,
        MIN(created_at) as date_inscription
    FROM users
    WHERE created_at >= '2026-03-01'
    GROUP BY user_id
),
activite_j7 AS (
    SELECT 
        nu.user_id,
        COUNT(DISTINCT e.exercise_id) as exercices_termines
    FROM nouveaux_utilisateurs nu
    LEFT JOIN exercise_completions e ON nu.user_id = e.user_id
        AND e.completed_at BETWEEN nu.date_inscription 
        AND nu.date_inscription + INTERVAL '7 days'
    GROUP BY nu.user_id
)
SELECT 
    COUNT(*) as nouveaux_utilisateurs,
    COUNT(CASE WHEN exercices_termines >= 2 THEN 1 END) as utilisateurs_actifs,
    ROUND(100.0 * COUNT(CASE WHEN exercices_termines >= 2 THEN 1 END) / COUNT(*), 1) as taux_activation_pct
FROM activite_j7;

Finance et Banque

Compétences prioritaires :

• Agrégations temporelles complexes (rolling windows)
• Calculs de risque et conformité réglementaire
• Requêtes sur gros volumes (millions de transactions)
• Précision décimale et gestion des arrondis

Exemple concret : Sophie, analyste risque dans une banque digitale, calcule l'exposition par tranche d'âge avec une fenêtre glissante de 30 jours :

WITH exposition_quotidienne AS (
    SELECT 
        DATE(transaction_date) as jour,
        CASE 
            WHEN DATEDIFF(CURRENT_DATE, u.date_naissance) / 365 < 30 THEN '18-29 ans'
            WHEN DATEDIFF(CURRENT_DATE, u.date_naissance) / 365 < 50 THEN '30-49 ans'
            ELSE '50+ ans'
        END as tranche_age,
        SUM(CASE WHEN type_transaction = 'credit' THEN montant ELSE -montant END) as exposition_nette
    FROM transactions t
    JOIN users u ON t.user_id = u.id
    WHERE transaction_date >= CURRENT_DATE - INTERVAL '90 days'
        AND montant > 0
    GROUP BY DATE(transaction_date), tranche_age
)
SELECT 
    jour,
    tranche_age,
    exposition_nette,
    AVG(exposition_nette) OVER (
        PARTITION BY tranche_age 
        ORDER BY jour 
        ROWS BETWEEN 29 PRECEDING AND CURRENT ROW
    ) as moyenne_mobile_30j,
    MAX(exposition_nette) OVER (
        PARTITION BY tranche_age 
        ORDER BY jour 
        ROWS BETWEEN 29 PRECEDING AND CURRENT ROW
    ) as exposition_max_30j
FROM exposition_quotidienne
ORDER BY jour DESC, tranche_age;

Validation par la pratique : exercices incontournables

Selon notre analyse des entretiens techniques, ces 5 types d'exercices représentent 80% des questions posées :

1. Top N par groupe (window functions)

-- Les 2 meilleurs vendeurs par région
WITH classement AS (
    SELECT 
        vendeur_id, region, ca_mensuel,
        ROW_NUMBER() OVER (PARTITION BY region ORDER BY ca_mensuel DESC) as rang
    FROM ventes_janvier
)
SELECT * FROM classement WHERE rang <= 2;

2. Comparaison période précédente (LAG/LEAD)

-- Évolution mois sur mois
SELECT 
    mois,
    revenus,
    LAG(revenus) OVER (ORDER BY mois) as revenus_precedent,
    revenus - LAG(revenus) OVER (ORDER BY mois) as delta
FROM revenus_mensuels;

3. Calcul de rétention

-- Taux de rétention à 30 jours
WITH premieres_connexions AS (
    SELECT user_id, MIN(date_connexion) as premiere_date
    FROM connexions GROUP BY user_id
),
retour_30j AS (
    SELECT 
        p.user_id,
        CASE WHEN EXISTS (
            SELECT 1 FROM connexions c 
            WHERE c.user_id = p.user_id 
            AND c.date_connexion BETWEEN p.premiere_date + 30 AND p.premiere_date + 37
        ) THEN 1 ELSE 0 END as est_revenu
    FROM premieres_connexions p
)
SELECT 
    ROUND(100.0 * SUM(est_revenu) / COUNT(*), 1) as taux_retention_30j
FROM retour_30j;

4. Self-join pour comparaisons

-- Employés qui gagnent plus que leur manager
SELECT 
    e.nom as employe,
    e.salaire as salaire_employe,
    m.nom as manager,
    m.salaire as salaire_manager
FROM employes e
JOIN employes m ON e.manager_id = m.id
WHERE e.salaire > m.salaire;

5. Agrégation conditionnelle

-- Pivot manuel avec CASE WHEN
SELECT 
    produit,
    SUM(CASE WHEN EXTRACT(MONTH FROM date_vente) = 1 THEN quantite ELSE 0 END) as janvier,
    SUM(CASE WHEN EXTRACT(MONTH FROM date_vente) = 2 THEN quantite ELSE 0 END) as fevrier,
    SUM(CASE WHEN EXTRACT(MONTH FROM date_vente) = 3 THEN quantite ELSE 0 END) as mars
FROM ventes
GROUP BY produit;

Techniques avancées pour data analysts expérimentés

Analyse de Monte Carlo en SQL

Pour les data analysts dans la finance ou l'actuariat, simuler des scénarios directement en SQL peut être très utile :

-- Simulation des revenus avec variabilité saisonnière
WITH mois_serie AS (
    SELECT generate_series(1, 12) as mois
),
simulations AS (
    SELECT 
        mois,
        100000 * (1 + 0.3 * SIN(2 * PI() * mois / 12)) * (1 + 0.1 * (RANDOM() - 0.5)) as simulation_1,
        100000 * (1 + 0.3 * SIN(2 * PI() * mois / 12)) * (1 + 0.1 * (RANDOM() - 0.5)) as simulation_2,
        100000 * (1 + 0.3 * SIN(2 * PI() * mois / 12)) * (1 + 0.1 * (RANDOM() - 0.5)) as simulation_3
    FROM mois_serie
)
SELECT 
    mois,
    ROUND((simulation_1 + simulation_2 + simulation_3) / 3) as revenu_moyen,
    ROUND(STDDEV(ARRAY[simulation_1, simulation_2, simulation_3])) as volatilite
FROM simulations;

Détection d'anomalies avec Z-score

WITH stats_base AS (
    SELECT 
        DATE_TRUNC('day', created_at) as jour,
        COUNT(*) as nb_inscriptions
    FROM users
    WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
    GROUP BY DATE_TRUNC('day', created_at)
),
stats_agregees AS (
    SELECT 
        AVG(nb_inscriptions) as moyenne,
        STDDEV(nb_inscriptions) as ecart_type
    FROM stats_base
)
SELECT 
    s.jour,
    s.nb_inscriptions,
    ROUND((s.nb_inscriptions - sa.moyenne) / NULLIF(sa.ecart_type, 0), 2) as z_score,
    CASE 
        WHEN ABS((s.nb_inscriptions - sa.moyenne) / NULLIF(sa.ecart_type, 0)) > 2 
        THEN '🚨 Anomalie'
        ELSE '✅ Normal'
    END as statut
FROM stats_base s
CROSS JOIN stats_agregees sa
ORDER BY z_score DESC;

Tableau récapitulatif : Compétences SQL par niveau

Cartographie des compétences SQL par profil

Ressources recommandées pour progresser

• Exercices pratiques : LeetCode SQL, HackerRank SQL
• Mise en pratique : Créez une base de données personnelle avec vos données (Spotify, Netflix, etc.)
• Spécialisation : Focus sur votre secteur cible (e-commerce, SaaS, finance)
• Entretiens blancs : Pratiquez avec des data analysts en ligne

Questions fréquentes

Quelle est la compétence SQL la plus testée en entretien ?

Les JOINs et GROUP BY représentent ensemble 50% des questions posées. Ils sont éliminatoires — sans une maîtrise solide, vous ne progresserez pas aux étapes suivantes. Les window functions arrivent en deuxième position et distinguent les bons candidats des excellents.

Dois-je apprendre plusieurs dialectes SQL (PostgreSQL, MySQL, SQL Server) ?

Pour un data analyst, concentrez-vous sur un dialecte populaire dans votre secteur (PostgreSQL pour la tech, SQL Server pour l'enterprise, BigQuery pour le cloud). Les 90% des concepts sont identiques. Une fois maîtrisé, passer d'un dialecte à l'autre prend 2-3 jours pour les différences syntaxiques.

En 2026, ChatGPT remplace-t-il vraiment les compétences SQL ?

Non. L'IA accélère la génération de code, mais elle génère rarement du SQL optimal. Les compétences critiques se déplacent vers : la vérification (lire et comprendre le code généré), l'optimisation (améliorer performance), et la stratégie (choisir la bonne approche). Les data analysts qui utilisent ChatGPT efficacement (en relisant et en corrigeant) sont 3x plus productifs.

Combien de temps pour maîtriser SQL à un niveau "intermédiaire" ?

Avec une pratique quotidienne de 2-3 heures : 4-6 semaines. Ce délai suppose que vous pratiquez sur des cas réels ou des exercices motivants. Les délais s'allongent si vous pratiquez sporadiquement ou sur des exercices abstraits.

Quelle est l'erreur la plus grave à éviter en entretien SQL ?

Écrire une requête "qui marche" mais donne des résultats faux. Exemple : un JOIN 1-to-many sans agréger séparément, qui duplique les données. Ces erreurs sont plus coûteuses qu'une requête qui plante (au moins, vous le saurez !). Toujours vérifier votre logique d'agrégation, surtout avec les JOINs.

Est-ce que les window functions sont vraiment nécessaires pour débuter ?

Non. Vous pouvez commencer en tant que data analyst sans maîtriser les window functions. Mais au-delà d'un niveau junior, c'est un passage obligatoire. Les analyses de cohortes, les comparaisons temporelles, les rankings — tout cela est beaucoup plus facile avec les window functions. C'est l'équivalent SQL de maîtriser les formules avancées en Excel : ce n'est pas fondamental, mais cela triple votre efficacité.

Comment progresser sans accès à une vraie base de données ?

Plusieurs options gratuites existent :

• Mode Analytics : plateformes avec datasets réalistes en SQL
• DataCamp, Codecademy : exercices interactifs progressifs
• Créer vos données : téléchargez des datasets Kaggle ou Wikipedia, importez-les dans SQLite/PostgreSQL local
• Projets personnels : analysez vos données (Spotify, Netflix, banque, emails)

Les données "réelles" (même vos propres données) sont beaucoup plus motivantes que les exercices abstraits.

Dernière mise à jour : mai 2026