Pipeline de revue SQL en couches pour dbt

Aucun outil unique ne détecte toutes les classes d’erreurs SQL. Les linters détectent le formatage. L’IA détecte les problèmes sémantiques. Les tests dbt détectent les violations de données. Un pipeline en couches empile les outils à différentes étapes afin que chaque couche détecte ce que les autres manquent, et la profondeur de revue s’adapte au risque de la modification.

Ce pattern s’applique spécifiquement aux projets dbt. Les outils et les points d’intégration sont spécifiques à dbt.

Couche 1 : Feedback IDE (temps réel)

Claude Code, Cursor ou un autre assistant de coding IA fournit un feedback en temps réel pendant que vous écrivez. Cette couche détecte les problèmes sémantiques de base : mauvaises références de table, erreurs évidentes de JOIN, colonnes manquantes, patterns qui ne correspondent pas aux conventions de votre projet.

La clé pour rendre le feedback IDE utile est le contexte. Un CLAUDE.md bien configuré avec vos conventions de nommage, votre stratégie de partitionnement et vos patterns courants réduit les faux positifs de 50% ou plus, selon ce que les équipes rapportent après avoir ajouté des règles spécifiques au projet.

Ce qu’il faut inclure dans votre CLAUDE.md pour la qualité de revue :

Spécificités du warehouse : colonnes de partition BigQuery et leurs filtres requis, colonnes de clé de clustering Snowflake
Règles PII : colonnes contenant des données personnelles qui ne doivent jamais apparaître dans les modèles marts
Définitions de logique métier : comment votre entreprise calcule le chiffre d’affaires, ce que signifie « client actif », quelles commandes doivent être exclues des métriques
Anti-patterns courants : les erreurs spécifiques que votre équipe répète

Cette couche fonctionne en permanence. Il n’y a pas de coût CI, pas de délai de pipeline. Le compromis est qu’elle ne voit que ce qui est dans votre contexte actuel — elle ne peut pas détecter les problèmes inter-modèles ou les problèmes qui émergent des interactions entre fichiers.

Couche 2 : Pre-commit (à chaque push)

Les hooks pre-commit s’exécutent automatiquement lors d’un commit. Ils détectent deux catégories de problèmes : les violations de formatage (SQLFluff) et les problèmes structurels spécifiques à dbt (DataPilot).

repos:
  - repo: https://github.com/sqlfluff/sqlfluff
    rev: 3.3.0
    hooks:
      - id: sqlfluff-lint
        args: [--dialect, bigquery]
  - repo: https://github.com/AltimateAI/datapilot-cli
    hooks:
      - id: datapilot-cli

SQLFluff gère le formatage : support de 20+ dialectes SQL, un plugin dbt dédié, auto-correction pour la plupart de ce qu’il signale. C’est le linter standard pour les projets dbt et doit être non négociable dans tout setup CI.

DataPilot ajoute des vérifications basées sur l’IA par-dessus : fanout élevé source/modèle, références codées en dur, sources inutilisées, longues chaînes de modèles non matérialisés. Ce sont les problèmes structurels qui s’accumulent en problèmes de maintenance s’ils ne sont pas traités.

Les hooks pre-commit sont rapides — des secondes, pas des minutes. Ils donnent aux développeurs un feedback immédiat avant que le code n’atteigne l’étape PR. La limitation est la portée : ils ne vérifient que les fichiers que vous committez, pas le contexte plus large du projet.

Si vous utilisez les hooks Claude Code, vous pouvez ajouter un hook PostToolUse qui exécute SQLFluff automatiquement après chaque modification de fichier SQL, détectant les problèmes de formatage encore plus tôt que l’étape pre-commit.

Couche 3 : Revue PR (à chaque pull request)

