Dédicaces

Je dédie ce travail
À ma chère mère, qui ne m’a jamais manqué d’amour inconditionnel et d’affection, veillant
toujours sur mon bonheur, ma santé et ma réussite.

À mon père, avec toute ma reconnaissance pour ses sacrifices, ses encouragements et son soutien
indéfectible. Rien ne lui suffisait vraiment, et c’est ainsi qu’il nous a appris à toujours viser plus
haut.

À mes sœurs et mon frère, qui n’ont jamais cessé de m’encourager et de me soutenir, tout en
plaçant la barre très haut avec leur esprit de compétition.

À mes chères tantes qui m’ont soutenue tout au long de mon parcours comme si j’étais leur
fille.

À mon grand père, paix à son âme, sa vision du monde et sa sagesse ont profondément façonné
la personne que je suis aujourd’hui.

Je vous dédie ce travail en signe de reconnaissance pour tout ce que vous avez fait pour moi.

Ranim Rabah

1
Remerciements

Au terme de cette aventure enrichissante, je tiens à exprimer ma profonde gratitude à toutes

les personnes qui ont contribué à la réalisation de ce projet.

À mon encadrante académique, Monsieur Aissa Abdelmonem, pour son soutien constant et ses
précieux conseils. Merci pour votre encouragement et vos éclairages tout au long de ce parcours.

À madame Yosra Wannen, mon encadrant professionnel chez Navinspire, pour sa présence et
ses conseils pratiques. Merci pour votre aide précieuse et votre soutien dans mon intégration
professionnelle.

À tous les collaborateurs de Navinspire, pour leur soutien logistique et leur accueil chaleureux,
qui ont créé un environnement propice à l’apprentissage.

À tous les enseignants de ESPRIT, pour avoir partagé leurs connaissances et leurs compétences
avec passion, contribuant ainsi à une formation riche et complète.

Merci à chacun de vous pour avoir rendu ce projet possible et pour avoir enrichi cette expérience.

2
Résumé

Ce rapport détaille un projet visant à automatiser le traitement des documents financiers et la

gestion des clients grâce à l’intelligence artificielle. La plateforme développée intègre plusieurs
agents intelligents pour :

— Extraire et normaliser les données de facturation grâce à l’OCR ;

— Classer l’urgence des factures grâce au machine learning ;
— Détecter les éléments frauduleux en fonction de la logique métier et de la validation
externe ;
— Prioriser les clients et adapter les stratégies marketing en conséquence.

Chaque sprint a contribué à une couche fonctionnelle de la plateforme, exploitant des compo-
sants d’IA modernes et des outils low-code pour créer des workflows modulaires et réutilisables.
En combinant prise de décision basée sur les données et communication basée sur le LLM,
le système offre une solution pratique et évolutive aux entreprises souhaitant optimiser leurs
processus financiers et CRM.

3
Abstract

Ce projet présente le développement d’une plateforme d’IA conçue pour automatiser le traite-
ment des factures, détecter les fraudes potentielles, prioriser les factures et les clients, et générer
des stratégies marketing personnalisées. Réalisé au sein de l’entreprise Navinspire IA, le système
s’appuie sur une architecture modulaire basée sur des frameworks low-code/no-code tels que
RAGDL, intégrant des technologies telles que l’OCR, le Machine Learning (ML) et les Large
Language Models (LLM).

Au cours de quatre sprints suivant la méthodologie Scrum, des agents intelligents ont été créés
pour gérer des tâches distinctes : extraction des données de factures, validation des fraudes
(conformité TVA, vérifications SIRET/IBAN), classification des factures et des clients, et gé-
nération de stratégies de communication personnalisées. Plusieurs modèles de Machine Learning
ont été évalués (régression logistique, forêt aléatoire, boosting de gradient, etc.), les choix finaux
étant basés sur la performance, l’interprétabilité et la facilité de déploiement.

Le système final permet aux entreprises de réduire les tâches manuelles, d’améliorer la confor-
mité, de détecter les anomalies et d’optimiser l’engagement client, le tout grâce à des workflows
intelligents et automatisés.

4
Table des matières

Liste des figures 8

Liste des tableaux 10

Liste des acronymes 11

Introduction Générale 12

1 Étude préliminaire et cadrage du projet 14

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.2 Technologie utilisée – RAGDL Platform . . . . . . . . . . . . . . . . . . 15

1.3 Cadre de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4 Contexte, problématique et solution proposée . . . . . . . . . . . . . . . . . . . 17

1.4.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5 Méthodologie et Méthode de travail . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.5.1 Méthodologie : Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.5.2 Méthode : Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5.3 Application de Scrum au projet . . . . . . . . . . . . . . . . . . . . . . . 19

1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5
TABLE DES MATIÈRES 6

2 Identification des besoins et de l’environnement de travail 21

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Spécificités du métier de la finance et processus manuels . . . . . . . . . . . . . 23

2.3.1 Éléments clés en comptabilité . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.2 Processus manuels actuels . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.3 Enjeux de l’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Besoins fonctionnels et non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.7 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.8 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Sprint 1 : Extraction des données d’une facture en utilisant l’OCR 30

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Analyse des Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.1 Composants crées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
TABLE DES MATIÈRES 7

4 Sprint 2 : Prioritisation des factures et génération des alertes pour clients et utilisa-
teurs selon priorité facture 38

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Analyse des Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4 Préparation des données, modélisation et évaluation . . . . . . . . . . . . . . . . 40

4.4.1 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.2 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.3 Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6.1 Composants crées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Sprint 3 : Détection fraude des factures 53

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2 Sprint 3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Analyse des Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5.1 Composants crées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
TABLE DES MATIÈRES 8

6 Sprint 4 : Prioritisation des clients et génération de stratégies de marketing selon

priorité client 61

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2 Sprint 4 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3 Analyse des Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4 Préparation des données, modélisation et évaluation . . . . . . . . . . . . . . . . 63

6.4.1 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.4.2 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.4.3 Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.6.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Liste des figures

1.1 Logo Navinspire IA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Platforme RAGDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3 Interface export API - RAGDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Architecture Globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Diagramme du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Composant upload image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Composant PaddleOCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4 Composant AWS TEXTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Composant GCS Google Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6 Output workflow OCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.7 Workflow OCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 données brutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 données traitées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Random Forest évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Évaluation d’autres modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.5 Diagramme du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.6 Composant Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

9
LISTE DES FIGURES 10

4.7 Composant SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.8 Workflow prioritisation factures . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.9 Output workflow prioritisation factures . . . . . . . . . . . . . . . . . . . . . . 47

4.10 Workflow alerte client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.11 Zoom workflow alerte client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.12 Exemple output email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.13 Workflow alerte utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.14 Output workflow alerte utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Diagramme sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2 RNE Scrapping Composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 IBAN Scrapping Composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.4 Output Workflow Fraude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.5 Workflow Fraude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.6 Zoom 1 Workflow Fraude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.7 Zoom 2 Workflow Fraude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1 Données Primaires client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Données traitées client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Logistic Regression - client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.4 Decision Tree - client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.5 Random Forest - client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.6 SVM - client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.7 KNN - client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.8 Gradient bOOSTING - client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.9 Diagramme sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.10 Workflow suivi client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.11 Output workflow suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Liste des tableaux

2.1 Analyse comparative des plateformes de gestion de factures existantes . . . . . . 21

2.2 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Modèles prioritisation factures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Sprint 3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1 Sprint 4 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Features Modèle prioritisation clients . . . . . . . . . . . . . . . . . . . . . . . . 63

6.3 Modèles prioritisation clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

11
Liste des acronymes

AWS :Amazon Web Services

BIC :Bank Identifier Code
GCP :Google Cloud Platform
GDPR :General Data Protection Regulation
IA : Intelligence Artificielle
IBAN :International Bank Account Number
KNN :K-Nearest Neighbors
LLM :Large Language Model
ML :Machine Learning
OCR :OpticalCharacter Recognition
RAG : Retrieval Augmented Ggeneration
RAGDL : RAG Data Lake
SIRET :Système d’Identification du Répertoire des Etablissements
SVM :Support Vector Machine
TVA :Taxe sur la Valeur Ajoutée

12
Introduction Générale

l’ère du numérique, les organisations de tous secteurs d’activité sont confrontées à des dé-
À fis croissants pour gérer efficacement leurs documents financiers et leurs relations clients.
Les processus manuels tels que le traitement des factures, le suivi des paiements et la communi-
cation client sont chronophages, sujets aux erreurs et difficiles à déployer. Pour répondre à ces
problématiques, l’automatisation intelligente basée sur l’intelligence artificielle (IA) est devenue
un facteur clé d’efficacité opérationnelle et de prise de décision.

