Mémoire de projet de fin d’étude

Présenté par

SALMA RAISS
En vue de l’obtention du diplôme
Master Universitaire Professionnel
Génie logiciel et web applications
Thème

Automatisation et la mise en place d’une

solution décisionnelle pour le suivi d’une
activité opérationnelle

Encadré par :
Mr MOHAMED HAMMA
Mr HASSAN ABBOU

Année universitaire : 2022/2023

DEDICACE

A ma très chère mère,

Tu représentes pour moi le symbole de la bonté, la source de tendresse et l’exemple de dévouement.
Aucun mot ne saurait exprimer à juste valeur l’amour que je ressente pour toi. Rien au monde ne
vaut les efforts fournis jour et nuit pour mon éducation et mon bien être, je te dois toutes mes
réussites et tout mon succès ;
A mon cher père,
Aucune dédicace ne saurait exprimer mon respect, ma gratitude éternelle et ma considération pour
les sacrifices que tu as consenti pour mon instruction. Tu as fait plus qu’un père puisse faire pour
que ses enfants suivent le bon chemin dans leur vie et leurs études. Je te dédie ce travail en
témoignage de mon profond amour ;
Puisse le tout puissant vous donner santé, bonheur et longue vie afin que je puisse vous combler à
mon tour.
A mes amis,
Je ne saurai vous remercier pour tous les moments qu’on a partagés ensemble durant cette année.
Merci pour vos sourires qui ont illuminés mes jours.

S.R

P a g e 2 | 72
REMERCIMENT
Au terme de ce travail, je tiens à exprimer mes sincères remerciements et ma gratitude envers tous
ceux qui, par leur enseignement, par leur soutien et leurs conseils, ont contribué à
l’accomplissement de ce projet.

Je tiens à remercier mon encadrant à INTELCIA, M. Mohamed Reda MOUAOUIA qui m’a
supervisé avec patience et n’a épargné aucun effort pour mettre à ma disposition les explications
nécessaires et les directives précieuses. Son assistance et ses conseils permanents m’ont été d’un
apport remarquable.

Je tiens également à adresser mes sincères remerciements au Professeur M. HASSAN ABBOU,

mon encadrant MOHAMED AMINE HAMMA, pour tous les conseils qu’il m’a prodigués ainsi
que ses encouragements, sans oublier ses efforts et son grand dévouement.

J’exprime ma gratitude à l’égard de Mme. Fatine BOUAAKIL, IT Project and Program Manager,
de m’avoir accordé cette opportunité pour enrichir mes connaissances et expériences
professionnelles, et de travailler au sein de l’équipe DATA FACTORY

Je suis tout aussi reconnaissante envers les membres du jury, qui m’ont honoré en acceptant de
juger ce travail.

Enfin Je tiens à remercier l’ensemble du corps enseignant et administratif de l’école pour les efforts
qu’ils fournissent afin de nous garantir une bonne formation.

EDICACDEDICAC
RESUME
Le présent document est le fruit du travail de mon projet de fin d’études effectué au sein d’Intelcia
IT Solutions, le pôle d’expertise IT du groupe Intelcia, dans le cadre du projet « PBC » du client
SFR, qui a pour objectif de faire l’automatisation et la refonte de son ancien système d’information
pour la gestion de l’activité opérationnelle. Ma mission se résume dans la contribution à
l’automatisation et la refonte du système décisionnel. Cette nouvelle solution présente un outil
d’aide à la décision basé sur des tableaux de bords permettant aux décideurs une meilleure vision
et un suivi précis de leur activité avec les données actualisés grâce à l’automatisation.
Le projet respecte les étapes du cycle de vie dimensionnel où je commence par étudier la solution
existante et comprendre les besoins et spécifications pour pouvoir contribuer à la conception de la
nouvelle solution décisionnelle, en se basant sur les différents indicateurs et axes d’analyses
relatifs aux tickets concernant l’offre PBC. Ensuite j’entame la réalisation des ETL à l’aide de
l’outils SSIS qui permettront de faire d’une part la reprise des données à savoir des extractions
EXCEL, en y effectuant des transformations pour les adapter à la nouvelle architecture, et d’autre
part, de transférer les données transformées vers une base de données. Finalement, j’ai exploité
les données alimentées dans cette base de données pour réaliser les tableaux de bords sous Power
BI.

Mots clés : Intelcia, Intelcia ITSolutions, PBC, SFR Business, datamart, système décisionnel,
ETL, SSIS, Power BI.

P a g e 4 | 72
ABSTRACT
The present document is the result of my graduation project carried out at Intelcia ITSolutions,
the IT expertise pole of the Intelcia group, as part of the "PBC" project for the SFR Business
client, which aims to automate and redesign its old information system for managing
operational activity. My mission consisted of contributing to the automation and the redesign
of the business intelligence system. This new solution presents a decision support tool based on
dashboards, allowing decision- makers to have a better understanding and precise tracking of
their activity with updated data thanks to automation.
The project follows the stages of the dimensional life cycle, where I begin by studying the
existing solution and understanding the needs and specifications in order to contribute to the
design of the new BI solution, based on various indicators and analysis axes related to PBC
tickets. Then, I start the realization of the ETLs using the SSIS tool, which will make it possible,
on the one hand, to recover data, as EXCEL extractions, by carrying out transformations to
adapt them to the new architecture, and on the other hand, to transfer the transformed data to
the new datamart. Finally, I used the data from this datamart to create the dashboards in Power
BI.

Keywords : Intelcia, Intelcia ITSolutions, PBC, SFR Business, datamart, dashboards,

ETL, SSIS, Power BI.

P a g e 5 | 72
LISTE DES ABREVIATIONS

Abbreviation Designation

BI Business Intelligence

PBC Pack Business Corporate

SFR Société Française du Radiotelephone

ODS operational data store

STG Staging

ETL Extract Transform Load

SSMS SQL Server Management Studio

SQL Structured Query Language

SSMS SQL Server Management Studio

SSIS SQL Server Integration Services

P a g e 6 | 72
TABLE DES FIGURES
FIGURE 1 : Solutions du groupe Intelcia ................................................................................ 13
FIGURE 2 : Histoire du groupe Intelcia .................................................................................. 14
FIGURE 3 : Organigramme d’Intelcia IT Solutions ................................................................... 15
Figure 4: Un schéma du processus Scrum ............................................................................... 24
Figure 5: Planning estimatif du projet ...................................................................................... 26
Figure 6: Planning réel du projet .............................................................................................. 27
Figure 7: Outil Servicenow ...................................................................................................... 33
Figure 8: Outil Clarify .............................................................................................................. 33
Figure 9: Outil Reflex .............................................................................................................. 34
Figure 10: OWorkflow ............................................................................................................. 34
Figure 11: Architecture de la solution ...................................................................................... 41
Figure 12: schéma en flocon .................................................................................................... 42
Figure 13: schéma en étoile ...................................................................................................... 32
Figure 14: schéma en constellation .......................................................................................... 33
Figure 15 : Modèle Incident ..................................................................................................... 35
Figure 16: Modèle Change ....................................................................................................... 36
Figure 17: Modèle Coordination .............................................................................................. 39
Figure 18: Réalisation d’un flux de cloud automatisé.............................................................. 43
Figure 19: Structure de la base de données .............................................................................. 43
Figure 20: Schéma Staging ...................................................................................................... 55
Figure 21: Schéma ODS ........................................................................................................... 60
Figure 22: Schéma AUDIT ...................................................................................................... 61
Figure 23: Procédures stockées ................................................................................................ 55
Figure 24: Schéma PARAM ................................................................................................... 56
Figure 25: Architecture du processus ETL .............................................................................. 56
Figure 26: Processus d’alimentation des tables STG et ODS .................................................. 57
Figure 27: Processus d’alimentation des tables de staging ...................................................... 58
Figure 28: ackage Alimentation de la table Incident staging ................................................... 60
Figure 29: Processus d’alimentation des tables ods ................................................................. 60
Figure 30: Package Alimentation de la table ODS .................................................................. 61
Figure 31: ODS.AlimIncident .................................................................................................. 62
Figure 32: Jobs sous SQL Server Agent .................................................................................. 63
Figure 33: Connexion aux sources de données dans Power BI................................................ 63
Figure 34: Modéle décisionnel "Incident"................................................................................ 64
Figure 35: Modéle décisionnel "Change" ................................................................................ 65
Figure 36: Modèle décisionnel"Build" ..................................................................................... 65
Figure 37: Modèle décisionnel"Build" ..................................................................................... 66
Figure 38: Modèle décisionnel"Build" ..................................................................................... 66
Figure 39: Tableau de bord "Change" ...................................................................................... 67
Figure 40: Tableau de bord "Build" ......................................................................................... 67
Figure 41: Tableau de bord "Coordination" ............................................................................. 68
Figure 42: Publication des tableaux de bord dans le serveur ................................................... 68

P a g e 7 | 72
LISTE DES TABLEAUX
Tableau 1 : tableau comparatif des Frameworks d'agilité ...................................................... 22
Tableau 2 : description de la phase initialisation .................................................................... 25
Tableau 3: Description de la phase préparation et planification ............................................. 25
Tableau 4 Description de la phase production ....................................................................... 26
Tableau5: Description de la phase finalisation ....................................................................... 26
Tableau 6: équipe core du projet ............................................................................................. 28
Tableau 7: Indicateur "Total ticket traité"............................................................................... 35
Tableau 8 Indicateur "Worflow deployé" .............................................................................. 35
Tableau 9: Indicateur "Change traité par attribution" ............................................................. 35
Tableau 10: Indicateur "Total ticket résolu" ........................................................................... 35
Tableau 11: Indicateur "Délai de résolution" .......................................................................... 35
Tableau 12: Indicateur "Total incident" .................................................................................. 35
Tableau 13: Indicateur "Total site migré" ............................................................................... 36
Tableau 14: Description des axes d’analyse pour le cas des tickets des incidents ................. 36
Tableau 15: Description des axes d’analyse pour le cas des tickets des changements ........... 36
Tableau 16: Description des axes d’analyse pour le cas des tickets du build d’outil Reflex . 36
Tableau 17: Table de comparaison ......................................................................................... 44
Tableau 18: Différence entre les trois modes de conception .................................................. 45
Tableau 19: Tableau de bord pour le volet « Incident" ........................................................... 47
Tableau 20: Tableau de bord pour le volet "Change" ............................................................. 48
Tableau 21: Tableau de bord pour le volet"Build" ................................................................. 48
Tableau 22: Tableau de bord pour le volet"Coordination....................................................... 49

P a g e 8 | 72
TABLE DES MATIERES
Liste des abréviations ................................................................................................................. 6
Table des figures ........................................................................................................................ 7
Liste des tableaux ....................................................................................................................... 8
Table des matières ...................................................................................................................... 9
Introduction générale................................................................................................................ 10
Chapitre 1 ................................................................................................................................. 11
Présentation générale ............................................................................................................. 12
1. PRESENTATION DE L’ORGANISME ........................................................................ 13
1.1Groupe Intelcia ................................................................................................................ 13
1.1.1Histoire du Groupe ................................................................................................... 14
1.1.2 Intelcia IT Soulutions .............................................................................................. 14
1.1.3 Organigramme d’Intelcia IT Solutions ................................................................... 15
1.2Contexte du Projet ........................................................................................................... 17
1.2.1 Problématique du projet .......................................................................................... 17
1.2.2 Objectifs du projet .................................................................................................. 18
1.2.3 Les Missions ............................................................................................................ 18
1.3 Démarche du projet ............................................................................................................ 19
1.3.1 Les Livrables ........................................................................................................... 19
1.3.2 ÉTUDE DE RISQUE .............................................................................................. 19
1.3.3. Définition de la méthode Agile .............................................................................. 20
1.3.4 L Définition du Framework Scrum ......................................................................... 20
1.3.5 Pourquoi le Framework Scrum ? ............................................................................. 21
1.3.6. Comparatif des Framework d’agilité...................................................................... 21
1.3.7 Cycle vie de vie Framework Scrum ....................................................................... 23
1.3.8. Description des phasest .......................................................................................... 24
1.3.8.1 Phase1 : Initialisation ....................................................................................... 24
1.3.8.2 Phase2 : Préparation et planification ................................................................ 24
1.3.8.3. Phase3 : Production ............................................................................................ 25
1.3.8.4. Phase4 : Finalisation............................................................................................ 25
1.3.9. Planning du projet .................................................................................................. 25
1.3.9.1. Planning Estimatif ............................................................................................... 25
1.3.9.2 Planning réel ......................................................................................................... 25
1.3.9.3 Analyse des écarts ................................................................................................ 26
1.3.10. Organisations du projet ........................................................................................ 26

