Gestion des alarmes : réduire le bruit, garder l’essentiel

Ajouter une alarme ne coûte presque rien. Un intégrateur la crée en quelques minutes, un ingénieur la demande « par précaution », un incident en fait ajouter trois. Personne, en revanche, n’est chargé de les retirer. Au bout de quelques années, les alarmes industrielles d’une salle de contrôle forment un bruit de fond que les opérateurs ont appris à acquitter sans lire. Le jour où une alarme importante survient, elle arrive noyée parmi des dizaines d’autres.

Le danger n’est pas théorique. Le rapport de l’autorité britannique de santé et de sécurité (HSE) sur l’explosion de la raffinerie de Milford Haven, en 1994, relève que les deux opérateurs en poste ont dû reconnaître et traiter 275 alarmes dans les onze minutes qui ont précédé l’explosion. Depuis, la gestion des alarmes est devenue une discipline à part entière, avec ses référentiels : le guide EEMUA 191, la norme ISA-18.2 et son équivalent international, l’IEC 62682.

Ce qu’est une bonne alarme

Les référentiels s’accordent sur une définition exigeante : une alarme signale à l’opérateur une anomalie qui demande une action de sa part, dans un délai donné. Tout le reste (une information d’état, un événement à consigner, un rappel de maintenance) relève d’autres canaux : journaux, écrans d’information, tableaux de suivi.

Cette définition fournit un test simple, applicable à chaque alarme existante. Que doit faire l’opérateur quand elle apparaît ? Combien de temps a-t-il pour le faire ? Que se passe-t-il s’il ne fait rien ? Si personne ne sait répondre à la première question, l’alarme n’en est probablement pas une.

Une bonne alarme est aussi unique (elle ne doublonne pas une autre alarme sur la même cause), pertinente dans l’état du procédé (une alarme de débit bas n’a pas de sens sur une pompe à l’arrêt) et hiérarchisée : sa priorité dépend de la gravité des conséquences et du délai disponible, non de l’importance que lui prête son auteur.

Mesurer avant de rationaliser

La tentation est de commencer par une grande revue de toutes les alarmes. C’est long et démotivant. La méthode consiste à mesurer d’abord, à partir de l’historique du système de supervision, sur quelques semaines d’exploitation représentatives.

Quatre indicateurs suffisent pour un premier diagnostic. La charge moyenne : nombre d’alarmes par opérateur et par heure, en fonctionnement normal. Les avalanches : périodes où les alarmes arrivent plus vite qu’un opérateur ne peut les traiter, typiquement plus d’une dizaine en dix minutes selon les repères des guides. Les alarmes répétitives, qui apparaissent et disparaissent plusieurs fois par minute autour d’un seuil. Les alarmes permanentes, actives depuis des jours, que plus personne ne regarde.

Le classement des alarmes les plus fréquentes révèle presque toujours le même phénomène : une poignée d’entre elles pèse une part considérable du total. Ce sont les « mauvais acteurs » de la salle de contrôle. Les traiter en premier produit une amélioration visible en quelques semaines, qui donne du crédit à la suite de la démarche.

La démarche en six temps

Les référentiels décrivent un cycle de vie complet. Ramené à l’essentiel, il tient en six temps, dont le premier est souvent sauté et le dernier oublié.

• Philosophierègles écrites : définition, priorités, couleurs, responsabilités
• Mesurecharge, avalanches, mauvais acteurs
• Rationalisationrevue alarme par alarme, décision documentée
• Mise en œuvreseuils, temporisations, alarmes conditionnées à l’état
• Suiviindicateurs mensuels partagés avec l’exploitation
• Modificationstoute création ou suppression passe par une validation

La philosophie d’alarme est un document court qui fixe les règles du site : ce qui mérite une alarme, comment on attribue une priorité, qui peut créer, modifier ou masquer une alarme, quels indicateurs on suit. Sans elle, chaque revue repart de zéro et les dérives reviennent dès que l’équipe change.

