Open Source : un risque ?

Regard critique sur les scénarios de support technique des logiciels Open Source en bibliothèque

Un «danger éventuel, plus ou moins prévisible, inhérent à une situation ou à une activité» est un risque. Analysons un instant dans cette perspective votre choix d’un logiciel open source. Vous mesurez les conséquences de vos actions et de vos décisions. Vous calculez en fonction de vos objectifs le niveau de risque que vous jugez acceptable pour votre établissement. Rien que de très normal en somme. Vous n’agissez pas autrement avec un logiciel propriétaire. Toutefois l’introduction de l’open source en bibliothèque étant toute récente encore, il convient de considérer cette question de la gestion du risque avec un regard neuf.

Certains aspects de l’évaluation d’un logiciel ne diffèrent pas entre propriétaire et open source : quelles sont les fonctionnalités du logiciel ? sont-elles pleinement opérationnelles ? les clients existants sont-ils satisfaits ? quelles sont les spécifications techniques du matériel nécessaire ? etc. Avec les logiciels open source, il convient d’approcher certaines questions sous un angle différent, la question revenant le plus souvent chez les bibliothécaires étant celle du support technique.

Quand vous avez un problème avec un logiciel propriétaire, vous décrochez votre téléphone et vous appelez le support de l‘éditeur. Vous avez payé pour ça. Si le logiciel a des bugs, vous êtes en droit d’attendre qu’ils soient corrigés, de même qu’il est prévu que de nouvelles fonctionnalités soient ajoutées au logiciel. Toujours pour la bonne raison que vous avez payé pour cela. De ce point de vue-là, tous les logiciels open source ne sont pas logés à la même enseigne. Plusieurs scénarios de maintenance sont envisageables, y compris celui d’un contrat de maintenance avec une société de services, très similaires à celui que vous auriez avec un éditeur de logiciel propriétaire.

Panorama des options de support

Tous les produits et tous les projets open source ne sont pas égaux. Si l’on veut approcher la question de la gestion du risque quant aux options de support des logiciels open source, il convient de dégager au préalable les trois scénarios suivants :

1. Les logiciels développés en interne – Ils sont développés par la bibliothèque ou par un petit nombre d‘établissements. Ils répondent à des besoins locaux sans trop d’effort pour les généraliser. Ils sont supportés par le personnel local qui a développé le logiciel. Le risque de tel logiciel est celui lié à la gestion de la transition quand le personnel d’origine quitte l‘établissement.
2. Les logiciels communautaires – Ils ont attiré un réseau d’utilisateurs et de développeurs dans un grand nombre d‘établissements. Cette communauté n’est évidemment pas tenue contractuellement de fournir une aide mais beaucoup de produits open source ont des groupes d’utilisateurs structurés qui sont prêts à passer du temps à aider les autres pour le bien du projet.
3. Les logiciels supportés par une société de services – Ces logiciels s’appuient sur des sociétés de services qui vendent des contrats d’assistance, de déploiement, etc. Même si ces sociétés ne possèdent pas le logiciel, elles fournissent une aide à son utilisation via des contrats, tout à fait comme avec les logiciels propriétaires. Un exemple de ce modèle est Red Hat Linux qui fournit une variante de Linux avec toutes sortes de contrats associés.

L’open source en action

Les logiciels développés en interne correspondent peu ou prou aux logiciels spécifiques écrits depuis les années 80. Ils représentent le risque le plus important pour un établissement, que l‘établissement l’adopte ou qu’il le développe lui-même. Le chemin emprunté par ces logiciels pour aller au succès les a souvent amené à devenir des logiciels propriétaires. C’est le cas du SIGB NOTIS qui a été développé à l’origine par l’Université de Northwestern, qui a été plus tard commercialisé par la société NOTIS Systems, puis qui finalement a fusionné avec Dynix.

Un exemple plus récent est le logiciel de gestion des prêts inter-bibliothèques, ILLiad, créé par l’Université Virgina Tech et commercialisé par Atlas Systems, plus tard racheté par l’OCLC.

