Les échecs de jugement de l’IA dans le développement dbt se distinguent des échecs d’exécution SQL (incohérences de filtre temporel, mauvaises clés de jointure). Les échecs de jugement sont architecturaux : le modèle est structurellement correct mais inadapté au projet, aux données ou à la logique métier spécifique. Ils apparaissent après que le code atteint la production, quand les chiffres ne correspondent pas aux attentes.
L’équipe de Recce a documenté cette catégorie dans une étude de cas où Claude Code a construit un projet dbt entier de bout en bout — de l’ingestion Snowflake aux modèles de base, intermédiaires et marts. L’IA a suivi précisément les conventions de nommage et les patterns CTE ; les échecs se sont produits là où les conventions ne suffisent pas.
Les trois types d’échec
Mauvais type de jointure
Claude Code a choisi des inner joins là où des left joins étaient nécessaires. Le résultat : les enregistrements avec des clés étrangères nulles ont été silencieusement filtrés. Le mart semblait correct — il avait les bonnes colonnes, la bonne granularité, les bonnes agrégations. Il manquait juste des lignes. Les totaux de revenus étaient sous-estimés. Les comptages de clients étaient sous-estimés. Pas de message d’erreur, pas d’échec de test, rien pour alerter du problème à moins de savoir déjà quels devraient être les bons chiffres.
C’est le mode de défaillance le plus dangereux parce qu’il se cache lui-même. Un inner join qui filtre les lignes nulles produit un jeu de données propre et plausible. Le modèle compile. Les tests passent (à moins que vous n’ayez un test qui valide par rapport au nombre de lignes attendu). Les tableaux de bord downstream se chargent sans erreur. Les chiffres sont faux.
L’IA a choisi des inner joins parce que les inner joins sont le choix conventionnel en SQL quand vous êtes certain que les deux côtés de la jointure correspondront. Elle n’a pas demandé : dans ce métier, est-il possible qu’une commande n’ait pas de client ? Est-il possible qu’une session n’ait pas d’utilisateur associé ? La réponse à ces questions nécessite de connaître le métier — ce que les nulls signifient dans ce modèle de données spécifique — pas juste le SQL.
Reconstruction d’assets existants
La même étude de cas a révélé que Claude Code avait reconstruit une dimension date qui existait déjà dans le projet. Il a généré un modèle dim_date complet et fonctionnel — différent de l’existant dans des aspects subtils (plage de dates différente, nommage des colonnes différent, ensemble différent de champs de calendrier fiscal). Le projet avait désormais deux dimensions date.
C’est un échec de conscience du projet, pas un échec SQL. L’IA savait comment construire une dimension date. Elle ne savait pas qu’il en existait déjà une parce que l’inventaire du projet n’est pas encodé dans le schéma YAML des modèles individuels. À moins que le CLAUDE.md ne dise explicitement « la dimension date est à marts/common/dim_date — ne pas la recréer », l’agent n’a aucun moyen de savoir qu’il ne devrait pas en générer une.
La solution est une documentation explicite dans CLAUDE.md des assets partagés existants. Mais cela nécessite que le praticien anticipe quels assets risquent d’être recréés — ce qui signifie comprendre les angles morts de l’IA avant qu’ils ne causent des problèmes. Le pattern CLAUDE.md est la bonne approche ; l’effort est d’être suffisamment exhaustif pour prévenir cette classe d’erreur.
Source depuis la mauvaise couche
Le troisième échec : Claude Code a puisé depuis des modèles de base au lieu de tables intermédiaires. Techniquement correct (les données y sont), mais incorrect pour l’architecture du projet. La couche intermédiaire existe précisément pour encapsuler la logique métier — jointures, enrichissements, déduplication — afin que les marts n’aient pas à la répéter. En sourcant depuis des modèles de base, l’IA a contourné cette logique, soit en la dupliquant (si elle a eu la logique juste) soit en l’omettant (si elle n’a pas réalisé qu’elle était nécessaire).
C’est un jugement de layering. L’IA sait que les modèles de base existent et que les marts devraient sourcer depuis quelque chose en amont. Elle ne sait pas si le bon upstream est un modèle de base ou un modèle intermédiaire sans comprendre quelle logique la couche intermédiaire applique et si cette logique devrait être dans le lignage du mart.
Les Skills d’agent dbt de dbt Labs adressent cette classe d’échec dans leur couverture des conventions de couche — quand sourcer depuis la base vs. l’intermédiaire vs. la Semantic Layer. Mais même avec de bons fichiers de skill, un agent qui ne sait pas ce que font les modèles intermédiaires de votre projet spécifique ne peut pas choisir de façon fiable le bon.
Pourquoi ces échecs se produisent
Le résumé de l’équipe de Recce était précis : « L’analytics engineering assistée par l’IA n’est pas un problème de prompting. C’est un problème d’infrastructure. »
Les échecs ne viennent pas de prompts inadéquats. Ils viennent de l’IA opérant sans contexte métier qu’aucun prompt ne peut entièrement fournir. Inner joins vs. left joins est un jugement sur la nullabilité dans votre domaine métier — quelque chose que vous comprenez parce que vous savez ce qui se passe quand un client est supprimé de votre CRM ou quand une commande est passée depuis une session non enregistrée. L’IA fait un choix structurel sans la connaissance du domaine pour le faire correctement.
Cela se connecte au The Context Gap in AI Data Engineering : le fossé entre ce qui est dans les fichiers du projet et ce qui est dans la tête du praticien. Votre projet dbt contient le code. Il ne contient pas pourquoi le code a été écrit ainsi, quels événements métier produisent des nulls, ni quels modèles existants devraient être réutilisés plutôt que reconstruits.
Trois catégories de contexte qui ne vivent pas dans les fichiers du projet :
- Sémantique du domaine : Ce que les nulls signifient. Ce que « actif » signifie. Ce que le métier considère comme une commande valide vs. une commande de test.
- Inventaire du projet : Quels assets partagés existent et ne doivent pas être recréés.
- Rationale des couches : Pourquoi les modèles intermédiaires existent, quelle logique métier ils encapsulent, et quels marts devraient sourcer depuis eux.
Ce qui aide réellement
CLAUDE.md avec des interdictions explicites. « Ne pas recréer les dimensions partagées existantes. Assets existants : dim_date à marts/common/dim_date, dim_customers à marts/customers/dim_customers. » « Toujours utiliser des left joins lors de jointures avec des tables d’enrichissement ; nos données CRM ont des lacunes. » Ces instructions ne nécessitent pas que l’IA comprenne le métier — elles encodent explicitement le bon choix.
Documentation du projet sur les assets existants. Une description de modèle qui dit « Dimension date partagée. Utiliser ce modèle plutôt que de construire votre propre scaffolding de dates » donne à l’agent l’information dont il a besoin pour ne pas le recréer. La documentation peut se substituer à la compréhension métier de l’IA quand elle est suffisamment spécifique et explicite.
Revue structurelle, pas seulement syntaxique. Lors de la revue des modèles dbt générés par l’IA, vérifiez délibérément les types de jointure. Vérifiez depuis quelle couche le modèle source. Vérifiez si une logique en cours d’implémentation existe déjà dans un modèle intermédiaire. Ce ne sont pas des choses que vous devriez normalement vérifier quand vous écrivez le code vous-même — ce sont des choses à vérifier spécifiquement à cause de la façon dont l’IA prend des décisions.
Des tests qui attrapent le filtrage silencieux. Un test qui valide les comptages de lignes par rapport à une baseline connue — ou un test not_null sur une colonne qui ne devrait jamais être null mais pourrait être silencieusement filtrée par un inner join — attrape l’échec de mauvaise jointure avant qu’il n’atteigne la production. La stratégie de tests dbt par couche couvre où ajouter ces tests.
Commencer plus petit. L’étude de cas impliquait de construire un projet dbt entier de bout en bout. Cette portée amplifie les échecs de jugement — chaque mauvaise décision se compose avec les autres. Demander à l’IA de construire des modèles individuels, dans le contexte d’un projet existant où la structure de couches existe déjà et où les modèles intermédiaires sont déjà en place, lui laisse moins de marge pour faire des choix architecturaux incorrects.
Périmètre opérationnel
L’IA est fiable pour la réplication de patterns, la génération de boilerplate, les modifications multi-fichiers et le débogage itératif. Elle est peu fiable pour le jugement architectural quand elle manque de contexte métier. La division productive consiste à ce que les humains prennent les décisions architecturales — depuis quelle couche sourcer, si un asset partagé existe, quel type de jointure est correct — et à ce que l’IA implémente ces décisions. C’est plus étroit que « construis-moi un projet dbt de bout en bout », mais le travail d’implémentation (SQL de modèle, génération YAML, exécution de tests, débogage de compilation) est là où l’IA économise le plus de temps avec le moins de risque.