### 5.2.1 Les approches préventives

Ces approches s'appuient sur l'ingénierie des systèmes d'information et le contrôle des processus. Elles utilisent des techniques permettant d'évaluer la qualité des modèles conceptuels de données, des développements logiciels et des processus traitant les données. Elles effectuent en amont du stockage des données, des évaluations au niveau des modèles et des processus mis en uvre.

### 5.2.2 Les approches diagnostiques

Ces approches s'appuient principalement sur des méthodes statistiques, d'analyse et de fouille de données exploratoire pour détecter les anomalies dans les données et notamment les erreurs présentes dans de grandes quantités de données.

### 5.2.3 Les approches correctives

Elles essaient de détecter les erreurs en les comparant à des valeurs issues de la réalité (dites "données de terrain") et proposent des corrections. Ces approches sont basées sur des techniques de nettoyage et de consolidation de données, elles utilisent en particulier des langages de manipulation des données étendus et des outils de type ETL.

### 5.2.4 Les approches adaptatives

Ces approches, dites aussi actives, proposent des traitements dynamiques de vérification en temps réel de contraintes garantissant la qualité des données. Elles sont généralement appliquées lors de la médiation ou l'intégration de données.

## 5.3 La gouvernance

Une fois les premières étapes de la mise en place d'une approche de la gestion de la qualité des données réalisées :

- définition de la mesure de la qualité des données,

- choix des indicateurs pour mesurer la qualité,

- mesures et analyse des résultats,

il faut définir des plans d'action à mettre en oeuvre pour corriger la situation. Ici intervient un paramètre dont nous n'avons pas parlé jusqu'à présent : **la gouvernance**. Il faut ainsi formaliser un modèle de pilotage des acteurs, processus et techniques pour assurer la maitrise des données de l'entreprise.

Une telle démarche doit être poussée par la direction et voir l'implication de tous les acteurs de l'entreprise. Il est important de créer un **comité Qualité des données**, sous la responsabilité d'un membre de la direction, qui porte la responsabilité de la qualité des données.

Ce comité doit être composé de correspondants représentant chaque partie de l'entreprise et qui sont responsables des données relevant de leur domaine, ainsi que de la définition des mesures et indicateurs de qualité de leur service (règles métier). Un analyste s'occupe alors de la mise en oeuvre des règles métiers dans des outils de profilage et de nettoyage.
## 5.4 Les outils de gestion de la qualité des données

La mise en place d'une gestion de la qualité des données passe par la mise en place de solutions technologiques ([9]) qui doivent permettre :

- de faire des diagnostics et d'évaluer les problèmes de qualité,

- de supporter l'intégration de données,

- d'automatiser le traitement des erreurs dans les processus d'extraction et de rechargement de données,

- définir un framework pour capturer et gérer les erreurs liées à la mauvaise qualité des données,

- de fournir un cadre pour mesurer l'évolution des indicateurs dans le temps,

- de fournir des indicateurs de qualité sur les données utilisées.

Les solutions technologiques de gestion de qualité des données se basent sur des outils qui permettent de réaliser du profilage, de la standardisation, du nettoyage, du rapprochement, de l'enrichissement, de la décomposition et de la surveillance.

### 5.4.1 Le profilage ou *Profiling*

Le profilage est le processus qui consiste à récolter les données dans les différentes sources de données existantes (bases de données, fichiers,...) et à collecter des statistiques et des informations sur ces données.

Plus précisément, les résultats d'un profilage permettent de définir des indicateurs clés associés aux valeurs de chaque donnée, tel que le nombre et le pourcentage de champs nuls ou remplis, le nombre de valeurs uniques, le nombre de fréquences pour chaque valeur et les patterns, les valeurs maximales ou minimales, l'information sur le type de la donnée et la longueur des chaînes de caractères. On peut même obtenir un niveau de détails supplémentaires sur les dépendances entre les colonnes et les relations entre tables, notamment.

L'objectif est d'identifier les anomalies ou partager les spécificités des éléments des données telles que :

- des valeurs manquantes,

- des valeurs présentes mais qui auraient dû être absentes,

- des valeurs qui apparaissent à une fréquence imprévues, qu'elle soit basse ou haute,

- des valeurs qui ne respectent pas un pattern ou un format donné,

- des données aberrantes qui sont bien trop basses ou trop élevées pour la plage définie.

Le profilage est assez proche de l'analyse des données. Il permet d'analyser la qualité des données afin de définir les domaines d'amélioration en étudiant la structure des tables et les relations entre les tables, la pertinence des données (colonnes utilisées, poids des colonnes vides...) et la validité de formats (adresses, informations d'identification...).

Il a pour objectif :

- d'identifier les données réutilisables pour d'autres fins ;

- d'avoir des mesures sur la qualité des données et sur la conformité par rapport aux standards de l'entreprise ;

- d'évaluer les risques engendrés par l'intégration de ces données dans de nouvelles applications ;
## 5.4 Les outils de gestion de la qualité des données

La mise en place d'une gestion de la qualité des données passe par la mise en place de solutions technologiques ([9]) qui doivent permettre :

- de faire des diagnostics et d'évaluer les problèmes de qualité,

- de supporter l'intégration de données,

- d'automatiser le traitement des erreurs dans les processus d'extraction et de rechargement de données,

- définir un framework pour capturer et gérer les erreurs liées à la mauvaise qualité des données,

- de fournir un cadre pour mesurer l'évolution des indicateurs dans le temps,

- de fournir des indicateurs de qualité sur les données utilisées.

Les solutions technologiques de gestion de qualité des données se basent sur des outils qui permettent de réaliser du profilage, de la standardisation, du nettoyage, du rapprochement, de l'enrichissement, de la décomposition et de la surveillance.

### 5.4.1 Le profilage ou *Profiling*

Le profilage est le processus qui consiste à récolter les données dans les différentes sources de données existantes (bases de données, fichiers,...) et à collecter des statistiques et des informations sur ces données.

Plus précisément, les résultats d'un profilage permettent de définir des indicateurs clés associés aux valeurs de chaque donnée, tel que le nombre et le pourcentage de champs nuls ou remplis, le nombre de valeurs uniques, le nombre de fréquences pour chaque valeur et les patterns, les valeurs maximales ou minimales, l'information sur le type de la donnée et la longueur des chaînes de caractères. On peut même obtenir un niveau de détails supplémentaires sur les dépendances entre les colonnes et les relations entre tables, notamment.

L'objectif est d'identifier les anomalies ou partager les spécificités des éléments des données telles que :

- des valeurs manquantes,

- des valeurs présentes mais qui auraient dû être absentes,

- des valeurs qui apparaissent à une fréquence imprévues, qu'elle soit basse ou haute,

- des valeurs qui ne respectent pas un pattern ou un format donné,

- des données aberrantes qui sont bien trop basses ou trop élevées pour la plage définie.

Le profilage est assez proche de l'analyse des données. Il permet d'analyser la qualité des données afin de définir les domaines d'amélioration en étudiant la structure des tables et les relations entre les tables, la pertinence des données (colonnes utilisées, poids des colonnes vides...) et la validité de formats (adresses, informations d'identification...).

Il a pour objectif :

- d'identifier les données réutilisables pour d'autres fins ;

- d'avoir des mesures sur la qualité des données et sur la conformité par rapport aux standards de l'entreprise ;

- d'évaluer les risques engendrés par l'intégration de ces données dans de nouvelles applications ;
- d'évaluer si les métadonnées décrivent correctement les données sources ;

- d'avoir une bonne compréhension de l'enjeu des données sources sur les projets à venir afin d'anticiper de mauvaises surprises ;

- d'avoir une vue globale des données pour permettre la gestion des données de référence ou la gouvernance des données afin de renforcer la qualité des données.

## 5.4.2 La standardisation

La standardisation des données a pour objectif d'assurer une interoperabilité optimale des données, en vue de leur réutilisation. En utilisant les règles métiers on automatise le processus de vérification et de correction des données afin notamment que les données soient correctement orthographiées, que les abréviations soient standardisées et que les modèles de formatage soient correctement utilisés.

Il existe tout un éventail de normes ISO, prévues pour un usage général dans les divers domaines scientifiques et techniques :

- Références bibliographiques (ISO 690:2010) : donne des principes directeurs pour la rédaction des références bibliographiques, en organisant un ordre dans les mentions. Exemple pour un livre : Nom, Prénom. Titre. Édition, collection, année.

- Représentation des pays (ISO 3166-3:2013) : énonce les principes pour une représentation des pays, BE pour Belgique, FR pour France ...

- Représentation des monnaies (ISO 4217:2015) : définit le code de trois lettres attribué aux devises dans le monde, EUR pour l'euro, USD pour le dollar américain, ...

- Représentation normalisée de la localisation des points géographiques par coordonnées (ISO 6709:2008): spécifie notamment la représentation des coordonnées, dont la latitude et la longitude, utilisées pour l'échange de données.

- ...

## 5.4.3 Le nettoyage ou *Cleansing*

Il permet de détecter et corriger les données corrompues ou inexactes. L'objectif du nettoyage est de rendre la source de données cohérente avec les autres sources de données de l'entreprise. Ce type d'opération est effectué a postériori sur les données contrairement à la standardisation qui a lieu lors de la saisie des données.

## 5.4.4 Le rapprochement ou *Matching*

Il s'agit de comparer et rapprocher des données de sources différentes pour détecter d'éventuels doublons dans de grands ensembles de données que ce soit dans une ou plusieurs bases de données.

Après avoir identifié les doublons, ou les doublons possibles, le rapprochement de données permet d'appliquer des mesures telles que la fusion des deux entrées identiques ou similaires en une seule. Il permet aussi d'identifier les non-duplicatas, ce qui peut être important pour savoir que deux données similaires ne sont pas les mêmes.
- d'évaluer si les métadonnées décrivent correctement les données sources ;

- d'avoir une bonne compréhension de l'enjeu des données sources sur les projets à venir afin d'anticiper de mauvaises surprises ;

- d'avoir une vue globale des données pour permettre la gestion des données de référence ou la gouvernance des données afin de renforcer la qualité des données.

## 5.4.2 La standardisation

La standardisation des données a pour objectif d'assurer une interoperabilité optimale des données, en vue de leur réutilisation. En utilisant les règles métiers on automatise le processus de vérification et de correction des données afin notamment que les données soient correctement orthographiées, que les abréviations soient standardisées et que les modèles de formatage soient correctement utilisés.

Il existe tout un éventail de normes ISO, prévues pour un usage général dans les divers domaines scientifiques et techniques :

- Références bibliographiques (ISO 690:2010) : donne des principes directeurs pour la rédaction des références bibliographiques, en organisant un ordre dans les mentions. Exemple pour un livre : Nom, Prénom. Titre. Édition, collection, année.

- Représentation des pays (ISO 3166-3:2013) : énonce les principes pour une représentation des pays, BE pour Belgique, FR pour France ...

- Représentation des monnaies (ISO 4217:2015) : définit le code de trois lettres attribué aux devises dans le monde, EUR pour l'euro, USD pour le dollar américain, ...

- Représentation normalisée de la localisation des points géographiques par coordonnées (ISO 6709:2008): spécifie notamment la représentation des coordonnées, dont la latitude et la longitude, utilisées pour l'échange de données.

- ...

## 5.4.3 Le nettoyage ou *Cleansing*

Il permet de détecter et corriger les données corrompues ou inexactes. L'objectif du nettoyage est de rendre la source de données cohérente avec les autres sources de données de l'entreprise. Ce type d'opération est effectué a postériori sur les données contrairement à la standardisation qui a lieu lors de la saisie des données.

## 5.4.4 Le rapprochement ou *Matching*

Il s'agit de comparer et rapprocher des données de sources différentes pour détecter d'éventuels doublons dans de grands ensembles de données que ce soit dans une ou plusieurs bases de données.

Après avoir identifié les doublons, ou les doublons possibles, le rapprochement de données permet d'appliquer des mesures telles que la fusion des deux entrées identiques ou similaires en une seule. Il permet aussi d'identifier les non-duplicatas, ce qui peut être important pour savoir que deux données similaires ne sont pas les mêmes.
### 5.4.5 L'enrichissement

Il utilise des sources externes pour compléter les données. L'objectif de l'enrichissement de données est de rechercher le plus grand nombre de données, sans aucun a priori, afin de permettre aux algorithmes la découverte de corrélations qui nont pas pu être observées jusque-là. Des données qui semblent pour certaines sans relation avec d'autres peuvent se révéler fondamentales dans les résultats obtenus. Il est donc important d'enrichir les données avec tous types de données, sans aucune limite et a priori.

### 5.4.6 La décomposition ou Parsing

Permet l'identification, la vérification et la décomposition des éléments des zones de saisie libre un par un. Le parsing consiste à analyser un flux de caractères en entrée et à le segmenter en éléments caractéristiques plus petits (adresse, nom, ...).

