Mettre en place une administration de données

15 février 2002

On appelle « administration des données » la fonction de ceux qui, dans une entreprise, sont chargés de veiller à la qualité sémantique du système d’information (SI) : absence de synonymes et d’homonymes ; entretien de la cohérence des codages ; accessibilité et clarté de la documentation, etc.

Les spécialistes connaissent l’importance de l’administration des données pour la qualité du SI. Pourtant il est difficile de la mettre en place. Elle nécessite un « travail de bénédictin » assidu et austère et il n’est pas aisé de trouver des volontaires pour le réaliser. Il est d’ailleurs délicat de doser l’effort : comme il n’existe pas de limite logique au détail de la documentation des données, seul le bon sens permet de s’arrêter lorsque l’on a atteint une précision raisonnable. S’agissant enfin d’une tâche fondamentale pour l’architecture mais dont les effets se font sentir à terme, il est pratiquement impossible d’évaluer sa rentabilité ; elle sera donc souvent classée au second rang des urgences, parmi ces travaux auxquels on pense toujours et que l’on ne réalise jamais.

D’ailleurs l’administration des données a des adversaires. Ceux qui n’aiment pas « les vagues » s’en méfient car elle risque de poser dans l’entreprise des problèmes « politiques ». Ceux qui pensent que, tout étant relié avec tout,  il ne convient pas d’établir dans la pensée des classifications aux contours nets, se défient d’un travail « intellectuel » qui vise à introduire de l’ordre parmi les concepts.

Le but de la présente fiche est de proposer une formulation des règles concernant l’administration des données ainsi qu'un programme de travail visant à les mettre en œuvre.

Qu’est-ce que l'administration des données ?

Une donnée, c'est le couple logique formé par une définition (sémantique) et une mesure, la mesure étant caractérisée par le type de la donnée (booléen, entier, réel, qualitatif, textuel etc.), la périodicité, le délai de mise à jour. A ce couple doit être associée l'identité de la personne morale [1] (« propriétaire de la donnée ») qui est habilitée à mettre la donnée à jour et à faire évoluer si nécessaire sa définition. 

La donnée se transforme en information lorsqu’elle est communiquée à un être humain capable de l’interpréter, un peu comme une gouttelette d’eau en surfusion se transforme en givre au contact d’une surface solide. Le mot « donnée » est donc un faux ami : la donnée résultant à la fois d’une abstraction, choix qui distingue ce qui sera observé de ce qui ne le sera pas, et d’une mesure, sa définition et son observation sont toutes deux produites par l'être humain et non « données » par la nature. Ceci n’enlève d’ailleurs rien à son objectivité [2].

Les définitions sont contenues dans des référentiels (cf. ci-dessous). L’administrateur des données est la personne morale garante de la qualité des référentiels et de leur bonne utilisation, ainsi que des informations concernant la mesure et l’identité du propriétaire de chaque donnée.

Cette fonction situe l'administrateur de données près des pouvoirs de décision ; en effet, lors de la construction d'une nomenclature et surtout lors de l'identification du propriétaire d'une donnée se règlent des questions de frontière entre entités de l'entreprise. Dans certaines entreprises, notamment les banques, le rôle de l'administrateur de données est si délicat que l'on a jugé bon de le rattacher au président ou au directeur général.

Référentiel du SI

Par « référentiel » du SI d'une entreprise, on entend :

- l'ensemble des règles, documents et bases de données concernant les identifiants et nomenclatures [3] utilisés par le SI,

- les règles de conception et d'administration du partage de ces références par les diverses composantes du SI.

Expliquons ce que nous entendons par « identifiant » et « nomenclature ».

On peut décrire l’entreprise comme un ensemble de « domaines » relatifs chacun à la production d’une valeur ajoutée spécifique ; les tâches réalisées dans ces domaines constituent des « processus » productifs. Ces processus articulent des « activités » réalisées par des êtres humains qu’assistent des automates et qu’outillent des machines (cf. Urbaniser un SI).

