Technologie · July 21, 2026 · 9 min de lecture

Prompt engineering pour les analystes de données : méfiez-vous du chiffre

Le prompt engineering pour les analystes de données, c'est une définition précise de la métrique et la discipline de se méfier du résultat tant qu'il ne se réconcilie pas. Pourquoi le chiffre est le risque.

← Fait partie de Évaluations générées par IA : le guide complet 2026

Pour un analyste de données, le résultat d'une session IA est un chiffre, et un chiffre est collé dans une présentation et transformé en décision. Cela soulève les enjeux du prompt engineering pour les analystes de données d'une façon spécifique : le mode d'échec n'est pas un code laid, c'est un chiffre plausible qui ne tient tranquillement pas la route. Si vous recrutez des analystes, c'est la compétence qui détermine si une requête générée par IA économise un après-midi ou envoie un fait erroné au conseil d'administration. C'est l'entrée de l'analyste dans notre série de prompt engineering par rôle, et c'est l'une des choses les plus claires que l'AI Sandbox révèle sur le vrai jugement d'un candidat.

Pourquoi les enjeux sont différents pour les analystes

L'erreur IA d'un ingénieur s'annonce généralement : le build casse, un test échoue, le linter se plaint. L'erreur d'un analyste fait le contraire. Une requête qui double-compte les remboursements retourne un chiffre propre et confiant, correctement formaté, dans les bonnes unités. Rien dans ce chiffre ne semble faux. Il coule dans un tableau de bord, puis une diapositive, puis une conversation stratégique, et l'erreur n'est jamais détectée que si quelqu'un le réconcilie avec un chiffre en lequel il a déjà confiance. Cette asymétrie est la raison entière pour laquelle le prompt engineering compte plus, pas moins, une fois qu'un analyste a des outils d'IA à portée de main. L'outil abaisse le coût de produire une réponse à presque zéro tout en laissant le coût d'une mauvaise réponse exactement là où il était.

Donc la compétence qui vaut d'être recrutée n'est pas la fluidité avec une fenêtre de chat. C'est l'habitude de traiter chaque chiffre généré par IA comme une affirmation qui doit mériter la confiance. Cette habitude est indiscernable d'une bonne pratique analytique ; l'IA a simplement rendu plus facile de l'ignorer. Les analystes qui prospèrent sont ceux qui refusent de l'ignorer.

Le chiffre survit à la requête

Considérez ce qui se passe après que l'analyste ferme l'ordinateur. Le SQL est jeté, mais le chiffre ne l'est pas. Il devient une ligne dans un rapport de conseil, un objectif dans un OKR, un seuil dans une règle d'alerte. Six semaines plus tard, personne ne se souvient quelle définition du chiffre d'affaires net l'a produit, et la requête qui réglerait l'argument est depuis longtemps disparue. C'est pourquoi la discipline de l'analyste ne peut pas être une habitude privée exercée dans l'instant ; elle doit être le genre d'habitude qui laisse une trace. Énoncer la définition dans le prompt, demander au modèle d'enregistrer ses hypothèses et réconcilier avant de publier sont toutes des façons de rendre le raisonnement durable. Quand vous recrutez un analyste, vous recrutez vraiment la durabilité des chiffres qu'il laissera derrière lui.

Un bon prompt est une définition précise

Réduire l'hallucination dans le travail analytique se résume à la spécificité et aux limites, pas à des formulations astucieuses. Une demande vague, « donne-moi le chiffre d'affaires par mois », invite le modèle à choisir une définition pour vous, et il choisira une mauvaise plausible chaque fois qu'il y a ambiguïté. Un analyste solide écrit la métrique, les exclusions et la source de vérité dans le prompt, et donne au modèle la permission explicite de repousser plutôt que de deviner. C'est l'AI Fluency dans le siège d'un analyste : le prompt et la rigueur analytique sont le même acte. Vous n'écrivez pas des instructions pour une machine autant que vous vous forcez à énoncer, en entier, ce que vous entendez vraiment par le chiffre que vous êtes sur le point de rapporter.

Les définitions sont le vrai travail

