L’IA agentique au service du développement des bases de données : qu’est-ce qui change lorsque l’IA peut réellement exécuter des requêtes ?

Depuis quelques années, le développement de bases de données assisté par l’IA repose sur un modèle plutôt confortable. Un développeur décrit un besoin. L’IA génère du SQL. Le développeur le relit, corrige ce qui lui semble erroné et décide s’il faut l’exécuter.

Ce processus a préservé une frontière importante : l’IA peut suggérer une action, mais c’est toujours un humain qui décide si elle sera appliquée à la base de données.

Toutefois, avec l’IA agentique, cette frontière commence à s’estomper. Aujourd’hui, les systèmes d’IA peuvent examiner des schémas, exécuter des requêtes, interpréter les résultats et décider de l’action à entreprendre ensuite. Selon une enquête récente, 62 % des organisations expérimentent déjà avec des agents d’IA, tandis que 23 % ont déclaré avoir déployé à grande échelle un système agentique dans leur entreprise.

Les équipes chargées des bases de données doivent donc rapidement répondre à une question d’architecture. La question n’est pas de savoir si l’IA peut exécuter du SQL. Elle le peut. La vraie question est de savoir ce qui change lorsqu’un assistant cesse de suggérer du code et commence à intervenir sur la base de données, et dans quelle mesure cette autonomie doit être encadrée.

Des suggestions aux actions

Une simple décision d’indexation montre pourquoi ce changement est important.

Un agent repère une requête lente, consulte le schéma, comprend qu’un index pourrait être utile, le crée, relance la charge de travail et vérifie le résultat.

Il pourrait exécuter une instruction aussi courante que :

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Cette instruction n’a rien d’inhabituel. Un assistant d’IA aurait pu suggérer exactement la même chose. La différence tient à la personne qui prend la décision finale.

Avec un assistant, le développeur examine la recommandation, la teste et décide s’il faut l’exécuter. L’IA conseille, mais c’est l’humain qui agit. Avec un agent disposant des droits d’exécution, le système peut prendre lui-même cette décision et poursuivre sans attendre d’approbation.

Si cette décision est bonne, le processus s’accélère. Mais les agents n’ont pas toujours une vue d’ensemble. Ils peuvent ne pas tenir compte des dépendances de l’application, des règles métier, des profils de charge, des fenêtres de maintenance ou d’autres éléments évidents pour les personnes qui exploitent le système.

Un agent peut donc prendre une décision qui semble techniquement raisonnable tout en étant inadaptée à l’environnement dans lequel il intervient, compte tenu des contraintes et des exigences qui lui sont propres.

Le risque augmente à mesure que les actions commencent à s’enchaîner. Une mauvaise SELECT peut simplement s’exécuter lentement. Une mauvaise UPDATE peut verrouiller une très grande table ou toucher beaucoup plus de lignes que prévu. Un index utilisé pour une requête peut être superflu tout en alourdissant l’exécution d’autres requêtes. Une modification du schéma peut casser un élément dont l’agent ignorait la dépendance, parce qu’il ne dispose peut-être pas de tout le contexte opérationnel et ne peut pas tester tous les cas d’utilisation possibles.

Le problème n’est donc pas que les agents soient incapables de prendre de bonnes décisions concernant les bases de données. Ils en sont souvent capables. Le problème, c’est que dès lors qu’ils sont autorisés à mettre ces décisions à exécution, les équipes doivent définir beaucoup plus clairement l’étendue de cette autorité, le contexte auquel l’agent peut accéder, les situations où un humain doit encore intervenir et la personne qui reste responsable du résultat.

Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici à la fin de 2027, en partie à cause de contrôles des risques insuffisants. Pour les équipes chargées des bases de données, la leçon est assez simple : les droits d’exécution doivent être accordés après la mise en place des contrôles, et non avant.

Que peut-on déléguer sans risque ?

Certaines tâches liées aux bases de données peuvent être confiées bien plus facilement que d’autres.

