Memoire Version Finale 1

REPUBLIQUE DE COTE D’IVOIRE
UNION-DISCIPLINE-TRAVAIL
___________________________________________________
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
MEMOIRE DE FIN D’ETUDE

Pour l’obtention d’un diplôme de
MASTER PROFESSIONNEL
GENIE INFORMATIQUE ET RESEAUX
CONCEPTION D'UN OUTIL DECISIONNEL

POUR LA GESTION EFFICIENTE ET L'ANALYSE
DE DONNEES MASSIVES : CAS D’UN GRAND
AEROPORT FRANÇAIS
Année académique: 2016-2017
Présenté par:
Mlle ADJAVOIN AMEGNINOU CAROLINE
Etudiante en Master Génie Informatique et Réseaux
Encadreur pédagogique Maître de stage

M. ZOGOURY MARC M. NICOLAS BLONDET
Enseignant à PIGIER Directeur des opérations
chez Link to Business
Techology
Conception d'un outil décisionnel pour la gestion efficiente et l'analyse de données massives
SOMMAIRE
SOMMAIRE .........................................................................................................................................I
DÉDICACE ........................................................................................................................................ II
SIGLES ET ABRÉVIATIONS .......................................................................................................... III
LISTE DES FIGURES.......................................................................................................................IV
LISTE DES TABLEAUX ................................................................................................................... V
LEXIQUES ........................................................................................................................................VI
REMERCIEMENTS ........................................................................................................................ VII
AVANT - PROPOS ....................................................................................................................... VIII
ABSTRACT .......................................................................................................................................IX
INTRODUCTION GÉNÉRALE ......................................................................................................... 1
PREMIERE PARTIE : GENERALITES ......................................................................................... 3
CHAPITRE-1. : PRÉSENTATION DE LA STRUCTURE D’ACCUEIL ............................... 4
CHAPITRE-2. : PRÉSENTATION ET CADRAGE DU PROJET .......................................... 7
DEUXIÈME PARTIE : ÉTUDE PRÉALABLE ............................................................................. 9
CHAPITRE-3. : ÉTUDE ET ANALYSE DE L’EXISTANT ................................................. 10
CHAPITRE-4. : PROPOSITION ET CHOIX DE SOLUTION ............................................. 12
TROISIEME PARTIE : ETUDE DETAILLEE DE LA SOLUTION RETENUE ....................... 18
PARTIE : ETUDE DETAILLEE DE LA SOLUTION RETENUE .............................................. 18
CHAPITRE-5. : ETUDE FONCTIONNELLE ....................................................................... 19
CHAPITRE-6. : ETUDE ORGANIQUE ................................................................................ 29
QUATRIEME PARTIE : IMPLEMENTATION ET DEPLOIEMENT DE LA SOLUTION ...... 53
CHAPITRE-7. : ETUDE TECHNIQUE ET RÉALISATION ................................................ 54
CHAPITRE-8. : DEPLOIEMENT ET PRESENTATION DU SYSTEME FINAL............... 62
CONCLUSION GENERALE ET PERSPECTIVES ......................................................................... 71
BIBLIOGRAPHIE ET WEBOGRAPHIE ................................................................................. LXXIII
ANNEXES ................................................................................................................................ LXXIV
TABLE DES MATIERES ........................................................................................................... XCIV
I
DÉDICACE
Ce document est dédicacé à ma famille.
II
SIGLES ET ABRÉVIATIONS
MAGIR: Master Génie Informatique et Réseau

CDP: Customer Data Platform
CRM: Customer Relationship Management

ETL: Extract Transform Load
RH: Ressources Humaines

PHP: Hypertext Preprocessor
HTML: HyperText Markup Language

2TUP: Two Tracks Unified Process
XP : eXtrem Program
MERISE : Méthode d’Etude et de Recherche Informatique par Sous-Ensembles
XUP: eXtrem Programming Unified Process

UML: Modèle Conceptuel des Données
RUP: Rational Unified Process

CSS: Cascading Style Sheets
SGBD : Système de Gestion de Base de Données
LTBT: Link To business Technology

FTP: File Transfert Protocol
III
LISTE DES FIGURES

Figure 1: Organigramme de Link to Business technology .................................................................. 6
Figure 2: Schéma du système actuel .................................................................................................. 10
Figure 3: Système d’information soumis à deux contraintes ............................................................. 26
Figure 4: Cycle de développement selon 2TUP................................................................................. 27
Figure 5: Formalisme d’un diagramme de cas d’utilisation .............................................................. 30
Figure 6: Diagramme des cas d’utilisation ........................................................................................ 31
Figure 7: Formalisme du diagramme de séquence............................................................................. 36
Figure 8: Diagramme des séquences .................................................................................................. 37
Figure 9: Formalisme du diagramme de classe .................................................................................. 38
Figure 10: Diagramme des classes ..................................................................................................... 39
Figure 11: Formalisme du diagramme d’état-transition .................................................................... 45
Figure 12: Diagramme d’activité du cas d’utilisation import de données ......................................... 46
Figure 13: Classe avec attribut ........................................................................................................... 47
Figure 14: Association un à plusieurs ................................................................................................ 48
Figure 15: Association plusieurs à plusieurs...................................................................................... 48
Figure 16: Modèle de données sous MySQL sous forme de modèle physique ................................. 50
Figure 17: Architecture générale du système ..................................................................................... 60
Figure 18: le diagramme de déploiement ........................................................................................... 63
Figure 19: Interface de connexion ..................................................................................................... 65
Figure 20: Interface d’import ............................................................................................................. 65
Figure 21: Interface de consultation des données .............................................................................. 66
Figure 22: Interface de l’exploration de données............................................................................... 66
Figure 23: Interface de transfert de segment vers XO-MATIC ......................................................... 67
Figure 24: Interface de XO-MATIC .................................................................................................. 68
Figure 25: Interface de API................................................................................................................ 68
IV
LISTE DES TABLEAUX

Tableau 1 : Niveaux d'abstraction et modèles MERISE .................................................................... 20
Tableau 2 : Principales implémentations du Processus Unifié .......................................................... 23
Tableau 3 : Etude comparative des méthodes d’analyse.................................................................... 24
Tableau 4 : Identification des cas d’utilisation .................................................................................. 29
Tableau 5 : Légende du formalisme de cas d’utilisation ................................................................... 30
Tableau 6 : Description des cas d’utilisation « consultation des données » ...................................... 32
Tableau 7 : Description des cas d’utilisation « import de données » ................................................. 33
Tableau 8 : Description des cas d’utilisation « Exploration des données » ....................................... 34
Tableau 9 : Description des cas d’utilisation « Export des données ». .............................................. 35
Tableau 10: Comparaison de quelques caractéristiques de WINDOWS et LINUX.......................... 44
Tableau 11 : Quelques correspondances Diagramme des classes-MCD ........................................... 47
Tableau 12 : Evaluation financière .................................................................................................... 69
V
LEXIQUES
XO-CDP : Nom de commercial donné par LTBT à la plateforme de gestion.
XO-MATIC : Nom de commercial donné par LTBT de l’outil de marketing automation

MAUTIC.
METABASE : est un logiciel open source permettant à tout un chacun d'explorer le contenu
d'une base de données et de mettre en corrélation les données entre elles. il est possible en
quelques secondes d'accéder à des données de manière individuelle ou d'aller plus loin en
explorant les autres données auxquelles elles sont rattachées.[]
MAUTIC : est un outil de Marketing Automation permettant de planifier et exécuter des

campagnes marketings. [14]
Traefik : c’est un proxy inverse HTTP et un équilibreur de charge modernes qui facilitent le
déploiement de micro services. [15]
Marketing : un état d’esprit, qui cherche à privilégier les attentes et les besoins des parties
prenantes de cette organisation (marchande ou non-marchande) par rapport aux attentes
et besoins des membres de celle-ci. [16]

Marketing digital : l’ensemble des techniques marketing utilisées sur les supports et canaux
digitaux. Le terme est probablement appelé à disparaître dans la mesure où le marketing à

tendance à devenir « par essence digital ». [17]
Campagne : un ensemble cohérent d’actions marketing entreprises sur une même période
et visant à promouvoir le même produit ou service. [18]
Data lakes : Un lac de données (en anglais data lake) est une méthode de stockage des
données utilisée par le big data (mégadonnées en français). Ces données sont gardées dans
leurs formats originaux ou sont très peu transformées. [19]

Datamart : c’est un sous-ensemble d’un datawarehouse destiné à fournir des données aux
utilisateurs, et souvent spécialisé vers un groupe ou un type d'affaire. [20]

Données en third party : sont généralement des données de ciblage publicitaire ou
marketing Internet qui sont fournies à l’annonceur par une société tierce autre que l’éditeur
utilisé comme site support pour une campagne.
VI
REMERCIEMENTS
La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes

à qui nous voudrions témoigner toute notre reconnaissance.
De prime abord, nous adressons notre reconnaissance à la Direction du Groupe Pigier Côte
d’Ivoire pour l’enseignement de qualité dispensé. Cette formation dans le parcours

informatique a su murir nos réflexions et a représenté une profonde satisfaction
intellectuelle.
Nous voudrions ensuite adresser toute notre reconnaissance à la Direction de Link to

Business qui nous a offert cette opportunité en milieu professionnel.
Nous adressons donc nos sincères remerciements à nos deux encadreurs de ce travail, à
savoir Monsieur Marc Zogoury, notre encadreur pédagogique, et Monsieur Nicolas

Blondet, pour leur disponibilité et surtout leurs conseils judicieux, qui ont contribué à
alimenter notre réflexion.
Nous ne pouvons oublier les enseignants ayant intervenu dans notre formation,
particulièrement Docteur KADJO Tanoh Lambert pour ses nombreux conseils pour la
finalisation de ce manuscrit
Nous adressons un grand merci à notre binôme Romain Laisné qui fait partie des premières
personnes à nous faire découvrir le sujet de notre mémoire.

A Monsieur Franck Grimonpont, Monsieur Koné Ousmane et toute l’équipe nous leur
témoignons notre gratitude pour les conseils judicieux.
Les intervenants et toutes les personnes qui par leurs paroles, leurs écrits, leurs conseils et
leurs critiques ont guidé nos réflexions et ont accepté de nous rencontrer et de répondre à
nos questions durant les recherches.
Nous présentons nos remerciements, nos respects et notre gratitude.
VII
AVANT - PROPOS
Le Groupe Pigier Côte d’Ivoire est l’une des plus anciennes grandes écoles de Côte
d’Ivoire. Il comptabilise plus de 50 ans d’expérience en matière de formation de haut niveau.

Ses diplômes sont reconnus par le CAMES et ouvrent les portes à plusieurs opportunités. Le
Groupe Pigier Côte d’Ivoire donne des formations dans les parcours Licence professionnelle
et Master professionnel dans différentes disciplines : Informatique, Marketing et
Comptabilité financière.
Par ailleurs, Pigier Côte d’Ivoire forme des ingénieurs capables de relever les défis futurs, et
répondre aux exigences du marché de l’emploi. Il s’attèle à dispenser un enseignement de
qualité à ses étudiants. La formation du Master Génie Informatique et Réseaux qui nous
concernent offre de nombreuses opportunités en matière de Technologies de l’Information
et de la communication.
Cette formation se déroule en deux phases : La première concerne des cours théoriques et
travaux pratiques pour l’acquisition des fondements indéniables pour un ingénieur accompli.
La deuxième phase porte sur un stage de production et des projets de fin d’études exigés
dans le cursus afin de parfaire la formation.
A cet effet nous avons effectué un stage chez Link to business Technology afin de parachever
notre formation, sanctionnée par le présent mémoire.
Durant ce stage nous avons été confrontés au défi de la gestion de projets jusqu’à la
réalisation à travers le thème suivant « Conception d'un outil décisionnel pour la gestion
efficiente et l'analyse de données massives : Cas d’un grand aéroport français».

Le présent mémoire expose les résultats de l’étude que nous avons réalisée.
VIII
ABSTRACT
One of the largest French airport, ranked in the ten most frequented, has decided to
centralize its information system. Those informations comes from, among other things, the
website of the organization, Excel files containing the details of newsletters, free wifi access
points, travel reservations, parking subscriptions, etc. Previously the data was operated
manually from the Excel files which was very tedious.
The shortcomings associated with this system are due to the amount of data collected
over the years. This makes it difficult to exploit the information because of the amount of
data collected and the file format of that data. However, several questions raise our interest:
how to exploit those data coming from the different sources? How do you sort and organize
them to best use them as part of an efficient marketing strategy? There is, therefore, a need
for a computer solution to overcome these difficulties and facilitate the work of the airport.
This is the reason why, in the framework of our master dissertation, we have decided
to work on the following theme: "Designing a Business Intelligence tool for efficient
management and the analysis of massive data: the case of a French airport". The expected
purpose of this project is the realization of a Customer Data Platform (abbreviated "CDP").
However, the use of agile methods with the Jira and Github platform has been an
ongoing guide in the proper conduct of this project. The CDP (Customer Data Platform)
designed in PHP with the Symfony framework integrated into the Docker container can
respond to the need by providing the services of uniform data aggregation according to
data model in the database, METABASE connected drill, the BI tool for segment realization
and Marketing automation connected to MAUTIC for behavioral analysis that leads to the
proposition of a better offer or communication to customers.
The realized tool is presented as a solution for an improvement of the productivity of

the airport. First, it allows the centralization and automation of the process, previously
manual in addition to the use of information in an efficient manner. Then the system
automatically records the data of the airport site; for example, when a customer registers for
the first time this information is stored in the CDP database and a welcome message is sent
to him. Finally, it also allows sending emails or SMS to registered contacts according to the
defined marketing strategy; for example when the car park reservation will soon expire or a
subscription a notification is sent to the contacts.
The deployment also complies with the standard two-thirds (2 thirds) and is hosted
on the OVH server that it is accessible simultaneously by several users.
IX
INTRODUCTION GÉNÉRALE
C’est dans un environnement fortement complexe et hautement concurrentiel

qu’évolue la majeure partie, si ce n’est la totalité, des entreprises. Ce climat de forte
concurrence exige de ces entreprises une surveillance très étroite du marché afin de ne pas
se laisser distancer par les concurrents et cela en répondant, le plus rapidement possible,
aux attentes du marché, de la clientèle et de leurs partenaires.
Pour se faire, les dirigeants d’entreprises, quel que soit d’ailleurs le domaine
d’activités, doivent être en mesure d’orienter leur politique dans le sens des attentes des
consommateurs. Ils devront prendre notamment les décisions les plus opportunes. Il s’agit
de prendre des décisions fondées, basées sur des informations claires, fiables et pertinentes.
Le problème est donc de savoir comment identifier ces informations et les présenter à qui
de droit.
Cette tâche est relativement complexe, sachant que les entreprises croulent d’une
part sous une masse considérable de données (internes et externes) et d’autre part les
systèmes opérationnels « transactionnels » s’avèrent limités, voire inaptes à fournir de telles
informations et constituer par là même un support à la prise de décision.

C’est dans ce contexte que les « systèmes décisionnels » ont vu le jour. Ils offrent aux
décideurs des informations de qualité sur lesquelles ils pourront s’appuyer pour arrêter leurs
choix décisionnels. Désormais, la démarche décisionnelle se développe dans des secteurs
différents : e-commerce, grande distribution, médecine ou encore dans le marketing.

De nouveaux outils gestion de données ont vu le jour afin de répondre aux besoins
décisionnel dans chaque domaine. Ces outils permettent d’agréger des données de sources
multiples. Dans le domaine du marketing, le but est de cerner par exemple les
comportements des internautes pour mieux les cibler, adapter les messages et optimiser les
campagnes.
C’est pourquoi Link To Business l’éditeur de solution marketing XO propose à l’un des
plus grands aéroports de la France classé parmi les 10 aéroports les plus fréquentés au
monde [13], l’une de ses solutions marketing.
1
En effet, cet aéroport cumule chaque année, de nombreuses données de leurs clients.
Ces données sont enregistrées dans des fichiers. Ainsi, au fil des années elles sont de plus
en plus difficiles à exploiter vu le volume de données et les multiples formats à prendre en