P a g e 9 | 72
 1.3.10.1 Équipe CORE27 .............................................................................................. 26
1.3.10.2 Instances de suivi de projet ................................................................................ 27
Conclusion ........................................................................................................................ 27
Chapitre 2 ................................................................................................................................ 28
2.1Rappel du But Projet ....................................................................................................... 29
2.2Étude de l’existant ........................................................................................................... 29
2.2.1Analyse de l’existant ............................................................................................... 29
2.2.2 Analyse de l’ancienne solution .............................................................................. 29
2.2.3 Critique de l’existant ............................................................................................... 30
2.3Recueil des besoins ......................................................................................................... 30
2.3.1. Besoins Fonctionnels.............................................................................................. 30
2.3.2. Besoins non Fonctionnels....................................................................................... 30
2.4. Cadrage fonctionnel ...................................................................................................... 31
2.4.1. Présentation des outils de ticketing ........................................................................ 31
2.4.2. Description des indicateurs .................................................................................... 34
2.4.3. Description des axes d’analyse .............................................................................. 35
2.5. Cadrage technique ........................................................................................................ 36
2.5.1. Architecture générale d’un système décisionnel .................................................... 36
2.5.2. Architecture matérielle ........................................................................................... 36
2. 5.2.1. Présentation de Microsoft SQL Server .............................................................. 36
2.5.2.2. Présentation de Microsoft SQL Server Intégration Services (SSIS) ................... 37
2.5.2.3. Présentation Visual studio 2019 .......................................................................... 37
2.5.2.4. Présentation de Power Bi .................................................................................... 37
2. 5.2.5. Présentation de Microsoft Power Automate....................................................... 38
Conclusion ........................................................................................................................ 38
Chapitre 3 ................................................................................................................................ 39
3.Architecture de la solution .................................................................................................... 40
3.1Modélisation multidimensionnelle ..................................................................................... 41
3.1.1. Choix du modèle .................................................................................................... 43
3.2Modélisation Adoptée ........................................................................................................ 44
3.3. Conception des tableaux de bord ..................................................................................... 46
Conclusion ............................................................................................................................ 48
Chapitre 4 ................................................................................................................................ 48
4.Création d’un flux de cloud automatisé ................................................................................ 10
4.1Création de la base de données "PBC" .............................................................................. 55
4.2.1 Architecture du processus d’ETL .............................................................................. 56
4.3 Réalisation des tableaux de bords Power BI ................................................................... 63

P a g e 10 | 72
 4.3.1Présentation du menu principal de Power BI ......................................................... 63
4.3.1.1.Modèle décisionnel ....................................................................................... 64
4.3.1.2 Présentation des tableaux de bords................................................................. 66
Conclusion générale ................................................................................................................. 70
Bibliographie ............................................................................................................................ 71
Webographie ............................................................................................................................ 72

P a g e 11 | 72
INTRODUCTION GENERALE
L’information représente le patrimoine le plus important pour l’entreprise dans le contexte
actuel. L’entreprise qui valorise et exploite au maximum l’information qu’elle détient peut
s’adapter, évoluer et réagir aux changements continus de son environnement et de sa
concurrence. En effet, disposer d’un système d’informations organisé, cohérent et facilement
accessible contribue largement à une prise de décision pertinente. Les différents processus
métiers de l’entreprise étant tous implémentés dans son système d’information, une quantité
importante de données est produite chaque jour donnant lieu à des informations certes utile
mais difficile à exploiter. L’informatique décisionnelle devient ainsi un enjeu majeur pour
assurer la pérennité de l’entreprise en exploitant son capital intellectuel et en contribuant à la
création de valeur
C’est dans ce contexte qu’Intelcia ITSolutions, organisme d’accueil de mon stage de fin
d’études, prend une orientation stratégique qui consiste à mesurer la performance de ses
différents processus métiers en implémentant un système d’information décisionnel pour
l’activité opérationnelle PBC permettant de suivre les différents états des tickets de chaque
outil.
La Direction de l’équipe Data Factory d’Intelcia ITSolutions ”a ainsi confié comme mission de
concevoir et de mettre en place un système décisionnel pour le suivi, le « Reporting » et les
analyses nécessaires afin de trouver des solutions à des problèmes de prise de décision. Mon
projet consiste tout d’abord à recueillir le besoin de mon client, analyser le métier et élaborer
les indicateurs de performance pour ainsi concevoir le Datamart correspondant à mon secteur
fonctionnel et enfin mettre en place des tableaux de bord de restitution de l’activité concernée.
Le présent rapport, dédié à la présentation de mon projet de fin d’études, s’articule sur quatre
chapitres :
Le premier chapitre aborde le cadre général du projet. Il décrit l’organisme d’accueil Intelcia
IT Solutions, puis présente le contexte général du projet, en mettant l’accent sur la
problématique et les objectifs du projet. Il présente aussi la méthodologie adoptée pour mener
ce projet en exposant le planning et les livrables adoptés et attendus dans mon projet.
Le deuxième chapitre détaille la phase d’analyse et de spécification, on y présente d’abord une
analyse de l’existant, ainsi qu’une critique pour situer les limites de ce dernier, suivie d’un
recueil des besoins en termes des fonctionnalités souhaitées. Il aborde par la suite le cadrage
fonctionnel pour présenter les indicateurs et les axes d’analyses recensés.
Le troisième chapitre est consacré à l’étude fonctionnelle et technique du projet en présentant
les différentes solutions techniques et le choix de l’environnement du travail ainsi que les outils
utilisés.
Le quatrième chapitre est consacré à la mise en œuvre de la solution décisionnelle. Je décrirai
les techniques et outils de développement adoptés, et j’illustrerai certaines fonctionnalités
assurées à travers quelques interfaces.
Pour clore ce mémoire, je synthétise les résultats et les acquis de mon projet de fin d’études
tout en proposant des perspectives à ce travail.

P a g e 12 | 72
CHAPITRE 1
CONTEXTE GENERAL
Ce chapitre est consacré au contexte général du
projet en présentant en premier lieu l’organisme
Intelcia, son métier et son organisation. La
deuxième section est dédiée à la description du
projet, sa problématique et ses objectifs ainsi que
la présentation de l’approche adoptée pour la
conduite du projet.

P a g e 13 | 72
1. PRESENTATION DE L’ORGANISME
1.1Groupe Intelcia

Intelcia est un groupe marocain devenu acteur majeur des métiers de l’externalisation et
faisant partie aujourd’hui du top 7 des outsourceurs francophones dans la relation client. Crée
en 2000, le Groupe a rapidement étendu sa présence géographique et ses activités pour
accompagner ses clients sur l’ensemble de leurs opérations d’externalisation et leur permettre
de mieux se concentrer sur leurs enjeux et cœur de métier.
Son savoir-faire repose sur sa capacité à conjuguer talents, technologies et processus pour
offrir un service sur-mesure et des compétences aux standards internationaux.
Intelcia assure un partenariat privilégié avec plusieurs clients prestigieux dans divers
domaines, tels que Google, Darty et SFR. Pour garantir la qualité de ses services auprès de ses
clients, le groupe Intelcia s’est engagé dans une démarche d’amélioration continue. Une
direction indépendante de la production a spécialement été créée pour contrôler la qualité et
veiller au respect du cahier des charges des clients.
Forte de ses 40 000 collaborateurs et avec une présence sur 85 sites au 17 pays

A travers ses services, Intelcia permet à ses clients de rester focalisés sur leurs enjeux et
cœur de métier.Le groupe Intelcia propose ainsi une offre globale et multisectorielle
autour de 4 pôles de solutions :

FIGURE 1 : Solutions du groupe Intelcia

P a g e 14 | 72
 1.1.1Histoire du Groupe

FIGURE 2 : Histoire du groupe Intelcia

Crée en 2000, Intelcia a connu un développement et une croissance continus grâce à un

ensemble d’acquisitions et d’ouvertures stratégiques au niveau national et international
Depuis 2016, Intelcia compte Altice parmi ses actionnaires, sur lequel il s’appuie pour
accélérer son développement à l’international.
En 2020, Intelcia poursuit son expansion internationale avec une implantation en Amérique
dans les caraïbes et de nouvelles destinations en Europe.
Au-delà des expertises, la pérennité d’une entreprise vient de ses valeurs. En 20 ans de vie,
Intelcia a toujours véhiculé des valeurs simples mais fortes :
- Optimise et Ambition : Sa vision optimiste est résolument tournée vers l’avenir.
C’est ce qui aide Intelcia à penser puis à façonner un lendemain meilleur. Intelcia croie
en capacités de ses collaborateurs. Voilà pourquoi ils n’hésitent pas à défier les
conventions et à abattre toutes les barrières psychologiques pour réaliser leurs ambitions.
- Transparence et respect : Sa culture d’entreprise est basée sur le partage.
Générosité et cohésion sont ses leitmotivs. A Intelcia, ils respectent la différence. C’est
ainsi qu’ils créent des relations riches et durables qui mènent inévitablement vers un
succès collectif. Ils veillent également au bien-être de ses collaborateurs de ses clients et
de ses partenaires.
- Exellence et agilité : Ils ont une responsabilité de résultat. Ils prônent donc la prise
d’initiative et la créativité dans l’exécution de leurs missions. Ils se surpassent au
quotidien pour trouver des solutions à tous les obstacles. C’est ce qui leur permet de
répondre avec agilité aux exigences et aux besoins de leurs clients.

P a g e 15 | 72
 1.1.2 Intelcia IT Solutions

Intelcia IT Solutions est un acteur majeur de l’infogérance et de la digitalisation. Avec

une forte ambition de croissance et d’expansion, Intelcia IT Solutions est née au Maroc
et a élargi ses horizons à l’international.

Les ingénieurs d’IITS sont au service des multinationales, des entreprises locales et du
secteur public du monde entier depuis le Maroc, la France, la Côte d’Ivoire et le
Cameroun.

Et leur expertise s’étend de la digitalisation des processus métiers aux services managés
multi-technologies :
Réseau, Cloud, Sécurité, Téléphonie IP, Business Intelligence.

Intelcia IT Solutions offre à ses clients des solutions adéquates et à forte valeur ajoutée
pour digitaliser leurs processus métiers. Ses solutions éprouvées ont été adoptées par
plus de 800 entreprises en 2021 et fluidifient les interactions au sein de ces
organisations.

Intelcia IT Solutions est le pôle d’expertise IT du groupe Intelcia avec 4 piliers de services :
- Services managés
- Solutions Applicatives
- Business Intelligence
- Consulting

1.1.3 Organigramme d’Intelcia IT Solutions

Intelcia IT Solutions s’organise sur plusieurs directions, chacune de ces directions est
supervisée par un directeur qui prend en charge les équipes de projets. L’ensemble de
ces directions sont sous l’intention d’un directeur général. L’organigramme suivant
(Figure 1.3) illustre cette hiérarchie.

P a g e 16 | 72
 FIGURE 3 : Organigramme d’Intelcia IT Solution

