Système de rapports d incidents conforme aux normes ITIL pour le réseau A.S.T.R.I.D

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 Web & Information Technologies Année académique 2011-2012

Remerciements Je souhaite adresser mes remerciements les plus sincères aux personnes qui m ont apporté leur aide et qui ont contribué à l élaboration de ce mémoire. Je tiens à remercier mon promoteur Olivier Firket qui s est toujours montré à l écoute et très disponible tout au long de la réalisation de ce mémoire, ainsi pour l inspiration, l aide et le temps qu il a bien voulu me consacrer. Mes remerciements s adressent également au Professeur Esteban Zimányi, le directeur de mémoire, pour ses conseils, relectures et retours. Je remercie également tous les membres de ma famille pour m avoir supporté pendant ces longues années d études. Merci beaucoup Mama, Papa et Ali. i

Table des matières Remerciements i 1 Introduction 1 1.1 Contexte.................................... 1 1.2 Aperçu d ITIL................................. 2 1.3 Objectifs de ce mémoire........................... 3 2 ITIL 4 2.1 Introduction.................................. 4 2.1.1 Historique............................... 4 2.1.2 ITIL et l approche orienté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 évènements (Event Management)........... 7 2.3.2 Cas pratique I............................. 8 2.3.3 Gestion des incidents......................... 9 2.3.4 Gestion des problèmes (Problem Management)........... 11 2.4 La CMDB................................... 11 2.5 Conclusions.................................. 12 3 Qualité, nettoyage et validation de données 13 3.1 Qualité de données.............................. 13 3.1.1 Introduction.............................. 13 3.1.2 Définition............................... 13 3.1.3 Les dimensions............................ 14 3.2 Nettoyage et validation de données..................... 17 3.2.1 Introduction.............................. 17 3.2.2 Définition............................... 17 3.2.3 Les méthodes............................. 19 3.3 Conclusions.................................. 20 4 Analyse du problème et solution proposée 23 4.1 Fonctionnalités à implémenter........................ 23 4.2 État de l art.................................. 24 4.3 Fonctionnement général du programme................... 26 ii

TABLE DES MATIÈRES iii 4.3.1 Optique de développement...................... 26 4.3.2 Les interventions........................... 26 4.3.3 Choix des infrastructures....................... 27 4.3.4 Structure de la base de données................... 27 4.3.5 Choix des dimensions pour la qualité de données.......... 28 4.3.6 Nettoyage et validation de données................. 31 4.3.7 Analyse temporelle.......................... 34 4.4 Patrons de conception............................ 34 4.4.1 Singleton............................... 34 4.5 Conclusions.................................. 35 5 Ré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 généré 48

Table des figures 1.1 Architecture du réseau A.S.T.R.I.D. extrait de [2].............. 2 2.1 Les composants d ITIL - schéma des publications tiré de [9]........ 6 2.2 Exemple de KPI s sur les interventions.................... 9 2.3 Les données relatives aux incidents constituent la matière première du systè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 données..................... 18 3.3 Classification des erreurs dans les sources de données - inspiré de [21]... 21 3.4 La méthode Sorting Neighborhood...................... 22 3.5 La méthode Sorting Neighborhood - Le calcul des clefs de tri - inspiré de [12]....................................... 22 4.1 Format du rapport à générer......................... 24 4.2 Quelques outils de reporting.......................... 25 4.3 Exemple de ticket............................... 26 4.4 Le déroulement d une intervention...................... 27 4.5 La base de données existante......................... 28 4.6 Les colonnes ajoutée à la table Intervention................. 29 4.7 Exemple illustrant les deux significations de la valeur NULL........ 29 4.8 Exemple illustrant une incohérence...................... 30 4.9 Exemple de valeurs inexactes......................... 30 5.1 La fenêtre principale du programme..................... 37 5.2 L adresse de la base de données........................ 37 5.3 Le module qualité des données........................ 38 5.4 Les incidents dé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 données - 1................................ 50 B.6 Les données - 2................................ 50

Listings 4.1 La stabilité.................................. 30 4.2 La complétude................................ 30 4.3 La cohérence................................. 30 4.4 L exactitude.................................. 31 4.5 Stockage des dates indésirables dans un fichier XML............ 31 4.6 Déclencheur de réinitialisation........................ 32 4.7 Nettoyage de données 1............................ 32 4.8 Nettoyage de données 2............................ 32 4.9 Nettoyage de données 3............................ 33 4.10 Nettoyage de données 4............................ 33 4.11 Nettoyage de données 5............................ 33 4.12 Nettoyage de données 6............................ 33 4.13 Validation de données............................ 34 4.14 Le gestionnaire de la base de données (DataManager)........... 34 vi

Chapitre 1 Introduction Dans ce chapitre, nous allons introduire ce mémoire en décrivant le contexte dans lequel il s inscrit. Ensuite, nous ferons une brève introduction d ITIL. Finalement, nous terminerons ce chapitre en énonçant les objectifs de ce mémoire. 1.1 Contexte Le réseau A.S.T.R.I.D (pour All around Semi-cellular Trunked Radio and Integrated Dispatching) est un réseau dédié aux radiocommunications des services de secours et de sécurité en Belgique employant un système radio digital TETRA 1. Ce réseau est géré par la société de même nom A.S.T.R.I.D SA qui fût créée en 1998 par l État belge dans le but de coordonner les différents services de secours. En effet, l État belge a constaté un manque de coordination entre ces services suite à deux faits précurseurs qui sont les drames de Heysel 2 et de Herald of Free enterprise 3. Afin d arriver à ses fins, A.S.T.R.I.D a conclu un contrat de maintenance du réseau radio avec Belgacom et Cassidian 4. Belgacom, quant à elle, sous-traite la partie logicielle à Intergraph. Ce mémoire se déroule au sein de la compagnie Intergraph. 1. TETRA (pour TErrestrial Trunked RAdio) est une norme développée en Europe pour les radiocommunications digitales de voix et de données conçue pour les besoins professionnels et en particulier, pour les services de secours et de sécurité. Les systèmes A.S.T.R.I.D reposent sur cette norme TETRA et fonctionnent dans la bande de fréquence 380-400 Mhz, spécialement réservée aux services de secours et de sécurité en Europe [?]. 2. Le drame du Heysel, survenu le 29 mai 1985 à Bruxelles en Belgique, est l une des tragédies les plus marquantes liées à une manifestation sportive, et due au hooliganisme. Il eut lieu à 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 séparation et un muret s effondrèrent sous la pression et le poids de supporters, faisant 39 morts et plus de 600 blessé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 défense et de sécurité d EADS (pour European Aeronautic Defence and Space Company). 1

Chapitre 1 : Introduction 2 Comme montré à la Figure 1.1, le réseau A.S.T.R.I.D est constitué de onze CIC s (pour Centre d Information et de Communication), un CIC par province plus un CIC pour la région de Bruxelles-capitale [3]. Chaque CIC comporte tous les équipements nécessaires au routage des communications. Les CIC s réunis constituent le cerveau du réseau A.S.T.R.I.D. Toutes les demandes d appels et les appels eux-mêmes transitent par les CIC s. Ils connaissent à chaque instant la position d un poste allumé se trouvant sous la couverture du réseau. Ils sont également connectés à des systèmes externes comme les réseaux téléphoniques fixes ou mobiles [4]. Figure 1.1 Architecture du réseau A.S.T.R.I.D. extrait de [2]. Comme cité plus haut, la partie logicielle qui permet aux opérateurs d effectuer leur travail est assurée par Intergraph. Afin de bien gérer l infrastructure informatique, Intergraph s appuie sur ITIL, une bibliothèque regroupant les bonnes pratiques concernant la fourniture et la gestion de services informatiques. Ce mé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 tâche de support des logiciels. 1.2 Aperçu d ITIL ITIL (pour Information Technology Infrastructure Library) est un ensemble de bonnes pratiques pour les infrastructures informatiques. Cet ensemble de bonnes pratiques permet de surmonter les difficultés liées à la croissance des systèmes informatiques. Une étude plus approfondie d ITIL est réalisée dans le chapitre suivant.

