Index des revues

• Ducharme, Christian
  Le catalogue, signe du changement , p.66-68.
• Lupovici, Catherine
  L'information secondaire du document primaire , p.68-72.
• Lahary, Dominique
  De SGML à HTML, p.73-76.
• Czaplinski, Jean-Marc, Moret, Yves
  Z39.50, p.77-81.
• Lahary, Dominique
  Le jeu de puzzle de l'accès aux catalogues , p.82-85.
• Renoult, Daniel
  L'informatique au service du public , p.85-90.
• Duchemin, Pierre-Yves
  La recherche d'informations sur l'internet , p.91-96.
• Curt, Anne
  Droit d'auteur, économie, tarification, p.97-102.
• Danset, Françoise
  La révision de la convention de berne sur la propriété littéraire et artistique , p.103.

Le jeu de puzzle de l'accès aux catalogues

World Wide Web et/ou Z39.50

Z 39.50, WAIS, World Wide Web : comment se comparent et éventuellement se combinent ces voies d'accès aux catalogues? Pas moyen de rendre compte de cette question si l'on ne part pas du modèle client-serveur. Et d'abord en rappelant que les termes client et serveur s'appliquent au matériel, mais aussi au logiciel.

Sur le plan matériel, on peut effectivement parler de machines serveur (on parle couramment en ce sens de serveurs) et de machines clientes. Par exemple, un micro-ordinateur à partir duquel on a accès à un serveur distant.

Mais il faut également parler de logiciels serveurs et de logiciels clients (1) Les premiers servent l'information aux seconds à la requête de ces derniers. Logiciels clients et serveurs forment des couples, car le dialogue entre les deux répond à des noms et protocoles précis.

Ce décor étant planté, il nous faut le compléter par deux notions clés. D'une part, logiciels serveurs et clients sont susceptibles d'être indifféremment répartis sur une ou plusieurs machines. D'autre part, il arrive qu'on empile les couples logiciels client-serveur, tel serveur devenant client d'une application située en amont.

L'exemple de l'accès aux catalogues constitue une magnifique application de ces principes.

L'interfaçage Z39.50 (figure 1)

Imaginons qu'un fournisseur de logiciel de bibliothèque souhaite rendre accessible son produit selon la norme Z39.50. Il va développer un module serveur Z39.50 en aval de son système et jouant le rôle d'interface. Ce serveur pourra communiquer avec des logiciels clients Z39.50, éventuellement élaborés par d'autres. L'interrogateur qui dispose sur son poste de travail d'un client Z39.50 va lancer sa requête sans se soucier du système gérant la base qu'il veut interroger. Son client envoie la requête selon la norme Z39.50. La question est reçue par le serveur Z39.50 qui la retraduit sous une forme intelligible par la base cible. Celle-ci envoie sa réponse dans son propre langage, le serveur Z39-50 la traduit en réponse conforme à la norme Z39.50 et l'envoie au client Z39.50, lequel l'affiche, sous une forme lisible par des yeux humains.

On aura compris que ce que nous avons ici désigné sous l'appellation de serveur Z39.50 est un logiciel qui interface spécifiquement tel système de gestion de bibliothèque (ou plus généralement de base de données) avec la norme Z39.50. Ce module est donc propre au système cible, tandis que le client Z39.50 peut lui être totalement indépendant. Si bien qu'avec un même client, on est susceptible d'interroger, successivement et même simultanément, des bases hétérogènes, pourvu qu'elle dispose d'un interfaçage Z39.50 adéquat.

Interfaçage Z39.50 pur

