NexTool Solutions

Configurer le SLA et l'OLA dans GLPI est la partie facile - ce qui casse en production, c'est l'escalade qui ne se déclenche jamais. En maintenance d'environnements GLPI de clients, la demande qui revient le plus n'est pas "comment créer un SLA", mais "j'ai tout configuré et personne n'est prévenu quand le délai est dépassé". Ce guide configure le SLA et l'OLA dans GLPI 11 depuis zéro et montre les requêtes SQL que nous utilisons pour diagnostiquer pourquoi les délais ne notifient pas.

SLA vs OLA : ce qui change en pratique

SLA (Service Level Agreement) est l'accord avec le client (interne ou externe) : il définit l'engagement de temps de réponse et de résolution. Exemple : "les tickets de priorité haute sont pris en compte en 1h et résolus en 4h".

OLA (Operational Level Agreement) est l'accord interne entre les équipes qui soutiennent ce SLA. Exemple : "l'infrastructure répond aux escalades du N1 en 30 minutes". Dans GLPI, le SLA écrit les délais dans time_to_own et time_to_resolve du ticket ; l'OLA écrit dans internal_time_to_own et internal_time_to_resolve. Les deux courent en parallèle - et c'est là le premier malentendu : escalader vers le N2 ne met PAS le SLA client en pause.

Comment GLPI modélise le SLA et l'OLA en interne

Comprendre le modèle de données évite la plupart des erreurs de configuration. Dans GLPI, le SLA et l'OLA ne sont pas des objets isolés : ils vivent dans un SLM (Service Level), et c'est le SLM qui porte le calendrier.

• SLM (glpi_slms) : le parapluie. Il porte le calendars_id - donc le calendrier appartient au SLM, pas à chaque SLA.
• SLA (glpi_slas) et OLA (glpi_olas) : chaque ligne est un délai, avec type (TTO ou TTR), number_time et definition_time (minute / hour / day).
• Niveaux d'escalade (glpi_slalevels / glpi_olalevels) : les actions déclenchées à X% du délai.

Deux notions qui perturbent souvent ceux qui viennent d'un autre outil :

TTO - Time to Own (temps de réponse)

Délai jusqu'à ce que le ticket soit "pris en compte" (assumé par un technicien). Attention : le TTO ne se ferme pas quand quelqu'un ouvre simplement le ticket à l'écran ; il se ferme à la première attribution ou au premier suivi - c'est ce que GLPI enregistre dans takeintoaccount_delay_stat.

TTR - Time to Resolve (temps de résolution)

Délai jusqu'à la résolution du ticket.

Pas à pas : configurer le SLA dans GLPI 11

1. Le calendrier d'abord. Avant le SLA, définissez le calendrier de service (Configuration > Calendriers) avec les plages horaires réelles (ex. : lun-ven, 08:00-18:00). Si le SLM n'a pas de calendrier (calendars_id = 0), GLPI compte 24h d'affilée ; avec un calendrier, il ne compte que les heures ouvrées.
2. Créez le SLM et associez le calendrier. C'est le conteneur qui regroupe les SLA et OLA du service.
3. Créez un SLA par priorité, un pour le TTO et un pour le TTR. Utilisez la matrice ci-dessous comme point de départ.
4. Attribuez via une règle métier (Administration > Règles > Règles métier pour les tickets) : critère Priorité = Haute, action "Attribuer SLA (TTR)" et "Attribuer SLA (TTO)". Le SLA est appliqué à la création ; si la priorité change ensuite, il faut une règle qui recalcule.
5. Configurez les niveaux d'escalade dans chaque SLA (actions à 75%, 100% et 150% du délai).

Ce sont des fourchettes honnêtes de départ : recalibrez après 60-90 jours avec les chiffres réels de votre Service Desk et ne copiez jamais les délais d'un autre client.

Configurer l'OLA

