Rapportpfe-Aicha Bouhouche3

Ecole Nationale Supérieure d’Informatique
et d’Analyse des Systèmes
Mémoire de Projet de Fin d’Études
Pour l’Obtention du Titre
D’Ingénieur d’État en Informatique

Option
Business Intelligence
Sujet
Développement d’un outil ETL pour l’exploitation des données
provenant du système de recharge VoMS
Soutenu par : Sous la direction de :
Aicha BOUHOUCHE M. Ismail KASSOU (ENSIAS)

M. Ridallah EL AZHARI (NSN)
Année Universitaire 2010-2011

Dédicaces
A tous ceux qui me portent un amour incomparable et qui n’ont

jamais économisé de leurs efforts pour m’aider, à mes chers
parents, je dédis ce travail.
Je dédis aussi ce travail :
A mes frères : Fahd, Mohamed, Mustafa, Aziz pour leur aide et

soutien,
Et mes sœurs : Khadija, Fadila, Rachidab, Sanae, RachidaL
A mes neveux et nièces : Amal, Mouna, Mohamed Aymen,

Mohamed Adam, Abdeallah, Ilyass, Chaimae
A toutes mes amies, pour les bons moments que nous avons passés
ensemble ;
A tous ceux qui m’aiment.
Aicha
Remerciements
Au terme de ce travail, je tiens à remercier toutes les personnes qui m’ont soutenues au cours
de ce projet et tout le personnel de NSN qui n’ont épargné ni temps ni effort pour m’aider, en
particulier M. Hamid MHIMDEN.
Ainsi j’exprime ma profonde gratitude à M. Ismail Kassou et M. Ridallah EL AZHARI, mes

encadrants pour l’aide qu’ils m’ont apportée tout au long de la période de réalisation du
projet, pour leurs conseils, leurs directives précieuses ainsi que leur assistance pour la
rédaction du rapport.
Je présente aux membres du jury l’expression de ma reconnaissance pour avoir accepté de

juger mon travail.
Mes vifs remerciements s’adressent aussi à Monsieur Mohammed Abdou JANNATI IDRISSI
pour son aide et ses encouragements précieux, et à tout le corps professoral et administratif de
l’ENSIAS pour leur contribution à ma formation.
Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail
trouvent, ici, l’expression de mes remerciements les plus chaleureux.
Projet de Fin d’Etudes 2010-2011

3
Résumé
Le domaine de la télécommunication connait une grande évolution en 2011, en particulier le

secteur de la téléphonie mobile. Ce secteur se compose de deux services : le prépayé et le
postpayé. Le service prépayé est choisi par la majorité des nouveaux abonnés.
L’objectif de ce projet est d’exploiter les données générées par les deux plateformes VoMS
Voucher Manager System et le réseau intelligent IN du service prépayé, afin de développer un
système décisionnel permettant d’avoir des informations sur les recharges et sur la
consommation des clients.
Un système décisionnel est mis en place à l’aide d’Oracle Data Integrator pour le
développement de la partie ELT concernant l’extraction, l’intégration et la transformation des
données. La phase de restitution et présentation des données est réalisée par Oracle BI
Entreprise Edition pour la construction du Cube multidimensionnel et pour la génération des
rapports et tableaux de bord.

4
Abstract
The present document represents a synthesis of my Final Project Thesis within Nokia Siemens
Networks Morocco (NSN).The main objective of this project is to develop a data integration
application using data from VoMS plateforme.Throughout our project, we have followed a
purely decision-making approach. First of all, we studied the functions of the team
responsible, then we examined the existing systems.
Once the needs defined, we improved the collection and integration system by correcting the
existing work before starting to implement user’s views.
At the end, we implemented the ORACLE BI tools in order to elaborate the broadcasting and
presentation system. So, as an end result we achieved the conception and the deployment of
different reports and dashboards.
Through this document, we describe in more detail every part of this project realization.

5
Liste des abréviations
Abréviation Nom complet
ANRT Agence Nationale de Réglementation des Télécommunications
AWM Analytique Workspace Manager
BSS Base Station Subsystem
CCF Call Control Function
CKM Check Knowledge Module
HRN(C) Hidden Recharge Number (Ciphered)
ETL Extract Load Transform
GSM Global System for Mobile Communications
IKM Integration Knowledge Module
IN Intelligent Networks
IP Internet Protocol
LKM Load Knowledge Module
MDX Multidimensionnel Expression
NMT Nordic Mobile Telephony
NSN Nokia Siemens Network
OBIEE Oracle Business Intelligence Entreprise Edition
ODI Oracle Data Integrator
OLAP On-line Analitycal Processing
SCEF Service Creation Execution function
SCF Service Control Function
SDF Service Data Function
SQL Structured Query Language
SMAF Service Management Access Function
SMF Service Management Function
SSF Service Switching Function
SRF Specialized Resource Function
VOMS Voucher Management System
VOMAN Voucher Manager

6
Introduction générale
Table des figures

Figure 1 : Evolution annulaire du parc global de la téléphonie mobile.................................. 16
Figure 2 : Evolution des opérateurs de télécommunication au Maroc ................................... 17
Figure 3 : Parts de Marché ................................................................................................... 17
Figure 4 : Cycle de vie d’un projet décisionnel......................................................................19
Figure 5 : Diagramme de Gantt de planification du projet .................................................... 20
Figure 6 : Exemple de recharge à travers le service prépayé................................................. 23
Figure 7 : Architecture du système de la recharge ................................................................. 24
Figure 8 : Architecture des plateformes intelligentes de Maroc Telecom .............................. 25
Figure 9 : Les entités du système de la recharge................................................................... 26
Figure 10 : Les étapes de création des recharges dans le système VoMS .............................. 27
Figure 11 : Cycle de vie du voucher ..................................................................................... 28
Figure 12 : Procédure de la communication de la VOMS avec la plateforme IN ................... 30
Figure 13 : Les propriétés des vouchers dépendent des profils clients .................................. 31
Figure 14 : Modèle de stockage des fichiers d’activité des vouchers ..................................... 32
Figure 15 : Architecture du système d’information décisionnel ............................................ 35
Figure 16 : Exemple de cube ................................................................................................. 38
Figure 17 : Schéma en étoile du datamart ............................................................................. 42
Figure 18 : L’hiérarchie Temps............................................................................................. 43
Figure 19 : L’hiérarchie Profil.............................................................................................. 43
Figure 20 : Architecture technique de la solution .................................................................. 46
Figure 21 : Architecture d’Oracle Data Iintegrator .............................................................. 47
Figure 22 : Différence entre le processus ETL et le processus E-LT d’ODI .......................... 48
Figure 23 : Les banques de données créées dans notre projet................................................ 49
Figure 24 : L’extraction le chargement et la transformation des fichiers de la VoMS ............ 50
Figure 25 : L’extraction le chargement et la transformation des fichier provenant de l’IN .... 51
Figure 26 : Interface ODI pour l’alimentation de la table de faits avec les dimensions..........52
Figure 27: Package ODI pour le processus d’alimentation de table de faits.......................... 52
Figure 28 : Création des dimensions et du cube sous l’AWM ................................................ 55
Figure 29 : Vérification du mapping de la dimension Time ................................................... 56
Figure 30 : Vérification du mapping de la dimension canaux ................................................ 56
Figure 31 : Les données enregistrées dans le cube AWM avec les axes ................................. 57
Figure 32 : Les trois couches d’Oracle BI Administration ..................................................... 58
Figure 33 : Attribution des rôles aux utilisateurs................................................................... 59

7
Figure 34 : Tableau croisé de nombre de client ayant rechargé par plusieurs dimensions ..... 59
Figure 35 : Présentation du nombre de recharges par catégorie ...........................................60
Figure 36 : Jauges de pourcentage des cartes utilisées par type de carte .............................. 61
Figure 37 : La répartition du Montant de vente par catégorie de voucher ............................ 61
Figure 38 : Nombre de recharge par heure ...........................................................................62
Figure 39 : Tableau de bord de montant de ventes pa profil et canal .................................... 62
Figure 40 : L’architecture d’OBIEE ..................................................................................... 67
Figure 41 : Modèle conceptuel d’un réseau intelligent .......................................................... 69
Figure 42 : Représentation graphique des SIB ......................................................................70
Figure 43 : Le plan physique du réseau intelligent ................................................................ 72

8
Liste des tableaux
Tableau 1 : Les livrables de chaque étape du projet .............................................................. 21

Tableau 3: Les axes d’analyse des vouchers..........................................................................39
Tableau 4 : Description de la mesure nombre de vouchers .................................................... 40
Tableau 5 : Description de la mesure montant de ventes ....................................................... 40
Tableau 6: Description de la mesure nombre de clients ayant effectués une recharge ...........41
Tableau 7 : Matrice d’expression des besoins ....................................................................... 41

9
Table des matières

Table des figures ....................................................................................................................7
Liste des tableaux ...................................................................................................................9
Table des matières ................................................................................................................ 10
Introduction générale ............................................................................................................ 12
Chapitre 1 ........................................................................................................................... 13
1 Contexte général du projet ............................................................................................ 14
1.1 Nokia Siemens Networks ....................................................................................... 14
1.2.1 Introduction sur Nokia Siemens Networks.................................................................. 14
1.2.2 NSN Maroc ................................................................................................................ 14
1.2 Présentation du Projet ............................................................................................. 15
1.3.1 La téléphonie mobile au Maroc .................................................................................. 15
1.3.2 Description du projet .................................................................................................. 18
1.3.3 Objectifs visés ............................................................................................................ 18
1.3.4 Planification du projet ................................................................................................ 19
1.3.5 Les livrables ............................................................................................................... 20
1.3 Conclusion ............................................................................................................. 21
Chapitre 2 ........................................................................................................................... 22
2 Analyse et spécifications des besoins ............................................................................ 23
2.1 Sources de données chez NSN ................................................................................ 23
2.2.1 Description de l'IN .................................................................................................... 23
2.2.2 Description du système Voucher Management System (VoMS) ................................. 26
2.2.3 La procédure de la communication entre la plateforme VOMS et la plateforme IN .... 29
2.2 Le reporting existant ............................................................................................... 31
2.3 Besoins principaux ................................................................................................. 31
2.4 Conclusion ............................................................................................................. 33
Chapitre 3 ........................................................................................................................... 34
Spécification du Datamart ................................................................................................. 34
3 Spécification du datamart .............................................................................................. 35
3.1 Système décisionnel visé ........................................................................................ 35
3.1.1 L’ETL ....................................................................................................................... 36
3.1.2 Datawarehouse........................................................................................................... 36
3.1.3 Le cube ...................................................................................................................... 37
3.2 Méthode de conception ........................................................................................... 38

10
3.3 Axes et Indicateurs ................................................................................................. 38

