Épigraphe

 

« La lecture courante est un véritable travail courante de divination. La mémoire dirige sur la perception reçue les anciennes images qui lui ressemblent»

Henri Bergson

 

« Car rien n’est impossible à Dieu »

Luc 1,37

 

 

 

 

 

 

 

 

 

 

 

 

 

DEDICACE

 

 

 

A Dieu Tout Puissant qui m’a donné le souffle de vie.

A la Sainte vierge Marie pour son intersection auprès de son Fils pour la grâce de ma vie.

A mes très chers parents MAKUMBA SAKUFA Louis Eric et KUTONGUNA MWILU Patience pour tous les sacrifices consentis durant mon parcourt du maternel à l’université.

A la grande famille MAKUMBA.

 

Je dédie ce travail

 

 

 

 

MAKUMBA ZUMBU Derick

 

 

 

 

 

 

 

 

Remerciements

 

Pour une bonne clôture de la carrière estudiantine, la formation universitaire en général, celle de l’informatique en particulier exige un travail scientifique à la fin du second cycle confirmant notre passage estudiantin.

C’est ainsi nous saisissons cette occasion pour traduire par ces écrits l’expression de notre gratitude à tous les professeurs de l’université de Kinshasa ; Plus particulièrement nos remerciements s’adressent à la faculté de sciences et plus précisément au département de mathématiques et  informatique. 

C’est dans cet esprit que nous témoignons notre profonde gratitude et reconnaissance à l’endroit du professeur docteur Pierre KAFUNDA KATALAYI, directeur de ce travail, qui malgré ses multiples occupations nous a offert sa disponibilités, dont la patience, les orientations et la rigueur nous ont guidés à alimenter nos réflexions.

A la grande famille MAKUMBA : Nadine MBONGO, Louisette SHARUFA, Héritier SAKUTA, Lareine KUTONGUNA, Walter KINZUNGA, Louis LEROI, Miche MAKUYA, Maria KINZUNGA, Dorcas MAKONGO.

A ma fille Heritiana MAKUMBA et ma nièce Marie NZITA BEDIE.

A toi l’amour et le bonheur de ma vie, KASONGO MAFETSHI Nancy.

A la grande famille KASONGO : Héritier, Hornella, Grace et Racheter.

A mes cousins et cousines : Nadine MATANGI, Louise

MAKUMBA,  Louange KUTONGUNA, Noëlla KUTONGUNA, Christiane KINZUNGA, Betty KINZUNGA, Chris KATAYI, Ruth MIANGO, Divine MIANGO, Nora KINZUNGA, Elmie, Négo KILADI, Gödel MAKODISA, Jeanne et Jeannette MUZINGU.

Nous pensons également à nos oncles et tantes : In mémoire Marie, Willy et Walter. Djef KUTONGUNA, Véronique KUTONGUNA, Pascaline Elisabeth NDOSO, Odette KUTONGUNA et Emeraude KUTONGUNA, Godé MASENGU, José LULENGWA, Deo LULENGWA, Mike KIWINGI, Willy KUZAMBA.

Que nos amis et connaissances ainsi que nos compagnons de lutte trouvent ici notre attention singulière : Chadrack KULA, L’or NGALULA, Jessica NGOYA, Adolph MUYOMBO, One CHRIS NDEMBISALA, Akhernathon BUNGA 513, Bénédicte BOTUKU, Angel NGOLO, Théo BUNI, Magalie KAWANGO, Giresse SASA, La grande famille de la légion de Marie, Junior OTSHUDI, Aristote MAVUNGU, Osée NDJOLI IMPATE, Jonathan KATALAY, Salomon TSHUNZA, Aristote MPETI, Desi MBOMA, Dora NZEMBA.

 

 

 

 

 

 

 

 

 

 

LISTE DES ABRIATIONS

 

BPM : Gestion des Processus Management

BRMS : Système de gestion de règles métier

CEGSI : Club Européen de la Gouvernance des systèmes d’information

CDI : Customer Data Intégration

CIGREF : Club d’information des grandes Entreprises

Françaises

COBIT : Control Objectives for Information and Technology

CRM : Customer Relationship Management

CXP : Centre d’eXpertise des Progiciels

DB : Base de données

DMG : Dossier Médical Global

DSI : Direction du système d’information DSS : Système de Soutien des Décisions

EAI : Entreprise Application Integration

EIS : Entreprise Information Système

ETL : Extract Transform and Load

ERP : Enterprise Ressource Planing

GSI : Gouvernance du système d’information

HRM : Human Ressource Management

HTML : Hyper Text Markup Language

ISACA : Information Systems audit and Control Association

IT : Technologie de l’Information

ITGI : Information Technology Governance Instutute

ITIL : Information Technology Infrastructure Library

MDM : Master Data Management

MIS : Management Information Système

PDM : Product Data Management

PLM : Product Lifecycle Management

SAP : Systems Applications and Products

SCM : Supply Chain Management

SI : Système d’information

SIH : Système d’Information Hospitalière

SOA : Architecture Orienté Service

SQL : Strutured Query Language

UDAF : User Defined Aggregate Function

UDF : User Defined Function

UDTF : User Defined Table Function

XML : eXtensible Markup Language

XRM : eXtended Relationship Management

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LISTE DES FIGURES

 

Figure 1.1 : Système d’information …………………………………….…… Page 5

Figure 1.2 : Mémorisation de l’information ……………….…… Page 7

Figure 1.3 : Système d’information …………………………………….…… Page 8

Figure 1.4 : Système classique ……………………………………………….…… Page 11

Figure 2.1 : Cadre général d’ITGI ……………………………………………. Page 19

Figure 2.2 : Principe de la bonne gouvernance ………..… Page 20

Figure 2.3 : Piliers de la démarche de gouvernance…. Page 21

Figure 2.4 : Historique du MDM ……………………………………………………. Page 24

Figure 2.5 : Partage de donnée de référence ……………... Page 27

Figure 2.6 : Répertoire virtuel ……………………………………………….. Page 28

Figure 2.7 : Architecture de centralisation ……………….. Page 29

 Figure 2.8 : Architecture de coopération …………………... Page 30

Figure 3.1 : Paysage technologique Big Data ………….….. Page 37

Figure 3.2 : Ecosystème ………………………………………….………………….….. Page 39

Figure 3.3 : Architecture Hadoop …………………………………………………. Page40

Figure 3.4 : Processus d’un traitement MapReduce ……. Page 42 Figure 4.1 : Les étapes à suivre MDM ……………………………..…. Page 47

 

 

 

 

 

 

 

 

 

CAPTURES ECRAN PROTOTYPE

 

1.   Elaboration du modèle de donnée …………………………………..Page 58

2.   Elaboration de règles de matching ……………………………. Page 58

3.   Détection des doublons ………………………….……………………….…… Page 59

4.   Fusionnement des doublons …………………………………………….…. Page 59

5.   Identifications de sources ………………………………………………. Page 60

6.   Historique de transactions …………………………………….………… Page 60

7.   Défusionnement de faux positif …………………………………. Page 61

8.   Définitions des sources authentiques ……………………… Page 61

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0.     INTRODUCTION GENERALE

I. PROBLEMATIQUE

La tendance actuelle à la mondialisation de la concurrence pousse les

entreprises à conquérir sans cesse de  nouveaux  marchés  et  à  mettre  en  œuvre  des  stratégies  fondées  sur  la  performance  de  toute  activité  et sur  la    conformité.  Transformées  en  prestataires  de  services  internes,  les  Directions  des  Systèmes d’Information  se  voient  demander  de  justifier  de  leur  efficacité,  de  leur  productivité  ou  encore  de  leurs dépenses. La  gouvernance    du  système  d’information (en  anglais, IT  Gouvernance)  devient  un  support important de la gouvernance d’entreprise (Corporate governance).

Quelle que soit sa sophistication, un système informatique ne peut

fournir une aide efficace que s’il traite et partage des données cohérentes et de bonne qualité. L’apparition de données hétérogènes entraîne notamment : des dysfonctionnements opérationnels dans des processus métier critiques, des choix stratégiques fondés sur des données potentiellement incohérentes et la mobilisation d’importantes ressources afin de resynchroniser les données entre différents services, voire différentes organisations. Cette hétérogénéité est principalement due au cloisonnement des données au sein des différentes applications existantes qui demeurent difficilement interopérables.

Cette problématique, dans une organisation, les données sont

généralement peu valorisables car dupliquées dans plusieurs silos fonctionnels, chacun exploitant sa propre base de données avec ses propres structures de données, sa propre interprétation de leur contenu et ses propres règles métier.

Dans ce but, il est nécessaire de mettre en place une gouvernance du système d’information particulier, appelée : « GOUVERNANCE D’UN SYSTÈME D’INFORMATION BASE SUR LE MDM POUR LA GESTION OPTIMALE DE DONNEE ». Le terme gouvernance du système d’information est maintenant fréquemment utilisé pour désigner les activités d’orientation et de contrôle relevant de l’instance administrative supérieur d’une organisation, soit celle qui tient le gouvernail. La gouvernance du SI est vue comme un processus de management, fondé sur des bonnes pratiques, qui permettent à l’entreprise d’optimiser ses investissements en systèmes d’information dans le but d’atteindre un ensemble d’objectifs.

L’enjeu MDM est de faciliter la gestion des données de référence

transversalement à différentes applications en mettant en place une organisation de circonstance supporté par une référence de données. Cet état des choses nous a conduits à porter un regard particulier et soutenu à un jeune concept en pleine expansion qu’est la gouvernance du système d’information par l’approche MDM.

 

II.       INTERET DU SUJET

Dans le cadre de notre travail de fin d’étude, la gouvernance qui sera appliquée c’est l’approche MDM (Master Data Management) qui est une démarche qui met en œuvre des procédures durables (la gouvernance des données). L’intérêt d’une telle approche est d’assurée par l’organisation de circonstance, composé d’individus aux tâches précises, et assistées par des outils dédiées en vue d’améliorer la qualité et le partage des données transversalement à l’organisation. Sans toutefois vouloir donner l’impression d’épuiser les éléments en la matière, nous voulons que ce travail ouvre une piste de recherche à d’autres scientifiques en se constituant  pour eux comme une documentation de référence.

III.    TECHNIQUES

Les techniques sont des moyens et des procédés qui permettent à un chercheur de rassembler des informations originales ou de seconde main sur un sujet donné; ce sont des instruments pour arriver à un résultat escompté en science sociales.

Dans ce travail, nous avons utilisé les techniques suivant :

•      L’interview ou l’entretien

La technique de l’interview ou l’entretien est un procédé d’investigation scientifique utilisant un processus de communication verbal, pour recueillir des informations en relation avec le but fixé. Cette technique nous a servi à consulter et à nous entretenir avec quelques agents de la santé pour des informations en rapport avec notre travail.

•      La technique documentaire

Cette technique nous a servi dans l’étude et l’analyse des documents mis à notre disposition par le département de formation de quelques établissements hospitaliers pour mieux en comprendre l’histoire. Ainsi que divers autres document portant sur notre sujet de recherche.

IV.    Méthodologie du travail

Dans le cadre de notre travail, nous allons mettre en place une approche MDM pour la gouvernance d’un système d’information pour gérer les données maitresses. Pour notre système, Notre choix concernant l’infrastructure s’est orienté vers des outils open source qui se basent sur les principes architecturaux du SOA et sur le langage de programmation JAVA. Ce choix permet la réalisation d’un prototype à moindre coût offrant la possibilité d’illustrer rapidement les concepts du MDM.

V.      PLAN DU TRAVAIL

Outre l’introduction et la conclusion générale, notre travail comprend quatre chapitres :

Ø  Premier chapitre : Généralités sur les systèmes d’information ;

Ø  Deuxième chapitre : Bonne gouvernance et mdm ;

Ø  Troisième chapitre : Big data 

Ø  Quatrième chapitre : Mise en place ainsi que notre contribution sur le logiciel.

 

 

 

 

 

 

 

 

 

 

 

 

 

CHAPITRE I.  GENERALITES SUR LE SYSTEME D'INFORMATION [10] [15]

Introduction [15]

Les entreprises sont censées aujourd’hui avoir une vision systémique

de leur structure et considérer indépendamment chaque secteur. A ce niveau, les normes et les méthodes interviennent pour rassurer les responsables de la sécurité des systèmes d’information. Ces outils ne cessent de s’adopter au contexte économique, social et politique dont lesquels ils sont insérées. Une vue d’ensemble de ces règles ou recommandation est dégager, cela facilitera leur appréhension et leur choix. Ensuite, se posera le problème de leur articulation les uns par rapport aux autres. Cela requiert un certain niveau de maturité que l’entreprise est censé atteindre et qui soit compatible avec règles et ces méthodes.

I.1 Système [10]

Toute organisation humaine (une entreprise, l’Etat, etc.) peut être perçue comme un système. Un système peut être défini comme un « ensemble d’éléments en interaction dynamique, organisé en fonction d’un but ». 

Pour parvenir à ce but, le système tient compte de son environnement et régule son fonctionnement en s’adaptant aux changements. L’interaction entre système et son environnement est possible grâce à des flux d’informations. Ces flux circulent aussi à l’intérieur du système, ce qui lui permet d’analyser son propre fonctionnement.

Les éléments du système sont eux-mêmes des systèmes(ou sous sous-systèmes) : le système de décision exploite les informations qui circulent et organise le fonctionnement du système. Des informations sont alors émises en direction du système opérant qui se charge de réaliser les taches qui lui sont confiées. Il génère à son tour des informations en direction du système de décision qui peut ainsi contrôler les écarts et agir en conséquence.

 

Figure 1.1 : Système (Joel De Rosnay, 2002)

