Le document aborde les enjeux des logiciels open source pour les bibliothèques, explorant les risques, les choix, et les étapes nécessaires à leur adoption. Il analyse le marché français des logiciels libres en bibliothéconomie, met en lumière les défis liés à la migration vers ces outils, et discute des critères économiques et organisationnels à considérer. Enfin, il souligne l'importance d'une analyse préalable rigoureuse et de l'évaluation des communautés de développement pour garantir le succès des projets open source.

1. que signifie aujourd'hui, pour une bibliothèque, monter un projet open source ? Table ronde ABF 21 mai 2010 Laurent Soual (doXulting) [email_address]

2. Sommaire Introduction : contexte et enjeux des logiciels libres en bibliothèque 1 - Une analyse des risques et des choix 2 - Avant le choix : les étapes de décision 3 - Le cahier des charges 4 - La mise en oeuvre

3. Introduction : contexte actuel et enjeux des logiciels libres en documentation et bibliothèque

4. De quoi parle-t-on : ce que je peux faire avec un logiciel libre Ne pas confondre gratuit ( free en anglais) et open source ou libre ( free également en anglais…) un logiciel open source peut être payant un logiciel propriétaire (code source non ouvert), peut être gratuit open source : ce que je peux faire techniquement : étudier le code source pour en comprendre la logique copier des parties de code pour faire un autre logiciel corriger des bugs ajouter des fonctions manquantes améliorer les fonctions existantes l'associer à un autre code supprimer une partie du code... Ce que je peux faire légalement : Utiliser le programme dans mon activité professionnelle, en cours, le donner à des élèves, à des clients le vendre (sans reverser de droits d'auteurs) associé à d'autres logiciels ou intégré dans le code d'un autre produit , ou encore en version modifiée dans le cadre défini par la licence.

5. Etat du marché français Tous secteurs confondus, le logiciel libre atteindrait 10% des dépenses en 2012 , soit une croissance de 32,7% par an. (Source PAC/OPIIEC)

6. Les logiciels libres d’ECM/CMS/GED SIGB Koha PMB Greenstone Outils de diffusion MoCCAM VUFind BlackLight LibraryFind … CMS ECM GED + ou - orientés portail Ez publish Spip (php mysql) ‏ Alfresco(Java) ‏ Nuxeo (J2EE) ‏ Drupal, Typo3… Infrastructure/brique SGBD : MySQL, PostGre... Moteurs de recherche : Lucene,Sol-R, Tsearch... HTTP : Apache Autres : eXist (gestion de bdd xml) ‏ Utilitaires Editeurs XML, gestion de bibliographie, Gestion d'enquête suite bureautique gestion de planning...

7. Le marché GED /ECM / CMS GED WCM COllaboratif RM Work flow SPIP, JOOMLA, DRUPAL,Typo3, eZpublish, Jahia, Nuxeo, Alfresco DAM On dénombre 240 logiciels libres dans le domaine ECM/CMS Marché : prometteur international (européen) concurrentiel

8. Les logiciels libres en bibliothéconomie SIGB Koha PMB Evergreen Outils de diffusion MoCCAM VUFind BlackLight LibraryFind CMS ECM GED + ou - orientés portail Ez publish Spip (php mysql) ‏ Alfresco(Java) ‏ Nuxeo (J2EE) ‏ Drupal … Infrastructure/brique SGBD : MySQL, PostGre... Moteurs de recherche : Lucene,Sol-R, Tsearch... HTTP : Apache Utilitaires Editeurs XML, gestion de bibliographie, Gestion d'enquête suite bureautique gestion de planning...

9. Etat du marché français (suite) Logiciels pour bibliothèques : 42 Millions d’Euros de CA en 2008 (en baisse de 7% par rapport à 2007) Source Tosca consultants 14 logiciels gratuits proposé sur le marché français en 2010 (Source Tosca) dont une minorité sont des logiciels open source au sens strict (PMB, Koha, Evergreen…) dont certains n’ont pas encore d’implémentation connue (Evergreen) les services sur ces logiciels sont offerts par des sociétés bénéficiant d’un quasi-monopole de fait 101 logiciels choisis sur le marché français en 2009, tous types de logiciels, toutes versions (Source Tosca) 1 064 en BM, 25 en BDP, 6 522 en milieu scolaire, 317 en BU, 1 152 en bib. spécialisées BM 47 %, bib. spé. 31 %, écoles 9 % ( hors BCDI )

