entête
entête

L'Hypertexte en réseau

repenser la bibliothèque

Hervé Le Crosnier

Nous connaissons l'avènement de la première génération du document électronique, dit aussi document hypertexte, ou multimédia, selon que l'on souhaite souligner le modèle de navigation au sein des composantes du document ou la diversité des types d'information mobilisés par la lecture du document. Ces documents électroniques se répandent rapidement sur support optique (principalement les CD-Rom, mais d'autres supports cherchent encore à se faire une place au soleil : CD-I, CD-Vidéo, Data-Discman, ou sont en gestation, comme les cartes au format PCMCIA 1).

Mais, à peine le mode de lecture de ces documents commence-t-il à se généraliser, que le réseau rend possible une extrapolation, en définissant un hypertexte en réseau, qui permet de considérer l'ensemble des documents électroniques de celui-ci comme des composantes d'un même métadocument qui serait l'espace virtuel tout entier. Cette conception du réseau informatique comme un immense document réparti entre plusieurs sites a été rendue possible par la normalisation portant sur trois éléments :

- une manière de nommer les ressources informatiques de façon à les rendre accessibles par divers outils de navigation : les URL (Uniform Resource Locator) ;

- le protocole http (hypertext transfer protocol), qui permet d'exploiter l'infrastructure technique du réseau à partir d'une généralisation du modèle client-serveur qui englobe tous les protocoles de transmission des données définis précédemment ;

- le langage de balisage HTML (Hypertext Markup Language), qui permet d'inscrire au sein même d'un document électronique des « ancres » permettant de « naviguer » aisément (par un simple « clic » de souris dans le cas général) entre diverses « ressources » réparties dans le réseau.

Cette conception du document électronique est d'emblée fondée sur la métaphore de la bibliothèque. Le modèle utilisé par les concepteurs de ces documents n'est plus la forme codex, qui est à la base du livre moderne 2, mais directement le concept d'une immense bibliothèque dans laquelle chaque « bloc d'information » serait offert en « libre accès » à la curiosité du lecteur. Document multimédia, le document électronique en réseau est construit à partir de divers types d'unités élémentaires : texte, image, sons, vidéo, et même outils de repérage comme les tables des matières, les index ou les recherches documentaires. Document hypertexte, le document électronique favorise une circulation rapide entre les unités élémentaires, principalement sous la responsabilité propre du lecteur, qui choisit son chemin parmi l'ensemble des chemins de lecture qui lui sont proposés.

Cette conception du document électronique qui émerge des recherches actuelles sur le réseau informatique pose deux types de problèmes au bibliothécaire :

- il s'agit d'un nouveau document qu'il convient d'offrir au lecteur : poste de travail en réseau, accès direct à Internet...

- il s'agit d'une nouvelle conception de l'organisation de l'information, qui permet à la fois de repenser la bibliothèque, mais aussi qui doit hériter du savoir-faire et des réflexions multi-séculaires des bibliothécaires pour ne pas entraîner le lecteur vers une perte de sens par surabondance et désorganisation de l'information.

C'est un défi intellectuel qui doit nous mobiliser passionnément. C'est aussi un défi social (qui aura droit à l'accès à l'information répartie en réseau ?) et un défi démocratique (comment les informations essentielles à la prise de décision réussiront à surnager parmi la pléthore d'informations qui provoquent un « bruit de fond » contraire à la liberté d'expression ?).

Il n'est pas indifférent que les bibliothécaires, compte tenu de leur situation intermédiaire entre les producteurs d'information et les lecteurs, aient une place à prendre et un rôle à jouer pour que se maintiennent les objectifs de démocratisation de l'accès à l'information qui fondent la profession. Le réseau est un nouvel espace géopolitique. La manière dont l'information qui y circulera sera utilisée pour la liberté ou la domination n'est encore écrite nulle part. Il y aura des enjeux, des combats, des reculs et des avancées de la liberté d'expression dans ce qu'il est convenu maintenant d'appeler le cyberespace. À nous d'y prendre une place, d'y jouer notre rôle.

Le document multimédia

Pour maîtriser les enjeux de l'hypertexte en réseau, il convient de revenir sur les caractéristiques principales de l'hypertexte 3 :

- dans un hypertexte, les informations sont contenues dans des « noeuds », mis en relation par des « liens » à l'action immédiate. L'information contenue dans chaque noeud particulier est disponible sous l'une des formes habituelles (message textuel, sonore, iconographique ou vidéo), mais aussi sous une forme exploitant complètement l'environnement informatique (logiciel, programme de simulation, programme de recherche documentaire, table des matières dynamique...) ;

