Test technique SQL : formats, préparation et stratégies

Le test technique SQL est devenu un passage obligé pour les postes data. Qu'il soit en ligne, en live ou en take-home, ce test évalue votre capacité à résoudre des problèmes concrets avec SQL. Découvrez exactement ce qui vous attend et comment maximiser vos chances de réussite.

Les formats de test SQL

Test en ligne chronométré (le plus courant)

Vous recevez un lien par email vers une plateforme comme HackerRank, Codility, StrataScratch ou DataLemur. Le test contient 3 à 5 questions à résoudre en 45 à 90 minutes.

Caractéristiques :

• Exécution asynchrone (vous choisissez le créneau)
• Environnement SQL intégré avec base de données pré-chargée
• Validation automatique (votre résultat doit matcher exactement)
• Chronomètre visible
• Souvent un mix de niveaux : 2 faciles, 2 moyennes, 1 difficile

Dialecte SQL : généralement PostgreSQL ou MySQL. Vérifiez avant de commencer — les syntaxes diffèrent pour les dates, les window functions et les CTE.

Live coding avec un interviewer

Le recruteur ou le hiring manager vous donne un problème en direct. Vous partagez votre écran et résolvez en temps réel pendant 30 à 60 minutes.

Caractéristiques :

• Le raisonnement verbal est évalué autant que le code
• Le recruteur peut donner des indices ou modifier l'énoncé
• Vous pouvez poser des questions (et vous devez le faire)
• L'environnement varie : IDE en ligne, Google Doc, ou même papier

Take-home assignment

Un exercice plus complet à réaliser chez soi en 24-48h. On vous fournit un jeu de données (CSV ou dump SQL) et plusieurs questions business à résoudre.

Caractéristiques :

• Plus de temps, mais plus d'exigences
• On attend du code propre, commenté et structuré
• Certaines entreprises demandent aussi des visualisations ou un memo

Les sujets testés par niveau de poste

Junior / Data Analyst débutant

Pour maîtriser ces notions fondamentales, consultez notre guide sur les JOINs SQL avec exercices pratiques et nos explications détaillées sur GROUP BY et HAVING.

Intermédiaire / Data Analyst confirmé

Les fonctions fenêtre SQL sont incontournables à ce niveau, tout comme la maîtrise des CTE (Common Table Expressions).

Senior / Data Engineer

Les plateformes de test les plus utilisées

HackerRank

• Utilisé par : grandes entreprises, banques, ESN
• Dialectes : PostgreSQL, MySQL, Oracle, SQL Server
• Difficulté : facile à difficile
• Conseil : lisez bien les contraintes de chaque question, le résultat doit être exact à la colonne et au tri près

Codility

• Utilisé par : entreprises tech européennes
• Dialectes : PostgreSQL principalement
• Difficulté : moyen à difficile
• Conseil : testez votre requête avec les cas d'exemple avant de soumettre

StrataScratch

• Utilisé par : entreprises data-driven (tech US, FAANG)
• Dialectes : PostgreSQL, MySQL
• Difficulté : questions tirées de vrais entretiens
• Conseil : excellent pour s'entraîner même si le test réel est ailleurs

DataLemur

• Utilisé par : comme outil de préparation et certains tests d'embauche
• Dialectes : PostgreSQL
• Difficulté : progressif (facile à expert)
• Conseil : commencez par les questions « Easy » pour gagner en confiance

Spécificités par type de poste et secteur

Data Analyst (fintech, e-commerce)

Les tests privilégient les analyses métier et les métriques business. Les questions portent souvent sur :

• Calculs de rétention : utilisateurs actifs, churn rate, lifetime value (LTV)
• Analyses de cohortes : évolution des comportements dans le temps
• Métriques de conversion : funnel d'acquisition, taux de transformation

Exemple type : "Calculez le taux de rétention mensuel des utilisateurs inscrits en janvier 2024"

