entête
entête

Réinformatiser la bibliothèque municipale... Pourquoi ?

Marc Maisonneuve

Les projets d’informatisation sont généralement relativement longs. Entre les préliminaires qui doivent emporter la décision de la ville, les appels d’offres en procédure européenne, la mise en œuvre et les inévitables premières mises au point, il s’écoule bien souvent deux à trois ans.

Tout cela étant fait, on pourrait souhaiter conserver son système une bonne décennie. De plus, tout projet est porteur de risques multiples. Se réinformatiser, c’est encourir des risques de solution technique inadaptée, de dérapage dans les coûts, d’interruption prolongée du fonctionnement de l’établissement... Bref, cela fait beaucoup d’arguments en faveur du statu quo.

Y a-t-il véritablement dans ces conditions un mouvement de réinformatisation des bibliothèques muni- cipales ? De quelle ampleur ? Pourquoi les BM changent-elles de système ? Enfin, quelles difficultés rencontrent-elles dans ces entreprises ?

Un mouvement massif de réinformatisation

La Direction du livre et de la lecture a publié en 1996 une brochure sur L’équipement informatique des bibliothèques municipales et départementales 1. Très complète, celle-ci rend compte d’une enquête quasi exhaustive auprès des bibliothèques de lecture publique. Elle permet de dégager des données précises sur l’ampleur de la réinformatisation. Ainsi, l’enquête recense 108 bibliothèques municipales qui ont déjà changé de système. L’analyse du taux d’informatisation des bibliothèques (cf. schéma 1) montre qu’aujourd’hui les fournisseurs sont confrontés à un marché comprenant deux segments bien délimités :

– les bibliothèques des villes de moins de 10 000 habitants ne sont équipées que dans un cas sur trois et ce depuis peu. Pour ces petites bibliothèques, le marché est dominé par les projets de première informatisation ;

– dans les villes de plus de 20 000 habitants, les bibliothèques sont équipées dans au moins trois cas sur quatre. La quasi-totalité des bibliothèques des villes de plus de 50 000 habitants sont maintenant informatisées.

L’enquête de la DLL date avec précision l’informatisation des bibliothèques ; elle montre également que les établissements garderaient leur système de 7 à 9 ans environ. Sur ces bases, il est facile de prévoir l’ampleur du mouvement de réinformatisation pour les deux à trois ans à venir.

Le schéma 2 représente les bibliothèques dont l’informatisation précédente s’est située entre les années 80 et 1991. Ce sont les candidates à une prochaine réinformatisation : 200 bibliothèques municipales devraient changer de système d’ici l’an 2000. Compte tenu de la taille de ces établissements, aucun doute ne peut demeurer. Le marché de la réinformatisation va dépasser très largement en montant celui des premières informatisations.

Une convergence d’intérêts

Qu’est-ce qui pousse les bibliothèques à changer de système ? Panne définitive ? Incompatibilité d’humeur avec le fournisseur ? Engouement pour Internet ?

Ce n’est pas parce que le système vieillit qu’il devient mauvais. Les fonctions qui étaient les meilleures vont bien souvent continuer à donner le même niveau de satisfaction. De multiples facteurs enclenchent le processus de réinformatisation 2. De notre point de vue, la décision de changer de système résulte d’une convergence des intérêts des fournisseurs, des services informatiques et des bibliothèques municipales.

La pression du marché

Parmi les facteurs externes à l’origine d’une réinformatisation plus ou moins choisie par la bibliothèque, les fournisseurs arrivent en tête de liste. Trois cas de figure peuvent se présenter :

– le fournisseur disparaît ou se fait racheter : CLSI et Odis NV ont été rachetés par Geac, ISL est en faillite...

– le progiciel n’est plus commercialisé ou n’évolue plus : Glis 8000 et Glis 9000, SDL*Média, Tobias, Dobis-Libis, Libs100, ALS...

– la société de services met sur le marché un nouveau produit et incite à effectuer une migration interne : AB6 en remplacement de SDL*Média, Orphée dans la foulée de Tobias, Opsys V8, Meritus ...