La mise en œuvre mobilise des techniques connues : une bande morte ou une temporisation pour les alarmes répétitives, des alarmes conditionnées à l’état de l’installation (démarrage, arrêt, maintenance), le regroupement des conséquences d’une même cause derrière une alarme de tête. Ces modifications touchent la configuration des automates ou de la supervision ; elles se testent comme toute modification de programme, idéalement sur un jumeau virtuel avant la mise en service.

La rationalisation, alarme par alarme

La revue se fait en groupe restreint : un opérateur expérimenté, un ingénieur procédé, un automaticien, et la personne chargée de la sécurité du procédé pour les alarmes qui contribuent à une protection. Pour chaque alarme, le groupe répond à la même série de questions, et consigne la réponse.

• Quelle anomalie l’alarme signale-t-elle, et quelle en est la cause probable ?
• Quelle action est attendue de l’opérateur, et de combien de temps dispose-t-il ?
• Quelle est la conséquence si rien n’est fait, et donc quelle priorité lui revient ?
• Une autre alarme signale-t-elle déjà la même situation ?
• Est-elle pertinente dans tous les états de l’installation, ou faut-il la conditionner ?
• Le seuil et la temporisation sont-ils justifiés par le procédé, ou hérités d’un réglage par défaut ?
• Contribue-t-elle à une fonction de sécurité, auquel cas toute modification suit une procédure renforcée ?

Le résultat est une base de rationalisation : pour chaque alarme, sa justification, sa priorité, son action attendue. Cette base devient la référence de la configuration, et la fiche d’aide que l’opérateur peut consulter quand l’alarme apparaît.

Ce que l’analyse de données peut apporter

L’historique des alarmes est un gisement de données rarement exploité. Des méthodes d’analyse, dont certaines relèvent de l’apprentissage automatique, peuvent repérer des alarmes qui surviennent toujours ensemble, des séquences qui précèdent un arrêt, des seuils manifestement mal réglés. Elles accélèrent la mesure et préparent la revue.

Leur place s’arrête là. Décider qu’une alarme est superflue engage la sécurité de l’installation et la responsabilité de l’exploitant : cette décision reste humaine, argumentée et tracée. Un outil qui masquerait automatiquement des alarmes en exploitation, sur la base d’une corrélation, déplacerait le risque au lieu de le réduire. C’est la logique que nous appliquons dans notre offre d’IA d’entreprise : des outils qui préparent la décision, encadrés et audités.

Par où commencer

Un premier pas raisonnable tient en un mois. Extraire l’historique d’alarmes d’une unité sur quatre semaines ; calculer la charge par opérateur, les périodes d’avalanche et le classement des alarmes les plus fréquentes ; réunir le groupe de revue sur les dix premières. En parallèle, rédiger une première version de la philosophie d’alarme, même brève.

Ce diagnostic donne une image chiffrée de la situation, propre à votre site, et des premières corrections à fort effet. Il s’inscrit dans un travail plus large sur l’automatisme et la supervision, que notre expertise industrie et automates accompagne, et que notre dossier de référence sur les automates programmables replace dans l’ensemble du système d’information industriel.

Questions fréquentes

Combien d'alarmes un opérateur peut-il traiter ?

Les guides de référence du domaine (EEMUA 191, ISA-18.2) donnent des repères de l'ordre d'une alarme toutes les dix minutes en fonctionnement normal comme cible confortable, et considèrent qu'au-delà d'une dizaine d'alarmes en dix minutes on entre dans une situation d'avalanche. Ce sont des repères, à adapter au procédé et à l'organisation de la salle de contrôle.

Peut-on simplement supprimer les alarmes inutiles ?

Oui, mais pas sans méthode : chaque alarme est examinée (cause, conséquence, action attendue, délai), la décision est documentée et validée par l'exploitation et la sécurité, et la modification passe par la gestion des modifications. Une suppression non tracée peut retirer une protection dont personne ne se souvenait.

L'intelligence artificielle peut-elle gérer les alarmes à notre place ?

Elle peut aider à repérer des alarmes corrélées, des séquences répétitives ou des causes communes dans l'historique, et proposer des regroupements. Elle ne doit pas décider seule de masquer une alarme en exploitation : la responsabilité de la configuration reste humaine et documentée.