Rapport Final001

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 161

 

  Conception et réalisation d’un système de   
Monitoring et d’analyse de rejets pour 
l'implémentation d'un projet CRM  
ZOUAOUI Khaled 

2008/2009 

 
Ministère de l’enseignement supérieur et de la recherche
scientifique

Ecole Nationale Supérieure d’Informatique (E.S.I)


Oued-Smar Alger

Mémoire de fin d’études


Pour l’obtention du diplôme d’ingénieur d’état en informatique

Option : Systèmes d’Information

Thème
 
«Conception et réalisation d’un système de monitoring et d’analyse de rejets

  pour l'implémentation d'un projet CRM»

Volet : suivi et traitement des rejets pour la migration des données


 
dans le carde d’un projet CRM.

Réalisé par : Proposé par :

Mr. ZOUAOUI Khaled Mr. K.KTATA

  

Promotion: 2008/2009
Ecole Nationale Supérieure d’Informatique (ESI)

Conception et réalisation d’un système de monitoring et


d’analyse de rejets pour l’implémentation d’un projet CRM

ZOUAOUI Khaled

Ecole nationale supérieure d’informatique

MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

DU DIPLÔME D’INGENIEUR D’ETAT EN INFORMATIQUE

(SYSTEMES D’INFORMATION)

SEPTEMBRE 2009

© ZOUAOUI Khaled, 2009.


Remerciements

C’est avec l’aide de Dieu qu’a vu le jour ce présent travail.

Ensuite, il n’aurait pas pu être achevé sans le soutien, les conseils et les
encouragements de certaines personnes auxquelles je tiens ici à exprimer mes sincères
remerciements.

En premier lieu, j’exprime toute ma gratitude pour mes Promoteurs, Monsieur


K.KTATA et Madame L.GRIRA ainsi que toute l’équipe CRM pour leurs précieux
conseils, leurs disponibilité, la confiance qu’ils m’ont toujours témoigné et la sollicitude
dont ils m’ont entouré, et ce tout au long de l’élaboration du présent travail.

Je n’oublie pas non plus mes Enseignants, qui tout au long du cycle d’études à
l’Institut National d’Informatique, m’ont transmis leur savoir.

J’adresse une pensée particulièrement à Monsieur A.HAKOUMI et tous Mes Amis de


l’INI, qui ont rendu agréables mes longues années d’études.

Je remercie tout particulièrement Les Membres du Jury, pour avoir accepté de


participer en tant qu'Examinateurs à ma soutenance.

Je tiens enfin à remercier tous ceux qui ont collaborés de près ou de loin à
l’élaboration de ce travail. Qu’ils acceptent mes humbles remerciements.

 
Dédicaces
 

Je dédie ce modeste travail,

A celle qui a attendu avec patience les fruits de sa bonne éducation….


A ma mère.

A celui qui m’a indiqué la bonne voie en me rappelant que la volonté


fait toujours les grands hommes…

A mon père.

A mes chers frères Mehdi et Abderrahmane, Aucun mot ne pourra


exprimer ma gratitude envers vous.

A Tous les Membres de Ma Famille Paternelle et Maternelle.

A tous mes Amis et à Tous les Collègues de Promotion.

A tous mes collègues de travail.

A tous ceux qui me sont chers.

K. ZOUAOUI
                                   RÉSUMÉ 

Le cycle de vie d’un opérateur de téléphonie mobile commence par une phase de
croissance rapide avec des acquisitions massives d’abonnés. Au fur et à mesure de la
saturation du marché, le coût d’acquisition d’un abonné devient de plus en plus élevé,
l’opérateur à tendance donc à privilégier la fidélisation de ses clients. De ce fait, notre
opérateur Nedjma Wataniya Télécom s’est projeté sur l’élaboration d’un Customer
Relationship Management. C’est un système qui mise à mettre le client au cœur des
préoccupations afin d’améliorer sa satisfaction qui implique l’augmentation de son profil,
cependant durant une étape du projet, nous aurons une migration de la base de Nedjma du
système existant vers le nouveau acquit, cette étape va engendrer des données qui seront
rejetées par le nouveau système ce qui risque de faire perdre de l’information, alors notre rôle
est de traiter ces données rejetées.

Le système que nous avons développé comporte deux interfaces : une dédiée à
l’administrateur pour y configurer entre autre les règles, une seconde pour l’utilisateur afin de
faire les traitements possibles sur les rejets.

Pour assurer la réutilisation et la bonne maintenance de notre système, nous avons


choisi de structurer l’architecture de l’application en trois couches : l’accès aux données
communiquant avec la base de données et le noyau métier comportant tous les composants
métier de notre système, développés sous la plateforme J2SE, et enfin la couche présentation
qui a été implémentée suivant la méthode MVC (Modèle Vue Contrôleur)

La réalisation d’un tel système nécessite, avant tout, d’appréhender et d’adopter les
briques théoriques et conceptuelles servant à définir le cadre de travail. C’est ce que nous
avons tenté de faire en nous appuyant sur la méthodologie itérative du 2TUP. 

Mot clés : CRM, fidélisation client, UML, 2TUP, Architecture Multi-Tier, Java, J2SE,
Siebel
TABLE DES MATIÈRES 

1.  CONTEXTE GENERAL : ............................................................................................................1 


2.  PROBLEMATIQUE...................................................................................................................4 
3.  OBJECTIFS DE L’ETUDE : .........................................................................................................6 
4.  ORGANISATION DU MEMOIRE :.............................................................................................7 

PARTIE I : ETAT DE L’ART 
1.GENERALITES ET DEFINITIONS....................................................................................................9 
    1.1.Definition du marketing : ........................................................................................................................ 9 
    1.2.L’orientation client ou marketing client : ................................................................................................ 9 
        1.2.1.Définition : ....................................................................................................................................... 9 
        1.2.2.Historique :..................................................................................................................................... 10 
            1.2.2.1.L´0rientation client : des années 50 a l’an 2000........................................................................ 10 
            1.2.2.2.La relation client : une nouvelle prise de conscience de la place du client................................ 12 
        1.2.3.Du marketing transactionnel au marketing relationnel .................................................................. 13 
        1.2.4.Marketing relationnel..................................................................................................................... 14  
            1.2.4.1.Présentation :........................................................................................................................... 14  
            1.2.4.2.Les formes du marketing relationnel........................................................................................ 15  
2.LE CUSTOMER RELATIONSHIP MANAGEMENT (CRM) :.............................................................17 
    2.1.D’où vient le concept CRM ? ................................................................................................................. 17 
    2.2.Qu’est ce qu’un CRM ?.......................................................................................................................... 18 
        2.2.1.Définition: ...................................................................................................................................... 18 
        2.2.2.Stratégie : ....................................................................................................................................... 20 
        2.2.3.Méthodologie :............................................................................................................................... 21 
    2.3.Pourquoi le CRM ? ................................................................................................................................ 22 
    2.4.Les typologies de fonctions concernées: ............................................................................................... 24 
    2.5.Les processus et fonctionnalités concernés........................................................................................... 25 
    2.6.Les Outils CRM:..................................................................................................................................... 29 
    2.7.Les principaux objectifs :....................................................................................................................... 32 
    2.8.Les avantages du CRM: ......................................................................................................................... 33 
    2.9.Les inconvénients de la mise en place de CRM:..................................................................................... 34 
    2.10.Les contraintes du CRM:...................................................................................................................... 35 
3.CONCLUSION............................................................................................................................35 

 
PARTIE II : Cas WTA Nedjma 

CHAPITRE 1 : 
PRESENTATION DE L’ENTREPRISE NEDJMA 

1.PRESENTATION DE L’ENTREPRISE D’ACCUEIL ...........................................................................39 
    1.1.Présentation générale de Nedjma......................................................................................................... 39 
    1.2.Présentation générale de QTEL ............................................................................................................. 39 
    1.3.Logo Nedjma......................................................................................................................................... 39 
    1.4.Organigramme...................................................................................................................................... 40 
    1.5.Chiffre clés de Nedjma .......................................................................................................................... 41 
    1.6.Actionnaires.......................................................................................................................................... 42 
    1.7.Parts de marché de WTA....................................................................................................................... 42 
    1.8.Les missions de Nedjma ........................................................................................................................ 43 
    1.9.Les objectifs de Nedjma ........................................................................................................................ 43 
2.ETUDE DE L’ENVIRONNEMENT DE L’ENTREPRISE .....................................................................43 
    2.1.La clientèle............................................................................................................................................ 43 
    2.2.Produits et services............................................................................................................................... 44 
3.CONCLUSION ............................................................................................................................................ 45 

CHAPITRE 2 : 
ANALYSE DE L’EXITANT DÉCISIONNEL 
1.LE SYSTEME ACTUEL : ...............................................................................................................47 
    1.1.Description de l’outil CRM Nedjma : ..................................................................................................... 47 
    1.2.Le service concerné par l’étude............................................................................................................. 49 
    1.3.Critique concernant les postes de travails :........................................................................................... 52 
    1.4.Positionnement du système CRM dans le schéma d’architecture de WTA: ........................................... 53 
    1.5.Description globale du système actuel :................................................................................................ 54 
        1.5.1.Extraction et chargement initiale des données............................................................................... 55 
        1.5.2.Synchronisation des données entre BSCS et SIEBEL. ....................................................................... 56 
        1.5.3.Enchaînement des processus IDL\DBL : .......................................................................................... 56 
    1.6.Chargement des données :.................................................................................................................... 57 
    1.7.Description des étapes du chargement des données sur SIEBEL :.......................................................... 58 
    1.8.Présence de données rejetées :............................................................................................................. 59 
    1.9.Diagnostique de l’existant :................................................................................................................... 60 
2.CONCLUSION............................................................................................................................60 
CHAPITRE 3 : 
ETUDE DU CONCEPT 
1.INTRODUCTION ........................................................................................................................62 
2.ORGANISATION DE L’ETUDE DU CONCEPT. ..............................................................................63 
3.PARTIE A :.................................................................................................................................64 
4.PARTIE B :.................................................................................................................................65 
    4.1. UML : ................................................................................................................................................... 65 
    4.2.Processus Unifié (Unified Process): ....................................................................................................... 66 
5.PARTIE C : .................................................................................................................................68 
    5.1.Etude préliminaire : .............................................................................................................................. 69 
        5.1.1.Identification des acteurs : ............................................................................................................. 69  
    5.1.2.Rôle des acteurs ............................................................................................................................. 70  
    5.1.3.Modéliser le contexte :................................................................................................................... 70  
5.2.Capture des besoins fonctionnels : ....................................................................................................... 73 
    5.2.1.Recueil initial des besoins fonctionnels et opérationnels :.............................................................. 74 
    5.2.2.Identification des cas d’utilisation : ................................................................................................ 75  
    5.2.3.Etude détaillée des cas d’utilisation :.............................................................................................. 79  
    5.2.4.Organisation des cas d’utilisation : ................................................................................................. 99  
        5.2.4.1.Relation entre cas d’utilisation :............................................................................................... 99  
        5.2.4.2.Organisation des cas d’utilisation en packages :..................................................................... 102 
    5.2.5.Identification des classes candidates : .......................................................................................... 107  
5.3.Capture des besoins techniques.......................................................................................................... 109 
    5.3.1.L’architecture applicative multicouche......................................................................................... 109  
    5.3.2.Architecture logique de l’application............................................................................................ 110  
    5.3.3.Spécification technique de point de vu de matériel...................................................................... 111 
    5.3.4.Élaboration du modèle de spécification logicielle......................................................................... 114 
5.4.Découpage en catégorie...................................................................................................................... 116 
5.5.Développement du modèle statique................................................................................................... 117 
5.6.Développement du modèle dynamique : ............................................................................................ 121 
    5.6.1.Analyse des états :........................................................................................................................ 121  
    5.6.2.Identification des scénarios: ......................................................................................................... 122  
5.7.Conception générique......................................................................................................................... 126 
    5.7.1.Organisation des Framework technique ....................................................................................... 127  
    5.7.2.Description des noyaux : .............................................................................................................. 128  
5.8.Conception préliminaire ..................................................................................................................... 129 
    5.8.1.Développement du modèle de déploiement ................................................................................ 129 
5.9.Conception détaillée........................................................................................................................... 130 
        5.9.1.Affinage des classes et extraction des méthodes : ........................................................................ 130 
        5.9.2.Description des méthodes : .......................................................................................................... 132  
        5.9.3.Passage au modèle relationnel : ................................................................................................... 134  
 6.CONCLUSION :....................................................................................................................... 135 

CHAPITRE 4 :
IMPLEMENTATION ET SECURITE DU SYSTEME
1.IMPLEMENTATION : ...............................................................................................................137 
    1.1.Outils de développement :.................................................................................................................. 137 
        1.1.1.Langage de programmation :........................................................................................................ 137  
        1.1.2.Environnement de travail : ........................................................................................................... 137  
        1.1.3.Système de Gestion de Base de Données (SGBD) :........................................................................ 137 
        1.1.4.Environnement de développement : ............................................................................................ 138  
2.LA SECURITE INFORMATIQUE :...............................................................................................138 
    2.1.Les risques : ........................................................................................................................................ 139 
        2.1.1.Classification des risques : ............................................................................................................ 139  
    2.2.La politique de sécurité du nouveau système :.................................................................................... 140 
        2.2.1.La sécurité au niveau du système d’exploitation : ........................................................................ 140 
        2.2.2.La sécurité au niveau de l’application et des données : ................................................................ 141 
        2.2.3.Sécurité du réseau : ...................................................................................................................... 142  
        2.2.4.Protection et sauvegarde des données : ....................................................................................... 142  
        2.2.5.La sécurité physique du matériel : ................................................................................................ 142  
 
CONCLUSION GENERALE : .........................................................................................................144 

 
 

LISTE DES TABLEAUX 

Tableau 1 : Marketing transactionnel et Marketing relationnel ......................................................................... 13 


Tableau 2 : Messages entrants et sortants du système. ...................................................................................... 73 
Tableau 3 : Les différents cas d’utilisation....................................................................................................... 78 
Tableau 4 : Tableau récapitulatif des packages des cas d’utilisation................................................................ 107 
Tableau 5: Liste des classes objet. ................................................................................................................ 119 
Tableau 6: Liste des classes associations....................................................................................................... 119 
Tableau 7: Liste affinée des classes Objet. .................................................................................................... 132 
Tableau 8 : Description des méthodes............................................................................................................ 134 
Tableau 9: Légende des objets...................................................................................................................... 134 
Tableau 10 : Privilèges accordés aux utilisateurs............................................................................................ 142 
 

LISTE DES FIGURES  

Figure 1: Marketing relationnel ...................................................................................................................... 15


Figure 2: Le cercle Vertueux du Client ............................................................................................................ 23
Figure 3: Logo Nedjma ................................................................................................................................... 39
Figure 4: Organigramme de Nedjma................................................................................................................ 40
Figure 5 :Parts de marché des trois opérateurs WTA, OTA et Mobilis.............................................................. 43
Figure 6: Cycle de vie d’une phase du projet. .................................................................................................. 49
Figure 7: Positionnement du système actuel dans le schéma d’architecture de WTA......................................... 53
Figure 8: Les étapes de l’extraction et chargement initiale des données. ........................................................... 55
Figure 9 :Les étapes de synchronisation des données entre BSCS et SIEBEL. .................................................. 56
Figure 10: Enchainement des processus IDL\DBL dans le temps .................................................................... 56
Figure 11 : Structure du l’EIM ........................................................................................................................ 58
Figure 12: Description des étapes du chargement des données sur SIEBEL. .................................................... 58
Figure 13 : Structure interne de l’EIM. ............................................................................................................ 59
Figure 14 : Schéma du principe de la solution.................................................................................................. 65
Figure 15 : La démarche 2TUP........................................................................................................................ 68
Figure 16: Diagramme de contexte. ................................................................................................................ 72
Figure 17 : Diagramme du cas d’utilisation « Définir les sources des rejets» .................................................... 79
Figure 18 : Diagramme d’activité du cas d’utilisation « Définir les sources des rejets » .................................... 80
Figure 19 : Diagramme du cas d’utilisation « Récupérer les rejets» .................................................................. 80
Figure 20: Diagramme d’activité du cas d’utilisation « Récupérer les rejets ».................................................. 81
Figure 21: Diagramme du cas d’utilisation « Configurer les règles de classification des rejets» ....................... 82
Figure 22: Diagramme d’activité du cas d’utilisation « Configurer les règles de classification des rejets » ....... 83
Figure 23 : Diagramme du cas d’utilisation « catégoriser les rejets»................................................................. 84
Figure 24 : Diagramme d’activité du cas d’utilisation « catégoriser les rejets »................................................. 85
Figure 25 : Diagramme du cas d’utilisation « configurer les critères d’assignation des rejets»........................... 86
Figure 26: Diagramme d’activité du cas d’utilisation «Configurer les règles d’assignation des rejets».............. 87
Figure 27: Diagramme du cas d’utilisation «Assigner un rejet»....................................................................... 88
Figure 28 : Diagramme d’activité du cas d’utilisation « Assigner un rejet »...................................................... 89
Figure 29: Diagramme du cas d’utilisation «Prendre en charge un rejet» ......................................................... 90
Figure 30 : Diagramme d’activité du cas d’utilisation « Prendre en charge un rejet »........................................ 91
Figure 31: Diagramme du cas d’utilisation «Changer le statut d’un rejet»........................................................ 92
Figure 32: Diagramme d’activité du cas d’utilisation « Changer le statut d’un rejet » ...................................... 93
Figure 33 : Diagramme du cas d’utilisation «Remise des rejets corrigés dans la source (recyclage) »................ 93
Figure34 : Diagramme d’activité du cas d’utilisation «Remise des rejets corrigés dans la source (recyclage)» . 94
Figure 35 : Diagramme du cas d’utilisation «Consulter les informations relative à un rejet » ............................ 95
Figure 36 : Diagramme d’activité du cas d’utilisation «Consulter les informations relative à un rejet» .............. 96
Figure 37 : Diagramme du cas d’utilisation « Consulter l’historique de traitement d’un rejet » ......................... 97
Figure 38 : Diagramme d’activité du cas d’utilisation « Consulter l’historique de traitement d’un rejet » .......... 99
Figure 39: Relation d’inclusion du cas « Authentification des utilisateurs »................................................... 100
Figure 40: Relation d’inclusion du cas « Définir le points de récupération des rejets »................................... 100
Figure 41 : Relation d’inclusion du cas « Configurer les règles de classification des rejets»............................ 101
Figure 42: Relation d’inclusion du cas « Configurer les règles de classification des rejets»............................. 101
Figure 43: Relation d’inclusion du cas « changer le statut d’un rejet»............................................................. 101
Figure 44: Relation d’extension du cas « Interroger la base de connaissances». .............................................. 101
Figure 45: Relation d’extension du cas « Catégoriser les rejets ».................................................................... 101
Figure 46: Relation d’extension du cas « Changer le statut d’un rejet ». ......................................................... 102
Figure 47: Diagramme des cas d’utilisation du package « administration du système »................................... 102
Figure 48: Diagramme des cas d’utilisation du package « Récupération des rejets » ....................................... 103
Figure 49: Diagramme des cas d’utilisation du package « Catégorisation des rejets » ..................................... 103
Figure 50: Diagramme des cas d’utilisation du package « Traitement d’un rejet » .......................................... 104
Figure 51: Diagramme des cas d’utilisation du package « Remise des rejets ». ............................................... 104
Figure 52: Diagramme des cas d’utilisation du package « Historique »........................................................... 105
Figure 53: Diagramme des cas d’utilisation du package « Base de connaissance ».......................................... 105
Figure 54: Diagramme des cas d’utilisation du package « rapports et statistiques »......................................... 106
Figure 55: Diagramme des classes candidates pour le package « Administration » ......................................... 107
Figure 56: Diagramme des classes candidates pour le package Récupération des rejets»................................ 107
Figure 57: Diagramme des classes candidates pour le package « Catégorisation des rejets» ............................ 108
Figure 58: Diagramme des classes candidates pour le package « Traitement des rejets».................................. 108
Figure 59: Diagramme des classes candidates pour le package « Historique» ................................................. 108
Figure 60: Diagramme des classes candidates pour le package « Base de connaissance» ................................ 109
Figure 61: Architecture en cinq couches. ....................................................................................................... 110
Figure 62: Architecture applicative de notre système. .................................................................................... 110
Figure 63: Schéma représentant une architecture 2-tiers................................................................................. 111
Figure 64: Schéma d’une architecture 2-tiers avec un serveur de base de données .......................................... 112
Figure 65: Schéma d’une architecture 2-tiers ................................................................................................. 113
Figure 66: Schéma d’une architecture 3-tiers avec serveur web...................................................................... 113
Figure 67. Modèle de spécification logicielle du système. .............................................................................. 115
Figure 68: Diagramme de déploiement. ......................................................................................................... 116
Figure 69: Diagramme représentant le découpage en catégories ..................................................................... 116
Figure 70: Diagramme des classes................................................................................................................. 120
Figure 71 :les états possibles des rejets dans le système DBL et monitoring. .................................................. 121
Figure 72: Diagramme d’états-transitions de l’entité « Rejet ». ...................................................................... 122
Figure 73 :Diagramme de séquence du scénario « Catégoriser les rejets ». ..................................................... 122
Figure 74 :Diagramme de séquence du scénario « Ajouter une catégorie rejet». ............................................. 123
Figure 75 :Diagramme de séquence du scénario « Assigner les rejets ». ......................................................... 123
Figure 76 :Diagramme de séquence du scénario « Prendre en charge un rejets »............................................. 124
Figure 77: Diagramme de séquence du scénario «Consulter l’historique de traitement d’un rejet ». ................ 124
Figure 78: Diagramme de séquence du scénario « Remise des rejets ». .......................................................... 125
Figure 79: Diagramme de séquence du scénario « Consulter base de connaissance». ...................................... 125
Figure 80: Diagramme de séquence du scénario « Changement d’affectation de groupe d’un utilisateur »....... 126
Figure 81: Diagramme de séquence du scénario « Authentification de l’utilisateur ». ..................................... 126
Figure 82: Organisation du modèle logique ................................................................................................... 128
Figure 83 : Modèle de déploiement ............................................................................................................... 130
Liste des abreviations:
CRM: Customer relationship management

EDGE: Enhanced Data for GSM Evolution

GPRS: General Packet Radio Service

GSM: Global System for Mobile

MMS: Multimedia Messaging Service

EDGE: Enhanced Data for GSM Evolution

PTT: Push-to-talk

SFA: Sales Forces Automation

SIM: Subscriber Identity Module

SMS: Short Message Service

WAP: Wireless Application Protocol

BSCS:

IDL: Initial Data Load

DBL: Daily Batch Load

EIM: Entreprise Integration Manager

PIN:
 

 
INTRODUCTION GENERALE 
 

 
                                                                                                                                           Introduction générale

1. Contexte général :

• Le boom de la téléphonie mobile en Algérie

Même les experts en télécommunication n’en revienne pas et d’ailleurs qui aurait cru
que le marché de la téléphonie mobile en Algérie atteindrait des résultats nettement supérieur
aux estimations avancées par des responsables du secteur, lesquels soutenaient il y’a de cela
4ans que le nombre d’utilisateur de la technologie GSM atteindrait les 10 millions a l’horizon
2010 et les 23 millions en 2015. Qu’en est-il en cette fin d’année 2008 : on parle de prés de 26
millions d’abonnées1. Un véritable succès.

Dès lors, dire qu’il y’a eu explosion dans le marché national de la téléphonie mobile
n’est aucunement erroné ou exagéré vu la dynamique persistante qui régné et qui règne
actuellement sur ce dernier. Sur cette dynamique orchestrées par les trois opérateurs qui se
partagent le marché du GSM en Algérie, a savoir Orascom Télécom Algérie (OTA\Djezzy),
Algérie Télécom et sa filiale Mobilis (ATM) et, enfin, le dernier opérateur entrant Wataniya
Télécom Algérie (WTA\Nedjma) est venus se greffer une kyrielle de distributeurs de
portables portant les noms des plus grands constructeurs de terminaux cellulaires et qui ont,
eux aussi créé des activités connexes faisant vivre de centaines de personnes ; quand a savoir
le nombres d’abonnés de chacun des trois opérateurs en cette périodes, l’autorités de la
régularisation de la poste et des télécommunication (ARTP) avance que Djezzy à atteint la
barre des 14 millions d'abonnés2; Suivi de Mobilis avec 8.5 millions3, et en dernier, Nedjma
avec plus de 5 millions d’utilisateurs de son réseau.

• La bataille commerciale :
Dans le marché du GSM, les trois opérateurs que sont OTA\Djezzy, AT Mobilis et
WTA\Nedjma se livrent une bataille a coups d’offres promotionnelles et où chacun y va de sa
propre stratégie pour tenter et de gagner d’autres clients et de communiquer plus : les tarifs
d’appels sont de moins en moins chers et par tranche horaire plus longue. Chaque opérateur à
au moins trois chevaux de bataille avec ses dernier temps un léger plus chez WTA\Nedjma, ce
qui d’ailleurs le rend plus agressif pour défendre son titre de leader Algérien du multimédia
« Nous avons dans notre escarcelle beaucoup d’offres a lancer et avec 50% de nos abonnés
qui sont équipés d’un téléphone multimédia, ce qui montre que ces services que nous

                                                             
1 Source site ‐ http://www.algeriesite.com. Lundi 01 décembre 2008. 
2 Source site ‐ http://www.djezzygsm.com.  
3 Source journal  ‐le midi‐  http://www.lemidi‐dz.com. Edition du 30 Mars 2009. 

 

 
                                                                                                                                           Introduction générale

sommes les premiers à développer en Algérie ont de beaux jours devant eux » tel est
l’argument avancé par le parton de Nedjma en réponse à la question de concurrence, et
d’ajouter : « il ne s’agit pas juste d’essayer d’avoir plus de clients mais c’est de les fidéliser
qui est le plus important. Et pour se faire, il suffit de donner toujours une meilleure qualité
de service et beaucoup d’avantages aux clients. Toujours le meilleur et rester a l’écoute de
nos abonnés, voila la devise de Nedjma » 4

• La dynamique innovatrice de Nedjma :

Nul doute que les nombreuses innovations en matière d’offres commerciales décidées
par l’opérateur Wataniya Télécom Algérie (WTA\Nedjma) tout le long de l’année 2008 ont
largement contribué à ce que Nedjma dépasse les 5 millions d’abonnés. Une prouesse qui fait
de Nedjma le leader Algérie du multimédias sur le marché mobile de type GSM.

• Nedjma par rapport aux autres opérateurs :

Wataniya Télécom avec son entré en scène en septembre 2004 a eu comme impact de
booster un peu plus le marché de la téléphonie mobile en Algérie et de laisser un peu plus sur
la défensive les deux autres opérateurs en ce sens que toute la stratégie commerciale de
Nedjma reposait sur l’innovation en mettant sur le marché les dernière technologies, c'est-à-
dire permettre a ses clients d’user de MMS, du WAP, etc. certes, cette démarche consistant à
développer les options multimédias et permettre leur accessibilité aux accros a donné de
l’effet puisque Nedjma, au bout de 4 ans d’activité en Algérie, a dépassé la borne de 5
millions d’abonné actif, on peut qualifier ce résultat de performance en ce sens que WTA est
arrivé en dernier sur le marché5.

