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é.

36
logiciels permettant de mettre en place la structure du Data Mart et de répondre aux besoins
énoncés.
Nous nous sommes posé les questions suivantes :
 Comment gérer l’environnement physique ?
 Comment mettre en place un lancement automatique ?
 Comment gérer le transfert de données ?
 Comment effectuer le traitement des données ?
 Comment générer et diffuser les reportings ?
Dans notre quotidien nous utilisons déjà des outils pour fournir des statistiques dont : un
environnement UNIX, des programmes SAS, le langage SQL, et le logiciel Microsoft Excel. Comme vu
dans la partie « Outils utilisés » des hypothèses, ces solutions permettent de répondre à nos attentes
en matière de fonctionnalités :
 L’environnement UNIX nous permet de créer des « scripts »22
et de gérer les dossiers et les
fichiers. Il permet aussi de programmer des lancements automatiques via un ordonnanceur.
 Les programmes SAS sont lancés par les scripts et permettent d’extraire les données des
bases sources, de les traiter, et de créer les nouvelles bases. Pour ce faire, il utilise le langage
SQL. Il permet aussi de générer les reportings sous format Excel à l’emplacement désiré.
 Finalement, Excel nous permet de créer les fichiers référentiels (cf. Figures 3 à 6), et aussi de
retraiter les reportings pour les mettre en forme.
Obtention des accès aux environnements
Une fois les outils sélectionnés, il faut obtenir les droits d’accès aux environnements et logiciels. Il
faut alors procéder aux étapes suivantes :
 Demande d’accès au serveur que nous manipulerons avec UNIX.
 Si on se base sur un SGBD pour la sauvegarde des données : demander l’accès en lecture et
en écriture à une base réservée pour y créer et gérer nos tables.
 Demander l’installation de SAS sur l’environnement.
 Demander les accès aux bases de données sources depuis l’environnement et les
programmes SAS.
 Demander l’installation du gestionnaire de reportings (ici Excel).
Dans notre cas, toutes ces demandes et installations sont déjà faites. D’une manière générale, pour
la mise en place de l’environnement, la réservation d’un espace serveur et les accès en lecture aux
bases de données, il faut justifier auprès de la direction informatique ces demandes.
Deuxième phase : Design
L’étape du Design est très importante car elle permet de modéliser et de normaliser le
fonctionnement théorique du Data Mart. Il s’agit d’abord de créer des versions « papiers » du futur
programme, qui expliquent son fonctionnement à l’aide de phrases, de référentiels et de schémas.
22
Dans notre cas, un script est un fichier exécutable sous UNIX qui regroupe un enchaînement d’action
effectuées à la suite. Cf. partie « Script »

37
Processus logique
Cette première partie du Design consiste à modéliser le fonctionnement du Data Mart dans son
ensemble (par exemple à l’aide d’un diagramme de processus). Il s’agit de schématiser les
enchaînements de fonctions et d’y apporter des descriptions globales. Le diagramme présenté en
Figure 3 résume l’enchaînement des différents processus avec les données utilisées en entrée et
celles générées en sortie, par le Data Mart. Il peut aussi servir pour expliquer rapidement le
fonctionnement à un nouvel arrivant ou lors d’une réunion.
Figure 3 : Diagramme sur le fonctionnement du Data Mart :
Ce diagramme nous montre le processus du Data Mart dans son ensemble. Il est important de tenir
les fichiers référentiels décrits par la suite à jour, car chaque tâche correspond à un fichier. Les
fichiers suivants offrent donc les explications complémentaires à ce diagramme.
Identifier les sources et modéliser les extractions
Puisque la première étape du data Mart est d’extraire les données de plusieurs bases de données et
tables, il faut commencer par identifier les sources qui seront requêtées. Dans notre cas, ces sources
ont changé durant le projet : au départ nous nous sommes basés dans le cadre d’un Data Mart
indépendant (qui tire ses sources directement des bases de données opérationnelles), alors
qu’actuellement le Data Mart est dépendant (il tire ses données du nouveau Data Warehouse). De ce
fait nous avons dû réaliser à deux reprises cette tâche. Dans les deux cas, pour la mener à bien, nous
avons créé un fichier sous forme de tableau (voir Figure 4) qui reprend les informations suivantes :
nom de l’extraction, nom de la table créée, serveur de données, nom de la base, nom de la table
source, nom du champ, condition sur le champ, jointures de l’extraction. Par exemple, le fichier créé
peut ressembler à la capture d’écran suivante :

38
Figure 4 : Fichier référentiel des extractions
On remarque la condition « dtvente = ‘mois_actu’ » qui modélise le fait que nous ne voulons que les
ventes du mois passé lorsque l’extraction est lancé en tout début de mois. Les ventes des mois
précédents sont conservées dans les tables des extractions du mois précédent.
Avec ce type de modélisation, il est facile et rapide de comprendre le fonctionnement des extractions
qui seront faites. Le fichier sert aussi de référentiel pour avoir une vue d’ensemble de cette partie
avant de se lancer dans la programmation. Finalement, lors du développement il sera facile
d’implémenter le code correspondant à cette modélisation en SQL car la colonne « Champs »
correspond aux attributs de la sélection (SELECT), la colonne « Table source » correspond aux
attributs de la source (FROM), et les colonnes « Conditions » et « Jointures requises » correspondent
aux attributs de la condition (WHERE).
Modéliser les transformations
Cette partie détermine en quoi seront transformées les données. Il s’agit de modéliser les parties
« transformation » de l’ETL. Une façon fonctionnelle consiste à renseigner les champs suivants :
calculs sur les champs récupérés, nom des nouveaux champs correspondants, leurs métadonnées
(format, longueur, label), et la table cible. La Figure 5 représente un référentiel des transformations :
Figure 5 : Fichier référentiel des transformations :

39
Comme pour la phase précédente, ce type de modélisation offre une vision d’ensemble du
fonctionnement de la partie transformation. Dans notre exemple, on remarque plusieurs choses :
 « nb6/100 » car on fait l’hypothèse que le prix est de base en centimes dans les tables
sources, on le retraite ainsi pour obtenir un réel sur 9 chiffres, dont 2 pour les centimes (réel
9.2). Exemple 142325 se transforme en 1 423,25. La devise n’est pas précisée par contre.
 « dtvente » est divisé en deux variables cibles « date_vente » et « time_vente ». La première
récupère la date au format « jour/mois/année » et la deuxième récupère l’heure au format
« 23:59:59 » « pour 23h, 59min et 59sec.). On verra dans la partie « Développement »
comment cela peut être fait techniquement.
 Certaines longueurs de caractères ont des « [ ] ». Ceci signifie que la longueur est variable : le
champ peut récupérer n’importe quelle chaine de caractères d’une longueur inférieure ou
égale à la valeur affichée entre crochets. Si la longueur dépasse, la chaîne est tronquée.
 Les nouveaux champs ont des noms plus parlants et leurs labels sont compréhensibles pour
le métier.

40
Modéliser les liaisons et le chargement
Ici, il faut se poser les questions suivantes :
 Quel modèle utiliser pour mes données finales ?
 Y a-t-il des champs qui ne seront finalement pas gardés ? (la réponse à cette question est
généralement négative car les données utiles ont déjà été retenues à l’étape d’identification
des sources.)
 En fonction du modèle retenu :
