Projet ITIL

Système de rapports d’incidents
conforme aux normes ITIL pour le

réseau A.S.T.R.I.D
Mémoire présenté en vue de l’obtention du diplôme de
Ingénieur civil Informaticien
Ahmed ABDEEN
Directeur
Professeur Esteban ZIMANYI
Promoteur
Olivier FIRKET
Service Année académique
Web & Information Technologies 2011-2012
Remerciements
Je souhaite adresser mes remerciements les plus sincères aux personnes qui m’ont
apporté leur aide et qui ont contribué à l’élaboration de ce mémoire.
Je tiens à remercier mon promoteur Olivier Firket qui s’est toujours montré à l’écoute
et très disponible tout au long de la réalisation de ce mémoire, ainsi pour l’inspiration,
l’aide et le temps qu’il a bien voulu me consacrer.
Mes remerciements s’adressent également au Professeur Esteban Zimányi, le directeur
de mémoire, pour ses conseils, relectures et retours.
Je remercie également tous les membres de ma famille pour m’avoir supporté pendant
ces longues années d’études. Merci beaucoup Mama, Papa et Ali.
i
Table des matières
Remerciements i
1 Introduction 1
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aperçu d’ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectifs de ce mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 ITIL 4
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 ITIL et l’approche orientée service . . . . . . . . . . . . . . . . . . 4
2.1.3 Pourquoi ITIL ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Conception des services (Service Design) . . . . . . . . . . . . . . . . . . 6
2.2.1 Gestion des niveaux de service . . . . . . . . . . . . . . . . . . . . 7
2.3 L’exploitation des services (Service Operation) . . . . . . . . . . . . . . . 7
2.3.1 Gestion des évènements (Event Management) . . . . . . . . . . . 7
2.3.2 Cas pratique I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3 Gestion des incidents . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.4 Gestion des problèmes (Problem Management) . . . . . . . . . . . 11
2.4 La CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Qualité, nettoyage et validation de données 13

3.1 Qualité de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3 Les dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Nettoyage et validation de données . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Les méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Analyse du problème et solution proposée 23

4.1 Fonctionnalités à implémenter . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Fonctionnement général du programme . . . . . . . . . . . . . . . . . . . 26
ii
TABLE DES MATIÈRES iii
4.3.1 Optique de développement . . . . . . . . . . . . . . . . . . . . . . 26

4.3.2 Les interventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 Choix des infrastructures . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4 Structure de la base de données . . . . . . . . . . . . . . . . . . . 27
4.3.5 Choix des dimensions pour la qualité de données . . . . . . . . . . 28
4.3.6 Nettoyage et validation de données . . . . . . . . . . . . . . . . . 31
4.3.7 Analyse temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Patrons de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 Résultats 36
5.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Guide d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6 Conclusions 41
A Guide d’installation 44
B Exemple de rapport généré 48

Table des figures
1.1 Architecture du réseau A.S.T.R.I.D. extrait de [2]. . . . . . . . . . . . . . 2
2.1 Les composants d’ITIL - schéma des publications tiré de [9]. . . . . . . . 6

2.2 Exemple de KPI’s sur les interventions. . . . . . . . . . . . . . . . . . . . 9
2.3 Les données relatives aux incidents constituent la matière première du
système. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Le processus de la gestion des incidents, extrait de [8]. . . . . . . . . . . 10
3.1 La relation LigueDesChampions. . . . . . . . . . . . . . . . . . . . . . 15

