🎤 Module 20 — Storytelling + IA

Bootcamp Data Analyst — From Zero to Hero | Niveau Intermédiaire · Module 20

🎯 Ce que tu seras capable de faire à la fin de ce module

Situer les différentes façons dont l'IA s'invite dans le travail d'un∙e DA (copilote de code, analyste autonome type Julius.ai, partenaire de communication) et connaître les limites documentées des outils d'analyse autonome
Expliquer pourquoi une analyse juste mais mal présentée échoue à générer une décision
Structurer une présentation avec le Pyramid Principle (Barbara Minto) : message principal d'abord, arguments ensuite, preuves détaillées en dernier
Construire une accroche avec le framework SCQA (Situation, Complication, Question, Answer)
Organiser tes arguments selon le principe MECE (mutuellement exclusifs, collectivement exhaustifs)
Utiliser l'IA pour challenger ton propre argumentaire avant de le présenter
Utiliser l'IA pour simuler les questions d'un décideur et arriver préparé·e en réunion

⏱️ Durée estimée : 1h30 🛠️ Outils : Claude / ChatGPT (ou équivalent) — aucun nouvel outil technique dans ce module 📌 Prérequis : Modules 16-17 (contexte ANSUT-CI/MobiCI réutilisé dans l'exemple), Module 18 (distinction corrélation/causalité mobilisée en section 5)

1. Le paysage de l'IA pour un∙e data analyst

Ce module est le seul du niveau intermédiaire explicitement consacré à l'IA — c'est l'occasion de prendre un peu de recul. Jusqu'ici, tu as déjà croisé l'IA une fois dans le bootcamp : au Module 09 (niveau débutant), pour t'aider à écrire du SQL plus vite, avec toujours la même règle d'or — c'est toi qui vérifies, l'IA ne fait que proposer. Mais ce n'est qu'une des façons dont l'IA s'invite aujourd'hui dans le travail d'un∙e DA. Avant de se concentrer sur la communication (le sujet du reste de ce module), il vaut la peine de voir le paysage complet.

On peut distinguer trois grandes familles d'usage :

Famille	Ce que ça fait	Tu restes aux commandes	Exemple
Copilote de code	L'IA t'aide à écrire une requête, un script, une formule — mais c'est toi qui l'exécutes, la relis et la corriges	Oui, entièrement	Claude/ChatGPT pour du SQL (Module 09)
Analyste autonome	Tu donnes un fichier de données et une question en langage naturel ; l'IA écrit et exécute le code elle-même, et te renvoie directement un graphique ou un résultat	Partiellement — le code tourne sans que tu l'aies écrit toi-même	Julius.ai, ChatGPT (analyse de données avancée), Claude (analyse de fichiers)
Partenaire de communication	Tu donnes à l'IA un rôle (relecteur sceptique, décideur qui pose des questions) pour préparer ta présentation, pas pour analyser tes données	Oui, l'IA ne touche jamais aux données	Les deux techniques du reste de ce module

Ce module se concentre sur la troisième famille. Mais la deuxième — les outils qui analysent tes données pour toi, comme Julius.ai — mérite qu'on s'y arrête, parce qu'elle change quelque chose d'important dans le métier : ce ne sont plus seulement des outils qui t'aident à aller plus vite, ce sont des outils qui peuvent produire un résultat fini (un graphique, une statistique) sans que tu aies écrit une seule ligne de code.

1.1 Comment fonctionnent ces outils "analyste autonome"

Le principe est le même chez Julius.ai, dans la fonction analyse de données avancée de ChatGPT (anciennement "Code Interpreter", disponible sur les offres payantes), et dans la fonction d'analyse de fichiers de Claude : tu déposes un fichier (CSV, Excel...), tu poses une question en français ou en anglais ("quelle est la ville avec le plus de désabonnements ce trimestre ?"), et l'outil :

Écrit lui-même du code (le plus souvent du Python — pandas, matplotlib — parfois du R) pour répondre à ta question ;
Exécute ce code dans un environnement isolé (un "sandbox"), comme si c'était toi qui appuyais sur "Run" ;
Te renvoie le résultat — un graphique, un tableau, un chiffre — accompagné d'une explication en langage naturel.

Le point le plus important à retenir, pour quelqu'un qui vient de passer plusieurs modules à apprendre pandas, dplyr et SQL : ce n'est pas une boîte noire. Ces trois outils permettent d'afficher le code Python exact qui a été exécuté (chez Julius.ai, un bouton "Show Code" ; chez ChatGPT, un panneau "View analysis" sous la réponse). Ce code est lisible, copiable, et modifiable — exactement le genre de code que tu sais maintenant lire, grâce aux Modules 14 et 15. Cette capacité à vérifier ce que l'IA a réellement fait, plutôt que de faire confiance au graphique produit, est ce qui distingue un usage rigoureux d'un usage naïf de ces outils.

💡 Ces trois outils évoluent vite (fonctionnalités, tarifs, limites de taille de fichier changent régulièrement) — les détails ci-dessous sont indicatifs au moment de la rédaction de ce module, vérifie toujours l'état actuel de l'outil avant de t'y fier pour un vrai projet.

1.2 Ce qu'il faut savoir avant de s'y fier

Ces outils sont impressionnants en démo, mais ils héritent d'un défaut bien connu des IA génératives : ils peuvent produire un résultat qui a l'air juste, avec un graphique propre et une explication assurée, alors qu'il est faux. Quelques points documentés, à connaître avant d'utiliser ce type d'outil sur un vrai dossier :

Les noms de colonnes ambigus sont un piège classique. Si une colonne s'appelle val_x_2_final plutôt que montant_facture, plusieurs utilisateurs de Julius.ai rapportent que l'outil "devine" ce que représente la colonne plutôt que de demander une clarification — et construit son analyse sur cette supposition, sans le signaler clairement.
Un cas documenté avec ChatGPT : un∙e journaliste de données a testé l'analyse de données avancée de ChatGPT sur des statistiques sportives (des tableaux NBA extraits de PDF) et a trouvé des erreurs discrètes mais réelles — des noms mal orthographiés, des lignes manquantes, un graphique en barres avec plusieurs valeurs fausses, causées par un signe pourcentage (%) dans les données source que le code généré n'avait pas géré correctement. Le résultat avait l'air propre ; il ne l'était pas.
La cohérence n'est pas garantie : poser exactement la même question sur le même fichier peut produire un code différent — et donc un résultat différent — d'une fois à l'autre.
Un risque plus technique, documenté par Anthropic elle-même pour Claude : parce que ces outils exécutent du code dans un environnement qui peut avoir un accès limité à internet, un fichier piégé (ou une page web récupérée) pourrait en théorie manipuler l'IA pour qu'elle exécute du code non désiré ou tente d'exfiltrer des données sensibles. Ce n'est pas une raison de ne jamais utiliser ces outils, mais une raison de ne pas leur confier de données sensibles sans en comprendre les garde-fous.

La conclusion n'est pas "n'utilise jamais ces outils" — ils sont réellement utiles pour explorer rapidement un fichier ou dégrossir une première analyse. La conclusion, cohérente avec tout ce que tu as appris dans ce bootcamp, est la même que pour l'IA copilote de code au Module 09 : le résultat d'une IA n'est jamais une vérité à accepter telle quelle — c'est un brouillon à vérifier, avec les mêmes réflexes que tu appliquerais à ton propre code : relire, tester sur un sous-ensemble connu, et cliquer sur "Show code" ou "View analysis" avant de présenter quoi que ce soit basé sur ce résultat.

2. Pourquoi la façon de présenter compte autant que l'analyse

Un data analyst peut passer trois jours sur une extraction propre, une jointure bien pensée et un test statistique parfaitement mené — et voir sa conclusion ignorée en réunion parce que personne n'a compris ce qu'il fallait en retenir. C'est une réalité qu'on n'aime pas admettre quand on vient du monde technique : le travail du DA ne s'arrête pas quand le chiffre est juste, il s'arrête quand un décideur a compris ce chiffre assez bien pour agir dessus.

Une analyse juste mais mal communiquée n'est pas une analyse à moitié réussie. C'est une analyse qui échoue tout court, du point de vue de l'entreprise — parce qu'elle n'aura déclenché aucune décision, aucun changement, aucune action. Le rigueur méthodologique (la bonne requête SQL, le bon test, le bon dashboard) est une condition nécessaire, mais elle n'est pas suffisante : elle garantit que la réponse est correcte, pas qu'elle sera comprise.

Un contraste illustratif. Imagine deux DA à qui on a posé la même question — pourquoi les résiliations d'abonnement augmentent dans une région donnée — et qui ont fait, au fond, le même travail d'analyse.

Le premier arrive en réunion avec 15 slides : une capture d'écran de sa requête SQL, un tableau croisé dynamique par mois, un autre par tranche d'âge, un troisième par type de forfait, des graphiques en cascade sans titre clair. Il commence par "alors, j'ai d'abord regardé les données brutes, ensuite j'ai croisé avec la table clients, et si on regarde ce tableau ici...". Cinq minutes plus tard, la salle a décroché. Quelqu'un finit par demander "mais du coup, on fait quoi ?" — et le DA n'a pas eu le temps d'y arriver.

Le second ouvre sur une seule phrase : "La résiliation a augmenté dans le Nord parce que la couverture réseau s'est dégradée après la panne de mars — je recommande de prioriser la maintenance de ces antennes avant la fin du trimestre." Puis il donne trois arguments qui soutiennent cette phrase, et seulement ensuite, pour qui veut creuser, le détail des données derrière chaque argument.

Le contenu analytique peut être rigoureusement identique dans les deux cas. Seul l'ordre de présentation change — et pourtant, un seul des deux DA a une chance réelle d'influencer une décision.

Ce n'est pas une question de charisme ou de talent oratoire inné. C'est une question de méthode : il existe une façon structurée de construire un message pour qu'il porte, indépendamment du sujet ou de la personnalité de celui qui le présente. C'est cette méthode qu'on va voir maintenant.

3. Le Pyramid Principle (Barbara Minto) — la méthode

Le Pyramid Principle (le "principe de la pyramide") est une méthode de structuration de la communication professionnelle, développée dans les années 1970 par Barbara Minto, alors consultante chez McKinsey. Elle a été conçue à l'origine pour que les consultants sachent rédiger des rapports que des dirigeants pressés liraient — et comprendraient — en quelques minutes. Depuis, elle est devenue un standard implicite du conseil, de la finance, et plus généralement de toute présentation orientée décision — exactement le contexte dans lequel un DA livre ses analyses.

L'idée centrale : descendant, pas ascendant

Le réflexe naturel, quand on a mené une analyse, est de raconter son propre cheminement : "j'ai d'abord fait ceci, puis j'ai remarqué cela, ce qui m'a amené à observer ceci d'autre, et donc, au final, on peut conclure que...". C'est une construction ascendante (bottom-up) : on part des données et on remonte progressivement jusqu'à la conclusion. Ce chemin est celui qu'a suivi l'analyste pour trouver la réponse — mais ce n'est jamais le meilleur chemin pour la communiquer.

Le problème, c'est que l'audience — un directeur, un client, un comité — n'a ni le temps ni l'obligation de suivre un raisonnement pas à pas. Elle veut savoir, dès les dix premières secondes, quelle est la réponse et ce qu'elle doit en faire. Si la réponse n'arrive qu'à la fin, on a perdu une bonne partie de la salle avant même d'y arriver.

Le Pyramid Principle inverse ce réflexe : on communique en mode descendant (top-down). On commence par l'idée la plus importante — la réponse, la recommandation, la conclusion — puis on descend progressivement vers les arguments qui la soutiennent, et enfin vers le détail des données et des preuves. Le raisonnement de découverte va du bas vers le haut ; le raisonnement de présentation va du haut vers le bas. Ce sont deux chemins différents, et confondre les deux est l'erreur la plus fréquente en restitution d'analyse.

La structure en pyramide

Concrètement, le message se construit sur trois niveaux :

                 ┌─────────────────────────┐
                 │      MESSAGE PRINCIPAL    │   ← la réponse à LA question
                 │   (la conclusion/recomm.) │      (1 seule phrase)
                 └─────────────────────────┘
                            ▲
              ┌─────────────┼─────────────┐
              │             │             │
      ┌───────────┐  ┌───────────┐  ┌───────────┐
      │ Argument 1 │  │ Argument 2 │  │ Argument 3 │   ← 3 (environ) arguments
      └───────────┘  └───────────┘  └───────────┘      qui soutiennent le message
            ▲               ▲               ▲
        ┌───┴───┐       ┌───┴───┐       ┌───┴───┐
        │données│       │données│       │données│      ← détail, preuves, graphiques,
        │preuves│       │preuves│       │preuves│         requêtes, chiffres
        └───────┘       └───────┘       └───────┘

Au sommet : le message principal. C'est la réponse directe à la question qu'on t'a posée (ou que tu t'es posée), formulée en une phrase, sans détour. Pas "voici ce que j'ai trouvé en analysant les résiliations", mais la conclusion elle-même : "la résiliation augmente dans le Nord à cause de X, il faut faire Y."
Au milieu : les arguments supports. En général 3, parfois 2 ou 4 — rarement plus, sous peine de diluer le message. Chacun répond à la question implicite "pourquoi je devrais croire ce message principal ?" ou "comment on arrive à cette conclusion ?".
À la base : les preuves détaillées. C'est ici, et seulement ici, que vont les tableaux, les requêtes SQL, les p-values, les graphiques détaillés. C'est le niveau que la plupart des DA présentent en premier par réflexe — alors qu'il devrait être le dernier, réservé à qui veut creuser.