Pour d’autres logiciels développés en interne, le succès n’est pas au rendez-vous. Les bibliothèques regrettent vite de les avoir utilisé et les remplacent par un logiciel propriétaire. De plus en plus, aujourd’hui, les logiciels développés en interne ont tendance à opérer une transition vers un modèle de logiciel communautaire, non pas dans le but pour la bibliothèque d’en tirer profit mais pour avancer et coopérer avec d’autres établissements à des objectifs communs et pour pérenniser le logiciel.

Pour les logiciels développés en interne qui ne se transforment pas en logiciels supportés par une communauté, le risque pour l‘établissement est de ne compter que sur ses propres forces et sur son expertise locale pour la maintenance et l‘évolution du logiciel. Le défi à relever consiste à s’assurer que l’expertise nécessaire est bien transmise quand les développeurs d’origine quittent l‘établissement et que des ressources suffisantes, spécialement en personnel, continuent d‘être allouées au projet afin qu’il reste viable.

Dans les années récentes, beaucoup d‘établissements ont utilisé des solutions développées en interne pour gérer leurs bases de données payantes (ERM, systèmes de gestion des ressources électroniques). Nombreux sont ceux qui aujourd’hui étudient une stratégie de sortie pour ce qui apparaît de plus en plus comme une approche non viable.

Ajout d’un support externe

C’est l’Internet qui a permis l‘émergence des logiciels communautaires, l’Internet en tant que nouveau médium de partage et d‘échange modifiant radicalement l’environnement du “support informatique”. Grâce à l’Internet, la nouvelle génération des logiciels développés en interne est plus pérenne que la génération des années 80. Le navigateur web Firefox est un bon exemple de logiciel open source qui prospère grâce à une communauté saine et robuste. Le navigateur web Apache est l’illustration type du logiciel serveur d’entreprise, utilisé par un nombre incalculable d‘établissements sans aucun contrat de maintenance, qui le font fonctionner avec l’aide d’un groupe d’utilisateurs et de développeurs.

Pour finir, il y a également des solutions payantes de support des logiciels open sources, proposées contractuellement par des sociétés de services. Le support payant met les solutions open source au même niveau que les logiciel propriétaires pour ce qui est de la maintenance et de la sécurité. Pour un système aussi complexe et aussi central dans l’activité de votre bibliothèque qu’un SIGB (ou ce qui le remplacera bientôt), vous voudrez probablement vous faire aider par une société de services. Pour d’autres logiciels, l’assistance d’une communauté sera peut-être suffisante. Les deux SIGB open source les plus populaires, Koha et Evergreen, ont tous deux des sociétés de services qui fournissent des contrats d’assistance : il est bon qu’il en soit ainsi pour des logiciels qui représentent un tel enjeu. D’un autre côté, certaines solutions open source ayant une couverture fonctionnelle moindre sont devenues populaires dans les bibliothèques sans que des sociétés de services leur soient associées. Il s’agit des extensions Firefox LibX et Zotero, permettant respectivement de faire des recherches dans des catalogues et de gérer des bibliographies personnelles. Ou encore, il s’agit de VuFind qui promet de remplacer l’OPAC de la bibliothèque. À mesure que les bibliothèques s’habituent au modèle de support communautaire, on peut s’attendre à ce que d’autres logiciels gagnent en popularité : Umlaut, un résolveur de lien OpenURL, Blacklight, une interface de découverte à facettes, et Scriblio, un catalogue construit au-dessus de la plate-forme de blog bien connue WordPress.

Bien évidemment, même dans la catégorie du support payant, il y a des différences d’un vendeur à l’autre, et vous devez les évaluer de la même façon que vous le feriez pour un éditeur de logiciel propriétaire. Le service est-il bon ? Pouvez-vous vous le payer ? La société est-elle pérenne ? Avec un logiciel supporté par une société de services, vous pouvez aussi bien n’avoir pas besoin de plus de personnel local qu’il vous en faut pour un logiciel propriétaire. Dans les deux cas, votre succès dépend de la force du logiciel et de celle de la société de services.

Commencez par marcher avant de courir

Quand il existe un support communautaire, il est bien moins risqué d’expérimenter le logiciel qu’avec un logiciel développé en interne, même si bien sûr, selon le logiciel, la communauté est plus ou moins forte et pérenne.

