--- sourceDocument: Gestion des services IT Australie sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/it-service-management Release : - australia ft:locale : - fr-FR ft:publication_title : - Gestion des services IT Australie ft:clusterId : - itsm bundleId : - itsm workflow : - Technology --- # legacy: modèle d'état et transitions # legacy: modèle d'état et transitions {#ariaid-title1} * Rversion finale: Australia * * Mis à jour 12 mars 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes de lecture Gestion des changements fournit un modèle d'état pour déplacer et suivre les demandes de changement selon différents états. Remarque : La fonctionnalité des états de changement a été remplacée par des modèles de changement depuis la Quebec publication. Pour plus d'informations, consultez [Créer un modèle de changement](https://servicenow-prod.fluidtopics.net/1vUDX2wePusop9UbW~NUMQ "Créez des modèles de changement pour configurer les états et les transitions en fonction des processus de changement de votre organisation."). Figure 1. Exemple de transitions d'états pour une demande de changement normal La table suivante fournit une liste de tous les états par lesquels une demande de changement peut passer. Des notifications par e-mail peuvent être envoyées à l'utilisateur à l'origine de la demande de changement lorsqu'elle passe aux états suivants : Planifié, Implémenter, Revue et Annulé. {#c_ChangeStateModel__table_stq_kft_zs__entry__3} | État | Description | Valeur d'état | |-|-|-| | Nouveau | La demande de changement n'est pas encore envoyée à des fins de revue et d'autorisation. Un demandeur de changement peut enregistrer une demande de changement autant de fois que nécessaire tout en peaufinant les détails du changement avant son envoi. | -5 | | Évaluer | L'examen par les pairs et l'approbation technique des détails du changement sont effectués au cours de cet état. | -4 | | Autoriser | Gestion des changements et le CAB planifient le changement et fournissent l'autorisation finale pour continuer. | -3 | | Planifié | Une fois entièrement planifié et autorisé, le changement attend la date de début planifiée. Une notification par e-mail est envoyée à l'utilisateur qui a demandé le changement. | -2 | | Implémenter | La date de début planifiée approche et les tâches réelles d'implémentation du changement sont en cours. Une notification par e-mail est envoyée à l'utilisateur qui a demandé le changement. | -1 | | Examen | Les tâches sont terminées. Le demandeur de changement détermine si le changement est correctement implémenté. Une revue post-implémentation peut être effectuée au cours de cet état. Une notification par e-mail est envoyée à l'utilisateur qui a demandé le changement. Remarque : vous ne pouvez pas annuler la demande de changement une fois dans l'état Revue. | 0 | | Fermé | Toutes les tâches de revue sont terminées. Le changement est fermé sans autre action requise. | 3 | | Annulé | Un changement peut être annulé à tout moment s'il n'est plus nécessaire. Toutefois, un changement ne peut pas être annulé une fois dans l'état Fermé. Une notification par e-mail est envoyée à l'utilisateur qui a demandé le changement. | 4 | [Tableau 1. États des changements] {#c_ChangeStateModel__table_stq_kft_zs} Les changements normaux, standard et urgents passent par des états de différentes manières. ## Progression de l'état pour différents changements {#c_ChangeStateModel__section_agv_5dv_fdb} * Les changements normaux passent par tous les états. * Les changements standard sont considérés comme pré-autorisés, ils contournent donc les états Évaluer et Autoriser qui déclenchent des enregistrements d'approbation. L'approbation de ces changements les fait avancer vers l'état approprié suivant. Le rejet de ces changements les renvoie vers l'état Nouveau. * Les changements urgents sont semblables aux changements standard, hormis le fait qu'ils doivent être autorisés. {#c_ChangeStateModel__ul_fgx_cdv_fdb} ## Rétablissement de l'état Nouveau pour une demande de changement {#c_ChangeStateModel__section_tms_xdv_fdb} Gestion des changements permet de rétablir l'état Nouveau pour les types de changement Urgence et Normal, qui est le premier état d'approbation, à l'aide de l'action Revenir à Nouveau dans le menu contextuel. Cette action est effectuée si l'approbation a été demandée et que l'émetteur reconnaît que tous les éléments de configuration concernés par le changement n'ont pas été inclus avant l'envoi pour approbation. * Pour rétablir l'état de la demande de changement Normal sur Nouveau, remplacez l'état d'une demande de changement Évaluer par Nouveau en cliquant sur Revenir à Nouveau dans le menu contextuel. * Pour rétablir l'état de demande de changement Urgent sur Nouveau, remplacez l'état d'une demande de changement Autorisé par Nouveau en cliquant sur Revenir à Nouveau à partir du menu Contexte. Remarque : lorsque vous revenez à l'état Nouveau à partir de l'état Évaluer ou Autorisé, le workflow est redémarré et toutes les approbations en attente sont annulées. {#c_ChangeStateModel__ul_ulc_12v_fdb} ## Modifier le type de demande de changement {#c_ChangeStateModel__section_vmn_22v_fdb} * Une nouvelle ACL pour change_request.type a été ajoutée et permet la modification du champ Type dans la demande de changement lorsqu'elle se trouve dans l'état Nouveau et qu'aucune approbation n'a encore été générée pour elle. * Dans le cas d'une demande de changement Standard, vous pouvez modifier son type de Standard à Normal ou Urgence, si son état est Nouveau. * Dans le cas d'une demande de changement Normal ou Urgence, vous pouvez modifier son type de Normal à Urgence et inversement, si son état est Nouveau. * Si une demande de changement Normal ou Urgence est rejetée, l'état de la demande de changement est défini sur Nouveau. Comme l'état de la demande de changement est Nouveau, vous pouvez modifier à nouveau le type de demande de changement. Par exemple, si votre demande de changement Urgence est rejetée au motif qu'elle est de type Normal, vous pouvez remplacer le Type de la demande de changement par Normal et renvoyer la demande de changement. {#c_ChangeStateModel__ul_l5x_f2v_fdb} ## Action Annuler le changement désactivée {#c_ChangeStateModel__section_s53_b21_1gb} L'option Annuler d'une demande de changement dans l'état Revue est désactivée. Cela empêche d'annuler la demande lorsque les tâches sont terminées et en attente d'examen. ## Attributs du modèle de changement {#c_ChangeStateModel__section_y1v_yy3_fdc} Le gestionnaire des changements a la possibilité d'imposer des actions spécifiques lorsqu'une demande de changement passe à un état spécifique. Les attributs affectés à cet état déterminent les actions qui peuvent avoir lieu. Par défaut, il existe deux attributs pour gérer une demande de changement : * allow_ci_modification : permet de modifier le CI. Les attributs ne sont pris en compte que s'ils sont inclus dans un modèle. Si l'attribut `allow_ci_modification` n'est pas ajouté à un modèle, il revient par défaut à son état initial. * allow_implementation : indique que le changement sera implémenté. En activant `allow_implementation`, cette fonctionnalité remplace le champ États d'implémentation actuellement présent dans le modèle de changement. Les états répertoriés dans le champ États d'implémentation et l'attribut seront respectés. {#c_ChangeStateModel__ul_mlv_bz3_fdc} * **[legacy: ajouter un état au modèle d'état](https://servicenow-prod.fluidtopics.net/Vy0sguUz3XPOrx08deZYKA#t_AddANewState)** Vous pouvez ajouter un nouvel état au modèle d'état existant pour différents types de changement en fonction des exigences de votre organisation. * **[legacy: configurer les transitions de modèle d'état](https://servicenow-prod.fluidtopics.net/GgMz2R75mwwaJm4REtT1eA)** Vous pouvez utiliser des scripts includes ou des politiques d'interface utilisateur pour configurer des modèles d'état et des critères de passage des demandes de changement d'un état à l'autre.