Des informaticiens en quête de standards

De même que les fournisseurs, les services informatiques semblent être des acteurs déterminants. Ils vont souvent hâter la prise de décision. Leurs arguments sont généralement très forts.

La maintenance d’un vieux système coûte de plus en plus cher. C’est également un argument repris par les fournisseurs pour stimuler les migrations internes : « Prenez la nouvelle version du progiciel, vous gagnerez 40 % sur le coût de maintenance ».

L’exploitation devient de plus en plus complexe et coûteuse. Les difficultés rencontrées sont de ce point de vue très variées. Il peut s’agir d’un problème de matériel avec une dégradation des performances sans possibilité d’ajustement de la configuration. Mais, le plus souvent, le problème concerne les compétences que doit maintenir le service informatique pour assurer la continuité de fonctionnement du système. En 7 à 8 ans, les standards de l’informatique ont considérablement évolué. Il paraît de plus en plus insupportable de maintenir un système Pick, alors que tous les services de la ville ont migré vers un environnement Unix ou Windows NT. Ce décalage par rapport aux standards du marché concerne à peu près la moitié du parc installé, c’est-à-dire une bibliothèque sur deux (cf. schéma 3).

C’est essentiellement de ce point de vue – maintien de compétence de plus en plus isolée – qu’un vieux système finit par coûter de plus en plus cher. Les services informatiques sont donc très intéressés par la réinformatisation. Le plus souvent, leur démarche s’inscrit dans le cadre plus général d’un schéma directeur informatique, qui définit l’environnement technique des nouveaux systèmes. C’est ainsi que des directives d’équipement soulignent la nécessité de retenir tel ou tel système d’exploitation (Unix, Windows NT...), tel ou tel SGBDR (Système de gestion des bases de données relationnelles, comme Oracle, Informix, Sybase)...

La recherche de nouvelles fonctionnalités

Les bibliothèques sont bien entendu les principaux acteurs du changement de progiciel. Sont-elles toujours satisfaites du système installé ? Rien n’est moins sûr. La brochure de la Direction du livre et de la lecture contient un bilan de l’utilisation des différentes fonctions. Elle fait ressortir ce qui semble être des insuffisances des systèmes installés.

Les bibliothèques n’utilisent les modules d’acquisition que dans un cas sur deux. Seul un système sur deux serait doté d’un chargeur de notices capable de récupérer des notices Unimarc. La très grande majorité des systèmes installés seraient dépourvus de fichiers d’autorité et de module de diffusion sélective d’information (liste personnalisée d’acquisitions, c’est-à-dire établie sur profil). Seule une bibliothèque sur trois propose la consultation de son catalogue sur Minitel.

L’impossibilité d’offrir la consultation du catalogue sur Internet doit constituer une cause majeure d’insatisfaction car, utile ou pas, cette fonctionnalité est très demandée par les élus.

Le passage à l’Euro (les administrations seront les premières concernées : budget en Euro, amendes en francs pendant la période de transition de 3 à 4 ans) et le changement de millénaire (qui pose d’insolubles problèmes aux systèmes qui mémorisent ou traitent seulement les deux derniers chiffres des années) sont deux arguments supplémentaires qui pourraient hâter le changement de certains systèmes.

L’enrichissement de l’offre de progiciels

Depuis la première vague d’informatisation, l’offre a considérablement évolué. Le marché s’est ouvert. Quelques systèmes français sont diffusés à l’étranger et de nombreux systèmes arrivent de tous les pays (cf. schéma 4). Les nouveaux systèmes nous viennent aussi bien d’Amérique, d’Asie que d’Océanie !

Cette ouverture du marché s’est accompagnée de facto d’un enrichissement des fonctionnalités offertes. Une société étrangère qui diffuse sur le marché français attend de disposer d’un produit qui a atteint une certaine maturité. Parfois un peu anciens, ces systèmes sont généralement très complets. Ainsi possèdent-ils généralement un module Web ou même Z39.50 (mais pas nécessairement en version 3).