Mais malgré tout ces résultats et ces efforts, Nedjma est encore loin derrière le leader
incontesté du marché mobile Algérien qui est Orascom Télécom Algérie qui domine avec plus
de 14 millions d’abonné, Djezzy depuis le 11 juillet 2001, date a laquelle il s’est vu attribuer
la 2eme licence GSM pour un montant de 737 millions de dollars, sept mois plus tard, il est
procédé a la mise en marche du réseau GSM. Août 2002 : lancement de la carte prépayée pour
la première fois en Algérie sous le nom commercial « Eich la vie » 6 une formule dont on dit
qu’elle a démocratisé le marché algérien.

                                                             
4 Source Document interne de Nedjma. 
5 Source Document interne de Nedjma. 
6 Source site ‐ http://www.djezzygsm.com.  

 

 
                                                                                                                                           Introduction générale

Donc pour pouvoir concurrencer les deux autres opérateurs qui ont déjà pris de l’avance,
Nedjma se voit dans l’obligation d’améliorer ses compétences et sa compétitivité afin
d’affirmer voir améliorer sa place au niveau du marché algérien car savoir cibler, attirer et
conserver les bons clients sont les facteurs déterminants du succès de nombreuses entreprise.
Or, construire et développer des relations avec ses clients est un challenge, particulièrement
lorsque l’entreprise possède des milliers voir des millions de clients qui communiquent avec
celle-ci de multiples manières, pour cela, Nedjma a compris que la clés de la croissance ce
sont ses clients c’est la raison pour la quel elle s’est intéressé a ces derniers avant que d’autres
ne le fasse a sa place, le client est ainsi devenu le principal sujet de conversation et de
mobilisation, on étudie alors toute ses facettes.

Voila pourquoi les responsables de Nedjma se sont penchés sur l’élaboration d’un
système de Gestion des Relations Clients –Customer Relationship Management (CRM) en
anglais- qui permet de mieux comprendre ses clients pour adapter et personnaliser leurs
produits ou leurs services.

 

 
                                                                                                                                           Introduction générale

2. Problématique
Le secteur de la téléphonie mobile connaît une grande expansion étant un marché très
lucratif en accord avec les évolutions technologiques. En effet, en Algérie le marché compte
trois opérateurs. Dans le contexte d’un tel marché en plein développement, le cycle de vie
d’un opérateur de téléphonie mobile commence par une phase de croissance rapide avec des
acquisitions massives d’abonnés. Au fur et à mesure de la saturation du marché, le coût
d’acquisition d’un abonné devient de plus en plus élevé, l’opérateur à tendance donc à
privilégier la fidélisation de ses clients.

L’opérateur Wataniya Telecom Algérie (WTA) a pénétré le marché algérien en 2004 et


compte maintenant plus de 5 millions abonnés. De ce fait, il est plus important de retenir ses
clients que d’acquérir de nouveaux prospects car satisfaire les clients actuels coûte 5 fois
moins cher que d’acquérir un nouveau client, Pour cela Nedjma a positionné le client au cœur
de ses préoccupations et a pris l’initiative d’élaborer un système de gestion de la relation
client CRM.

Cependant le nombre de client est devenu trop important et les systèmes actuels de
gestion ne permettent pas d’approprier un CRM, c’est pour ça que Nedjma s’est projeté sur
l’acquisition de l’outil du leader mondial en CRM « SIEBEL », alors durant une étape du
projet il y’a une migration de la base de données global des clients du système existant vers le
nouveau système CRM, cette étape très importante a généré les lacunes suivantes :

• La migration des données entre les différentes étapes d’éxtraction et chargement


engendre des rejets de données.
• L’existance des rejets va générer un disfonctionnement entre le système existant et le
CRM ce qui implique une perte de données qui correspond a une perte de clients existants
ce qui implique un déficit d’argent et de bénéfices.
• Le traitement actuel des données rejetées se fait d’une façon manuelle ce qui a engendré
une grand retard dans le traitement des données et une perte de temps et d’agrent

Les causes principales des problèmes cités ci-dessus sont les suivantes:

• Manque d’information pour l’analyse et le traitement des rejets.


• Absence de moyen pour identifier et classifier les rejets.
• Pas de suivi des rejets.

 

 
                                                                                                                                           Introduction générale

• Absence de solutions pour un éventuel recyclage des rejets.


• Les niveaux de traitement des rejets non identifiées
• Parmi les cas des données rejetées il y’a :
9 Incompatibilité entre les données.
9 Type de champ non conforme.
9 Erreur de syntaxe.
9 Champs obligatoire oublié.
9 Erreur de codification.
• Absence de rapport et statistiques sur les données rejetées.

Enfin, pour pouvoir résoudre ces problèmes, la mise en place d’un système de
monitoring et de synchronisation des données pouvant regrouper les indicateurs pertinents cité
ci dessous est indispensable, permettra au département CRM de mieux contrôler ses données
tout cela dans un environnement où se développe de plus en plus l’aspect de cohérence.

 

 
                                                                                                                                           Introduction générale

3. Objectifs de l’étude :
L’objectif principal de notre projet est de proposer une solution informatique à la
problématique posée, concrètement cela consiste à doter le service CRM d’un système de
monitoring et d’analyse des rejets pour l'implémentation d'un projet CRM. Ceci va nous
permettre d’avoir une vision plus claire sur la migration des données du système existant vers
la nouvelle application de gestion de la relation client.

Notre projet a pour vocation essentielle de :

• Réduire la perte des données qui concernent les clients ce qui va impliquer une
fidélisation optimal afin d’améliorer le profil de l’entreprise.
• Automatiser et accélérer le traitement des rejets pour un gain de temps précieux.
• Eviter les redondances dans le traitement des rejets.
• Créer et enrichir au fil du temps une base de connaissance afin de disposer d’un outil
d’aide pour les utilisateurs pour trouver les solutions aux problèmes déjà résolus.
• Elaborer et publier les statistiques et les rapports nécessaires pouvant servir à améliorer la
qualité de traitement.

Il est donc indispensable de se sensibiliser à l'importance de la procédure de migration et


de fournir des méthodes efficaces de traitement et de prévention et cela se réalise en :

• Mettant en place une interface de monitoring des données.


• Détectant et Analysant les rejets.
• Traitant et classifiant les rejets.
• Assignant les rejets aux équipes traitantes.
• Assainissant les rejets (Manuel ou automatique).
• Intégrant la notion du WorkFlow, cette dernière consiste à suivre les étapes de traitement
et d’assainissement des données rejetées.
• Définissant les différentes étapes de transition des rejets.
• Ayant l’historique de toutes les transitions pendant un cycle de traitement.

En résumé, le but de notre solution est de fournir aux dirigeants des informations
synthétiques, au moment opportun, permettant ainsi d’avoir une image reflétant au mieux la
situation de la migration des données.

 

 
                                                                                                                                           Introduction générale

4. Organisation du mémoire :
Afin de présenter le travail qui nous a été assigné. Nous avons organisé notre travail en
deux parties principales :

La première partie concerne l’aspect théorique, dans cette partie nous présenterons une
synthèse sur le Customer Relationship Management (CRM) et les techniques conceptuelles
qui permettent de le bâtir conformément aux objectifs de l’entreprise. Nous allons montrer les
concepts de base d’un CRM, ses origines et le marketing relationnel, les typologies de
fonctions concernées, les processus et fonctionnalités concernées, les outils CRM et les
avantages et inconvénients de sa mise en place.

La deuxième partie concerne l’aspect pratique de notre travail, dans laquelle nous
étudierons le cas de l’entreprise WTA Nedjma. Cette partie sera divisée en 5 chapitres où
chaque chapitre représente l’une des étapes nécessaire dans la construction de notre solution.

Ces chapitres sont :

4.1 Présentation générale de l’organisme d’accueil :


Sera consacré à la présentation de l’entreprise WTA Nedjma, son environnement et sa
structure.

4.2 Analyse de l’existant décisionnel :


Dans ce chapitre nous allons présenter l’analyse de l’existant décisionnel ; en décrivant
le projet « Orbit » CRM de Nedjma et en présentant le service concerné par l’étude, le
positionnement du système actuel dans le schéma d’architecture de WTA ainsi qu’une
description global du système.

4.3 Etude du concept :


Constitue une phase très importante pour notre projet. Nous allons voir dans ce chapitre
l’approche utilisée dont l’objectif est de déterminer de façon détaillée et précise ce que le
nouveau système devrait être afin de répondre aux besoins des utilisateurs finaux.

Ce chapitre englobe l’étude préliminaire, capture des besoins fonctionnels, capture des
besoins techniques, découpage en catégorie, développement du modèle statique et dynamique,
conception générique, primaire et détaillée.
4.4 Implémentation et sécurité du système:

Ce chapitre englobe l’implémentation et la sécurité de notre système.

4.5 Conclusion générale :


Nous achèverons notre document par une conclusion générale.

 

 
 

PARTIE I : ETAT
  DE L’ART

sYNTHESE SUR LE CUSTOMER   RELATIONSHIP MANAGEMENT 
 

 
PARTIE I                                                                                                                          Synthèse sur le CRM 

1. Généralités et définitions

Pour mieux comprendre notre projet, nous allons définir une multitude de notions et de
domaines que nous avons jugés indispensable d’aborder. Afin accompagner le lecteur, nous
commencerons par les concepts les plus généraux touchant aux domaines du Marketing et son
évolution passant par la notion du marketing client et le marketing relationnel pour arriver
finalement au concept du CRM en tant que technologie de l’information.

1.1. Définition du marketing :


Le marketing (appelé aussi par le néologisme mercatique) est une discipline qui
cherche à déterminer les offres de biens et services, Il existe deux sortes de définitions du
marketing, celles qui mettent l’accent sur le rôle sociétal et celles qui optent pour une
orientation managériale :

Du point de vu sociétale : « c’est le mécanisme économique et social par lequel


individus et groupes satisfont leurs besoins et désirs au moyen de la création et de l’échange
avec autrui de produits et sévices de valeurs » [Kot 03]

Dans sa dimension managériale, le marketing a souvent été assimilé à « l’art de


vendre ». Mais l’aspect le plus important du marketing n’est pas la vente, qui représente que
la partie immergée de l’iceberg. Comme l’explique Peter Drucker, un grand théoricien du
management :

« On aura toujours besoin, on peut le supposer, d’un effort de vente. Mais le but du
marketing est de rendre la vente superflue ; il consiste à connaître et comprendre le client à
un point tel que le produit ou le service lui conviennent parfaitement et se vendent d’eux-
mêmes. Dans l’idéal le marketing devrait avoir pour résultat un client prêt à acheter. Tout ce
dont on alors besoin est de rendre le produit ou le service disponible » [Kot 03]

1.2. l’orientation client ou marketing client :

1.2.1. Définition 7:

                                                             
7 Extrait du mémoire  « L’orientation client au marketing relationnel : Customer Relationship Management»  
réalisé par  Joumana Belkebir, Samia Tronnebati, Souad Belkahia Adnane Addioui, Safaa Sekkat. 2003/2004. 

 

 
PARTIE I                                                                                                                          Synthèse sur le CRM 

À mi-chemin entre le marketing produit et la vente, cette nouvelle discipline vise à


orienter l’offre de l’entreprise en fonction des besoins du marché et des clients.

Un marketing nouvelle génération, voilà comment les experts définissent, en substance,


le marketing client. « Auparavant, les industriels créaient un produit et le mettaient sur le
marché. Soit les clients adhéraient et achetaient, soit ils n’aimaient pas et les produits restaient
dans les rayons. Aujourd’hui, le contexte économique hyperconcurrentiel interdit une telle
approche. Pour être sûres d’écouler leurs stocks, les entreprises sont contraintes d’écouter et
d’anticiper les attentes du marché, et donc du client. » Relate Charles-Benoît Heidsieck,
consultant chez Orga Consultants. C’est là toute la valeur ajoutée du marketing client : mieux
orienter les travaux du marketing produit grâce à une meilleure connaissance du marché et des
besoins des consommateurs. Et réconcilier les deux frères ennemis de toujours : le marketing
et les ventes. « Le marketing client fait la jonction entre ces deux départements », confirme
Marie-Agnès Blanc, responsable des formations en management interentreprises à la Cegos.
Les sociétés l’ont bien comprise et sont de plus en plus nombreuses à accorder une place de
choix à cette nouvelle discipline. Des services entièrement dédiés voient même le jour au sein
de certaines entités.

1.2.2. Historique :

1.2.2.1. L´0rientation client : des années 50 a l’an 2000


a.L'ère préindustrielle : relation de proximité

L'ère préindustrielle s'est terminée plus ou moins récemment selon les secteurs. Pour
prendre l'exemple du commerce, l'apparition des grandes surfaces, les concentrations des
centrales d'achat et les pressions concurrentielles sur les petits commerces ont débuté il y a
quelques dizaines d'années. Auparavant, le commerce à destination du grand public était avant
tout bâti sur un modèle de valeurs de proximité, de fonds de commerce à taille humaine et de
relations personnelles, pour ne pas dire de voisinage.

b. Les fifties et sixties : reconstruction et push marketing

Les années 50 et 60 furent les années de la production de masse, il fallait proposer des
produits aux consommateurs pour répondre à une demande explosive. La demande était
simple, l'offre devait l'être également. Pendant cette période, les entreprises se sont
essentiellement concentrées sur la création de nouveaux produits et l'élargissement de l'offre.

 
10 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

c. Les seventies : segmentation de marchés et mass markets

Les années 70 furent les années de la rationalisation, L’optimisation de la production


visait à baisser les coûts de fabrication. Il fallait, par la combinaison d'une baisse des coûts,
d'une amélioration des processus de vente et de la création de nouveaux moyens, toucher la
clientèle et élargir la taille des marchés potentiels. Les entreprises ont commencé à segmenter
les clients et ont élargi leurs gammes de produits. La vente directe des années 70 constitue un
premier pas vers la relation client.

d. Les eighties : "consommateur" et one to many

Les années 80 furent les années de la qualité. Les exigences des consommateurs
commençant à se faire sentir, il fallait, pour satisfaire ceux-ci améliorer la qualité des
produits. Les entreprises se sont lancées dans la mesure de la qualité des produits et dans le
développement des services aux clients.

Pendant plus de trente ans, les entreprises ont perfectionné leurs techniques de
production et de gestion pour mieux connaître et maîtriser les produits. Dans la même
période, elles ont évidemment développé des approches du client, mais celles-ci sont restées
épisodiques et peu industrielles.

e. Les nineties : l'orientation client et le one to some

Depuis le début des années 90, le marché connaît une profonde modification avec
l'inversion du paradigme marketing : passage d'une orientation produit à une orientation
client. Les années 90 marquent le début de l'ère du client. Les bases de données client se
multiplient, l'essor du marketing direct met en avant les avantages de la relation directe. Les
canaux d'accès et d'information prolifèrent. Les années 90 et les années suivantes marquent un
recentrage sur le client.

f. l'inversion des relations client-fournisseur et le one to one

Sans aucun doute, les années 2000 marqueront l'intensification de cette tendance client
avec l'émergence du concept de marketing one to one : une offre spécifique pour chaque
client possible essentiellement grâce à l'avènement de l'Internet. Les entreprises, quelles que
soient leurs secteurs d'activité, concentreront leurs efforts sur le service et la gestion de la
relation client.

 
11 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

En parallèle, les nouveaux horizons ouverts par les technologies de communication et de


l'information dessinent également une inversion des rôles : le consommateur jouera un rôle de
plus en plus actif jusqu'à se substituer aux distributeurs, à s'autoconseiller et à assurer lui-
même son propre service client.

1.2.2.2. La relation client : une nouvelle prise de conscience de la place du client

™ Mieux vaut fidéliser que conquérir :

Il coûte entre 7 et 10 fois plus chère d’acquérir un client que d’en conserver un. Les
sociétés perdent la moitié de leurs clients en 5 ans8 .
Améliorer la rétention de 5 % peut doubler le profit. En effet, les travaux de Reichheld9
montrent les effets dramatiques de la perte de clients sur le résultat d’exploitation. Le fait de
réduire le taux d’attrition de 5 % se traduit par une croissance de revenus de 75 % dans
certains secteurs. Il est économiquement moins chère pour une entreprise de conserver et de
fidéliser sa clientèle que de chercher à élargir ses parts de marché par une politique
conquérante. Le ratio entre les deux peut atteindre un à dix selon le secteur d'activité. La santé
financière de l'entreprise est d'ailleurs évaluée en fonction du nombre des clients auxquels il
est attribué un "coût d'acquisition", le prix qu'il faut dépenser pour acquérir un nouveau client.
De même, que fidéliser coûte moins cher que de conquérir, la satisfaction du client est
un élément essentiel face à la concurrence10: 80 % des clients d’une entreprise seront
contactés par un de ces concurrents; 69 % des clients passent à la concurrence lorsqu’ils
rencontrent des difficultés de services ; 1 € dépensé en publicité rapporte 5€, investi en
service client, il en rapporte 60.

™ Un virage à 180 ° : Une mutation du marketing :

Pour Anderson Consulting et l’Economist Intelligence Unit, le virage à 180° correspond


à un nombre croissant d’entreprise se détournant d’une organisation par lignes de produit ou
divisions géographique au profit d’une structure axée sur les segments de client.
L'enquête sur la Gestion de la Relation Client menée en Amérique du Nord, en Europe
et en Asie auprès de 200 cadres dirigeants révèle les tendances suivantes : Près de 60% des

                                                             
   8 Extrait du mémoire  « L’orientation client au marketing relationnel : Customer Relationship Management»  
réalisé par  Joumana Belkebir, Samia Tronnebati, Souad Belkahia Adnane Addioui, Safaa Sekkat. 2003/2004. 
   9 Extrait du mémoire  « L’orientation client au marketing relationnel : Customer Relationship Management»  
réalisé par  Joumana Belkebir, Samia Tronnebati, Souad Belkahia Adnane Addioui, Safaa Sekkat. 2003/2004. 
 10 Extrait du mémoire  « L’orientation client au marketing relationnel : Customer Relationship Management»  
réalisé par  Joumana Belkebir, Samia Tronnebati, Souad Belkahia Adnane Addioui, Safaa Sekkat. 2003/2004. 

 
12 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

entreprises interrogées ont cité la « rétention de clients » au nombre de priorités pour les cinq
années à venir ; elles ne s’attachent plus tant a séduire le client qu’a le fidéliser. Les
entreprises affinent de plus en plus leurs méthodes d’évaluation de la rentabilité des clients.
Cette nouvelle démarche s’appuiera sur l’évolution des technologies interactives, et
notamment sur l’Internet, dont l’essor se confirme chaque jour.

1.2.3. Du marketing transactionnel au marketing relationnel

Comme toute science, le marketing a fait l’objet d’approches diachroniques ayant pour
finalité de retracer les évolutions des différents courants de pensée qui ont participé à la
construction du substrat théorique sur lequel il s’appuie. C’est Bartels (1965), le premier, qui
a souligné l’impossibilité de dégager, avant 1950, des écoles de pensées dans le champ du
marketing. Depuis, le marketing a connu un certain nombre d’évolutions qui l’ont conduit
d’une conception transactionnelle à une conception relationnelle de l’échange (flambard-
ruaud, 1997).

De la transaction à la relation :

Marketing transactionnel Marketing relationnel


ƒ Origine Grande consommation Industries et services
ƒ Stratégie Recrutement Développement, fidélisation
ƒ Avantage Economie d’échelle Economie de champs
ƒ Performance Part de marché Taux de nourriture
ƒ Interlocuteur Consommateur passif Coproducteur actif
ƒ Relation Indirecte (intermédiaires) Directe
ƒ Mode Méfiance, Conflit Confiance, Coopération
ƒ Horizon temporel Court terme Long terme
ƒ Echange Simple Complexe
ƒ Obligation Contractuelles Conventionnelles
ƒ Rapport Indépendance Interdépendance

Tableau 1 : Marketing transactionnel et Marketing relationnel11

                                                             
11  Extrait du mémoire  « L’orientation client au marketing relationnel : Customer Relationship 
Management»  réalisé par  Joumana Belkebir, Samia Tronnebati, Souad Belkahia Adnane Addioui, Safaa 
Sekkat. 2003/2004

 
13 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Cette orientation récente focalise aujourd’hui l’attention de bon nombre de chercheurs


(Aurier et Dubois, 1995) et le marketing relationnel apparaît actuellement comme un
domaine majeur de la stratégie marketing et tend à acquérir le statut de stratégie générique par
opposition au marketing transactionnel (Anderson 1994)

Cette évolution subtile et continue d'une approche de segmentation à une approche "sur
mesure" se manifeste dans un certains nombres de cas dont les plus commentés sont
certainement les jeans LEVI'S "custom made" ou encore le site APPLE sur Internet 12

LEVI'S, qui avait perdu du terrain face à l'émergence des marques de distributeurs, a
imaginé de fabriquer pour sa clientèle féminine des jeans sur mesure: un équipement
approprié permet à la société, dans les points de vente qu'elle gère en direct, de saisir et
d'enregistrer les mensurations de la cliente. Pour un tarif de 30% supérieur, le pantalon est
alors produit et livré en 2 à 3 semaines. Il peut être commandé à tout moment par téléphone.
Ainsi qu’APPLE ouvrait fin 1997 un site Internet dont la promotion dans la presse s'affichait
sous le titre "Look who's running the Factory" pour traduire sa capacité à faire des machines
"sur mesure". Cette initiative est à comparer à celle du category killer CompUSA, chaîne
américaine de magasins qui propose des ordinateurs construits sur mesure. Ils ont même
poussé cette stratégie jusqu'à ajouter la trade mark "Custom built for you" à leur enseigne.

1.2.4. Marketing relationnel

1.2.4.1. Présentation :

Né des travaux de Don Peppers et Martha Rogger, le marketing relationnel est aussi
appelé marketing one to one pour illustrer un objectif que chaque client se sente unique !

Selon Kotler & Dubois :

« Le marketing relationnel consiste à offrir d’excellents services aux clients grâce à


l’utilisation d’informations individualisées, avec pour objectifs la construction d’une relation
durable avec chacun d’entre eux » [Kot 03]

                                                             
12  Exemple tiré  du mémoire  « L’orientation client au marketing relationnel : Customer Relationship 
Management»  réalisé par  Joumana Belkebir, Samia Tronnebati, Souad Belkahia Adnane Addioui, Safaa 
Sekkat. 2003/2004

 
14 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Le marketing relationnel consiste dans son principe à accumuler de l’information sur le


consommateur dans des bases de données, en cela il est déjà une forme de néguentropie au
sens que lui donne Norbert Wiener. Sa vocation est ensuite d’évaluer la contribution de
chaque client à travers l’analyse des ventes passées, puis de le stimuler grâce aux outils du
marketing direct, fax, mailing, téléphone, internet.

Ainsi on peut schématiser le marketing relationnel de la manière suivante :

13
Figure 1: Marketing relationnel

Le marketing relationnel selon l’axe consommateur peut donc être décomposé en trois
phases, la collecte, l’analyse et la stimulation. Ces trois éléments devant obéir à la notion de
feed-back et rétroagir les uns sur les autres. Ainsi, le marketing relationnel s’inscrit dans une
perspective de communication de type circulaire. La base de données devant être
perpétuellement remise à jour par une communication dynamique en ponctuant1 les
séquences de communication ce qui détermine la qualité de la communication comme le
souligne Paul Watzlawick.

1.2.4.2. Les formes du marketing relationnel

a. Le marketing de base de données :


On distingue essentiellement trois types de bases de données :

                                                             
13  Extrait  du  mémoire    « L’orientation  client  au  marketing  relationnel  :  Customer  Relationship 
Management»    réalisé  par    Joumana  Belkebir,  Samia  Tronnebati,  Souad  Belkahia  Adnane  Addioui,  Safaa 
Sekkat. 2003/2004. 

 
15 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

) Les bases de données hiérarchiques :

Elles sont très utilisées dans le domaine de la gestion du personnel pour leur capacité à
décrire et à relier les différentes données concernant un individu dans sa vie dans l’entreprise,
mais qui sont peu adaptées aux analyses marketing. C’est un modèle qui consiste à organiser
des données de façon arborescente. Il n’y a pas de liaison entre les branches de même niveau,
ce qui en fait un modèle simple qui n’autorise que peu d’interrogation.

) Les bases de données objet :

Qui ouvrent des perspectives intéressantes, notamment par leur capacité à traiter des
données multimédia.
A partir de ce type de base, il est possible de construire de nouveaux types (ou classes)
qui participent eux-mêmes à la construction d’autres types et ainsi de suite. La construction se
fait par héritage simple, multiple ou par composition.

) Les bases de données relationnelles :

Qui sont basées sur la théorie de l’algèbre relationnel. Dans cette théorie, une relation
est représentée par des lignes d’une table.
Elles peuvent être décrites, pour simplifier, comme un ensemble de tableaux. Ainsi une
base de données clients comprendra le tableau des coordonnées des clients, le tableau de
l’historique des contacts, le tableau des produits achetés. La base de données relationnelle est
un outil parfaitement évolutif qui correspond bien aux attentes des services marketing, comme
par exemple ORACLE, INFORMIX, SYBASE, DBM…

b. Le marketing interpersonnel

Le responsable marketing doit identifier les meilleurs clients, reconnaître leur valeur et
les garder. Si l’entreprise projette d’améliorer la qualité et accroître sa clientèle, afin
d’augmenter sa part de marché, elle doit connaître la valeur à vie de cette dernière, tout en
développant des rapports suivis et personnalisés avec elle. Tout ceci aura pour conséquence la
fidélisation à la marque, par la mise en œuvre des programmes innovateurs de fidélisation des
campagnes de marketing, des campagnes personnalisées de publipostage direct, des
campagnes de marketing électronique et interactif, ainsi que des événements à l’intention des
consommateurs.

 
16 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

c. Le marketing des réseaux

Les réseaux sont nombreux, toute population identifiée et homogène est un réseau en
puissance, qui mérite une attention particulière pour optimiser son action.

Les réseaux sont variés, la vocation d'un réseau n'est pas uniquement la vente. Cela peut
être de prescrire, de représenter, d'influencer,...

Toutes ces logiques nécessitent un accompagnement régulier et rigoureux. Peu de


similitudes vont exister entre le Club des 250 clients grands comptes d'une multinationale, le
réseau de revendeurs d'un constructeur, le Club de super vendeurs européens, ou le réseau de
concessionnaires captifs, ou de courtiers en assurance, …

Dans tous les cas, la logique de gestion ou d'animation de ces réseaux est toujours
spécifique, et doit être adaptée à chaque situation.

2. Le customer relationship management (CRM) :

2.1. D’où vient le concept CRM ?

Dans les années 80, la prolifération des bases de données a permis aux entreprises
d’emmagasiner toutes sortes de données sur leurs clients.

Les besoins des plus grands comptes ont été les premiers à être traités par le biais de ces
données. Sinon, les informations concernant les petits clients n’étaient pas analysées sachant
bien qu’en étudiant leurs habitudes et en déterminant leurs besoins très spécifiques, de
nouveaux marchés pouvaient être crées.

Dans les années 90, les sociétés sont passées du simple recueil d’information sur leurs
clients, dans l’optique de répondre au mieux a leurs besoins, a la création d’un nouveau type
d’échange, qui enrichissait l’acte d’achat et de vente : la fidélisation.

La fidélisation des clients devient l’un des axes majeurs de développement de la relation
client et donc de la performance des entreprise.

Une stratégie de fidélisation doit :

• Développer et optimiser le capital client.

• Développer le marketing client.

 
17 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

• Améliorer le dispositif opérationnel de la relation client.

• Avoir une approche différenciée par segment de client.

Cette stratégie a eu pour résultat d’accroître les revenus et d’améliorer l’appréciation de


l’entreprise auprès de ses clients en leurs accordant des bons, des points bonus et d’autres
cadeaux.