Cela suppose naturellement que l'interrogateur dispose d'un client Z39.50. Il peut en acheter auprès des quelques fournisseurs qui en proposent, ou bien en récupérer sur Internet. Ces logiciels clients permettent de lancer des requêtes normalisées et gèrent la présentation (l'affichage) des réponses. Ce sont en général des outils intéressants pour les professionnels des bibliothèques et de la documentation, mais de maniement peu aisé pour le public.

L'interfaçage WWW (figure 2)

Imaginons maintenant qu'on souhaite proposer l'accès au catalogue sur Internet aux utilisateurs d'un logiciel client de World Wide Web : le navigateur (NestcapeTM, Internet Explorer et leurs concurrents).

Le cas de figure encore majoritaire en France en 1996 est le suivant : à partir d'une page Web, la bibliothèque donne accès à une session Telnet sur la machine hébergeant sa base bibliographique. Sur le poste de l'interrogateur apparaît une fenêtre qui joue le rôle de terminal du système distant, et l'OPAC sera exactement le même que sur les terminaux situés dans la bibliothèque interrogée. Encore faut-il que l'interrogateur dispose sur son poste d'un client Telnet (2) et qu'il l'ait configuré dans son navigateur.

Un tel accès n'est qu'un pis-aller. D'une part, il pose des problèmes de sécurité. L'interrogateur a la main sur l'ordinateur distant. Il doit taper un login ne lui donnant accès qu'à l'interrogation du catalogue, mais l'intrusion reste à craindre. D'autre part, on se retrouve dans une fenêtre quelque peu préhistorique insérée dans un environnement multimédia, une sorte de corps ergonomiquement étranger. La souris devient inutile, sauf pour sélectionner du texte afin de le copier-coller.

Pour éviter cet inconvénient, il faut inter-facer la base avec le World Wide Web. C'est possible, car on peut à partir du World Wide Web avoir accès à des bases de données, grâce à une programmation appelée CGI (Common gateway interface). Un module spécifique au système est mis en place en aval du système, que nous appellerons serveur Web. L'interrogateur qui souhaite interroger le catalogue reçoit sur son écran une page dite de formulaire, qui comprend des cases libres où formuler ses requêtes et éventuellement des menus déroulants ou des cases à cocher lui permettant de sélectionner des options.

Interfaçage WWW pur

Sa requête est reçue par le serveur Web qui la traduit en langage intelligible par la base. Celle-ci retourne sa réponse qui est traduite en langage HTML propre au World Wide Web puis envoyée au navigateur qui l'affiche sur l'écran de l'interrogateur.

L'OPAC est ainsi revêtu d'habits neufs. Mais, au-delà de l'apparence, il n'a pas fondamentalement changé. Les clés d'accès, la grammaire de recherche demeurent les mêmes. Si l'OPAC affiche des listes de vedettes entre lesquelles choisir avant d'afficher des notices, le navigateur affiche ces mêmes listes. La différence, c'est qu'on sélectionne une vedette en cli-quant, et certains systèmes nous envoient des notices bibliographiques également cliquables : un nom d'auteur permet de relancer la recherche sur cet auteur, et ainsi de suite.

Il importe enfin de signaler que le simple interfaçage Web d'un catalogue ne permet à l'utilisateur que d'interroger une base à la fois.

Comment marier Z39.50 au WWW ? (figure 3, page suivante)

Comment concilier l'avantage du client universel qu'est le navigateur avec celui de la norme 239.50 qui permet l'interrogation multibases? Tout simplement en emboîtant judicieusement clients et serveurs.

Tout en aval, nous avons le navigateur, client universel. Tout en amont, la base bibliographique avec son module serveur Z39.50. Il suffit d'insérer entre les deux un couple serveur Web-client Z39.50 », et le tour est joué. Ce double module reçoit les questions transmises selon les standards de World Wide Web et les traduit en requête Z39.50 avant de les envoyer au serveur Z39.50. Puis il reçoit les réponses de celui-ci en norme Z39.50 avant de le traduire en pages HTML puis de les envoyer au navigateur.

Où ce couple clé est-il implanté? La figure 3 le montre en position moyenne. C'est une représentation logique. Physiquement, on peut imaginer trois types de localisation :

• en position intermédiaire, sur un site jouant le rôle d'antéserveur ;
• en aval, sur le site ou même le poste client ;
• en amont, sur un site hébergeant une base et son serveur Z39.50, et qui propose ainsi une orientation vers d'autres bases.

Interfaçage Z39.50 + WWW

Cette localisation physique n'est pas anodine. Car où se fait la sélection des bases à interroger ? Sur le client Z39.50, exclusivement. D'où nous tirons cette règle : qui détient le client Z39.50 a le choix des bases à interroger.

Si le client Z39.50 se trouve sur le site de l'interrogateur, ce site peut (moyennant une configuration supposant la connaissance de l'adresse des machines, des types de requêtes admises, etc.) composer à sa guise son menu parmi toutes les bases bibliographiques du monde entier accessibles selon la norme Z39.50 et compatibles avec son client.