3.3.1 Les axes ..................................................................................................................... 39
3.3.2 Les indicateurs ........................................................................................................... 39
3.3.3 Matrice d’expression des besoins................................................................................ 41
3.4 Conception Datamart .............................................................................................. 41
3.5 Conclusion ............................................................................................................. 43
Chapitre 4 ............................................................................................................................ 45
4 Mise en œuvre du système décisionnel ......................................................................... 46
4.1 L’ETL .................................................................................................................... 46
4.2.1 Oracle data integrator ................................................................................................. 47
4.2.2 Choix des modules de connaissance ........................................................................... 48
4.2.3 Les banques de données ............................................................................................ 48
4.2.4 Les interfaces ODI .................................................................................................... 49
4.2.5 Le package d’exécution des interfaces ....................................................................... 52
4.2.6 Le scénario ODI ........................................................................................................ 53
4.2 La partie cube et rapports ....................................................................................... 53
4.2.1 La suite Oracle Business Intelligence Enterprise Edition OBIEE ............................... 54
4.2.2 États de restitution réalisés avec OBIEE ................................................................... 54
4.3 Conclusion ............................................................................................................. 63
Conclusion générale ............................................................................................................. 64
Bibliographie ........................................................................................................................ 65
Annexes ............................................................................................................................... 66

11
Le domaine de télécommunication demeure l’un des secteurs en plein progrès au Maroc en

2011. En effet, l’apparition du nouvel opérateur INWI en février 2010 a relancé une
concurrence qui joue un rôle primordial dans la croissance du marché. Ainsi, ce domaine
connait une grande évolution dans tous ses secteurs en particulier la téléphonie mobile, qui
occupe une grande partie de ce marché.
La téléphonie mobile se développe à une cadence assez rapide, vu qu’elle requiert, jour après
l’autre, des outils et des technologies qui répondent aux attentes des clients ayant le choix
entre plusieurs opérateurs. Ainsi la concurrence oblige à offrir aux clients des services de
qualité, à réaliser le maximum de ventes de recharges et à mieux connaitre le comportement
du client.
Nokia Siemens Network fait partie des entreprises offrant des prestations de services aiculier
Maroc Télécom. Vu le grand nombre de clients dans le service prépayé il est important de
maitriser les anomalies qui agissent sur le système et d’avoir des détails sur la consommation
des clients. Ce projet s’inscrit, alors, dans le cadre de prestations des services et plus
précisément la proposition d’un système décisionnel pour l’exploitation des données
provenant des plateformes qui gèrent le service prépayé.
Ce document comporte quatre chapitres. Le premier présente l’organisme d’accueil ,Nokia
Siemens Network et le marché de la téléphonie mobile au Maroc, et donne une description
concise du projet, des objectifs visés et de la planification de ce projet. Le deuxième chapitre
introduit les sources de données de Nokia Siemens Network, et décrit la plateforme du réseau
intelligent(IN) et le système Voucher Management System (VoMS), ainsi que le mode de
communication entre les deux. Cela permettra de dégager, par la suite, les axes et les
indicateurs sur lesquels sera basée la conception décisionnelle. Le troisième chapitre présente
le système décisionnel. Enfin, le quatrième chapitre met le point sur la mise en œuvre de ce
système décisionnel, tout en présentant les solutions et la solution réalisée.

12
Chapitre 1
Contexte général du projet
Nous allons présenter dans ce qui suit l’organisme d’accueil, l’intérêt du projet, envers Nokia
Siemens Networks, ensuite le contexte du projet et enfin la démarche suivie pour l’élaboration
du travail.
Chapitre 1 Contexte générale du projet
1 Contexte général du projet

Nous présentons dans cette partie l’organisme d’accueil Nokia Siemens Networks en
commencent par une introduction sur NSN et ses principales missions. Nous passons à NSN
Maroc et ses domaines d’activité par la suite.
1.1 Nokia Siemens Networks

1.2.1 Introduction sur Nokia Siemens Networks
Nokia et Nokia Siemens Networks sont deux sociétés séparées qui travaillent toutes les deux
étroitement en alliance dans différents secteurs, tels que la stratégie, la relation clientèle et
dans les problèmes opérationnels.
Nokia a annoncé le lancement de Nokia Siemens Networks le 1er Avril 2007. NSN
actuellement se positionne comme leader dans le marché d’infrastructure des communications
.Son but est d’aider des centaines de consommateurs à travers le monde pour atteindre
l’objectif de connecter les cinq milliards d’utilisateurs en 2015.
Cette nouvelle société, Nokia Siemens Networks est le leader en fourniture de services de
communications globales. NSN fournit un portefeuille complet et équilibré de produits pour
les solutions d’infrastructure fixes et mobiles, elle s’adresse à la demande croissante des
services avec 20000 professionnels des services à travers le monde. Les revenus pro-forma
combinés de €17.1 milliards durant l’exercice 2008 font de Nokia Siemens Networks l’une
des plus grandes sociétés d’infrastructure de télécommunication. Nokia Siemens Networks
opère dans 50 pays et son siège social est situé à Espoo, en Finlande. Elle combine Networks
Busines Group de Nokia et l’expertise de Siemens Communications.
1.2.2 NSN Maroc
Nokia Siemens Networks Maroc fait partie de Nokia Siemens Networks Business Group, et
collabore étroitement avec Maroc Telecom, premier opérateur mobile au Maroc.
NSN Maroc fournit principalement à son client Maroc Telecom, les équipements du réseau
radio GSM ainsi que les prestations de services associées qui sont :
 La rrecherche et la négociation des sites géographiques où ces équipements seront
installés, pour les projets clés en main totales.
 Les constructions et implémentation d’infrastructures GSM pour les projets clés en
main totales et partielles.
 Les tests et les entretiens de la qualité de service réseau pour les contrats
d’optimisation radio.
 Le redéploiement d’équipements.
L'architecture organisationnelle de NSN Maroc, où s’est déroulé mon stage, est composée de
trois pôles principaux :

14
 Le pôle Network Planning : Il représente le cœur du travail de NSN Maroc. Il

s'occupe de la partie technique (planification du réseau, dimensionnement,
optimisation et maintenance du réseau BSS de Maroc Telecom). Le groupe de
Network Planning est divisé par zones géographiques ; une équipe s'occupe du projet
de Casablanca, une autre s’intéresse à la zone de Rabat et une troisième travaille sur la
zone Nord Est. Ces différentes équipes sont supervisées par un manager.
 Le pôle commercial : Cette équipe se charge de toutes les procédures financières,
l'établissement des comptes de NSN Maroc et la planification du budget pour chaque
six mois.
 Le pôle de déploiement : Elle se charge de négocier l'installation des nouveaux sites
avec les propriétaires dans le cas des contrats Télécom, de la supervision de la
construction des sites et de la fourniture du matériel.
1.2 Présentation du Projet

Le domaine de Télécommunication connait une grande évolution dans tous ses secteurs. La
téléphonie mobile demeure, cependant, le secteur qui se réserve une grande part du marché.
Ainsi, une concurrence accrue s’est révélée, surtout après l’apparition du nouvel opérateur
Inwi. Chaque opérateur cherche à gagner plus de clients et à fidéliser ses anciennes abonnées.
En même temps, les opérateurs doivent vendre plus de recharges prépayées pour réaliser un
chiffre d’affaire important.
Alors, pour faire face à cette concurrence, Nokia Siemens Network propose ce projet comme
solution à son client principal Maroc Télécom.
Pour bien comprendre les intérêts du projet, on va essayer dans cette partie d’avoir une vision
sur le marché de la téléphonie mobile au Maroc.
1.3.1 La téléphonie mobile au Maroc
Le parc global de la téléphonie mobile au Maroc s’apprête à franchir le cap de 33 millions
d’abonnés. C’est ce qui ressort du dernier rapport publié par l’observatoire de l’Agence
nationale de réglementation des télécommunications (ANRT) sur le marché du GSM au
Royaume.

15
Figure 1 : Evolution annuelle du parc global de la téléphonie mobile
Selon les statistiques annuelles présentées sur la figure 1, on remarque que le parc global de la
téléphonie mobile a connu une évolution continue entre les années 2008 et 2011. Le parc
compte actuellement plus de 33 millions abonnés. Ce chiffre a dépassé les 27 millions
abonnés en 2010. C'est-à-dire qu’en une année, les trois opérateurs ont gagné plus de six
millions de nouveaux clients. Ceci est dit à l’apparition d’Inwi dans le marché en Février
2010 a eu effectivement un effet sur le marché de la téléphonie mobile que ce soit le service
post payé ou le service prépayé.
D’autre part, si on analyse l’évolution de chaque opérateur durant la période entre Mars 2010
et Mars 2011, on remarque qu’Inwi gagne la grande partie des nouveaux abonnés du parc.

16
Figure 2 : Evolution des opérateurs de télécommunication au Maroc

Inwi arrive en tête avec 68% de nouveaux abonnés, suivi de Maroc Telecom avec 17%, alors
que Meditel ne s’adjuge que 15%.
Marché 2009 Marché 2010

Wana Wana
2% 10%
Méditel
36%
IAM.
IAM
Méditel 55%
62%
35%
Marché 2011
Wana
17% IAM
50%
Méditel
33%
Figure 3 : Parts de Marché

17
Malgré ces résultats en faveur d’Inwi, Maroc Télécom domine le marché avec 49,90% de
parts de marché, suivi de Méditel avec 33,32%, alors que l’opérateur Wana a une part de
16%. On remarque que Maroc Télecom perd des parts de marché au profit d’Inwi.
Sur un autre registre, le marché reste dominé par le prépayé : plus de 95% des utilisateurs
disposent seulement d’un abonnement prépayé. Autrement dit, le nombre des abonnés « post-
payés » ne dépasse par la barre de 5%.
1.3.2 Description du projet
Le prépayé demeure le service le plus important de chaque opérateur. En effet, une grande
part du chiffre d’affaire des opérateurs de télécommunication est due à la vente des recharges
prépayées. Maroc Télécom est l’opérateur ayant le plus grand nombre de clients. Il doit avoir
une vue sur le système qui gère les services offerts à sa clientèle, en particulier le service
prépayé qui fourni une grande partie de son chiffre d’affaire, grâce aux ventes des recharges
(recharge prépayé). Pour cette raison, NSN cherche à proposer des solutions décisionnelles
permettant de superviser l’activité de ce service.
Le système est composé de deux principales plateformes qui gèrent tout le service prépayé :
VoMS (Voucher Management System) et IN (Intelligent Networks).
Suite à l’activité de VoMS et IN, des tickets qui regroupent un ensemble d’informations pour
chaque opération sont générés quotidiennement.
Ainsi, Maroc Telecom a besoin de manipuler de manière efficace le volume de données
générées pour pouvoir en tirer profit, et ce en les exploitant de manière à prendre des
décisions pertinentes, comme par exemple, pouvoir répondre à des problématiques de gestion
du système et de ciblage des clients.
1.3.3 Objectifs visés
NSN voudrait offrir à Maroc Télécom une vue totale et multidimensionnelle des informations
de la plate-forme VOMS à travers une intégration des données générées par l’activité de cette
plate-forme.
Cela permettra par la suite d’effectuer des analyses sur les données intégrées, de générer des
rapports, des tableaux de bord et permettre ainsi aux décideurs de prendre les bonnes
décisions au bon moment.
Le livrable de ce projet doit permettre aux utilisateurs d’avoir :
 Des statistiques constituant un diagnostic de la plateforme VoMS, par exemple les
