20Configuration ODESA

L'auditeur de conformité

Parcourir un corpus documentaire indexé pour vérifier une grille de règles et lister les écarts, en assistance au contrôle humain.

Besoin métier

Les fonctions qualité, conformité et juridique doivent régulièrement vérifier qu'un ensemble de documents respecte une grille d'exigences : présence de mentions obligatoires, de clauses, de signatures, de dates valides ou non périmées. Réalisé manuellement, ce contrôle est long, fastidieux et sujet à l'inattention sur de gros volumes. Le besoin : systématiser le repérage des écarts probables sur tout le corpus, pour orienter et accélérer le travail de l'auditeur, sans prétendre le remplacer.

Comment ça fonctionne

1

On désigne le corpus documentaire à auditer (un ou plusieurs dossiers) ; ODESA en construit ou en réutilise l'index plein-texte.

2

On définit la grille de règles en langage naturel : éléments devant être présents (clause, mention, signature, date) ou absents, et conditions associées (ex. date de révision postérieure à une échéance).

3

L'IA parcourt les documents et, pour chaque règle, recherche dans le contenu indexé la présence ou l'absence des éléments attendus.

4

Elle qualifie chaque document au regard de chaque règle (conforme / écart probable / à vérifier).

5

Elle restitue la liste des écarts : pour chaque manquement, le document concerné et la règle non satisfaite.

6

Sur demande, un rapport d'écarts est généré dans un fichier (tableau récapitulatif) déposé dans un dossier dédié.

7

Les cas incertains sont signalés comme « à vérifier » plutôt que tranchés automatiquement, pour renvoi au contrôle humain.

Capacités ODESA mobilisées

index (plein-texte)

Cœur du dispositif : rechercher dans le contenu du corpus la présence/absence des éléments requis par la grille, par pertinence, insensible casse/accents.

fichiers (fs)

Lire les documents pour préciser un cas, et écrire le rapport d'écarts dans le dossier prévu, dans les limites des racines autorisées.

interaction humaine (ui)

Confirmer le lancement de l'audit, ou signaler les cas ambigus à arbitrer ; restituer le rapport.

Déroulé type

1

L'utilisateur demande : « Vérifie toutes les procédures du dossier Qualité : chacune doit avoir une signature, une date de validation, et une date de révision postérieure à juin 2024. Liste-moi les écarts. »

2

L'IA s'assure que le corpus est indexé, puis applique chaque règle aux 58 procédures.

3

Pour la règle « signature », elle recherche les marqueurs attendus ; 4 procédures n'en présentent pas de visible.

4

Pour la règle « date de révision », elle repère 9 procédures dont la date est antérieure à juin 2024.

5

Elle restitue : « Sur 58 procédures : 4 sans signature visible (PROC-012, PROC-027, PROC-033, PROC-041), 2 sans date de validation, 9 dont la révision est antérieure à juin 2024. »

6

Elle propose : « Je génère un rapport d'écarts dans Qualité / Audits ? » et, après accord, produit le fichier récapitulatif.

7

Les cas où l'extraction est douteuse sont marqués « à vérifier » pour contrôle humain.

Données & accès
  • Le ou les dossiers constituant le corpus à auditer, accessibles en lecture.
  • La grille de règles de conformité, exprimée en langage naturel.
  • Le dossier de destination du rapport d'écarts, accessible en écriture.
  • Aucune base ni service externe requis : l'index est autonome.
Bornage & sécurité
  • Aucune capacité par défaut : seules index, fichiers et ui sont activées ; web, sql, com restent fermés.
  • Racines autorisées (jail) : ODESA ne lit que le corpus déclaré et n'écrit que le rapport dans le dossier prévu.
  • Lecture seule sur le corpus : l'audit ne modifie pas les documents source ; seul le rapport est écrit.
  • Jeton d'accès (Bearer) : tout appel à ODESA est protégé par un jeton.
  • Configuration verrouillable : règles et chemins peuvent être protégés par chiffrement / mot de passe.
  • Local : corpus, index et rapport restent sur les machines du client.

Mise en place

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

1

Installer ODESA (exécutable, double-clic, icône près de l'horloge).

2

Déclarer les racines autorisées (corpus en lecture, dossier de rapports en écriture).

3

Activer les capacités index, fichiers et ui.

4

Lancer l'indexation du corpus, puis formaliser la grille de règles avec l'utilisateur.

5

Connecter l'IA conversationnelle (jeton d'accès) et calibrer sur un échantillon de documents avant l'audit complet.

Limites & points d'attention
  • Aide à l'audit, pas substitution : l'IA repère des écarts probables ; la qualification d'un manquement et la décision finale restent humaines.
  • La qualité du contrôle dépend de l'extraction du texte : un PDF scanné non océrisé ou une image ne livrent pas de contenu vérifiable.
  • La détection d'éléments comme une signature manuscrite repose sur la présence de marqueurs textuels ; une signature purement graphique peut échapper à la vérification (cas « à vérifier »).
  • Des règles formulées de façon ambiguë génèrent des faux positifs ou des faux négatifs : la grille doit être précise.
  • Le résultat est un point de départ d'audit à valider, non un certificat de conformité.
