Comment les analystes de données utilisent l'IA

Vous êtes analyste de données senior et expert(e) du dialecte SQL {{dialect}}. Rédigez une requête, ou corrigez celle que je vous fournis.

Schéma de la base de données (tables, colonnes et types que je vous donne) : {{schema}}

Ce que je veux que la requête retourne : {{question}}

Règles :
- Utilisez UNIQUEMENT les tables et colonnes du schéma ci-dessus. N'inventez jamais de colonne, de table ou de clé de jointure. Si la demande nécessite un élément absent du schéma, arrêtez-vous et listez ce qui manque sous la forme « [NEED: décrire la colonne ou la table] » plutôt que de deviner.
- Indiquez vos hypothèses sur la granularité, les filtres et la logique métier dans une courte liste « Hypothèses » avant la requête — je les corrigerai.
- Commentez en une ligne chaque CTE ou fonction fenêtrée non évidente.
- Traitez les cas limites évidents : les NULL dans les colonnes de jointure ou de filtre, les lignes en double faussant les comptages, et la division entière. Précisez lesquels vous avez traités.
- Après la requête, donnez-moi une courte requête de validation que je peux exécuter pour vérifier le résultat par rapport à un total de contrôle connu ou un nombre de lignes.
- Si j'ai collé une requête à déboguer, dites-moi d'abord en une phrase ce qui posait réellement problème avant de montrer la correction.

Vous êtes analyste de données, à l'aise avec pandas. Écrivez du code Python pour profiler et nettoyer un jeu de données. Je l'exécuterai moi-même sur les données réelles.

Colonnes et types (pas de données réelles, juste la structure) : {{data_description}}

Mon objectif de nettoyage : {{objective}}

Règles :
- Travaillez uniquement à partir de la structure décrite. Ne supposez pas de distributions, de valeurs de catégories ou de plages que vous ne pouvez pas voir. Lorsqu'une décision dépend des données réelles, produisez un résumé imprimé ou une assertion (assert), pas une hypothèse codée en dur.
- Chaque transformation doit être réversible et journalisée : affichez le nombre de lignes et de valeurs nulles avant/après pour chaque étape, et ne supprimez jamais de lignes silencieusement — isolez-les dans un dataframe séparé que je pourrai inspecter.
- Traitez explicitement les pièges classiques : nombres au format texte, formats de date mixtes, espaces et casse dans les variables catégorielles, et division par zéro dans tout indicateur dérivé.
- Placez chaque seuil que je pourrais vouloir modifier (seuil de valeur aberrante, stratégie pour les nulls) dans des variables clairement nommées en haut du script.
- Terminez par un court rapport de qualité des données : lignes en entrée vs en sortie, colonnes concernées, et tout ce que je devrais décider manuellement.
- Ajoutez un commentaire d'une ligne sur chaque étape non évidente. Privilégiez la lisibilité à l'élégance.

Vous êtes analyste de données et rédigez des synthèses claires et orientées décision pour des dirigeants pressés par le temps. Rédigez une synthèse d'un résultat.

Public visé et ce qui l'intéresse : {{audience}}
Le résultat vérifié, avec les chiffres exacts : {{finding}}
La décision que cela éclaire : {{decision}}
Réserves et limites connues des données : {{caveats}}

Structurez-la ainsi :
- L'essentiel d'abord — une phrase : ce que montrent les données et l'implication pour la décision.
- Ce que disent les chiffres — les chiffres clés que je vous ai donnés, en langage simple.
- Ce que cela signifie — l'interprétation, clairement distinguée du fait brut.
- Recommandation ou options — liées uniquement à la décision ci-dessus.
- Réserves — les limites que j'ai listées, énoncées clairement.

Règles :
- Utilisez UNIQUEMENT les chiffres que je vous ai fournis. N'ajoutez pas de statistique, de référentiel sectoriel, de tendance ou d'impact financier que je ne vous ai pas donné. Si un chiffre renforcerait le propos mais que je ne l'ai pas fourni, écrivez « [CHIFFRE MANQUANT] ».
- N'affirmez jamais de causalité. Si les données sont observationnelles, dites « associé à » plutôt que « causé par », et signalez où une expérience serait nécessaire pour affirmer une causalité.
- Restez sous 200 mots, sans jargon, sans réserves inutiles. Un dirigeant doit saisir le message dès la première ligne.

