> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/glpi-12/fr/setup/service-levels.md). # Niveaux de services ## Comprendre les niveaux de service La gestion des niveaux de service est l'un des piliers d'un helpdesk. Dans GLPI, cette gestion repose sur deux mécanismes complémentaires : le **SLA** (Service Level Agreement) et l'**OLA** (Operational Level Agreement). Ils permettent de garantir des délais de traitement des tickets, de déclencher des actions automatiques et d'alerter les bonnes personnes avant qu'une échéance ne soit dépassée. *** ## SLA et OLA GLPI distingue deux types d'accords de niveau de service : le SLA, qui est l'accord entre un fournisseur informatique et son client, et l'OLA, qui est l'accord entre les groupes ou départements internes de ce même fournisseur : * Le **SLA** formalise l'engagement pris vis-à-vis du client final (utilisateur, entité, société bénéficiaire du support, etc.). Il s'agit d'un accord documenté entre un fournisseur de services informatiques et un client, définissant les services requis et le niveau de service attendu. GLPI permet de saisir ces SLA afin que le service rendu reste conforme au contrat signé entre les deux parties. * L'**OLA** est un niveau de service purement interne au service informatique : il sert par exemple à cadrer le délai dans lequel une équipe support doit transmettre un ticket à une autre équipe, sans que cet engagement soit visible ou opposable au client. {% hint style="success" icon="trophy" %} Le SLA protège la relation avec le client, l'OLA organise la mécanique interne qui permet de tenir cette promesse. {% endhint %} *** ## Suivi Ces deux types d'accords sont utilisés dans GLPI pour suivre, de façon optionnelle, deux échéances : * le temps maximum qui doit s'écouler avant qu'un ticket ne soit assigné à un technicien * le temps maximum qui doit s'écouler avant qu'un ticket ne soit résolu. Ces deux échéances correspondent à des indicateurs bien connus en gestion de service : * **TTO – Temps de prise en charge** (Time To Own) : le temps maximum de prise en charge du ticket. * **TTR – Temps de résolution** (Time To Resolve) : le temps maximum de résolution du ticket. Un SLA ou un OLA peut porter sur l'un, l'autre, ou les deux indicateurs à la fois, selon ce que prévoit le contrat ou l'organisation interne. *** ## Calendrier Le calcul des échéances dépend d'un calendrier. Un calendrier peut être associé à un SLA ou à un OLA. Par défaut, si aucun calendrier n'est associé, les calculs sont effectués sur une base de travail continue, 7 jours sur 7 et 24 heures sur 24. Il est également possible d'utiliser le calendrier associé au ticket, c'est-à-dire celui de l'entité à laquelle le ticket est rattaché. Le mode de calcul change selon l'unité choisie pour le temps de résolution : * Si le temps de résolution maximum est exprimé en jours, tous les calculs sont effectués en jours (J+1, J+4, etc.) en tenant compte du calendrier pour déterminer les jours ouvrés ; avec l'indicateur « Fin de journée ouvrée », la date d'échéance correspond alors à la fin de la journée ouvrée correspondante. * Si le temps de résolution maximum est exprimé en heures ou en minutes, les calculs tiennent compte des heures d'ouverture définies dans le calendrier — par exemple, pour un SLA en H+4 avec des heures d'ouverture de 8h à 18h, un ticket ouvert à 16h aura une échéance fixée à 10h le lendemain. **Point important** : passer un ticket au statut « **en attente** » met le SLA en veille ; si le ticket reste en attente pendant 3 heures, par exemple, la date d'échéance est automatiquement reportée de 3 heures. Cela évite qu'un ticket bloqué par le client (attente d'information, de pièce, de validation) ne pénalise injustement le technicien ou le fournisseur. C'est pourquoi la première étape de toute configuration sérieuse consiste à définir les calendriers de référence (heures ouvrables, astreinte, jours fériés, etc.) avant même de créer les SLA ou OLA. *** ## Créer un SLA La création d'un SLA se fait depuis **`Configuration`** > **`Niveaux de service`**. {% stepper %} {% step %} #### Créer la fiche du SLA * Cliquez sur **`+ Ajouter`** * Donnez un **nom** explicite au SLA (par exemple « Support Standard – 5j »). * Sélectionnez le **calendrier** à associer dans la liste déroulante, ou en créer un nouveau si aucun ne convient. {% hint style="warning" icon="calendar-days" %} Cette étape calendrier est déterminante : elle qui détermine les créneaux d'ouverture ou d'intervention pris en compte dans tous les calculs de délais. {% endhint %} * Cliquez sur **`+ Ajouter`**

