Les candidats échouent souvent sur six concepts SQL clés en entretien data, comme les fonctions fenêtre, HAVING vs WHERE, auto-jointures, CTE vs sous-requêtes, gestion des NULL, et déduplication via GROUP BY. Comprendre ces pièges booste significativement vos chances.
3 principaux points à retenir.
- Les fonctions fenêtre nécessitent un ORDER BY précis pour un résultat fiable.
- HAVING filtre après agrégation; WHERE, avant ; confondez-les et ça coince.
- Utiliser CTE simplifie grandement la lisibilité comparé aux sous-requêtes imbriquées.
Pourquoi les fonctions fenêtre échouent-elles souvent en entretien ?
Les fonctions fenêtre en SQL, c’est un peu comme une recette de cuisine : tout le monde connaît les ingrédients, mais trouver l’équilibre dans le dosage, c’est une autre paire de manches. Dans le cadre des entretiens data, beaucoup de candidats se retrouvent piégés par un détail souvent sous-estimé : l’importance du ORDER BY. Pourquoi ? Parce que lorsque l’on omet cette clause cruciale, les résultats se mettent à danser comme des feux follets, rendant toute analyse complètement aléatoire.
Pour comprendre cette subtilité, plongeons dans un exemple pratique avec la fonction LAG(). Imaginons que l’on souhaite récupérer la valeur précédente d’une colonne dans un ensemble de données ordonné. Si l’on écrit une requête comme suit :
SELECT
id,
valeur,
LAG(valeur) OVER (PARTITION BY categorie) AS valeur_precedente
FROM
ventes;Sans le ORDER BY, le résultat ne garantit absolument rien : une valeur précédente pourrait tout aussi bien être une donnée d’un autre ordre de votre dataset. Le chaos total, donc. Au lieu de cela, une requête correctement définie ressemblerait à ceci :
SELECT
id,
valeur,
LAG(valeur) OVER (PARTITION BY categorie ORDER BY date_vente) AS valeur_precedente
FROM
ventes;Dans cet exemple, l’absence du ORDER BY pourrait renvoyer des résultats qui ne kissent même pas la réalité des données. Plusieurs systèmes de gestion de bases de données (SGBD) vous avertiront si vous omettez cette clause, notamment SQL Server, tandis que d’autres, comme PostgreSQL, peuvent passer l’éponge sur ce détail. Mais dans les deux cas, le résultat risque d’être explosif : vos analyses pourraient se baser sur un résultat farfelu.
Pour résumer, comprendre l’utilisation des ORDER BY avec les fonctions fenêtre est primordial. Cela assure que vos résultats soient cohérents et exploitables. Quand vous faites des requêtes, gardez toujours la vérification à l’esprit : chaque groupe doit être ordonné pour que chaque valeur précédente ait réellement une signification. En somme, un bon usage des fonctions fenêtre peut transformer vous en un virtuose des données plutôt qu’un jongleur aveugle ! Et pour d’autres questions sur SQL, n’hésitez pas à consulter ceci.
Comment différencier WHERE et HAVING pour filtrer en SQL ?
Quand on se lance dans le SQL, il y a des pièges à éviter, sinon on finit comme un poisson hors de l’eau. Parlons ici de l’ordre d’exécution des requêtes SQL, un point crucial qui peut passer inaperçu. Comprendre cet ordre, c’est un peu comme connaître la recette d’un bon plat : si tu mets les ingrédients en désordre, tu n’obtiendras pas ce que tu espères.
Voici l’ordre d’exécution, basique mais essentiel :
- FROM
- WHERE
- GROUP BY
- HAVING
- SELECT
- ORDER BY
Alors pourquoi cette structure est-elle si importante ? La clause WHERE est utilisée pour filtrer les lignes avant l’agrégation, tandis que HAVING est prévu pour filtrer les résultats après que les données ont été regroupées et agrégées. C’est là qu’une erreur classique se glisse dans les entretiens data, comme utiliser MIN(points) dans la clause WHERE. Par exemple :
SELECT joueur, MIN(points)
FROM scores
WHERE MIN(points) > 10
GROUP BY joueur;Cette requête est incorrecte ! La fonction d’agrégation MIN(points) ne peut pas être utilisée ainsi dans la clause WHERE. Cela retournera une erreur ou simplement ne renverra pas les résultats escomptés.
La requête correcte serait :
SELECT joueur, MIN(points)
FROM scores
GROUP BY joueur
HAVING MIN(points) > 10;Cette fois, on filtre correctement après l’agrégation, ce qui garantit que seules les lignes pertinentes sont retournées. Ignorer cette distinction peut mener à des résultats erronés, à des décisions basées sur des données corrompues, et finalement à des migraines pour les analystes qui peinent à comprendre d’où vient l’erreur. C’est un vrai casse-tête, non ?
Ne sous-estime jamais la puissance de ces détails. Chaque clause a son rôle à jouer dans cette grande symphonie qu’est SQL, et la maîtrise de leur utilisation peut faire la différence entre une analyse éclairée et une compilation de données inutile. Pour creuser encore plus la question, je t’invite à consulter cet article enrichissant : différence entre WHERE et HAVING.
Quand et comment utiliser les auto-jointures en SQL ?
L’auto-jointure, c’est un peu le ninja des jointures SQL : souvent invisibile, mais ô combien efficace ! Imaginez que vous avez une table contenant des données sur les employés avec leur date d’embauche. Pour examiner les évolutions de salaire au fil du temps au sein de la même entreprise, l’auto-jointure devient vite indispensable. C’est une astuce dont on se sert trop peu lors des entretiens. Intentions comportementales, évolution des événements… Une auto-jointure peut les clarifier simplement.
Prenons un exemple classique avec une table employes contenant les colonnes id, nom, salaire et date_embauche. Si l’on veut voir l’évolution des salaires sur deux dates, un étudiant en SQL pourrait tenter d’utiliser une sous-requête corrélée comme ceci :
SELECT e1.nom, e1.salaire AS salaire_initial,
(SELECT salaire FROM employes e2 WHERE e2.date_embauche = '2023-01-01'
AND e1.nom = e2.nom) AS salaire_final
FROM employes e1
WHERE e1.date_embauche = '2020-01-01';Mais là, autant dire qu’on est en train de jongler avec des sous-requêtes compliquées, et la lisibilité en prend un sacré coup. En revanche, si l’on opte pour une auto-jointure, cela devient beaucoup plus fluide :
SELECT e1.nom, e1.salaire AS salaire_initial, e2.salaire AS salaire_final
FROM employes e1
JOIN employes e2 ON e1.nom = e2.nom
WHERE e1.date_embauche = '2020-01-01' AND e2.date_embauche = '2023-01-01';Ah, là on respire ! Avec cette approche, on voit clairement que l’on compare les salaires des employés pour les dates souhaitées, sans la complexité des dessous de la sous-requête. La jointure sur critères de date est également plus efficace, car SQL gère ces relations en parallèle, optimisant le temps d’exécution.
Prenons un autre exemple avec les taux de change. Imaginons une table taux_change contenant devise, montant, date. Pour comparer deux coûts d’une même devise à différentes dates, le tout avec une auto-jointure, on pourrait écrire :
SELECT t1.devise, t1.montant AS montant_initial, t2.montant AS montant_final
FROM taux_change t1
JOIN taux_change t2 ON t1.devise = t2.devise
WHERE t1.date = '2023-01-01' AND t2.date = '2023-12-01';Dans ce dernier exemple, on obtient un tableau clair avec toutes les informations nécessaires pour analyser l’évolution des taux de change, tout en gardant la requête concise et lisible.
L’auto-jointure facilite vraiment les requêtes complexes au niveau temporel, en permettant de comparer les valeurs dans la même table de manière intuitive. Au final, moins de code à gérer, plus de clarté à l’écran, et une efficacité redoutable. La prochaine fois que l’on vous coupera le souffle avec des requêtes alambiquées, n’oubliez pas d’utiliser ce puissant outil qu’est l’auto-jointure.
Pourquoi préférer les CTE aux sous-requêtes imbriquées ?
Quand on parle de SQL, on ne peut pas ignorer la question de la lisibilité et de la maintenance des requêtes. Les sous-requêtes imbriquées, malgré leur usage courant, peuvent vite devenir de véritables nids d’oiseaux, pleins de complicité et d’ornithologie un peu trop poussée. Qui n’a jamais passé des heures à tenter de déchiffrer une sous-requête méga-nidifiée, se demandant ce qui se cache derrière chaque couche ? C’est comme se plonger dans un roman police sans la fin, impossible de saisir qui a fait quoi.
Pour résoudre ce problème, les Common Table Expressions (CTEs) apparaissent comme des super-héros de l’art SQL. Avec leur syntaxe claire et concise, ils permettent de structurer des requêtes complexes en plusieurs étapes, favorisant ainsi la compréhension immédiate et la maintenance de votre code. L’avantage ici, c’est que vous pouvez décomposer des opérations compliquées en parties simples. Par exemple, imaginez que vous souhaitez évaluer les meilleures performances d’acteurs par genre, avec différentes étapes d’agrégation et de classement. Au lieu de vous embourber dans des sous-requêtes, une CTE peut vous rendre la tâche nettement plus agréable.
Voici comment cela se présente :
WITH GenreRank AS (
SELECT Actor, Genre, SUM(Score) AS TotalScore
FROM Movies
GROUP BY Actor, Genre
),
RankedActors AS (
SELECT Actor, Genre, ROW_NUMBER() OVER (PARTITION BY Genre ORDER BY TotalScore DESC) AS Rank
FROM GenreRank
)
SELECT * FROM RankedActors WHERE Rank <= 5;
En comparaison, une version avec des sous-requêtes pourrait ressembler à ceci :
SELECT Actor, Genre,
(SELECT COUNT(*)
FROM (SELECT Actor, Genre, SUM(Score) AS TotalScore FROM Movies
GROUP BY Actor, Genre) AS GenreScores
WHERE GenreScores.Actor = m.Actor) AS Rank
FROM Movies m;
La première version avec les CTE offre une clarté sans pareil, alors que la seconde, emplie de sous-requêtes, laisse souvent le lecteur dans un flou artistique. À la fin de la journée, un code lisible et maintenable se traduit par un gain de productivité, que ce soit lors des entretiens ou en production. Cela vous aide à briller dans votre carrière, prouvant que vous êtes le ninja SQL dont tout le monde a besoin.
| Critère | CTE | Sous-requête |
|---|---|---|
| Lisibilité | Très claire | Confuse |
| Maintenance | Facile | Difficile |
| Performance | Souvent meilleure | Variable |
Comment gérer correctement les NULL en SQL ?
Les NULL en SQL, parlons-en. Que signifie réellement cette notion ? En gros, NULL représente l'absence de valeur. Non, ce n'est pas une valeur zéro, ce n'est pas une chaîne vide, c'est le néant ! D'ailleurs, voici une petite astuce : NULL n'est jamais égal à quoi que ce soit. Ça veut dire qu'un NULL n'est même pas égal à un autre NULL. Une bénédiction et une malédiction à la fois pour les analystes de données.
Vous seriez étonné de voir à quel point cette petite spécificité empoisonne la vie des développeurs. Prenons un exemple classique. Imaginez que vous ayez une condition qui vérifie si une valeur est NULL. Si vous écrivez = NULL, une telle condition vous renverra toujours FALSE. La bonne syntaxe, celle qui fait le job, c'est IS NULL. Ça a l'air simple, non ? Pourtant, c’est une des erreurs les plus fréquentes en entretien, et elle peut vous coûter cher !
Mais creusons un peu plus. Imaginez une situation où vous faites une jointure FULL OUTER JOIN. C’est souvent ici que ça se gâte. Quand des valeurs NULL apparaissent et que vous n’utilisez pas COALESCE, ça peut donner des résultats complètement incohérents. Voici un exemple :
SELECT a.id, COALESCE(b.valeur, 'Valeur par défaut') AS valeur
FROM tableA a
FULL OUTER JOIN tableB b ON a.id = b.id;Imaginez que vous omettez le COALESCE :
SELECT a.id, b.valeur
FROM tableA a
FULL OUTER JOIN tableB b ON a.id = b.id;Dans le deuxième cas, si b.valeur est NULL, c’est une information perdue. En revanche, avec le COALESCE, vous avez la possibilité d’afficher une valeur par défaut, rendant vos rapports d’analyse non seulement plus clairs, mais également beaucoup plus fiables.
La gestion des NULL, c’est un vrai enjeu, surtout dans le cadre d’analyses clients. Pensez-y : si vous avez des NULL dans des données de clients, vos résultats d’analyse peuvent être faussés, et par ricochet, vos recommandations stratégiques aussi. Pour éviter la catastrophe, maîtriser les NULL est essentiel. Pour plus de détails, consultez cet article sur les NULL en SQL.
Quelle méthode pour dédoublonner en gardant une ligne complète ?
La problématique du dédoublonnage en SQL est un vrai casse-tête pour beaucoup. En théorie, cela semble simple : on veut extraire une seule ligne par groupe selon un critère, comme la date la plus récente ou la meilleure vente. Mais, surprise ! Utiliser GROUP BY seul ne suffira pas. Pourquoi ? Parce que GROUP BY agrège les données, il ne garde pas l’intégralité d’une ligne. En gros, il vous dit "Voici les résultats résumés", mais vous n’avez pas accès aux détails qui pourraient vous intéresser.
L'une des erreurs classiques est d'essayer d'utiliser GROUP BY avec LIMIT 1. Ce combo peut sembler séduisant à première vue, mais il ne fonctionne pas comme on l'espère pour chaque groupe. Vous risquez de revenir avec un beau désordre, pas vraiment utile pour votre analyse.
Pour réellement obtenir la ligne de référence par groupe, il est essentiel de se tourner vers les fonctions de fenêtre comme RANK() ou ROW_NUMBER(). Ces fonctions, comme leur nom l'indique, vous permettent de “classer” vos enregistrements par groupe. Par exemple, en utilisant RANK(), vous pouvez attribuer un rang à chaque produit vendu par mois, et ainsi déterminer lequel est le plus performant sans perte d'information.
Voici un exemple de requête pour illustrer cela :
SELECT produit_id, vente_date, montant_vente,
RANK() OVER (PARTITION BY MONTH(vente_date) ORDER BY montant_vente DESC) AS rang
FROM ventes
WHERE rang = 1;
Cette requête vous permet de sélectionner le produit le plus vendu pour chaque mois, tout en gardant toutes les colonnes d'informations. Facile non ? Il suffit ensuite d'ajouter le filtre WHERE rang = 1 pour obtenir le résultat souhaité.
Les fonctions de fenêtre comme celles-ci offrent une véritable puissance et flexibilité pour le dédoublonnage. Elles permettent non seulement de traiter des données de manière efficace, mais aussi d'extraire précisément l'information pertinente, sans sacrifier le détail. Finalement, se familiariser avec ces outils transforme l'approche face aux données !
Comment maîtriser ces concepts SQL pour réussir vos entretiens data ?
Ces six concepts SQL—fonctions fenêtre, HAVING versus WHERE, auto-jointures, CTE versus sous-requêtes, gestion des NULL et déduplication rigoureuse—sont des pièges classiques que les candidats ne maîtrisent pas. Les comprendre et pratiquer ces approches vous assure des requêtes plus correctes, lisibles, et performantes, augmentant significativement vos chances en entretien data. En internalisant ces bons réflexes, vous évitez les erreurs embarrassantes et démontrez un vrai savoir-faire opérationnel, indispensable face aux recruteurs exigeants.
FAQ
Qu'est-ce qu'une fonction fenêtre en SQL et pourquoi est-elle difficile ?
Quelle est la différence entre WHERE et HAVING ?
Quand utiliser une auto-jointure plutôt qu'une sous-requête ?
Pourquoi privilégier les Common Table Expressions ?
Comment traiter les valeurs NULL en SQL pour éviter des erreurs ?
A propos de l'auteur
Franck Scandolera, responsable de l'agence webAnalyste et formateur en Analytics Engineer, accompagne depuis plus de dix ans des professionnels dans la maîtrise du SQL, data engineering et automatisation. Expert reconnu en data, je transforme la complexité technique en solutions concrètes et opérationnelles pour les métiers. Concepteur de formations pointues et intervenant en France, Suisse et Belgique, j’aide les experts data à réussir leurs projets et entretiens avec rigueur et pragmatisme.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.