Le SCQA pour construire l'ouverture

Le SCQA est un outil concret pour rédiger l'introduction d'une présentation ou d'un rapport — le moment où on pose le contexte avant d'énoncer le message principal. Il tient en quatre étapes :

S — Situation : un rappel factuel, non contesté, que tout le monde dans la salle accepte déjà. Exemple générique : "L'entreprise suit son taux de résiliation mensuel depuis deux ans."
C — Complication : l'élément qui vient perturber cette situation stable, la raison pour laquelle on est réunis aujourd'hui. Exemple générique : "Ce taux a augmenté de façon inhabituelle sur les trois derniers mois."
Q — Question : la question que cette complication soulève naturellement dans l'esprit de l'audience. Exemple générique : "Pourquoi cette hausse, et que doit-on faire ?"
A — Answer : le message principal de la pyramide — la réponse directe, qui enchaîne ensuite sur les arguments et les preuves. Exemple générique : "La hausse est concentrée sur une cause identifiable, corrigible d'ici la fin du trimestre."

L'intérêt du SCQA est qu'il amène naturellement l'audience à se poser elle-même la question à laquelle on va répondre — au lieu de lui imposer une réponse hors contexte. Une fois le A énoncé, on est exactement au sommet de la pyramide, prêt à dérouler les arguments.