WITH inscriptions_janvier AS (
  SELECT user_id, DATE_TRUNC('month', created_at) as cohorte
  FROM users 
  WHERE created_at >= '2024-01-01' AND created_at < '2024-02-01'
),
activite_mois_suivants AS (
  SELECT 
    i.user_id,
    i.cohorte,
    DATE_TRUNC('month', a.activity_date) as mois_activite,
    DATE_PART('month', AGE(a.activity_date, i.cohorte)) as mois_depuis_inscription
  FROM inscriptions_janvier i
  LEFT JOIN user_activity a ON i.user_id = a.user_id
)
SELECT 
  mois_depuis_inscription,
  COUNT(DISTINCT user_id) as utilisateurs_actifs,
  ROUND(100.0 * COUNT(DISTINCT user_id) / (SELECT COUNT(*) FROM inscriptions_janvier), 2) as taux_retention
FROM activite_mois_suivants
WHERE mois_depuis_inscription BETWEEN 0 AND 12
GROUP BY mois_depuis_inscription
ORDER BY mois_depuis_inscription;

Pour approfondir ce type d'analyse, consultez notre [exercice SQL sur le taux de rétention utilisateurs](/exercice-sql-taux-retention-utilisateurs).

### Data Engineer (tech, SaaS)

Les tests évaluent la capacité à traiter des volumes importants et optimiser les performances :

- **Optimisation de requêtes** : index, partitioning, explain plans
- **Patterns ETL** : Slowly Changing Dimensions (SCD), upserts, déduplication
- **Architecture de données** : modélisation en étoile, normalisation

**Exemple type** : "Optimisez cette requête qui traite 10M de lignes quotidiennement"

Avant optimisation :
```sql
SELECT customer_id, SUM(amount) 
FROM orders o 
JOIN customers c ON o.customer_id = c.id 
WHERE o.order_date >= '2024-01-01'
AND c.country = 'FR'
GROUP BY customer_id;
Après optimisation :
```sql
WITH french_customers AS (
  SELECT id FROM customers WHERE country = 'FR'
),
recent_orders AS (
  SELECT customer_id, amount 
  FROM orders 
  WHERE order_date >= '2024-01-01'
)
SELECT 
  ro.customer_id, 
  SUM(ro.amount) as total_amount
FROM recent_orders ro
INNER JOIN french_customers fc ON ro.customer_id = fc.id
GROUP BY ro.customer_id;

Notre guide sur l'optimisation des requêtes SQL approfondit ces techniques d'amélioration des performances.

Business Intelligence (consulting, grande entreprise)

Focus sur les rapports complexes et la consolidation de données multi-sources :

• Agrégations avancées : ROLLUP, CUBE, window functions avec PARTITION BY multiples
• Réconciliation de données : détection d'écarts, validation de cohérence
• Reporting hiérarchique : drill-down, calculs cumulés

Erreurs fréquentes à éviter par niveau

Erreurs niveau débutant

1. Confusion entre WHERE et HAVING

-- ❌ Incorrect
SELECT customer_id, COUNT(*) as nb_commandes
FROM orders
WHERE COUNT(*) > 5
GROUP BY customer_id;

-- ✅ Correct
SELECT customer_id, COUNT(*) as nb_commandes
FROM orders
GROUP BY customer_id
HAVING COUNT(*) > 5;

2. JOINs non qualifiés créant des produits cartésiens

-- ❌ Dangereux - risque de produit cartésien
SELECT o.id, c.name, p.name
FROM orders o, customers c, products p
WHERE o.customer_id = c.id;

-- ✅ Correct
SELECT o.id, c.name, p.name
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
INNER JOIN order_items oi ON o.id = oi.order_id
INNER JOIN products p ON oi.product_id = p.id;

3. Ignorer les valeurs NULL

-- ❌ Problématique - NULL est ignoré
SELECT COUNT(*) FROM orders WHERE status IN ('pending', 'completed');

-- ✅ Correct si vous voulez inclure les NULL
SELECT COUNT(*) FROM orders 
WHERE status IN ('pending', 'completed') OR status IS NULL;

Erreurs niveau intermédiaire

1. Mauvaise utilisation des window functions

-- ❌ Incorrect - mélange aggregation et window function
SELECT 
  customer_id,
  SUM(amount) as total,
  ROW_NUMBER() OVER (ORDER BY SUM(amount) DESC) as rang
FROM orders
GROUP BY customer_id;

-- ✅ Correct - avec CTE
WITH customer_totals AS (
  SELECT customer_id, SUM(amount) as total
  FROM orders
  GROUP BY customer_id
)
SELECT 
  customer_id,
  total,
  ROW_NUMBER() OVER (ORDER BY total DESC) as rang