-         Le système opérant englobe toutes les fonctions liées à l’activité propre de l’entreprise : facturer les clients, régler les salaires, gérer les stocks.

-         Le système de décision appelé également système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs et des politiques de l’entreprise.

Pour organiser son fonctionnement, le système à besoin de mémoriser des informations (pour comparer, prévoir, etc.)

I.1.2 Information [15]

I.1.2.1 Donnée et information [15]

Les termes « données » et « informations » sont souvent utilisés dans un contexte de qualité des données. Cette section vise à les définir et à les distinguer.

Une « donnée » est un élément brut, Non analysée, non organisée, non liée, non interrompue, qui n’a pas encore été interprétée, mis en contexte, utilisée pour obtenir des informations après l’analyse. Emmagasinées dans un système informatique, les données ne sont pas des informations. Elles deviendront des informations dès qu’elles seront décodées dans leur contexte d’utilisation. (Way to LearmX).

Quant au terme « information » est  est perceptible, interprétée comme un message d’une manière particulière, qui donne un sens aux données. (Way to LearmX). Cette information prendra toute sa signification dans le contexte auquel elle est destinée. La récolte, le stockage et la diffusion de l’information est devenue une industrie à part entière. Et toute organisation quelle que soit, doit consacrer une partie de son effort à récolter, traiter, stocker et diffuser l’information issue de son propre fonctionnement. Ainsi l’information est l’élément conceptuel permettant le transfert, le stockage et traitement de la connaissance.

I.1.3 Classification des informations

Pour se présenter dans un ensemble important des informations qui constituent le système d’information de l’information de l’entreprise ou du système étudié, on est amené à procéder à un certain nombre de classifications. Ainsi, l’information peut se présenter sous les diverses catégories suivantes :

-         Informations élémentaires

-         Informations paramètres

-         Informations résultantes

-         Informations de commande

-         Informations externes ou internes

-         Informations quantitative ou qualitative

-         Informations permanente ou temporaire

I.1.4. Mémorisation de l’information

Une fois l’information saisie, il faut en assurer la pérennité, c’est à dire garantir un stockage durable et fiable. Aujourd’hui,  le  support  privilégié  de  l’information  est  constitué  par  les  moyens  mis  à disposition  par  les  disques  des  ordinateurs 

(magnétiques  ou  optiques :  disques  durs, Cédéroms, DVD, bandes et cassettes…) ; cependant, le papier reste un support très utilisé en entreprise (conservation des archives papiers). Les informations stockées dans les ordinateurs le sont sous forme de fichier ou organisés afin d’être  plus  facilement  exploitables  sous  la  forme  d’une  base  de  données.  Le  système  de gestion  de  bases  de  données  (SGBD)  est  donc  une  composante  fondamentale  d’un  système d’information. Pour  être  exploitées  dans  une  base  de  données,  les informations  doivent  subir  une transformation  car  l’ordinateur  ne  sait  stocker  que  des  données.  A  l’inverse,  on  doit  être capable de reconstituer de l’information à partir des données stockées dans la base.

Figure 1.2 : Mémorisation de l’information (Reix R. (2002))

Le stockage de l’information nécessite de mettre en œuvre des moyens importants et coûteux : ordinateurs, logiciels spécialisés, supports numériques, personnels, dispositifs de sécurité…

I.1.5 Traitement de l’information

Pour  être  exploitable,  l’information  subit  des  traitements.  Là  encore,  les  traitements  peuvent être  manuels  (c’est  de  moins  en  moins  souvent  le  cas)  ou  automatiques  (réalisés  par  des ordinateurs). Les  principaux  types  de  traitement  consistent  à  rechercher  et  à  extraire  de  l’information, consolider, comparer des information entre elles, modifier, supprimer des informations ou en produire de nouvelles par application de calculs.

I.1.6 Diffusion de l’information

Pour  être  exploitée,  l’information  doit  parvenir  dans  les  meilleurs  délais  à  son  destinataire. Les  moyens  de  diffusion  de  l’information  sont  multiples :  support  papier,  forme  orale  et  de plus  en  plus  souvent,  utilisation  de  supports  numériques  qui  garantissent  une  vitesse  de transmission  optimale  et  la  possibilité  de  toucher un  maximum  d’interlocuteurs.  Ceci  est d'autant plus vrai à l'heure d'Internet et de l'interconnexion des systèmes d'information. 

I.1.7 Système d’information 

Un système d'information (SI) est un ensemble organisé de ressources

qui permet de collecter, stocker, traiter et diffuser de l'information¹. Il s'agit d'un système sociotechnique composé de 2 sous-systèmes, l'un social et l'autre technique. Le sous-système social est composé de la structure organisationnelle et des personnes liées au SI. Le sous-système technique est composé des technologies (hardware, software et équipements de télécommunication) et des processus concernés par le SI.

Figure 1.3 : Système d’information (Gabriel Piccoli, 2000)

L'apport des nouvelles technologies de l'Information est à l'origine du regain de la notion de système d´information. L'utilisation combinée de moyens informatiques, électroniques et de procédés de télécommunication permet aujourd'hui selon les besoins et les intentions exprimés- d'accompagner, d'automatiser et de dématérialiser quasiment toutes les opérations incluses dans les activités ou procédures d'entreprise. 

Ces capacités de traitement de volumes importants de données, d'interconnexion de sites ou d'opérateurs géographiquement éloignés, expliquent qu'elles sont aujourd'hui largement utilisées (par exemple dans les activités logistiques) pour traiter et répartir l'information en temps réel, en lieu et place des moyens classiques manuels - plus lents - tels que les formulaires sur papier et le téléphone.

Ces capacités de traitement sont également fortement appréciées par le fait qu'elles renforcent le caractère « systémique » des données et traitements réalisés : la cohérence et la consolidation des activités lorsqu'elle est recherchée et bien conçue permet d'accroître la qualité du contrôle interne de la gestion des organisations, même lorsque celles-ci sont déconcentrées ou décentralisées.

I.2 Enjeux du système d'information

Le système d'information est le véhicule des entités de l'organisation. Sa structure est constituée de l'ensemble des ressources (les personnels, le matériel, les logiciels, les procédures) organisées pour : collecter, stocker, traiter et communiquer les informations. Le système d'information coordonne, grâce à la structuration des échanges, les activités de l'organisation et lui permet ainsi d'atteindre ses objectifs.

Relativement à l'organisation et la direction du système d'information, voir : Management du système d'information. Le système d'information se construit à partir de l'analyse des processus "métier" de l'organisation et de leurs interactions/interrelations, et non simplement autour de solutions informatiques plus ou moins standardisées par le marché. Le système d'information doit réaliser l'alignement stratégique de la stratégie d'entreprise par un management spécifique. La gouvernance des systèmes d'information ou gouvernance informatique (IT gouvernance) renvoie aux moyens de gestion et de régulation des systèmes d'information mis en place dans une organisation en vue d'atteindre ses objectifs ³. À ce titre, la gouvernance du SI fait partie intégrante de la gouvernance de l'organisation. Les méthodes ITIL (IT infrastructure Library) et COBIT sont par exemple des supports permettant de mettre un SI sous contrôle et de le faire évoluer en fonction de la stratégie de l'organisation.

I.2.1 Les différentes natures du système d'information

I.2.1.1 Système d'information et finalité de la chose

Le SI est né dans les domaines de l'informatique et des télécommunications, le concept de SI s'applique maintenant à l'ensemble des organisations, privées ou publiques. Le terme système d'information (ou SI) possède les significations suivantes :

•       un ensemble organisé de ressources (personnel, données, procédures, matériel, logiciel, …) permettant d'acquérir, de stocker, de structurer et de communiquer des informations sous forme de textes, images, sons, ou de données codées dans des organisations. Selon leur finalité principale, on distingue des systèmes d'information supports d'opérations (traitement de transaction, contrôle de processus industriels, supports d'opérations de bureau et de communication) et des systèmes d'information supports de gestion (aide à la production de rapports, aide à la décision…).

•       Un système ou sous-système d'équipements, d'informatique ou de télécommunication, interconnectés dans le but de l'acquisition, du stockage, de la structuration, de la gestion, du déplacement, du contrôle, de l'affichage, de l'échange (transmission ou réception) de données sous forme de textes, d'images, de sons, et/ou, faisant intervenir du matériel et des logiciels.

•       Un SI est un réseau complexe de relations structurées où interviennent hommes, machines et procédures qui a pour but d’engendrer des flux ordonnés d’informations pertinentes provenant de différentes sources et destinées à servir de base aux décisions selon Hugues Angot.

•       Un SI est un ensemble d'éléments matériels ou immatériels (hommes, machines, méthodes, règles) en interaction transformant en processus des éléments (les entrées) en d'autres éléments (les sorties).

I.2.1.2 Système d'information et application informatique

On distingue généralement deux grandes catégories de systèmes, selon les types d'application informatique :

Ø les systèmes de conception : fonctionnent selon des techniques temps réel ;

Ø les systèmes d'information de gestion, qui emploient des techniques de gestion.

Du point de vue de la valeur financière du patrimoine informatique, les systèmes d'information de gestion sont largement majoritaires.

Les langages informatiques employés diffèrent souvent selon chacune de ces catégories, et à l'intérieur des catégories. Par exemple, les systèmes d'information de gestion emploient du Cobol, du langage C, du C++, du Java, du Visual Basic.NET, du WinDev (WLangage), SQL, etc.

Aujourd'hui, la généralisation des applications web rend possible une très forte interopérabilité des systèmes, qui transcende ces catégories traditionnelles. Les langages de balisage (HTML, XML, ...) s'imposent comme des standards. Ces langages sont souvent associés à des Framework. Le Framework le plus communément employé est actuellement RDF (Resource Description Framework). 

RDF s'appuie sur des normes d'interopérabilité et l'utilisation massive de métadonnées, données élémentaires communes à toutes les ressources et tous les systèmes quelles que soient leurs utilisations, qui facilitent les accès et les échanges.

I.3. Composition d'un système d'information d'entreprise

I.3.1. Composition classique

Figure 1.4 : Système classique (Hermès Science, 2000) 

Dans les œuvres des années 1980 - 1990, la composition « classique » des systèmes de l'information d'une entreprise était comme une pyramide des systèmes d'information qui reflétait la hiérarchie de l'entreprise.

Les systèmes qui traitent les transactions fondamentales (TPS) au fond de la pyramide, suivis par les systèmes pour la gestion de l'information (MIS), et après les systèmes de soutien des décisions (DSS) et se terminant par les systèmes d'information utilisés par la direction la plus supérieure (EIS), au sommet.

Bien que le modèle pyramidal reste utile, un certain nombre de nouvelles technologies ont été développées et certaines nouvelles catégories de systèmes d'information sont apparues et ne correspondent plus aux différentes parties du modèle pyramidal.

I.3.2. Composition actuelle

Dans un système d'information d'une grande entreprise, on trouve :

•       Un ERP - Enterprise Resource Planning (en français : PGI pour progiciel de gestion intégré) - qui intègre théoriquement tous les systèmes informatisés transactionnels dont les modalités de fonctionnement sont désormais bien connues des informaticiens et des hommes de l'Art de chaque métier. Les ERP permettant de soutenir le fonctionnement de l'entreprise ;

•       Des systèmes appelés autres dits les intégrés métiers, où les verticalisés qui sont des progiciels métiers, et qui couvrent aussi bien le front-office, que le middle, puis le back-office et qui ne sont pas de conception maison, mais ont été bâtis par un éditeur spécialisé sur un métier et dont les modes de fonctionnement logiciels correspondent aux meilleurs pratiques constatées à un moment donné chez les plus performant dans leur secteur d'excellence ;

•       Des systèmes restants appelés « spécifiques » (ou encore : non standards, de conception « maison », développés sur mesure, que l'on ne trouve pas sur le marché, ...), où l'on rencontrera davantage d'applications dans les domaines du calcul de coûts, de la facturation, de l'aide à la production, ou de fonctions annexes.

La proportion entre ERP et systèmes spécifiques est très variable d'une entreprise à l'autre. L'urbanisation traite de la cartographie des systèmes de l'entreprise et donc de la manière d'organiser son système d'information pour parvenir à le faire évoluer de manière prévisionnelle, en accord avec la stratégie générale de l'entreprise. La stratégie de l'entreprise est menée par la direction générale et l'urbanisation permet de mener l'alignement du SI sur la stratégie.

Dans les ERP, on trouve des modules couvrant différents domaines d'activité (comme la gestion de la production, la gestion de la relation commerciale avec la clientèle, la gestion des ressources humaines, la comptabilité, la finance, les fusions, les intégrations comptables d'acquisitions récentes...) autour d'une base de données commune et unifiée.

Il est fréquent qu'une entreprise soit équipée de plusieurs progiciels différents selon ses domaines d'activité. Dans ce cas, les progiciels ne sont pas totalement intégrés comme dans un PGI, mais interfacés entre eux ainsi qu'avec des applications spécifiques. On trouvera par exemple des applications de :

Ø  CRM - Customer Relationship Management (en français : GRC pour Gestion de la relation client) : regroupe toutes les fonctions permettant d'intégrer les clients dans le système d'information de l'entreprise

Ø  XRM - eXtended Relationship Management (en français : Gestion de la Relation Tiers) : est un système d'information d'entreprise, imaginé par Nelis XRM en 2005, dont les processus relationnels constituent le socle de l'organisation de l'information.

Ø  SCM - Supply Chain Management (en français : GCL pour Gestion de la chaîne logistique) : regroupe toutes les fonctions permettant d'intégrer les fournisseurs et la logistique au système d'information de l'entreprise

Ø  HRM - Human Resource Management (en français : SIRH pour la GRH)

