Memoire_Julien_Diennet_20140905

- Mémoire de fin d’études (M2) -
Développer, Automatiser et Optimiser un
Data Mart
sans l’aide de logiciels spécialisés, dans le but de fournir
des indicateurs de performance
Julien DIENNET
Master 2 ID Apprentissage
5 septembre 2014
Responsable Master : Mr M. Ali Aloulou
Maître d’apprentissage : Mr G. Bretnacher
Tuteur enseignant : Mme M. J. Bellosta

Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
3
TABLE DES MATIERES
TABLE DES MATIERES .......................................................................................................................................3
REMERCIEMENTS .............................................................................................................................................6
GLOSSAIRE .......................................................................................................................................................7
INTRODUCTION ET PROBLEMATIQUE...............................................................................................................9
NOTIONS DE BASE.......................................................................................................................................... 11
PREAMBULE : INFORMATION ET DONNEES................................................................................................................... 11
L’information................................................................................................................................................ 11
Définition ................................................................................................................................................................... 11
But et bonne pratique................................................................................................................................................ 11
La donnée ..................................................................................................................................................... 12
Définition et valeur.................................................................................................................................................... 12
Qualité de données.................................................................................................................................................... 13
Les métadonnées....................................................................................................................................................... 15
LES INDICATEURS : UNE VISION TRAITEE ET CONCISE DE L’INFORMATION............................................................................ 15
Définition...................................................................................................................................................... 15
Avantages .................................................................................................................................................................. 16
Inconvénients ............................................................................................................................................................ 16
Caractéristiques recherchées........................................................................................................................ 16
Axes d’analyse .............................................................................................................................................. 17
Les « KPI » : notion ....................................................................................................................................... 18
L’AUTOMATISATION DU TRAITEMENT DE DONNEES ....................................................................................................... 19
Définition...................................................................................................................................................... 19
Méthodologie possible ................................................................................................................................. 19
Les différents niveaux d’automatisation ...................................................................................................... 20
Inconvénients................................................................................................................................................ 20
Lois et règles en vigueur sur les traitements automatisés............................................................................ 21
ETAT DE L’ART ET ANALYSE ............................................................................................................................ 22
DATA MART ......................................................................................................................................................... 22
Définitions et principes................................................................................................................................. 22
Définition ................................................................................................................................................................... 22
Structure physique et théorique................................................................................................................................ 22
En quoi un Data Mart est-t-il différent d’un Data Warehouse ?................................................................................ 23
Pourquoi développer un Data Mart ? Quelle en est la limite ?.................................................................................. 23
DataMarts dépendants et indépendants................................................................................................................... 24
Implémentation : les étapes......................................................................................................................... 26
Design ........................................................................................................................................................................ 26
Construction .............................................................................................................................................................. 27
Extractions et transformations .................................................................................................................................. 27
Calcul des indicateurs (optionnel).............................................................................................................................. 27
Recette....................................................................................................................................................................... 28
Accès et diffusion....................................................................................................................................................... 28
Automatisation .......................................................................................................................................................... 29
Maintenance.............................................................................................................................................................. 29
Optimisation................................................................................................................................................. 29
HYPOTHESES ET CADRE DE L’ETUDE ............................................................................................................... 31
L’ENTREPRISE........................................................................................................................................................ 31
TYPE DE DATA MART.............................................................................................................................................. 31

4
TAILLE ET COMPLEXITE DES DONNEES ......................................................................................................................... 31
ENVIRONNEMENT DE DEVELOPPEMENT ...................................................................................................................... 32
OUTILS UTILISES..................................................................................................................................................... 32
RESULTATS SOUHAITES ET ACCES AUX DONNEES ........................................................................................................... 33
RESUME............................................................................................................................................................... 33
METHODE ...................................................................................................................................................... 34
PREMIERE PHASE : PLAN D’ACTION ET RECUEIL DES BESOINS ........................................................................................... 34
Mise en place du plan d’action..................................................................................................................... 34
Définition du périmètre ............................................................................................................................................. 34
Définition des acteurs................................................................................................................................................ 34
Planning projet........................................................................................................................................................... 34
Recueil des besoins fonctionnels et techniques............................................................................................ 35
Recueil des besoins fonctionnels............................................................................................................................... 35
Définition des outils techniques ................................................................................................................................ 35
Obtention des accès aux environnements................................................................................................................. 36
DEUXIEME PHASE : DESIGN...................................................................................................................................... 36
Processus logique ......................................................................................................................................... 37
Identifier les sources et modéliser les extractions ........................................................................................ 37
Modéliser les transformations...................................................................................................................... 38
Modéliser les liaisons et le chargement ....................................................................................................... 40
Méthodes de calculs des indicateurs............................................................................................................ 40
Créer les axes d’analyse................................................................................................................................ 41
Préparer les reportings................................................................................................................................. 42
Design physique............................................................................................................................................ 43
TROISIEME PHASE : CONSTRUCTION, SPECIFICATIONS DETAILLEES ET CAHIER DE RECETTE...................................................... 44
Construction de l’environnement ................................................................................................................. 44
Création des fichiers programmes et reportings .......................................................................................... 44
Programmes............................................................................................................................................................... 44
Reportings.................................................................................................................................................................. 45
Documentation détaillée des futurs programmes........................................................................................ 45
Cahier de recette .......................................................................................................................................... 45
QUATRIEME PHASE : DEVELOPPEMENT ...................................................................................................................... 46
Script............................................................................................................................................................. 46
SAS................................................................................................................................................................ 46
Inclusions de sous-programmes ................................................................................................................................ 46
Macros variables et macros fonctions ....................................................................................................................... 47
Etapes « DATA »......................................................................................................................................................... 48
Procédures................................................................................................................................................................. 48
Reportings.................................................................................................................................................................. 49
Automatisation............................................................................................................................................. 50
Optimisation................................................................................................................................................. 50
Optimisation pour la lecture et l’écriture .................................................................................................................. 50
Optimisation pour l’exécution ................................................................................................................................... 51
CINQUIEME PHASE : RECETTE................................................................................................................................... 52
Recette technique......................................................................................................................................... 52
Recette fonctionnelle.................................................................................................................................... 53
SIXIEME PHASE : MAINTENANCE ET EVOLUTIONS.......................................................................................................... 54
RESULTATS..................................................................................................................................................... 55
DISCUSSION ................................................................................................................................................... 56
CONCLUSION.................................................................................................................................................. 58
BIBLIOGRAPHIE .............................................................................................................................................. 59

5
Livres et documents...................................................................................................................................... 59
Sites web....................................................................................................................................................... 59
ANNEXES........................................................................................................................................................ 60

6
REMERCIEMENTS
Je tiens tout d’abord à remercier Cedric Sarinena pour m’avoir recruté au sein de BNP Paribas
Personal Finance.
Une grande pensée à toute l’équipe du Système d’Aide à la Décision dont une partie m’a aidé à
monter l’étude de ce mémoire.
Je tiens également à faire part de ma reconnaissance envers tout le corps enseignant du Master 2 ID
Apprentissage de Dauphine, notamment à Mohamed Ali Aloulou (responsable de master), Patricia
Lavagna (correspondante au CFA AFIA), et Marie-Jo Bellosta (tutrice enseignante) qui m’a
grandement aidé dans la réalisation de ce mémoire.
Finalement, mes remerciements les plus profonds iront à Gilles Bretnacher qui fut mon maître
d’apprentissage et mon responsable entreprise durant cette année. Il m’a épaulé durant mes
missions professionnelles et pendant la rédaction de ce mémoire.

7
GLOSSAIRE
Clé primaire : Terme utilisé dans les bases de données pour définir un ou plusieurs champs qui
servent d’identifiant unique de la table dans laquelle il se trouve. Par exemple, une clé primaire
possible d’une table contenant le référentiel des individus est : nom + prénom + date de naissance.
Data Warehouse : Entrepôt de données qui regroupe une partie ou l'ensemble des données
fonctionnelles en provenance des bases de données opérationnelles d'une entreprise. Son but est de
fournir un ensemble de données valides servant de référence unique. Elles sont utilisées, entre
autres, pour la prise de décisions lorsqu’il s’agit de créer des « Cubes OLAP » à l’aide de bases de faits
et de dimensions. D’un point de vue technique, il sert aussi à « délester » les bases de données
opérationnelles des requêtes pouvant nuire à leurs performances. Son périmètre d’action est large
car il couvre plusieurs domaines d’activités de l’entreprise.
ERP : Un « Enterprise Resource Planning » permet la planification des ressources de l’entreprise. Par
« ressources » est entendu tout actif de l’entreprise, par exemple : les ressources humaines (RH), les
ressources comptables (Comptabilité), l’information et les données (Informatique), etc. Un ERP est
ainsi un « progiciel de gestion intégré » qui permet la gestion d’un domaine d’activité de l’entreprise.
ETL : Acronyme de « Extract-Transform-Load ». Il sert à extraire les données de bases sources, les
transformer (appliquer des calculs, changer le format, etc.) et les charger dans des bases cibles. C’est
la première partie d’un Data Warehouse ou d’un Data Mart. Des logiciels comme « Talend » sont
spécialisés dans cette activité.
Fichiers plats : Un fichier plat est un fichier de données qui n’est pas dans un format complexe type
base de données. Par « format » est entendu l’extension du fichier et donc l’encodage de ce dernier.
Par exemple un fichier texte regroupant des données en lignes est un fichier plat. Les fichiers Excel
ou CSV (Comma Separated Value) sont aussi des fichiers plats. Les fichiers .bdd (base de données) et
.sas7bdat (base de données SAS) ne sont pas des fichiers plats.
Granularité de l’information : La granularité de l’information définit la taille du plus petit élément, le
niveau de détail le plus profond, qui sera utilisé.
Hardware : Mot anglais pour parler des composants physiques d’un ordinateur. Exemple : disque
dur, carte graphique, processeur, etc.
Indexage : Technique utilisée dans les bases de données pour accélérer les traitements (notamment
les requêtes). Des indexs sont créés sur les clés primaires pour pouvoir accélérer les jointures entre
plusieurs tables.
Log : Fichier généré pendant l’exécution d’un programme qui recense l’historique des évènements :
les résultats et les erreurs qui sont survenues. Il peut être sous la forme de texte (fichier plat) ou de
données sauvegardées dans une base.
Logiciels BI : Logiciels spécialisés dans le traitement de la « Business Intelligence » (informatique
décisionnelle), à savoir : la gestion de grand volumes de données (ETL, Data Warehouse, Data Mart),
la fouille de données, les analyses, les reportings. Exemples : Cognos, SAP BI Analytics, Talend, SAS
Enterprise Suite, Microsoft SQL Server, Oracle EPM et BI, Hadoop…
Reporting : Compte-rendu alimenté de données et d’analyses qui peut être présenté sous la forme
de fichiers (Excel, CSV, etc.), de page web (HTML), ou de pages intégrées dans un logiciel spécialisé

