Un SLA solide ne doit pas être un document commercial vague. Il doit decrire précisément ce qui est couvert, quand, avec quel niveau d engagement, et comment les incidents sont pilotes jusqu'à résolution.
Les 6 briques d'un bon SLA
1. Le périmètre 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 très vite.
2. Les niveaux de sévérité
Un bon SLA distingue au minimum:
- P1: service indisponible ou incident critique
- P2: forte degradation avec impact métier important
- P3: anomalie non bloquante
- P4: demande évolutive ou confort
Chaque niveau doit avoir un temps de prise en charge et un objectif de résolution.
3. Les engagements mesurables
Exemples fréquents:
- prise en charge P1 en moins de 30 minutes
- contournement ou résolution P1 sous 4 heures
- disponibilité cible mensuelle
- délai de traitement des demandes standards
Le plus important est de distinguer temps de réponse, temps de prise en charge, et temps de résolution.
4. La supervision
Sans monitoring ni alerting, le fournisseur dépend du client pour découvrir les incidents. Un bon dispositif inclut supervision, logs, checks applicatifs et point de contact d astreinte. Voir aussi notre approche d'audit de sécurité pour le volet preventif.
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 amélioration
6. La sécurité et les accès
Gestion des accès, traces, sauvegardes, environnement de test, mises à jour critiques: tout cela doit être aligne avec le niveau de risque de l'application. Notre guide cybersécurité PME Maroc couvre les mesures techniques à exiger.
Ce que les entreprises oublient souvent
Beaucoup de contrats oublient les points suivants:
- qui valide la clôture d incident
- comment est gérée l escalade
- quels sont les horaires réels de couverture
- ce qui est hors périmètre
- comment sont suivies les actions préventives
Exemple de structure simple
Pour une plateforme critique B2B, on recommandé souvent:
- support ouvre ou 24/7 selon l activité
- sévérités clairement documentées
- canal d urgence dédié
- comites de suivi mensuels
- backlog d amélioration continue
Cette logique est au coeur de notre offre support et maintenance applicative.
SLA et budget
Le prix dépend du nombre d'applications, de la criticite, des horaires, et du niveau d expertise nécessaire. Un support 24/7 avec astreinte, supervision et incident management n'a pas le même coût qu'un support de bureau sur ticket.
Notre recommandation
Si votre application soutient des ventes, des opérations ou un service client, le SLA doit être considéré comme un outil de pilotage business, pas comme une simple annexe contractuelle.
Avant de signer, verifiez que le partenaire est capable de gérer aussi bien le correctif court terme que l amélioration continue. Si vous voulez structurer cela proprement, commencez par un audit sur la page contact.