Abdellah Aazdag

Plateforme de traitement de données financières

Smart Transformer

Une plateforme full-stack qui a modernisé des flux de données financières fondés sur des tableurs grâce à une ingestion structurée, la normalisation, un traitement déterministe et une analyse assistée par l’IA dans un périmètre défini.

Axes d’ingénierie

  • Ingénierie backend
  • Intégration full-stack
  • Architecture logicielle
  • Traitement de données
  • Systèmes assistés par l’IA

Contexte

Cadre du projet

Smart Transformer a été développé durant un stage de fin d’études de six mois chez CDG Capital en 2026.

Cette étude de cas reste au niveau du système logiciel : elle décrit comment un flux piloté par tableurs est devenu une application structurée, sans exposer les opérations internes ni les données financières sensibles.

Problème

Problème système

Des flux pilotés par des tableurs/VBA et des étapes semi-manuelles avaient besoin d’un parcours maintenable allant d’entrées hétérogènes à des données normalisées, des calculs reproductibles, des analyses et des sorties structurées.

  1. 01

    Ingérer et valider des tableurs hétérogènes.

  2. 02

    Normaliser les données avant le calcul et l’analyse.

  3. 03

    Conserver des opérations déterministes reproductibles.

  4. 04

    Générer des sorties JSON et XML structurées.

Contraintes

Contraintes de conception

La plateforme devait prendre en compte des fichiers d’entrée hétérogènes, des données sensibles, des calculs prévisibles, l’authentification, un traitement traçable et des interfaces orientées fichiers.

  • C01Tableurs d’entrée hétérogènes
  • C02Exigences de calcul déterministe
  • C03Traitement de données sensibles
  • C04Exigences d’authentification
  • C05Traitement structuré et traçable
  • C06Interfaces orientées fichiers

Mon périmètre

Contribution

Contribution substantielle à la conception et à l’implémentation de la plateforme : services backend, intégration frontend, normalisation des données, traitement déterministe, authentification, orchestration de l’IA, tests automatisés et automatisation de la livraison.

  • Services backend et API
  • Intégration frontend
  • Normalisation des données et traitement déterministe
  • Authentification et orchestration de l’IA
  • Tests automatisés et automatisation de la livraison

Architecture du système

Ports et adaptateurs

Une interface React communique avec une application/API FastAPI. Des frontières hexagonales séparent le cœur applicatif et de traitement du domaine des adaptateurs de persistance, d’identité, de fichiers et d’IA.

La logique du domaine et de l’application reste séparée des adaptateurs d’infrastructure.

Les interfaces externes peuvent évoluer sans redéfinir le cœur de traitement.

Des frontières claires réduisent le couplage et facilitent les tests du comportement central.

Figure A

Vue ports et adaptateurs

  1. 01Interface web React
  2. 02Application / API FastAPI
  3. 03Cœur applicatif et de traitement du domaine

Frontière ports / adaptateurs

  • Adaptateur de persistance PostgreSQL
  • Adaptateur de référentiels versionnés
  • Adaptateur d’identité
  • Adaptateurs d’entrée/sortie de fichiers
  • Adaptateur d’orchestration de l’IA
Le cœur de traitement dépend de frontières explicites ; les préoccupations d’infrastructure restent à l’extérieur et se connectent par des adaptateurs.

Flux de données

Séquence de traitement

Les entrées Excel ou structurées passent par l’ingestion, la validation, la normalisation, une représentation JSON structurée, le traitement déterministe, une analyse encadrée puis la génération de sorties XML ou structurées.

Figure B

Chaîne de traitement

  1. 01Entrée Excel / structurée
  2. 02Ingestion et validation
  3. 03Normalisation
  4. 04Représentation JSON structurée
  5. 05Traitement déterministe
  6. 06Analyse assistée par l’IA si nécessaireÉtape probabiliste encadrée
  7. 07Sortie XML / structurée
Parcours déterministe Frontière assistée par l’IA
L’assistance par l’IA intervient à une frontière d’analyse explicite ; le traitement déterministe reste responsable des calculs de règles métier reproductibles.

Décisions d’ingénierie

Registre des décisions