En 1997, les bibliothèques municipales disposent d’une véritable marge de manœuvre dans le choix des systèmes. Français ou étrangers, ceux-ci offrent des fonctionnalités qui n’étaient pas disponibles au moment du premier équipement : module Web, gestion de la communication indirecte (fonds d’étude), diffusion sélective de l’information, automate de prêt en libre-service... Enfin, ils permettent de mieux respecter les normes bibliothéconomiques et celles de translittération... Voilà de quoi répondre à la demande des bibliothécaires peu satisfaits de leurs vieux systèmes.

En bref, l’ancienneté des systèmes, la mondialisation du marché, la meilleure prise en compte des normes informatiques et techniques, la rationalisation des moyens informatiques et même l’avancée de la construction européenne... sont autant de facteurs qui vont stimuler fortement le marché de la réinformatisation. Que ceux qui redoutaient l’inévitable soient donc tranquilles : ils n’auront bientôt plus le choix. Après 7 ou 8 ans d’utilisation, il va leur falloir changer de système. Une nouvelle aventure commence.

Les tribulations des futurs aventuriers

Puisque les directeurs des bibliothèques municipales sont déjà initiés, je n’insisterai pas sur les joies habituelles d’une première informatisation... Voyons simplement quelques particularités de la réinformatisation.

Une démarche système d’information

Le cadre technique des nouveaux projets se résume en trois mots : standards, ouverture et démarche progiciel. L’heure n’est plus au système monolithique qui saurait couvrir l’intégralité des fonctions d’une bibliothèque. L’informatique de la bibliothèque municipale, en tout cas pour les établissements d’une certaine taille, va faire appel à plusieurs progiciels et plusieurs serveurs. Le schéma 5 présente les principales briques de cet ensemble :

– le système de gestion de bibliothèque, élément central qui prend en charge les fonctions de gestion, de catalogage et éventuellement l’OPAC ;

– les automates de prêt en libre-service ;

– les OPAC vidéotex, Web ou Z39.50 version 3 ;

– les systèmes de communication de publications numériques : cédérom, CD-I, DVD (Digital Versatile Disc)...

– les systèmes sécurisés offrant l’accès à une sélection de services Internet ;

– les systèmes de numérisation, de gestion et de communication de documents primaires retraités par la bibliothèque (par exemple, pour la communication de dossiers thématiques de presse) ;

– les postes multimédias offrant l’accès à tous les services, depuis la consultation du journal en ligne contenant quelques pages de présentation de la bibliothèque ou du catalogue jusqu’à la consultation de cédéroms ou de services Internet ;

– les multiples systèmes de sécurité informatique (serveur « pare-feu »), ou physique (système antivol, système de contrôle des accès...).

L’informatique de la bibliothèque est donc un ensemble de progiciels et de serveurs qui vont s’appuyer sur une infrastructure de communication (le réseau local) et qui vont devoir coexister ou même échanger des informations.

Dans ce cadre, la difficulté principale est la conception d’une architecture technique avec le choix des normes informatiques et documentaires associées et la définition des interfaces. Par rapport aux premières informatisations des années 80 à 90, il y a déplacement de la complexité des projets. La technique et les services informatiques vont occuper une place-clé dans la définition du projet. Le bibliothécaire lui-même sera davantage sollicité pour se pencher sur des problèmes qui se trouvent au croisement de l’informatique et de la bibliothéconomie. Il peut s’agir de la définition d’interfaces de chargement de cédéroms (par exemple pour les fichiers d’autorité) ou de récupération de notices d’un réseau de catalogage. Cela peut concerner aussi le choix d’une interface utilisateur pour la mise sur Internet du catalogue de la bibliothèque (Telnet, Web ou Z39.50 version 3).

Le cadre informatique de cette fin de siècle est le premier nouveau facteur de complexité. La prise en compte des enjeux associés à ce cadre n’est pas chose facile. Le directeur doit de plus en plus disposer d’une solide culture informatique. Ce n’est pas le seul point délicat.

