Mener un projet open source en bibliothèque, documentation et archives ADBS-Lorraine 27 mars 2008 Claire Scopsi et Ludovic Méchin

Présentation au sujet: "Mener un projet open source en bibliothèque, documentation et archives ADBS-Lorraine 27 mars 2008 Claire Scopsi et Ludovic Méchin"— Transcription de la présentation:

1 Mener un projet open source en bibliothèque, documentation et archives ADBS-Lorraine 27 mars 2008 Claire Scopsi et Ludovic Méchin claire.scopsi@cnam.fr lmechin@doxulting.fr

2 Sommaire Spécificités d'un projet d'implantation d'un logiciel libre ou open source. Rapide définition des logiciels libres et open source : implications juridiques, et techniques. Evolution des développements et nouveaux modèles économiques et techniques. Comment les logiciels libres s'intègrent-ils dans les systèmes d'information des professionnels de la documentation et des bibliothèques? En quoi un projet d'implantation d'un logiciel libre ou open source diffère de celui d'un logiciel propriétaire?

3 Sommaire Méthodologie de conduite d’un projet libre. La nécessaire analyse préalable : pourquoi l’aspect budgétaire ne peut être le seul critère de décision Comment gérer le temps du projet ? : maquettage et démarche itérative, constitution de l’équipe projet et évaluation des charges de travail. Comment recenser et évaluer les communautés de développement libre ? Postes d’économie et de dépense : maturité du projet libre et retour sur investissement 1ère étude de cas : L’Ecole des Mines de Paris 2e étude de cas : les Universités d’Aix-Marseille

4 I Spécificités d'un projet d'implantation d'un logiciel libre ou open source.

5 I 1 - Evolution des développements et nouveaux modèles économiques et techniques Naissance d'un concept 1969 Création du système d'exploitation UNIX 1973 Diffusion d'Unix dans les universités américaines, qui corrigent le programme. 1982 Commercialisationd'UNIX par AT&T 1983 Richard Stallman lance le projet GNU (Unix libre) ‏ 1985 Richard Stallman conceptualise le « libre » en créant la Free Software Foundation 1991 Linus Torvald lance le projet Linux 1992 – 2003 Série de procès entre les sociétés commerciales détentrices de code UNIX 1997 Création de l'Open Source Initiative

6 I 1 - Rapide définition des logiciels libres et open source. Implications juridiques, et techniques. Définitions Le Logiciel libre répond aux 4 critères de la Free Software Foundation (Richard Stallman) : - la liberté d'exécuter le programme pour tous types d'usages. - la liberté d'accéder au code source, de l'étudier, de l'adapter. - la liberté de distribuer des copies du programme, modifié ou non, gratuitement ou non - la liberté d'améliorer le programme et de publier ces améliorations. Logiciel propriétaire : Un logiciel qui ne répond pas à toutes les conditions du logiciel libre est dit « propriétaire ». Logiciel compilé : De nombreux programmes sont livrés sous une forme compilée, i.e. une traduction des sources dans un autre langage afin: - de permettre une meilleure exécution - d'interdire la lecture des sources. Pour mériter l'appellation « libre » un tel logiciel doit fournir ses sources sous une forme accessible en plus de la version compilée.

7 I 1 - Rapide définition des logiciels libres et open source. Implications juridiques, et techniques. Le logiciel open source : Depuis 1997, l'Open Source Initiative (Bruce Perens, Eric Steven Raymond) précise et cadre les critères des logiciels libres, dans l'objectif d'une exploitation commerciale: 1. Libre Redistribution 2. Code Source 3. Applications Dérivées 4. Intégrité du Code Source de l'Auteur 5. Pas de Discrimination Contre des Personnes ou des Groupes 6. Pas de Discrimination Contre des Domaines d'Application 7. Distribution de la Licence 8. La Licence ne doit pas être Spécifique à un Produit 9. La Licence ne doit pas Affecter d'Autres Logiciels 10. La Licence doit être Technologiquement Neutre