compte.
Dans le souci de transformer ces données recueillies en des données globalement

exploitables et afin de mieux cerner le comportement de ses clients, un projet a été initié. .
Notre participation à ce projet est libellé sous : « Conception d'un outil décisionnel pour
la gestion efficiente et l'analyse de données massives : Cas d’un grand aéroport
français ».
L’objet de ce mémoire est donc de présenter l’aboutissement de notre travail et pour
ce faire, nous avons jugé indispensable de le charpenter autour de quatre parties.

La première partie intitulée ‘Généralités’, met le projet dans son contexte par la
présentation de la structure d’accueil ainsi que la présentation du projet proposé.

Dans la deuxième partie intitulée ‘Etude préalable’, nous ferons premièrement
l’analyse de l’existant et deuxièmement nous ferons des propositions de solutions qui sera
conclu par le choix d’une solution adaptée selon notre cahier de charges. Cette partie pose
également les bases nécessaires à la compréhension de la suite de notre travail.

Dans la troisième partie intitulée ‘Etude détaillé de la solution retenue’, nous ferons
premièrement une étude fonctionnelle où nous présenterons d’une part les méthodes
d’analyses et de conception choisies et d’autre part le choix de la méthodologie suivie de
une description de la méthode choisie.

La dernière partie intitulée ‘Réalisation’, présentera premièrement l’étude technique
et l’implémentation puis le déploiement du système global ainsi que quelques captures

d’écrans. Elle proposera ensuite une évaluation financière.
2
PREMIERE PARTIE : GENERALITES
Dans cette partie nous présentons l’environnement dans lequel le projet est exécuté et nous
expliquerons le thème soumis à notre étude.
3
CHAPITRE-1. : PRÉSENTATION DE LA STRUCTURE D’ACCUEIL
Nous présenterons dans ce chapitre, les activités et infrastructures informatiques de Link

to Business, la structure qui nous a accueillis pour ce projet.
1.1 PRÉSENTATION DE LINK TO BUSINESS

Fondée en 2000, Link to Business est une société à responsabilité limitée en activité
depuis 19 ans. Implantée à GRENOBLE (38100), elle est spécialisée dans le secteur d'activité
de la programmation informatique et propose des activités diverses dans le domaine du
marketing. [1]
La société regroupe deux filiales distinctes :
 Link to Business Bâtiment : agence de conseil en marketing opérationnel et relationnel

spécialisée dans le bâtiment.
 Link to Business Technology : conception et développement de solutions web

personnalisées et notamment d’une plateforme de marketing relationnel autrement
appelée plateforme Marketing XO (datant de 2010).
1.1.1 MISSIONS
Chaque filiale intervient dans ses missions différentes présentées comme suit:
 La filiale Bâtiment met à disposition de ses clients des services de conseils
stratégiques, de marketing opérationnel, de web marketing et de communication. Elle
offre également la possibilité, dans le cadre de leur accompagnement marketing,
d’acquérir une plateforme dédiée à l’animation de leur réseau de distribution et

produite par Link to Business Technology.
 La filiale Technology est dédiée à la création de solutions web basées sur des produits
configurables et adaptables. Elles sont sur mesure et se démarquent des solutions
dites « prêt à porter ». Ces services permettent aux clients d’automatiser et de

simplifier les actions marketing et de communication au sein de leur propre réseau
de distribution tout en assurant un suivi et un contrôle constant et global de l’activité

de ce même réseau. Produit phare de Link to Business, la plateforme Marketing XO
est aujourd’hui installée sur plus d’une trentaine de réseaux de distribution dans des
4
secteurs variés allant de l’automobile (Total) à l’alimentaire (Carrefour) en passant par
le bâtiment (Somfy).
Intervenant dans de nombreux domaines, Link to Business se place donc au centre d'une
dynamique efficace, et se donne pour objectif de devenir un leader du marketing relationnel
local en proposant des services permettant l'optimisation et la simplification de la

communication entre une entreprise et son réseau de distribution:
 XO-CDP, Customer Data Platform, pour centraliser votre connaissance client.

 XO-Retail plateforme Marketing, pour automatiser le Marketing Local de votre réseau
de distribution.
 XO-MATIC, outil de Marketing Automation pour personnaliser votre relation et vos
offres avec chaque client, et acquérir de nouveaux clients.

L’axe stratégique de l'entreprise est de rendre non complexe pour l'utilisateur (Expérience
utilisateur UX) les fonctions à fortes valeurs ajoutées du Marketing Automation.
1.1.2 ORGANISATION
Link to Business est implantée non seulement à Grenoble, en Auvergne-Rhône-Alpes,

où se trouvent son siège et une grande partie de ses effectifs mais aussi en région parisienne
avec une agence chargée de la communication dans le secteur du bâtiment. De plus, une
équipe de développeurs participant au développement web en général et, plus
spécifiquement, à celui des plateformes marketing proposées par la société, est située à
Abidjan en Côte d'Ivoire.
Résultant de la variété des services proposés par l'entreprise, on retrouve des salariés
partagés entre les secteurs Bâtiment et Technology.
5
La figure ci-dessous (Figure 1) présente l’organigramme de Link To Business Technology.
Figure 1: Organigramme de Link to Business technology
NB : Des développeurs indépendants interviennent pour certains projets
1.2 PRÉSENTATION DU SERVICE D’ACCUEIL

La filiale Link To Business Côte d’Ivoire a été créée en septembre 2017. Elle vient en appui
à l'équipe Link to Business Technology pour ses différentes activités. Link to business Côte
d’Ivoire est en charge du développement des plateformes de Link To business Technology

en Côte d’Ivoire. Les nouvelles fonctionnalités d’un nouveau client ou les modifications
provenant du retour des clients sont gérées par l’équipe de développement de Côte d’Ivoire.
Elle est composée de développeurs dont des séniors et des juniors.
Ce chapitre nous a permis de présenter Link To Business et de décrire son activité. Nous
présenterons dans le chapitre suivant la présentation du projet.
6
CHAPITRE-2. : PRÉSENTATION ET CADRAGE DU PROJET
Dans ce chapitre, nous expliciterons de prime abord l’aspect organisationnel du projet visant
à cerner les exigences du client. Nous en ciblerons ensuite les contours, afin d’en
appréhender la complexité et d’établir un plan de gestion optimisé pour le mener à bien.
2.1 CONTEXTE
L’un des grands aéroports français classé parmi les 10 les plus fréquentés du monde [13]
sollicite l’expertise de notre structure dans le cadre de ses activités. En effet, cet aéroport
gère plusieurs activités en son sein et possède des informations diverses sur ses clients. Ces
données sont stockées dans des systèmes tiers et des fichiers Excel et concernent :
 le site web de la structure,
 les abonnements à la newsletter,
 les inscriptions au point d’accès wifi gratuits,
 les informations de réservations de voyages,

 les informations de réservation et d’abonnement de parking.
En effet, le volume actuel et le format en fichier de ces données rendent difficile le
réassemblage des fichiers et l’exploitation des informations pertinentes sur un client. Par
conséquent elles étaient difficilement utilisées. Cela freine l’aéroport sur la recherche
d’informations pertinentes pour faire de la connaissance client. Telle est la raison pour
laquelle, le projet ayant pour thème : « Conception et mise en exploitation d'un outil
décisionnel pour la gestion efficiente et l'analyse de données massives: Cas d’un grand
aéroport français», nous a été soumis.
2.2 DOMAINE D’ACTIVITÉ CONCERNÉE

Le domaine d’activité est le marketing et la communication avec : Data processing +
datawarehouse + Business Intelligence.
7
2.3 OBJECTIFS DU PROJET
Le présent travail permettra d’analyser les différentes possibilités:

 l’extraction de ses informations depuis des fichiers automatiquement générés par les
systèmes tiers (système d'abonnement des parkings, système de réservation de

voyages, etc...);
 la transformation des données de sorte qu’elles correspondent au modèle de

données souhaité et enfin de charger ces informations dans une base de données;
 la centralisation des informations constituant la connaissance clients de l’aéroport;

 l'analyse comportementale qui conduit à la proposition d'une meilleure offre ou
communication à la bonne personne ;

 la construction des offres marketing et commerciales adaptées aux clients.
2.4 REVUE DOCUMENTAIRE

Pour mener à bien notre projet, nous avons eu besoin de certaines personnes ressources et
des documents qui ont contribué à la rédaction du mémoire. Nous avons dans un premier
temps approché le Directeur des opérations.
 La première étape était une réunion dans laquelle les grandes lignes du projet ont
été données ;
 Il s’en suit par la remise de dossier contenant des fichiers de l’aéroport qui allait nous
servir de sources pour démarrer le projet ;
 Des échanges avec des spécialistes du domaine nous ont permis de collecter des
informations pertinentes pour notre thème ;
 Ces spécialistes sont les professeurs et des personnes dans le domaine de
l’informatique décisionnel;
 Nous avons approfondi nos recherches en parcourant des documents numériques en

ligne et des livres et mémoires issus de la bibliothèque.
Nous avons présenté dans ce chapitre, les besoins que nous avons recueillis et la démarche
pour y aboutir. Après les différentes présentations, nous ferons ensuite une étude préalable
du système existant.
8
DEUXIÈME PARTIE : ÉTUDE

PRÉALABLE
Dans cette partie nous ferons une analyse du système existant en prélude, ensuite nous
apporterons nos critiques puis nous proposerons des solutions et enfin faire un choix de
solution la plus adaptée.
9
CHAPITRE-3. : ÉTUDE ET ANALYSE DE L’EXISTANT
Dans cette partie nous allons décrire l’existant, ensuite nous ferons une analyse.
3.1 ETUDE DE L’EXISTANT

L’ensemble des procédures décrites ci-dessous sont manuelles.
3.1.1 Description du système actuel

Un grand aéroport français classé parmi les 10 premiers les plus fréquenté du monde
gère plusieurs activités en son sein et possède des informations diversifiées de ses clients.
Ces données sont répertoriées dans des fichiers Excel et permettent de gérer:
 le site web de la structure;
 des newsletters;
 les points d’accès wifi gratuits;
 les réservations de voyages;

 les abonnements de parking, etc.
 Les informations des fichiers sont traitées avec des formules Excel
3.1.2 Modélisation du système actuel (État des lieux)

Ce schéma ci-dessous (figure 2) décrit l’interaction entre le client de l’aéroport et
l’outil Excel. L’utilisateur est chargé de renseigner les informations dans un classeur Excel.
Figure 2: Schéma du système actuel
3.2 CRITIQUE DE L’EXISTANT

Après description de l’existant, des atouts et insuffisances sont à dégager.
 Forces
Les atouts du système existant sont les suivants :
10
 l’utilisation du logiciel Excel rend accessible pratiquement à n’importe quel emploi, la
manipulation d’une base de données.
 Faiblesses
Les insuffisances répertoriées sont les suivantes :
 L’outil utilisé pour le traitement des informations ne supporte pas de gros volume de
données ;
 Le volume de données augmente considérablement. Ce qui ne favorise pas un

traitement manuel ;
 Les données ne sont plus utilisées de manière optimum car elles sont départagées
dans des fichiers différents et très volumineux ;
 Le format des données n’est pas facilement exploitable par certaines applications
métiers;
 Les données sont délaissées car difficile à exploiter pour les besoins en temps réels.
Dans ce chapitre nous avons décrit le système existant et relevé ces insuffisances. Alors, il
serait intéressant de proposer une solution afin de pallier aux insuffisances de l’ancien
système utilisé. Ce sera l’objet du chapitre suivant.
11
CHAPITRE-4. : PROPOSITION ET CHOIX DE SOLUTION

A la suite de l’analyse nous donnerons une ébauche de solution en fonction des
besoins.
4.1 ÉBAUCHE DE SOLUTIONS

D’après les besoins énumérer dans le chapitre précédent, l’aéroport souhaite connaître
d’une manière intégrale les clients ou prospects de l’aéroport. Les solutions de CRM, DMP
et CDP, sont toutes des solutions de la collecte des données et leur. Les spécificités de
chacun(e) de ces outils ou plateformes permettront de les comparer.
4.1.1 Première solution

La première solution proposée est le Datawarehouse car elle est une base de données
permettant de stocker des données historiques structurées non volatiles orientées sujet afin
de les analyser. [24]
4.1.1.1 Description de la solution

Datawarehouse se traduit en français par « entrepôt de données ». Il s’agit d’un lieu
de stockage de toutes les données (clients ou non). Ces données sont chargées suivant un
processus ETL, si bien que les données d’un Datawarehouse sont structurées à leur entrée
dans le système (contrairement aux données des data lakes). En général, les Datawarehouses
sont compartimentés, chaque compartiment regroupant les données répondant à un

ensemble de besoins précis (RH, juridique, ventes, marketing…). Ces compartiments sont
appelés « Datamarts ». [22]
4.1.1.2 Avantages
 Elle permet de séparer les processus analytiques des processus d’exploitation
 Elle permet de visualiser le passé sans affecter les opérations quotidiennes.
4.1.1.3 Inconvénients
 Le marketing n’a pas les compétences requises pour gérer un Datawarehouse.
 les Datawarehouses ne sont pas alimentés en temps réel. Ce qui peut poser un
problème concernant la qualité des données.
12
4.1.2 Deuxième solution
La deuxième solution proposée est le CRM (Customer Relationship Management),
elle est un outil de gestion de la relation client. [23]

Les CRM sont des outils de gestion de la relation client utilisés dans les domaines de
la vente directe et de la fidélisation depuis les années 90. Leur but est de centraliser la
connaissance client autour d’un identifiant CRM en vue d’améliorer la qualité de la relation
client. Sur le plan de la donnée marketing, le CRM offre une vision nominative des clients et
des prospects. [22]
4.1.2.2 Avantages
 Le CRM permet d’automatiser les actions de vente et de fidélisation auprès
d’individus identifiés permettant de gagner en productivité et en compétitivité.

 Les données du CRM permettent d’engager des actions de marketing
direct rapidement (campagnes emailing, SMS).

 Aucune compétence technique (Business Intelligence, Data Mining) n’est nécessaire
pour exploiter ces données.
 Le CRM est limité aux données offline (n’agrège pas les données des cookies par
exemple).
 Le CRM est un outil « simple canal » uniquement contrairement aux plateformes
cross/multi/omni canal.
 Le CRM est limité aux données structurées uniquement (ce qui représente une part
très faible des données clients disponibles).
4.1.3 Troisième solution
La troisième solution proposée est la DMP (Data Management Platform). C’est un
accumulateur de données. [23]
13

La Data Management Platform (DMP) est un agrégateur de données anonymes réconciliées
autour du cookie. Par simplification, nous pouvons la représenter comme une très grande
base de données. La DMP est conçue pour mieux opérer les campagnes digitales
(programmatiques) dans un monde ouvert. La DMP repose sur des technologies Hadoop1,
Hbase2, Map Reduce3 et consorts et elle offre une vision statistique des visiteurs et des
audiences. [22]
4.1.3.2 Avantages
 Le ciblage précis d’une audience
 L’intégration d’une DMP est plus simple et moins coûteuse qu’une CDP
 La DMP permet de se séparer des agences publicitaires et d’avoir un accès direct à

des données précises afin de gérer des actions marketing les plus pertinentes (canal,
bannières)
 Les cookies collectés peuvent provenir de sites propriétaires (first-party data) comme
de sites affiliés (third-party data)
 Certaines DMP ont des connecteurs avec des outils tiers de type CRM, marketing
automation (comme Marketo) et avec des DSP
 Elle permet aussi de calculer le retour sur investissement (ROI) des campagnes par
canal
 Il manque des données offline pour atteindre l’objectif de connaissance client (valeur
hors média).
 La durée de conservation des données est de quelques mois seulement. C’est trop
court pour comprendre le cycle de vie d’un client.

 Les données ne sont pas nettoyées (données brutes et parfois en doublons) rendant
