Automatisation, SCADA et intégrité des données dans les systèmes d'eau pharmaceutique

À trois heures quarante du matin, le retour de la boucle WFI enregistre une excursion de conductivité qui dure quelques minutes et rentre d'elle-même. Personne ne la voit : l'alarme est configurée en priorité basse et l'écran se réinitialise au changement d'équipe. Deux semaines plus tard, lors de l'investigation d'un résultat microbiologique atypique, l'AQ demande la donnée brute de cette nuit-là. L'historian renvoie une valeur moyennée sur l'intervalle d'enregistrement : le pic n'existe plus. Le paramétrage de compression avait été défini par l'intégrateur à la mise en service, ne figure dans aucune spécification de configuration et aucun audit trail n'en garde la trace.

Ce n'est pas un problème d'instrumentation : les transmetteurs étaient étalonnés. C'est un problème de système informatisé — ce qui est acquis et avec quelle résolution, qui peut en modifier la configuration, où la valeur devient un enregistrement GMP et pendant combien de temps elle reste reconstituable. Dans les systèmes d'eau pharmaceutique, cette partie arrive presque toujours avec le skid, configurée par un intégrateur et réceptionnée comme « fonctionnelle ». Le périmètre Annexe 11 et Part 11 ne s'hérite pas du fournisseur : il doit être défini, justifié et documenté par le site.

Où naît la donnée et où elle devient un enregistrement

Un système d'eau comporte quatre niveaux. Les instruments génèrent le signal : conductivité, température, COT, débit, pression, ozone résiduel. L'automate (PLC) exécute la logique : régulation, verrouillages, séquences de sanitisation, comparaison aux seuils. L'IHM affiche et commande sur le terrain. Le SCADA supervise alarmes, comptes utilisateurs, recettes et tendances ; l'historian conserve la série temporelle et la rend interrogeable.

Le premier livrable d'un projet d'automatisation GMP n'est pas une spécification logicielle : c'est la cartographie du flux de données. Pour chaque paramètre critique, elle doit indiquer où la donnée naît, où elle est traitée, où elle est rendue durable, quelle copie constitue l'enregistrement de référence et qui peut la modifier à chaque niveau. Elle répond aux deux questions qui comptent en inspection : quelle est la donnée originale, et qui peut la modifier sans laisser de trace. Deux situations doivent y être traitées : si l'enregistrement durable réside dans l'historian, la chaîne qui le génère — intervalle d'échantillonnage, filtres, compression — détermine ce que cet enregistrement pourra démontrer ; et les analyseurs de COT dotés de leur propre mémoire, de leurs comptes et de leur audit trail sont des systèmes informatisés à part entière, non des composants implicitement absorbés dans le périmètre du SCADA.

Quelles données sont critiques, et pour quelle décision

La question qui débloque le périmètre n'est pas « le système est-il soumis à la Part 11 ? », mais : quelle décision GMP quelqu'un prend-il en regardant cette donnée ? Si personne ne décide rien, c'est une donnée de procédé. Si quelqu'un libère un usage, clôture une investigation ou justifie une limite, c'est un enregistrement GMP et il entraîne avec lui les contrôles.

L'Annexe 1 d'EudraLex Volume 4 rend cette cartographie non négociable sur trois points. Le 6.15 exige que les systèmes WFI incluent une surveillance continue, telle que le COT et la conductivité : c'est précisément la donnée que le système informatisé doit acquérir et conserver intègre. Le 6.13 établit que les niveaux d'alerte découlent des données de qualification initiale et sont réexaminés par la requalification, la surveillance de routine et les investigations : les seuils sont donc des paramètres de configuration qui évoluent dans le temps, et doivent évoluer sous contrôle. Le 6.14 demande que les dépassements d'alerte soient documentés, revus et investigués en distinguant l'événement isolé de la tendance défavorable : distinction possible uniquement si la série historique est complète et lisible. Les aspects métrologiques sont traités dans l'article sur la surveillance en ligne du COT et de la conductivité.

Le cadre réglementaire : ce qui est en vigueur

