Mobi-prêt à la bibliothèque de l'Université de Paris I

Françoise Malet

Cet article retrace l'expérience de l'implantation de MOBI-PRET à la bibliothèque de l'Université de Paris I. Si les avantages de ce système, qui gère les transactions de prêt, édite des lettres de relances et fournit des statistiques, sont sensibles (rapidité des opérations, rigueur de gestion et souplesse d'utilisation), il existe cependant certaines contraintes dont la principale, liée à la sauvegarde, nécessite le stockage des données sur disquettes.

This article goes over Mobi-prêt setting up at the Academic library of Paris 1 University. If Mobi-Prêt is most suitable (fast operating, strict management and easy to use), there are somehow drawbacks such as data stockage on discs.

Quand une bibliothèque est située à la périphérie d'une ville, quand un effectif réduit amène à limiter ses heures d'ouverture le soir, on peut imaginer que le service du prêt à domicile sera un rouage fondamental de la vie de cette bibliothèque.

Nous le pensions quand, à la rentrée de l'année universitaire 1979-1980, nous avons instauré ce service en même temps que l'accès libre aux collections; nous ne savions pas que, très rapidement, nous allions être débordés par notre succès.

De Newark à Mobi-prêt

Nous avions adopté un système de prêt très simple, inspiré du système Newark : carte de lecteur et carte de livre insérées dans une pochette et classées par ordre alphabétique de nom de lecteur à la date de retour souhaitée; nous disposions d'une carte de prêt établie par l'Université conjointement à la carte d'étudiant ; l'usager n'avait pour sa part aucun formulaire à remplir; les opérations de prêt devaient donc se dérouler très rapidement. Nous n'avions pas compté avec leur nombre : la première année, nous distribuions en moyenne 227 livres par jour; au bout de deux ans, la moyenne était passée à 369 prêts quotidiens; le 22 décembre 1982 nous avons prêté 1 121 ouvrages, donc classé 2 242 cartes en prenant soin d'associer carte de livre et carte de lecteur à bon escient, tout en assurant les retours des ouvrages empruntés la semaine précédente.

Deux personnes étaient préposées au service, une troisième s'y adjoignait aux heures de pointe uniquement pour le classement; bien souvent, elles appelaient en renfort l'un ou l'autre d'entre nous.

