Forces et limites de Claude Code pour la donnée

Claude Code est un outil de codage agentique qui lit des fichiers, comprend la structure du projet, écrit du code, exécute des commandes et itère sur la base des résultats. Le modèle mental : Claude Code est un développeur junior capable — rapide, productif, doué pour suivre des patterns — avec un humain qui revoit chaque ligne avant la mise en production.

Là où Claude Code fonctionne bien

Génération de boilerplate

Les modèles de base, le YAML source, les fichiers de tests de schéma — tout ce qui a une structure prévisible est le territoire le plus fort de Claude Code. Ces tâches partagent trois propriétés : le pattern est bien établi, la variation porte sur des détails (noms de tables, noms de colonnes, types de données), et la correction est mécaniquement vérifiable (est-ce que ça compile ? Est-ce que les tests passent ?).

Une invite typique :

Create a base model for raw_shopify.orders following my existing
base model patterns. Include source YAML, schema tests for primary
key uniqueness and not-null on required fields.

Claude Code lit vos modèles de base existants, capture la convention de nommage, la structure des CTE, la stratégie de matérialisation et le pattern de déduplication, puis génère un modèle qui semble appartenir à votre projet. Il génère également le YAML correspondant avec des tests. La sortie compile généralement dès le premier essai car Claude exécute dbt compile dans sa boucle de travail et corrige les problèmes.

C’est là que l’adéquation structurelle entre le travail data et l’IA agentique est la plus visible. La haute densité de patterns des projets dbt signifie que Claude Code apprend vos conventions à partir de quelques exemples et les applique de manière cohérente sur des dizaines de nouveaux modèles.

Modifications multi-fichiers

Renommer une colonne dans les modèles en aval, refactoriser une macro et mettre à jour tous ses sites d’appel, restructurer un ensemble de modèles après un changement de schéma de source — ces tâches nécessitent des modifications coordonnées sur plusieurs fichiers. Claude Code les gère nativement parce qu’il peut lire l’ensemble du projet, identifier chaque référence et les mettre à jour en une seule passe.

Rename the column order_amount to order__amount_usd in
base__shopify__orders and update all downstream references.
Run dbt build on the affected models to verify.

C’est le type de travail fastidieux et sujet aux erreurs pour les humains (ai-je trouvé toutes les références ? en ai-je manqué une dans une macro ?) et trivialement correct pour un agent qui peut parcourir l’ensemble du projet. Voir Workflows avancés de Claude Code pour dbt pour l’approche systématique des opérations multi-fichiers.

Exploration de base de code

Lorsque vous entrez dans un projet dbt inconnu — un nouveau projet client, une base de code héritée, un projet open source que vous évaluez — Claude Code peut expliquer ce que fait le projet, comment il est structuré et comment les données y circulent. “What does this project do?” produit un aperçu utile. “Trace the lineage from raw_stripe.payments to the final revenue mart” produit un parcours spécifique.

Cela fonctionne bien parce que c’est une tâche de lecture et de résumé. Claude Code lit les fichiers, suit les appels ref() et synthétise une explication cohérente. Aucun contexte métier n’est nécessaire — la compréhension structurelle est dans le code lui-même.

Réplication de patterns

Une fois que vous avez un bon exemple de n’importe quel pattern — un modèle intermédiaire bien structuré, une macro testée, un bloc de documentation — Claude Code applique ce pattern ailleurs de manière fiable. Le principe du “bon exemple unique” : investissez du temps pour qu’un modèle soit juste, puis laissez l’agent le répliquer dans tout votre projet.

Use int__orders__enriched as a template pattern. Create an
equivalent intermediate model for the sessions entity, joining
base__ga4__events with base__ga4__session_params.

L’agent lit le modèle de référence, extrait le pattern structurel (flux de CTE, approche de jointure, convention de nommage, bloc de config) et l’applique au nouveau contexte. Le résultat respecte vos conventions parce qu’il les a apprises de votre code, pas d’un ensemble d’entraînement générique.

Là où Claude Code peine

Logique métier inédite

Si vous concevez un modèle d’attribution complexe, construisez un calcul de reconnaissance des revenus avec des cas limites spécifiques à votre activité, ou créez une segmentation client qui dépend d’une connaissance organisationnelle — Claude Code ne peut pas réfléchir au problème à votre place. Il implémente ce que vous décrivez, mais la réflexion difficile reste humaine.

Cette limitation est structurelle, pas un bug. La logique métier inédite dépend d’un contexte qui n’existe pas dans votre base de code : ce que “client actif” signifie dans votre entreprise, comment votre équipe financière gère les remboursements, quels cas limites importent pour la conformité réglementaire. Quelle que soit la quantité de lecture de vos fichiers de projet, Claude Code n’a pas accès à cette connaissance.