10. Etat du marché français (suite) Palmarès des SIGB retenus par fournisseurs en 2009 (Source Tosca) BM : C3RB (Orphée) : 145 Décalog (Atalante, Carthame, Paprika) : 102 PMB Service (PMB) : 78 Agate Distribution (Agate, Amandine) : 61 AFI (Pergame) : 58 Bibliothèques spécialisées : CRDP Poitou-Charentes (BCDI) : 258 PMB Services (PMB) : 124 Kentika (Kentika) : 118

11. Choisir le libre n’est plus un aventure mais des logiciels de maturité différentes peu de recul sur le ROI (notamment pour les SIGB) peu de certitude sur la pérennité des communautés un modèle économique en évolution nouveaux acteurs nouvelles postures (redéfinition de la relation client/founisseur, nouveaux processus) Le choix de « passer au libre » : contexte actuel

12. 1 - une analyse des risques et des choix.

13. Tableau des choix Projet traditionnel : Projet LOS : Choix d’un fournisseur Choix d’un logiciel libre ou propriétaire Choix du logiciel Décision de développer des additifs Décision de reverser les additifs Décision de développer des additifs Choix d’un prestataire

14. Quand et pourquoi passer au libre? Quel investissement pour quel ROI? Quels partenaires?

15. On « bascule » dans le libre - Choix lié à l’absence de budget - Ou à la volonté de passer au libre - Procédures ou documents de consultation peu adaptés à une consultation mixte - Budgets ou subventions inadaptés à une consultation mixte (budgets d’investissement ou de fonctionnement) La comparaison entre logiciel libre et propriétaire est une situation encore peu fréquente Quand et pourquoi passer au libre?

16. La couverture fonctionnelle Attente : Un logiciel plus complet ou un logiciel aussi complet mais moins cher Risque : en cas de logiciel immature Phase d’attente Décollage Quand et pourquoi passer au libre?

17. En finir avec le verrouillage éditeur Obligation de faire appel à l’éditeur pour certaines actions par manque de documentation par manque d’ouverture du logiciel Ex : export de données Pression sur les migrations « chantage » au contrat de maintenance arrêt des prestations et non maintien des compétences sur l’ancien produit Rachats prédateurs un produit est racheté par un éditeur dans l’intention de le tuer et de migrer le parc de clients sous son propre produit. Quand et pourquoi passer au libre?

18. Evaluer la capacité de son organisation Le décideur : Culture du modèle libre? Confiance dans la communauté choisie? Le service juridique : Capacité à accepter un autre modèle de résolution de conflit que celui du contentieux? Le service informatique: Confiance dans la qualité des LL? Capacité à revenir à une appropriation technique (ressources, savoir-faire) et non plus à une gestion des externalisations. Capacité à maintenir un niveau de connaissance du produit suffisant pour ne pas être assujetti à un prestataire. Les collaborateurs : Capacité d’acceptation du modèle communautaire et de ses contraintes (tests des produits, tests des mises à jour), capacité à réguler et modérer les demandes d’évolution. Le chef de projet : Disponibilité, conscience des limites de ce qu’il peut contrôler Capacité à endosser la responsabilité sans possibilité de la dériver sur un éditeur Capacité à dire non à certaines demandes d’évolution Quand et pourquoi passer au libre?

19. Cas du ROI direct Quel investissement, quel ROI? ROI DEVELOPPEMENT + + - - Moins on développe, plus le ROI est élevé (et rapide) Attitudes possibles : Choisir un logiciel dont les fonctionnalités correspondent exactement aux besoins fonctionnels (s’il existe) Attendre qu’un logiciel atteigne la couverture fonctionnelle souhaitée Adapter le besoin à l’offre : se contenter des fonctionnalités existantes

20. Cas du ROI par échange Quel investissement, quel ROI? On investit dans le développement jusqu’au moment où la couverture fonctionnelle attire d’autres membres qui développent à leur tour DEVELOPPEMENT + + - - ROI Décollage Implique : Confiance du décideur dans la communauté Très bonne relation avec la communauté Pouvoir attendre un ROI à moyen terme Risque : Que le décollage ne se produise pas Que le décollage se produise trop tard

21. Cas du ROI par notoriété Quel investissement, quel ROI? Les efforts de développements sont compensés par un capital immatériel : notoriété, attention de l’environnement professionnel, situation privilégiée dans la communauté ou dans le réseau d’activité DEVELOPPEMENT + + - - ROI immatériel Avantages : Bénéfice du leadership (individuel ou de la part de l’organisation) Bénéfice du précurseur : la communauté est plus attentive et réactive dans les premières années. Difficulté : Convaincre le décideur

22. Axiome : Il n’y a pas d’opposition tranchée entre éditeur traditionnel et communauté libre Quels partenaires ? Éditeur propriétaire Éditeur libre Éditeur propriétaire Communauté hyper centralisée Communauté centralisée + développeurs périphériques Joyeux bazar