8
(Exemple : Tableau, Cognos, SAP…). Il sert à diffuser et mettre en forme l’information pour un
utilisateur, la rendre compréhensible et utilisable.
SAS : SAS est avant tout une entreprise. Elle a mis au point un langage de programmation ainsi que
plusieurs types de solutions spécialisées dans le management de données en général (exemple : SAS
Enterprise Guide, SAS Enterprise Miner…). Le langage de programmation permet de créer, modifier
et supprimer des bases de données SAS. Il permet aussi de coder tout un processus incluant des
fonctions, des variables dynamiques, etc. pour traiter les données.
Schéma en étoile : Les schémas en étoiles sont des types de représentations de plusieurs tables en
relation (une au centre reliée à toutes les autres, alors que ces dernières n’ont pas de liens entre
elles). Il est souvent utilisé dans les Data Warehouse et Data Mart. Le modèle en étoile permet une
économie de jointures à l'interrogation, ce qui le rend optimisé pour les requêtes d'analyse.
SGBD : Un « Système de Gestion de Bases de Données » est un logiciel système permettant de
stocker et gérer des bases de données. Il est composé de plusieurs bases de données, contenant
elles-mêmes plusieurs tables reliées entre elles par des relations. Deux SGBD connus sont « MySQL »
et « SQL Server ».
Software : Mot anglais pour parler des applications et logiciels. Ce sont donc les éléments
informatiques légers d’un ordinateur (à la différence des hardware).
SQL : « Structured Query Language » est un langage informatique destiné à créer, modifier,
supprimer et interroger les bases de données. C’est un langage dédié, spécialisé dans ce type de
fonctions. On parle souvent de « requêtes SQL ».

9
INTRODUCTION ET PROBLEMATIQUE
« Si l’on numérisait toutes les communications et les écrits depuis l’aube de l’humanité jusqu’en 2003,
il faudrait 5 milliards de gigabits pour les mettre en mémoire. Aujourd’hui ce volume d’informations
numériques est produit en deux jours. »1
Cette phrase, répétée par Eric Schmidt l’ex-PDG de Google, résume assez bien la problématique
générale que subit le monde informatique d’aujourd’hui : le nombre de données générées dans les
domaines publiques et privés devient vertigineux. Il s’agit de trouver comment stocker et analyser
ces données dans des temps raisonnables. Les termes Big Data, Smart Data, Business Intelligence (BI)
etc. font parler d’eux car ils tentent, à tort ou à raison, de répondre à ce problème qui ne cesse de
croître.
Pour comprendre ce domaine, il faut d’abord commencer par assimiler les notions d’information, de
données, de qualité de données, d’indicateurs et d’automatisation. L’expression « technologies de
l’information » n’est pas utilisée au hasard car le but premier de l’informatique est de récolter, traiter
et diffuser l’information. De là émane le terme « Informatique Décisonnelle » (traduction de Business
Intelligence) qui signifie « l’informatique au service des données, pour la prise de décisions ».
Cette spécialisation vient du fait que, de plus en plus, les dirigeants souhaitent connaître l’activité de
leur entreprise. L’accès à des résumés et analyses de l’activité devient essentiel pour piloter son
organisation. Un autre aspect de l’Informatique Décisionnelle est la gestion des sources de données
multiples au sein d’une entreprise : comment regrouper les informations éparpillées dans différentes
bases d’une entreprise ? Comment faire en sorte que ces données soient cohérentes et de
qualité (complètes, sans doublons, etc.) ?
Pour répondre à cette demande, les notions d’« Analytics » et de « Data Warehouse » sont apparues.
L’Analytics n’est autre que l’analyse de données qui comprend : les statistiques, les indicateurs et la
fouille de données (« Data Mining »). Tandis que le Data Warehouse est un entrepôt de données
central, chargé de regrouper et de formaliser toutes les données fonctionnelles de l’entreprise. Des
acteurs connus comme SAS, Oracle, IBM, SAP, Microsoft, Talend etc. ont développé des logiciels BI
qui offrent des suites intégrées pour implémenter ces solutions, qui sont en concurrence comme le
montre l’étude annuelle « Magic Quadrant » de Gartner.
Mais ces solutions sont souvent très coûteuses (de l’ordre de plusieurs milliers d’euros par
utilisateur, en comptant la somme des coûts de licence, d’implémentation et de maintenance). Qu’en
est-il alors de l’obtention d’une solution type « Data Warehouse » lorsque le budget à disposition est
limité ? De plus, le besoin d’avoir accès à un référentiel de données de qualité peut parfois provenir
de plus petites entités. Par exemple, au sein d’une même entreprise, la fonction « Ventes » peut
émettre un besoin plus urgent que la fonction « Ressources Humaines », et leurs attentes en termes
d’analyses seront différentes. Serait-il alors possible de construire rapidement et à coûts réduits un
« Data Warehouse » spécialisé dans les Ventes ?
Cette solution existe et est appelée « Data Mart » (magasin de données). C’est une sorte de Data
Warehouse réduit et spécialisé sur un périmètre donné (branche d’activité, fonction...). Un Data
Mart regroupe, consolide et traite les données d’un secteur d’activité spécifique. Il est généralement
facile, rapide et donc peu coûteux à mettre en place.
1
Citation d’Eric Schmidt, ex-PDG de Google.

10
Dans le cadre d’un logiciel BI déjà installé sur le système, il est assez intuitif de mettre en place un
Data Mart. Les phases de développement, d’automatisation et de diffusion des résultats sont alors
guidées par le logiciel. Cependant, lorsqu’il n'y a pas de logiciel spécialisé à disposition, il est toujours
possible de mettre en place un Data Mart par ses propres moyens. Des langages de programmation
comme SAS, UNIX et SQL peuvent permettre de générer la structure du Data Mart, de le fournir en
données, et de calculer des indicateurs qui pourront être analysés.
Le mémoire s’inscrit dans ce deuxième cas, lorsque nous ne possédons pas de logiciel BI déjà installé.
De ce fait, la problématique est la suivante :
Pourquoi et comment créer, implémenter et optimiser un Data Mart, sans l’aide de logiciel
spécialisé, dans le but de fournir des indicateurs de performances.
Pour tenter de répondre à cette problématique, le mémoire est divisé en deux parties : une première
partie faisant l’état de l’art et une deuxième partie décrivant la méthode utilisée pour apporter une
solution au développement, à l’automatisation et à l’optimisation d’un Data Mart.
Dans la première partie sont introduites les notions d’information, de données, de qualité de
données, d’indicateurs et d’automatisation. Il y est aussi fait une présentation du Data Mart : la
définition, les intérêts, les deux types possibles, et une méthode d’implémentation globale.2
La deuxième partie présente la méthode mise en place, à savoir : les hypothèses de notre étude, les
différentes phases d’implémentation du Data Mart sans l’aide de logiciel spécialisé, en passant par
les solutions d’automatisation et d’optimisation, et les spécificités des différents logiciels de
programmation utilisés.
Finalement, avant de commencer la lecture du mémoire il est conseillé de prendre connaissance des
mots et termes qui sont utilisés tout au long du document : cf. « Glossaire » page 7.
2
Faute de pertinence apportée dans la proposition, certains points ne sont pas abordés comme notamment :
les définitions plus poussées des critères de qualité de données, leurs algorithmes de résolution et les « Master
Data » ; la gestion fine des bases de données, des métadonnées et de l’indexage ; des exemples de Data Mart
et de leurs techniques d’automatisation et d’optimisation, dû à la confidentialité de ceux-ci.

11
NOTIONS DE BASE
Préambule : information et données
L’information
Définition
L’information c’est « le renseignement porté à la connaissance d'un public plus ou moins large, sous
forme d'images, de textes, de discours ou de sons »3
. Plus précisément en informatique, c’est
« l’Élément de connaissance susceptible d'être représenté à l'aide de conventions pour être conservé,
traité ou communiqué »4
.
L’information est donc un terme général qui permet d’identifier un renseignement sur un sujet
spécifique, mis en forme, et pour une audience déterminée. Elle peut être normalisée et
sauvegardée sous forme de donnée, dont certaines propriétés sont regardées (cf. partie suivante
« La donnée »). Et finalement, une nouvelle information peut émaner d’un traitement de données,
que ce soit par transformation, agrégation ou interprétation (cf. partie « Les indicateurs : une vision
traitée et concise de l’information »).
But et bonne pratique
Le but de l’information est bien entendu de communiquer des connaissances pour les assimiler,
l’historiser, prendre des décisions etc. Mais son objectif est aussi de faire l’état des lieux des
connaissances en termes d’identité, de fiabilité, de structure et d’accessibilité. On parle alors de
« bonne » information.
 Identité : L’auteur est-il facilement identifiable ? Cite-t-il à son tour ses sources ?
 Fiabilité :
o L’information a-t-elle été vérifiée ? Est-elle précise et exacte ?
o Est-elle mise à jour et donc apporte-t-elle du nouveau ? (Ce qui est la fonction même
de l’information : « enrichit-elle les connaissances ? »)
 Structure : L’information est-elle bien présentée ? Bien rédigée ? Sur quels critères se base-t-
on ?
 Accessibilité : Elle doit être facilement localisée et retrouvée à une adresse stable et par
