F08 - Data Literacy et Culture Data

Explication pédagogique

La data literacy — littéralement « littératie des données » — est la capacité à lire, comprendre, interroger et communiquer avec des données. Ce n'est pas une compétence réservée aux analystes : c'est devenu un savoir professionnel de base, au même titre que la maîtrise d'un tableur ou d'un traitement de texte.

Ce module se construit autour d'un cas fil rouge : Teranga Distribution, une PME sénégalaise qui distribue des produits de grande consommation dans plusieurs zones du pays. Ses ventes proviennent de boutiques, d'agents commerciaux et de commandes numériques ; ses paiements combinent espèces, virements et mobile money. Le dirigeant doit décider où réduire les retards de livraison, où améliorer la marge, et comment fiabiliser son reporting — trois décisions qui, comme dans la plupart des PME africaines, sont aujourd'hui prises largement à l'intuition, faute d'une culture data partagée.

Le diagnostic initial vise à situer votre point de départ : quel est votre rapport actuel aux données de votre activité ? Disposez-vous d'indicateurs fiables ? Savez-vous lire un graphique de façon critique ? Avez-vous déjà utilisé un outil de visualisation ou d'IA pour analyser un jeu de données ? Ce diagnostic honnête oriente votre parcours dans les cinq modules qui suivent.

Démonstration contextualisée

Voici comment un diagnostic data literacy structuré permet de cadrer un parcours de montée en compétence :

Question 1 : Dans mon activité, quelles décisions récurrentes
             pourraient s'appuyer sur des données plutôt que
             sur l'intuition ? (ex. Teranga : quelle zone de
             livraison prioriser ?)
Question 2 : Ai-je accès à ces données aujourd'hui ? Sous quelle
             forme (tableur, logiciel métier, papier) ?
Question 3 : Sais-je lire un graphique et repérer s'il est
             trompeur (échelle tronquée, comparaison biaisée) ?
Question 4 : Ai-je déjà utilisé un outil de visualisation (Power
             BI, Looker Studio) ou une IA pour analyser des
             données chiffrées ?
Question 5 : Ma structure a-t-elle des règles écrites sur qui
             peut accéder à quelles données et comment les
             protéger ?

→ Un score bas sur les questions 1-2 oriente vers le Module 1 ;
  sur la 3, vers le Module 2 ; sur la 4, vers le Module 3 ;
  sur la 5, vers le Module 4.

Leçon : la data literacy ne se limite pas à « savoir utiliser Excel » — c'est une chaîne complète qui va de la donnée brute à la décision documentée.

Explication pédagogique

Quatre notions s'enchaînent et se distinguent : la donnée, l'information, l'indicateur et la décision. Confondre ces niveaux est la première source de mauvaises décisions data-driven.

Une donnée est un fait brut, sans contexte : « 450 000 ». Seule, elle ne dit rien. Une information est une donnée contextualisée : « 450 000 FCFA de ventes en juin 2025, zone de Thiès ». Un indicateur est une information mise en relation avec un objectif ou une référence : « le taux de croissance des ventes à Thiès est de +12 % par rapport à mai, contre un objectif de +8 % ». Une décision est l'action choisie à partir de l'indicateur, avec un niveau de confiance assumé : « augmenter le stock de Thiès de 15 % pour le mois prochain, sous réserve de confirmer la tendance sur un second mois ».

La chaîne complète — donnée → information → indicateur → décision — doit toujours être traçable : quelle est la source de la donnée ? qui l'a définie ? à quelle date ? Une décision prise sur un indicateur dont on ne connaît pas la source ou la fraîcheur est une décision fragile, même si le chiffre affiché semble précis.

Démonstration contextualisée

Chez Teranga Distribution, une remontée mensuelle illustre la chaîne complète :

DONNÉE BRUTE : 128 commandes enregistrées en zone de Mbour
               en juin 2025 (extrait du logiciel de caisse).

INFORMATION : 128 commandes de la zone Mbour au mois de juin
              2025, en hausse par rapport aux 96 de mai 2025.

INDICATEUR : Taux de croissance mensuel des commandes à Mbour
             = (128-96)/96 = +33 %, contre un objectif de +10 %
             fixé en début d'année.

DÉCISION : Renforcer l'équipe commerciale à Mbour le mois
           prochain — SOUS RÉSERVE de vérifier que la hausse
           n'est pas due à un événement ponctuel (foire locale,
           opération promotionnelle) qui ne se répétera pas.

TRAÇABILITÉ : Source = logiciel de caisse Teranga, extraction
              le 30/06/2025, périmètre = zone Mbour uniquement.

Leçon : chaque niveau ajoute du sens, mais chaque niveau peut aussi introduire une erreur d'interprétation si la traçabilité est perdue en chemin.

Explication pédagogique

Toutes les données ne se traitent pas de la même façon : leur type, leur format et leur niveau de mesure déterminent les calculs et les visualisations possibles. Confondre ces catégories mène à des erreurs d'analyse fréquentes — comme calculer une moyenne sur des catégories, ce qui n'a pas de sens.

Les niveaux de mesure classiques sont au nombre de quatre. Le niveau nominal : des catégories sans ordre (zone de vente : Dakar, Thiès, Mbour — aucune n'est « supérieure » à l'autre). Le niveau ordinal : des catégories ordonnées mais sans écart mesurable (satisfaction client : faible, moyenne, élevée). Le niveau intervalle : des valeurs numériques où les écarts ont un sens mais où le zéro est arbitraire (température en degrés). Le niveau ratio : des valeurs numériques avec un vrai zéro, permettant tous les calculs (chiffre d'affaires, nombre de commandes, poids).

Le format ajoute une autre dimension pratique : texte, nombre, date, booléen (vrai/faux), catégorie. Un format mal identifié — une date stockée comme texte, un code postal traité comme un nombre — casse silencieusement les calculs et les tris dans un tableur ou un outil de BI.

Démonstration contextualisée

Un extrait du fichier de ventes de Teranga Distribution illustre les pièges classiques :

Colonne          | Type apparent | Niveau de mesure | Piège classique
-----------------|----------------|-------------------|------------------
Zone (Dakar...)  | Texte          | Nominal           | Calculer une
                 |                |                   | "moyenne de zone"
                 |                |                   | n'a AUCUN sens.
Satisfaction     | Texte          | Ordinal           | Un score "élevé"
(faible/moy/élevé)|               |                   | n'est pas 3x un
                 |                |                   | score "faible".
Code produit     | Nombre         | Nominal (déguisé) | Ne JAMAIS faire
(ex. 00452)      |                |                   | de moyenne sur
                 |                |                   | un identifiant.
Date de commande | Texte (souvent)| -                 | Si stockée comme
                 |                |                   | texte, impossible
                 |                |                   | de trier correcte-
                 |                |                   | ment (01/02 avant
                 |                |                   | 15/01 en texte).
Montant (FCFA)   | Nombre         | Ratio              | Seul niveau où
                 |                |                   | TOUS les calculs
                 |                |                   | sont valides.

Leçon : avant tout calcul, demandez-vous : quel est le VRAI niveau de mesure de cette colonne, indépendamment de son apparence ?

Explication pédagogique

Les données d'une organisation proviennent de sources internes (systèmes propres à l'entreprise) et de sources externes (données produites ailleurs). Cartographier ces sources est la première étape de toute démarche data literacy sérieuse — on ne peut pas exploiter ce qu'on ne sait pas localiser.

Les sources internes typiques d'une PME africaine : le logiciel de caisse ou de facturation, le tableur de suivi commercial, les registres papier (encore fréquents), les échanges mobile money, les fiches de stock. Les sources externes utiles : les données ouvertes des institutions (statistiques nationales, données de la BCEAO), les données sectorielles (rapports d'associations professionnelles), les plateformes partenaires (agrégateurs mobile money, marketplaces).

Un point spécifiquement africain mérite l'attention : les données de mobile money, d'e-commerce et de capteurs agricoles constituent des gisements de données en forte croissance, souvent sous-exploités par les PME faute de compétences internes pour les collecter et les croiser. Une organisation qui cartographie ses sources découvre généralement qu'elle dispose de plus de données qu'elle ne le pensait — dispersées dans des systèmes qui ne communiquent pas entre eux.

Démonstration contextualisée

La cartographie des sources de Teranga Distribution révèle une dispersion typique :

SOURCES INTERNES
• Logiciel de caisse (ventes boutiques) — quotidien, fiable
• Tableur Excel des agents commerciaux — hebdomadaire, saisie
  manuelle, erreurs fréquentes
• Registre papier des livraisons — non numérisé, perdu si abîmé
• Relevés mobile money (Wave, Orange Money) — quotidien, format
  variable selon l'opérateur

SOURCES EXTERNES POTENTIELLES
• Données ANSD (Agence nationale de la statistique et de la
  démographie) sur la consommation par région
• Rapports de la Chambre de commerce sur le secteur distribution
• Données météo (pour anticiper la demande selon la saison)

CONSTAT : les quatre sources internes ne communiquent PAS entre
elles. Le dirigeant additionne mentalement des chiffres de
systèmes différents, sans réconciliation formelle — source
majeure d'erreurs de pilotage.

Leçon : cartographier ses sources révèle souvent un problème de dispersion plus qu'un problème de rareté des données.

Explication pédagogique

La qualité des données se décompose en six dimensions classiques, chacune répondant à une question précise. L'exactitude : la donnée reflète-t-elle la réalité ? L'exhaustivité : manque-t-il des valeurs ? La cohérence : la donnée est-elle homogène entre les systèmes (le même client porte-t-il le même nom partout) ? La fraîcheur : la donnée est-elle à jour ? L'unicité : y a-t-il des doublons ? La validité : la donnée respecte-t-elle le format et les règles attendues (un email contient-il un « @ », une date est-elle dans une plage plausible) ?

Ces six dimensions ne sont pas de la théorie abstraite : elles se transforment directement en contrôles pratiques qu'on peut appliquer à n'importe quel fichier avant de l'analyser. Un jeu de données qui échoue sur une seule de ces dimensions peut produire une analyse entièrement faussée, même si le calcul lui-même est mathématiquement correct.

La qualité des données n'est jamais un état permanent : elle se dégrade dans le temps (un numéro de téléphone change, une adresse déménage) et doit faire l'objet de contrôles récurrents, pas d'une vérification unique au moment de la collecte.

Démonstration contextualisée

Un contrôle qualité sur le fichier clients de Teranga Distribution, dimension par dimension :

EXACTITUDE : 3 clients ont un numéro de téléphone qui ne
             correspond plus au bon abonné (vérifié par appel).

EXHAUSTIVITÉ : 12 % des fiches clients n'ont pas de zone
               géographique renseignée → impossible de les
               inclure dans une analyse par zone.

COHÉRENCE : le client "Fatou Diop" existe sous 3 orthographes
            différentes ("Fatou Diop", "F. Diop", "Fatou DIOP")
            dans le logiciel de caisse.

FRAÎCHEUR : le fichier des agents commerciaux n'a pas été mis
            à jour depuis 8 mois ; 2 agents ont quitté l'entreprise.

UNICITÉ : 7 doublons détectés (même client saisi deux fois avec
          un numéro de téléphone légèrement différent).

VALIDITÉ : 4 dates de naissance de clients sont dans le futur
           (erreur de saisie) — à corriger avant tout calcul d'âge.

→ Sur 6 dimensions, 6 problèmes concrets. Aucune analyse fiable
  n'est possible sans un nettoyage préalable.

