|
Une
évolution parfois difficile à mettre
en œuvre...
Las,
la plupart des bases de données
métier ont été conçues
par des spécialistes pour des
spécialistes d'un sujet donné. En
devenant des instruments de communication à
destination du public, elles doivent subir des
adaptations. Par exemple, un simple catalogue de
produits doit changer de présentation
lorsqu'il cesse de n'être qu'un outil
à usage de commerciaux en tournée
pour devenir un vecteur d'attraction de
clientèle via le Net.
De
plus, l'entretien de ces bases dans le temps n'a
pas toujours été parfaitement suivi.
Aussi les difficultés rencontrées
pour en faire des bases "publiables" sont
nombreuses. Citons, notamment:
- Des
bases "malpropres" : il arrive qu'une base
ait été conçue "au large",
puis ses gestionnaires se soient aperçu
qu'une seule partie des données leur
était effectivement utile. Dans ce cas,
une partie de la base a été mal
entretenue. Cela implique, avant publication,
une remise à niveau de la base parfois
très coûteuse (coût de
détermination, d'acquisition et de saisie
des données manquantes)
- Des
bases dans lesquels des champs utiles pour
le grand public manquent : Ainsi, une
base recense les communes ou l'on trouve
certaines espèces
protégées, mais la région
n'est pas mentionnée: cela oblige
à programmer des croisements avec des
tables de correspondance "commune
région", pour peu qu'on en
dispose...
- Une
indexation des enregistrements de la base
ne correspondant pas aux principaux
"cheminements intellectuels" des internautes
pour parvenir à l'information (cf. cet
article de veblog, "Organiser
l'info dans les sites
volumineux")
- Une
indexation des informations trop
détaillée, à partir de
thesaurus dont une partie des termes sont
incompréhensibles du commun des
mortels.
- La
désignation de certains champs par des
codes connus de l'entreprise mais
indéchiffrables par des
tiers.
De
plus, deux ou plusieurs bases qui auraient
intérêt à être
croisées ne peuvent l'être, à
cause des difficultés suivantes:
Par
exemple, imaginons qu'un ministère dispose
d'un côté d'une base de données
des sols pollués, de l'autre d'une base des
friches industrielles, et en prime d'un inventaire
des accidents industriels. Il serait certainement
bénéfique pour l'internaute de
pouvoir, via une seule interface de consultation,
consulter les zones concernées pour sa
commune et les alentours pour chacun de ces sujets.
Las, il risque de devoir accéder à
trois parties du site pour accéder à
ces données et ce sans pouvoir croiser les
résultats de ses consultation. Pourquoi
?
- Tout
d'abord, ces bases risquent d'être
gérées par des services
différents.
- De
plus, le champ commun qui permettrait de croiser
les données (la commune, avec une table
de correspondance
département-région-pays) ne sera
pas codé de la même façon
d'une base à l'autre.
- Enfin,
chaque base obéira à des standards
techniques particuliers pas touours
interopérables.
Dans
le cas de bases mises en œuvre
séparément par des entités
géographiques différentes mais
relatives à un même sujet, les
problèmes suivants sont à
attendre:
- Référentiels
variables: corpus de données
différents d'une entité à
l'autre, avec recouvrement partiel mais pas
total, unités de bases différentes
(par exemples échelles de
représentation dans le cas d'informations
géographiques), etc...
- Représentation
des données (textuelle, ou
graphique), différente d'une
entité à l'autre, légendes
non compatibles.
- Et
bien sûr, dans le pire des cas,
standards techniques différents et
difficilement interopérables.
On
le voit, les difficultés à surmonter
pour rendre diffusable une base de données
"métier" peuvent être importantes et
entraîner des coûts de remise à
niveau élevés. Voilà pourquoi
il convient, lorsqu'on crée une nouvelle
base, de prendre des précautions pour
qu'elle soit facile à convertir au web, le
cas échéant.
Concevoir
en amont des bases "web-compatibles"
Si
vous avez défini pour les informations de
votre site des axes d'indexation avec des
référentiels associés (cf.
"organiser
l'info des sites
volumineux"),
par exemple un axe chronologique, un axe par
auteur, un axe par catégorie de produit
(avec des sous catégories), et un dernier
par service émetteur, alors vous devez vous
arranger pour que les enregistrements de toute
nouvelle toute nouvelle base soient compatible avec
au moins un axe de cette indexation. On me
répondra que ce n'est parfois pas
évident, mais l'effort en vaudra la peine le
jour où la base devra être
déployée.
De
plus, si plusieurs bases utilisent un même
critère de référencement, par
exemple, "commune de rattachement", alors la
table dans laquelle sera puisée ce
critère devra être unique.
Exemple
: pas question d'utiliser le code INSEE dans un cas
et le code postal dans un autre. De plus, il sera
souhaitable de systématiser le calcul
automatique de la correspondance
commune(s)-département(s)-région(s)
selon un référentiel unique .
Cet
attachement des enregistrements à des tables
communes garantit un certain niveau de
cohérence des bases de données sans
obliger l'entreprise à adopter
nécessairement une architecture de bases de
données hypercentralisée qui peut
mener rapidement au syndrome de l'usine à
gaz.
D'autre
part, de même que les informations du site
doivent faire l'objet d'un "monitoring", celles
contenues dans les bases doivent être
régulièrement suivies pour s'assurer
qu'elles ne sont pas frappées
d'obsolescence.
Enfin,
les bases éditées par plusieurs
entités doivent faire l'objet d'un accord
préalable sur les corpus communs de
données, les référentiels
choisis, et la représentation graphique
("sémiologique" pour faire semblant
d'être spécialiste) des
données.
Pour
assurer ces résultats, si l'entreprise
possède plusieurs bases concernées ou
si elle compte en créer beaucoup, la mise en
place d'une fonction Administration Des
Données (ADD, cf. veblog, "Gérer
la fiabilité de
l'information")
se révélera indispensable. C'est
l'ADD qui aura la vision globale des données
disponibles dans l'entreprise, des
incohérences à réviser, et qui
pourra, en coopération avec les
administrateurs des différentes bases
"métier", définir les quelques axes
d'indexation communs des enregistrements facilitant
leur publication ultérieure. Enfin, une mise
en convergence des standards techniques pourra
s'avérer nécessaire, notamment au
niveau des formats de description de
données.
Des
interfaces de consultation adaptées au grand
public
Cet
article ne serait pas complet si nous n'abordions
pas la question des interfaces de consultation des
bases par les différents publics.
En
effet, les interfaces de consultation des bases de
données purement métier sont
généralement conçues pour les
spécialistes manipulant la base en question.
Aussi, reproduire ces interfaces sur le web, ou
réutiliser des critères de
consultation qui sont le quotidien de
spécialistes chevronnés est une
erreur de nature à compromettre
l'utilisabilité du résultat.
La
consultation des annonces du BOAMP (Bulletin
officiel d'annonces des marchés publics) en
est un exemple: la recherche "guidée" vous
oblige à naviguer dans plus de 100
intitulés de catégories aux
intitulés pas toujours très parlants
et pas forcément conformes aux "mots
clé instinctifs" auquel pense l'internaute.
Quant à la recherche libre, si vous ne
connaissez pas le numéro de l'annonce que
vous cherchez, ou le numéro du BOAMP qui l'a
publiée, alors bonne chance pour la trouver.
En cause ici, l'absence d'une recherche "simple" de
type texte intégral.
La
recherche des annonces sur le site du
BOAMP
passe par une interface pas vraiment
intuitive...
Le
BOAMP devrait faciliter la consultation de sa base
:
- En
donnant un accès chronologique
évident à ses annonces (une
sorte de "blog", de journal en continu des
annonces)
- En
permettant de resserrer le champ des
recherches, en structurant la
présentation de ses annonces à
travers un annuaire de type Yahoo, avec une
douzaine de catégories de base,
déclinées en sous
catégories.
- En
permettant par défaut une recherche
simple de type "plein texte" dans les
annonces
- En
reléguant les options de sélection
actuelles au rang de recherche avancée,
plutôt destinée aux
spécialistes.
Par
conséquent, publier une base sur le Net
nécessite le plus grand soin au niveau de
l'interface de consultation. Là encore, si
la base représente un fort enjeu pour vous,
des tests d'utilisabilité en cours de
conception se révéleront
précieux pour vous éviter des
déconvenues. De surcroît, il
conviendra pour les bases de contenus très
textuels d'implémenter des fonctions de
recherche plein-texte à des outils qui n'ont
peut-être pas été conçus
pour cela au départ.
Conclusion
Comme
souvent, certains pourront trouver que les
recommandations ci dessus sont excessives et que le
web, avec ses 20% d'internautes connectés en
France, ne justifie pas que l'on chamboule la
façon de gérer les bases de
données dans une structure, ou que l'on
investisse dans de nouvelles façons de les
mettre en œuvre.
Cela
relève effectivement d'un choix politique et
économique au sein de l'entreprise. Mais
gardez à l'esprit que, selon toute
vraisemblance, tôt ou tard, toute entreprise
devra relier au Net (via internet ou des extranets
spécialisés, ou sur son Intranet
mondial...) des pans entiers de son patrimoine
numérique, y compris des choses qu'elle
n'aurait jamais imaginé pouvoir sortir de
cercles très fermés quelques
années auparavant. Et reprendre a posteriori
des bases en vue de leur diffusion sera toujours
beaucoup plus coûteux que de prévoir
à l'avance la possibilité de cette
diffusion.
|