### 5.4.7 La surveillance ou Monitoring

Elle permet d'identifier les problèmes et de réagir avant qu'ils ne génèrent des non-qualités. Cette solution permet de suivre l'évolution des données dans le temps, d'identifier les tendances et d'alerter sur la violation de règles de qualité.

## 5.5 Quelques bonnes pratiques

Pour obtenir et conserver des données de qualité, il est important d'adopter quelques bonnes pratiques pour la définition, la création et la mise à jour des données ([4]). Ci-dessous sont présentés quelques exemples classiques et relativement simples de bonnes pratiques pour assurer la qualité des données.

### 5.5.1 La compréhension des besoins

La base de toute activité de conception ou de maintenance d'un système d'information est une bonne compréhension des besoins des utilisateurs. L'analyse et la formalisation des besoins est une phase essentielle ; l'utilisation de diagrammes et de modèles permet de formaliser et valider les besoins des utilisateurs.

L'une des difficultés de cette étape est le dialogue entre les utilisateurs et les informaticiens. Les premiers possèdent une expertise dans leur domaine, mais ne savent pas toujours exprimer formellement leurs besoins. Les informaticiens doivent poser des questions et reformuler les réponses.

Lors de l'étape d'expression des besoins, il est important d'essayer d'avoir une vision globale d'un processus et se focaliser sur ce qui est important, d'autre part il faut chercher à simplifier et éviter la construction de solutions trop complexes de type "usines à gaz". Il faut de plus éliminer les étapes sans valeur ajoutée, identifier les cas d'erreurs possibles et les exprimer clairement, penser les données dès la conception de la solution et consacrer du temps à la documentation.
### 5.4.5 L'enrichissement

Il utilise des sources externes pour compléter les données. L'objectif de l'enrichissement de données est de rechercher le plus grand nombre de données, sans aucun a priori, afin de permettre aux algorithmes la découverte de corrélations qui nont pas pu être observées jusque-là. Des données qui semblent pour certaines sans relation avec d'autres peuvent se révéler fondamentales dans les résultats obtenus. Il est donc important d'enrichir les données avec tous types de données, sans aucune limite et a priori.

### 5.4.6 La décomposition ou Parsing

Permet l'identification, la vérification et la décomposition des éléments des zones de saisie libre un par un. Le parsing consiste à analyser un flux de caractères en entrée et à le segmenter en éléments caractéristiques plus petits (adresse, nom, ...).

### 5.4.7 La surveillance ou Monitoring

Elle permet d'identifier les problèmes et de réagir avant qu'ils ne génèrent des non-qualités. Cette solution permet de suivre l'évolution des données dans le temps, d'identifier les tendances et d'alerter sur la violation de règles de qualité.

## 5.5 Quelques bonnes pratiques

Pour obtenir et conserver des données de qualité, il est important d'adopter quelques bonnes pratiques pour la définition, la création et la mise à jour des données ([4]). Ci-dessous sont présentés quelques exemples classiques et relativement simples de bonnes pratiques pour assurer la qualité des données.

### 5.5.1 La compréhension des besoins

La base de toute activité de conception ou de maintenance d'un système d'information est une bonne compréhension des besoins des utilisateurs. L'analyse et la formalisation des besoins est une phase essentielle ; l'utilisation de diagrammes et de modèles permet de formaliser et valider les besoins des utilisateurs.

L'une des difficultés de cette étape est le dialogue entre les utilisateurs et les informaticiens. Les premiers possèdent une expertise dans leur domaine, mais ne savent pas toujours exprimer formellement leurs besoins. Les informaticiens doivent poser des questions et reformuler les réponses.

Lors de l'étape d'expression des besoins, il est important d'essayer d'avoir une vision globale d'un processus et se focaliser sur ce qui est important, d'autre part il faut chercher à simplifier et éviter la construction de solutions trop complexes de type "usines à gaz". Il faut de plus éliminer les étapes sans valeur ajoutée, identifier les cas d'erreurs possibles et les exprimer clairement, penser les données dès la conception de la solution et consacrer du temps à la documentation.
### 5.5.2 La codification des données

La codification permet de définir le format et les valeurs possibles des données (attributs).

Elle doit être effectuée avec soin et en tenant compte des évolutions possibles du système d'information.

Il est important de s'appuyer sur des normes lorsqu'il en existe (ISO 80000-3:2006 pour les mesures, ISO 3166 pour les codes de pays, ...). L'utilisation de normes permet l'usage d'un langage reconnu par la communauté et facilite les échanges de données entre systèmes.

Il faut veiller, entre autres, à :

- bien structurer des éléments tels que les adresses et tenir compte des normes dans les différents pays ;

- éviter les codes mnémoniques qui constituent des codifications peu évolutives et ne peuvent se substituer à un descriptif de l'entité qu'ils identifient ;

- définir des règles claires et simples pour les descriptions et libellés. Il faut notamment éviter les abréviations ;

- prendre en compte les aspects multi-langues. En particulier la codification des entités doit pouvoir être reconnue par tous les utilisateurs quelque soit leur pays.

### 5.5.3 La documentation des données

Il est important de documenter l'ensemble des données, de décrire leur utilisation et leurs principales règles de gestion.

Pour chaque donnée on peut décrire : sa définition, l'utilisation qui en est faite, ses grandes règles de gestion, sa codification et ses contraintes particulières. L'intérêt d'une telle documentation est de centraliser les informations sur les données du système et de pouvoir les mettre à disposition des informaticiens et des utilisateurs. Elle permettra notamment, en termes de qualité de données, de comparer la représentation et la réalité.

### 5.5.4 L'administration des données

Lors de la mise en place d'une application il est important de définir les procédures de gestion des données et de préciser qui fait quoi.

Il faut ainsi prendre en compte : l'architecture logique de l'application et l'organisation des données. L'architecture logique définit les systèmes logiques nécessaires au fonctionnement des différentes applications. Ainsi, si une application doit être implantée dans différents systèmes, il peut être intéressant de mettre en place un système de données de référence qui centralise les données communes à ces systèmes.

### 5.5.5 L'organisation de la gestion des données

Il faut ici définir les acteurs qui maintiennent les données et décrire les procédures de gestion des données. En général, on essaie de déléguer la gestion des données à leurs utilisateurs naturels.

Par contre dans le cas des données de référence qui sont centralisées, il faut définir proprement quels acteurs peuvent créer, modifier, supprimer une donnée, sous quelles conditions et comment on peut mettre en place des contrôles pour vérifier la correction de ces données.

Toutes les données au sein d'une entreprise ne peuvent pas être centralisées il faut donc étudier chaque type de donnée pour décider ou non de sa centralisation. Le tableau 5.2 présente les
### 5.5.2 La codification des données

La codification permet de définir le format et les valeurs possibles des données (attributs).

Elle doit être effectuée avec soin et en tenant compte des évolutions possibles du système d'information.

Il est important de s'appuyer sur des normes lorsqu'il en existe (ISO 80000-3:2006 pour les mesures, ISO 3166 pour les codes de pays, ...). L'utilisation de normes permet l'usage d'un langage reconnu par la communauté et facilite les échanges de données entre systèmes.

Il faut veiller, entre autres, à :

- bien structurer des éléments tels que les adresses et tenir compte des normes dans les différents pays ;

- éviter les codes mnémoniques qui constituent des codifications peu évolutives et ne peuvent se substituer à un descriptif de l'entité qu'ils identifient ;

- définir des règles claires et simples pour les descriptions et libellés. Il faut notamment éviter les abréviations ;

- prendre en compte les aspects multi-langues. En particulier la codification des entités doit pouvoir être reconnue par tous les utilisateurs quelque soit leur pays.

### 5.5.3 La documentation des données

Il est important de documenter l'ensemble des données, de décrire leur utilisation et leurs principales règles de gestion.

Pour chaque donnée on peut décrire : sa définition, l'utilisation qui en est faite, ses grandes règles de gestion, sa codification et ses contraintes particulières. L'intérêt d'une telle documentation est de centraliser les informations sur les données du système et de pouvoir les mettre à disposition des informaticiens et des utilisateurs. Elle permettra notamment, en termes de qualité de données, de comparer la représentation et la réalité.

### 5.5.4 L'administration des données

Lors de la mise en place d'une application il est important de définir les procédures de gestion des données et de préciser qui fait quoi.

Il faut ainsi prendre en compte : l'architecture logique de l'application et l'organisation des données. L'architecture logique définit les systèmes logiques nécessaires au fonctionnement des différentes applications. Ainsi, si une application doit être implantée dans différents systèmes, il peut être intéressant de mettre en place un système de données de référence qui centralise les données communes à ces systèmes.

### 5.5.5 L'organisation de la gestion des données

Il faut ici définir les acteurs qui maintiennent les données et décrire les procédures de gestion des données. En général, on essaie de déléguer la gestion des données à leurs utilisateurs naturels.

Par contre dans le cas des données de référence qui sont centralisées, il faut définir proprement quels acteurs peuvent créer, modifier, supprimer une donnée, sous quelles conditions et comment on peut mettre en place des contrôles pour vérifier la correction de ces données.

Toutes les données au sein d'une entreprise ne peuvent pas être centralisées il faut donc étudier chaque type de donnée pour décider ou non de sa centralisation. Le tableau 5.2 présente les
avantages et inconvénients d'une gestion centralisée ou décentralisée des données au sein d'un système.

<table><caption>Table 5.2 : Gestion centralisée versus gestion décentralisée de la donnée</caption><thead><tr><th>Gestion</th><th>Avantages</th><th>Inconvénients</th></tr></thead><tbody><tr><td>Centralisée</td><td>- Respect des normes<br>- Evite les doublons<br>- Allège le travail</td><td>- Réactivité<br>- Coût (besoin d'une équipe dédiée)</td></tr><tr><td>Décentralisée</td><td>- Réactivité<br>- Autonomie<br>- Meilleure appropriation de la donnée par l'utilisateur</td><td>- Risque de dériver (langage commun)<br>- Risque de doublon accru<br>- Pollution de la BD (doublons, ...)</td></tr></tbody></table>

## 5.6 Exemples d'approches

Divers organismes, entreprises, ... ont défini des cadres de référence qui permettent de mettre en place des principes de gestion de la qualité des données selon une méthode clairement définie. Chacun de ces cadres contient des solutions qui lui sont propres, mais plusieurs contiennent également des méthodes communes qui peuvent, de ce fait, être considérées comme des incontournables en qualité de données. Le but recherché par ces cadres de référence est habituellement de contrôler la qualité des données comprises dans les systèmes d'information. Pour en arriver à ce contrôle, plusieurs activités sont nécessaires.

Les dimensions qui ont été présentés dans une deuxième partie de ce cours ne sont pas utilisées dans toutes les approches présentées, ou en tout cas pas nommées dimension.

### 5.6.1 TDQM

Le modèle TDQM ou Total Data Quality Management est une adaptation de la gestion totale de la qualité (TQM) de Deming adaptée aux données. Elle a été développée dans les années 90 au MIT (Massachusetts Institute of Technology). Les données ont leur propre cycle pour la qualité : définies, mesurées, analysées et améliorées. Ce modèle propose un parallèle entre la fabrication d'un produit physique et la fabrication d'une donnée qui est traitée comme un produit.

La première étape de cette méthode comprend des phases telles que :

1. identifier les dimensions clés ;

2. donner des définitions précises et significatives pour chacune des dimensions ;

3. définir les mesures de ces dimensions ;

4. développer un algorithme pour calculer la qualité des données.

Quinze dimensions sont utilisées et réparties en quatre catégories (intrinsèque, accessibilité, contextuelle et représentationnelle).
avantages et inconvénients d'une gestion centralisée ou décentralisée des données au sein d'un système.

<table><caption>Table 5.2 : Gestion centralisée versus gestion décentralisée de la donnée</caption><thead><tr><th>Gestion</th><th>Avantages</th><th>Inconvénients</th></tr></thead><tbody><tr><td>Centralisée</td><td>- Respect des normes<br>- Evite les doublons<br>- Allège le travail</td><td>- Réactivité<br>- Coût (besoin d'une équipe dédiée)</td></tr><tr><td>Décentralisée</td><td>- Réactivité<br>- Autonomie<br>- Meilleure appropriation de la donnée par l'utilisateur</td><td>- Risque de dériver (langage commun)<br>- Risque de doublon accru<br>- Pollution de la BD (doublons, ...)</td></tr></tbody></table>

## 5.6 Exemples d'approches

Divers organismes, entreprises, ... ont défini des cadres de référence qui permettent de mettre en place des principes de gestion de la qualité des données selon une méthode clairement définie. Chacun de ces cadres contient des solutions qui lui sont propres, mais plusieurs contiennent également des méthodes communes qui peuvent, de ce fait, être considérées comme des incontournables en qualité de données. Le but recherché par ces cadres de référence est habituellement de contrôler la qualité des données comprises dans les systèmes d'information. Pour en arriver à ce contrôle, plusieurs activités sont nécessaires.

Les dimensions qui ont été présentés dans une deuxième partie de ce cours ne sont pas utilisées dans toutes les approches présentées, ou en tout cas pas nommées dimension.

### 5.6.1 TDQM

Le modèle TDQM ou Total Data Quality Management est une adaptation de la gestion totale de la qualité (TQM) de Deming adaptée aux données. Elle a été développée dans les années 90 au MIT (Massachusetts Institute of Technology). Les données ont leur propre cycle pour la qualité : définies, mesurées, analysées et améliorées. Ce modèle propose un parallèle entre la fabrication d'un produit physique et la fabrication d'une donnée qui est traitée comme un produit.

La première étape de cette méthode comprend des phases telles que :

1. identifier les dimensions clés ;

2. donner des définitions précises et significatives pour chacune des dimensions ;

3. définir les mesures de ces dimensions ;

4. développer un algorithme pour calculer la qualité des données.

Quinze dimensions sont utilisées et réparties en quatre catégories (intrinsèque, accessibilité, contextuelle et représentationnelle).
### 5.6.2 TIQM

Cette méthode est inspirée de la proposition de Deming concernant la qualité qui présente une liste de 14 recommandations en gestion. Elle créé une correspondance de ses processus sur les méthodes : 1) définir; 2) mesurer; 3) analyser; 4) améliorer; 5) contrôler. Elle se caractérise par cinq étapes distinctes de mesures et d'amélioration ainsi que par un procédé général qui permet de suivre et de gérer l'ensemble du projet. On utilise des catégories pour identifier les problèmes de qualité. Dans chacune de ces catégories, on utilise des attributs similaires aux dimensions. Les attributs tels que la précision, la cohérence, la validité, la complétude et l'unicité sont fréquemment utilisés.

