Je travaille avec dbt Core et dbt Cloud, principalement sur BigQuery avec quelques projets Snowflake. Mes journées consistent à construire des modèles de base, écrire des tests, documenter des colonnes, et débugger des modèles incrémentaux.

Claude Code a transformé ma façon de travailler. Ce n’est pas qu’il écrit du code parfait, mais il gère la traduction du concept à l’implémentation concrète.

Les workflows qui ont tout changé

Génération de modèles de base

Créer un modèle de base prenait environ 15-20 minutes : examiner le schéma source, revoir les modèles existants, adapter les structures, ajouter les métadonnées, écrire le YAML, et inclure les tests.

Maintenant je demande :

“Create a dbt base model for source_shopify.orders following the patterns in models/base/”

Claude Code examine les modèles existants, reconnaît les conventions de nommage, identifie les colonnes de métadonnées standards, et génère les fichiers SQL et YAML. Je révise le diff et j’approuve.

Les prompts efficaces spécifient des contraintes :

“Create a base model for source_stripe.charges from that specific GCP project. Follow patterns in models/base/base_shopify__orders.sql…”

Les prompts vagues produisent des résultats génériques nécessitant des corrections importantes.

Je maintiens un fichier CLAUDE.md spécifiant les valeurs par défaut :

“All base models include _loaded_at and _source_table columns. Timestamps cast to Europe/Paris timezone. Source freshness: warn_after 12 hours, error_after 24 hours…”

Cela évite les incohérences. Le processus prend maintenant 2-3 minutes révision comprise—une amélioration substantielle pour l’intégration de nouvelles sources de données avec de nombreuses tables.

Écriture de tests

Écrire des tests est souvent reporté malgré sa nécessité. Claude Code rend la génération de tests suffisamment rapide pour que je les complète maintenant systématiquement.

Pour les tests de schéma, je référence un modèle :

“Write schema tests for mrt__daily_revenue. Include uniqueness on the primary key, not_null on required fields, and accepted_values where appropriate…”

Claude lit le modèle, trace les colonnes, et génère les tests appropriés tout en détectant les relations que je pourrais négliger.

Pour les tests singuliers nécessitant une logique complexe, je décris les exigences de validation :

“Write a singular test that verifies mrt__customer_lifetime_value never has negative values for total_revenue, and that first_order_date is always before or equal to last_order_date.”

Être explicite sur les règles de qualité des données assure la cohérence dans la génération des tests.

Documentation

Les descriptions de colonnes apportent une vraie valeur mais sont fastidieuses à écrire. Mon approche consiste à demander :

“Add documentation to models/marts/mrt__product_performance.yml. Read the model to understand what each column represents…”

Claude lit le SQL du modèle, trace les colonnes jusqu’aux sources si nécessaire, et écrit des descriptions expliquant la fonctionnalité.

Une documentation de qualité diffère des définitions techniques :

• Mauvais : “order_count: Le nombre de commandes”
• Mieux : “order_count: Nombre total de commandes complétées pour ce produit sur la période. Exclut les commandes annulées et remboursées.”

Pour les descriptions de modèles, je demande des informations contextuelles :

“Write a model description for mrt__site_performance that explains: What business questions it answers, key grain, main upstream dependencies, important caveats…”

Débogage

Avant : lire l’erreur → ouvrir le modèle → tracer en amont → exécuter des requêtes manuellement → identifier le problème, impliquant de nombreux changements d’onglets.

Maintenant :

“[Coller l’erreur] Why is it failing and how do I fix it?”

Claude examine le modèle, exécutant souvent dbt compile pour voir le SQL rendu, puis identifie les problèmes allant des clés de jointure nulles aux complications de macros.

Apprendre à Claude Code à utiliser dbt compile efficacement s’est avéré précieux. J’inclus dans mon CLAUDE.md :

“Use dbt compile -s model_name to see rendered SQL. Use dbt parse to understand lineage. Check source freshness with dbt source freshness -s source_name”

Refactoring

Renommer des colonnes utilisées dans de nombreux modèles en aval décourageait auparavant un refactoring approfondi. Avec Claude Code :

“Rename customer_id to user_id across all models in models/marts/ that reference dim_customers. Update the YAML files too.”

Claude localise toutes les références, effectue les changements, et affiche les diffs pour révision. Cette fonctionnalité excelle pour les migrations à l’échelle du projet :

“We’re moving from ref(‘stg_orders’) to ref(‘base__shopify__orders’) across the codebase. Find all references to stg_* models and update them to use the new base__* naming convention.”