o Quelles seront nos tables finales ?
o Avons-nous une table de référence ? (similaire à la table de faits dans un schéma en
étoile)
o Quelles sont les jointures nécessaires ?
o Quel est l’emplacement de sauvegarde des données finales ?
Dans notre cas, nous allons regrouper toutes les données dans une table globale qui servira de
référentiel unique pour la suite et nous ne sauvegardons pas les tables « temp_produits » et
« temp_ventes » dans un souci de mémoire. Notre table de référence sur laquelle se base les
jointures est la table des ventes :
Figure 6 : Fichier référentiel du chargement :
Ce choix de table globale permet de ne sauvegarder qu’une seule « grosse table » regroupant toutes
les informations. Les jointures sont donc déjà faites et ceci permet d’accélérer les traitements pour la
suite, comme le calcul des indicateurs. Dans le cas où le processus de chargement remplis plusieurs
tables distinctes (par exemple les tables produits et ventes, sans les rassembler en une table globale),
il faut effectuer les liaisons entre les tables avant le calcul des indicateurs car les champs «
nom_produit » et « qte_vendue » ne se trouveront pas dans la même table. Cependant, ce procédé
ralenti grandement le processus de calcul des indicateurs.
Méthodes de calculs des indicateurs
Cette quatrième partie du Design permet de détailler un point important de notre Data Mart : les
indicateurs. Il s’agit ici de renseigner la liste et les méthodes de calculs des indicateurs. Pour ce faire il
faut regrouper les informations suivantes : le nom de l’indicateur, sa description, son type, sa règle
de calcul, sa méthode d’agrégation et finalement son nom une fois agrégé.
Pour cela, il faut aussi définir une nomenclature qui devra être utilisée pour tous les indicateurs. Par
exemple les indicateurs booléens agrégés par une somme auront un nom commençant par « nbr_ »,
ou les indicateurs réels agrégés par une moyenne auront un nom commençant par « avg_ » (pour
« average », en anglais). On peut alors obtenir le fichier suivant :

41
Figure 7 : Fichier référentiel des indicateurs :
De ce fait, nous pouvons créer la liste des indicateurs qui devront être implémentés dans le
traitement du Data Mart. Les règles de calcul nous sont généralement données par le métier. Par
exemple pour les ventes, certains produits ne sont pas vraiment vendus car ils sont issus de tests
informatiques, le nom du produit vaut alors ‘TEST VENTE’, ou encore des ventes peuvent être
annulées et ceci se modélise par une quantité vendue à 0. Pour obtenir les ventes effectives, le
métier considère donc qu’il ne faut pas prendre en compte ces deux éléments.
Finalement, on rappelle qu’on se base dans le cadre d’une table globale, où tous les champs sont
présents. Dans ce cadre, les indicateurs sont sauvegardés à l’intérieur de la table globale, en tant que
champs supplémentaires, dont la valeur change selon l’observation (en suivant la règle de calcul).
Créer les axes d’analyse
Les axes d’analyse sont les dimensions à travers lesquelles seront fragmentés les indicateurs. Dans
cette partie le but est de recenser tous les axes d’analyse qui pourront être utiles pour le métier. Un
axe d’analyse peut se diviser en plusieurs niveaux, ce qui offre un découpage hiérarchique. Comme
pour les indicateurs, les axes d’analyse sont soumis à des règles et sont sauvegardés sous forme de
champs dans la table globale. Les axes d’analyse sont souvent donnés par le métier. Un exemple de
l’axe d’analyse géographique des magasins est donné dans la capture d’écran suivante :
Figure 8 : Exemple d’un axe d’analyse :

42
Ici il faut comprendre que les niveaux 2 et 3 de l’axe sont obtenus par des champs présents dans la
table globale. Plus généralement, le niveau le plus élevé (détail le plus fin) est toujours donné par un
champ, et les autres sont calculés en fonction. Il faut aussi remarquer que des calculs sont possibles
pour faciliter la définition de l’axe d’analyse. Par exemple pour le champ ‘cp_mag’ ce sont que les
deux premiers chiffres qui nous intéressent pour définir la valeur du niveau « dep »
(substr(‘75014’,1,2)23
devient ‘75’, etc.). Une fois le niveau 2 calculé, le niveau 1 peut alors l’être à
son tour : si « dep » appartient à la liste des départements d’Île-de-France, alors la région vaut ‘Ile-
de-France’. On peut donc interpréter l’axe d’analyse « axe_geo_mag » comme la dimension : ville ->
département -> région.
Un bon moyen de créer le référentiel des axes d’analyse est de créer un fichier type Tableur
(exemple Excel) avec pour chaque axe d’analyse une feuille, qui contient sa définition sous forme de
tableau (cf. Figure 8 précédente). Pour chaque axe, il faut se poser les questions : quel est le nombre
de niveaux que le métier considère ? Quelles sont les règles pour calculer ces niveaux ? À partir de
quelle donnée de base ?
Préparer les reportings
Les reportings sont les résultats attendus du Data Mart. C’est ce qui va être diffusé aux équipes
métiers selon leurs besoins. Comme vu dans la partie théorique, ils peuvent être de beaucoup de
formes différentes, mais dans notre cas ils seront diffusés via Excel. L’outil SAS permet de sortir les
résultats sous format Excel, via des fonctions spécifiques, et Excel permet de mettre en forme le
reporting final selon un template convenu avec le métier. Dans cette partie, il est donc important de
rappeler les points suivants :
 Combien avons-nous de reportings à fournir ?
 Pour quelles équipes ?
 Par quel moyen de diffusion ? (par mail ? par dépôt sur un serveur de partage ?)
 Que doit-il contenir ?
o Liste de données
o Indicateurs et Axes d’analyse
o Graphiques
o Compléments statistiques
 Il y aura-t-il un retraitement ? Manuel, automatique ou aucun ?
Les réponses aux questions complémentaires auxquelles nous avons déjà répondu dans la partie
hypothèses sont les suivantes :
 Quelle fréquence ? (hebdomadaire ? mensuelle ?) Ici nous nous plaçons dans un cadre
mensuelle car la mise à jour des données est faite mensuellement.
 Quel format ? Ici nous utilisons le format Excel.
Ces informations peuvent facilement se regrouper dans un fichier référentiel qui définit les
reportings diffusés chaque mois à partir du Data Mart.
23
La fonction « substr() » disponible en SQL et SAS permet de récupérer une sous-chaîne de caractères (« sub-
string »). Nomenclature : substr(chaîne source, position du premier caractère à récupérer, sur combien de
caractères ?).

