Contrat de cloud, négocier le SLA !

Le développement des services a consacré le Service Level Agreement comme un document essentiel dans la conclusion d’un contrat de service. Ce SLA, généralement désigné sous son acronyme anglais, signifie en français convention de service ou convention de niveaux de service. Il s’agit bien généralement d’un document porté en annexe du contrat, alors que, dans les faits, ce document très technique en constitue la pierre angulaire. Il est classiquement émis avec le pack contractuel, par la partie délivrant le service. Il a vocation à permettre d’en mesurer la qualité durant l’exécution contractuelle, au travers de différents indicateurs clés dénommés KPI c’est-à-dire les « Key Performance Indicators ».

Il est évident que ce document doit être analysé avec attention par les parties, et en particulier par celle qui souscrit le service auprès de l’autre. Il s’agit, pour le souscripteur du service, d’évaluer la portée du SLA pour comprendre son impact sur les conditions de délivrance, mais aussi sur les conséquences juridiques de son consentement à ce document, et donc sur ses droits…

SLA : un élément essentiel des conditions de délivrance du service

La pratique du SLA n’est pas nouvelle. Elle est née avec les contrats d’infogérance et de maintenance informatiques. Dans un contrat de service à exécution successive, elle répond aux besoins du client, de connaître les conditions d’intervention de son fournisseur, à savoir généralement :

  • sous quel délai celui-ci prend-t-il en compte la demande (délai de prise en compte ou de prise en charge) ;
  • sous quel délai il s’attaque à la réparation (délai d’intervention) ; quels sont les engagements que le fournisseur prend en matière de délai de rétablissement du service (délai de rétablissement). Ce dernier délai peut être lui-même subdivisé en :
    • un délai de remise en service opérationnel dégradé et
    • un délai de restauration du service en service nominal, c’est-à-dire en conditions normales d’utilisation.

Ce SLA qui donnait de la visibilité dans les pilotages des contrats de maintenance et d’infogérance est devenu aujourd’hui un élément clé d’un contrat de service. C’est particulièrement vrai pour les contrats de service cloud, dont le mode d’exploitation rend le suivi de son exécution compliqué pour le client. Dans la mesure où le service s’opère à distance via les réseaux, sans contrôle possible du souscripteur, le SLA est tout simplement l’outil de mesure de la performance du service : il permet d’évaluer si le service est correctement rendu ou à tout le moins, rendu en conformité avec les engagements souscrits. Il s’agit donc d’un outil contractuel de mesure de la performance, qui s’exerce a posteriori par un jeu de comparaison du service rendu avec les indicateurs contractuels.

En un mot donc, pas de bon service, sans niveaux de service. Bien sûr, l’exercice de lecture du SLA, à mi-chemin des engagements juridiques et opérationnels peut paraître complexe. C’est à dessein… et il faut donc se frayer une lecture dans ce qui peut parfois apparaître comme un fouillis technico-contractuel : un droit noyé par la technique ou une technique vernie de droits… Dès lors, la rédaction contractuelle doit pleinement en refléter les enjeux. Elle doit faire de la convention de service un élément déterminant du consentement du souscripteur, car les niveaux de service se confondent avec le service : ils sont le service, et nous verrons plus loin que ce n’est pas sans conséquence juridique.

Quels sont les services concernés par le SLA ?

Dans la lecture du SLA, le premier point qu’il convient de vérifier est l’assiette des services concernés par la qualité de service. C’est-à-dire à quoi s’appliquent les critères de qualité évoqués ci-dessus. En effet, il se peut que les deux critères susvisés, disponibilité et continuité, ne soient mesurables que sur une partie des services souscrits. Ce point de savoir à quel service s’appliquent les critères susvisés est donc déterminant pour un bon pilotage du service. Il va de soi qu’il faut vérifier que les services critiques pour les besoins de l’activité du souscripteur et de ses utilisateurs entrent bien dans le champ de mesure du SLA.

Il se peut aussi que l’application du SLA soit conditionnée. L’accès aux données de pilotage du service peut être soumis à un statut particulier (inscription à un programme, par exemple), ou encore à une souscription de « services optionnels » ou pour finir à une procédure préalable particulière à respecter par le souscripteur et/ou ses utilisateurs.

Il est sur ce point recommandé, lors de la négociation, de tenter d’inscrire la discussion sur la criticité du service dans le cadre de l’obligation de conseil du fournisseur. Il s’agit dès ce stade, de lui exposer de vive voix et par écrit les enjeux et les impacts d’un dysfonctionnement de la solution pour l’activité économique du souscripteur.

