Phuong Nguyen, Programme Accélérateur Projet Portfolio | 2.7K lecteurs de ma newsletter pour progresser en data | Data Analyst Freelance, recently posted something that made me stop scrolling: "Les exercices SQL qu'on trouve partout manquent de contexte métier réel. Vous apprenez des commandes. Pas comment les utiliser pour répondre à de vraies questions business."

Je vois exactement ce qu'il veut dire. On peut faire des dizaines d'exercices sur SELECT, JOIN et GROUP BY, et pourtant rester bloqué quand un responsable métier arrive avec une demande du type: "On perd des clients, tu peux regarder?" Entre connaître la syntaxe et produire une analyse utile, il y a un fossé. Et ce fossé, c'est le contexte.

Dans son post, Phuong partage aussi des pain points très concrets:

"Les exercices manquent de contexte métier concret"
"Je ne sais pas comment on utilise le SQL en vrai"
"Comment je passe de "je connais la syntaxe SQL" à "je sais construire des analyses ?""

Je vais développer cette idée comme si on continuait la discussion: à quoi ressemble, en pratique, du SQL "avec impact business" et comment s'entraîner pour y arriver.

Le problème: la plupart des exercices SQL entraînent la mécanique, pas la pensée

Les plateformes d'exercices font souvent la même chose: elles vous donnent une table (ou deux), une consigne précise, et une réponse attendue. C'est utile pour apprendre les bases. Mais dans un environnement réel, on ne vous donne presque jamais:

une question bien cadrée
le bon grain de données
une définition unique de chaque KPI
une table propre et documentée

En entreprise, le SQL sert rarement à "afficher des lignes". Il sert à décider. Donc la vraie compétence n'est pas seulement "écrire une requête", mais enchaîner un raisonnement: comprendre le besoin, traduire en métriques, choisir les sources, gérer les ambiguïtés, vérifier la qualité, puis raconter le résultat.

"Vous verrez comment penser, pas juste comment taper la syntaxe."

C'est exactement le bon objectif.

Ce que veut dire "utiliser le SQL en vrai"

Quand Phuong dit "Je ne sais pas comment on utilise le SQL en vrai", je l'interprète comme: "Je ne sais pas comment une équipe data s'y prend pour transformer une question floue en décision."

Dans un contexte réel, un flux de travail ressemble plus à ça:

Clarifier la question business (souvent vague)
Poser des définitions (période, population, segmentation)
Identifier les tables pertinentes et leurs limites
Construire une première requête simple (baseline)
Itérer, valider, contrôler les biais
Produire un résultat actionnable (pas juste un tableau)

Le SQL n'est que le moteur. La valeur est dans le cadrage et l'interprétation.

Passer de la syntaxe aux analyses: le pont en 3 étapes

Phuong pose la question clé: comment passer de "je connais la syntaxe" à "je sais construire des analyses". Voici un pont très opérationnel.

1) Transformer une demande floue en question mesurable

Exemple typique: "Les ventes baissent, tu peux analyser?"

Avant d'écrire la moindre requête, je réponds par des questions de cadrage:

Qu'est-ce qu'on appelle "baisse" (CA, volume, marge)?
Sur quelle période et par rapport à quel benchmark (mois précédent, N-1, moyenne 12 mois)?
Sur quel périmètre (pays, canal, gamme, nouveaux vs existants)?
Est-ce qu'on cherche une explication, une alerte, ou une décision immédiate?

Le but est de convertir une phrase en hypothèse testable.

Un bon signal: si vous pouvez écrire la définition exacte du KPI sur une ligne, votre SQL sera plus simple.

2) Définir les métriques et les dimensions avant la requête

Une analyse, c'est souvent: un KPI + une segmentation + une période.

Par exemple:

KPI: taux de rétention à 30 jours
Dimensions: source d'acquisition, plan tarifaire, cohorte d'inscription
Période: 8 dernières semaines

Si vous sautez cette étape, vous allez bricoler une requête qui "marche" mais qui ne répond pas à la vraie question.

C'est là que beaucoup d'exercices SQL échouent: ils vous donnent déjà les dimensions et le KPI implicite. Dans la vraie vie, c'est à vous de les expliciter.

3) Écrire du SQL orienté décision (et pas seulement orienté résultat)