Chapitre 1 : Introduction 3 1.3 Objectifs de ce mémoire En connaissant le contexte, et en ayant eu un bref aperçu d ITIL, nous pouvons maintenant énoncer les objectifs de ce mémoire. Il s agit de déployer un logiciel de reporting correspondant à diffé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 générer des rapports qui respectent un format bien déterminé. Le deuxième module sera principalement un outil de comparaison entre les différents sites CIC s. Cet outil servira de support pour le premier outil dans le sens où il pourrait aider à expliquer les résultats obtenus dans les rapports générés. Après avoir commencé le travail, nous nous sommes rendu compte de la nécessité de l implémentation d un troisième module. Ce dernier module nous permettra de : Faire une estimation de la qualité des données Nettoyer les donné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 années 80. Dans ces années là, le gouvernement britannique s était rendu compte que le niveau de la qualité des services IT qui leur sont fournis n était pas suffisant. Suite à 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 déjà rédigé plusieurs livres sur la gestion des services informatiques dans les années 90. L objectif était de développer des méthodes efficaces afin de garantir un certain niveau de qualité des services 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 orienté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 ça se faisait dans le passé. En effet, chaque produit pratiquement est vendu sous la forme d un service. Que ça soit une garantie sur le produit même, un support après vente,..., etc. Dans ITIL, un service est défini comme suit : 2.1 Définition Un service est un moyen de délivrer de la valeur aux clients en facilitant la production des résultats dans leurs activités sans qu ils aient à se préoccuper des coûts et des risques spécifiques au service qui leur est fourni [9]. Produit et service, tous deux, sont là pour satisfaire les besoins des utilisateurs. Néanmoins, la grande différence entre un produit et un service est que dans le cas d un service les utilisateurs s en servent sans devoir le posséder. Par exemple, si nous considérions l industrie automobile, dans le passé les voitures étaient vendues en tant que produits, 4

Chapitre 2 : ITIL 5 c est-à-dire lors d une panne c est la responsabilité de l utilisateur de faire la réparation. Aujourd hui, ce produit est souvent vendu comme un service en étant associé à un service de garantie (la voiture et le service de garantie constitue le service final), si jamais pendant un certain nombre d années une panne a lieu alors c est la responsabilité du constructeur de réparer la panne. 2.1.3 Pourquoi ITIL? La première question que nous pourrions nous poser est, pour quelle(s) raison(s) utiliser ITIL? Dans ce qui suit, nous allons essayer de répondre à cette question. De manière générale, les technologies d information peuvent être très complexes. Afin de gérer cette complexité, il est important de définir des processus claires, consistants et bien définis (qui peuvent être répétés). ITIL permet d identifier, d améliorer et de documenter les processus mis en œuvre. Ce qui peut résulter en une amélioration de l organisation de l entreprise. 2.2 Définition Un processus est un ensemble d activités coordonnées mettant en œuvre des ressources et des capacités en vue de produire un résultat aux clients [15]. Chacun des ouvrages de base qui constituent ITIL (au nombre de cinq) est destiné à améliorer un certain nombre de points bien précis dans une entreprise. En un premier temps, nous allons parcourir ces points pour chaque ouvrage. Ensuite, nous allons détailler les points qui sont directement liés au contexte de ce mémoire. Stratégie des services (Service Strategy) [17] : Ce volume de haut niveau explique comment faire l alignement du systè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 service est examiné afin de déterminer la façon de le concevoir pour qu il puisse être implémenté dans le système d informations tout en étant efficace et compétitif. Transition des services (Service Transition) [18] : Cet ouvrage décrit les objectifs 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) réussie, la réduction d impacts non pré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 conception des services) fourniture et gestion des services IT. L exploitation des services comprend : la résolution des défaillances du service, la résolution des problèmes,..., etc. Amélioration continue des services (Continual Service Improvement) [14] : Ce processus, comme son nom le laisse entendre, a pour objectif l amélioration continue de l efficacité des services en se basant sur des méthodes de gestion de qualité. La Figure 2.1 illustre la maniè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 - schéma des publications tiré de [9]. 2.2 Conception des services (Service Design) Cette partie d ITIL a pour but d assurer que les services sont conçus de façon à répondre aux besoins d affaires (Business). Dans la conception des services, plusieurs processus sont définis comme : la gestion de la disponibilité, la gestion des niveaux de service, la gestion de la capacité,..., etc. Dans la suite, seuls les processus qui sont en lien direct avec le contexte de ce mémoire seront présentés. Lors de la conception de services, plusieurs aspects doivent être pris en compte. Parmi ces aspects nous pouvons citer [9] : L alignement sur les besoins d affaires : Les objectifs d affaires doivent être satisfaits par la conception des services. L optimisation des délais et des coûts : Il faut avoir à l esprit qu après la phase de conception des services, ces derniers vont être améliorés au fur et à mesure et donc penser à minimiser les coûts à long terme. La gestion des risques : Avant que les services passent en production, il est nécessaire de connaître les risques pour pouvoir les éliminer ou les réduire (au moins). La mesures des objectifs : Pour pouvoir améliorer les services, il faut d abord connaître le niveau d atteinte des objectifs. Pour cela, des méthodes ainsi que des métriques doivent être conçus.

Chapitre 2 : ITIL 7 2.2.1 Gestion des niveaux de service La gestion des niveaux de service est un processus qui vise à 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 Définition Un accord sur les niveaux de service (Service Level Agreement ou SLA) est un accord écrit entre un fournisseur de services et un ou des clients. Il porte sur un ou plusieurs services d affaires et décrit les niveaux de services prévus avec la ou les organisations d affaires (disponibilité, capacité, sécurité et continuité de service) [9]. Ces SLA s constituent une façon formelle et donc mesurable pour définir les responsabilités de chaque partie (client et fournisseur). Afin de pouvoir quantifier ces SLA, des indicateurs clés de performance ou KPI s (pour Key Performance Indicator ou KPI ) sont fixés. Ensuite, ce sont les KPI s qui seront mesurés afin de savoir si les SLA s ont été respectés ou pas. 2.4 Définition Un indicateur clé de performance (Key Performance Indicator ou KPI) est un ensemble de métriques objectives et mesurables qui permettent d évaluer si les différents niveaux de services convenus (SLA) ont été respectés. ITIL propose également de définir d une manière claire et précise des pénalités au cas où des SLA s n ont pas été respectés et ceci en selon le manquement observé. 2.3 L exploitation des services (Service Operation) C est dans cette étape que le service est fourni à l utilisateur. Une fois que le service est fourni, il faut le gérer. Pour cela, il est nécessaire de collecter des données, de faire des mésures, de vérifier les performances,..., etc. L exploitation des services est donc une étape très importante puisque c est à ce moment qu on voit à quel niveau les besoins des utilisateurs ont été satisfaits. Dans ce qui suit, nous allons décrire quelques processus de l exploitation des services. 2.3.1 Gestion des évènements (Event Management) L intérêt de la gestion des évènements est de s assurer que les services fournis sont bien surveillés afin de pouvoir détecter les évènements qui se produisent. Dans ITIL, un évènement est défini comme suit : 2.5 Définition Un évènement est une occurrence détectable ou discernable ayant une signification sur la gestion d une infrastructure ou la fourniture d un service et une évaluation de l impact indiquant qu une déviation pourrait apparaître sur les services [9].

