Université Hassan II de Casablanca

Faculté des Sciences Ben M’Sik

Département de Mathématique et
Informatique

Mémoire de Stage de Projet Fin D’études

En vue de l’obtention du diplôme

MASTER DATA SCIENCE & BIG DATA

Projet :

Mise en place d’une solution de Business Intelligence

pour le secteur de la formation professionnelle au Maroc

Encadré par :
Réalisé par :
ABDERRAHMANE DAIF (académique)
SAAD LAKNIN Abdellaoui Oualid (professionnel)

Soutenu le 13/09/2025 devant les membres du jury :

Pr. AZZOUAZI MOHAMED Professeur à la FSBM Président de jury

Pr. DAIF ABDERRAHMANE Professeur à la FSBM Encadrant
Pr. OUNACER SOUMAYA Professeur à la FSBM Examinatrice
Pr. ARDCHIR SOUFIANE Professeur à la FSBM Examinatrice
‫م‬ ‫ي‬‫ح‬‫ِ‬ ‫ٱلر‬ ‫ن‬
‫ِ‬ ‫ٰ‬
‫م‬ ‫ح‬ ‫ٱلر‬ ‫ِ‬
‫ه‬ ‫بِسم ٱلل ٰ‬
‫َّ ِ‬ ‫ْ ِ ّ َّ ْ َ‬
 Dédicace

À mes parents bien‑aimés,

pour leur amour inconditionnel,

leurs sacrifices silencieux
et leur soutien constant dans chaque étape de ma vie.

À mes professeurs et encadrants,

pour leur transmission du savoir

et leur précieuse guidance.

Et à tous ceux qui ont cru en moi,

je vous dédie humblement ce travail.

SAAD LAKNIN
 Remerciements

Je tiens à exprimer ma profonde gratitude à toutes les personnes qui ont contribué, de près ou de
loin, à la réalisation de ce travail.

Je remercie tout d’abord mon encadrant académique, M. ABDERRAHMANE DAIF, pour sa

disponibilité, ses conseils avisés et son accompagnement tout au long de ce projet.

Je tiens également à remercier M. Abdellaoui Oualid, qui m’a accueilli(e) au sein de l’entreprise
BITBOT et m’a guidé(e) avec rigueur et bienveillance durant ce stage.

Je remercie toute l’équipe de DATA et BI, pour leur accueil chaleureux, leur esprit de collabora‑
tion, et les échanges enrichissants qui ont grandement contribué à ma progression.

Enfin, je souhaite exprimer ma reconnaissance à ma famille et à mes proches, pour leur soutien
moral constant et leurs encouragements tout au long de mon parcours universitaire.

SAAD LAKNIN
 Résumé

Ce travail s’inscrit dans le cadre de la mise en place d’une solution de Business Intelligence
dédiée au secteur de la formation professionnelle au Maroc. Le projet a consisté à concevoir et
déployer une architecture décisionnelle complète comprenant une zone de staging, un Data Wa‑
rehouse, des datamarts ainsi que des cubes OLAP. Des processus ETL ont été développés pour
assurer l’intégration, la transformation et l’historisation des données, permettant de produire des
indicateurs fiables et pertinents. Les résultats sont restitués sous forme de tableaux de bord inter‑
actifs réalisés avec Power BI Report Server, organisés autour de deux axes principaux : la partici‑
pation aux établissements de formation professionnelle (Catégorie 2) et l’offre de formation professionnelle
(Catégorie 3). Ce projet démontre l’apport stratégique de la BI dans l’amélioration du pilotage, de
l’analyse et de la prise de décision dans le domaine de la formation professionnelle.

Mots‑clés :
Business Intelligence, Data Warehouse, ETL, OLAP, Power BI, Formation Professionnelle, Tableaux
de bord, SSIS, SSAS, Indicateurs de performance.
 Abstract

This work is part of the implementation of a Business Intelligence solution dedicated to the
vocational training sector in Morocco. The project consisted in designing and deploying a com‑
plete decision‑making architecture including a staging area, a Data Warehouse, datamarts, and
OLAP cubes. ETL processes were developed to ensure the integration, transformation, and histo‑
rization of data, enabling the production of reliable and relevant indicators. The results are pre‑
sented through interactive dashboards built with Power BI Report Server, organized around two
main axes : participation in vocational training institutions (Category 2) and the offer of vocational trai‑
ning programs (Category 3). This project highlights the strategic contribution of BI in improving
decision‑making, monitoring, and analysis in the field of vocational training.

Keywords : Business Intelligence, Data Warehouse, ETL, OLAP, Power BI, Vocational Training, Dash‑
boards, SSIS, SSAS, Performance Indicators.
 Liste des abréviations

Abréviation Signification

BI Business Intelligence

ETL Extract, Transform, Load

OLAP Online Analytical Processing

SSIS SQL Server Integration Services

SSAS SQL Server Analysis Services

SGBD Système de Gestion de Base de Données

DWH Data Warehouse

EFP Établissements de Formation Professionnelle

KPI Key Performance Indicator

OFPPT Office de la Formation Professionnelle et de la Promo‑

tion du Travail

SQL Structured Query Language

MDX Multidimensional Expressions

Rapport de fin d’études TABLE DES MATIÈRES

Table des matières

INTRODUCTION GÉNÉRALE 15

Présentation de l’organisme d’accueil 16

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Présentation de Startup BITBOT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Domaines d’Expertise et Services d’entreprise . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Robotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Smart Chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Artificial Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Emerging Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Développement Web avec C#.NET & Angular . . . . . . . . . . . . . . . . . . . 19

4 Organisation et Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Organigramme de L’entreprise BITBOT . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Partenaires institutionnels et privés . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Collaborations et projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Contexte général du projet et cahier des charges 23

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Présentation des Établissements de Formation Professionnelle (EFP) . . . . . . 24
2.3 Rôle et mission des EFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Organisation et typologie des EFP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Niveaux et filières de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Acteurs de la formation professionnelle . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Enjeux actuels de l’EFP au Maroc . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Problématique, motivations, objectifs et enjeux du projet . . . . . . . . . . . . . . . . 28

3.1 Problématique et motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Objectifs généraux du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Enjeux du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Réalisé par : SAAD LAKNIN Page 7

Rapport de fin d’études TABLE DES MATIÈRES

4 Étude du besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Identification des besoins métiers et techniques . . . . . . . . . . . . . . . . . . 29
4.2 Analyse des processus existants . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Situation actuelle vs situation cible . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Exigences fonctionnelles et non‑fonctionnelles . . . . . . . . . . . . . . . . . . . . . . 32

5.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Exigences non‑fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1 Accès à une base externe Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Mise en place de processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Utilisation de cubes analytiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4 Performance et sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Contraintes organisationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Méthodologie de travail : le cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9 Étapes de réalisation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

10 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

État de l’art et travaux connexes 41

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1 Définition et concepts clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2 Objectifs et enjeux de la BI dans les organisations . . . . . . . . . . . . . . . . . 42
2.3 Évolution de la BI : des rapports statiques vers l’analytique avancée . . . . . . 43
2.4 Comparaison entre systèmes décisionnels et systèmes opérationnels . . . . . . 43

3 L’architecture du processus de la BI et ces principales phases : . . . . . . . . . . . . . 44

3.1 Les Principes phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Les outils utilisés dans ces déférentes phases . . . . . . . . . . . . . . . . . . . . . . . 45

4.1 Processus ETL (Extraction, Transformation, Loading) . . . . . . . . . . . . . . . 45
4.2 Data Warehouse et Data Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Approches de modélisation des entrepôts de données . . . . . . . . . . . . . . . 49
4.4 Modélisation dimensionnelle et schémas . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Les différents types de schémas dimensionnels . . . . . . . . . . . . . . . . . . . 52
4.6 Définition de l’OLAP (Online Analytical Processing) . . . . . . . . . . . . . . . 55
4.7 Caractéristiques d’un cube OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Réalisé par : SAAD LAKNIN Page 8

Rapport de fin d’études TABLE DES MATIÈRES

4.8 Opérations OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.9 Types de cubes OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.10 Avantages de l’analyse multidimensionnelle . . . . . . . . . . . . . . . . . . . 58

5 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Articles scientifiques et études de cas . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Comparaison entre les résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Conception et mise en œuvre de la solution 63

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2 Architecture proposée pour ce projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.1 Architecture proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.2 Pourquoi l’approche Inmon ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3 Conception de l’Architecture et du Modèle de Données BI . . . . . . . . . . . . . . . 66

3.1 Cas d’Utilisation du Système BI . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2 Modélisation des Interactions : Diagrammes de Séquence . . . . . . . . . . . . 69
3.3 Diagramme d’Activité : Flux vers la Zone de Staging . . . . . . . . . . . . . . . 71
3.4 Diagramme d’Activité : Flux vers le Data Warehouse (DWH) . . . . . . . . . . 72
3.5 Diagramme d’Activité : Flux vers les Datamarts . . . . . . . . . . . . . . . . . . 73
3.6 Modèle de Données du Data Warehouse . . . . . . . . . . . . . . . . . . . . . . 74

4 Conception du Data Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1 Catégorie 2 : Accès et participation au système de formation professionnelle . 76
4.2 Catégorie 3 : L’offre de formation professionnelle . . . . . . . . . . . . . . . . . 78

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Réalisation et présentation des résultats 81

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

2 Environnement de développement et outils utilisés . . . . . . . . . . . . . . . . . . . 82

2.1 Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.2 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.3 SQL Server Integration Services (SSIS) . . . . . . . . . . . . . . . . . . . . . . . . 83
2.4 SQL Server Analysis Services (SSAS) . . . . . . . . . . . . . . . . . . . . . . . . 83
2.5 Power BI et Power BI Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.6 UML (Unified Modeling Language) . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.7 Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Réalisé par : SAAD LAKNIN Page 9

Rapport de fin d’études TABLE DES MATIÈRES

2.8 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.9 Microsoft Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.10 Langages SQL et MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3 Collaboration et gestion de projet avec GitHub . . . . . . . . . . . . . . . . . . . . . . 86

