17Configuration ODESA

La saisie automatique

Recopie automatisée de données d'une source (base / fichier / tableur) vers un portail web ou un logiciel métier, avec validation par lot.

Besoin métier

De nombreux processus de back-office reposent sur de la « double saisie » : des données déjà présentes dans un système (base, fichier, tableur) doivent être ressaisies à la main dans un autre (portail web, logiciel métier) parce que les deux outils ne sont pas interfacés. C'est lent, répétitif et source d'erreurs sur les volumes. L'objectif est de déléguer cette recopie à l'IA, qui lit la source et remplit l'interface cible, en laissant à l'humain une validation d'ensemble avant enregistrement définitif.

Comment ça fonctionne

1

lit la source de données (base via SQL, fichier ou tableur via fichiers) ;

2

ouvre l'interface cible : portail web (navigateur réel) ou logiciel métier (COM) ;

3

remplit les formulaires / champs ligne par ligne, en suivant le mapping source → cible ;

4

isole les lignes problématiques (donnée manquante, valeur non reconnue) au lieu de bloquer ;

5

présente un récapitulatif du lot pour validation humaine avant enregistrement définitif ;

6

après validation, finalise l'enregistrement des lignes confirmées.

Capacités ODESA mobilisées

web (navigateur réel)

Ouvrir le portail, naviguer, remplir les formulaires, cliquer ; profil SSO (session déjà connectée), allowlist du portail ; sessions à état.

sql / fichiers (fs)

Lecture de la source : requête sur une base, ou lecture d'un fichier / tableur.

ui (interaction humaine)

Présentation du récapitulatif de lot ; validation avant enregistrement définitif.

com (optionnel)

Saisie dans un logiciel métier Windows piloté en COM, en alternative au portail web.

Déroulé type

1

Utilisateur : « Saisis les 120 commandes du fichier `commandes.xlsx` dans le portail fournisseur. Récapitulatif avant validation. »

2

IA (fichiers) : lit le tableur → 120 lignes, colonnes (référence, quantité, date, client).

3