8 I 1 - Rapide définition des logiciels libres et open source. Implications juridiques, et techniques. Ne pas confondre Free Software (logiciel libre) et freeware (logiciel gratuit). Les logiciels libres ne sont pas obligatoirement gratuits (même si de fait ils le sont le plus souvent!). La différence entre Logiciel Libre et Open Source est négligeable. Certains ont même forgé l'acronyme FLOSS (Free/Libre and Open Source Software). Un Freeware (gratuiciel) est toujours gratuit, mais son code n'est pas toujours ouvert. Les licences libres (ex Cecill, GPL..) précisent les conditions d'utilisation des LL dans le cadre défini par l'OSI. L' OSI évalue et certifie la conformité de ces licences avec son modèle

9 I 1 - Rapide définition des logiciels libres et open source. Implications juridiques, et techniques. 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, encours, 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. Si on associe des codes sources d'origines diverses, il faut donc faire attention à ce que l'utilisation soit conforme à toutes les licences.

10 I 2 - Evolution des développements et nouveaux modèles économiques et techniques En France, le chiffre d'affaires du logiciel libre en 2007 est de 730 millions d'euros. Rapportés aux 30 milliards du marché du logiciel, cela représente 2,4% de part de marché (contre 1,5% en 2006).chiffre d'affaires

11 I 2 - Evolution des développements et nouveaux modèles économiques et techniques 1991 2008 noyau Infrastructure Applicatif/ métier GNU 1991 GNU/Linux 1994 WikiWiki 1995 Mozilla 1998 OpenOffice.org 2000 Apache 1995 Applicatif/ généraliste Lucene 2000 PostgreSQL 1995/96 Mysql 1995 The GIMP 1996/98 Greenstone 2000 PMB 2002 Typo3 1997 SPIP 2001 Claroline 2000 Koha 1999 Moccam 2002 Alfresco 2005 NCSA httpd 1993

12 I 2 - Evolution des développements et nouveaux modèles économiques et techniques Caractéristiques des communautés d'infrastructures : - nombre de membres important - membres techniciens - contributeurs / utilisateurs - fonctionnalités homogènes - utilisateurs autonomes - contextes d'utilisation divers (y compris recherche) ‏

13 I 2 - Evolution des développements et nouveaux modèles économiques et techniques Caractéristiques des communautés des applications métier : - nombre de membres réduit - membres non techniciens - développeurs non praticiens - fonctionnalités : diverses, mouvantes - utilisateurs en attente d'assistance - contexte d'utilisation exclusivement professionnel

14 I 2 - Evolution des développements et 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?

15 I 2 - Evolution des développements et nouveaux modèles économiques et techniques Nouveaux modèles d'acteurs : « libres » « open » collaboratifs centralisés « open-éditeur » Licence gratuite Services payants « génial bidouilleur » bénévolat communauté libre échange de compétences consortium d'éditeurs mécénat de compétence mutualisation de R et D Nouveaux modèles d'acteurs :

16 I 2 - Evolution des développements et nouveaux modèles économiques et techniques 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? En louant les compétences d'un tiers technique. Comment rassurer l'entreprise et lui donnant des garanties d'assistance, de correction, d'évolution? En contractant avec un tiers technique, ou avec une structure issue de la communauté.

17 I 2 - Evolution des développements et nouveaux modèles économiques et techniques experts OS Compétence métier Accompagnement (formation, AMO, conseil)‏ intégration Intégrateurs documentairesIntégrateurs Open Source SSLLConsultants en documentation

18 I 3 - Comment les logiciels libres s'intègrent dans les systèmes d'information des professionnels de la documentation et des bibliothèques. Les familles de logiciels libres « documentaires » SIGB Koha PMB Evergren Gnuteca CMS documentaires + ou -orientés portail Spip(php mysql)‏ Alfresco(Java)‏ Nuxeo (J2EE)‏ Freedom Infrastructure Lucene (moteur de recherche)‏ Utilitaires Editeurs XML, gestion de bibliographie, Gestion d'enquête

