# IHM haute performance : 8 règles pour un écran de supervision web

Source : https://consignestudio.fr/guides/ihm-haute-performance-regles/ · publié le 2026-10-27 · Antoine Despres, Consigne

Une IHM haute performance est calme quand tout va bien, pour que l'anomalie se voie en une seconde. Concrètement : fond gris, couleur réservée aux alarmes, chaque mesure située par rapport à sa plage normale, quatre niveaux d'écrans, et des commandes en deux temps. Voici les huit règles et leur traduction en code web.

## Pourquoi les écrans de supervision fatiguent

Un écran de supervision est regardé huit à douze heures d'affilée par quelqu'un dont le métier est de remarquer ce qui change. Tout ce qui attire l'œil sans raison consomme un peu de cette attention : pompes vertes et rouges, tuyauteries animées en permanence, jauges circulaires sans repère, fond bleu nuit. Au bout de quelques semaines, l'opérateur ne voit plus la couleur, puisqu'elle ne signifie rien. Le jour où elle signale un vrai problème, elle passe inaperçue.

Les développeurs web reproduisent souvent ces défauts de bonne foi. Ils appliquent des réflexes justes ailleurs : le tableau de bord marketing qui doit impressionner, le design system grand public où le vert veut dire « succès », le responsive qui réorganise l'écran, la bibliothèque de graphiques qui recalcule l'échelle toute seule. En salle de contrôle, chacun de ces réflexes nuit.

L'approche dite « haute performance » a été formalisée par le *High Performance HMI Handbook* (2008), puis encadrée par la norme ANSI/ISA-101.01-2015. Son idée centrale tient en une phrase : **en situation normale, l'écran doit être calme, pour que l'anomalie se voie dès qu'elle apparaît.**

## Les 8 règles et leur traduction en code

| Règle | Ce qu'elle veut dire | Traduction web |
|---|---|---|
| 1. Calme par défaut | Fond gris, éléments neutres, presque aucune couleur vive en marche normale | un jeton `--hmi-bg` gris clair, des équipements en gris foncé |
| 2. Une couleur, un sens | Chaque couleur vive a un seul usage : une priorité d'alarme, ou la qualité de donnée | quatre jetons `--hmi-alarm-1…4`, un jeton qualité, aucun autre |
| 3. Information plutôt que donnée | La valeur est montrée avec sa position par rapport au normal | une barre analogique avec plage normale et seuils L, H, LL, HH |
| 4. Le temps comme contexte | Une tendance courte à côté des mesures clés montre la dérive avant le seuil | une mini-tendance de 15 à 60 min, échelle fixe |
| 5. Hiérarchie d'écrans | Quatre niveaux, du site au diagnostic | des routes `/site`, `/unite/:id`, `/equipement/:id`, `/diagnostic/:id` |
| 6. Codage redondant | Forme, couleur et texte disent la même chose | pastille triangle, losange, carré ou rond, avec chiffre et `aria-label` |
| 7. Honnêteté de la donnée | Une valeur douteuse, forcée, simulée ou figée est signalée comme telle | chaque mesure transporte `{ value, quality, sourceTime }` |
| 8. Commandes sûres | Toute action se fait en deux temps, et l'écran montre l'état retourné, pas l'ordre envoyé | sélectionner, puis confirmer ; afficher le retour d'état de l'automate |

## Règle 1 et 2 : le gris d'abord, la couleur ensuite

Le fond gris clair a deux justifications solides : il éblouit moins qu'un blanc pur sur de longues périodes, et il laisse de la marge dans les deux sens (un texte foncé, une surface plus claire, un symbole plus sombre restent tous distinguables).

Une affirmation circule : le gris ferait mieux ressortir les couleurs d'alarme qu'un fond noir. Les calculs de contraste ne la confirment pas. Sur un fond sombre bien choisi, un rouge d'alarme contraste souvent mieux que sur un gris clair. L'argument du gris porte sur le confort et la cohérence avec l'éclairage de la salle, pas sur le contraste.

Ce qui compte vraiment, c'est la rareté. Si la pompe en marche est verte, la vanne ouverte verte et la cuve pleine bleue, le rouge d'une alarme doit se battre contre tout l'écran. Si tout est gris, il gagne sans effort.

Côté code, la règle se tient avec des jetons CSS. Les couleurs vives n'existent que sous des noms d'alarme : un développeur qui voudrait colorer un bouton « pour faire joli » ne trouve tout simplement pas de jeton pour le faire.

> Les couleurs doivent aussi passer les seuils de contraste. Le critère WCAG 1.4.11 demande 3:1 pour un élément graphique. Un jaune assez clair pour être perçu comme jaune n'y arrive pas sur fond gris : la pastille jaune reçoit alors un contour foncé, et c'est sa forme qui porte l'information.

## Règle 3 : afficher une information, pas un chiffre

« 72,4 °C » ne dit pas si c'est bien. La barre analogique haute performance le dit : une barre grise, une zone normale légèrement marquée, des repères de seuils, et un curseur. Tant que le curseur est dans la zone normale, rien ne ressort. Dès qu'il franchit un seuil, la valeur prend la couleur de la priorité d'alarme.

Aligner plusieurs barres verticalement donne un effet très puissant : l'œil repère instantanément le curseur qui n'est pas aligné avec les autres. C'est la raison pour laquelle les écrans haute performance ressemblent à des rangées de petites barres plutôt qu'à des jauges circulaires.

## Règle 4 : le temps comme contexte