EudraLex Volume 4, Annexe 11 (Computerised Systems). La version en vigueur est celle de janvier 2011, applicable depuis le 30 juin 2011 : c'est le texte sur lequel on est inspecté aujourd'hui. Elle couvre par thèmes la gestion du risque, le personnel, les fournisseurs et prestataires, la validation, les données, les contrôles d'exactitude, la conservation des données, les impressions, les audit trails, la gestion des modifications et de la configuration, l'évaluation périodique, la sécurité, la gestion des incidents, la signature électronique, la continuité d'activité et l'archivage.

Le 21 CFR Part 11 est en vigueur (62 FR 13464 du 20 mars 1997, amendé par 86 FR 68830 de 2021 et 88 FR 13018 de 2023). Le guide FDA Part 11 – Scope and Application de septembre 2003 adopte une interprétation restreinte et exerce une enforcement discretion sur certains domaines, mais affirme explicitement que "part 11 remains in effect". La conséquence opérationnelle est nette : l'applicabilité de la Part 11 à un système d'eau donné doit être déterminée et documentée — quels enregistrements sont exigés par une predicate rule, lesquels sont conservés sous forme électronique, si et où des signatures électroniques sont utilisées — et non supposée ni exclue par habitude.

L'Annexe 15 (révision 2015, applicable depuis le 1er octobre 2015) régit la qualification du système d'eau, dont la partie informatisée est un composant et non un projet parallèle. L'ASTM E2500-25 fournit l'approche science- and risk-based permettant de faire découler les vérifications des aspects critiques ; l'ICH Q9(R1) (Step 4 le 18 janvier 2023) la méthode qui justifie l'étendue des contrôles. L'Aide-Mémoire PIC/S PI 009-4 « Inspection of Utilities », rév. 4 en vigueur depuis le 1er janvier 2021, est le document avec lequel les inspecteurs structurent l'examen des utilités.

Aucun de ces textes ne fixe de fréquence de sauvegarde, de durée de conservation des journaux ni de périodicité d'évaluation : ce sont des paramètres que le site déduit du risque et justifie.

Le projet de révision de l'Annexe 11 : ce n'est pas un texte en vigueur

Il faut le dire explicitement, car c'est aujourd'hui la principale source de confusion dans les cahiers des charges. Un projet de révision de l'Annexe 11, accompagné de la révision du Chapitre 4 et d'une nouvelle Annexe 22 consacrée à l'intelligence artificielle, a fait l'objet d'une consultation publique du 7 juillet 2025 au 7 octobre 2025. Il n'a pas été adopté et aucune date d'application n'a été publiée. Son contenu n'est pas repris ici : il peut changer avant l'adoption et le citer comme exigence serait incorrect. Règle opérationnelle sans nuance : le projet ne se cite pas dans une URS comme exigence, ne justifie pas un écart et ne figure pas dans un dossier comme base réglementaire. En inspection, c'est le texte de 2011 qui s'applique.

L'ignorer au stade de l'achat serait toutefois discutable, pour une raison purement d'ingénierie : un système d'eau vit des décennies, alors que l'infrastructure logicielle s'achète une seule fois. Les capacités qui rendent un système robuste face à toute évolution réglementaire — audit trail interrogeable et exportable dans un format ouvert, export des données brutes sans le fournisseur, comptes nominatifs et rôles ségrégués natifs, synchronisation horaire centralisée, restauration vérifiable, traçabilité des sessions distantes, politique de support et de correctifs déclarée — coûtent peu si elles sont demandées avant la commande et deviennent onéreuses en rétrofit. Elles doivent cependant être écrites dans les URS du système d'eau pour ce qu'elles sont : des exigences utilisateur motivées par le cycle de vie, non des exigences réglementaires.

Les contrôles qui tiennent en inspection

Audit trail

L'Annexe 11 demande, sur la base d'une évaluation du risque, que le système génère un enregistrement des modifications et suppressions pertinentes pour la GMP, disponible sous une forme compréhensible et revu régulièrement. Sur un système d'eau, le contenu minimal découle de la cartographie du flux de données : seuils d'alerte et d'action, paramètres des cycles de sanitisation, forçages de verrouillages, désactivation d'une alarme ou d'un point de mesure, configuration d'acquisition, coefficients d'étalonnage, acquittements d'alarme, connexions, restaurations depuis sauvegarde.

