Claude, bras droit data — pas remplaçant

Le réflexe qui coûte cher

Tu colles ta question, Claude renvoie une requête SQL impeccable, un chiffre tombe : « 1 284 312 € de chiffre d'affaires sur le trimestre ». Tu le recopies 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 toi, 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 tu lui dis lequel.
• Expliquer et commenter : il décortique une requête héritée de 200 lignes et te 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 :

1. 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.
2. 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.
3. 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 à toi de créer ce signal, par la vérification.

Le contexte de 1M tokens change ce que tu peux coller

Depuis Opus 5, tu n'as plus d'excuse pour briefer à moitié : le schéma complet, la doc métier, un extrait de données et la requête historique tiennent dans la même conversation. La plupart des erreurs de la leçon 2 viennent d'un contexte tronqué — ce plafond-là vient de sauter.

Analyste junior brillant, pas oracle

Traite Claude comme un analyste junior surdoué et infatigable, à qui tu confierais du travail — mais dont tu relis systématiquement le livrable, parce qu'il ne connaît pas tes données aussi bien que toi et qu'il ne te dira jamais spontanément « là, je ne suis pas sûr ».

Concrètement, ça change ta façon de prompter :

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.

Tu es analyste data senior. Nous allons travailler ensemble sur une base réelle.

Règles de travail, valables pour toute la conversation :
1. Tu ne devines jamais un nom de colonne, un type ou une unité : si l'information manque, tu la demandes.
2. Après chaque requête, tu listes explicitement les hypothèses que tu as faites (colonnes, unités, fuseau, filtres, cardinalités).
3. Tu proposes systématiquement une requête de contrôle indépendante qui valide le résultat par un autre chemin.
4. Tu restes concis : la requête, les hypothèses, le contrôle. Pas de préambule.

Confirme que tu as compris en une phrase, puis attends mon schéma.

Ce que tu as le droit de coller

Sur la data, la question n'est pas seulement « est-ce juste ? » mais « ai-je le droit de montrer ça ? ». Au 6 août 2026, le régime dépend de ton plan :

Trois conséquences concrètes :

• Si tu manipules des données clients réelles, un compte Pro ne suffit pas juridiquement. Il te faut Team ou Enterprise — ou une pseudonymisation sérieuse avant de coller quoi que ce soit.
• Anthropic n'héberge pas l'inférence dans l'Union européenne en direct : côté API, le paramètre inference_geo n'accepte que us ou global. Si ton cadre de conformité impose l'UE, ce point se traite en amont, pas dans le prompt.
• Une bonne pratique universelle, quel que soit le plan : colle des schémas et des échantillons anonymisés, pas des exports bruts. Claude a besoin de la structure, pas des noms de tes clients.

Le contrat de ce parcours

Sur les six leçons, tu vas apprendre à générer du SQL fiable à partir d'un schéma, debugger et optimiser une requête, mener une analyse exploratoire robuste, brancher Claude sur tes sources — et, c'est le cœur en 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 tu ne délègues ton jugement. Tu délègues la production, tu gardes 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, statistiques robustes et data-viz : savoir établi, vérifié à la rédaction. Contenu original pour ClaudeAI Academy.

Faits Claude vérifiés le 6 août 2026 — Opus 5, ce qui change · Modèles et tarifs · Cache de prompt · Prompter Opus 5 · Notes de version · Spécification MCP 2026-07-28 · Connecteur Anthropic Economic Index · Plans et tarifs. Les prix, les limites et les versions bougent vite : redate-les avant de t'en servir dans une décision.