Memoire de Magister Haciane

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Institut National de formation en Informatique
Direction de la Post-Graduation et de la Recherche
Mémoire
En vue de l’obtention du
Diplôme de Magister en Informatique
Option : Système d’Information
Présenté par
Ahmed HACIANE
Thème
Conception d’un datawarehouse Orienté

CRM
Soutenu le 09/01/2007 devant le jury composé de :

- Dr. D. E. ZEGOUR, Professeur, INI, Président ;
- Dr. M. AHMED NACER, Professeur, USTHB, Examinateur ;
- Dr. S. AIT AOUDIA, Maître de conférences, INI, Examinateur ;
- Dr. Z. ALIMAZIGHI, Maître de conférences, USTHB, Rapporteur.
2005 – 2006
Remerciements
Je tiens à exprimer mes sincères remerciements à

Mme. ALIMAZIGHI, maître de conférences à l’USTHB pour avoir
accepté d’encadrer ce mémoire et pour son aide précieuse pour
l’’accomplissement de mon travail.
Je tiens aussi à exprimer toute ma reconnaissance aux membres de l’équipe

LSI de l’institut d’électronique et d’informatique de l’USTHB pour m’avoir
accueilli au sein de leur équipe. Je les remercie et tiens à leur assurer ma
profonde gratitude.
Je tiens aussi à remercie M. SELMOUNE de l’équipe LSI pour ses

remarques qui m’ont permis d’améliorer la qualité finale de ce mémoire.
Je tiens à remercier très sincèrement l’ensemble des membres du jury qui me

font le grand honneur d’avoir accepté de juger mon travail.
Je remercie particulièrement les enseignants et le personnel de la DPGR de

l’INI, à leur tête Mme AIT ALI YAHIA, directrice de la PG, pour l’effort
considérable qu’ils fournissent pour la bonne marche de la DPGR.
Je tiens aussi à remercier mes collègues MM. BALA et CHOUDER pour
leur présence permanente à mes côtés. Je leur souhaite la pleine réussite dans
leurs travaux.
Je voudrais également exprimer mes remerciements aux personnes extérieures
au monde universitaire qui m’ont soutenu. En particulier, je remercie tous
mes amis et collègues de travail avec lesquels j’ai passé des moments
inoubliables…
Enfin, je remercie tout particulièrement mes parents qui m’ont toujours

soutenu et qui m’ont permis de mener à bien mes études. Je tiens à remercier
également mon frère et mes deux sœurs qui m’ont soutenu depuis le début.
C’est pour eux que je dédie ce mémoire.
Ahmed
Sommaire
Lexique ........................................................................................................................... VI
1. Introduction .................................................................................................................1
2. Les systèmes décisionnels « datawarehouses »...........................................................4

2.1. Les systèmes d’information décisionnels.............................................................4
2.1.1. Qu'est-ce que le décisionnel ?....................................................................4
2.1.2. Positionnement du décisionnel au sein du SI ............................................5
2.1.3. Les différentes composantes du décisionnel .............................................5
2.2. Le système datawarehouse ...................................................................................7
2.2.1. Définition du datawarehouse .....................................................................7
2.2.2. L’architecture globale du datawarehouse ..................................................8
2.2.3. Définition des concepts .............................................................................9
2.2.4. Le fonctionnement du système datawarehouse .......................................12
2.3. Les modèles de données du datawarehouse ......................................................14
2.3.1. Caractéristiques d’utilisation : OLTP vs OLAP ......................................14
2.3.2. Les techniques de modélisation...............................................................16
2.4. Le système datawebhouse ..................................................................................21
2.4.1. L'impact du Web sur le datawarehouse ...................................................21
2.4.2. Objectifs du datawebhouse......................................................................22
2.4.3. De et vers le Web.....................................................................................23
2.4.4. Amener le Web au datawarehouse ..........................................................24
2.4.5. Amener le datawarehouse au Web ..........................................................25
2.5. La gestion du « Temps » dans le datawarehouse................................................26
2.5.1. Le rôle des données temporelles..............................................................26
2.5.2. Les problématiques liées au « Temps » ...................................................28
2.5.3. Le temps dans la première génération des datawarehouses ....................29
3. CRM : Customer Relationship Management ............................................................31

3.1. Introduction au CRM..........................................................................................31
3.1.1. Définition du CRM..................................................................................31
3.1.2. Les objectifs du CRM..............................................................................33
3.1.3. Les résultats constatés avec le CRM .......................................................34
3.2. Les facteurs du CRM..........................................................................................35
3.2.1. Le facteur humain....................................................................................35
3.2.2. Le facteur organisationnel .......................................................................36
3.2.3. Le facteur technologique .........................................................................37
3.3. Le cycle de vie du client.....................................................................................38
3.4. Le développement de la relation client...............................................................38
3.4.1. Les étapes du développement ..................................................................38
3.4.2. Les raisons de la prédominance de la relation client ...............................39
3.5. Les fonctionnalités offertes par les systèmes CRM ...........................................42
3.6. E-Commerce et la gestion de la relation client via Internet ...............................44
3.6.1. Le CRM sur Internet................................................................................44
3.6.2. Choisir le bon moyen de communication ................................................46
3.6.3. Les trois règles de succès sur la route du e-commerce............................47
3.7. Les composants du CRM ...................................................................................47
3.7.1. Les systèmes et données en provenance de l’ERP ..................................47
3.7.2. Les bases de données externes.................................................................48
3.7.3. Les canaux d’interaction..........................................................................48
3.7.4. Le datawarehouse ....................................................................................48
3.8. La technologie du datawarehouse comme base pour le CRM ...........................49
4. Conception d’un datawarehouse orienté CRM..........................................................52

4.1. Etude de cas : présentation de « ETS Boissons » ...............................................52
4.2. Le modèle conceptuel général (MCG) orienté CRM .........................................54
4.2.1. Comportement client et circonstances client : le cause-à-effet ...............55
4.2.2. Le modèle conceptuel général « ETS Boissons » ....................................60
4.3. La méthode du point et la modélisation conceptuelle détaillée..........................63
4.3.1. La limite des méthodes traditionnelles ....................................................63
4.3.2. La causalité des changements sur les données ........................................69
4.3.3. Le modèle du « point »............................................................................70
4.3.4. La construction du modèle conceptuel détaillé « ETS Boissons » ..........75
4.4. La modélisation logique du datawarehouse orienté CRM .................................82
4.4.1. L’implémentation de la rétrospection......................................................82
4.4.2. Choisir la solution d’implémentation ......................................................89
4.4.3. Le schéma logique relationnel « Clients » ..............................................90
4.4.4. Les contraintes de la rétrospection ..........................................................92
4.5. L’implémentation physique du système.............................................................95

4.5.1. L’architecture physique du datawarehouse orienté CRM .......................95
4.5.2. La couche VIM.........................................................................................97
4.5.3. L’alimentation du datawarehouse..........................................................103
4.5.4. Le modèle physique de données............................................................104
4.5.5. Les applications CRM ...........................................................................109
4.5.6. Synthèse sur l’architecture du système..................................................110
4.6. Les produits logiciels........................................................................................111
4.6.1. Les produits ETL...................................................................................112
4.6.2. Les produits OLAP................................................................................114
4.6.3. Les outils de restitution .........................................................................115
4.6.4. Le Datamining .......................................................................................116
5. Conclusion et perspectives ......................................................................................119
6. Références Bibliographiques...................................................................................123
Sommaire des figures
Chapitre 2 : Les systèmes décisionnels « Datawarehouses »

Figure 2.1.1 : Une vision transversale de l’entreprise .......................................................4
Figure 2.1.2 : Le décisionnel au sein du système d’information.......................................5
Figure 2.1.3 : Les différents composants du décisionnel ..................................................5
Figure 2.2.1 : L’architecture du datawarehouse ................................................................8
Figure 2.2.2 : L’architecture du système décisionnel........................................................8
Figure 2.2.3 : L’acquisition des données.........................................................................12
Figure 2.2.4 : Le processus d’acquisition des données....................................................13
Figure 2.2.5 : L’alimentation des datamarts ....................................................................13
Figure 2.2.6 : La restitution des données.........................................................................14
Figure 2.3.1 : Le modèle de données normalisé ..............................................................17
Figure 2.3.2 : Le modèle de données dénormalisé ..........................................................18
Figure 2.3.3 : Le modèle de données en étoile ................................................................20
Figure 2.3.4 : Le modèle de données en flocon...............................................................21
Figure 2.4.1 : Le client, le site Web et le datawebhouse .................................................22
Figure 2.4.2 : Les deux facettes du datawebhouse ..........................................................23
Figure 2.4.3 : Exemple de datamart du « Clickstream » .................................................25
Chapitre 3 : CRM : Customer Relationship Management

Figure 3.1.1 : L’évolution des composantes d’entreprise................................................32
Figure 3.1.2 : Les objectifs du CRM ...............................................................................34
Figure 3.1.3 : Les résultats constatés...............................................................................34
Figure 3.6.1 : Les relations CRM – Datawarehouse........................................................49
Chapitre 4 : Conception d’un datawarehouse orienté CRM

Figure 4.1.1 : Le modèle général initial en étoile « ETS Boissons »...............................53
Figure 4.2.1 : Rappel : le modèle conceptuel général « ETS Boissons » ........................54

Figure 4.2.2 : MCG : Vue globale « circonstances ‘client’ changeantes » .....................57
Figure 4.2.3 : MCG : Vue détaillée « circonstances ‘client’ changeantes »....................58
Figure 4.2.4 : MCG : Vue globale « Client » ..................................................................58
Figure 4.2.5 : MCG « ETS Boissons » : Vue détaillée « Client »… ..............................59
Figure 4.2.6 : MCG : Vue globale complète « Client » ..................................................59
Figure 4.2.7 : MCG « ETS Boissons » 1/3 : Vue détaillée « Client »… ........................61
Figure 4.2.8 : MCG « ETS Boissons » 2/3 : Vue détaillée « Client »… ........................62
Figure 4.2.9 : MCG « ETS Boissons » 3/3 : Vue détaillée « Client »… .......................62
Figure 4.3.1 : Le modèle du point ...................................................................................71

Figure 4.3.2 : Le modèle du point comportemental « ETS Boissons »............................71
Figure 4.3.3 : Exemple d’un modèle du point d’une compagnie de télécom ..................74
Figure 4.3.4 : Le modèle comportemental initial ............................................................76
Figure 4.3.5 : Le modèle du point comportemental affiné « ETS Boissons » .................77
Figure 4.4.1 : L’implémentation de la rétrospection en utilisant… ................................88

Figure 4.4.2 : Le schéma logique des circonstances « clients » ......................................90
Figure 4.5.1 : L’architecture EASI du système ...............................................................96

Figure 4.5.2 : Le modèle des métadonnées de validation................................................99
Figure 4.5.3 : Le modèle des métadonnées de transformation ......................................100
Figure 4.5.4 : Le modèle des métadonnées de mappage ...............................................101
Figure 4.5.5 : Le modèle complet des métadonnées de la couche VIM ........................102
Figure 4.5.6 : L’extraction et le chargement des données .............................................103
Figure 4.5.7 : Le rafraîchissement des données.............................................................104
Figure 4.5.8 : Le modèle physique des circonstances « Clients » non-changeantes .....104
Figure 4.5.9 : Le modèle physique des circonstances « Clients » changeantes ............105
Figure 4.5.10 : Le modèle physique du comportement .................................................107
Figure 4.5.11 : Le modèle physique des segments dérivés ...........................................108
Figure 4.6.1 : Le processus ETL....................................................................................112

Lexique
ABC (activity Based Costing) : Méthode d’optimisation des processus. Elle est fondée
sur une évaluation au plus juste des coûts de revient de chacune des activités du processus.
ACSI (American Customer Satisfaction Index) : Indice américain de mesure de la
satisfaction de la clientèle. L’indice reflète les attentes des clients, la qualité réellement perçue
ainsi que la valeur perçue. Il peut être décliné au niveau de l’entreprise. http://acsi.asq.org/
Agent intelligent : Programme autonome et personnalisable. Les plus aboutis intègrent des
caractéristiques d’auto-apprentissage et de communication avec ses alter-ego pour une action
coopérative. Ils sont le plus souvent dédiés aux techniques de recherche et de collecte
d’information.
Analyse de la valeur (Target Costing) : Approche de conception fondée sur une
décomposition en fonctions élémentaires et la mise en exergue du coût d’utilité. En d’autres
termes, au moment de la conception, pour chaque fonction prévue d’un produit, on se posera
les deux questions : quelle est son utilité ? Quelle est sa valeur ?
API Application Programming Interface : C’est une interface de programmation
standardisant l’accès à des fonctions spécifiques d’un produit logiciel ou d’une application.
Pour l’accès aux bases OLAP, Microsoft est en train d’imposer son standard : OLE DB for
OLAP.
Balanced Scorecard : Une approche de pilotage d’entreprises proposée par Robert Kaplan
et David Norton conseillant de juger toutes les décisions sous l’éclairage de quatre (4)
perspectives :
Axe Financier : Comment nous voient les actionnaires ?
Axe Client : Comment nous voient les clients ?
Axe Processus internes : Quels sont nos avantages ?
Axe Apprentissage organisationnel : Allons-nous progresser ?
Cette approche rencontre un franc succès aux Etats-Unis. Elle mériterait cependant d’être
réactualisée pour considérer les nouveaux rôles des clients et des partenaires. Les adeptes de
cette approche pourront, avec profit, la compléter par la méthode GIMSI.
Business Intelligence : C’est le nouveau terme pour identifier toutes les fonctions ayant
trait à l’aide à la décision. Le terme englobe toute la chaîne décisionnelle, de la collecte en
passant par les Datawarehouses et les Datamarts, l’analyse et les tableaux de bord.
Cash-flow : Solde des flux de trésorerie engendré par un investissement à la clôture d’une
période.
Cross selling : Technique recherchant à améliorer la valeur client en l’incitant à acheter
aussi d’autres produits que ceux achetés régulièrement. La réussite du cross selling est
conditionnée par le décloisonnement de la fonction marketing. (voir Up selling)
CRM : CRM est un acronyme pour « Customer Relationship Management », en français
GRC pour « Gestion de la Relation Client ».
CRM est un terme de l’industrie des systèmes d’information englobant des méthodologies,
des stratégies, des outils logiciels et habituellement des capacités internet qui aide une
entreprise à gérer ses relations client d’une manière structurée.
Datamart : Entrepôt de données départemental orienté sur un problème spécifique.
Datamining : Outil d’analyse mettant en évidence des corrélations insoupçonnées en
travaillant sur grand nombre de données. Le terme datamining englobe des techniques
différentes comme : les recherches d’association, les arbres de décision, les algorithmes
génétiques ou encore les techniques d’apprentissage comme les réseaux de neurones.
Datawarehouse : Entrepôt de données. Un datawarehouse centralise les données issues des
applications utilisées dans l’entreprise. Les données sont organisées par sujet, horodatées et
historisées. Pour réussir son Datawarehouse, il faut en premier abandonner la vision
universelle de l’information et se focaliser sur des problèmes particuliers et les traiter un par
un. En deuxième, il faut surtout ne pas négliger les travaux de nettoyage qui constituent la
tâche la plus lourde du projet. En troisième, il faut adopter un système de gestion des méta-
données et le maintenir en permanence dans un esprit de qualité totale.
DOLAP Desktop OLAP : C’est une version simple du modèle OLAP pour des analyses
multidimensionnelles locales, au sein de la machine client.
Drill Down : zoom dans une base OLAP ou comment aller du global au détail.
EIS (Executive Information System puis Entreprise Information System) :
Tableau de bord destiné à l’origine au management. Le terme n’a pas survécu à la
banalisation des systèmes décisionnels et est remplacé par la « Business Intelligence »
ERP (Entreprise Ressource Planning ou Progiciel de gestion intégré) : Outil
fédérateur du système d’information, l’ERP intègre les fonctions de l’entreprise comme la
comptabilité, la gestion des ressources humaines, la gestion de production… Malgré ses
avantages quant au décloisonnement du SI dans l’entreprise, les ERP pèchent cruellement par
manque d’ouverture vers les clients, les partenaires et les besoins décisionnels des utilisateurs.
ETL (Extraction Transformation Loading) : Désigne une catégorie d’outils et par
extension d’activités dédiées à l’extraction des données des bases de productions, à leur
adaptation (nettoyage entre autre) et au stockage dans un système décisionnel, le
datawarehouse ou le datamart dans la plupart des cas.
GRC : Gestion de la relation client (voir CRM).
Groupware : Ce sont les outils destinés à favoriser le travail en équipe. On trouvera
notamment la messagerie, les bases d’informations partagées et le workflow. Une gestion de
contacts, un agenda partagé, voire des outils de vidéo conférence pouvant compléter la
panoplie d’outils.
HOLAP Hybrid OLAP : Ce terme décrit les bases assurant le juste compromis entre le
modèle MOLAP et ROLAP, MOLAP pour les données les plus souvent utilisées et ROLAP
pour les autres.
HTML Hyper Text Mark-up Language : Langage de description des pages Web. HTML
est un dérivé allégé du langage de documentation SGML.
HTTP : Protocole de transfert des pages HTML sur le réseau Internet.
Méta Donnée (Meta data) : ou les données sur les données. Les méta-données stockent
toutes les informations nécessaires à la vie des données : origine, date de dernière mise à jour,
mode de calcul, procédure de transformation… La gestion des méta-données est le point clé
de la gestion de la qualité du système d’information. Le manque de standard est aujourd’hui la
principale difficulté OIM (Open Information Model) du Meta Data Coalition ou CWM
(Common Warehouse MetaData) de l’OGM (Object Management Group).
MOLAP Multidimensionnal OLAP : Il s’agit des bases de données intégrant
physiquement le modèle OLAP.
MTBF (Mean Time Between Failure) : Temps moyen entre deux pannes.
MTTR (Mean Time To Repair) : Temps moyen de dépannage.
ODBC (Open Data Base Connectivity) : Le standard de Microsoft pour accéder aux
bases de données. Les solutions ODBC s’opposent aux interfaces dites « native » propriétaires
mais plus performantes.
OLAP (On-Line Analytical Processing) : Le concept de base de données
multidimensionnelle établi par EF CODD l’inventeur du modèle relationnel. Partant du
constat que le modèle classique OLTP (On-Line Transaction Processing) était inadapté aux
besoins de l’analyse, EF CODD a formalisé les 18 règles du modèle (gérer, traiter et présenter
les données multidimensionnelles).
Reporting : Informations constatant l’activité et entre autre la performance locale transmises
selon la voie hiérarchique au niveau supérieur à titre de compte-rendu. Elles seront le plus
souvent globalisées pour construire un indice « moyen ».
ROLAP Relationnal OLAP : Ce terme décrit les bases de structure relationnelle implantant
le modèle OLAP.
SFA – Sales Force Automation – : des anciens systèmes qui se bornaient principalement
à soutenir la mission du représentant en contact avec le client dans la prise des commandes.
UML (Unified Modeling Language) : Langage de modélisation. Il est issu des méthodes
d’analyse objet : OOD (Object Oriented Design), OMT (Object Modeling Technique) et
OOSE (Object Oriented Software Engineering).
Up Selling : Technique recherchant à améliorer la valeur client en l’incitant à augmenter ses
achats (en proposant des services complémentaires par exemple).
XML (eXtensible Markup Language) : Est un langage « d’écriture » de données. Il
dérive de SGML, un langage plus ancien utilisé dans les bases documentaires. Il est beaucoup
plus puissant sur le plan des règles et des possibilités de définition et de programmation que
HTML. Notamment, il sépare le texte de sa présentation. Il ne remet pas en cause tous les
acquis du Web, notamment le protocole HTTP, et peut devenir la norme d’écriture.
Chapitre 1
Introduction
n Introduction générale ;
n Problématique ;
n Contribution ;
n Présentation du mémoire.
Introduction
1. Introduction
Le CRM – Customer Relationship Management – ou GRC en français – Gestion de la
Relation Client – a trouvé son origine dans plusieurs études américaines qui ont démontré que
fidéliser un client coûtait jusqu’à cinq fois moins cher que d’en conquérir de nouveaux.
La mise en place d’une démarche CRM est une stratégie qui va mettre le client au centre de
l’entreprise et qui a pour objectif d’en améliorer la rentabilité et de le fidéliser.
La gestion de la relation client s’est surtout développée dans les années 90 afin de répondre à
l’évolution du contexte économique : passage d’une économie d’offre orientée « produit » –
années 50 à 60 – à une économie de demande orientée « marché » – années 70 à 80 – puis
« client » – depuis les années 90 –. Et enfin, avec l’avènement du Web, une nouvelle notion
est apparue : l’E-CRM, ou le CRM électronique via le Web – années 2000 –.
D’un autre côté, les systèmes décisionnels basés sur les datawarehouses sont apparus depuis
le début des années 90 afin de permettre de mesurer la performance de l’entreprise dans son
environnement. Cette mesure permet d’assister les décideurs dans leur processus de prise de
décision. Ainsi, Les systèmes décisionnels tentent de rendre ce processus le plus efficace
possible.
Le but principal du datawarehousing est de rendre l’information disponible pour tous les
acteurs de l’entreprise. Il n’existe pas de doute sur la valeur de l’information dans l’entreprise,
et nous admettons tous que la majorité des entreprises ont une masse d’informations
considérable non-exploitée dans leurs systèmes opérationnels. Le datawarehouse peut être la
clé qui ouvre la porte vers ces informations.
Au fil des années, les datawarehouses n’ont pas cessé d’évoluer afin d’intégrer des concepts
liés aux nouvelles tendances émergentes telle que Internet et aussi, le CRM.
Au début de leur apparition, les datawarehouses (de « première génération ») n’ont pas été
toujours un succès et cela pour au moins deux raisons :
La première est liée à la sous-estimation de la complexité des projets datawarehouses et la
difficulté de la gestion des bases de données décisionnelles. La deuxième raison est, quant-à-
elle, liée au fait que dans un projet datawarehouse, il n’est pas possible de définir
préalablement les besoins d’une manière précise, et cela au contraire des systèmes
opérationnels. Or, l’approche de conception traditionnelle des systèmes d’informations restent
toujours largement basée sur la compréhension préalable des besoins.
14
Introduction
Problématique :
Les entreprises existent pour générer un chiffre d’affaire et un profit et le client y constitue la
principale source de revenue. C’est pourquoi, la prise de décision dans l’entreprise doit « être
orientée » et « en relation » avec les clients. Cela ne devient possible que si les
datawarehouses sont capables de fournir toutes les données nécessaires sur les clients.
Les datawarehouses classiques stockent des données comportementales. Ainsi, ces systèmes
permettent de connaître et d’analyser le comportement des clients. Or, les données
comportementales ne sont pas suffisantes pour une prise de décision CRM efficace. Pour
atteindre cet objectif, les applications CRM doivent être supportées par des datawarehouses
conçus autour d’objectifs CRM et qui ne se limitent pas à recueillir que les données
comportementales. Ce sont des datawarehouses de « deuxième génération » qui intègrent un
nouvel objectif clair : maximiser l’efficacité de la gestion de la relation client (CRM).
Contribution :
Le but de ce mémoire est de traiter les éléments liés à la conception d’un datawarehouse
orienté CRM pouvant constituer l’élément de base de toute infrastructure CRM efficace. Dans
ce mémoire, une méthodologie complète de conception et d’implémentation de
datawarehouses orienté CRM est présentée. Ma contribution personnelle dans ce travail sera
de regrouper et de présenter tous les éléments de conception nécessaires d’un datawarehouse
orienté CRM en se basant sur les travaux de recherche actuels dans ce domaine et
d’appliquer en parallèle la méthode et les concepts sur une étude de cas. Ce mémoire traitera
donc tous les aspects liés à la conception d’un datawarehouse orienté CRM. Le sujet principal
de ce mémoire est donc le datawarehousing (la construction d’un datawarehouse).
Présentation du mémoire :
Le mémoire est organisé comme suit :
Un Premier chapitre état de l’art sur La première génération des datawarehouses :
Historiquement, la première génération des datawarehouses a été construite sur un certain
nombre de principes définis par les gourous de l’industrie des systèmes d’information. Les
deux principaux pionniers dans le domaine sont : ‘Ralph KIMBALL’ et ‘Bill INMON’. Ces
deux personnes peuvent être considérées comme les fondateurs du datawarehousing puisque
ce sont eux qui ont donné les définitions et les principes de conception des datawarehouses
qui restent actuellement la référence dans le domaine.
15
Introduction
Le premier chapitre de ce mémoire donne une introduction sur les datawarehouses de

première génération et traite, entre-autres, les points suivants :
• Le besoin en systèmes décisionnels,
• Comment le datawarehouse peut aider à répondre à ce besoin,
• Les différences entre les systèmes opérationnels et les systèmes décisionnels,
• Les principaux composants du datawarehouse,
• L’importance des données temporelles dans les datawarehouses.
Un deuxième chapitre état de l’art sur La gestion de la relation client :

Après avoir présenté les principes du datawarehousing, nous allons essayer de découvrir
l’univers de la gestion de la relation client (en anglais CRM pour : Customer Relationship
Management, abréviation que nous allons d’ailleurs utiliser tout-au-long de ce mémoire).
L’arrivée des systèmes CRM a tout changé. Le CRM ne peut pas être pratiqué dans une
entreprise sans avoir une source majeure d’information. Or, la disponibilité de cette source est
la raison d’être des datawarehouses. Ainsi, l’intérêt des datawarehouses a été ainsi revitalisé.
Les datawarehouses de première génération attendaient l’apparition du CRM pour évoluer et
montrer leur vrai intérêt. Sans le CRM, les datawarehouses auraient tout de même gardés leur
importance malgré le fait que les projets datawarehouses sont qualifiés de complexes, chers et
à grands risques.
Un troisième chapitre sur La conception d’un datawarehouse de deuxième génération

orienté CRM :
Nous allons ensuite entamer le cœur de notre sujet qui est la conception d’un datawarehouse
de deuxième génération orienté CRM. Nous rappelons, que dans ce mémoire, nous allons
agrémenter notre travail par une étude de cas. L’étude de cas concerne une entreprise
classique de commercialisation de boissons implantée sur le territoire national. Un
datawarehouse orienté CRM sera conçu pour cette entreprise. Pour ce faire, nous allons
produire les modèles conceptuels, logiques et physiques des données et proposer
l’architecture physique du système.
Le mémoire se termine par la présentation des axes de recherches actuels et futurs sur les
datawarehouses orientés gestion de la relation client.
16
Chapitre 2
Les systèmes décisionnels

« Datawarehouses »
n Les systèmes d’informations décisionnels ;

n Le Datawarehouse : définition, objectifs, concepts et architectures ;
n Les techniques de modélisation décisionnelle ;
n La gestion du « Temps » dans les datawarehouses.
Les systèmes décisionnels « datawarehouses »
2. Les systèmes décisionnels « datawarehouses »
2.1. Les systèmes d’information décisionnels
2.1.1. Qu’est-ce que le décisionnel ?

Le système d’information décisionnel est un ensemble de données organisées de façon
spécifique, facilement accessibles et appropriées à la prise de décision ou encore une
représentation intelligente de ces données au travers d’outils spécialisés. La finalité d’un
système décisionnel est le pilotage de l’entreprise.
Les systèmes de gestion sont dédiés aux métiers de l’entreprise pour les assister dans leurs
tâches de gestion quotidiennes, et directement opérationnels car maintenus par les utilisateurs
sur le terrain.
Les systèmes décisionnels sont dédiés au management de l’entreprise pour l’aider au pilotage
de l’activité, et indirectement opérationnels car n’offrant que rarement le moyen d’appliquer
les décisions. Ils constituent une synthèse d’informations opérationnelles, internes ou
externes, choisies pour leur pertinence et leur transversalité fonctionnelles, et sont basés sur
des structures particulières de stockage volumineux (datawarehouses, bases OLAP). Le
principal intérêt d’un système décisionnel est d’offrir au décideur une vision transversale de
l’entreprise intégrant toutes ses dimensions. [Source : Goglin1998]
Figure 2.1.1 : Une vision transversale de l’entreprise [source : Goglin1998]
Cette vue intégrée peut alors être étudiée par fonction ou par métier.
18
2.1.2. Positionnement du décisionnel au sein du système d’information

