Rapport de Stage PFE -Conception et Implémentation d'une Solution de Business Intelligence

Conception et Implémentation d'une Solution de
Business Intelligence et de Machine Learning
pour l'Analyse des Données Opérationnelles.
(Cas de l'ERP Sage 100c chez DEWEB Technologies)

1. Université Abdelmalek Essaâdi
École Normale Supérieure
Département : Mathématique, Informatique et science Physiques


Filière : Master Spécialisé - Science des Données pour l’Éducation

Rapport du Projet de Fin d’Etude








Réalisé par :
Elhocine ABOUALI

Soutenu le 26/07/2025

Jury:
Ahmed Bendahmane ENS Martil President
ENS Martil
ENS Martil


Année universitaire : 2024-2025
Conception et Implémentation d'une Solution de
Business Intelligence et de Machine Learning
pour l'Analyse des Données Opérationnelles.
(Cas de l'ERP Sage 100c chez DEWEB Technologies)

2. Remerciement


Après avoir rendu grâce à Dieu le tout puissant et le miséricordieux, qui m’a donné la force et la
persévérance d’accomplir ce modeste travail. Je tiens à exprimer ma gratitude et mes vifs
remerciements à tous ceux qui m’ont aidé à réaliser ce stage dans des conditions favorables, à tous
ceux qui n’ont cessé de me prodiguer leurs conseils et encouragements à travers ces lignes :

Tout d'abord, nos plus sincères remerciements vont à nos parents qui nous ont toujours encouragés
dans la poursuite de nos études, ainsi que pour leur aide, leur compréhension et leur soutien. De plus,
nous les remercie pour leurs généreux conseils.

Nos remerciements à Mr. Iliass JOUDAT le directeur de l’entreprise DEWEB Technologie, et Mr Hamza
SOUIHEL mon encadrant professionnelle pour sa supervision chaleureuse, ainsi que pour sa patience
et ses précieux conseils qui été plus qu’un maitre de stage, il nous a guidé, critiqué, fait des suggestions,
nous le remercions vivement pour tout.

Nous profitons également une fois de plus de présenter notre profonde gratitude et nos sincères
remerciements à notre encadrant universitaire Mr. Ahmed BENDAHMANE, pour ses précieux conseils
qui nous ont accompagnés tout long des étapes de réalisation de ce projet, et nous le remercions pour
tout.

Mes vifs remerciements vont également aux membres du jury pour son grand honneur en acceptant
de juger ce travail. Je tiens également à remercier tous mes enseignants de Ecole Normal Supérieure
de Tétouane plus précisément Mr Mohammed Lamarti Sefian , Mr Abdellatif El Afia ,et Mr Outman
El Hichami de leurs connaissances, leurs encouragements et leurs orientations si précieuses tout au
long de ma formation.

Je voudrais exprimer ma reconnaissance envers à mes camarades de la promotion 2024/2025 que j’ai
servis avec humilité et avec lesquels j’ai passé une scolarité exceptionnelle, riche d’enseignements, et
d’expériences de rencontres. Je veux ici dire ma sincère amitié.

Nous tenons à remercier toute l’équipe pédagogique et administratif de l’école Normal supérieure de
Tétouane, nous les remercier pour la qualité de l’information reçue durant tout la période que nous
avons passé au sein de cette école.
Mes remerciements vont enfin à toute personne qui a contribué de près ou de loin à l’élaboration de
ce projet.

3. Dédicace

Je dédie ce travail à :


A mes très chers parents

Dont leurs mérites, leurs sacrifices, leurs qualités humaines m’ont permis de vivre ce jour : Les
mots me manquent pour exprimer toute la reconnaissance, la fierté et le profond amour que
je vous porte pour les sacrifices qu’ils ont consentis pour ma réussite, qu’ils trouvent ici le
témoignage de mon attachement ma reconnaissance, gratitude et respect, que dieu leur
préservent bonne santé et longue vie. Tous mes sentiments de reconnaissance pour vous.

A mon frère
J’espère atteint le seuil de tes espérances. Que ce travail soit l’expression de ma profonde affection
Je te remercie pour le soutien moral et l’encouragement que tu m’as accordés. Je te souhaite tout le
bonheur que tu mérites.

A ma famille
Que je ne pourrais nommer de peur d‘en oublier mon attachement et mes affections les plus Sincères,
A tous les membres de ma famille ABOUALI, petits et grands. Je ne trouverais pas les mots pour vous
exprimer mon affection et mon estime envers vous. Je vous souhaite tous bonheur et sante.

A mes ami(e) s
A tout ceux qui ont su m’apporter aide et soutien aux moments propices, Je dédie ce travail,
reconnaissant et remerciant chaleureusement

4. Résumé

Dans un environnement hautement concurrentiel, le stage actuel chez DEWEB Technologies visait à
traiter une question stratégique essentielle : exploiter le potentiel des données de l'entreprise pour
améliorer la performance. L'observation première mettait en évidence l'abondance d'informations
présentes dans l'ERP Sage 100c, cependant sous-utilisée à cause de sa structure transactionnelle
compliquée, ce qui restreint la prise de décision à une analyse souvent réactive et manuelle. Le défi
était donc d’exploiter ces données brutes en un avantage compétitif concret.

Ainsi, notre approche a impliqué la conception et l'implémentation d'une solution décisionnelle
intégrale. Initialement, un flux de données a été établi en utilisant Talend Open Studio pour
l'extraction, la transformation et le chargement des informations provenant de la base SQL Server de
l'ERP. Après avoir été nettoyées et organisées selon un schéma en étoile, ces données ont été
consolidées dans un entrepôt de données (Data Warehouse) en utilisant PostgreSQL. La délivrance a
ensuite été réalisée grâce à l'élaboration de tableaux de bord interactifs sur Power BI, facilitant un suivi
détaillé des ventes, des clients, des fournisseurs et des stocks.

De plus cette approche descriptive, le projet a exploré la capacité de prédiction des données. Cinq
modèles ont été développés à l'aide de Python et de ses bibliothèques d'apprentissage automatique,
afin de répondre à des besoins professionnels particuliers, tels que la prévision des ventes futures, la
segmentation RFM des clients ou encore la détection anticipée des retards de paiement.

En En conclusion, ce projet a fourni à DEWEB Technologies un véritable instrument d'aide à la décision,
centralisé et efficace. Il donne aux équipes la liberté d'explorer les données et facilite le passage d'une
gestion réactive à une stratégie proactive, ancrée dans des indicateurs précis et des analyses
prédictives hautement bénéfiques.

5. Abstract

This internship project, conducted at DEWEB Technologies, was designed to address a key strategic
issue in a highly competitive market: leveraging the company's data assets to create a tangible
advantage. The initial assessment revealed a wealth of valuable information within the company's Sage
100c ERP. However, this data was siloed in a complex, transaction-oriented system, limiting decision-
making to slow, manual, and reactive analysis. The core problem was therefore how to transform this
raw data into actionable, strategic intelligence.

To address this challenge, our approach consisted of designing and implementing an end-to-end data
solution. A data pipeline was first built using Talend Open Studio to extract, transform, and load
information from the ERP's SQL Server database. This clean data, structured according to a star
schema, was then consolidated into a robust Data Warehouse hosted on PostgreSQL. This data
foundation supported the creation of dynamic dashboards in Power BI, providing clear insights into
sales, customers, inventory, and suppliers.

Moving beyond descriptive analytics, the project also explored the predictive potential of the data.
Using Python and its Machine Learning libraries, five models were developed to tackle specific business
needs, including sales forecasting, RFM-based customer segmentation, and the prediction of payment
delays.

Ultimately, this project has equipped DEWEB Technologies with a powerful decision-support tool,
creating a single source of truth. It empowers business teams with self-service analytics and enables a
fundamental shift from reactive management to a proactive, data-driven strategy, built on reliable
metrics and forward-looking, predictive insights.

6. Table des matières
Introduction Générale ................................................................................................................ 12
Chapitre 1 : Contexte Générale Du Projet ................................................................................... 13
1 Introduction : ................................................................................................................................ 13
2 Présentation de l’entreprise d’accueil : ....................................................................................... 13
2.1 Présentation générale de DEWEB Technologie : ....................................................................... 13
2.2 Domaines d‘activités : ............................................................................................................... 13
2.3 Fiche technique de l’entreprise: ................................................................................................ 14
2.4 Organigramme de l’entreprise : ................................................................................................ 14
3 Cadre de projet : ........................................................................................................................... 15
3.1 Problématique de stage : .......................................................................................................... 15
3.2 Analyse de l'existant : L'ERP Sage 100c et ses limites analytiques : .......................................... 15
3.3 Solution proposée : Architecture BI et Machine Learning : ...................................................... 16
3.4 Objectifs du stage : .................................................................................................................... 16
4 Spécification des besoins : ............................................................................................................ 17
4.1 Besoin fonctionnels : ................................................................................................................. 17
4.2 Besoin non fonctionnels : .......................................................................................................... 18
5 Méthodologie et planification du projet : ................................................................................... 18
5.1 Méthodologie de travail : .......................................................................................................... 18
5.2 Planification prévisionnelle (diagramme de Gantt) : ................................................................ 19
6 Conclusion de chapitre : ............................................................................................................... 20
Chapitre 2 : Concepts Théoriques & État de l’Art ................................................................................ 21
1 Introduction : ................................................................................................................................ 21
2 Concepts Généraux de la BI : ........................................................................................................ 21
2.1 Historiques de l’informatique décisionnelles : .......................................................................... 21
2.2 Définition de l’informatique décisionnelle : .............................................................................. 22
2.3 Principes de l’informatique décisionnel (pourquoi la BI ?) : ..................................................... 22
2.4 Objectif de l’informatique décisionnel : .................................................................................... 22
2.5 Architecture d’un système décisionnel : ................................................................................... 23
3 System ERP Sage 100c : ................................................................................................................ 24
3.1 Définition : ................................................................................................................................. 24
3.2 Sage 100c dans le contexte BI : ................................................................................................. 24
4 OLAP VS OLTP : ............................................................................................................................. 25
5 Le processus ETL (Extract, Transform, Load) : .............................................................................. 26
6 L'entrepôt de données (Data Warehouse) : ................................................................................ 27

7. 6.1 L’objectif de l’entrepôt de données : ........................................................................................ 27
6.2 Modélisation d’un entrepôt de données: ................................................................................. 27
7 Introduction aux modèles de Machine Learning utilisés : .......................................................... 29
7.1 Apprentissage supervisé : Classification & Regression : ........................................................... 29
7.2 Apprentissage non supervisé : ( Clustering ) ............................................................................. 29
8 Conclusion du chapitre : ............................................................................................................... 30
Chapitre 3 : Conception et modélisation : ........................................................................................... 31
1 Introduction : ..................................................................................................................................... 31
2 Architecture globale de la solution : ............................................................................................ 31
3 Conception du Data Warehouse sur PostgreSQL : ...................................................................... 32
3.1 Identification des axes d'analyse et des indicateurs de performance : .......................................... 32
3.2 Identification des Tables :.......................................................................................................... 33
3.3 Identification des Data Mart : ......................................................................................................... 40
3.3.1 Data Mart par domaine (Clients) : ........................................................................................ 40
3.3.2 Data Mart par domaine ( Ventes ) : ...................................................................................... 41
3.3.3 Data Mart par le domaine (Stock) : ..................................................................................... 42
3.3.4 Data Mart par le domaine (Fournisseurs): ........................................................................... 43
4 Conclusion du Chapitre : .................................................................................................................... 44
Chapitre 4 : Réalisation et mise en œuvre (ETL, BI, ML) ..................................................................... 45
1 Introduction : ..................................................................................................................................... 45
2. Environnement de développement et outils : ................................................................................. 45
2.1. Outil ETL : Talend Open Studio : ..................................................................................................... 45
2.2 SGBD pour le DWH : PostgreSQL : ................................................................................................... 46
2.3 SQL Server Management Studio ( Source de donneés ERP de sage 100C) : ................................... 46
2.4 Outil de restitution : Microsoft Power BI : ...................................................................................... 47
2.5 VSCode, Jupyter et Python: ............................................................................................................. 48
3 Implémentation des flux ETL : ...................................................................................................... 49
3.1. Extraction des données de Sage 100c (SQL Server) : ..................................................................... 49
3.2. Transformation des données avec le composant tMap : ............................................................... 50
3.3 : Exemple d’un job complet : ........................................................................................................... 51
4 Mise en œuvre de la restitution avec Power BI : ......................................................................... 52
4.1. Connexion au Data Warehouse ( Postgre SQL ) : ........................................................................... 52
4.2. Création des tableaux de bord (Ventes, Clients, Fournisseurs, Stocks) : ....................................... 53
5. Implémentation des Modèles de Machine Learning : ..................................................................... 58
6 Conclusion du Chapitre : .................................................................................................................... 72
CONCLUSION GÉNÉRALE....................................................................................................................... 73

8. Liste des figures

Figure 2.1 : Logo d’organisme d’accueil DewebTechnologie ................................................................ 13
Figure 2.4 : L’organigramme de l’entreprise DEWEBTechnologie ....................................................... 14
Figure 5.2 : Planification du projet avec diagramme de Gantt ............................................................. 19


Figure 2.1 : Historique de l’informatique décisionnelle ....................................................................... 21
Figure 2.5 – Architecture d’un système décisionnel ......................................................................... 23
Figure 3.1 : Logo de ERP Sage100c ....................................................................................................... 24
Figure 4 : OLTP Vs OLAP ...................................................................................................................... 25
Figure 5 : Processus ETL (Extract, Transform, Load) ............................................................................. 26
Figure 6.2 : Le Modèle en étoile ............................................................................................................ 28
Figure 6.2 : Le modèle en Flocon........................................................................................................... 28


Figure 2 : Architecture globale de la solution ....................................................................................... 31
Figure 3.3.1 : Schéma en étoile pour DataMart Clients ........................................................................ 40
Figure 3.3.2 : Schéma en étoile pour DataMart Ventes ........................................................................ 41
Figure 3.3.1 : Schéma en étoile pour DataMart Stocks ......................................................................... 42
Figure 3.3.2 : Schéma en étoile pour DataMart Fournisseurs ............................................................... 43


Figure 4.2.1 : Logo logiciel Talend ETL ................................................................................................... 45
Figure 4.2.2 : Logo du SGBD PostgreSQL ............................................................................................... 46
Figure 4.3.3 : Logo du SQL Server Management Studion (SSMS) ......................................................... 46
Figure 4..2.3 – Les outils majeurs de Power BI ...................................................................................... 47
Figure 4.2.3 : Les fonctionnalités de Power BI ..................................................................................... 47
Figure 4.2.3 : Logo du Power BI ............................................................................................................. 47
Figure 4.2.4 : Logo du Jupyter & VsCode .............................................................................................. 48
Figure 4.2.4 : Logo du Langage Python ................................................................................................. 48
Figure 4.3 : Les jobs ETL réaliser via Talend ......................................................................................... 49
Figure 4.3.1: Configuration de le Composant tDBinput(MS SqlServer) ................................................ 49
Figure 4.3.2 : Composant tMap pour montrant les flux d’entrée (Row1) et de sortie(out_COMPTET) .. 50

9. Figure 4.3.3 : Le composant tDBOutput( PoStgre SQL) ......................................................................... 50
Figure 4.3.3 : Exemple du job Talend Complet ..................................................................................... 51
Figure 4.2: Tableau de bord des Ventes, Clients, Stocks, Fournisseurs ................................................ 52
Figure 5.1 : Chiffres d’affaires mensuel ................................................................................................. 59
Figure 5.1 : La décomposition saisonnière du signal ............................................................................. 59
Figure 5.1 : Prédiction vs Réel ( Model Test ) ........................................................................................ 60
Figure 5.1 : Projection sur 12 mois à venir ............................................................................................ 60
Figure 5.2 : Choix de Nombre optimal K ............................................................................................... 62
Figure 5.2 : Visualisation des clusters.................................................................................................... 63
Figure 5.6 : Matrice de Confusion ..................................................................................................... 66

10. Liste des tableaux
Tableau 1: Fichier technique Deweb Technology ................................................................................. 14
Tableau 3.1 : Les axes d'analyse et des indicateurs de performance .................................................. 32
Tableau 3.2 : Les tables principale par domaine ................................................................................... 33
Tableau 3.2 : La table F_COMPTET sous ERP Sage100C ........................................................................ 33
Tableau 3.2 : La table F_ARTFOURNISS sous ERP Sage100C ................................................................. 34
Tableau 3.2 : La table F_DOCENTETE sous ERP Sage100C .................................................................... 34
Tableau 3.2 : La Table F_DOCLIGNE sous ERP Sage100C ...................................................................... 35
Tableau 3.2 : La table F_DOCREGLE sous ERP Sage100C ...................................................................... 35
Tableau 3.2 : La table F_ARTICLE sous ERP Sage100C ........................................................................... 36
Tableau 3.2 : La table F_ARTSTOCK sous ERP Sage100C ....................................................................... 36
Tableau 3.2 : La table F_DEPOT sous ERP Sage100C ............................................................................. 37
Tableau 3.2 : La table F_FAMILLE sous ERP Sage100C .......................................................................... 37
Tableau 3.2 : La table F_ECRITUREC sous ERP Sage100C ...................................................................... 38
Tableau 3.2 : La table F_CREGLEMENT sous ERP Sage100C .................................................................. 39
Tableau 3.2 : La table F_REGLEMENTT sous ERP Sage100C .................................................................. 39
Tableau 5.1 : série du chiffre d'affaires journalier 2017/2018/2019 .................................................... 58
Tableau 5.2 : séries mensuelles de chiffres d’affaires 2017/2018/2019 .............................................. 59
Tableau 5.1 : Résultats du Projection sur 12 mois à venir .................................................................... 61
Tableau 5.2 : Table pour Les données de transactions des clients 2017/2018/2019 ........................... 61
Tableau 5.2 : Tableau pour le modèle RFM des clients ( 147 Clients en Total ) ................................... 62
Tableau 5.2 : Conclusion et Recommandations du résultats du modèle ............................................. 64
Tableau 5.3 : Table des ventes moyennes pour chaque Article ........................................................... 65
Tableau 5.3 : Fusion des données pour les trois source de données .................................................... 65
Tableau 5.4 : Les données des factures 2017/2018/2019 .................................................................... 67
Tableau 5.4 : résultats et Interprétations ............................................................................................. 68
Tableau 5.5 : l'historique des ventes pour les clients ........................................................................... 69

11. Liste des Abréviations

BI Business Intelligence
DAX Data Analysis Expressions.
DW Data Warehouse.
ETL Extract Transform Load.
KPI Key Performance Indicator.
SID Système d’Information décisionnelle.
SQL Structured Query Language.
SSMS SQL Server Management Studio.
OLAP Online Analytical Processing
OLTP Online Transaction Processing
ERP Enterprise Resource Planning
DIM Table de Dimension
Fait Table de Fait
ML Machine Learning
PME Petite et Moyenne Entreprise

12. Introduction Générale


Dans le contexte de la digitalisation, les entreprises se trouvent dans un environnement de plus en
plus concurrentiel où la gestion de l'information s'est imposée comme un élément déterminant pour
réussir. Souvent décrites comme le nouvel or noir, les données constituent un atout stratégique de
première importance. Néanmoins, leur importance ne découle pas de leur simple accumulation, mais
de la possibilité de les convertir en savoir exploitable pour faciliter la prise de décisions, améliorer les
procédures et prévoir les évolutions à venir. L'informatique décisionnelle et ML, deux domaines qui
facilitent la transformation des données brutes en intelligence stratégique, s'inscrivent dans ce
paradigme.

Notre stage de fin d'études a eu lieu dans ce cadre précis, au sein de la société DEWEB Technologies,
qui travaille dans le domaine de l’informatique. À l'instar de nombreuses entreprises, DEWEB
Technologies utilise un système de gestion intégré (ERP), spécifiquement Sage 100c, pour gérer ses
opérations quotidiennes. Ce système regroupe un volume important d'informations opérationnelles
essentielles liées aux ventes, à la clientèle, aux fournisseurs et à la gestion des stocks, qui sont
conservées dans une base de données SQL Server.

Cependant, bien que cet environnement soit idéalement configuré pour les transactions quotidiennes,
il expose rapidement ses contraintes lorsqu'il est question de réaliser des analyses détaillées et
globales. Les informations sont fréquemment compartimentées, leur organisation complexe rend les
analyses lentes et laborieuses, et l'accès direct à la base de production peut mettre en péril l'efficacité
des opérations quotidiennes. Devant cette situation, l'entreprise a manifesté une nécessité précise :
acquérir des outils efficaces pour tirer parti de ce réservoir de données et en dégager des indicateurs
clés de performance (KPIs) significatifs ainsi que des analyses prédictives.

Notre projet a été centré sur plusieurs buts essentiels. Le 1 objectif était de concevoir et de mettre en
œuvre une architecture décisionnelle intégrale, débutant par réalisation d'un processus ETL solide à
l'aide de l'outil Talend Open Studio. Grâce à cet ETL, un entrepôt de données centralisé et optimisé sur
PostgreSQL a été alimenté. Dans cette optique consolidée, le second but était d'élaborer des tableaux
de bord interactifs et dynamiques grâce à Power BI, pour offrir aux gestionnaires une perspective claire
et actualisée de l'activité. En fin de compte Rendons-nous également compte que ce projet cherchait
à dépasser l'analyse descriptive en mettant en lumière le potentiel prédictif des données à travers la
mise en œuvre de plusieurs modèles de ML, allant accounting for la prévision des ventes et la
segmentation de la clientèle.

Ce rapport détaillera l'ensemble de la démarche adoptée pour mener à bien cette mission. Le 1
chapitre traitera de l'exposition du contexte du projet ainsi que de l'état actuel des concepts
théoriques utilisés. Le chapitre 2 décrira minutieusement l'architecture de la solution, ainsi que la
démarche et les décisions technologiques prises. Le chapitre 3 détaillera de manière précise les étapes
de mise en œuvre, allant de l'établissement des flux ETL à l'élaboration des modèles prédictifs. Pour
conclure, le dernier chapitre fournira une étude des résultats atteints, les bénéfices du projet pour la
société, et les possibilités de développement futur de cette solution.

13. Chapitre 1 : Contexte Générale Du Projet
1 Introduction :

Ce chapitre introductif a pour vocation de mettre le projet dans son contexte, à commencer par
présenter l’organisme d’accueil DEWEB Technologie, puis présenter le cadre de la mission la
problématique, l'analyse de l'existant et la solution proposée.

Enfin, il détaillera les besoins fonctionnels et non fonctionnels qui ont servi de cahier des charges, ainsi
que la méthodologie de projet utilisée pour la planification des travaux.

2 Présentation de l’entreprise d’accueil :

2.1 Présentation générale de DEWEB Technologie :

DEWEB TECHNOLOGY est une PME marocaine (SARL) basée dans la zone industrielle Tassila à Agadir.
Active depuis 2006, elle est dirigée par Iliass JOUDAT et se spécialise dans la distribution, intégration
et maintenance de systèmes de sécurité (vidéosurveillance, détection, contrôle d’accès…), ainsi que
de solutions informatiques et télécom.
Grâce à une double expertise fonctionnelle et technologique dans les domaines de la réseau et
télécom, ce groupe a déjà mené plus de 90 projets à succès. Il propose à ses clients des solutions
innovantes, élaborées par une équipe cumulant plus de 15 ans d’expérience et disposant de références
solides dans le secteur des technologies et services de l’information.







Figure 2.1 : Logo d’organisme d’accueil

2.2 Domaines d‘activités :

Consulting : Accompagnement stratégique et opérationnel dans l’optimisation des infrastructures, des
réseaux et télécommunications.

Réseau et Télécommunication : Mise en place et maintenance des réseaux informatiques et
téléphoniques

Développement : Création de produits et proposer des solutions informatiques sur mesure
(applications Mobile, outils métiers, plateformes web)

Importation & vente : Distribution de matériel informatique, équipements de téléphonie et
électroniques (ordinateurs, serveurs, Routeurs, Switch).

14. 2.3 Fiche technique de l’entreprise:

Le tableau ci-dessous contient les informations principales de l'entreprise :
Nom
DEWEB TECHNOLOGY
Forme juridique
Société à Responsabilité Limitée ( SARL)
Siège social
Zone Industrielle, Tassila, Rue Essaouira N° 124 - Agadir
Téléphone 05-28-33-43-34 05-28-33-73-37
ICE 001539019000026
Capital 3 500 000 DH
Email [email protected]
Site Web Www.deweb.ma

Tableau 1: Fiche technique Deweb Technology


2.4 Organigramme de l’entreprise :

















Figure 2.4 : L’organigramme de l’entreprise DEWEBTechnologie

15. 3 Cadre de projet :

3.1 Problématique de stage :

Dans un milieu économique de plus en plus concurrentiel, l'aptitude d'une société à opérer des choix
prompts et avisés est un élément crucial pour réussir. Tout comme un grand nombre d'entreprises
actuelles, DEWEB Technologies produit chaque jour une quantité considérable de données en raison
de ses opérations commerciales, logistiques et financières. Ces données, provenant de son logiciel
intégré de gestion d'entreprise (ERP) Sage 100c, constituent une source précieuse d'informations.

Toutefois, ces informations demeurent en grande partie « inactives » : elles sont conservées dans un
système dédié aux opérations quotidiennes (génération de factures, gestion des commandes), et non
pour l'analyse stratégique. Les équipes à la tête de l'entreprise et celles qui œuvrent au quotidien sont
confrontées à un enjeu de taille : comment fournir des réponses efficientes et promptes aux
interrogations essentielles pour la gestion de l'entreprise ? Par exemple :

 Quels sont les produits qui nous rapportent?

 Comment caractériser et repérer nos clients les plus loyaux ?

 Comment prévoir les risques de pénurie sur nos articles essentiels ?

 Est-il possible de prévoir quelles factures ont le plus de chances d'être réglées en retard ?
La problématique principale de ce stage s'énonce alors comme suit :
La problématique principale posée dans le cadre de ce stage est la suivante :
Comment exploiter les volumes de données opérationnelles générées par l'ERP Sage 100c,
actuellement sous-exploité, en un levier de performance stratégique permettant un pilotage proactif
et des prises de décisions éclairées et intelligentes pour l'entreprise DEWEB Technologies ?
3.2 Analyse de l'existant : L'ERP Sage 100c et ses limites analytiques :

Le système d'information principal de « DEWEB Technologies » est basé sur l'ERP Sage 100c Gestion
Commerciale, avec ses données stockées dans une base de données SQL Server. Cet instrument est
efficace et solide pour le traitement des transactions de tous les jours. Il assure la consistance des
transactions commerciales, de l'achat à la facturation et à la comptabilité.
Toutefois, pour répondre aux besoins d'analyse et de gestion évoquées plus tôt, ce système présente
plusieurs limites inhérentes :
Optimisation pour la Transaction (OLTP) : La structure de la base de données de l'ERP est de type OLTP
(Online Transaction Processing).
Performance : L'exécution de requêtes d'analyse intensives directement sur la base de production
pourrait indubitablement entraver le fonctionnement quotidien des utilisateurs de l'ERP.
Complexité et Accessibilité des Données : Le modèle de données d'un ERP est souvent complexe,
normalisé et éclaté sur des dizaines, voire des centaines de tables.

16. Outils de Reporting Limités et absence de Capacité Prédictive : Les outils de sage 100c ne permettent
pas de créer des tableaux de bord dynamiques, interactifs et visuels et ne se prête absolument pas à
l'intégration de modèles de Machine Learning pour des analyses prédictives.
3.3 Solution proposée : Architecture BI et Machine Learning :

Face aux limites de l'existant et pour répondre à la problématique, une solution complète, s'étendant
de l'ingénierie des données à la science des données, a été proposée. L'objectif est de construire une
plateforme décisionnelle moderne, fiable et évolutive.
L'architecture de cette solution se décompose en quatre grandes étapes :
Extraction et Transformation (ETL) : Mettre en place un processus ETL avec l'outil Talend Open Studio.
Ce processus sera chargé d'extraire périodiquement les données pertinentes de la base SQL Server de
Sage 100c.
Centralisation et Stockage (Data Warehouse) : Consolider ces données transformées au sein d'un
entrepôt de données (Data Warehouse) dédié sur un SGBD PostgreSQL.
Visualisation et Reporting (Business Intelligence) : Connecter l'outil Power BI au Data Warehouse
pour développer une série de tableaux de bord interactifs.
Analyse Avancée (Machine Learning) : Exploiter les données historiques, propres et centralisées dans
le Data Warehouse pour développer et évaluer des modèles prédictifs. Avec Python (via des notebooks
Jupyter/VS Code)
Cette architecture (expliqué en détail au chapitre 3)

3.4 Objectifs du stage :

Dans le cadre de la mise en œuvre de cette solution, mon stage a été défini autour des objectifs
opérationnels suivants :
Analyser le modèle de données de Sage 100c et recueillir les besoins analytiques précis auprès des
départements métier (Ventes, Achats, Finance).
Concevoir le schéma en étoile du Data Warehouse sur PostgreSQL, en définissant les tables de faits et
de dimensions pertinentes.
Développer avec Talend Open Studio l'ensemble des flux ETL ( Extract , Transform , Load )nécessaires.
Créer sur Power BI les tableaux de bord pour le suivi des domaines clés identifiés : les ventes, les clients,
les fournisseurs et les stocks.
Implémenter et évaluer des modèles de Machine Learning répondant à des problématiques métier
concrètes, en gérant l'ensemble du processus (de la préparation des données à l'interprétation des
résultats).
Accomplir ces objectifs m'a offert l'opportunité d'appliquer et de renforcer mes compétences sur toute
la chaîne de valeur des données.

17. 4 Spécification des besoins :

Une fois la problématique et la solution globale identifiées, cette section explique les besoins
spécifiques que le projet doit respecter, Ces besoins ont été recueillis lors d'ateliers de travail avec les
responsables des pôles Ventes, Achats et Logistique de l’entreprise.
Ils se divisent en deux catégories : les besoins fonctionnels, qui décrivent ce que le système doit faire,
et les besoins non fonctionnels, qui décrivent comment le système doit le faire.

4.1 Besoin fonctionnels :

Dans le cadre de la valorisation des données issues de l’ERP Sage 100c au sein de DEWEB Technologies,
plusieurs besoins fonctionnels ont été identifiés pour répondre aux enjeux métiers des départements
commercial, financier, logistique et achats. Ces besoins ont conduit à la mise en place d’un processus
ETL via Talend Open Studio, un entrepôt de données PostgreSQL, ainsi que plusieurs tableaux de bord
décisionnels sous Power BI.
 Extraction, transformation et centralisation des données :
 Extraire les données des modules ventes, clients, fournisseurs, stocks à partir de SQL Server.
 Nettoyer et transformer ces données à l’aide de composants Talend (tMap).
 Charger les données dans une Data Warehouse (PostgreSQL) .
 Création de tableaux de bord métiers interactifs :
Tableau de bord des ventes:
 Suivre les ventes journalières avec une granularité temporelle fine (par jour, mois ou année).
 Afficher la répartition du chiffre d’affaires par famille de produits.
 Identifier le Top 10 des produits les plus vendus.
Tableau de bord des clients :
 Afficher le nombre total de clients débiteurs et le montant global en retard.
 Identifier les meilleurs clients en termes de chiffre d'affaires.
 Liste détaillée des factures non réglées avec date, client, solde restant et délai moyen de
paiement.
Tableau de bord de Stocks :
 Valorisation du Stock : Connaître la valeur financière du stock actuel.
 Rotation des Stocks : Calculer le taux de rotation des stocks pour chaque produit afin
d'identifier les produits à faible rotation ("stocks dormants").
Tableau de bord des fournisseurs:
 Analyser l’évolution mensuelle des montants réglés et restants à payer.
 Un tableau de synthèse avec montant TTC ,montant payé, montant restant, et date de facture.

18. 4.2 Besoin non fonctionnels :

Au-delà des fonctionnalités, la qualité et la robustesse de la solution sont primordiales pour garantir
son adoption et sa pérennité.

 Performance :

- Le temps de chargement et d'interaction avec les tableaux de bord Power BI ne doit pas
excéder 10 secondes pour une expérience utilisateur fluide.

 Fiabilité et Disponibilité :

- Les données affichées dans les rapports doivent être exactes et cohérentes avec la source,
garantissant la confiance des utilisateurs.

- La solution doit être disponible à 99% durant les heures ouvrables de l'entreprise.

 Évolutivité : L'architecture du Data Warehouse doit être conçue pour pouvoir intégrer
facilement de nouvelles sources de données ou de nouveaux axes d'analyse à l'avenir.

 Ergonomie : Les tableaux de bord doivent être intuitifs, visuellement clairs et faciles à prendre
en main par des utilisateurs n'ayant pas de compétences techniques avancées.

5 Méthodologie et planification du projet :

5.1 Méthodologie de travail :

Il convient de souligner que le stage s’est déroulé principalement à distance, ce qui a influencé
l’organisation du travail au quotidien. Bien qu'aucune approche formelle de gestion de projet (comme
le Scrum ou le Kanban) n'ait été suivie strictement, une bonne coordination a été assurée par les
éléments suivants :

 Des réunions de suivi régulières ont été organisées à distance via Google Meet, avec mon