Chapitre 2 : ITIL 8 Afin de pouvoir facilement décider de l action (appropriée) à prendre, les évènements seront classés selon des catégories. Il est évident que chaque entreprise aura sa propre catégorisation mais ITIL propose d utiliser au moins les trois catégories suivantes : Évènements informationnels Ces évènements signalent des opérations régulières et ne requièrent aucune action à prendre. Il seront enregistrés dans le système pour une certaine période. Des exemples de tels évènements sont : une transaction est terminée avec succès, une imprimante est prête à être utilisée, un appareil peut être retiré en toute sécurité,..., etc. Évènements d alerte Ces évènements signalent des opérations inhabituelles. Lorsqu ils sont pris en compte, ils permettent d éviter l apparition d une exception. Nous pouvons citer comme exemples : l utilisation de la mémoire approche un seuil critique (au delà duquel, un SLA pourrait être manqué), une transaction est terminée avec succès mais avec 10% plus de temps que d habitude,..., etc. Évènements signalant une exception Ces évènement signalent qu un service fonctionne de façon anormale. Les exceptions résultent souvent en un manquement d un SLA. Des exemples d exception sont : l utilisation de la mémoire a dépassé un seuil critique, une transaction a échoué,..., etc. 2.3.2 Cas pratique I Comme suggéré par ITIL, des SLA s, des KPI s et des pénalités ont été fixés au sujet de la maintenance préventive et réactive. De plus, chaque incident (ou problème) se voit attribué une priorité en fonction de sa gravité. La maintenance réactive La maintenance réactive comprend la réparation les incidents qui apparaissent dans le système de façon à ce que les délais imposés par les SLA s soient respectés. Il est donc primordial de savoir, à tout moment, si les SLA s sont respectés ou non. Or, Intergraph n a pas accès à la base de données des incidents (détenue par son client, Belgacom). Intergraph a donc développé un outil afin d avoir une trace sur les incidents. Concrètement, cet outil est utilisé par les ingénieurs de site. L outil développé dans ce mémoire se base sur les informations fournies par les ingénieurs de site et permettra de suivre l évolution des SLA s ainsi que de générer des rapports comparables à ceux produits par le client (Belgacom). A titre indicatif, un exemple (nombres fictifs) de KPI s est donné à la Figure 2.2. La maintenance préventive Un second mémoire ayant pour titre Outils de monitoring conforme ITIL : Application au réseau A.S.T.R.I.D. a été réalisé dans le même contexte de ce mémoire par Nicolas Vannieuwerburgh. A travers ce mémoire, un outil de maintenance préventive a été réalisé.

Chapitre 2 : ITIL 9 Priorité Temps de réponse 1 4 heures 2 12 heures 3 Fin du jour ouvrable suivant 4 --- (a) Temps de réponse Priorité Temps de résolution 1 4 heures pour 98% des incidents 5 heures pour 100% des incidents 2 24 heures 3 Fin du jour ouvrable suivant 4 5 jours ouvrables (b) Temps de résolution Figure 2.2 Exemple de KPI s sur les interventions. 2.3.3 Gestion des incidents Quelque soit le niveau de qualité des systèmes informatiques, des incidents se produisent toujours. Si ces incidents ne sont pas résolus rapidement, ils peuvent avoir un impact négatif sur la confiance des utilisateurs. C est pourquoi il est très important pour une entreprise d implanter un processus de gestion des incidents. 2.6 Définition Un incident est un évènement entrainant une interruption ou une baisse de qualité pour un service. Les évènements ayant un impact potentiel mais non encore observé sont également considérés comme des incidents. La gestion des incidents est un point clé dans le cadre de ce mémoire. En effet, nous pouvons voir l outil de reporting comme un système avec une entrée et une sortie. A l entrée de ce système, nous retrouvons les données relatives aux incidents, et à sa sortie, des rapports permettant de vérifier l état des SLA s (maintenance réactive). Voir figure 2.3. Ci-dessous, une définition de la gestion des incidents est proposée : 2.7 Dé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 négatif sur les activités métiers. Nous pouvons donc dire que le but de la gestion des incidents est le rétablissement rapide du fonctionnement normal du service. Contrairement à la gestion des problèmes, la gestion des incidents ne se préoccupe pas des causes des incidents, on résout les incidents peu importe le moyen. Pour mieux visualiser, voici quelques exemples d incidents : Les requêtes de la base de données prennent un temps plus long que ce qui est défini par le SLA Le nombre d entrée/sortie d un disque dur est trop grand Le serveur d une base de données a échoué...

Chapitre 2 : ITIL 10 Rapports (KPI) Données relatives aux incidents Programme Qualité des données Comparaison par site CIC Figure 2.3 Les données relatives aux incidents constituent la matière première du système. Pourquoi un processus de gestion des incidents? La gestion des incidents permettra entre autres de : Empêcher les incidents de devenir critiques et affecter la qualité de service Avoir une trace de tous les incidents qui se produisent, de cette façon on évite de refaire tout le travail pour résoudre ce même type d incidents. Description du processus La Figure 2.4 représente les cinq étapes du processus de la gestion des incidents. Tout d abord la détection et l enregistrement de l incident : à cette étape on peut déterminer si l incident a déjà eu lieu et si une solution rapide existe, la classification de l incident : cette étape permet d attribuer une priorité à l incident, la recherche et diagnostic, la résolution et la restauration du service et pour terminer la clôture de l incident avec la remise du rapport (qui contient entre autres, le temps passé, détails des actions effectuées,..., etc.). Début Enregistrement de l incident Classification de l incident Recherche et diagnostic Fermeture de l incident Résolution et restauration du service Fin Figure 2.4 Le processus de la gestion des incidents, extrait de [8].

Chapitre 2 : ITIL 11 2.3.4 Gestion des problèmes (Problem Management) La gestion des problèmes est un processus qui s occupe de gérer le cycle de vie de tous les problèmes. Ce processus a pour but d empêcher que des incidents aient lieu et de minimiser leur impact sur le Business lorsqu ils ne peuvent pas être évités. ITIL définit les problèmes comme suit : 2.8 Définition Un problème est la cause d un incident ou d une série d incidents. Citons quelques exemples de problèmes : Problèmes Défaillance systématique d un programme lors de certaines manipulations Défaillance d un serveur provoquant plusieurs incidents sur les machines clientes Défaillance régulière d un service sans pistes de solution... 2.4 La CMDB La CMDB (pour Configuration Management DataBase) est une base de données de gestion des configurations. L objectif de la CMDB est de stocker les détails des éléments de configuration CI (pour Configuration Item) ainsi que les relations entre eux pendant tout leur cycle de vie. ITIL définit un élément de configuration comme suit : 2.9 Définition Un élément de configuration est tout composant ou autre actif de service dont la fourniture d un service informatique requiert sa gestion [9]. Un élément de configuration peut être : un service informatique un utilisateur un SLA le matériel un incident... En particulier, la CMDB est à la base de tous les processus de traitement des incidents et des problèmes.

Chapitre 2 : ITIL 12 2.5 Conclusions Dans ce chapitre, nous avons présenté ITIL de façon générale en expliquant la raison d être de ces différents composants : la stratégie des services, la conception des services, la transition des services, l exploitation des services et l amélioration continue des services. Ensuite, nous nous sommes focalisés sur les processus qui sont en lien direct avec le contexte de ce mémoire. Pour terminer, il est important de mettre l accent sur le fait qu ITIL n a pas de frontières strictes. C est à dire que toute entreprise désirant implémenter ITIL, peut le faire selon ses besoins. Du coup, il est difficile de trouver deux entreprises ayant une même implémentation d ITIL.

Chapitre 3 Qualité, nettoyage et validation de données 3.1 Qualité de données 3.1.1 Introduction Les données sont considérées comme une ressource précieuse car elles constituent la matière première dans un système d informations. Il est donc nécessaire de s assurer que ces données sont complètes, précises, correctes,..., etc. Autrement dit, les données doivent avoir une certaine qualité. Ce chapitre sert de base pour l élaboration de l outil de nettoyage de données (le troisième module). En effet, nous allons expliquer, dans ce chapitre, les métriques que nous allons utiliser afin de pouvoir détecter les problèmes liés aux données. De cette façon, nous pourrons donner un indice sur la qualité de nos données. Les sections suivantes seront consacrées à la réparation des éventuels problèmes détectés et à la validation des données. 3.1.2 Définition Dans la littérature, nous retrouvons plusieurs définitions pour la qualité de données. Une de ces définitions est la suivante : 3.1 Définition Une donnée est de qualité si elle satisfait aux exigences de son utilisation dans un contexte donné [19]. Dans cette définition, on considère une approche contextuelle. C est cette approche là qui sera considéré dans ce travail. En effet, la qualité des données dépend très fort des données mêmes ainsi que du contexte dans lequel ces données sont utilisées. Ainsi, les mêmes données peuvent être de grande qualité pour un usage et de mauvaise qualité pour un autre usage. De cette façon, dire que des données sont de qualité dans l absolu n a pas de sens, il faudrait préciser les critères que l on considère ainsi que l usage de 13