La connaissance du codebase par Claude permet de comprendre les dépendances et d’effectuer des modifications cohérentes.

Les prompts qui marchent (et ceux qui ne marchent pas)

Les prompts efficaces démontrent :

• La spécificité sur les résultats souhaités
• Des contraintes et exigences explicites
• Des références aux patterns existants du codebase
• Des définitions claires de “bons” résultats

Bon exemple :

“Create an intermediate model int_orders__pivoted that takes base__shopify__orders and pivots the order_status column into separate boolean columns (is_pending, is_completed, is_cancelled). Follow the pattern in int_customers__aggregated. Add tests for the primary key and ensure the grain stays at order_id.”

Les prompts inefficaces sont :

• Vagues sur l’intention
• Supposent une mémoire de session (inexistante)
• Manquent de contexte projet
• Laissent des décisions critiques indéfinies

Mauvais exemple :

“Make a model that aggregates orders”

Claude produit un résultat générique. Un autre mauvais exemple :

“Like we discussed yesterday, update the revenue model”

Claude n’a pas de mémoire entre les sessions. Spécifiez le modèle, indiquez les changements requis, et fournissez du contexte.

Structure CLAUDE.md exemple

# Analytics Project

## Project Structure
- models/base/ — One model per source table, light transformations only
- models/intermediate/ — Business logic, joins, aggregations
- models/marts/ — Final outputs for BI tools and analysts

## Common Commands
- `dbt run -s model_name` — Run specific model
- `dbt run -s +model_name` — Run model with upstream dependencies
- `dbt test -s model_name` — Test specific model
- `dbt compile -s model_name` — See rendered SQL (useful for debugging)
- `dbt build -s model_name+` — Run and test model with downstream

## SQL Style
- Trailing commas in SELECT
- CTEs ordered: imports, logical transformations
- CTE names: prefixed with source (e.g., orders__filtered)
- snake_case for all identifiers
- Explicit column lists (no SELECT *)

## Naming Conventions
- Base models: base__{source}__{table}
- Intermediate: int__{entity}__{table}
- Marts: mrt__{entity}__{area}

## Data Types
- Timestamps: TIMESTAMP, cast to Europe/Paris timezone
- Currency: INTEGER (cents, not decimals)
- IDs: STRING (even if numeric at source)

## Testing Standards
- Every model has unique + not_null on primary key
- Foreign keys tested with relationships
- Source freshness on all sources

## Warehouse
BigQuery (project: dbt-prod, dataset: dbt)

Ce document, d’environ 40 lignes, nécessite un investissement initial et des mises à jour périodiques mais devient de plus en plus précieux avec le temps.

Quand NE PAS utiliser Claude Code

Claude Code gère l’implémentation, pas la conceptualisation. J’évite de l’utiliser pour :

La logique métier complexe nécessitant compréhension : Concevoir des modèles d’attribution ou calculer la valeur vie client nécessite un engagement personnel. Déléguer ce travail produit du code que je ne comprends pas entièrement—problématique pour une logique critique.

Les requêtes sensibles en matière de sécurité : Tout ce qui implique des informations personnellement identifiables, des credentials, ou un accès en écriture à la production demande une manipulation soigneuse. Les générateurs de texte ne comprennent pas les conséquences.

L’apprentissage de nouveaux concepts : Lors de l’acquisition de nouvelles compétences, lutter à travers les difficultés facilite une compréhension véritable. Contourner cette lutte signifie manquer de vraie compréhension.

Investissement temps vs retour

La mise en place a nécessité un véritable effort :

• Installation et authentification : 10 minutes
• Création initiale du CLAUDE.md : 1 heure
• Apprentissage des prompts efficaces : plusieurs semaines d’expérimentation
• Développement de workflows personnalisés : 1-2 jours

Total : environ plusieurs semaines avant qu’une valeur constante n’émerge.

Retour : Les économies de temps quotidiennes estimées sur les tâches routinières (modèles de base, tests, documentation, débogage, refactoring) s’accumulent en jours mensuels et en temps significatif annuellement.

Au-delà des économies de temps, les tâches auparavant ignorées sont maintenant complétées : documentation, tests, refactoring qui semblaient autrefois trop fastidieux à prioriser.

Claude Code amplifie les capacités existantes—il accélère l’implémentation mais ne remplace pas les connaissances fondamentales. Les utilisateurs nécessitant une compréhension de la structure des données, de la qualité de conception des modèles, et de la reconnaissance des problèmes en tirent le maximum de bénéfices.

L’outil n’améliore pas les fondamentaux du data engineering ; il augmente la vitesse et la cohérence pour ceux qui les possèdent.