Ø  PDM - Product Data Management (en français la notion qui s'en rapproche le plus : SGDT pour Système de gestion de données techniques) : fonctions d'aide au stockage et à la gestion des données techniques. Surtout utilisé par les bureaux d'études. En fait le PDM est l'évolution de la fonction SGDT, jusqu'à de nouvelles manières de gérer le cycle de vie des données.

Ø  PLM - Product Lifecycle Management (en français : gestion du cycle de vie du produit). Il s'agit d'une notion qui comprend en plus du PDM, la conception et l'aide à l'innovation, et la fin de vie du produit, donc son recyclage).

I.3.3. Évolution de la composition du système d'information

Le domaine des systèmes d'information et de communication a certes une forte composante technologique et informatique. Mais c'est seulement un aspect de ce domaine qui est en fait beaucoup plus vaste. Il s'agit de concevoir comment circule et est stockée l'information de façon efficace et cohérente pour toutes les activités d'une entreprise, d'un réseau d'entreprises, d'une administration publique, des relations entre entreprises, citoyens, gouvernements...

Le champ est vaste et concerne tous les domaines des activités humaines. Malgré cette ampleur, ce domaine a son unité scientifique, construit autour de concepts, de constructions abstraites et concrètes, de composants de méthodes notamment qui sont indépendantes des activités concernées. Sans doute, un des maîtres mots de ce domaine des systèmes d'information est-il celui de "modèle accompagné", ou "modélisation". Par conséquent, dans les entreprises actuelles, le système d'information et de communication tend à s'orienter vers des ensembles plus globaux, l'information traitée par l'humain étant une connaissance à gérer.

Des économistes tels que Robert Solow ou Daniel Cohen ont montré que les systèmes d'information ne généraient de gains de productivité que s'ils étaient accompagnés de changements organisationnels. 

Le changement dans les organisations est donc indissociable du logiciel. Cette nouvelle dimension impose à une science plutôt dure originellement de se tourner vers les techniques d'amélioration continue comme le Lean.

En complément du SI classique, une ingénierie des connaissances (en anglais Knowledge Management) s'articule autour des deux composantes suivantes, que l'on peut retrouver dans chaque domaine d'activité de l'entreprise :

•       La gestion de contenu (en anglais : content management), destinée à gérer les informations brutes et à les transformer en connaissances ou données mieux structurées ;

•       La gestion des accès, c'est-à-dire la gestion des flux et des protocoles d'échange dans les réseaux de (télé-)communications internes ou partagés avec les partenaires.

Sur le plan du management des systèmes d'information, une tendance actuelle correspond à leur externalisation auprès d'une ou plusieurs sociétés prestataires pouvant se voir confier la gestion de l'infrastructure informatique, des développements de logiciels ou encore de la gouvernance.

I.3.4. Autres composants possibles

D'autres composants peuvent être inclus dans un système d'information pour offrir des caractéristiques techniques ou des fonctionnalités spécifiques :

•       Applications métiers,

•       Bases de données de l'entreprise,

•       Contrôle d'accès,

•       Dispositifs de sécurité,

•       Infrastructure réseau,

•       Postes de travail informatique,

•       Accès aux réseaux Internet, Intranet ou Extranet,

•       Serveurs d'application,

•       Serveurs de données et systèmes de stockage,

•       Système de paiement électronique,

•       Système de sécurité (protection et chiffrement),

•       Outils de Groupware, agendas,

•       Espace de partage de documents,

•       Échange d'informations (forums électroniques),

•       Gestion de contacts,

•       Conférence électronique (chat, vidéoconférence).

I.4. Systèmes d'information et développement durable

Les systèmes d'information comportent le plus souvent des informations de nature économique et financière, mais aussi de plus en plus d'informations environnementales et sociales. Le problème qui se pose sur le plan du développement durable est celui du partage de l'information, surtout extra financière (environnementale et sociale) entre les organismes et leurs parties prenantes.

L'architecture d'un système d'information durable est structurée autour de trois référentiels métiers :

•       la gestion des données de référence (MDM - Master Data Management) ;

•       le système de gestion de règles métier (BRMS - Business Rules Management Systems) ;

•       la gestion des processus métier (BPM - Business Process Management System).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CHAPITRE II : BONNE GOUVERNANCE ET MDM [1], [2], [3], [4], [5], [6], [7]

[8], [12], [13], [14], [16], [17], [18]

II.1 Bonne gouvernance [6]

Le système d’information est le véhicule de communication dans

l’organisation, il coordonne grâce à l’information les différentes activités de l’organisation. Les enjeux d'efficacité des projets, d'efficience des usages, de performances opérationnelles, d'alignement aux stratégies d'entreprise dépendent de la bonne gouvernance des systèmes d’information. La gouvernance des systèmes d’information relève la responsabilité des dirigeants de l’entreprise. Elle permet de répondre à des besoins de limitation des risques, de conformité réglementaire, de création de valeur ou d’alignement. Elle doit trouver une réponse outillée par l’intermédiaire des applications du système d’information.

II.1.1 Qu’est-ce que la gouvernance ? [2] [3]

Le terme de gouvernance sert à désigner « l’art ou la manière de gouverner » un système en le distinguant du terme « gouvernement » en tant qu’institution.

La notion de la gouvernance, très vogue aujourd’hui, est loin de n’être qu’une simple et belle idée. La gouvernance mondiale, gouvernance nationale, gouvernance sectoriel, gouvernance européenne, gouvernance africaine, gouvernance d’entreprise ou gouvernance d’internet, chaque fois que différents acteurs veulent exercer un pouvoir sur un système, quel que soit, ils évoquent la notion gouvernance. Nous allons nous focaliser dans le présent travail sur la gouvernance des SI. Dans son sens le plus large, la gouvernance peut désigner la manière de diriger, une façon d’administrer ou piloter.

II.1.2 Définition de la gouvernance du système d’information [14]

La gouvernance des systèmes d’information (GSI) peut se définir comme

la démarche à travers laquelle les professionnels des SI, confrontés à un problème de décision ayant comme objet le SI, vont (i) définir et prioriser des objectifs pour les projets de SI en cohérence avec la stratégie de l’organisation, et (ii) envisager des leviers d’action sur le portefeuille de projets en se basant sur des évaluations quantitatives qui elles seules pourront supporter des choix d’évolution argumentés.

La gouvernance du système d’information consiste d’abord à fixer au

système d’information des objectifs liés à la stratégie de l’entreprise. Cette démarche permet de définir la manière dont le système d’information contribue à la création de valeur par l’entreprise et précise le rôle des différents acteurs en tenant compte de leurs enjeux de pouvoir.

Selon l’itgi crée en 1998 dans le cadre de l’isaca et le cigref crée en 1970, la gouvernance des systèmes d’information est un processus de management, fondé sur les bonnes pratiques, permettant à l’entreprise de diriger la fonction SI dans le but de :

-         Soutenir ses objectifs de création de valeur.

-         Accroitre la performance des processus du si et leur orientation clients.

-         Maintenir les aspects financiers du si.

-         Développer des solutions et des compétences en si dont l’entreprise aura besoin dans le futur.

-         Assurer que les risques liés au si sont gérés.

Elle peut être également définie de la manière suivante : c’est l’ensemble d’activité hautement spécialisé, liées à des décisions stratégiques relatives aux systèmes d’informations et sa prise en compte dans la gouvernance des entreprises (cegsi, 2010). La gouvernance de SI concerne non seulement la direction du SI mais aussi tous les métiers de l’entreprise qui concourent à la création de valeur grâce aux SI.

II.1.3 Pourquoi le système d’information a-t-il besoin de gouvernance ? [2] [3]

Un système d’information connait nécessairement un mode de

gouvernance. Quelle que soit leur nature, il existe des règles s’appliquant à ce système. Et des mécanismes de contrôle sont généralement en place. Ainsi, il ne s’agit pas de créer la gouvernance du système d’information, mais véritablement d’en faire un outil de pilotage et d’amélioration. Vouloir mettre en œuvre une démarche de gouvernance du système d’information, c’est d’abord admettre que le mode de gouvernance à un impact sur l’efficacité du système d’information à court et à long terme. Les réflexions sur la gouvernance du système d’information portent sur la définition des démarches et sur la recherche des bons principes à mettre en œuvre. C’est une recherche d’accroissement de la performance et de réduction des couts et des risques.

Figure 2.1 : Cadre général de la ITGI (Florescu & al (2007))

La gouvernance est une notion essentielle pour le système

d’information. Elle permet de répondre à beaucoup de questions cruciales que se posent aujourd’hui de nombreux spécialistes des systèmes d’information, notamment :

-         Quels doivent être les modes de relation entre la direction générale et la direction des systèmes d’information ?

-         Quel doit être le partage des rôles et des responsabilités entre les différentes directions gérant et utilisant le système d’information de l’entreprise?

-         Quels sont les processus clés de la DSI ?

-         Comment s’assurer d’un usage efficient du système d’information ?

-         Quel doit être le mode d’organisation de la DSI, en particulier dans le cas d’un groupe ?

-         Comment accroitre la pérennité du système d’information ?

-         Comment réduire les risques associés au système d’information ?

 

 

II.1.4 Les principes de la bonne gouvernance du système d’information [4]

La GSI est fondée sur cinq(5) principes de base : alignement

stratégique, la fourniture de la valeur, la mesure de la performance, la gestion des ressources et la gestion des risques.

Figure 2.2 : principe de la bonne gouvernance (Delvaux 2007)

L’alignement  stratégique  (IT  Strategic  Alignment), concerne  l’alignement  de  la  stratégie  du  système d’information á la stratégie d’affaires (Henderson & Venkatraman, 1993 ; Florescu& Tamas, 2006).  

La  fourniture  de  la  valeur  (IT  Value  Delivery),  concerne  l’amélioration  de  la  valeur  des  services  de l'entreprise par le biais du système d’information (Corbel  & al.2004 ).  La mesure de la  performance (Performance Measurement), concerne l'analyse des pratiques en matière de pilotage et de contrôle de gestion informatique (tableaux de bord, reporting, etc.). La gestion des ressources (IT Resource Management), il s'agit d'analyser la connaissance et les principes de gestion des actifs matériels et logiciels, des ressources humaines, ainsi que des politiques de sous-traitance et d'externalisation. La  gestion  des  risques  (IT  Risk  Management),  il  s'agit  d'analyser  la  connaissance  du  risque  pris  par l'entreprise à travers ses systèmes informatiques (cf. cartographie du risque informatique) et ce, en termes d'impact métier.  Les  principes  de  gouvernance  du  système  d’information  sont  en  phase  avec  les  pratiques  managériales fondamentales : établir une stratégie efficace, disposer d'outils de pilotage pertinents, démontrer la valeur et la contribution de ses actions, connaître les risques encourus et gérer le patrimoine informatique.

II.1.5 Les quatre piliers de la gouvernance d’un système d’information [2]  Gouverner le système d’information suppose : 

•    un devoir d’anticipation : évaluer des opportunités et des risques ; 

•    un impératif de décision : réalisé des choix ; 

•    une nécessité  de communication : instaurer un dialogue de tous les acteurs concernés, avant, pendant et après les décisions prises ; 

•    une obligation de suivi : suivre et réviser les actions mises en œuvre. 

Ces quatre éléments sont intimement imbriqués et ne doivent pas  être vus seulement comme un simple enchaînement. Des itérations sont nécessaires. Il faut aussi penser ces quatre éléments comme les piliers du système de gouvernance, avec de fortes interactions entre eux.

Figure 2.3 : les quatre piliers de la démarche de gouvernance (Cigref 2002)

II.1.5.1 Gouverner, c’est anticiper et connaitre

Il faut connaître et prendre en compte différents  éléments : 

•    les orientations stratégiques de l’entreprise, des métiers et du système d’information (notion d’alignement) ; 

•    l’état de l’art technologique ; 

•    les  coûts et les dépenses associé s au système d’information ; 

•    les risques potentiels. Il n’est pas possible de se contenter de ré agir, il faut aussi établir une vision cible du système d’information qui permette de communiquer afin d’anticiper sur les points pré c é dents. 

Notions clés : proactivité, prospective, évaluation et gestion des risques.

II.1.5.2 Gouverner, c’est décider

Il n’existe pas de gouvernance sans prise de décision. La gouvernance n’existe que par la concrétisation. Cela signifie également de définir et de piloter les prises de décision liées au système d’information. 

Notion clé : prise de décision.

II.1.5.3 Gouverner, c’est communiquer et suivre

Il faut toujours s’assurer que les éléments de la démarche sont compris, partagés et suivis. La gouvernance nécessite un dialogue à différents niveaux hiérarchiques. Ce dialogue doit être soutenu, répété, varié  dans ses formes mais cohérent dans ses objectifs. 

Notions clés : dialogue, communication.

II.1.5.4 Gouverner, c’est adapter

Il n’existe pas de vérité  éternelle. Il faut toujours s’assurer de la bonne adéquation des modalités  de gouvernance aux réalités de l’organisation, de son environnement et surtout de ses acteurs. Si nécessaire, il faut réviser voire repenser ces modalités. 

Notions clé s : évolution, adaptation.

II.2 MDM [1] [5] [7] [12]

L’informatique d’entreprise s’oriente depuis plusieurs années vers une plus grande agilité : ouverture du système d’information dans « l’entreprise étendue » pour inclure les partenaires, ou pour accompagner les opérations des fusions/ acquisitions, ou que ce soit au travers de service web, d’outils de collaboration avancée, pour ne citer que ces exemples. Cependant, l’entreprise « agile » doit aussi pouvoir unifier ses différents visions « métiers », dans des contextes de processus métiers multiples et d’architectures informatiques distinctes, sans perdre de vue la base même de son capital : la donnée. La fiabilité des informations, des données, fait donc de plus en plus l’objet de recherches au sein des départements d’urbanisation et d’organisation des systèmes d’informations des entreprises, chargé de trouver une solution au problème de mise à jour des données, progiciels, ou autres applications.