Chapitre 3 : Qualité, nettoyage et validation de données 14 ces données. Du coup, il n existe pas de recette toute faite qui fonctionne dans tous les cas. Dans le contexte de ce mémoire (qui sera détaillé dans le chapitre suivant), quatre critères sont considérés afin de pouvoir faire une estimation de la qualité de nos données. Nous détaillerons ces aspects dans la section suivante. 3.1.3 Les dimensions La qualité de données est une agrégation de plusieurs critères (ou dimensions) comme la complétude (completeness), l exactitude (accuracy),..., etc. Dans les ouvrages de référence, les dimensions de la qualité de données sont souvent définies différemment (nom et signification). Il est à noter que 179 dimensions on été définies en 1996 [26] pour la qualité de données. Dans le contexte de ce mémoire, il n y a pas d intérêts de faire une étude de toutes ces dimensions. Dans ce qui suit, nous tenterons de définir et donner des exemples de quelques dimensions des plus répandues et ensuite (voir le prochain chapitre) nous ferons un choix parmi ces dimensions qui nous permettra de mieux répondre aux exigences de ce travail. L exactitude (accuracy) Ci-dessous une définition de l exactitude est proposée. 3.2 Définition L exactitude est la proximité d une valeur A à une autre valeur B considérée comme la représentation correcte d une entité réelle que A tente de représenter [5]. Deux types d exactitude peuvent être distingués ici, une exactitude syntaxique et une exactitude sémantique [5]. L exactitude syntaxique est la proximité d une valeur A par rapport aux éléments de l ensemble de définition de A, disons D. Ainsi, la valeur A = Belgique est considérée comme une valeur correcte même si B = Italie, si le domaine D est l ensemble des pays de l Europe. Considérons la relation LigueDesChampions montrée à la Figure 3.1. Cette relation représente des équipes de football ayant disputé ce tournoi européen de football avec le nom, le pays d origine, l année de fondation, le nombre de fois où l équipe a remporté le tournoi ainsi que l année du dernier triomphe. La valeur A.C. Mlan pour le Nom de l équipe 3 n est pas exacte syntaxiquement, puisque cette valeur ne correspond à aucune équipe de football européenne ayant participé à la Ligue des champions. Par contre, si nous comparions cette valeur à toutes les valeurs du domaine en question, nous trouverions une distance de Levenstein 1 égale à 1 (comparaison avec la valeur A.C. Milan). En effet, l exactitude syntaxique peut être mesurée en utilisant une fonction de comparaison (ici la distance de Levenstein). 1. La distance de Levenshtein mesure la similarité entre deux chaînes de caractères. Elle est égale au nombre minimal de caractères qu il faut supprimer, insérer ou remplacer pour passer d une chaîne à l autre. Elle est aussi connue sous le nom de distance d édition ou encore de déformation dynamique temporelle [27].

Chapitre 3 : Qualité, nettoyage et validation de données 15 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 sémantique est la proximité de la valeur A par rapport à la vraie valeur B. Ainsi si nous considérions l exemple donné à la Figure 3.1, nous pouvons remarquer que les Pays des équipes 3 et 4 ont été permutés. Du coup, les valeurs Allemagne et Angleterre ne sont pas exactes sémantiquement malgré qu elles le sont syntaxiquement. La complétude (completeness) La complétude peut être définie en général comme suit : 3.3 Définition La complétude se réfère au fait d avoir toutes les parties requises d un assemblage de données présentes. Dans [20], trois types de complétude sont proposés. La complétude au niveau du schéma, la complétude au niveau de la colonne et la complétude au niveau de la population. La complétude au niveau du schéma est définie comme le degré avec lequel toutes les entités et les attributs sont représentés. La complétude au niveau de la colonne est une mesure des valeurs manquantes d une colonne dans une table. La complétude au niveau de la population, quant à elle, est une mesure des valeurs manquantes par rapport à une autre population de référence. Dans un modèle relationnel, la présence de la valeur NULL (lorsque c est permis) peut avoir plusieurs significations. Afin de pouvoir mesurer la complé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 dernière colonne. Le tuple de Liverpool F.C. est incomplet, puisque Liverpool F.C. a déjà remporté 5 titres, tandis que le tuple de RSC Anderlecht est complet car ce dernier n a pas encore remporté de titres.

Chapitre 3 : Qualité, nettoyage et validation de données 16 La cohérence (consistency) La cohérence concerne tout ce qui se rattache à la violation des règles sémantiques. Dans les modèles relationnels, la cohérence concerne le non respect des contraintes d intégrités. Dans l exemple de la Figure 3.1, il y a un problème de cohérence pour le tuple de Real Madrid C.F. au niveau des trois dernières colonnes. En effet, sachant que le tournoi de la ligue des champions est organisé une fois par an, cette équipe ne peut pas avoir gagné neuf titres en sept ans. Par contre, il n est pas possible de dire d où 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 être traduit en français de plusieurs manières : opportunité, ponctualité, rapidité,..., etc. Cette dimension temporelle désigne le caractère à jour des données. Ci-dessous, une définition est proposée : 3.4 Définition La promptitude est le degré d actualité des données en tenant compte des tâches dans lesquelles elles sont utilisées [20]. La volatilité (volatility) La volatilité est la durée pendant laquelle les données demeurent valides [20]. Par exemple, les dates de naissance sont des données stables qui ne varient jamais et par conséquent ont une volatilité égale à 0. Un exemple de données très volatiles est celui des cours boursiers. Le tableau suivant donne plusieurs définitions pour les dimensions précédentes. Dimension L exactitude La complétude Définition Le niveau avec lequel les données sont correctes, fiables et certifiées exempts d erreurs [5]. Le degré de la présence de valeurs dans une collection de données [22]. La cohérence Le degré avec lequel les données sont toujours représentées de la même façon et sont compatibles avec les données précédentes [5]. La promptitude La volatilité La mesure dans laquelle l âge des données est approprié pour la tâche considérée [5]. La fréquence avec la quelle les données varient dans le temps [7].

Chapitre 3 : Qualité, nettoyage et validation de données 17 3.2 Nettoyage et validation de données 3.2.1 Introduction Le nettoyage de données (data cleansing, data cleaning ou encore data scrubbing en anglais) est une étape importante dans le processus de gestion de l information [1]. En effet, il est pratiquement impossible d avoir des données sans erreurs (surtout quand il s agit de données volumineuses). Ces erreurs peuvent avoir deux causes : elles sont créées pendant le traitement des données (mauvaise modélisation de l architecture du système) ou alors elles parviennent depuis la source de données (qui constitue le facteur majeur). Même en améliorant le processus d acquisition et d entrée de données, des erreurs peuvent toujours apparaître dans le système. Il est donc nécessaire de parcourir les données afin de détecter les erreurs et de les corriger, ce qui est très coûteux pour des données volumineuses. 3.2.2 Définition Le nettoyage de données peut être défini différemment selon le domaine dans lequel il est appliqué. Les principaux domaines dans lesquels le nettoyage de données a été étudié sont : les entrepôts de données, l exploration de données 2 et la gestion de la qualité de données [13]. Le tableau suivant donne quelques définitions pour le nettoyage de données en fonction du contexte. Définition Le processus qui permet d identifier et de corriger les informations incomplètes et incorrectes dans les bases de données [24]. Le processus de découverte des formes de données inutiles, vides de sens ou mal étiquetées [10]. Le nettoyage de données s occupe de détecter et enlever les erreurs et les inconsistances dans les données dans le but d améliorer leur qualité [21]. Domaine Base de données financières. L apprentissage automatique (machine learning en anglais). Entrepôt de données Nous pouvons donc voir le nettoyage de données comme un processus qui, à son entrée, reçoit des données brutes qui pourraient contenir un certain nombre d erreurs et qui génère à sa sortie un sous-ensemble de ces données exempt de ces erreurs. La Figure 3.2 résume la situation. Donc, pour implémenter un outil de nettoyage de données, la première étape à faire est de définir les problèmes que nous voudrions éviter dans nos données (comme définis dans la section précédente). Ensuite, il faut écrire les règles qui permettent de détecter ces problèmes. Finalement, il faut remédier les problèmes détectés lorsque c est possible. 2. L exploration de données (data mining en anglais) a pour objet l extraction d un savoir ou d une connaissance à partir de grandes quantités de données, par des méthodes automatiques ou semiautomatiques [29].

