Contrats de prestations de services et open source

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

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.

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

4 réponses

  1. Ner0lph dit :

    En ce qui concerne les brevets logiciels en France, pas d’inquiétude pour l’instant : ils n’ont aucune valeur légale. Idem en Europe.

    Sauf erreur de ma part.

  2. gfabre dit :

    Bonjour Philippe,

    Article très intéressant comme toujours 🙂

    Une petite idée au passage : il pourrait être pratique de pouvoir recevoir par mail les commentaires sur un billet sans avoir à poster un commentaire, qu’en penses-tu ? De pouvoir s’abonner à la discussion de l’article en quelques sortes, un peu comme sur ubuntu-fr.

    Voilà pour la petite idée 😉

    A bientôt,

    Ghis

  3. Philippe dit :

    @Ner0lph : tant mieux alors !
    @gfabre : oui tu as raison je vais l’ajouter au cahier des charges de mon site de la rentrée.

  4. Poupoul2 dit :

    J’ai une remarque concernant la garantie sur le logiciel : Pour avoir travaillé sur moultes projets de déploiement de logiciels propriétaires, j’ai rarement vu dans les contrats logiciels (je ne parle pas des contrats d’intégration) une clause garantissant la prise en charge des correctifs. Les éditeurs agissent en best effort. C’est notamment le cas pour les grands progiciels de gestion de type SAP, Oracle ou autres Peoplesoft ou Siebel. Si une anomalie est découverte dans le logiciel et peut être reproduite sur la version standard, tous les moyens sont généralement là pour déclarer le bug, mais l’éditeur ne s’engage pas à fournir les correctifs. De ce point de vue, le logiciel propriétaire est moins bien équipé que le logiciel libre. Dans le cas d’un logiciel libre, il est toujours possible d’intervenir sur le code source pour le patcher, puis de proposer le correctif à la communauté des développeurs. Dans le cas d’un logiciel propriétaire, c’est aussi possible, mais sous réserve que le code source soit effectivement disponible et que le contrat du logiciel en permette la modification.

    Concernant le reversement de code dans le cadre d’un logiciel libre (effectivement si ce code présente un intérêt), je crois que cet aspect est tout à fait essentiel lors de la négociation. L’intégration d’une telle clause est bénéficiaire pour le client et le logiciel : Le client limite l’impact d’un développement spécifique et bénéficie de l’effet d’image apporté par ce reversement auprès de la communauté. Le logiciel bénéficie quant à lui de l’apport de nouveaux développeurs et enrichit son portefeuille d’utilisateurs. C’est un moyen d’assurer sa pérennité.

    My 2 cents