D’un point de vue architectural, nous considérerons que nous pénétrons dans le monde du
décisionnel dès lors que les données de production sont valorisées en informations. Cette
valorisation est effective dès que l’on sort du monde de la production.
Sur le schéma suivant, décrivant l’architecture fonctionnelle d’une entreprise, on voit la place
prise par le décisionnel au sein d’un système d’information. [Source : Goglin1998]
Figure 2.1.2 : Le décisionnel au sein du système d’information [source : Goglin1998]
2.1.3. Les différentes composantes du décisionnel

Allié aux nouvelles technologies de communication et de diffusion de l’information, le
décisionnel va façonner la nouvelle informatique de demain.
Figure 2.1.3 : Les différents composants du décisionnel [source : Goglin1998]
19
De façon chronologique, on peut considérer que les premiers systèmes de pilotage ont été
constitués par des outils qui, via des requêtes, permettaient de constituer des tableaux de bord.
Ces outils se sont ensuite enrichis de fonctionnalités de simulation et d’interfaces de
présentation. Ce fût alors l’avènement des outils EIS et SIAD. Ces outils aussi puissants
soient-ils, ne permettent que de faire une photographie en deux dimensions d’une situation
donnée. On est donc : « capable d’identifier un dysfonctionnement, mais pas d’en connaître la
cause ». [Source : Goglin1998]
Pour pouvoir rechercher et identifier les causes, il fallait introduire une nouvelle dimension au
système « photographique » en deux dimensions existant, la dimension de l’agrégation qui
permet d’expliquer l’origine de l’information étudiée. Cette nouvelle dimension a été
introduite par les systèmes multidimensionnels au travers des systèmes OLAP (On-Line
Analytical Processing).
Les outils devenant plus conviviaux et plus puissants, les décideurs s’ingénièrent à trouver de
plus en plus d’indicateurs toujours plus astucieux et plus compliqués. La course à l’indicateur
était lancée. Elle eut pour principale conséquence de noyer le décideur sous une masse de
tableaux de bord et de synthèses dont il n’arrivait plus à extraire la substantifique moelle. On
introduisit alors un moyen graphique pour identifier plus vite les informations utiles, ce fut
l’introduction du « color-coding » et des systèmes d’information cartographiques qui
permettent d’identifier visuellement les informations intéressantes selon les critères du
décideur puis de les représenter sous une forme directement exploitable par une équipe de
direction.
Il devenait alors intéressant de diffuser en « temps réel » toutes ces informations et toutes ces
analyses vers tous les cadres concernés. C’est ce qu’allait permettre le développement des
réseaux, des activités de « Workflow » et maintenant Internet.
Notons que le décisionnel souffre toujours d’un grave manque : Il sait fournir les informations
nécessaires au décideur ou trouver des corrélations entre des évènements apparemment non
liés, mais ne sait pas assister le décideur dans sa prise de décision. Le décideur devient
victime du syndrome de la non prise de décision puisqu’il ne sait pas forcément ni par quel
bout commencer, ni, finalement, quelle décision prendre.
Il faut connaître les seuils à partir desquels les valeurs des indicateurs sont considérées
comme anormales, puis identifier les règles exploitant ces seuils afin de proposer un
diagnostic. Ce diagnostic permet de prendre la décision finale. Ces nouveaux outils sont
appelés les moteurs de règles de gestion. Leur objectif n’est pas de se substituer au décideur,
mais bien de l’assister dans sa prise de décision.
20
2.2. Le système datawarehouse
2.2.1. Définition du datawarehouse

Un datawarehouse est un entrepôt de données. Il s’agit d’un stockage intermédiaire des
données issues des applications de production, dans lesquelles les utilisateurs finaux puisent
avec des outils de restitution et d’analyse.
La définition suivante a été énoncée par ‘Bill Inmon’ :
« Un datawarehouse est une collection de données thématiques, intégrées, non volatiles et
historisées organisées pour la prise de décision ».
Un datawarehouse est une collection de données :

• Thématiques (orientées sujet) : l’objectif d’un datawarehouse est la prise de décisions
autour des activités majeures de l’entreprise. On assemblera à cet effet les informations
par thèmes contrairement aux modélisations traditionnelles qui regroupent les
informations par fonctions. On pourra ainsi passer d’une vision verticale de l’entreprise à
une vision transversale beaucoup plus riche.
• Intégrées : la transversalité recherchée sera d’autant plus efficiente que le système
d’information sera réellement intégré. Cette intégration nécessitera une forte
normalisation, une bonne gestion des référentiels et de la cohérence, une parfaite maîtrise
de la sémantique et des règles de gestion s’appliquant aux données manipulées.
• Non volatiles (pas de suppression) : afin de conserver la traçabilité des informations et
des décisions prises, les informations stockées au sein du datawarehouse ne peuvent être
supprimées.
• Historisées : outre les problèmes de volumétries, de capacité de stockage et de calcul des
machines hébergeant le datawarehouse, ce qui nécessite une historisation régulière des
informations stockées, l’historisation est rendue nécessaire en vue de suivre dans le temps
l’évolution des différentes valeurs des indicateurs à analyser. De ce fait, un référentiel
temporel est nécessaire.
• Organisé pour la prise de décision. [Source : Kimball1999]
21
2.2.2. L’architecture globale du datawarehouse

Le schéma suivant illustre l’architecture générique d’un système datawarehouse :
Figure 2.2.1 : L’architecture du datawarehouse [source : Goglin1998]
L'architecture des systèmes décisionnels met en jeu quatre éléments essentiels : les sources de
données, l'entrepôt de données, les magasins de données et les outils d'analyse et
d'interrogation.
Figure 2.2.2 : L’architecture des systèmes décisionnels [source : Teste2000]
Les sources de données sont nombreuses, variées, distribuées et autonomes. Elles peuvent
être internes (bases de production) ou externes (Internet, bases des partenaires) à l'entreprise.
22
L'entrepôt de données (datawarehouse) est le lieu de stockage centralisé des informations

utiles pour les décideurs. Il met en commun les données provenant des différentes sources et
conserve leurs évolutions.
Les magasins de données (datamarts) sont des extraits de l'entrepôt orientés sujet. Les
données sont organisées de manière adéquate pour permettre des analyses rapides à des fins
de prise de décision.
Les outils d'analyse permettent de manipuler les données suivant des axes d'analyses.
L'information est visualisée au travers d'interfaces interactives et fonctionnelles dédiées à des
décideurs souvent non informaticiens (directeurs, chefs de services,…).
2.2.3. Définitions des concepts [Source : Goglin1998]

Voici la définition des principaux concepts utilisés dans le domaine du datawarehousing :
Bases de production
On appelle, d’une façon générale, bases de production toutes les sources (qu’il s’agit de
données de production, d’informations internes ou d’informations externes quel que soit leur
mode de stockage) dont il va falloir extraire des données en vue d’alimenter le datawarehouse.
L’alimentation ou transformation
Les outils d’alimentation sont utilisés pour extraire les données des bases de production et des
bases d’informations internes et externes, pour les convertir, les transformer et enfin les
stocker dans le datawarehouse.
La base de données du datawarehouse

La base de données est le constituant principal du datawarehouse puisque c’est dans celle-ci
que l’on va stocker les informations extraites des bases de production. C’est au sein du SGBD
qu’est stocké le dictionnaire du datawarehouse où sont stockées les métadonnées, c’est-à-dire
« les données sur les données stockées dans le SGBD » décrivant la manière dont sont
constituées les informations stockées.
23
Le datawarehouse est supporté par une base de données relationnelle, multidimensionnelle ou

objet, même si celles-ci sont assez rares ou utilisées dans des contextes assez particuliers.
Une base de données multidimensionnelle est une base dont les données sont stockées de
manière à optimiser l’accès aux informations suivant des requêtes non prévues à sa création.
Datamart
Un datamart est un magasin de données. Il s’agit d’une solution départementale d’entrepôt de
données (datawarehouse) supportant une partie des données et fonctions de l’entreprise
(produit, département, activité, etc.). C’est un sous-ensemble du datawarehouse qui ne
contient que les données d’un métier de l’entreprise alors que le datawarehouse contient
toutes les données décisionnelles de l’entreprise pour tous les métiers.
OLAP (On Line Analytical Processing)

La finalité d’un datawarehouse est d’obtenir des vues multidimensionnelles. Ces vues sont
représentées sous la forme d’un cube en trois dimensions sachant qu’une base
multidimensionnelle peut comporter de nombreuses dimensions.
Les systèmes OLAP mettent en œuvre des technologies permettant de rassembler, gérer,
traiter et présenter des données multidimensionnelles à des fins d’analyse et de décision. Un
outil OLAP est capable de fournir une information multidimensionnelle partagée pour
l’analyse rapide.
Datamining
Les outils de datamining, également appelés « forage des données » ou « extraction de la
connaissance », s’appuient sur le constat qu’il existe au sein de chaque entreprise des
informations dont le sens ou les liens sont cachés dans le gisement des données de
l’entreprise. Le datamining permet de faire apparaître des corrélations dans des gisements de
données.
Le datamining est l’étape logique suivant le datawarehousing puisqu’il consiste en l’analyse
des données composant le datawarehouse à l’aide d’outils spécialisés en intelligence
artificielle, visant à mettre en exergue des corrélations non apparentes par des analyses de
premier niveau.
24
EIS
Un EIS (Executive Information System) est un outil de visualisation des données et de
navigation, permettant de constituer des tableaux de bord. Il est constitué d’outils qui
permettent aux différents niveaux de management d’accéder aux informations essentielles de
leur organisation, de les analyser et de les présenter de façon élaborée. Ces outils sont dotés
d’une interface graphique très conviviale et très esthétique.
L’utilisateur final ne peut visualiser ou exploiter que des informations qui ont été prévues par
le concepteur des tableaux de bord. A la différence d’un SIAD, l’EIS ne permet pas à
l’utilisateur final de poser une question qui n’aurait pas été prévue initialement.
SIAD
Un SIAD (Système Interactif d’Aide à la Décision) est un outil d’analyse et de modélisation
des données de l’entreprise qui permet de créer des représentations multidimensionnelles de
l’information. Historiquement, il s’agit d’une terminologie et d’outils utilisés avant
l’avènement et la maturité du datawarehouse.
Requêteur
Un requêteur permet à l’utilisateur final d’accéder aux données de l’entreprise de manière
autonome, dans un langage propre à son métier, mais qui nécessite généralement la
connaissance de la structure de la base accédée, et ce, en définissant lui-même les
informations qu’il veut obtenir ainsi que le format des restitutions souhaitées.
Progiciels
Ce sont des applications packagées orientées vers un ou plusieurs métiers dédiés (marketing,
logistique, finance, ressources humaines, etc.).
Moteur de règles de gestion

Un moteur de règles de gestion est un outil permettant de gérer le patrimoine d’une entreprise
qu’est son métier, cristallisé par un ensemble de règles de gestion constituant son expertise et
son savoir-faire.
25
Internet/intranet
Internet en tant que vecteur de communication normalisé et banalisé répond parfaitement aux
problématiques d’accès banalisé et de publication à distance et à faible coût. Internet permet
d’envisager, par exemple :
L’envoi par messagerie électronique et donc la publication des analyses effectuées ;
La possibilité pour un interlocuteur distant de se connecter pour connaître les dernières
évolutions des ventes par exemple ;
La mise à disposition, au sein d’un serveur Web par exemple, d’informations internes comme
les statistiques de production ou externes comme la présentation de la société.
2.2.4. Le fonctionnement du système datawarehouse

Une fois l’architecture du système connue, nous expliquons son fonctionnement. Un système
datawarehouse fonctionne selon les étapes suivantes :
a. L’acquisition des données
DWH
OLTP
Acquisition de données
Figure 2.2.3 : L’acquisition des données
Cette étape constitue la frontière entre le système décisionnel et les systèmes opérationnels.
Cette étape détermine la faisabilité du système. Elle consiste à extraire les données outils des
systèmes opérationnels qui dans de nombreux cas sont hétérogènes, diffuses et complexes.
La problématique de l’alimentation d’un datawarehouse se résout par la mise en place d’un
processus en cinq phases : découvrir, extraire, transformer, transporter et charger.
26
Administrer * Planifier * Surveiller
Découvrir Charger
Méta données
Fédérer
Extraire Transporter
Transformer
Figure 2.2.4 : Le processus d’acquisition de données
b. Le stockage des données dans le datawarehouse (l’entrepôt de données)

C’est le point central de stockage de toutes les données de l’entreprise concernées par le
système décisionnel. Les données du datawarehouse sont, rappelons-le, orientées sujet,
intégrées, non volatile et historisées pour le support du processus d’aide à la décision.
c. L’alimentation des datamarts (les magasins de données)
Finance
Commercial
DWH
RH
Figure 2.2.5 : L’alimentation des datamarts …….
• Le datawarehouse est le sas central de contrôle, garant de la qualité et de l’intégrité de

l’information. Son principal objectif est d’optimiser l’approvisionnement des magasins de
données.
• Chaque magasin de données est conçu pour répondre à un enjeu métier. Les données y
sont structurées en fonction de la problématique traitée. Le stockage de données y est
généralement multidimensionnel.
27
d. L’exploitation de l’information : la restitution des données

C’est le bout de la chaîne. Il s’agit du point d’utilisation du système par les utilisateurs. La
satisfaction de ceux-ci dépend de la capacité des outils de restitution à répondre à leur besoin
en information et aide à la décision. Les types de restitution possible sont :
Reporting
Data
marts Cube analysis
Requêtage
Data warehouse
Data mining
Figure 2.2.6 : La restitution des données
2.3. Les modèles de données du datawarehouse
Un datawarehouse est une base de données. Ainsi, le modèle de données du datawarehouse

est le cœur du système décisionnel. La modélisation d’un système décisionnel nécessite des
approches spécifiques car l’utilisation dont ce dernier va faire l’objet différera radicalement
de celle des systèmes d’information plus classiques.
2.3.1. Caractéristiques d’utilisation : OLTP vs OLAP [Source : Kimball1999]

Les techniques couramment utilisées pour modéliser les données ont initialement été conçues
pour qu’elles s’adaptent à des problématiques qui n’existent pas dans le cadre d’un système
décisionnel.
Dans la mise en œuvre des systèmes d’informations, nous maîtrisons des approches centrées
sur des méthodologies telles que Merise. Dans leurs composantes liées à la modélisation des
données, ces méthodes sont précises, standardisées, puissantes et assez peu contestées. Le
modèle « entité-association » est le plus utilisé, permettant la création d’un modèle logique
relationnel. Toutes les théories liées à ces modèles sont largement utilisées dans les
entreprises.
Ces techniques sont apparues alors que l’informatique était destinée à l’automatisation des
processus à caractère transactionnel. Ces applications sont communément nommées OLTP.
28
Cependant, l’informatique de décision, que certains désignent par OLAP, justifie une remise
en cause des méthodes de conception d’un modèle de données.
Caractéristiques d’un contexte OLTP

Dans la plupart des systèmes transactionnels, le rôle d’un modèle est de garantir la persistance
des données. De fait, la base de données est conçue pour garder la trace d’événements
survenus dans l’entreprise.
Dans un contexte transactionnel, le modèle de données est destiné à minimiser les
redondances, pour préserver la fiabilité et la cohérence du système. Des concepts, tels que les
formes normales, les clés uniques, les clés étrangères ou de contraintes d’intégrité
référentielle, permettent de garantir constamment l’intégrité de la base de données. L’origine
de ce souci de minimisation des redondances découle principalement de ce que les systèmes
transactionnels effectuent leurs mises à jour en ligne, éventuellement au travers d’un
ensemble d’applications partageant le même modèle de données.
Dans un système transactionnel, la conception est orientée processus et le modèle de donnée
intervient en support de ceux-ci. De point de vue de l’utilisateur, le modèle de données est
totalement transparent.
Les requêtes sont toujours prévisibles car elles sont effectuées au travers d’une application le
plus souvent développée par la même équipe que celle qui a la charge du modèle de données.
Les données sont généralement accédées par des clés, notamment des clés uniques. Une
bonne indexation permet de garantir des temps de réponse dépendant davantage du volume de
données à traiter pour réaliser la transaction que du volume global de la base de données. Les
volumes de données qui doivent être accédés pour traiter une transaction ou retournés en
résultat de celle-ci sont limités. Il est très rare qu’une requête transactionnelle nécessite de
rassembler ou d’agréger des informations issues d’un grand nombre de tables.
Dans un monde décisionnel (OLAP)

Dans un contexte décisionnel, les requêtes sont complexes, les redondances plus difficiles à
maîtriser ; l’optimisation consiste à anticiper sur les chemins d’accès aux données qui sont
fréquemment employés plutôt qu’à faire des optimisations requête par requête.
Un Datawarehouse est une base dédiée au décisionnel. L’information est mise à la disposition
des utilisateurs mais les mises à jour ne sont jamais faites en ligne. Les seules mises à jour
effectuées sur le Datawarehouse émaneront des systèmes de production, lors des phases de
29
chargement (processus d’acquisition de données). Il devient donc envisageable d’introduire

des redondances, à condition de les maîtriser dans le processus d’alimentation.
Dans un contexte décisionnel, les requêtes manipulent régulièrement des ensembles. Elles
effectuent des sélections ou des restrictions de population, des regroupements, des calculs, des
agrégations, etc. Pour répondre aux besoins des utilisateurs, même si le résultat des requêtes
peut n’être constitué que de quelques lignes, il faudra très souvent manipuler des volumes
importants. Dès lors, obtenir des temps de réponse proportionnels au volume de données
résultat d’une requête est beaucoup plus difficile qu’en transactionnel.
Il convient d’optimiser les requêtes effectuées fréquemment en prédéfinissant physiquement
des sous-ensembles de données, moins importants en taille que les données plus détaillées,
mais suffisants pour résoudre les requêtes les plus courantes.
Une autre caractéristique du décisionnel veut que les utilisateurs cherchent à mettre en
relation des éléments qui a priori ne sont pas corrélés au départ. Pour y parvenir, des requêtes
complexes sont nécessaires, interrogeant un nombre important de tables. Face à cette
complexité, le Datawarehouse doit pouvoir réagir dans des délais raisonnables.
Un Datawarehouse vise à répondre aux besoins des utilisateurs en termes d’informations et
non en termes d’applications.
Dans un contexte décisionnel, du point de vue de l’administrateur de base de données, une des
plus grosses difficultés qui se posent est de gérer l’imprévisible. En effet, les requêtes sont le
plus souvent ad hoc, générées par l’utilisateur au travers d’un outil, et il est donc impossible
d’optimiser chacune de celles-ci au cas par cas.
La dernière caractéristique du monde Datawarehouse est qu’il permet le plus souvent de
mettre en place un modèle de données intégré, qui entend être transversal à l’entreprise. Ce
modèle se constitue le plus souvent de manière incrémentale, au fur et à mesure des
réalisations successives des projets décisionnels de l’entreprise.
2.3.2. Les techniques de modélisation [Source : Franco/Lignerolles2000]

Cinq axes permettent de qualifier un modèle de données décisionnel :
1. La lisibilité du point de vue de l’utilisateur final ;
2. Les performances au chargement ;
3. Les performances liées à l’exécution des requêtes ;
4. L’administration : ce n’est pas tant construire le Datawarehouse que le faire vivre qui pose
des problèmes aux entreprises. Il faudra tracer les requêtes et identifier celles qui sont
lancées fréquemment, maîtriser et industrialiser tous les processus d’extraction ;
30
5. L’évolutivité qui permet de faire en sorte que le développement d’un datawarehouse soit
incrémental, et pas seulement itératif : un développement itératif peut en effet amener à
définir plusieurs modules applicatifs, indépendants les uns des autres. Par développement
incrémental, l’intégration de chacun des modules doit être considérée dans la mise en
œuvre itérative, afin de s’assurer de ce que l’homogénéité globale du système est prise en
compte.
a. Le modèle de données normalisé

Soit le modèle de données normalisé présenté dans la page suivante :
En décisionnel, ce modèle permet par exemple de ventiler les chiffres d’affaires par produit,
par client, etc.
Ce type d’approche est courant dans les entreprises en matière de modélisation. Si le système
à mettre en œuvre permet à la fois des sélections et des mises à jour en ligne, elle est adaptée.
Dans un contexte décisionnel où les mises à jour en ligne ne sont pas d’actualité, sa pertinence
doit être reconsidérée.
D’un point de vue décisionnel, la sémantique de ce modèle est faible. Les informations
intéressantes pour l’utilisateur n’existent pas a priori, elles doivent être extrapolées. Les
indicateurs devront être recalculés dynamiquement à chaque requête.
Gamme Fournisseur
ID_Gamme ID_Fourn Pays
Libellé Nom Code_pays
Obj_marge … Libellé Client
ID_Client
Nom
Adresse
Produit Code_pays
ID_Produit Commande …
Nom ID_cde
Code_pays ID_exp
Caract. ID_Client
Prix HT Date
Expéditeur
Coût standard Remise_gale
ID_Exp
Code_pays
Nom
…
TVA LG_CDE
ID ID_cde
Date No_ligne
Taux ID_Produit
Quantité
Remise
Figure 2.3.1 : Le modèle de données normalisé
31
Le modèle est en revanche très complet. Il laisse une marge d’autonomie très forte à
l’utilisateur.
En réalité, un modèle d’entreprise pourra contenir des centaines ou des milliers d’entités, et
donc d’autant de tables au niveau physique. Une requête utilisera peut-être des dizaines de
tables et qui sera très complexe à formuler pour l’utilisateur et à traiter pour l’optimiseur de la
base de données. Les performances seront donc au mieux médiocres et pire inacceptables.
Dans des systèmes décisionnels simples, où un nombre réduit d’utilisateurs lancent peu de
requêtes sur un modèle de données de petite envergure, ce type d’approche peut fonctionner.
Dans les autres cas, il faut absolument recourir à d’autres techniques.
b. Dénormalisation pour le décisionnel

Cette approche vise à adapter le modèle précédent aux besoins liés au décisionnel. La
transformation consiste à dénormaliser et à précalculer certains agrégats, donc à introduire
des redondances.
Aucune technique formelle de dénormalisation n’existe dans le domaine public. L’approche
doit être pragmatique. Aboutir à un tel modèle découle d’une analyse précise des besoins des
utilisateurs. Ainsi, le modèle précédent devient :
Fournisseur
ID_fourn
Nom
Client
Pays
ID_client
...
Nom
Adresse
Produit Code_pays
ID_produit …
Gamme
CA année n-1 Commande
CA année n ID_cde
Provenance LG_CDE PHT
Coût standard ID_cde PTTC
ID_fourn No_ligne Expéditeur
PHT
Remise
PTTC
ID_prod
ID_client
Pays
Remise
Figure 2.3.2 : Le modèle dénormalisé
Remarquez que le modèle contient un nombre de tables plus restreint, chaque table étant
associée à un sujet d’intérêt. L’orientation « sujet » rapproche le modèle des besoins des
32
utilisateurs. Le modèle présente un certain nombre d’informations agrégées très fréquemment

demandées.
Ce modèle est moins complexe que le précédent. Le nombre de tables a été diminué d’un
facteur de 2. En appliquant le même facteur pour un modèle normalisé de 200 tables, on
aboutit à une centaine de tables, ce qui reste complexe et peu lisible.
Le gain en performance par rapport au modèle normalisé est également très relatif. Le nombre
de tables a diminué, donc aussi le nombre de jointures nécessaires pour les requêtes
décisionnelles. En contrepartie, les tables sont plus grosses. Ainsi, les requêtes seront plus
simples mais porteront sur des tables plus volumineuses.
c. La modélisation dimensionnelle
La modélisation dimensionnelle est une approche dédiée aux systèmes décisionnels. Elle part
du principe que l’objectif majeur de ce type de système est l’analyse de la ventilation de
données quantitatives (les faits) par rapport à des données qualitatives (les dimensions).
La modélisation dimensionnelle dérive des concepts qui ont amené à l’émergence des bases
de données multidimensionnelles, dites bases OLAP, il y a de cela plus de dix ans (1994). La
nouveauté est que ce type de modèle est indépendant de la technologie. Elle peut permettre
l’utilisation de toute base de données, qu’elle soit relationnelle, multidimensionnelle, objet…
L’objectif majeur d’un système décisionnel est l’analyse de la performance qui se matérialise
au travers d’un ensemble d’indicateurs. Ces indicateurs n’ont de sens que mis en relation avec
des dimensions d’analyse.
Les bases de données OLAP du marché sont des solutions conçues exclusivement pour créer
rapidement et exploiter les modèles de type multidimensionnel. Ils offrent à l’utilisateur des
outils sophistiqués, permettant de naviguer d’une dimension à une autre, de zoomer sur des
informations plus détaillées, etc.
Dans le modèle dimensionnel qui suit, les indicateurs de base sont groupés dans une table
centrale, dite table de faits. Une table de faits regroupe tous les indicateurs qui partagent le
même ensemble de dimensions et qui ne peuvent être déduits d’autres indicateurs.
33
Produit Fournisseur
ID_Produit ID_Fourn
Nom Table des métriques Nom
Gamme (Faits) Dept
Resp Type
Coût standard Nationalité
Dimensions
Packaging …
Couleur
Dimensions
Ventes
ID_prod
ID_fourn
JJ MM YYY
ID_client
Période Client
CA
JJ MM YYY ID_Client
Marges
Jour_sem Nom
Unités
Sem. mois Région
Sem. trimestre … Age
Sem. année …
Mois
Figure 2.3.3 : Le modèle en étoile
Ce type de modèle est nommé « modèle en étoile ». Au centre de l’étoile se trouve la table de
« faits ». L’identifiant de cette table de « faits » est une clé multiple composée de la
concaténation des clés de chacune des dimensions d’analyse.
Autour de cette table figurent tous les éléments caractérisant les dimensions d’analyse. Ces
caractéristiques sont regroupées dans des tables de dimensions.
Les plus grandes forces de ce type de modèle sont la lisibilité et la performance. La lisibilité
tout d’abord : ce modèle est très parlant pour l’utilisateur, et sa finalité est évidente. Il est
naturellement orienté sujet et définit clairement les indicateurs d’analyse. La performance
ensuite : les chemins d’accès à la base de données sont prévisibles. Il existe d’autres
techniques de modélisation multidimensionnelle dérivées de la modélisation en étoile,
notamment la « modélisation en flocon » ou « snowflake ». Le flocon est simplement une
étoile dont les branches sont elles-mêmes décomposées en sous-hiérarchies. Modéliser en
flocon, c’est donc conserver le cœur du modèle en étoile, à savoir les tables de faits et affiner
la modélisation des tables de dimensions pour les éclater en sous-tables.
Ce type de modélisation est intéressant à deux points de vue. D’une part, il normalise les
dimensions, réduisant la taille de chacune des tables. D’autre part, ce modèle permet de
formaliser la notion de hiérarchie au sein d’une dimension. Un autre avantage du flocon, c’est
qu’il normalise les dimensions en éliminant les redondances qui pourraient s’y produire.
34
Couleur
ID_coul Fournisseur
Nom ID_fourn
Nom
Dept
Chef
ID_type
produit Produit
ID_cp
ID_Orig
ID_produit …
Nom Ventes
ID_famille
Prénom
Remarque ID_cp ID_prod
ID_couleur ID_fourn
Désignation
Type Origine
JJ MM YYY ID_type ID_orig
Coût standard ID_client Nom Nationalité
CA
Marges
Gamme Activité Unités
ID_gamme ID_famille Région
Nom …
ID_gamme ID_région
Fourchette Fourchette
prix Nom
prix Client
ID_client
Nom,…
Mois
MM
ID_région
ID_activité
Nom Période
ID_segment Activité
JJ MM YYY
Saison Code_jour … ID_activité
ID_saison ID_semaine Désignation
Nom
Remarques
ID_mois
Année Semaine Jour_sem Segment

ID_année ID_semaine Code_jour ID_segment
Remarques Semaine Nom Segment
Figure 2.3.4 : Le modèle en flocon
2.4. Le système datawebhouse [Source : Kimball/Merz2000]
2.4.1. L’impact du Web sur le datawarehouse

