03Configuration ODESA

Le chasseur de tarifs d'assurance

Piloter un vrai navigateur pour remplir les formulaires de tarification des assureurs (extranets courtier ou sites publics), récupérer les tarifs et les présenter comparés.

Besoin métier

Comparer des offres d'assurance impose de saisir les mêmes informations de risque sur plusieurs extranets ou sites assureurs, puis de relever et recopier chaque tarif. L'opération est répétitive, chronophage et source d'erreurs, et elle limite le nombre d'assureurs réellement consultés.

Le besoin : automatiser la saisie sur les formulaires de tarification, récupérer les tarifs de plusieurs assureurs, idéalement en parallèle, et restituer un comparatif fiable et tracé.

Comment ça fonctionne

Capacités ODESA mobilisées

navigateur réel (web) (centrale)

Piloter Chrome/Edge, utiliser les profils SSO des extranets, ouvrir des sessions parallèles, remplir les formulaires et lire les tarifs ; navigation bornée par une allowlist.

fichiers (fs)

Consigner les tarifs et le comparatif dans un fichier (CSV/Excel) d'un dossier autorisé.

bases de données (sql)

Optionnel : enregistrer les tarifs dans une base de suivi (historique des cotations).

interaction humaine (ui)

Confirmer avant de soumettre une demande, ou demander une saisie manuelle (ex. captcha).

VScript

Optionnel : encapsuler la procédure de tarification d'un assureur donné.

Déroulé type

1

L'utilisateur : « Tarife une flotte de 8 utilitaires, garanties tous risques, conducteur sans sinistre, chez nos cinq assureurs partenaires. »

2

L'IA : (ouvre cinq sessions, connectées en SSO aux extranets autorisés) remplit chaque formulaire avec les informations du risque.

3

L'IA (point de contrôle) : « L'assureur B demande une vérification (captcha). Pouvez-vous la valider ? »

4

L'IA : (lit les primes proposées) « Voici les cinq tarifs : A 2 140 €, B 1 980 €, C 2 310 €, D 2 050 €, E 2 200 €. Écart de 17 % entre le moins et le plus cher. »

5

L'utilisateur : « Ajoute la garantie bris de glace et relance A et C. »

6

L'utilisateur : « Consigne le comparatif dans le dossier client. »

Données & accès
  • Profils navigateur : un profil Chrome/Edge par assureur, avec la session SSO établie sur l'extranet courtier.
  • Allowlist d'URLs : la liste des domaines assureurs autorisés (extranets et/ou sites de tarification).
  • Modèle de saisie : la correspondance entre les informations du risque et les champs de chaque formulaire (peut varier d'un assureur à l'autre).
  • Dossier de sortie : une racine autorisée pour déposer les comparatifs.
  • Base de suivi (optionnel) : connexion nommée pour historiser les cotations.
Bornage & sécurité
  • Capacité web activée avec une allowlist stricte : seuls les domaines assureurs autorisés sont accessibles.
  • Profils SSO dédiés, isolés ; les identifiants restent dans les profils navigateur locaux.
  • Confirmation humaine (ui) requise avant toute soumission engageante et pour traiter les captchas.
  • Si écriture en base : connexion nommée dédiée au suivi des cotations.
  • Racine de fichiers restreinte au dossier des comparatifs.
  • Jeton Bearer exigé ; configuration chiffrable/verrouillable ; exécution en local, identifiants et données client ne sortent pas.

Mise en place

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

1

Installer ODESA en local sur le poste du courtier (accès aux extranets).

2

Préparer un profil navigateur par assureur, connecté en SSO à son extranet.

3

Activer la capacité web et définir l'allowlist des domaines assureurs.

4

Établir, pour chaque assureur, la correspondance risque → champs du formulaire.

5

Définir la racine de sortie ; si historisation, déclarer la connexion nommée.

6

Activer les confirmations (ui) pour les soumissions et captchas ; poser le jeton Bearer.

7

Tester un assureur, puis étendre aux autres et au mode parallèle.

Limites & points d'attention
  • Les sites changent : une refonte de formulaire peut casser la procédure ; prévoir une maintenance régulière des correspondances de champs.
  • Captchas et anti-bot : certains sites bloquent l'automatisation ; la confirmation humaine permet de franchir ces étapes au cas par cas, sans garantie.
  • Conformité contractuelle : vérifier que l'automatisation est compatible avec les accords assureurs et les conditions d'usage des extranets ; certaines compagnies l'interdisent.
  • Fiabilité de lecture : valider que les tarifs lus correspondent bien aux garanties saisies.
  • Sessions SSO : les expirations de session ou changements de mot de passe nécessitent une re-authentification du profil.
  • Données client : encadrer leur saisie et leur conservation conformément au RGPD.