### 5.6.3 ICIS

L'Institut canadien d'information sur la santé est considéré comme un pionnier dans les techniques de gestion de la qualité des données dans le milieu de la santé [12]. Il a mis en place, dans les années 2000, un cadre sur la qualité des données. Ce cadre comprend un outil d'évaluation qui permet de mesurer et de documenter les limites et les forces comprises dans les banques de données de l'ICIS. Cet outil d'évaluation utilise cinq dimensions pour lesquelles 19 caractéristiques et 61 critères ont été définis. Les dimensions utilisées sont l'exactitude, l'actualité, la comparabilité, la facilité d'utilisation et la pertinence.

### 5.6.4 MDM

L'approche MDM, *Master Data Management* ou Gestion des données de référence, permet de mettre en place un référentiel de données transversales ainsi qu'une organisation adaptée qui permet de gérer ces données. L'objectif est de mutualiser les efforts et d'assurer la synchronisation, le partage et le contrôle des données de référence.

## 5.7 En résumé

La gestion de la qualité des données n'est pas en soi une tâche insurmontable mais elle nécessite des qualités particulières que ce soit chez les informaticiens ou dans toute l'organisation. Outre la compétence en informatique, l'une des qualités les plus recherchées chez un informaticien est l'aptitude à communiquer et éventuellement l'association avec une compétence métier (production, environnement, ...).

"Il ne faut pas sous-estimer l'élégance toute simple de l'amélioration de la qualité. Outre le travail en équipe, la formation et la rigueur, elle n'exige pas de talents particuliers. Quiconque le veut peut en être un contributeur efficace." [12].
### 5.6.2 TIQM

Cette méthode est inspirée de la proposition de Deming concernant la qualité qui présente une liste de 14 recommandations en gestion. Elle créé une correspondance de ses processus sur les méthodes : 1) définir; 2) mesurer; 3) analyser; 4) améliorer; 5) contrôler. Elle se caractérise par cinq étapes distinctes de mesures et d'amélioration ainsi que par un procédé général qui permet de suivre et de gérer l'ensemble du projet. On utilise des catégories pour identifier les problèmes de qualité. Dans chacune de ces catégories, on utilise des attributs similaires aux dimensions. Les attributs tels que la précision, la cohérence, la validité, la complétude et l'unicité sont fréquemment utilisés.

### 5.6.3 ICIS

L'Institut canadien d'information sur la santé est considéré comme un pionnier dans les techniques de gestion de la qualité des données dans le milieu de la santé [12]. Il a mis en place, dans les années 2000, un cadre sur la qualité des données. Ce cadre comprend un outil d'évaluation qui permet de mesurer et de documenter les limites et les forces comprises dans les banques de données de l'ICIS. Cet outil d'évaluation utilise cinq dimensions pour lesquelles 19 caractéristiques et 61 critères ont été définis. Les dimensions utilisées sont l'exactitude, l'actualité, la comparabilité, la facilité d'utilisation et la pertinence.

### 5.6.4 MDM

L'approche MDM, *Master Data Management* ou Gestion des données de référence, permet de mettre en place un référentiel de données transversales ainsi qu'une organisation adaptée qui permet de gérer ces données. L'objectif est de mutualiser les efforts et d'assurer la synchronisation, le partage et le contrôle des données de référence.

## 5.7 En résumé

La gestion de la qualité des données n'est pas en soi une tâche insurmontable mais elle nécessite des qualités particulières que ce soit chez les informaticiens ou dans toute l'organisation. Outre la compétence en informatique, l'une des qualités les plus recherchées chez un informaticien est l'aptitude à communiquer et éventuellement l'association avec une compétence métier (production, environnement, ...).

"Il ne faut pas sous-estimer l'élégance toute simple de l'amélioration de la qualité. Outre le travail en équipe, la formation et la rigueur, elle n'exige pas de talents particuliers. Quiconque le veut peut en être un contributeur efficace." [12].
# Chapter 6

## Master Data Management ou MDM

Nous présentons dans ce chapitre le **Master Data Management** ou **MDM**, qui est une approche qui s'intéresse à la qualité de certaines données. Cette partie est intégralement issue de l'excellent document "Master Data Management - Mise en place d'un référentiel de données" [18]

L'enjeu du Master Data Management (MDM) est de faciliter la gestion des données de référence, de façon transversale à différentes applications en mettant en place une organisation de circonstance supportée par un référentiel de données. La mise en place d'un tel référentiel permet de se réapproprier ses propres données métier, de les enrichir et d'assurer leur pérennité, indépendamment des processus qui les manipulent. D'un point de vue opérationnel, l'intérêt de l'approche MDM est de mutualiser les efforts et d'assurer la synchronisation, le partage et la qualité des données à travers plusieurs silos d'informations en quasi temps réel.

### 6.1 L'approche MDM

Nous présentons ici cette approche et en quoi elle est utile pour assurer la qualité des données.

#### 6.1.1 Qu'est ce que l'approche MDM ?

Quelle que soit sa complexité, un système d'information ne fournit une aide efficace que si il peut proposer et traiter des données pertinentes et de qualité. Il est donc primordial de pouvoir mesurer cette qualité, de l'améliorer de manière continue et de la piloter suivant les besoins et usages (fitness for use). Cependant, on ne peut mesurer ce qu'on ne contrôle pas et on ne peut contrôler ce qu'on ne connaît pas ou plus.

L'échange contrôlé de données entre applications est un problème complexe. En effet, les applications constituant les systèmes d'information des grandes entreprises ou des administrations publiques sont fortement hétérogènes. Cette hétérogénéité engendre une perte de la maîtrise des données qui, dans la majorité des cas, restent cloisonnées au sein des différentes applications existantes qui sont difficilement interopérables. Au final, les données sont souvent 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.
# Chapter 6

## Master Data Management ou MDM

Nous présentons dans ce chapitre le **Master Data Management** ou **MDM**, qui est une approche qui s'intéresse à la qualité de certaines données. Cette partie est intégralement issue de l'excellent document "Master Data Management - Mise en place d'un référentiel de données" [18]

L'enjeu du Master Data Management (MDM) est de faciliter la gestion des données de référence, de façon transversale à différentes applications en mettant en place une organisation de circonstance supportée par un référentiel de données. La mise en place d'un tel référentiel permet de se réapproprier ses propres données métier, de les enrichir et d'assurer leur pérennité, indépendamment des processus qui les manipulent. D'un point de vue opérationnel, l'intérêt de l'approche MDM est de mutualiser les efforts et d'assurer la synchronisation, le partage et la qualité des données à travers plusieurs silos d'informations en quasi temps réel.

### 6.1 L'approche MDM

Nous présentons ici cette approche et en quoi elle est utile pour assurer la qualité des données.

#### 6.1.1 Qu'est ce que l'approche MDM ?

Quelle que soit sa complexité, un système d'information ne fournit une aide efficace que si il peut proposer et traiter des données pertinentes et de qualité. Il est donc primordial de pouvoir mesurer cette qualité, de l'améliorer de manière continue et de la piloter suivant les besoins et usages (fitness for use). Cependant, on ne peut mesurer ce qu'on ne contrôle pas et on ne peut contrôler ce qu'on ne connaît pas ou plus.

L'échange contrôlé de données entre applications est un problème complexe. En effet, les applications constituant les systèmes d'information des grandes entreprises ou des administrations publiques sont fortement hétérogènes. Cette hétérogénéité engendre une perte de la maîtrise des données qui, dans la majorité des cas, restent cloisonnées au sein des différentes applications existantes qui sont difficilement interopérables. Au final, les données sont souvent 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.
L'enjeu du 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. Ainsi 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 est consultable par des différents utilisateurs ou consommateurs. Ce référentiel se focalise sur les données à haute valeur ajoutée dont la qualité et l'accessibilité sont crucales 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çues et/ou collectées pour ensuite les rendre facilement accessibles. Cette intégration peut-être réalisée de manière logique ou physique :

- *Intégration Logique* : le référentiel de données joue un rôle d'*annuaire de données* permettant aux consommateurs d'identifier à quel(s) fournisseur(s) de données ils doivent s'adresser. 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.

- *Intégration Physique* : le référentiel de données joue un rôle de **consolidateur 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.

Depuis l'ouverture des systèmes d'information vers l'extérieur, la valorisation et le partage des données sont devenus des éléments primordiaux. Le cloisonnement des données constitue cependant un frein majeur à cette valorisation :

- Dans le meilleur des cas, les applications tentent de garantir la synchronisation des différentes données qu'elles partagent (produits, code pays, clients, employés, patients, etc.). Au fil du temps, cette synchronisation est malheureusement rarement conservée.

- Dans le pire des cas, les différents acteurs n'envisagent même pas la synchronisation de certaines de leurs données simplement en raison du fait qu'ils ne parlent pas le même langage. Les données qu'ils s'échange nt ne peuvent être confrontées/comparées car ils ne les interprètent pas de la même manière. Dès lors, sans un référentiel commun pour partager leurs données, toute échange devient infructueux.

Les problèmes liés à la synchronisation et la qualité des données ne sont souvent identifiés que tardivement par les utilisateurs finaux, ce qui est évidemment la pire des situations. La qualité des données ne peut pas être garantie que par le biais d'une opération curative et limitée dans le temps. L'enjeu est de gérer les données transversalement aux applications réparties dans différents services et sur différents sites géographiques. Gérer transversalement des données signifie pouvoir les partager, contrôler leur synchronisation, identifier, en quasi temps réel, leurs problèmes de qualité et les corriger conformément à un processus bien défini. Cette gestion transversale des données amène à investir dans la gestion des données de référence : le **Master Data Management** ou **MDM**.

Le MDM n'est ni une technologie, ni un logiciel mais une méthode qui se focalise sur la rationalisation de la gestion des données partagées au sein d'une organisation ou entre plusieurs organisations. L'objectif du Master Data Management est de gérer de manière unifiée et transversale les données partagées. Malheureusement, elles sont souvent hétérogènes et
L'enjeu du 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. Ainsi 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 est consultable par des différents utilisateurs ou consommateurs. Ce référentiel se focalise sur les données à haute valeur ajoutée dont la qualité et l'accessibilité sont crucales 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çues et/ou collectées pour ensuite les rendre facilement accessibles. Cette intégration peut-être réalisée de manière logique ou physique :

- *Intégration Logique* : le référentiel de données joue un rôle d'*annuaire de données* permettant aux consommateurs d'identifier à quel(s) fournisseur(s) de données ils doivent s'adresser. 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.

- *Intégration Physique* : le référentiel de données joue un rôle de **consolidateur 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.

Depuis l'ouverture des systèmes d'information vers l'extérieur, la valorisation et le partage des données sont devenus des éléments primordiaux. Le cloisonnement des données constitue cependant un frein majeur à cette valorisation :

- Dans le meilleur des cas, les applications tentent de garantir la synchronisation des différentes données qu'elles partagent (produits, code pays, clients, employés, patients, etc.). Au fil du temps, cette synchronisation est malheureusement rarement conservée.