Cette approche, répondant aussi au devoir d’information du client, a le mérite de mettre en avant les risques et d’adapter le cas échéant la qualité du service au plu risques encourus.  En cas de difficultés ultérieurement rencontrées dans la délivrance du service, voire de dommages causés, les éléments mis en discussions pourront être utiles à une interprétation plus favorable du contrat et des engagements contractuels. Il est donc important de se ménager la preuve que ces discussions sur la criticité et les moyens d’y répondre ont bien été tenues.

SLA : que permet-il de mesurer ?

Le SLA permet donc de mesurer ce qui est communément appelé la qualité de service. Classiquement, elle repose, entre autres, sur deux critères que sont la disponibilité et la continuité du service. Chacun d’entre eux est apprécié selon une période de temps qui est généralement mensuelle. On y mesure le nombre de requêtes, le taux de requêtes lancées sans succès ou les interruptions intempestives du service durant les plages horaires d’utilisation, ou bien encore leur durée. Il faut donc vérifier que les plages horaires durant lesquels les services seront mesurés, soient aussi les périodes de service durant  lesquels le service est utilisé…

Dans l’évaluation, il faut tenir compte de la nature du service cloud souscrit : plateforme (Platform as a service ou PaaS), logiciels (Software as a service ou SaaS), infrastructure (Infrastructure as a Service) etc. ainsi que de la criticité pour le souscripteur de ce qui sera mis dans le cloud : la criticité ne devrait pas être considérée de la même façon s’il s’agit d’un service de commande et de paiement en ligne ayant un fort impact sur le chiffre d’affaires et l’image de l’entreprise ou d’un service d’accès à la bibliothèque interne des contrats (n’en déplaisent aux juristes, contrariés par cette perte de temps…).

Enfin, deux clauses sont importantes pour s’assurer de la véracité des mesures réalisées. Il s’agit des clauses d’information et des clauses d’audit.  Pour la clause d’information, elle doit être proprement aménagée avec une périodicité de transmission des informations compatible avec les exigences opérationnelles de délais, ou au moins respecter un délai raisonnable suivant le mois d’exploitation. Bien entendu, cette périodicité doit être fonction du taux d’utilisation et de la criticité du service, sachant que plus l’information est partagée tardivement avec le souscripteur plus il lui sera difficile de son côté, de lancer les mesures correctives nécessaires, qui peuvent être tout autre que des  mesures contractuelles (geste commercial, mesure de communication pour lutter contre une perception client négative etc…).

Pour ce qui concerne la clause d’audit, classiquement soumise à un délai de préavis et au fait  de ne pas causer de trouble dans l’exploitation du service, il est recommandé de ne pas en limiter le nombre d’application. Si le cocontractant refuse, il convient de tenter de négocier que la limite du nombre d’audits ne sera pas opposable en cas de problème de sécurité, en cas d’interruptions régulières, ou dans les cas visées par les dispositions du Règlement Général sur les Données Personnelles où l’audit et les garanties des sous-traitants sont obligatoires.

SLA : les pièges à éviter…

Les pièges à éviter tournent autour de ce qui permet de qualifier un incident de disponibilité/continuité et autour de la notion de rétablissement du service. Très souvent définis dans un autre document que le SLA, il faut bien en lire les définitions et les mécanismes parfois savants de qualification.

A propos d’un incident de disponibilité ou de continuité du service, il est important que l’incident puisse être qualifié comme tel, quelle que soit la période contractuelle ou le niveau de qualité affectée, dès la première seconde d’interruption peu important la partie fautive, à ce stade. Il faut noter ici que le fait d’un opérateur tiers de télécoms par exemple, à l’origine d’une interruption de service, ne devrait pas pouvoir permettre une disqualification de l’incident. En effet, le fournisseur de service cloud a dû prévoir, dans l’engagement contractuel qui le lie à son fournisseur de télécoms, toute couverture contractuelle utile. A défaut, la pérennité du service ou le professionnalisme du fournisseur doit être mis en question.

Dans la remontée d’incident, son signalement, il est déterminant de s’intéresser aux modalités qui sont parfois enfermées dans des conditions très strictes (web applis) et aux délais de prise en charge (accusée de réception) qui doivent être distinguer des délais d’intervention (travail effectif sur l’incident), parfois aussi fonction d’un niveau de gravité.

La qualification du niveau de gravité de l’incident doit rester au jugement du client. La gravité affectée à l’incident (mineur, majeur, critique) est un élément important car elle permet généralement de fixer le délai d’intervention du fournisseur de service et le montant des pénalités dont il pourrait être redevable. Dès lors laisser cette qualification à la main du client relève d’un respect du bon équilibre contractuel car le fournisseur de cloud a des informations que le client n’a pas et auxquelles il ne peut avoir accès que partiellement et à contre-temps… Enfin s’il paraît juste que le fournisseur puisse contester la qualification affectée, cette contestation ne devrait être possible qu’une fois l’incident corrigé.