Ce projet, mené au sein de l’entreprise Navinspire IA, porte sur le développement d’une plate-
forme modulaire basée sur l’IA, conçue pour automatiser le traitement des factures, la détection
des fraudes, la priorisation des clients et l’élaboration de stratégies marketing. Le système s’ap-
puie sur des frameworks d’IA modernes, notamment LangChain, LangGraph et RAGDL, qui
facilitent l’orchestration de composants d’IA modulaires appelés agents.

Dans ce contexte, un agent désigne un module autonome, axé sur les objectifs, conçu pour
effectuer une tâche spécifique, comme la classification des factures, l’extraction d’informations
via OCR ou la génération de texte à l’aide d’un modèle de langage. Chaque agent peut être
composé, enchaı̂né ou réutilisé dans différents flux de travail, permettant une automatisation
flexible et intelligente.

Le projet a été structuré selon la méthodologie Scrum, divisée en quatre sprints itératifs, chacun
ciblant une fonctionnalité clé : l’extraction de données par OCR, la classification et l’alerte des
factures, la détection des fraudes et la segmentation des clients avec génération de stratégies.

Ce rapport détaille le cycle de vie complet du projet, de l’analyse des besoins métier et de
la conception du système au traitement des données, à la formation des modèles d’IA et à la
mise en œuvre du workflow en temps réel, en mettant l’accent sur les livrables pratiques et
l’évolutivité future.

13
Chapitre 1

Étude préliminaire et cadrage du projet

1.1 Introduction

Ce chapitre offre un aperçu complet du contexte dans lequel le projet a été lancé et pose les
bases de sa mise en œuvre. Il commence par présenter l’organisation hôte, Navinspire IA, une
startup évoluant dans le domaine de l’intelligence artificielle, et met en avant sa plateforme
innovante, RAGDL, qui sert de socle technologique à ce projet.

Le chapitre détaille ensuite la portée et l’objectif du projet, qui consiste à développer une solu-
tion intelligente et automatisée de gestion des factures, adaptée aux besoins des comptables et
des commerçants. Le contexte, les défis et les opportunités sont explorés, ainsi qu’une formu-
lation claire de la problématique à traiter et de la solution proposée. Enfin, le chapitre décrit
la méthodologie agile – Scrum – utilisée pour structurer et gérer le cycle de développement du
projet.

1.2 Organisme d’accueil

1.2.1 Présentation

Fondée en juin 2024, Navinspire IA opère à l’échelle internationale, avec une présence établie
en Europe, en Afrique et en Asie. L’entreprise se spécialise dans le développement de solu-
tions d’intelligence artificielle de pointe, conçues pour accompagner les organisations dans leurs
transformation numérique.

14
1.2 Organisme d’accueil 15

Figure 1.1 – Logo Navinspire IA

Navinspire IA évolue dans le secteur de l’Intelligence Artificielle, en développant des solutions

basées sur l’IA générative et le traitement du langage naturel. Les cas d’usage s’adressent à di-
vers secteurs d’activité, tels que le e-commerce, la finance, la santé, l’informatique, le marketing
et bien d’autres.

Grâce aux modèles avancés, nous accompagnons les entreprises dans l’automatisation des tâches,
l’optimisation des processus et l’amélioration de l’expérience client, en leur offrant des solutions
intelligentes et évolutives adaptées à leurs besoins.

1.2.2 Technologie utilisée – RAGDL Platform

Figure 1.2 – Platforme RAGDL

Dans le cadre de son engagement à fournir des solutions d’IA intelligentes et accessibles, Na-
vinspire IA a développé la plateforme RAGDL(représenté dans la figure 1.2), un framework
1.3 Cadre de projet 16

Figure 1.3 – Interface export API - RAGDL

low-code/no-code conçu pour simplifier la création d’agents back-end intelligents. Basée sur
LangChain et LangGraph, RAGDL permet le développement rapide d’applications capables
d’analyser diverses sources de données, d’automatiser les workflows et de fournir des informa-
tions contextuelles. Ces workflows peuvent être par la suite exporté comme API(représenté dans
la figure 1.3).

La plateforme prend en charge l’intégration avec divers flux de données tels que les PDF et
les bases de données, et est équipée de modules pour la génération augmentée de données
(RAG), d’agents personnalisés et de workflows multi-étapes. Elle simplifie la création de services
basés sur l’IA, permettant aux équipes de se concentrer sur la logique métier plutôt que sur
l’infrastructure. Dans le cadre de ce projet, la plateforme RAGDL sert de base à la création
d’un système de gestion des factures basé sur l’IA, permettant l’automatisation, la détection
des fraudes et une priorisation intelligente, adapté aux besoins des professionnels de la finance.

1.3 Cadre de projet

Dans un contexte où la gestion financière représente un défi majeur pour les commerçants et les
professionnels de la comptabilité, ce projet propose une plateforme numérique pour centraliser,
automatiser et optimiser les processus financiers du quotidien.

Le site vise à devenir un outil indispensable pour les commerçants et les comptables, en leur
1.4 Contexte, problématique et solution proposée 17

offrant une solution intégrée de gestion des factures, de gestion financière, de suivi des transac-
tions, de génération de rapports, et de collaboration sécurisée.

Le module gestion factures sert à faciliter les procédures et centraliser leurs opérations finan-
cières pour les commerçant et les comptables ainsi que de donner des recommendation person-
nélisés selon l’IA générative ou bien la machine learning. L’objectif est d’éliminer les tâches
manuelles, réduire les erreurs, et donner des recommendations basées sur l’IA.

1.4 Contexte, problématique et solution proposée

1.4.1 Contexte

La numérisation et l’introduction de l’IA boulverse le secteur de la comptabilité et de la gestion

financière. Face à la diversité sources d’information (factures papier, pdf, base de données, etx.),
et à l’exigence croissante du domaine, les professionnels du domaine ainsi que les commerçant
doivent s’adapter à de nouveaux outils et platformes pour rester compétitifs.

Dans ce contexte, les commerçants ainsi que les proffesionnels (comptables) confrontent des
processus pénibles en terme d’actions manuelles, répétitives et de précision.

1.4.2 Problématique

Comment automatiser et optimiser la gestion des factures en passant par une IA à capacité de :
— Traitement de flux multi-sources (scans, bases de données)
— Raisonnement pour validation de conformité et détection d’anomalies
— Intégration sans complexité aux applications web et mobiles ?
— Combiner puissance (LangChain/LangGraph) et simplicité (low-code) pour supprimer
les tâches manuelles et les erreurs.

1.4.3 Solution proposée

La solution proposée s’appuie sur RAGDL, une plateforme low-code/no-code développée par
Navinspire IA, qui intègre des technologies avancées telles que LangChain et LangGraph. Le
projet comprend le développement d’un agent intelligent spécialisé dans la gestion des factures,
conçu pour aider les comptables et les commerçants à rationaliser leurs processus financiers.
1.5 Méthodologie et Méthode de travail 18

La solution permet de :
— Extraire automatiquement les champs clés des factures (PDF ou images) grâce à des
technologies OCR telles que PaddleOCR, Google Vision et AWS Textract.
— Classer les factures par niveau de priorité (faible, moyen, élevé) grâce à un modèle de
machine learning (forêt aléatoire) basé sur les champs extraits, tels que le montant et la
date d’échéance.
— Détecter la fraude en validant les factures grâce à des contrôles automatisés (par exemple,
vérification de l’IBAN, extraction des numéros SIRET avec Playwright, consultation de
l’historique des fournisseurs).
— Envoyer des rappels personnalisés par e-mail ou SMS, dont le contenu est généré dy-
namiquement par un modèle de langage en fonction du statut de paiement et du profil
client.
— Centraliser toutes les opérations dans une interface utilisateur intuitive avec des work-
flows low-code configurables.
L’objectif est de fournir une solution complète, intelligente et accessible qui réduit les tâches
manuelles, améliore la conformité réglementaire et permet aux professionnels de la finance de
gagner un temps précieux.

1.5 Méthodologie et Méthode de travail

1.5.1 Méthodologie : Agile

Le projet a été mené selon la méthodologie Agile, une approche flexible et adaptative du déve-
loppement logiciel qui privilégie la progression itérative, le feedback continu et la collaboration
client.

La méthode Agile permet aux équipes de livrer régulièrement des améliorations fonctionnelles
du produit, au lieu d’attendre la fin du projet. Cela permet de mieux gérer l’évolution des
exigences, de réduire les risques et d’améliorer continuellement le produit en fonction des retours
utilisateurs.

Les principes clés de la méthode Agile incluent :

— La collaboration client plutôt que la négociation contractuelle : l’utilisateur est régu-
lièrement impliqué pour valider l’utilité et la pertinence des fonctionnalités livrées.
1.5 Méthodologie et Méthode de travail 19