leur accès et leur activation marketing plus complexe que dans une CDP.
1 Hadoop : un framework libre et open source écrit en Java destiné à faciliter la création d'applications
distribuées et échelonnables permettant aux applications de travailler avec des milliers de nœuds et des
pétaoctets de données.
2 Hbase : HBase est un système de gestion de base de données non-relationnel distribuée, écrit en Java,
disposant d'un stockage structuré pour les grandes tables.

3 Map Reduce : créé par Google, est l'un des principaux Framework de traitement de données Big Data.
14
 Il n’y a pas ou rarement la possibilité de mettre en place des actions de marketing
direct depuis une DMP.
 Les fonctions de Data Mining ou de machine Learning ne sont pas ou très peu
présentes.
 La DMP est intéressante uniquement à partir de 100 000 cookies collectés.

 Elle n’offre pas de vraie gestion des données en temps réel.
4.1.4 Quatrième solution
La quatrième solution proposée est la CDP (Customer Data Platform) est une nouvelle
solution pour tout connaître sur son client. [23]

La Customer Data Platform (CDP) est une solution d’agrégation et de mise en action de
toutes les données clients online et offline. La CDP, née en 2013 du concept de David Raad4,
permet de créer une connaissance intégrale du client. Tout comme la DMP, la CDP prend
toute sa puissance en programmatique (médias), mais permet cependant d’activer d’autres

leviers marketing. La CDP offre une vision individuelle des clients, prospects et visiteurs.
4.1.4.2 Avantages
 Elle permet d’optimiser les campagnes multi canal et le « reach5 ».
 Elle permet à des professionnels du marketing de manipuler facilement des données

(vs professionnels de la Business Intelligence pour les DMP).
 Elle offre une vue à 360° du client et offre un levier de ciblage très précis.
 La CDP permet de créer des segments précis et d’analyser les comportements d’achat.
 Elle permet d’analyser le ROI multicanal de manière précise et des répercussions entre
canaux.
 Elle facilite la mise en conformité avec le règlement européen sur la gestion des
données personnelles (RGPD) obligatoire à partir de mai 2018 : centralisation
des données personnelles, livraison des données sur demande et purge des données.
4 David Raad :
5 Reach est la couverture d'une campagne, d'un site ou d'un réseau
15
Intégration complexe : la mise en place d’une CDP mobilise une partie importante de
l’entreprise pendant 3 à 6 mois (métiers, Direction des Systèmes d’information, managers,

département juridique).
4.2 CHOIX DE LA SOLUTION

Nous avons vu que ces technologies de Data Management étaient différentes voire très
différentes les unes des autres. Il est important d’avoir en tête les principales spécificités de
ces différents systèmes et bien savoir, par exemple, que : [12]
 Une CDP peut être intégrée avec tous les systèmes, y compris la DMP.
 La CDP permet de réellement disposer d’une vue à 360° de ses clients, contrairement
au CRM et à la DMP.
 La CDP ingère des données brutes et les organise autour de profils clients.
 La DMP utilise des données très fines mais avec des durées de vie limitées.
 La CDP peut collecter des données sur tout le cycle de vie client.
 Le CRM n’intègre pas les données comportementales et transactionnelles.
La compréhension de ces spécificités est évidemment indispensable dans le choix des outils
et des technologies de gestion des données.

Si, par exemple, nous souhaitons surtout cibler et recibler des internautes anonymes
correspondant à votre cible dans le cadre de campagnes publicitaires, la DMP peut être
l’option la plus appropriée.
Si vous souhaitez nourrir une Relation Clients dans la durée, travailler sur la fidélisation et
l’allongement de la lifetime6 de vos clients existants, le CRM convient mieux.
D’après le cahier de charges, nous optons pour le choix de la CDP car l’objectif de notre
étude repose sur la construction d’une Relation Clients unifiée et homogène sur tous nos
canaux, et proposez à vos clients une expérience client omnicanale.
6 Lifetime : temps de vie
16
La CDP doit être envisagée car c’est là que réside la valeur ajoutée de la CDP : elle est l’outil
le plus perfectionné pour déployer une stratégie omnicanale.
Le choix d’implémenter une Customer Data Platform doit s’inscrire dans le cadre de notre
projet car nous avons une vraie réflexion sur les parcours clients cibles, sur l’expérience
souhaitée qui sera délivré au client, sur les programmes relationnels que nous souhaiterons
activer. Il est important de faire les choses dans l’ordre :

 Définir vos objectifs de Relation Clients / de marketing client.
 Bien comprendre les parcours des clients existants et envisager les axes
d’amélioration en imaginant des parcours cibles.
 Identifier les moments de vérité sur ces parcours, c’est-à-dire les points de contact
sur lesquels vous devez être particulièrement performants.
 Construire un plan relationnel et la série de programmes relationnels associés pour

atteindre vos objectifs marketings et améliorer l’expérience client, en priorité sur les
moments de vérité.
Suite à l’analyse de l’existant, nous avons proposé des solutions et retenue une qui fera
l’objet d’une étude détaillé dans la partie suivante.
17
TROISIEME PARTIE : ETUDE

DETAILLEE DE LA SOLUTION
RETENUE
Dans cette partie, nous présentons les différentes méthodes d’analyse et de conception,
suivis des choix opérés. Nous exposons enfin les différentes étapes de la conception du
système.
PARTIE : ETUDE DETAILLEE DE LA
SOLUTION RETENUE
18
CHAPITRE-5. : ETUDE FONCTIONNELLE
L’étude préliminaire est la première partie de notre processus de développement. Elle
consiste à faire un premier repérage, en utilisant principalement du texte, ou des

diagrammes très simples. Ainsi ce chapitre présentera-t-il d’une part les différentes
méthodes d’analyses et de conception, suivies des choix que nous avons opérés.
5.1 MÉTHODE D’ANALYSE ET DE CONCEPTION DU SYSTÈME

La mise en place un Système d’Information Informatisé (SII) impose de recourir aux
méthodes d’analyse et de conception. Ils sont des guides continus pour la réalisation d’un
projet. Il existe plusieurs méthodes d’analyse, mais nous ne présenterons que les deux
méthodes les plus utilisés, notamment Merise et Processus Unifié.
5.1.1 Merise
MERISE, est une méthode systémique de conception de Système d’Information, définie
comme Méthode d’Etude et de Recherche Informatique par Sous-Ensembles. Elle est à sa
deuxième génération: MERISE2.

Le principe de MERISE est l’étude séparée des données et des traitements à travers plusieurs
modèles d’abstractions. Une validation permet de vérifier que tous les traitements
nécessaires à l’acquisition des données sont prévus et que toutes les données utiles à la
réalisation des traitements sont présentes dans l’objectif d’assurer une cohérence entre les
données et les traitements.
Pour la réalisation d’un projet, MERISE s’appuie sur trois axes:
5.1.1.1 La démarche ou le cycle de vie

C’est le guide continu de la méthode MERISE suivant six étapes qui sont :
 Le schéma directeur ;
 L’étude préalable ;
 L’étude détaillée ;
 L’étude technique ;
 La mise en œuvre et la maintenance.
19
5.1.1.2 Le Raisonnement ou le cycle d’abstraction;

C’est la représentation du domaine étudié, à travers plusieurs modèles suivant un formalisme
en tenant compte du niveau d’abstraction.
5.1.1.3 La maîtrise ou le cycle de décision.

A chaque étape de la démarche, une décision est prise pour l’avancement du projet. Le
tableau ci-dessous (tableau 1) décrit les niveaux d’abstractions et les modèles
correspondants.
NIVEAU PREOCCUPATION MODELES
DONNEES TRAITEMENTS
Conceptuel Qu’est ce qui est fait MCD MCT
? Quoi ? Signification des Activité du
informations sans domaine sans
contraintes préciser les
techniques ou ressources ou leurs
économiques organisations
Organisationnel Qui fait quoi ? MOD MOT
Quand ? Où ? Signification des Fonctionnement
informations avec du domaine avec
contraintes les ressources
organisationnelles utilisées et leurs
et économiques organisations
Logique Avec quoi ? MLD MLT
Description des Fonctionnement
données tenant du domaine avec
compte de leurs les ressources et
conditions leurs organisations
d’utilisation par les informatiques
traitements
Physique Avec quels moyens ? MPD MPT
Comment ? Description de la Architecture
ou des bases de technique des
données dans la programmes
syntaxe du logiciel
SGBD
Tableau 1 : Niveaux d'abstraction et modèles MERISE
20
5.1.2 UML et le processus Unifié
UML est un langage de modélisation unifié en français, né de la fusion des trois méthodes
qui ont le plus influencé la modélisation objet au milieu des années 90. Ces méthodes sont
OMT de James Rumbaugh, OOD de Grady Booch et OOSE d’Ivar Jacobson. C’est un langage
graphique qui permet de représenter les divers aspects du système d’information. En 1995,
on assiste à la naissance d’UML 1.0 qui compte neuf (9) diagrammes.
Depuis que UML 2.0 est apparu en 2003, nous en sommes à treize (13) diagrammes.
N.B : Pour plus de détails sur les diagrammes d’UML, voir l’Annexe 1
Le Processus Unifié est une méthode générique de développement qui fusionne le
traitement des données avec de celui des opérations. Il permet d’analyser, de concevoir et
de réaliser des solutions logicielles techniques, mais peut très bien prendre en compte tout
comme Merise les solutions logicielles orientées vers la gestion des systèmes d’information.
Les caractéristiques du Processus Unifié sont les suivantes:
 Piloté par les cas d’utilisation ;

 Centré sur l’architecture ;
 Utilise le langage de modélisation UML (Unified Modeling Language) ;
 Itératif et incrémental.
La démarche du Processus Unifié est composée de quatre (4) phases :
 Le démarrage : définition du champ d’action du projet. Elle est réalisée par

identification des cas d’utilisation.
 L’élaboration : spécification du plan du projet, des exigences et des bases de
l’architecture. Le plan est spécifié en un plan d’itérations.
 La construction : réalisation du produit.

 La transition : test, validation et transfert du produit vers les utilisateurs
finaux.
Chaque phase inclut une évaluation en vue de la validation de la recette.
21
5.1.2.1 Déclinaisons du Processus Unifié

Le Processus Unifié étant générique, i.e. pouvant être adapté selon le projet et
l’environnement de travail, plusieurs déclinaisons en découlent avec des caractéristiques

différentes telles que RUP, XUP, 2TUP, OPENUP, etc.
Le tableau ci-dessous (tableau 2) suivante présente les principales variantes du Processus

Unifié, singulièrement : RUP, 2TUP, XUP.
DECLINAISONS DESCRIPTION AVANTAGES INCONVENIENTS
Instanciation d’UP Itératif Coûteux à

par Rational Spécifie le personnaliser
Software (IBM) dialogue entre les Très axé processus,
Le RUP est à la fois différents au détriment du
RUP une méthodologie intervenants du développement :
Rational Unified et un outil prêt à projet : les peu de place pour
Process l'emploi livrables, les plans le code et la
(documents types de travail, les technologie.
partagés dans un prototypes.
référentiel Web) Propose des
Cible des projets modèles de
de plus de 10 documents, et des
personnes canevas pour des
projets types.
Instanciation Itératif Ne couvre pas les
hybride intégrant Simple à mettre en phases en amont
UP avec l’Extrem Œuvre et en aval au
Programming Fait une large développement :
Ensemble des place aux aspects capture des
XUP meilleures techniques : besoins, support,
eXtrem pratiques de prototypes, règles maintenance, tests
Programming développement de développement, d'intégration
Unified Process (travail en équipe, tests… Elude la phase
transfert de d'analyse, si bien
compétences…) qu'on puisse
Cible des projets dépenser son
de moins de 10 énergie à faire et
personnes. défaire
Assez, confus dans
sa mise en œuvre:
quels intervenants,
quels livrables.
22
Suite du tableau des principales implémentations du Processus Unifié
DECLINAISONS DESCRIPTION AVANTAGES INCONVENIENTS
Instanciation d’UP,  Itérative Superficiel sur les

proposée par  Fait large place à phases situées en
Valtech prenant en la technologie et à amont et en aval
compte les aléas et la gestion du du développement
contraintes liées risque : captures des
aux changements  Définit les profils besoins, support,
perpétuels et des intervenants, maintenance,
rapides des SI des les plans de travail, gestion des
entreprises les prototypes changements, etc…
S’articule autour Ne propose pas de
de l’architecture documents types
Propose un cycle
de développement
en Y
 Cible des projets
2TUP de toutes tailles
Tableau 2 : Principales implémentations du Processus Unifié
5.2 ETUDE COMPARATIVE ET CHOIX DE LA METHODE D’ANALYSE

Le tableau suivant présente l’étude comparative entre Merise et PU, que nous avons
effectuée afin de choisir la méthode d’analyse et de conception, la mieux adaptée
à notre projet.
 Tableau comparatif
CRITERES MERISE PROCESSUS UNIFIE
Méthodologies Séquentielle Cycle de vie itératif et

incrémental
Traitement des données Analyse séparée données Regroupement des traitements

et et des traitements. des données et opérations au
Opérations sein des classes. Application du

principe de l’encapsulation des
méthodes orientées objets.
23
Suite du tableau de l’étude comparative des méthodes d’analyse
CRITERES MERISE PROCESSUS UNIFIE
Niveaux d’abstraction Plusieurs niveaux: Niveau unique mais plusieurs

conceptuel, logique, types de modèles en fonction
organisationnel, physique de l’aspect à décrire.

avec plusieurs types de Affinement des modèles lors
modèles : données, des différentes étapes de

traitements, l’analyse et de la conception.
communication. Existence Continuité entre les différentes

de règles de passage phases d'élaboration de
entre les différents l'application (traçabilité).

niveaux.
Gestion de projet Concentré principalement Prise en compte de tous les
sur la conception, sans stades de la conduite d'un

prise projet. Cohérence de la phase
en compte de la phase de d’analyse jusqu’au code du

programmation (modèle programme.
de déploiement et de
composants absent).
Tableau 3 : Etude comparative des méthodes d’analyse
5.3 JUSTIFICATION DU CHOIX

L’analyse du tableau ci-dessus permet de faire ressortir plusieurs points. D’une part,
il est notoire que Merise offre une démarche d’analyse cohérente et rigoureuse, et est mieux
orientée vers la gestion des systèmes d’information avec stockage des données dans des
bases de données relationnelles. Ensuite, nous constatons que le Processus Unifié utilisant
UML qui est basé sur l’approche objet, est très souvent utilisé dans l’informatique technique
(temps réel) et dans les projets évolutifs c’est à dire pouvant avoir différentes versions. Vu
les critères et exigences de notre cahier des charges et sachant qu’un Système Intégré est
24
amené à évoluer pour prendre en compte de nouvelles exigences, il nous est apparu
judicieux de retenir le Processus Unifié face à Merise pour les raisons suivantes :
 Souci de continuité
Puisque nous avons précédemment opté pour une méthode agile du fait des exigences du
projet, nous pensons qu’il faille demeurer dans cette logique pour la bonne marche du
système à réaliser.
 Solution modulaire
Vu la taille de notre projet, nous devons le scinder en plusieurs modules qui produiraient
des incréments pouvant être traités séquentiellement ou simultanément pour obtenir des
livrables. Ces livrables pourraient être testés, déployés et commercialisés au fur et à mesure.
Dans la démarche Merise, c’est à la fin de la dernière étape de la démarche que l’on obtient
les livrables.
 Solution évolutive
Grâce aux livrables fournis avant la fin du projet, l’architecture globale de la solution peut
être ajustée à plusieurs reprises.

 Déploiement simplifié
Une bonne représentation du déploiement technique de la solution doit être perçue dès la
conception pour faciliter le déploiement des composants et des modules sur les postes et
les serveurs des clients. Merise ne donne pas une représentation des composants techniques
sur l’architecture matérielle.
Au vu de ces raisons, nous avons opté pour le Processus Unifié en particulier sa déclinaison
2TUP. En effet, 2TUP est très approprié pour les projets de petite et grande taille et aux
changements réguliers d’un projet, il répond donc parfaitement aux exigences de la mise en
place de notre logiciel.
25
5.4 METHODOLOGIE 2TUP