Réussir à coup sûr

Il s’agit de réussir dès la première tentative et sans interruption de service.

La bibliothèque municipale informatisée depuis 5 à 10 ans a généralement stabilisé son informatique. Les lecteurs se sont habitués à la rapidité des transactions de prêt et ont adopté l’OPAC (ce qui ne signifie pas qu’ils savent s’en servir). Leur niveau d’exigence s’est progressivement élevé. Le changement de système doit apporter des améliorations à moyen terme et surtout limiter les perturbations de service lors du basculement.

Évitons de commencer une nouvelle ère de l’informatisation de la bibliothèque par une interruption prolongée et non maîtrisée du prêt. C’est là une contrainte forte de la réinformatisation 3, qui souligne la perte d’une marge de manœuvre, par rapport à la première opération d’informatisation.

Du côté des élus, le niveau d’exigence risque d’être également plus élevé. Le coût du projet, la participation du service informatique et le fait qu’il s’agit d’une deuxième informatisation imposent le « sans-faute ». En cas de gros pépins, les élus seront peut-être moins compréhensifs qu’il y a dix ans. La latitude est donc beaucoup plus étroite que lors de la première informatisation.

Ces considérations soulignent la nécessité d’une gestion rigoureuse du projet, intégrant l’existence de risques divers et la recherche de mesures de prévention ou de protection. L’enjeu de ces mesures est la maîtrise des performances et des résultats, des coûts et des délais...

Un autre facteur de complexité se conjugue avec cette réduction des marges de manœuvre : le projet dépasse très largement le cadre de la sous-traitance. Toute une partie des tâches échoit à la bibliothèque et à elle seule. Outre le suivi des contrats, la BM prend en charge la préparation des fichiers à reprendre, les opérations de contrôle des prestations de reprise des fichiers, l’encadrement des opérations de basculement d’un système sur l’autre, qui reposent autant sur des solutions organisationnelles de gestion des flux des retours que sur des dispositifs sophistiqués de reprise des fichiers...

Autant la première informatisation pouvait se dérouler de manière légèrement improvisée dans le sillage de l’intervention du fournisseur, autant la réinformatisation nécessite une véritable maîtrise d’œuvre, dont les mots clé sont planification, anticipation, coordination et suivi. Plus que jamais, la réussite dépend de la qualité de la structure de projet interne, au sein de laquelle le chef de projet et le directeur vont jouer un rôle central.

Récupérer les données

Que vaudrait le meilleur progiciel du monde sans les données décrivant le catalogue de la bibliothèque ?

La récupération des données est une condition nécessaire à la mise en service des fonctionnalités de gestion du prêt et de consultation du catalogue. Tant qu’elle n’est pas achevée et réussie, aucun basculement n’est possible. L’enjeu financier de cette reprise peut s’apprécier à 10 F environ pour faire ressaisir chacune des notices qui n’aurait pu être récupérée. Un échec de la reprise représenterait un coût qui dépasserait bien souvent le million de francs... et parfois le million d’Euros.

Il faut donc récupérer ces données et essayer d’obtenir un engagement sérieux du fournisseur sur ce point. Si possible, avant notification du marché. Cette reprise des données pose à la fois des problèmes juridiques et techniques. Pour reprendre des informations, il faut être capable d’en décrire le format, le contenu et les méthodes de codification (sans parler du jeu de caractères informatiques employé 4).

Le fournisseur de l’ancien système dispose de ces informations, prêtes à l’emploi, mais, pour garder un avantage concurrentiel, il risque fort d’en refuser la communication. C’est un conflit de propriété. La bibliothèque est propriétaire des données et l’auteur de l’ancien progiciel propriétaire des programmes et de la documentation technique. Ce conflit peut être traité fort simplement si les bonnes clauses d’accès à la documentation technique ont été incluses dans le cahier des charges initial 5. A défaut, il faut engager une procédure qui officialisera le refus du fournisseur et qui, sur cette base, permettra d’essayer de reconstituer soi-même les informations manquantes.