- la « navigation » dans un hypertexte se déroule en « invoquant » des liens rattachant deux noeuds, au travers d'une « interface » qui présente une métaphore explicite de l'action enclenchée par la sélection d'un lien. L'hypertexte est ainsi fortement associé aux interfaces graphiques, même si on trouve des modèles élémentaires s'appuyant sur les interfaces en mode ligne, dans lesquels les liens sont simplement représentés par un « numéro » de choix. On se trouve alors en face d'un « menu » imbriqué à l'intérieur du texte d'un nœud.

Les principales limites de l'hypertexte tiennent à la structure en blocs d'informations juxtaposés. En effet, nous ne connaissons pas encore une « grammaire de l'hypertexte » qui permette aux auteurs de jouer aisément d'un registre rhétorique étendu, qui indique les diverses formes de continuité et d'enchaînements qui président aux choix des liens mis en valeur 4. Cela se traduit pour le lecteur par deux formes de désorganisation cognitive 5 :

- le « problème du musée d'art » : le lecteur a vu tellement de choses juxtaposées qu'il ne sait plus quelle connaissance est liée à telle information. Il est plus hypnotisé qu'il n'acquiert une connaissance structurée ;

- le « problème des digressions imbriquées » qui se traduit par un sentiment de « perte dans l'hyperespace ». Le lecteur s'éloigne du but de sa recherche primaire pour suivre les chemins de traverse que l'hypertexte soumet à son bon vouloir.

Ces problèmes sont encore accentués par la constitution du réseau, qui permet de lier entre eux un très grand nombre d'éléments d'information. Il y aura encore du chemin pour que la lecture des hypertextes devienne « naturelle » ou « évidente ». Un profond bouleversement de nos modes de pensée. Mais d'ores et déjà, certains des acquis de l'hypertexte nous sont devenus indispensables, comme de « cliquer » spontanément sur un élément d'information afin « d'obtenir un supplément d'information ». Par exemple, cliquer sur un titre d'article... en espérant que le système enverra l'article lui-même ou son résumé. Ou encore cliquer sur un appel de note en attendant de voir s'ouvrir une fenêtre avec la note, sans avoir à quitter le corps du document. Ces « actes spontanés » du lecteur habitué aux interfaces graphiques sont à prendre en compte dans la conception des documents électroniques.

Du réseau d'ordinateur à l'espace informationnel mondial