différents moyens.
Toutes ces propriétés assurent, lorsqu’elles sont bien gérées, une information de qualité et donc une
information de valeur, reconnue par le public.
Aussi, Il faut bien différencier l’information de la communication. La communication est le support
de diffusion de l’information. Elle est composée d’un ensemble de moyens et techniques
permettant la transmission de l’information auprès d’une audience.
3
Citation : http://www.larousse.fr/dictionnaires/francais/information
4
Idem

12
La donnée
Définition et valeur
Une donnée c’est « ce qui est connu ou admis comme tel, sur laquelle on peut fonder un
raisonnement, qui sert de point de départ pour une recherche »5
. C’est aussi « une représentation
conventionnelle d’une information en vue de son traitement informatique »6
. Les données peuvent
être de différentes formes : papier, alphabétique, numérique, sons, images, etc.
Les données se regroupent généralement dans des bases de données qui sont des conteneurs
permettant de stocker et de retrouver l'intégralité des informations en rapport avec une activité.
Une base de donnée peut être modélisée par beaucoup de choses (bibliothèque, archives, web, etc.)
mais par vulgarisation, on appelle « base de données » un élément informatique qui sauvegarde les
données de manière hiérarchisée et structurée, en vue de collecter les données, de les stocker et
de les restituer. Ces données sont généralement reliées entre elles dans différentes tables par des
méthodes de jointures. La gestion des bases de données est un chantier volumineux en
informatique, mais il n’est pas abordé dans ce mémoire car il constitue un sujet à lui seul.
Il existe aussi les données non structurées, qui sont définies de la manière suivante par Bill Inmon7
:
« tout document, fichier, image, rapport, formulaire, etc. qui n’a pas de structure standard définie
qui permettrait de le stocker facilement dans un dispositif de traitement automatisé. Il ne peut pas
être défini en termes de lignes et de colonnes ou d’enregistrements. (...) Les données non
structurées sont les e-mails, les feuilles de calcul, les documents, etc. Certaines des informations les
plus précieuses de l’entreprise résident dans ses données non structurées. »8
Une donnée peut être figée (par exemple lorsqu’elle décrit une réalité absolue qui n’est pas censée
bouger dans le temps), mais elle peut aussi apparaître suite à un évènement. C’est le principe d’une
donnée dynamique mise à jour régulièrement et, si possible, automatiquement. On parle alors de
données « chaudes » (mises à jour dans la journée ou même dans l’heure) par rapport aux données
« froides » (qui datent depuis plusieurs semaines voire plusieurs mois). Les données chaudes ont
généralement plus de valeurs que les données froides car elles sont plus récentes et sont donc
censées mieux représenter la réalité actuelle. Cependant, suivant le type de donnée, une donnée
froide peut avoir tout autant de valeur qu’une donnée chaude. Par exemple : les historiques (dont la
plupart des données sont « froides » mais qui sont essentielles quand il s’agit d’effectuer un retour
sur l’activité, des prévisions, des estimations, etc.).
D’une manière plus générale, on définit la valeur d’une donnée comme la différence entre son
bénéfice et son coût. Ces deux aspects peuvent être calculés sur plusieurs critères :
 Son identité : source, date de création, date de mise à jour
 Sa forme et ses métadonnées (cf. partie « Les métadonnées » ci-dessous)
 Sa qualité (cf. partie « Qualité de données » ci-dessous)
 Son stockage : méthodes de sauvegardes et d’entretiens
 Son analyse : information dégagée
Le critère qui sera détaillé ici sera celui de la qualité, car c’est un élément déterminant dans la
construction d’indicateurs et l’analyse de données. C’est aussi le critère le plus important dans la
5
Citation : http://www.larousse.fr/dictionnaires/francais/donnée
6
Idem
7
Bill Inmon : Un des principaux théoricien de l’Informatique Décisionnelle, avec Ralph Kimball.
8
http://www.information-management.com/glossary/u.html

13
valeur de la donnée. Si la donnée n’est pas de qualité dès le départ, alors tout ce qui en découle est
biaisé. C’est le cas pour un Data Mart.
Qualité de données
La qualité de donnée est définie de la manière suivante par la réglementation ISO 90000:2005 :
« C’est l’ensemble des caractéristiques intrinsèques d’une entité qui lui confèrent l’aptitude à
satisfaire des besoins implicites, ou exprimés en interne (pilotage, prise de décision, etc.) ou en
externe (réglementations, etc.) ». Sachant que les données contribuent au succès de l’activité de
l’entreprise, leur qualité représente un enjeu critique pour l’entreprise dans les trois étapes de leur
cycle de vie :
 Lors de la saisie
 Au cours des transformations et agrégations
 Pendant l’analyse et la présentation des résultats
Les caractéristiques intrinsèques des données sont les suivantes :
1. Unicité
2. Complétude
3. Exactitude
4. Conformité
5. Cohérence
6. Intégrité

14
La description et les méthodes mises en œuvre pour assurer la qualité de données sur ces critères
sont résumées dans le Tableau 1 suivant, à l’aide du document de l’Université Paris Dauphine rédigé
par Dario Colazzo « La donnée et sa dimension de valeur », 10 décembre 2013 :
Tableau 1 : Récapitulatif des différents critères de qualité de données
Critères Description
Méthodes possibles pour assurer la
qualité
Unicité
Assurer l’absence de doublons Processus déterministe : vérifier des
propriétés de rapprochement simples sur
des champs discriminant précis.
Processus probabiliste : utilisation
d'algorithmes de rapprochement prenant en
compte les composants syntaxiques et les
informations complémentaires. (exemples :
Jaccard Similarity, Cosine Similarity...)
Complétude
Présence de données indispensables au
niveau objet ou jeu de données
Vérifications manuelles
Exactitude
La valeur de la donnée est la
représentation exacte de sa grandeur
dans le monde réel
Vérifications manuelles
Conformité
Sous dimension de l'exactitude. C'est le
respect d'un ensemble de contraintes
de format.
Vérification manuelles. Possibilités de les
faire en masse.
Cohérence
Pas d'informations conflictuelles ou
contradictoires
Vérification manuelles. Possibilités de les
faire en masse.
Intégrité
Respect des contraintes d'intégrités du
modèle de données (clés primaires, clés
externes, etc.)
Vérification manuelles. Rapides au niveau
des descriptions de données (métadonnées
etc.)
De plus, la qualité de donnée repose aussi sur des critères de services, plus généraux, qui sont :
 Actualité : une donnée est périmée à l’instant t si elle est incorrecte à cet instant, mais
qu’elle était correcte auparavant.
o Exemple : plus de 3 millions de foyers déménagent en France chaque année. Cela
implique que 5% des adresses d’un fichier client n’est plus d’actualité après un an.
 Accessibilité : facilité d’accès aux données. Accessible sur différentes plateformes, à
différents endroits, et suivant les droits d’accès.
 Pertinence : la granularité de l’information doit correspondre aux besoins.
 Compréhensibilité : chaque utilisateur, chaque processus, chaque application trouve
facilement l’information souhaitée.9
Les aspects plus poussés de la Qualité de données (tels que la Master Data, le Problème de qualité de
donnée, les Algorithmes de résolutions, etc.) ne sont pas abordés dans ce mémoire. L’objectif ici est
d’avoir une vision d’ensemble des principes de Qualité en prenant connaissances des 6
caractéristiques intrinsèques qui sont regardées dans ce milieu. L’Unicité est souvent une
9
« La donnée et sa dimension de valeur », Chercheur Dario Colazzo, Université Paris Dauphine, 10 décembre
2013

15
caractéristique difficile à gérer. Nous le verrons dans la partie « pratique » du mémoire, lorsqu’il
s’agit de dé-doublonner des listes de données pour le calcul des indicateurs.
Les métadonnées
Une métadonnée est une donnée à propos d’une donnée (mot composé du préfixe grec « meta »,
indiquant l'auto-référence10
). Par exemple, la métadonnée « taille » de la donnée « code postal »
peut prendre la valeur 5, pour définir que la donnée « code postal » doit faire exactement 5 chiffres
(75015, 92500, etc.).
Les métadonnées sont un aspect très important des bases de données car elles permettent de définir
en détails la nomenclature des données. Elles servent à la fois à blinder les saisies de manière brute
et donc à assurer une partie de la qualité de l’information (un code postal à 6 chiffres sera rejeté par
la base de données et celle-ci renverra une erreur), mais aussi à renseigner plusieurs informations
essentielles comme :
 Le type (entier, réel, caractères, date, etc.)
 La longueur
o Longueur max/min
o Longueur fixe (exemple code postale)
 Le nom (l’identifiant informatique de la donnée)
 Le label (nom affiché lors des résultats de requêtes)
 Et d’autres, comme le nombre de décimales pour un type « réel », ou l’encodage du texte
pour un type « caractères », etc.
L’ensemble des métadonnées est appelé le « dictionnaire de données ».
Dans le cadre d’un Data Mart, les métadonnées jouent un rôle important quand il s’agit de définir les
indicateurs qui seront créés. Dans notre proposition nous nous attachons à répondre à la question
suivante : quelles sont les métadonnées de nos indicateurs ?
Les indicateurs : une vision traitée et concise de l’information
Définition
En informatique décisionnelle, un indicateur est une nouvelle donnée créée pour fournir une
information supplémentaire à partir de données traitées suivant des règles. C’est un outil
d’évaluation et d’aide à la décision à partir duquel on va pourvoir mesurer une situation ou une
tendance. Un indicateur peut être perçu comme une sorte de résumé d'informations complexes
offrant la possibilité à des acteurs différents de comprendre leurs environnements et de dialoguer
entre eux.
Par exemple, dans le domaine du crédit, un indicateur simple peut être le « nombre de crédits
immobiliers d’une valeur supérieur à 100 000 € signés dans le mois ». Une liste de dossiers éparpillés
dans la base de données sera donc résumé en un nombre (ex : 2700). Dans la pratique, beaucoup
d’indicateurs simples sont utilisés pour avoir une vision rapide de l’activité quotidienne de
l’entreprise, mais aussi d’autres plus complexes sont pensés : calculs sur plusieurs données
10
Source : http://fr.wikipedia.org/wiki/Métadonnée

