Taux de disponibilité de l’hébergement cloud et SLA : tout ce qu’il faut savoir

Le SLA (Service Level Agreement) est un contrat qui a vocation à définir les engagements de niveaux de services pris par un prestataire. Il est donc conclu entre l’éditeur et l’hébergeur, mais aussi entre l’éditeur et le client final.

Ce document est indispensable dès lors que le client dépend de la continuité des services de l’éditeur et de l’hébergeur pour pouvoir exercer son activité, notamment dans le cadre d’une offre de logiciel en SaaS.

En effet, la durée d’indisponibilité d’un logiciel peut être extrêmement préjudiciable pour une entreprise. D’où la nécessité d’encadrer strictement les temps d’arrêt dus aux pannes ou à la maintenance, durant lesquels le client final ne peut plus accéder à son système de gestion.

Le SLA vise à définir les engagements de l’éditeur concernant la disponibilité et la performance du logiciel proposé, mais aussi la maintenance et le support. Concrètement, il doit décrire comment le prestataire prévoit d’assister son client, dans quel périmètre et dans quels délais. Le plus souvent, les modalités d’intervention varient selon le niveau de criticité de l’incident ou du problème technique rencontré.

Ce document est aussi un gage de transparence, de sérieux et de crédibilité pour l’éditeur. Il peut ainsi établir une véritable relation de confiance avec son client tout au long de la durée du contrat, tout en prévenant d’éventuels litiges.

Le contenu de l’accord de niveau de services varie en fonction du type de logiciel et des prestations fournies. Cependant, il doit inclure un certain nombre d’informations indispensables : 

• La nature des services fournis et leur étendue 
• Les niveaux de services et les indicateurs de performance permettant de les mesurer 
• Les critères retenus pour la mesure des indicateurs 
• Les modalités d’information en cas d’incident 
• Les modalités de suivi et de reporting 
• Le calendrier des interventions de maintenance 

Dans tous les cas, il est essentiel de rédiger un SLA répondant parfaitement aux besoins et aux attentes du client, sans pour autant surestimer les capacités de l’éditeur et de l’hébergeur. 

Dans le cas d’un logiciel hébergé sur le cloud, le SLA permet de préciser un certain nombre d’engagements, dont voici les plus importants. 

La PSG définit la période durant laquelle le service est garanti et disponible, par exemple :

• 5 jours par semaine ou 7 jours sur 7.
• De 8 h à 18 h, de 7 h à 20 h ou encore 24 heures sur 24.

Autrement dit, la plage de service garanti est la durée pendant laquelle l’éditeur et l’hébergeur s’engagent à rendre le service disponible et, le cas échéant, à le rétablir dans les plus brefs délais (comme prévu dans la garantie de temps de rétablissement, que nous aborderons ensuite).

Le choix de la PSG dépend largement de l’usage du logiciel ou du service. Par exemple :

• Un site web grand public doit être accessible 7 jours sur 7 sur des horaires étendus (voire 24 heures sur 24).
• En revanche, un progiciel utilisé par le personnel d’une entreprise pendant les heures de bureau n’a sans doute pas besoin d’une telle plage de service : une PSG de 8 h à 18 h, par exemple, peut suffire amplement.

À noter : dans la majorité des cas, le service n’est pas interrompu en dehors de la plage de service garantie, ce qui signifie que la solution logicielle peut toujours être utilisée. Toutefois, durant cette période, l’éditeur se réserve le droit d’effectuer des opérations de maintenance et n’est pas dans l’obligation de rétablir immédiatement le service en cas de panne.

Enfin, la PSG permet de calculer une durée annuelle qui servira notamment à évaluer le taux de disponibilité. Par exemple, avec une plage de service de 9 h à 19 h en 5 jours sur 7, on obtient environ 2 600 heures par an

La garantie de temps de rétablissement est le délai dans lequel le prestataire s’engage à intervenir pour rétablir le service, suite à un incident ou une coupure. Il s’agit d’une durée maximum, ce qui signifie que l’éditeur peut intervenir dans un délai plus court, mais jamais plus long. Enfin, la GTR intervient uniquement pendant la plage de service garanti, ce qui entraîne quelques complications.

