Technologie · July 21, 2026 · 8 min de lecture

L'ingénierie de prompts pour les analystes de données : d'abord des définitions précises, puis de la méfiance envers le chiffre

Pour les analystes, un bon prompt est une définition précise d'une métrique — et la compétence consiste à se méfier du résultat jusqu'à ce qu'il tienne la route. Un guide pratique de l'analyse assistée par l'IA qui ne livre pas un chiffre erroné, avec un exemple concret et la façon dont il est évalué.

Pour un analyste de données, le résultat d'une session avec l'IA est un chiffre — et un chiffre finit collé dans une présentation et transformé en décision. Cela accroît les enjeux du prompting d'une manière bien spécifique : le mode d'échec n'est pas un code laid, c'est une valeur plausible qui, discrètement, ne colle pas. Voici l'entrée consacrée aux analystes dans notre série sur l'ingénierie de prompts par rôle, et c'est l'une des choses les plus clairement révélées par l'AI Sandbox.

Un bon prompt est une définition précise

Les recherches sur la réduction des hallucinations dans le travail analytique pointent toutes dans la même direction : la spécificité et les limites l'emportent sur une formulation astucieuse. Une demande vague — « donne-moi le chiffre d'affaires par mois » — invite le modèle à choisir une définition à votre place, et il en choisira une qui est plausible mais fausse. Un bon analyste inscrit la métrique, les exclusions et la source de vérité dans le prompt, et donne au modèle la permission explicite de contester plutôt que de deviner. C'est cela la maîtrise de l'IA dans le fauteuil d'un analyste : le prompt et la rigueur analytique sont un seul et même acte.

Un exemple concret

Demandez le chiffre d'affaires net par mois. La version faible s'arrête là. La version forte définit « net », nomme les exclusions, précise 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 la cohérence du résultat par rapport à un chiffre auquel il fait 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 doesn't exist, tell me — do not guess a name
- Return the query, then list every assumption you made

• Bon : précise la métrique, les exclusions et la source de vérité ; vérifie la cohérence du résultat ; se méfie d'un chiffre que les données ne soutiennent pas.
• Faible : accepte une requête plausible, rapporte une valeur qui, discrètement, compte deux fois les remboursements, et ne s'en aperçoit jamais.

Les bonnes pratiques qui font vraiment la différence

• Définissez avant de demander. Mettez la définition de la métrique, les exclusions et la granularité temporelle dans le prompt — c'est dans l'ambiguïté que naissent les chiffres erronés.
• Donnez la permission de dire « je ne sais pas ». Dites au modèle de répondre « pas assez de données » ou « cette colonne n'existe pas » plutôt que de deviner. Il hallucine bien moins lorsque le refus est autorisé.
• Demandez les hypothèses. Faites-lui lister ce qu'il a supposé — c'est là que vous repérerez la définition mal comprise.
• Vérifiez la cohérence de chaque résultat par rapport à un chiffre auquel vous faites déjà confiance. Une valeur qui ne se réconcilie pas est le constat, pas une erreur d'arrondi.

Modes d'échec courants

• Métrique vague : « chiffre d'affaires » sans définition, alors le modèle en choisit une discrètement.
• Faire confiance au chiffre parce que la requête a l'air propre — du SQL propre sur une mauvaise définition reste une mauvaise réponse.
• Ne jamais réconcilier par rapport à un chiffre connu comme fiable, si bien que l'erreur est livrée comme un fait.

Comment nous l'évaluons

On ne peut pas tester cela avec un quiz de connaissances sur les prompts, et on ne peut pas le tester en retirant l'IA — cela ne mesure qu'une tâche que plus personne n'accomplit de cette façon. Vous confiez au candidat une tâche d'analyse réaliste avec des outils à disposition et vous observez s'il définit la métrique, s'il repère l'agrégat trompeur et s'il défend un chiffre qui tient réellement la route — ce que fait justement une évaluation AI Sandbox, et comment la maîtrise de l'IA est notée comme un pilier. Découvrez ce que couvre une évaluation complète d'analyste de données, pourquoi c'est le test honnête du recrutement natif de l'IA, ou regardez la composition d'une évaluation adaptée à un rôle.

Les meilleurs analystes traitent la réponse de l'IA comme ils traitent tout chiffre surprenant : coupable jusqu'à réconciliation. Cet instinct — et non la formulation du prompt — est ce qui empêche un chiffre erroné d'arriver au conseil d'administration.