— La réactivité face au changement plutôt que le suivi d’un plan fixe : la méthode Agile
favorise une adaptation rapide à l’évolution des besoins et des retours.
— Un logiciel fonctionnel plutôt qu’une documentation exhaustive : la priorité est donnée
à la livraison de fonctionnalités fonctionnelles à valeur ajoutée.
— Les individus et les interactions plutôt que les processus et les outils : la communication
et le travail d’équipe sont essentiels à la réussite.
Dans le cadre de ce projet, la méthode Agile a apporté la flexibilité nécessaire pour explorer,
prototyper et améliorer de manière itérative des modules basés sur l’IA, tels que l’OCR, la
détection de fraude et la classification des clients.

Chaque phase du projet a été divisée en itérations ciblées (sprints), permettant à l’équipe
d’identifier rapidement les problèmes, de tester les hypothèses et d’ajuster la portée de manière
dynamique.

1.5.2 Méthode : Scrum

Scrum est un cadre de gestion de projet agile conçu pour faciliter le développement itératif et
incrémental. Il favorise la planification adaptative, le développement évolutif, la livraison anti-
cipée et l’amélioration continue. Scrum s’articule autour d’une équipe auto-organisée travaillant
en cycles courts appelés sprints, d’une durée généralement de deux à quatre semaines. Chaque
sprint vise à livrer un incrément de produit potentiellement livrable.

Les rôles clés de Scrum sont les suivants :

— Product Owner : définit le backlog produit et fixe les priorités.
— Scrum Master : assure le bon déroulement du processus et élimine les obstacles.
— Équipe de développement : livre les incréments de produit.
Les activités clés incluent la planification de sprint, les réunions quotidiennes, les revues de
sprint et les rétrospectives de sprint.

1.5.3 Application de Scrum au projet

Dans ce projet, nous avons adopté Scrum pour garantir la flexibilité, un retour d’information
régulier et l’intégration continue des fonctionnalités. L’ensemble du cycle de développement a
été divisé en quatre sprints, d’une durée d’environ trois semaines chacun.

Chaque sprint a suivi un processus structuré :

1.6 Conclusion 20

— Planification du sprint : Les tâches ont été définies et estimées en fonction du backlog
et des objectifs du projet.
— Points quotidiens : Une brève réunion quotidienne a été organisée pour discuter de l’avan-
cement, des points bloquants et des prochaines étapes.
— Revue de sprint : À la fin de chaque sprint, les fonctionnalités développées ont été
démontrées et validées.
— Rétrospective du sprint : Nous avons analysé les performances du sprint et identifié les
axes d’amélioration pour le cycle suivant.
Cette approche itérative nous a permis de :
— Intégrer les retours d’expérience en amont et à intervalles réguliers.
— Prioriser les fonctionnalités clés telles que l’OCR, la classification et la détection des
fraudes.
— Maintenir une progression constante tout en s’adaptant aux défis (par exemple, incohé-
rences de l’OCR ou problèmes de qualité des données).

1.6 Conclusion

Ce premier chapitre a posé les bases de la compréhension du projet et de son environnement.

Grâce à une analyse du contexte métier, une présentation détaillée de l’organisation hôte et de
son écosystème technologique, et l’identification des principaux enjeux de gestion financière, la
pertinence et l’ambition de la solution proposée ont été clairement démontrées.

L’adoption de la méthodologie Scrum garantit un processus de développement structuré et ité-

ratif, permettant une amélioration continue et l’intégration régulière des retours d’expérience.
Une fois ces bases posées, les chapitres suivants se pencheront sur les besoins spécifiques iden-
tifiés, l’environnement de travail et la mise en œuvre concrète de la solution.
Chapitre 2

Identification des besoins et de

l’environnement de travail

2.1 Introduction

Ce chapitre vise à identifier et à définir les exigences métier et techniques nécessaires au dé-
veloppement réussi de la solution de gestion des factures. Il fournit également un aperçu de
l’environnement de travail, des outils et des choix architecturaux qui guident la mise en œuvre.
Des éléments clés tels que la compréhension du domaine d’activité, les besoins fonctionnels et
non fonctionnels, la planification du projet et l’architecture système sont abordés. Pour pallier

Plateforme Points forts Limites

Sage, QuickBooks Automatisation de la Flux de travail rigides, in-
comptabilité, suivi des telligence limitée, faible in-
factures tégration multisource
Rossum, Docsumo Extraction de données Absence de raisonnement,
par OCR absence de détection de
fraude, personnalisation li-
mitée
Outils open source (InvoiceNet, Tesseract) Personnalisables et Nécessitent une expertise
gratuits technique poussée, manque
d’interfaces métier

Table 2.1 – Analyse comparative des plateformes de gestion de factures existantes

21
2.2 Étude de l’existant 22

ces lacunes, la solution proposée dans ce projet s’appuie sur la plateforme RAGDL. Elle allie
la flexibilité d’une interface low-code à l’intelligence des modèles d’IA modernes (LLM et ML).
Elle comprend :
— Extraction intelligente des champs des factures grâce à l’OCR et aux LLM ;
— Détection automatisée des fraudes par vérification des SIRET, IBAN et historique des
fournisseurs ;
— Intégration multi-sources (PDF, bases de données, e-mails) ;
— Notifications personnalisées selon la priorité des factures ;
— Configuration des workflows accessible aux utilisateurs non techniques.
Le système proposé comble ainsi le fossé entre les logiciels de comptabilité statiques et l’auto-
matisation moderne basée sur l’IA, offrant une approche plus intelligente, efficace et évolutive
de la gestion des factures.

2.2 Étude de l’existant

Avant de concevoir un nouveau système de gestion des factures, il est important d’analyser les
solutions existantes sur le marché. Cette étape permet d’identifier leurs limites et de définir la
valeur ajoutée de la solution proposée.

Plusieurs plateformes, commerciales et open source, offrent des fonctionnalités de traitement

des factures. Parmi elles, on trouve des outils comme Sage, QuickBooks et Libeo, couramment
utilisés pour l’automatisation comptable, ainsi que Rossum et Docsumo, spécialisés dans le
traitement de documents à l’aide de technologies OCR.

Si ces plateformes offrent des fonctionnalités de base telles que le suivi des factures, l’extraction
de données et le reporting financier, elles présentent des lacunes dans plusieurs domaines clés :
— Manque de raisonnement contextuel : Elles se limitent à une simple extraction de
champs et ne comprennent ni n’analysent le contexte des données (par exemple, détection
de fraudes, identification d’anomalies).
— Flexibilité d’intégration limitée : La plupart des systèmes ne prennent en charge que les
fichiers PDF ou les images numérisées et ne gèrent pas les données provenant d’e-mails,
de bases de données ou d’autres environnements multisources.
— Absence de priorisation ou de personnalisation intelligente : les alertes et les commu-
nications utilisateur sont génériques et inadaptées à l’urgence ou au comportement du
client.
2.3 Spécificités du métier de la finance et processus manuels 23

— Dépendance technique : la plupart des solutions nécessitent l’intervention d’un dévelop-

peur pour toute modification ou configuration du flux de travail, ce qui les rend moins
accessibles aux utilisateurs métier.
Principales activités :
— Vérification des factures et extraction de clés
— Détection des fraudes
— Priorisation des factures et alertes
— Suivi client

2.3 Spécificités du métier de la finance et processus manuels

2.3.1 Éléments clés en comptabilité

Dans le domaine comptable et financier, plusieurs identifiants et codes sont essentiels pour
vérifier la légitimité et la conformité des documents financiers. Parmi ceux-ci, on peut citer :
— SIRET : Numéro d’immatriculation unique Tunisien utilisé pour identifier les fournis-
seurs. Il garantit l’existence légale de l’entreprise et permet un recoupement dans les
bases de données gouvernementales.
— IBAN : Code international normalisé utilisé pour identifier les comptes bancaires. La
validation du format et de la structure d’un IBAN est cruciale pour éviter les paiements
frauduleux ou incorrects.
— BIC : Utilisé avec l’IBAN pour identifier la banque du destinataire et prendre en charge
les virements internationaux.
— TVA : Les numéros de TVA permettent de garantir l’immatriculation fiscale correcte
des fournisseurs. Ceci est particulièrement important pour le traitement des factures et
la communication financière.
Chacun de ces éléments joue un rôle essentiel dans la validation des données des factures. Une
erreur ou une omission dans l’un de ces champs peut entraı̂ner une non-conformité réglemen-
taire, des retards de paiement ou une fraude financière.

2.3.2 Processus manuels actuels

Aujourd’hui, nombre de ces vérifications sont effectuées manuellement par des comptables ou
des assistants financiers. Elles impliquent généralement :
2.3 Spécificités du métier de la finance et processus manuels 24

— Vérification des formats IBAN à l’aide d’outils en ligne ;