Tout processus concerne un ensemble (ou « population », que l'on nomme aussi « entité » mais je n'aime pas ce mot aux implications philosophiques trop vagues) d'êtres que l'on peut appeler « individus » (on dit aussi « instances », mais je n'aime pas ce mot) en prenant ce terme dans un sens large : les clients, commandes, factures, produits, personnes de l'entreprise, partenaires et entités de l'organisation sont ainsi des « individus » formant des « populations » [4]. 

Pour construire le SI d'une entreprise on part de la définition de ces diverses populations. Le « référentiel » de l'entreprise sera le support de cette définition (quand on dit « le référentiel » tout court, c'est pour désigner l'ensemble des référentiels de l'entreprise ; ainsi l'annuaire d'entreprise est un référentiel particulier, le référentiel des personnes).

Le référentiel prend deux formes : une forme documentaire (papier ou électronique) pour les utilisateurs humains ; une forme physique (base de données) pour l’utilisation automatique dans le cadre des traitements informatiques. Il constitue le socle sur lequel le SI est bâti. Nous allons chemin faisant évoquer de « mauvaises pratiques » qui montrent à quoi s’expose l’entreprise  si le référentiel est de mauvaise qualité.

La première indication que donne le référentiel, c'est la liste des populations et leur définition.

Puis il faut identifier les individus qui composent chaque population. L'identifiant, clé associée à un individu, permet de retrouver les données le concernant aux diverses étapes de son cycle de vie.

A chaque individu sont associées des données (on dit aussi « attributs ») observées et mises à jour périodiquement ou en continu. A chaque donnée est associée un type logique : une donnée peut être quantitative (revenu, poids etc.), qualitative (métier, commune de résidence etc.), qualitative ordinale (nombre d'enfants d'un ménage, classe d'âge d'une personne, tranche d'imposition), textuelle (commentaire) ; ce peut être une image (photographie de la personne), une date, une adresse postale ou électronique, un nom propre, etc. [5]

La mesure d'une donnée quantitative est un nombre (de type entier, rationnel ou réel). La mesure d'une donnée qualitative est un codage caractérisant l'affectation (classement) d'un individu à une classe d'une nomenclature [6].

Pour définir la mesure d'une variable quantitative il suffit de préciser son type et, éventuellement, les bornes des valeurs qu'elle peut prendre. Par contre, pour définir la mesure d'une variable qualitative, il faut fournir une nomenclature.

Une nomenclature est une partition de la population sans omission ni double emploi. A chaque classe de la partition est associé un code. La nomenclature peut comporter plusieurs niveaux (ainsi le code géographique contient les niveaux îlot, commune, canton, département, région) emboîtés les uns dans les autres (une classe appartient à une et une seule classe de niveau supérieur).

Règles concernant les identifiants

Pour comprendre les règles concernant les identifiants, parcourons la liste des erreurs à éviter.

Beaucoup d'entreprises attribuent à leurs clients des identifiants qui identifient non le client, mais un équipement caractérisant le service rendu à celui-ci : ainsi un opérateur télécoms identifie non le client lui-même, mais la ligne téléphonique (à laquelle le nom et l'adresse du client seront attachés comme des attributs) ; une banque identifie non le client, mais le compte (c'est le cas du RIB). Ces procédés interdisent ou rendent difficile le rassemblement des données concernant un même client. Ils trahissent la priorité de ces entreprises : elles s'intéressent plus à leur organisation interne qu'au client et à ses besoins. La priorité donnée à l'organisation interne, à l'organigramme et aux principes de management, empêche ces entreprises de considérer en priorité leur marché, la satisfaction de leurs clients, ou encore l'état de l'art de leur métier et les bonnes pratiques des concurrents. L’examen des identifiants révèle des priorités de facto, souvent bien différentes de celles que l’entreprise prétend ou souhaiterait avoir.

Il arrive aussi que l'on confonde identifiant et attribut en introduisant dans l'identifiant des éléments porteurs d'information. Si l'on introduit par exemple un élément géographique dans l'identifiant d'un client (numéro du département etc.), on devra changer l'identifiant lorsque le client déménagera, ce qui rend difficile le suivi historique de son dossier. L'INSEE, avant la mise en place du fichier SIRENE, identifiait les établissements avec un code comportant l'indication de l'activité principale et de la commune ; il fallait changer l'identifiant d'un établissement lorsque son activité principale changeait.

Il arrive enfin que l'on réutilise pour un nouvel individu l'identifiant d'un autre individu arrivé en fin de cycle de vie. Ainsi l’ANPE a réutilisé, pour identifier ses agences, les identifiants d'agences supprimées. Cela oblige, lors de l'examen de l'historique des données concernant un individu, à vérifier s'il s'agit continûment du même individu.

Cette courte liste d'errements montre l'importance des règles suivantes :

-          définir correctement la population dont il s'agit d'identifier les individus : il ne faut pas confondre le client avec le service qui lui est rendu, avec le produit qui lui est fourni, ni avec le contrat que l'on a passé avec lui ;

-          construire des identifiants pérennes : ils resteront affectés à l'individu pendant tout son cycle de vie ;

-          ne pas confondre le rôle de l'identifiant et le rôle des attributs : l'identifiant ne doit être porteur d'aucune information ;

-          s'interdire de réutiliser un identifiant après la fin du cycle de vie de l'individu.

D'un point de vue technique, il résulte de ces règles que la meilleure façon de construire un identifiant est de choisir une suite de caractères tirée au hasard (le plus souvent des chiffres décimaux), dépourvue de toute signification (ce qui exclut de coder en utilisant des nombres successifs car le code prendrait alors une signification ordinale) et en vérifiant que cette suite n'a pas déjà été utilisée. Elle doit contenir assez de caractères pour qu'il soit possible d'identifier la population concernée, en tenant compte des cohortes successives qui la renouvelleront pendant le cycle de vie du SI (c'est à dire pendant quelques dizaines d'années). Il est utile enfin de lui associer une clé de contrôle qui permettra de contrôler l'exactitude de l'identifiant.

Règles concernant les nomenclatures

La qualité d'une nomenclature se juge:

-          sur le plan formel, selon l'exactitude du découpage de la population qu'elle fournit : il faut qu'elle constitue une suite emboîtées de partitions, sans omission ni double emploi ;

-          sur le plan fonctionnel (ou sémantique), selon la pertinence du découpage : il faut que les classes regroupent les individus en fonction de la similitude des actions que l'entreprise entend conduire envers eux ;

-          sur le plan pratique, selon la clarté de la documentation qui l'accompagne : une nomenclature non commentée, même si elle est pertinente, sera souvent mal interprétée par ceux qui l'utilisent et ils commettront des contresens ;

-          sur le plan technique :

o       par la clarté du code utilisé pour identifier les classes de la nomenclature (on utilisera souvent pour désigner un niveau de la nomenclature le nombre de chiffres que contient un code numérique),

o       par les procédures introduites dans les systèmes de saisie ou dans les interfaces pour vérifier la qualité du codage,

o       par la disponibilité des tables de passage (transcodages) assurant la traduction d'une nomenclature dans une autre lorsque cela s'impose (par exemple pour échanger des données avec un partenaire)..

 

Le codage est utilisé dans le SI à deux fins distinctes :

-          il peut déterminer le traitement du dossier de l'individu dans la procédure opérationnelle (en qualifiant une demande d'emploi par un métier; en classant un contribuable dans une tranche d'imposition etc.) ;

-          il sert à produire des statistiques sur la population étudiée, chaque individu étant compté dans la classe à laquelle le codage l'affecte.

Les nomenclatures utilisées en pratique peuvent présenter des défauts : si une partie du domaine visé n'est pas couverte par la codification, il y a omission ; si une même partie du domaine peut être classée de deux façons différentes, il y a double emploi (cela peut se produire si les libellés des postes de la nomenclature sont ambigus) ; si le découpage ne correspond pas à l'action que le SI est chargé d'outiller, la nomenclature n'est pas pertinente ; si le code est mal défini, il peut provoquer des erreurs etc.

Lorsque deux entreprises entendent faire communiquer leurs SI, elles doivent établir des tables de passage entre leurs nomenclatures. Tout est simple si l'on peut établir une bijection entre classes, la table de passage se ramenant alors à une simple traduction entre terminologies. Mais le plus souvent il sera impossible d'établir cette bijection car la correspondance se fait entre parties de classes. Dans ce cas la table de passage ne peut être qu'approximative. Il peut en résulter dans le traitement des dossiers individuels une incertitude telle, ou de telles impossibilités, que l'on se sentira obligé de réformer les nomenclatures, tâche lourde et contrariante. Ainsi la vérification de l'adéquation des nomenclatures est le préalable obligé de tout partenariat ou de toute coopération commerciale lorsque le projet implique, comme c’est le cas de plus en plus souvent, de faire coopérer les SI.

Évidemment les nomenclatures évoluent : pour rester pertinentes elles doivent pouvoir refléter des priorités changeantes. Cela pose plusieurs problèmes :

-          pour assurer la continuité sémantique de la description, le suivi historique des populations devra régler des questions de transcodage entre versions successives de la nomenclature. Souvent cette tâche est en toute rigueur impossible et l'on ne peut obtenir qu'une approximation ;

-          il importe, lorsqu'une nomenclature est changée, que ce changement soit répercuté immédiatement dans les composantes du SI qui l'utilisent ; c'est la question de la gestion des données de référence sur laquelle nous reviendrons plus loin.

On préfère parfois, pour éviter des à-coups qui rendraient le SI instable, prolonger la durée de vie d'une nomenclature un peu au delà de ce qui serait convenable en termes de pure pertinence.

Règles concernant le partage des références

Les nomenclatures sont utilisées par diverses composantes du SI (que l'on nomme souvent « applications »), et elles évoluent dans le temps même si l'on cherche à les stabiliser (le découpage géographique varie selon l'évolution du marché ; la nomenclature des produits doit être modifiée quand l'entreprise développe un nouveau produit etc.)

Il importe que les tables de codage utilisées par les diverses composantes du SI soient mises à jour sans délai : sinon, on risque des erreurs dans l'interprétation des données transmises d'une composante à l'autre, et on risque aussi de produire des statistiques dont l'interprétation sera impossible ou fallacieuse.

La synchronisation des tables de codage ne peut être obtenue que si elles sont asservies à une table mère dite « table de référence ». Il faut que dans la composante qui utilise une table de codage figure le dispositif permettant d'assurer en continu l'identité entre la table locale et la table de référence : soit cette dernière sera consultée au coup par coup ; soit elle sera répliquée sans délai perceptible dans toutes les composantes qui l'utilisent.

Une erreur fréquente est de « faire comme si » la mise à jour allait de soi et de recetter des composantes contenant une version de la table de référence, mais non les procédures qui permettront de la tenir à jour. Tout se passe bien lors de la recette (puisque la version utilisée est récente) et l'erreur reste inaperçue. C'est dans l'exploitation, de façon sournoise, que l'écart se creusera progressivement entre les tables, et que la qualité des données se détériorera.

Il revient à la direction de l’informatique d'énoncer les règles relatives à l'utilisation des tables de référence et de veiller à leur application lors des recettes techniques.