FROM customer_totals;

2. Gestion incorrecte des valeurs NULL dans les JOINs

-- ❌ Problématique - exclut les NULL involontairement
SELECT c.name, COUNT(o.id) as nb_commandes
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status != 'cancelled'
GROUP BY c.name;

-- ✅ Correct
SELECT c.name, COUNT(o.id) as nb_commandes
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id AND o.status != 'cancelled'
GROUP BY c.name;

3. Aliasing insuffisant dans les JOINs multiples

-- ❌ Ambigu avec plusieurs tables
SELECT id, created_at, amount
FROM orders
JOIN customers ON orders.customer_id = customers.id
JOIN invoices ON customers.id = invoices.customer_id;

-- ✅ Clair et maintenable
SELECT 
  o.id as order_id,
  o.created_at as order_date,
  o.amount as order_amount,
  c.name as customer_name,
  i.id as invoice_id
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
INNER JOIN invoices i ON c.id = i.customer_id;

Erreurs niveau avancé

1. CTE récursives mal structurées

-- ❌ Risque de boucle infinie
WITH RECURSIVE hierarchy AS (
  SELECT id, parent_id, name, 1 as level
  FROM categories WHERE parent_id IS NULL
  
  UNION ALL
  
  SELECT c.id, c.parent_id, c.name, h.level + 1
  FROM categories c
  JOIN hierarchy h ON c.parent_id = h.id
)
SELECT * FROM hierarchy;

-- ✅ Correct avec limite de profondeur
WITH RECURSIVE hierarchy AS (
  SELECT id, parent_id, name, 1 as level
  FROM categories WHERE parent_id IS NULL
  
  UNION ALL
  
  SELECT c.id, c.parent_id, c.name, h.level + 1
  FROM categories c
  JOIN hierarchy h ON c.parent_id = h.id
  WHERE h.level < 10
)
SELECT * FROM hierarchy;

2. NOT IN avec NULL (logique ternaire SQL)

-- ❌ Retourne toujours zéro ligne si NULL existe dans la sous-requête
SELECT * FROM orders 
WHERE customer_id NOT IN (SELECT customer_id FROM accounts WHERE status = 'inactive');

-- ✅ Utiliser NOT EXISTS (plus sûr)
SELECT * FROM orders o
WHERE NOT EXISTS (
  SELECT 1 FROM accounts a 
  WHERE a.customer_id = o.customer_id 
  AND a.status = 'inactive'
);

3. Oublier l'EXPLAIN dans l'optimisation

-- Avant d'optimiser, analysez le plan d'exécution
EXPLAIN ANALYZE
SELECT customer_id, SUM(amount) as total
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY customer_id;

Tableau comparatif : dialectes SQL les plus testés

Stratégie pendant le test

Les 5 premières minutes

1. Lisez TOUTES les questions rapidement pour évaluer la difficulté
2. Identifiez les questions faciles — commencez par elles pour sécuriser des points
3. Repérez le dialecte SQL utilisé (PostgreSQL, MySQL ?)
4. Vérifiez le schéma des tables disponibles (lisez les structures entièrement)

Gestion du temps

Pour un test de 5 questions en 60 minutes :

Gardez 5 minutes à la fin pour relire et tester.

Pendant la résolution de chaque question

1. Lisez l'énoncé complètement (2 fois si nécessaire)
2. Identifiez les tables nécessaires et les colonnes clés
3. Écrivez la requête progressivement — d'abord le FROM/JOIN, puis le WHERE, le GROUP BY, etc.
4. Testez avec les données d'exemple si la plateforme le permet
5. Vérifiez les cas limites : NULL, doublons, zéros

Exemples concrets par profil candidat

Clara, développeuse full-stack postule pour un Data Analyst chez une fintech. Solides bases en programmation mais SQL perfectible. Elle doit absolument maîtriser les JOINs complexes et les window functions pour calculer des métriques de rétention client. Stratégie recommandée : 3 semaines de préparation intensive sur StrataScratch, section "Finance/Banking", 1h minimum par jour.