Alors le passage d’une orientation produit a une orientation client est du évidemment a
la volonté des entreprises pour être a l’écoute de leurs clients de façon a anticiper leurs
besoins. Ce phénomène date du début des années 90et marque ainsi le début de l’ère du
client.

2.2. Qu’est ce qu’un CRM ?

Le CRM est apparu pendant l’euphorie de la nouvelle économie. Après l’éclatement de


la bulle internet, la prudence était le maître mot et par conséquent, les entreprises étaient
moins enclines à investir.

De plus, le CRM n’était pas encore bien compris et son positionnement était haut de
gamme, réservé principalement aux grands groupes internationaux. En définitive, les
conditions n’étaient pas optimales pour que les PME optent pour le CRM. Mais actuellement,
l’offre CRM s’élargit et de nombreuses sociétés proposent des systèmes CRM pour ces PME.

2.2.1. Définition14:

La Gestion de la Relation Client connue sous le nom anglo-saxon (Customer


Relationship Management) est la nouvelle fonction marketing créée dans l’entreprise. Née
d’un besoin accru de conquête et de reconquête des clients, le GRC aborde le marketing non
pas par la logique du produit mais par la logique du client : comment connaître le client, où le
trouver, comment le fidéliser et comment le retenir ?

Il se repose sur deux principes :

9 Tous les clients sont égaux

                                                             
14   Extrait du mémoire  « Y’a‐t‐il une différence entre la théorie du CRM et sa pratique ? »    Stage effectué au sein de 
RMA WATANYA. Réalisé par : Raouia Elhakimi. 
 

 
18 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

9 Le comportement suit la promesse de récompense

Le CRM ne constitue, en fait, rien de nouveau. Il a été à la base des échanges


commerciaux depuis longtemps. Ce qu’il y a de nouveau, ce sont les stratégies, les
technologies et applications qui désormais contribuent à une meilleure gestion de la clientèle,
de l’information sur les clients et de l’entreprise dans son ensemble.

En résumé, l’entreprise engrange des données sur ses clients. Générés par traitement
informatique, les profiles uniques décrivent avec un degré de granularité adéquat les
comportements des clients (habitudes de consommation, fréquence, dernier produit acheté et
même état émotionnel,…). L’accès à ce savoir recoupé permet aux fonctions managériales,
marketing, commerciales et service après vente, de mieux cibler leurs attentes et de les
satisfaire avec des informations, des Tips, des offres ou des produits appropriés.

Plus loin, cette connaissance amène l’entreprise à agir de manière proactive, en


développant des solutions à des besoins encore latents ou en sensibilisant ses clients à d’autre
service ou produit.

) Comprendre le client :
L’entreprise doit rassembler les informations lui permettant de décrire et de caractériser
sa clientèle, de la positionner sur son marché et de détecter de nouveau segments. Tous les
moyens technologiques existent aujourd’hui pour constituer, gérer et analyser des quantités
massives de données relatives aux clients. Ceci dans le but de mieux valoriser son capital
client.

D’un point de vue technique, le CRM implique de capturer, au niveau de l’entreprise,


l’ensemble des données clients, collectées en interne ou auprès d’organisme extérieurs, et de
les intégrer dans un Data Warehouse (entrepôt de données) orienté client.

) Choisir son client :


L’étape suivante consiste à analyser ces données avec les techniques les plus évoluées
Datamining, analyse statique et à rendre les résultats accessibles à tous les canaux
d’interactions avec les clients. Le Datamining permet d’analyser et d’interpréter un gros
volume de données, de différentes sources afin de dégager des tendances, de rassembler les

 
19 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

éléments similaires en catégories statistiques et de formuler des hypothèses. A partir des


informations collectées, l’entreprise pourra obtenir des réponses objectives sur lesquelles
fonder sa stratégie opérationnelle. La centralisation des données clients doit ainsi faciliter le
pilotage de toute l’activité de la société.

Ainsi il faut différencier les clients en fonction de leur besoin et de leur contribution au
résultat et dialoguer avec eux de manière à diminuer les coûts de la relation commerciale et à
en augmenter l’efficacité. C e dialogue doit permettre de faire remonter l’information.

) Conquérir de nouveaux clients :


La mise en œuvre d’une stratégie orientée client concerne l’ensemble du processus
commercial. Les nouveaux canaux de ventes (télévente, commerce électronique…) créent des
opportunités métiers.

) Fidéliser les meilleurs clients :


Les programmes de fidélisation bénéficient de nouvelles possibilités technologiques
telles que la carte à mémoire. Le service après vente devient l’occasion privilégiée de
concrétiser une relation personnalisée et durable avec le client, en lui proposant une offre
encore mieux adaptée à ses besoins. Le vecteur idéal de cette relation est le centre d’appel, qui
permet d’orchestrer tous les éléments de la stratégie client, depuis la base de connaissance qui
fournit la vue unique du client nécessaire a cette relation « one to one », jusqu’au scénario
personnalisé qui guide l’entretien pour lui présenter une offre adaptée a ces besoins.

Cette qualité de service supplémentaire permet à l’entreprise d’améliorer en permanence


sa connaissance du client, d’affiner sa stratégie et d’accroître son efficacité commerciale.

2.2.2. Stratégie :

Le CRM n’est pas simplement une technologie. C’est avant tout une stratégie
d’entreprise mettant le client au cœur d’un dispositif stratégique. Cette stratégie se formalise
notamment avec la mise en œuvre d’une solution capable de supporter la gestion des
processus concernés.

 
20 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Dans certain cas, cette mise en œuvre suppose la refonte des processus mais pas
nécessairement. Une solution CRM doit s’adapter à l’entreprise et se mettre au service de la
stratégie afin d’atteindre les objectifs fixés.

Il n’existe pas de recette pour assurer la bonne mise en place. Toutefois, un certain
nombre de précepte doit être respecté.

La satisfaction est nécessaire mais n’est pas suffisante pour conserver ses clients. Il
semble que les clients privilégient la qualité de la relation humaine qu’ils ont avec le
personnel de l’entreprise par rapport au produit en soi.

Incidemment on perd les clients essentiellement à la suite de ce qu’on pourrait qualifier


de bavure relationnelle plutôt qu’à cause d’une guerre de prix.

2.2.3. Méthodologie :

Un projet CRM n’est jamais figé puisqu’il est directement orienté sur la finalité de
l’entreprise à savoir, en augmentant la valeur pour les actionnaires.

La veille stratégique autant que l’intelligence d’affaires vont donc être mis à
contribution. Les bénéfices qui en découlent proviennent essentiellement d’une appropriation
par les acteurs à l’intérieur de l’entreprise de nouvelles connaissances qu’ils vont pouvoir
réintroduire dans l’action (Knowledge intelligence).

ƒ Vision exécutive :

Le déploiement d’une stratégie CRM ne débute pas avec la sélection d’un fournisseur
d’application. Il commence dés qu’un exécutif en exprime l’idée et manifeste la volonté d’y
regarder de plus pré. La direction doit en comprendre la portée afin de décider d’aller de
l’avant ou non. Cette étape consiste en exposés suivis s’échanges afin de partager la même
largeur de bande à propos du CRM.

ƒ Analyses stratégiques :

Le CRM est porteur de promesses en termes de croissance du chiffre d’affaire. Il mise


sur un recentrage de l’entreprise vers le client en plus du produit

 
21 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Il s’appuie sur une segmentation de la clientèle en fonction de sa valeur actuelle et


potentielle. Dés lors, il canalise les ressources en priorité vers les segments les plus profitables
en modulant les processus d’affaires.

Cette 2eme étape est incontournable et un gage de succès pour tout projet CRM.

ƒ Etude de faisabilité :

Dans tout projet CRM, il est judicieux d’en analyser la faisabilité afin d’élaborer ce qu’il
est convenu d’appeler le business case. Il s’agit de poser un diagnostic technologique,
d’évaluer les besoins, les alternatives technologiques pour y répondre et l’impact en terme de
rapport cout-bénéfices. Finalement les enjeux tant financiers que stratégiques sont précisés
tout comme les risques d’agir autant que de ne rien faire.

ƒ Gestion de projet :

La manifestation tangible d’un projet CRM, c’est l’implémentation des systèmes et la


formation du personnel. Toutefois, la gestion du changement tout comme la formation non
pas technique mais stratégique du personnel doit nécessairement être assumée par l’entreprise
elle-même. Il s’agit là de deux temps forts, en amont et en aval de l’implémentation, dont les
conséquences sont critiques pour la réussite d’un projet CRM.

Pour conclure, et à l’heure actuelle, l’attention est surtout portée sur la magie des
applications CRM. La performance des logiciels de CRM découle de leur intégration dans
l’environnement technologique de l’entreprise mais aussi avec ses processus d’affaire et avec
le tissu humain qui forme sa culture propre.

En bout de ligne, ce sont les employés d’une entreprise qui dans leurs relations avec les
clients au quotidien concrétisent une stratégie CRM alors que la méthodologie sert à les
mettre dans le coup.

2.3. Pourquoi le CRM ?

 
22 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Selon certains secteurs (ex : secteur bancaire), acquérir un nouveau client coûte
beaucoup plus cher que de garder un client déjà acquis. Selon les marchés que l'on considère,
ce rapport peut atteindre 1 à 5. Par conséquent, on comprend que l'entreprise doit certes
chercher à conquérir des parts de marché, mais doit aussi penser à améliorer la satisfaction de
ses clients. Améliorer la relation-client est au-delà des discours de mode une réelle nécessité.

Le début des années 90 a monopolisé l'attention et les ressources des entreprises sur la
mise en place de progiciels de gestion intégrés, d'applications bureautiques évoluant ensuite
vers le groupware et l'intranet, de projets de restructuration et de réorganisation de type BPR
(Business Process Re-engineering) ou de gestion de la qualité, autant d'interventions qui ont
plutôt orienté l'entreprise sur elle-même.

Les premières applications des entreprises tournées vers leurs clients intéressent en
premier lieu les équipes commerciales en permettant d'optimiser leurs tâches, de mieux
stocker les informations provenant du terrain et éventuellement de qualifier les contacts pris
par les commerciaux - grâce aux logiciels d'automatisation des forces de vente (SFA).

Viennent ensuite la création de centres d’appels qui visent à améliorer le service et le


support aux clients après- vente. Ce sont les débuts du CRM (Customer Relationship
Management) ou de la gestion de la relation client, un marché qui aujourd'hui s'envole.

Ce qui motive les entreprises à développer un outil CRM c’est :

• Obtenir un avantage concurrentiel en établissant une relation optimale avec son client :
adoptant une stratégie axée sur le client.

Figure 2: Le cercle Vertueux du Client

 
23 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

• Augmenter les revenus : depuis quelques temps, les entreprises ont mis l'accent sur la
réduction constante de leurs dépenses afin d'en augmenter leur profit, maintenant rendus
un point où difficile de couper plus leurs dépenses donc se tournent vers des solutions
axées sur l'augmentation de leurs revenus

• Maximiser le service à la clientèle : coûte plus cher pour gagner un nouveau client que de
le conserver.

Et les moyens pour y parvenir :


• Placer le client au centre de l’entreprise et le valoriser

• Bâtir de meilleurs relations d’affaires avec la clientèle : nouvelles opportunités d’affaires


ou de ventes (Ex : Ventes d’autres produits via des opérations publicitaires,
promotionnelles via systèmes et personnel).

• Créer une réelle valeur ajoutée pour le client; en donnant plus de place à la gestion de la
relation client.

• Viser à diminuer le coût d’acquisition d’un nouveau client en le fidélisant et rendant plus
élevé le coût de transfert vers une autre marque ou concurrent.

• Être à l’écoute du client, en identifiant et en tenant compte des ses besoins.

2.4. Les typologies de fonctions concernées:

Sur le plan fonctionnel, le CRM peut être organisé en trois grands domaines :
opérationnel, analytique, et collaboratif.

2.4.1. Opérationnel : le traitement de la commande

Ce domaine implique l'automatisation des processus qui touchent les départements en


contact avec les clients : commercial, marketing, et services clients, via les différents canaux
d'interaction. Cette partie se concentre essentiellement sur la gestion des forces de ventes
(Sales Force Automation ou SFA).

2.4.2. Analytique : basé sur le décisionnel

 
24 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Ce domaine permet d'effectuer des analyses sur l'ensemble des données clients; il est
intimement lié au Data Warehouse et aux applications décisionnelles. Cette partie a pour but
d'étendre la connaissance des clients et de fournir des éléments d'aide à la décision aux
responsables marketing.

Le client constitue une nouvelle source d'information pour l'entreprise. Située au cœur
du système d'information et partagée par l'ensemble des applications de l'entreprise, la base de
connaissance est indispensable au bon fonctionnement de toute relation client. Cette base est
presque toujours spécifique à l'entreprise car elle reflète les particularités de son métier, de sa
stratégie… En ce qui concerne les données externes, elles peuvent être inclues dans la base
client, soit incorporées dans le Data Warehouse.

La base de données est le premier outil de gestion de la relation client, elle est au cœur
du processus de gestion de la relation client pour l'identifier, le connaître et le fidéliser.
L'arrivée de l'Internet augmente ce besoin de capacité de traitement de l'information. Elle
centralise toutes les informations. Elle est l'outil de capitalisation des connaissances de
l'entreprise sur son marché. L'ensemble du système d'information de l'entreprise s'articule
désormais autour d'elle.

2.4.3. Multicanal et collaboratif : interaction avec le client à travers tous les


canaux possibles

Ce domaine met en œuvre les technologies de travail de groupe et consiste à mettre en


place des canaux ou des actions pour dialoguer avec le client : messagerie électronique,
conférences, fax/lettres…Cette partie "multicanal" (Enterprise Marketing Automation ou
EMA) a pour objet essentiel est d'optimiser les contacts clients et de transmettre le bon
message au bon moment par le bon canal.

2.5. Les processus et fonctionnalités concernés

2.5.1. Unité VENTE :

L’unité « vente » permet de gérer tout se qui se rapporte à une vente et, plus
particulièrement dans notre cas, la gestion de relation client. Ceci en vue de permettre aux
entreprises de prévoir, d'analyser et donc ensuite de pouvoir fixer des plans marketing
destinés à leurs clients. Cette unité prend en compte les fonctionnalités suivantes :

 
25 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

ƒ La gestion des contacts (clients et/ou prospects) à travers un système de fiche qui
regroupe toutes les informations d'un client ou prospect (nom, prénom, adresse, âge,
profession, adresse e-mail, etc.). Il doit également être possible de relier les contacts entre
eux (parrainage, plusieurs fiches contacts, même famille, etc.).

ƒ La gestion des doublons c'est à dire la gestion de l'unicité des informations pour une
meilleure qualité de celles-ci.

ƒ La gestion des opportunités qui permet aux équipes de ventes de collaborer et de


conclure les affaires plus rapidement. Par exemple, en offrant la possibilité de mettre à
jour les informations relatives aux contrats, d'assurer le suivi des événements jalons, des
opportunités et d'enregistrer toutes les interactions relatives aux opportunités à partir d'un
point unique.

ƒ La gestion des processus de vente complets à travers des formulaires : devis, commande,
livraison, retour, avoir, facture, etc.

ƒ Un catalogue de produits et les tarifs multiples de façon centralisés afin d'augmenter la


cohérence, d'offrir un accès aisé aux données produites et aux informations de tarification
précises.

ƒ La planification des ventes c'est à dire la programmation des actions et opérations de


vente à mener, les objectifs, les moyens à mettre en œuvre, les durées, etc.

ƒ La gestion des comptes, à savoir la gestion de toutes les données de compte client,
notamment les informations concernant les contacts, les organigrammes des clients, le rôle
joué par chaque contact dans la relation commerciale, les documents utiles, les partenaires
impliqués dans le compte, etc.

ƒ La gestion des contrats, c'est à dire la gestion de l'ensemble du cycle de vie client, de
l'approbation d'un contrat à son renouvellement.

2.5.2. Unité MARKETING:

L’unité « marketing et analyse » permet aux entreprises d'étudier les comportements


des clients, d'envoyer leurs offres publicitaires et promotionnelles, grâce à divers moyens de
communication, de gérer tout ce qui englobe la relation commerciale. L’unité marketing
prend en charge les fonctionnalités suivantes :

 
26 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

ƒ Le Mailing, soit l'envoi en nombre d'un document. Le mailing est dit « personnalisé » si
on utilise des champs pour modifier le message en fonction du destinataire. En général,
utilisé avec une liste d'adresses de diffusion.

ƒ L'e-mailing, qui est l'équivalent électronique du marketing direct, consistant à prospecter


et/ou fidéliser ses clients, via l'émission groupée et automatique de d’e-mails.

ƒ Un requêteur complet, mettre en place un système qui permet à l’utilisateur de réaliser


des requêtes de manière aisée (sans connaître le langage SQL spécifique aux bases de
données), à travers une interface simple et ergonomique.

ƒ La gestion de documentation commerciale/marketing qui permet la création et


enregistrement de documentations commerciales/ marketing types.

ƒ La veille concurrentielle, soit la surveillance des forces et des faiblesses de


l'organisation, de l'entreprise, de la fabrication, des coûts, etc., en comparaison avec la
concurrence.

ƒ La gestion des territoires commerciaux, c'est à dire la gestion de la répartition des


représentants ou commerciaux sur les territoires.

ƒ La gestion WEB, c'est à dire la gestion du contenu, du nombre de visites, du chemin


parcouru par le client sur le site Internet.

ƒ L’édition de rapport d’état, c'est à dire la gestion du contenu d'un rapport avec la
possibilité de modèles. Ces rapports doivent être imprimables.

ƒ La gestion call center, soit la gestion d'appels téléphoniques, récupération d'informations,


etc.

ƒ Des analyses, statistiques et graphiques, histogrammes, camemberts, etc. Ils doivent


être édités avec beaucoup de soin, donnant ainsi de vraies indications aux décideurs.

2.5.3. Unité GESTION & ORGANISATION :

L’unité « gestion et organisation » contient tout ce qui permet à l'entreprise de gérer,


suivre et organiser tous ses documents. Ce module prend en compte les fonctionnalités
suivantes :

 
27 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

ƒ La gestion de documents, privés ; accessibles selon certains droits et publics ; accessibles


par tous.

ƒ Le suivi/historique des tâches, c'est à dire des informations de suivi des opérations
effectuées sur les événements et les applications reliées.

ƒ L'import/export (en une seule fois) de données contenues, ou à ajouter à une base de
données.

ƒ Un tableau de bord, c'est à dire d'un gestionnaire ou d'un décideur présentant des
indicateurs permettant de suivre et d'anticiper le fonctionnement et l'activité de l'entreprise
ou du service.

ƒ Une messagerie électronique, un système classique de messagerie, permettant l'envoi et


la réception de courrier électronique.

ƒ Un agenda permettre aux utilisateurs d'associer des actions à des moments, et d'organiser
ainsi son temps, avec des rappels possibles (alertes), a travers un agenda électronique.

ƒ La gestion de pièces jointes est la possibilité d'associer une pièce jointe de tous types
(image, photo, vidéo, audio) à un compte, un contact, un produit, etc.

2.5.4. Unité SERVICES :

L’unité « service » est composé de tous les services types proposés par les offreurs de
solutions CRM. C'est dans ce type de fonctionnalités que les CRM se diffèrent. Cette unité se
compose des fonctionnalités suivantes:

ƒ La gestion des commissions/primes en fonction de critères d'analyses et de récompenses,


fixés par l'entreprise.

ƒ La gestion multilingue et multidevise, c'est-à-dire que le logiciel est disponible en


plusieurs langues et plusieurs devises.

ƒ Un moteur de recherche permettant de trouver des documents ou informations sur mots


clefs.

 
28 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

ƒ La gestion droits utilisateurs, c'est à dire la définition de profils utilisateurs possibles, en


fonction de leur droit d'accès à l'information, de leur statut hiérarchique et donc niveau de
responsabilité.

ƒ La mobilité, c'est à dire la possibilité d'accès au CRM sur PC portable, Pocket PC ou


autres et par conséquent à distance.

ƒ L'utilisation offline, soit la possibilité de réaliser des opérations lorsque la connexion à


Internet ou le CRM n’est pas active.

ƒ La personnalisation, c'est à dire la possibilité en fonction du domaine de l'entreprise de


personnaliser, de paramétrer le CRM (au niveau champs, formulaires, vues, règles de
gestion, etc.)

2.6. Les Outils CRM:

2.6.1. Automatisation des forces de ventes

Ensemble des outils à disposition des commerciaux leur permettant de structurer et de


partager les données sur les clients. Ces outils peuvent être mis en œuvre sur des téléphones
portables ou des assistants de poche. Ils augmentent la productivité des vendeurs et permettent
aux responsables d’équipes de jauger les résultats, au niveau individuel ou à celui d’un
groupe.
L´automatisation des ventes vient en appui aux forces commerciales. Elle permet le
suivi des actions en cours et des dossiers clients.

La gestion des contacts est l´élément majeur de l´automatisation des ventes. Mais elle
concerne également toutes les activités commerciales : la prospection et les ventes sont
suivies en temps réel (relances, propositions). La visibilité sur chaque dossier client est accrue
grâce à des fiches détaillées (historique notamment). Ainsi, le suivi des prévisions et cycles de
vente sont facilités par la prise en compte de l´intégralité des données.
Principaux éditeurs : Frontrange, Pivotal, SAS, Selligent.

2.6.2. Centres d'appels

Le fonctionnement des centre d’appels est qu’une série de personnes appelées


opérateurs se situe dans un local. Ils disposent d’un casque avec un micro pour répondre au

 
29 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

téléphone et d’un ordinateur pour encoder les données qui leurs sont transmises ou traiter un
dossier. Pour chaque type d’appel, il existe une procédure standard (« script ») mentionnant
les questions à poser et l’information à en retirer. Il n’y a généralement pas de place à
l’improvisation. Mais ce fonctionnement est un peu restrictif aujourd’hui avec l’arrivée des
nouvelles technologies de communication telles Internet. En 1997, 97% des interactions se
faisaient par téléphone, aujourd’hui elles sont passées à 60%, le reste se faisant
essentiellement par e-mail et par le Web.

2.6.3. Automatisation du marketing

Aide les responsables marketing à mieux connaître les différents segments de clientèle,
à mieux préparer les campagnes et à mesurer les résultats. Configurateur Outil permettant au
client de concevoir son propre produit en fonction de ses besoins. Le client explicite ses
besoins fonctionnels et le configurateur les transcrit en termes techniques pour définir le
produit final. Une fois conçu, le produit pourra être lancé en fabrication.

L´EMA (Enterprise Marketing Automation) ou Automatisation des campagnes


marketing permet d´optimiser les actions marketing quel que soit le canal utilisé. Elle offre
une vision globale de chaque campagne et un ajustement précis. L´automatisation porte sur
les phases majeures de la campagne : elle permet dans un premier temps le ciblage des
prospects en fonction des critères d´approche.

Le plan de campagne ainsi que la répartition des tâches en interne sont pris en charge
grâce à des fonctionnalités de gestion et de planning. Les formats de contenus sont adaptés en
fonction du canal préféré de chaque prospect. Enfin, l´EMA consiste à traiter et à analyser les
retours pour chaque campagne. (Principaux éditeurs : Marketic, Annuncio).

2.6.4. Personnalisation et commerce électronique

Le site de commerce électronique autorise l’ensemble des opérations commerciales, y


compris le paiement, via Internet. Une grande interactivité peut-être introduite dans la relation
avec chaque client, pour évoluer vers ce que l'on appelle le "marketing one to one".

Les outils de personnalisation permettent de définir les profils des cyberclients pour leur
faire des offres commerciales correspondant à leurs attentes. De manière dynamique, il est

 
30 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

également possible de faire apparaître les offres commerciales ou les bandeaux publicitaires
en fonction de leur cheminement sur le site.

2.6.5. Service au travers du Web

Le service client passe traditionnellement par un contact direct, via le téléphone, avec un
centre de support. Toutefois, une partie des demandes peut être satisfaite sur un site Web qui
intègre des outils basés sur des technologies avancées (intelligence artificielle, réseaux de
neurones, base de connaissance…).

2.6.6. La gestion des services

La gestion des services en après vente est extrêmement importante dans une logique de
fidélisation des clients. Elle consiste principalement à réagir de manière adéquate à toute
demande émanant d´un client. Que la requête soit formulée via un appel téléphonique, un
message laissé sur le net ou un courrier postal, il faut dans un premier temps qualifier le client
demandeur. La deuxième étape, cruciale, est la qualification de la demande elle-même
(demande d´information, réclamation, demande d´assistance...) et sa gestion immédiate. Après
recherche si nécessaire, la personne en charge du support doit procéder à l´envoi de la réponse
appropriée dans un délai acceptable. Dans le cas d´une intervention, le rendez-vous et les
modalités doivent être fixés en tenant compte des plannings de chacun. Enfin, une enquête de
satisfaction permet de gérer au mieux le suivi qualitatif de la prestation de service.

Les outils de gestion des services permettent de conserver l´historique de chaque client
et d´établir des bases de connaissances à partir des solutions apportées. Les principaux
éditeurs : Remedy, BusinessLine , Chordiant.

2.6.7. Les offres globales : suite intégrées

Les suites logicielles CRM sont à la fois destinées aux équipes du support client, du
marketing et aux forces commerciales et permettent ainsi une vue unifiée de la relation client.
Ces solutions s´adressent plus particulièrement aux grandes entreprises et s´intègrent aux
circuits internes.

Principaux éditeurs : Coheris, Siebel, Peoplesoft, MicroStrategy, Remedy, Chordiant,


Selligent, Amdocs Clarify, GEAC.

 
31 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

2.7. Les principaux objectifs :

Parmi les objectifs du CRM on trouve :

• Satisfaction des clients.

• L’accroissement du chiffre d’affaire provenant de la satisfaction des clients qui constitue


un facteur clef de rentabilité car la personnalisation de la relation client avec les outils
CRM permet de passer d’une relation de marketing de masse à une relation one to one.

• Il y a aussi la réduction des coûts de vente et de distribution et la réduction des coûts liés
au support destiné à la clientèle :
1) Pour réduire les coûts de vente et de distribution, il faut bien cibler les publicités sur
les clients potentiels, utiliser des sites Internet de vente pour réduire le nombre de
vendeurs en vente direct, et améliorer la gestion de la relation client plutôt que la
gestion des produits.
2) Pour minimiser les coûts du support client, il faut mettre à disposition toutes les
informations disponibles aux opérateurs pour qu’ils puissent répondre efficacement
et rapidement, et automatiser le système d’information des centre d’appels pour les
opérateurs aient un accès direct aux fiches clientes, à leurs historique et surtout leurs
préférences.

• Meilleure maîtrise et gestion du portefeuille client.

• Identifier les populations intéressées et leurs proposer des services différenciés.

• Diriger le client vers le meilleur interlocuteur.

 
32 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

• Bâtir un CRM à caractère décisionnel.

• Amener aux clients la bonne information au bon moment.

En effet, un des principaux objectifs d’un CRM est d’augmenter la performance à tous
les niveaux de l’entreprise et dans toutes ces fonctions.

L’utilisation d’un tel outil contribue à la maximisation des performances notamment


dans le domaine du marketing, des ventes et du service client ainsi qu’à la rationalisation et
l’amélioration de la gestion des processus métiers.

2.8. Les avantages du CRM:

L’exploitation rapide optimale de l’information sur le client devient aujourd’hui un


nouvel avantage concurrentiel déterminant dans toute stratégie d’entreprise.

Pour cette raison le recours au CRM permet de :

• Augmenter la satisfaction client

