Version classiqueVersion mobile

Réinformatiser une bibliothèque

 | 
Anna Svenbro

Partie 1. Questions de méthode

Choisir une solution libre ou propriétaire

Alexandre Garcia et Anna Svenbro

Texte intégral

Le choix d’une solution libre à la Bibliothèque francophone multimédia de Limoges (Bfm), état des lieux

1Dans le cadre du projet de la nouvelle bibliothèque (Bfm), il était prévu le renouvellement du SIGB et la création, en plus des OPAC, d’un site web. La bibliothèque était gérée depuis la fin des années 1980 avec le logiciel Advance de GEAC. Suite à un appel d’offres sur performances, c’est la solution proposée par CSC Ouroumoff (en tant qu’intégrateur de Loris de la société Ever) qui a été retenue. L’ouverture de nouveaux locaux avec le nouveau SI a eu lieu le 12 septembre 1998.

2Entre 2005 et 2010, avec l’annonce de Flora (nouvelle version du SIGB d’Ever) et la fin programmée de Loris (s’arrêtant à la version 3.7), nous avons dans un premier temps étudié cette nouvelle solution d’Ever. Nous avons eu des difficultés sur l’accompagnement à cette migration, notamment en termes de disponibilité de la part de l’éditeur. Parallèlement, nous avons observé le marché. Nous nous étions déjà intéressés aux SIGB open source (PMB, Koha). À l’époque, la taille de la Bfm ne correspondait pas aux capacités de ces logiciels (Koha était limité à 300 000 notices). Les problèmes de migration vers Flora et l’annonce de la version 3 de Koha permettant la gestion au-delà des limites de la version précédente nous ont amenés en 2010 à reconsidérer ce logiciel libre.

3Ainsi, dans le cadre d’une collaboration ancienne avec l’université de Limoges, nous partagions sur le sujet une préoccupation commune. Leur marché concernant le SIGB des BU arrivant à terme, nous avons échangé sur les options offertes par les éditeurs. Nous avons abordé la solution Koha avec un grand intérêt de part et d’autre car à cette époque de grandes BU avaient fait ce choix.

4Nous avons installé et testé une version de Koha. Entre-temps, Ever lançait une version libre de son dernier logiciel OpenFlora. Suite aux tests concluants de Koha et à l’intérêt de l’université, il a été décidé de lancer un appel d’offres pour des prestations d’installation, de paramétrage et de maintenance de Koha à la Bfm. Ce marché comprenait un lot spécifique à la migration des données. En effet, nous avions appris l’existence d’une société composée d’anciens techniciens d’Ever ayant la connaissance de la base Loris.

5Cette solution nous paraissait aussi ouvrir des perspectives de mutualisation de certains développements dont nous partagions le besoin. De plus, la communauté a plus de poids que les clients dans un club utilisateurs. Les prestataires peuvent être multiples et il y a donc concurrence et diversité. On est indépendant de la pérennité de l’éditeur tant que la communauté est vivante.

6De cette double expérience de réinformatisation à la Bfm, il est possible de tirer un certain nombre d’enseignements quant au type de solution à choisir lors d’une réinformatisation : pourquoi choisir une solution libre ou propriétaire ? Une solution hébergée à demeure ou par un tiers ? Enfin, quels paramètres prendre en compte à l’heure du choix, notamment au niveau des relations avec les services informatiques, de l’adaptation des solutions logicielles et leur durée de vie, et des perspectives de mutualisation ?

Solutions propriétaires, solutions libres, solutions à demeure, solutions tiers-hébergées : les différents modèles économiques

La solution traditionnelle : les solutions propriétaires

7Historiquement, le modèle éditeur propriétaire de la solution, de ses sources et de ses droits est le plus répandu et le plus culturellement établi.

8Lorsque l’on acquiert un logiciel dit « propriétaire » cela signifie que l’on contracte une cession de droits d'utilisation du logiciel et pas un « transfert de propriété du logiciel ». En conséquence, le logiciel qualifié de « propriétaire » par abus de langage, et mis à la disposition d’un utilisateur, reste la propriété de son auteur, personne physique ou personne morale (entreprise) ; l'auteur conserve les droits accordés par le droit d'auteur, notamment le monopole de la copie.

9Cette cession présente bien sûr ses avantages et ses inconvénients. Au niveau des risques, la pérennité de l’éditeur en est le premier. Que se passe-t-il en cas d’abandon du produit, de disparition de l’éditeur ou de rachat ?