3.2 Le module de nettoyage des données. . . . . . . . . . . . . . . . . . . . . 18
3.3 Classification des erreurs dans les sources de données - inspiré de [21]. . . 21
3.4 La méthode Sorting Neighborhood. . . . . . . . . . . . . . . . . . . . . . 22
3.5 La méthode Sorting Neighborhood - Le calcul des clefs de tri - inspiré de
[12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Format du rapport à générer. . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Quelques outils de reporting. . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Exemple de ticket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Le déroulement d’une intervention. . . . . . . . . . . . . . . . . . . . . . 27
4.5 La base de données existante. . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Les colonnes ajoutée à la table Intervention. . . . . . . . . . . . . . . . . 29
4.7 Exemple illustrant les deux significations de la valeur NULL. . . . . . . . 29
4.8 Exemple illustrant une incohérence. . . . . . . . . . . . . . . . . . . . . . 30
4.9 Exemple de valeurs inexactes. . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1 La fenêtre principale du programme. . . . . . . . . . . . . . . . . . . . . 37

5.2 L’adresse de la base de données. . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Le module qualité des données. . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Les incidents débordants. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Le rapport mensuel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 Le rapport hebdomadaire. . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.7 Le rapport annuel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.1 Installation - 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2 Installation - 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.3 Installation - 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.4 Installation - 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.5 Installation - 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iv
TABLE DES FIGURES v
A.6 Installation - 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.1 SLA’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.2 MTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.3 WTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.4 YTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.5 Les données - 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.6 Les données - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Listings
4.1 La stabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 La complétude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 La cohérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 L’exactitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Stockage des dates indésirables dans un fichier XML . . . . . . . . . . . . 31
4.6 Déclencheur de réinitialisation . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Nettoyage de données 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.13 Validation de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.14 Le gestionnaire de la base de données (DataManager) . . . . . . . . . . . 34
vi
Chapitre 1
Introduction
Dans ce chapitre, nous allons introduire ce mémoire en décrivant le contexte dans

lequel il s’inscrit. Ensuite, nous ferons une brève introduction d’ITIL. Finalement, nous
terminerons ce chapitre en énonçant les objectifs de ce mémoire.
1.1 Contexte
Le réseau A.S.T.R.I.D (pour All around Semi-cellular Trunked Radio and Integrated
Dispatching) est un réseau dédié aux radiocommunications des services de secours et de
sécurité en Belgique employant un système radio digital TETRA 1 . Ce réseau est géré par
la société de même nom A.S.T.R.I.D SA qui fût créée en 1998 par l’État belge dans le
but de coordonner les différents services de secours.
En effet, l’État belge a constaté un manque de coordination entre ces services suite à
deux faits précurseurs qui sont les drames de Heysel 2 et de Herald of Free enterprise 3 .
Afin d’arriver à ses fins, A.S.T.R.I.D a conclu un contrat de maintenance du réseau
radio avec Belgacom et Cassidian 4 . Belgacom, quant à elle, sous-traite la partie logicielle
à Intergraph. Ce mémoire se déroule au sein de la compagnie Intergraph.
1. TETRA (pour TErrestrial Trunked RAdio) est une norme développée en Europe pour les radio-
communications digitales de voix et de données conçue pour les besoins professionnels et en particulier,
pour les services de secours et de sécurité. Les systèmes A.S.T.R.I.D reposent sur cette norme TETRA
et fonctionnent dans la bande de fréquence 380 - 400 Mhz, spécialement réservée aux services de secours
et de sécurité en Europe [?].
2. Le drame du Heysel, survenu le 29 mai 1985 à Bruxelles en Belgique, est l’une des tragédies les
plus marquantes liées à une manifestation sportive, et due au hooliganisme. Il eut lieu à l’occasion
de la finale de Coupe d’Europe des clubs champions 1984-1985 entre le Liverpool Football Club et la
Juventus Football Club. Des grilles de séparation et un muret s’effondrèrent sous la pression et le poids
de supporters, faisant 39 morts et plus de 600 blessés [28].
3. Le Herald of Free Enterprise est un ferry de la compagnie Townsend Thoresen qui assurait la liaison
transmanche entre Douvres et Zeebruges. Il chavira le 6 mars 1987 au large du port de Zeebruges, faisant
193 morts [30].
4. Cassidian est la division de défense et de sécurité d’EADS (pour European Aeronautic Defence and
Space Company).
1
Chapitre 1 : Introduction 2
Comme montré à la Figure 1.1, le réseau A.S.T.R.I.D est constitué de onze CIC’s
(pour Centre d’Information et de Communication), un CIC par province plus un CIC
pour la région de Bruxelles-capitale [3].
Chaque CIC comporte tous les équipements nécessaires au routage des communica-
tions. Les CIC’s réunis constituent le cerveau du réseau A.S.T.R.I.D. Toutes les demandes
d’appels et les appels eux-mêmes transitent par les CIC’s. Ils connaissent à chaque instant
la position d’un poste allumé se trouvant sous la couverture du réseau. Ils sont également
connectés à des systèmes externes comme les réseaux téléphoniques fixes ou mobiles [4].
Figure 1.1 – Architecture du réseau A.S.T.R.I.D. extrait de [2].
Comme cité plus haut, la partie logicielle qui permet aux opérateurs d’effectuer leur
travail est assurée par Intergraph. Afin de bien gérer l’infrastructure informatique, Inter-
graph s’appuie sur ITIL, une bibliothèque regroupant les bonnes pratiques concernant la
fourniture et la gestion de services informatiques.
Ce mémoire prend corps sous la direction d’Intergraph et a pour but de fournir un
logiciel de reporting. Cet outil a pour mission de faciliter la tâche de support des logiciels.
1.2 Aperçu d’ITIL

ITIL (pour Information Technology Infrastructure Library) est un ensemble de bonnes
pratiques pour les infrastructures informatiques. Cet ensemble de bonnes pratiques per-
met de surmonter les difficultés liées à la croissance des systèmes informatiques. Une
étude plus approfondie d’ITIL est réalisée dans le chapitre suivant.
Chapitre 1 : Introduction 3
1.3 Objectifs de ce mémoire

En connaissant le contexte, et en ayant eu un bref aperçu d’ITIL, nous pouvons main-
tenant énoncer les objectifs de ce mémoire. Il s’agit de déployer un logiciel de reporting
correspondant à différentes attentes et contraintes.
Le logiciel se compose de trois modules. Le premier module est l’outil de reporting de
base. Celui-ci a pour but principal de générer des rapports qui respectent un format bien
déterminé.
Le deuxième module sera principalement un outil de comparaison entre les différents
sites CIC’s. Cet outil servira de support pour le premier outil dans le sens où il pourrait
aider à expliquer les résultats obtenus dans les rapports générés.
Après avoir commencé le travail, nous nous sommes rendu compte de la nécessité de
l’implémentation d’un troisième module. Ce dernier module nous permettra de :
– Faire une estimation de la qualité des données
– Nettoyer les données et dire lesquelles sont valides
Chapitre 2
ITIL
2.1 Introduction
2.1.1 Historique
Le concept d’ITIL trouve ses origines dans les années 80. Dans ces années là, le gou-
vernement britannique s’était rendu compte que le niveau de la qualité des services IT qui
leur sont fournis n’était pas suffisant. Suite à la demande du gouvernement britannique,
la CCTA (pour Central Computing and Telecommunications Agency), aujourd’hui connu
sous le nom de OGC (pour Office of Government Commerce), avait déjà rédigé plusieurs
livres sur la gestion des services informatiques dans les années 90. L’objectif était de
développer des méthodes efficaces afin de garantir un certain niveau de qualité des ser-
vices informatiques, en d’autres mots, avoir un recueil de bonnes pratiques. L’ensemble
de ces ouvrages constituent ITIL.
2.1.2 ITIL et l’approche orientée service

De nos jours, que ce soit dans le domaine informatique ou dans beaucoup d’autres
domaines, les produits ne sont plus vendus comme ça se faisait dans le passé. En ef-
fet, chaque produit pratiquement est vendu sous la forme d’un service. Que ça soit une
garantie sur le produit même, un support après vente, ..., etc.
Dans ITIL, un service est défini comme suit :
2.1 Définition
Un service est un moyen de délivrer de la valeur aux clients en facilitant la production
des résultats dans leurs activités sans qu’ils aient à se préoccuper des coûts et des risques
spécifiques au service qui leur est fourni [9].
Produit et service, tous deux, sont là pour satisfaire les besoins des utilisateurs.
Néanmoins, la grande différence entre un produit et un service est que dans le cas d’un ser-
vice les utilisateurs s’en servent sans devoir le posséder. Par exemple, si nous considérions
l’industrie automobile, dans le passé les voitures étaient vendues en tant que produits,
4
Chapitre 2 : ITIL 5
c’est-à-dire lors d’une panne c’est la responsabilité de l’utilisateur de faire la réparation.

Aujourd’hui, ce produit est souvent vendu comme un service en étant associé à un ser-
vice de garantie (la voiture et le service de garantie constitue le service final), si jamais
pendant un certain nombre d’années une panne a lieu alors c’est la responsabilité du
constructeur de réparer la panne.
2.1.3 Pourquoi ITIL ?

La première question que nous pourrions nous poser est, pour quelle(s) raison(s)
utiliser ITIL ? Dans ce qui suit, nous allons essayer de répondre à cette question. De
manière générale, les technologies d’information peuvent être très complexes. Afin de
gérer cette complexité, il est important de définir des processus claires, consistants et bien
définis (qui peuvent être répétés). ITIL permet d’identifier, d’améliorer et de documenter
les processus mis en œuvre. Ce qui peut résulter en une amélioration de l’organisation de
l’entreprise.
2.2 Définition
Un processus est un ensemble d’activités coordonnées mettant en œuvre des ressources
et des capacités en vue de produire un résultat aux clients [15].
Chacun des ouvrages de base qui constituent ITIL (au nombre de cinq) est destiné
à améliorer un certain nombre de points bien précis dans une entreprise. En un premier
temps, nous allons parcourir ces points pour chaque ouvrage. Ensuite, nous allons détailler
les points qui sont directement liés au contexte de ce mémoire.
Stratégie des services (Service Strategy) [17] : Ce volume de haut niveau ex-
plique comment faire l’alignement du système d’informations avec l’entreprise, en
d’autres mots, comment l’entreprise peut tirer profit de l’utilisation de l’IT. L’accent
est aussi mis sur l’aspect financier.
Conception des services (Service Design) [15] : Dans cet ouvrage, chaque ser-
vice est examiné afin de déterminer la façon de le concevoir pour qu’il puisse être
implémenté dans le système d’informations tout en étant efficace et compétitif.
Transition des services (Service Transition) [18] : Cet ouvrage décrit les ob-
jectifs de la phase de transition des services qui sont : la planification et la gestion
des ressources pour une transition (ajout ou modification d’un service) réussie, la
réduction d’impacts non prévus sur les services en production, ..., etc.
Exploitation des services (Service Operation) [16] : Le but de l’exploitation
des services est de s’assurer de la bonne (au niveau convenu lors de la concep-
tion des services) fourniture et gestion des services IT. L’exploitation des services
comprend : la résolution des défaillances du service, la résolution des problèmes, ...,
etc.
Amélioration continue des services (Continual Service Improvement) [14] :
Ce processus, comme son nom le laisse entendre, a pour objectif l’amélioration conti-
nue de l’efficacité des services en se basant sur des méthodes de gestion de qualité.
La Figure 2.1 illustre la manière de fonctionnement (continu) des composants d’ITIL
les uns par rapport aux autres.
Chapitre 2 : ITIL 6
Figure 2.1 – Les composants d’ITIL - schéma des publications tiré de [9].
2.2 Conception des services (Service Design)

Cette partie d’ITIL a pour but d’assurer que les services sont conçus de façon à
répondre aux besoins d’affaires (Business). Dans la conception des services, plusieurs
processus sont définis comme : la gestion de la disponibilité, la gestion des niveaux de
service, la gestion de la capacité, ..., etc. Dans la suite, seuls les processus qui sont en lien
direct avec le contexte de ce mémoire seront présentés.
Lors de la conception de services, plusieurs aspects doivent être pris en compte. Parmi
ces aspects nous pouvons citer [9] :
L’alignement sur les besoins d’affaires : Les objectifs d’affaires doivent être sa-
tisfaits par la conception des services.
L’optimisation des délais et des coûts : Il faut avoir à l’esprit qu’après la phase
de conception des services, ces derniers vont être améliorés au fur et à mesure et
donc penser à minimiser les coûts à long terme.
La gestion des risques : Avant que les services passent en production, il est nécessaire
de connaı̂tre les risques pour pouvoir les éliminer ou les réduire (au moins).
La mesures des objectifs : Pour pouvoir améliorer les services, il faut d’abord
connaı̂tre le niveau d’atteinte des objectifs. Pour cela, des méthodes ainsi que des
métriques doivent être conçus.
Chapitre 2 : ITIL 7
2.2.1 Gestion des niveaux de service

La gestion des niveaux de service est un processus qui vise à trouver un accord sur
le niveau de service entre le fournisseur de service et le client pour ensuite concevoir le
service en tenant compte de ces accords. Ces accords sont les niveaux de service ou SLA
(pour Service Level Agreement).
2.3 Définition
Un accord sur les niveaux de service (Service Level Agreement ou SLA)
est un accord écrit entre un fournisseur de services et un ou des clients. Il porte sur
un ou plusieurs services d’affaires et décrit les niveaux de services prévus avec la ou les
organisations d’affaires (disponibilité, capacité, sécurité et continuité de service) [9].
Ces SLA’s constituent une façon formelle et donc mesurable pour définir les respon-
sabilités de chaque partie (client et fournisseur). Afin de pouvoir quantifier ces SLA, des
indicateurs clés de performance ou KPI’s (pour Key Performance Indicator ou KPI )
sont fixés. Ensuite, ce sont les KPI’s qui seront mesurés afin de savoir si les SLA’s ont
été respectés ou pas.
2.4 Définition
Un indicateur clé de performance (Key Performance Indicator ou KPI)
est un ensemble de métriques objectives et mesurables qui permettent d’évaluer si les
différents niveaux de services convenus (SLA) ont été respectés.
ITIL propose également de définir d’une manière claire et précise des pénalités au cas
où des SLA’s n’ont pas été respectés et ceci en selon le manquement observé.
2.3 L’exploitation des services (Service Operation)

C’est dans cette étape que le service est fourni à l’utilisateur. Une fois que le service
est fourni, il faut le gérer. Pour cela, il est nécessaire de collecter des données, de faire
des mésures, de vérifier les performances, ..., etc. L’exploitation des services est donc une
étape très importante puisque c’est à ce moment qu’on voit à quel niveau les besoins des
utilisateurs ont été satisfaits. Dans ce qui suit, nous allons décrire quelques processus de
l’exploitation des services.
2.3.1 Gestion des évènements (Event Management)

L’intérêt de la gestion des évènements est de s’assurer que les services fournis sont
bien surveillés afin de pouvoir détecter les évènements qui se produisent. Dans ITIL, un
évènement est défini comme suit :
2.5 Définition
Un évènement est une occurrence détectable ou discernable ayant une signification sur
la gestion d’une infrastructure ou la fourniture d’un service et une évaluation de l’impact
indiquant qu’une déviation pourrait apparaı̂tre sur les services [9].
Chapitre 2 : ITIL 8
Afin de pouvoir facilement décider de l’action (appropriée) à prendre, les évènements

seront classés selon des catégories. Il est évident que chaque entreprise aura sa propre
catégorisation mais ITIL propose d’utiliser au moins les trois catégories suivantes :
Évènements informationnels Ces évènements signalent des opérations régulières
et ne requièrent aucune action à prendre. Il seront enregistrés dans le système pour
une certaine période. Des exemples de tels évènements sont : une transaction est
terminée avec succès, une imprimante est prête à être utilisée, un appareil peut être
retiré en toute sécurité, ..., etc.
Évènements d’alerte Ces évènements signalent des opérations inhabituelles. Lors-
qu’ils sont pris en compte, ils permettent d’éviter l’apparition d’une exception. Nous
pouvons citer comme exemples : l’utilisation de la mémoire approche un seuil cri-
tique (au delà duquel, un SLA pourrait être manqué), une transaction est terminée
avec succès mais avec 10% plus de temps que d’habitude, ..., etc.
Évènements signalant une exception Ces évènement signalent qu’un service fonc-
tionne de façon anormale. Les exceptions résultent souvent en un manquement d’un
SLA. Des exemples d’exception sont : l’utilisation de la mémoire a dépassé un seuil
critique, une transaction a échoué, ..., etc.
2.3.2 Cas pratique I

Comme suggéré par ITIL, des SLA’s, des KPI’s et des pénalités ont été fixés au sujet
de la maintenance préventive et réactive. De plus, chaque incident (ou problème) se voit
attribué une priorité en fonction de sa gravité.
La maintenance réactive
La maintenance réactive comprend la réparation les incidents qui apparaissent dans

le système de façon à ce que les délais imposés par les SLA’s soient respectés. Il est donc
primordial de savoir, à tout moment, si les SLA’s sont respectés ou non. Or, Intergraph n’a
pas accès à la base de données des incidents (détenue par son client, Belgacom). Intergraph
a donc développé un outil afin d’avoir une trace sur les incidents. Concrètement, cet
outil est utilisé par les ingénieurs de site. L’outil développé dans ce mémoire se base
sur les informations fournies par les ingénieurs de site et permettra de suivre l’évolution
des SLA’s ainsi que de générer des rapports comparables à ceux produits par le client
(Belgacom).
A titre indicatif, un exemple (nombres fictifs) de KPI’s est donné à la Figure 2.2.
La maintenance préventive
Un second mémoire ayant pour titre ”Outils de monitoring conforme ITIL : Appli-
cation au réseau A.S.T.R.I.D.” a été réalisé dans le même contexte de ce mémoire par
Nicolas Vannieuwerburgh. A travers ce mémoire, un outil de maintenance préventive a
été réalisé.
Chapitre 2 : ITIL 9
Priorité Temps de réponse

Priorité Temps de résolution
1 4 heures
1 4 heures pour 98% des incidents
12 heures 5 heures pour 100% des incidents
2
2 24 heures
3 Fin du jour ouvrable
suivant 3 Fin du jour ouvrable
suivant
4 --- 4 5 jours ouvrables
(a) Temps de réponse (b) Temps de résolution
Figure 2.2 – Exemple de KPI’s sur les interventions.
2.3.3 Gestion des incidents

Quelque soit le niveau de qualité des systèmes informatiques, des incidents se pro-
duisent toujours. Si ces incidents ne sont pas résolus rapidement, ils peuvent avoir un
impact négatif sur la confiance des utilisateurs. C’est pourquoi il est très important pour
une entreprise d’implanter un processus de gestion des incidents.
2.6 Définition
Un incident est un évènement entrainant une interruption ou une baisse de qualité
pour un service. Les évènements ayant un impact potentiel mais non encore observé sont
également considérés comme des incidents.
La gestion des incidents est un point clé dans le cadre de ce mémoire. En effet, nous
pouvons voir l’outil de reporting comme un système avec une entrée et une sortie. A
l’entrée de ce système, nous retrouvons les données relatives aux incidents, et à sa sortie,
des rapports permettant de vérifier l’état des SLA’s (maintenance réactive). Voir figure
2.3. Ci-dessous, une définition de la gestion des incidents est proposée :
2.7 Définition
La gestion des incidents est un processus responsable de la gestion du cycle de vie de
tous les incidents [9]. Ce processus doit garantir la restauration du fonctionnement normal
des services (dans les limites des SLA’s) , aussi vite que possible, tout en minimisant
l’impact négatif sur les activités métiers.
Nous pouvons donc dire que le but de la gestion des incidents est le rétablissement
rapide du fonctionnement normal du service. Contrairement à la gestion des problèmes, la
gestion des incidents ne se préoccupe pas des causes des incidents, on résout les incidents
peu importe le moyen.
Pour mieux visualiser, voici quelques exemples d’incidents :
– Les requêtes de la base de données prennent un temps plus long que ce qui est défini
par le SLA
– Le nombre d’entrée/sortie d’un disque dur est trop grand
– Le serveur d’une base de données a échoué
– ...
Chapitre 2 : ITIL 10
Rapports (KPI)
Données
Programme Qualité des
relatives
données
aux incidents
Comparaison
par site CIC
Figure 2.3 – Les données relatives aux incidents constituent la matière première du
système.
Pourquoi un processus de gestion des incidents ?
La gestion des incidents permettra entre autres de :

– Empêcher les incidents de devenir critiques et affecter la qualité de service
– Avoir une trace de tous les incidents qui se produisent, de cette façon on évite de
refaire tout le travail pour résoudre ce même type d’incidents.
Description du processus
La Figure 2.4 représente les cinq étapes du processus de la gestion des incidents. Tout
d’abord la détection et l’enregistrement de l’incident : à cette étape on peut déterminer si
l’incident a déjà eu lieu et si une solution rapide existe, la classification de l’incident : cette
étape permet d’attribuer une priorité à l’incident, la recherche et diagnostic, la résolution
et la restauration du service et pour terminer la clôture de l’incident avec la remise du
rapport (qui contient entre autres, le temps passé, détails des actions effectuées, ..., etc.).
Enregistrement
de l ’incident
Fermeture
de l ’incident
Classification
Début de l ’incident Fin
Résolution et
restauration
Recherche et du service
diagnostic
Figure 2.4 – Le processus de la gestion des incidents, extrait de [8].

2.3.4 Gestion des problèmes (Problem Management)

La gestion des problèmes est un processus qui s’occupe de gérer le cycle de vie de
tous les problèmes. Ce processus a pour but d’empêcher que des incidents aient lieu et de
minimiser leur impact sur le Business lorsqu’ils ne peuvent pas être évités. ITIL définit
les problèmes comme suit :
2.8 Définition
Un problème est la cause d’un incident ou d’une série d’incidents.
Citons quelques exemples de problèmes :

Problèmes
– Défaillance systématique d’un programme lors de certaines manipulations
– Défaillance d’un serveur provoquant plusieurs incidents sur les machines clientes
– Défaillance régulière d’un service sans pistes de solution
– ...
2.4 La CMDB
La CMDB (pour Configuration Management DataBase) est une base de données de
gestion des configurations. L’objectif de la CMDB est de stocker les détails des éléments
de configuration CI (pour Configuration Item) ainsi que les relations entre eux pendant
tout leur cycle de vie. ITIL définit un élément de configuration comme suit :
2.9 Définition
Un élément de configuration est tout composant ou autre actif de service dont la
fourniture d’un service informatique requiert sa gestion [9].
Un élément de configuration peut être :

– un service informatique
– un utilisateur
– un SLA
– le matériel
– un incident
– ...
En particulier, la CMDB est à la base de tous les processus de traitement des incidents
et des problèmes.
2.5 Conclusions
Dans ce chapitre, nous avons présenté ITIL de façon générale en expliquant la raison
d’être de ces différents composants : la stratégie des services, la conception des services, la
transition des services, l’exploitation des services et l’amélioration continue des services.
Ensuite, nous nous sommes focalisés sur les processus qui sont en lien direct avec le
contexte de ce mémoire.
Pour terminer, il est important de mettre l’accent sur le fait qu’ITIL n’a pas de
frontières strictes. C’est à dire que toute entreprise désirant implémenter ITIL, peut le
faire selon ses besoins. Du coup, il est difficile de trouver deux entreprises ayant une même
implémentation d’ITIL.
Chapitre 3
Qualité, nettoyage et validation de

données
3.1 Qualité de données
3.1.1 Introduction
Les données sont considérées comme une ressource précieuse car elles constituent la
matière première dans un système d’informations. Il est donc nécessaire de s’assurer que
ces données sont complètes, précises, correctes, ..., etc. Autrement dit, les données doivent
avoir une certaine qualité.
Ce chapitre sert de base pour l’élaboration de l’outil de nettoyage de données (le
troisième module). En effet, nous allons expliquer, dans ce chapitre, les métriques que
nous allons utiliser afin de pouvoir détecter les problèmes liés aux données. De cette façon,
nous pourrons donner un indice sur la qualité de nos données. Les sections suivantes seront
consacrées à la réparation des éventuels problèmes détectés et à la validation des données.
3.1.2 Définition
Dans la littérature, nous retrouvons plusieurs définitions pour la qualité de données.
Une de ces définitions est la suivante :
3.1 Définition
Une donnée est de qualité si elle satisfait aux exigences de son utilisation dans un
contexte donné [19].
Dans cette définition, on considère une approche contextuelle. C’est cette approche
là qui sera considéré dans ce travail. En effet, la qualité des données dépend très fort
des données mêmes ainsi que du contexte dans lequel ces données sont utilisées. Ainsi,
les mêmes données peuvent être de grande qualité pour un usage et de mauvaise qualité
pour un autre usage. De cette façon, dire que des données sont de qualité dans l’absolu
n’a pas de sens, il faudrait préciser les critères que l’on considère ainsi que l’usage de
13
Chapitre 3 : Qualité, nettoyage et validation de données 14
ces données. Du coup, il n’existe pas de recette toute faite qui fonctionne dans tous les
cas. Dans le contexte de ce mémoire (qui sera détaillé dans le chapitre suivant), quatre
critères sont considérés afin de pouvoir faire une estimation de la qualité de nos données.
Nous détaillerons ces aspects dans la section suivante.
3.1.3 Les dimensions

La qualité de données est une agrégation de plusieurs critères (ou dimensions) comme
la complétude (completeness), l’exactitude (accuracy), ..., etc. Dans les ouvrages de
référence, les dimensions de la qualité de données sont souvent définies différemment
(nom et signification). Il est à noter que 179 dimensions on été définies en 1996 [26] pour
la qualité de données. Dans le contexte de ce mémoire, il n’y a pas d’intérêts de faire une
étude de toutes ces dimensions. Dans ce qui suit, nous tenterons de définir et donner des
exemples de quelques dimensions des plus répandues et ensuite (voir le prochain chapitre)
nous ferons un choix parmi ces dimensions qui nous permettra de mieux répondre aux
exigences de ce travail.
L’exactitude (accuracy)
Ci-dessous une définition de l’exactitude est proposée.
3.2 Définition
L’exactitude est la proximité d’une valeur A à une autre valeur B considérée comme
la représentation correcte d’une entité réelle que A tente de représenter [5].
Deux types d’exactitude peuvent être distingués ici, une exactitude syntaxique et une
exactitude sémantique [5].
L’exactitude syntaxique est la proximité d’une valeur A par rapport aux éléments
de l’ensemble de définition de A, disons D. Ainsi, la valeur A = Belgique est considérée
comme une valeur correcte même si B = Italie, si le domaine D est l’ensemble des pays
de l’Europe.
Considérons la relation LigueDesChampions montrée à la Figure 3.1. Cette relation
représente des équipes de football ayant disputé ce tournoi européen de football avec le
nom, le pays d’origine, l’année de fondation, le nombre de fois où l’équipe a remporté le
tournoi ainsi que l’année du dernier triomphe. La valeur A.C. Mlan pour le Nom de
l’équipe 3 n’est pas exacte syntaxiquement, puisque cette valeur ne correspond à aucune
équipe de football européenne ayant participé à la Ligue des champions. Par contre, si
nous comparions cette valeur à toutes les valeurs du domaine en question, nous trouverions
une distance de Levenstein 1 égale à 1 (comparaison avec la valeur A.C. Milan). En effet,
l’exactitude syntaxique peut être mesurée en utilisant une fonction de comparaison (ici
la distance de Levenstein).
1. La distance de Levenshtein mesure la similarité entre deux chaı̂nes de caractères. Elle est égale
au nombre minimal de caractères qu’il faut supprimer, insérer ou remplacer pour passer d’une chaı̂ne à
l’autre. Elle est aussi connue sous le nom de distance d’édition ou encore de déformation dynamique
temporelle [27].
Id Nom Pays Fondé # de titres Dernier titre
1 Real Madrid C.F. Espagne 1902 9 1908
2 A.C. Mlan Italie 1899 7 2007
3 Liverpool F.C. Allemagne 1892 5 NULL
4 FC Bayern Munich Angleterre 1900 4 2001
5 FC Barcelona Espagne 1899 4 2011
6 RSC Anderlecht Belgique 1908 0 NULL
Figure 3.1 – La relation LigueDesChampions.
L’exactitude sémantique est la proximité de la valeur A par rapport à la vraie valeur

B. Ainsi si nous considérions l’exemple donné à la Figure 3.1, nous pouvons remarquer
que les Pays des équipes 3 et 4 ont été permutés. Du coup, les valeurs Allemagne et
Angleterre ne sont pas exactes sémantiquement malgré qu’elles le sont syntaxiquement.
La complétude (completeness)
La complétude peut être définie en général comme suit :
3.3 Définition
La complétude se réfère au fait d’avoir toutes les parties requises d’un assemblage de
données présentes.
Dans [20], trois types de complétude sont proposés. La complétude au niveau du

schéma, la complétude au niveau de la colonne et la complétude au niveau de la popula-
tion.
La complétude au niveau du schéma est définie comme le degré avec lequel toutes les
entités et les attributs sont représentés. La complétude au niveau de la colonne est une
mesure des valeurs manquantes d’une colonne dans une table. La complétude au niveau
de la population, quant à elle, est une mesure des valeurs manquantes par rapport à une
autre population de référence.
Dans un modèle relationnel, la présence de la valeur NULL (lorsque c’est permis)
peut avoir plusieurs significations. Afin de pouvoir mesurer la complétude (au niveau de
la colonne), il est important de comprendre pourquoi une valeur manque. Dans l’exemple
de la Figure 3.1, Liverpool F.C. et RSC Anderlecht ont toutes les deux une valeur
NULL dans la dernière colonne. Le tuple de Liverpool F.C. est incomplet, puisque
Liverpool F.C. a déjà remporté 5 titres, tandis que le tuple de RSC Anderlecht est
complet car ce dernier n’a pas encore remporté de titres.
La cohérence (consistency)
La cohérence concerne tout ce qui se rattache à la violation des règles sémantiques.

Dans les modèles relationnels, la cohérence concerne le non respect des contraintes d’intégrités.
Dans l’exemple de la Figure 3.1, il y a un problème de cohérence pour le tuple de Real
Madrid C.F. au niveau des trois dernières colonnes. En effet, sachant que le tournoi de
la ligue des champions est organisé une fois par an, cette équipe ne peut pas avoir gagné
neuf titres en sept ans. Par contre, il n’est pas possible de dire d’où provient l’erreur
(d’une seule colonne, de deux colonnes parmi les trois ou de toutes les trois colonnes).
La promptitude (timeliness)
Dans le monde de l’information, le mot anglais timeliness peut être traduit en français
de plusieurs manières : opportunité, ponctualité, rapidité, ..., etc. Cette dimension tem-
porelle désigne le caractère à jour des données. Ci-dessous, une définition est proposée :
3.4 Définition
La promptitude est le degré d’actualité des données en tenant compte des tâches dans
lesquelles elles sont utilisées [20].
La volatilité (volatility)
La volatilité est la durée pendant laquelle les données demeurent valides [20]. Par
exemple, les dates de naissance sont des données stables qui ne varient jamais et par
conséquent ont une volatilité égale à 0. Un exemple de données très volatiles est celui des
cours boursiers.
Le tableau suivant donne plusieurs définitions pour les dimensions précédentes.
Dimension Définition
L’exactitude Le niveau avec lequel les données sont correctes, fiables
et certifiées exempts d’erreurs [5].
La complétude Le degré de la présence de valeurs dans une collection
de données [22].
La cohérence Le degré avec lequel les données sont toujours
représentées de la même façon et sont compatibles avec
les données précédentes [5].
La promptitude La mesure dans laquelle l’âge des données est approprié
pour la tâche considérée [5].
La volatilité La fréquence avec la quelle les données varient dans le
temps [7].
3.2 Nettoyage et validation de données

3.2.1 Introduction
Le nettoyage de données (data cleansing, data cleaning ou encore data scrubbing en
anglais) est une étape importante dans le processus de gestion de l’information [1]. En
effet, il est pratiquement impossible d’avoir des données sans erreurs (surtout quand il
s’agit de données volumineuses).
Ces erreurs peuvent avoir deux causes : elles sont créées pendant le traitement des
données (mauvaise modélisation de l’architecture du système) ou alors elles parviennent
depuis la source de données (qui constitue le facteur majeur). Même en améliorant le
processus d’acquisition et d’entrée de données, des erreurs peuvent toujours apparaı̂tre
dans le système. Il est donc nécessaire de parcourir les données afin de détecter les erreurs
et de les corriger, ce qui est très coûteux pour des données volumineuses.
3.2.2 Définition
Le nettoyage de données peut être défini différemment selon le domaine dans lequel il
est appliqué. Les principaux domaines dans lesquels le nettoyage de données a été étudié
sont : les entrepôts de données, l’exploration de données 2 et la gestion de la qualité de
données [13]. Le tableau suivant donne quelques définitions pour le nettoyage de données
en fonction du contexte.
Définition Domaine
Le processus qui permet d’identifier et de corriger les informations Base de données fi-
incomplètes et incorrectes dans les bases de données [24]. nancières.
Le processus de découverte des formes de données inutiles, vides de L’apprentissage au-
sens ou mal étiquetées [10]. tomatique (machine
learning en anglais).
Le nettoyage de données s’occupe de détecter et enlever les erreurs Entrepôt de données
et les inconsistances dans les données dans le but d’améliorer leur
qualité [21].
Nous pouvons donc voir le nettoyage de données comme un processus qui, à son
entrée, reçoit des données brutes qui pourraient contenir un certain nombre d’erreurs et
qui génère à sa sortie un sous-ensemble de ces données exempt de ces erreurs. La Figure
3.2 résume la situation.
Donc, pour implémenter un outil de nettoyage de données, la première étape à faire
est de définir les problèmes que nous voudrions éviter dans nos données (comme définis
dans la section précédente). Ensuite, il faut écrire les règles qui permettent de détecter
ces problèmes. Finalement, il faut remédier les problèmes détectés lorsque c’est possible.
2. L’exploration de données (data mining en anglais) a pour objet l’extraction d’un savoir ou d’une
connaissance à partir de grandes quantités de données, par des méthodes automatiques ou semi-
automatiques [29].
Définition Qu ’est ce qu ’une

des donnée de
bonne qualité ??
problèmes
Données Nettoyage Données

brutes propres
de données
Eventuellement
de mauvaise
qualité
De meilleure Données Validation

qualité
valides
de données
Figure 3.2 – Le module de nettoyage des données.
Les problèmes dans les données peuvent être classifiées en deux catégories, selon que
les données sont collectées à partir d’une seule source ou de plusieurs sources, voir Figure
3.3(a). Nous pouvons aussi distinguer entre les problèmes au niveau tuples (c’est ce type
de problèmes que le nettoyage de données tente de résoudre) et ceux au niveau du schéma
(dont la résolution nécessite une transformation des données). Dans la suite, nous nous
restreignons au problèmes au niveau tuples.
Une vue d’ensemble est proposée à la Figure 3.3(b). En effet, il est évident que les
problèmes issus de plusieurs sources englobent ceux dans le cas d’une seule source.
Les erreurs dans les données peuvent se produire à l’acquisition ou pendant le traite-
ment dans la chaı̂ne de la gestion de l’information. Un exemple de traitement intéressant
qui pourrait générer des erreurs est l’intégration des données. En effet, lors de l’intégration
de différentes bases de données des doublons (plusieurs représentation d’une même entité
réelle) peuvent apparaı̂tre. En effet, nous pouvons distinguer deux cas de figures lors de
l’agrégation de différentes tables :
– Les attributs des tables peuvent être structurés différemment. Par exemple, dans
une base de données, le nom d’un client peut être enregistré dans une seule colonne
(nom) tandis que dans une autre base de données, ce même nom de client peut être
enregistré à l’aide de plusieurs colonnes (civilité, prénom, nom).
– Même lorsque les attributs des tables sont identiques, un même objet réel peut être
représenté différemment. Par exemple, les adresses bvd Émile Jacqmain, Boulevard
É. Jacqmain et bvd É. Jacqmain sont la représentation d’une même adresse.
Ce type de problème est appelé le problème de ”merge-purge” (dans le domaine des

entrepôts de données). Dans la littérature, d’autres appellations existent pour ce même
type de problème comme : ”record linkage”, ”semantic integration”, ”instance identifica-
tion” ou encore ”object identity” [12].
3.2.3 Les méthodes

Les méthodes appliquées dans le processus de nettoyage de données sont multiples.
Celles-ci peuvent être réparties en deux catégories : les méthodes dépendantes de domaine
et celles indépendantes de domaine. La majorité des méthodes que nous retrouvons dans
la littérature tentent de résoudre des problèmes spécifiques. Cela peut être expliqué par
le fait qu’il est très compliqué de développer des méthodes efficaces qui peuvent être
appliquées partout. De plus, comme nous allons le voir dans les sections qui suivent, la
connaissance du contexte permet d’améliorer la performance des méthodes.
Les méthodes les plus répandues tentent de résoudre les problèmes des doublons et
les problèmes dans les noms propres et les adresses postales.
Élimination de doublons
Beaucoup de travaux, comme dans [6], [11],[31] et [23], ont été réalisés afin de détecter
les doublons et les doublons similaires 3 . Dans la plupart de ces travaux, les méthodes
présentées se reposent sur des fonctions de tri ainsi que des fonctions de comparaison de
similarité. Naturellement, l’efficacité de ce type de méthodes dépend très fort de la façon
dont on compare les différentes entrées. Ainsi pour une base de données avec N entrées,
le nombre de comparaison à effectuer est de (N −1)·N2
ce qui peut être très lent pour un N
élevé.
[11] présente une méthode (Sorted Neighborhood Method) afin de limiter le nombre
de comparaisons et du coup accélérer le calcul. La modification apportée dans cette
méthode est que le tri est effectué de façon à regrouper les entrées similaires. Ensuite, la
comparaison est effectuée seulement pour un nombre fixe d’entrées (la fenêtre, w) ce qui
demande N · w comparaisons. Encore une fois, l’efficacité de cette méthode dépend de
bon choix de la clef utilisée pour effectuer le tri (spécifique au domaine). La Figure 3.4
illustre le fonctionnement de cette méthode.
Les clefs peuvent être obtenues en concaténant plusieurs attributs ou plusieurs sous-
ensembles de ces attributs. La Figure 3.5 donne un exemple de construction de clefs. Dans
cet exemple, la clef a été construite de la façon suivante : les trois premiers chiffres du
numéro d’identification à la sécurité sociale sont concaténés avec les trois premières lettres
du prénom, suivis par les trois premières consonnes du nom. Ensuite, on ajoute le numéro
de l’adresse ainsi que toutes les consonnes du nom de la rue. Nous pouvons remarquer
que les deux premières entrées sont identiques, la troisième entrée est probablement la
même personne mais avec une erreur dans le nom. La quatrième entrée est probablement
3. Les doublons similaires sont des entités identiques mais qui ont subi une modification par erreur.
une personne différente mais ayant la même clef que les trois premières entrées. Finale-
ment, nous pouvons clairement voir qu’un mauvais choix d’attributs donnera de mauvais
résultats.
D’autres difficultés liées au problème de détection des doublons persistent. Par exemple,
la détection des doublons proches 4 . Ou encore, le problème d’abréviation 5 .
[25] propose de résoudre ce dernier en comparant l’entrée la plus courte avec les x
premières lettres de l’entrée la plus longue (x étant la longueur de la plus petite chaı̂ne).
Cette méthode pose problème pour certains cas, par exemple considérons les deux chaı̂nes
de caractères ”John” et ”Johnathan”, ils seront considérés comme doublons selon cette
méthode.
[23] propose d’améliorer cette méthode en prenant x = la moyenne des longueurs des
deux chaı̂nes de caractères. Malgré que cette modification permet de reconnaı̂tre plus de
doublons que la méthode précédente, il exist d’autres cas de figures où celle-ci donnerait
de mauvais résultats. Par exemple, les mots VW et Volkswagen ne pourront jamais être
reconnus comme doublons. Encore une fois, c’est la connaissance du contexte étudié qui
permettra d’avoir de meilleurs résultats.
3.3 Conclusions
Nous pouvons conclure en disant que le l’élimination des problèmes de qualité de
données est une tâche assez complexe. Néanmoins, cette complexité peut être réduite
grâce aux contraintes imposées par la connaissance de contexte. C’est pourquoi la grande
majorité des outils qui existent dans le marché se focalisent en la résolution de problèmes
bien précis (Adresses postales, numéros de téléphones, ..., etc.). Dans le chapitre sui-
vant, nous expliquerons la méthode utilisée (spécifique au contexte de ce mémoire) pour
effectuer le nettoyage de données.
4. Les doublons proches sont des entités identiques par leur signification mais pas par leur apparence.
Par exemple les mots Professeur et Enseignant peuvent être identiques dans certain contexte
5. C’est le problème d’associer les abrévations aux entités qu’elles représentent.
Problèmes liés à la
qualité de données
Problèmes issus Problèmes issus

d ’une seule source de plusieurs sources
Niveau schéma Niveau tuple Niveau schéma Niveau tuple

(Manque decontraintes (erreurs pendant (modèles (données
d ’intégrités, schéma la saisie des de données incosistentes,
mal conçu) données) hétérogènes) contradictoires)
(a)
Problèmes liés à la qualité de données
issus de plusieurs sources
issus d ’une seule source
(b)
Figure 3.3 – Classification des erreurs dans les sources de données - inspiré de [21].
Fenêtre
w
courante
Prochaine
w
fenêtre
Figure 3.4 – La méthode Sorting Neighborhood.
ID Prénom Nom Adresse Clef
123456 Jon Miller 68 First Street 123JONMLL68FRST
123467 Jon Miller 68 First Street 123JONMLL68FRST
123558 Jon Millar 68 First Street 123JONMLL68FRST
123597 Jonas Muller 68 Forest Street 123JONMLL68FRST
Figure 3.5 – La méthode Sorting Neighborhood - Le calcul des clefs de tri - inspiré de
[12].
Chapitre 4
Analyse du problème et solution

proposée
4.1 Fonctionnalités à implémenter

L’outil de reporting attendu doit satisfaire plusieurs contraintes. Tout d’abord, l’exécution
du logiciel de reporting doit influencer le moins possible l’activité des bases de données.
Cet outil sera utilisé dans des environnements Windows avec une base de données SQL
Server. Le produit abouti devra en outre satisfaire les contraintes suivantes :
Collecte des données : Le programme devra être capable de récolter des données
pertinentes de manière fiable à partir de la base de données SQL Server, voir Figure
4.5. Les données relatives aux incidents sont mises à jour au fur et à mesure.
Visualisation des données : Le programme doit proposer un outil flexible de vi-
sualisation des données. Celui-ci permettra d’avoir un œil sur les KPI’s. Il sera
également possible de sélectionner une période de temps pour l’affichage.
Génération de rapports : Le programme permettra de générer des rapports (dans
le logiciel et dans le format Excel). Ceux-ci devront être sous un format bien
déterminé. Voir Figure 4.1.
Transparence des rapports : Les rapports dans le format Excel doivent inclure
toutes les données qui ont été utilisées afin de pouvoir aisément vérifier la crédibilité
des résultats au cas où il y aurait un doute. Autrement dit, tous les calculs doivent
être refaits dans le fichier Excel généré.
Travail supplémentaire : Dans la mesure du possible, le programme doit fournir
un outil de support dont les résultats ne seront pas générés dans les rapports.
Concrètement, il s’agit de comparer les différents sites CIC en terme d’incidents
apparus. De cette façon, l’analyse des résultats pourra être poussée un peu plus loin
afin détecter les incidents dont l’origine n’est pas la partie logicielle (responsabilité
d’Intergraph). Par exemple, un très grand nombre d’incidents apparaissant dans
un site CIC relativement petit pourrait laisser penser que c’est un problème lié au
réseau.
Travail supplémentaire : Le programme devra être capable de détecter et de cor-
riger les problèmes liés à la qualité de données.
23
Chapitre 4 : Analyse du problème et solution proposée 24
(a) Par mois (b) Par semaine
(c) Par an
Figure 4.1 – Format du rapport à générer.
4.2 État de l’art

Il existe un grand nombre de systèmes de reporting. Cette section se propose de
passer en revue certaines des solutions les plus répandues disponibles sur le marché. Nous
tenterons aussi de mettre en évidence les aspects attractifs et répulsifs propres à chacun
de ces produits.
Microsoft SQL Server Reporting Services (MSSRS) Le premier système de re-
porting est une solution fournie par Microsoft. Ce système de reporting est dispo-
nible gratuitement si l’on possède une licence de MS SQL Server. Néanmoins, ce
système de reporting est uniquement destiné à être utilisé depuis une interface web.
BIRT BIRT est un système de reporting open source destiné à être utilisé avec le
langage de programmation Java, de coup il est ”cross-platform” (Linux, Mac et Win-
dows). Ce système de reporting bénéficie d’un concepteur de rapports utilisant une
approche web (il n’est pas possible d’avoir un contrôle total sur le positionnement
des éléments de rapport). Il bénéficie également d’une très bonne documentation.
L’installation est rendue un petit peu laborieuse puisque BIRT ne vient avec au-
cun support pour les serveurs de bases de données, c’est à l’utilisateur d’installer
chercher le bon pilote.
JasperReports Cet outil est, comme BIRT, destiné pour les applications développés
en Java. JasperReports, contrairement aux autres produits présentés ici, bénéficie
d’un emplacement au pixel près des éléments de rapport, c’est donc un bon choix si
les rapports générés doivent être imprimés. Contrairement à BIRT, JasperReports
s’installe avec un support pour les quelques serveurs de bases de données assez
répandus comme MS SQL Server, Oracle, MySQL, ..., etc.
Crystal Reports Cet outil de reporting est l’un des plus connus qui a longtemps été
associé avec Microsoft et Visual Studio. Il est également ”cross-platform” puisqu’il
peut être utilisé avec les plateformes COM, .NET, Delphi et Java. De plus, cet
outil permet, outre la génération des rapports, la conception des tableaux de bord.
Contrairement à MSSRS, Crystal Reports n’est pas une solution uniquement basé-
Web, en effet les rapports qu’il génère peuvent aussi être utilisé dans des applications
standalone. Cependant, ce outil est payant, ce qui ne convient pas.
Comme nous allons voir dans les sections suivantes, aucun de ces produits ne convient
dans notre contexte. Nous avons donc décidé de créer les rapports manuellement.
(a) BIRT (b) JasperReports
(c) Crystal Reports (d) MSSRS
Figure 4.2 – Quelques outils de reporting.

4.3 Fonctionnement général du programme
4.3.1 Optique de développement

L’optique de développement de ce programme est bien sûr de fournir un logiciel fini
ayant un certain nombre de fonctionnalités. Les points suivants montrent les critères
auxquels il a été porté une attention toute particulière lors du développement.
Transparence : Afin de rendre les résultats facilement vérifiables pour l’utilisateur,
il est nécessaire de toujours montrer les données qui ont été utilisées et qui sont à
la base de ces résultats.
Convivialité : Il va de soi que le logiciel doit pouvoir être employé sans trop de
difficultés par une personne n’ayant pas participé au développement. Dans cette
philosophie, il a semblé intéressant d’offrir une interface graphique simple, efficace,
robuste et sans surenchère technologique.
Légèreté : Le logiciel doit être le plus léger possible, notamment au point de vue de
la connexion à la base de données. Ainsi, une seule connexion à la base de données
est suffisante pour générer tous les résultats attendus.
Paramétrabilité : L’outil de reporting doit être paramétrable le plus possible (rien
ne doit être codée en dur). En effet, à chaque fois qu’il nous manque une information
pour satisfaire une certaine tâche la meilleure solution est de créer un paramètre
pour la tâche en question.
4.3.2 Les interventions

Lorsqu’un incident apparaı̂t dans le système chez A.S.T.R.I.D, celui-ci crée un ticket
(un ticket est un email qui contient des données concernant l’incident apparu comme
le numéro d’incident, sa date de création, une description etc. La Figure 4.3 montre un
exemple de ticket.) et l’envoie à Intergraph. Dès la réception du ticket par Intergraph,
un compteur est lancé marquant le début d’une intervention. La figure 4.4 montre le
déroulement d’une intervention. Notons que des indicateurs clés de performance (KPI’s)
sont posés sur le temps de réponse (ResponseTime) et le temps de résolution de l’incident
(ResolutionTime).
Clarify number: 11365123

WO number: 73327
Priority: P2
Date/Time Opened: 28/09/2011 16:01:34
Title: CIC-LIM: listener packetten PZ_BERTHA komen niet doo= op CAD LIM. FIREWALL LIM:
Status: Open
Description:
Note Log created on Wednesday, September 28, 2011 4:01:36 PM was perfo=med by user XMLBridgeUser
and ....
Figure 4.3 – Exemple de ticket.

DateReceived
(Intergraph) DateOnSite DateClosed
Temps
DateCreated DateStarted DateFixed DateReport

(ASTRID)
ResponseTime (KPI) RepairTime
ResolutionTime (KPI)
Figure 4.4 – Le déroulement d’une intervention.
4.3.3 Choix des infrastructures

Concernant le choix du langage de programmation, nous avons opté pour C# (un
langage de programmation orienté objet) pour coder le projet. En effet, ce langage de
programmation, profitant directement de la plate-forme Microsoft .NET, est bien adapté
au contexte de ce travail :
– Environnement Windows
– Génération de fichier Excel (sans devoir utiliser une API tierce)
Notons qu’il était prévu, à la base, d’intégrer cet outil de repotring à un autre outil
de chez Intergraph et que ce dernier est implémenté avec les technologies de Microsoft
(Visual Studio, .NET, C#, SQL Server). Il était donc tout à fait naturel de garder ce
choix de technologies.
4.3.4 Structure de la base de données

N’ayant pas accès à la base de de données des incidents, la base de données de la Figure
4.5 a été construite afin de combler ce manque d’informations. En effet, tous les détails des
incidents (lieu, état, ..., etc.) sont envoyées dans la base de données des incidents qui est
détenue par le client. Un outil a donc été développé afin d’avoir ces informations. Celui-ci
permet aux gestionnaires des incidents d’entrer les détails des incidents manuellement.
Le programme se connecte donc à la base de données dont le diagramme entité-relation
est montré à la Figure 4.5 1 .
Au centre du diagramme se trouve la table Intervention qui reprend principalement,
le numéro du ticket reçu (TTNr ) ainsi que les temps caractéristiques d’une intervention.
Afin de pouvoir nettoyer/valider les données, nous avons rajouté des colonnes supplémentaires
(voir Figure 4.6) dans la table Intervention. Ces colonnes peuvent être divisées en deux
catégories :
1. Notons que la base de donnée et les tables contiennent, respectivement, des tables et des colonnes
qui ne sont pas montrées sur le diagramme pour une raison de clarté.
– Des colonnes qui remplacent celles de mêmes noms (en supprimant le suffixe Clea-
ned ) et qui contiennent les données nettoyées. Cette approche nous permet de ne
pas écraser les données existantes. Notons que nous aurions pu créer une table
supplémentaire et y ajouter seulement les tuples qui ont été validées. Mais cette
approche, malgrès le fait qu’elle permet d’utiliser un minimum d’espace, serait au
détriment de la légèreté du programme, car elle demanderait plus de travail à la
base de données (Jointures entre la table Intervention et la nouvelle table).
– Un ensemble de colonnes nécessaires pour faire une estimation de la qualité des
données (voir la section suivante).
Site Intervention
ID INT ID INT
Name NCHAR(3) TTNr NCHAR(20)
PriorityID INT
Indexes StatusID INT Software

SystemID INT ID INT
SoftwareID INT Name NCHAR(20)
SiteID INT
Status
ResponseTime DATETIME Indexes
ID INT
RepairTime DATETIME
Name NCHAR(50)
DateCreated DATETIME
DateReceived DATETIME System
Indexes
DateStarted DATETIME ID INT
DateOnSite DATETIME Name NCHAR(20)
DateFixed DATETIME
Priority DateClosed DATETIME
Indexes
ID INT DateReport DATETIME
Name NCHAR(5) RespRemainingMinutes INT
RepRemainingMinutes INT
Indexes Indexes
Figure 4.5 – La base de données existante.
4.3.5 Choix des dimensions pour la qualité de données

Dans cette section, nous allons faire une sélection des dimensions qui ont été étudiées
dans le chapitre précédent. Comme montré dans la Figure 4.5, les données dont nous
désirons estimer la qualité sont de type DateTime 2 .
Pour parvenir à faire un bon choix, une bonne idée est de d’abord expliquer quels
sont les problèmes qui peuvent apparaı̂tre dans nos données. Ci-dessous une liste de ces
problèmes accompagnés d’explications est donnée :
Valeurs nulles Comme cité plus haut, la table Intervention fonctionne par mise à
jour (elle est mise à jour au fur et à mesure que les interventions changent d’états).
Du coup, il a été décidé (par le concepteur de la base de données) de permettre
2. Le type DateTime permet de stocker une date et une heure dans la plupart des systèmes de gestion
de bases de données. 2012-08-20 12 :00 :00 est un exemple de DateTime dans SQL Server.
Figure 4.6 – Les colonnes ajoutée à la table Intervention.
d’avoir des valeurs NULL. Il en résulte que la valeur NULL peut avoir deux signi-
fications, une valeur manquante (oubli de la part du gestionnaire de l’incident) ou
une valeur qui n’as pas encore été introduite. La Figure 4.7 illustre ce problème.
Incohérence Un problème d’incohérence peut apparaı̂tre lorsque les relations entre
les différentes dates ne sont pas respectées. Ce type de problème est illustré à
la Figure 4.8. On remarque que la relation de précédence entre DateStarted et
DateOnSite n’a pas été respectée.
Valeurs non exactes Même lorsque les valeurs d’un tuple sont cohérentes, celles-
ci peuvent être inexactes. En effet des valeurs comme 2000-01-01 00 :01 :00 ou
encore 2011-01-01 00 :01 :00 ont déjà été détectées dans le système. Ce problème
est illustré à la Figure 4.9.
Intervention
ID DateCreated DateReceived DateStarted DateOnSite DateFixed StatusID
1 2012-08-20 12:03:15 2012-08-20 12:05:17 NULL 2012-08-20 13:21:13 NULL 1
Status
ID Name Valeur manquante Valeur pas encore entrée
1 On site
Figure 4.7 – Exemple illustrant les deux significations de la valeur NULL.
Les dimensions que nous allons utiliser afin d’estimer la qualité des données sont donc :
La stabilité dans le temps (non-volatilité) L’idée est de ne pas tenir compte des
Intervention
ID DateCreated DateReceived DateStarted DateOnSite DateFixed
1 2012-08-20 12:01:20 2012-08-20 12:05:00 2012-08-20 13:25:00 2012-08-20 13:20:00 2012-08-20 16:02:00
Figure 4.8 – Exemple illustrant une incohérence.
Intervention
ID DateCreated DateReceived DateStarted DateOnSite DateFixed
1 2000-01-01 00:01:00 2000-01-01 00:01:00 2000-01-01 00:01:00 2000-01-01 00:01:00 2000-01-01 00:01:00
Figure 4.9 – Exemple de valeurs inexactes.
interventions qui sont en cours. Pour cela, nous considérerons seulement les inci-
dents résolus ou suspendus (un incident est mis en en suspension (horloge en pause)
lorsque le client doit fournir des informations nécessaires pour la résolution de l’in-
cident).
1 UPDATE wsr . I n t e r v e n t i o n SET T i m e l y S t a b l e = 1 WHERE Status ID = 6 OR
StatusID = 8 AND P r o c e s s e d = 0
Listing 4.1 – La stabilité
La complétude Notons que nous nous intéresserons ici au problème des valeurs
manquantes. En effet, les valeurs qui ne sont pas encore entrées ne constituent pas
vraiment un problème (il suffit de ne pas tenir compte des interventions qui sont en
cours d’exécution, grâce à la table Status). La métrique qui sera utilisée pour cette
dimension est de type {1, 0}. Ainsi un tuple complet (aucune valeur NULL) aura
une valeur 1 pour la colonne Complete, de même un tuple non complet (au moins
une valeur NULL) aura une valeur 0 pour la colonne Complete. La complétude sera
globalement estimée en divisant le nombre de tuples complets par le nombre total
de tuples.
1 // Completude pour l e s i n c d i e n t s s t a b l e s dans l e temps
2 UPDATE wsr . I n t e r v e n t i o n SET Complete = 1 WHERE T i m e l y S t a b l e = 1
3 AND DateCreated IS NOT NULL AND DateReceived IS NOT NULL
4 AND D a t e S t a r t e d IS NOT NULL AND DateOnSite IS NOT NULL
5 AND DateFixed IS NOT NULL AND DateClosed IS NOT NULL
Listing 4.2 – La complétude
La cohérence La cohérence est calculée de manière directe en vérifiant que tous les
états d’une interventions se suivent dans l’ordre chronologique. De la même façon
que pour la complétude, nous utilisons une métrique de type {1, 0} et la cohérence
totale est donnée par le rapport du nombre des tuples cohérents par le nombre total
des tuples.
1 UPDATE wsr . I n t e r v e n t i o n
2 SET C o n s i s t e n t = 1 WHERE P r o c e s s e d = 0
3 AND RepairTime >= ResponseTime AND P r o c e s s e d = 0 AND

TimelyStable = 1
4 AND DateReceivedCleaned < ResponseTime ;
Listing 4.3 – La cohérence
L’exactitude Cette dimension est également estimée de la même manière. Notons
que des dates comme 2000-01-01 00 :01 :00 résultent d’une mauvaise traduction
de ces valeurs depuis le ticket reçu. Pour cela, nous avons décidé de paramétriser
l’insertion/suppression des dates ”non désirée”. En effet, dans le futur, il pourrait
exister d’autres valeurs inexactes ou bien le problème à l’origine de ces valeurs
pourrait être éliminé.
2 SET Accurate = 1 WHERE T i m e l y S t a b l e = 1
3 // c e c i e s t f a i t pour t o u t e s l e s d a t e s i n d e s i r a b l e s ( f l a g )
4 AND D a t e S t a r t e d C l e a n e d != f l a g AND DateOnSiteCleaned != f l a g
5 AND DateFixedCleaned != f l a g AND DateClosedCleaned != f l a g
6 AND DateReportCleaned != f l a g ;
Listing 4.4 – L’exactitude
Toujours dans la même optique de solliciter le serveur de la base de données le moins

possible, les dates indésirables (flag) sont stocker dans un fichier XML dont la structure
est donnée ci-dessous.
1 < s e t t i n g s>
2 <f l a g T i m e s>
3 < f l a g>2000−01−01 00 : 0 1 : 0 0</ f l a g>
4 < f l a g>2011−01−01 00 : 0 1 : 0 0</ f l a g>
5 </ f l a g T i m e s>
6 </ s e t t i n g s>
Listing 4.5 – Stockage des dates indésirables dans un fichier XML
4.3.6 Nettoyage et validation de données

Pour nettoyer et valider les données, deux approches peuvent être utilisées. La première
approche que nous pourrions adopter est de traiter les données au fur et à mesure de
leur arrivée dans la base de données (en temps réel), autrement dit en utilisant des
déclencheurs 3 (triggers en Anglais). Une autre façon de faire, serait de traiter les données
lors de l’exécution du programme. C’est cette approche là qui sera adoptée car elle a
l’avantage de ne pas surcharger le serveur de la base de données.
Comme nous l’avons déjà cité, la colonne Processed permet de marquer les données
qui ont déjà été traitées afin d’éviter de retraiter ces données à chaque lancement du
programme. Par contre, lors de la mise à jours d’une donnée qui a déjà été traitée, un
retraitement devient nécessaire au prochain lancement du programme. En effet, nous
3. Dans les bases de données, un déclencheur permet de lancer automatiquement une procédure
stockée lors de la mise à jour ou de la suppression d’une donnée, qui agit en parallèle sur la même
donnée dans une table afférente. Cela permet d’automatiser certains traitements assurant la cohérence
et l’intégrité de la base de données.
devons assigner la valeur 0 à Processed pour la donnée en question, ce qui doit être fait
en utilisant un déclencheur.
1 USE wsr
2 ALTER TRIGGER wsr . i n i t i a l i z e D a t a C l e a n s i n g ON wsr . I n t e r v e n t i o n FOR UPDATE
3 AS IF (UPDATE( D a t e S t a r t e d ) OR UPDATE( DateOnSite ) OR UPDATE( DateFixed ) OR
UPDATE( DateClosed ) OR UPDATE( DateReport ) )
4 BEGIN
6 SET P r o c e s s e d = 0 , T i m e l y S t a b l e = 0 , Complete = 0 ,
7 C o n s i s t e n t = 0 , Accurate = 0 , V a l i d = 0 , WasValid = 0 ,
8 DateReceivedCleaned = NULL, D a t e S t a r t e d C l e a n e d = NULL,
9 DateOnSiteCleaned = NULL, DateFixedCleaned = NULL,
10 DateClosedCleaned = NULL, DateReportCleaned = NULL
11 WHERE ID IN
12 (
13 SELECT ID FROM DELETED
14 )
15 END
Listing 4.6 – Déclencheur de réinitialisation
Nous avons donc un outil de nettoyage/validation qui est implémenté dans le pro-
gramme de reporting ainsi qu’un déclencher pour la base de données.
Dans ce qui suit, nous allons tenter d’expliquer le fonctionnement de cet outil.
Détections des problèmes
La première chose que l’outil fait est détecter les trois types de problèmes discutés
précédemment (les données incomplètes, les données incohérentes et les données in-
exactes).
Nettoyage
Notons que tous les problèmes détectés ne peuvent pas être corrigés. En effet, un
problème dans les colonnes DateCreated et DateReceived ne peut pas être résolu. Pour
les autres colonnes, DateStarted, DateOnSite, DateFixed, DateClosed et DateReport, la
règle générale appliquée est celle d’éviter un manquement d’un SLA.
1 UPDATE wsr . I n t e r v e n t i o n SET DateReceivedCleaned =
2 (CASE
3 WHEN ( DateReceived < DateCreated OR ( DateReceived IS NULL AND
DateCreated IS NOT NULL) )
4 THEN DateCreated
5 ELSE DateReceived
6 END)
7 WHERE P r o c e s s e d = 0 AND T i m e l y S t a b l e = 1 ;
Listing 4.7 – Nettoyage de données 1
1 UPDATE wsr . I n t e r v e n t i o n SET D a t e S t a r t e d C l e a n e d =

2 (CASE
3 WHEN ( DateReceivedCleaned IS NOT NULL AND ( D a t e S t a r t e d <

DateReceivedCleaned OR D a t e S t a r t e d IS NULL) )
4 THEN DateReceivedCleaned
5 ELSE D a t e S t a r t e d
6 END)
1 UPDATE wsr . I n t e r v e n t i o n SET DateOnSiteCleaned =

2 (CASE
3 WHEN ( DateOnSite < D a t e S t a r t e d C l e a n e d OR ( DateOnSite IS NULL AND
ResponseTime IS NOT NULL) )
4 THEN ResponseTime
5 ELSE DateOnSite
6 END)
1 UPDATE wsr . I n t e r v e n t i o n SET DateFixedCleaned =

2 (CASE
3 WHEN ( DateFixed < DateOnSiteCleaned OR ( DateFixed IS NULL AND
RepairTime IS NOT NULL) )
4 THEN RepairTime
5 ELSE DateFixed
6 END)
1 UPDATE wsr . I n t e r v e n t i o n SET DateClosedCleaned =

2 (CASE
3 WHEN ( DateClosed < DateFixedCleaned OR DateClosed IS NULL)
4 THEN DateFixedCleaned
5 ELSE DateClosed
6 END)
1 UPDATE wsr . I n t e r v e n t i o n SET DateReportCleaned =

2 (CASE
3 WHEN ( DateReport ] < DateClosedCleaned OR DateReport IS NULL)
4 THEN DateClosedCleaned
5 ELSE DateReport
6 END)
Validation
La validation des données se fait directement en parcourant toutes les données qui
ont été nettoyées et en vérifiant que celles-ci respectent toutes les dimensions de qualité
de données définies plus haut. Donc, une entrée dans la table Intervention est valide si et
seulement si elle est complète, cohérente, exacte et non volatile.
1 UPDATE wsr . I n t e r v e n t i o n SET V a l i d = 1
2 WHERE T i m e l y S t a b l e = 1 AND Complete = 1
3 AND C o n s i s t e n t = 1 AND Accurate = 1 AND P r o c e s s e d = 0 ;
Listing 4.13 – Validation de données
4.3.7 Analyse temporelle

