04Configuration ODESA

L'interrogateur de votre logiciel métier

Interroger en langage naturel la base de données d'un logiciel métier (ERP, GPAO, GMAO, gestion commerciale), en lecture seule, sans passer par ses écrans.

Besoin métier

La plupart des logiciels métier reposent sur une base de données relationnelle (SQLite, PostgreSQL ou SQL Server) qui concentre l'ensemble de l'activité : commandes, stocks, production, interventions, tiers, factures. Extraire une réponse de cette base passe aujourd'hui par les écrans du logiciel, parfois rigides, et toujours dépendants d'une bonne connaissance de l'outil.

Le besoin : permettre à un dirigeant ou à un opérationnel de poser une question métier en français et d'obtenir une réponse fondée sur les données réelles, sans manipuler le logiciel ni exporter manuellement.

Comment ça fonctionne

Capacités ODESA mobilisées

sql (centrale)

Interroger la base du logiciel métier via une connexion nommée, en lecture seule (query). Résultats en lignes/colonnes.

fichiers (fs)

Optionnel : déposer un export (CSV) des résultats dans un dossier autorisé.

interaction humaine (ui)

Optionnel : confirmer une requête lourde avant exécution.

VScript

Optionnel : encapsuler des questions récurrentes en fonctions métier réutilisables.

Déroulé type

1

L'utilisateur : « Combien de commandes clients sont encore ouvertes, et pour quel montant total ? »

2

L'utilisateur : « Lesquelles sont en retard par rapport à la date promise ? »

3

L'utilisateur : « Donne-moi les cinq clients les plus concernés par ces retards. »

4

L'utilisateur : « Parmi ces commandes en retard, lesquelles portent sur des articles qu'on a en stock ? »

5

L'utilisateur : « Exporte-moi la liste complète dans un fichier. »