nombres de recharges dans leur cycle de vie.
 Des KPI représentant d’une manière pertinente l’activité des VoMS et permettant de
détecter les anomalies globales, et d’avoir une vue sur le comportement des clients
dans le service, afin de fournir des tableaux de bord constamment à jour.
 Des rapports dynamiques qui donnent aux utilisateurs la possibilité de changer leurs
paramètres pour offrir une meilleure visibilité sur l’utilisation des recharges.

18
 Une facilité d’accès et d’utilisation.
1.3.4 Planification du projet

Le cycle de vie d’un projet décisionnel est composé de plusieurs étapes comme il montre la
figure 4.
Figure 4 : Cycle de vie d’un projet décisionnel

Pour réaliser ce planning de PFE, plusieurs réunions régulières ont été fixées tous les 15 jours,
afin de présenter l’état d’avancement du projet et préciser les tâches à faire pour les périodes
suivantes.
D’après le cycle de vie d’un projet décisionnel, les phases qui constituent notre projet sont :
1. Recueil et analyse des besoins : Durant cette étape, nous avons effectué une étude du
métier, en essayant de comprendre l’architecture VoMS. Nous avons aussi fait une étude de
l’existant, et nous avons préparé l’environnement Oracle.
2. Spécification du datamart : la conception du schéma en étoile et du cube OLAP.
3. Développement du processus ETL :
 Mise en place ODI
 Extraction des données à partir des fichiers générés par la plate forme VoMS
 Transformation des données afin d’avoir des données plus homogènes et plus
agrégées.
 Mise en place du datamart.
4. Développement des rapports & tableau de bord et mise en production :

19
 Mise en Place OBIEE, AWM

 Mise en place du cube OLAP
 Création de la couche business model et présentation
 Développer les rapports
5. Déploiement.
La planification du projet est une phase primordiale du cycle de vie décisionnel. Elle consiste
à prévoir le déroulement du projet tout au long des phases constituant le cycle de
développement.
Figure 5 : Diagramme de Gantt de planification du projet

La durée du projet est de quatre mois, qu’on a répartie sur les tâches. Le diagramme Gantt
montre les différentes étapes de ce projet avec leurs durées.
1.3.5 Les livrables
Pour chaque phase présentée dans ce diagramme, une remise de livrables est nécessaire, afin
d'assurer la traçabilité du projet et la communication avec le client. Ces livrables servent de
documentation pour le déploiement du projet et contribuent dans la rédaction du rapport.

20
Les étapes Livrables

Lancement et planification Cahier de charge et Méthodologie de conduite du
projet
Etude et définition des Dossier de spécification
Besoins
Conception Dossier conceptuel
Conception des flux.
Matrice de croisements dimensions/mesures
Schéma en étoile.
Modèle physique de données.
Dossier d’ETL Dossier d’ETL
Développement des Dossier de Rapports et des Cubes
modèles de restitutions
Tableau 1 : Les livrables de chaque étape du projet
1.3 Conclusion
Dans ce chapitre nous avons illustré les besoins généraux de Maroc Telecom, qui ont donné
naissance à ce projet décisionnel et qui nous ont permis d’expliquer son contexte général.
Dans le chapitre suivant nous présentons la démarche générale à suivre pour la réalisation et
mise en place d’un système décisionnel, ainsi que les sources de données de NSN.

21
Chapitre 2
Analyse et spécification des besoins
Nous allons consacrer ce chapitre à quelques généralités sur les sources de données à savoir
les deux plateformes VoMS et L’IN, pour arriver à détailler les principaux besoins et les
différents types de fichiers pour le reporting.
Chapitre 2 Analyse et spécification des besoins
2 Analyse et spécifications des besoins

Dans la partie d’analyse des besoins, nous cherchons à comprendre le métier et d’avoir une
idée sur le système existant.
2.1 Sources de données chez NSN

L’architecture du système de la recharge prépayée de Maroc Télécom est composée de deux
principales plates formes qui gèrent tout le service de la recharge prépayée.
Figure 6 : Exemple de recharge à travers le service prépayé

Dans la figure 5, nous avons deux exemples de recharges, soit par SMS, soit par appel. Les
deux canaux se connectent à la plateforme VoMS qui à son tour, se connecte au réseau
intelligent(IN) en particulier au service Charge@once. A travers ce processus, le client peut
recharger son compte.
Dans ce qui suit nous détaillerons les deux plateformes qui composent ce service de Maroc
Télécom, et nous décrirons la chaîne actuelle de mise à disposition des données.
2.2.1 Description de l'IN
Maroc Telecom, l’opérateur historique, à l’instar des autres opérateurs, a instauré son réseau
intelligent pour la bonne gestion du réseau de télécommunications et s’est appliqué pour le
développer en y intégrant de nouvelles plateformes afin de le performer.
Le réseau intelligent facilite l’introduction et la modification de nouveaux services de
recharge, avec une réduction importante des délais de développement associés, en même
temps, de réduction des coûts de développement. Nous allons détailler la description de cette
plateforme.
Nous essayerons tout d’abord d’avoir une idée générale et claire sur les différents plans de
fonctionnement sur lesquels s’appuient les réseaux intelligents, et nous découvrirons les
entités qui composent la solution IN proposée par Nokia Siemens Networks.

23
2.1.1.1 Le rôle de l’IN dans le service prépayé

Les possibilités de la recharge classique, à savoir la recharge par le 555, et la recharge par
SMS utilisent des codes composées de 14 chiffres, appelés HRN (Hidden Recharge Number).
Ces codes, doivent être vérifiés dans le VOMS (Voucher Management System). Ensuite, ce
dernier doit communiquer à la plateforme Charge@once, responsable de la taxation dans le
réseau intelligent ,le nouveau crédit et la durée de la validité de ce crédit. La figure 9 présente
les principaux éléments présents pour supporter la recharge via DTMF et SMS :
Figure 7 : Architecture du système de la recharge
Le mobile initie l’opération de la recharge, dans l’interface radio, ensuite le MSS (Mobile
Switching Center) doit router cette demande vers les entités Gateway de ce service. Les
entités passerelles de ces deux recharges sont l’IVR (Interactive Voice Response) et le SMS-
Gateway. L’IVR, est responsable de réponses vocales, permettant de guider un utilisateur du
service de la recharge vers le bon déroulement de cette opération. A la fin de ce processus,
l’utilisateur reçoit un message vocal lui confirmant le succès ou l’échec et le nouveau solde
ajouté à son compte. Le SMS-Gateway, permet de gérer les recharges via SMS. Cette entité
est responsable de délivrer les messages courts de confirmation d’ajout de solde.
L’architecture existante se base sur les éléments suivant SMS-GW (SMS Gateway), IVR,
VOMS, C@O(Charge@once), SEP en plus des plateformes Erefill et IPD (IP Dispatcher).
Ces entités et leurs rôles seront décrits en détail dans ce qui suit. La figure 10, décrit
l’architecture existante, et les éléments en rouge décrivent les entités du système supportant
les recharges via 555 et SMS :

24
Figure 8 : Architecture des plateformes intelligentes de Maroc Telecom

Pour la troisième recharge, à savoir la recharge par le service GAB (guichet automatique
bancaire), le serveur de médiation, appelé MDC GAB Rech jouera le rôle de la passerelle.
Les équipements Gateway s’interfacent avec le VOMS/ResP à travers une interface appelée
DB-connect(Database connect). Notons aussi que plusieurs serveurs appelés ResP sont
connectés directement avec le VOMS, pour lui véhiculer les trafics des recharges qui
proviennent de directions différentes, figure 9 :

25
Figure 9 : Les entités du système de la recharge
Ainsi, le VOMS reçoit le trafic des entités IVR, SMS, MDC et USSDR (USSD Gateway).
Cette dernière sera installée pour la recharge via les donnée USSD et pourra interroger l’entité
SEP dans le réseau intelligent pour le traitement de la demande de la recharge et la mise à
jour du solde du profil de l’abonné demandant.
2.2.2 Description du système Voucher Management System (VoMS)
La plate forme Voucher Management System est la plate forme qui gère les recharges dans
les différentes étapes de leur cycle de vie, de la création à l’utilisation.
La VoMS est une entité indispensable pour l’assurance du service de la recharge prépayée.
Elle est aussi d’une grande importance puisqu’elle représente la plateforme avec laquelle
toutes les autres plateformes s’interfacent. Ainsi, on peut remarquer le rôle primordial que
joue cette entité dans le service de recharge en ligne, et on peut déduire que ce dernier
représente un choix stratégique, et qu’il est la principale source des revenus de l’opérateur.

26
Figure 10 : Les étapes de création des recharges dans le système VoMS [2]
Pour que le voucher (recharge) soit disponible, un code de recharge ou HRN (Hidden
Recharge Number) doit être enregistré dans une base de données associée au VoMS et qui
contient des paramètres prédéfinis (crédit, validité de crédit..). Le gestionnaire de service crée
ses propres données justificatives dans la base de données pour le service de recharge en
utilisant l’application VoMAN (Voucher Manager). Le système VoMAN envoie un ordre de
création des vouchers choisi, ce qui permet de créer toutes les données exigées dans la base de
données. Pour améliorer la sécurité des services de recharge, tous les numéros de vouchers
14
(soit 10 éventualité, puisque on a 10 chiffres à utiliser et 14 chiffres dans un code de la
recharge) ne sont pas créés à la fois dans la base de données de la VoMS (un paramètre de
licence contrôle le nombre maximum de vouchers enregistrés dans le VoMS soit
généralement de 10 vouchers par abonné à un moment). Ainsi, il devient très difficile pour un
abonné qui n'a pas acheté une carte de prépayé de deviner un code de recharge qui a déjà été
produit dans la base de donnée.
L'HRN n'est pas écrite dans la base de données en clair, mais elle est cryptée (HRNC =
Hidden Recharge Number Ciphered). De cette façon, même si quelqu'un accède à la table de
la base de donnée, il n'y a pas d'information à l'intérieur qui peut être utilisée pour recharger.
Dès la réception de la demande de recharge, la VOMS effectue les vérifications suivantes:
 Elle vérifie que le client a bien entré 14 chiffres.
 Elle compare les 14 chiffres entrés avec les HRNCs déjà enregistrés dans la table des
vouchers.
 Elle vérifie l’état de l’activation du HRN. C.-à-d. est ce que le voucher est disponible
pour être utilisé ou pas encore.

27
 Elle complète le processus en mettant état =utilisé quand le compte client a été
rempli.
Le schéma ci-dessous illustre le cycle de vie des vouchers dans le système VOMS.
Figure 11 : Cycle de vie du voucher [2]
D’abord, le voucher est créé dans la base de donnée associée à l’entité VOMS, et il reste dans
l’état désactivé, jusqu’à la distribution de la carte prépayée chez les vendeurs et qui contient
le code HRN d’accès à ce voucher. Ensuite, le voucher devient prêt à être utilisé et une fois,
la carte associée est utilisée dans une opération de recharge, on attend l’acceptation du crédit
par le réseau intelligent. Pourtant, un voucher peut être bloqué par le VOMAN, ou bien expiré
s’il dépasse la date de validité.
La plate forme VoMS génère de nombreux rapports qui visent à savoir ce qui se passe sur le
système. Les rapports sont générés automatiquement (périodes quotidiennes) ou sur demande :
Parmi ces rapports, il y a les rapports qui sont utilisés pour garder une trace de l'activité du
système qui se composent de cinq types :
 Les rapports d'activité des vouchers: les Vouchers dont l'état a changé au cours des