Évolutions possibles
  • Bibliothèque de fonctions VScript, une par assureur, pour fiabiliser et maintenir chaque procédure.
  • Historique des cotations en base pour analyser l'évolution des tarifs dans le temps.
  • Pré-remplissage depuis la fiche client (lecture d'une base ou d'un fichier) pour éviter toute ressaisie.
  • Comparatif mis en forme (Word/Excel via COM) prêt à remettre au client.
  • Tarification planifiée (renouvellements) via VAILS, sous réserve des accords assureurs.

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.

03ODESA configuration

The insurance-rate hunter

Drive a real browser to fill in insurers' rating forms (broker extranets or public sites), retrieve the quotes and present them compared.

Business need

Comparing insurance offers requires entering the same risk information on several extranets or insurer sites, then reading and copying each quote. The operation is repetitive, time-consuming and error-prone, and it limits the number of insurers actually consulted.

The need: automate the entry on rating forms, retrieve the quotes from several insurers, ideally in parallel, and produce a reliable, traced comparison.

How it works

ODESA capabilities used

Real browser (web) (core)

Drive Chrome/Edge, use the extranets' SSO profiles, open parallel sessions, fill in forms and read quotes; navigation bounded by an allowlist.

Files (fs)

Log the quotes and comparison in a file (CSV/Excel) in an allowed folder.

Databases (sql)

Optional: record the quotes in a tracking database (quote history).

Human interaction (ui)

Confirm before submitting a request, or ask for manual input (e.g. captcha).

VScript

Optional: encapsulate a given insurer's rating procedure.

Typical flow

1

User: "Rate a fleet of 8 vans, comprehensive cover, claim-free driver, with our five partner insurers."

2

AI: (opens five sessions, logged in via SSO to the authorised extranets) fills each form with the risk information.

3

AI (checkpoint): "Insurer B requires a verification (captcha). Can you validate it?"

4

AI: (reads the proposed premiums) "Here are the five quotes: A €2,140, B €1,980, C €2,310, D €2,050, E €2,200. A 17% gap between the lowest and the highest."

5

User: "Add glass-breakage cover and re-run A and C."

6

User: "Log the comparison in the client file."

Data & access
  • Browser profiles: one Chrome/Edge profile per insurer, with the SSO session established on the broker extranet.
  • URL allowlist: the list of authorised insurer domains (extranets and/or rating sites).
  • Entry mapping: the correspondence between the risk information and each form's fields (may vary from one insurer to another).
  • Output folder: an allowed root to drop the comparisons.
  • Tracking database (optional): a named connection to historise the quotes.
Scope & security
  • web capability enabled with a strict allowlist: only the authorised insurer domains are reachable.
  • Dedicated, isolated SSO profiles; credentials stay in the local browser profiles.
  • Human confirmation (ui) required before any binding submission and to handle captchas.
  • If writing to a database: a dedicated named connection for quote tracking.
  • File root restricted to the comparisons folder.
  • Bearer token required; configuration encryptable/lockable; execution local, credentials and client data do not leave.

Setup

The steps to configure ODESA for this use case.

1

Install ODESA locally on the broker's workstation (extranet access).

2

Prepare a browser profile per insurer, logged in via SSO to its extranet.

3

Enable the web capability and define the insurer-domain allowlist.

4

Establish, for each insurer, the risk → form-field mapping.

5

Define the output root; if historising, declare the named connection.

6

Enable confirmations (ui) for submissions and captchas; set the Bearer token.

7

Test one insurer, then extend to the others and to parallel mode.

Limits & caveats
  • Sites change: a form redesign can break the procedure; plan regular maintenance of the field mappings.
  • Captchas and anti-bot: some sites block automation; human confirmation lets you clear these steps case by case, with no guarantee.
  • Contractual compliance: check that automation is compatible with the insurer agreements and the extranet terms of use; some companies forbid it.
  • Reading reliability: validate that the quotes read truly match the cover entered.
  • SSO sessions: session expiry or password changes require re-authenticating the profile.
  • Client data: govern its entry and retention in line with GDPR.
Possible extensions
  • A library of VScript functions, one per insurer, to make each procedure robust and maintainable.
  • Quote history in a database to analyse rate trends over time.
  • Pre-filling from the client record (reading a database or file) to avoid any re-entry.
  • A formatted comparison (Word/Excel via COM) ready to hand to the client.
  • Scheduled rating (renewals) via VAILS, subject to the insurer agreements.

Put ODESA to work.

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