- Dans le pire des cas, les différents acteurs n'envisagent même pas la synchronisation de certaines de leurs données simplement en raison du fait qu'ils ne parlent pas le même langage. Les données qu'ils s'échangent ne peuvent être confrontées/comparées car ils ne les interprètent pas de la même manière. Dès lors, sans un référentiel commun pour partager leurs données, toute échange devient infructueux.

Les problèmes liés à la synchronisation et la qualité des données ne sont souvent identifiés que tardivement par les utilisateurs finaux, ce qui est évidemment la pire des situations. La qualité des données ne peut pas être garantie que par le biais d'une opération curative et limitée dans le temps. L'enjeu est de gérer les données transversalement aux applications réparties dans différents services et sur différents sites géographiques. Gérer transversalement des données signifie pouvoir les partager, contrôler leur synchronisation, identifier, en quasi temps réel, leurs problèmes de qualité et les corriger conformément à un processus bien défini. Cette gestion transversale des données amène à investir dans la gestion des données de référence : le **Master Data Management** ou **MDM**.

Le MDM n'est ni une technologie, ni un logiciel mais une méthode qui se focalise sur la rationalisation de la gestion des données partagées au sein d'une organisation ou entre plusieurs organisations. L'objectif du Master Data Management est de gérer de manière unifiée et transversale les données partagées. Malheureusement, elles sont souvent hétérogènes et
dispersées dans plusieurs bases de données non synchronisées. Le MDM veut pallier cette
problématique en :

- définissant un **référentiel** commun pour les données partagées,

- automatisant le **partage** et la **synchronisation** des données,

- déterminant les règles de **gouvernance** associées aux données : Qui peut y accéder ?, Qui peut les modifier ?, Qui peut faire du reporting d'anomalies ?, ...

- garantissant la **qualité** des données dans le temps,

- favorisant l'intégration des données : soit physiquement dans une base de données commune, soit logiquement dans un annuaire de données déterminant les redirections vers les fournisseurs de données, soit en combinant une intégration physique et logique.

L'approche MDM est avant tout une méthode, qui doit être supportée par des solutions MDM spécifiquement adaptées à cet effet. Au départ, les solutions MDM étaient spécifiques à certains domaines et à certains types de données. Deux catégories de solutions MDM dites "verticales" se sont distinguées :

- la gestion des catalogues produits ou Product Information Management (PIM), notamment dans les domaines de la grande distribution et du manufacturing,

- l'intégration des données clients ou Customer Data Integration (CDI), particulièrement pour l'administration de grosses bases de données transactionnelles (gestion des doublons, vérification et homogénéisation des adresses, ...) dans des domaines tels que les banques ou les assurances.

À l'heure actuelle, les solutions MDM tendent de plus en plus vers des solutions "horizontales" et génériques qui prennent en compte tous types de données et qui couvrent l'ensemble de leur cycle de vie. Généralement, on distingue deux catégories de solutions MDM :

- Le **MDM analytique** 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.

- Le **MDM opérationnel** 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.

## 6.1.2 Pourquoi utiliser l'approche MDM ?

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.

### 6.1.2.1 Volume et complexité

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.

### 6.1.2.2 Interdépendance des données

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é.
dispersées dans plusieurs bases de données non synchronisées. Le MDM veut pallier cette
problématique en :

- définissant un **référentiel** commun pour les données partagées,

- automatisant le **partage** et la **synchronisation** des données,

- déterminant les règles de **gouvernance** associées aux données : Qui peut y accéder ?, Qui peut les modifier ?, Qui peut faire du reporting d'anomalies ?, ...

- garantissant la **qualité** des données dans le temps,

- favorisant l'intégration des données : soit physiquement dans une base de données commune, soit logiquement dans un annuaire de données déterminant les redirections vers les fournisseurs de données, soit en combinant une intégration physique et logique.

L'approche MDM est avant tout une méthode, qui doit être supportée par des solutions MDM spécifiquement adaptées à cet effet. Au départ, les solutions MDM étaient spécifiques à certains domaines et à certains types de données. Deux catégories de solutions MDM dites "verticales" se sont distinguées :

- la gestion des catalogues produits ou Product Information Management (PIM), notamment dans les domaines de la grande distribution et du manufacturing,

- l'intégration des données clients ou Customer Data Integration (CDI), particulièrement pour l'administration de grosses bases de données transactionnelles (gestion des doublons, vérification et homogénéisation des adresses, ...) dans des domaines tels que les banques ou les assurances.

À l'heure actuelle, les solutions MDM tendent de plus en plus vers des solutions "horizontales" et génériques qui prennent en compte tous types de données et qui couvrent l'ensemble de leur cycle de vie. Généralement, on distingue deux catégories de solutions MDM :

- Le **MDM analytique** 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.

- Le **MDM opérationnel** 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.

## 6.1.2 Pourquoi utiliser l'approche MDM ?

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.

### 6.1.2.1 Volume et complexité

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.

### 6.1.2.2 Interdépendance des données

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.

6.1.2.3 Partage des données

Dans un monde de plus en plus ouvert, où les données sont une ressource à part entière,
elles doivent être **partagées**. Le problème est similaire à celui du jeu du téléphone arabe.
Si on énonce une phrase quelconque à la première personne en tête d'une file et que je lui
demande de la répéter à son voisin et ainsi de suite, j'ai la quasi certitude, que, lorsque cette
phrase arrivera à la fin, sa signification aura probablement changé du tout au tout. En effet,
plus il existe d'intermédiaires, plus le contenu de la donnée risque d'être altéré ; soit parce
que les intermédiaires n'utilisent pas le même langage, soit parce qu'ils estiment que certaines
corrections peuvent être apportées ou que certaines données sont négligeables.

6.1.2.4 Qualité des données

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

6.1.2.5 Dispersion et duplication

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**. Si l'adresse d'un même citoyen est différente d'une application à l'autre, il faut en étudier la raison avec précaution. On doit être capable, d'une part, de retrouver et de rendre accessibles ses données où qu'elles se trouvent et, d'autre part, de détecter et de lever les divergences entre données hétérogènes. Les origines de ces divergences se retrouvent soit au niveau de leur contenu (valeur), soit dans la manière dont elles sont interprétées (définition) :

- D'une part, une donnée peut avoir une définition univoque mais des valeurs hétérogènes ; soit parce qu'une faute de frappe a été malencontreusement introduite, soit parce que le rythme de mise à jour des données est différent. Par exemple, l'adresse du domicile légal d'un citoyen a une définition juridique univoque mais un même citoyen peut avoir trois adresses différentes selon les applications considérées. Dans la première application, il est domicilié " 176 avenue des alouettes ", dans la seconde, " 176 avenue des allouettes " et dans la troisième, " 13 rue des mésanges ". Si la première adresse est considérée comme son véritable domicile légal, on peut présupposer qu'une erreur de frappe a été introduite dans la deuxième application, tandis que la troisième application n'a pas encore été avertie du changement d'adresse.

- D'autre part, une même donnée peut avoir des définitions différentes suivant l'application ou le domaine métier considéré. Par exemple, la notion d'adresse peut être interprétée soit comme l'adresse effective d'un citoyen soit comme l'adresse de son domicile légal. Suivant la définition utilisée, la valeur de la donnée est correcte mais les applications ne
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.

6.1.2.3 Partage des données

Dans un monde de plus en plus ouvert, où les données sont une ressource à part entière,
elles doivent être **partagées**. Le problème est similaire à celui du jeu du téléphone arabe.
Si on énonce une phrase quelconque à la première personne en tête d'une file et que je lui
demande de la répéter à son voisin et ainsi de suite, j'ai la quasi certitude, que, lorsque cette
phrase arrivera à la fin, sa signification aura probablement changé du tout au tout. En effet,
plus il existe d'intermédiaires, plus le contenu de la donnée risque d'être altéré ; soit parce
que les intermédiaires n'utilisent pas le même langage, soit parce qu'ils estiment que certaines
corrections peuvent être apportées ou que certaines données sont négligeables.

6.1.2.4 Qualité des données

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

6.1.2.5 Dispersion et duplication

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**. Si l'adresse d'un même citoyen est différente d'une application à l'autre, il faut en étudier la raison avec précaution. On doit être capable, d'une part, de retrouver et de rendre accessibles ses données où qu'elles se trouvent et, d'autre part, de détecter et de lever les divergences entre données hétérogènes. Les origines de ces divergences se retrouvent soit au niveau de leur contenu (valeur), soit dans la manière dont elles sont interprétées (définition) :

- D'une part, une donnée peut avoir une définition univoque mais des valeurs hétérogènes ; soit parce qu'une faute de frappe a été malencontreusement introduite, soit parce que le rythme de mise à jour des données est différent. Par exemple, l'adresse du domicile légal d'un citoyen a une définition juridique univoque mais un même citoyen peut avoir trois adresses différentes selon les applications considérées. Dans la première application, il est domicilié " 176 avenue des alouettes ", dans la seconde, " 176 avenue des allouettes " et dans la troisième, " 13 rue des mésanges ". Si la première adresse est considérée comme son véritable domicile légal, on peut présupposer qu'une erreur de frappe a été introduite dans la deuxième application, tandis que la troisième application n'a pas encore été avertie du changement d'adresse.

- D'autre part, une même donnée peut avoir des définitions différentes suivant l'application ou le domaine métier considéré. Par exemple, la notion d'adresse peut être interprétée soit comme l'adresse effective d'un citoyen soit comme l'adresse de son domicile légal. Suivant la définition utilisée, la valeur de la donnée est correcte mais les applications ne
- Réduire les coûts de licence, de support et de matériel des systèmes redondants en réduisant le nombre d'entrepôts de données et en rendant obsolètes ceux contenant des données dupliquées.

- Réduire les coûts de développement et de maintenance en utilisant une plateforme MDM configurable et évolutive offrant des services standardisés d'accès et de modification des données de référence.

- Réduire les coûts de livraison d'information en mettant en uvre un référentiel délivrant des données de qualité, à jour et traçable, et évitant ainsi les aller-retour entre le métier et les services informatiques pour discuter de l'origine, de la pertinence ou de la fraîcheur des données.

## 6.2 Les concepts

Nous présentons dans cette partie, les concepts de base du MDM, ainsi les différents types d'architecture MDM.

### 6.2.1 Concepts fondamentaux

Nous décrivons ici le concept de données de référence, comment le gérer et les 3 approches fondamentales de l'approche MDM : la gouvernance, l'intégration et la qualité des données.

#### 6.2.1.1 Données de référence

Assurer la synchronisation et l'intégration des données a un coût non négligeable et il est illu-
soire 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**.

Une donnée de référence est une information de base, fondamentale pour l'activité de l'entreprise, et partagée ou dupliquée dans plusieurs systèmes. 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 s'opposent aux données dites transactionnelles qui se réfèrent aux événements relatifs à ces objets métier. Elles possèdent un long cycle de vie et sont sujettes aux changements.

Généralement, ces données concernent des personnes (employés, consommateurs, patients, ...), des objets (produits, immeubles, ...), des lieux (succursales, bureaux, pays, ...) ou des concepts (ventes, contrats, licences, ...).

Gérer des données de référence génère des coûts supplémentaires non négligeables, en conséquence, tous les objets métier ne doivent pas être pris en compte et doivent donc être sélectionnés avec précaution. Les principales caractéristiques d'une donnée de référence sont qu'elle est partagée et/ou échangée avec des tiers, qu'elle possède une haute valeur ajoutée et que sa (ses) source(s) authentique(s) est (sont) reconnue(s).
- Réduire les coûts de licence, de support et de matériel des systèmes redondants en réduisant le nombre d'entrepôts de données et en rendant obsolètes ceux contenant des données dupliquées.

- Réduire les coûts de développement et de maintenance en utilisant une plateforme MDM configurable et évolutive offrant des services standardisés d'accès et de modification des données de référence.

- Réduire les coûts de livraison d'information en mettant en uvre un référentiel délivrant des données de qualité, à jour et traçable, et évitant ainsi les aller-retour entre le métier et les services informatiques pour discuter de l'origine, de la pertinence ou de la fraîcheur des données.

## 6.2 Les concepts

Nous présentons dans cette partie, les concepts de base du MDM, ainsi les différents types d'architecture MDM.

### 6.2.1 Concepts fondamentaux

Nous décrivons ici le concept de données de référence, comment le gérer et les 3 approches fondamentales de l'approche MDM : la gouvernance, l'intégration et la qualité des données.

#### 6.2.1.1 Données de référence

Assurer la synchronisation et l'intégration des données a un coût non négligeable et il est illu-
soire 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**.

Une donnée de référence est une information de base, fondamentale pour l'activité de l'entreprise, et partagée ou dupliquée dans plusieurs systèmes. 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 s'opposent aux données dites transactionnelles qui se réfèrent aux événements relatifs à ces objets métier. Elles possèdent un long cycle de vie et sont sujettes aux changements.