L'erreur la plus fréquente est une erreur de périmètre : la traçabilité existe dans le SCADA, mais le paramètre est réellement modifiable au niveau de l'automate via le logiciel de programmation, où il ne laisse aucune trace. L'audit trail doit couvrir le niveau où le paramètre est effectivement modifiable ; si ce n'est pas possible, l'accès à ce niveau doit être bloqué par conception et la modification acheminée vers le niveau tracé. La seconde erreur porte sur la lisibilité : une traçabilité exportable uniquement dans un format propriétaire, ou interprétable seulement par le technicien du fournisseur, ne fonctionne pas au moment où elle sert.

Sur la revue des audit trails, aucun texte en vigueur ne fixe de fréquence universelle. Elle doit être définie et justifiée par le site en fonction de la criticité du paramètre, en combinant généralement une revue déclenchée par l'événement — chaque investigation sur une excursion vérifie ce qui a été modifié et par qui — avec une revue périodique planifiée. L'inspecteur ne vérifie pas le chiffre : il vérifie le rationnel et la preuve de l'exécution.

Gestion des accès

Comptes nominatifs, jamais partagés : l'IHM d'atelier avec un compte générique « opérateur » reste l'observation la plus simple à rédiger et la plus difficile à défendre, car elle rend impossible l'attribution de toute action. La matrice rôles/droits est un livrable qualifié, non un réglage d'usine : elle se définit dans les URS, se vérifie en OQ en prouvant que chaque rôle peut faire ce qu'il doit et ne peut pas faire le reste, et se maintient sous change control. Trois principes la structurent. La ségrégation : celui qui administre les comptes ne génère ni n'approuve les données critiques. Le cycle de vie du compte : attribution, modification et révocation rattachées à l'arrivée, au changement de poste et au départ — les comptes actifs de personnes ayant quitté le site sont le défaut le plus récurrent en audit interne. Les comptes fournisseur : désactivés par défaut, activés sur demande approuvée et pour la durée de l'intervention, avec session tracée.

Synchronisation horaire

Automate, SCADA, historian, analyseurs dotés de leur propre mémoire et LIMS doivent se référer à une source horaire commune. Sans cela, la corrélation entre excursion, alarme, prélèvement, résultat de laboratoire et action menée n'est pas démontrable, et l'investigation exigée par l'Annexe 1 6.14 s'arrête avant de commencer. Doivent être gérés explicitement le fuseau horaire et le passage à l'heure d'été — qui génère des enregistrements dupliqués ou manquants s'il n'est pas anticipé —, le format d'horodatage sur toute la chaîne et le droit, restreint et tracé, de modifier l'horloge. La vérification relève de la qualification et se recontrôle à l'évaluation périodique.

Alarmes

Un SCADA de système d'eau gère facilement des centaines de tags. Le problème n'est pas de générer des alarmes : c'est qu'elles soient gérables et que chacune conduise à une action. La première séparation se fait entre alarmes de procédé et de maintenance et alarmes qualité, liées aux niveaux d'alerte et d'action sur la conductivité, le COT, la température, le débit et l'ozone résiduel ; les mélanger produit un flux indistinct dans lequel l'opérateur apprend à tout ignorer. La configuration est un livrable formel : tag, seuil, priorité, texte, destinataire, action attendue et renvoi à la procédure. Le système doit distinguer alerte et action, archiver tout le cycle de vie de l'événement — activation, prise en charge, retour à la normale, conclusion — et permettre de modifier les seuils sous change control avec preuve dans l'audit trail, puisque l'Annexe 1 6.13 impose que ces niveaux soient réexaminés. La suppression temporaire d'une alarme doit être une fonction contrôlée, tracée et à échéance, non une pratique de chantier.

Sauvegarde et restauration

Doivent être sauvegardés le programme de l'automate, la configuration du SCADA, la base des comptes, les séries historiques, l'audit trail, les recettes et les paramètres de cycle. La question qui compte n'est pas de savoir si les sauvegardes sont exécutées, mais si la restauration a été testée : une restauration jamais testée est une continuité déclarée, non démontrée. Le test relève de la qualification et se répète à l'évaluation périodique et après modification substantielle.