Bâtir un cahier des charges

Compte tenu des sommes qui sont en jeu, l’appel d’offres en procédure européenne va être la règle et la négociation de gré à gré avec le fournisseur de l’ancien système pour une migration interne la très rare exception. L’acheteur public a de nombreuses obligations, dont celle de garantir l’égalité de traitement et de chance des fournisseurs.

Il faut donc, pour la reprise des données, publier la documentation technique de tous les fichiers à reprendre sur le nouveau système (dessin d’enregistrement, contenu des zones et codifications employées). A cette condition vous pourrez parvenir à un engagement valide d’obtention de résultats et cela dans un cadre forfaitaire. A défaut de publication de ces éléments, sachez qu’il ne sert à rien d’exiger tel ou tel engagement de résultats. Les tribunaux jugeraient que vos exigences sont excessives, car allant au-delà des règles de l’art en la matière.

Ce développement sur la reprise des fichiers souligne la complexité des cahiers des charges de réinformatisation. D’autres exemples pourraient être cités, notamment les conditions de légitimité d’une clause de cession des droits de propriété des développements spécifiques ou même les conditions de validité d’une clause d’accès 6 aux programmes source et à la documentation technique. En fait, la rédaction d’un cahier des charges de réinformatisation, dans ses parties administratives et techniques, se trouve au croisement de plusieurs domaines de compétence :

– connaissance du Code des marchés publics, de la loi sur les droits de l’auteur d’un logiciel, de la jurisprudence des contrats informatiques ;

– connaissance des droits et des obligations du maître d’ouvrage (la ville) et du maître d’œuvre en matière de marché de progiciel ;

– connaissances informatiques et bibliothéconomiques ;

– pratique de la rédaction des marchés publics.

C’est la mise en œuvre de ces compétences qui permet une maîtrise des principaux risques (solution technique inadaptée, dérapage dans les coûts ou dans les délais...).

Choisir la bonne offre, pas simplement le bon système

Pourquoi est-ce différent de la première fois ? Voyons, au travers de quelques exemples, la nécessité d’effectuer aujourd’hui un choix de synthèse qui va relativiser l’importance des fonctionnalités du progiciel, alors que c’était la préoccupation dominante sinon unique lors du premier équipement.

Le marché s’est mondialisé. Il faut prendre en compte les aspects négatifs de cette situation. Vous allez être confrontés à des diffuseurs. Tous ne maîtrisent pas complètement le progiciel qu’ils proposent. Il faut valider les compétences des intervenants et, parfois, dans le cas d’une première implantation, celles de la société française.

Le marché est très difficile. Dans l’enquête publiée par Livres Hebdo 7, j’avais constaté que seulement 6 sociétés sur 26 dégageaient un bénéfice. Des sociétés françaises ou étrangères déposent leur bilan, sont rachetées ou liquidées. Les offres doivent permettre d’apprécier la solidité des sociétés, leur niveau d’engagement sur le marché français et prévoir les dispositions qui permettront d’assurer la continuité du fonctionnement du système dans ces cas extrêmes.

Le nouveau cadre informatique (réseaux locaux, SGBDR, architecture client-serveur...) complique de fait, même si cela paraît curieux, la maîtrise des performances. Peut-on accepter un système dont le temps moyen d’enregistrement d’un prêt est compris entre 5 et 8 secondes ? A la banque de prêt, les queues du samedi ou du mercredi seraient alors deux à trois fois plus longues. L’engagement sur les performances, temps de réponse et taux de disponibilité8, est un critère de choix déterminant.

Peut-on retenir la société qui propose un simple accord de partenariat pour la reprise des données, sans aucun engagement forfaitaire, ni engagement d’exhaustivité de la reprise (« Nous sommes partenaires, faites-nous confiance ! ») ?

Peut-on retenir le progiciel qui fonctionne sous un système d’exploitation propriétaire, si la ville vient de choisir un standard du marché ? Si vous dites oui, il y a fort à parier que les informaticiens vont vous laisser vous débrouiller avec votre système.

