Bases de données pour business analyste : collaborer avec les développeurs en autonomie

Objectifs pratiques

Dans cette leçon de 15 minutes, tu apprends à nommer avec précision le SGBD, la base, les tables, les lignes et les colonnes de la Boutique Wave/WhatsApp. Tu apprends aussi à dire à quoi sert SQL. C'est la première brique pour parler aux développeurs sans termes flous et sans les ralentir. À la fin, tu auras une fiche de vocabulaire d'une page pour ton Dossier BDD.

Pourquoi c'est utile pour votre objectif

Un business analyste qui dit « la base est lente » ou « il manque une colonne dans la table des commandes » est compris tout de suite. Celui qui dit « le fichier » ou « le système » oblige le développeur à poser des questions. Ce vocabulaire est aussi la base du métier de gestionnaire de base de données. Il te servira pour les solutions où une IA lit des données ou y écrit ses prédictions. Il te servira enfin pour former d'autres personnes.

Les trois termes à ne plus confondre

• SGBD (système de gestion de base de données) : le logiciel qui stocke, protège et sert les données. Exemple : PostgreSQL.
• Base de données : l'ensemble organisé des données d'une application, géré par le SGBD. Exemple : la base boutique.
• SQL : le langage standard pour interroger et modifier les données d'une base relationnelle.

Analogie : le SGBD est le bâtiment avec son gardien, la base est l'archive d'une entreprise, et SQL est la façon de demander un dossier au gardien.

Table, ligne, colonne

• Table : un sujet métier (clients, produits, commandes, paiements, predictions_ia).
• Colonne : un attribut, avec un type (nom, telephone, montant).
• Ligne (ou enregistrement) : une occurrence, par exemple un client précis.

Méthode pas à pas

1. Ouvre la capture d'écran de la boutique et repère le logiciel : c'est le SGBD (PostgreSQL dans notre fil rouge).
2. Repère le nom de la base à laquelle on est connecté (boutique).
3. Choisis une table et donne son sujet métier en une phrase.
4. Entoure une colonne et note son nom et son type probable (texte, nombre, date).
5. Entoure une ligne complète et traduis-la en phrase métier : « Le client X a commandé Y le jour Z ».
6. Écris 3 requêtes possibles en français, par exemple : lister les commandes du jour, compter les clients, calculer le total des paiements Wave de la semaine.
7. Rédige une définition en une phrase pour SGBD, base et SQL.

Exemple concret

Table commandes de la Boutique Wave/WhatsApp : colonnes id, client_id, date_commande, montant, statut. Une ligne : 1042 | 17 | 2025-03-02 | 15000 | payée. Le SGBD est PostgreSQL, la base est boutique, et la table est commandes. Requêtes possibles : lister les commandes impayées, additionner les montants du mois, compter les commandes par client. Le BA dit au développeur : « Dans la table commandes, j'ai besoin d'une colonne canal (WhatsApp ou boutique) ». Il est précis, et le développeur peut chiffrer la demande tout de suite.

Erreurs à éviter

