Transcript
GESTION DES FONCTIONS BIBLIOTHÉCONOMIQUES
À LA BIBLIOTHÈQUE DIOCÉSAINE de TUNIS
(BIBLIOTHÈQUE DES SCIENCES DES RELIGIONS)
La Bibliothèque diocésaine de Tunis (ci-après BiDio) est une bibliothèque spécialisée en sciences des religions avec un fonds de livres et des séries de revues, courantes et closes.
L’accès au fonds se fait à travers un catalogue automatisé sous deux versions de Winisis: une pour les données en arabe, l'autre pour celles en langues latines. Le prêt quant à lui demeure toujours manuel.
Les logiciels Greenstone et Zotero sont aussi utilisés, principalement pour la recherche sur les quelque 6.000 tables de matières que nous avons déjà scannées, avec l'aide de bénévoles, et pour les fichiers téléchargés d'internet.
Les catalogues latin et arabe sont généralement saisis et consultés sur des ordinateurs différents pour éviter les problèmes liés aux polices de caractères. Un thésaurus bilingue, qui doit être revu, est utilisé pour attribuer nos vedettes aux livres et aux articles des revues dépouillées.
Deux sites internet, hébergés sur des serveurs gratuits, ont été créés.
Le premier, http://bidio.site.voila.fr/ , est une présentation générale, et d'un petit moteur de recherches qui ne permet que la recherche, par auteur ou titre, que sur ce qui y était importé de la base "latine".
Le second, http://bibsr.ucoz.com , de type CMS,, est plutôt un essai de répondre à distance à des besoins d'utilisateurs et de maintenir à jour la liste des numéros de revues disponibles. Il comprend d'autres liens, dont un vers une bibliographie numérique "virtuelle" sur un groupe Zotero.
Le projet commencé avec l'aide de la CEMAT répond donc aux désirs:
d'unification en une seule base des données issues de Winisis, qui devrait être accessible en ligne. Le Système Intégré de Gestion de Bibliothèque « KOHA » semble adéquat pour réaliser ce souhait;
d'assurer une meilleure collaboration dans le domaine de l'informatique à l'intérieur-même de l'équipe de la bibliothèque en ce qui concerne la visibilité de la bibliothèque sur internet;
de faciliter le travail des chercheurs et les inviter à venir à la bibliothèque, ou leur éviter des déplacements inutiles;
de permettre à des stagiaires ou jeunes Tunisiens de se former partiellement chez nous;
et, finalement, de pouvoir aider d'autres bibliothèques à entrer dans la démarche des logiciels libres de qualité.
La bibliothèque diocésaine, seule spécialisée en sciences des religions en Tunisie, a un rôle à jouer dans le dialogue interreligieux, mais pourrait aussi, suite à sa petite dimension, servir de laboratoire de recherche en bibliothéconomie informatisée.
Le présent projet vise donc à améliorer les services que la BiDio peut rendre aux chercheurs des facultés environnantes, mais aussi à quelques étudiants des sciences de l'information, de bibliothéconomie, voire d'informatique.
Pour mieux appréhender la réalisation du projet nous allons, dans une premier temps focaliser notre attention sur l’existant et les facteurs clés de réussite du projet à travers une premiere partie, pour ensuite, dans une seconde partie un peu plus technique, donner quelques éléments à tenir en compte pour la mise en oeuvre utiliser du logiciel choisi : KOHA.
Les méthodes et outils utilisés, les problèmes rencontrés et les solutions reçues seront mises en ligne sur nos site, afin de mettre à la disposition d'autres bibliothécaires une suite ordonnée du développement de la mise en oeuvre de Koha à partir de données sous Winisis. Si le besoin s'en fait sentir, nous ouvrirons un forum sur notre site, mais nous préférerons toujours renvoyer vers les pages adéquates des sites d'utilisateurs et développeurs expérimentés de Koha et/ou Winisis.
Mots-Clés : BIBLIOTHÈQUE; INFORMATISATION; RÉINFORMATISATION; CATALOGUE; CATALOGUE INFORMATISÉ; PAGES DE CODES; KOHA; WINISIS; DIOCÈSE DE TUNIS; TUNISIE
Sigles, acronymes, logiciels gratuits
AVIE
:
Base de données arabe (5000 entrées) sous Winisis [CDS/ISIS 1.5 Arabic Enabled build 7, Unesco, 2004]
BiDio
:
Bibliothèque diocésaine de Tunis ou Bibliothèque des Sciences des Religions
BIDIO
:
Base de données latine (70.000 entrées) sous Winisis [CDS/ISIS 1.5 for Window build 3, Unesco, 2003]
CEMAT
:
Centre d'Études Maghrébines à Tunis
CDU
:
Classement décimal universel, à la base de notre thésaurus
CpConverter
:
Convertisseur de pages de codes: cp850 et cp1276 en UTF-8 [http://sourceforge.net/projects/cp-converter/files/cp-converter/CpConverter V 0.1.4.0/]
Greenstone
:
Suite de logiciels pour la construction et la distribution de collections de bibliothèques numériques [http://www.greenstone.org ]
ISIS
:
Famille de logiciels de bases de données développés par l'UNESCO: CDS/ISIS sous DOS, puis les différentes versions WINISIS (latine et arabisée), ISISMARC
MARC
:
Machine Readable Cataloging = normes de catalogage déclinées sous différentes versions: unimarc, marc21,...
MarcEdit
:
Suite d'outils pour éditer en MARC [http://people.oregonstate.edu/~reeset/marcedit/html/index.php]
OPAC
:
Online Public Access Catalog = catalogue bibliographique accessible par internet
PAGE DE CODES
:
Tableau qui met en relation les codes de caractères binaires utilisés par un programme avec les touches du clavier. Comme il existe plusieurs types de claviers, plusieurs langues humaines et de programmation, il y a donc beaucoup de pages de codes!
SIGB
:
Système Intégré de Gestion de Bibliothèque. Permet de gérer l'ensemble du cheminement des documents d'une bibliothèque: suggestion d'achat, commande, paiement, réception, catalogage, lecteurs, prêt, et même perte!
SGB
:
Système de Gestion de Bibliothèque
SGBD
:
Système de Gestion de Base de Données
SWK
:
Logiciel Swiss-Knife, développé par Bireme, qui est un ensemble d'outils pour la maintenance et l'amélioration de bases de données CDS/ISIS [http://www.unesco.org/isis/files/winisis/windows/utilities/swk/]
TDC
:
Table de Définition des Champs de la famille Isis
TSC
:
Table de Sélection des Champs de la famille Isis
ZOTERO
:
Extension du navigateur Mozilla Firefox qui permet de recueillir plus rapidement les informations concernant un livre, une publication ou autres objets du web [ http://www.zotero.org/]
Z39.50
:
Protocole d'échange de données bibliographiques
Introduction : but et rôle de la bibliothèque
Le dialogue des civilisations en général et le dialogue des religions en particulier est une des tâches prioritaires de notre temps. La Bibliothèque de l’Église catholique en Tunisie se veut un instrument au service de la rencontre entre les peuples. Elle est ouverte aux chercheurs qui s’intéressent à l’étude scientifique du fait religieux dans ses différents aspects.
Nous avons actuellement un fonds de plus de 25.000 livres en français, arabe et autres langues. Nous recevons périodiquement une vingtaine de revues spécialisées.
Notre fonds est presque entièrement informatisé. De plus, nous numérisons les tables de matières des livres les plus significatifs pour faciliter des recherches plus pointues. La plupart de nos livres portent sur les trois domaines suivants:
* Sciences des religions
Ces sciences regroupent diverses disciplines (histoire, sociologie, anthropologie, psychologie, phénoménologie, philosophie, etc.) qui prennent pour objet l’un ou l’autre des aspects du fait religieux (religions et spiritualités). Une attention spéciale est donnée aux trois grandes religions monothéistes (judaïsme, christianisme et islam), sans oublier les religions de l’Antiquité, les religions orientales ou les religions dites traditionnelles. Nous possédons également de nombreux ouvrages touchant aux phénomènes religieux contemporains: sécularisation et laïcité; identité religieuse; sectes et nouveaux mouvements religieux; ésotérisme, mystique et religiosité; syncrétisme, etc.
* Dialogue des cultures et des religions
« La richesse culturelle du monde, c’est sa diversité en dialogue » (UNESCO). La bibliothèque diocésaine possède des ressources importantes dans le domaine de la rencontre interculturelle et interreligieuse. Elles portent sur des sujets tels que: altérité et identité culturelle; acculturation et métissage culturel; couples mixtes; mondialisation; résolution des conflits; relations Nord-Sud; dialogue interreligieux, etc.
* Histoire de la Tunisie.
Nous portons un intérêt particulier à l’histoire de la Tunisie à travers les siècles: depuis la période phénicienne et la fondation de Carthage jusqu’à l’époque contemporaine, en passant par la Tunisie romaine, la conquête byzantine, l’arrivée des Arabes, la période ottomane et le protectorat français.
La bibliothèque est spécialement riche en ce qui concerne l’histoire du christianisme dans l’Afrique du Nord et ses grands noms: Augustin, Tertullien, Cyprien, etc.
Un bref historique de la bibliothèque diocésaine est disponible sur son premier site ( http://bidio.site.voila.fr/)
La gestion quotidienne et optimale des documents relatifs au dialogue interreligieux et à l'histoire des religions en Tunisie a une place de choix dans le souci de visibilité de l'Église catholique en Tunisie dans un souci d'améliorer toujours le niveau de respect de qualité dans son service envers l'Autre. C’est ce qui justifie toute l’attention vouée par le diocèse à l’amélioration services de sa bibliothèque. Le rôle de gardien de la mémoire des religions en Tunisie n'est pas non plus négligeable.
PREMIÈRE PARTIE: PRÉSENTATION GÉNÉRALE DU PROJET
I. Situation présente
I.1.- Contexte et justification du projet
I.1.1.- Contexte et existant
Le fonds documentaire est logé dans un magasin et est accessible aux seuls bibliothécaires de l'institution. Deux catalogues automatisés sous Winisis sont donc mis à la disposition des usagers de la BiDio pour la recherche à travers trois ordinateurs de consultations dédiés:
le premier comprend une copie régulièrement mise-à-jour de la base de données latine;
sur le deuxième est installé Greenstone pour permettre une recherche textuelle sur les tables des matières scannées et où des documents téléchargés sont aussi disponibles;
le troisième est arabisé et comprend une copie de la base arabe régulièrement mise-à-jour.
Bien qu'une connexion réseau soit disponible, nous avons préféré l'option de réimporter régulièrement les données saisies et corrigées sur les ordinateurs du personnel, qui travaille sur les bases de données installées sur le serveur. Cela permet d'une part d'éviter un propagation des problèmes (il est difficile d'empêcher les utilisateurs de sortir d'Isis, l'utilisation de clés USB entraîne un risque de contamination virale,...) et d'autre part cela nous donne des copies de sauvegarde.
L'aide du personnel et leur connaissance du fonds ainsi qu'une certaine proximité avec les étudiants et chercheurs ainsi que des matières de leurs recherches suppléent fréquemment à la perplexité que beaucoup de lecteurs manifestent face à l'interface d'Isis et/ou de Greenstone.
Le système de prêt est manuel mais ne concerne jusqu'à présent qu'un nombre restreint de lecteurs.
I.1.2.- Justification du passage à un système informatique plus performant
Pour améliorer ses services en offrant un accès plus aisé à ses catalogues, et dans un soucis de plus grande collaboration informatique, la bibliothèque diocésaine de Tunis se lance dans un projet de mise en ligne de ses données bibliographiques à travers un Système Intégré de Gestion des Bibliothèques (SIGB) libre, tant pour des raisons budgétaires que pour répondre à un désir d'unification des bases de données et de classement de documents téléchargés, mais encore pour devenir un lieu de formation et de collaboration avec des jeunes Tunisiens en formation.
Ce SIGB pourra donc, une fois installé et configuré, être utilisé comme outil de catalogage, de bulletinage, et de gestion des usagers et des prêts. Il permettra aussi la consultation du catalogue sur l'intranet et sur l’Internet et facilitera une interaction entre la Bibliothèque et ses usagers. Des jeunes chercheurs en bibliotéconomie, sciences de l'information ou même informatique pourront y trouver un lieu de stage.
I.1.2.- Objectif du projet
I.1.2.1.- Objectif global
Améliorer les services de la BiDio
en donnant accès aux bases de données bibliographiques à travers un OPAC
et mieux organiser la fonction de prêt.
I.1.2.2.- Objectifs spécifiques
- Rendre accessible sur Internet un catalogue unique latin-arabe de la BiDio, en utilisant le thésaurus maison;
- Faciliter le prêt, la régularisation, la réservation de documents et le prolongement des prêts à travers l’OPAC ;
- Offrir un lieu de stage à des étudiants;
- Faciliter l'interaction entre les usagers et la Bibliothèque.
I.1.3.- Bénéficiaires
Les bénéficiaires de ce projet sont multiples et de diverses origines géographiques. Mais il s’agit prioritairement des usagers réels de la BiDio (inscrits aux Facultés des Lettres et Sciences Humaines du 9 avril, de la Manouba ou des Facultés de théologie (musulmane) de la Zitouna ). Le panorama de ces bénéficiaires se présente comme suit :
- Usagers réels régulièrement inscrits à la BiDio:
o Étudiants des facultés sus-mentionnées;
o Étudiants d'autres facultés ;
o Enseignants et chercheurs, tunisiens ou visiteurs (d'Algérie, de France et d'Italie principalement ;
o Chercheurs en Sciences religieuses ;
o Religieux et religieuses;
o Lecteurs en recherche personnelle, hors cursus académique ; etc.
- Usagers potentiels intéressés par les sciences religieuses et/ou l'histoire de la Tunisie.
I.1.4.- Faisabilité
Étant donné que le présent projet a pour finalité d’améliorer les services offerts aux usagers de la BiDio, la question de retour sur investissement en terme quantitatif ne constitue guère une préoccupation majeure. Cependant, une analyse assez approfondie des compétences, ressources et fonds nécessaires à l’aboutissement du projet éviterait une improvisation exagérée.
I.1.4.1.- Compétences et ressources humaines
La BiDio dispose actuellement d’un effectif de quatre personnes dont les profils se définissent comme suit :
- 3 Personnes fortement motivées par le bon fonctionnement de la bibliothèque:
- 1 Prêtre "Père Blanc", nommé, avec l'accord de son Provincial, par l'Évêque de Tunis, directeur pour une période renouvelable de trois ans;
- 1 Soeur de Nevers, présente depuis la création de la bibliothèque, et sur qui repose l'essentiel de la saisie de la base de données en caractères latins;
- 1 Jeune Tunisienne, encore sous contrat à durée déterminée, qui se charge principalement du fonds arabe et de la numérisation des tables des matières.
- 1 dame de ménage qui s'occupe de l'entretien courant deux matinées par semaine.
Il est à noter que personne n'est formé académiquement ni dans le domaine de l'informatique, ni dans celui de la bibliothéconomie. Si le directeur est autodidacte et fonctionne à son rythme particulier, la secrétaire avide de connaissances informatiques, et la soeur passionnée par son travail, le souci de la rencontre et le désir d'être au service des lecteurs et chercheurs sont les moteurs essentiels de nos motivations pour améliorer le fonds et son utilisation.
I.1.4.2.- Ressources matérielles
Le potentiel matériel, infrastructurel et informatique de la BiDio se présente comme suit :
- Parc informatique
- 11 ordinateurs, de tous âges, chacun équipé de la version de Windows pré-installée au moment de l'achat ( de Windows 2000 à Vista), dont un serveur fonctionnant sous Windows 2000 server. Tous sont équipés d'onduleurs.
- 2 imprimantes
- 2 scanners bas de gamme,
- 2 photocopieuses
La bibliothèque est câblée en RJ 45 avec la possibilité de connexion sur des ordinateurs portables à partir de la salle de lecture et de la salle des périodiques.
I.1.4.3.- Ressources logicielles
- Winisis 1.5 build 3 pour la base de données BIDIO en caractères latins;
- Winisis 1.5 build 7 arabised pour les bases de données AVIE (arabe) et THES (thésaurus français-arabe). Il est à noter que la base THES permet une utilisation liée à la base AVIE, mais pas à BIDIO, suite au problème des différentes versions de pages de codes installées;
- Greenstone: "en sommeil", les données n'ont plus été mises à jour, mais un article de Guillaume Hatt ouvre de nouvelles perspectives, et encourage à le reprendre;
- Zotero : utilisé pour la gestion courante des documents téléchargés d'internet, il permet de sauvegarder des recherches effectuées et de recevoir les notices d'articles ou de livres téléchargés.
- Utilitaires divers : nous savons d'où nous partons, nous avons une idée de la destination finale, mais les moyens d'y arriver nous semblent encore assez flous, surtout en ce qui concerne les données en arabe. Les utilitaires gratuits téléchargés mentionnés ici ne seront peut-être pas tous nécessaires, mais les noter ici nous permettra d'y revenir au besoin: SwissKnife pour vérifier la cohérence des bases et effectuer certaines modifications; MarcEdit 5.2 pour importation (si nécessaire); Isismarc pour tester la structure; PSPad et/ou CPConverter pour le passage en UTF8.
I.1.5.- Opportunités
Existence d’un appui du CEMAT pour le bon aboutissement du projet ; existence d'instituts de formation compétants à Tunis.
Absence de date limite de réalisation: on peut se permettre de prendre le temps qui sera nécessaire.
Motivation: l'initiative du directeur a été bien acceptée par l'équipe et personne n'a l'impression de devoir faire un travail imposé.
I.1.6.- Risques
Notre manque de compétances dans le domaine informatique. Le directeur souffre des défauts des autodidactes: très bonnes connaissances pour certains aspects, lacunes abyssales dans certaines connaissances considérées de base.
Difficulté d'installation et de paramétrage de KOHA ; en effet, KOHA tourne sous Linux et nécessite pour son bon fonctionnement de bonnes installation et configuration. Il faut donc prendre le temps de collecter les informations nécessaires (manuels, fichiers d'aide, messages de forums,...) et de les assimiler. Il faudra peut-être envisager le concours d'un administrateur de base de données (MySQL) et d'un administrateur serveur pour son installation si celle-ci se révèle vraiment trop complexe, surtout lorsqu'il s'agira d'installer l'OPAC.
Difficulté de récupération des notices sous KOHA à partir des bases Isis: les Tables de Définition des Champs (TDC) des bases de données bibliographiques existantes ne sont ni au format MARC, ni en code UTF8.
Complexité de notre système de classement et de notre thésaurus, basé très librement sur le CDU, mais devenu progressivement "hermétique", suite à l'utilisation de nombreuses abbréviations.
Différences importantes et variées entre les bases latine et arabe de Winisis: il faut donc envisager deux procédures différentes pour arriver à un résultat unique.
Précarité liée à nos engagements dans nos communautés religieuses et dans l'Église en Tunisie en général. L'âge et la santé peuvent aussi engendrer des modifications de fonctionnement non prévues.
Et plus généralement, il ne faut pas minimiser le risque d'abandon ou de découragement face aux difficultés imprévues, les périodes de doute éventuelles sur la nécessité de passer à un système nouveau et plus complexe au départ alors qu'on pourrait continuer à fonctionner "comme avant"...
Et finalement, la gestion temporelle de ce projet. Il nous est difficile d'effectuer certaines tâches durant les permanences, voulant rester tous les trois disponibles aux lecteurs et chercheurs pour leurs recherches et la mise à leur disposition des livres et documents d'une part, d'autre part il est difficile d'imaginer pour de longues périodes l'arrêt de la saisie des données du fonds ou/et des nouvelles acquisitions. La plupart du travail de recherche sur le logiciel et son implémentation, d'essais de mise en oeuvre et de tests est donc réalisé par le directeur qui est également occupé par l'accompagnement de personnes à la clinique. Il s'agit donc souvent d'un travail nocturne, de week-ends, ou de rares périodes de fermeture de la bibliothèque.
I.2.- Description fonctionnelle
I.2.1- Résultats attendus
Au terme du projet :
les Tables de Définition des Champs des bases de données de la BiDio sous Winisis sont normalisées et réécrites sous format MARC21 . Une ou deux nouvelles bases sous IsisMARC pourraient être envisagées pour la saisie courante, si cela n'implique pas trop de modifications par rapport aux habitudes prises, ce qui risquerait d'engendrer un nombre d'erreurs excessif;
un catalogue unique (bilingue français-arabe) de la BiDio est accessible en ligne à travers un SIGB;
notre thésaurus simplifié, harmonisé et normalisé, est accessible à la fois pour la saisie et la recherche;
le prêt est mieux géré ;
une base de données des usagers est disponible et le dialogue entre la bibliothèque et les usagers renforcé ;
le catalogage reste possible sur le système simultanément par plusieurs catalogueurs.
I.2.2.- Choix du Système Intégré de Gestion de Bibliothèque (SIGB)
Afin d'adapter une solution logicielle aux besoins d'une autre bibliothèque et à ceux des ses usagers, une étude prospective des solutions sur le marché du libre a été réalisée par Mr Hounkpe. Il lui a été indispensable de déterminer à l’avance les fonctionnalités et normes technico-professionnelles requises.
Pour notre bibliothèque, les spécificités liées à la langue arabe et l'orientation du texte droite-gauche, impliquant un système BiDi (bi-directionnel) doivent être prises en compte.
I.2.2.1- Normes et standards
En plus des normes de catalogage, le SIGB doit être compatible avec des normes informatiques destinées à favoriser l’échange des données. Ils s’agit notamment des formats :
- MARC (MAchine-Readable Cataloging). Les formats MARC permettent de décrire les données bibliographiques contenues dans les catalogues de bibliothèques (UNIMARC, MARC21, etc.).
- ISO 2709 : norme internationale qui définit un format d’échange informatique de notices (bibliographiques ou autres).
- Z39.50 pour l'échange de données bibliographiques
- Prévoir le MarcXml et anticiper sa généralisation prévisible (selon certains forums)?
I.2.2.2.- Modules et fonctions
Généralement, les Systèmes de Gestion des Bibliothèques offrent séparément ou ensemble dans un même système les modules de gestion bibliothéconomique. Dans le cas où tous les modules sont intégrés dans un seul et même système, on parlera de SIGB. Le système que nous désirons devra intégrer en un tous les modules, donc un SIGB qui offrira les modules suivants :
- Acquisitions : pour la gestion des acquéreurs, des budgets, des fournisseurs. Ce module se consacre aussi à l’édition et la réception des factures, la gestion de différentes devises et des remises éventuelles.
- Catalogage : catalogage des notices bibliographiques au format MARC. Elles seront également reprises, si disponibles, des services Z39.50
- Circulation : la gestion de toutes les transactions de documents : prêt, retour, réservations, communication, gestion des pénalités de retard.
- Catalogue : le catalogue sera à la fois professionnel et public (OPAC). La recherche sera possible sur différents champs et sera simple et avancée.
- Editions : édition de listes : lettres de relance aux fournisseurs ou aux lecteurs, catalogues thématiques ou topographiques, bons de commande, liste de lecteurs, etc.
- Administration : paramétrage, sauvegardes, importations/exportations, traitements sur les bases de données.
- Statistiques : les statistiques devront porter sur l’utilisation du système par les utilisateurs en l’occurrence. Le SIGB doit donc pouvoir permettre l’édition d’un minimum de données (lecteurs, transactions, notices bibliographiques, exemplaires, dépenses).
I.2.3.- Revue des SGB gratuits étudiés par Mr Hounkpe
- Winisis
L’installation de Winisis - version Windows de CDS/ISIS - est très simple (un fichier exécutable) et le paramétrage se fait sans trop de problèmes. La clé de voute de Winisis est le formatage, un langage qui intervient à plusieurs niveau du paramétrage.
Winisis est conçu et distribué gratuitement par l’UNESCO. L’Institute for Computer and Information Engineering (ICIE) a développé et publié en 2004 une «surcouche» Web autour de bases au format CDS/ISIS : Weblis. Le catalogage, l’OPAC et la circulation peuvent ainsi se gérer à l’aide d’un navigateur Web . Mais ces fonctions ne sont pas à la taille du simple utilisateur de Winisis, car il faut les développer séparément et les lier.
- Koha
Koha est diffusé sous licence libre et fonctionne avec des technologies ouvertes (PERL, MySQL), tout en étant compatible avec les normes en usage dans les bibliothèques. L’accès professionnel et public se fait avec un navigateur Web. Le point faible de Koha est clairement l’installation et le paramétrage. Il intègre la quasi-totalité des fonctions bibliothéconomiques en allant de l’acquisition aux statistiques sans occulter le catalogage et l’OPAC. Koha permet la gestion simultanée de plusieurs sites de bibliothèques et autorise le catalogage collectif.
- PMB
PMB est un logiciel libre basé sur des technologies ouvertes (PHP, MySQL) et sur les normes de la profession. Il s’installe très facilement sur un serveur web (local ou distant). Les informations sont stockées au format XML, ce qui offre une garantie pour la pérennité des données. PMB s’administre et s’utilise avec un navigateur Web, il fonctionne aussi bien sous Windows que sur Unix/Linux. Point faible : certains champs UNIMARC ne sont pas présents dans la grille de catalogage. Mais on peut toujours les y ajouter manuellement.
I.2.4.- Synthèse et choix du logiciel
Bien que KOHA paraisse être le logiciel le plus complexe et le plus difficile à installer, nous allons opter pour KOHA. Le choix de KOHA se justifie par les points suivants :
Koha est un SIGB au sens strict et complet du terme ;
Koha intègre toutes les fonctionnalités bibliothéconomiques souhaitées ;
Koha intègre toutes les normes souhaitées ;
Koha, dans sa version 3.x, est supposé géré l'arabe
Koha est n'est pas lié à une entreprise particulière mais à un réseau de développeurs ;
Koha est l'objet de nombreux sites et forums où de l'aide peut être sollicitée ou trouvée suite à l'expérience d'autres bibliothèques ;
La BiDio aspire à partager son catalogue avec d'autres bibliothèques, donc obligation de faire du catalogage partagé en ligne ; etc.
I.2.5- Choix du format de catalogage
Le catalogage sous Koha se fait sous format MARC : UNIMARC et MARC 21. Le format MARC 21 proposé comporte presque toutes les zones prescrites dans la norme. Par contre, les zones comprises entre 001 et 008 sont absentes. KOHA offre tout de même la possibilité de paramétrer, d’ajouter et de modifier des zones. Le MARC 21 est utilisé par presque tous les pays anglosaxons alors que l’UNIMARC est utilisé notamment par la France et l’Espagne.
Nous allons opter pour le MARC 21. En effet le MARC 21 est :
- le format qui semble ouvert à plus de développement, et sera peut-être plus à même de gérer les situations arabisées ;
- un format pour lequel les ressources en ligne ne manquent pas ;
- Google renvoie plus de réponses à la demande conversion de UNIMARC vers MARC21 que l'inverse, ce qui suggère qu'il y a plus de transferts désirés vers MARC21 que vers UNIMARC.
I.3.- Mode de développement
Le développement se fera en deux étapes :
- Partie I : Développement sur deux ordinateurs de test, hors réseau (un à la bibliothèque, l'autre au domicile du directeur)
- Partie II : Développement sur serveur de production, si possible tunisien, et hébergement.
I.3.1.- Développement sur ordinateurs de test
Ce développement se fera en quatre modules principaux. Il s'agit du nettoyage des bases de données, de la récupération de leurs contenus et de leur conversion au format MARC 21 par l'écriture d'une application de reformatage de la TDC, avec la possibilité d'une phase de vérification/test sous Isismarc.
En parallèle, il s'agira d'installer, de configurer et de paramétrer KOHA pour y intégrer les données progressivement pour les tester et parer aux problèmes imprévus éventuels, et enfin, réaliser l’OPAC. Une attention particulière devra être portée sur les possibilités de réutiliser la base THES, ou certains de ses éléments, comme listes d'autorités ou thésaurus complet dans Koha.
- Module I : Vérification et corrections des bases "BIDIO" et "AVIE"
- Module II : Conversion des bases BIDIO et AVIE au format MARC21.
- Module III : Installation, configuration et paramétrage de Koha
- Module IV : Réalisation de l’OPAC
L'établissement de listes d'autorités à partir de THES et de certains champs vérifiés de BIDIO et AVIE devra aussi être fait, mais la tâche semble si longue et fastidieuse (22.500 lignes de "mots-clés" à revoir) qu'elle devra peut-être être reportée
I.3.2.- Développement sur serveur de production
Cette phase de développement n’est qu’une reprise des résultats de la phase du test sur le serveur.
En clair, il s’agira d’installer Koha sur un serveur, de reprendre exactement les paramètres de la phase de test et de migrer les données de cette phase sur le serveur. La phase de production sera aussi consacrée à des corrections éventuelles dans le catalogue et à l’automatisation du prêt. Ainsi, trois autres modules sont aussi identifiés à ce niveau. Mais il importe avant tout de présenter le projet aux collaborateurs éventuels et de former aussi bien les collègues documentalistes que les usagers à s’approprier Koha.
- Module V : Installation de Koha et migration des données sur le serveur de production
- Module VI : Automatisation du prêt
- Module VII : Formations
Tous ces modules sont découpés en plusieurs phases, ce qui permettra de déterminer le chemin critique lors de la planification. Les phases peuvent comporter une ou plusieurs tâches.
I.3.4.- Découpage des modules en phases
- Module I : Vérification et corrections des bases "BIDIO" et "AVIE"
- Module II : Conversion des bases BIDIO et AVIE au format MARC21
- Module III : Installation, configuration et paramétrage de Koha
- Module IV : Réalisation de l’OPAC
- Module V : Installation de Koha et migration des données sur un serveur
- Module VI : Automatisation du prêt
- Module VII : Formations
I.3.6.- Tableau synoptique de découpage des activités
MODULES
PHASES
INTITULÉS
TACHES
Développement sur les ordinateurs de test (BiDio et domicile)
MODULE I et II
Vérification et corrections des bases AVIE et BIDIO; conversion en MARC21 (structure) et en UTF-8 (page de code)
Étude des possibilité de réutiliser THES pour les listes d'autorité (langues, mots-clés, auteurs, pays...)
Phase 1
Corrections des structures d'après les données tomographiques obtenues avec SWK
Apprentissage progressif de Ubuntu (Linux)
1. Identification des anomalies (Sous-champs non déclarés et caractères résultants de fautes de frappe tels que ¤ )
2. Comparaison de la structure des champs des TDC avec les normes MARC21
3. Installation de Ubuntu sur plusieurs ordinateurs pour en acquérir les fonctions de base, passage progressif des tâches courantes sur logiciels libres (OpenOffice, messagerie,..)
Phase 2
Gestions des sous-champs et des champs répétitifs
1. Identification des sous-champs et attribution aux champs et délimiteurs de MARC21
2. Réaménagement des champs répétés lorsqu'ils ne doivent pas l'être (auteur principal p. ex.)
3. Création d'une base Isismarc
4. Création de TSC de reformatage et export en iso2709
5. Conversion en UTF-8
6. Import dans la base unique Isismarc(contenant AVIE et BIDIO)
Module III : Installation, configuration et paramétrage de Koha
Phase 3
Installation et configuration de Koha
• Installation du système d’exploitation linux sur la machine de test
• Installation de Koha et de ses dépendances
• Paramétrages des préférences d’administration et du système
Phase 4
Migration de la nouvelle base Isismarc sous Koha
• Importation du fichier des notices en format MARC 21
• Exemplarisation
• Test, corrections et gestion des problèmes des caractères accentués
Module IV : Réalisation de l’OPAC
Phase 5
Personnalisation de l’OPAC
• Changement des couleurs et logo
• Mise en ligne d’informations pratiques sur l’OPAC
• Création d’un échantillon de comptes d’utilisateurs pour test
Développement sur serveur de production (repris du rapport de Mr Hounkpe)
Module V : Installation de Koha et migration des données sur le serveur de production
Phase 6
Installation de Koha sur un serveur à déterminer
• Installation de Koha et de ses dépendances
• Reprises des paramètres de la phase de test
Phase 7
Migration des données sur le serveur
• Exportations des données de la machine de test
• Importations des données exportées sur le serveur de production
Module V : Automatisation du prêt
Phase 8
Gestion du prêt
• Création de la base de données des usagers
• Edition des carte de lecteurs
Phase 9
Gestion des exemplaires des documents
• Inventaire du fonds documentaire
• Equipement des documents d’identifiant unique (code à barre)
• Mise à jour du catalogue
Module VI : Formations et promotions
Phase 10
Formations
• Formations du personnel de la BiDio à l’utilisation de Koha
• Formation des usagers à la recherche sous Koha et à l’utilisation de l’OPAC
Phase 11
Promotion
• Présentations du projet aux autorités et collaborateurs
• Référencement de l’OPAC auxmoteurs de recherche
I.4.- Identification des intervenants
Le projet sera réalisé par l'équipe de la Bibliothèque diocésaine de Tunis.
Cependant, nous chercherons, avec l'aide du CEMAT, des contributions extérieures, tant pour:
- pouvoir arriver à une normalisation de nos bases de données avec une aide technique qui nous sera certainement nécessaire, tout en continuant la gestion quotidienne des activités de la bibliothèque, que pour
- donner l'occasion à des étudiants de partager l'expérience de cette mise en oeuvre.
Nous comptons aussi sur l'aide à distance de monsieur Steven Baker, ingénieur chez Microsoft, qui nous a déjà introduit brièvement mais très amicalement au monde d'Ubuntu (système Linux)
Nous sommes également ouverts à toute participation extérieure efficace, quelle que soit la qualification académique de(s) intervenant(s): un geek pourrait nous être plus utile qu'un docteur!
I.4.- Contraintes et planification
I.4.1.- Contraintes
Pour respecter les objectifs, nous nous posons les contraintes suivantes :
• Élimination des erreurs et incompatibilités structurelles dans nos bases
La base de données latine BiDio, dans son état actuel, présente un certain nombre de sous-champs non attribués. Il peut s'agir d'enregistrements effectués initialement sur d'autres bases (par des volontaires bénévoles qui nous ont aidés durant des périodes plus ou moins brèves, ou par le directeur qui a apporté des modifications dans une de ses bases sans les répercuter sur la base principale), mais la plus grande probabilité est qu'il s'agit de fautes de frappe. Ces sous-champs fantômes sont parfois difficiles à identifier: s'ils proviennent de champs non indexés, il suffit de modifier la TSC et de réindexer toute la base, mais si le caractère d'appel de sous-champ (^) se trouve au-delà des caractères affichés par le dictionnaire, il faudra trouver une manière de les repérer autrement...
• Respect du format MARC 21 pour l'encodage des notices
La table de définition des champs de nos bases est faite de façon empirique, selon certaines normes... adaptées. La migration immédiate des notices corrigées sous KOHA est impensable car elle poserait donc un certain nombre de problèmes dont les plus en vue sont : la perte d'information qui pourrait être causée par la non concordance des étiquettes des champs et sous-champs, la répétitivité de certains champs qui ne devraient pas l'avoir, les problèmes de carctères accentués, et, pour l'arabe, la question de l'orientation droite-gauche du texte, mais pas des délimeurs de MARC21. Le logiciel SWK devrait cependant nous permettre de manipuler la base arabe pour qu'elle soit compatible.
• Attribution de code à barre à chaque document du fonds. Contrairement à Mr Hounkpe, nous ne l'envisageons pas dans l'immédiat.
En effet, d'une part le prêt reste encore limité, et d'autre part tous nos documents physiques ont un numéro unique: un par livre ou numéro de revue, quel que soit le nombre de parties pour lesquelles une notice a été réalisée. De plus, le temps et l'immobilisation du personnel qui serait affecté à cette tâche porterait préjudice au service rendu aux lecteurs. On pourrait peut-être cependant enregistrer comme numéro de code barre ce numéro attribué aux documents (le champ BP, pour bordereau permanent, qui avait été créé pour éviter les confusions lors des procédures d'export-import qui peuvent modifier les MFN (master file number) des enregistrements dans Winisis.
• Durée du projet :
Il nous semble illusoire et contre-productif de fixer un délai précis pour la finalisation du projet.
Cependant, nous essayerons de déterminer un plan de travail pour un développement linéaire et par étapes progressives pour l'ensemble du projet. Par contre, un ordinateur dédié (le futur serveur intranet Linux) de la bibliothèque sera utilisé pour reproduire sur place, avec la secrétaire, ce qui aura été réalisé avec succès chez le directeur. Cet ordinateur devrait rester "propre" et uniquement sous Linux. On pourrait plus tard y verser une quantité restreinte mais représentative de données à un rythme plus rapide. Cette méthode aura pour intérêt de susciter l'appétit pour les étapes suivantes, de montrer la faisabilité du projet, mais surtout d'éviter de nous lancer dans des impasses lors de choix à effectuer en cours de route. Ce n'est que trop fréquemment que l'on se rend compte que des options choisies pour une étape se révêlent malheureuses lors du développement d'étapes ultérieures! De plus, un ordinateur en avance de quelques étapes permettra également d'identifier les difficultés et les moyens de les résoudre pour ne pas être en panne lorsque l'ensemble des données sera prêt pour l'import final.
Il s'agit aussi d'un projet qui s'inscrit dans une démarche de restructuration fondamentale du fonctionnement de la bibliothèque. Passer à Koha sans passer à un transfert général des tâches quotidiennes sous Linux (version Ubuntu) serait voué à l'échec. Idéalement, Windows ne devrait être gardé que pour la poursuite du fonctionnement de Winisis, en saisie et en recherche. Nous devrions nous approprier les logiciels tels qu'OpenOffice pour la bureautique, un programme Open Source pour la messagerie électronique. Nous commençons déjà à être habitués à Mozilla Firefox et Zotero, logiciels initialement conçus pour Linux.
La réalisation du projet pourrait trainer et durer dans le temps à cause de l'effectif restreint du personnel fonctionnel face aux tâches techniques et administratives déjà non négligeables qui existent. Le service offert aux lecteurs actuels ne pourra en aucun cas pâtir du développement du projet, et nous voulons tous les trois garder le même niveau de disponibilité face à leurs attentes.
• Absence d'informaticien et de bibliothécaire qualifié.
Pour régler ce problème, nous serons amenés à solliciter de l'aide, ponctuelle ou à plus long terme, à des personnes qualifiées. Nous désirons aussi partager, avec des personnes motivées, étudiants stagiaires par exemple, la chance que nous avons de développer un projet où, tel que cela se voit dans les forums consacrés à Koha et Linux, l'imagination et la "débrouille" doivent être associées à la culture et au savoir-faire ou apprendre-faire. N'étant pas soumis au couperet d'une échéance, les essais et erreurs seront acceptés, pourvu que la rigueur de la démarche et du travail accompli soit respectée, et, si possible, supervisée régulièrement par un encadreur, formel ou informel.
I.4.2.- Planification du projet
I.4.2.1.- Liste des tâches
1. Corrections des erreurs de frappe ayant une implication sur la structure de la base (^, .., majuscules accentuées,...) dans BIDIO et THES
2. Écriture d'une Table de Sélection des Champs (TSC) pour exporter en iso2709 à partir de BIDIO et AVIE en MARC 21
3. Installation du système d'exploitation Ubuntu Karmic sur les différents ordinateurs utilisés pour les tâches courantes. Vérifier le bon fonctionnement des imprimantes et scanners sur ce système (question des drivers, aide dans les forums)
4. Conversion des fichiers iso2709 venant de BIDIO et AVIE au format UTF-8
5. Étape critique: importation, soit en isismarc, soit en winisis, dans une base conforme au format MARC21. Recherche et vérification aléatoire de mots ou expressions "à risque": "État", mots en caractères non-latins, pagination et numérotations diverses (souvent, en arabe, des chiffres séparés par un de ces caractères: , ? - sont inversés ou non selon la présence ou l'absence de caractère d'espacement
6. Corrections ou retour à une étape antérieure si nécessaire et si les outils téléchargés (MarcEdit, SWK, Notepad++) ne permettent pas de les effectuer de façon globale.
7. Installation de Koha 3 (Linux) et de ses dépendances: à finaliser et vérifier (recherches sur les forums) s'il est utile de garder la version Koha 2.2.9 sur Windows sur l'un ou l'autre ordinateur.
8. Paramétrages des préférences d’administration et du système
9. Création et/ou importation des listes d'autorités de THES ou de certains champs existant en Isis
10. Importation du fichier des notices uniques en format MARC 21
11. Choix d'un hébergeur web
12. Exemplarisation
13. Test, corrections et gestion des problèmes des caractères accentués et arabes
14. Changement des couleurs et logo
15. Mise en ligne d’informations pratiques sur l’OPAC
16. Création d’un échantillon de comptes d’utilisateurs pour test
17. Installation de Koha et de ses dépendances sur le seveur de l'hébergeur
18. Reprises des paramètres de la phase de test
19. Exportations des données de la machine de test
20. Importations des données exportées sur le serveur de production
21. Création de la base de données des usagers
22. Edition des carte de lecteurs
23. Inventaire du fonds documentaire
24. Mise à jour du catalogue dont la saisie a été poursuivie sur AVIE et BIDIO
25. Poursuite de l'apprentissage de l’utilisation de Koha par le personnel
26. Formation des usagers à la recherche sous Koha et à l’utilisation de l’OPAC : création d'une présentation et séances de "cours"
27. Présentations du projet à l'Évêque, organisation d'une soirée de remerciement pour toutes les personnes qui seront intervenues.
28. Référencements de l’OPAC dans les moteurs de recherche. 29ss: imprévus ...
I.4.2.2.- Tableau de répartition des tâches
Tâche
PM
SM
KS
SB
ST
Autre(s)
Délai
Réalisation/Notes
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13
T14
T15
T16
T17
T18
T19
T20
T21
T22
T23
T24
T25
T26
T27
T28
T29
T30
T31
T32
Légende : PM=P. Marc (dir.); SM = Soeur Monique; KS= Karima; SB= Steve Baker (par mail); ST: Stagaire ;
T = Tâche; X = Personne associée à la tâche; XX = Responsable de la tâche.
I.4.3.- Facteurs de réussite
I.4.3.1.- Implication des acteurs
Une bonne entente entre les différents acteurs du projet, lors de sa réalisation, s'avère très indispensable. Il revient donc au chef du projet, de mettre tout en œuvre afin d'entretenir de bonnes relations avec ses interlocuteurs et de veiller au respect strict des engagements pris. La diplomatie, le tact mais aussi l’autorité sont des qualités nécessaires que doit posséder le chef de projet. Simplicité et honnêteté intellectuelle seront de rigueur. La capacité de reconnaître ses échecs involontaires ou erreurs de toutes sortes pour trouver ensemble une solution sera indispensable. Consécutivement, l'honnêteté intellectuelle sera de rigueur: trop de données sont en jeu (près de 80.000 notices à la fin du projet, 25000 entrées dans THES avant révision) pour que soit acceptée la dissimulation d'erreur trouvée, quelle que soit la personne ou la procédure responsable.
I.4.3.3.- Délai et finalisation des tâches
Le respect des délais de finalisation des tâches permettra de respecter la planification globale. Le chemin critique tracé lors de la planification des taches impose le respect de ce calendrier. Car il existe des activités clés dont le retard, ou la mise en oeuvre précipitée, pourrait nuire gravement au projet.
I.4.3.4.- Définition des rôles
Définir clairement les rôles des différents acteurs impliqués dans le projet permettra d'éviter les problèmes de conflits d'attribution d'une part, et va instaurer, d'autre part, un régime de responsabilité. En effet si les tâches ne sont pas bien définies ni attribuées personnellement à des personnes bien identifiées, il pourrait y avoir des conflits d'attribution ou des fuites de responsabilités.
I.4.3.5- Communication
Parce qu’une mauvaise communication peut ête source de conflits dans la réalisation du projet, il apparait impératif que le chef de projet instaure un bon système de communication entre les différents acteurs du projet. Ceci permettra de communiquer en temps réel à la hiérarchie les différents problèmes rencontrés et qui peuvent nuire au projet. La communication favorise aussi l'instauration d'une bonne ambiance de travail et permet aux uns et autres de travailler en toute confiance.
I.4.3.6.- Motivation
Un personnel motivé se libère très facilement de ses tâches. C'est pour cette raison qu'un accent particulier sera mis sur les conditions de motivation du personnel engagé dans le projet. La motivation passe par l'implication de la hiérarchie dans le projet et dans toutes les tâches, mais aussi par la reconnaissance des efforts fournis par les uns et les autres. Des avantages matériels et pécuniaires pourraient éventuellement suivre, en fonction de dons qui seraient reçus en vue de ce projet. En clair il s'agit de mettre le personnel fonctionnel dans les conditions idéales, à la limite du possible, afin qu'il se sente associé, valorisé et encouragé.
I.4.3.7.- Flexibilité
La planification devra être assez flexible pour permettre au personnel de s'acquitter également des tâches traditionnelles et quotidiennes de la bibliothèque ou de leur organisation respectives. Il en est de même pour la flexibilité dans les délais. Il s'agit ici d'affecter aux tâches des délais raisonnables afin que les personnes à charge disposent du temps suffisant pour des résultats sans faille, ni stress inutile! Les engagements extérieurs seront aussi à prendre en compte, ainsi que des besoins particuliers de nos congrégations et/ou de l'Église locale (pour la soeur et le père!)
I.4.3.8.- Relations avec le CEMAT
Si ce qui n'était qu'un rêve du directeur semble pouvoir se concrétiser, le mérite principal revient à messieurs Karim HAMDY et Riadh SAADAOUI du CEMAT, qui sont aussi désireux que nous de voir ce projet se réaliser. Concrètement, ils nous ont déjà donné l'occasion de travailler une semaine avec monsieur Steve BAKER, de Microsoft, semaine qui a marqué le début du projet, tant par les conseils techniques que par le début d'une amitié qui, nous l'espérons, se consolidera, comme le projet, avec le temps.
Il nous incombe donc, non seulement par simple politesse mais aussi par respect et gratitude à leur égard , de les tenir informés des avancées du projet.
Tableau récapitulatif des facteurs de réussite
Facteurs
Fonctions
Implication des acteurs
- Une bonne entente entre les différents acteurs du projet.
- Le chef du projet doit mettre tout en œuvre afin d'entretenir de bonnes relations avec ses interlocuteurs.
- Diplomatie, tact mais aussi autorité .
Respect des délais
- Permet d'éviter les blocages et arrêts à une étape du processus
- Garde le projet en route.
Définition des rôles
- Permet d'éviter les problèmes de conflits d'attribution.
- Instaurer, un régime de responsabilité.
Communication
- Une mauvaise communication peut être source de conflits.
- Communiquer en temps réel à la hiérarchie les différents problèmes rencontrés.
- La communication favorise aussi l'instauration d'une bonne ambiance de travail et permet aux uns et autres de travailler en toute confiance.
Motivation
- Un personnel motivé se libère très facilement de ses tâches.
- La motivation passe par l'implication de la hiérarchie dans le projet et dans toutes les tâches, mais aussi par la reconnaissance des efforts fournis par les un et les autres.
- Des avantages matériels et pécuniaires pourraient aussi suivre.
Flexibilité
- La planification devra être assez flexible.
- Flexibilité dans les délais de réalisation. Il s'agit ici d'affecter aux tâches des délais raisonnables afin que les personnes à charge disposent du temps suffisant pour des résultats sans faille.
I.5.-Besoins
Nous sommes conscients de l'importance de ce projet et de la pauvreté de nos moyens, ainsi que des mises en garde signalées dans les forums. D'autre part, nous sommes convaincus qu'à travers les expériences antérieures d'autres utilisateurs, le partage de leurs questions et solutions mises en ligne, ainsi que les réponses apportées aux questions posées dans les forums et l'esprit général du monde des logiciels libres, nous permettront de mener ce projet à terme.
Sans oublier, bien entendu, les offres d'aide, spontanées ou sollicitées, que nous recevons et continuerons certainement de recevoir de la part de connaissances, amis, ou gens de passage.
La réussite espérée de ce projet, dont nous mettrons le développement des différentes étapes en ligne, pourra aussi être un encouragement pour d'autres personnes responsables d'une bibliothèque dont les moyens pourraient être aussi modestes que les nôtres.
La collaboration souhaitée avec un institut de formation tunisien et la présence éventuelle de futurs coopérants ou personnes au service du diocèse nous incite à nous référer, une fois encore, à l'excellent rapport de monsieur Hounkpe, tout en les adaptant à la dimension et aux spécificités de notre bibliothèque.
La réalisation de ce projet de mise en ligne du catalogue et de l'automatisation du prêt requiert des ressources, tant humaines, financières que matérielles et technologiques.
I.5.1.- Ressources humaines : profils-type
Documentaliste bilingue français-arabe ayant une assez large culture historique et religieuse, spécialement dans le domaine de l'antiquité, du christianisme et de l'islam : révision, normalisation et concordance d'un nouveau thésaurus simplifié; révision et normalisation des noms propres arabes;
Aide-bibliothécaires : travaux d'inventaire du fonds; numérisation de tables des matières;
Informaticien spécialisé en Base de Données et serveur : installation, configuration de KOHA sur un serveur-hôte à trouver;
Sans oublier les geeks qui se porteraient volontaires!
I.5.2.- Ressources matérielles et technologiques :
Logiciels :
KOHA
Winisis
Utilitaires ISIS et MARC21: SwissKnife, CpConverter, MarcEdit
OCR utilisable pour l'arabe, à trouver...
Ordinateurs (développement + terminaux de consultation)
Serveur Web (Hébergement et mise en ligne du catalogue)
Disque dur externe pour le backup
[ Lecteurs de code à barre - pas dans l'immédiat]
[ Etiquettes de codes à barre - pas dans l'immédiat]
Fournitures bureautiques
Un scanneur de bureau (numériser les photos des usagers)
I.5.3.- Ressources financières
Budget pour l'acquisition des matériels non disponibles dans la bibliothèque: disque dur externe, lecteurs et étiquettes de code à barre - pas dans l'immédiat
Motivation des personnes extérieures impliquées dans le projet.
I.5.4. Tableau récapitulatif des ressources nécessaires
Nature de la ressource
Contenus
Observations
Ressources Humaines
Documentaliste
Aide-bibliothécaire
Informaticien programmeur
Informaticien spécialisé en Base de Données et serveur : installation, configuration de KOHA sur le serveur
gestion des fonctions bibliothéconomiques, fonctions avancées de Winisis en vue de l'élimination des doublons de la base de données sous Winisis ;
travaux d'inventaire du fonds, équipement des documents de codes à barre et rangement des documents sur les rayonnages ;
écriture d'une application de récupération de la base de données sous Winisis
écriture d'une application de récupération de la base de données sous Winisis
Ressources Matérielles et Technologiques
Logiciels
Ordinateurs
Serveur Web
Disque dur externe
Lecteurs de code à barre
Etiquettes de codes à barre
Fournitures bureautiques
Un scanneur de bureau
Appareil pour la plastification etc.
KOHA, Winisis, Application de récupération de la base Winisis
développement + terminaux de consultation
Hébergement et mise en ligne du catalogue
Backup
Prêt des documents
Attribution d'identifiant unique aux documents
Tâches administratives et bureautiques
Numériser les photos des usagers
Plastification des cartes de lecteurs
Ressources financières
Budget pour l'acquisition des matériels non disponibles dans la bibliothèque
Motivation des personnes extérieures impliquées dans le projet
Disque dur externe, lecteurs et étiquettes de code à barre etc.
SECONDE PARTIE: ASPECTS TECHNIQUES
Afin d'éviter d'entrer dans trop de détails techniques dans ce document, nous les ajouterons sur notre site, au cas où ils vous intéresseraient.
Vous pourrez suivre le développement de ce projet sur notre site (http://bibsr.ucoz.com ) où nous nous efforcerons de maintenir un cahier de bord, dans la section "Projet Koha"
II.1.- Opérations subséquentes à la réalisation du catalogue sous Koha
II.1.1.- Révision et corrections des structures des base de données
Elles seront effectuées pour chacune des bases à partir du diagnostic qui sera fourni par l'utilitaire SWK (Onglet: Tomographie de la base de données)
II.1.2.- Conversion aux normes MARC 21 et en code UTF-8
Nous nous aiderons des documents déjà trouvés sur les forums et, au moyen des utilitaires téléchargés, nous devrions y arriver sans trop de problèmes, sous réserve que le codage de l'arabe ne nous pose rop de difficultés. Dans cete hypothèse, nous rechercherons à nouveau sur les forums et prendrons contact avec des bibliothèques qui ont réussi à passer ce cap.
II.1.3.- Réutilisation de la base bilingue THES (thésaurus) à étudier
En soi, cela justifierait un projet séparé.
Nous espérons avoir pour cela l'expertise et l'aide d'enseignants et/ou stagiaires d'instituts de formation en documentation ou archives...
II.2.- Plate-forme technique
II.2.1.- Outils sous licence libre
Afin de permettre une parfaite intégration de toutes les fonctions et tâches bibliothéconomiques au sein d'un seul et même système intégré de gestion de base de données, et de profiter de la gratuité de la plupart des logiciels et notamment des moteurs de base de données disponibles pour un ordinateur individuel (phase de test!), sur intranet et sur Internet, nous avons fait le choix d'utiliser KOHA qui est un logiciel libre multiplateforme. Koha tourne sur et avec des outils sous licence libre uniquement et sur un environnement 100% web.
Dans le cadre de notre projet, nous allons installer sur la machine de test la distribution Ubuntu 9.10 (Karmic) de Linux avec un bureau Gnome, ainsi que le gestionnaire de langues pour un système bi-directionnel (gauche-doite, droite-gauche).
En ce qui concerne le choix du moteur de base de données, l'une des offres les plus complètes en terme de fonctionnalités et des plus performantes est le moteur de base de données MySQL. Koha stocke ses données dans le Système de Gestion de Base de Données (SGBD) qui convient à l'utilisateur, par exemple :
- MySQL 5.1
- PostgreSQL
Pour avoir MySQL, nous allons installer un serveur Web local qui est Apache. L’installation de KOHA requiert aussi Perl et d’autres dépendances, tous téléchargeable gratuitement.
- Le navigateur utilisé est Mozilla Firefox.
- Des logiciels tiers ont été utilisés lors du développement. Leur choix respecte l’esprit du libre. Ainsi pour le traitement des images nous avons utilisé « The Gimp » etc., pour l'utilisation des fichiers numérisés Greenstone, pour la récupération de notices au cours de recherches sur le net Zotero,...
II.2.2.- Fonctionnalités de Koha utilisées
En tant que SIGB, Koha offre la plus part des fonctions bibliothéconomiques et de gestion d’une bibliothèque. La page d’accueil de l’environnement du bibliothécaire de Koha, accessible par login et mot de passe, présente ses fonctionnalités, et aussi les fonctionnalités de paramétrage et de personnalisation.
Acquisitions
Catalogage
Lecteurs
Circulation
OPAC pour l'accès public
II.2.3.- Interface graphique de l’OPAC
II.2.3.1- Objectif
Le rôle d'une interface graphique est de rendre une application facile d'utilisation, intuitive, tout en ne ralentissant pas, voire en accélérant, les traitements et les saisies .
II.2.3.2.- Présentation graphique de l’OPAC
Étant donné que l'OPAC sera la vitrine de notre catalogue, un soin particulier lui sera accordé.
La couleur sera à choisir, et un logo à inventer?
Pour faciliter le chargement de la base et la navigation dans les menus, il sera essentiel de faire très peu usage d'images sur l'OPAC.
L'OPAC offrira, non seulement à travers les différentes collections thématiques, une vue panoramique de la diversité du fonds documentaire, mais aussi des accès aux documents soit par auteur, soit dans le titre ou mieux au niveau des vedettes matières.
L’OPAC fournira en plus de l’accès au catalogue, des informations pratiques aux utilisateurs. Il fait donc en même temps office de site web pour la bibliothèque.
Le menu identification permettra au usagers d'entrer dans le catalogue avec un login et un mot de passe personnel attribué lors de l'inscription.
II.2.4.- Gestion des préférences système
Nous prendrons autant que faire se peut les valeurs par défaut, et nous indiquerons sur notre site les valeurs modifiées tout en justifiant notre choix.
Webographie et bibliographie
Toutes les références que nous avons déjà utilisées ou que nous utiliserons en cours de route seront indiquées dans les groupes Zotero que nous avons créés ou auxquels nous participons (Voir les liens sur notre site http://bibsr.ucoz.com)
Conclusion
Un projet trop ambitieux pour nos moyens? Peut-être, l'histoire nous le dira.
Notre confiance en la possibilité de rencontre de personnes qui seront peut-être amené(e)s, sur place ou à distance, est-elle exagérée ou illusoire? Nous verrons, mais nous voulons en courir le risque.
Notre but est loin de parvenir à réussir l'une ou l'autre "prouesse" technique, qui ne servirait qu'à booster notre orgueil.
Ce projet, commencé suite à une rencontre avec les directeurs du Cemat, est vu comme un moyen de parvenir à mieux servir nos lecteurs et chercheurs mais aussi à être une forme d'encouragement pour d'autres personnes responsables de petites bibliothèques à prendre le risque du "logiciel libre" et à pouvoir ainsi garder leurs ressources pour l'acquisitions de livres ou autres documents au service de la rencontre de l'autre par le biais de la culture.
Note importante et remerciement 1
Résumé 3
Mots-Clés 4
Sigles, acronymes, logiciels gratuits 5
Introduction : but et rôle de la bibliothèque 6
PREMIÈRE PARTIE: PRÉSENTATION GÉNÉRALE DU PROJET 8
I. Situation présente 8
I.1.- Contexte et justification du projet 8
I.1.1.- Contexte et existant 8
I.1.2.- Justification du passage à un système informatique plus performant 8
I.1.2.- Objectif du projet 9
I.1.2.1.- Objectif global 9
I.1.2.2.- Objectifs spécifiques 9
I.1.3.- Bénéficiaires 10
I.1.4.- Faisabilité 10
I.1.4.1.- Compétences et ressources humaines 10
I.1.4.2.- Ressources matérielles 11
I.1.4.3.- Ressources logicielles 11
I.1.5.- Opportunités 12
I.1.6.- Risques 12
I.2.- Description fonctionnelle 13
I.2.1- Résultats attendus 13
I.2.2.- Choix du Système Intégré de Gestion de Bibliothèque (SIGB) 14
I.2.2.1- Normes et standards 14
I.2.2.2.- Modules et fonctions [Repris intégralement du rapport de Mr Hounkpe, sauf ce qui est en italique] 14
I.2.3.- Revue des SGB gratuits étudiés par Mr Hounkpe 15
I.2.4.- Synthèse et choix du logiciel 16
I.2.5- Choix du format de catalogage 16
I.3.- Mode de développement 17
I.3.1.- Développement sur ordinateurs de test 17
I.3.2.- Développement sur serveur de production 17
I.3.4.- Découpage des modules en phases 18
I.3.6.- Tableau synoptique de découpage des activités 19
I.4.- Identification des intervenants 20
I.4.- Contraintes et planification 21
I.4.1.- Contraintes 21
I.4.2.- Planification du projet 24
I.4.2.1.- Liste des tâches 24
I.4.2.2.- Tableau de répartition des tâches 25
I.4.3.- Facteurs de réussite 26
I.4.3.1.- Implication des acteurs 26
I.4.3.3.- Délai et finalisation des tâches 26
I.4.3.4.- Définition des rôles 26
I.4.3.5- Communication 26
I.4.3.6.- Motivation 26
I.4.3.7.- Flexibilité 27
I.4.3.8.- Relations avec le CEMAT 27
I.5.-Besoins 29
I.5.1.- Ressources humaines : profils-type 29
I.5.2.- Ressources matérielles et technologiques : 30
I.5.3.- Ressources financières 30
I.5.4. Tableau récapitulatif des ressources nécessaires 30
SECONDE PARTIE: ASPECTS TECHNIQUES 32
II.1.- Opérations subséquentes à la réalisation du catalogue sous Koha 32
II.1.1.- Révision et corrections des structures des base de données 32
II.1.2.- Conversion aux normes MARC 21 et en code UTF-8 32
II.1.3.- Réutilisation de la base bilingue THES (thésaurus) à étudier 32
II.2.- Plate-forme technique 33
II.2.1.- Outils sous licence libre 33
II.2.2.- Fonctionnalités de Koha utilisées 33
II.2.3.- Interface graphique de l’OPAC 34
II.2.3.1- Objectif 34
II.2.3.2.- Présentation graphique de l’OPAC 34
II.2.4.- Gestion des préférences système 34
Webographie et bibliographie 34
Conclusion 35