Le MECE pour organiser les arguments

Une fois le message principal posé, il reste à choisir les 2-4 arguments qui le soutiennent, au milieu de la pyramide. Le critère de qualité pour ce choix s'appelle MECE (Mutually Exclusive, Collectively Exhaustive — mutuellement exclusifs, collectivement exhaustifs) :

Mutuellement exclusifs : les arguments ne se chevauchent pas. Chaque idée n'apparaît qu'à un seul endroit, il n'y a pas de redondance entre deux arguments qui diraient en fait la même chose sous un angle différent.
Collectivement exhaustifs : les arguments couvrent, ensemble, tout ce qui est nécessaire pour justifier le message principal — sans trou logique évident que l'audience pourrait pointer.

Un exemple générique simple : si le message principal est "la baisse des ventes du trimestre s'explique par des facteurs externes, pas par un problème interne", des arguments MECE pourraient découper les causes possibles en "facteurs marché" / "facteurs concurrence" / "facteurs internes (écartés)" — trois catégories qui ne se recoupent pas et qui, ensemble, couvrent toutes les causes plausibles qu'un auditeur attentif aurait en tête. À l'inverse, un découpage non-MECE listerait par exemple "baisse du pouvoir d'achat" et "inflation" comme deux arguments séparés alors qu'ils se recouvrent largement — ou omettrait complètement la piste interne, laissant l'audience se demander pourquoi elle n'a pas été adressée.

