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

L soual abf 21 mai 2010_opensource

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: L soual abf 21 mai 2010_opensource

que signifie aujourd'hui, pour une que signifie aujourd'hui, pour une bibliothèque, monter un projet open bibliothèque, monter un projet open

source ?source ?

Table ronde ABFTable ronde ABF2121 mai mai 20102010

Laurent Soual (doXulting)

[email protected]

Page 2: L soual abf 21 mai 2010_opensource

Sommaire

Introduction : contexte et enjeux des logiciels libres en bibliothèque1 - 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

Page 3: L soual abf 21 mai 2010_opensource

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

Page 4: L soual abf 21 mai 2010_opensource

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.

Page 5: L soual abf 21 mai 2010_opensource

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)

Page 6: L soual abf 21 mai 2010_opensource

SIGBKohaPMB

Greenstone

Outils de diffusionMoCCAMVUFind

BlackLightLibraryFind

CMS ECM GED+ ou - orientés portail

Ez publishSpip (php mysql)Alfresco(Java)Nuxeo (J2EE)

Drupal, Typo3…

Infrastructure/brique

SGBD : MySQL, PostGre...Moteurs de recherche : Lucene,Sol-R, Tsearch...

HTTP : ApacheAutres : eXist (gestion de bdd xml)

Utilitaires

Editeurs XML,gestion de bibliographie,

Gestion d'enquêtesuite bureautique

gestion de planning...

Les logiciels libres d’ECM/CMS/GED

Page 7: L soual abf 21 mai 2010_opensource

Le marché GED /ECM / CMS

SPIP, JOOMLA, DRUPAL,Typo3, eZpublish, Jahia,

Nuxeo, Alfresco

On dénombre 240 logiciels libres dans le domaine ECM/CMS

Marché : prometteur international (européen) concurrentiel

Page 8: L soual abf 21 mai 2010_opensource

Les logiciels libres en bibliothéconomie

SIGBKohaPMB

Evergreen

Outils de diffusionMoCCAMVUFind

BlackLightLibraryFind

CMS ECM GED+ ou - orientés portail

Ez publishSpip (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êtesuite bureautique

gestion de planning...

Page 9: L soual abf 21 mai 2010_opensource

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)

Page 10: L soual abf 21 mai 2010_opensource

Etat du marché français (suite)

Palmarès des SIGB retenus par fournisseurs en 2009 (Source Tosca) BM :

1. C3RB (Orphée) : 145

2. Décalog (Atalante, Carthame, Paprika) : 102

3. PMB Service (PMB) : 78

4. Agate Distribution (Agate, Amandine) : 61

5. AFI (Pergame) : 58 Bibliothèques spécialisées :

1. CRDP Poitou-Charentes (BCDI) : 258

2. PMB Services (PMB) : 124

3. Kentika (Kentika) : 118

Page 11: L soual abf 21 mai 2010_opensource

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

Page 12: L soual abf 21 mai 2010_opensource

1 - une analyse des risques et des choix.

Page 13: L soual abf 21 mai 2010_opensource

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

Page 14: L soual abf 21 mai 2010_opensource

Quand et pourquoi passer au libre?

Quel investissement pour quel ROI?

Quels partenaires?

Page 15: L soual abf 21 mai 2010_opensource

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?

Page 16: L soual abf 21 mai 2010_opensource

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?

Page 17: L soual abf 21 mai 2010_opensource

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édateursun 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?

Page 18: L soual abf 21 mai 2010_opensource

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?

Page 19: L soual abf 21 mai 2010_opensource

Cas du ROI direct

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

Quel investissement, quel ROI?

Page 20: L soual abf 21 mai 2010_opensource

Cas du ROI par échange

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 pasQue le décollage se produise trop tard

Quel investissement, quel ROI?

Page 21: L soual abf 21 mai 2010_opensource

Cas du ROI par notoriété

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

+

+

-

-

ROIimmaté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

Quel investissement, quel ROI?

Page 22: L soual abf 21 mai 2010_opensource

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étaireCommunauté

hyper centralisée

Communauté centralisée

+ développeurspériphériques

Joyeux bazar

Page 23: L soual abf 21 mai 2010_opensource

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

Page 24: L soual abf 21 mai 2010_opensource

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

Page 25: L soual abf 21 mai 2010_opensource

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

Page 26: L soual abf 21 mai 2010_opensource

2 - Avant le choix

Page 27: L soual abf 21 mai 2010_opensource

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é.

Les nouveaux modèles économiques et techniques

Page 28: L soual abf 21 mai 2010_opensource

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?

Les nouveaux modèles économiques et techniques

Page 29: L soual abf 21 mai 2010_opensource

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)

Page 30: L soual abf 21 mai 2010_opensource

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

Page 31: L soual abf 21 mai 2010_opensource

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

Page 32: L soual abf 21 mai 2010_opensource

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

La nécessaire analyse préalable

Page 33: L soual abf 21 mai 2010_opensource

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, …)

Page 34: L soual abf 21 mai 2010_opensource

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

Recenser et évaluer les communautés de développement libre

Page 35: L soual abf 21 mai 2010_opensource

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)

Evaluer les communautés de développement libre

Page 36: L soual abf 21 mai 2010_opensource

3 - Le cahier des charges

Page 37: L soual abf 21 mai 2010_opensource

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

Page 38: L soual abf 21 mai 2010_opensource

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 !

Page 39: L soual abf 21 mai 2010_opensource

4 - La mise en oeuvre

Page 40: L soual abf 21 mai 2010_opensource

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

Page 41: L soual abf 21 mai 2010_opensource

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

Page 42: L soual abf 21 mai 2010_opensource

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

Page 43: L soual abf 21 mai 2010_opensource

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

Page 44: L soual abf 21 mai 2010_opensource

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