Gestion des Engagements (SLAs)
1. Contexte et Objectifs
Dans un parc informatique géré sous GLPI, la qualité du support ne se mesure pas seulement à la résolution des incidents, mais aussi au respect des délais. L'objectif de cette mission est de mettre en place des SLA (Service Level Agreement), c'est-à-dire des engagements de niveau de service qui définissent des délais maximaux à tenir pour prendre en charge et résoudre les tickets.
Le but est de passer d'un suivi "au ressenti" à un pilotage mesurable : surveiller automatiquement les temps de traitement, déclencher des alertes en cas de dépassement, et adapter ces délais aux horaires réels de l'entreprise (un délai ne doit pas courir la nuit ou le week-end, quand personne ne travaille).
2. Besoins identifiés
Respect des heures ouvrées : Les délais de SLA ne doivent s'écouler que pendant les heures d'activité de l'entreprise (par exemple 8h-18h30). Sans cela, un ticket ouvert un vendredi soir serait considéré "en retard" le lundi matin alors que personne n'a travaillé entre-temps. Il faut donc un calendrier de travail qui définit les plages d'ouverture et les jours fériés.
Indicateurs de performance (KPI) : Deux métriques clés encadrent le cycle de vie d'un ticket : - TTO (Time To Own) : le délai maximal pour la prise en charge initiale du ticket (le moment où un technicien se l'attribue). - TTR (Time To Resolve) : le délai maximal pour la résolution complète de l'incident.
Hiérarchisation des actifs : Tous les équipements n'ont pas la même criticité. Il faut donc appliquer des niveaux de service différenciés selon l'importance du matériel : - SLA Or : délais courts, réservés aux serveurs (criticité majeure, impact fort en cas de panne). - SLA Bronze : délais standards, pour les postes de travail (impact limité à un utilisateur).
3. Solution technique
Synchronisation temporelle : Pour que GLPI calcule correctement les délais, le moteur PHP doit être aligné sur l'heure locale. Cela passe par la configuration de la directive date.timezone dans le fichier php.ini, réglée sur Europe/Paris.
Automatisation système (Cron) : Les SLA ne se mettent pas à jour tout seuls dans l'interface web. Il faut un ordonnanceur qui déclenche les actions de GLPI en arrière-plan à intervalle régulier. On utilise pour cela cron, l'ordonnanceur de tâches de Linux, configuré pour exécuter le script GLPI chaque minute.
Mode d'exécution CLI : Par défaut, certaines tâches automatiques de GLPI dépendent de la navigation web d'un utilisateur (mode "GLPI"). On bascule ces tâches en mode CLI (Command Line Interface) pour qu'elles s'exécutent en totale autonomie, sans dépendre de la présence d'un utilisateur connecté.
4. Réalisation
Configuration PHP : Édition du fichier /etc/php/8.4/cli/php.ini pour activer la ligne date.timezone = Europe/Paris, garantissant un calcul correct des délais.
Mise en œuvre de la chaîne automatisée : Ajout de la tâche planifiée via la commande sudo crontab -u www-data -e, puis ajout de la ligne :
* * * * * /usr/bin/php /var/www/html/glpi/front/cron.php
Cette ligne déclenche le moteur GLPI chaque minute, sous l'utilisateur du serveur web.
Activation du mode Expert : Dans l'interface GLPI, paramétrage de la tâche automatique slaticket en mode d'exécution CLI avec une fréquence de 1 minute, pour un suivi des SLA en temps quasi réel.
Création des niveaux de service : Définition de deux niveaux dans Configuration > Niveaux de services : - SLA Or (Serveurs) : TTO de 15 minutes, TTR de 2 heures, rattaché au calendrier de l'entreprise. - SLA Bronze (Postes) : TTO de 4 heures, TTR de 19 heures, même calendrier.
Configuration du calendrier de travail : Définition des plages horaires d'ouverture (du lundi au vendredi, environ 8h-18h30) et ajout des périodes de fermeture récurrentes (Fête du travail, Fête nationale, Noël) pour que les délais ne courent pas pendant ces journées.
5. Preuves de réalisation
Capture 1 : Niveau de service SLA Or (Serveurs)
`
Légende : Configuration du niveau de service SLA Or appliqué aux serveurs. On y voit les deux engagements définis : TTO (prise en charge) et TTR (résolution) avec leurs durées maximales respectives, rattachés au calendrier de travail de l'entreprise. Ce niveau prioritaire garantit une réactivité maximale sur les équipements critiques.
Capture 2 : Niveau de service SLA Bronze (Postes de travail)
`
Légende : Configuration du niveau de service SLA Bronze appliqué aux postes de travail. Les délais TTO et TTR sont plus larges que ceux du SLA Or, reflétant la criticité moindre de ces équipements. Cette différenciation illustre la hiérarchisation des actifs selon leur impact métier.
Capture 3 : Calendrier de travail et périodes de fermeture
`
Légende : Définition des plages horaires d'ouverture de l'entreprise (lundi au vendredi) et des jours fériés récurrents. Ce calendrier garantit que les délais de SLA ne s'écoulent que pendant les heures effectivement travaillées, évitant les fausses alertes de dépassement la nuit, le week-end ou les jours fériés.
Capture 4 : Timeline TTO/TTR sur un ticket de test
`
Légende : Vue chronologique d'un ticket montrant les jalons SLA calculés automatiquement par GLPI : date d'ouverture, échéance TTO (prise en charge) et échéance TTR (résolution). Cette visualisation prouve que le moteur de SLA fonctionne et positionne correctement les délais sur la base du calendrier configuré.
Capture 5 : Historique du ticket montrant l'action automatique (Cron)
`
Légende : Historique d'un ticket de test où l'on observe une modification effectuée automatiquement par la tâche planifiée (cron), par exemple un changement de priorité ou l'ajout d'un observateur. Cette trace prouve que la chaîne d'automatisation (cron + mode CLI) est opérationnelle et agit sur les tickets sans intervention humaine.