# Cycle de vie d'un ticket

Le cycle de vie des tickets est défini au niveau du *profil* dans une [matrice de cycle de vie](/documentation/fr/modules/administration/profiles/lifecyclematrix.md). Pour afficher un cycle de vie et le modifier, cela se fait donc dans le formulaire de gestion des profils (menu **Administration > Profils**).

***

## Types de tickets

Les tickets GLPI sont soit des incidents, soit des demandes, ce type étant stocké dans le champ *Type* du ticket. Ce champ de type permet d'effectuer des actions basées sur le type de ticket (voir [règles métier pour la modification et l'assignation des tickets](/documentation/fr/modules/administration/rules/ticketbusinessrules.md), [modèles de tickets](https://github.com/glpi-network/gitbook-fr/blob/main/manual/modules/configuration/notifications/templates.md) et [gestion des problèmes](/documentation/fr/modules/assistance/problems.md)) et de personnaliser la liste des catégories disponibles.

***

## Statuts

L'ITIL définit un standard pour le cycle de vie des statuts de tickets. Ce cycle de vie des statuts est implémenté dans GLPI en définissant les statuts suivants :

* Nouveau
* Approbation
* Traitement (assigné)
* Traitement (planifié)
* En attente
* Résolu
* Fermé

Ces statuts ne peuvent être ni paramétrés ni modifiés.

{% hint style="info" %}
Il est donc possible de masquer certains statuts en fonction du profil (voir [Matrice de cycle de vie](/documentation/fr/modules/administration/profiles/lifecyclematrix.md)).
{% endhint %}

Pour aller plus loin dans la gestion des statuts, référez-vous aux [modèles de tickets](https://github.com/glpi-network/gitbook-fr/blob/main/manual/modules/configuration/notifications/templates.md) et aux [règles métier pour la modification et l'assignation des tickets](/documentation/fr/modules/administration/rules/ticketbusinessrules.md).

***

## Planification

La planification des tickets se fait en fonction des données fournies par le demandeur et le technicien :

* Le demandeur définit l'urgence
* Le technicien apprécie l'impact

La priorité résulte de ces deux valeurs. Elle est calculée automatiquement à l'aide d'une matrice et fournit la véritable importance du ticket.

{% hint style="info" %}
Pour aller plus loin sur la configuration de cette matrice, voir [Définir la matrice de calcul de la priorité](/documentation/fr/modules/assistance/prioritymatrix.md).
{% endhint %}

***

## Règles de gestion

Le statut du ticket suit le processus suivant :

* Lors de la création, le ticket a le statut **Nouveau ;**
* Lorsqu'un technicien assigne le traitement du ticket à un groupe, un technicien ou un fournisseur, le ticket passe au statut **Traitement (assigné) ;**
* Lorsqu'une nouvelle tâche est ajoutée au ticket et qu'elle est planifiée, le statut du ticket devient alors **Traitement (planifié) ;**
* Lorsqu'une solution est trouvée pour le ticket, son statut devient **Résolu ;**
* Enfin, lorsque le demandeur ou le rédacteur valide la solution proposée, le statut du ticket est **Fermé ;**

{% hint style="info" %}

* Le technicien peut changer le statut du ticket à tout moment, notamment pour mettre le ticket en **En attente** (il est aussi possible de configurer les [raisons de mise en attente](/documentation/fr/modules/assistance/tabs/pending-reason.md)). Conformément aux recommandations ITIL, un ticket ne doit être mis en **En attente** que par le demandeur, par exemple si la demande est incomplète ou si le demandeur n'est pas disponible pour une intervention.
* Le demandeur peut supprimer le ticket tant que le statut du ticket est **Nouveau** et qu'aucune action n'a été effectuée sur le ticket.
  {% endhint %}


---

# Agent Instructions: 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:

```
GET https://help.glpi-project.org/documentation/fr/modules/assistance/tickets/ticketlifecycle.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