Évolutions possibles
  • Océrisation préalable des documents scannés pour élargir le périmètre vérifiable.
  • Modèles de grilles réutilisables par type de corpus (contrats, factures, dossiers RGPD).
  • Rapport d'écarts enrichi (extrait justificatif, lien vers le passage du document).
  • Suivi des corrections : nouvel audit comparatif après reprise des écarts.
  • Planification via VAILS d'audits périodiques et d'alertes sur les dates de péremption approchant.

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.

20ODESA configuration

The compliance auditor

Go through an indexed document corpus to check a checklist of rules and list the gaps, in support of human control.

Business need

The quality, compliance and legal functions must regularly check that a set of documents meets a checklist of requirements: presence of mandatory mentions, clauses, signatures, valid or non-expired dates. Done manually, this control is long, tedious and prone to inattention on large volumes. The need: systematise the spotting of probable gaps across the whole corpus, to guide and speed up the auditor's work, without claiming to replace it.

How it works

1

You designate the document corpus to audit (one or more folders); ODESA builds or reuses its full-text index.

2

You define the checklist of rules in plain language: elements that must be present (clause, mention, signature, date) or absent, and associated conditions (e.g. a revision date after a deadline).

3

The AI goes through the documents and, for each rule, searches the indexed content for the presence or absence of the expected elements.

4

It qualifies each document against each rule (compliant / probable gap / to check).

5

It returns the list of gaps: for each breach, the document concerned and the rule not met.

6

On request, a gap report is generated in a file (summary table) dropped in a dedicated folder.

7

Uncertain cases are flagged as "to check" rather than decided automatically, for referral to human control.

ODESA capabilities used

Full-text index

Core of the setup: search the corpus content for the presence/absence of the elements required by the checklist, by relevance, case/accent-insensitive.

Files (fs)

Read the documents to clarify a case, and write the gap report in the intended folder, within the allowed roots.

Human interaction (ui)

Confirm the launch of the audit, or flag the ambiguous cases to arbitrate; return the report.

Typical flow

1

The user asks: "Check all the procedures in the Quality folder: each must have a signature, a validation date, and a revision date after June 2024. List me the gaps."

2

The AI ensures the corpus is indexed, then applies each rule to the 58 procedures.

3

For the "signature" rule, it searches for the expected markers; 4 procedures show none visible.

4

For the "revision date" rule, it spots 9 procedures whose date is before June 2024.

5

It returns: "Out of 58 procedures: 4 without a visible signature (PROC-012, PROC-027, PROC-033, PROC-041), 2 without a validation date, 9 whose revision is before June 2024."

6

It offers: "Shall I generate a gap report in Quality / Audits?" and, after agreement, produces the summary file.

7

Cases where extraction is doubtful are marked "to check" for human control.

Data & access
  • The folder(s) making up the corpus to audit, accessible for reading.
  • The compliance checklist of rules, expressed in plain language.
  • The destination folder for the gap report, writable.
  • No database or external service required: the index is self-contained.
Scope & security
  • No capability by default: only index, files and ui are enabled; web, sql, com stay closed.
  • Allowed roots (jail): ODESA only reads the declared corpus and only writes the report in the intended folder.
  • Read-only on the corpus: the audit does not modify the source documents; only the report is written.
  • Access token (Bearer): every call to ODESA is protected by a token.
  • Lockable configuration: rules and paths can be protected by encryption / password.
  • Local: corpus, index and report stay on the customer's machines.

Setup

The steps to configure ODESA for this use case.

1

Install ODESA (executable, double-click, icon near the clock).

2

Declare the allowed roots (corpus for reading, reports folder for writing).

3

Enable the index, files and ui capabilities.

4

Run the corpus indexing, then formalise the checklist of rules with the user.

5

Connect the conversational AI (access token) and calibrate on a sample of documents before the full audit.

Limits & caveats
  • Audit aid, not substitution: the AI spots probable gaps; the qualification of a breach and the final decision stay human.
  • Control quality depends on text extraction: a non-OCR'd scanned PDF or an image yields no checkable content.
  • Detecting elements like a handwritten signature relies on the presence of textual markers; a purely graphic signature may escape the check ("to check" case).
  • Ambiguously phrased rules generate false positives or false negatives: the checklist must be precise.
  • The result is an audit starting point to validate, not a compliance certificate.
Possible extensions
  • Prior OCR of scanned documents to widen the checkable perimeter.
  • Reusable checklist templates by corpus type (contracts, invoices, GDPR files).
  • Enriched gap report (supporting excerpt, link to the document passage).
  • Tracking of fixes: a new comparative audit after the gaps are addressed.
  • VAILS scheduling of periodic audits and alerts on approaching expiry dates.

Put ODESA to work.

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