Chapitre 3 : Qualité, nettoyage et validation de données 18 Définition des problèmes Qu est ce qu une donnée de bonne qualité?? Données brutes Nettoyage de données Données propres Eventuellement de mauvaise qualité De meilleure qualité Données valides Validation de données Figure 3.2 Le module de nettoyage des données. Les problèmes dans les données peuvent être classifiées en deux catégories, selon que les données sont collectées à partir d une seule source ou de plusieurs sources, voir Figure 3.3(a). Nous pouvons aussi distinguer entre les problèmes au niveau tuples (c est ce type de problèmes que le nettoyage de données tente de résoudre) et ceux au niveau du schéma (dont la résolution nécessite une transformation des données). Dans la suite, nous nous restreignons au problèmes au niveau tuples. Une vue d ensemble est proposée à la Figure 3.3(b). En effet, il est évident que les problèmes issus de plusieurs sources englobent ceux dans le cas d une seule source. Les erreurs dans les données peuvent se produire à l acquisition ou pendant le traitement dans la chaîne de la gestion de l information. Un exemple de traitement intéressant qui pourrait générer des erreurs est l intégration des données. En effet, lors de l intégration de différentes bases de données des doublons (plusieurs représentation d une même entité réelle) peuvent apparaître. En effet, nous pouvons distinguer deux cas de figures lors de l agrégation de différentes tables : Les attributs des tables peuvent être structurés différemment. Par exemple, dans une base de données, le nom d un client peut être enregistré dans une seule colonne (nom) tandis que dans une autre base de données, ce même nom de client peut être enregistré à l aide de plusieurs colonnes (civilité, prénom, nom). Même lorsque les attributs des tables sont identiques, un même objet réel peut être représenté différemment. Par exemple, les adresses bvd Émile Jacqmain, Boulevard É. Jacqmain et bvd É. Jacqmain sont la représentation d une même adresse.

Chapitre 3 : Qualité, nettoyage et validation de données 19 Ce type de problème est appelé le problème de merge-purge (dans le domaine des entrepôts de données). Dans la littérature, d autres appellations existent pour ce même type de problème comme : record linkage, semantic integration, instance identification ou encore object identity [12]. 3.2.3 Les méthodes Les méthodes appliquées dans le processus de nettoyage de données sont multiples. Celles-ci peuvent être réparties en deux catégories : les méthodes dépendantes de domaine et celles indépendantes de domaine. La majorité des méthodes que nous retrouvons dans la littérature tentent de résoudre des problèmes spécifiques. Cela peut être expliqué par le fait qu il est très compliqué de développer des méthodes efficaces qui peuvent être appliquées partout. De plus, comme nous allons le voir dans les sections qui suivent, la connaissance du contexte permet d améliorer la performance des méthodes. Les méthodes les plus répandues tentent de résoudre les problèmes des doublons et les problèmes dans les noms propres et les adresses postales. Élimination de doublons Beaucoup de travaux, comme dans [6], [11],[31] et [23], ont été réalisés afin de détecter les doublons et les doublons similaires 3. Dans la plupart de ces travaux, les méthodes présentées se reposent sur des fonctions de tri ainsi que des fonctions de comparaison de similarité. Naturellement, l efficacité de ce type de méthodes dépend très fort de la façon dont on compare les différentes entrées. Ainsi pour une base de données avec N entrées, le nombre de comparaison à effectuer est de (N 1) N ce qui peut être très lent pour un N 2 élevé. [11] présente une méthode (Sorted Neighborhood Method) afin de limiter le nombre de comparaisons et du coup accélérer le calcul. La modification apportée dans cette méthode est que le tri est effectué de façon à regrouper les entrées similaires. Ensuite, la comparaison est effectuée seulement pour un nombre fixe d entrées (la fenêtre, w) ce qui demande N w comparaisons. Encore une fois, l efficacité de cette méthode dépend de bon choix de la clef utilisée pour effectuer le tri (spécifique au domaine). La Figure 3.4 illustre le fonctionnement de cette méthode. Les clefs peuvent être obtenues en concaténant plusieurs attributs ou plusieurs sousensembles de ces attributs. La Figure 3.5 donne un exemple de construction de clefs. Dans cet exemple, la clef a été construite de la façon suivante : les trois premiers chiffres du numéro d identification à la sécurité sociale sont concaténés avec les trois premières lettres du prénom, suivis par les trois premières consonnes du nom. Ensuite, on ajoute le numéro de l adresse ainsi que toutes les consonnes du nom de la rue. Nous pouvons remarquer que les deux premières entrées sont identiques, la troisième entrée est probablement la même personne mais avec une erreur dans le nom. La quatrième entrée est probablement 3. Les doublons similaires sont des entités identiques mais qui ont subi une modification par erreur.

Chapitre 3 : Qualité, nettoyage et validation de données 20 une personne différente mais ayant la même clef que les trois premières entrées. Finalement, nous pouvons clairement voir qu un mauvais choix d attributs donnera de mauvais résultats. D autres difficultés liées au problème de détection des doublons persistent. Par exemple, la détection des doublons proches 4. Ou encore, le problème d abréviation 5. [25] propose de résoudre ce dernier en comparant l entrée la plus courte avec les x premières lettres de l entrée la plus longue (x étant la longueur de la plus petite chaîne). Cette méthode pose problème pour certains cas, par exemple considérons les deux chaînes de caractères John et Johnathan, ils seront considérés comme doublons selon cette méthode. [23] propose d améliorer cette méthode en prenant x = la moyenne des longueurs des deux chaînes de caractères. Malgré que cette modification permet de reconnaître plus de doublons que la méthode précédente, il exist d autres cas de figures où celle-ci donnerait de mauvais résultats. Par exemple, les mots VW et Volkswagen ne pourront jamais être reconnus comme doublons. Encore une fois, c est la connaissance du contexte étudié qui permettra d avoir de meilleurs résultats. 3.3 Conclusions Nous pouvons conclure en disant que le l élimination des problèmes de qualité de données est une tâche assez complexe. Néanmoins, cette complexité peut être réduite grâce aux contraintes imposées par la connaissance de contexte. C est pourquoi la grande majorité des outils qui existent dans le marché se focalisent en la résolution de problèmes bien précis (Adresses postales, numéros de téléphones,..., etc.). Dans le chapitre suivant, nous expliquerons la méthode utilisée (spécifique au contexte de ce mémoire) pour effectuer le nettoyage de données. 4. Les doublons proches sont des entités identiques par leur signification mais pas par leur apparence. Par exemple les mots Professeur et Enseignant peuvent être identiques dans certain contexte 5. C est le problème d associer les abrévations aux entités qu elles représentent.

