Phuong Nguyen a récemment partagé quelque chose qui m’a fait m’arrêter de scroller : "SQL en 1 heure". Et surtout, il a posé le cadre avec une clarté rare.

SQL en 1 heure

Au programme :

Vous travaillez sur des données typiques d’entreprise, proches de ce que vous verrez en poste.

Vous partez des questions métier, puis vous les traduisez en requêtes SQL. Écrire du SQL sans objectif business ne sert à rien.

Vous apprenez à repérer les subtilités dans une question métier, et à comprendre comment elles changent totalement la requête finale.

Vous découvrez les réflexes et astuces essentiels pour écrire des requêtes plus rapides et plus propres.

Ce qui résonne pour moi, ce n’est pas seulement la promesse du format court. C’est la philosophie derrière : le SQL n’est pas un exercice scolaire, c’est un outil de décision. Et quand on l’aborde par le métier (plutôt que par des requêtes au hasard), on progresse plus vite, on fait moins d’erreurs, et on produit des analyses qui comptent.

Dans cet article, je prolonge ce que Phuong Nguyen décrit, en ajoutant du contexte, des exemples concrets et une méthode simple pour passer d’une question business à une requête SQL propre et performante.

Le point clé de Phuong Nguyen : partir du métier, pas de la requête

Quand Phuong Nguyen écrit : "Écrire du SQL sans objectif business ne sert à rien", il met le doigt sur un piège fréquent. Beaucoup de personnes apprennent SQL comme une liste de fonctions (SELECT, JOIN, GROUP BY), puis cherchent ensuite des problèmes à résoudre. En entreprise, c’est l’inverse : une question apparaît (chute de conversion, hausse des retours, retard logistique), et SQL sert à obtenir une réponse fiable.

Le bonus de cette approche, c’est qu’elle force à clarifier les définitions. Or, la plupart des désaccords en data ne viennent pas de la technique, mais du vocabulaire : qu’est-ce qu’un "client actif" ? une "vente" ? un "mois" ?

Insight : une requête SQL est souvent l’implémentation d’une définition. Si la définition est floue, la requête le sera aussi.

Travailler sur des données d’entreprise : pourquoi ça change tout

Phuong Nguyen insiste sur des "données typiques d’entreprise". C’est essentiel, car les datasets pédagogiques sont souvent trop propres. En vrai, vous aurez :

des valeurs manquantes et des statuts incohérents ("delivered", "Delivered", "DELIV")
des doublons fonctionnels (même client, plusieurs identifiants)
des timestamps en UTC, des fuseaux horaires, des dates de mise à jour
des tables gigantesques et des jointures coûteuses

S’entraîner sur des données réalistes vous apprend deux réflexes :

Valider avant de conclure (compter, comparer, vérifier des échantillons).
Modéliser mentalement le parcours de la donnée (d’où vient-elle, quand est-elle créée, quand est-elle modifiée ?).

Traduire une question business en SQL : une méthode en 5 étapes

Voici la méthode que j’utilise et que j’aurais aimé appliquer plus tôt. Elle colle parfaitement à l’idée de Phuong Nguyen : partir des questions métier.

1) Reformuler la question en une phrase mesurable

Exemple de question : "Est-ce que nos nouveaux clients reviennent ?"

Reformulation mesurable : "Quel est le taux de clients acquis en janvier qui repassent une commande dans les 30 jours ?"

Rien qu’ici, on a ajouté une période (janvier) et une fenêtre (30 jours). Sans ça, vous pouvez écrire 5 requêtes différentes qui auront toutes l’air plausibles.

2) Définir les concepts ambigus

Quelques définitions à verrouiller :

"nouveau client" = première commande validée (ou payée) ?
"revient" = une seconde commande, ou une commande livrée ?
"dans les 30 jours" = 30 x 24h depuis l’achat, ou jusqu’à la fin du mois ?

3) Identifier les tables et les clés

En général : customers, orders, order_items, payments, events.

Décider la granularité : analyse au niveau client ou commande ? Ici, client.

4) Écrire d’abord une requête correcte, ensuite une requête rapide

C’est un point que j’associe aux "réflexes et astuces" cités par Phuong Nguyen. Visez d’abord la vérité (correctness), puis la performance.