16
mensuelles et suivant plusieurs règles, indicateurs imbriqués (indicateurs agrégés à partir d’autres),
etc. L’utilité d’un indicateur dépend naturellement de sa capacité à refléter la réalité, mais aussi de
sa simplicité de compréhension et d’acquisition.
Les indicateurs peuvent être de différentes formes : binaires (oui/non), quantitatif (numériques),
qualitatif (caractères), etc. Ils sont calculés à partir de règles qui s’appliquent sur un ensemble de
données. Par exemple : « si un dossier porte le nom ‘immobilier’ et une valeur initiale supérieur à
100 000 €, alors on le comptabilise ».
Avantages
 Fournis un accès rapide à l’information.
 Orienté pilotage pour les directions.
 Coût de stockage faible, bénéfice à l’analyse fort.
 Modulable (création et modification rapide).
 Historisable puis comparable.
Inconvénients
 S’ils sont regardés seuls : perte de l’information de base, vision « trop globale ».
 Ne prend pas en compte certaines données environnementales temporelles : si par exemple
les référentiels de données changent mais pas les méthodes de calculs, alors l’historique de
l’indicateur est biaisé.
Caractéristiques recherchées
Beaucoup de sites internet d’entreprises, de publications et de blogs sont convergents sur les
caractéristiques d’un « bon indicateur »11
. De façon générale, plusieurs critères sont regardés :
1. Pertinent : Doit correspondre à une attente de l’organisation qui le met en place, doit avoir
un but bien défini pour la mesure et l’analyse. Dans la pratique, beaucoup d’indicateurs sont
créés et seulement une poignée est réellement utilisée. Le but d’un indicateur pertinent est
d’éviter cela, même si, au vu de leurs coûts faibles et de leurs potentiels forts, il est
préférable d’avoir dès le départ une longue liste d’indicateurs à sa disposition (quitte à y
attribuer un niveau de pertinence).
2. Réalisable : Une fois pensé, l’indicateur doit pouvoir être construit à partir des données à
disposition. Il est rare de pouvoir imaginer un indicateur sans pouvoir le mesurer dans la
pratique, mais il faut garder en tête qu’un indicateur conceptuellement parfait mais
difficilement mesurable n’est pas très utile.
3. Représentatif : L’indicateur doit bien évidemment être précis dans sa définition, mais aussi
dans sa mesure. Il doit représenter le plus parfaitement possible la grandeur qu’il cherche à
mesurer. Ce critère n’est pas des plus simples à respecter puisque suivant les méthodes de
calculs qui peuvent être difficiles, ou la qualité de donnée qui peut faire défaut (comme la
11
Sources : - http://www.gbo.tn/index.php?option=com_fsf&view=faq&Itemid=189&catid=2&faqid=3
- http://www.qualiblog.fr/objectifs-indicateurs-et-tableaux-de-bord/comment-definir-des-indicateurs-
pertinents-pour-mesurer-lefficacite-des-systemes-de-management/
- http://www.has-sante.fr/portail/upload/docs/application/pdf/2013-
02/suivi_indicateurs_qualite_fiche_technique_2013_01_31.pdf
- http://www.blog.saeeed.com/2009/11/les-caracteristiques-dun-bon-indicateur/

17
présence de quelques doublons par exemple), il sera difficile d’avoir une valeur parfaitement
juste. Plus le jeu de données sur lequel se base l’indicateur est grand, et plus les risques de
biais augmentent.
a. Sensible : La sensibilité est l’équivalent de la représentativité sur les variations de
l’indicateur. Il doit refléter le plus parfaitement possible les variations de ce qu’il
cherche à mesurer. Si la grandeur évolue, alors l’indicateur est censé évoluer dans
les mêmes proportions.
b. Robuste : A l’instar de la sensibilité, un indicateur doit être suffisamment stable pour
ne pas être altéré par les fluctuations aléatoires et temporelles. Il faut donc trouver
l’équilibre entre sensibilité et robustesse.
Dans la pratique, un indicateur très représentatif entraine à la fois une bonne sensibilité ainsi
qu’une bonne robustesse. Il faut cependant garder en tête que l’indicateur parfait n’existe
pas. Il faut coupler et comparer plusieurs indicateurs pour avoir une représentation
complète et qualitative de la réalité.
4. Disponible : Un indicateur doit avant tout être vu et utilisé. S’il est sauvegardé quelque part
mais laissé à l’abandon, alors il devient inutile. C’est pourquoi les indicateurs doivent pouvoir
être accessibles facilement par les utilisateurs intéressés. Cela peut être sous forme de
compte d’accès à une base, ou sous forme de reportings générés automatiquement. Cet
aspect rejoint aussi la disponibilité des données, qui elles, doivent être produites
suffisamment rapidement avec une bonne fréquence pour garantir la mise à jour de
l’indicateur en temps utile.
5. Compréhensible : Si un indicateur n’est pas compris par la personne qui l’utilise, il perd tout
son sens. Il doit être intelligible : simple, clairement défini et compréhensible. Son
interprétation doit être commune et partagée pour pouvoir l’utiliser confortablement dans le
milieu opérationnel. Dans la pratique, une méthode simple pour satisfaire ce critère est de
rédiger un référentiel qui décrit en détails le but, les paramètres, et les règles de calculs des
indicateurs. Il peut même être plus complet pour l’équipe technique en affichant clairement
les requêtes utilisées pour les construire.
6. Traçable : Finalement, lorsque les 5 premiers critères sont respectés, il est important de
pouvoir justifier la source. La construction de l’indicateur doit être documentée et
identifiée. Par exemple si des modifications ont été apportées, il est important de savoir
pourquoi (à la suite de quelle anomalie et les états avant/après), par qui et quand ont été
faites ces modifications.
Axes d’analyse
Les axes d’analyse apportent la notion de dimension aux indicateurs. Ils sont similaires aux
« dimensions » que l’on retrouve dans un Cube OLAP (cf. Glossaire). Si on reprend l’exemple du
« nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés », c’est un chiffre global,
défini par une méthode de calcul générique. Tel quel, il apporte une information de valeur mais ne
permet pas non plus de piloter le crédit immobilier dans le détail. Il est possible de fragmenter ce
chiffre pour affiner l’indicateur et répartir le résultat : c’est ce que les axes d’analyse permettent de
faire.
La formule usuelle d’un indicateur soumis à un axe d’analyse est « indicateur par axe ». Par exemple,
si l’organisation se divise en plusieurs agences A, B, C, D et E qui appartiennent à deux pôles 1 et 2,
alors il est possible de soumettre l’indicateur aux deux axes :

18
1. « nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés, par agence »
2. « nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés, par pôle »
L’axe 1 par agence est l’axe le plus fin, tandis que l’axe 2 par pôle est l’axe de niveau supérieur, qui
intègre l’axe 1. D’une manière générale, un axe d’analyse est en fait une hiérarchie de plusieurs
sous-axes. C’est à partir de ces axes d’analyse que l’agrégation d’un indicateur va être réalisée. Dans
notre exemple, il est possible d’appeler l’axe d’analyse général : « axe_entité_gestionnaire ». On
obtient alors le tableau suivant qui donne un exemple de l’utilisation des axes d’analyse :
Tableau 2 : Exemple d’indicateurs et d’axes d’analyse
axe_entité_gestionnaire Indicateurs
Pôles Agences
Nb de crédits immobiliers
sup. à 100 000 € signés
Indicateur 2 Indicateur 3
1
A 120 … …
B 230 … …
C 90 … …
2
D 160 … …
E 210 … …
A partir d’une répartition par axe d’analyse, il devient donc possible de faire des totaux généraux ou
des sous-totaux (sommes, moyennes). Le total général n’est autre que la valeur de l’indicateur sans
axe d’analyse.
Les « KPI » : notion
KPI est l’acronyme de « Key Performance Indicator ». Il est traduit par ICP : « Indicateur Clef de
Performance ». Il est important de connaître cet acronyme car il est beaucoup utilisé, surtout dans
les domaines du marketing, de la finance et du risque. Initialement, un KPI est un indicateur très
important car très regardé pour le pilotage de l’organisation, mais il est de plus en plus utilisé
comme raccourci pour définir n’importe quel indicateur d’aide à la décision. Les KPI sont censés être
les quelques indicateurs regardés fréquemment à partir desquelles des conclusions importantes sont
tirées. Par exemple, dans une entreprise de marketing web, des KPI peuvent être : le nombre de
visites quotidiennes, le taux de transformation12
quotidien, le panier moyen d’un acheteur, etc. Les
indicateurs de moins grande importance sont par exemple le « nombre de clics quotidiens sur telle
rubrique », le « temps moyen passé par page », etc.
Les indicateurs sont, en partie, le résultat du développement d’un Data Mart. Ils doivent être pensés
et créés en respectant les caractéristiques citées ci-dessus, et le Data Mart doit être développé en
suivant ces idées. Un autre aspect important dans cette démarche est l’automatisation. Tout au long
du processus, les traitements doivent être automatisés pour garantir une fiabilité et une rapidité
maximale. Un indicateur est l’agrégation de plusieurs données, il est donc impossible de le générer
« à la main » lorsque la base de données sur laquelle il se base dépasse une certaine taille. On doit
alors avoir recours à des logiciels (Progiciels intégrés spécialisés dans la BI, Excel à petite échelle, etc.)
12
Taux de transformation : c’est le rapport entre le nombre de personnes qui achètent effectivement sur le
site, et le nombre total de visites. Il est généralement très faible.