Le SCQA structure l'ouverture, le MECE structure le corps : ensemble, ils garantissent que la pyramide tient debout — un message clair au sommet, des arguments solides et non redondants pour le porter, et les preuves disponibles pour qui veut vérifier.

4. Appliquer le Pyramid Principle à une vraie présentation

Passons de la théorie à la pratique. Imaginons que tu es l'analyste data d'ANSUT-CI / MobiCI, et qu'on te demande de présenter au comité de direction une situation préoccupante : à partir de vue_resume_clients et du dashboard Power BI construit en Module 17, tu as repéré que San-Pédro affiche une baisse notable de l'activité transactionnelle par rapport aux autres villes du portefeuille. Le comité te donne 10 minutes. Voici deux façons radicalement différentes de raconter exactement la même découverte.

Version bottom-up (à éviter)

C'est la présentation "par construction" : elle suit l'ordre dans lequel toi tu as découvert les choses, pas l'ordre dont le comité a besoin. Voici à quoi elle ressemble, diapositive par diapositive :

Diapo 1 : "Commençons par regarder la table transactions telle qu'elle sort de PostgreSQL, avec le détail des dépôts, retraits et transferts sur les douze derniers mois."
Diapo 2 : "Voici maintenant la vue vue_resume_clients qu'on a construite au Module 16, avec le nombre de transactions et le total par client."
Diapo 3 : "Si on agrège ça par ville, on obtient ce tableau — vous voyez, il y a des écarts entre les villes."
Diapo 4 : "En regardant plus en détail la colonne nb_transactions, on remarque que certaines villes progressent bien, comme Abidjan et Bouaké."
Diapo 5 : "Et là, si on zoome sur San-Pédro spécifiquement, sur les derniers mois, on observe une baisse notable par rapport à sa propre tendance historique et par rapport aux autres villes."
Diapo 6 (la dernière, après 8 minutes) : "Donc pour conclure, on recommande d'investiguer la cause de cette baisse à San-Pédro et de mettre en place un plan d'action ciblé."

Le problème saute aux yeux : le comité a passé huit minutes à regarder des tableaux intermédiaires sans savoir pourquoi on leur montre ça. Les décideurs, qui doivent souvent trancher ou passer au sujet suivant en quelques minutes, décrochent avant la diapo 4 — ou pire, ils interrompent avec des questions ("pourquoi on regarde ça ?") qui font dérailler le fil. Le message le plus important — celui qui justifie une action — arrive en dernier, à un moment où l'attention et le temps sont déjà épuisés.

Version pyramidale (SCQA + message principal en premier)

Avec le Pyramid Principle, on inverse complètement l'ordre : le message principal (la réponse) ouvre la présentation, et les données ne servent qu'à l'étayer — dans un ordre logique, pas chronologique. Voici un exemple de texte de diapo 1 / d'introduction orale, réutilisable tel quel :

Diapo 1 — Message principal

Situation : MobiCI opère aujourd'hui dans plusieurs villes, avec un volume de transactions globalement stable sur l'ensemble du portefeuille. Complication : Depuis quelques mois, San-Pédro se démarque négativement : son activité transactionnelle décroche par rapport à sa propre tendance historique et par rapport aux autres villes suivies dans le dashboard. Question : Faut-il agir sur San-Pédro maintenant, et si oui comment ? Réponse : Oui — nous recommandons de lancer une investigation ciblée sur San-Pédro dans les deux prochaines semaines, en priorité sur la rétention des clients parrainés, avant que la baisse ne s'installe durablement.

Trois éléments soutiennent cette recommandation :

L'ampleur — la baisse à San-Pédro est significativement plus marquée que la variation normale observée sur les autres villes du portefeuille.

La tendance — il ne s'agit pas d'un creux ponctuel : le repli se confirme sur plusieurs mois consécutifs dans vue_resume_clients.

Le risque de contagion — une partie des clients concernés sont liés entre eux via le système de parrainage (id_parrain), ce qui expose à un effet d'entraînement si rien n'est fait.

Je peux maintenant détailler les chiffres ville par ville, ou le détail des cohortes de clients parrainés à San-Pédro, selon ce qui vous est le plus utile.