encadrant pour faire le point sur l’avancement du projet, discuter des blocages éventuels et
définir les priorités à venir.

 La communication s’est faite de manière asynchrone et réactive par e-mail, permettant une
grande flexibilité tout en assurant un bon suivi du projet.

 Cette organisation a permis de maintenir une dynamique de travail autonome, tout en
bénéficiant d’un encadrement efficace et pertinent.
Ce mode de travail, a permis de respecter la planification globale du projet et d’atteindre les objectifs
fixés dans les délais impartis.

19. 5.2 Planification prévisionnelle (diagramme de Gantt) :

Le stage s'est déroulé sur une période de 6 mois. La planification a été matérialisée par un diagramme
de Gantt dont les grandes phases sont les suivantes :


Figure 5.2: Planification du projet avec diagramme de Gantt

20. 6 Conclusion de chapitre :

Ce premier chapitre a établi les bases du projet. Nous avons introduit la société DEWEB Technologies,
exposé le principal enjeu lié à l'utilisation insuffisante de ses données et examiné les contraintes de
son système en place. En conséquence, nous avons conçu une solution complète et détaillé les
exigences attendues, à la fois fonctionnelles et non-fonctionnelles. Pour conclure, la gestion du projet
et sa planification ont été détaillées.
Avec cette base bien définie, nous sommes maintenant en mesure de traiter les éléments plus
techniques.
Le chapitre suivant sera consacré à l'étude des concepts théoriques et de l'état de l'art qui sous-
tendent l'informatique décisionnelle et le Machine Learning, indispensables à la bonne compréhension
des choix de conception et de développement qui seront présentés par la suite