L’analyse des requêtes en est un bon exemple. Un agent peut examiner les statistiques des requêtes, récupérer les plans d’exécution, vérifier les index et les structures des tables, puis suggérer des corrections probables sans modifier les données de production.

Il peut repérer une requête qui parcourt à plusieurs reprises une grande Orders table :

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

À partir de là, il peut expliquer le parcours, suggérer un index et générer le DDL. Il n’a pas besoin d’autorisation pour exécuter CREATE INDEX pour être utile.

Il en va de même pour des tâches telles que :

• Décrire les plans d’exécution ;
• Repérer les index manquants ou superflus ;
• Signaler les SELECT * requêtes ou les prédicats non sargables ;
• Examiner la poussée des jointures et des filtres ;
• Examiner les dépendances et les schémas ;
• Résoudre les erreurs SQL ;
• Optimiser les scripts SQL.

La distinction pratique est simple : donner à l’agent suffisamment d’accès pour comprendre le problème, sans pour autant lui accorder automatiquement les droits nécessaires pour modifier la base de données. Une large visibilité peut être utile, mais accorder de vastes droits d’exécution est une tout autre décision.

Là où le contrôle humain reste essentiel

Certaines décisions concernant les bases de données nécessitent encore l’intervention d’un humain. Supposons qu’un agent trouve une AuditLog table contenant des centaines de millions de lignes et décide de supprimer les anciens enregistrements :

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

Le SQL peut être parfaitement valide et la décision, tout de même, catastrophique.

La réglementation exige peut-être une conservation pendant sept ans. Une application dépend peut-être de ces enregistrements. Il est peut-être préférable de procéder à la suppression par lots pour éviter que les journaux de transactions ne prennent trop de volume. Les enregistrements doivent peut-être être archivés avant leur suppression.

Aucune de ces exigences n’est nécessairement définie dans le schéma.

C’est l’une des limites d’une approche qui consiste à considérer le travail sur les bases de données comme un problème de génération de code. Les bases de données comportent des structures techniques, mais les décisions qui les concernent relèvent souvent de choix métier exprimés au moyen d’opérations techniques. La même prudence s’impose pour des opérations telles que :

• DROP et destructrices ALTER instructions ;
• en production UPDATE et DELETE opérations ;
• les migrations de données volumineuses ;
• les modifications des rôles et des autorisations ;
• les modifications des contraintes ;
• les changements qui affectent la réplication ou la disponibilité ;
• le déploiement de procédures stockées contenant de la logique métier.

Une action techniquement correcte n’est pas nécessairement appropriée. L’approbation humaine ne devrait donc pas être considérée comme une contrainte gênante pour l’IA agentique. Pour les opérations de base de données à fort impact, elle fait partie intégrante de l’architecture.

Les agents d’IA ont eux aussi besoin du principe du moindre privilège

Les équipes chargées des bases de données devraient éviter un raccourci : laisser un agent utiliser les identifiants existants d’un développeur. C’est facile, mais l’agent bénéficie alors de tous les accès dont dispose déjà ce développeur.

L’approche la plus sûre est la même que pour les utilisateurs et les services : appliquer le principe du moindre privilège. Microsoft recommande de n’accorder que les autorisations nécessaires à la tâche et de surveiller les activités privilégiées.

Un agent d’analyse des performances pourrait, par exemple, avoir besoin de :

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Il n’a probablement pas besoin de :

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Les agents peuvent aussi avoir des identités différentes. Un agent de reporting pourrait avoir SELECT accès à quelques schémas. Un agent de migration pourrait travailler uniquement dans les environnements de développement ou de préproduction. Un agent de production pourrait recevoir des autorisations strictement limitées, tout en devant obtenir une approbation avant de pouvoir exécuter une opération.

L’OWASP recommande la même approche de base pour les agents d’IA : séparer les accès en lecture et en écriture, limiter les outils et les ressources, et exiger une autorisation explicite pour les actions sensibles.

La règle est simple : accordez à l’agent les autorisations nécessaires à sa tâche, et non celles de la personne qui l’a lancé.

Intégrer l’humain au processus

Pour le travail agentique sur les bases de données, une meilleure approche consiste à mettre en place un processus contrôlé :