Généralement, ces données concernent des personnes (employés, consommateurs, patients, ...), des objets (produits, immeubles, ...), des lieux (succursales, bureaux, pays, ...) ou des concepts (ventes, contrats, licences, ...).

Gérer des données de référence génère des coûts supplémentaires non négligeables, en conséquence, tous les objets métier ne doivent pas être pris en compte et doivent donc être sélectionnés avec précaution. Les principales caractéristiques d'une donnée de référence sont qu'elle est partagée et/ou échangée avec des tiers, qu'elle possède une haute valeur ajoutée et que sa (ses) source(s) authentique(s) est (sont) reconnue(s).
### 6.2.1.2 Gestion des données de référence

La gestion des données de référence ou MDM n'est ni une technologie ni un logiciel, mais une démarche, la gouvernance des données, qui met en oeuvre des procédures durables. 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.

Il n'existe pas de définition de l'approche MDM qui soit communément acceptée par l'ensemble de la communauté. Différentes définitions existent, en voici deux habituellement citées :

1. MDM is the authoritative, reliable foundation for data used across many applications constituencies with the goal to provide a single view of the truth no matter where it lies. (MDM est le fondement fiable et faisant autorité pour les données utilisées dans de nombreuses applications et groupes dans le but de fournir une vue unique de la vérité, sans tenir compte de où elle se trouve).

2. Master Data Management (MDM) is a discipline in which the business and the IT organisation work together to ensure the uniformity, accuracy, semantic persistence, stewardship and accountability of the enterprise's official, shared master data. Organizations apply MDM to eliminate endless, time-consuming debates about whose data is right, which can lead to poor decision making and business performance. (Le Master Data Management (MDM) est une discipline dans laquelle l'entreprise et l'organisation informatique travaillent ensemble pour assurer l'uniformité, l'exactitude, la persistance sémantique, la gérance et la responsabilité des données de base officielles et partagées de l'entreprise. Les organisations appliquent le MDM pour éliminer les débats interminables et fastidieux sur "quelles données sont exactes", ce qui peut conduire à de mauvaises prises de décisions et à de mauvaises performances commerciales.)

Évidemment, ces définitions peuvent prêter à controverse. Ainsi, il est difficilement imaginable de fournir une vue unique de la vérité. La volonté est plutôt d'expliciter une vue commune entre les différents acteurs qui pourra ensuite être contextualisée par ceux-ci suivant leur besoins spécifiques. De plus, les débats concernant la validité et/ou l'authenticité des données ne vont pas disparaître comme par enchantement mais seront rationalisés au sein de l'organisation gérant le référentiel de données.

À ce stade, il est important de distinguer l'approche MDM d'autres approches qui partagent les mêmes idées et principes. À première vue, toutes ces approches semblent répondre à la même problématique. Il faut donc déterminer ce qui est couvert par chacune de ces approches et s'intéresser à la véritable valeur ajoutée du MDM.

Le MDM est une approche définissant un ensemble de bonnes pratiques et de moyens facilitant la gestion à la fois opérationnelle et analytique des données de référence de manière générique et transversale aux applications. La solution préconisée est de centraliser ces données dans un référentiel maître et indépendant des systèmes applicatifs afin d'en garantir sa pérennité et de mutualiser les efforts de contrôle et d'amélioration de la qualité. Pour cela l'approche MDM regroupe un ensemble de démarches et d'outils préexistants afin de centraliser et de rationaliser la gestion et le partage des données critiques.

L'approche MDM se base principalement sur trois approches fondamentales que sont la "Data Governance", la "Data Quality" et la "Data Integration".
### 6.2.1.2 Gestion des données de référence

La gestion des données de référence ou MDM n'est ni une technologie ni un logiciel, mais une démarche, la gouvernance des données, qui met en oeuvre des procédures durables. 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.

Il n'existe pas de définition de l'approche MDM qui soit communément acceptée par l'ensemble de la communauté. Différentes définitions existent, en voici deux habituellement citées :

1. MDM is the authoritative, reliable foundation for data used across many applications constituencies with the goal to provide a single view of the truth no matter where it lies. (MDM est le fondement fiable et faisant autorité pour les données utilisées dans de nombreuses applications et groupes dans le but de fournir une vue unique de la vérité, sans tenir compte de où elle se trouve).

2. Master Data Management (MDM) is a discipline in which the business and the IT organisation work together to ensure the uniformity, accuracy, semantic persistence, stewardship and accountability of the enterprise's official, shared master data. Organizations apply MDM to eliminate endless, time-consuming debates about whose data is right, which can lead to poor decision making and business performance. (Le Master Data Management (MDM) est une discipline dans laquelle l'entreprise et l'organisation informatique travaillent ensemble pour assurer l'uniformité, l'exactitude, la persistance sémantique, la gérance et la responsabilité des données de base officielles et partagées de l'entreprise. Les organisations appliquent le MDM pour éliminer les débats interminables et fastidieux sur "quelles données sont exactes", ce qui peut conduire à de mauvaises prises de décisions et à de mauvaises performances commerciales.)

Évidemment, ces définitions peuvent prêter à controverse. Ainsi, il est difficilement imaginable de fournir une vue unique de la vérité. La volonté est plutôt d'expliciter une vue commune entre les différents acteurs qui pourra ensuite être contextualisée par ceux-ci suivant leur besoins spécifiques. De plus, les débats concernant la validité et/ou l'authenticité des données ne vont pas disparaître comme par enchantement mais seront rationalisés au sein de l'organisation gérant le référentiel de données.

À ce stade, il est important de distinguer l'approche MDM d'autres approches qui partagent les mêmes idées et principes. À première vue, toutes ces approches semblent répondre à la même problématique. Il faut donc déterminer ce qui est couvert par chacune de ces approches et s'intéresser à la véritable valeur ajoutée du MDM.

Le MDM est une approche définissant un ensemble de bonnes pratiques et de moyens facilitant la gestion à la fois opérationnelle et analytique des données de référence de manière générique et transversale aux applications. La solution préconisée est de centraliser ces données dans un référentiel maître et indépendant des systèmes applicatifs afin d'en garantir sa pérennité et de mutualiser les efforts de contrôle et d'amélioration de la qualité. Pour cela l'approche MDM regroupe un ensemble de démarches et d'outils préexistants afin de centraliser et de rationaliser la gestion et le partage des données critiques.

L'approche MDM se base principalement sur trois approches fondamentales que sont la "Data Governance", la "Data Quality" et la "Data Integration".
### 6.2.1.3 Gouvernance des données ou 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 :

- Prévoir, c'est établir une stratégie de gestion des données déterminant les procédures afin de mettre à jour, partager, assurer la sécurité, contrôler l'accessibilité des données, préserver les droits de leur(s) propriétaire(s), etc.

- Négocier, c'est mettre les gens autour de la table afin de trouver des compromis permettant de gérer ces données tout en respectant les exigences des fournisseurs et consommateurs de données ainsi que les réglementations en vigueur.

- Soulever les problèmes, c'est être capable de détecter des anomalies relatives aux données et à leur utilisation.

- Résoudre les problèmes, c'est être capable de prendre les mesures nécessaires afin de corriger ces anomalies ou d'en diminuer au maximum les effets négatifs.

La gouvernance des données consiste principalement à superviser l'exploitation des données et englobe les éléments qui permettent de gérer de manière optimale les dimensions de qualité telles que l'exactitude, la disponibilité, la sécurité et la conformité réglementaire des données. Les principaux moyens préconisés sont :

- la création d'un comité de pilotage et de surveillance,

- l'identification des "propriétaires", des "fournisseurs" et des "consommateurs" des données,

- la définition des rôles et responsabilités,

- la description des données (glossaire métier, dictionnaires, métadonnées,...),

- la définition des politiques et des processus de gestion des données,

- l'établissement des normes et des procédures pour l'utilisation des données,

- la mise en oeuvre des vérifications et des contrôles des données.

### 6.2.1.4 L'intégration de données ou Data Integration

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. L'intégration de données consiste habituellement à extraire des données de différentes sources (bases de données, fichiers, applications, services web, emails, ...), à leur appliquer des transformations (jointures, déduplication, calculs, ...), 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/outils peuvent être utilisés :

- **Extraction Transformation Loading ou ETL** : cet outil permet d'effectuer des synchronisations massives de données d'une base de données vers une autre. Différentes techniques d'extraction, de réplication, de transformation et de conversion de données sont utilisées afin de (re)peupler différentes bases de données.

Les avantages de cette technique sont la forte intégration des données, la grande disponibilité des indicateurs et agrégats et son adéquation avec des outils d'analyse.
### 6.2.1.3 Gouvernance des données ou 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 :

- Prévoir, c'est établir une stratégie de gestion des données déterminant les procédures afin de mettre à jour, partager, assurer la sécurité, contrôler l'accessibilité des données, préserver les droits de leur(s) propriétaire(s), etc.

- Négocier, c'est mettre les gens autour de la table afin de trouver des compromis permettant de gérer ces données tout en respectant les exigences des fournisseurs et consommateurs de données ainsi que les réglementations en vigueur.

- Soulever les problèmes, c'est être capable de détecter des anomalies relatives aux données et à leur utilisation.

- Résoudre les problèmes, c'est être capable de prendre les mesures nécessaires afin de corriger ces anomalies ou d'en diminuer au maximum les effets négatifs.

La gouvernance des données consiste principalement à superviser l'exploitation des données et englobe les éléments qui permettent de gérer de manière optimale les dimensions de qualité telles que l'exactitude, la disponibilité, la sécurité et la conformité réglementaire des données. Les principaux moyens préconisés sont :

- la création d'un comité de pilotage et de surveillance,

- l'identification des "propriétaires", des "fournisseurs" et des "consommateurs" des données,

- la définition des rôles et responsabilités,

- la description des données (glossaire métier, dictionnaires, métadonnées,...),

- la définition des politiques et des processus de gestion des données,

- l'établissement des normes et des procédures pour l'utilisation des données,

- la mise en oeuvre des vérifications et des contrôles des données.

### 6.2.1.4 L'intégration de données ou Data Integration

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. L'intégration de données consiste habituellement à extraire des données de différentes sources (bases de données, fichiers, applications, services web, emails, ...), à leur appliquer des transformations (jointures, déduplication, calculs, ...), 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/outils peuvent être utilisés :

- **Extraction Transformation Loading ou ETL** : cet outil permet d'effectuer des synchronisations massives de données d'une base de données vers une autre. Différentes techniques d'extraction, de réplication, de transformation et de conversion de données sont utilisées afin de (re)peupler différentes bases de données.

Les avantages de cette technique sont la forte intégration des données, la grande disponibilité des indicateurs et agrégats et son adéquation avec des outils d'analyse.
Les désavantages sont les coûts souvent très élevés en matériel, logiciel, maintenance et service ainsi que le délai de rafraîchissement trop long.

- **Enterprise Information Integration ou EII** : cette technologie permet d'interroger plusieurs sources de données afin d'obtenir une vue unifiée et intégrée des données de l'entreprise. Le rôle du serveur EII est de faire la médiation entre les différentes sources de données en décomposant correctement les requêtes qu'il reçoit et en les redirigeant vers les différentes bases de données concernées pour ensuite rassembler les différents résultats avant de les renvoyer.

Les solutions EII permettent l'accès en quasi temps réel aux données, contrairement aux solutions ETL qui accèdent aux données de manière périodique.

- **Enterprise Application Integration ou EAI** : cette technologie propose une architecture intergicielle (middleware) permettant à des applications hétérogènes de gérer l'échange et la conversion des données en quasi temps réel. Ces applications peuvent être développées indépendamment et peuvent utiliser des technologies différentes.

Une solution MDM combine généralement ces trois techniques. Les techniques EII sont utilisées comme requêteur pour retrouver les différentes données dispersées dans plusieurs bases de données et les intégrer de manière logique. Les techniques ETL sont utilisées comme extracteur pour récupérer les données dispersées et les intégrer de manière physique dans une nouvelle base de données qui constituera la base de données centrale de référence. Les techniques EAI/ESB sont utilisées comme transporteur pour échanger les données entre applications consommatrices et/ou fournisseuses de données.

### 6.2.1.5 Qualité des données ou Data Quality

La Data Quality définit un ensemble de bonnes pratiques et de moyens en adéquation avec les usages 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 profilage, la surveillance, la standardisation et le rapprochement des données.

Au-delà de la technologie, le contrôle et l'amélioration de la qualité des données sont des éléments primordiaux à toute approche MDM. Le taux d'anomalies augmente fortement en fonction du nombre de sources de données et du degré d'hétérogénéité de celles-ci. D'un côté, l'efficacité de l'échange des données dépend principalement de la confiance accordée par les consommateurs à ces données. D'un autre côté, la qualité de l'intégration des données dépend largement de la qualité des données de départ. L'intégration de données de mauvaise qualité ne peut générer que des données de mauvaise qualité pour lesquelles il sera plus complexe d'identifier l'origine du problème.

