La gestion des incidents rétablit le service normal le plus vite possible quand quelque chose tombe en panne, et tient les utilisateurs informés pendant ce temps. Cette page explique le processus de gestion des incidents ITIL 4, la matrice de priorité, les SLA et les KPI, et comment SMC Consulting le paramètre dans HaloITSM ou dans l'outil que vous utilisez déjà.
La gestion des incidents est la pratique ITIL 4 qui réduit l'impact négatif des incidents en rétablissant le fonctionnement normal du service le plus rapidement possible. Un incident est une interruption imprévue d'un service, ou une baisse de sa qualité : le VPN refuse les connexions, une application est lente, les imprimantes d'un étage ne répondent plus. L'objectif est de remettre les utilisateurs au travail, pas encore de comprendre pourquoi c'est arrivé.
C'est ce dernier point qui distingue les incidents des pratiques voisines :
| Ce que c'est | Objectif | |
|---|---|---|
| Incident | Une interruption ou dégradation imprévue d'un service | Rétablir le service vite |
| Problème | La cause sous-jacente d'un ou plusieurs incidents | Trouver et supprimer la cause racine |
| Demande de service | Une demande planifiée : accès, matériel, information | La traiter via le catalogue |
| Incident majeur | Un incident à fort impact métier | Rétablir le service avec une procédure dédiée |
Mélanger incidents et demandes dans une même file ralentit les deux ; voir la gestion des demandes pour le volet demandes. La gestion des incidents est l'un des processus ITSM essentiels.
Relu par les consultants certifiés ITIL v4 de SMC Consulting. Source : la pratique Incident Management d'ITIL 4, ITIL 4 (PeopleCert).
Six étapes, du premier signal au dossier clôturé. Chacune est paramétrée dans l'outil selon votre modèle opérationnel, pas laissée en configuration par défaut.
Quand la correction exige une modification en production, elle sort de la gestion des incidents et suit la gestion des changements.
L'incident arrive par le portail, l'e-mail, Teams, un appel ou une alerte de supervision, et il est enregistré avec sa source, l'heure et les champs standard.
La catégorie suit votre catalogue de services ; la priorité découle de la matrice impact × urgence et fixe les objectifs SLA.
Le niveau 1 consulte la base de connaissances et les erreurs connues, résout ce qu'il peut et affecte le reste au bon groupe de résolution.
Les spécialistes analysent avec la CMDB et l'historique des incidents ; l'escalade se déclenche avant le dépassement du SLA.
La correction ou le contournement est appliqué, l'utilisateur confirme le retour du service, et le code et les notes de résolution sont enregistrés.
Le dossier est clôturé avec des données propres ; les incidents récurrents et majeurs passent à la gestion des problèmes et alimentent la revue suivante.
La priorité n'est pas une impression. Elle découle de deux questions : combien de personnes ou quelle part de l'activité sont touchées (l'impact), et à quelle vitesse le dommage augmente (l'urgence). En les croisant, on obtient une priorité que chaque agent applique de la même façon.
| Impact \ Urgence | Haute | Moyenne | Basse |
|---|---|---|---|
| Haut (un service ou un site à l'arrêt) | P1 Critique | P2 Haute | P3 Moyenne |
| Moyen (une équipe ou un département) | P2 Haute | P3 Moyenne | P4 Basse |
| Faible (un utilisateur, un contournement existe) | P3 Moyenne | P4 Basse | P5 Planifiée |
Chaque priorité porte ensuite un objectif de prise en charge et de résolution. Les valeurs dépendent de vos services, de vos horaires et de vos contrats : nous les fixons avec vous au lieu de recopier un modèle. Deux règles les rendent efficaces : le chronomètre SLA démarre à l'enregistrement de l'incident, et l'escalade se déclenche avant le dépassement (par exemple à 75 % du temps écoulé), quand il est encore temps d'agir. L'escalade fonctionnelle transfère le ticket à une équipe plus spécialisée ; l'escalade hiérarchique prévient un responsable quand une décision ou des moyens supplémentaires sont nécessaires.
Des critères clairs pour déclarer un incident majeur, un responsable désigné, une équipe dédiée et un circuit de décision raccourci. Mieux vaut déclarer tôt qu'escalader tard.
Utilisateurs et direction reçoivent des points d'étape à intervalles convenus, via le portail, Teams ou l'e-mail, pour que le service desk ne croule pas sous les « du nouveau ? ».
Une fois le service rétabli, les incidents récurrents ou majeurs deviennent des problèmes : cause racine, erreur connue, contournement, correction définitive.
La correction définitive est un changement : évalué, approuvé et planifié, pour que le remède ne cause pas le prochain incident.
Nous travaillons en quatre phases : concevoir le modèle opérationnel, paramétrer l'outil, ajouter connaissance, IA et automatisation, puis former et transférer. HaloITSM est notre choix pour la plupart des organisations de taille moyenne, mais le processus fonctionne sur chacune des 10 plateformes ITSM où nous intervenons : nous paramétrons le même modèle dans l'outil que vous avez déjà.
E-mail, portail libre-service, Microsoft Teams, API et alertes de supervision, avec des formulaires standard et des champs obligatoires pour un premier enregistrement exploitable.
Des catégories alignées sur vos services, et un routage par catégorie, service touché et utilisateur, pour que le ticket arrive du premier coup au bon groupe de résolution.
Des objectifs de prise en charge et de résolution par priorité, des alertes avant le dépassement et des chemins d'escalade convenus avec chaque équipe.
Des articles pertinents suggérés aux agents pendant l'analyse et aux utilisateurs à la saisie, et une invitation à mettre la base à jour à la clôture.
Des incidents liés aux éléments de configuration et aux services, pour que les agents voient ce qui est touché et que la gestion des problèmes repère les tendances.
Création de tickets, suivi et approbations dans Teams, et liens avec Jira, Azure DevOps et PagerDuty quand des équipes de développement ou d'astreinte sont impliquées.
Beaucoup d'incidents arrivent encore par téléphone, souvent hors des heures de bureau. AurionAI, un helpdesk IA pour le support IT édité par notre partenaire AurionAI SRL, répond 24/7 aux appels, chats et e-mails, vérifie l'appelant, et résout la demande ou crée le ticket d'incident dans votre ITSM avec sa catégorie et sa priorité. Les agents partent d'un ticket complet plutôt que d'un message vocal.
Lors d'un audit gratuit de 30 minutes, un consultant senior passe en revue avec vous votre processus d'incidents, vos priorités et vos SLA, et vous repartez avec vos trois priorités.
Quand le backlog ne cesse de grossir, la solution se trouve en général dans le tri, la conception des SLA et la connaissance, pas dans un nouvel outil.
Les demandes d'accès, de matériel et d'information ont leur place dans le catalogue de services, avec leurs propres formulaires et approbations.
Qui portent la file, les SLA et les escalades au quotidien et ont besoin d'un processus que toute l'équipe applique.
Qui veulent moins d'interruptions, un rétablissement plus rapide et des chiffres à présenter aux métiers.
Qui veulent un cycle de vie, des priorités et des passages de relais que les équipes suivent vraiment.
| KPI | Ce qu'il vous dit |
|---|---|
| Délai moyen de résolution (MTTR) | Le temps moyen entre l'enregistrement et la résolution, par priorité. |
| Résolution au premier contact (FCR) | La part d'incidents résolus au premier contact, sans escalade. |
| Respect des SLA | La part d'incidents résolus dans les délais, et l'écart pour les autres. |
| Taux de réouverture | Les incidents rouverts après résolution : un signal direct de la qualité des corrections. |
| Âge du backlog | Depuis combien de temps les incidents ouverts attendent ; les plus anciens montrent où le processus coince. |
Définitions, formules et objectifs : voir notre guide des KPI ITSM.
L'incident est l'interruption elle-même : un service est arrêté ou dégradé et les utilisateurs en ont besoin. Le problème est la cause derrière un ou plusieurs incidents. La gestion des incidents rétablit le service au plus vite ; la gestion des problèmes trouve et supprime la cause pour que l'incident ne revienne pas.
Détecter et enregistrer, catégoriser et prioriser, diagnostiquer et affecter, analyser et escalader, résoudre et rétablir, clôturer et revoir. ITIL 4 n'impose pas de séquence figée, mais ces six étapes sont celles que suivent la plupart des service desks, et chacune doit être visible dans l'outil.
Avec une matrice impact × urgence. L'impact mesure la part de l'activité touchée, l'urgence la vitesse à laquelle le dommage augmente ; leur combinaison donne une priorité de P1 à P5, et chaque priorité porte ses propres objectifs SLA. La matrice doit être assez simple pour que tous les agents arrivent à la même réponse.
Le délai moyen de résolution, la résolution au premier contact, le respect des SLA, le taux de réouverture et l'âge du backlog, complétés par la satisfaction des utilisateurs. Suivez une courte liste chaque mois et agissez dessus. Notre guide des KPI ITSM donne les définitions.
Un incident dont l'impact métier est assez élevé pour justifier sa propre procédure : un responsable d'incident majeur désigné, une équipe dédiée, une communication régulière vers les utilisateurs et la direction, et une revue après coup. Les critères de déclaration se fixent à l'avance, pas pendant la panne.
Non. Le processus, la matrice de priorité et les SLA viennent d'abord, et ils fonctionnent dans n'importe quel outil ITSM. HaloITSM est notre choix quand un changement d'outil est envisagé ; sinon, nous paramétrons votre plateforme actuelle. Un audit gratuit de 30 minutes vous dit ce qui s'applique.
Réservez votre audit ITSM gratuit de 30 minutes. Un consultant senior passe en revue votre processus d'incidents, vos priorités et vos SLA, et vous repartez avec vos trois priorités.
La découverte automatisée NIS2 aide les entreprises à bâtir un inventaire d’actifs prouvable avec des données à jour sur les systèmes, propriétaires et risques.
Read more →
Le serveur MCP de ServiceNow connecte les agents IA aux workflows ITSM gouvernés et à Action Fabric pour une automatisation sécurisée. Préparez-vous pour 2026.
Read more →
Découvrez comment une intégration HaloITSM Lansweeper connecte les données de découverte à HaloITSM, pour des enregistrements CMDB plus propres, un tri plus rapide et de meilleures décisions de changement.
Read more →
