Retour aux projets

RWA / COMPLIANCE · DOCUMENT INTELLIGENCE

Plateforme IA d’analyse réglementaire RWA

Pipeline backend d’analyse automatisée de whitepapers, intégré à l’application ARIA et orienté conformité dans le cadre VARA. La chaîne associe préparation documentaire, OCR, orchestration multi-agents, contrôles qualité, publication API et traçabilité des traitements.

  • Python
  • OCR
  • LLM
  • OpenAI
  • Gemini
  • Docker
  • API REST
Voir le dépôt public
Période
2025
Type
Pipeline IA · conformité réglementaire
Rôle
Conception & développement du pipeline IA
Contexte
Application ARIA · cadre VARA

VUE D’ENSEMBLE

Comprendre le projet

Contexte

L’application ARIA doit analyser des whitepapers liés aux actifs tokenisés selon un framework réglementaire structuré. Les documents arrivent sous plusieurs formats et les preuves retenues doivent rester précisément traçables.

Objectif

Transformer automatiquement un document soumis en analyse structurée : critères, flags, citations exactes, numéros de page, consolidation des preuves et synthèse exécutive, puis publier ces résultats.

Notre rôle

Concevoir et développer le pipeline Python V4 : récupération API, préparation documentaire et OCR, orchestration de trois agents IA, retry/failover, contrôles qualité, monitoring et publication API.

Résultat

Un worker conteneurisé capable de prendre en charge automatiquement un rapport, de produire et contrôler l’analyse, de publier les résultats et de conserver les artefacts utiles à l’audit.

ARCHITECTURE

Du whitepaper à l’analyse publiée

Le schéma distingue le contexte applicatif ARIA du périmètre effectivement réalisé : orchestration, préparation documentaire, agents IA, publication, monitoring et services LLM externes.

Vue système du pipeline RWA V4. Les interfaces web, le backend applicatif et la base de données sont représentés pour le contexte, mais ne font pas partie du périmètre de réalisation présenté.

REPÈRES TECHNIQUES

Les éléments structurants

3 pipelines documentaires DOCX, PDF vectoriel et PDF raster avec OCR.
3 agents IA Analyse, déduplication puis synthèse exécutive.
2 providers LLM OpenAI + Gemini avec retry et failover configurables.
Citations paginées Preuves exactes rattachées aux pages du document source.

DÉTAILS TECHNIQUES

Architecture et mise en œuvre

Cette partie présente le périmètre technique du worker : ingestion, orchestration IA, contrôles de qualité, traçabilité et intégration avec l’application.

DOCUMENT · INGESTION

Préparation documentaire & OCR

  • Récupération des rapports via API et téléchargement du whitepaper.
  • Trois chaînes : DOC/DOCX, PDF vectoriel et PDF raster.
  • Conversion DOCX vers PDF avec LibreOffice.
  • Rendu des PDF raster à 300 dpi puis OCR Tesseract.
  • Pagination avec marqueurs --- PAGE N --- pour tracer les citations.

AI · ORCHESTRATION

Analyse et consolidation multi-agents

  • Découpage du whitepaper en chunks d’environ deux pages.
  • Agent 1 : analyse du framework et extraction de citations verbatim.
  • Agrégation multi-chunks et contrôles de cohérence.
  • Agent 2 : suppression des redondances par framework_id.
  • Agent 3 : synthèse exécutive complémentaire et non bloquante.
  • Retry et failover OpenAI / Gemini configurables selon les étapes.

QUALITY · TRACEABILITY

Contrôles, audit & robustesse

  • Format JSON strict attendu des agents et redressement des structures incomplètes.
  • Contrôle de l’alignement entre flags, pages, extraits et sorties.
  • Validation des citations et des sous-points avant publication.
  • Conservation des chunks, JSON intermédiaires, payloads, audits et logs.
  • Monitoring du provider, du modèle utilisé, des statuts et artefacts.
  • Verrou anti-concurrence pour empêcher le double lancement CRON.

APPLICATION · INTÉGRATION

API, statuts & publication

  • Interaction avec le backend ARIA via API HTTP authentifiée.
  • Cycle PENDING → PROCESSING → COMPLETED / ERROR.
  • Publication des résultats détaillés par framework_id.
  • Publication séparée de la synthèse Agent 3.
  • Dockerisation du worker et utilisation de volumes partagés.
  • Interfaces Admin/Utilisateur et base applicative hors périmètre de réalisation.

STACK

Technologies utilisées

  • Python 3.11
  • pandas
  • requests
  • LangChain
  • OpenAI API
  • Google Gemini
  • PyMuPDF
  • pdfplumber
  • pdf2image
  • Tesseract OCR
  • LibreOffice
  • Ghostscript
  • Poppler
  • Docker
  • Docker Compose
  • CRON
  • API REST / JSON

EXEMPLES PUBLICS

Des dossiers analysés à leur évolution publique

Ces liens illustrent des projets ou actifs associés à des whitepapers étudiés. Le statut public d’un VASP ou d’un actif ne doit pas être confondu automatiquement avec l’approbation individuelle d’un token précis par VARA.

Projet public opérationnel

PRYPCO Mint

Plateforme publique de tokenisation d’actifs réels à Dubaï. PRYPCO indique une licence VARA pour ses activités réglementées et un partenariat avec le Dubai Land Department.

Voir le projet public

Projet public · émission à distinguer

AquaIndex / Water Tokenization

Projet public de valorisation et tokenisation d’actifs liés à l’eau. L’existence du projet est publique, sans assimiler automatiquement le token exact du whitepaper à une émission VARA confirmée.

Voir AquaIndex

Actif public · token exact non confirmé

Ellington — Belgravia Gardens

Belgravia Gardens est publiquement référencé par Ellington. L’existence du projet immobilier ne suffit toutefois pas à confirmer publiquement l’émission exacte du token étudié dans le whitepaper.

Voir Belgravia Gardens

Fonds public · token exact non confirmé

Laser Digital Carry Fund

Le fonds sous-jacent et son ouverture à des mécanismes de tokenisation sont publiquement documentés. Le token exact TLCF du whitepaper étudié ne doit pas être présenté comme une émission VARA publiquement confirmée.

Voir Laser Digital

Les statuts réglementaires évoluent. Cette sélection illustre le contexte métier du projet ; elle ne remplace pas le registre officiel VARA ni l’analyse réglementaire propre à chaque actif.