Chapitre 3 : Qualité, nettoyage et validation de données 21 Problèmes liés à la qualité de données Problèmes issus d une seule source Problèmes issus de plusieurs sources Niveau schéma (Manque decontraintes d intégrités, schéma mal conçu) Niveau tuple (erreurs pendant la saisie des données) Niveau schéma (modèles de données hétérogènes) Niveau tuple (données incosistentes, 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 données - inspiré de [21].

Chapitre 3 : Qualité, nettoyage et validation de données 22 Fenêtre courante w w Prochaine fenêtre Figure 3.4 La mé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 méthode Sorting Neighborhood - Le calcul des clefs de tri - inspiré de [12].

Chapitre 4 Analyse du problème et solution proposée 4.1 Fonctionnalités à implémenter L outil de reporting attendu doit satisfaire plusieurs contraintes. Tout d abord, l exécution du logiciel de reporting doit influencer le moins possible l activité des bases de données. Cet outil sera utilisé dans des environnements Windows avec une base de données SQL Server. Le produit abouti devra en outre satisfaire les contraintes suivantes : Collecte des données : Le programme devra être capable de récolter des données pertinentes de manière fiable à partir de la base de données SQL Server, voir Figure 4.5. Les données relatives aux incidents sont mises à jour au fur et à mesure. Visualisation des données : Le programme doit proposer un outil flexible de visualisation des données. Celui-ci permettra d avoir un œil sur les KPI s. Il sera également possible de sélectionner une période de temps pour l affichage. Génération de rapports : Le programme permettra de générer des rapports (dans le logiciel et dans le format Excel). Ceux-ci devront être sous un format bien déterminé. Voir Figure 4.1. Transparence des rapports : Les rapports dans le format Excel doivent inclure toutes les données qui ont été utilisées afin de pouvoir aisément vérifier la crédibilité des résultats au cas où il y aurait un doute. Autrement dit, tous les calculs doivent être refaits dans le fichier Excel généré. Travail supplémentaire : Dans la mesure du possible, le programme doit fournir un outil de support dont les résultats ne seront pas générés dans les rapports. Concrètement, il s agit de comparer les différents sites CIC en terme d incidents apparus. De cette façon, l analyse des résultats pourra être poussée un peu plus loin afin détecter les incidents dont l origine n est pas la partie logicielle (responsabilité d Intergraph). Par exemple, un très grand nombre d incidents apparaissant dans un site CIC relativement petit pourrait laisser penser que c est un problème lié au réseau. Travail supplémentaire : Le programme devra être capable de détecter et de corriger les problèmes liés à la qualité de données. 23

Chapitre 4 : Analyse du problème et solution proposée 24 (a) Par mois (b) Par semaine 4.2 État de l art (c) Par an Figure 4.1 Format du rapport à générer. Il existe un grand nombre de systèmes de reporting. Cette section se propose de passer en revue certaines des solutions les plus répandues disponibles sur le marché. Nous tenterons aussi de mettre en évidence les aspects attractifs et répulsifs propres à chacun de ces produits. Microsoft SQL Server Reporting Services (MSSRS) Le premier système de reporting est une solution fournie par Microsoft. Ce système de reporting est disponible gratuitement si l on possède une licence de MS SQL Server. Néanmoins, ce système de reporting est uniquement destiné à être utilisé depuis une interface web. BIRT BIRT est un système de reporting open source destiné à être utilisé avec le langage de programmation Java, de coup il est cross-platform (Linux, Mac et Windows). Ce système de reporting bénéficie d un concepteur de rapports utilisant une approche web (il n est pas possible d avoir un contrôle total sur le positionnement des éléments de rapport). Il bénéficie également d une très bonne documentation. L installation est rendue un petit peu laborieuse puisque BIRT ne vient avec aucun support pour les serveurs de bases de données, c est à l utilisateur d installer chercher le bon pilote.

Chapitre 4 : Analyse du problème et solution proposée 25 JasperReports Cet outil est, comme BIRT, destiné pour les applications développés en Java. JasperReports, contrairement aux autres produits présentés ici, bénéficie d un emplacement au pixel près des éléments de rapport, c est donc un bon choix si les rapports générés doivent être imprimés. Contrairement à BIRT, JasperReports s installe avec un support pour les quelques serveurs de bases de données assez répandus comme MS SQL Server, Oracle, MySQL,..., etc. Crystal Reports Cet outil de reporting est l un des plus connus qui a longtemps été associé avec Microsoft et Visual Studio. Il est également cross-platform puisqu il peut être utilisé avec les plateformes COM,.NET, Delphi et Java. De plus, cet outil permet, outre la génération des rapports, la conception des tableaux de bord. Contrairement à MSSRS, Crystal Reports n est pas une solution uniquement basé- Web, en effet les rapports qu il génère peuvent aussi être utilisé 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 décidé de créer les rapports manuellement. (a) BIRT (b) JasperReports (c) Crystal Reports (d) MSSRS Figure 4.2 Quelques outils de reporting.

Chapitre 4 : Analyse du problème et solution proposée 26 4.3 Fonctionnement général du programme 4.3.1 Optique de développement L optique de développement de ce programme est bien sûr de fournir un logiciel fini ayant un certain nombre de fonctionnalités. Les points suivants montrent les critères auxquels il a été porté une attention toute particulière lors du développement. Transparence : Afin de rendre les résultats facilement vérifiables pour l utilisateur, il est nécessaire de toujours montrer les données qui ont été utilisées et qui sont à la base de ces résultats. Convivialité : Il va de soi que le logiciel doit pouvoir être employé sans trop de difficultés par une personne n ayant pas participé au développement. Dans cette philosophie, il a semblé intéressant d offrir une interface graphique simple, efficace, robuste et sans surenchère technologique. Légèreté : Le logiciel doit être le plus léger possible, notamment au point de vue de la connexion à la base de données. Ainsi, une seule connexion à la base de données est suffisante pour générer tous les résultats attendus. Paramétrabilité : L outil de reporting doit être paramétrable le plus possible (rien ne doit être codée en dur). En effet, à chaque fois qu il nous manque une information pour satisfaire une certaine tâche la meilleure solution est de créer un paramètre pour la tâche en question. 4.3.2 Les interventions Lorsqu un incident apparaît dans le système chez A.S.T.R.I.D, celui-ci crée un ticket (un ticket est un email qui contient des données concernant l incident apparu comme le numéro d incident, sa date de création, une description etc. La Figure 4.3 montre un exemple de ticket.) et l envoie à Intergraph. Dès la réception du ticket par Intergraph, un compteur est lancé marquant le début d une intervention. La figure 4.4 montre le déroulement d une intervention. Notons que des indicateurs clés de performance (KPI s) sont posés sur le temps de réponse (ResponseTime) et le temps de ré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.

Chapitre 4 : Analyse du problème et solution proposée 27 DateReceived (Intergraph) DateOnSite DateClosed Temps DateCreated (ASTRID) DateStarted DateFixed DateReport ResponseTime ( KPI) RepairTime ResolutionTime ( KPI) Figure 4.4 Le déroulement d une intervention. 4.3.3 Choix des infrastructures Concernant le choix du langage de programmation, nous avons opté pour C# (un langage de programmation orienté objet) pour coder le projet. En effet, ce langage de programmation, profitant directement de la plate-forme Microsoft.NET, est bien adapté au contexte de ce travail : Environnement Windows Génération de fichier Excel (sans devoir utiliser une API tierce) Notons qu il était prévu, à la base, d intégrer cet outil de repotring à un autre outil de chez Intergraph et que ce dernier est implémenté avec les technologies de Microsoft (Visual Studio,.NET, C#, SQL Server). Il était donc tout à fait naturel de garder ce choix de technologies. 4.3.4 Structure de la base de données N ayant pas accès à la base de de données des incidents, la base de données de la Figure 4.5 a été construite afin de combler ce manque d informations. En effet, tous les détails des incidents (lieu, état,..., etc.) sont envoyées dans la base de données des incidents qui est détenue par le client. Un outil a donc été développé afin d avoir ces informations. Celui-ci permet aux gestionnaires des incidents d entrer les détails des incidents manuellement. Le programme se connecte donc à la base de données dont le diagramme entité-relation est montré à la Figure 4.5 1. Au centre du diagramme se trouve la table Intervention qui reprend principalement, le numéro du ticket reçu (TTNr) ainsi que les temps caractéristiques d une intervention. Afin de pouvoir nettoyer/valider les données, nous avons rajouté des colonnes supplémentaires (voir Figure 4.6) dans la table Intervention. Ces colonnes peuvent être divisées en deux catégories : 1. Notons que la base de donnée et les tables contiennent, respectivement, des tables et des colonnes qui ne sont pas montrées sur le diagramme pour une raison de clarté.

Chapitre 4 : Analyse du problème et solution proposée 28 Des colonnes qui remplacent celles de mêmes noms (en supprimant le suffixe Cleaned) et qui contiennent les données nettoyées. Cette approche nous permet de ne pas écraser les données existantes. Notons que nous aurions pu créer une table supplémentaire et y ajouter seulement les tuples qui ont été validées. Mais cette approche, malgrès le fait qu elle permet d utiliser un minimum d espace, serait au détriment de la légèreté du programme, car elle demanderait plus de travail à la base de données (Jointures entre la table Intervention et la nouvelle table). Un ensemble de colonnes nécessaires pour faire une estimation de la qualité des données (voir la section suivante). Site ID INT Name NCHAR(3) Indexes Status ID INT Name NCHAR(50) Indexes Priority ID INT Name NCHAR(5) Indexes Intervention ID INT TTNr NCHAR(20) PriorityID INT StatusID INT SystemID INT SoftwareID INT SiteID INT ResponseTime DATETIME RepairTime DATETIME DateCreated DATETIME DateReceived DATETIME DateStarted DATETIME DateOnSite DATETIME DateFixed DATETIME DateClosed DATETIME DateReport DATETIME RespRemainingMinutes INT RepRemainingMinutes INT Indexes Software ID INT Name NCHAR(20) Indexes System ID INT Name NCHAR(20) Indexes Figure 4.5 La base de données existante. 4.3.5 Choix des dimensions pour la qualité de données Dans cette section, nous allons faire une sélection des dimensions qui ont été étudiées dans le chapitre précédent. Comme montré dans la Figure 4.5, les données dont nous désirons estimer la qualité sont de type DateTime 2. Pour parvenir à faire un bon choix, une bonne idée est de d abord expliquer quels sont les problèmes qui peuvent apparaître dans nos données. Ci-dessous une liste de ces problèmes accompagnés d explications est donnée : Valeurs nulles Comme cité plus haut, la table Intervention fonctionne par mise à jour (elle est mise à jour au fur et à mesure que les interventions changent d états). Du coup, il a été décidé (par le concepteur de la base de données) de permettre 2. Le type DateTime permet de stocker une date et une heure dans la plupart des systèmes de gestion de bases de données. 2012-08-20 12 :00 :00 est un exemple de DateTime dans SQL Server.

Chapitre 4 : Analyse du problème et solution proposée 29 Figure 4.6 Les colonnes ajoutée à la table Intervention. d avoir des valeurs NULL. Il en résulte que la valeur NULL peut avoir deux significations, une valeur manquante (oubli de la part du gestionnaire de l incident) ou une valeur qui n as pas encore été introduite. La Figure 4.7 illustre ce problème. Incohérence Un problème d incohérence peut apparaître lorsque les relations entre les différentes dates ne sont pas respectées. Ce type de problème est illustré à la Figure 4.8. On remarque que la relation de précédence entre DateStarted et DateOnSite n a pas été respectée. Valeurs non exactes Même lorsque les valeurs d un tuple sont cohérentes, cellesci peuvent être inexactes. En effet des valeurs comme 2000-01-01 00 :01 :00 ou encore 2011-01-01 00 :01 :00 ont déjà été détectées dans le système. Ce problème est illustré à 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 1 On site Valeur manquante Valeur pas encore entrée Figure 4.7 Exemple illustrant les deux significations de la valeur NULL. Les dimensions que nous allons utiliser afin d estimer la qualité des données sont donc : La stabilité dans le temps (non-volatilité) L idée est de ne pas tenir compte des

Chapitre 4 : Analyse du problème et solution proposée 30 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 incohé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 considérerons seulement les incidents résolus ou suspendus (un incident est mis en en suspension (horloge en pause) lorsque le client doit fournir des informations nécessaires pour la résolution de l incident). 1 UPDATE wsr. I n t e r v e n t i o n SET TimelyStable = 1 WHERE StatusID = 6 OR StatusID = 8 AND Processed = 0 Listing 4.1 La stabilité La complétude Notons que nous nous intéresserons ici au problème des valeurs manquantes. En effet, les valeurs qui ne sont pas encore entrées ne constituent pas vraiment un problème (il suffit de ne pas tenir compte des interventions qui sont en cours d exécution, grâce à la table Status). La métrique qui sera utilisé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 même un tuple non complet (au moins une valeur NULL) aura une valeur 0 pour la colonne Complete. La complétude sera globalement estimé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 TimelyStable = 1 3 AND DateCreated IS NOT NULL AND DateReceived IS NOT NULL 4 AND DateStarted IS NOT NULL AND DateOnSite IS NOT NULL 5 AND DateFixed IS NOT NULL AND DateClosed IS NOT NULL Listing 4.2 La complétude La cohérence La cohérence est calculée de manière directe en vérifiant que tous les états d une interventions se suivent dans l ordre chronologique. De la même façon que pour la complétude, nous utilisons une métrique de type {1, 0} et la cohérence totale est donnée par le rapport du nombre des tuples cohé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 Processed = 0

Chapitre 4 : Analyse du problème et solution proposée 31 3 AND RepairTime >= ResponseTime AND Processed = 0 AND TimelyStable = 1 4 AND DateReceivedCleaned < ResponseTime ; Listing 4.3 La cohérence L exactitude Cette dimension est également estimée de la même manière. Notons que des dates comme 2000-01-01 00 :01 :00 résultent d une mauvaise traduction de ces valeurs depuis le ticket reçu. Pour cela, nous avons décidé de paramétriser l insertion/suppression des dates non désirée. En effet, dans le futur, il pourrait exister d autres valeurs inexactes ou bien le problème à l origine de ces valeurs pourrait être éliminé. 1 UPDATE wsr. I n t e r v e n t i o n 2 SET Accurate = 1 WHERE TimelyStable = 1 3 // c e c i e s t f a i t pour t o u t e s l e s dates i n d e s i r a b l e s ( f l a g ) 4 AND DateStartedCleaned!= 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 même optique de solliciter le serveur de la base de données le moins possible, les dates indésirables (flag) sont stocker dans un fichier XML dont la structure est donnée ci-dessous. 1 <s e t t i n g s> 2 <flagtimes> 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 </ flagtimes> 6 </ s e t t i n g s> Listing 4.5 Stockage des dates indésirables dans un fichier XML 4.3.6 Nettoyage et validation de données Pour nettoyer et valider les données, deux approches peuvent être utilisées. La première approche que nous pourrions adopter est de traiter les données au fur et à mesure de leur arrivée dans la base de données (en temps réel), autrement dit en utilisant des déclencheurs 3 (triggers en Anglais). Une autre façon de faire, serait de traiter les données lors de l exécution du programme. C est cette approche là qui sera adoptée car elle a l avantage de ne pas surcharger le serveur de la base de données. Comme nous l avons déjà cité, la colonne Processed permet de marquer les données qui ont déjà été traitées afin d éviter de retraiter ces données à chaque lancement du programme. Par contre, lors de la mise à jours d une donnée qui a déjà été traitée, un retraitement devient nécessaire au prochain lancement du programme. En effet, nous 3. Dans les bases de données, un déclencheur permet de lancer automatiquement une procédure stockée lors de la mise à jour ou de la suppression d une donnée, qui agit en parallèle sur la même donnée dans une table afférente. Cela permet d automatiser certains traitements assurant la cohérence et l intégrité de la base de données.

Chapitre 4 : Analyse du problème et solution proposée 32 devons assigner la valeur 0 à Processed pour la donnée en question, ce qui doit être fait en utilisant un dé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( DateStarted ) OR UPDATE( DateOnSite ) OR UPDATE( DateFixed ) OR UPDATE( DateClosed ) OR UPDATE( DateReport ) ) 4 BEGIN 5 UPDATE wsr. I n t e r v e n t i o n 6 SET Processed = 0, TimelyStable = 0, Complete = 0, 7 C o n s i s t e n t = 0, Accurate = 0, Valid = 0, WasValid = 0, 8 DateReceivedCleaned = NULL, DateStartedCleaned = 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 Déclencheur de réinitialisation Nous avons donc un outil de nettoyage/validation qui est implémenté dans le programme de reporting ainsi qu un déclencher pour la base de données. Dans ce qui suit, nous allons tenter d expliquer le fonctionnement de cet outil. Détections des problèmes La première chose que l outil fait est détecter les trois types de problèmes discutés précédemment (les données incomplètes, les données incohérentes et les données inexactes). Nettoyage Notons que tous les problèmes détectés ne peuvent pas être corrigés. En effet, un problème dans les colonnes DateCreated et DateReceived ne peut pas être résolu. Pour les autres colonnes, DateStarted, DateOnSite, DateFixed, DateClosed et DateReport, la règle générale appliquée est celle d é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 Processed = 0 AND TimelyStable = 1 ; Listing 4.7 Nettoyage de données 1 1 UPDATE wsr. I n t e r v e n t i o n SET DateStartedCleaned = 2 (CASE

Chapitre 4 : Analyse du problème et solution proposée 33 3 WHEN ( DateReceivedCleaned IS NOT NULL AND ( DateStarted < DateReceivedCleaned OR DateStarted IS NULL) ) 4 THEN DateReceivedCleaned 5 ELSE DateStarted 6 END) 7 WHERE Processed = 0 AND TimelyStable = 1 ; Listing 4.8 Nettoyage de données 2 1 UPDATE wsr. I n t e r v e n t i o n SET DateOnSiteCleaned = 2 (CASE 3 WHEN ( DateOnSite < DateStartedCleaned OR ( DateOnSite IS NULL AND ResponseTime IS NOT NULL) ) 4 THEN ResponseTime 5 ELSE DateOnSite 6 END) 7 WHERE Processed = 0 AND TimelyStable = 1 ; Listing 4.9 Nettoyage de données 3 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) 7 WHERE Processed = 0 AND TimelyStable = 1 ; Listing 4.10 Nettoyage de données 4 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) 7 WHERE Processed = 0 AND TimelyStable = 1 ; Listing 4.11 Nettoyage de données 5 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) 7 WHERE Processed = 0 AND TimelyStable = 1 ; Listing 4.12 Nettoyage de données 6

