Qu'est-ce que le SLA ?
1. Définition et concepts de base
1.1 Qu'est-ce qu'un SLA ?
Un Service Level Agreement (SLA), ou Accord de Niveau de Service, est un contrat formel entre un fournisseur de services (interne ou externe) et un client (ou une unité métier). Cet accord décrit :
- Les services fournis (périmètre et description précise).
- Les niveaux de performance ou les objectifs de service attendus (ex. : disponibilité, temps de réponse, temps de résolution).
- Les responsabilités du fournisseur de services et du client.
- Les pénalités ou mesures correctives prévues en cas de non-respect des objectifs de service.
Le but principal d'un SLA est de clarifier les attentes réciproques afin de favoriser la satisfaction du client et d'aligner les services informatiques sur les besoins métier.
1.2 Différence entre SLA, OLA et UC
- SLA (Service Level Agreement) : Accord formel entre la DSI/fournisseur et le client (ou la BU).
- OLA (Operational Level Agreement) : Accord entre différentes équipes ou départements internes pour soutenir la prestation de service définie dans le SLA. Par exemple, l'équipe réseau et l'équipe système se mettent d'accord sur leurs engagements internes pour garantir la disponibilité.
- UC (Underpinning Contract) : Contrat passé avec un fournisseur tiers pour soutenir la prestation de service. Par exemple, une entreprise peut avoir un contrat avec un prestataire de maintenance de matériel.
1.3 Pourquoi mettre en place un SLA ?
- Aligner l'IT sur les besoins métier (transparence des services rendus).
- Fournir un cadre d'amélioration continue grâce à la mesure d'indicateurs (KPI).
- Réduire les conflits en clarifiant les responsabilités et les seuils d'intervention.
- Faciliter la communication entre les utilisateurs, les équipes techniques et la direction.
2. Les SLA dans le cadre d'ITIL v4
2.1 Rappels sur ITIL v4
ITIL (Information Technology Infrastructure Library) est un ensemble de bonnes pratiques pour la gestion des services informatiques. La version 4 s'appuie sur le concept de Service Value System et s'articule autour de quatre dimensions et du Service Value Chain. ITIL v4 met l'accent sur :
- La création de valeur pour le client.
- L'adaptabilité face à des environnements changeants.
- L'approche holistique de la gestion de services.
2.2 La pratique de « Service Level Management » (SLM)
Dans ITIL v4, la pratique de Service Level Management consiste à définir, négocier, suivre et améliorer les niveaux de service. Ses missions principales :
- Comprendre les besoins des clients (au travers de la co-création de valeur).
- Établir des objectifs mesurables qui traduisent les besoins en indicateurs de performance.
- Créer et maintenir des SLA alignés sur ces objectifs.
- Assurer le suivi, l'évaluation et la révision continue des SLA, tout en communiquant sur la performance aux parties prenantes.
2.3 Les engagements typiques dans un SLA ITIL v4
- Disponibilité du service (en heures d'ouverture, 24/7, etc.).
- Temps de réponse (délai avant prise en compte de l'incident ou de la requête).
- Temps de résolution (délai pour solutionner un incident ou réaliser une demande).
- Taux de satisfaction (NPS, enquêtes utilisateurs).
- Pénalités ou compensations éventuelles si l'engagement n'est pas tenu.
3. Définir un SLA : étapes clés et contenu
3.1 Étapes clés pour construire un SLA
- Recueillir les besoins et attentes des utilisateurs/métiers.
- Analyser la faisabilité : identifier les contraintes techniques et organisationnelles.
- Définir les indicateurs clés de performance (KPI) et leurs seuils.
- Négocier les seuils de performance et les modalités (côté client et côté fournisseur).
- Rédiger l'accord formel avec la portée, les responsabilités et les procédures.
- Communiquer le SLA à toutes les parties prenantes.
- Mettre en place des outils de mesure et de suivi.
- Superviser et réviser régulièrement le SLA (amélioration continue).
3.2 Exemples de contenus détaillés
- Périmètre : Quels services, quelles applications, quelles unités concernées ?
- Heures de couverture : Support 8h/5j, 24h/7j, temps de hotline, etc.
- Disponibilité minimale : Par exemple, 99,5 % sur une plage donnée.
- Délai de prise en charge (SLA de réponse) : 30 minutes pour les incidents critiques, 4 heures pour les incidents modérés, etc.
- Délai de résolution (SLA de restauration) : 4 heures pour un incident de sévérité 1, 48 heures pour un incident de sévérité 2, etc.
- Escalade : Qui contacter et comment en cas de non-respect des seuils ou en cas de retard.
- Rapports et revues : Fréquence de reporting, format, interlocuteurs, indicateurs mesurés.
4. Exemples concrets d'indicateurs et de seuils
4.1 Indicateurs couramment utilisés
- Taux de disponibilité : Temps de disponibiliteˊTemps total planifieˊ\frac{\text{Temps de disponibilité}}{\text{Temps total planifié}} × 100
- Délai de réponse moyen : Temps moyen pour le premier contact après déclaration d'incident.
- Délai de résolution moyen : Temps moyen pour fermer un incident ou traiter une demande.
- Taux de satisfaction utilisateur : Résultat d'enquête post-intervention.
- Nombre d'incidents récurrents : Indique la stabilité ou non du système.
4.2 Exemple d'engagement pour un service « Helpdesk »
- Disponibilité du service de support : 7h-20h du lundi au vendredi.
- Temps de réponse :
- Incidents critiques (niveau 1) : 15 minutes
- Incidents hauts (niveau 2) : 1 heure
- Incidents moyens (niveau 3) : 4 heures
- Temps de résolution :
- Incidents critiques (niveau 1) : 4 heures
- Incidents hauts (niveau 2) : 24 heures
- Incidents moyens (niveau 3) : 72 heures
- Rapport mensuel : Taux de respect des objectifs, nombre d'incidents par niveau, taux de satisfaction.
5. Mettre en œuvre un SLA dans GLPI
5.1 Présentation de GLPI
GLPI (Gestionnaire Libre de Parc Informatique) est un outil open-source de gestion des services informatiques qui intègre :
- Un système de tickets pour gérer incidents et demandes.
- Un module SLA (natif ou via plugins selon les versions).
- La gestion de parc et des inventaires (via agents ou connecteurs).
- La gestion des changements, problèmes, etc., avec une approche ITIL.
5.2 Configurer un SLA dans GLPI
- Activer le module SLA (ou installer le plugin SLA si nécessaire).
- Définir les règles de priorités : associer des niveaux de gravité (critique, haut, moyen, bas) aux types d'incidents ou de demandes.
- Paramétrer les délais de réponse et de résolution pour chaque niveau de gravité.
- Configurer les heures de couverture (calendriers, jours fériés, horaires de support).
- Automatiser les escalades : définir des règles (notifier un manager si un ticket n'est pas traité dans le délai).
- Suivre les KPI via les rapports intégrés ou personnalisés (taux de respect SLA, délais moyens).
5.3 Exemples concrets d'utilisation dans GLPI
- Exemple 1 :
- SLA « Support bureautique » : Priorité moyenne pour les demandes d'installation ou de mise à jour de logiciels, objectif de résolution sous 48 heures.
- Dans GLPI : Création d'une règle SLA nommée « SLA Bureautique » avec délai de résolution 48h pour priorité "moyenne".
- Exemple 2 :
- SLA « Incidents réseaux critiques » : Objectif de résolution sous 4 heures.
- Dans GLPI : Règle SLA « SLA Réseau Critique », attribution automatique de la priorité "critique" aux tickets classés "réseau" + délai max 4h.
5.4 Suivi et rapport via GLPI
- Tableau de bord : Pour visualiser en temps réel le nombre de tickets ouverts, le respect du SLA, etc.
- Exports et rapports : Générer des rapports PDF/Excel mensuels pour la direction, avec le pourcentage de tickets traités dans les délais.
- Alertes automatiques : GLPI envoie des notifications d'escalade aux responsables si un ticket dépasse le délai défini.
6. Gouvernance, communication et amélioration continue
6.1 Processus de gouvernance
- Comité de pilotage (ou de gouvernance IT) : Valide et suit la performance des SLA, arbitre les éventuels conflits.
- Responsable Service Delivery : Supervise la mise en œuvre du SLA, communique avec les métiers, propose des ajustements.
- Équipes opérationnelles : Appliquent les procédures, respectent les engagements, font remonter les difficultés.
6.2 Communication autour des SLA
- Présentation : Communiquer clairement les objectifs aux équipes techniques et aux utilisateurs.
- Formation : Former les équipes au suivi des SLA et à l'utilisation des outils (ex. : GLPI).
- Reportings réguliers : Mettre en avant les succès (incidents résolus dans le délai), mais aussi les points d'amélioration (incidents récurrents, délais trop longs).
6.3 Amélioration continue
- Mesure régulière des écarts entre objectifs et résultats réels.
- Analyse des causes de non-respect (problèmes de ressources, de compétences, de procédures...).
- Plan d'action et ajustements réguliers des SLA, des processus ou des ressources allouées.
- Boucle de rétroaction pour réviser les SLA au gré de l'évolution des besoins métier.
7. Exemples concrets d'application
7.1 Entreprise de services numériques (ESN)
- Contexte : Une ESN fournit du support à plusieurs clients différents.
- SLA mis en place :
- Support VIP pour certains clients premium (temps de réponse < 15 min).
- Support standard pour d'autres (temps de réponse < 1h).
- Outils et méthodes :
- GLPI pour la gestion des tickets et l'assignation automatique.
- Rapports mensuels envoyés aux clients, mettant en avant le respect des SLA.
- Bénéfices :
- Clarification des attentes clients.
- Réduction des escalades conflictuelles.
- Fidélisation client grâce à une meilleure transparence.
7.2 Société interne (DSI d'un grand groupe)
- Contexte : La DSI gère tous les incidents et demandes bureautiques d'une filiale.
- SLA mis en place :
- Temps de résolution :
- Sévérité 1 (impact majeur) : 4 heures
- Sévérité 2 (impact moyen) : 24 heures
- Sévérité 3 (impact faible) : 3 jours
- Gestion dans GLPI :
- Configuration d'un calendrier spécifique (lun-ven, 8h-18h).
- Règles d'escalade envoyant un e-mail au manager de l'équipe si le ticket dépasse 75 % du temps SLA.
- Résultats attendus :
- Pilotage précis des performances (temps de réponse moyen, goulots d'étranglement).
- Reporting mensuel partagé avec la direction métier.
8. Conclusion et bonnes pratiques
- Commencer petit : Mieux vaut définir quelques indicateurs pertinents plutôt que trop d'indicateurs difficiles à suivre.
- Impliquer les parties prenantes : Les SLA doivent être compris et acceptés par tous (DSI, métiers, utilisateurs).
- Automatiser la mesure : Utiliser des outils comme GLPI pour automatiser la collecte de données et le reporting.
- Surveiller la satisfaction : Les SLA chiffrés ne garantissent pas la satisfaction s'ils ne reflètent pas la perception utilisateur.
- Réviser régulièrement : Les SLA doivent évoluer (niveaux d'engagement, périmètre, horaires) en fonction des nouveaux enjeux.
En somme, la mise en place de SLA est un levier essentiel pour la professionnalisation des services informatiques. ITIL v4 offre un cadre méthodologique moderne, centré sur la création de valeur et l'amélioration continue. GLPI, grâce à ses fonctionnalités de gestion de tickets et de SLA, constitue un outil robuste et accessible pour opérationnaliser ces pratiques.
Références complémentaires
- ITIL v4 Practice Guides -- Service Level Management, Incident Management, etc.
- Documentation officielle de GLPI : https://glpi-project.org/
- Forum de la communauté GLPI pour les plugins SLA et bonnes pratiques.
- ISO/IEC 20000 : Norme internationale pour la gestion des services IT, qui complète la démarche ITIL.
Conseil : La réussite d'un SLA ne dépend pas uniquement de l'outil, mais aussi de la maturité des processus, de l'engagement de la direction, et de la culture de service au sein de l'organisation.