Un SLA (Service Level Agreement) mal rédigé est une machine à litiges
Promesses vagues, indicateurs non mesurables, seuils irréalistes, mécanismes de compensation flous… Résultat : tensions, avoirs contestés, menaces de résiliation.
À l’inverse, un SLA bien conçu est un stabilisateur de la relation : il clarifie les attentes, définit les preuves, et propose des solutions proportionnées lorsque les seuils ne sont pas atteints (credits de service plutôt que pénalités punitives).
Ce guide vous livre une méthode opérationnelle pour écrire des SLA opposables et praticables, que vous soyez prestataire (SaaS/IT/infogérance/industrie) ou client (DSI, direction métier, supply).
I) Les indicateurs qui comptent (et comment les rendre mesurables)
1) Choisir les bons SLI (Service Level Indicators)
Un bon indicateur :
- Mesure le service perçu par le client (et non un proxy technique inutile) ;
- Est défini sans ambiguïté (périmètre, fenêtres de mesure, exclusions) ;
- Permet un arbitrage rapide (OK / non‑OK).
Exemples robustes (à adapter au contexte) :
- Disponibilité mensuelle d’un service (uptime, % sur 30 jours)
- Temps de rétablissement moyen (MTTR) par criticité
- Taux d’incidents P1 résolus dans le délai contractuel
- Délai de prise en charge (SLA de support)
- Qualité logistique (OTIF : On‑Time In‑Full, taux de conformité)
Astuce : si un SLI ne peut pas être audité par deux sources distinctes, il est probablement trop vague.
2) Passer du SLI au SLO (Service Level Objective)
Le SLO, c’est la cible chiffrée :
- Disponibilité 99,9 % / mois (avec définition des fenêtres d’entretien)
- MTTR < 2h pour incidents P1 ; < 8h pour P2
- OTIF ≥ 97 % par mois
Clés de robustesse :
- Fixer 1 à 3 SLOs majeurs (pas 12) ;
- Préciser comment on calcule (formule), quand (fenêtre), où (environnements), qui (responsable du calcul).
3) Définir les exclusions légitimes
Les SLA dérapent lorsque tout incident compte, même les cas hors contrôle. Prévoyez des exclusions :
- Fenêtres d’entretien planifié (avec préavis)
- Force majeure
- Mauvaise utilisation / non‑respect des prérequis
- Tiers non maîtrisés explicitement exclus (ou encadrés via des SLO spécifiques)
Principe : l’exclusion n’est pas une échappatoire ; elle s’applique rarement, est précise et documentée.
II) Seuils, credits & gouvernance : transformer la tension en mécanisme de correction
1) Fixer des seuils gradués (et un unique “seuil critique”)
Un SLA binaire (OK / KO) crée des crispations. Préférez une gradation :
- Seuil cible (vert) : SLO respecté → RAS
- Seuil d’alerte (orange) : écart mineur → plan d’actions & suivi
- Seuil critique (rouge) : écart significatif → credits de service (ou pénalités graduées)
Exemple (disponibilité 99,9 %) :
- ≥ 99,9 % : vert
- 99,7–99,89 % : orange (RCA + plan d’actions sous 10 j)
- < 99,7 % : rouge (credits)
2) Mettre en place des credits de service (plutôt que la sanction “coup de massue”)
Les credits sont des avoirs proportionnés à l’impact :
- Montant : % des frais mensuels du service impacté
- Plafond : ex. 20–30 % par mois (cap global)
- Cumul : préciser si cumulable entre SLOs (souvent non, ou limité)
- Déclenchement : automatique sur dépassement et après validation des preuves
- Non‑exclusivité : les credits n’excluent pas des recours en cas d’échec répété (clause de médiation / résiliation pour non‑performance)
Les credits évitent la bascule en contentieux en apportant une réponse immédiate et calibrée au préjudice.
3) Gouvernance & RCA (Root Cause Analysis)
Un SLA sans gouvernance se transforme en rituel stérile. Installez :
- Une revue mensuelle (30–45 min) : SLI/SLO, incidents, credits, plan d’actions
- Une RCA obligatoire sur chaque seuil critique franchi (modèle 5 “Pourquoi ?”, Ishikawa, etc.)
- Un plan d’amélioration daté, avec responsables & livrables
III) Prouver, auditer, trancher : la clause qui éteint 80 % des litiges
1) Les preuves (ce que le SLA doit exiger)
- Sources de données (outils de monitoring, ITSM, journal d’événements, ERP/logistique)
- Granularité (minute, 5 minutes, heure) et horodatage (UTC/local)
- Conservation (ex. 12 mois glissants minimum)
- Redevabilité : qui agrège ? qui valide ? comment le client peut répliquer le calcul ?
Règle d’or : “Pas de preuve, pas de SLA” — sans data pipeline explicite, vous créez une zone de litige.
2) Auditabilité & accès
- Droit d’audit annuel (raisonnable, sur préavis), limité au périmètre SLA
- Export mensuel standard (CSV/JSON/PDF)
- Tableaux de bord (read‑only) pour le client
- Traçabilité des corrections (journal de modifications)
3) Clause de résolution amiable intégrée au SLA
- Escalade interne (opérationnels → managers → directions) avec délais
- Médiation conventionnelle en cas de désaccord persistant (6–8 semaines)
- Sortie si échec (arbitrage/tribunal) — mais après avoir épuisé le filet amiable
Cette micro‑clause désamorce l’opposition stérile sur les chiffres et ramène les équipes à une logique de solution.
Exemples express (à adapter)
SaaS – Disponibilité & support
- SLI : disponibilité mensuelle (exclusions définies) ; délai de prise en charge P1
- SLO : dispo 99,9 % ; prise en charge P1 < 15 min
- Credits : 5 % si < 99,7 % ; 10 % si < 99,5 % (cap 25 %)
- Preuves : export monitoring + ITSM ; RCA si rouge
- Astuces : prévoyez un grace period de 15 min sur bascules planifiées
Infogérance – MTTR & incidents
- SLI : MTTR par criticité ; taux de résolution dans le délai
- SLO : MTTR P1 < 2h ; 95 % des P2 < 8h
- Credits : 2–3 % par seuil critique manqué (cap 20 %)
- Preuves : tickets horodatés + journaux d’événements corrélés
- Astuces : distinguer incidents P1 “activité empêchée” vs. P2 “activité dégradée”
Logistique – OTIF & intégrité
- SLI : OTIF mensuel ; taux d’avarie
- SLO : OTIF ≥ 97 % ; avaries ≤ 0,3 %
- Credits : avoir unitaire sur commandes impactées + cap global
- Preuves : WMS/TMS + POD (proof of delivery)
- Astuces : neutraliser les aléas douaniers clairement identifiés
Un bon SLA, c’est 3 choses
- Indicateurs utiles (SLI) et cibles claires (SLO) ;
- Seuils gradués & credits pour corriger sans s’entretuer ;
- Preuves et gouvernance pour sortir des impressions et piloter des plans d’amélioration.
Résultat : moins d’opacité, moins de crispation — plus de confiance, plus de résultats.
✅ FAQ
1) C’est quoi un SLA exactement ?
Un SLA est un accord de niveau de service : il définit ce que le prestataire doit délivrer, comment on le mesure et ce qui se passe en cas d’écart.
2) Quelle est la différence entre SLI et SLO ?
- SLI : l’indicateur (ce qu’on mesure).
- SLO : la cible (le niveau attendu).
3) Pourquoi les SLA créent-ils autant de litiges ?
Parce que les indicateurs sont souvent vagues, non mesurables, ou non auditables.
4) Comment choisir un bon indicateur (SLI) ?
Il doit être : mesurable, objectivable, lié au service perçu et auditables par deux sources.
5) Combien d’indicateurs faut-il dans un SLA ?
Entre 1 et 3 indicateurs majeurs. Au-delà, le système devient instable.
6) Comment fixer un SLO réaliste ?
En croisant : historique, capacités réelles, contraintes techniques et comparaisons sectorielles.
7) Qu’est-ce qu’un seuil d’alerte dans un SLA ?
Un niveau où le SLO n’est pas encore “cassé”, mais où une action corrective est nécessaire.
8) À quoi sert un seuil critique ?
À déclencher automatiquement des credits de service (ou pénalités).
9) Faut-il prévoir des exclusions dans un SLA ?
Oui, pour les cas hors contrôle : maintenance planifiée, force majeure, usage non conforme.
10) Faut-il préciser la méthode de calcul ?
Absolument : sans formule, le SLA devient interprétable → litige garanti.
11) Le SLA doit-il prévoir les outils de mesure ?
Oui : monitoring, ITSM, logs, WMS/TMS… avec précision des sources.
12) Comment éviter les contestations sur les chiffres ?
Préciser : source, granularité, horodatage, conservation des données.
13) Les credits de service sont-ils obligatoires ?
Non, mais ils stabilisent la relation : ils remplacent les conflits par des compensations proportionnées.
14) Comment calculer un credit de service ?
En % du montant mensuel du service impacté, avec un cap global défini.
15) Peut-on cumuler plusieurs credits ?
Oui ou non : il faut le dire. La plupart des contrats prévoient un plafond mensuel ou annuel.
16) Les credits remplacent-ils les recours en cas d’échec répété ?
Non. Ils corrigent ponctuellement ; mais une répétition peut mener à la médiation ou à la résiliation.
17) Comment structurer la gouvernance d’un SLA ?
Avec des revues mensuelles, un suivi des plans d’action, et des RCA sur les incidents critiques.
18) C’est quoi une RCA ?
Une Root Cause Analysis : recherche des causes profondes, pas seulement des symptômes.
19) Pourquoi l’auditabilité est-elle cruciale ?
Parce qu’un SLA non auditable ne peut pas être appliqué sans litige.
20) Faut-il un droit d’audit ?
Oui, raisonnable : sur préavis, limité au périmètre SLA.
21) Comment éviter les litiges sur les pénalités ?
En privilégiant des credits gradués, plutôt qu’une pénalité unique disproportionnée.
22) Les SLA doivent-ils prévoir un plan B en cas d’échec répété ?
Oui : escalade → médiation → résiliation si nécessaire.
23) Comment intégrer la médiation dans un SLA ?
Avec une clause simple : escalade interne → médiation → juge/arbitrage.
24) Les SLA doivent-ils être indépendants du contrat ?
Non. Ils doivent être cohérents avec les clauses de responsabilité, d’assurance et de réversibilité.
25) Un SLA peut-il être trop strict ?
Oui : un SLO irréaliste crée un litige automatique. Il doit être ambitieux et atteignable.
26) Comment sécuriser la disponibilité (uptime) ?
En définissant : fenêtres d’entretien, seuils, exclusions, logs, méthode de mesure.
27) Comment sécuriser les délais d’intervention (support) ?
En définissant : criticités, prise en charge, résolution, preuves (tickets horodatés).
28) Comment articuler SLA & réversibilité ?
Préciser que certains SLO cessent à la fin du contrat, mais que les obligations de transfert restent.
29) Pourquoi prévoir une “grille des incidents” ?
Pour classifier P1/P2/P3 de manière objective — sinon, chaque incident devient un débat.
30) Quelle est la règle d’or pour un SLA anti‑litige ?
Mesurer → prouver → corriger → escalader avant de s’affronter.