Internet a début comme un instrument permettant de constituer un réseau d'ordinateurs. Les premiers outils visaient à faciliter les connexions à distance (Telnet), à déplacer des fichiers d'un ordinateur connu vers son poste de travail ou vice-versa (FTP), et enfin à autoriser la communication asynchrone entre utilisateurs (messagerie). Dans l'ensemble de ces applications, la connaissance de l'adresse de la machine cible (ou du destinataire d'un message) était un pré-requis indispensable.

Or cette situation a très rapidement évolué en 1993-94. Les nouveaux outils qui sont apparus (WAIS, Gopher, et W3 6) permettaient de se libérer de cet adressage « physique » des machines support pour se concentrer sur l'adressage « logique » des informations. Les concepteurs de serveurs (serveurs Gopher, ou serveurs W3) se chargeant pour le bénéfice de leurs utilisateurs de repérer les informations disponibles dans l'ensemble du réseau, et d'établir des « pointeurs » agissant automatiquement pour permettre la consultation de ces informations à partir d'un univers symbolique le plus proche possible du sujet de la recherche. Le réseau est passé rapidement d'un maillage de machines à la constitution d'un tissu mondial d'informations 7.

Le modèle choisi en 1991 par Gopher consiste à présenter l'information dans une série de « menus », avec les limites de ce genre d'exercice : un texte d'introduction à l'information qui ne peut dépasser 60 caractères, et une hiérarchie des menus qui n'est jamais vue de la même manière par le concepteur et l'utilisateur. Par analogie, on retrouve une bibliothèque fonctionnant simplement sur une liste de « vedettes-matière » et une classification hiérarchique. Mais l'impulsion centrale, qui visait à mettre l'information elle-même au coeur du réseau, était donnée, avec un rapide succès de l'univers Gopher (gopher-space), conçu comme cet ensemble interconnecté d'informations placées dans des « menus ».

Gopher a aussi inauguré une dimension collective très forte de l'organisation de l'accès à l'information. Chaque concepteur de « serveur Gopher » pouvait s'appuyer sur le travail de ses collègues de par le monde, et, en sens inverse, offrait la spécialité de son lieu de recherche comme garantie d'un meilleur accès de toute la communauté à l'information de son domaine spécifique. On retrouve ainsi la logique des « réseaux de bibliothèques » tels que Conspectus ou le réseau des Cadist en France : les points forts servent l'ensemble de la communauté, ce qui les encourage à maintenir leur niveau d'excellence.

WAIS (Wide Area Information Server) est un outil qui permet d'indexer les textes numériques et d'interroger en même temps plusieurs banques de données ainsi constituées. Là encore, la notion spatiale (choix de la « bonne » banque de données) est dissimulée par la notion d'accès direct à l'information souhaitée. Certes, le modèle de recherche documentaire de WAIS n'est pas exempt de limites 8, mais sa facilité de mise en œuvre et sa capacité à offrir à l'utilisateur la possibilité d'interroger en même temps plusieurs petits services documentaires très spécialisés jouent en faveur d'une banalisation de cet outil. Par analogie, on retrouve accès aux bibliothèques proposé par les logiciels modernes : interroger en même temps tous les services documentaires d'un campus, et poser simplement une question par mots-clés, sans langage documentaire.

Les promesses de W3

W3 est pour sa part un ensemble de protocoles qui permet d'imbriquer l'information dans les pages mêmes qui sont présentées à l'écran.

On retrouve le modèle hypertexte : chaque page d'accueil (home page) de W3 est l'équivalent d'une « table des matières » et permet d'incorporer des liens vers d'autres informations. Là encore, la localisation physique des machines soutenant l'information cible reste sans importance. Ce modèle hypertexte permet de mieux coller au caractère d'ubiquité de l'information (plusieurs liens pour établir un graphe complet entre les noeuds d'information), comme de préciser dans le texte même de « l'ancre » d'appel une quantité d'information suffisante pour éclairer l'utilisateur. Même si, actuellement, toutes les promesses de W3 ne sont pas toujours tenues, la dynamique est lancée. Les utilisateurs ne s'y sont pas trompés, qui font un succès grandissant aux services W3 (plus fort taux de croissance de l'utilisation du réseau en 1994).

En marge de ses capacités hypertexte, W3 permet aussi de déplacer des images ; aussi bien des images de grand format et de bonne qualité, que des « imagettes » qui servent à éclairer la présentation des pages d'information, ou à servir de lien. Les versions récentes du protocole autorisent aussi la détermination des zones sensibles dans des images qui permettent d'appeler d'autres informations (un zoom sur l'image, ou un commentaire textuel, ou encore un message sonore...). On retrouve les instruments d'un outil multimédia. L'analogie propre à W3 est celle de la médiathèque en libre accès, classée par centres d'intérêt, mais qui conserve la possibilité accès plus traditionnels (par recherche de « mots-clés » ou par balayage hiérarchique comme dans une classification traditionnelle).

Enfin, le succès de W3 s'appuie sur sa capacité à intégrer les autres outils d'Internet (Telnet, FTP, mais aussi Gopher, WAIS, le babillard Usenet, la messagerie...). Pourquoi apprendre les règles d'utilisation et le langage de commande de FTP quand on peut obtenir le même effet simplement en cliquant sur les répertoires ou les noms des fichiers de l'ordinateur distant qui apparaissent comme une page W3 ? Cette simplicité de fonctionnement, cette unité de l'interface qui permet un apprentissage rapide, est au centre du succès de W3.

L'autre élément de l'accueil franc et massif de ce service par les utilisateurs tient aussi à la qualité des visualiseurs (browsers) qui ont été proposés gratuitement. W3 fonctionne suivant le mode client-serveur (cf. encadré). Un serveur W3 est appelé par n'importe quelle machine qui dispose d'un « client » adapté, appelé « visualiseur ». Le plus connu d'entre eux est sans conteste Mosaic, au point que souvent on en vient à confondre W3 (l'ensemble de protocoles qui permet l'hypertexte en réseau) et Mosaic (un visualiseur particulier). Les visualiseurs propres de W3 sont en outre capables d'appeler des visualiseurs plus spécifiques pour montrer à l'écran des images, des textes au format PostScript ou TEX, des vidéos... C'est cette intégration poussée permettant néanmoins le développement séparé de chaque visualiseur spécifique qui est aussi un moteur du succès de Mosaic, puis de ses concurrents.

Mosaic

Mosaic a été développé au NCSA (National Center for Supercomputing Applications), un service de l'Université de l'Illinois soutenu par la NSF (National Science Foundation) et ARPA (Advanced Research Projects Agency), qui vise à offrir à la communauté de recherche des États-Unis des outils informatiques diffusés ensuite gratuitement. Ce visualiseur a été lancé simultanément le 12 novembre 1993 sur les trois principales plates-formes d'Internet : le Macintosh d'Apple, Windows de Microsoft et le protocole X-Windows des stations UNIX. Ce choix permettait à tous les utilisateurs de disposer d'un accès à l'hypertexte en réseau, dépassant la communauté des utilisateurs d'UNIX pour toucher y compris le grand public. Les utilisateurs individuels qui contactent directement un fournisseur de services Internet, comme Francenet, Fnet, Oléane... peuvent utiliser Mosaic depuis leur ordinateur personnel, avec un modem à 14 400 bps et une simple ligne de téléphone en mode PPP (Point to Point Protocol). Plus lent qu'un accès complet au réseau, mais disponible chez soi sans attendre les autoroutes de l'information.

Le succès a été à la hauteur des espérances. Plusieurs millions de visualiseurs sont aujourd'hui actifs de par le monde, simplement quelques mois après le lancement du logiciel. Aujourd'hui d'autres visualiseurs, plus rapides, parfois plus ergonomiques et plus perfectionnés commencent à apparaître, souvent à l'initiative de sociétés commerciales (comme NetScape de Mozarilla, développé par d'anciens concepteurs de Mosaic). Une bataille des prix va certainement s'engager dans ce domaine dans les mois qui viennent. Cependant, la logique qui consiste à fournir gratuitement le logiciel accès au réseau W3 a servi de rampe de lancement à de nombreux services, publics ou privés. Un arrière-goût de Minitel distribué gratuitement, venant du fin fond des États-Unis, qui doit faire sourire plus d'un initiateur du réseau vidéotex français... et grincer des dents les contempteurs du « colbertisme à la française ».

Les protocoles de W3

W3 fonctionne grâce à un ensemble de protocoles qui permettent de :

– définir une manière de nommer toute ressource informatique (texte, image, page Gopher, accès Telnet...) répartie sur le réseau par le biais des URL 9 ;

– décrire une manière de placer des liens utilisant ces URL au sein de documents textuels grâce au langage de balisage normalisé HTML 10 ;

– préciser un moyen de demander et envoyer un document au travers du réseau par le protocole de transfert d'hypertextes HTTP 11.

La manière de nommer des ressources et la rédaction de pages W3 sont les deux éléments qui intéressent directement les bibliothécaires :

– les URL servent à nommer une ressource. Dans le cadre de la constitution d'un hypertexte en réseau, chaque noeud d'information est constitué par un fichier numérique, dit « ressource », pour rester suffisamment vague sur la nature de ce noeud (texte, image, son, vidéo, logiciel...). Un même fichier numérique peut être dupliqué et installé sur plusieurs serveurs. Deux démarches sont alors à envisager :

– définir un nom « absolu » de chaque ressource, qui soit attaché à toutes ses copies (l'analogue de l'ISBN dans le domaine du livre). Nous n'en sommes qu'aux prémisses de ce travail, car un tel nom doit être attribué par des instances décentralisées, qu'il convient d'abord de définir, puis d'organiser dans un réseau. Les pré -requis pour qu'une telle organisation puisse être mise en oeuvre sont décrits dans la RFC 1737 (Request for comments) 12 ;

– définir un nom représentant une localisation particulière de cette ressource dans le réseau. C'est l'objet des URL. Un URL est défini pour chaque ressource en suivant les règles de la RFC 1738, et s'écrit de la façon suivante : « protocole » : « partie spécifique dépendant du protocole »

Les protocoles couverts aujourd'hui sont :

– ftp (file transfer protocol) pour le déplacement de fichiers,

– http (hypertext transfer protocol) pour l'accès aux services W3,

– Gopher pour les ressources du Gopherspace,

mailto pour définir des adresses électroniques,

news et nntp (net news transfer protocol) pour le babillard Usenet,

– telnet pour définir des services accessibles en sessions interactives (catalogues de bibliothèques, banques de données...),

– WAIS pour les banques de données utilisant les indexeurs WAIS,

file pour accéder à des fichiers locaux,

prospero pour les serveurs utilisant les annuaires de ce type.

D'autres schémas sont réservés pour des applications existantes, mais peu utilisées, ou prévues pour les applications à venir. IANA (Internet Assigned Numbers Authority) maintient un registre des protocoles utilisés dans les URL. D'ores et déjà, certains protocoles sont réservés, même si la spécification des objets documentaires (ressources) au travers de ces protocoles n'est pas précisément définie. Il s'agit principalement des accès aux services Z39.50, des serveurs de courrier (mailserver), des identifiants de messages pour le courrier électronique (mid).

Les parties spécifiques dépendent bien entendu du protocole d'accès. En général, pour tous les protocoles utilisant une adresse IP (http, ftp, gopher, telnet...), la partie spécifique renferme l'indication :

– du nom de la machine serveur qui héberge la ressource, éventuellement suivie du « port d'accès », si celui-ci est différent du port standard de l'application. Le nom de machine peut être précédé d'un login pour les accès réservés (notamment les accès telnet) ;

– du chemin d'accès vers la ressource, décrivant les divers répertoires emboîtés et le nom final du fichier de destination (cf. encadré).

Les URL servent à deux opérations :

– intégrer le nom d'une ressource dans un texte quelconque afin d'indiquer au lecteur la démarche permettant d'y accéder. L'expression sous forme d'un URL est plus compacte qu'une description littérale des accès. Partant, elle est plus fiable dans un univers aussi mouvant qu'Internet. La RFC 1738 conseille d'encadrer la mention d'un URL au sein d'un texte des balises « < » et « > », et même d'indiquer clairement que la séquence est un URL (exemple : « Vous pouvez utiliser le document <URL : http:... //> pour.. »). Le caractère « espace » est interdit dans les URL. Ceci permet d'inclure une espace dans un URL afin d'obtenir une césure en fin de ligne. Au décryptage, les espaces doivent être retirées ;

– rendre une ressource accessible à un programme, qui peut décomposer les opérations nécessaires pour atteindre le fichier décrit. C'est l'utilisation principale des « ancres » dans le langage HTML.

Le langage de balisage HTML

Coextensif de la création de W3, le langage de balisage HTML évolue rapidement. La version 2.0 est aujourd'hui en préparation 13. HTML est une DTD (Document Type Definition) de SGML (Standard Generalized Markup Language), la norme de balisage la plus répandue dans le monde de l'édition. Un fichier HTML est un fichier de texte dans lequel chaque partie logique est délimitée par deux balises (balise de début - exemple : <TI>pour un titre ; et balise de fin correspondante : </TI>). Les indications logiques sont interprétées par un visualiseur afin de redonner au texte une typographie et une présentation adéquate.

En ce sens, HTML ne permet pas de définir l'aspect d'une page de document lors de la visualisation, à la différence des « langages de description de page » comme PostScript ou des « formateurs » comme TEX ou Acrobat. HTML propose une structure logique (parties d'un texte : têtes de chapitres, énumérations, citations...) que chaque visualiseur présentera à sa manière (choix du type de caractère, des mises en valeur typographiques...). Certaines règles sont cependant définies dans la norme HTML, afin d'assurer une homogénéité des rendus des pages balisées. Ainsi, la balise de citation (<BLOCKQUOTE> ...texte cité </BLOCKQUOTE>) sera « typiquement rendue par un léger retrait à droite et à gauche et/ou l'utilisation de caractères italiques. La citation provoque une rupture de paragraphe, avec un espace au-dessus et en-dessous du texte cité ».

De même, pour permettre la circulation sur le réseau de documents qui possèdent des signes diacritiques, une définition des jeux de caractères et d'un codage en strict ASCII de tous les caractères a été ajouté à la norme. Le é accent aigu s'écrit ainsi : &eacute ; il est évident qu'un tel jeu d'équivalence des caractères doit être réalisé par un logiciel dit « éditeur HTML », qui facilite le travail du concepteur de pages pour W3.

La forte imbrication entre HTML et W3 permet aussi de définir au sein d'un document des « ancres » qui servent de signal de lien vers d'autres documents (textes, images, son, vidéo, logiciels... rappelons-le). Un signal de sélection d'une ancre au sein d'un visualiseur W3 invoque le lien correspondant et fait présenter sur le poste de l'utilisateur le nouveau document. Bien entendu, les ancres sont en général des URL, qui indiquent le moyen d'accéder à un autre fichier reparti sur le réseau.

Enfin, HTML permet d'indiquer les fichiers sources des images qui seront incorporées dans le texte lors de la visualisation (images inline). Ces imagettes apportent une fraîcheur à la présentation du texte et incitent à la navigation. Toutefois, leur surabondance se paye en général de temps d'accès au document plus long... ce qui est préjudiciable à la fluidité de la lecture d'un hypertexte. Les concepteurs doivent faire une balance entre le coût (temps d'accès) et les bénéfices (présentation claire et aérée). Certaines de ces images peuvent aussi être définies comme comportant des « zones sensibles » : un « clic » de souris sur cette zone envoie une information à un programme de traitement désigné par son URL... qui produit un résultat et le retourne au visualiseur. C'est ainsi que Claude Gross maintient une « carte de France » des serveurs W3 : pointer un lieu de la carte permet de se connecter directement au serveur désigné 14.

Si l'on peut produire directement un fichier balisé HTML à partir d'un éditeur de texte ou d'un traitement de texte, plusieurs aides sont fournies qui permettent de composer plus aisément des pages HTML. Notamment, des transcodeurs permettent de transposer des pages présentées (RTF pour les traitements de texte habituels, ou TEX et LaTEX) en pages HTML. Le développement de tels outils est indispensable en regard du succès de W3. On voit même apparaître des éditeurs HTML de type « tel écrit, tel écran », qui permettent, malgré les limites générales liées à la distinction entre le balisage et le rendu, de visualiser au mieux le résultat en cours de rédaction.

Enfin, HTML permet de définir des « formulaires », qui sont remplis par l'utilisateur sur son visualiseur et envoyés à un programme de traitement désigné par son URL. Ceci permet de préparer des questionnaires, ou des formulaires de requêtes pour poser une question à une banque de données ou un catalogue de bibliothèque.

L'hypertexte en réseau dans les bibliothèques

Le succès de W3 ouvre de nouvelles perspectives... et de nouvelles responsabilités pour les bibliothèques. On peut distinguer deux axes de réflexion :

– comment utiliser les nouveaux modes de navigation dans l'information pour présenter différemment les ressources documentaires dont disposent les bibliothèques, et compléter les modes d'accès par requête qui sont le propre de nos catalogues ?

– comment intégrer les documents évolutifs du type des hypertextes en réseau à la pratique de gestion des unités bibliographiques ?

La première question doit nous inciter à repenser les modes d'accès à nos catalogues et aux banques de données. De deux manières complémentaires :

– intégrer les catalogues aux services W3, soit en proposant une session telnet à partir d'une présentation du catalogue dans une page d'accueil, soit en utilisant le mode « formulaire » de HTML pour faire dialoguer directement nos ressources bibliographiques et le visualiseur W3 sur le poste de travail de l'usager. Cette voie est aujourd'hui bien avancée, avec notamment la généralisation de normes définissant les manipulations qu'entraîne l'utilisation d'un serveur bibliographique (norme ISO Z39.50 ; norme ISO « search and retrieve » ; format client-serveur propriétaire comme DXP lancé par la société de CD-Rom Silverplatter 15...) ;

– intégrer le modèle navigationnel au sein même de l'acte de recherche documentaire : une question « graine » dégage un lot de documents. L'examen de ce lot de documents provoque soit l'établissement d'une nouvelle question (modèle de « retour de pertinence » de WAIS par exemple), soit permet de naviguer à partir d'un document vers les documents les plus « proches ». Ce modèle d'un « hypercatalogue » 16 semble donner des résultats positifs 17.

La seconde question recouvre la notion de « collection de documents électroniques ». Au moment de leur création dans le réseau, les services W3 sont conçus comme des « sites » qui font appel à des ressources propres (locales) et à des ressources maintenues par d'autres sur le réseau. L'hypertexte en réseau connaît en conséquence deux modes de mise à jour :

– la mise à jour d'un nœud d'information, par modification du texte (cas simple, équivalent à la réédition dans le domaine de l'imprimé), ou par ajout en mode local d'une nouvelle ressource. Ce nouveau « document » est rendu accessible au travers de son « hypertexte d'accueil », par exemple parce qu'un nouveau lien est tissé depuis une « page de sommaire », qui permet d'appeler le nouveau document. On pourrait concevoir l'ensemble de ce processus comme une « réédition » d'un document multimédia, car il ne fait appel qu'à des modifications décidées par le concepteur du service et enregistrées sur le site local du service ;

– la mise à jour « provoquée » par une modification dans un autre service W3. Un service qui se repose sur des ressources distantes doit aussi en épouser les évolutions, les remises en cause... Quand un des services W3 du réseau est modifié, c'est l'ensemble de l'hypertexte en réseau qui évolue.

La responsabilité du partage

Dans cette architecture répartie de l'information, un site créateur d'un service W3 devient le seul responsable de la fourniture de son service à l'ensemble des utilisateurs, et cela à l'échelle mondiale. Cette situation n'est pas sans danger. Même si la puissance des machines et des réseaux était suffisante pour que chaque utilisateur puisse accéder à un tel service dans des conditions de confort correctes, ce qui est encore loin d'être le cas, il resterait des critiques à formuler. Deux exemples, là encore issus de notre pratique de bibliothécaires :

– supposons qu'un organisateur de service décide de rompre unilatéralement ses liens avec le reste du monde : dès lors, l'ensemble de l'information qu'il diffusait et sur laquelle s'appuyaient les autres services disparaît corps et bien. Par exemple, suite à une modification des relations internationales, qui limiterait les échanges entre pays. Cela s'est vu souvent dans ce siècle. Récemment encore, les documents (textes scientifiques, logiciels, algorithmes...) concernant la cryptographie ont été classés « technologies à risque » par les États-Unis et dès lors soumis à embargo à l'exportation. Et si l'information du serveur W3 spécialisé en cryptographie était uniquement localisée dans ce pays ? On ne peut regrouper en un seul endroit une information. Depuis l'incendie de la bibliothèque d'Alexandrie, cela fait partie de notre culture professionnelle. Cela doit encore avoir un sens à l'heure du réseau ;

– supposons qu'un auteur de service (éditeur de journal, auteur offrant ses publications sur le réseau...), se repentant de ses textes de jeunesse, modifie tous ses documents sur son serveur. En l'absence de duplication, c'est tout un pan de l'histoire des idées qui disparaît. Nous avons tous en souvenir ces photos des cérémonies moscovites dans lesquelles disparaissaient les participants au fur et à mesure de leur disgrâce. Il y a trop de danger à conserver sous une responsabilité unique (pas seulement d'individus, mais aussi d'États) les traces de l'activité intellectuelle.

Cette remarque concernant la nécessaire duplication des ressources sur le réseau nous amène à formuler un axe de recherche important, qui devrait mériter toute l'attention des bibliothécaires qui souhaitent intégrer les documents de l'hypertexte en réseau dans leurs collections : comment déplacer un hypertexte entre deux ordinateurs, et comment maintenir à jour la copie au rythme des changements dans le serveur principal. Pire encore : imaginons un journal électronique sous W3 (par exemple HotWired, qui a beaucoup de succès aux États-Unis 18) qui incorpore les remarques et critiques des lecteurs dans l'ensemble hypertextuel qui constitue le « journal » lui-même. Est-ce que les remarques des lecteurs du site recevant une copie auront le même statut que celles de ceux qui s'adressent au site principal ? Et comment se gère l'échange bilatéral ?

Une période de refondation

Nos bibliothèques ont pris l'habitude de traiter des documents clos (livres, et même documents électroniques unitaires : un texte connaît des « versions », que l'on peut gérer du point de vue bibliothéconomie comme autant « d'éditions »). Or les hypertextes en réseau sont des documents évolutifs. La solution technique (dite site « miroir » en informatique) reste insuffisante pour gérer une telle situation. Il faut la doubler de protocoles spécifiques de transfert d'hypertextes, mais aussi de protocoles sociaux qui définissent les conditions d'un tel transfert : quel est le statut d'un site « miroir » par rapport au site primaire, quel est le rythme de mise à jour, comment distinguer une mise à jour dans un service...

Le succès des trois protocoles de W3, qui permettent de faire fonctionner l'ensemble des informations réparties sur le réseau comme un vaste hypertexte, nous apporte autant de questions qu'il n'est l'augure d'une démultiplication de l'offre d'information. C'est à une véritable refondation de notre profession que nous devrions assister dans les années qui viennent. Les nouveaux documents électroniques nous permettent de porter un regard neuf sur des pratiques anciennes. Car nos pratiques, et leur relatif succès, gagé sur leurs longévités, peuvent aussi servir à la conception d'un réseau qui prenne en compte les intérêts des lecteurs.

Comment garantir la continuité de l'accès à l'information, et l'archivage de ces documents complexes et évolutifs ? Comment doubler la navigation hypertexte d'un mode plus direct de requêtes ? Comment gérer comme une vaste bibliothèque le monde de l'information électronique, avec des moyens de retrouver l'information et des moyens d'en garantir la pérennité ? Enfin, comment garantir l'égalité de tous dans l'accès à cette information ? Une question, comme nous l'avons vu, qui nous conduit à nous interroger sur la nature même des hypertextes en réseau dès lors que les sites de lecture/écriture sont eux-mêmes répartis.

L'information de demain, ses modes d'existence et ses besoins de diffusion et de conservation, sont en germe dans le réseau des services W3. À nous de prendre part à ce mouvement de redéfinition du document pour défendre le point de vue des lecteurs, présents et à venir.

Janvier 1995

Illustration
Le modèle client/serveur

Illustration
Quelques exemples d'URL

  1. &nbsp;(retour)↑  Personal Computer Memory Card International Association. Cf. Didier SANZ, « PCMCIA; des périphériques dans une carte de crédit », Sciences &Vie Micro, 1992, n°5, p. 178-182.
  2. &nbsp;(retour)↑  Roger CHARTIER, « Du codex à l’écran : les trajectoires de l’écrit », Pour une nouvelle économie du savoir, Solaris, Dossier du GRISIC, n°1, sous la dir. De Ghislaine CHARTRON, et al., Rennes, Presses universitaires de Rennes, 1994, p. 65-77.
  3. &nbsp;(retour)↑  Hervé LE CROSNIER, « Une introduction à l’hypertexte », Bulletin des bibliothèques de France, 1991, t. 36, n°4, p. 280-294.
  4. &nbsp;(retour)↑  Roland DACHELET, « Hypertexte et hypermédia : documents, informations, connaissances », Le document électronqiue, cours INRIA, 11-15 juin 1990, Rocquencourt, INRIA, 1990.
  5. &nbsp;(retour)↑  Carolyn FOSS, « Tools for reading and browsing hypertext », Information Processing and Management, 1989, t. 25, n°4, p. 407-418.
  6. &nbsp;(retour)↑  Dans tout ce texte, nous utilisons l’abréviation W3, qui est euphonique en français, plutôt que l’abréviation WWW (pour World Wide Web), fastidieuse.
  7. &nbsp;(retour)↑  Bruce N. SCHATZ et Joseph B. HARDIN, « NCSA Mosaic and the World Wide Web : global hypermedia protocols for the Internet », Science, 12 aôut 1994, vol. 265, p. 895-901.
  8. &nbsp;(retour)↑  Gary MARCHIONINI et Diane bARLOW, « Extending retrieval strategies to networked environments: old ways, new ways and a critical look at WAIS », Journal of the American Society for Information Science, 1994, 45(8), p. 561-564.
  9. &nbsp;(retour)↑  Tim BERNERS-LEE, L. MASINTER; M. McCAHILL, Uniform Ressource Locators (URL), RFC 1738, décembre 1994, 25p.
  10. &nbsp;(retour)↑  Jeff BARRY, « The Hypertext Markup Language (HTML) and the World Wide Web: raising ASCII text to new level of usability », The Public-Access Computer System Review, 1994, 25 p.
  11. &nbsp;(retour)↑  http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTTP2.html
  12. &nbsp;(retour)↑  K. SOLLINS, L. MASINTER, Functionnal Requirements for Uniform Ressource Names, RFC 1737, décembre 1994.
  13. &nbsp;(retour)↑  Tim BERNERS-LEE, Daniel W. Connoly, et al., Hypertext markup Language Specifications –2.0., Internet Draft, 28 novembre 1994.
  14. &nbsp;(retour)↑  http://www.urec.fr/France/france.html
  15. &nbsp;(retour)↑  Pat ENSOR, « Silverplatter embraces the future : the electronic reference library becomes a reality », Computers in libraries, juin 1994, 14(6).
  16. &nbsp;(retour)↑  Sandra RONY-SINNO, « Les hypercatalogues : nouvelles perspectives pour les OPAC », Bulletin des Bibliothèques de France, 1991, t. 36, n° 4, p. 303-311.
  17. &nbsp;(retour)↑  W. John WILBUR et Leona COFFEE, « The effectiveness of document neighboring in search enhancement », Information Processing & Management, 1994, 30(2), p. 253-266.
  18. &nbsp;(retour)↑  http://www.hotwired.com/