Mon stage est effectué dans la direction BI, plus précisément au sein de l’équipe Data Factory
sous la direction d’un chef de projet BI qui supervise le déroulement du projet et répartit les
tâches entre les membres de l’équipe.

1.1.4 Présentation de SFR

La Société Française du Radiotéléphone, SFR est un opérateur de télécommunications
français qui propose une gamme complète de services de téléphonie fixe, mobile et
Internet. Fondée en 1987, SFR est aujourd’hui l’un des principaux acteurs du marché
français des télécommunications.

SFR propose une large gamme de services de télécommunications pour répondre aux besoins
des particuliers et des entreprises. Ces services comprennent :
Téléphonie mobile : SFR propose des forfaits mobiles pour tous les budgets, avec des options
de voix et de données personnalisables.
Téléphonie fixe : SFR propose des services de téléphonie fixe avec des options d’appels
illimités vers les numéros fixes et mobiles en France et à l’étranger.
Internet haut débit : SFR propose des solutions d’accès Internet haut débit pour les particuliers
et les entreprises, avec des vitesses allant jusqu’à 1 Gbit/s.
Télévision : SFR propose des services de télévision avec des chaînes en direct, des services de
vidéo à la demande et des enregistrements.
Cloud : SFR propose des solutions de stockage de données en ligne pour les particuliers et les
entreprises, avec des options de sauvegarde et de partage de fichiers.

P a g e 17 | 72
La stratégie de SFR repose sur plusieurs axes clés, notamment l’innovation technologique, la
qualité de service, la satisfaction client et le développement de nouveaux services. L’entreprise
investit régulièrement dans la recherche et le développement pour offrir des services de pointe
à ses clients.
SFR s’efforce également de fournir une qualité de service exceptionnelle à ses clients, avec
des offres personnalisées, un service client de qualité et une disponibilité élevée de ses
services. La satisfaction client est au cœur de la stratégie de SFR, avec une attention
particulière portée aux commentaires et aux retours des client.

FIGURE: Schéma du processus de production

Parmi les offres de SFR, il y’a PBC (Pack Business Corporate) qui est dédiée aux entreprises
qui cherchent à répondre à leurs besoins en matière de télécommunications. Cette offre
comprend une gamme complète de services tels que la téléphonie Fixe VoIP et plusieurs outils
de communication unifiés tel que le chat, la mobilité , la gestion des standard téléphonique , le
serveur vocal interactif, fax sur le cloud et teams.Cette offre permet aussi d’intégrer simplement
la téléphonie fixe Cisco à l’environnement Microsoft Teams.
Pour offrir un service complet et de qualité à leurs clients, SFR s’appuie sur des prestataires
comme Intelcia IT Solutions. Cette équipe de prestataires est chargée de la phase d’exploitation
et de déploie- ment pour les clients de SFR. Ils travaillent avec trois outils de ticketing : Service
Now, Clarify et Reflex, pour traiter les différents incidents et changements des clients de SFR
qui utilisent l’offre PBC.

P a g e 18 | 72
1.2. Contexte du Projet
1.2.1 Problématique du projet

Avant qu’Intelcia IT Solutions entame ce projet de refonte, le système existant ne permettait

pas de réaliser des tableaux de bord et la génération de rapports synthétisés et interactifs, il ne
permettait pas également d’historier les données, du coup on perdait l’ancienne information qui
a eu un changement. Aussi il ne permettait pas l’automatisation des processus d’extraction, de
transformation et de chargement des données (ETL). Les data analystes étaient donc
principalement engagés dans des tâches manuelles, rendant la production de rapports et
d’analyses laborieuse et chronophage.
C’est dans ce cadre qu’Intelcia IT Solutions m’a confié la mission de conception et de
réalisation d’un système décisionnel adoptant une approche Business Intelligence, permettant
de suivre, gérer, contrôler et prévoir le nombre de tickets traités ainsi que la durée de résolution
tout en intégrant des ETL et des tableaux de bord automatisés.

1.2.2. Objectifs du projet

Intelcia IT Solutions a décidé de mettre en place un système décisionnel pour le suivi , contrôler
et prévoir le nombre de tickets traités. Ce système doit extraire automatiquement les données
des systèmes sources afin de les combiner, transformer, consolider et historier, ainsi qu’a créer
des tableaux de bord synthétiques et interactifs avec les indicateurs de performance pour réaliser
les objectifs suivants :

• Suivi de l’évolution des clients de SFR

• Suivi de l’évolution des tickets traités et résolus dans chaque outil
• Suivi de la productivité de chacun d’équipe des prestataires

1.2.3. Les Missions

• Planification du projet : La phase de planification du projet aborde la définition et

l’étendue du projet et permet de définir les affectations des taches, leur durée et leur
séquencement.
• Définition des besoins : La phase de définition des besoins consiste à bien étudier et
analyser le système existant et analyser également les objectifs d’Intelcia IT Solution
pour en déduire les spécifications fonctionnelles.
• Modélisation dimensionnelle des données : Consiste à développer un modèle
dimensionnel qui permettra d'identifier les tables des faits, les dimensions associées, les
attributs ainsi que leur hiérarchisation.

P a g e 19 | 72
 • Conception du modèle physique de données : La conception physique d'une base de
données définit les structures physiques nécessaires pour l'implémentation de la base de
données logique.
• Conception et développement de la zone de préparation des données : Le processus de
préparation des éléments de la zone de préparation des données passe par trois étapes
principales : l'extraction, la transformation et le chargement des données.
• Définition de l'architecture technique : la définition de l’architecture technique sert à
donner une vision globale de la structure de l'architecture technique à mettre en œuvre
car les environnements de datawarehouse nécessitent l'intégration de nombreuses
technologies.
• Choix technologiques et mise en œuvre : Cette phase consiste à choisir les outils et les
technologies pour la mise en place de la solution décisionnelle.
• Développement de l'application utilisateur : Pour garantir que l'équipe de
développement et les utilisateurs ont intégré une compréhension commune des
applications qui vont être livrées.
• Déploiement : Le déploiement est le point de convergence de la technologie, des
données et des applications utilisateur accessibles à partir du poste de travail.
• Maintenance et croissance : Cette phase vient après la phase de déploiement initial de
l'entrepôt de données et nécessite un service de support et une formation continue pour
les utilisateurs.

1.3. Démarche du projet

1.3.1. Les Livrables
Phase Livrable

Etude préalable Cahier des charges

Plan qualité du projet

Préparation et planification Dossier des spécifications fonctionnelles et

technique
Sprint 1 Conception des flux ETL

Sprint 2 Création des tables de Staging

Sprint 3 Développement des ETL

P a g e 20 | 72
 Sprint 4 Création des tables ODS

Sprint 5 Réalisation des Tableaux de bord.

Tests unitaires Réaliser des tests unitaires

Déploiement de la solution La solution fonctionne bien

Tableau 1: tableau des livrables

1.3.2. ÉTUDE DE RISQUE

Par définition, un risque est un danger possible plus ou moins prévisible qui peut affecter En
fin de projet, la gestion des risques est essentielle pour réagir aux incidents Des événements
qui déstabilisent le projet. Il faut se poser la question néfaste Les problèmes qui peuvent
survenir au cours de cette tâche et les solutions qui peuvent être apportées. À toutes les étapes
de ce projet, nous sommes confrontés à plusieurs risques Cela peut nous empêcher d'atteindre
nos objectifs. On peut les reconnaitre Et les réduire par des mesures correctives et
préventives.

Réf Description Impact Type de risque Probabilité Niveau Actions

du risque d’impact préventives

Le cahier de Impact sur la Fonctionnel Moyen Elevé Elaboration d’un

charge est compréhension questionnaire
R01 non du besoin. Recueillir de la
complet. documentation
R02 La Le produit ne Fonctionnel Faible Moyen Le
conception couvre pas développement
est tous les volets incrémental et
insuffisante du besoin l’implication du
client.

La réalisation
Les outils Impossibilité d’une étude
exigés ne d’achever le technique
R03 peuvent pas projet. Technique Faible Faible La réalisation
répondre au d’une
besoin. démonstration
avec des
échantillons des
fichiers sources
Le Un planning
R04 Le suivi est dépassement Organisationnel détaillé
insuffisant des délais et Faible Moyen Des réunions de
sur les coûts suivi
hebdomadaires

P a g e 21 | 72
R05 Planning Le Définir des
non dépassement moyens de
conforme à des délais et Organisationnel Moyen Elevé réduire les phases
la réalité sur les coûts pour être
conforme à la
durée globale
Tableau 1: tableau d’études de risque

1.3.3. Définition de la méthode Agile

Agile est une approche itérative et collaborative, capable de prendre en compte les besoins
initiaux du client et ceux liés aux évolutions. Elle se base sur un cycle de développement qui
porte le client au centre. Le client est impliqué dans la réalisation du début à la fin du projet.
Grâce à la méthode agile, le demandeur obtient une meilleure visibilité de la gestion des travaux
qu’avec une méthode classique. Cette méthode vise à accélérer le développement d’un logiciel.
De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la durée de sa
création. Le principe de base consiste à proposer une version minimale du logiciel puis à
intégrer des fonctionnalités supplémentaires à cette base, par processus itératif.

1.3.4. Définition du Framework Scrum

La méthode Scrum fait partie des méthodes de gestion de projet agiles, utilisée dans le domaine
du développement informatique. Dans le cadre de la méthode Scrum, le produit logiciel est
développé ou évolue sous forme de sprints qui sont des phases de développement de quelques
semaines qui se contentent généralement sur quelques fonctionnalités, voire parfois sur une
fonctionnalité unique. Les fonctionnalités à développer lors des sprints sont notamment
répertoriées et priorisées dans le cadre d'un Backlog produit.
Au niveau organisationnel, le développement n'est pas forcément géré par un chef de projet,
mais plutôt coordonné par un "Scrum master" qui joue un rôle d'intermédiaire entre l'équipe de
développement et le responsable produit (Product Owner).
1.3.5. Pourquoi le Framework Scrum ?

Le Framework Scrum offre les avantages suivants :

❖ Compréhension des tâches à accomplir : Appliquer Scrum, permet de subdiviser le

projet en plusieurs petites parties réalisables et permet d’examiner d’un œil critique leur
exécution. On peut ainsi optimiser en continu les étapes qui mènent à l’objectif final.
❖ Transparence : Scrum exige de la transparence. Les membres de l’équipe doivent savoir
ce que les autres accomplissent et le résultat qu’ils peuvent en attendre. Il n’y a pas de
véritable « patron » avec Scrum ; c’est une équipe autopilotée qui collabore en restant
autonome.
❖ Deadlines intégrés : Comme le projet est subdivisé et que des tâches très spécifiques
peuvent être attribuées aux membres de l’équipe, on intègre chaque jour des échéances
pour évaluer les avancées des uns et des autres. Cela implique que tout le monde prenne
ses responsabilités
❖ Focus et flexibilité : Scrum a été conçu non seulement pour améliorer les projets, mais
aussi pour en accélérer la réalisation. Il importe donc de prévoir une marge de manœuvre
pour l’imprévu, mais aussi, Un Scrum Master doit donc surveiller et accompagner le
processus.

1.3.6. Comparatif des Framework d’agilité

P a g e 22 | 72
 Extreme