5.4.1 Historique
Le Two Tracks Unified Process, 2TUP a été créé par la société Valtech7. C’est un processus
qui répond aux caractéristiques du Processus Unifié. C’est un processus de développement
construit sur UML.
5.4.2 Les deux phases du 2TUP

Le 2TUP signifie littéralement que le processus suit deux chemins. Il s’agit des « axes
fonctionnels » et « axe technique », qui correspondent aux deux axes de changement

imposés au système d’information.
La figure ci-dessous (figure 3) illustre les phases essentielles du 2TUP.
Contraintes Système Contraintes

fonctionnelles d’information de techniques
l’entreprise
Figure 3: Système d’information soumis à deux contraintes
7
ValTech est une agence de marketing digital et technologique créée en 1993, présent dans 10 pays et
comptant environ 1 600 collaborateurs.
26
5.4.3 Etude détaillée des phases 2TUP

Le 2TUP a pour but de capitaliser le travail effectué sur la branche fonctionnelle d’une part
et technique d’autre part avant de commencer la réalisation du système. Il propose un cycle

de développement en Y, qui dissocie les aspects fonctionnels des aspects techniques. La
figure ci-dessous (figure 4) nous présente les phases du 2TUP.
Capture des besoins

Capture des techniques
besoins
Conception
fonctionnels
générique
Spécification des
besoins fonctionnels Architecture de logiciel et
applicative
Analyse
Conception
Phase Codage
de
Test
réalisa
tion Recette
Déploiement
Figure 4: Cycle de développement selon 2TUP
La figure suivante montre les différentes étapes de la déclinaison 2TUP. Il divise le cycle de
développement en deux pistes :
 En amont Nous avons :

 La branche fonctionnelle : qui a pour objectif de dégager les grandes
fonctionnalités et frontières du système.

 La branche technique : qui a pour but de recenser les besoins techniques et
d’élaborer une architecture logicielle et applicative.

 En aval nous avons ici une seule phase :
 La phase de réalisation : qui consiste en la conception et mise en œuvre du

système.
N.B : L’étape de conception est particulièrement importante dans la mesure où elle regroupe
un grand nombre d’informations. C’est ici que l’on construit les classes avec les méthodes
27
associées. Elle peut être placée après les deux branches en amont ou à la première étape de
la phase de réalisation.
Pour chaque phase du processus, des documents doivent être rédigés et adoptés par tous
les intervenants du projet. Dans le cadre d’un grand projet, les fonctionnalités sont
regroupées en modules. Un module est réalisé pendant un incrément du processus. Un
incrément 2TUP contient les phases suivantes :

 Analyse
 Conception préliminaire
 Conception détaillée
 Programmation et tests
 Mise en œuvre de la recette provisoire.
En définitive nous avons présentés deux méthodes d’analyse MERISE et UML. Selon les
besoins de notre projet nous avons choisis la plus adaptée.
28
CHAPITRE-6. : ETUDE ORGANIQUE
Ce chapitre complètera dans un premier temps, le choix de la méthode d’analyse. En un
second lieu, le diagramme de cas d’utilisation, l’épine dorsale de cette étape nous présentera
dans un formalisme assez simple, les acteurs interagissant avec le système « XO-CDP ». Enfin,
nous présenterons la phase d’analyse selon les axes statique et dynamique du système par
le biais des différents modèles adaptés.
6.1 ANALYSE ET CONCEPTION DU SYSTÈME

6.1.1 Capture des besoins fonctionnels
6.1.1.1 Identification des cas d’utilisation et structuration en

packages
L’analyse des besoins fonctionnels de notre système nous a permis de les regroupés en
catégories ou packages. Le tableau ci-dessous (tableau 4) montre le regroupement des cas

d’utilisations.
CAS D'UTILISATION ACTEUR
Connexion
Consultation des données
Import des données Utilisateur
Exploration des données
Exports des données
Consultation de feedback de campagne
Tableau 4 : Identification des cas d’utilisation
6.1.2 Diagramme de cas d’utilisations

A ce niveau, nous modéliserons les diagrammes de cas d’utilisations des différents packages
énumérés précédemment dans le tableau. Toutefois nous pensons qu’il faille définir de
prime abord le formalisme requis pour la modélisation d’un diagramme de cas d’utilisation.
29
6.1.2.1 Formalisme
La figure ci-dessous (figure 5) présente le formalisme d’un diagramme de cas d’utilisation.
Figure 5: Formalisme d’un diagramme de cas d’utilisation
Légende :
A B C D E
Relation de Représentation Cas d’utilisation Relation Relation
généralisation : d’un acteur : d’inclusion : le d’extension : on
L’acteur 1 peut humain. représente une cas a
accéder à tous La flèche simple fonctionnalité d’utilisation 2 la possibilité
les signifie qu’un du requiert d’accéder au
cas acteur effectue système l’exécution cas
d’utilisations de un préalable du d’utilisation 3
l’acteur 2. Mais cas d’utilisation cas en
l’inverse n’est d’utilisation 1 exécutant le cas
pas avant de d’utilisation 1
possible. s’exécuter
Tableau 5 : Légende du formalisme de cas d’utilisation
30
6.1.2.2 Modélisation
La figure ci-dessous (figure 6) présente la modélisation du diagramme de cas d’utilisation:
Figure 6: Diagramme des cas d’utilisation
6.1.3 Description textuelle des cas d’utilisation

Un cas d’utilisation représente un ensemble de séquences d’interactions entre le système et
ses acteurs. Pour décrire la dynamique du cas d’utilisation, le plus naturel consiste à recenser
toutes les interactions de façon textuelle.
31
Ainsi a –t-il été question pour nous de recenser tous les scénarii nominaux, alternatifs et
d’exception régissant les différents cas d’utilisation, et c’est ce que nous présenterons dans
la suite, pour quelques cas d’utilisation.
Le tableau ci-dessous (tableau 6) présente le cas d’utilisation : Consultation des données.
Titre du cas d’utilisation : Consultation des données
Résumé Consultation des données de XO-CDP
Acteur Principal L’utilisateur
Acteur Secondaire L’administrateur
Préconditions L’utilisateur a ouvert une session
Scénario nominal 1. L’utilisateur clique sur le bouton « tables » et déroule la

liste des tables de la base
2. L’utilisateur clique sur la table dont il a besoin
3. « XO-CDP » affiche la liste des données selon la table
sélectionnée
4. Fin du cas d’utilisation
Scénario alternatif 1. L’utilisateur clique sur le bouton « tables » et déroule la
liste des tables de la base
2. L’utilisateur clique sur la table dont il a besoin
3. L’utilisateur choisit de consulter des données
spécifiques
4. « XO-CDP » recherche et affiche la liste des données
selon la table sélectionnée
Exception Aucune
Post conditions Aucune
Tableau 6 : Description des cas d’utilisation « consultation des données »
32
Le tableau ci-dessous (tableau 7) présente le cas d’utilisation : Import des données
Titre du cas d’utilisation : Import des données
Résumé L’injection de nouvelles données dans XO-CDP
Acteur Secondaire Le système (automatique)
Scénario nominal 1. L’utilisateur clique sur le bouton « import »

2. L’utilisateur clique sur le bouton de chargement de
fichier
3. L’utilisateur choisit le fichier à charger et clique sur le
bouton « importer ».
4. « XO-CDP » affiche sur l’interface le résultat de l’import
et un mail est envoyer au administrateur
Scénario alternatif A1 :
1. L’injection est fait de façon automatique soit par la
tâche cron configurer

A2 :
1. L’injection est faite via l’API automatiquement depuis le

site de l’aéroport.
Exception Le fichier doit être au format CSV.
Post conditions Un rapport de notification doit être envoyé par mail.
Tableau 7 : Description des cas d’utilisation « import de données »
33
Le tableau ci-dessous (tableau 8) présente le cas d’utilisation : Exploration des données
Titre du cas d’utilisation : Exploration des données
Résumé Exploration des données contenues dans le datamining
Acteur Secondaire L’administrateur
Scénario nominal 1. L’utilisateur clique sur le bouton “exploration des

données”
2. L’utilisateur clique sur “explorer vos données”
3. Le système le redirige vers METABASE configurée pour
cette plateforme
4. L’utilisateur se connecter avec son nom utilisateur et
son mot de passe
5. l'utilisateur peut sélectionner les tables avec lesquelles
il souhaite travailler.
6. l’utilisateur crée un segment
7. L’outil d’exploration exécute la requête et lui fait un
retour
8. l’utilisateur enregistre le segment
Scénario alternatif A1 : A partir du point 4 du scénario nominal
1. L’utilisateur consulte un segment existant

2. l’utilisateur modifie le segment
3. L’outil d’exploration exécute la requête et lui fait un
retour
4. l’utilisateur enregistre le segment
Exception Aucune
Post conditions Synchronisation vers l’outil de marketing automation
Tableau 8 : Description des cas d’utilisation « Exploration des données »
34
Le tableau ci-dessous (tableau 9) présente le cas d’utilisation : Export des données.
Titre du cas d’utilisation : Export des données
Résumé Envoyer un segment vers l’outil de marketing automation
Acteur Secondaire Administrateur
Préconditions Créer le segment au niveau de XO-MATIC
Scénario nominal 1. L’utilisateur clique que le bouton du menu pousser vers

XO-MATIC
2. L’utilisateur déroule la liste “Sélectionner un segment
XO-CDP”
3. Il sélectionne un segment
4. L’utilisateur déroule la liste ‘Sélectionner un segment
XO-MATIC”
5. Il sélectionne un segment
6. Il effectue un tri des données de la plateforme (par date)
7. (On peut générer un aperçu)
8. Créer un pivot (mettre en commun des données en
double ex: si le contact a deux emails nous créons un
champ email_1 et email_2 dans un fichier temporaire)
9. L’utilisateur faire une correspondance entre les
colonnes des deux tables. (mapping)
10. L’utilisateur peut définir les fréquences de
synchronisation (une tâche CRON)
11. Il clique sur le bouton “Envoyer”
Scénario alternatif Aucun
Exception Aucune
Post conditions Attente de feedback de campagnes
Tableau 9 : Description des cas d’utilisation « Export des données ».
6.1.4 Diagramme de séquence
6.1.4.1 Définition
Le diagramme de séquence a pour but de représenter les interactions entre objets en
indiquant la chronologie des échanges. Un diagramme de séquence sert aussi à illustrer un
35
cas d’utilisation en représentant les évènements et les messages échangés entre le système
et ses acteurs.
6.1.4.2 Formalisme
La figure ci-dessous (figure 7) présente le formalisme du diagramme de séquence :
Figure 7: Formalisme du diagramme de séquence
36
La figure ci-dessous (figure 8) présente la modélisation du diagramme de séquence :
Figure 8: Diagramme des séquences
6.1.5 Développement du modèle statique

A ce niveau, il s’agira de présenter la modélisation du diagramme de classes métier
d’analyse. Une classe métier d’analyse est en effet, une classe décrivant un concept
significatif pour les acteurs du système étudié. Il contient des informations qui seront
persistées sur le support de stockage.
Ici, nous présenterons les diagrammes dans les différents packages vu dans les parties
précédentes. Avant de passer à la présentation des modèles, nous définirons le formalisme
des diagrammes de classes.
37
6.1.5.1 Formalisme
La figure ci-dessous (figure 9) présente le formalisme du diagramme de classe :
Figure 9: Formalisme du diagramme de classe
La figure ci-dessous (figure 10) présente le diagramme des classes de la plateforme.
Les figures suivantes présentent un zoom de la figure 10
38
Figure 10: Diagramme des classes
39
40
6.1.6 Capture des besoins techniques

La capture des besoins techniques couvre, par complémentarité avec celle des
besoins fonctionnels, tous les besoins et aspects non fonctionnels du système.
6.1.6.1 Organisation de l’application en couches logicielles

Afin obtenir une modularité du code de notre application, nous l’avons découpé en trois
couches :
 La couche de présentation
Cette couche permet l’interaction de l’application avec l’utilisateur. C’est la partie visible de
notre système. Elle gère la présentation des informations à l’écran. Elle devait être conviviale,
sobre et ergonomique. De ce fait, nous avons opté pour un client léger. Notre interface
devrait donc être accessible via un navigateur web.
41
 La couche applicative
Elle est constituée des traitements décrivant les travaux à réaliser par l’application. Ces
traitements peuvent être découpés en deux familles :

 Les traitements locaux, regroupant les contrôles effectués au niveau du dialogue
avec l'Interface Homme Machine, visant essentiellement le contrôle et l'aide à la

saisie.
 Les traitements globaux, constituant l’application elle-même. Cette couche

appelée couche métier, contient les règles internes qui régissent une entreprise
donnée.
 La couche d’accès aux données
Cette couche contient l’ensemble des mécanismes qui permettent l’accès aux différentes
sources de données de manière transparente (Fichiers CSV, etc.). Les données de la CDP
doivent être persistées dans une base de données relationnelle.
Les trois couches précédentes sont réparties de différentes manières sur les postes de
déploiement du système.
Cette répartition permet de distinguer aujourd’hui plusieurs architectures de déploiement

aux nombres desquelles :
 L’architecture un tiers ;
 L’architecture deux tiers ;
 L’architecture trois tiers ;

 L’architecture n-tiers.
Nous avons opté pour l’architecture 2 tiers composés de 2 niveaux physiques :

 Un poste client : interprète et affiche le code de présentation de l’interface ;
 Un serveur intermédiaire: interroge le serveur de base de données et génère le

code de présentation, suivant la logique du métier ;
42
Cette architecture est utilisée car l’utilisation du container docker permet de
regrouper toutes les images des composants utilisés (base de données ainsi que serveur
FTP). Elle est plus flexible et réduit l’utilisation d’espace physique en termes d’équipements.
6.1.6.2 Plateforme de développement

Pour répondre aux besoins de séparation en couches de notre développement, nous
devons choisir une plateforme de développement d’application d’entreprise.
Il existe plusieurs plateformes de développement d’applications d’entreprise : Java EE, PHP,

.NET, Ruby on Rails, Django, ou encore la nouvelle pile d’applications plébiscitée par les
start-ups, à savoir « MEAN » pour MongoDB, Express.js, Angular.js et Node.js.

Dans le cadre de notre projet, nous avons choisi d’étudier la plateforme: PHP.
Le logiciel sera développé en PHP (Version 7) et en HTML (Version 5) avec le Framework

Symfony dans sa version 3.
PHP: Hypertext Preprocessor, plus connu sous son sigle PHP (acronyme récursif), est
un langage de programmation libre, principalement utilisé pour produire des pages Web
dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe
quel langage interprété de façon locale. PHP est un langage impératif orienté objet.
Nous n’avons pas effectué d’étude comparative pour les raisons suivantes :
 Règle de l’entreprise
Link to Business développe les logiciels avec le langage PHP. Ce Framework fait partie de la
politique assurance qualité de l’entreprise.
 Gain du temps
La disposition de bundles déjà réalisé et son système de paramétrage permet au
développement d’aller plus vite, il permet donc de libérer le produit dans les délais prévus.
6.1.6.2.1 SGBD
La fonction première d'un Système de Gestion de Base de Données (SGBD) est d'être un
outil de stockage d'informations offrant des fonctions de manipulation des données. L’un
des avantages des SGBD est que l'interrogation de ces informations s’effectue d’une manière
indépendante de l'architecture physique de stockage.
43
6.1.6.2.2 Le système d’exploitation
Le tableau (tableau 10) nous présente quelques caractéristiques des deux systèmes
d’exploitation les plus utilisés dans la sous-région, à savoir WINDOWS et LINUX.
WINDOWS LINUX
Installation Installation et prise en Installation et prise en

