SLA des SaaS : ce que doivent inclure les contrats

Disponibilité des SLA

« En tant que disposition de base, on pourrait penser que le SLA correspond au niveau de service, aux garanties de disponibilité qu'il énonce. La disponibilité, c'est la fréquence à laquelle le système tombe en panne », explique Golden.

Elle s'exprime sous la forme d'un pourcentage comportant trois, quatre ou cinq chiffres 9. « Une chose à garder à l'esprit : plus le fournisseur ajoute de 9 – donc plus le taux d'immobilisation diminue – plus le coût augmente », explique Golden.

Parallèlement à la disponibilité, il faut tenir compte de la fonction métier fournie. « L'important – et c'est un véritable défi parce que les fournisseurs y rechignent – c'est de faire en sorte que les SLA soient axés sur la valeur métier que vous attendez de la solution SaaS », explique Bill Corrington, responsable de la stratégie Cloud chez Stony Point Enterprises.

Bill Corrington prend l'exemple de la messagerie en tant que service : « Le courrier électronique est en fait très complexe. Si votre routage interne et vos carnets d'adresses ne sont pas configurés, vos courriels ne seront pas acheminés. Le système fonctionne mais les messages ne vont nulle part », explique-t-il. Dans ce cas, il conseille de mettre en place un SLA garantissant un pourcentage de courriels acheminés.

L'immobilisation dans un SLA

Côté fournisseur de services, l'exemple de la messagerie de Bill Corrington pourrait ne même pas compter comme une immobilisation. Aussi est-il important de définir ce qu'est l'immobilisation dans le cadre d'un SLA.

« On négocie aussi ce qui compte en tant qu'immobilisation : l'immobilisation imprévue ou la maintenance planifiée pour la mise à jour des systèmes. Est-ce de l'immobilisation ? Du point de vue du fournisseur, cela peut ne pas compter », explique Golden.

Pourtant, il est hors de question de payer pour un système qui ne fonctionne pas. « Le contrat de base comprend systématiquement une indemnisation en cas d'indisponibilité du service. En cas d'indisponibilité du service, nous vous remboursons le coût du service à hauteur d'un montant X d'heures. Cette indemnisation ne couvrira pas les ventes perdues ; vous aimeriez que ce soit le cas, mais aucun fournisseur n'acceptera une telle condition. La responsabilité par rapport au X que l'entreprise représente serait tout simplement extrême », explique Golden.

Délai moyen de réparation et délai moyen de réaction

Un SLA doit également définir des niveaux de gravité de problème, ainsi que des délais moyens de réparation et de réaction pour chacun de ces niveaux, d'après Bill Corrington. Par exemple, en cas de problème de gravité 1 – niveau qui signifie que le système est immobilisé – le délai moyen de réaction et le délai moyen de réparation doivent être inférieurs à ceux d'un problème de gravité 3, qui tient davantage du simple désagrément.

De même, selon Corrington, les accords sur le niveau de service peuvent dépendre de vos utilisateurs. « Il est nécessaire d'identifier certains utilisateurs comme plus importants que d'autres », explique-t-il. Ces utilisateurs « VIP » doivent être prioritaires lorsqu'il s'agit de résoudre les problèmes. Par exemple, si vous utilisez une solution de messagerie SaaS et que votre utilisateur VIP – le vice-président d'une division – ne puisse pas envoyer de courriels depuis son smartphone un samedi matin, la question doit être traitée comme un problème de gravité 1.

« Le fournisseur doit comprendre ce que représentent ces utilisateurs VIP (par leur nom et leur titre professionnel) et mettre en oeuvre les SLA appropriés », explique Corrington.

Voie de remontée

« Lorsque l'on passe d'une solution interne sur site à une solution externalisée, l'une des principales différences tient à l'étendue du contrôle », explique Bill Corrington. « Lorsque votre système de messagerie interne présente un problème, vous appelez votre administrateur système », poursuit-il.  « Dans le cas d'une solution SaaS, il y a peu de chances que votre interlocuteur dispose de l'intégralité des privilèges d'administration sur l'infrastructure.

Vous avez donc besoin d'une personne qui pourra intervenir dans la chaîne d'administration, côté fournisseur. Il faut absolument que ce point soit compris et documenté. Vous ne voulez pas être mis en attente au niveau du centre d'appels », explique Corrington.

Un avertissement concernant les SLA

Enfin, il est important de remettre les SLA des solutions SaaS dans leur contexte. « L'existence d'un SLA ne constitue pas une garantie quant aux performances réelles de l'application SaaS », déclare Bernard Golden. « Le SLA n'élimine pas la nécessité d'évaluer le système ».

Autrement dit, ne considérez jamais que le service sera réellement disponible simplement parce que le SLA le stipule. Evaluez vous-même le service. Tenez compte des points suivants : Quelle est l'expérience réelle des clients à ce stade ? Quelle est l'efficacité de la prestation du fournisseur ? Quelles sont les dispositions du fournisseur en cas d'incident majeur ? Le fournisseur dispose-t-il d'un système de reprise sur incident qui se déclenchera instantanément ?

« Le SLA ne contrôle pas les éléments effectivement mis à disposition », explique Golden. « Il est là pour déterminer les responsabilités en cas de conflit. En fait, il est préférable de ne pas en arriver à débattre du SLA, car ce que vous voulez, c'est un service disponible. »