derniers jours sont énumérés dans les rapports quotidiens des vouchers.
 Les rapports d'activité des clients: les clients dont l'état a changé au cours des
derniers jours sont énumérés dans les rapports quotidiens.

28
 Les rapports de transaction: ce rapport énumère les transactions financières effectuées

dans un jour.
 Les rapports de distribution: les erreurs de la migration.
 Les rapports d’Activité IMAN: donnent des informations sur les numéros de série
rejetés.
Il ya aussi les rapports Audits qui gardent une trace des opérations effectuées à partir agent
Frontaux interfaces (ADMIN, VOMAN, Customer Care, et VoMSAPI). Ces rapports sont
générés périodiquement.
Finalement on trouve les rapports poubelles qui sont utilisés pour vérifier les paramètres de
base de données et l'établissement (segment par exemple, les clés d'encodage, la catégorie de
recharge, imprimantes, ...). Ces rapports sont générés à la demande.
2.2.3 La procédure de la communication entre la plateforme VOMS et la plateforme IN

Pour que l’opération de recharge soit valide, l’authentification du client prépayé dans le
réseau intelligent est indispensable. Le VOMS qui reçoit des requêtes de la recharge des
entités IVR, SMS Gateway ou GAB, doit communiquer à la plateforme Charge@once ,
responsable de la taxation dans le réseau intelligent, toutes les informations relatives à la carte
prépayée utilisée, pour qu’il puisse mettre à jour le solde et la durée de validité du compte
prépayée.
La figure ci-dessous décrit les transactions échangées entre la VOMS et la plateforme IN :

29
Figure 12 : Procédure de la communication de la VOMS avec la plateforme IN

Le mécanisme de la communication entre le VoMS et la plateforme IN se fait en deux
opérations principales la première est interrogation du compte (les étapes 1,2) et la deuxième
est recharge (les étapes 3,4).
Dans l’interrogation, du compte la Plate forme VoMS envoie la fonction de demande
d’informations GETSUBINFO. Cette fonction contient le paramètre acount-ID, ce paramètre
est l’identification du produit dans la VoMS, qui doit être mappé dans le réel acount-ID dans
le profil dédié à un abonné dans l’IN.
La réponse de la fonction GETSUBINFO contient des données qui fournissent :
 Le tarif utilisé pour la période en question.
 Le profil de l’abonné (Jawal, Mobisud..).
 Le type du scénario qui doit être communiqué au VOMS.
 L’état de l’abonné (activé, désactivé).
 Le statut du compte.
Dans l’opération recharge, la fonction GETSUBINFOCONF contient l’identifiant du compte
réel acount-Id qui est délivré à partir de la plateforme charge@once. Elle contient aussi :
 Le type de voucher considéré : normal ou exclusif.
 Le type du bonus de la recharge appliqué (double recharge, pourcentage..).

30
Les données que contient la réponse sont :

 Type scénario : si un scénario est dédié à un abonné, cette information est incluse
dans toutes les réponses qui proviennent du réseau intelligent.
 Service (abonnement) qui doit être activé : service_ID, statut, add-Info
 Bonus_ID (si un bonus est appliqué par IN)
 Voucher type (voucher-id).
La gestion des vouchers dans le système est liée à la gestion des profils des clients pour bien
calculer la durée de validité et le crédit offert au client concerné.
Figure 13 : Les propriétés des vouchers dépendent des profils clients [2]
L’interface intermédiaire de synchronisations entre l’IN et VOMS sert à récupérer les
informations sur le client et à passer la recharge au solde du client.
2.2 Le reporting existant

Le système actuel se base sur des fichiers Excel. Il n’est pas tout à fait automatisé vu que les
données arrivent de la Direction SI. Celles-ci sont utilisées pour calculer les statistiques. Cette
solution est opérationnelle mais demeure moins performante qu’une base de données
relationnelle. Dans la proposition de NSN, le processus de la collecte d’informations jusqu’à
la présentation des tableaux de bord, doit être automatisé. En même temps, ce processus
transforme les données des fichiers textes traités en un modèle relationnel.
2.3 Besoins principaux
Vu que les fichiers sont zippés, alors, on a besoin d’un scénario qui extrait les fichiers textes à
partir des fichiers zippés et qui parcourt la liste des fichiers pour alimenter le système
décisionnel par les données adéquates.

31
Les données qui sont liés aux clients comme le profil du client, les statuts du client…. Serant
extraites du réseau intelligent et les rapports du système VoMS seront utilisés pour extraire
les données liées aux vouchers.
La plate forme VoMS génère plusieurs types de rapports. On s’intéresse dans notre projet aux
rapports systèmes et exactement les rapports de l’activité des vouchers.
Figure 14 : Modèle de stockage des fichiers d’activité des vouchers
La figure 14 montre les différents types de rapports de l’activité des vouchers générés par
VoMS avec leurs ID_Rapport et le Sub_Id_Rapport.
Chaque rapport de l’activité des vouchers contient plusieurs enregistrements des transactions
des clients comme l’exemple ci-dessus :
100|1001|2009-04-14 08:36:51|2009-04-14 02:36:51|000001000000|||2010-04-14 00:00:00 ||
100 | 68 |||||2009-04-14 08:36:51|1000000|2009-04-14 08:35:11|2009-04-14 08:36:51||4| 100 ||
6356000||2009-04-14 08:36:16|||0|

32
Cet enregistrement comporte deux parties, la partie en rouge est la partie commune qui a la
même structure quel que soit le rapport, et la deuxième partie est la partie spécifique qui est
consacrée au rapport et qui contient les données réelles du rapport.
La génération des rapports d'activité est faite périodiquement. Le contenu du rapport est
sauvegardé dans un dossier zippé. Son endroit est défini dans la documentation d'installation
et la configuration de son nom est (par exemple : activityReport__DDMMYYHHMMSS.txt.)
La taille de chaque fichier peut atteindre les deux Go vu qu’il contient des milliers et des
milliers d’enregistrement. Pour chaque transaction d’un client IAM une ligne est crée dans le
fichier et à la fin de la journée le fichier qui contient toutes les transactions est généré.
On vise à développer un système décisionnel en nous basant sur les données des deux
plateformes. Chaque système décisionnel se compose de deux parties principales : collecte et
intégration, présentation et diffusion.
On va essayer d’expliquer d’avantage dans ce qui suit les deux parties.
2.4 Conclusion
Après avoir compris le besoin client, et eu une idée sur le type de données générées par la
plate forme VoMS, On va décrire les différentes sources de données qui servent à alimenter
le système décisionnel. On va essayer de détailler la conception du Datamart.

33
Chapitre 3
Spécification du Datamart
Notre projet consiste à développer un Datamart pour l’exploitation des données provenant de
VoMS, dans ce chapitre nous allons présenter le système décisionnel visé, et spécifier la
conception du schéma en étoile.
Chapitre 3 Spécification du Datamart
3 Spécification du Datamart
Cette partie vient pour répondre aux préoccupations fonctionnelles majeures de la solution
visée .Il s’agit de fixer les principaux indicateurs relevés chez la majorité des clients de
VOMS relativement aux thèmes ciblés indispensables au pilotage et l’aide à la décision.
3.1 Système décisionnel visé
Figure 15 : Architecture du système d’information décisionnel [1]

La mise en place d’un système décisionnel se base sur quatre étapes fondamentales :
1. La collecte des données brutes dans leurs environnements d'origine : Ceci est dû au fait que
dans le système d’information de toute entreprise, les données existent dans différents
supports physiques (bases de données, fichiers Excel, fichiers textes…) et probablement sur
des sites géographiquement dispersés. La première étape consiste donc à regrouper toutes les
données nécessaires. Ce qui implique un travail plus ou moins élaboré de détection et de
filtrage pour n’extraire que l’information nécessaire et utile
2. L'intégration des données, c'est-à dire leur regroupement en un ensemble technique, logique
et sémantique homogène approprié aux besoins de l'organisme,

35
3. La diffusion, ou la distribution des informations récupérées, dans des contextes appropriés

aux besoins des utilisateurs
4. La présentation, c'est-à-dire le contrôle d'accès, la personnalisation, l’ergonomie…
3.1.1 L’ETL
La collecte des données se fait grâce aux outils génériques ETL « Extract-Transform-
Load». Il s'agit d'une technologie informatique permettant d'effectuer des synchronisations
massives d'information d'une base de données vers une autre.
Un ETL a pour rôle d’extraire les données nécessaires depuis leurs sources vers le support de
destination. Il se charge ensuite de leur consolidation. En effet, en raison de la dispersion de
l’information, nous ne pouvons assurer l’homogénéité des données extraites. L’état d’un
élément par exemple peut être codé en « 0 » et « 1 » sur un site, et en « b » et «w » sur un
autre, d’où le besoin d’unifier le codage. La troisième fonctionnalité d’un ETL est d’assurer
l’alimentation de l’entrepôt de données qui contiendra par la suite toutes les informations dont
le décideur aura besoin dans son système décisionnel.
3.1.2 Datawarehouse
Un entrepôt de données, plus connu sous le nom de Datawarehouse, est, selon le grand
dictionnaire, «une structure informatique dans laquelle est centralisé un volume important de
données consolidées à partir des différentes sources de renseignements d’une entreprise
notamment les bases de données internes et qui est conçue de manière que les personnes
intéressées aient accès rapidement à l’information stratégique dont elles ont besoin ».
C’est une base de données dédiée au stockage de l’ensemble des données nécessaires à
l’analyse et à la prise de décision. Le datawarehouse est alimenté grâce à l’ETL.
La modélisation d’un entrepôt de données se base sur deux concepts: les faits et les
dimensions. Les faits étant ce que nous voulons analyser et les dimensions, les données
suivant lesquelles seront analysés ces faits.
La table de faits : elle contient des mesures correspondant aux données de l’activité à analyser
(exemple : nombre de carte d’émission et de réception). Elle regroupe également les clés
associées aux dimensions. Il s’agit de clés étrangères dans la table de faits. En général une
table de faits contient peu de colonnes et plus d’enregistrements qu’une table de dimension.
Dans une table de faits, nous trouvons, en plus des clés étrangères, des attributs quantitatifs
qui doivent être additifs, semi-additifs ou utilisés pour faire des sommes, des moyennes ou
des ratios.
La table de dimension : représente, quant à elle, les axes d’analyse des mesures contenues
dans la table de faits. Par exemple, si nous voulons analyser le nombre de cartes selon les