Remarque la structure : le message principal (la recommandation) est énoncé en une phrase, dès les premières secondes. Les trois arguments qui suivent sont MECE — mutuellement exclusifs (ampleur, tendance, risque de contagion ne se recouvrent pas) et collectivement exhaustifs (à eux trois, ils couvrent l'essentiel de ce qui justifie la recommandation). Et surtout, les tableaux détaillés de transactions et de vue_resume_clients ne sont montrés qu'en option, à la demande — ils passent du statut de "fil conducteur" à celui de "preuve à l'appui", disponible si le comité veut creuser.

Avant de présenter, vérifie que...

ta première phrase (ou ta première diapo) contient déjà la réponse à la question implicite du comité — pas une mise en contexte de dix minutes ;
tu peux résumer ton message principal en une seule phrase, sans "et aussi", "d'ailleurs" ou "au fait" ;
tes arguments de soutien sont MECE : ils ne se chevauchent pas et, ensemble, couvrent l'essentiel du raisonnement ;
chaque tableau, graphique ou requête SQL que tu montres sert un argument précis de la pyramide — s'il ne sert à rien, il va dans l'annexe, pas dans le corps de la présentation ;
tu peux répondre à "et donc, on fait quoi ?" sans revenir en arrière dans tes diapos ;
tu as préparé les détails (données brutes, requêtes, vues Power BI) en backup, prêts à sortir seulement si on te les demande.

5. Utiliser l'IA pour challenger sa présentation avant de la livrer

5.1 Pourquoi cette étape existe

Quand tu as passé plusieurs jours (parfois plusieurs semaines) sur une analyse, tu n'es plus vraiment objectif·ve vis-à-vis de ton propre raisonnement. Tu connais les données par cœur, tu as déjà éliminé mentalement certaines hypothèses en cours de route, et l'histoire que tu racontes te paraît évidente — parce qu'elle l'est devenue pour toi, à force de la construire. C'est un biais bien connu et totalement normal : plus on est proche d'un travail, moins on est capable d'en voir les failles de l'extérieur.

Le problème, c'est que la personne en face de toi en comité — un·e DG, un·e CFO, un·e directeur·rice commercial·e — n'a pas ce recul construit sur plusieurs jours. Elle va regarder ta première slide de conclusion et, en 10 secondes, chercher instinctivement la faille : "est-ce que c'est vraiment ce facteur qui explique la baisse, ou est-ce qu'il se passe autre chose en même temps ?", "est-ce que cette tendance est solide ou est-ce un artefact d'une période particulière ?", "qu'est-ce qui manque dans ce raisonnement ?"

L'idée de cette technique est simple : plutôt que de découvrir ces questions pour la première fois pendant la présentation — au moment le plus stressant et le moins confortable pour y répondre — tu les fais émerger avant, dans le calme de ta préparation, en demandant explicitement à une IA (Claude, ChatGPT, ou équivalent) de jouer ce rôle de sceptique.

Le point clé, c'est le mot explicitement. Si tu demandes simplement à l'IA "est-ce que ma présentation est bonne ?" ou "peux-tu améliorer ce texte ?", tu vas très probablement récupérer une réponse polie, qui reformule tes phrases et valide ta structure — parce que c'est la tâche que tu as donnée : améliorer, pas challenger. Une IA a par défaut tendance à être coopérative et à aller dans le sens de la demande. Pour obtenir un vrai regard critique, il faut lui donner un rôle et un objectif différents : trouver les points faibles, pas polir la forme.

5.2 Un prompt réutilisable

Voici un modèle de prompt que tu peux copier et adapter, en collant ton plan ou ton argumentaire juste en dessous :

Tu es un·e décideur·se sceptique (DG ou CFO) qui reçoit cette présentation
pour la première fois. Je vais te coller mon argumentaire / plan de
présentation ci-dessous. Ne le complimente pas et ne corrige pas le style.
Ton seul travail est de le challenger, en répondant point par point à ces
4 questions :

1. Quelles affirmations sont faibles ou insuffisamment soutenues par les
   données présentées ? (une affirmation "faible" est une conclusion qui
   va plus loin que ce que les chiffres montrent réellement)

2. Pour chaque tendance ou pattern observé, y a-t-il une explication
   alternative plausible que l'argumentaire n'exclut pas ? (saisonnalité,
   effet d'un autre facteur, biais de sélection dans les données, etc.)

3. Y a-t-il un endroit où une relation de cause à effet est affirmée ou
   sous-entendue, alors que ce qui a été démontré est seulement une
   corrélation ou une coïncidence temporelle ?

4. Sur une échelle de 1 à 10, à quel point cet argumentaire convaincrait-il
   un·e CFO/DG sceptique qui cherche activement la faille ? Justifie la
   note et indique ce qui, concrètement, la ferait remonter.

Voici l'argumentaire :
[COLLE ICI TON PLAN / TES SLIDES / TON ARGUMENTAIRE]

Ce prompt fonctionne parce qu'il fait trois choses à la fois : il assigne un rôle (décideur·se sceptique), il interdit explicitement le réflexe de politesse ("ne le complimente pas"), et il découpe la critique en catégories précises plutôt que de demander un avis général — ce qui pousse l'IA à vraiment inspecter chaque affirmation au lieu de produire un commentaire vague du type "c'est globalement solide, quelques points à clarifier."

5.3 Exemple illustratif

Pour rendre ça concret, voici un exemple fictif et illustratif (pas une vraie sortie IA, juste pour montrer le mécanisme) : imagine que ton argumentaire de présentation contienne ce passage.

Exemple d'argumentaire (illustratif) : "Depuis que nous avons lancé la nouvelle interface de l'app mobile en mars, le taux de désabonnement a baissé de manière continue. La nouvelle interface a donc permis de réduire le churn, et nous recommandons d'investir davantage dans l'expérience utilisateur pour les prochains trimestres."

Un pushback illustratif que l'IA pourrait générer, en suivant le prompt ci-dessus, ressemblerait à quelque chose comme :

Pushback illustratif : "Ce que tu montres, c'est que deux courbes évoluent en même temps après mars — le lancement de l'interface et la baisse du churn. Ce n'est pas la même chose que prouver que l'une cause l'autre. Qu'est-ce qui a changé d'autre en mars ? Une promotion tarifaire ? Une baisse saisonnière habituelle du churn à cette période de l'année ? Un changement chez un concurrent ? Sans comparer à un groupe témoin (utilisateurs qui n'ont pas eu la nouvelle interface, si elle a été déployée progressivement) ou sans écarter ces facteurs, l'affirmation 'la nouvelle interface a permis de réduire le churn' est une causalité présentée comme acquise, alors que la donnée montrée est une corrélation temporelle. Note de conviction pour un CFO sceptique : 4/10 — la baisse est réelle, mais l'attribution à l'interface ne l'est pas encore."

Tu reconnais ici exactement la distinction vue au Module 18 (statistiques inférentielles) : observer que deux variables évoluent ensemble ne suffit jamais à établir qu'une variable cause l'autre. Un troisième facteur non observé (une variable confondante) peut très bien expliquer les deux à la fois. Ce genre de raccourci — "après ça, donc à cause de ça" — est précisément ce qu'un·e stakeholder aguerri·e va chercher à démonter en premier, et c'est exactement ce type de trou qu'un prompt de challenge bien construit permet de repérer avant lui.

5.4 Une mise en garde importante

Le retour de l'IA n'est ni une validation, ni un verdict à appliquer aveuglément. C'est un déclencheur pour réfléchir plus fort, pas une autorité qui a toujours raison. Deux erreurs symétriques sont à éviter :

Tout accepter sans recul : l'IA peut proposer une explication alternative qui, en réalité, ne tient pas — parce qu'elle ne connaît pas un détail métier ou un contrôle que tu as déjà fait en amont (par exemple, tu as peut-être déjà vérifié qu'aucune promotion n'a eu lieu en mars). Dans ce cas, la bonne réponse n'est pas de retirer ta conclusion, mais d'ajouter dans ta présentation la précision qui neutralise l'objection ("nous avons vérifié qu'aucune campagne tarifaire n'a coïncidé avec le lancement").
Tout rejeter par réflexe défensif : si le pushback touche un vrai angle mort, l'ignorer parce que "l'IA n'a pas toutes les données" serait exactement l'erreur que cet exercice sert à éviter — le but est justement de trouver ces angles morts avant la salle de réunion, pas de les balayer.

Au final, c'est toujours toi, en tant que data analyst, qui portes le jugement sur ce qui est retenu, nuancé ou écarté. L'IA élargit l'éventail des questions à te poser ; elle ne remplace pas ton évaluation de ce qui est solide.

6. Simuler les questions d'un décideur avec l'IA

Challenger la logique de ton propre argumentaire, comme tu viens de le voir, se fait en amont — seul, face à ton document. Mais il existe un deuxième moment de vérité, plus redouté : celui où tu es debout devant un DG, un directeur commercial ou un comité de direction, et où quelqu'un lève la main pour poser une question à laquelle tu n'as pas pensé.

Un décideur ne se contente jamais de regarder tes graphiques. Il pose des questions concrètes et parfois inconfortables : combien ça coûte, pourquoi maintenant et pas dans six mois, qu'est-ce qui se passe si tu te trompes, et — la plus redoutable — qu'est-ce que tu ne nous montres pas. Ce ne sont pas des questions hostiles par nature, ce sont les questions que toute personne qui engage son budget ou sa réputation sur ta recommandation est en droit de poser.

Le problème, c'est que ces questions arrivent en direct, devant tout le monde, et que ta réaction dans ces dix secondes-là compte autant que la qualité de ton analyse. Bafouiller, improviser une réponse bancale ou découvrir en live que tu n'as pas la donnée qu'on te demande — même si le fond de ton travail est solide — suffit à faire douter toute la salle de ta crédibilité. La confiance se joue autant sur ta capacité à anticiper les objections que sur la rigueur de tes chiffres.

C'est là qu'intervient une deuxième technique, différente de la relecture critique vue précédemment : au lieu de demander à l'IA d'évaluer ton raisonnement, tu lui demandes d'incarner un décideur précis et de te bombarder des questions que cette personne poserait probablement dans la salle. L'objectif n'est plus de corriger ton argumentaire, mais de t'entraîner à l'oral, en conditions proches du réel, pour arriver avec des réponses déjà prêtes plutôt que de les improviser sous pression.

Le principe : le jeu de rôle plutôt que la critique

La différence est simple mais importante. Demander « est-ce que mon raisonnement tient la route ? » sollicite l'IA comme relecteur analytique. Demander « mets-toi à la place de mon DG et pose-moi les questions qu'il poserait » sollicite l'IA comme partenaire d'entraînement. Le résultat n'est pas une liste de failles logiques, mais une simulation de l'échange oral qui t'attend — avec le ton, les priorités et les réflexes propres à un type de décideur donné.

Pour que ça fonctionne, il faut donner à l'IA un persona précis, pas un vague "décideur". Un DG pressé qui n'a que cinq minutes ne pose pas les mêmes questions qu'un directeur financier obsédé par le ROI, ou qu'un directeur des opérations qui veut savoir qui va exécuter la recommandation sur le terrain. Plus tu précises le persona, plus les questions générées seront réalistes et utiles.

Modèle de prompt réutilisable

Tu es [PERSONA PRÉCIS — ex : "un DG sceptique, très pressé, qui n'a que
5 minutes en réunion et qui a déjà été déçu par des analyses trop
optimistes par le passé qui ne se sont pas vérifiées sur le terrain"].

Voici le résumé d'une présentation que je m'apprête à faire devant toi :
[COLLE ICI UN RÉSUMÉ DE TA PRÉSENTATION : constat principal, chiffres
clés, recommandation, action demandée]

Mets-toi entièrement dans la peau de ce persona. Génère la liste des
questions difficiles, précises et parfois inconfortables que tu me
poserais en réunion en entendant cette présentation — sur le coût de
l'action recommandée, le niveau de confiance dans les chiffres, ce qui
se passe si la tendance s'inverse, les explications alternatives que
je n'ai peut-être pas explorées, le calendrier, et tout ce que tu
soupçonnes que je n'ai pas montré volontairement ou par oubli.

Ne réponds pas à ma place : liste uniquement les questions, dans le
ton et le style que ce persona utiliserait réellement.

Le fait de préciser explicitement les thèmes attendus (coût, confiance, scénario d'échec, alternatives, calendrier, angles morts) évite que l'IA reste vague et t'aide à couvrir les familles de questions qui reviennent le plus souvent en réunion de décision, quel que soit le persona.

Exemple illustratif

Imaginons que tu t'apprêtes à présenter ceci : « Nos données montrent que le taux d'abandon de panier a augmenté de manière significative sur les trois derniers mois chez les clients mobiles en Côte d'Ivoire, et nous recommandons d'investir dans une refonte du parcours de paiement mobile d'ici le mois prochain. »

En simulant un DG sceptique et pressé sur ce résumé, l'IA pourrait générer une liste de questions illustrative de ce type :

« Cette refonte, elle coûte combien, et ça prend combien de temps avant qu'on voie un effet sur les ventes ? »
« Vous êtes sûrs à quel point que c'est le parcours de paiement le problème, et pas autre chose — une panne réseau, une promo concurrente, un souci avec un opérateur mobile money en particulier ? »
« Si dans deux mois la tendance ne s'inverse pas malgré l'investissement, qu'est-ce qu'on fait ? »
« Est-ce qu'il y a d'autres segments de clients touchés, ou c'est vraiment isolé au mobile en Côte d'Ivoire ? »
« Pourquoi il faut agir dès le mois prochain et pas attendre le prochain trimestre pour avoir plus de recul sur les données ? »

Encore une fois, ceci est un exemple purement illustratif destiné à montrer le type de questions à anticiper — pas une transcription réelle. Mais on voit déjà l'intérêt : chacune de ces questions, si elle te tombe dessus sans préparation, peut te faire perdre pied. Si tu les as déjà vues passer à l'écrit, tu arrives avec une réponse posée.

Le bon réflexe : simuler tôt, pas la veille au soir

Le piège classique est de faire cet exercice la veille de la présentation, une fois les slides finalisées. À ce stade, si l'IA te sort une question à laquelle tu n'as vraiment aucune réponse — parce que la donnée n'existe pas encore, ou parce qu'il faudrait recreuser un segment que tu n'as pas exploré — tu n'as plus le temps d'aller la chercher. Tu es coincé à improviser quand même, ou pire, à répondre "on n'a pas regardé ça" en direct.

Fais cette simulation tôt dans ton processus de préparation, idéalement dès que tu as un brouillon de constat et de recommandation, avant même de commencer à soigner tes slides. Si l'exercice révèle un trou — une donnée manquante, une explication alternative que tu n'as pas testée, un chiffre de coût que tu n'as pas encore — tu as encore le temps de retourner dans tes données ou de consulter un collègue pour combler ce trou avant le jour J. L'IA ne remplace pas cette recherche : elle te dit simplement, en avance, où chercher.

✅ Résumé du module

Concept	Ce qu'il faut retenir
Paysage de l'IA pour un DA	Copilote de code (M09) / analyste autonome (Julius.ai, ChatGPT, Claude — écrit et exécute du code pour toi, vérifiable via "Show Code"/"View analysis") / partenaire de communication (ce module)
Analyste autonome — limites	Peut halluciner sur des colonnes ambiguës, produire des résultats incohérents d'une exécution à l'autre — toujours vérifier le code exécuté avant de présenter un résultat
Pyramid Principle	Communiquer en mode descendant (top-down) : message principal d'abord, arguments ensuite, preuves détaillées en dernier — l'inverse du chemin suivi pour trouver la réponse
SCQA	Situation (fait accepté) → Complication (ce qui perturbe) → Question (qu'elle soulève) → Answer (le message principal) — pour construire l'ouverture d'une présentation
MECE	Les arguments supports doivent être mutuellement exclusifs (pas de chevauchement) et collectivement exhaustifs (pas de trou logique)
IA pour challenger	Demander explicitement à l'IA de jouer un rôle sceptique et de chercher les failles (affirmations faibles, explications alternatives, corrélation présentée comme causalité) — pas de lui demander un avis général
IA pour simuler un décideur	Faire jouer à l'IA un persona précis (ex: DG pressé et sceptique) pour générer les questions difficiles à l'avance, et s'entraîner à y répondre avant la réunion
Quand le faire	Tôt dans la préparation — pas la veille — pour avoir le temps d'aller chercher les réponses manquantes révélées par l'exercice

🧠 Quiz — Vérifie ta compréhension

Q1. Tu viens de terminer une analyse et tu prépares ta présentation. Dans quel ordre le Pyramid Principle recommande-t-il de communiquer ?

a) Dans l'ordre où tu as toi-même découvert les choses : données brutes, puis observations, puis conclusion
b) Le message principal (la réponse) en premier, puis les arguments qui le soutiennent, puis le détail des données en dernier
c) Toujours par ordre chronologique des données (du plus ancien au plus récent)

👉 Voir la réponse

✅ b) — Le chemin de découverte (a) est ascendant (bottom-up) : c'est celui que suit l'analyste pour trouver la réponse, mais c'est rarement le meilleur pour la communiquer à une audience pressée. Le Pyramid Principle inverse cet ordre : message principal d'abord, puis arguments, puis preuves détaillées disponibles pour qui veut creuser.

Q2. Dans le framework SCQA, à quoi correspond la lettre "C" ?

a) Conclusion — la réponse finale de la présentation
b) Complication — l'élément qui vient perturber une situation stable et qui justifie qu'on se réunisse aujourd'hui
c) Contexte — un rappel du secteur d'activité de l'entreprise