Chaque dispute analytique est une dispute définitionnelle déguisée en costume numérique. Un compte churné est-il celui qui a annulé, celui qui a arrêté de payer, ou celui qui est tombé en dessous d'un seuil d'utilisation ? « Utilisateur actif » signifie-t-il connecté, ou ayant effectué une action, ou ayant effectué une action significative ? L'IA ne peut pas résoudre cela pour vous, et quand vous les laissez non énoncés, elle les résout silencieusement. Mettre la définition dans le prompt n'est pas de la bureaucratie ; c'est le moment où vous découvrez que vous et votre partie prenante entendaient deux choses différentes depuis le début.

Un exemple concret

Demandez le chiffre d'affaires net par mois. La version faible s'arrête là. La version solide définit « net », nomme les exclusions, spécifie quel horodatage compte comme le mois, et dit au modèle de signaler tout ce qu'il ne trouve pas plutôt que d'inventer un nom de colonne. Puis, la partie qui compte vraiment, l'analyste vérifie le résultat par rapport à un chiffre en lequel il a déjà confiance avant qu'il ne quitte son écran.

## TASK
Write SQL: net revenue by calendar month for 2025.

## DEFINITIONS
- net revenue = gross - refunds
- Exclude internal test accounts (email domain @acme-internal.com)
- "Month" = orders.completed_at, not created_at

## RULES
- If a column I named does not exist, tell me. Do not guess a name.
- Return the query, then list every assumption you made

• Bien : spécifie la métrique, les exclusions et la source de vérité ; demande les hypothèses ; vérifie le résultat ; se méfie d'un chiffre que les données ne soutiennent pas.
• Faible : accepte une requête plausible, rapporte un chiffre qui double-compte tranquillement les remboursements, et ne le remarque jamais jusqu'à ce que quelqu'un en aval le fasse.

Où l'analyste solide concentre son attention

Observez un analyste solide travailler une tâche IA et les moments intéressants ne sont pas quand il tape le prompt. Ce sont quand il fait une pause sur le résultat. Le résultat revient, la requête semble soignée, et au lieu de copier le chiffre il s'arrête et se demande s'il est à peu près de la taille qu'il attendait. Un chiffre d'un ordre de grandeur de travers est détecté dans cette pause ; tout comme un chiffre qui est suspicieusement rond, ou qui a bougé dans le mauvais sens par rapport au trimestre précédent. C'est là que les connaissances de domaine et l'AI Fluency fusionnent. L'outil a produit la réponse, mais seul un analyste qui porte déjà un modèle approximatif de l'entreprise dans la tête sait quand s'en méfier. Le prompt pose la question ; le scepticisme décide si la réponse est autorisée à quitter la pièce.

C'est aussi là où les analystes juniors et seniors divergent le plus visiblement. Un analyste junior tend à faire confiance à une requête propre parce qu'elle s'est exécutée sans erreur. Un senior traite « elle s'est exécutée » et « elle est correcte » comme deux affirmations entièrement séparées, et concentre son attention sur la seconde. L'IA a élargi cet écart, parce qu'elle rend la production d'une requête propre-mais-fausse sans effort tout en ne faisant absolument rien pour vous aider à remarquer qu'elle est fausse.

Les bonnes pratiques qui changent vraiment les choses

• Définissez avant de demander. Mettez la définition de la métrique, les exclusions et le grain de temps dans le prompt. L'ambiguïté est l'endroit où naissent les mauvais chiffres, et le prompt est l'endroit où vous la résolvez ou la confiez au modèle pour qu'il la résolve mal.
• Autorisez le modèle à dire « je ne sais pas ». Dites-lui de répondre « données insuffisantes » ou « cette colonne n'existe pas » plutôt que de deviner. Il hallucine bien moins quand le refus est une réponse autorisée.
• Demandez les hypothèses. Faites-lui lister ce qu'il a supposé. C'est là que vous repérerez la définition mal lue avant qu'elle ne devienne un chiffre rapporté.
• Vérifiez chaque résultat par rapport à un chiffre en lequel vous avez déjà confiance. Un chiffre qui ne se réconcilie pas est la découverte, pas une erreur d'arrondi à lisser.
• Gardez une source de vérité. Nommez la table, la vue ou la couche de métriques canonique dans le prompt pour que le modèle ne soit pas libre de joindre ce qui semble pratique.

Modes d'échec courants