43
De plus, lorsque les reportings demandent un retraitement (manuel ou automatique), il est
important de référencer ces manipulations dans un mode opératoire, par exemple : « Pour le
reporting 1, copier les données vers tel template, puis lancer telle macro, et l’envoyer à Alice
Lécheveux et Sandra Housse ».
Design physique
Finalement, la dernière partie du Design consiste à modéliser la structure physique qui contiendra
nos programmes, nos données et nos résultats. Pour cela, il est possible de créer un diagramme style
organigramme qui référence les dossiers et sous-dossiers de notre arborescence :
Figure 9 : Diagramme sur la structure physique de l’environnement :
Nous rappelons que nous nous basons dans un environnement type répertoires (sous UNIX) qui
permet de sauvegarder dans chaque dossier (AXES_ANALYSE, FONCTIONS, etc.) des éléments
spécifiques du Data Mart, que ce soit une table de données, un programme SAS ou un résultat Excel.
Un fichier descriptif doit accompagner ce diagramme pour expliquer ce que contiendra chaque
répertoire. Par exemple dans notre cas, le répertoire
« /serv123/SAD/DATAMART/PROGRAMMES/EXTRACTIONS » se chargera de regrouper tous les
programmes d’extraction sous la forme [nom_extraction].sas, le répertoire
« /serv123/SAD/DATAMART/DONNEES/[MOIS] » contiendra la table_globale selon le mois de sa
création, etc.

44
Troisième phase : Construction, spécifications détaillées et cahier de
recette
Cette phase permet de construire le « squelette » du processus, c’est à dire : les fichiers qu’il va
utiliser (programmes et reportings) et l’environnement dans lequel il va opérer. Une documentation
des spécifications détaillées doit aussi être faite en parallèle ainsi qu’un cahier de recettes qui
permettra de tester chaque fonction (cf. partie « Cinquième phase : Recette »).
Construction de l’environnement
La première partie est la construction de l’environnement. Comme vu dans le « Design physique », il
s’agit ici de créer tous les dossiers et sous-dossiers qui contiendront les éléments du Data Mart (cf.
Figure 9).
En UNIX il est simple de générer l’arborescence à l’aide de la commande « mkdir [nom_répertoire] »
qui doit être utilisée séquentiellement pour tous les répertoires et sous-répertoires qui seront créés.
Les dossiers (…)/[MOIS] sont créés dynamiquement (cf. partie suivante « Script »).
Création des fichiers programmes et reportings
Programmes
Une fois l’environnement créé, il faut créer tous les fichiers programmes et leurs fonctions (sans pour
autant les développer pour le moment). Pour cela, il faut se poser les questions suivantes :
 Quels sont les programmes principaux dont je vais avoir besoin ?
 Comment les découper en sous-programme pour faciliter la lecture et le développement, et
favoriser l’évolutivité.
 Quelles seront les fonctions associées à mes programmes ? (Insérer un commentaire pour
chaque fonction pour décrire son utilité.)
 Quelles sont leurs typologies (variables en entrée, variables en sortie) ?
 Quels seront finalement mes enchaînements de programmes et de fonctions ?
Par exemple, nous savons que nous aurons besoin d’un programme qui gère les extractions
(première partie de notre Data Mart). Pour ce faire il est possible de créer plusieurs programmes
pour chaque extractions « [nom_extraction].sas » qui se chargeront de lancer la requête sql associée
à l’extraction, et un macro-programme « lancer_extractions.sas » qui va lancer toutes les extractions
séquentiellement selon la liste qu’on lui aura renseigné dans une fonction. Enfin, ce programme
« lancer_extractions.sas » se trouvera appelé par le programme mère « prog_general.sas » qui va
exécuter à la suite tous les macro-programmes liés à chaque fonction principale du Data Mart
(Transformation, Chargement, Indicateurs, etc.).
Lorsque des modifications surviendront par exemple pour implémenter un nouveau périmètre, de
nouveaux indicateurs, etc., il sera ainsi clair et intuitif d’aller rajouter des petits programmes
connectés aux macro-programmes.
Tout ceci doit être documenté dans la partie suivante « Documentation détaillée des futurs
programmes ».

45
Reportings
Un élément qui peut être fait en parallèle à la construction des programmes et fonctions est la
création des Reportings. Généralement, ce n’est pas le même acteur de l’équipe projet qui réalise ce
travail, mais il n’en reste pas moins en relation active avec les développeurs pour connaître
exactement la forme des données en sorties. Une fois connue, il est possible de développer les
templates de reportings qui serviront à accueillir les sorties Excel données par les procédures SAS.
Dans notre cas, un template de reporting est un fichier Excel qui prend en entrée des données sur
une page et qui s’en sert pour remplir un tableau esthétique, associé à des graphiques et statistiques,
sur une autre page. Le tableau a généralement été créé par les acteurs métiers, c’est eux qui nous
fournissent la mise en forme qu’ils souhaitent recevoir et les analyses qui iront avec. Il s’agit donc ici
de faire l’intermédiaire entre ce que les développeurs créés dans le fond et ce que les acteurs
attendent dans la forme.
Documentation détaillée des futurs programmes
Cette partie concerne la documentation écrite pour détailler le fonctionnement des programmes et
fonctions.
Comme dans tout projet d’une manière générale, il faut rédiger les spécifications. En informatique,
et donc ici en Business Intelligence, il faut différencier les spécifications fonctionnelles des
spécifications détaillées. Les spécifications fonctionnelles ont déjà été rédigées d’une certaine
manière lors de la phase de Design : tous les processus ont été expliqués fonctionnellement. Tandis
que les spécifications détaillées doivent être rédigées lors de la création des programmes et des
fonctions, et revues si besoin lors du développement.
Les spécifications détaillées servent de référentiel technique sur le fonctionnement du processus. Ce
document répertorie la liste des programmes, des fonctions, de leurs typologies et des liaisons
processus à un autre. Dans notre cas, il a été rédigé sous format texte, avec une partie pour chaque
programme et des sous parties pour les sous programmes (exemple « 2.1 lancer_extraction » et
« 2.1.[1] [nom_extraction] »). Une description du fonctionnement du programme est faite et ensuite
la liste des fonctions qu’il incorpore est énoncée sous forme d’un tableau, avec des informations sur
les variables en entrées, son fonctionnement, et les variables en sorties.
Cahier de recette
Finalement, le cahier de recette doit aussi être rédigé en parallèle : il permet d’avoir une procédure
complète à suivre pour la phase de recette lorsqu’il s’agira de tester toutes les fonctions du
programme mais aussi de valider les résultats obtenus avec le métier.
Le cahier de recette met en place une stratégie pour la recette fonctionnelle. Dans notre cas, deux
résultats devaient être validés avec le métier : les listes de données et les reportings d’indicateurs. Il
s’agit donc ici de se baser sur la liste des besoins fonctionnelles énoncés par les acteurs métiers, et
d’en faire une liste de recette à complèter.