5) Tester avec des contrôles simples

Compter le nombre de clients en cohorte
Vérifier quelques clients à la main
Comparer à un KPI existant

Les subtilités métier qui changent totalement la requête

Phuong Nguyen mentionne le fait de "repérer les subtilités" et de voir comment elles transforment la requête finale. Voici 4 subtilités courantes, avec leur impact.

1) "Chiffre d’affaires" : brut, net, reconnu ?

Une question type : "Quel est le CA du mois ?"

Subtilités possibles :

brut (avant remboursements) vs net (après remboursements)
date de commande vs date de paiement vs date de livraison
devise, taxes, remises

Le SQL peut passer d’un simple SUM(amount) à une logique multi-tables avec remboursements, statuts et dates.

2) "Clients actifs" : activité récente ou statut marketing ?

"Actif" peut vouloir dire :

a passé une commande dans les 90 derniers jours
a ouvert un email dans les 30 jours
a au moins une session dans les 14 jours

Même mot, trois sources de données différentes, donc trois requêtes différentes.

3) Dédoublonnage : identifiant technique vs vérité métier

Si un utilisateur a deux comptes, la question "combien de clients" peut dépendre de la règle de déduplication (email, téléphone, device, ou table de mapping).

4) Fenêtres de temps : inclusif, exclusif, fuseaux horaires

"Hier" en SQL peut être faux si vos timestamps sont en UTC et vos équipes en heure locale. Le détail paraît minuscule, mais il crée des écarts quotidiens dans les dashboards.

Réflexes pour des requêtes plus rapides et plus propres

Phuong Nguyen promet des "requêtes plus rapides et plus propres". Voici les réflexes que je considère comme les plus rentables, surtout en contexte entreprise.

Écrire lisible avant d’optimiser

Utiliser des CTE (WITH) pour raconter l’histoire
Nommer clairement les champs calculés
Éviter les SELECT * dans les requêtes finales

Une requête lisible est une requête audit-able. Et en data, l’audit vaut de l’or.

Réduire tôt, joindre ensuite

Filtrer le plus tôt possible (WHERE)
Agréger au bon niveau avant les JOIN
Sélectionner uniquement les colonnes utiles

Sur de gros volumes, c’est souvent la différence entre quelques secondes et plusieurs minutes.

Éviter les pièges classiques de performance

Méfiez-vous des fonctions sur les colonnes dans les filtres (ex : DATE(created_at) = ...)
Vérifier les cardinalités des jointures (1-to-1, 1-to-many)
Utiliser des fenêtres (window functions) quand elles simplifient une logique autrement coûteuse

Ajouter des garde-fous de qualité

Compter avant et après les JOIN
Vérifier l’unicité attendue (par client, par commande)
Tester des cas limites (remboursements, annulations, statuts rares)

Insight : une requête "propre" n’est pas seulement élégante. Elle produit des résultats stables quand les données changent.

Pourquoi "SQL en 1 heure" peut marcher (si l’objectif est clair)

Le format court peut sembler ambitieux, mais il a du sens si l’objectif est bien défini : pratiquer la traduction métier -> SQL, sur des cas réalistes, avec des subtilités volontaires.

En une heure, vous pouvez :

apprendre une démarche reproductible
renforcer des réflexes (validation, définitions, contrôle des jointures)
gagner en vitesse sur les requêtes du quotidien

Et surtout, vous pouvez vous entraîner sur ce qui fait la différence en poste : comprendre la question avant d’écrire la requête.

Une mini-checklist à garder sous la main

La prochaine fois qu’on vous pose une question business, testez cette checklist avant de coder :

Quelle est la métrique exacte ?
Quelle est la période et quel est le fuseau horaire ?
Quelle définition métier se cache derrière les mots (client, vente, actif) ?
Quelle table fait foi et quel statut doit être inclus/exclu ?
Comment vais-je valider le résultat ?

Si vous répondez à ces 5 questions, votre SQL devient naturellement plus juste, plus rapide à écrire, et beaucoup plus utile.

This blog post expands on a viral LinkedIn post by Phuong Nguyen, Programme Accélérateur Projet Portfolio | 2.7K lecteurs de ma newsletter pour progresser en data | Data Analyst Freelance. View the original LinkedIn post →