La technologie de gestion des données de référence (MDM), ou Master Data Management, correspond à cette recherche : pouvoir identifier des données de référence, ou données maitres, pour aboutir à une information à la fois unique et partagée dans l’entreprise. Proche de l’EAI ou de l’ETL, le master Data Management s’en distingue pourtant foncièrement : il ne s’agit pas d’intégrer des données entre applications, ni d’agréger les données dans un entrepôt pour ensuite les manipuler, mais de garantir leur unicité et leur cohérence à chaque fois qu’elles invoquées ou modifier depuis des sources distinctes. Au vu du caractère structurant de la gestion des données de référence, une analyse d’impact rigoureuse s’impose en amont de tout projet MDM. 

II.2.1 Qu’est-ce que l’approche MDM [5]

L’enjeu de l’approche MDM  est de pouvoir mettre en place un

référentiel de données ainsi qu’une organisation adaptée qui permettront de gérer les données transversalement aux différents projets et applications. L’objectif de l’approche MDM est de mutualiser les efforts et d’assurer la synchronisation, le partage et le contrôle des données à travers les différents silos en quasi temps réel.

Un  référentiel de données consiste essentiellement en une application qui supervise la gestion d’une banque de données alimentée par plusieurs fournisseurs et consultable par des différents consommateurs. Ce référentiel  se focalise sur les données à haute valeur ajoutée dont la qualité et l’accessibilité sont cruciales pour les partenaires métier. Ces données sont aussi appelées données de référence ou  master data. L’objectif du référentiel est d’intégrer et d’uniformiser les différentes données reçu ou collectées pour ensuite les rendre facilement accessibles. Cette intégration peut être réalisée de manière  logique ou physique :

Ø Soit le référentiel de données joue un rôle d’annuaire de données permettant aux consommateurs d’identifier à quel(s) fournisseurs de données ils doivent s’adresser (Intégration   Logique). Cet annuaire suit le même principe qu’un annuaire téléphonique ; il facilite les échanges de données sans s’occuper de leur contenu. 

Ø Soit le référentiel de données joue un rôle de consolidateur (harmonisateur) de données et une base de données spécifiquement dédiée à la gestion des données de référence est créée afin de faciliter leur consolidation (Intégration   Physique).

Le MDM est une approche récente (2005). Néanmoins, à l’échelle de

l’histoire de l’informatique, son passé ne doit pas être oublié. Durant les années 1980, les premiers travaux de recherche sur la gestion des données concernaient essentiellement leur stockage, la manière dont les données pouvaient être stockée sur disque et être rendues accessibles le plus rapidement possible.  À partir de 1995, des avancées particulièrement probantes ont été accomplies au niveau de l’analyse des données tant du point de vue de leur contenu que de leur signification. L’objectif était d’améliorer la connaissance qu’on avait sur ses données afin de les rendre à la fois mieux interprétables et plus exploitables.  Depuis 2005, au travers de l’approche MDM, on s’interroge non seulement sur la fiabilité du contenu des données mais également sur la fiabilité des échanges et sur la manière dont-elles sont partagées et réutilisées.

 

Figure 2.4 : Historique du MDM (Afai, 2011)

II.2.2 Pourquoi utiliser l’approche MDM [7]

Au fil du temps, les organisations ont constaté qu’elles perdaient le contrôle de leurs données. L’origine de cette perte de contrôle s’explique au travers de différents facteurs :  

•      Le volume et la  complexité  des données ne cessent de croître. La quantité d’information à stocker est de plus en plus importante, le niveau de détails exigé pour décrire une donnée est de plus en plus fin et les structures de données deviennent de plus en plus complexes.

•      Les données sont de plus en plus  interdépendantes. En effet, les contraintes métier imposent souvent des dépendances fortes entre les données. À tout moment il faut pouvoir être capable de vérifier que ces contraintes sont respectées. L’augmentation du volume de données implique l’augmentation du nombre de ces contraintes, ce qui entraîne une explosion de la complexité. Dès lors, lorsqu’une donnée est modifiée, il devient de plus en plus difficile d’identifier quels seront les impacts éventuels sur d’autres  données et de vérifier que les contraintes métier sont toujours satisfaites. 

•      Si aucune mesure n’est prise, la  qualité  des données manipulées a naturellement toujours tendance à se  détériorer. Soit les données sont mal introduites, soit elles sont incomplètes, soit elles ne sont plus à jour, soit elles sont corrompues lors de mauvaises manipulations, etc. 

•      Certaines données sont  dispersées et  dupliquées. Les données peuvent être dupliquées pour des raisons d’efficacité ou de facilité d’accès. Cependant, il faut toujours s’assurer que ces données dupliquées restent synchronisées et qu’elles n’évoluent pas de manière anarchique. Malheureusement, cette  synchronisation n’est souvent pas garantie, ce qui entraîne l’apparition de données  hétérogènes.

D’un point de vue économique, le principal avantage de l'approche MDM (et en particulier la mise en œuvre de référentiels centraux de données) est de réduire les coûts des services IT. En savoir ; Réduire les coûts d'interfaces applicatives, Réduire les coûts des redondances de données, Réduire les coûts de nettoyage de données, Réduire les coûts de traitement et de nettoyage de données externalisées, Réduire les coûts de licence, de support et de matériel des systèmes redondants, Réduire les coûts de développement et de maintenance, Réduire les coûts de livraison d'information.

II.2.3 Les concepts fondamentaux du mdm 

II.2.3.1 Qu’est-ce qu’une donnée de référence ?

Une donnée de référence ou master data est une information de base, fondamentale pour l'activité de l'entreprise, et partagée ou dupliquée dans plusieurs systèmes.

Assurer la synchronisation et l’intégration des données, soit en mode

batch soit en temps réel, a un coût non négligeable et il est illusoire de vouloir appliquer ces principes à l’ensemble de ses données. Il faut se concentrer sur un sous-ensemble de celles-ci appelées données de référence ou master data.

Cette donnée métier doit être identifiable et  reconnue comme telle partout dans l'organisation, quel que soit le service qui en est responsable, le système d’information, le serveur ou le logiciel qui l'héberge, la traite ou l'enregistre, la division ou la filiale qui la produit.  Les données de référence décrivent généralement des objets métier tels que « client », « produit », « fournisseur », « adresse »,  « employé »,  etc.  Traditionnellement, elles s’opposent aux données dites transactionnelles qui se réfèrent aux événements relatifs à ces objets métier.

II.2.3.2 Qu’est-ce que la gestion de donnée de référence ?

La gestion des données de référence  ou le Master Data Management (MDM) n'est ni une technologie ni un logiciel, mais une démarche, une méthode qui met en œuvre des procédures durables et se focalise sur la rationalisation de la gestion des données partagées au sein d’une organisation ou entre plusieurs organisations. (La gouvernance des données).

Cette gouvernance est assurée par une organisation de circonstance,

composée d'individus aux tâches précises, et assistée par des outils dédiés en vue d'améliorer la qualité et le partage des données transversalement à l’organisation. Le MDM se base principalement sur trois approches fondamentales que sont la «  Data Governance », la «Data Quality » et la «  Data Integration ».

Ø Data governance : La Data Governance définit un ensemble de bonnes pratiques et de moyens facilitant la gestion des données. Plus les données sont partagées entre différents intervenants plus cette problématique  devient cruciale. L’important est de gouverner ses données et d’éviter l’anarchie. Mais qu’entend-on par « gouverner ses données » ? Gouverner c'est essentiellement prévoir, négocier, soulever et résoudre des problèmes.

 

Ø Data intégration : L’intégration de données définit un ensemble de processus permettant de migrer, combiner et consolider des données provenant de différentes parties du système d’information, habituellement à extraire des données de différentes sources (bases de données, fichiers, applications, services web,  emails, etc.), à leur appliquer des transformations (jointures, lookups, déduplication, calculs, etc.), et à envoyer les données résultantes vers les systèmes cibles. Suivant le niveau d’intégration demandé et le niveau de disponibilité des données, différentes technologies peuvent être utilisées.

 

Ø Data quality : La Data Quality   définit un ensemble de bonnes pratiques et de moyens en adéquation avec les usages (fitness for use) améliorant la qualité des données stockées dans une base de données ou dispersées dans plusieurs bases de données. Différentes techniques sont utilisées tel que le profiling, le monitoring, la standardisation et le matching des données.

 

Figure 2.5 : partage de donnée de référence (Ifaci, 2011)

 

II.2.4 Les architecture MDM

Les architectures MDM sont des architectures d’échange qui

déterminent où les données de référence vont être stockées  et comment elles vont être partagées entre les différents fournisseurs et consommateurs de données. Chaque architecture possède ses avantages et  ses inconvénients. Le choix d’une architecture est souvent délicat, car ce choix peut évoluer au cours du temps et dans certaines situations une combinaison de différentes architectures peut se révéler nécessaire.

II.2.4.1 Le répertoire virtuel

La première architecture consiste à créer un annuaire de données dont le rôle principal est de rediriger les requêtes des consommateurs de données vers les fournisseurs de données adéquats Son activité principale consiste à gérer un index reprenant les clefs d’accès aux données sources. Cette architecture offre  une plateforme d’échange qui s’occupe d’aiguiller les messages vers les fournisseurs de données sans tenir compte de leur contenu.

Figure 2.6 : Répertoire virtuel (Ifaci, 2011)

Le principal avantage  de cette architecture est sa mise en place relativement transparente pour les utilisateurs finaux. Le principal inconvénient de cette architecture est qu’elle cache la nécessité d’avoir un modèle commun des données de référence.

II.2.4.2 Centralisation (Repository)

À l’autre extrême, se trouve l’architecture dite de « centralisation ». Cette architecture n’intègre plus les données  logiquement mais physiquement. Les données de référence et les attributs nécessaires au bon fonctionnement des applications sont centralisés dans une base de données unique. Cette DB centrale devient la seule source de vérité. Une seule et même application peut être utilisée pour l’acquisition, la validation et la consultation des données.

 

 

 

 

Figure 2.7 : MDM : Architecture de Centralisation (Ifaci, 2011)

Le principal avantage de cette solution est d’avoir une application unique pour gérer les données de référence, les rendre accessibles et ainsi éviter la duplication et l’hétérogénéité des données. Cette centralisation entraîne également des inconvénients majeurs. Les plus importants sont le coût de la mise en place de cette architecture et l’acceptation du principe de la centralisation des données dans une base de données unique.

II.2.4.3 Coopération (Hybrid)

Au croisement de ces deux architectures  est née une architecture intermédiaire dite de « coopération». Les objectifs de cette architecture sont : 

•      de diminuer la charge de travail liée à la mise en place d’une architecture de centralisation,  

•      de diminuer la complexité liée à la gestion et à l’évolution d’un répertoire virtuel, 

•      de minimiser les impacts sur les applications fournisseuses et 

•      de créer une DB commune et neutre contenant une version intégrée des données de référence.

 

 

 

 

 

 

 

Figure 2.8 : MDM : Architecture de coopération (Ifaci, 2011)

Le principal avantage de cette solution est de mettre à disposition des consommateurs de données une source de référence regroupant des données intégrées. L’objectif étant d’avoir le moins d’impact possible sur les systèmes existants tout en améliorant la qualité des données échangées. Bien qu’il semble que cette architecture tire profit des avantages des deux architectures précédentes, il est importa nt de souligner ses inconvénients. Premièrement, contrairement aux autres  architectures, les données de référence sont une nouvelle fois dupliquées. Ironiquement, cette duplication risque de créer un nouveau silo de données. Deuxièmement, comme dans le cas de l’architecture de centralisation, la complexité de la DB commune dépend de la quantité de données à stocker et du nombre potentiel d’utilisations de ces données. Enfin, la synchronisation des données n’est toujours pas garantie.

II.2.5 Les différents types de MDM       

Les solutions MDM sont généralement associées à d’autres       applications de l’entreprise; Pour cette raison elles sont        souvent        classées         dans   trois catégories             distinctes:

•      MDM opérationnel;           MDM analytique;  

•      MDM d’entreprise ou collaboratif.

II.2.5.1 MDM opérationnel (O-MDM)

Où les solutions MDM permettent de définir, créer et synchroniser les données de référence de qualité nécessaires au bon fonctionnement d’un système transactionnel et délivrées en quasi temps réel.  Vient consolider plusieurs applications opérationnelles (ex: ERP, CRM, applications maisons, etc.); doit supporter le temps réel; nécessite des changements au niveau des applications opérationnelles, ce qui n’est pas toujours évident; la structure des données est relativement stable (changements peu fréquents). Application possible en ES : enregistrement d'un patient au moment de son arrivée dans l’établissement de santé. Les différentes applications, étant informées de cette nouvelle venue, ne créent pas de doublon.

II.2.5.2 MDM analytique (A-MDM)

Où les solutions MDM se limitent principalement à faciliter les prises de décision sur des ensembles de données spécialement adaptées à ce type d’analyse. Les entrepôts de données en sont une forme;  les structures de données changent plus souvent; les dimensions conformes jouent un rôle clé dans cette solution. Application possible en ES : rapprochement de données économiques et financières ou encore rapprochement de données de ressources humaines et données d’activité par exemple.

II.2.5.3 MDM d’entreprise ou collaboratif (C-MDM)

C’est le niveau que voudrait atteindre toutes les entreprises; une seule structure intègre, synchronise et coordonne les structures des données communes aux différentes plateformes technologiques de l’entreprise (opérationnelles ou analytiques); lorsque le mot MDM est utilisé seul, on fait souvent référence au MDM d’entreprise. création ou modification de données de référence par différents acteurs de l'entreprise en vue de conserver en un seul lieu la source de vérité de la donnée de référence tout en garantissant son accès par les différentes applications. Application possible en ES : enrichissement du dossier patient via différentes applications (imagerie médicale, prescription médicamenteuse…), par exemple. En général, le MDM est utilisé pour une combinaison de toutes ou parties de ces 3 approches avec, par exemple, l'émergence du décisionnel en temps réel.

 

 

 

 