19
ou des langages informatiques de traitements de tables et de données (SQL, SAS, UNIX…) pour
développer et mettre en forme tous les programmes nécessaires.
L’automatisation du traitement de données
Définition
L’automatisation est la « suppression totale ou partielle de l'intervention humaine dans l'exécution
de tâches diverses »13
. Elle vise à accélérer et consolider les processus qui y sont soumis. C’est
l’essence même de l’informatique (les principes fondamentaux de l'informatique identifiés par Peter
Denning sont : computation, communication, coordination, automatisation, évaluation,
conception14
). L'automatisation ne consiste pas simplement à remplacer l'homme par un automate,
mais conduit à repenser plus ou moins profondément le processus considéré et à remettre en question
les habitudes acquises et les solutions traditionnelles. Prenant en charge tout ou partie des fonctions
intellectuelles intervenant dans la conduite d'un processus, elle se situe à un niveau supérieur à la
simple mécanisation. Partie intégrante de la conception et de la gestion des grands ensembles
industriels, administratifs et commerciaux, elle constitue l'un des facteurs d'accroissement de la
productivité et d'amélioration de la qualité.15
Cette description de l’automatisation donnée par Larousse est très large car elle introduit les sujets
de refonte des processus contre les solutions traditionnelles, de la différentiation par rapport à la
mécanisation, et de son apport d’améliorations dans la productivité et la qualité.
C’est ce dernier point d’améliorations de la productivité et de la qualité qui est le plus recherché
lorsqu’on décide d’automatiser un processus, et c’est celui qui est détaillé dans ce mémoire.
En informatique, la mise en automatisation est un investissement avant tout. Le fait de mettre en
place un projet pour automatiser un ou plusieurs processus requiert des fonds (humains et
financiers). Le fait d’automatiser est coûteux et doit répondre à des besoins de temps et d’efficacité.
C’est pourquoi il est important d’avoir une méthodologie adaptée pour formaliser ce qui est voulu
(besoin) et ce qui est fait (recette).
Méthodologie possible
Le souhait d’automatiser un processus vient souvent du fait que ce processus est connu, redondant
et long à réaliser. Par exemple, dans une équipe d’aide à la décision, les statisticiens peuvent être
chargés de sortir chaque mois des reportings pour les équipes opérationnelles. Pour cela ils peuvent
utiliser SQL, interroger la base de données directement, et retravailler la mise en forme et l’analyse
via un tableur (exemple : Excel). Il est aussi possible d’utiliser un logiciel spécialisé qui permet de faire
la même chose de façon plus intuitive (exemple : SAP, Cognos, Talend, SAS Enterprise Guide, etc.).
Dans les deux cas, ce sont des processus qui sont réalisés « à la main », qui demandent du temps et
qui peuvent être sources d’erreurs. L’automatisation, grâce à ses deux principaux avantages qui sont
la rapidité d’exécution et l’exactitude des résultats, est une solution à ce problème.
La méthodologie d’automatisation qui est globalement utilisée est la suivante :
13
http://www.larousse.fr/encyclopedie/divers/automatisation/24386
14
“Great Principles of Computing” : http://cs.gmu.edu/cne/pjd/GP/GP-site/welcome.html
15
http://www.larousse.fr/encyclopedie/divers/automatisation/24386

20
1. Définition du périmètre et des besoins : qu’est-ce qui est fait jusqu’à présent ? Des
évolutions métiers sont-elles prévues ? Qu’est-ce qui doit être automatisé ?
2. Analyse du ratio bénéfices/coûts : il faut s’assurer que sur le long terme, les bénéfices de
temps et de qualité seront supérieurs aux coûts de développement et d’entretien. Lorsque
les moyens humains sont disponibles, cette analyse est rarement faite car un processus
automatique est plus rentable dans quasiment tous les cas.
3. Outils utilisés : comment allons-nous automatiser, avec quels langages informatiques et/ou
quels logiciels ?
4. Forme des résultats : se mettre d’accord avec les équipes opérationnelles qui profiteront des
résultats pour s’assurer de leurs besoins dès le départ.
5. Développement : via des langages de programmation pour créer son propre logiciel ou via un
logiciel spécialisé (moins flexible, plus ergonomique).
6. Recette et validation : tester le programme et valider les résultats avec le métier. Ce qu’on
obtient est-il juste ? N’y a-t-il pas de régression par rapport à l’ancienne méthode ?
7. Mise en production : une fois les tests validés, il faut définir les paramètres temporels du
logiciel (lancé automatiquement chaque jour, chaque mois, à la main ?) et passer le
processus en production.
Les différents niveaux d’automatisation
Il existe plusieurs niveaux d’automatisation suivant le nombre d’intervention et leur type :
 Automatisation complète : le processus se lance tout seul depuis un serveur à des horaires
définis. Tout le processus est automatique, jusqu’à la diffusion des résultats.
 Automatisation quasi-complète : le processus nécessite une intervention humaine simple,
que ce soit au début pour lancer le programme, ou à la fin pour diffuser les résultats.
 Automatisation fragmentée : une grande partie du processus est automatique et plusieurs
interventions humaines simples sont nécessaires comme par exemple alimenter un
référentiel utilisé par le programme mais donné par les équipes métiers, transférer les
résultats obtenus avant l’envoi vers un template de mise en forme, etc.
 Automatisation partielle : certaines parties du processus sont automatiques mais d’autres ne
le sont pas. L’humain doit intervenir dans la modification des programmes pour mettre à
jour une variable par exemple, puis lancer manuellement le processus.
Inconvénients
Mise à part les avantages cités dans la définition de l’automatisation, celle-ci peut avoir certains
inconvénients, moins importants, mais dont il est bon d’avoir connaissance. Comme pour les
indicateurs, l’automatisation impose un certain recul par rapport aux données de bases qui sont
traitées, et ce recul est d’autant plus important que l’automatisation intervient à un niveau plus
élevé : elle intègre des processus et traitements imbriqués et pas seulement des agrégations de
données.
Les automatisations font souvent place à des « boites noires », c’est-à-dire des programmes qui
fonctionnent, mais dont on ne connait pas vraiment les détails de l’exécution. Le jour où un
problème survient, il devient difficile de le corriger car nous n’avons pas connaissance du programme
et de son fonctionnement. Il est donc important, voire primordial, de commenter le programme et

21
de documenter son fonctionnement, de manière fonctionnelle et détaillée. Les commentaires
figurent à l’intérieur du programme tandis que le document peut être un document texte qui
explique les fonctions du programme, avec des schémas par exemple.
Il existe aussi une 3ème
aide à la résolution des problèmes qui se met à jour à chaque exécution du
programme : la « log » (appelé « journal d’exécution » en français). Ce fichier sert de vérification et
permet d’identifier les erreurs rapidement (et même de les comprendre lorsque la génération de la
log est bien faite). La log peut être générée soit automatiquement par les logiciels spécialisés ou
même certains langages comme SAS, soit par le développeur via des instructions dans le programme.
Dans les deux cas, il est important de la sauvegarder à chaque exécution car elle peut s’avérer très
utile.
Lois et règles en vigueur sur les traitements automatisés
Il est important de prendre connaissance des réglementations en vigueur lorsqu’on souhaite
automatiser des traitements de données, car il se peut qu’ils soient soumis à des conventions. Par
exemple, en Europe, le traitement automatique de données à caractères personnel est soumis à
une convention dont le but est de « garantir, sur le territoire de chaque Partie, à toute personne
physique, quelles que soient sa nationalité ou sa résidence, le respect de ses droits et de ses libertés
fondamentales, et notamment de son droit à la vie privée, à l'égard du traitement automatisé des
données à caractère personnel la concernant »16
. Par « traitement automatisé s'entend des
opérations suivantes effectuées en totalité ou en partie à l'aide de procédés automatisés :
enregistrement des données, application à ces données d'opérations logiques et/ou arithmétiques,
leur modification, effacement, extraction ou diffusion ».
Dans le cadre du développement d’un Data Mart par exemple, des extractions, des opérations
logiques et arithmétiques, et des diffusions sont réalisées. Il faut donc s’assurer que le projet que
nous mettons en place a été validé sous un angle juridique.
16
« Convention pour la protection des personnes à l'égard du traitement automatisé des données à caractère
personnel », Strasbourg, 28.I.1981. Lien : http://conventions.coe.int/treaty/fr/treaties/html/108.htm

22
ETAT DE L’ART ET ANALYSE
Data Mart
Tout au long de ce chapitre, les notions énoncées se basent sur les expériences personnelles et sur
les écrits de documents et livres officiels rédigés par des acteurs principaux de la BI17
.
Définitions et principes
Définition
Le Data Mart (DM) est un « magasin » qui regroupe et traite les données d’un domaine spécifique.
Les deux principaux théoriciens de l’Informatique Décisionnelle en ont fait une définition formelle :
 Définition de Ralph Kimball : « Le Data Mart est un sous-ensemble du Data Warehouse,
constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer
tout le spectre d’une activité métier. L’ensemble des DataMarts de l’entreprise est censé
constituer le Data Warehouse. »
 Définition de Bill Inmon : « Le Data Mart est issu d’un flux de données provenant du Data
Warehouse. Contrairement à ce dernier qui présente le détail des données pour toute
l’entreprise, il a vocation à présenter la donnée de manière spécialisée, agrégée et regroupée
fonctionnellement. »
Un DM est souvent créé et géré par un seul département dans l’organisation. Par exemple, le
département Marketing gère le Data Mart marketing, les Finances le DM finance, etc. De par son
aspect « domaine d’activité », il récolte généralement les données de peu de sources. Ces sources
peuvent provenir d’un Data Warehouse central, de systèmes opérationnels internes, ou de
systèmes externes à l’organisation. On parle alors de DataMarts dépendants (Data Warehouse) ou
indépendants (autres sources internes ou externes). Généralement les DataMarts fournissent aussi
des données traitées et agrégées pour le métier, comme des indicateurs. Ces processus de calculs
doivent être automatisés pour garantir un certain niveau de performances.
Structure physique et théorique
Les DataMarts peuvent être stockés physiquement sur des disques durs hébergés sur un serveur. Le
support théorique quant à lui peut être de plusieurs formes :
 Soit par un Système de Gestion de Base de Données (SGBD) : le Data Mart n’est autre qu’un
SGBD relationnel.
 Soit par un système de dossiers contenants des fichiers plats (CSV, etc.).
 Soit finalement par un mélange des deux : un système de dossiers contenants des fichiers