Le système de reporting sera donc un logiciel C# (framework .NET) conçu lors de
ce mémoire, se connectant à une base de données SQL Server. A chaque lancement du
programme, les actions suivantes sont exécutées :
– Le programme analyse tous les tuples qui n’ont jamais été traités (Processed = 0 )
et procède à la validations de ces derniers.
– Ensuite, toutes les données nécessaires sont collectées et la connexion avec la base
de données est libérée.
– A cette étape, le programme est capable de générer le rapport (de base), faire une
estimation de la qualité de données, générer un rapport inter-sites ainsi que générer
le rapport sous format Excel.
4.4 Patrons de conception

Les patrons de conception sont également un receuil de bonnes pratiques. Dans le cadre
de ce mémoire nous avons introduit un patron de conception. Ce dernier est présenté dans
cette section.
4.4.1 Singleton
Ce patron de conception est utile lorsque l’on veut limiter le nombre d’instances d’une
classe à une seule instance. Cela peut être réalisé en empêchant l’accès au constructeur
depuis l’extérieur (constructeur privé) et en créant une méthode qui permet de renvoyer
une nouvelle instance seulement lorsque il n’y a actuellement aucune instance. Sinon, la
méthode renverra une nouvelle instance. Ainsi, ce patron de conception est utilisé afin
de garder une seule connexion à la base de données. Donc, le gestionnaire de la base de
données (DataManager) est un singleton.
1 p u b l i c s t a t i c DataManager dataManager ;
2 p r i v a t e DataManager ( )
3 {
4 // Le code de c o n s t r u c t e u r
5 }
6
7 p u b l i c s t a t i c DataManager g e t I n s t a n c e ( )
8 {
9 i f ( dataManager == n u l l )
10 {
11 dataManager = new DataManager ( ) ;
12 }
13 r e t u r n dataManager ;
14 }
Listing 4.14 – Le gestionnaire de la base de données (DataManager)
4.5 Conclusions
Nous avons donc établi les infrastructures employées ainsi que les justifications de ces
différents choix. Ainsi, nous avons opté pour C# comme langage d’implémentation du
logiciel. De plus, l’analyse temporelle, la sélection des dimensions pour l’estimation de la
qualité de données et la structure de la base de données ont été présentées.
Chapitre 5
Résultats
5.1 Installation
Le logiciel peut être facilement installé. Pour plus d’informations, un guide ’installa-
tion détaillé est fourni en annexe.
5.2 Guide d’utilisation