10En outre, la relation avec l’éditeur s’établit dans un rapport de force à son avantage. Ce qui ne pose que peu de problèmes quand tout va bien mais en cas de difficultés, cela devient sensible. La présence d’un club utilisateurs est un plus mais, en général, comme il est animé par l’éditeur, son influence est relative.

11D’un point de vue comptable, usuellement, l’acquisition d’une licence est considérée comme un investissement (entrant dans la catégorie des immobilisations incorporelles) donc amortissable (normalement dès la date d’acquisition et pour une durée correspondant à la durée réelle d’utilisation et à l’obsolescence technique et commerciale du produit) et plus facile à faire passer dans un budget que sur du fonctionnement fortement contraint en contexte budgétaire de plus en plus étroitement contrôlé. De plus, dans le cadre d’une acquisition, les prestations qui l’accompagnent (maintenance, développements) sont considérées comme accessoires à cet investissement et donc imputées comme telles.

L’origine et le développement des solutions open source

  • 1 Informaticien qui crée, analyse et modifie des programmes informatiques pour les améliorer et en d (...)

12À l’apparition des ordinateurs dans les universités, les logiciels (codes sources) étaient ouverts, disponibles (années 1960-1970). Les étudiants les plus brillants ont investi le domaine en parcourant les programmes (on assiste à la naissance du terme « hacker »1). Dès 1962, Spacewar (premier jeu vidéo réalisé au Massachussetts Institute of Technology) est considéré comme le premier projet open source. Puis, dans les années 1970, la protection des codes sources se répand (notamment à partir de 1976 et la réunion du Homebrew Computer Club avec Bill Gates et Paul Allen). À partir de 1983, Richard Matthew Stallman (considéré comme le fondateur du logiciel libre) prône un système d’exploitation libre (projet GNU inspiré d’Unix). Cette initiative est très vite concurrencée par le travail d’un étudiant finlandais de 21 ans, Linus Torvalds, qui sort en quelques mois la version 0.01 de Linux. Fin 1991, Linux passe sous licence libre GPL. Puis, en 1993, on assiste à la création de la distribution Linux Debian, de FreeBSD 1.0, et, en 1995, de la première version d’Apache (serveur web http). En 1998, Netscape livre le navigateur Mozilla en open source, qui deviendra Firefox. En 2000, Sun dépose la suite OpenOffice en open source (à l’origine de LibreOffice aujourd’hui). 2005 marque la naissance d’Alfresco, système de gestion électronique de documents (GED), encore une fois en open source. En 2006, Java passe sous licence ouverte GPL. L’année suivante, l’Assemblée nationale choisit Linux pour les postes de travail des députés.

13Le principe de l’open source répond à quatre libertés fondamentales :

  • exécuter le programme ;
  • étudier le programme et l’adapter selon son besoin (ce qui implique bien sûr l’accès au code source) ;
  • redistribuer le programme pour aider son prochain ;
  • améliorer le programme et distribuer ces améliorations au public (ce qui implique le libre l’accès aux sources).

14L’Open Source Initiative (OSI) a défini précisément le terme open source que l’on peut retrouver sur son site2 ainsi que la liste des principales licences. Il est à noter qu’une de ces licences est reconnue par le droit français et communautaire : CeCill3. Un logiciel libre s’appuie donc bien sur une licence.

Le modèle économique de l’open source

15Le modèle économique de l’open source est multiple, et va du logiciel téléchargeable sans support que l’on pourrait qualifier avec précaution de « gratuit » (par exemple : Gimp ou LibreOffice si on est autonome) au logiciel avec fonctions avancées, évolutions et support.

16On peut considérer trois grandes familles de logiciels open source :

  • les produits de fondations (Apache, Eclipse, Linux, etc.) ;
  • les produits communautaires ;
  • les produits d’éditeurs.

17Quant aux acteurs, on peut en distinguer quatre types :

  • les fondations (organismes à but non lucratif, qui stimulent et pilotent le développement de grands produits open source) ;
  • les distributeurs (assurent le packaging, la distribution et le support) ;
  • les éditeurs (créent un produit logiciel, qu’ils diffusent sous licence open source, en tout ou en partie, assurent la promotion de leur produit, et proposent des offres de support) ;
  • les prestataires (vendent des services, que ce soit dans un mode de régie ou de forfait, du conseil, de l'intégration, du support, de la formation, de l'hébergement, etc.).