main simplifiées main peu simplifiées
Utilisation Espace de travail convivial Espace de travail peu
et facilité de manipulation. convivial. Quelques
distributions en ligne de
commande.
Entrées/Sorties Bonne gestion Bonne gestion
Mémoire Bonne gestion Bonne gestion
Coût Payant Gratuit
Sécurité Faible Elevé
Tableau 10: Comparaison de quelques caractéristiques de WINDOWS et LINUX
Notre choix se porte sur le système LINUX, étant donné que les données que nous
collecterons sont très importantes, nous avons besoin d’une bonne sécurité du système
d’exploitation en plus il est gratuit. Aussi l’installation de Traefik n’a été possible qu'avec le
système d’exploitation linux et Mac. Nous utiliserons les distributions avec interface
graphique pour faciliter les prises en mains.
6.1.6.2.3 Développement du modèle dynamique

Les principaux diagrammes dynamiques sont :
 Le diagramme d‘activité : il consolide les enchaînements de la fiche de

description textuelle des cas d’utilisation ;
 Le diagramme d'états–transitions : il montre la dynamique interne à un objet ;

 Le diagramme de séquence expose la dynamique entre objets.
Tous les cas d’utilisations recensés dans l’étude préliminaire ne seront pas tous représentés
avec ces diagrammes dynamiques, car en fonction de la logique d’enchaînement dans la
description des cas d’utilisations, une dynamique est appropriée.
44
6.1.7 Diagrammes d’activités

Le diagramme d'activité est une variante du diagramme d'état où les "états" représentent
des opérations, et les transitions représentent les activités qui se produisent quand
l'opération est terminée. Aussi le diagramme d’activité comporte –il à la différence du
diagramme d’états, des nœuds de décisions, servant à matérialiser les choix et symbolisés
par les rectangles.
L'usage général des diagrammes d'activité permet de faire apparaître les flots de traitements
induits par les processus internes par rapport aux évènements externes. Dans la suite, nous
présenterons les diagrammes d’activités de quelques cas d’utilisations.
6.1.7.1 Formalisme
La figure ci-dessous (figure 11) montre le formalisme d’un diagramme d’état transition :
Figure 11: Formalisme du diagramme d’état-transition
45
6.1.7.2 Présentation
La figure ci-dessous (figure 12) montre le formalisme d’un diagramme d’activité du cas
d’utilisation ‘Import des données’
Figure 12: Diagramme d’activité du cas d’utilisation import de données
46
6.2 IMPLEMENTATION DU SYSTEME

6.2.1 Equivalence entre les termes objets et relationnels
La conception de notre système étant faite avec le processus unifié, il nous fallait
transformer le modèle obtenu en modèle relationnel afin de persister nos données dans une
base de données relationnelle notamment MySQL. Néanmoins, le formalisme utilisé par UML
diffère de celui utilisé dans les modèles relationnels. Pour cela nous avons effectué une
correspondance entre les modèles objets et relationnels afin d’arriver à nos fins. Le tableau
ci-dessous (tableau 11) liste quelques correspondances entre modèles objets et relationnels,
en occurrence le diagramme des classe d’UML et le MCD de MERISE.
Eléments du diagramme des classes Eléments du MCD
Classe Entité
Association Relation/Association
Multiplicité Cardinalité
Héritage Héritage
Méthode Rien
Tableau 11 : Quelques correspondances Diagramme des classes-MCD
6.2.2 Règles de passage
Les méthodes des classes ne sont pas concernées par les règles de passage. Nous
présenterons quelques règles nécessaires pour notre travail.
 Classe avec attribut

La figure ci-dessous (figure 13) présente la classe avec attribut.
CLASSE
#identifiant
-Attribut1
-Attribut2
+méthode()
Figure 13: Classe avec attribut
Chaque classe devient une relation. Les attributs de la classe deviennent des attributs de la
relation. L’identifiant de la classe devient la clé primaire de la relation.
47
 Association binaire un à plusieurs
La figure ci-dessous (figure 14) présente une association un à plusieurs.
CLASSE1 CLASSE2
#identifiant #identifiant2
1..* 0..1
-Attribut1 -Attribut3
+méthode() +méthode2()
Figure 14: Association un à plusieurs
Les associations un à plusieurs sont les plus nombreuses dans un modèle conceptuel. Or il
s’avère que c’est aussi le type d’association comportant la règle de dérivation la plus simple.
Elle se résume ainsi : la table dérivée de l’entité du côté de la multiplicité maximale plusieurs
(*) est considérée la table fille (CLASSE1). En conséquence, une copie de la clé primaire de la
deuxième table, la table mère (CLASSE2), est déposée dans la table fille à titre de clé
étrangère.
 Association plusieurs à plusieurs

La figure ci-dessous (figure 15) présente une association plusieurs à plusieurs.
CLASSE1 CLASSE2
#identifiant 0..* 1..* #identifiant2
+méthode() +methode2()
CLASSE_ASSOCIATION
#identifiant3
-Attribut5
-Attribut6
+methode3()
Figure 15: Association plusieurs à plusieurs
Une association plusieurs à plusieurs donne lieu à une table fille (CLASSE_ASSOCIATION)
comportant comme clé primaire la combinaison des clés primaires des tables mères.
6.2.3 Script de création de la base de données

(Voir annexe 2)
48
6.2.4 Modèle physique

La figure ci-dessous (figure 16) présente le modèle physique de la base de données.
Les figures suivantes sont un zoom de la figure 16.
49
Figure 16: Modèle de données sous MySQL sous forme de modèle physique
50
51
Ce chapitre nous a permis de relever en premier lieu, les besoins fonctionnels par le biais
des diagrammes de cas d’utilisation et des descriptions textuelles. Nous avons présenté par
la suite, les choix techniques nécessaires à la réalisation du système. Enfin, nous avons étalé
les modèles dynamiques et statiques du système. Il sera question pour nous dans la dernière
partie de la réalisation proprement dite du système.
52
QUATRIEME PARTIE :
IMPLEMENTATION ET
DEPLOIEMENT DE LA SOLUTION
Dans cette partie, nous couronnons notre travail au travers de l’implémentation du système.
Ensuite nous faisons une estimation financière dudit système et en présentons enfin
quelques captures d’écrans.
53
CHAPITRE-7. : ETUDE TECHNIQUE ET RÉALISATION
Ce chapitre nous permet de faire une étude technique et de présenter les outils,
fonctionnalités les difficultés et leurs solutions. En outre la fiabilité du système sera décrite.
7.1 ÉTUDE TECHNIQUE

Nous décrivons ici les différents outils qui ont été utilisés pour la mise en place de notre
plateforme. Ainsi nous avons :
Plateforme de PHPSTORM version 7

développement
Langage PHP avec le Framework SYMFONY
SGBD Maria DB
Container Docker
Travail collaboratif GIT et GITHUB
Méthode argile le logiciel JIRA et Confluence dans la suite Atlassian
Outil de marketing MAUTIC solution libre
automation
Outil de Datamining METABASE
7.2 RÉALISATION
7.2.1 Présentation des outils utilisés
XO-CDP a été développé en Symfony (version 3) utilisant l’architecture MVC qui est un
Framework PHP car l’entreprise souhaiterait faire une application basique pour répondre aux
besoins de leurs clients.
 Le logiciel est contenu dans un container DOCKER8 (Docker version 1.13.1, build
092cba3).
 Ce container comprend toutes les images des logiciels (serveur de DB, PHPmyadmin,
Serveur SFTP, serveur web, le serveur d’application, le serveur PUREFTP, METABASE).
 Le logiciel GIT pour un meilleur travail d’équipe et gérer le versionning.
8 Docker est une technologie de conteneurisation qui permet la création et l'utilisation de conteneurs Linux.
54
 XO-MATIC : intégration de LTBT de l’open-source MAUTIC, il est basé sur Symfony.
7.2.2 Présentation des fonctionnalités
7.2.2.1 Lister les fonctionnalités mise en œuvre

 Chargement des données par plusieurs méthodes (Interface, command et API)
 L'initialisation des données (Dépôt des fichiers sur le serveur de SFTP)
 Les flux à mettre en place (interfaces et fréquences de mises à jour)

 Les significations et la correspondance des champs (mapping)
 Le modèle de données (mise en place du modèle de données)

 La définition des stratégies d'import (via l’interface, via la commande, via l’API)
 La définition des unicités (représente la valeur unique dans chaque table)

 La définition du UCID (Unique Contact Identification)
 la conversion des valeurs (Ex : Mme→ Madame)
 Le service d’envoi de rapport par mail après chaque l’import de données;
 La configuration de l’outil de marketing automation dans la plateforme pour la

création des offres marketing (XO-MATIC);
 La configuration de l’outil l’exploration des données (METABASE).

 La gestion des retours de campagnes.
7.2.2.2 Approche algorithmique (fonctions, objets etc.)

Les différents services mise en œuvre en vue de la réalisation du système:
 Les services:
o Le service ImportCSV
 La première étape est le choix de la méthode d’import (API, Interface
ou Tâche CRON);
 La fonction prend en paramètre fichier de données, le fichier de
conversion, la méthode, le fichier de mapping;

 Si les données doivent être envoyé à un autre service, un fichier
temporaire est créé;
 Une sauvegarde automatique de la base données est lancée;
 Les données sont ensuite encodées au format UTF-8
55
 Connexion à la base de données
 Les données sont parsées à la fonction parseCsvData
 Si le format est correct on continue

 Sinon on envoie un message d’erreur dans le rapport final
 Une détection de la source est effectuée

 Si la source provient du fichier ou si la source est contenue dans
le fichier de mapping alors on continue

 Sinon on envoie un message d’erreur dans le rapport final
 Début de chargement des données dans la base

 Les entêtes de fichier de chaque ligne sont convertis depuis le
fichier de mapping
 Si l’entête n’est pas défini dans le fichier de mapping, sinon on
envoie un message d’erreur dans le rapport final

 Une analyse de chaque ligne est faite et les données regroupées par
table
 Les données sont importées dans les tables spécifiques
 un rapport final est envoyé avec les succès et erreur. Ce rapport est
envoyé par mail soit à l’administrateur ou l’utilisateur qui a les droits.
o Le service Datamining
 Une première étape où l'utilisateur peut sélectionner les tables avec
lesquelles il souhaite travailler;

 Mise en place de METABASE automatiquement sur le projet;
 La table contact est sélectionnée par défaut,

 Enregistrement de bout de jointure complexe (campagne,
commercialcampagne...). L'utilisateur peut choisir un de ces

éléments comme base,
 L'utilisateur peut ajouter d'autres tables (ex. resaparking),

 Le résultat est une requête SQL qui permet de créer une vue sur
la BDD (Voir annexe 3),

 Ajout de vues par sélection de plusieurs tables,
56
 Suppression de vue (peut-être pas?) - Contrôle pour voir si la vue
existe déjà,
 Enregistrement de la vue sous un nom - automatiquement créé

par concaténation des noms de tables,
 Symfony query builder à faire les requêtes (Voir annexe 4),

 Facilité par Docker,
 METABASE est configuré avec un utilisateur de base et une connexion

à une BDD pour chaque projet,
 La récupération des segmentations METABASE depuis la CDP pour

injection dans XO-MATIC;
o Le service SegmentPush
 Mettre en oeuvre un table segmentpush pour suivre les segments déjà
poussé et automatiser les push suivant;

 Ajout d'un titre + description par l'utilisateur pour reconnaître son
segment
 One-shot9 ou Synchronisé + fréquence (en heure);
 Créer le segment XO-MATIC à la volé depuis CDP;

 Interface de listage des push permanent pour pouvoir les
supprimer/annuler;
 Sélectionner les champs à importer ;
 Exposer les champs du segment. Créer un champ dynamique

XO-MATIC avec les champs choisis. Utiliser le nom du champ
CDP,
 Table contact-segmentxomatic pour suivre les contacts déjà
envoyés vers ce segment particulier XO-MATIC et n'envoyer que

le delta après coup,
 Attention, comme nous envoyons des champs spécifiques

comme resavoyage, nous voulons parfois renvoyer le même
9 One SHOT : réaliser une seule tentative ou action
57
contact dans un même segment, mais les valeurs spécifiques
seront différentes,
 Donc la CDP envoie tous les contacts dans le segment à chaque fois;
 Suppression de contacts dans un segment XO-MATIC lors de la
synchronisation.
 Command "xodmp:synchSegmentsToXomatic, tourney chaque minute.
 Contrôle si segmentpush_status est OK, sinon passer;

 Calculer l’intervalle entre la dernière synchronisation et la nouvelle
 Si le résultat est supérieur à la fréquence normale alors refait la

synchronisation.
7.2.2.3 Description de la mise en œuvre des principales

fonctionnalités
1. Consultation
Il s’agit de consulter les données importées dans la base de données

depuis l’interface de la plateforme. Appliquer des modifications ou supprimer.
Le CRUD généré par symfony permet de dynamiser cette interface.

2. Importer
L’injection des données est l’une des activités principales de cette

plateforme. Il est question de charger la base de données avec les données
contenues dans le fichier Excel et celle du site internet de la structure. Ces

données brutes doivent subir une transformation avant le chargement dans la
base de données. Il s’agit entre autre de faire de la correspondance de champ

d’entête, conversion de données au format UTF-8 ainsi que la conversion de
civilité qui peut être écrit sous plusieurs formes. Enfin générer un rapport
envoyé par mail aux administrateurs.
3. Explorer
L’exploration consiste à la création de segments c’est à dire une vue
depuis la dite plateforme connecté en CURL dans la plateforme.

4. Exporter
58
L’exploration consiste à charger les segments créés dans METABASE
vers l’outil de marketing automation.
7.2.2.4 Les différentes difficultés rencontrées

● L’installation du container docker sous Windows car Traefik ne démarre pas sous
Windows, problème de droit sur fichiers

● Lenteur des imports
● Installation de docker sous windows

● Prise en main du Framework Symfony
● Compréhension de l’architecture de la CDP (Kernel et Projet)

● Prise en main de git et docker
7.2.2.5 Les solutions apportées

● Plusieurs tests ont été effectués en vue de pallier à ce souci. Notons le changement
de droit de fichier sous Windows etc. Pour finir le système utilisé a été linux pour le
développement.
● Une documentation et de la pratique ont donné une maîtrise de l’environnement.
● Optimisation des requêtes pour optimiser l’import des fichiers.

● Création des vues matérialisés10.
10 Vue matérialisée : la différence d'une vue standard, dans une vue matérialisée les données sont dupliquées
59
7.2.2.6 Architecture générale de la solution
La figure ci-dessous (figure 17) présente l’architecture générale de la solution :
Figure 17: Architecture générale du système
Sur cette capture nous décrivons le système actuel et tous les composants du système.
1. La source des données venant de l’aéroport de Nantes ;

2. XO-CDP (système ETL développé en Symfony et utilisé comme interface
utilisateur) ;
3. XO-CDP intégré à METABASE, permet de générer les segments ;
4. XO-MATIC permet de créer des scénarios de campagnes de marketing

automation ;
Le système de la CDP est sur un serveur OVH hébergé en France et sous la maintenance de
Romain Laisné.
XO-MATIC est également hébergé sur un serveur en France.
60
7.3 SECURITE DU SYSTEME

La plateforme est déployée avec un certificat Let’s Enscrypt. La CDP est déployé sous la
distribution Debian du système linux.
Nous avons l’authentification avec htpasswd de Nginx pour avoir accès à l’interface.
Dans ce chapitre nous avons fait l’étude technique de notre solution en décrivant les outils
technique utilisés pour l'implémentation de la solution. Nous avons aussi décrit les
fonctionnalités du système.
61
CHAPITRE-8. : DEPLOIEMENT ET PRESENTATION DU SYSTEME

