Comment monter et vendre un projet open source à sa direction #1 – Les finances

Cet article a été publié il y a 16 ans 10 mois 7 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Voici le premier article d’une petite série. L’objectif est de vous donner des pistes et des axes de réflexion pour vous aider à vendre un projet open source à votre Direction. Mais ne vous attendez pas à un mode d’emploi 🙂 car le contexte doit aussi vous guider. Au passage je vous donnerais quelques conseils issues de mon expérience professionnelle.

L’idée de cet article m’est venue en échangeant avec redolive qui nous relatait ces « malheurs » dans le cadre de la mise en place d’une solution open source.

Dans l’absolu la conduite d’un projet open source ne diffère guère de celle d’un projet mettant en oeuvre des outils propriétaires. Vous ne couperez donc à aucune des phases classiques de recueil des besoins, d’analyse, de recherche de solutions et de vérification de l’adéquation du logiciel au besoin.

Car ne nous y trompons pas, choisir un logiciel open source juste parce qu’il est open source sans s’assurer de son adéquation aux besoins est un bon moyen d’aller dans le mur. Il peut y avoir des situations où même si cela va à l’encontre de vos convictions, un logiciel propriétaire sera mieux adapté. Mais nous parlons là de convictions personnelles et elles n’ont pas forcément droit de citer dans un cadre strictement professionnel du moins pas comme critère unique de décision.

Au passage, j’en profite pour éclaircir un autre point, je parle ici de logiciel open source. Je vous renvoie vers l’article de Jonathan Le Lous : Du logiciel libre à l’open source: de l’éthique à l’économie qui exprime très bien mon point de vue à ce sujet.

Je raisonne donc ici en faisant volontairement abstraction du besoin fonctionnel et technique, car je le considère comme satisfait par la solution open source que vous avez retenu.

Venons-en donc au volet budgétaire.

Il doit être tout particulièrement soigné surtout si vous êtes amené à comparer des solutions propriétaires et open source. Il  faut montrer et mettre en évidence les différences qui existent dans la structure des coûts entre ces deux solutions. Et puis soyons honnêtes, c’est souvent le chapitre qui est le plus épluché lorsque l’on en arrive au stade de la décision même s’il n’est pas le seul critère.

Pour une solution open source, le poste licence est en général nul. Je dis en général,car certaines solutions open source ont un coût de licence lorsque l’on souhaite les utiliser à des fins commerciales. Citons par exemple la base de données MySQL.

Viennent ensuite les prestations sauf si vous êtes à même de réaliser vous-même l’installation du logiciel. Si vous décidez de prendre en charge la mise en œuvre, assurez-vous d’en avoir réellement les compétences et ne vous contentez pas des tutoriels ou How-To que vous pourriez avoir trouvé sur Internet pour faire baisser le coût de votre projet. N’hésitez pas à intégrer des coûts de formation que ce soit pour vous ou pour les utilisateurs surtout si vous touchez au poste de travail et aux outils qui leurs sont mis à disposition. D’autant que ces formations peuvent passer sur le budget correspondant dans votre société et améliorer de cette façon le coût final.

Les économies réalisées sur les licences doivent vous permettre de vous faire  accompagner techniquement alors surtout n’hésitez pas à faire appel à une Société de Service en Logiciel Libre (SSLL ou SS2L).

Finissons par  les coûts de maintenance. Là encore deux solutions : vous faites en interne ou vous souscrivez un contrat de support auprès de l’éditeur du logiciel open source. Ils le proposent tous aujourd’hui. Dans le cas des logiciels communautaires vous pouvez aussi faire appel à une SSLL pour cela.

En résumé, ne faites pas d’économie sur les prestations même si leur montant est supérieur à ce que vous proposerez un prestataire pour la mise en place d’un logiciel propriétaire. C’est un point à mettre en avant : plus de service grâce aux économies sur les licences, pour un projet  en principe mieux accompagné donc aux chances de succès optimal. Je sais que ce n’est pas une garantie mais c’est mieux que de partir avec en déficit en assistance parce que les licences ont dévorées tout le budget.

La présentation budgétaire doit au final montrer une comparaison des coûts sur au moins trois ans voir cinq ans car c’est là aussi que les solutions open source se distinguent surtout si vous prévoyez une extension du périmètre de déploiement de votre application dans les années qui suivent.

Je m’en arrêterais là pour ce billet. Il y a bien sur tout un argumentaire autour des logiciels open source. Je tenterais de vous les indiquer dans un prochain billet.