97 % du SQL incorrect généré par l’IA s’exécute sans avertissement d’exécution (étude ErrorLLM). La requête compile, s’exécute et produit un résultat qui semble plausible. C’est différent de la plupart des bugs logiciels : une fonction cassée dans du code applicatif échoue visiblement, tandis qu’une requête SQL cassée retourne des résultats qui nécessitent une connaissance du domaine pour être identifiés comme incorrects. La boucle de feedback qui attrape les bugs est rompue.
Le problème des filtres temporels
Thomson Reuters Labs a documenté à quoi ressemble ce mode de défaillance en production. Leur agent IA a généré du SQL de taux de conversion qui a gonflé les résultats d’environ 40 %. La cause racine : l’agent a appliqué des filtres temporels à une table mais pas à la table des conversions jointe. Quand ils ont audité l’ensemble de leur pipeline, 73 % des analyses temporelles avaient des filtres temporels incohérents.
73 % des requêtes temporelles dans le pipeline de Thomson Reuters présentaient la même classe d’erreur — des filtres appliqués à certaines tables d’une jointure mais pas à d’autres.
Le pattern est prévisible. Quand vous écrivez WHERE events.event_date BETWEEN '2025-01-01' AND '2025-03-31' sans contraindre la table des conversions jointe à la même fenêtre, vous obtenez des conversions de toute la période mises en correspondance avec un trimestre d’événements. Le taux de conversion semble excellent. La finance adore les chiffres. Et ils sont faux.
Les filtres temporels sont difficiles pour l’IA parce qu’ils nécessitent de comprendre la relation entre les tables, pas seulement la syntaxe de chaque requête. L’IA voit une colonne de date, applique un filtre et passe à autre chose. Elle ne raisonne pas sur le fait que la table jointe a également besoin de bornes temporelles. C’est une compréhension architecturale — comment le temps est modélisé dans l’entrepôt — que le LLM ne possède pas.
Cela se connecte directement aux décisions d’architecture de l’entrepôt de données. Quelles tables utilisent le temps d’événement vs. le temps de traitement ? Comment les modèles incrémentiels gèrent-ils les frontières temporelles ? Quand les données en retard sont intégrées, quelles requêtes downstream doivent tenir compte du décalage ? Une mauvaise modélisation du temps au niveau de l’architecture signifie que chaque requête générée par l’IA hérite de la confusion.
Le problème des jointures
Thomson Reuters a trouvé un autre pattern d’échec : 78 % des erreurs SQL se produisaient quand l’agent joignait des tables sans identifier correctement les relations de clé primaire. L’IA voit deux tables avec une colonne customer_id et les joint. Elle ne demande pas si une table a une ligne par client et l’autre une ligne par commande. Elle ne vérifie pas les NULL dans la clé de jointure. Elle ne considère pas si la jointure devrait être LEFT ou INNER selon la question métier.
Tiger Data a corroboré cela depuis un angle différent : 42 % des requêtes générées par LLM sans contexte manquaient des filtres critiques ou comprenaient mal les relations entre tables. Le qualificatif « sans contexte » est important — ce sont des requêtes générées sans métadonnées sémantiques sur ce que les tables et colonnes signifient réellement.
Quand Tiger Data a ajouté des catalogues sémantiques — des descriptions générées par LLM de ce que les tables et colonnes représentent réellement — la précision s’est améliorée de 27 %. La solution n’était pas un meilleur modèle. La solution était plus de contexte. C’est pourquoi la documentation alimentée par l’IA importe même si vous pensez que « personne ne lit la documentation ». De meilleures descriptions alimentent de meilleurs outputs IA en aval, même quand le consommateur est une autre IA.
Le problème de confiance
Les chercheurs d’ErrorLLM ont mis en lumière quelque chose d’arguably pire que les requêtes incorrectes. Quand on demande aux LLM de corriger une requête SQL qui est déjà correcte, ils s’exécutent quand même. Ils modifient du code fonctionnel en code cassé. Ils ne disent pas « cette requête est correcte ». Ils trouvent quelque chose à changer, et ce changement introduit un bug.
Ce problème de confiance se compose à travers les requêtes complexes. Les hallucinations dans les premières sous-requêtes se propagent aux résultats finaux. Un CTE incorrect au début d’une requête produit des résultats intermédiaires incorrects, qui alimentent des CTE downstream, qui produisent un résultat final incorrect d’une manière presque impossible à tracer sans comprendre ce qu’aurait dû être le résultat correct.
L’IA est confiemment dans l’erreur, ce qui est pire qu’incertaine et dans l’erreur. Un système incertain invite la revue humaine. Un système confiant la contourne.
Ce qui aide réellement
La recherche pointe de façon cohérente dans une direction : la solution est le contexte, pas la capacité du modèle.
Les catalogues sémantiques améliorent la précision en donnant à l’IA des informations sur ce que les données signifient, pas seulement ce à quoi elles ressemblent. L’amélioration de 27 % de Tiger Data provenait de descriptions de tables et de colonnes — le type de métadonnées que l’infrastructure de tests et de documentation de dbt est conçue pour capturer.
Les fichiers d’instructions structurés réduisent les inadéquations de conventions. La plus grande source d’erreurs de Claude Code était les conventions mal assorties — utiliser stg_ quand le projet utilise base__, par exemple. Un CLAUDE.md bien maintenu résout entièrement cette classe d’erreur.
La revue humaine des outputs IA reste non négociable, notamment pour les jointures et la logique temporelle. La constatation de Thomson Reuters n’est pas que l’IA ne peut pas écrire du SQL. C’est que l’IA ne peut pas vérifier du SQL. L’étape de vérification — cette jointure a-t-elle du sens ? les filtres temporels sont-ils cohérents ? la granularité correspond-elle aux attentes ? — nécessite quelqu’un qui sait ce que les données signifient.
Les tests attrapent ce que la revue manque. La taxonomie des tests dbt fournit cinq mécanismes pour valider les données et la logique. Les tests génériques attrapent les violations structurelles (doublons, NULL, intégrité référentielle). Les tests unitaires valident la logique de transformation. Les tests dbt-expectations attrapent les violations de plage de valeurs. Aucun de ces éléments n’a été conçu spécifiquement pour le code généré par l’IA, mais ils constituent exactement le filet de sécurité nécessaire quand le code a été écrit par un système qui ne peut pas raisonner sur la correction.
Ce sont les comportements par défaut quand l’IA opère sans contexte suffisant sur ce que les données signifient. L’adoption de l’IA en analytics engineering a progressé de 33 % à 70 % en deux ans, augmentant le volume de SQL généré par l’IA dans les pipelines de production.