Au cours ce cette décennie, avant que la révolution Web prenne de la vitesse, les
organisations informatiques ont appris à publier les actifs en données de l’entreprise à
destination des analystes internes et du management. Cet acte de publication est la tâche
centrale du datawarehouse. Une décennie d’expérience dans la datawarehouse permet de
comprendre avec une relative maturité sa nature et la manière dont les services informatiques
peuvent amener les techniques à soutenir la publication de toutes ces données.
La révolution du Web n’a certainement pas remplacé le besoin du datawarehouse. En fait, elle
a accru chez tout un chacun une attente de voir publiées toutes sortes d’informations de
manière transparente sur les interfaces des navigateurs Web. L’auditoire des données du
35
datawarehouse a crû, partant des directions internes pour englober les clients, les partenaires
et un groupe plus large d’employés internes. Le fait que le Web se concentre sur
l’ « expérience client » a rendu de nombreuses entreprises plus conscientes du fait qu’elles
devaient connaître leurs clients et leur donner des informations utiles.
La révolution du Web a propulsé le datawarehouse sur le devant de la scène, car dans de
nombreux cas, il doit être le moteur qui contrôle ou analyse la pratique du Web. Pour se
conformer à ces responsabilités plus importantes, le datawarehouse doit s’ajuster. Sa nature
doit être quelque peu différente de ce qu’elle a été ces dix dernières années.
Figure 2.4.1 : Le client, le site Web et le datawebhouse [source : Kimball/Merz2000]
Nous appelons cette renaissance de datawarehouse le datawebhouse.
2.4.2. Les objectifs du datawebhouse
Le datawebhouse est la représentation Web d’un datawarehouse. Il joue un rôle crucial et

central dans l’exploitation d’une activité compatible avec le Web. Pour répondre à ses
promesses, le datawebhouse :
• héberge et publie les données du « Clickstream » et d’autres données comportementales

provenant du Web qui induisent une compréhension du comportement du client ;
• est mis en conformité avec les autres datamarts distribués de datawarehouse de

l’entreprise et ceux situés en amont et en aval de la chaîne d’approvisionnement pour
qu’ils puissent être utilisés ensemble ;
36
• est une source d’informations adaptative et élastique. Lorsque de nouvelles questions de

gestion se posent et au fur et à mesure que de nouvelles sources de données deviennent
disponibles, il est essentiel que le datawebhouse réponde avec grâce, c’est-à-dire en
permettant aux anciennes applications de s’exécuter sans interruption et sans besoin de
reprogrammation, tout en leur permettant de coexister avec les nouvelles questions et les
nouvelles données ;
• est extensibles aux nouveaux médias du Web, que ce soit les images fixes, les
graphiques, le son et la vidéo ;
• est un bastion de sécurité qui publie des données à destination des clients, des
partenaires commerciaux et des employés de manière appropriée, mais qui, dans le
même temps, protège les actifs en données de l’entreprise contre une utilisation non
prévue ;
• est la base de toute aide à la décision liée au Web. Répétons que le datawebhouse doit
permettre à ses utilisateurs de prendre des décisions concernant le Web et son utilisation.
2.4.3. De et vers le Web

Comme nous allons le voir, le datawebhouse a deux facettes :
Figure 2.4.2 : Les deux facettes du datawebhouse [source : Kimball/Merz2000]
La première décrit comment associer les technologies Web au datawarehouse. Le Web est une
immense source de données comportementales : les individus, en effet, interagissent avec leur
37
navigateur sur des sites Web distants. Si les données de ce flux continu de clics (le
Clickstream) sont bien souvent brutes et simples, elles constituent néanmoins potentiellement
une source d’informations jusque là inégalées sur les actions effectuées par les individus
utilisant le Web.
Associer les technologies Web au datawarehouse, c’est alimenter le datawebhouse avec cette
source de données considérable et indiscipliné, afin de les analyser, mais aussi de les mettre
en conformité et les conjuguer aux sources de données plus conventionnelles.
Le second aspect du datawebhouse, concerne l’apport du datawarehouse existant vers le Web.

Amener le datawarehouse au Web signifie rendre toutes les interfaces du datawarehouse
disponibles sur des navigateurs Web.
Amener le datawarehouse au Web signifie aussi résoudre, une fois pour toutes, les problèmes
d’un environnement entièrement distribué. Le datawebhouse est une approche totalement
différente du datawarehouse entièrement centralisé, car, pas plus que l’Internet, il ne peut être
centralisé.
2.4.4. Amener le Web au datawarehouse

a. Les données du Web
Comme présenté dans les sections précédentes, le datawarehouse (traditionnel) est alimenté
par les systèmes de traitement transactionnel OLTP. Dans un environnement datawebhouse,
nous disposons d’une nouvelle source d’alimentation encore insaisissable : capturer, analyser
et comprendre le comportement des utilisateurs qui naviguent sur les sites Web.
Le Clickstream est une suite chronologique d’actions atomiques qui peuvent être regroupées
en sessions. La trajectoire des actions ayant aboutit à un achat, par exemple, peut être
analysée et comprise. Nous pouvons désormais savoir comment un individu nous a contactés,
de ses intentions et de la qualité de son expérience. Nous pouvons savoir précisément l’écran
qu’il a vu et le temps qu’il a mis à faire ses choix. Nous pouvons observer des signes directs
de satisfaction ou d’insatisfaction. Nous nous trouvons donc dans une meilleure position pour
répondre efficacement au client individuel.
b. Création des datamarts du Clickstream

La création d'un datamart demande des connaissances de modélisation dimensionnelle. Les
dimensions auxquelles nous pouvons penser qui ont un sens (répondant à certaines questions)
dans un environnement de Clickstream sont en général de ce type :
38
Dimension page: (URL), Dimension date ;

Dimension agent de l'utilisateur, Dimension session ;
Dimension état du caddie de l'utilisateur, Dimension démographique.
Le modèle du datamart est le suivant :
Figure 2.4.3 : Exemple de datamart du Clickstream [source Kimball/Merz2000]
2.4.5. Amener le datawarehouse au Web

Publier sur le Web
Le datawarehouse est l’endroit où sont publiées les données stratégiques de l’entreprise. Le
gestionnaire de datawarehouse est une sorte de rédacteur en chef : il rassemble les entrées de
données provenant d’une grande diversité de sources qui sont ensuite réparties sur la « table
de composition » ; leur pertinence et leur exhaustivité sont alors évaluées. Puis, elles sont
enregistrées sous un format commun et reconnaissable, et publiées à l’attention des lecteurs
(utilisateurs finals) du datawarehouse.
A la fin des années 1990, l’arrivée du Web a favorisé l’essor du datawarehouse. Le Web
amplifie et étend ses possibilités de publication ; il offre de nombreux avantages que
l’industrie du datawarehouse n’aurait pas pu créer par elle-même. Le Web est tellement
irrésistible que le datawarehouse n’a pas d’autre choix que de monter dans ce train express.
39
2.5. La gestion du « temps » dans le datawarehouse [Source : Todman2001]
Remarque : Le terme « Temps » est utilisé ici et dans le reste de ce mémoire dans le sens
donnée « Date/heure ».
Un des points les plus importants dans le processus de conception des datawarehouses est la
représentation et le traitement des données temporelles (données sur le « Temps »).
L’importance des données temporelles est une des caractéristiques des systèmes décisionnels
qui les différencient des systèmes opérationnels. Nous allons essayer dans ce qui suit
d’introduire les caractéristiques du « Temps » et son utilisation dans les datawarehouses.
Les applications de gestion d’entreprise qui constituent le système opérationnel sont
développées pour fonctionner dans l’environnement présent où les données temporelles ne
nécessitent pas un traitement particulier. Dans plusieurs cas, ces données « Dates/Heures » ne
sont que des attributs descriptifs dans les tables des données.
Mais dans un datawarehouse, le « Temps » affecte considérablement la structure du système.
Les caractéristiques et les objectifs des datawarehouses engendrent des besoins en données
temporelles qui sont différents de ceux du système opérationnel.
En l’absence actuel de SGBD temporels où le support des données temporelles serait implicite
et où le langage de requête contiendrait des fonctions spécifiques sur le « Temps » afin d’en
simplifier la manipulation, les bases de données datawarehouses doivent être conçues pour
prendre en considération les besoins temporels et être implémentées sur des SGBDR
classiques. En d’autres termes, le support du « Temps » doit être explicitement intégré dans les
structures des tables et des requêtes.
2.5.1. Le rôle des données temporelles

Dans un datawarehouse, l’ajout des données temporelles (les données « Date/heure ») permet
d’historiser (archiver) les données. Cela signifie que les utilisateurs du datawarehouse peuvent
découvrir l’aspect de leur entreprise à n’importe quel moment ou période dans le temps. Ceci
permettra la découverte et l’étude des habitudes comportementales dans le temps et de faire
des comparaisons entre des périodes similaires ou non-similaires. Avec ces données, nous
pouvons réaliser des extrapolations en utilisant des modèles prédictifs afin de nous assister à
planifier et à prévoir. Ainsi, nous utiliserons le passé pour essayer de prévoir le futur.
40
La valeur et l’importance des données historiques sont généralement reconnues. La capacité

de stockage des données historiques est un des avantages majeurs des datawarehouses et
l’absence de ces données dans les systèmes opérationnels est un des facteurs de motivation
pour le développement des datawarehouses.
a. Période de validité et date de transaction

Ces deux notions seront utilisées plusieurs fois dans le chapitre 3 (Conception d’un
datawarehouse orienté CRM).
La date de validité associée à une valeur d’un attribut de donnée représente la date pendant
laquelle cette valeur est « vraie » (associée) pour cet attribut. Par exemple, la date de validité
d’une commande correspond à sa date de réception. Ces valeurs d’attributs peuvent être
associées :
• A un instant donné : définis comme une combinaison unique « Date/Heure ». Un
évènement est défini comme étant un fait instantané survenant à un instant « t ».
• A une période de temps : définie comme étant le temps entre deux instants.
La date de validité est normalement fournie par l’utilisateur sauf dans des cas particuliers
comme dans les appels téléphoniques où la date de validité peut être générée par les
équipements techniques.
La date de transaction associée à une valeur d’attribut de donnée représente la date de la
création (physique) et de la disponibilité de la valeur dans la base de données. Les dates de
transaction sont générées par les SGBD. Les dates de transaction peuvent aussi être
représentées par des instants uniques ou des intervalles de temps.
b. Les données comportementales

Dans un datawarehouse dimensionnel, les systèmes sources des données comportementales
sont les systèmes de gestion opérationnels tels que les systèmes de facturation ou les systèmes
de gestion logistique. Comme nous l’avons déjà expliqué, les systèmes opérationnels ne sont
pas conçus pour « historiser » les données. Par exemple, dans un système de gestion des
commandes, une fois qu’une commande est satisfaite et transformée en facture, elle disparaît
de la base de données opérationnelle après une certaine période de temps (un maximum d’une
année).
Le rôle d’un système datawarehouse est de capturer les données appropriées qui ont atteint un
certain état leur permettant d’intégrer la base de données du datawarehouse. Les données
d’une entité sont généralement intégrées au datawarehouse à la fin du cycle de vie
41
opérationnel de cette entité. Par exemple, les données sur une commande sont intégrées
lorsque l’état de celle-ci devient « facturé ». À ce moment, le montant facturé devient un
« fait » dans le datawarehouse. Une fois chargée, la donnée « fait » ne changera jamais.
L’enregistrement des données comportementales dans les tables de faits est réalisé par des
insertions continuelles des données en provenance des systèmes sources.
Généralement, chaque « fait » est associé à un attribut « Temps » unique (une combinaison
« Date/Heure ») relatif à la constatation de l’évènement. Cet attribut « Temps » correspond,
dans l’idéal, à la date de validité du « fait ». En pratique, la date de validité n’est pas toujours
disponible et est remplacée par la date de transaction générée par le SGBD.
c. Les données sur les circonstances

Les systèmes opérationnels gèrent des données de référence qui se rapportent à des entités
telles que : les clients, les produits, les régions, etc. Ces données sont utilisées pour alimenter
les dimensions du datawarehouse. Ce sont les données de circonstance (Voir chapitre 3).
Ces entités de référence possèdent un cycle de vie qui est différent du cycle de vie des
transactions organisationnelles. Le cycle de vie d’une entité de référence n’est pas toujours
clair et peut, parfois, être discontinue. Cela s’applique particulièrement pour l’entité
« Clients » (Clients qui changent souvent leurs fournisseurs) ou aussi l’entité « Produits »
(Produits saisonniers). Certains attributs d’entités peuvent avoir aussi un cycle de vie
discontinu (changement d’adresses, d’employeur, etc.). Le traitement de ces données de
circonstance, y compris leurs attributs « Temps », est important pour notre solution
datawarehouse. Dans le chapitre 3, nous allons expliquer l’importance des données sur les
circonstances et proposer des solutions d’implémentation.
2.5.2. Les problématiques liées au « Temps »

Voici en résumé, quelques problématiques liées aux données temporelles qu’il faut résoudre
lors de la conception d’un système datawarehouse.
• Identifier et capturer les besoins temporels : la première problématique est
d’identifier les besoins en données temporelles. Il n’existe pas actuellement de
méthodes pour la résoudre. Les techniques actuelles de modélisation des
datawarehouses ne fournissent pas un réel support à cette problématique.
• Capturer les changements dimensionnels : Qu’est-ce qui arrive lorsqu’une relation
change (ex. : un commercial qui change de département) ? Qu’est-ce qui arrive
42
lorsqu’une relation cesse d’exister (ex. : un commercial quitte l’entreprise) ? Comment

le datawarehouse manipule-t-il ces changements dans les valeurs d’attributs (ex. : un
produit était bleu, il est maintenant rouge) ? y a-t-il un besoin d’analyser ces
performances de vente lorsqu’il était rouge ou bleu ?
• La fréquence des captures : Un datawarehouse doit être à jour. La fréquence des
changements est une question à laquelle il faut répondre durant la conception d’un
datawarehouse.
• La synchronisation des changements : Quant un attribut change, un mécanisme doit
se déclencher pour déterminer les attributs dépendants qui doivent aussi changer.
L’absence de synchronisation affecte la crédibilité des résultats.
Certaines problématiques liées au « Temps » sont inhérentes aux modèles dimensionnels mais
il est possible de les surmonter en changeant la méthode de conception de ces modèles.
2.5.3. Le « Temps » dans la première génération des datawarehouses

Le « Temps » a un effet considérable sur les datawarehouses car ces derniers sont des
applications temporelles. La propriété temporelle des datawarehouses n’a jamais été
réellement reconnue dans la première génération des datawarehouse et, par conséquent, la
représentation du « Temps » était, dans la plupart des cas, non adéquate. Dans les modèles
dimensionnels, la représentation du « Temps » est largement restreinte à la dimension
« Temps ». Cela permet à la table des faits d’être partitionnée en utilisant cette dimension
mais ne permet pas une représentation du « Temps » dans les autres dimensions.
L’arrivée du CRM a soulevé le problème et a renforcé le besoin d’adopter une approche
systématique de traitement du « Temps ». Afin de pouvoir concevoir et construire un
datawarehouse orienté client (CRM) qui est capable d’assister les décideurs à résoudre leurs
problématiques CRM (ex. : la fuite des clients), nous devons s’assurer que les problématiques
liées à la représentation du « Temps » sont proprement traitées. La première génération des
datawarehouses (présentée dans ce chapitre) peine pour répondre à des questions orientées
CRM du genre « Combien de clients avons-nous actuellement ? ». Avec ce genre de capacité
limitée, il est impossible d’avoir des métriques ou des mesures en relation avec les
changements dans les circonstances.
Dans un environnement CRM, nous devons être capables de soumettre des requêtes
temporelles qui nous permettront d’analyser les changements dans les circonstances (données
43
de référence) des clients. Ce type de requêtes n’est pas supporté par les datawarehouses de
première génération.
Nous pouvons ainsi conclure que dans la première génération des datawarehouse, les attributs
des dimensions sont réellement considérés comme des attributs supplémentaires des faits.
Quand nous réalisons une jointure entre la table des faits et une table dimension, nous ne
faisons que juste étendre les attributs des faits avec ceux de la dimension.
La deuxième génération des datawarehouses, les datawarehouses orientés CRM, proposent

une autre vision pour le traitement des besoins temporelles. C’est ce que nous allons découvrir
dans le chapitre 4.
44
Chapitre 3
La gestion de la relation client
n Gestion de la relation client : définitions, objectifs et résultats ;

n Le développement de la relation client ;
n Les fonctionnalités des systèmes de gestion de la relation client ;
n La technologie du datawarehouse au service de la gestion de la
relation client.
Le CRM : Customer Relationship Management
2. Le CRM : Customer Relationship Management
3.1. Introduction au CRM

Dans les années 1970, la domination des producteurs était flagrante. Ces derniers
s’intéressaient peu de savoir quels clients achetaient et utilisaient quels produits. Aussi
longtemps qu’il y avait assez d’acheteurs, la production était le goulot d’étranglement. Les
clients étaient forcés de s’orienter d’après les biens produits. ‘Henry Ford’ avait pour
habitude de répondre à la question du nombre de couleurs disponibles pour ces voitures :
‘Naturellement nous produisons chaque couleur pour autant qu’elle soit noire’. [Dyche2002]
Au tournant du siècle, la situation s’est retournée. Nous sommes passés d’un marché de
l’offre à un marché de la demande. Ce retournement exige des changements à tous les niveaux
de l’entreprise, entre autres des activités marketing et vente qui doivent être soutenues plus
systématiquement par des systèmes d’information et des bases de données.
Nous le voyons, les entreprises sont en transition ; nous passons d’une organisation tournée
vers l’offre, donc orientée produits, pour nous diriger vers des structures orientées sur les
processus à accomplir dont le CRM est un exemple.
Cependant, il ne faut pas oublier que l’objectif d’amélioration de la relation client est un
objectif louable pour autant que l’on sache quelle relation améliorer et cela en fonction de la
profitabilité des relations; afin de mieux cerner l’étape de base qu’est la profitabilité du client,
le concept de « Customer Lifetime Value » reste l’étape de base de toute démarche CRM.
3.1.1. Définition du CRM

CRM est un acronyme pour « Customer Relationship Management », en français GRC pour
« Gestion de la Relation Client ».
CRM est un terme de l’industrie des systèmes d’information englobant des méthodologies,
des stratégies, des outils logiciels et habituellement des capacités internet qui aide une
entreprise à gérer ses relations client d’une manière structurée. [Source : Swift2003]
Par exemple, une entreprise pourra construire une base de données clients qui décrit les
relations avec suffisamment de détails afin que la direction, les vendeurs, les responsables du
service-clients et idéalement les clients eux-mêmes puissent avoir accès à l’information pour
effectuer des tâches comme le rapprochement entre les besoins des clients et les planifications
produits, la génération d’offres, et la description du profil des clients.
46
Mieux gérer les clients n’est pas un concept nouveau; il suffit pour s’en convaincre de
considérer les systèmes de rabais mis au point dans les années 1960 afin de fidéliser les
clients. Les outils par contre sont nouveaux ; au lieu de prendre des décisions stratégiques
basées sur leur propre expérience, les managers utilisent des outils logiciels spécifiques pour
prendre ou valider ces dernières.
Selon différentes vues de l’industrie, le CRM peut consister à :
• Permettre à un département marketing d’une entreprise d’identifier et de viser ses
clients les plus profitables, à gérer les campagnes marketing avec des objectifs clairs
afin de générer des « leads » de valeur pour la force de vente.
• Aider l’organisation dans l’amélioration du « telesales », « account » et « sales
management » en optimisant le partage de l’information par les multiples intervenants
et en simplifiant les processus existants.
• Favoriser le développement de relations individualisées avec les clients dans le but
d’améliorer la satisfaction client et de maximiser les profits.
• Fournir aux employés les informations et les processus nécessaires pour mieux
connaître leurs clients, leurs besoins et bâtir des relations durables entre la société, les
clients et les partenaires. [Source : Swift2003]
Examinons la figure suivante :
Figure 3.1.1 : L’évolution des composantes d’entreprise. [Source : Flueckiger2000]
47
La figure ci-dessus montre l’évolution des différentes composantes de l’entreprise tendant

vers des modèles de travail collaboratifs non seulement intra-entreprise mais aussi inter-
entreprises.
Le terme CRM s’est développé rapidement durant ces dernières années et comporte
actuellement de nombreuses fonctions associées pour un service clients supérieur.
Le CRM est un concept plus complet que son prédécesseur SFA – Sales Force Automation –
qui se bornait à soutenir la mission du représentant en contact avec le client dans la prise de
commandes principalement. Le CRM a pour but d’élargir le concept de SFA par un partage
des informations client au sein de la structure et une interface avec le système de gestion
interne de l’entreprise ERP.
3.1.2. Les objectifs du CRM

Une tendance très nette se dessine dans la fixation des objectifs des projets CRM. Même si
l’augmentation de la productivité de la force de vente reste l’objectif traditionnel principal, les
entreprises remarquant que le produit ne fournit plus à long terme un avantage concurrentiel
mettent de plus en plus l’accent sur l’amélioration de la relation et des services offerts au
client autour du produit.
Cette nouvelle manière de vendre exige de l’entreprise qu’elle donne plus d’autonomie à sa
force de vente et que les systèmes d’information soutiennent les vendeurs ou « marketers »
dans cette nouvelle approche.
L’approche globale du client devient aussi de plus en plus au centre des stratégies, tout
particulièrement dans les situations où l’approche multicanaux est développée. Le but du
CRM sera d’intégrer les fonctions isolées de la chaîne de la relation client.
Le graphique ci-dessous illustre les résultats d’une enquête menée auprès d’entreprises ayant
effectué des projets CRM. Cette enquête montre les objectifs CRM visés par l’implémentation
d’une solution CRM dans ces entreprises. [Source : Flueckiger2000]
48
Remarquons par exemple que 50% des entreprises ayant implémenté une solution CRM se sont fixées comme
Figurel’amélioration
objectif 3.1.2 : Les objectifs du CRM.des
de la satisfaction [Source
clients : Flueckiger2000]
3.1.3. Les résultats constatés avec le CRM

Examinons le graphique ci-dessous :
Figure 3.1.3 : Les résultats du CRM. [Source : Flueckiger2000]
49
Les chiffres ci-dessus récoltés auprès d’entreprises allemandes ayant mené des projets CRM
montrent les augmentations ou les diminutions par poste en pourcentage. Par exemple, nous
remarquons que ces entreprises ont constaté une augmentation du taux du succès des offres de
8% et une diminution du taux de réclamation de 5%. [Source : Flueckiger2000]
On peut en retenir que, même si le CRM a toujours pour but, parfois non-avoué, d’adapter la
structure des coûts de la société, les éléments qui visent le développement des ventes et de la
profitabilité deviennent des éléments de plus en plus importants.
3.2. Les facteurs du CRM

Le CRM prend forme en tirant parti du potentiel des composantes humaines,
organisationnelles et technologiques à disposition.
3.2.1. Le facteur humain

Les affaires comportent toujours et encore une relation d’homme à homme. Le CRM doit
placer l’être humain au centre des préoccupations, que ce soit le client, le collaborateur ou le
partenaire. De nombreux projets par le passé ont échoué du fait que l’aspect technologique
était prépondérant au détriment du facteur humain.
La base pour une relation d’affaires à long terme et pleine de succès est toujours et encore la
communication entre une entreprise et son client et vice versa.
Pour le client, toute personne avec qui il est en contact représente et personnifie l’entreprise.
L’attitude du collaborateur va donc influencer directement le client potentiel ou existant.
Il est donc essentiel que les collaborateurs, et tout spécialement ceux en contact direct avec les
clients, comprennent les buts du CRM et par là la stratégie de l’entreprise. Pour s’occuper de
leurs clients de manière ciblée, ils devront donc connaître leurs missions et leurs compétences.
Cependant, cette plus grande marge de manoeuvre gagnée par les collaborateurs qui
répondent de leurs actes ne va pas sans poser de questions; en effet, les situations où les
compétences sont limitées par la structure apportent une situation de confort non négligeable ;
le changement d’état entraînera auprès de la structure des mécontentements qu’il s’agira de
gérer en mettant sur pied des programmes d’accompagnement au changement pour mieux
canaliser ces rebellions. [Source : Freeland2002]
50
3.2.2. Le facteur organisationnel

Le processus est compris comme une suite logique d’activités qui contribuent à la stimulation
d’un résultat.
Du point de vue de l’entreprise, il existe trois types de processus fondamentaux :
• Le processus de développement de nouveaux produits : Cela comporte toutes les
activités qui permettent de lancer de nouveaux produits dans un temps, une qualité et
un prix définis par la stratégie de l’entreprise.
• Le processus de génération et de livraison des commandes : Cela comporte
l’acquisition et l’acceptation des commandes, la livraison à temps des commandes, la
production d’une facture et son encaissement.
• Le processus de la chaîne logistique intégrée : Comporte toutes les activités qui
assurent de manière optimale les flux monétaires, matériels et informationnels en
respectant les délais, les contraintes financières et le niveau de qualité fixé.
Plutôt que de réaliser ces processus de manière fragmentée et fonctionnelle, les départements
doivent être mis en relation selon des chaînes consistantes de manière à assurer la satisfaction
des clients.
Des flux d’informations des produits et des clients, traversant les différentes fonctions,
doivent venir alimenter les personnes qui pourront en avoir besoin. Alors que le client
s’adresse à l’entreprise par le biais d’un point d’interaction, ses besoins ont une influence qui
vont au-delà du point d’interaction et qui vont toucher la production, la logistique et les
finances.
L’exemple des sociétés de service est flagrant ; en effet, ces sociétés étaient auparavant
organisées par divisions de produits, ce qui signifie que chaque division abordait le client de
manière autonome, donc développait ses connaissances client ainsi que son système de base
de données de manière indépendante. Les pressions concurrentielles ont amené les banques,
par exemple, à introduire le principe du « key account » management qui traite les besoins du
client dans sa globalité, même si par la suite, en toile de fond, les tâches sont re-divisées sous
forme de spécialités. Cette évolution a été facilitée par les évolutions des possibilités offertes
par les systèmes d’information.
Une optimisation des processus n’est possible que si seulement l’organisation interne de
l’entreprise est structurée de manière à répondre aux besoins des processus. [Source :
Freeland2002]
51
3.2.3. Le facteur technologique

La technologie joue un rôle important dans la mise en place d’un système CRM. Elle sert à
soutenir certains processus afin que les collaborateurs puissent se concentrer sur les tâches où
ils apportent la plus grande valeur ajoutée.
La technologie offre au client la possibilité de communiquer avec l’entreprise de plusieurs
manières ( multichanelling ) ; que ce soit par téléphone, fax, ou email, une relation peut être
construite indépendamment de la distance géographique.
L’Internet a des conséquences profondes sur la refonte des processus de travail de
l’entreprise. Alors que la part du chiffre d’affaires générée par ce canal de vente reste pour la
plupart des entreprises encore modeste, la manière dont les informations peuvent être
échangées ou réparties, est en train d’offrir aux entreprises d’énormes opportunités soit en
termes de gain de productivité ou sous forme de potentiel de développement (Voir le chapitre
2.4 : le système datawebhouse).
L’Intégration des systèmes d’information en vue de l’optimisation des processus
Les architectures IT ont cru de manière disparate et sont basées sur des applications diverses
provenant de langages de programmation différents. Ce qui signifie que les informations sont
gérées de manière non coordonnées avec des bases de données pouvant être tenues, soit sur
des feuilles de papier jusqu’aux applications multidimensionnelles. Les informations
remplissent les besoins en informations des différents départements mais ne sont pas à la
disposition de l’entreprise de manière unifiée.
Les données informationnelles en provenance des ventes, des stocks, des fournisseurs
devraient être disponibles pour tous ceux qui peuvent créer de la valeur avec.
Alors que l’implémentation technique afin d’intégrer ces bases de donnes ne pose pas de
problèmes insurmontables, la plus grande difficulté réside dans la détermination et la
coordination des flux d’information pour assurer que les informations soient à disposition des
intervenants en temps voulu.
Le but ultime de l’intégration des bases de données est la création d’un point unique de
contact « SPOI – Single Point Of Information » qui pourra être réalisé grâce à la réalisation de
différentes interfaces. Par exemple, les différentes informations clients rassemblées dans les
différents canaux d’interactions sont rassemblées et coordonnées de manière unifiée afin que
ces informations puissent être remises à disposition des autres acteurs de la structure interne
ou externe par le biais du SPOI. [Source : Freeland2002]
52
3.3. Le cycle de vie du client