19 I 3 - Comment les logiciels libres s'intègrent dans les systèmes d'information des professionnels de la documentation et des bibliothèques. Le « malgré-lui » Les 4 têtes de l'utilisateur de logiciels libres Le « sans le savoir » Le « faute de mieux» Le volontaire

20 I 3 - Comment les logiciels libres s'intègrent dans les systèmes d'information des professionnels de la documentation et des bibliothèques. Bricoleur Les 4 profils de l'utilisateur volontaire Radin Idéaliste Opportuniste

21 I 4 - A chaque nature de projet ses ressources et son coût Développement collaboratif On développe les fonctions manquantes que l'on reverse à la communauté Ressources : Développeur interne (missionné officiellement, compétent et disponible) ou prestataire de service, communauté « intégrante » et dynamique. Coût du forfait de développement. Economie du coût de licence Type produit : SIGB ou CMS immature ou besoins spécifiques. Précautions : en phase « amont » : étude très sérieuse des fonctionnalités, de la vitalité de la communauté et de ses règles de contribution. Savoir estimer le temps de développement et contrôler le respect de cette estimation. Risque de dérive coût/délai si le volume de développement est sous estimé. Risque d'isolement si la communauté refuse d'intégrer les modifications.

22 « Sur étagère » le logiciel est accepté tel que sans modifications. Ressources : Machines, ressources internes + aide de la communauté pour l'installation Coût très modéré, voire nul Précaution : en phase « amont » étude très sérieuse des fonctionnalités Type produit : Utilitaires ou SIGB ou CMD mature si les besoins sont modérés et très classiques‏ Risque : si un manque fonctionnel apparaît en cours ou à l'issue du projet : dérive budgétaire. I 4 - A chaque nature de projet ses ressources et son coût

23 Intégration Plusieurs logiciels Open Source sont associés sous une même interface graphique/ergonomique/fonctionnelle Coût du forfait de développement. Economie du coût de licence Précaution :Très bonne connaissance des logiciels de base, de leur interopérabilité, de la compatibilité de leurs licences. Savoir estimer le temps de développement et contrôler le respect de cette estimation. Type projet : Infrastructure, ou CMS avec besoin spécifique à couvrir Risque de dérive coût/délai si le volume de développement est mal estimé. Ressources :développeur interne (missionné officiellement, compétent et disponible) ou prestataire de service très compétent en open source. I 4 - A chaque nature de projet ses ressources et son coût

24 Un choix fondamental : 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. Eventuellement création d'un fork. Ou Documentation rigoureuse des additifs et réintégration de ajouts à chaque chargement d'une nouvelle version. I 4 - A chaque nature de projet ses ressources et son coût

25 Spécificités - identification et évaluation des logiciels - l'évaluation de la communauté - le choix du reversement ou non des modifications. - l'absence de relation client/fournisseur dans le cas d'un travail direct avec la communauté Similitudes - analyse des besoins - la gestion projet des développements -la relation client/fournisseur dans le cas d'un recours à une SSLL

26 Merci de votre attention Avez-vous des questions? claire.scopsi@cnam.fr

27 II Méthodologie de conduite d’un projet libre.

28 II 1 - La nécessaire analyse préalable : pourquoi l’aspect budgétaire ne peut être le seul critère de décision Les critères budgétaires ne sont pas déterminants bien qu’un projet open-source ait des coûts d’investissements moindres dichotomie charges internes / charges externes bien que les coûts de licences soient nuls ou presque pas de licences sauf dans le cas d’open source payants car il faut se méfier des coûts cachés investissement temps humain coût interne ou externalisation

29 II 1 - La nécessaire analyse préalable : pourquoi l’aspect budgétaire ne peut être le seul critère de décision

30 Les critères techniques ne sont plus déterminants Il est très rare que des services informatiques s’opposent aujourd’hui techniquement aux solutions libres, puisqu’ils en utilisent de fait (Linux, Apache, Firefox, MySql, PostGre) Les éditeurs de logiciels propriétaires intégrent des briques libres (EverTeam, Jouve, Cadic, …) Même le monde Mac s’émancipe avec Mac OS X (implémentation libre d’Unix)