Ajout nouveau SLA

{% endstep %} {% step %} ### Ajouter un TTO (temps de prise en charge) Dans la fiche du SLA : * Cliquez sur **`Ajouter un nouvel élément`**. * Sélectionnez **TTO** dans **Temps de prise en charge** * Renseignez la valeur attendue, généralement fixée par le contrat (par exemple 4 heures). * Renseignez également la fréquence * Validez avec **`+ Ajouter`**.

Ajout d'un TTO

{% endstep %} {% step %} ### Ajouter un TTR (temps de résolution) * Cliquer de nouveau sur **`Ajouter un nouvel élément`**. * Sélectionner **Temps de résolution**. * Renseigner la valeur souhaitée (par exemple 5 jours). * Préciser si le dernier jour du délai doit obligatoirement être un jour ouvré. * Valider avec **`+ Ajouter`**.

Ajout d'un TTR

Au terme de ces deux étapes, l'engagement est clair et lisible : un ticket rattaché à ce SLA devra être pris en charge sous 4 heures et résolu sous 5 jours ouvrables. {% endstep %} {% step %} ### Créer un OLA L'ajout d'un OLA suit une procédure strictement identique à celle du SLA : * nom, * calendrier, * puis ajout éventuel d'un TTO et/ou d'un TTR. La seule différence est conceptuelle : l'OLA formalise un engagement interne (entre niveaux de support, entre équipes) plutôt qu'un engagement contractuel envers le client. À noter, **une évolution notable apportée par GLPI 12** : plusieurs OLA peuvent désormais être assignées sur un même ticket. Cela permet, par exemple, de modéliser un support à plusieurs niveaux : si le support de niveau 1 ne résout pas un ticket sous 48 heures, celui-ci remonte au niveau 2, qui dispose à son tour de son propre délai de prise en charge — le tout sans jamais toucher au SLA contractuel vis-à-vis du client.

Niveaux de service : Multiple OLA

{% endstep %} {% step %} ### Assigner automatiquement les SLA/OLA aux tickets Pour ne pas avoir à saisir manuellement un SLA à chaque ouverture de ticket, GLPI permet d'automatiser cette affectation via le **moteur de règles métier sur les tickets** (règles métier de type ticket). **Le principe** : définir des critères (catégorie, entité, priorité, type de demande, etc.) et, lorsqu'un ticket correspond à ces critères, la règle lui assigne automatiquement le SLA et/ou l'OLA adéquat. Il est ainsi possible de faire cohabiter plusieurs niveaux de service : un SLA pour une catégorie de tickets donnée, un autre pour le reste. **Deux points de vigilance** : * Si un SLA ou un OLA est assigné manuellement dès l'ouverture du ticket (par l'utilisateur ou via un modèle de ticket), les règles métier ne pourront pas le redéfinir ensuite. * Dès qu'un SLA/OLA est assigné à un ticket, il est entièrement rejoué, ce qui déclenche l'exécution des actions associées à ses niveaux d'escalade. **Exemple de règle d'affectation SLA** :

Exemple d'affectation de SLA

{% endstep %} {% endstepper %} *** ## Les niveaux d'escalade Un SLA ou un OLA sans niveau d'escalade se contente de fixer une échéance théorique. Ce sont les **niveaux d'escalade** qui transforment cette échéance en actions concrètes. Chaque niveau d'escalade déclenche des actions automatiques destinées à résoudre le ticket au plus vite. Il se déclenche avant ou après la date d'expiration du SLA/OLA, selon le délai que l'on a défini — par exemple, un jour avant l'échéance, le ticket peut être réaffecté au support de niveau 2 et sa priorité passée en « Haute ». Ces niveaux peuvent être conditionnés par des critères de déclenchement : sans critère, le niveau se déclenche systématiquement ; avec des critères, ceux-ci sont vérifiés avant application (par exemple, envoyer un rappel à l'administrateur uniquement si le ticket est encore au statut « Nouveau »). {% stepper %} {% step %} ### Configurer un niveau d'escalade sur un TTO Depuis **`Configuration`** > **`Niveaux de service`**, ouvrir l'onglet SLA (ou OLA) puis cliquer sur le TTO concerné : * Dans l'onglet **Niveau d'escalade**, renseigner un nom * Indiquer le moment d'exécution (avant, après ou à l'échéance du TTO) * Activer le niveau d'escalade * Cliquez sur **`+ Ajouter`**