Leçon : les six dimensions de qualité forment une check-list systématique à appliquer avant toute analyse, jamais après.

Explication pédagogique

Trois termes techniques reviennent constamment dans le vocabulaire data et méritent d'être démystifiés : big data, data warehouse et data lake. Comprendre leurs différences évite de confondre un projet réellement nécessaire avec un effet de mode coûteux.

Le big data ne désigne pas « beaucoup de données » en général, mais des données caractérisées par le volume, la vélocité (vitesse de génération) et la variété (formats hétérogènes) — typiquement des flux de capteurs, de transactions mobile money à très grande échelle, ou de réseaux sociaux. La plupart des PME, y compris Teranga Distribution, n'ont pas de problème de big data : elles ont un problème de qualité et d'organisation de données de taille modeste mais mal structurées.

Un data warehouse (entrepôt de données) est une base structurée, organisée pour l'analyse et le reporting : les données y sont nettoyées, modélisées et cohérentes, au prix d'un travail de préparation important. Un data lake (lac de données) stocke des données brutes de tous formats sans structure imposée au préalable, offrant une grande flexibilité mais exigeant une discipline forte pour ne pas devenir un « marécage de données » inexploitable. Le cycle de vie de la donnée traverse quatre étapes : collecte, stockage, traitement, analyse — et chaque étape doit être pensée en fonction de l'usage final.

Démonstration contextualisée

Pour Teranga Distribution, le bon dimensionnement de l'infrastructure évite le sur-investissement :

BESOIN RÉEL DE TERANGA :
• Quelques milliers de transactions par mois (pas des millions
  par seconde) → PAS de besoin de "big data" au sens technique.
• Données dispersées entre 4 systèmes non connectés → besoin
  d'un entrepôt SIMPLE (même un classeur Excel bien structuré
  avec des règles de nommage cohérentes peut suffire au début).
• Pas de flux massifs et hétérogènes en temps réel → PAS besoin
  d'un data lake sophistiqué.

CYCLE DE VIE APPLIQUÉ :
1. COLLECTE : caisse, agents, mobile money, papier → à unifier.
2. STOCKAGE : un tableur structuré ou une base légère (Google
   Sheets, Airtable) avec des identifiants cohérents entre sources.
3. TRAITEMENT : nettoyage mensuel (dédoublonnage, normalisation
   des noms, contrôle des dates).
4. ANALYSE : tableau de bord mensuel avec les indicateurs clés
   (Module 2 de cette formation).

ERREUR CLASSIQUE : investir dans un "data lake" sophistiqué
avant même d'avoir résolu la dispersion entre 4 tableurs.

Leçon : le bon niveau de sophistication technique dépend du volume et de la complexité réels des données — pas du vocabulaire à la mode.

Explication pédagogique