La Figure 5.1 montre l’interface principale du programme. Les trois premières sous-
fenêtres constituent le module de reporting de base. Les deux autres modules sont représentés
par les deux sous-fenêtres suivantes. Une fois le programme lancé, l’utilisateur est amené
à choisir une période pour le rapport mensuel (MTD, pour month to date), une date pour
le rapport hebdomadaire (WTD, pour week to date) et une date pour le rapport annuel
(YTD, pour year to date). Ensuite, il suffit de cliquer sur le bouton OK pour générer les
rapports. A ce stade, il est possible d’exporter les données vers le format Microsoft Excel
(bouton Export).
Dans la partie supérieure de la fenêtre principale, quelques paramètres peuvent être
ajustés :
Track by Ce paramètre permet de catégoriser les interventions selon soit leur date
de réception (DateReceived ) soit leur date de réparation (DateFixed ). Dans d’autres
mots, ce paramètre permet de fixer le point de référence des interventions.
Dates to exclude Comme expliqué dans le chapitre précédent, des dates dues à
une mauvaise traduction peuvent apparaı̂tre dans la base de données. Cette section
permet de gérer ces dates.
Set Db Permet d’entrer l’adresse de la base de données (MS SQL Server) à laquelle
l’utilisateur désire se connecter.
L’adresse de la base de données peut être entrée en cliquant sur le bouton setDb. Voir
Figure 5.2.
36
Chapitre 5 : Résultats 37
Figure 5.1 – La fenêtre principale du programme.
Figure 5.2 – L’adresse de la base de données.
La sous-fenêtre qui constitue le module qualité de données (Figure 5.3) comporte trois
régions :
– La région Overview montre les estimations des dimensions de la qualité de données
discutées dans le chapitre précédent.
– La région Valid and invalid data montre les interventions qui ne sont pas valides
ainsi que les interventions qui sont devenues valides après leur traitement.
– La région Cleaned data per month permet de visualiser ces données dans un
graphique dont l’axe des abscisse contient les mois de l’année choisie.
Une fois que le point de référence des interventions a été choisi, il est important de
montrer à l’utilisateur les interventions qui ”débordent”, c’est-à-dire les interventions qui
débutent dans une semaine (quand il s’agit d’un rapport hebdomadaire) et qui terminent
dans une autre semaine ultérieure, de même pour les rapports mensuels. En effet, aucune
règle à appliquer n’a été définie pour ce type d’incidents. Lorsque de telles interventions
existent, le bouton Overflowing incidents devient actif et permet de voir les détails
de ces interventions. La figure 5.4 montre un exemple d’interventions qui sont reçus le 31
Août 2011 et qui sont résolus le premier Septembre 2011.
Figure 5.3 – Le module qualité des données.
Les figures 5.5, 5.6 et 5.7 montrent, respectivement, le rapport mensuel, le rapport
hebdomadaire et le rapport annuel.
5.3 Conclusions
Après ces descriptions, nous pouvons donc voir que le logiciel répond le logiciel est
pleinement utilisable et permet de générer des rapports qui répondent bien à tous les
critères et contraintes mais dispose également d’un outil de nettoyage de données. Cet
outil est donc un produit abouti et fonctionnel.
Figure 5.4 – Les incidents débordants.
Figure 5.5 – Le rapport mensuel.