Chapitre 4 : Analyse du problème et solution proposée 34 Validation La validation des données se fait directement en parcourant toutes les données qui ont été nettoyées et en vérifiant que celles-ci respectent toutes les dimensions de qualité de données définies plus haut. Donc, une entrée dans la table Intervention est valide si et seulement si elle est complète, cohérente, exacte et non volatile. 1 UPDATE wsr. I n t e r v e n t i o n SET Valid = 1 2 WHERE TimelyStable = 1 AND Complete = 1 3 AND C o n s i s t e n t = 1 AND Accurate = 1 AND Processed = 0 ; Listing 4.13 Validation de données 4.3.7 Analyse temporelle Le système de reporting sera donc un logiciel C# (framework.net) conçu lors de ce mémoire, se connectant à une base de données SQL Server. A chaque lancement du programme, les actions suivantes sont exécutées : Le programme analyse tous les tuples qui n ont jamais été traités (Processed = 0 ) et procède à la validations de ces derniers. Ensuite, toutes les données nécessaires sont collectées et la connexion avec la base de données est libérée. A cette étape, le programme est capable de générer le rapport (de base), faire une estimation de la qualité de données, générer un rapport inter-sites ainsi que générer le rapport sous format Excel. 4.4 Patrons de conception Les patrons de conception sont également un receuil de bonnes pratiques. Dans le cadre de ce mémoire nous avons introduit un patron de conception. Ce dernier est présenté 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 à une seule instance. Cela peut être réalisé en empêchant l accès au constructeur depuis l extérieur (constructeur privé) et en créant une méthode qui permet de renvoyer une nouvelle instance seulement lorsque il n y a actuellement aucune instance. Sinon, la méthode renverra une nouvelle instance. Ainsi, ce patron de conception est utilisé afin de garder une seule connexion à la base de données. Donc, le gestionnaire de la base de donné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