Afin d‘évaluer la force d’une communauté, vous considérerez le nombre d‘établissements qui ont implémenté le logiciel. Vous regarderez en quoi ces établissements sont semblables entre eux et quelles caractéristiques ils partagent avec le vôtre. Vous regarderez le trafic des listes de discussion du projet et s’il y a des contributeurs venant de différents établissements. Plus sa communauté est forte, moins il y a de risque à adopter un logiciel open source et moins vous aurez à compter sur vos propres ressources.

Certains logiciels open source à succès fonctionnent très bien sur un modèle de support communautaire, la plupart des utilisateurs, voire tous, n’ayant jamais besoin des services d’une société. – Il est plaisant de noter à ce propos que le support communautaire fonctionne également pour des solutions propriétaires. Je m’occupe de SIGB propriétaires pour lesquels j’obtiens directement une aide de ses utilisateurs qui est meilleure et plus rapide que celle l‘éditeur lui-même.

Toutefois, il est rare qu’un logiciel qui démarre soit supporté par une communauté. Il doit commencer par être développé quelque part. Un premier établissement doit bien prendre le risque de lancer le projet, rendant à terme un insigne service à la communauté des bibliothèques. Savoir pour un établissement s’il est sage d’adopter un logiciel encore en développement ou de le développer en interne dépend nécessairement des ressources de cet établissement, des capacités de son personnel, de la complexité du projet, de ses besoins, et des conséquences en cas d‘échec.

Si vous vous lancez dans l’adoption ou le développement d’un logiciel, vous devez établir un plan de gestion des risques qui comprenne des actions concrètes et qui prévoit de consacrer des ressources à la construction d’une communauté d’utilisateurs et de développeurs. C’est la raison pour laquelle la conférence Code4Lib, qui s’est tenue cette année à Portland dans l’Orégon, bourdonnait de gens qui lançaient des invitations aux autres participants à rejoindre leurs projets. Mais la construction d’une communauté requiert d’avantage que des actions marketing et autres invitations. Il faut dépenser des ressources afin de rendre le projet facile à adopter. Il faut maintenir un code logiciel qui soit commun et non divergent. Tout doit être mis en œuvre pour faciliter la communication entre les participants.

Tout cela n’est pas que pur altruisme. En partageant au mieux votre projet afin bâtir un scénario de support communautaire, vous défendez vos propres intérêts en terme de gestion du risque. En effet, une fois votre objectif atteint, le risque qu’il y a à adopter votre logiciel décroît pour chacun et pour vous-même.

Portes de sortie

Avec les logiciels open source, vous avez une porte de sortie supplémentaire que vous n’avez pas avec les logiciels propriétaires. Si la société de service qui assure le support ne vous donne pas satisfaction, vous avez le droit de continuer à utiliser le logiciel avec une scénario de support communautaire ou de support interne. Je suis certain que si Horizon 8 avait été open source, le résultat eût été tout autre de ce qu’il a été quand SirsiDynix a décidé de cesser le développement d’un produit quasi achevé, en laissant la plupart de ses utilisateurs dans l’impossibilité légale de le faire fonctionner puisqu’il n‘était pas open source. De plus, si les utilisateurs ne sont pas satisfaits d’une société de support, un marché se crée pour une autre société qui peut facilement prendre le relais, puisqu’elle dispose du code source.

Selon le contexte, il est possible ou non d’emprunter cette porte de sortie. En effet, le scénario de support communautaire a besoin qu’il existe une communauté vivante et dynamique. Bien plus, tout cela est fonction de vos capacités internes et de votre expertise technologique. Vous ne pouvez changer de société de support que s’il y a bien plus d’une société de service travaillant sur votre logiciel, ce qui dépend de nombreux facteurs et particulièrement de la viabilité du marché. Au final, un critère déterminant est la qualité du code de votre logiciel qui doit être bien architecturé, bien écrit et bien documenté.