Les décisions centrales concernaient la frontière entre déterministe et probabiliste, l’isolation du domaine, les données internes normalisées, les référentiels versionnés, l’authentification adaptée au navigateur et la validation reproductible.

  1. D01

    Traitement déterministe et assistance par l’IA

    Décision
    Conserver les calculs structurés des règles métier dans une logique Python déterministe et utiliser l’IA pour les tâches d’analyse et d’interprétation.
    Raison
    Les calculs qui exigent un comportement prévisible et reproductible ne doivent pas dépendre d’une sortie probabiliste.
    Résultat
    L’IA complète le flux sans devenir la référence pour les calculs déterministes.
  2. D02

    Architecture hexagonale

    Décision
    Séparer la logique applicative et le traitement du domaine des intégrations de persistance, d’identité, de fichiers et d’IA à travers des ports et adaptateurs.
    Raison
    Le cœur de traitement avait besoin de frontières claires vis-à-vis des préoccupations d’infrastructure.
    Résultat
    Les adaptateurs sont restés remplaçables et le comportement central a pu être testé avec moins de couplage à l’infrastructure.
  3. D03

    Représentation JSON normalisée

    Décision
    Normaliser les données hétérogènes des tableurs dans une représentation JSON structurée avant les traitements en aval.
    Raison
    Une représentation interne stable fournit une frontière d’entrée cohérente aux étapes de calcul, d’analyse et de sortie.
  4. D04

    Référentiels versionnés

    Décision
    Gérer la configuration des correspondances et des référentiels comme des données versionnées sans exposer les valeurs internes.
    Raison
    Le traitement nécessitait des changements maîtrisés des référentiels tout en conservant le contexte historique.
  5. D05

    Keycloak avec PKCE et JWT

    Décision
    Utiliser Authorization Code Flow avec PKCE S256 pour le navigateur et valider les JWT avec RS256.
    Raison
    L’authentification nécessitait un flux standard adapté au navigateur plutôt qu’une gestion directe des identifiants dans l’application.
  6. D06

    Tests automatisés et validation de la livraison

    Décision
    Utiliser pytest, Tox, GitHub Actions et Docker pour des tests, une validation et une préparation de la livraison reproductibles.
    Raison
    Un système de traitement en plusieurs étapes bénéficie d’une protection contre les régressions et d’une automatisation reproductible.

Intégration de l’IA

Capacité encadrée

Des agents assistés par l’IA soutenaient l’identification des champs, les tâches d’analyse et la génération de rapports. Ils complétaient le flux sans devenir la référence pour les calculs métier déterministes.

Déterministe

Traitement de référence

Les calculs structurés des règles métier restent prévisibles et reproductibles.

Probabiliste

Assistance à l’analyse

L’IA soutient le travail d’interprétation dans une frontière explicite.

Responsabilités des agents

  1. A01Identification des champs
  2. A02Analyse des données
  3. A03Assistance à l’analyse des calculs
  4. A04Génération de rapports

Sécurité

Authentification navigateur

Keycloak assurait l’authentification OAuth 2.0 et OpenID Connect avec Authorization Code Flow et PKCE S256, tandis que les JWT étaient validés avec RS256.

S01Navigateur
S02Authorization Code + PKCE
S03Fournisseur d’identité
S04Jeton d’accès
S05Validation par l’API

Cette approche écarte la gestion directe des identifiants du flux applicatif tandis que l’API vérifie les jetons d’accès signés. Les paramètres, détails de realm, identifiants client et endpoints privés sont volontairement exclus.

Livraison et qualité

Validation et livraison

Plus de 450 tests automatisés, pytest, Tox, GitHub Actions et Docker soutenaient les contrôles de régression, la validation automatisée et une préparation reproductible de la livraison.

450+tests automatisés
  • pytest pour l’exécution des tests automatisés
  • Tox pour des environnements de validation reproductibles
  • GitHub Actions pour la validation CI
  • Docker pour la préparation conteneurisée de la livraison

Résultats

Résultat mesuré

Pour la charge de travail testée, un flux qui prenait auparavant environ quatre heures a été ramené à moins de 45 secondes.

Avant≈ 240 min
Après< 45 s

Pour la charge de travail testée

Enseignements d’ingénierie

Bilan d’ingénierie

Le projet a confirmé l’intérêt de normaliser tôt les entrées hétérogènes, d’isoler la logique du domaine, de concevoir des adaptateurs remplaçables et de maintenir l’assistance probabiliste hors des frontières d’autorité déterministe.

  1. T01

    Normaliser les entrées hétérogènes avant le traitement du domaine.

  2. T02

    Rendre explicite la frontière entre déterministe et probabiliste.

  3. T03

    Isoler l’infrastructure afin que les intégrations externes restent remplaçables.

  4. T04

    Utiliser des tests automatisés et une livraison reproductible pour réduire le risque de régression.

Index technologique

Référence technique

Une référence compacte des technologies vérifiées utilisées pour l’interface, le backend, les données, la sécurité, l’architecture, l’IA, la qualité et la livraison.

Interface
React / TypeScript
Backend
Python / FastAPI / Pydantic / SQLAlchemy / Alembic
Données
PostgreSQL / JSON structuré / Traitement Excel / XML
Sécurité
Keycloak / OAuth 2.0 / OIDC / PKCE S256 / JWT / RS256
Architecture
Architecture hexagonale / Ports et adaptateurs
IA
Agents fondés sur des LLM / Orchestration multi-agents
Qualité
pytest / Tox / Tests automatisés
Livraison
GitHub Actions / Docker / CI/CD