Une offre, c’est une société, un engagement de fournir les résultats et les performances demandés, un progiciel, une adéquation avec le cadre technique, un prix et un coût d’utilisation... Se réinformatiser, c’est choisir la meilleure offre en tenant compte non seulement des fonctionnalités du progiciel, mais aussi de tous ces éléments. Certes le choix est plus large aujourd’hui qu’en 1985, mais est-il pour autant plus facile ?

En fait, la problématique du choix n’a plus rien à voir. La réflexion sur les critères de choix appelle de nombreuses questions. Faut-il acheter un produit français récent correspondant peut-être à un moindre investissement et donc peut-être à des fonctions encore limitées ? Faut-il lui préférer un progiciel étranger ancien, mais validé et complet ? Quel poids faut-il donner à la technique informatique ? Comment concilier les priorités de la BM qui s’expriment en termes de services, de fonctions, de normes bibliographiques et les justes attentes des informaticiens ?...

Repérer les chausse-trappes des soumissionnaires

Après avoir défini, dans les affres de l’incertitude, l’architecture technique et les critères de choix les plus opportuns, après avoir rédigé un cahier des charges dans les règles de l’art, il reste à choisir l’offre la meilleure. Commence donc le dépouillement de l’appel d’offres. Au-delà des difficultés évoquées ci-dessus, ces travaux de dépouillement vont devoir prendre en compte un ensemble de pratiques bien désagréables quoique légitimes. Les règles du jeu sont archisimples. Trois d’entre elles résument bien le jeu du chat et de la souris auquel vous allez vous livrer.

Règle n° 1 : à chaque fois que vous allez essayer d’obtenir un engagement forfaitaire, le soumissionnaire va tenter d’instiller une dose de régie.

Règle n° 2 : à chaque fois que vous allez imposer l’engagement de résultat, le soumissionnaire va le transformer par un tour de passe-passe en un simple engagement de mise en œuvre de moyens.

Règle n° 3 : à chaque fois que vous pensez maîtrise des coûts, le soumissionnaire pense maîtrise de son risque financier.

Ces règles résultent d’une longue pratique des travaux de dépouillement des appels d’offres. Pour être plus convaincant, voici quelques-uns des trucs les plus employés.

Règle n° 1 : du faux forfait, de la vraie régie

L’offre commence par des propos rassurants : « Le soumissionnaire s’engage à reprendre tous vos fichiers pour un montant ferme et définitif ». Plus loin, en petits caractères, noyés dans une offre de 300 pages, on apprend que l’engagement s’entend dans la limite de 100 000 notices et, bien entendu, votre catalogue en comprend 213 000. Si vous laissez passer cela, lors de l’exécution de la prestation, le titulaire du marché vous tiendra à peu près ce langage : « On renégocie ou je m’arrête à la 100 000 ».

Une variante bien plus sournoise : le soumissionnaire inclut les droits d’utilisation des chargeurs ou les développements spécifiques pour la reprise des fichiers, mais pas les prestations pour effectuer cette reprise. Or, ni le service informatique, ni, à plus forte raison, la bibliothèque ne sont en mesure de mettre en œuvre ces programmes. Confrontée à une telle situation, la bibliothèque d’un musée national parisien s’est résignée à mettre en œuvre elle-même le chargeur standard de notices Unimarc pour charger une bande de conversion rétrospective. Surprise ! Ce chargeur traite environ une notice par minute. Pour les 120 000 notices à traiter, le système de gestion de bibliothèque aurait été immobilisé pendant 2 000 heures, soit 83 jours !

Est-il nécessaire d’ajouter que la bibliothèque a dû négocier, si on peut parler de négociation lorsque les termes des rapports de force sont à ce point déséquilibrés, avec son fournisseur. Hors marché et de gré à gré, celui-ci lui a certainement fait, vous en êtes convaincus, une offre très intéressante.

Règle n° 2 : de faux engagements de résultat

