RECHERCHE :
Bienvenue sur le site de Michel VOLLE
Powered by picosearch  


Vous êtes libre de copier, distribuer et/ou modifier les documents de ce site, à la seule condition de citer la source.
 GNU Free Documentation License.


Comment concevoir un référentiel

15 juillet 2001

Version imprimable

Pour poster un commentaire


Pour lire un peu plus :

-
Mettre en place une administration des données
-
Éloge du semi désordre

Qu'est-ce qu'un "référentiel" ?

Un référentiel, c'est un ensemble de bases de données contenant les "références" d'un système d'information. Ces références sont de deux types. Soit il s'agit d'informations dont les applications ont besoin pour fonctionner, mais qui, étant parfois mises à jour, sont stockées dans une base de donnée spéciale, les "données de référence", où les applications peuvent les retrouver chaque fois qu'elles en ont besoin ; c'est le cas pour les annuaires (de l'organisation, des personnes, des équipements etc.), les nomenclatures, etc. 

Soit il s'agit d'informations qui seront utilisées lorsque l'on doit faire évoluer une application : on parle alors d' "administration des données" ; ce sont des définitions, et aussi des indications sur le format de la donnée ("typage"), les conditions de sa mise à jour, son "propriétaire" (personne ou entité habilitée à la mettre à jour).

On comprend que le référentiel, c'est la colonne vertébrale d'un système d'information. Les règles auxquelles obéissent sa construction et sa gestion sont purement logiques, donc finalement assez simples. Nous allons toutefois montrer que leur application pose quelques problèmes.

Où est l'erreur ?

Un de mes clients a voulu appliquer des préceptes rigoureux pour construire son système d'information. Il a donc tenté de le fonder sur un référentiel. Il a identifié les domaines d'action de son entreprise, dans chaque domaine les processus opérationnels de création de valeur ajoutée, dans chaque processus les "acteurs" ainsi que les "populations" d'entités (clients, produits, fournisseurs, documents etc.) que les acteurs doivent considérer, pour chacune de ces populations les "classes" ou "composants" qui les décrivent, les "attributs" (identifiants, variables) et les "règles de gestion" de ces composants, les "interfaces" qui leur permettent de communiquer, les "cas d'utilisation" de chaque acteur, le "cycle de vie" de chaque composant, les données de référence, etc.

Ayant identifié cinq domaines, il a lancé la conception de cinq référentiels (plus, bien sûr, la description des relations entre ces référentiels). Au bout d'un an, il se trouve avec cinq référentiels en chantier, un quart de chacun étant réalisé ; s'il extrapole, il en a encore pour trois ans et comme le système d'information de l'entreprise ne peut pas attendre, on le construit sans disposer du référentiel complet.

"Où est l'erreur ?" demande-t-il. 

Me rappelant quelques expériences cuisantes, je lui dis que sans doute il n'a pas choisi au départ le "grain de photo" de son référentiel, le degré de détail à retenir, et qu'il s'est laissé piéger par le goût de la précision. Il est alors comme quelqu'un qui, ayant à nettoyer le carrelage d'une pièce, se serait acharné à récurer quelques carreaux ; ces carreaux sont très propres, mais les autres sont restés sales et l'ensemble a un drôle d'aspect.

Le problème, répond-il, c'est que si nous choisissons maintenant le "grain de la photo" (autrement dit le degré de propreté souhaitable pour le carrelage), nous devrons jeter une partie du travail réalisé car il serait trop détaillé.

Eh oui, lui dis-je, c'est la dure loi du choix stratégique : il oblige parfois à jeter le résultat d'efforts antérieurs coûteux.

Quel grain pour la photo ?

Nous en sommes restés là mais ma réponse ne me satisfaisait pas entièrement. Comment définir le "grain de la photo", le niveau de détail souhaitable pour un référentiel ? Toute nomenclature est une suite de partitions emboîtées définies sur un domaine conceptuel ; on peut toujours la détailler en ajoutant un niveau : il n'existe aucune critère formel permettant de définir le degré de détail auquel il convient de s'arrêter. 

En pratique, on s'arrête quand on est las de formaliser les choses. Le niveau de détail utile n'apparaît que plus tard, lorsqu'on utilise le référentiel. Alors ce qui est trop détaillé reste inutilisé, et les endroits où le détail manque font l'objet de réclamations. Tout au plus peut-on, en guise de critère, anticiper ces réactions. 

Revenons au point de départ de la démarche, tentons de nous la représenter de façon simple. Ce que l'on cherche à faire lorsqu'on se lance dans la réalisation d'un référentiel, c'est mettre de l'ordre, introduire de la clarté, de la cohérence dans le système d'information. On est comme un étudiant qui range sa chambre : il fait le lit, met les pull-overs dans des tiroirs, les livres sur des étagères, les feuilles de cours dans des classeurs, etc. Quand l'ordre lui semble suffisant, il s'arrête. Un ordre suffisant, ce n'est pas l'ordre parfait. Il se peut que l'étudiant n'ait pas classé les livres sur l'étagère par nom d'auteur, ou par matière, et que son lit ne soit pas exactement "au carré". Qu'importe, si l'ordre même imparfait lui procure cette clarté dans les idées qui aide à définir les choses à faire en priorité.

Limiter les frais

Faisons de même lorsque nous construisons un référentiel. Évitons de "récurer quelques carreaux quand il faut nettoyer le carrelage". Adoptons, comme "l'étudiant qui range sa chambre", une démarche qui couvrira tout, selon le détail répondant à l'effort que nous consentons. Puisqu'il est impossible de définir rigoureusement le degré de détail pertinent, fixons nous une contrainte : un référentiel couvrant tout le domaine sera produit à l'issue de tel délai ou après avoir dépensé tel budget. Si par la suite, à l'usage, il se révèle que nous aurions dû en détailler davantage une partie, alors nous aviserons.  

Mieux vaut un référentiel grossier couvrant l'ensemble du système d'information qu'un référentiel détaillé mais incomplet. Il ne faut pas s'efforcer à déterminer rigoureusement le niveau de détail "optimal", puisque c'est impossible. Comme l'on est toujours tenté d'en faire trop plutôt que pas assez, équilibrons cette tentation en nous imposant des contraintes sévères selon le principe de sobriété du système d'information. Pour construire le référentiel d'une entreprise de service faisant quelques dizaines de milliards de chiffre d'affaires, il sera raisonnable de se limiter à un délai de l'ordre de six mois et à un budget de l'ordre de 5 MF. Entre autres conséquences, cela obligera à choisir rapidement l'outil pour mettre en forme et stocker le référentiel (au lieu de passer des mois à chercher le meilleur outil). Si le référentiel se révèle trop peu détaillé à l'usage, il faudra envisager d'en établir une version enrichie.