18Or, le fait qu’un logiciel est libre ne signifie pas pour autant qu’il ne coûte rien. Voyons donc maintenant les différents modèles économiques associés aux logiciels libres :

  • le support seul : on pourrait faire l’analogie avec le contrat de maintenance sans option de mise à jour de version du modèle propriétaire, sauf qu’on n’a acheté aucune licence ;
  • la version « entreprise » et le support : il s’agit en fait d’une version payante qui est plus aboutie, avancée que la version téléchargeable et réputée plus stable, plus professionnelle. Cela permet de tester une version sans investir avant de prendre une décision ;
  • la version « avancée » et support : en fait, ici, il y a deux niveaux de licence : le « noyau » en open source et des modules portant des fonctionnalités avancées sous licence classique.

19Au-delà de ces modèles, il y a toujours, si l’on n’est pas autonome, les prestations d’installation, de paramétrage, de formation, etc. à prévoir et à suivre. D’un point de vue comptable, elles sont à passer dans les charges de fonctionnement, et ce, parce qu'il n'y a pas de dépenses d'investissement les rendant accessoires.

20Les risques dans ce cas sont liés aux compétences informatiques du personnel de l’établissement, plus ou moins étendues et plus ou moins fragiles dans le temps (mutations, départs en retraite, etc.), au dynamisme et à la pérennité de la communauté d’utilisateurs, ainsi qu’au nombre d’acteurs prestataires de la solution.

  • 4 Pour en savoir plus : « Smile - Comprendre l’Open Source - Livre blanc », [s.d.]. [En ligne] < htt (...)

21Les opportunités sont parfois financières (pas de coût de licence, mutualisation), fonctionnelles (les évolutions résultent plus des utilisateurs), et environnementales (la multiplicité des prestataires qui répond au risque de pérennité d’un éditeur seul)4.

Logiciel en tant que service (SaaS), tiers-hébergement dans le cloud : l’émergence de nouveaux modèles

22Le terme SaaS (Software as a Service = logiciel en tant que service) remplace les termes Application Service Provider (ASP) ou encore on demand, précédemment employés.

23La différence entre le logiciel en tant que service (SaaS) et les précédents modèles tels qu’ASP réside dans le fait que les applications s’appuyant sur ce modèle ont été nativement conçues pour l'accès via Internet.