👉 Voir la réponse

✅ b) — SCQA = Situation (fait accepté par tous) → Complication (ce qui perturbe cette situation) → Question (celle que la complication soulève naturellement) → Answer (le message principal, qui correspond à la "Conclusion" de la réponse a) — mais ce n'est pas la lettre C qui la désigne).

Q3. Trois arguments soutiennent ton message principal : "le churn augmente à cause d'un problème de couverture réseau", "le churn augmente à cause d'un problème de couverture dans le Nord spécifiquement", et "le service client reçoit plus de réclamations réseau". Pourquoi ce découpage n'est-il pas MECE ?

a) Il y a trop peu d'arguments (il en faut toujours au moins 4)
b) Les deux premiers arguments se chevauchent largement (ils parlent tous les deux du problème de couverture) — ils ne sont pas mutuellement exclusifs
c) Le troisième argument n'est pas assez détaillé

👉 Voir la réponse

✅ b) — MECE veut dire mutuellement exclusifs (pas de chevauchement entre les arguments) et collectivement exhaustifs (pas de trou logique). Ici, les deux premiers arguments racontent en réalité la même chose à deux niveaux de précision différents — ce n'est pas un vrai argument distinct, c'est une redondance. Le nombre d'arguments (a) n'est pas la règle — MECE porte sur la qualité du découpage, pas sur le compte.

