Le réflexe qui coûte cher
Vous collez votre question, Claude renvoie une requête SQL impeccable, un chiffre tombe : « 1 284 312 € de chiffre d'affaires sur le trimestre ». Vous le copiez dans le rapport du COMEX. Trois jours plus tard, quelqu'un remarque que la requête comptait deux fois les commandes remboursées. Le mal est fait.
Ce scénario est la raison d'être de ce parcours. Claude est un bras droit data extraordinaire : il écrit du SQL plus vite que vous, connaît les dialectes, repère des patterns d'analyse, rédige des synthèses claires. Mais il produit du texte plausible, pas du texte vérifié. Sur la data, plausible ne suffit jamais — un chiffre faux mais crédible est plus dangereux qu'une erreur évidente.
La règle d'or, non négociable
Toute sortie de Claude qui touche à un chiffre, une requête ou une décision se vérifie de façon indépendante avant d'être utilisée.
Ce n'est pas de la méfiance, c'est de la méthode. Les meilleurs analystes ne font confiance ni à leur propre SQL ni à celui d'un collègue sans contrôle. Claude ne mérite pas un traitement de faveur. Il mérite mieux : un cadre où ses forces brillent et où ses erreurs sont attrapées avant qu'elles ne fuient.
Ce que Claude fait remarquablement bien
- Traduire une intention en SQL : « le panier moyen par segment client, hors commandes annulées » devient une requête en secondes.
- Jongler avec les dialectes : PostgreSQL, BigQuery, Snowflake, MySQL n'ont pas la même syntaxe de dates ni les mêmes fonctions. Claude bascule de l'un à l'autre sans effort, si vous lui dites lequel.
- Expliquer et commenter : il décortique une requête héritée de 200 lignes et vous dit ce qu'elle fait.
- Profiler et explorer : il propose des angles d'analyse, des contrôles de qualité, des visualisations.
- Rédiger : il transforme un tableau de chiffres en synthèse lisible par un décideur non technique.
Ce sur quoi il se trompe — et pourquoi
Trois familles d'erreurs reviennent sans cesse :
- Les hypothèses silencieuses. Sans le schéma, Claude invente des noms de colonnes plausibles (order_date alors que la vraie colonne est created_at), suppose qu'un montant est en euros alors qu'il est en centimes, ou ignore qu'une table contient des doublons logiques.
- La sémantique SQL piégeuse. Les NULL, les jointures qui dupliquent les lignes, les agrégats sur des données dénormalisées : autant de zones où une requête s'exécute sans erreur tout en renvoyant un faux résultat. C'est le pire cas — pas de message d'alerte, juste un chiffre faux.
- L'aplomb. Claude formule une réponse fausse avec la même assurance qu'une réponse juste. Il n'y a pas de signal de confiance fiable dans le ton. C'est à vous de créer ce signal, par la vérification.
Le bon modèle mental : analyste junior brillant, pas oracle
Traitez Claude comme un analyste junior surdoué et infatigable, à qui vous confieriez du travail — mais dont vous relisez systématiquement le livrable parce qu'il ne connaît pas vos données aussi bien que vous, et qu'il ne vous dira jamais spontanément « là, je ne suis pas sûr ».
Concrètement, cela change votre façon de prompter. Au lieu de :
Donne-moi le CA du trimestre.
vous écrivez :
Voici le schéma de la table orders (je le colle ci-dessous). Le CA = somme de amount_cents / 100, uniquement pour status = 'paid', sur les commandes dont created_at est dans Q2 2026. Attention aux remboursements : ils sont dans une table refunds séparée. Donne-moi la requête PostgreSQL, explique tes hypothèses, et propose une requête de contrôle indépendante pour valider le total.
La différence de qualité est radicale — et la dernière phrase (« propose une requête de contrôle ») installe la vérification dès le premier prompt.
Le contrat de ce parcours
Sur les six leçons, vous allez apprendre à : générer du SQL fiable à partir d'un schéma, debugger et optimiser une requête, mener une analyse exploratoire robuste, et — c'est le cœur, la leçon 5 — vérifier le travail de l'IA par des requêtes de contrôle et du recompute indépendant. On termine par la synthèse exécutive : transformer des chiffres vérifiés en décisions.
À aucun moment vous ne déléguerez votre jugement. Vous déléguerez la production, vous garderez le contrôle. C'est exactement ce qui sépare un analyste qui utilise l'IA d'un analyste qui se fait piéger par elle.
Sources & méthode · Bonnes pratiques SQL/analytics établies, vérifiées à la rédaction. Contenu original pour ClaudeAI Academy.