36
types, la mesure « nombre de cartes » sera contenu dans la table des faits et analysée suivant
l’axe « site », attribut de la table de dimension objet.
Un modèle multidimensionnel sert à représenter le datawarehouse. Il est constitué de table de
faits et de tables de dimensions.
Il existe deux types de base de modèles multidimensionnels :
 Schéma en étoile : constituée d’une table de fait centrale, et de tables de dimensions
qui lui sont reliées
 Schéma en flocons de neige : c’est une variante du schéma en étoile. La différence
réside dans la simple normalisation des tables de dimensions. Les données sont alors
hiérarchisées et les attributs de chaque niveau hiérarchique sont mis dans une table
de dimension à part.
3.1.3 Le cube
C’est une représentation abstraite d'informations multidimensionnelles exclusivement
numériques utilisée par l'approche OLAP.
Cette structure est prévue à des fins d'analyses interactives par une ou plusieurs personnes
(souvent ni informaticiens ni statisticiens) du métier que ces données sont censées représenter.
OLAP (Online Analytical Processing), désigne les bases de données multidimen-sionnelles
ou cubes destinés à l'analyse. Ce terme s'oppose à OLTP qui désigne les systèmes
transactionnels. C’est un mode de stockage permettant l’analyse statistique des données.
Une base de données OLAP peut être représentée comme un cube à N dimensions où toutes
les intersections sont pré-calculées.

37
Figure 16 : Exemple de cube

Le grand avantage de ce modèle revient au fait que toutes les intersections du cube sont
calculées, ce qui facilite l’accès à l’information recherchée puisque le résultat se trouve aux
croisements des différentes dimensions.
Les requêtes sur les cubes OLAP sont écrites en langage MDX (Multidimensionnel
Expressions). C’est l’équivalent du langage SQL pour le modèle OLTP. Il permet de définir,
d'utiliser et de récupérer des données à partir d'objets multidimensionnels.
3.2 Méthode de conception

La méthode de conception qu’on a suivie pour ce projet est l'approche de Kimball. Alors on
consacrera le paragraphe suivant pour avoir une idée sur les caractéristiques de cette
approche:
Selon Kimball la première étape est la conception du modèle dimensionnel pour les datamarts,
c'est-à-dire ayant une vue métier. Celui-ci placera les datamarts au centre de l’architecture. Le
reste sera composé d’un staging area temporaire. Dans cette approche, on dit que les datamarts
sont centraux car ils peuvent contenir à la fois des données atomiques et agrégées, et qu’ils
offrent la possibilité de fournir une vue entreprise et une vue métier. Il est a noté que
l’implantation des datamarts se fait d’une façon incrémentale et intégrée. Pour finir, les
utilisateurs ne peuvent effectuer des requêtes sur le staging area.
Le staging area : comme dit précédemment, le staging area est temporaire. Il n’a pour
fonction que le stockage des données extraites des systèmes sources et les différentes
opérations de transformations savoir : Le nettoyage des données, la standardisation, le
déduplication...etc des données. Le staging area est dit temporaire car les données sont
détruites une fois le chargement des datamarts terminé.
Les datamarts indépendants : Les données sont donc transférées du staging area vers le
datamart concerné. Il est important de noter que le métadata est aussi stocké dans le datamart.
Les datamarts sont dit indépendants ce qui veut dire qu'il n'existe aucune intégration ou
communication entre ces derniers.
La zone présentation : lorsque les datamarts sont chargés, les utilisateurs peuvent, via la
zone de présentation, exécuter leurs requêtes Ad hoc, programmer les rapports, analyser et
visualiser l'information en provenance des datamarts.[6]
3.3 Axes et Indicateurs

Suite à une réunion avec les clients concernés, nous avons organisé les données par sujets
majeurs, et ainsi nous avons pu définir les besoins concernant les indicateurs et les axes
d’analyse liées à la supervision de l’activité des vouchers.

38
3.3.1 Les axes

L’analyse du service prépayé montre que le client peut choisir entre plusieurs modes de
recharge et plusieurs catégories de vouchers pour recharger son compte. On a choisi les
canaux et les catégories de recharge comme axe d’analyse.
La supervision des vouchers est liée aux clients. On veut donc avoir des données qui montre
l’utilisation des vouchers par profil client en précisant l’état du client avant effectuer la
recharge. Le profil client et statut client sont deux axes importants pour l’étude.
La dimension temps est toujours présente dans l’analyse décisionnelle vue que les données
dans le datawarehouse sont historiées et mises à jour.
Ainsi ces axes seront intégrés dans le tableau qui suit :
Nom de la dimension Définition Hiérarchie
Date Détermine la période de calcul des Année>Période>Mois>
indicateurs
jours>Heure
Canal Les canaux de recharges possibles :
187 : IVR
188 : USSD recharge
189 : SMS recharge…
Catégorie voucher Les catégories des vouchers :
5, 10, 20, 30,40dh …
Profil Classe
Les Classes des profils
>profil>sub_profil
Statut voucher Les différents états des vouchers dans leur
cycle de vie :
En attente, active, expiré,..
Statut client Définit la période avant d’effectuer une
nouvelle recharge
Tableau 2: Les axes d’analyse des vouchers
3.3.2 Les indicateurs
Les principaux indicateurs relativement aux thèmes visés
3.3.1.1 Nombre de vouchers

On cherche à avoir une vue globale sur les vouchers dans le système VoMS. Donc on aura
besoin du nombre de vouchers crées, le nombre de vouchers utilisés, le nombre de vouchers
en attente dans une période bien déterminée.

39
Définition L’ensemble de tous les vouchers
Enjeu Mesurer l’évolution des ventes des vouchers pour

concourir à sa maîtrise
Périodicité Période définie dans le paramétrage
Règle de gestion Calculer la somme des vouchers de tous les jours du

mois
Source Fichier Voucher_activity.txt
Axes d’analyse Canal, Profil, Statut du voucher, Statut du client,

Catégorie voucher, temps
Tableau 3 : Description de la mesure nombre de vouchers
3.3.1.2 Le montant de ventes

Le service prépayé est le principal revenu de Maroc Télécom, donc dans ce projet on doit
avoir une idée sur la contribution de chaque catégorie de recharge et chaque classe de profil
client dans le chiffre d’affaire de l’entreprise.
Définition Le montant réalisé du à la vente des vouchers
Enjeu Mesurer le chiffre d’affaire réalisé
Règle de gestion Calculer la somme des montants toutes les heures du

jour

Catégorie voucher, temps
Tableau 4 : Description de la mesure montant de ventes
3.3.1.3 Nombre de clients ayant effectué une recharge :

Pour bien cibler les clients on doit avoir des statistiques sur les clients ayant effectuées une
recharge par profil et statut du client.
Définition L’ensemble de tous les clients rattachés aux vouchers

utilisés

40
Enjeu Mesurer les ventes par rapport aux clients
Règle de gestion Calculer la somme des différents clients

Catégorie, temps
Tableau 5: Description de la mesure nombre de clients ayant effectués une recharge
3.3.3 Matrice d’expressions des besoins

Dans cette matrice on présente les relations entre les indicateurs et les axes déjà expliqués.
Axes Date Canal Profile Catégorie Statut Statut
client voucher
KPIs
Montant des ventes X X X X X
Nombre de clients
X X X X X
ayant effectués une
recharge
X X
Nombre de vouchers X X X X
Tableau 6 : Matrice d’expression des besoins
3.4 Conception Datamart

Notre Datamart est implémenté à l’aide d’un modèle en étoile. Cette structure de données est
constituée de tables de dimensions qui forment les branches de l’étoile et au centre d’une table
de faits qui enregistre les évènements qui se produisent à l’intersection de chaque dimension.
La table de faits contient les clés des différentes dimensions ainsi que les valeurs qui

41
correspondent aux indicateurs que l’on souhaite suivre. La plupart des données de la table de
faits sont donc numériques. Dans les dimensions se retrouvent tous les attributs, le plus
souvent textuels, utilisés pour qualifier les requêtes.
La figure qui suit montre le schéma en étoile du datamart de l’activité VoMS :
Figure 17 : Schéma en étoile du datamart
Ce schéma en étoile comporte la table de faits et celle des dimensions :

La table de faits contient les mesures :
 Nombre_voucher : le nombre de cartes de recharge.
 chiffre_affaire : montant réalisé par les transactions des clients.
 Nbre_client_ayant_rechargé : nombre de clients qui ont effectué une recharge.
Les six dimensions sont :
 Date_dim : c’est la dimension temps qui gère l’historique des données à travers sa
relation avec la table des faits. Elle est organisée selon l’hiérarchie Time_HR qui se
compose des niveaux année, trimestre, mois, jour puis heure.

42
All
Year …
Quarter …
Month …
Day
Figure 18 : L’hiérarchie Temps
 Profil_Dim : la dimension qui contient les informations sur les profils des clients de
chaque IN.
All
Classe …
Profil …
Sub_profil
Figure 19 : L’hiérarchie Profil
 Canal_Dim : contient les informations sur les différents canaux de recharge

possibles.
 Catégorie_voucher_Dim : cette dimension est utilisée pour identifier les catégories
des vouchers.
 Statut_client_Dim : cette dimension est liée aux statuts des clients qui ont effectués
de recharge.
 Statut_voucher_Dim : les états des vouchers dans leur cycle de vie.
3.5 Conclusion
Dans ce chapitre nous avons rappelé la démarche à suivre pour la réalisation et la mise en
place de notre datamart. Nous avons aussi décrit les différentes indicateurs et axes d’analyse
qui sert à répondre aux besoins de Maroc Télécom.

43
Ainsi, le chapitre suivant décrit les différentes étapes de que nous allons suivre pour mettre en
œuvre notre système décisionnel et sur lequel nous devons nous baser pour mener à bien la
phase de réalisation.

44
Chapitre 4
Mise en œuvre du système décisionnel
Ce chapitre a pour mission de présenter l’architecture technique de la solution mise en place
avec les outils de développement. Ensuite les phases de réalisation du système : ETL, Cube,
Reporting.
Chapitre 4 Mise en œuvre du système décisionnel
4 Mise en œuvre du système décisionnel

Comme cela a été expliqué précédemment la problématique se situe au niveau de
l’exploitation des données, qui ne peut pas se faire à l’état brut. Il est difficile, sans des outils
informatiques d’extraire les données nécessaires.
Ensuite nous décrivons la chaîne complète de mise à disposition des données, dans le but de
mieux appréhender le besoin du client.
Figure 20 : Architecture technique de la solution

La figure 20 montre les étapes de développement de notre système avec les outils qui
permettent de réaliser chaque partie.
Le premier outil c’est Oracle data integrator pour réaliser la partie ETL. La génération du
cube est faite avec Analytic workspace manager. Oracle Business Intelligence Entreprise
Edition est utilisé dans la phase de présentation des rapports et des tableaux de bords.
4.1 L’ETL
Comme on a déjà montré dans l’architecture technique de la solution, pour effectuer la phase
ETL on a utilisé ODI, on explique l’architecture de cette plateforme dans les sections
suivants.

46
4.2.1 Oracle data integrator
Figure 21 : Architecture d’Oracle Data Iintegrator [7]