Ajout niveau d'escalade au SLA

Vous serez basculé sur le paramétrage du niveau d'escalade adin de définir la règle associée : * Onglet **Critères** : par exemple « Statut est Nouveau ». * Onglet **Actions** : par exemple affecter un groupe de techniciens, puis changer la priorité en « Très haute ».

Règle du niveau d'escalade

{% hint style="info" icon="vial" %} Exemple : si le ticket est toujours au statut « **Nouveau** » à l'approche du TTO, un **groupe de techniciens** est automatiquement **affecté** et la **priorité** est relevée à « **Très haute** ». {% endhint %} {% endstep %} {% step %} ### Configurer un niveau d'escalade sur un TTR La logique est identique, avec une nuance : lorsqu'on veut couvrir tous les tickets « encore ouverts », il faut généralement combiner deux critères avec l'opérateur logique **OU** plutôt que ET — par exemple « Statut n'est pas Fermé » OU « Statut n'est pas Résolu ». Une action typique consiste ensuite à activer l'envoi des rappels automatiques de SLA. {% hint style="info" icon="vial" %} Exemple : deux jours avant l'échéance du TTR, si le ticket n'est ni fermé ni résolu, un rappel automatique est envoyé pour signaler que le délai de résolution approche. {% endhint %} Cette même mécanique de niveaux d'escalade se répète à l'identique pour les OLA. {% endstep %} {% endstepper %} *** ## Configurer les destinataires des rappels Les rappels s'appuient sur la notification **`Ticket Recall`** et son modèle associé. Par défaut, les destinataires de cette notification sont vides ; il est donc nécessaire de les configurer pour que les personnes concernées reçoivent effectivement les alertes SLA. Pour cela : * Aller dans **`Configuration`** > **`Notifications`** > **`Notifications`** * Rechercher la notification **`Ticket Recall`** * Dans l'onglet **Destinataires**, sélectionner les cibles souhaitées (profil, groupe, groupe du ticket, demandeur, administrateur de l'entité, etc.) * Il est également possible de configurer des exclusions de destinataires * Cliquez sur **`Modifier`**. *** ## Activer l'action automatique et vérifier le cron L'action automatique nommée **`slaticket`** doit être activée depuis **`Configuration`** > **`Actions automatiques`** : elle doit être planifiée, exécutée en mode CLI, avec une fréquence minimale de 5 minutes.

Configuration action automatique slaticket

Pour les instances on-premise, il faut également **s**'**assurer que la tâche cron du serveur est correctement configurée**, faute de quoi les actions automatiques ne s'exécuteront pas, même si elles apparaissent correctement paramétrées dans l'interface. Voir la configuration du cron GLPI *** ## Synthèse Pour déployer une gestion des niveaux de service complète dans GLPI, l'ordre logique est le suivant : 1. **Calendriers** : définir les plages horaires (heures ouvrées, astreinte, jours fériés). 2. **SLA** : créer les niveaux de service contractuels (TTO / TTR) par type d'engagement client. 3. **OLA** : créer les niveaux de service internes, éventuellement en cascade (niveau 1 → niveau 2). 4. **Règles métier** : automatiser l'affectation des SLA/OLA selon catégorie, entité, priorité, etc. 5. **Niveaux d'escalade** : programmer les actions avant/après échéance (réaffectation, changement de priorité, rappel). 6. **Notifications** : renseigner les destinataires du modèle « Rappel ticket ». 7. **Action automatique `slaticket`** : vérifier qu'elle est planifiée en CLI, toutes les 5 minutes maximum. 8. **Cron** : contrôler que la tâche planifiée du serveur s'exécute bien (instances on-premise). *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.glpi-project.org/glpi-12/fr/setup/service-levels.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.