Critères Scrum Kanban Scrumban programming
(XP)
Au début de Kanban board, Kanban
Planification Chaque sprint Flux bobard Planning gamme
Continues Avec
itérations
Estimation de Au début de Optionnel, Idem Pratiques XP
L’effort Chaque sprint Prédictibilité Kanban
Scrum master
(SM)
Rôles product owner Team Team Team + client
(PO)
Développeur(Dv)
Product backlog, Kanban board, Priorisation par
Boards/Artifacts Scrumboard, Diagramme des Idem le client,
burn flux cumules Kanban pratiques XP
down / burnup
MCO, TMA, MCO, TMA, Amélioration de
équipe travaillant équipe la qualité du
Quand choisir ? Équipe dédiée à sur plusieurs expérimentée logiciel critique,
100% au projet projets en agilité prise en compte
simultanément immédiat des
Changements
1. Méthode Kanban board, 1. Qualité code,
Caractéristiques leader, Pilotage visuel, Adaptabilité, 2. The
et principales 2.Sprints, Indicateurs / cycle Transition, craftmanship,
3. BurnUP time. 2. Outillage.
/vélocité.
Mise en place - Avantages - Qualité du code
Productivité, rapidesans de Scrum + plus importante, -
Scalabilité, changement des Kanban, Réactivité,
Top-bénéfice Engagement des processus adapté à des - Niveau
équipes. existants, portefeuilles d'expertise des
Pilotage visuel projets équipes.
CFD mixtes
Gestion des files cycle en V et
d'attente Flux. agile.
Tableau 1: tableau comparatif des Frameworks d'agilité

Parmi les principaux Framework qui implémentent la méthode agile on distingue : Scrum,
Kanban ; Scrumban et Extrême programming (XP). Voici une comparaison résumée de leurs
principales caractéristiques

1.3.7. Cycle vie de vie Framework Scrum

❖ On a choisi de présenter la figure ci-dessous reprenant de façon visuelle les
différents éléments du cyclede vie de la méthode Scrum :

P a g e 23 | 72
 Figure 4 : Un schéma du processus Scrum

1.3.8. Description des phases

1.3.8.1 Phase1 : Initialisation
DESCRIPTION
Objectifs Comprendre la problématique du projet, son scope et sa faisabilité
Définir la durée estimative, son budget et ses risques

Contrainte Définir l'opportunité du projet

Évaluer la faisabilité
Prérequis N/A
Livrables en sortie Charte du projet
Dépendance N/A
Critères de fin de Générer la fiche du projet
phase
Tableau 2 : description de la phase initialisation

1.3.8.2 Phase2 : Préparation et planification

DESCRIPTION
Objectifs identifiés les membres de l'équipe, discuter l’environnement et
demande
initiaux.
Contrainte Travailler activement avec les parties prenantes
Commencer à construire l'équipe
réaliser une architecture initiale pour le système
Prérequis Avoir la fiche de projet
Livrables en sortie Cahier des charges
Plan Qualité Projet
Dossier de spécifications fonctionnelles
Dossier de specification technique
Dépendance N/A
Critères de fin de Vérification et validation des livrables attendues par l’encadrent
phase
Tableau 3 : Description de la phase préparation et planification

P a g e 24 | 72
 1.3.8.3. Phase3 : Production

DESCRIPTION
Objectifs Fournir progressivement des modules applicatifs de haute qualité
qui répondent aux besoins changeants des parties prenantes
Contrainte Collaborer étroitement avec les parties prenantes et avec les
développeurs
Implémentation des fonctionnalités par ordre de priorité
Fournir périodiquement des solutions fonctionnelles
Effectuer des tests

Prérequis Avoir le cahier des charges, Plan Qualité Projet et les dossiers de
spécifications fonctionnelles et de spécification technique
Livrables en sortie Rapports d’avancement
Dépendance N/A
Critères de fin de Développement de tous les modules applicatifs
phase
Tableau 4:description de la phase production

1.3.8.4. Phase4 : Finalisation

DESCRIPTION
Objectifs Mettre la solution en production.
Contrainte Test final du système
Finalisation de la documentation utilisateur
Former les utilisateurs finaux
Déployez le système
Prérequis La solution déjà développée
Livrables en sortie Documentation utilisateur
Dépendance N/A
Critères de fin de Validation de la recette par PO Vérification et validation des
phase livrables attendues par l’encadrent
Tableau5:Description de la phase finalisation

1.3.9. Planning du projet

1.3.9.1. Planning Estimatif
Le projet est planifié en respectant les phases principales du Framework Scrum
et en suivant un calendrier prévisionnel détaillé dont voici la description :

P a g e 25 | 72
 Figure5: Planning estimatif du projet

1.3.9.2 Planning réel

Cette figure présente le planning réel du projet, grâce à cette étape déterminante, on obtient
une vue d’ensemble correcte de la durée globale du projet.

Figure 6: Planning réel du projet

P a g e 26 | 72
 1.3.9.3 Analyse des écarts
Le planning réel a connu quelques changements par rapport au planning estimatif.
Nous signalons les écarts suivants :
▪ Sprint 4 : Création des tables ODS, nous avons prévu 3 jours alors que nous avions
besoin de 5 jours.
▪ Sprint 6 : Réalisations des tableaux de bords, nous avons prévu 15 jours alors que nous
avions besoin de 13 jours.

1.3.10. Organisations du p r o j e t
1.3.10.1 Équipe CORE
L’un des principes au cœur de la méthodologie Scrum c’est l’idée d’itération et
d’amélioration. Cela concerne non seulement le produit en cours de
développement, mais aussi l’efficience de l’équipe elle- même. Voici donc la
description de l’équipe Core du projet.
Nom Fonction / rôle pour le project Mail

Salma Raiss Réalisatrice Raiss.selma@gmail.com

Reda Mouaouia President ______

Mohammed Product Owner ______

Tableau 6: équipe core du projet

Rôles des acteurs du projet :

➢ Salma Raiss a les rôles suivants :
• Recueil du besoin
• Analyse du besoin
• Préparation environnement
➢ Reda Mouaouia a les rôles suivants :
• Exprimer clairement les éléments du backlog produit.
• Ordonnancer les éléments du backlog produit pour mieux réaliser les objectifs et les
missions
• Assurer que le Backlog produit est visible, transparent et clair pour tous.
• Définir les critères d’acceptation et s’assurer que ces critères sont respectés.

1.3.10.2. Instances de suivi de projet

Le projet est suivi et encadré par deux encadrants universitaires au niveau méthodique, ainsi
qu’au niveau technique : M. Mohamed-Amine HAMMA et M. Hassane ABBOU.
➢ L’encadrement est mis en place à travers des réunions périodiques dans lesquelles on
discute :
• L’avancement du projet.
• Le respect des méthodes de travail.
• Les obstacles rencontrés et les solutions proposées.
• Vérification et validation des documents et livrables attendus.

P a g e 27 | 72
Conclusion
Dans ce chapitre j’ai présenté une description globale sur mon projet de fin
d’études : tout d’abord j’ai présenté l’organisme d’accueil avant de détailler le
périmètre du projet, et enfin j’ai décrit la démarche adoptée dans la réalisation du
projet.
Cette description est une phase essentielle qui précède l’étude des besoins du projet
qui sera détaillé dans le chapitre suivant.

P a g e 28 | 72
CHAPITRE 2
ETUDE DES BESOINS
Ce chapitre présente l’analyse et la spécification des
besoins nécessaires au démarrage du projet. J’y
présente d’abord une analyse de l’existant, ainsi
qu’une critique pour situer les limites de ce dernier.
Je passe après au recueil des besoins en termes des
fonctionnalités souhaitées par les managers vis à vis
la ligne à grande vitesse. Ensuite on entame un
cadrage fonctionnel pour présenter les indicateurs et
les axes d’analyses, avant de terminer avec un
cadrage technique du projet.

P a g e 29 | 72
2. Rappel de la problématique du projet

Avant qu’Intelcia IT Solutions entame ce projet de refonte, le système existant ne permettait

pas de réaliser des tableaux de bord et la génération de rapports synthétisés et interactifs, il ne
permettait pas également d’historier les données, du coup on perdait l’ancienne information qui
a eu un changement. Aussi il ne permettait pas l’automatisation des processus d’extraction, de
transformation et de chargement des données (ETL). Les data analystes étaient donc
principalement engagés dans des tâches manuelles, rendant la production de rapports et
d’analyses laborieuse et chronophage.
C’est dans ce cadre qu’Intelcia IT Solutions m’a confié la mission de conception et de
réalisation d’un système décisionnel adoptant une approche Business Intelligence, permettant
de suivre, gérer, contrôler et prévoir le nombre de tickets traités ainsi que la durée de résolution
tout en intégrant des ETL et des tableaux de bord automatisés.

2.1 Rappel du But Projet

Intelcia IT Solutions a décidé de mettre en place un système décisionnel pour le suivi, contrôler
et prévoir le nombre de tickets traités. Ce système doit extraire automatiquement les données
des systèmes sources afin de les combiner, transformer, consolider et historier, ainsi qu’à créer
des tableaux de bord synthétiques et interactifs avec les indicateurs de performance pour réaliser
les objectifs suivants :

• Suivi de l’évolution des clients de SFR

• Suivi de l’évolution des tickets traités et résolus dans chaque outil
• Suivi de la productivité de chacun d’équipe des prestataires
.

2.2 Étude de l’existant

2.2.1Analyse de l’existant

L’analyse de l’existant, est une étape essentielle avant la conception et réalisation d’un projet
décisionnel, qui va nous permettre de bien assimiler les objectifs du système à mettre en place.
Il s’agit donc dans cette étape d’étudier le processus existant, identifier les problèmes afin de
proposer des pistes d’amélioration.

2.2.2 Analyse de l’ancienne solution

La solution existante utilisée par l’équipe Data Factory, impliquait la génération régulière de
tableaux de bord à partir d’extractions Excel reçues chaque semaine de la part des prestataires
du client SFR pour son offre PBC. Cette approche avait été adoptée pour répondre aux besoins
d’analyse des données et de présentation des indicateurs clés à SFR.

P a g e 30 | 72
2.2.3 Critique de l’existant

Apres avoir recense et analyse les différents rapports élabores de l’ancien system décisionnel
et son architecture, j’ai pu dégager les critiques suivantes :
- Un cout élevé en termes de temps et de ressources : La solution adoptée consomme beaucoup
de temps et parfois tombe en panne, ce qui nuit à la performance et cause des pertes de
l’information.
- Absence de l’historisation : L’ancienne solution ne couvre pas l’historisation des données,
cela ne permet pas de collecter les changements à travers l’axe du temps.
- Une structure qui ne respecte pas les bonnes pratiques : Absence de la base de données
Staging: Un staging area, c’est où nous transférons les données à partir des systèmes sources
avec des transformations minimales, l’avantage d’utiliser ce staging temporaire est de ne pas
faire de transformation en même temps que les extractions. Ce qui a moins d’impact sur les
systèmes sources.
Tous ces problèmes causent des difficultés de maintenance et de mise à jour du système. Notons
aussi que le système n’est pas tout à fait fiable, ce qui engendre des taches supplémentaires chez
les utilisateurs qui doivent revérifier manuellement que les données saisies correspondent à la
réalité. Donc ma mission est de corriger ces problèmes en proposant une solution décisionnelle
adéquate que je détaillerai dans ce qui suit.

2.3 Recueil des besoins

2.3.1. Besoins Fonctionnels

Pour accompagner le lancement de son offre à grande vitesse, SFR souhaite mettre en œuvre
un système d’informations pour la gestion de son activité PBC adapté aux exigences de la
grande vitesse, et couvrant également l’ensemble du périmètre du projet. Pour cela, la refonte
du système existant correspond à un nombre d’objectifs fonctionnels qui s’inscrivent
principalement dans le suivi des tickets à savoir des incidents et des changements. Parmi ces
objectifs fonctionnels, on trouve :
L’amélioration de la visibilité et la génération des rapports et tableaux de bord :
Le nouveau système étant mis en place, les tableaux de bord préexistants seront remplacés en
ajoutant d’autres rapports et d’autres tableaux de bords.
Suivi de l’évolution des tickets traités et résolus dans chaque outil.
Suivi de l’évolution des clients de SFR qui ont opté pour utiliser l’offre PBC au fil de temps
Suivi de la productivité de chaque prestataire du client SFR :
• Le nouveau système permet de suivre les tickets affectés à chaque prestataire et leurs états.
• Il permet de suivre les statistiques de charge de l’équipe des prestataires qui s’occupent du
traite- ment des tickets d’incidents et de changements.