• Métrique vague : « chiffre d'affaires » sans définition, donc le modèle en choisit une tranquillement et vous héritez de son choix sans savoir que vous l'avez fait.
• Faire confiance au chiffre parce que la requête semble propre. Un SQL propre sur une mauvaise définition reste une mauvaise réponse, et un code propre est exactement ce qui le rend dangereux.
• Ne jamais réconcilier par rapport à un chiffre connu, donc l'erreur est envoyée comme un fait et ne remonte en surface que quand l'instinct d'une partie prenante contredit la diapositive.
• Laisser le modèle inventer une colonne ou une jointure qu'il ne peut pas vérifier, puis rapporter des données qui ne signifient pas ce que l'analyste suppose.

Aucun de ceux-ci n'est exotique. Ce sont les façons ordinaires dont l'analyse a toujours mal tourné, accélérées. La différence est la vitesse : un outil d'IA peut générer une mauvaise réponse plausible en quelques secondes, donc le seul garde-fou restant est la discipline de l'analyste à s'en méfier. Cette discipline n'est pas un trait de personnalité que vous pouvez sélectionner en conversation d'entretien. C'est une habitude de travail, et la seule façon honnête d'observer une habitude de travail est de regarder le travail.

Le prompt est l'endroit où la conversation avec la partie prenante se produit

Il y a un deuxième bénéfice, plus discret, à écrire des définitions dans le prompt : il force la conversation avec la partie prenante qui aurait de toute façon dû avoir lieu. Quand un chef de produit demande « la conversion par canal ce trimestre », l'analyste qui se contente de transmettre cela à un outil d'IA a sauté l'étape la plus importante. Quel événement de conversion compte ? « Ce trimestre » signifie-t-il le trimestre fiscal ou le trimestre calendaire ? Un canal est-il le premier point de contact ou le dernier ? Écrire le prompt est le moment où ces questions deviennent inévitables, parce que le modèle a besoin d'une réponse et l'analyste doit en fournir une. Un bon analyste traite cela comme une invitation à revenir demander, pas à deviner au nom du demandeur.

C'est pourquoi les analystes les plus solides produisent souvent le prompt et les questions de clarification dans le même souffle. La spécification qu'ils remettent au modèle est, presque mot pour mot, la spécification qu'ils devraient confirmer avec la personne qui a demandé. L'outil a tranquillement transformé une étape que les gens sautaient autrefois en une étape qu'ils ne peuvent plus sauter, à condition qu'ils prennent l'écriture au sérieux plutôt que de coller la demande verbatim. Un candidat qui rétrécit réflexivement une demande ambiguë avant de toucher aux données vous montre exactement l'instinct qui empêche les mauvais chiffres d'être générés en premier lieu.

L'AI Fluency est un pilier, pas un ajout

Dans notre modèle à cinq piliers, l'AI Fluency se place aux côtés de la capacité cognitive, de domaine, situationnelle et comportementale plutôt que de remplacer l'une d'elles. Pour un analyste, cela compte parce que l'AI Fluency sans jugement de domaine est pire qu'inutile : elle produit de mauvaises réponses plus vite et avec plus de confiance. L'analyste qui détecte le remboursement double-compté le fait parce qu'il sait déjà approximativement à quoi devrait ressembler le chiffre d'affaires net. L'outil ne lui a pas donné cet instinct ; il a rendu le fait d'en disposer plus précieux. C'est pourquoi nous traitons cela comme l'AI Fluency évaluée comme un pilier distinct, notée au-dessus des compétences de domaine qu'un bon analyste a déjà besoin, jamais à leur place.

Comment nous l'évaluons

Vous ne pouvez pas tester cela avec un quiz de prompt-trivia, et vous ne pouvez pas le tester en retirant l'IA, ce qui mesure juste une tâche que personne ne fait plus de cette façon. Vous donnez au candidat une tâche d'analyse réaliste avec les outils disponibles et vous observez s'il définit la métrique, détecte l'agrégat trompeur et défend un chiffre qui tient vraiment — ce qu'une évaluation AI Sandbox fait. Voyez ce qu'une évaluation complète d'analyste de données couvre, comment le rôle frère diffère pour les ingénieurs logiciels, et pourquoi c'est le test honnête dans le recrutement AI-native.

Les meilleurs analystes traitent la réponse de l'IA comme ils traitent n'importe quel chiffre surprenant : coupable jusqu'à réconciliation. Cet instinct, pas la formulation du prompt, est ce qui garde un mauvais chiffre hors de la salle du conseil.