• Réduction des coûts d’acquisition de nouveaux clients et de nouvelles ventes.

• Fidélisation accrue de la clientèle et meilleure conservation des clients

• Reconquérir les clients inactifs

• Optimisation du retour sur les relations existantes d’où une augmentation du chiffre

d’affaire par client

• Une réduction des problèmes clients

• Des décisions marketing plus avisées

• Redistribuer les moyens vers les clients les plus rentables.

• Acquérir de nouveaux clients

• Accroître la connaissance des besoins et préférences des clients

• Automatiser les compagnes marketing, marketing ciblé

• Réactualiser les actions marketing en temps réel

• Amélioration des processus opérationnels

 
33 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

• Avantage concurrentiel

• Un meilleur taux de réussite des ventes croisées et additionnelles

• Des cycles de vente raccourcis

• Pour comprendre la raison pour laquelle les clients désertent.

A cela s’ajoute d’autres objectifs. En effet, le CRM donnera à l’entreprise la possibilité de :

™ Disposer d’un canal de distribuer supplémentaire, permettant de,

™ Décharger l’équipe commerciale des opérations à faible valeur ajoutée afin de,

™ Soutenir le réseau dans ses actions commerciales en leurs donnant des outils d’aide à la

vente (prise de rendez vous…) pour,

™ Améliorer la production et la productivité de la force de vente, et

™ Contribuer à l’amélioration de la qualité du service offert aux clients, et

™ Véhiculer une image d’une entreprise à l’écoute de ses clients et de son marché.

2.9. Les inconvénients de la mise en place de CRM:

Le terme de Customer Relationship Management est utilisé pour définir deux concepts
très distincts : d’une part, le développement de la relation et, d’autre part, l’optimisation du
contact. En tant qu’instrument de développement de la relation, le CRM a pour but de mettre
en place et d’intensifier la loyauté de la clientèle en favorisant sa confiance et son attachement
émotionnel envers l’entreprise, et ce par le biais de prestations orientées sur le client durant
toutes les phases de la relation commerciale.

Pour ce qui est de l’optimisation du contact, il s’agit de viser en priorité une réduction
des coûts et une augmentation de l’efficacité en marketing, grâce à un appel direct et
individuel du client. Bien entendu, ces deux conceptions se complètent lorsque l’optimisation
du contact s’accorde parfaitement avec les objectifs d’un concept stratégique de
développement de la relation.

 
34 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Dans le cas contraire, les activités de CRM risquent de se répercuter négativement sur
la confiance et l’attachement de la clientèle, provoquant ainsi un affaiblissement de la relation
client.

2.10.Les contraintes du CRM:

• Implication et formation des utilisateurs

• Grande capacité de changement de l’orientation

• Ressources financières

• Délais d’implémentation d’un projet CRM

3. Conclusion
Déjà depuis quelques années, les capacités de l’informatique, tant au niveau de la
production que de la vente, ont permis de segmenter les marchés en sous-groupes et de donner
aux clients de plus larges possibilités de choix. L’arrivée du CRM permet d’aller encore plus
loin et d’inverser une nouvelle fois la proposition, à savoir fabriquer le produit ou le service
que demande le client mais à des coûts et dans des délais comparables à ceux de la production
de masse.

Ainsi, l’arrivée de cet outil va permettre une mutation du marketing au sein de


Logistique et Communication : passer de l’ère du marketing de masse à l’ère du marketing
relationnel (une offre individualisée pour chacun). L’entreprise en franchissant le cap du
CRM est passées d’une orientation produit à une orientation client. Le client est devenu une
des priorités stratégiques de l'entreprise. Mais si le logiciel n’est pas encore totalement
déployer, il pourra être mis en service d’ici peu et on pourra alors apprécier sa valeur ajoutée.

