Quel projet SQL choisir pour son portfolio data ?

Un projet SQL utile doit prouver que vous savez nettoyer, explorer, relier les données au business et expliquer vos choix. Je vous montre les projets qui parlent vraiment à un recruteur : churn e-commerce, data warehouse, ventes, banque et santé.

Pourquoi un projet SQL doit partir du business ?

Un bon projet SQL ne prouve pas que je sais écrire un SELECT. Il prouve que je sais partir d’un problème métier, utiliser les données proprement, puis arriver à une décision. C’est ça qui intéresse un recruteur ou un manager data. Pas une démonstration de syntaxe hors-sol.

Je vois beaucoup de portfolios SQL qui se ressemblent. On ouvre un dataset, on fait un SELECT, deux JOIN, un GROUP BY, parfois une CTE, c’est-à-dire une requête temporaire qu’on nomme pour rendre le SQL plus lisible, puis ça s’arrête là. Techniquement ce n’est pas mauvais. Mais business parlant, on ne sait pas quoi en faire.

Ce qui change tout, c’est le point de départ. Une vraie question. Par exemple : Quels clients risquent de partir ? Quels produits tirent la marge vers le bas ? Quelle région commerciale décroche ? À partir de là, le SQL devient un outil d’analyse, pas juste un exercice.

Dans un projet SQL solide, je veux voir plusieurs choses très simples, mais rarement bien reliées :

• Une problématique claire, formulée comme une vraie question business.
• Un jeu de données compréhensible, avec ses tables, ses champs et ses limites.
• Des choix de nettoyage assumés, comme la gestion des valeurs manquantes, des doublons ou des dates incohérentes.
• Des requêtes lisibles, pas forcément compliquées, mais faciles à suivre.
• Des indicateurs utiles, comme le taux de churn, le panier moyen, la marge, la fréquence d’achat ou le délai de conversion.
• Une lecture business, avec ce que les chiffres veulent dire concrètement.
• Une visualisation simple si possible, même un graphique basique, tant qu’il aide à comprendre.

Découvrez égalementComment réussir une étude de cas data science ?

Un projet doit raconter une décision. Pas juste afficher une table de résultats. Si je calcule un taux de rétention client, je dois expliquer ce qu’on peut faire avec. Relancer certains clients. Ajuster une offre. Prioriser un segment. Couper une campagne qui ne marche pas.

Sur le terrain, j’ai souvent vu des profils techniquement bons perdre l’attention parce qu’ils ne reliaient jamais leurs requêtes à une action concrète. À l’inverse, un projet plus simple, avec trois bons indicateurs et une recommandation claire, crée beaucoup plus de confiance. Parce qu’on comprend comment la personne pense.

Les projets suivants couvrent plusieurs situations réelles : fidélisation client, architecture data, pilotage commercial, segmentation financière et analyse sectorielle santé. C’est là que SQL devient vraiment intéressant.

Comment analyser le churn e-commerce ?

Analyser le churn e-commerce consiste à repérer les profils de clients qui arrêtent d’acheter et les signaux qui expliquent cet abandon. Le churn, c’est juste ça : un client qui était actif, puis qui disparaît. Et dans un business e-commerce, ça coûte souvent moins cher de retenir un client que d’en recruter un nouveau.

Sur ce type de projet, je regarde d’abord les causes possibles. Une plainte récente, une fréquence de commande qui baisse, une mauvaise satisfaction, un moyen de paiement peu pratique, l’usage ou non de coupons, l’ancienneté client, ou simplement trop de jours depuis la dernière commande. J’ai déjà vu un cas où les clients ne partaient pas à cause du prix, mais parce que les livraisons généraient trop de réclamations. Sans analyse, l’équipe marketing poussait juste plus de promos. Mauvais levier.

Découvrez égalementComment l'analyse de données améliore l'engagement ?

Je commence souvent par le taux de churn global. Ça donne le point de départ.

SELECT
  COUNT(*) AS total_clients,
  SUM(CASE WHEN churn = 1 THEN 1 ELSE 0 END) AS clients_churnes,
  ROUND(100.0 * SUM(CASE WHEN churn = 1 THEN 1 ELSE 0 END) / COUNT(*), 2) AS taux_churn
FROM customers;

Ensuite, je compare les clients churnés et non churnés. Là, SQL devient très utile parce qu’on peut agréger vite, avec COUNT et AVG, pour voir les écarts.