21. Chapitre 2 : Concepts Théoriques & État de l’Art
1 Introduction :

Après avoir défini dans le premier chapitre le contexte, la problématique et les objectifs de notre
projet, ce deuxième chapitre a pour but de poser les fondations théoriques indispensables à sa
compréhension. Pour mener à bien une transformation de la donnée brute en information stratégique,
il est nécessaire de s'appuyer sur des concepts et des architectures éprouvées.
Nous aborderons donc les deux piliers de notre étude. D'une part, l'informatique décisionnelle
(Business Intelligence), en détaillant son architecture, le processus central d'ETL et les principes de
modélisation d'un entrepôt de données. D'autre part, nous introduirons les concepts de Machine
Learning qui ont été appliqués pour enrichir l'analyse et créer des modèles prédictifs.

2 Concepts Généraux de la BI :

2.1 Historiques de l’informatique décisionnelles :

Les données au sein des entreprises ne cessent d’augmenter et la charge de travail ainsi que la
complexité´ des structures de données devient trop importante. Devant cette problématique, des
applications de collecte des données ont été´ mis en place à la fin des années 60 et les années 70
respectivement les bases de données et les 1 ers tableurs minimalistes : Excel.
Dans les années 80, les entrepôts de données sont apparus pour répondre aux besoins des utilisa-
tueurs de faire des analyses multidimensionnelles en leur permettant a` la fois un meilleur accès et
une meilleure gestion des bases de données.
Les besoins d’analyse ne cessent d’évoluer et les technologies continuent à se progresser, ce qui
exige la naissance de la Business intelligence en 1989 par l’informaticien « Howard Dresner ».







FIgURe 2.1 : Historique de l’informatique décisionnelle

22. 2.2 Définition de l’informatique décisionnelle :

Un système d’information décisionnel est défini comme étant ” un regroupement de données
orientées vers certains sujets, intégrées, dépendantes du temps, non volatiles, ayant pour but d’aider
les gestionnaires dans leurs prises de décision.” Bill Inmon,1996]
En effet, les SID ont pour mission de supporter la prise de décision et d’avoir une vue d’ensemble sur
l’activité´ d’une entreprise a` l’aide des tableaux de bord et des outils de pilotages qu’ils produisent et
permettre à une entreprise de prendre des décisions métier plus efficaces.
2.3 Principes de l’informatique décisionnel (pourquoi la BI ?) :

 Les systèmes transactionnels ne sont pas adaptés.
 Répondre aux questions des décideurs.
 Comprendre et analyser les données stockées.
 Centraliser et normaliser les données.
 Source unique d’information pour les décideurs.
 Disposer de données déjà consolidé pour prendre des décisions.
 Mesurer le résultats d’une activité ou d’une prise de décision.
 Mettre à disposition des utilisateurs finaux des données facilement exploitables.

2.4 Objectif de l’informatique décisionnel :

La plupart des entreprises disposent d’un volume important de données réparties à travers des bases
de données et des systèmes transactionnels distribués. Ces bases de données et systèmes sont
généralement conçus pour des opérations spécifiques ou pour des opérations de traitement.
Cependant, ce que ces bases de données et systèmes ne sont pas conçus pour faire, c’est de
communiquer entre eux, et de permettre aux utilisateurs de consulter des données d’une manière
non-usuelle, ou de fournir des analyses de données de haut niveau à des instants précis.
Les objectifs principaux de l’informatique décisionnelle sont, en fait, de combler ce vide et de fournir
ces capacités :
 La facilité de consulter en une seule vue des données provenant de diverses sources.
 La facilité d’obtenir rapidement des analyses de données provenant de différents systèmes.
 La facilité d’examiner des données réparties sur le temps.
 La facilité de générer des scénarios de simulation et d’obtenir des réponses basées sur des
données historiques
Une conception bien étudiée et une mise en œuvre réussie d’une solution d’informatique décisionnelle
peuvent rapidement générer un retour sur investissement fort intéressant qui est sans aucun doute
un facteur que les dirigeants d’entreprise apprécient.

23. 2.5 Architecture d’un système décisionnel :
Un système décisionnel est composé de différents phases que nous pouvons également les modéliser de
la manière suivante :

 Plusieurs sources de données en lecture.
 Un entrepôt de données fusionnant les données requises.
 Un ETL permettant d’alimenter l’entrepôt de données à partir des données existantes.
 Des magasins de données permettant de simplifier l’entrepôts de données.
 Des outils de visualisations données pour présenter l’étude aux utilisateurs finaux et décideurs.

La figure ci-dessous permet de connaitre le positionnement de chacun de ces éléments :








FIgURe 2.5 : Architecture d’un système décisionnel

Après avoir exposer l’architecture globale d’un système décisionnel, il serait intéressant de mieux
expliquer ses composants :
Source : Il s'agit de l'ensemble des systèmes opérationnels de l'entreprise qui produisent et stockent
les données brutes. Cela inclut les ERP (comme Sage 100c), les CRM, les fichiers plats (Excel, CSV), les
bases de données de production, etc.
La Zone d'Intégration (ETL) : C'est le cœur du réacteur. Un processus, généralement assuré par un outil
ETL (Extract, Transform, Load) comme Talend, se charge d'extraire les données des sources, de les
transformer (nettoyage, mise en conformité, enrichissement) et de les charger dans la zone de
stockage.
La Zone de Stockage (Data Warehouse) : C'est un référentiel central où les données consolidées,
nettoyées et historiées sont stockées. L'entrepôt de données (Data Warehouse) est la base de tout le
système. Il est parfois complété par des magasins de données (Data Marts), qui sont des sous-
ensembles du Data Warehouse, spécialisés pour un métier précis (Ventes, Finance, etc.).
La Zone de Restitution : C'est la couche visible par l'utilisateur final. Elle regroupe les outils qui
permettent d'exploiter les données du Data Warehouse pour l'analyse et la prise de décision. Cela va
des rapports statiques aux tableaux de bord interactifs (comme ceux créés avec Power BI).

24. 3 System ERP Sage 100c :

3.1 Définition :

Sage 100c est un progiciel de gestion intégré (ERP — Enterprise Resource Planning) destiné aux petites
et moyennes entreprises. Il permet d’automatiser et d’unifier la gestion des processus clés de
l’entreprise tels que la comptabilité, la gestion commerciale, la paie, la trésorerie, ou encore les
immobilisations. Grâce à une base de données centralisée, Sage 100c favorise la cohérence et la
fiabilité des informations partagées entre les différents services.
Techniquement, les données de Sage 100c sont stockées dans une base de données relationnelle, qui
dans le cas de notre projet est Microsoft SQL Server. Cet ERP est modulaire et couvre plusieurs
périmètres fonctionnels clés :
 La Gestion Commerciale : Cœur des données pour notre projet, ce module contient les
informations sur les clients (F_COMPTET), les articles (F_ARTICLE), les documents de vente
(devis, commandes, factures - F_DOCENTETE et F_DOCLIGNE), etc.
 La Comptabilité : Fournit les informations sur les règlements, les échéances de paiement et la
santé financière.
 La Gestion des Stocks : Contient l'état des stocks, les mouvements d'entrée et de sortie, les
emplacements.



Figure 3.1 : Logo de Logiciel ERP Sage100c

3.2 Sage 100c dans le contexte BI :

Dans le contexte de l’informatique décisionnelle, Sage 100c constitue une source de données
opérationnelles riches, utilisées pour l’alimentation de systèmes décisionnels (data warehouse).
Cependant, les données produites par Sage sont généralement structurées pour l’exploitation
opérationnelle (modèle OLTP), ce qui nécessite une phase de transformation (via un processus ETL)
pour être exploitées dans un contexte analytique (OLAP).
L’accès aux données de Sage 100c peut se faire via des outils d’extraction compatibles (comme Talend),
permettant ainsi leur intégration dans un entrepôt de données et leur visualisation via des outils de
reporting comme Power BI.

25. 4 OLAP VS OLTP :

Dans le cadre d’un système d’information, il est essentiel de distinguer deux types de traitements de
données : OLTP (Online Transaction Processing) et OLAP (Online Analytical Processing).
Ces deux approches répondent à des besoins différents et s’appuient sur des architectures distinctes.
 OLTP : Traitement Transactionnel en Ligne :
Le modèle OLTP est conçu pour la gestion des opérations courantes d'une entreprise, telles que la
saisie de factures, la gestion des commandes, la mise à jour des stocks, etc. Il est caractérisé par :
 Un grand nombre de transactions courtes.
 Une forte normalisation des données pour éviter les redondances.
 Des temps de réponse rapides pour les écritures et mises à jour.
 Une consistance et intégrité des données strictement assurées.
Les bases de données associées aux ERP comme Sage 100c relèvent du modèle OLTP, car elles sont
conçues pour assurer la bonne exécution des processus métier au quotidien.
 OLAP : Traitement Analytique en ligne :
OLAP est destiné à la consultation, l’analyse et l’aide à la décision. Ce modèle est pour :
 L’analyse de grandes quantités de données historiques.
 La lecture intensive plutôt que l’écriture.
 La modélisation en schéma en étoile ou en flocon pour faciliter l’analyse multidimensionnelle.
 L’exécution de requêtes complexes comme des agrégations, des regroupements ou des
comparaisons temporelles.
Les systèmes OLAP sont souvent utilisés dans les entrepôts de données (Data Warehouses), où les
données sont transformées et structurées spécifiquement pour répondre à des besoins décisionnels
Complémentarité dans le cadre de la Business Intelligence
Dans un projet de Business Intelligence, comme celui mené durant ce stage, les données issues d’un
système OLTP (Sage 100c) sont extraites, transformées et chargées (ETL) dans un système OLAP
(entrepôt de données). Cela permet de les exploiter à travers des outils comme Power BI pour produire
des tableaux de bord interactifs et prendre des décisions éclairées.
Figure 4 : OLTP Vs OLAP

26. 5 Le processus ETL (Extract, Transform, Load) :

ETL, acronyme d’Extraction Transformation et Chargement, est un processus automatise´ d’intégration
des données, qui extrait l’information nécessaire à l’analyse à partir des données brutes, la transforme
en un format qui peut répondre aux besoins opérationnels et la charge dans un entrepôt de données.
Cependant, la réalisation de l’ETL est une étape très importante et très complexe parce qu’il constitue
70% d’un projet décisionnel en moyenne.

Extract (Extraction) : Cette première phase consiste à se connecter aux différentes sources de données
et à en extraire les informations pertinentes. Les défis à ce stade sont la diversité des formats (bases
de données, fichiers, API) et la nécessité de ne pas impacter les performances des systèmes de
production.