46
Quatrième phase : Développement
Script
Un « script » est un diminutif pour parler des programmes qui sont écrits en « langage de script ».
Des langages de script connus sont par exemple : JavaScript, PHP, Python, etc. Mais aussi, et surtout
dans notre cas, les langages de script sont utilisés sous UNIX (exemple : bash, sh, ksh, etc.). C’est avec
ces derniers que la solution a été développée. Ils permettent de regrouper une série de commandes
reconnues par l’environnement UNIX et de les exécuter rapidement. Ils peuvent ainsi lancer des
programmes SAS. Dans notre cas, un script peut exécuter les actions suivantes (cf. ANNEXE 1) :
1. Récupérer la date du jour via une fonction prédéfinie
2. Créer une variable qui contient le mois actuel au format AAAAMM. Exemple 201408 pour
août 2014
3. Récupérer dans des variables les adresses des répertoires utiles. Exemple
« /serv123/SAD/DATAMART/DONNEES »
4. Créer les répertoires du mois dans DONNEES et SORTIES avec la commande « mkdir
(…)/[MOIS] »
5. Exécuter le programme SAS principal et sauvegarder sa log, datée du jour.
6. Informer que le programme est terminé
Lorsque le script est créé, un simple appel de celui-ci dans un terminal de commande UNIX permet
de lancer toutes les actions qui y sont contenues.
Un aspect très important des scripts vient de leur automatisation (lancement automatique depuis un
« ordonnanceur »). Il est détaillé dans la partie « Automatisation ».
SAS
SAS est un langage de programmation qui permet le traitement de données rapide et automatique. Il
permet ainsi de gérer des bases de données, de faire des statistiques et de générer des reportings, de
manière dynamique et intuitive pour un informaticien grâce à son langage « macro » (cf. partie
« Macros variables et macros fonctions »).
Inclusions de sous-programmes
Les inclusions de sous-programmes permettent d’imbriquer plusieurs programmes les uns à la suite
des autres de manière hiérarchique. On parle ainsi de « modularité des programmes ». De ce fait, au
lieu de tout développer dans un seul programme, on peut fragmenter le code en plusieurs morceaux
pour instaurer une cohérence dans nos programmes et ainsi obtenir une facilité de lecture et
d’écriture (cf. partie « Optimisation pour la lecture et l’écriture »). Cette facilité se retrouve aussi
dans la capacité d’évolution du programme (cf. partie « Sixième phase : Maintenance et
évolutions »).
Pour ce faire, il faut utiliser la ligne de code suivante : « %include ‘’[nom_programme].sas’’; ». Par
exemple, au début du programme « prog_général.sas », il est possible d’inclure le programme
« lancer_extractions.sas » et ce dernier va à son tour inclure plusieurs sous-programmes
« [nom_extraction].sas ». L’exécution va alors commencer depuis le premier programme, puis passer
au sous-programme suivant et commencer par le niveau le plus fin puis remonter, et ainsi de suite

47
dans l’ordre d’appel des « include ». La figure suivante montre par exemple l’exécution de notre
programme avec l’ordre numéroté :
Figure 10 : Exemple de diagramme d’exécutions encapsulées des programmes :
On remarque donc les aller-retours entre les programmes et leurs sous-programmes : quand un
sous-programme a fini son exécution, il revient au programme parent et poursuit l’exécution, et ainsi
de suite jusqu’à finir l’exécution totale du programme global (exécution « N »).
Macros variables et macros fonctions
Les macros variables sont des variables qui peuvent être utilisées à n’importe quel endroit dans
n’importe quel programme une fois qu’elles ont été créées lors d’une exécution. D’après l’ANNEXE
2, si une macro variable « liste_indics » est créée dans le programme « chargement.sas », alors elle
sera réutilisable par le programme « axes_analyse.sas ». Cet élément permet de n’effectuer qu’une
seule fois certains traitements pour pouvoir les réutiliser par la suite en tant que référentiels (la liste
des tables issues de l’extraction doit rester la même pendant la transformation et le chargement par
exemple). De plus, elles sont dynamiques car elles ne requièrent pas de gestion de la mémoire, et
n’ont pas de type défini ce qui permet de leur attribuer n’importe quelle valeur selon la situation
(chaîne de caractères, entier, booléen, etc.). Elles peuvent être utilisées dans le nom d’une table, le
nom d’un champ, le nom d’une fonction, et beaucoup d’autres cas, ce qui les rend simples et
« légères » à utiliser. Les macros variables s’initialisent avec le code « %LET [variable]=[valeur] » et
s’utilisent avec le signe « & » et un « . » à la fin (exemple : « &liste_indics. »).
Les « macros fonctions » sont les fonctions que nous créons nous même pour automatiser les
traitements (cf. partie « Automatisation »). De même que pour les macros variables, les macros
fonctions peuvent être utilisées à n’importe quel endroit d’un programme à partir du moment où
elles sont définies. Les macros fonctions se définissent par le code « %MACRO [nom_macro]; (…);
%MEND [nom_macro]; » et elles s’utilisent avec le signe « % » (exemple : « %indicateurs »).
Dans notre cas, nous avons utilisé un programme « initialiser_macro_variables.sas » au tout début du
processus qui permet d’initialiser toutes les macros variables importantes pour la suite. D’autres sont

48
bien évidemment créées et modifiées au fur et à mesure de l’exécution en fonction des données
qu’on obtient, etc.
Etapes « DATA »
Les étapes DATA sont l’essence même d’un programme SAS. C’est à travers elles qu’il est possible de
générer des tables et de créer, modifier ou supprimer leurs données. Tous les traitements qui y
sont incorporés sont exécutés pour chaque ligne de la table. Les étapes DATA permettent donc
d’automatiser en quelques lignes de code un grand nombre d’opérations qu’il faudrait effectuer sur
chaque ligne d’une table de données.
Dans notre cas, imaginons que nous voulons développer l’étape DATA qui créée la table_globale +
indicateurs à partir de la table_globale (cf. Figure 3). Il faut alors exécuter les opérations suivantes :
 Création de la table « table_globale_indics »
 A partir de la « table_globale »
 Pour chaque ligne (automatique) :
o Pour chaque indicateur
 Appliquer la règle de calcul de l’indicateur.
La première fois, la colonne portant le nom de l’indicateur est
automatiquement créée dans la table. A chaque fois, la valeur de l’indicateur
est appliquée.
o Fin « pour chaque indicateur »
 Fin « pour chaque ligne »
 Fin étape DATA.
Le code correspondant à cette exécution est l’ANNEXE 2 dans la partie « Annexes ». On peut
remarquer l’utilisation des macros variables, des macros fonctions et des boucles pour automatiser
les traitements à l’intérieur de l’étape DATA (cf. partie « Automatisation »). Il ne faut pas tenir
compte de l’ordre d’exécution qui est incorrect car l’étape DATA est censée se trouver après la
définition des macros fonctions. Il est voulu ici de montrer l’ordre d’enchainement des traitements à
l’intérieur des boucles.
De plus, l’étape DATA de SAS est très rapide puisque par exemple pour une table de 1 000 000 lignes,
l’ajout du champ correspondant à l’indicateur, ainsi que son remplissage pour chaque ligne selon la
règle conditionnelle, se font en une ou deux minutes.
Procédures
Les procédures (PROC) sont les fonctions prédéfinies par SAS. Elles s’utilisent facilement à l’aide de la
documentation en ligne24
. Les quatre procédures les plus utilisées dans notre cas sont les suivantes :
 PROC SQL : Permet de réaliser une requête SQL. Elle peut porter sur une base de données
d’un serveur distant à l’aide d’une connexion connue (instruction « CONNECT TO (…) »), ou
directement sur une base de données SAS. Elle est donc polyvalente quant au type de sa
source. Elle supporte aussi l’utilisation des macros variables ce qui rend la requête
dynamique.
24
Lien : http://support.sas.com/documentation/

