Symposium Koha – 27 mai 2010 – doXulting p 1 Quelle méthodologie de projet pour lintégration...

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)

[email protected]


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


1 - Avant le choix


« 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


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


experts OS Compétence métier

Accompagnement (formation, AMO, conseil)

intégration

Intégrateurs documentairesIntégrateurs Open Source

SSLL Consultants en documentation




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


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


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


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


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


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



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



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


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


é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


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



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)



2 - Le cahier des charges


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


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


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


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


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


3 - La mise en oeuvre


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


« 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)



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



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



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


> 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


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 ?


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 ?


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


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


Merci de votre attention

Avez-vous des questions?

[email protected]

Symposium Koha – 27 mai 2010 – doXulting p 1 Quelle méthodologie de projet pour lintégration...

Documents

Transcript of Symposium Koha – 27 mai 2010 – doXulting p 1 Quelle méthodologie de projet pour lintégration...