Figure 5.6 – Le rapport hebdomadaire.
Figure 5.7 – Le rapport annuel.

Chapitre 6
Conclusions
N’ayant pas accès à la base de données des incidents, nous n’avions pas la possibi-
lité d’établir nos statistiques et donc de confirmer ou d’infirmer le rapport produit par
les clients. En plus, rien ne pouvait être fait concernant les éventuelles erreurs se trou-
vant dans ces rapports et donc aucune contestation ne pouvait avoir lieu concernant les
pénalités infligées.
Le développement du logiciel a donc permis aux gestionnaires d’incident de pouvoir
constamment monitorer le niveau de leurs services. De plus, grâce aux rapports générés
par le logiciel, il devient possible de comparer les résultats obtenus avec ceux présentés
par les clients. Du coup, les rapports constituent un moyen de protection.
Finalement, nous pouvons donc dire que le développement du logiciel est un succès car
il correspond à toutes les attentes et satisfait toutes les contraintes. De plus, l’estimation
de la qualité de données permet d’avoir un regard critique sur les résultats.
Ce mémoire m’a donc permis de comprendre l’intérêt d’utiliser ITIL ainsi que de
connaı̂tre ses bases, d’aborder des sujets sur la qualité de données qui est un domaine
vaste (des milliers de recherches ont été effectuées) et complexe. Techniquement, j’ai eu
l’occasion à travers ce mémoire de développer un logiciel se basant sur la plate-forme
.NET.
41
Bibliographie
[1] Chapman A.D. Principlies of data quality, 2005.