Q4. Quelle est la différence entre "demander à l'IA de challenger ton argumentaire" (section 5) et "demander à l'IA de simuler un décideur" (section 6) ?

a) Ce sont deux noms différents pour exactement la même technique
b) La première cherche les failles logiques de ton raisonnement (rôle de relecteur analytique) ; la seconde entraîne ta réponse orale à des questions réalistes en te mettant dans la peau d'un persona précis (rôle de partenaire d'entraînement)
c) La première s'utilise après la réunion, la seconde avant

👉 Voir la réponse

✅ b) — Les deux techniques utilisent l'IA différemment : challenger l'argumentaire vise à corriger le raisonnement lui-même (affirmations faibles, corrélation vs causalité...) avant de finaliser la présentation ; simuler un décideur vise à s'entraîner à répondre à l'oral, sous forme de jeu de rôle avec un persona précis, pour ne pas être pris au dépourvu en réunion. Les deux se font avant la réunion (c), idéalement tôt dans la préparation.

Q5. Pourquoi est-il recommandé de faire l'exercice "simuler un décideur avec l'IA" tôt dans la préparation plutôt que la veille de la présentation ?

a) Parce que l'IA est plus lente à répondre le soir
b) Parce que si l'exercice révèle une question à laquelle tu n'as pas de réponse (donnée manquante, segment non exploré), il faut encore avoir le temps d'aller la chercher
c) Ce n'est pas recommandé, la veille est le meilleur moment pour rester concentré

