Un SLA (Service Level Agreement) précise les engagements de disponibilité et de réactivité d'un prestataire de maintenance. Sans SLA, la maintenance devient une promesse vague. Avec un SLA mal calibré (délais irréalistes ou criticités non définies), il devient une source de conflits.
Voici comment l'offre Run de Nticstudio structure ses SLAs et ce que vous devez vérifier avant de signer un contrat de support.
Les composantes d'un SLA de maintenance applicative
Délai de prise en charge : le temps entre la signalement d'une anomalie et la confirmation de sa prise en compte par l'équipe de maintenance. C'est la première mesure de réactivité.
Délai de résolution : le temps entre la prise en charge et la correction déployée en production. Ce délai dépend de la complexité de l'anomalie — il ne peut pas être garanti de manière absolue mais peut être estimé selon la criticité.
Disponibilité garantie : le pourcentage de temps pendant lequel l'application doit être accessible. 99,9 % représente environ 8,7 heures d'indisponibilité par an. 99,99 % représente moins d'une heure. Le niveau requis dépend de la criticité métier de l'application.
Niveaux de criticité et leur impact sur les délais
P0 — Critique : l'application est inaccessible ou une fonctionnalité cœur de métier ne fonctionne pas pour tous les utilisateurs. Prise en charge : immédiate (< 1 heure). Résolution cible : 4 heures.
P1 — Haute : une fonctionnalité importante est défaillante pour une partie des utilisateurs ou avec une solution de contournement. Prise en charge : < 4 heures. Résolution cible : 24 heures.
P2 — Normale : bug gênant mais non bloquant. Prise en charge : < 8 heures ouvrées. Résolution : prochain cycle de maintenance.
P3 — Basse : amélioration ou bug cosmétique. Planification : backlog de maintenance.
Plages horaires et astreinte
Un SLA standard couvre les heures ouvrées (9h-18h, lundi-vendredi). Une astreinte étendue (soirs, week-ends) est possible pour les applications dont la criticité le justifie, mais elle se facture en conséquence.
La définition des heures couvertes doit être explicite dans le contrat. Un incident signalé un dimanche à 22h est traité le lundi matin si le SLA ne couvre pas les week-ends.
Ce qui n'est pas couvert par un SLA standard
Un SLA couvre les anomalies de l'application telle qu'elle a été livrée. Il ne couvre pas : les incidents liés à des tiers (panne d'hébergeur, indisponibilité d'une API externe), les modifications demandées par le client (qui sont des évolutions), ou les incidents causés par des modifications non autorisées de l'application.
Ces exclusions doivent être explicites dans le contrat pour éviter les malentendus lors d'un incident.