SELECT
  churn,
  COUNT(*) AS nb_clients,
  AVG(satisfaction_score) AS satisfaction_moyenne,
  AVG(order_frequency) AS frequence_moyenne,
  AVG(days_since_last_order) AS jours_depuis_derniere_commande
FROM customers
GROUP BY churn;

Je segmente aussi les clients avec CASE WHEN. CASE WHEN sert à créer des catégories lisibles à partir de valeurs brutes. Par exemple, transformer une ancienneté en “nouveau client”, “client installé”, “client fidèle”.

SELECT
  CASE
    WHEN tenure_months < 6 THEN 'Nouveau'
    WHEN tenure_months BETWEEN 6 AND 24 THEN 'Installe'
    ELSE 'Fidele'
  END AS segment_anciennete,
  COUNT(*) AS nb_clients,
  AVG(churn) AS taux_churn
FROM customers
GROUP BY segment_anciennete;

Après ça, je zoome sur les signaux actionnables. Les plaintes, les coupons, les moyens de paiement. C’est là que le projet devient business, pas juste technique.

SELECT
  payment_method,
  used_coupon,
  COUNT(*) AS nb_clients,
  ROUND(100.0 * AVG(churn), 2) AS taux_churn
FROM customers
WHERE order_frequency > 0
GROUP BY payment_method, used_coupon;

La vraie valeur, c’est ce qu’on fait derrière. Relancer les clients inactifs avant qu’ils partent. Surveiller les plaintes dans les 30 jours après achat. Adapter les coupons aux segments qui réagissent vraiment. Prioriser les clients à forte valeur, parce qu’un client rentable qui churn n’a pas le même impact qu’un petit acheteur occasionnel.

Découvrez égalementComment analyser des séries temporelles Python ?

C’est un excellent projet de portfolio parce qu’il montre trois compétences en même temps : analyse descriptive, segmentation client, et recommandations concrètes. Vous ne montrez pas juste que vous savez écrire du SQL. Vous montrez que vous savez transformer une table clients en décisions utiles.

Comment construire un data warehouse SQL ?

Construire un data warehouse SQL, c’est montrer qu’on sait organiser des données brutes pour produire des tables fiables, propres et exploitables par le business. Pour un portfolio data, c’est un très bon signal, parce qu’on n’est plus juste sur “je sais faire des requêtes”. On montre qu’on comprend comment les données circulent dans un vrai système.

Ce projet est plus orienté data engineering que pure analyse. L’idée, c’est de partir de fichiers ou tables brutes, puis de construire une architecture simple en trois couches : Bronze, Silver, Gold. Bronze garde la donnée brute. Silver nettoie et standardise. Gold produit des tables métier prêtes pour le reporting. C’est exactement le genre de logique qu’on retrouve dans beaucoup d’équipes data.

Dans ce projet, je ferais apparaître clairement plusieurs compétences :

• Pipelines ETL : Extraire, transformer et charger les données dans les bonnes tables.
• Nettoyage : Gérer les doublons, les valeurs nulles, les formats de dates, les erreurs de typage.
• Modélisation : Créer des tables de faits et des dimensions.
• Schéma en étoile : Une table centrale, par exemple les ventes, reliée à des dimensions clients, produits, dates et régions.
• Reporting SQL : Produire des requêtes utiles pour suivre le chiffre d’affaires, les volumes ou la performance par segment.

Un exemple simple fonctionne très bien. Je crée une table de faits fact_orders avec les commandes, les montants, les quantités et les clés vers les dimensions. Puis des tables dim_customers, dim_products, dim_dates et dim_regions. Derrière, je peux sortir des requêtes comme celle-ci :

SELECT
  d.month_name,
  r.region_name,
  SUM(f.revenue) AS total_revenue,
  COUNT(DISTINCT f.order_id) AS order_volume
FROM fact_orders f
JOIN dim_dates d ON f.date_id = d.date_id
JOIN dim_regions r ON f.region_id = r.region_id
GROUP BY d.month_name, r.region_name
ORDER BY total_revenue DESC;

Dans le portfolio, je documente le flux de données, les choix de modélisation, les règles de nettoyage, les limites du dataset, les requêtes principales et les résultats obtenus. Un recruteur doit comprendre mon raisonnement sans devoir ouvrir chaque ligne de SQL. C’est souvent là que les bons projets se distinguent, j’ai déjà vu des portfolios avec du code correct, mais impossibles à lire côté logique métier.