CHAPITRE III : LES BIG DATA [9], [11], [13], [15]

III.1 Présentation [15]

L’explosion quantitative des données numériques a obligé les chercheurs à trouver de nouvelles manières de voir et d’analyser le monde. Il s’agit de découvrir de nouveaux ordres de grandeur concernant la capture, la recherche, le partage, le stockage, l’analyse et la présentation des données. Après le très en vogue « cloud computing », un nouveau concept émerge dans le secteur informatique, celui du ‘’Big Data’’. A l’origine du concept de ‘’Big Data’’ se trouve l’explosion du volume de données informatiques, conséquence de la flambée de l’usage d’internet, au travers des réseaux sociaux, des appareils mobiles, des objets connectés, etc.

Selon le CXP, les Big Data désignent des méthodes et des technologies (pas seulement des outils) pour des environnements évolutifs (augmentation du volume de données, augmentation du nombre d’utilisateurs, augmentation de la complexité des analyses, disponibilités rapide de données) pour l’intégration, le stockage et l’analyse des données multi-structurées (structurés, semi structures et non structurées).

III.2 Définition du Big Data [9]

Littéralement, ces termes signifient méga données, grosses données ou encore données massives. Ils désignent un ensemble très volumineux de données qu’aucun outil classique de gestion de base de données ou gestion de l’information ne peut vraiment travailler. En effet, nous procréons environ 2,5 trillions d’octets de données tous les jours. Ce sont les informations provenant de partout : messages que nous envoyons, vidéos que nous publions, informations climatiques, signaux GPS, enregistrements transactionnels d’achats en ligne et bien d’autres encore. Ces données sont baptisées Big Data ou volumes massif de donnée. Les tous premiers à déployer ce type de technologie.

Cependant, aucune définition précise ou universelle ne peut être donnée au Big Data. Etant un objet complexe polymorphe, sa définition varie selon les communautés qui s’y intéressent en tant qu’usager ou fournisseur de services.

 

III.3 Caractéristique des Big Data

Le Big Data se caractérise par la problématique des 3v :

Ø Volume : c’est le poids des données à collecter confrontées à des contraintes de stockage, les entreprises doivent aussi gérer le tsunami des réseaux sociaux. La montée en puissance des réseaux sociaux a accentué cette production de données.

Ø Variété : l’origine variée des sources de données qui sont générées premièrement, l’époque où les entreprises s’appuyaient uniquement sur les informations qu’elles détenaient dans leurs archives et leurs ordinateurs est évolué. De plus en plus de donnée nécessaires à une parfaite compréhension du marché sont produits par des tiers. Deuxièmes, les sources se sont multipliées : banques de données, sites blogs, réseaux sociaux, terminaux connectés comme les smartphones, puces RFID, capteurs, caméras, etc. 

Ø Vélocité : la vitesse à laquelle les données sont traitées simultanément à l’ère d’internet et de l’information quasi instantanée, les prises de décision doivent être rapides pour que l’entreprise ne soit pas dépasser par ses concurrents. La vélocité va du bath au temps réel.

A ces « 3v » les uns rajoutent la visualisation des données qui permet

d’analyser les tendances ; les autres rajoutent la variabilité pour exprimer le fait que l’on ne sait pas prévoir l’évolution des types de données.

III.4 Les Big Data en chiffre

Après le siècle du pétrole, nous entrons dans l’ère de la donnée. Les chiffres ci-dessous permettent de présenter la quantité de données générées jusqu’ici et la croissance dans les prochaines années.

Notons que : 12 zettaoctets de données ont été créés dans le monde en 2011, 118 milliards d’emails sont envoyés chaque jour, 235 téraoctets de données ont été collectés par the library of congress en avril 2011, 30 fois plus de données seront générées d’ici 2020, le telescope ‘’square kilometers away’’ produira plus d’un téraoctet de données par minute en 2024. Twitter génère 7 téraoctet de données par jour, Facebook génère 10 téraoctet de données et traite 50 milliards de photos de par jour, 30 milliards de contenus sont échangés chaque mois sur Facebook. Nous pouvons bien constater que nous nageons dans un océan de donnée où le niveau de la mer augmente rapidement.

 

III.5 Interets du Big Data

L’utilisateur des Big Data pourrait impacter fortement le monde de

l’entreprise et ce façon méliorative, aussi les entreprises pourront :

Ø Améliorer la prise de décision

Ø Réduire les couts d’infrastructures informatiques via l’utilisation des serveurs standards et des logiciels open source

Ø Développer la réactivité et l’interactivité à l’égard des clients

Ø Améliorer les performances opérationnelles

Tout ceci orientera les entreprises vers une économie centrée sur la donnée.

III.6 Enjeux des Big Data

Le Big Data apparait comme le challenge technologie des années 20102020. Dépassant les domaines techniques et informatiques, le Big Dat suscite un vif intérêt auprès des politiciens, des scientifiques et des entreprises. Les enjeux du Big Data touchent plusieurs secteurs d’activités.

III.6.1Enjeux techniques

Les enjeux techniques s’articulent autour de l’intégration, le stockage,

l’analyse, l’archivage, l’organisation et la protection des données.

III.6.2Enjeux économiques

D’après le cabinet de conseil dans le marketing IDC, « le marché du Big Data représentera 28 milliards de dollars en 2020, avec une part de stockage estimé à 1/3 de ce montant » (Saulem, enjeux économiques du Big Data à l’échelle mondiale). Il va sans dire que la « donnée » est le nouvel urinoir du siècle présent, les spécialistes s’accordent déjà sur le fait que le Big Data sera l’arme économique de demain pour les entreprises et se présentera comme un levier qui fera la différence. Les entreprises collectent de plus en plus d’information en relation avec leurs activités (production, stockage, logistique, ventes, clients, fournisseurs, partenaires, etc.), toutes ces informations peuvent être stockées et exploitées pour stimuler leur croissance. Les Big Data permettent :

Ø D’améliorer les stratégies marketing commerciale

Ø D’améliorer et entretenir la relation client

Ø De fidéliser la clientèle

Ø De gagner de nouvelles parts de marché

Ø De réduire les couts logistiques

Ø De favoriser la veille concurrentielle

III.6.3 Enjeux juridique

Le principal enjeu juridique dans ce contexte où les utilisateurs sont

souvent des « produits », reste la protection de la vie privée.

III.7 Limites des Big Data

Si le terrain de jeu du Big Data est loin d’être restreint, il n’est pas sans

limites. Elles tiennent, en premier lieu, à la nature des données et aux traitements en visages, et lorsqu’il est question des données personnelles, la vigilance est nécessaire. Dans certains pays, le traitement des données à caractère personnel est régi par des dispositions particulières, ce qui n’est pas le cas dans la majorité des pays.

Nous sommes arrivés à un point où la protection des données

personnelles, partie à la défense des libertés fondamentales de l’individu, est en train de devenir un argument économique. L’enjeu étant dorénavant, l’élaborer le cadre normatif le plus attractif pour le développement de l’économie numérique et des échanges de données, ceci nécessite d’être vigilent dans un contexte de forte concurrence entre les puissances économiques. L’autre préoccupation provient de la sécurité : une faille minuscule peut menacer des quantités de données considérables. Si les utilisateurs perdent confiance dans l’utilisation de leurs informations, c’est donc tout l’édifice du Big Data qui risque de s’écorcher. Pour éviter cela, par exemple en Europe, la commission européenne à présenter en début 2013 un règlement qui vise à protéger davantage les utilisateurs. Ce texte devrait être voté en 2014 pour une application en 2016, il obligera les entreprises à demander le consentement de l’utilisateur avant de collecter ses données.

III.8 Paysage technologique des Big Data

Après la présentation du Big Data, il est important de voir le paysage technologie qui constitue cette technologie. Les données quelques soit leur structure passent par plusieurs étapes avant que leur valeur ne soit perceptible. Ci-dessous, nous avons un aperçu global de différentes technologies présentes dans le paysage Big Data.

Figure 3.1 : paysage technologique Big Data, (Bermond, 2013)

Les Big Data reposent sur plusieurs technologies, qui sont utilisées pour exploiter les gigantesques masses de données.

III.8.1 Intégration

Dans le contexte Big Data, l’intégration des données s’est étendue à des

données non structurées (données des capteurs, journaux, web, réseaux sociaux, document). Hadoop utilise le scripting via MapReduce ; Sqoop et Flume participe également à l’intégration des données non structurées. Ainsi, certains outils d’intégration comprenant un adaptateur Big Data existe déjà sur le marché ; c’est le cas de Talend Enterprise Data Intégration_Big Data Edition. Pour intégrer des gros volumes de données issus de briques fondations du système d’information des entreprises (ERP, CRM, Supplychain(gestion de la chaine logistique)), Les ETL, Les EAI, Les EII sont toujours utilisés.

III.8.2 Stockage

Le premier élément structurant dans le contexte Big Data est le socle de stockage des données. Anciennement, la solution était les Data Warehouse (Entrepôts de données), qui ont évolué pour supporter de plus grandes quantités de données et faire porter par le stockage, une capacité de traitement étendue. Les solutions de Data Warehouse ont toutes en commun un modèle de données profondément structuré (Schéma, base de donnée, tables, types, vues, etc.) et un langage de requête SQL.

Le Big Data vient rompre cette approche ; l’approche du Big Data

consiste en 2 grandes principes. C’est le cas de l’ACIDITE (Atomicité, Cohérence, Isolation et Durabilité). (mathieu millet, 2013). Pour mettre en œuvre cette approche avec une infrastructure simple, scalable (mot utilisé pour indiquer à quel point un système matériel ou logiciel parvient à répondre à une demande grandissante de la part des utilisateurs ; il traduit aussi la capacité de montée en charge), matériel à bas cout, le frame work Hadoop est utilisé pour la gestion du cluster, l’organisation et la manière de développer. La solution la plus emblématique de cette approche est Hadoop et son écosystème.

III.8.3 Analyse

C’est bien de pouvoir stocker les données, mais faut-il pouvoir

également les rechercher, les retrouver et les exploiter : c’est l’analyse des données. Elle est naturellement l’autre volet majeur du paysage technologie du Big Data. En la matière, une technologie qui s’impose, Hadoop. Ce projet applicatif fait l’unanimité même s’il est loin d’être stable et mature dans ses développements. Hadoop utilise MapReduce pour le traitement distribué. MapReduce est patron d’architecture de développement informatique introduit par Google qui permet de réaliser des calculs parallèles de données volumineuses (supérieur à 1 téraoctet). Les calculs peuvent être distribués sur plusieurs machines ce qui permet de répartir les charges de travail et d’ajouter facilement le nombre de serveurs suivant les besoins.

Plusieurs implémentation de MapReduce existent dont les plus connues sont l’implémentation réalisé par Google nommé Google MapReduce et l’implémentation Apache MapReduce. L’implémentation de Google est propriétaire alors qu’Apache MapReduce est open source. Apache MapReduce est un des deux composants majeur du frame work open source Apache Hadoop qui permet la gestion des Big Data.

III.8.4 Restitution

Le Big Data met aussi l’accent sur l’importation de restituer

efficacement les résultats d’analyse et d’accroitre l’interactivité entre utilisateurs et données. Ainsi, des produits comme Qlikview, tableau (de tableau software), Powerview, SpotFire proposent des visualisations graphiques innovantes.

III.9 Ecosystème Hadoop

Pour certain, l’avenir appartiendra à ceux qui seront capable d’analyser

les vastes volumes de données qu’ils ont collectées. En écologie, un écosystème est l’ensemble formé par une association ou communauté d’êtres vivants et son environnement biologique, géologique, édaphique, hydrologique, climatique, etc. L’écosystème Hadoop est l’ensemble des projets Apache ou non, liés à Hadoop et qui sont appelés à se cohabiter.

Hadoop désigne un frame work Java libre ou un environnement

d’exécution distribué, performent et scalable, dont la vocation est de traiter des volumes des données considérables. Il est le socle d’un vaste écosystème constitué d’autres projets spécialisés dans un domaine particulier parmi lesquels on compte les entrepôts de données, le suivi applicatif (monitorring) ou la persistance de données. Le schéma ci-après présente les différents éléments de l’écosystème Hadoop en fonction du type d’opération.

Figure 3.2 : Ecosystème

III.9.1 Hadoop Kernel

Hadoop Kernel est le cœur de l’écosystème Haddop. Ce frame work est

actuellement le plus utilisé pour faire du Big Data. Hadoop est écrit en Java et a été créé par Doug Cutting et Michael Cafarella en 2005, (le frame work Apache Hadoop). Le noyau est composé de 2 composants. Hadoop présente l’avantage d’être issu de la communauté open source, de ce fait un porte un message exprimant une opportunité économique. En revanche, il affiche une complexité qui est loin de rendre accessible au commun des DSI. Nous continuerons par une présentation de quelques grands concepts d’Hadoop.

III.9.1.1 Architecture Hadoop

Le schéma ci-dessous présente l’architecture distribué dans le contexte Hadoop.

Figure 3.3 : Architecture Hadoop avec les principaux roles des machines (le frame work Apache Hadoop)

Il est primordial de savoir qu’une architecture Hadoop est basée sur le principe maitre/esclave, représentant les deux principaux rôles des machines. Les sous rôles relatifs au système de fichiers et à l’exécution des taches distribuées sont associés à chaque machine de l’architecture. Les machines maitresses ont trois principaux rôles qui leur sont associés :

