Un SLA solide ne doit pas etre un document commercial vague. Il doit decrire precisement ce qui est couvert, quand, avec quel niveau d engagement, et comment les incidents sont pilotes jusqu a resolution.
Les 6 briques d un bon SLA
1. Le perimetre exact
Le contrat doit lister les applications, environnements, interfaces, horaires et canaux de support inclus. Sans ce cadrage, les discussions sur les incidents deviennent floues tres vite.
2. Les niveaux de severite
Un bon SLA distingue au minimum:
- P1: service indisponible ou incident critique
- P2: forte degradation avec impact metier important
- P3: anomalie non bloquante
- P4: demande evolutive ou confort
Chaque niveau doit avoir un temps de prise en charge et un objectif de resolution.
3. Les engagements mesurables
Exemples frequents:
- prise en charge P1 en moins de 30 minutes
- contournement ou resolution P1 sous 4 heures
- disponibilite cible mensuelle
- delai de traitement des demandes standards
Le plus important est de distinguer temps de reponse, temps de prise en charge, et temps de resolution.
4. La supervision
Sans monitoring ni alerting, le fournisseur depend du client pour decouvrir les incidents. Un bon dispositif inclut supervision, logs, checks applicatifs et point de contact d astreinte.
5. La gouvernance
Le SLA doit aussi decrire:
- les revues hebdomadaires ou mensuelles
- le reporting des incidents
- la gestion des causes racines
- les demandes d amelioration
6. La securite et les acces
Gestion des acces, traces, sauvegardes, environnement de test, mises a jour critiques: tout cela doit etre aligne avec le niveau de risque de l application.
Ce que les entreprises oublient souvent
Beaucoup de contrats oublient les points suivants:
- qui valide la cloture d incident
- comment est geree l escalade
- quels sont les horaires reels de couverture
- ce qui est hors perimetre
- comment sont suivies les actions preventives
Exemple de structure simple
Pour une plateforme critique B2B, on recommande souvent:
- support ouvre ou 24/7 selon l activite
- severites clairement documentees
- canal d urgence dedie
- comites de suivi mensuels
- backlog d amelioration continue
Cette logique est au coeur de notre offre support et maintenance applicative.
SLA et budget
Le prix depend du nombre d applications, de la criticite, des horaires, et du niveau d expertise necessaire. Un support 24/7 avec astreinte, supervision et incident management n a pas le meme cout qu un support de bureau sur ticket.
Notre recommandation
Si votre application soutient des ventes, des operations ou un service client, le SLA doit etre considere comme un outil de pilotage business, pas comme une simple annexe contractuelle.
Avant de signer, verifiez que le partenaire est capable de gerer aussi bien le correctif court terme que l amelioration continue. Si vous voulez structurer cela proprement, commencez par un audit sur la page contact.