• Dire « la base » pour désigner le logiciel (c'est le SGBD).
• Confondre SQL (le langage) et le SGBD (le logiciel).
• Dire « fichier » ou « onglet » comme dans Excel : une table n'est pas une feuille de calcul, car elle impose des types et des règles.
• Appeler « champ », « colonne » et « ligne » la même chose.

À faire maintenant

Rédige ta fiche de vocabulaire d'une page à partir de la capture de la boutique : 3 définitions en une phrase, 1 table, 1 ligne et 1 colonne identifiées, le SGBD et la base nommés, et 3 requêtes possibles. Pour aller plus loin, parcours le tutoriel PostgreSQL (lien ci-dessous).

Objectifs pratiques

Dans cette leçon de 15 minutes, tu apprends à choisir une clé primaire (PK) et des clés étrangères (FK) pour les tables clients, commandes et paiements de la Boutique Wave/WhatsApp. Tu apprends aussi à prédire ce qui se passe quand on supprime un client. C'est ce qui te permet d'arbitrer avec un développeur sans le freiner : tu arrives avec une proposition justifiée et non un besoin vague. Cela te rapproche de ton objectif de gérer la base d'une solution digitale, y compris celle où une IA lira ou écrira des données.

Pourquoi c'est utile pour votre objectif

Un gestionnaire de base de données doit garantir que les données restent cohérentes. Les PK et FK sont le mécanisme de base pour cela. Si une commande pointe vers un client qui n'existe plus, les rapports sont faux. Une table de prédictions IA qui référence un client ou une commande a le même risque. Savoir poser la bonne question (« que se passe-t-il à la suppression ? ») est un réflexe de BA et de futur DBA.

Méthode pas à pas

1. Liste les tables et leur rôle : clients, commandes, paiements. Une commande appartient à un client. Un paiement appartient à une commande.
2. Choisis la PK de chaque table. Une PK identifie une ligne de façon unique, jamais vide, et stable dans le temps. Pour clients, propose un identifiant technique client_id (entier auto-incrémenté ou UUID).
3. Teste le téléphone comme candidat. Il est unique en apparence, mais un client change de numéro, perd sa SIM, ou partage un numéro familial. Si le téléphone est la PK, il faudrait modifier toutes les commandes liées. On garde donc le téléphone comme colonne normale, avec une contrainte d'unicité si le métier le décide.
4. Pose les FK. commandes.client_id référence clients.client_id. paiements.commande_id référence commandes.commande_id. La FK interdit d'enregistrer une commande pour un client inexistant.
5. Décide du comportement à la suppression (ON DELETE) :

• RESTRICT : la suppression du client est refusée tant qu'il a des commandes. C'est le choix sûr pour des données financières.
• CASCADE : supprimer le client supprime aussi ses commandes, et par effet en chaîne ses paiements. Pratique, mais dangereux : on perd l'historique comptable.

1. Prédis le résultat avant d'exécuter quoi que ce soit, puis écris ta recommandation en 5 lignes pour le développeur.

Exemple concret

Table clients : (1, Awa, 770000001). Table commandes : (101, client_id 1, 15 000 FCFA) et (102, client_id 1, 8 000 FCFA). Table paiements : (900, commande_id 101, Wave).

On exécute la suppression du client 1.

• Avec RESTRICT : la base refuse l'opération avec une erreur de violation de clé étrangère. Rien n'est perdu.
• Avec CASCADE : le client, les commandes 101 et 102 et le paiement 900 disparaissent. Le chiffre d'affaires historique baisse sans trace.

Proposition de BA : RESTRICT sur commandes et paiements, et une colonne statut (actif/archivé) ou date_suppression sur clients pour une désactivation logique.

Erreurs à éviter

• Utiliser le téléphone ou l'e-mail comme PK parce qu'ils « semblent uniques ».
• Oublier que CASCADE se propage en chaîne sur plusieurs tables.
• Confondre unicité (un téléphone ne doit pas être en double) et identité (la PK ne doit jamais changer).
• Décider seul de la règle de suppression : c'est un arbitrage métier, légal (données personnelles) et technique à valider avec le développeur.

À faire maintenant

Rédige 5 lignes d'arbitrage à envoyer au développeur : (1) la PK proposée pour clients et pourquoi ; (2) pourquoi le téléphone seul est risqué ; (3) les FK entre commandes, paiements et clients ; (4) ta règle ON DELETE avec justification ; (5) ta prédiction du résultat de la suppression d'un client ayant des commandes.

Pourquoi cet exercice t'aide\n\nQuand tu discutes d'un modèle de données avec les développeurs, la première question est toujours la même : « une commande, c'est combien de produits ? Un produit, dans combien de commandes ? » Savoir classer les cardinalités (1-1, 1-n, n-n) te permet de poser un besoin précis, de repérer seul quand une table de liaison est nécessaire et de ne pas bloquer l'équipe avec des allers-retours. C'est aussi la base du métier de gestionnaire de base de données et de la conception de tables que l'IA va lire ou dans lesquelles elle écrira ses prédictions.\n\nDurée estimée : 15 minutes.\n\n

Contexte : la Boutique Wave/WhatsApp\n\nUne boutique vend des produits à des clients qui commandent par WhatsApp et paient par Mobile Money. Les tables du fil rouge sont : client, produit, commande, paiement, prediction_ia (par exemple la probabilité qu'un client recommande dans les 30 jours), et profil_client (informations de fidélité, un seul profil par client).\n\n

Rappel de méthode\n\n1. Prends deux tables A et B.\n2. Demande : « Pour 1 ligne de A, combien de lignes de B au maximum ? » puis l'inverse.\n3. Si c'est 1 et 1 : relation 1-1. Si c'est 1 d'un côté et plusieurs de l'autre : 1-n, et la clé étrangère va du côté « n ». Si c'est plusieurs des deux côtés : n-n, qui impose une table de liaison contenant les deux clés étrangères.\n\nExemple résolu : un client passe plusieurs commandes, mais une commande appartient à un seul client. C'est une relation 1-n, et commande.client_id est la clé étrangère.\n\n

Étapes de l'exercice\n\n1. Classe ces 5 relations : client ↔ commande (exemple résolu, à recopier), commande ↔ produit, commande ↔ paiement (une commande est payée en un seul paiement Mobile Money), client ↔ profil_client, client ↔ prediction_ia (une prédiction par client et par date, plusieurs dans le temps).\n2. Pour chaque relation, écris la cardinalité, la clé étrangère et où elle se place, puis une phrase de justification.\n3. Pour la relation n-n, dessine la table de liaison ligne_commande avec : commande_id, produit_id, quantite, prix_unitaire. Explique pourquoi quantite ne peut pas être dans commande ni dans produit.\n4. Relis ton tableau comme si tu l'envoyais à un développeur : est-il compréhensible sans toi ?\n\n

Livrable attendu\n\nUn tableau (tableur ou document) avec les colonnes : Table A, Table B, Cardinalité, Clé étrangère et table porteuse, Justification en une phrase. Ajoute sous le tableau le schéma de la table de liaison.\n\n

Critères de réussite\n\n- Au moins 4 relations sur 5 correctement classées.\n- La relation n-n est identifiée et sa table de liaison est créée avec les deux clés étrangères.\n- Chaque classement est justifié en une phrase.\n\n

Erreurs à éviter\n\n- Placer la clé étrangère du côté « 1 » au lieu du côté « n ».\n- Mettre une liste de produits dans une seule cellule de commande au lieu d'une table de liaison.\n- Classer selon la situation d'aujourd'hui plutôt que selon la règle métier : valide la règle avec le métier en cas de doute (paiement fractionné possible ?).

Objectifs pratiques

À la fin de cette leçon (15 min), tu sauras lire un ERD de 6 tables, repérer les clés primaires (PK) et étrangères (FK), puis l'expliquer en 2 minutes à un développeur. C'est la première brique pour collaborer en autonomie sans ralentir l'équipe, et la base pour devenir gestionnaire de base de données.

Pourquoi c'est utile pour votre objectif

Un ERD (schéma entité-relation, appelé MCD côté conceptuel) est la référence commune entre métier et développeurs. Si tu sais le lire, tu poses des questions précises au lieu de besoins vagues. Tu peux aussi voir où l'IA lira ou écrira ses prédictions. Et tu pourras former d'autres personnes avec le même support.

Deux niveaux à distinguer :

• Modèle conceptuel : les entités métier et leurs liens, sans détails techniques.
• Modèle physique : les vraies tables, colonnes, types, PK et FK, telles que le développeur les crée.

Le fil rouge : la Boutique Wave/WhatsApp

Nous utilisons 6 tables (schéma pédagogique, à comparer avec l'ERD fourni dans ton module) :

1. clients (PK : id_client) : nom, téléphone, ville.
2. produits (PK : id_produit) : nom, prix, stock.
3. commandes (PK : id_commande, FK : id_client) : date, statut.
4. lignes_commande (PK : id_ligne, FK : id_commande, id_produit) : quantité, prix unitaire.
5. paiements (PK : id_paiement, FK : id_commande) : montant, opérateur Mobile Money, date.
6. predictions_ia (PK : id_prediction, FK : id_client) : valeur prédite, version du modèle, date.

Si ton ERD diffère, applique la même méthode à ses tables.

Méthode pas à pas

1. Compte les rectangles : nomme les 6 tables à voix haute et dis ce que chacune représente dans le métier.
2. Repère les PK : dans chaque table, entoure la colonne qui identifie une ligne de façon unique.
3. Repère les FK : trouve les colonnes qui pointent vers la PK d'une autre table. Elles matérialisent les relations.
4. Lis les relations : suis les traits. Un client a plusieurs commandes (1-n). Une commande a plusieurs lignes (1-n). Produits et commandes sont liés en n-n via lignes_commande.
5. Raconte un parcours : suis le trajet d'une vente, du client au paiement, puis à la prédiction IA.
6. Chronomètre 2 minutes : structure ton discours en 3 temps : vue d'ensemble (20 s), relations clés (60 s), points de vigilance ou questions (40 s).

Exemple concret

« La boutique a 6 tables. Au centre, commandes, reliée à clients par id_client. Chaque commande contient des lignes, qui pointent vers produits par id_produit. Les paiements sont rattachés à la commande. La table predictions_ia enregistre ce que le modèle prédit pour un client, avec la version du modèle. Ma question au dev : un paiement partiel est-il possible, c'est-à-dire plusieurs paiements pour une commande ? »

Erreurs à éviter

• Confondre PK et FK : la PK identifie sa propre ligne, la FK renvoie vers une autre table.
• Lire les tables sans les relations : un ERD sert d'abord à comprendre les liens.
• Employer du jargon que tu ne maîtrises pas : mieux vaut une phrase simple.
• Oublier la cardinalité (1-1, 1-n, n-n) : c'est elle qui déclenche les bonnes questions.
• Dépasser 2 minutes : prépare un plan court, pas un récit.

À faire maintenant

Imprime ou recopie l'ERD, annote-le (PK, FK, cardinalités) et prépare ton explication de 2 minutes. Chronomètre-toi, puis note les mots où tu as hésité. Livrable : une fiche « lecture d'ERD » annotée.

Pourquoi cet exercice

Tu veux collaborer avec les développeurs sans les freiner, puis devenir gestionnaire de base de données. Le dictionnaire de données est le livrable BA de référence en fin de cadrage. Il remplace les besoins vagues par une référence précise que les développeurs peuvent implémenter directement. Il te sert aussi plus tard : une IA qui lit ou écrit dans la base a besoin de colonnes sans ambiguïté, et tu pourras former d'autres personnes avec ce document.

Durée estimée : 30 à 45 minutes, à répartir sur 2 ou 3 sessions de 15 minutes.

Contexte : la Boutique Wave/WhatsApp

Une petite boutique vend des produits via WhatsApp et encaisse par Mobile Money (Wave, par exemple). Elle veut suivre ses clients, ses commandes et ses paiements, et enregistrer les prédictions d'un modèle IA (par exemple le risque de rupture de stock). Voici les 6 tables à documenter :

1. clients : id_client, nom, telephone, ville, date_creation
2. produits : id_produit, libelle, prix_unitaire, stock, actif
3. commandes : id_commande, id_client, date_commande, statut, canal
4. lignes_commande : id_ligne, id_commande, id_produit, quantite, prix_applique
5. paiements : id_paiement, id_commande, montant, operateur, reference_transaction, date_paiement
6. predictions_ia : id_prediction, id_produit, valeur_predite, version_modele, date_prediction

Si une colonne te semble manquer, ajoute-la en justifiant ton choix.

Étapes à suivre

Étape 1 : préparer le tableau

Crée un tableur (ou un tableau Markdown) avec ces colonnes : table, colonne, type, obligatoire (oui/non), exemple, règle de gestion, sensible (oui/non). Ajoute aussi une colonne « clé » (PK, FK ou rien) pour repérer les relations.

Étape 2 : remplir chaque colonne

Pour chaque colonne, choisis un type simple (entier, texte, décimal, date, booléen). Donne un exemple réaliste (ex. telephone : +221 77 000 00 00). Écris une règle de gestion testable, par exemple « le montant est strictement supérieur à 0 » ou « le statut vaut parmi : en_attente, payée, livrée, annulée ».

Étape 3 : marquer les données sensibles

Marque comme sensibles les données personnelles : nom, téléphone, ville et, selon ton analyse, la référence de transaction. Ajoute une phrase de justification (identifie une personne, ou révèle un paiement).

Étape 4 : relire comme un développeur

Relis ton dictionnaire en te demandant : « Pourrais-je coder cette colonne sans poser de question ? ». Supprime toute ambiguïté (ex. « date » : de quoi ? format ?). Liste ensuite 3 questions ouvertes que tu poserais à l'équipe de développement.

Erreurs à éviter

• Écrire des règles vagues (« doit être correct »).
• Oublier les clés étrangères et leur règle (ex. chaque commande appartient à un client existant).
• Ne pas distinguer « obligatoire » et « unique ».
• Oublier de marquer les colonnes personnelles comme sensibles.

Livrables attendus

1. Le dictionnaire de données complet des 6 tables (fichier tableur ou Markdown), à ranger dans ton Dossier BDD.
2. La liste de 3 questions ouvertes pour les développeurs.

Critères de réussite

• Chaque colonne contient nom, type, obligatoire, exemple et règle.
• Les colonnes de données personnelles sont marquées sensibles.
• Aucune colonne n'est ambiguë ou sans règle.
• Les clés primaires et étrangères sont identifiées.

Objectifs pratiques

À la fin de cette leçon, tu sauras écrire 5 requêtes de lecture avec SELECT, WHERE, ORDER BY et LIMIT sur la base de la Boutique Wave/WhatsApp. Tu pourras répondre seul à des questions comme « quels paiements ont échoué ? » sans attendre un développeur. C'est la première brique pour collaborer en autonomie, sans freiner l'équipe, et pour devenir gestionnaire de base de données.

Pourquoi c'est utile pour votre objectif

Un business analyste qui sait lire les données vérifie lui-même ses hypothèses. Il arrive aux checkpoints avec des chiffres, pas des suppositions. Plus tard, tu utiliseras les mêmes requêtes pour contrôler ce que l'IA écrit dans une table de prédictions. Dans ce cas, tu seras en lecture seule : tu regardes, tu ne modifies rien. C'est la meilleure façon de débuter sans risque.

Méthode pas à pas

1. Formule la question métier en français. Exemple : « Quels sont les 10 premiers clients par ordre alphabétique ? »
2. Choisis la table. Ici : clients. Relis ton dictionnaire de données pour repérer les colonnes (nom, telephone).
3. SELECT : choisis les colonnes. Évite * quand tu n'as besoin que de deux colonnes. Le résultat est plus lisible et plus léger.
4. WHERE : filtre les lignes. Texte entre apostrophes ('echec'), nombres sans apostrophes (5000).
5. Combine avec AND / OR. AND impose que toutes les conditions soient vraies. OR exige qu'une seule le soit. Utilise des parenthèses dès que tu mélanges les deux.
6. ORDER BY : trie. ASC par défaut, DESC pour du plus grand au plus petit.
7. LIMIT : borne le résultat. Commence toujours par un petit LIMIT pour ne pas surcharger la base.
8. Vérifie et commente. Relis le résultat, compare-le à ta question, puis note la question en commentaire SQL (-- question).

Exemple concret

```sql -- Q1 : les 10 premiers clients par ordre alphabétique ? SELECT nom, telephone FROM clients ORDER BY nom LIMIT 10;

-- Q2 : quels paiements en échec dépassent 5000 ? SELECT * FROM paiements WHERE statut = 'echec' AND montant > 5000;

-- Q3 : les 5 plus gros paiements réussis ? SELECT id, montant FROM paiements WHERE statut = 'succes' ORDER BY montant DESC LIMIT 5; ```

Si la Q2 renvoie 12 lignes, tu peux dire au développeur : « 12 paiements de plus de 5000 ont échoué, voici leurs identifiants. » Ce message est précis et exploitable.

Erreurs à éviter

• Écrire statut = echec sans apostrophes : la base cherche une colonne, pas un texte.
• Utiliser SELECT * sur une grosse table sans LIMIT.
• Mélanger AND et OR sans parenthèses : le résultat peut être faux sans message d'erreur.
• Oublier le point-virgule final ou écrire une casse différente pour les valeurs ('Echec' au lieu de 'echec'). Vérifie les valeurs réelles dans le dictionnaire de données.
• Ne pas relire le résultat : une requête qui s'exécute n'est pas forcément correcte.

À faire maintenant

Dans ton carnet, écris 5 requêtes commentées sur la Boutique : les deux requêtes de l'exemple (Q1 et Q2) plus trois à toi, par exemple les commandes les plus récentes, les produits les plus chers, les paiements d'un montant donné. Chaque requête porte en commentaire sa question métier. Vérifie que 4 requêtes sur 5 donnent un résultat correct, et que l'une utilise bien WHERE avec AND et ORDER BY.

Objectifs pratiques

Dans cette leçon, tu apprends à produire seul deux reportings sur la Boutique Wave/WhatsApp : le total des paiements par opérateur Mobile Money, puis la liste des clients avec leurs paiements en échec. Tu n'auras plus besoin de demander ces chiffres à un développeur. Tu pourras aussi lui envoyer des demandes précises, ce qui accélère le travail de l'équipe.

Pourquoi c'est utile pour votre objectif

Un business analyste autonome sait traduire une question métier en requête. Un futur gestionnaire de base de données doit en plus vérifier ce que la base contient avant de la modifier ou d'en donner l'accès. COUNT, SUM, GROUP BY et JOIN couvrent l'essentiel des demandes de reporting. Ce sont aussi les requêtes qu'un outil d'IA exécutera en lecture sur la base. Les maîtriser te permet de contrôler ses résultats.

Méthode pas à pas

1. Formule la question métier en une phrase. Exemple : « Combien a-t-on encaissé par opérateur ? »
2. Identifie les tables et les colonnes. Regarde ton ERD et ton dictionnaire de données. Hypothèse de travail : paiements(id, client_id, operateur, montant, statut) et clients(id, nom, telephone). Adapte les noms à ton schéma.
3. Choisis l'agrégat. SUM additionne des montants. COUNT compte des lignes.
4. Regroupe avec GROUP BY. Toute colonne du SELECT qui n'est pas agrégée doit figurer dans le GROUP BY.
5. Filtre avant de regrouper avec WHERE. Utilise HAVING pour filtrer après l'agrégation.
6. Joins avec la bonne clé. On relie paiements.client_id à clients.id, c'est-à-dire clé étrangère et clé primaire.
7. Relis le résultat. Vérifie qu'il est plausible : le total doit être cohérent avec le nombre de lignes, et les lignes ne doivent pas être dupliquées.
8. Commente la requête. Ajoute une phrase qui dit ce que la requête renvoie.

Exemple concret

```sql -- Requête 1 : total encaissé et nombre de paiements réussis par opérateur Mobile Money SELECT operateur, COUNT(*) AS nb_paiements, SUM(montant) AS total_fcfa FROM paiements WHERE statut = 'reussi' GROUP BY operateur ORDER BY total_fcfa DESC;

-- Requête 2 : clients ayant au moins un paiement en échec SELECT c.nom, c.telephone, p.operateur, p.montant FROM clients c JOIN paiements p ON p.client_id = c.id WHERE p.statut = 'echec'; ```

La requête 1 renvoie une ligne par opérateur, avec le nombre de paiements réussis et leur total. La requête 2 renvoie une ligne par paiement en échec, avec le client concerné. Un client qui a eu deux échecs apparaît deux fois. Pour n'avoir qu'une ligne par client, utilise SELECT DISTINCT ou GROUP BY c.id.

Erreurs à éviter

• Oublier une colonne non agrégée dans le GROUP BY, ce qui provoque une erreur.
• Mélanger WHERE et HAVING.
• Joindre sur la mauvaise colonne, par exemple p.id = c.id. Le résultat est faux mais ressemble à un vrai résultat.
• Additionner des paiements échoués sans le savoir, parce que le filtre sur le statut manque.
• Ne pas vérifier les valeurs réelles de statut : il peut s'écrire echec, failed ou ECHEC selon la base.

À faire maintenant

Dans ton carnet, écris les deux requêtes sur ton schéma. Ajoute au-dessus de chacune un commentaire d'une phrase qui explique ce qu'elle renvoie. Teste-les sur des données d'exemple de la boutique. Pour finir, rédige en trois lignes la demande que tu enverrais à un développeur si une colonne te manquait.

Pourquoi cet exercice t'aide

Ton objectif est de collaborer avec les développeurs sans les freiner, puis de devenir gestionnaire de base de données. Un business analyste qui sait extraire lui-même une donnée n'a plus besoin de demander un export à chaque question. Ce carnet de 10 requêtes est la preuve concrète de ton autonomie SQL, et tu pourras le montrer à un employeur. Il te servira aussi plus tard pour former d'autres personnes.

Contexte

Tu travailles sur la base de test de la Boutique Wave/WhatsApp. Elle contient les tables clients, produits, commandes, lignes de commande et paiements Mobile Money. Chaque samedi, la commerçante veut son « bilan du samedi » : ce qu'elle a vendu, à qui, et combien elle a encaissé.

Durée estimée

Prévois 6 sessions de 15 minutes, soit environ 1 h 30. Tu peux avancer à ton rythme, avec un checkpoint après la requête 5 et un autre après la requête 10.

Étapes

Étape 1 : préparer le carnet (10 min)

Crée un document avec un tableau de 10 lignes. Les colonnes sont : numéro, question métier, requête SQL, résultat obtenu, ce que j'ai compris, niveau d'aide utilisé (0, 1 ou 2).

Étape 2 : les requêtes 1 à 5, lecture simple (30 min)

Traduis ces questions en SQL en utilisant SELECT, WHERE, ORDER BY et LIMIT :

1. Liste de tous les produits.
2. Produits à plus de 5 000 FCFA, triés du plus cher au moins cher.
3. Les 5 dernières commandes.
4. Les clients de Dakar, ou de la ville de ton jeu de données.
5. Les commandes du samedi dernier.

Fais le checkpoint : 4 résultats corrects sur 5 minimum.

Étape 3 : les requêtes 6 à 10, agrégats et jointures (45 min)

1. Nombre total de commandes.
2. Chiffre d'affaires du samedi (SUM).
3. Montant encaissé par mode de paiement (GROUP BY).
4. Nom de chaque client avec ses commandes (JOIN).
5. Le bilan du samedi : par produit, quantité vendue et total, trié par total décroissant (JOIN + GROUP BY + ORDER BY).

Étape 4 : utiliser l'assistant IA comme coach

Demande à l'assistant des indices uniquement, jamais la réponse complète. Exemple de demande : « Donne-moi un indice sur la clause à utiliser, sans écrire la requête. » Note dans le carnet le niveau d'aide utilisé pour chaque requête.

Étape 5 : commenter et expliquer (15 min)

Ajoute au-dessus de chaque requête un commentaire SQL (-- ...) qui reprend la question métier. Choisis ensuite 2 requêtes et explique-les à voix haute en 1 minute chacune, comme si tu parlais à un développeur.

Erreurs à éviter

• Oublier le GROUP BY quand tu utilises SUM ou COUNT.
• Faire une jointure sans la condition ON, ce qui multiplie les lignes.
• Copier une réponse que tu ne sais pas expliquer.
• Travailler sur une base de production : reste sur la base de test.

Livrable

Un carnet de 10 requêtes commentées, avec leur résultat et une phrase d'explication pour chacune.

Critères de réussite

• Au moins 8 requêtes sur 10 donnent un résultat correct.
• Chaque requête est commentée avec sa question métier.
• Aucune requête n'est copiée sans compréhension. Tu dois pouvoir l'expliquer oralement.