La fréquence des sauvegardes, le nombre de générations conservées et la durée de conservation ne sont fixés par aucune exigence chiffrée universelle : ils s'établissent à partir de la criticité des données, de la perte maximale acceptable pour les décisions que ces données soutiennent et des exigences de conservation applicables au site, et se documentent dans le rationnel du système. La distinction reste ferme entre la sauvegarde, destinée à la reprise opérationnelle, et l'archivage, destiné à la lisibilité de l'enregistrement dans le temps : sur un système appelé à vivre aussi longtemps que la boucle, l'obsolescence du format et du logiciel de lecture est un risque à évaluer au choix de la plateforme.

Interfaces vers les autres systèmes

Un système d'eau reste rarement isolé : il échange des données avec le LIMS (résultats chimiques et microbiologiques hors ligne), avec le MES ou l'ERP, avec l'EMS ou la GTB, avec la GMAO, ainsi qu'avec les outils de reporting utilisés en product quality review. Pour chaque interface doivent être définis la donnée échangée, le sens, le système de référence pour cette donnée, les contrôles d'exactitude et de sécurité du transfert, le comportement en cas d'indisponibilité du destinataire et le mode de détection d'un transfert échoué. L'Annexe 11 exige précisément que les systèmes échangeant des données par voie électronique intègrent des contrôles de saisie et de traitement corrects et sûrs des données.

Deux points pratiques. La transcription manuelle d'une valeur du SCADA vers un formulaire papier est elle aussi une interface, la moins fiable : elle doit être encadrée par une vérification indépendante et déclarée comme risque résiduel. Et lorsque la même donnée vit dans plusieurs systèmes, il faut décider quelle copie constitue l'enregistrement, faute de quoi l'investigation choisit a posteriori quelle version de la vérité utiliser — précisément ce que l'intégrité des données exclut. La même logique appliquée à un système de surveillance environnementale est approfondie dans l'article sur le logiciel EMS, Annexe 11 et Part 11.

Accès distant, cybersécurité et correctifs

L'assistance à distance du fournisseur est le mode de support normal et, en même temps, le moyen normal de perdre la maîtrise de la configuration. Les exigences minimales à fixer au contrat et en procédure : connexion non permanente et initiée par le site, authentification nominative, approbation documentée par intervention, enregistrement de la session, revue des modifications à l'issue, et change control pour toute intervention touchant des paramètres ou un logiciel en état validé.

Sur la cybersécurité, la tension est connue : la logique de sécurité demande d'appliquer les correctifs rapidement, celle de validation de ne rien modifier sans évaluation. La réponse n'est pas de choisir un camp, c'est d'avoir un processus : catégories de correctifs définies à l'avance, critères préétablis d'évaluation de l'impact sur les fonctions GMP, vérifications proportionnées et parcours d'urgence documenté pour les vulnérabilités critiques. Un système non mis à jour est également un risque GMP : indisponibilité, perte de données historiques et altération des enregistrements sont des conséquences qualité. La ségrégation du réseau d'automatisation par rapport au réseau bureautique et à internet est une mesure de conception. Les URS doivent exiger la durée de support déclarée, la politique de publication des correctifs, la compatibilité entre versions et la disponibilité de la documentation de configuration : un SCADA sur un système d'exploitation qui n'est plus supporté se traite par un rétrofit, pas par un correctif.

CSV basée sur le risque : que valider, et sur quelle base

Le point de départ est une détermination documentée : quelles fonctions sont critiques GMP, quels enregistrements électroniques sont exigés par une predicate rule, si et où des signatures électroniques sont utilisées. Cette évaluation établit le périmètre Part 11 et est cohérente avec le guide FDA de 2003. Déclarer « le système n'est pas Part 11 » sans évaluation n'est pas défendable ; déclarer « tout est Part 11 » est coûteux et tout aussi peu argumenté.