L'OLA suit la même structure (TTO/TTR plus niveaux d'escalade), mais mesure l'engagement interne entre équipes. Le scénario typique : quand le N1 escalade vers le N2, l'OLA du N2 commence à compter - et GLPI enregistre ces délais dans internal_time_to_own et internal_time_to_resolve, séparés du SLA client. Pour répéter le point qui génère le plus de questions : l'OLA ne fige pas le SLA.

L'erreur courante : l'escalade qui ne se déclenche jamais

En maintenance, le ticket SLA récurrent ne porte pas sur la configuration - c'est "le délai a été dépassé et personne n'a été prévenu". Dans presque tous les cas la cause est la même : l'action automatique slaticket, qui parcourt les niveaux d'escalade, est en mode interne (elle ne s'exécute que quand quelqu'un navigue dans GLPI) ou le cron externe de GLPI n'est pas actif. Le niveau existe, le délai est enregistré dans time_to_resolve, mais rien ne se déclenche à 75% car le processus qui lit les niveaux ne s'exécute jamais. C'est pourquoi, dans notre checklist de déploiement, vérifier slaticket passe AVANT de créer le moindre niveau d'escalade.

Assurez-vous que le cron de GLPI tourne en mode externe :

# /etc/cron.d/glpi - exécute les actions automatiques de GLPI (dont slaticket)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Ensuite, confirmez dans la base que l'action est vivante et en mode externe :

-- État de l'action automatique d'escalade du SLA.
-- mode:  1 = interne (mauvais, dépend de la navigation), 2 = externe (correct)
-- state: 1 = en attente, 2 = en cours, 0 = désactivé
SELECT name, state, mode, lastrun, frequency
FROM glpi_crontasks
WHERE name = 'slaticket';

Et la requête que nous lançons au quotidien en maintenance : les tickets dont le délai de résolution est déjà dépassé et encore ouverts.

-- Tickets avec un TTR dépassé et non encore résolus.
-- status: 5 = résolu, 6 = clos (exclus)
SELECT t.id, t.name, t.time_to_resolve, t.status
FROM glpi_tickets t
WHERE t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()
  AND t.status NOT IN (5, 6)
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Pour auditer la configuration (et attraper le SLM sans calendrier avant qu'il ne casse les délais) :

-- SLAs configurés et le calendrier hérité du SLM.
-- calendrier NULL/vide = comptage 24h d'affilée (le piège classique).
SELECT s.name AS sla,
       CASE s.type WHEN 1 THEN 'TTO' WHEN 0 THEN 'TTR' END AS type,
       s.number_time, s.definition_time,
       cal.name AS calendrier
FROM glpi_slas s
JOIN glpi_slms slm ON slm.id = s.slms_id
LEFT JOIN glpi_calendars cal ON cal.id = slm.calendars_id
ORDER BY s.name;

Bonnes pratiques d'exploitant

• Commencez avec 3-5 niveaux et recalibrez après 60-90 jours avec des données réelles.
• Calendrier réaliste : ne configurez pas du 24x7 si l'équipe travaille en heures ouvrées - sinon le délai "court" la nuit et le ticket naît déjà dépassé.
• Alertez avant le dépassement (75%) pour laisser le temps de réagir, pas seulement au dépassement.
• N'éditez jamais les statuts ou les délais en masse via SQL : vous contournez le recalcul du temps d'attente (sla_waiting_duration) et le délai devient faux.
• Documentez quelle règle métier attribue chaque SLA - une règle orpheline est la deuxième cause de "SLA non appliqué".

Étape suivante

Une fois le SLA et l'OLA en place, construisez votre catalogue de services et suivez les KPI de votre Service Desk pour savoir si les délais sont réalistes.

Si votre exploitation a grandi et que le SLA devient un débat hebdomadaire, le service de maintenance GLPI de NexTool prend en charge la configuration, le cron et le suivi des délais pour vous.

Révisé par l'équipe NexTool Solutions.