FINAL
Ce chapitre met la pierre de faîte à notre construction, premièrement par le déploiement
de notre système. Il en étale ensuite l’évaluation financière que nous avons réalisée et en
montre enfin, quelques captures d’écrans.
8.1 DEPLOIEMENT
8.1.1 Notion
Le diagramme de déploiement se rapproche encore plus de la réalité physique,
puisqu’ il identifie les éléments matériels (PC, réseaux, postes de travail, serveur, etc.), leur
disposition physique (connexions) et la disposition des exécutables sur ces éléments
matériels.
Les concepts de bases sont :
● Un nœud : C’est un élément physique qui existe au moment de l'exécution et qui

représente une ressource ayant des possibilités d’exécution.
● Les associations entre nœuds : Elles représentent les connections physiques, à savoir
une connexion internet ou des câbles.
● Un artefact : Il correspond à un élément concret existant dans le monde réel

(document, exécutable, fichier, tables de bases de données, script, ...). Il se représente
comme un classeur par un rectangle contenant le mot-clé « artifact » suivi du nom

de l’artefact.
62
8.1.2 Modélisation
La figure suivante (figure 18) présente l’architecture technique du système final. En
effet, Dans le diagramme de déploiement suivant, les ressources matérielles sont

représentées sous forme de nœuds qui peuvent être liés entre eux à l’aide d’un support de
communication. [8]
Figure 18: le diagramme de déploiement
Nous constatons que la CDP (plateforme de gestion des données), le serveur web, et
le dossier des fichiers Excel sont localisés sur le même serveur physique (Cloud). Les données
63
provenant des fichiers Excel et du site de l’aéroport sont transmises à la CDP, qui les traite
et les charge dans le modèle de données hébergé sur le serveur WEB qui contient (le SGBD
Mysql –MariaDB).
Les données ainsi stockées sont utilisées par METABASE afin que le client créer les
segments dont ils auront besoin dans le système. Les données contenues dans ces segments
sont alors envoyées à XO-MATIC via une API développé dans la CDP afin de réaliser des
scénarios de campagnes de marketing automation. Enfin XO-MATIC envoyé les campagnes

aux différents segments selon le schéma. Par conséquent un retour de campagne est
enregistré dans les tables correspondantes dans la CDP.

o OVH Cloud
OVH Cloud permet la mise en place rapide de machine virtuelle. Une machine peut
également rapidement être dupliquée pour mettre en œuvre un nouveau projet.
o Docker/Traefik
Docker permet la mise en place d’un environ containerisé et configuré via un fichier yaml.
Traefik permet de router un domaine vers un container particulier.

o MySQL/Maria dB
Le gestionnaire de base de données

o php_fpm
Pour permettre les actions kernel.terminate11 après le retour des réponses sur Symfony.
o Nginx
Pour gérer l’authentification et utilisé comme serveur.
11Kernel.terminate : Cet événement est dispatché lorsque la réponse HTTP à été transmise au client. L’intérêt
étant de pouvoir effectuer des traitements coûteux en temps
64
8.2 PRÉSENTATION DE QUELQUES ÉCRANS
Les captures d’écrans suivantes montrent quelques interfaces du système conçu.

1- L’interface de connexion
L’authentification est faite depuis le htpasswd de ngnix présenté par la figure 19
Figure 19: Interface de connexion
2- L’interface d’import
Depuis cette interface (figure 20) d’utilisateur a la possibilité de charger depuis un

fichier CSV des données dans la base de données. Un rapport est généré juste en dessous à
la fin du chargement.
Figure 20: Interface d’import
65
3- Interface (consultation des données)
Il s’agit de l’interface (figure 21) pour gérer la consultation, la modification, la
suppression (pour les utilisateurs ayant les droits), la recherche d’une information dans la
base.
Figure 21: Interface de consultation des données
4- Interface de l’exploration des données
Cet figure ci-dessous (figure 22) présente outil de datamining pour permettre à
l’utilisateur de pouvoir créer des segments.
Figure 22: Interface de l’exploration de données
66
5- Interface de l’export des données vers l’outil de marketing automation
Les segments crées sous l’outil de datamining doivent être exportés vers l’outil de
marketing automation depuis l’API. Cette interface décrit le processus pour exporter ces
segments. La figure ci-dessous (figure 23) présente l’interface.
Figure 23: Interface de transfert de segment vers XO-MATIC
67
6- Interface de l’outil de marketing automation
Cette figure ci-dessous (figure 24) montre le tableau de XO-MATIC :
Figure 24: Interface de XO-MATIC
7- Interface des API

Le logiciel doit avoir un accès à ses fonctions via une API qui peut être utilisée par
une application tierce qui a besoin d’interroger les données contenues dans la CDP, d’en
insérer ou de les modifier. Cette figure (figure 25) présente l’interface de l’outil:
Figure 25: Interface de API
68
8.1 ESTIMATION FINANCIÈRE

La réalisation d’un logiciel engendre des coûts autant dans la phase de production que
dans la phase d’exploitation du produit. La date butoir de développement est généralement
fixée au préalable, tandis que l’exploitation et le support d’un logiciel peuvent prendre
plusieurs années. Notre structure d’accueil possède les licences des logiciels utilisés, ainsi
ces derniers ne seront pas répertoriés dans notre inventaire financier. Ce dernier ne prendra
donc en compte que la main d’œuvre la phase de conception et de réalisation de ce projet.
Ainsi notre évaluation financière ne concernera-t-elle que les ressources Humaines utilisées
durant la réalisation de tous les sprints du projet. Plusieurs méthodes s’offraient à nous pour
l’évaluation financière de notre solution, mais nous avons opté pour la méthode
Constructive Cost Model (COCOMO) [7], car elle concerne tous les types de projets et c’est
cette dernière que nous maîtrisons le mieux. Par ailleurs, elle est une référence dans le
domaine car fondée sur une base de données de plus de 60 projets différents. Notre projet
ayant un type organique, le tableau suivant (tableau 12) en résume l’évaluation financière :
Temps
Sprints Prix Unitaire(Euro) Total(Euro)
(Homme/jour)
Cadrage 5 18000 90000
Analyse et 3 30000 900000
Conception
Réalisation 3 30000 90000
Tests de validation 5 140000 70000
Déploiement et 2 30000 60000
Maintenance
TOTAL 18 - 400 000 Euros

Tableau 12 : Evaluation financière
69
Ce chapitre nous a permis de présenter l’implémentation du système final, au travers de
l’exposition en premier lieu de son architecture. Subséquemment, nous en avons présenté

quelques captures d’écrans. Enfin, nous avons inventorié les coûts engendrés par la main
d’œuvre.
70
CONCLUSION GENERALE ET PERSPECTIVES
Le stage effectué avec l’équipe de développement chez Link to Business Technology
avait pour but de faire une analyse sur le système existant de l’aéroport, notamment la
difficulté de réassemblage des données des fichiers et l’exploitation des informations
pertinentes sur les clients. Il s’agissait pour nous d’en déceler les difficultés et de proposer
des solutions informatiques en guise de palliatifs.
L’étude que nous avons alors menée, nous a permis de relever les différentes
insuffisances des processus existants. Après conjugaison de ces dernières et des besoins
exprimés par les responsables, nous avons trouvé deux axes principaux. Ces axes sont la
centralisation des informations dans une base de données centralisées et les outils pour la
mise en place de la stratégie marketing.

Ainsi notre travail consistait-il en la mise en œuvre d’un système intégrant d’une part
une application métier permettant la gestion centralisée et automatisée des données

provenant de sources diverses tels que le site web de la structure, des newsletters, les points
d’accès wifi gratuits, les réservations de voyages, les abonnements de parking, etc. Et d’autre
part la configuration d’un outil d’exploration de données et d’un outil de marketing
automation afin de construire des offres marketing et commerciales.

L’analyse du cahier des charges et des différentes interviews menées, nous a permis
de mettre en place système avec l’utilisation de la méthode agile, la modélisation d’une

Customer Data Platform, la mise en place de METABASE et enfin la configuration de XO-
MATIC. L’analyse et la conception du projet par la méthode d’analyse PU (Processus Unifié)

en particulier sa déclinaison 2TUP.
L’outil réalisé se présente comme une solution pour une amélioration de la

productivité de l’aéroport. D’abord, il permet la centralisation et l’automatisation du
processus, auparavant manuels en plus de l’utilisation des informations de manière

efficientes. Ensuite le système permet aussi l’enregistrement les données du site de
l’aéroport de manière automatique ; par exemple lorsqu’un client s’inscrit pour la première
fois ses informations sont enregistrées dans la base de données de la CDP et un message
de bienvenue lui est envoyé. Enfin, il sert également à envoyer des emails ou SMS aux
71
contacts enregistrés ; par exemple lorsque la réservation ou l’abonnement du parking va
bientôt expirer.
Nous avons procédé au déploiement avec différentes phases de tests. Le système est
présentement sur le serveur de production et est utilisé par l’aéroport. Des retours sont faits
à l’équipe pour les modifications ou les développements en cours.

De ce stage, nous sortons comblés car nous avons pu mettre en pratique les
connaissances théoriques acquises pendant notre formation et découvrir de nouveaux

horizons notamment les méthodes agiles et pratiquer un cas de la Business Intelligence.
Aussi avons-nous suivi un projet depuis la phase de test jusqu’à sa mise en production.
Il nous a également permis de prendre connaissance des exigences du monde
professionnel. Sur cette lancée, nous pouvons émettre les perspectives suivantes :
L’aéroport pourrait fidéliser sa clientèle en étant encore plus proche d’elle. Pour ce faire il
pourrait développer un module de compagnon qui permettrait d’envoyer à ses usagers des
SMS de notification pour les différents vols.
Toutefois, le présent travail demeurant le fruit d’une œuvre humaine, nous le

soumettons aux critiques et suggestions en vue d’y apporter des modifications et des
corrections. Ces dernières serviront à améliorer notre travail et nous permettront une
évolution de notre logiciel.
72
BIBLIOGRAPHIE ET WEBOGRAPHIE
 MEMOIRES
[1] Eva BARDOU. « Réalisation d’une application web d’aide à la vente dans le domaine médical -
Link To Business ».mémoire de stage ; département informatique - iut 2 Grenoble, 2016-2017, 50
pages.
 OUVRAGES
[3] NETBOOSTER . «Livre blanc - La Data au service de l’expérience client ». © NETBOOSTER, 2015,
60 pages. (http://www.netbooster.com/fr/Livre_Blanc_Data.pdf, consulté le 25 Janvier 2019 à 12h35)
[4] M. Arnaud Gallet . « XO-CDP Présentation »,Link to business, Septembre 2018, 10 pages.
[5] Joseph Gabay, David Gabay . « ANALYSE ET CONCEPTION Mise en œuvre guidée avec études de
cas ». EAN, Avril 2018, 240 pages. (https://www.dunod.com/sciences-techniques/uml-2-analyse-et-
conception-mise-en-oeuvre-guidee-avec-etudes-cas, consulté le 25 janvier 2019 à 13h30)
 WEBOGRAPHIE
[6] http://blog.smile.fr/Retour-d-experience-sur-docker-ou-comment-mettre-d-accord-les-
administrateurs-systeme-et-les-developpeurs (Consulté le lundi 25 Février 2019 à 16h31m)
[7] https://fr.wikipedia.org/wiki/Constructive_Cost_Model(Estimation des coûts consulté le 26 Février
2019 à 14h48)
[8] https://www.cartelis.com/blog/customer-data-platforms/(consulté le 17 Janvier 2019 à 9h30)
[9] https://fr.wikipedia.org/wiki/Docker_(logiciel)(consulté le 17 Janvier 2019 à 9h45)
[10] https://www.custup.com/customer-data-platform-cdp-definition-et-differences-entre-le-crm-
et-la-dmp/ (consulté le 07 Avril 2019 à 20h45)
[11]https://fr.wikipedia.org/wiki/Liste_des_a%C3%A9roports_les_plus_fr%C3%A9quent%C3%A9s_en
_France (Consulté le 23 Avril 2019 à 15h14min)
[12] https://framalibre.org/content/mautic (Consulté le 01 Mai 2019 à 11h30)
[13] https://docs.traefik.io/ (Consulté le 01 Mai 2019 à 11h35)
[14] https://fr.wikipedia.org/wiki/Marketing (Consulté le 01 Mai 2019 à 11h40)
[15] https://www.definitions-marketing.com/definition/marketing-digital/ (Consulté le 01 Mai 2019 à 11h45)
[16] https://www.definitions-marketing.com/definition/campagne-marketing/ (Consulté le 01 Mai
2019 à 11h50)
[17] https://fr.wikipedia.org/wiki/Lac_de_données (Consulté le 01 Mai 2019 à 11h55)
[18] https://fr.wikipedia.org/wiki/Datamart (Consulté le 01 Mai 2019 à 12h00)
[19] https://www.noodo-wifi.com/faq/cookie-informatique/ (Consulté le 01 Mai 2019 à 12h15)
[20]https://www.definitions-marketing.com/definition/dmp-media/ (Consulté le 02 Mai 2019 à 09h36)
[21] https://fr.wikipedia.org/wiki/Gartner (Consulté le 02 Mai 2019 à 09h54)
[22] https://www.appvizer.fr/magazine/marketing/cdp/cdp-dmp-marketing-digital-
multicanal#definition-du-crm-ou-customer-relationship-management (Consulté le 02Mai à 13h17)
[23] https://rosemees.com/differences-entre-crm-dmp-et-cdp/ (Consulté le 02Mai à 13h29)
[24] https://www.lebigdata.fr/data-warehouse-entrepot-donnees-definition (Consulté le 02Mai à
13h29)
[25] https://www.01net.com/telecharger/windows/Bureautique/base_de_donne/fiches/137453.html
(consulté le 03 Mai 2019 à 9h35)
LXXIII
ANNEXES
Annexe 1 : Liste des treize (13) diagrammes UML
Les diagrammes d’UML se regroupent en deux grandes catégories : les diagrammes

statiques et dynamiques.
1- Les diagrammes statiques
Le diagramme de classe : représente les classes intervenant dans le système. Une classe est
un ensemble d’individus ayant les mêmes caractéristiques et les mêmes comportements.
Le diagramme objet : (objet : instance d’une classe) sert à représenter les instances utilisées
dans le système.
Le diagramme de composant : permet de montrer les composants du système d’un point

de vue physique, tels qu’ils sont mis en œuvre (fichiers, bibliothèques, base de données)
Le diagramme de déploiement : sert à représenter les éléments matériels (ordinateurs,

réseaux, serveur) et la manière dont les composant du système sont repartis sur ces éléments
matériels et interagissent entre eux.

Le diagramme des paquetages : un paquetage étant un conteneur logique permettant de
regrouper et d’organiser les éléments dans le modèle UML, le diagramme de paquetage sert
à représenter les dépendances entre paquetage.
Le diagramme de structure composite : permet de décrire sous forme de boite blanche

les relations entre composants d’une classe.
2- Les diagrammes dynamiques
Les diagrammes comportementaux

Le diagramme des cas d’utilisation : permet de représenter les besoins des utilisateurs par
rapport au système. Il permet d’indiquer toutes les fonctionnalités que doit avoir le système.
Le diagramme d’état-transition : permet de décrire sous forme de machine à état fini le
comportement du système ou de ses composants.

Le diagramme d’activité : permet de décrire sous forme de flux ou d’enchainement
d’activités le comportement du système.
Les diagrammes d’interactions
LXXIV
Le diagramme de séquence : permet la représentation séquentielle du déroulement des
traitements et des interactions entre les éléments du système et/ou des acteurs.
Le diagramme de communication : permet la représentation simplifiée d’un diagramme

de séquence en se concentrant sur les échanges de messages entre les objets.
Le diagramme global d’interaction : permet de décrire les enchainements possibles entre