— Consultation des numéros SIRET dans les registres gouvernementaux (par exemple,
RNE) ;
— Vérification des données historiques relatives au comportement d’un fournisseur (retards
de paiement, incohérences) ;
— Validation des numéros de TVA selon les normes nationales.
Ces tâches sont :
— Chronométreuses, notamment lors du traitement de gros volumes de factures ;
— Sujets aux erreurs, dus à une surveillance humaine ou à des méthodes de validation
incohérentes ;
— Inefficaces, car nécessitant le basculement entre plusieurs systèmes ou outils.
Dans les flux de travail complexes, l’absence d’automatisation peut ralentir le traitement des
factures, augmenter les coûts opérationnels et réduire la réactivité de l’entreprise.

2.3.3 Enjeux de l’automatisation

Compte tenu de la nature répétitive et sensible de ces processus, leur automatisation représente
une opportunité précieuse. Dans le cadre de ce projet, l’automatisation sera mise en œuvre
grâce à des agents basés sur l’IA qui :
— Extrairont les champs clés des factures grâce à des technologies OCR telles que Padd-
leOCR, Google Cloud Vision et AWS Textract ;
— Valideront automatiquement les numéros SIRET et IBAN grâce à l’intégration avec des
registres en ligne et des API fiables ;
— Utiliseront des modèles de machine learning pour classer les factures par priorité et
détecter les anomalies en fonction du comportement des fournisseurs ;
— Généreront des alertes personnalisées (par SMS, e-mail ou notification intégrée à l’appli-
cation) adaptées à la priorité et au statut de paiement, grâce à des modèles de langage
étendus comme OpenAI et DeepSeek.
Cette automatisation réduira considérablement la charge de travail manuelle, minimisera les
erreurs humaines et améliorera considérablement la rapidité et la fiabilité du traitement des
documents financiers.
2.4 Besoins fonctionnels et non fonctionnels 25

2.4 Besoins fonctionnels et non fonctionnels

2.4.1 Besoins fonctionnels

Les besoins fonctionnels des APIs qui seront traités par la suite sont :
— L’utilisateur peut importer des factures au format PDF ou image.
— Le système extrait les champs clés (montant, date d’échéance, TVA) grâce à l’OCR
(PaddleOCR, GCP Vision, AWS Textract).
— Le système classe les factures par priorité (faible/moyenne/élevée) grâce à un modèle
d’apprentissage automatique.
— Le système détecte les fraudes en fonction de la validité des numéros SIRET et IBAN
des fournisseurs, ainsi que de leur historique de comportement.
— Le système génère des rappels personnalisés (SMS/e-mails/notifications) grâce à des
LLM (OpenAI, DeepSeek) en fonction de la priorité des factures.
— Le système stocke les données de facture structurées dans MongoDB.
— Le système priorise les clients en fonction de leur historique grâce à un modèle d’appren-
tissage automatique.
— Le système génère des stratégies marketing basées sur la priorité du client.

2.4.2 Besoins non fonctionnels

Les besoins non fonctionnels figurents comme :

Maintenabilité :
Découpage clair des services (OCR, ML, Fraude) pour des mises à jour indépendantes et utili-
sation de LangChain/LangGraph pour isoler les workflows.
Expérience Utilisateur :
Low-Code : Interface drag-and-drop pour configurer les composants avec un minimum de code.
Conformité :
Règles tunisiennes : Validation systématique des formats (IBAN 24 caractères, TVA 7 chiffres,
etc.) et intégration du scraper RNE pour vérifier les SIRET.
Sécurité :
Les workflow sont développés tout en respectant les régles GDPR.
2.5 Technologies utilisées 26

2.5 Technologies utilisées

Développement back-end : Python, FastAPI

ML : Scikit-learn

OCR : PaddleOCR, Google Vision (GCP), Textract (AWS)

LLM et agents : OpenAI, DeepSeek, LangChain, LangGraph

Base de données : MongoDB

Outils de scraping : Playwright

API de communication : E-mail SMTP, Twilio (SMS)

Plateforme : RAGDL (framework back-end low-code/no-code)

Environnement de développement : WSL (Windows Subsystem for Linux) avec Ubuntu

2.6 Pilotage du projet avec Scrum

Scrum a été adopté pour soutenir une approche agile, flexible et itérative tout au long du projet.
Le backlog était géré dans Trello et l’équipe a suivi quatre sprints, chacun axé sur des livrables
progressifs. Les sprints sont représentés dans le tableau 2.2 :

Sprint Module Durée (semaines)

Sprint 1 Extraction des données d’une facture en utilisant l’OCR 4
Prioritisation des factures et génération des alertes pour
Sprint 2 4
clients et utilisateurs selon priorité facture
Sprint 3 Détection fraude des factures 4
Prioritisation des clients et génération de stratégies de
Sprint 4 4
marketing selon priorité client

Table 2.2 – Sprints

2.7 Diagramme de Gantt

Un diagramme de Gantt a été créé pour visualiser le calendrier du projet, l’allocation des
ressources et les dépendances des tâches, représenté dans la figure 2.1.
2.8 Architecture globale 27

Figure 2.1 – Diagramme de Gantt

2.8 Architecture globale

L’architecture globale, dans la figure 2.2, du système est modulaire, intelligente et conçue pour
être extensible. Elle adopte une approche orientée services basée sur RAGDL, un framework
d’orchestration low-code/no-code basé sur LangChain et LangGraph. L’architecture est struc-
turée autour d’agents indépendants, chacun responsable d’une tâche spécifique, comme l’ex-
traction OCR, la détection des fraudes, la classification des factures, la priorisation des clients
et l’élaboration de stratégies marketing.

Au cœur du système se trouve un pipeline centralisé qui permet un chaı̂nage fluide des agents,
chaque composant étant faiblement couplé pour garantir flexibilité et réutilisation entre les flux
de travail.

Couches fonctionnelles clés :

— Couche front-end : Le système commence par une interface utilisateur permettant le
téléchargement de fichiers de factures au format image ou PDF.
— Ingestion des données : Les documents téléchargés sont traités par un composant de
téléchargement dédié et transmis au pipeline de traitement.
— Pipeline RAGDL : Cette couche centrale coordonne plusieurs agents intelligents :
— Agent OCR : Extrait le texte brut des images de factures à l’aide de moteurs tels
que PaddleOCR, Google Vision ou AWS Textract.
— Agent d’extraction LLM : Analyse et normalise la sortie OCR dans un format JSON
structuré.
2.9 Conclusion 28

— Agent de détection de fraude : Applique des règles métier et des vérifications externes
(par exemple, validation SIRET, IBAN) pour évaluer l’intégrité des factures.
— Classificateur de factures : Un modèle d’apprentissage automatique (par exemple,
Random Forest) attribue un niveau de priorité à chaque facture en fonction des
caractéristiques extraites.
— Couche d’alerte et de notification : Des notifications par e-mail, SMS et tableau de
bord sont générées en fonction de la priorité et du statut des factures à l’aide des
messages générés par LLM.
— Module de suivi client : Un agent intelligent distinct classe les clients en fonction
de leur historique de comportement et utilise les LLM pour générer des stratégies
marketing personnalisées.
— Couche de stockage et d’API : Toutes les sorties structurées (données extraites, résultats
de classification, statuts de fraude, profils clients et messages marketing) sont stockées
dans une base de données MongoDB et accessibles via des points de terminaison d’API
ou des interfaces de tableau de bord.

2.9 Conclusion

Ce chapitre a défini le contexte opérationnel et technique dans lequel le projet a été mené. La
compréhension des besoins métier, l’identification des exigences fonctionnelles et non fonction-
nelles, et le choix des technologies appropriées ont fourni une base solide pour la mise en œuvre.
L’utilisation de Scrum a assuré un développement agile et une livraison régulière de composants
fonctionnels. Le chapitre suivant détaillera l’exécution de chaque sprint et les fonctionnalités
livrées progressivement.
2.9 Conclusion 29

Figure 2.2 – Architecture Globale

Chapitre 3

Sprint 1 : Extraction des données d’une

facture en utilisant l’OCR

3.1 Introduction

Ce sprint s’est concentré sur la mise en œuvre de la fonctionnalité principale du système de

gestion des factures : l’extraction automatisée des données des factures grâce à la reconnaissance
optique de caractères (OCR). L’objectif était de développer un pipeline modulaire et extensible
capable de traiter les factures aux formats PDF et image, d’extraire les champs clés (montant,
date d’échéance, TVA, fournisseur, etc.) et de produire une structure JSON normalisée adaptée
au stockage en base de données et aux traitements ultérieurs.

Ce sprint a posé les bases techniques des modules en aval, tels que la priorisation, la détection
des fraudes et la notification client.

3.2 Sprint 1 Backlog

Le backlog du sprint 1, figurant dans le tableau 3.1, s’articulait autour de trois axes principaux :
la configuration du traitement OCR, la mise en œuvre de la normalisation des données et la
préparation des composants pour une extensibilité future. Les tâches comprenaient la création
de composants pour le téléchargement d’images et l’intégration de PaddleOCR, la conception
d’un schéma de sortie unifié et la configuration initiale de GCP Vision et d’AWS Textract
comme futures alternatives.