Concrètement, du SQL orienté business ressemble souvent à:

une requête lisible (CTE, noms clairs)
des filtres justifiés (période, exclusions)
des contrôles qualité (doublons, valeurs manquantes, outliers)
des comparaisons (avant vs après, segment A vs B)
une trace des choix (commentaires, définitions)

Un mini-pattern utile: commencer par une baseline, puis ajouter des découpes.

Baseline: "Quel est le KPI global?"
Segmentation: "Où ça bouge?"
Diagnostic: "Qu'est-ce qui explique l'écart?"

Ce chemin correspond bien à ce que Phuong promet: "Vous montrer le chemin complet: du problème à la solution à l'impact".

Exemple concret: de "on perd des clients" à un insight actionnable

Imaginons une entreprise SaaS. Le responsable succès client dit: "On perd des clients. Est-ce que c'est un problème de produit?"

On peut transformer ça en question mesurable:

KPI: churn mensuel (logo churn ou revenue churn)
Définition: client churn = compte actif le mois M-1 et inactif le mois M
Période: 6 derniers mois
Segments: plan, ancienneté, taille, pays, canal d'acquisition

Ensuite, on construit une analyse en escalier:

Étape 1: churn global par mois (tendance)
Étape 2: churn par plan (où est la casse?)
Étape 3: churn par ancienneté (early churn vs churn tardif)
Étape 4: corrélation avec l'usage produit (ex: événements clés)

L'insight actionnable ne sera pas "le churn a augmenté". Ce sera plutôt:

"Le churn augmente surtout sur le plan Basic, chez les nouveaux clients, après 14 jours sans activer la fonctionnalité X."

Et l'impact business devient clair:

améliorer l'onboarding
déclencher des séquences proactives
revoir la promesse marketing du plan Basic

Le SQL est indispensable, mais la valeur est dans la logique du diagnostic.

Les bonnes pratiques SQL qui comptent vraiment (quand il y a un enjeu business)

Phuong mentionne aussi: "Apprendre la syntaxe SQL et les bonnes pratiques au passage." Dans un contexte pro, certaines pratiques font une différence immédiate.

Lisibilité et maintenance

Utiliser des CTE (WITH) pour raconter l'histoire
Nommer les colonnes calculées de manière explicite
Ajouter des commentaires sur les définitions KPI

Fiabilité des chiffres

Vérifier les niveaux de granularité avant de JOIN
Contrôler les doublons (COUNT(*) vs COUNT(DISTINCT id))
Traiter explicitement les NULL

Reproductibilité

Paramétrer les dates (ex: 30 derniers jours)
Sauvegarder les requêtes avec contexte (ticket, hypothèse, version)

Ces points paraissent "non techniques". Pourtant, c'est ce qui fait de vous la personne dont l'équipe peut dépendre.

S'entraîner avec du contexte: la méthode la plus rapide

Si vous avez l'impression, comme le décrit Phuong, que votre SQL est limité ou que vous ne savez pas par où commencer, la meilleure méthode d'entraînement n'est pas: plus d'exercices isolés.

C'est: des mini-projets guidés avec une question business, des données imparfaites, et une attente de décision.

Voici un format simple à reproduire en autonomie:

Choisir un cas d'usage (churn, panier moyen, acquisition, fraude, logistique)
Écrire la question business en une phrase
Définir 1 KPI et 3 segments
Écrire 3 requêtes maximum:
- baseline
- segmentation
- explication
Conclure en 5 lignes: insight, cause probable, action recommandée, risque, next step

C'est ce dernier bloc qui transforme un "SQL correct" en "analyse utile".

Conclusion: le SQL n'est pas le but, c'est le levier

Je reviens à la phrase de Phuong Nguyen: "Vous apprenez des commandes. Pas comment les utiliser pour répondre à de vraies questions business." Tant qu'on s'entraîne sans contexte, on progresse surtout en grammaire. Dès qu'on ajoute une vraie question, des définitions, et une contrainte d'impact, on progresse en pensée analytique.

Si votre objectif est de devenir la personne qui "résout les problématiques" et pas seulement la personne qui "écrit des requêtes", alors la compétence à construire est celle-ci: relier une question floue à une décision claire, avec un SQL fiable et lisible.

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 →