Une plate-forme ODI est organisée autour d’un référentiel central accédé en mode
client/serveur par des composants entièrement écrits en Java :
 Les modules d’interface graphique dédiés aux utilisateurs de la plate-forme ODI.
 Les agents d’exécution en charge de jouer les traitements implémentés.
Les référentiels ODI sont constitués d’un Référentiel Maître stockant et exposant toute la
typologie du système décisionnel (serveurs physiques, bases physiques et logiques, agents
ODI) et de plusieurs Référentiels de Travail stockant et exposant toutes les méta-données des
projets d’alimentation ainsi que toutes les informations nécessaires à leur exploitation
(planification, ordonnancement et compte-rendu d’exécution).
Les référentiels (Maître & de travail) s'installent sur tout moteur de base de données
relationnel supportant la syntaxe ANSI ISO 89, tel qu’Oracle, Microsoft SQL Server, Sybase
AS Enterprise, IBM DB2 UDB, IBM DB2/400 etc.
Les espaces de stockage préconisés pour les référentiels ODI sont les suivants :
Référentiel Maître : prévoir environ 1 Go d'espace de stockage.
Référentiel de Travail : prévoir environ 5 Go d'espace de stockage par référentiel de travail.
Notez que l'espace de stockage requis dépend de la taille des projets et modèles, et du volume
des journaux d'exécution qui doivent être conservés.
La figure qui suit montre la différence entre l’approche traditionnelle d’ETL et la nouvelle
approche d’ODI.

47
Figure 22 : Différence entre le processus ETL et le processus E-LT d’ODI [8]
L’approche dite traditionnelle ou ETL, sert à alimenter un entrepôt de données. Les outils qui
s’inscrivent dans cette logique disposent en général d’un moteur (engine) et sont installés sur
des serveurs distincts. Tous les traitements de transformation se font par le biais du moteur
ETL. On peut citer par exemple Informatica, cognos decisionStream...C’est l’approche la plus
étendue actuellement.
L’approche d’ELT (Extraction, Loading, Transformation), génère du code SQL natif pour
chaque moteur de base de données impliqué dans les processus - sources et cibles. Cette
approche profite des fonctionnalités de chaque base de données, et les requêtes de
transformation doivent respecter la syntaxe spécifique au SGBD.
4.2.2 Choix des modules de connaissance

Les modules de connaissance sont des composants prédéfinis relatifs à certaines technologies
contenant des informations ODI qui servent pour un processus de génération pour cette
technologie, pour une fonction précise.
 Load knowledge module(LKM) File to Oracle (SQLDLLR) : charge les données depuis
un fichier sur un espace de travail Oracle à l’aide de SQL*Loader. Au Contraire de LKM
File to SQL, LKM File to Oracle permet une insertion de masse des données sur la cible,
ce type d’avantage est très utile pour les fichiers sources de très grande taille.
 Check Knowledge Module(CKM) Oracle: vérifie les différentes contraintes définies au
préalable pour Oracle, comme le respect de la clé primaire, le filtrage des données, pour
assurer une certaine qualité des données intégrées.
 Integration knowledge module (IKM) Oracle to incremental update : intègre les
données, déjà extraites depuis l’espace de travail Oracle, sur le schéma cible.
4.2.3 Les banques de données

ODI utilise ce mot pour désigner les table de base de données, les fichiers plats, les queue
JMS (Java Message Service) et plusieurs autres structure de données.

48
Figure 23 : Les banques de données créées dans notre projet

La banque des données des fichiers sources : cette banque contient les modèles relatifs aux
fichiers sources, la structure de ces fichier est obtenue à partir d’un reverse engineering sur les
fichiers pour en retirer les métadonnées.
La banque des données des tables Oracle : cette banque contient tous les modèles cibles
Oracle, à savoir la table cible pour l’activité de VoMS et la table cible pour les informations
concernant les clients, ainsi que le schéma en étoile. Ces modèles sont récupérés avec les
différentes contraintes, comme les clés primaires et les clés étrangères.
4.2.4 Les interfaces ODI
Une interface est un élément graphique contenant un ou plusieurs source de données et une
seule cible de données, elle permet de faire le mapping entre la source et la cible, ainsi que de
définir les transformations et les règles de gestion à appliquer.
 L’interface de mapping du fichier de l’activité de VoMS

Cette interface permet de faire le mapping entre le modèle de données du fichier source pour
l’activité de VoMS et la table Oracle VoMS_Activity. Ainsi que de faire les différentes
transformations pour obtenir à la fin des données intégrées.
49
Figure 24 : L’extraction le chargement et la transformation des fichiers de la VoMS

Le fichier texte de l’activité des vouchers contient plus de 2 millions d’enregistrement, pour
charger ce fichier dans une table créée sous oracle data base, ODI a besoin de plus de 10 min.
 L’interface de mapping du fichier des clients :

Cette interface permet de faire le mapping entre le modèle de données du fichier source des
clients et la table Oracle Costumer_IN.
L’exécution de ces deux interfaces se passe en plusieurs étapes pour avoir à la fin des tables
Oracle dans l’espace de travail, prêtes à être utilisées pour le remplissage de notre table de
faits.

50
Figure 25 : L’extraction le chargement et la transformation des fichier provenant de l’IN
 L’interface de population de la table de faits :

Cette interface fait la correspondance entre les différents champs remplis à travers l’extraction
et les dimesions retenues pour l’analyse, et permet ainsi de calculer les mesures de la table de
faits et de remplir cette dernière avec les clés des dimension et les mesures calculées.

51
Figure 26 : Interface ODI pour l’alimentation de la table de faits avec les dimensions
4.2.5 Le package d’exécution des interfaces

Un package ODI définit un travail complet d’intégration des données. Un travail se compose
de toute une suite d’étapes auxiliaires. En général ces étapes sont des procédures, des
interfaces ODI et autres composants qu’il faut concevoir en premier.
Figure 27: Package ODI pour le processus d’alimentation de table de faits

52
Le package conçu contient une suite logique d’étapes qui a été choisie pour répondre
exactement au besoin exprimé par le client. L’enchainement d’exécution des éléments est
comme suite:
1) En premier lieu une procédure ODI est exécutée pour lister les fichiers compressés et
enregistre tous les fichiers trouvés dans un fichier texte.
2) Le fichier texte est lu ligne par ligne et le résultat de chaque ligne est stocké dans une
variable ODI qui est passée en paramètre à l’outil « odiUnzip » qui procédera à
l’extraction des fichiers.
3) Une fois les fichiers décompressés, une autre procédure est responsable de lister tous
les fichiers texte qui contiennent les données et les passer en paramètre par
l’intermédiaire d’une variable ODI à une procédure ODI qui va vérifier chaque fichier
s’il a été extrait au préalable :
 Si le fichier n’existe pas dans la table des fichiers traités, il sera passé en paramètre à
l’interface ODI responsable de l’extraction des données.
 Si le fichier existe dans la table des fichiers traités, la boucle sera interrompue pour
passer au fichier suivant.
4) L’interface ODI est responsable de l’extraction du fichier, si pour n’importe quelle
raison le traitement du fichier ne se passe pas bien, un mail va être envoyé à
l’administrateur via l’élément « OdiSendMail » pour l’informer de l’erreur.
5) Une fois le l’extraction réalisée, le fichier est enregistré dans une table Oracle via une
procédure ODI avec un flag pour éviter une autre extraction du même fichier. Le
fichier est ensuite supprimé avec l’élément « odiDeleteFile »
6) Après l’extraction de tous les fichiers, une Interface ODI est lancée pour
l’alimentation de la table des faits à partir des nouvelles données.
7) Après l’alimentation de la table de faits, un mail est envoyé à l’administrateur pour
l’informer du bon déroulement du scénario ODI.
4.2.6 Le scénario ODI
Le scénario ODI est obtenu après la compilation du package ODI, similaire à la compilation
de tout code source, et sera stocké dans un référentiel ODI pour être exécuté par la suite par
un Agent ODI ayant accès au référentiel.
Dans l’étape de préparation du scenario pour le déploiement il a fallu tester l’ensemble des
composants, à travers leurs exécutions un par un et vérifier l’intégrité du résultat et des
données obtenues et réaliser les tests d’intégrité entre les différents composants à travers
l’exécution des scénarios élaborés.
4.2 La partie cube et rapports

Le marché du BI a connu une évolution rapide ces dernières années, d’où la présence d’une
multitude d’éditeurs qui sont continuellement en concurrence pour améliorer leurs offres.
Nous utilisons la solution décisionnelle OBIEE, ce choix a été adopté par l’organisme pour
des raisons de licence.

53
4.3.1 La suite Oracle Business Intelligence Enterprise Edition OBIEE
OBIEE est une plate forme décisionnelle de nouvelle génération qui permet de délivrer
facilement des informations pertinentes à un grand nombre d’utilisateurs, quelles que soient
les sources de données et l’infrastructure existante dans l’entreprise.
OBIEE est une solution de business Intelligence qui inclut tout ce qui est nécessaire pour
adresser les besoins des entreprises :
 The Oracle Database : La base de données pour la création de l’entrepôt de données
ou Datamart.
 Oracle Business Intelligence Server : le serveur pour intégrer de multiples sources
de données et les fédérer en une seule vue.
 Oracle Business Intelligence Answers : l’outil graphique pour la création des
rapports.
 AWM : l’outil pour la création des dimensions et des cubes OLAP.
 Oracle BI Administration : l’outil qui sert à développer, gérer et actualiser un
repository, ainsi qu’à administrer Oracle BI Server.
 Oracle Business Intelligence Interactive Dashboards : l’outil qui fournit des
graphiques, tableaux, pictogrammes qui suivent l’activité de l’entreprise. [1]
Nous abordons plus en détails dans l’annexe A chacun de ces outils.
4.3.2 États de restitution réalisés avec OBIEE
Cette partie présente en détail les étapes parcourues pour mettre en œuvre le système de
diffusion et présentation, à savoir l’analyse multidimensionnelle et le reporting.
4.3.2.1 Création du cube
Dans le cadre de l’informatique décisionnelle, le terme « analyse » désigne la possibilité de
naviguer parmi une grande quantité de données organisées sous format multidimensionnelle à
l’aide des requêtes MDX.
Notre cube OLAP est défini à l’aide de l’Analytic Workspace Manager l’AWM. Il permet de
mapper les données stockées dans un SGBD aux cubes multidimensionnels suivant le modèle
en étoile. Nous y spécifions les dimensions, et leurs hiérarchies, la table des faits, et ses
agrégats.
La figure ci-dessous montre le cube déployé:

54
Figure 28 : Création des dimensions et du cube sous l’AWM
Il se compose de l’arborescence suivante :

 Espace de travail analytique: représente l’espace de travail.
 Dimensions : où nous définissons nos dimensions
 Cubes : représente le cube et toutes ses mesures.
 correspondances : est l’onglet où nous définissons les différentes correspondances
existantes entre les colonnes des vues matérialisées créées auparavant et les champs
des dimensions et cube multidimensionnel.
L’AWM permet ainsi de tester les données, après avoir chargé les paramètres de mappage du
cube et ses dimensions. Les données des dimensions s’affichent sous forme d’arborescence en
respectant les hiérarchies créées :

