# Gestion des incidents

> Suivre les incidents d’un projet EMS Voltmasters : la liste avec ses onglets et ses filtres, et ce que chaque entrée dit sur l’appareil et le type.

Source: https://voltmasters.io/fr/docs/voltmasters-platform/incident-management/

### Aperçu des incidents

La page **Incidents** liste tous les incidents actifs et passés du projet. Chaque entrée montre le projet, l’appareil, le type d’incident et une description. Utilisez les filtres pour vous concentrer sur ce qui n’est pas résolu ou pour parcourir l’historique.

Les incidents propres à un projet sont aussi accessibles via l’onglet **Incidents** à l’intérieur d’un projet.

### Les onglets

La liste des incidents est répartie en trois onglets :

| Onglet | Ce qu’il montre |
| --- | --- |
| **Incidents ouverts** | Tout ce qui n’est pas encore résolu. C’est la vue de travail. |
| **Tous** | Les incidents ouverts et clôturés, hors incidents masqués. |
| **Masqué** | Uniquement les incidents d’un type masqué, pour qu’un type mis en sourdine reste consultable. |

### Mettre un type d’incident en sourdine

Certaines alarmes sont correctes mais sans utilité sur une installation donnée : un appareil sciemment hors ligne, une limitation attendue sur ce site, un avertissement sur du matériel qui sera remplacé la semaine prochaine. Plutôt que de vivre avec une liste durablement rouge, vous pouvez **mettre le type d’incident en sourdine**.

La mise en sourdine fonctionne **par type**, pas par incident. Depuis un incident de la liste, utilisez l’action de mise en sourdine et choisissez la portée :

| Portée | Effet |
| --- | --- |
| **Ignorer pour l’appareil** | Seul cet appareil cesse de générer ce type d’incident. Les autres continuent. |
| **Ignorer pour le projet** | Plus aucun appareil du projet ne génère ce type d’incident. |

La portée par appareil est celle à utiliser par défaut ; la portée projet est réservée à un type réellement sans intérêt pour toute l’installation.

**Ce que la mise en sourdine fait et ne fait pas :**

-   Les incidents d’un type masqué sont **toujours enregistrés**. Ils passent dans l’onglet **Masqué** au lieu de la liste ouverte : rien n’est perdu et vous pouvez toujours voir ce qui s’est passé.
-   Les incidents masqués **n’envoient plus** de notification par e-mail ni de notification push.
-   La mise en sourdine est **réversible**, à la portée où elle a été appliquée : la lever pour l’appareil, ou pour le projet.
-   La colonne **Mis en sourdine par** montre qui a masqué le type, de sorte qu’une alarme silencieuse peut toujours être remontée à la personne qui l’a silencée et la décision réexaminée.

Un type peut aussi être masqué pour un appareil **supprimé**, ce qui compte quand un appareil retiré continue de faire du bruit en partant.

> **Avertissement**
>
> La mise en sourdine cache un symptôme, elle ne corrige pas une cause. Utilisez-la pour une situation connue et acceptée, et privilégiez la portée par appareil pour que la même alarme ailleurs dans l’installation vous parvienne encore. Repassez de temps en temps dans l’onglet Masqué : une mise en sourdine prévue pour une semaine a vite fait de durer un an.

### Gravité

Chaque incident a une gravité : **Info**, **Avertissement** ou **Critique**. Les notifications sont volontairement limitées : les notifications par **e-mail** comme les **notifications push** ne sont envoyées que pour les incidents **Critique**, pour que ces canaux gardent leur sens et ne se remplissent pas de bruit informatif. Les incidents de toutes les gravités restent visibles dans la liste. Certains incidents liés au contrôleur et au réseau sont traités comme des **notifications d’urgence** et remontent immédiatement.

### Questions fréquentes

**Quels incidents déclenchent une notification ?**

Presque tous les incidents apparaissent dans votre liste, y compris les défauts, les avertissements et les alertes informatives concernant les appareils, le contrôleur EMS et les limites réseau.

Les **notifications par e-mail** sont groupées et envoyées uniquement pour les incidents **Critique** :

-   Un premier e-mail part dès que l’incident est ouvert depuis **au moins cinq minutes** (pas encore résolu et pas déjà repris dans un envoi groupé).
-   Un e-mail de suivi peut partir environ **douze heures** après le début de l’incident, s’il est encore ouvert à ce moment-là.

Les **notifications push** sont elles aussi limitées aux incidents **Critique**. Une notification push est retirée automatiquement dès que l’incident qu’elle annonçait est résolu.

Les incidents de gravité *Info* et *Avertissement* sont enregistrés et affichés dans la liste, mais ne génèrent ni e-mail ni notification push.

**Combien de temps avant qu’une notification parte ?**

| Canal de notification | Moment |
| --- | --- |
| E-mail (incidents Critique) | Après que l’incident est ouvert depuis au moins 5 minutes |
| E-mail de suivi | Environ 12 heures après le début de l’incident, s’il n’est toujours pas résolu |
| Push (Critique uniquement) | Envoyée à l’ouverture de l’incident, retirée à sa résolution |

**Comment configurer les destinataires des notifications ?**

Sous **Paramètres → Règles d’incidents**, vous choisissez quels utilisateurs reçoivent les notifications pour ce projet.

1.  Allez dans **Paramètres → Règles d’incidents**.
2.  Vous voyez la liste des utilisateurs liés au projet.
3.  Mettez l’interrupteur à côté du nom d’un utilisateur sur **activé** pour lui envoyer les notifications par e-mail et dans le portail.
4.  Mettez-le sur **désactivé** pour cesser de lui en envoyer.

Cette configuration est propre au projet ; les modifications faites ici ne concernent que les notifications du projet en cours.

![Voltmasters EMS : règles d’incidents](https://voltmasters.io/assets/docs/image-78.webp)

*Voltmasters EMS : gestion des incidents*