Version classiqueVersion mobile

Réinformatiser une bibliothèque

 | 
Anna Svenbro

Partie 1. Questions de méthode

Jusqu’à quel point externaliser ? La question de la maintenance

Valérie Bertrand et Sonia Bouis

Texte intégral

Externaliser : les enjeux

1Externaliser ou internaliser relèvent de deux logiques différentes. La question d’internaliser la maintenance ne s’est pas posée durant de nombreuses années dans les bibliothèques, les logiciels étaient fournis par des prestataires qui vendaient des logiciels fermés, propriétaires, qu’ils étaient les seuls à pouvoir maintenir.

2Avec la diffusion de logiciels documentaires libres cette question se pose puisque certains établissements sont en capacité de prendre en charge eux-mêmes cette maintenance. Or, cette prise en charge est tributaire des compétences informatiques ‒ plus ou moins développées ‒ disponibles sur site.

  • 1 Cloud : « nuage » fait référence à l’hébergement des logiciels et données sur les serveurs du fourn (...)

3L’externalisation de la maintenance est renforcée par la logique d’externalisation des solutions : matériels, logiciels et données sont désormais hébergées dans le cloud1 des fournisseurs. Ce type de solution a de nombreux avantages. Par conséquent, donner des points de repère face à cette question devenue plus complexe s’impose.

Les aspects économiques

4L’externalisation a tout d’abord l’avantage de représenter des économies budgétaires, dans une période où les bibliothèques sont soumises à des baisses de budget et une augmentation des tarifs de la documentation, notamment électronique. Les économies budgétaires sont de plusieurs ordres :

  • économie d’infrastructure : dans certaines bibliothèques, ces coûts ne sont pas toujours perçus car ils relèvent souvent d’investissement à la charge des DSI, mais ils peuvent s’avérer importants ;
  • économie en personnel surtout, puisque ces systèmes doivent être mis à jour, sauvegardés et maintenus dans un environnement sécurisé, ce qui nécessite l’emploi de personnels qualifiés (dans l’administration, la problématique est bien entendue différente, on n’économise pas de rémunération, mais on peut réorienter des compétences et développer de nouveaux projets).
  • 2 Sophie Demange, « L’informatisation documentaire, combien ça coûte ? », Arabesques, avril-mai-juin (...)

5Externaliser reporte donc ces coûts sur le fournisseur qui prend à sa charge l’accessibilité et la sécurité des solutions hébergées dans son cloud. À ce titre, les résultats d’une enquête effectuée par l’Agence bibliographique de l’enseignement supérieur (ABES), bien que limités, sont intéressants : dans la revue Arabesques, Sophie Demange2 expose la hiérarchie des coûts constatée par 17 membres du comité technique du Système de gestion de bibliothèque mutualisé (SGBm). Les constats sont les suivants : « le coût le plus important est celui du personnel qui administre les systèmes (60 %) », « le coût du SIGB est le plus important dans celui des services (48 %) » ‒ ces services comprenant quatre grands blocs : le SIGB, la gestion des ressources électroniques, les services en ligne et autres systèmes, et les catalogues collectifs. « Le coût du matériel est relativement faible (8 %) et dans ce coût le SIGB tient une place prépondérante (63 %) ».

6Autre constat intéressant, « pour les SIGB les coûts de fonctionnement sont essentiellement des coûts de maintenance : entre 10 000 et 100 000 euros annuels selon les établissements ».

7La question de la maintenance est donc une question qui revêt des enjeux importants pour les bibliothèques.