55
Figure 29 : Vérification du mapping de la dimension Time
Figure 30 : Vérification du mapping de la dimension canaux

On peut visualiser les données du cube en déterminant les différents axes d’analyse.AWM
donne la possibilité de naviguer dans le cube et avoir des exemples de rapports.

56
Figure 31 : Les données enregistrées dans le cube AWM avec les axes
4.3.2.2 Création du référentiel

L’outil Oracle BI Administration permet d’organiser les données dans un référentiel avant de
les mettre à la disposition de l’utilisateur, pour préparer les données BI.
Alors il faut créer en premier lieu le référentiel avant de passer aux étapes de déploiement du
cube.

57
Figure 32 : Les trois couches d’Oracle BI Administration
Oracle BI Administration est constitué de trois couches :

 Couche physique: zone dans laquelle nous importons les vues physiques créées par
AWM auparavant.
 Couche Business Model and Mapping: zone où nous produisons des vues logiques
qui pointent sur les vues importées et où nous redéfinissons les hiérarchies tout en
spécifiant pour chaque niveau ses attributs.
 Couche Présentation: zone de dernières retouches sur les données. Elle permet de les
renommer, les réordonnant selon le type d’affichage que nous voulons obtenir lors de
la phase de création des rapports et autres manipulations.

58
Figure 33 : Attribution des rôles aux utilisateurs

Cet outil permet de définir les utilisateurs de reporting. Ainsi on a défini trois groupes selon la
répartition de l’équipe qui doit utiliser le produit final. Ces groupes sont BI administrateur ,BI
client et BI autres .
4.3.2.3 Reporting
Figure 34 : Tableau croisé de nombre de client ayant rechargé par plusieurs dimensions

59
Le diagramme en camembert ou pie chart ci-dessous présente le pourcentage de chaque
catégorie dans le nombre total des vouchers utilisés. Afin de réaliser ce graphe nous avons
mis en œuvre la mesure nombre de vouchers et la concaténation du pourcentage des nombres
de vouchers avec les catégories vouchers.
Figure 35 : Présentation du nombre de recharges par catégorie

On remarque que plus de 53% des recharges vendus sont de 10 Dhs. Suivi de 50Dhs et de
20Dhs.
La jauge ci-dessous est utilisée pour surveiller le nombre de cartes utilisés pour chaque type
de carte. Nous remarquons que les cartes de 10 Dhs ont un niveau moyen d’utilisation un
peu prés 50% des recharges utilisés.

60
Figure 36 : Jauges de pourcentage des cartes utilisées par type de carte

Malgré que le nombre de vouchers de 10 dhs utilisés est le plus grand nombre comme il
montre les jauges, mais ce n’est pas forcément le type de vouchers qui influence le chiffre
d’affaire réalisé par les mêmes ventes.
On remarque dans le diagramme qui montre la répartition du montant de vente par catégorie
de voucher que les vouchers de 50 Dhs sont eux qui contribuent avec un pourcentage très
important dans les ventes.
Figure 37 : La répartition du Montant de vente par catégorie de voucher

61
Figure 38 : Nombre de recharge par heure

Le système VoMS présente une activité très importante pendant les heures 18h et 19h, donc
Maroc Télécom doit faire attention aux plateformes qui gèrent le système pendant ces deux
heures pour que le système ne tombe pas en panne, ou pour ne pas perdre des recharges à
cause des fraudes.
Figure 39 : Tableau de bord de montant de ventes pa profil et canal

62
Les différents rapports réalisés sous l’outil answers sont de nature dynamique, ainsi même si
nous mettons à la disposition des utilisateurs des rapports prédéfinis, ils ont la possibilité de
les personnaliser à leur guise.
Pour avoir les statistiques sur les ventes par profil et canal, il suffit de sélectionner la date et
cliquer sur update pour avoir les nouveaux résultats.
4.3 Conclusion
Ce qui peut être approuvé de notre part, après une expérience vécue avec les outils oracle BI,
c’est qu’ORACLE est une plateforme décisionnelle extrêmement complète. Elle permet non
seulement d’utiliser les différents outils décisionnels, mais elle permet d’étendre et de
combiner leurs fonctionnalités grâce à l’utilisation d’un moteur de workflow.

63
Conclusion générale
5 Conclusion générale
L’objectif de ce projet de fin d’études était le développement d’un ETL pour l’exploitation
des données provenant du système de recharges VoMS. Pour réaliser ce travail, on a suivi une
démarche décisionnelle. D’abord, la spécification des besoins, ensuite la conception du
datamart pour arriver à la partie ETL où les données des fichiers des deux plateformes VoMS
et IN sont chargées dans une zone intermédiaire, base de données relationnelle Oracle, avec
l’outil ODI pour alimenter la table de faits et les dimensions. La partie développement du
cube et génération des rapports est faite à l’aide d’OBIEE.
Nous avons pu offrir, via notre travail, un système décisionnel permettant aux utilisateurs de
Maroc Télécom de découvrir un système opérationnel remplaçant les outils traditionnels.
Notre projet va permettre à Maroc Télécom d’avoir des statistiques sur le nombre de
vouchers à travers leur cycle de vie dans le système, et des statistiques sur le nombre de
clients ayant effectué des recharges par rapport aux profils, au statut client, et bien sûr par
rapport aux dates de recharges.
Comme perspective de ce stage. Une extension du travail achevé peut être réalisée, d’un côté,
non uniquement pour VoMS mais peut atteindre également d’autres plateformes gérant les
services inhérents aux réseaux intelligents. L’utilisation de la classification datamining d’un
autre côté, permettre de créer des segmentations de la clientèle, et d’appliquer les concepts de
datamining pour avoir des prévisions sur les comportements des clients.

64
Bibliographie
6 Bibliographie
1. Rapports
[1] [ABDEL ILAH Sara, BEN SID Asma, A. EL AFIA, 2009] Rapport du projet de fin
d’étude pour cycle ingénieur «Développement des vues utilisateurs pour la supervision
des équipements du réseau BSS», ENSIAS - Rabat, Février – Juin 2009.
[2] IAM_Combined training material V8 Top-Up solution, June 2009
2. Cours
[3] [KJIRI 2010] Mme Laïla KJIRI, Datawarehouse, 2010.
3. Webographie
[4] http://www.labdecisionnel.com/Solutions/Oracle-Data-Integrator/Espace-Oracle-Data-
Integrator.html
[5] http://download.oracle.com/docs/cd/E14571_01/integrate.1111/e12643/intro.htm
[6] http://www.oracle.com/technetwork/database/options/olap/index.html
4. Ouvrage
[7] [Kimball, 2009] Ralph Kimball, Laura Reevers, Margy Rose, Warren Thoruthwaite,
Le datawarehouse Guide de conduit de projet, Eyrolles, 2009.
5. White paper oracle
[8] [ODI June 2007] Oracle Data Integrator: Administration and Development, Student
guide, June 2007.

65
Annexes
Annexes

66
Annexes
ANNEXE A : Oracle Business Intelligence Entreprise Edition :
Oracle Business Intelligence Enterprise Edition Plus 11g
(OBIEE ) est une plate-forme complète d’analyse opérationnelle offrant une gamme étendue
de fonctionnalités : tableaux de bord interactifs, analyses à la demande, notifications et
alertes, reporting interne et reporting financier, tableaux d’indicateurs et gestion de la
stratégie, invocation de processus opérationnels, recherche et collaboration, analyses mobiles
et déconnectées, gestion système intégrée, etc. OBIEE 11g s’appuie sur une robuste
architecture Web orientée services qui s’intègre avec l’infrastructure informatique existante
des entreprises pour assurer un coût total de possession (TCO) minimum et un retour sur
investissement (ROI) maximum.
OBIEE Plus 11g fournit des analyses complètes et pertinentes pour tous les utilisateurs d’une
organisation, afin qu’ils puissent prendre de meilleures décisions, agir en s’appuyant sur une
information complète et mettre en œuvre des processus opérationnels plus efficaces.
Figure 40 : L’architecture d’OBIEE
A.1) Les Composants d’Oracle Business Intelligence :
 Oracle BI server : Un serveur d’analye qui procure un moteur de calcule et

d’agrégation qui intègre les données de plusieurs sources relationnels, non
structurés, OLAP, et autre.
 Oracle BI Admin Tool : Un outil d’administration utilisé pour la construction des
référentiels qui consiste en une couche physique, un business model et une couche de
mapping, et une couche abstraite de présentation pour es utilisateurs finaux.

67
Annexes
 Oracle BI Answers : Un outil personnalisé de requête et d’analyse qui traite les

données provenant de plusieurs sources de données dans un environnement web
pure. Les utilisateurs sont isolés de la complexité de la structure des données, il
visualise la vue logique des informations. Les utilisateurs peuvent créer des
diagrammes interactifs, des rapports, et des tableaux de bord. Les analyses peuvent
être sauvegardé, partagé, modifié, formaté, ou intégré dans les tableau de bord des
utilisateurs
 Oracle BI Marketing : Répond aux besoins du service marketing, connu aussi sous
le nom de Segmentation Server
 Oracle BI Interactive Dashboards : Des tableaux de bord web interactifs qui
affiche les informations requis pour l’aide à la décision. L’accès aux informations est
interactif, basé sur des rôles et des identités individuels.
 Oracle BI Delivers : Un outil de d’alerte qui procure un monitoring de l’activité. Il
peut être atteint de plusieurs manières incluant les emails, les tableaux de bord, et les
téléphone mobile.
 Oracle BI Disconnected Analytics : Il procure des réponses BI et des tableaux de
bord aux professionnels mobile avec des ordinateurs déconnecté du réseau. Il offre la
même interface que l’utilisateur soit connecté ou non au réseau.
 Oracle BI Publisher : Un moteur de reporting capable de générer des rapports en se
basant sur de multiples sources de données en multiples formats via multiples
canaux.
 Oracle BI Briefing Books : Rapporte des captures des tableaux de bord d’Oracle BI.

68
Annexes
ANNEXE B : Modèle conceptuel d’un réseau intelligent

La figure 41 décrit les quatre plans du modèle conceptuel du réseau intelligent INCM
(Intelligent Network Conceptual Model). Chacun de ces plans correspond à une abstraction
différente du réseau. Ce modèle ne doit pas être considéré en soi comme une architecture. Il
s’agit d’un guide de référence conceptuel pour les concepteurs.
Figure 41 : Modèle conceptuel d’un réseau intelligent
Généralement, un élément de service est indépendant d’un service donné. Cela est le cas par
exemple des authentifications ou mise en file d’attente qui peut être réutilisés pour la
création de nombreux services RI.
a) Le plan fonctionnel global, GFP (Global Functional Plane)
Il modélise un réseau intelligent comme une seule entité. Cette entité est capable d’effectuer
un certain nombre de fonctions représentées par des blocs de construction indépendants des
services SIB (Service Independent Building Block).

