Symposium Koha – 27 mai 2010 – doXulting p 1 Quelle méthodologie de projet pour lintégration dun produit libre ? 27 mai 2010 Ludovic Méchin (doXulting)

Présentation au sujet: "Symposium Koha – 27 mai 2010 – doXulting p 1 Quelle méthodologie de projet pour lintégration dun produit libre ? 27 mai 2010 Ludovic Méchin (doXulting)"— Transcription de la présentation:

1 Symposium Koha – 27 mai 2010 – doXulting p 1 Quelle méthodologie de projet pour lintégration dun produit libre ? 27 mai 2010 Ludovic Méchin (doXulting) lmechin@doxulting.fr

2 Symposium Koha – 27 mai 2010 – doXulting p 2 1 - Avant le choix : les étapes de décision > Comprendre la nouvelle donne en matière de modèles économiques > La décision : choisir de choisir, choisir de ne pas choisir… > La nécessaire analyse préalable : le critère budgétaire ne suffit pas > Comment recenser et évaluer les communautés de développement libre ? > Essai de typologie des projets de mise en œuvre de logiciels libres > Comment gérer le temps du projet ? : maquettage et démarche itérative, constitution de léquipe projet et évaluation des charges de travail > Repenser la relation contractuelle ? > Postes déconomie et de dépense : maturité du projet, retour sur investissement 2 - Le cahier des charges > Choisir un prestataire > Choisir un logiciel 3 - La mise en oeuvre Sommaire

3 Symposium Koha – 27 mai 2010 – doXulting p 3 1 - Avant le choix

4 Symposium Koha – 27 mai 2010 – doXulting p 4 « 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 Les nouveaux modèles économiques et techniques

5 Symposium Koha – 27 mai 2010 – doXulting p 5 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 lon 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

6 Symposium Koha – 27 mai 2010 – doXulting p 6 experts OS Compétence métier Accompagnement (formation, AMO, conseil) intégration Intégrateurs documentairesIntégrateurs Open Source SSLLConsultants en documentation Les nouveaux modèles économiques et techniques

7 Symposium Koha – 27 mai 2010 – doXulting p 7 Les nouveaux modèles économiques et techniques Paradoxe du libre (pour la communauté de développeurs) > 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? en troquant le modèle du bénévolat contre un modèle marchand pour rémunérer les techniciens

8 Symposium Koha – 27 mai 2010 – doXulting p 8 Choisir de choisir : on fait le choix du libre > un logiciel libre a été évalué et jugé adéquat > ou loffre 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 loffre libre et loffre propriétaire > loffre libre nest pas suffisante ou assez convaincante > ou bien lon souhaite se donner des garanties de mise en œuvre procédure classique de mise en concurrence (appel doffres) La décision

9 Symposium Koha – 27 mai 2010 – doXulting p 9 Dans un projet open source les critères budgétaires ne doivent pas être prépondérants > coûts dinvestissements 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 > il faut se méfier des coûts cachés investissement temps humain coût interne ou externalisation (études et développements) des mises en œuvre qui sallongent dans le temps Relativité du critère budgétaire

10 Symposium Koha – 27 mai 2010 – doXulting p 10 Comparaison nest pas raison ? Ce qui distingue essentiellement les projets open source des projets classiques tient dans la répartition de la part de chaque poste de coût par rapport au coût global du projet Type de coûtsSolutions propriétaires : en % du total des coûts Solutions libres : en % du total des coûts Comparaison des coûts bruts Coûts dinvestissement Matériels et système dexploitation 10 à 20 %20 à 30 % Logiciels substrats (SGBDR, Middleware…) 0 à 15 %0 % Taux supérieurs pour les solutions propriétaires Logiciel métier (SIGB, logiciel documentaire, logiciel darchives, portail, outils multimédia…) 20 à 30 %0 % Prestations externalisées (reprises, paramétrages, formations…) 50 à 70 %10 à 80 % Taux équivalents, peuvent être supérieurs pour les logiciels libres Prestations assurées en interne et autres coûts cachés 10 à 50 %20 à 100 % Taux pouvant être supérieurs pour les logiciels libres Coûts récurrents Maintenance logicielle2 à 10 %0 à 20 % Taux peuvent être supérieurs pour les logiciels libres Veille sur le produit et autres coûts cachés 1 à 5 %0 à 20 % Peuvent être confondus avec la maintenance pour les logiciels libres Hébergement externalisé de lapplication 0 à 5 % Taux équivalents, peuvent être supérieurs pour les solutions propriétaires basées sur des technologies non standard