La gestion de la relation client se représente aisément par un cycle de vie :
Tout commence par un client potentiel intéressé par les produits ou les services de
l’entreprise. Après un premier achat, le client potentiel devient un client réel. L’étape suivante
est la création de lien durable avec le client à travers des achats successifs, ce qui signifie
l’offre constante de nouveaux produits « cross-selling », le but étant de faire constamment
augmenter le chiffre d’affaires généré par le client en le fidélisant. En fin, le client interrompe
un jour sa relation avec l’entreprise. Cette interruption peut être graduelle ou subite.
Durant le cycle de vie d’un client, le système CRM doit pouvoir aider l’entreprise à réactiver
ses clients « dormants » : « Sont-ils momentanément non intéressés ou sont-ils globalement
mécontents et donc sur le point d’être perdus ? »
Afin d’atteindre ce but, il est essentiel de pouvoir déterminer dans quels segments de clientèle
des actions de réactivation valent la peine et de définir les mesures à effectuer.
Pour exécuter cette mission, le département marketing nécessite des profils clients détaillés et
tenus à jour. Ces informations sont en général déjà disponibles dans l’entreprise dans des
systèmes séparés et sous des formes différentes; le système CRM a pour mission de
consolider ces données pour pouvoir les utiliser de manière opérationnelle. [Source :
Todman2001]
3.4. Le développement de la relation client
3.4.1. Les étapes du développement

a. La relation de voisinage (- => 2000)
Cette relation était caractérisée par les commerces de voisinage. La pression effectuée par les
grands groupes de la distribution disposant d’organisation d’achat centralisée et d’un concept
global a fait disparaître les petits commerces où la composante relationnelle était un élément
du marketing déterminant.
La disparition de ce type de relation se trouve à différents stades selon le secteur économique
ou la région géographique du globe.
53
b. Le push marketing (1950 => 1985)

Apparu dans les années d’après-guerre, le push marketing était lié à la production de masse
qui avait pour but de répondre à la demande massive pour des produits peu compliqués. Dans
un deuxième temps, les entreprises se sont concentrées sur l’élargissement de l’offre.
c. La segmentation (1970 => 2000)

Les années 70 sont les années de consolidation. Les sociétés cherchent avant tout à
rationaliser les coûts de production. Le client n’apparaît plus comme un consommateur de
masse, mais la segmentation fait son apparition.
d. Le service et la qualité (1980 => 2000)

Dans les années 80, les sociétés doivent développer des concepts de qualité et de services
autour des produits afin de pouvoir se différencier de la concurrence.
Après s’être focalisée sur l’offre, les entreprises commencent des programmes de stimulation
de la demande.
e. La relation client (1995 => 2000)

Depuis le début des années 90, les entreprises remarquent qu’il devient quasi impossible de
différencier leur offre de la concurrence. Une solution réside dans l’utilisation des
informations relatives au client afin de développer des offres ciblées qui correspondront aux
besoins réels du client ; on parlera ici du « one to one marketing ». Ce nouveau type de
relation est fortement promu par l’avènement des technologies Internet qui permettent un
échange d’informations constant entre les entreprises et le client. [Source : Dyche2002]
3.4.2. Les raisons de la prédominance de la relation client

a. Une croissance ralentie
Il est commun de mentionner que les produits vendus actuellement ne se différencient plus de
par leur qualité qui est en principe à la hauteur des attentes des consommateurs qui ont eux-
mêmes amélioré leur capacité à sélectionner et leur formation à l’utilisation des produits. Ces
facteurs ont pour conséquence de prolonger le cycle de vie des produits et de réduire le taux
de renouvellement.
54
Une pyramide des âges à la base de plus en plus fragile contribue avec les facteurs
mentionnés ci-dessus à créer des situations de saturation des marchés et pousse les sociétés à
trouver des solutions de diversification.
b. Une offre banalisée

Les années 90 ont vu les entreprises se concentrer sur l’optimisation des processus internes
entre autres par les « Business Process Reenginering » ainsi que l’implémentation des
systèmes de gestion intégrés ERP. Bien que le but de réduction des coûts ait été largement
atteint, ces différentes opérations ont amené les entreprises à travailler de manière
standardisée et par là à produire de manière plus ou moins standard, ce qui pose le problème
de la différenciation.
c. Les clients de plus en plus exigeants

Dans l’ère pré-industrielle, les produits étaient fabriqués par des artisans et directement
vendus par ces derniers qui connaissaient donc les goûts et les besoins de leurs clients de par
la proximité qui prévalait.
Dans l’ère industrielle, les produits sont fabriqués en masse afin de répondre à des besoins
standards ; de plus, la montée en puissance des distributeurs allongent le chemin entre le
fabriquant et le consommateur.
Aussi la globalisation amène le consommateur à avoir le choix entre des produits en
provenance des différentes régions du globe. Les sociétés se rendent compte qu’il ne leur est
plus possible de se différencier par leur offre produit, mais qu’elles doivent soit bâtir un
portefeuille de marques qui leur permettent de vendre leurs produits avec un premium et/ou
offrir des services accompagnant le produit. Cependant, même ces méthodes ne permettent
bientôt plus aux entreprises de se développer ; elles doivent à nouveau porter leur attention
non plus sur l’offre mais sur la demande, soit le client, d’où le développement des stratégies
basées sur la relation client. [Source : Dyche2002]
Dans la course à la différentiation, les entreprises ont mis au point les options suivantes :
• Rendre la vie du client plus facile
La valeur pour le client n’est plus seulement créée par le produit ou le service en lui-même
mais par le fait que ce produit peut être disponible dans de multiples canaux et dans une
fenêtre temps plus large. Pour l’entreprise, il est logique que, plus l’acte d’achat est facile,
plus la probabilité de générer une vente est grande.
55
Il est donc important pour les vendeurs de repousser constamment les variables temps et
espace, ce qui peut aller à l’encontre d’une relation personnalisée.
• Multiplier les tentations d’achat
Les entreprises démultiplient leurs promotions en offrant des packages différents à des prix
différents dans des canaux différents. Ces actions sont lancées de manière centrale mais
peuvent très bien être taillée sur les besoins de chaque client afin de répondre à ses besoins
potentiels définis.
Cependant, la multiplication des actions promotionnelles peut aussi entraîner auprès du
consommateur une sorte de saturation qui aurait des conséquences négatives sur la marche des
affaires.
• Proposer des offres personnalisées
Les nouvelles méthodes de production permettent d’offrir des produits sur-mesure, ce qui est
un argument d’achat pour les consommateurs qui cherchent eux aussi à se différencier de la
masse.
L’exemple de la voiture dont les options sont commandées dans le point de vente, les
informations transmises à la fabrique directement afin de permettre la fabrication selon les
souhaits du client montre à quel point les implications pour le système d’information peuvent
être grandes.
Les entreprises entraînées dans une course effrénée aux parts de marchée et aidées par
l’évolution des systèmes de production et d’information ont créé des systèmes complexes qui
certes offraient des solutions intéressantes pour les clients mais qui pouvaient pénaliser leurs
propres résultats financiers et qui ont eu pour conséquence deux grands effets :
1. Un client de plus en plus impliqué dans le processus

- Le client informé : Le client type a appris à se défendre contre les actions marketing
en développant un comportement qui l’amène à ne pas nécessairement répondre par
la vérité afin de provoquer les actions que lui-même souhaite.
Les clients connaissent de mieux en mieux les produits, ont la possibilité de
s’informer sur les caractéristiques et les prix par l’intermédiaire de l’internet. Le
vendeur doit être perçu comme conseiller et non plus comme un vendeur.
- Le client se sert lui-même : Le client a développé un goût pour le self-service dans le
temps et l’espace. Cette nouvelle tendance a aussi été poussée par les entreprises qui
y trouvent un intérêt dans la réduction des coûts lorsque différentes opérations ne
sont plus effectuées par l’entreprise mais par le client.
56
2. La perte de contrôle du client

La croissance importante des canaux d’accès aux clients et des messages contenus dans ces
canaux à destination des clients ont eu pour conséquence d’inonder littéralement les
consommateurs ; il est donc de plus en plus difficile, même pour les sociétés à gros budget,
d’avoir accès au client qui lui-même se protège contre le flot grandissant de messages.
La fameuse fidélité client pour les entreprises est une notion de plus en plus théorique ; le
client doit à chaque acte d’achat être fidélisé.
Le processus de recherche devenant de plus en plus aisé pour le client, on ne peut plus parler
de contrôle du client.
Toujours plus pour le client a entraîné des conséquences en termes de baisse de rentabilité
pour les entreprises par la complexité des produits, l’allongement du cycle de vie et la
complexité des opérations. [Source : Dyche2002]
3.5. Les fonctionnalités offertes par les systèmes CRM

Les systèmes CRM dans une entreprise ont la mission de soutenir tous les processus
impliquant la relation « client ». A cet effet, tout système CRM dispose de fonctions de base.
Selon la branche et la mission, certaines fonctions seront ajoutées.
D’un point de vue fonctionnel, la direction des ventes ou les responsables des secteurs auront
besoin de masques spécifiques pour la planification des ventes ; une hiérarchisation selon
diverses variables sera ici très importante.
Le département du contrôle nécessitera par contre une comparaison effectif/budget par région.
Pour le management, des informations en rapport avec les actions de la concurrence seront par
contre utiles.
La définition et la mise-à-jour de la base de données « concurrence » incomberont au
département marketing qui recevra les données du service extérieur et des autres sources
extérieures.
Le tableau suivant résume les fonctionnalités des systèmes de gestion de contacts, SFA (Sales
Force Automation) et CRM :
57
Fonction Fonctionnalités Gestion Contact App. SFA App. CRM

Ventes Planification / Prévision annuelle X X
Base de données clients X X X
Key Account Management X X
Channel Management X
Tracking concurrence X
Gestion des contacts X X X
Préparation des offres X X
Gestion des opportunités X
Gestion / prise des commandes X X
Gestion des RDV / agenda X X X
Reporting X X X
Telesales / Callcenter X
E-Sales X
Analyses / évaluations X X
Utilisation des notebooks X X X
Echange / synchro. des données X X X
Communication / emails X X X
Marketing Planification / Prévision annuelle X
Marketing direct X X X
Database marketing X X X
Segmentation du marché X
Telemarketing / Callcenter X X
Gestion des compagnes X
Encyclopédie marketing X
Controlling X X
E-Marketing X
Service Planification / prévision annuelle X
Teleservice / Callcenter X
Help Desk X
Gestion des réclamations X
Gestion de la qualité X
Service clients technique X
E-Service X
Interface Configuration produit X X
MS Office (Word, Excell, …) X X X
Lotus Notes X X X
ERP X X
Datawarehouse X
OLAP X X
Workflow X
Gestion des documents X
SI géographique X X
L’aperçu des fonctionnalités ci-dessus nous montre que le CRM représente une démarche
globale et englobe tous les outils de ses prédécesseurs, comme la gestion des contacts que le
SFA (Sales Force Automation), comportaient partiellement. [Source : Flueckiger2000]
58
3.6. E-Commerce et La gestion de la relation client via Internet

Quelques années auparavant, organiser une action marketing grand public relevait de
l’exploit. L’action nécessitait un investissement financier lourd puisqu’il fallait engager des
compagnes publicitaires sur les médias et les journaux ou imprimer des prospectus qu’il
fallait après distribuer sur les gens tout en payant bien sûr les employés qui s’en chargeaient.
Tout cela car à l’époque, les gens n’étaient pas tous connectés sur Internet. Certains jugeaient
inutile d’avoir une adresse email, d’autres ne voulaient pas faire l’investissement financier
nécessaire, les restants avaient tout simplement peur de l’Internet. Mais deux ans après, la
situation a complètement changé, le coût des connexions Internet a sensiblement baissé et la
confiance envers ce moyen de communication a été instaurée. Du coup, tout le monde se
trouve désormais sur Internet et la réalité suivante est actuellement claire : « Si vous voulez
être un professionnel, vous devrez être présent sur la super autoroute de l’information,
Internet ».
Quelques années auparavant, on s’inclinait pour argumenter que toutes les entreprises doivent
prendre cette autoroute. Aujourd’hui, on s’empresse de trouver des entreprises prospères qui
ne conduisent pas sur l’autoroute de l’information dans un sens ou dans un autre. Au fait, on
est préparé pour argumenter que l’e-commerce n’est pas négociable si on veut maximiser le
succès CRM, quelque soit l’entreprise.
Chacun de nous doit mieux apprendre sur Internet pour comprendre comment le e-commerce
change et va continuer de changer les attentes des clients et comment il est entrain de changer
leurs relations avec les autres fournisseurs de service qui nous sont concurrents.
3.6.1. Le CRM sur Internet

En réalité le e-commerce n’est pas un nouveau terrain. C’est juste une extension d’un
domaine que toutes les entreprises possèdent depuis l’avènement du commerce : celui qui
consiste à créer, maintenir et étendre les relations clients.
Pour jouer les jeux des entreprises de ce siècle, il est important de connaître que peut faire le
e-commerce pour vous et comment il est entrain de changer les attentes des clients. En
travaillant avec la pierre de touche de votre stratégie CRM, vous serez capable d’utiliser les
nouvelles règles et les nouveaux utiles offerts par le e-commerce pour satisfaire vos clients.
[Source : Kimball/Merz2000]
59
Internet permet de gérer votre stratégie CRM en trois niveaux :

- Niveau 1 : envoyer les informations aux clients
Internet peut fournir une grande route pour avoir des informations sur l’entreprise, ses
produits et ses services, pour ses clients actuels et futurs. Dans son niveau le plus bas, cela
veut dire laisser les clients savoir que l’entreprise est présente et leur montrer comment la
contacter. Cela peut commencer par la publication sur le Web d’une brochure qui décrit les
produits et les services de l’entreprise et communiquer les adresses et les numéros de
téléphones utiles.
- Niveau 2 : recevoir les informations sur les clients
Ce niveau de sophistication signifie que l’entreprise ne fait pas que fournir des informations à
ses clients, mais aussi apprendre plus sur eux. Internet permet de collecter tout type de
données utiles, et parfois inutiles, sur les clients. Dans certains cas, cela veut dire que les
clients doivent répondre à des questionnaires et fournir des informations utiles. Dans d’autres
cas, l’entreprise doit être capable de collecter des informations utiles sans s’interfacer
directement avec les clients en analysant les données du « ClickStream ».
- Niveau 3 : les e-ventes
L’entreprise peut aussi utiliser Internet pour vendre ses produits et ses services aux clients.
Elle peut tisser des relations avec des clients sans jamais les rencontrer. Cette relation
complète peut exister dans ce cyber-espace et être un succès. Avec la technologie actuelle, on
peut vendre les produits sur Internet, répondre aux questions des clients, offrir des produits et
des services additionnels en se basant uniquement sur des achats antérieurs et surtout évaluer
le degrés de satisfaction des clients par rapport à ces offres, le tout sans traiter directement
avec eux. [Source : Kimball/Merz2000]
L’entreprise peut aussi fournir un service client en ligne via les moyens suivants :
• Les moteurs de recherches : un moteur de recherche sur un site aide les clients à
trouver des réponses à leurs questions, localiser les informations et se connecter
rapidement au département concerné.
• Les FAQs (Frequently Asked Questions) : une page sur le site qui publie et répond
aux questions les plus posées par les clients.
• L’aide en direct : les clients peuvent de nos jours parler directement avec la personne
en charge du service quand ils sont sur le site web en utilisant la technologie de la voix
sur IP (VOIP).
60
• Suivi des commandes en ligne : avec des applications personnalisées, l’entreprise peut
permettre aux clients de suivre l’évolution et la progression de leurs commandes.
Citons comme exemple l’entreprise « DHL » qui donne la possibilité à ses clients de
poursuivre leur courrier en temps réel.
3.6.2. Choisir le bon moyen de communication

« Amazon.com » utilise sa présence sur le Web pour fortifier ses relations clients. Chaque
personne peut effectuer des recherches dans la base de données ‘produits’ d’« Amazon ».
Après un premier achat, « Amazon » encourage et mène le client à l’achat suivant. Lorsque
nous visitons « Amazon.com », nous sommes automatiquement reconnus et salués par
un : « Bonjour, nous avons des recommandations pour vous ». « Amazon.com » invite aussi
les clients à donner leurs avis après un achat. Les clients se connectent au site et exprime leur
degré de satisfaction ou de non satisfaction sur le produit acheté.
Pour gérer ses clients en utilisant ce moyen hautement sophistiquée, « Amazon.com » investit
un capital financier et un autre humain considérables. Les applications d’ « Amazon.com »
représentent actuellement ce qu’il y a de mieux dans le monde du e-commerce et ça marche
très bien pour cette entreprise.
Les entreprises novices dans le domaine doivent cependant commencer par un investissement
plus modeste. Il faut prendre en considération comment l’entreprise et ses départements se
connectent actuellement à ses clients. Il faut penser aux clients externes, ceux qui payent de
l’argent pour les produits et les services, et les clients internes, les autres départements et les
personnes qui dépendent de l’entreprise.
Voici la liste de départ :
• Les pages jaunes et les répertoires téléphoniques : de plus en plus de clients
cherchent les contacts des entreprises sur Internet. Etes-vous listé ? est-ce que les
données vous concernant sont à jour ?
• Email : est-ce que votre adresse email est facilement accessible à vos clients ?
• Site Web : est-ce que votre site Web est passif ? est-ce qu’il contient uniquement des
brochures sur vos produits et vos services ? Ou, permet-il à vos clients de faire des
recherches sur des informations ou des FAQs ? Les clients peuvent-ils acheter
directement sur votre site ? Est-ce que votre site vous permet d’apprendre d’avantage
sur vos clients ?
• Interaction en direct via le site Web : Les clients peuvent-ils se connecter avec vous
sur votre site en utilisant la VOIP ou le partage de documents ?
61
3.6.3. Les trois règles de succès sur la route du e-commerce

Durant toute la phase d’implémentation d’une solution e-commerce, il faut toujours avoir en
tête ces trois règles de succès :
• Le e-commerce n’a pas besoin de coûter très chers.
• Le maintien à jour. Les clients attendent que les données sur Internet soient plus à jour
que celles sur les brochures imprimées.
• La personnalisation des services.
- Le e-commerce n’a pas besoin de coûter très chers

Une simple page (une brochure électronique) qui révèle qu’on est présent dans cette espace et
qui montre la direction pour nous atteindre est mieux qu’une non présence.
- Le Maintien à jour
Cela veut dire tout simplement mettre à jour les données électroniques dès que des
changements se produisent sur le terrain de la réalité. Exemple, si un N° de téléphone change,
il faut mettre à jour immédiatement la page Web, sinon on risque de perdre idiotement des
clients potentiels qui voudraient rentrer en contact avec nous.
- Personnaliser le service
Offrez des services personnalisés aux clients. Une page Web personnalisée est une page qui
essaye de faciliter la vie du client. [Source : Kimball/Merz2000]
3.7. Les composantes d’un système CRM
3.7.1. Les systèmes et données en provenance de l’ERP

La plupart des fonctionnalités d’un système CRM vont demander de pouvoir disposer de
données en provenance du système central ERP de l’entreprise.
Par exemple, une commande prise par un représentant dans un magasin nécessitera la
recherche d’un prix de vente qui provient du système de calcul des prix de revient appartenant
à l’ERP. Il pourrait aussi être utile de disposer des informations concernant les limites de
crédit du client.
Cet accès aux systèmes ERP nécessite une interface et représente une des difficultés
techniques du projet CRM. On devra aussi veiller à régler la nécessité de synchronisation des
données entre l’ERP et les bases de données répliquées auprès des utilisateurs distants.
62
Les droits d’accès aux données sont aussi des points à régler soigneusement, par exemple
définir qui est habilité à ouvrir un nouveau compte, est-ce l’utilisateur distant à partir du
système CRM ou uniquement l’utilisateur central ayant accès direct à l’ERP.
3.7.2. Les bases de données externes

Les bases de données externes permettent d’intégrer des données provenant non pas de
l’entreprise mais de sources externes comme les instituts de sondage.
Ces données sont importantes car elles permettent d’aborder la totalité d’un marché et non pas
uniquement les produits de la société en question.
L’intégration des données provenant de sources différentes dans un référentiel commun pose
dans la plupart des cas un problème majeur étant donné que les méthodes de saisie et de
traitement sont différentes.
3.7.3. Les canaux d’interaction

Le client est de plus en plus servi à travers de multiples canaux comme le représentant, le
« call center », le site web ou le fax.
Cette nouvelle situation exige une synchronisation en temps réel entre les canaux.
En effet, il arrive encore souvent qu’un produit soit en promotion sur le site web, que le client
souhaitant retirer le produit immédiatement au magasin qui lui n’est pas au courant de la
promotion en question.
Le point d’interaction au moment du contact est l’identité de l’entreprise.
3.7.4. Le datawarehouse
La connaissance du client repose sur des informations quantitatives et qualitatives concernant
le client et demande la collaboration de toutes les personnes en contact avec le client.
Le datawarehouse comportera non seulement des informations comportementales provenant
de l’ERP mais aussi les informations relatives à toutes les interactions entre le client et
l’entreprise.
Le datawarehouse permettra d’offrir une vision unifiée du client aux différents acteurs dans
l’entreprise.
Quant à la segmentation, elle pourra être effectuée sur des faits objectifs.
63
3.8. La technologie du datawarehouse comme base pour le CRM

Le facteur clé de succès d’un projet CRM est le traitement des données sur les clients. Ainsi,
parmi les technologies-clés qui rendent possible le succès du CRM sont le datawarehousing et
le datamining.
Les différents processus rencontrés dans le cycle du « Marketing » peuvent clairement être
divisés en deux domaines :
• Il y a tout d’abord le traitement opérationnel des données qui aide les collaborateurs
comme élément « Front-End » à mettre en place les activités marketing et enregistre les
résultats.
• Puis il y a les éventuels systèmes Datawarehouses comme élément « back end » qui
analysent les résultats et aident les « Marketers » à élaborer une stratégie et planifier les
actions.
La base du datawarehouse orienté CRM est donc les données qui proviennent des différentes
sources opérationnelles, par exemple les données transactionnelles en provenance des
systèmes ERP, de « Sales Force Automation », de « Campaign Management », des « Call
Centers », et plus récemment du commerce électronique ; on pourrait y rajouter les données
provenant de sources externes comme les instituts statistiques.
Cela nous amène à conclure que le CRM ne peut pas être pratiqué dans une entreprise d’une
manière efficace sans avoir une source majeure d’information qui est le datawarehouse. Mais
comme nous allons le voir, ce datawarehouse doit intégrer dès sa conception les objectifs
CRM de l’entreprise. Et cela nous mène finalement au cœur de notre sujet.
Examinons le schéma d’interaction CRM - Datawarehouse suivant :
Très souvent, les données récoltées durant les différentes étapes du processus ne sont pas homogènes mais
Figureêtre
devront 3.8.1 : Les relations
analysées CRMconsistante.
sur une base – Datawarehouse. Source
Le système [Flueckiger2000]
de datawarehouse ‘unifie’ les données et les classes
selon différents sujets comme les clients ou groupe de clients.
64
Le transfert de données est donc bidirectionnel :

• les données transactionnelles sont importées des systèmes opérationnels dans le
datawarehouse qui rend possible des recherches complexes sur une base homogène.
• Un retour doit être prévu pour permettre aux résultats des analyses d’être utilisés pour
des actions concrètes, par exemple pour permettre au « Call Center » lors d’actions
téléphoniques de disposer d’informations fines sur le client pour leur proposer des
solutions correspondant à leurs attentes.
Selon les besoins, on pourra avoir accès au datawarehouse de différentes manières. Deux
principales manières ressortent : OLAP et le Datamining. La principale différence entre les
deux est que la méthode OLAP travaille avec des dimensions et relations prédéfinies alors que
le datamining recherche des échantillons nouveaux et non connus au départ qui pourront
ensuite servir comme base pour OLAP :
- L’OLAP
OLAP offre un moyen très rapide de considérer et d’analyser des données et des nombres
selon différentes perspectives.
D’après le centre d’intérêt, les données, par exemple les lignes de produits, les régions et les
résultats des analyses peuvent être représentés graphiquement selon différentes vues.
De cette manière, les différents départements reçoivent des informations qui correspondent à
leurs besoins. Le « Product Manager » reçoit la situation de son groupe de produits dans une
région déterminée alors que le « Controller » reçoit le chiffre d’affaires de toute la palette de
produits pour un mois donné.
- Le Datamining
Le datamining est approprié pour découvrir les relations non connues. Derrière le concept se
trouve une combinaison de différents algorithmes statistiques qui peuvent aider les
« Marketers » à découvrir des relations et des tendances.
Ce processus complexe nécessite la définition de variables à partir d’un grand nombre de
données.
Le choix du modèle statistique approprié avec lequel les données doivent être analysées est
décisif pour le résultat d’une requête.
L’exploitation du potentiel lié au « Cross-Selling » et « Up-Selling » se trouve dans la
classification des clients. Dans un segment donné, les clients qui ont des intérêts semblables
sont répertoriés et ainsi ciblés par un produit défini. Une des méthodes de « Datamining » est
65
l’analyse de clustérisation qui permet de répartir constamment les clients dans de nouveaux
groupes.
Par exemple, à partir d’une commande de vêtements pour bébés, une maison de vente par
correspondance pourra prédire quand l’envoi d’un catalogue spécial pour du matériel
d’écolage est approprié.
Le but ultime de l’utilisation de système de traitement de l’information dans la relation client
est le gain d’avantages compétitifs à travers une meilleure gestion de l’information et une
orientation client plus forte.
Le but de notre travail sera donc d’approfondir ces concepts et de construire une solution
datawarehouse qui servira de base pour les systèmes CRM.
Dans le reste de ce mémoire, nous allons donner les éléments essentiels de conception et de
construction d’un datawarehouse de deuxième génération destiné à supporter les systèmes
CRM des entreprises.
66
Chapitre 4
Conception d’un datawarehouse orienté

CRM
n La méthode du point et la modélisation conceptuelle ;

n La modélisation logique du datawarehouse ;
n L’implémentation physique du système ;
n Les produits logiciels.
Conception d’un Datawarehouse orienté CRM
4. Conception d’un Datawarehouse orienté CRM
4.1. Etude de cas : présentation de « ETS boissons »

Pour la suite de cette étude, nous allons construire un Datawarehouse pour le support des
activités CRM pour une entreprise de commercialisation de boissons implantée au niveau
national. Appelons cette entreprise : « ETS Boissons ».
Durant ce chapitre, Nous allons commencer par construire un modèle conceptuel général de
notre datawarehouse qui nous servira de base pour le reste de notre étude. Nous allons ensuite
présenter une nouvelle méthode de modélisation adaptée au contexte des datawarehouses de
deuxième génération orientés CRM. Cette méthode sera utilisée pour produire le modèle
conceptuel détaillé de l’« ETS Boissons ». Nous entamerons par la suite les modélisations
logique et physique de la base de données et nous terminerons par présenter et expliquer
l’architecture d’implémentation physique du système.
Rappelons que le facteur clé de succès d’un projet CRM est le traitement des données sur les
clients. Ainsi, parmi les technologies-clés qui rendent possible le succès du CRM sont le
« datawarehousing » et le « datamining ».
Les différents processus métiers CRM peuvent clairement être divisés en deux domaines :
• Il y a tout d’abord le traitement opérationnel des données qui aide les collaborateurs
comme élément « Front-End » à mettre en place les activités marketing et enregistre les
résultats.
• Puis, il y a les dispositifs « Datawarehouses » comme élément « Back-End » qui analysent
les résultats et aident les « Marketers » à élaborer une stratégie et planifier les actions.
La base du datawarehouse orienté CRM est donc les données qui proviennent des différentes
sources opérationnelles, par exemple les données transactionnelles en provenance des
systèmes ERP, de « Sales Force Automation », de « Campaign Management », des « Call
Centers », et plus récemment du commerce électronique ; on pourrait y rajouter les données
provenant de sources externes comme les instituts statistiques.
68
Concernant notre système futur, nous commençons par donner un premier schéma global
générique simplifié en étoile de la future solution. Ce schéma nous servira de base pour la
suite de notre étude :
Gestionnaire
Boisson Compte
Ventes Client
Dépôt
Temps
Figure 4.1.1 : Modèle générale initial en étoile « ETS Boissons »
Voici aussi quelques attributs de la principale dimension, la dimension « Client » :

Dimension « Client »
ID Client (clé primaire)
Nom Client
Adresse
Ville
Wilaya
Code postal
ID Gestionnaire Compte
Dimension « Gestionnaire Compte »
ID Gestionnaire Compte
Nom Gestionnaire Compte
Ensuite, voici les attributs obligatoires de la table des faites :

Ventes
ID Client (Clé primaire 1)
ID Boisson (Clé primaire 2)
Heure (Clé primaire 3)
ID Dépôt
Quantité
Valeur
Intéressons nous maintenant à la modélisation conceptuelle générale de notre datawarehouse.
69
4.2. Le modèle conceptuel général (MCG) orienté CRM