30
3.2 Sprint 1 Backlog 31

ID Tâche N° de jours Statut

Analyser les formats de factures (PDF, image, tableau) et
T1 1 Terminé
définir les besoins d’extraction
Concevoir un schéma JSON standard pour une sortie norma-
T2 1 Terminé
lisée
T3 Créer un component-upload pour l’entrée image/PDF 1 Terminé
Intégrer et tester PaddleOCR pour l’extraction de blocs de
T4 2 Terminé
texte
Développer une logique de post-traitement avec LLM (Deep-
T5 3 Terminé
Seek/OpenAI) pour l’extraction de champs
Normaliser les résultats OCR + LLM dans un schéma JSON
T6 2 Terminé
défini
Créer des espaces réservés de secours pour les composants
T7 1 Terminé
GCP Vision et AWS Textractn
Tester le pipeline de bout en bout avec des exemples de fac-
T8 2 Terminé
tures (tabulaires et non structurées)
Créer un point de terminaison d’API pour renvoyer une sortie
T9 2 Terminé
JSON
Rédiger des cas de test pour chaque composant (télécharge-
T10 2 Terminé
ment, OCR, post-traitement)
Documenter le flux de travail et préparer des captures d’écran
T11 1 Terminé
pour l’interface utilisateur et le rapport
T12 Refactoriser et modulariser le code 1 Terminé
Révision interne, validations et préparation de la démonstra-
T13 1 Terminé
tion

Table 3.1 – Sprint 1 Backlog

3.3 Analyse des Besoins 32

3.3 Analyse des Besoins

La principale exigence fonctionnelle de ce sprint était d’automatiser l’extraction des champs

clés des factures avec une grande précision. Cela impliquait :

— Prise en charge de plusieurs formats de factures (PDF, image, structure tabulaire)

— Extraction de champs tels que :
— Montant total
— Date d’échéance
— TVA
— Remise
— Détails de chaque produit
— Détails fournisseurs et client
— Garantir la cohérence et la structure de la sortie JSON, quelle que soit la disposition des
données d’entrée
— Préparation de l’architecture pour permettre le basculement entre différents moteurs
OCR

La précision, la cohérence et la modularité étaient les principales contraintes, notamment

compte tenu des besoins futurs en matière de validation des fraudes et de traitement LLM
en aval.

3.4 Architecture

Pour mieux illustrer le pipeline mis en œuvre lors du Sprint 1, le schéma suivant (3.1)présente
l’architecture du workflow d’extraction des données de factures. Il illustre la conception modu-
laire du système, qui garantit flexibilité, extensibilité et facilité d’intégration avec les composants
futurs.

Le workflow se compose de plusieurs composants clairement définis :

— Module de téléchargement de factures : Ce module permet aux utilisateurs de soumettre
des factures au format PDF ou image. Il valide le format du fichier et le prépare pour le
traitement.
— Composant PaddleOCR : Une fois le fichier téléchargé, l’image est transmise au moteur
OCR. PaddleOCR détecte et extrait les blocs de texte du document, quelle que soit sa
mise en page (champ unique ou tabulaire).
3.5 Réalisation 33

— Post-traitement et extraction de champs : La sortie OCR brute est traitée par un

modèle de langage étendu (LLM) qui identifie et extrait les champs prédéfinis : montant
total, date d’échéance, nom du fournisseur et numéro de TVA. Cette couche applique le
raisonnement et la normalisation.
— Générateur de sortie JSON : Les champs extraits sont mappés à un format JSON
standardisé. Cela garantit la cohérence et la compatibilité avec le schéma de base de
données utilisé lors des étapes suivantes.
— Couche de sortie/API : Les données normalisées sont renvoyées via un point de terminai-
son API ou stockées pour une utilisation ultérieure (par exemple, priorisation, détection
de fraude dans Sprint 2+).
Cette approche modulaire permet une intégration transparente des futurs moteurs OCR (par
exemple, Google Cloud Vision, AWS Textract) sans impacter le flux de travail principal.

3.5 Réalisation

3.5.1 Composants crées

Au cours de ce sprint, les composants suivants ont été développés :

— component-upload : gère le téléchargement des factures aux formats PDF et image
(figure 3.2).
— component-paddleocr : traite les images téléchargées à l’aide de PaddleOCR et génère
des zones de texte brut (figure 3.3).
— component-gcp-gv et component-aws-textract : modules d’espace réservé préparés pour
l’intégration de services OCR alternatifs lors de sprints ultérieurs (figure 3.4 et figure
3.5).
Chaque composant a été conçu pour être indépendant et prêt à l’emploi, selon une architecture
modulaire orientée services.

3.5.2 Workflow

Le flux de travail complet d’extraction de données peut être décrit comme suit (figure 3.7) :

1. L’utilisateur télécharge une facture au format PDF ou image via le composant de télé-
chargement.
3.5 Réalisation 34

Figure 3.1 – Diagramme du sprint 1

Figure 3.2 – Composant upload image

3.5 Réalisation 35

Figure 3.3 – Composant PaddleOCR

Figure 3.4 – Composant AWS TEXTRACT

Figure 3.5 – Composant GCS Google Vision

3.6 Conclusion 36

2. La facture est transmise au moteur PaddleOCR, qui détecte les blocs de texte.
3. Le résultat OCR brut est envoyé au module de post-traitement, où un LLM pré-entraı̂né
l’analyse et le mappe à un schéma JSON normalisé.
4. Le résultat OCR brut est envoyé au module de post-traitement, où un LLM pré-entraı̂né
l’analyse et le mappe à un schéma JSON normalisé comme dans figure 3.6.
5. Le résultat structuré est affiché ou renvoyé via une API, prêt à être inséré dans la base
de données.

Figure 3.6 – Output workflow OCR

Ce pipeline garantit que, malgré les variations de mise en page ou de format des factures, le
résultat reste cohérent, complet et exploitable.

3.6 Conclusion

Le Sprint 1 a posé les bases du système d’automatisation des factures. Les champs clés des
factures sont désormais extraits de manière fiable de divers formats de fichiers grâce à un
3.6 Conclusion 37

Figure 3.7 – Workflow OCR

pipeline OCR modulaire. Grâce à PaddleOCR et à un LLM de post-traitement, le système peut

gérer les documents structurés et non structurés et produire un JSON propre et normalisé, prêt
à être intégré.

Ce sprint fondateur pose les bases des sprints futurs impliquant la priorisation des factures, la
détection des fraudes et la communication client intelligente.
Chapitre 4

Sprint 2 : Prioritisation des factures et

génération des alertes pour clients et
utilisateurs selon priorité facture

4.1 Introduction

Le deuxième sprint s’est concentré sur la mise en œuvre de la couche d’intelligence centrale
du système : la priorisation des factures grâce au machine learning et la génération d’alertes
(e-mails, SMS et notifications) adaptées au niveau d’urgence de la facture. L’objectif était
de permettre au système non seulement d’évaluer le risque financier (factures en retard ou
impayées), mais aussi de communiquer efficacement et de manière adaptative avec les clients
et les utilisateurs internes (comptables et commerçants).

4.2 Sprint 2 Backlog

Le backlog du Sprint 2, dans le tableau 4.1, s’est concentré sur la mise en œuvre de trois
workflows clés : la priorisation des factures, les alertes clients et les notifications internes aux
utilisateurs. Chaque tâche visait à convertir les données brutes des factures en informations ex-
ploitables grâce à un modèle d’apprentissage automatique (Random Forest) et à la génération
de langage naturel via un modèle de langage (LLM). De plus, deux composants ont été déve-
loppés pour automatiser la communication par e-mail et SMS, en adaptant le ton des messages

38
4.3 Analyse des Besoins 39

en fonction du niveau d’urgence. Le tableau ci-dessous décrit les étapes techniques mises en
œuvre pour une prise de décision intelligente au sein du système.

ID Tâche N° de jours Statut

Préparer et nettoyer les données de facturation (caractéris-
T1 2 Terminé
tiques : solde, dates d’échéance, ratios d’impayés, etc.)
Développer et entraı̂ner le modèle Random Forest pour la clas-
T2 2 Terminé
sification des factures
Tester et comparer les modèles ML (Random Forest, SVM,
T3 2 Terminé
KNN, etc.)
T4 Intégrer l’agent ML et l’outil de classification au workflow 2 Terminé
Utiliser LLM (DeepSeek) pour générer des explications sur la
T5 1 Terminé
priorité attribuée aux factures
Créer un composant ‘component-email‘ avec ‘smtplib‘ de Py-
T6 2 Terminé
thon pour l’envoi d’alertes par e-mail personnalisées
Développer un composant ‘component-sms‘ avec l’API Twilio
T7 2 Terminé
pour envoyer des rappels par SMS en fonction de la priorité
Créer le workflow 1 : Priorisation des factures + explications
T8 2 Terminé
générées par LLM
Créer le workflow 2 : Alertes clients par e-mail/SMS selon la
T9 2 Terminé
priorité
Créer le workflow 3 : Notifications internes aux utilisateurs
T10 2 Terminé
(commerçant/comptable)
Réaliser des tests au niveau des composants et une validation
T11 1 Terminé
de la sortie de l’API
Documenter les composants et préparer des captures d’écran
T12 1 Terminé
pour l’intégration des rapports