Ø JobTracker : c’est le rôle qui permet à la machine de lancer des taches distribuées, en coordonnant les esclaves. Il planifie les exécutions, gère l’état des machines esclaves et agrège les résultats des calculs.

Ø NameNode : ce rôle assure la répartition des données sur les machines esclaves et la gestion de l’espace de nom cluster. La machine qui joue ce rôle contient des métadonnées qui lui permettent de savoir sur quelle machine chaque fichier est hébergé.

Ø Secondary NameNode : ce rôle intervient pour la redondance du NameNode. Normalement, il doit être assuré par une autre machine physique autre que le NameNode car il permet en cas de panne de ce dernier, d’assurer la continuité de fonctionnement du cluster.

Deux rôles sont associés aux machines esclaves :

Ø <taskTracker : ce rôle permet à un esclave d’exécuter une tache MapReduce sur les données qu’elle héberge. Le TaskTracker est piloté par JobTracker d’une machine qui lui envoie la tâche à exécuter.

Ø DataNode : dans le cluster, c’est une machine qui héberge une partie des données. Les nœuds de données sont généralement répliqués dans le cadre d’une architecture Hadoop dans l’optique d’assurer la haute disponibilité des données.

Lorsqu’un client veut accéder aux données ou exécuter une tache distribué, il fait appel à la machine maitresse qui joue le rôle de JobTracker et NameNode. Maintenant que nous avons vu globalement l’articulation d’une architecture Hadoop, nous allons voir deux principaux concepts inhérents aux différents rôles que nous avons présentes.

III.9.1.2 HDFS

HDFS est le système de fichiers Java, permettant de gérer le stockage des données sur des machines d’une architecture Hadoop. Il s’appuie sur le système de fichier natif de l’os (unix) pour présenter un système de stockage unifié reposant sur un ensemble de disque et systèmes de fichiers. La consistance des données réside sur la redondance ; une donnée est stockée sur au moins n volumes différents. Le NameNode rendait le cluster inaccessible s’il venait à tomber en panne, il représente le SPOF (maillon faible) du cluster Hadoop. Actuellement, la version 2.0 introduit le farilaver  automatisé (capacité d’un équipement à basculer automatiquement vers un équipement alternatif, en cas de panne). Bien qu’il y ait plusieurs NameNodes, la promotion d’un NameNode se fait manuellement sur la version 1.0.

Dans un cluster les données sont découpées et distribuées en blocks

selon la taille unitaire de stockage (généralement 64 ou 128 Mo) et le facteur de réplication (nombre de copie d’une donnée, qui est de 3 par défaut). Un principe important de HDFS est que les fichiers sont de type « Write-one » ; ceci est lié au fait que lors des opérations analytiques, la lecture des données est beaucoup plus utilisée que l’écriture.

III.9.1.3 MapReduce 

MapReduce qui est le deuxième composant du noyau Hadoop permet

d’effectuer des traitements distribués sur les nœuds du cluster. Il décompose un Job (unité de traitement mettant en œuvre un jeu de données en entrée, un programme MapRedue (packagé dans un JAR (Java archive : fichier d’archive, utilisé pour distribuer un ensemble de classes Java)) et des éléments de configuration) en un ensemble de tache plus petite qui vont produire chacune un sous ensemble du résultat final ; ce moyen de fonction Map. L’ensemble des résultats intermédiaires traité (par agrégation, filtrage), ce au moyen de la fonction Reduce.

Le schéma ci-dessous présente le processus d’un traitement MapReduce.

Figure 3.4 : Processus d’un traitement MapReduce, (Bermond, 2013)

Le MapReduce présente sur le schéma permet de trouver le nombre d’occurrence des mots d’un fichier nommé ici « un fichier .txt » durant la phase de « découpage », les lignes du fichier sont découpées en blocs. Puis lors de la phase « Map », des clés sont créées avec une valeur associée. Dans cet exemple une clé est un mot et la valeur est 1 pour signifier que le mot est présent une fois. Lors du tri, toutes les clés identiques sont regroupées, ici ce sont tous les mots identiques.

En suite lors de la phase « Reduce » un traitement est réalisé sur toutes les valeurs d’une même clé. Dans cet exemple on additionne les valeurs ce qui peut permet d’obtenir le nombre d’occurrence des mots.

III.9.1.4 Modes d’utilisations

Hadoop peut être sous trois modes différents :

v Mode standalone : ce mode à pour objectif de tester le fonctionnement d’une tache MapReduce. Ici, la tâche est exécutée sur le poste client dans

la seule machine virtuelle Java (JVM), pas besoin d’une configuration particulière car c’est la mode de fonctionnement de base de Hadoop.

v Mode pseudo distributed : ce mode permettra de tester l’exécution d’une tache MapReduce sur une seule machine tout en simulant le fonctionnement d’un cluster Hadoop. Le Job est exécuté sur la machine et les opérations de stockage et de traitement du Job seront gérées par des processus Java différents. L’objectif de ce mode est de tester le bon fonctionnement d’un Job sans besoin de mobiliser toutes les ressources du cluster.

v Mode fully distributed : c’est le mode réel d’éxecution d’Hadoop. Il permet de mobiliser le système de fichier distribueé et les Jobs MapReduce sur un ensemble de machines ; ceci nécessite de disposer de plusieurs postes pour héberger les données et exécuter les taches. Dans la suite, d’autres composants qui entrent dans l’écosystème Hadoop sont présentés.

III.9.2 Composants Apache Hadoop

III.9.2.1 Hbase

Hbase est un système de gestion de beses de données non

relationnelles distribuées, écrit en Java, disposant d’un stockage structuré pour les grandes tables. C’est une base de données NoSQL, orientée colonnes utilisé conjointement avec HDFS, ce dernier facilite la distribution des données de Hbase sur plusieurs nœuds contrairement à HDFS, HBASE permet de gérer les accès aléatoires read/write pour des applications de type temps réel.

III.9.2.2 Hcatalog

Hcatalog prmet l’interopérabilité d’un cluster de données Hadoop avec d’autres systèmes (Hive, Pig, …). C’est un service de gestion de tables et de schéma Hadoop. Il permet :

-         D’attaquer les données HDFS via des schémas de type tables de données en lecture/écriture.

-         D’opérer sur les données issues de MapReduce, Pig ou Hive.

III.9.2.3 Hive

Hive est un outil de requetage des données, il permet l’exécution de

requête SQL sur le cluster Hadoop en vue d’analyser et d’agréger les données. Le langage utilisé par Hive est nommé Hive QL. C’est un langage de visualisation uniquement, raison pour laquelle seules les instructions de type « select » sont supportées pour la manipulation des données. Hive proposent des fonctions prédéfinies (calcul de la somme, du maximum, de la moyenne), il permet également à l’utilisateur de définir ses propres fonctions qui peuvent être de 3 types :

v UDF (User defined function) : qui prennent une ligne en entrée et retournent une ligne en sortie. Exemple : mettre une chaine de caractère en minuscule et inversement.

v UDAF (User defined aggregate function) : qui prennent plusieurs lignes en entrée et retournent une ligne en sortie. Exemple : somme, moyenne, max …

v UDTF (User defined table function) : qui prennet une ligne en entrée et retournent plusieurs lignes en sortie. Exemple : découper une chaine de caractère en plusieurs mots.

Hive utilise un connecteur jdbc/ odbc, ce qui permet de le connecter à des outils de création de rapport comme Qlikvieuw.

III.9.2.4 Pig

Pig est une brique qui permet le requetage des données Hadoop à

partir d’un langage de script (langage qui interprète le code ligne par ligne au lieu de faire une compilation). Pig est basé sur un langage de haut niveau appelé Piglatin. Il transforme étape par étape des flux de données en exécutant des programmes MapReduce successivement ou en utilisant des méthodes prédéfinies du type calcul de la moyenne, de la valeur minimale, ou en permettant à l’utilisateur de définir ses propres méthode appelées User Défined Functions (UDF).

III.9.2.5 Sqoop

Sqoop est une brique pour l’intégration des données. Il permet le

transfert des données entre un cluster et une base de données relationnelles.

III.9.2.6 Flume

Flume permet la collecte et l’agrégation des fichiers logs, destinés à

être stockés et traités par Hadoop. Il s’interface directement avec HDFS au moyen d’une API native.

III.9.2.7 Oozie

Oozie est utilisé pour gérer et coordonner les taches de traitement de données à destination de Hadoop. Il supporte des Jobs MapReduce, Pig, Hive, Sqoop, etc.

III.9.2.8 Zookeeper

Zookeeper est une solution de gestion de cluster Hadoop. Il permet e

coordonner les taches des services d’un cluster Haddop. Il fournit au composant Hadoop les fonctionnalités de distribution.

III.9.2.9 Ambari

Ambari est une solution de supervision et d’administration de cluster Hadoop. IL propose un tableau de bord qui permet de visualiser rapidement l’état d’un cluster. Ambari inclut un système de gestion de configuration permettant de déployer des services d’Hadoop ou de son écosystème sur des clusters de machines. Il ne se limite pas à Hadoop mais permet de gérer également tous les outils de l’écosystème.

III.9.2.10 Mahout

Mahout est un projet de la fondation Apache visant à créer des implémentations d’algorithmes d’apprentissage automatique et le data mining.

III.9.2.11 Avro

Avro est un format utilisé par la sérialisation des données. Le caractère open source de Hadoop a permis à des entreprises de développer leur propre distribution en ajoutant des spécificités.

 

 

 

 

 

 

 

 

CHAPITRE IV : MISE EN PLACE

Comme tout projet de développement d’un système d’information (SI), un projet MDM comprend un certain nombre d’étapes successives. L’objectif de cette section n’est pas d’exposer en détail les étapes classiques d’un projet de développement logiciel mais de mettre l’accent sur les particularités des projets MDM en mettant en avant les tâches spécifiques à ceux-ci et en les illustrant sur notre étude de cas. Le caractère transversal et multi-organisationnel des projets MDM exige une attention particulière. Dans la suite de cette section, nous regroupons les étapes spécifiques aux projets MDM suivant trois phases: l’analyse, la conception et l’implémentation. Le processus de développement d’un référentiel est itératif ; c'est-à-dire qu’à tout moment, lors des phases de conception ou d’implémentation, un retour en arrière vers les phases précédentes est toujours possible.

Figure 4.1 : MDM : les étapes à suivre

ü Projet SIH (système d’information hospitalière)

L’accès au soin de santé est un besoin fondamental. En RDC, de nombreux professionnels de la santé répartis dans différents établissements prodiguent des soins. Les données concernant notre état de santé sont recueillies et conservées sur différents supports : papier, films, fichiers électroniques, etc. Les données nous concernant sont dispersées auprès de différents prestataires et institutions de soins. La qualité des soins de santé dépend aussi de la qualité des données nous concernant et de la capacité des prestataires et institutions de soins de santé à s’échanger ces données. Dans cette perspective, tout patient peut se poser les questions suivantes :

•      Suis-je certain que le médecin que je consulte connaît tous mes antécédents médicaux ?

•      Que se passera-t-il quand mon médecin traitant prendra sa retraite ?

•      Où peut-on trouver un aperçu complet de mes antécédents médicaux ?

•      Qui connaît les médicaments que je prends actuellement ?

•      Que m’arrivera-t-il, si en cas d’urgence, je me trouve loin de la clinique ou de l’hôpital où je me rends habituellement ?

Le SIH (système d’information hospitalière) correspond à la photographie sanitaire d’un patient. Il s’agit d’un instantané que le médecin traitant, en tant que gestionnaire du Dossier Médical Global (DMG), saisira lors de contacts privilégiés avec le patient. Il ne s’agit donc pas d’un dossier santé complet, mais bien d’une extraction à partir de celui-ci des éléments de soins utiles au suivi médical. Le SIH constitue un document de liaison entre les Dossiers Médicaux Informatisés (DMI) des médecins généralistes, mais aussi avec ceux des médecins spécialistes hospitaliers ou non. Il pourrait être partagé selon plusieurs modes, par exemple :

•      le simple transfert d’un fichier électronique à partir d’un logiciel médical vers un autre,

•      sa conservation au sein d’un container, formant ainsi un dossier santé partagé établi au sein d’un réseau santé, etc.

L’échange de ces dossiers médicaux minimaux pourrait être facilité grâce à la plate-forme santé publique qui « est avant tout une institution publique, instituée par la loi, qui vise à promouvoir et à soutenir l'échange électronique et sécurisé de données entre tous les acteurs des soins de santé (médecins, hôpitaux, pharmaciens, patients, …) tout en respectant la protection de la vie privée et le secret médical.

Lorsque les SIH seront mis à la disposition de plusieurs prestataires de soins, il faudra établir des règles d’accès spécifiant qui peut accéder à quel dossier hospitalier et à quelles parties de celui-ci. Par exemple, une condition préalable est l’existence d’un lien thérapeutique fort entre le médecin et le patient. Cette règle peut paraître évidente, pourtant, définir la notion de « lien thérapeutique fort » est une question fondamentale et délicate dont les aspects juridiques ne doivent pas être négligés.

4.1. Phase d’analyse

Aborder l’approche MDM comme un problème avant tout technologique est une erreur qui peut être lourde de conséquence. L’approche MDM c’est essentiellement comprendre des processus et des systèmes métier complexes et mettre en place des (nouveaux) processus afin de gérer leurs données. La première question à se poser n’est pas de savoir si l’approche MDM se basera sur une solution IBM, Oracle, ou SAP en suivant ou non les principes d’une architecture SOA. Au départ, il faut identifier quelles données vont être partagées, pourquoi elles doivent être partagées, qui va en être la source authentique, où vont-elle être stockées, qui en est le propriétaire, qui peut y accéder et quels sont les obstacles (techniques, conceptuels ou politiques) qui pourraient empêcher le partage de ces données. Ensuite, il faut s’interroger sur les règles à appliquer afin d’assurer la gestion et la maintenance de ses données de référence. Enfin, il faut déterminer les parts de responsabilité dans la gestion journalière des données de référence et favoriser la coordination des différents intervenants en créant une organisation spécifiquement dédiée à cette tâche.