31 II 1 - La nécessaire analyse préalable : pourquoi l’aspect budgétaire ne peut être le seul critère de décision Le critère organisationnel est en revanche crucial Un projet open source ne peut être mené sans équipe Il n’est plus possible de dériver la responsabilité sur un éditeur Même si le retour en arrière est toujours possible : une maquette ne devient pas un prototype si ce dernier n’est pas porté par une équipe convaincue et opérationnelle

32 II 1 - La nécessaire analyse préalable : pourquoi l’aspect budgétaire ne peut être le seul critère de décision On ne peut faire pas l’économie d’une analyse préalable même si elle ne rentre pas dans les “canons projets” (budget prévisionnel, cahier des charges, mise en concurrence, validation du choix par une commission d’AO) Pour autant 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 ?

33 II 2 – Comment gérer le temps du projet : maquettage et démarche itérative, constitution de l’équipe projet, évaluation des charges de travail - Le temps du projet, moins d’urgence, plus long - Maquettage facilité (pas besoin de prêt de logiciel) et démarche itérative : prototypage beaucoup plus facile qu’avec des logiciels propriétaires, part de risques moins importante (benchmarcking, montée en charge) - Caractériser l’équipe projet : bibliothécaire, informaticiens - Evaluer les charges de travail : reprise des données, formation, paramétrage, scénarisation étape par étape - Impact sur l’appel d’offres (démarche open source pressenti / démarche classique)

34

35

36 II 3 – Comment recenser et évaluer les communautés de développement libre. - Evaluer 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 Valider que les procédures de contributions des uns et des autres est bien formalisée - Identifier les compétences SSLL consultants équipes informatiques dans des établissements croiser avec des critères thématiques (qui fait quoi en terme de maintenance évolutive, de reprise de données, d’intégration, …)

37 II 4 – Postes d’économie et de dépense : maturité du projet libre et retour sur investissement. Tout dépend du degré de maturité du projet - Les projets pionniers ne sont pas forcément mois coûteux en investissement, l’objectif est le retour sur investissement à long terme Nouveaux entrants Partage des développements - L’investissement humain est important, quel que soit le projet et il est rarement chiffré Vacataires Bibliothécaire informaticien - A long terme, l’absence de contrat de maintenance propre aux logiciels propriétaires permet de consacrer, le cas échéant, des moyens à une véritable maintenance évolutive - La présence d’une communauté active permet de disposer de modules qui seraient chiffrés auprès d’éditeurs propriétaires - En cas de réinformatisation après un épisode libre, pas de chantage de l’éditeur sur la reprise des données

38 II 5 – 1ère Etude de cas : l’Ecole des Mines de Paris. - Contexte favorable Environnement technique hétérogène Logiciel non maintenu Enveloppe budgétaire limitée - Décisions affirmées Analyse préalable (l’essentiel, le superflu) L’harmonisation des données L’observation de Koha - La démarche Installation du logiciel Maquettage itératif, tests, pédagogie Développements, réflexion sur le support Mise en exploitation définitive au bout de 15 mois - Analyse Une équipe impliquée Un projet assez coûteux en assistance et en développement mais plus économique que s’il y avait eu appel d’offres Un effet d’entraînement notable Un retour sur un investissement qui se profile

39 II 6 – 2e Etude de cas : les Universités d’Aix-Marseille - Contexte Etude préalable pour la gestion commune des bibliothèques 2 options : 1 SIGB / 3 SIGB et une couche fédératrice Choix d’un SIGB unique avec un périmètre précis (couches basses) - Préparation du cahier des charges Visites de sites Démonstrations produits Intérêt pour le libre (VP mais aussi bibliothécaires) - Lotissement du cahier des charges Un lot ferme prototype (20 bibliothèques) Un lot optionnel : toutes les bibliothèques Souplesse du Cahier des charges de manière à ce que des prestataires libres puissent répondre - Un libre en BU ? Appel d’offres paru Ouverture des plis le 14 avril...

40 Merci de votre attention Avez-vous des questions? lmechin@doxulting.fr