Le logiciel d'un Environmental Monitoring System est la partie qui produit l'enregistrement — donc celle sur laquelle se concentre la plupart des questions en inspection. Qui peut modifier un seuil, qui peut invalider une donnée, comment démontrer qu'une valeur n'a pas été altérée, qui revoit l'audit trail et selon quels critères, où sont les données d'il y a cinq ans et qui peut encore les lire : ce sont des questions de configuration et de gestion du logiciel, non de qualité des instruments de mesure.
La règle de fond est que la data integrity se conçoit, elle ne s'ajoute pas. Rôles, permissions, traçabilité et conservation se définissent avant la configuration : une fois le système en exploitation, toute correction structurelle exige change control, re-vérification et souvent des interventions sur les données déjà produites. La seconde règle est de distinguer avec précision ce qui est une exigence réglementaire applicable à son contexte et ce qui relève d'un choix d'entreprise : confondre les deux conduit à dépenser là où ce n'est pas nécessaire et à découvrir des lacunes là où il aurait fallu agir.
Pourquoi le logiciel est le point le plus exposé du système
Un système de surveillance environnementale informatisé concentre trois fonctions qui, sur papier, seraient séparées : il acquiert la donnée, la traite et la conserve, et il en permet la revue. Qui contrôle le logiciel contrôle potentiellement les trois. C'est cette concentration qui rend nécessaires les contrôles sur les accès, la séparation des rôles et la traçabilité des modifications.
La seconde raison est la durée. Les instruments se remplacent ; les données demeurent pendant toute la période de conservation applicable et doivent rester lisibles et reconstructibles même lorsque le système qui les a générées n'existe plus. Les décisions prises aujourd'hui sur les formats, l'exportabilité et l'archivage déterminent s'il sera possible, dans plusieurs années, de répondre à une question sur un lot fabriqué aujourd'hui.
Le cadre réglementaire : ce qui s'applique réellement
| Niveau | Ce qui est établi concernant le logiciel EMS |
|---|---|
| Exigence réglementaire (EudraLex Volume 4, Annexe 11 — révision de janvier 2011) | C'est la version applicable. Elle s'applique aux systèmes informatisés utilisés dans des activités GMP et fixe des attentes sur la validation, la gestion des fournisseurs, la sécurité et la gestion des accès, l'audit trail, la maîtrise des modifications, les sauvegardes et l'archivage, la gestion des incidents, la continuité et l'évaluation périodique. |
| Texte en consultation (révision de l'Annexe 11 en cours) | Ce n'est pas une exigence en vigueur. Il peut être pris en compte pour orienter des choix de conception durables, à condition d'être explicitement déclaré comme élément prospectif. Il ne doit jamais servir de critère d'acceptation en qualification ni être cité comme une obligation. |
| Exigence réglementaire (21 CFR Part 11, FDA) | S'applique aux enregistrements et signatures électroniques dans le champ des produits réglementés par la FDA et de leurs predicate rules. Son applicabilité à votre système doit être déterminée et documentée : elle n'est pas automatique pour un site qui ne fournit pas le marché américain. |
| Exigence réglementaire (EudraLex Volume 4, Annexe 15) | Définit le cadre de la qualification et de la validation, applicable également à la composante informatisée. |
| Attente / guidance (guidance PIC/S sur la data integrity, guidances des autorités, ICH Q9(R1)) | Clarifient les attentes sur l'exhaustivité, l'attribuabilité, la lisibilité, la contemporanéité, l'originalité et l'exactitude des données, ainsi que sur l'approche basée sur le risque dans leur gestion. |
| Bonne pratique de secteur | Modèles de catégorisation des logiciels et approches structurées de la validation des systèmes informatisés largement diffusés. Ce sont des méthodologies reconnues, non des prescriptions réglementaires. |
| Recommandation opérationnelle GuideGxP | Rédiger une évaluation d'applicabilité écrite — quelles exigences s'appliquent au système, pourquoi, et lesquelles non — approuvée avant la configuration. C'est le document qui rend défendable chaque choix ultérieur. |
Guide technique
Rôles utilisateurs et segregation of duties
La matrice des rôles se définit avant la configuration, elle ne se déduit pas des profils par défaut du fournisseur. Les principes :
- Identification univoque : chaque utilisateur dispose d'identifiants personnels et non partagés ; les comptes génériques de service comptent parmi les observations les plus fréquentes.
- Privilège minimal : chaque rôle ne dispose que des permissions nécessaires à sa fonction.
- Séparation des rôles : qui configure le système ne devrait pas être la personne qui revoit les enregistrements produits ; qui exploite ne devrait pas pouvoir modifier les paramètres qui gouvernent son propre travail.
- Administration du système : les privilèges d'administration se limitent à un petit nombre de personnes, de préférence extérieures à la fonction qui exploite le système, avec activité tracée.
- Cycle de vie des comptes : création, modification, suspension et désactivation suivent un processus défini, lié aux mouvements de personnel.
- Accès du fournisseur : temporaires, autorisés au cas par cas, tracés et révoqués à la fin de l'intervention.
Audit trail : contenu et revue
Un audit trail utile répond, pour chaque événement pertinent, à quatre questions : qui, quoi, quand et pourquoi. À vérifier en spécification et en qualification :
- couverture des événements pertinents : création, modification et invalidation des enregistrements, modifications de configuration et de seuils, gestion des alarmes, événements d'accès ;
- impossibilité de désactivation ou d'altération par les utilisateurs, administrateurs compris ;
- présence du motif de la modification là où la modification est permise ;
- lisibilité sous une forme compréhensible sans outils du fournisseur ;
- possibilité de filtrer et de revoir efficacement : un audit trail techniquement complet mais non revisable en pratique ne remplit pas sa fonction ;
- conservation pendant toute la période requise pour les enregistrements auxquels il se rapporte.
La revue de l'audit trail se planifie avec une approche basée sur le risque : quels événements sont revus, par qui, à quelle fréquence et avec quelle preuve de la revue. La fréquence ne découle pas d'une règle générale mais de la criticité des données et du processus, et se justifie par écrit.
Enregistrements électroniques, signatures et gestion des données
- Définition de la donnée brute : établir ce qui constitue la donnée originale et où elle réside est le préalable de tout contrôle ultérieur.
- Métadonnées : l'enregistrement n'est pas seulement la valeur ; il comprend les informations qui permettent de l'interpréter et de le reconstruire.
- Signatures électroniques : si elles sont employées, il faut définir les opérations qui les exigent, la signification de la signature et les contrôles associés. Si le contexte ne les exige pas, la décision de ne pas les utiliser se documente.
- Gestion des données anormales : la possibilité d'exclure ou d'annoter une donnée doit être encadrée par procédure, avec motivation enregistrée et traçabilité complète. La suppression de données brutes n'est pas une fonction à configurer.
- Exports et rapports : à vérifier dans le cadre de la qualification ; un rapport présentant les données de façon incomplète ou trompeuse est un problème de système, non d'usage.
Configuration, personnalisation et validation
L'effort de validation dépend de l'écart entre le système et le produit standard. Un système configuré avec les paramètres prévus par le fournisseur représente un effort différent d'un système comportant des développements spécifiques. Le critère opérationnel : tout élément configuré ou développé doit être documenté, justifié et vérifié, et la documentation de configuration doit rester à jour comme partie du système, non classée en fin de projet.
L'évaluation du fournisseur — capacité de développement, gestion des versions, support, documentation disponible — fait partie du dispositif et se documente ; son résultat influence légitimement la profondeur des vérifications menées en propre.
Conservation, archivage et migration
- Durée de conservation : définie en cohérence avec les exigences applicables aux enregistrements concernés.
- Lisibilité dans le temps : le format d'archivage doit rester interprétable même en cas de déclassement du système ; la dépendance exclusive à un format propriétaire est un risque à évaluer explicitement.
- Migration : tout transfert de données historiques exige un plan, des critères de vérification d'exhaustivité et d'exactitude, et une preuve du résultat.
- Stratégie de sortie : la manière d'accéder aux données après la fin du contrat ou du support est une question d'appel d'offres, non de déclassement.
Revue périodique du système informatisé
Le système se revoit périodiquement pour confirmer qu'il reste en état de maîtrise : modifications intervenues, incidents enregistrés, déviations, résultat des revues d'audit trail, gestion des accès, état du support et de l'obsolescence, essais de restauration réalisés. La revue périodique n'est pas une répétition de la qualification : c'est une vérification documentée que les hypothèses sur lesquelles la qualification reposait sont toujours valables.
Outil opérationnel : checklist de configuration orientée data integrity
| Domaine | À définir avant la configuration | Preuve attendue |
|---|---|---|
| Accès | Matrice rôles-permissions approuvée | Document approuvé et configuration correspondante vérifiée |
| Accès | Processus de gestion du cycle de vie des comptes | Procédure et enregistrements |
| Audit trail | Liste des événements tracés | Vérification en OQ sur chaque type d'événement |
| Audit trail | Plan de revue basé sur le risque | Procédure avec fréquence justifiée et enregistrements de revue |
| Données | Définition de la donnée brute et des métadonnées | Document de système |
| Données | Règles de gestion des données anormales | Procédure et traçabilité dans le système |
| Seuils et alarmes | Qui peut les modifier et avec quelle autorisation | Configuration des permissions et traçage des modifications |
| Rapports | Rapports prévus et leur vérification | Vérification en OQ contre les données sources |
| Conservation | Durée, format et localisation | Politique documentée |
| Restauration | Essai de restore dans la configuration réelle | Rapport d'essai |
| Fournisseur | Évaluation documentée | Rapport d'évaluation |
| Applicabilité | Quelles exigences s'appliquent et pourquoi | Évaluation d'applicabilité approuvée |
Scénario pratique
Sur un site que nous appellerons Site Delta — réaliste mais fictif — l'équipe projet configure l'EMS en utilisant les profils utilisateurs par défaut proposés par le fournisseur, pour ne pas retarder le démarrage. Le profil destiné aux responsables d'équipe inclut, par commodité opérationnelle, la possibilité de modifier les seuils d'alarme.
La qualification se clôt sans observation : le système fait exactement ce pour quoi il a été configuré. Le problème apparaît à la première revue périodique, lorsque l'audit trail montre des modifications de seuils effectuées par du personnel opérationnel pendant la production. Aucune de ces modifications n'était irrégulière au regard de la configuration ; toutes étaient incompatibles avec le principe de séparation entre ceux qui exploitent et ceux qui définissent les paramètres gouvernant l'exploitation.
La correction — redéfinir la matrice des rôles, reconfigurer les permissions, re-vérifier, évaluer rétrospectivement les modifications déjà intervenues et en documenter l'impact — demande bien plus d'efforts que la définition préalable de la matrice. C'est le cas typique où le temps économisé au départ est rendu avec intérêts.
Erreurs fréquentes et signaux d'alerte
- Adopter les profils utilisateurs par défaut du fournisseur. Ils reflètent une hypothèse organisationnelle générique, non la séparation des rôles du site.
- Comptes partagés ou génériques. Ils rendent l'attribuabilité impossible, alors qu'elle est le premier des principes de data integrity.
- Audit trail actif mais jamais revu. L'enregistrement sans revue ne produit pas de maîtrise ; l'absence de plan de revue justifié est un constat fréquent.
- Citer l'Annexe 11 en révision comme exigence en vigueur. La version applicable reste celle de janvier 2011 ; un texte en consultation n'est pas une obligation.
- Supposer que la Part 11 s'applique toujours. L'applicabilité se détermine et se documente ; la supposer sans analyse conduit à des contrôles injustifiés, la nier sans analyse conduit à des lacunes.
- Ne pas définir la donnée brute. Sans cette définition, toute discussion sur l'intégrité et la conservation reste ambiguë.
- Configurer la possibilité de supprimer des données. La gestion des données anormales passe par l'annotation tracée, non par la suppression.
- Négliger l'exportabilité et la migration. Ce sont les sujets qui rendent coûteux ou impossible le remplacement du système des années plus tard.
- Traiter la revue périodique comme une formalité. C'est l'instrument par lequel on démontre que le système reste en état de maîtrise.
Comment documenter
- Évaluation d'applicabilité : quelles exigences s'appliquent au système et pourquoi, lesquelles non et sur quel raisonnement.
- Matrice rôles-permissions approuvée avec le rationnel de la séparation des rôles.
- Spécification de configuration tenue à jour comme document vivant.
- Plan de revue de l'audit trail avec fréquence justifiée et responsabilités attribuées.
- Définition de la donnée brute, des métadonnées et de la durée de conservation.
- Évaluation du fournisseur et son influence sur la stratégie de vérification.
- Rapport de qualification de la composante informatisée, traçable vers les exigences.
- Enregistrements de revue périodique et actions consécutives.
Points clés
- La data integrity se conçoit avant la configuration : ensuite, toute correction coûte bien davantage.
- La version applicable de l'Annexe 11 est celle de janvier 2011 ; un texte en consultation n'est pas une exigence.
- L'applicabilité de la Part 11 se détermine et se documente, elle ne se suppose pas.
- Un audit trail non revisable en pratique ne remplit pas sa fonction.
- La séparation des rôles est un choix organisationnel traduit en configuration, non l'inverse.
- Exportabilité, archivage et stratégie de sortie se négocient à l'appel d'offres, pas au déclassement.
Questions fréquentes
Quelle version de l'Annexe 11 est applicable ?
La révision de janvier 2011 reste la version applicable. Un texte en consultation peut être pris en compte pour orienter des choix durables, mais il doit toujours être déclaré comme tel et ne peut servir de critère d'acceptation en qualification.
La 21 CFR Part 11 s'applique-t-elle à notre EMS ?
Cela dépend du contexte : elle s'applique aux enregistrements et signatures électroniques dans le champ des produits réglementés par la FDA et de leurs predicate rules. La détermination se fait au cas par cas et se documente dans une évaluation d'applicabilité approuvée.
À quelle fréquence revoir l'audit trail ?
Il n'existe pas de fréquence universelle. Elle se définit avec une approche basée sur le risque, selon la criticité des données et du processus, et se justifie par écrit avec le périmètre de la revue et les responsabilités.
Peut-on utiliser des comptes de service quand plusieurs opérateurs se succèdent ?
Non, si les enregistrements doivent être attribuables à une personne. L'attribuabilité est l'un des principes fondamentaux de data integrity ; les besoins opérationnels de rapidité se résolvent par des solutions techniques d'authentification, non par le partage d'identifiants.
Qui devrait pouvoir modifier les seuils d'alarme ?
Pas ceux qui travaillent sous ces seuils. Le choix précis dépend de l'organisation, mais le principe de séparation entre exécution et définition des paramètres doit être respecté et documenté dans la matrice des rôles.
Que deviennent les données lors du remplacement du système ?
Elles doivent rester lisibles et reconstructibles pendant toute la durée de conservation. Les options — migration vers le nouveau système, archivage dans un format indépendant, maintien en lecture seule de l'ancien système — s'évaluent avec un plan documenté. Le sujet rejoint le remplacement des systèmes existants, traité dans l'article sur le retrofit d'un EMS.
Références réglementaires et techniques
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Commission européenne) : Annexe 11 (révision de janvier 2011), Annexe 15 (en vigueur depuis le 1er octobre 2015), Annexe 1 (applicable depuis le 25 août 2024).
- 21 CFR Part 11 — Electronic Records; Electronic Signatures (eCFR).
- PIC/S — Guides and Guidance Documents, y compris la guidance sur la data integrity en environnement réglementé.
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
Poursuivre le parcours projet
Cet article fait partie du parcours Environmental Monitoring Systems de GuideGxP, qui suit le cycle de vie d'un projet EMS de la définition des exigences à la gestion en exploitation.
- En amont : l'URS du système et l'infrastructure réseau et alimentation.
- En aval : FAT, SAT, IQ, OQ et PQ du système et gestion en exploitation.
- Fondements réglementaires GuideGxP : data integrity, ALCOA+ et audit readiness selon l'Annexe 11.
Envie de recevoir ce type d'analyse par email ? Abonnez-vous à The Pragmatic GMP, la newsletter GuideGxP destinée à celles et ceux qui travaillent au quotidien avec les GMP, la qualification et la data integrity.