49
Exemple :
PROC SQL;
connect to oracle as accora (user=&user. password=&pass. path=&path.);
CREATE TABLE lib.vente_&dtjour.
AS select * from connection to accora
(
SELECT *
FROM &source..ventes
);
disconnect from accora;
QUIT;
 PROC SORT : Permet de trier une table SAS selon un ou plusieurs champs, et de supprimer
les doublons selon un ou plusieurs champs discriminants.
Exemple :
PROC SORT DATA=lib.vente_&dtjour. NODUPKEY;
BY ref_vente no_vente;
RUN;
 PROC MEANS : Permet de sortir les statistiques basiques de certains champs d’une table
(moyenne, médiane, écart-type, etc.).
 PROC PRINT : Permet d’afficher une table sous forme de tableau. Des options comme
« LABEL » permettent d’utiliser les labels des variables pour l’affichage.
Exemple :
PROC PRINT DATA=lib.vente_&dtjour. LABEL;
RUN;
Dans nos programmes, la PROC SQL est utilisée pour les extractions des bases de données sources et
pour les agrégations des indicateurs suivant les axes d’analyse (avec l’instruction « group by » d’SQL).
La PROC SORT est utilisée à plusieurs endroits pour, par exemple, trier une table avant une jointure
(cf. partie « Optimisation »), ou supprimer les doublons des tables afin d’améliorer la qualité de
donnée et supprimer les biais des indicateurs. Enfin, les PROC MEANS et PROC PRINT sont utilisées
pour les reportings.
Reportings
Finalement, la dernière fonctionnalité essentielle qu’offre SAS pour notre Data Mart est la génération
des reportings. Cette opération est effectuée tout à la fin du processus global par l’utilisation d’une
fonction spécifique : « ODS TAGSETS.EXCELXP ». C’est une alternative à la fonction d’exportation
classique de SAS (PROC EXPORT) qui permet de sortir les résultats directement sous format Excel.
La méthode qui est utilisée dans notre étude est la « PROC PRINT » à l’intérieur de la fonction « ODS
TAGSETS.EXCELXP » pour « imprimer » les résultats dans le fichier Excel. Il est aussi possible de
renseigner l’emplacement d’exportation de ce fichier résultat. Ici, tous nos fichiers résultats du mois
se trouvent dans le répertoire « /serv123/SAD/DATAMART/SORTIES/[MOIS] ».

50
Automatisation
Comme nous l’avons vu dans la partie théorique et tout au long de notre démarche, l’automatisation
est sans doute l’aspect le plus important du Data Mart.
Le fait même d’utiliser l’informatique pour générer le Data Mart créer une certaine « base
automatique ». Mais en plus de cette base, il faut chercher à automatiser au maximum chaque
opération de chaque programme, et le programme dans son ensemble. Pour cela, beaucoup de
notions ont déjà été introduites dans les parties précédentes (exemples d’utilisation des scripts,
macros variables, macros fonctions, procédures, etc.). Cependant, d’une manière générale, pour
tendre vers une automatisation des programmes il faut maximiser les points suivants :
 Utiliser des macros variables et des listes, calculées dynamiquement.
 Utiliser des macros fonctions qui implémentent des boucles de traitements.
 Gérer tous les cas possibles de chaque opération à l’aide de conditions (« IF … THEN …
ELSE »).
 Imbriquer les programmes, les boucles et les conditions.
En plus de l’automatisation des programmes et des traitements de données, il faut aussi
automatiser les scripts qui permettent de lancer le processus. Pour cela il suffit d’utiliser un
« ordonnanceur » dans lequel on ajoute une ligne de commande mentionnant notre script et les
horaires/dates auxquelles nous souhaitons qu’il tourne. Le programme peut alors se lancer
automatiquement et tous les résultats peuvent être disponibles dès la première journée du mois.
Dans notre cas, l’ordonnanceur n’est pas encore utilisé.
Finalement, l’automatisation passe aussi par les reportings. Bien que la production des premières
versions de reportings soit déjà automatisée via les fonctions SAS, il faut tout de même automatiser
les parties de mise en forme, de création des graphiques et des analyses. Il s’agit ici de créer des
templates Excel contenant des formules et des « macros » programmées en « VBA » qui permettent
de réaliser automatiquement toutes ces actions.
Optimisation
L’optimisation d’un programme peut se diviser en deux parties : une concernant la lecture et
l’écriture (qui n’a généralement aucun impact sur la rapidité d’exécution) et l’autre concernant
l’exécution.
Optimisation pour la lecture et l’écriture
L’optimisation pour la lecture doit toujours se faire à partir de l’idée suivante : si demain je ne suis
plus là, est-ce que mon remplaçant sera capable de comprendre rapidement le programme et de le
faire évoluer si besoin ? Lorsqu’un programmeur commence à développer, il a rarement le réflexe de
penser de la sorte, alors qu’il est primordial de le faire.
La solution à ce problème est d’apporter des explications directement dans le code, à chaque
fonction et chaque traitement qui est effectué. Il s’agit donc de « commenter » le programme. Par
exemple, les ANNEXE 1 et ANNEXE 2 sont commentés (« # (…) » pour le script et « /* (…) */ » pour le
programme sas). De plus, un autre moyen facilitant la lecture et la compréhension du programme est
« l’indentation » : Toute nouvelle fonction ou toute nouvelle boucle implique une tabulation
supplémentaire dans l’écriture, pour modéliser les différents niveaux d’exécutions (encore une fois,
les annexes en montre un exemple).

51
Dans un deuxième temps, l’optimisation pour l’écriture doit se faire en se posant la question
suivante : qu’est-ce qui peut être condensé ou centralisé pour permettre une écriture rapide et à
moins d’endroits possibles ? Ce principe reprend les idées d’automatisation en passant par des
variables, des boucles et des fonctions. Ces utilisations permettent de condenser le code (macros
variables et boucles) et centraliser les traitements (fonctions). En s’aidant à nouveau de l’ANNEXE 2,
si par exemple la macro variable « liste_indics » n’est pas initialisée au tout début du programme et
qu’elle doit être écrite à la main à chaque utilisation des indicateurs, alors ceci devient fastidieux et
source d’erreurs pour le développeur. L’optimisation pour l’écriture est donc le moyen même
d’obtenir une bonne automatisation et, par la suite, d’obtenir une bonne optimisation pour
l’exécution.
Optimisation pour l’exécution
Comme vu dans la partie précédente, l’optimisation de l’exécution passe par l’automatisation des
processus et une bonne écriture du programme. Elle sert avant tout à accélérer l’exécution et
garantir des résultats corrects, mais aussi à garder une certaine stabilité dans les traitements et à
assurer les possibilités d’évolutions. L’évolutivité étant vu dans la partie « Sixième phase :
Maintenance et évolutions », les actions suivantes ont été réalisées pour les 3 premiers objectifs :
- Rapide : Pour connaître le temps d’exécution d’un programme SAS il suffit de lire sa log. Il est décrit
alors la durée de chaque étape DATA et chaque procédure (PROC). Les requêtes d’extractions sont
généralement l’opération qui prend le plus de temps dans toute l’exécution et elles ne peuvent pas
être accélérées. Dans ce cas, il faut donc se focaliser sur le reste du processus :
 Des PROC SORT sont utilisées avant les jointures de plusieurs tables (notamment pour le
chargement dans la table_globale) pour trier chaque table suivant l’id qui sera utilisé pour la
jointure. De ce fait, SAS va reconnaître que les tables ont déjà été triées et va entamer une
« jointure non redondante »25
. Le principe est de sauvegarder en mémoire la dernière
observation sur laquelle on a pu effectuer une jointure, et recommencer de cette dernière
pour les jointures suivantes. La figure suivante montre un exemple de ce cas :
Figure 11 : Exemple de jointure « non redondante » :
On remarque alors les étapes suivantes :
1. L’id 1 trouve son homologue (1) dans la table 2 pour la jointure.
2. L’id 2 cherche son homologue à partir du dernier id trouvé (1) dans toute la table 2
mais ne le trouve pas.
3. L’id 3 pareil.
4. L’id 4 cherche son homologue à partir du dernier id trouvé (1) dans toute la table 2 et
le trouve à la deuxième ligne parcourue (4).
25
Lien : http://support.sas.com/onlinedoc/913/docMainpage.jsp