👉 Voir la réponse

✅ b) — Si l'exercice est fait la veille au soir, une question sans réponse découverte à ce moment-là ne peut plus être creusée : il ne reste que l'improvisation ou l'aveu en réunion. Fait tôt, l'exercice sert justement à identifier les trous pendant qu'il est encore temps d'aller chercher la donnée manquante ou de consulter un∙e collègue.

Q6. Tu utilises un outil comme Julius.ai pour analyser rapidement un fichier de ventes. Il te renvoie un graphique avec une explication convaincante. Quel est le bon réflexe avant de t'en servir dans une présentation ?

a) Faire confiance au résultat : l'outil a exécuté du vrai code, donc le résultat est forcément juste
b) Vérifier le code réellement exécuté (via "Show Code" ou "View analysis") et le confronter à ce que tu sais des données, exactement comme tu le ferais pour ton propre code
c) Ne jamais utiliser ce type d'outil, il n'a aucune utilité pour un∙e DA

👉 Voir la réponse

✅ b) — Ces outils exécutent réellement du code (ce n'est pas une boîte noire), mais ce code peut reposer sur une mauvaise interprétation d'une colonne ambiguë ou une erreur silencieuse (comme le cas documenté avec des signes "%" mal gérés dans un tableau). Le fait que le code s'exécute ne garantit pas qu'il fait ce que tu crois — d'où l'importance de vérifier le code affiché, pas seulement le graphique produit. Les rejeter entièrement (c) fait perdre un vrai gain de rapidité pour l'exploration ; leur faire confiance aveuglément (a) est exactement le piège documenté.

🎉 Niveau Intermédiaire — modules terminés !

Tu as maintenant complété les 8 modules du Niveau Intermédiaire :

M13 — Git & GitHub pour DA
M14 — Data Cleaning robuste
M15 — Pandas approfondi + DuckDB
M16 — SQL avancé & vues optimisées
M17 — Power BI connecté à SQL
M18 — Statistiques inférentielles
M19 — Automatisation Python (API & scripts)
M20 — Storytelling + IA

🚀 La suite — Mini-Projet C & Projet Final Niveau Intermédiaire

Mini-Projet C — Pipeline complet Tu enchaîneras une API (Module 19) → un nettoyage robuste (Modules 14-15) → une mini-app Streamlit (Module 19) qui affiche le résultat, de bout en bout.

Projet Final Niveau Intermédiaire Le projet de clôture : de vraies données, mobilisant SQL avancé, Power BI et statistiques inférentielles, publié sur Streamlit Community Cloud.

Bootcamp Data Analyst — From Zero to Hero | Niveau Intermédiaire

←

M19 — Automatisation Python (API & scripts)