Un guide de conception pour la gestion des alarmes

Les alarmes concernent des actions, pas seulement des signaux. Concevoir pour la sécurité signifie concevoir le cycle de vie complet des alarmes. Le but n’est pas la prise de conscience, c’est la réponse.

La vérité alarmante

Lorsque les systèmes deviennent complexes, la sécurité devient un défi. Les alarmes sont des garde-fous qui aident à prévenir les catastrophes. Pourtant, un logiciel mal conçu crée une réalité alarmante.

Les catastrophes surviennent rarement en raison d’un manque d’alarmes. Cela arrive parce qu’il y en a trop.

Dans les salles de contrôle, les alarmes sont partout. Et c’est peut-être là le problème. Les alarmes se déclenchent si souvent que les utilisateurs ne les remarquent plus. Ils coupent le son juste pour passer le changement. Et lorsqu’ils remarquent une alarme, celle-ci est souvent non essentielle, voire faussement positive.

Quand tout semble urgent, rien ne l’est. Lorsque les alarmes se déclenchent constamment, les gens ne répondent plus.

Nous aimons penser qu’avoir des alarmes est synonyme de sécurité. Nous surestimons. Méfiance. Et une mauvaise conception des alarmes entraîne fatigue, surcharge et inactivité.

Concevoir des alarmes signifie concevoir pour l’humain dans la boucle. Car lorsque l’alarme se déclenche, ce n’est pas le capteur qui résout le problème. C’est la personne responsable à l’intérieur du système.

Clarté de la classification

Si vous voulez des alarmes auxquelles les gens peuvent faire confiance, vous avez besoin d’alarmes que les gens peuvent comprendre. Cela commence par une classification claire et cohérente des alarmes.

Une alarme n’est pas seulement une prise de conscience. C’est un signal que quelque chose nécessite une attention particulière.

Mais les systèmes deviennent de plus en plus complexes. Le personnel est réduit. La charge de travail a augmenté. Ce contexte cognitif exige une communication claire comme du cristal. Des alarmes avec la bonne priorité et la fiabilité attendue.

Vous avez besoin d’un système de classification commun sur l’ensemble de votre plateforme, qui couvre le code, l’interface utilisateur, les processus et les personnes.

Cela signifie s’aligner sur deux dimensions clés : priorité et fiabilité.

Priorité

La priorité vous indique sur quoi vous concentrer, sur ce qui requiert vraiment votre attention.
Cela reflète une combinaison d’urgence et de gravité.

• Urgence c’est le temps dont vous disposez. Agissez-vous maintenant ou disposez-vous d’un tampon ?
• Gravité est la conséquence. Que se passe-t-il si vous manquez cela ?

Fiabilité

La fiabilité vous indique si l’alarme est fiable. Cela dépend de deux facteurs : probabilité × précision.

• Probabilité c’est faire confiance à l’événement. Est-ce que cela est susceptible d’arriver ?
• Précision il s’agit de faire confiance à la source. Les données sont-elles fiables ?

Une classification cohérente crée de la clarté.

J’ai vu des systèmes utilisés par le même opérateur. L’un utilisait une priorité faible, moyenne et élevée avec un code couleur vert, jaune et rouge. Un autre a utilisé lo-lo, lo, mid, hi, hi-hi. Un tiers a utilisé des traitements normaux, critiques et urgents. Ce type d’incohérence rend difficile le jugement des opérateurs.

Mais l’étiquetage d’une alarme n’est qu’un début. Le véritable défi est ce qui se passera ensuite. Quelle est la prochaine étape du cycle de vie des alarmes ?

Le cycle de vie des alarmes

Les alarmes ne sont pas de simples messages d’événements. Ils font partie d’une boucle. Vous voulez que les utilisateurs répondent. Pour résoudre un problème ou prévenir une catastrophe.

C’est le travail du cycle de vie des alarmes: un système continu qui aide les équipes à gérer les risques.

J’utilise un modèle simple pour décrire cela : le triangle du cycle de vie des alarmes

Gérer → Surveiller → Événement → Déclencheur → Notifier → Répondre → Gérer

Lorsque vous concevez un système, vous facilitez ce cycle de vie grâce aux interfaces utilisateur. Vous pouvez exploiter les composants d’interface utilisateur existants pour concevoir chaque étape avec une meilleure expérience.

Gérer

C’est votre début et votre fin. Avant qu’une alarme ne se déclenche, quelqu’un doit la définir. Qu’est-ce qui le déclenche ? À qui appartient-il ? Comment cela devrait-il dégénérer ?

Vous avez besoin d’alarmes dans un aperçu, une liste ou un tableau de bord. Un endroit où les équipes configurent, contrôlent et stockent les alarmes.

Composants communs :
Grille de données, liste, carte, formulaire.

Moniteur

Il s’agit de l’activité entre Gérer et Événement. La surveillance signifie observer les données, les modèles, les signaux. Jusqu’à ce que quelque chose arrive, vous anticipez ce qui pourrait arriver.

Composants communs :
Graphique, chronologie, jauge, liste.

Événement

C’est le moment de vérité. Une condition est remplie. Une règle est enfreinte. Ou bien un système prévoit que quelque chose va se produire.

Vous pouvez voir ces événements se dérouler à travers des visuels. Remarquer des anomalies, des pics ou des baisses dans les données.

Composants communs :
Graphique, jauge, diagramme.

Déclenchement

C’est là que la logique se transforme en action. Le système prend une décision : sonner l’alarme.

Les déclencheurs doivent être clairement définis. Pas seulement ce qui s’est passé, mais ce qui compte suffisamment pour être notifié. Une bonne conception du déclencheur évite les faux positifs et les seuils mal placés.

Composants communs :
Popup, badge, lignes de style conditionnel.

Notifier

C’est le transfert. L’alarme passe du système à l’utilisateur.

Mais comment ? À qui ? Par quel canal ? C’est là que l’UX compte le plus. Les alarmes doivent parvenir à la bonne personne, dans le bon contexte et au bon moment.

Composants communs :
Alerte, badge, toast, modal, panneau de notification, chatbot.

Répondre

C’est le moment d’agir. L’utilisateur voit l’alarme. Et maintenant ? Reconnaître. Intensifier. Ou réparer ? Peut-être même le rejeter ou le répéter.

Vous ne concevez pas uniquement pour la réaction. Vous concevez pour la décision.

Composants communs :
Bouton, liste déroulante, puce.

Alarme, alerte ou action ?

Une idée fausse très répandue est que les alarmes et les alertes sont identiques. Mais les alertes ne sont qu’un type de notification parmi d’autres, utilisé par les alarmes.

Une alerte vous indique que quelque chose s’est produit. Une alarme vous demande de faire quelque chose. Que action c’est ce qui compte réellement.

Trop de systèmes s’arrêtent à la notification. Ils lancent des popups et des badges et c’est fini. Mais si l’on veut une réelle sécurité, il faut aller plus loin.

Vous devez concevoir différents types de réponses :

• Passif – «Je l’ai vu.»
• Réactif – «Je vais agir maintenant.»
• Proactif – «Je vais l’empêcher.»

Si vous voulez que les gens agissent, vous devez concevoir en conséquence, avec une classification appropriée et un cycle de vie bien géré.

De hors de contrôle à sous contrôle.