Grâce aux NTIC (Nouvelles Technologies de l'Information et de la Communication)  et


notamment aux bases de données l’entreprise va pouvoir affiner la connaissance de sa
clientèle car les responsables se sont bien rendus compte qu'il est moins coûteux et plus
rentable de fidéliser un client existant que d'en recruter un nouveau. Ainsi l’entreprise s’est
maintenant engagée dans cette stratégie de "sur-mesure" en adoptant à terme le plus possible
ses produits aux besoins de ses clients et futurs clients.

 
35 
 
PARTIE I                                                                                                                          Synthèse sur le CRM 

Dans ce contexte et sachant que la société Logistique et Communication bénéficie d’une


forte expérience dans le domaine de conception et de développement d’outil web, dès lors
l'e-CRM semble être la prochaine étape vers la fidélisation.

La méthode de suivi d’un projet CRM relève du bon sens. Elle est un peu différente des
projets classiques de mise en œuvre d’outils de gestion dont la finalité est connue (paye,
comptabilité, production…), il faut favoriser la réflexion, l’organisation et une approche
pragmatique gérée étape après étape, seuls ces règles d’or permettront un déploiement réussi.

 
36 
 
 

 
PARTIE II :
 
CAS WTA NEDJMA

 
 

 
PARTIE II :
 

 
CHAPITRE 1 :
 

PRESENTATION DE L’ENTREPRISE
 
NEDJMA

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

1. Présentation de l’entreprise d’accueil


1.1. Présentation générale de Nedjma
Nedjma (qui signifie étoile en arabe) est le 3e opérateur de téléphonie mobile en
Algérie. C'est la marque commerciale mobile de Wataniya Telecom Algérie, elle-même étant
la filiale de l'entreprise Wataniya Telecom Koweït. L'opérateur compte aujourd'hui plus de 5
millions d'abonnés.
Wataniya Telecom Algérie (WTA), le premier opérateur multimédia de téléphonie
mobile en Algérie, a obtenu une licence de desserte nationale des services de téléphonie sans
fil en Algérie le 2 décembre 2003, grâce à une soumission gagnante de 421 millions de dollars
US. Le 25 août 2004, Wataniya a procédé au lancement commercial de sa marque Nedjma,
assorti de services et d’avantages encore jamais égalés dans le pays. Nedjma introduit de
nouveaux standards dans l’industrie des télécommunications en Algérie.

1.2. Présentation générale de QTEL


Qtel est parmi les plus grandes entreprises qataries, elle compte plus de 1900 employés.
Elle est cotée à la Bourse de Doha depuis 1998. Elle est également cotée à la Bourse de
Londres depuis 1999, à la Bourse de Bahreïn et à la Bourse d'Abou Dhabi depuis 2002. Elle
offre des services GSM, de téléphonie fixe, d'Internet et de télévision câblée.
« Qtel » opère sur trois marchés : celui de l’Indonésie, d’Irak ainsi que de l’Algérie.
L’année 2008 se dirige vers un résultat du groupe « Qtel » de près de 5 milliards de dollars de
CA pour un bénéfice estimé à 500 millions de dollars pour fin septembre dernier. Des
résultats qui conforteront encore plus la présence de Wataniya Telecom Algérie.
L’opérateur qatari Qatar Telecom (QTEL) a racheté les parts majoritaires de la société
Kipco dans le capital de l’opérateur koweïtien Wataniya, Le montant de la transaction
pourrait être de l’ordre de 3,7 milliards de dollars. C’est comme ça que Q-TEL s’est offert le
marché algérien.

1.3. Logo Nedjma

Figure 3: logo Nedjma

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

1.4. Organigramme

Figure 4: Organigramme de Nedjma

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

1.5. Chiffre clés de Nedjma

¾ Investissements :

• Montant de la l’achat de la licence : 421 millions de dollars

• Investissements : 1,5 milliards de dollars

¾ Performances sur le marché algérien :

• Plus de 5 millions d’abonnés à ce jour.

• Un réseau équipé à 100% de la technologie GPRS/EDGE.

• Taux de croissance de 35% du chiffre d’affaires au 3ème trimestre 2008 par rapport à la
même période en 2007.

• Equilibre financier atteint en juin 2008.

• Meilleur opérateur mobile 2007 en Afrique du Nord.

¾ Réseau technique :

• Couverture des 48 wilayas en une année d’opération.

• 99,1% de qualité de réseau (Etude ARPT)

• Près de 90% de la population couverte.

• 2 739 sites (BTS) installés à ce jour.

¾ Réseau de vente :

• 37 Espaces Nedjma à travers le territoire national.

• 200 Espaces Services Nedjma.

• 6 distributeurs officiels nationaux et régionaux.

• 23 000 points de vente agréés.

¾ Ressources humaines :

• Près de 1600 employés dont 99% d’algériens.

• 50% de femmes.

• Moyenne d’âge des employés : 30 ans

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

• Nombre d’heures de formation des employés en 2008 : 50 000 heures.

1.6. Actionnaires

WTA a été mise en place par la société koweïtienne Wataniya Telecom, à laquelle s’est
jointe United Gulf Bank (UGB). Dotée d’une licence d’une durée de 15 ans, WTA a adopté
un programme d’investissements accéléré comportant des projets de 1 milliard de dollars US
sur trois ans. Grâce à ces investissements, Nedjma se taille la place de leader de l’innovation
et de la plus-value : elle rend la technologie multimédia accessible à tous et facile à utiliser.

Wataniya Telecom, l’opérateur de référence de WTA, a été fondée en 1999 au Koweït.


Il fait partie des sociétés de Koweït Projects Company (KIPCO), la plus importante entreprise
privée du Koweït avec un actif de plus de 10 milliards USD. Wataniya Telecom a connu une
croissance fulgurante dans l’univers des télécommunications sans fil au Moyen-Orient et en
Afrique du Nord. En mars 2007, Qtel devient actionnaire majoritaire (51%) de Wataniya
Telecom Kuweit et détient par conséquent 80% de Nedjma.

1.7. Parts de marché de WTA


Comme représenté dans la figure 5, WTA détient 19,30% de parts de marché de
téléphonie mobile en Algérie en 2009, face à ses deux concurrents :
- Orascom Telecom Algérie (OTA): “Djezzy” qui a obtenu sa licence en juillet 2001,

tandis que son lancement commercial s’est fait le 07 Novembre 2001 est leader incontesté
du marché de la téléphonie mobile en Algérie avec 52,90%.
- Mobilis : Opérateur Algérien “Mobilis” qui a obtenu sa licence en 1998, tandis que son
lancement commercial s’est fait en 1999. Mobilis détient 28,50% de parts de marché

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

Figure 515 : Parts de marché des trois opérateurs WTA, OTA et Mobilis.

1.8. Les missions de Nedjma


Les activités majeures de Nedjma sont :

ƒ Fournir des services de télécommunications permettant le transport et l’échange de la


voix, de messages écrits, de données numériques et d’information audiovisuelles.

ƒ Développer, exploiter et gérer les réseaux publiques et privés de télécommunications.

ƒ Etablir, exploiter et gérer les interconnexions avec les opérateurs des réseaux.

1.9. Les objectifs de Nedjma

Wataniya Telecom Algérie (Nedjma) est engagée dans le monde des technologies de
l’information et de la communication avec les objectifs suivants :

ƒ Reprendre rapidement ses parts du marché.

ƒ S’inscrire à l’avant-garde de l’innovation.

ƒ Développer l’expertise et la performance.

ƒ Etre constamment compétitif (qualité, prix et services), WTA Nedjma veut accroitre la
qualité de services offerts et la gamme de prestations rendues et rendre plus compétitifs
les services de télécommunications.

ƒ Générer des profits et de la croissance.

ƒ Participer au développement national.

2. Etude de l’environnement de l’entreprise


Notre objectif est d’étudier l’environnement de l’entreprise, puis nous allons donner une
image sur sa structure pour introduire et faciliter notre travail.

2.1. La clientèle
Les clients de WTA Nedjma sont classés par catégorie de produit, dont on trouve : les
clients prépayés (prepaid), les clients post payés (postpaid) et les clients hybrides.

                                                             
15
 Chiffres tirés du site www.jeuneafrique.com du 21/07/2009.

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

• Prépayés :

Le client qui veut bénéficier d’une ligne Nedjma selon la gamme prépayé, n’a ni facture
ni abonnement ni engagement, maid doit présenter certains documents pour l’affectation du
contrat. Ce client sera facturé à temps réel. A l’épuisement du crédit, le client doit recharger
son compte,lesz offres existantes sont : la Nedjma star, la Nedjma plus, la Nedjma 55, la
Nedjma Bonus et la Nedjma FREE.

• Postpayés :
Le client qui veut bénéficier d’une ligne Nedjma selon la gamme postpayé, doit
présenter certains documents nécessaires pour l’affectation du contrat. Ce client recevra
mensuellement une facture de ses consommations, ce qui lui offre une liberté de
consommation (pas de limitation de crédit) on trouve ici Nedjma abonnement
• Hybrides :
Le client qui veut bénéficier d’une ligne Nedjma selon la gamme hybride, doit présenter
certains documents nécessaires pour l’affectation du contrat. Ce client combine les avantages
du Postpayé et la maîtrise du budget qu’offre le Prépayé, offrant un abonnement fixe et
rechargeable, sans aucune contrainte, pour cette catégorie on trouve : L’abonnement
résidentiel et La Nedjma illimite

2.2. Produits et services

Nedjma offre à ses clients une large gamme de services, on cite :


• La messagerie vocale

• Le renvoi d’appels

• Le double appel

• Le SMS (Messages texte écrits)

• MMS (Multimedia messaging service)

• WAP (en anglais : Wireless Application Protocol)

• Push to talk (push to talk)

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

• Présentation du numéro

• Le mobile anonyme (le CLIR)

• Appel à l’international

• Le Roaming

• Le Fax et le Data

• L’appel en conférence

• Websms

• La facture détaillée

• Service AWEDLI

• Service STORMILI

• Service DIMA

• Nedjma Chat.

3. Conclusion
Nous avons pu donner, lors de ce chapitre, une présentation générale de l’organisme
d’accueil « WTA Nedjma ». Nous avons présenté l’environnement dans lequel évolue
Nedjma, nous avons aussi identifié les différentes structures organisationnelles de l’entreprise.

Au cours du chapitre suivant nous allons faire une étude détaillée sur l’existant
décisionnel de l’entreprise WTA Nedjma.

 
45 
 
 

 
PARTIE II :
 

 
CHAPITRE 2 :
 

ANALYSE DE L’EXISTANT
 
DÉCISIONNEL

 
Partie II Chapitre 2: Analyse de l’existant décisionnel

1. Le système actuel :

1.1. Description de l’outil CRM Nedjma :

Dans le cadre de conquête et de reconquête des clients, Nedjma s’est projetée sur
l’adoption de la nouvelle fonction marketing créée dans l’entreprise qui est le Customer
Relationship Management (Gestion de Relation Client) , Pour que l’intégration d’un outil
comme le CRM soit couronnée de succès, tous les employés de la société doivent acquérir
la philosophie du client, en effet, chaque employé doit être « orienté client » et doit être
convaincu que le client est la principale source de rentabilité de l’entreprise. Cependant
certains services (de par leurs natures) sont plus conscients de l’importance du client et de
la relation qui doit le lier à la firme, ce sont les divisions commerciales et marketings. Les
Systèmes de Gestion de la Relation Client sont conçus pour améliorer et optimiser le travail
de ces divisions.

Un projet de telle grandeur ne peut que se réaliser en plusieurs étapes car il sera conçu
pour plusieurs services de la compagnie comme le Customer care, le marketing les ventes…
etc.

Ce projet qui est en cours de réalisation est géré par une équipe d’experts qui est
l’équipe CRM en interaction avec les autres équipes IT/SI et qui s’est mis d’accord pour
que l’intégration de l’outil soit projetée en plusieurs phases:

ƒ Phase 1: le customer care (service clients):

Le service à la clientèle se retrouve au centre de la stratégie CRM de l’entreprise.


C’est un des piliers de différenciation de l’entreprise vis-à-vis de ses concurrents, Le CRM
a pour objectif de :

• Minimiser le temps de prise d’appels (affichage automatique de la fiche client, vue 360

du client, …)

• Avoir une Interface Unique

• Avoir une Base de données unifiée

• Permettre une meilleure gestion des réclamations (Workflow supervisé)

• Garder l’historique de toutes les interactions clients (service personnalisé)

 
47 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

• Créer une base de connaissance intelligente reliée à un échange d’information

• Développer une relation à long terme avec les clients

• Réduire et améliorer le process d’activation

• Gestion des campagnes à l’aide de scripts d’appels

ƒ Phase 2: le marketing

Pour le département marketing, le CRM a pour objectifs d’Identifier et cibler les


meilleurs prospects et clients; de segmenter le portefeuille client et mettre en évidence leurs
comportements d’achat ; de concevoir et mettre en place les stratégies marketing en matière
de prix, de produits et de promotions, tout ça en assurant de :

• Avoir des critères supplémentaires pour segmenter la base

• Avoir une meilleure compréhension du comportement clients

• Permettre un meilleur ciblage de la base clients pour des campagnes de fidélisation

• Créer des offres ciblées pour retenir les clients « High end » et minimiser le churn

• Améliorer approche Fidélisation

• Avoir un marketing décisionnel: Analyse multidimensionnelle, Scoring, tableau de

bord,…

ƒ Phase 3: les ventes

Pour le département marketing, le CRM a pour objectifs de : 

• Avoir une Interface clients dans les boutiques

• Développer le process de ventes (lignes, cartes de recharges, Handset, solutions,…)

• Faire le Suivi du dossier clients

• Assurer la gestion des contrats

• Faire le Suivi du cycle de vente

• Garantir un suivi des prévisions de ventes

• Suivre la prise de rendez vous (élaboré par les campagnes appels sortant)

 
48 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

• Reporting (Analyse de performance,…)

Ainsi chaque phase a le cycle de vie suivant

Figure 6: Cycle de vie d’une phase du projet.

• Spécification : Définition de tous les éléments structurants d’une phase (objectifs,


budget, liste, équipes…etc.)

• Développement : Développer dans le système les éléments nécessaires pour exécuter


l’étape (Scripts, Acteurs, Audience, Déclencheurs, Offre …)

• Intégration : Implémenter dans le système les éléments développés.

• Validation : Cette étape consiste à exécuter et tester la phase sur une audience limitée
afin de mesurer la réponse de l’audience à cette étape, ainsi que mesurer les
performances de la phase grâce aux différents rapports.

• Déploiement : Après tout les testes et les rectifications on passe au déploiement final.

1.2. Le service concerné par l’étude


Dans cette partie, nous allons identifier les acteurs métiers du service concerné par
l’étude, ses rôles, ses principales tâches, etc. Puis nous décrirons ses processus critiques.

Commençons d’abord par décrire la direction de l’IT/IS, cette dernière couvre le


secteur de l’informatique. Les employés de l’IT/IS sont des experts dans ce domaine. Tout
ce qui concerne de près ou de loin les clients passe par eux.

Cette direction est constituée du :

- Département Projets PMO

- Département VAS
- Département CRM
- Département Product, Billing et médiation
- Département infrastructure IT
- Service intégration systèmes et projets

 
49 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

Dans le cadre de la mise en place du système de Gestion des Relations Clients, et


partant de la première phase du projet qui concerne le service clients, l’équipe CRM a
besoin d'avoir une vue de synthèse sur la migration de données du système existant
(Système de facturation) sur lequel les données sont présentes vers le nouveau système
(Système CRM).

Pour implémenter son CRM, Nedjma s’est doté de l’outil mondial « SIEBEL»
d’ORACLE.

Ainsi, le service concerné par notre étude est le service CRM, nous allons identifier
les postes de travail ainsi que les activités et les taches des personnes qui occupent ces
postes, ces acteurs sont nos plus proches collaborateurs. Ils représentent les utilisateurs
futurs de notre système, c’est d’eux que dépend le succès de notre projet. Il est donc
primordial de s’intéresser à leur travail et à leurs besoins.

Post 1 : Chef de projet.


Effectif : 1 personne.
Moyens de communication de l’information : téléphone, fax, courrier électronique.
Moyens de traitement de l’information : 1 Micro-ordinateur, 1 Imprimante.
Mission : Gérer et veiller au bon fonctionnement de l’équipe CRM.
Principales Tâches :
• Gestion et management du projet « ORBIT».

• Fournir l’encadrement et l’assistance nécessaire à l’équipe CRM dans la résolution des


cas complexes
• Analyser les résultats mensuels et tendances de son équipe.
• Communiquer les besoins de formation et informe le chef de département IT/SI des
situations difficiles (problème sur le projet, un besoin de formation, un élément
réfractaires.)
• Saisir et analyser les résultats afin d’identifier les forces et les opportunités
d’amélioration.
• Animer des réunions mensuelles d’équipe ou rencontre individuelles.
• Maintenir à jour des fichiers de contrôle ou autres sources de références, et de registre
administratif (gestion du temps, compte rendus de réunion, état d’avancement du
projet…)
• Assurer le respecter du cahier de charges établi

 
50 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

Post 2 : Intégration, Architecture et webservice (SOA Plateforme).


Effectif : 1 personne.
Moyens de communication de l’information : téléphone, fax, courrier électronique.
Moyens de traitement de l’information : 2 Micro-ordinateur, 1 Imprimante.
Mission: Integration Siebel, WebServices et Architecture Siebel.
Principales Tâches :

• Chapoter le projet d’implémentation des webservices.


• Intégration de Siebel avec les différents systèmes d’information de WTA à l’aide des
WebServices (Siebel Tools)
• Architecture Siebel : Suivi de l’implémentation des différents environnements Siebel
(Développement, Acceptance, Formation, Test, Production) supportant la haute
disponibilité (Clustering/Load Balancing).

Post 3 : Chargement des données (EIM).


Effectif : 1 personne.
Moyens de communication de l’information : téléphone, fax, courrier électronique.
Moyens de traitement de l’information : 2 Micro-ordinateur, 1 Imprimante.
Mission : Charger et gérer les données sur l’EIM de SEIBEL.
Principales Tâches :

• Schématisation des données du système tiers selon le modèle Siebel.


• Développement de l’EIM
• Récupération, vérification des fichiers de données pour le chargement.
• Chargement des données.
• Vérification des données chargées dans Siebel.

Post 4: IDL\DBL.
Effectif: 1 personne.
Moyens de communication de l’information : téléphone, fax, courrier électronique.
Moyens de traitement de l’information : 2 Micro-ordinateur, 1 Imprimante.
Mission : Etablir les tables IDL (Initial Data Load) et DBL (Data Batch Load)
Principales Tâches :
• Préparer les scripts d’IDL\DBL.
• Vérification du déroulement des scriptes.
• Traitement et nettoyage des données IDL/DBL.

Post 5 : Administration fonctionnelle.


Effectif : 1 Personne.
Moyens de communication de l’information : téléphone, fax, courrier électronique.

 
51 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

Moyens de traitement de l’information : 1 Micro-ordinateur, 1 Imprimante.


Mission : Etablir l’administration fonctionnelle
Principales Tâches :
• Etablir et faire le suivie de l’administration fonctionnelle du projet.

Post 6 : Administration technique.


Effectif : 1 personne.
Moyens de communication de l’information : téléphone, fax, courrier électronique.
Moyens de traitement de l’information : 1 Micro-ordinateur, 1 Imprimante.
Mission : Gérer l’administration technique
Principales Tâches :

• Génération des extractions de la base de données pour les développeurs


• Paramétrer le CTI (Intégration avec la téléphonie).
• Configuration des WebServices entrants et sortants.
• Administration et configuration des composants Siebel.

Post 7 : Configuration (développement).


Effectif : 2 personnes.
Moyens de communication de l’information : téléphone, fax, courrier électronique.
Moyens de traitement de l’information : 1 Micro-ordinateur, 1 Imprimante.
Mission : Gérer le volet configuration.
Principales Tâches :

• Etablir la configuration requise pour le projet.


• Faire la vérification et le suivi des multiples configurations.

1.3. Critique concernant les postes de travails :


Les postes de travails du service CRM semblent souffrir de quelques lacunes. Après
avoir passé du temps à les étudier, on remarque :

¾ Un manque d’effectif évident qui ralenti l’évolution du projet.

¾ Une surcharge de travail pour les membres de ce département, notamment pour les

postes les plus sollicités, tels que pour l’extraction des données IDL/DBL et
l’Intégration les webservices

¾ Un manque d’organisation très pénalisant avec les autres départements qui


interagissent avec le projet.

¾ Décalage entre les descriptifs des postes et les tâches réellement effectuées.

 
52 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

1.4. Positionnement du système CRM dans le schéma d’architecture de WTA:


Dans cette partie nous allons aborder un l’intégration fonctionnelle entre Siebel et les
applications de WTA. L’objectif étant de connaître pour chaque application :

- Les données à intégrer.


- Les fonctionnalités à intégrer.
- La stratégie d’intégration (Faible, Moyenne, Forte).

Nous avons trois types de stratégies d’intégrations :


ƒ FORTE : On entend par intégration forte, une reprise totale de l’application dans
Siebel.
ƒ MOYENNE : On entend par intégration moyenne, une migration des données et
fonctionnalités de l’application concernée dans Siebel
ƒ FAIBLE : On entend par intégration faible, un appel contextuel (positionnement sur la
bonne page / bon client dans l’application appelée) de l’application concerné depuis
Siebel.

Ainsi Le système SEIBEL va fonctionner en interaction avec les autres systèmes de


WTA à savoir le Billing « BSCS », l’IN « expert », le système « DMC », le « VMS », le
« VAD » et le système « E-voucher ». La figure ci-dessous représente ces interactions.

Figure 7: Positionnement du système actuel dans le schéma d’architecture de WTA


Nous détaillons la description des interactions du système actuel avec les différents
systèmes de WTA en annexe.

 
53 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

1.5. Description globale du système actuel :


Notre étude s’étalera sur la 1ère phase du projet CRM, c’est à dire sur la partie qui
concerne le Customer Care (service clients), pour cette phase du projet, BSCS (Billing) est
maître et Siebel (CRM) est esclave. Durant cette période il y aura besoin de synchroniser les
deux systèmes. Pour se faire, il faudrait d’abord migrer les données déjà existantes via un
premier processus batch (extraction initiale de données) et pour toute modification qui se
fera dans BSCS elle sera répercutée dans Siebel via un deuxième processus batch appelé
DELTA (synchronisation journalière des données).

Avant de commencer la description des étapes, nous allons définir une multitude de
notions que nous avons jugées indispensable d’aborder.

BSCS : Progiciel avec une innovatrice architecture modulaire, il convient aux besoins
nouveaux des entreprises pour les opérations cruciales des prépayés et post-payés comme
les migrations des plans tarifaires et la facturation de ces derniers. Il est assez fort comme
progiciel car ses modules englobent tous ce qui concerne les clients, contrats, offres,
facture, services …etc.

IDL (Initial Data Load) : Processus de chargement initial de données.

DBL (Daily Batch Load): appelé aussi DELTA est un processus de synchronisation
de données entre deux systèmes.

FICHIER PLAT : ou Flat file terme utilisé pour caractériser des données stockées
séquentiellement, généralement en format texte, par opposition aux bases de données qui
stockent les données d'une manière plus organisée.

SQL LOADER : ou « sqlldr » est un exécutable binaire qui permet le chargement de


données à partir de fichiers plats et à destination d'Oracle.

Siebel EIM (Entreprise Integration Manager) : est un composant de serveur dans le


volet Siebel EAI groupe qui assure les transferts de données entre la base de données de
Siebel et les autres sources de données. Cet échange d'informations se fait par
l'intermédiaire de tables appelé EIM tables. Les EIM tables agissent comme une zone
d’intermédiaire entre l'application de base de données de Siebel et d'autres sources de
données.

 
54 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

SIEBEL d’Oracle : c’est un progiciel porté sous l’environnement qui intègre des
solutions sectorielles pour le self-service, il offre aux entreprises la puissance et la souplesse
nécessaires pour fournir les bonnes informations à la bonne personne au bon moment. Avec
des solutions spécialement adaptées à plus de 20 secteurs d’activité et des options de
déploiement « à la demande », entièrement hébergées, ou installées « sur site », C’est
pourquoi les analystes le considère comme la solution numéro un du marché car le CRM
peut améliorer les activités de l’organisme pour stimuler la croissance future.

1.5.1. Extraction et chargement initiale des données.


Cette 1ère partie consiste à extraire les données du système Billing BSCS et les
charger dans le système CRM Siebel.

Figure 8: les étapes de l’extraction et chargement initiale des données.

Cette opération se fait qu’une seule fois et se résume ainsi :

1. Développement du l’IDL batch : Développer les scripts d’extractions.

2. Lancement de l’IDL batch : Exécuter ces scripts pour extraire les données du BSCS
et les ranger dans les tables IDL.

3. Cleansing et checking : Faire les vérifications et les traitements nécessaires sur les
données.

4. Génération des fichiers plats : Générer les données sur des fichiers plats depuis les
tables IDL afin de pouvoir les insérer sur les tables Siebel

5. Chargement dans les tables Siebel : Charger les données via SQL loader dans les
tables Siebel (ce processus sera détaillé dans la partie qui va suivre)

 
55 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

1.5.2. Synchronisation des données entre BSCS et SIEBEL.

Cette étape représente un moyen de synchronisation entre les applications sources, en


l’occurrence BSCS et le CRM.

Une modification sur BSCS d’une entité particulière est un élément déclencheur d’un
traitement DBL, bien entendu il faut que l’élément modifié sur l’application source ait un
rapport avec Siebel.

Figure 9 : les étapes de synchronisation des données entre BSCS et SIEBEL.

Cette étape est amenée à être journalière et se résume ainsi :

1. Lancement de l’DBL batch : Exécuter les scripts pour extraire les données du BSCS
et les ranger dans les tables DBL.

2. Génération des fichiers plats : Générer les données sur des fichiers plats depuis les
tables DBL afin de pouvoir les insérer sur les tables Siebel.

3. Chargement dans les tables Siebel : Charger les données via SQL loader dans les
tables Siebel (ce processus sera détaillé dans la partie qui va suivre)

Le DBL est ramené à disparaître progressivement et dépendamment de l’intégration


de BSCS avec Siebel (Gestion de commande sur Siebel).

1.5.3. Enchaînement des processus IDL\DBL :

T0 T1 T2-2 T2 T2+2 T2+3 temps


IDL 2

Figure 10: Enchainement des processus IDL\DBL dans le temps

 
56 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

T0 : Date de lancement de Nedjma.


T2 : Date du lancement du CRM.

Cette partie présente le processus d’exécution de l’IDL et DBL

ƒ T1 : Lancement de l’IDL batch, ceci est pour extraire toutes les données de BSCS
depuis le lancement de Nedjma (T0)

ƒ Entre T1 et T2-2 : Chargement des données de l’IDL sur Siebel et lancement d’un
DELTA1 qui va regrouper les données entre T1 et T2-2.

ƒ Entre T2-2 et T2 : Chargement sur Siebel du DELTA 1 et lancement officiel du CRM.

ƒ Entre T2-2 et T2+2 : Lancement d’un DELTA2 qui va rassembler les données entre T2-2
et T2+2.

ƒ Entre T2+2 et T2+3 : Chargement du DELTA 2 ainsi la synchronisation entre BSCS et


SIEBEL est complétée.

ƒ Chaque jour qui va suivre : il y’aurai une exécution du script DBL (Daily Batch Load)
pour les modifications journalières.

1.6. Chargement des données :


Les données extraites de BSCS vont être chargées dans le CRM Siebel qui propose
comme solution Entreprise Integration Manager «EIM» ce dernier est composé de :

• Base tables : se sont les tables de bases Siebel ou sont stocké les données

• Interface tables (Tables EIM): Siebel EIM TABLES sont des tables intermédiaires qui

agissent comme une zone entre la base de données Siebel et les bases de données
externes, EIM Tables sont conçues pour être simple et facile afin de pouvoir charger et
lire les données depuis un programme extérieur.

• EIM Server Component : c’est un serveur propre à l’EIM qui fait la transaction des

données des tables interface vers les tables de bases de Siebel.

• EIM Configuration File : c’est la configuration propre à l’EIM qui détermine quelle

est l’opération à faire. exemple : importer, migrer, supprimer, ou exporter... et sur


quelles tables il faut charger les données.

 
57 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

Figure 11 : Structure du l’EIM

1.7. Description des étapes du chargement des données sur SIEBEL :


Dans cette partie nous allons décrire le processus d’importation des données débutant
des fichiers plats jusqu'aux tables de bases SIEBEL.

Figure 12: Description des étapes du chargement des données sur SIEBEL.

Les étapes du chargement des données sur Siebel se résument ainsi :

• Extraction des données sur des fichiers plats.

• Charger ces données dans des tables de traitement afin de faire les vérifications et les
traitements nécessaires sur les données. Exemple :
¾ Changer les codes par leurs significations (statut client =2 Î client Active)

¾ Vérifier les champs obligatoires.

¾ Vérifier le bon format des champs (ex. format date JJ/MM/AAAA).

• Charger les données traitées sur les tables d’interfaces de l’IEM

 
58 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

• Charger les données sur les tables de base Siebel, le serveur EIM va :

¾ Lire un fichier de configuration qui spécifie processus EIM à exécuter (importer,


mettre à jour, fusionner, supprimer, exporter) en utilisant les paramètres
appropriés. Les fichiers EIM de configuration (le fichier par défaut est default.ifb)
est un fichier texte ASCII extension de type (. IFB) qui réside dans le serveur
Siebel / admin répertoire.

¾ Exécuter les commandes à faire soit importer, migrer, supprimer ou exporter


comme le montre le schéma ci-après :

• Base table est la destination finale des données importées dans la base de données de
Siebel et la source de données pour l’interface clients.

Figure 13 : structure interne de l’EIM.

1.8. Présence de données rejetées :


La migration entre les différentes étapes d’extraction et chargement des données décrit
précédemment a généré des données rejetées qui ne rentrent pas dans les critères des
procédures, ces derniers engendrent un dysfonctionnement entre les deux systèmes BSCS et
Siebel.

 
59 
 
Partie II Chapitre 2: Analyse de l’existant décisionnel

1.9. Diagnostique de l’existant :


Le but de cette étude était dans un premier temps de décrire le système actuel, puis
d’établir un diagnostique nous permettant d’extraire les dysfonctionnements afin d’y
remédier. Nous avons constaté quelques anomalies que voici :

Anomalie 1. Processus d’extraction et chargement de données sur Siebel contraignant.


Cause :
Manque de standard pour les opérations.
Conséquences :
Augmentation du nombre de rejets.

Anomalie 2. Gestion manuelle des données rejetées.


Cause :
Manque d’outils informatiques.
Traitement effectué manuellement, et sans suivie.
Conséquences :
Perte de temps dans le traitement de l’information.
Risque de perte d’informations concernant les clients.
Diminution du chiffre d’affaire.

2. CONCLUSION
Au cours de cette partie de l’étude de l’existant, nous avons présenté Wataniya
Télécom Algérie et sa politique, étudié les différentes composantes de son environnement et
tiré les conclusions qui en découlent.
Un système de monitoring et d’analyse des rejets est nécessaire au service CRM pour
bien piloter les données, En effet, le suivi actuel ne se fait pas d’une façon organisée ce qui
engendre en général un grand retard (donc perte d’argent et de temps). Une fois
l’application faite, l’utilisateur se trouve en face de données qui reflètent d’une manière
fidèle la réalité du système.

Cette étape que nous venons d’achever nous servira de point base dans l’élaboration
de la prochaine étape, qui est l’étude conceptuelle.

 
60 
 
 

 
PARTIE II :
 

 
CHAPITRE 3 :
 
ETUDE DU  CONCEPT
 

 
Partie II Chapitre 3 : Etude du Concept

1. INTRODUCTION
De nos jours les entreprises cherchent de plus en plus à fidéliser leur clientèle à cause
de l’environnement devenu très concurrentiel. Pour se faire, il faut opter pour un programme
de fidélisation bien adapté. C’est pour ça que Nedjma positionne le client au cœur de ses
préoccupations. Toute l’activité de l’entreprise tourne autour du client. Cette prise de
conscience a donné naissance au besoin d’un CRM (Customer Relationship Management).
Le CRM est une démarche qui vise à procurer tous les outils indispensables à la gestion de
la clientèle. Le CRM englobe aussi l’aspect fidélisation de la clientèle.

Une fois l’étude du système existant achevée, une étude qui nous a permis de
comprendre le système, d’apporter un diagnostic sur ce dernier, et de tirer les points de
dysfonctionnement, la conception peut alors commencer.

La première des choses, avant d’entamer cette phase est de fixer d’abord une approche
de conception à suivre, par ailleurs, il est un fait que l’usage de l’expression adjective
« Orienté Objet », est devenu dans les milieux informatiques quasiment synonyme de
modernité, de sûreté et de valeur, au delà de cette publicité nous avons décidé de se faire une
opinion plus nuancée.

Il existe plusieurs outils de conception et nous avons choisi la modélisation orientée


objet UML qui est un langage unifié correspondant à notre système, le choix de cet outil a
trouvé origine dans le fait qu’il est caractérisé par la stabilité de la modélisation par rapport
au monde réel et la réutilisation des objets, ainsi que la notion de prototypage.

Cet outil doit être accompagné d’une démarche qui pourra guider la conception, étape
par étape jusqu’à la réalisation.

Le processus 2TUP (2 Track unified process), est une démarche pouvant supporter
l’outil UML qui permet de séparer un projet en deux branches principales, à savoir
fonctionnelle (gauche) et la branche technique (droite). La première concerne les besoins
métiers du système et la deuxième tachera de construire le squelette technique et la
composition logicielle du nouveau système. Et à la fin ces deux branches se fusionneront
pour déboucher sur la branche du milieu qui tracera la cartographie des composants du
système à développer.

 
62 
 
Partie II Chapitre 3 : Etude du Concept

2. ORGANISATION DE L’ETUDE DU CONCEPT.


Nous allons présenter à travers ce document le travail accomplis relativement à cette
étape, dont l’objectif est de déterminer de façon détaillée et précise ce que le nouveau
système devrait être afin de répondre aux objectifs établis.

Cette partie sera structurée de la manière suivante :

Partie A : Description du principe de la solution proposée et présentation de l’architecture


globale.

Partie B : Définir l’outil de conception et la méthode choisie, expliquer la démarche, et les


différentes étapes à suivre dans notre conception.

Partie C : Suivre la démarche adopter pour la solution qui est la démarche 2TUP et elle
est structuré de la manière suivante :

• Etude préliminaire.

• Capture des besoins fonctionnels.

• Capture des besoins techniques.

• Découpage en catégorie.

• Développement du modèle statique

• Développement du modèle dynamique.

• Conception générique.

• Conception primaire.

• Conception détaillée.

• Conclusion.

 
63 
 
Partie II Chapitre 3 : Etude du Concept

3. PARTIE A :
Le principe de notre solution pour le projet CRM, est de rendre le traitement des
données rejetées en traitement automatique grâce à une application qui va d’abords
récupérer les données rejetées des différentes étapes de migration, puis faire une
catégorisation de ces rejets, assigner chaque catégorie a un groupe d’utilisateurs pour faire
le traitement de ces derniers et enfin les remettre corrigées dans la source de recyclage.

2
4

1
3

Source de  Table des
rejets rejets

5 Les utilisateurs

6
Table de Les rejet traitées
recyclage

 
64 
 
Partie II Chapitre 3 : Etude du Concept

Figure 14 : Schéma du principe de la solution

4. PARTIE B :
Notre choix s’est porté sur l’approche orientée objet destinée à faciliter l’évolution
d’applications complexes et offrant une panoplie d’outils et de langages performants pour le
développement. De ce fait, nous optons pour le langage de modélisation UML (Unified
Modeling Language). Cependant, UML n’est qu’un langage de modélisation, il doit être
accompagné d’une méthode à savoir UP (Unified Process) qui prend en charge le cycle de
vie d’un logiciel et son développement. Mais la méthode UP reste générique c’est à dire elle
définit un certain nombre de critères de développement, que chaque société peut par la suite
personnaliser afin de créer son propre processus plus adapté à ses besoins

4.1. UML :

4.1.1. Introduction à la notation UML :

UML (Unified Modeling Language, que l’on peut traduire par « langage de
modélisation unifié) est une notation permettant de modéliser un problème de façon
standard. Ce langage est né de la fusion de plusieurs méthodes existantes auparavant, et est
devenu désormais la référence en terme de modélisation objet, à un tel point que sa
connaissance est souvent nécessaire pour obtenir un poste de développeur objet.

4.1.2. La notion d’objet :

La programmation orientée objet consiste à modéliser informatiquement un ensemble


d’éléments d’une partie du monde réel (que l’on appelle domaine) en un ensemble d’entités

 
65 
 
Partie II Chapitre 3 : Etude du Concept

informatiques. Ces entités informatiques sont appelées objet. Il s’agit de données


informatiques regroupant les principales caractéristiques des éléments du monde réel (taille,
la couleur, …). La difficulté de cette modélisation consiste à créer une représentation
abstraite, sous forme d’objets, d’entités ayant une existence matérielle (chien, voiture,
ampoule, …) ou bien virtuelle (sécurité sociale, temps, …).

4.2. Processus Unifié (Unified Process):

Un processus unifié c’est le développement de logiciels construit sur UML. Il est :

• Itératif ;

• Centré sur l’architecture ;

• Conduit par les cas d’utilisation et piloté par les risques.

La gestion d’un tel processus est organisée suivant 4 phases :


• Pré – étude;
• Elaboration;

• Construction;

• Transition.
Les activités de développement sont définies par 5 workflows fondamentaux qui décrivent:
• La capture des besoins ;
• L’analyse ;

• La conception ;

• L’implémentation ;

• Le test.
Tout processus UP répond aux caractéristiques ci après :
• Il est incrémental. La définition d’incréments de réalisation est en effet la meilleure
pratique de gestion des risques techniques et fonctionnels.

 
66 
 
Partie II Chapitre 3 : Etude du Concept

• Il est piloté par les risques. Les causes majeures d’échec d’un projet logiciel doivent être
écartées en priorités ; les deux principales causes sont l’incapacité de l’architecture
technique à répondre aux contraintes opérationnelles et l’inéquation du développement
aux besoins utilisateurs.

• Il est construit autour de la création et de la maintenance d’un modèle, plutôt que de la


production de montage de documents.

• Il est itératif. Chaque itération porte sur un niveau d’abstraction de plus en plus précis.

• Il est orienté composant.

• Il est orienté utilisateur.

4.2.1.2TUP :

Créer par la société Valtech, la méthode 2TUP ou l’approche en Y est l’acronyme de


«2 Track Unified Process». C’est un processus qui répond aux caractéristiques du Processus
Unifié apportant une réponse aux contraintes de changement continuel imposées aux
systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités
d’évolution et de correction de tels systèmes. « 2 Track» illustre le fait que cette méthode
contienne 2 branches principales à savoir une branche fonctionnelle et une branche
technique (Voir figure 16). La 1ere branche traite l’aspect métier du système et la 2eme
branche traite la structure technique et la composition logicielle du nouveau système. Puis
ces deux branches se rejoignent pour déboucher sur la branche du milieu qui tracera la
cartographie des composants du système à développer.

 
67 
 
Partie II Chapitre 3 : Etude du Concept

Branche fonctionnelle Branche technique

Contraintes Capture des besoins Capture des besoins


fonctionnels techniques
Contraintes
fonctionnelles techniques
Analyse Conception générique

Conception préliminaire

Conception détaillée

Implémentation

Déploiement

Figure 15 : La démarche 2TUP

4.2.2. La démarche 2TUP

La démarche 2 TUP se résume en :

• Branche fonctionnels (gauche)


• Branche architecture technique (droite)
• Branche conception (milieu)

• Capture des besoins fonctionnels


• Analyse
• Capture des besoins techniques
• Conception générique
• Conception préliminaire
• Conception des classes

Nous détaillons chaque étape en annexe.

5. PARTIE C :

 
68 
 
Partie II Chapitre 3 : Etude du Concept

5.1. Etude préliminaire :


Cette partie va nous servir à poser les bases de la capture du système à réaliser.

L’étude préliminaire (ou pré étude) est la première étape de notre processus de
conception. Elle survient à la suite d’une décision de démarrage de projet, et consiste à
effectuer un premier repérage des besoins fonctionnels ou opérationnels, en utilisant
principalement des testes, ou des diagrammes très simples.

Nous verrons successivement dans cette partie :

• L’identification des acteurs.

• L’identification des messages.

• La réalisation des diagrammes de contexte.

5.1.1. Identification des acteurs :

Qu’est-ce qu’un acteur ?

Un acteur représente l’abstraction d’un rôle joué par des entités externes (utilisateur,
dispositif matériel ou autre système) qui interagissent directement avec le système étudié.

Un acteur peut consulter et/ou modifier directement l’état du système, en émettant


et/ou en recevant des messages éventuellement porteurs de données.

Les acteurs candidats sont systématiquement :

• Les utilisateurs humains directs : il faut identifier tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance, etc.

• Les autres systèmes connexes qui interagissent aussi directement avec le système.

Il faut vérifier que les acteurs communiquent bien directement avec le système, par
émission et/ou réception de messages.

Les acteurs recensés dans notre système sont :

• Système Billing BSCS.

• Système CRM Siebel.

• Equipe Billing.

 
69 
 
Partie II Chapitre 3 : Etude du Concept

• Equipe CRM.

• Administrateur système.

• Administrateur de données.

• Equipes d’assainissement.

5.1.2. Rôle des acteurs

• Système Billing BSCS : C’est le système d’où proviennent toutes les données (source
de données).
• Système CRM Siebel: C’est le système où vont êtres acheminés les données
(destination des données).
• Equipe Billing : C’est l’équipe facturation qui gère le système BSCS.

• Equipe CRM : C’est l’équipe responsable du projet CRM.

• Administrateur de données : Traite principalement les données rejetées.


• Administrateur système : Définit les rôles et les privilèges d’accès aux ressources du
système des utilisateurs, les profils utilisateurs, les mots de passe.
• Equipes d’assainissement : C’est les équipes chargées par l’assainissement des
données rejetées (épuration, correction)

5.1.3. Modéliser le contexte :

 
70 
 
Partie II Chapitre 3 : Etude du Concept

Tous les messages (système acteurs)


identifiés précédemment peuvent être représentés de façon synthétique sur un diagramme
appelé « diagramme de contexte dynamique ».

Cette notion de message est utilisée pour décrire les interactions de plus haut niveau
entre les acteurs et le système.

On utilise un diagramme de contexte UML.

Š Le système utilisé est représenté par un objet central.

Š Cet objet central est entouré par d’autres objets symbolisant les différents acteurs.

Š Des liens relient le système à chacun des acteurs.

Š Sur chaque lien sont montrés les messages en entrée et en sortie du système, sans

numérotation.

 
71 
 
Partie II Chapitre 3 : Etude du Concept

Figure 16: Diagramme de contexte.

Lien Description

(1) - Création, modification et attribution des privilèges utilisateurs (profil user).

(2) - Rôles et privilèges des utilisateurs.

(3) - Les données rejetées BSCS.

(4) - Les données à corriger.

- Les réponses concernant les données corrigées.


(5)
- Edition des rapports et statistiques.

(6) - Les données rejetées Siebel.

(7) - Les données traitées.

(8) - Les données à corriger.

 
72 
 
Partie II Chapitre 3 : Etude du Concept

- Edition des rapports et statistiques.

(9) - Les réponses concernant les données corrigées.

- Configuration des sources de récupération des rejets.

(10) - Ajout de nouveaux critères ou de nouveaux évènements ponctuels qui


entraînent la Mise à jour des données systèmes.

(11) - Edition des rapports et statistiques.

(12) - les données à assainir.

(13) - Commentaires sur les cas traité.

Tableau 2 : Messages entrants et sortants du système.

5.2. Capture des besoins fonctionnels :

Cette partie traite le rôle que tient UML pour compléter la capture des besoins
fonctionnels ébauchés durant l’étude préliminaire. La technique des cas d’utilisation est la
pierre angulaire de cette étape. Elle va nous permettre de préciser l’étude du contexte
fonctionnelle du système, en décrivant les différentes façons qu’auront les acteurs d’utiliser
le futur système.

Nous verrons successivement dans cette partie comment :

• Faire un recueil initial des besoins fonctionnels et opérationnels.


• Identifier les cas d’utilisation du système par ses acteurs.
• Décrire les cas d’utilisation.
• Organiser les cas d’utilisation.
• Identifier les classes candidates du modèle d’analyse.

L’objectif de la capture des besoins fonctionnels consiste à déterminer ce que le


système doit faire, c'est-à-dire, « le quoi », à fournir aux développeurs une meilleure
compréhension des fonctionnalités du système qu’ils doivent développer, à définir le
contour du système et enfin à fournir la base de la planification ainsi que le contenu
technique des itérations.

 
73 
 
Partie II Chapitre 3 : Etude du Concept

5.2.1. Recueil initial des besoins fonctionnels et opérationnels :

Nous avons effectué plusieurs recherches pour cerner et identifier au mieux les besoins
de l’application dans le but de répondre aux attentes des utilisateurs.

Dans ce qui suit nous allons exposer ces besoins ainsi que les attentes du nouveau
système de traitement des rejets, ces besoins seront regroupés selon leur domaine d’impact
pour améliorer la lisibilité du document

™ Récupération des rejets :


Cette partie concerne le besoin en termes de récupération des données rejetées qui
commence par la définition des sources de rejet de ces données afin de permettre à notre
système de les inclure dans le processus de traitement.

™ Analyse des rejets :


Durant cette partie, nous allons faire l’analyse des données rejetées afin de pouvoir
déterminer les critères de classification pour faire une catégorisation des rejets et déclencher
le traitement de ces derniers.

™ Assignation des rejets :


Cette partie consiste à assigner les rejets classifiés aux services concernés.

™ Assainissement des rejets :


Cette étape consiste à faire une correction manuelle ou automatique des données
rejetées.

™ Recyclage des données rejetées :


Une fois les données sont corrigées, notre système doit permettre de les remettre dans
le système sources.

™ Administration :
Pour cette partie le rôle principal est de créer les profiles utilisateurs, gérer les
privilèges, les droits d’accès aux multiples niveaux, ainsi que définir les catalogues de
privilège pour chaque profile.

™ Etablir des rapports et statistiques :


Cette étape consiste à faire des différents rapports sur plusieurs critères citons :

• Faire des divers historiques sur :


a.les données rejetées dénombrées.

 
74 
 
Partie II Chapitre 3 : Etude du Concept

b. les données rejetées traitées.


c.Les rejets avec états en suspens, encore pas traitées.
d. …etc.

• Faire une base de connaissances qui va regrouper tout les cas déjà rencontrés.

Ainsi que mettre à disposition ces rapports pour l’ensemble des services concernées
par notre études.

™ Gestion et sécurité des utilisateurs :


Les utilisateurs de notre système devraient avoir leur propre section, à partir de
laquelle ils devraient pouvoir voir les détails de notre système chacun selon ces privilèges
attribués.

Le système doit assurer la sécurité d’accès; c'est-à-dire qu’une personne qui n’a pas de
session ne pourra en aucun cas accéder a notre système. Le système doit aussi sauvegarder
soigneusement les mots de passe des utilisateurs et faire des changements répétés des
passeword sur des durées déterminées.

™ Conditions d’intégration du système :


Le système doit être flexible pour s’intégrer avec les divers systèmes existant tel que :
CRM (SIEBEL), Billing (BSCS)…

L'intégration de notre système aux autres systèmes doit s’effectuer selon une méthode
de communication standard avec un protocole standard et non pas propre au système de
traitement des rejets.

5.2.2. Identification des cas d’utilisation :

Les cas d’utilisations modélisent un dialogue entre un acteur et le système. Ils


représentent la fonctionnalité fournie par le système, c’est-à-dire, les services qui seront
rendus par le système. L’ensemble des cas d’utilisation pour un système donné constitue
toutes les façons dont le système peut être utilisé.

La définition formelle d’un cas d’utilisation est la suivante : « représente un ensemble


de séquences d’actions réalisées par le système produisant un service ou une valeur ajoutée
pour un acteur particulier. Il exprime les interactions (acteur/système) et permet de décrire
ce que le futur système devra faire, sans spécifier le comment ». [UML A, 02]

 
75 
 
Partie II Chapitre 3 : Etude du Concept

Les questions suivantes contribuent à identifier les cas d’utilisation d’un système.

- Quelles sont les tâches de chaque acteur ?


- Un acteur va-t-il créer, modifier, supprimer ou stocker ou lire des informations du
système ?
- Pour quel cas d’utilisation devra-t-on créer, stocker, modifier, supprimer ou lire ces
informations ?
- Un acteur aura-il le besoin d’informer le système d’un changement externe inopiné ?
- Un acteur aura-il besoin d’être informé de certains événements survenant dans le
système ?
- Quels cas d’utilisation décriront la maintenance du système ?
- Tous les cas d’utilisation identifiés couvrent-ils l’ensemble des besoins fonctionnels ?

La réponse aux questions citées précédemment a permis de faire ressortir les cas
d’utilisation en mettant en évidence les notions suivantes : message, acteur principal, acteur
secondaire.

Le tableau ci-après résume les principaux cas d’utilisation qui seront détaillés par la
suite :

Cas d’utilisation Acteurs Description

L’administrateur des données défini


Définir les sources des Administrateur des dans une procédure stockée les tables
rejets données. des différentes bases ou le système va
récupérer les rejets.

Cette tache se résume sur l’importation


Administrateur des des données rejetées, autrement dis
Récupérer les rejets
données. c’est le lancement de la procédure de
récupération.

L’administrateur de données peut


modifier les critères de catégorisation
Configurer les règles de Administrateur de des rejets et ça dans une procédure
classification des rejets données stockée selon le besoin.

 
76 
 
Partie II Chapitre 3 : Etude du Concept

La catégorisation est soit automatique


grâce à la procédure pour les critères de
Administrateur des classification déjà définie, soit manuelle
Catégoriser les rejets données. par l’administrateur de données pour les
cas qui ne rentrent pas dans la
catégorisation automatique.

L’administrateur de données configure


Configurer les règles Administrateur des
les critères d’assignation selon la
d’assignation des rejets données.
catégorisation des données rejetées.

L’assignation est aussi soit automatique


grâce à la procédure pour les cas qui
Administrateur des rentrent dans les critères de
Assigner les rejets
données. classification déjà définie, soit manuelle
par l’administrateur de données pour le
reste des cas.

l’équipe Billing, les


le traitement d’un rejet c’est comme un
Prendre en charge un équipes
statut préliminaire au rejet afin d’éviter
rejet assainissement,
les redondances dans les traitements.
l’équipe CRM.

L’acteur peut mettre à jour le statut


d’un rejet exemple : fermé, ouvert pour
Administrateur des assainissement (manuel/automatique),
Changer statut d’un
données, l’équipe assigné vers un autre utilisateur
rejet
Billing, les équipes (Escalader le rejet vers un autre niveau
assainissement, afin de poursuivre son traitement),
l’équipe CRM. Garder le rejet dans le même niveau
dans le but de le suspendre ou
régler...etc.

Administrateur des L’acteur peut avoir une vision sur l’état


Consulter les données, l’équipe de n’importe quel rejet
informations relatives a Billing, les équipes
un rejet assainissement,
l’équipe CRM.

 
77 
 
Partie II Chapitre 3 : Etude du Concept

Administrateur des Permet à l’utilisateur de consulter le


données, l’équipe traitement d’un cas de rejet à n’importe
Consulter l’historique
Billing, les équipes quel moment ainsi que le cycle de vie
de traitement d’un rejet.
assainissement, de ce rejet depuis la création jusqu’à
l’équipe CRM son état actuel.

Mettre à jour la base de Administrateur de Permet à l’acteur d’enrichir la base avec


connaissances. données les nouvelles connaissances acquises.

Administrateur des
données, l’équipe
Interroger la base de Permet à l’acteur d’avoir une Aide pour
Billing, les équipes
connaissances. trouver une solution rapidement.
assainissement,
l’équipe CRM

L’administrateur de données défini une


Remise des rejets
Administrateur de procédure qui permet la remise des
corrigés dans la source
données rejets traités dans la source de
(recyclage).
recyclage.

L’administrateur de données édite des


Editer les rapports et Administrateur de rapports et statistiques sur toute donnée
statistiques. données ou traitement voulu et peut consulter
ces derniers à n’importe quel moment.

Gestion des utilisateurs L’administrateur du système gère les


système Administrateur
droits d’accès des utilisateurs du
système système, il peut créer, supprimer ou
modifier les comptes des utilisateurs.

Administrateur
système, Les utilisateurs du système doivent
administrateur des toujours s’authentifier avant d’accéder à
Authentification des
données, l’équipe leurs espaces de travail.
utilisateurs
Billing, l’équipe
CRM

Tableau 3 : les différents cas d’utilisation

 
78 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3. Etude détaillée des cas d’utilisation :

Dans ce qui suit nous allons détailler les principaux cas d’utilisation de notre système,
les autres seront décrits en annexe.

5.2.3.1. Cas d’utilisation « Définir les sources des rejets » :

Description préliminaire :
Intention : Définir des systèmes extérieurs les sources des rejets afin de pouvoir les insérer
dans notre système.
Action : Identifier et paramétrer les sources ou sont stocké les données rejetées.

Figure 17 :Diagramme du cas d’utilisation « Définir les sources des rejets»


Sommaire d’identification

Titre : Définir les sources des rejets.


But : Déterminer où nous pouvons récupérer les rejets des différents systèmes.
Résumé : L’administrateur des données défini les tables des différentes bases ou sont
stocké ces rejets.
Acteur : Administrateur de données.
Description des enchaînements
Pré conditions :
- Avoir accès sur la base des systèmes extérieurs.
Enchaînements :
Ce cas d’utilisation résume la méthode de la détermination des points de récupération des
données rejetées des différents systèmes liés à notre application le tout dans une procédure.
Enchaînement a : Définir les sources des rejets.
L’administrateur des données définit les sources des rejets.
Enchaînement b : Paramétrage des sources.
L’administrateur des données crée une script sur lequel il paramètre ces sources.
Post-condition :
Les sources des données rejetées définies et paramétrées.
 

 
79 
 
Partie II Chapitre 3 : Etude du Concept

Figure 18 : Diagramme d’activité du cas d’utilisation « Définir les sources des rejets »
 

5.2.3.2. Cas d’utilisation « Récupérer les rejets » :

Description préliminaire :
Intention : Récupération des rejets par notre système.
Action : Récupérer les données qui se trouvent dans les sources des rejets.

                              
Figure 19 : Diagramme du cas d’utilisation « Récupérer les rejets»
 

Sommaire d’identification
Titre: Récupérer les rejets.
But: Alimenter notre système par les données rejetées.
Résumé: Cette tache se résume sur l’importation des données rejetées de ces différentes
sources.
Acteur: Administrateur des données.
Description des enchaînements
Pré conditions :
- Les sources des données rejetées définies.

 
80 
 
Partie II Chapitre 3 : Etude du Concept

Enchaînements :
Ce cas d’utilisation est sensé être journalier et planifier a une heure bien précise
Enchaînement a : Récupération des données.
L’administrateur programme le système pour exécuter le script de récupération des
données rejetées depuis les sources.
Enchaînement b : Insertion des données dans le système.
L’administrateur programme les tables ou les données vont êtres insérées.

Enchaînements alternatifs :
Enchaînement c : annulation de l’opération
Si L’administrateur annule l’opération aucune récupération ne sera effectuée.

Post conditions :
- les données rejetées sont récupérées et insérées dans notre système.

Exceptions :
- Action annulée

                                

Figure 20: Diagramme d’activité du cas d’utilisation « Récupérer les rejets »

 
81 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3.3. Cas d’utilisation « Configurer les règles de classification des rejets» :

Description préliminaire:
Intention : Faire la Catégorisation des rejets selon des règles que nous allons définir.
Action : Configurer les règles de catégorisation des rejets.

Figure 21: Diagramme du cas d’utilisation « Configurer les règles de classification des rejets»
Sommaire d’identification
Titre : Configurer les règles de classification des rejets.
But : Etablir les règles de classification.
Résumé : L’administrateur de données configure les critères de catégorisation des rejets
et les modifie selon le besoin du système.
Acteur : Administrateur des données.
Description des enchaînements
Pré conditions :
- L’administrateur de données est authentifié.
- Les rejets récupérés sur système.

Enchaînements :
Ce cas d’utilisation commence une fois les rejets soient insérées dans notre système et
lorsque l’administrateur demande la configuration des règles de classification de ces
derniers.
Scénario1 : Création de la procédure de catégorisation.
Enchaînement a : Analyse des données rejetées
L’administrateur de données fait une analyse sur ces rejets pour détecter les
critères de catégorisation.
Enchaînement b : Création de la procédure de catégorisation
L’administrateur crée un script qui fait la catégorisation des rejets selon les
critères définis.

 
82 
 
Partie II Chapitre 3 : Etude du Concept

Scénario2 : Un nouveau cas de rejet.


Enchaînement a : Analyse des données rejetées non catégorisée
L’administrateur de données fait une analyse sur ces nouveaux cas de rejets pour
détecter les nouveaux critères de catégorisation.
Enchaînement b : Ajouter le nouveau critère a la procédure de catégorisation
L’administrateur modifie la procédure et ajoute les nouveaux critères.
Post conditions :
Post-condition scénario 1 :
- les règles de classification des rejets définies dans notre système.
Post-condition scénario 2 :
- nouveau critère ajouté
Exceptions :
- Connexion et authentification échouées.
- Opération annulée.

Figure 22: Diagramme d’activité du cas d’utilisation « Configurer les règles de classification des
rejets »

 
83 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3.4. Cas d’utilisation « Catégoriser les rejets » :

Description préliminaire :
Intention: Faire une catégorisation des rejets.
Action : Catégoriser un rejet.

Figure 23 : Diagramme du cas d’utilisation « catégoriser les rejets»


Sommaire d’identification
Titre : Catégoriser les rejets.
But : Attribuer une classe à un rejet.
Résumé : Pour chaque rejet, l’administrateur va faire sa catégorisation.
Acteur : Administrateur des données.

Description des enchaînements

Pré conditions :
- L’administrateur est authentifié.
- Rejets récupérés sur système.
- Les règles de classification définies.

Enchaînements :
Ce cas d’utilisation commence lorsque nous avons des nouvelles données rejetées dans
notre système et l’administrateur demande la catégorisation.
Enchaînement a : Sélection des rejets.
Sélectionner tout les nouveaux les rejets.
Enchaînement b : Lancer la catégorisation automatique.
Lancement du script pour faire une première catégorisation automatique.
Scénario 1 : Si tous les rejets ont été catégorisés :
Enchaînement d : confirmer l’opération puis valider.
Scénario 2 : Des rejets n’ont encore catégorisés :

 
84 
 
Partie II Chapitre 3 : Etude du Concept

Enchaînement e : Récupération des rejets non catégorisés.


L’administrateur récupère les rejets qui ne rentrent pas dans les critères de la
catégorisation automatiques.
Enchaînement c : Regrouper et analyser les rejets non classifiés.
L’administrateur regroupe ces rejets et leurs donnes une valeur par défaut afin de faire
l’analyse et détecter les nouveaux critères de classification.
Enchaînement h : Ajouter les nouveaux critères de classification.
Faire appel au cas d’utilisation « Configurer les règles de classification des rejets »
Enchaînement i : aller Enchaînement a

Post conditions :
- Tous les rejets catégorisés.

Exceptions :
Connexion et authentification échouées.

Figure 24 : Diagramme d’activité du cas d’utilisation « catégoriser les rejets »

 
85 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3.5. Cas d’utilisation « configurer les critères d’assignation » :

Description préliminaire :
Intention : Faire l’assignation des rejets selon les types de catégorisation.
Action : Configurer les critères d’assignation des rejets.

 
Figure 25 : Diagramme du cas d’utilisation « configurer les critères d’assignation des rejets»
Sommaire d’identification
Titre : configurer les critères d’assignation des rejets
But : Etablir les règles d’assignation.
Résumé : L’administrateur de données configure les critères d’assignation des rejets et
les modifie selon le besoin du système.
Acteur : Administrateur des données.
Description des enchaînements
Pré conditions :
- L’administrateur de données est authentifié.
- Les rejets catégorisés.

Enchaînements :
Ce cas d’utilisation commence une fois les rejets soient catégorisés
Scénario1 : Création de la procédure d’assignation.
Enchaînement a : Analyse des données rejetées catégorisés
L’administrateur de données fait une analyse sur les catégories des rejets pour
détecter les critères d’assignation.
Enchaînement b : Création de la procédure d’assignation.
L’administrateur crée un script qui fait l’assignation des rejets selon les catégories
définis.
Scénario2 : Un nouveau cas de rejet.
Enchaînement a : Analyse des nouvelles catégories des rejets.
L’administrateur de données fait une analyse sur ces nouvelles catégories des
rejets pour les faire assigner à un groupe d’utilisateurs.

 
86 
 
Partie II Chapitre 3 : Etude du Concept

Enchaînement b : Ajouter le nouveau critère a la procédure d’assignation.


L’administrateur modifie la procédure et ajoute les nouvelles catégories des rejets.
Post conditions :
Post-condition scénario 1 :
- la procédure d’assignation établie.
Post-condition scénario 2 :
- nouveau critère ajouté
Exceptions :
- Connexion et authentification échouées.
- Opération annulée.

Figure 26: Diagramme d’activité du cas d’utilisation «Configurer les règles d’assignation des
rejets»

5.2.3.6. Cas d’utilisation « Assigner les rejets » :

Description préliminaire :

 
87 
 
Partie II Chapitre 3 : Etude du Concept

Intention: Faire un suivi de traitement d’un rejet.


Action : assigner un rejet aux filières concernées.

Figure 27: Diagramme du cas d’utilisation «Assigner un rejet»


Sommaire d’identification
Titre : Assigner un rejet.
But : Assigner les rejets aux services concernés selon le type et la catégorisation.
Résumé : Pour les données rejetées de notre système, l’administrateur va faire une
assignation aux équipes concernées par le traitement.
Acteur : Administrateur des données.
Description des enchaînements
Pré conditions :
- L’administrateur est authentifié.
- Procédure d’assignation établie.
Enchaînements :
Ce cas d’utilisation commence une fois l’opération de catégorisation terminée et lorsque
l’administrateur entame l’opération de traitement.
Enchaînement a : Lancer l’assignation automatique.
L’administrateur lance le script pour faire une première assignation automatique.
Scénario 1 : Si tous les rejets ont été assignés :
Enchaînement c : confirmer l’opération puis valider. (le rejet change d’état « nouveau »
vers « Assigné »)
Scénario 2 : Des rejets n’ont encore assignés:
Enchaînement d : Récupération des rejets non assigné.
L’administrateur récupère les rejets qui ne rentrent pas dans les critères d’assignation
automatiques.
Enchaînement f : Regrouper et analyser les rejets non assignés.
L’administrateur regroupe ces rejets (statut « En attente») afin de faire l’analyse et
détecter les nouveaux critères d’assignation.
Enchaînement h : Ajouter les nouveaux critères de classification.

 
88 
 
Partie II Chapitre 3 : Etude du Concept

Faire appel au cas d’utilisation « Configurer les critères d’assignation des rejets »
Enchaînement i : aller Enchaînement a.

Post conditions :
- Tous les rejets assignés.

Exceptions :
Connexion et authentification échouées.

Figure 28 : Diagramme d’activité du cas d’utilisation « Assigner un rejet »


 

5.2.3.7. Cas d’utilisation «Prendre en charge un rejet» :

Description préliminaire :
Intention: Faire le traitement d’un rejet
Action : Traiter un rejet

 
89 
 
Partie II Chapitre 3 : Etude du Concept

Figure 29: Diagramme du cas d’utilisation «Prendre en charge un rejet»


Sommaire d’identification
Titre: Prendre en charge un rejet.
But: Garantir qu’un rejet soit traitée par un seul utilisateur à la fois afin d’éviter les
redondances dans les traitements.
Résumé: Une fois l’assignation des rejets a été faite, chaque acteur prend en charge le
traitement de ses cas de rejets.
Acteur : Administrateur des données, l’équipe Billing, l’équipe assainissement, l’équipe
CRM
Description des enchaînements
Pré conditions :
- L’acteur est authentifié.
Enchaînements :
Ce cas d’utilisation commence lorsque l’acteur demande le traitement d’un rejet.
Enchaînement a : Afficher la liste des nouveaux rejets.
L’acteur ouvre la liste des nouveaux rejets qui lui sont assignés.
Enchaînement b : Sélectionner un rejet.
L’acteur ouvre le rejet sélectionné (le rejet change d’état d’«Assigné» à « ouvert »)
Enchaînement c : Faire le traitement du rejet.
Scénario 1 : Traitement possible
L’acteur prend en charge le rejet et fait les traitements nécessaires.
Enchaînement d : Faire le changement de statut.
Appel au cas d’utilisation « changer le statut d’un rejet », le rejet aura comme
nouvel état « Fermer »

 
90 
 
Partie II Chapitre 3 : Etude du Concept

Enchaînement e : Valider le traitement.


L’acteur ferme le rejet et le système assigne le rejet à l’acteur qui l’a traité.
Scénario 2 : Traitement impossible
Enchaînement b : Annuler la prise en charge.
L’acteur annule la prise en charge du rejet.
Enchaînement c : Retransférer le rejet.
Remettre le rejet a l’état «Assigné».
Post conditions :
Post-condition cas de succès :
Le rejet aura comme statut « Clos ».

Post-condition cas d’échec :


Le rejet aura comme statut « Assigné».
Exceptions :
Connexion et authentification échouées.

Figure 30 : Diagramme d’activité du cas d’utilisation « Prendre en charge un rejet »

 
91 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3.8. Cas d’utilisation «Changer le statut d’un rejet » :

Description préliminaire :
Intention : Faire le changement de statut pour un rejet.
Action : Basculer le statut du rejet d’un état à un autre.

 
Figure 31: Diagramme du cas d’utilisation «Changer le statut d’un rejet»
 

Sommaire d’identification
Titre : Changer le statut d’un rejet.
But : Basculer le statut d’un rejet d’un état à un autre.
Résumé : Le traitement d’un rejet nécessite le changement de son statut, alors quelque
soit le résultat du traitement le rejet doit avoir à la fin un nouveau statut.
Acteur : Administrateur des données, l’équipe Billing, l’équipe assainissement, l’équipe
CRM
Description des enchaînements
Pré conditions :
- L’acteur est authentifié.
Enchaînements :
Ce cas d’utilisation commence lorsque l’acteur prend en charge un rejet qui lui est
assigné et aborde le traitement de ce dernier.
Enchaînement a : sélectionner le rejet.
L’acteur choisi un rejet et affiche ses détails.
Enchaînement b : sélectionner un nouveau statut.
L’acteur défile du système la liste des statuts et sélectionne un nouveau.
Enchaînement c : Valider le changement.
Le système valide le changement d’état du rejet.

 
92 
 
Partie II Chapitre 3 : Etude du Concept

Post conditions :
- chaque rejet ouvert aura un nouveau statut.
Exceptions :
Connexion et authentification échouées.
 

 
Figure 32: Diagramme d’activité du cas d’utilisation « Changer le statut d’un rejet »
 

5.2.3.9. Cas d’utilisation «Remise des rejets corrigés dans la source (recyclage) » :

Description préliminaire :
Intention : Une fois le traitement des rejets terminé on renvois les données corrigées dans la
source.
Action : Remettre les rejets corrigés dans la source.

 
Figure 33 : Diagramme du cas d’utilisation «Remise des rejets corrigés dans la source (recyclage) »

 
93 
 
Partie II Chapitre 3 : Etude du Concept

Sommaire d’identification
Titre : Remise des rejets corrigés dans la source (recyclage).
But : dépôt des données rejetées corrigées à la source.
Résumé : Après la fin du traitement d’un rejet, le gestionnaire du système renvoi la
solution a la source.
Acteur : Administrateur des données.
Description des enchaînements
Pré conditions :
- L’acteur est authentifié.
- traitement de rejets achevés.
Enchaînements :
Ce cas d’utilisation commence une fois le traitement terminé, l’administrateur de
données récupère les rejets corrigés des différents niveaux.
Enchaînement a : Récupérer les données corrigées.
L’administrateur des données défini une procédure qui récupère tout les rejets dont le
statut est « Fermer ».
Enchaînement b : Renvoyer ces rejets dans la source.
L’acteur met ces données dans la source.
Post conditions :
- les rejets dont le statut « Fermer» remit dans la source.
Exceptions :
Connexion et authentification échouées.

Figure34 : Diagramme d’activité du cas d’utilisation «Remise des rejets corrigés dans la source
(recyclage)»

 
94 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3.10. Cas d’utilisation « Consulter les informations relative a un rejet » :

Description préliminaire :
Intention : Avoir une vue sur l’état d’un rejet donnée.
Action : Consulter l’état d’un rejet.

Figure 35 : Diagramme du cas d’utilisation «Consulter les informations relative à un rejet »

Sommaire d’identification
Titre : Consulter les informations relatives à un rejet.
But : Consulter à tout moment les informations relatives à un rejet.
Résumé : L’acteur peut avoir une vision sur l’état de n’importe quel rejet.
Acteur: Administrateur des données, l’équipe Billing, l’équipe assainissement, l’équipe
CRM.
Description des enchaînements
Pré conditions :
- Le Administrateur des données, l’équipe Billing, l’équipe assainissement et l’équipe
CRM sont authentifiés.
- - Il existe au moins un rejet dans la base de données.
Enchaînements :
Ce cas d’utilisation commence lorsque l’utilisateur demande au système de rechercher
un rejet.
Enchaînement a : Rechercher un rejet.
L’utilisateur lance une nouvelle recherche en choisissant des critères spécifiques.
Si ce rejet recherché n’existe plus, alors exécuter
[exeption1 : Recherche inexistante]

 
95 
 
Partie II Chapitre 3 : Etude du Concept

Si le rejet existe alors le système affiche le résultat de la recherche demandée.

Enchaînements alternatifs :
Enchaînement b : Afficher une liste.
Si l’utilisateur le souhaite, il peut chercher et afficher la liste de tous les rejets

Exceptions :
[exeption1 : recherche inexistante] le système indique que le rejet n’existe pas, et
redirige l’utilisateur vers une nouvelle recherche.
Post conditions :
Post-condition cas de succès :
L’utilisateur aura trouvé le rejet recherché.
Post-condition cas d’échec :
La recherche indique que les critères demandés ne donnent aucun résultat.

         

Figure 36 : Diagramme d’activité du cas d’utilisation «Consulter les informations relative à un


rejet»

 
96 
 
Partie II Chapitre 3 : Etude du Concept

5.2.3.11. Cas d’utilisation « Consulter l’historique de traitement d’un rejet » :

Description préliminaire :
Intention : vérifier l’historique d’un rejet donné.
Action : consulter l’historique d’un rejet.

Figure 37 : Diagramme du cas d’utilisation « Consulter l’historique de traitement d’un rejet »

Sommaire d’identification
Titre : Consulter l’historique de traitement d’un rejet.
But : Consulter à tout moment l’historique relatif à un rejet.
Résumé : Les utilisateurs peuvent consulter les historiques des cas traités ainsi que le
cycle de vie d’un rejet depuis la création de son statut jusqu’à son état actuel.
Acteur: Administrateur des données, l’équipe Billing, l’équipe assainissement, l’équipe
CRM.
Description des enchaînements

Pré conditions :
- L’administrateur des données, l’équipe Billing, l’équipe assainissement et l’équipe
CRM sont authentifiés.
- Il existe au moins un cas de rejet traité dans la base de données.
Enchaînements :
Ce cas d’utilisation commence lorsque l’utilisateur demande au système de consulter
l’historique de traitement d’un cas.

 
97 
 
Partie II Chapitre 3 : Etude du Concept

Enchaînement a : Rechercher un historique.


L’utilisateur a le choix de faire la recherche soit par rejet ou bien par cas, alors il lance
une recherche en choisissant son critère spécifique.
Scénario 1 : par rejet :
Enchaînement b : Rechercher un rejet.
L’utilisateur lance une recherche en choisissant des critères spécifiques.
Si ce rejet recherché n’existe plus, alors exécuter
[exeption1 : rejet inexistant]
Si le rejet existe alors le système affiche le résultat de la recherche demandée.
Scénario 2 : par cas :
Enchaînement c : rechercher un l’historique de traitement par « cas »
L’utilisateur lance une nouvelle recherche en choisissant son cas spécifique.
Si ce cas recherché n’existe plus, alors exécuter
[exeption2 : cas inexistant]
Si le cas existe alors le système affiche le résultat de la recherche demandée.
Enchaînements alternatifs :
Enchaînement d : Afficher une liste.
Si l’utilisateur le souhaite, il peut chercher et afficher la liste soit de tous les rejets, soit de
tous les cas.
Exceptions :
[exeption1 : Rejet inexistant] le système indique que le rejet n’existe pas, et redirige
l’utilisateur vers une nouvelle recherche.
[exeption2 : cas inexistant] le système indique que le cas n’existe pas, et redirige
l’utilisateur vers une nouvelle recherche.
Post conditions :
Post-condition cas de succès :
L’utilisateur aura trouvé sa demande recherchée.
Post-condition cas d’échec :
La recherche indique que les critères demandés ne donnent aucun résultat.

 
98 
 
Partie II Chapitre 3 : Etude du Concept

Choisir le critère
de recherche

Par rejet Par cas

Rechercher un
Rechercher un rejet cas

rejet Afficher la liste des cas


inexistant cas de rejets inexistant

Selectionner un
cas

Consulter
l’historique du
traitement

Figure 38 : Diagramme d’activité du cas d’utilisation « Consulter l’historique de traitement d’un


rejet »

5.2.4. Organisation des cas d’utilisation :

Nous allons organiser les cas d’utilisation de deux façons différentes et complémentaires :

• En ajoutant des relations d’inclusion, d’extension et de généralisation entre les


cas d’utilisation.

• En les regroupant en packages, afin de définir des plans fonctionnels de plus haut
niveau.

5.2.4.1. Relation entre cas d’utilisation :

UML propose trois types de relation standard entre cas d'utilisation : inclusion
<<include>>, extension <<extend>> et généralisation. Les deux premières sont des

 
99 
 
Partie II Chapitre 3 : Etude du Concept

dépendances stéréotypées qui sont représentées par une flèche avec un trait pointillé. Si le
cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.

Dans ce qui suit, nous citerons les différentes relations entre nos cas d’utilisation et
Nous détaillons la description de ces relations en annexe….

a. Relations d’inclusion du cas « Authentification des utilisateurs » :

Figure 39: Relation d’inclusion du cas « Authentification des utilisateurs ».


b. Relation d’inclusion du cas « Définir les sources des rejets » :

Figure 40: Relation d’inclusion du cas « Définir le points de récupération des rejets ».

c. Relation d’inclusion du cas « configurer les règles de classification des rejets ».

 
100 
 
Partie II Chapitre 3 : Etude du Concept

Figure 41 : Relation d’inclusion du cas « Configurer les règles de classification des rejets».

d. Relation d’inclusion du cas « configurer les critères de assignation des rejets ».

Figure 42: Relation d’inclusion du cas « Configurer les règles de classification des rejets».

e. Relation d’inclusion du cas « Changer le statut d’un rejet » :

Figure 43: Relation d’inclusion du cas « changer le statut d’un rejet».


 

f. Relation d’extension du cas « interroger la base de connaissance » :

Figure 44: Relation d’extension du cas « Interroger la base de connaissances».


 

g. Relation d’extension du cas « Catégoriser les rejets » :

Figure 45: Relation d’extension du cas « Catégoriser les rejets ».

h. Relation d’extension du cas « Changer le statut d’un rejet » :

 
101 
 
Partie II Chapitre 3 : Etude du Concept

Figure 46: Relation d’extension du cas « Changer le statut d’un rejet ».

5.2.4.2. Organisation des cas d’utilisation en packages :

Cette étape consiste à délimiter explicitement les différents packages en regroupant les
cas d’utilisation qui représentent un ensemble fortement cohérent dans un même package.

Dans ce qui suit, nous citerons les packages regroupant nos cas d’utilisation. Nous
détaillons la description de ces packages en annexe….

a. Package « Administration » :

 
Figure 47: Diagramme des cas d’utilisation du package « administration du système »

b. Package « Récupération des données » :

 
102 
 
Partie II Chapitre 3 : Etude du Concept

Figure 48: Diagramme des cas d’utilisation du package « Récupération des rejets »

c. Package « Catégorisation des rejets » :

Figure 49: Diagramme des cas d’utilisation du package « Catégorisation des rejets »

d. Package « Traitement d’un rejet » :

 
103 
 
Partie II Chapitre 3 : Etude du Concept

Figure 50: Diagramme des cas d’utilisation du package « Traitement d’un rejet »
e. Package « Remise des rejets » :

Figure 51: Diagramme des cas d’utilisation du package « Remise des rejets ».
 

f. Package « Historique» :

 
104 
 
Partie II Chapitre 3 : Etude du Concept

Figure 52: Diagramme des cas d’utilisation du package « Historique ».

g. Package « Base de connaissance » :

Figure 53: Diagramme des cas d’utilisation du package « Base de connaissance »

 
105 
 
Partie II Chapitre 3 : Etude du Concept

h. Package « rapports et statistiques » :

Figure 54: Diagramme des cas d’utilisation du package « rapports et statistiques »

Le tableau 5 qui suit est un tableau récapitulatif qui résume tout les packages avec les
cas d’utilisation qu’ils contiennent.

Le package Les cas d’utilisation contenants

• Gestion des utilisateurs système


Administration
• Authentification des utilisateurs

• Définir les sources des rejets


Récupération des
• Récupérer les rejets
données

Catégorisation des • Configurer les règles de classification des rejets


rejets • Catégoriser les rejets

• Assigner les rejets

Traitement d’un rejet • Prendre en charge un rejet


• Changer statut d’un rejet
• Retransférer un rejet

Remise des rejets • Remise des rejets corrigés dans la source (recyclage).

Historique • Consulter l’historique de traitement d’un rejet.


• Consulter les informations relatives a un rejet
Base de • Mettre à jour la base de connaissances.
connaissance • Interroger la base de connaissances.

 
106 
 
Partie II Chapitre 3 : Etude du Concept

Rapports et
• Editer les rapports et statistiques.
statistiques

Tableau 4 : Tableau récapitulatif des packages des cas d’utilisation.

5.2.5. Identification des classes candidates :

La rédaction d'une liste de classes candidates a pour but de "dégrossir" un peu le


domaine fonctionnel et d'en faire ressortir les principales notions. Notions qui pourront,
éventuellement, par la suite se concrétiser sous forme de classes. Dans la pratique, les
classes candidates sont obtenues à partir des textes fournis par le client (cahier des charges,
documents techniques…etc.), des connaissances générales du domaine, des entretiens avec
le client, etc. Le but est de répertorier, dans une liste, un maximum de notions. Cette liste
sera ensuite affinée.

5.2.5.1. Les classes candidates du package « Administration» :


Groupe_utilisateur

1 0..*

Avoir
Fait partie
Profil
utilisateur
0..* 1

Figure 55: Diagramme des classes candidates pour le package « Administration »


 

5.2.5.2. Les classes candidates du package « Récupération des rejets » :

Utilisateur Source de rejets


Définie
1 1..*

Figure 56: Diagramme des classes candidates pour le package Récupération des rejets»

 
107 
 
Partie II Chapitre 3 : Etude du Concept

5.2.5.3. Les classes candidates du package « Catégorisation des rejets » :


Catégorie_rejet

0..* 1 appartien
Avoir Rejet
Priorité_rejet
0..*
1

Figure 57: Diagramme des classes candidates pour le package « Catégorisation des rejets»

5.2.5.4. Les classes candidates du package « Traitement des rejets » :

Utilisateur
Etat_rejet
0..*
Modifie 1
Avoir
0..* 0..*
0..* Rejet

fait_partie
0..*
0..*
Modifie 0..* Concerne
1
Entite
Groupe-utilisateur Avoir 1
0..*

1
1 assigner
Catégorie_rejet
1
0..*

Figure 58: Diagramme des classes candidates pour le package « Traitement des rejets»

5.2.5.5. Les classes candidates du package « Historique» :


Etat_rej et

Uti li sateur 0..*


0..*

Avoir Avoir

0..1
0..1
Histori que

0..1
Avoi r 0..1 Avoi r

Rej et
Groupe_uti li sateur
0..* 0..*

Figure 59: Diagramme des classes candidates pour le package « Historique»

 
108 
 
Partie II Chapitre 3 : Etude du Concept

5.2.5.6. Les classes candidates du package « Base de connaissance» :


Question
0..*

1 Contient

1 Priorité_rejet
Base_de_connaissance Connaissance Catégorie_rejet Avoir
A
0..1 0..* 0..* 1

0..*

Réponse

Figure 60: Diagramme des classes candidates pour le package « Base de connaissance»

5.3. Capture des besoins techniques

La capture des besoins techniques couvre, par complémentarité avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des
utilisateurs, ni de la description applicative. Le modèle de spécification logicielle concerne
donc les contraintes techniques. La spécification technique est une activité de la branche
droite du Y ; elle est primordiale pour la conception d’architecture. [UML A, 02].

Abordons quelques notions et définitions.

5.3.1. L’architecture applicative multicouche


Une architecture multicouche (appelée aussi « Architecture n-tiers ») permet de
décomposer le système en sous systèmes. Chaque couche présente l’architecture de
l’application sur un aspect bien précis et peut être modélisée, développée et testée
individuellement. Cette architecture permet de séparer la logique présentation, la logique
applicative et la logique transactionnelle et de persistance (la mise à jour des bases de
données).

Ce type d’architecture peut répondre à des objectifs qualitatifs et quantitatifs


permettant d’atteindre de hauts niveaux de productivité et de réutilisation.

Le modèle d’architecture que nous avons choisi pour notre application est un modèle
en cinq couches qui sont les suivantes : la couche client, présentation, métier, intégration et
données. La figure ci-dessous représente cette architecture en cinq couches.

 
109 
 
Partie II Chapitre 3 : Etude du Concept

Modèle

- Métier

Contrôleur Accès au
données

Métier

- Vue

CoucheClient
Couche Client Couche Couche
Couche Couche
CoucheM
Métier
étier CoucheAcc
Accèsès Couche
CoucheDonn
Données
ées
Présentation
Présentation aux
auxdonn
donnéées
es
 

Figure 61: Architecture en cinq couches.

Nous allons décrire chacune des couches représentées dans la figure ci-dessus en
annexe…

5.3.2. Architecture logique de l’application

• Schéma de l’architecture applicative :

Après avoir défini les cas d’utilisation de la sphère fonctionnelle, il faut spécifier les
différents composants techniques de notre application qui supportent les besoins
fonctionnels, ainsi que les interactions entre ces composants. Le schéma qui suit illustre
notre solution proposée pour l’architecture applicative.

             
Figure 62: Architecture applicative de notre système.

 
110 
 
Partie II Chapitre 3 : Etude du Concept

Dans ce qui suit nous allons décrire chaque partie de l’architecture applicative du
système :

• Noyau applicatif : C’est la partie fonctionnelle de l’application, celle qui implémente la


logique métier décrivant les opérations que l’application opère sur les données en
fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation.
• Couche présentation : Cette couche correspond à la partie de l'application visible et
interactive avec les utilisateurs.
• Couche accès aux données : C’est la partie permettant l’accès et les mises à jours des
différentes sources de données (bases de donnés).
• Base de données EIM et CRM : C’est les bases d’où proviennent les données de notre
système

5.3.3. Spécification technique de point de vu de matériel

Dans cette partie nous allons traiter les contrainte relatives a la configuration du réseau
matériel, ces contraintes peuvent être de nature géographique, organisationnelle et
technique. Elles concernent les performances d’accès aux données, la sécurité du système,
l’interopérabilité, la volumétrie et le mode d’utilisation du système.

5.3.3.1. Les différents Style d’architecture en niveaux :


a.1. Architecture en 2 niveaux « 2 tiers » :
Une architecture 2-tiers est composée de deux éléments, un client et un serveur et où le
tiers fait référence non pas à une entité physique mais logique, et que l'on peut représenter
via le simple schéma suivant :

Figure 63: Schéma représentant une architecture 2-tiers

 
111 
 
Partie II Chapitre 3 : Etude du Concept

C'est parce que le client assume des tâches de présentation et de processing, et donc de
fait communique avec le serveur sans intervention d'un autre processus que le client est dit
"lourd" par opposition à l'architecture 3-tiers où le client est constitué d'un simple navigateur
internet et communique avec le serveur via un frontal.

En définitive et dans la perspective d'une architecture 2-tiers avec un serveur de base


de données (SGBD) le schéma précédent sera plus exactement le suivant :

Figure 64: Schéma d’une architecture 2-tiers avec un serveur de base de données

Nous citerons les avantages et inconvénients de cette architecture 2-tiers en annexe.

a.2 Architecture en 3 niveaux« 3 tiers » :


L'architecture 3-tiers est composée de trois éléments, ou plus précisément dans ce
cadre là de trois couches. En effet dans ce contexte, et dans la philosophie qui a guidé
l'élaboration de cette architecture, il est plus adéquat de parler de couche fonctionnelle où à
chacune d'elle est attachée un élément/entité logique.
Hors donc dans le modèle 3-tiers il faut distinguer trois couches/éléments :
1. La couche présentation (ou affichage si l'on souhaite) associée au client qui de fait
est dit "léger" dans la mesure où il n'assume aucune fonction de traitement à la
différence du modèle 2-tiers.
2. La couche fonctionnelle liée au serveur, qui dans de nombreux cas est un serveur
Web muni d'extensions applicatives.
3. La couche de données liée au serveur de base de données (SGBD).

Le schéma suivant résume la structure générique d'une architecture 3-tiers, qui s'entend
ici hors serveur Web.

 
112 
 
Partie II Chapitre 3 : Etude du Concept

Figure 65: Schéma d’une architecture 2-tiers

Enfin le schéma ci-après suivant illustre une architecture avec un serveur Web.

Figure 66:Schéma d’une architecture 3-tiers avec serveur web

D'un point de vue général quelques points importants sont à souligner pour
l'architecture 3-tiers :
1. Client : ce tiers est responsable de la présentation des données, de la réception des
événements d'utilisateur et du contrôle de l'interface utilisateur.

2. Server d’application : ce tiers est responsable d’héberger les objets métiers et sont
disponibles pour le tiers client. Cela protège les données de l'accès direct par les
clients.

3. Server de base de données : Ce tiers est responsable du stockage des données.

Nous citerons les avantages et inconvénients de cette architecture 3-tiers en annexe.


 

5.3.3.2. Choix de l’architecture :


Après avoir fait la comparaison entre les deux architectures et selon notre besoin, notre
choix s’oriente vers la première solution qui est l’architecture 2-tiers. Elle représente la
solution la plus adaptée à notre système car elle nous permet d'atteindre la qualité requise
des caractéristiques de notre projet.

 
113 
 
Partie II Chapitre 3 : Etude du Concept

5.3.4. Élaboration du modèle de spécification logicielle


Après que les spécifications techniques et architecturales soient exprimées, on
s’intéresse aux fonctionnalités propres du système technique et cela, en procédant à une
spécification logicielle. On utilisera les cas d’utilisation comme lors de la description des
aspects fonctionnels de notre système, cependant des petites différences sont à signaler :

Nous présentons ici ces différences en introduisant le concept d’exploitant et de cas


d’utilisation technique.

Š Exploitant : C’est un acteur au sens UML, si ce n’est qu’il ne bénéficie que des
fonctionnalités techniques du système. [UML A, 03]
Š Cas d’utilisation technique : Il est destiné à l’exploitant. C’est une suite d’actions
produisant une valeur ajoutée opérationnelle ou purement technique. [UML A, 03]

5.3.4.1. Identification des cas d’utilisation techniques

Les exploitants du notre système sont les suivants :

Š L’utilisateur : qui utilise une des applications du système. La majorité des acteurs de la
branche fonctionnelle sont donc des utilisateurs dans la dimension technique.
Š Administrateur du système: qui est chargé de déployer et de dépanner le système.

Les cas d’utilisation techniques : les cas d’utilisation sont identifiés en considérant
l’attente opérationnelle de chaque exploitant :

‚ Manipulation des objets : l’utilisateur va manipuler des entités sous formes d’objets,
ce qui implique la mise en œuvre des mécanismes de persistance et de gestion de cycle
de vie des objets.
‚ Gérer l’intégrité : plusieurs utilisateurs peuvent travailler en parallèle, l’intégrité est le
mécanisme qui empêche la mise à jour simultanée d’une même entité par deux
utilisateurs différents.
‚ Consulter l’aide : chaque utilisateur doit disposer d’une aide contextuelle qui l’aide à
exploiter le système de la manière la plus facile.
‚ Gérer la sécurité : l’ingénieur d’exploitation ainsi qui les utilisateurs sont soumis à des
règles de sécurité. Dans un système/client serveur ces aspects recouvrent l’authenticité,
l’habilitation, le cryptage, la non répudiation et l’audit.

 
114 
 
Partie II Chapitre 3 : Etude du Concept

‚ Gérer les erreurs : le système doit être exploitable, à ce titre, il faut qu’il soit en
mesure de générer des traces et des alertes qui vont faciliter sa maintenance au sein du
système informatique global de l’entreprise. C’est cette analyse technique du problème
qui permet d’introduire l’ingénieur d’exploitation comme autre exploitant.

Figure 67. Modèle de spécification logicielle du système.

5.3.4.2. Spécification d’architecture et influence sur le modèle de déploiement

Un diagramme de déploiement décrit la disposition physique des ressources


matérielles qui composent le système. Chaque ressource étant matérialisée par un nœud, le
diagramme de déploiement précise quelles sont les connexions entre les nœuds. Ces
associations entre nœuds sont des chemins de communication qui permettent l’échange
d’informations.

La spécification d’une architecture à composants métier 2-tiers implique des


contraintes sur le modèle d’exploitation. Une solution client/serveur 2-tiers entraîne en effet
la répartition des composants d’exploitation suivant les responsabilités :

 
115 
 
Partie II Chapitre 3 : Etude du Concept

Figure 68: Diagramme de déploiement.

5.4. Découpage en catégorie

Le découpage en catégorie constitue la première activité de l’étape d’analyse. Il se


situe sur le branche gauche du cycle en Y et succède à la capture des besoins fonctionnels.
Cette étape est une étude plus affinée du découpage fonctionnel induit des cas d’utilisations
en package avec ses classes candidates .en effet, on s’inspire du résultat obtenu
précédemment en tenant compte de deux principes fondamentaux qui sont : cohérence et
indépendance. La figure80 qui suit illustre le découpage en catégorie avec leurs
dépendances.

     
Figure 69: Diagramme représentant le découpage en catégories

 
116 
 
Partie II Chapitre 3 : Etude du Concept

5.5. Développement du modèle statique


Le développement du modèle statique constitue la deuxième activé de l’étape
d’analyse. Nous allons dans ce qui suit décrire toutes les classes objets et association ainsi
que leurs attributs. Au niveau des types d’attributs nous retrouvons les acronymes suivants :

- N(x) pour Numérique de longueur maximum x ;


- AN(x) pour Alphanumérique de longueur maximum x ;

Classe Description Attributs Description Type


Id_rejet Identifiant du rejet N(5)
Customer_id Identifiant du client N(9)
Contract_id Identifiant du contrat N(9)
Service_id Identifiant du service N(4)
Parameter_id Identifiant du paramètre N(4)
Rejet Classe des Date_insertion Date insertion Date
Rejet Date_recyclage Date de recyclage Date
Le Nombre de
Retraitement N (2)
retraitement du rejet.
Retr_date Date de retraitement Date
Commentaire Commentaire sur le rejet AN(200)
Identifiant de l’état du
ID_état N(2)
rejet
Etat_rejet Classe des états des
Nom_etat Nom de létat N(20)
rejets
Description de l’état du
Desc_etat AN(100)
rejet
Identifiant de la
Classe des ID_Catégorie N(2)
Catégorie_rejet catégorie du rejet
catégories des
Description de la
rejets DES_Catégorie AN(100)
catégorie du rejet

Id_priorité Identifiant de la priorité. N(2)


Classe des
Priorité_rejet Description de la
Priorité_rejet Desc_priorité priorité. AN(100)

 
117 
 
Partie II Chapitre 3 : Etude du Concept

Classe de la source Id_source Identifiant de la source. N(1)


Source_rejet
de rejet Desc_source Description de la source. AN(100)

ID_Entité Identifiant de l’entité AN(15)


Entité Classe des entités
DES_Entité Description du l’entité AN(100)
Type_catég Type de catégorisation AN(1)
Mode de Classe des modes
Description du type de
catégorisation de catégorisation Desc_type_catég AN(100)
catégorisation
Identifiant de
id_utilis N(4)
l’utilisateur du système
pseudo Pseudo de l’utilisateur AN(25)
Nom de l’utilisateur du
nom_utilis AN(25)
système

Utilisateur prenom_utilis Prénom de l’utilisateur AN(25)


Classe des
Numéro de téléphone de
utilisateurs du tel_utilis N(13)
l’utilisateur
système
Poste de travail de
poste_utilis AN(25)
l’utilisateur

Email_utilis Email de l’utilisateur AN(40)

Note_utilis Note sur l’utilisateur AN(100)


Mot de passe de
Mdp_ utilis AN(25)
l’utilisateur
Identifiant du groupe
id_gpe N(3)
d’utilisateurs

Groupe_utilis Classe des groupes nom_gpe Nom du groupe AN(25)


d’utilisateurs Description du groupe
des_gpe AN(100)
d’utilisateurs

Id_profil Identifiant du profil N(1)

Nom_profil Description du profil AN(25)


Classe des profils AN(100)
Profil_utilis
d’utilisateurs
Desc_profil Description du profil

 
118 
 
Partie II Chapitre 3 : Etude du Concept

Id_article Identifiant de l’article N(4)


Base_de_ Classe de la base de Descr_article
Description de l’article AN(50)
connaissance connaissance

ID_question Identifiant de la question N(4)

Description de la
Desc_Question AN(100)
Classe de la base de question

connaissance Date d’ajout de la


Question Date_ajout_ques Date
question
Date de modification de
Date_mod_ques Date
la question

Id_rép Identifiant de la réponse N(4)

Description de la
Desc-rep AN(100)
Classe de la base de réponse
Réponse Date d’ajout de la
connaissance Date_ajout_rep Date
réponse
Date de modification de
Date_modif_rep Date
la réponse.

Tableau 5: Liste des classes objet.

Liste des classes associations

Classe Description Attributs Description Type

Classe d’association entre les classes ID_rejet Identifiant du rejet N(5)


rejet: etat_rejet : utilisateur et
ID_utilis Identifiant du user N(4)
grp_utlisateur. Elle contient la date
Historique du changement d’état du rejet et id_gpe Identifiant du groupe N(3)
nous permet de savoir qui des
ID_état Identifiant de l’état N(2)
utilisateurs qui appartiennent à tel
groupe ont modifié tel rejet pour lui Date_chgt Date de changement Date
donner tel état ainsi qu’une note sur
Commentaire sur le
le traitement effectué Mémo AN(100)
traitement

Tableau 6: Liste des classes associations.

 
119 
 
Partie II Chapitre 3 : Etude du Concept

Priorité_rejet
- Id_priorité
- Desc_priorité
question Catégorie_rejet + Creer ()
Base_de_connaissa a 1
- Id_quest : - Id_catégorie + Consulter ()
- Desc_quest : - Id_base : Nu - Desc_catégorie 0..* + Modifier ()
- Cause_rejet : ch 0..* Rejet
- Date_ajout : Avoir 1 1 + Supprimer ()
- Solution : ch + Creer ()
- Date_mod : 0..* - ID_rejet
1 Connaissance + Consulter ()
+ Creer () - Customer_Id
+ creer () + Modifier ()
+ consulter () - Contract_Id
+ consulter () + Supprimer () appartien
- Service_Id
+ modifier ()
+ supprimer () 0..* 0..* - Parameter_id Entité
- Date_insertion
- Id_entite
1 - Date_recyclage
- descrip_entite
- Retry 0..*
- retry_date + Creer ()
Etat_rejet Concerne 1..1 + Consulter ()
Concerne - commentaire
- ID_état : N + Modifier ()
+ Creer ()
Affecté 0..* + Supprimer ()
- Desc_état : c 1..1 + Consulter ()
0..* - Nom_état : c a + modifier () 0..*
+ Creer () + classifier ()
Réponse + Consulter () + changer_etat ()
- Id_réponse : + modifier () + assigner ()
0..* + supprimer ()
- Desc_rep : 0..*
- Date_ajout : Groupe utilisateur 0..1 a
- Date_modif :
- Id_groupe : Number 0..1
+ creer () : - nom_groupe : char 1..1
+ consulter () : - Desc_groupe : char
Profil Mode_catégorisatio
+ modifier () :
+ supprimer () : + Creer () 0..1 Avoir Avoir
- Id_profil : - Type_catégo
- Desc_profil : 1 * + Consulter ()
- Desc_type_catég
+ Modifier ()
+ Creer () a_comme_profil + Supprimer () + conslter() () : in
+ Consulter () Avoir + modifier() () : in
+ Ajouter_drt_a_grp ()
+ Modifier () 0..* Contient
+ select_drt_pr_grp ()
+ Supprimer () 0..*
+ supprimer_drt_grp ()
0..*
Historique
- Date_MAJ :
1..1 - mémo :

Utilisateur
0..*
- Id_utlisateur
Appartien - Pseudo Avoir
- Nom_utilisateur 1
- Prenom_utilisateur Source_de_rejets
- Tel_utilisateur
- Poste_utilisateur 0..1 - Id_Source
- Email_utilisateur - Desc_Source
- note_utilisateur + Creer ()
0..*
- Mdp_utilisateur + Consulter ()
+ Creer () + Modifier ()
+ Consulter () + Supprimer ()
+ Modifier ()
+ Changer_pwd ()
+ Supprimer ()
+ Select_utili_by_grp

Figure 70: Diagramme des classes.

 
120 
 
Partie II Chapitre 3 : Etude du Concept

5.6. Développement du modèle dynamique :


Le développement du modèle dynamique nous permettra d’illustrer l’utilisation des
concepts dynamiques d’UML, qui nous conduisons à la description des scénarios mettant en
jeu un ensemble d’objets échangeant des messages. Ensuite nous détaillerons les cycles de
vie des objets d’une classe au fil de ses interactions et de son évolution propre.

5.6.1 Analyse des états :

L’analyse des états s’intéresse particulièrement aux changements des états des objets
durant leur cycle de vie. Cette technique est nécessaire pour décrire les comportements
dynamiques du système. Pour modéliser ces changements d'états on utilise les diagrammes
d’états-transitions.

Nous allons dans ce qui suit vous présenter les différents états des objets dynamiques
de notre système, le détail de la description de ces derniers se trouve en annexe….

• Objet « Rejet» :

Pour l’objet « rejet » nous allons décrire les états de ce dernier par rapport à notre
système de monitoring et ses états dans les autres systèmes (DBL).

La figure suivante montre les différents états des rejets :

Figure 71 : les états possibles des rejets dans le système DBL et monitoring.

 
121 
 
Partie II Chapitre 3 : Etude du Concept

Les états d’un rejet dans notre système changent selon les étapes de traitement de ce
dernier, les différents états sont décrits dans le schéma suivant:

Figure 72: Diagramme d’états-transitions de l’entité « Rejet ».


 

5.6.2.Identification des scénarios:

Nous allons déterminer des cas d’utilisation les scénarios qui les composent. Un
scénario représente une séquence d’interactions entre le système et ses acteurs. Le système
étant considéré comme une boite noire. Maintenant que nous avons développé le modèle
statique, nous allons représenter le système par une collaboration d’objets dans chaque
scénario, Dans ce qui suit Nous allons détailler les principaux scénarios de notre système,
les autres seront décrits en annexe…

5.6.2.1.Cas d’utilisation « Catégorisation des rejets » :

¾ Scénario « Catégoriser les rejets» :

Figure 73 : Diagramme de séquence du scénario « Catégoriser les rejets ».


 

¾ Scénario « Ajouter une Catégorie rejet» :

 
122 
 
Partie II Chapitre 3 : Etude du Concept

Figure 74 : Diagramme de séquence du scénario « Ajouter une catégorie rejet».


 

5.6.2.2.Cas d’utilisation « Traitement des rejets » :

¾ Scénario « Assigner les rejets» :

Figure 75 : Diagramme de séquence du scénario « Assigner les rejets ».

¾ Scénario « Prendre en charge un rejet» :

 
123 
 
Partie II Chapitre 3 : Etude du Concept

 
Figure 76 : Diagramme de séquence du scénario « Prendre en charge un rejets ».

5.6.2.3.Cas d’utilisation « Consulter l’historique de traitement d’un rejet » :

Figure 77: Diagramme de séquence du scénario «Consulter l’historique de traitement d’un


rejet ».
5.6.2.4.Cas d’utilisation «Remise des rejets » :

 
124 
 
Partie II Chapitre 3 : Etude du Concept

Figure 78: Diagramme de séquence du scénario « Remise des rejets ».


 

5.6.2.5.Cas d’utilisation «Consulter Base de connaissance» :

Figure 79: Diagramme de séquence du scénario « Consulter base de connaissance».

5.6.2.6.Cas d’utilisation « Gestion des utilisateurs système » :

 
125 
 
Partie II Chapitre 3 : Etude du Concept

¾ Scénario « changement d’affectation de groupe d’un utilisateur » :

Figure 80: Diagramme de séquence du scénario « Changement d’affectation de groupe d’un


utilisateur ».

¾ Scénario « Authentification de l’utilisateur» :

Figure 81: Diagramme de séquence du scénario « Authentification de l’utilisateur ».

5.7. Conception générique

 
126 
 
Partie II Chapitre 3 : Etude du Concept

La conception générique est une activité de la branche technique (droite). Elle consiste
à développer la solution qui répond aux satisfactions techniques vues précédemment. Cette
conception est qualifiée de générique car elle est entièrement indépendante des aspects
fonctionnels. La conception technique constitue le niveau d’abstraction à atteindre et les
points de vue développés sont les suivants :

• Point de vue logique qui détaille les classes de la solution.


• Point de vue d’exploitation, car les premiers composants d’exploitation du système
sont conçus à ce niveau.
• Point de vue de configuration logicielle, qui trace les classes et les versions nécessaires
pour mettre en œuvre le système.

Framework technique : Est un réseau de classes qui collaborent à la réalisation d’une


responsabilité qui dépasse celle de chacune des classes qui y participent. [UML A, 02]

Interface : Une interface est une classe de stéréotype « interface ».qui ne peut ni définir
d’attributs, ni définir d’associations navigables vers d’autres classes. [UML A, 02]

5.7.1. Organisation des Framework technique

L’organisation du modèle logique reprend les couches logicielles. A chaque couche


correspond à un Framework technique qui définit des responsabilités logicielles :

• Le noyau présentation définit les classes, les interfaces et les mécanismes de base
pour réaliser l’affichage d’un objet.
• Le noyau application définit ces mêmes éléments pour rafraîchir les vues, charger les
modèles de fonctionnement et contrôler les commandes d’une application.
• Le noyau métier définit les éléments permettant d’identifier les objets métiers et de
définir leurs attributs et leurs caractéristiques.
• Le noyau d’accès aux données définit les mécanismes de chargement, de sauvegarde
de mise à jour et de recherche des objets persistants.
• Le noyau sécurité qui définit les mécanismes d’authentification.

 
127 
 
Partie II Chapitre 3 : Etude du Concept

Figure 82: Organisation du modèle logique

5.7.2. Description des noyaux :

a. Noyau présentation :
Nous avons opté pour des interfaces graphiques. Chacune des interfaces est
représentée par des formulaires d’affichage, des tables, des menus. C’est la partie visible à
l’utilisateur du système.

b. Noyau Applicatif :

C’est la partie invisible à l’utilisateur. Elle regroupe les interfaces, les scriptes qui
exécutent certaines actions ou commandes et communique avec le noyau métier.

c. Noyau Sécurité :

Le noyau sécurité définit les stratégies de contrôle et d'authentification afin de protéger


le système. La sécurité est composée de deux niveaux :

• L'aspect sécuritaire du côté du système de gestion de base de données (SGBDR)


chaque utilisateur ouvre le droit d'accès à certaines ressources du système par le biais
de la définition de privilèges pour chacun des utilisateurs.

 
128 
 
Partie II Chapitre 3 : Etude du Concept

• L'aspect sécuritaire du côté applicatif : pour définir un système d'information sécurisé.


Les concepts suivant sont souvent utilisés:
9 L'authentification: pour accéder au système chaque personne doit s’authentifier à
l’aide d’un mot de passe et d’un nom d’utilisateur antérieurement attribué par
l’administrateur.
9 La disponibilité: les données ainsi que les ressources du système d'information
sont accessibles par ceux qui en ont besoin.
9 L'intégrité: l'information ne peut être modifiée que par la personne qui en a le
droit, et ce, de façon volontaire.
9 Le contrôle d'accès: une ressource n'est accessible que par les personnes
autorisées.

Mettre au point une politique de sécurité va donc consister à faire respecter ces règles.
L'utilisation de toute ressource du réseau doit se faire de façon à :

• Empêcher à une personne non autorisée d'utiliser certaines ressources.


• Identifier les auteurs de malveillances ou de maladresses.

d. Noyau accès aux données :

Le noyau accès aux données défini les accès aux différentes sources de données. Il
permet l’ajout des sources de données et mieux gérées l’accès à ces multiples sources.

5.8. Conception préliminaire

La conception préliminaire représente une étape délicate car elle intègre le modèle
d’analyse dans l’architecture technique de manière à tracer la cartographie des composants
du système à développer.

Lors de cette étape, les classes sont regroupées en frameworks pour remplir des
fonctions techniques spécifiques. Les frameworks constituent éventuellement des
composants du modèle d’exploitation et participent au modèle de configuration logicielle.

5.8.1. Développement du modèle de déploiement

Le premier niveau de conception d’un système est son déploiement. Le déploiement,


c’est l’organisation des environnements de travail sur un réseau. La solution adoptée dans
cette étape est l’architecture 2-tiers : l’application est installée dans tous les postes de travail

 
129 
 
Partie II Chapitre 3 : Etude du Concept

qui effectue les différents traitements métiers, ce dernier puise ses données à partir d’un
serveur de données.

SE: WindowsXP Poste : Administrateur


CPU : 2.8 Ghz
RAM : 1 Go
Disque: 80 Go
Client oracle : 10g
SE: WindowsXP
CPU : 2.8 Ghz
RAM : 1 Go
Disque: 80 Go
Client oracle : 10g
Poste : Administrateur
SE : Windows Server de données
2003t
CPU : 2.8 Ghz
Disque: 280 Go
héberge : Oracle 10g Commutateur

Serveur de base de données SE: WindowsXP


CPU : 2.8 Ghz
RAM : 1 Go
Disque: 80 Go
Client oracle : 10g

.
. Postes : Utilisateurs
.

Figure 83 : modèle de déploiement

5.9. Conception détaillée


La conception détaillée est la phase ultime de la modélisation qui consiste à construire
et à documenter précisément les classes, les tables et les méthodes qui constituent le codage
de la solution.

5.9.1. Affinage des classes et extraction des méthodes :


Classe Rubrique Désignation Type Taille
Id_rejet identifiant du rejet. AN 5
rejet

Customer_id Identifiant du client. AN 9


Contract_id Identifiant du contrat. AN 9
Service_id Identifiant du service. AN 4
Parameter_id Identifiant du paramètre. AN 4
Date_insertion Date insertion. D
Date_recyclage Date de recyclage. D
retry Nombre de fois de traitement. N 2
retry_date Date de traitement. D
commentaire Commentaire sur le rejet. AN 200

Id_état Identifiant de l’état du rejet. AN 2


Etat_ rejet

Nom_état Nom de l’état AN 20


Desc_etat Description de l’état. AN 100

 
130 
 
Partie II Chapitre 3 : Etude du Concept

Id_Catégorie Identifiant de la catégorie. N 2


Catérorie_ Désc_catégorie Description de la catégorie. AN 100
rejet

Id_priorité Identifiant de la priorité. N 2


Desc_priorité Description de la priorité. AN 100
Priorité_
rejet

Id_source Identifiant de la source. AN 2


Source_
rejet

Desc_source Description de la source. AN 100

Type_catég Type de catégorisation AN 1


catégorisation
Mode_

Desc_type_catég Description du type de catégorisation AN 100

Id_Entité Identifiant de l’entité. AN 15


Entité

Desc_entité Description de l’entité. AN 100

Id_utilis Identifiant de l’utilisateur. N 3


Utilisateur

Pseudo Pseudo de l’utilisateur. AN 20


Nom_utilis nom de l’utilisateur. AN 20
Pnom_utilis Prénom de l’utilisateur. AN 20
Tel_utilis Téléphone de l’utilisateur. N 20
Poste_ utilis Fonction de l’utilisateur. AN 35
Email_ utilis Email principale. AN 40
Note_ utilis Note sur l’utilisateur. AN 100
Mdp_ utilis Mot de passe de l’utilisateur. AN 20
Id_grp Identifiant du groupe d’utilisateurs. N 3
Groupe_

Nom_grp Nom du groupe. A 20


Desc_grp Description du groupe. AN 100
utilis

Id_profil Identifiant du profil. N 1


Utilis
Profile_

Nom_profil Nom du profil AN 25


Desc_profil Description profil. A 100

 
131 
 
Partie II Chapitre 3 : Etude du Concept

Id_rejet identifiant du rejet. N 5


Historique Id_état identifiant de l’état du rejet. N 2
Id_user identifiant de l’utilisateur. N 3
Id_grp identifiant du groupe d’utilisateur. N 3
Date_Chgt Date du changement D
Mémo Commentaire sur le traitement AN 200

Id_article Identifiant de la base AN 10


connaissances
Basede_

Desc_article Description de l’article AN 30

Id_quest Identifiant de la question AN 10


Questions

Desc_quest Description de la question AN 30


Date_ajout_questi Date d’ajout de la question D
Date_modif_quest Date de modification de la question D

Id_Rep Identifiant de la réponse. AN 10


Réponses

Desc_rep Description de la réponse. AN 30


Date_ajout_rep Date d’ajout de la réponse. D
Date_modif_rep Date de modification de la réponse. D

Tableau 7: Liste affinée des classes Objet.

5.9.2. Description des méthodes :


Le développement du modèle dynamique nous a permis de déceler les méthodes qui
seront ajoutées aux classes et qui serviront à l’implémentation. Le tableau ci-après reporte la
description de ces méthodes.

Classe Méthode Désignation

findREJECT( ) Chercher un rejet.


updateREJECT( ) Modifier un rejet.
findInfoREJECT( ) Consulter les informations d’un rejet.

Rejet categorizeREJECT( ) Catégoriser un rejet.


assignREJECT( ) Assigner un rejet.
changestatusREJECT( ) Changer statut d’un rejet.
SelectREJECTByGrp( ) Sélectionner les rejets par groupes.
SelectREJECTByUser( ) Sélectionner les rejets par utilisateur.
findSTATUS( ) Chercher un statut.

Etat_rejet insertSTATUS ( ) Insérer un statut


updateSTATUS( ) Modifier un statut.

 
132 
 
Partie II Chapitre 3 : Etude du Concept

findInfoSTATUS( ) Consulter les informations d’un statut.


GetprioritySTATUS( ) Donner une priorité a un statut de rejets.
findCATEGORY( ) Chercher une catégorie.
insertCATEGORY ( ) Insérer une catégorie.
Catérorie_rejet updateCATEGORY ( ) Modifier une catégorie.
findInfoCATEGORY ( ) Consulter les informations d’une catégorie
assignCATEGORYtousergrp( ). Assigner une catégorie a un groupe d’utilisateur.
findSOURCEReject( ) Chercher la source de rejet.
Source_rejet
findInfoSOURCEReject ( ) Consulter les informations d’une source de rejet.
insert PRIORITY ( ) Insérer une priorité.
Priorité_rejet
deleteCATEGORY ( ) Supprimer une priorité
insertENTITY( ) Insérer une entité.
Entité updateENTITY( ) Modifier une entité.
findInfoENTITY( ) Consulter les informations d’une entité.
findUSERbyNOM( ) Chercher un utilisateur par nom
insertUSER( ) Insérer un utilisateur
updateUSER( ) Modifier un utilisateur
changePWD( ) Changer le mot de passe d’un utilisateur.
Utilisateur
GetProfilUSER( ) Donner un profil a un utilisateur.
deleteUSER( ) Supprimer un utilisateur
changegrpUSER( ) Changer le groupe d’un utilisateur.
selectUSERbyGPE( ) Sélectionner les utilisateurs par groupe
findGPE( ) Chercher un groupe d’utilisateur.
findInfoGPE( ) Trouver info groupe.
insertGPE( ) Insérer un groupe d’utilisateur.
Groupe_util deleteGPE( ) Supprimer un groupe d’utilisateur.
selectDRTofGPE( ) Sélectionner droit d’un groupe.
ajoutDRTtoGPE( ) Ajouter droit d’un groupe.
suppDRTfromGPE( ) Supprimer droit d’un groupe.
findProfilUSer( ) Chercher un profil d’utilisateur.
insertProfilUSer ( ) Insérer un profil d’utilisateur.
Profil_utilisateur
findInfoProfilUSer ( ) Consulter les informations profil d’utilisateur.
deleteProfilUSer ( ) Supprimer droit d’un profil d’utilisateur.
findITEM ( ) Chercher un article.
Base_de_ insert ITEM( ) Insérer un article.
connaissances
findInfoITEM ( ) Consulter les informations d’un article.
insertQUESTION( ) Insérer une question.

Questions findInfoQUESTION( ) Consulter les informations d’une question.


updateQUESTION( ) Modifier une question.

 
133 
 
Partie II Chapitre 3 : Etude du Concept

deleteQUESTION( ) Supprimer une question.


assignQUESTIONtoitem( ). Assigner une question a un article.
insert ANSWER( ) Insérer une réponse.
findInfoANSWER( ) Consulter les informations d’une réponse.

Réponses updateANSWER( ) Modifier une réponse.


delete ANSWER( ) Supprimer une réponse.
assignANSWERtoquestion( ). Assigner une réponse a une question.
findHistoRejet Consulter l’historique de traitement des rejets
findHistoRejetbyGrp Consulter l’historique de traitement par groupe
Historique
findHistoRejetbyUtil Consulter l’historique de traitement par utilisa.
findHistoRejetbyReject Consulter l’historique de traitement par rejet.

Tableau 8 : Description des méthodes.


 

5.9.3. Passage au modèle relationnel :


Le modèle relationnel est basé sur une organisation des données sous forme de tables.
Les attributs correspondent aux colonnes des tables.

Pour traduire un diagramme des classes vers le modèle relationnel, on peut appliquer
les règles résumées dans le tableau suivant:

Modèle objet Modèle relationnel

Classe Table

Attribut de type simple Colonne

Attribut de type complexe Colonnes ou clé étrangère

Association Clé étrangère ou table de liens

Héritage Clé primaire identique sur plusieurs tables

Tableau 9: Légende des objets.

Dans ce qui suit, nous présentons les tables de notre modèle relationnel. Les clés
primaires sont les premiers attributs soulignés et les clés étrangères sont les derniers attributs
soulignés et italique.

• Rejet (Id_rejet, Customer_id, Contract_id, Service_id, parameter_id, Date_insertion,


Date_recyclage, retraitement, retrait_date, commentaire, Id_état, Id_Catégorie,
id_source, Id_Entite, Type_catég).
• Etat_rejet ( Id_etat, nom_etat, desc_etat).

 
134 
 
Partie II Chapitre 3 : Etude du Concept

• Catérorie_rejet (Id_Catég, nom_categ, Desc_catég, Id_priorité).


• Priorité_rejet (Id priorité, Desc_priorité).
• Source_rejet (Id_source, Desc_source).
• Mode_catégorisation ( Type_catég, Desc_type_catég)

• Entité (Id_Entité, Desc_entité).

• Base_de_connaissances (Id_article, Desc_article, Id_Catég).


• Question (Id_quest, Desc_quest, Date_ajout_questi, Date_modif_quest, Id_article).
• Réponse (Id_Rep, Desc_rep, Date_ajout_rep, Date_modif_rep, Id_quest).
• Utilisateur (Id_util, Pseudo, Nom_util, Pnom_ util, Tel_ util, Poste_ util, Email_ util,
Note_ util, pwd, Id_grp, Id_pfl ) .

• Groupe_utilis (Id_grp, Nom_grp, Desc_grp).


• Profil_utilis (Id_pfl, nom_pfl, Desc_pfl).
• Historique (Id rejet, Id_etat, Id_util, Id_grp, Date_de_changement, Mémo).

• Assignation (Id_Catégorie, Id_grp).

6. Conclusion :
Dans ce chapitre, nous avons commencé par définir l’outil de conception et la méthode
choisie, expliquer la démarche, et les différentes étapes à suivre dans notre conception qui a
été faite avec la démarche 2TUP en utilisant comme principe le modèle UML.

Nous avons présenté ensuite l’architecture du principe de la solution proposée, notre


solution est divisée en trois partie essentielles qui sont : la récupération des rejets, traitement
des rejets et remise des rejets corrigé à la source.

Et enfin, nous avons suivie la démarche 2TUP pour la conception de notre solution
avec tout ce qu’elle a comme étapes commençant par l’étude préliminaire et terminant par la
conception détaillée

Dans le chapitre suivant, nous aborderons le déploiement du système qui consiste à


spécifier la disposition physique de notre système décisionnel à savoir les logiciels utilisés et
la sécurité de notre système.

 
135 
 
 

PARTIE II :
 

 
CHAPITRE 4 :
 

IMPLEMENTATION ET S ECURITE DU SYSTEME 
 

 
Partie II Chapitre 4: Implémentation et Sécurité du système

1. Implémentation :
La phase d’implémentation donne une description technique détaillée du système
conçu. Elle permet de décrire les outils choisis pour la mise en œuvre de la solution et la
réalisation des services définis pour chaque couche logicielle

Dans cette étape, nous décrivons l’environnement technique du nouveau système, à


savoir :

• Outils de développement.
• environnement de travail.
• Système de Gestion de Base de Données (SGBD).

1.1. Outils de développement :


1.1.1. Langage de programmation :

Pour notre projet, le choix du langage de programmation s’est porté sur JAVA orienté
objet qui a la particularité principale d'être portable sur plusieurs systèmes d’exploitation.
C'est la plateforme qui garantit la portabilité des applications développées en Java. Ce choix
s’est fait du fait que java soit un langage distribué, fiable, orienté objet, sécurisé, et dont
l’API est très riche. La raison principale reste sa portabilité. En effet, ce langage est une
bibliothèque d'exécution qui se veut indépendante de la plateforme: il est possible d'utiliser
le même code sur plusieurs systèmes d'exploitation différents (Windows 95/98/XP/NT,
Solaris, UNIX, etc.)

1.1.2. Environnement de travail :

L’environnement de travail choisi est « Eclipse 3.1 » développé par IBM puis rendu
open source. Son évolution est maintenant gérée par la fondation Eclipse. Eclipse est un
environnement de développement intégré dont le but est de fournir une plate-forme
modulaire pour permettre de réaliser des développements informatiques.

1.1.3. Système de Gestion de Base de Données (SGBD) :

Pour l’implémentation de la couche stockage des données, le système de gestion de base


de données Oracle 10g.

 
137 
 
Partie II Chapitre 4: Implémentation et Sécurité du système

Oracle est un SGBD (système de gestion de bases de données) édité par la société du
même nom (Oracle Corporation), leader mondial des bases de données.

Oracle est fourni avec de nombreux outils permettant de simplifier l'administration de


la base de données. Parmi ces outils, les plus connus sont : Oracle Manager (SQL*DBA),
NetWork Manager, Oracle Enterprise Manager, Import/Export : un outil permettant
d'échanger des données entre deux bases Oracle.

Le choix de ce SGBD est justifié par le fait qu’il permet d'assurer : la définition, la
cohérence, la confidentialité et la manipulation des données, ainsi la sauvegarde et la
restauration des données. Ce SGBD assure aussi la gestion des accès concurrents. D’autre
part, si l'on monte à de plus importants volumes de donnée (>200Go) et un grand nombre
d'utilisateurs (>300), les écarts de performance entre Oracle et les autres SGBD seront très
visibles.

1.1.4. Environnement de développement :

Notre application est développée en respectant la norme J2SE et le Kit de


développement Java JDK 1.5, cette norme est définie dans ce qui suit :

• Définition de J2SE :
J2SE (Java 2 Standard Edition) est le framework Java destiné aux applications pour
poste de travail. Ce framework contient toutes les API de base, mais également toutes les
API spécialisées dans le poste client (JFC et donc Swing, AWT et Java2D), ainsi que des
API d'usage général comme JAXP (pour le parsing XML) et JDBC (pour la gestion des
bases de données). [WIK*]