Comment transformer les ventes en décisions ?

Une analyse des ventes sert à identifier ce qui génère le chiffre d’affaires, quand ça progresse ou ralentit, et quels clients ou produits méritent l’attention. C’est un projet SQL simple en apparence, mais très parlant dans un portfolio, parce qu’il colle à une vraie question business : où est l’argent, et qu’est-ce qu’on fait maintenant ?

Les questions à traiter sont classiques, et justement c’est ça qui les rend utiles :

• Quels produits génèrent le plus de revenus ?
• Comment les ventes évoluent dans le temps ?
• Quels groupes de clients dépensent le plus ?
• Quelles périodes montrent une saisonnalité ?
• Quels segments semblent sous-performer ?

Côté SQL, je veux montrer que je sais relier des tables clients, commandes et produits avec des jointures. Je veux aussi montrer des agrégations avec SUM pour additionner le chiffre d’affaires, COUNT pour compter les commandes, des filtres, des tris avec ORDER BY, des fonctions de date, et des groupements par mois ou trimestre. Le panier moyen est aussi très utile : chiffre d’affaires divisé par nombre de commandes.

SELECT
  p.product_name,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM order_items oi
JOIN products p ON p.product_id = oi.product_id
GROUP BY p.product_name
ORDER BY revenue DESC;

Cette requête montre les produits qui tirent le chiffre d’affaires. Si un produit représente une grosse part des ventes, il mérite d’être protégé, mieux stocké, ou mis en avant.

SELECT
  DATE_TRUNC('month', o.order_date) AS month,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
GROUP BY month
ORDER BY month;

Ici, je lis la tendance. Si le chiffre d’affaires monte, ralentit ou chute, je peux relier ça à une campagne, une saison, une rupture stock, ou un changement de prix.

SELECT
  c.customer_name,
  COUNT(DISTINCT o.order_id) AS orders_count,
  SUM(oi.quantity * oi.unit_price) AS total_spent
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id = o.order_id
GROUP BY c.customer_name
ORDER BY total_spent DESC
LIMIT 10;

Cette requête sort les meilleurs clients. C’est très concret pour une équipe commerciale : qui fidéliser, qui relancer, qui traiter en priorité.

SELECT
  DATE_TRUNC('quarter', o.order_date) AS quarter,
  SUM(oi.quantity * oi.unit_price) AS revenue,
  SUM(oi.quantity * oi.unit_price) / COUNT(DISTINCT o.order_id) AS avg_order_value
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
GROUP BY quarter
ORDER BY quarter;

Là, je regarde la saisonnalité et le panier moyen. Si le chiffre d’affaires baisse mais que le panier moyen reste stable, le problème vient peut-être du volume de commandes, pas de la valeur des clients.

Dans le portfolio, je présenterais les requêtes, puis un tableau de synthèse ou une visualisation simple. Pas besoin d’un dashboard énorme. L’important, c’est le message : ce produit tire la croissance, ce segment ralentit, cette période mérite une action commerciale.

Honnêtement, ce projet paraît basique. Mais bien raconté, il est très fort. Presque toutes les entreprises doivent piloter leurs ventes, et elles cherchent surtout des profils capables de transformer des lignes de données en décisions claires.

Quels projets SQL pour banque et santé ?

Les projets banque et santé sont utiles parce qu’ils montrent que je sais adapter SQL à des secteurs où les indicateurs, les risques et les décisions sont très structurés. C’est exactement ce que recherchent beaucoup d’équipes data : quelqu’un qui ne fait pas juste des requêtes, mais qui comprend ce qu’il mesure.

Sur la partie bancaire, je partirais sur une segmentation clientèle avec un jeu de données simulé. L’objectif est clair : identifier les clients haute valeur, repérer les comptes actifs et dormants, analyser les motifs de transaction, comparer la performance régionale. Ça permet de montrer des CTE, c’est-à-dire des requêtes temporaires lisibles, des jointures, des agrégations, des fonctions fenêtrées pour comparer des lignes entre elles, du ranking, et une vraie logique de segmentation.