Marcus, consultant business avec 5 ans d'expérience Excel/Power BI, vise un Data Developer dans une grande banque. Il connaît les concepts métier mais doit se mettre à niveau sur les CTE et l'optimisation. Stratégie : DataLemur (progression douce, 15j) puis HackerRank (interface type entreprise traditionnelle, 10j).

Léa, ingénieure data senior change de boîte (scale-up → GAFAM). Excellentes compétences techniques mais doit s'adapter au format "live coding" et aux questions algorithmiques. Stratégie : simulations complètes en conditions réelles avec chrono, focus sur la verbalisation du raisonnement, 2 simulations par semaine pendant 4 semaines.

Les erreurs de stratégie à éviter

Erreur 1 : le tri manquant

Beaucoup de tests vérifient l'ordre des résultats. Si la question dit « triez par montant décroissant », ajoutez ORDER BY montant DESC.

Erreur 2 : les types de données

Si on demande un pourcentage, vérifiez que vous retournez un décimal et non un entier :

-- Retourne 0 (division entière en SQL standard)
SELECT COUNT(CASE WHEN statut = 'actif' THEN 1 END) / COUNT(*)

-- Retourne 0.75 (division flottante)
SELECT 100.0 * COUNT(CASE WHEN statut = 'actif' THEN 1 END) / COUNT(*)

Erreur 3 : les alias attendus

Certaines plateformes (HackerRank notamment) vérifient le nom exact des colonnes du résultat. Si la question dit « nommez la colonne total_revenue », utilisez exactement cet alias.

Erreur 4 : les doublons inattendus

Un JOIN peut multiplier les lignes si la relation n'est pas 1:1. Vérifiez avec COUNT(*) si le nombre de lignes est cohérent.

Erreur 5 : la gestion du contexte

En live coding, le recruteur évalue aussi votre communication. Verbalisez votre approche : « Je vais d'abord identifier les tables… puis j'écrirai les JOINs… »

Particularités des tests par secteur d'activité

Secteur bancaire/finance

Les tests privilégient la précision et la conformité réglementaire :

