Le SNIA définit le Service Level Agreement (SLA) est «un accord entre un fournisseur de service (…) et un consommateur de service (…) [qui] définit des paramètres pour mesurer le service et indique des valeurs quantitatives pour ces paramètres»¹.

Plus simplement, le Service Level Agreement (SLA) est une partie d’un contrat de service dans lequel le niveau de service attendu est formellement défini.

Et plus précisément, le SLA est l’accord résultant d’une négociation et qui a pour but de définir les objectifs, auxquels il peut y avoir des exceptions, de poser les contraintes et de prévoir des pénalités. C’est cette définition que nous retiendrons.

La négociation est la recherche d’un accord.

Il n’y a négociation que si les parties ont des intérêts divergents et la négociation ne peut aboutir à un accord que si les négociateurs sont prêts à faire des concessions.

L’accord s’entend ici dans le même sens qu’en droit des obligations, et est donc synonyme de consentement. Le consentement est le fait de se prononcer favorablement à une convention par laquelle la personne qui consent s’oblige, se rend débitrice d’une obligation.

Toujours d’un point de vue légal, il faut faire la distinction entre l’obligation de moyens et l’obligation de résultats. En cas d’obligation de moyens, la personne qui s’engage est tenue de faire tout ce qui est en son pouvoir pour atteindre l’objectif alors qu’en cas d’obligation de résutat, elle est tenue d’atteindre l’objectif. Le but ici n’étant pas d’écrire un ouvrage de droit, il faut simplement retenir que, dans la plupart des cas, les objectifs ICT sont soumis à une obligation de moyens. Il existe quelques exceptions pour lesquels la jurisprudence a retenu une obligation de résultat, notamment les opérations liées aux backups.

Le code civil² retient quatre conditions essentielles pour la validité d’une convention :

Le consentement des parties qui se créent des obligations peut sembler une évidence, mais il faut toutefois rappeler que dans le cas de la négociation d’un SLA, aucune des deux parties ne peut imposer ses vues à l’autre sous peine d’impossibilité, si le client impose des objectifs hors de portée du fournisseur ICT, ou d’inadéquation, si les objectifs imposés par le fournisseur ICT ne conviennent pas au client.

La capacité de contracter ne concerne que peu le domaine des SLA. On considère a priori que les intervenants ont le droit, la capacité légale, de s’engager.

Ce n’est par contre pas le cas de l’objet certain qui forme la matière de l’engagement. Les objectifs définis par le SLA sont l’objet du contrat. Mais comment faire pour que ces objectifs soient concrets, précis et réalistes? Cette vaste question est abordée ci-après…

La condition de licéité de l’objet signifie que la convention, le SLA dans notre cas, n’est pas au dessus des lois. Il est des domaines pour lesquels une règlementation existe et le SLA ne peut y contrevenir. Les banques en sont un exemple.

Un objectif est un but que l’on cherche à atteindre.

Les objectifs définissent les obligations auxquelles les personnes qui donnent leur accord consentent.

Un objectif dans ce cas s’entend au sens COSO d’objectif opérationnel. Objectifs opérationnels ont trait à la réalisation d’une mission de base de l’entité – la raison fondamentale de son existence³. Assez curieusement ISO 310×0 ne donne aucune définition de ce qu’est un objectif.

La mission de base d’une infrastructure ICT est de mettre à disposition un ou plusieurs services ICT dans des conditions de performance et sécurité définies.

En ICT, les objectifs portent donc sur la disponibilité, la performance et la sécurité. Chaque expression d’une attente peut comporter une ou plusieurs exceptions.

Si les objectifs exprimés dans le SLA doivent être l’expression des cas généraux, ils doit être possible d’y adjoindre des dérogations ou des restrictions si nécessaire.

En effet, hors les cas triviaux, il est illusoire de prétendre que les objectifs généraux pourront s’appliquer à la totalité des cas. Présenter la liste des exceptions aux objectifs généraux est faire preuve de réalisme et d’honnêteté.

La difficulté principale de l’exercice est de tendre vers l’exhaustivité. C’est une raison majeure de l’application d’une méthode, telle AMDEC, à l’analyse systématique de l’infrastructure ICT.

Une contrainte est une condition à satisfaire.

Il faut ici bien faire la distinction entre les objectifs et les contraintes. Un objectif porte sur le coeur du métier ICT, une contrainte pas. Les contraintes font partie du contexte externe ou interne du service ICT. Les contextes internes et externes s’entendent ici au sens ISO du terme, c’est-à-dire «l’environnement interne ou externe dans lequel l’organisme cherche à atteindre ses objectifs»⁴. COSO parle dans ce cas de «facteurs externes ou internes».

Les pénalités peuvent souvent prendre la forme de sanctions financières mais pas uniquement. Bien que peu courante, la résiliation du contrat liant les parties, par exemple, peut être envisagée.

¹ The Storage Networking Industry Association, http://www.snia.org/education/dictionary.
² Code civil, « Des contrats ou des obligations conventionnelles en général », chapitre I, article 1108, 7 février 1804.
³ Committee of Sponsoring Organizations of the Treadway Commission, « Internal Control—Integrated Framework », page 7, point 42.
⁴ ISO/CEI Guide 73, « Management du risque — Vocabulaire », page 4, points 3.3.1.1 et 3.3.1.2.