Données & accès
  • Base à interroger : la base de données du logiciel métier (SQLite, PostgreSQL ou SQL Server). Pour SQL Server, le pilote est en pur Python (mssql), sans installation de pilote système.
  • Identifiants : un compte de connexion en lecture seule dédié, déclaré comme connexion nommée dans la configuration ODESA.
  • Cartographie du schéma : un document (ou un contexte fourni à l'IA) décrivant les tables et colonnes utiles et leur signification métier.
  • Dossier d'export (optionnel) : une racine autorisée pour déposer les fichiers de résultats.
Bornage & sécurité
  • Une connexion nommée unique vers la base métier, avec un compte en lecture seule côté base de données (le droit d'écriture est retiré au niveau du SGBD lui-même, pas seulement côté ODESA).
  • La capacité sql limitée à la lecture (query) ; pas d'écriture (exec) ni de transaction activées pour ce profil.
  • Un jeton Bearer exigé pour tout appel.
  • Une racine de fichiers restreinte au seul dossier d'export, si l'export est utilisé.
  • Configuration chiffrable et verrouillable ; l'ensemble tourne en local, la base ne sort pas de l'infrastructure du client.

Mise en place

Les étapes pour configurer ODESA sur ce cas d'usage.

1

Installer ODESA en local (exécutable unique) sur le poste ou le serveur ayant accès à la base.

2

Créer un compte de connexion lecture seule sur la base du logiciel métier.

3

Déclarer la connexion nommée dans la configuration ODESA et activer la capacité sql en lecture.

4

Cartographier les tables et colonnes utiles, et fournir cette cartographie comme contexte à l'IA.

5

Définir le jeton Bearer et, le cas échéant, la racine d'export.

6

Tester avec quelques questions métier représentatives, ajuster la cartographie.

Limites & points d'attention
  • Connaissance du schéma indispensable : sans cartographie correcte, l'IA peut mal interpréter une table ou une colonne. C'est l'étape clé du projet.
  • Lecture seule conseillée : l'écriture directe dans la base d'un logiciel métier est risquée (intégrité, déclencheurs, règles applicatives) et doit rester l'exception, validée avec l'éditeur.
  • Réticence possible de l'éditeur : certains éditeurs n'aiment pas qu'on accède directement à leur base. Vérifier les conditions de support et de licence.
  • Données sensibles : le périmètre de lecture doit exclure ce qui n'a pas à être exposé (données personnelles, salaires…).
  • Performance : sur de très grosses bases, certaines questions agrégées peuvent être lourdes ; prévoir des index ou des questions bornées.
Évolutions possibles
  • Encapsuler les questions récurrentes en fonctions VScript (« mes commandes en retard », « mon CA du mois »).
  • Brancher un export automatique (CSV/Excel) ou un envoi de rapport.
  • Ajouter une planification VAILS pour produire chaque matin une synthèse (voir le cas « Le rapport du matin »).
  • Étendre à plusieurs bases (commercial + production + maintenance) avec autant de connexions nommées.
  • Combiner avec l'index plein-texte pour relier des documents (devis, fiches) aux enregistrements de la base.

Mettez ODESA au travail.

ODESA installe l'IA agentique chez vos clients, en local et sous contrôle. Devenez le partenaire qui la déploie.

04ODESA configuration

The business-software interrogator

Query a business software's database (ERP, MRP, CMMS, sales management) in plain language, read-only, without going through its screens.

Business need

Most business software relies on a relational database (SQLite, PostgreSQL or SQL Server) that concentrates the whole activity: orders, stock, production, jobs, parties, invoices. Getting an answer out of this database today means going through the software's screens, sometimes rigid, and always dependent on a good knowledge of the tool.

The need: let a manager or an operational user ask a business question in plain language and get an answer grounded in the real data, without operating the software or exporting manually.

How it works

ODESA capabilities used

sql (core)

Query the business-software database via a named connection, read-only (query). Results as rows/columns.

Files (fs)

Optional: drop a CSV export of the results in an allowed folder.

Human interaction (ui)

Optional: confirm a heavy query before execution.

VScript

Optional: encapsulate recurring questions as reusable business functions.

Typical flow

1

User: "How many customer orders are still open, and for what total amount?"

2

User: "Which ones are late against the promised date?"

3

User: "Give me the five customers most affected by these delays."

4

User: "Among these late orders, which involve items we have in stock?"

5

User: "Export the full list to a file."

Data & access
  • Database to query: the business software's database (SQLite, PostgreSQL or SQL Server). For SQL Server, the driver is pure Python (mssql), with no system driver to install.
  • Credentials: a dedicated read-only connection account, declared as a named connection in the ODESA configuration.
  • Schema mapping: a document (or context provided to the AI) describing the useful tables and columns and their business meaning.
  • Export folder (optional): an allowed root to drop result files.
Scope & security
  • A single named connection to the business database, with a read-only account on the database side (write rights are removed at the DBMS level itself, not just within ODESA).
  • The sql capability limited to reading (query); no write (exec) or transactions enabled for this profile.
  • A Bearer token required for any call.
  • A file root restricted to the export folder only, if export is used.
  • Configuration encryptable and lockable; everything runs locally, the database does not leave the customer's infrastructure.

Setup

The steps to configure ODESA for this use case.

1

Install ODESA locally (single executable) on the workstation or server with access to the database.

2

Create a read-only connection account on the business-software database.

3

Declare the named connection in the ODESA configuration and enable the sql read capability.

4

Map the useful tables and columns, and provide this mapping as context to the AI.

5

Set the Bearer token and, if applicable, the export root.

6

Test with a few representative business questions, adjust the mapping.

Limits & caveats
  • Schema knowledge is essential: without a correct mapping, the AI may misinterpret a table or column. This is the key step of the project.
  • Read-only advised: writing directly into a business software's database is risky (integrity, triggers, application rules) and should remain the exception, validated with the vendor.
  • Possible vendor reluctance: some vendors dislike direct access to their database. Check the support and licence terms.
  • Sensitive data: the read perimeter must exclude what should not be exposed (personal data, salaries…).
  • Performance: on very large databases, some aggregated questions can be heavy; provide indexes or bounded questions.
Possible extensions
  • Encapsulate recurring questions as VScript functions ("my late orders", "my month's revenue").
  • Wire an automatic export (CSV/Excel) or a report send-out.
  • Add VAILS scheduling to produce a morning summary every day (see the "Morning report" case).
  • Extend to several databases (sales + production + maintenance) with as many named connections.
  • Combine with the full-text index to link documents (quotes, sheets) to database records.

Put ODESA to work.

ODESA brings agentic AI to your clients, locally and under control. Become the partner who deploys it.