Une visualisation efficace repose sur trois piliers : le design (l'apparence sert le message, pas l'inverse), la lisibilité (l'information se comprend en quelques secondes) et l'honnêteté (le graphique ne trompe pas, même involontairement). Ces trois piliers s'appuient sur des principes de perception visuelle que le cerveau humain applique automatiquement — et qu'un bon visualiseur exploite plutôt que de les ignorer.

Le cerveau perçoit certains éléments visuels beaucoup plus vite et plus précisément que d'autres. La position sur un axe commun est la comparaison la plus précise (d'où l'efficacité du graphique en barres). La longueur vient ensuite. La couleur et la taille sont perçues moins précisément — elles conviennent pour attirer l'attention ou catégoriser, rarement pour comparer des valeurs précises.

Une visualisation sert toujours une décision, jamais la décoration. Avant de choisir un graphique, il faut se demander : quelle question précise ce visuel doit-il permettre de trancher ? Un graphique « joli » qui ne répond à aucune question décisionnelle est un graphique inutile, voire nuisible s'il détourne l'attention.

Démonstration contextualisée

Chez Teranga Distribution, le choix entre deux visualisations du même indicateur illustre le principe :

QUESTION DÉCISIONNELLE : quelle zone de vente a le meilleur taux
de croissance ce trimestre ?

❌ VISUALISATION FAIBLE : un graphique en secteurs (camembert)
   à 6 zones, avec des couleurs proches, sans étiquettes de
   valeur. → Le cerveau ne compare pas précisément des angles ;
   impossible de dire laquelle des zones à 18% et 21% est
   la plus grande sans lire les chiffres.

✅ VISUALISATION FORTE : un graphique en barres horizontales,
   trié par valeur décroissante, avec l'étiquette du pourcentage
   directement affichée. → La POSITION sur un axe commun permet
   une comparaison immédiate et précise ; le tri fait ressortir
   la hiérarchie en un coup d'œil.

PRINCIPE : la position et la longueur sont perçues plus
précisément que l'angle ou la couleur — d'où la supériorité
quasi systématique des barres sur les camemberts pour comparer
des catégories.

Leçon : le choix d'un graphique n'est pas une question de goût, mais de perception : certaines formes visuelles permettent une lecture plus précise que d'autres.

Explication pédagogique

Choisir le bon type de graphique dépend directement de la question posée, pas des goûts esthétiques. Chaque famille de graphique répond à un type de question précis.

Les barres comparent des catégories entre elles (ventes par zone). Les lignes montrent une évolution dans le temps (ventes mensuelles sur un an). Le nuage de points (scatter) révèle une relation entre deux variables numériques (nombre de visites commerciales et chiffre d'affaires). Les cartes situent une donnée dans l'espace géographique (répartition des ventes par région du Sénégal). Les heatmaps (cartes de chaleur) montrent une intensité croisant deux dimensions catégorielles (jour de la semaine × heure de la journée pour les commandes).

Une erreur fréquente consiste à utiliser un graphique en ligne pour des catégories sans ordre naturel (zones géographiques), suggérant à tort une continuité ou une tendance qui n'existe pas. À l'inverse, utiliser des barres pour une évolution temporelle avec de nombreux points masque la tendance générale que la ligne rendrait immédiatement visible.

Démonstration contextualisée

Dix questions métier de Teranga Distribution et le graphique adapté à chacune :

1. Comparer les ventes des 6 zones ce mois → BARRES
2. Suivre l'évolution des ventes sur 12 mois → LIGNE
3. Ventes vs nombre d'agents actifs par zone → NUAGE DE POINTS
4. Répartition géographique des livraisons → CARTE
5. Commandes par jour de semaine × heure → HEATMAP
6. Part de chaque mode de paiement (espèces/virement/mobile
   money) → BARRES (PAS un camembert à comparer précisément)
7. Évolution du taux de retard de livraison sur l'année → LIGNE
8. Corrélation marge et taille de commande → NUAGE DE POINTS
9. Classement des 10 meilleurs clients par CA → BARRES triées
10. Répartition des retours produits par catégorie → BARRES

ERREUR CLASSIQUE À ÉVITER : représenter les 6 zones (catégorie
SANS ordre naturel) avec une LIGNE — cela suggère à tort une
continuité ou une tendance entre Dakar et Thiès qui n'existe pas.

Leçon : la nature de la question (comparaison, évolution, relation, localisation, intensité croisée) détermine mécaniquement le bon type de graphique.

Explication pédagogique

Un graphique peut être techniquement correct et néanmoins trompeur. Les manipulations les plus fréquentes concernent les échelles et les axes — souvent sans intention malveillante, simplement par méconnaissance des bonnes pratiques.

Le piège le plus courant est l'axe tronqué : démarrer l'axe des ordonnées à une valeur autre que zéro exagère visuellement les différences. Une croissance de 100 à 105 (soit +5 %) peut sembler spectaculaire si l'axe démarre à 95 au lieu de 0. Le second piège est l'échelle non linéaire non signalée : utiliser une échelle logarithmique sans le préciser clairement change radicalement la perception des écarts. Le troisième piège est la double échelle (deux axes Y différents sur un même graphique) qui permet de faire apparaître n'importe quelle corrélation visuelle en ajustant les échelles respectives.

La règle de bonne pratique : pour un graphique en barres, l'axe doit toujours démarrer à zéro — sans exception. Pour un graphique en ligne, une troncature de l'axe peut se justifier pour montrer une variation fine, à condition de le signaler explicitement (par un symbole de rupture d'axe ou une mention écrite).

Démonstration contextualisée

Deux versions du même graphique de ventes chez Teranga Distribution, avec un effet radicalement différent :

DONNÉES RÉELLES : ventes passées de 100 à 105 millions FCFA
                   (croissance de +5%).

❌ GRAPHIQUE TROMPEUR : barres avec axe Y démarrant à 95.
   → La barre "105" semble DEUX FOIS plus haute que la barre
     "100", suggérant visuellement un doublement des ventes
     qui n'a jamais eu lieu.

✅ GRAPHIQUE HONNÊTE : barres avec axe Y démarrant à 0.
   → Les deux barres apparaissent quasiment de la même hauteur,
     reflétant fidèlement une croissance modeste de +5%.

RÈGLE : pour des BARRES, l'axe démarre TOUJOURS à zéro.
Si l'on veut montrer une variation fine, on utilise une LIGNE
avec une rupture d'axe clairement signalée par un symbole "≈"
ou une mention explicite "axe tronqué pour lisibilité".

Leçon : un graphique en barres à axe tronqué n'est jamais acceptable — c'est la manipulation visuelle la plus fréquente et la plus facile à repérer une fois qu'on la connaît.

Explication pédagogique

Une bonne visualisation guide l'œil selon une hiérarchie visuelle délibérée : ce qui est important doit être vu en premier, ce qui est secondaire doit rester discret. Sans hiérarchie, tous les éléments se font concurrence et le message se dilue.

Les leviers de hiérarchie visuelle sont limités mais puissants. La taille : un élément plus grand attire l'attention en premier. La couleur : une couleur vive au milieu de gris capte immédiatement le regard — à réserver à l'élément le plus important (par exemple, mettre en couleur uniquement la barre qui répond à la question posée, et laisser les autres en gris neutre). La position : en français, l'œil lit naturellement de haut en bas et de gauche à droite ; les éléments-clés se placent donc en haut à gauche ou au centre. Le contraste : un texte ou un élément à fort contraste ressort davantage.

Un tableau de bord surchargé — trop de graphiques, trop de couleurs, aucune hiérarchie — est un tableau de bord inutilisable, même si chaque graphique pris isolément est correct. La règle d'or : un tableau de bord répond à trois à cinq questions clés, pas à toutes les questions possibles.

Démonstration contextualisée

TABLEAU DE BORD DE TERANGA DISTRIBUTION — application de la
hiérarchie visuelle :

NIVEAU 1 (le plus important, en haut, grand, en couleur) :
  → KPI unique : "Chiffre d'affaires du mois : 45M FCFA (+8%)"
    Grande police, couleur or de la marque, position centrale
    en haut de page.

NIVEAU 2 (secondaire, milieu de page, taille moyenne) :
  → Graphique en barres des ventes par zone, TOUTES en gris SAUF
    la meilleure zone en couleur vive, pour attirer l'œil sur
    l'élément qui répond à la question "où ça marche le mieux ?"

NIVEAU 3 (détail, en bas, petit, discret) :
  → Tableau détaillé des 50 dernières transactions, en texte
    noir sur fond blanc, sans couleur d'accent — consultable
    mais pas imposé au regard.

ERREUR À ÉVITER : mettre les 6 zones en 6 couleurs vives
différentes → aucune ne ressort, l'œil ne sait pas où regarder
en premier.

Leçon : la couleur n'est un outil de hiérarchie que si elle est utilisée avec parcimonie — colorer tout revient à ne rien mettre en valeur.

Explication pédagogique

Avant d'ouvrir Power BI, il faut construire un modèle mental de ce que l'outil attend : des données structurées, idéalement organisées selon une logique de tables reliées entre elles plutôt qu'un unique tableau géant mélangeant tout.

Power BI (comme la plupart des outils de BI moderne) fonctionne mieux avec un modèle en étoile : une table de faits centrale (les transactions, une ligne par vente) reliée à des tables de dimensions (une table Clients, une table Produits, une table Zones, une table Calendrier). Cette organisation évite la duplication d'information et permet des calculs rapides et cohérents, même quand les données grossissent.

La préparation des données avant import est une étape non négociable : colonnes bien nommées, types corrects (dates reconnues comme dates, nombres comme nombres), absence de lignes vides ou de doublons, cohérence des libellés (une même zone toujours orthographiée pareil). Un import de données sales dans Power BI produit un tableau de bord qui semble fonctionner mais qui calcule des résultats faux — l'outil ne détecte pas les erreurs de fond, seulement les erreurs de format.

Démonstration contextualisée

MODÈLE EN ÉTOILE POUR TERANGA DISTRIBUTION

TABLE DE FAITS : Ventes
  (id_vente, date, id_client, id_produit, id_zone, montant, quantité)

TABLES DE DIMENSIONS reliées à la table de faits :
  • Clients (id_client, nom, type_client, date_inscription)
  • Produits (id_produit, nom_produit, catégorie, prix_unitaire)
  • Zones (id_zone, nom_zone, région, agent_responsable)
  • Calendrier (date, mois, trimestre, année, jour_semaine)

AVANTAGE : pour changer le nom d'une zone, on le modifie UNE
seule fois dans la table Zones, et cela se répercute partout
— au lieu de devoir corriger des centaines de lignes dans un
tableau unique où "Thiès" et "THIES" et "Thies" coexisteraient.

PRÉPARATION AVANT IMPORT — checklist :
□ Chaque colonne a un nom clair et un type correct (date, nombre,
  texte).
□ Aucune ligne totalement vide.
□ Les identifiants (id_zone, id_produit) sont cohérents entre
  la table de faits et les tables de dimensions.
□ Les libellés textuels sont harmonisés (pas de "Thiès" et
  "THIES" coexistant).

Leçon : le temps investi dans la structuration en modèle étoile avant l'import est largement rentabilisé par la fiabilité et la rapidité du tableau de bord ensuite.

Explication pédagogique

Construire un premier tableau de bord dans Power BI suit une séquence logique : importer les données préparées, vérifier le modèle de données (les relations entre tables), créer les visuels un par un en partant des questions décisionnelles, puis organiser la mise en page selon la hiérarchie visuelle vue précédemment.

La séquence pratique recommandée : commencer par un ou deux indicateurs clés (cartes de type KPI, grand chiffre unique), ajouter ensuite un graphique de tendance temporelle (ligne), puis un graphique de comparaison par catégorie (barres), et enfin des filtres interactifs (slicers) permettant à l'utilisateur d'explorer par zone, par période ou par produit sans avoir à refaire le tableau de bord pour chaque vue.

Un piège fréquent des débutants est de vouloir tout montrer dès la première version. Il vaut mieux livrer un tableau de bord simple et fiable avec trois visuels bien pensés, que dix visuels approximatifs. On enrichit ensuite par itérations, en fonction des questions que les utilisateurs posent réellement une fois le premier tableau de bord en main.

Démonstration contextualisée

PREMIER TABLEAU DE BORD DE TERANGA DISTRIBUTION — étapes :

1. IMPORT : charger la table de faits Ventes et les dimensions
   Clients, Produits, Zones, Calendrier préparées en amont.

2. VÉRIFICATION DU MODÈLE : contrôler que Power BI a bien
   détecté les relations entre id_zone (Ventes) et id_zone
   (Zones), etc. Corriger manuellement si une relation manque.

3. VISUEL 1 (KPI) : "Chiffre d'affaires du mois" — carte simple,
   grand chiffre, avec l'évolution vs mois précédent.

4. VISUEL 2 (tendance) : graphique en ligne du CA mensuel sur
   12 mois, pour repérer la saisonnalité.

5. VISUEL 3 (comparaison) : graphique en barres du CA par zone,
   trié décroissant.

6. FILTRE INTERACTIF (slicer) : un menu déroulant "Zone" qui,
   une fois sélectionné, met à jour automatiquement les 3
   visuels pour ne montrer que la zone choisie.

VERSION 1 = ces 4 éléments SEULEMENT. On enrichit ensuite selon
les questions réellement posées par le dirigeant en l'utilisant.

Leçon : un tableau de bord se construit par versions successives et sobres, jamais en une seule fois exhaustive.

Explication pédagogique

Google Looker Studio (anciennement Google Data Studio) est un outil de visualisation en ligne, gratuit, particulièrement adapté au partage et à la collaboration — un atout pour une PME qui ne dispose pas encore d'une licence Power BI ou qui souhaite partager un tableau de bord avec des partenaires externes sans installation logicielle.

Sa force principale : un tableau de bord Looker Studio se partage par un simple lien, consultable depuis n'importe quel navigateur, sans installation. Il se connecte nativement à Google Sheets, ce qui en fait un choix naturel pour une PME dont les données transitent déjà par des feuilles de calcul partagées. La contrepartie : moins de fonctionnalités avancées de modélisation que Power BI, et une dépendance à une connexion internet stable pour la mise à jour des données.

La question du choix entre Power BI et Looker Studio ne se résout pas dans l'absolu mais selon le contexte : environnement Microsoft existant → Power BI ; besoin de partage large et gratuit avec des partenaires externes → Looker Studio ; données déjà dans Google Sheets → Looker Studio ; besoin de modélisation complexe multi-sources → Power BI.

Démonstration contextualisée

SCÉNARIO TERANGA DISTRIBUTION — partage avec un partenaire
financier (banque, investisseur) qui n'a pas Power BI installé :

AVEC LOOKER STUDIO :
1. Les données de vente sont dans un Google Sheets partagé,
   mis à jour chaque semaine par l'équipe commerciale.
2. Le tableau de bord Looker Studio se connecte directement
   à ce Google Sheets.
3. Un simple LIEN est envoyé au partenaire financier — il
   consulte le tableau de bord depuis son navigateur, sans
   rien installer, avec des données toujours à jour.
4. Les droits de partage sont réglés en "lecture seule" pour
   éviter toute modification accidentelle.

COMPARAISON DE CHOIX :
• Power BI : préférable si Teranga a déjà Microsoft 365 et des
  besoins de modélisation complexe (plusieurs bases de données
  à croiser).
• Looker Studio : préférable pour ce cas précis — partage
  externe simple, gratuit, données déjà dans Google Sheets.

Leçon : le choix d'outil dépend du contexte de partage et de l'écosystème existant, pas d'une supériorité technique absolue de l'un sur l'autre.

Explication pédagogique

Le storytelling avec les données consiste à organiser des chiffres en un récit compréhensible qui conduit l'auditoire vers une conclusion et une action — au lieu de simplement empiler des graphiques sans fil conducteur.

Une bonne histoire de données suit une structure narrative simple : le contexte (où en sommes-nous ?), la tension (quel problème ou quelle opportunité se dessine ?), les preuves (les données qui étayent ce constat, présentées progressivement), et la résolution (la recommandation d'action qui découle logiquement des preuves). Cette structure transforme une présentation de quinze graphiques en un message mémorable et actionnable.

Un principe clé du storytelling data : une idée par visuel. Chaque graphique présenté doit illustrer un seul point du récit ; un graphique qui essaie de montrer trop de choses à la fois dilue le message et perd l'auditoire. L'ordre de présentation compte également : commencer par planter le décor, construire la tension, puis livrer la preuve qui justifie la recommandation — jamais l'inverse.

Démonstration contextualisée

RÉCIT DE DONNÉES — Teranga Distribution devant son comité de
direction :

1. CONTEXTE (1 visuel) : "Notre chiffre d'affaires global a
   progressé de 8% cette année." (KPI simple, ton neutre)

2. TENSION (1 visuel) : "Mais cette croissance cache une forte
   disparité entre zones : Thiès recule de -5% pendant que
   Mbour explose à +33%." (graphique en barres, zones triées,
   Thiès et Mbour mis en couleur, les autres en gris)

3. PREUVES (2 visuels) : "Le recul de Thiès coïncide avec une
   hausse des retards de livraison (+40% sur la période)."
   (graphique en ligne croisant CA et taux de retard à Thiès)
   "À l'inverse, Mbour a bénéficié d'un nouvel agent commercial
   recruté en mars." (annotation sur la ligne de tendance Mbour)

4. RÉSOLUTION (1 visuel + texte) : "Recommandation : renforcer
   la logistique de livraison à Thiès et évaluer la réplication
   du modèle Mbour (agent dédié) dans les zones en difficulté."

→ 5 visuels au total, chacun porteur d'UNE SEULE idée, organisés
  selon un fil narratif clair du contexte à la recommandation.

Leçon : le storytelling data n'ajoute pas de fioritures — il ordonne des preuves existantes selon une logique qui mène naturellement à une décision.

Explication pédagogique

Les statistiques descriptives résument un jeu de données en quelques nombres clés, sans prétendre généraliser au-delà des données observées. Elles répondent à la question « que disent mes données, telles quelles ? », par opposition aux statistiques inférentielles qui cherchent à généraliser à une population plus large (traitées à la séquence suivante).

Les indicateurs de tendance centrale résument où se situe « le centre » des données : la moyenne (somme divisée par le nombre de valeurs, sensible aux valeurs extrêmes), la médiane (valeur du milieu quand on trie les données, insensible aux valeurs extrêmes), le mode (valeur la plus fréquente). Les indicateurs de dispersion montrent à quel point les données sont regroupées ou étalées : l'écart-type, l'étendue (max - min), les quartiles.

Le piège le plus fréquent : utiliser uniquement la moyenne sans regarder la dispersion. Une moyenne peut masquer une réalité très hétérogène — un salaire moyen de 300 000 FCFA peut résulter de dix salariés à 300 000 FCFA, ou d'un salarié à 2 000 000 FCFA et neuf à 100 000 FCFA. Dans ce second cas, la médiane raconte une histoire radicalement différente de la moyenne, et c'est elle qui reflète le mieux la situation typique.

Démonstration contextualisée

L'analyse des commandes mensuelles de Teranga Distribution illustre le piège de la moyenne seule :

DONNÉES : montants de 20 commandes du mois (en milliers FCFA) :
15, 18, 12, 20, 16, 14, 19, 17, 13, 15, 500, 18, 16, 14, 20,
15, 17, 19, 13, 16

MOYENNE : (somme / 20) = 41,4 → chiffre TROMPEUR, tiré vers le
          haut par la commande exceptionnelle de 500.

MÉDIANE : 16 → reflète beaucoup mieux la commande "typique"
          de Teranga Distribution.

MODE : 15 et 16 (valeurs les plus fréquentes) → confirme que la
       plupart des commandes tournent autour de 15-16.

ÉCART-TYPE (calculé sur les données brutes) : très élevé, à
cause de la valeur 500 — signal qu'il faut EXAMINER cette valeur
avant de l'inclure dans une moyenne globale (client exceptionnel ?
erreur de saisie ? commande groupée ?).

CONCLUSION : si le dirigeant lit uniquement "commande moyenne =
41 400 FCFA", il se fait une fausse idée de son activité
courante. La médiane (16 000 FCFA) est ici l'indicateur pertinent.

Leçon : ne jamais communiquer une moyenne sans vérifier au moins la médiane et repérer les valeurs extrêmes qui pourraient la fausser.

Explication pédagogique

Les statistiques inférentielles cherchent à généraliser une observation faite sur un échantillon à une population plus large. Contrairement aux statistiques descriptives (qui décrivent les données observées, point final), l'inférence introduit systématiquement de l'incertitude qu'il faut savoir exprimer et respecter.

Un échantillon n'est représentatif que s'il est constitué de façon rigoureuse : une enquête de satisfaction menée uniquement auprès des clients de Dakar ne permet pas de généraliser à l'ensemble du Sénégal. La taille de l'échantillon compte également : dix réponses ne permettent pas la même confiance que mille réponses. Plus l'échantillon est petit ou biaisé, plus l'intervalle d'incertitude autour de toute conclusion doit être large — et honnêtement communiqué.

Un principe central à retenir sans entrer dans le calcul formel : toute généralisation à partir d'un échantillon comporte une marge d'erreur. Dire « 73 % de nos clients sont satisfaits » sur la base de 15 répondants n'a pas la même solidité que le même chiffre sur 1 500 répondants représentatifs. La rigueur consiste à toujours préciser la taille de l'échantillon et la méthode de sélection avant de généraliser une conclusion.

Démonstration contextualisée

ENQUÊTE DE SATISFACTION — Teranga Distribution

SCÉNARIO A (échantillon fragile) :
15 clients interrogés, tous situés à Dakar, recrutés parmi les
plus fidèles (contactés via un programme de fidélité).
→ Résultat : "80% de satisfaction"
→ PROBLÈME : échantillon petit, non représentatif (uniquement
  Dakar, uniquement les clients fidèles). Généraliser ce chiffre
  à "nos clients sont satisfaits à 80%" à l'échelle nationale
  est une erreur d'inférence.

SCÉNARIO B (échantillon solide) :
300 clients interrogés, répartis proportionnellement dans les
6 zones de vente, tirés au hasard dans la base clients complète
(pas seulement les fidèles).
→ Résultat : "68% de satisfaction"
→ Ce chiffre, bien que moins flatteur, est BEAUCOUP plus fiable
  pour orienter une décision nationale.

RÈGLE : avant de généraliser un résultat d'enquête, toujours
vérifier (1) la taille de l'échantillon, (2) sa représentativité
géographique et sociale, (3) le mode de sélection (aléatoire ou
biaisé vers un sous-groupe).

Leçon : un chiffre séduisant issu d'un petit échantillon biaisé est plus dangereux qu'utile — il donne une fausse confiance à une décision mal fondée.

Explication pédagogique

« Corrélation n'est pas causalité » est sans doute le principe statistique le plus important et le plus souvent ignoré. Deux variables peuvent évoluer ensemble (corrélation) sans que l'une soit la cause de l'autre.

Trois explications alternatives à une corrélation observée méritent d'être systématiquement envisagées. La coïncidence pure : sur suffisamment de variables, certaines corrélations apparaissent par hasard, sans aucun lien réel. La causalité inverse : A et B sont corrélées, mais c'est B qui cause A, et non l'inverse qu'on présumait spontanément. La variable cachée (ou facteur de confusion) : une troisième variable C influence à la fois A et B, créant une corrélation entre elles sans lien causal direct — c'est le piège le plus fréquent en contexte professionnel.

Établir une véritable causalité exige généralement une expérimentation contrôlée (comparer un groupe test et un groupe témoin) ou, à défaut, un raisonnement rigoureux excluant les variables cachées plausibles. En l'absence de cette rigueur, la prudence impose de parler de corrélation observée et non de « cause », et de formuler toute recommandation en conséquence, avec la réserve appropriée.

Démonstration contextualisée

OBSERVATION CHEZ TERANGA DISTRIBUTION :
Les zones où les commerciaux passent PLUS de visites par mois
affichent aussi un CHIFFRE D'AFFAIRES plus élevé.
→ Corrélation positive claire entre "nombre de visites" et "CA".

INTERPRÉTATION HÂTIVE (à éviter) :
"Plus de visites commerciales CAUSENT plus de chiffre d'affaires
→ augmentons les visites partout !"

TROIS EXPLICATIONS ALTERNATIVES À EXAMINER :
1. CAUSALITÉ DIRECTE PLAUSIBLE : effectivement, plus de visites
   → plus de ventes conclues. (Peut être vrai, à vérifier.)

2. CAUSALITÉ INVERSE : les commerciaux visitent PLUS SOUVENT
   les zones qui ont DÉJÀ un fort potentiel commercial repéré
   → c'est le potentiel élevé qui cause plus de visites, pas
   l'inverse.

3. VARIABLE CACHÉE : les zones urbaines denses (Dakar, Thiès)
   permettent À LA FOIS plus de visites (proximité géographique
   des clients) ET plus de ventes (densité de population) —
   la vraie cause commune est la DENSITÉ URBAINE, pas les visites
   elles-mêmes.

→ Sans creuser, augmenter les visites dans une zone RURALE peu
  dense pourrait ne produire AUCUN effet sur le CA, contrairement
  à l'extrapolation hâtive.

Leçon : avant de transformer une corrélation en recommandation d'action, examinez systématiquement la causalité inverse et les variables cachées plausibles.

Explication pédagogique

Avant de soumettre un fichier CSV ou Excel à une IA pour analyse, une préparation minimale conditionne la qualité et la fiabilité du résultat. Une IA analysant un fichier mal préparé produira des résultats plausibles mais potentiellement faux, sans le signaler nécessairement.

La checklist de préparation comprend : des en-têtes de colonnes clairs (pas de « Colonne1, Colonne2 » mais des noms explicites), une seule ligne d'en-tête (pas de titres fusionnés sur plusieurs lignes qui perturbent la lecture automatique), des types cohérents par colonne (pas de mélange texte/nombre dans une même colonne), l'absence de cellules fusionnées (qui cassent la structure tabulaire), et une description du contexte à fournir à l'IA en même temps que le fichier (que représente chaque colonne, quelle est l'unité, quelle est la période couverte).

Un principe de sécurité s'ajoute à la préparation technique : avant de soumettre un fichier à une IA en ligne, il faut vérifier qu'aucune donnée personnelle ou confidentielle identifiable ne s'y trouve — noms de clients réels, numéros de téléphone, montants de contrats confidentiels. La règle est la même que dans les formations précédentes : anonymiser ou utiliser des données fictives représentatives.

Démonstration contextualisée

FICHIER BRUT DE TERANGA DISTRIBUTION (à ne PAS soumettre tel quel) :

❌ PROBLÈMES DÉTECTÉS :
• En-tête sur 2 lignes fusionnées ("Ventes" puis "Janvier/Février")
• Colonne "Montant" mélangeant nombres et texte ("15000", "N/A",
  "environ 12000")
• Noms de clients réels et numéros de téléphone en clair
• Cellules fusionnées pour les totaux de zone

✅ FICHIER PRÉPARÉ AVANT SOUMISSION À L'IA :
• En-tête unique : date | zone | produit | montant_fcfa | client_id
• Colonne montant_fcfa : uniquement des nombres, "N/A" remplacé
  par une valeur vide standardisée
• Clients ANONYMISÉS : "client_id" (C001, C002...) au lieu du nom
• Cellules fusionnées supprimées, une ligne = une transaction

DESCRIPTION DE CONTEXTE À FOURNIR À L'IA :
"Ce fichier contient les ventes de Teranga Distribution (PME
fictive de distribution au Sénégal) sur janvier-juin 2025.
Chaque ligne = une transaction. montant_fcfa est en francs CFA.
client_id est anonymisé."