les scénarios préalablement identifiés sous forme de diagramme de séquence (variante du
diagramme d’activité).
Le diagramme de temps : permet de décrire les variations d’une donnée au cours du temps.
Annexe 2: Le modèle objet relation

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
-- -----------------------------------------------------
-- Schema dmpxo
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `dmpxo` DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_bin ;
USE `dmpxo` ;
-- -----------------------------------------------------
-- Table `dmpxo`.`contact`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`contact` (
ìd` INT(11) NOT NULL AUTO_INCREMENT,
`contact_id_interne` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NULL DEFAULT NULL,
`contact_insertion_date` DATETIME NULL DEFAULT NULL,
`contact_modification_date` DATETIME NULL DEFAULT NULL,
`contact_drupal_id` VARCHAR(255) NOT NULL,
LXXV
`contact_civilite` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NULL

DEFAULT NULL,
`contact_nom` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NULL
DEFAULT NULL,
`contact_prenom` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NULL DEFAULT NULL,
`contact_date_naissance` DATETIME NULL DEFAULT NULL,
`contact_is_pmr` TINYINT(1) NULL,
`contact_date_union` DATETIME NULL,
`contact_situation_matrimoniale` VARCHAR(255) NULL,
`contact_adresse` VARCHAR(255) NULL,
`contact_code_postal` INT NULL,
`contact_ville` VARCHAR(255) NULL,
`contact_pays` VARCHAR(255) NULL,
`contact_code_pays` VARCHAR(255) NULL,
`contact_email` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NULL
DEFAULT NULL,
`contact_is_email_non_valide` TINYINT(1) NULL DEFAULT NULL,
`contact_telmobile` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NULL DEFAULT NULL,
`contact_is_telmobile_non_valide` TINYINT(1) NULL DEFAULT NULL,
`contact_telfixe` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NULL
DEFAULT NULL,
`contact_is_pro` TINYINT(1) NULL DEFAULT NULL COMMENT 'professionnel: oui ou non',
`contact_pro_entreprise` VARCHAR(255) NULL,
`contact_pro_societe` VARCHAR(255) NULL,
`contact_pro_fonction` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NULL DEFAULT NULL,
`contact_pro_service` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NULL DEFAULT NULL,
`contact_pro_titre` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NULL DEFAULT NULL,
`contact_pro_metier` VARCHAR(255) NULL DEFAULT NULL,
`contact_grading` VARCHAR(255) NULL DEFAULT NULL,
LXXVI
PRIMARY KEY (ìd`))

