En s’alliant le Cigref et le CISPE veulent influer sur le Digital Market Act -DMA- de l'UE pour dénoncer certaines pratiques déloyales d’éditeurs de logiciels et promouvoir un marché cloud juste et concurrentiel. Si les principes sont louables, ils opposent des paradigmes bien différents (licences vs services) en abstraction du droit commercial applicable (US vs européen). Décryptage
Obsolescence programmée des logiciels par l’arrêt du support, incompatibilité avec les versions plus récentes pour forcer les montées de version, introduction de nouvelles technologies: autant de pratiques commerciales dénoncées par le CIGREF depuis plusieurs années s’agissant des grands éditeurs de logiciels. Pour mener son combat avec plus de force, il vient de s’allier avec le CISPE (Cloud Infrastructure Service Providers of Europe), qui regroupe une petite trentaine de fournisseurs d’infrastructures cloud en Europe. De cette alliance est née le FairSoftware.Cloud, qui publie une liste de 10 principes à respecter pour l’octroi de licences logicielles équitables et pour lesquels la Commission européenne et les États membres sont invités à considérer afin d' élaborer des obligations pour les contrôleurs d’accès telles que celles du DMA Digital Market Act. En voici les 10 principes et notre décryptage.
1. Transparence et intelligibilité des conditions de licences.
L’alliance demande à ce titre une plus grande transparence et explicabilité des contrats de licences.
Dans le domaine du cloud, le logiciel (SaaS) est fourni comme un service qui intègre outre son utilisation, sa maintenance, sa disponibilité, sa sécurité, les mises à jour.
Ce nouveau modèle de service vient impacter la manière dont les éditeurs délivraient des logiciels en mode on premise. En clair dans un contrat SaaS, le client obtient un service, mais pas un logiciel. Il n’achète pas de licence mais souscrit à un abonnement. Le CSP lui peut par contre obtenir un contrat de licences, s’agissant de la revente de services à des tiers. Pour avoir une meilleure visibilité sur les contrats SaaS, il faut donc éviter d’utiliser le terme de licence, qui sous-entend un droit d’auteur qui n’existe pas juridiquement.
Dans le SaaS, on l’aura bien compris, tout doit être fourni comme un service et ce, avec des engagements clairs. C’est donc bien au niveau du SLA et des contrats associés qu’il faut agir afin d’obtenir plus de transparence et de visibilité.
2. Utilisation dans le cloud de licences déjà acquises
Ici se pose le problème d’une utilisation hybride SaaS et logiciel installé. Ce qui nécessite alors un accord de licence intégré dans un contrat de service. La licence et ses modalités de soutien doivent traiter de l'application installée uniquement. Mais là encore, c’est assez difficile à matérialiser, au regard des versions installées par exemple et de la définition des responsabilités éditeurs/ hébergeurs/ client qui n’est pas la même en fonction soit de l’exploitation de la licence chez le client, soit de l’exploitation d’un service. Cela nécessite donc la rédaction spécifique de contrat de service entre l’éditeur et le client qu’il soit hébergeur ou non. Cela peut prendre du temps, alors que l’intérêt même du SaaS est le provisionnement et/ou le développement rapide de services à valeur ajoutée
3. Les clients doivent être libres d’utiliser leurs logiciels on premise chez le fournisseur de cloud de leur choix.
Oui. Mais là encore tout dépend du contrat de licence et de service qui a été signé entre l’éditeur et le fournisseur de cloud.
4. Les clients doivent pouvoir optimiser leurs coûts grâce à une utilisation efficace du matériel informatique de leur choix
Dans le modèle SaaS, logiciel et matériel sont étroitement liés dans la fourniture du service et cela engage des clauses de responsabilité en cas d’indisponibilité, de faille de sécurité. Là encore tout se joue dans la rédaction des SLA et ou des contrats de service ad hoc entre les différents tenants.
5. Les clients doivent être libres du choix de leur fournisseur de cloud, sans faire l'objet de représailles
Ici intervient la notion de "bargaining power": Plus est on verrouillé sur un fournisseur, ou un éditeur, moins on aura de marges de négociation. Le fait de choisir librement son CSP pour l’utilisation d’un SaaS est bien entendu une condition non négociable sur le principe de la portabilité et de l’interopérabilité. Cela demande une lecture assidue des contrats et de leurs clauses avant engagement.
6. Les éditeurs de logiciels d'annuaire doivent privilégier les standards ouverts et interopérables, sans verrouiller leurs clients (Locked-in).
Il ‘agit moins d’un problème de standard couvert aujourd’hui par le LDAP que d’architecture de déploiement. Par définition, un serveur d’annuaire est centralisé et donc facilement verrouillable. De plus bien souvent, on construit des systèmes IAM et d’authentification autour de ces annuaires, ce qui renforce encore le verrouillage technique. Rien n’empêche aujourd’hui de construire son annuaire sur des solutions agnostiques DaaS- directory as a service, pour lesquelles il conviendra aussi de bien lire les contrats de SLA, portabilité oblige.
7. Les éditeurs de logiciels doivent respecter l'égalité de traitement concernant les redevances logicielles sur le cloud
C’est la frontière matérielle-logicielle du SaaS qui crée avant tout cette ambigüité commerciale. Sur une économie de marché libre et de droit commercial, les pratiques de facturations ne peuvent être régulées au niveau global, seules les pratiques de consommations le peuvent, et encore, au niveau des états, sur preuve de verrouillage commercial ou d'atteinte aux codes de consommation en vigueur.
8. Les conditions d’usage des logiciels doivent être fiables et pérennes
Toute modification d’usage doit être intégrée dans les CGU/CGV et à acceptation du client (signature), elle serait difficilement opposable, surtout s’agissant de fournisseurs régit par un droit commercial hors EU
9. Les licences doivent couvrir les utilisations raisonnablement attendues des logiciels
Encore une fois, dans le cloud, on ne parle plus de licences mais de services. Opposer les deux paradigmes est un contre sens. Il convient d’étudier la couverture fonctionnelle avant de provisionner un XaaS qu’il s’agisse d’application, d’infrastructure ou de tout autre modèle. Le même argument pourrait ainsi être utilisé à l’encontre des CSPs.
10. Permettre des transferts logiciels équitables
Lorsque les clients (CSP) ont le droit de revendre et de transférer des licences de logiciels, les fournisseurs de logiciels doivent continuer à offrir une assistance et des correctifs dans des conditions équitables. Oui et cela doit être vérifié par la signature d’un contrat de licence ad hoc. Là encore le problème vient du droit commercial opposable et de la juridiction dans lequel opère l’éditeur.
Le FairSoftware cloud Alliance vient un peu plus compliquer la compréhension des modèles de licences classiques (logiciel) vs services Cloud (SaaS). Plutôt que d’édicter des principes certes louables mais qui ont peu de chance d’aboutir à des règlementations au vu de la structuration et de la complexité du modèle économique du cloud, il serait plus intéressant d'œuvrer à redonner plus de visibilité aux éditeurs FR/EU afin de rééquilibrer le marché en leur faveur, ce qui reviendrait à repenser le modèle classique de marketplace des CSP, pour autant calqué sur le modèle US.
Comments