La revue au niveau PR est là où les problèmes inter-modèles apparaissent. CodeRabbit ou Greptile examine le changeset complet avec le contexte de la base de code. Un renommage de colonne qui casse des références en aval, un changement de filtre qui affecte des métriques utilisées par d’autres équipes — ceux-ci ne deviennent visibles que lorsque l’outil de revue peut voir au-delà des fichiers modifiés.

Exécutez dbt Project Evaluator en parallèle avec la revue IA à cette étape. L’IA détecte les problèmes de logique ; dbt Project Evaluator détecte les problèmes structurels :

Modèles sans tests
Références directes aux sources dans les modèles mart
Chaînes DAG excessivement longues
Modèles avec trop de dépendances en amont

Vous avez besoin des deux pour une couverture complète. La revue IA comprend la logique des requêtes mais n’applique pas les conventions de structure du projet. dbt Project Evaluator applique la structure mais ne peut pas évaluer si une condition de JOIN est correcte.

L’étape PR est aussi là où la revue humaine se produit. La checklist de revue humaine s’applique ici : vérifier les conditions de JOIN, les filtres temporels, la gestion des NULL, le grain d’agrégation et l’exhaustivité des filtres. La revue IA signale les candidats ; les humains prennent les décisions de jugement.

Couche 4 : dbt Cloud CI (modèles modifiés + en aval)

Dans dbt Cloud, le Slim CI avec dbt build --select state:modified+ teste uniquement les modèles modifiés et leurs dépendances en aval. Cela détecte des problèmes qu’aucune revue de code ne peut attraper : les violations au niveau des données qui ne se manifestent que lorsque la requête s’exécute réellement sur les données du warehouse.

La Taxonomie des tests dbt définit ce qui est testé à cette étape : tests génériques (unique, not_null, relationships), tests singuliers pour les règles métier complexes, tests unitaires pour la logique de transformation, et enforcement de contrat pour la stabilité du schéma.

Sur dbt Core sans dbt Cloud, un workflow GitHub Actions équivalent offre la même couverture :

- name: dbt CI
  run: |
    dbt build --select state:modified+ --defer --state ./prod-manifest

Le flag --defer indique à dbt d’utiliser les artefacts de production pour les modèles inchangés, afin de ne construire et tester que ce qui a changé. Cela maintient le CI rapide tout en conservant une couverture complète en aval.

Adapter la profondeur de revue au risque

Toutes les couches n’ont pas besoin de s’exécuter à chaque modification. L’architecture est conçue pour que l’intensité de revue s’adapte au risque du changement :

Type de changement	Couches exécutées
Tout changement de code	Feedback IDE (constant)
Chaque commit	Hooks pre-commit (SQLFluff + DataPilot)
Chaque PR	Revue IA PR + dbt Project Evaluator + revue humaine
Chaque fusion vers main	Slim CI avec tests dbt
Mensuel/trimestriel	Revue approfondie Claude Code des chemins critiques

La dernière ligne est importante. Pour les modèles mart, les données financières et tout ce qui est orienté client, une revue approfondie périodique avec Claude Code et le contexte complet de votre projet détecte les problèmes qui s’accumulent lentement — dérive des conventions, patterns obsolètes, logique métier qui ne correspond plus à l’interprétation des métriques par les parties prenantes.

Le minimum à trois couches

En pratique, trois couches couvrent la plupart du manque :

SQLFluff pour le formatage (rapide, déterministe, non négociable)
Un outil de revue IA pour les PR (CodeRabbit pour la moindre friction, Greptile pour la couverture la plus profonde)
Un assistant contextuel au niveau IDE (Claude Code avec un bon CLAUDE.md)

Les outils spécifiques importent moins que la configuration de chaque couche avec le schéma, les conventions et les règles métier de votre projet. Un Greptile non configuré vous donnera moins qu’un CodeRabbit bien configuré. Les compromis de l’ajout de plus de couches sont réels — latence CI, volume de faux positifs, feedbacks contradictoires — commencez donc avec trois et ajoutez-en seulement quand vous avez des preuves de manques.