### 6.2.1.6 L'originalité de l'approche MDM

Produire un annuaire de données de référence ou constituer une base de données rassemblant les données de référence ne suffit pas. Il faut pouvoir assurer la maintenance et garantir la qualité des données de référence sur le long terme. Les efforts investis dans la création de données de référence cohérentes et de qualité ne doivent pas être réduits à néant par un manque de bonnes pratiques favorisant la préservation de cette cohérence et de cette qualité.

Dans la majorité des cas, des changements importants doivent avoir lieu au niveau des processus métier et des outils adéquats doivent être mis en place. Néanmoins, les défis les plus importants
Les désavantages sont les coûts souvent très élevés en matériel, logiciel, maintenance et service ainsi que le délai de rafraîchissement trop long.

- **Enterprise Information Integration ou EII** : cette technologie permet d'interroger plusieurs sources de données afin d'obtenir une vue unifiée et intégrée des données de l'entreprise. Le rôle du serveur EII est de faire la médiation entre les différentes sources de données en décomposant correctement les requêtes qu'il reçoit et en les redirigeant vers les différentes bases de données concernées pour ensuite rassembler les différents résultats avant de les renvoyer.

Les solutions EII permettent l'accès en quasi temps réel aux données, contrairement aux solutions ETL qui accèdent aux données de manière périodique.

- **Enterprise Application Integration ou EAI** : cette technologie propose une architecture intergicielle (middleware) permettant à des applications hétérogènes de gérer l'échange et la conversion des données en quasi temps réel. Ces applications peuvent être développées indépendamment et peuvent utiliser des technologies différentes.

Une solution MDM combine généralement ces trois techniques. Les techniques EII sont utilisées comme requêteur pour retrouver les différentes données dispersées dans plusieurs bases de données et les intégrer de manière logique. Les techniques ETL sont utilisées comme extracteur pour récupérer les données dispersées et les intégrer de manière physique dans une nouvelle base de données qui constituera la base de données centrale de référence. Les techniques EAI/ESB sont utilisées comme transporteur pour échanger les données entre applications consommatrices et/ou fournisseuses de données.

### 6.2.1.5 Qualité des données ou Data Quality

La Data Quality définit un ensemble de bonnes pratiques et de moyens en adéquation avec les usages 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 profilage, la surveillance, la standardisation et le rapprochement des données.

Au-delà de la technologie, le contrôle et l'amélioration de la qualité des données sont des éléments primordiaux à toute approche MDM. Le taux d'anomalies augmente fortement en fonction du nombre de sources de données et du degré d'hétérogénéité de celles-ci. D'un côté, l'efficacité de l'échange des données dépend principalement de la confiance accordée par les consommateurs à ces données. D'un autre côté, la qualité de l'intégration des données dépend largement de la qualité des données de départ. L'intégration de données de mauvaise qualité ne peut générer que des données de mauvaise qualité pour lesquelles il sera plus complexe d'identifier l'origine du problème.

### 6.2.1.6 L'originalité de l'approche MDM

Produire un annuaire de données de référence ou constituer une base de données rassemblant les données de référence ne suffit pas. Il faut pouvoir assurer la maintenance et garantir la qualité des données de référence sur le long terme. Les efforts investis dans la création de données de référence cohérentes et de qualité ne doivent pas être réduits à néant par un manque de bonnes pratiques favorisant la préservation de cette cohérence et de cette qualité.

Dans la majorité des cas, des changements importants doivent avoir lieu au niveau des processus métier et des outils adéquats doivent être mis en place. Néanmoins, les défis les plus importants
sont bien souvent plus organisationnels que techniques.

L'exploitation des données de référence nécessite de les partager et de les tenir à jour de manière collaborative. Les données de référence passent du statut de données stockées dans de simples fichiers plats difficilement exploitables au statut de données réellement valorisables pour l'organisation. En conséquence, la gestion de ces données doit être rationalisée. Il est primordial de faciliter leur échange, de contrôler et d'améliorer leur qualité de manière continue.

Pour ce faire, l'approche MDM met en avant quatre principes fondamentaux :

1. Les données étant généralement dispersées et donc difficilement valorisables, il est indispensable de pouvoir **créer une vision unique de ces données**. Unique ne veut pas dire qu'elle est imposée à tous, mais que l'ensemble des acteurs a trouvé un consensus sur le contenu, le format et la sémantique des données échangées. C'est une vision commune et neutre qui a l'avantage d'être explicite et de permettre l'intégration des données. Chacun est libre de la contextualiser à sa guise suivant ses besoins métier.

2. Une fois que la vision consolidée est jugée exploitable il faut pouvoir la **partager**. La création de cette vue consolidée est une étape préalable qui peut se révéler très complexe, surtout dans un contexte multi-organisationnel. Elle requiert un travail d'harmonisation qui peut prendre de nombreuses années.

3. Dans le cadre du partage des données, l'approche MDM met en avant les notions de référentiel de données, de **qualité des données** et de **gouvernance des données**.

4. Créer et partager la vue unique ne suffit pas, il faut aussi pouvoir **la gérer et la faire évoluer dans le temps** en fonction des besoins métier. Un référentiel n'est pas qu'une simple banque de données logique ou physique, c'est aussi une application qui permet de gérer les échanges de données entre les différentes applications qui y sont connectées. Par exemple, le référentiel doit être capable de garder pour chaque donnée de référence les liens entre les identifiants (primary key) utilisés chez les fournisseurs, chez les consommateurs et dans le référentiel.

## 6.2.2 Les architectures 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.

### 6.2.2.1 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 (cf. figure 6.1).

L'objectif est de créer un point d'entrée unique auquel se référer pour consulter les données de référence et ainsi permettre leur **intégration logique** alors qu'elles demeurent dans les applications sources d'origine.
sont bien souvent plus organisationnels que techniques.

L'exploitation des données de référence nécessite de les partager et de les tenir à jour de manière collaborative. Les données de référence passent du statut de données stockées dans de simples fichiers plats difficilement exploitables au statut de données réellement valorisables pour l'organisation. En conséquence, la gestion de ces données doit être rationalisée. Il est primordial de faciliter leur échange, de contrôler et d'améliorer leur qualité de manière continue.

Pour ce faire, l'approche MDM met en avant quatre principes fondamentaux :

1. Les données étant généralement dispersées et donc difficilement valorisables, il est indispensable de pouvoir **créer une vision unique de ces données**. Unique ne veut pas dire qu'elle est imposée à tous, mais que l'ensemble des acteurs a trouvé un consensus sur le contenu, le format et la sémantique des données échangées. C'est une vision commune et neutre qui a l'avantage d'être explicite et de permettre l'intégration des données. Chacun est libre de la contextualiser à sa guise suivant ses besoins métier.

2. Une fois que la vision consolidée est jugée exploitable il faut pouvoir la **partager**. La création de cette vue consolidée est une étape préalable qui peut se révéler très complexe, surtout dans un contexte multi-organisationnel. Elle requiert un travail d'harmonisation qui peut prendre de nombreuses années.

3. Dans le cadre du partage des données, l'approche MDM met en avant les notions de référentiel de données, de **qualité des données** et de **gouvernance des données**.

4. Créer et partager la vue unique ne suffit pas, il faut aussi pouvoir la **gérer et la faire évoluer dans le temps** en fonction des besoins métier. Un référentiel n'est pas qu'une simple banque de données logique ou physique, c'est aussi une application qui permet de gérer les échanges de données entre les différentes applications qui y sont connectées. Par exemple, le référentiel doit être capable de garder pour chaque donnée de référence les liens entre les identifiants (primary key) utilisés chez les fournisseurs, chez les consommateurs et dans le référentiel.

## 6.2.2 Les architectures 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.

### 6.2.2.1 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 (cf. figure 6.1).

L'objectif est de créer un point d'entrée unique auquel se référer pour consulter les données de référence et ainsi permettre leur **intégration logique** alors qu'elles demeurent dans les applications sources d'origine.
<figure><img src="image_18.png" /><figcaption>Figure 6.1 : Répertoire virtuel</figcaption></figure>

### 6.2.2.2 Centralisation

À l'autre extrême, se trouve l'architecture dite de "centralisation". Cette architecture n'intègre plus les données logiquement mais physiquement (cf. figure 6.2). 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 base de données 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. Dès lors, fournisseurs et consommateurs de données utilisent la même application centrale pour gérer ou interroger les données de référence.

<figure><img src="image_19.png" /><figcaption>Figure 6.2 : Architecture centralisée</figcaption></figure>

### 6.2.2.3 Coopération

Au croisement des deux architectures précédentes est née une architecture intermédiaire dite de "coopération" (Figure 6.3). 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,
<figure><img src="image_19.png" /><figcaption>Figure 6.1 : Répertoire virtuel</figcaption></figure>

### 6.2.2.2 Centralisation

À l'autre extrême, se trouve l'architecture dite de "centralisation". Cette architecture n'intègre plus les données logiquement mais physiquement (cf. figure 6.2). 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 base de données 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. Dès lors, fournisseurs et consommateurs de données utilisent la même application centrale pour gérer ou interroger les données de référence.

<figure><img src="image_20.png" /><figcaption>Figure 6.2 : Architecture centralisée</figcaption></figure>

### 6.2.2.3 Coopération

Au croisement des deux architectures précédentes est née une architecture intermédiaire dite de "coopération" (Figure 6.3). 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,

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

<figure><img src="image_20.png" /><figcaption>Figure 6.3 : Architecture de coopération</figcaption></figure>

### 6.2.2.4 Choix d'une architecture MDM

Chacune des trois architectures MDM présentée possède des avantages et des inconvénients. L'architecture de centralisation semble la plus efficace opérationnellement car les applications consommatrices ont toujours accès à une seule source de données de référence consistante et à jour. Cependant, le coût de la mise en place d'une telle architecture est extrêmement élevé et les impacts sur les applications fournisseuses de données sont souvent trop importants voir même radicaux. Les deux autres architectures autorisent la duplication des données ce qui implique, d'une part, une latence entre la mise à jour des données sources et la mise à jour des données de référence et, d'autre part, l'obligation de mettre en place des techniques complexes assurant la consistance et la synchronisation des données.

Le choix d'une architecture de type répertoire virtuel semble le plus indiqué lorsque :

- la gouvernance des données est faible,

- les données de référence évoluent peu,

- le nombre de sources authentiques différentes pour la même donnée est limité et la cohérence entre ces différentes sources est importante,

- le niveau de disponibilité requis pour les données de référence n'est pas primordial,

- la complexité des requêtes de consultation des données de référence est faible,

- un retour sur investissement à court terme est primordial.

Le choix d'une architecture de type centralisation semble le plus indiqué lorsque:

- la gouvernance des données est forte,

- le nombre d'applications impliquées dans le projet est limité,

- le contrôle sur les applications fournisseuses est important,

- la contextualisation des données de référence n'est pas un besoin capital pour les applications consommatrices,
- de minimiser les impacts sur les applications fournisseuses,

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

<figure><img src="image_21.png" /><figcaption>Figure 6.3 : Architecture de coopération</figcaption></figure>

### 6.2.2.4 Choix d'une architecture MDM

Chacune des trois architectures MDM présentée possède des avantages et des inconvénients. L'architecture de centralisation semble la plus efficace opérationnellement car les applications consommatrices ont toujours accès à une seule source de données de référence consistante et à jour. Cependant, le coût de la mise en place d'une telle architecture est extrêmement élevé et les impacts sur les applications fournisseuses de données sont souvent trop importants voir même radicaux. Les deux autres architectures autorisent la duplication des données ce qui implique, d'une part, une latence entre la mise à jour des données sources et la mise à jour des données de référence et, d'autre part, l'obligation de mettre en place des techniques complexes assurant la consistance et la synchronisation des données.

Le choix d'une architecture de type répertoire virtuel semble le plus indiqué lorsque :

- la gouvernance des données est faible,

- les données de référence évoluent peu,

- le nombre de sources authentiques différentes pour la même donnée est limité et la cohérence entre ces différentes sources est importante,

- le niveau de disponibilité requis pour les données de référence n'est pas primordial,

- la complexité des requêtes de consultation des données de référence est faible,

- un retour sur investissement à court terme est primordial.

Le choix d'une architecture de type centralisation semble le plus indiqué lorsque:

- la gouvernance des données est forte,

- le nombre d'applications impliquées dans le projet est limité,

- le contrôle sur les applications fournisseuses est important,

- la contextualisation des données de référence n'est pas un besoin capital pour les applications consommatrices,
- la valeur ajoutée apportée par un répertoire central opérationnel justifie les coûts et le temps nécessaires à sa mise en place.

Le choix d'une architecture de type coopération semble le plus indiqué lorsque :