Observer → Analyser → Proposer → Examiner → Exécuter → Valider → Consigner

Imaginons qu’un agent enquête sur un point de terminaison d’API lent. Il trouve la requête SQL qui le sous-tend, examine le plan d’exécution et les statistiques des tables, repère un index probablement manquant et prépare un script de migration.

Ce script peut d’abord être exécuté en préproduction. L’agent relance la charge de travail, vérifie le résultat et prépare la modification à appliquer en production.

Il s’arrête alors.

Un développeur ou un administrateur de base de données examine la migration, vérifie les dépendances et les répercussions métier, puis l’approuve avant toute mise en production.

L’agent peut tout de même prendre en charge une grande partie des tâches répétitives. La responsabilité finale d’une modification à fort impact reste du ressort de l’humain.

Les mécanismes de contrôle des transactions peuvent offrir un niveau de sécurité supplémentaire. Dans PostgreSQL, par exemple, les points de sauvegarde permettent d’annuler une partie d’une transaction sans effacer tout ce qui a été effectué auparavant. Cela peut être utile pour des modifications automatisées étroitement liées, mais l’annulation ne remplace ni des autorisations adéquates ni une approbation.

C’est aussi dans ce contexte que des outils comme dbForge AI Assistant trouvent naturellement leur place. En s’appuyant sur le contexte du schéma, il peut générer et expliquer du SQL, diagnostiquer des erreurs, comparer des DDL, repérer des index inefficaces et préparer des scripts d’optimisation, tout en laissant le SQL obtenu à la vue des développeurs pour qu’ils puissent l’examiner.

L’objectif est d’automatiser les tâches courantes tout en laissant les décisions importantes aux humains.

Le véritable objectif : une autonomie maîtrisée

L’IA agentique n’oblige pas à choisir entre « l’IA se contente de suggérer » et « l’IA gère la base de données ». Les possibilités intermédiaires sont nombreuses.

Les équipes peuvent commencer par des tâches à faible risque, comme expliquer du SQL, examiner des schémas et effectuer des contrôles en lecture seule. Ensuite, elles peuvent progressivement confier davantage de tâches aux agents dans les environnements de développement et de préproduction.

Les droits d’écriture ne devraient être accordés que bien plus tard, avec des limites claires concernant les lignes concernées, les transactions, les annulations, la surveillance et les approbations. Les modifications entièrement autonomes en production devraient être rares.

Cette approche rejoint également les recommandations de Deloitte : commencer par des processus à faible risque et des données non critiques, tenir les équipes informées et renforcer la gouvernance à mesure que les agents gagnent en autonomie.

Le but n’est pas l’autonomie absolue. Il s’agit de donner à l’agent assez de latitude pour être utile, mais pas davantage d’accès que nécessaire.

À retenir : le développement de bases de données nécessite toujours du discernement

Les agents d’IA peuvent décharger les équipes d’ingénierie des bases de données d’une grande partie des tâches répétitives. Ils peuvent observer les charges de travail, examiner les requêtes, mettre en corrélation les schémas, les plans, les erreurs et les données de performance, puis agir en conséquence.

Mais dès qu’un système d’IA peut modifier l’état de la base de données, le problème change. Les équipes ont besoin de règles claires concernant l’identité, les autorisations, les limites des transactions, les approbations, l’observabilité, la restauration et les pistes d’audit.

C’est pourquoi, parmi les 88 % d’organisations qui utilisaient l’IA en 2025, seulement 7 % ont déclaré qu’elle avait été déployée à grande échelle dans l’ensemble de l’organisation. Le plus difficile est de rendre l’IA suffisamment fiable pour qu’elle puisse fonctionner à grande échelle.

Le développement de bases de données suit la même évolution. L’agent le plus utile ne sera pas celui auquel on permet de faire le plus de choses, mais celui dont les pouvoirs sont clairement définis et contrôlés.

La question n’est plus de savoir si l’IA peut exécuter des tâches liées aux bases de données, mais quelles tâches nous pouvons lui confier et sous quelles contraintes.