ENGINE = InnoDB
-- -----------------------------------------------------
-- Table `dmpxo`.òperation`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.òperation` (
ìd` INT(11) NOT NULL,
`contact_id` INT(11) NOT NULL,
òperation_insertion_date` DATETIME NULL,
òperation_modification_date` DATETIME NULL,
òperation_nom` VARCHAR(255) NULL,
òperation_type` VARCHAR(255) NULL COMMENT 'jeu OU\nenquete OU\nopération
commerciale',
òperation_date_participation` DATETIME NULL,
òperation_is_ok_reglement` TINYINT(1) NULL,
PRIMARY KEY (ìd`),
INDEX `fk_Projet_Chantier_Contact1_idx` (`contact_id` ASC),
UNIQUE INDEX ìd_UNIQUE` (ìd` ASC),
CONSTRAINT `fk_Projet_Chantier_Contact1`
FOREIGN KEY (`contact_id`)
REFERENCES `dmpxo`.`contact` (ìd`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
COMMENT = 'Stocke les informations des opérations commerciales et des jeux concours';
-- -----------------------------------------------------
-- Table `dmpxo`.`campagne`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`campagne` (
ìd` INT NOT NULL AUTO_INCREMENT,
`campagne_insertion_date` DATETIME NULL DEFAULT NULL,
LXXVII
`campagne_modification_date` DATETIME NULL DEFAULT NULL,

`campagne_external_id` VARCHAR(255) NULL,
`campagne_external_source` VARCHAR(255) NULL,
`campagne_nom` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT
NULL,
`campagne_description` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NOT NULL,
`campagne_date_lancement` DATETIME NOT NULL,
`campagne_type` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT
NULL,
`campagne_duree` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT
NULL,
PRIMARY KEY (ìd`))
ENGINE = InnoDB
AUTO_INCREMENT = 2
COMMENT = 'Stocke la définition de la campagne marketing';
-- -----------------------------------------------------
-- Table `dmpxo`.àction`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.àction` (
`campagne_id` INT(11) NULL DEFAULT NULL,
àction_insertion_date` DATETIME NULL DEFAULT NULL,
àction_modification_date` DATETIME NULL DEFAULT NULL,
àction_external_id` VARCHAR(255) NULL,
àction_nom` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT
NULL,
àction_description` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci'
NOT NULL,
àction_date` DATETIME NOT NULL,
àctioncol` VARCHAR(45) NULL,
PRIMARY KEY (ìd`),
INDEX ÌDX_47CC8C9216227374` (`campagne_id` ASC),
LXXVIII
CONSTRAINT `FK_47CC8C9216227374`
FOREIGN KEY (`campagne_id`)
REFERENCES `dmpxo`.`campagne` (ìd`))
ENGINE = InnoDB
AUTO_INCREMENT = 2
COMMENT = 'Stocke la définition de l\'action de la campagne marketing';
-- -----------------------------------------------------
-- Table `dmpxo`.`messagedefinition`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`messagedefinition` (
àction_id` INT(11) NULL DEFAULT NULL,
`messagedefinition_insertion_date` DATETIME NULL DEFAULT NULL,
`message_modification_date` DATETIME NULL DEFAULT NULL,
`messagedefinition_type` VARCHAR(255) CHARACTER SET 'utf8' COLLATE
'utf8_unicode_ci' NOT NULL COMMENT 'email OU\nSMS',
`messagedefinition_libelle` VARCHAR(255) NOT NULL,
`messagedefinition_description` VARCHAR(255) CHARACTER SET 'utf8' COLLATE
'utf8_unicode_ci' NULL,
`messagedefinition_statut` VARCHAR(255) CHARACTER SET 'utf8' COLLATE
'utf8_unicode_ci' NULL,
PRIMARY KEY (ìd`),
INDEX ÌDX_B6BD307F9D32F035` (àction_id` ASC),
CONSTRAINT `FK_B6BD307F9D32F035`
FOREIGN KEY (àction_id`)
REFERENCES `dmpxo`.àction` (ìd`))
ENGINE = InnoDB
AUTO_INCREMENT = 2
COMMENT = 'Stocke la définition du message envoyé (nom, SMS ou email)';
-- -----------------------------------------------------
-- Table `dmpxo`.`liendefinition`
-- -----------------------------------------------------
LXXIX
CREATE TABLE IF NOT EXISTS `dmpxo`.`liendefinition` (

`message_id` INT(11) NULL DEFAULT NULL,
`liendefinition_insertion_date` DATETIME NULL DEFAULT NULL,
`liendefinition_modification_date` DATETIME NULL DEFAULT NULL,
`liendefinition_libelle` VARCHAR(255) CHARACTER SET 'utf8' NULL DEFAULT NULL,
`liendefinition_description` VARCHAR(255) CHARACTER SET 'utf8' NULL DEFAULT
NULL,
`liendefinition_url` VARCHAR(255) CHARACTER SET 'utf8' NULL DEFAULT NULL,
PRIMARY KEY (ìd`),
INDEX ÌDX_C71C56FD537A1329` (`message_id` ASC),
CONSTRAINT `FK_C71C56FD537A1329`
FOREIGN KEY (`message_id`)
REFERENCES `dmpxo`.`messagedefinition` (ìd`))
ENGINE = InnoDB
AUTO_INCREMENT = 5
COMMENT = 'Stocke les infos de définition des liens ou des TAGs';
-- -----------------------------------------------------
-- Table `dmpxo`.`lienresultat`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`lienresultat` (
`contact_id` INT(11) NULL DEFAULT NULL,
`liendefinition_id` INT(11) NULL DEFAULT NULL,
`lienresultat_insertion_date` DATETIME NULL DEFAULT NULL,
`lienresultat_modification_date` DATETIME NULL DEFAULT NULL,
`lienresultat_record_date` DATETIME NULL DEFAULT NULL COMMENT 'Date du clic sur
email',
PRIMARY KEY (ìd`),
INDEX ÌDX_E182EBEAE7A1254A` (`contact_id` ASC),
INDEX `FK_resultatlien_liendefinition_idx` (`liendefinition_id` ASC),
LXXX
CONSTRAINT `FK_E182EBEAE7A1254A`
REFERENCES `dmpxo`.`contact` (ìd`),
CONSTRAINT `FK_resultatlien_liendefinition`
FOREIGN KEY (`liendefinition_id`)
REFERENCES `dmpxo`.`liendefinition` (ìd`)
ON DELETE NO ACTION
ENGINE = InnoDB
AUTO_INCREMENT = 23
COMMENT = 'Stocke le résultat des clics sur des liens/tags d\'une page d\'atterrissage d\'une
campagne XO-MATIC ou de navigation du site web';
-- -----------------------------------------------------
-- Table `dmpxo`.`messageresultat`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`messageresultat` (
`contact_id` INT(11) NULL DEFAULT NULL,
`messagedefinition_id` INT(11) NULL DEFAULT NULL,
`messageresultat_insertion_date` DATETIME NULL DEFAULT NULL,
`messageresultat_modification_date` DATETIME NULL DEFAULT NULL,
`messageresultat_record_date` DATETIME NOT NULL,
`messageresultat_is_adresse` TINYINT(1) NOT NULL,
`messageresultat_is_abouti` TINYINT(1) NOT NULL,
`messageresultat_is_cliqueur` TINYINT(1) NULL,
PRIMARY KEY (ìd`),
INDEX ÌDX_271FABA1537A1329` (`messagedefinition_id` ASC),
INDEX ÌDX_271FABA1E7A1254A` (`contact_id` ASC),
CONSTRAINT `FK_271FABA1537A1329`
FOREIGN KEY (`messagedefinition_id`)
REFERENCES `dmpxo`.`messagedefinition` (ìd`),
LXXXI
CONSTRAINT `FK_271FABA1E7A1254A`
REFERENCES `dmpxo`.`contact` (ìd`))
ENGINE = InnoDB
AUTO_INCREMENT = 136
COMMENT = 'Stocke le résultat de l\'envoi du message par rapport à un contact et une définition
de message';
-- -----------------------------------------------------
-- Table `dmpxo`.`projectexecutant`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`projectexecutant` (
ìd` INT NOT NULL,
èxecutant_id` INT NOT NULL,
`projet_id` INT NOT NULL,
PRIMARY KEY (ìd`),
INDEX `fk_projectexecutant_executant_idx` (èxecutant_id` ASC),
INDEX `fk_projectexecutant_projet1_idx` (`projet_id` ASC),
CONSTRAINT `fk_projectexecutant_projet1`
FOREIGN KEY (`projet_id`)
REFERENCES `dmpxo`.òperation` (ìd`)
ON DELETE NO ACTION
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `dmpxo`.`versioning`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`versioning` (
`bundle` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL,
`bundle_repository_name` VARCHAR(255) CHARACTER SET 'utf8' COLLATE
'utf8_unicode_ci' NOT NULL,
LXXXII
`version` VARCHAR(255) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL,

`latest_kernel_files_loaded` TINYINT(1) NULL DEFAULT NULL,
`latest_project_files_loaded` TINYINT(1) NULL DEFAULT NULL,
PRIMARY KEY (ìd`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `dmpxo`.`resaparking`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`resaparking` (
ìd` INT NOT NULL,
`resaparking_insertion_date` DATETIME NULL,
`resaparking_modification_date` DATETIME NULL,
`resaparking_date_reservation` DATETIME NULL,
`resaparking_date_annulation` DATETIME NULL,
`resaparking_date_entree` DATETIME NULL,
`resaparking_date_sortie` DATETIME NULL,
`resaparking_service` VARCHAR(255) NULL,
`resaparking_quantite` INT NULL,
`resaparking_montant` FLOAT NULL,
PRIMARY KEY (ìd`),
INDEX `fk_parking_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_parking_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke les infos de réseervation de parking';
-- -----------------------------------------------------
-- Table `dmpxo`.`recherches- en v2`
LXXXIII
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`recherches- en v2` (
`recherches_insertion_date` VARCHAR(45) NULL,
`recherches_modification_date` DATETIME NULL,
`recherches_nom` VARCHAR(255) NOT NULL,
`recherches_creation_date` DATETIME NULL,
`recherches_criteres` VARCHAR(255) NULL,
`recherches_is_actif` TINYINT(1) NULL,
PRIMARY KEY (ìd`),
INDEX `fk_recherches_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_recherches_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke les recherche définies dans le compte utilisateur du site web';
-- -----------------------------------------------------
-- Table `dmpxo`.`resavoyage`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`resavoyage` (
ìd` INT NOT NULL,
`resavoyage_insertion_date` DATETIME NULL,
`resavoyage_modification_date` DATETIME NULL,
`resavoyage_date_reservation` DATETIME NULL,
`resavoyage_date_depart` DATETIME NULL,
`resavoyage_date_retour` DATETIME NULL,
`resavoyage_destination` VARCHAR(255) NULL,
LXXXIV
`resavoyage_compagnie` VARCHAR(255) NULL,

`resavoyage_montant` FLOAT NULL,
PRIMARY KEY (ìd`),
INDEX `fk_reservation_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_reservation_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke les réservations de voyage depuis HAVAS';
-- -----------------------------------------------------
-- Table `dmpxo`.òptinlast`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.òptinlast` (
òptinlast_insertion_date` DATETIME NULL COMMENT 'system',
òptinlast_modification_date` DATETIME NULL COMMENT 'system',
òptinlast_source` VARCHAR(255) NULL COMMENT 'Source de la demande d\'optin:
newsletter, bon-plans, info parking, etc...',
òptinlast_categorie` VARCHAR(255) NULL,
òptinlast_ss_categorie` VARCHAR(255) NULL,
òptinlast_decision_date` DATETIME NULL COMMENT 'date de la prise de décision par le
contact',
òptinlast_is_ok` TINYINT(1) NULL COMMENT 'ok ou pas ok pour utiliser le canal cible pour
envoyer de l\'info au contact',
PRIMARY KEY (ìd`),
INDEX `fk_optin_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_optin_contact1`
LXXXV
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke les infos d\'optin pour toutes les sources de communication avec le contact.
Unicité sur contact_id et source.';
-- -----------------------------------------------------
-- Table `dmpxo`.ìmport`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.ìmport` (
ìmport_insertion_date` DATETIME NULL,
ìmport_modification_date` DATETIME NULL,
ìmport_date_maj` DATETIME NULL,
ìmport_fichier_source` VARCHAR(255) NULL,
ìmport_nom_source` VARCHAR(255) NULL,
ìmport_page` VARCHAR(255) NULL,
ìmport_code` VARCHAR(255) NULL,
PRIMARY KEY (ìd`),
INDEX `fk_origine_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_origine_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke les infos de recrutement, import et origine (1er import)';
-- -----------------------------------------------------
-- Table `dmpxo`.`scoreresultat`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`scoreresultat` (
LXXXVI
ìd` INT NOT NULL,

àction_id` INT(11) NOT NULL,
`scoreresultat_insertion_date` DATETIME NULL,
`scoreresultat_modification_date` DATETIME NULL,
`scoreresultat_record_date` DATETIME NULL,
`scoreresultat_score` VARCHAR(255) NULL,
PRIMARY KEY (ìd`),
INDEX `fk_resultatscore_action1_idx` (àction_id` ASC),
INDEX `fk_resultatscore_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_resultatscore_action1`
REFERENCES `dmpxo`.àction` (ìd`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_resultatscore_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke le SCORE remonté par la\'action de campagne liée par XO-MATIC';
-- -----------------------------------------------------
-- Table `dmpxo`.àboparking`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.àboparking` (
àboparking_insertion_date` DATETIME NULL,
àboparking_modification_date` DATETIME NULL,
àboparking_date_abonnement` DATETIME NULL,
LXXXVII
àboparking_date_debut` DATETIME NULL,

àboparking_date_fin` DATETIME NULL,
àboparking_nom` VARCHAR(255) NULL,
àboparking_frequence` VARCHAR(255) NULL,
àboparking_montant` FLOAT NULL,
PRIMARY KEY (ìd`),
INDEX `fk_aboparking_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_aboparking_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB
-- -----------------------------------------------------
-- Table `dmpxo`.òptinlog`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.òptinlog` (
òptinlog_insertion_date` DATETIME NULL COMMENT 'system',
òptinlog_modification_date` DATETIME NULL COMMENT 'system',
òptinlog_source` VARCHAR(255) NULL COMMENT 'Source de la demande d\'optin:
newsletter, bon-plans, info parking, etc...',
òptinlog_categorie` VARCHAR(255) NULL,
òptinlog_ss_categorie` VARCHAR(255) NULL,
òptinlog_decision_date` DATETIME NULL COMMENT 'date de la prise de décision par le
contact',
òptinlog_is_ok` TINYINT(1) NULL COMMENT 'ok ou pas ok pour utiliser le canal cible pour
envoyer de l\'info au contact',
PRIMARY KEY (ìd`),
INDEX `fk_optin_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_optin_contact10`
LXXXVIII

ON DELETE NO ACTION
ENGINE = InnoDB
-- -----------------------------------------------------
-- Table `dmpxo`.`tagresultat`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`tagresultat` (
ìd` INT NOT NULL,
àction_id` INT(11) NOT NULL,
`tagresultat_insertion_date` DATETIME NULL,
`tagresultat_modification_date` DATETIME NULL,
`tagresultat_record_date` VARCHAR(45) NULL,
`tagresultat_name` VARCHAR(255) NULL,
PRIMARY KEY (ìd`),
INDEX `fk_resultatscore_action1_idx` (àction_id` ASC),
INDEX `fk_resultatscore_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_resultatscore_action10`
REFERENCES `dmpxo`.àction` (ìd`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_resultatscore_contact10`
ON DELETE NO ACTION
ENGINE = InnoDB
COMMENT = 'Stocke le SCORE remonté par la\'action de campagne liée par XO-MATIC';
LXXXIX
-- -----------------------------------------------------
-- Table `dmpxo`.ènvie`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.ènvie` (
ènvie_insertion_date` DATETIME NULL,
ènvie_modification_date` DATETIME NULL,
ènvie_reference` VARCHAR(255) NULL COMMENT 'réference de l\'envie (numéro 1, 2,
3...)\nou ref interne site web',
ènvie_intitule` VARCHAR(255) NULL COMMENT 'Intitulé de l\'envie',
ènvie_record_date` DATETIME NULL,
ènvie_is_actif` TINYINT(1) NULL COMMENT 'J\'aime ou pas',
PRIMARY KEY (ìd`),
INDEX `fk_envie_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_envie_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `dmpxo`.`navigation`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`navigation` (
`navigation_insertion_date` DATETIME NULL,
`navigation_modification_date` DATETIME NULL,
`navigation_titre_page` VARCHAR(255) NULL,
`navigation_langue_page` VARCHAR(255) NULL,
XC
`navigation_url_page` VARCHAR(255) NULL,

`navigation_referrer` VARCHAR(255) NULL,
`navigation_record_date` DATETIME NULL,
PRIMARY KEY (ìd`),
INDEX `fk_navigation_contact1_idx` (`contact_id` ASC),
CONSTRAINT `fk_navigation_contact1`
ON DELETE NO ACTION
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `dmpxo`.`resavoyagepax`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `dmpxo`.`resavoyagepax` (
ìd` INT NOT NULL,
`resavoyage_id` INT NOT NULL,
`resavoyagepax_insertion_date` DATETIME NULL,
`resavoyagepax_modification_date` DATETIME NULL,
`resavoyagepax_nom` VARCHAR(255) NULL,
`resavoyagepax_prenom` VARCHAR(255) NULL,
`resavoyagepax_date_naissance` DATETIME NULL,
PRIMARY KEY (ìd`),
INDEX `fk_resavoyagepax_resavoyage1_idx` (`resavoyage_id` ASC),
CONSTRAINT `fk_resavoyagepax_resavoyage1`
FOREIGN KEY (`resavoyage_id`)
REFERENCES `dmpxo`.`resavoyage` (ìd`)
ON DELETE NO ACTION
XCI
ENGINE = InnoDB;
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
Annexe 3
XCII
Annexe 4
XCIII
TABLE DES MATIERES
SOMMAIRE .........................................................................................................................................I
DÉDICACE ........................................................................................................................................ II
SIGLES ET ABRÉVIATIONS .......................................................................................................... III
LISTE DES FIGURES.......................................................................................................................IV
LISTE DES TABLEAUX ................................................................................................................... V
LEXIQUES ........................................................................................................................................VI
REMERCIEMENTS ........................................................................................................................ VII
AVANT - PROPOS ....................................................................................................................... VIII
ABSTRACT .......................................................................................................................................IX
INTRODUCTION GÉNÉRALE ......................................................................................................... 1
PREMIERE PARTIE : GENERALITES ......................................................................................... 3
CHAPITRE-1. : PRÉSENTATION DE LA STRUCTURE D’ACCUEIL ............................... 4
1.1 PRÉSENTATION DE LINK TO BUSINESS ............................................................. 4
1.1.1 MISSIONS ............................................................................................................... 4
1.1.2 ORGANISATION ................................................................................................... 5
1.2 PRÉSENTATION DU SERVICE D’ACCUEIL ......................................................... 6
CHAPITRE-2. : PRÉSENTATION ET CADRAGE DU PROJET .......................................... 7
2.1 CONTEXTE................................................................................................................. 7
2.2 DOMAINE D’ACTIVITÉ CONCERNÉE .................................................................. 7
2.3 OBJECTIFS DU PROJET ........................................................................................... 8
2.4 REVUE DOCUMENTAIRE ....................................................................................... 8
DEUXIÈME PARTIE : ÉTUDE PRÉALABLE ............................................................................. 9
CHAPITRE-3. : ÉTUDE ET ANALYSE DE L’EXISTANT ................................................. 10
3.1 ETUDE DE L’EXISTANT ........................................................................................ 10
3.1.1 Description du système actuel................................................................................ 10
3.1.2 Modélisation du système actuel (État des lieux) .................................................... 10
3.2 CRITIQUE DE L’EXISTANT .................................................................................. 10
CHAPITRE-4. : PROPOSITION ET CHOIX DE SOLUTION ............................................. 12
4.1 ÉBAUCHE DE SOLUTIONS ................................................................................... 12
4.1.1 Première solution ................................................................................................... 12
4.1.1.1 Description de la solution ................................................................................ 12
4.1.1.2 Avantages ........................................................................................................ 12
4.1.1.3 Inconvénients................................................................................................... 12
4.1.2 Deuxième solution ................................................................................................. 13
4.1.2.2 Avantages ........................................................................................................ 13
XCIV
4.1.2.3 Inconvénients................................................................................................... 13
4.1.3 Troisième solution.................................................................................................. 13
4.1.3.2 Avantages ........................................................................................................ 14
4.1.3.3 Inconvénients................................................................................................... 14
4.1.4 Quatrième solution ................................................................................................. 15
4.1.4.2 Avantages ........................................................................................................ 15
4.1.4.3 Inconvénients................................................................................................... 16
4.2 CHOIX DE LA SOLUTION ..................................................................................... 16
TROISIEME PARTIE : ETUDE DETAILLEE DE LA SOLUTION RETENUE ....................... 18
PARTIE : ETUDE DETAILLEE DE LA SOLUTION RETENUE .............................................. 18
CHAPITRE-5. : ETUDE FONCTIONNELLE ....................................................................... 19
5.1 MÉTHODE D’ANALYSE ET DE CONCEPTION DU SYSTÈME ........................ 19
5.1.1 Merise..................................................................................................................... 19
5.1.1.1 La démarche ou le cycle de vie ....................................................................... 19
5.1.1.2 Le Raisonnement ou le cycle d’abstraction;.................................................... 20
5.1.1.3 La maîtrise ou le cycle de décision. ................................................................ 20
5.1.2 UML et le processus Unifié ................................................................................... 21
5.1.2.1 Déclinaisons du Processus Unifié ................................................................... 22
5.2 ETUDE COMPARATIVE ET CHOIX DE LA METHODE D’ANALYSE ............ 23
5.3 JUSTIFICATION DU CHOIX .................................................................................. 24
5.4 METHODOLOGIE 2TUP ......................................................................................... 26
5.4.1 Historique ............................................................................................................... 26
5.4.2 Les deux phases du 2TUP ...................................................................................... 26
5.4.3 Etude détaillée des phases 2TUP ........................................................................... 27
CHAPITRE-6. : ETUDE ORGANIQUE ................................................................................ 29
6.1 ANALYSE ET CONCEPTION DU SYSTÈME ....................................................... 29
6.1.1 Capture des besoins fonctionnels ........................................................................... 29
6.1.1.1 Identification des cas d’utilisation et structuration en packages ..................... 29
6.1.2 Diagramme de cas d’utilisations ............................................................................ 29
6.1.2.1 Formalisme ...................................................................................................... 30
6.1.2.2 Modélisation .................................................................................................... 31
6.1.3 Description textuelle des cas d’utilisation ............................................................. 31
6.1.4 Diagramme de séquence ........................................................................................ 35
6.1.4.1 Définition......................................................................................................... 35
6.1.4.2 Formalisme ...................................................................................................... 36
6.1.4.3 Modélisation .................................................................................................... 37
6.1.5 Développement du modèle statique ....................................................................... 37
XCV
6.1.5.1 Formalisme ...................................................................................................... 38

6.1.5.2 Modélisation .................................................................................................... 38
6.1.6 Capture des besoins techniques.............................................................................. 41
6.1.6.1 Organisation de l’application en couches logicielles ...................................... 41
6.1.6.2 Plateforme de développement ......................................................................... 43
6.1.6.2.1 SGBD ....................................................................................................... 43
6.1.6.2.2 Le système d’exploitation ........................................................................ 44
6.1.6.2.3 Développement du modèle dynamique .................................................... 44
6.1.7 Diagrammes d’activités.......................................................................................... 45
6.1.7.1 Formalisme ...................................................................................................... 45
6.1.7.2 Présentation ..................................................................................................... 46
6.2 IMPLEMENTATION DU SYSTEME ...................................................................... 47
6.2.1 Equivalence entre les termes objets et relationnels ................................................ 47
6.2.2 Règles de passage................................................................................................... 47
6.2.3 Script de création de la base de données ................................................................ 48
6.2.4 Modèle physique .................................................................................................... 49
QUATRIEME PARTIE : IMPLEMENTATION ET DEPLOIEMENT DE LA SOLUTION ...... 53
CHAPITRE-7. : ETUDE TECHNIQUE ET RÉALISATION ................................................ 54
7.1 ÉTUDE TECHNIQUE ............................................................................................... 54
7.2 RÉALISATION ......................................................................................................... 54
7.2.1 Présentation des outils utilisés ............................................................................... 54
7.2.2 Présentation des fonctionnalités ............................................................................. 55
7.2.2.1 Lister les fonctionnalités mise en œuvre ......................................................... 55
7.2.2.2 Approche algorithmique (fonctions, objets etc.) ............................................. 55
7.2.2.3 Description de la mise en œuvre des principales fonctionnalités .................... 58
7.2.2.4 Les différentes difficultés rencontrées ............................................................ 59
7.2.2.5 Les solutions apportées ................................................................................... 59
7.2.2.6 Architecture générale de la solution ................................................................ 60
7.3 SECURITE DU SYSTEME....................................................................................... 61
CHAPITRE-8. : DEPLOIEMENT ET PRESENTATION DU SYSTEME FINAL............... 62
8.1 DEPLOIEMENT ........................................................................................................ 62
8.1.1 Notion..................................................................................................................... 62
8.1.2 Modélisation........................................................................................................... 63
8.2 PRÉSENTATION DE QUELQUES ÉCRANS ......................................................... 65
8.1 ESTIMATION FINANCIÈRE .................................................................................. 69
CONCLUSION GENERALE ET PERSPECTIVES ......................................................................... 71
BIBLIOGRAPHIE ET WEBOGRAPHIE ................................................................................. LXXIII
ANNEXES ................................................................................................................................ LXXIV
TABLE DES MATIERES ........................................................................................................... XCIV
XCVI
XCVII

Langue

Memoire Version Finale 1

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

Memoire Version Finale 1

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DE COTE D’IVOIRE

MEMOIRE DE FIN D’ETUDE

CONCEPTION D'UN OUTIL DECISIONNEL

Encadreur pédagogique Maître de stage

Ce document est dédicacé à ma famille.

MAGIR: Master Génie Informatique et Réseau

CRM: Customer Relationship Management

RH: Ressources Humaines

HTML: HyperText Markup Language

XUP: eXtrem Programming Unified Process

RUP: Rational Unified Process

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

LTBT: Link To business Technology

LISTE DES FIGURES

LISTE DES TABLEAUX

XO-CDP : Nom de commercial donné par LTBT à la plateforme de gestion.

XO-MATIC : Nom de commercial donné par LTBT de l’outil de marketing automation

MAUTIC : est un outil de Marketing Automation permettant de planifier et exécuter des

et besoins des membres de celle-ci. [16]

digitaux. Le terme est probablement appelé à disparaître dans la mesure où le marketing à

leurs formats originaux ou sont très peu transformées. [19]

utilisateurs, et souvent spécialisé vers un groupe ou un type d'affaire. [20]

La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes

d’Ivoire pour l’enseignement de qualité dispensé. Cette formation dans le parcours

Nous voudrions ensuite adresser toute notre reconnaissance à la Direction de Link to

savoir Monsieur Marc Zogoury, notre encadreur pédagogique, et Monsieur Nicolas

alimenter notre réflexion.

personnes à nous faire découvrir le sujet de notre mémoire.

témoignons notre gratitude pour les conseils judicieux.

d’Ivoire. Il comptabilise plus de 50 ans d’expérience en matière de formation de haut niveau.

notre formation, sanctionnée par le présent mémoire.

efficiente et l'analyse de données massives : Cas d’un grand aéroport français».

The realized tool is presented as a solution for an improvement of the productivity of

C’est dans un environnement fortement complexe et hautement concurrentiel

aux attentes du marché, de la clientèle et de leurs partenaires.

systèmes opérationnels « transactionnels » s’avèrent limités, voire inaptes à fournir de telles

informations et constituer par là même un support à la prise de décision.

différents : e-commerce, grande distribution, médecine ou encore dans le marketing.

en plus difficiles à exploiter vu le volume de données et les multiples formats à prendre en

Dans le souci de transformer ces données recueillies en des données globalement

ce faire, nous avons jugé indispensable de le charpenter autour de quatre parties.

présentation de la structure d’accueil ainsi que la présentation du projet proposé.

également les bases nécessaires à la compréhension de la suite de notre travail.

une description de la méthode choisie.

et l’implémentation puis le déploiement du système global ainsi que quelques captures

PREMIERE PARTIE : GENERALITES

CHAPITRE-1. : PRÉSENTATION DE LA STRUCTURE D’ACCUEIL

Nous présenterons dans ce chapitre, les activités et infrastructures informatiques de Link

1.1 PRÉSENTATION DE LINK TO BUSINESS

 Link to Business Bâtiment : agence de conseil en marketing opérationnel et relationnel

 Link to Business Technology : conception et développement de solutions web

appelée plateforme Marketing XO (datant de 2010).

d’acquérir une plateforme dédiée à l’animation de leur réseau de distribution et

dites « prêt à porter ». Ces services permettent aux clients d’automatiser et de

de distribution tout en assurant un suivi et un contrôle constant et global de l’activité

secteurs variés allant de l’automobile (Total) à l’alimentaire (Carrefour) en passant par

local en proposant des services permettant l'optimisation et la simplification de la

 XO-CDP, Customer Data Platform, pour centraliser votre connaissance client.

offres avec chaque client, et acquérir de nouveaux clients.

utilisateur UX) les fonctions à fortes valeurs ajoutées du Marketing Automation.

Link to Business est implantée non seulement à Grenoble, en Auvergne-Rhône-Alpes,

La figure ci-dessous (Figure 1) présente l’organigramme de Link To Business Technology.