24Les principaux avantages de ce type de solution sont les suivants :

  • l'utilisation de solutions logicielles dans un mode service (SaaS) permet un meilleur contrôle des charges techniques surtout en l’absence d’équipe technique en interne. L'ensemble des solutions techniques étant délocalisées, le coût devient fixe, généralement fonction du nombre de personnes utilisant la solution SaaS et les problèmes techniques sont externalisés. Le prix par utilisateur englobe le coût des licences des logiciels, de la maintenance et de l'infrastructure ;
  • les coûts totaux d'acquisition et de maintenance de la solution s'avèrent plus faibles qu’une acquisition traditionnelle de licence qui est généralement passée en immobilisation. D’un point de vue comptable, tout sera passé en charges de fonctionnement ;
  • un gros avantage est la rapidité de déploiement lorsque le logiciel SaaS correspond exactement au besoin (et qu'il ne nécessite aucune adaptation) ou que l’on s’y contraint. Les solutions SaaS étant déjà pré-existantes, le temps de déploiement est extrêmement faible.

25Néanmoins, ces solutions ne sont pas sans inconvénients :

  • lors de la mise en place de solutions SaaS, les données relatives au maître d’ouvrage sont habituellement stockées sur les serveurs du prestataire fournissant la solution. Lorsqu'il s'agit de données sensibles ou confidentielles, le maître d’ouvrage est obligé de prendre des dispositions contractuelles avec le fournisseur ;
  • la délocalisation des serveurs de la solution SaaS permet également un accès nomade aux données du maître d’ouvrage. Cet accès engendre un souci de sécurité de l'information lors du départ de collaborateurs. Il est indispensable d'avoir mis en place des procédures permettant, lors d'un départ, de supprimer l'habilitation de l'ancien collaborateur à accéder aux données du maître d’ouvrage ;
  • par ailleurs, l'intégration des applications SaaS entre elles ainsi qu'avec les autres applications du SI, hébergées dans les centres de données du maître d’ouvrage, figure parmi les principaux handicaps du SaaS. De nouveaux profils d'acteurs apparaissent pour répondre à cet enjeu à travers des plates-formes applicatives de type PaaS (Platform as a Service) fournissant des briques complémentaires ou des Application Programming Interface* (API) permettant à ces applications de dialoguer entre elles.

26Il est également important d'adapter son plan de continuité de l'activité à l'intégration de solutions SaaS ainsi que de prévoir les divers scénarios possibles en cas de problèmes avec le prestataire de la solution SaaS.

27En termes de contrôles internes, il est recommandé que le prestataire de services fournisse un certificat de type SSAE16 à son client afin de garantir de la bonne qualité de son propre système de contrôles internes. Le cas échéant, le maître d’ouvrage doit prendre des mesures compensatoires comblant les manquements de son fournisseur de services.

28Les migrations informatiques peuvent être compliquées puisqu'il faut basculer les données de la plate-forme d'un fournisseur vers celle d'un autre, avec divers problèmes associés (compatibilité, apparence pour le maître d’ouvrage, etc.). Dans le cadre du SaaS, le maître d’ouvrage se trouve particulièrement lié à son fournisseur.

29Il y a également un troisième acteur, c'est le fournisseur d'accès internet (FAI), car c'est lui qui assure la communication entre le maître d’ouvrage et le prestataire, donc une ligne hors service implique l'arrêt total de l'activité du maître d’ouvrage d'où la nécessité de se procurer des lignes redondantes avec un débit minimal fixe assuré par l'opérateur télécom.

Encadré. Forces et faiblesses des trois solutions : comparatif

Solution Licence « propriétaire » :

avantage : classique.
inconvénient : dépendance éditeur.
commentaires :mesurer la capacité d’adaptation d’une solution « clef en main » ; bien évaluer la durée de vie de la solution.

Solution Licence libre (open source) :

avantages : coût ; mutualisation ; communauté ; évolutions.
inconvénients : multiplicité des modèles ; moins usité.
commentaires :bien réfléchir aux compétences disponibles en interne et aux possibilités de mutualisation ;bien réfléchir aux enjeux et à l’extension d’une externalisation de la maintenance et des développements ;renforcer le travail en réseau ;repenser les logiques de fonctionnement des services et de l’établissement.

Solution mode SaaS (abonnement) :

avantage : externalisation de la technique.
inconvénients : fonctionnement ; dépendance fournisseur ; externalisation des données sensibles.
commentaires :tester la solution au préalable ;évaluer la maîtrise des coûts ;vérifier la réversibilité des données : le fournisseur doit pouvoir les restituer à la bibliothèque en cas d’arrêt de l’abonnement ;bien évaluer la solidité du prestataire ;vérifier le lieu d’hébergement des données et le régime juridique dont il dépend (compatible avec les règles CNIL).

Avant le choix de la solution : des questions essentielles

Un élément essentiel : la nature et l’importance des liens de la bibliothèque avec la DSI

30Le nombre de personnels et leur qualification, au sein de la bibliothèque et du service informatique de la tutelle, sont déterminants dans le choix de la solution. En outre, la qualité des relations entre la bibliothèque et la DSI de la tutelle est d’emblée à prendre en considération.

31La qualité de cette relation garantit la fiabilité et la qualité technique de la relation avec le support de la solution. Il est recommandé de signer un contrat de service avec la DSI afin de formaliser le cadre de leurs interventions (horaires d’intervention/amplitude horaire d’ouverture au public, délais, niveau d’intervention, solutions de contournement, plan de reprise d’activité, etc.).

32En effet, une bibliothèque livrée à elle-même sur des problématiques techniques perdra beaucoup de temps, d’énergie, de motivation avec des risques d’altération de la relation avec le prestataire. Il est essentiel que la criticité du SIGB soit reconnue au plus haut niveau. Aujourd’hui, une bibliothèque sans informatique ne peut apporter qu’un service très limité (pas de prêt, pas de recherche catalogue). Il ne reste que la consultation sur place.

33S’il n’est pas possible d’avoir un réel soutien de la DSI, il faut le prendre en compte dans la relation de support avec le prestataire.

L’adaptation du fonctionnel et de la maintenance des outils choisis

34Il faut également tenir compte de la complexité du fonctionnel dans le choix final du SID. Plus on demande quelque chose de compliqué, plus ce sera difficile à maintenir après : la liste au Père Noël peut mener à de mauvaises surprises si l’on n’est pas vigilant. Il est important de savoir qu’un logiciel sait bien faire ce qu’il fait déjà (il est éprouvé par les autres utilisateurs). Tout nouveau développement peut fragiliser l’application par des effets collatéraux et ajouter des problèmes aux surcoûts déjà engendrés.

35Pour répondre à ce risque, il existe un outil très utile : la pondération des fonctionnalités. Il s’agit de lister les fonctionnalités attendues de la nouvelle solution et de les noter selon 4 critères : indispensable, nécessaire, accessoire, gadget. On leur donne également un poids en termes de coût ou de charge de réalisation. On peut classer ces fonctionnalités et éliminer les moins importantes qui coûtent le plus jusqu’à obtenir un compromis acceptable.

36C’est un exercice de groupe à faire avec sincérité. Il ne s’agit pas de se faire plaisir. Les questions à se poser sont : cette fonctionnalité est-elle indispensable au fonctionnement du métier, si on ne l’a pas que se passe-t-il ? À qui est-elle destinée (public ou professionnel) ? Y a-t-il des solutions de contournement ?

37Au final, on doit obtenir une vision pragmatique de ce que l’on peut faire avec la solution en l’état, qu’est-ce qu’on y perd, quels sont l’importance des suppléments et leur coût.

La durée de vie des logiciels choisis lors de la réinformatisation

38On ne peut envisager le choix de telle ou telle solution sans tenir compte de la durée de vie du produit informatique (5 ans parfois). Les solutions SaaS permettent en partie de résoudre le problème mais rendent le client davantage dépendant de leur fournisseur.

  • 5 Voir la contribution de Valérie Bertrand et Sonia Bouis : « Gérer les différentes applications au (...)

39Dans le cas des mises à jour informatiques d’un produit libre, il faut tenir compte de l’éventualité d’un fork* technique5, une partie de la communauté ayant développé un outil rencontrant des problèmes de compatibilité avec les solutions utilisées par le reste de la communauté (par exemple : le fork SolR/Zebra pour le moteur de recherche de Koha).

40Les évolutions technologiques s’accélérant, la durée de vie d’un logiciel raccourcit. La gestion de son obsolescence n’en est que plus délicate. Il faut pourtant prendre en compte cette durée de vie dans les calculs de retour sur investissement qui nous sont demandés.

41Les premiers critères à prendre en compte sont la technologie utilisée, l’âge de la solution ou sa version, le vécu sur ce métier de l’éditeur ou du prestataire, le nombre de versions prévues par an, sa roadmap (feuille de route) en termes d’évolution, etc.

42Aujourd’hui, on compte entre 5 et 10 ans pour un logiciel sur une technologie en intégrant les évolutions. Il faut savoir qu’un logiciel peut changer de plate-forme technologique mais cela entraîne une migration, une remise en cause des infrastructures et souvent des rachats de licence le cas échéant. Un produit mature ou en fin de vie implique de prendre des dispositions contractuelles afin de prévoir ces changements et d’en maîtriser les impacts.

Perspectives autour du libre : et la mutualisation ?

43S’agissant du cas particulier du choix d’une solution libre, la mutualisation offre des perspectives intéressantes : pourquoi ne pas essayer de collaborer ensemble autour d’une solution open source qu’on mutualise ?

44C’est la possibilité qu’offre l’open source mais cela ne se fait pas tout seul, surtout dans le contexte des administrations. Cela repose très souvent sur la volonté de certains (souvent trop peu nombreux). La tâche est ingrate ; pourtant, quand on y parvient, les résultats sont à la hauteur des efforts consentis.

  • 6 Voir Jérôme Pouchol (dir.), Mutualiser les pratiques documentaires : bibliothèques en réseau, Vill (...)

45Les avantages de la mutualisation sont nombreux : réduction des coûts, partage entre professionnels au-delà du produit lui-même, maîtrise des évolutions, développement des réseaux, travail collaboratif, enrichissement des pratiques6, etc.

46Ainsi, pour résumer l’attitude à adopter lorsque se pose la question du type de logiciel à choisir, on doit souligner qu’il n’existe pas de solution idéale, quel qu’en soit le modèle économique. C’est toujours un compromis, un équilibre entre trois paramètres : coût, qualité, délais. La question est à envisager globalement, par rapport aux objectifs du projet et à ses contraintes. La solution la plus séduisante fonctionnellement n’est pas forcément celle qui répondra le mieux à l’ensemble des attentes, et réciproquement.

Notes

1 Informaticien qui crée, analyse et modifie des programmes informatiques pour les améliorer et en développer les fonctionnalités. Il peut aussi reporter et exploiter leurs faiblesses.

2www.opensource.org >.

3www.cecill.info >.

4 Pour en savoir plus : « Smile - Comprendre l’Open Source - Livre blanc », [s.d.]. [En ligne] < http://www.smile.fr/Ressources/Livres-blancs/Culture-du-web/Comprendre-l-open-source >.

5 Voir la contribution de Valérie Bertrand et Sonia Bouis : « Gérer les différentes applications au sein du système », p. XX.

6 Voir Jérôme Pouchol (dir.), Mutualiser les pratiques documentaires : bibliothèques en réseau, Villeurbanne, Presses de l’enssib, 2016 (coll. La Boîte à outils ; 38). En accès libre : < mutualisationpratiquesdoc.enssib.fr >.

© Presses de l’enssib, 2017

Conditions d’utilisation : http://www.openedition.org/6540

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search