IA (web) : ouvre le portail (session SSO déjà active sur l'allowlist), repère le formulaire de saisie.

4

IA (web) : pour chaque ligne, remplit les champs et passe à la suivante ; met de côté 4 lignes dont le code article est refusé par le portail.

5

IA (ui) : « 116 commandes saisies et prêtes, 4 en attente (codes article inconnus : …). Valider les 116 ? »

6

Utilisateur : « Corrige ces deux codes, écarte les deux autres, valide. »

7

IA (web) : applique les corrections, enregistre les 118 lignes confirmées.

8

IA : « 118 commandes enregistrées, 2 écartées. Récapitulatif déposé. »

Données & accès
  • Source de données : connexion SQL nommée (lecture) ou chemin du fichier/tableur à lire.
  • Mapping : correspondance entre les champs source et les champs de l'interface cible.
  • Interface cible : URL(s) du portail + profil SSO, ou ProgID du logiciel métier COM.
  • Dossier de récapitulatifs : répertoire de dépôt des comptes-rendus de saisie (optionnel).
Bornage & sécurité
  • web : allowlist limitée au strict domaine du portail cible ; profil SSO dédié ; sessions bornées.
  • sql : si la source est une base, connexion nommée en lecture seule.
  • fichiers : si la source est un fichier, racine de lecture limitée au dossier des fichiers à saisir.
  • com (si logiciel métier) : ProgID explicitement autorisé uniquement.
  • ui : validation de lot avant enregistrement définitif (recommandée, surtout en phase de mise en route).
  • Jeton Bearer exigé ; configuration chiffrable/verrouillable ; exécution locale.

Mise en place

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

1

Installer ODESA sur le poste back-office.

2

Déclarer la source (connexion SQL lecture seule, ou racine fichier).

3

Définir le mapping source → champs de l'interface cible.

4

Configurer l'accès à la cible : allowlist + profil SSO (web), ou ProgID (COM).

5

Activer la validation de lot (ui).

6

Tester sur un petit échantillon, vérifier le rendu côté cible, ajuster le mapping, puis verrouiller la configuration.

Limites & points d'attention
  • Dépendance à la stabilité de l'interface cible : point d'honnêteté majeur, si le portail ou le logiciel change de structure (champs renommés, étapes ajoutées), le remplissage peut nécessiter un ajustement. Les interfaces stables donnent les meilleurs résultats.
  • Qualité de la source : une donnée erronée à la source sera recopiée fidèlement ; la validation de lot limite le risque.
  • Volumes et performance : les très gros lots gagnent à être découpés ; la parallélisation par sessions reste bornée.
  • Cas hors cadre : les lignes non reconnues sont isolées, pas devinées ; elles restent à la décision humaine.
  • Anti-automatisation : certains portails posent des contrôles (captcha) qui limitent l'automatisation ; à vérifier au cas par cas.
Évolutions possibles
  • Planification VAILS : déclenchement automatique de la saisie à réception d'un nouveau lot.
  • Contrôles de cohérence (VScript) : validation des données avant saisie (formats, doublons).
  • Réconciliation : relecture post-saisie pour confirmer que la cible reflète la source.
  • Multi-cibles : recopie vers plusieurs systèmes dans la foulée.

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.

17ODESA configuration

Automatic data entry

Automated copying of data from a source (database / file / spreadsheet) into a web portal or business software, with batch validation.

Business need

Many back-office processes rely on "double entry": data already present in one system (database, file, spreadsheet) must be re-entered by hand into another (web portal, business software) because the two tools are not interfaced. It is slow, repetitive and error-prone on volumes. The goal is to delegate this copying to the AI, which reads the source and fills the target interface, leaving the human an overall validation before final saving.

How it works

1

reads the data source (database via SQL, file or spreadsheet via files);

2

opens the target interface: web portal (real browser) or business software (COM);

3

fills the forms / fields line by line, following the source → target mapping;

4

isolates problematic lines (missing data, unrecognised value) instead of blocking;

5

presents a batch recap for human validation before final saving;

6

after validation, finalises the saving of the confirmed lines.

ODESA capabilities used

web (real browser)

Open the portal, navigate, fill forms, click; SSO profile (already-logged-in session), portal allowlist; stateful sessions.

sql / files (fs)

Read the source: a query on a database, or reading a file / spreadsheet.

ui (human interaction)

Present the batch recap; validation before final saving.

com (optional)

Entry into a Windows business software driven via COM, as an alternative to the web portal.

Typical flow

1

User: "Enter the 120 orders from the file `orders.xlsx` into the supplier portal. Recap before validation."

2

AI (files): reads the spreadsheet → 120 lines, columns (reference, quantity, date, client).

3

AI (web): opens the portal (SSO session already active on the allowlist), locates the entry form.

4

AI (web): for each line, fills the fields and moves to the next; sets aside 4 lines whose item code is rejected by the portal.

5

AI (ui): "116 orders entered and ready, 4 pending (unknown item codes: …). Validate the 116?"

6

User: "Correct these two codes, discard the other two, validate."

7

AI (web): applies the corrections, saves the 118 confirmed lines.

8

AI: "118 orders saved, 2 discarded. Recap dropped."

Data & access
  • Data source: a named SQL connection (read) or the path of the file/spreadsheet to read.
  • Mapping: correspondence between the source fields and the target interface fields.
  • Target interface: portal URL(s) + SSO profile, or the business-software COM ProgID.
  • Recaps folder: directory to drop the entry reports (optional).
Scope & security
  • web: allowlist limited to the strict target-portal domain; dedicated SSO profile; bounded sessions.
  • sql: if the source is a database, a read-only named connection.
  • files: if the source is a file, a read root limited to the folder of files to enter.
  • com (if business software): explicitly allowed ProgID only.
  • ui: batch validation before final saving (recommended, especially during rollout).
  • Bearer token required; configuration encryptable/lockable; local execution.

Setup

The steps to configure ODESA for this use case.

1

Install ODESA on the back-office workstation.

2

Declare the source (read-only SQL connection, or file root).

3

Define the source → target-fields mapping.

4

Configure access to the target: allowlist + SSO profile (web), or ProgID (COM).

5

Enable batch validation (ui).

6

Test on a small sample, check the rendering on the target side, adjust the mapping, then lock the configuration.

Limits & caveats
  • Dependence on the target interface's stability: a major honesty point, if the portal or the software changes structure (renamed fields, added steps), filling may require adjustment. Stable interfaces give the best results.
  • Source quality: erroneous data at the source will be copied faithfully; batch validation limits the risk.
  • Volumes and performance: very large batches benefit from being split; parallelisation by sessions stays bounded.
  • Out-of-frame cases: unrecognised lines are isolated, not guessed; they stay for human decision.
  • Anti-automation: some portals add controls (captcha) that limit automation; to check case by case.
Possible extensions
  • VAILS scheduling: automatic trigger of the entry on receipt of a new batch.
  • Consistency checks (VScript): validation of the data before entry (formats, duplicates).
  • Reconciliation: post-entry re-read to confirm the target reflects the source.
  • Multi-target: copying into several systems in one go.

Put ODESA to work.

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