2.3.2. Besoins non Fonctionnels

• Facilité : Le nouveau système fournira un meilleur accès à l’information, et une analyse à tout
moment.
• Performance : Le nouveau système nous permet un Gain de temps et une analyse plus juste
et plus puissante.

P a g e 31 | 72
• Fiabilité : le processus ETL permet d’Empêcher les erreurs de saisie. Elle consiste à garantir
que les informations contenues dans les bases de données soient correctes et facilement
exploitables (bon format, pas de doublons, etc.).
• Sécurité
• Journalisation
• Les droits d’accès

2.4. Cadrage fonctionnel

Dans cette partie, on va présenter les indicateurs et les axes d’analyse que nous avons tiré après
une analyse approfondie des besoins spécifiques au suivi des tickets de changements et
d’incidents.

2.4.1. Présentation des outils de ticketing

Un outil de ticketing, également appelé système de gestion des incidents, est un logiciel utilisé
par les entreprises pour suivre, gérer et résoudre les problèmes, les incidents et les demandes
de service. Ces outils fournissent une plateforme centralisée pour enregistrer, suivre et résoudre
les tickets, ce qui permet aux équipes de support et aux services informatiques de gérer
efficacement les demandes des utilisateurs.
Un ticket est un enregistrement dans un système de ticketing qui représente une demande, un
incident ou un problème soumis par un utilisateur ou identifié par une équipe de support. Les
tickets contiennent des informations telles que la description du problème, la priorité, la
catégorie, les informations de contact, et d’autres détails pertinents.
Un ticket d’incident est généralement utilisé pour signaler des problèmes ou des incidents qui
affectent le fonctionnement normal d’un service ou d’un système. Par exemple, un utilisateur
peut signaler un problème d’accès à un logiciel, une panne de matériel, ou une erreur système.
Un ticket de changement, quant à lui, est utilisé pour demander, planifier et suivre des
modifications apportées à un système ou à une infrastructure. Les demandes de changement
peuvent inclure des demandes d’ajout, de modification ou de suppression de fonctionnalités, de
configurations ou d’infrastructures informatiques.
Dans notre cas, l’équipe des prestataires du client SFR utilisent trois outils . Pour la phase
d’exploitation on a deux outils de ticketing :
Servicenow :

Servicenow est une plateforme de gestion de services IT qui propose un outil de ticketing pour
suivre les demandes et les changements des clients.
L’outil de ticketing Servicenow permet aux clients PBC de soumettre des demandes de service
des changes via un formulaire. Chaque demande reçue est enregistrée comme un ticket qui est
ensuite attribué à un ingénieur de support pour le résoudre.

P a g e 32 | 72
 Clarify :

FIGURE7: Outil Servicenow

L’outil de ticketing Clarify permet aux clients de soumettre des demandes de service, des
incidents ou des problèmes via un formulaire en ligne . Chaque demande reçue est enregistrée
comme un ticket qui est ensuite attribué à un technicien de support pour le résoudre.

FIGURE 8: Outil Clarify

Pour la phase de déploiment :

On a l’outil du Client SFR :
Reflex

P a g e 33 | 72
Un outil de création de workflow déploiement, il permet :
•La Hiérarchisation des tâches (créée automatiquement au fur et à mesure de l’avancement,
dépendances des taches)
•L’Affectation automatique
•Le Conditionnement de la clôture de certaines phases
•L’historisation des actions (ouverture, modification, clôture, commentaire, fichiers)
•Les Statistiques de charge de l’équipe
•Notification par mail automatiques
•Conservation d’une souplesse (création de ticket hors-workflow défini)

FIGURE 9: Outil Refle

FIGURE 10 : OWorkflow

P a g e 34 | 72
 2.4.2. Description des indicateurs
Les indicateurs sont les éléments calculables par des formules ou bien des agrégations qui
permettent de mesurer l’activité et d’avoir une vision complète sur le suivi des tickets dans les
différents outils que je viens de présenter. Les principaux indicateurs sont présentés par les
tableaux suivants :

Nom Total ticket traité

Description C’est le nombre total des tickets qui sont traités
Règle de calcul If ([Statut du cas]== Fermé || [Statut du cas]==Résolu)
Origine des données Extraction du Clarify
TABLE7: Indicateur "Total ticket traité"

Nom Worflow deployé

Description C’est le nombre des workflow qui ont le type de demande égal à
prequalification.
Règle de calcul If ([Type de demande] =="Pre-Qualification")
Origine des données Extraction du Reflex
TABLE 8 : Indicateur "Worflow deployé"

Nom Change traité par attribution

Description C’est le nombre des tickets de changement filtré par l’attribution
Règle de calcul If ([State]=="Closed Complete" || [State]=="Closed Incomplete")
Origine des données Extraction du Servicenow
TABLE 9 : Indicateur "Change traité par attribution"

Nom Total ticket résolu

Description C’est le nombre des tickets qui sont résolus
Règle de calcul If ([État]="Fermé" || [État]="Traité")
Origine des données Extraction du Reflex
TABLE 10 : Indicateur "Total ticket résolu"

Nom Délai de resolution

Description C’est le délai de résolution du ticket en heures
Règle de calcul Durée en heures = hh + (mm / 60) + (ss / 3600)
Origine des données Extraction du Servicenow
TABLE 11 : Indicateur "Délai de résolution"

Nom Total incident

Description C’est le nombre total des incidents
Règle de calcul [Nombre incdient]
Origine des données Extraction du Clarify
TABLE 12 : Indicateur "Total incident"

P a g e 35 | 72
Nom Total site migré
Description C’est le nombre total des sites migrés
Règle de calcul If([Type de demande] =="Mise en production &([État]=="Traité" ||
[État]=="Fermé")
Origine des données Extraction du Reflex
TABLE 13 : Indicateur "Total site migré"

2.4.3. Description des axes d’analyse

Une dimension est une table qui contient les axes d’analyse selon lesquels on veut étudier les
indicateurs pour donner aux utilisateurs des renseignements nécessaires à la prise de décision.
Les axes d’analyse spécifiques au suivi des tickets qui décrivent les indicateurs cités auparavant
sont exprimés dans les tableaux suivants :
Pour le volet Incident à savoir les extractions d’outil Clarify on a :

Axe Description
Propriétaires Liste tous les utilisateurs responsables du traitement des tickets
Statut Liste les différents états des tickets
Sévérité Regroupe les différents degrés d’importance ou d’impact d’un cas d’incident.
Date Regroupe les dates
TABLE 14 : Description des axes d’analyse pour le cas des tickets des incidents

• Pour le volet Change à savoir les extractions d’outil Servicenow on a :

Axe Description
Attribution Liste tous les utilisateurs responsables du traitement des tickets
Etat d’urgence Regroupe les différents étas des tickets de changement .
Type de traitement Regroupe les différents types de traitement des tickets de changement
Etat Regroupe les différents états des tickets de changement.
Date Regroupe les dates

TABLE 15 : Description des axes d’analyse pour le cas des tickets des changements

• Pour le volet Build à savoir les extractions d’outil Reflex on a :

Axe Description
Client Liste les clients du SFR
Attribution Regroupe tous les prestataires à qui les tickets sont attribués
Etat Regroupe les différents états des tickets
Type de demande Liste les différents types de demandes reçues.
Date Regroupe les dates
TABLE 16 : Description des axes d’analyse pour le cas des tickets du build d’outil Reflex

P a g e 36 | 72
2.5. Cadrage technique
2.5.1. Architecture générale d’un système décisionnel
Tout système décisionnel est présenté globalement en trois catégories correspondantes chacune
à une fonction spécifique :
La phase d’extraction et de transformation des données :
Avant d’être utilisables, les données seront formatées, nettoyées et consolidées. Les outils
d’ETL permettent d’automatiser ces traitements et de gérer les flux de données alimentant les
bases de stockage : datawarehouse ou datamart.
La phase de chargement et stockage des données :
Les données, au préalable nettoyées et consolidées, seront stockées dans une base spécialisée :
le datawarehouse ou le datamart. Le datamart est une version plus réduite du Datawarehouse,
il est orienté sujet et peut être par exemple utilisé pour des différentes applications.
La phase de restitution et d’analyse :
Une fois les données stockées, nettoyées, consolidées et accessibles, elles sont utilisables. Selon
les besoins, différents types d’outils d’extraction et d’exploitation seront envisagés. Analyser
les données, notamment avec les outils de type OLAP pour les analyses multidimensionnelles.
Rechercher des corrélations peu visibles avec le Datamining.

Piloter la performance, aide à la décision des décideurs en situation avec les tableaux de bord
présentant les indicateurs clés de l’activité.
Communiquer la performance avec le Reporting.

2.5.2. Architecture matérielle

2. 5.2.1. Présentation de Microsoft SQL Server

Microsoft SQL Server est un produit de Microsoft servant de système de gestion de bases de
don- nées. De plus, SQL Server fournit une solution intégrée d’analyse et de gestion de bases
de données, chose qui rend les données de l’entreprise facilement gérables et le développement
plus fluide. Cette intégrité de SQL Server fait qu’elle réduit la complexité en temps et en
développement de la création, le déploiement et la gestion des données de l’entreprise qui
proviennent de plusieurs sources hétérogènes.

P a g e 37 | 72
 2.5.2.2. Présentation de Microsoft SQL Server Intégration Services (SSIS)

Microsoft SQL Server Intégration Services (SSIS) est une plateforme conçue pour élaborer des
solutions d’intégration de données très performante, notamment des packages d’extraction, de
transformation et de chargement (ETL) pour l’entreposage des données (Datawarehouse).
Un package est une collection organisée de connexions, d’éléments de flux de contrôle,
d’éléments de flux de données, de gestionnaires d’événements, de variables, de paramètres et
de configurations assemblés à l’aide des outils de conception graphiques de SQL Server
Intégration Services.
Le schéma suivant illustre un package simple contenant un flux de contrôle avec une tâche de
flux de données, qui contient à son tour un flux de données.

2.5.2.3. Présentation Visual studio 2019

Visual Studio est un ensemble complet d'outils de développement

permettant de générer des applications web ASP.NET, des services XML,
des applications bureautiques et des applications mobiles. Visual Basic,
Visual C++, Visual C# utilisent tous le même environnement de
développement intégré (IDE), qui leur permet de partager des outils et facilite la création de
solutions faisant appel à plusieurs langages. Par ailleurs, ces langages permettent de mieux tirer
parti des fonctionnalités du Framework .NET, qui fournit un accès à des technologies clés
simplifiant le développement d'applications web ASP et de services web XML grâce à Visual
Web Développer.
Mais aussi un espace de travail Business Intelligence ralliant (SSIS, SSAS, SSRS) pour la
création de solutions de l’informatique décisionnelle.

2.5.2.4. Présentation de Power Bi

Power BI est un service d’analyse commerciale fourni par

Microsoft qui permet de visualiser des données et de partager
des informations. Il convertit les données de différentes sources
pour créer des tableaux de bord interactifs et des rapports de
Business Intelligence.

P a g e 38 | 72
Power BI propose un éditeur convivial qui offre une gamme de graphiques et de tableaux inter-
actifs pour créer des visualisations percutantes. Des fonctionnalités avancées telles que la
création de mesures personnalisées, la gestion des relations entre les tables et la collaboration
en temps réel sont également disponibles. C’est un outil largement utilisé par les professionnels
pour exploiter les données et prendre des décisions éclairées basées sur des informations
précises.
2. 5.2.5. Présentation de Microsoft Power Automate