3.1 Structure du projet sur GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4 Développement des traitements ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.1 Les flux ETL de la zone de staging . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2 Zone Data Warehouse (DWH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3 Zone Datamarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5 Mise en place des Cubes OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.1 Cube OLAP Catégorie 2 : Participation EFP . . . . . . . . . . . . . . . . . . . . . 96
5.2 Cube OLAP Catégorie 3 : Offre de Formation Professionnelle . . . . . . . . . . 97
5.3 Les requêtes MDX pour le Cube Catégorie 2 : Participation EFP . . . . . . . . . 97
5.4 Les requêtes MDX pour le Cube Catégorie 3 : Offre de Formation Professionnelle 98

6 Visualisation et Restitution des Données . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.1 Dashboard Catégorie 2 : Participation EFP . . . . . . . . . . . . . . . . . . . . . 99
6.2 Dashboard Catégorie 3 : Offre de formation professionnelle . . . . . . . . . . . 101

7 Déploiement des Tableaux de Bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

CONCLUSION GÉNÉRALE 104

Réalisé par : SAAD LAKNIN Page 10

Rapport de fin d’études TABLE DES FIGURES

Table des figures

1.1 Logo de Bitbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3 Intelligence Artificielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4 Internet of things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5 Développement Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6 Organigramme des services de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . 20

1.7 Principaux partenaires et collaborations de l’entreprise. . . . . . . . . . . . . . . . . . 21

2.1 OFFPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 Niveaux de L’OFPPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Objectifs généraux du projet : dimension métier . . . . . . . . . . . . . . . . . . . . . 29

2.4 Processus de flux actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5 Exigences Fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.6 Méthodologie de travail basée sur le cycle en V . . . . . . . . . . . . . . . . . . . . . 38

2.7 Planification du projet BI entre mars et juillet 2025 . . . . . . . . . . . . . . . . . . . . 40

3.1 Architecture de la Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3 Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4 Data Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.5 Approche Inmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.6 Approche kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.7 Exemple de table de faits et table de dimension . . . . . . . . . . . . . . . . . . . . . 52

3.8 Schema Etoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.9 Schema Flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.10 Schema Flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.11 cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.12 Opération Cube OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.13 Type de Cube OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Réalisé par : SAAD LAKNIN Page 11

Rapport de fin d’études TABLE DES FIGURES

4.1 Architecture de la Solution BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Use Case de Système décisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3 Séquence d’alimentation de la zone de staging par l’ETL . . . . . . . . . . . . . . . . 69

4.4 Diagramme de séquence du processus ETL vers le Data Warehouse (3NF) . . . . . . 69

4.5 Diagramme de séquence du processus ETL vers les Datamarts et les Cubes OLAP . 70

4.6 Diagramme de séquence de la consultation des tableaux de bord via Power BI . . . 71

4.7 Diagramme d’activité — Flux d’alimentation de la Zone de Staging . . . . . . . . . . 72

4.8 Diagramme d’activité — Flux de chargement du Staging vers le Data Warehouse (3NF) 73

4.9 Diagramme d’activité — Flux de construction et alimentation des Datamarts . . . . 74

4.10 Modèle relationnel du Data Warehouse (3NF) : tables et clés de liaison. . . . . . . . 74

4.11 Catégorie 2 — Accès & participation . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.12 Datamart Catégorie 2 — Accès & participation . . . . . . . . . . . . . . . . . . . . . 78

4.13 Catégorie 3 — Offre de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.14 Datamart Catégorie 3 — Offre de formation . . . . . . . . . . . . . . . . . . . . . . . 80

5.1 Oracle Database — système de gestion de base de données relationnelle. . . . . . . . 82

5.2 SQL Server — plateforme de gestion et de structuration des données. . . . . . . . . . 83

5.3 SSIS — outil d’intégration et de transformation des données (ETL). . . . . . . . . . . 83

5.4 SSAS — analyses multidimensionnelles et cubes OLAP. . . . . . . . . . . . . . . . . 83

5.5 Power BI — visualisation et reporting interactif. . . . . . . . . . . . . . . . . . . . . . 84

5.6 UML — langage de modélisation unifié. . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.7 Visual Studio — environnement de développement intégré (IDE). . . . . . . . . . . . 85

5.8 GitHub — gestion de versions et collaboration sur le code. . . . . . . . . . . . . . . . 85

5.9 Microsoft Teams — outil de communication et de collaboration. . . . . . . . . . . . . 86

5.10 Langages SQL et MDX — interrogation relationnelle et multidimensionnelle. . . . 86

5.11 Structure du projet collaboratif sur GitHub. . . . . . . . . . . . . . . . . . . . . . . . 87

5.12 Flux SSIS de chargement des données de la table CANDIDAT Flux de Controle . . . . 89

5.13 Flux SSIS de chargement des données de la table CANDIDAT . . . . . . . . . . . . . . 89

5.14 Flux SSIS de chargement des données de la table BENEFICIAIRE . . . . . . . . . . . 90

5.15 Flux SSIS de chargement des données de la table PROGRAMME_VALIDATION_REQUEST 91

Réalisé par : SAAD LAKNIN Page 12

Rapport de fin d’études TABLE DES FIGURES

5.16 Flux SSIS de chargement des données de la table FILIERE . . . . . . . . . . . . . . . 91

5.17 Flux SSIS de chargement des données vers la table CANDIDAT DWH . . . . . . . . . 92

5.18 Flux SSIS de chargement des données vers la table PROGRAMME VALIDATION REQUEST
DWH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.19 Flux SSIS de chargement des données vers la table PROVINCE DWH . . . . . . . . . 93

5.20 Flux SSIS de chargement des données vers la table FILIÈRE DWH . . . . . . . . . . 93

5.21 Flux SSIS de chargement de la table de faits Accès et Participation EFP . . . . . 94

5.22 Flux SSIS de chargement de la table de faits Offre de Formation Professionnelle 95

5.23 Cube OLAP de la catégorie 2 : Participation EFP . . . . . . . . . . . . . . . . . . . 96

5.24 Cube OLAP de la catégorie 3 : Offre de Formation Professionnelle . . . . . . . 97

5.25 Dashboard Catégorie 2 – Indicateurs globaux de la participation EFP . . . . . . . . 99

5.26 Dashboard Catégorie 2 – Bénéficiaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.27 Dashboard Catégorie 2 – Candidat et Taux d’affluence vers la FP . . . . . . . . . . . 100

5.28 Dashboard Catégorie 2 – Version avec filtres dynamiques (année, région) . . . . . . 100

5.29 Dashboard Catégorie 3 – Indicateurs globaux de l’offre de formation professionnelle 101

5.30 Dashboard Catégorie 3 – Répartition par région et par programme . . . . . . . . . 101

5.31 Dossier déployé sur Power BI Report Server – Catégorie 2 (Accès et Participation
aux EFP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.32 Dossier déployé sur Power BI Report Server – Catégorie 3 (Offre de Formation Pro‑
fessionnelle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Réalisé par : SAAD LAKNIN Page 13

Rapport de fin d’études LISTE DES TABLEAUX

Liste des tableaux

2.1 Acteurs de la formation professionnelle au Maroc et leurs rôles . . . . . . . . . . . . 27

2.2 Comparaison entre la situation actuelle et la situation cible avec une solution BI . . 32

3.1 Comparaison entre systèmes opérationnels et systèmes décisionnels . . . . . . . . . 44

3.2 Comparaison des approches Inmon, Kimball et Data Vault [18] . . . . . . . . . . . . 51

3.3 Tableau comparatif des travaux connexes en Business Intelligence . . . . . . . . . . 61

Réalisé par : SAAD LAKNIN Page 14

Rapport de fin d’études INTRODUCTION GÉNÉRALE

INTRODUCTION GÉNÉRALE

« Data is useless without the ability to turn it into information and insight. » — Carly Fiorina
Aujourd’hui, dans un monde où la donnée est devenue un atout stratégique, les organisa‑
tions cherchent à mieux comprendre, analyser et exploiter l’information dont elles disposent pour
prendre des décisions éclairées. La Business Intelligence s’inscrit pleinement dans cette logique :
elle réunit un ensemble d’outils, de méthodes et de bonnes pratiques qui transforment de simples
données brutes en connaissances exploitables.
Dans le secteur de la formation professionnelle au Maroc, cette capacité d’analyse est parti‑
culièrement importante. Disposer d’indicateurs fiables et actualisés permet non seulement d’éva‑
luer l’efficacité des programmes de formation, mais aussi d’anticiper les besoins en compétences,
d’orienter les choix pédagogiques et de mieux répartir les ressources disponibles. Pourtant, dans
la réalité, les données proviennent souvent de systèmes différents, sont fragmentées et parfois
difficiles à exploiter directement.
C’est dans ce contexte que s’inscrit notre projet. Nous avons choisi de mettre en place une
solution décisionnelle basée sur un Data Warehouse, afin de centraliser, organiser et structurer
ces données. Cette architecture permet ensuite de construire des cubes OLAP, offrant une analyse
multidimensionnelle et une exploration flexible des informations. Combinée à des tableaux de
bord interactifs, elle ouvre la voie à un suivi précis des KPI : nombre d’inscrits, taux de réussite,
répartition par région, popularité des filières, etc.
Ce rapport décrit et illustre pas à pas la réalisation de cette solution : depuis l’analyse des
besoins et la conception du modèle de données, jusqu’à l’intégration via les processus ETL, la
création des cubes et la visualisation des résultats. Il met en lumière les choix techniques effec‑
tués, les défis rencontrés, ainsi que la valeur ajoutée apportée par la BI au service de la formation
professionnelle au Maroc.

Réalisé par : SAAD LAKNIN Page 15

Rapport de fin d’études Présentation de l’organisme d’accueil

Chapitre 1 :
Présentation de l’organisme d’accueil

Réalisé par : SAAD LAKNIN Page 16

Rapport de fin d’études Présentation de l’organisme d’accueil

1 Introduction
Le succès d’un projet de stage repose en grande partie sur la compréhension du cadre dans le‑
quel il s’inscrit. Ainsi, avant de présenter le travail réalisé, il est essentiel de découvrir l’organisme
d’accueil, son environnement, ses domaines d’expertise ainsi que son organisation interne.
Ce chapitre est consacré à la présentation de la startup Bitbot, une entreprise innovante spéciali‑
sée dans la robotique, l’intelligence artificielle , l’Internet des objets et le Big Data. Après un aperçu
général de la société et de ses activités, nous mettrons en lumière ses principaux domaines d’exper‑
tise, ses services, ainsi que son organisation interne. Nous évoquerons également ses partenariats
stratégiques et ses projets phares, qui illustrent son rôle actif dans l’écosystème technologique.
Cette présentation permettra de mieux comprendre le contexte professionnel dans lequel s’est
déroulé mon stage et servira de base pour appréhender les enjeux du projet de Business Intelli‑
gence qui sera exposé dans les chapitres suivants.

2 Organisme d’accueil

2.1 Présentation de Startup BITBOT

FIG. 1.1 : Logo de Bitbot

Bitbot est une startup innovante, créée en 2012 et implantée au Casablanca Technopark. Spé‑
cialisée dans les technologies de pointe, elle intervient dans des domaines tels que la robotique,
l’intelligence artificielle (IA), l’Internet des objets (IoT) et le Big Data. Elle conçoit et développe des
solutions créatives et performantes, allant des robots éducatifs interactifs aux systèmes intelligents
capables de collecter, analyser et exploiter les données pour faciliter la prise de décision. L’entre‑
prise se distingue par son approche centrée sur l’innovation et la qualité, combinant recherche et
développement, applications pratiques et technologies émergentes. Bitbot vise à répondre aux be‑
soins croissants en automatisation, connectivité et transformation numérique, tout en favorisant
l’apprentissage, l’expérimentation et la valorisation des données à travers des solutions adaptées
aux différents secteurs industriels et éducatifs.

Réalisé par : SAAD LAKNIN Page 17

Rapport de fin d’études Présentation de l’organisme d’accueil

3 Domaines d’Expertise et Services d’entreprise

3.1 Robotics
La startup conçoit des robots académiques destinés à l’apprentissage, à l’expérimentation et à
la formation. Ces robots offrent une approche interactive et pratique permettant aux utilisateurs
de découvrir la programmation, l’électronique et l’intelligence artificielle de manière ludique et
pédagogique.

FIG. 1.2 : Robots

3.2 Smart Chips

Des puces intelligentes performantes sont développées et intégrées dans divers appareils pour
offrir rapidité, autonomie et prise de décision en temps réel, au service de la connectivité et de
l’innovation.

3.3 Artificial Intelligence

L’intégration de l’intelligence artificielle permet aux robots de s’adapter au niveau de chaque
utilisateur, de proposer des parcours personnalisés et d’interagir de façon intuitive et motivante.

FIG. 1.3 : Intelligence Artificielle

3.4 Machine Learning

Grâce au machine learning, les solutions évoluent et s’améliorent avec le temps. Elles ap‑
prennent des comportements des utilisateurs afin d’accroître leur efficacité pédagogique et de
s’adapter aux différents styles d’apprentissage.

3.5 Emerging Technologies

Les technologies émergentes, telles que la réalité augmentée, la vision par ordinateur et l’In‑
ternet des objets (IoT), sont explorées afin d’enrichir l’expérience éducative et de rendre l’appren‑
tissage plus immersif et connecté au monde réel.

Réalisé par : SAAD LAKNIN Page 18

Rapport de fin d’études Présentation de l’organisme d’accueil

FIG. 1.4 : Internet of things

3.6 Développement Web avec C#.NET & Angular

Des applications web robustes, sécurisées et ergonomiques sont conçues en utilisant C#.NET
pour la partie back‑end et Angular pour la partie front‑end, offrant ainsi des solutions perfor‑
mantes et adaptées aux besoins spécifiques des clients.

FIG. 1.5 : Développement Web

4 Organisation et Structure

4.1 Organigramme de L’entreprise BITBOT

L’entreprise est structurée autour d’une direction centrale assurée par Mouad Bettach, Direc‑
teur Général. Sous sa supervision, plusieurs services spécialisés travaillent en étroite collaboration
pour assurer le bon fonctionnement et le développement stratégique de l’entreprise :

• Service Développement (Dev) — Ce service est responsable de la conception, du dévelop‑

pement et de la maintenance des applications et plateformes logicielles de l’entreprise. Il
veille à la qualité du code, à la sécurité des systèmes et à l’implémentation des nouvelles
fonctionnalités adaptées aux besoins des clients.

Réalisé par : SAAD LAKNIN Page 19

Rapport de fin d’études Présentation de l’organisme d’accueil

• Service Data & Intelligence Artificielle (IA) — Ce service se concentre sur l’exploitation des
données, l’analyse avancée, le machine learning et le développement de solutions d’intelli‑
gence artificielle. Il permet à l’entreprise de prendre des décisions basées sur les données et
de proposer des produits intelligents et adaptés aux utilisateurs.C’est au sein de ce service
que j’ai effectué mon stage, ce qui m’a permis de participer à l’analyse des données et à la
création de tableaux de bord BI.

• Service Internet of Things (IoT) — Chargé du développement et de l’intégration de solu‑

tions connectées, ce service conçoit des dispositifs IoT innovants et veille à leur compatibilité
avec les systèmes existants. Il contribue à la transformation digitale et à l’amélioration de la
connectivité des solutions de l’entreprise.

• Service Ressources Humaines (HR) — Ce service gère le recrutement, la formation, le suivi

et le bien‑être du personnel. Il s’assure que l’organisation dispose des compétences néces‑
saires pour atteindre ses objectifs et favorise le développement professionnel des collabora‑
teurs.

Cette organisation permet une coordination efficace entre les différents pôles afin de mener à
bien les projets de l’entreprise.

FIG. 1.6 : Organigramme des services de l’entreprise

4.2 Partenaires institutionnels et privés

L’entreprise collabore étroitement avec plusieurs acteurs majeurs du secteur. Ces partenariats
sont essentiels pour bénéficier de solutions avancées, accélérer le développement technologique

Réalisé par : SAAD LAKNIN Page 20

Rapport de fin d’études Présentation de l’organisme d’accueil

et mener à bien des projets innovants.

• Microsoft et Azure : ces collaborations permettent à l’entreprise d’exploiter pleinement les

solutions cloud, les outils de Business Intelligence et les plateformes de développement Mi‑
crosoft, offrant ainsi une infrastructure solide pour ses projets logiciels et analytiques.

• Oracle : cette coopération aide l’entreprise à gérer et exploiter efficacement de grandes quan‑
tités de données, renforçant ses capacités analytiques et facilitant la prise de décision basée
sur les données.

• Partenariats IoT : l’entreprise s’appuie sur des experts et freelances spécialisés en électro‑
nique embarquée et IoT pour concevoir et intégrer des prototypes technologiques adaptés
aux besoins spécifiques de chaque projet, garantissant innovation et fiabilité.

(a) Microsoft (b) Azure

(c) Oracle

FIG. 1.7 : Principaux partenaires et collaborations de l’entreprise.

4.3 Collaborations et projets

Ces partenariats se traduisent concrètement par des projets stimulants et variés. Pour le déve‑
loppement de prototypes IoT, l’entreprise :

• analyse les besoins techniques et valide les choix technologiques ;

• conçoit des circuits électroniques intégrant capteurs, microcontrôleurs et systèmes de com‑

munication sans fil ;

• réalise les schémas et le routage PCB avec des outils comme KiCad ou Altium ;

• développe et intègre des modules IoT utilisant Zigbee, LoRa, Wi‑Fi, BLE ou MQTT ;

Réalisé par : SAAD LAKNIN Page 21

Rapport de fin d’études Présentation de l’organisme d’accueil

• prototype, teste et documente l’ensemble des solutions pour assurer leur performance et leur
fiabilité.

En parallèle, l’entreprise investit également dans des projets à forte valeur ajoutée dans diffé‑
rents domaines :

Intelligence Artificielle (IA)

Mise en place de solutions de traitement automatique du langage, de systèmes de recomman‑
dation, ainsi que d’algorithmes de prédiction et d’optimisation adaptés aux besoins des clients.

Développement Web
Conception et réalisation d’applications web modernes basées sur les frameworks .NET et An‑
gular, garantissant des solutions robustes, évolutives et centrées sur l’expérience utilisateur.

Business Intelligence (BI)

Développement de projets décisionnels en utilisant SQL Server Integration Services (SSIS)
pour la migration, le traitement et l’intégration des données, ainsi que la mise en place de tableaux
de bord interactifs et pertinents pour l’aide à la décision.
Grâce à ces collaborations et à la diversité des projets réalisés, l’entreprise transforme rapide‑
ment les idées en solutions concrètes et innovantes. Elle bénéficie également d’un échange constant
de connaissances et d’expertises, ce qui lui permet de rester à la pointe des technologies émergentes
et d’étendre son influence sur le marché national et international. L’accent est mis sur l’innovation
continue, la qualité des produits, et l’adaptation aux besoins réels des clients.

5 Conclusion
En conclusion, la découverte de l’organisme d’accueil a permis d’aller au‑delà d’une simple
présentation descriptive pour comprendre la logique qui anime Bitbot : une structure jeune, tour‑
née vers l’innovation, qui investit dans des technologies de rupture et s’appuie sur une organisa‑
tion interne agile. Cette analyse met en évidence non seulement ses atouts stratégiques et techno‑
logiques, mais aussi l’environnement stimulant dans lequel le stage a été réalisé. Elle offre ainsi
une lecture globale du cadre professionnel et constitue une transition naturelle vers l’étude du
contexte du projet de Business Intelligence développé par la suite.

Réalisé par : SAAD LAKNIN Page 22

Rapport de fin d’études Contexte général du projet et cahier des charges

Chapitre 2 :
Contexte général du projet et cahier des
charges

Réalisé par : SAAD LAKNIN Page 23

Rapport de fin d’études Contexte général du projet et cahier des charges

1 Introduction
L’objectif de ce chapitre est de présenter le contexte général du projet ainsi que le cahier des
charges qui en découle. Après avoir introduit la problématique et les motivations qui ont conduit
à la mise en place d’une solution de Business Intelligence pour le secteur de la formation profes‑
sionnelle au Maroc, nous exposerons les objectifs poursuivis ainsi que les enjeux liés à ce projet.
Par ailleurs, une attention particulière sera accordée à la présentation du secteur de la formation
professionnelle, en mettant en avant son importance stratégique pour l’économie marocaine et les
défis auxquels il fait face. Enfin, nous procéderons à l’analyse des besoins, à l’identification des
contraintes et à la formulation du cahier des charges fonctionnel et technique qui serviront de
base pour la conception et la réalisation de la solution proposée.

2 Contexte général du projet

2.1 Présentation du projet

Le projet que nous entreprenons s’inscrit dans le cadre de la mise en place d’une solution dé‑
cisionnelle permettant d’exploiter et de valoriser les données relatives à la formation profession‑
nelle au Maroc. L’objectif est de concevoir un système de Business Intelligence (BI) qui permette
d’améliorer la visibilité, l’analyse et la prise de décision en s’appuyant sur des données fiables et
consolidées.
La nature du projet est à la fois technique et organisationnelle. Sur le plan technique, il s’agit
de mettre en place une architecture intégrant un entrepôt de données, des processus d’alimentation
(ETL) ainsi que des outils de reporting et de visualisation tels que Power BI ou Tableau. Sur le plan
organisationnel, le projet vise à renforcer la capacité de pilotage et d’évaluation des programmes
de formation, en offrant aux décideurs des indicateurs clairs et actualisés.
Le périmètre du projet couvre l’ensemble des processus liés à la collecte, au traitement et à
l’analyse des données issues des établissements de formation, qu’ils soient publics ou privés. Les
résultats attendus consistent en la mise à disposition de tableaux de bord interactifs et de rapports
analytiques facilitant la prise de décision stratégique.

2.2 Présentation des Établissements de Formation Professionnelle (EFP)

Les Établissements de Formation Professionnelle (EFP) représentent l’un des piliers du sys‑
tème éducatif marocain. Ils constituent un espace d’apprentissage pratique et théorique destiné
à préparer les jeunes et les adultes à intégrer le marché du travail, en leur offrant des compé‑
tences techniques et professionnelles adaptées aux besoins des différents secteurs économiques.
Ces établissements jouent un rôle fondamental dans la stratégie nationale de développement des
ressources humaines et dans la promotion de l’employabilité.

Réalisé par : SAAD LAKNIN Page 24

Rapport de fin d’études Contexte général du projet et cahier des charges

FIG. 2.1 : OFFPT

2.3 Rôle et mission des EFP

Les missions principales des EFP peuvent être résumées comme suit :

• Assurer des formations qualifiantes et diplômantes dans des filières diversifiées.

• Répondre aux besoins en main‑d’œuvre qualifiée des entreprises et des secteurs porteurs.

• Accompagner les politiques publiques en matière d’insertion professionnelle et de lutte contre

le chômage.

• Promouvoir la formation continue pour les salariés en activité.

• Encourager l’esprit d’initiative et l’entrepreneuriat chez les jeunes diplômés.

Ainsi, les EFP ne se limitent pas à dispenser des cours, mais s’inscrivent dans une logique
globale de développement du capital humain.

2.4 Organisation et typologie des EFP

Les établissements de formation professionnelle au Maroc se distinguent par leur diversité,
tant au niveau de leur statut que de leur offre de formation. On peut en distinguer plusieurs caté‑
gories :

• Les EFP publics : gérés principalement par l’Office de la Formation Professionnelle et de

la Promotion du Travail (OFPPT), qui constitue le plus grand opérateur public dans ce do‑
maine. Ils sont implantés dans toutes les régions du Royaume et couvrent différents niveaux
de qualification (spécialisation, qualification, technicien, technicien spécialisé).

• Les EFP sectoriels : rattachés à certains départements ministériels ou établissements publics

(santé, tourisme, agriculture, artisanat, etc.), et qui répondent à des besoins spécifiques de
chaque secteur.

Réalisé par : SAAD LAKNIN Page 25

Rapport de fin d’études Contexte général du projet et cahier des charges

• Les EFP privés : en pleine croissance, ils complètent l’offre publique et proposent des for‑
mations adaptées, notamment dans les domaines du management, de l’informatique et des
services.

• Les centres de formation par apprentissage (CFA) : qui favorisent l’alternance entre la for‑
mation en établissement et l’expérience en entreprise, renforçant ainsi l’employabilité des
jeunes.

2.5 Niveaux et filières de formation

Les EFP dispensent des formations couvrant plusieurs niveaux :

• Niveau spécialisation : destiné aux jeunes ayant un niveau d’études inférieur au collège, il
vise l’acquisition de compétences de base dans un métier précis.

• Niveau qualification : ouvert aux candidats ayant au minimum le niveau de la 9ème année
du collège, il prépare à des postes d’ouvriers qualifiés.

• Niveau technicien : accessible aux élèves ayant un niveau de 2ème année du lycée, il prépare
à des postes intermédiaires.

• Niveau technicien spécialisé : réservé aux bacheliers, il forme des profils capables d’occuper
des postes de responsabilité technique et de supervision.

FIG. 2.2 : Niveaux de L’OFPPT

Les filières de formation proposées sont variées et couvrent plusieurs secteurs : industrie, bâtiment
et travaux publics, hôtellerie‑tourisme, gestion‑commerce, santé, technologies de l’information et

Réalisé par : SAAD LAKNIN Page 26

Rapport de fin d’études Contexte général du projet et cahier des charges

communication, artisanat, etc. Cette diversité témoigne de la volonté d’adapter l’offre de formation
aux besoins changeants du marché du travail.

2.6 Acteurs de la formation professionnelle

Acteur Rôle principal

Ministère de l’Inclusion Définit les politiques nationales, fixe les objectifs stratégiques, co‑
Économique, de la Petite ordonne les différents acteurs et veille à l’adéquation des forma‑
Entreprise, de l’Emploi et tions avec les besoins du marché.
des Compétences

OFPPT Premier opérateur public : gère un vaste réseau d’établissements,

propose des filières adaptées, assure la formation initiale et conti‑
nue, et favorise l’insertion professionnelle des jeunes.

Secteur privé Complète l’offre publique, propose des formations spécialisées,

souvent dans l’informatique, le management et les services, par‑
ticipe à l’alternance et à la formation par apprentissage.

Centres de formation par Favorisent l’alternance entre formation théorique et pratique en

apprentissage (CFA) entreprise, renforçant ainsi l’employabilité des jeunes.

Partenaires sociaux et Participent à l’adaptation des programmes de formation aux be‑

économiques (entreprises, soins réels du marché et accompagnent l’insertion profession‑
syndicats, associations) nelle des diplômés.

TAB. 2.1 : Acteurs de la formation professionnelle au Maroc et leurs rôles

2.7 Enjeux actuels de l’EFP au Maroc

Les enjeux actuels de l’Éducation et de la Formation Professionnelle (EFP) au Maroc s’articulent
autour de trois dimensions principales : la digitalisation, l’emploi et l’adéquation formation/em‑
ploi.
D’abord, la digitalisation constitue un levier essentiel pour moderniser les programmes et les
méthodes pédagogiques. Elle permet non seulement d’intégrer les technologies numériques dans
les processus d’apprentissage, mais aussi de développer les compétences digitales chez les forma‑
teurs et les apprenants. De plus, la mise en place de plateformes d’e‑learning et d’outils numé‑
riques favorise un accès élargi à la formation, tout en préparant les jeunes aux métiers émergents
liés à la transformation digitale des entreprises.
Ensuite, en matière d’emploi, l’EFP joue un rôle crucial dans la réduction du chômage des
jeunes en améliorant leur insertion professionnelle. Cet objectif passe par le renforcement des

Réalisé par : SAAD LAKNIN Page 27

Rapport de fin d’études Contexte général du projet et cahier des charges

formations pratiques et des stages en entreprise, qui facilitent l’acquisition de compétences opé‑
rationnelles. Il implique également une veille constante sur l’évolution du marché du travail afin
d’adapter l’offre de formation aux secteurs les plus porteurs de l’économie nationale.
Enfin, l’adéquation formation/emploi demeure un défi central. L’alignement des programmes
de formation sur les compétences effectivement demandées par les entreprises est indispensable
pour répondre aux attentes du marché. Dans ce sens, les partenariats entre l’EFP et le secteur privé
permettent de co‑construire des cursus plus pertinents et mieux adaptés aux réalités profession‑
nelles. La promotion de filières techniques et stratégiques pour le développement économique,
ainsi que l’évaluation régulière de l’impact des formations sur l’insertion professionnelle, sont
également des enjeux majeurs.

3 Problématique, motivations, objectifs et enjeux du projet

3.1 Problématique et motivations

Le système de l’Éducation et de la Formation Professionnelle (EFP) au Maroc connaît depuis
plusieurs années une dynamique de réformes et de modernisation. Cependant, malgré les efforts
engagés, certaines limites persistent et freinent l’efficacité globale du dispositif.
Les données relatives à la formation et à l’insertion professionnelle sont souvent dispersées
entre différents acteurs : ministères, organismes de formation, établissements privés, entreprises,
etc. Cette dispersion rend difficile la consolidation et l’exploitation des informations. Il n’existe pas
toujours de base de données centralisée permettant de suivre le parcours complet d’un apprenant,
depuis son inscription jusqu’à son insertion sur le marché du travail.
De plus, il existe un manque de visibilité sur certains indicateurs clés tels que le taux d’aban‑
don, le taux d’insertion ou encore l’adéquation réelle entre les formations suivies et les métiers
exercés par les lauréats. Les décideurs peinent ainsi à disposer d’outils précis pour évaluer l’im‑
pact des politiques de formation et ajuster les programmes en conséquence.
Dans ce contexte, une solution de Business Intelligence (BI) s’avère particulièrement perti‑
nente. La BI permet de collecter, centraliser, transformer et analyser de grandes quantités de don‑
nées provenant de sources diverses. Grâce aux tableaux de bord interactifs, les utilisateurs peuvent
accéder à des informations synthétiques et visuelles, facilitant ainsi la prise de décision et le pilo‑
tage stratégique.

3.2 Objectifs généraux du projet

Les objectifs de ce projet s’inscrivent principalement dans deux dimensions : métier et tech‑
nique.
D’un point de vue métier, il s’agit de concevoir une solution décisionnelle capable de transfor‑
mer les données en informations exploitables afin de soutenir la prise de décision. L’objectif est

Réalisé par : SAAD LAKNIN Page 28

Rapport de fin d’études Contexte général du projet et cahier des charges

de fournir aux acteurs concernés des indicateurs fiables et pertinents, facilitant ainsi l’analyse de
l’activité, l’optimisation des processus et l’anticipation des besoins stratégiques.
Sur le plan technique, le projet vise la mise en œuvre d’une architecture décisionnelle fiable et
performante. Cela comprend l’utilisation d’outils adaptés pour l’intégration et le traitement des
données, la conception d’un entrepôt de données structuré ainsi que la réalisation de rapports et
de tableaux de bord interactifs. L’enjeu est de garantir la qualité, la sécurité et l’évolutivité de la
solution tout en assurant une exploitation optimale des données disponibles.
Cette articulation entre objectifs métiers et techniques confère au projet une portée à la fois opé‑
rationnelle et technologique, répondant aux besoins concrets des utilisateurs tout en s’appuyant
sur une infrastructure robuste et durable.

Objectifs généraux du projet BI

Objectifs métiers Objectifs techniques

– Indicateurs fiables pour le – Centralisation des données.
pilotage. – Automatisation des flux.
– Optimisation des processus. – Sécurité et quali‑
– Anticipation des be‑ té de l’information.
soins stratégiques.

FIG. 2.3 : Objectifs généraux du projet : dimension métier

3.3 Enjeux du projet

Les enjeux du projet concernent trois niveaux principaux :
Pour l’organisme : optimisation de la gestion de l’offre de formation, accès à des indicateurs
fiables, meilleure transparence et crédibilité auprès des partenaires institutionnels et économiques.
Pour le Maroc : amélioration de l’adéquation formation/emploi, réduction du chômage des
jeunes, soutien à la compétitivité économique du pays via une meilleure valorisation du capital
humain.
Pour le porteur du projet : acquisition d’une expérience pratique dans un projet BI complet, dé‑
veloppement de compétences techniques et analytiques, contribution à une problématique socio‑
économique concrète.

4 Étude du besoin

4.1 Identification des besoins métiers et techniques

Réalisé par : SAAD LAKNIN Page 29

Rapport de fin d’études Contexte général du projet et cahier des charges

Besoins métiers
Le secteur de la formation professionnelle au Maroc occupe une place stratégique dans le dé‑
veloppement socio‑économique national, notamment dans le cadre de la vision Maroc Digital 2030
et du programme de modernisation de l’OFPPT (Office de la Formation Professionnelle et de la
Promotion du Travail). Pour accompagner cette dynamique, il est impératif de mettre en place une
solution de Business Intelligence (BI) capable de répondre à plusieurs besoins métiers.

Pilotage stratégique national Les décideurs au niveau central (ministères, directions générales)
ont besoin d’outils fiables pour analyser et comparer les performances des établissements, des
régions et des filières. La BI doit permettre de suivre des indicateurs nationaux tels que :

• le taux d’insertion professionnelle des diplômés par région et par filière ;

• le taux d’abandon en cours de formation ;

• la correspondance entre l’offre de formation et les besoins des entreprises.

Suivi opérationnel des établissements Chaque directeur d’institut ou responsable régional doit
pouvoir visualiser en temps réel l’évolution des inscriptions, la répartition des stagiaires par filière,
le suivi des absences, ou encore la disponibilité des ressources pédagogiques (salles, ateliers, for‑
mateurs).

Aide à la prise de décision Les décisions actuelles reposent sur des rapports annuels statiques,
souvent publiés avec retard. Une plateforme BI doit offrir la possibilité d’analyser les données en
temps quasi‑réel et de simuler différents scénarios, par exemple anticiper les besoins en infrastruc‑
tures dans les filières numériques en forte croissance.

Communication et transparence Les indicateurs produits serviront également aux partenaires

externes (Banque mondiale, Union européenne, entreprises privées). Des rapports interactifs et
fiables renforceront la crédibilité du système marocain de formation professionnelle.
Besoins techniques
Collecte et centralisation Les données proviennent de sources hétérogènes (bases académiques,
applications de gestion des examens, systèmes RH et financiers, fichiers Excel). Un processus
ETL/ELT est nécessaire pour automatiser l’extraction, la transformation et le chargement.

Stockage et modélisation La mise en place d’un Data Warehouse structuré (schéma en étoile)
permettra d’analyser les faits (inscriptions, examens, insertion) selon différentes dimensions (éta‑
blissement, région, filière, genre, année académique).

Réalisé par : SAAD LAKNIN Page 30

Rapport de fin d’études Contexte général du projet et cahier des charges

Visualisation et reporting L’outil choisi doit proposer des tableaux de bord interactifs (Power
BI, Tableau) avec filtres dynamiques.

Sécurité et gouvernance La solution doit assurer un accès différencié selon les rôles (adminis‑
trateur, responsable central, directeur régional, établissement), et respecter les lois marocaines
relatives à la protection des données.

Scalabilité et performance Le système doit être capable de traiter des millions d’enregistrements
couvrant plusieurs années historiques, avec des temps de réponse rapides.

4.2 Analyse des processus existants

Situation actuelle
Actuellement, la gestion et le suivi de la formation professionnelle au Maroc reposent sur des
processus manuels et fragmentés :

• utilisation d’Excel dans chaque établissement pour gérer inscriptions et résultats ;

• consolidation manuelle par les directions régionales puis envoi au siège central ;

• production de rapports PDF/Word statiques avec plusieurs mois de retard ;

• absence d’interopérabilité entre systèmes académiques, RH et financiers.

Ces pratiques entraînent une perte de temps considérable, un risque élevé d’erreurs hu‑
maines et une faible capacité d’analyse en temps réel.
Processus de flux actuel
Le processus existant peut être résumé en quatre étapes :

1. Saisie locale des données par chaque établissement.

2. Transmission aux directions régionales qui effectuent une consolidation partielle.

3. Agrégation centrale par le siège avec un fort risque d’incohérences.

4. Génération de rapports statiques pour diffusion interne et externe.

FIG. 2.4 : Processus de flux actuel

Réalisé par : SAAD LAKNIN Page 31

Rapport de fin d’études Contexte général du projet et cahier des charges

4.3 Situation actuelle vs situation cible

Aspect Situation actuelle Situation cible avec BI

Collecte des données Manuelle, fichiers Excel dispersés Automatisée via ETL

Stockage Bases hétérogènes, silos Data Warehouse centralisé

Consolidation Longue et manuelle Rapide et automatisée

Accessibilité Rapports statiques Tableaux de bord interactifs

Fiabilité Risque élevé d’erreurs Données nettoyées et validées

Décision Réactive, a posteriori Proactive, quasi temps réel

Communication Rapports annuels statiques Partage interactif et transparent

TAB. 2.2 : Comparaison entre la situation actuelle et la situation cible avec une solution BI

5 Exigences fonctionnelles et non-fonctionnelles

Dans le cadre de mon stage, ma mission porte principalement sur deux axes majeurs du SNI‑
FOP : la Catégorie 2 – Accès et participation au système de formation professionnelle et la Caté‑
gorie 3 – Offre de formation professionnelle. Ces deux catégories constituent un pilier essentiel
pour suivre à la fois l’intégration des apprenants dans le système de formation et l’évolution de
l’offre en termes de programmes et de filières. Afin de répondre à ces objectifs, un ensemble d’exi‑
gences fonctionnelles et non‑fonctionnelles a été défini dans le présent cahier des charges.

5.1 Exigences fonctionnelles

Les exigences fonctionnelles traduisent les services concrets que le système doit offrir aux diffé‑
rents acteurs. Elles couvrent l’ensemble du cycle de vie de la donnée : de sa collecte à sa restitution,
en passant par sa transformation et son stockage.

Réalisé par : SAAD LAKNIN Page 32

Rapport de fin d’études Contexte général du projet et cahier des charges

Collecte des données

La première exigence fonctionnelle concerne la capacité du système à rassembler toutes les
données nécessaires au suivi des indicateurs. Il s’agit de centraliser des informations dispersées
dans plusieurs organismes et de faciliter leur remontée.

• Collecte automatique des données auprès des établissements de formation publics et privés.

• Connexion aux bases existantes (DFP, OFPPT, CNSS, HCP) afin d’éviter la double saisie.

• Import manuel possible via fichiers Excel ou CSV, notamment pour les données locales non
numérisées.

• Intégration de données sur les populations vulnérables (handicapés, migrants, réfugiés, dé‑
tenus).

Transformation et traitement des données

Les données collectées doivent être nettoyées et standardisées avant d’être exploitées. Ce pro‑
cessus garantit leur fiabilité et permet de produire des indicateurs harmonisés.

• Vérification de la qualité des données et suppression des doublons.

• Normalisation des formats (codes établissements, nomenclature des filières).

• Calcul automatisé des principaux indicateurs définis par le SNIFOP : taux d’affluence, taux
de bacheliers, nombre de nouvelles filières créées, programmes développés selon l’APC, etc.

• Possibilité de ventiler les résultats par région, par sexe, par opérateur ou par niveau de for‑
mation.

Stockage et historisation
Une exigence clé réside dans la mise en place d’un stockage centralisé et sécurisé des données,
permettant un suivi dans le temps.

• Base de données unique et sécurisée, centralisant toutes les informations.

• Conservation des données historiques afin de mesurer les évolutions sur plusieurs années.

• Archivage annuel des indicateurs pour disposer de séries statistiques comparables.

• Traçabilité des modifications apportées aux données (utilisateur, date, action).

Réalisé par : SAAD LAKNIN Page 33

Rapport de fin d’études Contexte général du projet et cahier des charges

Restitution et visualisation
Les données doivent être restituées de façon claire, interactive et utile pour la prise de décision.

• Création de tableaux de bord interactifs regroupant les indicateurs par catégorie.

• Production de rapports périodiques (mensuels, annuels) avec export PDF et Excel.

• Visualisation sous forme de graphiques comparatifs, cartes régionales et filtres dynamiques.

• Accès différencié selon le rôle : administrateur, établissement ou décideur institutionnel.

FIG. 2.5 : Exigences Fonctionnelle

5.2 Exigences non-fonctionnelles

En complément des fonctionnalités attendues, il est nécessaire de définir des exigences non‑
fonctionnelles. Celles‑ci ne concernent pas directement les services fournis par le système, mais
déterminent la manière dont il doit fonctionner afin de garantir sa qualité, sa robustesse et sa
pérennité.
Performance
Le système doit offrir une performance élevée afin de permettre une exploitation fluide, même
en présence d’un volume important de données. Les temps de réponse aux requêtes doivent rester
courts et les calculs d’indicateurs doivent s’exécuter de manière quasi instantanée. L’objectif est

Réalisé par : SAAD LAKNIN Page 34

Rapport de fin d’études Contexte général du projet et cahier des charges

que l’utilisateur puisse naviguer, filtrer et consulter ses tableaux de bord sans subir de ralentisse‑
ments, et ce, même si la plateforme traite plusieurs centaines de milliers d’enregistrements.
Sécurité
La sécurité représente une exigence fondamentale dans la mesure où le système manipule des
données sensibles concernant les stagiaires, les établissements et les programmes de formation.
Un dispositif d’authentification forte doit être mis en place afin de limiter l’accès aux seules per‑
sonnes autorisées, et les informations doivent être protégées par des mécanismes de chiffrement
robustes. La gestion des droits doit être hiérarchisée selon les profils utilisateurs (administrateurs,
responsables d’établissements, décideurs), et un suivi des connexions doit être assuré pour ren‑
forcer la traçabilité.
Fiabilité
Un autre critère essentiel est la fiabilité. Le système doit rester disponible en permanence, avec
un taux de disponibilité supérieur à 99,5%. Des sauvegardes régulières et automatiques doivent
être effectuées afin d’éviter toute perte d’information, et un mécanisme de restauration rapide doit
permettre de remettre en service l’ensemble des données en moins de 24 heures en cas de panne.
Ces dispositions garantissent la continuité d’activité et renforcent la confiance des utilisateurs.
Interopérabilité
Le système doit également être interopérable, c’est‑à‑dire capable d’échanger et de communi‑
quer avec d’autres plateformes et bases de données nationales. Cette exigence est indispensable
pour éviter les redondances et favoriser la circulation de l’information entre les différentes institu‑
tions (DFP, CNSS, HCP, ANAPEC, etc.). L’utilisation de standards ouverts et d’API permettra de
garantir une intégration durable et évolutive avec les systèmes déjà en place et ceux qui pourraient
émerger à l’avenir.
Ergonomie et accessibilité
L’ergonomie et l’accessibilité constituent des critères essentiels pour assurer une appropriation
large du système. L’interface doit rester simple, intuitive et personnalisable en fonction des pro‑
fils d’utilisateurs, afin que chacun puisse trouver rapidement l’information recherchée. Une na‑
vigation fluide, des filtres clairs et des tableaux de bord dynamiques doivent contribuer à rendre
l’expérience utilisateur agréable et efficace.

6 Contraintes techniques
Dans le cadre du projet, les données exploitées proviennent d’une base de données Oracle ex‑
terne. Le système ne pouvant pas agir directement sur cette source, il est indispensable de mettre
en place un dispositif adapté pour extraire, transformer et charger les données dans un entrepôt
dédié. Les contraintes techniques identifiées concernent donc principalement la gestion des flux

Réalisé par : SAAD LAKNIN Page 35

Rapport de fin d’études Contexte général du projet et cahier des charges

externes, la construction de processus ETL robustes et l’utilisation de cubes pour l’analyse multi‑
dimensionnelle.

6.1 Accès à une base externe Oracle

La première contrainte est liée au fait que les données résident dans une base de données Oracle
externe. L’accès nécessite la mise en place de connexions sécurisées, le respect des droits d’accès
et la compatibilité avec l’architecture cible. Toute défaillance au niveau de la connexion ou de la
structure des tables source peut impacter directement le processus de collecte.

6.2 Mise en place de processus ETL

Afin d’intégrer les données issues de la base externe, il est nécessaire de construire des pro‑
cessus ETL (Extract, Transform, Load). Ces flux doivent permettre l’extraction régulière des don‑
nées depuis la base Oracle, leur transformation et leur nettoyage afin de supprimer les doublons
et d’uniformiser les formats, avant leur chargement vers un entrepôt de données centralisé. La
principale complexité réside dans l’automatisation de ces traitements ainsi que dans la gestion de
volumes potentiellement très élevés.

6.3 Utilisation de cubes analytiques

Pour optimiser l’analyse et faciliter la restitution, les données doivent être organisées sous
forme de cubes OLAP. Ces cubes offrent une vision multidimensionnelle des informations et per‑
mettent d’effectuer des analyses rapides selon différents axes tels que la période, la région ou
le type de programme. La contrainte essentielle consiste à modéliser correctement les cubes afin
qu’ils répondent aux besoins métiers tout en maintenant des performances satisfaisantes.

6.4 Performance et sécurité

Deux contraintes transversales s’appliquent à l’ensemble de la chaîne. D’une part, la perfor‑
mance doit être assurée : les temps de traitement des flux ETL et les temps de réponse lors des
requêtes sur les cubes doivent rester optimaux, même en présence de très gros volumes de don‑
nées. D’autre part, la sécurité doit être garantie : les flux d’échanges entre la base Oracle externe et
l’entrepôt doivent être protégés par des mécanismes de chiffrement robustes et un contrôle strict
des accès, afin d’assurer la confidentialité et l’intégrité des données tout au long du processus.

7 Contraintes organisationnelles
Plusieurs contraintes organisationnelles ont marqué le déroulement du projet. Tout d’abord,
l’accès aux données issues de la base Oracle externe a nécessité des autorisations spécifiques et
une coordination avec les responsables techniques, ce qui a ralenti certaines étapes.
Ensuite, la disponibilité limitée des équipes internes a parfois retardé la validation des règles

Réalisé par : SAAD LAKNIN Page 36

Rapport de fin d’études Contexte général du projet et cahier des charges

ETL et la configuration des cubes analytiques. De plus, l’absence initiale d’une structure claire de
gestion de projet a compliqué la coordination, rendant nécessaires des points de suivi réguliers.
Enfin, la sensibilisation des utilisateurs aux nouveaux outils BI a représenté un défi : les ha‑
bitudes liées aux rapports statiques (Excel, PDF) ont engendré une certaine résistance au change‑
ment, nécessitant des actions de formation et d’accompagnement.

8 Méthodologie de travail : le cycle en V

La réalisation du projet s’appuie sur la méthodologie du cycle en V, qui organise les différentes
phases en une succession descendante (spécifications et conceptions), suivie d’une remontée (tests
et validations).
Les étapes principales sont les suivantes :

• Analyse des besoins : identification des attentes des utilisateurs, des contraintes techniques
et des objectifs du projet BI.

• Conception fonctionnelle : définition des fonctionnalités attendues, des flux de données et

des cas d’utilisation.

• Conception technique : choix de l’architecture cible, modélisation des schémas de données

et planification des traitements.

• Implémentation (ETL + Cubes) : développement des processus d’extraction, de transforma‑

tion et de chargement, ainsi que la construction des cubes OLAP pour l’analyse multidimen‑
sionnelle.

• Tests unitaires : vérification du bon fonctionnement de chaque composant développé (scripts

ETL, cubes, connecteurs).

• Tests d’intégration : contrôle de la cohérence du système complet, de bout en bout, depuis

la source Oracle externe jusqu’aux tableaux de bord.

• Validation des KPI : confirmation que les indicateurs calculés sont conformes aux besoins
métiers et qu’ils reflètent fidèlement la réalité.

• Déploiement : mise en production du système BI, mise à disposition des utilisateurs finaux
et accompagnement au changement.

Réalisé par : SAAD LAKNIN Page 37

Rapport de fin d’études Contexte général du projet et cahier des charges

FIG. 2.6 : Méthodologie de travail basée sur le cycle en V

9 Étapes de réalisation du projet

La mise en œuvre du projet s’est déroulée en plusieurs étapes successives, organisées de ma‑
nière méthodique afin de garantir la qualité des livrables et la cohérence du système décisionnel :

1. Analyse des besoins Identification des objectifs du projet, recueil des attentes des utilisa‑
teurs finaux, et définition des indicateurs de performance (KPI) à mettre en place.

2. Étude des sources de données Analyse de la base de données Oracle externe, compréhen‑
sion de la structure des tables, et identification des données pertinentes pour le reporting.

3. Conception fonctionnelle et technique Définition de l’architecture cible, spécification des

flux ETL, modélisation du schéma de l’entrepôt de données (data warehouse) et conception
des cubes analytiques (OLAP). Cette étape inclut également l’implémentation de l’entrepôt
de données, permettant de centraliser, structurer et historiser les informations issues des
différentes sources.

4. Implémentation des processus ETL Développement des flux d’extraction, transformation et

chargement des données, nettoyage et uniformisation des formats pour garantir la fiabilité
des indicateurs.

5. Construction des cubes analytiques Mise en place des cubes OLAP pour permettre l’analyse
multidimensionnelle, facilitant la navigation par région, programme, filière ou période.

6. Développement des rapports et tableaux de bord Création de visualisations interactives

et dynamiques, exportables en différents formats (PDF, Excel), adaptées aux besoins des
décideurs.

Réalisé par : SAAD LAKNIN Page 38

Rapport de fin d’études Contexte général du projet et cahier des charges

7. Tests et validation Vérification de la cohérence des données, validation des règles de calcul
des KPI et contrôle de la performance des cubes et rapports générés.

8. Déploiement et formation Mise en production du système BI, sensibilisation et accompa‑

gnement des utilisateurs pour favoriser l’appropriation des outils.

10 Planification du projet
La planification du projet s’appuie sur un diagramme de Gantt (figure 2.7), qui illustre les diffé‑
rentes étapes prévues entre mars et juillet 2025. Chaque phase est définie de manière séquentielle
afin d’assurer la cohérence entre l’analyse des besoins, la mise en place technique et la livraison
finale.
Formation (Mars 2025) Durant le mois de mars, une phase de formation est prévue afin de se
familiariser avec les outils, les concepts de Business Intelligence et les environnements techniques
nécessaires à la réussite du projet.
Étude des besoins et KPIs (1er au 15 avril 2025) Cette étape vise à recueillir et analyser les
besoins métiers, identifier les utilisateurs finaux, et définir les indicateurs de performance (KPIs)
qui serviront de base au futur système de reporting.
Phase Staging (16 au 30 avril 2025) Le staging correspond à la préparation des données is‑
sues de la base Oracle externe. Il inclut l’extraction, la mise en correspondance des formats et la
préparation des flux pour faciliter l’intégration dans l’entrepôt de données.
Implémentation et conception du Data Warehouse (1er au 20 mai 2025) Durant cette phase,
l’entrepôt de données (Data Warehouse) est conçu et mis en place. Il s’agit de modéliser la structure
cible, organiser les schémas, et préparer le socle technique sur lequel reposeront les cubes et les
dashboards.
Développement des Datamarts (21 mai au 15 juin 2025) Cette étape consiste à développer les
datamarts thématiques, c’est‑à‑dire des vues spécialisées et optimisées pour l’analyse par départe‑
ment, filière ou axe métier. Cela permet d’offrir une granularité adaptée aux besoins décisionnels.
Création des cubes et mesures (16 au 30 juin 2025) Les cubes OLAP sont développés afin de
permettre des analyses multidimensionnelles (par région, période, programme, etc.). Des mesures
calculées sont également définies pour enrichir l’analyse et faciliter la navigation.
Développement des dashboards et testing (1er au 25 juillet 2025) Les tableaux de bord inter‑
actifs sont développés et testés. Cette étape inclut la création de rapports visuels, l’ajout de filtres
dynamiques et la validation de leur conformité par rapport aux besoins exprimés.
Déploiement (26 au 31 juillet 2025) Enfin, le système est déployé en production. Les dash‑
boards sont mis à disposition des utilisateurs finaux et une sensibilisation est assurée afin de ga‑
rantir leur appropriation.

Réalisé par : SAAD LAKNIN Page 39

Rapport de fin d’études Contexte général du projet et cahier des charges

FIG. 2.7 : Planification du projet BI entre mars et juillet 2025

11 Conclusion
En conclusion, le cahier des charges représente une étape fondamentale pour garantir la réus‑
site du projet. Il établit un cadre clair et partagé entre les parties prenantes, en traduisant les be‑
soins en objectifs concrets et en limitant les risques liés aux ambiguïtés. Véritable outil de pilotage,
il assure la cohérence des choix techniques et organisationnels et sert de référence tout au long du
cycle de vie du projet. Son importance réside dans sa capacité à orienter la conception, la mise
en œuvre et le déploiement de la solution BI, tout en garantissant l’alignement avec les attentes
définies au départ.

Réalisé par : SAAD LAKNIN Page 40

Rapport de fin d’études État de l’art et travaux connexes

Chapitre 3 :
État de l’art et travaux connexes

Réalisé par : SAAD LAKNIN Page 41

Rapport de fin d’études État de l’art et travaux connexes

1 Introduction
Dans le cadre de ce travail, il est essentiel de s’appuyer sur des fondements théoriques et
conceptuels afin de mieux comprendre les technologies et méthodes utilisées. L’état de l’art consti‑
tue ainsi une étape incontournable puisqu’il permet de présenter les notions de base, les approches
classiques et les travaux existants dans le domaine étudié.
Au sein des systèmes décisionnels modernes, la Business Intelligence occupe une place centrale
et constitue un levier stratégique pour les organisations. Elle permet de valoriser les données issues
de sources multiples et de les transformer en un support efficace pour la prise de décision. Cette
démarche repose sur une architecture robuste et organisée autour d’un entrepôt de données, qui
assure la consolidation et l’exploitation des informations.
Autour de cette architecture gravitent plusieurs concepts essentiels qui structurent l’environ‑
nement décisionnel. Les modèles de données, les tables de faits et de dimensions, les datamarts
spécialisés et les cubes analytiques multidimensionnels représentent autant de mécanismes qui
garantissent la pertinence et l’efficacité des analyses.
L’objectif de ce chapitre est donc de proposer une vue d’ensemble de ces éléments constitutifs
de la Business Intelligence et de l’entrepôt de données. Cette revue théorique servira de base de
référence pour situer notre démarche dans le prolongement des approches existantes et justifier
les choix méthodologiques adoptés dans ce rapport.

2 Business Intelligence

2.1 Définition et concepts clés

La Business Intelligence (BI) peut être définie comme l’ensemble des méthodes, des technolo‑
gies et des processus permettant de transformer de grandes quantités de données brutes en in‑
formations pertinentes, utiles et exploitables par les décideurs. Elle s’articule autour de plusieurs
concepts clés : la collecte de données, leur intégration, leur analyse et leur restitution sous une
forme intelligible (rapports, tableaux de bord, visualisations interactives). À l’origine, la BI se li‑
mitait essentiellement à fournir une vision rétrospective de l’activité organisationnelle, grâce à des
rapports standards et des analyses descriptives. Aujourd’hui, l’intégration avec le Big Data et les
outils analytiques modernes lui confère une dimension beaucoup plus proactive et prédictive, en
facilitant l’analyse en temps réel et la modélisation avancée des comportements[1].

2.2 Objectifs et enjeux de la BI dans les organisations

La Business Intelligence (BI) a pour objectif central de transformer des données brutes, souvent
massives et hétérogènes, en informations exploitables au service de la décision. Elle contribue à
améliorer la qualité des décisions, en mettant à disposition des informations pertinentes, fiables

Réalisé par : SAAD LAKNIN Page 42

Rapport de fin d’études État de l’art et travaux connexes

et actualisées, ce qui réduit les incertitudes et aide les organisations à évoluer dans des environ‑
nements hautement concurrentiels et instables [1].
Les enjeux associés à la BI dépassent la simple dimension technique. Elle renforce la réactivité
organisationnelle en permettant une identification plus rapide des opportunités et des menaces,
et favorise l’efficacité opérationnelle grâce à l’intégration et au traitement de données issues de
sources multiples. De plus, la BI constitue un levier stratégique pour accroître la compétitivité,
stimuler l’innovation et soutenir durablement la performance globale des organisations [2].
En définitive, la BI s’affirme non seulement comme une technologie de gestion de données,
mais aussi comme un instrument stratégique de gouvernance et de création de valeur pour les
entreprises modernes.

2.3 Évolution de la BI : des rapports statiques vers l’analytique avancée

Historiquement, la Business Intelligence (BI) a vu le jour vers la fin des années 1990, avec un rôle
initial limité à la simple diffusion d’informations descriptives destinées aux responsables pour
appuyer leurs décisions. Elle se distinguait alors des systèmes transactionnels classiques, dont la
fonction principale se limitait au traitement et à l’enregistrement des données [4].
Avec l’évolution des systèmes intégrés et des infrastructures informatiques, la BI s’est progres‑
sivement transformée en un dispositif plus complet, allant au‑delà du reporting statique. Elle est
désormais définie comme la capacité de l’entreprise à fixer des objectifs, à tracer des plans et à
mettre en œuvre des actions intelligentes en s’appuyant sur la sécurité et la fiabilité de ses sys‑
tèmes décisionnels [4].
Les travaux de recherche et les pratiques managériales montrent que la BI s’oriente aujourd’hui
vers l’analytique avancée, intégrant des modèles prédictifs et des techniques d’optimisation. Cette
évolution traduit le passage d’une logique descriptive (rapports et états statiques) à une logique
prédictive et prescriptive, où l’accent est mis sur l’anticipation des tendances, l’optimisation des
processus et l’amélioration continue de la performance organisationnelle [16, 14].
Ainsi, la BI est passée d’un outil de reporting rétrospectif à une véritable plateforme analytique,
permettant une prise de décision plus rapide, éclairée et proactive.

2.4 Comparaison entre systèmes décisionnels et systèmes opérationnels

Dans une organisation, il convient de distinguer deux grandes catégories de systèmes d’infor‑
mation :

• les systèmes opérationnels (ou transactionnels), qui soutiennent les activités quotidiennes
de l’entreprise, comme la gestion des ventes, de la production ou des ressources humaines ;

• les systèmes décisionnels (ou systèmes de Business Intelligence), qui visent à fournir une
vision consolidée et analytique des données afin de faciliter la prise de décision stratégique.

La table 3.1 résume les principales différences entre ces deux types de systèmes.

Réalisé par : SAAD LAKNIN Page 43

Rapport de fin d’études État de l’art et travaux connexes

Critère Systèmes opérationnels Systèmes décisionnels

(OLTP) (OLAP/BI)
Objectif principal Gérer les opérations cou‑ Aider à la décision straté‑
rantes (transactions quoti‑ gique et tactique.
diennes).
Type de données Données actuelles, dé‑ Données historiques, agré‑
taillées, orientées transac‑ gées, orientées analyse.
tions.
Structure des don‑ Bases relationnelles nor‑ Modèles multidimension‑
nées malisées (3NF). nels (étoile, flocon, constel‑
lation).
Volumétrie Grand nombre de petites Faible nombre de requêtes
transactions. complexes sur gros vo‑
lumes.
Exemples d’utilisa‑ ERP, CRM, gestion des Tableaux de bord, indica‑
tion commandes, paie. teurs de performance, pré‑
visions.
Utilisateurs Employés opérationnels, Analystes, décideurs, di‑
managers de proximité. rection stratégique.
Impact temporel Réactivité immédiate aux Vision rétrospective, ana‑
opérations. lytique et prospective.

TAB. 3.1 : Comparaison entre systèmes opérationnels et systèmes décisionnels

Ainsi, les systèmes opérationnels assurent la bonne exécution des processus métier quotidiens,
tandis que les systèmes décisionnels exploitent l’historique des données pour orienter la stratégie,
optimiser les processus et renforcer l’avantage concurrentiel.

3 L’architecture du processus de la BI et ces principales phases :

3.1 Les Principes phase

Au‑delà de son architecture technique, la Business Intelligence (BI) se déploie à travers un
ensemble de phases interdépendantes qui traduisent le cycle de vie d’un projet BI [10] :

1. Phase de planification et identification des besoins : définition des objectifs stratégiques et

des besoins décisionnels à couvrir.

Réalisé par : SAAD LAKNIN Page 44

Rapport de fin d’études État de l’art et travaux connexes

2. Phase de collecte et d’intégration des données : sélection des sources pertinentes (internes
et externes), extraction, nettoyage et transformation (processus ETL).

3. Phase de stockage et d’organisation : consolidation des données dans des entrepôts et da‑
tamarts, avec historisation et structuration pour les futures analyses.

4. Phase d’analyse et d’exploration : exploitation des données via l’OLAP, le data mining et
les modèles analytiques afin de dégager tendances et connaissances.

5. Phase de restitution et d’utilisation décisionnelle : diffusion des résultats sous forme de

rapports, tableaux de bord et indicateurs de performance, permettant aux décideurs d’agir.

6. Phase d’évaluation et d’amélioration continue : mesure de la satisfaction des utilisateurs et

ajustement des processus pour améliorer la pertinence et l’efficacité du système BI.

FIG. 3.1 : Architecture de la Business Intelligence

4 Les outils utilisés dans ces déférentes phases

4.1 Processus ETL (Extraction, Transformation, Loading)

Le processus ETL (Extraction–Transformation–Loading) constitue l’une des étapes les plus cri‑
tiques dans la mise en place d’un entrepôt de données. Il est chargé d’extraire des données depuis
diverses sources, de les transformer et nettoyer afin d’assurer leur qualité, puis de les charger dans
l’entrepôt de données. Selon Vassiliadis et al. [15], cette étape peut représenter jusqu’à 55 à 80%
du coût et du temps total d’un projet de data warehouse.

Réalisé par : SAAD LAKNIN Page 45

Rapport de fin d’études État de l’art et travaux connexes

Définition générale. Les outils ETL sont des logiciels spécialisés permettant :

• l’extraction des données brutes issues de bases relationnelles, fichiers plats, flux ou systèmes
externes ;

• la transformation et le nettoyage des données afin de corriger les incohérences, convertir

les formats et harmoniser les structures ;

• le chargement des données consolidées dans l’entrepôt (tables de faits et dimensions).

Comme le rappellent Vassiliadis et al. [15], ces trois étapes constituent le cœur du processus d’in‑
tégration des données décisionnelles.

Phases du processus ETL. Le processus ETL s’organise autour de trois grandes étapes [15] :

1. Extraction : capture des données depuis les sources opérationnelles. Cette étape peut consis‑
ter en des extractions complètes (snapshots) ou différentielles.

2. Transformation et nettoyage : réalisée dans la Data Staging Area (DSA), elle comprend :

• le nettoyage des données (contrôle des valeurs nulles, détection des violations de clés
primaires/étrangères, cohérence des types),
• les conversions de formats et d’unités (par exemple, formats de date ou devises),
• l’harmonisation structurelle (normalisation, dénormalisation, projection),
• l’attribution de clés techniques (surrogate keys),
• les opérations analytiques (agrégations, jointures, détection de mises à jour).

3. Chargement : transfert des données transformées vers l’entrepôt, avec des contraintes de
performance (par exemple, la durée totale d’exécution inférieure à une fenêtre temporelle
fixée).

Avantages. Les principaux avantages d’un processus ETL bien modélisé sont [15] :

• Qualité des données : détection et correction systématique des erreurs ;

• Uniformisation : harmonisation des formats et des unités entre différentes sources ;

• Traçabilité : suivi clair des données depuis la source jusqu’à l’entrepôt ;

• Réutilisabilité : construction d’une bibliothèque de transformations récurrentes ;

• Performance : optimisation du temps d’exécution et respect des contraintes opérationnelles.

Réalisé par : SAAD LAKNIN Page 46

Rapport de fin d’études État de l’art et travaux connexes

FIG. 3.2 : ETL

4.2 Data Warehouse et Data Mart

Un Data Warehouse (DW) est défini comme une unité centrale qui connecte plusieurs sources
de données hétérogènes (structurées et non structurées), puis fournit ces données à des outils
analytiques ou décisionnels. Son rôle est de stocker, intégrer et rendre accessibles les informations
pour le reporting, l’analyse ou encore l’alimentation de modèles tels que le machine learning et
la Business Intelligence [13]. Un DW repose généralement sur cinq composants principaux : une
base de données, des processus ETL, des métadonnées, des outils de requêtes et une architecture
de bus [13].

Caractéristiques d’un Data Warehouse. Selon la littérature, les principales caractéristiques d’un
DW peuvent être résumées comme suit [13] :

• Orienté sujet : les données sont organisées autour de thèmes métiers majeurs (ventes, clients,
produits, finances, etc.) plutôt que par processus opérationnels.

• Intégré : il rassemble des données issues de sources multiples en harmonisant les formats,
les unités de mesure, les conventions de nommage et les structures.

• Historisé : les données stockées sont conservées sur de longues périodes, permettant l’ana‑
lyse des tendances et l’évolution temporelle (time‑variant).

Réalisé par : SAAD LAKNIN Page 47

Rapport de fin d’études État de l’art et travaux connexes

• Non volatile : une fois intégrées, les données ne sont pas modifiées ni supprimées, assurant
stabilité et cohérence pour l’analyse.

• Granularité multiple : le DW peut contenir différents niveaux de détail, allant des données
très fines aux données agrégées pour l’analyse stratégique.

Types d’architectures de Data Warehouse. Selon Rana [13], l’architecture d’un entrepôt de don‑
nées peut être organisée en trois niveaux :

• Architecture à un seul niveau (One‑tier) : vise à minimiser la redondance en réduisant la

duplication des données. Toutefois, elle ne sépare pas le traitement transactionnel (OLTP)
du traitement analytique (OLAP), ce qui limite son utilisation.

• Architecture à deux niveaux (Two‑tier) : introduit une couche intermédiaire de staging. Les
données sont traitées puis stockées dans le DW avant restitution. Elle souffre néanmoins de
limitations réseau et d’un manque de scalabilité pour de nombreux utilisateurs.

• Architecture à trois niveaux (Three‑tier) : la plus répandue et utilisée dans les organisations.

– Couche inférieure : stockage des données issues des processus ETL.

– Couche intermédiaire : serveur applicatif/OLAP (ROLAP ou MOLAP) qui structure les
données pour les rendre exploitables.
– Couche supérieure : restitution via tableaux de bord, outils de BI, reporting ou encore
intégration avec des applications d’IA et de machine learning.

Cette architecture est considérée comme la plus robuste, évolutive et adaptée aux analyses
avancées.

FIG. 3.3 : Data Warehouse

Réalisé par : SAAD LAKNIN Page 48

Rapport de fin d’études État de l’art et travaux connexes

Data Mart et ses caractéristiques : Un Data Mart est une sous‑partie spécialisée d’un entrepôt
de données, centrée sur un domaine ou une fonction métier spécifique (par exemple : ventes, mar‑
keting, finances, RH). Les données qu’il contient proviennent du DW, mais elles sont restreintes à
un périmètre limité et organisées pour répondre aux besoins particuliers d’un département [13].
Ses principales caractéristiques sont :

• Thématique : orienté sur un sujet ou une fonction précise.

• Orienté utilisateur : conçu pour les besoins décisionnels d’un service particulier.

• Réduction de la complexité : offre une vision simplifiée et ciblée.

• Performance : requêtes plus rapides car le volume de données est restreint.

• Flexibilité : peut être indépendant (standalone) ou dépendant du DW central.

En résumé, le Data Warehouse constitue la plateforme centrale pour l’intégration et l’analyse

des données, tandis que le Data Mart en est une version spécialisée et allégée, destinée à un usage
plus ciblé.

FIG. 3.4 : Data Mart

4.3 Approches de modélisation des entrepôts de données

La conception d’un entrepôt de données peut suivre plusieurs approches de modélisation. Les
plus répandues sont l’approche d’Inmon, l’approche de Kimball et, plus récemment, l’approche
Data Vault. Ces trois méthodes diffèrent par leur philosophie, leur architecture, leur méthodologie
et leurs avantages/inconvénients [18].

Approche d’Inmon. Bill Inmon est considéré comme le père du Data Warehouse. Son approche est
dite data‑driven et repose sur une modélisation en 3ème forme normale (3NF). L’architecture est
centrée sur un entrepôt de données unique et intégré, appelé Atomic Data Warehouse, qui alimente

Réalisé par : SAAD LAKNIN Page 49

Rapport de fin d’études État de l’art et travaux connexes

par la suite différents Data Marts dédiés aux départements de l’entreprise. Les modèles utilisés
sont d’abord conceptuels (ERD), puis logiques (DIS) et enfin physiques. Cette approche garantit
une intégration forte et une grande cohérence des données, mais elle est relativement complexe,
coûteuse et longue à mettre en place. L’implication des utilisateurs est faible car la priorité est
donnée à la centralisation et à l’intégration technique.

FIG. 3.5 : Approche Inmon

Approche de Kimball. Ralph Kimball propose une méthode dite user‑driven, basée sur la mo‑
délisation dimensionnelle (schéma en étoile, tables de faits et tables de dimensions). Pour lui,
l’entrepôt de données est vu comme un ensemble de Data Marts intégrés grâce à des dimensions
conformes. Cette approche met l’accent sur la facilité d’utilisation, la rapidité de mise en œuvre et
la performance des requêtes. Les utilisateurs métiers sont fortement impliqués dès les premières
phases du projet. Cependant, l’intégration globale peut devenir complexe si le nombre de Data
Marts augmente fortement.

FIG. 3.6 : Approche kimball

Approche Data Vault. Introduite par Dan Linstedt au début des années 2000, l’approche Data
Vault est plus récente et adopte une philosophie hybride, à la fois data‑driven et process‑driven. Elle

Réalisé par : SAAD LAKNIN Page 50

Rapport de fin d’études État de l’art et travaux connexes

repose sur une structure normalisée composée de trois entités principales :

• Hubs : contiennent les clés métiers fondamentales (client, produit, commande, etc.) ;

• Links : gèrent les relations entre hubs ;

• Satellites : stockent les informations descriptives et temporelles liées aux hubs et links.

Cette séparation assure une grande flexibilité et une évolutivité du modèle, car il suffit d’ajou‑
ter de nouveaux satellites pour intégrer des changements. L’approche est bien adaptée aux en‑
vironnements agiles et aux contextes où les sources de données sont nombreuses et évolutives.
En revanche, les performances en interrogation directe sont faibles, et l’utilisation de Data Marts
dimensionnels reste nécessaire pour l’analyse et le reporting.

Comparaison des approches. Le tableau suivant présente une comparaison synthétique entre
les trois approches selon plusieurs critères clés.

Critères Inmon Kimball Data Vault

Philosophie Data‑driven, intégra‑ User‑driven, besoins Hybride
tion et stabilité métiers (data/process‑
driven), agile
Architecture Entrepôt central 3NF Data Marts inté‑ Hubs, Links, Satel‑
+ Data Marts grés via dimensions lites
conformes
Complexité Plus complexe mais Simple, adapté aux Simple, très flexible
robuste projets rapides
Méthodologie Spirale incrémentale Processus itératif en 4 Méthodologie agile
étapes
Coût et temps Investissement initial Déploiement rapide, Progressif, coût opti‑
élevé, maintenance coût réduit misé
faible
Intégration Très forte intégration Bonne intégration, Simplifiée (Hubs/‑
et cohérence plus complexe à Links/Satellites)
maintenir
Performance Correcte avec optimi‑ Excellente (schéma Limitée, nécessite Da‑
sations OLAP en étoile) ta Marts
Flexibilité Stable, peu flexible Moyenne, sensible Très élevée, évolutive
aux changements aux impacts
Implication uti‑ Orientée IT, faible im‑ Forte implication des Bonne implication,
lisateurs plication métiers collaborative

TAB. 3.2 : Comparaison des approches Inmon, Kimball et Data Vault [18]

Réalisé par : SAAD LAKNIN Page 51

Rapport de fin d’études État de l’art et travaux connexes

4.4 Modélisation dimensionnelle et schémas

La modélisation dimensionnelle, introduite par Kimball (1996), est une approche spécifique
de conception des entrepôts de données, différente de la modélisation relationnelle classique (ERD).
Son objectif est de produire des structures de données simples, intuitives et optimisées pour l’ana‑
lyse, afin que les utilisateurs métiers puissent interroger directement les bases décisionnelles [8].

Table de faits. Une table de faits occupe le centre du schéma en étoile. Elle contient :

• des mesures quantitatives ou faits (par ex. montant des ventes, quantités, coûts) ;

• les clés étrangères vers les dimensions qui décrivent le contexte des faits ;

• une clé primaire composée de la concaténation des clés des dimensions associées.

Elle représente donc les événements ou transactions à analyser (ventes, commandes, paiements,
etc.).

Table de dimensions. Les tables de dimensions décrivent le contexte des faits en fournissant
des attributs qualitatifs. Elles permettent de répondre aux questions qui, quoi, où, quand, comment,
pourquoi. Exemple : une dimension Client peut inclure les hiérarchies Région → Ville → Maga‑
sin, ou bien les segments de marché. Ces tables sont souvent dénormalisées afin de simplifier la
navigation et réduire le nombre de jointures.

FACT_SALES (table de faits) DIM_CUSTOMER (table de dimension)

fact_id (PK, entier) customer_id (PK, entier)
time_id (FK potentielle) customer_name
product_id (FK potentielle) segment
qty_sold (mesure) city
amount (mesure) country

FIG. 3.7 : Exemple de table de faits et table de dimension

4.5 Les différents types de schémas dimensionnels

La modélisation dimensionnelle organise les données décisionnelles selon plusieurs types de
schémas, chacun ayant ses avantages et inconvénients [8].

Schéma en étoile (Star Schema). C’est la structure la plus simple, intuitive et la plus utilisée en
entrepôts de données.

• Une table de faits centrale stocke les mesures numériques (par exemple : montant des ventes,
quantités, coûts). Ces mesures sont généralement additives, ce qui permet de les agréger
facilement (somme, moyenne, etc.).

Réalisé par : SAAD LAKNIN Page 52

Rapport de fin d’études État de l’art et travaux connexes

• Autour de cette table de faits gravitent plusieurs tables de dimensions dénormalisées, qui
contiennent les attributs décrivant le contexte des faits (qui, quoi, où, quand). Exemple : la
dimension Temps (jour, mois, année), la dimension Client (nom, ville, segment), la dimension
Produit (nom, catégorie, marque).

• Cette structure est dite « en étoile » car la table de faits se trouve au centre et les dimensions
rayonnent autour.

• Avantages : grande simplicité, rapidité d’exécution des requêtes analytiques (moins de join‑
tures nécessaires), facilité de compréhension pour les utilisateurs métiers et les analystes.

• Limites : présence de redondance dans les dimensions, entraînant une consommation d’es‑
pace mémoire plus élevée et un risque de données incohérentes si la gouvernance n’est pas
rigoureuse.

FIG. 3.8 : Schema Etoile

Schéma en flocon (Snowflake Schema). Le schéma en flocon est une extension du schéma en
étoile, qui introduit une normalisation des dimensions.

• Une dimension est décomposée en plusieurs sous‑tables liées hiérarchiquement. Exemple :

la dimension Produit peut être décomposée en Produit � Catégorie � Famille.

Réalisé par : SAAD LAKNIN Page 53

Rapport de fin d’études État de l’art et travaux connexes

• Cette organisation réduit la redondance des données et améliore l’intégrité référentielle,

puisque les hiérarchies sont représentées explicitement.

• Le nom « flocon » vient de la forme plus complexe que prend le schéma : les dimensions
« éclatées » produisent des ramifications, ce qui donne un aspect de flocon de neige.

• Avantages : moins de redondance, meilleure cohérence des données, représentation explicite

des hiérarchies.

• Limites : plus grand nombre de jointures nécessaires, donc performances moindres par rap‑
port au schéma en étoile, et structure plus difficile à comprendre pour les utilisateurs finaux.

FIG. 3.9 : Schema Flocon

Schéma constellation ou galaxy (Constellation Schema / Galaxy). Le schéma en constellation,

aussi appelé galaxy schema, est une généralisation du schéma en étoile.

• Il comprend plusieurs tables de faits qui partagent des dimensions communes. Exemple :
une constellation peut inclure une table de faits Ventes et une autre Livraisons, toutes deux
liées aux dimensions Temps, Produit, Client.

• Cette approche permet de représenter plusieurs processus métiers au sein d’un même en‑
trepôt de données, ce qui la rend adaptée aux organisations complexes.

Réalisé par : SAAD LAKNIN Page 54

Rapport de fin d’études État de l’art et travaux connexes

• La structure obtenue ressemble à une galaxie, où plusieurs « étoiles » (schémas en étoile)

coexistent et partagent certaines dimensions.

• Avantages : flexibilité accrue, possibilité d’analyser simultanément plusieurs processus mé‑

tiers, mutualisation des dimensions (meilleure cohérence).

• Limites : conception plus complexe, volume de données plus élevé, optimisation des re‑
quêtes plus difficile, et nécessité d’une gouvernance stricte pour garantir la cohérence des
différentes tables de faits.

FIG. 3.10 : Schema Flocon

4.6 Définition de l’OLAP (Online Analytical Processing)

L’OLAP (On‑Line Analytical Processing) est une technologie permettant l’analyse multidimen‑
sionnelle des données. Elle vise à fournir aux décideurs des vues synthétiques, rapides et flexibles
sur de grandes quantités de données, en support à la Business Intelligence et à l’aide à la décision.
OLAP repose sur l’organisation des données en cubes multidimensionnels qui permettent une
navigation intuitive selon différents axes d’analyse [9, 5, 6].

4.7 Caractéristiques d’un cube OLAP

Un cube OLAP est une structure multidimensionnelle composée de trois éléments principaux :

• Mesures : valeurs numériques analysées, stockées dans la table de faits (par exemple : ventes,
bénéfices, quantités).

• Dimensions : axes d’analyse donnant du contexte aux mesures (par exemple : temps, pro‑
duit, client, localisation).

Réalisé par : SAAD LAKNIN Page 55

Rapport de fin d’études État de l’art et travaux connexes

• Cellules : chaque cellule du cube correspond à une combinaison unique de dimensions et

contient la valeur d’une mesure.

Les cubes OLAP présentent les caractéristiques suivantes :

1. Multidimensionnalité : capacité à représenter les données selon plusieurs axes simultané‑

ment (exemple : analyser les ventes par produit, région et période).

2. Hiérarchies : chaque dimension est souvent organisée selon une hiérarchie (exemple : Jour
→ Mois → Année).

3. Granularité : le cube supporte plusieurs niveaux de détail, du plus fin (transactions) au plus
agrégé (ventes annuelles).

4. Pré‑agrégation : dans les systèmes MOLAP et HOLAP, certaines données sont précalculées
pour accélérer les temps de réponse.

5. Navigation intuitive : les utilisateurs peuvent explorer les données en changeant le niveau
de détail ou l’angle d’analyse.

FIG. 3.11 : cube

Réalisé par : SAAD LAKNIN Page 56

Rapport de fin d’études État de l’art et travaux connexes

4.8 Opérations OLAP

Le roll‑up est une opération d’agrégation qui consiste à remonter dans la hiérarchie d’une
dimension afin d’obtenir une vue plus synthétique des données. Par exemple, on peut passer des
ventes journalières aux ventes mensuelles, puis annuelles. Cette opération permet donc de réduire
la granularité et de dégager des tendances globales [9].
Le drill‑down est l’opération inverse du roll‑up : elle permet de descendre dans la hiérarchie
d’une dimension pour obtenir davantage de détails. Par exemple, à partir d’un rapport annuel, on
peut descendre au niveau mensuel, puis hebdomadaire et enfin journalier. Le drill‑down est utile
pour identifier des anomalies ou des variations fines dans les données [9].
Le slice est une opération qui consiste à fixer une valeur particulière d’une dimension afin
d’extraire un sous‑cube. Par exemple, l’analyste peut choisir de n’étudier que les ventes de l’année
2023. Cela permet de restreindre l’analyse à une période, un produit ou une région spécifique tout
en conservant les autres dimensions intactes [9].
Le dice est une opération de sélection multidimensionnelle qui permet de définir un sous‑
cube en appliquant des conditions sur plusieurs dimensions simultanément. Par exemple, on peut
analyser uniquement les ventes des produits A et B en Europe et en Afrique sur la période 2021–
2023. Cette opération offre la possibilité de combiner plusieurs critères pour un focus analytique
plus précis [9].
Le pivot (ou rotation) est une opération qui modifie l’orientation du cube afin de fournir une
nouvelle perspective d’analyse. Ainsi, les ventes peuvent être représentées par produit en ligne et
par région en colonne, puis ces axes peuvent être inversés. Le pivot permet donc de réorganiser
l’affichage des dimensions pour mieux comparer les données et améliorer leur lisibilité [9].

FIG. 3.12 : Opération Cube OLAP

Réalisé par : SAAD LAKNIN Page 57

Rapport de fin d’études État de l’art et travaux connexes

4.9 Types de cubes OLAP

MOLAP (Multidimensional OLAP). Les données sont stockées dans des cubes multidimen‑
sionnels spécialisés, avec des agrégats précalculés. Avantages : rapidité des requêtes, indexation
multidimensionnelle, compression. Limites : moins adapté aux très grands volumes de données
[9].

ROLAP (Relational OLAP). Les données sont stockées dans des bases relationnelles, et les opé‑
rations OLAP sont traduites en requêtes SQL. Avantages : scalabilité élevée, support des grands
volumes, compatibilité SQL. Limites : temps de réponse plus lent, dépend fortement des optimi‑
sations SQL [9].

HOLAP (Hybrid OLAP). Combine les deux approches : les données détaillées restent en base
relationnelle (ROLAP), tandis que les agrégations sont stockées dans des cubes multidimension‑
nels (MOLAP). Avantages : compromis entre scalabilité et performance. Limites : conception et
maintenance plus complexes [9].

FIG. 3.13 : Type de Cube OLAP

4.10 Avantages de l’analyse multidimensionnelle

L’OLAP offre plusieurs bénéfices clés :

• Rapidité : temps de réponse réduit grâce aux agrégats précalculés.

Réalisé par : SAAD LAKNIN Page 58

Rapport de fin d’études État de l’art et travaux connexes

• Exploration flexible : navigation fluide avec les opérations drill‑down, roll‑up, slice et dice.

• Compréhension intuitive : modèle cube simple à comprendre pour les métiers (mesures,
dimensions, hiérarchies).

• Adaptabilité : MOLAP pour la performance, ROLAP pour les grands volumes, HOLAP
pour combiner les deux.

5 Travaux connexes

5.1 Articles scientifiques et études de cas

Dans leur étude, Raj et al. (2016) présentent l’expérience d’une petite et moyenne entreprise
(PME) britannique ayant entrepris une transformation décisionnelle grâce à la mise en place d’une
solution de Business Intelligence. Le contexte décrit est celui d’une organisation aux ressources li‑
mitées, cherchant à dépasser les contraintes d’outils traditionnels comme Excel pour la production
de rapports. Le projet s’est appuyé sur la conception d’un entrepôt de données centralisé, alimenté
par des processus ETL, et relié à des tableaux de bord interactifs. Cette architecture a permis de
réduire considérablement la charge de travail liée au reporting manuel, d’améliorer la qualité des
informations disponibles et d’accélérer la prise de décision au niveau managérial. L’étude insiste
également sur les bénéfices organisationnels liés à l’automatisation, notamment la réduction des
erreurs humaines et la meilleure collaboration entre les équipes [12].

Dans l’article de Yahaya et al. [17], les auteurs décrivent un projet d’intégration de la Business
Intelligence et de l’analytique dans le secteur public en Malaisie, appliqué à la gestion de la perfor‑
mance organisationnelle. L’objectif était de mettre en place un dispositif décisionnel permettant de
suivre plus efficacement les indicateurs clés de performance (KPI). L’architecture proposée com‑
bine un entrepôt de données et des outils analytiques orientés performance. Ce dispositif a permis
d’améliorer la transparence et la fiabilité du reporting, d’assurer un suivi plus précis des objectifs
stratégiques et de favoriser l’adoption d’une culture de gestion basée sur les données au sein des
administrations publiques. L’étude montre que l’intégration de l’analytique à la BI constitue un
levier majeur de modernisation des services publics.

L’étude de Yetgin (2025) se concentre sur la transformation d’une institution financière par
l’adoption d’une plateforme de Business Intelligence centralisée. Le projet visait à remplacer un
système manuel de reporting, coûteux et risqué, par une architecture moderne reposant sur un
entrepôt de données sécurisé et des outils de visualisation automatisée. Grâce à cette refonte, l’or‑
ganisation a pu passer de rapports mensuels lourds à des rapports hebdomadaires automatisés,
tout en améliorant la fiabilité et la sécurité des données. Les résultats montrent une amélioration
significative de l’efficacité opérationnelle, une réduction des erreurs liées au reporting manuel et

Réalisé par : SAAD LAKNIN Page 59

Rapport de fin d’études État de l’art et travaux connexes

une autonomie renforcée pour les équipes métiers. L’auteur insiste également sur le rôle organi‑
sationnel de la BI, qui a contribué à renforcer la gouvernance des données et la culture analytique
de l’institution [19].

Dans leur contribution, Orji et al. (2023) illustrent le déploiement d’un projet BI appliqué au
service de vélos partagés Divvy à Chicago. L’étude met en avant le cycle complet de valorisa‑
tion des données : extraction, nettoyage, transformation, analyse et visualisation. L’architecture
repose sur un pipeline ETL qui alimente des outils analytiques et de reporting interactif. Cette
approche a permis d’identifier des tendances d’utilisation des vélos, comme les pics horaires et
les profils types d’usagers, et d’élaborer des recommandations pour améliorer la distribution et la
disponibilité des vélos. Les auteurs soulignent que cette expérience montre la capacité de la BI à
transformer des données opérationnelles brutes en insights stratégiques directement exploitables
pour l’optimisation des services urbains [11].

Dans l’article de Hasan et al. [7], les auteurs analysent les principaux défis rencontrés dans
des projets d’implémentation de la Business Intelligence à travers différents secteurs, notamment
les télécommunications (Telenor au Pakistan), les PME en Pologne et l’hôtellerie avec Marriott.
L’étude s’appuie sur une revue de littérature et plusieurs études de cas pour classifier les difficultés
selon trois dimensions : organisationnelle, technologique et procédurale. Les obstacles les plus
fréquents identifiés incluent la mauvaise qualité des données, les budgets limités, la résistance au
changement et le manque d’expertise technique. Toutefois, certains cas, comme celui de Marriott,
illustrent que la BI peut générer une valeur ajoutée tangible lorsqu’elle est correctement adoptée,
notamment en renforçant la fidélisation client et en optimisant les stratégies de réservation. Cette
étude met ainsi en lumière l’importance d’une gouvernance claire et d’un engagement fort du
management pour réussir un projet BI.

Enfin, Bagheri et Zwering [3] proposent une étude de cas approfondie menée dans une banque
multinationale néerlandaise afin d’identifier les facteurs critiques de succès (CSF) pour les pro‑
jets de Business Intelligence et d’Analytics. Leur démarche repose sur une méthodologie en deux
étapes : une revue systématique de la littérature identifiant treize CSF, suivie d’une enquête em‑
pirique composée de douze entretiens semi‑directifs avec des experts et managers. L’architecture
inclut un entrepôt de données et un dispositif de gouvernance BI renforcé. Les résultats mettent
en évidence que le soutien managérial et la qualité des données constituent les leviers essentiels
de succès, tandis que la communication entre départements et l’implication active des utilisateurs
finaux complètent ces conditions. Les auteurs proposent un cadre intégré des CSF qui peut servir
de référence pour d’autres institutions financières souhaitant entreprendre des projets similaires.

Réalisé par : SAAD LAKNIN Page 60

Rapport de fin d’études État de l’art et travaux connexes

5.2 Comparaison entre les résultats

Article Contexte Architecture / Résultats et apports

Approche

Raj et al. PME britan‑ Entrepôt de don‑ Reporting automatisé, ré‑

(2016) [12] nique, ressources nées centralisé + duction des erreurs, déci‑
limitées. ETL + tableaux sions plus rapides.
de bord.

Yahaya et al. Secteur public Entrepôt de don‑ Suivi stratégique renfor‑

(2019) [17] malaisien (KPI). nées + outils ana‑ cé, transparence accrue,
lytiques orientés culture analytique.
performance.

Yetgin (2025) Institution Entrepôt de don‑ Rapports accélérés, fiabili‑

[19] financière, mo‑ nées sécurisé + té accrue, meilleure gou‑
dernisation du visualisation au‑ vernance des données.
reporting. tomatisée.

Orji et al. Service de vélos Pipeline ETL + Analyse des usages, opti‑
(2023) [11] partagés (Chica‑ outils de visuali‑ misation de la distribution
go). sation. des vélos.

Hasan et al. Secteurs variés : Revue + études Défis identifiés : qualité

(2016) [7] télécoms, PME, de cas (entrepôts des données, budgets, ré‑
hôtellerie. et solutions lo‑ sistance au changement.
cales).

Bagheri & Banque mul‑ Revue systéma‑ CSF : soutien managérial,

Zwering tinationale tique + entre‑ qualité des données, com‑
(2023) [3] néerlandaise. tiens ; entrepôt + munication, implication
gouvernance BI. des utilisateurs.

TAB. 3.3 : Tableau comparatif des travaux connexes en Business Intelligence

5.3 Discussion
L’analyse comparative des six articles étudiés met en évidence plusieurs points communs et
différences notables. Tout d’abord, la plupart des travaux insistent sur la valeur ajoutée de la cen‑
tralisation des données via un entrepôt décisionnel, qu’il s’agisse d’entreprises privées [12, 19]
ou du secteur public [17]. Cette centralisation, associée à des processus ETL et à des outils analy‑
tiques adaptés, constitue un facteur clé pour améliorer la qualité de l’information et accélérer le

Réalisé par : SAAD LAKNIN Page 61

Rapport de fin d’études État de l’art et travaux connexes

processus décisionnel.
Un second point majeur concerne l’importance de la gouvernance des données et du soutien
organisationnel. Les études de [7] et [3] montrent que les projets BI échouent souvent en raison
de problèmes organisationnels : résistance au changement, budgets limités ou encore mauvaise
qualité des données. Inversement, la réussite dépend fortement de l’implication managériale et
de la collaboration inter‑départements.
Par ailleurs, certains cas [11] mettent en évidence le rôle de la BI dans l’optimisation opéra‑
tionnelle, en démontrant comment l’analyse des données peut transformer des processus urbains
tels que la gestion des vélos partagés. Cela illustre le potentiel de la BI non seulement comme outil
de reporting, mais aussi comme levier d’innovation et d’amélioration des services.
Enfin, il apparaît que si les approches techniques (entrepôts, pipelines ETL, visualisation) sont
relativement similaires, les résultats dépendent fortement du contexte organisationnel et secto‑
riel. La BI appliquée dans une PME, une institution financière ou un service public ne répond pas
aux mêmes contraintes, mais toutes convergent vers un même objectif : rendre la décision plus
rapide, fiable et stratégique.
En somme, ces travaux confirment que la Business Intelligence ne constitue pas uniquement
un projet technologique, mais avant tout un projet socio‑technique, où la réussite repose sur un
équilibre entre infrastructures techniques, qualité des données, et gouvernance organisationnelle.

6 Conclusion
En conclusion, l’état de l’art et l’analyse des travaux connexes ont permis de dégager les en‑
seignements essentiels pour la réussite d’un projet de Business Intelligence. Au‑delà des aspects
technologiques, ils ont montré l’importance d’une vision méthodologique claire et d’une gouver‑
nance adaptée afin de garantir la qualité et la valeur des données. Cette synthèse met en évidence
que la BI ne se limite pas à un ensemble d’outils ou de modèles, mais constitue un levier stratégique
dont l’efficacité repose sur l’articulation entre choix techniques, organisationnels et humains. Ce
chapitre clôt ainsi la partie théorique en posant les bases nécessaires pour la conception et la mise
en œuvre de la solution BI qui feront l’objet des chapitres suivants.

Réalisé par : SAAD LAKNIN Page 62

Rapport de fin d’études Conception et mise en œuvre de la solution

Chapitre 4 :
Conception et mise en œuvre de la solution

Réalisé par : SAAD LAKNIN Page 63

Rapport de fin d’études Conception et mise en œuvre de la solution

1 Introduction
Ce chapitre est consacré à la conception de la solution proposée dans le cadre de ce projet de
Business Intelligence (BI). Il s’agit d’une étape clé qui permet de traduire les besoins fonctionnels
et techniques identifiés en une architecture et un modèle de données cohérents.
Nous présenterons d’abord l’architecture générale envisagée ainsi que les choix technologiques
retenus pour répondre aux objectifs du projet. Ensuite, nous aborderons la modélisation du sys‑
tème décisionnel, en mettant l’accent sur la définition du schéma en étoile, la structuration des
tables de faits et des tables de dimensions, ainsi que les relations qui les unissent.
Cette phase de conception constitue le fondement de la solution BI, puisqu’elle définit la struc‑
ture sur laquelle reposera l’ensemble du système décisionnel et garantit la cohérence des analyses
futures.

2 Architecture proposée pour ce projet

2.1 Architecture proposée

L’architecture décisionnelle mise en place repose sur une approche top‑down, conformément à
la méthodologie proposée par Bill Inmon. Elle se caractérise par la création d’un Data Warehouse
central en 3NF, véritable socle unique et intégré, avant la déclinaison en datamarts et en cubes
OLAP destinés à l’analyse. Cette structure garantit à la fois la cohérence, l’évolutivité et la qualité
des données.

FIG. 4.1 : Architecture de la Solution BI

Réalisé par : SAAD LAKNIN Page 64

Rapport de fin d’études Conception et mise en œuvre de la solution

Sources de données. Les sources de données exploitées dans ce projet proviennent de deux
environnements distincts mais complémentaires. Les bases de données Oracle constituent une
source structurée et centralisée, contenant les informations essentielles relatives à la gestion des
programmes et des activités de formation. En parallèle, des fichiers Excel sont utilisés par les ac‑
teurs du secteur pour compléter ou échanger certaines informations, notamment des indicateurs
spécifiques ou des données opérationnelles collectées sur le terrain. Cette diversité de sources met
en évidence la nécessité d’un processus d’intégration robuste afin de garantir une vision cohérente
et homogène.

Zone de Staging. Afin de préparer ces données avant leur intégration dans l’entrepôt, une zone
de Staging est mise en place. Cet espace tampon permet d’appliquer plusieurs traitements in‑
dispensables : nettoyage des anomalies, suppression des doublons, uniformisation des formats
(dates, codes, encodages, unités de mesure) et consolidation des informations. Le Staging agit
comme une barrière de sécurité entre les systèmes opérationnels et la partie décisionnelle, évitant
toute surcharge et assurant une qualité optimale des données chargées dans l’entrepôt.

Data Warehouse et gestion des SCD. Le cœur du dispositif est constitué par le Data Warehouse
(DWH). Cet entrepôt centralise et intègre l’ensemble des données dans un modèle relationnel co‑
hérent et historisé. Un point clé du Data Warehouse est la gestion des Slowly Changing Dimensions
(SCD), qui permet de suivre l’évolution des données de référence dans le temps. Deux approches
principales sont utilisées. La première, le SCD Type 1, consiste à écraser les anciennes valeurs et
ne conserver que la version la plus récente de l’information, ce qui est pertinent pour les correc‑
tions mineures. La seconde, le SCD Type 2, crée un nouvel enregistrement à chaque modification
avec une date de début et une date de fin de validité, permettant ainsi de conserver l’historique
complet et de réaliser des analyses temporelles. Cette gestion des SCD est particulièrement impor‑
tante dans le secteur de la formation professionnelle, où les données relatives aux programmes,
établissements ou filières peuvent évoluer au fil du temps.

Datamarts et cubes OLAP. Sur la base de ce Data Warehouse, des datamarts thématiques sont
développés afin de répondre aux besoins des différents acteurs institutionnels et pédagogiques.
Ces datamarts alimentent ensuite des cubes OLAP, qui permettent de réaliser des analyses mul‑
tidimensionnelles. Grâce à cette organisation, il devient possible de suivre l’évolution des indi‑
cateurs de la formation professionnelle selon différents axes d’analyse (par exemple par établis‑
sement, par région, par type de programme ou par année), d’effectuer des comparaisons et de
produire des tableaux de bord fiables pour le pilotage stratégique.

Reporting et visualisation. La restitution des données et leur valorisation s’appuient sur l’outil
Power BI. Celui‑ci permet de concevoir des tableaux de bord interactifs, de visualiser les données

Réalisé par : SAAD LAKNIN Page 65

Rapport de fin d’études Conception et mise en œuvre de la solution

consolidées sous forme de graphiques et d’indicateurs dynamiques, et de diffuser l’information

de manière efficace auprès des décideurs et responsables du secteur. Power BI contribue ainsi à
rendre les analyses accessibles et exploitables, tout en facilitant la prise de décision dans le cadre
du pilotage de la formation professionnelle au Maroc.

2.2 Pourquoi l’approche Inmon ?

Le choix de l’approche Inmon se justifie par le contexte et les objectifs du projet. En effet, le
secteur de la formation professionnelle au Maroc nécessite une vue intégrée et consolidée de
ses données (apprenants, filières, établissements, insertion professionnelle) pour permettre une
gouvernance efficace et une prise de décision stratégique. L’approche Inmon répond parfaitement
à ce besoin car :

• elle garantit une vision d’ensemble unique grâce à un Data Warehouse central en 3NF qui
joue le rôle de socle unique de vérité ;

• elle permet une gestion centralisée de l’historique via les SCD type 1 et 2, indispensable
pour suivre les changements d’affectation d’apprenants, l’évolution des programmes ou la
performance des établissements dans le temps ;

• elle offre une évolutivité forte, puisque de nouvelles sources de données (bases adminis‑
tratives, enquêtes nationales, fichiers Excel des directions régionales) peuvent être intégrées
sans remise en cause de l’architecture ;

• elle favorise une gouvernance des données rigoureuse, en alignant les référentiels natio‑
naux (nomenclatures des filières, répartition des établissements, référentiels métiers) ;

• enfin, elle permet la création de Data Marts thématiques dédiés (apprenants, filières, éta‑
blissements, insertion professionnelle), tout en conservant une cohérence globale.

3 Conception de l’Architecture et du Modèle de Données BI

3.1 Cas d’Utilisation du Système BI

Le diagramme de cas d’utilisation présenté illustre les différentes interactions possibles avec
le système décisionnel (BI). Deux acteurs principaux sont identifiés : l’Administrateur DWH et
l’Utilisateur final. Chacun joue un rôle bien défini, contribuant à la mise en place et à l’exploitation
de la solution BI.

Réalisé par : SAAD LAKNIN Page 66

Rapport de fin d’études Conception et mise en œuvre de la solution

FIG. 4.2 : Use Case de Système décisionnelle

Rôle de l’Administrateur DWH

L’administrateur est responsable de la gestion technique et de l’alimentation du Data Ware‑
house (DWH). Ses principales activités comprennent :

• Planifier et démarrer les traitements ETL pour automatiser l’intégration des données.

Réalisé par : SAAD LAKNIN Page 67

Rapport de fin d’études Conception et mise en œuvre de la solution

• Surveiller les processus ETL et gérer les erreurs afin de garantir la qualité des données.

• Charger les données dans la zone de staging pour un premier stockage temporaire.

• Alimenter le DWH en 3NF avec gestion des SCD1 et SCD2 afin de conserver l’historique
des données.

• Créer et gérer des Datamarts orientés vers les besoins spécifiques des métiers.

• Construire des cubes OLAP permettant l’analyse multidimensionnelle.

• Configurer la connexion avec Power BI pour la visualisation et l’exploration.

Toutes ces opérations nécessitent une authentification administrateur, garantissant la sécurité et

le contrôle d’accès.
Rôle de l’Utilisateur Final
L’utilisateur final exploite les données préparées par l’administrateur. Ses principales interac‑
tions avec le système décisionnel sont :

• Consulter les tableaux de bord pour obtenir une vision synthétique des données.

• Explorer les cubes OLAP afin de réaliser des analyses ad hoc.

• Exporter et imprimer des rapports pour partager les résultats avec d’autres parties pre‑
nantes.

• Consulter les indicateurs KPI pour évaluer la performance et suivre l’évolution des activi‑
tés.

Ces actions passent par une authentification utilisateur qui garantit la personnalisation et la sé‑
curité des accès.
Vision Globale
Le diagramme met en évidence la complémentarité entre les deux acteurs :

• L’Administrateur DWH assure la préparation, la structuration et la mise à disposition des

données.

• L’Utilisateur final exploite ces données pour la prise de décision à travers l’analyse et la
visualisation.

Réalisé par : SAAD LAKNIN Page 68

Rapport de fin d’études Conception et mise en œuvre de la solution

3.2 Modélisation des Interactions : Diagrammes de Séquence

Diagramme de Séquence : Processus ETL vers Staging
Ce diagramme décrit les principales étapes d’alimentation de la zone de staging via l’ETL :

FIG. 4.3 : Séquence d’alimentation de la zone de staging par l’ETL

1. L’équipe de développement alimente la base Oracle avec les données sources.

2. L’administrateur démarre le processus ETL.

3. Extraction des données depuis la base Oracle.

4. Nettoyage et transformation des données.

5. Chargement des données consolidées dans la zone de staging.

Diagramme de Séquence : Processus ETL vers le Data Warehouse (3NF)

Ce diagramme illustre le chargement des données depuis la zone de staging vers le Data Wa‑
rehouse (DWH) en 3NF. Il décrit les interactions entre l’administrateur, le module ETL et le DWH.

FIG. 4.4 : Diagramme de séquence du processus ETL vers le Data Warehouse (3NF)

Réalisé par : SAAD LAKNIN Page 69

Rapport de fin d’études Conception et mise en œuvre de la solution

1. L’administrateur lance le processus ETL vers le DWH.

2. Lecture des données préparées dans la zone de staging.

3. Application des règles métier.

4. Gestion des SCD Type 1 (mise à jour directe des données).

5. Gestion des SCD Type 2 (historisation complète des données).

6. Chargement des données consolidées dans le DWH (3NF).

Diagramme de Séquence : Processus ETL vers les Datamarts et Cubes OLAP

Ce diagramme illustre le passage des données du Data Warehouse (3NF) vers les Datamarts
en schéma étoile, ainsi que leur exploitation dans les cubes OLAP.

FIG. 4.5 : Diagramme de séquence du processus ETL vers les Datamarts et les Cubes OLAP

1. L’administrateur lance l’ETL vers les Datamarts.

2. Extraction des données historisées depuis le DWH.

3. Agrégation et modélisation en étoile.

4. Chargement des données dans les Datamarts.

5. Construction et alimentation des cubes OLAP.

Diagramme de Séquence : Consultation des Tableaux de Bord via Power BI

Ce diagramme illustre l’accès des utilisateurs finaux aux tableaux de bord interactifs générés
à partir des cubes OLAP via Power BI.

Réalisé par : SAAD LAKNIN Page 70

Rapport de fin d’études Conception et mise en œuvre de la solution

FIG. 4.6 : Diagramme de séquence de la consultation des tableaux de bord via Power BI

1. Connexion de Power BI aux cubes OLAP.

2. Génération des tableaux de bord.

3. Connexion et authentification de l’utilisateur final.

4. Consultation des dashboards interactifs.

3.3 Diagramme d’Activité : Flux vers la Zone de Staging

Le diagramme d’activité présenté décrit le processus d’alimentation de la zone de staging à
partir des différentes sources de données. Ce flux permet de préparer les données brutes avant
leur intégration dans le Data Warehouse.

• Vider la table : au début du processus, la table de staging est vidée pour éviter les doublons
et assurer l’intégrité des données.

• Sources de données multiples : les données peuvent provenir de plusieurs systèmes tran‑
sactionnels (Source 1, Source 2, …, Source n).

• Transformation nécessaire : les données brutes subissent des opérations de nettoyage, de

normalisation ou de conversion afin de les rendre exploitables.

• Chargement vers destination : les données transformées sont finalement chargées dans la
zone de staging, servant d’espace intermédiaire temporaire.

Réalisé par : SAAD LAKNIN Page 71

Rapport de fin d’études Conception et mise en œuvre de la solution

FIG. 4.7 : Diagramme d’activité — Flux d’alimentation de la Zone de Staging

3.4 Diagramme d’Activité : Flux vers le Data Warehouse (DWH)

Le diagramme d’activité présenté illustre les différentes étapes de passage des données depuis
la zone de staging vers le Data Warehouse (3NF). Ce processus comprend la préparation des
données, l’application de règles métier ainsi que la gestion des dimensions historisées.

• Lecture depuis le staging : les données sont extraites à partir de la zone de staging via une
connexion OLE DB.

• Préparation des données : avant le chargement, plusieurs opérations sont effectuées :

– Tri (Sort) pour organiser les données.

– Dérivation de colonnes (Derive Columns) pour créer de nouveaux attributs néces‑
saires au DWH.
– Jointure (Merge Join) pour consolider les flux issus de différentes sources.
– Multicast pour dupliquer les données et permettre un traitement parallèle (mise à jour,
suppression, ajout).

• Split conditionnels : les données sont orientées selon des règles métier :

– Delete : suppression des enregistrements devenus obsolètes.

– SCD Type 1 : mise à jour directe des données (correction de valeur).
– SCD Type 2 : historisation complète en ajoutant une nouvelle ligne afin de conserver
l’historique des évolutions.
– Ajout : insertion de nouveaux enregistrements inexistants dans le DWH.

• Chaîne de chargement commune : toutes les données traitées passent ensuite par une phase
finale :

– Préparation pour la cible (Merge/prepare to target) afin d’uniformiser le format.

Réalisé par : SAAD LAKNIN Page 72

Rapport de fin d’études Conception et mise en œuvre de la solution

– Dérivation pour le chargement (Derive for load) pour adapter les colonnes à la struc‑
ture finale.
– Chargement dans le DWH (OLE DB) où les données consolidées sont intégrées dans
les tables du Data Warehouse.

FIG. 4.8 : Diagramme d’activité — Flux de chargement du Staging vers le Data Warehouse (3NF)

3.5 Diagramme d’Activité : Flux vers les Datamarts

Le diagramme d’activité suivant décrit le processus de construction des Datamarts, qui repose
sur l’extraction des données historisées depuis le Data Warehouse (DWH), leur traitement et leur
intégration dans une table de faits. Ce flux permet de passer d’un modèle normalisé (3NF) à un
modèle en étoile plus adapté à l’analyse décisionnelle.

• Lecture des sources DWH : les données proviennent de plusieurs tables du Data Warehouse
(Source A et Source B).

• Préparation : chaque source est triée (Sort A, Sort B) afin de préparer les jointures.

• Jointure (Merge/Join) : les flux sont combinés pour produire un ensemble cohérent.

• Lookups successifs : plusieurs recherches de correspondance sont effectuées :

– No match : lorsqu’aucune correspondance n’est trouvée, les données sont redirigées

vers des unions spécifiques (Union no‑match 1, Union no‑match 2).
– Match : lorsqu’une correspondance existe, les données passent par plusieurs étapes de
vérification (Lookup 1, Lookup 2, Lookup 3) avant d’être redirigées vers Union match.

• Union finale : les flux issus des différents cas (match et no‑match) sont regroupés pour pro‑
duire un flux unique.

• Chargement dans le Datamart : les données finales sont insérées dans la table de faits du
Datamart, qui servira de base aux analyses OLAP et aux tableaux de bord.

Réalisé par : SAAD LAKNIN Page 73

Rapport de fin d’études Conception et mise en œuvre de la solution

FIG. 4.9 : Diagramme d’activité — Flux de construction et alimentation des Datamarts

3.6 Modèle de Données du Data Warehouse

FIG. 4.10 : Modèle relationnel du Data Warehouse (3NF) : tables et clés de liaison.

Le modèle relationnel présenté ci‑dessus est construit selon une approche en troisième forme
normale (3NF), ce qui permet d’éliminer les redondances et de garantir la cohérence des don‑
nées. Il regroupe un ensemble de tables interdépendantes qui structurent les informations rela‑
tives aux inscriptions, aux bénéficiaires, aux établissements, aux formateurs ainsi qu’aux filières

Réalisé par : SAAD LAKNIN Page 74

Rapport de fin d’études Conception et mise en œuvre de la solution

et programmes de formation.
La table DWH_INSCRIPTION occupe une place centrale dans le modèle. Elle enregistre l’en‑
semble des inscriptions réalisées par les bénéficiaires dans une filière donnée et au sein d’un éta‑
blissement précis. Cette table établit des liens directs avec les entités DWH_BENEFICIAIRE, qui
représente les apprenants inscrits, DWH_ETABLISSEMENT, qui identifie l’organisme de forma‑
tion, ainsi que DWH_FILIERE, qui décrit la spécialité concernée. Elle est également reliée à la
table DWH_Programme_validation_request, permettant de suivre les demandes de validation
des programmes associés.
La table DWH_BENEFICIAIRE contient les informations personnelles et administratives des
apprenants. On y retrouve notamment le nom, le prénom, le numéro d’identité, la nationalité,
le sexe, ainsi que des données relatives au niveau scolaire et à la situation professionnelle. Elle
constitue une source essentielle pour analyser le profil des individus inscrits. Parallèlement, la
table DWH_CANDIDAT permet d’enregistrer les informations concernant les personnes ayant
candidaté à une formation, même si elles n’ont pas encore été inscrites. Cette distinction offre la
possibilité de comparer les profils des candidats et ceux des bénéficiaires effectifs.
La table DWH_FILIERE regroupe l’ensemble des filières de formation. Elle précise notamment
le code de la filière, son intitulé, le niveau de formation qu’elle représente ainsi que le domaine
auquel elle appartient. L’information est complétée par la table DWH_HOMOLOGATION, qui
conserve les détails liés à l’homologation officielle des filières ou des établissements, garantissant
la conformité administrative et réglementaire.
La table DWH_ETABLISSEMENT décrit les établissements de formation. Elle contient le nom
de l’établissement, son type, son secteur de rattachement ainsi que des informations relatives aux
dates d’autorisation et d’accréditation. Chaque établissement est géographiquement situé grâce
aux tables DWH_PROVINCE et DWH_REGION. La première associe un établissement à une
province donnée, tandis que la seconde regroupe l’ensemble des régions, permettant ainsi une
hiérarchisation géographique des données et une analyse territoriale des formations.
La gestion des formateurs est assurée par la table DWH_FORMATEUR, qui contient les infor‑
mations personnelles et professionnelles relatives aux enseignants ou intervenants, notamment
leur spécialité, leur niveau académique et leur expérience. Pour compléter cette description, la
table DWH_SUIVI_HEURE_FORMATEUR assure le suivi des heures de formation dispensées
par chaque formateur, ce qui permet de mesurer leur charge horaire et leur implication dans les
différentes filières et établissements.
Enfin, la table DWH_Programme_validation_request trace l’ensemble des demandes de va‑
lidation des programmes de formation. Cette table constitue un élément important du suivi ad‑
ministratif, puisqu’elle relie les filières, les inscriptions et les établissements aux procédures de
validation.

Réalisé par : SAAD LAKNIN Page 75

Rapport de fin d’études Conception et mise en œuvre de la solution

4 Conception du Data Mart

Dans le cadre du système de pilotage de la formation professionnelle, plusieurs catégories d’in‑
dicateurs clés de performance (KPI) sont définies dans la nomenclature statistique nationale. Ces
indicateurs permettent de suivre l’évolution du secteur, de mesurer son efficacité et d’orienter les
décisions stratégiques. Pour mon projet, je me suis concentré particulièrement sur deux catégo‑
ries : l’accès et la participation (catégorie 2) et l’offre de formation (catégorie 3). Pour chacune
d’elles, un datamart spécifique a été conçu afin de faciliter l’analyse et la production de tableaux
de bord.

4.1 Catégorie 2 : Accès et participation au système de formation profession-

nelle
Les indicateurs de cette catégorie visent à mesurer la capacité du système à attirer et accueillir
les stagiaires, tout en assurant l’équité et l’inclusion. On s’intéresse par exemple au nombre total de
stagiaires inscrits, au flux de nouveaux candidats aux concours d’accès, ou encore à la proportion
de bénéficiaires issus de groupes spécifiques (bacheliers, étrangers, personnes en situation de han‑
dicap, détenus, migrants, réfugiés, etc.). Ces KPI permettent donc d’apprécier à la fois l’attractivité
de la formation professionnelle et son ouverture à la diversité.

FIG. 4.11 : Catégorie 2 — Accès & participation

Réalisé par : SAAD LAKNIN Page 76

Rapport de fin d’études Conception et mise en œuvre de la solution

Datamart de Categori 2
Dans mon travail, j’ai conçu ce datamart afin de disposer d’un outil dédié à l’analyse de l’accès et de
la participation au dispositif de formation professionnelle. Le grain que j’ai choisi pour la table de
faits FACT_PARTICIPATION correspond à l’unité analytique la plus fine : chaque ligne traduit
un évènement de participation, c’est‑à‑dire la présence d’un candidat ou d’un bénéficiaire inscrit
dans un établissement précis, replacée dans un cadre temporel et territorial bien défini. Toutes
les relations vers les dimensions se font par des surrogate keys, ce qui garantit la cohérence et la
traçabilité des données.
Chaque dimension du modèle apporte un éclairage spécifique aux utilisateurs. La dimension
DIM_INSCRIPTION fournit le contexte administratif de l’accès, en intégrant les dates d’inscrip‑
tion et de validation, l’année scolaire, le mode de formation et le statut. La dimension DIM BENE‑
FICIAIRE décrit le profil social et éducatif des apprenants à travers des attributs tels que le genre,
l’âge, la nationalité ou le niveau scolaire, et permet ainsi d’évaluer les aspects d’équité et d’inclu‑
sion. La dimension DIM_CANDIDAT renseigne sur les caractéristiques des personnes qui se pré‑
sentent aux concours ou aux sélections, ce qui facilite la comparaison entre le vivier de candidats
et les admissions effectives. La dimension DIM_ETABLISSEMENT situe chaque participation
dans une structure donnée et en précise les caractéristiques principales comme le type, le statut
ou la capacité d’accueil, ce qui est essentiel pour analyser la répartition des charges par établisse‑
ment. Enfin, la dimension DIM_PROVINCE fournit l’ancrage territorial grâce aux informations
sur la province et la région, ce qui permet de cartographier l’accès et d’identifier les disparités
géographiques.
Un point particulier de ce modèle réside dans la dimension DIM_DATE, utilisée sous plusieurs
rôles. Elle intervient pour la date associée au candidat, pour la date liée à un détenu lorsqu’il s’agit
d’un dispositif en milieu carcéral, et pour une date de référence annuelle destinée aux agrégations.
Cette approche de type role‑playing dimension a permis d’éviter la duplication de la même table tout
en respectant la sémantique de chaque temporalité. Grâce à cette organisation, les indicateurs de
la catégorie 2 peuvent être calculés de manière fluide et robuste : il est possible d’analyser l’évo‑
lution des effectifs inscrits sur une période et un territoire, de suivre la dynamique des nouvelles
admissions, de mesurer la part de publics spécifiques et d’établir des ratios d’accès en lien avec les
capacités d’accueil des établissements. La séparation claire entre la table de faits et ses dimensions
assure ainsi la production de mesures fiables tout en maintenant un modèle lisible et exploitable
pour le reporting décisionnel.

Réalisé par : SAAD LAKNIN Page 77

Rapport de fin d’études Conception et mise en œuvre de la solution

FIG. 4.12 : Datamart Catégorie 2 — Accès & participation

4.2 Catégorie 3 : L’offre de formation professionnelle

La troisième catégorie d’indicateurs se concentre sur le développement et la diversification de
l’offre de formation. Elle renseigne sur le nombre total de filières et de programmes, sur la créa‑
tion de nouvelles filières, sur la mise à jour des programmes existants ou encore sur l’adoption de
référentiels élaborés selon l’approche par compétences (APC). Ces indicateurs traduisent directe‑
ment la capacité du dispositif national à adapter son offre aux besoins du marché du travail et à
anticiper les évolutions des métiers.

FIG. 4.13 : Catégorie 3 — Offre de formation

Réalisé par : SAAD LAKNIN Page 78

Rapport de fin d’études Conception et mise en œuvre de la solution

Datamart de Categori 3
Dans mon travail, j’ai également conçu un deuxième datamart qui soutient l’analyse de l’offre de
formation et de son évolution. La table de faits FACT offre de formation est construite avec un
grain orienté « évènement d’offre » : chaque ligne relie un établissement et une filière en fonction
d’un programme ou d’une décision administrative, en l’ancrant dans le temps et l’espace. Cette
granularité rend possible l’étude de la disponibilité effective des parcours, de leur renouvellement
et de leur diffusion territoriale.
La dimension DIM_Etablissement décrit l’organisme porteur à travers ses identifiants sources,
son nom, son type, son statut, son année de fondation, sa capacité d’accueil et les informations
relatives à l’autorisation. La dimension DIM_Etab_Filiere précise le couple établissement–filière
en ajoutant des attributs opérationnels comme la capacité déclarée, le mode de formation et des
indicateurs de roulement, ce qui permet d’analyser la soutenabilité de l’offre dans le temps. La di‑
mension DIM_FILIERE caractérise le contenu pédagogique, en détaillant le niveau de formation,
le programme, la durée et le statut d’innovation ; elle constitue ainsi la dimension centrale pour
inventorier et comparer les catalogues de formation. La dimension DIM Programme validation
request conserve la trace du processus d’instruction des demandes de création ou de modification
de filières, avec les dates de dépôt et de validation, le type de demande, l’approche pédagogique et
l’indication de nouveauté. Enfin, la dimension DIM_PROVINCE fournit la géolocalisation admi‑
nistrative et permet d’analyser la couverture régionale ainsi que les éventuels déséquilibres entre
territoires.
Comme pour le premier datamart, la dimension DIM_DATE joue plusieurs rôles afin de cap‑
turer les différentes temporalités. Elle est utilisée pour la date d’autorisation qui officialise une
ouverture de formation, pour la date de clôture qui marque la fin d’une offre, et pour une date de
contexte liée à l’établissement, destinée aux agrégations calendaires classiques. Cette modélisation
clarifie le suivi des trajectoires de chaque filière au sein des établissements. Grâce à cette organi‑
sation, les décideurs peuvent analyser la croissance du portefeuille de filières, mesurer la part des
nouvelles ouvertures, évaluer la rapidité d’instruction des demandes, contrôler l’adéquation des
capacités affichées avec la diffusion territoriale et suivre les cycles d’ouverture et de fermeture qui
structurent l’offre de formation à moyen terme.

Réalisé par : SAAD LAKNIN Page 79

Rapport de fin d’études Conception et mise en œuvre de la solution

FIG. 4.14 : Datamart Catégorie 3 — Offre de formation

5 Conclusion
En conclusion, la phase de conception a permis de transformer les besoins identifiés en une ar‑
chitecture décisionnelle solide et cohérente. La modélisation du Data Warehouse et la structuration
des datamarts autour des indicateurs clés de performance posent les bases d’un système capable
de garantir l’intégrité, la pertinence et la fiabilité des analyses futures. Cette étape constitue un
jalon essentiel, puisqu’elle conditionne la réussite des phases suivantes, notamment l’implémen‑
tation technique et l’évaluation des résultats, qui feront l’objet du prochain chapitre.

Réalisé par : SAAD LAKNIN Page 80

Rapport de fin d’études Réalisation et présentation des résultats

Chapitre 5 :
Réalisation et présentation des résultats

Réalisé par : SAAD LAKNIN Page 81

Rapport de fin d’études Réalisation et présentation des résultats

1 Introduction
Ce chapitre est consacré à la mise en œuvre pratique de notre travail ainsi qu’à la présentation
des résultats obtenus. Après avoir défini le cadre conceptuel et méthodologique, nous passons
ici à l’étape d’application qui permet de valider les choix effectués lors de la conception. Dans
un premier temps, nous décrivons le processus de réalisation en précisant les différentes étapes
suivies et les outils mobilisés. Dans un second temps, nous présentons et analysons les résultats
issus de cette mise en œuvre. L’objectif est de mettre en évidence la pertinence de la solution
proposée et d’évaluer sa capacité à répondre aux objectifs fixés.

2 Environnement de développement et outils utilisés

Dans le cadre de ce projet, plusieurs outils technologiques et environnements de travail ont été
mobilisés afin d’assurer la réalisation des différentes étapes, allant de la gestion des données à leur
analyse et visualisation, en passant par la modélisation et la collaboration. Dans cette section, nous
présentons de manière détaillée les principaux outils utilisés ainsi que leur rôle dans le projet.

2.1 Oracle Database

Oracle est un système de gestion de base de données relationnelle (SGBDR) largement utilisé
dans les grandes entreprises. Il permet de stocker, gérer et sécuriser de grands volumes de données
tout en assurant la fiabilité et la performance des transactions. Oracle est souvent exploité comme
source de données dans des environnements décisionnels.

FIG. 5.1 : Oracle Database — système de gestion de base de données relationnelle.

2.2 Microsoft SQL Server

SQL Server est le SGBDR développé par Microsoft. Il assure la gestion et la structuration des
données relationnelles et offre une intégration native avec l’écosystème décisionnel de Microsoft.
Dans ce projet, il est utilisé pour le stockage et la préparation des données en vue de leur exploi‑
tation.

Réalisé par : SAAD LAKNIN Page 82

Rapport de fin d’études Réalisation et présentation des résultats

FIG. 5.2 : SQL Server — plateforme de gestion et de structuration des données.

2.3 SQL Server Integration Services (SSIS)

SSIS est un outil d’intégration de données faisant partie de SQL Server. Il permet de mettre en
œuvre des processus ETL (Extraction, Transformation, Chargement) afin de collecter des données
depuis des sources hétérogènes, de les transformer (nettoyage, agrégation, conversion) et de les
charger vers un entrepôt de données.

FIG. 5.3 : SSIS — outil d’intégration et de transformation des données (ETL).

2.4 SQL Server Analysis Services (SSAS)

SSAS est un composant décisionnel de SQL Server qui permet de créer et d’exploiter des cubes
OLAP (Online Analytical Processing). Il facilite l’analyse multidimensionnelle des données en of‑
frant des perspectives riches sur les indicateurs métiers. Dans ce projet, il est utilisé pour structurer
les données et répondre à des requêtes complexes via le langage MDX.

FIG. 5.4 : SSAS — analyses multidimensionnelles et cubes OLAP.

2.5 Power BI et Power BI Reporting

Power BI est un outil de visualisation et de reporting interactif développé par Microsoft. Il
permet de créer des tableaux de bord dynamiques et d’analyser les données de manière intuitive

Réalisé par : SAAD LAKNIN Page 83

Rapport de fin d’études Réalisation et présentation des résultats

à travers des graphiques et des indicateurs personnalisés. Le module Power BI Reporting est utilisé
pour la génération et la publication de rapports analytiques.

FIG. 5.5 : Power BI — visualisation et reporting interactif.

2.6 UML (Unified Modeling Language)

L’UML est un langage de modélisation normalisé qui permet de représenter graphiquement
la structure et le comportement d’un système. Dans ce projet, il a été utilisé pour décrire les pro‑
cessus métiers ainsi que l’architecture de la solution à travers des diagrammes de classes, de cas
d’utilisation et d’activités.

FIG. 5.6 : UML — langage de modélisation unifié.

2.7 Visual Studio

Visual Studio est un environnement de développement intégré (IDE) proposé par Microsoft. Il
offre un espace complet pour le codage, la gestion de projets et le débogage. Dans ce projet, Visual
Studio a été utilisé principalement pour développer et gérer les packages SSIS ainsi que d’autres
scripts nécessaires.

Réalisé par : SAAD LAKNIN Page 84

Rapport de fin d’études Réalisation et présentation des résultats

FIG. 5.7 : Visual Studio — environnement de développement intégré (IDE).

2.8 GitHub
GitHub est une plateforme de gestion de versions basée sur Git. Elle permet de stocker le code
source, de suivre les modifications et de faciliter la collaboration entre plusieurs développeurs
grâce au contrôle de version distribué. Cet outil a été utilisé pour gérer le code du projet et assurer
la traçabilité des évolutions.

FIG. 5.8 : GitHub — gestion de versions et collaboration sur le code.

2.9 Microsoft Teams

Microsoft Teams est une plateforme de communication et de collaboration en temps réel. Elle
permet de réaliser des réunions, d’échanger des messages instantanés et de partager des fichiers
entre les membres de l’équipe. Dans le cadre de ce projet, Teams a joué un rôle essentiel pour la
coordination et le suivi des tâches.

Réalisé par : SAAD LAKNIN Page 85

Rapport de fin d’études Réalisation et présentation des résultats

FIG. 5.9 : Microsoft Teams — outil de communication et de collaboration.

2.10 Langages SQL et MDX

SQL (Structured Query Language) est le langage standard utilisé pour interroger et manipu‑
ler les bases de données relationnelles. MDX (Multidimensional Expressions) est quant à lui un
langage conçu pour interroger les cubes OLAP et manipuler les données multidimensionnelles. Il
est utilisé principalement avec SSAS pour analyser les mesures selon plusieurs axes et hiérarchies.

FIG. 5.10 : Langages SQL et MDX — interrogation relationnelle et multidimensionnelle.

3 Collaboration et gestion de projet avec GitHub

Dans le cadre de ce projet, GitHub a été utilisé comme plateforme centrale de collaboration.
Il a permis de stocker et de partager le code, de suivre l’avancement des différentes étapes, et de
faciliter la gestion des versions. L’utilisation de GitHub a également rendu possible une meilleure
coordination entre les membres de l’équipe grâce à la clarté et la transparence apportées par le
dépôt du projet.

Réalisé par : SAAD LAKNIN Page 86

Rapport de fin d’études Réalisation et présentation des résultats

3.1 Structure du projet sur GitHub

FIG. 5.11 : Structure du projet collaboratif sur GitHub.

Le dépôt du projet est organisé en plusieurs répertoires, chacun correspondant à une étape clé
du processus d’alimentation et d’exploitation du système décisionnel :

• Staging : contient les scripts des ETL de la partie staging, où les données brutes issues des
sources opérationnelles sont nettoyées et préparées pour l’intégration.

• DW (Data Warehouse) : regroupe les scripts permettant d’alimenter l’entrepôt de données

en suivant le modèle en 3NF. Cette étape assure la centralisation et la cohérence des données.

• DataMarts : comprend les programmes dédiés à l’alimentation des datamarts, orientés vers
des besoins analytiques spécifiques.

• Cube : contient la configuration des cubes OLAP pour l’analyse multidimensionnelle.

• Viz : rassemble les éléments de visualisation et de reporting (tableaux de bord, graphiques,

etc.) qui permettent d’exploiter les informations issues du système décisionnel.

Cette structuration claire du projet sur GitHub permet non seulement de segmenter les res‑
ponsabilités, mais aussi de rendre le projet plus lisible et plus facile à maintenir.

Réalisé par : SAAD LAKNIN Page 87

Rapport de fin d’études Réalisation et présentation des résultats

4 Développement des traitements ETL

Dans le projet, les données sont d’abord collectées depuis les différentes sources et centralisées
dans la zone de staging, où elles sont préparées pour le traitement. Elles sont ensuite transférées
vers le Data Warehouse (DWH), qui sert de stockage centralisé et garantit la cohérence des infor‑
mations. Enfin, des sous‑ensembles de données sont redirigés vers les datamarts, organisés par
thématique ou besoin métier, pour permettre leur exploitation dans les analyses et rapports.
Dans cette partie, nous présentons les flux de données spécifiques entre la zone de staging, le
DWH et les datamarts, afin d’illustrer le cheminement des données depuis leur extraction jusqu’à
leur exploitation finale.

4.1 Les flux ETL de la zone de staging

Dans le cadre de la réalisation de notre projet BI, nous avons mis en place une zone de Staging.
Cette zone joue le rôle d’espace intermédiaire entre les sources de données et l’entrepôt (Data
Warehouse). Elle sert principalement à centraliser les données brutes, mais également à appliquer
des transformations légères afin de faciliter leur exploitation dans les étapes suivantes.
Transformations effectuées
Dans la zone de Staging, certaines opérations de préparation ont été appliquées, parmi les‑
quelles :

• Normalisation des formats : uniformisation des dates, des chaînes de caractères et des types
numériques ;

• Nettoyage des données : suppression des doublons et gestion des valeurs manquantes ;

• Harmonisation des clés : adaptation des identifiants et des relations pour assurer la cohé‑
rence entre les différentes entités ;

• Filtrage initial : élimination des enregistrements inutiles pour l’analyse (par exemple don‑
nées de test ou incohérentes).

Tables principales
Les principales tables de la zone Staging sont les suivantes :

• BÉNÉFICIAIRE : informations sur les bénéficiaires ;

• CANDIDAT : données relatives aux candidats et à leurs inscriptions ;

• ÉTABLISSEMENT : détails sur les établissements de formation ;

• FILIÈRE : liste des filières ou programmes disponibles ;

• FORMATEUR : informations sur les formateurs et leurs affectations ;

Réalisé par : SAAD LAKNIN Page 88

Rapport de fin d’études Réalisation et présentation des résultats

• INSCRIPTION : enregistre les inscriptions individuelles ou par groupe ;

• HOMOLOGATION : suivi des homologations et validations ;

• PROGRAMME_VALIDATION_REQUEST : conserve les demandes de validation liées aux

programmes ;

• PROVINCE et RÉGION : référentiels géographiques.

Table Candidat

FIG. 5.12 : Flux SSIS de chargement des données de la table CANDIDAT Flux de Controle

FIG. 5.13 : Flux SSIS de chargement des données de la table CANDIDAT

Les deux figures ci‑dessous illustrent le processus de traitement des données pour la table
CANDIDAT. La première figure représente le flux de contrôle, qui définit la séquence d’exécution
des différentes tâches du package SSIS. La seconde figure montre le flux de données, où les in‑
formations sont extraites de la source Oracle, puis soumises à un fractionnement conditionnel

Réalisé par : SAAD LAKNIN Page 89

Rapport de fin d’études Réalisation et présentation des résultats

permettant de séparer les enregistrements selon des règles prédéfinies. Une conversion est en‑
suite effectuée pour uniformiser les types de données et garantir leur compatibilité avec la base
cible. Enfin, les données transformées sont chargées dans la destination OLE DB, correspondant
à la table de Staging.
Table Bénéficiaire

FIG. 5.14 : Flux SSIS de chargement des données de la table BENEFICIAIRE

Ce flux illustre l’intégration des données de la table BENEFICIAIRE. Les informations sont ex‑
traites depuis deux sources Oracle distinctes, puis triées afin d’assurer la cohérence des enregis‑
trements. Une jointure de fusion permet ensuite de combiner les données issues des deux flux.
Un composant script est utilisé pour appliquer un traitement personnalisé, suivi d’une colonne

Réalisé par : SAAD LAKNIN Page 90

Rapport de fin d’études Réalisation et présentation des résultats

dérivée afin de générer de nouveaux champs ou d’adapter certains formats. Enfin, les données
consolidées sont chargées dans la destination OLE DB de la zone de Staging.
Table PROGRAMME VALIDATION REQUEST

FIG. 5.15 : Flux SSIS de chargement des données de la table PROGRAMME_VALIDATION_REQUEST

Ce flux montre l’extraction des données depuis la source Oracle, suivie d’une étape de colonne
dérivée permettant de générer ou transformer certains attributs. Les données sont ensuite trans‑
férées vers la destination OLE DB de la zone de Staging.
Table Filière

FIG. 5.16 : Flux SSIS de chargement des données de la table FILIERE

Ce flux illustre un chargement direct des données depuis la table source Oracle vers la table
de Staging correspondante. Aucune transformation intermédiaire n’est appliquée, ce qui permet
de conserver les données dans leur format brut d’origine.

Réalisé par : SAAD LAKNIN Page 91

Rapport de fin d’études Réalisation et présentation des résultats

4.2 Zone Data Warehouse (DWH)

Dans cette partie, l’accent est mis sur la zone Data Warehouse, considérée comme le cœur
du système décisionnel. Elle reçoit les données depuis le Staging à travers des packages SSIS,
puis les prépare à l’analyse grâce à différentes transformations. Ces traitements permettent de
consolider les informations, d’appliquer les règles métiers, d’assurer la cohérence entre les entités
et de produire des données fiables et structurées.
Table CANDIDAT DWH

FIG. 5.17 : Flux SSIS de chargement des données vers la table CANDIDAT DWH

Ce flux gère l’intégration des données candidates dans le DWH. Il applique des transforma‑
tions et utilise les méthodes SCD de type 1 et 2 pour assurer à la fois la mise à jour des données
courantes et l’historisation des évolutions.
Table PROGRAMME VALIDATION REQUEST DWH

FIG. 5.18 : Flux SSIS de chargement des données vers la table PROGRAMME VALIDATION REQUEST
DWH

Réalisé par : SAAD LAKNIN Page 92

Rapport de fin d’études Réalisation et présentation des résultats

Ce flux alimente la table Programme Validation Request dans le DWH. Il combine plusieurs
opérations de recherche et de jointure afin de préparer des données fiables. L’historisation est
assurée par l’utilisation des SCD de type 1 et 2 pour suivre les évolutions dans le temps.
Table PROVINCE DWH

FIG. 5.19 : Flux SSIS de chargement des données vers la table PROVINCE DWH

Ce flux assure le chargement des données de la province. Il consolide les informations issues
du Staging et du DWH en appliquant des traitements de fusion et de contrôle conditionnel pour
garantir la qualité et la cohérence des enregistrements.
Table FILIÈRE DWH

FIG. 5.20 : Flux SSIS de chargement des données vers la table FILIÈRE DWH

Réalisé par : SAAD LAKNIN Page 93

Rapport de fin d’études Réalisation et présentation des résultats

Ce flux traite l’intégration des données liées aux filières dans le DWH. Il applique des trans‑
formations ciblées afin de maintenir l’intégrité des données et de faciliter leur exploitation dans
les analyses décisionnelles.

4.3 Zone Datamarts

Après l’alimentation du Data Warehouse, la zone Datamarts constitue l’étape suivante du pro‑
cessus décisionnel. Elle organise les données sous forme de tables de dimensions, incluant par
exemple les informations relatives aux candidats, aux filières et aux programmes de validation, de
manière à offrir une structuration adaptée aux différents axes d’analyse. Elle comprend également
des tables de faits qui retracent les événements et mesures essentielles, telles que la participation
aux programmes de formation (catégorie 2) et l’offre de formation (catégorie 3). Cette combinaison
de dimensions et de faits permet d’enrichir les analyses et de renforcer la pertinence des indica‑
teurs de performance.
Table FACT ACCÈS ET PARTICIPATION EFP

FIG. 5.21 : Flux SSIS de chargement de la table de faits Accès et Participation EFP

Ce flux correspond à la mise en place de la table de faits de catégorie 2, dédiée à l’accès et à

la participation aux EFP. Il intègre et consolide les données issues de différentes sources afin de
retracer les événements liés à la participation. Cette historisation permet de suivre les évolutions
et d’analyser les niveaux d’engagement dans le temps.

Réalisé par : SAAD LAKNIN Page 94

Rapport de fin d’études Réalisation et présentation des résultats

Table FACT OFFRE DE FORMATION PROFESSIONNELLE

FIG. 5.22 : Flux SSIS de chargement de la table de faits Offre de Formation Professionnelle

Ce flux est rattaché à la catégorie 3 et concerne l’offre de formation professionnelle. Il gère

l’intégration et la préparation des données afin de représenter l’ensemble des offres disponibles et
leurs évolutions. La structuration de cette table permet d’analyser la diversité, la couverture et la
dynamique des programmes de formation proposés.

5 Mise en place des Cubes OLAP

Après la mise en place des datamarts, l’étape suivante concerne la construction des cubes
OLAP. Ces cubes permettent d’exploiter les données en croisant les dimensions et les faits afin
de réaliser des analyses multidimensionnelles. Dans ce cadre, deux cubes principaux ont été dé‑
veloppés : le cube de catégorie 2 relatif à la Participation EFP, et le cube de catégorie 3 consacré à
l’Offre de formation professionnelle. Ils offrent une vision agrégée et interactive, facilitant l’explora‑
tion des données et la production d’indicateurs stratégiques.

Réalisé par : SAAD LAKNIN Page 95

Rapport de fin d’études Réalisation et présentation des résultats

5.1 Cube OLAP Catégorie 2 : Participation EFP

FIG. 5.23 : Cube OLAP de la catégorie 2 : Participation EFP

Ce cube est consacré à l’analyse de la participation aux EFP. Il s’appuie sur plusieurs dimen‑
sions telles que Candidat, Bénéficiaire, Inscription, Établissement, Province et Date. Ces di‑
mensions permettent de croiser les faits relatifs au nombre de stagiaires et aux inscriptions avec
des axes temporels, géographiques et organisationnels, afin d’obtenir une vision multidimension‑
nelle des niveaux de participation.

Réalisé par : SAAD LAKNIN Page 96

Rapport de fin d’études Réalisation et présentation des résultats

5.2 Cube OLAP Catégorie 3 : Offre de Formation Professionnelle

FIG. 5.24 : Cube OLAP de la catégorie 3 : Offre de Formation Professionnelle

Ce cube est dédié à l’étude de l’offre de formation professionnelle. Il mobilise des dimensions
telles que Établissement, Filière, Établissement-Filière, Programme Validation Request, Province
et Date. L’intégration de ces dimensions permet d’analyser le nombre de filières offertes par ré‑
gion, la répartition par établissements et l’évolution de l’offre dans le temps, fournissant ainsi une
base solide pour l’aide à la décision.

5.3 Les requêtes MDX pour le Cube Catégorie 2 : Participation EFP

Listing 5.1 : Requête MDX : Comptage distinct des stagiaires

1 DISTINCTCOUNT (
2 NONEMPTY (
3 (
4 [DIM INSCRIPTION ].[ INSCRIPTION SK ].[ INSCRIPTION SK ]. MEMBERS ,
5 [DIM INSCRIPTION ].[ STATUT ].&[ Stagiaire ]
6 ),
7 [ Measures ].[ FACT PARTICIPATION FP Nombre ]
8 )
9 )

Listing 5.2 : Requête MDX : Proportion de stagiaires titulaires du Bac

1 IIF ([ Measures ].[ NB Stagaire ] = 0, NULL ,
2 [ Measures ].[ Stagaire titulaire de Bac] / [ Measures ].[ NB Stagaire ]
3 )

Réalisé par : SAAD LAKNIN Page 97

Rapport de fin d’études Réalisation et présentation des résultats

5.4 Les requêtes MDX pour le Cube Catégorie 3 : Offre de Formation Pro-
fessionnelle

Listing 5.3 : Requête MDX : Proportion de stagiaires en situation de handicap

1 IIF ([ Measures ].[ NB Stagaire ] = 0, NULL ,
2 [ Measures ].[ NB Stagaire Handicapé ] / [ Measures ].[ NB Stagaire ]
3 )

Listing 5.4 : Requête MDX : Comptage distinct des filières nouvelles

1 DISTINCTCOUNT (
2 NONEMPTY (
3 [DIM FILIERE ].[ FILIERE SK ].[ FILIERE SK ]. MEMBERS ,
4 (
5 [ Measures ].[ FACT Offre De Formation Nombre ],
6 [DIM FILIERE ].[ PROGRAMME ]. CurrentMember ,
7 [DIM FILIERE ].[ Is New ].&[1]
8 )
9 )
10 )

Listing 5.5 : Requête MDX : Comptage distinct des programmes validés

1 DISTINCTCOUNT (
2 NONEMPTY (
3 FILTER (
4 [DIM Programme Validation Request ].[ Programme Sk ].[ Programme Sk ]. MEMBERS ,
5 NOT (
6 [DIM Programme Validation Request ].[ Programme Sk ]. CURRENTMEMBER IS
7 [DIM Programme Validation Request ].[ Programme Sk ].[ Unknown ]
8 )
9 ),
10 (
11 [ Measures ].[ FACT Offre De Formation Nombre ],
12 [DIM Programme Validation Request ].[ APPROCHE ]. CURRENTMEMBER ,
13 [DIM Programme Validation Request ].[ DEMANDEUR ]. CURRENTMEMBER ,
14 [DIM Programme Validation Request ].[ TYPE DEMANDE ]. CURRENTMEMBER
15 )
16 )
17 )

Réalisé par : SAAD LAKNIN Page 98

Rapport de fin d’études Réalisation et présentation des résultats

6 Visualisation et Restitution des Données

Après la construction des cubes OLAP, l’étape suivante consiste à présenter les dashboards
développés à partir de ces cubes. Dans cette partie, l’accent est mis sur deux tableaux de bord
principaux : le premier concerne la catégorie 2, relatif à la Participation EFP, tandis que le second
est dédié à la catégorie 3, portant sur l’Offre de formation professionnelle. Ces dashboards permettent
de restituer les indicateurs clés de manière visuelle et interactive, offrant ainsi une meilleure com‑
préhension des tendances et facilitant la prise de décision.

6.1 Dashboard Catégorie 2 : Participation EFP

FIG. 5.25 : Dashboard Catégorie 2 – Indicateurs globaux de la participation EFP

FIG. 5.26 : Dashboard Catégorie 2 – Bénéficiaire

Réalisé par : SAAD LAKNIN Page 99

Rapport de fin d’études Réalisation et présentation des résultats

FIG. 5.27 : Dashboard Catégorie 2 – Candidat et Taux d’affluence vers la FP

FIG. 5.28 : Dashboard Catégorie 2 – Version avec filtres dynamiques (année, région)

Le dashboard de catégorie 2, consacré à la Participation EFP, présente différents indicateurs tels

que le nombre total de stagiaires, leur répartition par genre, par région et par nationalité, ainsi que
l’évolution annuelle des effectifs. Une version enrichie avec des filtres dynamiques (année, région)
permet d’affiner l’analyse en fonction de critères spécifiques, offrant une lecture plus détaillée des
tendances et des disparités territoriales.

Réalisé par : SAAD LAKNIN Page 100

Rapport de fin d’études Réalisation et présentation des résultats

6.2 Dashboard Catégorie 3 : Offre de formation professionnelle

FIG. 5.29 : Dashboard Catégorie 3 – Indicateurs globaux de l’offre de formation professionnelle

FIG. 5.30 : Dashboard Catégorie 3 – Répartition par région et par programme

Le dashboard de catégorie 3, dédié à l’offre de formation professionnelle, met en avant les princi‑
paux indicateurs relatifs aux programmes et aux filières. On y retrouve le nombre de programmes

Réalisé par : SAAD LAKNIN Page 101

Rapport de fin d’études Réalisation et présentation des résultats

actualisés, leur évolution par année de dépôt ou de validation, ainsi que la répartition par type et
par approche (APC ou APO). Des graphiques supplémentaires présentent la répartition des filières
et des établissements par région, permettant d’analyser la couverture géographique de l’offre et
son évolution dans le temps.

7 Déploiement des Tableaux de Bord

Après la conception et la validation des cubes OLAP, les tableaux de bord ont été déployés sur
Power BI Report Server. Deux dossiers distincts ont été créés afin d’organiser les rapports selon
les catégories :

• Catégorie 2 – Accès et Participation aux EFP : ce dossier contient l’ensemble des tableaux
de bord relatifs à l’accès et à la participation.

• Catégorie 3 – Offre de Formation Professionnelle : ce dossier regroupe les visualisations

dédiées à l’offre de formation.

FIG. 5.31 : Dossier déployé sur Power BI Report Server – Catégorie 2 (Accès et Participation aux
EFP)

Réalisé par : SAAD LAKNIN Page 102

Rapport de fin d’études Réalisation et présentation des résultats

FIG. 5.32 : Dossier déployé sur Power BI Report Server – Catégorie 3 (Offre de Formation Profes‑
sionnelle)

8 Conclusion
En définitive, la phase de réalisation et de présentation des résultats a permis de valider l’archi‑
tecture décisionnelle conçue et de confirmer la fiabilité des traitements mis en place. Les flux ETL,
l’alimentation du Data Warehouse, la structuration en datamarts ainsi que la mise en place des
cubes OLAP se sont traduits par des tableaux de bord interactifs, offrant une vision claire et mul‑
tidimensionnelle des données. Ces résultats témoignent de la maturité de la solution développée
et ouvrent la voie à des perspectives d’évolution et d’optimisation continue.

Réalisé par : SAAD LAKNIN Page 103

Rapport de fin d’études CONCLUSION GÉNÉRALE

CONCLUSION GÉNÉRALE
Au terme de ce travail, nous avons pu mettre en place une approche méthodologique visant à
répondre aux objectifs fixés. La démarche adoptée, allant de la préparation et l’exploration des
données jusqu’à l’analyse et l’interprétation des résultats, a permis de mettre en évidence l’impor‑
tance de la structuration et de la qualité des données dans la réussite d’un projet. Les résultats
obtenus confirment la pertinence des choix technologiques et méthodologiques réalisés, tout en
soulignant certaines limites liées notamment au volume, à la diversité et à l’hétérogénéité des
données traitées.
Ce projet a constitué une expérience enrichissante sur le plan technique et scientifique, en per‑
mettant de mobiliser des outils modernes de traitement, d’analyse et de visualisation, mais aussi
sur le plan méthodologique en développant des compétences d’organisation, de réflexion critique
et de travail collaboratif.
Cependant, plusieurs perspectives d’amélioration restent ouvertes. D’une part, l’intégration
de méthodes plus avancées, notamment basées sur l’intelligence artificielle et l’apprentissage pro‑
fond, pourrait améliorer la précision et la pertinence des analyses. D’autre part, une extension
du périmètre de l’étude à des données plus volumineuses et diversifiées offrirait une vision plus
complète et généralisable des phénomènes étudiés. Enfin, le déploiement des solutions proposées
dans un environnement réel, avec une interaction directe avec les utilisateurs finaux, permettrait
de valider leur efficacité et d’identifier de nouvelles pistes d’optimisation.
En somme, ce travail constitue une base solide qui ouvre la voie à des développements futurs
plus ambitieux, et s’inscrit dans une dynamique d’évolution continue des pratiques d’analyse et
de valorisation des données.

Réalisé par : SAAD LAKNIN Page 104

Rapport de fin d’études BIBLIOGRAPHIE

Bibliographie
[1] Adebunmi Okechukwu Adewusi, Ugochukwu Ikechukwu Okoli, Ejuma Adaga, Temidayo
Olorunsogo, Onyeka Franca Asuzu, and Donald Obinna Daraojimba. Business intelligence
in the era of big data : A review of analytical tools and competitive advantage. Computer
Science IT Research Journal, 5(2) :415–431, February 2024.

[2] Tamara Adel Al‑Maaitah, Al Smadi Khalid, Ala’a Mohammed Fadel Al‑Junaidi, Tariq Khai‑
ro Issa Al Daabseh, Ahmed Alnawafleh, Nour Abdulwahab Qatawneh, and Dirar Abdelaziz
Al‑Maaitah. Strategies for success : A theoretical model for implementing business intelli‑
gence systems to enhance organizational performance. International Journal of ADVANCED
AND APPLIED SCIENCES, 11(5) :55–61, May 2024.

[3] Shohreh Bagheri and Jeroen Zwering. Business intelligence and analytics success factors : A
case study in the financial sector. International Journal of Information Management, 69:102593,
2023.

[4] Ouarda Lina Bensehamdi. L’impact du business intelligence sur les fonctions d’entreprises.
In Ouvrages du CRASC, pages 59–78. Centre de Recherche en Anthropologie Sociale et Cultu‑
relle (CRASC), 2022.

[5] Surajit Chaudhuri and Umeshwar Dayal. An overview of data warehousing and olap tech‑
nology. SIGMOD Record, 26(1) :65–74, 1997.

[6] Jiawei Han, Micheline Kamber, and Jian Pei. Data Mining : Concepts and Techniques. Morgan
Kaufmann, 3rd edition, 2011.

[7] Rizwan Hasan, Suraya Miskon, N. Ahmad, and I. Tlili. Issues and challenges in business
intelligence case studies. International Journal on Advanced Science, Engineering and Information
Technology, 6(6) :924–930, 2016.

[8] Daniel L. Moody and Mark A.R. Kortink. From enterprise models to dimensional models :
A methodology for data warehouse and data mart design. In Proceedings of the International
Workshop on Design and Management of Data Warehouses (DMDW’2000), Stockholm, Sweden,
2000. CEUR‑WS.org.

[9] Adhish Nanda, Swati Gupta, and Meenu Vijrania. A comprehensive survey of olap : Recent
trends. In Proceedings of the Third International Conference on Electronics Communication and
Aerospace Technology (ICECA 2019), pages 425–430. IEEE, 2019.

Réalisé par : SAAD LAKNIN Page 105

Rapport de fin d’études BIBLIOGRAPHIE

[10] In Ong, Pei Siew, and Siew Wong. A five‑layered business intelligence architecture. Commu‑
nications of the IBIMA, page 1–11, March 2011.

[11] R. Orji, A. Singh, and K. Patel. Using data analytics to derive business intelligence : A case
study. arXiv preprint arXiv :2305.19021, 2023.

[12] P. Raj, R. Badii, and N. Aslam. A case study – business intelligence solution for an sme. In
Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER
2016), pages 604–610. SCITEPRESS ‑ Science and Technology Publications, 2016.

[13] Milankumar Rana. Overview of data warehouse architecture, big data and green computing.
Journal of Computer Science and Technology Studies, 5(4) :213–217, 2023.

[14] Ramesh Sharda, Dursun Delen, and Efraim Turban. Business Intelligence, Analytics, and Data
Science : A Managerial Perspective. Pearson, 4th edition, 2018.

[15] Panos Vassiliadis, Alkis Simitsis, and Spiros Skiadopoulos. Conceptual modeling for etl pro‑
cesses. In Proceedings of the ACM 5th International Workshop on Data Warehousing and OLAP
(DOLAP’02), pages 14–21, McLean, Virginia, USA, 2002. ACM.

[16] Carlo Vercellis. Business Intelligence : Data Mining and Optimization for Decision Making. John
Wiley & Sons, 2009.

[17] Nor Azlina Yahaya, Azizah Yahaya, Asmidar Deraman, Norazlin Mokhtar, and Nor Az‑
man Ismail Yusof. The implementation of business intelligence and analytics integration
for organizational performance management : A case study in public sector. In International
Conference on Information Retrieval and Knowledge Management, pages 1–6. IEEE, 2019.

[18] Lamia Yessad and Aissa Labiod. Comparative study of data warehouses modeling ap‑
proaches : Inmon, kimball and data vault. In 2016 International Conference on System Reliability
and Science (ICSRS), pages 94–99. IEEE, 2016.

[19] A. Yetgin. Analyzing the corporate business intelligence impact. Applied Sciences, 15(3) :1012,
2025.

Réalisé par : SAAD LAKNIN Page 106