aux formats bases de données (par exemple SAS avec ses bases de données sous formes de
fichiers mobiles .sas7bdat)
17
- « Building the Data Warehouse » – William H. (Bill) Inmon. 3
rd
edition, John Wiley & Sons, 2002.
- « The Data Warehouse Toolkit » – Ralph Kimball & Margy Ross. 2
nd
edition, John Wiley & Sons, 2002.
- « Business Intelligence Standard » – Oracle®. Edition one, 2007.
Lien : http://docs.oracle.com/html/E10312_01/dm_concepts.htm
- « Data Mart Consolidation : getting control of your enterprise information » – IBM®, Redbooks. 2005.
Lien : http://www.redbooks.ibm.com/redbooks/pdfs/sg246653.pdf

23
Le Data Mart peut parfois être confondu avec la notion de Cube OLAP. Il peut par exemple être
représenté par un modèle en étoile dans une base de données (notamment lorsqu'il s'agit de
données brutes non agrégées).
En quoi un Data Mart est-t-il différent d’un Data Warehouse ?
Un Data Warehouse, contrairement à un Data Mart, traite des données de plusieurs domaines
d’activités et est souvent contrôlé par une entité centrale au sein de l’organisation (par exemple la
Direction des Systèmes d’Information). On parle alors de Data Warehouse central de l’entreprise. Il
va tirer ses données de plusieurs sources à travers l’organisation et de ce fait être volumineux.
Rien n’empêche un Data Mart d’être lui aussi complexe ou volumineux mais, ne cherchant pas à
regrouper toutes les données de l’organisation mais plutôt à se spécialiser dans un domaine
d’activité, il sera généralement moins volumineux qu’un Data Warehouse. Il peut aussi différer sur
plusieurs caractéristiques comme sa granularité, son partitionnement de données, etc. Il est de ce
fait plus facile à créer et maintenir que le Data Warehouse. Le tableau suivant présente les
principales différences entre un Data Mart et un Data Warehouse.
Tableau 3 : Principales différences entre un Data Warehouse et un Data Mart
Catégorie Data Warehouse Data Mart
Périmètre Toute l’organisation Par domaine d’activité
Thèmes Plusieurs Un seul
Sources de données Beaucoup Peu
Taille (moyenne) 100 Go à plusieurs To < 100 Go
Temps d’implémentation Plusieurs mois voire années Quelques mois
Une autre des principales différences entre un Data Warehouse et un Data Mart vient du fait que
lorsque le Data Mart est implémenté dans un environnement munis d’un Data Warehouse, il est
souvent généré après celui-ci. C’est-à-dire qu’il tire ses sources de données du Data Warehouse (cf.
partie « DataMarts dépendants et indépendants » ci-dessous). C’est alors là que la définition de
Ralph Kimball prend tout son sens.
Pourquoi développer un Data Mart ? Quelle en est la limite ?
Le but premier d’un Data Mart est de regrouper de manière spécialisée les données d’un domaine
d’activité de l’entreprise. Il va chercher les données liées aux applications métiers pour les
regrouper dans une même base exhaustive et récapitulative. Par ce biais, il permet de classer et de
clarifier les données pour les métiers. Chaque métier, appartenant au domaine d’activité choisi, aura
ainsi accès aux données qui l’intéresse, sans être affecté par des données contiguës. C’est d’ailleurs
de là que découle l’intérêt technique d’un Data Mart : délester les systèmes opérationnels d’où il
tire ses données (Data Warehouse ou autres bases de données) des requêtes répétitives que ces

24
derniers subissent. Il est plus facile pour les utilisateurs et le système de gérer un Data Mart qui ne
contient que l’essentiel de l’information car il est plus rapide à l’exécution et moins coûteux pour le
SI.
Le deuxième but, tout aussi important, est de fournir une base de qualité pour l’analyse et la
construction d’indicateurs. Les données contenues dans le Data Mart sont généralement dans l’état
le plus « pur » pour le secteur d’activité qui les utilise (c’est du moins ce qui est visé lors de la partie
« Extractions et transformations »). De ce fait, il est possible de diffuser des rapports d’analyse pour
le métier, et d’implémenter une partie qui regroupe tous les indicateurs et leur historique (cf. partie
« Les indicateurs : une vision traitée et concise de l’information »).
Mais le premier point de simplification présente certaines limites. Le fait de ne contenir que des
données spécifiques à un domaine d’activité peut parfois entrainer des complications, notamment
lorsqu’il s’agit de vouloir expliquer une problématique plus globale et que cela impose de sortir de
son cadre d’analyse habituel. L’accès aux autres données est alors requis ce qui entraine des coûts
de développement importants pour des requêtes éphémères. Le problème peut devenir encore plus
grave lorsque les DataMarts ne constituent que l’unique accès aux données pour toute
l’organisation.
DataMarts dépendants et indépendants
Comme introduit dans la définition, il existe deux types de Data Mart : les DataMarts dépendants et
les DataMarts indépendants. La principale différence vient du mode d’importation des données :
d’où et comment ?
 « D’où ? » : Les DM dépendants prennent leurs données d’un Data Warehouse central qui
est déjà construit.
Tandis que les DM indépendants récoltent directement leurs données de systèmes
opérationnels internes et/ou externes à l’entreprise.
 « Comment ? » : L’ETL (Extraction-Transformation-Loading) mis en place pour déplacer les
données est simplifié dans le cadre d’un DM dépendant car il a déjà eu lieu en tout ou partie
lors du chargement des données dans le Data Warehouse. Le travail de la partie ETL est alors
principalement de l’identification de données utiles pour le domaine d’activité du DM.
Cependant, dans le cadre d’un DM indépendant, tout le processus ETL doit être mis en place
lors du chargement des données. Puisque le DM traite un seul sujet, il prend ses données de
sources moins nombreuses que le Data Warehouse, mais ceci n’empêche pas d’avoir un
travail délicat à réaliser d’extraction, de transformation, de traitements automatisés et
d’optimisation.
Mais le mode d’importation des données n’est pas le seul point divergent entre les deux types de
Data Mart. L’autre question qu’apporte cette différence est : pourquoi ?
 Les DM dépendants sont généralement créés dans le but de fragmenter de Data Warehouse
et ainsi d’assurer un meilleur contrôle et une réduction des coûts d’utilisation des données
(cf. partie « Pourquoi développer un Data Mart ? Quelle en est la limite ? » ci-dessus).
 La construction de DM indépendants est souvent motivée par un besoin d’obtenir une
solution dans un délai court, par exemple lorsque le Data Warehouse n’est pas encore mis
en place. Il peut aussi provenir d’une envie de contrôler complètement tout le processus du

25
Data Mart, notamment la partie d’extraction des données, normalement gérée en majeur
partie par le Data Warehouse.
Figure 1 : Schéma représentatif de DataMarts « dépendants »
Figure 2 : Schéma représentatif de DataMarts « indépendants »

26
Implémentation : les étapes
Design
L’étape de Design est la première étape du processus d’implémentation d’un Data Mart. Elle couvre
toute les tâches allant de de l’initiation de l’idée, au design des structures physiques et logiques. Elle
comprend ainsi les tâches suivantes :
 Mise en place du plan d’action dans le but d’énumérer le besoin, la fonctionnalité et la
finalité du futur Data Mart :
o Obtenir l’autorisation de la hiérarchie pour commencer d’étude.
o Définir le périmètre du projet. Il détermine les limites du projet et doit souvent être
pensé en fonction de l’organisation. Pour quel domaine d’activité ?
o Identifier les risques (par exemple que le DM devienne vite obsolète).
o Estimer les coûts (humains, techniques, risques)
o Créer le planning projet (à l’aide de diagrammes de Gantt ou Pert par exemple) et
prévoir les livrables qui valideront les différents phases du projet.
 Définition des besoins fonctionnels et techniques :
o Faire un recueil des besoins fonctionnels. Connaître en détail ce que l’utilisateur
souhaite avoir pour ensuite définir les données qui seront importées et les
indicateurs qui seront créés. Il s’agit de trouver un compromis entre détail, efficacité
et budget.
o Définir les outils techniques qui seront utilisés (software, langages informatiques,
etc.) et les composants physiques pour la sauvegarde des données en estimant la
taille du Data Mart (hardware, serveurs, etc.)
o Obtenir l’accès aux environnements physiques qui permettront de matérialiser le
Data Mart et d’y stocker les données.
 Mise en place du Design :
o Définir la liste des données qui seront importées et ainsi identifier les sources.
o Choisir les méthodes de classification des données pour définir le schéma du Data
Mart.
 Modèle en étoile avec tables de faits + dimensions. (cf. Glossaire)
 Ou modèle SGBD relationnelle. (cf. Glossaire)
o Dans les deux cas, il faut détailler le schéma en définissant les tables qui seront
créées, leurs liens entre elles, les données qu’elles contiendront, leurs métadonnées
(cf. partie « Les métadonnées »), et la granularité (c’est-à-dire le niveau de détail du
stockage des données).
o Créer le design logique, c’est-à-dire le fonctionnement du DM dans sa globalité.
Cette étape peut être réalisée par un diagramme de processus18
. Il est aussi possible
de le compléter avec un pseudo-code (code compréhensible pour des non-
informaticiens) dans le cas d’un DM développé sans l’aide d’un logiciel spécialisé.
Le Design est l’étape la plus importante car il définit la structure et les fonctions principales du Data
Mart. Un Data Mart bien pensé est un Data Mart qui sera efficient et évolutif.
Cette étape reste généralement en parallèle de toutes les autres phases de l’implémentation car le
design peut avoir besoin d’être modifié à tout stade du projet.
18
Un diagramme de processus est un schéma destiné à représenter le processus dans son ensemble avec un
enchaînement d’états et de fonctions. Cf. Figure 3

27
Construction
La phase de construction n’est autre que l’acquisition du support physique et le développement de
la structure du Data Mart. Que ce soit par le biais d’outils intégrés directement dans un logiciel BI ou
par une méthode personnalisée, le but est de :
 Créer la base de données physique du Data Mart, les structures de stockage etc. Par
exemple, utiliser les logiciels comme SQL Server, MySQL…
 Créer les schémas des objets comme les tables ou les interfaces. Référencer les schémas et
