Les scripts SQL Oracle générés par des agents de modèles de langage de grande taille (LLM) peuvent sembler parfaits sur le papier et pourtant provoquer des catastrophes en production. Dans une base de code héritée de 2,3 millions de lignes, un agent piloté par l'IA insérait régulièrement des identifiants inexistants – par exemple, en utilisant POLICY_STATUS au lieu de la véritable colonne STATUS_CD, ou en faisant référence à une table CUSTOMERS inexistante au lieu de CUSTOMER.

Exécuter le script pour détecter la faute de frappe n'est pas une option pour les instructions UPDATE ou DELETE. Leur exécution sur un jeu de données similaire à la production acquiert des verrous, consomme des numéros de séquence et peut déclencher des effets secondaires en cascade. Les développeurs ont besoin d'un moyen de valider les noms et la syntaxe sans toucher aux données. La réponse, étonnamment simple, réside dans la commande EXPLAIN PLAN d'Oracle – réutilisée comme une étape de linting.

Comment EXPLAIN PLAN fonctionne comme un validateur rapide

Lorsqu'Oracle reçoit une instruction, il l'analyse d'abord (parsing). L'analyse vérifie que chaque table, colonne et privilège référencé existe, puis construit un plan d'exécution et écrit ce plan dans une table système. La commande n'exécute jamais l'instruction : aucune ligne n'est modifiée, aucun déclencheur (trigger) ne se déclenche, aucun verrou n'est pris. Si l'analyseur rencontre un objet inconnu, il renvoie une erreur en quelques millisecondes.

Ce comportement fait d'EXPLAIN PLAN un contrôle pré-vol parfait pour le SQL généré par l'IA. Une table ou une colonne manquante est signalée instantanément, permettant à la boucle de génération de corriger l'erreur avant même qu'un humain ne voie le script.

Le workflow que j'ai intégré dans mon pipeline CI

  1. Découper le script entrant en instructions individuelles.
  2. Exécuter EXPLAIN PLAN FOR <statement> sur un schéma de développement.
  3. Collecter toutes les erreurs d'analyse renvoyées par Oracle.
  4. Renvoyer les erreurs au LLM pour une nouvelle tentative.

En pratique, une seule tentative de correction élimine la majorité des erreurs de nommage. L'IA apprend le schéma correct et ajuste sa sortie automatiquement. Je verrouille également l'agent en mode lecture seule : il peut émettre des SELECT et des appels EXPLAIN PLAN, mais le DDL, le DML et le COMMIT sont bloqués. Ce bac à sable (sandbox) garantit que la base de données reste intacte pendant que l'IA sonde sa structure.

Au-delà de la vérification des noms, le plan généré révèle des signaux d'alerte de performance évidents. Si une instruction devait déclencher un scan complet de table (full-table scan) sur une table massive, le plan le montre avant que les lignes ne soient touchées, donnant aux développeurs la possibilité de suggérer des index ou de réécrire le prédicat.

Limites de l'approche

  • La correction logique n'est pas vérifiée. Une instruction qui fait référence aux bonnes colonnes mais applique le mauvais filtre passera tout de même le linting.
  • Les blocs PL/SQL sont hors de portée. L'analyseur ne gère que les instructions SQL individuelles ; le code procédural nécessite un chemin de validation distinct.
  • La validation au niveau des données est absente. Le linting ne peut pas vous dire si une valeur littérale est conforme au domaine d'une colonne ou si une référence de clé étrangère existe réellement.
  • Schéma de dev uniquement. Les erreurs qui n'apparaissent qu'en production – par exemple, une table qui existe en dev mais qui est renommée en prod – restent invisibles jusqu'à plus tard.

Ces lacunes ne diminuent pas l'utilité de la méthode ; elles en définissent simplement le périmètre. Pour la plupart des scripts DML générés par LLM, le mode de défaillance le plus courant est une faute de frappe ou un nom d'objet erroné, et c'est précisément ce qu'EXPLAIN PLAN détecte.

Portabilité vers d'autres moteurs de base de données

Le même principe s'applique au-delà d'Oracle. L'instruction PREPARE ou EXPLAIN de PostgreSQL peut analyser une requête sans l'exécuter. SQL Server propose SET PARSEONLY ON, ce qui force le moteur à valider la syntaxe et les noms d'objets tout en sautant le traitement réel. Tout SGBDR qui sépare l'analyse de l'exécution peut devenir une passerelle de linting légère.

À retenir

Exécuter EXPLAIN PLAN (ou son équivalent) sur chaque instruction SQL générée par l'IA transforme l'analyseur d'une base de données en une passerelle de linting peu coûteuse et sans risque. Cela permet de détecter les erreurs de nommage et de syntaxe les plus fréquentes avant toute manipulation de données, maintenant la stabilité des systèmes hérités tout en permettant aux développeurs de profiter du gain de productivité du codage assisté par LLM.