Pour finir, il est déterminant de prévoir les conséquences à tirer d’une répétition d’incidents de moindre intensité mais perturbant régulièrement générale la qualité de service, soit par un jeu d’aggravation de pénalités soit par une résiliation pure et simple du service en la qualifiant de faute.

Les pièges relatifs au rétablissement du service sont simples. Il s’agit d’arriver à déterminer quand les parties peuvent considérer que le fournisseur est libéré de son obligation de rétablissement du service : s’agit-il du moment où l’incident est corrigé mais le service pas encore rétabli ? S’agit-il du moment où le service est rétabli dans des conditions dégradées mais acceptables (et comment le détermine-t-on dans ce cas, sur la base de quels critères) ? S’agit-il du moment où il est en service opérationnel nominal, c’est-à-dire qu’il fonctionne dans des conditions normales d’utilisation ?

Enfin, pour le client, il vaut mieux disposer de quelques indicateurs compréhensibles bien suivis, que de disposer d’une pléthore d’indicateurs compliqués à « monitorer ».

SLA, contrat, et droit…

Bien qu’étant porté en annexe du corpus contractuel, le SLA relève de la définition du service au sein du contrat. Il doit donc faire une référence directe et expresse au SLA pour constituer une sorte de tout qui ne se divise pas. Il va de soi, qu’une référence contractuelles qui prendrait la forme de lien hypertexte pointant vers un site web est à éviter….même pour des raisons de mise à jour de l’annexe en fonction des évolutions du service.

Ces points, comme l’ensemble des autres clauses et annexes du contrat doit être négocié, quoiqu’en dise le fournisseur de cloud. L’argument qui consiste à dire que le contrat n’est pas modifiable parce que le produit est un service sur étagère similaire pour tout client peut être contré en demandant des modifications par voie d’avenant à ces documents figés par le caractère standard du service offert ou par insertion de conditions particulières. Cette approche est avantageuse à la lecture des dispositions de l’article 1119 du Code civil qui dispose  qu’« en cas de discordance entre les conditions générales et des conditions particulières, les secondes l’emportent sur les premières » (Code civil, art.1119, al.2). Si le fournisseur de service s’y refuse, il peut être avantageux de rappeler (par écrit…) que l’absence de discussions aboutissant à une modification du contrat permet de le qualifier de contrat d’adhésion, selon les dispositions de l’article 1110 du Code civil (Code civil, article 1110, al.2), une qualification bien utile (essentielle…) lorsqu’il s’agira :

  • d’invoquer un déséquilibre significatif entre les droits et les obligations des parties, selon l’article 1171 du Code civil (Code civil, article 1171) ;
  • d’invoquer, en cas de doute, une interprétation très partisane du contrat à l’encontre du fournisseur qui l’a rédigé, conformément à l’article 1190 du Code civil (Code civil, article 1190);

deux arguments clés pour ramener à la raison et conduire à la table des négociations, un fournisseur récalcitrant…  Les essayer… c’est déjà les adopter !

SLA, pénalités, crédit de services… un peu de droit pour la soif…

La raison qui motive les fournisseurs de cloud à  amoindrir le degré de leurs engagements dans les SLA, vient du fait que les niveaux de service sont assujettis à des pénalités ou des crédits de services. Au-delà de leurs impacts financiers sur la rentabilité du service, leur qualification juridique interroge et mériterait d’être débattue plus avant.

Tout d’abord, il semble qu’en matière de service le fait d’accepter que des pénalités ou des crédits de services puissent s’appliquer et être dus lorsque les niveaux de service ne sont pas atteints n’est pas neutre. Cette pratique influera sur l’interprétation qui pourra être tirée du contrat. Particulièrement, il semble que consentir par avance à ce que les SLA puissent ne pas être atteints, revient, pour le souscripteur à consentir par avance à une défaillance du service du service au-delà des niveaux prescrits (les SLA).

Dès lors, et quelles que soient les stipulations insérées au contrat, il sera compliqué au souscripteur d’arguer d’une obligation de résultat à atteindre un service parfait ou rendu à 100%. Il lui sera aussi compliqué d’invoquer un préjudice causé par le fait que le service n’a pas été rendu parfaitement, puisque il aura par le contrat accepté le fait que le service soit imparfaitement rendu.  En un mot, le SLA revient pour le souscripteur à accepter une faillibilité dans le rendu du service, acceptation qui pourra lui être reprochée ou opposable au moment d’invoquer son préjudice.

