Pourquoi l'Administration de données

Introduction

Je ne suis pas un adepte de tout ce qui est purement théorique. Cela a toujours été facile pour moi quant j’ai des exemples concrets, des illustrations, bref n’importe qui me permet de faire un schème du percepts à apprendre. Je préfère faire les mixes entre les percepts théoriques et les exemples pratiques. Je préfère aussi savoir le pourquoi de la chose, il est facile de bombarder le lecteur avec une panoplie de définitions, mais à mon avis, il serait plus pertinent de commencer par définir la problématique à la quelle l’administration de données avant de définir cette dernière.

Commençons donc par la problématique ou les problématiques qui ont amené à l’apparition de l’administration de données.

Plus d’applications, plus de confusion !
Pour mieux saisir la problématique, revenons au le travail de Nolan et Gibson sur l’évolution des SI/TI en fonction des dépenses. Le résultat du travail est le modèle présenté dans le tableau 1. Certes ce modèle date de 1979, cependant il a le mérite de mettre en évidence la croissance des systèmes d’information dans une organisation. Ce qui nous intéresse le plus dans ce travail n’est pas les dépenses, mais plutôt les étapes de transformation des systèmes d’information dans l’organisation.

L’explication de chacune de ces étapes est la suivante :
1 – Démarrage (Initiation) : Les applications réalisées dans cette étape répondent le plus à un besoin d’automatisation de processus d’affaire et de traitement en lot dont le but est de réduire les coûts. L’emphase est mise sur les systèmes opérationnels et on ne note en général aucun intérêt des gestionnaires. Dans cette étape on parle de traitement de données et non pas de système d’information.

2 – La contagion : La demande des utilisateurs devient de plus en plus accrue. Satisfaits, cela aboutit à une multitude d’applications de traitement de données et des gros budgets. Lors de cette étape le contrôle n’existe presque pas. Chaque service/ département ou entité organisationnelle développe ses propres applications de traitement de données sans se préoccuper de savoir s’il en existe d’autres ailleurs dans l’organisation qui peuvent répondre au même besoin ou du moins gèrent les mêmes données. Le résultat est qu’on se retrouve avec une multitude d’applications de traitement de données codées pour des besoins spécifiques qui gèrent probablement la même information sous différents noms, représentations… L’exemple le plus concret est le fichier ou la table des clients de l’entreprise, une problématique commune à tous les entrepôts de données, il existe autant de versions d’un client qu’il existe d’applications dans la compagnie. Dans cette phase on parle toujours de traitement de données

3 – Contrôle : Les gestionnaires commencent à se poser des questions sur le Retour Sur Investissement applications de traitements de données. Pour y répondre on commence à produire des plans de projets et à mettre en place des méthodologies et standards. Bien sûr cela se fait toujours d’une façon isolée sans aucune vision d’intégration. Les utilisateurs sont alors insatisfaits de la bureaucratie qui touche les applications.

On continue toujours de parler de Traitement de données.

4 – Intégration : L’intégration vient donc répondre à ce besoin de profiter au maximum des applications de l’organisation, ce qui engendre encore des grosses dépenses ( Mise en place des bases de données). Les utilisateurs deviennent dépendants des applications de traitement de données, qui en plus de résoudre les problèmes commencent à leur fournir des services en information. C’est dans cette phase que l’on commence à ce stade de parler de SI.

5 – Administration de données : En plus répondre aux besoins de traitement de données, les applications répondent à des besoins en information qui devient partagée au sein de l’organisation. Les capacités des bases de données sont alors mieux exploitées et les utilisateurs commence à découvrir la valeur de l’information.

6 – La maturité : Je ne crois pas que le terme maturité convient exactement à ce stade. Il est pour dire que la planification et le développement des SI/TI commencent à rentrer dans un cadre d’affaires plus précis ! Ce qui veut dire un alignement entre les SI/TI et les affaires de l’entreprise.

Les experts reproche plusieurs faiblesses à ce modèle : Trop simple et trop simpliste, ne représente pas la réalité… Cependant il est encore souvent utilisé justement pour sa simplicité.

Il faut bien avouer qu’il y’a encore des entreprises dont les systèmes d’information se trouvent encore au stade du contrôle. Ce genre d’entreprise rencontrent les problèmes suivants que seule une bonne administration de données peut résoudre (http://www.ieti.fr/add_accueil.htm):

1. La règle a toujours été, et malheureusement continue encore : chaque service/ département ou entité organisationnelle développe ses propres applications sans se préoccuper à savoir s’il existe d’autres applications ailleurs dans l’organisation qui peuvent répondre au même besoin ou du moins gèrent les mêmes données. Le résultat est qu’on se retrouve avec une multitude d’application codées pour des besoins spécifiques qui gèrent probablement la même information sous différents noms, représentations… L’exemple le plus concret est le fichier ou la table des clients de l’entreprise, un problématique commun à tous les entrepôts de données, il existe autant de version d’un client qu’il existe d’application dans la compagnie.
2. Les divers systèmes d’information de l’organisme doivent communiquer entre eux : système d’information de gestion, système d’information du patrimoine, système d’information géographique… La mise en œuvre d’interfaces logicielles ne résout pas les problèmes.
3. Les bases de données sont parfois difficilement exploitables par d’autres personnes que leurs créateurs ou utilisateurs réguliers en raison des carences de définition des informations.
4. La qualité des données est difficile à évaluer ce qui empêche leur communication à des partenaires ou organismes tiers.


L’ADD rapporte des solutions plus sérieuses à toutes ces problématiques. Mais qu’est ce que l’Administration de données ?

Qu'est ce que l'administration de données ?

L’administration de données

Michel Volle (http://www.volle.com/travaux/add.htm) définit l’administration de données comme étant la fonction de ceux qui sont chargés de veiller à la qualité « sémantique » des données du système d’information (SI). Cette définition a le mérite de mettre en évidence d’une part le caractère sémantique de la donnée et d’autre part le fait que l’administration de données a trait à ce caractère et non à la valeur de la données. Ce qui nous ramène à la définition suivante
« L’administration de données est l’ensemble de tâches permettant de collecter, stocker et mettre à jour les informations métiers de l’organisation en terme de définitions de données (Sémantique), les règles de gestion, les procédures et standards de nomenclature.

Ainsi l’administration de données concerne :

1. la documentation des données (schémas conceptuels, nomenclatures, dictionnaires, catalogues et référentiel), qu’il s’agit de collecter, constituer, maintenir, diffuser et quand c’est possible mettre en cohérence ;
2. la qualification des données : l’administration des données ne concerne pas les tâches d’acquisition ou de mise à jour des données (sauf éventuellement pour la mise au point de procédures ou de la définition de règles de gestion), mais s’intéresse au contrôle qualité des données ;
3. la diffusion des données : l’administration des données doit participer à la définition d’une politique de diffusion des données, proposer des règles et vérifier leur application.
4. les procédures et standards : l’administration des données doit aussi définir les procédures à suivre lors du développement ou de mise à jour d’applications. Aussi doit-elle mettre en place des standards de nomenclatures, de présentation et voire même d’ergonomie.