Microsoft Power Automate est une plateforme d’automatisation des processus qui permet de
créer des flux de travail automatisés en connectant différentes applications et services. Avec
une interface conviviale, les utilisateurs peuvent configurer facilement des actions, des
déclencheurs et des conditions pour automatiser des tâches manuelles et répétitives. Power
Automate simplifie l’automatisation sans nécessiter de compétences en développement
avancées. Il offre la possibilité de connecter des applications populaires et d’orchestrer des
flux de travail entre celles-ci, ce qui améliore l’efficacité opérationnelle et la productivité.
Power Automate est un outil puissant pour automatiser les processus d’entreprise et accélérer
les opérations.
Nous pouvons créer des flux de cloud, flux de bureau, ou flux de processus d’entreprise.

Conclusion
Grâce à une étude approfondie de l’ancien système décisionnel, j’ai pu identifier les limites et
les problématiques de ce dernier. Et après avoir assimilé les besoins recueillis par les utilisateurs
finaux et mentionnés dans le cahier de charges, nous avons pu ressortir les nouveaux indicateurs
et axes d’analyse relatifs au suivi des tickets dans les différentes outils utilisés et présentés ci-
dessus. En- fin, j’ai défini l’architecture de notre système et précisé les outils décisionnels
adoptés à savoir la composante SSIS et l’outil de reporting Power BI. Dans le chapitre suivant,
nous détaillerons le datamart conçu pour répondre au suivi des tickets de changements et
d’incidents. J’y décrirai ensuite la conception des tableaux de bord, en spécifiant les indicateurs
et les axes d’analyse utilisés.

P a g e 39 | 72
CHAPITRE 3
MODELISATION DU PROJET
Une fois les besoins définis et analysés, la phase de
conception est l’étape suivante dans le cycle
dimensionnel. Après une description des différentes
couches du système décisionnel, Je présenterai la
démarche suivie pour concevoir notre base de
données. J’enchainerai par la conception de
tableaux de bord en spécifiant pour chacun les
indicateurs et les axes d’analyse mis en jeu.

P a g e 40 | 72
1. Architecture de la solution
Comme illustré sur la Figure présentée ci-dessous, les différents composants de l’architecture
technique de ce projet sont :
L’Extraction : Dans cette phase j’ai utilisé l’outil Power Automate pour automatiser le
processus de téléchargement des extractions Excel reçues chaque lundi dans ma boite mail.
➢ L’Alimentation :
Pour la préparation de données, nous utilisons comme outil ETL la composante SSIS (SQL
Server Intégration Services), qui est un outil de gestion de flux. Il permet le développement
simplifié des ETL, en mettant à la disposition de l’utilisateur, dans une interface d’édition
graphique, un large éventail de fonctionnalités

FIGURE 11 : Architecture de la solution

➢ Le Stockage :
Les données seront stockées dans Microsoft SQL Server, qui est un produit de Microsoft servant
de système de gestion de bases de données. De plus, SQL Server fournit une solution intégrée
d’analyse et de gestion de bases de données, chose qui rend les données de l’entreprise
facilement gérables et le développement plus fluide. Cette intégrité de SQL Server fait qu’elle
réduit la complexité en temps et en développement de la création, le déploiement et la gestion
des données de l’entreprise qui proviennent de plusieurs sources hétérogènes.

➢ La Restitution :
L’outil de restitution utilisé dans mon projet est le logiciel Power BI. On a choisi Power BI car
il présente une approche différente de celle utilisée dans la Business Intelligence traditionnelle.
Power BI permet un déploiement rapide grâce à sa technologie en mémoire et offre une
simplicité accrue par rapport aux solutions traditionnelles de Business Intelligence, à condition
d’adopter une approche appropriée.

P a g e 41 | 72
Power BI met également l’accent sur l’interopérabilité avec diverses sources de données, ce qui
per- met d’agréger des informations provenant de différentes origines pour une analyse
holistique. Les fonctionnalités de création de tableaux de bord interactifs, de rapports visuels et
d’exploration de données font de Power BI un outil puissant pour transformer les données en
informations exploitables.
La figure suivante résume l’architecture applicative adoptée pour notre solution, commençant
par l’ETL, passant par la modélisation et arrivant à la restitution et reporting.

3.1 Modélisation multidimensionnelle

Avant d’entamer les détails de la modélisation, nous allons décrire brièvement les types de
modélisations.
Il existe trois possibilités :
➢ Modélisation en flocon : Ce type est caractérisé par une seule table de fait entourée de
dimensions qui ont des hiérarchies entre elles. Il permet d’offrir un gain en termes de
volumétrie de la base de données.

FIGURE 12: schéma en flocon

P a g e 42 | 72
➢ Modélisation en étoile : c’est un modèle qui simplifie le modèle logique normalisé en
organisant les données de manière optimale pour les traitements d’analyse. Dans chaque
dimension figure une seule table, ce modèle offre des performances d’accès très
intéressantes mais au prix d’une consommation de l’espace de stockage.

FIGURE 13 : schéma en étoile

➢ Modélisation en constellation : C’est un modèle hybride contenant plusieurs tables de

faits chacune avec une modélisation et qui peuvent partager des dimensions entre elles

FIGURE 14 : schéma en constellation