Le Datawarehousing est devenu actuellement une solution mature. Cependant, l’évolution des
entreprises nécessite de faire évoluer aussi les datawarehouses. Les entreprises actuelles ont
besoin de maîtriser leur CRM, et pour le satisfaire, l’information sera la clé de succès.
Les projets CRM ne peuvent pas réussir sans avoir des informations de « haute qualité », à
jour et précise. Nous ne pouvons pas gérer un client sans de telles informations. Ainsi, sans
ces informations, nous ne pouvons pas, par exemple, adresser aux clients des communications
personnalisées ni d’estimer le risque les perdre.
Si nous voulons obtenir de telles informations, nous avons besoin de construire un
datawarehouse de « deuxième génération » orienté CRM.
Un datawarehouse de deuxième génération est un datawarehouse qui gère les données sur :
• Le comportement des clients (données comportementales),
• Les circonstances des clients : La distinction entre les circonstances et le
comportement, qui sont deux différents types de données, est importante dans la
conception du datawarehouse.
• La segmentation des clients : La capacité de segmenter les clients d’une manière
précise est une des plus importantes propriétés d’un datawarehouse conçu pour
supporter une stratégie CRM.
Rappelons le modèle initial de l’entreprise « ETS boissons » :
Gestionnaire
Boisson Compte
Ventes Client
Dépôt Temps
Figure 4.2.1 : Rappel : le modèle conceptuel général initial « ETS Boissons »
70
Les deux premières questions qu’on se pose sont : est-ce que ce modèle contient les
informations sur :
• Le comportement des clients,
• Les circonstances des clients.
Il est évident que la réponse est OUI.
La table « Ventes » qui est la table de faits contient des détails sur les ventes aux clients. Ce
sont des données comportementales, et c’est une caractéristique des datawarehouses et des
datamarts dimensionnels qui précise que la table des faits contient des données
comportementales.
La dimension « Client » est l’endroit unique où on stocke les informations sur les
circonstances clients. Selon ‘Ralph KIMBALL’, le principale rôle de la dimension « Client »,
et des autres dimensions d’un modèle dimensionnel, est de permettre d’ajouter des contraintes
aux requêtes à exécuter sur la table des faits. Les dimensions permettent de regrouper
(d’agréger) les faits et apparaissent dans les entêtes des tableaux résultats des requêtes. Nous
devons être capables d’effectuer des « Drill Down » et des « Slice & Dice » sur la table des
faits. Une solution basée sur un modèle dimensionnel est idéal pour cela.
Un modèle dimensionnel est avant tout, un modèle orienté comportement. Il est orienté
comportement car son principal objectif est de faciliter l’analyse compréhensive des données
comportementales.
4.2.1 Comportement Client et Circonstances Client : le principe du cause-à-

effet
Le plus important problème que les entreprises actuelles s’empressent de maîtriser et « la
fidélité des clients » et sa directe conséquence : « le mouvement des clients ». Pour mieux
comprendre la situation, prenons l’exemple d’un client d’un opérateur de téléphonie mobile et
réfléchissons aux raisons qui peuvent pousser ce client à changer d’opérateur :
• Probablement qu’il vient de déménager vers une autre adresse et que la couverture
réseau de cet opérateur est mauvaise dans la nouvelle région.
• Le client a changé d’employeur. Le nouvel employeur lui offre un téléphone portable
avec une ligne d’un autre opérateur.
• Un enfant du client vient de rentrer à l’université, les dépenses ont augmenté et le père
a jugé que le téléphone portable devient désormais un luxe qu’il ne peut plus
supporter.
71
Toutes ces situations (circonstances) peuvent être la cause pour laquelle ce client apparaîtra le
mois prochain sur la liste des clients ayant cessé leur relation avec cet opérateur.
Ça aurait été parfait si l’opérateur avait prédit qu’il s’agissait d’un client à risque. La seule
manière de pouvoir réaliser ce classement est d’analyser les données recueillies et d’appliquer
sur elles quelques modèles prédictifs qui donneraient un classement du genre :
1 : Client à faible risque,…, 10 : Client à haut risque.
Mais quelles sont ces données là ?

Traditionnellement, les datawarehouses sont organisées autour de modèles purement
comportementaux. Dans une compagnie de téléphonie mobile, les données comportementales
fréquemment utilisées sont liées aux appels téléphoniques :
• Type d’appel : national, international,
• Durée de l’appel,
• Coût de l’appel,
• Heure de l’appel,
• L’opérateur destination.
Si nous analysons ces données comportementales, qu’est-ce qu’allons-nous trouver ?
Peut-être qu’on peut simplement prédire que juste avant le départ du client, il a cessé
d’utiliser son téléphone !!!
Cependant, « Ce changement brutal de comportement est le résultat d’un changement
dans les circonstances ».
En partant du fait que les datawarehouses dimensionnels mesurent le comportement, on peut
conclure que de tels modèles ne nous aident pas à connaître d’avance les clients que nous
risquons de perdre. Nous devons alors être rigoureux et se concentrer beaucoup plus sur les
données des circonstances. C’est pourquoi, les datawarehouses de nouvelle génération sont
construits comme une base de développement d’applications CRM en incluant le traitement
des données de circonstances.
Au lieu d’être orientée « Comportement », la nouvelle génération de datawarehouses est
qualifiés de « Orientée client ».
Et pour construire un modèle orienté client, il faut commencer par modéliser celui-ci. Nous
savons maintenant qu’il existe deux types majeurs de données : « comportementales et de
circonstances ». Pour le moment, concentrons-nous sur les circonstances.
72
Parmi les données sur les clients que nous voulons stocker figurent :
Client
Nom
Adresse
N° téléphone
Date de naissance
Sexe
Situation familiale
Il est clair que nous aurons besoin de beaucoup plus de données. Mais cette liste sera utilisée
comme un exemple pour simplifier notre étude de cas.
Circonstances ‘client’
Client changeantes
Figure 4.2.2 : MCG : Vue globale « circonstances ‘Client’ changeantes »
Nous commençons par construire un modèle conceptuel général pour les clients. Pour chaque
client, nous identifions les attributs qui peuvent changer de valeur et les attributs qui ne
changent pas de valeur où ceux dont on ne veut pas suivre les changements et connaître les
anciennes valeurs.
Dans notre étude de cas « ETS Boisson », le nom, le n° de téléphone, la date de naissance et le
sexe sont des attributs qui ne peuvent pas changer de valeurs ou si elles changent, on n’aura
pas besoin de connaître les anciennes valeurs. Pour l’instant, considérons que l’adresse et la
situation familiale du client peuvent changer plusieurs fois leurs valeurs.
73
Le modèle sera comme suit :
Client Adresse
Situation familiale
Figure
Ainsi, 4.2.3la: MCG
on garde : Vue
trace des détaillée «d’adresses
changements circonstances
et de la‘Client’ changeantes
situation familiale. »
Maintenant, l’autre principal type de données clients que nous devons capturer est le
comportement. Les données comportementales résultent des interactions entre le client et
l’entreprise. Les modèle conceptuel général que nous essayons de développer doit inclure les
données comportementales.
Circonstances
Comportement Client client
client changeantes
Figure 4.2.4 : MCG : Vue globale « Client »
La relation entre le client et son comportement montre qu’il y’a plusieurs instances
comportementales dans le temps. Le modèle actuel que nous proposons pour l’« ETS
Boisson » sera comme suit :
74
Adresse
Ventes boissons
Client
Situation
familiale
Figure 4.2.5 : MCG « ETS Boissons » : Vue détaillé ‘Client’ : comportement et circonstances
Ce modèle conceptuel général de notre datawarehouse orienté client parait simple. Mais à ce
stade, il n’est pas encore complet.
Nous rappelons qu’il existe trois types de données client. Les deux premiers sont les
circonstances et le comportement. Le troisième type est les « segments dérivés ». Comme
exemples de principaux segments dérivés, nous pouvons lister : « Durée de vie estimée » et
« tendance à partir ». En réalité, la classification d’un client par rapport à un segment dérivé
se fait sur la base de processus de calcul de type « modèles prédictifs ». Donc, il est préférable
de modifier notre modèle afin d’inclure les segments dérivés :
Comportement Circonstances
Client Client changeantes
Segments dérivés
Figure 4.2.6 : MCG : Vue globale complète « Client »
Ce modèle peut être décrit comme le modèle conceptuel général d’un datawarehouse orienté
client. Ce MCG constitue un « Template » à partir du quel seront construit dans le futur des
modèles conceptuels finalisés.
75
4.2.2 Le modèle conceptuel général « ETS Boissons »

Maintenant que nous avons notre vue MCG « Client », nous pouvons appliquer ses principes
pour notre cas pratique. Nous commençons par définir les données client que nous voulons
stocker. Dans notre cas, les attributs choisis sont :
Données client
Titre
Nom
Adresse
N° Téléphone
Date de naissance
Sexe
Situation familiale
Détails enfants
Détails épouse
Revenue mensuel
Loisirs et intérêts
Profession
Détails employeur
Ces attributs doivent être divisés en deux types :

• Les attributs qui sont relativement statiques (où dont les anciennes valeurs peuvent
être supprimées),
• Les attributs qui changent de valeur.
76
Données client statiques

Titre
Nom
N° Téléphone
Date de naissance
Sexe
Données client dynamiques
Adresse
Situation familiale
Détails enfants
Détails épouse
Revenu mensuel
Loisirs et intérêt
Profession
Détails employeur
Construisons maintenant notre vue « Client » du modèle conceptuel global « ETS Boissons »:
Situation
Adresses familiale Enfants
Epouse Client Revenu
Loisir/Intérêt Profession Employeurs
Figure 4.2.7 : MCG « ETS Boissons » 1/3 : Vue détaillée « Client » : les circonstances
77
Le modèle comportemental sera le suivant :
Ventes boissons
Client
Figure 4.2.8 : MCG « ETS Boissons » 2/3 : Vue globale « Client » : le comportement
Maintenant, il faut détailler le point relatif aux « segments dérivés ». Voici quelques exemples
que nous pouvons appliquer pour l’« ETS Boissons » :
• Durée de vie : une bonne classification que toute entreprise doit avoir.
• Promotions spéciales : c’est un bon exemple de segment qui peut être très efficace. Si
un jour, l’« ETS Boissons » voudrait augmenter les ventes d’une boisson spécifique,
elle serait capable de déterminer quel client est susceptible d’acheter ce produit. Cela
impliquerait l’analyse préalable des précédents comportements et circonstances.
Notre modèle de segments dérivé sera comme suit :
Promotions
Durée de vie Client spéciales
Figure 4.2.9 : MCG « ETS Boissons » 3/3 : Vue détaillée « Client » : les segments dérivés
Ainsi, en rassemblant les trois modèles des vues détaillées, nous aboutissons à un modèle
conceptuel général d’un datawarehouse orienté client appliqué à un cas pratique. Ce modèle
nous accompagnera dans le reste de cette étude.
Remarquez que dans cette conception globale, nous nous sommes intéressés uniquement à la
dimension « Client » car par rapport aux datawarehouses classiques, les datawarehouses
orientés CRM diffèrent surtout par la manière de traiter cette dimension « Client ».
Nous allons maintenant aborder la construction du modèle conceptuel détaillé.
78
4.3. La méthode du point et la modélisation conceptuelle détaillée

Dans cette section, nous allons commencer par exprimer le besoin d’adopter une méthode de
modélisation adaptée aux projets datawarehouses de deuxième génération orientés CRM.
Ensuite, nous allons présenter la méthode du point en général sans rentrer dans les détails et
nous terminons par la construction du modèle conceptuel détaillé de notre solution
Datawarehouse orienté CRM pour l’« ETS Boissons » en se basant sur le modèle conceptuel
général (MCG) que nous avons élaboré dans la section précédente.
Nous rappelons que pour pouvoir concevoir un datawarehouse de deuxième génération

orienté CRM, nous devons traiter les éléments de modélisation suivants :
• Le diagramme conceptuel global orienté « Client » (Modèle orienté « Client ») ;
• Les circonstances changeantes et non-changeantes des clients ;
• Le comportement des clients ;
• Les segments dérivés.
Enfin, notre modèle conceptuel doit être capable de gérer les données temporelles pour
chaque élément de conception. Nous allons aussi traiter les changements causals et les
dépendances entre les données à capturer.
Enfin, nous précisons que cette section s’inspire des travaux de Chris Todman, publiés dans
son livre “Designing a Datawarehouse Supporting CRM”; Édition Prentice Hall; 2001.
4.3.1. La limite des méthodes traditionnelles

Le modèle conceptuel de données d’un datawarehouse doit :
• Etre simple à comprendre et à utiliser par des non-informaticiens ;
• Etre conforme au MCG ;
• Supporter les données temporelles.
Le type de modélisation généralement utilisée pour ce type de modèle est l’entité-relation

(ER). Ces modèles sont bien maitrisés par les informaticiens mais ils sont, en revanche,
difficiles à comprendre par les non-informaticiens. Les modèles « ER » sont sémantiquement
très riches et ils sont bien adaptés pour modéliser les systèmes opérationnels. En réalité, pour
pouvoir modéliser un système décisionnel, nous n’avons pas besoin de toute cette richesse
79
sémantique mais nous avons plutôt besoin d’un modèle simple, facilement compréhensible
par les non-informaticiens et surtout être adapté aux concepts des systèmes décisionnels.
Comme nous le savons déjà, les datawarehouses ne sont pas conçus pour supporter les
applications opérationnelles telles que la gestion des ventes où la gestion des stocks. Ils sont
conçus pour assister les responsables dans leurs processus de prise de décision.
Généralement, les utilisateurs sont incapables d’exprimer clairement leurs besoins en
information. Ces utilisateurs savent qu’ils ont des problèmes mais ils ne connaissent pas leurs
origines.
D’un autre côté, les managers ont des objectifs à atteindre. Leurs performances sont mesurées
à l’aide d’indicateur clé de performance (KPI : Key Performance Indicator). Un
datawarehouse pourrait aider les décideurs à atteindre leurs objectifs s’ils sont capables
d’exprimer précisément les informations dont ils ont besoin pour prendre les bonnes
décisions.
Nous avons besoin d’un modèle qui permet l’expression du besoin d’une manière
participative. Les utilisateurs doivent être capables de construire, valider, modifier et même
remplacer par eux-mêmes le modèle conceptuel. Ceci dit, le modèle doit être aussi riche et
puissant et permettre ainsi de spécifier les caractéristiques techniques des données afin que les
informaticiens puissent développer le modèle logique des données.
a. Le traitement du comportement :
Les besoins temporels des données comportementales (les faits) sont très simples. Une fois
enregistrées, ces données ne changent pas. Les faits comportementaux sont dérivés d’une
entité opérationnelle qui a atteint un état particulier. Le changement de l’état est causé par un
évènement qui s’est produit à un instant donné. Donc, un des attributs du « fait » sera un
attribut de « temps » (combinaison Date/Heure). L’attribut « temps » enregistre les
informations temporelles lors de la réalisation de l’évènement. Cet attribut sera utilisé de deux
manières :
• Comme un paramètre d’une contrainte de sélection dans une requête,
• Comme un moyen pour joindre les dimensions à des groupements hiérarchiques.
Pour chaque évènement ou changement, nous associons une donnée « temps ». Le besoin en
granularité du « temps » diffère d’une application à une autre. Certaines applications ont
80
simplement besoin du « jour » comme la granularité du temps la plus fine. Nous pouvons
citer comme exemple :
• Vente des voitures des constructeurs pour une compagnie d’assurance,
• Analyse des balances comptables d’une banque,
• Analyse de ventes des produits dans un hypermarché.
D’autres applications ont besoin d’un grain plus fin qui peut-être l’« heure ». Par exemple :
• Analyse du comportement des clients dans un hypermarché,
• Contrôle du volume du trafic des voitures.
D’autres applications ont besoin de plus qu’un unique grain de temps. En analysant les
exemples précédents, nous nous apercevons qu’au niveau des hypermarchés, nous avons
besoin de deux différents granules de temps pour l’analyse des ventes et pour l’analyse du
comportement. Toutes les analyses dimensionnelles auront besoin de différents niveau
d’agrégation des ces données suivant l’axe du temps.
b. Le traitement des circonstances - rétrospections :

Dans la première génération des datawarehouses dimensionnels, la manière de traiter une
valeur d’attribut de dimension en respectant les valeurs antérieures dépend entièrement des
besoins liés au partitionnement temporel des faits. Le rôle principal des attributs de dimension
est de servir comme contraintes dans les requêtes. Les besoins en partitionnement temporel
n’ont pas été convenablement traités dans les datawarehouses de première génération.
Principalement, les attributs de dimension existent pour être des paramètres de contraintes de
requêtes sur les faits, même si 80 % des requêtes exécutées sont des requêtes de navigation
dimensionnelle.
Ce n’est que depuis l’émergence du CRM, que nous avons constaté que même les dimensions
doivent contenir des données importantes sur l’entreprise comme par exemple la croissance
de la clientèle (dimension « Client »). Dans certaines industries, comme dans le secteur des
télécommunications, cela devient une impérative.
Notre MCG de base (Modèle Conceptuel Général), en étant orienté client, permettra de
répondre à des requêtes riches et complexes sur les circonstances clients, bien plus que le
permet un modèle traditionnel. De ce fait, le MCG nous impose de traiter en profondeur les
aspects non-dimensionnels des clients ; Ce que nous appelons : les circonstances et les
segments dérivés.
81
Aussi, chaque composant du modèle qui est sujet à des changements dans le temps doit être
évalué pour définir la manière de traiter les valeurs « historiques ». Un composant peut être :
• Une entité : un ensemble de circonstances ou une dimension entière.
• Une relation : exemple, hiérarchie.
• Un attribut : exemple, l’adresse du client.
Pour chaque composant, nous donnons une classification que nous appelons la rétrospection
du composant. La rétrospection possède trois valeurs possibles :
• Vrai,
• Faux,
• Permanent.
Une rétrospection dont la valeur est « Vrai » signifie que le composant doit pouvoir nous
restituer son historique. Il permet de retourner des enregistrements temporels des données
reflétant un partitionnement historisé des valeurs. Chaque valeur de dimension, de relation et
d’attribut aura ainsi une durée de vie déterminée.
Une rétrospection dont la valeur est « Faux » signifie que la vision de l’historique sera altérée
si les valeurs de données de l’objet changent. En d’autres termes, quand les changements
subviennent, les anciennes valeurs seront écrasées et définitivement perdues, comme si les
anciennes valeurs n’ont jamais existé.
Une rétrospection dont la valeur est « Permanent » signifie que la valeur de donnée de l’objet
ne change jamais.
- La rétrospection et les entités (les dimensions)

La valeur de la rétrospection se rapporte à l’existence de la dimension. Par exemple,
l’existence du client commence avec sa première commande chez l’« ETS Boissons » et
l’existence se termine lorsque le client devient inactif.
Rétrospection = Vrai : signifie que la durée de vie de l’entité consiste en un ou plusieurs

intervalles de temps. Un client peut ne pas avoir une seule durée de vie continue. Cela reste
aussi vrai pour la dimension « Boisson ». Une boisson peut être disponible pendant des
intervalles de temps spécifiques, ou la durée de vie entière est ponctuée par des périodes
pendant lesquelles une boisson n’est pas disponible.
82
Rétrospection = Faux : signifie que seul l’état actuel de l’existence de l’entité est enregistré.
Un exemple pour l’« ETS Boissons » peut être la dimension « Fournisseur ». Il y aurait peut-
être le besoin d’être capable de distinguer entre les fournisseurs actuels et les anciens
fournisseurs. Pour cela, nous n’avons pas besoin d’enregistrer les périodes de temps pendant
lesquelles un tel fournisseur livrait ses boissons à l’« ETS Boissons » en distinguant les autres
périodes d’inactivité du fournisseur.
Rétrospection = Permanent : signifie que l’entité existe indéfiniment.
- La rétrospection et les relations

Dans un modèle dimensionnel, le type de cardinalité est toujours « un à plusieurs ». Quand la
relation devient temporelle, à cause du besoin d’avoir une rétrospection sur elle, la cardinalité
peut devenir « plusieurs à plusieurs ».
Il est important que cette information soit ajoutée au modèle sans y ajouter de complexité.
La situation avec les relations est similaire avec les entités. C’est l’existence et la durée de vie
de la relation qui déterminent la valeur de la rétrospection dans les relations.
Rétrospection = Vrai : signifie que la durée de vie de chaque relation doit être enregistrée et
historisée pour que les résultats des requêtes reflètent fidèlement le passé. Dans notre étude de
cas, citons l’exemple de la relation entre « Client » et « Région des ventes ». Si un client
change de région, il est important que l’ancienne relation de ce client avec l’ancienne région
soit gardée.
Rétrospection = Faux : signifie que seules les relations actuelles doivent être enregistrées. Le
système n’a pas besoin de garder les anciennes relations. Un exemple de ça est la relation
entre « Client » et « Loisirs ». Si les loisirs d’un client changent, nous n’avons pas besoin de
garder la trace des anciennes relations.
Rétrospection = Permanent : signifie que la relation ne change jamais.
- La rétrospection et les attributs

Chaque attribut du modèle doit être évalué afin de déterminer s’il a besoin ou non d’un
support temporel. Donc, une des propriétés de l’attribut est sa valeur de rétrospection. Et
83
comme dans le cas des autres objets de données, ce besoin ne doit pas ajouter une complexité
signifiante au modèle de données.
Rétrospection = Vrai : signifie que nous devons enregistrer et garder toutes les valeurs d’un
attribut sur l’axe du temps. Notre exemple sera le « Coût » d’une bouteille de boisson.
Comme ce coût change dans le temps, nous devons enregistrer le nouveau coût sans perdre les
anciens.
Rétrospection = Faux : signifie que seulement la dernière valeur de l’attribut est

sauvegardée. Quand la valeur de l’attribut change, la nouvelle valeur remplace l’ancienne
valeur et celle-ci est perdue définitivement.
Rétrospection = Permanent : signifie que la valeur de l’attribut ne change jamais.
- La rétrospection et notre étude de cas :

Dans le tableau suivant, nous listons quelques éléments de données : entités, relations et
attributs de l’« ETS Boissons ». Pour chaque élément, nous donnons une valeur de
rétrospection qui satisferait les besoins.
Nom de l’objet Type Rétrospection Raison

Client Entité Vrai Les clients peuvent avoir plusieurs intervalles
d’activité. Il est important d’étudier le
comportement des clients dans le temps.
Région_Ventes Entité Faux Uniquement la dernière instance est requise. Les
régions peuvent être fusionnées ou éclatées.
Seule la dernière structure a un intérêt.
Loisirs Entité Permanent Les loisirs, une fois saisis, ne changeront jamais.
Région_V – Client Relation Vrai Il y’a un besoin d’analyser les performances des
régions. Et comme les clients changent de
régions, nous devons garder l’historique des
relations.
Loisirs – Client Relation Faux Seule le loisir actuel est gardé.
Client – Ventes Relations Permanent La relation entre une vente et un client implique
que cette vente ne change jamais.
Client.Code_Client Attribut Permanent Attribut clé.
Client.Nom_client Attribut Faux La dernière valeur est suffisante.
84
Nom de l’objet Type Rétrospection Raison

Client.Adresse Attribut Vrai Analyse détaillé par zone ramenée au niveau
ville.
Client.Date_affiliation Attribut Faux La dernière valeur est suffisante.
La liste complète des éléments de données du modèle conceptuel de l’« ETS Boissons » est
fournie en Annexe 1.
4.3.2. La causalité des changements sur les données

Durant l’analyse des changements sur les valeurs des données, nous devons analyser les
causalités existantes entre elles. Il serait suffisant d’identifier les changements causales et
d’assumer que les autres changements non identifiées sont non-causales. Cela facilitera la
tâche des concepteurs. Comme nous l’avons déjà expliqué, les changements peuvent toucher
des attributs ayant une rétrospection avec la valeur « Faux » mais qu’ils ont, du fait qu’ils sont
déterminants, un effet sur d’autres attributs qui ont une rétrospection avec la valeur « Vrai ».
La capture de ces changements doit être automatisée. Certains mécanismes sont créés pour
permettre l’identification des changements au niveau des systèmes opérationnels qui
représentent la source de données du datawarehouse. Par exemple, au niveau du SI de
l’« ETS boissons » existe une relation entre l’adresse du client et la région de ventes à qui
l’adresse appartient. Donc, nous pouvons dire que l’adresse du client détermine la région de
ventes. Cette relation est la même utilisée dans le processus de normalisation. Cependant, le
but ici est différent et il concerne la synchronisation des changements sur les valeurs des
attributs afin d’assurer une consistance temporelle. Ainsi, le terme « causalité » est adopté
afin de distinguer ce besoin qui est spécifique au datawarehousing. Le système opérationnel
qui enregistre les données détaillées des clients ne se soucie pas des régions de ventes. Quand
un client déménage, le fait qu’un changement de région doit être constaté n’est pas apparent.
Les concepteurs du datawarehouse doivent gérer ce problème.
Sans cela, le datawarehouse peut enregistrer des données inconsistantes. Si l’adresse d’un
client change, la région doit être contrôlée et mise à jour et cela, si nécessaire, à l’instant
même du changement de l’adresse. Quand les données relatives aux adresses et aux régions se
trouvent dans des systèmes sources différents, la synchronisation des ces changements devient
difficile à implémenter. Si la synchronisation n’est pas réalisée, certaines requêtes invoquant
l’historique des ces attributs peuvent donner des résultats incohérents.
85
4.3.3. Le modèle du « Point »

a. La modélisation par les points [Source : Todman2001]
Dans ce qui suit, nous allons présenter une méthodologie de développement des modèles
conceptuels pour les datawarehouses. Cette méthodologie est appelée : la méthode du point
(en Anglais : ‘Dot Modeling’).
La méthode du point est basée sur les pré-requis simplifiés des modèles dimensionnels qui ont
été décrits dans le chapitre sur les datawarehouses. C’est une méthodologie complète qui
permet aux non-informaticiens de construire leurs propres modèles conceptuels qui reflètent
leur perception de l’entreprise d’une manière dimensionnelle. Elle fournit aussi une approche
structurée pour la construction du modèle logique (généralement relationnel) à partir du
modèle conceptuel.
La méthode est apparue en 1997 et elle est, depuis cette date, utilisée dans des projets réels.
Elle a reçu des opinions positives des personnes qui l’ont utilisée. Le nom a été donné par un
utilisateur. Cette dénomination (le point) vient du fait que le centre de la partie
comportementale du modèle, les faits, sont représentés par un point. La méthode est apparue
comme une sorte d’évolution de l’utilisation des concepts dimensionnels et elle a évolué pour
s’adapter aux besoins des modèles orientés clients.
Nous commençons par modéliser le comportement. La figure suivante représente la
conception d’un rapport sous forme d’un tableau à deux dimensions. Ce type de rapport est
familier et est souvent utilisé pour la restitution des données.
Rapport des ventes

Produit
Client
L’intersection des deux axes, qui est représenté par un point, contient des données sur la vente
d’un produit spécifique à un client spécifique. La donnée représentée par le point est
généralement numérique. Elle peut être atomique, comme le montant de la vente, ou
complexe et peut aussi inclure d’autres valeurs comme l’unité de vente et le profit dégagé.
86
Pour pouvoir représenter plus de trois dimensions dans la méthode du point, le point est placé
au centre du diagramme et les dimensions sont ajoutées autour du ledit point.
Branche Client
Région Produit
Fournisseur Temps
Ainsi, le modèle adopte la symétrie radiale des schémas en étoile.
Figure 4.3.1 : Le modèle du point
b. Les composants du modèle comportemental du point :

Il existe trois composants de base du modèle du point :
• Le point : il représente les faits. Le nom du modèle dimensionnel est appliqué aux faits.
Pour l’« ETS Boissons », les faits sont nommés « Ventes ».
• Les dimensions : chaque dimension est représentée dans le modèle par un nom.
• Les connecteurs : ils sont placés entre les faits et les dimensions de premier niveau et
entre les dimensions pour représenter leur structure hiérarchique.
Le modèle comportemental de l’« ETS Boissons » sera comme suit :
Type Région Manager
Région Vente
Boisson
Ventes
Client
Fournisseur
Les attributs des faits et des dimensionsTemps

ne sont pas représentés sur le modèle. Les attributs
Loisir sont décrits
séparément du modèle. La même règle est appliquée pour les besoins temporels.
Figure 4.3.2 : Le modèle du point comportemental de l’ « ETS Boissons »
87
La méthode utilise plusieurs documents de travail. Le premier document représente le modèle