L'étendue de la validation se gradue sur le risque avec la méthode de l'ICH Q9(R1). Le logiciel d'un système d'eau est presque toujours un logiciel configuré sur plateforme commerciale : la stratégie efficace consiste à évaluer le fournisseur — l'Annexe 11 exige l'évaluation des fournisseurs et la gestion des prestataires —, à exploiter lorsque l'évaluation le permet la documentation de développement et de test qu'il a déjà produite, et à concentrer sa propre vérification sur la configuration spécifique du site et sur les fonctions critiques.

Les essais ne doivent pas être dupliqués par rapport à la qualification du système d'eau : ils appartiennent au même plan, avec l'approche ASTM E2500-25 qui fait découler chaque vérification d'un aspect critique identifié. Sur le terrain, on vérifie typiquement la correspondance entre la valeur lue par l'instrument, la valeur affichée et la valeur archivée jusqu'à l'historian ; le comportement au dépassement des seuils ; les droits effectifs par rôle, éprouvés aussi en négatif ; la génération de l'audit trail ; la restauration ; la synchronisation horaire ; le comportement en cas de perte d'alimentation ou de réseau. La façon dont ces essais s'insèrent dans les FAT, SAT, IQ, OQ et PQ est traitée dans l'article sur la qualification du système d'eau ; les essais sur les cycles, que le système doit enregistrer intégralement, dans celui sur la qualification des cycles de sanitisation.

Revue périodique du système informatisé

L'Annexe 11 exige que les systèmes informatisés soient évalués périodiquement afin de confirmer qu'ils restent en état validé et conformes. La fréquence n'est pas fixée par un chiffre : elle s'établit selon la criticité et le risque, s'écrit en procédure et se justifie. Ce qui rend la revue utile plutôt que formelle : les modifications réalisées sur la période et leur statut de change control ; les déviations et incidents ; la performance des alarmes, y compris alarmes chroniques et suppressions encore actives ; le résultat des revues d'audit trail ; la liste des comptes comparée au personnel réellement en poste ; le résultat des tests de restauration ; l'état du support logiciel et de l'obsolescence ; le retard d'étalonnage. Ce n'est pas un exercice séparé : il réexamine les mêmes tendances que la revue périodique du système d'eau et doit être planifié avec elle. Les autres phases du cycle de vie sont rassemblées dans le hub du cluster Pharmaceutical Water & WFI.

Exemple d'application : Site Delta

Exemple pédagogique, site fictif. Site Delta achète un nouveau système WFI et traite l'automatisation comme un accessoire de la fourniture mécanique. Quatre points ressortent en design review : l'analyseur de COT dispose de sa propre mémoire, de ses comptes et de son audit trail, non intégrés au SCADA ; les seuils d'alerte sont modifiables depuis le logiciel de programmation de l'automate sans trace dans le SCADA ; la configuration d'acquisition de l'historian a été définie par l'intégrateur et ne figure dans aucune spécification ; la sauvegarde ne couvre que la base historique et les comptes prévus sont partagés par équipe.

Actions convenues avant le FAT : cartographie du flux de données signée par l'Ingénierie et l'AQ ; paramètres critiques listés avec le niveau où ils résident et l'exigence d'audit trail à ce niveau ; modification des seuils bloquée au niveau automate et acheminée vers le SCADA avec comptes nominatifs ; configuration de l'historian déclarée paramètre qualifié et placée sous change control ; test de restauration complet inclus en OQ ; analyseur de COT traité comme système autonome. Le coût s'est concentré avant la commande, là où il s'agit d'une clause contractuelle : les mêmes modifications après le SAT auraient été des avenants au prix du fournisseur, avec retard sur le planning.

Matrice de décision : architecture de gestion de la donnée

La colonne des poids est volontairement vide : ils dépendent de la criticité des produits, du parc de systèmes et de la maturité IT/OT du site, et doivent être attribués et justifiés en interne avant toute notation.

Checklist de design review et d'audit interne

• Cartographie du flux de données approuvée, avec l'enregistrement de référence pour chaque paramètre critique.
• Évaluation documentée de l'applicabilité de la Part 11 et de la criticité GMP des fonctions.
• Audit trail actif au niveau où les paramètres sont modifiables et exportable sans le fournisseur.
• Configuration de l'historian déclarée, qualifiée et sous change control.
• Matrice rôles/droits vérifiée en positif et en négatif ; aucun compte partagé ; révocation liée aux processus RH.
• Source horaire commune ; gestion documentée du fuseau et de l'heure d'été.
• Liste d'alarmes avec priorité et action attendue ; alerte distincte d'action ; aucune suppression permanente.
• Test de restauration réalisé et documenté, pas seulement planifié.
• Accès distant du fournisseur non permanent, approuvé par intervention et enregistré.