- le niveau de gouvernance sur les données doit être flexible,

- le contrôle sur les applications sources n'est pas garanti,

- la création d'une source de données neutre est nécessaire,

- le niveau de disponibilité des données est important,

- la cohérence des données apporte une grande valeur ajoutée,

- l'architecture de type répertoire virtuel doit évoluer de manière incrémentale vers une architecture plus centralisée.

Le choix d'une architecture MDM peut aussi être déterminé par les objectifs métier liés au projet. Nous considérons ici 7 objectifs :

- Améliorer le **contrôle des données**. Le contrôle des données est directement lié au niveau de gouvernance souhaité.

- Améliorer la **disponibilité des données**. La disponibilité dépend de nombreux paramètres. Le premier est le nombre d'intervenants par lesquels les données vont transiter. Pour améliorer la disponibilité, il faut éviter de faire des appels en cascade à différents services d'accès aux données provenant de différentes applications.

- Améliorer la **cohérence/qualité des données**. La cohérence des données n'est pas assurée avec l'utilisation d'un répertoire virtuel. De plus, la qualité des données échangées n'est pas connue. Ainsi des données de mauvaise qualité risquent d'être diffusées vers les applications consommatrices. L'architecture de coopération permet de créer une vue unique cohérente et intégrée des données de référence. Cependant, la synchronisation entre les fournisseurs de données et la vue unique n'est pas toujours garantie. L'architecture de centralisation élimine ce problème de synchronisation et assure l'accès à des données de référence uniques, cohérentes et à jour.

- Améliorer l'**enrichissement des données**. L'enrichissement et l'intégration des données sont fortement dépendants des données de départ. Si les données à enrichir sont incohérentes ou de mauvaise qualité le résultat de l'intégration sera forcément discutable. C'est pourquoi les architectures de type coopération et centralisation devraient être privilégiées si l'objectif principal est de favoriser un enrichissement optimal des données de référence.

- Préserver l'**indépendance** des applications fournisseuses de données. Plus la gestion des données de référence se centralise, moins l'indépendance des applications fournisseuses pourra être préservée.

- Minimiser les changements nécessaires à la mise en place de la solution MDM. La mise en place d'un répertoire virtuel est nettement moins onéreuse que la mise en place d'une architecture de centralisation. Dans le premier cas, la difficulté est de créer un annuaire de données performant. Dans le deuxième cas, la difficulté est d'adapter radicalement les applications existantes en revoyant complètement la gestion et l'implémentation de leurs accès aux bases de données.

- Diminuer les **coûts de gestion des données**. Une fois que la solution MDM a été mise en place, l'architecture de type centralisation favorise les économies d'échelle. Les
- la valeur ajoutée apportée par un répertoire central opérationnel justifie les coûts et le temps nécessaires à sa mise en place.

Le choix d'une architecture de type coopération semble le plus indiqué lorsque :

- le niveau de gouvernance sur les données doit être flexible,

- le contrôle sur les applications sources n'est pas garanti,

- la création d'une source de données neutre est nécessaire,

- le niveau de disponibilité des données est important,

- la cohérence des données apporte une grande valeur ajoutée,

- l'architecture de type répertoire virtuel doit évoluer de manière incrémentale vers une architecture plus centralisée.

Le choix d'une architecture MDM peut aussi être déterminé par les objectifs métier liés au projet. Nous considérons ici 7 objectifs :

- Améliorer le **contrôle des données**. Le contrôle des données est directement lié au niveau de gouvernance souhaité.

- Améliorer la **disponibilité des données**. La disponibilité dépend de nombreux paramètres. Le premier est le nombre d'intervenants par lesquels les données vont transiter. Pour améliorer la disponibilité, il faut éviter de faire des appels en cascade à différents services d'accès aux données provenant de différentes applications.

- Améliorer la **cohérence/qualité des données**. La cohérence des données n'est pas assurée avec l'utilisation d'un répertoire virtuel. De plus, la qualité des données échangées n'est pas connue. Ainsi des données de mauvaise qualité risquent d'être diffusées vers les applications consommatrices. L'architecture de coopération permet de créer une vue unique cohérente et intégrée des données de référence. Cependant, la synchronisation entre les fournisseurs de données et la vue unique n'est pas toujours garantie. L'architecture de centralisation élimine ce problème de synchronisation et assure l'accès à des données de référence uniques, cohérentes et à jour.

- Améliorer l'**enrichissement des données**. L'enrichissement et l'intégration des données sont fortement dépendants des données de départ. Si les données à enrichir sont incohérentes ou de mauvaise qualité le résultat de l'intégration sera forcément discutable. C'est pourquoi les architectures de type coopération et centralisation devraient être privilégiées si l'objectif principal est de favoriser un enrichissement optimal des données de référence.

- Préserver l'**indépendance** des applications fournisseuses de données. Plus la gestion des données de référence se centralise, moins l'indépendance des applications fournisseuses pourra être préservée.

- Minimiser les changements nécessaires à la mise en place de la **solution MDM**. La mise en place d'un répertoire virtuel est nettement moins onéreuse que la mise en place d'une architecture de centralisation. Dans le premier cas, la difficulté est de créer un annuaire de données performant. Dans le deuxième cas, la difficulté est d'adapter radicalement les applications existantes en revoyant complètement la gestion et l'implémentation de leurs accès aux bases de données.

- Diminuer les **coûts de gestion des données**. Une fois que la solution MDM a été mise en place, l'architecture de type centralisation favorise les économies d'échelle. Les
données ne sont plus dupliquées et aucun mécanisme de synchronisation n'est plus nécessaire. Lorsque les données de référence évoluent, les changements sont apportés une et une seule fois. Dans le cas du répertoire virtuel, chaque application continue à devoir assurer la cohérence et la qualité de ses données de manière locale. On échange des données mais on ne mutualise pas les efforts pour leur gestion. Dans le cas de la coopération, on mutualise les efforts pour gérer les données, mais on les duplique dans une base de données commune, ce qui augmente inévitablement les coûts de gestion.

Ces 7 objectifs sont repris dans le tableau 6.1.

<table><caption>Table 6.1 : Choisir son architecture MDM</caption><thead><tr><td></td><td>Répertoire Virtuel</td><td>Coopération</td><td>Centralisation</td></tr></thead><tbody><tr><td>Contrôle</td><td>-</td><td>+</td><td>++</td></tr><tr><td>Disponibilité</td><td>-</td><td>+</td><td>++</td></tr><tr><td>Cohérence</td><td>-</td><td>+</td><td>+++</td></tr><tr><td>Enrichissement</td><td>-</td><td>++</td><td>++</td></tr><tr><td>Indépendance</td><td>++</td><td>-</td><td>--</td></tr><tr><td>Mise en place</td><td>++</td><td>-</td><td>--</td></tr><tr><td>Coûts de gestion</td><td>--</td><td>--</td><td>+++</td></tr></tbody></table>

## 6.3 La mise en place d'une solution MDM

Le taux d'échec des projets MDM reste important. La mise en place et l'utilisation de bonnes pratiques est essentielle à la conduite de tels projets.

Un projet MDM passe par différentes étapes similaires à celles d'un projet de développement de système d'information. Cependant les projets MDM ont des particularités du fait de leurs caractères transversal et multi-organisationnel.

Les grandes phases du développement d'un tel projet sont bien évidemment l'analyse, la conception et l'implémentation (6.4).

<figure><img src="image_21.png" /><figcaption>Figure 6.4 : Les étapes de la mise en place d'une solution MDM</figcaption></figure>
données ne sont plus dupliquées et aucun mécanisme de synchronisation n'est plus nécessaire. Lorsque les données de référence évoluent, les changements sont apportés une et une seule fois. Dans le cas du répertoire virtuel, chaque application continue à devoir assurer la cohérence et la qualité de ses données de manière locale. On échange des données mais on ne mutualise pas les efforts pour leur gestion. Dans le cas de la coopération, on mutualise les efforts pour gérer les données, mais on les duplique dans une base de données commune, ce qui augmente inévitablement les coûts de gestion.

Ces 7 objectifs sont repris dans le tableau 6.1.

<table><caption>Table 6.1 : Choisir son architecture MDM</caption><thead><tr><th></th><th>Répertoire Virtuel</th><th>Coopération</th><th>Centralisation</th></tr></thead><tbody><tr><td>Contrôle</td><td>-</td><td>+</td><td>++</td></tr><tr><td>Disponibilité</td><td>-</td><td>+</td><td>++</td></tr><tr><td>Cohérence</td><td>-</td><td>+</td><td>+++</td></tr><tr><td>Enrichissement</td><td>-</td><td>++</td><td>++</td></tr><tr><td>Indépendance</td><td>++</td><td>-</td><td>--</td></tr><tr><td>Mise en place</td><td>++</td><td>-</td><td>--</td></tr><tr><td>Coûts de gestion</td><td>--</td><td>--</td><td>+++</td></tr></tbody></table>

## 6.3 La mise en place d'une solution MDM

Le taux d'échec des projets MDM reste important. La mise en place et l'utilisation de bonnes pratiques est essentielle à la conduite de tels projets.

Un projet MDM passe par différentes étapes similaires à celles d'un projet de développement de système d'information. Cependant les projets MDM ont des particularités du fait de leurs caractères transversal et multi-organisationnel.

Les grandes phases du développement d'un tel projet sont bien évidemment l'analyse, la conception et l'implémentation (6.4).

<figure><img src="image_22.png" /><figcaption>Figure 6.4 : Les étapes de la mise en place d'une solution MDM</figcaption></figure>
### 6.3.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 consiste essentiellement à comprendre des processus et des systèmes métier complexes et à mettre en place des processus afin de gérer leurs données.

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.

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

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.

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 :

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

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

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

- 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. Outre le volume des données, le volume des transactions est également à prendre en considération.

Une fois ces données identifiées, il faut les expliciter et les faire valider par les acteurs impliqués.
### 6.3.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 consiste essentiellement à comprendre des processus et des systèmes métier complexes et à mettre en place des processus afin de gérer leurs données.

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.

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

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.

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 :

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

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

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

- 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. Outre le volume des données, le volume des transactions est également à prendre en considération.

Une fois ces données identifiées, il faut les expliciter et les faire valider par les acteurs impliqués.
### 6.3.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 oeuvre pour détecter les anomalies.

- Définir les règles d'arbitrage pour traiter ces anomalies.

- Définir les règles d'intégration et 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é.

### 6.3.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é, ...),

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

## 6.3.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 oeuvre correcte.
### 6.3.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 oeuvre pour détecter les anomalies.

- Définir les règles d'arbitrage pour traiter ces anomalies.

- Définir les règles d'intégration et 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é.

### 6.3.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é, ...),

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

## 6.3.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 oeuvre correcte.
### 6.3.2.1 Définir un modèle commun des données 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, ...

L'interprétation des données doit être 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.

### 6.3.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 sert 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 :

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

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

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

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.

### 6.3.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.

Durant cette étape, on explicite de manière contractuelle un *Service Level Agreement* ou SLA qui définit essentiellement :

- le propriétaire du service,

- les modalités de l'échange : output, input, type de données, fréquences, volumétrie, dates de mise à disposition, ...
### 6.3.2.1 Définir un modèle commun des données 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, ...

L'interprétation des données doit être 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.

### 6.3.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 sert 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 :

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

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

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

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.

### 6.3.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.

Durant cette étape, on explicite de manière contractuelle un *Service Level Agreement* ou SLA qui définit essentiellement :

- le propriétaire du service,

- les modalités de l'échange : output, input, type de données, fréquences, volumétrie, dates de mise à disposition, ...
- la qualité du service fourni : disponibilité, temps de réponse, engagement sur la qualité des données, ...

- les procédures relatives au traitement des non-conformités : délais de dépannage, instances d'arbitrage, mesures de reprise, ...

### 6.3.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 supporte l'architecture choisie et satisfait aux exigences notamment en terme de gouvernance, de scalabilité et de reliability.

## 6.3.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 sortie un référentiel de données respectant l'architecture choisie et satisfaisant les SLA spécifiés lors de la phase de conception.

### 6.3.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* utilisées afin d'alimenter un entrepôt de données (normalisation des formats de date, insertion de valeur par défaut, correction des codes postaux, ...).

Le nettoyage comprend également la détection de doublons pouvant apparaître au sein même d'une 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 grandes bases de données est fortement recommandée, notamment, pour les fonctionnalités de profilage, standardisation, rapprochement et nettoyage.

### 6.3.3.2 Consolider les données sources

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 d'enregistrements.

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
- la qualité du service fourni : disponibilité, temps de réponse, engagement sur la qualité des données, ...

- les procédures relatives au traitement des non-conformités : délais de dépannage, instances d'arbitrage, mesures de reprise, ...

### 6.3.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 supporte l'architecture choisie et satisfait aux exigences notamment en terme de gouvernance, de scalabilité et de reliability.

