Requêtes de base de données en langage naturel avec OpenClaw

Les utilisateurs professionnels ont besoin de données. Les administrateurs de bases de données écrivent des requêtes. Cet écart – entre la personne qui sait quelle question poser et la personne qui sait comment récupérer la réponse – coûte énormément de temps aux organisations et concentre les goulots d'étranglement analytiques chez les personnes possédant des connaissances en SQL.

La requête de base de données en langage naturel (également appelée texte vers SQL ou NL vers SQL) comble cette lacune. La capacité de requête NL d'OpenClaw permet aux utilisateurs professionnels de poser des questions dans un anglais simple et de recevoir des réponses précises de leurs bases de données sans connaissances SQL, sans informations d'identification d'accès à la base de données ou sans attendre un développeur.

Il ne s’agit pas de la simple expérience de chatbot sur CSV qu’offrent de nombreux outils. Il s'agit d'un texte vers SQL de qualité production capable de gérer des requêtes multi-tables complexes, des calculs agrégés, des expressions de plage de dates et la traduction de la terminologie commerciale.

Points clés à retenir

• Les utilisateurs professionnels peuvent interroger les bases de données de production en utilisant un anglais simple sans connaissances SQL.
• OpenClaw traduit le langage naturel en SQL paramétré - jamais de saisie utilisateur brute en SQL (sécurisé par injection)
• La compréhension des schémas via la couche sémantique mappe la terminologie commerciale aux champs de bases de données techniques
• Les requêtes complexes comprenant les jointures, les agrégations, les CTE et les fonctions de fenêtre sont prises en charge
• Les résultats sont renvoyés dans un format convivial avec contexte et visualisations
• Le contrôle d'accès garantit que les utilisateurs interrogent uniquement les données qu'ils sont autorisés à voir
• La mise en cache des requêtes réduit la charge de la base de données et le temps de réponse aux questions courantes
• L'intégration avec Odoo, PostgreSQL, MySQL, SQL Server, BigQuery et Snowflake est native

---

Le problème de traduction du langage naturel vers SQL

Traduire le langage naturel en SQL est trompeusement difficile. L'apparente simplicité — « posez simplement une question, obtenez une réponse » — cache plusieurs problèmes difficiles qui déterminent si l'implémentation est utilisable en production ou s'il s'agit d'une démonstration frustrante.

Problème 1 : Cartographie terminologique. Les utilisateurs professionnels disent « revenu » – mais s'agit-il du champ invoice_total, du champ order_amount ou du champ payment_received ? « Clients » peut désigner la table accounts, la table contacts ou une vue qui joint les deux. Sans une couche sémantique qui mappe la terminologie commerciale au schéma technique, le LLM doit deviner – et il se trompe souvent.

Problème 2 : complexité du schéma. Les bases de données d'entreprise contiennent des centaines ou des milliers de tables. Une question sur les « performances des ventes par région ce trimestre » peut nécessiter de joindre 6 à 8 tableaux. Le LLM a besoin de suffisamment de contexte de schéma pour générer la jointure correcte, mais l'envoi du schéma complet à chaque invite est inefficace et coûteux.

Problème 3 : Résolution d'ambiguïté. « Montrez-moi les meilleurs clients » – en tête de quelle métrique ? Quelle période ? Y a-t-il un seuil pour « sommet » ? Les systèmes de requête en langage naturel qui ne gèrent pas l'ambiguïté supposent (et se trompent souvent) ou demandent des éclaircissements (ce que les utilisateurs trouvent frustrants).

Problème 4 : Vérification de l'exactitude. Vous ne pouvez pas simplement croire que le SQL généré est correct. Il a besoin d'une validation — validation syntaxique (va-t-il fonctionner ?), validation sémantique (répond-il à la question souhaitée ?) et validation des résultats (les résultats semblent-ils plausibles ?).

Problème 5 : Sécurité. L'entrée en langage naturel ne peut pas être transmise directement à la base de données. Le SQL généré doit être paramétré, validé et contrôlé par accès avant l'exécution. Sinon, un utilisateur demandant « montrez-moi les ventes où nom = '; DROP TABLE sales;' » pourrait causer de réels dommages.

L'architecture de requête NL d'OpenClaw résout les cinq problèmes.

---

Architecture : comment fonctionnent les requêtes OpenClaw NL

Couche sémantique

La couche sémantique est le fondement des requêtes NL de qualité production. Il s'agit d'une définition structurée de vos concepts métier que l'agent utilise pour traduire le langage utilisateur en objets de base de données.

Composants de la couche sémantique :

Définitions du concept commercial : "Revenu" = SUM(invoice_lines.unit_price * invoice_lines.quantity) WHERE invoice.state = 'posted'. "Clients actifs" = accounts WHERE account_type = 'customer' AND last_transaction_date > NOW() - INTERVAL '12 months'.