69
Annexes
Un SIB est une capacité normalisée réutilisable, définie indépendamment des services et de la
technologie. Il possède une entrée logique, une ou plusieurs sorties logiques, et deux
paramètres statiques et dynamique nécessaires à l’exécution du service.
Chaque module SIB, figure 42, est décrit à travers les éléments suivants :
 Une définition
 L’opération que ce module est appelé à effectuer
 Les paramètres SSD (Service Support Data) et CID (Call Instance Data).
 Ses sorties qui incluent la description des fins logiques et les paramètres CID qui
résultent à l’exécution du module SIB.
Figure 42 : Représentation graphique des SIB

Un SIB particulier représente la fonctionnalité du traitement d’appel BCP (Basic Call
Process). C’est à partir de ce SIB que le service est généralement initié. Un service correspond
dans le plan fonctionnel global, GFP (Global functional plan), à un chaînage de SIB. Ce
chaînage commence à un endroit précis dans le traitement d’appel, Ce point de départ est
appelé point d’initiation POI (Point Of Initiation). Dans l’exemple du service numéro vert, le
POI correspond à la détection du préfixe « 0800 ».
b) Le plan fonctionnel réparti, DFP ( Distributed Functional Plane)

Il modélise le réseau intelligent comme un ensemble d’entités fonctionnelles réparties qui
exécutent des actions FEA (Functional Entity Action). Une entité fonctionnelle FE
(Functional Entity) peut être assimilée à un objet de traitement.
Un SIB est matérialisé dans ce plan par une séquence d’actions exécutées dans les entités
fonctionnelles. Certaines de ces actions, peuvent induire des flux d’information IF
(Information flow) entre les entités fonctionnelles.
70
Annexes
Définition des entités fonctionnelles : Une entité fonctionnelle est un ensemble de fonctions
réalisant un service. L’organisation exécutoire des entités fonctionnelles est réalisée par des
flux d’informations (Information Flow) dont la sémantique est commune à toutes les entités;
Les entités fonctionnelles principales sont :
 CCAF (Call Control Agent Function): Fournit un accès au réseau à l'utilisateur et
gère l’interface entre l’utilisateur et le réseau.
 CCF (Call Control Function) : Se charge du control et de traitement d'appel et de la
nconnexion au sens classique du terme.
 SCF (Service Control Function) : Contient les logiques de service et assure l'interface
avec les fonctions de commande d'appel CCF, de ressources spécialisées SRF
(Specialized Resource Function) et de données de service SDF (Service Data
Function).
 SSF (Service switching Function) : Contient la logique de l’appel et sert d'interface
entre le SCF et le CCF. Elle permet au CCF d'être piloté par le SCF. Le CCF et SSF
sont inséparables, un élément de réseau possédant la fonction SSF doit posséder la
fonction CCF. C'est la raison pour laquelle on retrouve fréquemment la dénomination
SSF/CCF.
 SRF: Fournit des ressources spécifiques qui peuvent être utilisées par d'autres entités
du réseau.
 SDF : Fournit les données associées au service.
 SCEF (Service Creation Environment Function).
 SMAF (Service Management Access Function).
 SMF (Service Management Function).
c) Le plan physique PP ( Physical Plane)

Il modélise les aspects physiques du réseau intelligent. Il identifie les différentes entités
physiques PE (Physical Entity) et les protocoles qui existent dans le réseau intelligent réel. Il
spécifie par ailleurs les entités fonctionnelles implémentées dans les différentes entités
physiques. Cette implémentation doit respecter la règle qu'une entité fonctionnelle ne peut
être répartie sur plusieurs entités physiques. Elle peut par contre être dupliquée dans
différentes entités physiques.
Les flux d’information, IF, du plan fonctionnel global, correspondent habituellement à des
protocoles d’application. Dans le plan physique, on leur assigne la pile de protocole sur
laquelle ils vont fonctionner.
Le plan physique est pris en charge par les équipementiers et les opérateurs, La figure 3
montre le plan physique du réseau intelligent :

71
Annexes
Figure 43 : Le plan physique du réseau intelligent
Les entités physiques qui composent ce plan sont les entités SSP (Service Switching Point)
qui gèrent la commutation du réseau télécom vers le réseau de la signalisation et les entités
qui permettent le control tel que le SCP (Service Control Point), le SDP (Service Data Point),
les entités de gestion tel que le SMP (Service Management Point) et le SMAP (Service
Management Access Point). En plus, des entités intelligentes IP (Intelligent Peripheral) qui
fournissent les ressources nécessaires pour l’exécution du service.

72
Annexes
ANNEXE C: Les profils des abonnés de Maroc Telecom
Dans l’ancienne architecture, chaque abonné possède un seul compteur qui représente son
crédit (solde), donc le coût d’un appel, un message, un MMS ou un autre service est déduit de
ce compteur. En analysant le comportement des abonnés, on peut constater que ceux-ci
peuvent être catégorisés, autrement dit, il y a ceux qui utilisent beaucoup plus de SMS que
d’appels et ainsi de suite, d’où l’idée de séparer la facturation de tels services. Pour ce faire,
NSN a introduit d’autres compteurs, en l’occurrence 12 pour chaque abonné. Du coup, après
l’intégration de ce service dans les différentes plateformes du réseau intelligent, les
consommateurs peuvent faire des recharges de chaque service séparément et d’une façon
indépendante.
Il existe deux types d’abonnés, postpayés et prépayés, donc les profils dépendent aussi de ces
types :
 Prépayé :
Les abonnés prépayés possèdent deux types de profils :
 Jawal : Ce profil est rechargeable via les Vouchers (cartes à gratter) ou eRefill, il offre
8 types de contrats et 12 compteurs.
 Classic : c’est l’offre normale la plus utilisée.
 Jeune : c’est une offre semblable à Classic, destinée aux jeunes, avec la seule
différence en termes de tarif.
 Liberté : elle est similaire aux deux offre précédentes, mais avec un tarif différent.
 Spare 1 à 5 : ce sont des offres conçues pour des utilisations futures.
 Mobisud : C’est un nouveau profil similaire à Jawal, destiné aux jeunes, il offre 5
contrats et 12 compteurs.
 Mobisud : c’est une offre semblable aux offres Jawal, avec une autre logique de
tarification.
 Mobisud Spare 1 à 5 : conçues pour un usage ultérieur.
Postpayé :
 Forfait Planifié (FFP) : c’est un profil où l’abonné reçoit chaque mois une durée bien
déterminée des appels, répartie sur 2 compteurs. Les abonnés peuvent recharger leur
compte pour plus d’appel que la durée déterminée par le contrat. Différents types de
contrats sont offerts qui se différencient par la durée des appels mensuelle. Il offre
deux arborescences de contrats :
 Forfait Maitrisé (FM)
1- FM_Normal
2- FM_Entreprise
3- FM_Spare 1 à 4.
 Forfait Liberté
1- FL_Normal
2- FL_Student
3- FL_Spare
73
Annexes
Tous les contrats ont la même structure et priorité des compteurs, mais chacun est définit par
un tarif et une annonce à part. Par exemple FL_Student offre un crédit de 45 minutes, avec
des appels illimitées durant le soir ou les weekends à un numéro ou un ensemble de numéros
IAM.
 NTPE : c’est une offre dédiée aux entreprises. Il est définit par une valeur monétaire.
Deux types de contrats sont offerts et 2 compteurs.
 Compteur 1 :
C’est un forfait monétaire en deux variantes :
1- Forfait limité.
2- Forfait illimité.
 Compteur 2 :
Contient la valeur monétaire (annoncée en Dirhams) dérivée des recharges via vouchers.
 Teenz : les consommateurs reçoit au début de chaque mois un crédit de SMS,un crédit
de minutes et un autre crédit que l’abonné peut charger à sa guise en utilisant les
vouchers, pour des appels en plus du budget contracté. Ce profil est contrôlé par le
département de Billing et destiné aux consommateurs qui communiquent plus par des
SMSs.
Il offre 3 types de contrats :
 Teenz_Normal
 Teenz-Illimité
 Teenz_Spare

74

Rapportpfe-Aicha Bouhouche3

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapportpfe-Aicha Bouhouche3

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale Supérieure d’Informatique

et d’Analyse des Systèmes

Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre

D’Ingénieur d’État en Informatique

Soutenu par : Sous la direction de :

Aicha BOUHOUCHE M. Ismail KASSOU (ENSIAS)

Année Universitaire 2010-2011

A tous ceux qui me portent un amour incomparable et qui n’ont

Je dédis aussi ce travail :

A mes frères : Fahd, Mohamed, Mustafa, Aziz pour leur aide et

Et mes sœurs : Khadija, Fadila, Rachidab, Sanae, RachidaL

A mes neveux et nièces : Amal, Mouna, Mohamed Aymen,

A tous ceux qui m’aiment.

Ainsi j’exprime ma profonde gratitude à M. Ismail Kassou et M. Ridallah EL AZHARI, mes

Je présente aux membres du jury l’expression de ma reconnaissance pour avoir accepté de

Projet de Fin d’Etudes 2010-2011

Le domaine de la télécommunication connait une grande évolution en 2011, en particulier le

Projet de Fin d’Etudes 2010-2011

Projet de Fin d’Etudes 2010-2011

Projet de Fin d’Etudes 2010-2011

Table des figures

Projet de Fin d’Etudes 2010-2011

Projet de Fin d’Etudes 2010-2011

Liste des tableaux

Tableau 1 : Les livrables de chaque étape du projet .............................................................. 21

Projet de Fin d’Etudes 2010-2011

Table des matières

Projet de Fin d’Etudes 2010-2011

3.3 Axes et Indicateurs ................................................................................................. 38

Projet de Fin d’Etudes 2010-2011

Le domaine de télécommunication demeure l’un des secteurs en plein progrès au Maroc en

Projet de Fin d’Etudes 2010-2011

1 Contexte général du projet

1.1 Nokia Siemens Networks

Projet de Fin d’Etudes 2010-2011

 Le pôle Network Planning : Il représente le cœur du travail de NSN Maroc. Il

1.2 Présentation du Projet

Projet de Fin d’Etudes 2010-2011

Figure 1 : Evolution annuelle du parc global de la téléphonie mobile

Projet de Fin d’Etudes 2010-2011

Figure 2 : Evolution des opérateurs de télécommunication au Maroc

Marché 2009 Marché 2010

Figure 3 : Parts de Marché

Projet de Fin d’Etudes 2010-2011

Projet de Fin d’Etudes 2010-2011

 Une facilité d’accès et d’utilisation.

1.3.4 Planification du projet

Figure 4 : Cycle de vie d’un projet décisionnel

Projet de Fin d’Etudes 2010-2011

 Mise en Place OBIEE, AWM

Figure 5 : Diagramme de Gantt de planification du projet

Projet de Fin d’Etudes 2010-2011

Les étapes Livrables

Projet de Fin d’Etudes 2010-2011

Analyse et spécification des besoins

2 Analyse et spécifications des besoins

2.1 Sources de données chez NSN

Figure 6 : Exemple de recharge à travers le service prépayé

Projet de Fin d’Etudes 2010-2011

2.1.1.1 Le rôle de l’IN dans le service prépayé

Figure 7 : Architecture du système de la recharge

Projet de Fin d’Etudes 2010-2011