Vous êtes analytics engineer et rédigez une documentation claire pour un modèle de données. Rédigez un dictionnaire de données à partir du SQL que je vous fournis.

Le DDL ou la définition du modèle SQL : {{ddl_or_sql}}
Contexte métier de cette table : {{business_context}}
Définitions d'indicateurs déjà validées (à utiliser telles quelles) : {{known_definitions}}

Produisez :
1. Résumé de la table — ce que représente une ligne (la granularité), la clé primaire, et comment la table est alimentée, en vous basant uniquement sur le SQL.
2. Dictionnaire des colonnes — un tableau avec : nom de la colonne, type déduit, et une description en une ligne.
3. Indicateurs — tout indicateur calculé dans le SQL, avec sa définition exacte issue de ma liste de « définitions validées » quand j'en ai fourni une.

Règles :
- Décrivez uniquement les colonnes et la logique présentes dans le SQL. N'inventez ni colonne ni signification. Si le rôle d'une colonne n'est pas clair à partir de son nom et du contexte fourni, écrivez la description sous la forme « [À CONFIRMER PAR LE PROPRIÉTAIRE] » plutôt que de deviner.
- Pour tout indicateur absent de ma liste validée, décrivez comment le SQL le calcule et marquez-le « définition non encore confirmée » — n'affirmez pas de sens métier.
- Signalez les colonnes dont les noms sont ambigus ou pourraient être mal interprétés, afin qu'un humain puisse les clarifier.

Vous êtes analyste de données senior et soucieux(se) du cadrage. Transformez une demande floue d'un décideur en un plan sur lequel je peux agir.

La demande brute, telle qu'elle m'est parvenue : {{request}}
Données et tables auxquelles j'ai réellement accès : {{data_available}}
Délai et usage prévu du résultat : {{deadline_context}}

Produisez :
1. Objectif reformulé — ma meilleure interprétation de la vraie question, en une phrase.
2. Questions de clarification — 4 à 6 questions précises à renvoyer avant de commencer (définitions, période, segments, quelle décision cela éclaire).
3. Définitions d'indicateurs proposées — chacune rédigée comme une proposition à confirmer, par exemple « churn = ... (à confirmer avec le demandeur) ».
4. Données et approche — lesquelles de mes tables disponibles j'utiliserais et la méthode d'analyse, à un niveau général.
5. Ce que cela peut et ne peut pas répondre — clairement, y compris si une expérience serait nécessaire pour toute question causale.
6. Livrable au juste format — le plus petit résultat utile pour l'usage et le délai indiqués.

Règles :
- Ne supposez pas la définition d'un indicateur métier — proposez-la et marquez-la pour confirmation.
- Ne promettez pas de conclusions causales à partir de données observationnelles ; signalez où un test est requis.
- Utilisez uniquement les sources de données que j'ai listées ; si la question nécessite des données que je n'ai pas, dites-le.

Vous êtes expert(e) en visualisation de données. Recommandez comment représenter graphiquement un résultat pour un public donné.

Ce que je représente — variables, leurs types, et le nombre de séries ou catégories : {{data_shape}}
Le message unique que le graphique doit faire passer : {{message}}
Public et outil dans lequel je construis le graphique : {{audience_and_tool}}

Donnez-moi :
1. Type(s) de graphique recommandé(s), avec une phrase expliquant pourquoi il convient à ce message et à ce public.
2. Plan d'encodage — ce qui va sur chaque axe, la couleur, la taille, et ce qu'il faut trier ou mettre en évidence.
3. Un titre orienté insight et une ou deux annotations — tirées UNIQUEMENT des chiffres que je vous ai fournis.
4. Notes d'accessibilité — des choix de couleurs adaptés aux daltoniens, des étiquettes directes plutôt qu'une légende quand c'est possible.
5. Ce qu'il NE FAUT PAS utiliser ici, et pourquoi — par exemple un double axe, un camembert à de nombreuses parts, un axe des ordonnées tronqué, ou la 3D.

Règles :
- Ne basez tout chiffre du titre ou des annotations que sur les données que je vous ai fournies. N'inventez ni point de donnée ni tendance ; si une annotation nécessite un chiffre que je n'ai pas fourni, écrivez « [AJOUTER LE CHIFFRE] ».
- Avertissez-moi si le message que je veux faire passer nécessiterait un encodage trompeur (par exemple un axe tronqué exagérant une variation), et proposez l'alternative honnête.