Transform (Transformation) : C'est l'étape la plus complexe et celle qui apporte le plus de valeur
ajoutée. Les données extraites sont brutes et hétérogènes ; il faut donc les transformer pour garantir
leur qualité et leur cohérence. Les transformations courantes incluent :
 Nettoyage : Gestion des valeurs manquantes, correction des erreurs.
 Standardisation : Mise en conformité des libellés (ex: "FR", "fr", "France" -> "France").
 Enrichissement : Calcul de nouveaux champs (ex: Marge = Prix de Vente - Coût d'Achat).
 Agrégation : Calcul de sommes, de moyennes sur des axes temporels ou autres.
 Mise en correspondance (Jointures) : Combinaison de données issues de différentes tables
ou sources.
Load (Chargement) : Une fois transformées, les données sont chargées dans le Data Warehouse cible.
Le chargement peut être total (on efface et on recharge tout) ou, plus fréquemment, incrémental (on
n'ajoute que les données nouvelles ou modifiées depuis le dernier chargement).









Figure 5 : Processus ETL (Extract, Transform, Load) :

27. 6 L'entrepôt de données (Data Warehouse) :

Un Data Warehouse (DWH) ou entrepôt de données est une base de données conçue spécifiquement
pour la requête et l'analyse plutôt que pour le traitement transactionnel. Selon l'un de ses pères
fondateurs, Bill Inmon, un DWH est une collection de données orientées sujet, intégrées, non volatiles
et historiées, organisées pour le support d'un processus d'aide à la décision.
6.1 L’objectif de l’entrepôt de données :

L’objectif principal des entrepôts de données est de supporter la prise de décision en permettant une
meilleure exploitation des informations des systèmes opérationnels des entreprises.
- L’entrepôt de données doit rendre les données de l’organisation accessible facilement : le contenu
de l’entrepôt de données doit être facile a` comprendre pour le simple utilisateur et pas uniquement
pour le développeur.
- L’entrepôt de données doit présenter l’information de l’organisation de manière cohérente : les
données de l’entrepôt doivent être assemblées à partir de différentes sources de l’organisation et
nettoyées et leurs qualités soient contrôlées. La cohérence implique une haute qualité´, elle suppose
aussi que l’on a tenu compte que toutes les données soient complètes.
- L’entrepôt de données doit protéger notre richesse informationnelle : l’entrepont de données doit
efficacement contrôler l’accessibilité´ aux informations confidentielles de l’organisation.
- L’entrepôt de données doit être le socle sur lequel repose l’amélioration des prises de décision : Il
doit contenir les données permettant a` étayer les décisions. En fait, ces dernières sont la valeur
ajoutée de l’entrepôt de données.

6.2 Modélisation d’un entrepôt de données:

 Les composants d’un schéma décisionnel :
Les entrepôts de données sont destinés à la mise en place des systèmes décisionnels. Ces systèmes,
devant répondre aux différents objectifs des systèmes transactionnels, ce qui met en évidence la
nécessité de s’adresser à un modèle de données simplifié et compréhensible : c’est la modélisation
dimensionnelle.
Elle consiste à considérer un sujet d’analyse comme un cube à plusieurs dimensions, mettant à sa
disposition des vues en tranches ou des analyses selon différents axes.
Dans la modélisation dimensionnelle, chaque modèle se compose d’une grande table centrale et un
jeu de petites tables auxiliaires disposées autour de la table centrale.
Celle-ci est appelée table de faits et les autres tables sont appelées tables de dimensions.
- Table de faits : est la table centrale du modèle dimensionnel, regroupant des clés étrangères, qui ne
sont autres que les clés primaires des tables de dimension. Elle contient les informations observables
(les mesures) sur ce qu’on veut analyser. Chaque ligne de la table correspond à une mesure qui
modélise le sujet de l’analyse.

28. - Tables de dimensions : sont des compagnons de la table de faits, chaque table représente un axe
d’analyse. Elles contiennent le contexte associé à un évènement de mesure du processus métier,
Modélise un axe d’analyse.
 Modélisation logique des données :
Les tables de faits et les dimensions sont organisé suivant un modèle de données spécifiques
et simple qui correspond au besoin de la modélisation dimensionnelle. Nous distinguons trois
modèle possibles :

 Le modèle en Etoile : ce modèle se présente comme une étoile dont le centre est la table
des faits et les branches sont les tables de dimensions.

La force de cette modélisation est sa lisibilité et sa performance, elle utilise moins de joint-
tures et de requetés simples mais présente des problèmes tels que la redondance et l’intégrité
des données.







Figure 6.2 : Le Modèle en Etoile


 Le modèle en Flocon de neige : identique au modèle en Etoile, sauf que ses dimensions sont
décomposées en hiérarchies (chaque niveau est représenté dans une table différente).
Cette modélisation est plus facile à maintenir permettant de réduire la redondance des données et de
prévenir les pertes de mémoire, par contre, elle est plus lente lors de l’interrogation suite à
l’augmentation du nombre de jointures.







Figure 6.2 : Le Modèle en Flocon

29. 7 Introduction aux modèles de Machine Learning utilisés :

Le Machine Learning (Apprentissage Automatique) est un champ de l'intelligence artificielle qui donne
aux ordinateurs la capacité d'apprendre à partir de données, sans être explicitement programmés.
Dans le cadre de ce projet, nous avons utilisé deux grandes familles d'apprentissage.

7.1 Apprentissage supervisé : Classification & Regression :

L’apprentissage supervisé est une des techniques de Machine Learning qui consiste à former des
modèles d’intelligence artificielle (IA) sur des jeux de données d’entrée et de sortie étiquetés par
l’homme. L’algorithme apprend ici un lien entre les données d’entrée (features) et les étiquettes des
données de sortie (target). Une fois les relations sous-jacentes entre les entrées et les sorties apprises,
ces modèles sont ensuite capables de prédire des sorties correctes à partir de nouvelles données
d’entrée (réelles) non étiquetée.

La Classification : L'objectif est de prédire une catégorie (ou classe) discrète.
 Exemple de notre projet : Prédire si une facture sera payée "en retard" ou "à l'heure".
Le modèle apprend à partir des factures passées pour classer les nouvelles factures dans l'une
de ces deux catégories.
 Algorithmes courants : Régression Logistique, Random Forest, Support Vector Machines
(SVM).
La Régression : L'objectif est de prédire une valeur continue.
 Exemple de notre projet : Prédire le montant des ventes futures. Le modèle apprend à partir
des ventes passées pour estimer un chiffre pour le futur.
 Algorithmes courants : Régression Linéaire, SARIMA, Prophet, XGBoost.
7.2 Apprentissage non supervisé : ( Clustering )

L'apprentissage non supervisé est utilisé lorsque l'on dispose de données non étiquetées. L'objectif
n'est pas de prédire un résultat connu, mais de découvrir des structures ou des motifs cachés
directement dans les données.
Le Clustering (ou segmentation) : C'est la tâche qui consiste à regrouper un ensemble de données de
telle manière que les points de données d'un même groupe (appelé cluster) soient plus similaires entre
eux qu'avec ceux des autres groupes.
Exemple de notre projet : Segmenter le portefeuille clients. En se basant sur leur comportement
d'achat (fréquence, montant, etc.), le modèle peut créer des groupes homogènes comme les "clients
très fidèles", les "clients occasionnels" ou les "clients à risque de départ".
Algorithme courant : K-Means.

30. 8 Conclusion du chapitre :

Ce chapitre a facilité de définir l'ensemble des concepts théoriques qui constituent la base de notre
projet. Nous avons étudié la structure et les éléments d'un système de Business Intelligence, en
mettant l'accent sur le processus ETL et la modélisation des données qui sont au centre de notre
travail d'ingénierie. Nous avons aussi mis en place les paradigmes de l'apprentissage automatique
qui nous ont aidés à aller au-delà de l'analyse descriptive pour nous atteler à l'analyse prédictive.

Avec cette maîtrise théorique en main, nous nous dirigerons dans le prochain chapitre vers la
phase de conception et de modélisation de notre solution sur mesure pour DEWEB Technologies,
mettant en pratique ces principes.

31. Chapitre 3 : Conception et modélisation :
1 Introduction :

Ce chapitre se concentre sur la phase de conception en ce qui concerne notre solution, nous l’avons
réservée en entier pour décrire la conception de notre solution, ce que nous avons déjà entrepris dans
le second chapitre. Ce dernier nous a permis d’établir les bases théoriques de la Business Intelligence
et du Machine Learning; rappelons aussi qu’il présente l’essentiel des concepts théoriques.
Pour cela, une première partie de ce chapitre est dédiée à l'architecture globale de la solution, de
l'extraction des données jusqu'à leur consommation. Nous essayons aussi d’expliquer la conception
du le Data Warehouse que nous créerons sur PostgreSQL. Nous faisons un pas en avant pour expliquer
les processus de l'identification des indicateurs et des axes d’analyse, l’élaboration de chaque table de
dimension et de fait pour finir par le schéma en étoile qui est la base de notre analyse.
2 Architecture globale de la solution :

L'architecture mise en place est une architecture décisionnelle classique à plusieurs niveaux, conçue
pour assurer la séparation des environnements transactionnels et analytiques, et pour garantir une
circulation fluide et maîtrisée de la donnée. Elle a été pensée pour servir à la fois les besoins de
reporting (BI) et d'analyse prédictive (ML).






Source de données Talend ETL DataWerhouse(Postgre) Restitution

Figure 2 : Architecture globale de la solution

Le schéma ci-dessus illustre les différentes briques de notre solution et leurs interactions :

Sources de Données (Data Sources) : À gauche, nous avons la source principale de données : la base
de données transactionnelle (OLTP) de l'ERP Sage 100c, hébergée sur un serveur Microsoft SQL Server.
C'est le système qui enregistre toutes les opérations quotidiennes de l'entreprise.



Figure 2 : Source des données de sage 100C

32. Processus d'Intégration (ETL) : Au centre, l'outil Talend Open Studio joue le rôle de passerelle. Il est
responsable de l'ensemble du processus ETL :
 Extraction : Il se connecte à la base SQL Server pour extraire les données brutes des tables
pertinentes.

 Transformation : Il applique un ensemble de règles de gestion pour nettoyer, standardiser,
convertir et enrichir les données (calcul de marge, création de clés, etc.).

 Load : Il charge les données transformées et prêtes à l'analyse dans notre entrepôt de données.

Stockage Décisionnel (Data Warehouse) : Les données sont centralisées dans un Data Warehouse
(DWH) hébergé sur un serveur PostgreSQL. Ce DWH, qui constitue notre source unique de vérité pour
l'analyse, est structuré selon un modèle dimensionnel pour optimiser les requêtes.
Consommation des Données (Data Consumption) : À droite, deux principaux outils consomment les
données du DWH :
 Business Intelligence : Microsoft Power BI se connecte directement au DWH PostgreSQL pour
permettre la création de rapports et de tableaux de bord interactifs à destination des
utilisateurs métier.
 Machine Learning : En parallèle, les notebooks Jupyter, utilisés via l'éditeur VS Code, accèdent
également aux données historisées et qualifiées du DWH pour l'exploration et l'entraînement
des modèles prédictifs en Python.
3 Conception du Data Warehouse sur PostgreSQL :

La pièce maîtresse de notre architecture est le Data Warehouse. Sa conception a suivi une
méthodologie de modélisation dimensionnelle (décrite au Chapitre 2) pour aboutir à un schéma en
étoile, favorisant la simplicité de compréhension et l'efficacité des requêtes.
3.1 Identification des axes d'analyse et des indicateurs de performance :

Cette première étape cruciale a consisté à traduire les besoins fonctionnels (identifiés en section 1.4.1)
en éléments techniques. Les "questions métier" nous ont permis de définir les axes d'analyse (qui
deviendront nos dimensions) et les indicateurs de performance (qui deviendront nos mesures dans les
tables de faits).

Tableau 3.1 : Les axes d'analyse et des indicateurs de performance
Processus Métier Questions Clés des Utilisateurs Axes d'Analyse
(Dimensions)
Indicateurs de Performance
(Mesures)
Analyse des Ventes Qui achète quoi, quand et
auprès de quel fournisseur ?
Client, Produit,
Temps, Fournisseur
Montant de vente HT, Quantité
vendue,etc..
Suivi des Stocks Quel produit est en stock, où, et
depuis quand ?
Produit, Entrepôt,
Temps
Quantité en stock, Valorisation du
stock
Suivi des Paiements

Quelle facture est en retard,
pour quel client ?

Client, Fournisseurs

Montant dû, Jours de retard

33. 3.2 Identification des Tables :

 Organisation des tables par domaines fonctionnels :

Domaine Tables principales
Tiers ( Clients et Fournisseur ) F_COMPTET, F_ARTFOURNISS
Ventes & Facturation F_DOCENTETE, F_DOCLIGNE, F_DOCREGLE
Articles & Stock F_ARTICLE, F_ARTSTOCK, F_DEPOT, F_FAMILLE
Comptabilité & Règlement F_ECRITUREC, F_CREGLEMENT, F_REGLEMENTT

Tableau 3.2 : Les tables principale par domaine
 Tiers (Clients et Fournisseur) :
Ce domaine regroupe les entités externes avec lesquelles l’entreprise échange des biens ou des services.
 Clients : personnes physiques ou morales achetant les produits ou services de l’entreprise.
 Fournisseurs :partenaires fournissant des matières premières, produit ou service à l’entreprise
 Table F_COMPTET :


La table F_COMPTET dans Sage 100c (généralement issue du module Comptabilité) contient les
comptes tiers, c’est-à-dire les comptes comptables associés aux Clients et Fournisseurs.

Champ Description
CT_Num ?????? - Identifiant unique du compte tiers (code client ou fournisseur)
- Exemple : CL0102 pour Client , FR0195 pour un Fournisseur
CT_Intitule Nom du tiers
CT_Type Type de tiers : "0" pour client, "1" pour fournisseur
CG_NumPrinc Numéro de compte comptable principal
CT_Ville Ville du tiers
Addresse_Complet Adresse postale complète
CT_Pays Pays du tiers
CT_Identifiant Numéro d’identification fiscal (ex. N° TVA intracommunautaire)
CT_NumPayeur Code d’un tiers désigné comme payeur
CT_Sommeil Permet de filtrer les tiers inactifs
CO_No Identifiant du commercial rattaché
N_CatTarif Catégorie tarifaire appliquée (lien avec les ventes)
DE_No Code du dépôt par défaut associé
CT_Telephone Numéro de téléphone
CT_Telecopie Numéro de fax
CT_EMail Adresse e-mail

Tableau 3.2 : La table F_COMPTET sous ERP Sage100C

34.  Table F_ARTFOURNISS:
Elle contient les conditions d’achat spécifiques négociées entre l’entreprise et ses fournisseurs pour
chaque article. Autrement dit, elle permet de définir les prix d’achat, les remises, les quantités
minimales et d’autres paramètres logistiques liés à l’approvisionnement.

Tableau 3.2 : La table F_ARTFOURNISS sous ERP Sage100C

 Ventes et Facturation :
Ce domaine gère l’ensemble du processus commercial, de la commande client jusqu’à la facturation.
 Gestion des commandes, devis, bons de livraison, factures, et avoirs.
 Suivi de l’état des ventes : en attente, validées, payées, annulées…
 Table F_ DOCENTETE:

Cette table contient les informations générales (en-têtes) des documents commerciaux émis ou reçus
par l’entreprise. Elle est commune aux ventes et aux achats, et couvre tous les types de documents :
devis, bons de commande, bons de livraison, factures, etc.
Tableau 3.2 : La table F_DOCENTETE sous ERP Sage100C
Champ Description
AR_Ref ?????? Référence de l’article
CT_Num ?????? Code du fournisseur concerné
AF_RefFourniss Référence de l’article chez le fournisseur
AF_PrixAch Prix d’achat hors taxe actuel
AF_Unite Unité d’achat utilisée (pièce, carton, etc.)
AF_DelaiAppro Délai d’approvisionnement en jours
AF_Garantie Durée de garantie en mois
AF_Colisage Quantité par colis (packaging fournisseur)
AF_QteMini Quantité minimale de commande
AF_Principal Indique si ce fournisseur est le principal pour cet article (si oui = 1 sinon 0)
AF_DateApplication Date à laquelle le nouveau tarif doit s’appliquer
Colonne Description
DO_Piece Numéro du document (identifiant unique)
DO_Date Date de création du document
DO_Domaine Domaine : Ventes (0), Achats (1),
DO_Type Type de document : devis, commande, facture, etc.
DO_Tiers Code du client ou fournisseur
CT_NumPayeur Code du tiers payeur
CO_No Code du commercial responsable
DE_No Dépôt (stock) lié au document
DO_TotalHT Total hors taxes
DO_TotalTTC Total toutes taxes comprises
DO_NetAPayer Montant net à payer
DO_MontantRegle Montant déjà réglé
DO_DateLivr Date prévue de livraison
DO_Tarif Code tarifaire appliqué

35.  Table F_ DOCLIGNE:
Cette table contient chaque ligne de produit ou service figurant dans les documents enregistrés dans
F_DOCENTETE. Elle est utilisée pour :
 Suivre les articles vendus ou achetés Analyser les ventes ou achats ligne par ligne
 Gérer les remises, prix unitaires, quantités, poids, etc.


Tableau 3.2 : La Table F_DOCLIGNE sous ERP Sage100C
 Table F_ DOCREGLE:
La table F_DOCREGLE enregistre les conditions de règlement (paiement total ou partiel) associées à
un document commercial (F_DOCENTETE). Elle est essentielle pour analyser :
 Le suivi des encaissements (clients) Le suivi des décaissements (fournisseurs)
 La part payée et le reste à payer
Colonne Description
DR_No ?????? Identifiant unique du règlement
DO_Piece ?????? Numéro du document lié (F_DOCENTETE)
DO_Domaine Domaine : ventes (0), achats (1),
DO_Type Type du document (facture, avoir, etc.)
DR_TypeRegl Type de règlement (ex : chèque, virement, espèces…)
DR_Date Date prévue ou réelle de règlement
DR_Montant Montant du règlement (en devise locale)
DR_Regle Booléen : indique si le document est réglé (1 = payé)
N_Reglement Code de la condition de règlement utilisée
CA_No Code du commercial ou responsable associé
DO_DocType Type du document Sage (ex. Facture client = 6)
Tableau 3.2 : La table F_DOCREGLE sous ERP Sage100C
Colonne Description
DO_Piece ?????? Numéro du document (clé étrangère vers F_DOCENTETE)
DL_Ligne Numéro de ligne dans le document
DO_Date Date du document
CT_Num Code du tiers (client/fournisseur)
AR_Ref Référence de l’article concerné
DL_Design Désignation de l’article
DL_Qte Quantité de l’article dans cette ligne
DL_PrixUnitaire Prix unitaire hors taxes
DL_PUTTC Prix unitaire TTC
DL_MontantHT Montant total HT de la ligne
DL_MontantTTC Montant total TTC de la ligne
DE_No Dépôt associé
DO_DateLivr Date de livraison prévue
CA_No Commercial responsable
DO_DocType Type du document (code)

36.  Article & Stock :
Ce domaine gère les produits ou articles de l’entreprise ainsi que leur quantité en stock.
 Suivi des articles (référence, désignation, unité, famille, etc.).
 Gestion des mouvements de stock (entrées, sorties, inventaires, transferts).
 Table F_ARTICLE:
Cette table contient les informations de base sur chaque article : nom, prix, unité, suivi de stock,
famille, délai de fabrication, etc. Elle est utilisée pour lister, classifier et suivre les articles
achetés, vendus ou stockés.

Colonne Description
AR_Ref ?????? Référence unique de l’article (code article)
AR_Design nom de l’article
FA_CodeFamille Code de la famille d’articles
AR_PrixAch Prix d’achat standard
AR_PrixVen Prix de vente standard
AR_UniteVen Unité de vente
AR_PUNet Prix unitaire net
AR_SuiviStock Suivi de stock activé
AR_Garantie Durée de garantie (en mois)
AR_PoidsNet Poids net de l’article
AR_Type Type d’article (Produit fini, semi-fini, matière première)
AR_Nature Nature (produit, service, etc.)
CO_No Code du commercial associé

Tableau 3.2 : La table F_ARTICLE sous ERP Sage100C

 Table F_ARTSTOCK:
La table F_ARTSTOCK contient les quantités de stock par article et par dépôt. C’est une table de faits
logistique, indispensable pour suivre :
 Les niveaux de stock actuels
 Les quantités réservées, commandées, ou préparées
 Les seuils mini/maxi La gestion par dépôt
Colonne Description
AR_Ref ?????? Référence de l’article
DE_No ?????? Code du dépôt (lieu de stockage)
AS_QteSto Quantité en stock réelle
AS_QteRes Quantité réservée (non disponible à la vente)
AS_QteCom Quantité commandée à un fournisseur (pas encore livrée)
AS_QteMini Seuil minimal de stock
AS_QteMaxi Seuil maximal de stock
AS_MontSto Valeur monétaire du stock (stock × coût unitaire)
AS_QtePrepa Quantité en préparation (en picking ou en attente de livraison)

Tableau 3.2 : La table F_ARTSTOCK sous ERP Sage100C

37.  Table F_DEPOT:
La table F_DEPOT contient les informations relatives à chaque dépôt physique où sont stockés les
articles. Elle est reliée aux mouvements de stock, aux documents logistiques, et à la gestion des
inventaires.

Colonne Description
DE_No ?????? Identifiant unique du dépôt
DE_Intitule Nom ou désignation du dépôt
DE_Adresse Adresse complète du dépôt
DE_Ville Ville du dépôt
DE_Principal Indique si c’est le dépôt principal (si oui = 1 sinon 0)

Tableau 3.2 : La table F_DEPOT sous ERP Sage100C

 Table F_FAMILLE:

La table F_FAMILLE contient les familles d’articles, c’est-à-dire des catégories logiques dans
lesquelles on regroupe les articles selon des critères comme le type de produit, l’unité de vente,
le suivi de stock, ou encore la garantie.

Colonne Description
FA_CodeFamille ?????? Code unique de la famille
FA_Intitule Intitulé ou nom de la famille
FA_Type Type de famille (produit, service, etc.)
FA_UniteVen Unité de vente principale des articles de cette famille
FA_SuiviStock Booléen : les articles sont-ils suivis en stock ?
FA_Garantie Durée de garantie standard (mois)
FA_Nature Nature des articles (produit, matière première, etc.)
FA_Criticite Niveau de criticité de la famille (utile pour prioriser ou alerter)

Figure : La table F_FAMILLE sous ERP Sage100C

38.  Comptabilité et règlement :
Ce domaine est responsable de la tenue des écritures comptables et du suivi des règlements.
 Enregistrement des écritures comptables issues des ventes, achats, règlements.
 Gestion des comptes clients et fournisseurs
 Table F_ECRITUREC:
La table F_ECRITUREC contient les écritures comptables générées par les documents (ventes, achats,
règlements, opérations diverses). Elle est utilisée pour :
 Le suivi des débits/crédits par compte comptable
 La gestion des journaux comptables et des échéances
Colonne Description
EC_No ?????? Identifiant unique de l’écriture
JO_Num Numéro du journal comptable
EC_Date Date de l’écriture comptable
EC_Piece Numéro de pièce comptable (souvent = DO_Piece)
EC_RefPiece Référence externe de la pièce
CG_Num Compte général débité ou crédité
CG_NumCont Compte de contrepartie (le cas échéant)
CT_Num Code tiers (client/fournisseur)
EC_Sens Sens : Débit = 0, Crédit = 1
EC_Montant Montant de l’écriture
EC_Echeance Date d’échéance du règlement (si liée à une facture)
EC_Lettrage Code de lettrage (pour le rapprochement)
N_Reglement Code de mode de règlement
N_Devise Devise utilisée
EC_MontantRegle Montant effectivement réglé (si partiel ou total)
EC_StatusRegle Statut du règlement (réglé ou non)

Tableau 3.2 : La table F_ECRITUREC sous ERP Sage100C


 Table F_CREGLEMENT:
La table F_CREGLEMENT contient les règlements enregistrés dans le système : paiements reçus des
clients, paiements effectués aux fournisseurs, etc.
Elle permet d’analyser :
 Les encaissements et décaissements
 Les références de paiement
 Les modes de règlement
 Les liens avec la comptabilité générale

39. Colonne Description
RG_No ?????? Identifiant unique du règlement
CT_NumPayeur Code du tiers (client/fournisseur) qui a payé
RG_Date Date du règlement
RG_Reference Référence du règlement (ex : n° de chèque, virement...)
RG_Libelle Libellé libre du règlement
RG_Montant Montant réglé en devise locale
RG_MontantDev Montant en devise étrangère (si applicable)
N_Reglement Code du mode de règlement (espèces, virement...)
RG_Compta Booléen : est-ce que le règlement est comptabilisé ?
EC_No Lien vers l’écriture comptable associée (F_ECRITUREC)
JO_Num Journal comptable du règlement
CG_Num Compte comptable du règlement (caisse, banque, etc.)
RG_TypeReg Type de règlement (ex : acompte, règlement final, etc.)
N_Devise Devise utilisée
RG_Piece Référence du document d’origine (facture liée)

Tableau 3.2 : La table F_CREGLEMENT sous ERP Sage100C

 Table F_REGLEMENTT:
La table F_REGLEMENTT contient les conditions de règlement associées à un tiers (client ou
fournisseur). Elle permet de définir les délais de paiement, les échéanciers personnalisés, et la
répartition des montants dans le temps.
C’est une table de paramétrage souvent utilisée pour générer automatiquement des échéances
lors de la saisie d’une facture.


Tableau 3.2 : La table F_REGLEMENTT sous ERP Sage100C

Colonne Description
CT_Num ?????? Code tiers (client ou fournisseur)
N_Reglement ?????? Code de la condition de règlement
RT_Condition Description ou nom de la condition de règlement (ex. : "30 jours fin de mois")
RT_NbJour Nombre de jours avant l’échéance principale (ex : 30, 60…)
RT_TRepart Type de répartition des paiements (ex. : % ou valeur fixe)
RT_VRepart Valeur de répartition principale (ex : 100%)

40. 3.3 Identification des Data Mart :

3.3.1 Data Mart par domaine (Clients) :

Table de faits :
F_DOCLIGNE : Cette table contient chaque ligne de produit ou service figurant dans les documents
enregistrés dans F_DOCENTETE.
Tables des Dimensions :
 F_DOCENTETE : Cette table contient les informations générales (en-têtes) des documents
commerciaux émis ou reçus par l’entreprise.
 CALENDRIE
 F_COMPTET : table client
 F_ECRUTEREC : La table F_ECRITUREC contient les écritures comptables générées par les
documents (ventes, achats, )

Figure 3.3.1 : Schéma en étoile pour DataMart pour les Clients

41. 3.3.2 Data Mart par domaine ( Ventes ) :

Table de faits : F_DOCLIGNE
Tables du Dimensions :
 F_ARTICLE : Cette table contient les informations de base sur chaque article: nom, prix, unité ,.
 F_DOCENTETE : Cette table contient les informations générales (en-têtes) des documents
commerciaux émis ou reçus par l’entreprise
 Calendrier : nécessaire pour les analyses temporelles
 F_FAMILLE : contient les familles d’articles, c’est-à-dire des catégories dans lesquelles on
regroupe les articles.



Figure 3.3.2: Schéma en étoile pour DataMart pour les Ventes

42. 3.3.3 Data Mart par le domaine (Stock) :
Table de faits :
F_ARTSTOCK : La table F_ARTSTOCK contient les quantités de stock par article et par dépôt.
Tables du Dimensions :
 F_DEPOT : correspond aux lieux de stockage
 F_ARTICLE : les produits
 F_DOCLIGNE : utilisée pour calculer la quantité vendue (par article,
 F_FAMILLE : classification des articles


Figure 3.3.3 : Schéma en étoile pour DataMart pour les stocks

43. 3.3.4 Data Mart par le domaine (Fournisseurs):

 Table de faits :

F_DOCENTETE : Contient les documents (commandes, factures d’achat, avoirs, etc.)

 Tables de dimensions :

DIM_CALENDRIER : Pour les analyses temporelles : date de facture, date d’échéance, date de
règlement, etc.

F_COMPTET : Liste des tiers fournisseurs avec leurs infos : nom, code, adresse, secteur, etc.

F_DOCREGLE : Table de paiements associés à la facture : date, montant réglé, mode de paiement,

F_ECRITUREC : Table comptable contenant les écritures liées aux factures fournisseurs (utile pour les
rapprochements comptables ou reporting).

















Figure 3.3.4 : Schéma en étoile pour DataMart pour les Fournisseurs

44. 4 Conclusion du Chapitre :

Ce chapitre a détaillé la phase de conception de notre solution, qui est le socle de tout le projet. Nous
avons défini une architecture globale claire et découplée, puis nous avons méticuleusement conçu le
modèle de données de notre Data Warehouse en suivant les meilleures pratiques de la modélisation
dimensionnelle. Chaque table, chaque attribut et chaque mesure a été défini en réponse directe aux
besoins métier identifiés.

Nous disposons maintenant d'un plan directeur (blueprint) technique, clair et justifié, parfaitement
aligné sur les objectifs du projet. Le plan étant désormais établi, le chapitre suivant sera consacré à sa
mise en œuvre concrète : le développement des flux ETL avec Talend et la création des tableaux de
bord sur Power BI et enfin implémentation des modèles de ML.

45. Chapitre 4 : Réalisation et mise en œuvre (ETL, BI, ML)

1 Introduction :

Après la phase de conception détaillée au chapitre 3, qui nous a dotés d'un plan directeur clair pour
notre Data Warehouse, ce chapitre aborde la phase de mise en œuvre concrète. C'est ici que les
concepts et les modèles prennent vie à travers le développement technique. Nous allons décrire pas à
pas la construction de la chaîne décisionnelle, depuis l'extraction des données brutes jusqu'à leur
présentation sous forme de tableaux de bord interactifs.
Ce chapitre présentera d'abord l'environnement de développement et les outils qui ont été nos
compagnons tout au long de cette phase. Puis, nous détaillerons la pièce maîtresse de l'alimentation
des données : l'implémentation des flux ETL avec Talend, ainsi nous décrirons la construction de la
couche de restitution avec Power BI, l'outil mis à la disposition des utilisateurs finaux pour explorer les
données et piloter leur activité et enfin en va construire des modèles d'apprentissage automatique
(Machine Learning) capables de répondre à des problématiques métier à forte valeur ajoutée.
2. Environnement de développement et outils :

Le choix des outils est une étape déterminante pour la réussite d'un projet de Business Intelligence.
Nos choix se sont portés sur des solutions open-source et des leaders du marché, reconnus pour leur
robustesse, leur flexibilité et leur performance.
2.1. Outil ETL : Talend Open Studio :

Pour l'ensemble des processus d'extraction, de transformation et de chargement des données, nous
avons utilisé Talend Open Studio for Data Integration. Cet outil a été choisi pour plusieurs raisons :
Open-Source : Il est gratuit et bénéficie d'une large communauté d'utilisateurs.
Interface Graphique : Son approche visuelle par "glisser-déposer" de composants permet de
concevoir, de lire et de maintenir les flux de données (jobs) de manière intuitive.
Connectivité Étendue : Il dispose d'une vaste bibliothèque de connecteurs natifs, nous permettant de
nous interfacer facilement avec nos sources (Microsoft SQL Server) et notre cible (PostgreSQL).
Puissance de Transformation : Ses composants, notamment le tMap, offrent des capacités de
transformation de données très avancées.




Figure 4.2.1 : Logo logiciel Talend ETL

46. 2.2 SGBD pour le DWH : PostgreSQL :

La base de notre entrepôt de données est PostgreSQL, un système de gestion de bases de données
relationnelles open-source réputé pour sa fiabilité, sa robustesse et ses excellentes performances sur
des requêtes analytiques complexes. Il est parfaitement capable de supporter la charge d'un Data
Warehouse et s'intègre nativement avec la majorité des outils de BI du marché.





Figure 4.2.2 : Logo du SGBD PostgreSQL

2.3 SQL Server Management Studio ( Source de donneés ERP de sage 100C) :

SQL Server Management Studio (SSMS) est un environnement graphique développé par Microsoft qui
permet de gérer et d’administrer les bases de données SQL Server. Il offre une interface conviviale
pour exécuter des requêtes SQL, créer ou modifier des bases de données,
Dans le contexte des logiciels de gestion intégrée (ERP) tels que Sage 100c, SQL Server joue un rôle
central en tant que source principale de données. Toutes les informations liées à la comptabilité, à la
gestion commerciale, aux stocks, aux clients et aux fournisseurs y sont enregistrées sous forme de
tables relationnelles.






Figure 4.3.3 : Logo du SQL Server Management Studion (SSMS)

47. 2.4 Outil de restitution : Microsoft Power BI :
Pour la couche de visualisation, notre choix s'est porté sur Microsoft Power BI Desktop. C'est
aujourd'hui l'un des leaders incontestés de la BI en libre-service.
Il se traduit en un ensemble de 3 outils majeurs :





FIgURe 4.2.3 : Les outils majeurs de Power BI

Les grandes fonctionnalités de Power BI :
La figure ci-dessous représente les fonctionnalités de Power BI :







Figure 4.2.3 : Les fonctionnalités de Power BI
Les points forts stratégiques de Power BI :
Etre efficient :
 Disposer des bonnes informations en temps réel pour agir rapidement.
 Gagner du temps, donc de l’argent et se concentrer sur les taches a` valeurs ajoutées.
Etre professionnel :
 Renvoyer une bonne image.
 Faciliter la transmission d’information entre les équipes.
Les points forts pratiques de Power BI :
 Utilisation des fonctions innovantes (Calculate, xfunctions,etc).
 Rapidité´ de calcul.
 Visualisation dynamique.
 Partage entre utilisateurs très facile.
 Licence standard gratuite et complète, licence pro à faible coût.

Figure 4.2.3 : Logo du Power BI

48. 2.5 VSCode, Jupyter et Python:

L'ensemble des développements de Machine Learning a été réalisé en Python, le langage de
programmation de facto pour la science des données, en raison de son immense écosystème de
bibliothèques spécialisées.
L'environnement de travail était composé de :
 Visual Studio Code : Utilisé comme éditeur de code principal pour son excellente intégration
avec Python et les notebooks.
 Jupyter Notebooks : Employés pour toutes les phases d'exploration, de prototypage rapide et
de visualisation des résultats. Leur format interactif est idéal pour la démarche itérative de la
data science.





Figure : Logo du Jupyter & VsCode

Les principales bibliothèques Python mobilisées sont :

 Pandas : Pour la manipulation et l'analyse des données (chargement des données depuis
PostgreSQL, création et transformation des DataFrames).
 NumPy : Pour les calculs numériques et les opérations sur les tableaux.
 Scikit-learn : La bibliothèque centrale pour le Machine Learning, utilisée pour la préparation
des données (scaling, encodage), la modélisation (Random Forest, K-Means, etc.) et
l'évaluation des performances (calcul des métriques).
 Matplotlib & Seaborn : Pour la visualisation des données lors des phases d'exploration et pour
la présentation des résultats des modèles.





Figure 4.2.4 : Logo du Langage Python

49. 3 Implémentation des flux ETL :

L'alimentation de notre Data Warehouse a été réalisée par une série de jobs Talend. La stratégie
adoptée a été de créer un job distinct pour chaque table de notre modèle en étoile (un job pour
Dim_Client et Fournisseur, un pour Dim_Article, etc.).











Figure 4.3 : Les jobs ETL réaliser via Talend
3.1. Extraction des données de Sage 100c (SQL Server) :

La première étape de chaque job consiste à extraire les données de la base de production. Pour cela,
nous avons utilisé le composant tDBInput de Talend. Après avoir configuré la connexion à la base de
données SQL Server, Par exemple extraction des donnes depuis la table Tiers F_COMPTET.










Figure 4.3.1: Configuration de le Composant tDBinput(MS SqlServer)

50. 3.2. Transformation des données avec le composant tMap :

Le composant tMap est le cœur de la logique de transformation dans nos jobs Talend. Il nous a permis
d'appliquer les règles de gestion définies lors de la conception pour transformer les données brutes en
données propres et structurées.
Voici ce que l'on peut faire avec tMap :
 Associer des colonnes d’entrée à des colonnes de sortie.
 Renommer, supprimer, ou créer des colonnes de sortie selon les besoins.
 Supprimer les ligne Vide ou ligne qui contient des valeur null
 Ajouter des calcul mathématique, Ex : row1.price * row1.quantity
Figure 4.3.2 : Composant tMap pour montrant les flux d’entrée (Row1) et de sortie(out_COMPTET)
. 3.3. Chargement de l'entrepôt de données PostgreSQL :
L'étape finale du processus ETL est le chargement des données transformées dans notre DWH
PostgreSQL. Nous avons utilisé le composant tDBOutput ( POstgre).








Figure 4.3.3 : Le composant tDBOutput( PoStgre SQL)

51. 3.3 : Exemple d’un job complet :
Ce job a pour objectif de charger plusieurs tables sources depuis SQLServer (F_ARTICLE, F_ARTSTOCK,
F_DEPOT, F_FAMILLE), d’appliquer des transformations via des composants tMap, de faire des copies
via tReplicate, et d’envoyer les données dans des tables cibles (tDBOutputPostgreSQL), avec une
gestion structurée de la connexion à la base de données.
Étapes principales du flux Talend :
 Initialisation avec un Prejob
tPrejob_1 : Composant de pré-exécution. Démarre l’exécution du job.
tDBConnection_1 : Établit la connexion à la base de données SQLServer.
Il est suivi de plusieurs flux OnComponentOk pour exécuter les étapes suivantes dans un ordre précis.
 Chargement et traitement des tables :
 Ordre 1 - F_ARTICLE
 F_ARTICLE : Lecture de la table source.
 tMap_1 : Transformation des données de F_ARTICLE.
 tReplicate_1 : Duplique les données transformées en deux sorties :
 Vers tDBOutput_1 : Chargement vers la base de données PostgreSQL.
 Vers tLogRow_1: Peut servir au débogage ou à la vérification.
 Ordre 2 - F_ARTSTOCK
 F_ARTSTOCK → tMap_2 → tReplicate_2 → tDBOutput_2
 Ordre 3 - F_DEPOT
 F_DEPOT → tMap_3 → tReplicate_3 → tDBOutput_3
 Ordre 4 - F_FAMILLE
 F_FAMILLE → tMap_4 → tReplicate_4 → tDBOutput_4










Figure 4.3.3 : Exemple du job Talend Complet

52. 4 Mise en œuvre de la restitution avec Power BI :

Une fois le Data Warehouse alimenté, l'étape suivante a été de rendre ces données accessibles et
intelligibles pour les utilisateurs métier via Power BI.
4.1. Connexion au Data Warehouse ( Postgre SQL ) :

La connexion depuis Power BI Desktop à notre base de données PostgreSQL a été réalisée via le
connecteur natif. Nous avons choisi le mode de stockage "Importer", qui charge une copie des données
dans le modèle Power BI. Ce mode offre des performances optimales pour l'exploration et l'interaction
avec les tableaux de bord.
Une fois les tables importées, les relations entre les tables de faits et les dimensions, définies dans
notre schéma en étoile, ont été recréées dans la vue "Modèle" de Power BI.







Figure 4.1 : Configuration de connexion au DataWerhouse ( PostgreSQL)
Cet entrepôt de données est organisé en plusieurs schémas, chacun correspondant à un data mart
thématique, facilitant ainsi la séparation logique des données selon les domaines fonctionnels de
l’entreprise. On y retrouve les schémas suivants :
 Data_Mart_Clients : pour les données relatives aux clients.
 Data_Mart_Fournisseurs : pour les fournisseurs.
 Data_Mart_Stocks : pour la gestion des stocks.
 Data_Mart_Ventes : pour les données de ventes. public : schéma par défaut de PostgreSQL.






Figure 4.1 : Organisation des schémas de l’entrepôt de données

53. 4.2. Création des tableaux de bord (Ventes, Clients, Fournisseurs, Stocks) :

Pour chaque grand domaine d'analyse, un tableau de bord spécifique a été conçu, en se concentrant
sur les KPIs identifiés dans la phase de conception.
 Tableau de Bord des Ventes & Clients :

 Analyse du Tableau de Bord "Ventes" :









Figure 4.2: Tableau de bord des Ventes
Ce tableau de bord se concentre sur la performance des ventes de produits sur la période par exemple :
du 4 janvier 2017 au 30 décembre 2019, comme indiqué par le filtre de date.
Voici le détail de chaque section :
1. Graphes des ventes (en haut à gauche)
 Axe vertical : Montant total Hors Taxes (de 0 à 1,0M) Axe horizontal : Date de Facture.
 Ce qu'il montre : Ce graphique linéaire illustre l'évolution quotidienne du chiffre d'affaires hors
taxes. Il permet d'identifier rapidement les périodes de forte et les périodes plus calmes. C'est
un outil essentiel pour visualiser la saisonnalité et les tendances des ventes.
2. Top articles vendus (en bas à gauche)
 Axe vertical : Nom du Produit Axe horizontal : Quantité d'Article.
 Ce qu'il montre : Ce graphique à barres classe les produits les plus vendus en termes de
quantité. On voit clairement que le "Cable informatique Legrand Cat.6 F/UTP 4P L." est le
produit le plus populaire, loin devant les autres.
3. Répartition des ventes par famille (en bas à droite)
 Titre : Répartition des ventes par famille Type : Graphique circulaire (camembert).
 Ce qu'il montre : Ce graphique décompose le chiffre d'affaires total par "Famille d'Article".
Chaque part représente le pourcentage du chiffre d'affaires total généré par une famille de
produits.

54.  Analyse de tableau de bord des Clients :
Figure 4.2 : Tableau de bord pour les Clients
Ce tableau de bord analyse la performance des ventes sous l'angle des clients pour la période du 24
février 2017 au 14 novembre 2019.
Voici le détail de chaque section :
1. Tableau de ventes détaillé (en haut)
 Colonnes : Date, Client, Article, Quantité, Prix Unitaire, CA (Chiffre d'Affaires).
 Ce qu'il montre : Il s'agit d'un journal des ventes qui affiche les transactions une par une. On
peut y voir quel client a acheté quel produit, à quelle date, en quelle quantité et pour quel
montant. La ligne "Total" en bas résume les chiffres pour l'ensemble des transactions listées :
un total de 14 003 147,61 de chiffre d'affaires pour 2 165 877,30 articles vendus.
2. Meilleurs clients par chiffre d'affaires (en bas à gauche)
 Axe vertical : Nom des Clients. Axe horizontal : Montant total Hors Taxes.
 Ce qu'il montre : Ce graphique à barres classe les clients en fonction du chiffre d'affaires
qu'ils ont généré. C'est un "Top Clients".
o Le client "CLIENTS DIVERS" est de loin le plus important avec un CA de 45M.
o Il est suivi par "DISWAY" avec 16M.
 Ce visuel est crucial pour la gestion de la relation client (CRM), permettant d'identifier et de
fidéliser les clients les plus précieux.
3. Indicateur du nombre de clients (en bas à droite)
 Titre : Clients_Actif Valeur : 147
 Ce qu'il montre : C'est un indicateur clé de performance (KPI) qui affiche simplement le
nombre total de clients uniques et actifs ayant effectué au moins un achat durant la période
sélectionnée par le filtre de date (du 24/02/2017 au 14/11/2019).

55.  Tableau de Bord des Fournisseurs :
Ce tableau de bord offre une vue synthétique et analytique des dettes envers les fournisseurs pour la
période du 1er janvier 2018 au 31 décembre 2018. Il permet de suivre les factures, les paiements et
les soldes restants à payer. Voici la signification de chaque élément :
 Les Indicateurs Clés de Performance (à droite)
Ces trois chiffres donnent une vue d'ensemble immédiate de la situation :
 Montant Total TTC (7,70M) : C'est le montant total de toutes les factures reçues des
fournisseurs sur l'année 2018. "M" signifie Millions.
 Montant Payé (7,21M) : C'est la somme totale qui a déjà été payée à ces fournisseurs sur la
même période.
 Montant restant à régler (486,93K) : C'est le solde total qu'il reste à payer aux fournisseurs.
"K" signifie Milliers. Ce montant est la différence entre le Montant Total et le Montant Payé.
 Graphique en barres : Évolution mensuelle (en haut à gauche)
Ce graphique montre l'évolution des factures et des paiements mois par mois pour l'année 2018.
 Axe horizontal : Les mois de l'année. Axe vertical : Les montants en millions.
 Barres bleues (Montant Total TTC) : Le montant total facturé par les fournisseurs.
 Barres vertes (Montant Payé) : La part de ce montant qui a été payée.
 Barres rouges (Montant Reste à Régler) : La part qui n'a pas encore été payée.
 Graphique circulaire : Répartition du solde restant (en haut à droite)
Ce graphique, intitulé "Solde Restant par Fournisseur", détaille à qui l'entreprise doit de l'argent.
 Il représente les 486,93K € de dette totale.
 Chaque part du cercle correspond à un fournisseur.
 On voit immédiatement qu'un fournisseur, LEGRAND MAROC, représente la plus grande partie
de la dette avec 305,71K €, soit 62,78% du total restant à payer.
C'est un outil très utile pour prioriser les paiements.
 4. Tableau de données : Détail par Fournisseur (en bas)
Ce tableau fournit les données brutes qui alimentent les graphiques. Il liste les fournisseurs et donne
pour chacun :
 Nom du Fournisseur : Le nom du créancier.
 Montant total TTC : Le total facturé par ce fournisseur sur la période.
 Montant Réglé : Ce qui a été payé à ce fournisseur.
 MontantRestePayer : Le solde dû. On peut voir que pour des fournisseurs comme "LEGRAND
MAROC" (deuxième ligne) ou "ABB SA", le solde est de 0, ce qui signifie qu'ils ont été
intégralement payés.

56.  Date de la facture et Date d'échéance.
La ligne "Total" en bas du tableau récapitule les montants pour tous les fournisseurs et correspond
aux indicateurs clés de droite.
 Filtre de Date : Il permet à l'utilisateur de choisir la période exacte qu'il souhaite examiner.
Figure 4.2 : Tableau de bord pour les Fournisseurs
 Tableau de Bord le stock :
Ce tableau de bord fournit une vue complète de l'état des stocks, en croisant les données de ventes et
les niveaux d'inventaire actuels. La période d'analyse pour les données de ventes par exemple est du
18 juin 2018 au 27 août 2020.
1. Les Indicateurs Clés de Performance (en haut)
Ces quatre indicateurs offrent un résumé instantané de la performance des stocks :
 Quantité Vendue (525,00K) : Le nombre total d'articles vendus durant la période
sélectionnée (juin 2018 - août 2020).
 Quantité en Stock (93,03K) : Le nombre total d'articles actuellement disponibles dans le
stock du dépôt sélectionné.
 Valeur du Stock (7,38M) : La valeur totale des 93,03K articles actuellement en stock.
 Taux de Rotation des Stocks (16,26%) : Un ratio de performance qui indique à quelle vitesse
le stock est vendu et renouvelé sur la période. Il compare la quantité vendue à la quantité
moyenne en stock.

57. 2. Les Filtres Interactifs (sur les côtés)
Ces panneaux permettent d'affiner l'analyse :
 Filtre "Depots" (à gauche) : Permet de choisir un ou plusieurs entrepôts. Ici, seul le dépôt
"Dep0001 TASSILA" est sélectionné. Toutes les données affichées (quantité en stock, valeur,
etc.) concernent donc exclusivement ce dépôt.
 Filtre "FA_Intitule" (Famille d'Article, à gauche) : Permet de filtrer par catégorie de produit
(ex: "Accessoire Fibre optique", "Accessoires électriques").
 Filtre "Dates" (à droite) : définir la plage de temps pour l'analyse des données de ventes.
3. Graphique : Quantité Vendue par Produit (au centre)
Ce graphique à barres classe les produits en fonction de leur popularité.
 Il montre les articles les plus vendus du dépôt de Tassila sur la période 2018-2020.
 On voit que le "Cable informatique Legrand Cat.6A F/UTP 4P LSZH..." est le produit le plus
vendu avec 50 000 unités écoulées.
 Cela aide à identifier les produits "stars" pour optimiser les commandes et éviter les ruptures
de stock.
4. Tableau : État des Stocks (en bas)
Ce tableau donne le détail précis de ce qui se trouve actuellement en stock dans le dépôt de Tassila.
 Référence de l'Article : Le code unique du produit.
 Nom Produit : La description du produit.
 Quantité d'Article : Le nombre exact d'unités disponibles pour chaque produit.
 Statut Stock : Indique l'état du stock pour l'article (ici, "Normal").









Figure 4.2 : Tableau de bord pour le Stocks

58. 5. Implémentation des Modèles statistique et Machine Learning :

Les chapitres précédents ont détaillé la construction d'un Data Warehouse robuste et la mise en place
de tableaux de bord pour l'analyse descriptive et diagnostique. Cette partie finale de mise en œuvre
aborde la brique d'analyse la plus avancée du projet : l'analyse prédictive. L'objectif est d'exploiter la
richesse et la qualité des données centralisées pour construire des modèles d'apprentissage
automatique (Machine Learning) capables de répondre à des problématiques métier à forte valeur
ajoutée.
5.1. Projet 1 : Prédiction des ventes futures (Chiffres d’affaires):
Objectif Métier: Le but de ce projet était de prévoir le chiffre d'affaires mensuel pour les 12 mois à
venir, dans le but d’aider à la planification des ressources, à la gestion des stocks et à l’anticipation des
besoins commerciaux.
Données Utilisé : Les données proviennent du système ERP Sage 100c, extraites de la base
PostgreSQL datawarehouse_sage, en combinant deux tables principales :
F_DOCENTETE : contient les métadonnées des documents de vente (dates, types, domaines).
F_DOCLIGNE : détail des lignes de vente, notamment les montants hors taxe.
















Tableau 5.1 : série du chiffre d'affaires journalier 2017/2018/2019
Prétraitement :
 Agrégation des ventes journalières en séries temporelles mensuelles.
 Remplissage des dates manquantes par 0.
 Indexation temporelle et lissage.
Date Transaction Chiffre Affaires
04/01/2017 11050
05/01/2017 1840
06/01/2017 575
16/01/2017 1020
17/01/2017 1079,57
21/01/2017 19940,07
23/01/2017 18452
……….. ………


22/05/2018 2425
23/05/2018 2410
24/05/2018 4795,89
28/05/2018 72322,95
04/06/2018 29688,28
05/06/2018 5178,1
………………………. …………………..
20/12/2019 1505,65
23/12/2019 24770,88
24/12/2019 31829,19
25/12/2019 109730,38
26/12/2019 133561,42
28/12/2019 301261,32
30/12/2019 355351,22

59. Tableau 5.2 : séries mensuelles de chiffres d’affaires 2017/2018/2019
Exploration des Données
Le graphique montre des pics saisonniers marqués à certaines périodes (notamment en fin d’année),
confirmant la présence d’une saisonnalité forte.







Figure 5.1 : Chiffres d’affaires mensuel

Analyse Saisonnière
La décomposition saisonnière du signal révèle :
 Une tendance globalement croissante. Une saisonnalité annuelle claire.
 Un résiduel modéré, ce qui suggère que la structure du signal est exploitable pour la prévision.







Figure 5.1 : La décomposition saisonnière du signal
Date Transaction chiffre affaires
31/01/2017 102911,65
28/02/2017 271001,07
31/03/2017 278587,09
……….. ………….
31/05/2018 256976,93
30/06/2018 594891,78
31/07/2018 1225950,48
………… ………..
30/09/2019 839847,62
31/10/2019 1160807,13
30/11/2019 428019
31/12/2019 2678425,73

60. Modélisation – SARIMA
Le modèle choisi est un SARIMA (Saisonnier AutoRegressif Integrated Moving Average), construit
automatiquement via pmdarima.auto_arima.
Le jeu de données a été scindé en deux :
 Train : 2017–2018 Test : 2019
Le modèle a été entraîné sur les données d’apprentissage, puis évalué sur 12 mois de test.
Résultats d’évaluation :
 MAE : 142 301 € RMSE : 193 842 €
Résultats et Visualisation :
Figure 5.1 : Prédiction vs Réel ( Model Test )
Projection sur 12 mois à venir
Une projection du chiffre d’affaires a été réalisée pour l’année 2020.
La courbe inclut :
 Les valeurs prédites (en vert) -L’intervalle de confiance à 95% -L’historique pour référence








Figure 5.1 : Projection sur 12 mois à venir

61. Résultats sous format tableau :








Tableau 5.1 : Résultats du Projection sur 12 mois à venir
5.2. Projet 2 : Segmentation Comportementale des Clients :
Problématique Métier : L'entreprise souhaitait mieux comprendre les différents comportements
d'achat de ses clients. Sans une vision claire des groupes de clients, les actions marketing étaient
génériques et peu efficaces, menant à un faible engagement et un risque de perte de clients de valeur.
Objectif du Projet : L'objectif était de segmenter la base de clients en groupes distincts et homogènes
en se basant sur leur historique de transactions. Cette segmentation devait permettre d'identifier les
clients les plus précieux, ceux à risque, et d'adapter les stratégies marketing pour chaque groupe afin
d'améliorer la fidélisation et d'augmenter le chiffre d'affaires.
Source des Données : Les données de transactions ont été extraites de la base de données PostgreSQL
de l'entreprise. La requête SQL a joint les tables F_DOCENTETE (informations sur les factures) et
F_DOCLIGNE (détails des montants) pour obtenir les informations nécessaires.
DO_Tiers DO_Date DO_Piece DL_MontantHT
CL0267 07/02/2017 FDT2255 3897,5
CL0344 03/02/2017 FDT2245 2901
CL0306 29/01/2018 FDT180013 2300
……. ……. ……. …….
CL0357 07/08/2017 FDT2389 5060
CL0344 03/02/2017 FDT2245 360
CL0344 03/02/2017 FDT2246 6908,27
CL0344 03/02/2017 FDT2246 6664
CL0044 06/01/2017 FDT2226 575
CL0456 21/06/2019 FDT190223 247,38
CL0456 21/06/2019 FDT190223 2616,3
CL0456 21/06/2019 FDT190223 430,92
CL0456 24/06/2019 FDT190224 10799,68
CL0461 26/09/2019 FDT190369 136,08
CL0461 26/09/2019 FDT190369 535,66
CL0461 26/09/2019 FDT190369 2039,04
CL0461 26/09/2019 FDT190369 69,12
CL0461 26/09/2019 FDT190369 235,22
Tableau 5.2 : Table pour Les données de transactions des clients 2017/2018/2019
Date Prédictions Borne Inférieure Borne Supérieure
2020-01-31 1 153 032 -234 670 2 540 733
2020-02-29 745 751 -647 792 2 139 295
2020-03-31 736 610 -662 752 2 135 972
2020-04-30 707 742 -697 414 2 112 898
2020-05-31 757 380 -653 546 2 168 306
2020-06-30 919 194 -497 479 2 335 868
2020-07-31 1 103 065 -319 331 2 525 462
2020-08-31 1 632 362 204 265 3 060 460
2020-09-30 948 776 -484 999 2 382 551
2020-10-31 905 282 -534 149 2 344 712
2020-11-30 1 387 636 -57 428 2 832 701
2020-12-31 1 853 461 402 785 3 304 136

62. Ingénierie des Caractéristiques (Feature Engineering) - Modèle RFM :
Pour qualifier le comportement des clients, le modèle RFM a été calculé :
 Récence : Nombre de jours depuis le dernier achat. Un client récent est souvent plus engagé.
 Fréquence : Nombre total de transactions (factures uniques). Elle mesure la fidélité du client.
 Montant : Somme totale des achats. Elle mesure la valeur monétaire du client.
Le résultat de ce calcul a produit le tableau de données suivant, prêt pour la modélisation :












Tableau 5.2 : Tableau pour le modèle RFM des clients ( 147 Clients en Total )
3. Approche de Modélisation (Le "Comment ?")
Préparation des données : Les variables Récence, Fréquence et Montant ayant des échelles très
différentes, une normalisation avec StandardScaler a été appliquée. Cette étape est cruciale pour que
l'algorithme de clustering traite chaque variable avec la même importance.
Choix de l'Algorithme : L'algorithme de clustering K-Means a été choisi pour sa simplicité, son
efficacité et la facilité d'interprétation de ses résultats dans un contexte marketing.
Détermination du Nombre Optimal de Segments (K) : Pour trouver le nombre de clusters le plus
pertinent, la méthode du coude (Elbow Method) a été utilisée. Le graphique ci-dessous montre l'inertie
du modèle en fonction du nombre de clusters. Le "coude", point où le gain à ajouter un cluster devient
marginal, se situe clairement à K=4.



Figure 5.2 : Choix de Nombre optimal K
DO_Tiers Récence Fréquence Montant
CL0001 370 14 78 825.43
CL0002 20 8 24 933.44
CL0005 3 12 39 672.00
CL0007 578 1 8 986.67
CL0009 245 3 2 710.00
CL0013 971 2 2 281.00
CL0020 308 14 132 083.39
CL0025 3 36 334 932.92
CL0027 731 2 103 315.61
CL0043 1 10 59 951.63
CL0044 7 97 382 641.63
………. ……… ……. ………
CL0047 472 9 291 679.70
CL0049 69 10 19 660.00
CL0054 546 1 980 445.49
CL0057 732 6 99 914.72
CL0060 116 9 1 885 027.14
CL0069 743 1 850.00

63. Résultats et Interprétation (Les "Résultats ?")
 Profil des Segments : Le modèle K-Means a permis de diviser les clients en 4 segments
distincts. L'analyse des caractéristiques moyennes de chaque segment révèle leurs profils :
 Description des Segments :
o Segment 3 ("Super Champions") : Ils achètent très souvent (Fréquence de 52),
récemment (Récence de 17 jours) et dépensent beaucoup. Ce sont les meilleurs
clients.
o Segment 2 ("Champions") : Ils dépensent le plus en valeur absolue (Montant de
1.38M), achètent régulièrement mais un peu moins récemment que les Super
Champions. Ce sont des clients à très forte valeur.
o Segment 0 ("Clients Actifs") : C'est le plus grand groupe. Ils achètent de manière
modérée et sont relativement récents. C'est le cœur de la base clients.
o Segment 1 ("Clients à Risque") : Ce sont des clients qui n'ont pas acheté depuis très
longtemps (Récence de 769 jours) et peu souvent. Ils sont sur le point d'être perdus.
 Visualisation des Clusters : Le graphique pairplot ci-dessous montre bien la séparation des 4
groupes selon les axes Récence, Fréquence et Montant. On distingue nettement le groupe des
"Clients à Risque" (rose, segment 1) isolé par sa forte récence.
















Figure 5.2 : Visualisation des clusters

64. Conclusion et Recommandations Opérationnelles (Et "Après" ?)
 Conclusion : L'analyse a permis d'identifier avec succès quatre segments de clients distincts et
actionnables. La majorité des clients sont "Actifs" (98), tandis qu'un groupe critique de 33
clients est "à Risque". Les clients à plus haute valeur sont répartis entre les "Super Champions"
(10) et les "Champions" (4).
 Recommandations Stratégiques : Cette segmentation permet de passer d'un marketing de
masse à une approche ciblée et personnalisée.



Tableau 5.2 : Conclusion et Recommandations du résultats du modèle
5.3. Projet 3 : Prédiction de Rupture de Stock :
Problématique Métier : La gestion des stocks est un défi majeur. Une rupture de stock entraîne des
ventes manquées et une insatisfaction client, tandis qu'un surstockage immobilise inutilement de la
trésorerie. L'entreprise avait besoin d'un outil proactif pour anticiper les ruptures et optimiser les
commandes.
Objectif du Projet : L'objectif était de développer un modèle de machine learning capable de prédire
avec une grande fiabilité si un article sera en rupture de stock dans un horizon de 7 jours.
Source des Données : Les données ont été extraites de trois tables de la base de données de
l'entreprise (Sage) pour obtenir une vue à 360° de chaque article :
1. Stocks : Le niveau de stock actuel par article et par dépôt.
2. Ventes : L'historique des quantités vendues pour calculer la demande.
3. Fournisseur : Le délai de livraison principal pour chaque article.
Ingénierie des Caractéristiques : Plusieurs étapes de calcul ont été nécessaires pour préparer les
données
1. Calcul de la Vente Moyenne : La demande pour chaque article a été estimée en calculant sa
vente moyenne historique.
article_id depot_id vente_moyenne
+00001 0 42.125
+00002 0 141.000
Libellé du Segment Nombre de
Clients
Recommandation d'Action Marketing
?????? Super Champions 10 Objectif : Fidélisation maximale. Accès en avant-première aux
nouveautés, programme VIP, cadeaux exclusifs.
?????? Champions 4 Objectif : Maintenir la valeur. Offres de cross-selling ciblées, invitations
à des événements, programme de fidélité avancé.
?????? Clients Actifs 98 Objectif :Augmenter la fréquence et le montant. Campagnes
promotionnelles, newsletters régulières, offres pour augmenter le
panier moyen.
⚠️ Clients à Risque 33 Objectif : Réactivation immédiate. Campagnes de "reconquête" avec
des offres attractives, sondages pour comprendre leur inactivité.

65. +00003 0 57.625
+00004 0 6.800
+00005 0 301.000
... ... ...
HVK2.5/C1-B 1 39.000
HVK2.5/C1-N 1 39.000
HVK6/C1-B 1 6.600
HVK6/C1-N 1 15.250
HVK6/C1-R 1 11.875

Tableau 5.3 : Table des ventes moyennes pour chaque Article
2. Fusion des Données : Les trois sources de données ont été fusionnées en un seul tableau. Les
valeurs manquantes (articles sans vente ou sans délai de livraison) ont été traitées,
notamment en utilisant la médiane pour les délais.

article_id depot_id stock_actuel vente_moyenne
1908 1 5.0 1.935484
032756 1 500.0 327.989529
700500758 1 1.0 1.000000
032756 1 500.0 327.989529
080041 1 199.0 17.347826
... ... ... ...
411664 0 34.0 5.333333
067552 1 99.0 18.027778
406479 0 120.0 1.666667
FCP-O320 1 12.0 8.200000
419499 1 46.0 20.742857

Tableau 5.3 : Fusion des données pour les trois source de données
Création de la Variable Cible : La variable à prédire (rupture_7j) a été créée. Un article est considéré
comme "à risque de rupture" si son stock actuel ne peut pas couvrir la demande moyenne pour les 7
prochains jours.
 jours_avant_rupture = stock_actuel / vente_moyenne
 Si jours_avant_rupture <= 7, alors rupture_7j = 1 (Oui), sinon 0 (Non).
Approche de Modélisation (Le "Comment ?")
 Caractéristiques (Features) : Le modèle a été entraîné sur les trois facteurs les plus directs
influençant une rupture :
1. stock_actuel
2. vente_moyenne (la demande)
3. delai_livraison
 Algorithme : Un modèle Random Forest Classifier a été choisi. Cet algorithme est performant,
robuste et bien adapté pour les problèmes de classification, car il combine les prédictions de
nombreux "arbres de décision" pour un résultat plus stable.

66. Résultats et Interprétation (Les "Résultats ?")
 Performance Globale : Le modèle a atteint des performances exceptionnelles sur l'ensemble
de test. Avec une précision globale (accuracy) de 99 % et un score AUC de 0.999, il
démontre une très grande capacité à distinguer les articles à risque de ceux qui ne le sont
pas.

 Analyse des Prédictions (Matrice de Confusion) : La matrice de confusion confirme
l'excellente performance du modèle :
o Vrais Négatifs (92) : 92 articles non à risque ont été correctement identifiés.
o Vrais Positifs (580) : Sur 581 articles réellement en risque de rupture, le modèle en a
correctement détecté 580. Le rappel est quasi-parfait (580/581 = 99.8%).
o Erreurs : Le modèle n'a commis que 4 erreurs au total sur 676 prédictions : 1 rupture
manquée et 3 fausses alertes.











Figure 5.6 : Matrice de Confusion

67. 5.4 Projet 4 : Prédiction des retards de paiement :

 Contexte et Objectifs (Le "Pourquoi ?")

 Problématique Métier : Les retards de paiement des clients affectent directement la
trésorerie de l'entreprise, augmentent les charges de travail du service de recouvrement et
créent une incertitude financière. Agir après le constat d'un retard est une solution réactive et
coûteuse.
 Objectif du Projet : L'objectif était de construire un modèle de machine learning proactif. Le
modèle devait être capable de prédire, dès la création d'une facture, si celle-ci présente un
risque élevé d'être payée en retard. L'enjeu principal était de maximiser la détection des
futurs retards pour anticiper les actions de suivi.

 Données et Préparation (Le "Avec Quoi ?")

 Source des Données : Une requête SQL complexe a été exécutée sur le data warehouse (Sage)
pour agréger toutes les informations pertinentes. Elle a permis de joindre des données
provenant de la facture elle-même (montants, dates), du client (type, localisation, encours) et
des règlements (dates d'échéance, dates de paiement effectif).
date_facture montant_HT Montant_TTC Montant_regle Id date_echeance date_paiement
_effectif
payee_en
_retard
05/01/2017 1840 2208 1190.4 CL0045 05/01/2016 26/01/2017 1
06/01/2017 575 690 363.26 CL0044 09/01/2017 09/01/2017 0
16/01/2017 1020 1224 1000 CL0025 28/01/2017 10/02/2017 1
17/01/2017 1079.57 1295.48 524.4 CL0128 03/02/2017 01/03/2017 1
21/01/2017 1110.66 1332.79 157 CL0266 10/02/2017 10/02/2017 0
21/01/2017 1039.5 1247.4 200000 CL0162 13/02/2017 17/02/2017 1
21/01/2017 3011.41 3613.69 1214.4 CL0162 13/02/2017 13/02/2017 0
21/01/2017 13218.5 15862.2 2391 CL0262 14/04/2017 17/04/2017 1
23/01/2017 460 552 10000 CL0044 16/02/2017 21/02/2017 1
23/01/2017 1700 2040 2000 CL0049 16/02/2017 20/02/2017 1
23/01/2017 16292 19550.4 100000 CL0262 17/02/2017 21/02/2017 1
24/01/2017 4975 5970 370 CL0266 21/02/2017 15/03/2017 1
26/01/2017 16065 19278 149488 CL0025 06/05/2017 09/05/2017 1
28/01/2017 5960 7152 3270 CL0162 30/04/2017 02/05/2017 1
........ ……… …….. …….. ……… ……… ……. …….
02/02/2019 1960 2352 2388 CL0013 18/05/2019 19/05/2019 1
02/02/2019 6653.4 7984.08 1399.62 CL0269 18/04/2019 18/04/2019 0
02/02/2019 3520 4224 12146.3 CL0001 17/06/2019 20/06/2019 1
03/02/2019 36133.85 43360.62 1100 CL0344 10/01/2019 10/01/2019 0
03/02/2019 23694.39 28433.27 2460.05 CL0344 26/01/2019 26/01/2019 0
03/02/2019 8120 9744 480 CL0266 26/01/2019 26/01/2019 0
03/02/2019 5260 6312 6397.71 CL0266 30/01/2019 30/01/2019 0
03/02/2019 1277 1532.4 11927.8 CL0372 31/01/2019 31/01/2019 0
Tableau 5.4 : Les données des factures 2017/2018/2019

68.  Création de la Variable Cible : La cible de prédiction, payee_en_retard, a été directement
calculée via la requête SQL. Elle prend la valeur 1 si la date de paiement effectif est postérieure
à la date d'échéance contractuelle, et 0 sinon.

 Préparation des Données : Le jeu de données a été soigneusement préparé pour la
modélisation :
Gestion des Nuls : Remplacement des valeurs numériques manquantes par la médiane.
Encodage : Transformation des variables textuelles comme type_client ou ville_client
en format numérique via l'encodage "one-hot".
Standardisation : Mise à l'échelle des variables numériques (StandardScaler) pour
qu'elles aient une importance comparable lors de l'entraînement du modèle.
 Approche de Modélisation (Le "Comment ?")
 Algorithme : Le modèle Random Forest Classifier a été sélectionné. C'est un algorithme
puissant et bien adapté aux données tabulaires complexes, capable de capturer les relations
non linéaires entre les caractéristiques d'une facture/client et le risque de retard.
 Processus d'Entraînement : Les données ont été divisées en un ensemble d'entraînement
(70%) et un ensemble de test (30%). Une méthode de stratification a été utilisée pour s'assurer
que la proportion de retards de paiement soit la même dans les deux ensembles, garantissant
une évaluation juste et représentative du modèle
 Résultats et Interprétation (Les "Résultats ?")
 Performances du Modèle : Le modèle a démontré une excellente performance sur les données
de test, qui n'avaient jamais été vues durant l'entraînement.

Tableau 5.4 : résultats et Interprétations





Métrique Score Interprétation
✅ Accuracy 86.2% Le modèle est correct dans 86,2% des cas.
?????? Precision 86.2% Quand le modèle prédit un retard, il a raison dans 86,2% des cas.
?????? Recall (Rappel) 99.9% C'est le résultat le plus important. Le modèle identifie la quasi-totalité des vrais
retards de paiement.
?????? F1-Score 92.6% Excellent équilibre global entre la Précision et le Rappel.

69. 5.5 Projet 5 : Système de Recommandation de Produits :

 Contexte et Objectifs (Le "Pourquoi ?")

 Problématique Métier : Pour augmenter le chiffre d'affaires et la satisfaction client,
l'entreprise cherche à mettre en place des stratégies de vente croisée (cross-selling).
Cependant, recommander manuellement des produits pertinents est complexe et peu
scalable. Une approche data-driven est nécessaire pour automatiser et personnaliser ces
recommandations.
 Objectif du Projet : L'objectif était de développer un système de recommandation en
explorant deux méthodologies :
1. Analyse du Panier Moyen : Pour découvrir des règles d'association générales entre les
produits (ex: "les clients qui achètent X achètent aussi Y").
2. Filtrage Collaboratif : Pour générer des recommandations personnalisées pour chaque
client en fonction de son historique et des comportements d'autres clients similaires.
 Données et Préparation (Le "Avec Quoi ?")
Source des Données : Les données proviennent de l'historique des ventes, extraites de la base de
données Sage. La requête SQL a permis de lier chaque transaction (DO_Piece) à un client (DO_Tiers) et
aux articles achetés (AR_Ref).

DO_Piece AR_Ref DO_Tiers
FDT2255 F6W14A CL0267
FDT2245 700500758 CL0344
FDT180013 IPC-HFW5431EP-Z CL0306
FDT2389 N015O3040MT_UBU_VG CL0357
FDT2245 CL3MC6/OR CL0344
FDT2246 4095S CL0344
…………….. ……………… ………………
FDT2246 JG926A CL0344
FDT2226 ADAP-CE255A CL0044
FDT2345 NP18-12R CL0357
FDT2245 700476005 CL0344
FDT2245 339096 CL0344
FDT2245 700479702 CL0344
FDT2245 700289762 CL0344
FDT2245 700429202 CL0344
FDT2245 700504556 CL0344
FDT2245 700417330 CL0344
FDT2245 700469869 CL0344
FDT2245 700469869 CL0344
……………. ……………… …………….

Tableau 5.5 : l'historique des ventes pour les clients

70. Approche 1 : Analyse du Panier Moyen (Market Basket Analysis)
Cette première approche cherche des règles générales applicables à tous les clients.
Méthodologie
1. Transformation des Données : Les données de ventes ont été transformées en une matrice de
paniers. Chaque ligne représente une facture et chaque colonne un produit. La valeur est 1 si
le produit est dans le panier, 0 sinon.
2. Algorithme Apriori : L'algorithme Apriori a été utilisé pour identifier les ensembles de produits
fréquemment achetés ensemble (les "itemsets fréquents").
Figure :
3. Génération des Règles d'Association : À partir de ces itemsets, des règles de la forme "Si {A}
alors {B}" ont été générées et évaluées selon 3 métriques clés :
 Support : La popularité de l'ensemble des produits.
 Confiance : La probabilité d'acheter {B} sachant que {A} est déjà dans le panier. C'est la
fiabilité de la règle.
 Lift : Indique si les produits sont achetés ensemble plus souvent que par pur hasard.
Un lift > 1 montre une réelle affinité entre les produits.

71. Résultats et Interprétation :
Le modèle a généré de nombreuses règles d'association pertinentes.
 Exemple d'interprétation d'une règle : La règle (3501/6) -> (3501/5) affiche une confiance de
1.0 et un lift de 85.2.
 Signification : Cela veut dire que 100% du temps, lorsqu'un client achète le produit
3501/6, il achète aussi le produit 3501/5.

 Action : Le lien entre ces deux produits est extrêmement fort (85 fois plus que le hasard).
Ils pourraient être des composants d'un même kit ou des produits parfaitement
complémentaires.

Approche 2 : Filtrage Collaboratif Personnalisé
Cette seconde approche vise à créer des recommandations uniques pour chaque client.
Méthodologie
1. Préparation des "Notes" : Un "rating" implicite a été créé : plus un client achète un produit,
plus sa note pour ce produit est élevée.

2. Algorithme SVD : L'algorithme SVD (Singular Value Decomposition), via la bibliothèque
Surprise, a été utilisé. C'est une technique de factorisation de matrices qui permet de découvrir
les "goûts" latents des clients et les "caractéristiques" latentes des produits pour prédire la
note qu'un client donnerait à un produit qu'il n'a jamais acheté.

3. Génération de Recommandations : Une fonction a été créée pour, à partir d'un ID client,
prédire les notes pour tous les articles non encore achetés et retourner les 10 meilleures
prédictions.

72. 6 Conclusion du Chapitre :


Ce chapitre a détaillé le passage de la conception à la réalisation concrète de la chaîne décisionnelle.
En nous appuyant sur les outils Talend et Power BI, et enfin implémentation des modèles de ML. Nous
avons mis en œuvre un processus robuste qui transforme les données opérationnelles brutes de Sage
en informations visuelles et interactives à forte valeur ajoutée. Chaque étape, de l'extraction à la
restitution, a été soigneusement construite pour répondre aux exigences de performance et de
fiabilité.

À ce stade, l'entreprise dispose d'une chaîne de Business Intelligence opérationnelle, capable
d'alimenter automatiquement les tableaux de bord et de fournir aux managers une vision claire de
leur activité. Cependant, l'objectif de notre projet ne s'arrêtait pas à l'analyse descriptive.

En derniere partie de ce chapitre a démontré comment, en s'appuyant sur un Data Warehouse propre
et structuré, il est possible de développer une série de modèles de Machine Learning pour adresser
des problématiques concrètes. nous avons mené à bien cinq projets, de la prévision à la classification

Avec la construction de cette brique prédictive, notre solution décisionnelle est désormais complète,
couvrant l'ensemble du spectre de l'analyse. La conclusion générale de ce rapport dressera le bilan
global du projet et de ses apports stratégiques pour DEWEB Technologies.

73. CONCLUSION GÉNÉRALE

Arrivés au terme de ce rapport, il convient de prendre du recul pour dresser le bilan des travaux réalisés
durant ce stage de fin d'études au sein de l'entreprise DEWEB Technologies. L'objectif initial était
ambitieux : répondre à une problématique centrale pour l'entreprise, à savoir comment transformer
ses données opérationnelles, jusqu'alors cloisonnées dans son ERP Sage 100c, en un véritable levier
de performance et un outil d'aide à la décision stratégique.

Ce projet nous a conduits à traverser l'ensemble de la chaîne de valeur de la donnée, de l'ingénierie à
la science des données. Cette conclusion propose de synthétiser les réalisations, d'évaluer les apports
et les limites de la solution, avant de conclure sur les acquis personnels et les perspectives d'évolution.

74. Synthèse des réalisations

Notre démarche, à la fois structurée et pragmatique, a permis de bâtir une solution décisionnelle
complète et fonctionnelle. Le parcours a débuté par la mise en place des fondations techniques : un
processus ETL robuste, développé sous Talend Open Studio, a été créé pour extraire, nettoyer et
fiabiliser les données issues de l'ERP. Ces données ont ensuite été centralisées au sein d'un Data
Warehouse sur PostgreSQL, dont la conception en étoile a été méticuleusement pensée pour
optimiser les futures analyses.

Sur cette base saine et performante, la brique de Business Intelligence a été déployée. Des tableaux
de bord interactifs et pertinents, créés sur Power BI, permettent aujourd'hui aux équipes de suivre en
autonomie les indicateurs clés de performance relatifs aux ventes, aux clients, aux stocks et aux
fournisseurs.

Enfin, pour dépasser l'analyse descriptive, le projet a pris une dimension prédictive avec la mise en
œuvre de cinq modèles de Machine Learning, nous avons développé des prototypes capables
d'anticiper les ventes futures, de segmenter la clientèle, de prédire les retards de paiement, d'anticiper
les ruptures de stock et de détecter des anomalies, démontrant ainsi le potentiel immense de l'analyse
avancée pour l'entreprise.

75. Bilan, apports pour l'entreprise et limites du projet

Apports pour l'entreprise : La solution mise en place apporte une valeur ajoutée tangible et multiple
à DEWEB Technologies. Le principal apport est la création d'une source de données unique et fiable,
qui met fin aux analyses manuelles, chronophages et sujettes aux erreurs. Les équipes métier
disposent désormais d'outils autonomes leur permettant de passer d'un pilotage réactif, basé sur des
constats passés, à une stratégie proactive, éclairée par des données à jour et des visualisations claires.
Les modèles prédictifs, quant à eux, offrent un avantage concurrentiel significatif en permettant
d'anticiper les risques (impayés, ruptures) et de mieux cibler les opportunités commerciales. Ce projet
initie une véritable culture de la donnée au sein de l'entreprise.

Limites du projet : Il est toutefois important de rester lucide sur les limites de ce travail. Premièrement,
la qualité de l'analyse dépend intrinsèquement de la qualité des données sources de l'ERP. Bien qu'un
nettoyage ait été effectué, une démarche de gouvernance des données à long terme serait bénéfique.
Deuxièmement, les modèles de Machine Learning ont été développés et évalués en tant que preuves
de concept (PoC). Leur intégration complète dans les processus métier nécessiterait une phase
d'industrialisation (M-Lops) qui sortait du cadre de ce stage. Enfin, le périmètre de l'analyse est pour
l'instant limité aux données de Sage 100c ; l'intégration de sources externes (CRM, données web, etc.)
pourrait encore enrichir la vision à 360°.

76. Apports personnels et perspectives d'évolution

Apports personnels : Sur le plan personnel, ce stage a été une expérience extrêmement formatrice. Il
m'a permis de développer un large éventail de compétences techniques, notamment la maîtrise de la
suite décisionnelle (Talend, PostgreSQL, Power BI) et l'application concrète des cycles de vie de projets
BI et Data Science. J'ai pu approfondir mes connaissances en modélisation de données et en
développement de modèles prédictifs avec Python et ses bibliothèques (Scikit-learn, Pandas). Au-delà
de la technique, ce projet a été une opportunité de développer des compétences professionnelles
essentielles : la gestion de projet en autonomie, la communication avec des interlocuteurs métier pour
traduire leurs besoins en solutions, ainsi que la rigueur et la capacité d'analyse critique.

Perspectives d'évolution : Ce projet, loin d'être une fin en soi, ouvre la porte à de nombreuses
perspectives d'évolution pour DEWEB Technologies :
 Industrialisation des modèles ML : Déployer les modèles les plus pertinents via des APIs pour
qu'ils puissent être consommés par d'autres applications et automatiser leur réentraînement.

 Enrichissement des données : Intégrer de nouvelles sources de données (par exemple, un CRM
ou Google Analytics) pour affiner les analyses, notamment la vision client.

 Analyse en temps réel : Explorer des technologies de streaming de données pour alimenter
certains indicateurs en temps quasi réel.

 Diffusion de la culture data : Former davantage d'utilisateurs à Power BI pour encourager le
"self-service BI" et renforcer la prise de décision basée sur les données à tous les niveaux de
l'entreprise.
Ce stage a été une démonstration réussie de la manière dont une utilisation intelligente des données
peut transformer en profondeur le pilotage d'une entreprise, la rendant plus agile, plus performante
et mieux préparée pour les défis de demain.

77. Bibliographie & Webographie

[1] “Définition de l’informatique décisionnelle.
http://theses.univ-lyon2.fr/documents/lyon2/2016/younsifz/pdfAmont/younsifztheseudl.pdf.

[2] Architecture d’un système décisionnel.
http://theses.univ-lyon2.fr/documents/lyon2/2016/younsi_fz/pdfAmont/younsi_fz_these_udl.pdf.

[3] Comparatif des outils ETL.
https://www.educba.com/talend-vs-ssis/

[4] Comparatif des outils de visualisation.
https://www.educba.com/power-bi-vs-tableau-vs-qlik/

[5] Sage 100 Comptabilité
https://www.sage.com/fr-fr/documentations-produits/#sage100cloudcomptabilite

[5] Talend Data Integration ETL
https://www.talend.com/resources/talend-job-design-patterns-and-best-practices-part-3/