Pour la reprise des fichiers, après un engagement ferme d’obtenir une récupération exhaustive des informations, vous trouvez 215 pages plus loin la mention suivante. « Prestations (sic) du client. Le client met en forme les données à reprendre. Il crée des fichiers texte sans zone packée, ne contenant que des enregistrements vivants ». Si vous, client, n’êtes pas capable de le faire et si vous avez laissé passer cette disposition, l’engagement d’exhaustivité de la reprise, voire le forfait lui-même, vont tomber.

Pour les temps de réponse, la société s’engage, mais en proposant des conditions d’exploitation du système qui ne peuvent être remplies. Par exemple, « les performances sont garanties hors utilisation d’autres applications ». Dès qu’un traitement de texte fonctionne sur le réseau local, l’engagement sur temps de réponse tombe.

Pour le taux de disponibilité, une clause peut vous imposer de signaler toute intervention sur le réseau local qui n’est pourtant pas dédié au système. Prise au pied de la lettre, cette disposition vous contraint à appeler le fournisseur à chaque fois que vous ajoutez un poste bureautique même s’il n’utilise le réseau que pour un partage d’imprimante.

Règle n° 3 : un gisement de coûts cachés

Là, tout est possible. La liste des cas est sans fin. Voici sinon les plus fréquents, du moins les plus marquants.

Vous faites un appel d’offres pour un système clés en main couvrant la totalité des matériels et logiciels. Une société ne compte pas le droit d’utilisation du SGBDR. Est-ce un oubli, est-ce volontaire ? Cela fait une différence de 10 % sur le montant de l’offre et c’est très difficile à repérer.

Pour mieux s’adapter à votre budget, un autre fournisseur multiplie les options. Le total annoncé ne tient pas compte des options et surtout pas de celles qui sont obligatoires pour répondre à la demande exprimée.

Et maintenant, un grand classique : le soumissionnaire prévoit la fourniture des composants mais pas celles des prestations. C’est là d’ailleurs plutôt la règle que l’exception lorsqu’il s’agit des options. Par exemple, les serveurs Web ou les serveurs Z39.50 font l’objet d’un chiffrage précis pour le logiciel, mais ni pour le serveur dédié, ni pour les services d’assistance à la mise en œuvre et de formation. Et il n’est pas toujours facile d’identifier ce genre de lacunes.

Aurai-je réussi à convaincre que le dépouillement des offres ne pouvait se limiter au choix d’une offre, mais qu’il fallait également repérer un certain nombre d’omissions ?

Mieux organiser l’exploitation bibliothéconomique

Une fois dépassées les quelques difficultés que je viens d’évoquer, vous constaterez avec plaisir que votre nouveau système est remarquable. C’est un outil très complet, très puissant dont le paramétrage est extrêmement riche. Le revers de la médaille est la plus grande difficulté qu’il y a à s’approprier cette nouvelle génération de système. Pour obtenir une bonne maîtrise de l’outil, il faut mettre en œuvre une structure d’exploitation plus formelle.

En ce qui concerne la partie bibliothéconomique, il s’agit de définir des responsabilités claires en terme d’administration des données et de paramétrage. Il est d’usage de désigner un administrateur des données pour garantir leur qualité et la constitution de fichiers d’autorité à même de réduire le silence assourdissant qui règne dans l’OPAC.

En revanche, les responsabilités sont beaucoup moins formelles en matière de paramétrage et de formation interne. Pourtant, l’enjeu d’une maîtrise du paramétrage et des fonctions avancées (par exemple les requêtes SQL 8 ou les infocentres) justifie tout à fait l’émergence d’une responsabilité transversale permanente.

Généralement, je propose qu’à chaque module soit associé un responsable chargé du paramétrage, de l’utilisation des fonctions avancées, du suivi de formation de l’équipe et de la formation des nouveaux venus (notamment les personnels à statut précaire, sans lesquels les bibliothèques fermeraient boutique).

