Contrats de prestations de services et open source

Au cours de mes lectures je suis tombé sur un article anglais qui m’a rappelé les quelques années passées à faire des prestations de services. Ce furent les huit premières années de ma vie professionnelle.

Je travaillais pour une petite société lyonnaise qui éditait un logiciel de Gestion Electronique de Documents. Je participais à son développement, sa commercialisation et sa mise en place chez les clients. Il s’agissait alors d’un logiciel propriétaire (c’est toujours le cas d’ailleurs). Cette double casquette d’éditeur et d’intégrateur me permettait de travailler avec la même souplesse que si j’avais utilisé des logiciels libres. Je pouvais en effet modifier ou corriger le code du logiciel selon mon bon vouloir. Peut-être faut-il y voir une raison de mon manque d’intérêt à leur égard à l’époque. Mais passons ce n’est pas vraiment le sujet de l’article.

Avant tout je vais comme l’auteur de l’article initial bien préciser que je ne suis PAS un juriste. Cet article n’a donc pas pour vocation de définir ce que peut ou doit-être un contrat de prestations de services incluant des logiciels open source. Il s’agit essentiellement de mettre à plat les spécificités de ce cas de figure.

Le délivrable

Dans le cadre d’un contrat de prestations de services réalisée en mode projet, c’est à dire avec un engagement de résultat, on définit en général ce qui va constituer le délivrable. Le prestataire s’engage à fournir ce dernier conformément à un cahier des charges fournit par le client et annexé au contrat.

Ce délivrable dans le cas de la mise en place d’une solution open source pourra inclure :

• un logiciel open source standard,
• des développements spécifiques impliquant soit des modifications dans le logiciel soit des développements autour du logiciel open source ,

La garantie

Les termes de la garantie précisent comment et sous quels délais seront corrigés les anomalies détectées après la mise en production et la durée durant laquelle le prestataire s’engage à les traiter. C’est ici qu’il faut commencer à être vigilant dans les clauses décrivant la couverture des corrections. En effet, votre garantie couvre-t-elle les anomalies du logiciel open source ou seulement les développements que vous avez réalisés ?

C’est un point important à négocier avec le client qui bien souvent souhaitera que votre garantie couvre l’ensemble de la solution. Etes-vous capable de prendre en charge les bugs détectés dans le logiciel open source et de les corriger ?

J’en profite pour changer de casquette et me placer coté client. C’est un point qu’il faut creuser avec le prestataire. C’est d’autant plus vrai si le logiciel est maintenu par une communauté et pas par un éditeur open source qui peut proposer des contrats de maintenance avec des engagements en termes de délais de résolution d’incidents.

Dans le cas du logiciel communautaire, il n’y a pas d’engagements de résultat. Si vous trouvez un bug, vous pouvez le soumettre et si votre prestataire n’est pas en mesure de le corriger , il vous faudra patienter une correction plus ou moins longtemps selon la réactivité de la communauté de ce logiciel. Une incertitude qui sur des applications critiques n’est pas concevable.

A bien réfléchir pour les deux parties, car en cas de problème, il faudra passer au chapitre suivant.

Les indemnités

Si dans le chapitre précédent vous avez décidé d’exclure le logiciel open source de la garantie, il faudra prendre le soin de l’exclure aussi dans ce chapitre. Reste le problème des brevets logiciels qui peuvent être enfreins soit par le code que vous aurez fourni soit par celui du logiciel open source. Je ne m’avancerais pas trop sur ce sujet car je ne connais pas bien la législation en France.

Reverser le code

Un autre point qu’il faut aussi négocier, c’est la possibilité de reverser le code réalisé pour le client au projet si, bien sur, il a un intérêt pour ce dernier. C’est aussi un point important car c’est aussi un gage de pérennité pour le client de son investissement qui même si le prestataire disparaît verra le développement maintenu par la communauté du logiciel. En plus cela permet de contribuer à l’amélioration du logiciel et permet d’entretenir le cercle vertueux des logiciels open source.

Billets similaires :

• Heureux sont les intégrateurs de logiciels libres…
• Comment vendre un projet open source à sa direction #2 – Les arguments
• SOGo et Thunderbird un concurrent pour Exchange et Outlook

Article original écrit par Philippe Scoffoni le 08/07/2009. | Lien direct vers cet article | © Philippe.Scoffoni.Net - 2009

Cette création est mise à disposition sous un contrat Creative Commons BY-SA.

Feed enhanced by Better Feed from Ozh