52
5. L’id 5 cherche son homologue à partir du dernier id trouvé (4) dans toute la table 2 et
le trouve à la deuxième ligne parcourue (5). Il n’aura donc parcourue que deux lignes
au lieu de trois pour effectuer la jointure.
Cependant, il faut que cette manipulation (deux PROC SORT sur deux tables pour ensuite les
joindre via une étape DATA) offre suffisamment de bénéfices par rapport au temps
d’exécutions des PROC SORT. Sinon, la jointure seule reste préférable.
 Il existe des options pour la PROC SORT qui permettent d’accélérer leurs traitements et donc
de profiter d’une meilleure rapidité d’exécution lorsqu’elles sont exécutées
indépendamment du reste ou en combinaison avec d’autres fonctions (comme vu
précédemment).
 Une optimisation de la rapidité a aussi été effectuée au niveau de la suppression des
doublons une fois les indicateurs créés. Ce qui était fait de base était d’exécuter une PROC
SORT (avec l’option « nodupkey » qui supprime les doublons) à chaque création d’indicateur
sur l’id de la table plus les variables qui servaient à créer l’indicateurs. Le traitement a été
changé pour n’exécuter qu’une seule fois la suppression de doublons à partir de l’id de la
table et de tous les champs indicateurs à la fin de la création de ces derniers.
- Correct : Le dernier point énoncé dans la « rapidité » est lié à la méthode qui a été employée pour
obtenir des résultats corrects. La nouvelle méthode employée dans le dédoublonnage des
indicateurs a permis de garder des observations qui étaient supprimé par l’ancienne méthode, mais
qui n’étaient en fait pas réellement des doublons d’un point de vue métier. De ce fait, les indicateurs
sont devenus plus représentatifs de la réalité. Par exemple, le nombre de vente_eff sur un mois est
passé de 3000 à 3100 car dorénavant il comptabilise bien certains cas ambiües. De plus, ceci a permis
de sortir la liste des ventes différentes et le métier a pu se rendre compte de certains
disfonctionnements au niveau de leurs applications etc.
- Stable : L’automatisation est une sorte d’optimisation qui assure d’avoir des traitements stables
d’une fois sur l’autre. Puisque l’humain n’intervient pas, chaque processus est exécuté
scrupuleusement de la même manière à chaque lancement du Data Mart. L’optimisation pour rendre
l’exécution stable a donc été faite en harmonie avec l’automatisation et l’optimisation pour l’écriture
(cf. parties « Automatisation » et « Optimisation pour la lecture et l’écriture »).
Cinquième phase : Recette
Comme vu dans la partie théorique, la recette permet de tester et valider le fonctionnement du
programme (recette technique) et de valider les résultats qu’on obtient avec le métier (recette
fonctionnelle). Cette phase doit être commencée en même temps que la phase de développement,
notamment pour la recette technique.
Recette technique
La recette technique a été réalisée de manière assez classique à l’aide des log. Ces fichiers décrivent
toute l’exécution du programme en allant de l’affectation des variables à la génération des
reportings, en passant par la création des tables et leurs contenus (taille, champs, etc.). Par exemple,
une erreur peut être repérée par la ligne « ERROR: File WORK.TABLE_GLOBALE.DATA does not
exist. », ce qui signifie que la table de données « table_globale » n’existe pas et que sa création n’a
pas été effectuée lors d’un traitement antérieur. Mais l’absence de cette table peut aussi provenir

53
d’une opération qui a mal tournée lors de sa création. La création a donc été entamée mais elle a
finalement échouée. Il faut alors remonter dans l’exécution et trouver l’autre erreur à l’origine de ce
disfonctionnement. D’une manière générale, la correction d’un programme a été effectuée de la
façon suivante :
 Identification des erreurs dans l’ordre chronologique (de haut en bas dans la lecture de la
log).
 Analyse de chaque erreur :
o Quel effet ?
o Par quelle cause ?
 Correction des erreurs reconnues.
 Re-lancement de la partie du programme dysfonctionnant.
 Si le résultat n’est toujours pas bon :
o Refaire toutes les étapes ci-dessus, en sachant que les anciennes erreurs ont
normalement disparues, mais que des nouvelles peuvent être apparues.
o Et ainsi de suite, jusqu’à ce qu’il n’y ait plus d’erreurs.
Il faut aussi faire attention aux erreurs « invisibles » comme par exemple la mauvaise valeur d’un
indicateur car sa définition a mal été implémentée, ou l’oubli d’une fonction qui n’influe pas sur le
reste mais limite les résultats, etc.
Ces erreurs-là sont corrigeables par la partie suivante de recette fonctionnelle.
Recette fonctionnelle
La recette fonctionnelle se fait à l’aide du « Cahier de recette » rédigé lors de la troisième phase du
projet. Elle permet de valider ou d’invalider les résultats obtenus avec le Data Mart. Dans notre cas,
le cahier de recette comporte la liste des indicateurs et, pour chaque indicateur, deux types de
vérifications ont été mises en place : une vérification en volume (est-ce que le total agrégé
correspond à la réalité) et une vérification unitaire (nous testons 10 observations différentes une à
une sur la valeur de l’indicateur associé). Ainsi, un « état » pour chaque indicateur a été définit :
 Vert si les deux vérifications sont bonnes
 Orange si l’une des deux est fausse
 Rouge si les deux sont fausses
Dans l’état « vert », l’indicateur est considéré comme validé. Lorsque l’état est « orange » ou
« rouge », l’indicateur doit être re-testé, avec une nouvelle exécution pour le volume, et un jeu
d’observations différent pour la partie unitaire. Si le problème persiste, alors il faut revoir la
définition de l’indicateur avec le métier.
La recette fonctionnelle est une partie importante car elle permet de rendre compte des indicateurs
dont la règle de calcul n’est pas correcte et de les corriger. Dans notre cas, 10% des indicateurs ont
dû être corrigés à la suite de la recette fonctionnelle.
Cette opération de recette fonctionnelle se répète jusqu’à que tous les indicateurs aient été validés.
A la fin de cette phase, le Data Mart est mis en production. Si un ou deux indicateurs restent
invalides au bout d’un certain temps, il est tout de même conseillé de lancer la production du Data
Mart, et finir de corriger ces indicateurs ultérieurement.

