On réalise vite en travaillant dans les salles de contrôle que les opérateurs de quart ne manquent pas de compétences. Ils connaissent leurs procédés, souvent mieux que les ingénieurs process qui les ont conçus. Ce qui leur fait défaut, en revanche, c’est une interface optimisée ; trop souvent, l’IHM présente l’information de façon aléatoire, trop dense, mal priorisée. Et c’est là que les choses se compliquent.
L’interface homme-machine a longtemps été le parent pauvre des projets d’automatisation. On investissait dans les automates, dans les capteurs, dans les réseaux terrain. L’IHM, se configurait en fin de projet, souvent sous contrainte budgétaire, parfois confiée à quelqu’un sans expérience réelle des opérations. Le résultat : des synoptiques surchargés, des couleurs sans aucun standard, des alarmes qui s’enchainent sans logique lisible. Et au bout du compte, des incidents dont l’analyse post-mortem révélait que l’opérateur avait eu les informations disponibles – mais qu’il ne les avait pas vues, ou pas interprétée correctement, faute d’une interface adaptée.
Ce temps-là n’est pas entièrement révolu. Mais le secteur a changé de posture.
La définition académique – dispositif matériel et logiciel permettant à un humain d’interagir avec un système automatisé – ne dit pas grand chose de la réalité terrain. Dans un contexte de supervision industrielle, l’interface homme-machine c’est d’abord un synoptique : une représentation graphique animée du procédé, avec ses tuyauteries, ses cuves, ses vannes, ses moteurs, et les valeurs qui changent en temps réel. Ce sont aussi les courbes de tendance qui permettent de voir si une température monte depuis deux heures. Les alarmes qui s’affichent avec leur priorité et leur horodatage. Les commandes qui permettent d’agir – ouvrir une vanne, démarrer une pompe, modifier un setpoint.
Tout cela s’appuie sur des couches logicielles plus ou moins complexes selon les architectures : systèmes SCADA pour les infrastructures distribuées, DCS pour les procédés continus, voire des combinaisons hybrides sur les grandes installations.
Chacune a ses forces, ses contraintes de migration, ses communautés d’intégrateurs. Ignition, notamment, a connu une adoption très rapide ces dernières années grâce à son modèle de licence par serveur et son architecture web-native – un avantage non négligeable pour les équipes qui veulent éviter les coûts de déploiement client lourd sur chaque poste opérateur.
Les premières interfaces homme-machine industrielles, ce sont des panneaux synoptiques câblés. Un voyant = un état physique dans l’installation. C’est simple, direct, sans ambiguïté. Un opérateur habitué à un panneau le lit comme un texte familier – il repère une anomalie presque avant même de l’avoir identifiée consciemment, par un changement de couleur périphérique dans son champ de vision.
L’arrivée des terminaux informatisés dans les années 1980, puis l’explosion des interfaces graphiques dans les années 1990, ont changé la donne. L’affichage devient configurable, l’information disponible explose, on peut maintenant superviser cent fois plus de points qu’avant depuis un même poste. Et c’est précisément là que les problèmes ont commencé. Parce que plus d’information ne signifie pas nécessairement meilleure compréhension. Et les premiers SCADA graphiques ont souvent produit des interfaces visuellement peu structurées, avec une colorimétrie non standardisée – du rouge partout, parfois pour signifier un état normal, parfois une alarme, selon l’humeur du configurateur.
Les référentiels qui existent aujourd’hui – la norme ISA-101 pour la conception des IHM en automatisation de procédés, l’EEMUA 191 pour la gestion des alarmes – sont en partie nés de cette prise de conscience collective. Il fallait mettre de l’ordre, imposer une discipline de conception que le secteur n’avait pas établi spontanément.
Passer une nuit de quart dans une grande salle de contrôle, c’est instructif à plus d’un titre. On comprend très vite que l’environnement impose des contraintes que peu de concepteurs d’IHM intègrent dans leur développement. La lumière basse pour préserver la lisibilité des écrans. La fatigue qui s’accumule en fin de poste. La rotation d’équipes, qui fait qu’un opérateur peut se retrouver face à une situation inhabituelle après une longue absence du process. Et par-dessus tout, la nécessité de maintenir une représentation mentale cohérente d’un système qui évolue en permanence.
Les spécialistes en facteurs humains parlent de « conscience situationnelle » – un concept emprunté à l’aviation, transposé assez naturellement aux environnements industriels critiques. Il s’agit de la capacité à percevoir ce qui se passe dans son environnement, à en comprendre la signification, et à anticiper ce qui va probablement se passer ensuite. Une IHM bien conçue soutient cette conscience situationnelle. Une IHM mal conçue la dégrade activement.
Il n’existe probablement pas de meilleur indicateur de la qualité d’une IHM industrielle que l’état de sa gestion des alarmes. Pas parce que les alarmes sont la partie la plus visible du système, mais parce qu’elles concentrent tous les défauts de conception accumulés au fil des années.
Le phénomène des « tempêtes d’alarmes » est bien documenté dans le secteur. Lors d’un incident, des dizaines voire des centaines d’alarmes se déclenchent en cascade, souvent parce que chaque sous-système a sa propre logique d’alarme sans que personne n’ait pensé à hiérarchiser l’ensemble. Certaines installations font état de plus de 300 alarmes en moins de dix minutes lors d’un incident significatif. À ce rythme, un opérateur ne peut plus rien faire d’utile – il acquitte mécaniquement, ou pire, il cesse d’acquitter du tout.
Le référentiel EEMUA 191 donne des repères chiffrés : en régime normal de supervision, un opérateur ne devrait pas avoir à traiter plus de 6 à 12 alarmes par heure. Lors d’une perturbation, le seuil critique est d’une alarme toutes les dix secondes – au-delà, la capacité de traitement humain est saturée. Des études internes menées dans des sites pétrochimiques ont montré que certaines installations opéraient en permanence bien au-dessus de ces seuils, sans que personne ne l’ait jamais formalisé comme un problème.
La rationalisation des alarmes est un travail long, souvent ingrat, qui suppose de revenir sur des années de configuration sédimentée. Mais les IHM modernes offrent des outils de plus en plus sophistiqués pour y aider : moteurs d’analyse des journaux d’alarmes, détection des alarmes récurrentes non traitées, mécanismes de suppression contextuelle selon l’état du procédé.
La question revient régulièrement dans les appels d’offres et les projets de modernisation : faut-il raisonner en termes de SCADA, de DCS, ou d’IHM ? La meilleure réponse, est que ces distinctions ont de moins en moins de pertinence.
Historiquement, le SCADA supervise des équipements géographiquement dispersés – un réseau de distribution d’eau, un réseau de gaz, des postes électriques répartis sur plusieurs centaines de kilomètres. Le DCS gère un procédé continu concentré – une colonne de distillation, un four de cimenterie. L’IHM était la couche de présentation de l’un ou de l’autre. Aujourd’hui, des plateformes comme AVEVA System Platform ou Ignition proposent une architecture unifiée qui peut assumer les deux rôles, avec une couche IHM commune accessible depuis un navigateur web.
Cette convergence a des conséquences pratiques considérables. Elle simplifie les architectures, réduit le nombre de systèmes à maintenir, facilite l’accès aux données depuis plusieurs types de terminaux. Mais elle crée aussi une pression nouvelle sur les équipes : un opérateur habitué à des outils numériques modernes dans sa vie quotidienne tolère de moins en moins une IHM avec des temps de rafraîchissement de plusieurs secondes et une ergonomie datée des années 2000. L’écart entre l’expérience numérique grand public et celle qu’offrent certains postes de supervision industrielle est devenu tellement visible qu’il commence à poser des problèmes de formation dans certains secteurs.
La migration vers des IHM basées sur les standards web (HTML5, SVG, WebSocket) représente une véritable rupture technologique pour le secteur. Elle permet théoriquement d’afficher les synoptiques dans un simple navigateur, sans client lourd, avec une mise à jour centralisée depuis le serveur. Les gains en maintenance sont réels.
Mais cette ouverture architecturale a un revers que les équipes cybersécurité industrielle connaissent bien. Une IHM accessible via un navigateur, c’est une IHM potentiellement accessible depuis le réseau IT de l’entreprise, voire au-delà si la segmentation n’est pas rigoureusement gérée. Les bonnes pratiques imposent ici une discipline stricte : zones OT et IT physiquement séparées, DMZ industrielle, authentification multi-facteur sur tous les accès distants. Des exigences que le standard IEC 62443 formalise avec précision.
Le sujet de la cybersécurité industrielle a longtemps été traité comme une préoccupation théorique par beaucoup d’industriels. L’argument revenait souvent : les systèmes OT sont isolés, air-gappés, personne ne peut les atteindre de l’extérieur. Cet argument a pris du plomb dans l’aile au fil des incidents documentés ces dernières années.
L’affaire d’Oldsmar, en Floride en 2021, illustre bien le problème. Un attaquant avait pris le contrôle à distance de l’IHM d’une station de traitement des eaux potables et avait temporairement augmenté le dosage de soude caustique à un niveau dangereux. L’accès avait été rendu possible par une IHM accessible à distance sans authentification robuste, sur un réseau insuffisamment segmenté. Un scénario que beaucoup d’installations industrielles auraient du mal à exclure pour leur propre infrastructure, si elles avaient à y regarder honnêtement.
Selon le rapport Claroty The Global State of Industrial Cybersecurity 2023, 75 % des organisations industrielles interrogées avaient subi au moins une cyberattaque ayant eu un impact opérationnel direct au cours des douze mois précédents. Les vecteurs les plus fréquents incluaient les accès distants aux IHM et aux systèmes SCADA, notamment via des outils de prise en main à distance mal sécurisés.
Il faut une certaine humilité pour concevoir une bonne IHM industrielle. L’humilité de reconnaître que l’opérateur qui utilise le système au quotidien en sait souvent plus sur ses besoins réels que l’ingénieur qui le conçoit dans son bureau.
Bill Hollifield, auteur du High Performance HMI Handbook, a contribué à populariser une approche de conception centrée sur la performance opérationnelle réelle plutôt que sur l’esthétique ou la richesse fonctionnelle. Ses recommandations peuvent sembler contre-intuitives au premier abord : des synoptiques majoritairement en niveaux de gris, peu de couleurs vives, des valeurs numériques limitées au profit des indicateurs de tendance. Derrière cette sobriété apparente, il y a une logique solide. Si tout est coloré, rien n’est prioritaire. Si le rouge est utilisé pour signaler un état normal sur certains équipements, il perd sa valeur d’alerte. La discipline chromatique, dans une IHM industrielle, n’est pas une question de goût – c’est une question de sécurité.
La modernisation d’un parc IHM sur une installation en production est un exercice délicat. Trop souvent, les projets démarrent avec une ambition de refonte totale et finissent en compromis douloureux, avec des interfaces hybrides qui cumulent les défauts des deux générations sans les avantages d’aucune.
L’approche qui fonctionne le mieux – et les retours d’expérience convergent sur ce point – c’est la migration par couches, par zones, par criticité décroissante. On commence par auditer l’existant : combien d’alarmes par heure en régime normal, quels synoptiques sont les plus utilisés, où les opérateurs perdent le plus de temps en navigation. Ces données permettent de définir des priorités réelles, pas des priorités d’ingénieurs.
La phase de conception qui suit gagne à être conduite avec les opérateurs dans la boucle dès le début.
> Ce sont des questions auxquelles ceux qui travaillent sur le procédé au quotidien peuvent répondre avec pertinence.
La résistance au changement, dans ces projets, est souvent mal comprise. Elle n’est pas irrationnelle. Un opérateur qui maîtrise parfaitement son ancienne IHM, même imparfaite, sait que la période de transition est celle où il sera le plus vulnérable.
L’IHM, c’est la couche visible – le synoptique, les écrans, la console avec laquelle l’opérateur interagit. Le SCADA est l’ensemble du système : acquisition des données terrain, transmission, stockage, restitution. En pratique, les deux termes sont souvent utilisés indifféremment, et les plateformes modernes intègrent les deux fonctions dans un même environnement logiciel.
La norme ISA-101 (ANSI/ISA-101.01-2015) est la référence principale pour la conception des IHM de supervision de procédés. L’EEMUA 191 couvre la gestion des alarmes avec des seuils chiffrés précis. Pour la cybersécurité des systèmes de contrôle, l’IEC 62443 est incontournable – et ses exigences ont des implications directes sur la façon dont les IHM doivent être déployées et sécurisées.
L’analyse des journaux d’alarmes est le premier indicateur. Si le taux d’alarmes dépasse régulièrement 12 par heure en régime normal, il y a un problème structurel. Ensuite, des entretiens avec les opérateurs de quart permettent souvent de faire remonter des frictions quotidiennes que personne n’a jamais formalisées – des navigations trop longues, des informations mal placées, des couleurs qui ne veulent rien dire. Ces retours terrain sont souvent plus révélateurs que n’importe quel audit formel.
Les accès distants non sécurisés arrivent largement en tête – des outils de prise en main à distance laissés actifs, des comptes partagés sans traçabilité, des systèmes d’exploitation non patchés depuis plusieurs années. Le phishing ciblé sur les opérateurs et les techniciens de maintenance représente aussi un vecteur croissant. La réponse passe par la segmentation réseau, l’authentification forte et, surtout, une cartographie à jour de ce qui est réellement accessible depuis l’extérieur.
La disponibilité de l’installation passe avant tout. Remplacer une IHM sur un site en production continue suppose une fenêtre de maintenance, une formation des équipes, une période de risque accru. Beaucoup d’industriels préfèrent maintenir l’existant le plus longtemps possible – ce qui est compréhensible, mais génère des problèmes de support logiciel et, de plus en plus, des vulnérabilités cybersécurité difficiles à combler sur des systèmes dont le constructeur ne publie plus de correctifs. La tendance actuelle pousse vers des cycles de renouvellement de 8 à 12 ans maximum.
Copyright © 2026. MOTILDE. All rights reserved.