L’implication pratique : utilisez Claude Code pour implémenter la logique métier après l’avoir conçue, pas pour la concevoir. Rédigez les exigences vous-même (ou dans votre invite), puis laissez l’agent les traduire en SQL. Revoyez la sortie par rapport à vos exigences, pas par rapport à une correction SQL générique.

Exigences ambiguës

Lorsque les invites sont vagues, Claude Code fait des choix qui semblent confiants mais peuvent ne pas correspondre à votre intention. “Build me a customer model” produit quelque chose — mais le grain, les attributs inclus, le niveau d’agrégation et la logique métier sont tous des hypothèses que l’agent a faites sans guidance.

La solution est la spécificité. Comparez :

Vague : “Create a customer metrics model.”

Spécifique : “Create a mart model at one-row-per-customer grain. Include total_orders, total_revenue_usd, first_order_date, last_order_date, and days_since_last_order. Source from int__orders__enriched. Materialize as table. Add unique and not_null tests on customer__id.”

La deuxième invite ne laisse aucune place à des hypothèses. Chaque colonne, le grain, la source, la matérialisation et les tests sont spécifiés. La sortie de Claude Code correspondra à votre intention parce que votre intention est explicite.

C’est l’une des raisons pour lesquelles CLAUDE.md comme mémoire de projet est si important. Les conventions encodées dans CLAUDE.md (patterns de nommage, valeurs par défaut de matérialisation, exigences de tests) agissent comme une spécificité implicite pour chaque invite. Vous n’avez pas à répéter “use double-underscore naming” parce que l’agent le lit dans le fichier.

Sur-ingénierie

Sans contrainte, Claude Code tend à ajouter plus que ce que vous avez demandé. Une gestion d’erreurs supplémentaire où aucune n’est nécessaire. Des abstractions inutiles (“let me create a macro for that”). Des commentaires expliquant du code évident. Des CTE supplémentaires qui décomposent une transformation simple en étapes trop granulaires.

C’est un pattern connu des LLM en général — ils optimisent pour paraître rigoureux. Dans un contexte dbt, la sur-ingénierie se manifeste sous forme de :

• Ajout de SAFE_CAST partout, même sur des colonnes qui ne peuvent pas échouer à une conversion de type
• Création de macros auxiliaires pour des transformations ponctuelles
• Ajout de descriptions de colonnes dans le YAML qui reformulent le nom de colonne (“customer_id: The ID of the customer”)
• Encapsulation de logique simple dans des CTE inutiles

L’atténuation est la revue. Lorsque vous voyez quelque chose que l’agent a ajouté et que vous n’avez pas demandé, demandez-vous : est-ce que cela ajoute de la valeur ou seulement des lignes ? Dans le deuxième cas, dites à Claude de le supprimer. Avec le temps, ajoutez des instructions dans votre CLAUDE.md : “Don’t add SAFE_CAST unless the data type conversion could genuinely fail.” “Don’t create macros for logic used in only one model.”

Grands monorepos

Sur des bases de code très volumineuses — des centaines de modèles sur plusieurs projets dans un monorepo — Claude Code peut perdre le fil des fichiers pertinents ou manquer des patterns enfouis profondément dans le projet. La fenêtre de contexte, bien que large, n’est pas illimitée. Lorsque le projet dépasse ce que Claude Code peut garder en mémoire, il commence à faire des choix sur ce qu’il faut lire et ce qu’il faut ignorer. Ces choix ne sont pas toujours corrects.

Pour les grands projets, l’atténuation est un contexte structuré. Un CLAUDE.md bien organisé avec des pointeurs vers les répertoires clés, les conventions de nommage et les décisions architecturales aide Claude Code à naviguer dans le projet sans tout lire. Les fichiers CLAUDE.md au niveau des répertoires dans les sous-répertoires de monorepos délimitent le contexte à la section pertinente.

Le modèle mental en pratique

Le cadre du “junior capable” n’est pas condescendant — il est opérationnel. Un développeur junior capable :

• Suit les patterns établis de manière fiable
• Produit du code propre et conventionnel rapidement
• A besoin d’instructions spécifiques pour les exigences non évidentes
• Fait parfois plus que demandé (par enthousiasme, pas par malveillance)
• Nécessite une revue de code sur chaque travail
• Ne peut pas prendre de décisions métier indépendamment
• S’améliore avec le temps à mesure que vous encodez plus de conventions

Travailler efficacement avec Claude Code signifie adopter le même style de management que vous utiliseriez avec un membre d’équipe solide mais inexpérimenté. Donnez des instructions claires. Fournissez de bons exemples. Revoyez tout. Encodez le retour d’information récurrent comme des conventions (dans CLAUDE.md) afin de ne pas vous répéter.

Le contexte et le processus autour de l’outil — configuration du projet, commandes réutilisables, garde-fous, et une revue approfondie — sont ce qui différencie une utilisation efficace d’une utilisation frustrante.