Table 4.1 – Sprint 2 Backlog

4.3 Analyse des Besoins

L’objectif principal de ce sprint était de classer les factures en trois catégories (faible, moyenne
et haute priorité) en fonction de caractéristiques telles que le solde impayé, les retards et
4.4 Préparation des données, modélisation et évaluation 40

l’historique de comportement. Cette classification permet de générer des rappels proactifs et

une communication axée sur les risques.

Le processus nécessitait :
— Identifier les caractéristiques pertinentes grâce à l’exploration de données à partir d’en-
sembles de données brutes de factures ;
— Former plusieurs modèles de machine learning et sélectionner le plus performant ;
— Concevoir une stratégie d’incitation pour générer des explications en langage naturel et
des rappels personnalisés ;
— Créer des composants modulaires pour l’envoi d’e-mails et de SMS ;
— Assurer la cohérence et l’adaptation du ton en fonction de la priorité des factures.

4.4 Préparation des données, modélisation et évaluation

4.4.1 Préparation des données

L’ensemble de données brutes comprenait initialement les caractéristiques suivantes dans figure
4.1.

Figure 4.1 – données brutes

Après nettoyage et ingénierie des caractéristiques, un ensemble de données affiné a été créé avec
des caractéristiques techniques telles que dans figure 4.2.

Ces transformations ont permis de mettre en évidence les tendances en matière de retard de
paiement et de fiabilité des clients.
4.4 Préparation des données, modélisation et évaluation 41

Figure 4.2 – données traitées

4.4.2 Modélisation

Trois modèles de classification ont été entraı̂nés dans tableau 4.2 :

Modèle Précision Notes

Random Forest 1.00 Haute précision, interprétable, rapide
Gradient Boosting 1.00 Également parfait, mais plus complexe
Extra Trees 0.988 Rappel légèrement inférieur pour la classe haute priorité

Table 4.2 – Modèles prioritisation factures

Random Forest a été sélectionnée en raison de sa précision parfaite, de sa faible complexité et

de ses performances robustes dans toutes les classes.

4.4.3 Évaluation

Les performances du modèle ont été évaluées à l’aide de rapports de classification :

Précision : 100% (pour la forêt aléatoire et le gradient boosting)

Précision / Rappel / Score F1 : Toutes les mesures étaient à 1,00 pour toutes les classes

Distribution des classes :

— Classe 0 (faible) : 1 161 échantillons
— Classe 1 (moyenne) : 569 échantillons
— Classe 2 (élevée) : 75 échantillons
4.5 Architecture 42

L’ensemble de données était suffisamment équilibré pour permettre l’apprentissage sans sur-
échantillonnage, et les résultats ont été validés par validation croisée et par des ensembles de
tests.

Figure 4.3 – Random Forest évaluation

Figure 4.4 – Évaluation d’autres modèles

4.5 Architecture

L’architecture de Sprint 2, dans la figure 4.5, introduit une couche décisionnelle optimisée par
l’apprentissage automatique et la génération de langage naturel pour prioriser les factures et
déclencher des notifications intelligentes.

Composants clés :
4.5 Architecture 43

— Classificateur de factures (agent ML) : Utilise un modèle de forêt aléatoire entraı̂né

pour classer les factures par niveaux de priorité (faible, moyen, élevé) en fonction de
caractéristiques extraites telles que le montant total, la date d’échéance, le solde et
l’historique des paiements.
— Agent d’explication LLM : Génère une explication compréhensible par l’utilisateur de
la priorité attribuée, améliorant ainsi la transparence et l’interprétabilité.
— Système d’alerte :
— Composant e-mail : Envoie des rappels personnalisés en fonction de la priorité des
factures.
— Composant SMS : Utilise l’API Twilio pour notifier les clients avec différents niveaux
d’urgence.
— Module de notification utilisateur : Informe les utilisateurs internes (commerçants/comptables)
des factures impayées ou des actions requises.

Figure 4.5 – Diagramme du sprint 2

4.6 Réalisation 44

4.6 Réalisation

4.6.1 Composants crées

Au cours de ce sprint, les composants suivants ont été développés :

— component-email : Envoi d’e-mails via smtplib et [Link] de Python, configu-
rables avec un contenu basé sur la priorité dans la figure 4.6.
— component-sms : Intègre l’API Twilio pour envoyer des rappels par SMS en fonction du
niveau de priorité dans la figure 4.7.

Figure 4.6 – Composant Email

4.6 Réalisation 45

Figure 4.7 – Composant SMS

4.6 Réalisation 46

4.6.2 Workflow

Workflow 1 : Priorisation des factures avec explication dans figure 4.8.

Saisie : Fonctionnalités nettoyées de la base de données (total, remise, taxe, solde, jours restants,
ratio impayés/total, etc.).

Modèle ML : Forêt aléatoire (précision : 100 %) en utilisnat un agent machine learning et un

tool de classification.

Sortie : Priorité des factures (0 = Faible, 1 = Moyenne, 2 = Élevée).

Invitation : DeepSeek LLM génère une explication pour chaque facture comme dans figure 4.9.

Sortie finale : Libellé de priorité et une explication.

Figure 4.8 – Workflow prioritisation factures

Workflow 2 : Génération d’alertes client comme dans figures 4.10 et 4.11. Saisie : Factures
priorisées

Logique : Blocs ”if-else” pour déterminer le ton (par exemple, ”rappel court” ou ”urgent”) De-
mande de paiement)

Sortie :

E-mail via component-email ( exemple dans figure 4.12) SMS via component-sms
4.7 Conclusion 47

Figure 4.9 – Output workflow prioritisation factures

Objectif : Maximiser les chances de recouvrement grâce à une communication personnalisée

Workflow 3 : Notification interne aux commerçants/comptables figurant dans 4.13. Similaire

au Workflow 2, mais cible les utilisateurs plutôt que les clients

Notifie :

Créances clients impayées

Factures fournisseurs impayées

Adapte le ton en conséquence pour prioriser les actions comme dans figure 4.14.

4.7 Conclusion

Le Sprint 2 a transformé avec succès les données brutes des factures en informations exploitables
grâce à l’apprentissage automatique et à la génération de langage naturel. Le système est
désormais capable de :
— Classer précisément les factures par niveaux de priorité ;
— Justifier chaque classification grâce à des explications générées par l’IA ;
4.7 Conclusion 48

Figure 4.10 – Workflow alerte client

4.7 Conclusion 49

Figure 4.11 – Zoom workflow alerte client

4.7 Conclusion 50

Figure 4.12 – Exemple output email

4.7 Conclusion 51

Figure 4.13 – Workflow alerte utilisateur

Figure 4.14 – Output workflow alerte utilisateur

4.7 Conclusion 52

— Communiquer efficacement avec les clients et les utilisateurs internes grâce à des notifi-
cations personnalisées par e-mail et SMS.
Ce sprint a introduit une prise de décision intelligente dans le système et a préparé le terrain
pour la détection des fraudes et l’élaboration de stratégies financières lors des étapes suivantes.
Chapitre 5

Sprint 3 : Détection fraude des factures

5.1 Introduction

Ce sprint visait à créer un système intelligent de détection des fraudes capable de valider
les champs clés d’une facture à l’aide de règles métier, de données historiques et de sources
de vérification externes. L’objectif était d’automatiser les contrôles de fraude aux factures en
vérifiant l’intégrité des dates, l’exactitude des taux de taxe, la cohérence entre les prix des
produits et le montant total, et la validation externe des identifiants sensibles tels que le SIRET
et l’IBAN par web scraping.

Ce système vise à aider les commerçants et les comptables en signalant les factures poten-
tiellement frauduleuses ou incohérentes avant tout engagement financier, garantissant ainsi la
conformité réglementaire et réduisant les risques.

5.2 Sprint 3 Backlog

Le backlog du Sprint 3, dans le tableau 5.1, était axé sur la création d’un pipeline intelligent de
détection des fraudes, capable de valider les champs de factures à l’aide de règles métier internes
et de sources de vérification externes. Les tâches comprenaient la mise en œuvre d’une validation
basée sur des règles (logique de date, exactitude fiscale, cohérence des montants, historique
fournisseur/client), le développement de deux composants de scraping et l’intégration d’un
workflow de validation unifié. Ce sprint a posé les bases de la couche de conformité réglementaire
du système.