en faire des schémas génériques, réutilisables pour une future automatisation.
Extractions et transformations
Cette partie appelée « ETL » (Extract-Transform-Load) consiste à importer, filtrer, transformer
(mettre dans le bon format), calculer (concaténer, agréger, additionner…) et charger les données
dans le Data Mart. C’est un travail qui peut être réalisé de nombreuses manières différentes. Certains
logiciels intègrent directement l’outil, mais il est aussi possible d’utiliser des solutions ETL
indépendantes. Encore une fois, lorsque la solution est développée « à la main », il est possible de
créer son propre ETL via des langages de gestion de données (SQL, SAS…). Les étapes d’un ETL à
mettre en place sont :
 L’extraction des données : créer les liens vers les bases de données et développer les
requêtes nécessaires.
 Le « mapping » des données sources vers les données cibles : quelles données sources vont
permettre d’alimenter quelles données cibles ?
 Filtrer et transformer les données : définir les nouveaux formats des données, implémenter
les données calculées, ne garder que l’information utile.
 Générer les métadonnées associées aux données cibles du Data Mart.
 Charger les données dans l’environnement du Data Mart, en cohérence avec les schémas
développés précédemment.
Calcul des indicateurs (optionnel)
Mettre à disposition des indicateurs dans un Data Mart apporte une forte valeur ajoutée au projet.
Le but étant d’apporter des chiffres et ratios permettant une évaluation rapide de l’activité du métier
(cf. partie « Les indicateurs : une vision traitée et concise de l’information »). Une fois que la partie
ETL est effectuée, il est possible de mettre en place ce système. Il faut alors suivre les étapes
suivantes :
 Reprendre les besoins énoncés dans la partie Design concernant les indicateurs. S’assurer
que la liste est exhaustive.
 Définir en détail les méthodes de calculs et les codes qui y sont affectés.
 Regrouper les indicateurs par métier et ainsi créer les axes d’analyse. Les axes d’analyse
définissent les critères d’agrégation des indicateurs (cf. partie « Erreur ! Source du renvoi
ntrouvable. »). Ils sont ce qui permet d’encadrer l’indicateur et de lui donner son sens.

28
Recette
La recette est la phase de test du Data Mart. Elle permet d’assurer la cohérence et la validité des
données et indicateurs qui y sont présents. Pour ce faire, une méthode simple et efficace consiste à
fournir des lots de données et d’indicateurs aux acteurs métiers, qui sont censés valider les
résultats fournis avec ce qu’il observe réellement sur les applications. Durant cette phase il est
possible de revoir tout ou partie du Data Mart en passant par les étapes suivantes :
 Recette technique : est-ce-que tout le processus fonctionne sans bug informatique ?
 Recette fonctionnelle :
o Le spectre de données est-il complet ?
o Le support physique réservé sera-t-il suffisant à long terme ?
o Les données sont-elles correctes ? Si non, est-ce le processus ETL qui est défaillant ?
o Les indicateurs reflètent-ils la réalité ? Si non, revoir les définitions avec le métier, les
méthodes de calculs et d’agrégation.
o Etc.
Tout le processus technique doit être balayé et toutes les données et indicateurs doivent être
validés. Ceci permet de passer le Data Mart en production et de faire aboutir la première grande
partie du projet.
Accès et diffusion
Il existe deux types d’accès aux données :
1. L’accès direct via un identifiant à renseigner dans une interface de connexion par exemple.
L’utilisateur peut alors naviguer à travers les données en fonction de ses droits. Par
vulgarisation on appellera cela un « accès ».
2. Et l’accès indirect comme par exemple la diffusion et la publication de reportings. Ces
derniers sont utilisés pour les requêtes périodiques qui nécessitent l’affichage d’un rapport
avec souvent plusieurs informations, des graphiques, etc. (cf. Glossaire).
La phase d’accès et de diffusion implique théoriquement que la phase de recette soit validée. En
réalité, les premiers accès et premières publications se font pendant la phase de recette. On parle
« d’accès en environnement de recette » : les acteurs métiers qui sont mobilisés pour la phase de
recette obtiennent des accès provisoires et reçoivent des publications de test. Dans tous les cas, il est
recommandé de suivre les étapes suivantes :
 Instaurer un système de « labels » pour rendre les informations du Data Mart
compréhensible pour un utilisateur métier (labels de bases, de données et d’indicateurs).
Prenons une donnée dans le domaine du crédit bancaire dont l’identifiant est « str11 ». Il
faut par exemple lui attribuer le label « situation comptable » pour qu’elle devienne
identifiable et compréhensible. Ce processus est facilement réalisable via la gestion des
métadonnées puisque le label est une métadonnée.
 Créer et distribuer les accès aux interfaces pour les utilisateurs métiers.
 Définir les diffusions qui seront faites : les reportings. Créer les requêtes, les calculs, les
templates associés, etc.
Pour le dernier point, les logiciels BI (exemple SAS Information MAP) sont très efficaces car ils
proposent un « tout en un » en partant des requêtes jusqu’à l’édition des reportings dans le format
voulu (Web, Excel, CSV, etc.).

29
Automatisation
L’automatisation présente enfin la dernière phase cruciale dans le développement d’un Data Mart.
Comme décrit dans la partie « L’automatisation du traitement de données », c’est un investissement
avant tout. L’automatisation nécessite des ressources (humaines et financières) mais son utilité est
double : accélérer et consolider les processus qui y sont soumis. Un processus automatisé est un
processus rapide et informatiquement stable qui laisse peu de place à l’erreur humaine.
Pour un Data Mart, tout son traitement, que ce soit de l’extraction des données jusqu’à l’édition des
reportings, est automatisable. Un Data Mart automatisé est un Data Mart efficace et durable. Encore
une fois, les solutions apportées par les logiciels spécialisés sont intuitives donc relativement faciles à
mettre en œuvre, tandis que pour un Data Mart personnalisé cette phase est plus délicate et très
chronophage.
Pour obtenir une automatisation complète, par exemple pour faire en sorte que le Data Mart se
lance tout seul la nuit, il est possible d’utiliser une méthode très répandue : le batch processing
(traitement par lots, cf. Glossaire).
Maintenance
Finalement, lorsque tout le système est mis en place il faut en assurer la maintenance, ce qui
implique :
 Un accès sécurisé aux données, en accords avec les accès déjà mis en place sur les systèmes
opérationnels d’où le Data Mart tire ses sources.
 Contrôler l’évolution de l’espace de stockage.
 Assurer la disponibilité des données même lorsque le système tombe en panne. Par exemple
par des systèmes de bases de Back-Up, archives consultables sur demande.
 Et optimiser le système pour des meilleures performances.
Optimisation
Le dernier point relatif à la maintenance du Data Mart est très rarement diffusé auprès du public.
C’est pourquoi il est délicat de donner des exemples concrets de cette partie, alors qu’elle joue un
rôle crucial dans l’efficacité et la disponibilité du Data Mart.
Il existe deux niveaux d’optimisation :
1. L’optimisation de l’impact du Data Mart sur l’existant : Il va de soi qu’un DM qui met 20h à
tourner tous les jours n’est pas un DM de très bonne qualité. Mais en prenant un exemple
plus concret : un DM qui met 6h à tourner la nuit n’est pas forcément très optimisé non plus
car il encombre les bases de données qu’il requête pendant un long moment, tandis que
celles-ci sont sollicitées par d’autres processus. Le but de ce niveau d’optimisation est donc
d’accélérer la mise à jour quotidienne, hebdomadaire, ou mensuelle du DM. Elle permet
aussi d’assurer l’évolutivité de la partie ETL.
2. L’optimisation du Data Mart en lui-même : Puisqu’un Data Mart est avant tout conçu pour
subir des requêtes de plusieurs utilisateurs, il est important qu’il dégage une sensation de
rapidité lors de son utilisation. Pour cela, il est notamment possible de passer par des
techniques d’indexage et de pré-calcul des données comme les indicateurs.

30
Ce niveau d’optimisation requiert aussi une très bonne qualité de données (cf. partie
« Qualité de données »). Il est important de mettre en place un bon système de
dédoublonnage car une Unicité défaillante entraîne des indicateurs biaisés.
D’une manière générale plus les aspects techniques seront intégrés en amont du projet de création
du Data Mart, plus sa maintenance et son évolution seront aisées et moins coûteuses. Comme tout
projet d’industrialisation, l’arbitrage entre le coût d’investissement et le coût de maintenance sera
un élément clé de pérennité et de réussite.

31
HYPOTHESES ET CADRE DE L’ETUDE
Cette partie permet d’identifier les différentes hypothèses possibles en termes d’organisation,
d’environnement, de besoin, de résultat souhaité et d’outils utilisés.
L’entreprise
L’organisation dans laquelle on développe un Data Mart peut être de n’importe quel type. Par
exemple, on peut très bien vouloir le développer dans le secteur Bancaire comme dans le secteur de
l’Industrie. Le seul prérequis vient de la taille des données générées qui doit être grande (de l’ordre
de plusieurs centaines de Mo19
par jour). Un Data Mart dans une petite organisation sera
généralement trop coûteux par rapport au bénéfice dégagé : puisqu’il doit couvrir un secteur
d’activité spécifique, si ce secteur génère peu de données alors son utilité devient très limitée.
Si l’entreprise, petite ou grande, a un découpage par domaine d’activité bien défini et que ceux-ci
génèrent un grand nombre de données, alors il est recommandé de procéder à l’implémentation du
Data Mart. Ce DM doit être géré par une équipe d’aide à la décision spécialisée et non pas par les
acteurs métiers directement. C’est dans ces hypothèses là que nous nous basons.
Type de Data Mart
Le type de Data Mart peut être dépendant ou indépendant, ceci n’influe pas vraiment sur sa finalité.
La modification se fera au niveau de l’extraction et de la transformation. Un Data Mart dépendant,
qui tire ses sources d’un Data Warehouse, aura moins d’extractions et de transformations à faire
qu’un Data Mart indépendant.
Lors de la méthode proposée dans la section suivante, nous n’expliquons pas un cas en particulier.
Les deux types de Data Mart (dépendants et indépendants) dont identifiables dans notre méthode.
Taille et complexité des données
Le système de données initial doit avoir un certain niveau de complexité. On part du principe que le
Data Mart va interroger plusieurs tables dont la taille est de plusieurs Go20
. Ces tables suivent
généralement le modèle de bases de données relationnelles, et des fichiers plats peuvent s’y ajouter
(cf. partie « DataMarts dépendants et indépendants »). De ce fait, on peut soit se connecter à un
Data Warehouse existant, soit être indépendant.
En qualité de données il y a 3 niveaux d’hypothèses identifiables :
1. Indispensable car insolvable par la Data Mart : Complétude, Exactitude
2. Complexe à résoudre : Unicité (pas de champs discriminants), Intégrité
3. Facile à résoudre : Unicité (présence de champs discriminants), Conformité, Cohérence
19
« Mo » veut dire « Méga octects ». Les octets sont l’unité de mesure de la taille d’un élément informatique.
Ils déterminent ce que l’élément va réquisitionner comme mémoire (sur le disque dur par exemple). 1 Mo =
1 000 000 octets.
20
« Go » = « Giga octects » = 1 000 Mo.