• Gestion rigoureuse des NULL et des arrondis (jusqu'à 2 décimales parfois)
• Transactions et cohérence des données
• Calculs financiers complexes : intérêts composés, VaR, stress testing
• Audit trails : qui a modifié quoi et quand
• Données sensibles : anonymisation, respect de la RGPD

E-commerce/retail

Focus sur les métriques d'acquisition et de conversion :

• Analyses de panier : produits associés, prix moyen, saisonnalité
• Segmentation client : RFM (Recency, Frequency, Monetary), CLV, propensity scoring
• Optimisation logistique : stocks, délais de livraison, retours

Pour ce secteur, notre exercice sur le tunnel de conversion e-commerce vous donnera un avant-goût réaliste des questions posées.

Tech/SaaS

Emphasis sur la performance et l'évolutivité :

• Métriques produit : DAU (Daily Active Users), WAU, MAU, feature adoption
• A/B testing : significance statistique, power analysis, contrôle des variables
• Infrastructure : monitoring, alerting, capacity planning
• Données non-structurées : JSON, texte libre

Particularités selon le profil du candidat

Ressortissants européens (UE/EEE)

Marco, développeur italien visant un poste Data Engineer à Berlin. Bonne maîtrise technique mais doit s'adapter aux spécificités allemandes :

• Tests plus longs (jusqu'à 2h) avec emphasis sur la rigueur
• Documentation obligatoire du code SQL (commentaires détaillés)
• Questions sur la RGPD et anonymisation des données

Stratégie Marco : préparation sur Codility (plateforme européenne type), focus sur la propreté du code et les aspects légaux, simulation en 2h.

Candidats extra-européens

Priya, data scientist indienne postulant en France via visa compétences et talents. Excellente formation technique mais doit prouver son niveau :

• Tests souvent plus difficiles pour justifier le visa
• Emphasis sur les soft skills pendant le live coding (communication claire)
• Questions métier en français (secteur bancaire français, par ex.)

Stratégie Priya : double préparation technique + linguistique, simulations en français avec un mentor, focus sur l'explication verbale.

Validation et suivi post-test

Débrief immédiat (dans les 2h)

Notez pendant que c'est frais :

• Questions sur lesquelles vous étiez à l'aise → points forts à capitaliser
• Questions où vous avez hésité → axes d'amélioration prioritaires
• Erreurs de stratégie : mauvaise gestion du temps, stress sur une question, mauvaise lecture d'énoncé
• Particularités de la plateforme : interface, dialecte SQL, types de validation

Analyse des résultats

Si vous recevez un score ou des commentaires :

Score > 80% : excellent, vous pouvez viser des postes plus seniors ou des entreprises plus exigeantes (GAFAM, scale-ups).

Score 60-80% : bon niveau, travaillez les points faibles identifiés pour gagner 10-15 points et repasser dans 2-3 semaines.

Score < 60% : bases à consolider, prévoir 4-6 semaines de préparation supplémentaires avant le prochain test. Revoyez les fondamentaux sur DataLemur.

Tableau de suivi personnel

Que faire si vous ne savez pas résoudre une question

1. Ne restez pas bloqué — passez à la question suivante après 5 minutes d'essai
2. Écrivez ce que vous pouvez — une requête partiellement correcte obtient souvent des points
3. Documentez votre logique — même en commentaires : "Ici je joindrais customers"
4. Revenez-y à la fin si vous avez du temps

-- Exemple : vous êtes bloqué sur une window function
-- Écrivez quand même le squelette

WITH base_data AS (
  SELECT customer_id, order_date, amount
  FROM orders
  WHERE order_date >= '2024-01-01'
)
SELECT 
  customer_id,
  order_date,
  amount,
  -- À FAIRE : window function ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date)
  SUM(amount) OVER (PARTITION BY customer_id) as total_par_client
FROM base_data;

Ressources et outils de pratique par niveau

Débutant (0-6 mois SQL)

• DataLemur : commencez par Easy (50 exercices)
• Tempo SQL : micro-leçons + exercices
• Notre guide : les 10 requêtes SQL indispensables

Temps recommandé : 4-6 semaines, 5h/semaine

Intermédiaire (6-18 mois)

• StrataScratch : Medium (80+ exercices)
• HackerRank : certains tests faciles et moyens
• Nos exercices : le guide avancé des window functions

Temps recommandé : 3-4 semaines, 7h/semaine

Avancé (18+ mois)

• StrataScratch : Hard (vrais entretiens FAANG)
• Codility : tests complets
• Système et optimisation : EXPLAIN ANALYZE en profondeur

Temps recommandé : 2-3 semaines, 10h/semaine incluant les simulations en live

Questions fréquentes

Combien de temps faut-il pour se préparer ?

Débutant complet : 4-8 semaines de 5h/semaine | Débutant avec bases : 2-3 semaines | Intermédiaire : 10-15 jours | Avancé : 5-7 jours.

PostgreSQL et MySQL : c'est pareil ?

Non. Les différences principales : dates (DATE_TRUNC vs DATE_FORMAT), strings (|| vs CONCAT), window functions (syntaxe identique généralement). Conseil : maîtrisez PostgreSQL (plus courant en interviews), puis adaptez à MySQL sur les détails spécifiques.

Window functions : par où commencer ?

Commencez par ROW_NUMBER(), puis RANK(), puis SUM() OVER (...). Pratiquez d'abord sans PARTITION, puis avec. Notre guide complet les couvre dans cet ordre : fonctions fenêtre SQL.

Comment gérer le stress pendant le test en live ?

Verbalisez votre réflexion (rassure le recruteur), posez des questions si l'énoncé est flou, notez le schéma avant de coder. Rappel : 30-40% du temps à comprendre, 60-70% à coder.

Faut-il apprendre les transactions SQL ?

Senior/Data Engineer : oui, c'est possible (ACID, isolation levels). Pour Junior/Analyst : très rare mais bon à connaitre en contexte de take-home. Maîtrisez d'abord JOINs et window functions.

Quelle plateforme pour se préparer si je passe chez X ?

Impossible de savoir en avance. Stratégie universelle : maîtrisez les fondamentaux sur 2 plateformes (ex : DataLemur + StrataScratch), vous serez prêt peu importe celle utilisée réellement.

Combien de points faut-il pour réussir ?

Généralement 70-80% = seuil de passage | 80%+ = très bon signal | 90%+ = excellent. Mais certaines entreprises aiment les exigences baissent à 60% si vous justifiez bien. Demandez toujours votre score.