Leçon : le temps investi dans la préparation du fichier est directement proportionnel à la fiabilité de l'analyse IA qui en résultera.

Explication pédagogique

Interroger un fichier de données en langage naturel — via ChatGPT Code Interpreter ou un outil équivalent — permet d'obtenir rapidement des analyses, des graphiques et des synthèses sans écrire de code. Cette capacité démocratise l'analyse de données, mais elle exige la même rigueur de formulation que le prompt engineering vu dans d'autres modules de la formation.

Une bonne demande d'analyse précise : la question exacte (pas « analyse ce fichier » mais « quelle est l'évolution mensuelle du chiffre d'affaires par zone sur les six derniers mois ? »), le format de sortie attendu (tableau, graphique, résumé textuel), et les contraintes de fiabilité (ne pas extrapoler au-delà des données présentes, signaler les valeurs manquantes ou aberrantes plutôt que de les ignorer silencieusement).

Un des grands avantages de cette approche est l'itération rapide : poser une première question, observer le résultat, puis affiner (« peux-tu filtrer uniquement la zone de Thiès ? », « peux-tu trier par ordre décroissant ? »). C'est un dialogue exploratoire, pas une requête unique et figée — exactement la logique d'itération du prompt engineering déjà vue dans les modules consacrés à l'IA.

Démonstration contextualisée

DIALOGUE D'ANALYSE — fichier de ventes Teranga Distribution
(préparé et anonymisé selon la séquence précédente) :

❌ DEMANDE VAGUE : "Analyse ce fichier."
→ Résultat générique, souvent hors sujet par rapport au vrai
  besoin décisionnel.

✅ DEMANDE PRÉCISE (1er tour) :
"Voici un fichier de ventes anonymisé (colonnes : date, zone,
produit, montant_fcfa, client_id). Calcule le chiffre d'affaires
total par zone pour chaque mois de janvier à juin 2025. Présente
le résultat sous forme de tableau. Si des valeurs sont manquantes
ou aberrantes, signale-les au lieu de les ignorer."

✅ ITÉRATION (2e tour) :
"Peux-tu maintenant ne garder que les 3 zones ayant le CA le
plus élevé, et produire un graphique en ligne de leur évolution
sur la période ?"

✅ ITÉRATION (3e tour) :
"La zone de Thiès semble en baisse en avril. Peux-tu isoler les
transactions de Thiès en avril et vérifier s'il y a une raison
visible dans les données (baisse de commandes, retards, etc.) ?"

Leçon : l'analyse en langage naturel fonctionne en dialogue itératif — la première question est rarement la dernière.

Explication pédagogique

Une analyse produite par IA sur un fichier de données doit être vérifiée avant d'être utilisée pour une décision — exactement comme n'importe quelle autre production d'IA vue dans les modules précédents de cette formation. Le risque spécifique ici : une IA qui analyse des données peut faire une erreur de calcul silencieuse, appliquer un filtre incorrect, ou mal interpréter une colonne, tout en présentant un résultat parfaitement formaté et convaincant.

La méthode de vérification comporte trois réflexes systématiques. Le contrôle par recalcul partiel : reprendre manuellement (au tableur) un sous-ensemble simple du calcul et vérifier qu'il correspond au résultat de l'IA. Le contrôle de cohérence globale : le total obtenu par l'IA correspond-il approximativement à ce que l'on sait déjà de l'activité (ordre de grandeur plausible) ? Le contrôle des filtres appliqués : demander explicitement à l'IA de préciser quelles lignes elle a incluses ou exclues, et vérifier que cela correspond à la question posée.