[2] ASTRID. ASTRID - Architecture réseau. http://www.astrid.be/templates/
content.aspx?id=492&LangType=1036.
[3] ASTRID. ASTRID - Astrid en bref. http://www.astrid.be/templates/content.
aspx?id=1224&LangType=1036.
[4] ASTRID. ASTRID - Le noeud provincial et le centre de dispatching (CIC). http:
//www.astrid.be/Templates/content.aspx?id=520.
[5] Carlo Batini and Monica Scannapieco. Data Quality : Concepts, Methodologies And
Techniques. Springer, 2006.
[6] D. Bitton and D.J. DeWitt. Duplicate record elimination in large data files. ACM
Transactions on database systems (TODS), 8(2) :255–265, 1983.
[7] M. Bovee, R.P. Srivastava, and B. Mak. A conceptual framework and belief-function
approach to assessing overall information quality. International journal of intelligent
systems, 18(1) :51–74, 2003.
[8] C. Dumont. ITIL pour un service informatique optimal : Mis à jour avec ITIL v3
et la norme ISO 20000 ! Solutions d’entreprise. Eyrolles, 2011.
[9] ITIL France. http ://www.itilfrance.com/. http://www.itilfrance.com.
[10] I. Guyon, N. Matic, V. Vapnik, et al. Discovering informative patterns and data
cleaning. Advances in knowledge discovery and data mining, 181 :203, 1996.
[11] M.A. Hernández and S.J. Stolfo. The merge/purge problem for large databases. In
ACM SIGMOD Record, volume 24, pages 127–138. ACM, 1995.
[12] Mauricio A. Hernández and Salvatore J. Stolfo. Real-world data is dirty : Data
cleansing and the merge/purge problem. DATA MINING AND KNOWLEDGE
DISCOVERY, 2 :9–37, 1998.
[13] Jonathan I. Maletic and Andrian Marcus. Data cleansing : Beyond integrity analysis,
2000.
[14] Cabinet Office. ITIL Continual Service Improvement. TSO (The Stationery Office),
2011.
[15] Cabinet Office. ITIL Service Design. TSO (The Stationery Office), 2011.
[16] Cabinet Office. ITIL Service Operation. TSO (The Stationery Office), 2011.
[17] Cabinet Office. ITIL Service Strategy. TSO (The Stationery Office), 2011.
[18] Cabinet Office. ITIL Service Transition. TSO (The Stationery Office), 2011.
42
BIBLIOGRAPHIE 43
[19] Jack E. Olson. Data Quality : The Accuracy Dimension. Morgan Kaufmann Publi-
shers In, 2003.
[20] Leo L. Pipino, Yang W. Lee, and Richard Y. Wang. Data quality assessment. Com-
munications of the ACM, 45(4) :211–218, 2002.
[21] E. Rahm and H.H. Do. Data cleaning : Problems and current approaches. IEEE
Data Engineering Bulletin, 23(4) :3–13, 2000.
[22] Thomas C. Redman. Data Quality for the Information Age. Artech House, 1996.
[23] K.S.N. Ripon, A. Rahman, and GM Rahaman. A domain-independent data cleaning
algorithm for detecting similar-duplicates. Journal of Computers, 5(12) :1800–1809,
2010.
[24] E. Simoudis, B. Livezey, and R. Kerber. Using recon for data cleaning. In Pro-
ceedings of KDD-95 : First International Conference on Knowledge Discovery and
Data Mining, pages 275–281, 1995.
[25] A. Udechukwu, C. Ezeife, and K. Barker. Independent de-duplication in data clea-
ning. Journal of Information and Organizational Sciences, 29(2) :53–68, 2005.
[26] Richard Y. Wang and Diane M. Strong. Beyond accuracy : What data quality means
to data consumers, 1996.
[27] Wikipédia. Distance de levenshtein — wikipédia, l’encyclopédie libre. http://fr.
wikipedia.org/wiki/Distance_de_Levenshtein, 2012. [En ligne ; Page disponible
le 01-Août-2012].
[28] Wikipédia. Drame du heysel — wikipédia, l’encyclopédie libre. http:
//fr.wikipedia.org/w/index.php?title=Drame_du_Heysel&oldid=77733285,
2012. [En ligne ; Page disponible le 18-Juillet-2012].
[29] Wikipédia. Exploration de données — wikipédia, l’encyclopédie libre. http://
fr.wikipedia.org/wiki/Exploration_de_donn%C3%A9es, 2012. [En ligne ; Page
disponible le 06-Août-2012].
[30] Wikipédia. Herald of free enterprise — wikipédia, l’encyclopédie libre. http:
//fr.wikipedia.org/w/index.php?title=Herald_of_Free_Enterprise&oldid=
74462757, 2012. [En ligne ; Page disponible le 18-Juillet-2012].
[31] L. Zhao, S. Yuan, S. Peng, and L. Wang. A new efficient data cleansing method. In
Database and Expert Systems Applications, pages 153–182. Springer, 2002.
Annexe A
Guide d’installation
Afin d’installer le logiciel, il suffit de lancer le fichier setup.exe et suivre les instruc-
tions.
Figure A.1 – Installation - 1.
La Figure A.4 montre que le logiciel occupe une petite taille sur le disque dur (environ
1 MB).
44
Chapitre A : Guide d’installation 45