WITH client_value AS (
  SELECT
    c.customer_id,
    c.region,
    SUM(t.amount) AS total_value,
    COUNT(t.transaction_id) AS transaction_count,
    MAX(t.transaction_date) AS last_transaction_date
  FROM customers c
  JOIN accounts a ON c.customer_id = a.customer_id
  JOIN transactions t ON a.account_id = t.account_id
  GROUP BY c.customer_id, c.region
)
SELECT
  customer_id,
  region,
  total_value,
  RANK() OVER (ORDER BY total_value DESC) AS value_rank,
  CASE
    WHEN last_transaction_date < CURRENT_DATE - INTERVAL '180 days' THEN 'Dormant'
    WHEN transaction_count >= 50 THEN 'High activity'
    ELSE 'Standard'
  END AS customer_segment
FROM client_value;

SELECT
  region,
  SUM(amount) AS regional_revenue,
  RANK() OVER (ORDER BY SUM(amount) DESC) AS region_rank
FROM customers c
JOIN accounts a ON c.customer_id = a.customer_id
JOIN transactions t ON a.account_id = t.account_id
GROUP BY region;

Pour la santé, je choisirais une analyse de données patient. Là, je regarde les pathologies, les hôpitaux, les assureurs, les types d’admission, les montants facturés, la prévalence, l’activité hospitalière et les coûts. Même avec un dataset public ou simulé, ça montre une lecture métier plus fine. J’ai vu des recruteurs accrocher là-dessus, parce qu’on sent vite si la personne comprend les indicateurs ou si elle empile juste des GROUP BY.

SELECT
  hospital_name,
  diagnosis,
  admission_type,
  COUNT(*) AS patient_count,
  AVG(billing_amount) AS avg_billing,
  SUM(billing_amount) AS total_billing
FROM patient_records
WHERE discharge_date IS NOT NULL
GROUP BY hospital_name, diagnosis, admission_type;

La banque parle très bien aux fintechs, à l’analytics financier et au pilotage client. La santé montre une capacité à manipuler des données sensibles en lecture métier, avec des indicateurs propres pour un tableau de bord.

Et maintenant vous construisez lequel ?

Le bon projet SQL n’est pas forcément le plus compliqué. C’est celui qui montre clairement comment vous partez d’une donnée brute pour arriver à une décision. Le churn e-commerce prouve votre capacité à travailler sur la rétention. Le data warehouse montre votre compréhension des systèmes data. Les ventes parlent directement business. La banque et la santé ajoutent une dimension sectorielle intéressante. Si je devais choisir, je privilégierais un projet bien documenté, avec des requêtes propres et des recommandations simples. Le bénéfice pour vous est clair : un portfolio plus crédible, plus lisible, et beaucoup plus convaincant.

FAQ

• Quel est le meilleur projet SQL pour débuter un portfolio data ?
  Je commencerais par une analyse des ventes ou du churn e-commerce. C’est concret, facile à comprendre pour un recruteur, et ça permet de montrer des compétences solides : jointures, agrégations, filtres, dates, segmentation et recommandations business.
• Faut-il absolument créer un data warehouse pour se démarquer ?
  Pas forcément. Un data warehouse SQL est très fort si vous visez des rôles plus orientés analytics engineering ou data engineering. Pour un poste d’analyste, un projet business bien expliqué peut suffire. L’idéal, c’est d’avoir les deux à terme.
• Quelles compétences SQL faut-il montrer dans un portfolio ?
  Il faut montrer les bases utiles en contexte réel : GROUP BY, JOIN, CASE WHEN, filtres, agrégations, fonctions de date, CTE, fonctions fenêtrées et ranking. Mais surtout, il faut expliquer ce que chaque requête apporte à l’analyse.
• Un projet SQL doit-il inclure des visualisations ?
  Ce n’est pas obligatoire, mais c’est très utile. Une requête donne le résultat, une visualisation aide à le comprendre vite. Même un graphique simple ou un tableau de synthèse peut rendre le projet beaucoup plus lisible.
• Comment rendre un projet SQL plus professionnel ?
  Documentez la problématique, les données utilisées, les choix de nettoyage, les requêtes principales, les indicateurs et les recommandations. Je conseille aussi d’ajouter une courte conclusion business. C’est souvent ça qui fait la différence entre un exercice SQL et un vrai projet data.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes data, marketing et business chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Mon sujet, c’est simple : transformer les données en décisions utiles. Si vous voulez structurer vos projets data, automatiser vos analyses ou former vos équipes, contactez-moi.

Franck Scandolera

⭐ 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é (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, 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.