Un réflexe simple et puissant : demander systématiquement à l'IA « montre-moi le détail du calcul » ou « quelles lignes as-tu utilisées pour ce total ? ». Une IA rigoureuse peut expliquer sa méthode ; si l'explication est incohérente ou vague, c'est un signal d'alerte fort.

Démonstration contextualisée

RÉSULTAT PRODUIT PAR L'IA : "Le chiffre d'affaires total de la
zone de Mbour sur le premier semestre 2025 est de 47 500 000 FCFA."

VÉRIFICATION 1 — RECALCUL PARTIEL :
Je prends manuellement les 20 premières lignes de Mbour dans le
tableur et je fais la somme moi-même sur ce sous-ensemble.
→ Le résultat partiel est-il cohérent avec la proportion attendue
  du total annoncé par l'IA ?

VÉRIFICATION 2 — COHÉRENCE GLOBALE :
47,5M FCFA sur 6 mois pour Mbour — est-ce plausible au regard de
l'activité connue de cette zone (nombre de commandes habituelles,
montant moyen par commande) ? Si le chiffre est 10 fois supérieur
à ce qu'on attendait, cela signale probablement une erreur de
filtre (doublons, période mal bornée).

VÉRIFICATION 3 — DEMANDER LE DÉTAIL :
"Quelles lignes exactement as-tu incluses dans ce total ? Le
filtre porte-t-il bien sur la zone 'Mbour' uniquement et sur la
période janvier-juin 2025 uniquement ?"
→ Si l'IA a, par exemple, inclus par erreur des lignes de juillet
  ou mal orthographié "Mbour" dans son filtre, la réponse détaillée
  le révèle.

Leçon : une analyse IA convaincante et bien formatée n'est pas une garantie d'exactitude — les trois vérifications systématiques restent indispensables avant toute décision.

Explication pédagogique

Google Sheets, enrichi d'extensions et de fonctions IA, offre une voie d'automatisation accessible pour des PME qui n'ont pas nécessairement les moyens ou le besoin d'un outil de BI complet. C'est souvent le point de départ le plus réaliste pour une petite structure sénégalaise.

Les capacités utiles à connaître : les fonctions natives avancées (RECHERCHEV/VLOOKUP pour croiser des tables, SOMME.SI.ENS pour des totaux conditionnels multi-critères, des tableaux croisés dynamiques pour résumer rapidement), les extensions IA qui permettent de générer des formules à partir d'une description en langage naturel, et les automatisations simples (Google Apps Script pour des tâches répétitives comme l'envoi automatique d'un résumé hebdomadaire par email).

L'avantage de cette approche pour une PME : elle s'appuie sur un outil déjà largement connu et gratuit, avec une courbe d'apprentissage progressive — on peut commencer par des formules simples et complexifier au fur et à mesure des besoins, sans investissement initial ni changement d'écosystème.

Démonstration contextualisée

AUTOMATISATION PROGRESSIVE — Teranga Distribution dans
Google Sheets :

NIVEAU 1 — Fonctions natives :
=SOMME.SI.ENS(Ventes!D:D; Ventes!C:C; "Thiès"; Ventes!A:A;
">="&DATE(2025;1;1))
→ Total des ventes de la zone Thiès depuis janvier 2025.

NIVEAU 2 — Génération de formule assistée par IA :
Demande en langage naturel : "Je veux le montant total des
ventes par zone pour le mois en cours, dans un nouveau tableau."
→ L'IA propose une formule ou un tableau croisé dynamique adapté,
   que l'on vérifie avant de l'appliquer (même principe de
   vérification que la séquence précédente).

NIVEAU 3 — Automatisation légère (Apps Script) :
Un script simple envoie automatiquement, chaque lundi matin, un
résumé des ventes de la semaine précédente par email au dirigeant
— sans intervention manuelle.

PROGRESSION RECOMMANDÉE : commencer au niveau 1, ne passer au
niveau 3 qu'une fois les niveaux précédents maîtrisés et les
besoins clairement stabilisés.

Leçon : l'automatisation dans Google Sheets se construit par paliers, en partant des fonctions de base avant d'introduire des scripts plus complexes.

Explication pédagogique

Une initiation minimale à Python permet de comprendre ce qu'une IA fait « sous le capot » quand elle analyse un fichier, sans nécessiter de devenir développeur. Deux bibliothèques suffisent pour l'essentiel de l'analyse de données courante : pandas (manipulation de tableaux de données) et matplotlib (création de graphiques).

Les opérations de base à connaître conceptuellement : charger un fichier CSV dans une structure de données appelée « DataFrame » (un tableau manipulable), filtrer des lignes selon une condition, grouper des données par catégorie et calculer une statistique (somme, moyenne) par groupe, et visualiser le résultat par un graphique simple.

L'intérêt pour un non-développeur n'est pas de devenir autonome en programmation, mais de comprendre le raisonnement qui sous-tend une analyse — ce qui permet de mieux formuler des demandes à une IA et de mieux évaluer la plausibilité de ses résultats. Comprendre qu'un groupby (regroupement) peut, par exemple, exclure silencieusement les valeurs manquantes aide à poser la bonne question de vérification à l'IA.

Démonstration contextualisée

PRINCIPE (pas besoin d'écrire ce code soi-même, mais de le
COMPRENDRE quand une IA l'utilise pour analyser Teranga
Distribution) :

# 1. Charger le fichier
donnees = lire_fichier("ventes_teranga.csv")

# 2. Filtrer : ne garder que la zone de Mbour
mbour = donnees[donnees["zone"] == "Mbour"]

# 3. Grouper par mois et sommer les montants
total_par_mois = mbour.grouper_par("mois").sommer("montant_fcfa")

# 4. Visualiser
tracer_graphique(total_par_mois, type="ligne")

CE QUI PEUT MAL SE PASSER (à savoir repérer) :
• Si des lignes ont "mbour" en minuscule et d'autres "Mbour" avec
  majuscule, le filtre peut EXCLURE une partie des données sans
  erreur affichée — juste un résultat incomplet.
• Si des valeurs de montant sont vides, le regroupement peut les
  ignorer silencieusement plutôt que de signaler leur absence.

→ Comprendre cette logique permet de demander à l'IA : "As-tu
  bien pris en compte toutes les variantes d'écriture de 'Mbour' ?
  Y a-t-il des valeurs manquantes que tu as exclues ?"

Leçon : comprendre la logique de base de pandas (filtrer, grouper, visualiser) permet de poser les bonnes questions de vérification à une IA, même sans écrire soi-même de code.

Explication pédagogique

Cet atelier de synthèse du Module 3 mobilise l'ensemble des compétences d'analyse assistée par IA acquises jusqu'ici : préparation du fichier, formulation de questions précises, itération, vérification systématique du résultat, et rédaction d'une conclusion proportionnée au niveau de confiance des données.

L'objectif est de traiter un jeu de données business complet de bout en bout, comme le ferait un analyste dans une PME sénégalaise : depuis le fichier brut jusqu'à une recommandation présentable à un dirigeant, en passant par toutes les étapes de contrôle qualité vues dans ce module et le précédent.

Ce livrable constitue une répétition générale avant le grand atelier intégré du Module 5, qui reprendra une démarche similaire sur un projet plus complet en équipe. La rigueur méthodologique appliquée ici — préparation, question précise, itération, vérification, conclusion prudente — est directement transférable à n'importe quelle analyse future dans votre activité professionnelle.

Démonstration contextualisée

ATELIER COMPLET — Teranga Distribution, analyse business
assistée par IA (Python de base) :

ÉTAPE 1 — PRÉPARATION : fichier de ventes anonymisé, en-têtes
clairs, types cohérents, description de contexte rédigée.

ÉTAPE 2 — QUESTION DÉCISIONNELLE : "Quelle zone présente le
meilleur potentiel de croissance pour le prochain trimestre,
et quels facteurs l'expliquent ?"

ÉTAPE 3 — DIALOGUE ITÉRATIF AVEC L'IA :
 (a) CA par zone et par mois sur les 6 derniers mois
 (b) Isoler les 2 zones à la croissance la plus forte
 (c) Croiser avec le nombre d'agents actifs et le taux de
     retard de livraison par zone

ÉTAPE 4 — VÉRIFICATION : recalcul partiel manuel sur un
échantillon, contrôle de cohérence, demande du détail des
filtres appliqués par l'IA.

ÉTAPE 5 — CONCLUSION PRUDENTE :
"Mbour affiche la croissance la plus forte (+33%), associée à
un agent commercial supplémentaire recruté en mars. Cette
corrélation est cohérente mais n'exclut pas d'autres facteurs
(saisonnalité, événement local) qui mériteraient une
investigation complémentaire avant d'étendre ce modèle à
d'autres zones."

Leçon : la rigueur d'une analyse ne se mesure pas à la sophistication de l'outil utilisé, mais à la qualité de la préparation, de la vérification et de la prudence dans la conclusion.

Explication pédagogique

La gouvernance des données désigne l'ensemble des règles, rôles et processus qui garantissent que les données d'une organisation sont fiables, protégées et utilisées correctement. Elle devient cruciale à mesure qu'une organisation grandit : ce qui fonctionnait de façon informelle avec cinq employés devient risqué et source d'erreurs à cinquante.

Sans gouvernance, les symptômes typiques apparaissent rapidement : plusieurs versions contradictoires du « même » chiffre circulent selon qui l'a calculé, personne ne sait qui est responsable de la mise à jour d'une donnée clé, les accès aux données sensibles ne sont pas contrôlés, et une erreur de saisie se propage sans qu'on puisse en retracer l'origine. Ces symptômes coûtent cher : décisions prises sur des chiffres faux, temps perdu à réconcilier des versions différentes, exposition à des risques de conformité.

La gouvernance n'est pas réservée aux grandes entreprises dotées de directions des systèmes d'information : une PME sénégalaise comme Teranga Distribution a tout intérêt à formaliser, même simplement, qui est responsable de quelles données, quelles règles de qualité s'appliquent, et qui peut accéder à quoi — avant que la croissance ne rende ces questions urgentes et coûteuses à résoudre dans l'urgence.

Démonstration contextualisée

SYMPTÔMES D'ABSENCE DE GOUVERNANCE CHEZ TERANGA DISTRIBUTION :

• Le dirigeant reçoit trois chiffres différents pour "le chiffre
  d'affaires du mois" : celui de la comptabilité (45M), celui de
  l'équipe commerciale (48M), celui du logiciel de caisse (43M).
  → Personne ne sait lequel est le bon, ni pourquoi ils diffèrent.

• Un agent commercial a quitté l'entreprise il y a 3 mois ; son
  compte d'accès au fichier clients est toujours actif.
  → Risque de sécurité non maîtrisé.

• Une erreur de saisie dans le prix d'un produit s'est propagée
  dans 200 factures avant d'être détectée, sans que personne ne
  sache qui a saisi le prix erroné ni quand.

COÛT CONCRET : plusieurs heures perdues chaque mois à réconcilier
les trois chiffres de CA, et un risque de décision erronée si le
dirigeant se fie au chiffre le moins fiable des trois par
méconnaissance.

CE QUE LA GOUVERNANCE APPORTERAIT :
Une SEULE source de vérité désignée pour le CA (avec une règle
claire sur comment elle est calculée), un processus de révocation
des accès au départ d'un salarié, et une traçabilité des
modifications de prix.

Leçon : l'absence de gouvernance ne se voit pas immédiatement — elle se traduit par des coûts cachés (temps perdu, décisions fragiles, risques de sécurité) qui grandissent avec la taille de l'organisation.

Explication pédagogique