## 6.3.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 sortie un référentiel de données respectant l'architecture choisie et satisfaisant les SLA spécifiés lors de la phase de conception.

### 6.3.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* utilisées afin d'alimenter un entrepôt de données (normalisation des formats de date, insertion de valeur par défaut, correction des codes postaux, ...).

Le nettoyage comprend également la détection de doublons pouvant apparaître au sein même d'une 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 grandes bases de données est fortement recommandée, notamment, pour les fonctionnalités de profilage, standardisation, rapprochement et nettoyage.

### 6.3.3.2 Consolider les données sources

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 d'enregistrements.

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

### 6.3.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 les données de référence vont être stockées et rendues disponibles. Elles 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), ...

### 6.3.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.

### 6.3.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,
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 ne 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.

### 6.3.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 les données de référence vont être stockées et rendues disponibles. Elles 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), ...

### 6.3.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.

### 6.3.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 à d'abord consulter les données de référence avant de créer un nouvel enregistrement.

## 6.4 En résumé

L'approche MDM n'est pas simplement une approche de gestion de la qualité des données telle que nous l'avons présenté au chapitre 5. Elle se focalise sur la gestion des données de référence.
- la capacité des applications à d'abord consulter les données de référence avant de créer un nouvel enregistrement.

## 6.4 En résumé

L'approche MDM n'est pas simplement une approche de gestion de la qualité des données telle que nous l'avons présenté au chapitre 5. Elle se focalise sur la gestion des données de référence.
# Part IV

## Annexes
# Part IV

## Annexes
# Bibliography

Les références données dans cette page correspondent à des supports qui ont été utilisés lors de la conception de ce cours.

Il n'y a aucun besoin de consulter ces documents pour atteindre les objectifs du module de base de données avancées. Par contre ces supports peuvent être intéressants pour les étudiants qui souhaitent aller plus loin.

## Qualité des données

- Laure Berti-Equille *Qualité de données multi-sources et recommandation multi-critères*. 1999- Actes du XVIIème Congrès INFORSID, La Garde, France, 1-4 juin, 1999

- Laure Berti-Equille *La qualité des données comme condition à la qualité des connaissances : un état de l'art* - 2004 MQPFD, pp.95-118

- Laure Berti-Equille *Qualité des données* - 2004 Ingénierie des Systèmes d'Information. 9. 117-143. doi:10.3166/isi.9.5-6.117-143

- Christophe Brasseur *Data Management : qualité des données et compétitivité* 2005 - Hermès Sciences - Collection Management et Informatique - ISBN2-7462-1210-2

- M.L. Brodie *Data quality in information systems* 1980 - Information and management vol. 3, pp. 245-258

- Artur D. Chapman *Les principes de qualité des données* 2005 - version 1.0. Trad. Chenin, N. Copenhague: Global Biodiversity Information Facility https://www.gbif.org/document/80626/les-principes-de-qualite-des-donnees

- G.P.A. Delen and B.B. Rijsenbrij *The specification, engineering, and measurement of information systems quality* 1992 - J. Systems Software, vol. 17, no. 3, pp. 205-217

- Institut canadien d'information sur la santé *Le cadre de la qualité des données de l'ICIS* 2009 - Ottawa

- Informatica France *Des données de qualité - Exploitez le capital de votre organisation* 2008 - Livre Blanc JEMM research

- Yang W. Lee, Diane M. Strong, Beverly K. Kahn, Richard Y. Wang *AIMQ: a methodology for information quality assessment* 2002 - Information Management, Vol 40, Issue 2, doi.org/10.1016/S0378-7206(02)00043-5

- Pipino, Leo L. and Lee, Yang W. and Wang, Richard Y. *Data Quality Assessment*
# Bibliography

Les références données dans cette page correspondent à des supports qui ont été utilisés lors de la conception de ce cours.

Il n'y a aucun besoin de consulter ces documents pour atteindre les objectifs du module de base de données avancées. Par contre ces supports peuvent être intéressants pour les étudiants qui souhaitent aller plus loin.

## Qualité des données

- Laure Berti-Equille *Qualité de données multi-sources et recommandation multi-critères*. 1999- Actes du XVIIème Congrès INFORSID, La Garde, France, 1-4 juin, 1999

- Laure Berti-Equille *La qualité des données comme condition à la qualité des connaissances : un état de l'art* - 2004 MQPFD, pp.95-118

- Laure Berti-Equille *Qualité des données* - 2004 Ingénierie des Systèmes d'Information. 9. 117-143. doi:10.3166/isi.9.5-6.117-143

- Christophe Brasseur *Data Management : qualité des données et compétitivité* 2005 - Hermès Sciences - Collection Management et Informatique - ISBN2-7462-1210-2

- M.L. Brodie *Data quality in information systems* 1980 - Information and management vol. 3, pp. 245-258

- Artur D. Chapman *Les principes de qualité des données* 2005 - version 1.0. Trad. Chenin, N. Copenhague: Global Biodiversity Information Facility https://www.gbif.org/document/80626/les-principes-de-qualite-des-donnees

- G.P.A. Delen and B.B. Rijsenbrij *The specification, engineering, and measurement of information systems quality* 1992 - J. Systems Soffware, vol. 17, no. 3, pp. 205-217

- Institut canadien d'information sur la santé *Le cadre de la qualité des données de l'ICIS* 2009 - Ottawa

- Informatica France *Des données de qualité - Exploitez le capital de votre organisation* 2008 - Livre Blanc JEMM research

- Yang W. Lee, Diane M. Strong, Beverly K. Kahn, Richard Y. Wang *AIMQ: a methodology for information quality assessment* 2002 - Information Management, Vol 40, Issue 2, doi.org/10.1016/S0378-7206(02)00043-5

- Pipino, Leo L. and Lee, Yang W. and Wang, Richard Y. *Data Quality Assessment*
2002 - Commun. ACM, doi.acm.org/10.1145/505248.50601

- Thomas C. Redman, Michael Daugherty, Mike Daugherty *Data Quality: The field Guide* 2001 - Sagebrush Education Resources - ISBN 978-0-61-391717-9

- Talend Open studio *Les 10 causes principales des problèmes de qualité de données* 2013 - Livre blanc Talend Open Studio.

- Richard Y. Wang, Veda C. Storey, Christopher P. Firth *A Framework for Analysis of Data Quality Research* 1995 - IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 7, NO. 4, AUGUST 1995

- Y. Wand and R.Y. Wang *Anchoring data quality dimensions in ontological foundations* 1996 - Commun. ACM 39, 11 pages 86-95.
DOI=http://dx.doi.org/10.1145/240455.240479

- Sabrina Zaïdi-Chtourou *La qualité de l'information dans les systèmes d'information marketing* 2009 - Thèse de l'université Jean Moulin Lyon 3

## MDM

- Franck Régnier-Pécastaing, Michel Gabassi, Jacques Finet *MDM : enjeux et méthodes de la gestion des données* 2008 - DUNOD - ISBN 978-2-10-053555-2

- Jean-Christophe Trigaux *Master Data Management* - Mise en place d'un référentiel de données 2009 - http://documentation.smals.be

## Autres

- Gabriel Siméon *Données le vertige* 2012 - Article Libération (http://www.liberation.fr/futurs/2012/12/03/donnees-le-vertige_864585)

- Smile E-commerce Open Source 2009 - Livre blanc Smile

- Smile Décisionnel : Le meilleur des solutions open source 2012 - Livre blanc Smile

- J.M. Juran *Managerial Breakthrough* 1964 - New York: McGraw-Hill

- Rolande Marciniak, Frantz Rowe *Systèmes d'information, dynamique et organisation* 2009 - 3e éd., Economica, Paris.

## Quelques sites

- Bilan *Les ventes sur Internet ont grimpé de 10% en 2017 20 Février 2018* - Bilan La référence Suisse en économie - http://www.bilan.ch/economie/ventes-internet-ont-grimpe-de-10-2017

- FEVAD *Bilan 2017 du e-commerce en France : les ventes sur internet en hausse de 14% sur un an* 6 février 2018 - https://www.fevad.com/bilan-2017-e-commerce-france-ventes-internet-hausse-de-14-an/

- Forrester *Site Forrester : définition du e-commerce*
2002 - Commun. ACM, doi.acm.org/10.1145/505248.50601

- Thomas C. Redman, Michael Daugherty, Mike Daugherty *Data Quality: The field Guide* 2001 - Sagebrush Education Resources - ISBN 978-0-61-391717-9

- Talend Open studio *Les 10 causes principales des problèmes de qualité de données* 2013 - Livre blanc Talend Open Studio.

- Richard Y. Wang, Veda C. Storey, Christopher P. Firth *A Framework for Analysis of Data Quality Research* 1995 - IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 7, NO. 4, AUGUST 1995

- Y. Wand and R.Y. Wang *Anchoring data quality dimensions in ontological foundations* 1996 - Commun. ACM 39, 11 pages 86-95.
DOI=http://dx.doi.org/10.1145/240455.240479

- Sabrina Zaïdi-Chtourou *La qualité de l'information dans les systèmes d'information marketing* 2009 - Thèse de l'université Jean Moulin Lyon 3

## MDM

- Franck Régnier-Pécastaing, Michel Gabassi, Jacques Finet *MDM : enjeux et méthodes de la gestion des données* 2008 - DUNOD - ISBN 978-2-10-053555-2

- Jean-Christophe Trigaux *Master Data Management* - Mise en place d'un référentiel de données 2009 - http://documentation.smals.be

## Autres

- Gabriel Siméon *Données le vertige* 2012 - Article Libération (http://www.liberation.fr/futurs/2012/12/03/donnees-le-vertige_864585)

- Smile E-commerce Open Source 2009 - Livre blanc Smile

- Smile Décisionnel : Le meilleur des solutions open source 2012 - Livre blanc Smile

- J.M. Juran *Managerial Breakthrough* 1964 - New York: McGraw-Hill

- Rolande Marciniak, Frantz Rowe *Systèmes d'information, dynamique et organisation* 2009 - 3e éd., Economica, Paris.

## Quelques sites

- Bilan *Les ventes sur Internet ont grimpé de 10% en 2017 20 Février 2018* - Bilan La référence Suisse en économie - http://www.bilan.ch/economie/ventes-internet-ont-grimpe-de-10-2017

- FEVAD *Bilan 2017 du e-commerce en France : les ventes sur internet en hausse de 14% sur un an* 6 février 2018 - https://www.fevad.com/bilan-2017-e-commerce-france-ventes-internet-hausse-de-14-an/

- Forrester *Site Forrester : définition du e-commerce*
https://www.forrester.com/eCommerce

- Les meilleures solutions de Business Intelligence selon Forrester 2015 - Journal du Net - https://www.journaldunet.com/solutions/saas-logiciel/meilleures-outils-de-bi-business-intelligence.shtml

- Wikipedia *Mars Climate Orbiter* https://fr.wikipedia.org/wiki/Mars_Climate_Orbiter

- *Problèmes de câblage pour l'A380* ? 2009 - https://www.ladepeche.fr/article/2009/03/15/573829-problemes-de-cablage-pour-l-a380.html

- Mary Shacklett *La mauvaise qualité des données est un problème coûteux : 3 conseils pour progresser* 2015 - http://www.zdnet.fr/actualites/la-mauvaise-qualite-des-donnees-est-un-probleme-couteux-3-conseils-pour-progresser-39830220.htm

- Jean-Michel Franco *La qualité des données, produites par les collaborateurs des entreprises, est essentielle pour maximiser les effets positifs de l'IA* 2017 - https://www.journaldunet.com/solutions/expert/68190/a-l-heure-de-l-automatisation-le-role-de-l-humain-gardien-du-temple-est-renforce.shtml
https://www.forrester.com/eCommerce

- Les meilleures solutions de Business Intelligence selon Forrester 2015 - Journal du Net - https://www.journaldunet.com/solutions/saas-logiciel/meilleures-outils-de-business-intelligence.shtml

- Wikipedia *Mars Climate Orbiter* https://fr.wikipedia.org/wiki/Mars_Climate_Orbiter

- *Problèmes de câblage pour l'A380* ? 2009 - https://www.ladepeche.fr/article/2009/03/15/573829-problemes-de-cablage-pour-l-a380.html

- Mary Shacklett *La mauvaise qualité des données est un problème coûteux : 3 conseils pour progresser* 2015 - http://www.zdnet.fr/actualites/la-mauvaise-qualite-des-donnees-est-un-probleme-couteux-3-conseils-pour-progresser-39830220.htm

- Jean-Michel Franco *La qualité des données, produites par les collaborateurs des entreprises, est essentielle pour maximiser les effets positifs de l'IA* 2017 - https://www.journaldunet.com/solutions/expert/68190/a-l-heure-de-l-automatisation-le-role-de-l-humain-gardien-du-temple-est-renforce.shtml