32
Autrement dit, si les données que l’on extrait à l’aide du Data Mart ne sont ni complètes ni exactes, il
nous serait impossible de les corriger dans ce processus et elles influeraient négativement sur les
résultats. Généralement, les qualités qui sont toujours vérifiées sont l’exactitude, la complétude et
l’intégrité (cf partie « Qualité de données »).
Les qualités qui seront traitées dans notre étude sont l’unicité (doublons) et la conformité (format).
Environnement de développement
L’environnement se divise en deux types :
 L’environnement physique.
 Et l’environnement logique.
L’environnement physique qui accueil notre Data Mart doit être un serveur ayant une mémoire
suffisante pour la taille maximum du DM sous 1 an. Bien entendu, des accès de lecture, d’écriture et
d’exécution doivent être fournis par le service informatique pour ce serveur.
L’environnement logique quant à lui peut être polyvalent. Pour les données du Data Mart il est
possible de les conserver dans un SGBD ou dans un système d’environnement de dossiers. Pour ce
qui est des résultats (reportings, processus d’analyses, etc.) il est recommandé de les stocker dans un
environnement de dossiers, mais il est aussi possibles de les sauvegarder dans des bases de données
(ce qui donne des données « non structurées », cf. partie « La donnée »). Ces hypothèses-là sont
donc flexibles.
Dans notre cas on se basera exclusivement dans un système de gestion de dossiers (répertoires) avec
des bases de données mobiles (qui ne sont pas soumises à un SGBD type « MySQL », « SQL Server »,
etc.).
Outils utilisés
L’hypothèse maitresse de ce mémoire vient du fait que nous souhaitons développer un Data Mart
sans l’aide de logiciel spécialisé. C’est-à-dire que les outils qui sont utilisés ne sont pas des solutions
intégrées (par exemples des logiciels BI comme Talend, Cognos, etc.).
Dans notre expérience, nous utiliserons trois langages informatiques (UNIX, SQL, SAS) et un
logiciel (Excel) :
 Pour la gestion de l’environnement physique et le lancement automatique : UNIX.
 Pour les transferts de données : SQL.
 Pour le traitement des données : SAS, SQL.
 Pour la gestion des reportings : SAS, Excel.
Ces langages et logiciels fonctionnent très bien ensemble mais sont donnés à titre d’exemple. D’une
manière générale il faut que ceux qu’on choisit puissent remplir les 4 fonctions énoncés ci-dessus.

33
Résultats souhaités et accès aux données
Les résultats que doit fournir le Data Mart sont donnés par le métier du domaine d’activité. C’est
donc une phase de recueil de besoin qui déterminera les résultats souhaités.
Dans notre cas, nous faisons l’hypothèse que les besoins du métier sont d’obtenir des reportings
d’indicateurs et de listes de données, à une fréquence définie (notamment mensuelle). Les accès
aux bases de données du Data Mart seront réservés à l’équipe d’aide à la décision qui le développe
et l’utilise pour la génération des rapports.
Résumé
Les hypothèses sur lesquelles se base notre étude sont les suivantes :
 Entreprise : les secteurs d’activité sont clairement définis et ils produisent un grand nombre
de données quotidiennement.
 Gestion du Data Mart : faite par une équipe d’aide à la décision spécialisée.
 Type de Data Mart : indépendant puis dépendant.
 Taille des données : plusieurs Go de données sont utilisées.
 Modèle de données et qualité : les données sont relationnelles, et elles vérifient
l’exactitude, la complétude, la conformité et l’intégrité. Une table globale regroupant toutes
les données est créée pour faciliter les calculs.
 L’environnement physique : un serveur pouvant stocker plusieurs Go.
 L’environnement logique : système de répertoires avec bases de données mobiles.
 Outils utilisés : pas de logiciel avec solutions intégrées. Langages SQL, UNIX et SAS. Logiciel
Excel.
 Automatisation : réalisée car définie comme indispensable.
 Résultats souhaités : indicateurs et listes de données.
 Accès aux données : réservés à l’équipe d’aide à la décision qui gère le Data Mart. Diffusion
des résultats sous forme de reportings.

34
METHODE
Cette partie propose une méthode de résolution de la problématique. Elle permet d’expliquer ce qui
a été mis en œuvre de manière logique et pratique.
Première phase : plan d’action et recueil des besoins
Pour cette première phase nous partons du principe que l’autorisation de la hiérarchie a déjà été
obtenue.
Mise en place du plan d’action
Définition du périmètre
Le lancement du projet Data Mart commence par la définition du périmètre qu’il va couvrir au sein
du secteur d’activité. Il faut « faire passer le message » aux acteurs métiers et leur faire savoir qu’un
Data Mart va être créé. De ce fait, ils pourront dire s’ils souhaitent faire partie du projet ou non. Par
exemple, dans le domaine du crédit bancaire, le secteur d’activité « Recouvrement » peut être
subdivisé en plusieurs pôles : « recouvrement amiable », « recouvrement judiciaire »,
« surendettement », etc. Il s’agit de définir lesquels seront effectivement inclut dans le Data Mart
« recouvrement ». Bien entendu, il est toujours possible d’inclure de nouveaux pôles ultérieurement,
lorsque le Data Mart sera mis en production et évolutif, mais le but ici est de définir les limites
initiales du projet.
Pour mener à bien cette partie, des réunions collectives pour présenter le projet dans sa globalité ont
été réalisées auprès des équipes métiers. Nous nous sommes rendu compte que le métier était très
intéressé et qu’il introduisait d’ailleurs l’étape de « Recueil des besoins fonctionnels » pendant ces
réunions, impatient de connaître les fonctions et les résultats du Data Mart.
Définition des acteurs
Après le périmètre fonctionnel vient le périmètre organisationnel. Il faut définir quels seront les
acteurs qui participeront au projet en allant du chef de projet aux développeurs, en passant par les
acteurs métiers qui interviennent lors du recueil des besoins, de la préparation des reportings et de
la validation de la recette.
Dans notre cas, le projet a été construit et mené à l’aide d’un chef de projet, de deux développeurs,
de deux « recetteurs », et d’un grand nombre d’acteurs métiers.
Planning projet
Pour cette partie du projet il s’agit de définir le planning du projet, allant du recueil des besoins à la
mise en production. En fonction du périmètre et des acteurs actifs sur le projet, un diagramme de

35
Gantt21
a été créé. Il a bien évidemment été revu tout au long du projet en fonction des avancements
et des imprévus. L’ordre des tâches a suivi le plan de la « Méthode ».
Recueil des besoins fonctionnels et techniques
Recueil des besoins fonctionnels
Le recueil des besoins fonctionnels est une partie très importante du projet. Elle consiste à
déterminer ce dont le métier aura besoin à l’aide du Data Mart, et donc ce qui devra être développé.
Pour ce faire, nous avons passé des entretiens avec chaque manager de chaque pôle inclut dans le
périmètre, ainsi qu’avec la direction. La première réunion avec la direction nous a permis de guider
les autres réunions avec les opérationnels. Nous avons posé les questions et reçu les besoins
suivants :
 Questions à la direction :
o Quelle utilité doit remplir le Data Mart ?
o A quelle fréquence est souhaitée la mise à jour des données ?
 Besoins de la direction :
o Regrouper les données dans un référentiel unique
o Mise à jour à chaque début de mois pour avoir la « photo fin de mois » du mois passé
o Historique des mois passés par le stockage des anciennes bases
 Questions au métier :
o Que doit fournir le Data Mart ?
o Sous quelle forme ?
o Souhaitez-vous des accès directs aux données ?
 Besoins du métier :
o Des indicateurs de performances à chaque début de mois, sur l’activité du mois
passé. Ces indicateurs doivent pouvoir être fragmentés par axes d’analyse.
o Des listes de données spécifiques permettant d’avoir l’essentiel des détails de
l’activité du mois passé.
o Obtenir ces résultats sous forme de reportings via Excel, dont la forme sera discutée
ultérieurement.
o Certains accès aux données du Data Mart par des acteurs ayant des connaissances
techniques.
A la fin de chaque réunion il est important de faire un compte rendu (par exemple par mail) en
définissant un secrétaire de séance au début de la réunion et qui est chargé de prendre les notes. Un
tel procédé permet de récapituler et dater ce qui a été dit. L’information est alors retrouvable et
traçable.
Définition des outils techniques
Ici nous souhaitons connaître avec quels outils nous allons travailler. Sachant que notre projet ne se
base pas sur un logiciel avec solution intégrée, il faut choisir des langages de programmations et des
21
Un diagramme de Gantt est un type de diagramme qui permet de représenter, suivant un axe temporelle, les
étapes qui devront être réalisées. Ainsi, la liste des étapes est dressée et leur ordre d’exécution est spécifié.

Memoire_Julien_Diennet_20140905

Memoire_Julien_Diennet_20140905

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Memoire_Julien_Diennet_20140905

Similar a Memoire_Julien_Diennet_20140905 (20)

Memoire_Julien_Diennet_20140905