conceptuel. Il contient :
• Le nom de l’application ou du modèle (ici : Vente « ETS Boissons »).
• Le diagramme conceptuel.
• La liste des attributs de la table des faits (ici : « quantité » et « valeur »). Pour chaque
attribut, une brève description est donnée.
Le deuxième document est appelé le « document des entités ». Il contient :

• Les dimensions comportementales.
• Les circonstances clients.
• Les segments dérivés.
Pour chaque entité, les éléments suivants sont précisés :
• Le nom de la dimension.
• La valeur de la rétrospection.
• L’attribut clé de la dimension.
• La fréquence des mises à jour.
Pour chaque dimension, les attributs sont listés dans d’autres documents. Pour chaque attribut,
nous précisons :
• Le nom de la dimension propriétaire.
• Le nom de l’attribut.
• La valeur de rétrospection.
• La fréquence des mises à jour.
• Les dépendances avec les autres attributs afin de définir les causalités.
• Une description de l’attribut : Métadonnées.
• La source : d’où vient cet attribut.
• Les transformations : préciser les transformations sur la donnée avant son transfert au
datawarehouse.
• Type de données (ex. : numérique).
Les informations sur les hiérarchies des dimensions sont précisées au niveau du document sur
les hiérarchies. Le document liste les noms des composants de la hiérarchie et contient aussi :
• La rétrospection de la hiérarchie.
88
• La fréquence de la capture.
• Métadonnées décrivant la hiérarchie.
c. Exemple d’un modèle du point complet orienté client :

Un projet très intéressant a été élaboré au Royaume-Uni pour une grande compagnie de
télécommunication. Leur objectif était de construire un modèle de données orienté client qui
couvre tous leurs besoins.
Plusieurs modèles comportementales du « point » ont été élaborés :

Call Usage (Utilisation) : Les types d’appels effectués, leur durée, leur coût,…
Payments (Règlements) : Le client a-t-il payé à temps ? Combien de fois a-t-il été relancé ?
Recurring Revenue (Revenues récurrents) : ex. : la facturation.
Nonrecurring Revenue (Revenues Non-récurrents) : ex. : Vente d’accessoire.
Order Fulfillment (Traitement Commandes) : Combien de temps dure le traitement des
commandes clients ?
Service Events (Evènement de service) : Les réclamations liées au service fourni.
Contacts : Chaque contact avec les clients.
En termes dimensionnels, cela signifie plusieurs modèles dimensionnels, chacun traitant un

sujet précis. Durant l’avancement du projet, un seul modèle orienté client a été proposé et
couvrant tous les objectifs de l’entreprise tels que exprimés par les utilisateurs.
La figure suivante illustre sept (7) modèles dimensionnels séparés partageant des dimensions.
Cela montre que même dans des situations complexes, il est facile de construire des modèles
dimensionnels séparés en utilisant les notations de la modélisation par le point.
89
Type Contact Type résultat Produit

Utilisation
Contact Tarif
Base
Type appareil
Traitement
Commande Compte
Revenue R
Produit Client Type
collection
Revenue NR Règlement
Evènement
Service Segments
Organisation
hiérarchique
4.3.4. Type Campagne
évènement
Figure 4.3.3 : Exemple d’un modèle du point d’une compagnie de télécom
90
La construction du modèle conceptuel détaillé « ETS Boissons »

Nous allons maintenant construire notre modèle conceptuel pour l’« ETS boissons » en
utilisant la méthode du point présentée précédemment. Dans la pratique, cette conception sera
organisée sous forme d’ateliers de développement par étapes.
Comme vous l’avez constatez, la méthodologie du point n’a pas été étudiée en détail. Comme
toute méthodologie, la méthode du point se compose d’un certain nombre de processus qui
s’enchaînent dans le but de construire le modèle conceptuel.
Les ateliers de travail seront décris dans ce qui suit. Le modèle conceptuel détaillé de
l’ « ETS Boissons » sera fournit en annexe (Annexe 1).
a. Atelier 1 : Stratégie de l’information

L’objectif de cet atelier est de permettre aux utilisateurs de développer leur propre modèle qui
reflète leur propre perception de leur environnement. L’équipe de travail sera composé de
consultants experts, utilisateurs clés et des techniciens IT. Le rôle principale des consultants
est superviser l’atelier, d’animer les discutions et d’aider l’équipe client dans leur processus
de conception. La présence d’un responsable senior est préconisée.
N’oublions pas que le facteur clé de succès d’un projet datawarehouse est de se concentrer sur
le métier et non pas sur la technologie.
L’atelier commence par définir clairement les objectifs de l’entreprise. Ces objectifs doivent
être :
• Mesurables,
• Limités dans le temps,
• Orientés clients.
Exemple : Augmenter la fidélité client de 5% dans les 3 prochaines années.
- Le modèle initial
Après une brève explication de la modélisation par le point, les participants commencent à
exprimer par le dessin leur vision du système.
Nous aurons un modèle qui ressemblerait à ça :
91
Revenue Manager
Boisson
Ventes
Profession Région Vente
Fournisseur
Temps Client
Figure 4.3.4 : Le modèle comportemental initial
- Le comportement
Nous expliquons aux participants la signification du point, qui est le comportement. Les
attributs de ce point constitueront le noyau du système. Les faits typiques sont « la valeur » et
« la quantité ». Nous devons aussi inclure des faits dérivés tels que « le profit » et « le
retour sur investissement » (ROI). Chaque attribut « fait » doit être numérique et sommable
ou semi-sommable.
Chaque fait mesurable et participant dans la mesure des objectifs doit avoir sa place dans le
datawarehouse. A ce stade, des questions doivent être posées sous forme de requêtes en
langage naturel afin de déterminer la manière d’utiliser ce fait.
Nous devons aussi connaître la granularité du temps pour chaque fait. L’idéal est d’opter pour
la plus fine granularité possible. Généralement, tous les faits partagent la même granularité.
Nous terminons par donner une description détaillée de chaque fait retenu.
- Les dimensions
Nous expliquons aux participants le sens de la dimension, et nous leur laissons le soin
d’exprimer leur besoin en dimensions.
- La construction du modèle
Le processus de construction doit être itératif : nous commençons par un modèle initial qui est
affiné au fur et à mesure du déroulement des travaux de l’atelier.
Pendant la construction, les informaticiens doivent traiter les points suivants :
• La disponibilité des données sources,
• L’architecture de la base de données cible,
• La qualité des données.
L’affinement du modèle se fait essentiellement par :
92
• La combinaison des dimensions,

• La hiérarchisation des dimensions,
• L’inclusion de certaines suggestions.
Voici donc le modèle affiné de l’« ETS Boissons » :
Région Manager
Boisson Région Vente
Ventes
Fournisseur
Client
Temps
- Documenter le modèle Loisir
Figure 5.3.5 : Le modèle du point comportemental affiné de l’« ETS Boissons »
Le modèle est documenté en élaborant les documents de travail déjà introduits et expliqués dans ce chapitre.
Parmi les documents les plus importants sont ceux liés aux entités et à la segmentation. Les
entités incluent les circonstances client et les dimensions du modèle comportemental. La
segmentation est en relation avec les segments dérivés, qui est la dernière composante de
notre MCG.
b. Atelier 2 : L’analyse des composants

L’objectif de cet atelier et d’analyser les composants du modèle créé et d’y ajouter d’autres
éléments de détail.
- Définir les attributs

L’objectif est de définir les attributs de toutes les dimensions du modèle. Pour cela, nous
utilisons un document de travail nommé : « Entités et segments ».
93
Voici donc un premier exemple concernant la dimension « Client » :

Modèle du point : Entités et segments
Nom entité Rétrospection Fréquence
Client Vrai Mensuelle
Métadonnée
Cette entité contient toutes les données détaillées des clients. Nous devons suivre les cycles de vie discontinus
et identifier les clients actifs et non-actifs.
Un client actif est celui qui a envoyé une commande durant les derniers 12 mois. Les périodes d’inactivité
doivent être préservées dans le système.
Nom attribut Nom Client PK ? N
Rétrospection Fréquence Dépendance
Faux Mensuelle Non
Métadonnée
Le nom du client
Source Transformation Type donnée
ADMIN Client Non Char 25
Nom attribut Adresse client PK ? N
Vrai Mensuelle Région Vente
Métadonnée
L’adresse du client
ADMIN client Non Char 75
Nom attribut Indicateur durée de vie PK ? N
Vrai Mensuelle Non
Métadonnée
Indicateur calculé sur la durée de vie du client. Les valeurs sont de 1 à 20.
ADMIN client SQL_package_crm_life_value.sql Numérique (2)
94
Le second exemple concerne la dimension « Boisson » :

Modèle du point : Entités et segments
Nom entité Rétrospection Fréquence
Boisson Vrai Mensuelle
Métadonnée
La dimension « Boisson » contient les données sur les boissons vendues par l’ « ETS Boissons ». Ces données
incluent les prix et les coûts.
Nom attribut Boisson.Coût_bouteille PK ? N
Vrai Mensuelle Non
Métadonnée
Le coût d’une bouteille de boisson, net après discount, en TTC et en incluant toutes les charges.
Stock Non Numérique (7,3)
Nom attribut Boisson.Taux_sucre PK ? N
Vrai Mensuelle Région Vente
Métadonnée
La contenance en sucre exprimée en pourcentage.
Stock Non Numérique (3,1)
Et ainsi, pour chaque entité du modèle, nous élaborons le document de conception en

respectant le format présenté ci-dessus et en remplissant toutes les cases.
- Analyse dimensionnelle des faits

Maintenant, pour chaque attribut de fait mesurable, nous examinons les dimensions y sont
associées pour définir les fonctions arithmétiques standards qui peuvent y être appliquées.
Cela nous permettra de distinguer entre les faits sommables et semi-sommables.
Par exemple :
• Les quantités d’un supermarché peuvent être sommées par produit et non pas par
client.
• Les balances bancaires peuvent être sommées à un instant donné mais pas dans le
temps.
• Le retour sur investissement (ROI) et tout autre pourcentage ne peuvent pas être
sommés mais on peut déterminer le maximum, le minimum ou la moyenne.
Le document édité pour ce besoin s’appelle : « document d’utilisation de fait ».
95
Voici un exemple pour notre étude de cas :

Modèle du point : utilisation fait
Nom modèle : Ventes « ETS Boissons »
Nom Fait : Valeur Fréquence : Journalière
Dimensions Somme Comptage Moyenne Min. Max.
1. Client ? ? ? ? ?
2. Boisson ? ? ? ? ?
3. Fournisseur ? ? ? ? ?
- Hiérarchies et groupements
Le but ici est simplement de fournir des métadonnées pour décrire les relations entre les
différents niveaux hiérarchiques des dimensions.
Le document utilisé ici s’appelle : « Hiérarchies et groupements ».
Voici un exemple :
Modèle du point : Hiérarchies et groupements
Nom modèle : Ventes « ETS Boissons »
Région vente
Client
Rétrospection Vrai Fréquence Mensuelle

Métadonnée
Cette hiérarchie enregistre le lien qui existe entre un client et la région de vente où il réside. Le client peut
déménager vers une nouvelle adresse dans une autre région de vente.
96
- La rétrospection
Nous avons déjà expliqué la signification de la rétrospection et son rôle dans les modèles
dimensionnels décisionnels. En pratique, il faut être capable d’expliquer ce concept à l’équipe
du client afin qu’ils puissent définir par eux-mêmes les valeurs de rétrospection pour chaque
entité du modèle.
Nous rappelons ici que la rétrospection est la capacité de regarder dans le passé. Chaque objet
de base de données peut avoir une des trois valeurs de rétrospection suivantes :
• Vrai : on garde la trace des changements donc on peut remonter le passé.
• Faux : On ne garde que la dernière valeur. Le passé est perdu.
• Permanent : la valeur de change pas.
- La granularité de la table « Temps »

Nous avons déjà discuté la granularité du temps des faits mesurables. Maintenant, nous
devons nous intéresser à la granularité temporelle des dimensions, des hiérarchies et des
attributs. Nous devons aussi déterminer le contenu de la table « Temps ».
Nous rappelons que nous fournirons le détail de la conception dans l’annexe 1.
Une fois la modélisation conceptuelle terminée, nous abordons la modélisation logique de

notre datawarehouse.
97
4.4. La modélisation logique du datawarehouse orienté CRM

Dans cette section, nous allons étudier les solutions d’implémentation logique de la
rétrospection dans les datawarehouses orientés CRM. La rétrospection est une des
composantes clés de notre modèle conceptuel qui a été introduite dans la section précédente.
Dans cette section, nous allons aussi présenter le modèle logique relationnel (vue « Client »
uniquement) de l’« ETS boissons », résultat de la transformation du modèle conceptuel.
En pratique, les concepteurs ont la tendance de transiter directement du modèle conceptuel au
modèle physique sans passer par le modèle logique. Cela implique l’écriture du LDD
(Langage de Définition de Données) à partir du modèle conceptuel. Cette pratique s’est
généralisée du fait que les bases de données relationnelles sont devenues la plateforme
d’implémentation de toutes les applications de base de données. Cela s’applique aux systèmes
opérationnels ainsi qu’aux systèmes décisionnels. Cependant, les datawarehouses peuvent ne
pas être implémentés sur des SGBD relationnels mais sur SGBD dimensionnels appelé aussi
systèmes OLAP. Actuellement, il n’existe pas de standard pour assister les concepteurs à
produire des modèles logiques sur des systèmes OLAP propriétaires. Dans ce cas là, une
certaine attention doit être accordée au processus de conception logique. Quand le système
cible n’est pas relationnel, il n’est pas possible de produire un modèle physique sauf si les
concepteurs ont une bonne connaissance du LDD propriétaire ou du processus
d’implémentation physique du SGBD en question.
4.4.1. L’implémentation de la rétrospection

Avant de passer en revue les solutions, rappelons les besoins qui doivent être satisfaits en
premier :
- Un « Reporting » actualisé et fiable des faits : dans un modèle dimensionnel, il est
important que chaque occurrence de fait soit jointe avec la bonne occurrence dimension
et avec la bonne valeur « Temps ». En réalité, on reconnaît que généralement cela ne
peut pas être satisfait complètement à cause des déficiences qui existent dans le
processus de chargement des données opérationnels.
- Une mise à jour fiable des changements de données : afin de répondre aux requêtes
sur les circonstances clients et la navigation dans les dimensions. Il est important de
s’assurer que les périodes de validité des dimensions, des relations et des attributs soient
98
enregistrées correctement. Une fois encore, la capacité à réaliser cela dépend de la

qualité et de la fiabilité des données sources.
a. L’utilisation des attributs d’existence

Nous allons maintenant étudier l’utilisation des attributs d’existence (cycle de vie) comme
une approche d’implémentation de la rétrospection. Le concept de l’existence a été expliqué
précédemment (Voir la section 2.5 : La gestion du « Temps »…), mais son application à tous
les composants d’un datawarehouse peut ne pas être entièrement claire. Le raisonnement est
le suivant :
Le « besoin temporel » d’une entité se rapporte à son existence (i.e. Cycle de vie). Dans
certaines circonstances, l’existence d’une entité est discontinue. Par exemple, une
boisson peut être vendue par l’« ETS boisson » durant une période de temps ensuite elle
est suspendue et retirée des ventes. Cette boisson peut réapparaitre (ré-exister) dans le
futur. Cette discontinuité dans le cycle de vie de la boisson peut avoir des conséquences
sur les requêtes du genre : « Combien de lignes de produits vendons-nous
actuellement ? ». Un autre exemple concerne les clients. Le retour des clients perdus est
entrain de devenir un objectif primordial des entreprises, spécialement dans des
domaines comme la télécommunication et les services financiers où la mobilité des
clients est grande. Quand un client revient, il est préférable de juste l’activer dans le
système en gardant les anciennes données et en préservant tout son historique et non pas
le créer de nouveau.
Une relation qui a besoin d’un « support temporel » peut être modélisée en relation n-m.
En utilisant la modélisation entité-relation (ER), cette relation va se transformer en une
entité intermédiaire entre les deux entités en relation. Comme le besoin temporel d’une
entité se rapporte à son existence, le traitement de la relation est quasiment le même que
le traitement des entités.
Un attribut doit réellement être considéré comme une propriété d’une entité. L’entité est
engagée dans une relation avec un ensemble de valeurs. Cette relation est de type n-m.
Un attribut qui a besoin d’un « support temporel » doit être modélisé sous forme d’une
entité intermédiaire entre l’entité principal et l’ensemble de valeurs sans avoir à l’ajouter
sur le diagramme. Comme pour les entités et les relations, le traitement des attributs se
rapporte à l’existence de sa valeur pendant une période de temps.
99
Le « support temporel » de chaque élément se rapportant aux circonstances client, à la

segmentation ou la structure dimensionnelle d’un datawarehouse sera implémenté en utilisant
les attributs d’existence. Si nous avons besoin d’un support temporel total, l’attribut doit être
composé de « la date début » et « la date fin » d’existence de l’occurrence et qui enregistre
ainsi toutes les périodes d’existence. Une valeur particulière est assignée à la date fin pour
signifier une période en cours. Voici le détail de l’implémentation :
- Pour le support temporel d’une entité qui peut avoir une existence discontinue,
une table séparée est requise qui contient la clé primaire de l’entité et une période
d’existence. Si l’existence est continue, la période est incluse dans l’entité principale.
- Pour le support temporel d’une relation entre des entités, une table séparée est
requise qui contient les clés primaires des entités participantes dans la relation et une
période d’existence.
- Pour le support temporel d’un attribut d’une entité, une table séparée est requise
qui contient la clé primaire de l’entité, une période d’existence et la valeur de
l’attribut.
Cette solution permet de résoudre beaucoup de problème lors de l’exécution des requêtes.
Voici quelques exemples :
• Combien de clients avons-nous perdus durant le dernier trimestre 2005,
comparativement à 2004 et 2003 ?
• Parmi les clients perdus, combien ont existé durant au moins une année ?
• Parmi ces clients, combien ont changé d’interlocuteur à cause d’un déménagement
dans l’année où ils nous ont quittés ?
• Combien de changements de prix a-t-il eu dans l’année où ils nous ont quittés ?
En utilisant notre solution, la première requête peut être exprimée comme suit :
Select ‘Q4 2005’ as trimestre, count(*)

From CustomerExist ce
Where ce.ExistenceEnd
Between ‘01/10/2005’ and ‘31/12/2005’
Union
Between ‘01/10/2004’ and ‘31/12/2004’
Union
Between ‘01/10/2003’ and ‘31/12/2003’
100
La réponse à la deuxième question est la suivante :

Between ‘01/10/2005’ and ‘31/12/2005’
And (ce.ExistenceEnd – ce.ExistenceStart) > 365
Union
Between ‘01/10/2004’ and ‘31/12/2004’
Union
Between ‘01/10/2003’ and ‘31/12/2003’
Pour répondre à la troisième question, nous supposons qu’il existe un attribut d’existence
séparé pour la relation entre le client et la zone de vente. La requête aura la syntaxe suivante :

From CustomerExist ce, CustomerSalesAreaExist csa
Between ‘01/10/2005’ and ‘31/12/2005’
And (ce.ExistenceEnd – ce.ExistenceStart) > 365 And ce.CustomerCode = csa.CustomerCode
And csa.CustomerStart
Between ’01/01/2005’ and ‘31/12/2005’
Union
Between ‘01/10/2004’ and ‘31/12/2004’
Between ’01/01/2004’ and ‘31/12/2004’
Union
Between ‘01/10/2003’ and ‘31/12/2003’
Between ’01/01/2003’ and ‘31/12/2003’
101
Afin de répondre à la quatrième question, nous supposons aussi qu’il existe un attribut
d’existence séparé pour le prix de la boisson.
Select ‘Q4 2005’ as quarter, ce.CustomerCode, Count(distinct spe.DrinkCode)

From CustomerExist ce, SalesPriceExist spe, Sales s, Time t
Between ‘01/10/2005’ And ‘31/12/2005’
And (ce.ExistenceEnd – ce.ExistenceStart) > 365 And ce.CustomerCode = s.CustomerCode
And s.DrinkCode = spe.DrinkCode And s.TimeCode = t.TimeCode
And t.Year = 2003 And spe.ExistenceStart
Between ‘01/10/2005’ And ‘31/12/2005’
Group By quarter, ce.CustomerCode Having Count(distinct spe.DrinkCode) > 5
Union
Between ‘01/10/2004’ And ‘31/12/2004’
And t.Year = 2002 And spe.ExistenceStart
Between ‘01/10/2004’ And ‘31/12/2004’
Union
Between ‘01/10/2003’ And ‘31/12/2003’
Cette requête
Anddonne la =liste
t.Year 2001des clients qui ont quitté l’« ETS Boisson » dans le dernier trimestre de l’année tout
And spe.ExistenceStart
Between ‘01/10/2003’ And ‘31/12/2003’
en ayant eu plus de cinq changements de prix dans l’année.
b. L’utilisation de la dimension « Temps »

Nous pouvons aussi utiliser la dimension « Temps » afin de simplifier l’écriture des requêtes
complexes.
Le rôle de la dimension « Temps » est de fournir un mécanisme de regroupement et
d’expression de contraintes sur les faits. Cependant, il est approprié de permettre aux
utilisateurs du datawarehouse d’exprimer des contraintes de temps sur d’autres composants du
modèle en utilisant la même approche que celle concernant les faits.
‘Ralph Kimball’ [Source : Kimball/Ross2002] proscrit l’utilisation de la dimension
« Temps » avec les autres dimensions car la sémantique du temps pour les dimensions et
différente de sa sémantique pour les faits et cela peut induire en erreur. Cette règle est incluse
implicitement dans les modèles en étoile et en flocon puisque la dimension « Temps » est liée
uniquement à la table des « Faits ». Il n’y a pas de relation entre la dimension « Temps » et les
autres dimensions.
En considérant cela, deux points émergent :
102
- Premièrement, la dimension « Temps » fournit une interface simple aux utilisateurs

pour formuler les requêtes. Cette interface empêchera les utilisateurs d’utiliser la
dimension « Temps » avec les autres entités.
- Deuxièmement, certaines requêtes de navigation dimensionnelle sont plus faciles à
exprimer si les jointures sont permises entre les autres dimensions et la
dimension « Temps ».
Revenant à la première requête de la section précédente : Combien de clients avons-nous
perdus durant le dernier trimestre 2005, comparativement à 2004 et 2003 ? En utilisant
la dimension « Temps », la requête peut être exprimée ainsi :
Select t.quarter, count(*)

From CustomerExist ce, Time t
Where ce.ExistenceEnd = t.TimeCode
And t.Quarter in (‘Q4 2005’,’Q4 2004’,’Q4 2003’)
Group By t.Quarter
La deuxième requête : Parmi les clients perdus, combien ont existé durant au moins une
année ? devient en utilisant la dimension « Temps » ainsi :
Select t.quarter, count(*)

From CustomerExist ce, Time t
Where ce.ExistenceEnd = t.TimeCode
And t.Quarter in (‘Q4 2005’,’Q4 2004’,’Q4 2003’)
And (ce.ExistenceEnd - ce.ExistenceStart) > 365
Group By t.Quarter
La troisième : Parmi ces clients, combien ont changé d’interlocuteur à cause d’un
déménagement dans l’année où ils nous ont quittés ? sera exprimée comme suit :
Select t1.quarter, count(*)

From CustomerExist ce, CustomerSalesArea csa, Time t1, Time t2
Where ce.ExistenceEnd = t1.TimeCode
And t1.Quarter in (‘Q4 2005’,’Q4 2004’,’Q4 2003’)
And ce.CustomerCode = csa.CustomerCode
And csa.ExistenceStart = t2.TimeCode
And t2.Year = t1.Year
Group By t1.Quarter
103
La quatrième : Combien de changements de prix a-t-il eu dans l’année où ils nous ont
quittés ? sera exprimée comme suit :
Select t1.quarter, ce.CustomerCode, Count(distinct spe.DrinkCode)

From CustomerExist ce, SalesPriceExist spe, Sales s, Time t1, Time t2, Time t3
Where ce.ExistenceEnd = t1.TimeCode
And t1.Quarter in (‘Q4 2005’,’Q4 2004’,’Q4 2003’)
And ce.CustomerCode = s.CustomerCode
And s.DrinkCode = spe.DrinkCode
And spe.ExistenceStart = t2.TimeCode
And s.TimeCode = t3.TimeCode
Group By t1.Quarter, ce.CustomerCode
Having Count(distinct spe.DrinkCode) > 5
Ainsi, nous pouvons conclure qu’en mettant en relation la dimension « Temps » avec les autres dimensions,
l’écriture de certaines requêtes temporelles devient plus simple.
Voici une partie du schéma de l’« ETS Boisson » modifiée pour inclure ces nouvelles
relations :
Client
Ventes
Temps Boisson
Figure 4.4.1 : L’implémentation de la rétrospection en utilisant la dimension « Temps »
Ce changement dans l’approche conventionnelle de modélisation rend les modèles

dimensionnels complexes en perdant leur figure simple. La simplicité est une condition des
modèles dimensionnels. En proposant cette idée, nous avons créé un nouveau problème à
résoudre. Il est important que la figure dimensionnelle simple soit préservée. En clair, nous ne
pouvons pas présenter un tel modèle aux utilisateurs.
La solution peut être de supprimer la dimension « Temps » du modèle. Nous avons dit que la
dimension « Temps » est toujours incluse dans les modèle dimensionnel car le « Temps » est
toujours une dimension d’analyse dans les datawarehouses qui sont nativement « historisée ».
De cela, l’inclusion explicite de la dimension « Temps » peut s’avérer non-nécessaire et qui
devient, de ce fait, implicite. Cela signifie que la présence de la dimension « Temps » sur le
104
diagramme ne sera pas explicite, mais posera un problème avec la méthodologie de

modélisation conceptuelle entité-relation (ER). Avoir des entités implicites dans le modèle
créera une confusion totale. La méthode du point n’a pas cette limitation et sera adaptée pour
répondre à ce nouveau besoin.
Cependant, la dimension « Temps » possède des attributs qui sont différents d’une application
à une autre et ce n’est pas une question qui peut être ignorée.
Dans la méthode du point, nous pouvons résoudre ce problème en ajoutant une table qui va
satisfaire à ces besoins précédemment couverts par une dimension « Temps » explicite. La
table aura comme nom : Temps_Point (Dot_Time).
La suppression de la dimension « Temps » explicite du modèle conceptuel et son ajout dans le
modèle logique est une étape en avant dans l’approche de conception des datawarehouses.
C’est une manière de reconnaître que les datawarehouses sont de vraies applications
temporelles et que le support du temps est implicite dans la solution.
4.4.2. Choisir la solution d’implémentation

Le choix d’une solution dépend des besoins et du type de datawarehouse en construction.
La rétrospection fournit un mécanisme permettant aux circonstances et aux dimensions d’être
considérées comme une source d’information. Si la nécessité de réaliser des analyses
historiques sur un composant de la structure dimensionnelle est exprimée alors la valeur de
rétrospection de ces composants sera « Vrai ». S’il y a un besoin en requêtes de durée statique
ou de détection de transition alors la solution la plus appropriée est de prévoir des attributs
d’existence sous forme de date et heure débute et date et heure fin.
105
Le choix d’une solution se fait suivant le tableau ci-dessous :

Val. Circonst. /Dimensions Relations Attributs
Vrai Besoin d’analyse de durée Besoin d’analyse de durée statique ou Besoin d’analyse de durée
statique ou de détection de de détection de transition ? statique ou de détection de
transition ? transition ?
Oui Non Oui Non Oui Non
Période Marque de temps Période La hiérarchie change-t- Période La hiérarchie
d’existence d’existence elle souvent ? d’existence change-t-elle
souvent ?
Oui Non Oui Non
Période Marque Marque Marque
d’existence de temps de de
temps temps
Faux Attribut d’existence Vrai/Faux Attribut d’existence Vrai/Faux Attribut d’existence Vrai/Faux
Perm. Pas de changement Pas de changement Pas de changement
4.4.3. Le schéma logique relationnel « Clients »