11 Symposium Koha – 27 mai 2010 – doXulting p 11 Les critères techniques ne peuvent plus être avancés pour refuser de passer au libre > Il est devenu rare que des services informatiques sopposent aujourdhui pour des raisons exclusivement techniques aux solutions libres, puisquils en utilisent de fait (Linux, Apache, Firefox, MySql, PostGre…) > Les éditeurs de logiciels propriétaires intègrent de plus en plus de briques libres soit comme logiciel substrat base de données : MySQL, PostGre moteur HTTP : Apache briques middleware : PHP… Moteur de recherche : Lucene, SOLR soit comme complément à leur offre : exemple Alfresco ou Nuxeo proposés comme module de GED > nativement ouvertes et interopérables, ces briques sont difficilement attaquables sur le plan de la qualité technique La nécessaire analyse préalable

12 Symposium Koha – 27 mai 2010 – doXulting p 12 Dans un projet open source le critère organisationnel est crucial > un projet open source ne peut être mené sans équipe > il nest plus possible de dériver la responsabilité sur un éditeur (externalisation de la responsabilité) > le « plus » du prototypage : même si le retour en arrière est toujours possible : une maquette ne devient pas un prototype si ce dernier nest pas porté par une équipe convaincue et opérationnelle > 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 La nécessaire analyse préalable

13 Symposium Koha – 27 mai 2010 – doXulting p 13 Dans un projet open source on ne peut pas faire léconomie dune analyse préalable > même si le projet open source nentre pas dans les canons projets (budget prévisionnel, cahier des charges, mise en concurrence, validation du choix par une commission dAO), comme cest la cas du choix a priori dun logiciel libre > Cette analyse préalable doit répondre aux questions suivantes : loutil 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

14 Symposium Koha – 27 mai 2010 – doXulting p 14 projet « libre » les jalons de lavant projet

15 Symposium Koha – 27 mai 2010 – doXulting p 15 projet classique les jalons de lavant projet

16 Symposium Koha – 27 mai 2010 – doXulting p 16 é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é dintérêt des institutions concernées > Sassurer de limportance 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, dintégration, …) Recenser et évaluer les communautés de développement libre

17 Symposium Koha – 27 mai 2010 – doXulting p 17 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

18 Symposium Koha – 27 mai 2010 – doXulting p 18 Caractéristiques des communautés d'infrastructures ou des applications transverses (MySQL, Typo3, Alfresco, Drupal…) : > nombre de membres important > membres techniciens > contributeurs / utilisateurs > fonctionnalités homogènes > utilisateurs autonomes > contextes d'utilisation divers (y compris recherche) Recenser et évaluer les communautés de développement libre

19 Symposium Koha – 27 mai 2010 – doXulting p 19 2 - Le cahier des charges

20 Symposium Koha – 27 mai 2010 – doXulting p 20 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, den 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) sadresse plutôt à des prestataires qui connaissent le métier > au temps passé (régie) recrutement dune compétence technique pour réaliser des prestations qui peuvent ne pas être définies précisément à lavance ne dispense pas de bien connaître le logiciel et implique un pilotage informatique stricte en interne peut sadresser à des prestataires qui ne connaissent pas le métier ou le domaine Choix a priori : trouver un prestataire

21 Symposium Koha – 27 mai 2010 – doXulting p 21 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 durgence Choix a priori : trouver un prestataire