L’aspect juridique

  • 3 Voir le site de la sécurité des systèmes d’information (SSI) rattaché au Premier Ministre. [En lign (...)

8Un autre aspect de ces enjeux est un aspect juridique qui concerne la localisation et la sécurité des données hébergées. Dans son Guide de l’infogérance3, concernant les risques liés à la localisation des données, l’Agence nationale de la sécurité des systèmes d’information (ANSSI) note qu’« Il convient de s’assurer que l’ensemble des lieux d’hébergement (site principal, site(s) de secours, de sauvegarde, etc.) répondent d’une part, aux exigences de sécurité du donneur d’ordres, et d’autre part, aux obligations légales et réglementaires, notamment en ce qui concerne la protection de données à caractère personnel ».

9Concernant les données à caractère personnel, il est rappelé que « le transfert des données à caractère personnel en dehors des frontières de l’Union européenne (UE) est réglementé par la directive européenne 95/46/CE et la loi n° 78-17 du 6 janvier 1978 modifiée relative à l’informatique, aux fichiers et aux libertés ».

10Dans un contexte de développement des systèmes de cloud, l’UE légifère et harmonise la législation via l’adoption du Règlement général sur la protection des données (en anglais, General Data Protection Regulation [GDPR]) qui concerne 28 pays de l'UE depuis début 2015, et dont les retombées sont encore peu analysées.

La montée du libre : la tentation d’internaliser

11Dans l’Étude d’impact sur le SGBM4, l’ABES a commandité un panorama du réseau Sudoc qui comprend 18 SIGB, le logiciel libre Koha apparaît comme le 4e SIGB implémenté dans le réseau en 2013, ce qui recoupe partiellement les constats de l’enquête du Consortium unifié des établissements universitaires et de recherche pour l'accès aux publications numériques (Couperin) sur les outils de découverte de 2013 dans laquelle 141 établissements de l’enseignement supérieur avaient répondu à propos de leur SIGB : Koha était le troisième SIGB avec 20 implantations et deux projets (derrière Aleph – 28 implantations et Horizon – 32 implantations).

  • 5 Voir Marc Maisonneuve, « Logiciels pour bibliothèques 2014. Nouveaux acteurs, nouvelles solutions » (...)

12En 2014, dans une enquête sur les logiciels métiers pour les bibliothèques5, Tosca consultants référence 28 produits dont au moins une version est disponible gratuitement. Ces produits recouvrent des champs de fonctionnalités très variés et prouvent la bonne santé et la bonne implantation des logiciels libres dans les bibliothèques.

13La logique d’externalisation vers les serveurs de fournisseurs qui proposent des services clés en main avec l’infrastructure matérielle, la fourniture des logiciels, l’hébergement, la mise à jour et la sécurisation des données, aboutit logiquement à l’externalisation de la maintenance. Les établissements qui ont implémenté des logiciels libres ont plus de choix, ils peuvent opter pour une externalisation totale ou peuvent être tentés d’internaliser en partie ou complètement la maintenance.

14Si l’institution possède en interne les compétences pour maintenir le système sans faire appel à un prestataire extérieur c’est autant d’allégement sur la facture annuelle du logiciel (dont on rappelle qu’elle est l’un des postes les plus importants de dépense).

Le contrat de maintenance

  • 6 Association française de normalisation* (Afnor), NF EN 13306, Maintenance-Terminologie de la mainte (...)

15Dans la norme européenne NF EN 13306, intitulée Terminologie de la maintenance, on retrouve la définition suivante de la maintenance : « Ensemble de toutes les actions techniques, administratives et de management durant le cycle de vie d’un bien, destinées à le maintenir ou à le rétablir dans un état dans lequel il peut accomplir la fonction requise »6.

16On retrouve ici le socle minimal d'une fonction maintenance : maintenir ou rétablir dans un état dans lequel il peut accomplir la fonction requise. Dans un processus de maintenance logiciel, cet état est déterminé la plupart du temps par une version dudit logiciel à laquelle correspond un nombre de fonctionnalités définies. À partir de cette base, le contrat de maintenance va élaborer le contour plus ou moins large de la prestation de maintenance et de ses modalités d'application.

17On retrouve souvent plusieurs types de maintenance dans les contrats, des différences liées aux niveaux d'externalisation, aux modèles de facturation. Sans vouloir établir un inventaire exhaustif, un panorama peut déjà permettre de mieux se situer et pouvoir établir avec discernement un contrat de maintenance.

Encadré. Les systèmes de gestion des bibliothèques : cinq grands types de maintenance

La fonction maintenance peut être déclinée en de nombreux types qui définissent un processus complexe. Toutefois, on retrouve généralement cinq grands types de maintenance dans les contrats associés à la maintenance de SIGB :

• la maintenance préventive : elle consiste à prévenir un risque établi et connu ou lié à la compatibilité des autres logiciels nécessaires au fonctionnement du SIGB. Par exemple, elle sera associée à des mises à jour de sécurité pour protéger les serveurs des attaques liées à des failles identifiées. Elle peut aussi être liée à l'évolution de certains navigateurs web, pour assurer la continuité du fonctionnement du logiciel. C'est en général le prestataire qui prévient le client et propose cette maintenance ;
• la maintenance corrective : elle consiste à corriger les anomalies détectées par les utilisateurs par rapport au périmètre fonctionnel décrit pour ce logiciel (c’est-à-dire défini dans la documentation officielle) ;
• la maintenance évolutive : elle consiste à proposer au client des compléments au logiciel qui apportent de nouvelles fonctionnalités par rapport à la version qu'il utilise en production ;
• la maintenance adaptative : elle consiste à proposer des solutions aux clients dont l’infrastructure technique (serveurs, réseaux, navigateur) n’est pas complètement compatible avec le SIGB ;
• la maintenance réglementaire : en cas de modification de la réglementation en rapport avec un des éléments de gestion du logiciel, le prestataire doit alors fournir une mise à jour qui rende le logiciel conforme à cette réglementation (par exemple, un changement lié à la conservation des données personnelles).

18Si les maintenances préventives, correctives et réglementaires sont la plupart du temps dans la maintenance « de base », c'est rarement le cas pour les maintenances adaptatives ou évolutives. Pour ces dernières, les changements de version du logiciel ne sont parfois pas couverts et entraînent une tarification supplémentaire. Tous ces éléments sont définis dans le contrat de maintenance qui est signé entre le client et le prestataire.

Les éléments d'un contrat

19Le contrat est très important car il sera la base pour traiter tous les litiges avec le prestataire, même si celui-ci a des obligations de service. En dehors de la couverture de la fonction maintenance, plusieurs éléments sont importants à prendre en compte pour évaluer le service qui sera fourni :

  • la localisation de la maintenance : depuis une décennie de nombreuses sociétés proposant des SIGB ont été rachetées au niveau international. Le siège de ces sociétés peut être situé à l'étranger et il peut être intéressant de vérifier s'ils conservent des locaux en France, si leur prestation de maintenance est délocalisée et si elle reste francophone. La langue de l'interlocuteur et le décalage horaire sont des éléments à prendre en compte ;
  • les modalités d'intervention : corrections directes sur le serveur et télémaintenance sont largement répandues. Toutefois, il est intéressant de conserver une possibilité d'intervention sur site pour des problèmes liés à l'interaction avec d'autres matériels (démagnétiseurs, automates de prêt) ;
  • les délais d'intervention : il est utile de préciser les heures et jours ouvrables du côté du prestataire et du client pour que les délais en heures ou jours soient interprétables. Les délais doivent toujours être spécifiés sur le contrat car ils sont facilement quantifiables et c'est sur ce point que des recours seront possibles en cas de litige ;
  • les définitions des niveaux d'anomalies, où l’on retrouve souvent au minimum 3 niveaux : bloquant/semi-bloquant/non-bloquant (qui peuvent aussi être signalées comme bloquant/majeur/mineur). Pour les anomalies bloquantes, une solution de contournement doit être proposée très rapidement, dans les heures qui suivent la déclaration de l'incident ;
  • les modalités de communication/suivi : les prestataires utilisent de plus en plus des plates-formes de suivi des anomalies où chaque action liée à celles-ci sera regroupée sous un même ticket*. Des éléments de base peuvent être demandés au client (copies d’écran, exemples reproductibles, etc.) Une adresse électronique pour le contact du support est encore utilisée. Il peut être utile de pouvoir joindre le support par téléphone en cas d'anomalie bloquante ;
  • la mise à disposition des mises à jour logicielles : celles-ci ne sont pas forcément incluses dans le contrat, ni les changements de version. C'est un point qu'il faut bien définir avec son prestataire car un changement de version peut parfois revenir presque aussi cher qu'une réinformatisation.

Les spécificités, adaptations demandées par le client

20Dans un appel d'offres, il est fréquent que les clients demandent des aménagements ou des fonctionnalités supplémentaires par rapport à la couverture fonctionnelle du SIGB choisi. Les prestataires proposent alors facilement des adaptations du logiciel. Ces adaptations ne sont que rarement couvertes par la maintenance de base. Elles font souvent l'objet d'une tarification particulière ou d'un autre contrat.

Les obligations du mainteneur

  • 7 Pascal Alix et Tuyêt-Thi Nguyen, « Les obligations juridiques du mainteneur de logiciel », indexel. (...)

21Le mainteneur se doit, en dehors du contrat, à plusieurs obligations7 :

  • information, renseignement et conseil : par exemple, le prestataire doit indiquer les spécifications matérielles et installations nécessaires (serveurs, navigateurs, etc.) pour le bon fonctionnement du logiciel. Il doit pouvoir indiquer à son client les difficultés qu'il pourrait rencontrer, par exemple en cas de communication avec d'autres systèmes ;
  • obligations de moyens : le prestataire est tenu à une obligation de moyens pour la prestation de maintenance mais pas de résultats. Il devra toutefois proposer des solutions de contournement ;
  • obligation de maintenir une interopérabilité avec les logiciels ou systèmes d'exploitation nécessaires à son utilisation ;
  • obligation de confidentialité, notamment sur les données de connexion informatique aux serveurs du client.

Spécificités des SIGB libres : l'exemple de Koha

  • 8 « Les logiciels en tant que service (en anglais Software as a Service) désignent des logiciels qui (...)

22Dans le cas d'un logiciel libre comme Koha toutes les solutions d'installation et de maintenance sont envisageables. Une complète externalisation des serveurs hébergés chez le prestataire, en mode SaaS8, est possible. Pour les établissements avec du personnel dédié, une complète internalisation sans aucun contrat de maintenance est aussi pratiquée.

Panorama des différentes solutions de maintenance autour du logiciel Koha

23En France, il existe trois prestataires qui proposent des solutions de maintenance autour de Koha : Biblibre, Progilone et Tamil. L'offre de maintenance est variée et on peut retrouver plusieurs formules :

  • dans le cas des solutions hébergées, les établissements ne possèdent pas leurs propres serveurs et le logiciel ainsi que les données sont hébergés chez les prestataires (mode SaaS). La maintenance couvre donc le logiciel et toute l'infrastructure, dont la sécurité du système. Les mises à jour du logiciel et du serveur sont incluses. La fourniture du logiciel et de la maintenance est souvent proposée sous la forme d'abonnement, en fonction du nombre de notices, et pour un coût modique, ce qui la rend attractive pour les petits établissements. Ainsi, la BDP de la Meuse accompagne certaines bibliothèques de son réseau pour la mise en place d'une solution Koha hébergée ;
  • dans le cas d’une maintenance du logiciel par contrat annuel, c'est l'établissement qui possède ses serveurs et qui les gère. La maintenance ne s'applique qu'au logiciel. La tarification est aussi calculée selon le nombre de notices. Les mises à jour du logiciel sont incluses dans le contrat et les changements de version sous certaines conditions. Il n'y a pas de limitation au nombre d'anomalies déclarées et on paye le service qu'on l'utilise ou non ;
  • dans le cas d’une maintenance au ticket, c'est également l'établissement qui possède ses serveurs et la maintenance ne s'applique qu'au logiciel. Dans ce cas, après paiement d’un forfait au démarrage de la maintenance, seules les anomalies déclarées sont tarifées. Ce mode de maintenance peut être choisi car il est très économique ;
  • enfin, dans le cas de la maintenance internalisée, toute la maintenance du système, infrastructure et logiciel, dépend de l'établissement et celui-ci n'a plus de contrat avec un prestataire. Cette solution est souvent choisie par des établissements ayant une division informatique importante et qui collabore bien avec la bibliothèque. Dans le cas de BU, il y a souvent du personnel avec de larges compétences dans la gestion des serveurs et dans la sécurité informatique. Si on a également du personnel avec des compétences en programmation, notamment en langage Perl, il est possible de réduire les frais de maintenance externe à zéro. C'est le choix qui a été fait par la BU de Rennes 2 et par la bibliothèque universitaire des langues et civilisations (BULAC).

La gestion des adaptations locales

24Pour adapter leur système de bibliothèque à des besoins fonctionnels locaux, il est fréquent que les établissements demandent des adaptations ou des modules complémentaires à la version diffusée du logiciel. Ceci est possible chez des éditeurs de logiciels propriétaires mais est pratiquement intrinsèque au logiciel libre puisqu'il doit répondre aux quatre principes suivants :

  • liberté d'utiliser le logiciel ;
  • liberté de modifier le logiciel ;
  • liberté de redistribuer le logiciel ;
  • interdiction de restreindre les trois premières libertés.

25Toutefois, en matière de maintenance, il faut avoir conscience que le fait de modifier le logiciel peut avoir de nombreuses conséquences. En effet, les mises à jour et les nouvelles versions peuvent ne plus être compatibles avec les développements réalisés en interne.

26Les modifications du code source peuvent être prises en charge dans le contrat de maintenance du prestataire, surtout si c'est lui qui les a réalisées, mais souvent avec un supplément au contrat de maintenance « de base ».

27Si ces modifications sont faites en interne, elles peuvent être suivies par l'établissement. C'est le choix que nous avons fait à Lyon 3. Notre contrat de maintenance couvre la version communautaire 2 du logiciel et nous maintenons nous-mêmes nos développements locaux. Nous essayons également de proposer une partie de ces développements à la communauté pour qu'ils soient intégrés dans la version officielle9.

  • 10 Dans le domaine du développement logiciel, et en particulier dans celui de l’open source, on appell (...)

28Lorsque les modifications sont très nombreuses et touchent au cœur du logiciel, on peut aboutir à un fork10, une branche du logiciel qui diverge de l'original. Dans ce cas, les mises à jour et changements de versions sont très difficiles voire impossibles. En France, plusieurs établissements ont eu une installation d'une version de Koha avec un moteur de recherche différent de celui d'origine notamment dans le but d'améliorer la gestion des facettes du logiciel. Après quelques années de production, ces établissements ne peuvent plus bénéficier des dernières améliorations de Koha. Certains d'entre eux préfèrent conserver leur version et payer pour obtenir des développements compatibles avec leur version, d'autres ont fait le choix d'abandonner cette version pour revenir à une version communautaire.

29Koha a en effet la particularité de s'améliorer rapidement. Les établissements qui avaient opté pour des développements locaux peuvent se rendre compte que certaines fonctionnalités qu'ils avaient demandées dans les adaptations sont intégrées dans la version communautaire. Le bénéfice de rester sur une branche du logiciel qui n'évolue que très peu est alors à étudier de très près.

Le troisième acteur de la maintenance : la communauté Koha

30Le logiciel Koha évolue très rapidement car la communauté de développement est très active et très structurée. Une nouvelle version sort tous les 6 mois et des mises à jour de version sont proposées tous les mois. Un circuit de validation est organisé pour vérifier la qualité des développements intégrés dans la version :

  • d’abord, des tests fonctionnels sont réalisés ‒ ils peuvent être exécutés par des bibliothécaires/documentalistes ‒ ce qui est le gage qu'ils conviendront à l'utilisateur final11 ;
  • ensuite, la qualité du code est vérifiée par une équipe de développeurs spécialisés dans Koha et de provenance internationale ;
  • enfin, le responsable de la version, également développeur Koha, vérifie l'ensemble et valide l'intégration dans le logiciel.

31Des corrections ou améliorations sont proposées pratiquement quotidiennement dans la base de données Bugzilla*. Lorsqu'un bug est découvert dans son établissement, il est facile de vérifier s'il a déjà été déclaré et si une correction a été proposée. Si c'est le cas, il est possible de le signaler à son prestataire ou de le récupérer directement. C'est aussi pour cela qu'une maintenance totalement internalisée est possible car les personnes qui l'ont en charge dans les établissements peuvent s'appuyer sur un réseau mondial de développeurs qui travaillent sur Koha.

Notes

1 Cloud : « nuage » fait référence à l’hébergement des logiciels et données sur les serveurs du fournisseur.

2 Sophie Demange, « L’informatisation documentaire, combien ça coûte ? », Arabesques, avril-mai-juin 2013, p. 18.

3 Voir le site de la sécurité des systèmes d’information (SSI) rattaché au Premier Ministre. [En ligne] < http://www.ssi.gouv.fr/IMG/pdf/2010-12-03_Guide_externalisation.pdf >.

4 [En ligne] < http://sgbm.abes.fr/2013/03/30/letude-dimpact-du-sgb-mutualise-et-letude-sur-un-dispositif-de-decouverte/ >.

5 Voir Marc Maisonneuve, « Logiciels pour bibliothèques 2014. Nouveaux acteurs, nouvelles solutions », Livres Hebdo, 7 mars 2014, n° 988, pp. 20-26. [En ligne] < http://toscaconsultants.fr/wp-content/uploads/2016/04/logiciels_pour_bibliotheques_2014.pdf >.

6 Association française de normalisation* (Afnor), NF EN 13306, Maintenance-Terminologie de la maintenance, Paris, Éd. Afnor, 2010.

7 Pascal Alix et Tuyêt-Thi Nguyen, « Les obligations juridiques du mainteneur de logiciel », indexel.net, 25 mars 2009. [En ligne] < http://www.indexel.net/management/les-obligations-juridiques-du-mainteneur-de-logiciels-2850.html >.

8 « Les logiciels en tant que service (en anglais Software as a Service) désignent des logiciels qui sont hébergés sur le serveur d’un prestataire, accessibles à distance (par exemple au travers d’un navigateur web), et dont la facturation s’effectue sous forme d’abonnement, ou proportionnellement à l’utilisation de certaines ressources. En français, on parle couramment de solutions en mode SaaS) ». [En ligne] < http://www.dictionnaireduweb.com/saas-software-as-a-service/ >.

9 [En ligne] < www.koha-community.org >.

10 Dans le domaine du développement logiciel, et en particulier dans celui de l’open source, on appelle Fork une branche divergente d’un programme, c’est-à-dire un nouveau projet basé sur le premier mais qui prend une autre direction. [En ligne] < http://www.dictionnaireduweb.com/fork-developpement-logiciel/ >.

11 Nous organisons à Lyon 3 des journées de tests où des bibliothécaires peuvent tester et valider (ou non) des corrections et de nouvelles fonctions, proposées pour améliorer Koha.

© Presses de l’enssib, 2017

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

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search