L’implémentation d’une rétrospection en « Vrai » pour une entité, un attribut ou une relation
nécessite l’existence d’une durée de vie de l’objet. Cela doit être implémenté sous forme
d’une période marquant une « date début » et une « date fin ». L’introduction de telles
périodes change la structure des entités. Par exemple, les circonstances client ont une
rétrospection en « Vrai » dans le modèle de l’« ETS Boisson ». Elle est aussi en « Vrai » pour
les relations entre les circonstances client d’un côté et les régions de vente et les adresses
client de l’autre côté. Les périodes d’existence doivent être ajoutées à ces objets comme le
montrera le schéma et les tableaux suivants.
Loisirs
Existence Existence
Client
Adresse client Client
Région Ventes
Client
Région Ventes
Figure 4.4.2 : Le schéma logiques des circonstances « Clients »

Chaque relation du modèle sera décrite dans ce qui suit :
106
Relation : Client
Code_Client
Nom_Client
Code_Loisirs
Date_Création
Clé primaire(Code_Client)
Clé étrangère(Code_Loisirs référence Loisirs.Code_Loisirs)
Relation : Existence Client

Code_Client
Exist_Client_Début
Exist_Client_Fin
Clé primaire(Code_Client, Exist_Client_Début)
Clé étrangère(Code_Client référence Client.Code_Client)
Relation : Existence Adresse Client

Code_Client
Exist_Adr_Client_Début
Exist_Adr_Client_Fin
Adresse_Client
Clé primaire(Code_Client, Exist_Adr_Client_Début)
Relation : Région Vente Client

Code_Client
Code_Région_Vente
Exist_Code_Région_Vente_Début
Exist_Code_Région_Vente_Fin
Clé primaire(Code_Client, Code_Région_Vente, Exist_Code_Région_Vente_Début)
Clé étrangère(Code_Région_Vente référence Région Vente.Code_Région_Vente)
Relation : Loisirs
Code_Loisir
Nom_Loisir
Clé primaire(Code-Loisir)
Relation : Région Vente

Code_Région_Vente
Nom_Région_Vente
Clé primaire(Code_Région_Vente)
107
Les questions liées aux performances du modèle seront traitées lors de l’implémentation de la
solution, et certaines dénormalisations du schéma ci-dessus seraient appropriées.
4.4.4. Les contraintes de la rétrospection

Un des rôles du modèle logique est de répondre à toutes les contraintes imposées par
l’implémentation de la rétrospection. L’introduction d’un support total du temps ajoute des
besoins additionnels en termes de contraintes.
a. Les contraintes du double-comptage

Le double-comptage se manifeste lorsque la jointure entre plusieurs tables retourne plus
d’enregistrement que prévu. Ce problème est généralement évité si les règles générales de la
modélisation dimensionnelle ont été respectées.
Cependant, l’introduction des attributs d’existence augmente le risque d’erreurs en changeant
la nature des relations dans un datawarehouse de simples (1:n) à complexes (n:m).
Ce problème est plus clair en utilisant des exemples. La table suivante concerne l’existence
des coûts des bouteilles :
Code Boisson Début Fin Coût bouteille

4504 27/02/2002 31/03/2005 43,60
4504 31/03/2005 A ce jour 47,90
Le coût de la bouteille a un attribut d’existence. L’existence est continue, mais un changement

de coût a eu lieu. Cela a donné naissance à un nouvel enregistrement.
La table suivante montre un fait de vente détaillant une vente de la boisson précédente :
Code Boisson Jour Quantité Valeur
4504 31/03/2005 5 249,50
En suite, la requête suivante est exécutée et essaye de lister les valeurs de vente et les coûts :
Select w.Nom_Boisson, s.Valeur ‘Revenue’, sum(s.quantité * w.coût_bouteille) ‘Coût’

From Ventes s, Boisson w, ExistenceCoutBouteille bce
Where w.Code_Boisson = s.Code_Boisson
And s.Code_Boisson = bce.Code_Boisson And s.Jour
Between bcd.Date_Début and bce.Date_Fin
Group By w.Nom_Boisson
108
Le résultat retourné est :

Nom Boisson Revenue Coût
Hamoud 249,50 218,00
Hamoud 249,50 239,50
Le résultat est que la vente a été doublement comptée. Le problème s’est manifesté car la date
du « 31/03/2005 » appartient à deux intervalles.
La solution de changer la date fin du premier enregistrement à : « 30/03/2005 ».
Donc, l’entrelacement des périodes d’existence dans un modèle dimensionnel est interdit.
b. Les contraintes d’intégrité référentielle

Plusieurs contraintes d’intégrité référentielle de base peuvent être citées :
- La période d’existence d’un objet subordonné doit être contenue dans une seule période
d’existence de l’objet subordonnant.
- Durant une période d’existence d’une entité, tous les attributs de l’entité doivent existés.
Si une entité à une rétrospection « Vrai » :
- On peut avoir des attributs avec une valeur de rétrospection « Vrai ». Les durées de vie
de ces attributs doivent correspondre aux périodes de vie de l’entité. Si l’entité cesse
d’exister alors tous ces attributs avec une rétrospection « Vrai » devront cesser d’exister
au même temps.
- On peut avoir des attributs avec une valeur de rétrospection « Faux ». Ces attributs
peuvent changer uniquement si l’attribut d’existence de l’entité indique qu’elle existe.
Sinon, ils ne peuvent pas changer de valeur.
Si une entité à une rétrospection « Faux » :
- On peut avoir des attributs avec une valeur de rétrospection « Vrai ». Si l’entité cesse
d’exister, alors les attributs avec une rétrospection « Vrai » doivent cesser d’exister au
même temps. Quand l’entité change de non-existante à existante, ces attributs doivent
commencer un nouvel intervalle d’existence au même temps.
- On peut avoir des attributs avec une valeur de rétrospection «Faux ». Ces attributs
peuvent changer seulement si l’attribut d’existence de l’entité indique que celle-ci
existe. Ils ne peuvent pas changer si l’entité n’existe pas.
c. Les contraintes de suppression
109
Il appartient aux concepteurs du datawarehouse de déterminer les valeurs de rétrospection à

appliquer pour chaque objet de base de données.
Les règles fixant les violations des contraintes d’intégrité référentielle relatives aux
suppressions (dans les bases de données relationnelles) doivent être appliquées à la notion
d’existence. Quand une dimension change de statu d’existence pour devenir logiquement non-
existante, cela équivaut à une suppression logique de l’entité. L’application des règles doit
être sélective.
- La suppression en cascade ne peut être utilisée car elle pourrait supprimer les faits et
créer une incohérence dans la base de données.
- La suppression des relations ne peut pas être utilisée. Si cela est fait, les requêtes
d’agrégation des faits en utilisant les dimensions concernées par la suppression
donneront des résultats faux.
- La seule méthode de traiter avec les changements d’existence est d’utiliser des effets
restrictifs. Cela signifie que quand l’existence d’une dimension cesse, toutes ses
relations de références doivent avoir leurs existences terminées avant de terminer
l’existence de la dimension.
Donc, une attention particulière doit être accordée aux contraintes imposées par
l’implémentation de la rétrospection.
Enfin, nous rappelons que nous avons traités uniquement la modélisation logique de la vue
« Clients » car il s’agit du seul vrai point qui différencie les datawarehouses orientés CRM
des datawarehouses traditionnels.
110
4.5. L’implémentation physique du système

Dans cette section nous allons étudier quelques points relatifs à l’implémentation et au
fonctionnement physique du datawarehouse orienté CRM.
Le premier point important à traiter dans tous les projets de datawarehouse est celui relatif à
son alimentation qui se caractérise par un flux de données continuel des systèmes sources vers
le datawarehouse. Ce processus de chargement de données commence par une extraction des
données. Les données sont ensuite contrôlées pour déterminer leur qualité avant d’être
transformées et chargées dans le datawarehouse. La qualité des données est une vraie
problématique pour les concepteurs de datawarehouses puisque une mauvaise qualité de
données constitue une menace pour la réussite de tout le projet.
Aussi, nous devons analyser ce qui se produit au niveau du datawarehouse lorsque des
changements se produisent au niveau des systèmes sources. Les changements peuvent être
insignifiants sans aucun impact comme ils peuvent être profonds et importants. Citons
l’exemple de l’introduction d’un système ERP qui va créer une nouvelle source de données
majeure du datawarehouse.
Ensuite, il y’a la nécessité de faire fonctionner le datawarehouse dans un environnement actif
et évolutif. Chaque jour, des nouvelles données sont extraites, contrôlées qualitativement,
transformées, chargées et agrégées.
Cette section est inspirée des travaux de ‘R. Kimball’, ‘M. Ross’ et ‘C. Todman’ (voir
bibliographie : [Kimball/Ross2002], [Todman2001])
4.5.1. L’architecture physique du datawarehouse orienté CRM

Rappelons les quatre caractéristiques de base d’un SGBD qui sont :
1. Evolutivité. La capacité de la base de données à s’adapter aux changements dans
l’organisation et dans la communauté des utilisateurs. Cela inclue les capacités de
monté en charge en terme de volume de données, d’applications et d’utilisateurs.
2. Disponibilité. S’assurer que les données sont structurées et peuvent être vues de
différentes manière par des applications différentes et des utilisateurs différents.
3. Partage. Les données sont accédées par l’organisation entière.
4. Intégrité. Améliorer la qualité, maintenir l’existant et assurer la sécurité.
111
Dans un environnement décisionnel, nous ajoutons les contraintes spécifiques suivantes :

1. Les accès utilisateurs sont non-structurés.
2. Le besoin en information concerne un plus grand nombre d’utilisateurs avec des
besoins différents.
3. Le système doit être capable de répondre aux changements de stratégie d’entreprise en
un temps minime.
4. Les résultats des requêtes doivent être fiables et cohérents.
Afin de répondre à ces besoins, l’architecture EASI (Evolvability, Availability, Sharability,

Integrity) suivante est proposée :
Données
Données Segmentation Gestion des Centres locales
externes
contacts d’appels
Applications Analyse Data

CRM des vantes Mining
Analyse des Données Analyse

compagnes locales
du marché
Base de données du Datawarehouse
Processus VIM (Validation, Intégration, Mappage)

Méta
données
Systèmes sources
Figure 4.5.1 : L’architecture EASI du système
L’élément central de cette architecture est la base de données du datawarehouse. Cette base de
données contient le niveau le plus détaillé (en termes de granularité) des données que
l’entreprise a besoin de stocker. Cette base est alimentée par les systèmes opérationnels.
Cette base supporte les applications CRM qui sont capables d’y puiser les données. Ces
applications gèrent aussi leurs propres données.
Les applications CRM sont totalement indépendantes. Elles peuvent fournir des données à
d’autres systèmes et, dans certains cas, mettre à jour les systèmes sources.
112
Le point le plus important à noter est que la base de données du datawarehouse est une
ressource disponible pour toutes les applications CRM.
Nous allons maintenant décrire les autres composants du modèle.
4.5.2. La couche VIM

Avant d’être stockées dans le datawarehouse, les données doivent se conformer à des
contraintes rigoureuses qui concernent leur structure et leur intégrité. Les données sont
traitées dans le processus « VIM » : Validation, Intégration, Mappage. Le processus VIM
constitue l’élément de base du contrôle de la qualité des données du datawarehouse.
a. La validation des données

Il s’agit de l’étape la plus importante du processus. Les prises de décision ne peuvent en
aucun cas se baser sur des données de mauvaise qualité. Si la qualité n’est pas assurée, les
utilisateurs perdront leur confiance dans le système et cesseront de l’utiliser.
En réalité, Les données sources peuvent être :
Absentes (ou partiellement absentes),
Erronées,
Périmées,
Inconsistantes,
Confuses.
- Données absentes
La cause principale de l’absence de données est un défaut de rigueur lors de la saisie
(collecte) des données au niveau des systèmes sources. Nous pouvons envisager deux
approches pour combler cela :
• L’utilisation des valeurs par défaut,
• Le rejet de l’enregistrement : il y a trois types de rejets :
Un rejet permanent : l’enregistrement est simplement rejeté et ne sera
jamais chargé dans le datawarehouse.
Un rejet pour correction et réessayage : les données rejetées seront
mises dans un fichier particulier pour correction. Après correction, les
données vont être soumises de nouveau au processus de validation.
Un réessayage automatique : dans certains cas de figure, un simple
réessayage suffit à régler le problème.
113
- Données erronées
Il existe plusieurs types de données erronées :
• Valeurs n’appartenant pas à des intervalles ou listes de valeurs valides : celles-
ci sont simples à reconnaitre. Exemple : sexe du client = ‘Z’ au lieu de ‘M/F’.
• Erreurs de référencement qui violent les contraintes d’intégrité référentielle :
L’enregistrement contient une clé étrangère qui ne correspond à aucun
enregistrement parent. Quand cette erreur est détectée, il est recommandé de
rejeter l’enregistrement incriminé car il peut être la cause d’incohérences dans
les résultats des requêtes. Toutefois, il faut prévoir des processus de traitement
de ces erreurs et réessayer pas la suite d’intégrer l’enregistrement.
• Erreurs valides : ce sont des erreurs qui sont presque impossibles à détecter. Il
s’agit de valeurs qui ont été saisies incorrectement mais qui restent valides. Par
exemple, on a saisi la valeur 26 dans le champ « âge du client » au lieu de 62.
Ces erreurs doivent être corrigées au niveau des systèmes opérationnels.
- Données périmées
Les données périmées sont le résultat d’une fréquence de synchronisation insuffisante des
données relatives aux circonstances client changeantes entre les systèmes opérationnels et le
datawarehouse. Par exemple, l’adresse du client a changé au niveau du système opérationnel
mais ce changement n’a pas été répercuté au niveau du datawarehouse. La solution pour ce
type d’erreur est de revoir la fréquence de chargement et de synchronisation des données.
- Données inconsistantes
L’inconsistance des données du datawarehouse est le résultat des dépendances de données que
les systèmes opérationnels ne gèrent pas. Prenons l’exemple suivant : nous avons créé une
segmentation des régions de ventes en se basant sur les adresses client. Cette segmentation est
gérée uniquement par le datawarehouse. Quand un client change d’adresse, le datawarehouse
effectue les ajustements nécessaires au niveau des circonstances clients. Le segment
« Région », ou tout autre segment dépendant, sont mis à jour. Ce changement est sous le
contrôle exclusif du datawarehouse. Les effets causals des changements de circonstances sur
les segments dépendants sont difficiles à gérer et sont souvent sources d’inconsistances dans
les données.
114
- Données confuses
Les données confuses peuvent se produire quand un changement de rétrospection est effectué
et que la représentation du temps n’a pas été corrigée. Par exemple, à cause d’une application
incorrecte de la rétrospection, lorsqu’un changement d’adresse se produit, la nouvelle adresse
est appliquée aux données comportementales historisées par confusion.
La solution :
Afin de fournir une approche de validation flexible, nous devons construire des règles de
validation en utilisant les métadonnées. Voici un exemple de modèle de validation.
Attribut par Intervalle attribut

défaut Attribut
Liste valeurs
attribut
Figure 4.5.2 : Le modèle des métadonnées de validation
Les attributs des tables du modèle de validations sont les suivants :

Table : Attribut
ID Attribut
Nom Table
Nom Attribut
Type données
Rétrospection
Table : Intervalle Attribut

ID Attribut
Valeur Min
Valeur Max
Table : Attribut par défaut

ID Attribut
Valeur par défaut
115
Table : Liste Valeurs Attribut

ID Attribut
Valeur
b. L’intégration des données

La deuxième couche du processus « VLM » concerne l’intégration des données. Cette couche
s’assure que le format des données est correct. Cette intégration s’assure, par exemple, que
toutes les dates soient au format « jj/mm/aaaa ».
Quand les formats de données sont standardisés au niveau d’une entreprise, le besoin de
manipuler et de transformer les données est minime. Cette intégration doit être aussi
implémentée en utilisant les métadonnées. Notre modèle devient ainsi :
Source Attribut Transformation

Attribut Attribut
Transformation
Figure 4.5.3 : Le modèle des métadonnées de transformation
Les attributs des tables du modèle de validations sont les suivants :

Table : Attribut
ID Attribut
Nom Table
Nom Attribut
Type données
Format donnée
Description
Table : Source Attribut

ID Source Attribut
Nom Source Attribut
Type Donnée
Format Donnée
Description
Table : Transformation
ID Processus Transformation
116
Nom Processus Transformation

Type Processus Transformation
Description
Table : Transformation Attribut

ID Attribut
ID Source Attribut
ID Processus Transformation
c. Le mappage des données

Cette couche mappe les données sources vers le format de destination. Le rôle de cette couche
est de faciliter les changements futurs dans les systèmes sources.
Afin de répondre à ce besoin, notre modèle de métadonnées devient ainsi :
Source Attribut Transformation Attribut

Attribut
Source Donnée Transformation
Figure 4.5.4 : Le modèle des métadonnées de mappage
117
Les attributs de la source sont :

Table : Source Donnée
ID Source
Nom Source
Application Source
Type Fichier
Format Interface
Plateforme Source
Processus Extraction
Fréquence Extraction
Description
Table : Source Attribut

ID Source
ID Source Attribut
Nom Source Attribut
Type Donnée
Format donnée
Description
Voici enfin le modèle complet des métadonnées du processus « VIM ».
Liste valeurs
attribut
Attribut par Intervalle attribut

défaut Attribut
Source attribut Transformation

attribut
Source donnée
Transformation
Figure 4.5.5 : Le modèle complet des métadonnées de la couche VIM
4.5.3. L’alimentation du datawarehouse

Le datawarehouse est alimenté à partir des sources de données se trouvant dans
l’environnement transactionnel de l’entreprise. Le processus de chargement des données
118
transactionnelles nécessite un traitement périodique des données sources afin de sélectionner

les données à intégrer dans le datawarehouse. Les données sélectionnées dans
l’environnement transactionnel sont soumises au processus « VIM » avant le chargement.
Extraction, VIM,
Chargement
Sources DWH
Figure 4.5.6 : L’extraction et le chargement des données
Le processus du chargement à partir des processus transactionnels est d’une importance

spéciale car beaucoup de ressources machines peuvent être consommées.
Il existe deux types de chargement de données vers un datawarehouse :

1. Le chargement initial (un processus One-Shot),
2. les chargements incrémentaux (les mises à jour périodiques).
Le chargement initial concerne essentiellement les données sur les circonstances. Ce

chargement inclut la création des clients, des produits, des promotions et des données
géographiques. Le chargement initial des données comportementales est effectué lorsqu’il
existe des données historiques qui doivent être chargées.
Si le chargement initial échoue, il est relativement simple d’annuler la transaction et de
recommencer. Cela n’est pas toujours applicable avec les chargements incrémentaux de mise
à jour.
Le chargement incrémental (appelé aussi : rafraichissement des données) est un processus qui
est exécuté périodiquement. C’est le processus le plus important.
Le rafraîchissement des données consomme beaucoup de ressources machines. Il est exécuté
selon une fréquence régulière qui peut être quotidienne. La fréquence dépend de la vivacité de
l’environnement transactionnel de l’entreprise.
119
La figure suivante illustre ce rafraîchissement :
Supprimer
Ajouter
Modifier
Supprimer
DWH
M-à-j
Ajouter
Modifier Sources
Figure 4.5.7 : Le rafraîchissement des données
4.5.4. Le modèle physique des données

La base de données du datawarehouse est l’incarnation physique du Modèle Conceptuel. En
clair, le modèle physique est similaire, ou presque, au modèle conceptuel d’origine.
Néanmoins, le modèle physique dépend du SGBD choisi et des besoins en performance.
Supposons que le SGBD choisi est relationnel (ce qui est généralement le cas) et essayons de
construire le modèle physique en gardant l’aspect général du modèle conceptuel.
Voici le modèle présenté en parties :

• Partie A : Circonstances Client Non-Changeantes (Rétrospection = ‘Faux’ ou ‘Perm’)
Client
Figure 4.5.8 : Le modèle physique des circonstances « Client » non-changeantes
120
Voici les attributs fixes de la table « Client » :
Table : Client
Titre
Nom
Date de Naissance
Sexe
N° Téléphone
• Partie B : Circonstances ‘Clients’ Changeantes (Rétrospection = Vrai)
Adresses Situation Enfants

familiale
Epouses Clients Revenus
Loisirs Professions Employeurs
Figure 4.5.9 : Le modèle physique des circonstances « Clients » changeantes
Les attributs de cette partie sont :

Table : Adresses
ID Client
Adresse
Date Début
Date Fin
Table : Situation familiale

ID Client
Situation familiale
Date Début
121
Date Fin
Table : Enfants
ID Client
Nom Enfant
Date de naissance Enfant
Table : Epouses
ID Client
Nom Epouse
Date de naissance Epouse
Table : Revenus
ID Client
Revenu
Date Début
Date Fin
Table : Loisirs
ID Client
Loisir
Date Début
Date Fin
Table : Professions
ID Client
Profession
Date Début
Date Fin
Table : Employeurs
ID Client
Nom Employeur
Adresse Employeur
Catégorie Employeur
Date Début
Date Fin
122
• Partie C : Le modèle comportemental
Classe
Fournisseur Boisson Région
Ventes Boissons
Vente Accessoire
Client Visite prise
Produit Visite
Figure 4.5.10 : Le modèle physique du comportement
123
• Partie D : Les segments dérivés
Client
Segment Client
Type segment Segment marché Valeur attribut

marché segment
Figure 4.5.11 : Le modèle physique des segments dérivés
Voici les attributs de ces tables avec un exemple de valeurs d’attributs :

Table : Type Segment Marché
ID Type Segment Marché LT217
Description Type Segment Marché ‘Segment Revenu’
Table : Segment Marché

ID Type Segment Marché LT217 LT217
ID Segment Marché 04 05
Description Segment Marché ‘Revenu Moyen’ ‘Revenu Fort’
Table : Valeur Attribut Segment

Table ‘Salaires Client’ ‘Salaires Client’
Attribut ‘Salaire’ ‘Salaire’
Valeur Min. Attribut 30 001 50 001
Valeur Max. Attribut 50 000 75 000
Table : Segment Client

ID Client 12LJ49 12LJ49
124
Date Début 21/01/2005 01/03/2005

Date Fin 28/02/2005 Null
Vous remarquez dans l’exemple que le client ‘12LJ49’ a passé d’un segment de marché
(Revenu Moyen) à un autre segment (Revenu Fort). Un segment de marché est composé d’un
certain nombre de valeurs d’attribut de segment.
4.5.5. Les applications CRM

Les applications décisionnelles CRM développées auront comme principale source de
données la base de données du datawarehouse. Les applications puiseront les données de cette
base pour répondre directement aux requêtes ou pour faire des sauvegardes dans leurs propres
bases de données, peut être sous forme d’agrégats. En plus, les applications pourraient aussi
utiliser leurs propres données. Ces données peuvent être internes ou externes fournies par une
agence de données (Ex. : Un institut de statistiques).
Les applications auront leur propres cycles de traitement, totalement indépendants de celui du
datawarehouse. Ces cycles incluent :
1. La capture des données,
2. Les transformations spécifiques aux applications,
3. Le chargement des données,
4. Les accès utilisateurs finaux,
5. La sauvegarde.
Cette séparation entre le datawarehouse et les applications signifie que nous pouvons
développer et ajouter des applications après la mise en exploitation du datawarehouse. Notre
architecture est ainsi complètement évolutive. Les données historisées du datawarehouse
seront toujours disponibles pour les nouvelles applications.
En général, les applications CRM sont achetées sous forme de « packages ». Il existe sur le
marché une multitude d’offres d’applications CRM plus au moins riches en couverture
fonctionnelle : Gestion des compagnes, personnalisation des produits, Data Mining, Analyse
marché/produits… . Il est plus judicieux de ne pas réinventer ces applications même si elles
ne fournissent pas 100% des fonctionnalités dont nous avons exprimé le besoin. Ces
125
applications ont besoin de données pour fonctionner et notre architecture est capable de les
fournir rapidement.
4.5.6. Synthèse sur l’architecture du système

L’architecture des datawarehouses orientés CRM se caractérise par son respect des principes
d’évolutivité, de disponibilité, de partage et d’intégrité. L’objectif du datawarehouse est de
rendre les données disponibles pour toutes les applications CRM.
Les avantages de cette architecture sont :

• Elle permet à l’entreprise d’adopter une approche stratégique de construction des
systèmes d’information. Cette approche se repose sur l’idée que ces systèmes doivent
être construits autours d’impératives d’entreprise et non pas autour de besoins
tactiques ou départementaux.
• Elle supporte l’approche incrémentale de développement de systèmes d’information.
Le ROI (Retour Sur Investissement) est mesurable pour chaque incrément.
• L’ajout de nouvelles applications est relativement simplifié.
• En garantissant la séparation entre les données et les applications et à un niveau de
granularité bas, nous assurons à notre système un support total des changements
inévitables de stratégie d’entreprise.
• Les données historisées sont immédiatement disponibles aux nouvelles applications.
Le système d’information décisionnel est conçu pour aider l’entreprise à atteindre ses
objectifs. Ce système doit évoluer avec l’évolution de ces objectifs. Pour cela, il faut adopter
une démarche de construction incrémentale qui présente le moins de risques et qui minimise
les coûts afin d’aboutir toujours à un système complet et complètement intégré.
126
4.6. Les produits logiciels

Il existe actuellement sur le marché une multitude de produits logiciels orientés
Datawarehouse et/ou CRM. Certains éditeurs affirment que leurs produits sont capables
d’augmenter la productivité avec des délais d’implémentation très courts. Ces éditeurs
assurent aussi que leurs produits prennent en charge le « CRM ».
L’auteur P. Greenberg dans son livre intitulé “CRM at the speed of light, 3rd edition”
[Greenberg2004] a cité l’exemple d’un produit logiciel qui était à la base, un outil de
requêtage SQL. Depuis son lancement initial, ce produit n’a pas subit de grands changements.
Actuellement, le produit possède une version Web et une interface OLAP. Il s’agit, selon
l’auteur, d’un bon outil de requêtage. Cependant, les fournisseurs de ce produit logiciel
affirmaient qu’il est à la fois :
• Un produit de Datawarehousing,
• Un produit OLAP (Avant le développement de l’interface OLAP),
• Un outil de Datamining,
• Et un outil CRM.
Ces affirmations sont la source d’échec de plusieurs projets.
Certaines personnes pensent qu’on achetant les meilleurs outils sur le marché, ils auront la
garantie de réussir leurs projets. Les expériences passées ont prouvé que cette condition n’est
pas toujours suffisante.
Les produits CRM n’existent pas

Cette phrase révèle une vérité. Il existe certains produits qui aident l’entreprise à implémenter
une stratégie CRM mais il n’y a pas de produits CRM. Le CRM ne se résume pas à un ou
plusieurs produits logiciels (voir le chapitre 3 sur le CRM).
Dans cette section, nous allons présenter certains types de produits logiciels indispensables
pour implémenter une solution Datawarehouse. Nous n’allons pas évaluer ou traiter des
produits spécifiques mais nous allons décrire leurs caractéristiques et citer des exemples de
produits présents sur le marché actuel.
127
4.6.1. Les produits ETL (Extraction, Transformation and Loading)

Le terme ETL est utilisé pour décrire le processus qui commence par l’extraction des données
à partir des systèmes sources pour ensuite les modifier et les transformer en une forme
acceptée par le datawarehouse pour enfin les charger dans la base de données. Ces outils sont
nécessaires pour l’implémentation de la couche VIM présentée dans la section précédente.
Il existe actuellement sur le marché plusieurs outils ETL qui fournissent des mécanismes
d’extraction, de transformation et de chargement des données vers les datawarehouses.
La figure suivante illustre les composants majeurs de la plupart des produits ETL :
Extraire Transformer Charger

