GUIDE TECHNIQUE · SERVICENOW
ServiceNow : ITSM : qualifier et résoudre un incident
Structurer le traitement d'un incident ServiceNow ITSM : qualification, impact et urgence, groupe d'affectation, SLA et clôture documentée. La procédure utilise des enregistrements de recette fictifs.
L’ESSENTIEL EN BREF
Les étapes clés
Ce guide présente 4 étapes, de « Créer un incident de laboratoire » à « Résoudre et vérifier avant clôture ».
Avant de commencer : Instance de développement ou test avec droits de création d'incident.
01 · CADRAGE
Périmètre et résultat visé
Résultat attendu : Impact, urgence et priorité concordent avec la matrice de l'instance.
Public concerné : Service desk, support N1/N2, incident managers et administrateurs ITSM
ServiceNow ITSM selon la release et la configuration de l'instance ; formulaires, tables et matrice de priorité peuvent être personnalisés.
Contrôlez les versions, les droits et les options disponibles dans votre environnement avant de suivre la procédure.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Instance de développement ou test avec droits de création d'incident.
- Matrice locale impact x urgence, groupes support et SLA documentés.
- Scénario de recette avec application fictive et aucune donnée d'utilisateur réel.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Suivez les étapes dans l’ordre et contrôlez chaque résultat avant de poursuivre. Renseignez les paramètres adaptés à votre environnement.
ÉTAPE 1 / 4
Créer un incident de laboratoire
Un dossier bien qualifié limite les réaffectations.
- Ouvrir Incident > Create New dans le parcours de votre instance.
- Renseigner un titre descriptif, le service impacté et une description reproductible.
# Exemple de titre non sensible :
Accès impossible au portail de recette depuis un compte de testÀ vérifier : Le ticket contient un symptôme, une portée et les premiers constats.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 2 / 4
Évaluer impact, urgence et priorité
La priorité doit traduire la gravité métier plutôt qu'une impression subjective.
- Choisir impact et urgence selon la matrice validée par l'organisation.
- Comparer la priorité calculée à la situation et expliquer toute exception autorisée.
# Fiche de recette :
# Impact : 2
# Urgence : 2
# Priorité : calculée selon matrice localeÀ vérifier : La priorité correspond à la règle de l'instance.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 3 / 4
Affecter le bon groupe
Le routage dépend des compétences et des services pris en charge.
- Associer une catégorie et un Assignment group correspondant au service fictif.
- Ajouter dans Work notes les vérifications utiles pour le support suivant.
# Exemple de Work notes :
Reproduction sur recette ; connectivité HTTPS vérifiée ; investigation applicative attendue.À vérifier : Le groupe support peut reprendre l'incident sans demander les constats initiaux.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 4 / 4
Résoudre et vérifier avant clôture
Un ticket résolu ne prouve pas la restauration sans vérification métier.
- Documenter cause observée, action corrective et résultat de recette.
- Faire confirmer le rétablissement puis appliquer le code et les règles de résolution de l'instance.
# Compte rendu attendu :
Symptôme -> diagnostic -> action -> preuve de rétablissementÀ vérifier : L'incident suit les états prévus et conserve une trace exploitable.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
RÉFÉRENCES TECHNIQUES
Documentation officielle
Retrouvez les prérequis, les fonctionnalités et les versions prises en charge par ServiceNow. Vérifiez les commandes sur un environnement de test avant leur utilisation en production.
05 · RECETTE
Comment vérifier que tout fonctionne ?
Impact, urgence et priorité concordent avec la matrice de l'instance.
L'affectation et les transitions sont traçables.
La résolution contient une preuve de rétablissement et respecte les règles SLA.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
Priorité inattendue
Cause probable : Matrice locale ou Business Rule particulière
Que faire : Vérifier la configuration de priorité et les règles d'exception.
Assignment group vide
Cause probable : Catégorie ou routage mal configuré
Que faire : Contrôler le service et les règles d'affectation.
SLA absent
Cause probable : Conditions d'application non remplies
Que faire : Examiner SLA Definitions et les conditions de démarrage/arrêt.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Priorité et SLA, est-ce la même chose ?
Non. La priorité classe l'incident ; les SLA définissent des objectifs mesurables selon des conditions locales.
Un incident peut-il être résolu sans être fermé ?
Oui : selon le modèle de gestion, un état résolu précède souvent la clôture.
Qui valide la résolution ?
L'organisation définit le responsable et les modalités de validation utilisateur ou métier.
AUTRES TECHNOLOGIES
Guides complémentaires
VOTRE ENVIRONNEMENT
Besoin d’aller plus loin sur votre environnement ?
Automatisation, sécurité et exploitation : échangeons sur vos pratiques ServiceNow.
Échanger avec ADN Consulting