Prenons l’exemple d’une GTR de 3 h et d’une PSG de 9 h à 19 h, 5 jours sur 7

• Si une panne survient le lundi à 9 h, il sera corrigé le jour même avant midi.
• Si un incident se produit le mercredi à 18 h 30, le prestataire aura jusqu’à jeudi, 11 h 30, pour intervenir. En effet, la PSG s’interrompt entre 19 h et 9 h le lendemain.
• Enfin, si un problème se manifeste pendant le week-end, il ne sera résolu que le lundi entre 9 h et 12 h, car le samedi et le dimanche ne sont pas inclus dans la plage de service garanti.

Ainsi, l’efficacité de la GTR dépend largement de la PSG : c’est pourquoi elles doivent être définies ensemble, en fonction du service fourni et des besoins de l’entreprise.

S’il s’agit d’une application critique ou d’un site internet commercial, par exemple, une PSG en horaires de bureau représente un risque. En cas de panne le vendredi soir, le service est susceptible de rester indisponible tout le week-end, quel que soit le délai de la GTR.

De manière générale, la disponibilité désigne la probabilité qu’un système informatique soit en mesure de fonctionner correctement à un instant précis. Ainsi, plus le taux de disponibilité d’un service en ligne est élevé, plus ledit service est stable.

Calculé annuellement, trimestriellement ou même mensuellement, le taux de disponibilité permet de définir la durée d’indisponibilité maximale par rapport à la plage de service garanti. Par exemple :

• Avec une PSG de 2 600 heures par an et un taux de disponibilité de 99 %, la durée d’indisponibilité annuelle ne dépassera pas 26 heures.
• Avec une PSG 24/7 de 8 760 heures par an et un taux de disponibilité de 99 %, la durée d’indisponibilité annuelle ne dépassera pas 87 heures.

Ainsi, l’étendue de la plage de service garanti a un impact direct sur la durée d’indisponibilité maximale. C’est pourquoi il est important de relativiser la signification du taux de disponibilité en fonction de la PSG.

Le terme RPO, qui peut être traduit par « objectif de restauration », désigne la durée maximale d’enregistrement des données qu’une entreprise peut accepter de perdre sans que cela ne compromette son activité. Cette perte de données peut être due à une panne, un sinistre ou tout autre incident.

Pour quantifier cet objectif de restauration, il est nécessaire d’évaluer le volume des données produites, leur niveau d’importance, mais aussi les fenêtres de sauvegarde permettant de répliquer la data sur des unités externes. La durée du RPO est donc liée au laps de temps nécessaire pour effectuer la sauvegarde, auquel il faut ajouter la durée de redémarrage des systèmes et de rechargement des données.

Dans la plupart des cas, le RPO est à J-1, avec une sauvegarde effectuée chaque nuit. Mais ce délai peut être réduit à une demi-journée ou moins, ce qui peut être utile pour les systèmes traitant un volume élevé de transactions.

En définitive, le RPO dépend de l’activité, de la taille de l’entreprise et de son usage des données. Selon ces critères, on peut employer des techniques de réplication et de sauvegarde plus ou moins onéreuses :

• Un snapshot permet de revenir à un état antérieur d’un environnement, par exemple en cas de mauvaise manipulation.
• Une sauvegarde, en revanche, est une image réalisée à intervalles réguliers et hébergée sur un espace de stockage distinct. En cas d’incident sur un serveur physique, la sauvegarde permet donc de rétablir les données, alors qu’un snapshot sera perdu.

La garantie de temps d’intervention est le délai dans lequel l’éditeur s’engage à prendre en charge un incident ou une demande de son client. Toutefois, « intervention » n’est pas synonyme de « rétablissement » : dans les faits, la GTI n’engage en rien le prestataire.

Seule la garantie de temps de rétablissement (GTR) peut être considérée comme un véritable gage de sécurité, obligeant le prestataire à résoudre rapidement le problème rencontré.