Annexe B
Exemple de rapport généré
Figure B.1 – SLA’s
Figure B.2 – MTD
48
Chapitre B : Exemple de rapport généré 49
Figure B.3 – WTD
Figure B.4 – YTD

Figure B.5 – Les données - 1
Figure B.6 – Les données - 2


Projet ITIL

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Projet ITIL

Transféré par

Droits d'auteur :

Formats disponibles

Système de rapports d’incidents

conforme aux normes ITIL pour le

3 Qualité, nettoyage et validation de données 13

4 Analyse du problème et solution proposée 23

4.3.1 Optique de développement . . . . . . . . . . . . . . . . . . . . . . 26

B Exemple de rapport généré 48

1.1 Architecture du réseau A.S.T.R.I.D. extrait de [2]. . . . . . . . . . . . . . 2

2.1 Les composants d’ITIL - schéma des publications tiré de [9]. . . . . . . . 6

3.1 La relation LigueDesChampions. . . . . . . . . . . . . . . . . . . . . . 15

4.1 Format du rapport à générer. . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 La fenêtre principale du programme. . . . . . . . . . . . . . . . . . . . . 37

Dans ce chapitre, nous allons introduire ce mémoire en décrivant le contexte dans

Figure 1.1 – Architecture du réseau A.S.T.R.I.D. extrait de [2].