Une valeur instantanée cache sa tendance. Une température à 85 % de son seuil haut et stable n'appelle aucune action ; la même valeur qui monte depuis vingt minutes en appelle une. Une tendance courte à côté de chaque mesure clé rend la dérive visible avant l'alarme.

Deux pièges propres aux bibliothèques web : l'échelle automatique (qui transforme un bruit de mesure en catastrophe apparente) et les transitions animées (qui font bouger l'écran sans raison). Une tendance de procédé a une échelle fixe, définie par l'ingénierie, et ne s'anime pas.

## Règle 5 : quatre niveaux d'écrans

| Niveau | Question | Contenu typique |
|---|---|---|
| 1. Vue d'ensemble | Tout va-t-il bien sur le site ? | indicateurs clés, état des unités, compteurs d'alarmes par priorité |
| 2. Vue d'unité | Comment se comporte cette unité ? | synoptique simplifié, barres analogiques, tendances courtes |
| 3. Détail | Que se passe-t-il sur cet équipement ? | faceplate, consignes, modes, verrouillages |
| 4. Diagnostic | Pourquoi, et que faire ? | données brutes, entrées-sorties, procédures |

Le niveau 2 est l'écran de travail : c'est lui qu'on dessine en premier et qu'on teste avec des opérateurs. Un bon critère de recette : depuis n'importe quel écran, l'opérateur atteint le niveau 1 en un clic, et n'importe quel équipement en alarme en deux clics au plus depuis la liste d'alarmes.

Une conséquence pour le web : **pas de responsive**. L'opérateur retrouve chaque mesure au même endroit, tous les jours. La position fait partie de l'information. On conçoit une grille fixe par format de moniteur, pas une mise en page qui se réorganise.

## Règle 6 : coder chaque alarme trois fois

Environ 8 % des hommes d'ascendance européenne ont une forme de daltonisme rouge-vert. Dans une équipe de quarante opérateurs, deux ou trois sont probablement concernés, et pour eux le rouge et l'orange se confondent. Chaque priorité est donc portée par sa couleur, sa forme et son chiffre, et décrite en texte pour les lecteurs d'écran.

La répartition des priorités compte autant que leur nombre. Un ordre de grandeur souvent cité pour trois priorités est d'environ 80 % d'alarmes basses, 15 % moyennes et 5 % hautes. Si la moitié des alarmes d'un site sont « hautes », la priorité ne trie plus rien.

## Règle 7 : ne jamais mentir sur la donnée

Une IHM web ajoute des sources de mensonge qu'un SCADA classique gère tout seul : un WebSocket coupé qui laisse la dernière valeur affichée, un `null` converti en 0, un `NaN` affiché tel quel. Une valeur figée par une perte de liaison ressemble exactement à une valeur stable.

La parade : chaque mesure transporte sa qualité et son horodatage source, et la liaison est surveillée par un signal de vie, pas seulement par l'âge de la dernière valeur. Une donnée douteuse prend la couleur réservée à la qualité, différente de toutes les couleurs d'alarme, pour qu'un problème de capteur ne soit jamais confondu avec un problème de procédé.

## Règle 8 : des commandes en deux temps

Un clic ne démarre pas une pompe. On sélectionne l'équipement, puis on confirme l'action dans un panneau qui rappelle ce qui va se passer. Ensuite, l'écran affiche l'état **retourné par l'automate**, pas l'ordre envoyé : si la pompe n'a pas démarré, l'opérateur doit le voir. Quand une commande est impossible (verrouillage, mode local), l'écran dit pourquoi au lieu de griser le bouton sans explication.

## Vérifier un écran en 5 minutes

1. **Test des cinq secondes** : montrez l'écran cinq secondes à quelqu'un qui ne le connaît pas, cachez-le, demandez « y a-t-il un problème, et où ? ».
2. Comptez les couleurs vives en marche normale. Plus de zéro ou une, c'est trop.
3. Cherchez une mesure affichée sans repère de normalité.
4. Imprimez l'écran en niveaux de gris : les priorités d'alarme se distinguent-elles encore ?
5. Coupez la liaison : l'écran le montre-t-il en moins de quelques secondes ?

> Ces règles ne sont ni une charte graphique ni une certification. Chaque site les ajuste à son éclairage et à sa philosophie d'alarme, puis les écrit dans une charte IHM que tous les écrans respectent. Pour un engagement contractuel, c'est le texte de la norme qui fait foi.

## Pour aller plus loin

Le [guide IHM haute performance pour développeurs web](https://consignestudio.fr/ihm-haute-performance-isa-101/) détaille chacune de ces règles sur 55 pages, avec le code testé et une checklist d'audit de 40 points (dont un extrait de 10 points gratuit). Les [composants hmi-kit](https://consignestudio.fr/composants-web-ihm-scada/) appliquent ces règles en Web Components pour Angular, React ou HTML. Si vous voulez un regard extérieur sur vos écrans existants, l'[audit IHM à distance](https://consignestudio.fr/audit-ihm-supervision/) les note sur 40 critères à partir de simples captures.

## Sources

- Bill Hollifield, Dana Oliver, Ian Nimmo, Eddie Habibi, The High Performance HMI Handbook, PAS, 2008
- ANSI/ISA-101.01-2015, Human Machine Interfaces for Process Automation Systems
- ANSI/ISA-18.2 et IEC 62682, gestion des systèmes d'alarme
- EEMUA Publication 191, Alarm systems, a guide to design, management and procurement
- [W3C, WCAG 2.2, critère 1.4.11 Contraste du contenu non textuel](https://www.w3.org/TR/WCAG22/#non-text-contrast)