22 Symposium Koha – 27 mai 2010 – doXulting p 22 Le cahier de charges ne doit pas être un faux nez ! Un a priori favorable ne doit pas fausser la concurrence : respect de légalité de traitement sur tous les compartiments du cdc > ne pas exiger un accès au code source, ce qui serait déloyal > couverture fonctionnelle réelle si une fonction nexiste pas, le prestataire, éditeur ou prestataire libre, doit sengager sur une date contractuelle > retour « clients » : club utilisateur / communauté > aspects techniques (cadre technique, intégration, interopérabilité) on ne peut pas demander aux éditeurs de sengager sur des performances et sur un environnement matériel et ne pas demander la même chose aux prestataires répondant avec du libre > formation : formation directe des usagers / formation de formateurs > migration des données > conduite de projet et accompagnement idem, les offres doivent être comparées sur ce sujet également > maintenance on doit moduler les exigences en termes de maintenance corrective et évolutive (prévoir différents niveaux de maintenance, en option) on ne peut pas exiger une hot-line performante et la maintenance le samedi, et retenir au final un prestataire qui noffre pas ces garanties > question des développements additionnels difficile de les anticiper, mais le prévoir en incitant les candidats à proposer une démarche (reversement ou non) Choix a posteriori : comment garantir légalité de traitement

23 Symposium Koha – 27 mai 2010 – doXulting p 23 Le cadre de réponse Pas un questionnaire fonctionnel et technique mais Un document de référence contractuelle listant les principales fonctionnalités attendues et demandant pour chacune delle, si elle est disponible dans la version actuelle du logiciel elle fera lobjet dun développement additionnel par le prestataire et livrée à une date ou dans un délai précis dans ce cas préciser les conditions et délais de reversement de ce développement dans une version ultérieure elle fera partie dune prochaine version du logiciel (laquelle, disponible quand ?), engagement contractuel (cas dun éditeur classique) elle est prévue dans une version future, engagement non contractuel (cas dune communauté ou dun éditeur qui na pas encore défini précisément sa road-map de développement) Un document qui sera le support de la recette de lapplication (VSR) Un outil nécessaire

24 Symposium Koha – 27 mai 2010 – doXulting p 24 Comparaison des deux approches A priori : choix dun prestataire approche « libre » : travail avec la communauté, implication dans le développement du logiciel le prestataire est un partenaire, mais il ne doit pas oublier ses engagements contractuels, même sil ne sengage que sur ses prestations, et non sur lévolution du logiciel nécessité de bien se connaître : disponibilité, compétence, investissement Choix de la liberté, au détriment de la sécurité (part de risque) A posteriori : choix dun logiciel approche traditionnelle : on reste dans lexternalisation de la responsabilité et dans le cadre de lengagement contractuel sur le bon fonctionnement du logiciel, relation client/fournisseur classique si on souhaite ouvrir la porte à des offres basées sur un ou plusieurs logiciels libres il faut accepter de moduler, voire modérer certaines exigences, tout en garantissant légalité de traitement entre les candidats en cas de choix dun logiciel libre, il faut accepter de ne pas « faire ce quon veut » avec le logiciel, car le prestataire ne peut sengager sur des évolutions quil ne maîtrise pas Choix de la sécurité, aux dépens de la liberté A priori / a posteriori

25 Symposium Koha – 27 mai 2010 – doXulting p 25 3 - La mise en oeuvre

26 Symposium Koha – 27 mai 2010 – doXulting p 26 Développement collaboratif On développe les fonctions manquantes que l'on reverse à la communauté Type de produit : applications métier immatures ou besoins spécifiques Ressources : Architecture technique (matériel, réseau…), développeur interne (missionné officiellement, compétent et disponible) ou prestataire de service, communauté « intégrante » et dynamique. Coûts : Forfait de développement. Economie sur le coût de licence 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ûts/délai si le volume de développement est sous estimé. Risque d'isolement si la communauté refuse d'intégrer les modifications (fork). typologie des projets libres et open source