1.2 Aperçu d’ITIL

1.3 Objectifs de ce mémoire

2.1.2 ITIL et l’approche orientée service

c’est-à-dire lors d’une panne c’est la responsabilité de l’utilisateur de faire la réparation.

2.1.3 Pourquoi ITIL ?

2.2 Conception des services (Service Design)

2.2.1 Gestion des niveaux de service

2.3 L’exploitation des services (Service Operation)

2.3.1 Gestion des évènements (Event Management)

Afin de pouvoir facilement décider de l’action (appropriée) à prendre, les évènements

2.3.2 Cas pratique I

La maintenance réactive comprend la réparation les incidents qui apparaissent dans

Priorité Temps de réponse

(a) Temps de réponse (b) Temps de résolution

Figure 2.2 – Exemple de KPI’s sur les interventions.

2.3.3 Gestion des incidents

Pourquoi un processus de gestion des incidents ?

La gestion des incidents permettra entre autres de :

Figure 2.4 – Le processus de la gestion des incidents, extrait de [8].

2.3.4 Gestion des problèmes (Problem Management)

Citons quelques exemples de problèmes :

Un élément de configuration peut être :

Qualité, nettoyage et validation de

3.1 Qualité de données

3.1.3 Les dimensions

Ci-dessous une définition de l’exactitude est proposée.

Id Nom Pays Fondé # de titres Dernier titre

1 Real Madrid C.F. Espagne 1902 9 1908

2 A.C. Mlan Italie 1899 7 2007

3 Liverpool F.C. Allemagne 1892 5 NULL

4 FC Bayern Munich Angleterre 1900 4 2001

5 FC Barcelona Espagne 1899 4 2011

6 RSC Anderlecht Belgique 1908 0 NULL

Figure 3.1 – La relation LigueDesChampions.

L’exactitude sémantique est la proximité de la valeur A par rapport à la vraie valeur

La complétude peut être définie en général comme suit :

Dans [20], trois types de complétude sont proposés. La complétude au niveau du

La cohérence concerne tout ce qui se rattache à la violation des règles sémantiques.

3.2 Nettoyage et validation de données

Définition Qu ’est ce qu ’une

Données Nettoyage Données

De meilleure Données Validation

Figure 3.2 – Le module de nettoyage des données.

Ce type de problème est appelé le problème de ”merge-purge” (dans le domaine des

3.2.3 Les méthodes

Problèmes issus Problèmes issus

Niveau schéma Niveau tuple Niveau schéma Niveau tuple

Problèmes liés à la qualité de données

issus de plusieurs sources

issus d ’une seule source

Figure 3.4 – La méthode Sorting Neighborhood.