symposium koha – 27 mai 2010 – doxulting p 1 quelle méthodologie de projet pour lintégration...
Post on 03-Apr-2015
104 Views
Preview:
TRANSCRIPT
Symposium Koha – 27 mai 2010 – doXulting p 1
Quelle méthodologie de projet pour Quelle méthodologie de projet pour l’intégration d’un produit libre ?l’intégration d’un produit libre ?
2727 mai mai 20102010
Ludovic Méchin (doXulting)
lmechin@doxulting.fr
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
SommaireSommaire
Symposium Koha – 27 mai 2010 – doXulting p 3
1 - Avant le choix
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'éditeursmécénat de compétencemutualisation de R et D
Nouveaux modèles d'acteurs
Les nouveaux modèles économiques et techniquesLes nouveaux modèles économiques et techniques
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 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
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
SSLL Consultants en documentation
Les nouveaux modèles économiques et techniques
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
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 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)
La décision
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 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
> 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 s’allongent dans le temps
Relativité du critère budgétaire
Symposium Koha – 27 mai 2010 – doXulting p 10
Comparaison n’est 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ûts Solutions propriétaires :
en % du total des coûtsSolutions libres :
en % du total des coûtsComparaison des coûts bruts
Coûts d’investissement
Matériels et système d’exploitation
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 d’archives, 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 logicielle 2 à 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 l’application
0 à 5 % 0 à 5 % Taux équivalents, peuvent être supérieurs pour les solutions propriétaires basées sur des technologies non standard
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 s’opposent aujourd’hui pour des raisons exclusivement techniques aux solutions libres, puisqu’ils 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
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 n’est 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 n’est 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
Symposium Koha – 27 mai 2010 – doXulting p 13
Dans un projet open source on ne peut pas faire l’économie d’une analyse préalable
> même si le projet open source n’entre pas dans les “canons projets” (budget prévisionnel, cahier des charges, mise en concurrence, validation du choix par une commission d’AO), comme c’est la cas du choix a priori d’un logiciel libre
> 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
Symposium Koha – 27 mai 2010 – doXulting p 14
Identification de l’offre en matière de logiciels libres (ycompris sur le plan international)
Approfondissement de la connaissance du produit et de lacommunauté:-téléchargement, installation et premiers tests rapides du produit-évaluation du dynamisme et des règles de fonctionnement de lacommunauté, consultation des usagers si cela est possible-étude des règles de contribution de la communauté
Décision d’évaluation
Elaboration d’un plan –projet pour le maquettageet le prototypage, avec 1ou 2 étapes de validation
ou
Rédaction d’un cahier descharges en vue du choixd’une SSII pour desprestations de mise enœuvre ou en vue uneréalisation en interne (siles ressources existent)
Logiciel open source identifié ?
OKChoix provisoire
OKChoix définitif
KO
Passage en modeclassique : rédactiond’un CCTP et appeld’offres
KO
Définition du contexte, des acteurs concernés, des gainsattendusExpression des besoins et recensement des fonctionsattendues
Définition du contexte techniqueRecensement des contraintes et des performances attendues
Passage en modeclassique : rédactiond’un CCTP et appeld’offres
projet « libre »les jalons de l’avant projet
Symposium Koha – 27 mai 2010 – doXulting p 15
Cahier des charges (CCTP en marché public)
Définition du contexte, des acteurs concernés, des gains attendus Expression des besoins et recensement des fonctions attendues
Définition du contexte technique Recensement des contraintes et des performances attendues
Identification de l’offre, d’après les bancs d’essai, les documents commerciaux, les démonstrations effectuées en amont, les rencontres avec des utilisateurs
Consultation des sociétés dont les produits répondent aux principales contraintes définies dans le cahier des charges fonctionnel et technique
Dépouillement des réponses constitution d’une
« short list » (3 à 5 sociétés), selon procédure
Approfondissement de la connaissance du produit et de la société (selon la procédure) : oraux, démonstration, maquette
Grille de décision
Présentation et validation du choix en Commission des marchés
projet classiqueles jalons de l’avant projet
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é 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, …)
Recenser et évaluer les communautés de développement libre
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
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
Symposium Koha – 27 mai 2010 – doXulting p 19
2 - Le cahier des charges
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, 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
Choix a priori : trouver un prestataire
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 d’urgence
Choix a priori : trouver un prestataire
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 n’existe pas, le prestataire, éditeur ou prestataire libre, doit s’engager 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 s’engager 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 n’offre 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
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 d’elle, si
• elle est disponible dans la version actuelle du logiciel• elle fera l’objet d’un 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 d’une prochaine version du logiciel (laquelle, disponible quand ?), engagement
contractuel (cas d’un éditeur classique)• elle est prévue dans une version future, engagement non contractuel (cas d’une communauté
ou d’un éditeur qui n’a pas encore défini précisément sa road-map de développement)
Un document qui sera le support de la recette de l’application (VSR)
Un outil nécessaire
Symposium Koha – 27 mai 2010 – doXulting p 24
Comparaison des deux approches
A priori : choix d’un 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 s’il ne s’engage 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 d’un logiciel
• approche traditionnelle : on reste dans l’externalisation de la responsabilité et dans le cadre de l’engagement 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 d’un logiciel libre, il faut accepter de ne pas « faire ce qu’on veut » avec le logiciel, car le prestataire ne peut s’engager sur des évolutions qu’il ne maîtrise pas
• Choix de la sécurité, aux dépens de la liberté
A priori / a posteriori
Symposium Koha – 27 mai 2010 – doXulting p 25
3 - La mise en oeuvre
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
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 l’on 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
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 d’inté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
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
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 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
Symposium Koha – 27 mai 2010 – doXulting p 31
> Temps du projet : moins d’urgence, planning plus étiré
> Maquettage / prototypage facilité 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é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
Symposium Koha – 27 mai 2010 – doXulting p 32
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
Repenser la relation contractuelle ?
Symposium Koha – 27 mai 2010 – doXulting p 33
Et pourquoi pas s’extraire de la logique institutionnelle…? plusieurs acteurs
> des commanditaires (maîtrises d’ouvrage) 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 ?
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, l’objectif 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)
> l’investissement 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 l’informatique (bibliothécaires,documentalistes)• informaticiens de métier
> à long terme, l’absence 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 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 de l’existant
postes d’économie et de dépense : maturité du projet et retour sur investissement
Symposium Koha – 27 mai 2010 – doXulting p 35
4 – 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 équipel’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
Symposium Koha – 27 mai 2010 – doXulting p 36
Merci de votre attention
Avez-vous des questions?
lmechin@doxulting.fr
top related