Comment requêter DynamoDB avec l'IA (langage naturel)

« Montre-moi les commandes échouées de la semaine dernière » tient en une ligne dans ta tête et devient une KeyConditionExpression avec des maps de placeholders sur le réseau. Combler cet écart, c'est ce que « requêter DynamoDB avec l'IA » signifie réellement — parce que l'API DynamoDB elle-même n'a aucun endpoint en langage naturel. Chaque requête reste des expressions ou du PartiQL ; l'IA se place dans la couche outillage, traduisant ton intention vers eux.

Cette traduction peut être authentiquement excellente ou discrètement dangereuse, selon une seule chose : si le modèle peut voir ton vrai schéma ou non. Ce guide couvre les trois configurations qui fonctionnent et où chacune casse.

Comment requêter DynamoDB en langage naturel ?

Trois vraies options : demander à un LLM généraliste de rédiger du PartiQL et l'exécuter toi-même (rapide, mais le modèle devine tes noms d'attributs), connecter un agent IA à DynamoDB via un serveur MCP pour qu'il puisse inspecter et requêter pour de vrai, ou utiliser un client DynamoDB avec un assistant intégré conscient du schéma — le chat IA de DynoTable transforme le langage naturel en PartiQL ou en SQL contre ton schéma réellement indexé, calcule des agrégats exacts sur toute la table, et met chaque écriture en attente pour ta revue.

Option 1 : du PartiQL rédigé par LLM, exécuté par toi

La version zéro-installation : décris la requête à n'importe quel modèle capable, récupère du PartiQL, exécute-le dans l'éditeur PartiQL de la console ou via la CLI :

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

Ça marche — et ça échoue de trois façons prévisibles :

• Le modèle ne peut pas voir ta table. Il inventera avec assurance des noms d'attributs et des formes de clés (orderId quand la tienne est PK = ORDER#<id>). Tu finis par déboguer un schéma halluciné au lieu d'écrire la requête.
• Les limites de PartiQL s'appliquent toujours. Un SELECT lit exactement une table, et un WHERE qui ne fixe pas une clé devient un scan de table entière — silencieusement coûteux, exactement comme si tu l'avais écrit toi-même. Le modèle te prévient rarement ; PartiQL vs SQL explique ce que la surface SQL apporte et n'apporte pas.
• Coller un schéma ou des données dans un chatbot est une décision de gouvernance des données. Des items d'exemple dans un prompt, ce sont des données de production qui quittent ton périmètre.

Bon pour des requêtes ponctuelles sur un schéma que tu peux coller de mémoire ; bancal comme workflow.

Option 2 : un agent IA connecté via MCP

Le correctif structurel à « le modèle ne peut pas voir ta table » est de donner à l'agent des outils plutôt qu'un schéma collé dans le prompt. Le Model Context Protocol (MCP) fait exactement ça : un serveur MCP expose les opérations DynamoDB comme des outils typés, et n'importe quel agent compatible MCP (Claude, les assistants d'IDE, des agents personnalisés) peut lister les tables, inspecter les clés et exécuter des requêtes, avec de vrais résultats qui alimentent la conversation.

Nous couvrons l'installation complète — et les questions de consentement, de périmètre et de sécurité d'écriture qui viennent avec le fait de laisser un agent toucher une base de données — dans Utiliser DynamoDB avec un serveur MCP. DynoTable en embarque un : il peut exposer des outils contrôlés, en loopback uniquement, à des agents externes, avec consentement et scopes par connexion.

C'est la bonne architecture quand l'agent est le produit — un bot de support, un assistant Slack interne. Pour le travail interactif au quotidien, elle te laisse quand même assembler toi-même agent, serveur et identifiants.

Option 3 : un assistant conscient du schéma dans ton client DynamoDB

L'assistant intégré de DynoTable est la version intégrée : il vit à côté de tes tables (⌘;), et il lit ton schéma indexé — les tables sous le profil actif, leurs clés et index, les chemins d'attributs et types découverts par l'indexation de table, même des valeurs d'exemple — pour que « filtre ça sur la semaine dernière » se résolve contre tes vrais noms d'attributs, pas une supposition. Tape @ pour référencer explicitement une @table, une @column ou un @gsi.

Ce qu'il fait d'une question, d'après le catalogue de capacités :