27 Symposium Koha – 27 mai 2010 – doXulting p 27 « Sur étagère » le logiciel est accepté tel que sans modifications. Type de produit : Utilitaires, applications matures ou CMS ( si les besoins sont modérés et très classiques Ressources : Architecture technique (matériel, réseau…), ressources internes + aide de la communauté pour l'installation. Coût : très modéré, voire nul, sauf si lon fait appel à une assistance externe pour la mise en oeuvre (paramétrages, formations…) Précaution : en phase « amont » étude très sérieuse des fonctionnalités Risque : si un manque fonctionnel apparaît en cours ou à l'issue du projet : dérive budgétaire ou retour arrière (temps perdu) typologie des projets libres et open source

28 Symposium Koha – 27 mai 2010 – doXulting p 28 Intégration Plusieurs logiciels Open Source sont associés sous une même interface graphique/ergonomique/fonctionnelle Type projet : Infrastructure, applications ou CMS avec besoin spécifique à couvrir Ressources :développeur interne (missionné officiellement, compétent et disponible) ou prestataire de service très compétent en open source. Coût : forfait de développement et dintégration. économie 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. Risque de dérive coût/délai si le volume de développement est mal estimé. typologie des projets libres et open source

29 Symposium Koha – 27 mai 2010 – doXulting p 29 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

30 Symposium Koha – 27 mai 2010 – doXulting p 30 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 Spécificités dun 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 sengage que sur ses prestations, et non sur lévolution du logiciel

31 Symposium Koha – 27 mai 2010 – doXulting p 31 > Temps du projet : moins durgence, planning plus étiré > Maquettage / prototypage facilité et démarche itérative prototypage beaucoup plus facile quavec des logiciels propriétaires part de risques moins importante (benchmarcking, montée en charge) > Caractériser léquipe projet : bibliothécaires, informaticiens (pour la définition du cadre technique notamment) > Evaluer les charges de travail reprise des données (prévoir les itérations) formation, formation de formateurs Paramétrage Intégration scénarisation étape par étape Comment gérer le temps du projet

32 Symposium Koha – 27 mai 2010 – doXulting p 32 Lengagement à laune du libre… Plusieurs acteurs > Le commanditaire (maîtrise douvrage) > 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 nen est pas la composante principale ou le prescripteur en chef > La communauté nest 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 sengager 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 simmisce pas dans ses arbitrages fonctionnels et techniques et ne lui impose pas son propre calendrier Repenser la relation contractuelle ?

33 Symposium Koha – 27 mai 2010 – doXulting p 33 Et pourquoi pas sextraire de la logique institutionnelle…? plusieurs acteurs > des commanditaires (maîtrises douvrage) aux besoins proches > un ou des prestataires (maîtrise dœuvre) > la communauté solution du groupement de commande > mutualisation des développements > économies déchelle > plus de poids auprès du prestataire… > …et de la communauté. quelles modalités ? > convention préalable entre les institutions ou consortium… > stipulant par exemple les développements communs et les prestations communes le sort de ces développements (reversement ou non) les relations avec la communauté > marché avec un volet commun et un volet spécifique propre aux différents membres du groupement > au besoin des lots distincts selon le type de prestation (développement / déploiement par ex.) Repenser la relation contractuelle ?

34 Symposium Koha – 27 mai 2010 – doXulting p 34 Tout dépend du degré de maturité du projet > les projets pionniers ne sont pas forcément plus coûteux en investissement, lobjectif est le retour sur investissement à long terme, à condition de drainer de nouveaux entrants sur la solution (pas de fork) de partager les développements (et leurs coûts) > linvestissement humain est toujours très important, quel que soit le projet et il est rarement chiffré vacataires et intérimaires gens du métier versés dans linformatique (bibliothécaires,documentalistes) informaticiens de métier > à long terme, labsence de contrat de maintenance, qui est le propre des logiciels propriétaires, permet de consacrer, le cas échéant, des moyens à une véritable maintenance évolutive > la présence dune 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 de lexistant postes déconomie et de dépense : maturité du projet et retour sur investissement

35 Symposium Koha – 27 mai 2010 – doXulting p 35 4 – conclusion dans une période pionnière, le coût dun projet open source nest pas nécessairement déterminant par rapport à une solution « propriétaire » le retour sur investissement nest pas immédiat solution non viable si non portée par une équipe lavenir du projet open source (retour sur investissement rapide) réside donc dans la mutualisation (consortium, groupements dachat..) …ce qui est dans la logique communautaire du libre

36 Symposium Koha – 27 mai 2010 – doXulting p 36 Merci de votre attention Avez-vous des questions? lmechin@doxulting.fr