Erreurs fréquentes et red flags

• « Le système est Part 11 compliant », déclaré par le fournisseur. La conformité est une propriété de l'implémentation et de l'usage, non du produit.
• Le projet de révision de l'Annexe 11 cité comme exigence. Il n'est pas adopté et n'a pas de date d'application : c'est le texte de janvier 2011 qui s'applique.
• Audit trail seulement au niveau SCADA alors que les seuils sont modifiables dans l'automate. La traçabilité ne couvre pas le point où la modification a réellement lieu.
• Comptes partagés sur l'IHM d'atelier. Ils rendent impossible l'attribution d'une action à une personne.
• Compression ou intervalle d'enregistrement réglés à la mise en service et jamais formalisés. La donnée nécessaire à l'investigation peut ne plus exister.
• Sauvegardes régulières et restauration jamais testée. Continuité déclarée, non démontrée.
• Connexion distante du fournisseur en permanence active. L'état validé de la configuration n'est pas défendable.
• Alarmes qualité mélangées aux alarmes de maintenance. Elles empêchent la distinction entre événement isolé et tendance défavorable exigée par l'Annexe 1 6.14.
• Horloges non synchronisées entre automate, SCADA, analyseurs et LIMS. La séquence des événements devient indémontrable.
• Fréquences de sauvegarde, de revue ou d'évaluation périodique copiées d'un autre site. Elles doivent être déduites du risque de son propre système et justifiées.

Si ce type d'analyse vous est utile au quotidien, The Pragmatic GMP rassemble des approfondissements techniques et des mises à jour réglementaires dans le même registre.

Points clés

• Le système d'automatisation est l'endroit où la surveillance continue exigée par l'Annexe 1 6.15 devient un enregistrement : si l'enregistrement n'est pas reconstituable, la surveillance ne démontre rien.
• Le périmètre se définit à partir de la décision GMP que chaque donnée soutient, non de l'étiquette du fournisseur.
• C'est la version de janvier 2011 de l'Annexe 11 qui s'applique ; le projet en consultation jusqu'au 7 octobre 2025 n'a pas été adopté et ne se cite pas comme exigence.
• L'applicabilité de la Part 11 se détermine et se documente : le guide FDA de 2003 restreint l'interprétation mais confirme que la Part 11 reste en vigueur.
• Un audit trail au bon niveau, des comptes nominatifs, une horloge commune et une restauration testée valent plus que n'importe quelle déclaration de conformité du fournisseur.
• Les fréquences de sauvegarde, de revue et d'évaluation périodique ne sont pas fixées par un chiffre réglementaire : elles se déduisent du risque et se justifient.

Références

• EudraLex Volume 4, Annexe 11 Computerised Systems — version de janvier 2011, applicable depuis le 30 juin 2011. Projet de révision (avec le Chapitre 4 et une nouvelle Annexe 22) en consultation du 7 juillet au 7 octobre 2025, non adopté. health.ec.europa.eu
• EudraLex Volume 4, Annexe 1 (C(2022) 5938 final), applicable depuis le 25 août 2023 — points 6.13, 6.14, 6.15. Annexe 15, révision 2015, applicable depuis le 1er octobre 2015.
• 21 CFR Part 11 — en vigueur. ecfr.gov
• FDA, Part 11 – Scope and Application, septembre 2003 — interprétation restreinte et enforcement discretion ; "part 11 remains in effect".
• ICH Q9(R1) Quality Risk Management, Step 4 le 18 janvier 2023. ich.org
• PIC/S PE 009-17 et Aide-Mémoire PI 009-4 Inspection of Utilities, rév. 4, en vigueur depuis le 1er janvier 2021. picscheme.org
• ASTM E2500-25 ; WHO TRS 1033, Annexe 3 (2021). who.int