|
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.
|