Si ce client se trouve en position intermédiaire, cela signifie qu'un site propose au public une orientation vers un choix de bases qu'il a lui-même constitué. C'est ainsi que le futur Catalogue collectif de France ménagera, depuis une page Web, un accès simultané à trois bases bibliographiques : celle de la BNF, celle du système universitaire et celle issue des conversions rétrospectives des fonds patrimoniaux d'un certain nombre de bibliothèques municipales.

Enfin, si le client Z39.50 se trouve sur le site hébergeant une base à interroger, cela signifie que ce site propose à ses interrogateurs une orientation vers un choix d'autres bases.

Et comme nous avons vu que ce client Z39.50 formait un couple avec le serveur Web qui lui était lié en aval, c'est ce couple que nous avons, dans cette explication, successivement imaginé en position amont, intermédiaire et aval.

La solution WAIS (figure 4)

WAIS a représenté la première application à une échelle significative de la norme Z39.50, en l'occurrence une variante de sa version 1. Les bases interrogées doivent répondre à certains impératifs de format et être indexées par un outil appelé WAISindex. Ou bien l'on constitue des bases WAIS conformément à ce format, ou bien, ce qui est très courant, on effectue des copies reformatées conformément à WAIS de bases diverses, ce qui peut nécessiter leur mise à jour régulière à partir de la base « réelle

WAIS + WWW

WAIS a d'abord exigé de l'interrogateur qu'il dispose sur son poste de travail d'un client WAIS, mais on rencontre de plus en plus un interfaçage Web, selon le modèle décomposé plus haut.

Les premières WAIS n'autorisaient qu'une interrogation sur tout le texte des enregistrements, avant que ne soit possible une interrogation par champ permettant par exemple des requêtes sur auteur, titre, sujet, etc.

WAIS n'a guère pénétré le monde des bibliothèques publiques, mais de nombreuses bases de données WAIS, bibliographiques ou textuelles, généralement spécialisées, sont interrogeables sur Internet.

Conclusion

De ces quatre schémas logiques, dont on pourrait décliner un certain nombre de variantes, chacun peut en déduire de quoi il a besoin, comme client ou comme serveur, comme interrogateur ou comme fournisseur d'informations. Qui a vraiment besoin de Z39.50? Et d'un interfaçage Web ? La question se pose d'ailleurs dans des termes différents selon que l'on a les moyens de réaliser soi-même, ou de faire réaliser les interfaçages ou qu'on dépend des initiatives et propositions de son fournisseur de logiciels intégrés.

Mais il est également permis d'en tirer un enseignement sur la question des catalogues collectifs. Pendant longtemps, la seule façon de permettre une interrogation simultanée relative à des collections réparties était de fondre plusieurs catalogues en un seul, ce qui, en matière de catalogues informatisés, n'allait pas sans de délicates opérations de formatage et de délicates et rarement abouties tentatives de dédoublonnage. Or voilà qu'on sait organiser des accès à des bases réparties et même hétérogènes : le catalogue collectif peut être virtuel. Encore faut-il que la présentation des résultats puisse se faire non base par base, mais par liste unique, ce que commencent à faire réaliser certains clients Z39.50. Les moyens existent en tout cas pour que de véritables réseaux bibliographiques s'organisent en faisant l'économie de lourdes opérations de fusion de bases.

Enfin, il serait erroné de considérer que tout ceci ne concerne que la mise à la disposition des catalogues sur Internet. Ce qui est possible à l'échelle mondial l'est à l'échelon local. Les liens figurés sur les quatre schémas peuvent représenter des milliers de kilomètres ou quelques mètres, voire des emplacements sur un même disque dur : le catalogue local en Intranet est possible et souhaitable.