Dans la mesure où J2SE s'appuie entièrement sur le Java, il bénéficie des avantages et
inconvénients de ce langage, en particulier une bonne portabilité et une maintenance du
code.

2. La sécurité informatique :
La sécurité informatique est un domaine d’étude à lui seul, il est d’une importance
capitale. En particuliers, les entreprises stratégiques, qui manipulent des informations
confidentielles (banques, ministères, grandes compagnies,…etc.), qui se trouvent contraintes
de se prémunir contre tout éventuel danger qui pourrait les menacer.

 
138 
 
Partie II Chapitre 4: Implémentation et Sécurité du système

De ce fait et voulant préserver les travaux, les secrets et les avantages concurrentiels de
l’entreprise, notre systèmes d’information mis en place doit être équipés d’une sécurité
optimale, qu’elle soit physique ou logique, lui assurant une protection durant son cycle de
vie.
Le concept de Sécurité du Système d’Information (SSI) recouvre un ensemble de
méthodes, techniques et outils chargés de protéger les ressources d’un système informatique
et d’assurer que les ressources matérielles ou logicielles d'une organisation sont uniquement
utilisées dans le cadre prévu visant généralement cinq principaux objectifs :
• L'intégrité des données qui est la propriété qui assure qu’une information n’est
modifiée que dans des conditions prédéfinies (selon des contraintes précises);
• La confidentialité consiste à assurer que seules les personnes autorisées aient accès
aux ressources échangées.
• La disponibilité consiste à assurer un accès effectif et fiable au service pour toute
entité autorisée ce qui permet de maintenir le bon fonctionnement du système d'information ;
• Le non répudiation est une propriété qui assure que l’auteur d’un acte ne peut
ensuite nier l’avoir effectué (signature de l’acte) et que le récepteur ne peut ultérieurement
dénier avoir reçu un message (exemple exécution d’un ordre boursier, d’une commande…).
• L'authentification, consistant à assurer que seules les personnes autorisées aient
accès aux ressources.