Concernant la qualification de crédit de service, si parfois, il peut s’agir d’un savant mécanisme de compensation entre niveaux de service, permettant d’aboutir au calcul d’une performance moyenne des indicateurs,  il s’agit plus généralement d’une créance de somme d’argent. Cette créance est acquise  au souscripteur au motif que le SLA n’a pas été atteint et elle a vocation à être compensée sur une somme d’argent à devoir pour la délivrance du service à venir.

La qualification juridique de cette pratique à la lecture du nouveau droit des contrats, mérite un mot. Dans la mesure où le service crédit atteste de l’exécution imparfaite du service, il pourrait être qualifié de réduction du prix, telle que prévue par l’article 1223 du Code civil (Code civil, art 1223). Dans la mesure où en matière de cloud, les prix sont acquittés par avance, l’intérêt de la sanction perd l’intérêt pratique de la rétention (le refus de payer). Mais elle reste à la main du souscripteur du service qui décide de son application, après une mise en demeure. Sur ce dernier point, il semble dans la mesure où le mécanisme est contractuellement prévu qu’il soit nécessaire d’exclure cette formalité par dérogation à cet article. L’avantage, pour le souscripteur du service consiste dans le fait qu’il peut toujours réclamer la réparation entière de son préjudice, puisque la réduction du prix n’est pas une forme de responsabilité. Du coup, la réduction du prix reste possible même si l’inexécution du SLA est causée par un case de force majeure (contrairement à ce que bon nombre de contrats type stipulent…).

Enfin, dans la mesure où l’inexécution des SLA donne lieu à des pénalités en  réparation du préjudice causé par leur non-atteinte, le régime juridique en est différent. Il devrait s’agir d’une clause d’indemnisation forfaitaire ou d’une clause pénale, dont le régime est dicté par l’article 1231-5 du Code civil qui semble les avoir fusionnées (Code civil, article 1231-5). Si le montant de la somme à payer en cas de manquement ne peut être modifié par les parties, il reste modifiable par les juges, son acquittement devrait faire l’objet d’une mise en demeure, dont au cas d’espèce, il conviendrait d’aménager une dérogation pour pouvoir s’en passer, ou en faciliter l’usage pour le limiter à un simple effet de notification de créance.

2 Comments

  • julien

    13 mai 2018 at 15 h 56 min Répondre

    Merci pour ce post assez clair. Serai intéressé pour avoir quelques techniques de négociations car mon expérience de discussions se limite avec les sociétés de cloud à « c’est à prendre ou à laisser »! Je comprends que la réforme du droit permet de discuter… aussi courte soit cette négociation mais quand on a besoin du service, le droit n’est que de peu d’aide… sauf à aller en justice….

  • Xavier MARCHAND

    14 mai 2018 at 7 h 14 min Répondre

    Cette analyse très pertinente du contrat de Cloud peut s’étendre à tous les contrats techniques. Contrairement à une idée souvent trop répandue parmi les juristes (j’y inclus naturellement les avocats), l’essence du contrat n’est pas dans les dispositions contractuelles, qui ne sont souvent que le catalogue de principes généraux, mais bien dans la définition précise de l’objet de celui-ci, à savoir le service rendu ou le bien fourni. Le meilleur contrat n’est rien si la « spécification technique » n’est pas claire, Le véritable travail du juriste est de veiller à la clarté de la rédaction de l’annexe technique (SLA, CCTP, Spécifications techniques, etc…) : si moi, juriste, je ne comprends pas l’annexe technique, comment fera le juge qui est censé en juger les termes ? Je suis toujours surpris de constater le maintien de cette dichotomie entre le juriste qui serait littéraire et ferait des grandes phrases absconses et le scientifique qui n’écrirait qu’en bullet point. Lire les articles scientifiques, écouter les conférences données par nos plus grands chercheurs montrent qu’une pensée scientifique claire s’exprime dans un français parfait. Pourquoi diable ne pas continuer à rédiger des annexes techniques en « petit nègre » (j’utilise là une expression consacrée qui n’a aucune connotation culturelle ou raciale)?
    Pour les SLA, notre technique de discussion s’appuie sur ce principe : puisque nous ne comprenons rien au SLA et ses ramifications, nous demandons simplement au prestataire de bien vouloir répondre par écrit à des questions que nous posons sur le service rendu et faisons des réponses apportées, que nous souhaitons claires et précises, une annexe ayant une force contractuelle supérieure au SLA…

Post a Comment