Malgré cette mobilisation, la place manquait dans les tourniquets destinés au classement des pochettes, les responsables n'arrivaient plus à les intercaler au fur et à mesure des opérations si bien qu'il était quasiment impossible à un lecteur d'échanger l'ouvrage qu'il venait d'emprunter ou d'y ajouter le deuxième tome qu'il avait oublié de prendre à son premier passage. Par ailleurs, le retour des ouvrages s'avérait délicat : notre seul repère était le nom de l'étudiant, nous étions souvent obligés de le lui faire répéter ou de lui demander de nous montrer sa carte d'étudiant. La gestion des transactions s'alourdissait de celle des cartes confisquées (tout retard dans un retour était sanctionné d'une confiscation de durée égale de la carte de prêt).

De jour en jour, les files s'allongeaient devant le bureau de prêt et les conditions de travail du personnel se détérioraient.

Ni les uns ni les autres n'avions aucune connaissance en informatique, nous savions seulement que cette technique aidait à résoudre les problèmes de grand nombre. C'est la raison pour laquelle nous avons accueilli sans aucune hésitation la proposition que nous faisaient les responsables de l'informatisation des bibliothèques à la DBMIST en septembre 1982 de servir de site pilote pour l'implantation de Mobi-prêt.

Paradoxalement, c'est cette inexpérience, alliée à la situation de besoin dans laquelle nous étions, qui allaient nous aider à mener à bien cette opération. Nous nous y sommes en effet lancés « tête baissée »; avant même que ne soit installé le micro-ordinateur définitif sur lequel nous allions travailler, nous avions commencé à entrer les données concernant nos lecteurs et une partie de notre fonds sur un matériel prêté par le constructeur R2E 1.

Quand la période d'expérimentation réelle commença et que redoublèrent nos difficultés, nous avions déjà entré en mémoire plus de 2 000 lecteurs; il n'était donc plus question de faire machine arrière quel qu'en ait été parfois notre désir, même inexprimé.

Les épreuves que nous avons connues seront d'ailleurs épargnées aux futurs utilisateurs de Mobi-prêt, elles vinrent en effet essentiellement de problèmes techniques : des retards dans la livraison du micro-ordinateur nous ont amenés à utiliser un matériel dont la fiabilité n'était pas totale, la présence d'électricité statique dans nos locaux n'avait pas été détectée d'emblée et provoquait des perturbations aberrantes dans le système; elles étaient accrues parce que nous avions démarré l'opération en plein coeur de l'année universitaire. La livraison du MICRAL 80-55 en janvier 1983, l'achat de tapis anti-statiques dans les semaines qui suivirent, quelques interventions des techniciens de R2E allaient nous permettre de commencer à tester le logiciel dans des conditions normales d'utilisation.

Ce logiciel avait été conçu par une société de service : le Centre Normand de Conseil en Bureautique et Informatique (CNCI) 2 pour les besoins d'une bibliothèque municipale; il nous appartenait d'y faire apporter toute modification que nous jugerions nécessaire jusqu'à obtenir un produit adapté aux besoins de n'importe quelle bibliothèque universitaire.

Nous avons ainsi demandé que la durée du prêt soit modulable en fonction de la durée des vacances universitaires et en fonction du lecteur : étudiant ou professeur. Pour les besoins de l'Enquête statistique générale auprès des bibliothèques universitaires, nous avons réclamé que soient comptabilisés les lecteurs inscrits et non seulement le nombre d'emprunts effectués. Le renouvellement annuel du public étudiant comparé à la relative stabilité du public de la lecture publique devait aussi poser un problème.

A cette recherche étaient associées la bibliothèque de l'Ecole normale supérieure de Saint-Cloud et la bibliothèque de l'UER de psychologie de l'Université de Toulouse II.

Après une année d'utilisation nous disposons d'un système de prêt automatisé efficace.

Qu'y a-t-il au menu ?

Mobi-prêt gère non seulement les transactions de prêts et les pénalisations qu'entraînent les retards, mais encore édite les lettres de relance et produit à la demande toutes les statistiques souhaitables (cf. tableau 1) 3.

Le système comprend une unité centrale, une ou plusieurs consoles avec clavier, écran et crayon optique, une imprimante.

Le MICRAL 80-55, dont nous disposons actuellement, peut gérer 50 000 documents et 20 000 lecteurs.

Les caractéristiques de la bibliothèque

Les caractéristiques de la bibliothèque (intitulé, UER desservies, catégories d'usagers) et du service du prêt (nombre d'emprunts autorisés à la fois, durée du prêt selon les catégories) sont enregistrées dans le fichier des « paramètres » (cf. tableau 2). Les premières serviront à l'établissement des statistiques; les secondes régleront le dialogue qui s'instaure entre la machine et l'opératrice : si le règlement prévoit qu'on ne peut sortir qu'un livre à la fois et si un lecteur tente un deuxième emprunt, un message apparaîtra à l'écran : « lecteur possédant déjà un document, acceptez-vous le prêt ? »; si un lecteur interdit pour un retard essaye d'emprunter avant la levée de la sanction, le message apparaîtra : « lecteur pénalisé jusqu'au... ».

Les paramètres peuvent être transformés selon les besoins: une nouvelle UER peut être créée, une nouvelle catégorie de lecteurs admise, la durée du prêt peut passer de 7 à 14 ou 21 jours, le nombre d'emprunt permis de 1 à 2 ou plus, au moment des vacances de Noël ou de Pâques par exemple.

L'opération du prêt consiste en la lecture d'une étiquette « code à barres » placée d'une part sur le livre emprunté, d'autre part sur la carte de l'emprunteur; cette lecture, qui peut se faire soit par l'intermédiaire du clavier de la console, soit par celui du crayon optique, détermine la conjonction du fichier des lecteurs et du fichier des documents. Par conséquent toute opération de prêt suppose d'avoir déjà en mémoire les données de l'emprunteur et celles du livre.

Les lecteurs

Pour tout nouveau lecteur, on frappe sur le clavier de la console son nom, son prénom, sa catégorie, son UER d'appartenance, son adresse, tous éléments nécessaires, d'une part pour l'établissement des statistiques et, d'autre part, pour le bon acheminement des lettres de relance.

Il ne faut pas cacher qu'il s'agit là d'une tâche lourde quand on la compare à la facilité que représentait l'existence d'une carte de prêt établie par l'Université en même temps que la carte d'étudiant et quand on la multiplie par plusieurs milliers.

La CNCI nous avait proposé une carte de prêt que l'étudiant aurait gardée tout au long de ses études; dans ce cas, le fichier des lecteurs aurait été apuré chaque année par la suppression des étudiants de 3e cycle de l'année antérieure. Nous avons rejeté cette proposition : nous savions en effet par expérience que l'étudiant attache peu de prix à sa carte de bibliothèque, il la prête, la perd; nous souhaitions utiliser pour le prêt la carte d'étudiant dont la valeur est plus grande à ses yeux. C'est donc sur cette carte que nous collons l'étiquette code à barres.

La carte d'étudiant change chaque année; il fallait ou bien pouvoir y apposer une étiquette portant le même code que celui de l'année passée (et pour ce faire disposer d'une imprimante à étiquettes) ou bien effacer tout le fichier des lecteurs de l'année précédente et le recréer avec de nouveaux codes ou encore pouvoir modifier le code du lecteur tout en gardant ses données, corrigeant au besoin son adresse ou son niveau d'études. C'est cette solution, de loin la plus économique, qui nous est maintenant possible : quand un lecteur se présente pour une réinscription, il suffit de lire son ancien code, de coller une nouvelle étiquette sur sa carte de l'année en cours; à sa lecture, l'ancien code est effacé de la mémoire. Ne nous restent à créer ex-nihilo que les usagers nouveaux venus à l'Université.

A chaque année universitaire correspond une tranche numérique différente; quand nous saurons que tous les étudiants sont en possession de leur nouvelle carte, nous effacerons les codes de la tranche numérique antérieure demeurant en mémoire; jusqu'à ce jour, anciens et nouveaux codes restent actifs, peuvent donc être servis aussi bien les lecteurs qui ont reçu leur nouvelle carte d'étudiant que ceux qui n'en disposent pas encore.

Si la création des lecteurs au fur et à mesure qu'ils se présentent peut apparaître comme une perte de temps, il faut se garder de la tentation d'une inscription préalable de tous les lecteurs potentiels, à partir par exemple des listings établis par l'Université : cette solution fausserait les statistiques, mais surtout elle encombrerait inutilement la mémoire du micro-ordinateur dont la capacité est par nature limitée.

En revanche, la souplesse du logiciel permet dans le fichier lecteurs d'autres manœuvres que la simple création. S'il a perdu sa carte, un lecteur peut être « supprimé » sous son ancien code et « recréé » sous un nouveau. Les données d'un lecteur peuvent être modifiées, nous l'avons vu plus haut. Le code d'un lecteur qui aurait oublié sa carte peut être retrouvé par son patronyme : on effectuera alors le prêt en frappant le code au clavier.

Le logiciel permet également de sanctionner les lecteurs indélicats. Nous avons vu précédemment que les pénalisations pour retard étaient automatiques; il nous est aussi permis de bloquer les prêts d'un lecteur que nous voudrions repérer pour une anomalie quelconque dans sa situation ou que nous voudrions interdire. Un indice ajouté à son identification fera apparaître à l'écran, dès son premier passage, le message « lecteur non autorisé à emprunter, vérifier sa carte »; nous supprimerons l'indice quand sa situation aura été réglée.

Le tableau n° 3 montre les différentes interventions possibles sur le fichier des lecteurs.

Les documents

C'est en fonction de la capacité limitée de la mémoire d'un micro-ordinateur que les données relatives aux documents ont été volontairement écourtées. Une grande partie de la mémoire étant occupée par le fichier des lecteurs, 10 caractères seulement restent disponibles pour l'entrée de chaque document.

Le premier d'entre eux est requis pour caractériser la discipline à laquelle appartient le document : à Paris I, un D pour les ouvrages de sciences juridiques, un E pour ceux de sciences économiques, un H pour ceux de sciences humaines. Il pourrait être affecté au type du document prêté : monographie, thèse ou périodique. Cette donnée est nécessaire pour l'affinage des statistiques quotidiennes du prêt.

Le nombre de caractères restant ne permettait pas de définir l'ouvrage par sa cote : cote de libre accès, elle est souvent complexe et doit être complétée par le numéro de l'exemplaire en prêt. Nous avons donc résolu de définir chaque livre par son numéro d'inventaire, unique, par définition, pour chaque unité bibliographique.

Quand nous réclamons un ouvrage à un étudiant, il n'est par conséquent connu que par son code et par son numéro d'inventaire. Contrairement à ce que l'on aurait pu craindre, ceci ne semble gêner en rien les lecteurs de Paris I; recevant une lettre à l'en-tête de la bibliothèque, ils retrouvent l'objet de la réclamation. En revanche, quand un litige survient, il convient que nous nous reportions au registre d'inventaire avant de pouvoir connaître l'auteur et le titre du livre réclamé et au catalogue avant de pouvoir vérifier sur les rayons si l'ouvrage en question est ou non présent.

Mais la proportion entre le temps perdu pour ce type de recherche, relativement rare, et le temps gagné au moment de l'entrée en mémoire des documents (lecture de l'étiquette code à barres et frappe du numéro d'inventaire) est telle que, même s'il nous était donné de pouvoir caractériser plus largement le document, nous donnerions la préférence au système actuel.

Toutefois il faut remarquer que, puisque le numéro d'inventaire est le seul identifiant du livre, sa frappe requiert une grande attention : une simple inversion de chiffres voue à l'échec toute recherche pour l'avenir.

C'est pourquoi, contrairement à l'inscription des lecteurs, nous nous efforçons d'entrer en mémoire le maximum d'ouvrages avant leur emprunt.

Le logiciel permet certes de créer un document au moment même où on le prête mais il est plus sûr de le faire dans le calme. Nous avions donc, avant la mise en oeuvre de l'expérience, entré en mémoire tous les ouvrages qui avaient été prêtés durant les vacances de Noël 1982; désormais, nous entrons en mémoire les nouveautés avant leur mise en rayons, aux heures de moindre affluence; ne sont créés au moment de leur emprunt que les ouvrages qui préexistaient à l'installation du système informatisé. Sur 11 000 ouvrages enregistrés durant une année universitaire, quatre cas d'erreur dans le numéro d'inventaire ont été repérés et réparés par des moyens divers.

Le logiciel se prête également à toute une série d'interventions sur le fichier documents (cf. tableau 4). Un document peut être « supprimé », s'il est exclu du prêt. Un document peut être modifié, si on s'aperçoit après coup que le numéro d'inventaire entré était erroné. Il arrive qu'un livre revienne de chez le relieur en ayant perdu son étiquette en chemin, une interrogation par le numéro d'inventaire permettra de retrouver son code, de l'annuler et de lui en attribuer un autre.

Les transactions

Si l'opération « prêt » est extrêmement rapide (un coup de crayon optique sur l'étiquette de l'étudiant, un autre sur l'étiquette du livre), l'opération « retour » l'est encore plus : au coup de crayon sur l'étiquette du livre s'affichent le nom de l'emprunteur et la date à laquelle il devait rendre son livre, le prêt est effacé de la mémoire, on passe au lecteur suivant.

Le système est rigoureux : on ne prêtera à un étudiant que le nombre de livres inscrit dans les paramètres et pour la durée prescrite.

Il n'en est pas pour autant figé; la date de retour du prêt s'affiche automatiquement au moment de la validation, mais si l'on veut l'influencer il suffit, au lieu de valider, de taper sur le clavier la date de retour souhaitée; c'est ainsi que, même si le prêt est fixé pour une semaine, nous pouvons le limiter à 24 heures ou l'étendre à 10 jours, les relances se feront aussi bien.

Le nombre d'emprunts pour un usager peut excéder celui qui est de règle : il suffit de répondre affirmativement quand s'affiche le message « lecteur possédant x documents, acceptez-vous le prêt ? ».

Si le lecteur se justifie, la sanction pour retard peut être levée : il suffit d'effacer un indice dans les données de l'intéressé.

La trace écrite des transactions opérées n'existe plus, elle est remplacée par l'interrogation du menu (cf. tableau 5).

Par le programme « situation d'un lecteur » on peut connaître le numéro d'inventaire des ouvrages qu'il détient, par le programme « situation d'un document » si celui-ci est ou non en prêt (ce programme a été exploité en particulier au moment du récolement annuel).

Il faut savoir que le traitement des prêts est complété par un programme qui permet le renouvellement d'un prêt ou la réservation d'un document : nous n'avons pas nous-même testé ces programmes, incompatibles à nos yeux avec la demande de nos usagers : trop de lecteurs ont besoin d'un même ouvrage en même temps et les exemplaires du même titre sont trop peu nombreux sur nos rayons pour que nous puissions permettre qu'un livre reste plus d'une semaine entre les mains d'une seule personne ou qu'il soit bloqué en attendant le lecteur qui l'aurait réservé.

Nous utilisons pourtant la « réservation » quand, pour une raison ou pour une autre, nous souhaitons arrêter un ouvrage au moment où il rentre à la bibliothèque : le « réservant » est alors un membre du personnel.

Le système allie donc dans la pratique quotidienne rapidité d'exécution, rigueur de gestion et souplesse d'utilisation. Il nous a permis le vendredi 25 mars 1983, veille des vacances de Pâques, de prêter 1 258 ouvrages (et de reprendre ceux que nous rendaient les étudiants) sans qu'aucune file ne se soit formée devant la banque de prêt.

Il est vrai que pour faire face à ce flux, nous disposons de deux consoles que nous spécialisons selon les périodes de l'année, l'une pour les inscriptions, l'autre pour les transactions, ou l'une pour les prêts et l'autre pour les retours, mais au mois de juillet dernier nous faisions encore près de 400 transactions quotidiennes et une seule console, donc une seule opératrice, suffisait à la tâche.

Mobi-prêt soulage tout autant le travail intérieur. Les lettres de relance sont en effet éditées au nom et à l'adresse du lecteur infidèle quand nous le souhaitons; nous déterminons nous-même la date en deçà de laquelle nous désirons que soient rappelés à l'ordre tous les retardataires. Il ne nous reste qu'à mettre les lettres sous enveloppe et à attendre le retour des ouvrages. A la fin de l'édition des relances la liste des noms des destinataires s'imprime.

Les statistiques

Les statistiques de prêt si fastidieuses et si difficiles à établir nous sont également données par Mobi-prêt sous différentes formes.

Les unes réclament du temps et du papier, ce sont heureusement les moins intéressantes. Les listes de lecteurs inscrits au service du prêt par ordre alphabétique ou par ordre numérique sont très longues à établir (l'édition des listes de 5 000 lecteurs inscrits a pris plus d'une heure, nous n'avons pas renouvelé l'expérience). La liste des lecteurs actifs est plus exploitable, elle peut n'être éditée qu'en toute extrémité d'année, elle donnera alors les noms des lecteurs qui n'ont pas rendu les ouvrages empruntés et pourra servir de « liste noire ». Enfin, des statistiques de communication pour chaque ouvrage entré en mémoire sont possibles, cependant elles ne peuvent être individualisées, l'ordinateur balaiera nécessairement l'ensemble du fichier des documents. Nous avons reculé devant le temps requis pour une telle opération et préférons en ce domaine en rester à la tradition et garder sur chaque livre le papillon « à retourner le ... » que nous collions à l'époque du prêt manuel; c'est une garantie pour le lecteur qui ne peut ainsi ignorer la date à laquelle il doit restituer son emprunt et, pour nous, une information immédiate sur la circulation du livre dans l'année.

D'autres statistiques sont rapidement extraites et fort utiles pour la gestion d'une bibliothèque. A la demande s'imprime le nombre de prêts effectués pour chaque discipline ; puisqu'au moment de l'entrée en mémoire des documents nous distinguons le droit, l'économie et les sciences humaines, c'est sous ces trois rubriques que les statistiques se présentent.

Nous avons choisi de tirer cette donnée chaque jour et de faire une addition en fin de semaine, mais nous aurions pu choisir une autre périodicité. A la demande également et en quelques secondes nous obtenons le nombre de lecteurs inscrits, triés selon leur catégorie, nous savons ainsi quel est le succès de notre bibliothèque parmi les étudiants de 3e cycle ou parmi les chercheurs. Enfin, et chaque conservateur soucieux de maîtriser la politique documentaire de sa bibliothèque appréciera cette possibilité, nous pouvons connaître en quelques minutes combien d'emprunts ont été faits par catégorie de lecteurs à l'intérieur de chaque discipline : nous apprenons ainsi que ce sont les étudiants de 1er cycle d'histoire qui ont emprunté le plus, les professeurs de géographie qui ont eu le moins recours à notre service, et nous pouvons donc modeler nos achats en conséquence.

Il faut noter cependant que statistiques et relances ne peuvent se faire conjointement aux opérations de prêt : une plage horaire doit leur être réservée. De la même façon il faudra tenir compte, dans les heures d'ouverture quotidiennes et hebdomadaires du service, du temps nécessaire aux « sauvegardes ».

Une contrainte : les sauvegardes

Nous abordons là la principale contrainte du système qui ne peut être négligée.

Les enregistrements magnétiques sont par nature fragiles : une erreur de manipulation, une micro-coupure dans l'alimentation électrique et les transactions enregistrées sur le disque de l'unité centrale sont perdues en tout ou en partie. Il s'agit donc de les sauvegarder en les stockant sur un support externe, en l'occurence des disquettes. Plus le nombre de données enregistrées sera important, plus la fréquence des « sauvegardes » doit être courte. En effet, si les informations contenues sur le disque se trouvent effacées, elles seront reconstituées à partir des disquettes de sauvegarde mais il manquera les transactions enregistrées entre le moment où les dernières disquettes auront été écrites et celui où la panne est intervenue; ces transactions seront reprises à partir de la trace que la machine adjointe au système imprime au fur et à mesure du travail. Dans ce cas, le crayon optique ne peut servir, c'est par le clavier de la console qu'on intervient et une demi-journée de travail de l'ordinateur devient une journée entière de « dactylographie ».

Fortes de cette expérience, nous sauvegardons nos fichiers deux fois par semaine durant les mois de juin et de septembre mais chaque jour à partir de la rentrée universitaire. De plus, comme l'opération « sauvegarde » peut être empêchée par la défectuosité d'une disquette (et c'est un support dont la fiabilité est imprévisible) nous avons constitué trois jeux de sauvegardes et nous nous donnons le temps de pouvoir, si nécessaire, recommencer les manoeuvres. C'est pourquoi, sachant qu'une sauvegarde dure environ 45 minutes, notre service du prêt est interrompu 1 heure au moment du déjeuner et s'arrête 1 heure avant la fermeture de la bibliothèque. Il ne fonctionne pas non plus le lundi de 9 heures à 12 heures pour nous permettre d'établir lettres de relance et statistiques et de procéder à la « réorganisation » du disque. En effet, au fur et à mesure les informations des transactions, se désorganisent dans l'unité centrale aboutissant finalement à un temps de réponse trop lent; il faut donc une fois par semaine rétablir l'ordre sur le disque en relisant les disquettes de sauvegarde l'une après l'autre.

Cette opération, rapide en elle-même (une quinzaine de minutes) est délicate car, autant la sauvegarde sur disquettes peut être interrompue sans interdire la remise en marche de l'ordinateur, autant l'opération « réorganisation du disque » doit être menée à son terme pour pouvoir retrouver des fichiers exploitables. Si donc durant cette opération une disquette ne pouvait être relue parce qu'abîmée, force nous serait de repartir avec le jeu de sauvegardes précédemment écrites et de récupérer par l'imprimante les transactions manquantes, avant de reprendre le prêt. Cette mésaventure ne nous est arrivée qu'une fois entre janvier et juin 1983, mais c'est une éventualité qui oblige à prévoir un temps suffisant de travail interne chaque semaine. Par ailleurs, ces opérations nécessitent la présence du personnel, à la fois pour surveiller le fonctionnement de l'imprimante quand il s'agit de statistiques ou de relances et pour changer les disquettes quand il s'agit de sauvegardes.

Mobi-prêt les bibliothécaires et les lecteurs

Pour ce travail, comme pour la pratique quotidienne du prêt, toute personne est rapidement efficace; pour peu qu'elle soit attentive à ce qu'elle fait, elle apprendra très vite à manier le crayon et à tirer parti de toutes les possibilités qu'offre le système.

Toutefois, la bonne marche du service suppose la désignation d'une responsable qui, maîtrisant l'ensemble, saura démêler l'écheveau des fausses manoeuvres, en cas d'erreur, et trouver sans hésitation la parade, en cas de panne : dans tous les cas, cela demande une analyse de la situation et des réactions rapides.

Si le personnel de la bibliothèque avait tendance à fuir la banque de prêt aux débuts malheureux de notre expérience, jamais celles qui connaissaient les difficultés du prêt manuel ne se sont découragées. Aujourd'hui conservateurs et bibliothécaires adjoints ont toutes manié l'ordinateur au moins au moment du récolement et deux d'entre elles sont plus particulièrement capables de relayer la responsable du service en cas de besoin.

Quant aux lecteurs, après que nous ayons fait face à leurs railleries à l'origine de l'expérience, que nous ayons rassuré certains d'entre eux en leur garantissant que le système ne gardait pas trace de leurs emprunts dès lors qu'ils étaient rendus, que nous ayons montré à d'autres notre déclaration à la Commission nationale de l'informatique et des libertés, ils apprécient maintenant la rapidité de notre service, s'inclinent sans mot dire devant les sanctions et, grâce à la rigueur du système, aux garanties qu'il nous a apportées dans nos rapports avec les services administratifs de l'université (la « liste noire » de fin d'année sert à interdire la réinscription des étudiants en litige avec la bibliothèque), rendent les livres avec une régularité que nous n'avions jamais obtenue auparavant. Sur plus de 50 000 ouvrages prêtés en 1982-83 ne manquaient à la rentrée 83 que 51 d'entre eux.

En offrant Mobi-prêt aux bibliothèques universitaires, la DBMIST avait deux objectifs : y introduire l'informatique « en douceur » et répondre à un besoin ponctuel et urgent.

Ces deux buts sont atteints à la bibliothèque de l'Université de Paris I. Nous nous sommes si bien habitués à Mobi-prêt que les seules anomalies que nous constatons maintenant dans son fonctionnement sont dues à une trop grande familiarité des opératrices avec le système : elles ont tendance à anticiper ses instructions. Quel que soit le nombre de lecteurs qui s'inscrivent au service du prêt, quel que soit le nombre de transactions qu'ils effectuent, le logiciel nous permet de dominer la situation. Seule la capacité de la mémoire pourrait nous arrêter : les différents modèles proposés par R2E, les progrès que les micro-ordinateurs ne vont pas manquer de connaître, permettent d'envisager sereinement l'avenir proche en attendant qu'un système d'informatisation intégré résolve, en même temps que le prêt, tous les problèmes de gestion d'une bibliothèque.

Illustration
1974-1984 : La Bibliothèque de l'Université de Paris I a 10 ans

Illustration
1. Menu principal

Illustration
2. Visualisation des paramètres

Illustration
3. Fichiers lecteurs

Illustration
4. Fichier document

Illustration
5. Transactions

Illustration
Annexe 1 - Groupe technique de suivi et d'évaluation des projets d'informatisation des bibliothèques

Illustration
Annexe 2 - Liste des sites Mobi-prêt

  1. (retour)↑  R2E : Zone de Courtabœuf - 91940 LES ULIS (6) 926.01.77.
  2. (retour)↑  CNCI : « Les Marronniers », rue Saint-Nicolas, 50400 Granville (33) 907313.
  3. (retour)↑  Les tableaux datent de fin 1983.