54
Sixième phase : Maintenance et évolutions
La dernière phase de maintenance permet d’assurer la pérennité du Data Mart. Une fois que celui-ci
est passé en production, il s’agit de réaliser régulièrement les opérations suivantes :
 S’assurer à chaque exécution qu’aucune erreur n’est survenue, en allant par exemple
regarder la log et vérifier qu’il n’y a pas de mot clé « ERROR ».
 S’assurer que la taille du Data Mart (somme de toutes les tailles des bases de données et
fichiers qui sont contenus dans le répertoire « /serv123/SAD/DATAMART ») ne dépasse pas
la limite autorisée pas le serveur. Si la taille totale approche la taille limite, il faut alors
demander au SI d’archiver certaines bases dont le Data Mart ne se sert plus.
 Faire évoluer le Data Mart selon les nouveaux besoins et les nouvelles techniques
d’optimisations.
Dans notre cas, les deux premiers points sont faits à chaque exécution. Après la correction de
quelques petites erreurs, il n’y en a plus eu puisque le Data Mart est actuellement bien automatisé et
optimisé.
Le dernier point est sans doute le plus important car c’est souvent ce qui demande la plus grande
dose de travail et parfois tout un processus de projet peut être relancé depuis la phase 1 (pour les
grosses évolutions par exemple). Prenons le cas d’une demande d’ajout d’un nouveau périmètre au
Data Mart impliquant 10 nouveaux acteurs, 90 nouveaux indicateurs et 5 nouveaux reportings. Il faut
alors reprendre toutes les phases du Design à la Recette. Les fichiers référentiels, la documentation,
la structure et les programmes sont déjà créés. Il s’agit donc de compléter ces éléments étape par
étape et de créer les reportings nécessaires. Si un processus est automatisé et optimisé pour la
lecture et l’écriture, alors il sera facile de le faire évoluer. Un programme automatisé,
compréhensible, condensé et cohérent possède une bonne capacité d’évolution.
Dans notre cas nous avons eu affaire à deux évolutions :
 Une concernant le périmètre en impliquant 2 nouveaux acteurs métiers, 9 indicateurs, et 1
reporting.
 Une autre concernant les données sources extraites : le Data Mart est passé du type
indépendant au type dépendant. Dans un premier temps il effectuait ses extractions depuis
des bases de données de l’organisation et dorénavant il extrait les données d’un Data
Warehouse, récemment mis en place.
Cette évolution a été menée à bien en modifiant les extractions et les transformations
faites : en partant de la partie chargement et en se basant sur les données que le Data Mart
attend, il est intuitif de remonter le processus dans le sens inverse et de redéfinir les
extractions et les transformations. Les référentiels et la documentation doivent donc être
modifiés ainsi que les programmes correspondants à ces deux parties.

55
RESULTATS
Au terme de notre étude, les résultats obtenus sont assez convaincants. Le Data Mart offre les
résultats fonctionnels attendus et de bonnes performances techniques.
Sur le plan fonctionnel, le Data Mart répond aux besoins suivants :
 Intègre tout le périmètre définit au début du projet.
 Fournit 300 indicateurs mensuellement, ventilés sous 10 axes d’analyse
 Ces résultats sont répartis dans une dizaine de reportings
Sur le plan technique, le Data Mart s’exécute de la façon suivante :
 Une table générale est sauvegardée chaque mois et contient tous les indicateurs et tous les
axes d’analyse.
 Cette table pèse environ 3 Go en mémoire.
 Pour la créer il faut en général 8h d’exécution : 2 heures pour les extractions, 1h pour les
transformations et le chargement, et 5 heures pour le calcul des indicateurs et des axes
d’analyse. L’impression des reportings prend très peu de temps.
 Les optimisations décrites dans la partie « Optimisation pour l’exécution » ont permis
d’obtenir ces temps de traitements. Autrement, le Data Mart mettrait environ 20 heures à
tourner (principalement dû à la suppression de doublons non centralisée).
 Le processus est divisé en plusieurs programmes SAS. Un indicateur est décrit dans un et un
seul SAS, de même pour les extractions et les axes d’analyse.
 Le Data Mart est évolutif :
o Pour rajouter un indicateur il suffit de créer un nouveau SAS, de le placer dans le bon
répertoire, et de renseigner son ajout dans le programme SAS des macros variables.
De même pour les axes d’analyse.
o Pour modifier une extraction, il suffit d’ouvrir le programme SAS correspondant et
d’appliquer la nouvelle requête.
o Pour modifier un reporting il suffit de modifier le programme SAS qui se charge de
créer la table temporaire qui est imprimée grâce à l’« ODS TAGESETS.EXCELXP ».
Pour en ajouter un nouveau il faut s’aider des modèles de programmes déjà
effectués et reproduire la même exécution pour les données qui nous intéressent.
 Le Data Mart ne se lance pas encore automatiquement.
 Il éxiste une partie manuelle dans le processus global : certains reportings doivent être
retraités « à la main ».
 Certains reportings sont complètement automatisés à l’aide de macros VBA sous Excel.
Tandis que d’autres nécessitent quelques interventions.
 Tous les reportings s’envoient par mail chaque mois à une liste de diffusion.
 Plusieurs erreurs ont été rencontrées puis corrigées, notamment pendant les phases de test
et la recette fonctionnelle. Actuellement il manque très peu d’indicateurs non validés.
 Certains doublons persistent avec la méthode déterministe employée (champs
discriminants). Ils sont issus de « paradoxes » métiers qui ont un sens pour le métier mais qui
engendrent des agrégations légèrement biaisées.

56
DISCUSSION
Cette partie permet de discuter des hypothèses, de la méthode employée et des résultats obtenus.
Elle sert à prendre du recul pour faire le bilan de ce qui a été fait et penser ce qui pourrait être
changé ou amélioré.
Comme vu dans la partie « Résumé », nous avons fait des hypothèses sur l’entreprise, le type de Data
Mart, la taille et la complexité des données, l’environnement de développement, les outils utilisés,
les résultats souhaités et les accès aux données. Il est cependant possible d’élargir ces hypothèses
selon notre cas de figure :
 Entreprise : n’importe quelle taille tant que les secteurs d’activité et leurs bases de données
sont clairement définis.
 Gestion du Data Mart : peut être fait par n’importe quelle équipe qui a les compétences
nécessaires dans le traitement de données.
 Type de Data Mart : dépendant ou indépendant.
 Taille des données : n’importe quelle taille moyenne ou importante tant que les bénéfices
dégagés sont supérieurs aux coûts d’implémentation et de maintenance du Data Mart.
 Modèle de données et qualité : les données peuvent être relationnelles, provenir de fichiers
plats ou de fichiers web, et elles doivent vérifier au moins l’exactitude et la complétude. Une
table globale regroupant toutes les données peut être créée ou alors les tables peuvent
rester indépendantes, avec des clés de jointures disponibles.
 L’environnement physique : n’importe quel type de serveur qui puisse supporter le poids du
Data Mart.
 L’environnement logique : peut être un SGBD fournit par un logiciel ou un système de