Dans les cas les plus favorables, cette stratégie de sortie réduit significativement les risques – souvenez-vous que nous parlons ici de gestion du risque. Même dans les cas moins favorables où les alternatives n’existent pas toutes, vous n‘êtes pas, avec votre contrat de maintenance payant, dans une situation moins favorable que vous le seriez avec le contrat équivalent proposé par l‘éditeur d’une solution propriétaire.

Maintenant, j’ajouterais que même si cette possibilité de sortie représente un avantage non négligeable, il est de loin très préférable de ne pas avoir à compter dessus pour quelque chose d’aussi central dans la bonne marche d’une bibliothèque que son SIGB. Fort heureusement, à la fois LibLime et Equinox offrent un support de qualité pour les SIGB open source.

Les SIGB Koha et Evergren, chacun à leur façon, sont passés très rapidement à une situation de support assuré par une société via, respectivement, LibLime et Equinox. Les établissements pionniers ont eu une stratégie de gestion du risque intelligente. Ils n’ont pas manqué de courage et de prévoyance en faisant le pari initial et en engageant les ressources qui ont permis à ces projets open source de passer au statut de logiciel supporté par une société de services. Nous leur sommes redevable de bénéficier aujourd’hui de SIGB open source que nous pouvons adopter sans avoir à encourir les risques qu’ils ont eu à prendre.

Il y a une autre façon pour un produit open source d‘être supporté par une société de services, c’est quand le logiciel provient d’un éditeur solidement établi qui décide de le diffuser sous licence open source. Cela s’est déjà produit avec certains logiciels utilisés par les bibliothèques mais jamais encore avec un logiciel aussi complexe qu’un SIGB. C’est intéressant parce que vous avez un support professionnel. Mais si l‘éditeur tient trop serré les rênes du code officiellement open source, cela rend assez improbable l‘émergence d’une communauté de support et de tous les autres avantages d’un logiciel open source.

Risque et innovation

Un partisan de l’open source, comme moi, ne rendrait pas service aux bibliothèques et n’aiderait pas au succès de l’open source, s’il minimisait les risques et s’il ignorait la nature de ces risques. Il est très vrai que les logiciels open source et le support associé ne conviennent pas à toutes les situations. Comme il est vrai que, dans tout établissement, il y a des situations appropriées pour le logiciel open source idoine. Même l‘établissement le plus prudent se trouvera bien avec un produit open source, dans la mesure où celui-ci sera déployé par une société de services qui donnera le niveau souhaité de garantie. Souvenez-vous qu’un logiciel open source avec un support professionnel ne présente pas plus de risque qu’un logiciel propriétaire.

La gestion du risque consiste parfois à prendre précisément de grands risques. Savoir s’il est sage de courir un risque significatif quant au support de son logiciel dépend, entre autres facteurs, des bénéfices escomptés en cas de succès (avez-vous vraiment besoin de ce logiciel ? quels gains pour vos usagers ?) mais dépend aussi du coût que représenterait un échec. Certains échecs sont riches d’enseignements tandis que d’autres sont juste catastrophiques pour votre établissement. Échec ou succès ? tout dépend en définitive des ressources que vous aurez allouées à l’expérience : temps du personnel, argent, opportunité perdue de poursuivre d’autres options ; et cela dépend également beaucoup de la précision de votre évaluation des risques. Mais ne pas agir est en soi un risque susceptible de devenir très important sur le long terme.

Plus il y aura d‘établissements qui feront des paris raisonnés sur des logiciels développés en interne ou des logiciels supportés par une communauté, plus il y aura d’innovation et meilleurs seront les logiciels dont disposeront nos bibliothèques. Nous commençons d’ailleurs à voir les éditeurs propriétaires réagir et innover en réponse à la menace que représente pour eux l’open source.

La survie même des bibliothèques en tant qu’institutions pertinentes et utiles à l‘ère de la société de l’information dépend directement des innovations dont nous parlons ici. Pour ce qui est des technologies utilisées en bibliothèque, la gestion du risque ne devrait pas être et ne peut pas être uniquement une politique d‘évitement. Les bibliothèques ont bien au contraire besoin de prendre des risques afin de rester pertinentes et utiles à leurs usagers. Dans l’environnement technologique actuel, l’utilisation de logiciels open source est bien souvent la voie d’accès privilégiée à l’innovation.