53
5.2 Sprint 3 Backlog 54

ID Tâche N° de jours Statut

Analyse des règles métier applicables (TVA, montant total,
T1 2 Terminé
intégrité des dates, vérifications des données historiques)
Conception d’un format de sortie JSON unifié pour les résul-
T2 1 Terminé
tats de validation (interne et externe)
Mise en œuvre des contrôles internes (validité des dates, co-
T3 hérence des montants, conformité à la TVA, recherche dans 3 Terminé
l’historique)
Développement de ‘component-rne-validator‘ pour extraire les
T4 2 Terminé
données du registre RNE tunisien
Développement de ‘component-iban-validator‘ pour extraire
T5 les données de [Link] à l’aide de Playwright ou Sele- 2 Terminé
nium
Intégration des validateurs RNE et IBAN dans un agent de
T6 2 Terminé
validation unifié
Création du workflow complet de détection des fraudes
T7 2 Terminé
(couches de validation internes et externes)
Création de cas de test pour les factures valides, non valides
T8 1 Terminé
et suspectes
Génération des sorties JSON structurées finales pour le statut
T9 1 Terminé
et l’audit des factures
Documentation des composants et captures d’écran du scra-
T10 1 Terminé
ping et du workflow pour le rapport

Table 5.1 – Sprint 3 Backlog

5.3 Analyse des Besoins 55

5.3 Analyse des Besoins

La logique de détection des fraudes a été conçue pour répondre à plusieurs exigences pratiques
et réglementaires :
— Validation de la date : S’assurer que la date de la facture existe, qu’elle n’est pas ultérieure
et qu’elle respecte la chronologie logique.
— Validation de la TVA : S’assurer que le taux de taxe est conforme à la législation tuni-
sienne. Par exemple :
— médicaments → 7%
— aliments → 0% ou 7%
— services hôteliers → 13%
— Généraux → 19%
— Vérification de la cohérence totale : Vérifier que le montant total (total ttc) est cohérent
avec la somme des prix unitaires × quantités + TVA.
— Cohérence historique : Vérifier si le client et le fournisseur existent dans l’historique du
système et si leurs comportements antérieurs correspondent à la transaction en cours.
— Vérifications externes :
— Numéro SIRET : Analyser le site RNE tunisien pour vérifier l’existence de l’entité
juridique.
— IBAN : Utilisez le scraping sur [Link] pour valider la structure, le code pays,
la somme de contrôle et le format de l’IBAN.
Chacune de ces vérifications contribue à une évaluation globale du risque de fraude. Les résultats
sont renvoyés dans un objet JSON structuré qui consolide les validations internes et externes.

5.4 Architecture

L’architecture de Sprint 3, dans la figure 5.1, introduit un pipeline de détection de fraude

combinant règles métier et vérification externe des données.

Composants clés :

1. Couche de validation interne : Vérifie la logique de facturation, notamment :

— Validité de la date de facturation (hors futur)
— Cohérence entre les lignes et le montant total
— Taux de TVA correct en fonction du type de produit
5.4 Architecture 56

— Cohérence avec les données historiques clients/fournisseurs

2. Agents de validation externes :
— Validateur RNE : Analyse le registre officiel tunisien (RNE) pour vérifier les numéros
SIRET.
— Validateur IBAN : Analyse [Link] pour confirmer le format IBAN, le code
pays et la somme de contrôle.
3. Agrégateur de résultats : Consolide tous les résultats de validation dans un rapport
JSON structuré indiquant l’état de chaque vérification et le risque global de fraude.

Figure 5.1 – Diagramme sprint 3

5.5 Réalisation 57

5.5 Réalisation

5.5.1 Composants crées

Deux composants clés ont été développés lors de ce sprint :