Fichiers Cible
sources
Figure 4.6.1 : Le processus ETL
Cette figure montre que le processus ETL peut être considéré comme étant composé de
plusieurs processus distincts.
a. L’extraction
Ce processus accède aux sources et pompe les données nécessaires pour le datawarehouse.
Les routines d’extraction peuvent être simples dans le cas où le fichier est délivré par le
système source ou complexes lorsqu’il s’agit d’essayer d’identifier les changements de
circonstances clients. Le processus d’extraction doit comprendre la signification des données
sources afin de n’extraire que les données utiles. Les études montrent qu’à chaque cycle
d’extraction, moins de 2% des données sources sont intégrées au datawarehouse. Il est aussi
important que l’outil d’extraction nous permette de descendre au niveau enregistrement afin
de définir ce qu’on veut extraire. Les données extraites sont enregistrées dans une zone de
traitement avant de passer aux autres processus. L’outil doit, de ce fait, nous permettre de
générer des fichiers intermédiaires de données.
b. La transformation
128
Dans un produit ETL, la partie liée à la transformation est la plus distinctive et la plus
importante. Le traitement VIM que nous avons décris dans la section 4.5 est pris en charge par
le processus de transformation. Rappelons que VIM signifie : Validation, Intégration et
Mappage des données. L’outil ETL doit couvrir toutes les opérations à effectuer durant le
processus VIM (voir la section 4.5.2).
c. Le chargement
Le chargement des données dans le datawarehouse est une source de problèmes. Certains
outils opèrent des insertions physiques des enregistrements dans les tables cibles du
datawarehouse en utilisant les clauses SQL « Insert ». D’autres outils exécutent le processus
ETL enregistrement par enregistrement. Ce qui signifie que chaque enregistrement est lu à
partir du système source, transformé puis chargé dans le datawarehouse, et ainsi de suite.
Cette approche est envisageable dans le cas où nous n’avons pas de grands volumes de
données à transférer. Sinon, cette approche sera la source de goulots d’étranglement.
Pour traiter de grands volumes de données, il faut utiliser les outils proposés par l’éditeur du
SGBD du datawarehouse qui sont en général bien adaptés pour ces situations.
Il existe deux familles d'ETL :

• Les générateurs : la description des processus d'alimentation aboutit à la génération
automatique de code qui sera en suite intégré dans les chaînes d'exploitation.
• Les moteurs : ils offrent des fonctions d'administration des processus d'alimentation
(lancement, répartition des tâches entre sources et cibles, …).
Voici un exemple des produits ETL existants sur le marché :

• ‘Data Stage’ (Ardent Software) : Moteur/Générateur,
• ‘Genio’ (Hummingbird) : Moteur,
• ‘Informatica’ : Moteur,
• ‘ETI Extract’ : Générateur,
• ‘WareHouse Administrator’ (SAS) : Moteur.
129
4.6.2. Les produits OLAP

OLAP est un concept qui est apparu avec la naissance des datawarehouses. OLAP fait
référence à la fois à une méthodologie de structuration dimensionnelle des données dans un
contexte décisionnel, et à des techniques utilisées par les systèmes de gestion de bases de
données (SGBD) et par les outils de restitution pour faciliter l’exploitation de ses structures.
Une structure OLAP se définit par rapport à un problème décisionnel. Dans un contexte
décisionnel, l’utilisateur se posera un certain nombre de questions sur des indicateurs clés
accompagnés éventuellement d’informations complémentaires telles que :
• Quoi, quel produit ou quel service,
• Quand : la date ou la période,
• A qui : à quel client,
• Qui : quelles entités dans l’entreprise,
• Où, la localisation de la vente ou du marché
Chacun de ces éléments constituera une dimension d’analyse pour les indicateurs de ventes.
La structure ainsi conçue est communément nommé « Cube OLAP ».
Les SGBD actuels proposent des modèles de stockage et/ou d’accès aux données basé sur
cette structure. On parle alors de base de données OLAP. Les techniques d’accès aux données
OLAP, telle que OLE-DB for OLAP de Microsoft, permettent la navigation dans le cube :
l’utilisateur peut ainsi zoomer (notion de drill-down), ou changer d’axe d’analyse (on parle
alors de slice & dice). La navigation dans les données OLAP est particulièrement intuitive.
Les caractéristiques définis par ‘E. Codd’ pour les bases OLAP sont [Source : Kimball1999] :
• Rapide : les temps de réponse doivent être prévisibles et constants. Une réponse en
moins de cinq secondes doit être donnée à la plupart des requêtes ad hoc lancées par
l’utilisateur.
• Analyse : les outils d’accès à la base de données doivent permettre l’exécution
d’analyse sur les données, en y associant des règles de calcul (statistiques, financières,
séries temporelles, etc.). Ces analyses peuvent être prédéfinies ou spécifiées de façon
appropriée par l’utilisateur final.
• Partage : les données et la structure multidimensionnelle sont potentiellement
accessibles par un ensemble d’utilisateurs ; les mécanismes de gestion de la sécurité et
de la confidentialité des données doivent être proposés.
• Multidimensionnel : c’est la caractéristique de base d’OLAP.
130
• Information : toutes les données doivent être accessibles en mode multidimensionnel,

quelle que soit leur localisation. Les contraintes de volumétrie doivent être quasi
inexistantes.
Les remarquables possibilités d’analyse des Bases de données OLAP impliquent toutefois une
certaine rigidité du modèle. En effet, tous les besoins utilisateurs doivent être modélisés au
préalable. L’utilisateur a une latitude extrêmement faible pour faire évoluer le modèle.
Un des facteurs différenciateur de la multitude d’outils OLAP est le mode de stockage des
données, qui permet de diviser cette gamme d’outils en plusieurs familles :
• Les outils MOLAP, les données étant stockées sous une forme multidimensionnelle ;
• Les outils ROLAP, les données étant stockées sous une forme relationnelle ;
• Les outils HOLAP, les données étant stockées sous une forme hybride dans des
environnements multidimensionnels et relationnels.
4.6.3. Les outils de restitution

Le concept de datawarehouse n’intègre l’aspect « outils d’aide à la décision » qu’en bout de la
chaîne. C’est une composante nécessaire et importante car c’est l’unique point d’entrée visible
pour le consommateur de l’information.
Dans le domaine de la restitution des données, trois grands types de besoins apparaissent :
• La diffusion d’information en masse. L’objectif principal en est le partage
d’information pour une très large population d’utilisateurs. Ceux-ci sont relativement
passifs par rapport à l’information qui leur est accessible : il s’agit alors d’informations
pré-structurées sous la forme de tableaux de bord ou d’états prédéfinis. On parle à ce
propos de Reporting.
• L’analyse. L’utilisateur travaille dans ce cas sur un périmètre fonctionnel précis dont les
enjeux ont été préalablement formalisés. Ceux-ci se présentent sous la forme
d’indicateurs clés de performance. L’utilisateur peut alors se servir du système pour
découvrir l’ensemble des facteurs susceptibles d’améliorer cette performance, puis
mesurer l’impact des décisions que cette analyse a contribué à prendre. Pour notre
système, cette analyse touchera le domaine du CRM.
• L’accès aux données en libre-service. L’utilisateur est libre de sélectionner les données
adéquates en fonction de ses objectifs du moment. [Source : Franco/Lignerolles2000]
131
Pour chaque type de besoin, il existe sur le marché des produits qui y sont adaptés, nous
pouvons citer quelques exemples :
• Le domaine du Reporting d’entreprise était à l’origine dominé par trois spécialistes :
‘Actuate’, ‘Seagate Software’, avec ‘Seagate Info’, et ‘Sqribe’, dont la société a été
depuis rachetée par ‘Brio’. Puis il s’est élargi, notamment en raison de l’adaptation à ce
marché des offres de type requêteur, comme celles de ‘Business Objects’ ou de
‘Cognos’ ou des éditeurs d’état, comme ‘Oracle Reports’.
• Le marché des outils d’analyse OLAP était d’abord dominé par les offres MOLAP
comme celles de ’Applix’ (TM/1), ‘Hyperion’ (Essbase), ‘Oracle’ (Express) et ‘Seagate’
(Holos) ; celles-ci ont depuis évolué vers le modèle HOLAP. Des offres plus légères,
orientées micro, comme ‘Powerplay’ de ‘Cognos’ où ‘BI/analyze’ de ‘Hummingbird’
les ont rejointes sur ce marché. Puis les requêteurs comme ‘Business Object’ ou ‘Brio’
ont également intégré le multidimensionnel. Ensuite sont arrivés les outils ROLAP,
comme ‘Metacube’ de ‘Informix’, ‘Information advantage DSS’ de ‘Microstrategy’, ou
‘BW’ de ‘SAP’. Enfin, certains acteurs comme ‘Microsoft’ (OLAP services) ou ‘SAS’
ont proposé une offre de type HOLAP, intégrant leur propre serveur multidimensionnel,
ou un outil susceptible de s’appuyer sur une couche de stockage relationnelle.
• Le marché des requêteurs est de son côté dominé par ‘Brio’, ‘Business Object’,
‘Cognos’ et ‘Hummingbird’. D’autres acteurs non positionnés initialement sur ce
marché ont élargi leurs offres : on peut citer ‘Seagate’ (Info), ‘Oracle’ (Discoverer) et
‘SAS’ (SER).
4.6.4. Le Datamining
Le « Datamining » est un procédé permettant de découvrir des nouvelles corrélations, de
nouveaux schémas et de nouvelles relations dans de grandes quantités de données stockées
dans des bases, en utilisant aussi bien les techniques de « Pattern recognition » que des
techniques statistiques et mathématiques. [Source : Rud2001]
Le problème actuel des entreprises n'est plus de récupérer de la donnée, au contraire elles en
récupèrent même « trop » dans le sens ou elles n'arrivent pas forcément à la traiter dans le
temps voulu.
Le but du Datamining est de permettre à la machine d'interpréter les données présentent dans
ces bases de données. Ainsi la tâche de compréhension normalement dévolue aux humains est
132
affectée sur la machine, qui en échange produit un compte rendu clair et simple de ce qu'elle a
trouvée.
Le Datamining permet aux entreprises de se focaliser sur les informations les plus importantes
de leurs bases de données.
Les objectifs du Datamining peuvent être classés en deux grandes catégories :
• La prédiction automatique des marchés et comportements,
• La découverte automatique de schémas encore inconnus.
La prédiction automatique est simplement une mise en corrélation de données obtenues par la
découverte des schémas. En clair la prédiction est une ré-applications des schémas sur les
données arrivantes.
Parmi les formes de représentation de la connaissance générée par les algorithmes de

Datamining, les plus courantes sont : [Source : Rud2001]
• Les classes qui sont des groupes d'individus ayant des propriétés communes. Le but
des classes est de trouver des dénominateurs communs des individus pour permettre,
par exemple, de trouver à quelle classe appartient un nouvel individu arrivant.
• Des associations, c'est-a-dire des règles permettant de savoir quelle condition
déclenche quelle conséquence. En utilisant des tickets de caisse, on peut par exemple
déduire que les individus achetant un produit ‘x’ vont certainement acheter
le produit ‘y’.
• Des arbres de décision, ce sont des arbres permettant de répondre à des questions
ayant un nombre de réponse connu et fini. De tels arbres sont obtenus d'après les
valeurs des attributs d'une base d'exemple.
Dans le domaine du CRM, les algorithmes de « Datamining » présente une très grande
importance dans le processus de la reconnaissance client CKM (Customer Knowledge
Management).
L’Enjeu de la connaissance fine et détaillée des clients est de créer, développer et maintenir
des relations profitables pour l’entreprise en utilisant les techniques de management de
l’information « Client ». Ces techniques permettent de :
• détecter les niches marketing,
• déterminer les profils des clients,
• modéliser le comportement des clients,
133
• détecter les besoins en services nouveaux,

• détecter les potentiels économiques des clients,
• détecter et expliquer les risques d’infidélité,
• détecter et expliquer les risques d’impayés,
• détecter les tendances des concurrents et des marchés,
• d’améliorer la QoS fournie aux clients,
• d’améliorer la satisfaction des clients,
En des termes clairs, Le datamining CRM est un processus de management des données
« Client » qui opère à partir sur les données élémentaires pour produire de l’information et de
la connaissance.
Il existe sur le marché tout une gamme d'outils allant de ceux supportant une unique méthode
statistique fonctionnant en monoposte sur des volumes de données limités (exemple : ‘Alice’),
jusqu'aux outils offrant une palette complète de méthodes statistiques fonctionnant en
client/serveur sans limitation de volume (exemple : ‘Les outils SAS’).
134
Chapitre 5
Conclusion et perspectives
n Les bases de données temporelles ;

n Les extensions « SQL OLAP » ;
n Les systèmes décisionnels actifs ;
n L’exploitation des données externes ;
n Les données non-structurées.
5. Conclusion et perspectives
Développer une stratégie CRM est devenu un objectif majeur des entreprises actuelles. Or, la
réalité nous a montré que les projets CRM sont des projets risqués et très couteux à mettre en
œuvre. Une des conditions nécessaires pour réussir l’implémentation d’une stratégie CRM est
la disponibilité de données « Clients » fiables, pérennes, précises et répondant aux besoins des
décideurs permettant ainsi une gestion efficace de la relation clients.
Pour satisfaire cette condition, les applications CRM doivent être supportées par des
datawarehouses conçus autour d’objectifs CRM qui ne se limitent pas à recueillir que les
données comportementales. Ce sont les datawarehouses de « deuxième génération » qui
intègrent un nouvel objectif clair : maximiser l’efficacité de la gestion de la relation client.
Alors que les projets de datawarehouses classiques se concentrent sur les faits et les
dimensions, les projets de datawarehouses orientés CRM se focalisent sur la dimension
« Client » en la structurant de manière à répondre aux objectifs CRM des entreprises.
Dans ce mémoire, nous avons traités les éléments nécessaires à la conception et

l’implémentation d’un datawarehouse orienté CRM. Nous avons focalisé notre travail sur la
dimension « Clients » ; car pour le reste, le projet diffèrera peu des datawarehouses
classiques. La différence entre les datawarehouses de première génération et ceux de la
deuxième génération est la manière d’aborder la conception de la dimension « Clients ».
Dans les datawarehouses orientés CRM, les données « Clients » ne se limitent pas à une
unique table dimension. La dimension « Client » devient un modèle complet de données qui
est le centre du modèle global du datawarehouse. Ce modèle intègre les données sur le
comportement, les circonstances et la segmentation des clients.
Dans ce mémoire, nous avons principalement traité la modélisation conceptuelle et logique

des données « Clients » et proposé une architecture d’implémentation physique du
datawarehouse.
A ce stade, le travail n’est certainement pas complet puisque nous n’avons pas traité tous les
détails de ce projet mais nous espérons pouvoir le faire ultérieurement.
Il n’existe pas actuellement de standards dans le domaine et beaucoup de travaux de recherche

sont menés actuellement sur le concept du datawarehouse du futur.
Le CRM est un des services à valeur ajoutée que les consommateurs d’aujourd’hui exigent.
La question est : que-est ce que le futur amène dans ce domaine ?
Nous pouvons penser qu’il est impossible de prédire cet avenir. Cependant, si nous restons
focaliser sur les datawarehouses, il est quasi certain que l’architecture de base présentée dans
ce mémoire ne va pas changer. Par contre, l’implémentation physique va certainement
évoluer. Internet, par exemple, va faciliter l’émergence de centre de données très larges qui
contiennent des centaines, voir des milliers ou même des millions de serveurs interconnectés,
gérés par des fournisseurs de service qui vont permettre l’externalisation à de larges
proportions. Mais les données ne vont pas changer, et notre MCG fournira toujours les
données nécessaires pour pouvoir comprendre les clients.
Nous présentons dans ce qui suit les axes de recherches actuels dans le domaine des
datawarehouses orienté CRM :
a. Les bases de données temporelles (les extensions temporelles)

Depuis les années 90, plusieurs travaux de recherches ont été menés sur les bases de données
temporelles. Une base de données temporelle supporterait nativement certains aspects du
« Temps ». Nous pouvons penser que tous les SGBD actuels supportent le « Temps » avec
l’inclusion et l’utilisation du type de données « Date/Time ». Or, l’objectif des bases de
données temporelles est tout autre.
Une base de données temporelle supporterait les données temporelles nativement par le biais
de la structure du SGBD. Le schéma des tables, le processeur de requêtage, etc. doivent avoir
une compréhension native du « Temps ».
Nous avons déjà traité dans ce mémoire certains aspects liés au temps. Les datawarehouses
sont des bases de données temporelles sans qu’ils soient implémentés sur des SGBD
temporels. La communauté des chercheurs a échoué, jusqu’à présent, à développer un SGBD
temporel. La gestion du « Temps » se fait actuellement en utilisant les attributs de type
« Date/Heure ». Les recherches dans ce domaine se concentrent sur la manière de modifier le
modèle relationnel pour répondre aux besoins « Temporels » sans violer les principes
théoriques de la modélisation relationnelle.
Des propositions ont été faites concernant les extensions possibles au langage SQL. Ces
propositions concernent généralement l’ajout d’une clause « WHEN » au langage. Jusqu’à
présent, aucun éditeur de SGBD n’a voulu implémenter cette proposition.
137
Peut-être que le problème vient du faite que les tables relationnelles sont à deux dimensions.
Le « Temps » ajoute une autre dimension et toutes les tentatives pour trouver une solution se
terminent par un échec. La vraie solution n’est pas de modifier les SGBD actuels mais de
créer un nouveau modèle de bases de données différent du modèle relationnel.
b. Les extensions « SQL OLAP »

Il existe actuellement plusieurs propositions d’extension du langage SQL afin de permettre la
prise en charge et l’exécution de certaines fonctions OLAP. Voici les principales
propositions :
Les moyennes mobiles :
Il sera possible de spécifier un nombre d’enregistrement à inclure dans la moyenne mobile.
Par exemple, dans un tableau résultat contenant les ventes mensuelles, nous pouvons calculer
des moyennes mobiles pour un nombre de mois spécifié. Nous pouvons, par exemple, créer
une moyenne mobile de trois mois qui contient le mois actuel (pointé avec la souris), le mois
précédent et le prochain mois.
Les groupes d’agrégation :
Alors que la moyenne mobile est une fonction « d’agrégation limitée », il serait possible de
définir des agrégations non-limitées afin de permettre la définition de colonnes cumulatives.
Un autre développement de cette idée pourrait nous permettre de définir des colonnes
d’agrégation qui n’incluent pas l’enregistrement actuel. Par exemple, nous pouvons comparer
les ventes de ce mois avec la moyenne des trois mois précédents.
Les fonctions de classement :
Les utilisateurs d’un datawarehouse ont souvent besoin de connaître la liste des TOP « n » des
clients, produits ou régions. Cette fonction proposée nous permettra de formuler de telles
requêtes.
c. Les systèmes décisionnels actifs

Les systèmes d’aide à la décision actuels sont des systèmes passifs et les datawarehouses
n’échappent pas à cette règle. Les systèmes décisionnels attendent que d’autres applications
leur soumettent des requêtes avant de réagir et fournir les réponses. L’idée est de construire
des systèmes d’aide à la décision actifs (semblables aux systèmes experts) qui sauraient
reconnaître les informations intéressantes et les fournir sans interventions ou sollicitations
138
externes. Ces systèmes chercheraient en permanence les nouvelles données et réagiraient

lorsque des changements importants seraient détectés. Ces systèmes seraient totalement
différents des systèmes d’alerte traditionnels.
d. L’exploitation des données externes

Certains datawarehouses doivent avoir un accès aux données externes. Les données externes
ne sont pas celles importées dans le datawarehouse en utilisant les outils ETL.
L’intégration des données externes signifie qu’en cas de besoin les utilisateurs peuvent
accéder à ces données via le système du datawarehouse.
Dans l’industrie pharmaceutique, par exemple, il existe des centaines de bases de données
épidémiologiques tierces à qui les entreprises du secteur peuvent souscrire à un accès. Le
datawarehouse doit être en mesure d’exploiter ces données. Or, ces bases de données sont très
grandes et il est inapproprié d’envisager de les copier dans le datawarehouse. Nous pouvons
simplement créer des liens vers ces données sans compromettre la sécurité et l’intégrité des
données internes du datawarehouses.
e. Les données non-structurées

Les données du datawarehouse sont des données structurées : ces données sont organisées
sous forme de lignes et de colonnes, avec des types de données précis.
Les données non-structurées sont celles qu’on trouve dans les documents, les pages Web, les
journaux, etc. Ces données sont aussi importantes que les données structurées.
Ces données non-structurées sont très intéressantes puisqu’elles sont disponibles plus vite que
leur version structurée. L’objectif est de pouvoir obtenir, interpréter et présenter les
informations issues de ces données aux utilisateurs et d’écrire éventuellement des algorithmes
de datamining pouvant analyser ces données.
Parmi toutes les technologies disponibles aujourd’hui, XML (eXtensible Markup Language)
est la plus prometteuse pour fournir une solution d’interprétation des données non-structurées.
139
Bibliographie
Références Bibliographiques
6. Références Bibliographiques
• Les livres :
[Adamson/Venerable1998]
“Datawarehouse Design Solutions”;
C. Adamson, M. Venerable; John Wiley and Sons; 1998.
[Anderson/Kerr2002]
“Customer relationship management”;
K. Anderson, C. Kerr; McGraw-Hill; 2002.
[Anton/Vilsoet2002]
“Customer Relationship Management Technology”;
J. Anton, B. Vilsoet; John Wiley and Sons; 2002.
[Dyche2002]
“The CRM Handbook: A Business Guide to Customer Relationship Management”;
J. Dyche; Addition Wesley; 2001.
[English2004]
“Improving Datawarehouse and Business Information Quality: Methods for Reducing Costs
and Increasing Profits”;
L.P. English; John Wiley and Sons; 2004.
[Franco/Lignerolles2000]
“Piloter l’entreprise grâce au datawarehouse”;
J.M. Franco, S. De Lignerolles; Eyrolles; 2000.
[Freeland2002]
“The Ultimate CRM Handbook: Strategies and Concepts for Building Enduring Customer
Loyalty and Profitability”;
J. Freeland; John Wiley and Sons; 2002.
141
[Goglin1998]
“La construction du datawarehouse : du datamart au dataweb”;
J.F. Goglin; Hermes; 1998.
[Greenberg2004]
“CRM at the speed of light, 3rd edition”;
P. Greenberg; McGraw-Hill Osborne Media; 2004.
[IBM1998]
“Data Modelling Techniques for Data Warehousing”;
C. Ballard, D. Herreman, D. Schau, R. Bell, E. Kim, A. Valencic; IBM Redbooks; 1998.
[Johnson/Gustafsson2000]
“Improving Customer Satisfaction, loyalty and Profit”;
M.D. Johnson, A. Gustafsson; Jossey-Bass (A Wiley Company); 2000.
[Kimball/Ross2002]
“The Datawarehouse Toolkit: The Complete Guide to Dimensional Modelling, 2nd Edition”;
R. Kimball, M. Ross; John Wiley and Sons; 2002.
[Kimball1999]
“Concevoir et déployer un datawarehouse : guide de conduite de projet”;
R. Kimball, L. Reeves, M. Ross, W. Thornwaite; Eyrolles; 2000.
[Kimball/Merz2000]
“Le datawebhouse : Analyser le comportement client sur le Web”;
R. Kimball, R. Merz; Eyrolles; 2000.
[Lowenstein2004]
“One Customer, Divisible: Target, Analyze and Prosper”;
M. Lowenstein; John Wiley and Sons; 2004.
142
[Reynolds2002]
“A practical Guide to CRM”;
J. Reynolds; CMP Books; 2002.
[Rud2001]
“The Datamining Cookbook”;
O. Parr Rud; John Wiley and Sons, 2001.
[Swift2003]
“Accelerating Customer Relationships: Using CRM and Relationship Technologies”;
Ronald S. SWIFT; Prentice Hall; 2003.
[Todman2001]
“Designing a Datawarehouse Supporting CRM”;
C. Todman; Prentice Hall; 2001.
[Turk/Bligh2004]
“CRM Unplugged: Releasing CRM’s Strategic Value”;
D. Tulk, P. Bligh; John Wiley and Sons; 2004.
143
• Articles et thèses :
[Bauer/Grether/Leach2002]
“Building Customer Relations over the Internet”;
H. H. Bauer, M. Grether, M. Leach; Mannheim University (Germany); 2002.
[Bret/Soule/Zurfluh2000]
“Outils méthodologiques pour la conception de bases de données décisionnelles orientées
objet”;
F. Bret, C. Soule-Dupuy, G. Zurfluh;Université St Hilaire, Canada; 2000.
[Chaudhuri/Dayal1997]
“An Overview of Datawarehousing and OLAP Technology”;
S. Chaudhuri, U. Dayal; ACM SIGMOD Record; 1997.
[Codd1993]
“Providing OLAP to user-analysts: an IT mandate”;
E.F. Codd; Technical Report, E.F. Codd and associates; 1993.
[Dayal/Wuu1992]
“A uniform approach to processing temporal queries”;
Y. Dayal, G.T.J. Wuu; International conference on very large databases, Canada, 1992.
[Flueckiger2000]
“Les systèmes TES, Customer Relationship Management”;
A. Flueckiger; Gartner Group; 2000.
[Teste2000]
“Modélisation et manipulation d’entrepôts de données complexes et historisées” ;
O. TESTE ; Thèse de doctorat, Université P. Sabatier, Toulouse (France) ; 2000.
144

Memoire de Magister Haciane

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Memoire de Magister Haciane

Hochgeladen von

Copyright:

Verfügbare Formate

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Conception d’un datawarehouse Orienté

Soutenu le 09/01/2007 devant le jury composé de :

Je tiens à exprimer mes sincères remerciements à

Je tiens aussi à exprimer toute ma reconnaissance aux membres de l’équipe

Je tiens aussi à remercie M. SELMOUNE de l’équipe LSI pour ses

Je tiens à remercier très sincèrement l’ensemble des membres du jury qui me

Je remercie particulièrement les enseignants et le personnel de la DPGR de

Enfin, je remercie tout particulièrement mes parents qui m’ont toujours

2. Les systèmes décisionnels « datawarehouses »...........................................................4

3. CRM : Customer Relationship Management ............................................................31

4. Conception d’un datawarehouse orienté CRM..........................................................52

4.5. L’implémentation physique du système.............................................................95

5. Conclusion et perspectives ......................................................................................119

Chapitre 2 : Les systèmes décisionnels « Datawarehouses »

Chapitre 3 : CRM : Customer Relationship Management

Chapitre 4 : Conception d’un datawarehouse orienté CRM

Figure 4.2.1 : Rappel : le modèle conceptuel général « ETS Boissons » ........................54

Figure 4.3.1 : Le modèle du point ...................................................................................71

Figure 4.4.1 : L’implémentation de la rétrospection en utilisant… ................................88

Figure 4.5.1 : L’architecture EASI du système ...............................................................96

Figure 4.6.1 : Le processus ETL....................................................................................112

Le premier chapitre de ce mémoire donne une introduction sur les datawarehouses de

Un deuxième chapitre état de l’art sur La gestion de la relation client :

Un troisième chapitre sur La conception d’un datawarehouse de deuxième génération

Les systèmes décisionnels

n Les systèmes d’informations décisionnels ;

2. Les systèmes décisionnels « datawarehouses »

2.1. Les systèmes d’information décisionnels

2.1.1. Qu’est-ce que le décisionnel ?

Figure 2.1.1 : Une vision transversale de l’entreprise [source : Goglin1998]

2.1.2. Positionnement du décisionnel au sein du système d’information

Figure 2.1.2 : Le décisionnel au sein du système d’information [source : Goglin1998]

2.1.3. Les différentes composantes du décisionnel

Figure 2.1.3 : Les différents composants du décisionnel [source : Goglin1998]

2.2. Le système datawarehouse

2.2.1. Définition du datawarehouse

Un datawarehouse est une collection de données :

2.2.2. L’architecture globale du datawarehouse

Figure 2.2.1 : L’architecture du datawarehouse [source : Goglin1998]

Figure 2.2.2 : L’architecture des systèmes décisionnels [source : Teste2000]

L'entrepôt de données (datawarehouse) est le lieu de stockage centralisé des informations

2.2.3. Définitions des concepts [Source : Goglin1998]

La base de données du datawarehouse

Le datawarehouse est supporté par une base de données relationnelle, multidimensionnelle ou

OLAP (On Line Analytical Processing)

Moteur de règles de gestion

2.2.4. Le fonctionnement du système datawarehouse

Figure 2.2.3 : L’acquisition des données

Administrer * Planifier * Surveiller

Figure 2.2.4 : Le processus d’acquisition de données

b. Le stockage des données dans le datawarehouse (l’entrepôt de données)

c. L’alimentation des datamarts (les magasins de données)

Figure 2.2.5 : L’alimentation des datamarts …….

• Le datawarehouse est le sas central de contrôle, garant de la qualité et de l’intégrité de

d. L’exploitation de l’information : la restitution des données

Figure 2.2.6 : La restitution des données

2.3. Les modèles de données du datawarehouse

Un datawarehouse est une base de données. Ainsi, le modèle de données du datawarehouse

2.3.1. Caractéristiques d’utilisation : OLTP vs OLAP [Source : Kimball1999]

Caractéristiques d’un contexte OLTP

Dans un monde décisionnel (OLAP)

chargement (processus d’acquisition de données). Il devient donc envisageable d’introduire