Alias ​​terminologiques : Associez plusieurs termes au même concept. « Revenus », « ventes », « chiffre d'affaires », « revenus » correspondent tous au calcul des revenus. « Client », « client », « compte », « acheteur » sont tous mappés au tableau des comptes.

Définitions des relations : Documentez les relations entre les tables et quelles jointures sont correctes pour quelles questions. « Produits vendus à un client » nécessite un chemin de jointure spécifique à travers les commandes et les lignes de commande — documentez-le une fois dans la couche sémantique.

Définitions de métriques : prédéfinissez des métriques calculées (marge brute %, coût d'acquisition client, jours de vente en suspens) avec leurs formules précises. Les utilisateurs peuvent demander ces métriques par leur nom.

Définitions de contrôle d'accès : définissez quels rôles d'utilisateur peuvent accéder à quels tableaux, colonnes et sous-ensembles de lignes. Un responsable commercial régional peut interroger uniquement les données de sa région.

Pipeline de génération de requêtes

Lorsqu'un utilisateur soumet une question en langage naturel, OpenClaw la traite via un pipeline en plusieurs étapes :

Étape 1 — Classification des intentions : Classez le type de question (recherche, agrégation, analyse des tendances, comparaison, classement) et identifiez les principales entités impliquées.

Étape 2 — Extraction d'entités : Identifiez les entités commerciales mentionnées dans la question (produits, clients, périodes, zones géographiques) et mappez-les aux concepts de couche sémantique.

Étape 3 — Détection d'ambiguïté : Identifiez les termes ambigus et résolvez-les en utilisant le contexte (tours de conversation précédents, profil utilisateur) ou générez une question de clarification.

Étape 4 — Sélection du schéma : Sélectionnez le sous-ensemble pertinent du schéma de base de données nécessaire pour répondre à la question. Cela évite de surcharger le contexte LLM avec un schéma non pertinent.

Étape 5 — Génération SQL : Générez du SQL à l'aide des entités résolues, des mappages de couche sémantique et du schéma sélectionné. La sortie est paramétrée en SQL, jamais d'interpolation de chaîne.

Étape 6 — Validation : Validez syntaxiquement le SQL généré. Validez sémantiquement qu’il répond à la question. Vérifiez les estimations du nombre de lignes pour détecter les requêtes susceptibles de renvoyer des résultats inattendus.

Étape 7 — Application du contrôle d'accès : Vérifiez que l'utilisateur interrogeant dispose d'un accès en lecture à toutes les tables et colonnes référencées. Ajoutez automatiquement des filtres de sécurité au niveau des lignes en fonction du profil d'accès de l'utilisateur.

Étape 8 — Exécution et formatage des résultats : Exécutez la requête validée. Formatez les résultats pour une lisibilité professionnelle : noms de colonnes lisibles par l'homme, formatage approprié des nombres, formatage de la date et contexte de la signification des chiffres.

Étape 9 — Réponse en langage naturel : Générez un résumé en langage naturel des résultats. « Votre chiffre d'affaires au premier trimestre s'est élevé à 4,2 millions de dollars, en hausse de 23 % par rapport au premier trimestre de l'année dernière. La croissance a été principalement tirée par le segment Entreprise (+41 %).

---

Complexité des requêtes prise en charge

La capacité de requête NL d'OpenClaw gère l'ensemble du spectre de complexité SQL :

Recherches simples : - « Quel est le prix actuel du produit SKU-1234 ? »

• "Montrez-moi les coordonnées d'Acme Corp"

Agrégations :

• "Quel était le chiffre d'affaires total par catégorie de produits au dernier trimestre ?"
• "Combien de nouveaux clients avons-nous acquis chaque mois cette année ?"

Jointures multi-tables :

• "Quels clients ont acheté le produit A mais pas le produit B au cours des 6 derniers mois ?"
• "Montrez-moi toutes les factures ouvertes dont la limite de crédit du client est inférieure au montant de la facture"

Analyse des séries chronologiques :

• "Montrez-moi les revenus mensuels des 24 derniers mois avec une moyenne mobile sur 3 mois"
• "Comparez les performances commerciales par commercial entre le premier trimestre 2024 et le premier trimestre 2025"

Classements et requêtes top-N :

• "Montrez-moi les 20 meilleurs clients par valeur à vie"
• "Quels 10 produits ont les taux de retour les plus élevés ?"

Analyse de cohorte :

• "Pour les clients acquis au 1er trimestre 2024, quel pourcentage sont encore actifs aujourd'hui ?"
• "Quelle est la valeur moyenne à vie d'un client acquis via différents canaux ?"

Questions commerciales complexes : - « Quels clients courent un risque de désabonnement en raison de la baisse de la fréquence des commandes ? »

• "Quelles combinaisons de produits sont fréquemment achetées ensemble ?"

---

Expérience utilisateur professionnelle

L’expérience utilisateur professionnel est volontairement simple. Les utilisateurs interagissent via une interface de chat ou un widget de requête intégré dans leurs outils existants.

Interface de conversation :

Utilisateur : "Montrez-moi les revenus par vendeur ce trimestre par rapport à leur quota"

Agent : « Voici le quota atteint par le vendeur pour le premier trimestre 2026 :

Sarah et Maria sont sur la bonne voie. James a 128 500 $ de retard sur son quota alors qu'il reste 3 semaines. Souhaitez-vous voir le pipeline de James pour évaluer s'il peut combler l'écart ? »

Questions de suivi : Les utilisateurs peuvent poser des questions de suivi en contexte. « Quels accords James a-t-il dans la phase finale ? » — l'agent comprend que « James » fait référence à James Wilson de la conversation précédente.

Explication : Les utilisateurs peuvent demander « pourquoi ? » ou "comment avez-vous calculé cela?" et l'agent explique le calcul et affiche les données sous-jacentes.

Visualisation : Pour les données de tendance, l'agent génère un graphique à côté du tableau. Les utilisateurs peuvent demander des types de graphiques spécifiques : « montrez-moi ceci sous forme de graphique à barres » ou « tracé cela au fil du temps ».

---

Architecture de sécurité

La sécurité n'est pas négociable pour tout système accédant aux bases de données de production. Modèle de sécurité des requêtes NL d'OpenClaw :

Connexions en lecture seule : La connexion de requête dispose d'autorisations de base de données en lecture seule. Il est structurellement impossible pour l'agent de modifier les données via l'interface de requête NL.

Requêtes paramétrées : Tout le SQL généré par l'agent est paramétré : les valeurs fournies par l'utilisateur ne sont jamais concaténées dans des chaînes SQL. Cela élimine le risque d’injection SQL au niveau de l’architecture.

Sécurité au niveau des lignes : Les politiques d'accès sont appliquées au moment de la génération de la requête. Un responsable commercial régional obtient automatiquement WHERE region = 'North' ajouté à toutes les requêtes. Un agent du service client ne peut voir que les comptes qui lui sont attribués.

Contrôle d'accès au niveau des colonnes : Les colonnes sensibles (informations sur les salaires, SSN, données de carte de paiement) sont exclues du schéma interrogeable pour les rôles sans accès approprié.

Validation des requêtes : Avant l'exécution, chaque requête générée passe par une étape de validation de sécurité qui vérifie : les références de table non autorisées, les tentatives d'accès aux colonnes restreintes, les modèles de requête suspects et les limites de complexité des requêtes (empêchant les requêtes d'épuisement accidentel ou intentionnel des ressources).

Journalisation d'audit : Chaque requête, qui l'a posée, quand et quelles données ont été renvoyées, est enregistrée. Cela prend en charge les rapports de conformité et la détection des menaces internes.

---

Intégration avec les systèmes d'entreprise

Odoo ERP : OpenClaw est profondément intégré au modèle de données d'Odoo. La terminologie commerciale correspond automatiquement au schéma d'Odoo : « commandes client », « factures fournisseurs », « commandes de fabrication », « mouvements de stock » sont tous résolus correctement dans les tables Odoo appropriées.

PostgreSQL et MySQL : Connexion directe avec introspection complète du schéma. La couche sémantique est configurée lors de la mise en œuvre pour mapper la terminologie métier au schéma spécifique.

Bases de données analytiques : Snowflake, BigQuery, Redshift et Databricks sont pris en charge pour les organisations qui centralisent les données analytiques dans un entrepôt de données. Ces environnements gèrent des requêtes analytiques complexes (agrégations à grande échelle, analyse de tendances historiques) inadaptées aux bases de données de production.

SQL Server et Oracle : Pris en charge pour les organisations exécutant des plateformes de données Microsoft ou Oracle.

Bases de données multiples : L'agent peut fédérer des requêtes sur plusieurs bases de données — répondre à des questions qui nécessitent de combiner les données du CRM (Salesforce) et de l'ERP (Odoo) sans nécessiter d'entrepôt de données.

---

Implémentation : Construire la couche sémantique

La couche sémantique est l'artefact d'implémentation le plus important pour la qualité des requêtes NL. ECOSIRE construit la couche sémantique à travers un processus structuré :

Semaine 1-2 : Découverte

• Interviewer les utilisateurs professionnels pour collecter les questions courantes
• Auditer le schéma de la base de données avec le personnel technique
• Identifier les conflits et ambiguïtés terminologiques
• Prioriser les 50 questions commerciales les plus courantes

Semaine 2 à 4 : Construction de la couche sémantique

• Définir les cartographies de concepts métiers
• Rédiger des définitions métriques avec des formules précises
• Documenter les relations de jointure
• Configurer les politiques de contrôle d'accès

Semaine 4 à 6 : Tests et étalonnage

• Testez les 50 questions prioritaires par rapport à la couche sémantique
• Identifier les inadéquations et affiner la couche sémantique
• Étendre les tests à 200 questions couvrant les cas extrêmes
• Ajuster les seuils de confiance pour les questions de clarification

Semaine 6 à 8 : Tests d'acceptation des utilisateurs

• Déployer sur un groupe d'utilisateurs pilote
• Recueillir des commentaires sur l'exactitude du traitement des questions
• Ajouter la terminologie des requêtes des utilisateurs réels à la couche sémantique
• Mesurer le taux d'exactitude des réponses aux questions

---

Questions fréquemment posées

Quelle est la précision de la traduction du langage naturel vers SQL en pratique ?

Pour les questions relevant de la portée de la couche sémantique configurée, la précision atteint généralement 88 à 95 % pour les questions commerciales standard. La précision est moindre pour les questions analytiques multi-étapes très complexes et pour les questions sur les domaines de schéma non couverts par la couche sémantique. La précision s'améliore au cours des 2-3 premiers mois, à mesure que de vraies questions d'utilisateurs sont utilisées pour affiner la couche sémantique.

L'agent peut-il générer du code SQL pouvant être exécuté directement par un développeur ?

Oui. L'agent peut éventuellement exposer le code SQL généré aux utilisateurs qui souhaitent le voir, le copier ou le modifier eux-mêmes. Ceci est particulièrement utile pour les analystes de données qui souhaitent partir d’une requête générée et la personnaliser davantage. L'interface affiche le langage naturel, le SQL généré et les résultats ensemble.

Que se passe-t-il lorsque l'agent ne comprend pas une question ou que la question est ambiguë ?

L'agent pose une question de clarification plutôt que de deviner. Par exemple : « Lorsque vous dites « revenu », voulez-vous dire les revenus facturés (y compris les factures impayées) ou les revenus encaissés (paiements reçus) ? » Les questions de clarification sont réduites au minimum : l'agent résout automatiquement les cas sans ambiguïté et ne demande que lorsque la distinction affecte réellement la réponse.

Comment traiter les questions auxquelles il serait trop gourmand en ressources pour répondre en temps réel ?

L'agent estime le coût de la requête avant son exécution. Les questions qui analyseraient des tables volumineuses ou effectueraient des opérations coûteuses sont soit redirigées vers la base de données analytique (si disponible), planifiées en tant que tâches en arrière-plan avec des résultats fournis de manière asynchrone, ou présentées à l'utilisateur avec un avertissement concernant le temps d'exécution et une confirmation requise.

Les utilisateurs professionnels non techniques peuvent-ils créer des rapports à l'aide de cette fonctionnalité ?

Oui. L'interface de requête NL peut exporter les résultats vers Excel, générer des rapports statiques et créer des requêtes enregistrées qui s'actualisent selon un calendrier. Les utilisateurs professionnels peuvent créer des rapports personnels à partir de requêtes en langage naturel sans l'aide d'un développeur. Les requêtes enregistrées peuvent être partagées avec d'autres utilisateurs, créant ainsi progressivement une bibliothèque de requêtes courantes auxquelles l'équipe peut référencer.

Quelles bases de données ne sont pas prises en charge ?

Les bases de données propriétaires ou fermées sans interfaces SQL standard (certaines bases de données NoSQL, magasins de données personnalisés) peuvent nécessiter un développement supplémentaire pour l'intégration. Les bases de données de documents (MongoDB) et les magasins de valeurs-clés (Redis) nécessitent des approches différentes de celles des bases de données relationnelles. Pour ces cas, ECOSIRE conçoit une intégration personnalisée qui traduit le langage de requête approprié plutôt que SQL.

---

Prochaines étapes

Les requêtes de bases de données en langage naturel éliminent l'un des goulots d'étranglement les plus persistants dans l'analyse commerciale : l'écart entre les personnes qui ont des questions et celles qui peuvent rédiger des requêtes. La capacité de requête NL d'OpenClaw, correctement implémentée avec une couche sémantique solide, donne à chaque utilisateur professionnel un accès direct à ses données.

Explorez les compétences personnalisées d'OpenClaw pour en savoir plus sur la capacité de requête NL et d'autres options de compétences personnalisées, ou planifiez une évaluation de base de données pour voir comment OpenClaw correspondrait à votre schéma de données spécifique et à vos questions commerciales.