SLA support IT: comment éviter les faux indicateurs
Mesurer le temps de réponse, c’est bien. Mesurer l’impact, c’est mieux. Voici une grille simple (B2B).
Un SLA qui mesure uniquement le temps de réponse peut masquer des problèmes réels. Exemple: un ticket résolu en 2h mais qui bloque la production pendant 48h n’est pas un succès.
Priorités claires: P1 (production down, perte de données), P2 (impact utilisateur majeur), P3 (fonctionnalité dégradée), P4 (amélioration). Chaque niveau a sa fenêtre de réponse et d’escalade.
Fenêtre de service: définir les heures ouvrables (ex: 09h-18h) et les astreintes (24/7 pour P1 uniquement). Hors fenêtre, escalade automatique vers l’astreinte.
Escalade: si pas de réponse dans la fenêtre, escalade vers le niveau supérieur (technicien → expert → manager). Le délai d’escalade doit être documenté et auditable.
Reporting: mesurer le temps de résolution réel (pas seulement le temps de réponse), le taux d’escalade, et l’impact métier (downtime, perte de revenus). Un dashboard simple avec ces 3 métriques suffit.
Point clé: un SLA doit être lisible, aligné sur les risques métier, et auditable. Évitez les métriques de vanité (nombre de tickets fermés) qui ne reflètent pas la qualité du service.