La gouvernance des données repose sur des rôles clairement définis, même dans une petite structure où une même personne peut cumuler plusieurs de ces rôles. Quatre rôles reviennent systématiquement dans les cadres de gouvernance : le Data Owner, le Data Steward, le DPO et les utilisateurs.

Le Data Owner (propriétaire de la donnée) est responsable métier d'un domaine de données (par exemple, le responsable commercial est propriétaire des données de vente) : il décide des règles d'usage et de qualité attendues. Le Data Steward (gestionnaire opérationnel) applique concrètement les règles de qualité au quotidien : nettoyage, contrôle, mise à jour. Le DPO (Data Protection Officer, ou responsable de la protection des données) veille spécifiquement à la conformité légale sur les données personnelles — un rôle qui devient obligatoire dans certaines organisations selon la réglementation applicable. Les utilisateurs consomment les données pour leurs décisions quotidiennes, avec des droits d'accès proportionnés à leur besoin réel.

Dans une PME comme Teranga Distribution, ces rôles peuvent être cumulés par une ou deux personnes, mais la clarté sur qui fait quoi reste essentielle : sans cette clarté, personne ne se sent réellement responsable de la qualité des données, et chacun présume que « quelqu'un d'autre » s'en occupe.

Démonstration contextualisée

ATTRIBUTION DES RÔLES CHEZ TERANGA DISTRIBUTION (PME de 25
salariés — rôles cumulés par nécessité) :

DATA OWNER (données de vente) : le responsable commercial —
il décide de la définition officielle du "chiffre d'affaires"
(TTC ou HT ? inclut les retours ou non ?) et des règles de
qualité attendues sur les fichiers de vente.

DATA STEWARD (données de vente) : l'assistante administrative —
elle applique concrètement le nettoyage mensuel (dédoublonnage,
vérification des zones, correction des libellés incohérents).

DPO (protection des données personnelles) : le dirigeant
lui-même, en l'absence d'un poste dédié dans une structure de
cette taille — il s'assure que les données clients (numéros de
téléphone, adresses) sont traitées conformément à la loi
sénégalaise sur la protection des données personnelles.

UTILISATEURS : les agents commerciaux, qui consultent le fichier
clients de LEUR zone uniquement (pas l'ensemble de la base
nationale) — droit d'accès proportionné au besoin réel.

CLARTÉ APPORTÉE : en cas de question sur la fiabilité d'un
chiffre de vente, on sait désormais À QUI s'adresser (le Data
Owner pour la définition, le Data Steward pour un problème de
saisie).

Leçon : même dans une petite structure où les rôles sont cumulés, nommer explicitement qui assume chaque responsabilité évite la dilution de responsabilité qui mène à l'inaction.

Explication pédagogique

La protection des données et le principe de minimisation constituent le socle de la conformité légale, qu'il s'agisse du RGPD européen (pertinent pour les entreprises traitant des données de résidents européens) ou de la loi sénégalaise sur la protection des données à caractère personnel (PDCP), applicable à toute organisation opérant au Sénégal.

Le principe de minimisation est central et simple à retenir : ne collecter que les données réellement nécessaires à la finalité poursuivie, ne les conserver que le temps nécessaire, et ne les partager qu'avec les personnes qui en ont réellement besoin. Une PME qui collecte systématiquement la date de naissance de ses clients sans jamais l'utiliser viole ce principe — c'est une donnée inutile qui n'apporte qu'un risque supplémentaire en cas de fuite.

Les droits fondamentaux des personnes concernées, communs à la plupart des cadres légaux (RGPD, PDCP sénégalaise), incluent : le droit d'accès (savoir quelles données sont détenues à son sujet), le droit de rectification (corriger une donnée erronée), le droit de suppression (demander l'effacement dans certaines conditions), et le droit d'opposition à certains traitements. Une organisation doit être en mesure de répondre à ces demandes, ce qui suppose une organisation minimale de ses données personnelles.

Démonstration contextualisée

AUDIT DE MINIMISATION — fichier clients de Teranga Distribution :

DONNÉES COLLECTÉES ACTUELLEMENT :
Nom, téléphone, adresse, date de naissance, situation familiale,
numéro de pièce d'identité, historique complet des achats.

FINALITÉ RÉELLE : livrer les commandes et facturer les clients.

ANALYSE DE MINIMISATION :
✅ Nom, téléphone, adresse → nécessaires (livraison, contact).
✅ Historique des achats → nécessaire (facturation, service client).
❌ Date de naissance → PAS nécessaire à la livraison ni à la
   facturation. Collectée "au cas où" sans usage réel identifié.
❌ Situation familiale → AUCUN lien avec l'activité de distribution.
⚠️ Numéro de pièce d'identité → à justifier : est-il exigé par une
   obligation légale précise (ex. vente de certains produits
   réglementés) ou collecté par excès de prudence ?

ACTION DE MISE EN CONFORMITÉ :
Cesser la collecte de la date de naissance et de la situation
familiale pour les nouveaux clients ; envisager la suppression de
ces champs pour les clients existants après vérification qu'ils
ne sont utilisés par aucun processus.

RÉPONSE À UN DROIT D'ACCÈS : si un client demande "quelles données
détenez-vous sur moi ?", Teranga doit pouvoir lister l'ensemble
des champs et sources en quelques minutes — ce qui suppose une
cartographie des données déjà réalisée (module précédent).

Leçon : chaque donnée collectée doit pouvoir se justifier par une finalité précise ; à défaut, elle représente un risque sans bénéfice.

Explication pédagogique

Les six dimensions de qualité des données vues au Module 1 (exactitude, exhaustivité, cohérence, fraîcheur, unicité, validité) doivent être transformées en règles de contrôle formalisées et appliquées de façon récurrente pour avoir un effet durable — un contrôle ponctuel unique ne suffit jamais dans la durée.

Une règle de qualité formalisée précise : la dimension concernée, le contrôle exact à effectuer (par exemple, « le champ montant_fcfa doit toujours être un nombre positif »), la fréquence du contrôle (à chaque saisie ? une fois par semaine ? une fois par mois ?), et l'action corrective en cas d'anomalie détectée (qui corrige, comment, dans quel délai).

La mise en place de règles de contrôle ne doit pas viser la perfection immédiate mais la récurrence : mieux vaut un contrôle simple appliqué chaque semaine sans faute, qu'un contrôle sophistiqué jamais réellement exécuté. Pour une PME comme Teranga Distribution, cela peut commencer par une simple check-list manuelle mensuelle avant de s'automatiser progressivement à mesure que les volumes de données grandissent.

Démonstration contextualisée

RÈGLES DE QUALITÉ FORMALISÉES — fichier de ventes Teranga
Distribution :

RÈGLE 1 (validité)
Contrôle : le champ montant_fcfa doit être un nombre positif.
Fréquence : à chaque import mensuel.
Action corrective : toute ligne négative ou non numérique est
isolée et vérifiée manuellement avant intégration.

RÈGLE 2 (unicité)
Contrôle : aucun id_vente ne doit apparaître deux fois.
Fréquence : à chaque import mensuel (contrôle automatisable
par une formule de comptage de doublons).
Action corrective : les doublons détectés sont signalés à
l'agent responsable de la zone concernée pour clarification.

RÈGLE 3 (cohérence)
Contrôle : le nom de chaque zone doit correspondre exactement
à l'une des 6 zones officielles de la table Zones (pas de
variante d'orthographe).
Fréquence : à chaque import mensuel.
Action corrective : harmonisation automatique via une table de
correspondance, ou correction manuelle si non reconnu.

RÈGLE 4 (fraîcheur)
Contrôle : la table des agents commerciaux ne doit pas dater de
plus d'un mois.
Fréquence : contrôle mensuel systématique.
Action corrective : mise à jour par les ressources humaines
avant le calcul des indicateurs du mois.

Leçon : une règle de qualité n'a de valeur que si elle précise le contrôle exact, sa fréquence et l'action corrective — sans ces trois éléments, elle reste une bonne intention sans effet réel.

Explication pédagogique

Une politique de gestion des données formalise, pour l'ensemble d'une organisation, les règles vues dans ce module : rôles, règles de qualité, protection des données personnelles. C'est le document qui transforme des bonnes pratiques individuelles en engagement collectif durable, transmissible à un nouvel employé sans tout réexpliquer oralement.

Une politique utile pour une PME reste courte, concrète et applicable — un document de deux pages réellement appliqué vaut infiniment mieux qu'un document de vingt pages jamais lu. Elle couvre typiquement : les rôles et responsabilités (qui est Data Owner de quoi), les règles de qualité minimales (les contrôles non négociables), les règles de protection des données personnelles (minimisation, durée de conservation, droits des personnes), les règles d'accès (qui peut voir quoi), et une procédure en cas d'incident (que faire si une fuite ou une erreur grave est détectée).

Le succès d'une politique de gestion des données se mesure à son appropriation réelle par les équipes, pas à son exhaustivité théorique. Elle doit être présentée, expliquée, et révisée périodiquement à mesure que l'organisation évolue — un document figé et oublié dans un tiroir ne protège personne.

Démonstration contextualisée

POLITIQUE DE GESTION DES DONNÉES — Teranga Distribution
(version courte et applicable) :

1. RÔLES
   Responsable commercial = Data Owner des ventes.
   Assistante administrative = Data Steward.
   Dirigeant = référent protection des données (DPO informel).

2. RÈGLES DE QUALITÉ MINIMALES
   Contrôle mensuel des doublons et de la cohérence des zones
   avant tout calcul d'indicateur (voir séquence précédente).

