Sur une ligne de remplissage de bouteilles, l’opérateur surveille un écran tactile qui affiche le débit, la température et l’état des vannes. Sur son PC de bureau, l’ingénieur de maintenance ouvre une application Windows pour analyser les historiques de production. Les deux utilisent une interface graphique, mais le contexte d’usage sépare nettement HMI et GUI. Comprendre cette distinction évite des erreurs de spécification lors du choix d’un système de contrôle ou d’un logiciel métier.
IHM industrielle et GUI logicielle : pourquoi la confusion persiste
Le terme HMI (Human-Machine Interface, ou IHM en français) désigne tout dispositif qui permet à un humain d’interagir avec une machine ou un procédé industriel. Un écran SCADA, un pupitre d’automate, un panneau à boutons physiques : tous relèvent de l’IHM.
A lire aussi : Quelle est la prochaine grande innovation ?
Le terme GUI (Graphical User Interface) désigne une couche logicielle qui présente des éléments visuels (fenêtres, icônes, menus) pour piloter un programme. Un navigateur web, un logiciel de CAO, un système d’exploitation de bureau : tous reposent sur une GUI.
La confusion vient du fait que la plupart des IHM modernes embarquent une GUI. L’écran tactile d’un poste de conduite affiche des boutons, des jauges et des courbes, exactement comme un logiciel classique. On confond alors le support (l’IHM) et la couche de présentation (la GUI). En réalité, la GUI est un composant possible de l’IHM, pas son équivalent.
A lire également : Quelle est la blockchain la plus rapide ?
Périmètre fonctionnel d’une HMI face à une simple GUI
Une GUI gère l’affichage et la saisie. Elle traduit les actions de l’utilisateur (clic, glisser-déposer, frappe clavier) en commandes logicielles, puis restitue le résultat à l’écran. Son périmètre s’arrête à l’interaction visuelle entre l’utilisateur et l’application.
Une IHM industrielle couvre un périmètre bien plus large. Elle assure la communication en temps réel avec des automates programmables (PLC), des capteurs et des actionneurs. Elle gère les alarmes, l’archivage des données de procédé, les niveaux d’accès opérateur et la traçabilité des actions. L’IHM connecte un opérateur à un procédé physique, pas seulement à un logiciel.
Ce périmètre élargi explique pourquoi la conception d’une IHM suit des normes spécifiques. La norme ANSI/ISA-101 encadre par exemple la conception, la mise en œuvre, l’exploitation et la maintenance des IHM de procédés. Aucune norme comparable ne régit la conception d’une GUI de logiciel bureautique.
Critères qui distinguent HMI et GUI sur un projet
- Environnement de déploiement : l’IHM fonctionne dans un contexte industriel (poussière, vibrations, températures extrêmes), ce qui impose des contraintes matérielles absentes pour une GUI de bureau
- Communication machine : l’IHM dialogue avec des protocoles industriels (Modbus, OPC UA, Profinet) tandis qu’une GUI standard communique avec des API logicielles classiques
- Cycle de vie : une IHM fait l’objet d’une maintenance opérationnelle planifiée (mises à jour firmware, recalibrage écran, remplacement de dalles), là où une GUI se met à jour par déploiement logiciel
- Gestion des alarmes : l’IHM intègre nativement la priorisation, l’acquittement et l’historisation des alarmes, fonctions absentes d’une GUI généraliste
Cybersécurité : un enjeu qui sépare encore plus HMI et GUI
Sécuriser une GUI revient à protéger une application : authentification, chiffrement des échanges, correctifs réguliers. Le périmètre reste logiciel.
Sécuriser une IHM impose de prendre en compte l’architecture complète de l’installation. La série de normes ISA/IEC 62443 structure la sécurité des systèmes d’automatisation industrielle par zones et conduits. Protéger l’écran seul ne suffit pas : il faut sécuriser les communications entre l’IHM, les contrôleurs et le réseau de terrain.
Le Cyber Resilience Act européen ajoute une couche réglementaire. Ce texte prévoit des obligations pour les fabricants de produits comportant des éléments numériques, notamment la sécurité dès la conception et le traitement des vulnérabilités. Un terminal IHM et un logiciel GUI sont tous deux concernés, mais les exigences pratiques diffèrent selon que le produit pilote un procédé physique ou non.
Concevoir une IHM ergonomique : au-delà du design GUI
Quand on conçoit une GUI, on optimise l’expérience utilisateur : fluidité de navigation, cohérence visuelle, accessibilité. Les principes UX classiques s’appliquent (hiérarchie visuelle, feedback immédiat, réduction de la charge cognitive).
Quand on conçoit une IHM de procédé, ces principes restent utiles mais ne suffisent pas. L’ergonomie cognitive entre en jeu : on cherche à limiter la surcharge informationnelle pour un opérateur qui surveille des dizaines de paramètres simultanément, parfois en situation de stress.
Les IHM mal conçues noient l’opérateur sous les données. Trop de couleurs, trop de chiffres affichés en même temps, des alarmes non hiérarchisées : le résultat est un écran illisible en situation critique. La norme ISA-101 recommande des principes de conception axés sur la situation : afficher uniquement les informations pertinentes pour l’état courant du procédé, pas la totalité des variables disponibles.
Certifications et contraintes terrain pour les écrans IHM
Un écran GUI de bureau n’a besoin que d’une conformité CE ou FCC standard. Un panneau IHM déployé en zone industrielle peut nécessiter des certifications supplémentaires : indice de protection IP65 ou supérieur contre la poussière et les projections d’eau, certification ATEX pour les atmosphères explosives, conformité aux normes de compatibilité électromagnétique renforcées.
Le choix d’un écran IHM engage des contraintes que la sélection d’une GUI ne pose jamais. Le matériel, le logiciel et l’environnement forment un ensemble indissociable.
HMI ou GUI : choisir le bon terme au bon moment
Dans un cahier des charges industriel, parler de GUI quand on désigne l’interface de conduite d’un procédé revient à réduire le besoin à sa couche graphique. On risque alors de sous-spécifier les fonctions de communication, d’alarme et de traçabilité.
À l’inverse, qualifier de HMI l’interface d’un logiciel de gestion ou d’un site web n’a pas de sens : aucun procédé physique n’est piloté, aucune norme industrielle ne s’applique.
- Utilisez HMI (ou IHM) quand l’interface relie un opérateur à un équipement physique ou un procédé industriel
- Utilisez GUI quand l’interface relie un utilisateur à un logiciel, sans lien direct avec un procédé
- Quand une IHM intègre une interface graphique, on peut préciser « IHM à base de GUI » pour lever toute ambiguïté dans les spécifications
La prochaine fois qu’un fournisseur propose une « GUI industrielle », vérifiez s’il livre aussi la gestion d’alarmes, la communication automate et la conformité aux normes de procédé. Sans ces fonctions, ce n’est qu’un écran, pas une IHM.
