Un opérateur commande une vanne et voit son symbole changer de couleur. La vanne n’a pourtant pas bougé : l’écran représente la demande, tandis que le retour de position est indisponible. Ce défaut d’interface peut avoir des conséquences sur le procédé. Une IHM visuellement soignée reste trompeuse si elle ne distingue pas demande, acceptation, exécution et état confirmé de l’équipement.
La conception SCADA et IHM pour la fabrication GMP doit soutenir les décisions pendant la production, les perturbations et la reprise. Le graphisme n’est qu’une composante. Le travail déterminant concerne le contexte, les droits d’action, les limites, les enregistrements et la démonstration que les utilisateurs comprennent réellement le comportement du système.
Organiser les écrans autour des décisions opérationnelles
Partir des tâches : préparer un équipement, démarrer une opération approuvée, surveiller son avancement, diagnostiquer une condition d’autorisation absente, répondre à une alarme et transmettre les informations à l’équipe suivante. Identifier ce que l’opérateur doit connaître avant d’agir et ce qui confirme le résultat. La hiérarchie des écrans doit éviter de mémoriser des informations dispersées sur plusieurs pages.
Une vue du site donne le contexte de production et des utilités ; les vues d’unité expliquent l’état du procédé ; les détails d’équipement permettent le diagnostic et l’intervention contrôlée. La navigation conserve l’identité de l’unité, du lot, de la recette et du mode. Deux pages presque identiques ne doivent pas masquer un changement d’équipement cible au moment d’une commande.
[NORME] ISA-101.01-2015 concerne les interfaces homme-machine pour l’automatisation des procédés. Elle constitue une référence de conception sur le cycle de vie, sans imposer une disposition universelle aux installations pharmaceutiques. Appliquer ses principes au procédé, aux tâches et aux utilisateurs concernés.
Rendre visibles l’état et la qualité des données
Distinguer état mesuré, état commandé et état déduit. Une indication de pompe en fonctionnement peut provenir d’un retour électrique, d’un état du contrôleur ou d’une hypothèse fondée sur la commande. Définir la source de chaque indication et la représentation des contradictions. Une commande active ne prouve pas que le débit attendu est établi.
Présenter les modes manuel, automatique, local, distant, inhibé ou maintenance lorsqu’ils influencent l’interprétation ou l’autorité. Une valeur figée après perte de communication ne doit pas ressembler à une mesure stable et valide. Définir les conventions pour données invalides, anciennes ou absentes, avec des indications complémentaires à la couleur lorsque nécessaire.
Examiner toute la chaîne du signal. L’IHM peut communiquer avec le serveur SCADA alors que celui-ci a perdu le contrôleur. Une icône générale « connecté » ne suffit donc pas. L’opérateur doit connaître l’état des informations utiles à sa décision, leur origine et, lorsque cela compte, leur fraîcheur.
Concevoir la commande comme une interaction contrôlée
Pour chaque commande, préciser le rôle autorisé, l’état applicable, les préconditions, la confirmation et le résultat. Une action peut être impossible à cause des droits, du mode ou d’une condition procédé. Expliquer la cause permet une réponse légitime ; un bouton désactivé sans explication encourage les contournements et les demandes d’accès excessifs.
Les dialogues de confirmation doivent identifier la cible et la conséquence. Les réserver aux risques évalués : des confirmations identiques pour chaque action habituent à cliquer sans lire. Pour une modification significative, montrer la valeur actuelle, la valeur proposée, l’unité et les limites applicables avant validation.
Distinguer réception de la demande et exécution réelle. Afficher un résultat retardé, rejeté ou interrompu. Éviter les commandes répétées accidentelles susceptibles de provoquer un double dosage ou une nouvelle exécution de phase. Définir aussi l’annulation d’une demande en attente et la manière dont son résultat est confirmé.
Définir les consignes et l’intervention manuelle
Un champ numérique possède une signification technique : paramètre, unité, plage, résolution et source d’autorité. Les limites opératoires diffèrent de l’échelle d’affichage et des capacités de l’instrument. Spécifier les valeurs invalides, les séparateurs décimaux et les conversions. Un nombre identique exprimé dans deux unités différentes représente un danger prévisible.
Le mode manuel nécessite une stratégie de commande explicite : fonctions automatiques suspendues, protections maintenues et autorité requise pour la transition. L’interface signale l’intervention et conserve les actions et motifs nécessaires. Le retour en automatique doit avoir un comportement défini, sans variation de sortie inattendue et inexpliquée.
[QRM] Les limites, confirmations et autorisations découlent de l’évaluation du procédé. Ni les GMP ni une norme générale d’IHM ne fournissent une plage de consigne universelle ou une obligation de double autorisation pour toute modification. Lorsqu’une seconde autorisation est nécessaire, son déroulement concret doit être conçu et vérifié.
Relier l’identité de recette à son exécution
Afficher l’identité et la version approuvée utilisées pour l’opération actuelle. Distinguer les paramètres préparés pour le prochain lot de ceux exécutés maintenant. Si des ajustements sont permis dans des bornes approuvées, définir leur autorisation, leur enregistrement et leur présentation à la revue. Une modification opérateur ne doit pas écraser silencieusement la recette maître.
Présenter la phase courante, ses critères de fin et la raison d’une suspension. L’opérateur doit comprendre les événements passés et la prochaine action possible. Une barre de progression ne remplace pas l’état procédural. Préciser si la répétition d’une phase est autorisée et quels contrôles supplémentaires elle nécessite.
Prévoir les redémarrages. Après reprise d’un serveur, l’écran retrouve l’état réel d’exécution et ne présente pas des valeurs en cache comme actuelles. Une session restaurée ne doit pas rejouer une ancienne commande en attente. Le contrôleur et la supervision doivent appliquer le même contrat de reprise.
Utiliser les tendances pour répondre à des questions précises
Composer les tendances autour des relations opérationnelles. Une dérive de température peut nécessiter température, consigne, demande de chauffe, position de vanne et phase sur des axes temporels compatibles. Rendre les unités et les échelles explicites. Une mise à l’échelle automatique peut minimiser visuellement une variation si son changement passe inaperçu.
Distinguer affichage temps réel et consultation historique. Signaler les lacunes, changements de qualité et interpolations qui influencent l’interprétation. Une ligne continue peut cacher une interruption de collecte. La résolution et l’agrégation doivent correspondre à la question : une synthèse de navigation peut être insuffisante pour analyser un événement bref.
[BONNES PRATIQUES D’INGÉNIERIE] Vérifier les tendances avec des événements connus et les données sources conservées. Démontrer l’alignement temporel des variables, marqueurs et contextes de lot. Il n’existe pas de fréquence d’acquisition ni de durée de tendance universelle adaptée à tous les procédés pharmaceutiques.
Relier les alarmes à une réponse exploitable
Une alarme attire l’attention sur une condition nécessitant une réponse dans un délai pertinent selon la philosophie du site. Les événements et informations habituelles ne doivent pas concurrencer automatiquement ces signaux. Présenter équipement, condition, priorité et contexte utile sans obliger l’utilisateur à décoder des identifiants obscurs.
L’acquittement indique que l’alarme a été reconnue ; il ne prouve ni disparition de la condition ni réussite de l’action corrective. Maintenir ces états distincts. Masquage temporaire, suppression et inhibition répondent également à des objectifs et règles différents. Leur état doit rester accessible aux utilisateurs autorisés.
L’article sur la gestion des alarmes développe rationalisation et maîtrise du cycle de vie. Pour l’IHM, vérifier la réponse à une perturbation réaliste comprenant plusieurs alarmes liées. Cacher les alarmes gênantes de l’écran principal ne résout pas leur cause.
Intégrer la traçabilité dans le parcours d’action
Identifier les actions et changements nécessitant des preuves conservées : utilisateur, objet, valeurs ancienne et nouvelle, heure, motif et lot, selon l’usage prévu et les exigences applicables. Journal d’actions et piste d’audit GMP peuvent se recouvrir, mais leur périmètre et leur protection doivent être explicités.
Assurer l’attribution individuelle lorsque requise et contrôler les comptes partagés ou de service selon leur fonction. Examiner relève, changement de session, maintenance et postes sans surveillance. Définir le comportement des sessions selon les risques : une déconnexion brutale pendant une tâche critique peut compliquer la situation si la reprise est mal conçue.
Les heures doivent rester interprétables entre systèmes. Préciser synchronisation, fuseaux et changements d’horloge. Lors du passage à l’heure d’hiver, une heure locale ambiguë exige suffisamment de contexte dans l’enregistrement. Tester la présentation du même événement dans les écrans, les historiques et les traces d’action.
Transformer la conception en preuves d’acceptation
| Scénario | Compréhension attendue | Preuve |
|---|---|---|
| Commande de vanne refusée | Demande échouée et précondition identifiable | Tâche observée, résultat du contrôleur, explication affichée |
| Perte de communication mesure | Valeur indisponible ou ancienne | Défaut provoqué, qualité visible, contexte conservé |
| Ajustement autorisé de recette | Cible, unités, limites et version explicites | Valeurs avant et après, autorisation et trace |
| Redémarrage IHM pendant une phase | État réel récupéré sans répétition de commande | Redémarrage contrôlé et comparaison au contrôleur |
| Investigation historique | Heure, lacunes et lot interprétables | Reconstruction d’un événement connu |
Conserver les versions logicielles et configurations testées, les observations défavorables et leur traitement, y compris les problèmes d’utilisation sans erreur logicielle. Une capture montre une apparence ponctuelle ; elle ne démontre pas le comportement d’une séquence interactive.
Exemple : suspension CIP et reprise manuelle
Dans un exemple illustratif de nettoyage en place, une phase se suspend lorsqu’une condition définie n’est pas atteinte. L’écran initial montre seulement une cuve rouge et un défaut général. Les opérateurs ignorent si la phase est suspendue, arrêtée ou continue à compter le temps, avec un risque de reprise inappropriée.
La conception corrigée présente l’état de phase, la condition manquante, la tendance pertinente et les actions permises. Elle sépare acquittement et autorisation d’intervention. Tout ajustement respecte les rôles et limites approuvés, tandis que l’enregistrement relie la modification au cycle concerné.
L’acceptation comprend simulation du procédé, perte d’un signal et redémarrage IHM. Les utilisateurs identifient la condition, choisissent une réponse autorisée et expliquent l’état résultant. Les spécialistes procédé évaluent la reprise ; la qualité examine les preuves de revue. L’interface ne remplace pas une stratégie d’acceptation du nettoyage clairement définie.
Vérifier les langues et les conditions d’utilisation
Conserver des identifiants d’équipement cohérents tout en traduisant délibérément instructions et explications. Tester longueur des libellés, décimales, dates et unités dans chaque langue. Une alarme traduite qui perd son sens opérationnel constitue un défaut même lorsque la présentation reste élégante. Éviter les abréviations inexpliquées.
Évaluer distance de lecture, éclairage, cibles tactiles, gants éventuels et informations disponibles sans défilement. Un écran validé sur un grand moniteur d’ingénierie peut être inadapté au panneau installé. Consigner ces conditions pour évaluer ensuite les remplacements matériels selon le même usage prévu.
Observer des utilisateurs représentatifs réalisant des tâches anormales, sans leur indiquer à l’avance chaque bouton. Les hésitations, retours inutiles et erreurs de sélection révèlent des problèmes que la simple inspection des écrans ne détecte pas. Documenter les corrections et vérifier à nouveau la tâche affectée.
Lorsqu’un poste de secours existe, vérifier également son contexte initial : unité sélectionnée, utilisateur connecté et commandes encore disponibles. Le transfert vers ce poste ne doit pas créer une ambiguïté sur l’autorité de commande.
Maîtriser l’interface pendant son cycle de vie
Gérer objets, vues détaillées, scripts et configurations comme des composants applicatifs contrôlés. Une modification de symbole partagé touche plusieurs unités ; un changement apparemment esthétique peut masquer une information. Évaluer les tâches et risques concernés, puis vérifier le comportement après déploiement.
[RECOMMANDATION GUIDEGXP] Maintenir une philosophie IHM concise avec conventions approuvées et exemples. Examiner retours opérateurs, erreurs de commande et contournements. Actualiser la formation lorsque le comportement change. Vérifier identité de cible, qualité des données, modes dégradés, traçabilité des recettes et capacité à traiter les anomalies.
Appliquer ces principes aux systèmes Cleaning, CIP & SIP et aux Cleanrooms & HVAC. Le hub Automation & Digital Systems relie architecture, intégration et maintenance.
Cadre réglementaire et sources primaires
[EXIGENCE RÉGLEMENTAIRE] Les exigences GMP applicables encadrent fonctions et preuves, sans imposer un style graphique. Vérification au 23 septembre 2026 : Annexe 11 et Chapitre 4 de 2011 restent opératoires ; les propositions de 2025 restent des projets. Consulter EudraLex Volume 4 et 21 CFR Part 11. [NORME] Le catalogue ISA identifie ISA-101 et ISA-18.2. Tableau et scénarios sont des contenus originaux GuideGxP.