3. PROTECTION DES DONNÉES PERSONNELLES
   Collecte limitée aux champs nécessaires (nom, téléphone,
   adresse, historique d'achat). Conservation 3 ans après le
   dernier achat, puis suppression ou anonymisation.

4. RÈGLES D'ACCÈS
   Les agents commerciaux voient uniquement les clients de leur
   zone. Le fichier complet est accessible au responsable
   commercial et au dirigeant uniquement.

5. EN CAS D'INCIDENT
   Toute suspicion de fuite ou d'erreur grave de données est
   signalée immédiatement au dirigeant, qui évalue les mesures
   à prendre (correction, notification aux personnes concernées
   si nécessaire selon la loi PDCP).

DIFFUSION : ce document est présenté à chaque nouvel employé
et revu une fois par an.

Leçon : une politique de deux pages, connue et appliquée, protège infiniment mieux qu'un document exhaustif que personne n'a lu.

Explication pédagogique

Cette séquence de synthèse du Module 4 consiste à élaborer un plan d'amélioration de la culture data réaliste pour une organisation, en s'appuyant sur l'ensemble des notions de gouvernance et de qualité vues précédemment : rôles, protection des données, règles de qualité, politique formalisée.

Un bon plan d'amélioration évite deux écueils opposés. Le premier est l'ambition démesurée : vouloir tout mettre en place en même temps (gouvernance complète, outils sophistiqués, politique exhaustive) sans tenir compte des ressources réelles disponibles, ce qui conduit généralement à l'abandon du projet après un démarrage enthousiaste. Le second est l'inaction par excès de prudence : attendre d'avoir les moyens d'un dispositif parfait avant de commencer, ce qui retarde indéfiniment les premières améliorations, pourtant simples et à fort impact.

La bonne approche est progressive et priorisée : identifier les deux ou trois actions à plus fort impact et à plus faible coût (souvent liées à la clarification des rôles et à quelques règles de qualité de base), les mettre en œuvre rapidement, puis élargir progressivement le dispositif à mesure que l'organisation en constate les bénéfices concrets.

Démonstration contextualisée

PLAN D'AMÉLIORATION DE LA CULTURE DATA — Teranga Distribution
(approche progressive, priorisée par impact/coût) :

PRIORITÉ 1 (fort impact, faible coût — à faire immédiatement) :
• Désigner explicitement un Data Owner par domaine de données
  (ventes, clients, stock) — coût : une réunion d'une heure.
• Définir UNE source de vérité officielle pour le chiffre
  d'affaires mensuel, éliminant les trois versions concurrentes.

PRIORITÉ 2 (impact moyen, coût modéré — dans les 3 mois) :
• Mettre en place les 4 règles de qualité formalisées (séquence
  27) avec un contrôle mensuel simple, même manuel au départ.
• Réviser les droits d'accès au fichier clients selon le
  principe du besoin réel.

PRIORITÉ 3 (impact à plus long terme — dans les 6-12 mois) :
• Rédiger et diffuser la politique complète de gestion des
  données (5 rubriques).
• Automatiser progressivement les contrôles de qualité
  (formules Google Sheets, puis éventuellement Power BI).

CE QU'ON ÉVITE DÉLIBÉRÉMENT AU DÉPART :
Un projet de gouvernance "complet" avec un outil de gestion des
métadonnées sophistiqué — hors de portée et hors de proportion
pour une PME de 25 salariés à ce stade.

Leçon : un plan d'amélioration réaliste priorise les actions à fort impact et faible coût, et construit la maturité data progressivement plutôt que d'un seul bloc.

Explication pédagogique

Ce Module 5 est un projet data de bout en bout, décliné en sept étapes qui reproduisent fidèlement le cycle complet d'un projet professionnel : cadrage, collecte, nettoyage, analyse, visualisation, recommandations et gouvernance. Cette première étape — le cadrage de la question décisionnelle — est la plus déterminante : un projet data mal cadré au départ produit, même avec les meilleurs outils, une analyse techniquement correcte mais inutile.

Cadrer une question décisionnelle suppose de répondre précisément à quatre points. Quelle décision doit être éclairée par cette analyse (pas « comprendre les ventes » mais « décider où renforcer l'équipe commerciale au prochain trimestre ») ? Qui prendra cette décision et à quelle échéance ? Quel niveau de preuve est nécessaire pour agir (une tendance suffit-elle, ou faut-il une certitude statistique forte) ? Quelles contraintes pèsent sur le projet (délai, données disponibles, budget) ?

Un principe à retenir tout au long de cet atelier intégré : chaque étape suivante (collecte, nettoyage, analyse, visualisation) doit rester reliée à la question décisionnelle initiale. Un projet qui s'égare dans une exploration de données fascinante mais déconnectée de la décision à prendre est un projet qui échoue à sa mission, même s'il produit des résultats techniquement impressionnants.

Démonstration contextualisée

CADRAGE DU PROJET — Teranga Distribution, atelier intégré :

❌ QUESTION MAL CADRÉE : "Analysons nos données de vente pour
   mieux comprendre notre activité."
   → Trop vague ; ne débouchera sur aucune décision précise.

✅ QUESTION BIEN CADRÉE :
   "Sur quelles zones et quels produits Teranga Distribution
   devrait-elle concentrer ses efforts commerciaux au prochain
   trimestre, pour maximiser la croissance du chiffre d'affaires
   tout en maîtrisant les retards de livraison ?"

DÉCOMPOSITION DU CADRAGE :
• DÉCISION : réallocation de l'effort commercial (agents,
  stocks) entre zones pour le trimestre à venir.
• QUI DÉCIDE : le dirigeant, sur recommandation de l'équipe
  projet, avant le 15 du mois prochain.
• NIVEAU DE PREUVE NÉCESSAIRE : une tendance claire sur 6 mois
  suffit (pas besoin d'une certitude statistique absolue pour
  ce type de décision opérationnelle réversible).
• CONTRAINTES : données disponibles limitées aux 6 derniers
  mois ; budget d'analyse = temps de l'équipe uniquement (pas
  d'outil payant supplémentaire) ; délai = 2 semaines pour
  l'ensemble du projet.

CETTE QUESTION CADRÉE GUIDERA LES 6 ÉTAPES SUIVANTES.

Leçon : les deux tiers du succès d'un projet data se jouent dans la qualité du cadrage initial, avant même d'ouvrir le premier fichier de données.

Explication pédagogique

La collecte des données nécessaires au projet et la constitution d'un dictionnaire de données forment la deuxième étape. Un dictionnaire de données est un document qui décrit, pour chaque colonne d'un jeu de données, sa signification exacte, son format, son unité et sa source — un outil simple mais souvent négligé, qui évite des malentendus coûteux entre les membres d'une équipe projet.

La collecte s'appuie sur la cartographie des sources vue au Module 1 : identifier précisément quelles sources internes et externes sont nécessaires pour répondre à la question cadrée à l'étape précédente, et rassembler ces données dans un format exploitable. À ce stade, il ne s'agit pas encore de nettoyer les données (étape suivante), mais de s'assurer qu'on dispose de toutes les données nécessaires, sans en avoir oublié une source essentielle.

Le dictionnaire de données répond à des questions simples mais essentielles pour éviter les erreurs d'interprétation ultérieures : que signifie exactement la colonne « montant » (TTC ou HT ? inclut-elle les remises ?) ? Que signifie une valeur vide dans la colonne « zone » (donnée manquante, ou zone non applicable) ? Quelle est l'unité de la colonne « délai » (jours ou heures) ?

Démonstration contextualisée

DICTIONNAIRE DE DONNÉES — projet Teranga Distribution :

Colonne          | Signification            | Format | Unité  | Source
-----------------|--------------------------|--------|--------|------------------
date              | Date de la transaction   | JJ/MM/AAAA | -  | Logiciel caisse
zone              | Zone de vente (6 valeurs | Texte  | -      | Table Zones
                  | possibles, cf. liste)    |        |        |
montant_fcfa      | Montant TTC de la vente, | Nombre | FCFA   | Logiciel caisse
                  | REMISES DÉJÀ DÉDUITES    |        |        |
delai_livraison   | Délai entre commande et  | Nombre | JOURS  | Registre
                  | livraison effective      |        |(pas heures) | livraisons
                  |                          |        |        | (papier, saisi
                  |                          |        |        | manuellement)
agent_id          | Identifiant de l'agent   | Texte  | -      | RH
                  | commercial responsable   |        |        |

COLLECTE — SOURCES NÉCESSAIRES POUR LA QUESTION CADRÉE :
1. Logiciel de caisse (ventes, montants) — disponible, format OK.
2. Table Zones (référentiel) — disponible.
3. Registre de livraisons — SEULEMENT PAPIER, à numériser
   manuellement pour les 6 derniers mois (tâche identifiée
   comme nécessaire, à intégrer au planning du projet).
4. Fichier RH des agents (dates d'affectation par zone) —
   disponible mais non mis à jour depuis 2 mois (à vérifier).

Leçon : un dictionnaire de données rédigé en amont évite des malentendus qui, découverts tardivement (par exemple, un montant qu'on croyait HT et qui était en réalité TTC), peuvent invalider tout le travail d'analyse déjà réalisé.

Explication pédagogique

Le nettoyage des données collectées applique concrètement les six dimensions de qualité vues au Module 1 : exactitude, exhaustivité, cohérence, fraîcheur, unicité, validité. Cette étape est souvent la plus chronophage d'un projet data réel — et la plus fréquemment sous-estimée par les débutants pressés d'arriver aux résultats.

La traçabilité du nettoyage est aussi importante que le nettoyage lui-même : documenter précisément quelles modifications ont été apportées aux données brutes (combien de doublons supprimés, combien de valeurs corrigées, quelles lignes exclues et pourquoi) permet de justifier la méthode auprès de toute personne qui contesterait le résultat final, et de reproduire le nettoyage si de nouvelles données arrivent.

Une règle de bonne pratique : ne jamais modifier le fichier brut original. Le nettoyage doit toujours produire un nouveau fichier (ou un nouvel onglet), en conservant l'original intact — ce qui permet de revenir en arrière si une erreur de nettoyage est détectée, et de vérifier a posteriori la légitimité de chaque transformation appliquée.

Démonstration contextualisée

JOURNAL DE NETTOYAGE — projet Teranga Distribution :

FICHIER BRUT : ventes_teranga_brut.csv (jamais modifié, conservé
intact comme référence).
FICHIER NETTOYÉ : ventes_teranga_nettoye.csv (nouveau fichier).

ACTIONS DE NETTOYAGE DOCUMENTÉES :
1. DOUBLONS : 7 lignes identiques détectées et supprimées
   (même id_vente en double) → traçé dans le journal.
2. COHÉRENCE DES ZONES : "Thies", "THIES", "Thiès" harmonisés
   en "Thiès" (12 lignes concernées) selon la table Zones de
   référence.
3. VALIDITÉ DES MONTANTS : 3 lignes avec montant négatif isolées
   et vérifiées manuellement — il s'agissait en réalité de
   remboursements mal codés, recodés en conséquence.
4. EXHAUSTIVITÉ : 4% des lignes sans zone renseignée — décision
   documentée de les EXCLURE de l'analyse par zone (mais de les
   conserver pour le calcul du chiffre d'affaires global).
5. FRAÎCHEUR : la table des agents, non mise à jour depuis 2
   mois (détectée à l'étape précédente), a été actualisée avant
   le croisement avec les ventes.

RÉSUMÉ CHIFFRÉ (pour traçabilité) :
"Sur 1 240 lignes brutes, 7 doublons supprimés, 12 libellés de
zone harmonisés, 3 montants négatifs recodés, 50 lignes (4%)
exclues de l'analyse par zone pour absence de zone renseignée.
Fichier nettoyé final : 1 233 lignes exploitables."

Leçon : un nettoyage tracé et documenté transforme une manipulation potentiellement opaque en une méthode vérifiable et reproductible.

Explication pédagogique

L'analyse exploratoire mobilise les compétences statistiques et d'analyse assistée par IA vues aux Modules 2 et 3 : statistiques descriptives, recherche de corrélations (avec la prudence nécessaire sur la causalité), et dialogue itératif avec un outil IA sur le fichier nettoyé — toujours reliée à la question décisionnelle cadrée en étape 1.

L'exploration procède généralement du général au particulier : d'abord une vue d'ensemble (tendances globales, moyennes, médianes), puis des zooms progressifs sur les segments les plus pertinents au regard de la question posée (les zones ou produits qui se distinguent, en positif comme en négatif). Chaque piste explorée doit être immédiatement reliée à la question décisionnelle : « cette observation m'aide-t-elle à répondre à la question cadrée, ou est-ce une digression intéressante mais hors sujet ? ».

Cette étape applique concrètement les réflexes de vérification vus au Module 3 : tout résultat produit par un outil IA sur le fichier nettoyé doit être contrôlé (recalcul partiel, cohérence globale, détail des filtres) avant d'être retenu comme un constat fiable pour la suite du projet.

Démonstration contextualisée

ANALYSE EXPLORATOIRE — projet Teranga Distribution
(rappel de la question cadrée : où concentrer l'effort commercial
au prochain trimestre ?) :

NIVEAU 1 — VUE D'ENSEMBLE :
CA total en hausse de +8% sur 6 mois ; médiane du panier moyen
stable ; délai de livraison moyen en légère hausse (+2 jours).

NIVEAU 2 — ZOOM PAR ZONE (question centrale) :
Mbour +33%, Thiès -5%, les 4 autres zones stables autour de +5%.
→ Deux zones extrêmes méritent une investigation approfondie.

NIVEAU 3 — CROISEMENT AVEC FACTEURS EXPLICATIFS :
Mbour : recrutement d'un agent supplémentaire en mars (corrélation
avec la hausse, causalité plausible mais à nuancer — cf. Module 3
sur corrélation/causalité).
Thiès : hausse du délai de livraison (+40%) sur la même période
— corrélation avec la baisse des ventes, hypothèse de causalité
plausible (clients mécontents des retards) à confirmer.

VÉRIFICATION APPLIQUÉE : recalcul manuel partiel du CA de Mbour
sur un échantillon de 20 lignes, cohérent avec le résultat de
l'IA ; demande du détail du filtre zone appliqué, confirmé correct.

RETOUR À LA QUESTION CADRÉE : ces deux constats (Mbour et Thiès)
répondent directement à la question "où concentrer l'effort
commercial" — l'exploration reste bien focalisée, sans digression.

Leçon : une bonne analyse exploratoire progresse du général au particulier tout en restant continuellement reliée à la question décisionnelle initiale.

Explication pédagogique

La construction du tableau de bord final applique les principes de visualisation efficace, de choix de graphique et de hiérarchie visuelle vus au Module 2, cette fois sur les résultats réels de l'analyse exploratoire de l'étape précédente, dans l'outil de votre choix (Power BI ou Looker Studio).

Le tableau de bord de cette étape ne doit pas chercher à montrer l'ensemble de l'exploration réalisée, mais uniquement les trois à cinq visuels qui répondent directement à la question décisionnelle cadrée en étape 1 — en appliquant la règle de sobriété et de priorisation déjà vue en Module 2. Chaque visuel retenu doit passer le test : « ce graphique aide-t-il concrètement le décideur à trancher la question posée ? ».

Cette étape est aussi l'occasion d'appliquer concrètement les règles anti-manipulation vues au Module 2 : axes démarrant à zéro pour les barres, pas de doubles échelles trompeuses, hiérarchie visuelle claire mettant en avant l'élément le plus important pour la décision à prendre.

Démonstration contextualisée

TABLEAU DE BORD FINAL — projet Teranga Distribution
(question : où concentrer l'effort commercial au trimestre
prochain ?) :

VISUEL 1 (KPI, niveau 1 de hiérarchie) :
"Croissance moyenne du CA : +8% sur 6 mois" — grand chiffre,
couleur d'accent, en haut de page.

VISUEL 2 (comparaison, niveau 2) :
Graphique en barres du CA par zone, TRIÉ décroissant, axe à
ZÉRO, avec Mbour et Thiès mis en couleur (les autres en gris)
pour attirer l'œil sur les deux cas extrêmes pertinents.

VISUEL 3 (tendance, niveau 2) :
Graphique en ligne croisant l'évolution du CA et du délai de
livraison à Thiès sur 6 mois, pour visualiser la corrélation
observée.

VISUEL 4 (détail, niveau 3, discret) :
Tableau détaillé des indicateurs par zone, consultable mais non
mis en avant visuellement.

CE QUI N'EST PAS INCLUS : l'ensemble des explorations secondaires
menées à l'étape précédente qui ne répondaient pas directement à
la question (par exemple, l'analyse par produit, intéressante
mais hors du cadrage initial) — gardées en annexe si besoin, mais
pas dans le tableau de bord principal.

Leçon : le tableau de bord final ne montre pas tout ce qui a été exploré — il montre seulement ce qui répond à la question décisionnelle, selon une hiérarchie visuelle claire.

Explication pédagogique

La formulation des recommandations et le storytelling final transforment l'analyse et le tableau de bord en un message actionnable, en appliquant la structure narrative en quatre temps (contexte, tension, preuves, résolution) vue au Module 2.

Une bonne recommandation issue d'un projet data respecte plusieurs exigences. Elle est actionnable : elle propose une action concrète, pas seulement un constat. Elle est proportionnée au niveau de preuve obtenu : si l'analyse repose sur une corrélation non confirmée par une causalité solide (cf. Module 3), la recommandation doit être formulée avec la prudence appropriée, éventuellement assortie d'une proposition de vérification complémentaire avant un déploiement à grande échelle. Elle est chiffrée quand c'est possible : « renforcer l'équipe » est vague, « ajouter un agent commercial supplémentaire, sur le modèle du recrutement de mars à Mbour » est actionnable.

La présentation finale doit suivre la structure narrative complète : planter le contexte, exposer la tension (l'écart entre zones), présenter les preuves (tableau de bord), et conclure par la résolution recommandée — avec la mention explicite des incertitudes restantes et des vérifications complémentaires suggérées, en toute honnêteté intellectuelle.

Démonstration contextualisée

RECOMMANDATION FINALE — projet Teranga Distribution :

CONTEXTE : "Le chiffre d'affaires global de Teranga Distribution
a progressé de 8% sur le premier semestre 2025."

TENSION : "Cette croissance masque une forte disparité : Mbour
progresse de +33% pendant que Thiès recule de -5%."

PREUVES : tableau de bord présentant l'évolution par zone, la
corrélation entre le recrutement d'un agent à Mbour et sa
croissance, et la corrélation entre la hausse des délais de
livraison et le recul de Thiès.

RECOMMANDATION (résolution) :
"1. Recruter un agent commercial supplémentaire à Thiès, sur le
   modèle du recrutement de mars à Mbour, dont l'effet semble
   positif.
2. Investiguer en priorité la cause des retards de livraison à
   Thiès (+40%) avant tout renforcement commercial, car un
   effort commercial supplémentaire serait peu efficace si les
   clients restent mécontents des délais.
3. Ces deux recommandations reposent sur une corrélation
   observée sur 6 mois seulement — nous suggérons de confirmer
   la tendance sur un second semestre avant un déploiement à
   plus grande échelle dans d'autres zones."

→ Recommandation actionnable, chiffrée quand possible, et
  honnête sur le niveau de preuve encore incertain.

Leçon : une recommandation professionnelle assume et communique explicitement son niveau d'incertitude, plutôt que de présenter une conclusion comme définitive alors qu'elle ne l'est pas encore.

Explication pédagogique

La dernière étape du projet intégré porte sur la gouvernance et le plan de déploiement des enseignements du projet, en appliquant les notions du Module 4 : comment pérenniser les bonnes pratiques mises en œuvre pendant ce projet ponctuel, au-delà de la restitution finale ?

Un projet data réussi produit deux types de valeur : la valeur immédiate (la recommandation elle-même, pour la décision en cours) et la valeur durable (les processus, règles de qualité et outils mis en place pendant le projet, qui peuvent être réutilisés pour les analyses futures). Trop de projets data s'arrêtent à la restitution finale sans capitaliser sur cette seconde valeur — chaque nouveau projet repart alors de zéro.

Cette étape formalise donc un plan de déploiement qui répond à plusieurs questions : quelles règles de qualité mises en place pendant le projet (dictionnaire de données, nettoyage tracé) doivent devenir des pratiques permanentes ? Le tableau de bord construit doit-il être mis à jour régulièrement (et par qui) ? Quelles leçons de gouvernance (rôles, accès) tirées de ce projet méritent d'être généralisées à d'autres domaines de données de l'organisation ?

Démonstration contextualisée

PLAN DE GOUVERNANCE ET DÉPLOIEMENT — projet Teranga Distribution :

VALEUR IMMÉDIATE (la recommandation) :
Recrutement à Thiès + investigation des retards de livraison
(déjà formulés à l'étape précédente).

VALEUR DURABLE À PÉRENNISER :
1. Le DICTIONNAIRE DE DONNÉES construit pour ce projet (étape 2)
   devient le référentiel officiel du fichier de ventes,
   maintenu à jour par le Data Steward désigné.
2. Le PROCESSUS DE NETTOYAGE TRACÉ (étape 3) devient une routine
   mensuelle appliquée par l'assistante administrative, avec le
   même niveau de documentation.
3. Le TABLEAU DE BORD (étape 5) est mis à jour mensuellement par
   le Data Steward, et non recréé à chaque fois — sa maintenance
   est budgétée comme une tâche récurrente (30 minutes par mois).

GÉNÉRALISATION DES LEÇONS DE GOUVERNANCE :
La désignation claire d'un Data Owner et d'un Data Steward pour
le domaine "ventes", testée avec succès dans ce projet, est
étendue au domaine "stock" et au domaine "clients" dans les
trois mois suivants.

RESPONSABLE DU SUIVI : le responsable commercial (Data Owner)
vérifie trimestriellement que ce dispositif reste appliqué et
que le tableau de bord continue d'être mis à jour.

Leçon : un projet data qui ne laisse aucune trace durable au-delà de sa restitution finale gaspille une grande partie de sa valeur potentielle — la gouvernance transforme un effort ponctuel en capacité permanente.

Explication pédagogique

Cette évaluation finale valide les acquis de l'ensemble du parcours — comprendre les données, visualiser efficacement, analyser avec l'IA, gouverner la qualité et la protection des données — et prépare le plan de transfert à 30 jours, le pont entre la formation et son application réelle dans votre activité professionnelle.

L'évaluation couvre les cinq modules : comprendre les données (M1), visualisation et tableaux de bord (M2), analyse assistée par IA (M3), gouvernance et qualité (M4), et l'atelier pratique intégré (M5). Chaque erreur au quiz désigne une séquence à revoir : l'évaluation sert la progression, pas le jugement.

Le plan de transfert à 30 jours organise la mise en pratique en jalons datés et mesurables. J+1 : identifier une décision réelle de votre poste qui pourrait s'appuyer sur des données, et cartographier les sources disponibles. J+7 : construire un premier tableau de bord simple (trois visuels maximum) sur cet indicateur, en appliquant les règles de visualisation honnête. J+15 : formaliser au moins une règle de qualité des données et désigner informellement un Data Owner pour ce domaine. J+30 : mesurer l'usage réel du tableau de bord dans une décision effectivement prise, et identifier un second indicateur à outiller. Un principe encadre le tout : un bon score valide la compréhension, mais seule la pratique régulière sur vos données réelles construit la culture data durable.

Démonstration contextualisée

PLAN DE TRANSFERT À 30 JOURS :

J+1  : Identifier 1 décision réelle de mon poste qui pourrait
       s'appuyer sur des données. Cartographier les sources
       disponibles (internes/externes).
       Résultat mesurable : une question décisionnelle cadrée.

J+7  : Construire un premier tableau de bord simple (3 visuels
       max) sur cet indicateur, avec axes honnêtes et hiérarchie
       visuelle claire.
       Résultat mesurable : tableau de bord fonctionnel produit.

J+15 : Formaliser 1 règle de qualité des données (contrôle,
       fréquence, action corrective) et désigner un Data Owner
       informel pour ce domaine.
       Résultat mesurable : règle écrite et rôle assigné.

J+30 : Vérifier que le tableau de bord a réellement servi à une
       décision prise ; identifier un second indicateur à
       outiller pour le mois suivant.
       Résultat mesurable : décision documentée + nouveau
       chantier identifié.

→ Chaque jalon : une action concrète et un résultat mesurable,
  appliqué à VOS données réelles, pas à un exercice théorique.

Leçon : la culture data ne se construit pas par la formation seule, mais par l'application répétée et mesurée sur des décisions réelles du quotidien professionnel.