Tenter de sécuriser un système d'information revient à essayer de se protéger contre les


risques liés à l'information pouvant avoir un impact sur la sécurité de celui-ci, alors pour
mieux protéger il faut d’abord commencer par savoir contre quoi doit ont protégé notre
système

2.1. Les risques :


Un risque est défini comme étant l’arrivée potentielle d’un (des) évènement(s) qui peut
(vent) causer des pertes.

2.1.1. Classification des risques :

Les risques de manque de sécurité dans un système d’information sont classifiés en


quatre catégories :
ère
1 catégories : Les accidents
ème
2 catégories : Les erreurs

 
139 
 
Partie II Chapitre 4: Implémentation et Sécurité du système
ème
3 catégories : Les attaques
ème
4 catégories : Risques divers
Nous détaillons ces 4 catégories de risque en annexe…

2.1.2. Les mesures de sécurité :

Pour définir un système d’information sécurisé, nous pouvons mettre en place les cinq
points que l’International Standard Organisation (ISO) a fait ressortir dans ses études sur les
sécurités des réseaux : la confidentialité, l’authentification, la disponibilité ou non
répudiation, l’intégrité et le contrôle d’accès.

2.2. La politique de sécurité du nouveau système :

La phase de mise en œuvre consiste à déployer des moyens et des dispositifs visant à
sécuriser le système d'information ainsi que de faire appliquer les règles définies dans la
politique de sécurité.