C’est grâce à une telle structure que la bibliothèque peut espérer obtenir le meilleur profit de son système. Cela me paraît tellement important, qu’en poussant un peu le propos, je dirais qu’au-delà du choix du progiciel, l’enjeu essentiel est de bien tirer parti du nouveau système quel qu’il soit.

Comment réussir ce nouveau pari ?

Espérons que ces mises en garde n’ont pas découragé les candidats à une prochaine réinformatisation.

Pour conclure, je voudrais souligner un facteur-clé de réussite. La bibliothèque municipale dispose d’une équipe déjà rodée sur un premier système. Son personnel a maintenant une culture informatique. Pour la bibliothèque, le changement de système va être l’occasion de monter d’un cran dans l’échelle de la qualité des services rendus. C’est un facteur de motivation.

Il faut profiter de la dynamique que le projet peut créer en mettant en œuvre une équipe de projet, dès les tout premiers travaux d’étude. Plus que jamais, la réussite dépend du niveau d’engagement du personnel. La réinformatisation doit être le projet d’une équipe. Associée dès le départ, celle-ci va évoluer naturellement vers la formation d’une équipe d’exploitation « bibliothéconomique » du système. Employer une démarche participative est, de mon point de vue, un gage de réussite.

Cette démarche présente deux autres attraits. Une équipe de projet est plus en mesure de réunir l’ensemble des compétences nécessaires à la réussite qu’une seule personne. C’est également une garantie pour l’établissement : la bibliothèque ne sera pas dépossédée de son projet.

Mars 1997

Illustration
Schéma 1. Taux d'informatisation des bibliothèques municipales

Illustration
Schéma 2. Bibliothèques municipales dont la réinformatisation se situerait sur la période 97-99

Illustration
Schéma 3. Systèmes d'exploitation utilisés, en pourcentage du nombre de bibliothèques informatisées

Illustration
Schéma 4. Origine des progiciels de gestion de bibliothèque

Illustration
Schéma 5. Inscrire le projet dans une démarche système d'information

  1.  (retour)↑  L’équipement informatique des bibliothèques municipales et départementales, dll, 1996.
  2.  (retour)↑  Pour d’autres informations sur ce point, consulter l’article d’Annie Gourdier qui analyse les causes identifiées du changement de système : Annie Gourdier « Le marché de réinformatisation des bibliothèques : qui choisit-on en secondes noces ? », Bulletin d’informations de l’Association des bibliothécaires français, n° 171, 2e trimestre 1996.
  3.  (retour)↑  L’expérience réussie de plusieurs bibliothèques – dont l’une compte aujourd’hui 1 000 000 d’entrées par an – montre qu’il n’est nullement impossible de basculer d’un système à l’autre sans interruption du prêt ou, au pire, avec une interruption annoncée d’une durée courte et respectée (généralement 2 jours).
  4.  (retour)↑  La non-connaissance des formats et des contenus n’est pas un cas d’école. Ainsi, en 1996, dans un projet de réinformatisation, l’équipe informatique – composée en fait d’une seule bibliothécaire remarquable – a dû reprendre sa calculette pour reconstituer la structure des fichiers en convertissant au départ de l’hexadécimal en caractère ascii, en essayant ensuite de déterminer la longueur et le contenu des champs... ! Ce ne fut pas une partie de plaisir, mais le fournisseur ne l’aurait pas fait à la place de la bibliothèque.
  5.  (retour)↑  Celui-ci ayant été rédigé dans les années 80, je doute que cela soit le cas. Sur 28 projets de réinformatisation dont je me suis occupé, ce cas ne s’est pas présenté une seule fois.
  6.  (retour)↑  Cette clause cherche à limiter les conséquences que peuvent avoir la défaillance du fournisseur, l’interruption ou les déficiences de son service de maintenance...
  7.  (retour)↑  Marc Maisonneuve, « Informatisation des bibliothèques : étude du marché français 1996 », Livres Hebdo, n° 207, 31 mai 1996.
  8.  (retour)↑  Sql : System Query Language, langage d’interrogation de bases de données devenu un standard de fait.