• Il écrit la requête pour toi — du PartiQL en lecture seule, ou du SQL Workbench quand la question a besoin de JOIN / GROUP BY / d'agrégats (l'analytique que l'API de DynamoDB n'a pas) — et propose le résultat comme un chip que tu cliques pour l'ouvrir en vrai onglet.
• Il calcule des réponses exactes sur toute la table. Demande un comptage, une somme, une moyenne ou une ventilation par groupe et il lit chaque item correspondant, pas une page échantillonnée — « combien de commandes le mois dernier ? » reflète la table réelle. Il peut remodeler la même passe en un fichier d'export transformé.
• Il met chaque écriture en attente. Demande-lui de corriger une ligne et le changement atterrit dans la zone de mise en attente comme un diff révisable — l'assistant ne peut pas écrire directement dans DynamoDB, supprimer une table par lots, ni modifier la structure d'une table, quel que soit le mode de permission. Tu revois, tu valides.
• Il demande avant de dépenser ton argent. Les lectures qui touchent AWS et coûtent de la capacité sont contrôlées par permission (Manual / Auto / Full Auto, par profil), et chaque décision contrôlée atterrit dans un journal d'audit local, toujours actif.

Le modèle de confiance compte autant que les fonctionnalités : l'assistant tourne sur tes propres identifiants AWS Bedrock, en parlant directement à Bedrock dans ton compte — les prompts, le schéma et les données de table ne transitent jamais par les serveurs de DynoTable, et l'inférence t'est facturée aux tarifs propres de Bedrock, sans marge. Les résultats d'outils sont traités comme des données non fiables, donc une ligne contenant « ignore previous instructions » ne peut pas détourner l'agent.

Ce que l'IA ne change PAS à DynamoDB

Toute couche IA honnête hérite de la physique de la base de données :

• Les modes d'accès gouvernent toujours. « Where status = X » sur un attribut non-clé est un scan filtré peu importe qui l'écrit — le modèle tape juste la requête coûteuse plus vite. Si une question force sans cesse des scans, le correctif est de la modélisation (un GSI, une meilleure clé de tri), pas un meilleur prompt.
• Les lectures coûtent de la vraie capacité. Un agrégat exact sur toute la table est une lecture de toute la table. Les bons outils le contrôlent et le disent ; le calculateur de prix te dit ce que coûte une passe complète avant que tu l'approuves.
• Le déterminisme a sa place. Pour une requête que tu exécuteras pour toujours en production, construis l'expression une fois à la main dans l'Expression Builder et livre les maps exactes de noms/valeurs — l'IA sert à l'exploration, le builder au code que tu commites.

FAQ

Puis-je requêter DynamoDB en langage courant ? Pas contre l'API elle-même — DynamoDB ne parle que les expressions et PartiQL. Mais une couche IA peut traduire : un LLM qui rédige du PartiQL, un agent connecté via MCP, ou un assistant conscient du schéma comme celui de DynoTable qui génère et exécute la requête contre ton vrai schéma.

DynamoDB a-t-il une fonction de requête IA intégrée ? L'API DynamoDB n'a pas d'endpoint en langage naturel. Tout le requêtage IA que tu obtiens vient de la couche outillage au-dessus — c'est pourquoi le modèle de sécurité de cet outillage (lectures contrôlées, écritures mises en attente, tes propres identifiants) est la chose à évaluer.

Est-il sûr de laisser l'IA près de données de production ? C'est une question de permissions. Cherche : des lectures contrôlées par une approbation explicite, des écritures qui atterrissent dans une zone de mise en attente révisable au lieu de s'exécuter directement, un journal d'audit, et de l'inférence sur des identifiants que tu contrôles. L'assistant de DynoTable remplit les quatre ; un chatbot avec tes données collées n'en remplit aucun.

L'IA peut-elle joindre des tables ou faire du GROUP BY ? Pas via l'API DynamoDB — aucun moteur n'existe pour ça. L'assistant de DynoTable répond à ces questions via son SQL Workbench en lecture seule (de vrais JOIN, GROUP BY et agrégats dans le respect des règles de mode d'accès de DynamoDB), qui est aussi là où atterrissent les questions de count/sum/average.

Combien ça coûte ? Deux compteurs : la capacité de lecture DynamoDB pour ce que touchent les requêtes (l'assistant demande avant les lectures contrôlées), et l'inférence Bedrock facturée sur ton propre compte AWS — DynoTable n'ajoute aucune marge et ne fait transiter aucune donnée.

Pose ta prochaine question en langage naturel — télécharge DynoTable, pointe l'IA sur ton propre Bedrock, et garde chaque écriture derrière une revue.