SLA dans les contrats SaaS – disponibilité, temps de réponse, RTO, RPO et crédits de service
Un SLA rend le niveau de service du fournisseur SaaS mesurable. Il doit définir ce que signifie la disponibilité, comment elle est calculée, comment les incidents sont priorisés, quels délais de réponse s'appliquent, quels objectifs de rétablissement sont pertinents et ce que le client obtient si le niveau de service n'est pas atteint.
Qu'est-ce qu'un SLA dans un contrat SaaS ?
SLA signifie Service Level Agreement (Accord de niveau de service) et constitue souvent une annexe au contrat principal. Le contrat principal décrit la relation commerciale, tandis que le SLA précise les niveaux de qualité mesurables du service continu.
Un bon SLA doit pouvoir être utilisé aussi bien en fonctionnement normal qu'en cas de problème. Si les parties ne commencent à discuter de ce que signifient « perturbation critique » ou « 99,9 % de disponibilité » qu'au moment d'un incident, le contrat est trop flou.
Voir également le guide principal sur ce qu'un contrat SaaS doit contenir.
Disponibilité – le pourcentage n'est qu'un début
Un niveau de disponibilité, par exemple 99,9 %, ne signifie pas grand-chose sans règles de mesure. Précisez donc :
- quel service ou quels composants sont couverts,
- la période de mesure, par exemple le mois civil,
- quelle source de données est utilisée,
- quand les temps d'arrêt commencent et se terminent,
- si la maintenance planifiée est déduite,
- comment les erreurs causées par le client ou la force majeure sont traitées,
- si une dégradation des performances peut être considérée comme une indisponibilité.
La différence entre 99,9 et 99,99 % peut être commercialement importante. L'exigence doit donc être basée sur le caractère critique du service pour l'entreprise et sur ce que l'architecture technique du fournisseur peut réellement offrir.
| Point de mesure | Question à résoudre |
|---|---|
| Disponibilité | Quel niveau de pourcentage, période et composant s'appliquent ? |
| P1/P2/P3 | Comment définir un incident critique, élevé ou normal ? |
| Temps de réponse | Quand le fournisseur doit-il avoir commencé une prise en charge qualifiée ? |
| Rétablissement | Existe-t-il des objectifs de rétablissement du service et des données ? |
| Communication | À quelle fréquence le client doit-il recevoir une mise à jour du statut ? |
| Pénalité | Quand un crédit de service ou un autre droit est-il déclenché ? |
Classes d'incidents et temps de réponse
La classification des incidents doit être basée sur l'impact, et non uniquement sur le type de défaut technique. Une erreur peut être techniquement limitée mais critique pour l'activité si, par exemple, elle bloque les paiements ou l'accès à un processus central.
Pour chaque niveau de priorité, le SLA peut indiquer le temps de première réponse, l'objectif de temps pour une solution de contournement (workaround) ou le rétablissement, la fréquence de mise à jour et le niveau d'escalade. Soyez attentif à la différence entre le temps de réponse et le temps de résolution. Une réponse dans les 30 minutes ne signifie pas automatiquement que l'erreur doit être résolue dans les 30 minutes.
Les fenêtres de support doivent correspondre à l'activité
Un temps de réponse P1 de 30 minutes est inutile pour une entreprise qui fonctionne 24h/24 si le support du fournisseur n'est ouvert que les jours ouvrables de 09h à 17h. Précisez quels niveaux s'appliquent en dehors des heures d'ouverture habituelles du support et comment les incidents critiques sont signalés.
RTO et RPO – deux objectifs de rétablissement différents
Le RTO est utilisé comme objectif pour la rapidité avec laquelle un service ou un processus doit pouvoir être rétabli après une interruption. Le RPO est utilisé comme objectif pour déterminer quelle quantité de perte de données vers le passé peut être tolérée dans une situation de rétablissement.
Ils ne doivent pas être choisis isolément dans le contrat informatique. Une BIA (Business Impact Analysis) peut montrer combien de temps l'entreprise peut réellement supporter une interruption et quelle perte de données est acceptable. Lisez le guide sur la Business Impact Analysis et l'exemple pratique de BIA.
Vérifiez également ce que le fournisseur entend par ses valeurs. Le RTO est-il un objectif, une garantie ou seulement un principe de conception interne ? Le RPO s'applique-t-il à tous les types de données ? À quelle fréquence le rétablissement est-il testé ?
Crédits de service – compensation ou seule sanction ?
Les crédits de service peuvent créer une incitation économique automatique lorsque le niveau de service n'est pas atteint. Un barème peut, par exemple, accorder un crédit plus important à mesure que le service s'éloigne du niveau cible.
Cependant, vérifiez si le contrat stipule que le crédit de service est la seule sanction pour le client. En cas de manquements graves ou récurrents, le client peut avoir besoin d'autres droits, comme le droit à un plan d'action, une escalade spécifique ou la résiliation. Coordonnez le SLA avec les limitations de responsabilité et les règles de résiliation du contrat principal.
Maintenance planifiée et autres exceptions
Le fournisseur doit normalement pouvoir assurer la maintenance du service, mais une exception trop large peut rendre l'objectif de disponibilité trompeur. Régulez le délai de préavis pour la maintenance, les fenêtres horaires autorisées et si la maintenance de sécurité d'urgence est traitée différemment.
Soyez également prudent avec les exceptions concernant les services tiers. Si le fournisseur a lui-même choisi un fournisseur cloud ou d'infrastructure critique, le contrat doit clarifier comment cette dépendance affecte le SLA et la responsabilité.
Check-list pour un SLA utile
- Le service mesuré est-il clairement défini ?
- Existe-t-il une formule univoque pour la disponibilité ?
- La maintenance planifiée est-elle limitée ?
- Les niveaux d'incidents sont-ils liés à l'impact sur l'activité ?
- Le contrat distingue-t-il la réponse, la solution de contournement et la résolution ?
- Le support fonctionne-t-il pendant vos périodes critiques d'exploitation ?
- Le RTO/RPO est-il lié aux besoins réels de continuité ?
- Existe-t-il une exigence de mise à jour du statut lors d'incidents P1 ?
- Les crédits de service et autres sanctions sont-ils clairs ?
- Existe-t-il un droit d'agir en cas de violations répétées du SLA ?
Besoin d'un contrat principal et d'un SLA dans la même structure ?
Les modèles de contrat SaaS de la boutique contiennent un contrat principal et six annexes concernant, entre autres, la spécification du service, le SLA, le sous-traitant (PUB/RGPD), la sécurité, la sortie et le prix. Word et PDF. Prix en boutique : 149 kr.
Voir le contrat SaaSQuestions fréquentes
99,9 % est-il toujours un bon SLA ?
Non. Le bon niveau dépend de la criticité du service, de la méthode de mesure, des exceptions et du coût d'une redondance plus élevée. Le pourcentage doit être replacé dans son contexte.
Le RTO est-il la même chose que la disponibilité SLA ?
Non. La disponibilité mesure normalement l'exploitation sur une période. Le RTO concerne l'objectif de rétablissement après une interruption.
Le crédit de service doit-il être la seule sanction ?
C'est une question contractuelle, mais le client doit consciemment évaluer si le crédit seul est suffisant en cas de manquements graves ou répétés.
Conseils connexes
Lisez le guide du contrat SaaS, NIS2 et la sécurité des fournisseurs et le guide du plan de continuité.
Sources et lectures complémentaires
Le guide fournit des informations générales. Les niveaux de SLA doivent être adaptés à l'architecture du service, à la criticité de l'activité et aux autres conditions contractuelles.