4.1.1 Identifier et décrire les données de référence

Selon Forrester, les projets MDM ne couvriront pas l’ensemble des données mais se focaliseront sur les données critiques avec des problèmes de qualité visibles. De toute évidence, le périmètre des données de référence doit être délimité avec précaution. Cette première étape d’analyse est généralement révélatrice de la complexité d’un projet MDM. L'objectif est de définir un périmètre optimal pour les données de référence et d'obtenir un aperçu détaillé de leur statut actuel. Certaines organisations identifient des centaines de structures de données différentes avec des centaines d’interprétations tout aussi différentes. L’identification des données de référence dépend principalement du domaine d’application, des besoins métier et du type de données échangées.

Généralement, une donnée de référence possède les caractéristiques suivantes :

1.     Une donnée de référence a une valeur métier importante. Il faut distinguer les données critiques pour le métier des données moins sensibles tant du point de vue de leur qualité que de leur disponibilité.

2.     Une donnée de référence est réutilisée, partagée entre différentes applications et/ou échangée avec des tiers.

3.     La durée de vie d’une donnée de référence est considérée comme longue. En opposition aux données dites transactionnelles, une donnée de référence a généralement un long cycle de vie. Cette durée dépend principalement du métier considéré. De plus, un même type de données peut avoir des cycles de vie et des rythmes de mise à jour différents suivant les contextes d’utilisation de cette donnée. Par exemple, les données concernant un patient ou un dossier patient ont potentiellement un long cycle de vie et sont plus sujettes aux changements. Tandis qu’une prescription ou les résultats d’un examen médical ont un cycle de vie court et ne sont pas sujets au changement.

4.     Le volume des données de référence est suffisamment élevé. L’utilité de la création d’un référentiel dépend de la quantité de données qui vont y être stockées. Gérer trois ou cent mille patients nécessite différents types de stratégies et d’outils. Outre le volume des données, le volume des transactions est également à prendre en considération. Une fois les données de référence identifiées, la maîtrise des données de référence dépend de notre capacité à les expliciter et à les faire valider par les acteurs impliqués. Expliciter ces données de référence consiste essentiellement à décrire :

•      les structures des données et les relations entre elles,

•      les métadonnées (Attribut, type de données, valeurs autorisées, valeurs par défaut, les contraintes, les dépendances, etc.) [Elmasri, 06],

•      la manière dont ces données sont interprétées (glossaire métier),

•      le cycle de vie des données avec les processus de création, de modification (correction) et de suppression des données,

•      qui sont les fournisseurs et les consommateurs de ces données,  les cas d’utilisation

•      les exigences de qualité par rapport aux données (fraîcheur, disponibilité, complétude, …).

4.1.2 Déterminer les méthodes et les règles de gouvernance

Sans une gouvernance efficace et appropriée, les initiatives MDM

rencontreront des difficultés principalement liées à des conflits politiques et à la résistance des fournisseurs de données. Cette résistance se justifie par le manque d’une explicitation claire des règles régissant l’utilisation de leurs données et sur la responsabilité qu’ils devront endosser. L'objectif est de définir une stratégie de gouvernance dès les premières phases du projet de manière à augmenter ses chances de réussite. Définir une stratégie de gouvernance consiste à :

•      Définir les règles de qualité concernant la consistance, la précision et la complétude des données.

•      Définir des indicateurs de mesure de la qualité des données  Définir les moyens mis en œuvre pour détecter les anomalies.

•      Définir les règles d’arbitrage pour traiter ces anomalies.

•      Définir les règles d’intégration, d’élimination des doublons.

•      Définir les règles de sécurité en termes de protection et d’accessibilité des données.

•      Définir un processus de maintenance et de gestion du changement afin de préserver la qualité des données et d’assurer leur disponibilité.

4.1.3 Mettre en place une organisation pour gérer les données de référence

Au terme de la phase d’analyse, il est nécessaire de mettre en place une

organisation afin de mener la suite du projet et d’assurer la gestion journalière des données de référence ainsi que le respect et l’évolution des règles de gouvernance. L'objectif est de constituer une équipe de personnes en charge de la gestion du référentiel aussi bien pour sa constitution que sa maintenance.

Cette organisation est dotée de différentes prérogatives :

•      La gestion et la centralisation des données de référence,

•      L’élaboration et l’évolution des règles de gouvernance,

•      La supervision des données de référence (utilisation, accès, préservation de la cohérence et du caractère privé, etc.),

•      L’arbitrage des problèmes relatifs au référentiel et aux données gérées par celui-ci,

•      Faciliter l’utilisation du référentiel et le valoriser.

Ce groupe de personnes est généralement composé des contributeurs à l’élaboration des règles de gouvernance. Toutefois, il faut préserver son caractère transversal et la mixité des profils business et IT. Dans la suite de cette section, nous décrirons différents rôles à jouer au sein de cette organisation. Cependant, ces rôles doivent être reconsidérés au sein de chaque organisation :

Ø Sponsor. Le Sponsor détermine le plan stratégique et met à disposition les moyens (ressources et personnel) à la mise en place de la solution MDM.

Ø Business Data Owner. Le Business Data Owner participe à :

-         La validation et la définition de la structure et de la sémantique des données,

-         La spécification des niveaux de qualité et de sécurité.

-         La définition des règles concernant la création, modification et suppression des données de référence dont il est le propriétaire. Le Business Data Owner collabore étroitement avec les gestionnaires des processus métier qui ont un impact sur le cycle de vie de ses données.

Ø Data Steward. Le data Steward joue le rôle de coordinateur et assure la gestion journalière des données de référence. Il gère opérationnellement la qualité des données et supporte la mise en œuvre des règles de gouvernance. Il est garant de l’intégrité des données de référence et du support aux Data Users.

Ø Data User. Soit le Data User est limité à une simple consultation des données, soit il possède aussi des prérogatives en termes de création/modification/suppression de données. Habituellement, un Data User est également un Data Owner pour un autre type de données. Dans tous les cas, il participe à la définition des scenarii d’utilisation et spécifie ses exigences notamment au niveau de la disponibilité et de la qualité des données.

Ø Data Architect. Le Data architect participe à la définition des architectures applicatives et techniques des solutions MDM. Il collabore étroitement avec les Business Data Owners afin de définir les modèles de données et d’assurer leur cohérence et standardisation. Il s’attache au respect des normes et standards et favorise l’interopérabilité entre les différents systèmes partageant les données.

En résumé, le Sponsor s’occupe de l’établissement des budgets et de la définition de la stratégie générale. Le Business Data Owner s’occupe en détail de ses données. Le Data Steward s’occupe de l’utilisation correcte du référentiel et vérifie la bonne synchronisation et intégration des données. Le Data User définit ses exigences quant à l’utilisation des données. Enfin, le Data Architect met à disposition son expertise technique et métier afin de favoriser la convergence vers une solution la plus interopérable possible.

4.2 Phase de conception

Une fois la phase d’analyse terminée, différentes décisions doivent être

prises afin de concevoir le référentiel. Dans un premier temps, il est nécessaire de définir un modèle commun pour les données de référence. Ce modèle permettra à tous les intervenants de comprendre la structure et la sémantique des données qui vont être échangées. Dans un deuxième temps, un format standard d’échange doit être défini afin de servir de langage commun entre les différents interlocuteurs. Ensuite, il faut déterminer l’architecture d’échange et spécifier les contrats d’échanges établis entre les différents intervenants. Enfin, une infrastructure d’échange doit être proposée afin de pouvoir satisfaire au mieux les règles de gouvernance et vérifier leur mise en œuvre correcte.

4.2.1 Définir un modèle commun de référence

L’objectif de cette étape est de définir une modèle logique standard

pour les données de référence explicitant leurs attributs, le type des attributs, les valeurs par défaut, les valeurs autorisées, les contraintes, les relations entre les données, la signification des données, etc. Le premier risque est de vouloir satisfaire tous les acteurs en incluant la majorité des attributs des données sources. Les données de référence deviennent alors très détaillées et extrêmement complexes à produire, à maintenir et à utiliser. Le second risque est de créer des données de référence dont l’interprétation n’est pas claire pour tous les utilisateurs. Des techniques telles que la modélisation des données de référence, la constitution d’une ontologie et/ou la constitution d’un glossaire métier sont fortement recommandées afin de minimiser les ambiguïtés et de s’assurer de la convergence des points de vue sur les données de référence.

4.2.2 Standardiser le format d’échange des données de référence

L’étape préalable à l’échange effectif de données est la définition d’un

format standard (généralement basé sur les technologies XML/XSD) qui servira de langage commun pour toutes les applications fournissant ou consommant ces données. L'objectif est de définir un langage commun pour toutes les applications leur permettant de pouvoir comprendre, publier et retraiter les données de référence. Ce langage commun est généralement défini à partir du modèle commun de données et détermine la structure des données et leur format. Deux alternatives sont envisageables pour définir ce type de langage :

1.     le standard est un langage pivot permettant la traduction d’un format de données vers un autre. L’avantage de cette solution est que ce standard reste transparent pour les applications. La solution MDM traduit les données dans le format spécifique à l’application consommatrice.

2.     le standard est un langage commun et la solution MDM fournit simplement les données de référence sous ce format qui devra pouvoir être compris et donc exploité par toutes les applications.

4.2.3 Définir une architecture pour échanger les données de référence

Bien que les solutions MDM puissent prendre de nombreuses formes, la plupart se basent sur les mêmes types d’architectures. Généralement, trois types d’architectures MDM sont privilégiés : le répertoire virtuel (registry), la centralisation (repository) et la coopération (hybrid). Des considérations à la fois techniques et business entrent en ligne de compte dans la sélection d’une architecture. Le critère le plus discriminant est souvent le niveau de contrôle sur les données. L’architecture de centralisation permet un contrôle fin et poussé des données de référence, de leur qualité et de leur intégration. À l’opposé, l’architecture de type répertoire virtuel limite le contrôle aux échanges de données et à la redirection des demandes d’accès vers les données. Entre les deux se situe l’architecture de coopération. Une description de ces architectures ainsi que leurs avantages et inconvénients respectifs ont été détaillés.

4.2.4 Spécifier les contrats d’échange

L’élaboration des contrats d’échange est généralement une étape

obligatoire pour spécifier la qualité des échanges effectués entre les différents partenaires. Ces contrats d’échange déterminent le niveau de service sur lequel s’accordent les parties concernées afin de partager et administrer les données de référence.

4.2.5 Constituer l’infrastructure d’échange des données de référence

Une fois que la phase d’analyse permet d’avoir une vue globale de la

situation et qu’une architecture d’échange a été choisie, il est nécessaire de mettre en place une infrastructure adaptée et efficace. L'objectif est de construire une infrastructure qui supportera l’architecture choisie et satisfera aux exigences notamment en termes de gouvernance, de scalabilité et de reliability. Cette infrastructure se base sur différents outils et technologies :

Ø Gouvernance des données

-                 Modélisation des données et des flux de données

-                 Gestion des processus de validation des données et de gestion des anomalies (Système de workflow et de gestion de règles) Ø Qualité des données

-                 Profiling et Monitoring

-                 Détection des doublons (Matching)

-                 Standardisation

-                 Enrichissement et Intégration

Ø Stockage des données

-         Repository

-         Sécurité

-         Gestion des versions

Ø Distribution des données

-         Data distribution platform

-         Mode Pull ou Push

-         Temps réel ou batch

-         Chiffrement, anonymisation, timestamping, …

-         Accessibilité (UAM), disponibilité, temps de réponse, détection des goulots d'étranglement, …

4.3 Phase d’implémentation

Une fois que l’infrastructure et les outils la supportant sont

opérationnels, il est temps de les utiliser pour produire les données de référence et les partager effectivement entre les différents fournisseurs et consommateurs de données. Ce processus d’implémentation est généralement itératif et a pour objectif final de fournir en output un référentiel de données respectant l’architecture choisie.

4.3.1 Nettoyer et transformer les données sources

L’objectif de cette étape est d’améliorer la qualité des données sources et de se conformer au format standard d’échange défini durant la phase de conception. Le nettoyage et les transformations appliquées aux données sources sont similaires aux opérations d’Extract Transform and Load (ETL) utilisées afin d’alimenter un entrepôt de données. Des exemples typiques de transformations sont la normalisation des formats de date, l’insertion de valeur par défaut, la correction des codes postaux, etc. Le nettoyage comprend également la détection de doublons pouvant faire leur apparition au sein d’une même base de données. La plupart des outils et technologies sont capables d’identifier un grand nombre d’erreurs potentielles. Néanmoins, en ce qui concerne leur correction, seules les plus triviales peuvent être prises en charge de manière automatisée. Certaines erreurs nécessiteront toujours des investigations humaines déterminant les actions à prendre en accord avec le métier. L’utilisation d’outils adaptés à l’analyse de larges bases de données est fortement recommandée, notamment, pour les fonctionnalités liées au data profiling, data standardisation, data matching, data cleansing (cfr Data Quality).

4.3.2 Consolider les données

L'objectif de la consolidation est d’identifier les doublons existant entre différents fournisseurs de données ou au sein du même fournisseur de données pour ensuite les fusionner. La consolidation des doublons est une étape délicate qui doit être menée par le métier et supportée par des outils facilitant l’identification et la résolution des doublons. Des outils sont nécessaires car la phase d’identification peut nécessiter l’analyse et la comparaison de milliers de records.