2.2.1. La sécurité au niveau du système d’exploitation :

• Compte et mot de passe :

Tous les utilisateurs doivent avoir un compte et un mot de passe leur permettant de
s’authentifier lors de leur accès au système d’exploitation et ceci dans le but de protéger les
postes de travail des intrusions. Les mots de passe choisis doivent être sûrs, il ne faut pas
donc utiliser d'éléments ayant un rapport direct avec la vie privée de l’employé, comme un
nom ou une date de naissance. Idéalement, le mot de passe se composera d'un mélange de
majuscules, de minuscules et de chiffres. On prévoit un changement périodique des mots de
passe.
• Prévention contre les virus:

Il est également très important de se prévenir des virus informatiques par l’utilisation
des antivirus dotés d’une mise à jour automatique afin d’éliminer les programmes dangereux
avant qu'ils ne causent de dommages.

• Mise à jour du système d’exploitation :

 
140 
 
Partie II Chapitre 4: Implémentation et Sécurité du système

De plus, il est nécessaire d’actualiser systématiquement les systèmes d'exploitation


ainsi que les navigateurs Internet étant donné que la majorité de ces modifications vient
colmater les failles au niveau de la sécurité des systèmes d'exploitation ou navigateurs
Internet.

2.2.2. La sécurité au niveau de l’application et des données :


• Compte et mot de passe :
Les utilisateurs ne peuvent accéder à l’application que s’ils possèdent une combinaison
valide de nom d’utilisateur et de mot de passe, cette authentification vise à assurer une
combinaison de fonctions d’attribution de privilèges et d’imputation (ces privilèges seront
détaillés dans le point suivant).
Concernant les utilisateurs :

- Le nom d’utilisateur sera celui du groupe auquel il appartient.


- Le mot de passe sera attribué aux utilisateurs par l’administrateur.
- L’administrateur définit le rôle de chaque utilisateur.
• Les privilèges :
L’attribution des privilèges d’accès à un système d'information, consiste à associer des
droits d'accès et/ou des ressources aux utilisateurs, leur permettant ainsi d'accéder à la
ressource souhaitée, s’ils en ont les droits. Concernant notre cas, nous détaillerons les
privilèges associés aux utilisateurs du système dans le tableau suivant :

Utilisateur Privilèges associés


Consultation des rejets assignés.
Faire le traitement des rejets.
Utilisateur Consultation des informations concernant les rejets.
Consultation de l’historique de traitement des rejets.
Possibilité de changer les mots de passe personnel.
Création et suppression de groupes d’utilisateurs.
Mise à jour des groupes d’utilisateurs existants.
Création, suppression et mise à jour des utilisateurs
Configuration des règles classification des rejets.
Administrateur
Configuration des règles d’assignation des rejets.
Création et suppression des articles de la base de connaissances.
Mise à jour du contenu de la base de connaissances.
Edition des rapports et statistiques.

 
141 
 
Partie II Chapitre 4: Implémentation et Sécurité du système

Tableau 10 : Privilèges accordés aux utilisateurs.

• Historique des accès :


Consiste à garder trace sur tous les accès des utilisateurs au système pour veiller au
bon fonctionnement du système pour contrôler les accès à la base et à l’application.

2.2.3. Sécurité du réseau :

• Pare-feu : Les principaux dispositifs permettant de sécuriser un réseau contre les


intrusions sont les systèmes pare-feu (firewall en anglais). La fonction primaire du pare-feu
est le contrôle de flux réseau, en relation avec des règles d’accès établies par un
administrateur réseau, et ce en autorisant ou bloquant le flux concerné tentant de le traverser.

• Cryptographie : Ainsi, la plupart du temps il est nécessaire de recourir à des


applications implémentant des algorithmes cryptographiques permettant de garantir la
confidentialité des échanges.
• VPN : La mise en place de tunnels sécurisés (VPN) permet d'obtenir un niveau
de sécurisation supplémentaire dans la mesure où l'ensemble de la communication est
chiffré.
• Antivirus : Mise en place d'antivirus mis à jour régulièrement.

2.2.4. Protection et sauvegarde des données :

- Séparer le serveur des données et le serveur d’application avec un pare-feu, ce qui

garantit la protection de l’accès aux données.


- Mettre en place un centre de reprise sur sinistre géographiquement éloigné avec le
matériel, les logiciels et la connectivité Internet nécessaires dans l’éventualité où les
installations principales ne seraient plus utilisables.
- Sauvegarde périodique des données sur des supports externes (CDs…), l’utilitaire
d’import et export des données d’oracle.
- Mettre en place des équipements de sauvegarde conçus pour assurer le fonctionnement
permanent et sans faille des serveurs.

2.2.5. La sécurité physique du matériel :

- Prévoir une alimentation électrique de secours.

 
142 
 
Partie II Chapitre 4: Implémentation et Sécurité du système

- Abriter les équipements dans des installations qui assurent la sécurité physique.
- Sécuriser l’accès aux locaux où sont installés les serveurs.
- Redondance de certains équipements (serveurs, disques durs,...) pour prendre le relais
en cas de panne.
- Doter le matériel informatique de générateurs électriques (onduleurs) et de systèmes d’air
conditionné redondants.

 
143 
 
 

CONCLUSION GENERALE :

Ce projet représente l’aboutissement d’une année de travail au sien de WTA Nedjma


qui nous a permis de mettre en pratique les connaissances acquises durant les quatre années
de formation à l’école supérieure d’informatique « ESI » ex « INI ».

L’objet de notre étude était la conception et la réalisation d’un Système de monitoring


et analyse des rejets pour l’implémentation du projet CRM Nedjma.

La première partie de ce projet (état de l’art) nous a permis en premier lieu d’acquérir
des connaissances précieuses dans le domaine du marketing en général, et dans le marketing
relationnel ainsi que la notion du Customer Relationship Management. Ces connaissances
nous ont permis d’introduire notre mémoire et de mieux comprendre notre sujet.

La deuxième partie consistait à faire « un état des lieux » sous forme d’une étude de
l’existant, et ce par un balayage des différents postes de travail, des procédures de travail,
des outils existants, etc. afin d’arriver à dresser une liste d’anomalies présentées sous forme
de diagnostic.

En suite, nous avons entamé l’étude conceptuelle en utilisant un processus de


développement unifié qu’est : le processus 2TUP construit sur le langage de modélisation
UML, cela nous a permis d’avoir une approche complète du développement logiciel, allant
de l’analyse, en passant par conception pour arriver aux différentes étapes incrémentales de
codage et de tests. Nous avons utilisé pour cette dernière étape le SGBD Oracle 10g et le
langage de développement JAVA J2SE, ainsi que des outils adaptés à cet environnement.

Au terme de ce travail, le prototype proposé permet :

¾ D’assurer la gestion complète du traitement des rejets.


¾ D’automatiser le recyclage des rejets.
¾ D’avoir un suivi des rejets de la récupération de ces derniers jusqu’au traitement final.
¾ D’offrir une large panoplie de choix dans la configuration des règles de catégorisation
et d’assignation des rejets en réponse au changement possible des procédures de
traitement.
¾ D’avoir une coordination de travail d’équipes pour le traitement des rejets.

 
144 
 
 

¾ D’avoir des rapports et statistiques en temps réel sur les informations concernant les
rejets.

Tout travail est amené à être amélioré, en ce sens, notre système peut encore évoluer et
se voir améliorer et enrichi des fonctionnalités suivantes:

¾ Intégrer le traitement des rejets coté Siebel.


¾ Intégrer notre système avec le BSCS et Siebel pour unifier le traitement sur une seule
application.

Avec cette conclusion, nous arrivons à terme de notre étude, ce stage de fin d’études
m’as permis de me mettre dans des conditions réelles de travail, et de consolider ainsi les
connaissances théoriques acquises durant cycle de notre formation, j’espère avoir répondu
aux besoins et soucis des utilisateurs, une première expérience professionnelle concluante en
tout point.

 
145 
 
 

BIBLIOGRAPHIE :
1. Ouvrages :
Š [Kot 03] : KOTLER&DUBOIS, Marketing et Management, 11ème édition.

2003, PEARSON Education.

Š [UML A 02] : UML 2 EN ACTION, Pascal Roques et Frank Vallée Quatrième


tirage, 2002, EYROLLES.

Š [UML A 03] : UML 2 EN ACTION, Pascal Roques et Frank Vallée Premier tirage
Juin 2004, EYROLLES JOUVE.

Š [WIK*] : « Java 2 Standard Edition » article lu sur


http://fr.wikipedia.org/wiki/Java_2_Standard_Edition

2. Mémoires :

Š « L’orientation client au marketing relationnel : Customer Relationship


Management » réalisé par : Joumana Belkebir, Samia Tronnebati, Souad Belkahia
Adnane Addioui, Safaa Sekkat. 2003/2004.
Š « Y’a-t-il une différence entre la théorie du CRM et sa pratique ? »

Stage effectué au sein de RMA WATANYA. Réalisé par : Raouia Elhakimi.

3. Sites Internet :

Š www.algeriesite.com.
Š www.crm-france.com.
Š www.commentcamarche.net.
Š www.djezzygsm.com.
Š www.lemidi-dz.com.
Š www.nedjma.dz

 
 

Vous aimerez peut-être aussi