— component-rne-validator (figure : 5.2 ) : Examine le site web public du Registre natio-
nal des entreprises (RNE) tunisien (https ://[Link]) pour valider
l’existence et la légalité d’un numéro SIRET donné. Il analyse la réponse et extrait le
statut de vérification.
— component-iban-validator (figure : 5.3 ) : Examine https ://[Link]/iban-checker
à l’aide d’une navigation headless automatisée (par exemple, Playwright ou Selenium)
pour valider l’IBAN en fonction des règles nationales, de la longueur, du format et de la
somme de contrôle.

Figure 5.2 – RNE Scrapping Composant

Ces deux composants peuvent être réutilisés dans d’autres flux de travail financiers où la confor-
mité juridique et l’intégrité bancaire sont essentielles.

5.5.2 Workflow

Le workflow, dans figures 5.5, 5.6 et 5.7, de détection des fraudes intègre les composants ci-
dessus dans un pipeline de validation complet :
1. Saisie : Données de facture (PDF extrait → JSON) avec les champs : invoice id, total
ttc, TVA, IBAN, SIRET, date, lignes de transaction, etc.
5.5 Réalisation 58

Figure 5.3 – IBAN Scrapping Composant

2. Étape 1 – Vérifications internes :

— Valider la date : non vide et non future
— Correspondance du montant total (total ttc) avec les prix unitaires des articles
— Vérifier les taux de TVA par rapport au type d’entreprise
— Vérifier la cohérence client/fournisseur dans l’historique
3. Étape 2 – Validations externes :
— Utiliser component-rne-validator pour extraire le RNE et confirmer si le SIRET est
légalement enregistré
— Utiliser component-iban-validator pour extraire les résultats de la validation IBAN
4. Étape 3 – Structuration des réponses :Combiner tous les résultats dans un JSON détaillé,
comme illustré ci-dessous dans figure 5.4.

Figure 5.4 – Output Workflow Fraude

Ce format structuré permet aux services en aval d’agir en conséquence : signaler la facture,
envoyer des alertes ou bloquer le traitement.
5.5 Réalisation 59

Figure 5.5 – Workflow Fraude

Figure 5.6 – Zoom 1 Workflow Fraude

5.6 Conclusion 60

Figure 5.7 – Zoom 2 Workflow Fraude

5.6 Conclusion

Le sprint 3 a introduit avec succès un mécanisme robuste de détection des fraudes dans le
système de traitement des factures. En combinant règles métier internes et validations externes,
le système peut désormais évaluer la légitimité de chaque facture et réduire le risque de fraude
financière.

Les principaux résultats du sprint incluent :

— Mise en œuvre de deux composants de scraping réutilisables (RNE et IBAN) ;
— Un workflow unifié de validation des fraudes ;
— Format de sortie JSON pour un audit et un suivi simplifiés.
Ce sprint renforce la couche de confiance du système et garantit que toutes les futures automa-
tisations fonctionneront sur des données vérifiées et conformes.
Chapitre 6

Sprint 4 : Prioritisation des clients et

génération de stratégies de marketing selon
priorité client

6.1 Introduction

Le sprint final visait à enrichir l’intelligence du système en déplaçant l’attention de l’analyse

des factures vers la priorisation des clients. L’objectif était de catégoriser les clients en fonction
de leur historique de transactions (par exemple, habitudes de dépenses, fréquence, récence) et
d’utiliser cette priorisation pour générer automatiquement des stratégies marketing personna-
lisées pour chaque client.

Ce sprint a combiné la classification par apprentissage automatique et la génération de texte ba-

sée sur un modèle de langage, créant ainsi un système adaptatif capable d’adapter les messages
marketing et les stratégies d’engagement à l’importance du client.

6.2 Sprint 4 Backlog

Le backlog du Sprint 4, dans le tableau 6.1, s’articulait autour de l’extension de l’intelligence

du système, de la gestion des factures à la priorisation des clients et à la création de stratégies
marketing personnalisées. Cela nécessitait l’intégration de l’apprentissage automatique pour la
classification des clients et l’exploitation d’un modèle linguistique pour générer des messages

61
6.3 Analyse des Besoins 62

d’engagement personnalisés. Les tâches étaient axées sur la préparation des données transac-
tionnelles, le développement et l’évaluation des modèles de classification, et la création d’un
workflow adaptatif capable d’aligner le contenu marketing sur la valeur client.

ID Tâche N° de jours Statut

Analyser l’ensemble de données brutes des transactions et dé-
T1 2 Terminé
finir les caractéristiques client (récence, fréquence, etc.)
Agréger les données par client et étiqueter manuellement les
T2 1 Terminé
niveaux de priorité (Faible, Moyen, Élevé)
Concevoir les fonctionnalités clés : total dépensé, nombre de
T3 2 Terminé
transactions, récence, produits uniques, etc.
Entraı̂ner et comparer plusieurs modèles ML (régression lo-
T4 3 Terminé
gistique, SVM, RF, GB, etc.)
Choisir le modèle le plus performant (régression logistique) et
T5 1 Terminé
finaliser l’entraı̂nement
Créer un workflow pour la prédiction et l’attribution de prio-
T6 2 Terminé
rités par client
Intégrer la génération d’invites LLM pour produire des stra-
T7 2 Terminé
tégies marketing personnalisées
Concevoir des exemples d’invites basées sur les priorités pour
T8 1 Terminé
les segments Élevé, Moyen et Faible
Créer un workflow complet : BD → Agent ML → Moteur
T9 2 Terminé
d’invites → Sortie de messages marketing
Tester les prédictions et la cohérence des messages dans les
T10 1 Terminé
cas extrêmes
Documenter le workflow et réaliser des captures d’écran pour
T11 1 Terminé
le rapport

Table 6.1 – Sprint 4 Backlog

6.3 Analyse des Besoins

Ce module devait répondre à deux objectifs fonctionnels principaux :

Priorisation des clients :

6.4 Préparation des données, modélisation et évaluation 63

— Classer les clients en trois niveaux : priorité faible, moyenne et élevée.

— La priorisation est basée sur des caractéristiques telles que le montant total des dépenses,
la fréquence d’achat, la récence et la diversité des produits.
Génération de stratégie :
— En fonction du niveau de priorité prévu, générer automatiquement une stratégie mar-
keting sur mesure (par exemple, récompenses de fidélité, remises ciblées, messages de
fidélisation).
— Utiliser un LLM pour adapter le ton et le contenu du message à l’importance du client.

6.4 Préparation des données, modélisation et évaluation

6.4.1 Préparation des données

L’ensemble de données brutes (figure 6.1) contenait des données de transactions e-commerce,
notamment des champs tels que :
— Numéro de facture, Code de stock, Description, Quantité, Date de facture, Prix unitaire,
ID client, Pays.
Après prétraitement et agrégation par ID client, diverses fonctionnalités ont été créées, comme
dans tableau 6.2 et figure 6.2 : Chaque client a été étiqueté manuellement avec une priorité

Feature Description
[Link] Chiffre d’affaires total généré par le client
[Link] Nombre de factures
[Link] Somme de toutes les quantités achetées
[Link] Prix moyen unitaire
[Link] Nombre de produits uniques achetés
[Link] Nombre de jours depuis le dernier achat
[Link] Nombre de jours depuis la première transaction du client
[Link] Fréquence basée sur la récence et l’âge

Table 6.2 – Features Modèle prioritisation clients

(Faible, Moyenne, Élevée) pour un apprentissage supervisé.

6.4 Préparation des données, modélisation et évaluation 64

Figure 6.1 – Données Primaires client

Figure 6.2 – Données traitées client

6.4 Préparation des données, modélisation et évaluation 65

6.4.2 Modélisation

Plusieurs modèles de classification ont été entraı̂nés et comparés dans tableau 6.3 et résultats
spécifiés dans figures 6.3, 6.4, 6.5, 6.6, 6.7, 6.8 :

Modèle Précision Notes

Logistic Regression 0.9988 Meilleur équilibre et simplicité
Decision Tree 0.9781 Précision légèrement inférieure sur la classe moyenne
Random Forest 0.9862 Excellent, mais excessif pour les petits ensembles de donnéesé
SVM 0.9954 Faible performance sur la classe minoritaire (Élevée)
KNN 0.9873 Bon, mais sensible aux valeurs aberrantes
Gradient Boosting 0.9873 Haute précision, complexité plus élevée

Table 6.3 – Modèles prioritisation clients

Pourquoi la régression logistique ?

— Classification parfaite obtenue sur toutes les classes.
— Léger, interprétable et facile à déployer.
— Performance optimale, même avec peu d’échantillons dans la classe de priorité élevée.

Figure 6.3 – Logistic Regression - client

6.4.3 Évaluation

La matrice de confusion, dans figure 6.3, pour la régression logistique n’a révélé aucune erreur
de classification :

Tous les indicateurs (précision, rappel, score f1) étaient de 1,00 pour toutes les classes, démon-
trant la robustesse du modèle et son adéquation au déploiement en production.
6.4 Préparation des données, modélisation et évaluation 66

Figure 6.4 – Decision Tree - client

Figure 6.5 – Random Forest - client

Figure 6.6 – SVM - client

6.4 Préparation des données, modélisation et évaluation 67

Figure 6.7 – KNN - client

Figure 6.8 – Gradient bOOSTING - client

6.5 Architecture 68

6.5 Architecture

Sprint 4, dans la figure 6.9, a introduit un workflow qui recentre l’analyse des factures sur
l’analyse des données clients, permettant ainsi un marketing ciblé basé sur la valeur client.

Composants clés :

1. Classificateur client (régression logistique) : analyse le comportement client (historique

de dépenses, fréquence, récence) pour attribuer un niveau de priorité : faible, moyen ou
élevé.
2. Générateur de stratégie LLM : en fonction de la priorité du client, une stratégie marketing
sur mesure est générée automatiquement (par exemple, récompenses de fidélité, remises,
offres d’engagement).
3. Couche de sortie : résultats structurés contenant le niveau de priorité du client et la
stratégie générée, prêts à être utilisés dans de futures campagnes ou systèmes CRM.

Figure 6.9 – Diagramme sprint 4

6.6 Réalisation 69

6.6 Réalisation

6.6.1 Workflow

Le workflow, dans figure 6.10, implémenté suit la logique suivante :

1. Entrée : Caractéristiques transactionnelles client issues de la base de données.

2. Priorisation : Un modèle de régression logistique entraı̂né classe le client comme étant
faible, moyen ou élevé.
3. Génération de la stratégie : En fonction de la priorité, une invite est créée et transmise
à un modèle de langage (par exemple, DeepSeek ou OpenAI). Exemple :
— Priorité élevée → Client fidèle, offrez 15% de réduction et un accès anticipé exclusif.
— Priorité moyenne → Envoyer une offre de suivi pour encourager les achats fréquents.
— Priorité faible → Suggérer des articles connexes ou des incitations pour le retour.
4. Sortie : Le niveau de priorité et la stratégie marketing personnalisée comme dans figure
6.11.

Figure 6.10 – Workflow suivi client

6.7 Conclusion

Le Sprint 4 a marqué l’aboutissement du projet en intégrant l’intelligence client au système.

Grâce à la priorisation basée sur le Machine Learning et à la génération dynamique de stratégies,
6.7 Conclusion 70

Figure 6.11 – Output workflow suivi

le système prend désormais en charge le marketing ciblé, aidant ainsi les entreprises à concentrer
leurs efforts sur les clients à forte valeur ajoutée tout en améliorant la fidélisation sur tous les
segments.

Ce sprint a permis :
— Un pipeline complet, des données client brutes à la stratégie exploitable ;
— Un modèle de Machine Learning précis et interprétable ;
— Une génération de texte adaptative grâce aux LLM pour le marketing contextuel.
Ce module ouvre la voie à de futurs travaux sur l’engagement personnalisé, les tests A/B de
stratégies et l’automatisation des campagnes.
Conclusion Générale

e projet a permis de mettre en place un système de gestion des factures et des clients
C intelligent et entièrement intégré, exploitant l’IA pour rationaliser les flux financiers et
améliorer la prise de décision. De l’extraction de données à la détection des fraudes, en passant
par la communication personnalisée et l’engagement client, chaque composant a été conçu
comme un agent réutilisable, facilitant ainsi l’extension et l’adaptation de la plateforme.

Principales réalisations :
— Extraction automatisée des données de facturation grâce à des agents OCR (PaddleOCR,
AWS Textract, GCP Vision).
— Classification intelligente des factures et des clients grâce à des modèles de machine
learning (forêt aléatoire, régression logistique).
— Génération de contenu personnalisé grâce à des agents LLM (DeepSeek, OpenAI).
— Validation en temps réel des informations financières et juridiques (SIRET, IBAN) grâce
à des agents de scraping.
En combinant des flux de travail structurés, des modèles précis et des agents modulaires, la
plateforme offre une base solide pour la création de solutions d’IA évolutives, adaptées aux
opérations financières et CRM des entreprises.

Ce projet a non seulement amélioré l’écosystème technique de Navinspire IA, mais a également
démontré les avantages pratiques du déploiement d’agents d’IA dans des environnements low-
code. Les améliorations futures pourraient impliquer l’intégration de boucles de rétroaction des
utilisateurs, la prise en charge d’analyses en temps réel ou l’extension du système à des contextes
multilingues et multidevises.

71
Netographie

PaddleOCR : https ://[Link]/PaddlePaddle/PaddleOCR

Google Cloud Vision API : https ://[Link]/vision/docs

AWS Textract : https ://[Link]/textract/

Twilio SMS API : https ://[Link]/docs/sms

scikit-learn ML models : https ://[Link]/stable/

LangChain documentation : https ://[Link]

MongoDB documentation : https ://[Link]/docs/

72