Néanmoins, même avec des outils, la tâche demeure complexe car si on fusionne trop de données on perd de l’information et, d’un autre côté, si on oublie certains doublons on risque des désynchronisations et l’apparition d’incohérences entre les données utilisées par les différentes applications. Dans tous les cas, les bonnes pratiques préconisent de toujours conserver l’historique des versions afin d’éviter que des opérations de fusionnement ou de défusionnement deviennent irréversibles. De plus, l’élimination des doublons ne suffit pas, il est nécessaire d’étudier comment les relations existant entre les données vont évoluées lors de la consolidation. C’est pourquoi, les algorithmes de matching et d’intégration sont à la fois sophistiqués et complexes.

4.3.3 Constituer le référentiel

Suivant l’architecture et l’infrastructure d’échange choisies, différentes politiques sont envisageables pour constituer un référentiel. Une fois que le nettoyage, la transformation et potentiellement la consolidation des données ont été effectués, il faut déterminer comment elles vont être stockées et rendues disponibles. Les données de référence peuvent être stockées à leur emplacement initial, ou être dupliquées et/ou migrées vers une base de données spécifiquement dédiée au stockage des données de référence. La migration des données de référence n’est pas improbable et, dans ce cas de figure, il est primordial de minimiser les impacts sur les applications sources. Enfin, il faut offrir différents services (Data Services) permettant de consulter les données du référentiel, de les filtrer, de les créer, de les supprimer, de les mettre à jour, de vérifier certaines anomalies (automatiquement ou manuellement), etc.

4.3.4 Tester et évaluer le référentiel

Une fois le référentiel constitué et avant de le mettre en production, il est nécessaire de tester la disponibilité des données, les mécanismes de synchronisation, la charge sur les bus de données, les temps de réponse, la fiabilité. Les utilisateurs de données doivent vérifier que les données qu’ils réceptionnent sont correctement interprétables et contextualisables suivant les besoins qu’ils ont spécifiés. Dans cette étape on ne vérifie pas que l’infrastructure, on vérifie également :

•      la qualité des données et la manière dont elles ont été consolidées,

•      le résultat du nettoyage et de la consolidation et leur conformité par rapport aux attentes des utilisateurs du référentiel,

•      l’utilisabilité du référentiel par rapport aux scénarii d’utilisation et services spécifiés au préalable,

•      la disponibilité des données auprès des fournisseurs de données.

 

4.3.5 Modifier les applications fournisseuses et consommatrices

L'objectif est de faire évoluer les applications fournisseuses et consommatrices en fonction des choix architecturaux et d'infrastructure pour tenir compte du référentiel et satisfaire les contrats d’échanges. Les principales améliorations à apporter sont :

•      La capacité à envoyer et recevoir des messages conformes au standard d’échange communément accepté.

•      La capacité des applications à mettre en place des mécanismes de synchronisation avec les données de référence.

•      La capacité des applications fournisseuses de données à améliorer la qualité de leurs données en interne avant de les exporter vers les données de référence.

•      La capacité des applications a d’abord consulté les données de référence avant de créer un nouveau record.

Captures d’écran prototype

1.     Elaboration du modèle de donnée

 

2.     Elaboration de règles de matching

 

 

3.     Détection de doublons

 

4.     Fusionnement de doublons

 

 

 

5.     Identifications de sources

 

 

 

6.     Historique de transactions

 

7.     Défusionnement de faux positif

 

8.     Définition des sources authentiques

 

 

 

 

Conclusion 

Après notre étude, nous ne constatons que la gouvernance d’un

système d’information à un impact positif sur les organisations. En fait, une bonne gouvernance est un gage pour une contribution optimale des SI aux performances globales de l’entreprise. La gouvernance des SI fait partie intégrante de la gouvernance d’entreprise. Elle vise à définir des objectifs planifier et mesurer les activités liées au SI.

Nous avons vu que la gouvernance d’un système d’information par

l’approche MDM intègre différentes méthodes et technologies afin de limiter la perte de contrôle sur nos données critiques et de rationaliser leur gestion lorsqu’elles sont partagées entre plusieurs applications. 

Le respect des principes MDM et l’utilisation d’un référentiel de données permettrait de se réapproprier ses données métier, de les enrichir et d’assurer leur pérennité, indépendamment des processus qui les manipulent. L’approche MDM permet de mutualiser les efforts pour assurer la synchronisation, le partage et la qualité des données de référence à travers les différents silos d’information en quasi temps réel.

Nous avons élaboré cette solution pour faire l’objet d’amélioration des systèmes d’informations existants au sein des hôpitaux, tout en rendant disponible les informations et les partages des données liées aux patients dans différents sites hospitaliers.

 

 

 

 

 

 

 

BIBLIOGRAPHIE

OUVRAGES

1.     Bonnet, 07 Pierre Bonnet, Master Data Management & SOA, Orchestra Networks, 2007.

2.     Cigref, Alignement stratégique du système d’information (à paraître) Comment faire du système d’information un atout pour l’entreprise ?, publié en 2001-2002.

3.     Cigref (2004), Gouvernance du système d’information, rapports cigref(club d’information des grandes entreprises françaises).

4.     Florecu Vasile, problème de la gouvernance du système d’information, 2006.

5.     Jean-Christophe Trigaux, Master Data Management, décembre 2009.

6.     Jihad Boussay Mohamed talea, Chafik okar, Razane chroqui, Marieme chouki, la gouvernance des systèmes d’information et son impact sur les organisations, avril 2017.

7.     Laurence Dubrovin, Synthèse et perspective, gestion de données de référence. JEMM research, 2008.

8.     Place de la gouvernance du SI dans la gouvernance générale de l'entreprise /CIGREF, AFAI. – 2005

9.     Pirmin Lemberger, Big Data et machine learning Dunod 2015.

10.          Pr Fatima Bouyahia, introduction aux systèmes d’information de l’entreprise, faculté des sciences semlalia-Marakkech.

11.          Rudi Bruchez, les bases de données NoSQL et le big data,avril 2013.

NOTES DES COURS

12.          Pierre KAFUNDA KATALAYI, gestion d’info centre, cours inédit en Deuxième Licence, informatique, gestion, UNIKIN, 2017-2018.

13.          KASORO MULENDA, analyse de données, cours inédit Deuxième Licence, Informatique Gestion, Faculté des Sciences, Unikin, 2017-2018

THESE

14.          Claudepierre B., Conceptualisation de la Gouvernance des Systèmes d'Information : Structure et Démarche pour la Construction des Systèmes d'Information de Gouvernance, Thèse de doctorat de l’Université Paris I,

2010

INTERNET

15.          http : // www.wikipedia.com, (25/03/2019)

16.          http:// www.itgovernance.org, (05/05/2019)

17.          http:// www.isaca.org, (05/05/2019)

18.          http:// www.itgi.org, (05/05/2019)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

TABLE DES MATIERES

INTRODUCTION GENERALE .................................................................................... x

PROBLEMATIQUE ................................................................................................ x

INTERET DU SUJET ............................................................................................... xi

TECHNIQUES ....................................................................................................... xi

Méthodologie du travail ..................................................................................... xii

PLAN DU TRAVAIL ............................................................................................... xii

CHAPITRE I.  GENERALITES SUR LE SYSTEME D'INFORMATION [10] [15] .............. xiii

Introduction ...................................................................................................... xiii

I.1 Système ........................................................................................................ xiii

I.1.2 Information ............................................................................................ xiv

I.1.2.1 Donnée et information .................................................................... xiv

I.1.3 Classification des informations ............................................................... xv

I.1.4. Mémorisation de l’information ............................................................. xv

I.1.5 Traitement de l’information .................................................................. xvi

I.1.6 Diffusion de l’information ...................................................................... xvi

I.1.7 Système d’information .......................................................................... xvi

I.2 Enjeux du système d'information ............................................................... xviii

I.2.1 Les différentes natures du système d'information ............................. xviii

I.2.1.1 Système d'information et finalité de la chose ............................... xviii

I.2.1.2 Système d'information et application informatique ....................... xix

I.3. Composition d'un système d'information d'entreprise ................................ xx

I.3.1. Composition classique ........................................................................... xx

I.3.2. Composition actuelle ............................................................................ xxi

I.3.3. Évolution de la composition du système d'information ...................... xxii

I.3.4. Autres composants possibles ............................................................. xxiv

I.4. Systèmes d'information et développement durable ................................. xxiv

CHAPITRE II : BONNE GOUVERNANCE ET MDM ................................................. xxvi

II.1 Bonne gouvernance .................................................................................. xxvi II.1.1 Qu’est-ce que la gouvernance ? ......................................................... xxvi

II.1.2 Définition de la gouvernance du système d’information ................... xxvi

II.1.3 Pourquoi le système d’information a-t-il besoin de gouvernance ? . xxvii

II.1.4 Les principes de la bonne gouvernance du système d’information…….  ..................................................................................................................... xxix

II.1.5 Les quatre piliers de la gouvernance d’un système d’information ..... xxx

II.1.5.1 Gouverner, c’est anticiper et connaitre ........................................ xxx

II.1.5.2 Gouverner, c’est décider .............................................................. xxxi

II.1.5.3 Gouverner, c’est communiquer et suivre .................................... xxxi

II.1.5.4 Gouverner, c’est adapter ............................................................. xxxi

II.2 MDM ......................................................................................................... xxxi

II.2.1 Qu’est-ce que l’approche MDM ? ..................................................... xxxii

II.2.2 Pourquoi utiliser l’approche MDM ................................................... xxxiii

II.2.3 Les concepts fondamentaux du mdm .............................................. xxxiv

II.2.3.1Qu’est-ce qu’une donnée de référence ? .................................. xxxiv

II.2.3.2Qu’est-ce que la gestion de donnée de référence ? ................... xxxv

II.2.4 Les architecture MDM ...................................................................... xxxvi

II.2.4.1Le répertoire virtuel .................................................................. xxxvii

II.2.4.2Centralisation (Repository) ........................................................ xxxvii

II.2.4.3Coopération (Hybrid) ................................................................. xxxviii

II.2.5 Les différents types de MDM ........................................................... xxxix

II.2.5.1MDM opérationnel (O-MDM) .................................................... xxxix

II.2.5.2MDM analytique (A-MDM) .............................................................. xl

II.2.5.3MDM d’entreprise ou collaboratif (C-MDM) ................................... xl

CHAPITRE III : LES BIG DATA .................................................................................. xli

III.1 Présentation ................................................................................................ xli

III.2 Définition du Big Data .................................................................................. xli

III.3 Caractéristique des Big Data ....................................................................... xlii

III.4 Les Big Data en chiffre ................................................................................ xlii

III.5 Interets du Big Data ................................................................................... xliii III.6 Enjeux des Big Data ................................................................................... xliii

III.6.1 Enjeux techniques............................................................................... xliii

III.6.2 Enjeux économiques........................................................................... xliii

III.6.3 Enjeux juridique .................................................................................. xliv

III.7 Limites des Big Data................................................................................... xliv

III.8 Paysage technologique des Big Data ......................................................... xliv

III.8.1 Intégration ........................................................................................... xlv

III.8.2 Stockage .............................................................................................. xlv

III.8.3 Analyse................................................................................................ xlvi

III.8.4 Restitution .......................................................................................... xlvi

III.9 Ecosystème Hadoop .................................................................................. xlvi

III.9.1 Hadoop Kernel ................................................................................... xlvii

III.9.1.1Architecture Hadoop .................................................................. xlviii

III.9.1.2HDFS ............................................................................................. xlix

III.9.1.3MapReduce .................................................................................. xlix

III.9.1.4Modes d’utilisations ......................................................................... l

III.9.2 Composants Apache Hadoop ................................................................ li

III.9.2.1     Hbase ............................................................................................... li

III.9.2.2     Hcatalog ........................................................................................... li

III.9.2.3     Hive .................................................................................................. li

III.9.2.4     Pig ................................................................................................... lii

III.9.2.5     Sqoop .............................................................................................. lii

III.9.2.6     Flume .............................................................................................. lii

III.9.2.7     Oozie ...............................................................................................liii

III.9.2.8     Zookeeper ......................................................................................liii

III.9.2.9     Ambari ............................................................................................liii

III.9.2.10              Mahout .........................................................................................liii

III.9.2.11              Avro ..............................................................................................liii

CHAPITRE IV : MISE EN PLACE ............................................................................... liv

4.1. Phase d’analyse ........................................................................................... lvi

4.1.1 Identifier et décrire les données de référence ......................................lvi

4.1.2 Déterminer les méthodes et les règles de gouvernance ...................... lvii

4.1.3 Mettre en place une organisation pour gérer les données de référence  ...................................................................................................................... lviii

4.2 Phase de conception ..................................................................................... lx

4.2.1 Définir un modèle commun de référence ............................................. lx

4.2.2 Standardiser le format d’échange des données de référence .............. lx

4.2.3 Définir une architecture pour échanger les données de référence ...... lxi

4.2.4 Spécifier les contrats d’échange ............................................................ lxi

4.2.5 Constituer l’infrastructure d’échange des données de référence ........ lxi

4.3 Phase d’implémentation ............................................................................. lxii

4.3.1 Nettoyer et transformer les données sources ..................................... lxii

4.3.2 Consolider les données ....................................................................... lxiii

4.3.3 Constituer le référentiel ...................................................................... lxiii

4.3.4 Tester et évaluer le référentiel ............................................................ lxiv

4.3.5 Modifier les applications fournisseuses et consommatrices............... lxiv

Conclusion ........................................................................................................... lxix

BIBLIOGRAPHIE ..................................................................................................... lxx

TABLE DES MATIERES …………………………………………………………………………………..….64

 

Travail Disponible en pdf sur demande