Chapitre 4 : Analyse du problème et solution proposée 35 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 return datamanager ; 14 } Listing 4.14 Le gestionnaire de la base de données (DataManager) 4.5 Conclusions Nous avons donc établi les infrastructures employées ainsi que les justifications de ces différents choix. Ainsi, nous avons opté pour C# comme langage d implémentation du logiciel. De plus, l analyse temporelle, la sélection des dimensions pour l estimation de la qualité de données et la structure de la base de données ont été présentées.

Chapitre 5 Résultats 5.1 Installation Le logiciel peut être facilement installé. Pour plus d informations, un guide installation détaillé est fourni en annexe. 5.2 Guide d utilisation La Figure 5.1 montre l interface principale du programme. Les trois premières sousfenêtres constituent le module de reporting de base. Les deux autres modules sont représentés par les deux sous-fenêtres suivantes. Une fois le programme lancé, l utilisateur est amené à choisir une pé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 générer les rapports. A ce stade, il est possible d exporter les données vers le format Microsoft Excel (bouton Export). Dans la partie supérieure de la fenêtre principale, quelques paramètres peuvent être ajustés : Track by Ce paramètre permet de catégoriser les interventions selon soit leur date de réception (DateReceived) soit leur date de réparation (DateFixed). Dans d autres mots, ce paramètre permet de fixer le point de référence des interventions. Dates to exclude Comme expliqué dans le chapitre précédent, des dates dues à une mauvaise traduction peuvent apparaître dans la base de données. Cette section permet de gérer ces dates. Set Db Permet d entrer l adresse de la base de données (MS SQL Server) à laquelle l utilisateur désire se connecter. L adresse de la base de données peut être entrée en cliquant sur le bouton setdb. Voir Figure 5.2. 36

Chapitre 5 : Résultats 37 Figure 5.1 La fenêtre principale du programme. Figure 5.2 L adresse de la base de données. La sous-fenêtre qui constitue le module qualité de données (Figure 5.3) comporte trois régions : La région Overview montre les estimations des dimensions de la qualité de données discutées dans le chapitre précédent. La région Valid and invalid data montre les interventions qui ne sont pas valides ainsi que les interventions qui sont devenues valides après leur traitement. La région Cleaned data per month permet de visualiser ces données dans un graphique dont l axe des abscisse contient les mois de l année choisie. Une fois que le point de référence des interventions a été choisi, il est important de montrer à l utilisateur les interventions qui débordent, c est-à-dire les interventions qui débutent dans une semaine (quand il s agit d un rapport hebdomadaire) et qui terminent dans une autre semaine ultérieure, de même pour les rapports mensuels. En effet, aucune règle à appliquer n a été définie pour ce type d incidents. Lorsque de telles interventions existent, le bouton Overflowing incidents devient actif et permet de voir les détails de ces interventions. La figure 5.4 montre un exemple d interventions qui sont reçus le 31 Août 2011 et qui sont résolus le premier Septembre 2011.

Chapitre 5 : Résultats 38 Figure 5.3 Le module qualité des donné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 Après ces descriptions, nous pouvons donc voir que le logiciel répond le logiciel est pleinement utilisable et permet de générer des rapports qui répondent bien à tous les critères et contraintes mais dispose également d un outil de nettoyage de données. Cet outil est donc un produit abouti et fonctionnel.

Chapitre 5 : Résultats 39 Figure 5.4 Les incidents débordants. Figure 5.5 Le rapport mensuel.

Chapitre 5 : Résultats 40 Figure 5.6 Le rapport hebdomadaire. Figure 5.7 Le rapport annuel.

Chapitre 6 Conclusions N ayant pas accès à la base de données des incidents, nous n avions pas la possibilité d établir nos statistiques et donc de confirmer ou d infirmer le rapport produit par les clients. En plus, rien ne pouvait être fait concernant les éventuelles erreurs se trouvant dans ces rapports et donc aucune contestation ne pouvait avoir lieu concernant les pénalités infligées. Le développement du logiciel a donc permis aux gestionnaires d incident de pouvoir constamment monitorer le niveau de leurs services. De plus, grâce aux rapports générés par le logiciel, il devient possible de comparer les résultats obtenus avec ceux présentés par les clients. Du coup, les rapports constituent un moyen de protection. Finalement, nous pouvons donc dire que le développement du logiciel est un succès car il correspond à toutes les attentes et satisfait toutes les contraintes. De plus, l estimation de la qualité de données permet d avoir un regard critique sur les résultats. Ce mémoire m a donc permis de comprendre l intérêt d utiliser ITIL ainsi que de connaître ses bases, d aborder des sujets sur la qualité de données qui est un domaine vaste (des milliers de recherches ont été effectuées) et complexe. Techniquement, j ai eu l occasion à travers ce mémoire de dé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 ré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 à 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. Herná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. Herná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 Publishers In, 2003. [20] Leo L. Pipino, Yang W. Lee, and Richard Y. Wang. Data quality assessment. Communications 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 Proceedings 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 cleaning. 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] Wikipédia. Distance de levenshtein wikipédia, l encyclopédie libre. http://fr. wikipedia.org/wiki/distance_de_levenshtein, 2012. [En ligne ; Page disponible le 01-Août-2012]. [28] Wikipédia. Drame du heysel wikipédia, l encyclopé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] Wikipédia. Exploration de données wikipédia, l encyclopédie libre. http:// fr.wikipedia.org/wiki/exploration_de_donn%c3%a9es, 2012. [En ligne ; Page disponible le 06-Août-2012]. [30] Wikipédia. Herald of free enterprise wikipédia, l encyclopé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 instructions. 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 Figure A.2 Installation - 2. Figure A.3 Installation - 3.

Chapitre A : Guide d installation 46 Figure A.4 Installation - 4. Figure A.5 Installation - 5.

Chapitre A : Guide d installation 47 Figure A.6 Installation - 6.

Annexe B Exemple de rapport généré Figure B.1 SLA s Figure B.2 MTD 48

Chapitre B : Exemple de rapport généré 49 Figure B.3 WTD Figure B.4 YTD