Analyse de données
- Décrire un jeu de données comme un modèle en a besoin — colonnes, types et granularité
- Appliquer le flux de travail sûr en cinq étapes : décrire, demander, générer, exécuter vous-même, interpréter
- Traiter tout chiffre que le modèle n'a pas calculé comme non vérifié
- Énoncer les quatre hypothèses qui changent un résultat en silence : valeurs nulles, déduplication, fuseaux horaires, devise
- Garder les données sensibles hors des outils que vous n'avez pas vérifiés
Pas besoin d'être data scientist pour obtenir des réponses à partir de données avec l'IA — mais il faut la garder honnête. L'IA écrit la requête et explique le résultat ; c'est vous qui confirmez que les chiffres sont réels.
Ce avec quoi elle aide
- Écrire du SQL / des formules de tableur / du pandas à partir d'une question en langage courant.
- Expliquer ce que signifie une requête ou un résultat en termes métier.
- Nettoyer et transformer des données en désordre (décrivez le désordre, obtenez les étapes).
- Suggérer le bon graphique pour la question.
- Interpréter la sortie et proposer la question suivante.
Le flux de travail sûr
- Colonnes, types, et la GRANULARITÉ — une ligne correspond à quoi, exactement ? Ne présumez pas que le modèle puisse deviner vos noms, ni que order_id soit unique. La plupart des requêtes erronées se trompent sur la granularité, pas sur le SQL.
- En termes métier, avec la période et le filtre explicités. « Le chiffre d'affaires mensuel des commandes finalisées en 2025 » est une question à laquelle on peut répondre ; « comment vont les ventes » ne l'est pas.
- C'est l'explication que vous relisez. Si les hypothèses énoncées ne correspondent pas à vos données, la requête est fausse, aussi propre qu'elle paraisse.
- C'est l'étape non négociable. Un modèle qui annonce un résultat sans l'avoir exécuté sur vos données devine un chiffre plausible.
- Collez la sortie réelle. Le modèle lit alors des chiffres au lieu de les inventer, et c'est la seule chose qu'il fait ici de façon fiable.
Décrivez la granularité, puis demandez — du SQL avec hypothèses énoncées
My table orders has columns: order_id, customer_id, created_at, total_eur, status. One row per order. Write SQL for monthly revenue from completed orders in 2025, and explain any assumptions.
Rendez-lui la sortie — interprétation avec réserves
Here is the result of that query. Interpret it in business terms in under 120 words, then list anything that could make these numbers misleading — nulls, duplicate rows, time zone of created_at, mixed currencies, or partial months. Label each as "checked" or "unverified". Result: [paste the rows]
Garde-fous
Si l'IA énonce un résultat sans avoir exécuté la requête sur vos données, ce chiffre peut être inventé. Exécutez les requêtes vous-même ; traitez tout chiffre que vous n'avez pas calculé comme non vérifié. Et n'oubliez pas que corrélation ≠ causalité — demandez-lui de signaler les affirmations d'association. Voir Hallucinations.
- Vérifiez la plausibilité des ordres de grandeur — un résultat invraisemblable ? enquêtez, ne publiez pas.
- Énoncez les hypothèses (valeurs nulles, déduplication, fuseaux horaires, devise).
- Ne collez pas de données sensibles/PII dans des outils que vous n'avez pas vérifiés (Confidentialité).
Ces quatre hypothèses sont listées dans un ordre précis, car il correspond à peu près à la fréquence à laquelle elles vous piègent. Les valeurs nulles réduisent silencieusement un dénominateur ; les lignes en doublon gonflent silencieusement une somme ; un horodatage stocké en UTC mais lu en heure locale déplace du chiffre d'affaires d'un mois à l'autre ; et une colonne total qui mélange des devises produit un nombre arithmétiquement correct et économiquement dénué de sens.
- Demandez la requête ET une seconde requête qui en vérifie la plausibilité — un nombre de lignes, une plage de dates, une somme que vous pouvez juger à l'œil. Deux requêtes bon marché valent mieux qu'une seule, élégante, que vous ne pouvez pas vérifier.
- Quand un résultat vous surprend, soupçonnez la jointure avant de soupçonner l'activité. Une jointure qui démultiplie les lignes est la source la plus fréquente d'un chiffre soudainement 3× trop grand.
- Pour un travail sur tableur, demandez la formule plus une cellule d'exemple résolue. Si l'exemple est faux, vous avez trouvé le bug sans toucher à votre fichier réel.
Testez vos connaissances
Check yourself
0/3À retenir
- Décrivez d'abord les colonnes, les types et la GRANULARITÉ — les erreurs de granularité battent les erreurs de syntaxe en fréquence comme en coût
- Demandez toujours les hypothèses de la requête, et relisez-les avant le SQL
- Exécutez-la vous-même. Un chiffre que le modèle n'a pas calculé est non vérifié par définition
- Rendez-lui la sortie réelle pour l'interprétation — lire des chiffres est la partie que l'IA fait de façon fiable
- Valeurs nulles, lignes en doublon, fuseaux horaires et devises mélangées sont les quatre facteurs qui changent discrètement un résultat
- Vérifiez la plausibilité des ordres de grandeur et des nombres de lignes ; soupçonnez la jointure quand un total s'envole
- Gardez les PII hors des outils que vous n'avez pas vérifiés
Et après
- Artefacts : des sorties vivantes et exécutables — construisez un tableau de bord rapide
- Pack de compétences Analyste de données
- Hallucinations et comment les réduire