23. En théorie tout le monde peut assurer des prestations de service sur des systèmes ouverts sous licence open source Quels partenaires? le cas du prestataire de service “historique” En pratique celui qui a développé le produit ou qui le suit depuis ses origines sera plus compétitif Pratique courante : Faire appel à la société de service de l’éditeur libre ou du leader de la communauté Risques Non respect de la méthodologie projet (mise en concurrence) Situation de monopole (coûts plus élevés) Dissuasion des nouveaux entrants Risque de verrouillage prestataire

24. Ouvrir largement la consultation à d’autres prestataires Risque : prestataire ne connaissant pas bien les fonctionnalités ou nos métiers Lancer une consultation globale sur les besoins fonctionnels, sans préjuger du produit, open source ou propriétaire Les intégrateurs répondent avec un logiciel libre ou propriétaire de leur choix Peut être le modèle qui se dégagera avec la maturité des LL. Quels partenaires? autres choix

25. Conclusion (provisoire) La fin des processus projets ? Des tâches amont toujours essentielles Des budgets à gérer Des mises en concurrence indispensables L’approche logiciel ne doit pas supplanter l’approche fonctionnelle Des rôles et des responsabilités à définir clairement

26. 2 - Avant le choix

27. Les nouveaux modèles économiques et techniques Le paradoxe du libre (pour l'utilisateur) : Comment exercer la “liberté d'accéder au code source, de l'étudier, de l'adapter » quand on n'est pas informaticien ou que l’on ne dispose pas de ressources internes suffisantes ? en louant les compétences d'un tiers technique. Comment se donner des garanties d'assistance, de correction, d'évolution ? en contractant avec un tiers technique, ou avec une structure issue de la communauté.

28. Les nouveaux modèles économiques et techniques Paradoxe du libre (pour la communauté de développeurs) : en troquant le modèle du bénévolat contre un modèle marchand pour rémunérer les techniciens. Comment « faire le job » quand il y a plus de prescripteurs que de développeurs dans la communauté et qu'il faut en outre assurer une assistance à l'utilisation?

29. La décision Choisir de choisir : on fait le choix du libre un logiciel libre a été évalué et jugé adéquat ou l’offre libre est jugée suffisamment conséquente (cas des ECM, par exemple, et depuis peu des couches OPAC 2.0) mise en œuvre réalisée en interne ou appel à un prestataire Choisir de ne pas choisir : on souhaite mettre en concurrence l’offre libre et l’offre propriétaire l’offre libre n’est pas suffisante ou assez convaincante ou bien l’on souhaite se donner des garanties de mise en œuvre procédure classique de mise en concurrence (appel d’offres)

30. Relativité du critère budgétaire Dans un projet open source les critères budgétaires ne doivent pas être prépondérants coûts d’investissements moindres mais dichotomie charges internes / charges externes coûts de licences nuls ou presque (cas des open source à distribution payante) mais des droits attachés aux licences qui peuvent être complexes Évaluer les coûts cachés investissement temps humain coût interne ou externalisation (études et développements) des mises en œuvre qui s’allongent dans le temps

31. La nécessaire analyse préalable Dans un projet open source le critère organisationnel est crucial un projet open source ne peut être mené sans équipe il n’est plus possible de dériver la responsabilité sur un éditeur (externalisation de la responsabilité) Le « plus » du prototypage Conclusion : le temps passé par les équipes est plus important. On y gagne en adhésion et motivation, on y perd en ressources mobilisées

32. La nécessaire analyse préalable Dans un projet open source on ne peut pas faire l’économie d’une analyse préalable Cette analyse préalable doit répondre aux questions suivantes : l’outil pressenti répond il aux besoins minimaux ? les contraintes ont-elles été analysées ? le contexte organisationnel a-t-il été pris en compte ? si cette étude est externalisée, elle constitue un coût à prendre en compte

33. Evaluer les communautés de développement libre - évaluer la communauté site web, forums, listes de diffusion - critères d’évaluation Mesurer le nombre et la variété des participants Vérifier la proximité d’intérêt des institutions concernées S’assurer de l’importance et du positionnement des développeurs Vérifier que les procédures de contributions sont bien formalisées - identifier les compétences SSLL consultants équipes informatiques dans des établissements parties prenantes de la communauté croiser avec des critères thématiques (qui fait quoi en terme de maintenance évolutive, de reprise de données, d’intégration, …)

34. Recenser et évaluer les communautés de développement libre Caractéristiques des communautés des applications métier (Koha, PMB…) : nombre de membres réduit, parfois concentrés dans une société de service ou dans un établissement membres non techniciens développeurs non praticiens fonctionnalités : diverses, mouvantes utilisateurs en attente d'assistance contexte d'utilisation exclusivement professionnel

35. Evaluer les communautés de développement libre Caractéristiques des communautés d'infrastructures ou des applications transverses (MySQL, Typo3, Alfresco…) : nombre de membres important membres techniciens contributeurs / utilisateurs fonctionnalités homogènes utilisateurs autonomes contextes d'utilisation divers (y compris recherche) ‏

36. 3 - Le cahier des charges

37. Choix a priori : trouver un prestataire Objet du cahier des charges Trouver un prestataire pour la mise en oeuvre du logiciel identifié Type de consultation : prestation de services Options possibles : au forfait implique de connaître parfaitement le logiciel, d’en connaître les limites et les capacités et de définir très précisément la prestation attendue : type de prestation (paramétrages, migration de données, développement, intégration) Si développement, il faut décrire les développements attendus et leur destination (reversement ou non) s’adresse plutôt à des prestataires qui connaissent le métier au temps passé (régie) recrutement d’une compétence technique pour réaliser des prestations qui peuvent ne pas être définies précisément à l’avance ne dispense pas de bien connaître le logiciel et implique un pilotage informatique stricte en interne peut s’adresser à des prestataires qui ne connaissent pas le métier ou le domaine

38. Choix a posteriori : trouver une solution Objet du cahier des charges Acquérir un logiciel et faire assurer sa mise en oeuvre Type de consultation : acquisition et mise en œuvre de logiciel(s) (voire de matériel associé) Options possibles : avec prototypage en tranche ferme prototype sur un nombre restreint de licences prototype sur un nombre limité de fonctions dans les 2 cas, implique disponibilité pour tester le prototype et un planning étiré sans prototypage Autres options possibles : dialogue compétitif envisageable pour des projets novateurs et sans caractère d’urgence Le cahier de charges ne doit pas être un faux nez !

39. 4 - La mise en oeuvre

40. typologie des projets libres et open source Développement collaboratif On développe les fonctions manquantes que l'on reverse à la communauté « Sur étagère » le logiciel est accepté tel que sans modifications. Intégration Plusieurs logiciels Open Source sont associés sous une même interface graphique/ergonomique/fonctionnelle

41. S'éloigner ou non du standard Cas de développements additionnels reversés (et intégrés par la communauté) : Fonctionnement classique d'une communauté, les modifications sont intégrées au logiciel et seront disponibles dans les nouvelles versions . Cas de développements additionnels non reversés ou non intégrés par la communauté : Renoncement aux nouvelles versions. éventuellement création d'un fork. Ou Documentation rigoureuse des additifs et réintégration des ajouts à chaque chargement d'une nouvelle version. Coût récurrent typologie des projets libres et open source

42. Spécificités d’un projet « libre » identification et évaluation des logiciels open source évaluation de la communauté choix du reversement ou non des modifications absence de relation client/fournisseur dans le cas d'un travail direct avec la communauté si prestataire (SSLL) il ne s’engage que sur ses prestations, et non sur l’évolution du logiciel Similitudes avec un projet “propriétaire ” analyse des besoins gestion projet des développements relation client/fournisseur dans le cas d'un recours à une SSII Similitude et spécificités

43. Repenser la relation contractuelle ? L’engagement à l’aune du libre… - Plusieurs acteurs Le commanditaire (maîtrise d’ouvrage) Le prestataire (maîtrise d’œuvre) La communauté Or seul le commanditaire et le prestataire sont liés contractuellement - Un positionnement non étanche Le commanditaire peut faire partie de la communauté Le prestataire également, quand il n’en est pas la composante principale ou le prescripteur en chef La communauté n’est pas sensée connaître le lien contractuel entre le commanditaire et son prestataire… - Quelles seraient les règles de bonne conduite ? Le prestataire ne doit pas s’engager contractuellement sur des évolutions et des développements en sachant que ceux-ci doivent être validés par la communauté sinon, il doit proposer les modalités précises de gestion des développements additionnels Le prestataire ne doit pas invoquer les décisions de la communauté pour ne pas honorer un engagement contractuel Le commanditaire doit se doter de garde fous organisationnels pour que la communauté ne s’immisce pas dans ses arbitrages fonctionnels et techniques et ne lui impose pas son propre calendrier

44. 5 – conclusion dans une période pionnière, le coût d’un projet open source n’est pas nécessairement déterminant par rapport à une solution « propriétaire » le retour sur investissement n’est pas immédiat solution non viable si non portée par une équipe l’avenir du projet open source (retour sur investissement rapide) réside donc dans la mutualisation (consortium, groupements d’achat..) … ce qui est dans la logique communautaire du libre