dossiers, ou les deux. Dans un système de dossiers, les types des bases de données doivent
être unifiés et ces dernières doivent être mobiles.
 Outils utilisés : pas de logiciel avec solutions intégrées. Les langages de programmation et
logiciels utilisés peuvent être de toute sorte. Ils doivent simplement remplir les 4 fonctions
identifiées dans la partie « Outils utilisés ».
 Automatisation : généralement indispensable. Un Data Mart non automatique est un DM qui
sera lent et source d’erreurs.
 Résultats souhaités : indicateurs, listes de données, données brutes ou analyses.
 Accès aux données : l’équipe de développement doit avoir des accès de lecture et d’écriture
sur l’ensemble du Data Mart. Les équipes métiers peuvent avoir des accès en lecture
seulement.
Dans un environnement type SGBD classique (« SQL Server », « MySQL »), il serait par exemple
possible de créer les tables grâce à la commande « CREATE TABLE [nom_table] AS … ». C’est
d’ailleurs cette même commande qui gère les métadonnées dans le cadre d’un SGBD. Avec cet
environnement, la création des indicateurs et axes d’analyses serait par contre plus difficiles à gérer
(utilisation des commandes « ALTER TABLE », « UPDATE », « INSERT », etc.) à la différence d’une
étape DATA SAS intuitive et facile à automatiser.
Au niveau des méthodes de dédoublonnage pour assurer l’Unicité des données, les seules méthodes
employées dans notre étude sont des méthodes déterministes utilisant des champs discriminant.
Comme vu dans la partie théorique « Les indicateurs : une vision traitée et concise de l’information »,

57
il existe des méthodes dites « probabilistes » qui donne un score (exemple : « Jaccard Similarity ») à
chaque observation sur sa probabilité d’être un doublon ou non. Une méthode de ce type pourrait
être employée ici, mais devrait l’être en plus de la méthode déjà mise en place pour ne pas perdre en
efficacité, quitte à prendre plus de temps et à la lancer manuellement une fois le Data Mart mis à
jour automatiquement.
Les axes d’analyse et les indicateurs sont déjà calculés après le chargement du Data Mart. Il est
possible de ne pas pré-calculer ces deux éléments pour réduire la taille du Data Martet mais ceci
engendrerait des temps de traitement plus long lorsqu’il faudrait sortir les reporting un par un en
calculant sur le moment chaque indicateur et chaque axe d’analyse. Ce paradoxe fait penser aux
différents Cubes d’un Data Warehouse (les M-OLAP où tout est pré-calculé, les R-OLAP où rien n’est
pré-calculé, et les H-OLAP o un juste milieu est trouvé).
Actuellement, le script qui lance le SAS général pour la mise à jour du Data Mart envoi un mail à la fin
de l’exécution. Il serait intéressant de profiter un peu plus de ce mail en comptant dans la log le
nombre de mot clés « ERROR » ou « WARNING » qui sont apparus et d’afficher ce résultat dans le
corps du mail. Il serait donc possible de vérifier en un coup d’œil si l’exécution s’est bien passée.
Cette opération est faisable à l’aide de commandes UNIX, par exemple rajoutées entre le lancement
du SAS et l’envoi du mail dans le script général.
Finalement, la méthode de diffusion des résultats aurait aussi pu être repensée. Actuellement tous
les envois sont effectués par mail, aux acteurs métiers concernés et, en copie, aux membres de
l’équipe projet. Ceci multiplie le « poids » de la diffusion par le nombre de destinataires et ne permet
pas de centraliser l’accès aux fichiers résultats. Une résolution à ce problème est d’utiliser un
système de partage de fichiers. Il peut être sous forme de disque dur serveur, commun à tous les
acteurs, ou sous forme de site web type « Sharepoint ». Dans tous les cas, le fichier n’est déposé qu’à
un seul endroit et peut être retrouvé très facilement (plusieurs mois après l’envoi par exemple).
D’autres aspects auraient pu être source de changement, notamment l’environnement utilisé (UNIX),
sa modélisation, l’imbrication des programmes et leurs enchaînements, l’utilisation d’Excel pour les
reportings, etc. Mais la modification de ces aspects auraient changé le Data Mart dans la forme et
non pas dans le fond.

58
CONCLUSION
Tout au long de ce mémoire, l’état de l’art et la solution qui ont été présentés ont permis de
répondre à la problématique qui était de comprendre pourquoi et comment développer, automatiser
et optimiser un Data Mart, sans l’aide de logiciel spécialisé.
L’étude mise en œuvre se base sur des outils informatiques non exhaustifs pour la construction d’un
Data Mart, mais capables de le réaliser à des coûts réduits : aucune licence de logiciel intégré n’a dû
être achetée et le temps utilisé pour la réalisation du projet fut relativement court.
Les résultats obtenus ont été satisfaisant car ils ont permis de répondre au besoin initial de création
du Data Mart : avoir un accès centralisé aux données utiles pour le métier et obtenir des rapports
d’indicateurs et d’analyses. D’autres types de modélisations ou d’optimisations auraient pu être mis
en place afin d’obtenir un Data Mart de la sorte. Mais le but ici était de proposer un exemple, le plus
complet possible, d’une solution au problème par le biais d’une méthode généralisable.
Mais le besoin engendrant cette solution reste très spécial puisqu’il implique de se baser dans des
conditions spécifiques de périmètre fonctionnel : il doit émaner d’un secteur d’activité unique de
l’entreprise et le coût de développement du Data Mart, si réduit soit-il, doit être justifié vis-à-vis de
ce besoin. Dans un tel compromis, serait-il alors possible d’élargir la solution à plusieurs secteurs
d’activités pour répartir les coûts ? Ou serait-il utile de générer un Data Mart pour chaque secteur
d’activité ? Dans ces cas-là, les méthodes employées sans l’aide d’un logiciel spécialisé resteront-t-
elles peu coûteuses et performantes à grande échelle ?

59
BIBLIOGRAPHIE
Livres et documents
- « Building the Data Warehouse » – William H. (Bill) Inmon. 3rd edition, John Wiley & Sons, 2002.
- « The Data Warehouse Toolkit » – Ralph Kimball & Margy Ross. 2nd edition, John Wiley & Sons,
2002.
- « La donnée et sa dimension de valeur », Chercheur Dario Colazzo, Université Paris Dauphine, 10
décembre 2013.
- « 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
- « 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
Sites web
- http://www.larousse.fr/dictionnaires/francais/information
- http://www.larousse.fr/dictionnaires/francais/donnée
- http://www.information-management.com/glossary/u.html
- http://methodoc.univ-rennes2.fr/content.php?pid=105695&sid=1066140
- http://fr.wikipedia.org/wiki/Métadonnée
- 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/
- http://www.larousse.fr/encyclopedie/divers/automatisation/24386
- http://cs.gmu.edu/cne/pjd/GP/GP-site/welcome.html

60
ANNEXES
ANNEXE 1 : Exemple du SCRIPT principal :

61
ANNEXE 2 : Exemple de l’utilisation d’une étape DATA, avec macro variables et fonctions, pour
générer les valeurs des indicateurs :

Memoire_Julien_Diennet_20140905

Contenu connexe

Tendances

Memoire_Julien_Diennet_20140905