P a g e 43 | 72
3.1.1. Choix du modèle
Après avoir défini les axes d’analyse et les indicateurs à partir desquels le modèle
multidimensionnel sera conçu, la deuxième étape consiste à élaborer ce dernier.
Les analyses décisionnelles sont basées sur des traitements directement liés à la modélisation
de l'information sous une forme conceptuelle proche de la perception qu'en a l'analyste. Cette
perception de l'information est basée sur une vision multidimensionnelle des données.
Cette modélisation multidimensionnelle consiste à considérer un sujet analysé comme un point
dans un espace à plusieurs dimensions (axes d'analyses). Les données sont organisées de
manière à mettre en évidence le sujet analysé et les différentes perspectives de l'analyse.
Dans notre exemple, la modélisation multidimensionnelle repose sur le concept de fait et de
dimension.

TABLE DE FAIT TABLE DE DIMENSION

Clé primaire La table de faits contient une clé
primaire qui est une concaténation
de clés primaires de toutes les
tables de dimensions.
Signification La table de faits contient les
mesures avec des attributs d’une
table de dimension.
Taille de la table La table de faits se développe
verticalement.
Attribut & Records La table de faits contient moins
d’attributs et plus
d’enregistrements.
Création
La table de faits peut être créée
uniquement lorsque les tables de
dimensions sont complétées.
Chaque table de dimension
contient sa clé primaire.
La table de dimension
contient les attributs avec
lesquels la table de faits
calcule la métrique.
La table de dimensions se
développe horizontalement.
La table de dimension
contient plus d’attributs et
moins d’enregistrements.
Les tables de dimension
doivent être créés en
premier.

Schéma Un schéma contient moins de Un schéma contient plus de

tables de faits. tables de dimension.
Les attributs La table de dimension
La table de faits peut contenir des contient toujours des
données au format numérique et attributs au format textuel.
au format textuel.

Tableau 17: Table de comparaison

P a g e 44 | 72
Pour faciliter l'utilisation et améliorer les performances lors de l'analyse des données, trois
types de schémas sont généralement : schéma en étoile, schéma en flocon de neige, schéma
de constellation.
Pour choisir un modèle de conception de données, nous avons étudié les différences entre ces
trois modes de conception :

Schéma en étoile Schéma en Schéma en

flocon
TABLE DE FAIT Une seule table de Une seule table de
faits entourée par un faits entourée par un
seul cercle de seul cercle de
dimensions dimensions
TABLE DE Toute dimension à Toute dimension à
dimension niveaux multiple est niveau multiples au
aplatée en une seule moins un niveau de
dimension dimension est géré
dans une structure
séparée des autres
niveaux
Le schéma en étoile Le schéma en
est conçu pour flocons de neige est
répondre à des conçu pour répondre
Avantages requêtes inhérentes à à des requêtes sur
la structure une dimension ayant
dimension-fais des relations
complexes entre ses
niveaux
Performant, Eviter les
navigation facile redondances
d’information
Reduction d volume
Tableau 18: Différence entre les trois modes de conception
constellation
Plusieurs tables de
faits
Plusieurs modèles
dimensionnels se
partagent les mêmes
dimensions, c’est –
à- dire,les de faits
ont des tables de
dimensions en
commun
La modélisation en
constellation est une
technique de
modélisation, issue
du modèle en étoile.

3.2 Modélisation Adoptée

Pour ce qui est de notre modèle décisionnel, les conditions suivantes sont à satisfaire :
➢ Contenir la table de fait.
➢ Contenir plusieurs tables de dimensions.
➢ Faciliter la navigation dans les données.
➢ Augmenter la performance d’accès et la rapidité de réponse.
➢ Satisfaire les exigences fonctionnelles et techniques.

P a g e 45 | 72
Le modèle qui s’avère le plus adapté aux besoins de mon projet est le modèle en étoile.
Pour procéder à la modélisation, il nous est nécessaire de recenser les axes d’analyse dont nous
disposons pour pouvoir concevoir les dimensions en premier lieu, en leur donnant comme clé
primaire « Id » qui servira comme clé étrangère dans la table de fait. Nous entamerons en
deuxième lieu la conception de la table de fait, qui aura comme clé l’ensemble des clés
étrangères des dimensions en plus des indicateurs que je voulais calculer à partir des
informations provenant des dimensions. J’ajouterai aussi les champs Dates provenant des
dimensions contenant les dates.
Ce processus que je viens d’expliquer va être appliqué sur chaque volet à savoir : Incident,
change- ment, build, coordination.
Notre client SFR souhaite avoir un tableau de bord pour chaque volet cité au- dessus et donc
pour chaque volet on a un schéma qui lui correspond.
• La figure suivante (Figure 15) illustre le schéma en étoile pour le volet incident (Tickets
des incidents) :

FIGURE 15 : Modèle Incident

• La figure suivante (Figure 16) illustre le schéma en étoile pour le volet changement
(Tickets de changement) :

FIGURE 16 : Modèle Change

P a g e 46 | 72
 • La figure suivante (Figure 17) illustre le schéma en étoile pour le volet build :

FIGURE 17 : Modèle Coordination

3.3. Conception des tableaux de bord

Afin de répondre aux besoins du reporting opérationnels, j’ai conçu des tableaux de bords qui
nous permettons de faire le suivi des indicateurs que je suis supposé arranger à manière de leur
donner un sens. Pour ce faire, j’ai recours aux modèles décisionnels de l’outil Power Bi que je
détaillerai dans le chapitre suivant.
Les tableaux ci-dessous résument la conception des tableaux de bord en mettant en évidence
les indicateurs, les axes d’analyse, ainsi que leurs objectifs.

➢ Le volet "Incident

Intitulé du tableau de bord Incident

Total incident par état,
Total incident par sévérité du cas, Total incident par mois,
Total ticket traité, Délais de résolution,
Top 10 Max du délais de résolutions, Total incident par
Indicateurs propriétaire et statut du cas,
Evolution Backlog

Axe d’analyse Custom,propriétaire,statut , sévérité , date

Objectifs et résultats attendus La disponibilité des informations actualisées chaque semaine.
Consulter l’évolution de traitement des tickets.
TABLE 19 : Tableau de bord pour le volet « Incident"

P a g e 47 | 72
 ➢ Le volet "Change"

Intitulé du tableau de bord Change

Change traité par attribution, Change traité par urgence,
Change automatisé,
Total change traité, Total change par état Délais de
résolution,
Indicateurs Top 10 Max du délais de résolutions,
Total change par état et par mois, Evolution Backlog

Axe d’analyse Custom,attribution,état d’urgence , type de traitement,état,

date
Objectifs et résultats attendus La disponibilité des informations actualisées chaque
semaine
Consulter l’évolution de traitement des tickets
TABLE 20: Tableau de bord pour le volet "Change"

➢ Le volet " Build"

Intitulé du tableau de Build
bord
Indicateurs Nouveau client, client résilié, Total site migré,
Total ticket résolu,
Total ticket résolu par attribution, Evolution Backlog

Axe d’analyse Client,custom,attribution,état , type de demande, date

Objectifs et résultats La disponibilité des informations actualisées chaque semaine.
attendus Consulter l’évolution de traitement des tickets par chaque membre
d’équipe Évaluer la productivité de chaque menmbre de l’équipe
Suivre l’évolution des clients de SFR à savoir les nouveaux et les
résiliés
TABLE 21 : Tableau de bord pour le volet"Build"

P a g e 48 | 72
 ➢ Le volet "Coordination"

Intitulé du tableau de Coordination

bord
Indicateurs Total ticket, Workflow déployé,
Total ticket résolu par attribution, Total ticket résolu par type de
demande,
Nombre ticket résolu par mois, Total ticket résolu
Total ticket par état

Axe d’analyse Attribution,état , type de demande, date

Objectifs et résultats La disponibilité des informations actualisées chaque semaine.
attendus Consulter l’évolution de traitement des tickets par chaque membre
d’équipe Évaluer la productivité de chaque menmbre de l’équipe
TABLE 22 : Tableau de bord pour le volet"Coordination"

Conclusion
La conception de la solution décisionnelle est l’étape la plus délicate du projet. Afin de
concevoir notre base de données, nous avons adopté une modélisation en étoile en se basant sur
les indicateurs et axes d’analyse identifiés dans le chapitre précédant. Le chapitre suivant
détaille la réalisation des ETL d’alimentation à l’aide de SSIS et des tableaux de bords
moyennant Power BI et automatiser tous ce travail par la suite.

P a g e 49 | 72
CHAPITRE 4
MISE EN ŒUVRE
Ce chapitre a pour objectif de présenter la phase de
réalisation qui concrétise la conception exposée lors
du chapitre précédent à savoir l’automatisation du
reporting. Je commence par la mise en œuvre de la
phase de téléchargement automatique de données
puis la phase de l’ETL automatisé en utilisant l’outil
SSIS. Ensuite, je présente les tableaux de bord
automatisés et réalisés à l’aide de l’outil Power BI.

P a g e 50 | 72
2. Création d’un flux de cloud automatisé
En utilisant Power Automate dans mon projet, j’ai pu automatiser certaines tâches liées aux
téléchargements de données, ce qui a permis de gagner du temps et d’assurer la disposition des
données.
Dans mon cas, le team leader des prestataires de l’activité opérationnelle PBC m’envoie un
mail contenant les extractions Excel de la semaine chaque lundi au plus tard 10h matin.
Pour automatiser le téléchargement de ces fichiers j’ai réfléchi à utiliser un flux de cloud
automatisé à l’aide de l’outil Power Automate.
L’utilisation de ce type de flux permet d’automatiser efficacement les processus et les tâches
récurrentes, ce qui permet de gagner du temps et d’améliorer l’efficacité opérationnelle. Les
flux de cloud automatisés peuvent être configurés facilement grâce à des interfaces visuelles
conviviales, ce qui les rend accessibles même aux utilisateurs non techniques. De plus, ces flux
offrent une flexibilité et une extensibilité considérables, car ils peuvent intégrer différentes
applications et services, permettant ainsi une automatisation complète des flux de travail à
travers les systèmes. Ainsi ils s’exécutent dans le cloud, ce qui signifie qu’ils sont accessibles
de n’importe où et à tout moment, sans nécessiter une présence physique sur site.

FIGURE 18 : Réalisation d’un flux de cloud automatisé

P a g e 51 | 72
Dans mon flux de cloud automatisé, j’ai créé un déclencheur "Quand un nouvel e-mail arrive"
pour capturer les e-mails spécifiques. J’ai configuré le filtre pour l’objet en spécifiant
"Reporting- PBC", que j’ai partagé avec le chef d’équipe. Ainsi, chaque fois qu’un e-mail
correspondant est reçu, le flux est déclenché. J’ai utilisé ensuite l’action "Apply for Each" pour
itérer sur chaque e-mail capturé.
À l’intérieur de cette boucle, j’ai défini une action pour télécharger les pièces jointes des e-
mails dans un répertoire spécifié. Cela permet de stocker les fichiers de manière organisée et
accessible pour une utilisation ultérieure. Grâce à ce flux de cloud automatisé, j’ai pu
automatiser le processus de récupération et de stockage des pièces jointes des e-mails.

4.1 Création de la base de données "PBC"

Avec la création des tables dans la base de données du serveur de l’entreprise vient création des
schémas de base de données afin de permettre le développement des flux ETL et les tableaux
bords qu’on va présenter dans la partie suivante.
La base de données est nommée « PBC », et contient quatre schémas à savoir :
STG : pour les tables Staging.
ODS : pour les tables ODS.
Audit : pour les tables D’audit
Param : pour les tables de paramétrage

FIGURE 19 : Structure de la base de données

P a g e 52 | 72
La phase de staging, également appelée étape de préparation des données, consiste à extraire
les données brutes à partir de différentes sources de données, telles que des fichiers, des bases
de données ou des services Web. Les données extraites sont ensuite transformées pour les
préparer à être chargées dans le système cible. Cela peut inclure des opérations de nettoyage,
de filtrage, de validation et de reformatage des données.
Schéma "STG" : Le schéma STAGING présente les données provenant des extractions Excel:

FIGURE 20 : Schéma Staging

Le schéma STG contient les tables staging. Ces tables prennent la même structure des
extractions Excel avec quelques modifications minimes.
La phase ODS est une étape intermédiaire entre la phase de staging et la phase de data
warehousing. Dans cette phase, les données préparées dans la phase de staging sont stockées
dans une structure de base de données spécifique appelée Opérationnel Data Store (ODS).
L’ODS agit comme une zone tampon entre les sources de données et le data Warehouse final.
Il permet d’effectuer des opérations supplémentaires sur les données, telles que
l’enrichissement, l’intégration et la consolidation, afin de les rendre prêtes à être utilisées dans
les rapports et les analyses.
Schéma "ODS" : Le schéma ODS présente les données après avoir appliqué toutes les
transformations nécessaires sur les tables staging.

P a g e 53 | 72
 FIGURE 21 : Schéma ODS

La phase d’audit est une étape primordiale dans tout projet. Elle consiste à examiner de
manière approfondie les processus, les activités et les résultats du projet afin de s’assurer de
leur conformité aux normes, aux exigences et aux objectifs établis.
Schéma « Audit » : Le schéma AUDIT contient également des tables qui sont spécifiquement
utilisées pour enregistrer les informations relatives aux packages développés à l’aide de l’outil
SSIS.

FIGURE 22: Schéma AUDI

P a g e 54 | 72
Dans mon projet SSIS (SQL Server Intégration Services), j’ai mis en place des tables d’audit
dans notre base de données pour suivre les packages. Ces tables sont remplies à l’aide de
procédures stockées spécialement conçues à cet effet. Les procédures stockées sont exécutées
à des moments clés du flux de travail SSIS, capturant ainsi les informations pertinentes sur
l’exécution des packages.
Les tables d’audit nous permettent de garder une trace détaillée des activités liées à l’exécution
des packages. Elles enregistrent les déclenchements, les succès ou les échecs, ainsi que les
statistiques associées. En examinant les données enregistrées dans ces tables, nous pouvons
suivre précisément l’exécution des packages, détecter d’éventuels problèmes ou erreurs, et
analyser les performances.

FIGURE 23 : Procédures stockées

Cette approche de suivi des packages à l’aide de tables d’audit nous offre une meilleure
visibilité sur les activités et les modifications effectuées lors de l’exécution des packages SSIS.
Cela nous per- met d’identifier les points d’amélioration, de résoudre les problèmes plus
rapidement et d’optimiser les performances de nos flux de travail. Les données capturées dans
les tables d’audit sont une ressource précieuse pour l’analyse et la prise de décision, nous aidant
à améliorer continuellement nos processus d’intégration de données.
Les tables de paramétrages dans mon projet sont utilisées pour stocker des informations
essentielles liées à la configuration et à la gestion. Elles contiennent des valeurs ajustables
manuellement, telles que les extractions de données, les packages, le projet lui-même, et les
tableaux de bord. Ces tables me permettent de personnaliser et d’adapter facilement les
paramètres du projet en fonction des besoins spécifiques, offrant ainsi une plus grande
flexibilité et une meilleure gestion de la configuration. On Schéma "param" : Le schéma AUDIT
présentent les informations qui concernent le projet à savoir : les informations des extractions
Excel que je reçois, les packages que j’ai développé, les tableaux de bord que je vais présenter
par la suite ....

P a g e 55 | 72
 FIGURE 24 : Schéma PARAM

4.2 Réalisation de l’ETL

4.2.1 Architecture du processus d’ETL

L’ETL est le processus qui nous permet d’extraire les données depuis les sources, les
transformer et les charger dans le datawarehouse. Dans la zone de préparation « Staging area »
les données sont extraites à partir des sources de données "Fichiers Excel", transformées et
préparées pour le chargement final dans les tables d’ods. Au niveau du serveur d’ETL, se fait
quelques transformations nécessaires avant le chargement final dans la zone d’entreposage. La
figure ci-dessous présente l’architecture du processus de l’ETL

FIGURE 25 : Architecture du processus ETL

Sous l’outil SSIS présenté dans la partie précédente, que j’utilise pour l’ETL, la solution est
organisée sous forme de packages. Chaque package contient des flux de données et chaque

P a g e 56 | 72
flux est une succession de tâches. Pour la réalisation, j’ai procédé par étapes. En effet, j’ai
alimenté d’abord les tables staging puis j’ai effectué quelques transformations sur ces tables à
savoir des jointures etc. pour alimenter finalement les tables d’ods. Ces étapes sont détaillées
dans ce qui suit.

4.2.2 Développement de l’ETL

Dans cette partie, je vais présenter les processus de développement des ETL, en commençant
par l’alimentation des tables Staging (les packages exécutés dans le package global
d’alimentation des Tables Staging (BIP_LVL1_STG_AlimSTGtables) et en finissant par
l’alimentation des tables ODS (BIP_LVL1_ODS_AlimODStables). La figure suivante présente
la séquence des différents packages d’alimentation :

FIGURE 26 : Processus d’alimentation des tables STG et ODS

Ce que je viens de présenter c’est le package "Main" qui contient des taches pour exécuter en
premier lieu les procédures stockées, puis exécuter le package global STG et la package global
ODS à savoir : (BIP_LVL1_STG_AlimSTGtables) ,(BIP_LVL1_ODS_AlimODStables)
Alimentation des tables de Staging :
La figure suivante présente le package d’alimentation des tables de STAGING à partir des
extractions Excel

P a g e 57 | 72
 FIGURE 27 : Processus d’alimentation des tables de staging

Codification des packages ETL : Les traitements ETL, à partir des extractions Excel vers le
staging, seront organisés comme suit :
➢ Un traitement (package) par table cible
➢ La codification des packages ETL vers le staging est comme suit :

P a g e 58 | 72
 ➢ Cette organisation permettra de :

• Faciliter le diagnostic des erreurs d’exécutions.

• Réduire la charge et les temps de traitement du staging vers les tables ods.

➢ Exemple d’alimentation d’une table staging :

Je prends comme exemple l’extraction Excel provenant d’outil Clarify à savoir le fichier :
"Incidents de la semaine.xlsx"
Le package d’alimentation table "STG_Incident" : "EPT_STG_Incident" s’exécute en plusieurs
tâches :
La première tâche est une exécution de script SQL afin d’exécuter la procédure stockée qui
s’occupe que je viens d’expliquer avant.
La deuxième tâche est une exécution de script SQL afin de supprimer les données existantes
dans la table Staging. Ceci nous permet de libérer les tables de staging en cas de réexécution du
package.
La troisième tâche est une exécution de script pour s’assurer que le fichier Excel existe dans le
répertoire spécifié dans le flux de cloud automatisé. Si le fichier existe on passe à :
La quatrième tâche est une tâche de flux de données permettant d’extraire les données depuis
le fichier Excel vers la table Staging.
La cinquième tâche est une tâche qui crée un dossier qui prend comme nom "GetDate()" dans
un dossier "Archive" que j’ai créé dans le but d’archiver le fichier Excel après traitement
Staging. Si le fichier n’existe pas on passe à :
La sixième tâche est une exécution de script SQL afin d’insérer une ligne dans la table " ". Cette
ligne a pour but d’informer que le fichier "X" n’existe pas.

Finalement l’exécution de la procédure stockée en cas de réussite du package et au cas d’erreur.

J’applique le même processus pour les packages d’alimentation des tables de staging qui restent.

P a g e 59 | 72
 FIGURE 28 : Package Alimentation de la table Incident staging

➢ Alimentation des tables ODS :

La figure suivante présente le package d’alimentation des tables ods à partir des tables de
staging après avoir appliqué quelques transformations.

FIGURE 29 : Processus d’alimentation des tables ods

P a g e 60 | 72
 ➢ Codification des packages ETL : La codification des packages ETL à partir des tables
de staging vers les tables ods est comme suit

✓ Exemple de chargement d’une table ods à partir de deux tables de staging :

FIGURE 30 : Package Alimentation de la table ODS

Je prends comme exemple la table [ods].[Icident] qui se charge à partir des deux tables à savoir
: [stg].[incident] et [stg].[backlog-incident]
Le package d’alimentation table "ODS_Incident" : "EPT_ODS_Incident" s’exécute en
plusieurs tâches :
La première tâche est une exécution de script SQL afin d’exécuter la procédure stockée qui
s’occupe que je viens d’expliquer avant.
La deuxième tâche est une tâche de flux de données permettant d’extraire les données depuis
les deux tables de Staging, appliquer des transformations minimes à savoir l’ajout de quelques
colonnes puis fusionner les deux sorties pour le chargement vers la table ods.
P a g e 61 | 72
 FIGURE31: ODS.AlimIncident

• La troisième et la quatrième tache c’est pour modifier la valeur de la colonne "Is_To_Load"

de 1 à O. Cette colonne se trouve dans tous les tables de staging et prend deux valeurs :

• 0 signifie que la ligne dans la table de staging est déjà chargée vers la table ods.
• 1 signifie que la ligne n’est pas encore chargée dans la table ods. Cela nous facilite la tâche
de suivi.
Finalement l’exécution de la procédure stockée en cas de réussite du package et au cas d’erreur.
J’applique le même processus pour les packages d’alimentation des tables ods qui restent.
Après avoir terminé la conception et le développement de mon projet SSIS (SQL Server
Intégration Services), la prochaine étape consiste à déployer le projet dans SQL Server Agent.
Cela m’a permis d’organiser et de planifier l’exécution automatisée des packages que j’ai créés.
En utilisant SQL Server Agent, j’ai pu créer des jobs qui représentent les différentes tâches ou
processus à exécuter. Chaque job peut être configuré pour exécuter un ou plusieurs packages
SSIS à des horaires spécifiques, de manière récurrente ou selon des déclencheurs personnalisés.
Dans mon cas j’ai créé deux jobs le premier s’occuper de l’exécution des packages STG et le
deuxième s’occupe de l’exécution des packages ODS.

P a g e 62 | 72
 FIGURE 32 : Jobs sous SQL Server Agent

4.3 Réalisation des tableaux de bords Power BI

La dernière phase de mon projet, et qui constitue en l’occurrence la dernière étape de tout projet
décisionnel, consiste en l’élaboration des rapports qui offriront aux utilisateurs finaux la
possibilité d’accéder de manière autonome et interactive aux informations. Ces fonctionnalités
seront assurées par l’outil que j’ai choisi d’utiliser pour cette étape, à savoir Power BI présenté
dans la première partie de ce chapitre.

4.3.1 Présentation du menu principal de Power BI

La première tâche est de charger les données à partir de la base de données la
connexion vers les "views" (j’ai créé une view pour chaque table ods). La figure
suivante montre le menu principal permettant de réaliser cette tâche.

FIGURE33: Connexion aux sources de données dans Power BI

P a g e 63 | 72
La fenêtre "Get Data" dans Power BI est l’endroit où nous sélectionnons et configurons nos
sources de données. Elle nous permet d’importer des données à partir de diverses sources telles
que des bases de données, des fichiers plats ou des services cloud. Après avoir cliqué sur le
bouton "Get Data", une fenêtre de dialogue apparaît, nous permettant de rechercher et de choisir
notre source de données. Une fois sélectionnée, nous fournissons les informations de connexion
nécessaires et pouvons prévisualiser, transformer et charger les données dans Power BI pour
créer des rapports et des tableaux de bord.
Dans le cas de mon projet, j’ai choisi "base de sonnées" comme source de données, une fois j’ai
entré le nom du serveur SQL les tables de ma base de données "PBC" sont affichées dans la
fenêtre de configuration comme montré dans la figure ci-dessus.

4.3.1.1.Modèle décisionnel
Avant de générer les modèles décisionnels, j’ai créé tout d’abord les dimensions ainsi que les
tables de fait. Dans mon projet j’ai généré quatre modèles décisionnels.

➢ Le volet Incident :

FIGURE 34 : Modéle décisionnel "Incident"

P a g e 64 | 72
➢ Le volet Change :

FIGURE 35 : Modéle décisionnel "Change"

➢ Le volet Build :

FIGURE 36 : Modèle décisionnel"Build"

P a g e 65 | 72
➢ Le volet Coordination :

FIGURE 37 : Modéle décisionnel "Coordination"

4.3.1.2 Présentation des tableaux de bords

Dans cette partie je vais présenter quelques types de tableaux de bord que j’ai élaborés. Ces
tableaux de bord représentent l’information de manière synthétisée sous forme des graphiques
plus faciles à interpréter. La Figure 38 représente le tableau de bord qui permet le suivi des
tickets des incidents :
La partie droite en haut représente les deux filtres à savoir : Un filtre sur les clients de SFR qui
ont opté pour l’offre PBC, puis le filtre de date depuis 2017.
Le reste des graphs sont des kpi’s que j’ai cité leur explication dans le deuxième chapitre.

FIGURE 38 : Tableau de bord "Incident"

La Figure 39 représente le tableau de bord qui permet le suivi des tickets des changements :

P a g e 66 | 72
 • La partie droite en haut représente les deux filtres à savoir : Un filtre sur les clients de
SFR qui ont opté pour l’offre PBC.
• Le reste des graphs sont des kpi’s que j’ai cité leur explication dans le deuxième
chapitre.

FIGURE 39 : Tableau de bord "Change"

La Figure 40 représente le tableau de bord qui permet le suivi de la productivité de chaque

membre de l’équipe ainsi que suivre l’évolution des clients de SFR à savoir les nouveaux et
les résiliés :

• La partie droite en haut représente le filtre de date depuis 2019.

• La partie gauche en haut représente les deux graphes de la partie "Client" à savoir : les
nouveaux clients et les résiliés.
• Le reste des graphs sont des kpi’s que j’ai cité leur explication dans le deuxième
chapitre.

FIGURE 40 : Tableau de bord "Build"

P a g e 67 | 72
La Figure 41 représente le tableau de bord qui permet le suivi de la productivité de chaque
membre de l’équipe :
• La partie droite en haut représente le filtre de date depuis 2019.
• La partie "Tableau de données" représente une table avec toutes les données pour
permettre aux clients une vision global.
• Le reste des graphs sont des kpi’s que j’ai cité leur explication dans le deuxième
chapitre.

FIGURE 41 : Tableau de bord "Coordination"

Publication des tableaux de bord dans le report server

Après avoir créé les tableaux de bord à l’aide de l’outil Power BI j’ai créé un serveur où nous
allons publier nos tableaux de bord. J’ajoute par la suite toutes les personnes qui auront accès
à ce serveur à savoir le client SFR et ses prestataires à Intelcia IT Solutions pour pouvoir
analyser les kpi’s qu’ils ont demandé.

FIGURE 42 : Publication des tableaux de bord dans le serveur

P a g e 68 | 72
Cette fenêtre représente le menu principal de notre serveur où nous pouvons publier les tableaux
de bords.
Après cette étape j’ai configuré la planification des mises à jour et des rafraîchissements des
tableaux de bord. Cette configuration permet de spécifier quand et à quelle fréquence les
données des tableaux de bord doivent être mises à jour et rafraîchies. Ainsi, le système
effectuera automatiquement les mises à jour selon le calendrier défini, assurant que les données
affichées restent à jour et reflètent les dernières informations disponibles. Cela permet
d’automatiser le processus de maintenance des tableaux de bord et de garantir que les
utilisateurs ont toujours accès aux informations les plus récentes.

FIGURE 43 : Configuration de la mise à jour des tableaux de bo

P a g e 69 | 72
Conclusion Générale

L’objectif de mon stage de fin d’étude est la participation à la refonte de la brique décisionnelle
du nouveau projet PBC de SFR, Client d’Intelcia IT Solutions. Il s’agit de mettre à la disposition
des décideurs des tableaux de bord offrant une meilleure visibilité sur l’évolution de l’activité
PBC en particulier les tickets d’incidents et de changements.
Vu le caractère décisionnel du projet, j’ai suivi les différentes étapes du cycle de vie. Après
avoir étudié le système décisionnel existant, j’ai procédé au recueil des besoins et exigences de
la ligne à grande vitesse, à la définition des indicateurs et les axes d’analyse et enfin à la
conception des tables et la réalisation des tableaux de bords pour le suivi des tickets. Je me suis
ensuite consacrée à la réalisation des modèles, cette réalisation a consisté à alimenter les tables
grâce à l’outil SSIS depuis les sources de données Excel et a généré les états de restitution ciblés
sous forme de tableaux de bords sous l’outil Power BI.
En guise de perspectives, j’envisage entamer l’automatisation de toutes les étapes que j’ai suivi
pour aider le client à faire le suivi du traitement des tickets reçus ainsi que garder une visibilité
sur ses clients qui ont opté pour son offre PBC.
Signalons enfin que j’ai, dans le cadre de ce projet, pu bénéficier au sein d’Intelcia IT Solutions
d’un encadrement exceptionnel de la part d’un groupe d’experts auprès desquels on a été initié
au métier du réseaux et téléphonies, renforcé mes connaissances en informatique décisionnelle,
et manipulé les différents outils BI d’actualité

P a g e 70 | 72
Bibliographie

Livre/CD Contributeurs Pages/Duration Langue Editeurs

Business Objects - Web Thierry Edition

400 pages Français
Intelligence (version XI R2) Petibon ENI
Entrepôts de données. Guide Ralph Kimball, Français Edition
pratique de modélisation Margy ross 437 pages Vuibert
dimensionnelle 2ème édition.
Ralph Français Edition
Entrepôt de données : Guide
Vuibert
pratique de la modélisation
Kimball
multidimensionnelle
Le Data Warehouse : Guide de Ralph Kimball Français Edition
conduite de projet Eyrolles
The Data Warehouse Toolkit The
Complete Guide to Dimensional Ralph Kimball
Anglais N/A
Modeling (Second Edition)

P a g e 71 | 72
Webographie

[1] http ://infodecisionnel.com/la-bi-en-generale/datawarehouse/ods-vs-staging-

area/. Dernière visite : le 1 Mai 2023.

[2] https ://www.intelcia.com/fr. Dernière visite : le 15 Avril 2023.

[3] https ://www.intelcia.com/fr/it-solutions. Dernière visite : le 15 Avril 2023.

[4] T. Denizet. SSIS - Implémenter un flux.

[5] P. Valentin. Introduction à la B.I.

Avec SQL Server 2008. [4] [5] [2] [3]
[1]

P a g e 72 | 72